Re: Re: Cancel "culture" is a threat to Debian

2021-03-30 Thread Sergey B Kirpichev
> 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

Re: I'm orphan my packages and leave the project as maintainer

2021-03-26 Thread Sergey B Kirpichev
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

I'm orphan my packages and leave the project as maintainer

2021-03-25 Thread Sergey B Kirpichev
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

Re: [Pkg-php-pecl] Bug#816265: Bug#816265: Bug#816265: Bug#816265: php-geoip: FTBFS: libtool: No such file or directory

2016-02-29 Thread Sergey B Kirpichev
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

Re: [Pkg-php-pecl] Bug#816265: Bug#816265: Bug#816265: Bug#816265: php-geoip: FTBFS: libtool: No such file or directory

2016-02-29 Thread Sergey B Kirpichev
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

Re: [Pkg-php-pecl] Bug#816265: Bug#816265: Bug#816265: Bug#816265: php-geoip: FTBFS: libtool: No such file or directory

2016-02-29 Thread Sergey B Kirpichev
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

Re: Bug#752532: Sources licensed under PHP License and not being PHP are not distributable

2014-06-26 Thread Sergey B Kirpichev
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

Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

2014-02-18 Thread Sergey B Kirpichev
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

Re: Re: Two line init.d scripts? Sure, that will work!

2014-02-16 Thread Sergey B Kirpichev
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.

Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

2014-02-16 Thread Sergey B Kirpichev
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

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

2014-02-07 Thread Sergey B Kirpichev
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'

Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

2014-02-06 Thread Sergey B Kirpichev
> 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

Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

2014-02-06 Thread Sergey B Kirpichev
> 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

Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

2014-02-06 Thread Sergey B Kirpichev
>> 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

Re: Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

2014-02-06 Thread Sergey B Kirpichev
> $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

Re: Re: Two line init.d scripts? Sure, that will work!

2014-02-06 Thread Sergey B Kirpichev
>> 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

Re: Re: Two line init.d scripts? Sure, that will work!

2014-02-06 Thread Sergey B Kirpichev
> 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

Re: Two line init.d scripts? Sure, that will work!

2014-02-06 Thread Sergey B Kirpichev
> 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

Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

2013-12-23 Thread Sergey B Kirpichev
>> 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

Annual ping for Sergey B Kirpichev

2013-02-28 Thread Sergey B Kirpichev
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

Bug#521654: ITP: parser3-mysql -- MySQL driver for Parser 3

2009-03-29 Thread Sergey B Kirpichev
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

Bug#519574: ITP: parser3 -- Parser 3, HTML-embedded scripting language

2009-03-13 Thread Sergey B Kirpichev
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

Bug#478051: ITP: php5-geoip -- This package provides a module for Maxmind's GeoIP functions in PHP

2008-04-26 Thread Sergey B Kirpichev
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