Package: wnpp
Severity: wishlist
Owner: Janos Guljas
* Package name: python-django-mptt
Version : 0.4.2
Upstream Author : Jonathan Buchanan
* URL : http://github.com/django-mptt/django-mptt
* License : MIT
Programming Lang: Python
Description : Modified
Package: wnpp
Severity: wishlist
Owner: Janos Guljas
* Package name: python-django-faincms
Version : 1.1.4
Upstream Author : Matthias Kestenholz
* URL : http://github.com/matthiask/feincms
* License : BSD
Programming Lang: Python
Description : Django-b
Package: wnpp
Severity: wishlist
Owner: Alessio Treglia
* Package name: ladish
Version : 0.3
Upstream Author : Nedko Arnaudov
* URL : http://ladish.org
* License : GPL
Programming Lang: C
Description : session management system for JACK applications
Package: wnpp
Severity: wishlist
Owner: "P. J. McDermott"
* Package name: gtk2-engines-oxygen-gtk
Version : 1.0.1
Upstream Author : Bellegarde Cédric , Hugo Pereira Da Costa
, Ruslan Kabatsayev
* URL :
https://projects.kde.org
Package: wnpp
Severity: wishlist
Owner: "Siegfried-Angel Gevatter Pujals"
* Package name: zeitgeist-datahub
Version : 0.5.1
Upstream Author : Michal Hruby
* URL : https://launchpad.net/zeitgeist-datahub
* License : LGPL-3+
Programming Lang: Vala
Descriptio
On Monday 24 January 2011, Iustin Pop wrote:
> This is a very good idea, but I think it could be taken two steps
> further. These are just some ideas I have but did not explore in
> depth, so take them with a grain of salt.
>
> First, tests run during a package build are good, but they do not
> en
Package: wnpp
Severity: wishlist
Owner: Alessio Treglia
* Package name: laditools
Version : 0~git.f4d4a2
Upstream Author : Marc-Olivier Barre
* URL : http://marcochapeau.org/software/laditools
* License : GPL
Programming Lang: Python
Description : tool
On Mon, Jan 24, 2011 at 10:37:26AM +0100, Holger Levsen wrote:
> Hi,
>
> On Montag, 24. Januar 2011, Iustin Pop wrote:
> > Second, README.test are designed for human consumption, whereas a
> > standardisation of how to invoke the tests would allow for much more
> > automation. E.g. piuparts would
On Mon, Jan 24, 2011 at 03:02:17PM +0100, Christian Kastner wrote:
> I was
> wondering though if anybody had a better approach to recommend?
Simply remove them. They are not needed for proper operation, as the
shlibs file works as fallba
Hi Henrique,
On Mon, 24 Jan 2011, Henrique de Moraes Holschuh wrote:
> No. When we backport something, we are perfectly capable of backporting
> dpkg-dev first.
> Crap happens when you need backported debhelper, should whomever did that
> backport have neglected to _change_ debhelper to do whate
Package: wnpp
Severity: wishlist
Owner: Ron
* Package name: opus-codec
Version : 0.1
Upstream Author : xiph.org and others
* URL : http://www.xiph.org/
* License : 2-clause BSD
Programming Lang: C
Description : A standard track, low-latency audio codec
On Mon, 24 Jan 2011, Yaroslav Halchenko wrote:
> Alternatively, version of dpkg could be lowered and functionality
> conditioned on the version of dpkg (thus implementing necessary logic to
> support older versions), it would imho be better and more flexible to
> please those backport-lovers, savin
On Mon, 24 Jan 2011, Christian Kastner wrote:
> >> One simple way to resolve this would be to rename the .symbols file
> >> during build and again during clean (or similar approaches); I was
> >> wondering though if anybody had a better approach to recommend?
> > I'd say you need a versioned build
On 01/24/2011 04:32 PM, Adam Borowski wrote:
> On Mon, Jan 24, 2011 at 03:02:17PM +0100, Christian Kastner wrote:
>> Hello,
>>
>> it was recently pointed out to me that one of my library packages
>> encountered a build error whilst attempting to backport it to an older
>> system.
>>
>> The build fa
Please do manually run os-prober (as root) on your system and report
the output as a bug against os-prober if it still says Vista.
Did you upgrade from Vista to Windows 7 or was it a clean install?
- Fabian
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "
On Mon, Jan 24, 2011 at 03:02:17PM +0100, Christian Kastner wrote:
> Hello,
>
> it was recently pointed out to me that one of my library packages
> encountered a build error whilst attempting to backport it to an older
> system.
>
> The build failed because I use symbol patterns, specifically c++
On Mon, Jan 24, 2011 at 03:11:47PM +, David Goodenough wrote:
> On Monday 24 January 2011, Andrey Rahmatullin wrote:
> > On Mon, Jan 24, 2011 at 02:28:28PM +, David Goodenough wrote:
> > > thinks that Window 7 is Windows Vista. I am installing an amd64 machine
> > > which already has the 6
On Monday 24 January 2011, Andrey Rahmatullin wrote:
> On Mon, Jan 24, 2011 at 02:28:28PM +, David Goodenough wrote:
> > thinks that Window 7 is Windows Vista. I am installing an amd64 machine
> > which already has the 64 bit version of Windows 7 Professional on it, and
> > when I came to inst
On Mon, Jan 24, 2011 at 02:28:28PM +, David Goodenough wrote:
> thinks that Window 7 is Windows Vista. I am installing an amd64 machine
> which already has the 64 bit version of Windows 7 Professional on it, and
> when I came to install Debian using the squeeze installer RC2 in the grub
> bit
thinks that Window 7 is Windows Vista. I am installing an amd64 machine
which already has the 64 bit version of Windows 7 Professional on it, and
when I came to install Debian using the squeeze installer RC2 in the grub
bit it said that it had detected Windows Vista loader. I am not sure this
mat
Hello,
it was recently pointed out to me that one of my library packages
encountered a build error whilst attempting to backport it to an older
system.
The build failed because I use symbol patterns, specifically c++ tags,
in the package's .symbols file. This feature was introduced in dpkg-1.15.6
On 24/01/11 02:52, Paul Wise wrote:
* README.test
An alternative is to just provide *-test Debian packages.
If the package exists then building it is the same as running a test of
the packages
it requires to be installed - maybe just the "*" package, but it could
also be an
integration test.
On Mon, Jan 24, 2011 at 07:48:18AM +0100, Iustin Pop wrote:
> IMHO what would be a sufficient first step would be much simpler:
> - being able to know if a package does offer build & post-install tests
> - how to run such tests
> - for post-install tests, what are the depedencies (Test-Depends? ;-)
Hi,
On Montag, 24. Januar 2011, Iustin Pop wrote:
> Second, README.test are designed for human consumption, whereas a
> standardisation of how to invoke the tests would allow for much more
> automation. E.g. piuparts would not only be able to test that the
> install succeeds, but the automated tes
24 matches
Mail list logo
