pkgutil-users — User list for questions etc.

[Pkgutil-users] SF.net SVN: pkgutil:[63] trunk/pkgutil

[<bon...@us...>]

Revision: 63
          http://pkgutil.svn.sourceforge.net/pkgutil/?rev=63&view=rev
Author:   bonivart
Date:     2009-06-16 15:11:32 +0000 (Tue, 16 Jun 2009)

Log Message:
-----------
pkgutil: make install/remove prompts more clearly visible

Modified Paths:
--------------
    trunk/pkgutil


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

[Pkgutil-users] SF.net SVN: pkgutil:[62] trunk/pkgutil

[<bon...@us...>]

Revision: 62
          http://pkgutil.svn.sourceforge.net/pkgutil/?rev=62&view=rev
Author:   bonivart
Date:     2009-06-16 15:08:37 +0000 (Tue, 16 Jun 2009)

Log Message:
-----------
pkgutil: replace deprecated $# with scalar

Modified Paths:
--------------
    trunk/pkgutil


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Re: [Pkgutil-users] pkgutil package install/available mismatch

[Rob R. <rr...@fa...>]

I would rather do the full compare for sake of accuracy. I see the value
in keeping that functionality intact. It would be nice if it was faster.

I can switch between pkg-get and pkgutil in puppet but I have a second
repo configured in the configuration and pkg-get doesn't support
multiple repos or repos over https.

Rob Ruma
Harvard University
Faculty of Arts and Sciences (FAS)
UNIX IT Systems

Peter Bonivart wrote:
> On Wed, Jun 10, 2009 at 3:28 PM, Rob Ruma <rr...@fa...> wrote:
>> Here's a scenario:
>>
>> I have 10 packages in my puppet manifest I need to make sure are installed.
>>
>> Each time puppet runs on the client server, it uses pkgutil -c <pkg
>> name> to check if that particular package is still installed. It runs
>> this command for each package which results in overall slower
>> performance for puppet opposed to using pkg-get for the package provider.
> 
> Ok, that's unfortunate since "pkgutil -c pkgname" does a full compare
> and then just filters the output to match "pkgname". In the case of
> puppet, a full compare is done for every package installed. I have no
> idea how pkg-get does a compare.
> 
> I guess I could look into a compare option that is not just a filter
> but instead only compares exactly your arguments. That would be
> faster.
> 
> I don't use puppet, can you change between pkg-get and pkgutil and
> different options yourself or is it "built-in" how it's used?
> 

Re: [Pkgutil-users] pkgutil package install/available mismatch

[Peter B. <bon...@op...>]

On Wed, Jun 10, 2009 at 3:28 PM, Rob Ruma <rr...@fa...> wrote:
> Here's a scenario:
>
> I have 10 packages in my puppet manifest I need to make sure are installed.
>
> Each time puppet runs on the client server, it uses pkgutil -c <pkg
> name> to check if that particular package is still installed. It runs
> this command for each package which results in overall slower
> performance for puppet opposed to using pkg-get for the package provider.

Ok, that's unfortunate since "pkgutil -c pkgname" does a full compare
and then just filters the output to match "pkgname". In the case of
puppet, a full compare is done for every package installed. I have no
idea how pkg-get does a compare.

I guess I could look into a compare option that is not just a filter
but instead only compares exactly your arguments. That would be
faster.

I don't use puppet, can you change between pkg-get and pkgutil and
different options yourself or is it "built-in" how it's used?

-- 
/peter

Re: [Pkgutil-users] pkgutil package install/available mismatch

[Rob R. <rr...@fa...>]

Here's a scenario:

I have 10 packages in my puppet manifest I need to make sure are installed.

Each time puppet runs on the client server, it uses pkgutil -c <pkg
name> to check if that particular package is still installed. It runs
this command for each package which results in overall slower
performance for puppet opposed to using pkg-get for the package provider.

Rob Ruma
Harvard University
Faculty of Arts and Sciences (FAS)
UNIX IT Systems

