Re: [arch-dev-public] migrate libusb1 to libusb and add libusb-compat to [core]

2010-11-29 Thread Jan de Groot
On Sun, 2010-11-28 at 17:16 +0100, Tobias Powalowski wrote:
 - libusb1 is the successor of libusb 0.1.x
 - Jan moved this lib into extra in order to allow to build packages wich need 
 libusb 1.x
 - Now some programs still need libusb 0.1.x functions. The upstream 
 developers 
 created a wrapper for this called libusb-compat
 
 The plan is to replace the old unmaintained libusb 0.1.x with the new 
 maintained one.
 
 The libusb1 package will die and will be replaced by the libusb package which 
 moves to 1.x series.
 
 A new package libusb-compat will be created which support old programs that 
 are not yet libusb 1.x ready.
 All packages which still need the old functions should be rebuilt against 
 libusb-compat.
 
 Hope this clears some things.
 greetings
 tpowa

Life would be so much easier if we wouldn't mess so much. Why didn't we
choose for the easy solution?

libusb1 (extra) - libusb1 (core). No rebuilds required
libusb (core) - libusb-compat (core). Some replaces/provides/conflicts
and we're done.



Re: [arch-dev-public] migrate libusb1 to libusb and add libusb-compat to [core]

2010-11-29 Thread Allan McRae

On 29/11/10 18:25, Jan de Groot wrote:

On Sun, 2010-11-28 at 17:16 +0100, Tobias Powalowski wrote:

- libusb1 is the successor of libusb 0.1.x
- Jan moved this lib into extra in order to allow to build packages wich need
libusb 1.x
- Now some programs still need libusb 0.1.x functions. The upstream developers
created a wrapper for this called libusb-compat

The plan is to replace the old unmaintained libusb 0.1.x with the new
maintained one.

The libusb1 package will die and will be replaced by the libusb package which
moves to 1.x series.

A new package libusb-compat will be created which support old programs that
are not yet libusb 1.x ready.
All packages which still need the old functions should be rebuilt against
libusb-compat.

Hope this clears some things.
greetings
tpowa


Life would be so much easier if we wouldn't mess so much. Why didn't we
choose for the easy solution?

libusb1 (extra) -  libusb1 (core). No rebuilds required
libusb (core) -  libusb-compat (core). Some replaces/provides/conflicts
and we're done.



Because libusb1 is an ugly package name compared to libusb...  We do not 
tend to add version numbers in package names for other libraries and the 
rebuild is fairly minimal.


Allan


Re: [arch-dev-public] migrate libusb1 to libusb and add libusb-compat to [core]

2010-11-29 Thread Allan McRae

The rebuild is complete and moved to [testing]/[community-testing].

Note that some packages in the TODO list were excessive as the 
dependency update was handled further down the dependency chain. So do 
not be concerned if a package you though needed rebuilt is not there... 
  unless of course it should really have been there, in which case file 
a bug!


I'll leave the signoff email to Tobias P given he did the builds for [core].

Allan


[arch-dev-public] [signoff] lilo 23.1-2

2010-11-29 Thread Andrea Scarpino
from lilo 23.1-1
- upstream release
- new url
- updated source
- use package() function
- updated make options
- rebuilt to switch to tar.xz

lilo 23.1-2
- fixed source
- added sharutils as new makedependence
- added perl as optdependence to run keytab-lilo

lilo 23.1-1 was without signoff, please signoff lilo 23.1-2 for both arches

-- 
Andrea Scarpino
Arch Linux Developer


[arch-dev-public] [signoff] nano 2.2.6-1

2010-11-29 Thread Andreas Radke
The 2.2.5-2 build with fixed deps didn't move to core. Maybe because an
i686 signoff was missing.

A new release is out. Please sign off now both arches.

-Andy

2010.11.22 - GNU nano 2.2.6 Pimp my BBS wants you to go to 
www.desertbus.org and donate a few bucks for the great 
Child's Play Charity!  This is just a small release to 
update a bug where restricted mode was not particularly 
restricted since key bindings were introduced. It also 
signals the return of win32 builds which now feature 
nanorc support; please see the FAQ for details of how
to enable it, this feature is a bit of a kludge for
now. Remember that when all else fails, USE SPACE JUMP.


Re: [arch-dev-public] [signoff] nano 2.2.6-1

2010-11-29 Thread Guillaume ALAUX
On Mon, 2010-11-29 at 20:33 +0100, Andreas Radke wrote:
 The 2.2.5-2 build with fixed deps didn't move to core. Maybe because an
 i686 signoff was missing.
 
 A new release is out. Please sign off now both arches.
 
 -Andy
 
 2010.11.22 - GNU nano 2.2.6 Pimp my BBS wants you to go to 
   www.desertbus.org and donate a few bucks for the great 
   Child's Play Charity!  This is just a small release to 
   update a bug where restricted mode was not particularly 
   restricted since key bindings were introduced. It also 
   signals the return of win32 builds which now feature 
   nanorc support; please see the FAQ for details of how
   to enable it, this feature is a bit of a kludge for
   now. Remember that when all else fails, USE SPACE JUMP.

Basic things work here.

Signoff x86_64

-- 
Guillaume


signature.asc
Description: This is a digitally signed message part


Re: [arch-dev-public] [signoff] usbutils-0.91-2

2010-11-29 Thread Guillaume ALAUX
On Sun, 2010-11-28 at 14:24 +0100, Tobias Powalowski wrote:
 Hi guys,
 fixed depend to correct libusb1
 please signoff both arches
 
 greetings
 tpowa

I see the -3 (instead of -2 you are mentionning) in testing. So I can
signoff x86_64 for this -3 !
-- 
Guillaume


signature.asc
Description: This is a digitally signed message part


Re: [arch-dev-public] [signoff] nano 2.2.6-1

2010-11-29 Thread Eric Bélanger
On Mon, Nov 29, 2010 at 3:30 PM, Guillaume ALAUX
guilla...@archlinux.org wrote:
 On Mon, 2010-11-29 at 20:33 +0100, Andreas Radke wrote:
 The 2.2.5-2 build with fixed deps didn't move to core. Maybe because an
 i686 signoff was missing.

 A new release is out. Please sign off now both arches.

 -Andy

 2010.11.22 - GNU nano 2.2.6 Pimp my BBS wants you to go to
               www.desertbus.org and donate a few bucks for the great
               Child's Play Charity!  This is just a small release to
               update a bug where restricted mode was not particularly
               restricted since key bindings were introduced. It also
               signals the return of win32 builds which now feature
               nanorc support; please see the FAQ for details of how
               to enable it, this feature is a bit of a kludge for
               now. Remember that when all else fails, USE SPACE JUMP.

 Basic things work here.

 Signoff x86_64

 --
 Guillaume


signoff i686