Re: [gentoo-dev] systemd + postgresql is non-obvious to me

2014-08-22 Thread Aaron W. Swenson
On 2014-07-15 08:52, Ian Stakenvicius wrote:
 On 15/07/14 07:36 AM, Pacho Ramos wrote:
  El mar, 15-07-2014 a las 13:31 +0200, Alexander Berntsen escribió: 
  [...]
  To alleviate this I needed to run systemd-tmpfiles --create.
  This was non-obvious to me. Sounds like a packaging issue that I
  need to do it in the first place?
  
  It's: https://bugs.gentoo.org/show_bug.cgi?id=462118
  
  The problem is that it's not clear to us how to make it
  automatically without needing to call it manually from every ebuild
  installing a tmpfiles.d file :(
  
  
 
 Wasn't there a plan to make an eclass helper to process tmpfiles.d
 files that get installed, during pkg_postinst ?
 
 ...and now that I think about it, did I say that I was going to write it?
 

There's a bit more to it, as well.

On the whole, I'm displeased with the systemd alternative for
controlling PostgreSQL. It's significantly hampered and doesn't allow
as much flexibility as the initscript. The major issue being trying to
nicely shut down the server instead of jumping straight to murder.

I really don't want to get into an OpenRC versus systemd flame-war,
but I really hate the systemd offering we have for PostgreSQL. It's
dumb and I recommend against using it.

I haven't used systemd and do not plan on using it until it actually
fixes a problem that's non-trivial, which is most likely never for me.

So, if any of you would like to improve our systemd offering, it'd be
welcomed enthusiastically.

-- 
Mr. Aaron W. Swenson
Gentoo Linux Developer
PostgreSQL Herd Bull
Email : titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0

signature.asc
Description: Digital signature


[gentoo-dev] new global use flag: opus

2014-08-22 Thread Steve Dibb

It's time to give opus its own global USE flag.  15 ebuilds use it locally for 
the same thing, and I've got another ebuild in the works to add it.

Current usage:

 local:opus:media-libs/mediastreamer: Enable opus codec support
 local:opus:media-plugins/gst-plugins-meta: Enable Opus audio codec support
 local:opus:media-sound/asunder: Support for creation of Opus files
 local:opus:media-sound/cmus: enable support for media-libs/opusfile
 local:opus:media-sound/darkice: Enable Opus audio codec support
 local:opus:media-sound/easytag: Enable support for media-libs/opus and 
media-libs/opusfile (opus audio codec)
 local:opus:media-sound/kwave: Enable Opus audio codec support
 local:opus:media-sound/mangler: Codec specialized for speech over the internet
 local:opus:media-sound/mpd: Enable Opus codec support
 local:opus:media-sound/qmmp: Enable the opus plugin
 local:opus:media-sound/soundconverter: Enable Opus audio codec support
 local:opus:media-video/ffmpeg: Adds (decoding) support for the Opus codec via 
media-libs/opus.
 local:opus:media-video/libav: Use the external opus library for encoding and 
decoding.
 local:opus:media-video/vlc: Support opus decoding via libopus.
 local:opus:virtual/ffmpeg: Use the external opus library for encoding and 
decoding.

New description: Add support for the Opus audio codec

I'll add it into the tree in a few days if no-one objects.

Thanks,

Steve



Re: [gentoo-dev] systemd + postgresql is non-obvious to me

2014-08-22 Thread Rich Freeman
On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson titanof...@gentoo.org wrote:
 On the whole, I'm displeased with the systemd alternative for
 controlling PostgreSQL. It's significantly hampered and doesn't allow
 as much flexibility as the initscript. The major issue being trying to
 nicely shut down the server instead of jumping straight to murder.


It looks like the package installs a service file provided by
upstream, so you might want to direct your complaint there unless it
really is a systemd limitation.

Checking the latest version in portage it calls:
ExecStop=/usr/@LIBDIR@/postgresql-@SLOT@/bin/pg_ctl stop -D
${DATA_DIR} -s -m fast

I'm no postresql expert, but according to the manpage that should
bring the server to a screeching, but still controlled, halt.  Perhaps
you would prefer setting it to -m smart instead of -m fast.

If so override it in /etc/systemd/system.  I generally recommend using
drop-ins for this, but I'm not sure if doing a drop-in for ExecStop
will override the existing value, or simply cause systemd to run both
commands (which means that whichever runs first will control how it
stops).

Systemd shouldn't begin killing processes without mercy until the
process invoked in ExecStop terminates, so it should not terminate
until the process has finished graceful shutdown.

Rich



Re: [gentoo-dev] systemd + postgresql is non-obvious to me

2014-08-22 Thread Canek Peláez Valdés
On Fri, Aug 22, 2014 at 1:07 PM, Rich Freeman ri...@gentoo.org wrote:
 On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson titanof...@gentoo.org 
 wrote:
 On the whole, I'm displeased with the systemd alternative for
 controlling PostgreSQL. It's significantly hampered and doesn't allow
 as much flexibility as the initscript. The major issue being trying to
 nicely shut down the server instead of jumping straight to murder.


 It looks like the package installs a service file provided by
 upstream, so you might want to direct your complaint there unless it
 really is a systemd limitation.

 Checking the latest version in portage it calls:
 ExecStop=/usr/@LIBDIR@/postgresql-@SLOT@/bin/pg_ctl stop -D
 ${DATA_DIR} -s -m fast

 I'm no postresql expert, but according to the manpage that should
 bring the server to a screeching, but still controlled, halt.  Perhaps
 you would prefer setting it to -m smart instead of -m fast.

 If so override it in /etc/systemd/system.  I generally recommend using
 drop-ins for this, but I'm not sure if doing a drop-in for ExecStop
 will override the existing value, or simply cause systemd to run both
 commands (which means that whichever runs first will control how it
 stops).

It's the same as with ExecStart=; it gets added to a list, and all of
them are executed in the same order as they appear in the unit file.
In a drop-in, you can reset the list like this:

ExecStop=
ExecStop=new_and_only_command_to_be_executed

 Systemd shouldn't begin killing processes without mercy until the
 process invoked in ExecStop terminates, so it should not terminate
 until the process has finished graceful shutdown.

If ExecStop= wasn't specified, systemd would immediaely kill all the
service processes; from [1]: If this option [ExecStop] is not
specified, the process is terminated immediately when service stop is
requested, which kinda sounds like jumping straight to murder.

That the upstream unit file is configured otherwise, shows that
PostgreSQL upstream itself thinks that's a bad idea. No fault on
systemd's part.

Regards.

[1] http://www.freedesktop.org/software/systemd/man/systemd.service.html
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México



Re: [gentoo-dev] systemd + postgresql is non-obvious to me

2014-08-22 Thread Mike Gilbert
On Fri, Aug 22, 2014 at 2:07 PM, Rich Freeman ri...@gentoo.org wrote:
 On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson titanof...@gentoo.org 
 wrote:
 On the whole, I'm displeased with the systemd alternative for
 controlling PostgreSQL. It's significantly hampered and doesn't allow
 as much flexibility as the initscript. The major issue being trying to
 nicely shut down the server instead of jumping straight to murder.


 It looks like the package installs a service file provided by
 upstream, so you might want to direct your complaint there unless it
 really is a systemd limitation.

 Checking the latest version in portage it calls:
 ExecStop=/usr/@LIBDIR@/postgresql-@SLOT@/bin/pg_ctl stop -D
 ${DATA_DIR} -s -m fast

 I'm no postresql expert, but according to the manpage that should
 bring the server to a screeching, but still controlled, halt.  Perhaps
 you would prefer setting it to -m smart instead of -m fast.


Personally, I prefer the thing to stop within a reasonable time period
when I tell it to stop. Waiting around for the remaining connections
to magically die (smart mode) is just tedious.



Re: [gentoo-portage-dev] [PATCH 1/6] self-update: Copy only relevant packages from PORTAGE_PYM_PATH

2014-08-22 Thread Brian Dolbec
On Thu, 21 Aug 2014 22:19:39 +0200
Michał Górny mgo...@gentoo.org wrote:

 Update the self-update code to copy only packages relevant to Portage,
 to avoid copying other packages when Portage is installed alongside
 them.
 ---
  pym/portage/const.py   | 3 +++
  pym/portage/package/ebuild/doebuild.py | 8 ++--
  2 files changed, 9 insertions(+), 2 deletions(-)
 

Seems fine to me...


-- 
Brian Dolbec dolsen




Re: [gentoo-portage-dev] [PATCH 4/6] tests: Fix running on installed copy of Portage

2014-08-22 Thread Brian Dolbec
On Thu, 21 Aug 2014 22:19:42 +0200
Michał Górny mgo...@gentoo.org wrote:

 ---
  pym/portage/tests/__init__.py| 20
 ++ pym/portage/tests/dbapi/test_portdb_cache.py
 |  5 ++--- pym/portage/tests/emerge/test_emerge_slot_abi.py |  7
 +++ pym/portage/tests/emerge/test_simple.py  | 26
 
 pym/portage/tests/lint/test_compile_modules.py   | 10 +
 pym/portage/tests/lint/test_import_modules.py|  8 ++--
 pym/portage/tests/repoman/test_simple.py |  8 +---
 pym/portage/tests/resolver/ResolverPlayground.py |  8 +---
 pym/portage/tests/util/test_getconfig.py |  5 ++--- 9 files
 changed, 62 insertions(+), 35 deletions(-)
 
 
diff --git a/pym/portage/tests/util/test_getconfig.py
 b/pym/portage/tests/util/test_getconfig.py index e5fd60f..16f415c
 100644 --- a/pym/portage/tests/util/test_getconfig.py
 +++ b/pym/portage/tests/util/test_getconfig.py
 @@ -3,6 +3,7 @@
  
  import tempfile
  
 +import portage
  from portage import os
  from portage import shutil
  from portage import _unicode_encode
 @@ -26,9 +27,7 @@ class GetConfigTestCase(TestCase):
   }
  
   def testGetConfig(self):
 -
 - make_globals_file = os.path.join(PORTAGE_BASE_PATH,
 - 'cnf', 'make.globals')
 + make_globals_file = os.path.join(self.cnf_path,
 make.globals) d = getconfig(make_globals_file)
   for k, v in self._cases.items():
   self.assertEqual(d[k], v)

