On Sat, Feb 07, 2009 at 11:48:44PM +0100, Daniel Baumann wrote:
>
>however, for cosmetic reasons, it would be nicer to build them against
>final lenny. otherwise the release files on lenny final images would
>claim it's testing (without any other technical consequence) which feels
> akward.
Sure,
Package: wnpp
Severity: wishlist
Owner: Evgeni Golov
* Package name: xfswitch-plugin
Version : 0.0.1
Upstream Author : Jérôme Guelfucci
* URL :
http://goodies.xfce.org/projects/panel-plugins/xfswitch-plugin
* License : GPL-2+
Programming Lang: C
Descripti
Hi,
I have the bug report #489917 that complains that Jed can't handle
64‐bit kernel structures. In this special case, the stat() return with
EOVERFLOW Value too large to be stored in data type. Jed was compiled for
a 32‐bit kernel and is run with a 64‐bit kernel. The error can be fixed
by compili
On Sun, Feb 08, 2009 at 10:46:42AM +, Jörg Sommer wrote:
> I have the bug report #489917 that complains that Jed can't handle
> 64‐bit kernel structures. (...) The error can be fixed by compiling
> Jed with -D_FILE_OFFSET_BITS=64. Should I set this option for all
> 32‐bit builds or does it hav
hi,
On Sun, Feb 08, 2009 at 12:58:43PM +0100, Lionel Elie Mamane wrote:
> I'd think you should enable it for all 32 bit builds; it is, I think,
> a step in having support for large files (files bigger than 2 or 4
> gigabytes), something we wanted to have for... woody.
more specifically, what i th
Steffen Moeller writes:
> * Package name: globus-usage
> * URL : http://www.globus.org/
> * License : Apache 2
> Programming Lang: C/C++
> Description : Globus Toolkit - Usage Library
>
Debian-science has been collecting packages useful for science into
task packa
Russ Allbery wrote:
> Loïc Minier writes:
>
>> I can see how it would be useful to recommend calling dh_desktop as
>> soon as you distribute .desktop files just like it would be more useful
>> if we could inject any rules in packages via cdbs or the new "dh".
>> However, this is really packag
Steve McIntyre wrote:
> Cool. I'll be doing builds during Saturday; let's co-ordinate as we go
> so that we can release as quickly as possible.
i'll be online the whole weekend, so best would be if someone would ping
me on irc when i can start the builds. once they are finished, i'll let
steve kno
Michael Biebl wrote:
> Maybe i missinterpreted your conclusion, but this what I get in one of my
> packages:
> desktop-mimetype-without-update-call /usr/share/applications/...
>
> Now that we have triggers, I really don't see the benefit of adding such a
> lintian warning. Imho we should get rid
On Sun, Feb 08, 2009 at 09:21:10PM +0100, Emilio Pozuelo Monfort wrote:
> Michael Biebl wrote:
> > Maybe i missinterpreted your conclusion, but this what I get in one of my
> > packages:
> > desktop-mimetype-without-update-call /usr/share/applications/...
> >
> > Now that we have triggers, I rea
Emilio Pozuelo Monfort wrote:
> Michael Biebl wrote:
>> Maybe i missinterpreted your conclusion, but this what I get in one of my
>> packages:
>> desktop-mimetype-without-update-call /usr/share/applications/...
>>
>> Now that we have triggers, I really don't see the benefit of adding such a
>> li
On 02/08/2009 04:46 AM, Jörg Sommer wrote:
Hi,
I have the bug report #489917 that complains that Jed can't handle
64‐bit kernel structures. In this special case, the stat() return with
EOVERFLOW Value too large to be stored in data type. Jed was compiled for
a 32‐bit kernel and is run with a 64‐
Le Sun, Feb 08, 2009 at 10:03:09PM +0100, Joey Schulze a écrit :
>
> The data archive will contain huge packages that cannot be distributed
> through the regular archive due to their sheer size. The number of free
> large data packages, such as medical and statistical data sets, and also
> game d
On Mon, 09 Feb 2009, Charles Plessy wrote:
> Le Sun, Feb 08, 2009 at 10:03:09PM +0100, Joey Schulze a écrit :
> >
> > The data archive will contain huge packages that cannot be distributed
> > through the regular archive due to their sheer size. The number of free
> > large data packages, such a
Le Mon, Feb 09, 2009 at 12:57:12AM +0100, Peter Palfrader a écrit :
>
> The data.debian.org thing is actually Joerg's proposal, he first raised
> it at http://lists.debian.org/debian-devel/2008/05/msg00970.html last
> year.
Hi Peter,
thanks for the pointer.
I think that I will keep on exploring
On Sun, 2009-02-08 at 10:46 +, Jörg Sommer wrote:
> Hi,
>
> I have the bug report #489917 that complains that Jed can't handle
> 64‐bit kernel structures. In this special case, the stat() return with
> EOVERFLOW Value too large to be stored in data type. Jed was compiled for
> a 32‐bit kernel
On Sun, Feb 8, 2009 at 7:13 PM, Charles Plessy wrote:
> Le Mon, Feb 09, 2009 at 12:57:12AM +0100, Peter Palfrader a écrit :
>>
>> The data.debian.org thing is actually Joerg's proposal, he first raised
>> it at http://lists.debian.org/debian-devel/2008/05/msg00970.html last
>> year.
>
> Hi Peter,
Michael Biebl writes:
> Russ Allbery wrote:
>> Okay, that matches my reasoning. I'll remove that tag in the next
>> version of Lintian. Thank you very much!
> Maybe i missinterpreted your conclusion, but this what I get in one of
> my packages:
> desktop-mimetype-without-update-call /usr/sha
Le Sun, Feb 08, 2009 at 07:22:10PM -0600, Lukasz Szybalski a écrit :
>
> Is there a capability of creating a mirror that would use torrent technology?
>
> If you have these .deb packages that are big (could you list few, with
> their sizes), I was under the assumption that having torrent mirror
>
On Mon, Feb 9, 2009 at 2:19 PM, Ben Hutchings wrote:
> If jed can deal with files that large, sure. But if it expects to be
> able to load the entire file into memory - as most text editors do -
> stat() will be only the first of its problems.
Old vi was able to work with files larger than avail
Hi,
This is a heads up for a major change in kernel-package, the
tool to create user packaged kernel images and headers; which will
make the make-kpkg script far less error prone, and far more
deterministic.
a. Every invocation of kernel-package will remove ./debian directory,
21 matches
Mail list logo
