FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 01-01-2008, 04:16 PM
"K. Piche"
 
Default Updated perl 5.10.0

I put perl 5.10.0 in testing. It follows the new perl hierarchy, the
install file removes the symlink farm that confused everybody and it
prints a small blurb about the update.

Please test,

k



--
K. Piche <kpiche@rogers.com>
 
Old 01-01-2008, 05:04 PM
Andreas Radke
 
Default Updated perl 5.10.0

Am Tue, 01 Jan 2008 12:16:19 -0500
schrieb "K. Piche" <kpiche@rogers.com>:

> I put perl 5.10.0 in testing. It follows the new perl hierarchy, the
> install file removes the symlink farm that confused everybody and it
> prints a small blurb about the update.
>
> Please test,
>
> k

http://bugs.archlinux.org/task/7530

can we close this bug now?

-Andy
 
Old 01-02-2008, 06:34 AM
Jason Chu
 
Default Updated perl 5.10.0

On Tue, Jan 01, 2008 at 12:16:19PM -0500, K. Piche wrote:
> I put perl 5.10.0 in testing. It follows the new perl hierarchy, the
> install file removes the symlink farm that confused everybody and it
> prints a small blurb about the update.
>
> Please test,

As mentioned by Pierre I ran into the ptar and ptardiff conflicts. I ended
up just forcing the upgrade (probably not the best idea in the long run
though).

I'm also having a problem starting spamassassin with this version. It
might not be the fault of perl, but here's the error message anyway:

:: Stopping spamd [DONE]
:: Starting spamd [BUSY]
/usr/bin/perl: symbol lookup error: /usr/lib/perl5/site_perl/current/i686-linux-thread-multi/auto/HTML/Parser/Parser.so: undefined symbol: Perl_Tstack_sp_ptr
[FAIL]

Seems that there's a symbol that used to be in some perl lib but isn't
anymore (Perl_Tstack_sp_ptr).

I can create a bug if need be.

Jason
 
Old 01-02-2008, 12:11 PM
"Dan McGee"
 
Default Updated perl 5.10.0

On Jan 2, 2008 1:34 AM, Jason Chu <jason@archlinux.org> wrote:
> On Tue, Jan 01, 2008 at 12:16:19PM -0500, K. Piche wrote:
> > I put perl 5.10.0 in testing. It follows the new perl hierarchy, the
> > install file removes the symlink farm that confused everybody and it
> > prints a small blurb about the update.
> >
> > Please test,
>
> As mentioned by Pierre I ran into the ptar and ptardiff conflicts. I ended
> up just forcing the upgrade (probably not the best idea in the long run
> though).
>
> I'm also having a problem starting spamassassin with this version. It
> might not be the fault of perl, but here's the error message anyway:
>
> :: Stopping spamd [DONE]
> :: Starting spamd [BUSY]
> /usr/bin/perl: symbol lookup error: /usr/lib/perl5/site_perl/current/i686-linux-thread-multi/auto/HTML/Parser/Parser.so: undefined symbol: Perl_Tstack_sp_ptr
> [FAIL]
>
> Seems that there's a symbol that used to be in some perl lib but isn't
> anymore (Perl_Tstack_sp_ptr).
>
> I can create a bug if need be.

Same issue for urxvt:
http://bugs.archlinux.org/task/9075

-Dan
 
Old 01-03-2008, 01:10 AM
"K. Piche"
 
Default Updated perl 5.10.0

On Wed, 2008-01-02 at 07:11 -0600, Dan McGee wrote:
> On Jan 2, 2008 1:34 AM, Jason Chu <jason@archlinux.org> wrote:
> > On Tue, Jan 01, 2008 at 12:16:19PM -0500, K. Piche wrote:
> > > I put perl 5.10.0 in testing. It follows the new perl hierarchy, the
> > > install file removes the symlink farm that confused everybody and it
> > > prints a small blurb about the update.
> > >
> > > Please test,
> >
> > As mentioned by Pierre I ran into the ptar and ptardiff conflicts. I ended
> > up just forcing the upgrade (probably not the best idea in the long run
> > though).