Why was import portage added but not used anywhere in additional code?


-- 
Brian Dolbec dolsen




Re: [gentoo-portage-dev] [PATCH 5/6] Install Python modules using setup.py

2014-08-22 Thread Brian Dolbec
On Thu, 21 Aug 2014 22:19:43 +0200
Michał Górny mgo...@gentoo.org wrote:

 ---
  .gitignore   |   1 +
  Makefile | 215 
  doc/Makefile |  11 -
  pym/portage/const.py |   4 +-
  setup.py | 557
 +++ 5 files changed,
 560 insertions(+), 228 deletions(-) delete mode 100644 Makefile
  delete mode 100644 doc/Makefile
  create mode 100755 setup.py




 diff --git a/setup.py b/setup.py new file mode 100755
 index 000..bd6e506 --- /dev/null
 +++ b/setup.py
 @@ -0,0 +1,557 @@
 +#!/usr/bin/env python
 +#vim:fileencoding=utf-8
 +# (c) 2010 Michał Górny mgo...@gentoo.org
 +# Released under the terms of the 2-clause BSD license.
 +
 +from distutils.core import setup, Command
 +from distutils.command.build_scripts import build_scripts
 +from distutils.command.clean import clean
 +from distutils.command.install import install
 +from distutils.command.install_data import install_data
 +from distutils.command.install_lib import install_lib
 +from distutils.command.install_scripts import install_scripts
 +from distutils.dir_util import remove_tree
 +from distutils.util import change_root, subst_vars
 +
 +import codecs, collections, glob, os, os.path, re, subprocess, sys
 +
 +# TODO:
 +# - smarter rebuilds of docs w/ 'install_docbook' and
 'install_epydoc'. +
 +package_name = 'portage'
 +package_version = '2.2.12'

