Bug#683247: Bug#683030: unblock: vlc/2.0.3-1

2012-08-04 Thread Reinhard Tartler
tags 683247 -moreinfo
retitle 683247 unblock libav_6:0.8.3-6
stop

On Mon, Jul 30, 2012 at 2:17 PM, Adam D. Barratt
a...@adam-barratt.org.uk wrote:
 On 30.07.2012 08:08, Reinhard Tartler wrote:

 I intend to work on a new upload that incorporates your suggestions
 for clarifying the debian/changelog file this week. If you don't mind,
 I'd leave the doxygen and the Provides: ffmpeg changes as-is.
 Additionally, I intend to change ffmpeg-dbg from Arch: any to arch:
 all for consistency with libav-extra-dbg (both are empty, transitional
  packages).


 That sounds fine to me; thanks.  Please let us know (and retitle the libav
 unblock bug appropriately) once that's been done.

I'm doing so with this email. Please consider adjusting the time that
is required for migration.

Please also note that in additional to the above, I've also included a
fix for bug #679542, which prevents the migration of the vlc package.
AFAIUI, if vlc would be rebuild against this new version of libav
(e.g., by scheduling binNMUs), Britney should let vlc migrate
independently of libav. But that might be just a waste of ressources,
so your call.

-- 
regards,
Reinhard


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#683247: Bug#683030: unblock: vlc/2.0.3-1

2012-08-01 Thread Stepan Golosunov
01.08.2012 в 09:45:12 +0100 Adam D. Barratt написал:
 On 01.08.2012 09:14, Fabian Greffrath wrote:
 So, will libav 6:0.8.3-5 get unblocked or should we request this
 separately?
 
 The libav discussion moved to (the cloned) #683247, where Reinhard
 said he was going to upload -6.  That bug also contains some
 discussion which suggests the previous m-a:foreign changes were
 incorrect.  In any case, let's move the discussion there, please.
 :-)

These multi-arch changes were correct (the packages cannot be
Multi-Arch: foreign because they provide architecture-specific
interface) but not ideal (architecture-specific packages should not be
Architecture: all). And problems created by this non-ideality are
mitigated by general uselessness of the packages (they are intented to
transition packages which were never in stable).

Also, multi-arch changes were described correctly in the changelog
before
http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=commitdiff;h=677532340a55be1e0974de241f06aa605e2be083
The architecture change of libav-extra-dbg (with libav-regular-dbg
forgotten again) was in fact related to #680602, not #680613. And it
also creates architecture-dependent Architecture: all package
problems. Which are again mitigated by uselessness of the package
(it is not only intended to transition from package not found in
stable, but also does not have reverse dependencies).


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#683247: Bug#683030: unblock: vlc/2.0.3-1

2012-07-30 Thread Julien Cristau
On Mon, Jul 30, 2012 at 09:08:50 +0200, Reinhard Tartler wrote:

 AFAIUI the multi-arch spec, arch:all packages are not allowed to
 specify Multi-Arch: foreign, so I had the impression that this part
 was rather obvious to multi-arch experts. Which I am clearly not, so
 being more explicit in the changelog is very much warrented.

That is not true, there's lots of arch:all m-a:foreign packages.

Cheers,
Julien


signature.asc
Description: Digital signature


Bug#683247: Bug#683030: unblock: vlc/2.0.3-1

2012-07-30 Thread Russ Allbery
Julien Cristau jcris...@debian.org writes:
 On Mon, Jul 30, 2012 at 09:08:50 +0200, Reinhard Tartler wrote:

 AFAIUI the multi-arch spec, arch:all packages are not allowed to
 specify Multi-Arch: foreign, so I had the impression that this part
 was rather obvious to multi-arch experts. Which I am clearly not, so
 being more explicit in the changelog is very much warrented.

 That is not true, there's lots of arch:all m-a:foreign packages.

Are you sure?  That doesn't make sense to me (as opposed to arch:any
m-a:foreign packages).  Surely arch:all packages are already effectively
multi-arch without needing to use any of the new support?

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#683247: Bug#683030: unblock: vlc/2.0.3-1

