On Fri, 05 Jun 2009 08:02:20 +0200
Luca Capello wrote:
> Package: gpe-gallery
> Version: 0.97-3
> Severity: minor
> Hello,
>
> the .desktop file looks for gpe-gallery.png while only the .xpm version
Bah - this is getting really annoying. If Debian is going to stick with
two menu systems, why d
On Fri, 05 Jun 2009, Luk Claes wrote:
> The thing is that it is not a bug in the buildd chroot or buildd
> setup, it's a porter issue...
I haven't really analyzed the bug (and only read this thread in the
most superficial manner imaginable), so what I said previously (and
say below) shouldn't be c
Don Armstrong wrote:
> On Thu, 04 Jun 2009, Manoj Srivastava wrote:
>> If it is not a bug in the package (in other words, no change made
>> in the package would fix the issue), I see no point in keeping it
>> open. It would be nice, however, is a psuedo-package were created
>> for the buildds (
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 383 (new: 5)
Total number of packages offered up for adoption: 133 (new: 0)
Total number of packages request
On Thu, 2009-06-04 at 18:40 +0200, Stefano Zacchiroli wrote:
> I'm packaging this is because PEAK Rules is one of the missing
> dependencies for turbojson, no matter its being currently uploaded to
> unstable. Without PEAK Rules, turbojson is currently useless and makes
> in turn unusable both turb
On Thu, 04 Jun 2009, Manoj Srivastava wrote:
> If it is not a bug in the package (in other words, no change made
> in the package would fix the issue), I see no point in keeping it
> open. It would be nice, however, is a psuedo-package were created
> for the buildds (or one per buildd, though t
Hi,
I think there are some resources in:
https://fossbazaar.org
Not exactly the one you mentioned, but something similar
At Thu, 04 Jun 2009 09:10:30 +0200,
Frank Lin PIAT wrote:
>
> Hello,
>
> I am preparing a document to advocate further use of open-source
> software in my organization.
>
>
Package: wnpp
Severity: wishlist
Owner: Pini
* Package name: syrthes
Version : 3.4.2
Upstream Author : EDF R&D
* URL : http://rd.edf.com/syrthes
* License : GPL
Programming Lang: Fortran, C
Description : Transient thermal simulations in complex solid g
Norbert Preining wrote:
> On Do, 04 Jun 2009, Luk Claes wrote:
>> Except for arguing, mixing (non?) bugs and resisting to upload an easy
>> workaround might have made things worse btw...
>
> And that easy workaround would be???
To only conditionaly use a command that seems to not always be availa
Luk Claes wrote:
> Frank Küster wrote:
>> Luk Claes wrote:
>>
>>> Fine, though taking the trouble to talk to the porters might still be
>>> worthwile.
>>
>> Yes, but definitely not after I've spend hours of my little Debian
>> arguing about non-bugs with people who don't read what I say and in
On Do, 04 Jun 2009, Luk Claes wrote:
> Except for arguing, mixing (non?) bugs and resisting to upload an easy
> workaround might have made things worse btw...
And that easy workaround would be???
Best wishes
Norbert
---
Frank Küster wrote:
> Frank Küster wrote:
>
>> Luk Claes wrote:
>>
>>> Fine, though taking the trouble to talk to the porters might still be
>>> worthwile.
>> Yes, but definitely not after I've spend hours of my little Debian
>
Frank Küster wrote:
> Luk Claes wrote:
>
>> Fine, though taking the trouble to talk to the porters might still be
>> worthwile.
>
> Yes, but definitely not after I've spend hours of my little Debian
> arguing about non-bugs with people who don't read what I say and instead
> insist on blaming ou
Frank Küster wrote:
> Luk Claes wrote:
>
>> Fine, though taking the trouble to talk to the porters might still be
>> worthwile.
>
> Yes, but definitely not after I've spend hours of my little Debian
^time
> arguing about non-bu
Philipp Kern wrote:
> On 2009-06-04, Frank Küster wrote:
>> And what would be the criterion for "solved"? After an analysis of
>> N build logs of random packages on that buildd show no segfaults any
>> more? I am not going to do that.
>>
>> It's not a bug in my package; I am not going to take
Luk Claes wrote:
> Fine, though taking the trouble to talk to the porters might still be
> worthwile.
Yes, but definitely not after I've spend hours of my little Debian
arguing about non-bugs with people who don't read what I say and instead
insist on blaming our packages without explaining why.
Frank Küster wrote:
> Luk Claes wrote:
>
>>> That doesn't solve my problem: Should I
>>> - make sure that the porters, buildd admins etc. are aware of the
>>> problem and simply close the bug?
>> You might want to downgrade the bug and only close it when it is realy
>> solved?
>
> And what wo
Package: wnpp
Severity: wishlist
Owner: Stefano Zacchiroli
* Package name: python-peak.rules
Version : 0.5a1
Upstream Author : Phillip J. Eby
* URL : http://pypi.python.org/pypi/PEAK-Rules
* License : ZPL
Programming Lang: Python
Description : generic f
On Thu, Jun 04, 2009 at 03:01:03PM +0200, Stefano Zacchiroli wrote:
> Another important note is that this package depends on
> zope.sqlalchemy which is not currently packaging. I'm trying to
> contact the Zope maintainers to decide whether I'm to package it or
> they are.
Just receive a comment ab
Gunnar Wolf writes:
> Has this suggestion been pushed upstream? Don't you think we would do
> a greater service to the KDE users if we convinced the authors instead
> of just the Debian maintainers? (or at least, if we listened at their
> arguments as well)
My understanding of the job of package
John Goerzen dijo [Sun, May 31, 2009 at 08:24:17AM -0500]:
> > Actually an advisory dialog (which could be turned off) would make some
> > sense.
> > ("The author of this PDF document didn't mean to allow you $foo, do you want
> > to continue anyway? Abort Continue")
> >
> > Then a) you are awar
Roberto C. Sánchez dijo [Sun, May 31, 2009 at 07:27:56AM -0400]:
> Here is behavior that I consider to be equally sane:
>
> $ su -
> Password:
> # echo ciao >/tmp/foo
> # chmod -w /tmp/foo
> # exit
> logout
> $ vim /tmp/foo
> :w -> E45: 'readonly' option is set (add ! to override)
> :w! -> "/tmp/f
Package: wnpp
Severity: wishlist
Owner: Stefano Zacchiroli
* Package name: python-tg.devtools
Version : 2.0
Upstream Author : Kevin Dangoor and contributors
* URL : http://www.turbogears.org/
* License : MIT/X
Programming Lang: Python
Description : deve
Package: wnpp
Severity: wishlist
Owner: Ray Wang
* Package name: mono-uia
Version : 1.0
Upstream Author : Mono Accessibility
* URL : http://www.mono-project.com/Accessibility
* License : MIT/X
Programming Lang: C#
Description : Implementations of memb
Uwe Kleine-König wrote:
Hi,
I was wondering about how far are we with implementing a RT kernel in
Debian... Some progress here? Would be nice.
The patch I created that "fits" on Debian's vanilla kernel creates
conflicts on the sources with the Debian patches.
I hope to be abl
On 2009-06-04, Frank Küster wrote:
> And what would be the criterion for "solved"? After an analysis of
> N build logs of random packages on that buildd show no segfaults any
> more? I am not going to do that.
>
> It's not a bug in my package; I am not going to take responsibility for
> it.
Th
Ken Bloom writes:
> Josselin Mouette wrote:
>> Le lundi 01 juin 2009 à 16:26 +0200, Goswin von Brederlow a écrit :
>> > > What has the initramfs got to do with this?
>> >
>> > For / to be on LVM you need an initramfs. / on raid (with custom
>> > kernel) or plain partition works without one.
>
On Jun 04, Giacomo Catenazzi wrote:
> Do we really need to handle such hotplugs? We could require that
> all boot hardwares must be available short after boot loader. The
> later plugged hardware will be shown only later, when the system
> in up. I see no disadvantage, and make thing easier, mor
Luk Claes wrote:
>> That doesn't solve my problem: Should I
>
>> - make sure that the porters, buildd admins etc. are aware of the
>> problem and simply close the bug?
>
> You might want to downgrade the bug and only close it when it is realy
> solved?
And what would be the criterion for "sol
Hello,
I am preparing a document to advocate further use of open-source
software in my organization.
I am looking for some statistics of the [main] licenses used in Debian
packages (or some statistics about the license used in open-source
software at large).
Are you aware of such analyze?
Thank
30 matches
Mail list logo