What's the conflicting package? I've never seen a conflict.

> > I'm also having a problem starting spamassassin with this version. It
> > might not be the fault of perl, but here's the error message anyway:
> >
> > :: Stopping spamd [DONE]
> > :: Starting spamd [BUSY]
> > /usr/bin/perl: symbol lookup error: /usr/lib/perl5/site_perl/current/i686-linux-thread-multi/auto/HTML/Parser/Parser.so: undefined symbol: Perl_Tstack_sp_ptr
> > [FAIL]

I'll rebuild the html-parser modules tonight, thanks.

> >
> > Seems that there's a symbol that used to be in some perl lib but isn't
> > anymore (Perl_Tstack_sp_ptr).
> >
> > I can create a bug if need be.
>
> Same issue for urxvt:
> http://bugs.archlinux.org/task/9075
>
> -Dan

Yeah, it's cause of the move to perl 5.10.0. I had the same symbol
problem with perlxml - a rebuild will fix it. Adding urxvt to the list.


--
K. Piche <kpiche@rogers.com>
 
Old 01-03-2008, 01:56 AM
"Dan McGee"
 
Default Updated perl 5.10.0

On Jan 2, 2008 8:10 PM, K. Piche <kpiche@rogers.com> wrote:
> > > Seems that there's a symbol that used to be in some perl lib but isn't
> > > anymore (Perl_Tstack_sp_ptr).
> > >
> > > I can create a bug if need be.
> >
> > Same issue for urxvt:
> > http://bugs.archlinux.org/task/9075
> >
> > -Dan
>
> Yeah, it's cause of the move to perl 5.10.0. I had the same symbol
> problem with perlxml - a rebuild will fix it. Adding urxvt to the list.

Thanks for the good work here! Urxvt working fine now, and running
perl 5.10.0. If all is well I'll give it a signoff in a couple of
days.

Can you perhaps point the rest of us in the right direction as to what
we need to do to packages to make them comply with the new perl
policy? That wiki page looks good (not sure how recent it has been
updated), but is there an easy trick to get modules to install in the
vendor directory? I know I have a few packages that install stuff into
site_perl instead of vendor_perl, and I'm sure others do as well.

-Dan
 
Old 01-03-2008, 03:10 AM
"K. Piche"
 
Default Updated perl 5.10.0

On Wed, 2008-01-02 at 20:56 -0600, Dan McGee wrote:
> On Jan 2, 2008 8:10 PM, K. Piche <kpiche@rogers.com> wrote:
> > > > Seems that there's a symbol that used to be in some perl lib but isn't
> > > > anymore (Perl_Tstack_sp_ptr).
> > > >
> > > > I can create a bug if need be.
> > >
> > > Same issue for urxvt:
> > > http://bugs.archlinux.org/task/9075
> > >
> > > -Dan
> >
> > Yeah, it's cause of the move to perl 5.10.0. I had the same symbol
> > problem with perlxml - a rebuild will fix it. Adding urxvt to the list.
>
> Thanks for the good work here! Urxvt working fine now, and running
> perl 5.10.0. If all is well I'll give it a signoff in a couple of
> days.
>
> Can you perhaps point the rest of us in the right direction as to what
> we need to do to packages to make them comply with the new perl
> policy? That wiki page looks good (not sure how recent it has been
> updated), but is there an easy trick to get modules to install in the
> vendor directory? I know I have a few packages that install stuff into
> site_perl instead of vendor_perl, and I'm sure others do as well.
>
> -Dan

Sure, no problem. There are 2 main things that need to be taken care of
for official perl modules:

- files installed in the vendor directories
- man pages should be named with .[0-9]pm extensions so they don't
conflict with CPAN/CPANPLUS installed packages. There is no distinction
between vendor/site/core in regards to man pages

