Bug#668870: RFH: golang

[Ondřej Surý]

Package: wnpp
Severity: normal

Hi,

I am looking for co-maintainers (DMs are welcome).  I don't use Go
myself, so the prospective co-maintaner should be a person who is
involved in Go more than I am.

Ondrej



-- 
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/20120415082727.10641.4109.reportbug@localhost6.localdomain6

Re: The future of non-dependency-based boot

[James Cloos]

Three notes:

Manually choosing the order remains a reasonable choice for many
servers.  The upstream dependencies are not always sufficiently detailed
and edits to the init files can be lost when upgrading.  Such servers
generally start only a few services and hand-tuning the order is easy
and obvious.  They also typically restart less often than once per year.

Systems which have had various packaged added and removed can retain
legacy init scripts which prevent conversion to the new setup even where
it is not unwanted.  I have one long-time server on which apt-get upgrade
displays a full (96x66) page dialog filled with init script which block
the automated switch to dependency-based boot order.

On a server which did update to dep-based I see that there are serveral
S files in the default run level which shouldn't be there.  They had
been removed but reappeared.  (Just because something is installed
doesn't mean one wants it always to run.)

-JimC
-- 
James Cloos  OpenPGP: 1024D/ED7DAEA6


-- 
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/m3hawlwf3v@carbon.jhcloos.org

Re: The future of non-dependency-based boot

[Petter Reinholdtsen]

[James Cloos]
> Manually choosing the order remains a reasonable choice for many
> servers.  The upstream dependencies are not always sufficiently detailed
> and edits to the init files can be lost when upgrading.

Your assumptions are wrong.  You do not have to edit the init.d files
themselves to override their dependencies, and risk them going away
during upgrades.  I created the possibility for the system
administrator to insert overrides in /etc/insserv/overrides/ for just
this use case.
-- 
Happy hacking
Petter Reinholdtsen


-- 
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/2flbomtibjh@login2.uio.no

Re: Results for Debian Project Leader 2012 Election

[Philipp Kern]

On Sun, Apr 15, 2012 at 12:00:55AM +, devo...@vote.debian.org wrote:
> The winners are:
>Option 3 "Stefano Zacchiroli"

By a large margin, too.  Congrats! \o/

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: Changing the default document root for HTTP server

[Marco d'Itri]

On Apr 15, Daniel Baumann  wrote:

> packages should have a debconf question for the document root,
No, because this would require making every package significantly more 
complex. Not just because of asking the question, but the configuration 
files would not be conffiles anymore.
And it would be a pointless exercise, since for most people either the 
name does not really matter or they need to change it anyway to manage 
virtual hosts.

I think /var/www/ is OK.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: [pkg-lighttpd] Changing the default document root for HTTP server

[Olaf van der Spek]

On Sun, Apr 15, 2012 at 2:25 AM, Arno Töll  wrote:
> 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?

I'd use ht instead of html. Not every ht file is a html file.

We should consider vhosts as well. Lighttpd defaults to
/srv//htdocs (for mod simple vhost). ht instead of htdocs might
be better.

We could use /srv/default/ht as the default doc root.
FHS: /srv : Data for services provided by this system. The methodology
used to name subdirectories of /srv is unspecified as there is
currently no consensus on how this should be done.

Please CC me
-- 
Olaf


--
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/caa7u3hpvn6ztpjguuyubzwyklfgw2x1oboj_y3gdkamx5u7...@mail.gmail.com

Re: [pkg-lighttpd] Changing the default document root for HTTP server

[Paul Wise]

On Sun, Apr 15, 2012 at 6:29 PM, Olaf van der Spek wrote:

> We should consider vhosts as well. Lighttpd defaults to
> /srv//htdocs (for mod simple vhost). ht instead of htdocs might
> be better.
>
> We could use /srv/default/ht as the default doc root.
> FHS: /srv : Data for services provided by this system. The methodology
> used to name subdirectories of /srv is unspecified as there is
> currently no consensus on how this should be done.

/srv is solely the domain of the sysadmin, packages cannot rely on any
particular layout not specified by the sysadmin (via debconf etc).

-- 
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/CAKTje6GYrr-MRcbcD2=ryf5ZPm1noYDZHkg96iWA=9-p1nu...@mail.gmail.com

Re: Changing the default document root for HTTP server

[Thomas Goirand]

On 04/15/2012 08:25 AM, Arno Töll wrote:
> 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?
>   
I support this.

Thomas


--
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/4f8aabd9.4000...@debian.org

Re: [pkg-lighttpd] Changing the default document root for HTTP server

[Thomas Goirand]

On 04/15/2012 06:29 PM, Olaf van der Spek wrote:
> On Sun, Apr 15, 2012 at 2:25 AM, Arno Töll  wrote:
>   
>> 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?
>> 
> I'd use ht instead of html. Not every ht file is a html file.
>
> We should consider vhosts as well. Lighttpd defaults to
> /srv//htdocs (for mod simple vhost). ht instead of htdocs might
> be better.
>
> We could use /srv/default/ht as the default doc root.
> FHS: /srv : Data for services provided by this system. The methodology
> used to name subdirectories of /srv is unspecified as there is
> currently no consensus on how this should be done.
>   
Moving to anywhere outside of /var is a bad idea because this might
fill up space on the rootfs, while /var is traditionally (at least on
servers) a separate partition. As you wrote above, the content inside
/srv isn't specified, thus there could be collisions, while /var/www is
already used in many distros for the web server.

Thomas


--
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/4f8aad2c.9000...@debian.org

Re: wine-unstable in Debian

[Petr Baudis]

  Hi!

On Sat, Apr 14, 2012 at 11:23:47PM +0200, Kai Wasserbäch wrote:
> I'm going to be brief:
>  (short version of
> my motivation behind those packages).

  I have read that post originally, it explained well why you created
the packages but not why they are not simply merged into Debian.

  As I understand it now, you are neutral about their inclusion, i.e.
there is no technical reason the packages couldn't be uploaded to Debian
until Ove's version is ready, but you aren't interested in investing
your personal time in this effort?

Johan Grönqvist wrote:
> At  you will find more recent status
> updates, and you will also see that progress is being made.

  Thanks, I have read through that bug report.

  I am rather dazzled that while there is working source package
of wine-1.5 ready, other people are working on gradually packaging
wine-1.1.x releases; I don't quite follow the reasoning behind that
except Ove's mention of "QA resons".

  Also, it seems the current direction of that discussion is still to
make the package "perfect" first and upload it then rather than vice
versa, which seems unfortunate to me, but I'm still glad that there is
a recent surge of activity!

  Best,

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/20120415111828.gc6...@machine.or.cz

Re: [pkg-lighttpd] Changing the default document root for HTTP server

[Olaf van der Spek]

On Sun, Apr 15, 2012 at 1:12 PM, Thomas Goirand  wrote:
>> I'd use ht instead of html. Not every ht file is a html file.
>>
>> We should consider vhosts as well. Lighttpd defaults to
>> /srv//htdocs (for mod simple vhost). ht instead of htdocs might
>> be better.
>>
>> We could use /srv/default/ht as the default doc root.
>> FHS: /srv : Data for services provided by this system. The methodology
>> used to name subdirectories of /srv is unspecified as there is
>> currently no consensus on how this should be done.
>>
> Moving to anywhere outside of /var is a bad idea because this might
> fill up space on the rootfs, while /var is traditionally (at least on
> servers) a separate partition.

That's what you get with silly partitioning. :p
FHS says /srv contains site-specific data which is served by this system.
Besides, it's the admin that's going to populate the space, so if it's
not enough, he can change the location.


-- 
Olaf


-- 
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/caa7u3hofqplsqhhm7uqjwqzja57pqsmo91veupbmeudk2a6...@mail.gmail.com

config files, ucf and dpkg (was: Re: The future of non-dependency-based boot)

[Vincent Danjean]

Le 15/04/2012 11:34, Petter Reinholdtsen a écrit :
> 
> [James Cloos]
>> Manually choosing the order remains a reasonable choice for many
>> servers.  The upstream dependencies are not always sufficiently detailed
>> and edits to the init files can be lost when upgrading.
> 
> Your assumptions are wrong.  You do not have to edit the init.d files
> themselves to override their dependencies, and risk them going away
> during upgrades.  I created the possibility for the system
> administrator to insert overrides in /etc/insserv/overrides/ for just
> this use case.

And then, if the maintainer fix some problem in dependencies,
you will not notice there is two conflicting or complementary
modifications at the same place.
  I'm aware of this possibility but I always modify the init.d files
in order to be notified (and to be able to check my modifications are
still right) when the init.d files are modified during an upgrade.

  However, I would be more than pleased if maintainers use ucf with
the --three-way flags (often modifications are done in unrelated
places and a three-way merge would work perfectly). One "problem"
here is that, with ucf, there are no config files any more but only
configuration files (ie dpkg -S will not find them, dpkg does not
remove them automatically on purge, ...)
  So I would be even more pleased if the three-way merge possibility
would be offered by dpkg itself. Dpkg would have to store a copy of
the original config file elsewhere in this case, but for me cost of
the disk space is largely outperformed by the feature.

  Regards,
Vincent
-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/4f8abac1.30...@free.fr

Re: Changing the default document root for HTTP server

[Thomas Goirand]

On 04/15/2012 07:21 PM, Olaf van der Spek wrote:
> That's what you get with silly partitioning. :p

I'm not sure if this is supposed to be a joke, but if it is, it's not
really funny (because it's been re-occurring so many times).

Each time there's a change proposed that will affect people with a
*decent* partitioning, there's always someone that will tell it's a
*silly* way to partitions. When saying that, you're missing the point.
The point is to avoid breaking working setups, the fact that it is a
silly way to do partitioning (in your eyes) is totally irrelevant to the
fact you're going to break an admin's (perfectly valid IMO) choice.

Have a wider 3 foot view. Many people are doing what you call
"silly", and don't want their rootfs to be filled to death with user
data, so they use separate partitions. Typically, /usr, /tmp, /var,
/home, and also probably /var/log and /var/lib. If it's not YOUR choice,
it might be the one of someone else. Breaking things just because it's
not *your* preference, and you feel it looks better this way, isn't a
smart move. Please try to refrain yourself from pushing Debian to break
our user's systems.

More over, that's *not* the proposed change, which is to move from
/var/www to /var/www/html. Could we please stick this thread to this
*only* and not loose our time with "silly" proposals, which the
maintainers of apache didn't talk about?

> FHS says /srv contains site-specific data which is served by this system.
> Besides, it's the admin that's going to populate the space, so if it's
> not enough, he can change the location.

1/ If it's site-specific, it means we shouldn't touch it, just like it
doesn't make sense to put things in /usr/local

2/ If your proposal is to move things in /srv because anyway, it's going
to be changed by the admin, then it's "silly" ...

Cheers,

Thomas


-- 
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/4f8ac2ed.9050...@debian.org

Re: wine-unstable in Debian

[Andrey Rahmatullin]

On Sun, Apr 15, 2012 at 01:18:28PM +0200, Petr Baudis wrote:
>   I am rather dazzled that while there is working source package
> of wine-1.5 ready, other people are working on gradually packaging
> wine-1.1.x releases; 
I'm surprised that not everyone involved is such dazzled.

>   Also, it seems the current direction of that discussion is still to
> make the package "perfect" first and upload it then rather than vice
> versa,
It seems to *me*, that the current direction is not just to make the
package perfect, but to package tons of obsolete versions first. The
combined result is that unfortunate but familiar situation when a package
is theoretically perfect but doesn't exist in the distribution.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: wine-unstable in Debian

[Ben Hutchings]

On Sun, 2012-04-15 at 19:32 +0600, Andrey Rahmatullin wrote:
> On Sun, Apr 15, 2012 at 01:18:28PM +0200, Petr Baudis wrote:
> >   I am rather dazzled that while there is working source package
> > of wine-1.5 ready, other people are working on gradually packaging
> > wine-1.1.x releases; 
> I'm surprised that not everyone involved is such dazzled.
> 
> >   Also, it seems the current direction of that discussion is still to
> > make the package "perfect" first and upload it then rather than vice
> > versa,
> It seems to *me*, that the current direction is not just to make the
> package perfect, but to package tons of obsolete versions first. The
> combined result is that unfortunate but familiar situation when a package
> is theoretically perfect but doesn't exist in the distribution.

I think we are doing our users and upstream a disservice when we fail to
package new stable releases for a long time, particularly in the run-up
to a freeze.

If WINE 1.0 or 1.1 works better for some applications, perhaps it should
be kept around as an alternate version.  But please let's have a recent
upstream stable release as default (i.e. what 'apt-get install wine'
will install).

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.


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

Re: [pkg-lighttpd] Changing the default document root for HTTP server

[Tollef Fog Heen]

]] Olaf van der Spek 

> FHS says /srv contains site-specific data which is served by this system.
> Besides, it's the admin that's going to populate the space, so if it's
> not enough, he can change the location.

You're going to end up with some packages creating directories in /srv
with the wrong name (and it'll be the wrong name whatever you choose,
since reasonable people have different ideas about what the right
structure should be) and maintainers who'll then put that into debconf
at priority low who'll then respond with «but you can run debconf at
priority low and get asked about it» and we'll get huge flame wars.
It's just not a good idea.

I'd rather we just either added an excemption for /var/www or moved it
to /var/lib/www as Russ suggested.

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

Re: Changing the default document root for HTTP server

[Arno Töll]

On 15.04.2012 04:23, Russ Allbery wrote:
> 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).

