[DRE-maint] Processing of ruby-safe-yaml_1.0.4-1_amd64.changes

2015-06-25 Thread Debian FTP Masters
ruby-safe-yaml_1.0.4-1_amd64.changes uploaded successfully to localhost
along with the files:
  ruby-safe-yaml_1.0.4-1.dsc
  ruby-safe-yaml_1.0.4.orig.tar.gz
  ruby-safe-yaml_1.0.4-1.debian.tar.xz
  ruby-safe-yaml_1.0.4-1_all.deb

Greetings,

Your Debian queue daemon (running on host franck.debian.org)

___
Pkg-ruby-extras-maintainers mailing list
Pkg-ruby-extras-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers


[DRE-maint] ruby-safe-yaml_1.0.4-1_amd64.changes ACCEPTED into unstable

2015-06-25 Thread Debian FTP Masters


Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 25 Jun 2015 09:13:26 -0300
Source: ruby-safe-yaml
Binary: ruby-safe-yaml
Architecture: source all
Version: 1.0.4-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Extras Maintainers 
pkg-ruby-extras-maintainers@lists.alioth.debian.org
Changed-By: Antonio Terceiro terce...@debian.org
Description:
 ruby-safe-yaml - safer YAML loader for Ruby
Changes:
 ruby-safe-yaml (1.0.4-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream release
 - test suite ported to RSpec 3
   * Update packaging with a new dh-make-ruby run
Checksums-Sha1:
 2356b1ca903ef0b4da5c6421d3b167515170abb6 2107 ruby-safe-yaml_1.0.4-1.dsc
 c1391ddd7a9c16015c851a7a97a8fd980b05695d 26868 ruby-safe-yaml_1.0.4.orig.tar.gz
 286cd99b9b6fbc5a9bfd0b012c615d35681f1d75 2968 
ruby-safe-yaml_1.0.4-1.debian.tar.xz
 936119e0912268415ad1529eac5c2dded50e997d 18464 ruby-safe-yaml_1.0.4-1_all.deb
Checksums-Sha256:
 f358a0fd97158b402b4d7e0856d81e117d61c2d706b6ea4ae0ea3affe3fb5ce9 2107 
ruby-safe-yaml_1.0.4-1.dsc
 a098285a8a676d2d2f3ec19ab0ef45ca1ee5e9e6b12b2827c7bc6941613faa5c 26868 
ruby-safe-yaml_1.0.4.orig.tar.gz
 96ad62527bad52ce15b3dfb4913d8fe09fc26df49a572cd73eda9e445db0f63c 2968 
ruby-safe-yaml_1.0.4-1.debian.tar.xz
 3fcb468e02b884bc2c6ad99afb86a3597d7f58bdb4cbe555b8a85314c28be533 18464 
ruby-safe-yaml_1.0.4-1_all.deb
Files:
 7588e3237dd6f2a04c466364ad1333df 2107 ruby optional ruby-safe-yaml_1.0.4-1.dsc
 03c5ebed82c004cdcffd939e5878a292 26868 ruby optional 
ruby-safe-yaml_1.0.4.orig.tar.gz
 591e375c6ec119817f01a7fa358212dd 2968 ruby optional 
ruby-safe-yaml_1.0.4-1.debian.tar.xz
 84b7346c39cad163a2b939d62b07c8e8 18464 ruby optional 
ruby-safe-yaml_1.0.4-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVi/LLAAoJEPwNsbvNRgve+BsP/iwOhx/6cIY9DIKHjHvQGHEu
EPtzS96uXleYXQLtLKaxgf3Tym4yiQqBXUDeivBBa1lPIWcq/vh/eE/7yKbidqTS
FyuNoykknEIQGybKiIjTZvz02sLMqsTBEGI1taHXr5V4eoB1HDvnef1ci8LQB7oR
ukzUXK7bIoyJmVhGSG/H6ECHX+4Knt6NAP7D/Kka8VMOc+6KlBQxtsPHZh/hVMeM
f/XA1gNGfg15vN2e/EJOOrLUzMfzbHwX8vWL/EmKOMHVOq90hayjKTSqnrnSm9Tu
ty3atO3TfyafIBhMpgoXXpJpDdJcPow3GipTrOxuwKVoJmpZcVQjESfuHQSB72Ro
e3gGLfVTLr6O28EvGI0JQAd+T50FYg5jwc+sNjMcZuV857B47W+1JdEbmM7uZ1ri
pfaLSVcz1S7S3JzFoEdAeTSfRloBEt4mTkD14vPbMFfLcVY0/pxtIGRw00hsxf86
WZmfCk48LNcM2QrcIVaaUzeRW7Jh1MG1rCwHvcNSW/gg5dfdusZudDuvKk8x/LGG
NB7Jfdly7jL13uNPwqcfdGo2eJ4uieQQr7+073fazBy5Hr9uT91FSl4FXy8GWVWX
7PYCFpianoZifNkic7BdK1BBylnfY5NP9ryyhebpT4N8MuMwIaiHp21GRYK+m+i3
UEGEY21Rh6XLU86dCn5c
=ik6a
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

___
Pkg-ruby-extras-maintainers mailing list
Pkg-ruby-extras-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers


Re: [DRE-maint] unicorn: native systemd service

2015-06-25 Thread Dmitry Smirnov
On Fri, 26 Jun 2015 00:34:36 Hleb Valoshka wrote:
 So if it still supports sysv scripts and native services does not
 provide additional functions why to add useless native support which
 breaks enhanced sysv features?

Because native support works better than SysV emulation. Because supporting 
both systemd and SysV is better. Because systemd do not allow to invoke non-
standard commands in SysV.


  interface to services is quite intentional. Frankly it is annoying when
  init.d
  script does too much but we can avoid this by offering an additional
  utility to do soft restart and you can call it from init.d script as well
  if you wish.
 
 WE DO NOT NEED ADDITIONAL UTILITIES. DIXI. Init script is well known
 interface between user and daemon. No need to break with additional
 utilities.

Additional utility is good because under systemd you can not use custom 
commands of the SysV script -- disregarding of availability of the native 
.service file. Postinst do not allow user to invoke soft restart manually.
Utility won't break anything and you can call it from custom command of your 
init script if you insist.


  Shell script could be common and independent from init system. It should
  be
  easier to test and debug as well...
 
 I don't think that unicornctl upgrade is more simple that invoke-rc.d
 unicorn upgrade.

It is not more complex either but more flexible.


  You have to get over it. It was debated enough and Technical Committee has
  decided. You still can use init.d if you wish, can you?
 
 I don't want somebody to make sysv useless, cutting away features of
 init scripts

As I've said, I'm not against custom command of the SysV init script. However 
utility allows to avoid duplication of effort (i.e. implement soft restart 
only once) as well as it allows systemd users to benefit from soft restart.


 just because redhat's crapd does not supports them (but
 supports a lot of useless crap).