Peter Bonivart wrote:
> On Wed, Jun 10, 2009 at 4:50 AM, Rob Ruma <rr...@fa...> wrote:
>> Hi Peter,
>>        After doing more testing with pkgutil as a package provider for puppet,
>> I've discovered that using the true package name to call packages works
>> just fine. Although, I have noticed that manifests referencing many
>> packages does take considerably longer to process compared to pkg-get.
> 
> Do you mean when there are many dependencies?
> 
> When pkg-get installs it doesn't check dependencies at all, it just
> downloads the requested package, unpacks it and then check if there
> are dependencies to add, this repeats recursively.
> 
> It's of course faster not to do something than doing it but normally
> download and install is like 90-99% of the time spent.
> 
> I just tried with Firefox on a 10 year old Sparc and it calculated the
> dependencies in 2 seconds. Gnome, however, took 2 minutes. On a
> relatively modern x86 server it took 1s and 30s respectively.
> 

Re: [Pkgutil-users] pkgutil package install/available mismatch

[Peter B. <bon...@op...>]

On Wed, Jun 10, 2009 at 4:50 AM, Rob Ruma <rr...@fa...> wrote:
> Hi Peter,
>        After doing more testing with pkgutil as a package provider for puppet,
> I've discovered that using the true package name to call packages works
> just fine. Although, I have noticed that manifests referencing many
> packages does take considerably longer to process compared to pkg-get.

Do you mean when there are many dependencies?

When pkg-get installs it doesn't check dependencies at all, it just
downloads the requested package, unpacks it and then check if there
are dependencies to add, this repeats recursively.

It's of course faster not to do something than doing it but normally
download and install is like 90-99% of the time spent.

I just tried with Firefox on a 10 year old Sparc and it calculated the
dependencies in 2 seconds. Gnome, however, took 2 minutes. On a
relatively modern x86 server it took 1s and 30s respectively.

-- 
/peter

Re: [Pkgutil-users] pkgutil package install/available mismatch

[Rob R. <rr...@fa...>]

Hi Peter,
	After doing more testing with pkgutil as a package provider for puppet,
I've discovered that using the true package name to call packages works
just fine. Although, I have noticed that manifests referencing many
packages does take considerably longer to process compared to pkg-get.

Rob Ruma
Harvard University
Faculty of Arts and Sciences (FAS)
UNIX IT Systems

Rob Ruma wrote:
> Peter,
> 	Thanks for the quick response. I didn't look at the code before I sent
> my last email so I should of mentioned that I have noncsw set to true in
> pkgutil.conf so the if statement in "sub compare" uses the full output
> of `pkginfo` for the array.
> 
> I discovered this issue while using pkgutil as a package provider for
> puppet so if I don't call packages as they are exactly named in the
> repo, the package reference fails and reinstalls the package continuously.
> 
> Here is an example of another package that doesn't report correctly:
> 
> system      CSWgfile                         fileutils - GNU file utilities
> 
> It will be useful if a new option to pkgutil is created to do more exact
> compares between the repo and whats installed.
> 
> Again, thanks for the response, please keep up the great work on this
> project!
> 
> Rob Ruma
> Harvard University
> Faculty of Arts and Sciences (FAS)
> UNIX IT Systems
> 
> Peter Bonivart wrote:
>> On Mon, Jun 8, 2009 at 9:21 PM, Rob Ruma<rr...@fa...> wrote:
>>> This could be a possible bug. pkgutil doesn't report if a package is
>>> installed if the name of the CSW package doesn't match what it goes by
>>> from the repo.
>> Since both compare options (c/C) list package names and not catalog
>> names, that is what you should provide on the command line. Think of
>> it as piping to grep.
>>
>>> [root@sun]# pkgutil -c pkg_update_watch
>>> package                   installed                 catalog
>> This would have worked if you had specified pkgupdatewatch.
>>
>>> [root@sun]# pkgutil -C pkg_update_watch
>>> package                   installed                 catalog
>> Even if this matched it would only have shown something if installed
>> version didn't match catalog version.
>>
>>> [root@sun]# pkgutil -a pkg_update_watch
>>> pkg_update_watch     CSWpkgupdatewatch    1.0,REV=2007.04.10
>>> 4.0 KB
>> Here it works using catalog name since output contains both package
>> and catalog names. Again, think of it as a grep.
>>
>> Actually, all internal work in pkgutil is done with package names.
>> When you, for example, use catalog names to install something a lookup
>> has to be done for every one so you lose a few milliseconds. :-) For
>> this to work I guess I would have to do lookups here as well. Do you
>> think that would be better?
>>
>> I could try to fix that if you want it.
>>
> 

