[Python-modules-team] Bug#818115: turn python-sphinx into an arch:any package
Hi Helmut, On Sun, Mar 13, 2016 at 09:32:28PM +0100, Helmut Grohne wrote: > [skip] > > So here is a patch: > > sed -i -e '/Package: python3\?-sphinx/,+1s/\(Architecture: a\)ll/\1ny/' > debian/control > > Please apply it, so we can start adding the :native annotation to > reverse dependencies such as jansson #807848. I wonder what's the point of cross-building the arch-indep packages at all? In jansson case, it looks like python-sphinx should be moved from Build-Depends to Build-Depends-Indep, and the arch-any packages will be correctly cross-built without sphinx. If there are other cases except jansson, please let me know. Though I can't imagine how sphinx can be used for building something arch-specific… (Also, if I just apply the change you suggested, sphinx will FTBFS on some archs, because the tests use webkit which segfaults there — so it's a bit more tricky). -- Dmitry Shachnev signature.asc Description: PGP signature ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#818115: turn python-sphinx into an arch:any package
Package: python-sphinx Version: 1.3.6-2 Tags: patch User: helm...@debian.org Usertags: rebootstrap Control: block #807848 by -1 Hi, I have a request that may sound strange: Please turn python-sphinx and python3-sphinx from Architecture: all into Architecture: any. On first hearing this, it may make no sense and indeed the rationale is elaborate. You may have heard about the "multiarch interpreter problem". Unfortunately, sphinx is a victim of it in a strange way. When other packages Build-Depends: python-sphinx, they ask for the host architecture version. Since python-sphinx is Architecture: all, it is treated as native architecture and commonly the build architecture is the native architecture. During cross builds, the host and build architectures differ and thus there is no way to satisfy such a dependency (from a resolver pov). >From a practical pov, we do want the build architecture python for running sphinx, because the host architecture python cannot be executed. So maybe we can say that architectures don't matter for sphinx by marking it Multi-Arch: foreign? Unfortunately, no. python-sphinx transitively depends on python-markupsafe (via python-jinja2) and thus exposes it. Since python-markupsafe is an architecture dependent Python extension, python-sphinx exposes the architecture. This is the gist of the multiarch interpreter problem. Bummer, so maybe we can tell the dependency to not care about the architecture? The multiarch specification considered that problem and therefore you can annotate Build-Depends with :native to select the build architecture for a dependency. Unfortunately, this is only allowed for Architecture: any packages. So we cannot use this to fix dependencies either, unless we turn python-sphinx (and python3-sphinx) into Architecture: any packages. We thought long and hard about better solutions[1], but ultimately the we figured there are none in practical reach. At DC15, I sat down with Guillem Jover and Ian Jackson and after a long discussion, we concluded that we will have to employ this workaround to move forward, because any change to the dependency model (and thus dpkg) would be too involved. sphinx is an early target, because it affects[2] lots of reverse dependencies (>= 100). python-sphinx will certainly not be the last[3] package that requires this weired change. So here is a patch: sed -i -e '/Package: python3\?-sphinx/,+1s/\(Architecture: a\)ll/\1ny/' debian/control Please apply it, so we can start adding the :native annotation to reverse dependencies such as jansson #807848. If you have any questions about the reasoning, don't hesitate to ask and Cc debian-cr...@lists.debian.org. Helmut [1] https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges [2] http://bootstrap.debian.net/cross_all.html [3] http://bootstrap.debian.net/ma_interpreter.html ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Processed: turn python-sphinx into an arch:any package
Processing control commands: > block #807848 by -1 Bug #807848 [src:jansson] jansson: cross Build-Depends unsatisfiable 807848 was not blocked by any bugs. 807848 was not blocking any bugs. Added blocking bug(s) of 807848: 818115 -- 807848: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807848 818115: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818115 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] bibtexparser 0.6.2-2 MIGRATED to testing
FYI: The status of the bibtexparser source package in Debian's testing distribution has changed. Previous version: 0.6.1-1 Current version: 0.6.2-2 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] django-classy-tags 0.7.2-1 MIGRATED to testing
FYI: The status of the django-classy-tags source package in Debian's testing distribution has changed. Previous version: 0.7.1-1 Current version: 0.7.2-1 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See https://release.debian.org/testing-watch/ for more information. ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
