Bug#654949: ITP: libgoogle-gson-java -- Converts Java objects into their JSON representation

[Jakub Adam]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: libgoogle-gson-java
Version: 2.1
Upstream Author: Google Inc.
URL: http://code.google.com/p/google-gson/
License: Apache-2.0
Description: Converts Java objects into their JSON representation

 Gson is a Java library that can be used to convert Java Objects into their JSON
 representation. It can also be used to convert a JSON string to an equivalent
 Java object. Gson can work with arbitrary Java objects including pre-existing
 objects that you do not have source-code of.
 .
 Gson Goals
 .
  * Provide simple toJson() and fromJson() methods to convert Java objects to
JSON and vice-versa
  * Allow pre-existing unmodifiable objects to be converted to and from JSON
  * Extensive support of Java Generics
  * Allow custom representations for objects
  * Support arbitrarily complex objects (with deep inheritance hierarchies and
extensive use of generic types).



--
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/4f07aeca.6040...@ktknet.cz

Re: Source package without a binary

[Guillem Jover]

Hi!

On Thu, 2012-01-05 at 18:26:13 +0100, Joachim Breitner wrote:
> Theoretically, there is no interesting binary package produced from this
> source package and it seems that the policy does not explicitly require
> that a source package produces binary packages... but I am certain that
> this is an assumption buried deep within so many parts of our
> infrastructure that it is not a good idea to actually try this.

AFAIK the build daemons will not even try to build a source if their
architecture is not listed on that field in the .dsc file. To generate
this kind of package with an appropriate Architecture field, you
currently have (at least?) two options, both suboptimal:

* Every time you build the source you'd have to remember to override
  the Architecture field on the dpkg-source -b call with -D.
* Add a dummy binary package stanza in debian/control for the only
  purpose of making the Architecture value percolate to the .dsc file
  automatically, taking into account that the rules file has to ignore
  such stanza.

Another issue is how to track that the build succeeded and that it
does not have to be retried, if there's no binary and .changes files,
and as such no installed version on the archive.

> So the logical conclusion is to build a binary package from the source
> that contains nothing (or maybe a log of the test results) and clearly
> states in its description that there is no point in installing this
> binary package.

That's what I did for the last posixtestsuite 1.5.2-4 upload, and
while the “dummy” binary package might seem a bit worthless, it has
some advantages; it keeps the maintainer build log, something the buildd
network does not currently do, and it makes the test results, which in
a way could be considered different to build logs, available in an
easily installable form. The other advantage of not providing a
foo-source binary package is that the natural way of building binary
packages is from source packages not binary ones.

regards,
guillem


-- 
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/20120107014054.ga3...@gaara.hadrons.org

Re: [Long] UEFI support

[Steve Langasek]

On Fri, Jan 06, 2012 at 02:41:41PM +, Tanguy Ortolo wrote:
> Current status
> ==

> This is what I think we have for Debian.

> Installer image
> - ---

> I do not think we have any UEFI-bootable installer images so far.

I don't know if we do or not, but this seems to be a topic for discussing
with the installer team (debian-boot).

> It would be possible to create hybrid BIOS/UEFI bootable images, but
> that will probably be incompatible with hybrid USB/optical images as we
> have them currently. Thanks to the /efi/boot/boot.efi convention,
> it would also be possible to have multiarch images.

> It is also worth noting that an amd64 PC will probably support x64 UEFI
> only, so given that there is probably no UEFI-base x86 PCs, there is no
> point in creating corresponding images.

Your terminology is a bit muddled here.  If you mean "there will be no
32-bit-only systems using UEFI", that's not a safe assumption to make. 
There are still 32-bit-only systems being produced, and the move from BIOS
to UEFI will affect them as well.

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


-- 
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/20120107000815.gc23...@virgil.dodds.net

Re: Removing web server dependencies from web apps

[Daniel Baumann]

On 01/06/2012 02:46 PM, Milan P. Stanic wrote:
> live with the idea that Debian must be usable for everyone in the
> world (which is impossible, IMHO) but that's the life.

at least debian is equally bad for everyone/everything, having almost no
worst cases by itself, already is quite a good thing, isn't it? ;)

-- 
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.baumann/


-- 
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/4f077a76.90...@progress-technologies.net

Re: Removing web server dependencies from web apps

[Daniel Baumann]

On 01/06/2012 11:06 AM, Thomas Goirand wrote:
> That's what I don't get! I think using a remote MySQL is as uncommon as
> a chrooted CGI environment. [...] we should apply the same reasoning to the 
> MySQL
> server. There's no logic at all here.

i beg to differ.

web applications that use mysql (or most dbs for that matter) can access
that db on localhost or on another host with a mechanism from *within*
their own system, e.g. with networking. therefore, mysql is often not a
depends but a recommends of a web application, and that's correct.

web applications need an httpd to get served to their audience, it is
not possible for them to use mechanisms from within the system to make
use of an http installed on another system to serve themselfs (it very
well works the other way round, though, httpd serving a web application
located on another system, but that's not what you were writing about).

in your usecase with sbox, you're using a mechanism from *outside* the
system to bring the web application together with the httpd (by
"aufs-mounting" in the httpd binaries et al).

while it's totally legitimate to challenge existing habits and
traditions to improve debian and make it ready for new and future use
cases, i think the current reality is that such uses cases where a
package gets brought together with it's dependencies not through system
immanent mechanisms but mechanisms outside of it, are a) atypical
minority stuff and b) not worth vast changes for the whole distribution
that would make it significantly inconvenient for everyone else, rather
than to just use edge-case solutions for edge-cases (equivs). that looks
pretty much logical to me.

-- 
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.baumann/


-- 
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/4f0776a0.9000...@progress-technologies.net

Re: Removing web server dependencies from web apps

[Daniel Baumann]

On 01/06/2012 06:43 PM, Thomas Goirand wrote:
 How many of these packages do clever things upon installation like
 setup their own virtual hosts or similar?
   
>>> None, because that's forbidden by the Debian policy.
>>> 
>> Where is that forbidden?
> 
> Sorry, I don't want to spend the time to search and point at it.
> But I'm quite sure of what I'm saying. What packages do, is
> install an Alias directive, but *never* a VirtualHost.

it's not policy incompliant if e.g. php5 would install
/etc/apache2/sites-enabled/whatever containing a virtualhost definition.
the reason why nobody would do that, is, that it's just wrong and
unreasonable to do such a thing (where e.g. aliases and directory
directives are a reasonable thing to do for a web application).

or in other words; you right with your description of the resulting
situation, but the reason is not policy, but common sense.

-- 
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.baumann/


-- 
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/4f0770ce.6000...@progress-technologies.net

Bug#654920: ITP: python-icalendar -- parser/generator of iCalendar files for use with Python.

[Paul Tagliamonte]

Package: wnpp
Severity: wishlist
Owner: Paul Tagliamonte 

* Package name: python-icalendar
  Version : 2.2
  Upstream Author : Rok Garbas 
