Re: demoting a dependency

On Mar 31, Steve Langasek <vorlon <at> debian.org> wrote:

> libkrb5 is also Priority: standard these days, so is it really necessary to
> try that hard, anyway?
Thanks to symbol dependencies this removed the need for backports.

--

-- 
ciao,
Marco

Re: why is Ardour pretty outdated in stable and not in testing?

Grammostola Rosea wrote:

>>
>> http://release.debian.org/migration/testing.pl?package=ardour
>>   
> So this should be fixed, wait till it hit testing and then make an
> backport?

Yes. That's the best way to go.

--

-- 
 Bernd Zeimetz                           Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79

Bug#522135: ITP: python-pip -- Alternative Python package installer

Package: wnpp
Severity: wishlist
Owner: Jeff Licquia <licquia <at> debian.org>

* Package name    : python-pip
  Version         : 0.3.1
  Upstream Author : Ian Bicking
* URL             : http://pip.openplans.org/
* License         : MIT/X
  Programming Lang: Python
  Description     : Alternative Python package installer

This is Ian Bicking's easy_install replacement.  It integrates with 
virtualenv, and does a number of things better.

The package is pretty much done and is being tested.  If you're 
impatient, my bzr repository should be here soon:

http://bzr.licquia.org/pip/debian

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Major Vendors and FSF Announce Instigation of Cloud Alliance and New Open Source License

Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)

[...]
> 
> I'm unsure why we need *any* 32-bit libraries or binaries on an
> amd64 system.  If one needs to run 32-bit software, it is possible to
> debootstrap an i386 system and use it as a chroot.  Using a tool such
> as schroot handles all of the kernel personality and chroot details,
> and even allows normal users to use it with access to all their files,
> etc.  With a few one line scripts/shell aliases, it's completely
> transparent.  It also has the advantage of being a complete i386
> system rather than just a collection of libraries; you can keep it up
> to date using the usual tools, and even boot it if you desire.  i.e.
> you get all the normal security support and updates.
> 
> With multiarch, it's a different story, but we aren't quite there yet.
> 

My main use of 32-bit libraries is commercial software that is available for
32bit systems only. Yes, that's bad, but I can't do anything about that ATM. I'd
really hate to run (and maintain!) an additional chroot on each of those servers
just to run a single application. I do have i386 schroots on other systems, but
I prefer not to maintain that on each and every server. It might actually be a
bit of problem, because one of those commercial products is our backup
software...

Best,
Michael

Bug#522142: ITP: Qoreutils -- Coreutils reimplemented using Qt libraries

Package: wnpp
Severity: wishlist
Owner: Sune Vuorela <reportbug <at> pusling.com>

* Package name    : Qoreutils
  Version         : 1.0.0
  Upstream Author : John Doe <john <at> qoreutils.org>
* URL             : http://www.qoreutils.org/
* License         : GPL
  Programming Lang: C++ with Qt
  Description     : Coreutils reimplemented using Qt libraries

Qoreutils is a reimplementation of the classic tools from coreutils,
such as ls, mkdir and cp

I'm packaging this on behalf of the Debian Qt/KDE maintainers as a first
step towards making the Qt libraries Essential: yes and on the way to
take over the world.

Currently, the package will dpkg-divert all the implemented tools of
coreutils to shake out any remaining bugs and if any bugs found,  the
user can fall back to command.coreutils as a last way out. Within the
next couple of months, it will instead have replace/conflict/provides
coreutils and slowly push out coreutils from the most users machines.

/Sune

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (200, 'experimental')
Architecture: i386 (i686)

Re: Transitions update: some done, some ready, some starting

Adeodato Simó wrote:

> We’ll be also
> doing some Bin-NMUs to get rid of dependencies on obsolete
> jack-audio-connection-kit transitional packages

Should we file bugs against packages for build-depending on the wrong package,
so that we can drop the Provides later? Or just let it be for the time being?

-- 

  Felipe Sateler

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org

Re: Transitions update: some done, some ready, some starting

Adeodato Simó wrote:

> We’ll be also
> doing some Bin-NMUs to get rid of dependencies on obsolete
> jack-audio-connection-kit transitional packages

Also, I think you can start the binNMUs now, since the shlibs file already point
to the libjack0 package.

-- 

  Felipe Sateler

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org

Bug#522151: ITP: calf -- High quality open source audio plugins for musicians

Package: wnpp
Severity: wishlist
Owner: Adrian Knoth <adi <at> drcomp.erfurt.thur.de>

* Package name    : calf
  Version         : 0.0.18.3
* URL             : http://calf.sf.net/
* License         : GPL
  Programming Lang: C++
  Description     : High quality open source audio plugins for musicians

(Include the long description here.)

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.28.7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Re: Transitions update: some done, some ready, some starting

> > We’ll be also
> > doing some Bin-NMUs to get rid of dependencies on obsolete
> > jack-audio-connection-kit transitional packages

> Should we file bugs against packages for build-depending on the wrong package,
> so that we can drop the Provides later? Or just let it be for the time being?

You will need to file bugs at RC severity against jackbeat and
gst-plugins-bad0.10 ASAP, as I already mentioned in the previous mail.

For the rest, feel free to file bugs at minor severity; you’ll probably
want to usertag them, and to include a mention that libjack-dev is in
Lenny already. When there are no packages left in testing build-depending
on the old name, you can drop the provides.

> Also, I think you can start the binNMUs now, since the shlibs file already point
> to the libjack0 package.

Yes, I just need to find a bit of time to do it. I’ll get back to you
once I’ve scheduled them, so that you can track failures, etc.

-- 
- Are you sure we're good?
- Always.
        -- Rory and Lorelai

--

-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org