Hi, I only want to know when will jessie released , I am waitting for
SteamOS final version, but first you must launch jessie, thanks for your
time! // Hola, solo quería saber cuando se lanzará la versión estable de
Debian Jessie, estoy pendiente del lanzamiento de la versión definitiva de
SteamO
On 29/01/15 09:32, Balder García García wrote:
> Hi, I only want to know when will jessie released , I am waitting for
> SteamOS final version, but first you must launch jessie, thanks for your
> time! // Hola, solo quería saber cuando se lanzará la versión estable de
> Debian Jessie, estoy pendi
of things that need to be done before the
release. We are currently in feature freeze for Jessie.
At the page for information on the Jessie release, you can see:
People often ask if there is a single release "progress meter".
Unfortunately there isn't one, but we can refer y
Hi,
now might be the right time to start a discussion about release goals
for jessie. Here are some points that come into my mind right now (and
some were already discussed very recently):
* multiarch compatible binNMUs
* discarding maintainer uploaded binary packages [!arch:all]
* discarding mai
Hey.
I would like to see the following with respect to PHP and all packages
using PHP:
1) We should try to educate users not to use mod_php. From a security
POV it's rather problematic, as it runs in server context. And for
people really needing the performance, FPM should be an equally good
solut
On 2013-05-06 14:49, Andreas Beckmann wrote:
> Hi,
>
> now might be the right time to start a discussion about release goals
> for jessie. Here are some points that come into my mind right now (and
> some were already discussed very recently):
>
While the ideas themselves are worthwhile, they d
Hello,
2013/5/6 Christoph Anton Mitterer :
> Hey.
>
> I would like to see the following with respect to PHP and all packages
> using PHP:
[...]
Related to PHP, but more on the PEAR side, I would like to see all
PEAR packages migrated to build with pkg-php-tools (the dh way of PEAR
packages).
Mig
On 05/06/2013 08:49 AM, Andreas Beckmann wrote:
Hi,
now might be the right time to start a discussion about release goals
for jessie. Here are some points that come into my mind right now (and
some were already discussed very recently):
* multiarch compatible binNMUs
* discarding maintainer up
Two more things I remember:
1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that listen per
default on the network (unless loopback only) shouldn't be started per
default, after being installed.
The usually come only with a default config which may not be hardened
enough for the local syst
On Mon, May 06, 2013 at 04:08:07PM +0200, Christoph Anton Mitterer wrote:
> 1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that listen per
> default on the network (unless loopback only) shouldn't be started per
> default, after being installed.
> The usually come only with a default confi
2013/5/6 Andrey Rahmatullin :
> There is also a related thing that was discussed in the past: stop
> disabling services via /etc/default.
Modern service management systems might be better choice.
E. g. systemd or SMF :-P
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
On 05/06/2013 09:15 PM, Christoph Anton Mitterer wrote:
> Hey.
>
> I would like to see the following with respect to PHP and all packages
> using PHP:
> 1) We should try to educate users not to use mod_php. From a security
> POV it's rather problematic, as it runs in server context. And for
> peopl
On May 06, Christoph Anton Mitterer wrote:
> 1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that listen per
> default on the network (unless loopback only) shouldn't be started per
> default, after being installed.
This has been discussed over and over, I think with a clear consensus:
i
On 05/06/2013 09:29 PM, Mathieu Parent wrote:
> Related to PHP, but more on the PEAR side, I would like to see all
> PEAR packages migrated to build with pkg-php-tools (the dh way of PEAR
> packages).
Yes ! I do 100% agree with the above. This could be a release goal, IMO.
> Migrating PECL packag
* Niels Thykier , 2013-05-06, 15:26:
now might be the right time to start a discussion about release goals
for jessie. Here are some points that come into my mind right now (and
some were already discussed very recently):
While the ideas themselves are worthwhile, they do not seem to be
"releas
On 05/06/2013 10:08 PM, Christoph Anton Mitterer wrote:
> The usually come only with a default config which may not be hardened
> enough for the local system, and that short time may already be enough
> for an attacker to attack.
If the default config isn't hardened enough, fix the default config.
severity 601455 normal
thanks
Hi,
On Montag, 6. Mai 2013, Andrey Rahmatullin wrote:
> There is also a related thing that was discussed in the past: stop
> disabling services via /etc/default.
#601455 "can't stop daemon using /etc/init.d/foo stop when disabled via
/etc/default/foo" is related to
* Christoph Anton Mitterer , 2013-05-06, 16:08:
2) No more packages that bypass the package management system and
secure apt:
a) There are still several (typically non-free) packages which download
stuff from the web, install or at least un-tar it somwhere without
checking any integrity informa
On 2013-05-07 00:52:03 +0800, Thomas Goirand wrote:
> On 05/06/2013 10:08 PM, Christoph Anton Mitterer wrote:
> > The usually come only with a default config which may not be hardened
> > enough for the local system, and that short time may already be enough
> > for an attacker to attack.
> If the
On 2013-05-06 17:22:57 +0200, Marco d'Itri wrote:
> On May 06, Christoph Anton Mitterer wrote:
> > 1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that listen per
> > default on the network (unless loopback only) shouldn't be started per
> > default, after being installed.
> This has been
As the sole driver and implementor of DEP9, I would like to see all reverse
depends of update-inetd migrate to reconf-inetd. That is, assuming inetd is
not entirely deprecated by systemd/upstart/whathaveyou by the time jessie is
released.
On a less boring note, I would like to see apt-listbugs bec
On Mon, 06 May 2013, Vincent Lefevre wrote:
> On 2013-05-06 17:22:57 +0200, Marco d'Itri wrote:
> > On May 06, Christoph Anton Mitterer wrote:
> > > 1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that
> > > listen per default on the network (unless loopback only) shouldn't
> > > be starte
Christoph Anton Mitterer wrote:
> I would like to see the following with respect to PHP and all packages
> using PHP:
> 1) We should try to educate users not to use mod_php.
If "Best Practices" such as this were documented such as on the Debian
wiki then it would go a long way to making this easy
On Mon, May 06, 2013 at 04:08:07PM +0200, Christoph Anton Mitterer wrote:
> 1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that listen per
> default on the network (unless loopback only) shouldn't be started per
> default, after being installed.
May I point to /usr/sbin/policy-rc.d? As ha
On Mon, May 6, 2013 at 8:49 AM, Andreas Beckmann wrote:
> Hi,
>
> now might be the right time to start a discussion about release goals
> for jessie. Here are some points that come into my mind right now (and
> some were already discussed very recently):
>
> * multiarch compatible binNMUs
> * disca
On Mon, 2013-05-06 at 14:59 -0600, Bob Proulx wrote:
> > 1) We should try to educate users not to use mod_php.
> If "Best Practices" such as this were documented such as on the Debian
> wiki then it would go a long way to making this easy for users to do.
> They could then simple follow recipies to
On Mon, 2013-05-06 at 20:47 +0200, Jakub Wilk wrote:
> Do you have any concrete examples (besides flashplugin-nonfree, which is
> indeed abominable)?
I know at least of susv2/3.
I once manually went through all the packages depending on wget/curl,...
but I don't have the list anymore and would li
On Tue, 2013-05-07 at 00:52 +0800, Thomas Goirand wrote:
> If the default config isn't hardened enough, fix the default config.
> Adding a supplementary step to start the service doesn't fix the
> problem anyway.
I don't think this is only a question of hardened enough of not...
simply supplying a
+++ The Wanderer [2013-05-06 09:36 -0400]:
>
> I don't know whether it would be practical, but one thing I would like
> to see included as an explicit goal is the completion of multi-arch -dev
> support.
I think it's eminently practical.
> There is functionality provided by the old ia32-libs-dev
On Mon, May 6, 2013 at 8:49 PM, Andreas Beckmann wrote:
> now might be the right time to start a discussion about release goals
> for jessie. Here are some points that come into my mind right now (and
> some were already discussed very recently):
I have a long wishlist that contains some items wh
On Mon, 06 May 2013, Helmut Grohne wrote:
> On Mon, May 06, 2013 at 04:08:07PM +0200, Christoph Anton Mitterer wrote:
> > 1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that listen per
> > default on the network (unless loopback only) shouldn't be started per
> > default, after being insta
On Tue, May 7, 2013 02:55, Christoph Anton Mitterer wrote:
> On Mon, 2013-05-06 at 14:59 -0600, Bob Proulx wrote:
>> > 1) We should try to educate users not to use mod_php.
>> If "Best Practices" such as this were documented such as on the Debian
>> wiki then it would go a long way to making this e
Raphael Hertzog writes:
>> provided as a hook. You also might want to look at the
>> policyrcd-script-zg2 package.
>>
> Except for chroots that do not run the boot-time scripts, this mechanism
> is mostly useless. /etc/init.d/rc doesn't know about policy-rc.d and thus
> you can't use it to disable
classic
> binNMU should stay of course)
I would like to see the elimination of "ENABLE"-style variables in
/etc/default snippets, to enable or disable initscripts, as a jessie
release goal.
These things are ugly, annoying hacks that try to work around the fact
that we can't ship in
On Tue, 2013-05-07 at 10:06:34 +0300, Timo Juhani Lindfors wrote:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584865
>
> discusses a prototype that I internally use. It hooks to policy-rc.d to
> prevent services from starting during package installation and to dpkg
> post-invoke to detect n
On Mon, May 6, 2013 at 2:49 PM, Andreas Beckmann wrote:
> Hi,
>
> now might be the right time to start a discussion about release goals
> for jessie. Here are some points that come into my mind right now (and
> some were already discussed very recently):
>
> * multiarch compatible binNMUs
> * disc
Hi,
On Mon, 06 May 2013 14:49:57 +0200
Andreas Beckmann wrote:
> now might be the right time to start a discussion about release goals
> for jessie.
* xz for default package compression (as I said in last summer :)
* handling release goal/target/task via BTS to clear what is done or not
* ..
Hi Wookey,
On Tue, 7 May 2013 03:04:50 +0100, Wookey wrote:
> (just a decision to leave arch-independent headers in /usr/include and
> move arch-dependent headers to /usr/include/triplet).
Doesn't this limit us to cross-compiling only across Debian architectures? If
we go for a full /usr/include
Hi,
On Mon, 06 May 2013 14:49:57 +0200, Andreas Beckmann wrote:
> now might be the right time to start a discussion about release goals
> for jessie. Here are some points that come into my mind right now (and
> some were already discussed very recently):
http://wiki.debian.org/ReleaseGoals/Remov
Am 07.05.2013 10:10, schrieb Wouter Verhelst:
> I would like to see the elimination of "ENABLE"-style variables in
> /etc/default snippets, to enable or disable initscripts, as a jessie
> release goal.
>
> These things are ugly, annoying hacks that try to work around the
On 05/07/2013 04:11 AM, Vincent Lefevre wrote:
> This doesn't make any sense. What is installed is a package, not
> a service. There are packages, like rsync, that provide more than
> a service, e.g. a client and a daemon. What if the user wants the
> client but not the corresponding service (at an
On 05/07/2013 04:00 AM, Vincent Lefevre wrote:
> This can be fine for some daemons/servers. For instance, for a web
> server, displaying a default web page is harmless. But what about a
> mail server? Any default config would probably lead to loss of mail
> if things like virtual alias domains are
On Tue, May 07, 2013 at 02:38:07PM +0200, Stephen Kitt wrote:
> Hi Wookey,
> On Tue, 7 May 2013 03:04:50 +0100, Wookey wrote:
> > (just a decision to leave arch-independent headers in /usr/include and
> > move arch-dependent headers to /usr/include/triplet).
> Doesn't this limit us to cross-comp
On Lunes, 6 de mayo de 2013 13:49:57 Andreas Beckmann wrote:
> Hi,
>
> now might be the right time to start a discussion about release goals
> for jessie. Here are some points that come into my mind right now (and
> some were already discussed very recently):
>
> * multiarch compatible binNMUs
>
+++ Stephen Kitt [2013-05-07 14:38 +0200]:
> Hi Wookey,
>
> On Tue, 7 May 2013 03:04:50 +0100, Wookey wrote:
> > (just a decision to leave arch-independent headers in /usr/include and
> > move arch-dependent headers to /usr/include/triplet).
>
> Doesn't this limit us to cross-compiling only acro
Wookey wookware.org> writes:
> And you can still use a sysroot and non-multiarch ways of filling it
> if you prefer. I haven't really experimented with mulitarch and
> sysroot at the same time but SFAIK it should work.
I can confirm Multi-Arch doesn’t break traditional cross compilers
as prepar
* Wookey [130507 23:31]:
> The tradeoff is:
> 1) (Move _all_ headers to /usr/include/triplet)
> * Much duplication of installed headers
> * Only one system include dir, which fits current build-system
> expectations
Which would also punish the libraries getting headers correct while
making
+++ Wookey [2013-05-07 22:31 +0100]:
> The tradeoff is:
> 1) (Move _all_ headers to /usr/include/triplet)
> * Much duplication of installed headers
> * Only one system include dir, which fits current build-system
> expectations
>
> 2) (Move only arch-dependent headers to /usr/include/tri
+++ Wookey [2013-05-07 22:31 +0100]:
[right. 3rd attempt at getting this email to make sense. reposting the
whole thing this time, hopefully with no remaining howlers]
+++ Stephen Kitt [2013-05-07 14:38 +0200]:
> Hi Wookey,
>
> On Tue, 7 May 2013 03:04:50 +0100, Wookey wrote:
> > (just a decisi
On 7 May 2013 05:38, Stephen Kitt wrote:
> Hi Wookey,
>
> On Tue, 7 May 2013 03:04:50 +0100, Wookey wrote:
>> (just a decision to leave arch-independent headers in /usr/include and
>> move arch-dependent headers to /usr/include/triplet).
>
> Doesn't this limit us to cross-compiling only across De
On Wed, 8 May 2013 03:57:20 +0100, Wookey wrote:
> +++ Wookey [2013-05-07 22:31 +0100]:
>
> [right. 3rd attempt at getting this email to make sense. reposting the
> whole thing this time, hopefully with no remaining howlers]
>
> +++ Stephen Kitt [2013-05-07 14:38 +0200]:
> > Hi Wookey,
> >
> >
Christoph Anton Mitterer wrote:
> 2) No more packages that bypass the package management system and secure
> apt:
> a) There are still several (typically non-free) packages which download
> stuff from the web, install or at least un-tar it somwhere without
> checking any integrity information that
* Joey Hess , 2013-05-08, 17:53:
(Last I checked, flashplugin-nonfree verified the integrity of its
downloads in a secure way.)
Last I checked, flashplugin-nonfree was unauditable. It downloaded a
script from people.d.o and the ran it. We may never know what the script
did.
--
Jakub Wilk
On Wed, 2013-05-08 at 17:53 -0400, Joey Hess wrote:
> There's nothing stopping you filing a release critical bug
> against any package that does this. I do it whenever I notice
> something doing that.
Obviously :)
The thing is just... we need a way (at least at a social level) to
prevent this from
On Mon, May 06, 2013 at 02:49:57PM +0200, Andreas Beckmann wrote:
> Hi,
>
> now might be the right time to start a discussion about release goals
> for jessie. Here are some points that come into my mind right now (and
> some were already discussed very recently):
>
> * multiarch compatible binNM
On Thu, 9 May 2013 10:10:01 +0200, Mike Hommey wrote:
> On Mon, May 06, 2013 at 02:49:57PM +0200, Andreas Beckmann wrote:
> > Hi,
> >
> > now might be the right time to start a discussion about release goals
> > for jessie. Here are some points that come into my mind right now (and
> > some were
On 06/05/13 13:49, Andreas Beckmann wrote:
> now might be the right time to start a discussion about release goals
> for jessie.
Some random "make things less fragile" ideas, from the packages that
FTBFS with the new GLib[1]:
* Packages intended to reach stable not FTBFSing just because a
funct
On Tue, May 07, 2013 at 09:34:09PM +0100, Noel David Torres Taño wrote:
> On Lunes, 6 de mayo de 2013 13:49:57 Andreas Beckmann wrote:
> > Hi,
> >
> > now might be the right time to start a discussion about release goals
> > for jessie. Here are some points that come into my mind right now (and
>
On Tue, May 07, 2013 at 10:31:10PM +0100, Wookey wrote:
> +++ Stephen Kitt [2013-05-07 14:38 +0200]:
> > Hi Wookey,
> >
> > On Tue, 7 May 2013 03:04:50 +0100, Wookey wrote:
> > > (just a decision to leave arch-independent headers in /usr/include and
> > > move arch-dependent headers to /usr/inclu
On Wed, May 08, 2013 at 11:57:58AM +0200, Stephen Kitt wrote:
> Let me explain where I'm coming from... With MinGW-w64, we have a set of
> compilers, headers and libraries which allow building software targeting
> native Windows, without Cygwin or much in the way of wrappers at all. This is
> defin
On 2013-05-07 23:53:07 +0800, Thomas Goirand wrote:
> On 05/07/2013 04:11 AM, Vincent Lefevre wrote:
> > This doesn't make any sense. What is installed is a package, not
> > a service. There are packages, like rsync, that provide more than
> > a service, e.g. a client and a daemon. What if the user
Maybe we could have a release goal of dropping as many lib32* and lib64*
packages as possible in favor of multi-arch. (And also as many package
dependencies on libc6-[i386|amd64] as possible, which would in addition
mean limiting some packages to arch:i386 if they currently provide a fake
arch:amd
Daniel Schepler (12/05/2013):
> Maybe we could have a release goal of dropping as many lib32* and
> lib64* packages as possible in favor of multi-arch. (And also as
> many package dependencies on libc6-[i386|amd64] as possible, which
> would in addition mean limiting some packages to arch:i386 if
Am 12.05.2013 16:18, schrieb Daniel Schepler:
> Maybe we could have a release goal of dropping as many lib32* and lib64*
> packages as possible in favor of multi-arch. (And also as many package
> dependencies on libc6-[i386|amd64] as possible, which would in addition
> mean limiting some packages
On Sun, May 12, 2013 at 8:06 AM, Matthias Klose wrote:
> Am 12.05.2013 16:18, schrieb Daniel Schepler:
> > Maybe we could have a release goal of dropping as many lib32* and lib64*
> > packages as possible in favor of multi-arch. (And also as many package
> > dependencies on libc6-[i386|amd64] as
]] Vincent Lefevre
> I agree for these services (though Apache is useless after just
> being installed, as one just has a dummy web page).
So useful, since you can then put files into the docroot and serve those
files. (An analogy to your example could be an imap server being
useless, since ther
Hi Vincent,
Vincent Lefevre writes:
...
> I agree for these services (though Apache is useless after just
> being installed, as one just has a dummy web page). But not for
> postfix, which can reject mail by default without an initial
> configuration. Since it is not working by default, and loses
+++ Daniel Schepler [2013-05-12 09:19 -0700]:
>On Sun, May 12, 2013 at 8:06 AM, Matthias Klose <[1]d...@debian.org>
>wrote:
>
> �- find a solution that GCC's b-d's may not be installable anymore with
> � �the current approach to binNMUs.
>
>OK, that's a good point that I had
On Mon, May 13, 2013 at 1:01 AM, Philip Hands wrote:
> I don't know about you, but I find it quite reassuring to be able to
> confirm that the first half of an install is going pretty well when I
> get to see the "useless" dummy page from Apache. I'd imagine someone
> installing their first web s
On May 12, 2013, at 2:49 PM, Wookey wrote:
> +++ Daniel Schepler [2013-05-12 09:19 -0700]:
>> On Sun, May 12, 2013 at 8:06 AM, Matthias Klose <[1]d...@debian.org>
>> wrote:
>>
>> �- find a solution that GCC's b-d's may not be installable anymore with
>> � �the current approach to bi
Paul Wise writes:
> On Mon, May 13, 2013 at 1:01 AM, Philip Hands wrote:
>
>> I don't know about you, but I find it quite reassuring to be able to
>> confirm that the first half of an install is going pretty well when I
>> get to see the "useless" dummy page from Apache. I'd imagine someone
>> i
On Mon, May 13, 2013 at 5:20 PM, Philip Hands wrote:
> It looks to me as though your apache and rsyncd suggestions are straying
> into the forbidden territory of using debconf as a registry.
I didn't advocate storing such info in debconf.
PS: I'm subscribed.
--
bye,
pabs
http://wiki.debian.or
On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote:
> ]] Vincent Lefevre
>
> > I agree for these services (though Apache is useless after just
> > being installed, as one just has a dummy web page).
>
> So useful, since you can then put files into the docroot and serve those
> files.
But the a
]] Vincent Lefevre
> On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote:
> > ]] Vincent Lefevre
> > > But not for postfix, which can reject mail by default without an
> > > initial configuration. Since it is not working by default, and loses
> > > mail, the daemon shouldn't be enabled by default.
On 2013-05-07 23:54:36 +0800, Thomas Goirand wrote:
> On 05/07/2013 04:00 AM, Vincent Lefevre wrote:
> > This can be fine for some daemons/servers. For instance, for a web
> > server, displaying a default web page is harmless. But what about a
> > mail server? Any default config would probably lead
Vincent Lefevre writes:
> On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote:
>> ]] Vincent Lefevre
>>
>> > I agree for these services (though Apache is useless after just
>> > being installed, as one just has a dummy web page).
>>
>> So useful, since you can then put files into the docroot a
On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote:
> ]] Vincent Lefevre
>
> > On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote:
> > > ]] Vincent Lefevre
> > > > But not for postfix, which can reject mail by default without an
> > > > initial configuration. Since it is not working by default,
]] Vincent Lefevre
> On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote:
> > ]] Vincent Lefevre
> >
> > > On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote:
> > > > ]] Vincent Lefevre
> > > > > But not for postfix, which can reject mail by default without an
> > > > > initial configuration. S
On 2013-05-13 12:02:31 +0100, Philip Hands wrote:
> Vincent Lefevre writes:
> > My only use of Apache on some machine is because of sensord. But
> > it may happen that in a few months, I would no longer need sensord
> > and may remove the package. In this case, it would make sense to
> > stop the
On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote:
> ]] Vincent Lefevre
>
> > On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote:
> > > So you configured it through debconf, in a non-default way, and it
> > > refused mails according to how you configured it.
> >
> > AFAIK, debconf is the *onl
]] Vincent Lefevre
> On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote:
> > ]] Vincent Lefevre
> >
> > > On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote:
> > > > So you configured it through debconf, in a non-default way, and it
> > > > refused mails according to how you configured it.
>
On 05/13/2013 08:33 AM, Tollef Fog Heen wrote:
]] Vincent Lefevre
On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote:
No, it does not, since the default configuration («Local only»)
sets
This is not the default configuration, just the default choice (it
is not written "Default configurat
Vincent Lefevre writes:
> On 2013-05-13 12:02:31 +0100, Philip Hands wrote:
>> Vincent Lefevre writes:
>> > My only use of Apache on some machine is because of sensord. But
>> > it may happen that in a few months, I would no longer need sensord
>> > and may remove the package. In this case, it w
On Mon, May 13, 2013 at 7:33 PM, Vincent Lefevre wrote:
> Yes, but similarly, there's no way to do this automatically.
apt-get autoremove is automatic, or if you want that earlier you could
remove sensord using aptitude which will automatically remove unused
dependencies.
> There's also a proble
On 2013-05-13 08:48:33 -0400, The Wanderer wrote:
> On 05/13/2013 08:33 AM, Tollef Fog Heen wrote:
>
> >]] Vincent Lefevre
> >
> >>On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote:
>
> >>>No, it does not, since the default configuration («Local only»)
> >>>sets
> >>
> >>This is not the default
On 2013-05-13 14:37:28 +0100, Philip Hands wrote:
> Vincent Lefevre writes:
> > There's also a problem that the man pages are in the package:
> >
> > $ dpkg -L apache2.2-common | grep /man/
> > /usr/share/man/man8
> > /usr/share/man/man8/apache2.8.gz
> > /usr/share/man/man8/a2ensite.8.gz
> > /usr/
On 2013-05-13 16:26:58 +0200, Vincent Lefevre wrote:
> One could imagine the same thing but with testing directories...
> Something like in the /etc/default/ file:
>
> test -f some_dir || ENABLED=0
>
> But this method needs an "ENABLED" variable!
Actually, that would be more like
ENABLED=0
test
On 2013-05-13 21:42:20 +0800, Paul Wise wrote:
> On Mon, May 13, 2013 at 7:33 PM, Vincent Lefevre wrote:
> > Yes, but similarly, there's no way to do this automatically.
>
> apt-get autoremove is automatic, or if you want that earlier you could
> remove sensord using aptitude which will automatica
Le lundi 13 mai 2013 15:37:28, Philip Hands a écrit :
>
> If you must see the man page from a particular package:
>
> dget apache2.2-common
> mkdir -p ./tmp/apache2.2-common
> dpkg -X apache2.2-common_2.2.22-13_amd64.deb ./tmp/apache2.2-common
JTYI, you could also use debman -p apache2.2-c
On Sat, 11 May 2013 11:39:28 +0200, Goswin von Brederlow
wrote:
> On Wed, May 08, 2013 at 11:57:58AM +0200, Stephen Kitt wrote:
> > The big issue which crops up then isn't so much the directory structure's
> > impact on the build process, but rather its impact on the packaging
> > process. If the
On 13/05/13 18:26, Stephen Kitt wrote:
> Yes, but that's not the problem. Take the premise that the target
> directory structure is as described above, so most library
> development packages ship as many headers as possible in
> /usr/include. For now we'll assume all mingw-w64-...-dev headers
> are
On Mon, May 13, 2013 at 10:36 PM, Vincent Lefevre wrote:
> But there isn't a dependency (and currently all the config needs
> to be done manually, as described in the sensord(8) man page).
> So, this won't work.
That sounds like a suboptimal package,
--
bye,
pabs
http://wiki.debian.org/PaulWis
On 13-05-13 05:59, Mark Symonds wrote:
> Can we keep the distribution simple enough for nearly anyone to understand?
No.
The goal of Debian is not to be "simple". While we should document
things as much as possible so that the interested can learn how things
work, in no case should we ever avoi
Quoting Wouter Verhelst (2013-05-14 12:22:14)
> On 13-05-13 05:59, Mark Symonds wrote:
> > Can we keep the distribution simple enough for nearly anyone to
> > understand?
>
> No.
>
> The goal of Debian is not to be "simple". While we should document
> things as much as possible so that the inte
On Tue, May 7, 2013 at 9:06 AM, Thijs Kinkhorst wrote:
> I suggest that you file a bug against php5 with suggested changes and we can
> discuss the pros and cons of each for jessie.
And I must add that I consider very rude to push your (sometimes
extreme, sometimes very usefull) ideas how should
On Mon, May 13, 2013 at 07:26:15PM +0200, Stephen Kitt wrote:
> On Sat, 11 May 2013 11:39:28 +0200, Goswin von Brederlow
> wrote:
> > On Wed, May 08, 2013 at 11:57:58AM +0200, Stephen Kitt wrote:
> > > The big issue which crops up then isn't so much the directory structure's
> > > impact on the bu
Paul Wise wrote:
> Probably the rsync package should just ask you via debconf if you want
> to serve any directories and what their names and paths should be.
> Since most folks who have rsync installed don't need rsyncd, the
> default would be to not setup anything.
No, it should not. 60 packages
+++ Stephen Kitt [2013-05-13 19:26 +0200]:
> Yes, but that's not the problem. Take the premise that the target directory
> structure is as described above, so most library development packages ship as
> many headers as possible in /usr/include. For now we'll assume all
> mingw-w64-...-dev headers
On 05/13/2013 07:08 PM, Vincent Lefevre wrote:
> On 2013-05-07 23:54:36 +0800, Thomas Goirand wrote:
>> On 05/07/2013 04:00 AM, Vincent Lefevre wrote:
>>> This can be fine for some daemons/servers. For instance, for a web
>>> server, displaying a default web page is harmless. But what about a
>>> m
Philip Hands wrote:
> Vincent Lefevre writes:
> > I agree for these services (though Apache is useless after just
> > being installed, as one just has a dummy web page).
>
> I don't know about you, but I find it quite reassuring to be able to
> confirm that the first half of an install is going pr
1 - 100 of 388 matches
Mail list logo
