Certificate of mail.opencsw.org has expired

[Laurent Blume via maintainers]

Hello people:

Just in case, I've noticed this morning the certifiate of 
mail.opencsw.org is expired. There has been some changes recently with 
Let's Encrypt, they've retired some methods of authentication earlier 
this month, maybe it's that?


Laurent

Re: IRC under attack

[Laurent Blume via maintainers]

Le 2018/08/01 23:46 +0200, Maciej (Matchek) Bliziński a écrit:
> On Wed, Aug 01, 2018 at 10:39:41PM +0200, Laurent Blume wrote:

> I changed the channel to +r, hopefully it'll make things better.
> 
> --Maciej
> 

Good evening,

It doesn't seem to help, sadly :/ That crap is getting worse.
There must be some magic missing...

Laurent

 

Re: IRC under attack

[Laurent Blume via maintainers]

Hello Maciej,

Thanks for intervening! I'm not very good at IRC, but I understand there
is a setting that works fairly well, without going to invite-only.
If I'm correct, it's something that only allows registered users to send
messages. I believe that's what #rhel does, for example. I'm not in
favour of invite-only either.

Laurent

Le 2018/08/01 22:04 +0200, Maciej (Matchek) Bliziński a écrit:
> Maciej (Matchek) Bliziński  > escreveu no dia quarta, 1/08/2018 às 15:46:
> 
> I've set the channel to invite-only.
> 
> 15:45  SET #opencsw MLOCK +i
> 15:45 -ChanServ(ChanServ@services.)- The MLOCK for #opencsw has been
> set to +i.
> 
> 
> After this, I can't join the channel, because I'm not invited. I can't
> invite myself, because I'm not on the channel. So I set the channel back
> to open, and I join the channel. I try to invite myself, and I get a
> message saying that I can't invite myself because I'm already on the
> channel. Great, I change the channel back to invite-only, and I try to
> join. I can't. I'm not invited.
> 
> I changed the channel back to open. Does anybody here know how to manage
> an invite-only channel?
> 
> In the meantime, I don't know if there's actually anything happening on
> #opencsw. Did anybody notice the spam bots?
> 
> Maciej


 

IRC under attack

[Laurent Blume via maintainers]

Hello people,


There's an atrocious slander campaign going on and using IRC, for more
than one week already. Could one of the #opencsw channel admins pop in
and make it registration only or something?

https://freenode.net/news/spambot-attack

Thanks in advance,

Laurent

Re: 10th Anniversary Camp!

[Laurent Blume via maintainers]

Cool!

Will there be an agenda or it's mostly a nice get-together? Or in other
words can one bring a kid safely to the freezing Irish weather?

Laurent

Le 2018/05/19 21:30 +0200, List For Opencsw Maintainers a écrit:
> Ok, the poll is now closed. The majority of folks preferred November
> 9-11, so we'll go with that. Stay tuned for more details as we plan things.
> 
> Thanks
> -Ben
> 
> On Fri, May 11, 2018 at 8:21 PM Ben Walton  > wrote:
> 
> Hi All,
> 
> We're coming up on the 10 year anniversary of OpenCSW and thought it
> might be fun to get together for a camp. Maciej and I are willing to
> host it in Dublin again. We did a bit of pre-filtering to nail down
> when both Maciej and I would be around as hosts and when Dago would
> also be available. That left us two weekends in November. Please
> vote for your preferred weekend
> here: https://doodle.com/poll/yc9xkw7vm3qqdt7t
> 
> Note that by voting for the Friday, you're voting for Fri-Sun.
> 
> We'll close the poll next Friday and publicize the chosen date. With
> that nailed down, we can arrange the rest of the camp.
> 
> I know that I've essentially gone dormant over the last years, but
> I'd still love to see you again if you're able to make it. :)
> 
> Thanks
> -Ben 
> 


 

Re: OpenCSW 10th Anniversary Camp

[Laurent Blume via maintainers]

A camp with more beer and less Solaris?
Count me in!

I'm good for Dublin, I've not been there yet.
I'm also good for pretty much any locale reachable under a 6 hour flight
for that kind of short stay, so feel free to target white beaches if you
feel like it!

:D

Laurent

Le 2018/01/15 16:13 +0100, List For Opencsw Maintainers a écrit:
> Dear maintainers,
> 
> OpenCSW was founded 6. December 2008 and we will have our 10th anniversary 
> this year!
> Personally I don’t have much to do with Solaris any more (as probably most of 
> you too)
> but I still think back how much fun it was and I wonder what all the cool 
> people
> from those days are doing now.
> 
> The camps have basically stalled in the past years (the last one was in 
> Ilmenau 2014).
> However, maybe there is some interest in doing a special 10 year anniversary 
> camp
> where all attendees talk about their current profession and hobbies and what 
> they
> think is cool, have some beer, probably hack on stuff of general interest, 
> ideas welcome!
> 
> I’ll happily take suggestions on where to make the camp and the agenda,
> I could think of making it in Dublin, first because it is easily reachable and
> also because it was a great venue last time.
> 
> 
> Best regards
> 
>  — Dago
> 


 

MySQL 5.6.35 does not support GCC anymore

[Laurent Blume via maintainers]

Hello all,


So, a head's up: since 5.6.35, Oracle decided that the only compiler 
supported on Solaris is Studio. There's a check in cmake/os/SunOS.cmake.


For now, the check can be overridden, so I've built with GCC5 as usual 
and pushed the new version. The usual recommendation applies now more 
than ever: use staging servers.


As to when Oracle starts using incompatible code, I ll announce it and 
in all likelihood, drop further upgrades, as I have no interest in 
dealing with Studio again.


5.5.54 doesn't have the issue at this point.

Laurent

Re: Conduct unbecoming of a hacker

[Laurent Blume]

Le 2016/10/31 11:02 +0100, Maciej (Matchek) Bliziński a écrit:
> Hello maintainers!
> 
> Long time no see... Here's an article I've just read. I think that we're
> doing pretty well in this regard! Still, it's good to be actively
> conscious of the issue.
> 
> http://sealedabstract.com/rants/conduct-unbecoming-of-a-hacker/


Looks like somebody hasn't quite grasped yet that the Internet of today
is used mostly by non-IT consumers, unlike their beloved Internet of the
90's, which was mostly reserved to tech people (the rest was parked in a
special area called AOL).
Is he going to whine about it until he runs out of breath? Is he also
going to whine that those tech types of the 90's built an easy-to-use
Internet that eventually allowed any non-IT consumer to connect to it
like it were an AOL browser?

Free email addresses for everybody doesn't seem like such a smart move
now, hmmm? :)

Laurent

 

.so file now appearing in two packages instead of one?

[Laurent Blume]

Hello all,

I'm having some weirdness with a simple repackaging of MySQL, where only 
the postinstall script was modified:
mgar wants to add a new dependency, which is because libmysqlclient.so 
is not included in CSWmysql56.
The prototypes do show that it (and others) are now included in two 
packages, which is weird:


CSWmysql56-dev.prototype:s none 
/opt/csw/lib/libmysqlclient.so=libmysqlclient.so.18


CSWmysql56.prototype:s none 
/opt/csw/lib/libmysqlclient.so=libmysqlclient.so.18


What could have caused that?

Laurent

Some 64 bit subdirectories not merged into pkgroot

[Laurent Blume]

Hello all,

It's been pointed to me that the Samba 3 package does not contain the
needed symlinks to have NSS/PAM work in 64 bit.
This is odd, because when I worked on it, I took time to check it was
working.

I've double-checked my recipe, it appears to be creating the symlinks
for each MEMORY_MODEL, and that shows in the install directories, all good:
work/install-isa-pentium_pro/usr/lib/nss_winbind_csw.so.1
work/install-isa-pentium_pro/usr/lib/nss_wins_csw.so.1
work/install-isa-pentium_pro/usr/lib/security/pam_winbind_csw.so
work/install-isa-pentium_pro/usr/lib/security/pam_smbpass_csw.so

work/install-isa-amd64/usr/lib/amd64/nss_winbind_csw.so.1
work/install-isa-amd64/usr/lib/amd64/nss_wins_csw.so.1
work/install-isa-amd64/usr/lib/security/amd64/pam_winbind_csw.so
work/install-isa-amd64/usr/lib/security/amd64/pam_smbpass_csw.so

But in the pkgroot, only the 32 bit version is there, no 64:
work/pkgroot/usr/lib/nss_winbind_csw.so.1
work/pkgroot/usr/lib/nss_wins_csw.so.1
work/pkgroot/usr/lib/security/pam_smbpass_csw.so
work/pkgroot/usr/lib/security/pam_winbind_csw.so

How come? mgar acting up? Considering the age of the current Samba 3
package, it would have been for around a year, at least.

Laurent

Re: Disk needed for mail server

[Laurent Blume]

Le 2016/01/31 12:22 +0100, İhsan doğan a écrit:


If they are original Sun disks, then I would prefer these, as they are
much less of trouble.


Oh really? Why? T2000 have buggy SAS controllers? Then by all means, 
change the server, not the disks.
There's no such things as original Sun disks anyway, Sun never 
manufactured any disk, only relabelled other brands, the same as HP does.


Laurent

Re: Disk needed for mail server

[Laurent Blume]

Hello,

That column could indicate something else than the disk. Have you 
checked its SMART data to be sure?


Otherwise, there was a bunch of HP hardware going to the trash not long 
ago. I think I can still put my hands on some, probably nothing that 
small, but you don't mind 146 or 300, right?

SAS, 2.5", 10k.

Laurent

Le 30/01/2016 22:31, İhsan Doğan a écrit :

Hi,

One of the disks on the OpenCSW has failed:

   pool: rpool
  state: DEGRADED
status: One or more devices has experienced an unrecoverable error.  An
 attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
 using 'zpool clear' or replace the device with 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-9P
  scan: scrub repaired 2.64M in 1h10m with 0 errors on Sun Jan 18
04:55:11 2015
config:

 NAME  STATE READ WRITE CKSUM
 rpool DEGRADED 0 0 0
   mirror-0DEGRADED 0 0 0
 c1t0d0s0  ONLINE   0 0 0
 c1t1d0s0  DEGRADED 0 023  too many errors

Does anybody has or is willing to sponsor a 73 GB disk for a T2000 machine?




Ihsan

Re: OpenSSL

[Laurent Blume]

Le 2016/01/26 17:31 +0100, Juraj Lutter a écrit:
> Hi,
> 
> I don't know if you noticed, but FYI:
> 
> http://www.securityweek.com/openssl-patch-high-severity-vulnerability
> 
> /j
> 

Do not panic.

The «high severity vulnerability» from the title impacts only 1.0.2,
which is not in OpenCSW. There is only a low one for 1.0.1.

Next time, feel free to sum up the situation instead of merely posting a
fear-inducing link.

Laurent

Re: packaging in IPS

[Laurent Blume]

Le 2015/12/09 13:40 +0100, Dagobert Michelsen a écrit:
> 1. Enable/Disable development files
> 
> I thought of having this also in SVR4 packages with pkgutil by having an 
> attribute
> for each package which lists the development package name.
> 
> 2. Switch to development version with debug symbols enabled and w/o 
> optimization
> 
> I would have wished it would be easier on deployed systems which show bugs to 
> switch
> to debug binaries/libs easily.

That's comparing it to SVR4 packaging.
There are plenty of distros systems out there which do those functions
just fine with -devel and -debuginfo packages. It's simple to
understand, simple to use, you don't even need to read the manual.
Solaris did not gain *anything*, *at all*, by introducing confusing
features that did things differently from everybody else, and OpenCSW is
not going to gain users nor maintainers by following them that way.

Compare two typical discussions:
«Development files, we do it the same way as Red Hat does, install the
-devel package.
 - Ok, get it»