* URL : http://pypi.python.org/pypi/icalendar
* License : GPL
  Programming Lang: Python
  Description : parser/generator of iCalendar files for use with Python.

Generate or parse iCalendar files according to the RFC 2445 (iCalendar)
specification.
..
This package contains the Python bindings only.



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

Re: Providing a dummy web server package in Debian (Removing web server dependencies from web apps)

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06.01.2012 19:09, Thomas Goirand wrote:
> I don't think this would be an issue for anyone, and I wouldn't see any
> argument against it (I'm sure someone in this list will though... :) ).
> Your thoughts?

The overall benefit over our virtual package system, possibly in
addition to equivs seems flexible enough. Why do we tailor incomplete
special case solutions instead of recommending equivs more popularly?

I say incomplete, because similar use cases exist for different package
groups - e.g. think of mail servers and database servers. Do we really
want dummy packages for each group of alternatives?

On the other hand, we have a perfect solution which apparently only
needs some more propaganda if even developer don't know it.

That said, you're a developer. If you want to maintain such a dummy
package, you could consider uploading it despite of all critics and hope
ftpmaster will accept it.

I would, however, support any effort in finding a consolidated web
application policy regarding dependencies, suggestions, ways to interact
with web servers and such.

- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPB0l2AAoJEMcrUe6dgPNtJ4AP/3EE5wJYBGcSuUinQWDqF6BP
cusFmmsHhB7xnrUxfu6/JdDgBjV81PZ7FCV503X3EXbAUsF2iy9W2O9FFOrhfPi7
WTpLK72SGlkiESelffcNMpERV5f/N+QJnowa9k6PGLzgFpgpShEI+RokTL6IXYu2
XjqJvNPB8BbwXeAK/OR4LfcZeHx2kZNUWlbSxyWdhnDvAQMVX4Ryc7XFrfjYjqw/
nFoYQ7cpS/i9EzJcTk1vXxF4HOP4FHXX23h5/A/RdCQuFPcG3u7E73rG4+D7+/WE
+wt9q/CeEV1OTql09uAaPYOV+RJdI0q5akkEOmF6tHFN9+eaq7vc4aKmazqMd/H6
i560WR/pv7rTeD/azwCajO1zFLnCNStIUIFZPHpQbq5tMU0hxzFrFaFWtaRZS8SR
9eWh9OJbsbLMocg8jkWzCJTLAzdBjzYNyhAFOR1Vntm60mGAYj3yz3Rn2HAJOI7I
lC+3rhnW2e0vTYtKe2DT1j5D9D7fK8RyokY/OMVjLfodguiQIOx7Sxl+vgbFVxBA
TrJiABus7vnWU1nfDd8uA10JZuC6Zh+J9QFSsimXgARv8N3Yk6+JKw9caXKAmJ1G
F6RgPqzoMOMsxt17Ha+emt/9qbVEymqiHKIkgRDVXrRb8HrsCUjx87+f8tgLch5A
eKB2duwWdAPJeHD2YtBL
=5jiK
-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/4f074977.2050...@toell.net

db.debian.org with new layout

[Martin Zobel-Helas]

Hi,

with todays update of userdir-ldap-cgi, i have applied the 'spacefun'
theme from Kalle, we applied to the debian website (www.debian.org) also
to db.debian.org.

Cheers,
Martin
-- 
 Martin Zobel-Helas   | Debian System Administrator
 Debian & GNU/Linux Developer   |   Debian Listmaster
 GPG key http://go.debian.net/B11B627B  | 
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 


-- 
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/20120106185455.gq...@ftbfs.de

Re: Providing a dummy web server package in Debian (Removing web server dependencies from web apps)

[Thomas Goirand]

It seems to be that I wasn't the only one with the issue. Bug #627213
shows how messy things can be.

So, what about Debian providing a dummy package that would provide
httpd, so that it would solve the issue?

It'd be something like this:

Package: dummy-httpd
Provides: httpd, httpd-fastcgi, httpd-wsgi, httpd-scgi, httpd-ajp
Description: dummy web server meta package to prevent installation of a
real server
 In some setup, for some web apps, you don't want to install a web server.
 This package will provide a web server, so that when you install a web
 application, you wont be forced to also install a web server like Apache.
 .
 This is a meta package, aimed at experts who know what they are doing,
 and who wish not to install the provided default web server dependencies
 for web applications.


I don't think this would be an issue for anyone, and I wouldn't see any
argument against it (I'm sure someone in this list will though... :) ).
Your thoughts?

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/4f0738d1.9040...@debian.org

Re: [Long] UEFI support

[Johan Henriksson]

On Fri, Jan 6, 2012 at 6:55 PM, Ben Hutchings  wrote:

> On Fri, Jan 06, 2012 at 02:41:41PM +, Tanguy Ortolo wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Hello all,
> >
> > UEFI (often called EFI, which was the name of its previous version) is a
> > new firmware interface, which is expected to replace the BIOS on new
> > PCs, as at has already done so on Apple PCs. While modern operating
> > system do not rely much on firmware calls for normal operation, the boot
> > loader does.
>
> As I understand it, almost all new PCs for sale today have UEFI and a
> BIOS compatibility layer on top.  So this replacement has already
> happened.
>

I recently set up a linux server and do see a need for linux to boot on
UEFI without relying on BIOS. The reason is the limitations of the size of
the booting harddrive. there are hacks around this (multiple MBRs) but
these would upset for example a dual-booting windows. this also doesn't
chime well when persuading new users to try out linux. so, in my opinion,
debian should be among the first to support UEFI well and to show that
linux can be first rate in hardware support.

one challenge for the installer will be how to support manual partitioning
while making installation of the uefi boot partition easy. if there is none
then debian should suggest to create it, with good default settings.

/Johan


-- 
---
Johan Henriksson
PhD student, Karolinska Institutet
http://mahogny.areta.org  http://www.endrov.net

Re: Removing web server dependencies from web apps

[Thomas Goirand]

On 01/07/2012 12:33 AM, Tollef Fog Heen wrote:
>> On 01/06/2012 04:34 PM, Neil Williams wrote:
>> 
>>> It depends which is more common
>>>   
>> I don't see why we would steer on the direction of the most common
>> thing only. What we want is something that works all the time, no?
>> If we remote the web server dependency, it works all the time.
>> 
> No, it then breaks if you don't install the package by hand.
>   

That's not what my proposal *was* (I already given up) about.
It would break if you don't install the package by hand *AND*
if you have disabled automatic install of Recommends:.

>> Don't you think that someone who can setup a PHP app, also knows
>> that it will need apache, and that apt-get install apache2 is quite an
>> easy thing to do?
>> 
> That argument can be taken ad absurbum quite easily.  Don't you know
> that ssh requires libssl0.9.8g?  Everybody knows that, you should just
> grab it by hand.
>   

You are talking about strict, mandatory, dependencies, for a library that
would anyway never by a problem on your server. That is totally different.

>>> How many of these packages do clever things upon installation like
>>> setup their own virtual hosts or similar?
>>>   
>> None, because that's forbidden by the Debian policy.
>> 
> Where is that forbidden?
>   

Sorry, I don't want to spend the time to search and point at it.
But I'm quite sure of what I'm saying. What packages do, is
install an Alias directive, but *never* a VirtualHost.

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/4f0732b7.2020...@debian.org

Re: [Long] UEFI support

[Ben Hutchings]

On Fri, Jan 06, 2012 at 02:41:41PM +, Tanguy Ortolo wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hello all,
> 
> UEFI (often called EFI, which was the name of its previous version) is a
> new firmware interface, which is expected to replace the BIOS on new
> PCs, as at has already done so on Apple PCs. While modern operating
> system do not rely much on firmware calls for normal operation, the boot
> loader does.

As I understand it, almost all new PCs for sale today have UEFI and a
BIOS compatibility layer on top.  So this replacement has already
happened.

[...]
> In order not to see Debian become uninstallable (meaning, not
> installable unless you are a guru) on most computers, I wonder if UEFI
> support should not even be promoted as a release goal. But anyway, here
> is a basic summary of how it works from a boot procedure point of view,
> and what it means to support it.
[...]

If Debian doesn't yet fully support installation and booting on UEFI
(I haven't bought a new PC in a while so I haven't tried it) then it
should be a very high priority for the maintainers of whichever
packages are involved (installer, boot loaders, kernels).  But release
goals are usually defined for issues that involve a large number of
packages, which is not the case for UEFI support.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20120106175527.gm20...@decadent.org.uk

Re: Removing web server dependencies from web apps

[Tollef Fog Heen]

]] Thomas Goirand 

