Hi all,
we have many packages which are build against popt. Some of them
have included a bundled (inlined) verion of popt. But they are using
Debian's libopt-dev like pkg-config.
Can someone please advise me on how to handle this. I don't find a
section in Debian's Policy which describes how to h
On Sat, Nov 5, 2011 at 6:45 PM, Elimar Riesebieter wrote:
> we have many packages which are build against popt. Some of them
> have included a bundled (inlined) verion of popt. But they are using
> Debian's libopt-dev like pkg-config.
Sounds like a bunch of bugs to be filed and info to be added t
On Sat, Nov 5, 2011 at 6:45 PM, Elimar Riesebieter wrote:
> Thanks for any suggestions
I forgot to say: if you are contacting upstreams, please include this URL:
http://wiki.debian.org/UpstreamGuide
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-devel-requ.
Hiya,
On Sat, Nov 05, 2011 at 07:00:58PM +0800, Paul Wise wrote:
> On Sat, Nov 5, 2011 at 6:45 PM, Elimar Riesebieter wrote:
>
> > we have many packages which are build against popt. Some of them
> > have included a bundled (inlined) verion of popt. But they are using
> > Debian's libopt-dev like
* Paul Wise [05 19:00 +0800]:
[...]
> For Debian there are only disadvantages to inlined popt in most cases.
Thanks for all your advises. I'll take care of them by packaging a
new version of moc build against libpopt-dev.
Elimar
--
Alles was viel bedacht wird ist bedenklich!;-)
severity 645793 normal
reassign 645793 wnpp
retitle 645793 O: lprfax - Utility to allow printing to a fax modem
thanks
Hi,
I am orphaning lprfax[1] on behalf of Camm Maguire (see #645793).
Due to its RC bugs and its very low popcon I intend to request the
removal of this package in about 14 day
Package: wnpp
I'm orphaning the xmltoman package. The reason is that the current
maintainer is no longer active and I will not sponsor him anymore.
Best regards,
// Ola
--
--- Inguza Technology AB --- MSc in Information Technology
/ o...@inguza.comAnnebergsslingan 37
Am Freitag, 4. November 2011, 20:55:24 schrieb Tollef Fog Heen:
> So since gnome-shell actually needs gnome-bluetooth, the dependency
> should be demoted to a Recommends?
Needs? Why should a desktop _need_ bluetooth? It's not even common to have
bluetooth hardware.
HS
--
To UNSUBSCRIBE, email
Josselin Mouette wrote:
>
> Worse, it would let metapackages migrate to testing without the
> appropriate dependencies.
Then _this_ problem should be fixed and not used as a justification to use
Depends, either at the britney side or by providing "enforcing"
metapackages, not supposed to be use
Clint Adams writes ("Re: directory under /usr/bin -- Ok or not?"):
> On Fri, Nov 04, 2011 at 09:46:20PM +0100, Josselin Mouette wrote:
> > I don?t think Debian requests FHS to document something before we can
> > use it. The real problem with the bizarre GNU invention that
> > is /usr/libexec is th
Oh and:
> Clint Adams writes ("Re: directory under /usr/bin -- Ok or not?"):
> > On Fri, Nov 04, 2011 at 09:46:20PM +0100, Josselin Mouette wrote:
> > > I don?t think Debian requests FHS to document something before we can
> > > use it. The real problem with the bizarre GNU invention that
> > > is
package: wnpp
severity: wishlist
URL: https://fedorahosted.org/libverto/
Description: libverto provides a common interface on top of libev, libevent,
glib, tevent.
The goal is to allow development of asynchronous libraries that will work
with whatever event loop an application happens to be u
package: wnpp
severity: wishlist
URL: libradsec branch of http://www.project-moonshot.org/gitweb/radsecproxy.git
URL2: http://software.uninett.no/radsecproxy/
Description: libradsec is a library for RADIUS clients and servers
This library features support for RADSEC (RADIUS over TLS/DTLS) as wel
On Fri, 2011-11-04 at 20:55 +0100, Tollef Fog Heen wrote:
> So since gnome-shell actually needs gnome-bluetooth, the dependency
> should be demoted to a Recommends?
Well but then it would be enough for gnome-shell to depend on it.
And one should perhaps try to, whether it's easy to patch it, that
On Fri, Nov 04, 2011 at 10:12:59PM +0100, Frank Lin PIAT wrote:
> On Fri, 2011-11-04 at 10:21 +0100, Andreas Tille wrote:
> > On Fri, Nov 04, 2011 at 09:13:43AM +0100, Frank Lin PIAT wrote:
> > > Other package that depend on menu... mostly meta package
> > >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I would like to propose the goal of getting archive-wide support for
the optional debian/rules targets "build-arch" and "build-indep".
The intention is to finally solve issues like #619284 and the goal
is related to #629385.
According to Linti
Neil Williams wrote:
> Other than using sed and awk during the build on a package-specific
> basis with all the potential for typos, is there a wider use case for
> dissemination of variables from debian/rules into maintainer scripts?
In tex-common and texlive-{base,extra,lang,doc}, we use eper
Package: wnpp
Severity: wishlist
Owner: Sebastian Reichel
* Package name: radare2-bindings
Version : 0.8.8
Upstream Author : pancake
* URL : http://www.radare.org
* License : LGPL
Programming Lang: many
Description : bindings for radare2
The project a
]] Christoph Anton Mitterer
(please don't Cc me on mails to lists, it's rude and against the mailing
list etiquette)
[...]
| > I believe the Gnome packaging team would be happy to accept more members
| > if somebody wants to work on this and keep maintaining it.
|
| You shouln't take my comment
]] Hendrik Sattler
| Am Freitag, 4. November 2011, 20:55:24 schrieb Tollef Fog Heen:
| > So since gnome-shell actually needs gnome-bluetooth, the dependency
| > should be demoted to a Recommends?
|
| Needs? Why should a desktop _need_ bluetooth?
Maybe it uses the gnome-bluetooth DBus APIs uncon
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: g...@debian.org
Package name: jfugue
Version: 4.0.3
Upstream Author: David Koelle
URL: http://www.jfugue.org/
License: LGPL-2.1+
Description: Java API for music programming
JFug
Le vendredi 04 novembre 2011 à 21:21 +, Ben Hutchings a écrit :
> It's not a GNU invention; I believe it derives from BSD.
I stand corrected. That doesn’t make it have any more sense, though.
> Apparently it's for executables that don't belong in the path (rarely
> used from interactive shel
Le vendredi 04 novembre 2011 à 17:30 -0400, Daniel Ruoso a écrit :
> The basic idea is creating "dummy libraries" that would serve for the
> linking but that had no code on it. This would allow the linking to
> happen -- of course this only helps in the case where the build
> process doesn't run a
23 matches
Mail list logo
