Re: [gentoo-dev] systemd + postgresql is non-obvious to me
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
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
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
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
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
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
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
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
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
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