> On 01/06/2012 04:34 PM, Neil Williams wrote:
> > It depends which is more common
> 
> I don't see why we would steer on the direction of the most common
> thing only. What we want is something that works all the time, no?
> If we remote the web server dependency, it works all the time.

No, it then breaks if you don't install the package by hand.

> Don't you think that someone who can setup a PHP app, also knows
> that it will need apache, and that apt-get install apache2 is quite an
> easy thing to do?

That argument can be taken ad absurbum quite easily.  Don't you know
that ssh requires libssl0.9.8g?  Everybody knows that, you should just
grab it by hand.

> > How many of these packages do clever things upon installation like
> > setup their own virtual hosts or similar?
> 
> None, because that's forbidden by the Debian policy.

Where is that forbidden?

If the problem is the full overhead of apache2, just install mini-httpd
or monkey or similar and then disable them.  They weigh in at a few
hundred k each, so shouldn't be a problem for you.  Or just use equivs
as other people have 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/87mxa0eqoz@qurzaw.varnish-software.com

Bug#654896: ITP: xul-ext-debianbuttons -- Buttons for querying Debian-related pages with Iceweasel/Firefox

[Tanguy Ortolo]

Package: wnpp
Severity: wishlist
Owner: Tanguy Ortolo 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: xul-ext-debianbuttons
  Version : 1.5
  Upstream Author : Damyan Ivanov 
* URL : https://addons.mozilla.org/firefox/addon/debian-buttons/
* License : MIT/X
  Programming Lang: XUL, JavaScript
  Description : Buttons for querying Debian-related pages with 
Iceweasel/Firefox

Debian buttons is an extension that provides three new buttons for quick
access to information about Debian package or bug report on the web
using text from the X11 clipboard.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCgAGBQJPByIMAAoJEOryzVHFAGgZkRUP/3TSvcJf73skxiIwt9iv6tT0
QMgDzAGtcEJSTvJk2a7jFIFolOhb7KQSpUmIhoU5sItCmA4B8LTcAZDox+1BSqjt
/8i+DdSGD8aztWhw6KoPIZBqgn2UlNhvVRVaX3P5ySBeO89x/y1pmhPl6/rPzyCd
K2o8V1WCOCcBjJtTBIoffrH1yJ34k68MeVQoYGtku9LGJwZ8uFA+Nu3KNm+Rkp9t
5/BjMVHFZ/t5RxmXr6FwVJpdBfwRfbiNUU3DL+VjlgLKPUJYmm7IJEZzAnCQ4pE/
KqW2rj2CegLbq5W5wiN3hxgi/WBKLpdxRWFpdQvYB7CamqbTByDA3NKg8kIiU8Lv
IAfCAaJdAeFuZkoxg6iZOEq2tHC/M5uWi9ltlE6So5jqfwDJ/qO6e8aRw5bMM6jU
wBCZOFubYEhHVxH0Sr3Q2HLwHoX0Uaz4Zf2t5YJYG1fK/ukW9FYkb8tTrDiFFvOT
lXspB2411ZTKQ+mpS7fVj/Nw8uOIRYWFQA5nfycJnYSOe4oVXeE/6lueCXMiYbzU
eMtpWP6dWlJSssV1QaUKLAithNtS396ZwtTgJOakL5NSmheBrA4cEHH1926A57Vz
X6KwfhWVD6e2K3ynlwlVJjnNDQtIaZW8j9feo42iizzswSdX32LaXp7L4Q9+p5/t
is6BcN3SU0oUcZ0UoLpq
=c1VK
-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/20120106163220.29427.89481.report...@dick.ortolo.eu

Bug#654892: ITP: libgxps -- GObject based library for handling and rendering XPS documents.

[Savvas Radevic]

Package: wnpp
Severity: wishlist
Owner: Savvas Radevic 


* Package name: libgxps
  Version : 0.2.0
  Upstream Author : Carlos Garcia Campos , Jason Crain 

* URL : http://live.gnome.org/libgxps
* License : LGPL-2+
  Programming Lang: C
  Description : GObject based library for handling and rendering XPS 
documents.

This library is being used by evince to read XPS documents

There's an already created package: 
https://bugs.launchpad.net/ubuntu/+bug/912789
https://bugs.launchpad.net/ubuntu/+source/evince/+bug/375038/+attachment/2660037/+files/libgxps-debian-package.zip



-- 
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/20120106154726.29012.14204.reportbug@savvas-desktop

ITP: tk-table -- Table extension for Tcl/Tk

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 

* Package name: tk-table
  Version : 2.10
  Upstream Author : Jeffrey Hobbs 
* URL : http://tktable.sourceforge.net
* License : BSD
  Programming Lang: C, Tcl
  Description : Table extension for Tcl/Tk
 Provides support for tables and matrices in Tcl/Tk. The basic features
 of the widget are:
  * multi-line cells
  * support for embedded windows (one per cell)
  * row & column spanning
  * variable width columns / height rows (interactively resizable)
  * row and column titles
  * multiple data sources ((Tcl array || Tcl command) &| internal caching)
  * supports standard Tk reliefs, fonts, colors, etc.
  * x/y scrollbar support
  * 'tag' styles per row, column or cell to change visual appearance
  * in-cell editing - returns value back to data source
  * support for disabled (read-only) tables or cells (via tags)
  * multiple selection modes, with "active" cell
  * multiple drawing modes to get optimal performance for larger tables
  * optional 'flashes' when things update
  * cell validation support
  * Works everywhere Tk does (including Windows and Mac!)

