On Mon, 26 Nov 2007, Roman Kyrylych wrote:
> 2007/11/26, Scott Horowitz <[EMAIL PROTECTED]>:
>> Okay, here's a much improved version of the script. By default, it
>> will do fresh cvs checkouts of all archs (i.e. i686 and x86_64), so
>> I'd strongly recommend looking at the --help screen if that's
On Nov 26, 2007 4:22 AM, Roman Kyrylych <[EMAIL PROTECTED]> wrote:
> > coreutils>pam>db>coreutils
> this is already fixed in CVS HEAD
> Doesn't this script doesn't check that?
No, it checks the CURRENT/CURRENT-64 tags only, the same as if a user
was running abs and using the pkgbuilds. Using cvs h
2007/11/26, Scott Horowitz <[EMAIL PROTECTED]>:
> Okay, here's a much improved version of the script. By default, it
> will do fresh cvs checkouts of all archs (i.e. i686 and x86_64), so
> I'd strongly recommend looking at the --help screen if that's not what
> you want. You can point it at an exis
On Nov 26, 2007 1:49 AM, Scott Horowitz <[EMAIL PROTECTED]> wrote:
> Okay, here's a much improved version of the script. By default, it
> will do fresh cvs checkouts of all archs (i.e. i686 and x86_64), so
> I'd strongly recommend looking at the --help screen if that's not what
> you want. You can
Okay, here's a much improved version of the script. By default, it
will do fresh cvs checkouts of all archs (i.e. i686 and x86_64), so
I'd strongly recommend looking at the --help screen if that's not what
you want. You can point it at an existing abs tree instead if you
wish.
Changes:
- Better ac
On Sun, 18 Nov 2007, Scott Horowitz wrote:
> On Nov 17, 2007 11:54 PM, Eric Belanger <[EMAIL PROTECTED]> wrote:
>> but without formatting
>> and not taking in account the fact that the package version can be
>> different for the 2 archtectures (because of arch specific bug).
>
> I'm not sure what
On Nov 17, 2007 11:54 PM, Eric Belanger <[EMAIL PROTECTED]> wrote:
> but without formatting
> and not taking in account the fact that the package version can be
> different for the 2 archtectures (because of arch specific bug).
I'm not sure what you're referring to here. Can you elaborate?
I simp
2007/11/18, Xavier <[EMAIL PROTECTED]>:
> On Sun, Nov 18, 2007 at 11:42:11AM +0200, Roman Kyrylych wrote:
> > Huh?
> > gcc-libs doesn't depend on gcc
> > python doesn't depend on tk
> > I guess makedepends were counted here, which is wrong.
> >
>
> Ah indeed, the script doesn't make any distinction
On Sun, Nov 18, 2007 at 11:42:11AM +0200, Roman Kyrylych wrote:
> Huh?
> gcc-libs doesn't depend on gcc
> python doesn't depend on tk
> I guess makedepends were counted here, which is wrong.
>
Ah indeed, the script doesn't make any distinction between makedepends and
depends. It probably should j
2007/11/18, Scott Horowitz <[EMAIL PROTECTED]>:
> I posted this script to the pacman-dev list last time, but thought
> maybe it should go here instead. It essentially looks for a number of
> problems with Arch PKGBUILDs, repos, etc. Since the previous posting,
> it now checks for a number of additi
On Sat, 17 Nov 2007, Scott Horowitz wrote:
> I posted this script to the pacman-dev list last time, but thought
> maybe it should go here instead. It essentially looks for a number of
> problems with Arch PKGBUILDs, repos, etc. Since the previous posting,
> it now checks for a number of additional
I posted this script to the pacman-dev list last time, but thought
maybe it should go here instead. It essentially looks for a number of
problems with Arch PKGBUILDs, repos, etc. Since the previous posting,
it now checks for a number of additional things including if a
PKGBUILD's dependency provisi
12 matches
Mail list logo
