Zitat von Christian Perrier :
Quoting Cyril Brulebois (k...@debian.org):
4) http://article.gmane.org/gmane.comp.video.blender.devel/19895
Patch to add support for system-wide FTGL. I kind of get flamed for
thinking about using something else than what blender provides. And
who cares about sha
Christian Perrier writes:
> Just drop that blender thing and announce this loudly enough,
> preferrably by coordinating with other distro maintainers. That will
> eventually trigger a fork from people who have a more collaborative
> way of thinking.
This coordination would probably best be done
Hi,
2009/8/1 Leinier Cruz Salfran :
> I disagree with you on this point .. where is success? in a civilized
> discussion on the proposal and the exchange of ideas .. if we discover
> that there is a problem why we will not publish this list, for example,
> although it is obvious that this is a pro
Quoting Cyril Brulebois (k...@debian.org):
> 4) http://article.gmane.org/gmane.comp.video.blender.devel/19895
>
> Patch to add support for system-wide FTGL. I kind of get flamed for
> thinking about using something else than what blender provides. And
> who cares about shared libraries anyway, th
Rob Browning writes:
> Rob Browning writes:
>> Daniel Moerner writes:
>>
>>> Thanks for packaging this, I think you mean:
>>>
>>> http://alioth.debian.org/~rlb/tmp/emacs23/
>>>
>>> Daniel
>>
>> Yes, and thanks.
>
> I've just uploaded 23.1+1-2 which fixes some significant problems with
> 23.1+1-1
Rob Browning writes:
> Daniel Moerner writes:
>
>> Thanks for packaging this, I think you mean:
>>
>> http://alioth.debian.org/~rlb/tmp/emacs23/
>>
>> Daniel
>
> Yes, and thanks.
I've just uploaded 23.1+1-2 which fixes some significant problems with
23.1+1-1.
Thanks
--
Rob Browning
rlb @defau
On Thu, Jul 30, 2009 at 02:00:18PM +0200, Sven Joachim wrote:
> On 2009-07-29 22:12 +0200, Aurelien Jarno wrote:
>
> > On Wed, Jul 29, 2009 at 04:10:27PM +0200, Aurelien Jarno wrote:
> >> In short it looks like a Pre-Depends is overkill, and that a Depends is
> >> enough. I'll upload a new versio
On Sun, Aug 02, 2009 at 08:11:57PM +, Philipp Kern wrote:
> On 2009-08-02, Vincent Danjean wrote:
> > Unpacking a source package is not needed during an upgrade. However, it
> > occurs before
> > a build.
> >
> > So, I understand the question of Charles as "do we want that stable dpkg be
> >
On 2009-08-02, Vincent Danjean wrote:
> Unpacking a source package is not needed during an upgrade. However, it
> occurs before
> a build.
>
> So, I understand the question of Charles as "do we want that stable dpkg be
> able to
> unpack all packages from testing ?". I have no strong opinion for
Emilio Pozuelo Monfort wrote:
> Charles Plessy wrote:
>> I see that .bzip2 and .lzma are also supported compression methods for the
>> 3.0
>> (native) format as well as for the binary packages. But I do not think it
>> would
>> be useful to add zip to this list. It seems to me that the only thing
On Sun, Aug 02, 2009 at 01:46:17PM +0200, Paul Wise wrote:
> On Sun, Aug 2, 2009 at 11:59 AM, Stefano Zacchiroli wrote:
>
> > I'm eager for more details, in particular:
>
> In addition:
>
> I seem to remember that some arch:all packages can only be built on
> some architectures due to being fir
(I hope a single reply will also address Paul's and Christian's
questions.)
Maximiliano Curia (02/08/2009):
> Hola Cyril Brulebois!
Hola! (KiBi or Cyril would be sufficient. ;))
> Given the points you listed before, its understandable if you prefer
> to dedicate your time to any other activity
On Thu, 30 Jul 2009, Petter Reinholdtsen wrote:
> [Matthias Klose]
> >> Right. This seem to be a problem that need to be solved by the
> >> compiler, and not by initscripts. Reassigning to gcc.
> >
> > this has nothing to do with the compiler, which is built for a fixed
> > arch/tune setting.
>
Raphael Hertzog writes:
> On Sun, 02 Aug 2009, Charles Plessy wrote:
>> But actually, among the programs that are not distributed upstream in a
>> tar.gz format, we in the Debian Med team have as many zip cases as
>> bzip2. Do you think that it would be possible to support zip format
>> (i.e. .zi
thanks both of you frans and daniel
i must to get involved with reportbug
El dom, 02-08-2009 a las 08:59 +0200, Frans Pop escribió:
> Leinier Cruz Salfran wrote:
> > The following packages have unmet dependencies:
> > aptitude: Depends: libapt-pkg-libc6.9-6-4.7 but it is not installable
> > Depe
Package: wnpp
Severity: wishlist
Owner: Yann Lejeun
* Package name: httpry
Version : 0.1.5
Upstream Author : Jason Bittel
* URL : http://dumpsterventures.com/jason/httpry/
* License : GPL
Programming Lang: C
Description : HTTP logging and information r
On Sun, Aug 02, 2009 at 03:53:48PM +0200, Tollef Fog Heen wrote:
> ]] Roger Leigh
>
> | On Sun, Aug 02, 2009 at 08:39:46AM +0200, Tollef Fog Heen wrote:
> | > Anyway, IIRC this is now solved in glibc by sending out the queries in
> | > parallel and returning the first answer you get.
> |
> | OK.
On 2009-08-02, Julien BLACHE wrote:
>> There will be a Build-Arch field or some other way to make sure the
>> arch:all packages can be built reliably.
> How will this work wrt non-Linux ports?
>
> If you declare Build-Arch: i386, and that means the package should be
> built only from Linux/i386, t
Julien BLACHE wrote:
> Luk Claes wrote:
>
> Hi,
>
>> There will be a Build-Arch field or some other way to make sure the
>> arch:all packages can be built reliably.
>
> How will this work wrt non-Linux ports?
>
> If you declare Build-Arch: i386, and that means the package should be
> built onl
Luk Claes wrote:
Hi,
> There will be a Build-Arch field or some other way to make sure the
> arch:all packages can be built reliably.
How will this work wrt non-Linux ports?
If you declare Build-Arch: i386, and that means the package should be
built only from Linux/i386, that makes the kfreebs
Package: wnpp
Severity: wishlist
Owner: Vincent Duvert
* Package name: slimevolley
Version : 2.4.1
Upstream Author : Vincent Duvert
* URL : http://slime.tuxfamily.org/
* License : GPL
Programming Lang: C
Description : Unrealistic 2D volleyball simulati
Package: wnpp
Severity: wishlist
Owner: Patrick McEvoy
* Package name: libcastledynamicproxy2.1-cli
Version : 2.1.0
Upstream Author : Castle Project
* URL : http://www.castleproject.org
* License : ASL
Programming Lang: C#
Description : Castle DynamicP
Hola Cyril Brulebois!
El 01/08/2009 a las 22:40 escribiste:
> So: what should I do? I'm thinking about orphaning the package as a
> first step, and if nobody takes care of it as much as it is needed,
> just remove it from the distribution. Packaging would still be
> available in a git repository,
]] Roger Leigh
| On Sun, Aug 02, 2009 at 08:39:46AM +0200, Tollef Fog Heen wrote:
| > ]] Roger Leigh
| >
| > | Having working local networking is important. We wouldn't consider
| > | broken IPv4 loopback acceptable, and broken IPv6 loopback is just as
| > | bad.
| >
| > Sure, having it worki
On Sun, Aug 02, 2009 at 08:39:46AM +0200, Tollef Fog Heen wrote:
> ]] Roger Leigh
>
> | Having working local networking is important. We wouldn't consider
> | broken IPv4 loopback acceptable, and broken IPv6 loopback is just as
> | bad.
>
> Sure, having it working is important. Is it more impo
On 2009-08-02, Tollef Fog Heen wrote:
>| Not only do you have the local loopback, you also have link-local
>| addresses which you can legitimately use. Does zeroconf support
>| these? Fundamentally breaking IPv6 for these use cases to work around
>| broken routing hardware is IMO a step too far.
Charles Plessy wrote:
> I see that .bzip2 and .lzma are also supported compression methods for the 3.0
> (native) format as well as for the binary packages. But I do not think it
> would
> be useful to add zip to this list. It seems to me that the only thing needed
> is
> the capacity to unpack t
Daniel Baumann wrote:
> Stefano Zacchiroli wrote:
>> - which auto-builder will rebuild arch:all packages?
>
> especially because this will break packages with 'faked' arch:all binary
> packages, such as e.g. syslinux where syslinux-common has to be build on
> i386.
This will be solved by an extra
retitile 479397 O: gutenprint -- printer drivers for CUPS
thanks
Hi,
I sent out a mail over a year ago looking for a new maintainer for the
gutenprint Debian packaging. At the time, I put up an RFA (#479397).
I'm now orphaning the package, and will only give it minimal attention.
I no longer ha
Paul Wise wrote:
> On Sun, Aug 2, 2009 at 11:59 AM, Stefano Zacchiroli wrote:
>
>> I'm eager for more details, in particular:
>
> In addition:
>
> I seem to remember that some arch:all packages can only be built on
> some architectures due to being firmware for specific CPUs or similar.
> Will
Paul Wise wrote:
> I seem to remember that some arch:all packages can only be built on
> some architectures due to being firmware for specific CPUs or similar.
> Will there be a Build-Arch field or a way to override discarding
> uploaded .debs?
An option to override the discard would also be usefu
On Sun Aug 02 09:26, Sandro Tosi wrote:
> > All I ask for is that you understand that you are about the change the
> > relavant semantics of something security relevant, and act accordingly.
>
> What? all I'm trying to do is say "hey man, if you need to open a url,
> do it with x-o as you've done
Stefano Zacchiroli wrote:
> - which auto-builder will rebuild arch:all packages?
especially because this will break packages with 'faked' arch:all binary
packages, such as e.g. syslinux where syslinux-common has to be build on
i386.
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562
On Sun, Aug 2, 2009 at 11:59 AM, Stefano Zacchiroli wrote:
> I'm eager for more details, in particular:
In addition:
I seem to remember that some arch:all packages can only be built on
some architectures due to being firmware for specific CPUs or similar.
Will there be a Build-Arch field or a w
I think tying such information to a source or binary package is a bad
idea since it changes independently of the package. I have similar
issues with the Homepage field and to a lesser extent, watch files.
Do you think that apt needs to have access to this information?
The Packages/Sources files a
Le Sun, Aug 02, 2009 at 11:03:11AM +0200, Raphael Hertzog a écrit :
> On Sun, 02 Aug 2009, Charles Plessy wrote:
About zip support:
> > But actually, among the programs that are not distributed upstream in a
> > tar.gz
> > format, we in the Debian Med team have as many zip cases as bzip2. Do you
On Sun, Aug 2, 2009 at 11:59:44 +0200, Stefano Zacchiroli wrote:
> - as a by product, would this enable binNMUs for arch:all packages?
>
Pretty sure it won't, since many packages assume that .dsc version and
_all.deb version are the same. You'd have to solve that somehow.
Cheers,
Julien
--
Stefano Zacchiroli wrote:
> - do we have an estimate of whether architectures for which we often
> upload compiled packages (amd64/i386) have enough buildd power to
> cope with the load increase?
That, and buildd admin resources for log processing/signing.
JB.
--
Julien BLACHE - Debian &
On Thu, Jul 30, 2009 at 07:28:42PM +0200, Meike Reichle wrote:
> * Discard and rebuild of binary packages uploaded by maintainers,
>leaving only packages build in a controlled environment
Hear hear \o/, wonderful news!
I'm eager for more details, in particular:
- which auto-builder will r
Quoting Cyril Brulebois (k...@debian.org):
> So: what should I do? I'm thinking about orphaning the package as a
> first step, and if nobody takes care of it as much as it is needed,
> just remove it from the distribution. Packaging would still be
> available in a git repository, so if someone som
Dear all,
In the Debian Med and Science teams, we are looking for efficient ways to
document slow-changing metadata relevant to our packages, in particular:
- Bibliographic information: which article to cite when a software is used
in a published scientific work. This can be summarised by a d
Hi,
sorry for the late reply, we were celebrating my wife's birthday at
the seaside until yesterday late in the evenign.
On Fri, Jul 31, 2009 at 17:53 +0100, Steve Kemp wrote:
> On Fri Jul 31, 2009 at 18:47:58 +0200, Siggy Brentrup wrote:
>
> > Who wrote debmirror? Without installing I can't fi
On Fri, Jul 31, 2009 at 12:36:16PM +0200, Emilio Pozuelo Monfort wrote:
> Do you think that limitation is enough to change from one ddeb per source
> package? Should we maybe allow any number of ddebs, and only build one ddeb in
> the common case? Or allow both one ddeb per source package and one p
On Sun, 02 Aug 2009, Charles Plessy wrote:
> But actually, among the programs that are not distributed upstream in a tar.gz
> format, we in the Debian Med team have as many zip cases as bzip2. Do you
> think
> that it would be possible to support zip format (i.e. .zip, .jar and .xpi
> extensions)
On 2009-08-02 10:38 +0200, Florian Weimer wrote:
> * Sven Joachim:
>>
>> I haven't tried emacs23 yet, but on recent emacs-snapshot packages I did
>> not experience much of a slowdown compared to emacs22. There is often a
>> delay when Emacs has to display characters that cannot be represented
>>
* Sven Joachim:
>> Has anybody else experienced the FTBFS related to the removal of
>> dir.old?
>
> Not me (building in pbuilder).
My sid pbuilder is currently somewhat hosed (due to lack of current
aptitude on amd64). 8-/ I will re-check when it's fixed.
>> It also seems to me that the Truetype
On 2009-08-02 09:58 +0200, Florian Weimer wrote:
> * Rob Browning:
>
>> I've uploaded the first emacs23 packages (23.1+1-1) to unstable. Please
>> file bugs as appropriate.
>
> Has anybody else experienced the FTBFS related to the removal of
> dir.old?
Not me (building in pbuilder).
> It also s
* Rob Browning:
> I've uploaded the first emacs23 packages (23.1+1-1) to unstable. Please
> file bugs as appropriate.
Has anybody else experienced the FTBFS related to the removal of
dir.old?
It also seems to me that the Truetype-capable redisplay code is much,
much slower, especially during sc
Hi,
I think we make clear our opinions, like they were clear on IRC; but
the reason I started this thread is to have *others* opinions.
On Sat, Aug 1, 2009 at 21:12, Bernhard R.
Link wrote:
> * Sandro Tosi [090801 20:22]:
>> x-o is just a glue around other too to try to identify the best
>> candi
Le Thu, Jul 30, 2009 at 04:55:16PM +0200, Raphael Hertzog a écrit :
>
> I updated the wiki page listing the status of this project:
> http://wiki.debian.org/Projects/DebSrc3.0
Bonjour Raphaël,
first of all, thank you for making things progress for the support of a
next-generation source format
50 matches
Mail list logo
