Re: Changing the default document root for HTTP server

[Daniel Baumann]

-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 debconf question for the document root,
defaulting to /srv/, and create the directory where necessary (see
'/srv/tftp' handling in tftpd-hpa).

- -- 
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.baumann/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+KYGgACgkQ+C5cwEsrK56CnwCfZX1U0Fgep6y7SCQNXWdvkzBv
hrsAoLFedwX7UccQ4nNJc8g0Ku7Lsd5y
=jLd9
-END PGP SIGNATURE-


-- 
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/4f8a6068.4040...@progress-technologies.net

Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator

[Miles Bader]

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
>> >common when talking about parsers.
>> 
>> 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.
>
> 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.

In my experience, "EBNF" and "LL"/"SLR"/"LALR" are widely known (they
are "classic compiler terms"), for the type of person who might be
interested in parser generators, but "GLR" isn't.

So I'd provide an expansion (maybe in parentheses) for the latter only.

Moreover, one wants to err on the side of being too verbose, at least
in the long description; of course one should provide both the acronym
and the expansion in case the person only recognizes the former
[e.g. "XYZ (Xxx Yyyy Zzzz)"].

-Miles

-- 
Acquaintance, n. A person whom we know well enough to borrow from, but not
well enough to lend to.


--
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/87wr5hhha2@catnip.gol.com

Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator

[Miles Bader]

"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 their acronym.

-miles

-- 
P.S.  All information contained in the above letter is false,
  for reasons of military security.


-- 
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/87r4vphh6a@catnip.gol.com

Re: Changing the default document root for HTTP server

[Russ Allbery]

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 document root
> either.

I'd like us to consider switching to /var/lib/www for FHS compliance.
This does have the significant drawback of breaking backward compatibility
to at least some extent, but it's FHS-compliant (or at least is as good as
we're going to get for a default).  One option for dealing with the
backward compatibility issue is to create a one-time symlink from /var/www
to /var/lib/www (and move /var/www if it already exists) during upgrade
but not on new installs and then just leave it.

-- 
Russ Allbery (r...@debian.org)   


--
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/87d379enra@windlord.stanford.edu

Re: eglibc 2.14 for wheezy?

[Steve Langasek]

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 Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Changing the default document root for HTTP server

[Arno Töll]

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 to reach consensus
among developers in general and HTTP server maintainers in particular
before pushing any change.

Currently, all web servers (as far as I am aware) are being installed
with the default document root pointing to /var/www. Let me point out
this change is _not_ going to affect existing web application packages -
these are already installed to /usr/share/application (or similar) and
are typically configured as an overlay alias into the web server (e.g.
by using a global /packagename alias or  whatever the preferred
methodology for a particular web server is). Thus this change does not
have any effects on existing packages in Debian (with one exception, see
below).

First, consider the status quo:

* Local site administrators tend to put virtual hosts into
/var/www/sitename/htdocs or something similar. Nonetheless the default
configuration for several web servers allows access to /var/www
directly. Thus, an attacker could potentially access sensitive data by
connecting to the default virtual host instead of the configured site
unless in some scenarios unless the default configuration was
modified/disabled. Consider reading #340947 for more background.

* Using /var/www as document root violates the File Hierarchy Standard.
/var is suggested to be used for "spool directories and files,
administrative and logging data, and transient and temporary files".

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 document root
either.

* No package should be using /var/www directly (as per policy §11.5).
However, there is one counter-example: dspam (binary package:
dspam-webfrontend). They rely on suexec which in turn requires a
compiled-in physical path which is not configurable. See #555129 for
more background.


You can see, there is no ideal solution. Thus, I'd like to do a rather
conservative change to switch the default document root for HTTP servers
from /var/www to /var/www/html. This would not need any changes to the
policy and it would not solve the FHS discrepancy. However, it would
come over the remaining problems:

* Users can put sensitive data into /var/www, /var/www/whatever.
* Packages can put their configuration into /var/www/packagename if
/usr/share/packagename is not possible with a slight decreased risk of
unwanted side-effects.
* Compatibility to programs relying on suexec remains intact.
* Average users do not need to disable/edit the default configuration
and they do not need to worry about sensitive information disclosed by
accidentally matching last-resort catch-all name based hosts anymore.

