Bug#534162: ITP: python-pyneo -- pyneo mobile stack: basis libraries
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: python-pyneo Version : 1.13 Upstream Author : Michael Dietrich m...@pyneo.org * URL : http://pyneo.org * License : GPL3 Programming Lang: Python Description : pyneo mobile stack: basis libraries Helper modules to support development for and with pyneo in Python. It contains common functions, modules and constants. -- I already attempted to build a Debian package: http://rabenfrost.net/pyneo/python-pyneo/python-pyneo_1.13-1.dsc This ITP is related to the ITP of pyneod Bug#534160 -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534163: ITP: gsm0710muxd -- GSM 07.10 Multiplexer
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: gsm0710muxd Version : 1.13 Upstream Author : Michael Dietrich m...@pyneo.org * URL : http://pyneo.org * License : GPL2+ Programming Lang: C Description : GSM 07.10 Multiplexer pyneo mobile stack: muxer as GSM 07.10 describes. A muxer for gsm modems to allow more than one channel to be used with the modem. Each channel can be used to issue phonecalls, watch signal strength, receiving sms or even doing ppp (gprs) at the same time. Access to the multiplexer is managed via D-Bus. - I already attempted to build a Debian package: http://rabenfrost.net/pyneo/gsm0710muxd/gsm0710muxd_1.13-1.dsc This ITP relates to the ITP of pyneod Bug#534160 -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: thoughts on using multi-arch based cross-building
Hi, On Mon, Oct 01, 2012 at 01:05:11AM +0100, Wookey wrote: Build-depends installation: apt-get build-dep is fine if you are building an unmodified package from a repo but it's of no use if you have modified the build-dependencies to make them satisfiable. Annoying isn't it? This has been irritating me for years. /usr/lib/pbuilder-satisfydepends-classic is very useful for the native-build case, but I am not aware of a multiarch-aware tool. A tool like this should really be in devscripts. dpkg-dev has dpkg-checkbuilddeps which also has the -a switch for foreign architectures. But it has two problems: - the string it outputs contains versions in a format not compatible with the apt-get command line. - even with -a it doesnt seem to append architecture qualifiers to package name (package:arch) But dpkg-checkbuilddeps could probably easily be used as a template for a script that is able to feed apt. Does a tool exist that can be told install the build-depends needed to build the debianised source tree in directory x for architecture y? if not IMO such a tool (or a new option in an existing tool) needs to be created. The dose3 tools can produce the same answers as apt for this problem, and could quite easily be modified to look at a local source package rather than only at packages files. Johannes Schauer was looking into doing this a couple of weeks ago. Any joy Johannes? When we talked about it, I did some quick hacking and created some patches for the dose3 parser so that it would also be able to read debian/control files. When I was in Paris we didnt talk much about dose3 but more about my code. I will ask Pietro about the best way to integrate this into dose3 on the debian-bootstrap list [1] today. I have just created (following on from PJ McDermott's GSOC work) a cross-build-essential source package that makes crossbuild-essential-arch packages to bring in cross-gcc, cross-g++, dpkg-cross (aka cross-support) pkg-config-triplet. That in this PPA: https://launchpad.net/~linaro-foundations/+archive/cross-build-tools and needs some dpkg-vendor foo adding to make it right for both debian and ubuntu. And it needs wanna-build fixing (support for architecture qualifiers eg package:arch) in Debian. cheers, josch [1] http://lists.mister-muffin.de/cgi-bin/mailman/listinfo/debian-bootstrap -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121001083403.GB1682@hoothoot
History of Debian bootstrapping/porting efforts
Dear list, I am the student that did the Port bootstrap build-ordering tool Google Summer of Code project this summer [1]. I am still continuing that work and will turn it into my Master thesis. The tools I developed are currently in use by wookey for doing the arm64 port [2]. A long list of results of my programs as well as outstanding problems can be found in the Debian wiki [3]. For the introduction of my thesis, I want to give a summary of how past ports were accomplished. Since there does not seem to be a mailinglist for general ports (but only for each specific port), I am addressing this email to debian-devel. I created a wiki page to collect the information so that it would also be available to everybody else: http://wiki.debian.org/DebianBootstrap/History If you were ever involved in porting Debian to a new architecture or know how a port was done, please do not hesitate to either write me an email or directly enter the information in the linked wiki page linked above. It assumes that arch labels are established and that gcc, glibc, binutils etc understand the arch. I basically would like to know things like: - did you cross compile parts of Debian? How much? How hard was it? - did you natively compile on another distribution (openembedded, gentoo) - how did you go about finding reduced build dependencies? What were the heuristics you used? How did you find dependency cycles to break and how did you pick a solution? - how long did the port take you? - what were the most common bugs you filed when introducing the new architecture? Having an overview that answers above questions (and anything else noteworthy or quantifiable) can also be useful for future porters to get an overview or ideas how to go about it technically. At the very best, I will get more ideas for heuristics that allow my tools to get better at breaking build dependency cycles. Thanks for your help! cheers, josch [1] http://wiki.debian.org/SummerOfCode2012/StudentApplications/JohannesSchauer [2] http://wiki.debian.org/Arm64Port [3] http://wiki.debian.org/DebianBootstrap/TODO -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121113201924.GA16619@hoothoot
How to make port/bootstrapping work easier
Hi Daniel, thanks for your detailed report! You also commented a lot on your actual practice (thanks!) so I changed the subject to reflect the slight topic change of my reply. On Wed, Nov 14, 2012 at 05:54:06PM -0800, Daniel Schepler wrote: I read your recent post to debian-devel with great interest, as I've done some bootstrapping efforts in the past, and I'm currently in the middle of a port for the x32 ABI. In the past, what I've done (mostly privately) was to develop a script I called pbuildd which essentially just runs through the list of currently unbuilt packages and tries running pbuilder on them all, then installs anything that succeeds into a local repository and starts up the loop again. This is what a small function does for me in the very early steps in a theoretical manner. Naturally it quickly fails due to dependency cycles ;) Then, when things got stuck, I just did a manual inspection of the unsatisfied dependencies to find the cycles, and chose one to break. In fact, I've just started uploading my current iteration of this to http://87.98.215.228/debian/ -- you might want to especially look at scripts/pbuildd which is the central script to run this loop. (And over time, it's gathered various optimizations to speed up the installation into local repository step, try to avoid invoking pbuilder if it can easily determine that certain Build-Depends aren't present at all, etc.) What my tools try to do, is to figure out a build order for bootstrapping Debian from nothing. This order can then be given to a tool that does the actual compilation in that order. The figuring out the order part is purely theoretical. I only look at the Packages and Sources files and the dependency relationships stored within to generate a dependency graph which I then evaluate. My tool doesnt know or care about whether or not a package can actually be compiled on the new architecture. It does no compilation by itself and can therefor not figure this out by itself. Running into compilation problems is (as of now) still what the user would have to take care of (from the point of view of my tools). I call it my tools because there is no name for the project yet. The git repository [6] and mailing list [7] just run under the name debian-bootstrap. At this point I should also mention that everything heavily depends on dose3 and Pietro Abate is a great help with this project and I certainly wouldnt be where I am without dose3 and his continuous help and additions to the project. Initially, when I needed to break a cycle, I would just build something by hand and stick it into the partial directory, but over time I started developing automated cycle-breaker scripts, which are currently under scripts/cb.inactive (the pbuildd script looks for them under scripts/cb). I had a look at the files in scripts/cb.inactive and they seem to store lots of information about which build dependencies can be dropped for a huge number of source packages. This is, if I read lines like inst_pkgs `get_control_re $PBUILDD_ROOT/build/a/antlr/*.dsc 'build-(depends|depends-indep)' | sed -e '/\gcj-native-helper\/d' -e '/\nant\/d' \ -e '/\cli-common-dev\/d' -e '/\mono-devel\/d' \ -e '/\libmono-winforms2\.0-cil\/d'` correct in meaning that gcj-native-helper, nant, cli-common-dev etc can be dropped, right? Sadly, that information is stored in a turing complete format (bash scripts) which makes the information badly machine readable. But if the format '/\package\/d' is mostly used, then I guess a regex can extract lots of the information with some tolerable uncertainty. I will try to hack up a script that harvests the droppable build dependencies from the files you have in scripts/cb.inactive. This information might be immensely usable, thanks! As a porter has to come up with those droppable build dependencies for each new port, a new syntax has been proposed in [3] by Guillem Jover called build profiles. Would this information be included in the build dependencies of some core packages, bootstrapping would already become much easier for a porter. An example of how the proposed format works: Build-Depends: huge (= 1.0) [i386 arm] !embedded !bootstrap, tiny The and brackets are used in the same way [ and ] are used for architectures to denote the profile for which that dependency can be dropped (or is exclusively required). Besides bootstrapping, such profiles could also be used for embedded builds or for bootstrapping compilers that need themselves to be built. The latter topic also recently came up on debian-devel [8]. There exist trivial patches for dpkg [4] and dose3 [5] to implement this functionality. The scripts tend to become outdated over time, though, with a moving target, and I'm sure the current state is no exception. My personal heuristics for what I preferred were: first, prefer cycle-breaking which just removes Build-Depends which are there to build
Re: History of Debian bootstrapping/porting efforts
Hi, On Tue, Nov 20, 2012 at 09:22:40PM +, Thorsten Glaser wrote: For reviving m68k: Thanks for your detailed explanations! I added a summary of it to the m68k section of the wiki page [1], extending the notes entered there by Ingo Jürgensmann. Thanks to both of you! - how did you go about finding reduced build dependencies? What were the heuristics you used? How did you find dependency cycles to break and how did you pick a solution? Fully manually. I mostly drew ASCII files like this: sourcepkg1 sourcepkg2 sourcepkg3 sourcepkg4 sourcepkg5 sourcepkg3dup sourcepkg6 sourcepkg2cyc [...] Then I worked on them from right to left, occasionally patching a huge dependency out or breaking a B-D loop by hand, sometimes also installing older versions of B-Ds manually, or even building versions older than sid but newer than what I had. Since yesterday, my tools can now finally turn the whole dependency graph into an acyclic graph by braking only a small number of build dependencies (using an approximative solution to the minimal feedback arc set problem) and output a final build order to build all of Debian starting from an initial minimal build system (priority:essential plus build-essential plus debhelper). Detailed explanations can be found in the email I wrote to our debian-bootstrap mailinglist: http://lists.mister-muffin.de/pipermail/debian-bootstrap/2012-November/000425.html A summary: Using the results I got from Daniel Scheplers x32 bootstrapping work, droppable build dependencies from Thorsten Glaser, Patrick McDermott and my Gentoo work, I was able to reduce the original 923 nodes SCC into one SCC with 159 nodes and another with 42 nodes: http://mister-muffin.de/p/NRTs.png http://mister-muffin.de/p/myFd.png Those two graphs were easily breakable into a DAG by just removing 4 and 2 build dependencies respectively using the feedback arc set algorithm I wrote over the weekend. The same algorithm can also be applied to the full 923 node SCC for Debian Sid, resulting in 90 build dependencies to be dropped to make the graph acyclic and making a final build order possible with (close to) minimal changes. For this to happen, only 50 source packages have to be modified. Build-Depends: huge (= 1.0) [i386 arm] !embedded !bootstrap, tiny Yeah, waiting for it… As build profiles do not exist yet, there might be instances where my algorithm chooses build dependencies that are not droppable in practice. One obvious example is the dependency cycle: src:pkg-config -- libglib2.0-dev So I'm now implementing a facility that allows to explicitly mark build dependencies as unbreakable so that the algorithm finds an alternative solution or throws an error. The above case for example has no alternative solution as the cycle is of length two and has no other way of braking it than building pkg-config without libglib2.0-dev. Since this is unlikely to be possible and since the assumption is that only build dependencies might be dropped when necessary but not binary dependencies, a possible solution might be cross compilation. Looking at the cross build dependency graph and braking its dependency cycles is the next step I will take. cheers, josch [1] http://wiki.debian.org/DebianBootstrap/History -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121120225523.GA18533@hoothoot
Debian port bootstrap build ordering tool status
Hi, On Fri, Nov 23, 2012 at 03:48:04AM +, peter green wrote: Since yesterday, my tools can now finally turn the whole dependency graph Does this whole dependency graph include the implicit build-dependency every package has on build-essential? For source packages for native compilation, yes. What is not included is Build-Depends-Indep. I have been told that there are many problems with Build-Depends-Indep but not considering those dependencies tremendously helps to reduced the amount of cyclic dependency hell, so they should be made working for better bootstrappability. For binary packages, the implicit dependency on priority:essential is kept. For source packages for cross compilation, afaik wookey currently uses an implicit dependency on crossbuild-essential-$arch but this is not yet policy of course and has to be discussed still. The above case for example has no alternative solution as the cycle is of length two and has no other way of braking it than building pkg-config without libglib2.0-dev. Since this is unlikely to be possible I don't see why it would be impossible to hack up the glib source package to not rely on pkg-config. Whether that is a good idea or not is another matter. It is not a dependency loop between the pkg-config source package and the glib2.0 source package. It is a dependency loop between src:pkg-config (we use the src: prefix to never confuse source package names with binary package names) and libglib2.0-dev. There is a loop because libglib2.0-dev has a binary dependency on pkg-config but the source package that pkg-config builds from (src:pkg-config) cannot be built without libglib2.0-dev. So even if the glib2.0 source package can be built and therefor make libglib2.0-dev available, libglib2.0-dev can never be installed because it has a binary dependency on pkg-config. pkg-config builds from src:pkg-config but src:pkg-config can never be compiled because it has a build dependency on libglib2.0-dev, which cannot be installed - loop. The assumption that this specific loop cannot trivially (without cross compilation) be broken depends on the following two assumptions: - binary dependencies should never be modified - src:pkg-config cannot be built without libglib2.0-dev and since the assumption is that only build dependencies might be dropped when necessary but not binary dependencies, a possible solution might be cross compilation. It seems pretty clear to me that there is a core of software that will need to be cross-built as the first stage of bootstrapping a port. Obviously essential and build-essential fall into this category but while i'm sure there are ways one could hack away the cycles and make things like pkg-config and debhelper natively bootstrapable I don't think there is much point in doing so. It is always the call of the user to decide what is easier: - to bootstrap package A natively by braking cycles or - to make all source packages that need to be cross compiled to have package A installable cross compile Both tasks (finding out if the necessary source packages can be built with reduced build dependencies and checking how easy it is to make them cross compilable) can only be solved by a human. My tools help the user in that task by allowing to analyze the dependency graph situation for native compilation and also allow to investigate the list of source packages that have otherwise to be cross compiled to make the package installable. Comparing these two options allows the user to make a better call when he has to decide for either of those two choices. But right now, debhelper is indeed taken as part of the packages to be cross compiled to avoid a horribly messy initial dependency graph. What i'd ideally like to see is for a tool to be able to generate a directed acyclic graph of build jobs (some cross, some native, there should be an option in the tool as to whether to preffer native or cross-build jobs) that takes the user from having no packages for the target architecture to having a set of bootstrap packages that can be used to seed the regular building process. This is the final goal of my project. What is currently done is the native part of the above. Given a minimal build system (build-essential, priority:essential) it can devise said order of build jobs by braking the graph into a directed acyclic graph (DAG). The tool helps the user to find build dependencies that make most sense to be broken and uses a list of brake-able build dependencies supplied by the user to break the graph into DAG with a close to minimal number of source packages that have to be built with reduced build dependencies. Once Debian understands build profiles (see my last email) those will of course be taken into account as well. Until this is the case, my tool can help to identify those source packages that make sense to have build dependencies dropped. In a state where Debian understands build profiles, my current code
Bootstrappable Debian - proposal of needed changes
Hi, the following is an email written by Wookey and myself. 0. Introduction === The Debian bootstrap build ordering tool Google Summer of Code project [1] was continued even after the summer ended and recently reached a new milestone by being able to create a final build order from a dependency graph [2] for Debian Sid. By now, all important tools and algorithms have been written [5] to solve the following problems: - find source packages to which build profiles (reduced build dependencies) should be added - given enough source packages annotated with build profiles, generate a final build order which produces a full Debian archive from zero, starting from cross compiling a minimal system and natively compiling the rest, breaking build dependencies as necessary (and as possible) Since Debian source packages do not (yet) contain enough meta data to decide whether or not a build dependency can be dropped, USE flags of Gentoo source packages were harvested [3] [6]. On top of that, suggestions from Thorsten Glaser, Patrick McDermott and Daniel Schepler were used. This way, our current results are hopefully not too far away from reality, While the theoretical results do look consistent, this has so far not been completed in practice due to the following open issues: 1. missing multiarch annotations prevent the multiarch cross build dependencies of some source packages from being resolved correctly 2. not all source packages of the minimal build system are cross compilable in practice yet 3. no decision has been made on the syntax of the new control fields (build profiles) which are required for automated bootstrapping 4. not enough source packages implement build profiles (this depends on 3 being solved) More details on this scheme are given at the DebianBootstrap wiki page [8]. Work has been going on for a couple of years on this, evolving as practical experience was gained, and input taken from more people. We therefore make the following proposals (field names not set in stone) in descending order of importance for us: 1. Build-Profiles = The build profile format was proposed by Guillem Jover together with other solutions he presented in this document [7] as part of bug#661538. Build profiles extend the Build-Depends format with a syntax similar to architecture restrictions but using and instead. Build-Depends: huge (= 1.0) [i386 arm] !embedded !stage1, tiny The build dependency huge would not be required by the source package if it is built in the embedded or stage1 profile. This mechanism neatly allows for removed build-deps, replaced build-deps and added build-deps, and an arbitrary number of possible 'profiles'. Besides bootstrapping, these build profiles could also be used for embedded builds, and to allow for changed buil-deps when cross-building. One could also imagine that DEB_BUILD_OPTIONS=nodocs could be replaced by a profile called nodocs. Patches for dpkg (bug#661538) and dose3 implementing this syntax already exist. This scheme supersedes an earlier version, (referred-to as 'staged' builds), which used repeated Build-depends-StageN: lines. See the dpkg bug#661538 for the evolution of this. The profile labels are arbitrary but agreement on label usage is necessary. For bootstrap automation we have been using 'stage1', 'stage2', etc which fits with existing custom in packages which already have such internal mechanisms using DEB_STAGE (currently gcc, eglibc, libselinux, gcj, gnat, gdc, linux [9]) These seem like sensible names so we propose to stick with them. Other useful profiles can be defined in the future. The drawback of this syntax is that Build-Dep parsing tools need to be updated to read/accept it, so uploads of source containing these annotations cannot be done until the dpkg in buildds at least parses it. 2. Build-Profiles (extension 1) === When a source package is built with fewer build dependencies (cross, embedded, stage1, nodocs...), then it often happens that it does not build one or more of its binary packages at all (e.g. foo-gtk, foo-java, foo-doc). While this is a minor nuisance during a half automated bootstrap, a fully automated bootstrapping process needs to know which binary packages a source package does not build if it is compiled in one of its profiles. We therefore propose a new field for binary packages in their control file which indicates for which profiles it builds. Builds-With-Profile: !stage1 !embedded Different profile names are separated by spaces similar to the Architecture field. A binary package with the above field would not be built during the profile builds stage1 or embedded. Binary packages which do not have this field would default to being built by every profile. This field would mean a minor change to dpkg-gencontrol. 3. Build-profiles (extension 2) === A build profile is set either using a DEB_
Re: Bootstrappable Debian - proposal of needed changes
Hi, On Wed, Jan 16, 2013 at 01:50:17PM +, Ian Jackson wrote: 5. Cross-Builds field = For even further automation and also for quality assurance, we propose another new field for source packages which indicates whether or not this source package is supposed to be cross compilable. Is it possible that packages might only cross build for certain targets ? Or only for certain hosts ? Yes. But for the intended purpose of this field, it does not make much sense to encode the information on which architecture and for which architecture a source package cross compiles. If a source package would not compile on some architectures or for some architectures, then it would be Cross-Builds:No. If the Cross-Builds field is being introduced, then only a few base source packages *must* carry this field. For all other source packages, this field would be optional. The tools we developed can always be used to calculate which source packages are necessary to cross compile a minimal build system. Therefor, this field would only be: - a more obvious way for the maintainer of a source package to know that his/her package is one of those that must be cross compilable for any upcoming architecture. - a more obvious way for a bootstrapper to see which native build dependency cycles could easily be solved by cross compiling some source packages The field is therefor rather low priority compared to the other ideas. I haven't spotted anything hideously wrong. I have three suggestions for changes: * Packages should explicitly declare which profiles they support. This should be done with a Profile field in the source stanza of debian/control. Good idea - this would make it even more analogous to the Architecture field and its meaning in source and binary stanzas in ./debian/control. * It should be made explicit in the spec that building occurs with zero or one profile, not several. As far as I understood (but I'm not the one who actually cross-compiles things in real life), different dependencies might be needed during cross compilation of some source packages. If that source package must be cross compiled for a minimal base system and if it also must be built with reduced build dependencies, then two build profiles at the same time are necessary. In this case a cross and stage1 profile. * The concrete syntax in build-depends should not use but rather reuse the architecture qualification syntax. You basically propose to extend the architecture qualification syntax from a single disjunction into a conjunctive normal form expression. If any number of disjunctions is allowed, your proposal will also support more than one profile at the same time. What would an example of a different namespace than profile: be? From the perspective of dependency analysis, your proposal seems to be able to carry all information that is needed for it. I leave it up to you guys to decide on which you like better. Thanks for your input! cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130116160543.GA30841@hoothoot
Re: Bootstrappable Debian - proposal of needed changes
Hi,
On Wed, Jan 16, 2013 at 04:00:15PM +0100, Matthias Klose wrote:
this only takes care about packages with a reduced package set built,
or packages with reduced functionality. There are same cases missing:
- extra build dependencies for cross builds, like for gcc-4.7:
{gobjc++,gccgo,gfortran}-target-gnu-type
profile:cross?
- build dependencies for running the check target. Usually these
dependencies can be ignored when cross-building packages, or when
building a package natively with DEB_BUILD_OPTIONS=nocheck.
profile:check? There are not few packages which can be easier
cross-built when identifying and dropping these build dependencies.
So it does make sense to build with two profiles like stage1 check.
You probably mean a nocheck profile?
Your first example indeed demonstrates why multiple profiles are useful
to be enabled at once.
The second example can be accomplished with only one profile by marking
all dependencies that are not being needed by a nocheck profile as not
being needed by the stage1 profile as well.
So instead of:
Build-Depends: foo !stage1, bar !nocheck
and then needing two profiles at the same time, one could have:
Build-Depends: foo !stage1, bar !nocheck !stage1
Though I agree that the first option looks more maintainable.
There is also the idea of a nodocs profile which would work like
DEB_BUILD_OPTIONS=nodocs.
Whether or not nocheck and nodocs can/should become build profiles
is of course still to be debated.
An argument for them becoming build profiles is, that the analysis
algorithm would then be able to just choose the less dangerous nodocs
or nocheck profile instead of a stage1 profile if they break a
dependency cycle. How safe/dangerous choosing a profile is, could be
evaluated by the number of binary packages which are not built with a
given profile but which are needed as build dependencies by other source
packages. While a stage1 profile is likely to not build binary
packages which are needed somewhere else, the nodocs and nocheck
profiles will likely not lead to needed binary packages not being
compiled.
So nocheck and nodocs profiles could allow safer reduced builds.
An argument against nodocs might be, that since (most?) *-doc packages
are Architecture:all, the build dependencies that are needed by them to
be built are already/should be included in Build-Depends-Indep anyways.
The current algorithms discard the Build-Depends-Indep field as
Architecture:all binary packages do naturally not need to be built
during the bootstrapping process.
cheers, josch
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130116162652.GB30841@hoothoot
Re: Bootstrappable Debian - proposal of needed changes
On Wed, Jan 16, 2013 at 05:41:31PM +, Colin Watson wrote: If Debian wants to incorporate the ability to being bootstrappable in its policy, then there *must* be some packages which are cross compiled for a minimal build system. Adding this header to those source packages would make it a bug if they do not actually cross compile. Without this header, cross compilation would be wishlist as usual. This would be better done by way of an external list of the packages that need to cross-build cleanly. It will be possible for every developer to generate this external list by using the tools that were developed during my GSoC. Note, that a consistent list cannot be generated at this point, as some source packages have conflicts in their multiarch cross build dependencies. So (as pointed out in my initial email) the algorithms exist but package meta data must still be fixed. What we have right now is: - the *minimum* list of source packages that must be cross compiled - the *maximum* list of source packages that must be cross compiled The actual list of source packages that must be cross compiled is somewhere in between, closer to the minimum list of source packages and depends on how multiarch cross dependencies will be resolved in practice. Furthermore, cross compilation is one of the methods a porter can use to break build dependency cycles. If some packages carry this new field then not only could a porter decide quicker whether or not a source package is cross compilable, an algorithm could also incorporate this information to automatically break build dependency cycles for cross compilation. While this is true, having stared at similar things myself in the past, I've come to believe that it's a better use of time to just make everything in sight cross-buildable than to spend lots of effort trying to algorithmically decide what might work or not. The only way to algorithmically decide this, is to actually attempt to cross build the package in question. For example by using a buildd which constantly tests source packages for cross buildability as you already mentioned in your last email. From what I was told by wookey and others, cross building should only be the very last option and therefor the current version of the tools tries to select as few source packages as possible for cross compilation. Cross building is also currently regarded as only the last resort for breaking native build dependency cycles. From the perspective of the dependency analysis algorithms, deciding that cross compilation is suddenly an easy thing which can and should be done for most source packages, is just switching the dependency resolution from native to cross. So the developed algorithms would still all be valid if building things cross were suddenly preferred. The question remains of how many source packages would have to have the proposed new fields added to them to make a full bootstrap from zero possible. If the Gentoo USE flags were not too far off and assuming or tools do the correct thing so far, then: - the number of source packages that has to be modified with the new fields is at maximum 83 (there might be a smaller set). https://wiki.ubuntu.com/CrossBuilding/BuilddChroot (thanks, Matthias) suggests that we are not that far from being able to at least get to a sensible minimal chroot with a modicum of hacking. Not sure whether you meant to reply to my paragraph above yours, but you linked to a different selection of packages than I meant. The 83 source packages I mentioned were not the minimal build system but those which need to have build profile information added to break dependency cycles. The ~300 source packages out of which the 83 are selected can be found here: http://wiki.debian.org/DebianBootstrap/TODO#Break_dependency_cycles_using_staged_builds The list is of Debian Sid from (IIRC) August last year and consists of the main build dependency problem. All those ~300 source packages depend upon each other through their build dependencies. Maximum 83 of them must be modified to break this strongly connected component into a directed acyclic graph. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130116195100.GA12783@hoothoot
Re: Bootstrappable Debian - proposal of needed changes
Hi, On Thu, Jan 17, 2013 at 08:33:57AM +0100, Wouter Verhelst wrote: If wanna-build is updated to support these two fields, then I imagine it can run the bootstrapping dependency algorithm. While you wouldn't want to upload a package to the debian.org archive when the architecture is as yet incomplete, the same isn't true for the debian-ports.org archive. It would require some patches for wanna-build to understand that package foo would need to be rebuilt once a particular profile is fully built and available, but I don't think that's impossible. I'm not sure if wanna-build is the right tool to do this but we also did not yet implement anything which would require a specific tool for the build process. The output of the current version of the algorithm produces is an ASCII, comma separated list of source packages. All packages which can be built in parallel are given on the same line. Source packages that need to be built with reduced build dependencies are annotated as such. The rebuilding of profile built packages is part of this output and triggered after all source packages of a strongly connected component finished building. After all profile built packages successfully rebuilt fully, *all* source packages of the strongly connected component are rebuilt. This is to make sure that every source package was built once with all build dependencies available. This list gave me so far an idea of the build order and a way to check whether it made sense. By coming up with a more machine readable version of this output, a tool can be triggered/controlled which then gives the actual build jobs and does things like you mentioned above. However, to do that, there's one thing I'm missing in your mail: there will be cases where packages, when built in a particular profile do not support some functionality. That is, the package is available and does most of what the full package does, but because some build-dependency is missing, it doesn't support some feature or other -- for example, let's say that a document translation package (which we'll call foo) which supports many input formats does not support XML as an input format when built in the stage1 profile. The output of its stage1 build would not change the number of binary packages built with the source package, it would just build a binary package with reduced functionality. Now it might be that a package build-depends on our package foo because it needs to translate documents in that XML format into something else, With your proposal, there's no way for the build-depending package to declare that it needs a version of foo that was built at a richer profile than stage1. Is this something you've considered? Glad you bring this up because we indeed forgot to mention this in our initial email. Yes, what you mention can indeed happen and this is also why extensive rebuilding is part of the build order: to make sure that all features are always compiled into the binaries. We have thought about this issue but did not manage to come up with a global solution. A solution would require a way to depend on features of a package and therefor create an overcomplicated dependency syntax which would not justify its purpose. There are two things that a developer could do to avoid such FTBFS errors during the bootstrap process when he modifies a source package with reduced stage1 build dependencies: - only remove build dependencies which do not modify the binary packages which are produced (instead, let some binary packages not be produced, like foo-doc, foo-java or foo-gtk) - look at the reverse dependencies in the generated dependency graph to make sure that features which are changed in built binary packages are not depended upon (naturally, those reverse dependencies will change over time...) Both solutions are very fragile. This is also why the developed algorithms try to build as few source packages as possible with reduced build dependencies. Do we have some experience of how common such errors are during a manual bootstrap? cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130117083416.GA26882@hoothoot
Re: Bootstrappable Debian - proposal of needed changes
Hi, On Thu, Jan 17, 2013 at 09:51:32PM +0100, Wouter Verhelst wrote: I'm not sure if wanna-build is the right tool to do this Why not? It already needs to do build-dependency tracking, marking packages as can't be built yet because build-depends aren't there yet all the time. That's exactly the sort of thing you need to be doing, no? No. The tool that actually does the build, doesnt have to keep track of which dependencies are met at any point (but is of course free to check anyways). Which source package is compiled when and which binary packages exist and are installable at which point is known by the dependency analysis tools that produced the build order. If the calculation of the build order went right, then at each compilation step, all dependencies will be met. So the tool doesnt have to have a way of knowing can't be built yet because build-depends aren't there yet. The tool is of course free to check anyways ;) It is also entirely possible to include the algorithms *into* the build tool and make them part of the process that figures out the can't be built yet because build-depends aren't there yet. Maybe this is what you meant. I mean in theory you could even drive a trivial dpkg-buildpackage wrapper or similar instead of something more fancy like wanna-build. I didnt think much about the actual implementation of this step yet (aka: what tools to use to do the actual compilation). After all profile built packages successfully rebuilt fully, *all* source packages of the strongly connected component are rebuilt. This is to make sure that every source package was built once with all build dependencies available. If you have enough information on what a package needs to build properly, you wouldn't need to do this. But I agree that's a pretty big if. There is a higher guarantee of a source package having built properly if it was built with all its dependencies in place because this is also how it had been normally built for other arches for (possibly) years. Bootstrapping is the exception and not the rule, so it is easy that the additional information you mention goes out of sync. By trading a bit more CPU time for a recompilation, the bootstrapper will have to worry less about having produced binary packages with a reduced feature set. We have thought about this issue but did not manage to come up with a global solution. A solution would require a way to depend on features of a package and therefor create an overcomplicated dependency syntax which would not justify its purpose. I'm not sure I agree with that. Your build profiles are essentially creating additional variants of a particular binary package. I imagine we should be able to come up with a syntax for the build-depends header which would allow one to declare you depend on a particular variant of a binary package. Let's say something like the following (extending the syntax as suggested by Ian Jackson earlier): Build-Depends: foo (profile:stage1 = 1.3) [profile:stage1], foo (= 1.3) [!profile:stage1] Essentially, with this syntax I'm saying that to build a the package which contains this build-dependency header, under normal circumstances you'd need the package foo at version 1.3 or above, as built with no profiles enabled; but if you enable the stage1 profile for this package, you can use the stage1 version of the foo package instead. I don't think this is too confusing or complicated, and I think it makes sense to add the profile to the version information in this manner; a () qualifier for a package could then be interpreted as a statement of *what* a package needs to comply with (version or profile of the build-dependency), whereas a [] qualifier would state *when* we need a particular build-dependency (architecture or profile of our *current* build). Sure, anything is possible. I just again worry about this being too fragile and the additional data not being maintained because it is only seldom used. But to go with your idea I have another proposal: Ian Jackson was proposing a syntax which combined build profile names and architecture names to create one format which describes restrictions on both: Build-Depends: foo [amd64 i386] [!profile:stage1 profile:stage2] The MultiArchCross spec [1] already defines a syntax on how to explicitly depend on a binary package of a specific architecture. Namely, the : character is used as a separator of package name and architecture in the same way it is used for the :any and :native qualifiers needed for dependencies on M-A:allowed packages. So somebody is able to write: Build-Depends: bar:amd64, baz:native This is not currently supported in Debian but I heard it is in Ubuntu and I also heard cross compilers need to depend on binary packages of a specific architecture, so I guess this syntax needs to be supported by wanna-build sooner or later? Ians proposal put profile names and architecture names in the same pot.
Re: Bootstrappable Debian - proposal of needed changes
Hi, On Fri, Jan 18, 2013 at 04:27:00PM -0800, Steve Langasek wrote: On Thu, Jan 17, 2013 at 08:33:57AM +0100, Wouter Verhelst wrote: Now it might be that a package build-depends on our package foo because it needs to translate documents in that XML format into something else, With your proposal, there's no way for the build-depending package to declare that it needs a version of foo that was built at a richer profile than stage1. The obviously correct solution to this is to strictly order the builds, by considering the stageX package builds as satisfying the build dependencies *only* of those packages that are part of the build loop. All other revdeps should wait until the final version of the package is available. In that case, misbuilds are only possible if there's an error in the bootstrapping metadata itself (or in the bootstrapping code). Unfortunately, in practice the problem is a bit bigger than individual cycles. We still call them cycles all the time because that's what people can imagine best. In reality, packages are involved in strongly connected components. When starting native compilation from a minimal build system (priority:essential plus build-essential plus debhelper), then the biggest problem is a strongly connected components with 900-1000 nodes. This means that each of the involved nodes is part of millions/billions of real cycles. This is partly why breaking this dependency graph with minimal cuts is an NP-complete problem and only approximate solutions are currently known. The approximate solution I came up with allows to break this strongly connected component into a directed acyclic graph with just modifying 83 source packages. The problem here is, that any of the packages in that strongly connected component is a (direct or indirect) reverse dependency of every other package in it. And also depending on which source packages are selected to be profile built, different orders are produced. And these different orders can all behave differently due to the kind of problem Wouter pointed out: because all packages in the SCC are potential (direct or indirect) reverse dependencies. And one can only reliably rebuilt all source packages of an SCC once all profile built packages have been rebuilt. But this again is only possible for all profile built source packages after all of the SCC has been solved. So there is no obvious solution of this problem to me because the size of the problem is a 900-100 big graph. Unfortunately, the size of this graph is also growing with Debian over time (as I already noted in our inital email): http://blog.mister-muffin.de/images/dep_graph_scc.svg cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130119104118.GA4367@hoothoot
Re: RFC declarative built-using field generation
Hi, On Fri, Feb 08, 2013 at 08:36:56AM +0100, Raphael Hertzog wrote: On Thu, 07 Feb 2013, Joey Hess wrote: Ben Hutchings wrote: What I mean is that a changes file for a sourceful upload has 'source' (and maybe some real architecture names) in the Architecture field. Therefore 'source' cannot be assigned as the name of a real architecture. Ah, sure. However, source in Build-Depends could be taken to mean that it Build-Depends on the source of the package. Which is not currently supported, but I'm sure everyone stuck maintaining foo-source binary packages would be happy if it were one day. So perhaps best not to overload it. There are apparently currently 67 .*-source.* packages in Debian Sid: $ grep-dctrl -P --pattern -source -c Packages 67 However, if this would get implemented, it would probably end up using the multiarch syntax foo:source (at least that seems to be the most logical choice to me). Since source packages can't have an architecture by themselves (only the architecture on which they are buildable), this seems sensible. In other places (like the debian bugtracker) src:pkgname is used. We also use src:pkgname in dose3. So this might be an alternative. So I don't believe that this would be in conflict with foo [source]. It might be a bit confusing though to use the same keyword in different situations (and furthermore it should be foo [any source] if we don't want the build-dependency to be dropped...). Another idea to mark source packages of build dependencies for inclusion in the built-using field would be using the syntax proposed by ian jackson in the Bootstrappable Debian thread: His idea encoded the information about which build dependencies are needed for a specific build profile like this: Build-Depends: huge (= 1.0) [i386 arm] [!profile:embedded !profile:stage1] He propose an extension to the architecture specification syntax using scopes (like profile). This extension could be used to mark the source packages of build dependencies for inclusion in the built-using field as well. Build-Depends: foobar (= 1.0) [i386 arm] [extras:built-using] As an example, I put the information in an extras scope. Maybe this makes sense. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130208081620.GA10547@hoothoot
Re: upstream advise page about circular dependencies (bootstrapping)
Hi, On Tue, Feb 12, 2013 at 07:55:42PM +0800, Paul Wise wrote: Which software is this and why does it need itself to build? Is it a compiler? There are many examples of source packages that build depend on binary packages they build. This includes languages like python, vala, sml, freepascal and haskell. But besides those simple cycles there are other cycles of length 2 when taking whole installation sets into account. For example src:pkg-config indirectly build depends on pkg-config because src:pkg-config build depends on libglib2.0-dev which depends on pkg-config. As the subject mentions bootstrapping, this extended type of self-cycle is of just as much importance as the first type mentioned initially. Here are all cycles of length two (both types) in Debian Sid as of January 2013. Each cycle contains one source package and one of its build dependencies. Sometimes those build dependencies are directly built by the source package itself (first type) and sometimes those build dependencies need binary packages the source package builds to be installed. texlive-latex-base - src:libtasn1-3 gtk-doc-tools - src:libtasn1-3 libldap2-dev - src:cyrus-sasl2 libpq-dev - src:cyrus-sasl2 heimdal-multidev - src:cyrus-sasl2 heimdal-dev - src:openldap gtk-doc-tools - src:gnutls26 texlive-latex-base - src:libgcrypt11 texlive-generic-recommended - src:libgcrypt11 libdbus-glib-1-dev - src:dbus python-dbus - src:dbus libgtk2.0-dev - src:avahi libgtk-3-dev - src:avahi python-gtk2 - src:avahi xfonts-utils - src:libfontenc ghostscript - src:cups default-jdk - src:java-atk-wrapper src:python2.7 - python lsb-release - src:python2.7 gdb - src:python2.7 openjade1.3 - src:opensp docbook-dsssl - src:opensp ghostscript - src:ijs docbook-utils - src:ijs src:colord - libgtk-3-dev kdelibs5-dev - src:libproxy libwebkitgtk-dev - src:libproxy libphonon-dev - src:phonon-backend-gstreamer libavformat-dev - src:x264 libffms2-dev - src:x264 libopencv-dev - src:libav libcv-dev - src:libav libgtk-3-dev - src:d-conf valac - src:vala-0.16 gcj-jdk - src:ecj gcj-4.7-jdk - src:ecj python-matplotlib - src:python-numpy fp-utils-2.6.0 - src:fpc fp-compiler-2.6.0 - src:fpc fp-units-base-2.6.0 - src:fpc fp-units-fcl-2.6.0 - src:fpc mlton - src:mlton src:sbcl - sbcl src:alex - alex gnat - src:gnat-4.6 gforth - src:gforth src:happy - happy src:hscolour - haskell-devscripts ghc - src:ghc libglib2.0-dev - src:pkg-config cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130212124038.GA28938@hoothoot
Re: upstream advise page about circular dependencies (bootstrapping)
Hi, On Tue, Feb 12, 2013 at 04:58:46PM +, Simon McVittie wrote: Either GLib or pkg-config should document how you can avoid this cycle by doing a stage 1 build of one project or the other. You assume a dependency cycle between the src:pkg-config and src:glib2.0. But instead I wrote that the cycle was: libglib2.0-dev - src:pkg-config So the only involved source package involved in the cycle is src:pkg-config. To break the cycle, src:pkg-config has to be built without libglib2.0-dev. Even if a native version of libglib2.0-dev was magically appearing from somewhere (for example by compiling src:glib2.0 without pkg-config as you explained) it would *not* break this dependency cycle because libglib2.0-dev would still depend on pkg-config which can only be compiled if src:pkg-config can be compiled. And src:pkg-config can't be compiled because it depends on libglib2.0-dev which we compiled beforehand but we can't install it. I also fell into the same trap countless times during the first weeks of my GSoC last year. :) A dependency cycle between two source packages (as you mentioned) would always be of length four because in between both source packages there would be a set of binary packages. Example: src:doxygen - libqt4-dev - src:dbus - doxygen This gives two possibilities to break the cycle: the dependency of src:dbus on doxygen or the dependency of src:doxygen on libqt4-dev. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130212172613.GA21015@hoothoot
Bootstrapping: list of 81 self-cycles in Debian Sid
Hi, Since self-cycles in Debian are often unintuitive, maintainers might be unaware that the source packages they maintain are actually forming a self cycle. I therefore created a wiki page with the list of the 81 self-cycles in Debian Sid as of 2013-01-01: http://wiki.debian.org/DebianBootstrap/SelfCycles Some extra explanations follow. During bootstrapping we must build some source packages with reduced build dependencies (build profiles) to work around cyclic build dependencies. At the same time we leave runtime dependencies of binary packages untouched. While the build dependency graph contains thousands of nodes and there exist many possible choices of build dependencies which would make the graph acyclic if they were removed, some build dependencies are non-optional and *must* be dropped: those which are part of self-cycles. Build dependencies which are part of self-cycles are not optional because self-cycles consist of only a single build dependency and a number of runtime dependencies. Since runtime dependencies are not to be touched, this single build dependency *must* be broken to be able to break the cycle. Since all cycles must be broken to make the graph acyclic, breaking self-cycles is also not optional. Therefor, if we enumerate a list of self-cycles in the build dependency graph, we automatically have a list of source packages and their build dependencies which must be part of a build profile (or be cross compiled). Self-cycles can be divided into two classes: 1. a build dependency on a binary package the source package builds (the simple case) 2. a build dependency on a binary package which needs one of the binary packages the source package builds to be installable The first class is easily detectable by checking whether any binary package is part of the build dependencies of the source package that builds it. Such cycles often appear in compilers that need themselves to be built. The second class is harder to find because it is not enough to simply traverse the dependency tree of a source package until one finds a dependency on one of the binary packages the source package builds. Instead, the strong dependencies [1] of a source package have to be calculated. If any of the strong build dependencies of a source package are built by the source package itself, a self-cycle is created. Such cycles are created by the interdependencies between binary packages and are often very unintuitive. Here two examples: src:gnutls26 build depends on libgnutls26 because src:gnutls26 build depends on gtk-doc-tools which needs libgnutls26 to be installable. src:libproxy build depends on libproxy0 because src:libproxy build depends on libwebkitgtk-dev which needs libproxy0 to be installable. My code found 81 such cases in Debian Sid as of 2013-01-01. Due to this high amount of results I pasted them into a wiki page instead of this email. http://wiki.debian.org/DebianBootstrap/SelfCycles If you find any inconsistencies, please dont hesitate to contact me or write to our mailinglist at debian-bootst...@lists.mister-muffin.de cheers, josch [1] Abate P, Boender J, di Cosmo R, Zacchiroli S. Strong Dependencies between Software Components ESEM 2009 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130305112246.25881.60404@hoothoot
Re: Bootstrapping: list of 81 self-cycles in Debian Sid
Hi, Quoting Samuel Thibault (2013-03-05 13:41:12) Maybe arch:all-only source packages should be shown in a different color: AIUI these do not pose a problem for bootstrapping a new Debian port, since one does not need to build the source package, and just pick up the existing _all.deb. They still pose a problem for bootstrapping debian from scratch, of course. Can you give an example of a source package which you think is wrongly included in the list? The code generating that list is part of the debian bootstrap project [1] and as such it would be a bug if architecture:all package were required to be recompiled for the reason you mentioned. cheers, josch [1] https://gitorious.org/debian-bootstrap/bootstrap -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130305134151.25881.28816@hoothoot
Re: Bootstrapping: list of 81 self-cycles in Debian Sid
Hi, Quoting Wouter Verhelst (2013-03-05 14:47:20) On Tue, Mar 05, 2013 at 02:41:51PM +0100, Johannes Schauer wrote: The code generating that list is part of the debian bootstrap project [1] and as such it would be a bug if architecture:all package were required to be recompiled for the reason you mentioned. In that case, rather than putting this up on a wiki page, would it be possible to run this tool periodically and post the output somewhere (under the debian.net or debian.org domain, preferably)? This is interesting information, but only if kept up to date. Wiki pages need to be updated manually, so having this run from cron every so often would be much more interesting. Yes, the information is likely to get outdated once some binary packages change their dependencies. Would it be possible to use existing Debian infrastructure to run this code instead of my own server which would be too low-spec for this kind of task? It would be trivial to write a shell script which runs the correct code for all architectures and all suites and outputs static html with the relevant information. Unfortunately, the code depends on some yet uncommitted fixes to dose3 [1] so compiling it is not yet too trivial but requires applying my patches first. cheers, josch [1] https://gforge.inria.fr/tracker/?atid=13808group_id=4395func=browse -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130305140743.25881.12276@hoothoot
Re: Bootstrapping: list of 81 self-cycles in Debian Sid
Hi, Quoting Samuel Thibault (2013-03-05 14:57:04) For instance commons-beanutils is only producing arch:all packages (I don't understand why it has separate Build-Depends and Build-Depends-Indep BTW), so AIUI, ports don't need to build it and thus do not have to care about the dependency loop. Thanks, I was wondering why there was so much java stuff in this list all of a sudden. The list is now updated to correctly take arch:all into account which was not the case before because I passed some arguments incorrectly. Thanks for the catch! cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130305141721.25881.15562@hoothoot
Re: Bootstrapping: list of 81 self-cycles in Debian Sid
Hi, Quoting The Wanderer (2013-03-05 15:35:37) You can build either one without a matching version of the other, but you won't get full functionality. In order to get the full functionality of both, from what I've been able to tell you need a minimum of three builds on every cross-matching-version update: x264 without libavformat support, then FFmpeg with x264 support, then x264 with libavformat support. (Or possibly the reverse, but x264 is faster to build than FFmpeg is.) Assuming you build x264 without libavformat, the correct order is actually: 1. src:x264 without libavformat-dev 2. src:libav fully 3. src:x264 fully 4. src:libav fully again We add the fourth step so that it is less likely that a libx264-dev with limited functionality influences the binaries built by src:libav in some funny way. Though in practice, src:x264 as well as src:libav are part of a big 900-1000 vertices big strongly connected component. So the actual build order is: 1. build tons of source packages (all source packages in the strongly connected component, so about 380-400), some of them fully, some of them with reduced dependencies 2. rebuild all source packages fully which were earlier built with reduced dependencies 3. rebuild the rest of source packages fully At a glance, this looks to me like a variant of the self-cycle problem. Is it something which should/could be addressed as part of the same effort? Or is it already handled in Debian in a way I haven't noticed? Or none of the above? Maybe I didnt understand you correctly but maybe it helps if I note that the example you give is not a self-cycle but a cycle of length two (or four depending on the type of dependency graph). Go to this wiki page: http://wiki.debian.org/DebianBootstrap/TODO And search for this string: src:libav - libx264-dev - src:x264 - libavformat-dev This is the cycle that you took as an example earlier. So yes, we can also find those cyclic dependencies but they are a different problem class because instead of having just one way to break them, there are now two: 1. either building src:libav without libx264-dev 2. or building src:x264 without libavformat-dev But those cycles are a bit less interesting because there are two possibilities to break it. So a bootstrapper must go and decide which of the two to build with reduced dependencies depending on which one is easier to modify, faster to build or because the structure of the surrounding dependency graph indicates that one build dependency has a much higher impact of the overall graph structure than the other. Our tools help to make the latter decision easier. I hope this helps a bit. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130305154626.25881.49802@hoothoot
Re: Bootstrapping: list of 81 self-cycles in Debian Sid
Hi, Quoting Simon McVittie (2013-03-05 16:54:00) This is useful information. Is there any way in which the maintainers of these packages can say yes, we know, and here is where you break the cycle without using unmerged dpkg features or breaking the freeze? I'm afraid there is little one can do right now because of the two reasons you mentioned. If somebody is very eager to help out, then one way to help is by expanding these lists: https://gitorious.org/debian-bootstrap/bootstrap/trees/master/droppable They are plain ascii text files which list the droppable build dependencies for source packages until build profiles are supported by Debian. The lists currently contain contributions from Thorsten Glaser, Patrick McDermott, Daniel Schepler, Wookey and Gentoo USE flags. The more complete these lists are, the better the current approximation of how a real Debian bootstrap would look like is. We are currently down to only 11 build dependencies our algorithms suggest to remove but of which we do not know whether this would be possible in practice or not. Those lists become obsolete once Debian supports build profiles and enough packages in the archive implement them. If not, now is not really the time to be doing anything about these cycles: wheezy has been frozen for well over 6 months, and maintainers who want to be able to fix 'important' bugs in wheezy are avoiding non-freeze-compatible changes to unstable. Agreed. I am not saying anybody should implement any of the suggestions right now (even creating patches for later would be a gamble until there is a decision on the profile format). Instead, I wanted to report this new ability of our bootstrap tools, raise awareness of the problem and educate maintainers about this type of issue during a bootstrap of Debian. I should've better explained my intentions in my initial email. :) It is unfortunate that this work is being done during a freeze because it means that nothing I implement right now can be tried out in practice without going through a ridiculous amount of work. But I rather wanted to implement all this functionality now than wait until the freeze is over. This way, once wheezy is released, we already have a number of tools which at least should work on paper. :D cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130305172517.26281.64856@hoothoot
Re: Bootstrapping: list of 81 self-cycles in Debian Sid
Hi, Quoting The Wanderer (2013-03-06 14:46:49) In that case, this (part of it) is a problem with my misunderstanding the terminology being used. The terminology is based upon the dependency representation in the dependency graph. We have two different types of graph, the source graph which only contains source packages and the build graph which also contains binary package nodes between source package nodes. My GSoC application contains a graphical representation of the build graph: http://wiki.debian.org/SummerOfCode2012/StudentApplications/JohannesSchauer The term self-cycle is used in the same way as in any other graph and just describes a self-edge: an edge which has the same start and end node. Those self-cycles can only exist in the source graph. In the build graph representation, self cycles are cycles of length two. If you look at the wiki page I linked to earlier, then you will see that the smallest cycles are of length two. This is because that wiki page and most of our work is based upon the build graph. This is the cycle that you took as an example earlier. So yes, we can also find those cyclic dependencies but they are a different problem class because instead of having just one way to break them, there are now two: Thank you. On the face of it this doesn't seem to address the question I was actually trying to ask (does this cycle-detection effort also detect soft dependencies which simply result in reduced functionality, as well as ones which result in build failures?), but the fact that this particular soft dependency is included in that - presumably automatically-generated - list implies that the answer is yes. No it doesnt. The software can only work on existing meta data. As of now, there exist no meta data about which build dependencies of a debian source package are droppable. That this cycle was detected does not mean that the software knows that it can be dropped. The cycle is a syntactic property of the dependency graph. For this cycle to exist it doesnt matter whether or not a dependency is droppable in practice. The fact that the build dependencies of the cycle in your example can be dropped in practice is pure luck. If you know any way to automatically generate these soft dependencies, dont hesitate to tell. Right now, those soft dependencies are supplied either manually or were harvested from Gentoo USE flags. I wrote another email in this thread about that topic. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130306144410.26281.18657@hoothoot
Re: Bootstrapping: list of 81 self-cycles in Debian Sid
Hi, I wrote a shell script which outputs the following static html: http://mister-muffin.de/bootstrap/selfcycles.html If you guys find this useful, then I can see how to get this generated periodically and published somewhere under the debian.org domain. Quoting Joerg Jaspert (2013-03-06 09:07:44) That obviously depends a bit on what is actually needed to run (and then on talking to DSA, but they don't bite so much :) ). If it is found useful, then I have to figure out who to contact about this. I guess you need a mirror (or at least packages/sources files) as input, though you might want to check if you can use an existing database within Debian to just use the already exsiting data. Yes, the input to the code is just a pair of Packages.bz2 and Sources.bz2 files. For the output you see in the link above, they total to a size of 500MB. If they can be retrieve directly from somewhere on the same machine, then it would naturally save lots of space. And then whatever $packages. And disk space, RAM, CPU requirements. disk space: Executables are only a few megabytes. Packages.bz2 and Sources.bz2 files total to 500MB if they have to be downloaded from a mirror. RAM: The highest amount I observed was 260 MB of used resident memory. This value is that high because the build dependency graph and the strong dependency graph of the whole distribution has to be kept in memory at the same time. CPU: The whole script producing the output above took 7 hours to run on a 2.5GHz Core i5 for all suites and all architectures (38 combinations). This is because generating strong strong dependencies for all packages in the archive takes 8-10 minutes with current archive sizes. I dont think this value can considerably be lowered. On the other hand, the cron job doesnt have to be run every day but maybe once a week or once a month? Now, your data input: What are you using? You might want to check if the buildd or archive databases don't already hold the data you need (or are easily extended to do so), and then just use that instead of duplicating the extraction. Input is a pair of Packages.bz2 and Sources.bz2. From that a dependency graph is generated. Strong dependencies are calculated and the graph is annotated with them. I dont think that neither dependency graphs nor strong dependencies are information which currently exist elsewhere. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130306175647.26281.72388@hoothoot
Re: Bootstrapping: list of 81 self-cycles in Debian Sid
Hi, Quoting Michael Tautschnig (2013-03-06 19:22:37) What about parallelizing parts of the job? Sure, the html page I linked to contains 38 different data points: - 11 architectures from stable - 13 architectures from testing - 14 architectures from unstable The most trivial way of parallelizing the generation would be to execute those 38 jobs in parallel. With 38 processors and enough RAM, the generation would just take 12 minutes. It might be possible compute strongly connected components of the graph first, and then do the job for each component? Strongly connected components do not play a role for this task. They are not calculated at any point. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130306190056.26281.74543@hoothoot
Re: Bootstrapping: list of 81 self-cycles in Debian Sid
Hi, Quoting Simon McVittie (2013-03-05 16:54:00) On 05/03/13 11:22, Johannes Schauer wrote: Since self-cycles in Debian are often unintuitive, maintainers might be unaware that the source packages they maintain are actually forming a self cycle. This is useful information. Is there any way in which the maintainers of these packages can say yes, we know, and here is where you break the cycle without using unmerged dpkg features or breaking the freeze? Actually, yes. Here is the full list of things available to the bootstrapper when encountering a build dependency cycle: 1. Introduce reduced build dependencies 2. Move dependencies from Build-Depends to Build-Depends-Indep 3. Use Multi-Arch:foreign packages to satisfy dependencies 4. Choose different installation sets for not-strong dependencies 5. Split the source package in question 6. Make binary packages available through cross compilation The first item is obviously not implementable right now. But the second one is! The third solution depends on the target the bootstrap is done for. The fourth item is of no concern for this type of cycle. The fifth one is implementable right now. The sixth is always the last resort. So it is possible right now for maintainers to say yes, we know, and here is where you break the cycle without using unmerged dpkg features or breaking the freeze by either 2. moving the dependency to Build-Depends-Indep (if the build dependency only builds Architecture:all packages) or 5. by splitting the source package into two I was reminded of the option to split a source package by bug#702620 [1] which splits colord-gtk from colord. Just note that splitting might not always be sensible as cycles might simply vanish once some dependencies of binary packages in the dependency chain change. Though in this case one can probably be sure that libgtk-3-0 will always depend on libcolord1? cheers, josch [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702620 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130309071856.3714.93257@hoothoot
Re: Generators for debian/* files?
Hi, Quoting Wookey (2013-04-05 12:17:42) Because it's an entirely unnecessary circular build-dependency. java is not part of build-essential and this doesn't seem like a good reason for making it so. mh_make is part of the package maven-debian-helper (Thomas: I cant find the package debian-java you were talking about) but according to the bootstrap tools, maven-debian-helper is not part of any dependency cycle. I would be glad if you can prove me wrong because then you found yet another bug in my code. :) A java helper which is part of many dependency cycles, is the package javahelper which is part of the main SCC. It seems that 233 source packages relevant for the bootstrap process build depend on javahelper (out of a total of 290 source packages build depending on it). cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130405114542.14032.2997@hoothoot
Re: idea: generalized soft dependencies
Hi,
Without discussing whether adding generalized soft dependencies would be a
good idea or not, let me give you my two cents about the syntax.
Quoting Eugene V. Lyubimkin (2013-05-08 20:51:54)
Soft-Depends: a {90%}, b (= 1.2) {20%}, c (= 4) {99%}, c (= 6) {70%}
Soft-Depends: iceweasel {50%,tag:desktop}, curl {95%,if_not_installed:wget}
Soft-Depends: debdelta {10%,text:to enable automatic delta downloading}
We (myself+wookey) recently proposed a new syntax to tag build dependencies
with build profiles for bootstrapping [1] but it was deemed not to be a good
idea to introduce a new meta character. Instead, it seems that your proposal
can easily be implemented using the unified qualifier proposal that was made by
Ian Jackson in the same thread [2] which does not spend an additional meta
character but extends the architecture qualification syntax:
Soft-Depends: a [minthresh:90], b (= 1.2) [minthresh:20], c (= 4)
[minthresh:99], c (= 6) [minthresh:70]
Soft-Depends: iceweasel [minthresh:50 tag:desktop], curl [minthresh:95
!installed:wget]
I also started a thread to discuss Ian Jackson's proposal on d-dpkg@l.d.o [3]
where Raphael Hertzog gave a use case [4] for this syntax similar to the one
which you address here.
cheers, josch
[1] http://lists.debian.org/20130115181840.GA16417@hoothoot
[2] http://lists.debian.org/20726.45081.38709.233...@chiark.greenend.org.uk
[3] http://lists.debian.org/20130419194252.17205.76995@hoothoot
[4] http://lists.debian.org/20130421194955.gb2...@x230-buxy.home.ouaza.com
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130509070158.18633.47628@hoothoot
Re: Debian development and release: always releasable (essay)
Hi, Quoting Paul Wise (2013-05-11 10:40:18) Lucas created a script that displays a list of important packages, puppet isn't on that either: http://udd.debian.org/cgi-bin/important_packages.cgi Not surprising as the algorithm (from what can be read in the comments) executes what we call build_closure algorithm in this paper [1]. During bootstrapping we execute the same algorithm with the only difference that we do not pull in source packages that only contribute arch:all packages (for obvious reasons). While we also recognized this selection of packages as important from a bootstrapping point of view (as it contains the largest strongly connected component in the dependency graph) it is not surprising that puppet is not in it. Instead, puppet is just a leaf package in the dependency graph. So while the set of source packages found by the build_closure algorithm should certainly be part of the important packages, this also shows an observation that we made during dependency graph analysis: The syntax of the dependency graph is not enough to make semantic conclusions of the contained packages. So instead, the important packages should be the union of: - the result of the build_closure algorithm - the transitive dependencies of all tasks and all blends - ??? Maybe the puppet question can just be solved by introducing an openstack task? Adding new tasks could help codify the set of features that are deemed important. cheers, josch [1] http://mancoosi.org/~abate/bootstrapping-software-distributions -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130511093758.32278.6057@hoothoot
Re: Source build-dependencies
Hi, Quoting Paul Wise (2013-05-12 04:03:54) Another one I would like is to be able to depend or build-dep on foo:build-depends or foo [Build-Depends] (or by extension foo:depends), which would mean we could get rid of the ugly hack that is mk-build-deps. Should a dependency of a source package src:A on src:foo not mean that src:A also automatically build depends on the build dependencies of src:foo? It would be weird if the transitive dependencies are taken into account for build dependencies on binary packages but not for build dependencies on source packages. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130512051516.32278.72480@hoothoot
Re: DebianBootstrap supported in which Debian suites?
Hi, I talked with Lisandro off-list. Apparently my idea applies to this problem so I'm sharing it here for everybody. :) Quoting Wookey (2013-06-07 17:55:48) In general we don't have a mechanism to do this _in the archive_ until build-profiles are supported (or at least ignored by B-D parsing tools) You can bootstrap happily using local builds and local tools that support profile builds. Existing patches here: http://people.debian.org/~wookey/bootstrap/patches/profiles/ Then just upload the final builds, and sources with the profile info only encoded as comments. As *-doc packages are arch:all you can also move the dependencies needed to build the doc packages to Build-Depends-Indep. One kind of build dependency which can be dropped in most cases to break build dependency cycles are those build dependencies which only facilitate building the documentation. But since binary packages containing documentation packages are mostly arch:all, no build profiles and therefore no unsupported !stage1 syntax is needed for this case. Adding the respective build dependencies to Build-Depends-Indep solves the problem just as well. Using the (yet unsupported and undecided upon) build profile syntax should be avoided if the problem can also be solved by moving build dependencies to Build-Depends-Indep. So one thing every maintainer can do to help making bootstrapping of Debian more simple is to make sure that all build dependencies which can go to Build-Depends-Indep are also listed there. During bootstrapping we discard the contents of the Build-Depends-Indep field as we are only interested in building architecture dependent binary packages. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130607214206.3820.15475@hoothoot
Re: Candidates for removal from testing (2013-06-30)
Hi, Quoting Lucas Nussbaum (2013-07-01 08:21:30) Currently, the following criterias are used: | Key packages are: | - packages whose popcon is higher than 5% of the max popcon (that's | 7570 insts currently) | OR | - packages of priority = standard | OR | - packages of section debian-installer | OR | - debian-installer, debian-cd, piuparts | OR | - build-dependencies of key packages [binary dependencies are covered | by the popcon criteria] How are dependency disjunctions in direct or indirect build dependencies handled? Which package is selected if a key package Build-Depends: A | B? And are you only talking about direct build dependencies or also indirect build dependencies? In the latter case, the amount of possible choices (installation sets) becomes even higher. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130701130056.14706.49386@hoothoot
Bug#714956: ITP: brickutils -- Utility for organizing your collection of LEGO(R) bricks
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: brickutils Version : 0.1.6.1 Upstream Author : Mario Pascucci mpascucci gmail com * URL : http://bricksnspace.wordpress.com/brickutils/ * License : GPL2+ Programming Lang: Python Description : Utility for organizing your collection of LEGO(R) bricks The main problem that BrickUtils tries to solve is to answer the question: can I build this model with the bricks I own? It allows one to import LEGO(R) models in different CAD formats (LDraw and LEGO(R) Digital Designer) and check if one can build that model with the pieces one owns. Parts lists can be exported in various formats, including printable HTML or bricklink XML to easily buy missing pieces at bricklink.com. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130704155436.14245.77281.reportbug@hoothoot
Bug#714999: ITP: ldraw-parts -- LDraw LEGO(R) parts library
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: ldraw-parts Version : 1203 Upstream Author : LDraw.org and others (see debian/copyright) * URL : http://www.ldraw.org/parts/latest-parts.html * License : CCAL-2.0 Programming Lang: C Description : LDraw LEGO(R) parts library The source package builds two binary packages. The package ldraw-parts contains the (architecture independent) part library and the package ldraw-mklist contains the (architecture dependent) program ldraw-mklist to create a parts.lst file. Package: ldraw-parts Description: LDraw LEGO(R) parts library Library of LDraw parts, part primitives and two example models. This part library is needed by 3D CAD programs such as MLCAD, LeoCAD and Konstruktor which allow to construct LEGO(R) models from individual LDraw parts. It is also needed by rendering software such as LDView and LdGLite. Package: ldraw-mklist Description: LDraw mklist program 3D CAD programs and rendering programs using the LDraw parts library of LEGO(R) parts rely on a file called parts.lst containing a list of all available parts. The program ldraw-mklist is used to generate this list from a directory of LDraw parts. Having this package in Debian is the prerequisite for packaging more of the tools mentioned above which depend on this part library. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130705104216.1204.59555.reportbug@hoothoot
Bug#715053: ITP: ldglite -- Display, edit and render 3D LEGO(R) LDraw models
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: ldglite Version : 1.2.6 Upstream Author : Don Heyse dhe...@hotmail.com * URL : http://ldglite.sourceforge.net/ * License : GPL2+ Programming Lang: C Description : Display, edit and render 3D LEGO(R) LDraw models The program ldglite allows one to open LDraw files to view 3D LEGO(R) models using openGL. It also offers an editing mode to change and save those models. In batch processing mode it allows one to render models to png images. A program like ldglite or ldview is needed to render raster graphics of pieces and models which can then be used by brickutils or lpub. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130706011138.22247.62629.reportbug@hoothoot
Bug#715280: ITP: ldview -- OpenGL based viewer and renderer for LEGO LDraw 3D models
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: ldview Version : 4.2 beta1 Upstream Author : Travis Cobbs and Peter Bartfai * URL : http://ldview.sourceforge.net/ * License : GPL2 Programming Lang: C++ Description : OpenGL based viewer and renderer for LEGO LDraw 3D models The program can read LDraw dat and mpd files. It allows one to display them and manipulate the perspective and rendering options using commandline arguments as well as through a QT based GUI. It offers a batch mode which allows one to produce PNG raster graphics from LDraw models or pieces. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130707152622.7715.19317.reportbug@hoothoot
Re: asking for advice: all dependencies incl. version numbers
Hi, Quoting FARKAS, Illes (2013-08-22 17:47:57) I'd like to download/parse for each version of each debian package which other package versions it depends on. Do you think this information available in managable formats? In addition to the information Joachim already gave, let me specifically point you at dose3. It is a framework for working with dependencies and allows you to parse Packages.bz2 and Sources.bz2 files, create all kinds of dependency graphs and analyze them and includes a solver for package relationships. Have you seen similar work before? Joachim was pointing you at edos. There exists the tool edos-debcheck (or edos-distcheck as a more general tool) in the main archive. But instead you might want to look at the dose3 tools which supersede the edos tools. More specifically you want to look at the binary packages built from the source package dose3. The dose-extra binary package contains a tool called ceve which allows you to build many different kinds of dependency graphs from a Packages.bz2 file. Maybe this gives you the information you need. Contact me if you have any trouble. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130823094312.4755.71787@hoothoot
Re: asking for advice: all dependencies incl. version numbers
Hi, Quoting FARKAS, Illes (2013-08-27 10:17:47) According to the developer info page of the package (http:// packages.qa.debian.org/0/0ad.html) there have been also previous versions of the package 0ad, for example, versions 0.0.12 and 0.0.11. I would be curious to know too the list of package versions that 0ad-0.0.12, 0ad-0.0.11, etc depend on. You can find Packages.bz2 files from Debian all the way back to 2005 at http://snapshot.debian.org by downloading a sample of these (say, every few days), you can possibly get enough data for older versions of every package maintained in Debian since then. Unfortunately, older versions of Packages.b2 files on snapshot.d.o contain errors which make it impossible for dose3 to parse them. Since later in your email you said you might want to use dose3, you might want to have a look at this script I wrote to clean up and repair old Packages.bz2 files from snapshot.d.o so that dose3 can parse them: https://gitorious.org/debian-bootstrap/botch/source/examples/snapshot/download.sh That script downloads and cleans Packages.bz2 and Sources.bz2 from snapshot.d.org in a five day interval starting in 2005. You can find a bit more here: http://blog.mister-muffin.de/2012/10/12/analyzing-packages-and-sources-from-snapshot.debian.org/ The result can then be parsed with dose3. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130827084250.5326.87466@hoothoot
Re: UTF-8 in jessie
Hi,
Quoting Adam Borowski (2013-08-12 02:51:52)
On Mon, May 06, 2013 at 02:49:57PM +0200, Andreas Beckmann wrote:
now might be the right time to start a discussion about release goals
for jessie.
I would like to propose full UTF-8 support. I don't mean here full
support for all of Unicode's finer points, merely complete eradication of
mojibake. That is, ensuring that /m.o/ matches möo, or that ä sorts
as equal to acombining ¨ is out of scope of this proposal.
I propose the following sub-goals:
1. all programs should, in their default configuration, accept UTF-8 input
and pass it through uncorrupted. Having to manually specify encoding
is acceptable only in a programmatic interface, GUI/std{in,out,err}/
command line/plain files should work with nothing but LC_CTYPE.
as an addendum to this release goal proposal, it is maybe also worth mentioning
working multibyte character support in coreutils as a possible goal.
From http://bugs.debian.org/139861 :
$ echo -e 日\n本\nで\nは | sort -u | wc -l
3
$ echo -e 日\n本\nで\nは | sort | wc -l
4
Or having head/tail which work character base instead of byte based would be
sweet as well.
While upstream doesnt seem to support this, it seems that Fedora has a patch
for coreutils:
http://pkgs.fedoraproject.org/cgit/coreutils.git/tree/coreutils-i18n.patch?id=6e10f376996b64f538259091a524df2249b653fb;id2=HEAD
or also:
http://trac.cross-lfs.org/browser/patches/coreutils-6.12-unicode-1.patch?rev=577dd2d59133e10bd32c58844293e93af0e6f162
cheers, josch
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131014105058.7934.26083@hoothoot
Bootstrappable Debian - a decision is needed, patches exist
Hi, This email is a follow up on the thread started January 2013 [1]. In summary: it seems that the ability to bootstrap Debian from scratch and the requirement to extend the Build-Depends syntax meet general agreement. What is yet to be decided is the concrete format for the Build-Depends syntax extension. The first proposals suggested a syntax which looked like Build-Depends: foo [amd64] !stage1 Which would indicate that the build dependency foo would not apply if the build profile called stage1 is activated. It was critisized [2] that this syntax wastes a meta character and thus prohibits future extensions of the Build-Depends syntax. Therefore the second proposal (finalised at debconf13) looked like this: Build-Depends: foo [amd64] [!profile.stage1] The rectangular brackets are reused and a prefixed namespace is used to indicate that stage1 is a build profile name. We hoped this would be the final spec, given the previous discussion, but those brackets also got some pushback [3] and thus the third version was born: Build-Depends: foo [amd64] !profile.stage1 We wrote down the last two options in form of a spec on the Debian wiki [11]. Patches for dpkg, python-debian, apt and sbuild implementing the original format have existed for years [4]. Patches for the new formats have existed for some time as well [5]. They are surely not perfect but we would like to get them into a state in which they can be integrated into dpkg. But for that we need some feedback from the dpkg devs as well as a final decision of the Debian community about which syntax to choose. We are writing to d-devel this time because the thread on d-dpkg [6,7] has been dormant for a month once again. Maybe bringing this issue to a wider audience will help make a decision on this problem. The results from two years of GSoC [8,9] as well as the year long efforts of others [10] cannot bear any fruit without this issue finally being taken care of. Thank you! josch wookey [1] http://lists.debian.org/20130115181840.GA16417@hoothoot [2] http://lists.debian.org/20726.45081.38709.233...@chiark.greenend.org.uk [3] http://lists.debian.org/20130816121504.gb20...@gaara.hadrons.org [4] http://people.debian.org/~wookey/bootstrap/patches/profiles/tools/ [5] http://lists.debian.org/20130917103117.2726.40546@hoothoot [6] http://lists.debian.org/20130419194252.17205.76995@hoothoot [7] http://lists.debian.org/debian-dpkg/2013/08/msg00019.html [8] http://www.alkmim.eti.br/~alkmim/gitrepo/autobootstrap.git [9] https://gitorious.org/debian-bootstrap/botch [10] http://people.debian.org/~wookey/bootstrap [11] https://wiki.debian.org/BuildProfileSpec -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131015060337.7934.42627@hoothoot
Re: Bootstrappable Debian - a decision is needed, patches exist
Hi, Quoting YunQiang Su (2013-10-15 08:08:52) On Tue, Oct 15, 2013 at 2:03 PM, Johannes Schauer j.scha...@email.de wrote: What is yet to be decided is the concrete format for the Build-Depends syntax extension. The first proposals suggested a syntax which looked like Build-Depends: foo [amd64] !stage1 I'd prefer Build-Depends-Stage1 if possible. When bootstrap, dpkg only ask for these build-depends while for normal build, dpkg should merge Build-Depends-Stage1 and Build-Depends. this approach does not work because it does not allow to specify additional dependencies for when a source package is compiled with a certain profile activated. The Build-Depends-Stage1 field name was used in earlier proposals with a different meaning. Instead of making the final build dependencies the union of Build-Depends and Build-Depends-Stage1 as you proposed, Build-Depends-Stage1 contained all dependencies necessary for the build profile stage1. When doing a normal build, only the Build-Depends would be used. When building with the build profile stage1 activated only the Build-Depends-Stage1 would be used. This solves the problem I explained above which your solution has. This Build-Depends-Stage1 format was abolished in favor of the syntax additions explained in my last email because of the following reasons: - it requires variable field names to match all possible profiles - it requires a near duplication of the Build-Depends field which is highly prone to bitrot - it does not work with multiple profiles activated at the same time For a full history of the development of this see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661538 cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131015063400.7934.32962@hoothoot
Re: Bootstrappable Debian - a decision is needed, patches exist
Hi Steve, Quoting Steve Langasek (2013-10-20 05:46:15) My recollection is that the abolishing of the Build-Depends-Stage1 field was done by the same dpkg maintainer who you say is now not giving you feedback. Correct. It's elegant that a general-purpose syntax has been proposed, but elegance isn't worth anything if it doesn't result in shipping code. Being able to automatically bootstrap the Debian archive is self-evidently useful to the project. The other uses proposed for profiles are all corner cases that should be kept far, far away from the archive. I don't think the implementation of automated bootstrapping should be allowed to block on such pie-in-the-sky plans for profiles. My understanding is that all build-dependency loops in the archive can be broken with a single additional stage (stage1), so only one added profile and one added build-dependency field would be required. Yes, it could bitrot, but it's better than not having any of the data in the source packages at all. I agree with you and from my talking to wookey, he probably agrees too, that *any* solution is fine as long as it's accepted by dpkg devs and allows us to finally make Debian bootstrappable. You nicely summarized the situation and I dont think I have much more to add. Yes, falling back to the Build-Depends-Stage1 proposal (for which patches also existed for over a year, see bug#661538) would also fully satisfy our needs for now until something fancier is needed. In addition, my analysis from last year showed that probably below 70 source packages have to be modified to make everything bootstrappable. If that is the case, then any future switch to something different might still be managable. And if someone really finds this inelegant and insists that we should extend the syntax of the Build-Depends field, let them step up and make that happen instead of pointing at grandiose plans they're not making any effort to implement. A Build-Depends-Stage1 field requires no support from dpkg in the archive to implement. I would love if that person did. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131020064754.10620.38358@hoothoot
Re: Bits from the Release Team (Jessie freeze info)
Hi, (I was not able to find the debian-ports list on lists.debian.org (so I subscribed via email) did I just miss it?) Quoting Steven Chamberlain (2013-10-23 22:04:59) I had a play with the 'botch' tool (see description[1]) for determining build order when bootstrapping an architecture. botch author here. Just stumbled upon this already a few day old email in my inbox :) To start off with it determines a minimum required set of packages - you'd normally cross-compile those from another system. This set (see attached example list for kfreebsd-amd64 wheezy) looks to me like what constitutes the 'toolchain'. This minimum set of packages which has to be cross compiled (because no binary package of the target architecture exists at this point) is what we call the minimal native build system (the name is misleading as disjunct dependencies make different choices of this set possible). Currently it is not possible to present a correct selection of source packages which have to be cross compiled to produce the minimal build system. What we currently do is to just do: grep-dctrl -X \( -FPackage build-essential --or -FPackage debhelper --or -FEssential yes) and assume that the resulting list of packages (the one you attached to your last email) is cross compilable from nothing. This is of course not the case in practice but a formal analysis is not possible yet. This is because multiarch annotations are missing in some packages and because of the problem of how to handle source packages directly depending on gcc, g++, binutils etc in the cross compilation case. While the first one is easy to fix there doesnt exist a solution for the second one yet. Build profiles would be able to solve the second problem. Until these two issues are fixed we will not be able to get an algorithmic answer to the question of what constitutes the minimum required set of packages. On the other hand wookey did lots of ubuntu crossing and identified that with just (I think it was) a dozen modified packages (reducing their build dependencies to break cross build dependency cycles) he was able to cross build all of these packages: http://people.linaro.org/~wookey/buildd/raring-arm64/status-bootstrap.html So while an automated analysis is not possible right now, it also does not seem to be necessary to have this automated. Having the to-be-crossed selection of packages retrieved automatically becomes more interesting as more source packages are known to be cross-compilable including all their required recursive build dependencies. The list will be different for each port, and change over time. This example included freebsd-libs, freebsd-utils and kfreebsd-kernel-headers but of course others won't. Thanks for trying out botch for kfreebsd :) AIUI those packages should be able to rebuild each of themselves without any other dependencies. Should but unfortunately they are not :( In fact, to nativel rebuild the minimal build system for amd64 (just essential:yes + build-essential + debhelper) one needs to be able to compile 383 source packages (excluding the source packages in the minimal build system itself). This is as of debconf13 when I last ran those scripts. You can look at the numbers here as well: http://mister-muffin.de/bootstrap/stats/ These 383 source packages include ugly ones like iceweasel, nautilus, webkit, network-manager, mysql, kde4libs which as you can imagine draw in half of what makes a modern desktop system and thus might naively have been dismissed as non-essential for the bootstrapping purpose at all. But of course this list will be different between arches. I think doing that regularly would be a good health check for a port's toolchain. Probably these packages would be the focus of the reproducible-builds project, at least from a security point-of-view. Any differences in output of subsequent builds are of interest, and would potentially reveal when significant changes or bugs were introduced too. Being able to use botch to automatically bootstrap all arches from scratch has always been one of botch's goals. Unfortunately the build profile discussion is holding up the implementation of this in practice but guillem promised to look into this for dpkg 1.17.2. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131026213931.16796.6@hoothoot
on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))
Hi Peter, Quoting peter green (2013-10-27 01:11:24) Johannes Schauer wrote: Until these two issues are fixed we will not be able to get an algorithmic answer to the question of what constitutes the minimum required set of packages. There is also the complication of what I will call non-key self building compilers. fpc is an example Yes, this is also an issue and the two issues I mentioned are only a necessity but not a sufficiency for the whole bootstrap problem. In practice, it is of course not only needed to know that one must be able to build src:fpc without all the fp-* binaries (that's what my algorithms do right now) but also that this is really possible in practice. Since I only work with the algorithmic side of things I often forget to mention that one naturally needs more than correct meta data (dependency relationships) to make everything work :) You will find your example (fpc) in the section of Type 1 Self-Cycles on http://mister-muffin.de/bootstrap/stats/ together with other compilers like for haskell, sml or lisp. We call Type 1 Self-Cycles those where the source package directly build depends on a binary package it builds. Those are the most obvious self cycles and they are mostly made up of the non-key self building compilers as you call them. These are not needed to bootstrap the core of debian but if one wants to bootstrap all of debian they will need to be built. Indeed, none of the Type 1 Self-Cycles are needed to bootstrap the core of Debian. Unfortunately though, most of the Type 2 Self-Cycles are. You will find many surprising (at least to me) examples in the section of Type 2 Self-Cycles under the above link. We call Type 2 Self-Cycles those where the source package indirectly and strongly [1] build depends on a binary package it builds. They are hard to find because the only tool which is able to compute strong dependencies (afaik) is dose3 which is used by botch to do the required computations. [1] www.mancoosi.org/papers/esem-2009.pdf Surely every maintainer of source packages involved in a Type 1 Self-Cycle knows about this issue. Because Type 2 Self-Cycles are non-obvious we could in the future (once build profiles are available) embed this information in the pts for the relevant packages. On the other hand, there only exist a small number (26 for amd64) source packages involved in Type 2 Self-Cycles so it might be enough to just post priority wishlist bug reports for each of them. Since the only way to build them is with themselves they cannot be bootstrapped natively even with the help of build profiles. So the only way to bootstrap them is to either cross-build them or start with a binary from upstream. And even compilers which allow some way of bootstrapping them, do not have this process automated (ghc [2], mlton [3]). This is fine under the assumption that initial porting is rarely done and once it's done does not have to be repeated. But it does not allow continuous testing of bootstrappability of the whole archive. [2] http://ghc.haskell.org/trac/ghc/wiki/Building/Porting [3] http://mlton.org/PortingMLton cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131027083354.16796.89806@hoothoot
Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))
Hi Daniel,
Quoting Daniel Schepler (2013-10-27 16:06:43)
Johannes Schauer wrote:
Indeed, none of the Type 1 Self-Cycles are needed to bootstrap the core of
Debian. Unfortunately though, most of the Type 2 Self-Cycles are. You will
find
many surprising (at least to me) examples in the section of Type 2
Self-Cycles under the above link.
On the other hand, if you count Build-Depends-Indep and Architecture: all
packages as part of what you want to bootstrap, then gnat-4.6 does get pulled
in...
gzip Build-Depends-Indep: mingw-w64
mingw-w64 Build-Depends: gcc-mingw-w64-{i686,x86_64}
gcc-mingw-w64 Build-Depends: gnat-4.6
(And also, you have the issue that gcc-4.8 Build-Depends on libantlr-java and
libecj-java, whose builds require either gcj-4.8 from the same source
package,
or openjdk-7-jdk which also Build-Depends on ecj.)
I realize that these sorts of issues aren't as important for the practical
problem of bootstrapping a new port; but ideally, from a philosophical point
of view we should be able to bootstrap all our packages. (To be honest, the
Java packages are such a tangled mess that I've given up on trying to
bootstrap that part of the archive for now -- and many of those do get pulled
into the minimal set of ca. 1473 source packages I get with my criteria.)
you can easily use botch for an analysis of dependency cycles under your
conditions as well. Botch is a collection of tools doing some mangling with
sets of binary and source package metadata and creating and analyzing a graph
build from them. By calling the involved tools a bit differently than it is
done in the example shell script (which is to demonstrate the practical
bootstrap scenario and thus drops B-D-I and arch:all) you can also analyze the
situation you are talking about.
More specifically, you want to change how the create_graph binary is called.
The --available option expects a filename of a file containing the list of
packages which is expected to be available in the bootstrapping sense [1].
This file is currently compiled containing all arch:all and all cross compiled
binary packages. You are free to not add any arch:all packages or only some to
that list.
Secondly, per default B-D-I dependencies are ignored but you can pass the
--keep-indep argument to the create_graph binary to let them be considered
nevertheless.
cheers, josch
[1] https://gitorious.org/debian-bootstrap/pages/Terminology#Availability
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131027152758.16796.78747@hoothoot
announcing bootstrap.debian.net
Hi, I cross posted the following message on my blog: http://blog.mister-muffin.de/2013/11/05/announcing-bootstrap.debian.net/ While [botch][1] produces loads of valuable data to help maintainers modifying the right source packages with build profiles and thus make Debian bootstrappable, it has so far failed at producing this data in a format which is: - human readable (nobody wants to manually go through 12 MB of JSON data) - generated automatically periodically and published somewhere (nobody wants to run botch on his own machine or update periodically update the [TODO wiki page][2]) - available on a per-source-package-basis (no maintainer wants to know about the 500 source packages he does NOT maintain) While human readability is probably still lacking (it's hard to write in a manner understandable by everybody about a complicated topic you are very familiar with), the bootstrapping results are now generated automatically (on a daily basis) and published in a per-source-package-basis as well. Thus let me introduce to you: [bootstrap.debian.net][3] Paul Wise encouraged me to set this up and also donated the debian.net CNAME to my server. Thanks a lot! The data is generated daily from the midnight packages/sources records of [snapshot.debian.org][4] (I hope it's okay to grab the data from there on a daily basis). The resulting data can be viewed in HTML format (with some javascript for to allow table sorting and paging in case you use javascript) per architecture ([here][10] for amd64). In addition it also produces HTML pages per source package for all source packages which are involved in a dependency cycle in any architecture (for example [src:avahi][11] or [src:python2.7][12]). Currently there are 518 source packages involved in a dependency cycle. While this number seems high, remember that estimations by calculating a feedback arc set suggest that only 50-60 of these source packages have to be modified with build profiles to make the whole graph acyclic. For now it is funny to see that the main architectures do not bootstrap (since July, for different reasons) while less popular ones like ia64 and s390x bootstrap right now without problems (at least in theory). According to the logs (also accessible at above link, [here][13] for amd64) this is because gcc-4.6 currently fails compiling due to a build-conflict (this has been reported in [bug#724865][5]). Once this bug is fixed, all arches should be bootstrappable again. Let me remind you here that the whole analysis is done on the dependency relationships only (not a single source package is actually compiled at any point) and compilation might fail for many other reasons in practice. It has been the idea of Paul Wise to integrate this data into the pts so that maintainers of affected source packages can react to the heuristics suggested by botch. For this purpose, the website also publishes the raw JSON data from which the HTML pages are generated ([here][14] for amd64). The bugreport against the bts can be found in [bug#728298][6]. I'm sure that a couple of things regarding understandability of the results are not yet sufficiently explained or outright missing. If you see any such instance, please drop me a mail, suggesting what to change in the textual description or presentation of the results. I also created the following two wiki pages to give an overview of the utilized terminology: - [Explaining basic terminology][7] - [Explaining used heuristics][8] Feel also free to tell me if anything in these pages is unclear. Direct patches against the [python code][9] producing the HTML from the raw JSON data are also always welcome. cheers, josch [1]: https://gitorious.org/debian-bootstrap/botch [2]: https://wiki.debian.org/DebianBootstrap/TODO [3]: http://bootstrap.debian.net [4]: http://snapshot.debian.org [5]: http://bugs.debian.org/724865 [6]: http://bugs.debian.org/728298 [7]: https://gitorious.org/debian-bootstrap/pages/Terminology [8]: https://gitorious.org/debian-bootstrap/pages/Heuristics [9]: https://gitorious.org/debian-bootstrap/bootstrap_debian_net [10]: http://bootstrap.debian.net/amd64/ [11]: http://bootstrap.debian.net/source/avahi.html [12]: http://bootstrap.debian.net/source/python2.7.html [13]: http://bootstrap.debian.net/amd64/log.txt [14]: http://bootstrap.debian.net/amd64/stats.json -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131105101147.27416.81714@hoothoot
Bug#733518: ITP: libfixbuf -- Implementation of the IPFIX protocol
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: libfixbuf Version : 1.4.0 Upstream Author : Brian Trammell * URL : http://tools.netsa.cert.org/fixbuf/index.html * License : LGPL2 Programming Lang: C Description : Implementation of the IPFIX protocol libfixbuf is a compliant implementation of the IPFIX Protocol, as defined in RFC 5101. It supports the information model defined in RFC 5102, extended as proposed by RFC 5103 to support information elements for representing biflows. libfixbuf supports UDP, TCP, SCTP, TLS over TCP, and Spread as transport protocols. It also supports operation as an IPFIX File Writer or IPFIX File Reader. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131229170501.7901.12008.reportbug@hoothoot
Bug#735177: ITP: fuseloop -- loopback mount using FUSE
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: fuseloop Version : 1.0.1 Upstream Author : Johny Mattsson * URL : https://github.com/jmattsson/fuseloop * License : BSD Programming Lang: C Description : loopback mount using FUSE Allows one to map parts of one file at a specific offset and with a specific size to another file by using Filesystem in Userspace (FUSE). This allows one to work around shortcomings of mke2fs or fuse-ext2 which allow to work on regular files but do not allow to specify an offset or size that they should work on. With fuseloop it is no longer necessary to create multiple files and concatenate them together to create a full disk image (including a valid partition table) in user space without superuser privileges. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140113142745.4166.82712.reportbug@hoothoot
Bug#735884: ITP: ocp-indent -- OCaml indentation tool for emacs and vim
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: ocp-indent Version : 1.4.1 Upstream Author : Thomas Gazagnaire, Fabrice Le Fessant * URL : http://www.typerex.org/ocp-indent.html * License : LGPL-3 with OCaml linking exception Programming Lang: OCaml Description : OCaml indentation tool for emacs and vim ocp-indent is a command-line tool that allows one to indent a whole OCaml source code file (or parts of it) either to standard output or in-place. A configuration file allows user defaults as well as per-project parameters. The ratio of correctly indented lines is comparable with emacs tuareg mode while being an order of magnitude faster. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140118104121.2014.83206.reportbug@hoothoot
Bug#740087: ITP: python-efl -- Python bindings for the Enlightenment Foundation Libraries
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: python-efl Version : 1.8.1 Upstream Author : Gustavo Sverzut Barbieri barbi...@gmail.com and others * URL : http://www.enlightenment.org * License : LGPL-3 Programming Lang: Python, Cython Description : Python bindings for the Enlightenment Foundation Libraries This package provides Python bindings for the Enlightenment Foundation Libraries. Provides bindings for evas, ecore and edje. Support for elementary and emotion is disabled. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140225162613.15711.10195.reportbug@hoothoot
Bug#741640: ITP: vcmi -- Free implementation of the Heroes of Might and Magic 3 game engine
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: vcmi Version : 0.95 Upstream Author : Micha³ Urbañczyk aka Tow imp...@gmail.com Ivan Savenko saven.i...@gmail.com Tom Zielinski aka Warmonger warmon...@vp.pl AVS Benjamin Gentner aka beegee * URL : http://forum.vcmi.eu/portal.php * License : GPL2.0+ Programming Lang: C++ Description : Free implementation of the Heroes of Might and Magic 3 game engine VCMI is a free implementation of the Heroes of Might and Magic 3 game engine as well as a platform for mods. VCMI is a turn-based strategy game where the player controls a number of heroes commanding an army of creatures. It extends the original capabilities of the game by supporting maps of any size, greater display resolutions. Since the game requires the graphics, videos and music of the original game, can only go into contrib. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140314190002.12745.94908.reportbug@hoothoot
Bug#742075: ITP: python-img2pdf -- Lossless conversion of JPEG, JPEG2000 and other raster graphic formats to PDF
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: python-img2pdf Version : 0.1.0 Upstream Author : Johannes Schauer j.scha...@email.de * URL : https://github.com/josch/img2pdf * License : GPL3+ Programming Lang: Python Description : Lossless conversion of JPEG, JPEG2000 and other raster graphic formats to PDF This tool is able to embed JPEG or JPEG2000 files into a PDF container without re-encoding them. Files of other formats will be stored using the lossless Flate/zlib encoding. In addition to JPEG and JPEG 2000, all formats supported by the Python Imaging Library are supported as input. There seems to be no tool (correct me if I'm wrong) which can embed an image into a pdf without either loosing information due to JPEG re-encoding or blowing up the filesize through Flate/zlib encoding. It would thus be a useful tool to have in Debian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140318220600.8370.15162.reportbug@hoothoot
arch:all cross-build-deps in ubuntu (was: :any syntax in package names in jessie/sid Packages)
Hi, Quoting Wookey (2014-04-20 16:24:46) So far as I know that spec doc is correct for Debian and Ubuntu. The only significant difference is that Ubuntu has patched apt to assume that :all packages are M-A:foreign by default. Debian has not, and requires all packages to be so marked explicitly. I think this bug is related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666772 And as far as I understood the patch, this only makes arch:all packages used in build dependencies m-a:foreign and not arch:all packages used as binary dependency of other binary packages. Is this correct? We would also like to have this situation clarified for a correct Ubuntu specific implementation of this in dose3. Thanks! cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140420144601.21059.95258@hoothoot
Advice for how to make new things policy (was: ':any' syntax in package names in jessie/sid Packages)
Hi all,
Quoting Stuart Prescott (2014-04-20 16:58:21)
As xnox says there is still some pending changes around the interpreter
problem, as described here:
https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges
And that debate is part of the reason this stuff hasn't been
considered 'finalised' and thus ready for policy. But I think the core
stuff is now well-enough used that at the very least policy should not
be inconsistent with it.
pending changes, things still to be finalised, undocumented syntax changes
being pushed into jessie that broke wheezy→jessie upgrades (which had to be
fixed in both dh_python{2,3} and also required a stable update to apt
[1])... this worries me. It feels like it is being done backwards.
This is the exact situation where I would like to see policy lead the way
and be part of the process to design and codify things *before* we start
implementing them on 21k packages. This is a general comment, not just about
multi-arch -- our policy editors have a huge amount of experience in
developing technical policies and documentation to go with them. Making use
of their expertise at the design stage would be much better for the project.
Currently, the project seems to tend towards policy documenting current
practice rather than policy leading us towards better (best!) practice; this
culture means that improving things can be very hard because you may have to
become policy non-compliant in order to develop the new standard practice
to then seek a change in policy. (And as observed recently, this also means
that when given a choice between A and B, we end up choosing A, B, C and Z
[2].)
One thing that makes me personally like to contribute to Debian in contrast to
other distribution is how much importance is being put on the Debian policy and
how well everything is documented in it. I was very alienated when I found that
something as important (well at least from the point of view of stuff that
I'm working on) as multiarch is not documented at policy at all but just in the
Ubuntu wiki.
Now together with wookey I have been pushing the build profile syntax extension
[1] forward and while it is already integrated in a number of important tools
(dpkg, apt, debhelper, lintian) it is also not yet in policy. The only
available documentation sits at [1] and is not even finished yet because of a
missing issue I raised at [2]. I would really *love* to have build profiles in
policy but how to proceed without the spec even being finished yet? How to
finish a spec? How to get input from enough relevant people and people who know
what they are talking about? I should at least get approval of dpkg maintainers
before I document a Build-Depends syntax extension, right? And if a decision
is taken elsewhere, should dpkg maintainers who probably know best not have a
veto?
On top of that there is yet another thing (potentially another build-depends
syntax extension, yes I know everybody must hate me now) that I want to discuss
on dpkg-devel. And for that I want to take the way most accepted by the
project. Should I first discuss it on debian-devel even though (as it happened
with build profiles) dpkg maintainers will make the final call anyways?
I wholeheartedly agree with Stuart's email. I would love to see policy lead the
way. But as somebody who comes up with new things that might end up in policy:
how to proceed? My current approach is to write countless mails to dpkg-devel
and over time, an agreement is formed, things get implemented in dpkg and
others follow because if dpkg does it, then it's probably nothing too wanky.
But that's not the process I'd like to follow. How to turn it around? I also
fear that turning the process around produces too much bureaucracy at the
expense of finding a technically excellent solution decided by the people who
have most experience? Is it not the way of Debian as a do-ocracy to first have
the tool support decided by the people maintaining the tool and *then* the
policy after stuff works? Maybe there is a middle ground?
cheers, josch
[1] https://wiki.debian.org/BuildProfileSpec
[2] https://lists.debian.org/debian-dpkg/2014/02/msg00029.html
[3] https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges
[4] https://wiki.debian.org/Multiarch/InterpreterProposal
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140420175357.21059.78687@hoothoot
Re: ':any' syntax in package names in jessie/sid Packages
Hi, Quoting Niko Tyni (2014-04-20 23:50:56) I thought so too, but it doesn't seem to be the case? For example, I can't install cmake:i386 in an amd64 trusty chroot: The following packages have unmet dependencies: cmake:i386 : Depends: cmake-data:i386 (= 2.8.12.2) but it is not installable (cmake-data is arch:all but not multi-arch annotated.) the patch submitted to https://bugs.debian.org/666772 only affects the arch:all packages that satisfy cross build dependencies - not the arch:all packages satisfying other dependencies. Try to do: apt-get build-dep -ai386 --simulate build-essential This will fail on Debian because of dh-python which is arch:all and m-a:none. But it will succeed in Ubuntu. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140421065907.21059.59698@hoothoot
Bug#748102: ITP: botch -- Bootstrapping helper
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: botch Version : 0.1 Upstream Author : Johannes Schauer j.scha...@email.de * URL : https://gitorious.org/debian-bootstrap/pages/Home * License : LGPL3+ with OCaml linking exception Programming Lang: OCaml, Python, Shell Description : Bootstrapping helper Botch stands for bootstrap/build ordering tool chain and allows one to create and analyze bootstrapping dependency graphs, creates suggestions how to break dependency cycles and generates a build order. It includes a range of utilities to: - transform Packages and Sources control files - set operations (union, intersection, difference) - adding and removing specific metadata - only pick latest version - Packages to Sources - Sources to Packages - generating self contained repositories (min and max) - analysis of Packages and Sources control files - diff tool - multiarch changes application - check multi-arch:same versions - create graphs of different types - installation sets - strong dependency sets - dependency closure - conversion of graphs - buildgraph to source graph - graphml to dot format - annotation with strong dependency information - extract neighborhood - extract strongly connected components - collapsing strongly connected components - analyze graphs - find all cycles - find selfcycles - find amount of cycles through edges - find feedback arc set - find feedback vertex set - find strong articulation points and strong bridges - general graph info - generating partial order - graph rendering - graph difference - calculate betweenness - calculate port metric - shell scripts connecting the tools for meaningful operations - analyzing cross bootstrap phase - analyzing native bootstrap phase - create a transition order -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140514093940.1746.50770.reportbug@hoothoot
Re: Bug#748102: ITP: botch -- Bootstrapping helper
Hi, Quoting Joachim Breitner (2014-05-14 12:39:41) cool. Can this also be used in a relative ad-hoc manner to replace the simple script at http://anonscm.debian.org/gitweb/?p=pkg-haskell/tools.git;a=blob;f=order-sources.pl which does Usage: $0 dir / control / dsc... Each argument is expected to be a Debian source package directory; the debian directory in a Debian source package directory the control file or the .dsc file of a Debian source. These will be ordered by “obvious” build-dependencies and printed out again. or does will it require stuff like local repositories to be set up first? I can't speak about your specific haskell use case but in general, the problem is that dependencies of binary packages get autogenerated during build time and are not explicitly expressed in debian/control. Thus, a debian/control file doesnt help to find a correct solution in all cases. That botch can create transition orders is just a side product of the other things it does. I verify botch's output by comparing it with the output of ben. But ben also needs a repository as input. The best thing both tools can do is to give you an order for the old, existing packages and hope that your new packages depend on each other in the same way. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140514133534.24634.2374@hoothoot
Re: Bug#748102: ITP: botch -- Bootstrapping helper
Hi, Quoting Niko Tyni (2014-05-14 13:15:59) Heh. FWIW we've been using http://anonscm.debian.org/gitweb/?p=pkg-perl/scripts.git;a=blob;f=perl-5.10-transition/find-rebuild-order for transition ordering when preparing Perl transitions. That one uses the system apt cache. I wonder if the Python and Ruby folks have rolled their own ones too. from reading the DESCRIPTION section it seems that botch is able to do the same thing but without the drawback listed in BUGS AND LIMITATIONS. In case you ever run into trouble with that perl script and want to evaluate other options, feel free to contact me. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140514134502.24634.29020@hoothoot
possible MBF: automatically detecting unused build dependencies
Hi, we would like to propose an MBF with severity wishlist to drop unused build dependencies in a number of source packages indicated by the attached two text files and the dd-list output. TLDR; We searched a selection of source packages relevant to bootstrapping for build dependencies which are never used during the package build. Fewer build dependencies help making bootstrapping easier so we want to submit bugs for the results we generated. The results were generated automatically by a script using fatrace(1) and fake packages. It follows the MBF template email and a detailed explanation of our procedures. Attached is the list of the unused build dependencies we found and the output of dd-list. We would like you to review the list, drop unused build dependencies or report errors. MBF template email: --%--- Subject: Please consider removing the build dependencies on $foo, $bar and $baz Severity: wishlist Usertag: unusedbd User: bootst...@lists.debian.org Dear Maintainer, the build dependencies $foo, $bar and $baz of this source package do not seem to be needed. Neither are any of their files accessed during the build nor are their dependencies on other binary packages required. Please consider dropping those build dependencies to make bootstrapping Debian easier. You can find more detail about the procedures that were used to find this problem in the MBF announcement on debian-devel: $email --%--- Long version: Our bootstrappable Debian GSoC student Peter Pentchev found a number of source packages that did not make use of some of their build dependencies [1]. We thought we could automate this process so we set up a simple sbuild based package builder. The machinery works in two passes. In the first pass, all source packages are built normally but with fatrace(1) active. From the fatrace output we determine all build dependencies of which no files were used during the build. In the second pass we go through all source packages for which candidate droppable build dependencies where found with fatrace and test whether those build dependencies are really droppable by replacing them with an empty equivs package without dependencies one by one. The first pass makes sure that the files of a specific build dependency are not needed. This is to make sure not to produce false positives of build dependencies which, if not installed on the build system, do not result in a build failure but instead just in a reduction of functionality of the output binary. The second pass makes sure that also the dependencies of a specific build dependency are not needed. This makes sure to not produce false positives of meta or virtual packages. We executed the build on the amd64 snapshot 20140601T00Z of Debian Sid. A selection of 549 source was made from the source packages that are involved in the central strongly connected component of the bootstrapping dependency graph. We needed to patch fatrace to be able to handle files larger than 2 GB (bug #722901). We ran the whole process with `sbuild --arch-all` and then again with `sbuild --no-arch-all`. This way we can find build dependencies which can be dropped from full package builds as well as those which can be moved to Build-Depends-Indep. We did not use the results to also check for build dependencies that can be removed from Build-Depends-Indep. The source code to run the whole machinery can be found at [2]. Executing everything took two weeks and over 2000 package builds. We found 277 build dependencies could be dropped from the 549 tested source packages, affecting 158 source packages. We checked the impact on the bootstrap dependency graph. If all the found build dependencies were really droppable, then the minimum (strong) dependency graph would shrink from containing 483 source packages to 447 source packages. More importantly, the solution to the feedback arc set problem for making it acyclic would shrink from 74 to 56 source packages. Thus, the generated results are very relevant for making solving the bootstrap problem easier. You can find the results per source package in the attachment together with the dd-list output. The file drop-from-bd.txt lists the build dependencies that can be dropped from Build-Depends while move-to-bdi lists the build dependencies that can be moved from Build-Depends to Build-Depends-Indep. Can you spot obvious mistakes in the results or in the procedure used to generate them? cheers, josch [1] #749616 #749972 #751702 #751897 #752938 [2] https://github.com/josch/findunusedbd Adam C. Powell, IV hazel...@debian.org mpi-defaults (U) Adam Conrad adcon...@0c3.net cyrus-sasl2 (U) eglibc (U) freetds (U) Agustin Martin Domingo agmar...@debian.org linuxdoc-tools (U) Alan Woodland awoodl...@debian.org blcr Alessandro Ghedini gh...@debian.org curl valgrind
Re: possible MBF: automatically detecting unused build dependencies
Hi, sorry I attached two wrong files containing the many false positives already noticed by some of the replies. Here the actual results. Sorry. cheers, josch == apache2_2.4.9-1.arch-all.unusedbd.real == libcap-dev:amd64=1:2.22-1.2 == apparmor_2.8.0-5.arch-all.unusedbd.real == dejagnu=1.5-3 texlive-latex-recommended=2014.20140528-3 == apr-util_1.5.3-2.arch-all.unusedbd.real == libpcre3-dev:amd64=1:8.31-5 == apt_1.0.3.arch-all.unusedbd.real == automake=1:1.14.1-3 == at-spi2-atk_2.10.2-3.arch-all.unusedbd.real == libglib2.0-bin=2.40.0-3 == avahi_0.6.31-4.arch-all.unusedbd.real == python-all-dev=2.7.6-2 == bc_1.06.95-8.arch-all.unusedbd.real == bison=2:3.0.2.dfsg-2 libreadline-dev:amd64=6.3-6 == bison_3.0.2.dfsg-2.arch-all.unusedbd.real == autotools-dev=20140510.1 == blcr_0.8.5-2.1.arch-all.unusedbd.real == autoconf=2.69-6 automake=1:1.14.1-3 autotools-dev=20140510.1 libtool=2.4.2-1.7 == bluez_4.101-4.1.arch-all.unusedbd.real == bison=2:3.0.2.dfsg-2 gstreamer-tools=0.10.36-1.2 == boost-defaults_1.55.0.2.arch-all.unusedbd.real == libboost1.55-dev:amd64=1.55.0+dfsg-1 == ceph_0.80.1-1.arch-all.unusedbd.real == libboost-dev:amd64=1.55.0.2 libboost-system-dev:amd64=1.55.0.2 python-all=2.7.6-2 uuid-runtime=2.20.1-5.7 == chicken_4.8.0.5-1.arch-all.unusedbd.real == texinfo=5.2.0.dfsg.1-3 == cloog_0.18.2-1.arch-all.unusedbd.real == texinfo=5.2.0.dfsg.1-3 == cpio_2.11+dfsg-2.arch-all.unusedbd.real == texinfo=5.2.0.dfsg.1-3 == cunit_2.1-2.dfsg-1.arch-all.unusedbd.real == quilt=0.63-2 == cups-filters_1.0.53-1.arch-all.unusedbd.real == sharutils=1:4.14-2 == curl_7.37.0-1.arch-all.unusedbd.real == ca-certificates=20140325 openssh-server=1:6.6p1-5 python=2.7.6-2 == db5.3_5.3.28-3.arch-all.unusedbd.real == gcj-native-helper=2:1.7-52 == dbus-python_1.2.0-2.arch-all.unusedbd.real == xmlto=0.0.25-2 == dbus_1.8.2-1.arch-all.unusedbd.real == python=2.7.6-2 == devscripts_2.14.4.arch-all.unusedbd.real == libjson-perl=2.61-1 libterm-size-perl=0.207-1+b1 == doxygen_1.8.7-1.arch-all.unusedbd.real == texlive-extra-utils=2014.20140528-2 == e2fsprogs_1.42.10-1.arch-all.unusedbd.real == m4=1.4.17-4 == ecj_3.9.0-2.arch-all.unusedbd.real == python=2.7.6-2 == eglibc_2.18-7.arch-all.unusedbd.real == autoconf=2.69-6 quilt=0.63-2 == exiv2_0.23-1.arch-all.unusedbd.real == autotools-dev=20140510.1 dh-linktree=0.4 libjs-jquery=1.7.2+dfsg-3 == fastjar_0.98-5.arch-all.unusedbd.real == texinfo=5.2.0.dfsg.1-3 == fftw3_3.3.4-1.arch-all.unusedbd.real == ghostscript=9.05~dfsg-8.1 transfig=1:3.2.5.e-3 == findlib_1.4.1-1.arch-all.unusedbd.real == gawk=1:4.1.1+dfsg-1 == flite_1.4-release-8.arch-all.unusedbd.real == ghostscript=9.05~dfsg-8.1 == fontconfig_2.11.0-5.arch-all.unusedbd.real == gperf=3.0.4-1 == freeglut_2.8.1-2.arch-all.unusedbd.real == libxt-dev:amd64=1:1.1.4-1 == freetds_0.91-6.arch-all.unusedbd.real == libreadline-dev:amd64=6.3-6 == gdb_7.6.2-1.1.arch-all.unusedbd.real == autoconf=2.69-6 flex=2.5.39-7 gcj-jdk=4:4.9.0-1 gobjc=4:4.8.2-4 libtool=2.4.2-1.7 procps=1:3.3.9-5 == geoclue-2.0_2.1.8-1.arch-all.unusedbd.real == geoip-database=20140509-1 == geoip_1.6.0-1.arch-all.unusedbd.real == zlib1g-dev:amd64=1:1.2.8.dfsg-1 == ghostscript_9.05~dfsg-8.1.arch-all.unusedbd.real == freeglut3-dev:amd64=2.8.1-2 == gnome-keyring_3.12.0-2.arch-all.unusedbd.real == ca-certificates=20140325 docbook-xml=4.5-7.2 libglib2.0-doc=2.40.0-3 libtasn1-3-dev=3.6-1 == gnome-vfs_2.24.4-4.arch-all.unusedbd.real == libattr1-dev:amd64=1:2.4.47-1 == gpac_0.5.0+svn5194~dfsg1-3.arch-all.unusedbd.real == libxmlrpc-c3-dev=1.16.33-3.2 == gpm_1.20.4-6.1.arch-all.unusedbd.real == texi2html=1.82+dfsg1-3 texlive-base=2014.20140528-3 == graphviz_2.26.3-17.arch-all.unusedbd.real == pdksh=49-2 == gsl_1.16+dfsg-1.arch-all.unusedbd.real == libtool=2.4.2-1.7 == gst-plugins-base0.10_0.10.36-1.1.arch-all.unusedbd.real == gir1.2-freedesktop=1.40.0-2 gir1.2-glib-2.0=1.40.0-2 == gst-plugins-base1.0_1.2.4-1.arch-all.unusedbd.real == gir1.2-freedesktop=1.40.0-2 == gstreamer1.0_1.2.4-1.arch-all.unusedbd.real == gir1.2-freedesktop=1.40.0-2 libgmp3-dev=2:6.0.0+dfsg-4 == gtest_1.7.0-3.arch-all.unusedbd.real == python=2.7.6-2 == gtk+2.0_2.24.23-1.arch-all.unusedbd.real == libatk1.0-doc=2.12.0-1 libcairo2-doc=1.12.16-2 libglib2.0-doc=2.40.0-3 libpango1.0-doc=1.36.3-1 == gtk+3.0_3.12.2-1.arch-all.unusedbd.real == gsettings-desktop-schemas=3.8.2-2 == gtkglext_1.2.0-3.1.arch-all.unusedbd.real == autotools-dev=20140510.1 == heimdal_1.6~rc2+dfsg-6.arch-all.unusedbd.real == libperl4-corelibs-perl=0.003-1 == hunspell_1.3.2-7.arch-all.unusedbd.real == libreadline-dev:amd64=6.3-6 == hwloc_1.9-3.arch-all.unusedbd.real == autotools-dev=20140510.1 doxygen-latex=1.8.7-1 help2man=1.45.1 transfig=1:3.2.5.e-3 == ijs_0.35-10.arch-all.unusedbd.real == docbook-utils=0.6.14-3 docbook=4.5-5.1 ghostscript=9.05~dfsg-8.1 == klibc_2.0.3-1.arch-all.unusedbd.real == bison=2:3.0.2.dfsg-2 m4=1.4.17-4 == lcms_1.19.dfsg1-1.3.arch-all.unusedbd.real ==
Re: possible MBF: automatically detecting unused build dependencies
Hi, Quoting Julian Taylor (2014-07-07 14:14:20) There seem to be a bunch of false positives for virtual/metapackages: == python-numpy_1.8.1-1.arch-all.unusedbd == gfortran=4:4.8.2-4 python-all-dbg=2.7.6-2 python-all-dev=2.7.6-2 python3-all-dbg=3.4.1~rc1-1 python3-all-dev=3.4.1~rc1-1 the -all packages are basically empty packages pulling in all python versions supported, those packages are definitely used during the build. Removing them during an arch-any build should fail the build. does sbuild --arch-all only build the indep part? Sorry, I attached the wrong files in my first email. I posted a follow up with the correct results which correctly do not contain the empty packages anymore. If so that might explain why your pass2 did not remove these, but so far I know we have no way to declare this state in our control, we only have Build-Depends and Build-Depends-Indep, no Build-Depends-Arch. Was Build-Depends-Arch not added with #629480? Similar fftw3: == fftw3_3.3.4-1.arch-all.unusedbd == gfortran=4:4.8.2-4 ghostscript=9.05~dfsg-8.1 mpi-default-dev=1.0.2+nmu1 transfig=1:3.2.5.e-3 mpi-default-dev is not used directly but its dependencies are required for the fully featured arch any build. Same story as above. Sorry for the confusion :( cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140707122328.14505.92338@hoothoot
Re: possible MBF: automatically detecting unused build dependencies
Hi, Quoting Henrique de Moraes Holschuh (2014-07-07 14:07:26) Please don't assume that the unused build dependency is always where the defect is. Rather, the MBF text should account for the possibility that the unused build-dependency should have been used in the first place, but something is broken in the build and it is being left unused. you are correct, this should be mentioned. Here the updated text: --%--- Dear Maintainer, the build dependencies $foo, $bar and $baz of this source package do not seem to be needed. Neither are any of their files accessed during the build nor are their dependencies on other binary packages required. This can either mean that the build dependency is superfluous and should be removed to make bootstrapping easier or it indicates a bug where a package should be used but is in fact not. Please remove the build dependency from the Build-Depends in the former case or fix the build procedure in the latter. You can find more detail about the procedures that were used to find this problem in the MBF announcement on debian-devel: $email --%--- thank you! cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140707123210.14505.41481@hoothoot
Re: possible MBF: automatically detecting unused build dependencies
and the updated dd-list Sorry for not having attached the right files in my initial email :( cheres, josch Adam C. Powell, IV hazel...@debian.org mpi-defaults (U) Adam Conrad adcon...@0c3.net eglibc (U) freetds (U) Alan Woodland awoodl...@debian.org blcr Alessandro Ghedini gh...@debian.org curl valgrind Alessio Treglia ales...@debian.org gpac (U) Alexander Wirt formo...@debian.org rrdtool (U) Andreas Barth a...@not.so.argh.org netpbm-free Andreas Henriksson andr...@fatal.se gnome-keyring (U) gtk+3.0 (U) libarchive (U) libgnome-keyring (U) libsecret (U) libsoup2.4 (U) Andreas Metzler ametz...@debian.org libtasn1-6 (U) Andreas Rottmann ro...@debian.org libglade2 Andres Mejia ame...@debian.org gpac (U) libarchive (U) Andrew Moise ch...@demiurgestudios.com open-iscsi (U) Anibal Monsalve Salazar ani...@debian.org cpio libidn (U) libmnl xfsprogs (U) Anton Gladky gl...@debian.org freeglut APT Development Team de...@lists.debian.org apt python-apt Arnaud Fontaine ar...@debian.org xcb-util (U) xcb-util-image (U) xcb-util-keysyms (U) xcb-util-renderutil (U) xcb-util-wm (U) Arno Töll a...@debian.org apache2 (U) Aron Xu a...@debian.org libxml2 (U) netcat-openbsd Atsuhito KOHDA ko...@debian.org lynx-cur Aurelien Jarno aure...@debian.org eglibc (U) libusb libusb-1.0 qemu (U) Bart Martens ba...@debian.org gtkglext Bastian Blank wa...@debian.org parted (U) redhat-cluster (U) xen (U) Bastien ROUCARIÈS roucaries.bastien+deb...@gmail.com ghostscript (U) Benjamin Drung bdr...@debian.org devscripts (U) Benjamin Kaduk ka...@mit.edu krb5 (U) Bernd Zeimetz b...@debian.org rrdtool (U) Brian May b...@debian.org heimdal Ceph Maintainers ceph-maintain...@lists.ceph.com ceph Chris Halls ha...@debian.org hunspell (U) Christian Perrier bubu...@debian.org apt (U) Christoph Martin christoph.mar...@uni-mainz.de openssl (U) Chuan-kai Lin ck...@debian.org bison Clint Adams cl...@debian.org eglibc (U) Colin Watson cjwat...@debian.org parted (U) Craig Andrews candr...@integralblue.com geoclue-2.0 (U) Cyril Brulebois k...@debian.org libxkbcommon (U) xfonts-utils (U) Damien Raude-Morvan draz...@debian.org openjdk-7 (U) Daniel Leidert (dale) daniel.leid...@wgdd.de libxml-parser-perl (U) xmlto (U) Dave Beckett daj...@debian.org redland Davide Puricelli (evo) e...@debian.org chicken Debian Accessibility Team debian-accessibil...@lists.debian.org at-spi2-atk flite Debian Apache Maintainers debian-apa...@lists.debian.org apache2 apr-util Debian Berkeley DB Group pkg-db-de...@lists.alioth.debian.org db5.3 Debian Bluetooth Maintainers pkg-bluetooth-maintain...@lists.alioth.debian.org bluez Debian Boost Team pkg-boost-de...@lists.alioth.debian.org boost-defaults Debian GCC Maintainers debian-...@lists.debian.org cloog libffi Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org gnome-keyring (U) gnome-vfs (U) gtk+2.0 gtk+3.0 libglade2 (U) libgnome-keyring libsecret libsoup2.4 pango1.0 pygobject-2 (U) pygtk (U) Debian GnuTLS Maintainers pkg-gnutls-ma...@lists.alioth.debian.org libtasn1-6 Debian HA Maintainers debian-ha-maintain...@lists.alioth.debian.org redhat-cluster Debian iSCSI Maintainers pkg-iscsi-maintain...@lists.alioth.debian.org open-iscsi Debian Java Maintainers pkg-java-maintain...@lists.alioth.debian.org ecj zookeeper Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org exiv2 Debian Libarchive Maintainers ah-libarch...@debian.org libarchive Debian Libidn Team help-lib...@gnu.org libidn Debian LibreOffice Maintainers debian-openoff...@lists.debian.org hunspell Debian Multimedia Maintainers pkg-multimedia-maintain...@lists.alioth.debian.org gpac x264 Debian OCaml Maintainers debian-ocaml-ma...@lists.debian.org findlib ocaml Debian OpenLDAP Maintainers pkg-openldap-de...@lists.alioth.debian.org openldap Debian OpenSSL Team pkg-openssl-de...@lists.alioth.debian.org openssl Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org libxml-parser-perl Debian PHP Maintainers pkg-php-ma...@lists.alioth.debian.org php5 Debian Printing Team debian-print...@lists.debian.org cups-filters ghostscript ijs Debian Python Modules Team python-modules-t...@lists.alioth.debian.org markupsafe (U) python-numpy Debian QA Group packa...@qa.debian.org graphviz readline5 Debian QEMU Team pkg-qemu-de...@lists.alioth.debian.org qemu Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org qca2 qt4-x11 qtbase-opensource-src qtwebkit Debian RRDtool Team rrdt...@ml.snow-crash.org rrdtool Debian Samba Maintainers pkg-samba-ma...@lists.alioth.debian.org tdb Debian Science Team debian-science-maintain...@lists.alioth.debian.org fftw3
Re: possible MBF: automatically detecting unused build dependencies
Hi, Quoting Jérémy Lal (2014-07-07 14:12:19) Consider also the case when arch:all package require a build dependency on a package that only builds on some archs, to prevent the arch:all package being available on archs where its dependencies are not. nodejs and node-* packages are such an example. could you clarify this case? An arch:all package cannot require a build dependency because an arch:all package is a binary package. I can also not find any nodejs packages in the lists I posted. In fact, nodejs package have not yet been a problem with respect to bootstrapping - probably because they are mostly arch:all? cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140707133254.14505.99230@hoothoot
Re: possible MBF: automatically detecting unused build dependencies
Hi, Quoting Steve Langasek (2014-07-07 18:36:50) There seem to still be some false positives here. pam is on the list because of a build-dependency on libdb-dev, freetds and unixodbc are there because of a build-dependency on libreadline-dev. Both of these are metapackages that pull in version-specific -dev packages. So something seems to be wrong with the detection of empty packages yet? Empty packages are not detected. The first phase will find empty packages because they do not contain any files and thus they are detected as build dependencies of which no files were used. Since empty packages are mostly meta packages and we do not want to include them, we replace them by a fake equivs package without dependencies. If the build still succeeds, that means that the meta package is indeed not needed. Lets find out what happens here. Steps to reproduce: $ sudo debootstrap sid debian-sid # the pam build needs /proc mounted $ sudo mount -o bind /proc debian-sid/proc $ sudo chroot debian-sid $ echo deb-src http://ftp.us.debian.org/debian sid main /etc/apt/sources.list $ apt-get update $ apt-get install build-essential equivs $ apt-cache show libdb-dev | grep -v ^Depends: | grep -v ^Conflicts: | equivs-build - $ dpkg -i libdb-dev_5.3.0_amd64.deb $ apt-get build-dep pam $ dpkg -l | grep libdb ii libdb-dev 5.3.0amd64 Dummy package to fulfill package dependencies ii libdb5.3:amd64 5.3.28-5 amd64 Berkeley v5.3 Database Libraries [runtime] $ apt-get source --build pam [...] $ echo $? 0 I get the same effect when replacing pam by freetds and unixodbc and libdb-dev by libreadline-dev. Can you point out at which step my error is? Thanks! cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140707180506.14505.22612@hoothoot
Re: possible MBF: automatically detecting unused build dependencies
Hi, Quoting Don Armstrong (2014-07-07 20:33:37) On Mon, 07 Jul 2014, Johannes Schauer wrote: Empty packages are not detected. The first phase will find empty packages because they do not contain any files and thus they are detected as build dependencies of which no files were used. Since empty packages are mostly meta packages and we do not want to include them, we replace them by a fake equivs package without dependencies. If the build still succeeds, that means that the meta package is indeed not needed. Unfortunately, this is not necessarily the case; some builds systems disable optional functionality if the required build dependency is not present, and still let the build complete. correct. The exact problem here is that a meta package without any actual files depends on a package without which the build will still successfully complete. Usually, optional build dependencies are not registered as false positives because the first pass does a full build with all build dependencies present. Even if a build dependency could be optional it will not register in this pass because its files will still be used. The problem here is that the optional build dependency is not a direct dependency of the source package. I cannot think of an automated way to catch dependencies of meta packages without which the build will still succeed. This of course except if there was an easy way to compare the build output against the original binary package. But that's doesnt seem possible yet without reproducible builds. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140707190347.14505.76518@hoothoot
Re: possible MBF: automatically detecting unused build dependencies
Hi, Quoting Steve Langasek (2014-07-07 20:22:42) Ah. No, it only means that the package build does not *fail* if the build-dependency is removed. That is not the same thing as saying that the build-dependency is not used. you are correct. I expanded more on this in my other reply to Don Armstrong. It would of course be better if packages were resilient against breakage in their build-dependencies, instead of misbuilding with features disabled or with wrong fallback code. But this isn't easy to do in all build systems, and anyway this isn't something we routinely audit about our packages; we shouldn't regard this as a bug to be reported without a lot more discussion of how we're going to systematically stay on top of those issues in the future. I agree that it should not be a bug if a package does not fail if a certain build dependency is not installed. Nevertheless, those false positives that were generated this way are still useful to be later marked with !profile.stage1 once build profiles are allowed in the archive because they are obviously droppable. About systematically staying on top of those issues I do not know how to proceed. I guess for that we would first need to know how many source packages depend on meta packages which are not completely empty (besides /usr/share/doc) and still silently fail and continue building with reduced features. I did not plan to run this script more often yet. I'll probably do another run after having added a detection for meta packages as suggested by you below. Running it more regularly might not require any big discussion because the problem size might be small enough that maintaining a white list would be enough. For your purposes, a better method would be: - identify those build-dependencies which are empty except for /usr/share/doc - for each such package, look at the contents of its direct dependencies - check the build against those contents While this would often work it would still miss some meta packages which do ship some more files than /usr/share/doc but are otherwise mostly important because of the packages they depend on. Though I guess this would already tremendously decrease the amount of false positive (however high their number is) and I should implement that for the next time I recalculate this. For the case of pam, I would be interested in seeing the full build log to understand how in the world this built successfully without libdb. That's definitely a packaging error on my part, because without libdb, pam_userdb.so should not build, which in turn *should* be treated as a build failure. But I guess I'm not accounting for individual modules in the build output, since in general the greater risk is failing to keep this list in sync with new upstream modules, rather than misbuilding and losing a module from the tree. Sorry, I already deleted my chroot :( cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140707191444.14505.34985@hoothoot
Re: possible MBF: automatically detecting unused build dependencies
Hi, Quoting Steve Langasek (2014-07-08 00:07:29) On Mon, Jul 07, 2014 at 09:14:44PM +0200, Johannes Schauer wrote: Nevertheless, those false positives that were generated this way are still useful to be later marked with !profile.stage1 once build profiles are allowed in the archive because they are obviously droppable. No, marking build-dependencies with build profiles should be driven by what is needed to break build-dep loops, not by what build-deps are droppable without further modification of the packages. Excessive stage1 profile tagging will result in unnecessary extra builds during a bootstrap. Bootstrapping should not get into the way of the normal packaging. There should be strong reasons before a disruptive patch is applied to make a package build with fewer build dependencies. This class of cases that is found by this script (and it could be abused to find even more by omitting the first phase) sounds to me as if only trivial changes were needed to build the package with fewer build dependencies. Thus in case the maintainer does not have any strong objections, there is no harm applying them. The downside you list unnecessary extra builds are easy to avoid in practice. Botch contains algorithms to find a close to minimum set of source packages to modify to make a dependency graph acyclic (a feedback vertex set). Even if all source packages in the dependency graph had removable build dependencies it would only choose a small set of them (currently 60-70 are needed) to actually build with a stage1 profile active. Furthermore, the only time when there is a hard requirement to remove a dependency without alternative are self cycles which currently involve only about 30 source packages. For all other source packages there are always alternatives. So you will mostly not get into a situation where you absolutely need to break a build-dep loop as you describe it above (aside from these 30 source packages). I did not plan to run this script more often yet. I'll probably do another run after having added a detection for meta packages as suggested by you below. Running it more regularly might not require any big discussion because the problem size might be small enough that maintaining a white list would be enough. If you really want to systematically detect misbuilds on missing build-dependencies, it's a much bigger problem than just detecting this for the build-dependencies which are metapackages. Why? The build dependencies which are not metapackages are not listed as false positives because they get weeded out in the first phase. There certainly will be other cases that this technique won't cover, but it won't cause any false-negatives for your purposes. I don't know what the numbers will look like overall, but 3 out of 4 packages listed by my name were false-positives that can be filtered out this way, so I definitely think it's worth a rerun before MBF. You are right. I'll see what I can do. Thanks a lot for your input! cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140708042249.14505.27900@hoothoot
Re: possible MBF: automatically detecting unused build dependencies
Hi, Quoting Steve Langasek (2014-07-07 20:22:42) Ah. No, it only means that the package build does not *fail* if the build-dependency is removed. That is not the same thing as saying that the build-dependency is not used. It would of course be better if packages were resilient against breakage in their build-dependencies, instead of misbuilding with features disabled or with wrong fallback code. But this isn't easy to do in all build systems, and anyway this isn't something we routinely audit about our packages; we shouldn't regard this as a bug to be reported without a lot more discussion of how we're going to systematically stay on top of those issues in the future. For your purposes, a better method would be: - identify those build-dependencies which are empty except for /usr/share/doc - for each such package, look at the contents of its direct dependencies - check the build against those contents it turns out that 13% of my results are packages with no other content than in /usr/share/doc. Namely: libreadline-dev, default-jdk-doc, doxygen-latex, gcj-native-helper, g++-multilib, gobjc, libboost-dev, libboost-system-dev, libgmp3-dev, libgphoto2-2-dev, libopenais-dev, libtasn1-3-dev, libxmlrpc-c3-dev, lynx, mysql-server, python3-all-dbg, python3-all-dev, libdb-dev, python-all, python-gobject, python-all-dbg, python-all-dev I'll re-run the whole caboodle later this year but consider the file content of empty packages to be the sum of the content of packages it depends on. This should reduce the number of this kind of false positives. Do you think I should fill bugs for all non-empty packages that were already found? Or do you think there is another high chance of false positives for that kind of packages too? cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140708074302.14505.28772@hoothoot
Re: possible MBF: automatically detecting unused build dependencies
Hi, Quoting Kurt Roeckx (2014-07-09 00:36:37) On Mon, Jul 07, 2014 at 01:51:00PM +0200, Johannes Schauer wrote: Kurt Roeckx k...@roeckx.be libtool == libtool_2.4.2-1.7.arch-all.unusedbd == gfortran=4:4.8.2-4 gfortran Depends on gfortran-4.8, and that is being used. indeed this is then a false positive of a nearly-meta package. Unfortunately the gfortran package does ship some files besides /usr/share/doc (both symlinks) and would thus not be classified as a meta package. Maybe I should also check debtags. gfortran is tagged role::dummy. I also found role::metapackage. Is there another debtag or method in general that would allow to consider the dependencies of a package instead and avoid this kind of false positive? Maybe a package shipping only symlinks besides /usr/share/doc is another way of finding meta packages. On the other hand it's harder to check the type of file a package ships as it needs downloading and unpacking first. I'm not aware whether tools like apt-file display information about the file type. openssl (U) == openssl_1.0.1g-4.arch-all.unusedbd == m4=1.4.17-4 From the changelog: * Add Build-Dependency on m4, since sparc needs it to generate it's assembler files. (Closes: #334542) Then it makes sense that my amd64 build caught that. Could you make m4 an architecture specific dependency if it's only used on sparc? cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140709043719.14505.38892@hoothoot
Re: possible MBF: automatically detecting unused build dependencies
Hi, Quoting Maarten Lankhorst (2014-07-09 15:48:33) == llvm-toolchain-3.4_3.4.1-4.arch-all.unusedbd.real == automake=1:1.14.1-3 autotools-dev=20140510.1 diffstat=1.58-1 doxygen=1.8.7-1 flex=2.5.39-7 lcov=1.10-1 libtool=2.4.2-1.7 patchutils=0.3.3-1 procps=1:3.3.9-5 sharutils=1:4.14-2 tcl=8.6.0+8 texinfo=5.2.0.dfsg.1-3 No, building with DEB_BUILD_OPTIONS=codecoverage enables at least some of them, should build dependencies which the source package only requires after setting some DEB_BUILD_OPTIONS go into Build-Depends? and applying patches might require the autotools to be re-run, so I think lots of the requirements are sane. My naive assumption was that the Build-Depends line contains a list of binary packages needed to build the package. Not binary packages that might be needed in some situations during the lifetime of a source package? doxygen is probably used for llvm-3.4-doc, so I think it might not be unused either. texinfo probably the same. The traces show that no file of the doxygen or texinfo package are run during a normal build (including building architecture:all packages). You say they are used. So maybe this indicates a bug where you think they should be used but are in fact not? Could you make sure? diffutils, tcl, flex, patchutils, procps could possibly be unused, although not 100% sure. :-) the only kind of false positive that was pointed out this method has is that it discovers otherwise empty packages (meta packages) which depend on other packages without which the build will nevertheless succeed because it will just silently fail if the tools provided by them are found to not be present. The package tcl is such a case and might thus be a false positive. The other packages are containing actual usable content and should be legitimate. It would be great if you could point out if there was yet another undiscovered flaw in my method. Thank you! cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140709145041.14505.85252@hoothoot
Re: possible MBF: automatically detecting unused build dependencies
Hi, Quoting Jakub Wilk (2014-07-10 12:45:36) * Johannes Schauer j.scha...@email.de, 2014-07-09, 16:50: should build dependencies which the source package only requires after setting some DEB_BUILD_OPTIONS go into Build-Depends? Probably not, unless it's one of the optioned blessed by Policy §4.9.1. :-) And even those are probably options which, if enabled, require less build dependencies than for a full build rather than more. Once build profiles arrive in stable, it will be possible to add !profile.nocheck to build dependencies which are not needed when specifying DEB_BUILD_OPTIONS=nocheck. My naive assumption was that the Build-Depends line contains a list of binary packages needed to build the package. Not binary packages that might be needed in some situations during the lifetime of a source package? Agreed. But here I'd recommend regenerating auto* stuff unconditionally, rather than dropping the build-dependencies. Yes, of course. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140710110704.14505.27633@hoothoot
Re: possible MBF: automatically detecting unused build dependencies
Hi, Quoting Steve Langasek (2014-07-09 00:32:18) But it absolutely does have this effect if we add bootstrap-specific metadata unnecessarily, because: - it introduces a syntax incompatibility with older versions of the package tools we are currently trying to get a minimal change to dpkg, apt and python-apt into wheezy backports to solve this problem: http://lists.debian.org/20140706211617.14505.38487@hoothoot - it makes the packaging more complex to understand While this is true in one sense, one could also argue that annotating build dependencies with what they are used for (with !profile.nodoc or !profile.nocheck) does also add some clarity. Though I guess you were mainly talking about complexity in debian/rules. Sure, more conditionals add complexity. The latter point is as likely to cause problems for the bootstrappers themselves as it is for the maintainers, since the more maintainers who have to get this metadata right and keep it up to date, the more it's going to bitrot. If you are worried about bitrot, then we have to throw more continuous testing at it. With botch we can create a build order and then verify it once enough source packages have build profile information attached. Should Debian not have sufficient resources for that I am willing to do those rebuilds on my own hardware. The bitrot will happen even if bootstrap data is added out of necessity. Due to changing dependencies, some stage1 information might not be needed anymore at some point because it becomes better to break cycles at another point of the graph. So continuous testing is needed in any case. I'm happy that tools like botch exist and think botch has been a useful accelerator for bootstrappability of Debian. However, my own goal is to see that future port bootstraps can be done using the standard buildd infrastructure (for each of Debian and Ubuntu), which doesn't currently make use of such techniques - rather, they work by building everything which is buildable. If you plan to wire up botch to wanna-build for archive-friendly bootstrappability, that would be great to see! I would need to know far more about wanna-build until I can do that. I'm also not too sure whether wanna-build is the right machinery to do bootstraps from scratch? Maybe it is in the sense that botch could provide the info of which source package to best build with reduced build dependencies once nothing is buildable anymore. But it would probably be prudent to show that such an automated bootstrap is possible without wanna-build in the first place. And we are still quite far away from being able to do automated bootstraps, sadly :( But until that's happened, I stand by my claim that stage1 data not needed for breaking build-dep loops is counterproductive for bootstrapping ports. I agree with you that it is unwise to add such extra information to more packages than needed (currently about 60 source packages) before there is enough infrastructure to run and test everything. But again, except for self-cycles there are no hard requirements on a source package needing stage1 annotations. Botch can show which source packages, if modified accordingly could solve the problem with a (close to) minimal number of source packages changed. But if one source package cannot be changed because of technical reasons or because the maintainer refuses to implement these changes, then there are ways to work around that by modifying other source packages. But I guess that's what you meant by need. I guess either once jessie is released or once the wheezy backport happens, build profiles will slowly be introduced with the most obvious packages first. Then will come the other, harder packages until we can for example do a native amd64 bootstrap, starting from a minimal build system. Once we are that far (and that will probably take another release at least) we can talk again about adding bootstrap-specific metadata unnecessarily. :) So let me retract my claim from my earlier email and instead say that I agree that adding !profile.stage1 annotation should be done very selectively and only if necessary. Nevertheless the generated information should be stored somewhere so that a bootstrapper can use it as a source of information which build dependencies can be dropped without much effort from a source package if so necessary. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140710120943.14505.4470@hoothoot
Bug#754460: ITP: pdf2htmlex -- Converts PDF to HTML while retaining most formatting
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: pdf2htmlex Version : 0.11 Upstream Author : WANG Lu coolwan...@gmail.com * URL : http://github.com/coolwanglu/pdf2htmlEX * License : GPL3, MIT, CC-BY-3.0 Programming Lang: C++ Description : Converts PDF to HTML while retaining most formatting pdf2htmlEX converts PDF to HTML while retaining text, format and style as much as possible. In contrast to other converters like pdftohtml from libpoppler-utils it makes use of HTML5, JavaScript and modern CSS features. Even difficult content like PDFs with embedded fonts, multicolumn documents, scientific papers with complicated figures and mathematical formulas will mostly be represented correctly. Fallback mode generates HTML pages which do not require any JavaScript to view them correctly at the expense of a larger file size. https://mentors.debian.net/package/pdf2htmlex -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014073622.19613.32108.reportbug@hoothoot
Bootstrapping also increases the package count (was: Re: Bug#754551: ITP: node-ms -- milliseconds conversion utility)
Hi, Quoting Russ Allbery (2014-07-12 19:19:16) I'd really like to see us solve this problem by figuring out a better metadata distribution system (and IIRC some progress was made on that front recently) than in making life more difficult for packagers. which progress is that? With bootstrapping we also have the problem that we often have to increase the package count with very small packages as it is often required to split a package so that - one part of it can be multiarched (to be able to satisfy cross build dependencies) - or so that the content of the produced binary package of a stage1 profile build is not different from the full build (for example by splitting a foo-plugins package into foo-plugins-nogtk and foo-plugins-gtk) So we would also like to not run into the problem of making people's life harder because we increase the amount of package meta data too much. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140712190136.31130.49432@hoothoot
Re: let missing-debian-source-format lintian tag be a warning!
Hi Charles,
Quoting Charles Plessy (2014-07-16 02:58:58)
viewed from the opposite side of the chain, I have the impression that in
most cases where I receive a report that package X does not build on
architecture Y, it is a pure waste of time, since that package has no user
base on that architecture.
while that package might have no user base, it might be required to build other
source packages on that architecture. You can easily check whether this is the
case by doing:
curl --silent http://bootstrap.debian.net/importance_metric_all.txt \
| awk '$1 == src:$yoursrcpkgname { print $3; }'
The number that is printed is the amount of other source packages which need
$yoursrcpkgname to be buildable so that they can be built on Debian sid amd64.
The file is regenerated daily.
So if you feel wookey becomes too eager you can tell him that not only do the
binary packages that $yoursrcpkgname builds have no users but it also is likely
not needed to build more source packages.
cheers, josch
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140716060243.31130.14458@hoothoot
Re: Bug#754513: ITP: libressl -- SSL library, forked from OpenSSL
Hi, Quoting Russ Allbery (2014-07-16 22:17:23) Ben Hutchings b...@decadent.org.uk writes: On Wed, 2014-07-16 at 12:47 -0700, Russ Allbery wrote: It would be nice to have a reliable kernel interface for getting randomness rather than relying on proper chroot configuration. There is such an interface. It happens to be a char device. Expecting administrators to create /dev/urandom in a chroot is no more unreasonable than expecting them to create /dev/null or /dev/zero. I'm not a big fan of that either. :) Also, I think it's relatively rare for a library to require those devices exist for secure behavior, although perhaps I'm just not knowledgable in this area. maybe this will help in the future: http://lists.openwall.net/linux-kernel/2014/07/17/235 cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140718120306.31130.41027@hoothoot
Re: possible MBF: automatically detecting unused build dependencies
Hi, Quoting Johannes Schauer (2014-07-07 13:51:00) we would like to propose an MBF with severity wishlist to drop unused build dependencies in a number of source packages I fixed many of the previous false positives of build dependencies on meta packages (not the file contents of the package are required for the build but its dependencies) which, if not present during build, would make the build not fail but just let the resulting binary be generated with less features. In contrast to the initial results, this means that 70 fewer build dependencies were found to be unneeded (25% of the original amount). The following binary packages were found to be meta packages and are thus not false positives in the result anymore: bison, ca-certificates, default-jdk, doxygen-latex, g++-4.8-multilib, gcc-multilib, gcj-jdk, gfortran, gir1.2-freedesktop, gir1.2-glib-2.0, g++-multilib, iasl, jadetex, libblas-dev, libboost-dev, libcorosync-dev, libdb-dev, libgmp3-dev, libgphoto2-2-dev, libkrb5-dev, libopenais-dev, libpcap-dev, libreadline-dev, libsonic-dev, libtasn1-3-bin, libtasn1-3-dev, libxi-dev, libxmlrpc-c3-dev, libxmu-dev, libxt-dev, lynx, mysql-server, portaudio19-dev, python, python2.7-dev, python3, python3-all, python3-all-dbg, python3-all-dev, python3-minimal, python-all, python-all-dbg, python-all-dev, python-gobject, ruby, ruby-dev, swig, tcl-dev, texinfo, texlive, texlive-latex-recommended, tk-dev, valac, x11-utils, zip The classification is done automatically (without a blacklist) based on their debtags (role::metapackage or role::dummy) or whether they ships any regular file except for those in /usr/share/doc. If they were found to be a meta package by this method, then they will be considered to contain the files of the binary packages that were used to satisfy their dependencies. indicated by the attached two text files and the dd-list output. I attached the updated list of droppable build dependencies and build dependencies that can be moved to Build-Depends-Indep together with dd-list output. The results exclude python-defaults and python3-defaults (as requested by Scott Kitterman) and openldap (as requested by Ryan Tandy) and lirc (as requested by Stefan Lippers-Hollmann). Thank you Scott, Ryan and Stefan for already having fixed your packaging! Here is the updated MBF template email --%--- Subject: Please consider removing the build dependencies on $foo, $bar and $baz Severity: wishlist Usertag: unusedbd User: bootst...@lists.debian.org Dear Maintainer, the following build dependencies of this source package do not seem to be needed during an --arch-all build with sbuild: - $foo - $bar And the following do not seem to be needed during a --no-arch-all build with sbuild: - $baz Neither are any of their files accessed during the respective build nor are their dependencies on other binary packages required. This can mean that either one of those build dependencies 1. is useless old cruft 2. is architecture dependent and does not occur on amd64 but on other architectures 3. indicates a bug in the packaging where you intend to use the build dependency but where that is not happening in practice during the build 4. is a false positive of a dependency which is used as a meta package (only its dependencies are used but not its files) but not detected as one and for which the build does not fail if it is not installed Depending on the case, you should 1. remove the build dependency (if it was found in a --arch-all build) or move it to Build-Depends-Indep (if it was found in a --no-arch-all build) 2. add an architecture restriction 3. fix your packaging to make use of the build dependency 4. make the build fail when the contents of the binary package are not found (for example by passing an explicit ./configure flag) or report the problem to j.scha...@email.de (reply to this bugreport) so that this false positive is not reported again You can find more detail about the procedures that were used to find this problem in the MBF announcement on debian-devel: $email --%--- Is it missing anything? Thank you! cheers, josch == apache2_2.4.9-1.arch-all.unusedbd == libcap-dev:amd64=1:2.22-1.2 == apparmor_2.8.0-5.arch-all.unusedbd == dejagnu=1.5-3 texlive-latex-recommended=2014.20140528-3 == apr-util_1.5.3-2.arch-all.unusedbd == libpcre3-dev:amd64=1:8.31-5 python=2.7.6-2 == apt_1.0.3.arch-all.unusedbd == automake=1:1.14.1-3 == at-spi2-atk_2.10.2-3.arch-all.unusedbd == libglib2.0-bin=2.40.0-3 == bc_1.06.95-8.arch-all.unusedbd == bison=2:3.0.2.dfsg-2 == bison_3.0.2.dfsg-2.arch-all.unusedbd == autotools-dev=20140510.1 == blcr_0.8.5-2.1.arch-all.unusedbd == autoconf=2.69-6 automake=1:1.14.1-3 autotools-dev=20140510.1 libtool=2.4.2-1.7 == bluez_4.101-4.1.arch-all.unusedbd == bison=2:3.0.2.dfsg-2 gstreamer-tools
Re: possible MBF: automatically detecting unused build dependencies
Hi, Quoting gregor herrmann (2014-07-28 11:45:14) == libxml-parser-perl_2.41-1.arch-all.unusedbd == sharutils=1:4.14-2 Already fixed in 2.41-2. thanks! I assume you're planning to do a new run before actually filing the bugs? I cannot do a new run before September because I'm moving places twice within the next month and thus do not have a stable always-on machine available during that time. The only thing that could change this would be if I found easily accessible compute time elsewhere (I asked at debian-qa@l.d.o: http://lists.debian.org/20140726090503.4150.56356@hoothoot ) I thought that hardly any build dependencies get removed over time so that it would still be appropriate to fill bugreports for the June results now. If that would not be appreciated then I'll re-run the whole thing once I settled in at our new place some time in September. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140728100758.4150.21535@hoothoot
Re: possible MBF: automatically detecting unused build dependencies
Hi, I cannot believe I attached the wrong list once again. My sincere apologies to fill up your inboxes like that :( Attached are the right files and dd-list Quoting Johannes Schauer (2014-07-28 11:34:24) bison, ca-certificates, default-jdk, doxygen-latex, g++-4.8-multilib, gcc-multilib, gcj-jdk, gfortran, gir1.2-freedesktop, gir1.2-glib-2.0, g++-multilib, iasl, jadetex, libblas-dev, libboost-dev, libcorosync-dev, libdb-dev, libgmp3-dev, libgphoto2-2-dev, libkrb5-dev, libopenais-dev, libpcap-dev, libreadline-dev, libsonic-dev, libtasn1-3-bin, libtasn1-3-dev, libxi-dev, libxmlrpc-c3-dev, libxmu-dev, libxt-dev, lynx, mysql-server, portaudio19-dev, python, python2.7-dev, python3, python3-all, python3-all-dbg, python3-all-dev, python3-minimal, python-all, python-all-dbg, python-all-dev, python-gobject, ruby, ruby-dev, swig, tcl-dev, texinfo, texlive, texlive-latex-recommended, tk-dev, valac, x11-utils, zip and ignore this list. :( Sorry... josch == apache2_2.4.9-1.arch-all.unusedbd.real == libcap-dev:amd64=1:2.22-1.2 == apparmor_2.8.0-5.arch-all.unusedbd.real == dejagnu=1.5-3 texlive-latex-recommended=2014.20140528-3 == apr-util_1.5.3-2.arch-all.unusedbd.real == libpcre3-dev:amd64=1:8.31-5 == at-spi2-atk_2.10.2-3.arch-all.unusedbd.real == libglib2.0-bin=2.40.0-3 == bc_1.06.95-8.arch-all.unusedbd.real == bison=2:3.0.2.dfsg-2 == bison_3.0.2.dfsg-2.arch-all.unusedbd.real == autotools-dev=20140510.1 == blcr_0.8.5-2.1.arch-all.unusedbd.real == autoconf=2.69-6 automake=1:1.14.1-3 autotools-dev=20140510.1 libtool=2.4.2-1.7 == bluez_4.101-4.1.arch-all.unusedbd.real == bison=2:3.0.2.dfsg-2 gstreamer-tools=0.10.36-1.2 == boost-defaults_1.55.0.2.arch-all.unusedbd.real == libboost1.55-dev:amd64=1.55.0+dfsg-1 == ceph_0.80.1-1.arch-all.unusedbd.real == uuid-runtime=2.20.1-5.7 == chicken_4.8.0.5-1.arch-all.unusedbd.real == texinfo=5.2.0.dfsg.1-3 == cloog_0.18.2-1.arch-all.unusedbd.real == texinfo=5.2.0.dfsg.1-3 == cpio_2.11+dfsg-2.arch-all.unusedbd.real == texinfo=5.2.0.dfsg.1-3 == cunit_2.1-2.dfsg-1.arch-all.unusedbd.real == quilt=0.63-2 == cups-filters_1.0.53-1.arch-all.unusedbd.real == sharutils=1:4.14-2 == curl_7.37.0-1.arch-all.unusedbd.real == ca-certificates=20140325 openssh-server=1:6.6p1-5 python=2.7.6-2 == dbus-python_1.2.0-2.arch-all.unusedbd.real == xmlto=0.0.25-2 == dbus_1.8.2-1.arch-all.unusedbd.real == python=2.7.6-2 == devscripts_2.14.4.arch-all.unusedbd.real == libjson-perl=2.61-1 libterm-size-perl=0.207-1+b1 == doxygen_1.8.7-1.arch-all.unusedbd.real == texlive-extra-utils=2014.20140528-2 == e2fsprogs_1.42.10-1.arch-all.unusedbd.real == m4=1.4.17-4 == eglibc_2.18-7.arch-all.unusedbd.real == autoconf=2.69-6 quilt=0.63-2 == exiv2_0.23-1.arch-all.unusedbd.real == autotools-dev=20140510.1 dh-linktree=0.4 libjs-jquery=1.7.2+dfsg-3 == fftw3_3.3.4-1.arch-all.unusedbd.real == ghostscript=9.05~dfsg-8.1 transfig=1:3.2.5.e-3 == flite_1.4-release-8.arch-all.unusedbd.real == ghostscript=9.05~dfsg-8.1 texlive=2014.20140528-3 == fontconfig_2.11.0-5.arch-all.unusedbd.real == gperf=3.0.4-1 == freeglut_2.8.1-2.arch-all.unusedbd.real == libxt-dev:amd64=1:1.1.4-1 == gdb_7.6.2-1.1.arch-all.unusedbd.real == autoconf=2.69-6 flex=2.5.39-7 gcj-jdk=4:4.9.0-1 libtool=2.4.2-1.7 procps=1:3.3.9-5 python3-dev=3.4.1~rc1-1 == geoclue-2.0_2.1.8-1.arch-all.unusedbd.real == geoip-database=20140509-1 == geoip_1.6.0-1.arch-all.unusedbd.real == zlib1g-dev:amd64=1:1.2.8.dfsg-1 == ghostscript_9.05~dfsg-8.1.arch-all.unusedbd.real == freeglut3-dev:amd64=2.8.1-2 == gnome-keyring_3.12.0-2.arch-all.unusedbd.real == ca-certificates=20140325 docbook-xml=4.5-7.2 libglib2.0-doc=2.40.0-3 == gnome-vfs_2.24.4-4.arch-all.unusedbd.real == libattr1-dev:amd64=1:2.4.47-1 == gpm_1.20.4-6.1.arch-all.unusedbd.real == texi2html=1.82+dfsg1-3 texlive-base=2014.20140528-3 == graphviz_2.26.3-17.arch-all.unusedbd.real == libgd2-noxpm-dev=2.1.0-3 pdksh=49-2 == gsl_1.16+dfsg-1.arch-all.unusedbd.real == libtool=2.4.2-1.7 == gst-plugins-base0.10_0.10.36-1.1.arch-all.unusedbd.real == gir1.2-freedesktop=1.40.0-2 gir1.2-glib-2.0=1.40.0-2 == gst-plugins-base1.0_1.2.4-1.arch-all.unusedbd.real == gir1.2-freedesktop=1.40.0-2 == gstreamer1.0_1.2.4-1.arch-all.unusedbd.real == gir1.2-freedesktop=1.40.0-2 == gtest_1.7.0-3.arch-all.unusedbd.real == python=2.7.6-2 == gtk+2.0_2.24.23-1.arch-all.unusedbd.real == libatk1.0-doc=2.12.0-1 libcairo2-doc=1.12.16-2 libglib2.0-doc=2.40.0-3 libpango1.0-doc=1.36.3-1 == gtk+3.0_3.12.2-1.arch-all.unusedbd.real == gsettings-desktop-schemas=3.8.2-2 == gtkglext_1.2.0-3.1.arch-all.unusedbd.real == autotools-dev=20140510.1 == heimdal_1.6~rc2+dfsg-6.arch-all.unusedbd.real == libperl4-corelibs-perl=0.003-1 == hwloc_1.9-3.arch-all.unusedbd.real == autotools-dev=20140510.1 help2man=1.45.1 transfig=1:3.2.5.e-3 == ijs_0.35-10.arch-all.unusedbd.real == docbook-utils=0.6.14-3 docbook=4.5-5.1 ghostscript=9.05~dfsg-8.1 == klibc_2.0.3-1.arch-all.unusedbd.real == bison=2:3.0.2.dfsg-2 m4=1.4.17-4
Re: possible MBF: automatically detecting unused build dependencies
Hi, Quoting Scott Kitterman (2014-07-28 14:54:29) It is quite common for people to fix things based on the initial discussion about an impending MBF, so I think it would be less than impolite to not acknowledge that by filing bugs on obsolete data. The two packages that I show up for are fixed as well. I know. That's why I wrote a few emails up: The results exclude python-defaults and python3-defaults (as requested by Scott Kitterman) and openldap (as requested by Ryan Tandy) and lirc (as requested by Stefan Lippers-Hollmann). Thank you Scott, Ryan and Stefan for already having fixed your packaging! Nevertheless, I'm currently talking with Holger Levsen and it seems that it should be possible to implement the machinery on jenkins.debian.net. If you think that I should not file bugs for the current results, then I'll wait until the first jenkins runs come in with fresh data. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140728153328.4150.86639@hoothoot
Re: First steps towards source-only uploads
Hi, Quoting Ansgar Burchardt (2014-08-01 12:25:05) I want to understand purpose and syntax of this new field. The field was originally discussed in https://bugs.debian.org/619131 to allow easier processing of packages that build arch-specific binaries such as src:linux[1]. The architecture information was only (re)introduced later, as far as I know to help with bootstrapping, but it turns out that I also want this for source-only uploads to catch uploads introducing NEW binary packages. The field started out with the binary package name, type, section and priority. For bootstrapping it is necessary to know for which architectures and build profiles a binary package builds without having access to the unpacked source package but just from looking at the Packages/Sources files. Thus this information was added as optional fields. Every field that comes after the first four will be of the form key=value. The arch information will always be printed and the profile field only for a build with a build profile. Guillem explains the new field here: https://lists.debian.org/20140421140417.ga1...@gaara.hadrons.org cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140806051637.19236.26348@hoothoot
Re: First steps towards source-only uploads
Hi, Quoting Charles Plessy (2014-08-06 07:41:40) what do you think about the patch I sent to the Policy, for describing the syntax of the current optional fields of the Packages-List field ? Do you think that modifications are needed ? Would you second it ? https://bugs.debian.org/756835 Have a nice day, I had worded it a bit differently: diff --git a/policy.sgml b/policy.sgml index fbbe4a3..840951c 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3824,10 +3824,17 @@ Checksums-Sha256: the source package, considering every architecture. The first line of the field value is empty. Each one of the next lines describes one binary package, by listing its name, type, section and priority - separated by spaces. Fifth and subsequent space-separated items - may be present and parsers must allow them. See the - qref id=f-Package-TypePackage-Type/qref field for a list of - package types. + separated by spaces. + See the qref id=f-Package-TypePackage-Type/qref field for a + list of package types. + Fifth and subsequent space-separated items are key/value pairs of + the form ttkey=value1,value2/tt. The currently used keys are + the ttarch/tt key which lists the architectures a binary + package builds for and the ttprofile/tt key which lists the + build profiles a binary package builds in. + footnoteThe key/value syntax for all fields after the fourth was + introduced in prgndpkg/prgn version tt1.17.7/tt in + emJessie/em./footnote /p /sect1 cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140806060316.19236.55079@hoothoot
Re: Bug#756835: First steps towards source-only uploads
Hi, Quoting Matthias Urlichs (2014-08-07 07:54:26) Also, build profiles are not explained anywhere in Policy (unless that's been added after 3.9.5), so how would I discover which values are allowed / make sense? right. For the purpose of documenting the Package-List its usage for build profiles can just be omitted until build profiles are documented. Somehow I thought that a bug to document the restriction list syntax and build profiles had long been filled but apparently that wasn't the case so now there is #757760. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811075507.14069.52073@hoothoot
Re: First steps towards source-only uploads
Hi, Quoting Guillem Jover (2014-08-13 13:48:11) On Tue, 2014-08-12 at 13:27:38 +0200, Ansgar Burchardt wrote: There are also other problems that need to be eventually addressed: as far as I know there are some source packages producing arch:all binaries that cannot be built on all architectures. A Build-Architecture-Indep field was proposed to indicate where it should be built in this case[1], but for now I think we can require that maintainers have to upload the arch:all packages in this case. I think all proposed field names in that thread are rather confusing. In Debian packaging lingo build means several things, it can mean at least the build machine (!= host machine), or it can mean the act of building. In the case of Build-Depends style fields, it's referring to the act of building, but Architecture is related to the host system/compiler, so mixing the different meanings would be messy, think for example about cross-compiling. But is the question not *on* which architecture arch:all packages are built, and would the term build in Build-Architecture-Indep thus not be correct in both of its meanings (as the architecture I'm building *on* as well as the act of building)? cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140815092700.14069.93664@hoothoot
Detecting more undeclared conflicts (was: Re: Bug#758234: Raising priority of Debian packages)
Hi, Quoting Paul Wise (2014-09-07 11:38:27) On Fri, Sep 5, 2014 at 3:35 AM, Jakub Wilk wrote: We should probably also monitor package conflicts. We made a big fuss about node vs nodejs (and rightly so); but I bet that we have lots of other package pairs in the archive that can't be co-installed for no good reason. We have this already: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=edos-file-overwrite;users=trei...@debian.org https://qa.debian.org/dose/file-overwrites.html would it make sense to extend this test and not only check whether packages that share a file listed in Contents.gz can be co-installed but also packages which access/change/create the same files in their pre/post-install maintainer scripts do? Is the information about which files are touched in any way by maintainer scripts generated already somewhere? I think piuparts only takes two snapshots before installation and after removal but not one in the middle and neither runs a file system access tracer for all other changes to the filesystem? If this could be useful, then I could run some tests locally, using fatrace similar to how I used it to detect unneeded build dependencies. Does this make sense? cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907103606.3685.16945@hoothoot
Bug#761075: ITP: fuzzylite -- fuzzy logic control library
Package: wnpp Severity: wishlist Owner: Johannes Schauer j.scha...@email.de * Package name: fuzzylite Version : 5.0 Upstream Author : Juan Rada-Vilela jcr...@fuzzylite.com * URL : http://www.fuzzylite.com/cpp/ * License : LGPL3+ Programming Lang: C++ Description : fuzzy logic control library fuzzylite is a fuzzy logic control library which allows one to easily create fuzzy logic controllers in a few steps utilizing object-oriented programming. It supports five controller types (Mamdani, Takagi-Sugeno, Larsen, Tsukamoto, Inverse Tsukamoto), 20 linguistic terms, five integral and two weighted defuzzifiers, six hedge types, three import types (FuzzyLite Language, Fuzzy Inference System and Fuzzy Control Language) and six export types (C++, Java, FuzzyLite Language, FuzzyLite Dataset, Fuzzy Inference System, Fuzzy Control Language). It comes bundled with more than thirty examples for Mamdani, Takagi-Sugeno and Tsukamoto controllers from fuzzylite, octave and matlab, each in all supported export formats. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140910150609.8760.14056.reportbug@hoothoot
Re: ppc64 not in any-powerpc ?
Hi, Quoting Simon McVittie (2014-09-12 12:18:35) There might be situations where it would be useful to have a way to spell any member of the x86 family, any member of the PowerPC family, any member of the ARM family and any member of the MIPS family, but we currently don't. There is something that spells some members of the ARM family: $ dpkg-architecture -aarm -iany-arm echo yes || echo no yes $ dpkg-architecture -aarmel -iany-arm echo yes || echo no yes $ dpkg-architecture -aarmhf -iany-arm echo yes || echo no yes It it doesn't match arm64 though. $ dpkg-architecture -aarm64 -iany-arm echo yes || echo no no The common fallacy is that the foo in any-foo is the name of a Debian architecture while in fact it is the name of the CPU which is mapped to one or more Debian architectures by /usr/share/dpkg/triplettable This is even done wrongly by apt itself. See #748936. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140912131108.3685.97213@hoothoot
Re: ppc64 not in any-powerpc ?
Hi, Quoting Andrey Rahmatullin (2014-09-12 18:14:55) On Fri, Sep 12, 2014 at 03:11:08PM +0200, Johannes Schauer wrote: The common fallacy is that the foo in any-foo is the name of a Debian architecture while in fact it is the name of the CPU which is mapped to one or more Debian architectures by /usr/share/dpkg/triplettable Indeed, maybe we need to spell this more explicitly in the Policy? Either that (footnote 99 [1] gives some more explanation) or change the meaning of architecture wildcards into something more intuitive like os-debianarch as it is probably understood by most developers because the existing values for cpu happen to be (or used to be) debian architecture names. Another relevant bug about this topic is #694630. I think this and the apt bug #748936 give a good overview about how the current system works, why it exists and how alternatives could/should look like. Lintian successfully warns when things like any-armel are used in an attempt to let the second part be a debian architecture instead of a cpu name, so we don't have many of these in the archive. This is the relevant thread where I tried to identify packages with invalid architecture wildcards: http://lists.debian.org/2014052314.20924.60609@hoothoot cheers, josch [1] https://www.debian.org/doc/debian-policy/footnotes.html#f99 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140912225415.3685.31745@hoothoot
Re: binary data file and endianness and multiarch
Hi, Quoting Thomas Goirand (2014-09-28 12:42:24) Just to be sure: is ppc64el also using little endian? yes it is. Here is a great overview which answers that question and others: https://wiki.debian.org/ArchitectureSpecificsMemo cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140928112602.3685.73@hoothoot
Re: inconsistent versions of M-A: same packages
Hi Holger, Quoting Holger Levsen (2014-11-07 15:46:31) On Mittwoch, 5. November 2014, Ralf Treinen wrote: yes, you did miss something :-) first link on the page: Non-installable packages https://qa.debian.org/dose/debcheck/unstable_main/index.html thanks! (+doh, I guessed I oversaw these links on the debcheck pages and then didnt find anything for the outdated and file-overwrite checks so I didnt check again. but was your original question not about debcheck checking for multiarch co-installability across architectures? I agree with Ralf, that this would best be done not by debcheck but by a small script which compares if the Packages files for all distributions ship M-A:same packages in the same version. 2) if you ask about co-installablity of packages with the same name but different architectictures (and which are M-A=same) : this is a completely different (and much more interesting) question. Since dose is now multi-arch aware we can do this, but there are some questions to discuss about the precise scenario. Is this what you meant ? yes, these are the interesting cases to discover (and fix)! One interesting scenario for which to detect co-installability problems is when it comes to satisfying crossbuild dependencies. The following page is regenerated daily: http://bootstrap.debian.net/cross.html I have new hardware now, so I plan to extend the set of source packages that I check for crossbuild dependency satisfaction. Furthermore, a current problem of debcheck is, that it will only tell you one reason for non-installability but for fixing problems like this it is useful to have more than one reason to be able to parallelize bugreports and to better estimate how many packages are blocked by a certain multiarch problem. I'm currently working on an enhanced dose-builddebcheck version which will provide this functionality and when it's done, the web page above will show those additional problems too. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107151612.6173.861@hoothoot
Re: inconsistent versions of M-A: same packages
Hi Holger, Quoting Holger Levsen (2014-11-07 16:31:09) I agree with Ralf, that this would best be done not by debcheck but by a small script which compares if the Packages files for all distributions ship M-A:same packages in the same version. I'd happily run this script on jenkins.debian.net... if someone gives it to me ;-) is jenkins not triggered by pushes to git and thus sub-optimal for jobs that should be run like a cron job? I thought I'd run such a script on bootstrap.debian.net because that one has all Packages files for all architectures already and it would be trivial to run such a script in addition. But first I'd like to make sure what the interesting information would be. Would it be interesting to get the highest version of a binary package across all architectures and then check if that version exists in all architectures? Or would it be interesting to make sure that all versions exist across all architectures? (binary packages can exist in more than one version in unstable) botch currently ships the program botch-check-ma-same-versions which checks whether two Packages packages files agree on the M-A:same versions. Running it with amd64 and armhf unstable Packages files as input yields that all 25 version skews are due to binNMUs. I can extend the script to allow more than two Packages files as input and make the output machine readable. One interesting scenario for which to detect co-installability problems is when it comes to satisfying crossbuild dependencies. The following page is regenerated daily: http://bootstrap.debian.net/cross.html cool, very nice! I have new hardware now, so I plan to extend the set of source packages that I check for crossbuild dependency satisfaction. not sure what ressources you need, but maybe jenkins.d.n can also help here? (or alternatively, jenkins can also be used to just notify about problems like the d-i_overview* jobs from https://jenkins.debian.net/view/d-i_misc/ do...) Gladly, dose3 is very fast and even checking the whole archive doesn't take more than 3 minutes :) The problem before was, that I was running the script on a shared server with *very* limited resource constraints. But thanks for the offer! cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107154739.6173.88256@hoothoot
Re: inconsistent versions of M-A: same packages
Hi, Quoting Ralf Treinen (2014-11-07 17:35:06) It just appeared to me that we probably do not have a syntax to pinpoint a package built for a specific architecture. We meaning in this case dpkg, apt, and dose (if I am not mistaken). No. We do have it. The usual trick in dose would be, for all package names that exist on multiple architectures and that are M-A=same, to create a pseudo package like this: Package: p-multi Depends: amd64:p, i386:p and then to check installability of all these pseudo packages against a background of all the real Packages files. If the above is a Debian Packages file, then it must be the other way round. First the name and then the architecture. Dose3 internally does the encoding the other way round which is very confusing because it exposes this in its yaml output. If you wanted to write a cudf file, then your example is correct except that your : must be encoded as %3a. However, dose does currently not allow this syntax in dependencies, nor does dpkg TTBOMK. Dose distcheck does not allow it but dose buildcheck does. This is probably a bug in the distcheck frontend. Dpkg and apt allow this just fine. Try to do: apt-get install --simulate gcc-4.9-arm-linux-gnueabihf And you will end up with a number of armhf packages on your system (you have to enable armhf beforehand of course). Internally, dose already identifies packages by a triple (architecture,name,version), so it should be only a question of extending the input language. Once we can teach dose to accept the pseudo packages as described above we could run it with all the Packages files for all archiectures, which makes roughly 500.000 packages. This might fail not only because of M-A:same conflicts but also because some packages just conflict with each other through a normal Conflicts:. You probably need a clever way to partition dependencies. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141108054124.6173.66236@hoothoot
Re: inconsistent versions of M-A: same packages
Hi, Quoting Ralf Treinen (2014-11-09 15:58:15) On Sat, Nov 08, 2014 at 06:41:24AM +0100, Johannes Schauer wrote: Dpkg and apt allow this just fine. Try to do: apt-get install --simulate gcc-4.9-arm-linux-gnueabihf And you will end up with a number of armhf packages on your system (you have to enable armhf beforehand of course). Interesting, I did not know this. Is this documented somewhere? I just looked through apt-get(1) man page and couldn't find it there. it should definitely be documented in deb-control(5) but is not. I filed #768842. Otherwise, this is documented in https://wiki.ubuntu.com/MultiarchCross in sections Cross-architecture dependencies and Toolchains. There is an ambiguity in the docs whether support for them was introduced in dpkg 1.16.2 or 1.16.7. Confusingly, support seems to have been implemented in dpkg git commit 7acf7afa which was released with version 1.16.5. In any case, wheezy has 1.16.15, so it definitely supports this. This might fail not only because of M-A:same conflicts but also because some packages just conflict with each other through a normal Conflicts:. You probably need a clever way to partition dependencies. In my understanding these are precisely the cases which we want to find: packages which are supposed to be co-installable for different archiectures (since they are M-A=same), but which are not for some reason. Ah okay! Somehow I misunderstood your initial email that you wanted to say: Depends: foo:i386, foo:amd64, ..., bar:i386, bar:amd64,... But instead you just want... Depends: foo:i386, foo:amd64, ... ...in one package and... Depends: bar:i386, bar:amd64,... ... in the other, right? This sounds very useful, because it does not make sense to mark a package M-A:same if they cannot actually be co-installed across architectures. Instead of creating dummy packages for this task, you can also use dose-deb-coinstall for this job. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109161810.6173.86072@hoothoot
Re: inconsistent versions of M-A: same packages
Hi,
Quoting Ralf Treinen (2014-11-09 18:05:15)
But this does only one co-installability check at a time, right ?
correct, this makes your solution the better choice.
Anyway, the script is very simple (attached).
Nifty! I didn't know that dose-debcheck can read from stdin!
The raw result of a run for amd64 together with i386 can be found at [1].
What one can see from a cursery inspection of that result :
We have 4415 MA=same packages that exist both in amd and i386 (main/sid).
I didn't expect it to be that many.
1033 of them are not co-installable.
Where they are not co-installable, the reason seems mostly to be that
the packages have dependencies which are not MA-enabled. The first case in
the list, for instance:
audacious-dbg-pseudo is MA=same but depends on audacious which is MA=no.
On top of that it seems that there are many instances where the reason for a
package not being co-installable is a package from the same source package.
Thus, it would probably be very helpful to generate this information regularly
and display in the pts/tracker if a package makes another one
un-co-installable.
Here some quick results of why packages are not co-installable:
Missing:
import yaml
from collections import Counter
d = yaml.load(open(out))
Counter([p['reasons'][0].get('missing',
{'pkg':{'unsat-dependency':0}})['pkg']['unsat-dependency'] for p in
d['report']])
Gives as the top 10:
[unsat dependency] [X times encountered]
ttf-bitstream-vera 22
dh-python18
poppler-data (= 0.4.5-3~) | gs-cjk-resource 16
augeas-lenses15
libgsf-1-common (= 1.14.30-2) 9
lxmenu-data 8
openmpi-common (= 1.6.5-9) 6
krb5-config 4
vlc-plugin-pulse 4
gnat 3
From a purely dependency point of view, the above would be solved by making the
packages depended upon by the first column Multi-Arch:foreign. Of course this
is not the technically correct solution in many cases.
Conflict:
Counter([p['reasons'][0].get('conflict',
{'pkg1':{'package':0}})['pkg1']['package'] for p in d['report']])
Gives as the top 10:
[packages][makes X packages not co-installable]
perl-base 147
libtbb2 43
libglib2.0-dev35
libglu1-mesa-dev 32
libatlas3-base24
liblog4cpp5 22
libboost1.54-dev 21
libevdev2 20
libopenmpi1.6 14
libgupnp-1.0-413
From a purely dependency point of view, the above would be solved by making the
packages in the first column Multi-Arch:same. Of cource this is not the
technically correct solution in many cases.
Incidentally, I was just producing very similar results in the realm of
crossbuild satisfiability today. Unsurprisingly, the results look very similar
to the above. I posted a message about this to the debian-cross list today:
https://lists.debian.org/20141109152937.6173.82192@hoothoot
The important links from that message:
1. http://bootstrap.debian.net/cross.html (regenerated daily with 550 source
packages)
2. https://mister-muffin.de/p/Lc4-.html (static but all of sid)
3. https://mister-muffin.de/p/xOJO.html (static and package selection as in 1.
but multiple reasons)
The two sections in all three above links are also Missing and Conflicts,
just as I made the destinction above with Ralf's results.
cheers, josch
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014111009.6173.73845@hoothoot
Re: floating point testsuites on softfloat buildds
Hi,
Quoting Michael Banck (2014-12-01 14:22:12)
3. If 1 but not 2 are OK, should there be a way for packages to say I should
really be built on a buildd without softfloat?
One proposal might be to add something like XS-Buildd-Flags: hardfloat
to debian/control for packages, which ship a floating-point heavy
testsuite as a first step. This could possibly be extended for other
buildd machine-specific features (though I am not sure off-hand which
would benefit).
I was recently told in #debian-mentors that one can mail
${arch}@buildd.debian.org to restrict the buildd's on which a package is built
for architecture ${arch}. This might be able to solve your problem for now.
I would welcome a way that allows adding metadata to my source packages which
restricts the selection of buildd's it's built on.
For example I recently removed the --parallel argument from the dh invocation
in the d/rules of my package vcmi because individual calls to c++ easily eat
up to 2.3 GB of memory which leads to failures due to heavy swapping on buildds
that set DEB_BUILD_OPTIONS=parallel=5 but only have 4 GB of physical RAM.
So in addition to asking for hardfloat it would be handy if one could specify
the required memory consumption as a function of parallel jobs such that either
the right buildd can be selected or the number of jobs can be reduced
accordingly.
cheers, josch
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141201144756.6173.44130@hoothoot
Re: Can/should we have an efi/efi-any platform architecture?
Hi, Quoting Simon McVittie (2014-12-11 21:49:55) At a source package granularity, you can fake it by having a (possibly spurious) Build-Depends on the required package, which will put the requiring package in BD-Uninstallable state (e.g. https://buildd.debian.org/status/package.php?p=gtk-sharp3 explains why gtk-sharp3 isn't built on mips, which doesn't have mono). Either please don't add known-unused build dependencies as this will just make the dependency graph bigger and life for bootstrappers harder or, once jessie is released, if you feel you must, then add them with a !stage1 (or similar - not sure what would best apply here) build profiles restriction. That doesn't work for individual binary packages unless you hard-code architecture lists, though (e.g. a C library with an optional Java or C# binding would need to hard-code the Java/C# architectures). Perhaps this could be a build-profile? Source: dbus Build-Depends: ..., valgrind-dev archfeature.valgrind, ... Source: libfoo ... Package: libfoo-sharp Architecture: any Build-Profiles: archfeature.mono Firstly, the build profile spec was revised during the bootstrap sprint in Paris and what will end up in Jessie now does not have namespaces anymore. The reasoning is fully explained in the sprint result email section 6.2: https://lists.debian.org/debian-devel-announce/2014/08/msg00013.html Maybe we could even use package names as the features, so each feature in the archfeature namespace is automatically said to be available iff the package exists in apt? That covers the common interpreter that needs porting case, although I don't know whether there's anything like an efi-dev that could act as the flag for EFI architectures. Other possible colours for this bike shed include pkgexists.valgrind, with.valgrind, or (with the opposite sense) without.valgrind, missing.valgrind. Secondly, what you are expressing with: valgrind-dev archfeature.valgrind is that you do or do not depend on the package valgrind-dev depending on whether or not archfeature.valgrind evaluates to true (however this is resolved). Build profiles are NOT meant for tagging purposes but for conditional selection of build dependencies. The disjunctive normal form expression of build profiles does not make sense for tagging purposes as needed for this use case (archfeature.valgrind is used like a tag that adds meaning to the build dependency valgrind-dev). For this reason I don't think that build profiles will solve this problem. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212104050.15300.84986@hoothoot
Re: Can/should we have an efi/efi-any platform architecture?
Hi, Quoting Dimitri John Ledkov (2014-12-11 22:28:07) And it will require a long time to be used. Imho this smells more like a build profile e.g. BuildDepends: does-not-implement-efi !efi That way on non-efi implementing architectures the package will get stuck in a dep-wait state. I wouldn't say it smells like a use for build profiles because it would require builders to set the DEB_BUILD_PROFILES variable on known architectures. Depending on whether or not you see it as one, this might open a can of worms because this technique could then be abused for other non-efi source packages which should also only be built on a certain set of architectures. This in turn will increase the amount of existing build profile names which is currently a well defined set of cardinality six. Depending on whether or not you want Debian to use build profiles more like Gentoo USE flags (Debian build profiles are equally powerful in what they allow to express) instead of limiting build profiles to special situations like bootstrapping or cross building, this increase of build profile names might be a good or a bad thing. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014121232.15300.26065@hoothoot
Using build profiles beyond bootstrappingcross (was: Re: Can/should we have an efi/efi-any platform architecture?)
Hi, Quoting Simon McVittie (2014-12-12 12:09:05) Yes, but I think that's exactly what I want for dbus' use-case? I want to build-depend on valgrind (I thought it was valgrind-dev, but it's actually valgrind) on exactly those architectures to which valgrind has been ported, so that the debug flavour of libdbus can have its optional valgrind instrumentation on those architectures; but on architectures to which valgrind has not yet been ported, dbus still needs to produce working binaries. Some packages solve this by copying (a random snapshot of) the valgrind headers into their source code, but I'd prefer to minimize the number of embedded code copies. At the moment that's: Build-Depends: ..., valgrind [amd64 armhf i386 mips mipsel powerpc ppc64 s390x], ... which is an inconvenient amount of hard-coding, and has led to one RC bug already (when valgrind dropped support for armel). With build profiles (which I'll reinstate in unstable when jessie becomes stable) it would be something like: Build-Depends: ..., valgrind [amd64 armhf i386 mips mipsel powerpc ppc64 s390x] !stage1, ... but I'd rather have Build-Depends: ..., valgrind arch-where-valgrind-exists !stage1, ... or whatever spelling. okay. I get you now. Debian build profiles can express what USE flags do for Gentoo. What you probably want is: Build-Depends: ..., valgrind !without-valgrind, ... No need for the !stage1 because you will probably have the without-valgrind build profile activated during a bootstrap unless you already have valgrind. Then buildds could set DEB_BUILD_PROFILES=without-valgrind on architectures without valgrind. Whether you call it valgrind or without-valgrind depends on what you want the default to be. In this regard, Debian build profiles work opposite to Gentoo USE flags. By default, no build profile is active which in Debian means: build everything with all features active. If no USE flag is enabled in Gentoo you get a very minimal build. Thus, if you want the default build to build *with* valgrind, then your profile should be named without-valgrind and only be set when you want to build without it (for example during bootstrapping or on architectures that don't have valgrind). Similarly, db5.3 has Build-Depends: ..., default-jdk [!m68k], ... (and other Java things on [!m68k]) and gdcm has Build-Depends: ..., cli-common-dev (= 0.8~) [amd64 armel i386 kfreebsd-amd64 kfreebsd-i386 powerpc ppc64 s390x], ... (and other Mono things on those architectures) but there'd be no need for the Java and Mono maintainers to coordinate these ad-hoc architecture lists with other maintainers via bugs like #719842, #575138, #541612, #477855, #699379, #657779 if packages like db5.3 and gdcm could instead say: Build-Depends: ..., default-jdk arch-where-java-exists, ... Build-Depends: ..., cli-common-dev arch-where-mono-exists, ... It is entirely possible to add build profile names for a bunch of stuff like valgrind, java and mono (they would probably just be called without-valgrind, without-java and without-mono - or s/without/no/). The question is, whether the Debian project wants to extend build profiles beyond it's current limited use for bootstrapping and cross building and thus make them more like Gentoo USE flags? This also means that if somebody builds the package locally on an architecture without valgrind, for example, then they must not forget to without-valgrind build profile or they will trigger a FTBFS. Thus it probably makes more sense to let the list of profiles that are active by default be stored somewhere on the system (which is also how it's done in Gentoo for USE flags). A good place for such a hypothetical list is probably dpkg. In that case, the buildds would also not need to do anything special when building. Should that be done, it probably also makes sense to add a facility to overwrite the default. In Gentoo they prefix a minus. In Debian, the most logical syntax would probably be the exclamation mark. So to enable valgrind on an architecture that doesn't have it would then be like: DEB_BUILD_PROFILES=!without-valgrind dpkg-buildpackage or dpkg-buildpckage -P!without-valgrind You could then even go one step further and say: if dpkg stores a list of build profiles that are activated by default on an architecture, then the default list of active build profiles is not empty and there is no need to have a without-valgrind profile because the valgrind profile could be active by default on architectures with valgrind. This would make it quite a bit more readable and even more similar to Gentoo :P Thoughts? cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212114840.15300.27739@hoothoot