This is a kind of adoption of the package "tktable2.9" (binary package
"libtktable2.9") which was orphaned since 2008 and removed from unstable
in Feb 2011. See .


-- 
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/4f070175.2070...@liska.ath.cx

Re: Removing web server dependencies from web apps

[Jon Dowland]

On Fri, Jan 06, 2012 at 10:12:15AM +0100, Miroslav Suchy wrote:
> >Depends: apache2 | httpd, libapache2-mod-php5 | php5-cgi
> 
> I would not say that your chroot setup is typical. Or common.  I would
> suggest creating your own empty apache2 package with version , which you
> will install in this chrooted environment.

^^ a unique package name that provides: httpd would be safer in the above 
specific case.


-- 
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/20120106153854.GA11343@pris

Bug#654888: ITP: glances -- Glances is a CLI curses based system monitoring tool.

[Nicolargo]

Package: wnpp
Severity: wishlist
Owner: Nicolargo 


* Package name: glances
  Version : 1.3.5
  Upstream Author : Nicolas Hennion 
* URL : https://github.com/nicolargo/glances
* License : LGPL
  Programming Lang: Python
  Description : Glances is a CLI curses based system monitoring tool.

Glances is a CLI curses based monitoring tool for GNU/Linux or BSD OS.
Glances uses the libstatgrab library to get information from your system.
It is developed in Python and uses the python-statgrab lib.
You can have a look on CPU, LOAD, MEMORY, NETWORK INTERFACE, DISK IO and 
PROCESS.



-- 
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/20120106152536.1418.61726.report...@ks387949.kimsufi.com

Re: [Long] UEFI support

[Philipp Kern]

Hi,

On 2012-01-06, Tanguy Ortolo  wrote:
> Debian is concerned by this standard, because it has to be supported if
> we want it to be usable on UEFI-based systems. And I think we should be
> *very* concerned by it because, if I recall correctly, UEFI is a
> requirement for the Windows 8 sticker program (“designed for Microsoft
> Windows”), which means that we can expect that many branded PCs and
> motherboards, if not most, will be UEFI-based.

at least currently they still ship a compatibility mode.  With Ubuntu 64bit a
colleague of mine experienced that it did indeed boot by EFI, and installed an
appropriate grub for EFI, but the Lenovo firmware did not look in the right
places.  (It was probably only tested with the Windows bootloader.)

With Ubuntu 32bit everything worked.  Why?  Because it did not contain an
(U)EFI bootloader on the CD, and hence grub-pc was installed.  Compatibility
booting then worked as expected.  (There was also quite a bit of pain involved
in trying to get grub-pc working with amd64.  It seems the BIOS still tried
to do UEFI boots, possibly due to GPT being used by the Ubuntu installer, again
due to EFI startup.)

And note that the BIOS did not have much options, especially no option to turn
off EFI booting.  The machine in question was an Ideapad.  Please include a
boot menu option to force the installer to forget everything it knows about
EFI despite booting successfully from it, so that you can still use BIOS
compatibility (which is to many, IIRC even Linus Torvalds, still the lesser
of the two evils of x86 booting).

Kind regards
Philipp Kern


-- 
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/slrnjge2s4.udt.tr...@kelgar.0x539.de

Re: Removing web server dependencies from web apps

[Jérémy Lal]

On 06/01/2012 15:19, Mathieu Parent wrote:
> 2012/1/6 Olivier Bonvalet :
>> Le 06/01/2012 08:56, Thomas Goirand a écrit :
>>
>> For info, web apps which are not in PHP like redmine which use Ruby doesn't
>> depend of apache2 or any other http server.
>> So why should we depends of it for PHP apps only ?
> 
> Because ruby has an embedded web server (webrick), so it doesn't
> require one (but it is better for performance and more).

Right, and there have been several discussions concerning webapps :

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627213
http://lists.debian.org/debian-webapps/2010/05/msg1.html

Also consider continuing this dicussion to
debian-weba...@lists.debian.org
?

Jérémy.


-- 
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/4f0706a8.80...@edagames.com

[Long] UEFI support

