Marco d'Itri wrote:
> This has been happening more and more after SuSE has become irrelevant.
>
> I will cite just a few simple examples:
> - no good strategy to prevent lockstep udev/kernel upgrades, since RHEL
> does not support upgrading to the next major release
> - configuration files in /
On Sun, 2012-04-29 at 23:48 +0200, Carsten Hey wrote:
> * Svante Signell [2012-04-29 21:51 +0200]:
> > In line with the recent discussion, lets aim at defining what _boot_ is:
>
> I'm rather sure that he wants to define booting as part of what
> currently is done in /etc/rcS.d. Configuring the ne
]] Bernd Zeimetz
> You actually want to start your iscsi stuff even your network is not
> available right now - and you for sure don't want to stop it just
> because the link flaps.
You need to wait for the right IP to become available so it can bind to
the right place. And why would you stop n
Bernd Zeimetz writes:
>> Er, what? Please don't throw out silly strawmen...
>
> Stephan's points are valid. Just having a link on your favourite cisco does
> not
> mean that you are allowed to send packets anywhere yet. Getting a ipv6 address
> via radvd does not mean that you are able too acce
Le Thu, Mar 08, 2012 at 12:26:46AM +0900, Charles Plessy a écrit :
>
> Thanks (and thanks Cyril) for the hint. Still there are two things
> I do not understand:
>
> - Why and when it is a problem to add preprocessor flags in CFLAGS.
>
> - Why we chose the solution that require more extensive
Package: wnpp
Severity: wishlist
Owner: Alessio Treglia
* Package name: volti
Version : 0.2.3
Upstream Author : Milan Nikolic
* URL : http://code.google.com/p/volti/
* License : GPL
Programming Lang: Python
Description : control audio volume from syste
Adam Borowski writes:
> On Sun, Apr 29, 2012 at 10:50:45PM +0200, Carsten Hey wrote:
>> Looks like the DragonFly Mail Agent (dma), which already has been
>> mentioned in this thread, could become a decent default for Wheezy+1
>> after some small changes.
>>
>> In a nutshell: it's able to deliver
On Sun, Apr 29, 2012 at 10:50:45PM +0200, Carsten Hey wrote:
> Looks like the DragonFly Mail Agent (dma), which already has been
> mentioned in this thread, could become a decent default for Wheezy+1
> after some small changes.
>
> In a nutshell: it's able to deliver locally and remotely, has a qu
On 30/04/2012 03:51, Svante Signell wrote:
> - starting up the network: yes if network booting, other things can be
> done later.
> - starting an MTA: no
> - staring sshd: no
On my remotely administered Debian server, these three are *definitely* part of
the boot process, and it's not network boot
On Sun, Apr 29, 2012 at 11:11:08PM +0200, Svante Signell wrote:
> On Sun, 2012-04-29 at 21:52 +0100, Ben Hutchings wrote:
> > On Sun, Apr 29, 2012 at 09:51:37PM +0200, Svante Signell wrote:
> > > Hello,
> > >
> > > In line with the recent discussion, lets aim at defining what _boot_ is:
> > [...]
Marco d'Itri wrote:
> I am on friendly terms with many Red Hat people, but it is a fact that
> they take design decisions which are aligned with the needs of RHEL
> and these needs are often far from what is good for other distributions.
> - configuration files in /etc/ overriding configuration
* Svante Signell [2012-04-29 21:51 +0200]:
> In line with the recent discussion, lets aim at defining what _boot_ is:
I'm rather sure that he wants to define booting as part of what
currently is done in /etc/rcS.d. Configuring the network or mounting
non-essential remote file systems wouldn't be
Package: wnpp
Severity: wishlist
Owner: Thomas Mueller
* Package name: php-sabredav
Version : 1.6.2
Upstream Author : Evert Pot
* URL : http://www.http://sabredav.org/
* License : BSD
Programming Lang: php
Description : SabreDAV allows you to easily ad
Roger Leigh wrote:
> One of the definining characteristics of the Linux ecosystem, including
> Debian, has been that the system has been made up of a set of loosely-
> coupled compoments with well-defined interfaces. This is in stark
> contrast to, e.g. Windows, MacOS and other proprietary systems
On Apr 29, Jonathan Nieder wrote:
> Red Hat employs some eminently friendly and reasonable people.
I am on friendly terms with many Red Hat people, but it is a fact that
they take design decisions which are aligned with the needs of RHEL
and these needs are often far from what is good for other
On Sun, 2012-04-29 at 21:52 +0100, Ben Hutchings wrote:
> On Sun, Apr 29, 2012 at 09:51:37PM +0200, Svante Signell wrote:
> > Hello,
> >
> > In line with the recent discussion, lets aim at defining what _boot_ is:
> [...]
>
> No, let's not. Beyond RAM, CPU, IRQ controllers and timers (all
> of w
Package: wnpp
Severity: wishlist
Owner: Thilo Uttendorfer
* Package name: logsurfer
Version : 1.8
Upstream Author : Kerry Thompson
* URL : http://www.crypt.gen.nz/logsurfer/
* License : BSD
Programming Lang: C
Description : Monitoring system logs in re
* Joey Hess [2012-04-29 14:22 -0400]:
> Joerg Jaspert wrote:
> > It's insane to even think of switching one full featured MTA against
> > another full featured one. It feels like "gosh, i dislike $onepiece,
> > lets all move to $differentpiece", though both are bad as default.
Looks like the Drago
On Sun, Apr 29, 2012 at 5:14 PM, Roger Leigh wrote:
> Keeping our options open, and evaluating what are options are
> available and usable is important, and this is the principal reason
> why I am interested in looking at OpenRC. It doesn't hurt to try it
> out and see if it meets our needs.
Agr
On Sun, Apr 29, 2012 at 09:51:37PM +0200, Svante Signell wrote:
> Hello,
>
> In line with the recent discussion, lets aim at defining what _boot_ is:
[...]
No, let's not. Beyond RAM, CPU, IRQ controllers and timers (all
of which are part of the kernel's early initialisation) pretty
much all of t
Svante Signell wrote:
> In line with the recent discussion, lets aim at defining what _boot_ is:
Why? Unless you are suggesting documentation is unclear, I don't see
how this has any impact on the development of Debian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
On Sun, 2012-04-29 at 03:13 +0200, Marco d'Itri wrote:
> Is this the right time to do it?
I'd vote for it :)
Or better said for depending on a default-mta which is going to be
postifx, as already outlined.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On Sun, Apr 29, 2012 at 08:19:44PM +0200, Marco d'Itri wrote:
> On Apr 29, Roger Leigh wrote:
>
> > While sysvinit is clearly inferior, it gives us (Debian) something the
> > others do not: control over our own destiny, and the ability to
> > modify every aspect of it and the init scripts to fit
Hello,
In line with the recent discussion, lets aim at defining what _boot_ is:
- initializing the RAM: yes
- initializing the CPU(s): yes
- loading the kernel: yes
- initializing the graphics card: yes for text mode, graphics mode can
come later
- initializing the HDD(s): yes, if boot devices.
-
Marco d'Itri wrote:
> We can all be "uneasy" about it until we are blue in the face, but since
> Red Hat maintains most Linux core components and we do not, there is not
> much we can do about it.
I'll repeat what I said last time you made this (in my opinion
strange) argument:
Red Hat employs
On Sun, Apr 29, 2012 at 2:45 PM, Roger Leigh wrote:
> One of the definining characteristics of the Linux ecosystem, including
> Debian, has been that the system has been made up of a set of loosely-
> coupled compoments with well-defined interfaces. This is in stark
> contrast to, e.g. Windows, M
On Sun, 2012-04-29 at 20:19 +0200, Marco d'Itri wrote:
> On Apr 29, Roger Leigh wrote:
>
> > I hope I'm not alone in feeling quite uneasy about the implications
> > of the above.
> We can all be "uneasy" about it until we are blue in the face, but since
> Red Hat maintains most Linux core compon
On Apr 29, Roger Leigh wrote:
> I hope I'm not alone in feeling quite uneasy about the implications
> of the above.
We can all be "uneasy" about it until we are blue in the face, but since
Red Hat maintains most Linux core components and we do not, there is not
much we can do about it.
> While
Joerg Jaspert wrote:
> It's insane to even think of switching one full featured MTA against
> another full featured one. It feels like "gosh, i dislike $onepiece,
> lets all move to $differentpiece", though both are bad as default.
Yeah, Debian has certianly never done that before ..
(Remember sma
On Sun, Apr 29, 2012 at 03:59:03PM +0200, Stephan Seitz wrote:
> On Sun, Apr 29, 2012 at 10:33:16PM +0900, Miles Bader wrote:
> >Isn't mounting filesystems, which can depend on the network, part of
> >the boot process?
> Yes, but how do you check if the network is configured and operational?
> - w
On Thu, Apr 26, 2012 at 01:42:48PM +0100, Roger Leigh wrote:
> I'm going to investigate it in more detail on a running Gentoo system
> and learn a bit more about it before doing anything. If anyone fancies
> doing the packaging, I'll be happy to join in. I'll probably be able
> to provide a bette
On Fri, Apr 27, 2012 at 08:49:24AM +0200, Adrian Knoth wrote:
> On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
>
> > I believe Debian still supports running locally compiled kernels which
> > do not depend on udev, and that some setups do not require udev either
> > (not every
On 12831 March 1977, Marco d'Itri wrote:
> Is this the right time to do it?
No.
It never will be.
It's insane to even think of switching one full featured MTA against
another full featured one. It feels like "gosh, i dislike $onepiece,
lets all move to $differentpiece", though both are bad as de
On Sun, Apr 29, 2012 at 07:16:18PM +0200, Marco d'Itri wrote:
> > The giant endless flamewars on debian-devel required to make a decision to
> > change anything. :)
> IIRC, last time we discussed this I think that even the exim maintainers
> were in favour of the change...
What were the reasons?
On Apr 29, Russ Allbery wrote:
> The giant endless flamewars on debian-devel required to make a decision to
> change anything. :)
Unrelated: you have just shown what poisons Debian and has been keeping
us behind innovation for the last years.
Not the flamewars themselves, most of us are grown u
On Sun, Apr 29, 2012 at 19:08:56 +0200, Raphael Hertzog wrote:
> On Sun, 29 Apr 2012, Julien Cristau wrote:
> > The 500 packages that would have to change their Depends from "exim4 |
> > mta" to something else.
>
> We're already on our way to update them with "default-mta |
> mail-transport-agent
On Apr 29, Russ Allbery wrote:
> > What kind of disruption are you thinking about?
> Existing users who are familiar with Exim and who would get Postfix on a
> new install and be surprised.
This does not really look like a big surprise.
If somebody is familiar enough with Exim to modify the defau
On Sun, 29 Apr 2012, Julien Cristau wrote:
> The 500 packages that would have to change their Depends from "exim4 |
> mta" to something else.
We're already on our way to update them with "default-mta |
mail-transport-agent".
That would provide an incentive to finish converting the dependencies :-
Julien Cristau writes:
> The 500 packages that would have to change their Depends from "exim4 |
> mta" to something else.
Well, it would be nice to change all of those to depend on default-mta |
mail-transport-agent anyway, but yeah. Making that low-priority change
urgent would be sort of annoy
On Sun, Apr 29, 2012 at 07:03:11PM +0200, Julien Cristau wrote:
> The 500 packages that would have to change their Depends from "exim4 |
> mta" to something else.
The brokenness of having to have a default package hardcoded in
every virtual dependency rather than having a virtual defaults
package
On Sun, Apr 29, 2012 at 09:58:14 -0700, Russ Allbery wrote:
> m...@linux.it (Marco d'Itri) writes:
> > On Apr 29, Russ Allbery wrote:
>
> >> desires. The disruption doesn't seem worth it even if we had consensus
>
> > What kind of disruption are you thinking about?
>
> Existing users who are
m...@linux.it (Marco d'Itri) writes:
> On Apr 29, Russ Allbery wrote:
>> desires. The disruption doesn't seem worth it even if we had consensus
> What kind of disruption are you thinking about?
Existing users who are familiar with Exim and who would get Postfix on a
new install and be surprise
OoO Pendant le repas du samedi 28 avril 2012, vers 19:54, Thomas Goirand
disait :
>> We are in 2012 and if a non-essential daemon blocks the boot (no working
>> network), we have no way to get a getty to be run.
>>
> I agree with the rest of your post, but here, you are are
> picturing a very ba
OoO En cette fin de matinée radieuse du dimanche 29 avril 2012, vers
11:25, Svante Signell disait :
>> But that's the whole point : new hardware pops up while booting. See for
>> example a server that will need a 3G connection. The 3G connection will
>> be done by some classic USB key. Wh
On Sun, 2012-04-29 at 16:26 +0200, Bernd Zeimetz wrote:
> On 04/29/2012 04:11 PM, Ben Hutchings wrote:
> > On Sun, 2012-04-29 at 14:59 +0200, Bernd Zeimetz wrote:
> >> On 04/27/2012 03:28 AM, Ben Hutchings wrote:
> >>> On Fri, 2012-04-27 at 08:55 +0800, Patrick Lauer wrote:
> On 04/27/12 03:32
On Apr 29, Harald Jenny wrote:
> Agreed but how long would it take to fix the policy vs how long would it
> take to produce this package in the face of next stable release?
The current situation does not even cause any practical problems, just
a policy violation.
--
ciao,
Marco
signature.asc
On Sun, Apr 29, 2012 at 04:23:25PM +0200, Marco d'Itri wrote:
> On Apr 29, Harald Jenny wrote:
>
> > Wouldn't this solve the whole dilemma in a policy compliant and easy
> > enough fashion that it could be used or what error is there in my idea?
> If fixing a real world problem requires so much o
On 04/29/2012 04:18 PM, Miles Bader wrote:
> Stephan Seitz writes:
>>> Isn't mounting filesystems, which can depend on the network, part of
>>> the boot process?
>>
>> Yes, but how do you check if the network is configured and operational?
>> - when the link is up?
>> - when the IP address is conf
On 04/29/2012 04:11 PM, Ben Hutchings wrote:
> On Sun, 2012-04-29 at 14:59 +0200, Bernd Zeimetz wrote:
>> On 04/27/2012 03:28 AM, Ben Hutchings wrote:
>>> On Fri, 2012-04-27 at 08:55 +0800, Patrick Lauer wrote:
On 04/27/12 03:32, Adam Borowski wrote:
> On Thu, Apr 26, 2012 at 08:08:01PM +0
On Apr 29, Russ Allbery wrote:
> desires. The disruption doesn't seem worth it even if we had consensus
What kind of disruption are you thinking about?
--
ciao,
Marco
signature.asc
Description: Digital signature
On Apr 29, Harald Jenny wrote:
> Wouldn't this solve the whole dilemma in a policy compliant and easy
> enough fashion that it could be used or what error is there in my idea?
If fixing a real world problem requires so much overhead because of
policy concerns then it looks like the policy needs
Stephan Seitz writes:
>>Isn't mounting filesystems, which can depend on the network, part of
>>the boot process?
>
> Yes, but how do you check if the network is configured and operational?
> - when the link is up?
> - when the IP address is configured (how do you check this with
> IPv6?)? What ar
On Sat, Apr 28, 2012 at 08:39:41PM +0200, Jonas Smedegaard wrote:
> On 12-04-28 at 01:50pm, Joey Hess wrote:
> > Jonas Smedegaard wrote:
> > > As I understand the current status, it has already on this list been
> > > resolved that *both* packages should back off from using the
> > > clashing nam
On Sun, 2012-04-29 at 14:59 +0200, Bernd Zeimetz wrote:
> On 04/27/2012 03:28 AM, Ben Hutchings wrote:
> > On Fri, 2012-04-27 at 08:55 +0800, Patrick Lauer wrote:
> >> On 04/27/12 03:32, Adam Borowski wrote:
> >>> On Thu, Apr 26, 2012 at 08:08:01PM +0100, Ben Hutchings wrote:
> On Thu, Apr 26,
On Sun, Apr 29, 2012 at 10:33:16PM +0900, Miles Bader wrote:
Isn't mounting filesystems, which can depend on the network, part of
the boot process?
Yes, but how do you check if the network is configured and operational?
- when the link is up?
- when the IP address is configured (how do you chec
Package: wnpp
Severity: wishlist
Owner: Jan Dittberner
* Package name: python-cliff
Version : 0.4
Upstream Author : Doug Hellmann
* URL : https://github.com/dreamhost/cliff
* License : Apache License 2.0
Programming Lang: Python
Description : command l
Svante Signell writes:
> So, the
> real problem is: How do you define the boot process of a computer. For
> me it is when the kernel has been loaded by the boot media, memory,
> graphics card, etc initialized. Some modules are needed for boot, other
> modules can be loaded later. The only case I c
On 04/27/2012 03:28 AM, Ben Hutchings wrote:
> On Fri, 2012-04-27 at 08:55 +0800, Patrick Lauer wrote:
>> On 04/27/12 03:32, Adam Borowski wrote:
>>> On Thu, Apr 26, 2012 at 08:08:01PM +0100, Ben Hutchings wrote:
On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote:
> I believe
On 04/27/2012 07:33 PM, Tollef Fog Heen wrote:
> ]] Martin Wuertele
>
>> * Josselin Mouette [2012-04-27 09:53]:
>>
>>> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit :
> Yes of course, because event-driven init systems have *always* been
> *only* about mounting USB devices
On Sun, 29 Apr 2012 12:05:06 +0300, Andrei POPESCU
wrote:
On Sb, 28 apr 12, 19:12:42, Russ Allbery wrote:
There's nothing particularly wrong with Exim; it works just fine.
It's
been the default in Debian for years, and it's actively maintained
upstream. And it's completely trivial to repla
On Sat, 2012-04-28 at 02:29 +0200, Vincent Bernat wrote:
> OoO Vers la fin de l'après-midi du vendredi 27 avril 2012, vers 16:29,
> Svante Signell disait :
>
> > Apparently it can today ... with init scripts, which _new_ features will
> > be brought in for the _boot_ process. udev takes care of
On Sb, 28 apr 12, 19:12:42, Russ Allbery wrote:
>
> There's nothing particularly wrong with Exim; it works just fine. It's
> been the default in Debian for years, and it's actively maintained
> upstream. And it's completely trivial to replace it with Postfix if one
> desires. The disruption doe
62 matches
Mail list logo