Thus, to summarize once again: I'd like to change the default directory
served by web servers from /var/www to /var/www/html along with
remaining web servers in Debian.

Comments?


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Results for Debian Project Leader 2012 Election

[devotee]

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,
Devotee (on behalf of Debian Project Secretary)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Starting results calculation at Sun Apr 15 00:00:52 2012

Option 1 "Wouter Verhelst"
Option 2 "Gergely Nagy"
Option 3 "Stefano Zacchiroli"
Option 4 "None Of The Above"

In the following table, tally[row x][col y] represents the votes that
option x received over option y.

  Option
  1 2 3 4 
===   ===   ===   === 
Option 1  20337   310 
Option 2 97  34   281 
Option 3347   354 385 
Option 4 607812   



Looking at row 2, column 1, Gergely Nagy
received 97 votes over Wouter Verhelst

Looking at row 1, column 2, Wouter Verhelst
received 203 votes over Gergely Nagy.

Option 1 Reached quorum: 310 > 46.184412955022
Option 2 Reached quorum: 281 > 46.184412955022
Option 3 Reached quorum: 385 > 46.184412955022


Option 1 passes Majority.   5.167 (310/60) >= 1
Option 2 passes Majority.   3.603 (281/78) >= 1
Option 3 passes Majority.  32.083 (385/12) >= 1


  Option 1 defeats Option 2 by ( 203 -   97) =  106 votes.
  Option 3 defeats Option 1 by ( 347 -   37) =  310 votes.
  Option 1 defeats Option 4 by ( 310 -   60) =  250 votes.
  Option 3 defeats Option 2 by ( 354 -   34) =  320 votes.
  Option 2 defeats Option 4 by ( 281 -   78) =  203 votes.
  Option 3 defeats Option 4 by ( 385 -   12) =  373 votes.


The Schwartz Set contains:
 Option 3 "Stefano Zacchiroli"



-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 Option 3 "Stefano Zacchiroli"

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-- 
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
  ranksep=0.25;
 "Wouter Verhelst\n5.17" [ style="filled" , fontname="Helvetica", fontsize=10  
];
 "Wouter Verhelst\n5.17" -> "Gergely Nagy\n3.60" [ label="106" ];
 "Wouter Verhelst\n5.17" -> "None Of The Above" [ label="250" ];
 "Gergely Nagy\n3.60" [ style="filled" , fontname="Helvetica", fontsize=10  ];
 "Gergely Nagy\n3.60" -> "None Of The Above" [ label="203" ];
 "Stefano Zacchiroli\n32.08" [ style="filled" , color="powderblue", shape=egg, 
fontcolor="NavyBlue", fontname="Helvetica", fontsize=10  ];
 "Stefano Zacchiroli\n32.08" -> "Wouter Verhelst\n5.17" [ label="310" ];
 "Stefano Zacchiroli\n32.08" -> "Gergely Nagy\n3.60" [ label="320" ];
 "Stefano Zacchiroli\n32.08" -> "None Of The Above" [ label="373" ];
 "None Of The Above" [ style="filled" , shape=diamond, fontcolor="Red", 
fontname="Helvetica", fontsize=10  ];
}


pgpLfHq7JFpec.pgp
Description: PGP signature

Re: The future of non-dependency-based boot

[Raphael Geissert]

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.

If it is caused by a package: file a bug, otherwise fix it.

> As a side note I have a use case at work where static order seems to be
> needed. We build boot images for network boot of clusters. During boot
> additional files can be copied from NFS into the system including boot
> scripts. When using dependency based boot order the numbers for boot
> scripts change a lot depending on the boot image (include support for
> lustre, ha, slurm, ... and each gets a different order). That makes it
> impossible (or at least a lot harder) to copy in the same generic boot
> scripts from NFS into different images since the name needs to be
> different for each case. The boot scripts would have to be reordered
> during boot.

Sounds very much like you want to configure those other boot scripts in a 
different runlevel to then switch to it. If you do it all by hand you need 
to: copy them, create the symlinks, run insserv, telinit.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/jmcsoc$hoa$1...@dough.gmane.org

