Bug#683247: Bug#683030: unblock: vlc/2.0.3-1
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#683030: unblock: vlc/2.0.3-1
Am 28.07.2012 17:47, schrieb Adam D. Barratt: On Sat, 2012-07-28 at 15:54 +0100, Adam D. Barratt wrote: Depends: vlc libav (not considered) The new libav does not have an unblock request ttbomk and from a quick look at the diff I'm not prepared to unblock it without at least some discussion (there are changes which don't appear to be mentioned in the changelog and some of the changes listed in the changelog don't actually appear tohave been made). So, will libav 6:0.8.3-5 get unblocked or should we request this separately? - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683030: unblock: vlc/2.0.3-1
On 2012-08-01 10:14, Fabian Greffrath wrote: Am 28.07.2012 17:47, schrieb Adam D. Barratt: On Sat, 2012-07-28 at 15:54 +0100, Adam D. Barratt wrote: Depends: vlc libav (not considered) The new libav does not have an unblock request ttbomk and from a quick look at the diff I'm not prepared to unblock it without at least some discussion (there are changes which don't appear to be mentioned in the changelog and some of the changes listed in the changelog don't actually appear tohave been made). So, will libav 6:0.8.3-5 get unblocked or should we request this separately? - Fabian There is a bug for it, #683247, tagged moreinfo. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683030: unblock: vlc/2.0.3-1
On 01.08.2012 09:14, Fabian Greffrath wrote: Am 28.07.2012 17:47, schrieb Adam D. Barratt: On Sat, 2012-07-28 at 15:54 +0100, Adam D. Barratt wrote: Depends: vlc libav (not considered) The new libav does not have an unblock request ttbomk and from a quick look at the diff I'm not prepared to unblock it without at least some discussion (there are changes which don't appear to be mentioned in the changelog and some of the changes listed in the changelog don't actually appear tohave been made). 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. :-) Regards, Adam -- 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
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#683030: unblock: vlc/2.0.3-1
clone 683030 -1 retitle -1 unblock libav block 683030 by -1 tag -1 moreinfo stop On Sat, Jul 28, 2012 at 5:47 PM, Adam D. Barratt a...@adam-barratt.org.uk wrote: On Sat, 2012-07-28 at 15:54 +0100, Adam D. Barratt wrote: Depends: vlc libav (not considered) The new libav does not have an unblock request ttbomk and from a quick look at the diff I'm not prepared to unblock it without at least some discussion (there are changes which don't appear to be mentioned in the changelog and some of the changes listed in the changelog don't actually appear tohave been made). Yeah, sorry for the confusion. I indeed intend to request the release team to unblock the libav package, but didn't manage to get the package in shape for that so far. I had a hell of a week with day-work and returned from my one-week vacation only today. So your review is more than appreciated, I will see to address your comments ideally this week in a new package upload. Looking again and reading through the associated bug reports, it looks a bit better than I thought; I really shouldn't have to read through longish bug report logs to find out why a change has been made to the packaging, however. libav maintainers (Cced): - the changelog for -5 mentions making transitional packages arch:all, but not a number of removals of Multi-Arch: foreign that seem to have been applied to some packages. Oh, I will make the changelog more explicit, then. 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. - the changelog also doesn't mention the dropping of the ffmpeg Provides. I'll amend the changelog. The provides is potentially harmful as it prevents package to declare a versioned dependency on the 'ffmpeg' package. In any case, as long as we still provide an empty, transitional package 'ffmpeg', the provides seem pretty pointless to me. - this change looks slightly odd: * Do not run doxygen if it is not installed. doxygen is in B-D-Indep and only appears to be used when building the arch:all -doc package. On that basis, why would it not always be installed when required? Your analysis in http://lists.debian.org/1343596589.18013.133.ca...@jacala.jungle.funky-badger.org seems right to me. The point of this commit seems to me (Fabian, please clarify if I'm wrong) to allow the package to be built also in with earlier version of dpkg, such as found in earlier releases of Debian and derivatives. 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). I believe that such an -6 upload qualifies the RT criteria for unblocks at this point. However, I'd appreciate feedback on the points that you disagree so that I can address them in time to avoid a further, unnecessary -7 upload. Thank you for your time reviewing the libav package! -- 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#683030: unblock: vlc/2.0.3-1
Am 28.07.2012 17:47, schrieb Adam D. Barratt: - the changelog also doesn't mention the dropping of the ffmpeg Provides. This was also my change, I am sorry this slipped through without proper documentation. However, this field was so utterly wrong in that libav-tools simply does not provide ffmpeg - it's in its own package. Maybe I found this so obvious that I forgot to mention it. ;) - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683030: unblock: vlc/2.0.3-1
Dear Adam, Am 29.07.2012 23:16, schrieb Adam D. Barratt: I did not apply this change but recognize it from Emdebian sprint: Reason is, I believe, to ease bootstrapping new architectures by suppressing build of arch-all packages. Jonas is right. The main reason for this change was to make it easier to bootstrap the libav package with as little additional (Build-)Dependencies as possible. Libav is involved in several circular dependencies and in the past we got requests by porters to document which B-Ds of libav are actually mandatory and which are optional. Since they are all optional, I suggested a minimal Build-Depends-Bootstrap1 field in README.source, in which I also omitted doxygen. A few weeks later, when I rebuilt the libav package on my system with dpkg-buildpackage -d to test the changes fixing #680602, I found that doxygen is still called, which I found unnecessary and thus removed it. Hmmm, unless I'm reading the rules files incorrectly, purely running the binary-arch target should already have DTRT without requiring doxygen to be installed. Hence the query, as the change appears to be effectively an unnecessary no-op right now. Yes, for regular builds which have the full set of B-Ds available, this change is a no-op. But for (1) bootstrapping efforts - which merely need a minimal libav to build other packages which in turn are required to rebuild a full-featured libav - and for (2) quick testings of packaging related changes, this makes a subtle difference. Best Regards, Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683030: unblock: vlc/2.0.3-1
[BCCed to the vlc bug for info; let's move discussion to the libav clone] On 30.07.2012 08:08, Reinhard Tartler wrote: On Sat, Jul 28, 2012 at 5:47 PM, Adam D. Barratt a...@adam-barratt.org.uk wrote: On Sat, 2012-07-28 at 15:54 +0100, Adam D. Barratt wrote: Depends: vlc libav (not considered) The new libav does not have an unblock request ttbomk and from a quick look at the diff I'm not prepared to unblock it without at least some discussion (there are changes which don't appear to be mentioned in the changelog and some of the changes listed in the changelog don't actually appear tohave been made). Yeah, sorry for the confusion. I indeed intend to request the release team to unblock the libav package, but didn't manage to get the package in shape for that so far. No problem. Looking again and reading through the associated bug reports, it looks a bit better than I thought; I really shouldn't have to read through longish bug report logs to find out why a change has been made to the packaging, however. libav maintainers (Cced): - the changelog for -5 mentions making transitional packages arch:all, but not a number of removals of Multi-Arch: foreign that seem to have been applied to some packages. Oh, I will make the changelog more explicit, then. Thanks. 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. I guessed it was related, yes. Clarification via the changelog that it was intended is helpful though. - the changelog also doesn't mention the dropping of the ffmpeg Provides. I'll amend the changelog. The provides is potentially harmful as it prevents package to declare a versioned dependency on the 'ffmpeg' package. In any case, as long as we still provide an empty, transitional package 'ffmpeg', the provides seem pretty pointless to me. Makes sense; thanks. - this change looks slightly odd: * Do not run doxygen if it is not installed. doxygen is in B-D-Indep and only appears to be used when building the arch:all -doc package. On that basis, why would it not always be installed when required? Your analysis in http://lists.debian.org/1343596589.18013.133.ca...@jacala.jungle.funky-badger.org seems right to me. The point of this commit seems to me (Fabian, please clarify if I'm wrong) to allow the package to be built also in with earlier version of dpkg, such as found in earlier releases of Debian and derivatives. 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. Regards, Adam -- 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
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
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
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
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
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
Bug#683030: unblock: vlc/2.0.3-1
On Sat, 2012-07-28 at 22:32 +0200, Jonas Smedegaard wrote: On 12-07-28 at 04:47pm, Adam D. Barratt wrote: - this change looks slightly odd: * Do not run doxygen if it is not installed. doxygen is in B-D-Indep and only appears to be used when building the arch:all -doc package. On that basis, why would it not always be installed when required? I did not apply this change but recognize it from Emdebian sprint: Reason is, I believe, to ease bootstrapping new architectures by suppressing build of arch-all packages. Hmmm, unless I'm reading the rules files incorrectly, purely running the binary-arch target should already have DTRT without requiring doxygen to be installed. Hence the query, as the change appears to be effectively an unnecessary no-op right now. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683030: unblock: vlc/2.0.3-1
On Sat, 2012-07-28 at 00:44 +0200, Benjamin Drung wrote: VLC 2.0.3 is a bug fix release of upstreams 2.0.x maintanence branch. It contains a bunch of fixes. Expanding on that would have been useful... You can review them in our git repository [1]. There are many changes to extras/package/macosx/ and some to contrib/. These changes affect only MacOS or Windows and have no effect on the Debian package. [1] http://anonscm.debian.org/gitweb/?p=pkg-multimedia/vlc.git;a=summary We generally won't go digging in VCSen to look at diffs. Aside from not necessarily matching what got uploaded, it takes longer and requires more context switching, at least IME. Attaching a diff with the relevant changes is often helpful as an alternative. Having filtered the diff to get rid of the considerable noise, I'd be prepared to unblock it. There is, however, an issue: Depends: vlc libav (not considered) The new libav does not have an unblock request ttbomk and from a quick look at the diff I'm not prepared to unblock it without at least some discussion (there are changes which don't appear to be mentioned in the changelog and some of the changes listed in the changelog don't actually appear tohave been made). Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683030: unblock: vlc/2.0.3-1
On Sat, 2012-07-28 at 15:54 +0100, Adam D. Barratt wrote: Depends: vlc libav (not considered) The new libav does not have an unblock request ttbomk and from a quick look at the diff I'm not prepared to unblock it without at least some discussion (there are changes which don't appear to be mentioned in the changelog and some of the changes listed in the changelog don't actually appear tohave been made). Looking again and reading through the associated bug reports, it looks a bit better than I thought; I really shouldn't have to read through longish bug report logs to find out why a change has been made to the packaging, however. libav maintainers (Cced): - the changelog for -5 mentions making transitional packages arch:all, but not a number of removals of Multi-Arch: foreign that seem to have been applied to some packages. - the changelog also doesn't mention the dropping of the ffmpeg Provides. - this change looks slightly odd: * Do not run doxygen if it is not installed. doxygen is in B-D-Indep and only appears to be used when building the arch:all -doc package. On that basis, why would it not always be installed when required? Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683030: unblock: vlc/2.0.3-1
On 12-07-28 at 04:47pm, Adam D. Barratt wrote: - this change looks slightly odd: * Do not run doxygen if it is not installed. doxygen is in B-D-Indep and only appears to be used when building the arch:all -doc package. On that basis, why would it not always be installed when required? I did not apply this change but recognize it from Emdebian sprint: Reason is, I believe, to ease bootstrapping new architectures by suppressing build of arch-all packages. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#683030: unblock: vlc/2.0.3-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package vlc VLC 2.0.3 is a bug fix release of upstreams 2.0.x maintanence branch. It contains a bunch of fixes. You can review them in our git repository [1]. There are many changes to extras/package/macosx/ and some to contrib/. These changes affect only MacOS or Windows and have no effect on the Debian package. [1] http://anonscm.debian.org/gitweb/?p=pkg-multimedia/vlc.git;a=summary unblock vlc/2.0.3-1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