Why hard code the version?  can you not import it?  or did you add this
to the sed list in mkrelease.sh?

-- 
Brian Dolbec dolsen




Re: [gentoo-portage-dev] [PATCH 5/6] Install Python modules using setup.py

2014-08-22 Thread Michał Górny
Dnia 2014-08-22, o godz. 15:30:15
Brian Dolbec dol...@gentoo.org napisał(a):

 On Thu, 21 Aug 2014 22:19:43 +0200
 Michał Górny mgo...@gentoo.org wrote:
 
  ---
   .gitignore   |   1 +
   Makefile | 215 
   doc/Makefile |  11 -
   pym/portage/const.py |   4 +-
   setup.py | 557
  +++ 5 files changed,
  560 insertions(+), 228 deletions(-) delete mode 100644 Makefile
   delete mode 100644 doc/Makefile
   create mode 100755 setup.py
 
 
 
 
  diff --git a/setup.py b/setup.py new file mode 100755
  index 000..bd6e506 --- /dev/null
  +++ b/setup.py
  @@ -0,0 +1,557 @@
  +#!/usr/bin/env python
  +#  vim:fileencoding=utf-8
  +# (c) 2010 Michał Górny mgo...@gentoo.org
  +# Released under the terms of the 2-clause BSD license.
  +
  +from distutils.core import setup, Command
  +from distutils.command.build_scripts import build_scripts
  +from distutils.command.clean import clean
  +from distutils.command.install import install
  +from distutils.command.install_data import install_data
  +from distutils.command.install_lib import install_lib
  +from distutils.command.install_scripts import install_scripts
  +from distutils.dir_util import remove_tree
  +from distutils.util import change_root, subst_vars
  +
  +import codecs, collections, glob, os, os.path, re, subprocess, sys
  +
  +# TODO:
  +# - smarter rebuilds of docs w/ 'install_docbook' and
  'install_epydoc'. +
  +package_name = 'portage'
  +package_version = '2.2.12'
 
 Why hard code the version?  can you not import it?  or did you add this
 to the sed list in mkrelease.sh?