Re: Bug#668841: ITP: svipc -- System V InterProcess Communication for Python/Yorick

[Thibaut Paumard]

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 continue using yorick-svipc as the package name?

Sure, I can do that.

> Are the POSIX equivalents not supported already in Yorick and
> Python? 

There's no implemented alternative for yorick, and I can't find
alternative packages for python in Debian. I may have missed something
though.

> While yorick-svipc is undoubtedly useful, it's also
> quite dated; the standard POSIX equivalents to the old SysV
> should really be preferred.

>From what I've read, the benefit of the POSIX IPC over the SysV
implementation is not that tremendous.

> FWIW, http://pypi.python.org/pypi/posix_ipc/0.8.1

Best regards, Thibaut.


-- 
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/4f89efe8.7020...@free.fr

Re: wine-unstable in Debian

[Kai Wasserbäch]

[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 providing wine-unstable
> packages for Debian at
> 
>   http://dev.carbon-project.org/debian/wine-unstable/
> 
>   I would like to ask if you have considered contributing these packages
> to Debian sid, or if there is some major hurdle preventing that action?

I'm going to be brief:
 (short version of
my motivation behind those packages).

Kind regards,
Kai Wasserbäch



-- 

E-Mail: cu...@debian.org
IRC: Curan
Jabber: dri...@debianforum.de
URL: http://wiki.debian.org/C%C3%B9ran
GnuPG: 0xE1DE59D2  0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2



signature.asc
Description: OpenPGP digital signature

Re: Packaging of new upstream (pre-)releases until wheezy

[Christoph Egger]

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 missing mips* and
arm* (even hurd is there) so I'd say this is no issue at all.

Regards

Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer


-- 
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/87y5pykqkx@hepworth.siccegge.de

Re: Packaging of new upstream (pre-)releases until wheezy

[Neil Williams]

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. 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 comes out?
> > 
> > And what makes you assume that?
> 
> I could give several examples of pre-releases and new upstream releases
> that are not yet packaged, that will probably enter into wheezy. But you
> never know what plan the DMs have for their packages, do you?

(That has happened before with other freezes but hopefully we've learnt
not to get into that mess again.)

You can ask individual maintainers / maintainer teams ... file wishlist
bugs for the new version so that everyone can talk about the merits of
uploading or delaying until after the release due to unwarranted
disruptive changes in the new version...

> In order
> not to point at specific DMs I defer to mention which packages I'm
> thinking of.

Bearing in mind your previous question about eglibc, it is probably
worth saying now that a new upstream version of such an important
package is not something which should be rushed merely to get it into
Wheezy. That's a decision for the maintainers in discussion with the
release team.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpGBafHpSQtn.pgp
Description: PGP signature

Re: Bug#668841: ITP: svipc -- System V InterProcess Communication for Python/Yorick

[Roger Leigh]

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 using yorick-svipc, wouldn't it be
better to continue using yorick-svipc as the package name?

> The 3 packages expose SysV IPC functionalities to the corresponding
> interpreter:
> 
>  - shared memory;
>  - semaphores;
>  - message queues.

Are the POSIX equivalents not supported already in Yorick and
Python?  While yorick-svipc is undoubtedly useful, it's also
quite dated; the standard POSIX equivalents to the old SysV
should really be preferred.

FWIW, http://pypi.python.org/pypi/posix_ipc/0.8.1


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120414203044.gf...@codelibre.net

Bug#668841: ITP: svipc -- System V InterProcess Communication for Python/Yorick

[Thibaut Paumard]

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 InterProcess Communication for Python/Yorick

This souce package will build the following binary packages:

yorick-svipc
python-svipc
python3-svipc

The 3 packages expose SysV IPC functionalities to the corresponding
interpreter:

 - shared memory;
 - semaphores;
 - message queues.

This package is used (for instance by yorick-yao, already packaged) for
parallel (mutliprocess) computing and for mixed yorick/python applications.

Regards, Thibaut.



-- 
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/20120414201653.1780.69870.reportbug@localhost.localdomain

Re: Packaging of new upstream (pre-)releases until wheezy

[Svante Signell]

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 package pre-releases in experimental, to squeeze bugs
> > out before the new upstream release comes out?
> 
> And what makes you assume that?

I could give several examples of pre-releases and new upstream releases
that are not yet packaged, that will probably enter into wheezy. But you
never know what plan the DMs have for their packages, do you? In order
not to point at specific DMs I defer to mention which packages I'm
thinking of.


-- 
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/1334432946.2822.21.camel@x60

Re: Packaging of new upstream (pre-)releases until wheezy

[Fernando Lemos]

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. Whether the new version goes into experimental or into
> unstable, the sooner the uploads are made the better - with the
> requirement that if the changes involve a SONAME change or other
> disruptions, talk to the release team (and wait for a response) before
> uploading.

Well, since now we have a roughly "scheduled" freeze, I can see why a
maintainer might want to postpone the packaging of a new upstream
release (or even skip it) in order to avoid unnecessary work and/or
multiple transitions.

Although I agree that "package early" should be a strong
recommendation, it's entirely up to the maintainers to decide what's
best. I believe the release team can help a maintainer to decide it
too, not entirely sure if that's a common procedure.

Regards,


-- 
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/canvyna8+qo6rteej4nyvudax9krz+-w7q6mnsxxaqvr_tho...@mail.gmail.com

Re: Packaging of new upstream (pre-)releases until wheezy

[Martin Bagge / brother]

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 comes out?


And what makes you assume that?


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??)