Most of our official modules use the 'perl Makefile.PL' method to build
and the perlxml PKGBUILD would be a good example of this. The other
method 'perl Build.PL' I'm figuring out now with sdl-perl (need frozen
bubble!).

Makefile.PL stuff becomes:
# install module in vendor directories.
perl Makefile.PL INSTALLDIRS=vendor || return 1
make MAN1EXT=1p MAN3EXT=3pm || return 1
make install MAN1EXT=1p MAN3EXT=3pm DESTDIR=${startdir}/pkg || return
1

The extension stuff is twice cause some modules create some man pages
during the first make and the rest during install, dumb.

I've already mass converted (hopefully) all of the module PKGBUILDs in
extra using some sed hacking - I'm just going through them all checking
for errors and rebuilding. Technically only modules with *.so libraries
need to be rebuilt right away to fix the perl symbol problems - pure
perl modules should be fine for now since the old current directories
are included in @INC.

Another thing to note is that additional modules were added to the
default perl library so some official packages are not needed once
5.10.0 is installed. However the packages can be used to "update" parts
of the perl library. I'm not sure how we're going to deal with this
situation yet. For example perl 5.10.0 now comes with
IO::Compress::Base version 2.008, perl-io-compress-base is 2.006. The
package is not required until 2.009 is released and before the perl
package gets updated.

k


--
K. Piche <kpiche@rogers.com>
 
Old 01-03-2008, 02:39 PM
"Aaron Griffin"
 
Default Updated perl 5.10.0

On Jan 2, 2008 8:10 PM, K. Piche <kpiche@rogers.com> wrote:
>
> On Wed, 2008-01-02 at 07:11 -0600, Dan McGee wrote:
> > On Jan 2, 2008 1:34 AM, Jason Chu <jason@archlinux.org> wrote:
> > > On Tue, Jan 01, 2008 at 12:16:19PM -0500, K. Piche wrote:
> > > > I put perl 5.10.0 in testing. It follows the new perl hierarchy, the
> > > > install file removes the symlink farm that confused everybody and it
> > > > prints a small blurb about the update.
> > > >
> > > > Please test,
> > >
> > > As mentioned by Pierre I ran into the ptar and ptardiff conflicts. I ended
> > > up just forcing the upgrade (probably not the best idea in the long run
> > > though).
>
> What's the conflicting package? I've never seen a conflict.

perl-archive-tar (required by spamassassin)

I'd venture a guess that it's not needed anymore? Maybe rebuild
spamassassin without the dep and/or add a conflicts/provides to the
new perl package?
 
Old 01-04-2008, 03:34 AM
"K. Piche"
 
Default Updated perl 5.10.0

On Thu, 2008-01-03 at 09:39 -0600, Aaron Griffin wrote:
> On Jan 2, 2008 8:10 PM, K. Piche <kpiche@rogers.com> wrote:
> >
> > On Wed, 2008-01-02 at 07:11 -0600, Dan McGee wrote:
> > > On Jan 2, 2008 1:34 AM, Jason Chu <jason@archlinux.org> wrote:
> > > > On Tue, Jan 01, 2008 at 12:16:19PM -0500, K. Piche wrote:
> > > > > I put perl 5.10.0 in testing. It follows the new perl hierarchy, the
> > > > > install file removes the symlink farm that confused everybody and it
> > > > > prints a small blurb about the update.
> > > > >
> > > > > Please test,
> > > >
> > > > As mentioned by Pierre I ran into the ptar and ptardiff conflicts. I ended
> > > > up just forcing the upgrade (probably not the best idea in the long run
> > > > though).
> >
> > What's the conflicting package? I've never seen a conflict.
>
> perl-archive-tar (required by spamassassin)
>
> I'd venture a guess that it's not needed anymore? Maybe rebuild
> spamassassin without the dep and/or add a conflicts/provides to the
> new perl package?

Yep. Archive::Tar is included as a standard module now with 5.10.0. A
good number of provides will be added to the next testing perl pkg.

