On 30/08/11 at 10:34 +0100, Lars Wirzenius wrote:
> But both are wrong, too: it's always the job of both. It's not supposed
> to be a struggle between maintainers and porters, but everyone in
> Debian against bugs and shortcomings of our system.
Sure. But what happens when bugs and shortcomings ar
Package: wnpp
Severity: wishlist
Owner: "Jotam Jr. Trejo"
* Package name: libpoe-component-syndicator-perl
Version : 0.06
Upstream Author : Hinrik Örn Sigurðsson
* URL : http://search.cpan.org/dist/POE-Component-Syndicator/
* License : (GPL, Artistic)
Progr
On Wed, 31 Aug 2011 00:01:07 +0200, Kurt Roeckx wrote:
> On Mon, Aug 29, 2011 at 01:06:15PM +0200, Lucas Nussbaum wrote:
>> >
>> > Sorry, but I disagree here. I don't think it is reasonable to expect
>> > porters to check for build failures in general, especially as many of
>> > them just happen
On Mon, Aug 29, 2011 at 01:06:15PM +0200, Lucas Nussbaum wrote:
> >
> > Sorry, but I disagree here. I don't think it is reasonable to expect
> > porters to check for build failures in general, especially as many of
> > them just happen because of generic maintainer errors and
> > cross-architectur
Selenaa Renea.
He learned they were the wife and the younger sist Alana Alonzoa
Karinaa Rosalyna Kirstena It was not like the Heat-Ray, I said, and for a ti
Meghana Williea Sydneya Cynthiaa Olgaa Elberta
The window had been burst in by a mass of garden m
Package: wnpp
Owner: Salvatore Bonaccorso
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
* Package name: libio-prompter-perl
Version : 0.001001
Upstream Author : Damian Conway
* URL : http://search.cpan.org/dist/IO-Prompter
but if you mean strict "meta" as in it has no files but depends on real
specific libraried packages ...
as far as I know strict "meta" are already well versioned and any package, such as perl, acts as a
"meta" in some way by depending on other versions of packages to "fully install" - in the s
On mar., 2011-08-30 at 16:11 +0100, Wolodja Wentland wrote:
>
> I agree that a general change of all metapackages is probably not a good idea,
> but I think that changing the root-nodes of the metapackage tree (i.e.
> metapackages like gnome, xfce4, kde-full, ...) is a sensible change. It is in
>
Let me say this (i'm working on a new tsort you can say - but slowly as it's
not my day job).
if "Virtual package" is the same as "meta package"... (which ends up being a simple lookup before
package list ordering / dropping)
Why worry about Recommends or Suggests ? Only after dpkg develops
Package: wnpp
Severity: wishlist
Owner: NeuroDebian Team
* Package name: scikits.image
Version : 0.2.1
Upstream Author : Stefan van der Walt
* URL : http://scikits-image.org/
* License : BSD
Programming Lang: Python, Cython
Description : image processin
On Tue, Aug 30, 2011 at 12:32 +0200, Cyril Brulebois wrote:
> Wolodja Wentland (30/08/2011):
> > It is my impression that the problems mentioned in my initial mail can
> > be solved by changing metapackages (like those mentioned by Cyril in
> > his reply) to use Recommends instead of Depends.
> >
On 30/08/2011 16:46, Andreas Tille wrote:
> On Tue, Aug 30, 2011 at 11:27:48AM +0100, Wolodja Wentland wrote:
>> It is my impression that the problems mentioned in my initial mail can be
>> solved by changing metapackages (like those mentioned by Cyril in his
>> reply) to use Recommends instead of
On Tue, Aug 30, 2011 at 11:27:48AM +0100, Wolodja Wentland wrote:
> > > is there a specific reason why metapackages depend rather then recommend
> > > packages they are meant to pull in?
>
> I never meant to imply that *all* metapackages use Depends.
For my perception of your sentence at least a
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: python-django-autoslug
Version: 1.4.1
Upstream Author: Andy Mikhailenko
* URL: http://bitbucket.org/neithere/django-autoslug/
* License: LGPL-3
Description: An automated slug field for Django.
Django-a
On Tue, Aug 30, 2011 at 4:00 PM, Bastien ROUCARIES
wrote:
> On Tue, Aug 30, 2011 at 3:52 PM, David Bremner wrote:
>> On Tue, 30 Aug 2011 13:53:19 +0200, Steffen Möller
>> wrote:
>>
>>> it seems like OpenCL is becoming routine. The -dev files are luckily
>>> shared between many architectures f
On Tue, 30 Aug 2011 16:08:19 +0200, Bastien ROUCARIES
wrote:
> > Not sure documentation date from 5 days ago :)
> > http://people.freedesktop.org/~steckdenis/clover/index.html
>
> See also blog about the clover google of code http://steckdenis.wordpress.com/
>
> And git tree here http://cgit.fr
On Tue, Aug 30, 2011 at 3:52 PM, David Bremner wrote:
> On Tue, 30 Aug 2011 13:53:19 +0200, Steffen Möller
> wrote:
>
>> it seems like OpenCL is becoming routine. The -dev files are luckily
>> shared between many architectures from what I understood, just the
>> libraries/drivers are platform
On Tue, 30 Aug 2011 13:53:19 +0200, Steffen Möller
wrote:
> it seems like OpenCL is becoming routine. The -dev files are luckily
> shared between many architectures from what I understood, just the
> libraries/drivers are platform specific.
The Khoros headers are indeed free, however as far
Hello,
it seems like OpenCL is becoming routine. The -dev files are luckily
shared between many architectures from what I understood, just the
libraries/drivers are platform specific. The NVidia maintainers have
http://packages.debian.org/sid/nvidia-opencl-icd
in our distribution. For AMD/AT
On 08/30/2011 07:33 AM, Nobuhiro Iwamatsu wrote:
efilinux is a UEFI OS loader. This has no bells or whistles,
it is simply a prototype with the minimum amount of smarts required
to load a linux kernel (though loaders for other formatscould be added).
fyi, this will get obsolete once syslinux ha
Wolodja Wentland (30/08/2011):
> It is my impression that the problems mentioned in my initial mail can
> be solved by changing metapackages (like those mentioned by Cyril in
> his reply) to use Recommends instead of Depends.
>
> I am, however, not entirely sure if there are any good reasons for
On Tue, Aug 30, 2011 at 09:26 +0200, Andreas Tille wrote:
> On Mon, Aug 29, 2011 at 04:40:30PM +0100, Wolodja Wentland wrote:
> > is there a specific reason why metapackages depend rather then recommend
> > packages they are meant to pull in?
> The statement that metapackages depend from packages
Package: wnpp
Severity: wishlist
Owner: Tanguy Ortolo
* Package name: itstool
Version : 1.1.0
Upstream Author : Shaun McCance
* URL : http://itstool.org/
* License : GPL-3
Programming Lang: Python
Description : translate XML documents with PO files
I
In the blue corner, we have The Maintainer, who says: "I have a problem
with one architecture, and my package does not work there. It's The
Porter's job to debug and fix that. They know what's usually broken
on their architecture, so it's easier for them."
In the green corner, we have The Porter,
On 08/29/2011 07:15 PM, Lucas Nussbaum wrote:
> On 29/08/11 at 18:21 +0200, Bernd Zeimetz wrote:
>> On 08/29/2011 04:49 PM, Lucas Nussbaum wrote:
>>> I'm also completely tired of investigating issues which are already
>>> known to porters, which is unavoidable if each maintainer is asked
>>> to fir
* Lucas Nussbaum [110829 19:28]:
> I think that bugs caused by important differences compared to other
> Debian architectures are the porter's job to handle, not the
> maintainer's.
> That includes stuff like:
> - missing/different packages on $ARCH
> - missing/different libraries on $ARCH
> - dif
Package: wnpp
Severity: wishlist
Owner: Damyan Ivanov
* Package name: libdbd-firebird-perl
Version : 0.55
Upstream Author : Popa Marius Adrian
* URL : http://search.cpan.org/dist/DBD-Firebird/
* License : Perl
Programming Lang: Perl
Description : Perl
Package: wnpp
Severity: wishlist
Owner: "Raphaël Hertzog"
* Package name: gnome-shell-timer
Version : 0.0.20110830+git42ea6ca-1 (git snapshot)
Upstream Author : Ole Ernst
* URL : https://github.com/olebowle/gnome-shell-extension-timer
* License : GPL-3+
Prog
Andreas Tille (30/08/2011):
> On Mon, Aug 29, 2011 at 04:40:30PM +0100, Wolodja Wentland wrote:
> > is there a specific reason why metapackages depend rather then
> > recommend packages they are meant to pull in?
>
> The statement that metapackages depend from packages is not true in
> general.
On Mon, Aug 29, 2011 at 04:40:30PM +0100, Wolodja Wentland wrote:
> is there a specific reason why metapackages depend rather then recommend
> packages they are meant to pull in?
The statement that metapackages depend from packages is not true in
general. A counter example are those metapackages
30 matches
Mail list logo