Given that the current state is to freeze the archive in about two 
months[1] the "finalizing" part should already be ongoing as we speak.


[1] http://lists.debian.org/debian-devel-announce/2012/01/msg9.html
"A reminder to everyone that the freeze is due in June."

--
/brother
http://martin.bagge.nu
Anyone who makes love to Bruce Schneier discovers a 0-day flaw in a crypto 
protocol the next day.


--
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/alpine.deb.2.00.1204142136070.32...@salyut.bsnet.se

Re: Packaging of new upstream (pre-)releases until wheezy

[Neil Williams]

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
time ...

> 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 comes out?

It is a very good use of experimental but there just aren't that many
people running systems with packages from experimental and unstable
gets priority as far as the buildd network is concerned.

If there are concerns that the pre-release isn't ready, push the
release into experimental and ask people to test it.

> 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. Whether the new version goes into experimental or into
unstable, the sooner the uploads are made the better - with the
requirement that if the changes involve a SONAME change or other
disruptions, talk to the release team (and wait for a response) before
uploading.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpG3GwG4aWvK.pgp
Description: PGP signature

Packaging of new upstream (pre-)releases until wheezy

[Svante Signell]

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 new upstream release comes out? 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??)

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/1334428573.2822.10.camel@x60

Re: eglibc 2.14 for wheezy?