Re: [Pkgutil-users] pkgutil package install/available mismatch

[Rob R. <rr...@fa...>]

Peter,
	Thanks for the quick response. I didn't look at the code before I sent
my last email so I should of mentioned that I have noncsw set to true in
pkgutil.conf so the if statement in "sub compare" uses the full output
of `pkginfo` for the array.

I discovered this issue while using pkgutil as a package provider for
puppet so if I don't call packages as they are exactly named in the
repo, the package reference fails and reinstalls the package continuously.

Here is an example of another package that doesn't report correctly:

system      CSWgfile                         fileutils - GNU file utilities

It will be useful if a new option to pkgutil is created to do more exact
compares between the repo and whats installed.

Again, thanks for the response, please keep up the great work on this
project!

Rob Ruma
Harvard University
Faculty of Arts and Sciences (FAS)
UNIX IT Systems

Peter Bonivart wrote:
> On Mon, Jun 8, 2009 at 9:21 PM, Rob Ruma<rr...@fa...> wrote:
>> This could be a possible bug. pkgutil doesn't report if a package is
>> installed if the name of the CSW package doesn't match what it goes by
>> from the repo.
> 
> Since both compare options (c/C) list package names and not catalog
> names, that is what you should provide on the command line. Think of
> it as piping to grep.
> 
>> [root@sun]# pkgutil -c pkg_update_watch
>> package                   installed                 catalog
> 
> This would have worked if you had specified pkgupdatewatch.
> 
>> [root@sun]# pkgutil -C pkg_update_watch
>> package                   installed                 catalog
> 
> Even if this matched it would only have shown something if installed
> version didn't match catalog version.
> 
>> [root@sun]# pkgutil -a pkg_update_watch
>> pkg_update_watch     CSWpkgupdatewatch    1.0,REV=2007.04.10
>> 4.0 KB
> 
> Here it works using catalog name since output contains both package
> and catalog names. Again, think of it as a grep.
> 
> Actually, all internal work in pkgutil is done with package names.
> When you, for example, use catalog names to install something a lookup
> has to be done for every one so you lose a few milliseconds. :-) For
> this to work I guess I would have to do lookups here as well. Do you
> think that would be better?
> 
> I could try to fix that if you want it.
> 

Re: [Pkgutil-users] RFE: pkgutil 1.6 needs to insert a CR

[Peter B. <bon...@bl...>]

On Mon, Jun 8, 2009 at 7:06 PM, Dennis Clarke<dc...@bl...> wrote:
>
> Here is a example of current output :
>
> ...
>
> Not very easy to read.
>
> Perhaps we could have a CR at the end of every pkgname ?

I agree, it got worse with 1.5 which added the version number. On the
other hand, I'm kind of old school and still do some work with old
VT100 consoles which doesn't have scrollback so saving lines is
important. Maybe no one else ever use this?

A compromise would be to use tabs instead of spaces, that should raise
readability without using lots of lines. I could try that in the next
beta and see what you think.

-- 
/peter

Re: [Pkgutil-users] pkgutil package install/available mismatch

[Peter B. <bon...@op...>]

On Mon, Jun 8, 2009 at 9:21 PM, Rob Ruma<rr...@fa...> wrote:
> This could be a possible bug. pkgutil doesn't report if a package is
> installed if the name of the CSW package doesn't match what it goes by
> from the repo.

Since both compare options (c/C) list package names and not catalog
names, that is what you should provide on the command line. Think of
it as piping to grep.

> [root@sun]# pkgutil -c pkg_update_watch
> package                   installed                 catalog

This would have worked if you had specified pkgupdatewatch.

> [root@sun]# pkgutil -C pkg_update_watch
> package                   installed                 catalog

Even if this matched it would only have shown something if installed
version didn't match catalog version.

> [root@sun]# pkgutil -a pkg_update_watch
> pkg_update_watch     CSWpkgupdatewatch    1.0,REV=2007.04.10
> 4.0 KB

Here it works using catalog name since output contains both package
and catalog names. Again, think of it as a grep.

Actually, all internal work in pkgutil is done with package names.
When you, for example, use catalog names to install something a lookup
has to be done for every one so you lose a few milliseconds. :-) For
this to work I guess I would have to do lookups here as well. Do you
think that would be better?

I could try to fix that if you want it.

-- 
/peter