[Tanguy Ortolo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello all,

UEFI (often called EFI, which was the name of its previous version) is a
new firmware interface, which is expected to replace the BIOS on new
PCs, as at has already done so on Apple PCs. While modern operating
system do not rely much on firmware calls for normal operation, the boot
loader does.

Debian is concerned by this standard, because it has to be supported if
we want it to be usable on UEFI-based systems. And I think we should be
*very* concerned by it because, if I recall correctly, UEFI is a
requirement for the Windows 8 sticker program (“designed for Microsoft
Windows”), which means that we can expect that many branded PCs and
motherboards, if not most, will be UEFI-based.

In order not to see Debian become uninstallable (meaning, not
installable unless you are a guru) on most computers, I wonder if UEFI
support should not even be promoted as a release goal. But anyway, here
is a basic summary of how it works from a boot procedure point of view,
and what it means to support it.


UEFI boot procedure
===

Boot manager
- 

First there is a boot /manager/, which is menu provided by the firmware
to select what to boot among the available systems, for instance:
1. CD/DVD
2. HDD1 - Microsoft Windows
3. HDD1 - Debian GNU/Linux
4. USB key

This is similar to the boot device selection menu that is provided by
most BIOSes, but it has been extended so that:
1. it offer a way to choose between several systems on the same device;
2. it can be configured (add, remove or reorder entries) from a running
   operating system.

A bootable system
- -

In practice, a bootable system means a bootloader. On hard disks and USB
keys, contrary to BIOS which simply loads it from a fixed location, the
UEFI boot manager will load it from a file.

To be usable from the boot manager, a bootloader file has to be placed
on a supported filesystem (in practice, that means a FAT) on a partition
with an GUID corresponding to the type called “EFI System Partition”.

When it comes to the boot manager menu, there are two cases. On fixed
devices (hard disks), an entry has to be added to the menu, by
interacting with the UEFI NVRAM from a running OS using a dedicated
program. There can be several bootloaders on a single EFI System
Partition. On removable devices, such a procedure would be irrelevant,
so the boot manager will simply look for a file names
/efi/boot/boot.efi, where  == {ia32|ia64|x64|arm}. Thus
there can only be a single bootloader on a removable device's EFI System
Partition.

For optical media, I am not really sure: it may use ElTorito or load a
file /efi/boot/boot.efi from the ISO-9660 or UDF filesystem, so
this should be checked.

The bootloader
- --

The bootloader itself has nothing specific except that is runs on an
UEFI environment and should thus use UEFI calls rather than BIOS calls,
of course.


Supporting UEFI
===

I am taking the point of view of a user trying to install an operating
system.

Starting the installer
- --

First we need to start the installer from a removable medium. This means
having a USB key image containing a GTP with one FAT-formatted EFI
System Partition containing a boot loader at /efi/boot/boot.efi,
and possibly another partition containing whatever it takes to run the
installer.

After that, most of the installation has nothing specific, except the
following two points.

Partitionning
- -

We are installing an operating system to a hard disk, which may or may
not already contain an EFI System Partition.

If there is one, that partition and the content of its filesystem should
be kept (formatting it could mean removing an existing bootloader, which
would be wrong™), and it should be used later to install our bootloader.

If ther is none, it should be created and used later to install our
bootloader.

Installing the bootloader
- -

The bootloader should be installed on the EFI System Partition, on a
path following the convention /efi//, for instance
/etc/debian/grubx64.efi.

It should then be added to the boot manager menu by doing the appopriate
calls, which probably means using the appriopriate dedicated tool.


Current status
==

This is what I think we have for Debian.

Installer image
- ---

I do not think we have any UEFI-bootable installer images so far.

It would be possible to create hybrid BIOS/UEFI bootable images, but
that will probably be incompatible with hybrid USB/optical images as we
have them currently. Thanks to the /efi/boot/boot.efi convention,
it would also be possible to have multiarch images.

It is also worth noting that an amd64 PC will probably support x64 UEFI
only, so given that there is probably no UEFI-base x86 PCs, there is no
point in creating corresponding images.

Partitionning
- -

An EFI System Partition is basically a r

Re: Removing web server dependencies from web apps

[Mathieu Parent]

2012/1/6 Olivier Bonvalet :
> Le 06/01/2012 08:56, Thomas Goirand a écrit :
>
> For info, web apps which are not in PHP like redmine which use Ruby doesn't
> depend of apache2 or any other http server.
> So why should we depends of it for PHP apps only ?

Because ruby has an embedded web server (webrick), so it doesn't
require one (but it is better for performance and more).

Regards

-- 
Mathieu Parent


--
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/CAFX5sbwLLb7znfJQ30Q2q+ZTHL9A7FTBdC6nFJ_uSSMy7e�a...@mail.gmail.com

Re: Removing web server dependencies from web apps

[Milan P. Stanic]

On Fri, 2012-01-06 at 20:45, Thomas Goirand wrote:
[...]
> This is why I think the solution of moving apache2 | http as
> a Recommends: is a good compromise.
> 
> Never mind, it seems there's more people against my idea
> than some thinking it was a smart one, so I'll hack with equivs
> (which I didn't know) and see how it goes.

You can't be sure ;-)
Maybe we just tired to repeat our arguments against 'Debian dependency
hell', as I call it.

I just do what you do: rebuild application without unneeded dependencies
and live with the idea that Debian must be usable for everyone in the
world (which is impossible, IMHO) but that's the life.

-- 
Kind regards,  Milan


-- 
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/20120106134615.gb12...@arvanta.net

Re: Removing web server dependencies from web apps

[Thomas Goirand]

On 01/06/2012 06:47 PM, Stefano Zacchiroli wrote:
> On Fri, Jan 06, 2012 at 06:15:36PM +0800, Thomas Goirand wrote:
>   
>> Then please explain to me how I can install let's say wordpress, in a
>> chroot (and of course, without apache), without doing some hacks! Yes,
>> wordpress is FORCING ME to install a web server package.
>> 
> It has been mentioned to you in this thread already (by Neil): use
> "equivs". Can you explain why equivs doesn't match your needs?
>
> Yes, it is a hack, but there is always some sort of spectrum between a
> clean solution and a hack, and you have to concede you're surely not in
> the most common of the use cases. This discussion has the potential of
> being useful, but before proposing to change hundreds of packages, you
> need at the very least to explain why the current recommended solution
> does not fulfill your needs.
>
> Cheers.
>   

Hi,

I will give that a try, thanks for the tip.

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/4f06ede9.5070...@debian.org

Re: Removing web server dependencies from web apps

[Thomas Goirand]

On 01/06/2012 07:07 PM, Olivier Bonvalet wrote:
> Le 06/01/2012 08:56, Thomas Goirand a écrit :
>>
>> The issue is that most PHP packages in Debian have dependencies on web
>> servers, most of the time with something like this:
>>
>> Depends: apache2 | httpd, libapache2-mod-php5 | php5-cgi
>>
>
> For info, web apps which are not in PHP like redmine which use Ruby
> doesn't depend of apache2 or any other http server.
> So why should we depends of it for PHP apps only ?
Yeah, that's my point as well!

Also, with the dependency set like as above, if you remove
"apache2 | httpd", then apt / dpkg will pickup libapache2-mod-php5,
which depends on apache2 anyway, so apache will be installed
by default unless you explicitly install php5-cgi.

This is why I think the solution of moving apache2 | http as
a Recommends: is a good compromise.

Never mind, it seems there's more people against my idea
than some thinking it was a smart one, so I'll hack with equivs
(which I didn't know) and see how it goes.

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/4f06eccd.4070...@debian.org

Re: new on list

[Josselin Mouette]

Le jeudi 05 janvier 2012 à 17:40 +0200, vangelis a écrit : 
> Hi folks,
> I'm totaly new and i need instructions and a guide how to start or if 
> there are groups to join as new beginner.

1. Go to http://wiki.debian.org/Teams
2. Pick a team working on something of interest for you.
3. Talk to them.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1325853830.3342.815.camel@pi0307572

Re: Removing web server dependencies from web apps

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06.01.2012 12:07, Olivier Bonvalet wrote:
> For info, web apps which are not in PHP like redmine which use Ruby
> doesn't depend of apache2 or any other http server.
> So why should we depends of it for PHP apps only ?

And as a third example: trac is written in Python but recommends
"apache2 | httpd" (albeit not depends).

We better consolidate dependencies of web applications instead of
picking examples for either arguments, as different people sadly solve
the same problem different here.


- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPBuk5AAoJEMcrUe6dgPNt3XcP/1QOdZ0yRRJbmUYIWs+gW7BO
rT9F5ZrkQ4oiQqSXNgncABe+hIBncDSqxDM9DIEIeDjxTkzhuOZBn2hsAqTab7Yq
AIaefM5fH3bbU6G6UPszgzY+VqGHs9QK8Q7ScQMlXrwm/ldjBout3AAExiDmkrcZ
d8NwCEdg0ufE8C7h64C2SqhlsN4njuRdRcM4xgIkKyWMbIRG9hCzUCsDhT01sFMc
8VUimmqAkCBCZe9jpqC1hTJ62xSUuj3aLk3k0EQBp+VQUuWHNb0nDVkJpUYjdvuN
YuO3ANO427j6QVXx7LRcaWTbbQWJpoF8XOynyPWzcE5H//+kbBhZRpHVJaBNyd5k
5sZ9Van/n8iJ7dpgjDJ0vOZIFTkK7L3WX6R1xEak/0BSePGNwpBYW2++oCT8C65/
iC6QhLTB2+ubCOR8NpGzG4E2WYiApU9uKGsBUbgUICzUKCBb8Y91kDEc6URU0xZ3
XBv8+6Bkw06tgWYEE21w1GbNkXtLHPMqvmj/RpWu0HSzVTsyyCrJ1nDBec2IWOZo
5wIpiB+WNd1sHCGzI4e67HKTCmLEYYmSYcYw7Q/dq8DuOUswM1DIydXrk8637x8Y
8PJCQZqz3TozM5z1Ko4b3jge4mWC0d9f9gi43unmso01Eh1NiIS6r7WNKMM+EEu2
AFEvbJMu3to15R3CQ9JL
=atN+
-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/4f06e939.3040...@toell.net

Re: Removing web server dependencies from web apps

[Roland Mas]

Thomas Goirand, 2012-01-06 18:06:35 +0800 :

[...]

> That's what I don't get! I think using a remote MySQL is as uncommon
> as a chrooted CGI environment.

>From what I've seen of various clients' systems, it isn't.  The web
server is often isolated not in a chroot but in a separate host (whether
physical host, VM or LXC); and I've seen several cases of one
consolidated (and adequately-maintained) database server used remotedy
by many applications.

Roland.
-- 
Roland Mas

'ALL your base? No!! One tiny base continue bravely to resist.'
  --  in #debian-devel


-- 
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/87vcop1183@mirexpress.internal.placard.fr.eu.org

Re: Source package without a binary

[Joachim Breitner]

Hi,

Am Donnerstag, den 05.01.2012, 22:33 -0800 schrieb Josh Triplett:
> Joachim Breitner wrote:
> > From my point of view, it seems desirable to package the testsuite as a
> > source-package of its own, build-depending on GHC and the additional
> > libraries required, and upload that. Our autobuilding infrastructure
> > would thus run the testsuite on the various architectures, which is very
> > desirable, given that we are talking about a compiler that is not
> > well-tested by upstream on the more exotic architectures.
> 
> Wouldn't this mean that you'd have to trigger a no-changes bin-NMU of
> the testsuite package every time GHC changes, to re-run the test suite?

correct. It sounds rather convenient to me (at least with todays
wanna-build architecture with edos-support and autosigning, so this
would not burn human resources). And by using binNMUs, I can even select
individual architectures, e.g. after adding a patch to to GHC that only
affects s390, I can schedule a binNMU on s390 only, or skip running the
test suite after an upload of GHC that has only non-functional changes.
Thanks for pointing out that advantage.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Removing web server dependencies from web apps

[Olivier Bonvalet]

Le 06/01/2012 08:56, Thomas Goirand a écrit :


The issue is that most PHP packages in Debian have dependencies on web
servers, most of the time with something like this:

Depends: apache2 | httpd, libapache2-mod-php5 | php5-cgi



For info, web apps which are not in PHP like redmine which use Ruby doesn't 
depend of apache2 or any other http server.
So why should we depends of it for PHP apps only ?


$ LC_ALL=C apt-cache show redmine
Package: redmine
Version: 1.3.0+dfsg1-1
Installed-Size: 10522
Maintainer: Jérémy Lal 
Architecture: all
Depends: ruby1.8, ruby-rails-2.3 (>= 2.3.14) | rails (>= 2.3.14), dbconfig-common, 
redmine-sqlite | redmine-mysql | redmine-pgsql, ruby-coderay, ruby-net-ldap, debconf 
(>= 0.5) | debconf-2.0
Pre-Depends: debconf
Suggests: libsvn-ruby (>= 1.3), ruby-rmagick, libopenid-ruby


--
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/4f06d5eb.3010...@daevel.fr

Bug#654858: ITP: jenkins-remoting -- Bridge separate JVMs into a single semi-shared space

[James Page]

Package: wnpp
Severity: wishlist
Owner: James Page 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: jenkins-remoting
  Version : 2.4
* URL : http://github.com/jenkinsci/remoting
* License : MIT
  Programming Lang: Java
  Description : Bridge separate JVMs into a single semi-shared space

  Allows separate JVMs to be bridged into a single semi-shared space.
  .
  This package is primarily used by Jenkins for slave node management
  but has potential re-use outside of this project.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPBtO5AAoJEL/srsug59jDGjkP/RYtouBkN012ZuYqnN9JPGXf
nNYu7wKgPGZ0qdcSr9ebTM4ZaVB7Um7xBWpOXH1xUprCCzaxHc5XE49kK5EHiDCu
zyWpMTF8zWApK/X6dt5g2s4USZ+Cy85fYSa/7saIxVz7rsE8+zEeMy6Hp2nmZJ73
9XXxqbkWjedocXOymMwT8bNskWupgw67+Rda5VgDQ4qULW03LQf4gvRAqIQUy1fU
7yR5QojeNwx7+Lzsyb/nIpdM2TzGX3nluQdrcd54XV+xzb6QghU8iYLMl9f9rwPK
gGV8Se1n2ckCHE+AjLnzvPh73FhTOOGzDnxh7+V8t09Me8rIjqxH7yIGhZ1WpLQy
Ye9gxWVXKeAIvkCKgSG6fvylEnibEFqkL7Y5c7pmRchrLZFHjwznwfVgeHu0EUxZ
BeQYv6LLgUWevAYyA17bUeWoF3B14JMyf16tvejOHCr5wg0NP3QSRoWb03Vr6LLb
/TALMwFtR5svAE6ZdxLxUj49Xux0LdFwToH2wugFNEH4suQRemBixsxGWwEUl2/A
pTr1Xu6fNnrtmJJQXjaxCCA02KzOSq19FKCOv8GmemShlw8mYD8OYWK3RX2h+weu
P9DWbD/v0n0nEx1NxER2VDJDdXL3XRRxvttGRaWfrFZkr1/3D3UfnplOaUm8ir/4
U9pZB+Pr+kHQ3GWEOpp2
=E0mO
-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/20120106105801.19475.15708.reportbug@hendrix.shouse.local

Re: Removing web server dependencies from web apps

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 06.01.2012 10:12, Tanguy Ortolo wrote:
> The database server used by a given piece of software can be installed
> on another system. The Web server cannot.

Actually it can. Many modern webservers, including one I am maintaining
support CGI offloading and load balancing [1].

However I'd yet disagree with Thomas. Yes, his scenario is feasible and
a perfect use case for equivs, but I do not think, we should generally
drop dependencies to web servers because of that.

I personally do not get, why we do need packages of web applications at
all, but apparently other people do. Yet I do think, users of such
packages expect us to setup a working instance, just like we do for
almost every other package. We just can't provide a scenario which fits
all and generally I think, people using advanced setups like chroots and
CGI offloading are expected to know how to workaround such problems then.


>> But since I would install these packages in the chroot template, I *do
>> not* want to install apache there. The result is that I can't install
>> popuplar packages like wordpress, gallery, phpbb3 and so on, unless I
>> rebuild them and remove the "apache2 | httpd" dependency. I suspect that
>> I wouldn't be the only one with the issue.

It has been said before: Provide a httpd-cgi and a httpd package in your
chroot, and all is good.

>> Remember that a strong dependency is *forcing* users to install things,
>> and when, like here, it's going the wrong way for what one would do,
>> it's just *bad* (tm).
> 
> No it is not. Using a package-based distribution that could take care of
> dependencies and not using that feature is, however.

Agreed. My bottom line is, the overall benefit of depending on a web
server for a web apllication is higher than working in special case
scenarios we - as a distribution - do not support just because we can't.
That has already been said before, so this argument is a bit redundant.

>> So, my suggestion would be to actually *remove* the dependency to the
>> web server (and move it as a Recommends: if you see fit...). I would
>> strongly advocate for this as being written in our beloved policy.

Why would web applications be the only exception of the rule? I'm sure
there are many more special case scenarios where a weaker dependency
would be better, but the overall benefit is more valuable. In fact, we
do have "Depends" at all then? I'm sure there is a special use case for
almost every dependency where it would be better not to have it at all.


[1] http://redmine.lighttpd.net/wiki/lighttpd/Docs%3AModFastCGI

- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPBtBCAAoJEMcrUe6dgPNt0DwQAMCeqP8dnYO+etDDhTDadln2
GwS55LsRhvL9J3oyQ4/adVPdEwTqJTqtkOibe9OknWymBVW30+bEZApT93XGnBhT
0mJga486QXRKHM2xiS1W5M8a7SegMKjU83gtSaetgs8hccWwjnnsZV7D/1XGYxam
qmwfg3H/Qk9gROdBjpnKNSO3YJK9CZzb4ZFZ9kF+VJDsh8T3k4ajX0mwlf2fws19
D495jrCZhNmDG0+F+k+3UvQfDO48xOw7aD6QJs2taHxGrD8zg6/J10/8m15aKjLV
u6GXfbXA3WVIxrSnvWyNWupGGjaF3dm7IaUncI0NpCRrFocFCu553PHBud5tofYB
wZYOC6fr5ZtfomX7jcD+LNWUBjcTAgTl6MHwHtIwCwsoxxC/duARqzdJBh1lBJUE
KX6SQQ/vVT5NO5wbwuNYb+4R77YxYwpxps0mzfuckJJZfzmn9Lm48B5uFjfqJA5u
inJL1+NVCdIjqlODSmQQPFJacAQ5mI0K7r8IaxckOnFm6V1fhJtyh50muTHnMcdT
B96MRDJi00tnd0iJMGxIrTwB2+ibWPnFy1ig9nLE69EVex/PrmJkvY9/h66NY1dO
Ht37Th5idbrFgBouCtGXVO+oyHzZUmqkvYguJ7ni3V2L/mII9yA5EUXDL5Tt5A/Q
ilIisPkeSRKsQVr/7PKb
=IL3m
-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/4f06d042.9080...@toell.net

Re: Removing web server dependencies from web apps

[Thomas Goirand]

On 01/06/2012 05:12 PM, Tanguy Ortolo wrote:
> Thomas Goirand, 2012-01-06 08:56+0100:
>   
>> Also, it's very surprising to see that we have dependencies for web
>> servers, but most of the time *not* for mysql-server, which is as much
>> needed in order to run these applications. I really don't understand the
>> logic behind this.
>> 
> The database server used by a given piece of software can be installed
> on another system. The Web server cannot.
>   

See my reply to Miroslav about this.

>> But since I would install these packages in the chroot template, I *do
>> not* want to install apache there. The result is that I can't install
>> popuplar packages like wordpress, gallery, phpbb3 and so on, unless I
>> rebuild them and remove the "apache2 | httpd" dependency. I suspect that
>> I wouldn't be the only one with the issue.
>> 
> This sounds like you are using your own crafted stuff to provide the
> needs of your software stuff. Just like someone that would for instance
> compile his own version of Python from sources.

Why do you think this is uncommon? Doing shared hosting services isn't, and
if you don't use a good chrooted thing, you don't have security. I don't
need
to compile ANYTHING, I use plain Debian, and all packages that comes with
it. And I would like to keep things this way.

> Well, in such a case I
> see it as a will not to use the package manager, and thus your
> responsibility to do whatever is needed to fool it. This is usually done
> by creating fake empty packages, I guess.
>   

That's exactly what I would like to avoid!

>> Remember that a strong dependency is *forcing* users to install things,
>> and when, like here, it's going the wrong way for what one would do,
>> it's just *bad* (tm).
>> 
> No it is not. Using a package-based distribution that could take care of
> dependencies and not using that feature is, however.
>   

Then please explain to me how I can install let's say wordpress, in a
chroot (and
of course, without apache), without doing some hacks! Yes, wordpress is
FORCING
ME to install a web server package.

> That it would be a very bad thing to do. Most users want to install
> software so that it works without further questions.

Excuse my wording, but that's plain wrong (no aggressiveness intended).
These packages don't depend on a database server, so that's not the case.

> You are in a very
> specific, specialized case, so you should be able to deal with it.
>   

Plain simple: we can support ANY cases (by not depending on a web
server), or we can say that we only want to support SOME of them,
in which case we should also depend on a MySQL server. Otherwise,
there's absolutely no logic at all in what we are doing.

Also again, how hard is it to just do "apt-get install apache2"? Do
you *seriously* think that someone capable of installing a MySQL
server, a php web app, AND configuring the web server to run it,
can't do this? Again, remember that most apps will NOT setup the
virtualhost thing, as this is a task left to the administrator.

Also, if we have the web server dependency downgraded as a
Recommends:, then BY DEFAULT, it will be pulled. So what's the
big deal here?

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/4f06c9c8.3050...@debian.org

Re: Removing web server dependencies from web apps

[Thomas Goirand]

On 01/06/2012 05:12 PM, Miroslav Suchy wrote:
> On 01/06/2012 08:56 AM, Thomas Goirand wrote:
>> The issue is that most PHP packages in Debian have dependencies on web
>> servers, most of the time with something like this:
>>
>> Depends: apache2 | httpd, libapache2-mod-php5 | php5-cgi
>
> I would not say that your chroot setup is typical. Or common.

I tend to believe it becomes less and less truth.

> I would suggest creating your own empty apache2 package with version
> , which you will install in this chrooted environment.

Yes, I think I'll do that, but I'm sure such hack isn't what we want to
advise in Debian in general.

>
>> Also, it's very surprising to see that we have dependencies for web
>> servers, but most of the time*not*  for mysql-server, which is as much
>> needed in order to run these applications. I really don't understand the
>> logic behind this.
>
> Because mysql-server can (and actually very often) is located on
> different machine.
>
> Mirek

I was expecting an answer like that (and was waiting for it). THANKS ! :)

That's what I don't get! I think using a remote MySQL is as uncommon as
a chrooted CGI environment. If we push for Apache / $web-server being
pulled so that $web-app would work out of the box with all needed
dependencies, then we should apply the same reasoning to the MySQL
server. There's no logic at all here.

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/4f06c7ab.7080...@debian.org

Re: Removing web server dependencies from web apps

[Thomas Goirand]

On 01/06/2012 04:34 PM, Neil Williams wrote:
> It depends which is more common

I don't see why we would steer on the direction of the most common
thing only. What we want is something that works all the time, no?
If we remote the web server dependency, it works all the time.

Don't you think that someone who can setup a PHP app, also knows
that it will need apache, and that apt-get install apache2 is quite an
easy thing to do?

If someone is can setup a PHP app, I think we can assume that he
also knows how to install apache.

> How many of these packages do clever things upon installation like
> setup their own virtual hosts or similar?
>   

None, because that's forbidden by the Debian policy.

> One reason why the database is not included in dependencies is dbconfig.
>   
Could you elaborate?

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/4f06c5ae.1030...@debian.org

Re: Removing web server dependencies from web apps

[Miroslav Suchy]

On 01/06/2012 08:56 AM, Thomas Goirand wrote:

The issue is that most PHP packages in Debian have dependencies on web
servers, most of the time with something like this:

Depends: apache2 | httpd, libapache2-mod-php5 | php5-cgi


I would not say that your chroot setup is typical. Or common.
I would suggest creating your own empty apache2 package with version 
, which you will install in this chrooted environment.



Also, it's very surprising to see that we have dependencies for web
servers, but most of the time*not*  for mysql-server, which is as much
needed in order to run these applications. I really don't understand the
logic behind this.


Because mysql-server can (and actually very often) is located on 
different machine.


Mirek


--
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/4f06baef.5070...@suchy.cz

Re: Removing web server dependencies from web apps

[Tanguy Ortolo]

Thomas Goirand, 2012-01-06 08:56+0100:
> Also, it's very surprising to see that we have dependencies for web
> servers, but most of the time *not* for mysql-server, which is as much
> needed in order to run these applications. I really don't understand the
> logic behind this.

The database server used by a given piece of software can be installed
on another system. The Web server cannot.

> But since I would install these packages in the chroot template, I *do
> not* want to install apache there. The result is that I can't install
> popuplar packages like wordpress, gallery, phpbb3 and so on, unless I
> rebuild them and remove the "apache2 | httpd" dependency. I suspect that
> I wouldn't be the only one with the issue.

This sounds like you are using your own crafted stuff to provide the
needs of your software stuff. Just like someone that would for instance
compile his own version of Python from sources. Well, in such a case I
see it as a will not to use the package manager, and thus your
responsibility to do whatever is needed to fool it. This is usually done
by creating fake empty packages, I guess.

> Remember that a strong dependency is *forcing* users to install things,
> and when, like here, it's going the wrong way for what one would do,
> it's just *bad* (tm).

No it is not. Using a package-based distribution that could take care of
dependencies and not using that feature is, however.

> So, my suggestion would be to actually *remove* the dependency to the
> web server (and move it as a Recommends: if you see fit...). I would
> strongly advocate for this as being written in our beloved policy.
> 
> What do others think about this?

That it would be a very bad thing to do. Most users want to install
software so that it works without further questions. You are in a very
specific, specialized case, so you should be able to deal with it.

-- 
 ,--.
: /` )   Tanguy Ortolo  
| `-'Debian Developer
 \_


-- 
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/je6due$rqk$2...@dough.gmane.org

Re: Removing web server dependencies from web apps

[Aron Xu]

On Fri, Jan 6, 2012 at 16:34, Neil Williams  wrote:
> On Fri, 06 Jan 2012 15:56:37 +0800
> Thomas Goirand  wrote:
>
>> The issue is that most PHP packages in Debian have dependencies on web
>> servers, most of the time with something like this:
>>
>> Depends: apache2 | httpd, libapache2-mod-php5 | php5-cgi
>
> Sounds like the situation for which equivs was designed.
>
>> Remember that a strong dependency is *forcing* users to install things,
>
> Not quite. A strong dependency requires that something with that name
> is installed - it can just as easily be an empty package which just
> matches the name. Put that package into your chroots and the problems
> disappear.
>

Disagrees. Debian can't require all users/administrators of a package
to learn how to
*make your own empty package* when the dependency is actually
unnecessary. It that
were me, I'll rebuild the webapp package and remove whatever I don't
like, which is
not reasonable for common users either.

I support to downgrade those Depends to Recommends.


-- 
Regards,
Aron Xu


-- 
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/CAMr=8w4pCnUUUCw+13aJHLtQ-ceut=qtzz7vk9nbq+3hud1...@mail.gmail.com

Re: Removing web server dependencies from web apps

[Neil Williams]

On Fri, 06 Jan 2012 15:56:37 +0800
Thomas Goirand  wrote:

> The issue is that most PHP packages in Debian have dependencies on web
> servers, most of the time with something like this:
> 
> Depends: apache2 | httpd, libapache2-mod-php5 | php5-cgi

Sounds like the situation for which equivs was designed.

> Remember that a strong dependency is *forcing* users to install things,

Not quite. A strong dependency requires that something with that name
is installed - it can just as easily be an empty package which just
matches the name. Put that package into your chroots and the problems
disappear.

> So, my suggestion would be to actually *remove* the dependency to the
> web server (and move it as a Recommends: if you see fit...). I would
> strongly advocate for this as being written in our beloved policy.

It depends which is more common - complex installations with a web
server available over IP but not visible to dpkg or simple
installations where the admin installing the application is also
responsible for setting up the virtual hosts etc.

How many of these packages do clever things upon installation like
setup their own virtual hosts or similar?

One reason why the database is not included in dependencies is dbconfig.
Whether that's a good thing or a bad thing is left as an exercise for
the reader.

-- 


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



pgpU9I7O2iSuw.pgp
Description: PGP signature

Removing web server dependencies from web apps

[Thomas Goirand]

Hi,

It's been a long time I'm thinking about writing a message like this one
to -devel. I hope I can convince others.

In many large installations, web servers are providing spaces in a chroot.

Myself, I use sbox (which I rewrote for a big part) to provide this to
my customers, so that each site that runs scripts (Perl, Python, Ruby or
PHP) can do so in a safe, secure, chroot environment. Since it would
otherwise take too much space to have a full debian chroot for each
site, I use AUFS to provide it. So I have a template operating system,
on which there is PHP, Ruby, Python and Perl support, all running as CGI.

I know others are using tools like php-fpm to achieve the same thing.

Running sites in a chroot environment is increasingly important
considering how much security issues are regularly discovered.

The issue is that most PHP packages in Debian have dependencies on web
servers, most of the time with something like this:

Depends: apache2 | httpd, libapache2-mod-php5 | php5-cgi

Also, it's very surprising to see that we have dependencies for web
servers, but most of the time *not* for mysql-server, which is as much
needed in order to run these applications. I really don't understand the
logic behind this.

But since I would install these packages in the chroot template, I *do
not* want to install apache there. The result is that I can't install
popuplar packages like wordpress, gallery, phpbb3 and so on, unless I
rebuild them and remove the "apache2 | httpd" dependency. I suspect that
I wouldn't be the only one with the issue.

Remember that a strong dependency is *forcing* users to install things,
and when, like here, it's going the wrong way for what one would do,
it's just *bad* (tm).

So, my suggestion would be to actually *remove* the dependency to the
web server (and move it as a Recommends: if you see fit...). I would
strongly advocate for this as being written in our beloved policy.

What do others think about this?

Cheers,

Thomas Goirand (zigo)


-- 
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/4f06a935.6040...@goirand.fr