[Thomas Preud'homme]

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 maintainers. Not dd@.
> 
> OK, I will, where?

egl...@packages.debian.org


signature.asc
Description: This is a digitally signed message part.

Re: eglibc 2.14 for wheezy?

[Svante Signell]

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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1334428634.2822.11.camel@x60

Re: eglibc 2.14 for wheezy?

[Cyril Brulebois]

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

eglibc 2.14 for wheezy?

[Svante Signell]

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/1334427910.2822.2.camel@x60

Re: wine-unstable in Debian

[Stefano Zacchiroli]

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-2
> 
> If you're totally out of time, Ubuntu has 1.4, perhaps taking their work
> could be good enough.

See #585409 for some background on that and related topics.

Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: wine-unstable in Debian

[Johan Grönqvist]

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 working solution
in Debian now and perfect solution as soon as it's ready? :-)



At  you will find more recent status 
updates, and you will also see that progress is being made.


Regards

Johan


--
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/jmc925$hqu$1...@dough.gmane.org

Re: wine-unstable in Debian

[Adam Borowski]

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
> packages for Debian at
> 
>   http://dev.carbon-project.org/debian/wine-unstable/

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-2

If you're totally out of time, Ubuntu has 1.4, perhaps taking their work
could be good enough.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


signature.asc
Description: Digital signature

wine-unstable in Debian

[Petr Baudis]

  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-unstable/

  I would like to ask if you have considered contributing these packages
to Debian sid, or if there is some major hurdle preventing that action?

  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 working solution
in Debian now and perfect solution as soon as it's ready? :-)

  Can anyone else help with the process?

  Best regards,

Petr "Pasky" Baudis


-- 
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/20120414145156.gz6...@machine.or.cz

Bug#668809: ITP: logging-tree -- introspect and display the logging tree

[Federico Ceratto]

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 : introspect and display the logging tree

A debugging tool for inspecting the hierarchy of loggers in Python. 
It is useful for troubleshooting applications where the logging levels seem 
inconsistent across modules and libraries. 
The loggers and their configuration is printed in a ascii tree. 



-- 
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/20120414145035.6827.30895.reportbug@ehm

Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator

[Bernhard R. Link]

* 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 extending the acronyms, I propose to change the
> long description as follows:
>
>  DParser is a scannerless, generalized left-to-right, rightmost
>  deviation (GLR) parser generator based on the Tomita algorithm. It is
>  self-hosted and very easy to use. Grammars are written in a natural
>  style of extended Backus-Naur form (EBNF) and regular expressions and
>  support both speculative and final actions.
>
> I'm not a native speaker, so please feel free to comment on spelling,
> grammar, comma or other errors.

I'm not sure that is that much more understandable for people not
knowing the concepts or for people trying to understand what this
package does and why some other admin installed it (or why a user
requests its installation).

Let's take a look at start of bison's description:
 Bison is a general-purpose parser generator that converts a
 grammar description for an LALR(1) context-free grammar into a C
 program to parse that grammar.

That sentence also describes what a parser generator is (so even
someone not so deep into computer science knows what this package
is about), while still containing the details and not being much longer.

I personally cannot take much more out of "generalized
left-to-right, rightmost deviation (GLR) parser generator" than
out of "GLR parser", I'd need to look it up anyway, so "GLR parser
generator" is quite well in my eyes.

For the grammer I personally would prefer it expanded, though
I think it is more understandable as "EBNF (extended Backus-Naur form)
Grammer" than the other way around.

Other questions I ask myself when looking at the description:

What is "based on the Tomita algorithm" about? Wikipedia tells me
GLR parser generators are based on work of Tomita, so is that a
description of "GLR parser" or is it a somehow important implementation
detail that this is based on the original and not some reinvention
or totally different algorithm one would also call GLR parser?
Would that information be important for anyone to decide if they
want to install that package or not?

What is "a natural style of EBNF" supposed to mean? Are there any
unnatural styles of EBNF? Does it mean I can write something I
would be able to identify as EBNF in contrast to other parser
generators? As EBNF is already about forms of expression grammars,
what is meant here that not having that could still be called EBNF?
That might be only my ignorance, so my question: "Does this
'natural style of' give anyone a information they would want when
determining if installing or uninstalling this package?"

What is "scannerless"? After considering that "does not contain a
scanner" does not make much sense I guess it means I do not need
something like flex run first to translate the input into tokens?
Perhaps that can also expressed more generally understandable.

If all my guesses above are right, that would result in something
like:

 DParser is a scannerless GLR parser generator that converts
 a grammar given in EBNF (extended Backus-Naur form) and
 regular expressions into  to parse
 that grammer without needing an extra scanner to tokenize the
 input.

(With perhaps "GLR" being replaced with "GLR (generalized left-to-right,
rightmost deviation)" and perhaps "to tokenize the input" removed).


-- 
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/20120414133220.gb2...@client.brlink.eu

Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator

[Markus Wanner]

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, IIRC.

http://www.gnu.org/software/bison/manual/html_node/GLR-Parsers.html#GLR-Parsers

Regard

Markus Wanner


-- 
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/4f89746b.6020...@bluegap.ch

Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator

[Moray Allan]

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 abbreviated forms.

The new proposed description doesn't remove the abbreviations, so I
don't see any problem here.  It seems useful to me to include both
abbreviations and spelt-out versions, (a) as users might search for
either, and (b) it's good if descriptions are understandable enough for
users looking for something else to know when this is *not* the package
they wanted, so even if all target users know related jargon/an
abbreviation it's good to explain what it is.

-- 
Moray


--
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/1334406771.16637.20.ca...@claudin.sermisy.org

Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator

[Markus Wanner]

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 included in the long
description as well. But it cannot hurt to provide the expansion. At
best, it might even increase the number of people who actually know what
the acronyms stand for (Although I - for example - am not sure I'm able
to remember the GLR one...).  ;-)

