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
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
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
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
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
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
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,
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
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
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:
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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...
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ?
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
1 - 100 of 576 matches
Mail list logo