I do not think /var/lib would be any better than /var/www in respect to
FHS compatibility. Note, /var/lib is defined as directory which holds
"state information pertaining to an application or the system. State
information is data that programs modify while they run, and that
pertains to one specific host. Users must never need to modify files in
/var/lib to configure a package's operation" [1].

This does not really qualify for documents served through HTTP which are
neither vital or relevant to the web server itself, nor would it add any
state to a running web server. On the other hand that may well be data
which is to be modified (or even supplied) by the user. Likewise I find
the data directory used by MySQL for example (/var/lib/mysql) wrong -
but I personally do not intend to address that, too.

I have no strong opinion on any particular directory, but I do not see
why /var/lib/www would be better than /var/www/. Please let me know if I
missed something here.



[1]
http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION

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



signature.asc
Description: OpenPGP digital signature

Re: [pkg-lighttpd] Changing the default document root for HTTP server

[Arno Töll]

Hi,

On 15.04.2012 12:29, Olaf van der Spek wrote:
> I'd use ht instead of html. Not every ht file is a html file.

I have no strong opinion on the actual name, as long as it is another
subdirectory. We could equally use /var/www/default, /var/www/htdocs or
whatever we feel like.

I only proposed /var/www/html to minimize diversity among distributions
as that's what Red Hat/Fedora uses. As a quick survey, this is what
other operating systems and distributions use as default document root:

Upstream: /usr/local/apache2/htdocs
Red Hat / CentOS: /var/www/html
Mandriva:   /var/www/html
NetBSD:  /usr/pkg/share/httpd/htdocs
FreeBSD: /usr/local/www/apache22/data
OpenBSD: /var/apache2/htdocs/
Solaris: /var/apache2/htdocs
Slackware:  /svr/httpd/htdocs
Gentoo: /var/www/localhost/htdocs


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



signature.asc
Description: OpenPGP digital signature

Bug#668917: ITP: libio-lcdproc-perl -- Perl extension to connect to a LCD display through lcdproc

[Dominique Dumont]

Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: 
debian-devel@lists.debian.org,debian-p...@lists.debian.org,jcmul...@gmail.com

* Package name: libio-lcdproc-perl
  Version : 0.037
  Upstream Author : Juan C. Muller 
* URL : http://search.cpan.org/dist/IO-LCDproc/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl extension to connect to a LCD display through lcdproc

Lcdproc is a client/server suite including drivers for all kinds of
nifty LCD displays. IO::LCDproc module provides a Perl interface to
lcdproc.

Dominique


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

Re: wine-unstable in Debian

[Chris Knadle]

On Sunday, April 15, 2012 09:32:53, Andrey Rahmatullin wrote:
> On Sun, Apr 15, 2012 at 01:18:28PM +0200, Petr Baudis wrote:
> >   I am rather dazzled that while there is working source package
> > 
> > of wine-1.5 ready, other people are working on gradually packaging
> > wine-1.1.x releases;
> 
> I'm surprised that not everyone involved is such dazzled.