«Development files, you only need to install the devel facet, the same
was as Oracle does.
 - Wait, facet? What's that?
 - You know, it's [I don't know how to explain it myself]
 - I don't get it.
 - Have you looked at the man?
 - No, reading man in Solaris sucks [true fact].
 - Have you looked at the docs on Oracle.com?
 [at this point, we've lost them]»

And using that in a production environment means you have to duplicate
and upgrade the documentation, when it could just be the exact same as
what was for S10, merely adding new examples of commands.

It's like building cycloid-shaped roads because Sun decided to build
square wheels.

But seriously, you don't really have to listen to me :) It's just my -0
for facets and any similar IPS crapola, since I'll never work on or with
it (well, unless there are significantly astronomical sums of money
involved ;)

Laurent

Re: packaging in IPS

[Laurent Blume]

Le 2015/12/09 12:24 +0100, Juraj Lutter a écrit:
> I'd preferably go with facets, to be more consistent with IPS concepts.
> We can disaggree with them but they are here and we could probably avoid
> problems that may arise in the future.

They are here, and they are one reason I decided to not migrate to S11
in the first place.
What problem exists that they fix? What problem may arise in the future?
Concrete examples please, not FUD.
I'm not a fan of using stuff just because it's lying around. I use stuff
when it's the most fit solution to a problem.

Laurent

Re: packaging in IPS

[Laurent Blume]

Le 2015/12/09 12:13 +0100, Carsten Grzemba a écrit:
> Hi folks,
> 
> for SVR4 packages we use a concept to package shared libs, header files
> and manuals in own packages like:
> CSWlibssl1-0-0 CSWlibssl-dev CSWopenssl-utils
> Although there are facets for IPS packages, I would suggest to keep this
> concept also for IPS packages

Agreed. Facets are another needlessly confusing innovation, different
for the sake of difference.

Laurent

Re: IPS package versioning

[Laurent Blume]

Le 2015/12/02 14:21 +0100, Juraj Lutter a écrit:
> On 12/02/15 14:14, Jan Holzhueter wrote:
>> I don't know if we should drop package prefix though . (what if oracle
>> does ship libwarp1 too? might confuse people to do an install
>> opencsw/libwrap1 then just cswlibrap1.)
> 
> Just for the record:
> 
> https://docs.oracle.com/cd/E26502_01/html/E21383/pkgterms.html#gludb
> 

After all those years, I'm still amazed at how disconnected with reality
the IPS designers were.

Laurent

MySQL issues on Solaris 11/sparc

[Laurent Blume]

Hello all,

Dagobert has pointed out that the MySQL packages don't work on Solaris
11/sparc, failing with this error:

This seems t151104  9:56:09 [Note] /opt/csw/libexec/mysqld (mysqld
5.5.46) starting as process 19236 ...
151104  9:56:09 [ERROR] Initialization of transaction delegates failed.
Please report a bug.
151104  9:56:09 [ERROR] Aborting

o be a known bug about which Oracle does not give much of a shit, since
they provide a magical «fix», but no solution.

https://groups.google.com/forum/?hl=en#!topic/dimstat/596RKYcVPIQ
https://groups.google.com/forum/#!topic/dimstat/GiewfGElRZk

The workaround is to use the MySQL 5.6 package in 64 mode. Edit or
create /etc/opt/csw/csw.conf after installing it, and add this line:
mysql56_arch=sparcv9

I'll make it use 64 bit as default instead of the historical 32 in a respin.
MySQL 5.5 32 bit, MySQL 5.5 64 bit, MySQL 5.6 32 bit, all have the same
issue on Solaris 11/sparc exclusively.

I will not investigate further. If somebody wants to, you're welcome to it.

Regards,

Laurent

Re: gnutls 3 round 2

[Laurent Blume]

Riccardo,

While you work in the past, your computer time is two hours in the
future, you might want to fix it:

for ; Thu,  1 Oct 2015 17:57:15 +0200 (CEST)
Date: Thu, 01 Oct 2015 19:56:34 +0200

Regards,

Laurent

Re: OpenCSW catalog update report

[Laurent Blume]

Riccardo,

I would rather like to know what the fuck you think you are doing.

You've been tinkering (ie, breaking) that package, and I had to step in
to fix your mistakes.

Now you are just taking it over, without any polite asking for it, and
AFAICT, without making a single committed change that would require a
reupload.

I'm all good to give packages to other maintainers, since I've got less
time to deal with them myself, even to those who have shown
unwillingness to make their own research.

But in your position, the *very least* you can do is *ask*.

Regards,

Laurent


Le 2015/08/04 20:26 +0200, Catalog Update Notifier a écrit:
> Catalog update report for laur...@opencsw.org
> Catalog URL: http://mirror.opencsw.org/opencsw/
> 
> You no longer maintain packages:
> - librsvg2_2-2.40.9,REV=2015.07.29-SunOS5.10-sparc-CSW.pkg.gz
>   In catalogs:
>   - unstable: sparc (5.10, 5.11)
> 
> - librsvg2_2-2.40.9,REV=2015.07.29-SunOS5.10-i386-CSW.pkg.gz
>   In catalogs:
>   - unstable: i386 (5.10, 5.11)
> 
> - librsvg_dev-2.40.9,REV=2015.07.29-SunOS5.10-i386-CSW.pkg.gz
>   In catalogs:
>   - unstable: i386 (5.10, 5.11)
> 
> - rsvg-2.40.9,REV=2015.07.29-SunOS5.10-i386-CSW.pkg.gz
>   In catalogs:
>   - unstable: i386 (5.10, 5.11)
> 
> - librsvg_dev-2.40.9,REV=2015.07.29-SunOS5.10-sparc-CSW.pkg.gz
>   In catalogs:
>   - unstable: sparc (5.10, 5.11)
> 
> - rsvg-2.40.9,REV=2015.07.29-SunOS5.10-sparc-CSW.pkg.gz
>   In catalogs:
>   - unstable: sparc (5.10, 5.11)
> 


 

Re: svg problem during cairo build

[Laurent Blume]

Le 2015/06/27 11:25 +0200, Claudio Ramirez a écrit:
> This is interesting!
> I hear a lot of people that discarded Solaris talk positively about
> FreeBSD because it already has ZFS and Linux have not. I had the
> impression the project was on a side track and that all the Linux people
> put theirs chips on brtfs. Good to be wrong, I really miss the ZFS
> experience (with the exception of the binary magic in /etc) when working
> on Linux.

«Linux people» doesn't mean much, it's not a single entity, right? But
truly, distros are pushing btrfs, because it's politically safer. And at
some point, it will probably become good enough.
ZFS on Linux works well enough, but it's still not for the faint of
heart, and you'll need to make sure you can devote the needed amount of
skill and resources to it. It's still somewhat tricky, behaves
differently on different distros, the odd bugs seep in, and AFAICT,
there's no paid support for it yet (and maybe never considering the FUD
around it).
So, good for my data at home, but I can't use it at work.

Laurent

Re: libpng15 + dev respin

[Laurent Blume]

Le 2015/05/21 09:32 +0200, Dagobert Michelsen a écrit:
> Wouldn’t it be better to have the latest CSWlibpng16-dev provide a symlink?
>   /opt/csw/lib/pkgconfig/libpng.pc -> libpng16.pc

I thought about that, but no. It really needs libpng15, specifically.
Remember it will also add -lpng15 and other versioned stuff. I don't
want to think about doing a build that uses cairo asking for png15 while
using png16 for the current source.

> The import of the unversioned pkgconfig-file seems to have happened some time 
> ago.
> Probably some configure-scripts still contain the search for libpng.pc only?

I don't think so. I checked, it's the same with CentOS 7.1. It's just
the way it's done is a mess. I don't believe many distros try to do what
we're doing, having two different versions concurrently.

Laurent

Re: libpng15 + dev respin

[Laurent Blume]

Hello,

The ball has been tackled a bit further, but that rabbit hole is deep.
That one is for Rafi.

Symptom:
In file included from coders/pango.c:71:0:
/opt/csw/include/pango-1.0/pango/pangocairo.h:26:19: fatal error: 
cairo.h: No such file or directory

 #include 

The configure script called:
$ /opt/csw/bin/pkg-config --cflags "cairo-svg"
sh: gnome-config: introuvable
Package libpng was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpng.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libpng', required by 'cairo', not found

The cause is in cairo.pc:
Requires.private:   gobject-2.0 glib-2.0  pixman-1 >= 0.16.0 
fontconfig >= 2.2.95 freetype2 >= 9.7.3   libpng xrender >= 0.6 x11 xext


It has to be modified in the cairo_dev package to match the library 
used, eg it should be «libpng15» here (so it picks up libpng15.pc).



Laurent


Le 2015/05/11 14:34 +0200, Riccardo Mottola a écrit:

Hi,

especially for Laurent: I was finally able to do a libpng-15 respin with
its dev versioned dev package.
The dev-package is really minimal but I hope it is enough? IN case
please add yourself or tell me which precise file to add, one by one,
explicitely.

I uploaded it successully, perhaps they can be already installed on the
buildfarm

I am still working on the 16 package: I get a strange error I didn't get
in the unversioned one and it makes no sense since I did not change
anything in the content of the packages when versioning. I am doing a
total clean build on all platforms and it takes a lot of time.

Riccardo

Re: Brokenness caused by libpng update

[Laurent Blume]

Le 2015/05/05 19:49 +0200, Riccardo Mottola a écrit:
> hey, I just upgraded... I didn't "break it" more than the last revision,
> it is just necessary to update a dozen of packages, as happened probably
> last time libpng's soname was upgraded.

I was not blaming you. You have to understand that when you're working
with packages that impact the work of other people, you fully assume the
responsibility of not disturbing the work of those people more than
necessary, and fix new issues that appear.

This is tangent to Peter's recent post. We get the feeling that for you,
this is a hobby, you play and learn on obsolete OS's. That's a perfectly
fine and legit reason to work with OpenCSW.
But others still have actual business needs for those packages you are
impacting with your changes. You are very welcome to make those changes,
but you do have to be careful and responsible with them.

> Then probably didn't understand your proposal, sorry. Except for actual
> status which we need to recover, supposing that 15 had already a
> versioned package, I would have just upgraded to 16, producing another
> one, but incompatible to the 16, since both would have the symlink?

No, we don't want both to have the symlink. We want the most recent one
to have the symlink, only the most recent one, so new packages that use
libpng-dev will use that libpng.pc symlink and link to whatever is the
most current one. Yes, they will get an implicit dependency on
libpngXX-dev in the process, but that's apparently the way the libpng
devs want it.
Then, packages that depend on eg libpng15-dev will still be able to use
libpng15.pc

> In other words, the current dev package is fine, except you want it to
> have a versioned name? Let's start with that easy fix.

No, it is not fine.
If you get back to my original post, you will see that my recipes are
broken because they lack the file libpng15.pc.

So you absolutely must respin now a libpng15-dev without the symlink,
that will obsolete libpng-dev, and modify the current libpng-dev so it
becomes libpng16-dev.

> Do you want then to produce the same versioned package for the old 15
> version, doing a partial revert of the Makefile? Fine too. What is it
> for, if you anyway have a symlink in the 16 version? it would overwrite
> a file.

Because the recipes currently need the libpng***15***.pc file, that is
not part of libpng***16***. The symlink is only used for the initial
build of the recipes. Since it points to a versioned file that contains
versioned content, the dependencies of those dependencies will then
later request the versioned content.
If you've not had the time yet, I suggest you have a look at
pkg-config(1) and how it is used to provide build-time informations.

> I can take care of the above steps. But you still have packages
> depending on the "old" unversioned one, right? those need to be updated
> anyway.

Yes, that is precisely why I said you have to contact the maintainers of
the dependencies of your package to make sure that they are aware of
those changes they have to make.

Welcome to dependency hell. It's part of the job :-)

Laurent

Re: Brokenness caused by libpng update

[Laurent Blume]

Le 2015/05/05 10:05 +0200, Riccardo Mottola a écrit:
> Hi,
> 
> well, you somehow convinced me that we need a versioned developer
> package. My guts still don't like it, but what you say makes a lot of
> sense.
> 
> Does it work not having the symlink at all?

Maybe. Up to you to prove it. Hey, you broke it ;-)
Personally, seeing Linux distros have it, I think it's needed.

 I that case everything is
> fine! If you can confirm that, we can think about removing the symlink.
> If things work like the libraries symlink however it is needed and it is
> better just to upgrade all packages.

> Can we somhow simplify this procedure? Seems a lot of work to me. I see
> not problems

It's what happens when you start playing with dependencies that impact
other people's work :-)
Don't worry, you're not the first, and this looks pretty easy compared
to some others.