Please cut your negativity and remain polite and professional.


 I suppose that you are from RF, according to your surname. It doesn't
 matter anyway.

Please refrain from making assumptions. It shouldn't matter where I'm from 
(I'm from Australia FWIW). I find it disturbing that you are trying to make 
connections between my origin and my views. In any case drawing any 
conclusions from surname--origin--beliefs is far fetched and unnecessary.
What is your point anyway?

 
 SW can't be evil and I didn't call crapd as such. Only people can be,
 and those who made crapd default in Debian are definitely made evil
 thing to Debian and Free Software community.

Decision was well debated and thought. IMHO so far there were more good than 
harm. There is no point arguing about it here. Please be polite and 
professional.


  Let's not go there. As maintainer you can't care only about those users
  who
  happened to be using Unicorn on your favourite init system. That kind
  hostility is harmful. Please do not discriminate.
 
 Your last words sounds like manipulation.

No manipulation intended.

-- 
Cheers,
 Dmitry Smirnov.

---

The more false we destroy the more room there will be for the true.
 -- Robert G. Ingersoll, 1902


signature.asc
Description: This is a digitally signed message part.
___
Pkg-ruby-extras-maintainers mailing list
Pkg-ruby-extras-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers

Re: [DRE-maint] unicorn: native systemd service

2015-06-25 Thread Hleb Valoshka
On 6/25/15, Dmitry Smirnov only...@debian.org wrote:

 Not sure... I know systemd can invoke init.d script but only standard
 {start|
 stop|restart|status} functions and only with the absence of native .service
 file.

So if it still supports sysv scripts and native services does not
provide additional functions why to add useless native support which
breaks enhanced sysv features?


 interface to services is quite intentional. Frankly it is annoying when
 init.d
 script does too much but we can avoid this by offering an additional utility
 to do soft restart and you can call it from init.d script as well if you
 wish.

WE DO NOT NEED ADDITIONAL UTILITIES. DIXI. Init script is well known
interface between user and daemon. No need to break with additional
utilities.


 Shell script could be common and independent from init system. It should be
 easier to test and debug as well...

I don't think that unicornctl upgrade is more simple that invoke-rc.d
unicorn upgrade.

 You have to get over it. It was debated enough and Technical Committee has
 decided. You still can use init.d if you wish, can you?

I don't want somebody to make sysv useless, cutting away features of
init scripts just because redhat's crapd does not supports them (but
supports a lot of useless crap).

 , it quite similar to the last
 marriage in Chechnya (old police bastard and young girl), so I don't
 want to support this.
 I do not know this story but from the way you've described it I'm sure that