2012-07-30 Thread Julien Cristau
On Mon, Jul 30, 2012 at 11:01:20 -0700, Russ Allbery wrote:

 Julien Cristau jcris...@debian.org writes:
  On Mon, Jul 30, 2012 at 09:08:50 +0200, Reinhard Tartler wrote:
 
  AFAIUI the multi-arch spec, arch:all packages are not allowed to
  specify Multi-Arch: foreign, so I had the impression that this part
  was rather obvious to multi-arch experts. Which I am clearly not, so
  being more explicit in the changelog is very much warrented.
 
  That is not true, there's lots of arch:all m-a:foreign packages.
 
 Are you sure?  That doesn't make sense to me (as opposed to arch:any
 m-a:foreign packages).  Surely arch:all packages are already effectively
 multi-arch without needing to use any of the new support?
 
There are arch:any - arch:all - arch:any dependencies, and without
m-a:foreign in the arch:all package, both arch-specific packages have to
be from the same arch, AIUI.  So yes, pretty sure.

Cheers,
Julien


signature.asc
Description: Digital signature


Bug#683247: Bug#683030: unblock: vlc/2.0.3-1

2012-07-30 Thread Neil Williams
On Mon, 30 Jul 2012 20:16:07 +0200
Julien Cristau jcris...@debian.org wrote:

 On Mon, Jul 30, 2012 at 11:01:20 -0700, Russ Allbery wrote:
 
  Julien Cristau jcris...@debian.org writes:
   On Mon, Jul 30, 2012 at 09:08:50 +0200, Reinhard Tartler wrote:
  
   AFAIUI the multi-arch spec, arch:all packages are not allowed to
   specify Multi-Arch: foreign,

It's the opposite. Arch all packages are not allowed to specify
Multi-Arch: same.

 Setting a value of Multi-Arch: same on a package which is Architecture:
 all is considered an error. dpkg-deb must refuse to generate a .deb
 with this combination of values

https://wiki.ubuntu.com/MultiarchSpec#Binary_package_control_fields

 This means that for an Architecture: all package to satisfy the
 dependencies of a foreign-architecture package, it must be marked
 Multi-Arch: foreign or Multi-Arch: allowed.

https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages

 so I had the impression that this part
   was rather obvious to multi-arch experts. Which I am clearly not, so
   being more explicit in the changelog is very much warrented.
  
   That is not true, there's lots of arch:all m-a:foreign packages.

It should be close to 100% of the Arch:all packages which are ready for
MultiArch. (allowed is rare currently and is only for specialised
situations.)

  Are you sure?  That doesn't make sense to me (as opposed to arch:any
  m-a:foreign packages).

Arch:any Multi-Arch: foreign would typically be executables like
'at' (I'm fairly sure Ansgar understands MultiArch). Also base-passwd
(Colin Watson, ditto). This is much more likely in the base system
packages or where libraries end up depending on executables. As Julien
states, in order to install such libraries as Multi-Arch: same, the base
system and any executables in the dependency chain need to be available
- usually as Multi-Arch: foreign.

  Surely arch:all packages are already effectively
  multi-arch without needing to use any of the new support?
  
 There are arch:any - arch:all - arch:any dependencies, and without
 m-a:foreign in the arch:all package, both arch-specific packages have to
 be from the same arch, AIUI.  So yes, pretty sure.

Agreed. I don't know if I qualify as a Multiarch expert but I have
been testing MultiArch conversions, toolchains and installations as
part of Emdebian for ~2 years.

The terms used can be confusing - foreign means that the package meets
the requirements of a foreign arch package which depends on it. Clearly,
Arch:all will nearly always satisfy the dependencies of a foreign arch
package. Typical example is debhelper - there is no reason for me to
install debhelper:armel on amd64 in order to build stuff for amd64 
armel. Foreign means that I just need one version - ideal for Arch:all.

i.e. foreign is less constrained than same and foreign packages need
only specify Multi-Arch: foreign in debian/control to complete their
conversion.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpSxWFPh56Rj.pgp
Description: PGP signature


Bug#683247: Bug#683030: unblock: vlc/2.0.3-1

2012-07-30 Thread Russ Allbery
Neil Williams codeh...@debian.org writes:
 Julien Cristau jcris...@debian.org wrote:

 This means that for an Architecture: all package to satisfy the
 dependencies of a foreign-architecture package, it must be marked
 Multi-Arch: foreign or Multi-Arch: allowed.

 https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages

Oh, thank you.  That was the bit that I was missing.  It looks like I have
some updates to do on my packages!

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org