> 
> 1) respin 1.5 versioned dev without the symlink
> 2) respin 1.6 versioned dev without the symlink
> 
> respinnin a non-versioned dev with "which" comments "where" seems a lot
> of hassle.

I don't understand what you tried to say here. FWIW, I'm in favor of the
symlink to be in the most recent version, whatever that is, not having
an additional unversioned package that contains only that link.

Laurent

Re: Brokenness caused by libpng update

[Laurent Blume]

Le 2015/04/30 23:51 +0200, Riccardo Mottola a écrit:
> but these look the same to me? except that CentOS7 is back one release.
> so why do we want to differ?
> I still think that somehow having N different developer packages is messy.
> 
> Isn't libpng.pc looked for after all? We need that symlink.


The point is having it only for libpng16.pc, so further development use
it, while keeping libpng15.pc for older packages.

Laurent

Re: GCC 5.1

[Laurent Blume]

Le 2015/04/30 11:06 +0200, Dagobert Michelsen a écrit:
> Hi folks (and especially Maciej),
> 
> I am fiddling with GCC 5.1 and get some file collisions with GCC 4. I am not 
> sure how to
> best proceed here as these are non-versioned libs and devel-stuff. I tend to 
> make them
> incompatible with the corresponding GCC 4 packages. Thoughts?

Incompatible seems good. The only other way is having a separate
/opt/csw/gcc5 dir, and that was given up a long time ago, right?

BTW, relevant read:

http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/


Laurent
 

Re: Brokenness caused by libpng update

[Laurent Blume]

Le 2015/04/30 09:46 +0200, Dagobert Michelsen a écrit:
> Ah yes, I guess I took the contents wrong. As the *-config and pkgconfig-files
> explicitly contain the version number the development package must stick to 
> it.
> So I too favor for bringing back CSWlibpng16-dev

FWIW, here's what I see on CentOS7:
-rw-r--r-- 1 root root 226 10 juin   2014 libpng15.pc
lrwxrwxrwx 1 root root  11 11 janv. 20:38 libpng.pc -> libpng15.pc

And the current CSW package:
lrwxrwxrwx   1 root  root11 avr  28 09:22 libpng.pc -> libpng16.pc
-rw-r--r--   1 root  bin236 avr  21 15:19 libpng16.pc


So here is a proposal:
  - respin 1.5 with a versioned -dev, *removing* the libpng.pc symlink,
and obsoleting the unversioned -dev (since other current -dev
dependencies will need that version)
  - reversion it to 1.6, this time commenting out the symlink removal,
and of course removing the obsoleting (since future dependencies will
need to use a versioned -dev)
  - add a lot of comments in the recipe explaining how to do it for
future version changes (one last respin of the current version without
the symlink, then new version with it, the obsoleting is a one-time
thing, won't be needed further)
  - check that it all works
  - warn the maintainers of all packages that have a dependency on
libpng that they will need to upgrade their BUILD_DEP.


I'm not the one doing it, so up to you :-)

Laurent


Laurent
  -

Re: set ISA depend path in GAR recipe

[Laurent Blume]

Le 2015/04/29 22:17 +0200, Matchek a écrit:
> On Wed, Apr 29, 2015 at 09:25:11AM +0200, Carsten Grzemba wrote:
>> I set
>>
>> CONFIGURE_ARGS += --with-httpd=/opt/csw/sbin/$(ISA_DEFAULT)/httpd
> 
> Can you tell a bit more about the problem you're solving? I know you're
> working on the 64-bit Apache.
> 
> Can you use isaexec?

I'm not in favor of using isaexec indiscriminately for server apps. This
is IMO a choice that should be made explicitly by the admin, because
it's not neutral.

I'm speaking from the MySQL viewpoint, where an automatic choice 32/64
bit choice by the OS can effectively break a DB (it's the one area where
the database are not guaranteed to be binary-compatible).
I can see it easily being needed on Apache too, since not all modules
are going to be equally available.

> If you can't or don't use isaexec, why do you want to create directories
> compliant with isaexec?

Because it satisfies the principle of least astonishment in the
organization of binaries :-)

> Can you define your own names for httpd, like /opt/csw/sbin/httpd-32 and
> /opt/csw/bin/httpd-64?