Left it in my todo and forgot about it. Which also makes me think that
we may want to try to get 'setup.py sdist' working as well, and rethink
how much we need mkrelease.sh afterwards.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature


Re: [gentoo-portage-dev] [PATCH 4/6] tests: Fix running on installed copy of Portage

2014-08-22 Thread Michał Górny
Dnia 2014-08-22, o godz. 15:19:12
Brian Dolbec dol...@gentoo.org napisał(a):

 On Thu, 21 Aug 2014 22:19:42 +0200
 Michał Górny mgo...@gentoo.org wrote:
 
  ---
   pym/portage/tests/__init__.py| 20
  ++ pym/portage/tests/dbapi/test_portdb_cache.py
  |  5 ++--- pym/portage/tests/emerge/test_emerge_slot_abi.py |  7
  +++ pym/portage/tests/emerge/test_simple.py  | 26
  
  pym/portage/tests/lint/test_compile_modules.py   | 10 +
  pym/portage/tests/lint/test_import_modules.py|  8 ++--
  pym/portage/tests/repoman/test_simple.py |  8 +---
  pym/portage/tests/resolver/ResolverPlayground.py |  8 +---
  pym/portage/tests/util/test_getconfig.py |  5 ++--- 9 files
  changed, 62 insertions(+), 35 deletions(-)
  
  
 diff --git a/pym/portage/tests/util/test_getconfig.py
  b/pym/portage/tests/util/test_getconfig.py index e5fd60f..16f415c
  100644 --- a/pym/portage/tests/util/test_getconfig.py
  +++ b/pym/portage/tests/util/test_getconfig.py
  @@ -3,6 +3,7 @@
   
   import tempfile
   
  +import portage
   from portage import os
   from portage import shutil
   from portage import _unicode_encode
  @@ -26,9 +27,7 @@ class GetConfigTestCase(TestCase):
  }
   
  def testGetConfig(self):
  -
  -   make_globals_file = os.path.join(PORTAGE_BASE_PATH,
  -   'cnf', 'make.globals')
  +   make_globals_file = os.path.join(self.cnf_path,
  make.globals) d = getconfig(make_globals_file)
  for k, v in self._cases.items():
  self.assertEqual(d[k], v)
 
 Why was import portage added but not used anywhere in additional code?

Good catch. It was used in the previous version of the patch. Fixed now.


-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature