Package: wnpp
Severity: wishlist
Owner: Johannes Schauer
* Package name: python-pyneo
Version : 1.13
Upstream Author : Michael Dietrich
* URL : http://pyneo.org
* License : GPL3
Programming Lang: Python
Description : pyneo mobile stack: basis
Package: wnpp
Severity: wishlist
Owner: Johannes Schauer
* Package name: gsm0710muxd
Version : 1.13
Upstream Author : Michael Dietrich
* URL : http://pyneo.org
* License : GPL2+
Programming Lang: C
Description : GSM 07.10 Multiplexer
pyneo mobile
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~r
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
> somethin
and the updated dd-list
Sorry for not having attached the right files in my initial email :(
cheres, josch
"Adam C. Powell, IV"
mpi-defaults (U)
Adam Conrad
eglibc (U)
freetds (U)
Alan Woodland
blcr
Alessandro Ghedini
curl
valgrind
Alessio Treglia
gpac (U)
Alexander
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 v
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 dependenc
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 A
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 once build profiles
> > are allo
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
> >libtool
>
> ==> libtool_2.4.2-1.7.arch-all.unusedbd <==
> gfortran=4:4.8.2-4
>
> gfortran Depends on gfortran-4.8, and
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
Hi,
Quoting Jakub Wilk (2014-07-10 12:45:36)
> * Johannes Schauer , 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 optione
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 t
Package: wnpp
Severity: wishlist
Owner: Johannes Schauer
* Package name: pdf2htmlex
Version : 0.11
Upstream Author : WANG Lu
* URL : http://github.com/coolwanglu/pdf2htmlEX
* License : GPL3, MIT, CC-BY-3.0
Programming Lang: C++
Description : Converts
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 bootstra
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 ar
Hi,
Quoting Russ Allbery (2014-07-16 22:17:23)
> Ben Hutchings 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 interfac
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 p
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
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-mu
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 ar
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 ar
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
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
pr
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 ar
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 b
Package: wnpp
Severity: wishlist
Owner: Johannes Schauer
* Package name: fuzzylite
Version : 5.0
Upstream Author : Juan Rada-Vilela
* URL : http://www.fuzzylite.com/cpp/
* License : LGPL3+
Programming Lang: C++
Description : fuzzy logic control
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
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 whic
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..
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 ov
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 jenkin
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,
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
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
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
* Package name: brickutils
Version : 0.1.6.1
Upstream Author : Mario Pascucci
* URL : http://bricksnspace.wordpress.com/brickutils/
* License : GPL2+
Programming Lang: Python
Description
Package: wnpp
Severity: wishlist
Owner: Johannes Schauer
* 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
Package: wnpp
Severity: wishlist
Owner: Johannes Schauer
* Package name: ldglite
Version : 1.2.6
Upstream Author : Don Heyse
* URL : http://ldglite.sourceforge.net/
* License : GPL2+
Programming Lang: C
Description : Display, edit and render 3D LEGO(R
Package: wnpp
Severity: wishlist
Owner: Johannes Schauer
* 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
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 specif
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
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 o
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
Hi,
Quoting YunQiang Su (2013-10-15 08:08:52)
> On Tue, Oct 15, 2013 at 2:03 PM, Johannes Schauer 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
> >
> >
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 el
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.
botc
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 a
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
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 s
(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
&
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 res
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 in
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 ab
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 compil
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
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 s
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++,gcc
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 m
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 ye
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. T
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 yo
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. Theref
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 an
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: http://wiki.debian.org/DebianBootstrap/S
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. The
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
> &
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 l
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
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
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 on
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:
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 paralle
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.
>
> Thi
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-
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 pack
Package: wnpp
Severity: wishlist
Owner: Johannes Schauer
* 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
Package: wnpp
Severity: wishlist
Owner: Johannes Schauer
* 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
Package: wnpp
Severity: wishlist
Owner: Johannes Schauer
* 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
Package: wnpp
Severity: wishlist
Owner: Johannes Schauer
* Package name: python-efl
Version : 1.8.1
Upstream Author : Gustavo Sverzut Barbieri and others
* URL : http://www.enlightenment.org
* License : LGPL-3
Programming Lang: Python, Cython
Description
Package: wnpp
Severity: wishlist
Owner: Johannes Schauer
* Package name: vcmi
Version : 0.95
Upstream Author : Micha³ Urbañczyk aka Tow
Ivan Savenko
Tom Zielinski aka Warmonger
AVS
Benjamin Gentner
Package: wnpp
Severity: wishlist
Owner: Johannes Schauer
* Package name: python-img2pdf
Version : 0.1.0
Upstream Author : Johannes Schauer
* URL : https://github.com/josch/img2pdf
* License : GPL3+
Programming Lang: Python
Description : Lossless
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 explic
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
> >
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
* Package name: botch
Version : 0.1
Upstream Author : Johannes Schauer
* URL : https://gitorious.org/debian-bootstrap/pages/Home
* License : LGPL3+ with OCaml linking exception
Programming Lang: OCaml
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 ...
>
> Each a
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 P
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
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-s
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
>
> That way on non-efi implementing architectures the package will get
> stuck in a dep-wait state.
I wou
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 debu
1 - 100 of 432 matches
Mail list logo
