> It's supposed to represent everyone who fights for a future where software is
> open
Is it possible? To reopresent everyone.
Shouldn't he instead represent that he's expected to represent?
>From the fsf.org:
>8
...
Our Core Work
The FSF maintains historic articles covering free soft
On Fri, Mar 26, 2021 at 02:08:34PM +0100, Pierre-Elliott Bécue wrote:
> I'm not trying to refrain you from leaving
Well, lets I'll try last time to make things clear as much as I can.
1) Don't get me wrong, this is the end of story, started not today.
2) It's not something like "this hurts me, pl
Hello,
I don't want to be associated with the organization, being part of the
witch hunt like this one https://rms-open-letter.github.io/.
Unfortunately, it seems the only option to be not involved in all
that - leave the Debian project.
I've seen how many DD's were present in this and how well t
On Mon, Feb 29, 2016 at 06:02:40PM +0100, Andrew Shadura wrote:
> there are no releases of non-release architectures
AFAIK, there is no defined release archs for stretch yet, so
"non-release arch" doesn't make sense before freeze.
But the whole point was not about severity. One maintainer
clearl
On Mon, Feb 29, 2016 at 05:22:19PM +0100, Michael Banck wrote:
> It pretty clearly says:
>
> | serious; is a severe violation of Debian policy (roughly, it violates
> | a "must" or "required" directive), or, in the package maintainer's or
> | release manager's opinion, makes the package unsuitable
On Mon, Feb 29, 2016 at 03:56:57PM +0100, Ondřej Surý wrote:
> I simply cannot fix
I'm not about requesting a fix from you. Just about accepting that
there is a problem ("We won't hide problems", remember?). But it seems
you know better how to do the work and I'm just in a wrong place
as a co-ma
On Thu, Jun 26, 2014 at 01:00:12PM +0200, Ondřej Surý wrote:
> 3. We remove the source packages from Debian.
Can you kindly explain why? Is the PHP license is non-free? If so,
why? If not - let's lower the bugs severity.
I see only *one* reply from debian-legal here:
https://lists.debian.org/d
On Sun, Feb 16, 2014 at 10:19:24PM +0100, Wouter Verhelst wrote:
> On Sun, Feb 16, 2014 at 03:28:30PM +0400, Sergey B Kirpichev wrote:
> > Kevin Chadwick :
> > >> Doesn't matter) rc.local shouldn't be used by local
> > >> admin to start services from. W
Petter Reinholdtsen :
>> Probably, we should have hooks, that can be invoked before specified
>> action (e.g. start or stop) and after. But not just for start/stop.
>
> I already got most of these hooks. Are more needed?
I think, for every action, mentioned in the LSB. But
that's a minor issue.
Kevin Chadwick :
>> Doesn't matter) rc.local shouldn't be used by local
>> admin to start services from. Why not use usual init-script?
>
> I wouldn't be surprised if rc.local has been around longer than Debian
> and is meant to run at the end. Particularly for a service that isn't
> packaged it
On Sat, Feb 08, 2014 at 01:41:18AM +0900, hero...@gentoo.org wrote:
> Sergey B Kirpichev writes:
>
> > http://packages.qa.debian.org/m/monit.html
> > Usually, you want to start this service last and stop first.
>
> The question is, before or after rc.local?
Doesn'
> I'm pointing out why $all doesn't do what you want.
It's exactly what I want.
> «$all» means «after everything else has started» and if you
> have two of those
You have a bug. Yes, some packages abuse $all, I admit this,
but not all of them (e.g. monit).
> In your particular case (and sysvin
> An init system that doesn't handle the case of something going «please
> start $service» when it's already in the process of starting that
> service, is buggy.
It's not the problem, as all (most) debian's init-scripts use
start-stop-daemon. The real problem - email notifications. You don't
wan
>> Usually, you want to start this service last and stop first.
>
> Why should it start last?
Because monit is not systemd. monit - is only an utility for
proactive monitoring, not yet another init-replacement.
So, lets start services first, then start monitoring. Do
we want to play races with
> $all obviously (as you point out) doesn't work well. Semantically, it
> doesn't make sense to have more than one script depending on $all.
What I should use instead? Use case:
http://packages.qa.debian.org/m/monit.html
Usually, you want to start this service last and stop first.
--
To UNSUBS
>> Peter, thank you for your work. Have you tried any complex init
>> script to fit this business (apache2 or postfix, for example)?
>
> Nope. It is ment as an option for the packages with simple needs.
> Those with complex needs can use it too, probably, but it might be
> easier to just keep the
> Where can I read more about these problems. One obvious and annoying
> one is that 'sh -x /etc/init.d/script start' no longer work, making it
> harder to debug the scripts
Probably init-d-script could pass some cli-specified options to sh
with set builtin. To allow something like this:
/etc/i
> I think this illustrates nicely the problem with this approach:
> - there are two lines, which contain code.
> - there are five commented lines, which are interpreted and contain important
> data.
> - and there are four lines of commented code, which are mostly comments,
> except two.
And yet
>> You don’t want anything like these in your local init service. For such
>> tests you have Nagios, Icinga or similiar daemons. And they can do much
>> deeper checks, e.g. can you login into your webservice because your
>> database backend on a different server is available.
>
> Once your monit
Package: debian-maintainers
This is my annual ping.
CC'd to debian-devel@, as d-m pseudo-package has lots of stalled
"annual ping" reports. Are we have need in such kind of bureaucracy?
signature.asc
Description: Digital signature
Package: wnpp
Severity: wishlist
Owner: Sergey B Kirpichev
* Package name: parser3-mysql
Version : 10.0
Upstream Author : Alexandr Petrosian
* URL : http://www.parser.ru/en/download/src/
* License : GPL-2+
Programming Lang: C++
Description : MySQL
Package: wnpp
Severity: wishlist
Owner: Sergey B Kirpichev
* Package name: parser3
Version : 3.3.0
Upstream Author : Alexandr Petrosian
* URL : http://www.parser.ru/en/
* License : GPL2+
Programming Lang: C++
Description : Parser 3, HTML-embedded
Package: wnpp
Severity: wishlist
Owner: Sergey B Kirpichev <[EMAIL PROTECTED]>
* Package name: php5-geoip
Version : 1.0.2
* URL : http://pecl.php.net/package/geoip
* License : PHP
Programming Lang: C
Description : This package provides a modu
23 matches
Mail list logo