On Thu, 2014-05-15 at 22:49 -0300, Antonio Terceiro wrote:
> On Thu, May 15, 2014 at 08:20:53PM +0100, Ian Campbell wrote:
> > On Thu, 2014-05-15 at 02:10 +0100, Wookey wrote:
> > > Also if anyone has expertise in language porting we'd like to hear
> > > from you. Below is the list of languages we
Package: wnpp
Severity: wishlist
Owner: Dariusz Dwornikowski
* Package name: raceintospace
Version : 1.1
Upstream Author : Michael K McCarty ,
Pace Willisson ,
Krzysztof Kosciuszkiewicz ,
Wil
On Thu, May 15, 2014 at 08:20:53PM +0100, Ian Campbell wrote:
> On Thu, 2014-05-15 at 02:10 +0100, Wookey wrote:
> > Also if anyone has expertise in language porting we'd like to hear
> > from you. Below is the list of languages we believe still need porting to
> > arm64:
>
> Ruby wasn't on the l
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: 589 (new: 21)
Total number of packages offered up for adoption: 135 (new: 0)
Total number of packages reques
Hi,
The mirror.debian.net zone's records have been unmaintained for some time and
the count of queries against the zone is exceedingly low.
The Debian Mirror Team does not need the zone and the Debian System
Administration Team would like to remove this 'special snowflake' delegation
from debian.
On Fri, May 16, 2014 at 01:16:58AM +0100, Steven Chamberlain wrote:
> On 16/05/14 00:00, Luca Filipozzi wrote:
> > I'm guessing the gb.* lookups are mostly you. The au.* lookups are DSA.
> >
> > That leaves somebody looking up nl*. You and he/she might be the last
> > users of this zone.
>
> Wh
Am 15.05.2014 03:10, schrieb Wookey:
> Go (we have gccgo, but not gcgo)
this is not arm64 specific. Debian has a serious problem in that the current Go
maintainers are focused on gc only, which only supports amd64, i386, armhf, and
probably armel.
> Mono
needs porting
> GCL
> CLISP
need porti
Hi,
On 16/05/14 00:00, Luca Filipozzi wrote:
> I'm guessing the gb.* lookups are mostly you. The au.* lookups are DSA.
>
> That leaves somebody looking up nl*. You and he/she might be the last users
> of
> this zone.
Why did you discount the fr., it. and us. queries?
nl.arm. does not seem to
On Thu, May 15, 2014 at 02:10:39AM +0100, Wookey wrote:
> GHCi (ghc is done, but not ghci - is this hard?)
This is hard. You need either an LLVM-based port or a native code
generator, and in either case I think you need some linker support in
GHC. Both of these are serious compiler engineer proj
Le jeudi 15 mai 2014 à 02:10 +0100, Wookey a écrit :
> Also if anyone has expertise in language porting we'd like to hear
> from you. Below is the list of languages we believe still need porting to
> arm64:
> Julia
Note that currently Julia is only available on i386/amd64 (so no
armel/armhf for
On Thu, May 15, 2014 at 12:27:19AM +0100, Steven Chamberlain wrote:
> On 14/05/14 23:34, Luca Filipozzi wrote:
> >> In the last week at least 13 of my own servers/VMs at two sites (each site
> >> has a caching DNS resolver), my desktop and also my laptop from offsite
> >> have been querying this zo
2014-05-15 02:10 Wookey:
The debian-port arm64 rebootstrap is progressing nicely, and we just
passed 4200 source packages built, with another few hundred
pending. There are now 2 buildds running.
In the course of that 344 have failed to build, (see
http://buildd.debian-ports.org/status/architect
On Thu, 2014-05-15 at 18:48 +0100, Ian Jackson wrote:
[...]
> For example, one of the oldest open emacs bugs is my own bug #9741
> from May 1997. It should clearly remain open.
[...]
That is your opinion. Really, it is up to the maintainer(s) whether
they leave a bug open (or tag it 'wontfix') w
On Thu, May 15, 2014 at 07:51:37AM +, Thorsten Glaser wrote:
> > From: Guido =?iso-8859-1?Q?G=FCnther?=
>
> >GTK+3 supports themes
>
> GTK/GNOME people have stated numerous times that they do not want
> them.
There's not Debian people and not Gtk+/GNOME people, this current
thread shows t
Le jeudi 15 mai 2014 à 07:51 +, Thorsten Glaser a écrit :
> > From: Guido =?iso-8859-1?Q?G=FCnther?=
>
> >GTK+3 supports themes
>
> GTK/GNOME people have stated numerous times that they do not want them.
Do you have a quote to back up your claims?
The fact is that themes are supported, a
On Thu, 2014-05-15 at 02:10 +0100, Wookey wrote:
> Also if anyone has expertise in language porting we'd like to hear
> from you. Below is the list of languages we believe still need porting to
> arm64:
Ruby wasn't on the list, is that under control?
Ruby seems to be at the bottom of the build-d
On Thu, May 15, 2014 at 06:33:41PM +0200, Luca Capello wrote:
> ...despite the above, MANY THANKS to all people writing the Release
> Notes (and any other official documentation), which is highly
> important at least for me, as well as a pleasure to read.
Hear hear, strongly and fully ack'd.
(And
Andrei POPESCU writes ("Dealing with emacs21 (and related) bugs [was: Re:
ignoring bugs with no maintainer]"):
> On Jo, 15 mai 14, 13:43:31, Ian Jackson wrote:
> > One of my bugs was involved in this situation and I was one of the
> > people (the person?) who objected. I contacted the maintainer
Jean-Christophe Dubacq writes:
> Completely at random, I tested this one:
> • #128748 [w| | ] [emacs21] emacs21: M-x word-count (from xemacs) is
> missing?
> It happens that this one is solved in emacs24, not in emacs23.
> What should be done: reassign to emacs23 (which obviously will never
On 15/05/2014 17:06, Russ Allbery wrote:
> Andrei POPESCU writes:
>
>> For this concrete case, might I suggest following course of action:
>
>> 1. ping all submitters of emacs21 (and related) bugs to test against
>> recent emacs (at a minimum emacs23 from wheezy) and deal with the bug as
>> ne
+++ Matthias Klose [2014-05-13 14:56 +0200]:
> With gcc-4.9 now available in testing, it is time to prepare for the change of
> the default to 4.9, for a subset of architectures or for all (release)
> architectures. The defaults for the gdc, gccgo, gcj and gnat frontends
> already
> point to 4.9
Hi there!
Nothing related to any init system in Debian, but...
On Tue, 13 May 2014 19:19:54 +0200, Cyril Brulebois wrote:
> Thibaut Paumard (2014-05-13):
>> Le 13/05/2014 17:36, Russ Allbery a écrit :
>> > Right, which I've been arguing for already in this thread. I don't think
>> > we should f
Package: wnpp
Severity: wishlist
Owner: Benjamin Drung
* Package name: flower (binary: python-flower)
Version : 0.6.0+dfsg
Upstream Author : Mher Movsisyan
* URL : https://github.com/mher/flower
* License : BSD
Programming Lang: Python
Description : web
Andrei POPESCU writes:
> For this concrete case, might I suggest following course of action:
> 1. ping all submitters of emacs21 (and related) bugs to test against
> recent emacs (at a minimum emacs23 from wheezy) and deal with the bug as
> needed
> 2. if no response within a reasonable amount
On Jo, 15 mai 14, 13:43:31, Ian Jackson wrote:
> Andrei POPESCU writes ("Re: ignoring bugs with no maintainer (Re: Removal of
> emacs23 from unstable/testing)"):
> > Last time someone (Bcc'd) tried to tackle these (admittedly without
> > contacting the maintainer in advance) the contributor was pr
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: liboptimization-java
Version : 0.1
Upstream Author : Steve Verrill
* URL : http://www1.fpl.fs.fed.us/optimization.html
* License : Public Domain
Programming Lang: Java
Description :
Andrei POPESCU writes ("Re: ignoring bugs with no maintainer (Re: Removal of
emacs23 from unstable/testing)"):
> Last time someone (Bcc'd) tried to tackle these (admittedly without
> contacting the maintainer in advance) the contributor was prevented
> from doing so and was requested to either che
Rob Browning writes ("Re: ignoring bugs with no maintainer (Re: Removal of
emacs23 from unstable/testing)"):
> Don Armstrong writes:
> > The right solution for these (and other bugs which happen when source
> > packages are renamed) is for the bugs to follow the new source package
> > name.
...
>
Thibaut Paumard writes:
> Le 15/05/2014 10:55, Gergely Nagy a écrit :
>> You do realise we have one libc (sure, you can install *additional*
>> ones, but we have one libc the archive is compiled against), we have one
>> package manager (you can, of course, install rpm too, it is packaged!),
>> we
Le 15/05/2014 10:55, Gergely Nagy a écrit :
> You do realise we have one libc (sure, you can install *additional*
> ones, but we have one libc the archive is compiled against), we have one
> package manager (you can, of course, install rpm too, it is packaged!),
> we have one "make" we use to build
On Thu, 2014-05-15 at 10:55 +0200, Gergely Nagy wrote:
> Thorsten Glaser writes:
> > Integration of some components at the cost of disabling the freedom
> > of users to choose a different free component that also does the job,
> > and at the cost of removing some users' use cases: no. That is not
Thorsten Glaser writes:
>>. This
>>> is a perfectly fine job for a derivate or Pure Blend: to provide a
>>> polished system that serves one use case well.
>>
>>Proper integration certainly belongs into Debian or did we become a
>>supermarket:
>
> Proper integration of components: yes. That is the
Hi,
Michael Biebl:
> I can not confirm this behaviour Matthias describes with v204.
>
Sorry, my bad. Turns out that this was not done via the rescue shell.
I was using the root shell which you get on TTY9 (assuming it is enabled,
which it usually isn't for obvious reasons).
Thanks for double-che
> From: Guido =?iso-8859-1?Q?G=FCnther?=
>GTK+3 supports themes
GTK/GNOME people have stated numerous times that they do not want them.
>. This
>> is a perfectly fine job for a derivate or Pure Blend: to provide a
>> polished system that serves one use case well.
>
>Proper integration certain
On Tue, May 13, 2014 at 10:25:52AM -0400, The Wanderer wrote:
> this>
It is indeed much easier to throw mud than to bake bricks.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://list
35 matches
Mail list logo