I think the issue is that the HTTPD_ROOT would still be the same for
both, and that's the basis on which the default httpd.conf picks up the
modules/*.so files (which would have to be 32 or 64).

Would there be an environment value that could be used in the httpd.conf
to make an if clause that would load either of 2 blocks, one for 32, one
for 64, or maybe reset the HTTPD_ROOT, like what they do eg for varied
httpd engines?

Laurent

Re: Brokenness caused by libpng update

[Laurent Blume]

Le 2015/04/28 23:03 +0200, Riccardo Mottola a écrit:
> Hi,
> 
> On 04/28/15 21:26, Laurent Blume wrote:
>> The website should tell you which packages depend on linpng, check their
>> .pc files for inclusion of libpng15 as a dependency there.
> 
> it is actually CSWlibpng15-15 (for 1.5.13) thus I copied and created
> CSWlibpng16-16

Sorry, I was talking specifically about the libpng15.pc file, that
others' .pc files depend on.

> why the -15 actually? CSWlibpng15 would have been enough?

Because they versioned both the library name and its soname, and mgar
concatenates them automatically.

> it justconfused me since the release 1.6.16, once 1.6.17 comes out, this
> fallout won't happen I hope: it remains CSWlibpng16-16, doesn't it?

Should be fine. Probably.

Actually, maybe the error here was to have libpng-dev not be
libpng15-dev. Maybe that could have worked.

Laurent

Re: Brokenness caused by libpng update

[Laurent Blume]

Le 2015/04/28 21:19 +0200, Riccardo Mottola a écrit:
> sorry if I did something wrong. I tried my best upgrading libpng and
> asked for confirmation in the receipe changes.

Nothing wrong, it's just the fun of handling dependencies. I've dealt
with such things in the past too.

> what are these .pc files? perhaps package-config? Are they part of libpng?

USed by pkg-config(1).

> Should I change something in libpng? I have seen that a new, minor 1.6
> release is out so I planned an update anyway, although it is minor and
> not a security concern like this update was.

No, you only need to deal with organizing the rebuild of deps impacted
by it.

> but is this a problem with the reverse dependencies on libpng? Is this
> just a matter of rebuilding them?

Yep.

> Sure, how do I do it best, how do I have a list of those issues?
> libpng-dev has  just once reverse dependency, however

The website should tell you which packages depend on linpng, check their
.pc files for inclusion of libpng15 as a dependency there.

> http://www.opencsw.org/packages/CSWlibpng15-15/
> 
> shows 49 reverese dependencies, many of them don't appear to have a
> maintainer/uploader.

List them and check if they have -config scripts or .pc files that could
need a rebuild with 1.6.

Laurent

 

Brokenness caused by libpng update

[Laurent Blume]

Hello,

The recent libpng update to 1.6 has broken building every package
indirectly depending on it: the .pc files referenced the 1.5 version,
which has now disappeared.

I already can't rebuild ImageMagick, because librsvg's .pc complains. I
can't rebuilt librsvg, because gdk_pixbuf's .pc complains.

Note that because of the way those .pc are used in the configure
scripts, the errors happen during building, and look unrelated, eg:

rsvg.h:31:25: fatal error: glib-object.h: No such file or directory

Even though the glib-object.h is present.

That's because the CFLAGS are improperly set, due to configure not
catching the error while setting them:

$ /opt/csw/bin/pkg-config --cflags gdk-pixbuf-2.0
sh: gnome-config: introuvable
Package libpng15 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpng15.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libpng15', required by 'GdkPixbuf', not found

Riccardo, since you upgraded, can you please list those issues and
contact each maintainer, in order to fix the dependencies in the right
order?

Thanks,

Laurent

Re: OpenSSL 1.0.1m considered harmful on Sparc

[Laurent Blume]

Done, same place:

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

The Solaris 9 GCC target doesn't appear too well maintained either. 
Unsurprisingly.


Laurent

Re: OpenSSL 1.0.1m considered harmful on Sparc

[Laurent Blume]

Le 2015/04/22 09:30 +0200, Dagobert Michelsen a écrit:
> I installed it on „web“ and BIND now works. Looks good to me. Would you mind 
> respinning the rest?


Sure.
Do note that I replaced the sparcv8plus+vis target by simple
sparcv8plus. The former implies adding a patch unsupported by upstream,
potentially adding issues we obviously don't have resources to deal
with. I'll stick with vanilla OpenSSL.

Laurent

Re: OpenSSL 1.0.1m considered harmful on Sparc

[Laurent Blume]

Don't feel alone:

https://mta.openssl.org/pipermail/openssl-users/2015-April/001080.html

Though I don't see a relationship.

Dagobert: I put together a build of the package using GCC, if you want 
to give it a try.


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

Laurent

Le 2015/04/20 22:24 +0200, Yann Rouillard a écrit:

No special precaution I think.
You can speed the rebuild by using mgar platforms-fast or mgar
package-fast but that is not required.

Yann

2015-04-20 22:11 GMT+02:00 Dagobert Michelsen mailto:d...@opencsw.org>>:

Hi Yann,


Am 20.04.2015 um 22:09 schrieb Yann Rouillard
mailto:y...@pleiades.fr.eu.org>>:

Hi everybody,

I still don't have enough time work on it but my advice would be
to first try to recompile the openssl sparc package with all
upstream Oracle patches disabled to ensure that check if it is an
openssl upstream problem or not.

Patches to disabled are: openssl-1.0.1m-fork_safe.patch,
openssl-1.0.1m-pkcs11-engine.patch, openssl-1.0.1m-wanboot.patch,
openssl-1.0.1m-t4-engine.sparc.5.11.patch,
openssl-1.0.1e-t4-engine-sparcv9+vis.sparc.5.11.patch.

I will try to answer questions from whoever can work on this.


I just had a discussion with Laurent about the rebuild: are there
any special precautions to be
taken or can it just be built by „mgar spotless && mgar platforms“?


Best regards

   — Dago



Yann


2015-04-20 15:22 GMT+02:00 Dagobert Michelsen mailto:d...@opencsw.org>>:

Hi folks,

I want to raise the issue about OpenSSL 1.0.1m again. On Sparc
we have now
two serious issues:

- BIND fails with crypto failure
https://www.opencsw.org/mantis/view.php?id=5237
- Solaris 9 applications have issues with hangs in unrelated
code. This has been seen
  at least in GIT and Python

How do we proceed here? While I do notice that it would be
good to provide a working 1.0.1m
the status quo is that bad that I would suggest rolling back
to 1.0.1l at least on Sparc
if the issue can not be resolved in a reasonable timeframe.


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




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

Re: Mantis Problems

[Laurent Blume]

Le 2015/03/24 10:12 +0100, Juraj Lutter a écrit:
> From MySQL perspective, even a "minor" numeric version upgrade can
> impose MAJOR functional and/or API changes.

Let me tell you that again in bold letters:

the SONAME version number has not changed and is MEANT TO BE BINARY
COMPATIBLE.

If you have actual concerns, please substantiate them with actual
evidence rather than assertions.
I have no time to try to prove negatives to you.

Thank you.


Laurent





 

Re: Mantis Problems

[Laurent Blume]

Le 2015/03/23 22:32 +0100, Juraj Lutter a écrit:
> On 03/23/2015 09:04 PM, Laurent Blume wrote:
>> PHP being famous for breakage between very minor releases, they assume
>> everybody else is the same.
> 
> MySQL 5.5 vs. 5.6 is quite "major" update.

It's LIBmysql. So no, it's not a major update. That's is why the library
version number has not changed.
The server and the libs are very distinct.

Laurent

Re: Mantis Problems

[Laurent Blume]

Le 2015/03/23 13:47 +0100, Jan Holzhueter a écrit:
> for the time beeing going back to a CSWlibmysqlclient18 that was build
> with 5.5 should work also.

Do note that this is a PHP issue. The MySQL libs are explicitly
compatible, there is no reason for it to complain.
There must be a way to remove that warning.

PHP being famous for breakage between very minor releases, they assume
everybody else is the same.

Laurent

Re: libicu on solaris 9s

[Laurent Blume]

Le 2015/03/22 20:34 +0100, Riccardo Mottola a écrit:




Why would this happen (and why on solaris 9 and not 10)?


Because this lib is installed on S10, and not on S9, so you're actually 
testing the already installed library, and not the one you just built.

You could check that by running ldd on your new binaries.


perhaps some -L -R magic that is missing or anyway different in solaris 10?


No, it all works as expected, except it's not what you want.
Good test scripts know how to handle that by setting LD_LIBRARY_PATH. 
This one obviously doesn't.


So it's a pointless test. Disable it.

Laurent

Re: gcc receipe and architecture comment

[Laurent Blume]

Le 2015/03/18 21:39 +0100, Matchek a écrit:
> I think we were still building for Solaris 8 until shortly before that
> (measured in years). We stopped supporting Solaris 8 in March 2010. A
> year and a half. An eye blink.

But since S8 did not, ever, support the 386, it truly made zero sense,
even in 2010. Even in 2000, it made no sense. The last Solaris to
support the 386 was 2.5.1 (and it was not exactly a recommended CPU...)
Solaris truly attracts hardcore traditionalists :-D


http://docs.oracle.com/cd/E19620-01/805-4853/6j4jev6qc/index.html
http://docs.oracle.com/cd/E19504-01/802-5739/6i9fpme6d/index.html
http://docs.oracle.com/cd/E19504-01/802-5739/6i9fpme6c/index.html
http://docs.oracle.com/cd/E19695-01/802-1960/802-1960.pdf
http://docs.oracle.com/cd/E19457-01/801-6617/801-6617.pdf

Re: gcc receipe and architecture comment

[Laurent Blume]

Le 2015/03/18 20:48 +0100, Matchek a écrit:
> 2015-03-18 19:19 GMT+00:00 Laurent Blume :
>> Seriously?! When was that?!
> 
> Found it, October 2011: https://sourceforge.net/p/gar/code/15950/
> 


Makes no sense. S8 did not support the 386. S7, I'm not even sure. Why
settle for such a low target?

Laurent

Re: missing libffi.so master link

[Laurent Blume]

Le 2015/03/18 20:19 +0100, Riccardo Mottola a écrit:
> The real problem is that I don't know how to keep a separate, older
> version for solaris 9 in mgar. Some kind of branch? a new Package? Since
> "current" is 4.9 right now. This is a problem that sooner or later needs
> to be done anyway. Older systems will eventually diverge before you give
> them up.

Then don't bother with Solaris 9.

> The same problem is why I did not start working on the "solaris 8
> respin" (apart form the general lack of  time and immense effort that
> getting the first gnustep package working is)

Honestly, considering your energy, I think it's a waste to use it all on
S9. Why don't you pick more worthy targets on more current systems?

Laurent

Re: gcc receipe and architecture comment

[Laurent Blume]

Le 2015/03/18 10:29 +0100, Matchek a écrit:
> We had a similar rule to build for 386, where 386 didn't stand for just
> Intel processors, it actually meant the 386 processor, as opposed to the
> newer 486.


Seriously?! When was that?!

Re: missing libffi.so master link

[Laurent Blume]

Le 2015/03/17 01:25 +0100, Matchek a écrit:
> Quick check, CSWgcc3javart only exists in the Solaris 9 unstable catalog.
> 
> curl -s https://mirror.opencsw.org/opencsw/unstable/sparc/5.9/catalog |
> grep CSWgcc3javart
> 
> We could drop CSWgcc3java from the unstable Solaris 9 catalog.


Agreed. AFAIR, it was not a very useful Java implementation.

Laurent

Re: libffi unwind test fails

[Laurent Blume]

Look closer at the lines you've just quoted:
 if $CC -Wa,--fatal-warnings $CFLAGS -c conftest1.s > /dev/null 
2>&1 && \

   $CC conftest2.c conftest1.o > /dev/null 2>&1 ; then

See the $CFLAGS for the first GCC call? It's missing for the second.

So you get that actually executed:
+ gcc -Wa,--fatal-warnings -m64 -Wall -fexceptions -c conftest1.s
+ gcc conftest2.c conftest1.o

The first succeeds, creates a 64 bit object. The second fails, because 
it tries to link a 64 bit object in 32 bit mode (the default).


Add a $CFLAGS, it'll work better. Report upstream too.

Laurent

On 13/03/2015 17:16, Riccardo Mottola wrote:

Hi,

the other thread reached a too deep reply level and got a bit out of
topic :) The summary is: the toolchain supports unwind section type
returns no even if it should return yes. This makes solaris-x86-64 fail.
The test is executed only if target is X86_64, this is why we weren't
seeing the test in the 32bit build.

The full test check in configure.ac is:
if test x$TARGET = xX86_64; then
 AC_CACHE_CHECK([toolchain supports unwind section type],
 libffi_cv_as_x86_64_unwind_section_type, [
 cat  > conftest1.s << EOF
.text
.globl foo
foo:
jmp bar
.section .eh_frame,"a",@unwind
bar:
EOF

 cat > conftest2.c  << EOF
extern void foo();
int main(){foo();}
EOF

 libffi_cv_as_x86_64_unwind_section_type=no
 # we ensure that we can compile _and_ link an assembly file
containing an @unwind section
 # since the compiler can support it and not the linker (ie old
binutils)
 if $CC -Wa,--fatal-warnings $CFLAGS -c conftest1.s > /dev/null
2>&1 && \
$CC conftest2.c conftest1.o > /dev/null 2>&1 ; then
 libffi_cv_as_x86_64_unwind_section_type=yes
 fi
 ])
 if test "x$libffi_cv_as_x86_64_unwind_section_type" = xyes; then
 AC_DEFINE(HAVE_AS_X86_64_UNWIND_SECTION_TYPE, 1,
   [Define if your assembler supports unwind section
type.])
 fi
fi

it links with $CC a small piece with assembler and tries to see if there
are warnings.

I created the two files manually, I tried:
gcc -Wa,--fatal-warnings -m64 -c conftest1.s

and got no error. (without -m64, I would get an unrecognized section type)

then I do:
cc -m64 conftest2.c conftest1.o


and get no errors, so the test should pass.

What's wrong?

Riccardo

Re: linker eh_frame unwind [was: missing libffi.so master link]

[Laurent Blume]

Le 2015/03/13 10:22 +0100, Riccardo Mottola a écrit:
> Why does it fail? the check should return "yes", 

Well, what is the test?

Re: missing libffi.so master link

[Laurent Blume]

Le 2015/03/08 21:00 +0100, Riccardo Mottola a écrit:

This on unstable10x:
libtool: link: /opt/csw/bin/gcc-4.9 -shared  -fPIC -DPIC -Wl,-z -Wl,text
-Wl,-h -Wl,libffi.so.6 -o .libs/libffi.so.6.0.4 src/.libs/prep_cif.o
src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o
src/.libs/closures.o src/x86/.libs/ffi64.o src/x86/.libs/unix64.o
src/x86/.libs/ffi.o src/x86/.libs/sysv.o -L/opt/csw/lib/64  -O2 -m64
-march=opteron -m64 -march=opteron -m64 -march=opteron
ld: fatal: file src/x86/.libs/unix64.o: section [5].eh_frame: section
type is SHT_PROGBITS: expected SHT_AMD64_UNWIND
collect2: error: ld returned 1 exit status
Makefile:1165: recipe for target 'libffi.la' failed


Some search seems to hint it's a GNU assembler / Solaris ld issue. There 
might be some optimization selected by ./configure that's not good.

http://gcc.1065356.n5.nabble.com/Building-GCC-4-7-2-on-Solaris-10-x86-AMD64-Getting-linker-error-involving-eh-frame-td893484.html

I see that option in configure that's probably worth enabling:

--enable-portable-binary

Check the config.log carefully.


that is,  have trouble only on intel.. of which I don't know much. Help!


Solaris 9 x86 is 32 bit only. My generic advice about it is: drop it.

Laurent

Re: missing libffi.so master link

[Laurent Blume]

Le 2015/03/08 14:59 +0100, Dagobert Michelsen a écrit:
>   BUILD64 = 1

Only this one is enough IMO.

Laurent

Re: missing libffi.so master link

[Laurent Blume]

Le 2015/03/08 12:14 +0100, Dagobert Michelsen a écrit:
> I vaguely remember that there were two libffi, one with gcc and another one 
> as a separate
> project. Is this still the case? I also vaguely remember that the issue was 
> resolved,
> but can’t find a reference right now.

I've not looked much into it, Just noticed that the .so of that libffi
is in a different subdir. I see no .so for the GCC one, nor dependency
on it, so it looks basically useless. I have no idea what either lib
does, nor why they've got the same name, and 30 seconds of duckduckgoing
did not turn up much.

Riccardo:
you missed the 64 bit lib in your updated package, it has only 32 bit
libs. You'd better fix it quickly, as it will break building some deps.

Laurent


 

Re: missing libffi.so master link

[Laurent Blume]

Le 2015/03/08 10:35 +0100, Riccardo Mottola a écrit:
> Hi,
> 
> now we have a shiny new libffi package on all 4 platform (9/10
> x86/sparc) combinations!
> 
> However, I cannot build gnustep-base:
> 
> ld: fatal: library -lffi: not found

1 s none /opt/csw/lib/ffi<<<

Re: libffi on solaris 9

[Laurent Blume]

Le 2015/03/07 11:39 +0100, Matchek a écrit:
> Or $PATH? We don't add /opt/csw/bin to PATH system-wide.
> 

Yes, it's done by Baltic Online stuff in /etc/environment, which is not
installed on unstable9x.

Definitely a request for buildfarm@.

Laurent

Re: problem building libffi on x86-10 (fatal link error)

[Laurent Blume]

Le 2015/03/05 17:57 +0100, Riccardo Mottola a écrit:
> I upgraded to latest libffi, which incorporated also certain patches (I
> checked), disabled those that do not apply anymore too. Switched to GCC.
> It would make 6.0.5 instead of 5.0.10

Not a problem.

> I got everything to compile and it appears to work for my configure test!
> 
> I wanted to run the tests (mgar test ?) and re-enabled them.
> TEST_TARGET = check
> 
> however when I run mgar test I get:
> WARNING: could not find 'runtest'

Not mgar test? mgar check?

> so  suppose they did nothing.
> 
> The recipe contains some stuff I do not understand fully that I think
> needs to be updated:
> 
> OBSOLETED_BY_CSWlibffi5 = CSWlibffi
> OBSOLETED_BY_CSWlibffi5-dev = CSWlibffi
> INCOMPATIBLE_PKGS_CSWlibffi5 = CSWlibffi

You'll have to replace the 5 by 6.

> These just mean that unversioned packaged are obsoleted? These need to
> be updated to CSWlibffi6 I suppose

No, it was for transition from the old, pre-standard naming. Packages
won't need to be updated (except that to avoid a broken lib, that is).

> PACKAGES += CSWlibffi5
> PKGFILES_CSWlibffi5 += $(call baseisadirs,$(libdir),libffi\.so\.5(\.\d+)*)
> SPKG_DESC_CSWlibffi5 += $(DESCRIPTION), libffi.so.5
> 
> what do the last two lines do? I just substituted blindly 5 with 6
> what is SPKG_*?

Actually, mgar will surely tell you what to copy-paste.

> then we have:
> PACKAGES += CSWlibffi-dev
> SPKG_DESC_CSWlibffi-dev = $(DESCRIPTION) - developer package
> RUNTIME_DEP_PKGS_CSWlibffi-dev += CSWlibffi6
> 
> why does it have CSWlibffi-dev and not CSWlibffi6-dev ?

Because there is only one -dev at a time, pointing to the latest version
that is used for all new linking, while there can be several numbered
versions of the libs used by previously linked packages.

> Should I commit the receipe as is? I can also post the diff to the list,
> as you prefer.

Run "mgar package" first so it will warn you for missing deps and other
issues.

Laurent

Re: libffi dependencies problem

[Laurent Blume]

Le 2015/03/05 21:04 +0100, Riccardo Mottola a écrit:
> Hi,
> 
> in my updated, uncommited libffi package, I added:
> RUNTIME_DEP_PKGS_CSWlibffi6 += CSWlibgcc-s1
> because when compiled with gcc, the libffi is linked against this.
> 
> However, mgar tells me:
> 
> CHECKPKG_OVERRIDES_CSWlibffi-dev += missing-dependency|CSWlibgcc-s1

A -dev packages should contain only headers, some scripts and symlinks,
so if it tells you it depends on a lib, it means it improperly contains
binaries. Check why. Look at the mgar output, usually it gives the right
syntax for the -dev.
Maybe theres another package that you should create to contain binaries.


> CHECKPKG_OVERRIDES_CSWlibffi6 += surplus-dependency|CSWlibgcc-s1
> 
> but it makes no sense to add a linked library to "-dev", doesn't it?
> 
> Riccardo
> 


 

Re: problem building libffi on x86-10 (fatal link error)

[Laurent Blume]

Le 2015/03/05 12:11 +0100, Riccardo Mottola a écrit:
> Hi,
> 
> as Laurent suggested, I wanted to try to build libffi 5 with dfferent
> compilers.
> 
> The first thing I did is build the package "as is" on unstable10x
> 
> mgar fetch makesum configure build
> 
> <...>
> libtool: link: /opt/SUNWspro/bin/cc -G -h libffi.so.5 -o
> .libs/libffi.so.5.0.10  src/.libs/debug.o src/.libs/prep_cif.o
> src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o
> src/.libs/closures.o src/x86/.libs/ffi64.o src/x86/.libs/unix64.o
> src/x86/.libs/ffi.o src/x86/.libs/sysv.o   -L/opt/csw/lib/64 -lc -m64
> -xarch=sse2 -m64 -xarch=sse2
> ld: fatal: file src/x86/.libs/unix64.o: section [4].eh_frame: section
> type is SHT_PROGBITS: expected SHT_AMD64_UNWIND
> Makefile:790: recipe for target 'libffi.la' failed
> 
> May I assume that the standard recipe is broken? What could that be? I
> suppose the package at least used to build
> The build is happening with the Sun compiler, as expected.

Some recipes have been worked on, but never finalized, particularly
those of Dago and Maciej, who are overloaded, and this one is old, mgar
has much evolved.
Don't hesitate to start by removing stuff, like I said, get the latest
libffi version, remove the patches, use a recent compiler, check if it
builds.

> This comment in the Makefile is not reassuring:
> # Fix needed for amd64 using SOS compiler
> # found at http://software.intel.com/en-us/forums/showthread.php?t=56652
> # originally for icc, but at least get the stuff to compile
> 
> we are on amd64, aren't we?

Use GCC4, forget SOS.

> further question: the library is said to be "ELF 32-bit LSB dynamic lib
> 80386 Version 1 [FPU]'
> which I think is fie but I think is not amd64.
> In the makefile I find:
> BUILD64_LIBS_ONLY = 1

Remove that line. It's only a way to save a few bytes by including only
the libraries in a 64 bit build, but it's usually a little pointless IMO.

Laurent

Re: gnustep-base configure failure on x86

[Laurent Blume]

Le 2015/03/04 00:08 +0100, Matchek a écrit:
> 2015-03-03 22:55 GMT+00:00 Maciej (Matchek) Bliziński :
>> Possibly this:
>> https://buildfarm.opencsw.org/source/xref/opencsw/csw/mgar/pkg/gcc4/trunk/files/0002-default-rpath.diff
> 
> I found it:
> http://lists.opencsw.org/pipermail/maintainers/2011-December/015763.html
> 

Before I got on that list, then.
I note that the discussion says nothing of the implied -I.

I can't say I'm happy about the idea. However, since it happened at the
time I mostly stopped building with OpenCSW's GCC outside of mgar, and
not seen breakage directly caused by that, I guess that'll stay.

Laurent
 

Re: gnustep-base configure failure on x86

[Laurent Blume]

Le 2015/03/04 00:19 +0100, Riccardo Mottola a écrit:
> So I should try to build locally a package and then point to it? Ok

Basically, you tinker with libffi5 until it works for your binary, then
when it does, you update its package.
It's not been updated in a while, I'm sure Maciej won't mind if you take
it over.
You can upgrade it to a newer version, and start by commenting out all
the patches, to check if they're still needed.

> But how can I select different compilers?

GARCOMPILER=GCC4

> I see also the receipe forces 64biit, is that correct?
> 
> $file a.out
> a.out:  ELF 32-bit LSB executable 80386 Version 1, dynamically
> linked, not stripped, no debugging information available
> 
> while the two libffi's appare slighlty different:
> 
> /opt/csw/lib/libffi.so.4:   ELF 32-bit LSB dynamic lib 80386 Version
> 1, dynamically linked, not stripped
> /opt/csw/lib/libffi.so.5:   ELF 32-bit LSB dynamic lib 80386 Version
> 1 [FPU], dynamically linked, not stripped
> 
> also:
> dd /opt/csw/lib/libffi.so.4
> libgcc_s.so.1 => /opt/csw/lib/i386/libgcc_s.so.1
> libc.so.1 => /lib/libc.so.1
> libm.so.2 => /lib/libm.so.2
> 
> ldd /opt/csw/lib/libffi.so.5
> libc.so.1 => /lib/libc.so.1
> libm.so.2 => /lib/libm.so.2

Nothing to worry about.

Laurent

Re: gnustep-base configure failure on x86

[Laurent Blume]

Le 2015/03/03 21:05 +0100, Riccardo Mottola a écrit:
> really, I'm not trying to hide anything!
> I just logged in.
> I'm not trying tricks, here a transcript, I just redid everything.

Apologies, I'm truly stumped. WTF is going on with GCC being a smartass
and now having default -R/-I parameters?
Ie, how can that line produce a working binary:

gcc config.ffi.c -lffi -L/opt/csw/lib/ffi

When cc needs that:

cc config.ffi.c -L/opt/csw/lib/ffi -R/opt/csw/lib/ffi -lffi
-I/opt/csw/include

When did GCC acquire that feature??


On the problem, it's definitely libffi.so.5 hich is broken. Building
with .4, it works:

$ gcc config.ffi.c /opt/csw/lib/libffi.so.4
$ ./a.out
$ echo $?
0

Considering the libffi recipe is still using the default obsolete
compiler, I can only advise to give it a try with SOS12U4, then with Gcc4.

You have a fair use of LD_LIBRARY_PATH there: point it to your newly
built lib so a.out picks it up (check with ldd) and you can try it
quickly without having to install it.

Laurent

Re: gnustep-base configure failure on x86

[Laurent Blume]

Le 2015/03/02 22:16 +0100, Riccardo Mottola a écrit:

> Usually there is a link to the latest version. Can the v4 be uninstalled
> from unstable10x? But I am just poking around.

> 
> gcc config.ffi.c -L/opt/csw/lib/ffi -lffi

You can gather it from here. Since it did not fail the linking, it means
it found the .so in the -L directory.

$ ls -l /opt/csw/lib/ffi
total 1
lrwxrwxrwx  1 root  root  19 Aug 23  2012 libffi.so -> ../libffi.so.5.0.10


> ./a.out
> Segmentation Fault (core dumped)

That, however, is odd. What it should be saying is that it's not finding
the library, since you've not put -R above. That means you have tinkered
with LD_LIBRARY_PATH or some such, and you are not telling us.

Could you please copy-paste EVERYTHING you've done, instead of trying to
hide stuff?
What is the output of "ldd a.out"? And also, please post the content of
config.ffi.c.

> could it be that we have both libffi 4 and 5 ?

No. That has nothing to do with it.

Laurent

Re: csw-upload-package platform problem

[Laurent Blume]

Le 2015/02/11 18:12 +0100, Riccardo Mottola a écrit:
> what does "leaving in experimental" mean? I need the package to be
> availale, so that Dago can install it and then I can continue building
> the next 2 gnustep  core packages an then finally the applications and
> get a working chain.

You put it in /home/experimental/gnustep, that will make it available on
http://buildfarm.opencsw.org/experimental.html

> I might never reach "package parity" since I have no clue on why that
> crash happens, I will ask help here on the list but I suspect something
> intricate.

That's the risk of getting involved with unfashionable software. Not the
best place to learn. Do get in touch with upstream and check if they
have an interest in getting it to work on Solaris, too, else, you'll
feel lonely quickly.

Good luck,

Laurent

Re: csw-upload-package platform problem

[Laurent Blume]

Le 2015/02/11 17:46 +0100, Riccardo Mottola a écrit:
> I try to upload with csw-upload-package but get:
> 
> There is a problem with the presented file list.
> * CheckpkgTag(None, 'i386-SunOS5.10-missing', 'gnustep_base')
> 
> Suggestions?

Don't upload it. Leave it on experimental until you get package parity.

Laurent

Stopping maintenance of vim on S9

[Laurent Blume]

Hello all,

Just a heads up: at patch level 7.4.622, the vim recipe on S9 does not
work anymore. I've looked at the error, scratched my head, and for two
seconds, even considered connecting to one of the S9 to have a look.
Then common sense prevailed, and I just removed it from the build.

The one still in the repo will have to do for those poor souls that have
been sent to that particular circle of Hell.

Laurent

Re: Yann missing in action?

[Laurent Blume]

Good to hear, I had a feeling Dago was going to ask me to go
investigate, and it's just too cold, I'd rather stay at home with hot
chocolate.

Laurent

Le 2015/02/08 22:06 +0100, Yann Rouillard a écrit:
> Hi everybody,
> 
> Hey, don't bury me yet ! I am still alive !

Re: Documentation: 4 places and their use

[Laurent Blume]

Le 2015/02/05 10:43 +0100, Matchek a écrit:
> Ah, the discussion about words versus their meaning!

Let's not get too deep into Google's hubris at this point :-P

> An easy way to be
> literal is to surround your search terms in quotes, and if you don't
> care about the order, you can quote each search individually, "like"
> "that".

I know that, I was pissed when that replaced the + that was easier.

But sadly, it's just not true anymore. Recently, I noticed that when
searching one of my "" enclosed words in a page result, they're simply
not present. And whatever you do, non alphanumeric characters are always
replaced by spaces and thus ignored.

Conversely, putting a - in front of a word does not guarantee anymore
that it won't appear, apparently.

It's okay, gives me motivation to try out others. And Google's still
good overall, only frustrating in non-consumer-friendly cases.

> With GAR variable reference the problem is that even if you enter "gar
> variable reference" in quotes, the buildfarm host does not appear in
> the results.


I bet that just put some Doubleclick ads on it and it will get higher,
quickly

Laurent

Re: Documentation: 4 places and their use

[Laurent Blume]

Le 2015/02/05 01:39 +0100, Matchek a écrit:
> It's not certain. Our buildfarm host is a low ranking one, and it
> might never bubble up to the first page: http://xkcd.com/1334/

Happens to me more and more often. Google keeps on ignoring the words I
type to replace them with its own terms it feels I should look for
instead, even though it's definitely not what I want.

Laurent



 

SF commit emails not arriving

[Laurent Blume]

Apparently, my own commits don't get an email, though I'm receiving 
those of a few others.


What gives?

Laurent

Re: road block updating sdlimage

[Laurent Blume]

Hello,

Just replacing the compiler with GCC4, it builds. Since there's no C++ 
involved AFAICT, I advise you to just do that. It can only be faster in 
any case than using an obsolete, unsupported compiler.


I'm committing that small change so you can fully test.

Laurent

Le 2014/12/11 00:15 +0100, Jake Goerzen a écrit:

Hello,

   I can successfully build updated sdlimage packages on unstable10x but
I'm having trouble building them on unstable10s.  The problem is
undefined symbol during linking on sparc.   The missing symbols are
provided by it's self and seem to be included (.libs/IMG_webp.o). Would
someone take the current recipe for a spin and see if can find what is
wrong?

Here's a snip of where the compile stops on sparc:


libtool: link: /opt/SUNWspro/bin/cc -G -z defs -h libSDL_image-1.2.so.0
-o .libs/libSDL_image-1.2.so.0.8.4 .libs/IMG.o .libs/IMG_bmp.o
.libs/IMG_gif.o .libs/IMG_jpg.o .libs/IMG_lbm.o .libs/IMG_pcx.o
.libs/IMG_png.o .libs/IMG_pnm.o .libs/IMG_tga.o .libs/IMG_tif.o
.libs/IMG_xcf.o .libs/IMG_xpm.o .libs/IMG_xv.o .libs/IMG_webp.o
-R/opt/csw/lib -L/opt/csw/lib -lSDL -lpthread -lposix4 -lc  -m32
-xarch=sparc -m32 -xarch=sparc
Undefined   first referenced
  symbol in file
WebPInitDecBufferInternal   .libs/IMG_webp.o
WebPGetFeaturesInternal .libs/IMG_webp.o
WebPInitDecoderConfigInternal   .libs/IMG_webp.o
WebPIDecGetYUVA .libs/IMG_webp.o
ld: fatal: symbol referencing errors. No output written to
.libs/libSDL_image-1.2.so.0.8.4


Best regards,
Jake

Re: Some packages are missing bundle information, we need to fix it

[Laurent Blume]

Le 2014/12/04 20:42 +0100, Matchek a écrit:

2014-12-04 19:36 GMT+00:00 Maciej (Matchek) Bliziński :

Affected packages:
- flac (multiple packages)
- libmysqlclient18


I have an idea why this might be:

A change in the bundle name for a preexisting package. For example,
moving a package from bundle "flac" to bundle "libflac".

Probable fix: revert to the old name of bundle, upload.


Sorry, but I'll ask the naive question: what's a bundle field and how to 
add it?


Laurent

Re: IT's time to remove the Solaris 8 packages

[Laurent Blume]

Le 2014/12/04 20:02 +0100, İhsan doğan a écrit:

I see your point, but if there is no newer version of a
particular package and if there are no security or functional
issues, I don't see any reason to remove the package.


Fair enough, but really, how many packages are going to be left there 
once all those with CVE's and their dependencies are removed?

I'm not volunteering to sort them one by one myself, who is?

Laurent

Re: IT's time to remove the Solaris 8 packages

[Laurent Blume]

Le 2014/12/04 19:38 +0100, Riccardo Mottola a écrit:

Hi,

I'm usually against removing something.. the usage of those packages is
at the user's risk.
If you think e.g. NetBSD, you can go and download every version up to
1.x, everything which is not supported anymore is moved into an
"archive", often not mirrored.

Solaris 8 machines might be used more by by hobbyists or some special
apps where there is still old hardware running.


My point exactly. If they are hobbyists, they have time to help. If they 
run special software, they have resources to help.


I've yet to see somebody coming out as either.


Now I understand that if people run it in production it is generally a
bad thing. So given that, perhaps "archiving" them is not enough?

I said that my intention is to do a re-spin of some core packages:
compiler, bash and of course openssl/openssh. But I still have my
troubles getting packages build on solaris 9/10 first.
It shows though that I am not the only one :) But I am not crazy to run
externally exposed services. Actually, right now I even removed ssh
access to it, since it surely has a bugy ssl!


ssh does not use ssl.

Laurent

Re: IT's time to remove the Solaris 8 packages

[Laurent Blume]

Le 2014/12/04 15:16 +0100, Dagobert Michelsen a écrit:

Hi folks,

@Laurent: Please don’t post to maintainers@ and users@ at the same time as it 
leads to
bounces when people reply to all from users@


I should have set the reply-to, right.


While I do understand your motivation I personally think it is wrong to remove 
stuff,
regardless of how old it is. I cursed the times when I looked up old stuff like 
firmware
and it was gone. What has proposed earlier (by Maciej IIRC) was renaming old 
stuff to
/UNSUPPORTED-USE-ONLY-IF-YOU-ARE-UNPROFESSIONAL/ or similar which I think is ok.


I'll be direct: no, it is not ok. I truly thought the same some time 
ago. Since then, I've seen and interacted with many of those requests.


The point is, those people, they /don't give a fuck/. They will not tell 
their customers the risks, nor make an honest assessment of the situation.


I really do not want OpenCSW to be assisting people who are essentially 
scammers, helping them to deceive those who give them money.


You don't understand that attitude, because you're honest, and doing 
your best for your customers. But it's definitely not the case for those 
companies. They're doing the LEAST effort possible, and cashing in on it.
It's not comparable to firmware. A bad OpenBoot cannot be exploited 
remotely to get access to your systems, unlike plenty of those packages 
we're distributing. I understand your past experience, but don't let it 
influence you: your motivations were not the same, at all.


But by all means, again, put a message instead of the catalogs that they 
are welcome to assist in maintaining them. So they will contact us when 
they need. That's what we need, that's what they need, everybody will be 
happy.


Laurent

IT's time to remove the Solaris 8 packages

[Laurent Blume]

People,

There's another guy on IRC coming to ask for S8 binaries. I think it is 
more than time to remove them from the archive.


I have nothing against him, he asked nicely, But nevertheless, they must go.

At this point, they are more a liability than anything else. All the 
famous vulnerabilities are there, HEARTBLEED, SHELLSHOCK, POODLE, and 
those who've not done the headlines.


The people who come asking for them are following a pattern: they're 
obviously not experimented, and they clearly are not able to assess the 
risks, and *never* in a position to take decision.


Then, their employers follow a similar pattern: they're cheapskates, who 
want to get as much money as possible from obsolete systems with no 
investment in time nor money. They willingly put their customers are 
risk because of their greed.


And lastly, there's an existing alternative, there's SunFreeware, which, 
from a quick look, has much more recent packages.


So frankly, I think we're doing a disservice to everybody by keeping 
those old files online. They should be removed. If a company is 
motivated to revive it and provides resources for it, welcome to it. But 
those files as they stand are just used as an excuse to avoid doing that.


Thanks,

Laurent

Re: OpenCSW contact maintainer

[Laurent Blume]

Hello Kruno,

CC:ing the maintainers list for future reference.

About the legal issues, Wireshark is distributed under the terms of the 
GNU GPLv2. Best to ask your lawyer to be sure, see the Wireshark FAQ as 
a starting point:

https://www.wireshark.org/faq.html#derived_work_gpl

Technically, you can create you own buildfarm as described there:
http://www.opencsw.org/manual/for-maintainers/buildfarm-setup.html

The first steps are easy and allow you to get the recipes and work on 
them locally. Having checkpkg allows to get the dependencies right, but 
it's somewhat more difficult. The OpenCSW buildfarm has all this 
running, of course.


If your changes are of common interest, you could get them included. 
More generally, if you are planning to work with Wireshark as a Solaris 
product on the long term, I can only encourage you to participate in 
OpenCSW, where you could keep it up-to-date more easily, and make sure 
whatever changes you need can be applied.
Myself, I had a need it for it and it was broken, so I fixed it, but I 
have little time for it now.


HTH,

Laurent


Le 2014/11/24 14:30 +0100, Kfranic a écrit:

Hello,
I have one question about repackaging the openCSW Wireshark package.
We would like to unpack it, make some changes then repackage it and provide 
that package to the customer.
I am finding it difficult to get the info if this is allowed or not, do you 
have info if this is allowed and if so under which license?

Any info would be appreciated.

Thanks!

Br,
Kruno

Re: Efforts to relocate recent perl to /opt/csw/perlgcc/*

[Laurent Blume]

Le 2014/11/13 09:37 +0100, Dagobert Michelsen a écrit:

I suggest you use
   EXTRA_RUNPATH_LINKER_FLAGS += /opt/csw/perlgcc/lib/amd64/perl/5.20/CORE
The problem is that the ISA is in the middle of the path, this is not a
standard-case for library locations.


Minor point: would it be easier here to use the lib/64/ link instead of 
an arch-specific name?


Laurent

Re: Removing stale packages

[Laurent Blume]

Le 2014/10/13 14:42 +0200, Matchek a écrit:

Yes, I see what you mean. What we would want to signal to people is
that there is nobody taking care of this package and there will not be
anybody caring about this package, unless they do it. Package not being
in the catalog does send that message (I hope).


I'm afraid the message is too direct: «go away, nothing for you here». 
Considering the requests, few people look long for a solution.



Which approach works better, should be possible to determine
empirically, but I don't have a good idea how. Maybe looking at the
past. Around 2010/2011 we had an influx of new people taken on the
project, followed by most of them not releasing any packages ever.
We've done some package cleanups, and there wasn't much reaction
either. I got contacted once about "why was this package removed?",
and it did not result in a new maintainer joining the project, so I
only have depressing examples for both approaches.


Look, there are no two ways around the facts: Solaris is a dying platform.
S10 has less than 4 years left. Anecdotal evidence shows that it is used 
more and more as a kind of sadistic punishment to people with no 
sufficient skill to administer it properly, let alone build stuff on it. 
S11 is becoming an appliance, and anyway, at this point, its unsupported 
FOSS is still good enough (yes, it will be completely rotten in a few 
years, just like for S10, but that will take time to sink in: many 
people actually believe Oracle supports all that stuff, poor souls).


It won't get better, and sooner or later, we'll all have to find other 
hobbies. Unless maybe we get to the COBOL situation where some companies 
are forced to pay insane amounts to train people to keep using legacy 
systems. But I doubt it, it's not that irreplaceable.


Laurent

Re: Removing stale packages

[Laurent Blume]

Le 2014/10/13 14:26 +0200, Matchek a écrit:

- Deleting old/stale packages can be good, because when a package is
not there, potential new maintainers are motivated to rebuild/update
them. As a backup, allpkgs still contains all of the old packages in
case somebody has their back against the wall.


I somewhat disagree on just that point. If a stale package is not a 
blocking dependency for another, and has no overly sensitive breakage 
(eg security), I think it's better to keep it.


In my view, it's psychologically easier to get somebody to fix something 
already present than if they have the feeling they start from scratch 
(even though the actual work here is often the same if there is no recipe).
Maybe because they can see it has worked in the past, so they can do it 
again?


Laurent

Re: Boost and GCC

[Laurent Blume]

Le 2014/10/10 12:58 +0200, Matchek a écrit:

Hello Maintainers,

I heard unfavorable opinions about /opt/csw/gxx. Our general direction
is to switch to GCC and build C++ libraries into /opt/csw. Boost is one
of the biggest C++ libraries we have. Do we want to move it to /opt/csw?


I see there is a libpcre.so there, wouldn't that conflict?

I'm glad of the move to GCC, but I'm reluctant to do it in a way that 
would be a problem for people who need to build stuff with Studio, 
whether fully in OpenCSW or not.


I was trying to build MySQL 5.7, which uses boost, and apparently it 
could pick it up in its current location (albeit not use it, too old).


So I'd keep it that way unless there's a significant issue (ie, not «it 
doesn't look cool»).


Laurent

Re: ld: fatal: relocations remain against allocatable but non-writable sections -- on linking dtrace probes

[Laurent Blume]

Le 2014/10/02 08:24 +0200, Carsten Grzemba a écrit:

I have seen on different projects (TCL, PHP, ...) that there are
problems to link dtrace userland probes on Solaris. The problem is that
the linker complains if it has to link the dtrace compiled object with
gcc compiled PIC objects (position independent code).
Now I have the problem if I attempt to add dtrace probes in Python.

Has anybody a solution for this problem?
@Laurent: Do you has the dtrace support now in TCL8?




I merely dusted off the recipe at the time because I had a specific 
need, but I've not done any effort to improve it. I'm not a TCL user myself.


Laurent

Re: Mysql hickups. (was The Python web apps throw 500s)

[Laurent Blume]

I will look into it.
For now, be careful that I'm going to push a new package that will 
overwrite it (now that MySQL works, the MySQL packages could be created :-)


My first idea is that it could be handled automatically, following this 
rough outline:

  - CSW package installs cswservice:default
  - users can create cswservice:otherinstance if they wish
  - on package removal, cswservice:* are handled by CAS (instead of 
just the :default)
  - so on updates, all are stopped/restarted. Only :default is updated, 
the others stay of course the responsibility of their creators


Makes sense?

Laurent

Le 2014/09/26 16:15 +0200, Carsten Grzemba a écrit:

mysql trac is online again.

I have changed /etc/opt/csw/init.d/cswmysql5 for support instances:

root@mysql [mysql]:/etc/opt/csw/init.d > diff cswmysql5.org cswmysql5
41c41,42
< datadir=
---
 > datadir=`/bin/svcprop -p config/datadir ${SMF_FMRI} 2>/dev/null`
 > defaults=`/bin/svcprop -p config/defaults ${SMF_FMRI} 2>/dev/null`
293a295,299
 > if [ ! -z "$defaults" ]
 > then
 > defaults_args="--defaults-file=$defaults"
 > extra_args="$defaults_args $extra_args"
 > fi
323c329
<   $bindir/mysqld_safe --datadir="$datadir"
--pid-file="$mysqld_pid_file_path" $other_args >/dev/null 2>&1 &
---
 >   $bindir/mysqld_safe $defaults_args --datadir="$datadir"
--pid-file="$mysqld_pid_file_path" $other_args >/dev/null 2>&1 &

I don't if it is the best place for do this but this kind is a usual way.
@ Laurent: what do you mean, would you incorporate this script change in
your package?

Am 26.09.14 schrieb *Jan Holzhueter * :

Hi,
had some time to debug it :)

Simple problem someone somehow updated the mysql Packege on our mysql
zone.

That caused an update from Mysql Version 5.0 to 5.5 (all praise whom
they like that this did not cause any database problems )

But with this the my.cnf file moved from /opt/csw/mysql5 to /etc/opt/csw
but without any migration script. So some default was loaded with did
not fit our environment. I fixed that now.
It should not give those errors anymore I hope.

@Carsten your mysql trac database needs to be looked at. To do the
update the cswmysql5:trac Service is broken now and starts not your
database anymore. I disabled it for now. If you have the time please
fix it.

Greetings
Jan

Re: putting a dependency on libicu

[Laurent Blume]

Le 2014/09/18 19:40 +0200, Riccardo Mottola a écrit:
> and get:
> CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibgcrypt11
> CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibz1
> CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibobjc3
> CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibicui18n49
> CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibicuuc49
> CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibxslt1
> CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibgnutls26
> CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibxml2-2
> CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibicudata49
> CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibgcc-s1
> CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibgmp10
> CHECKPKG_OVERRIDES_CSWgnustep-base += missing-dependency|CSWlibffi4
> CHECKPKG_OVERRIDES_CSWgnustep-base += surplus-dependency|CSWlibffi5

Don't look at the overrides, look above, where it tells you the proper
line to add.

Also, there's a long standing ld bug on the Solaris sparc build boxes,
which I think has not been fixed.
So build on x86, and check dependencies there. When that's good, look eg
at the ImageMagick recipe to add a conditional section to make the sparc
ld happy.

> it looks like a mess
> It seems that several times older libraries get picked up, why?
> sometimes the corresponding I selected is marked as surplus, sometimes
> not which makes me fear "double linking" of different versions
> 1) objc3 (I really want 4 if I compile with gcc4 or it will crash)
> 2) libffi
> 3) gnutls
> 4) libicu components

Double check your config.log to see what was picked up by configure.

> Other appear as missing, but they are there!
> 1) CSWlibxml2-2
> 2) CSWlibxslt1

There, where? Did you check with ldd?


Laurent

Re: putting a dependency on libicu

[Laurent Blume]

Le 2014/09/17 22:14 +0200, Riccardo Mottola a écrit:

Hi,

what's the best way to mark ICU as a dependency? the version is actually
indifferent to me.

Currently I have in gnustep-base:
BUILD_DEP_PKGS = CSWgmake CSWgcc4objc CSWlibgnutls-dev CSWlibffi-dev
CSWlibicu-dev
DEP_PKGS = CSWgnustep-make CSWlibgnutls28 CSWlibssl1-0-0 CSWlibffi5
CSWlibicuuc52



it seems they are "split" and only for 4.6 there is a full version. What
are the splits for?

suggestions?


Remove that DEP_PKGS, mgar package will tell you what dependencies you 
need to add, you basically only need to copy/paste what it tells you 9 
times out of 10.


Laurent

Re: Update of MySQL to 5.6

[Laurent Blume]

Le 2014/09/17 14:35 +0200, Matchek a écrit:

2014-09-17 12:19 GMT+01:00 Laurent Blume :


I could do it the weekend of 27th of September.



Okay then.


After 5 seconds of strenuous thinking: this is less than 2 weeks, so
you can push the new MySQL, and I will release stable before your new
packages hit the testing catalog. Don't wait!



The 4th second is the one that really counts. Okay, so it should hit 
unstable before this weekend :-)


Laurent

Re: Update of MySQL to 5.6

[Laurent Blume]

Le 2014/09/17 09:47 +0200, Matchek a écrit:

2014-09-16 19:53 GMT+01:00 Laurent Blume :

Sounds reasonable. Do you have a timeframe already?


I could do it the weekend of 27th of September.



Okay then.

Laurent

Re: Update of MySQL to 5.6

[Laurent Blume]

Le 2014/09/16 17:38 +0200, Matchek a écrit:

2014-09-16 15:54 GMT+01:00 Laurent Blume :

A heads up: I'll be pushing MySQL 5.6.20 shortly.


We plan to carve a new stable soon. The task is simple. I will write
it up when performing, for the sake of future releases.

Maybe let's publish a new stable first, and release 5.6 after that?


Sounds reasonable. Do you have a timeframe already?

Laurent

Re: [csw-maintainers] New ImageMagick

[Laurent Blume]

On 11/09/2014 17:17, Kester Habermann wrote:
[snip]

I've already reported this upstream, but no one has confirmed the problem:
http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=25919&sid=e2b38c6d2c2db0333abd5c4bb817ccdf


Have you tried with some other tool using libtiff, just to make sure 
it's specific to ImageMagick?



A completely unrelated issue also involving ImageMagick, it is actually
more an emacs issue. GNU emacs can actually display images inline. Some
images formats (likes fits are displayed using ImageMagick). It appears
that the version of ImageMagick was changed without rebuilding emacs.
This causes emacs to crash when opening an image file:

$ emacs file.fits
ld.so.1: emacs-24.3-athena: fatal: libMagickWand-6.Q16HDRI.so.1: open failed: 
No such file or directory
ld.so.1: emacs-24.3-athena: fatal: relocation error: file 
/opt/csw/bin/emacs-24.3-athena: symbol MagickWandGenesis: referenced symbol not 
found
killed emacs

Note: DISPLAY has to be set to see the problem.

ldd also shows the problem:
kester@unstable10s [unstable10s]:~ > ldd -ur /opt/csw/bin/emacs | grep "not 
found"
 libMagickWand-6.Q16HDRI.so.1 =>  (file not found)
 libMagickCore-6.Q16HDRI.so.1 =>  (file not found)
 symbol not found: MagickGetException
(/opt/csw/bin/emacs-24.3-athena)


That's a mistake of mine, I think I some point I pushed a stub for the 
.so.1 libs, and that was wrong. I hadn't realized it had had some 
effect. I need to find a way to rebuild that version. Can you open a bug 
report on it to prod me?


Laurent

Re: Updates from unstable to testing

[Laurent Blume]

Le 2014/08/09 12:19 +0200, Matchek a écrit:

2014-08-09 11:03 GMT+01:00 Laurent Blume :


Err, am I missing something, I don't see how to do that?


Click the "Update Issue" button on the left. It's not intuitive.



Thanks!

Re: Updates from unstable to testing

[Laurent Blume]

Le 2014/08/09 10:38 +0200, Matchek a écrit:

- if the bug is real but not high severity and you want the package
integrated, lower the severity in mantis


Err, am I missing something, I don't see how to do that?

Laurent

Re: Updates from unstable to testing

[Laurent Blume]

Le 2014/08/09 10:38 +0200, Matchek a écrit:

Looking at the last report, there are some packages with blocking bugs:

mysql5


Recently opened bug, looks like a configuration error, I've asked for 
feedback, I'm not getting it, so I'll close it soon.


Laurent

Re: libutil not found

[Laurent Blume]

Best approach is going to opencsw.org, clicking on «Search» on the 
right, entering «libutil.so» in the Filename field, and checking 
«partial match» before clicking on the Search button.


If there's no match, well, welcome to Dependency Hell! :-)

Laurent

Le 2014/07/30 23:04 +0200, Riccardo Mottola a écrit:

Hi,

while trying to package GNUsteps IDE, I get:

ld: fatal: library -lutil: not found

what's the best approach? do we have this lbirary but just in a place
not found? or is it not needed? is there a deeper porting problem?
The closest library I could find is libuutil

Riccardo

Re: gnustep-back no longer builds

[Laurent Blume]

Le 2014/07/03 18:50 +0200, Riccardo Mottola a écrit:

I get such an error:
Making all for subproject x11...
  Compiling file context.c ...
In file included from context.c:24:0:
/usr/openwin/include/X11/Xlib.h:38:0: warning: ignoring #pragma ident
[-Wunknown-pragmas]
  #pragma ident "@(#)Xlib.h 1.12 04/07/14 SMI"


Not an error, a warning. Unlikely to be an issue, just ignore it.


Most surely an include problem.

I notice that during configure I get a lot of errors:
checking for cairo... yes
checking CAIRO_CFLAGS... sh: gnome-config: not found
Package gobject-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gobject-2.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gobject-2.0', required by 'cairo', not found

I have gobject installed:


That .pc file is in CSWlibglib2-dev, I'd say that CSWlibcairo-dev is 
missing a dependency on it.


Laurent

Re: OpenSSL roadmap - community support wanted

[Laurent Blume]

Le 2014/07/02 09:54 +0200, Peter Bonivart a écrit:

I just read their new roadmap: https://www.openssl.org/about/roadmap.html

Look under Platform Strategy at the end, they are looking for
community support to include operating systems into a secondary
support group (the primary group will only be Linux and FreeBSD). We
look like a good fit to make sure Solaris will be included in the
future.


Definitely, at the very least for Solaris 10 to stay a supported platform.

Laurent

Re: first gnustep app! but segfaults

[Laurent Blume]

Le 2014/06/26 09:45 +0200, Riccardo Mottola a écrit:

as far as I know, it is the standard way to pass those to configure
one-shot, it always worked for me.

This is from configure help:

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.


Check what is the RPATH there:
/usr/ccs/bin/dump -Lv 
/opt/GNUstep/Local/Library/Libraries/libgnustep-gui.so | grep PATH


It surely looks like RUNPATH /usr/lib:/opt/csw/lib

Save the output of the whole build: make >& output

And confirm there if there are some places the arguments are in the 
wrong order (-R/usr/lib -R/opt/csw/lib), because configure has its own 
ideas on what to add.


Most probably, it's now time to get out the LD_OPTIONS sledgehammer.

Laurent

Re: Checkpkg insists that a library is surplus, I think it is not

[Laurent Blume]

Le 2014/06/05 14:06 +0200, Matchek a écrit:

I registered a few by hand to see if this has an effect:

curl --netrc -X PUT
http://buildfarm.opencsw.org/releases/svr4/7cb32f2d4a23841cc23277015620040a/db-level-2/;
echo
{"message": "Package registered to level 2"}

It does have an effect. Maybe csw-upload-pkg has a bug where it
forgets to make this call, or mistakenly thinks that it's not
necessary.



At least now it looks all good for me - thanks!



Laurent

Re: Checkpkg insists that a library is surplus, I think it is not

[Laurent Blume]

Le 2014/06/05 11:13 +0200, Matchek a écrit:

I have a guess.

checkpkg does the following:

Q: "What does the binary need?"
A: "librsvg-2.so.2"

Q: "Which package provides librsvg-2.so.2?"
A: "SUNWgnome-base-libs and CSW... no, actually, no CSW* package
provides librsvg-2.so.2."

The CSWlibrsvg2-2 package only provides librsvg-2.so.2.36.4 (!=
librsvg-2.so.2).


Err what?

$ pkgchk -lp /opt/csw/lib/librsvg-2.so.2
NOTE: Couldn't lock the package database.
Pathname: /opt/csw/lib/librsvg-2.so.2
Type: symbolic link
Source of link: librsvg-2.so.2.36.4
Referenced by the following packages:
CSWlibrsvg2-2
Current status: installed

And that's not new, it's been like that for a while. So I don't think 
that explanation is the right one :-)


Laurent

Checkpkg insists that a library is surplus, I think it is not

[Laurent Blume]

Hello,

With the ImageMagick recipe, between a beta two weeks ago and now, the 
behaviour of checkpkg has changed, it has now decided that librsvg is 
not needed:


 * Dependency issues of CSWimagemagick:
 * If you don't know of any reasons to include these dependencies, you 
might remove them:

 * ? CSWlibrsvg2-2

That seems really weird: the library was properly detected and used, 
dump -Lv shows it, so why would checkpkg decide it is not needed?


./work/solaris10-i386/pkgroot/opt/csw/lib/ImageMagick-6.8.9/modules-Q16HDRI/coders/svg.so:

   DYNAMIC SECTION INFORMATION 
.dynamic:
[INDEX] Tag Value
[1] NEEDED  libMagickCore-6.Q16HDRI.so.2
[2] NEEDED  librsvg-2.so.2

Can somebody explain that?

Thanks,

Laurent

Re: ld: fatal: file /lib/libc.so: version 'SUNW_1.22.5' is unavailable

[Laurent Blume]

The rebuilt 5.5.36 has been pushed, it works for me.

Regards,

Laurent


Le 2014/02/25 11:56 +0100, Dagobert Michelsen a écrit:

Hi Jake,

Am 18.02.2014 um 18:15 schrieb Jake Goerzen mailto:jgoer...@opencsw.org>>:

On 02/16/14 04:39, Dagobert Michelsen wrote:

Am 13.02.2014 um 18:27 schrieb Jake Goerzen mailto:jgoer...@opencsw.org>>:

  Since the last update to mysql packages I can no longer build
dovecot anymore, configure fails with:

checking for mysql_config... mysql_config
checking for mysql_init in -lmysqlclient... no
configure: error: Can't build with MySQL support: libmysqlclient
not found
/home/jgoerzen/opencsw/.buildsys/v2/gar//gar.lib.mk:835: recipe
for target

'configure-work/solaris10-i386/build-isa-pentium_pro/dovecot-2.2.10/configure'
failedgmake[1]: ***

[configure-work/solaris10-i386/build-isa-pentium_pro/dovecot-2.2.10/configure]
Error 1


Looking In config.log the error encountered is:
ld: fatal: file /lib/libc.so: version 'SUNW_1.22.5' is unavailable

configure:23474: checking for mysql_init in -lmysqlclient
configure:23499: /opt/SUNWspro/bin/cc -o conftest -xO3 -m32
-xarch=pentium_pro -xchip=pentium_pro -I/opt/csw/include
-I/opt/csw/include/mysql -I/opt/csw/include/postgresql
-I/opt/csw/include -m32 -xarch=pentium_pro -xchip=pentium_pro
-L/opt/csw/lib conftest.c -lmysqlclient  -lrt -lnsl -lsocket
-lsendfile -L/opt/csw/lib -lmysqlclient  -lsocket -lz -lnsl -lrt
-lssl -lcrypto -lz -lm >&5
"conftest.c", line 155: warning: statement not reached
ld: fatal: file /lib/libc.so: version 'SUNW_1.22.5' is unavailable:
required by file /opt/csw/lib/libmysqlclient.so
ld: fatal: file processing errors. No output written to conftest


I tried switching the compiler to GCC4 but configure still can't
find or link -lmysqlclient  What could be the problem?


The problem is that mysql actually needs the newer libc-version for
getpagesize2() as reported in
https://www.opencsw.org/mantis/view.php?id=5137
This is not related to GCC or Sun Studio. I suggest you disable the
linker map forcing 1.22.5 in your Makefile with
  # Disable linker map forcing SUNW_1.22.2 as the linked MySQL needs
SUNW_1.22.5
  LINKER_MAPS =
After that everything sould work cleanly.


Hi Dago,

I added the suggestion to the dovecot recipe, now configure finishes
successfully but the build fails to link.  Here is what I get in the
build process now:

on unstable10x:

libtool: link: /opt/SUNWspro/bin/cc -xO3 -m32 -xarch=pentium_pro
-xchip=pentium_pro -I/opt/csw/include -m32 -xarch=pentium_pro
-xchip=pentium_pro -o .libs/auth auth.o auth-cache.o
auth-client-connection.o auth-master-connection.o
auth-postfix-connection.o mech-otp-skey-common.o mech-plain-common.o
auth-penalty.o auth-request.o auth-request-handler.o auth-settings.o
auth-fields.o auth-token.o auth-worker-client.o auth-worker-server.o
db-checkpassword.o db-dict.o db-dict-cache-key.o db-sql.o
db-passwd-file.o main.o mech.o mech-anonymous.o mech-plain.o
mech-login.o mech-cram-md5.o mech-digest-md5.o mech-external.o
mech-gssapi.o mech-ntlm.o mech-otp.o mech-scram-sha1.o mech-skey.o
mech-rpa.o mech-apop.o mech-winbind.o mech-dovecot-token.o passdb.o
passdb-blocking.o passdb-bsdauth.o passdb-cache.o
passdb-checkpassword.o passdb-dict.o passdb-passwd.o
passdb-passwd-file.o passdb-pam.o passdb-shadow.o passdb-sia.o
passdb-vpopmail.o passdb-sql.o passdb-static.o passdb-template.o
userdb.o userdb-blocking.o userdb-checkpassword.o userdb-dict.o
userdb-nss.o userdb-passwd.o userdb-passwd-file.o userdb-prefetch.o
userdb-static.o userdb-vpopmail.o userdb-sql.o userdb-template.o
db-ldap.o passdb-ldap.o userdb-ldap.o -m32  -L/opt/csw/lib
libpassword.a ../lib-ntlm/libntlm.a ../lib-otp/libotp.a
../../src/lib-sql/.libs/libsql.a
../../src/lib-dovecot/.libs/libdovecot.so -liconv -lpam -lintl
-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lgss -lldap -llber
-lmysqlclient -lssl -lcrypto -lpq -lsqlite3 -lz -lrt -lnsl -lsocket
-lsendfile -R/opt/csw/lib/dovecot -R/opt/csw/lib
Undefined   first referenced
 symbol in file
floor   /opt/csw/lib/libmysqlclient.so
ld: fatal: symbol referencing errors. No output written to .libs/auth
Makefile:812: recipe for target 'auth‘ failed


This is because libmysqlclient.so is not self-contained as it should be:
it uses floor() but does not link to libm.
@Laurent: Can you please rebuild the mysql libs with -lm as
EXTRA_LINKER_FLAGS?

dam@unstable10s [unstable10s]:/home/dam > ldd -r
 librt.so.1 =>/lib/librt.so.1
 libssl.so.1.0.0 =>
/opt/csw/lib/sparcv8plus+vis/libssl.so.1.0.0
 libcrypto.so.1.0.0 =>
  /opt/csw/lib/sparcv8plus+vis/libcrypto.so.1.0.0
 libnsl.so.1 =>   /lib/libnsl.so.1
 librt.so.1 =>/lib/librt.so.1
 libsocket.so.1 =>/lib/libsocket.so.1
 libpthread.so.1 =>   /lib/libpthread.so.1
 libgcc_s.so.1 => /o

Re: ld: fatal: file /lib/libc.so: version 'SUNW_1.22.5' is unavailable

[Laurent Blume]

Le 2014/02/19 15:10 +0100, Dagobert Michelsen a écrit:

This is because libmysqlclient.so is not self-contained as it should be:
it uses floor() but does not link to libm.
@Laurent: Can you please rebuild the mysql libs with -lm as
EXTRA_LINKER_FLAGS?


Hmmm, I will, however it's already there as CFLAGS/CXXFLAGS (as per the 
way the MySQL and Solaris teams make their builds).


Strange that this would only surface now. Maybe a side-effect of going 
to GCC.


Laurent

Re: genshi, subvertpy not in catalog?

[Laurent Blume]

On 12/28/2013 04:42 PM, Dagobert Michelsen wrote:
> Nope, some else to blame ;-)
> 
> ERROR! Cyclic dependency detected in package CSWlibkrb5-3 because of 
> CSWlibkrb5-3 -> CSWlibkrb5-priv -> CSWlibgssapi-krb5-2 -> CSWlibkrb5-3.
> ERROR! Cyclic dependency detected in package CSWlibkrb5-priv because of 
> CSWlibkrb5-priv -> CSWlibgssapi-krb5-2 -> CSWlibkrb5-3 -> CSWlibkrb5-priv.
> 
> Laurent, just by a strange coincidence do you happen to know someone who
> would have both the capability and kindness of crafting another set of
> kerberos packages? ;-)

Bit messy, I'm not even sure how it got in partially. I've pushed a new
version that upgraded fine from experimental. Basically I merged
packages that depend one on the other so they won't create circular deps
anymore. Some day, I'll remake the whole recipe to look just like .

> PS: How about a new rule? Whoever breaks the catalog is up for a round of 
> beer at the next camp!
> PPS: I'll throw the first one for the monitoring email not reaching me before 
> someone notices...

Heh, when is it going to be? My trip schedule for next year is filling
up already :-)

Joyeuses fêtes!

Laurent

Re: [csw-maintainers] HEADS-UP: DKIM & DMARC compliant mailing lists

[Laurent Blume]

On 13/10/2013 13:12, Peter FELECAN wrote:
> Laurent Blume  writes:
> 
>> Is there a reason why we can't have the subject tags back? I do miss
>> them, the lack of them is making my opencsw.org box confusing.
> 
> FWIW, you are probably alone wanting that back. FYI, there is the
> List-Id tag which can be used to filter and classify messages.

FWIW, I know I am not alone, since there is at least one other person
that asked about it on IRC.

FYI, if you bothered to read my messages, I was talking about my own
eyes. I'm not using those tags for automatic filters. I am using them so
I can recognize messages easily without having to waste more time
creating filters. I already have dozens of filters. I am up to my nose
in filters, procmail filters, firefox filters, outlook/exchange filters.

I do not want to create more filters just because... just because what?
I do not even know what nail-looking problems this hammer-sized change
was supposed to fix. It would be easier for me to accept changing old
habits if I were explained why it's not an arbitrary.

I'll just unsubscribe.

Laurent

Re: [csw-maintainers] HEADS-UP: DKIM & DMARC compliant mailing lists

[Laurent Blume]

Hello,

This one might have gone unnoticed :-)

Is there a reason why we can't have the subject tags back? I do miss
them, the lack of them is making my opencsw.org box confusing.

Thanks in advance,

Laurent

On 08/10/2013 09:49, Laurent Blume wrote:
> Hello Ihsan,
> 
> Is it possible to have the subject line tag back?
> It's not for filter: my eyes do need it to sort the different emails at
> a glance in that mailbox. It's not one I use for personal email, so I
> really appreciated the possibility to notice emails sent to me directly.
> 
> Thanks in advance,
> 
> Laurent
> 
> On 07/10/13 19:18, İhsan Doğan via maintainers wrote:
>> Am 07.10.2013 18:40, schrieb Maciej (Matchek) Bliziński:
>>
>>>> In order to be DMARC and DKIM compliant, I've changed the Mailman
>>>> configuration and it will affect the mailing lists:
>>>>
>>>> - The "From" field ist changed to "xxx via maintainers"
>>>> - The subject line will be not anymore modified
>>>> - The footes has been removed
>>>
>>> Good riddance! I never liked these footnotes.
>>>
>>>> - Each mail going through a mailing list is now DKIM signed
>>
>> Well, something is still not right. Mails are not getting signed.
>> Hmm...
>>
>>
>>
>> Ihsan
>>
> 

Re: [csw-maintainers] Buildfarm setup - documentation

[Laurent Blume]

On 08/10/13 15:08, Peter FELECAN wrote:

Laurent Blume  writes:


I will revert what you did, because as it happens, it conflicts with
what *I* am working on.


How can this conflict with whatever you do? Maybe you're adding the
documentation in the recipe on which you are working on. Anyhow, here is
the patch, so you can have the courtesy to include it in the next
release:


I certainly will consider if there is a need. Since you left out all the 
dependencies that would be needed, I need to think about that too.


In the meantime, since the file is already provided by CSWmysql5, I 
think you can already use it by typing «info mysql».


Laurent