[Pkgutil-users] pkgutil package install/available mismatch

[Rob R. <rr...@fa...>]

This could be a possible bug. pkgutil doesn't report if a package is
installed if the name of the CSW package doesn't match what it goes by
from the repo.

Here is a case I ran into today.

[root@sun]# pkgutil -c pkg_update_watch
package                   installed                 catalog
[root@sun]# pkgutil -C pkg_update_watch
package                   installed                 catalog
[root@sun]# pkgutil -a pkg_update_watch
pkg_update_watch     CSWpkgupdatewatch    1.0,REV=2007.04.10
4.0 KB
[root@sun]# pkginfo CSWpkgupdatewatch
application CSWpkgupdatewatch pkg_update_watch - Package updates watcher
[root@sun]# pkgutil -v
1.6.1

-- 

Rob Ruma
Harvard University
Faculty of Arts and Sciences (FAS)
UNIX IT Systems

[Pkgutil-users] RFE: pkgutil 1.6 needs to insert a CR

[Dennis C. <dc...@bl...>]

Here is a example of current output :

# /opt/csw/bin/pkgutil --install CSWeasytag CSWaspell
Checking catalog integrity with gpg.
gpg: Signature made Sat May 30 21:00:22 2009 GMT using DSA key ID A1999E90
gpg: Good signature from "Blastwave Software (Blastwave.org Inc.)
<sof...@bl...>"
Parsing catalog, may take a while...
New packages: CSWftype2-2.1.10,REV=2005.12.11 CSWgpgerr-1.6
CSWlibx11-1.1.5,REV=2008.11.17 CSWpng-1.2.29,REV=2008.05.08
CSWpixman-0.12.0,REV=2008.11.15 CSWfconfig-2.3.2,REV=2005.11.04
CSWgcrypt-1.4.1,REV=2008.05.27 CSWlibxrender-0.9.4,REV=2008.11.17
CSWlibxdmcp-1.0.2,REV=2008.11.16 CSWlibxau-1.0.4,REV=2008.11.17
CSWjpeg-6b,REV=2007.10.28 CSWopencdk-0.6.6 CSWgcc3corert-3.4.5
CSWlibxft2-2.1.6,REV=2005.02.01 CSWlibxcb-1.1,REV=2008.11.16
CSWlibcairo-1.8.4,REV=2008.11.27 CSWglib2-2.18.3,REV=2008.11.26
CSWtiff-3.8.2,REV=2007.12.09 CSWgnutls-2.0.4
CSWlibogg-1.1.3,REV=2009.02.21 CSWgcc3g++rt-3.4.5
CSWpango-1.22.3,REV=2008.11.11 CSWlibcups-1.3.10,REV=2009.04.20
CSWlibatk-1.24.0,REV=2008.11.11 CSWjasper-1.701.0,REV=2004.08.30
CSWvorbis-1.2.0,REV=2008.12.07 CSWspeex-1.0.5
CSWlibid3tag-0.15.1,REV=2004.04.12.01_rev=b CSWid3lib-3.8.3,REV=2008.06.04
CSWgtk2-2.14.5,REV=2008.11.26 CSWflac-1.1.2
CSWaspell-0.60.6,REV=2009.04.13 CSWeasytag-2.1.5,REV=2008.02.07
Current packages: CSWcommon-1.4.6,REV=2008.04.28
CSWstl4-11.0,REV=2005.10.13 CSWiconv-1.13,REV=2009.05.26
CSWzlib-1.2.3,REV=2007.05.12 CSWggettext-0.17,REV=2009.05.27
CSWexpat-2.0.1,REV=2009.05.27 CSWisaexec-0.1 CSWncurses-5.7,REV=2009.05.30
CSWsunmath-2007.08.04 CSWreadline-5.2,REV=2009.05.19
CSWgcc4corert-4.3.3,REV=2009.04.10 CSWgcc4g++rt-4.3.3,REV=2009.04.17
Total size: 30.4 MB
33 packages to fetch. Do you want to continue? [Y,n] n
#

Not very easy to read.

Perhaps we could have a CR at the end of every pkgname ?

Like so :