I suppose that you are from RF, according to your surname. It doesn't
matter anyway.

 your analogy is very inaccurate and unfair. I'm worried about such attitude
 of
 yours. There are things we may not like. For instance I do not like GNOME
 (so
 naturally I do not use it) but I don't need to demonise it (e.g. declare it
 Evil etc.) to justify my preference.

SW can't be evil and I didn't call crapd as such. Only people can be,
and those who made crapd default in Debian are definitely made evil
thing to Debian and Free Software community.

 Let's not go there. As maintainer you can't care only about those users who
 happened to be using Unicorn on your favourite init system. That kind
 hostility is harmful. Please do not discriminate.

Your last words sounds like manipulation.

___
Pkg-ruby-extras-maintainers mailing list
Pkg-ruby-extras-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers


Re: [DRE-maint] unicorn: native systemd service

2015-06-25 Thread Dmitry Smirnov
Hi Christos,

On Thu, 25 Jun 2015 11:50:57 Christos Trochalakis wrote:
 I have recently migrated our main ruby application to systemd implementing
 zero downtime upgrades.
 [...]

Thank you for a very useful hints. I'll update .service file as soon as I try 
soft restart under systemd.


 On more minor note regarding the proposed patch: You can safely use
 `update-rc.d` in maintainer scripts, no need to use $(which update-rc.d).

Thanks. I wasn't sure about that and so far I merely fixed the check which is 
probably redundant...

-- 
All the best,
 Dmitry Smirnov.

---

Platitude: an idea (a) that is admitted to be true by everyone, and (b)
that is not true.
-- H. L. Mencken


signature.asc
Description: This is a digitally signed message part.
___
Pkg-ruby-extras-maintainers mailing list
Pkg-ruby-extras-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers

Re: [DRE-maint] unicorn: native systemd service

2015-06-25 Thread Dmitry Smirnov
Hi Eric,

On Wed, 24 Jun 2015 23:26:49 Eric Wong wrote:
 Dmitry: unicorn upstream here, is there anything in unicorn itself
 can do to make systemd integration easier?

Thank you very much for keeping an eye on us and for all your help.
I'm not sure if we need anything special -- let me experiment more with soft 
restart and maybe I'll come back to you with questions. :)


 I haven't had much interest or time to dig into systemd, but I'm willing
 to put some effort into making unicorn work more smoothly with systemd
 (and any other Free Software process managers/init systems).

Great. I'm entertaining idea of modifying init scripts to make soft restart 
the default behaviour. Is there are any risks or drawbacks of always 
attempting soft restart instead of normal restart? What do you think?

-- 
Cheers,
 Dmitry Smirnov.

---

It is no use saying, 'We are doing our best.' You have got to succeed
in doing what is necessary.
-- Winston Churchill


signature.asc
Description: This is a digitally signed message part.
___
Pkg-ruby-extras-maintainers mailing list
Pkg-ruby-extras-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers

Re: [DRE-maint] unicorn: native systemd service

2015-06-25 Thread Eric Wong
Adding unicorn-pub...@bogomips.org to Cc:

Those of you who haven't followed along on the unic...@packages.debian.org
list can catch up here:
http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/2015-June/024539.html

Dmitry: unicorn upstream here, is there anything in unicorn itself
can do to make systemd integration easier?

I haven't had much interest or time to dig into systemd, but I'm willing
to put some effort into making unicorn work more smoothly with systemd
(and any other Free Software process managers/init systems).

So far unicorn.git has documented the UNICORN_FD environment variable in
the manpage in commit 548e1e67d314f6ebd17df37ece0ee20632462f6f [1]
and support SIGWINCH (kill children) in
commit a6077391bb62d0b13016084b0eea36b987afe8f0 [2]

I think that should be sufficient, but maybe there's more.
Thanks.

[1] http://bogomips.org/unicorn.git/patch/?id=548e1e67
[2] http://bogomips.org/unicorn.git/patch/?id=a6077391

___
Pkg-ruby-extras-maintainers mailing list
Pkg-ruby-extras-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ruby-extras-maintainers