Regards

Markus Wanner


-- 
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/4f896a8d.3020...@bluegap.ch

Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator

[Tollef Fog Heen]

]] 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 term GLR parser before.  Maybe I'm unique in that respect, but I
doubt it.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87vcl2ecmh@qurzaw.varnish-software.com

Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator

[Andrew Shadura]

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 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 abbreviated forms.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator

[Adam Borowski]

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 "Generalized LR parser". EBNF is the Extended Backus–Naur
> >Form. Acronyms like these - i.e. LL, LL(k), SLR, LALR - are pretty
> >common when talking about parsers.
> 
> 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.

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.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
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/20120414111248.ga17...@angband.pl

Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator

[Markus Wanner]

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 the
long description as follows:

 DParser is a scannerless, generalized left-to-right, rightmost
 deviation (GLR) parser generator based on the Tomita algorithm. It is
 self-hosted and very easy to use. Grammars are written in a natural
 style of extended Backus-Naur form (EBNF) and regular expressions and
 support both speculative and final actions.

I'm not a native speaker, so please feel free to comment on spelling,
grammar, comma or other errors.

Regards

Markus


-- 
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/4f895c10.4050...@bluegap.ch

Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)

[Moray Allan]

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 start by asking the author if they're
happy about this version of the software being packaged at this time.
Often there are also a few specific questions to politely raise (e.g. if
they would mind using a configurable prefix rather than hard-coding 
/opt/arbitraryname/ on every second line, or if the files in the warez/
subdirectory are really under the overall GPL licence).  It's more
friendly to ask these directly to the upstream maintainer (this can be
CCd to the ITP), rather than in a CC of a message somewhere else.  

(I'm slightly torn between our usual openness and the benefits of CCing
all such questions to the ITP, versus the potential unfairness of
incriminating upstream by picky licensing questions -- in those cases it
may be better to only CC the ITP once a positive solution is found.)

-- 
Moray


--
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/1334398351.16637.16.ca...@claudin.sermisy.org

Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator

[Jakub Wilk]

* 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 Backus–Naur Form. 
Acronyms like these - i.e. LL, LL(k), SLR, LALR - are pretty common 
when talking about parsers.


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.


--
Jakub Wilk


--
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/20120414092206.ga6...@jwilk.net

Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)

[Paul Wise]

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 know of anyone else doing so, an ITP can seem
> (depending on the particulars of the situation) a bit superfluous.
>
> If people are going to do only one of (a) heads-up to upstream author,
> and (b) file an ITP, I personally would rather see them do (a).  Of
> course, doing both would typically be best.

Might be best to both at once (using X-Debbugs-CC)?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
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/caktje6g41h_ra16ps-kd0e1fah9myqd_cyx+pj-bmfltww1...@mail.gmail.com

Re: Bug#668556: ITP: dparser -- a scannerless GLR parser generator

[Markus Wanner]

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". EBNF is the Extended Backus–Naur Form.
Acronyms like these - i.e. LL, LL(k), SLR, LALR - are pretty common when
talking about parsers.

RPF is actually a typo, I meant to point to the archived Request For
Packaging (RFP) bug in Debian, see here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248589

That last sentence isn't meant to be part of the long description of the
package. I wasn't sure how to make that clear.

Regards

Markus


-- 
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/4f89392d.2060...@bluegap.ch

Re: usefulness of ITPs (Re: mosh ITP not done, just package name taken over)

[Barak A. Pearlmutter]

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 particulars of the situation) a bit superfluous.

If people are going to do only one of (a) heads-up to upstream author,
and (b) file an ITP, I personally would rather see them do (a).  Of
course, doing both would typically be best.

--Barak.
--
Barak A. Pearlmutter
 Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
 http://www.bcl.hamilton.ie/~barak/


-- 
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/E1SIy6b-7u-Cf@port-kdr.hamilton.local