# /opt/csw/bin/pkgutil --install CSWeasytag CSWaspell
Checking catalog integrity with gpg.
gpg: Signature made Sat May 30 21:00:22 2009 GMT using DSA key ID A1999E90
gpg: Good signature from "Blastwave Software (Blastwave.org Inc.)
<sof...@bl...>"
Parsing catalog, may take a while...
New packages:
CSWftype2-2.1.10,REV=2005.12.11
CSWgpgerr-1.6
CSWlibx11-1.1.5,REV=2008.11.17
CSWpng-1.2.29,REV=2008.05.08
CSWpixman-0.12.0,REV=2008.11.15
CSWfconfig-2.3.2,REV=2005.11.04
CSWgcrypt-1.4.1,REV=2008.05.27
CSWlibxrender-0.9.4,REV=2008.11.17
CSWlibxdmcp-1.0.2,REV=2008.11.16
CSWlibxau-1.0.4,REV=2008.11.17
CSWjpeg-6b,REV=2007.10.28
CSWopencdk-0.6.6
CSWgcc3corert-3.4.5
CSWlibxft2-2.1.6,REV=2005.02.01
CSWlibxcb-1.1,REV=2008.11.16
CSWlibcairo-1.8.4,REV=2008.11.27
CSWglib2-2.18.3,REV=2008.11.26
CSWtiff-3.8.2,REV=2007.12.09
CSWgnutls-2.0.4
CSWlibogg-1.1.3,REV=2009.02.21
CSWgcc3g++rt-3.4.5
CSWpango-1.22.3,REV=2008.11.11
CSWlibcups-1.3.10,REV=2009.04.20
CSWlibatk-1.24.0,REV=2008.11.11
CSWjasper-1.701.0,REV=2004.08.30
CSWvorbis-1.2.0,REV=2008.12.07
CSWspeex-1.0.5
CSWlibid3tag-0.15.1,REV=2004.04.12.01_rev=b
CSWid3lib-3.8.3,REV=2008.06.04
CSWgtk2-2.14.5,REV=2008.11.26
CSWflac-1.1.2
CSWaspell-0.60.6,REV=2009.04.13
CSWeasytag-2.1.5,REV=2008.02.07

Current packages:
CSWcommon-1.4.6,REV=2008.04.28
CSWstl4-11.0,REV=2005.10.13
CSWiconv-1.13,REV=2009.05.26
CSWzlib-1.2.3,REV=2007.05.12
CSWggettext-0.17,REV=2009.05.27
CSWexpat-2.0.1,REV=2009.05.27
CSWisaexec-0.1
CSWncurses-5.7,REV=2009.05.30
CSWsunmath-2007.08.04
CSWreadline-5.2,REV=2009.05.19
CSWgcc4corert-4.3.3,REV=2009.04.10
CSWgcc4g++rt-4.3.3,REV=2009.04.17
Total size: 30.4 MB
33 packages to fetch. Do you want to continue? [Y,n] n

Perhaps even sort them also.

wdyt ?

-- 
Dennis Clarke

[Pkgutil-users] SF.net SVN: pkgutil:[61] tags/1.6.1/

[<bon...@us...>]

Revision: 61
          http://pkgutil.svn.sourceforge.net/pkgutil/?rev=61&view=rev
Author:   bonivart
Date:     2009-06-05 21:35:10 +0000 (Fri, 05 Jun 2009)

Log Message:
-----------
create tag for 1.6.1 release

Added Paths:
-----------
    tags/1.6.1/


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

[Pkgutil-users] SF.net SVN: pkgutil:[60] trunk/readme

[<bon...@us...>]

Revision: 60
          http://pkgutil.svn.sourceforge.net/pkgutil/?rev=60&view=rev
Author:   bonivart
Date:     2009-06-05 14:15:18 +0000 (Fri, 05 Jun 2009)

Log Message:
-----------
update readme

Modified Paths:
--------------
    trunk/readme


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

[Pkgutil-users] SF.net SVN: pkgutil:[59] trunk/pkgutil

[<bon...@us...>]

Revision: 59
          http://pkgutil.svn.sourceforge.net/pkgutil/?rev=59&view=rev
Author:   bonivart
Date:     2009-06-05 13:11:02 +0000 (Fri, 05 Jun 2009)

Log Message:
-----------
pkgutil: better fix for pkgutil upgrade problem (#3701)

Modified Paths:
--------------
    trunk/pkgutil


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Re: [Pkgutil-users] Install of gcc4core fails during postinstall script

[Peter B. <bon...@op...>]

On Thu, Jun 4, 2009 at 8:07 PM, Bob Washburne <rc...@ps...> wrote:
> 1) Does pkgutil leave a log anywhere which I can check for errors?  I've
> looked around, but can't find one.

