-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/15/2012 02:25 AM, Arno Töll wrote:
> /srv can't be used either as no path hierarchy is specified for
> /srv (e.g. think of /srv/www) and we really do not want to serve
> the entire /srv hierarchy as a document root either.
packages should have a
Adam Borowski writes:
> On Sat, Apr 14, 2012 at 11:22:06AM +0200, Jakub Wilk wrote:
>> >GLR means "Generalized Left-to-right Rightmost deviation parser"
>> >or maybe "Generalized LR parser". EBNF is the Extended BackusâNaur
>> >Form. Acronyms like these - i.e. LL, LL(k), SLR, LALR - are pretty
>
"Bernhard R. Link" writes:
> For the grammer I personally would prefer it expanded, though I
> think it is more understandable as "EBNF (Extended Backus-Naur Form)
> Grammar" than the other way around.
I agree -- in reinforces the fact that these are well-known terms
which are often known by thei
Arno Töll writes:
> Unless I'm missing something there is no better location for HTTP
> documents mentioned within the FHS. Note /srv can't be used either as no
> path hierarchy is specified for /srv (e.g. think of /srv/www) and we
> really do not want to serve the entire /srv hierarchy as a docu
On Sat, Apr 14, 2012 at 08:25:10PM +0200, Svante Signell wrote:
> As the title says, are there plans to use eglibc 2.14 for wheezy??
> It has been out for some time now.
No. 2.14 was a dud release with many quality issues, and everyone else has
skipped it over in favor of 2.15.
--
Steve Langase
Hello,
(please keep replies limited to -devel; I'd just like to point relevant
maintainers to this thread)
I'd like to discuss a change related to the default document root for
HTTP servers in Debian. On behalf of the Apache maintainers I consider
this change a worthwhile idea, but we would like t
Greetings,
This message is an automated, unofficial publication of vote results.
Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary
This email is just a convenience for the impatient.
I remain, gentle folks,
Your humble servant,
De
Goswin von Brederlow wrote:
> 3) Aborting the upgrade because dependency boot ordering fails will be a
> major issue for users. You already mentioned 2 issues and on my system
> at home I get an error about a dependency loop. Dependency based boot
> doesn't seem to be universally working enough yet
Hi,
Thanks for your interest.
Le 14/04/12 22:30, Roger Leigh a écrit :
>> * Package name: svipc
>> * URL : https://github.com/frigaut/yorick-svipc/
>
> Given the rather generic package name, and the fact that
> upstream is already using yorick-svipc, wouldn't it be
> better to co
[Please don't CC me on messages to debian-devel.]
Petr Baudis schrieb am 14.04.2012 16:51:
> Hi!
>
> It appears that the last release of wine easily available in Debian
> is from 2009, quite a surprising state for a high-profile project like
> that. Kai Wasserbäch appears to be very kindly p
Hi!
Neil Williams writes:
> unstable
> gets priority as far as the buildd network is concerned.
While that's true, a sample package (priority optional) I've uploaded
to experimental today has been building on half the debian architectures
in less than half an hour and now, after 7h is only mis
On Sat, 14 Apr 2012 21:49:06 +0200
Svante Signell wrote:
> On Sat, 2012-04-14 at 21:40 +0200, Martin Bagge / brother wrote:
> > On Sat, 14 Apr 2012, Svante Signell wrote:
> >
> > > It seems
> > > like many DMs package new releases/fixes bugs closer to the release than
> > > attending to that now
On Sat, Apr 14, 2012 at 10:16:53PM +0200, Thibaut Paumard wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Thibaut Paumard
>
> * Package name: svipc
> * URL : https://github.com/frigaut/yorick-svipc/
Given the rather generic package name, and the fact that
upstream is already
Package: wnpp
Severity: wishlist
Owner: Thibaut Paumard
* Package name: svipc
Version : 0.9
Upstream Author : Matthieu Bec
* URL : https://github.com/frigaut/yorick-svipc/
* License : GPL-3
Programming Lang: C, Yorick, Python
Description : System V Inte
On Sat, 2012-04-14 at 21:40 +0200, Martin Bagge / brother wrote:
> On Sat, 14 Apr 2012, Svante Signell wrote:
>
> > It seems
> > like many DMs package new releases/fixes bugs closer to the release than
> > attending to that now. Of course it is a time/resource issue, but
> > anyway. Why not packag
On Sat, Apr 14, 2012 at 4:36 PM, Neil Williams wrote:
> On Sat, 14 Apr 2012 20:36:13 +0200
> Svante Signell wrote:
>> Doing that will make the
>> release of wheezy much smoother than trying to fix things in the last
>> minute (and risk that the packages gets excluded from wheezy??)
>
> Definitely
On Sat, 14 Apr 2012, Svante Signell wrote:
It seems
like many DMs package new releases/fixes bugs closer to the release than
attending to that now. Of course it is a time/resource issue, but
anyway. Why not package pre-releases in experimental, to squeeze bugs
out before the new upstream release
On Sat, 14 Apr 2012 20:36:13 +0200
Svante Signell wrote:
> A question about packaging of some upstream (pre-)releases. It seems
> like many DMs package new releases/fixes bugs closer to the release than
> attending to that now.
... which makes life harder for everyone, so let's not do that this
Hi,
A question about packaging of some upstream (pre-)releases. It seems
like many DMs package new releases/fixes bugs closer to the release than
attending to that now. Of course it is a time/resource issue, but
anyway. Why not package pre-releases in experimental, to squeeze bugs
out before the n
Le samedi 14 avril 2012 20:37:14, Svante Signell a écrit :
> On Sat, 2012-04-14 at 20:27 +0200, Cyril Brulebois wrote:
> > Svante Signell (14/04/2012):
> > > As the title says, are there plans to use eglibc 2.14 for wheezy??
> > > It has been out for some time now.
> >
> > Again, ask the maintain
On Sat, 2012-04-14 at 20:27 +0200, Cyril Brulebois wrote:
> Svante Signell (14/04/2012):
> > As the title says, are there plans to use eglibc 2.14 for wheezy??
> > It has been out for some time now.
>
> Again, ask the maintainers. Not dd@.
OK, I will, where?
--
To UNSUBSCRIBE, email to debi
Svante Signell (14/04/2012):
> As the title says, are there plans to use eglibc 2.14 for wheezy??
> It has been out for some time now.
Again, ask the maintainers. Not dd@.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Hi,
As the title says, are there plans to use eglibc 2.14 for wheezy??
It has been out for some time now.
Thanks!
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/133
On Sat, Apr 14, 2012 at 05:56:58PM +0200, Adam Borowski wrote:
> It's not even about unstable releases of wine, we're multiple major stable
> releases past as well:
>
> Upstream has:
> * devel 1.5.2
> * stable1.4
>
> Debian has:
> * unstable 1.0.1-3.5
> * experimental 1.1.24
2012-04-14 16:51, Petr Baudis skrev:
I know that there is also an effort by Ove Kåven to bring wine
up-to-date with some nice extras (thanks for that too!), but it seems
to be quite slow-paced (the last status update I have found was from
Sep 2011), so perhaps it would be beneficial to have wo
On Sat, Apr 14, 2012 at 04:51:56PM +0200, Petr Baudis wrote:
> Hi!
>
> It appears that the last release of wine easily available in Debian
> is from 2009, quite a surprising state for a high-profile project like
> that. Kai Wasserbäch appears to be very kindly providing wine-unstable
> packag
Hi!
It appears that the last release of wine easily available in Debian
is from 2009, quite a surprising state for a high-profile project like
that. Kai Wasserbäch appears to be very kindly providing wine-unstable
packages for Debian at
http://dev.carbon-project.org/debian/wine-unsta
Package: wnpp
Severity: wishlist
Owner: Federico Ceratto
* Package name: logging-tree
Version : 1.1
Upstream Author : Brandon Rhodes
* URL : http://rhodesmill.org/brandon/2012/logging_tree/
* License : BSD
Programming Lang: Python
Description : introsp
* Markus Wanner [120414 13:32]:
> On 04/14/2012 11:22 AM, Jakub Wilk wrote:
> > Sure, they are also much more common than GLR. And if you are "just"
> > interested in parsing and not a computer scientists, there's a chance
> > you've never heard about any of them.
>
> Based on two votes for extend
Hi,
On 04/14/2012 02:12 PM, Tollef Fog Heen wrote:
> I've written parsers (using bison, though) and can't recall having heard
> the term GLR parser before. Maybe I'm unique in that respect, but I
> doubt it.
Note that bison also supports building GLR parsers. That's a somewhat
recent addition, I
On Sat, 2012-04-14 at 15:09 +0300, Andrew Shadura wrote:
> During my university studies I had a course dedicated to compilers
> theory, but while I knew (and still know) the meaning of all those
> abbreviations I rarely tried to spell them out in full, but rather was
> always using their abbreviate
On 04/14/2012 01:12 PM, Adam Borowski wrote:
> I can't really imagine someone writing a parser using such tools without
> having heard these acronyms first, though. And I'd risk saying they are
> actually more widely known than their expansions.
Yeah, that's why I think the acronyms must be inclu
]] Adam Borowski
> I can't really imagine someone writing a parser using such tools without
> having heard these acronyms first, though. And I'd risk saying they are
> actually more widely known than their expansions.
I've written parsers (using bison, though) and can't recall having heard
the
Hello,
On Sat, 14 Apr 2012 13:12:48 +0200
Adam Borowski wrote:
> I can't really imagine someone writing a parser using such tools
> without having heard these acronyms first, though. And I'd risk
> saying they are actually more widely known than their expansions.
During my university studies I
On Sat, Apr 14, 2012 at 11:22:06AM +0200, Jakub Wilk wrote:
> * Markus Wanner , 2012-04-14, 10:45:
> >>I would like to suggest to explicit the "GLR", "RPF", and
> >>perhaps "EBNF" acronyms in the long description.
> >
> >GLR means "Generalized Left-to-right Rightmost deviation parser"
> >or maybe "
Hi,
On 04/14/2012 11:22 AM, Jakub Wilk wrote:
> Sure, they are also much more common than GLR. And if you are "just"
> interested in parsing and not a computer scientists, there's a chance
> you've never heard about any of them.
Based on two votes for extending the acronyms, I propose to change t
On Sat, 2012-04-14 at 17:21 +0800, Paul Wise wrote:
> Might be best to both at once (using X-Debbugs-CC)?
That's fine if the upstream author is sufficiently aware of Debian
processes, but if not then the ITP template is rather an impersonal way
to make contact.
Despite licences, it's polite to st
* Markus Wanner , 2012-04-14, 10:45:
I would like to suggest to explicit the "GLR", "RPF", and perhaps
"EBNF" acronyms in the long description.
Thanks for your suggestions.
GLR means "Generalized Left-to-right Rightmost deviation parser" or
maybe "Generalized LR parser". EBNF is the Extended
On Sat, Apr 14, 2012 at 4:13 PM, Barak A. Pearlmutter wrote:
> People embarking on packaging a bit of software are also supposed to
> contact the upstream author. When one contacts the upstream author
> and they respond quickly and say they'd love to have the software
> packaged and they don't kn
Dear Charles,
On 04/14/2012 05:37 AM, Charles Plessy wrote:
> I would like to suggest to explicit the "GLR", "RPF", and perhaps "EBNF"
> acronyms in the long description.
Thanks for your suggestions.
GLR means "Generalized Left-to-right Rightmost deviation parser" or
maybe "Generalized LR parser
People embarking on packaging a bit of software are also supposed to
contact the upstream author. When one contacts the upstream author
and they respond quickly and say they'd love to have the software
packaged and they don't know of anyone else doing so, an ITP can seem
(depending on the particul
41 matches
Mail list logo