--
K. Piche <kpiche@rogers.com>
 
Old 01-05-2008, 02:30 AM
"K. Piche"
 
Default Updated perl 5.10.0

On Wed, 2008-01-02 at 23:10 -0500, K. Piche wrote:
> On Wed, 2008-01-02 at 20:56 -0600, Dan McGee wrote:
> > On Jan 2, 2008 8:10 PM, K. Piche <kpiche@rogers.com> wrote:
> > > > > Seems that there's a symbol that used to be in some perl lib but isn't
> > > > > anymore (Perl_Tstack_sp_ptr).
> > > > >
> > > > > I can create a bug if need be.
> > > >
> > > > Same issue for urxvt:
> > > > http://bugs.archlinux.org/task/9075
> > > >
> > > > -Dan
> > >
> > > Yeah, it's cause of the move to perl 5.10.0. I had the same symbol
> > > problem with perlxml - a rebuild will fix it. Adding urxvt to the list.
> >
> > Thanks for the good work here! Urxvt working fine now, and running
> > perl 5.10.0. If all is well I'll give it a signoff in a couple of
> > days.
> >
> > Can you perhaps point the rest of us in the right direction as to what
> > we need to do to packages to make them comply with the new perl
> > policy? That wiki page looks good (not sure how recent it has been
> > updated), but is there an easy trick to get modules to install in the
> > vendor directory? I know I have a few packages that install stuff into
> > site_perl instead of vendor_perl, and I'm sure others do as well.
> >
> > -Dan
>
> Sure, no problem. There are 2 main things that need to be taken care of
> for official perl modules:
>
> - files installed in the vendor directories
> - man pages should be named with .[0-9]pm extensions so they don't
> conflict with CPAN/CPANPLUS installed packages. There is no distinction
> between vendor/site/core in regards to man pages
>
> Most of our official modules use the 'perl Makefile.PL' method to build
> and the perlxml PKGBUILD would be a good example of this. The other
> method 'perl Build.PL' I'm figuring out now with sdl-perl (need frozen
> bubble!).
>
> Makefile.PL stuff becomes:
> # install module in vendor directories.
> perl Makefile.PL INSTALLDIRS=vendor || return 1
> make MAN1EXT=1p MAN3EXT=3pm || return 1
> make install MAN1EXT=1p MAN3EXT=3pm DESTDIR=${startdir}/pkg || return
> 1


I've rethought how I'm going to handle the man page extension stuff so
packagers won't need to set man1ext and man3ext like this. I'm going to
try tweaking Config.pm after the perl pkg 'make install'. So don't
convert all your builds yet although the above will still work.

Also the Build.PL stuff is now:
perl Build.PL installdirs=vendor destdir=${startdir}/pkg
--config man1ext=1p --config man3ext=3pm
perl Build
perl Build install

With man extension settings for now. Note that perl-module-build and
perl-extutils-cbuilder are in core perl now so are no longer required in
makedepends. You may still need perl-yaml though.

Have fun,

k


> The extension stuff is twice cause some modules create some man pages
> during the first make and the rest during install, dumb.
>
> I've already mass converted (hopefully) all of the module PKGBUILDs in
> extra using some sed hacking - I'm just going through them all checking
> for errors and rebuilding. Technically only modules with *.so libraries
> need to be rebuilt right away to fix the perl symbol problems - pure
> perl modules should be fine for now since the old current directories
> are included in @INC.
>
> Another thing to note is that additional modules were added to the
> default perl library so some official packages are not needed once
> 5.10.0 is installed. However the packages can be used to "update" parts
> of the perl library. I'm not sure how we're going to deal with this
> situation yet. For example perl 5.10.0 now comes with
> IO::Compress::Base version 2.008, perl-io-compress-base is 2.006. The
> package is not required until 2.009 is released and before the perl
> package gets updated.
>
> k
>
>
--
K. Piche <kpiche@rogers.com>
 

Thread Tools




All times are GMT. The time now is 09:13 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org