Not yet, I'm thinking about logging everything in a future release but
if you're using the latest pkgutil you can use the --trace option to
add debugging to all scripts during install/remove.

Check your pkgutil version with:

# pkgutil -v

If it's not 1.6 do:

# pkgutil -u pkgutil

Then try with --trace:

# pkgutil --trace -i gcc4core (or whatever the exact name is)

> 2) Where does the postinstall script live, so that I can look at it and
> see what it was trying to do.

See above.

> 3) Is gcc4core supposed to create links to /opt/csw/bin?  Or do people
> need to include /opt/csw/gcc4/... in their paths to use the compiler?

Since this is a problem with a Blastwave package other than pkgutil I
would recommend you posting on their forum:

http://wiki.blastwave.org/forum/

I'm sure they will help you further with why gcc4core fails.

-- 
/peter

[Pkgutil-users] Install of gcc4core fails during postinstall script

[Bob W. <rc...@ps...>]

Greetings!

I am relatively new to Blastwave, but I have tried to follow the 
instructions as best I could.

I am using an x86 based Sun Ultra 24.

I installed pkgutil and set up the md5/pgp keys as documented.

My second install (gnupg being the first) was then gcc4core.  It had two 
dependencies of binutils and gcc4corert which installed with no error.  
But the gcc4core failed due to an error in the postinstall script.  
There were no further details.

1) Does pkgutil leave a log anywhere which I can check for errors?  I've 
looked around, but can't find one.

2) Where does the postinstall script live, so that I can look at it and 
see what it was trying to do.

3) Is gcc4core supposed to create links to /opt/csw/bin?  Or do people 
need to include /opt/csw/gcc4/... in their paths to use the compiler?

4) Is anyone else having these problems?

Thanks in advance!

-- 
Bob Washburne
Penn State Harrisburg
E302 Olmsted Building
777 West Harrisburg Pike
Middletown, PA 17057-4898
717-948-6436

[Pkgutil-users] SF.net SVN: pkgutil:[58] trunk/readme

[<bon...@us...>]

Revision: 58
          http://pkgutil.svn.sourceforge.net/pkgutil/?rev=58&view=rev
Author:   bonivart
Date:     2009-06-04 16:11:20 +0000 (Thu, 04 Jun 2009)

Log Message:
-----------
update readme

Modified Paths:
--------------
    trunk/readme


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

[Pkgutil-users] SF.net SVN: pkgutil:[57] trunk/pkgutil

[<bon...@us...>]

Revision: 57
          http://pkgutil.svn.sourceforge.net/pkgutil/?rev=57&view=rev
Author:   bonivart
Date:     2009-06-04 15:50:44 +0000 (Thu, 04 Jun 2009)