I'm similarly confused.  I'm not sure I correctly understand the reasoning, 
but I'll summarize what I've gathered having read the bug report.

In the bug report Zack pointed to [#585409] the bottom line seems to be:

A) packaging every release up to 1.2 for quality-assurance reasons

   I'm not sure I know what "for quality-assurance reasons" means here.

   My best guess is that it would allow someone to do some kind of custom
   Git checkout of the source package to get and build an older verison of
   the package in order to support certain Windows software that won't work
   as well when run in newever versions of WINE.

   I don't know how many people would use this feature of the source
   package, but I suspect it would be rare, so I'm dubious if this effort
   is worth holding up all newer WINE versions in order to have it.  I'm
   also wondering if WINE 1.5 could be packaged and committed to the Git
   repo, and if WINE 1.1.x versions could be committed later, rather than
   having to hold up everything newer in order to package WINE 1.1.x
   versions first.
   Since commits are based on the parent, isn't this something Git can do?

B) issues with both multiarch support and backporting

C) Current WINE maintainers are either MIA or time overload elsewhere.  
Volunteers trying to help who have made additional 1.1.x packages are stuck 
waiting because they do not have access to the pkg-wine git repo.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us


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

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

[Jon Dowland]

I'd lke to see the ITP be MUST but the ITP template be SHOULD.


-- 
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/20120415221713.GA24051@debian

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

[Markus Wanner]

Dear Debian developers,

On 04/15/2012 04:15 AM, Miles Bader wrote:
> 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.

Thank you all for your feedback on the long description. I've completed
packaging now and sent out an RFS here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668966

Please go after sponsoring as eagerly as you discussed the long
description. ;-)

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/4f8bb6ab.4000...@bluegap.ch