Log Message:
-----------
pkgutil: change RE, add debug info (#3702)

Modified Paths:
--------------
    trunk/pkgutil


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

[Pkgutil-users] SF.net SVN: pkgutil:[56] trunk/pkgutil

[<bon...@us...>]

Revision: 56
          http://pkgutil.svn.sourceforge.net/pkgutil/?rev=56&view=rev
Author:   bonivart
Date:     2009-06-04 15:38:32 +0000 (Thu, 04 Jun 2009)

Log Message:
-----------
pkgutil: fix order of installs (#3702)

Modified Paths:
--------------
    trunk/pkgutil


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

[Pkgutil-users] SF.net SVN: pkgutil:[55] trunk/pkgutil

[<bon...@us...>]

Revision: 55
          http://pkgutil.svn.sourceforge.net/pkgutil/?rev=55&view=rev
Author:   bonivart
Date:     2009-06-01 14:48:28 +0000 (Mon, 01 Jun 2009)

Log Message:
-----------
pkgutil: disable -y when upgrading pkgutil (#3701)

Modified Paths:
--------------
    trunk/pkgutil


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

[Pkgutil-users] SF.net SVN: pkgutil:[54] tags/1.6/

[<bon...@us...>]

Revision: 54
          http://pkgutil.svn.sourceforge.net/pkgutil/?rev=54&view=rev
Author:   bonivart
Date:     2009-05-30 13:12:56 +0000 (Sat, 30 May 2009)

Log Message:
-----------
create tag for 1.6 release

Added Paths:
-----------
    tags/1.6/


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

[Pkgutil-users] having problems with bldcat from 1.6

[Don J. <pkg...@cl...>]

I found the problem, and it had nothing to do with bldcat.  I'm sorry  
for the bogus report and the noise.

Apologies to all.

=======

Upgraded to 1.6 today, I am using the blastwave.org version I believe

# /opt/csw/bin/pkgutil --v
1.6

# cat  /opt/csw/bin/bldcat | head -20
#!/opt/csw/bin/perl -w

# bldcat - build a CSW catalog from packages in a directory
# Copyright (C) 2008-2009 Peter Bonivart

# $Id: bldcat 40 2009-05-04 12:43:19Z bonivart $

If I don't manually create a subdirectory for the catalog, I got this:

# /opt/csw/bin/bldcat catalog
Could not write new catalog at catalog/catalog.new: Not a directory  
at /opt/csw/bin/bldcat line 44.

Then I created ./catalog

# mkdir catalog
# /opt/csw/bin/bldcat catalog
# ls -lt
total 220
drwxr-xr-x   2 root     root           4 May 29 18:11 catalog

# cd catalog

# ls -lAF
total 2
-rw-r--r--   1 root     root           0 May 29 18:11 catalog
-rw-r--r--   1 root     root           0 May 29 18:11 descriptions

What am I doing wrong?

[Pkgutil-users] having problems with bldcat from 1.6

[Don J. <pkg...@cl...>]

Upgraded to 1.6 today, I am using the blastwave.org version I believe

# /opt/csw/bin/pkgutil --v
1.6

# cat  /opt/csw/bin/bldcat | head -20
#!/opt/csw/bin/perl -w

# bldcat - build a CSW catalog from packages in a directory
# Copyright (C) 2008-2009 Peter Bonivart

# $Id: bldcat 40 2009-05-04 12:43:19Z bonivart $

If I don't manually create a subdirectory for the catalog, I got this:

# /opt/csw/bin/bldcat catalog
Could not write new catalog at catalog/catalog.new: Not a directory  
at /opt/csw/bin/bldcat line 44.

Then I created ./catalog

# mkdir catalog
# /opt/csw/bin/bldcat catalog
# ls -lt
total 220
drwxr-xr-x   2 root     root           4 May 29 18:11 catalog

# cd catalog

# ls -lAF
total 2
-rw-r--r--   1 root     root           0 May 29 18:11 catalog
-rw-r--r--   1 root     root           0 May 29 18:11 descriptions

What am I doing wrong?

[Pkgutil-users] Version 1.6 released

[Peter B. <bon...@op...>]

The new version 1.6 of pkgutil is spreading across the mirrors right now.

One new feature is -C which finally rids you of having to filter out
all lines with "SAME" when doing compares. There's also an easy way of
tracing all scripts during pkgadd/pkgrm operations, this is good when
you have local problems and the package maintainer wants debugging
info, now you don't have to download and install the package manually
any more. You can also use a custom configuration file instead of the
normal ones, this can be useful if you sometimes use different
settings, like another mirror for jumpstart for example, just save
your settings in a file and call that file with --config=file. Bldcat
and chkcat are also improved.

Change log:

  - Fix -T bug (#3689)
  - Fix -W bug (#3688)
  - New option -C, same as -c but only shows different versions, no
more piping to grep -v SAME (Ben Walton)
  - New option --trace to debug pkgadd/pkgrm operations (#3683) (Yann Rouillard)
  - Replaced some system commands with native Perl
  - New option --config for using custom configuration file (Don Jackson)
  - Fix size formatting
  - Skip showing pkgadd patch when using -V on 5.11 (Dennis Clarke)
  - Update credits in perldoc/man page
  - Perldoc/man page added to both bldcat and chkcat
  - Chkcat now includes more tests (Derek Whayman)
  - Chkcat exit values are 0 for OK, 1 for warning and 2 for error
  - New option -e (erroronly) added to chkcat to supress warnings
  - New option -q (quiet) added to chkcat to supress all output

I also want to say that I had a big feature contributed for this
release but I had to postpone that to get other, smaller, features out
in time instead.

http://pkgutil.wikidot.com/

-- 
/peter