Re: [gentoo-dev] [PATCH 1/3] ecm-utils.eclass: New eclass
On Wed, 2019-11-06 at 02:19 +0100, Andreas Sturmlechner wrote:
> > > +# @ECLASS-VARIABLE: ECM_NONGUI
> > > +# @DESCRIPTION:
> > > +# If set to "false", add dependency on kde-frameworks/breeze-icons
> > > +# or kde-frameworks/oxygen-icons and run the xdg.eclass routines for
> > > +# pkg_preinst, pkg_postinst and pkg_postrm.
> > > +# For any other value, do nothing.
> > > +if [[ ${CATEGORY} = kde-frameworks ]]; then
> > > + : ${ECM_NONGUI:=true}
> > > +fi
> > > +: ${ECM_NONGUI:=false}
> >
> > I don't think eclassdoc is going to parse this correctly.
>
> Can we do something about that? I need to be able to set (overrideable)
> defaults for a category without being limited by eclassdoc. @DEFAULT_UNSET
> would not be precise. Same as ECM_QTHELP, this is what we do in kde5.eclass
> already.
>
If I knew, I would've told you. I've personally settled for
@DEFAULT_UNSET, and explained what happens when it's unset.
Alternatively, you could set default earlier in a separate var, then do
something like:
: ${ECM_NONGUI:=${ECM_NONGUI_DEFAULT}}
but I don't think that will be very helpful. Maybe sth like:
: ${ECM_NONGUI:=${IS_KDE_FRAMEWORKS}}
but then, it's just a hack.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/3] ecm-utils.eclass: New eclass
On Tuesday, 5 November 2019 22:20:46 CET Michał Górny wrote:
> On Tue, 2019-11-05 at 00:30 +0100, Andreas Sturmlechner wrote:
> > --- /dev/null
> > +++ b/eclass/ecm-utils.eclass
>
> I know we historically screwed this up repeatedly but please don't use
> '-utils' for eclasses that export phases.
Fine, I would then choose ecm.eclass instead.
> > +# @ECLASS-VARIABLE: ECM_NONGUI
> > +# @DESCRIPTION:
> > +# If set to "false", add dependency on kde-frameworks/breeze-icons
> > +# or kde-frameworks/oxygen-icons and run the xdg.eclass routines for
> > +# pkg_preinst, pkg_postinst and pkg_postrm.
> > +# For any other value, do nothing.
> > +if [[ ${CATEGORY} = kde-frameworks ]]; then
> > + : ${ECM_NONGUI:=true}
> > +fi
> > +: ${ECM_NONGUI:=false}
>
> I don't think eclassdoc is going to parse this correctly.
Can we do something about that? I need to be able to set (overrideable)
defaults for a category without being limited by eclassdoc. @DEFAULT_UNSET
would not be precise. Same as ECM_QTHELP, this is what we do in kde5.eclass
already.
> > +# @ECLASS-VARIABLE: ECM_DEBUG
> > +# @DESCRIPTION:
> > +# If set to "false", add -DNDEBUG (via cmake-utils_src_configure) and
> > +# -DQT_NO_DEBUG to CPPFLAGS.
> > +# Otherwise, add debug to IUSE.
> > +: ${ECM_DEBUG:=true}
>
> To be honest, I don't really like this 'anything-or-false' logic. It's
> rather confusing and error-prone. For example, if I misspell 'false'
> the eclass is going to silently assume true.
Making all options explicit then and erroring out on unknown input.
> > +# @FUNCTION: ecm_punt_bogus_dep
> > +# @USAGE:
> > +# @DESCRIPTION:
> > +# Removes a specified dependency from a find_package call with multiple
> > components.
> > +ecm_punt_bogus_dep() {
> > + local prefix=${1}
> > + local dep=${2}
> > +
> > + if [[ ! -e "CMakeLists.txt" ]]; then
>
> Can this really ever happen in a valid use case? Maybe it should be
> an error instead.
Even cmake-utils.eclass makes that check in cmake_comment_add_subdirectory and
leaves the erroring out if the file's missing central to src_prepare(), I
guess is why it was done that way.
Thanks for looking over it!
Regards,
Andreas
Re: [gentoo-dev] [PATCH 1/3] ecm-utils.eclass: New eclass
On Tue, 2019-11-05 at 00:30 +0100, Andreas Sturmlechner wrote:
> Support eclass for packages that use KDE extra-cmake-modules.
>
> This eclass is intended to streamline the creation of ebuilds for packages
> that follow KDE upstream packaging conventions. It's primarily intended for
> the three upstream release groups (Frameworks, Plasma, Applications) but
> is also for any package that follows similar conventions.
>
> This eclass unconditionally inherits cmake-utils.eclass and all its public
> variables and helper functions (not phase functions) may be considered as part
> of this eclass's API.
>
> When used together with kde.org.eclass this will replace kde5.eclass and
> kde5-functions.eclass, most of the latter is becoming obsolete.
>
> --- /dev/null
> +++ b/eclass/ecm-utils.eclass
I know we historically screwed this up repeatedly but please don't use
'-utils' for eclasses that export phases.
> @@ -0,0 +1,549 @@
> +# Copyright 1999-2019 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: ecm-utils.eclass
> +# @MAINTAINER:
> +# k...@gentoo.org
> +# @SUPPORTED_EAPIS: 7
> +# @BLURB: Support eclass for packages that use KDE extra-cmake-modules.
> +# @DESCRIPTION:
> +# This eclass is intended to streamline the creation of ebuilds for packages
> +# that follow KDE upstream packaging conventions. It's primarily intended for
> +# the three upstream release groups (Frameworks, Plasma, Applications) but
> +# is also for any package that follows similar conventions.
> +#
> +# This eclass unconditionally inherits cmake-utils.eclass and all its public
> +# variables and helper functions (not phase functions) may be considered as
> part
> +# of this eclass's API.
> +#
> +# This eclass's phase functions are not intended to be mixed and matched, so
> if
> +# any phase functions are overridden the version here should also be called.
> +
> +if [[ -z ${_ECM_UTILS_ECLASS} ]]; then
> +_ECM_UTILS_ECLASS=1
> +
> +# @ECLASS-VARIABLE: VIRTUALX_REQUIRED
> +# @DESCRIPTION:
> +# For proper description see virtualx.eclass manpage.
> +# Here we redefine default value to be manual, if your package needs virtualx
> +# for tests you should proceed with setting VIRTUALX_REQUIRED=test.
> +: ${VIRTUALX_REQUIRED:=manual}
> +
> +inherit cmake-utils flag-o-matic toolchain-funcs virtualx xdg
> +
> +case ${EAPI} in
> + 7) ;;
> + *) die "EAPI=${EAPI:-0} is not supported" ;;
> +esac
> +
> +if [[ -v KDE_GCC_MINIMAL ]]; then
> + EXPORT_FUNCTIONS pkg_pretend
> +fi
> +
> +EXPORT_FUNCTIONS pkg_setup src_prepare src_configure src_test pkg_preinst
> pkg_postinst pkg_postrm
> +
> +# @ECLASS-VARIABLE: ECM_KDEINSTALLDIRS
> +# @DESCRIPTION:
> +# If set to "false", do nothing.
> +# For any other value, assume the package is using KDEInstallDirs macro and
> switch
> +# KDE_INSTALL_USE_QT_SYS_PATHS to ON.
> +: ${ECM_KDEINSTALLDIRS:=true}
> +
> +# @ECLASS-VARIABLE: ECM_NONGUI
> +# @DESCRIPTION:
> +# If set to "false", add dependency on kde-frameworks/breeze-icons
> +# or kde-frameworks/oxygen-icons and run the xdg.eclass routines for
> +# pkg_preinst, pkg_postinst and pkg_postrm.
> +# For any other value, do nothing.
> +if [[ ${CATEGORY} = kde-frameworks ]]; then
> + : ${ECM_NONGUI:=true}
> +fi
> +: ${ECM_NONGUI:=false}
I don't think eclassdoc is going to parse this correctly.
> +
> +# @ECLASS-VARIABLE: ECM_DEBUG
> +# @DESCRIPTION:
> +# If set to "false", add -DNDEBUG (via cmake-utils_src_configure) and
> +# -DQT_NO_DEBUG to CPPFLAGS.
> +# Otherwise, add debug to IUSE.
> +: ${ECM_DEBUG:=true}
To be honest, I don't really like this 'anything-or-false' logic. It's
rather confusing and error-prone. For example, if I misspell 'false'
the eclass is going to silently assume true.
> +
> +# @ECLASS-VARIABLE: ECM_DESIGNERPLUGIN
> +# @DESCRIPTION:
> +# If set to "false", do nothing.
> +# Otherwise, add "designer" to IUSE to toggle build of designer plugins
> +# and add the necessary BDEPEND.
> +: ${ECM_DESIGNERPLUGIN:=false}
> +
> +# @ECLASS-VARIABLE: ECM_EXAMPLES
> +# @DESCRIPTION:
> +# If set to "false", unconditionally ignore a top-level examples
> subdirectory.
> +# Otherwise, add "examples" to IUSE to toggle adding that subdirectory.
> +: ${ECM_EXAMPLES:=false}
> +
> +# @ECLASS-VARIABLE: ECM_HANDBOOK
> +# @DESCRIPTION:
> +# If set to "false", do nothing.
> +# Otherwise, add "+handbook" to IUSE, add the appropriate dependency, and let
> +# KF5DocTools generate and install the handbook from docbook file(s) found in
> +# ECM_HANDBOOK_DIR. However if USE handbook is disabled, disable build of
> +# ECM_HANDBOOK_DIR in CMakeLists.txt.
> +# If set to "optional", config with -
> DCMAKE_DISABLE_FIND_PACKAGE_KF5DocTools=ON
> +# when USE=!handbook. In case package requires KF5KDELibs4Support, see next:
> +# If set to "forceoptional", remove a KF5DocTools dependency from the root
> +# CMakeLists.txt in addition to the above.
> +: ${ECM_HANDBOOK:=false}
> +
> +# @ECLASS-VARIABLE:
Re: [gentoo-portage-dev] [r...@gentoo.org: Cron /usr/local/bin/pidlock -s sync-distfiles /usr/bin/timeout -k 2h 1h /usr/local/bin/mastermirror/sync-distfiles.sh]
On 11/5/19 10:15 AM, Michał Górny wrote: > On Tue, 2019-11-05 at 18:13 +, Robin H. Johnson wrote: >> Can Portage handle this error more gracefully please? >> > > Is it still happening though? I thought the Portage upgrade fixed it. The UnboundLocalError is an outstanding bug. I'll make a release right away to fix it (unless we would like to add some other changes first): https://bugs.gentoo.org/699392 Also, DeletionTask error handling could use some improvement, but maybe that's not so urgent to fix: https://bugs.gentoo.org/699400 >> The symlink test file is there to verify mirror behavior, so we don't >> want to delete it either. > > I think it's fine to delete it now. If you wanted to keep it, then you could whitelist it, right? -- Thanks, Zac signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-admin/certmgr, app-admin/ksonnet, dev-go/delve
# Michał Górny (2019-11-05) # The following packages are unmaintained and have incorrect LICENSE # entries. All of them have additional bugs reported. # # app-admin/certmgr: #694690 # app-admin/ksonnet: #694710 # dev-go/delve: #694382 # Removal in 30 days. app-admin/certmgr app-admin/ksonnet dev-go/delve -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [r...@gentoo.org: Cron /usr/local/bin/pidlock -s sync-distfiles /usr/bin/timeout -k 2h 1h /usr/local/bin/mastermirror/sync-distfiles.sh]
On Tue, 2019-11-05 at 18:13 +, Robin H. Johnson wrote: > Can Portage handle this error more gracefully please? > Is it still happening though? I thought the Portage upgrade fixed it. > The symlink test file is there to verify mirror behavior, so we don't > want to delete it either. I think it's fine to delete it now. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-portage-dev] [r...@gentoo.org: Cron /usr/local/bin/pidlock -s sync-distfiles /usr/bin/timeout -k 2h 1h /usr/local/bin/mastermirror/sync-distfiles.sh]
Can Portage handle this error more gracefully please? The symlink test file is there to verify mirror behavior, so we don't want to delete it either. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 --- Begin Message --- [ERROR] rename symlink-test from distfiles to recycle failed: [Errno 2] No such file or directory Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/portage/util/_async/ForkProcess.py", line 55, in _spawn rval = self._run() File "/usr/lib64/python2.7/site-packages/portage/util/_async/FileCopier.py", line 16, in _run shutil.copy(self.src_path, self.dest_path) File "/usr/lib64/python2.7/site-packages/portage/__init__.py", line 246, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) File "/usr/lib64/python2.7/shutil.py", line 139, in copy copyfile(src, dst) File "/usr/lib64/python2.7/shutil.py", line 96, in copyfile with open(src, 'rb') as fsrc: IOError: [Errno 2] No such file or directory: '/data/gmirror-distfiles/distfiles/ee/symlink-test' Traceback (most recent call last): File "/usr/bin/emirrordist", line 86, in exec(data, new_globals) File "", line 23, in File "/usr/lib64/python2.7/site-packages/portage/_emirrordist/main.py", line 450, in emirrordist_main signum = run_main_scheduler(MirrorDistTask(config)) File "/usr/lib64/python2.7/site-packages/portage/util/_async/run_main_scheduler.py", line 27, in run_main_scheduler scheduler.wait() File "/usr/lib64/python2.7/site-packages/_emerge/AsynchronousTask.py", line 83, in wait self.scheduler.run_until_complete(self.async_wait()) File "/usr/lib64/python2.7/site-packages/portage/util/_eventloop/EventLoop.py", line 831, in run_until_complete self.iteration() File "/usr/lib64/python2.7/site-packages/portage/util/_eventloop/EventLoop.py", line 285, in iteration return self._iteration(*args) File "/usr/lib64/python2.7/site-packages/portage/util/_eventloop/EventLoop.py", line 306, in _iteration if self._run_timeouts(): File "/usr/lib64/python2.7/site-packages/portage/util/_eventloop/EventLoop.py", line 601, in _run_timeouts if self._run_idle_callbacks(): File "/usr/lib64/python2.7/site-packages/portage/util/_eventloop/EventLoop.py", line 560, in _run_idle_callbacks if x._callback(*x._args): File "/usr/lib64/python2.7/site-packages/portage/util/_eventloop/EventLoop.py", line 101, in __call__ self._callback(*self._args) File "/usr/lib64/python2.7/site-packages/_emerge/AsynchronousTask.py", line 84, in wait self._wait_hook() File "/usr/lib64/python2.7/site-packages/_emerge/AsynchronousTask.py", line 195, in _wait_hook self._exit_listener_stack.pop()(self) File "/usr/lib64/python2.7/site-packages/portage/_emirrordist/DeletionTask.py", line 92, in _recycle_copier_exit "to recycle failed: %s") % (self.distfile, e)) UnboundLocalError: local variable 'e' referenced before assignment --- End Message --- signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Removing obsolete thick Manifest compatibility from MetaManifests
On Tue, 2019-11-05 at 14:01 +0100, Michael Haubenwallner wrote: > Hi, > > On 10/24/19 2:37 PM, Michał Górny wrote: > > Hello, > > > > TL;DR: I'd like to disable thick Manifest support in Portage, in order > > to disable some of the compatibility quirks from MetaManifest format. > > All files would still be verified by gemato. > > WDYT? > > > > I'm using Gentoo Prefix as a Meta Distribution, where I can not use the > Gentoo infrastructure, but have to provide the master services on my own. > > While I've been able to set up rsync & distfiles master ~10 years ago, > where I haven't discovered any docs for so far, I feel lost when I think > of setting up additional master services for gemato without some docs. > > Facing the removal of thick Manifest support (which I don't want to block > in any way), I've started to search for some docs how to set up these > additional master services to support gemato, but failed. > > What I've found is the Infrastructure wiki project, providing a list of > servers maintained by infra, but nothing about how to set them up. > > Did I miss something? > gemato has commands to create and update MetaManifests. Also there's (much faster) trivial script in utils/ directory of gemato. The relevant infra script is: https://gitweb.gentoo.org/infra/mastermirror-scripts.git/tree/rsync-gen.sh#n243 -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [RFC] Removing obsolete thick Manifest compatibility from MetaManifests
Hi, On 10/24/19 2:37 PM, Michał Górny wrote: > Hello, > > TL;DR: I'd like to disable thick Manifest support in Portage, in order > to disable some of the compatibility quirks from MetaManifest format. > All files would still be verified by gemato. > > WDYT? > I'm using Gentoo Prefix as a Meta Distribution, where I can not use the Gentoo infrastructure, but have to provide the master services on my own. While I've been able to set up rsync & distfiles master ~10 years ago, where I haven't discovered any docs for so far, I feel lost when I think of setting up additional master services for gemato without some docs. Facing the removal of thick Manifest support (which I don't want to block in any way), I've started to search for some docs how to set up these additional master services to support gemato, but failed. What I've found is the Infrastructure wiki project, providing a list of servers maintained by infra, but nothing about how to set them up. Did I miss something? Thanks! /haubi/
Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?
On Mon, 4 Nov 2019 23:24:57 + Michael 'veremitz' Everitt wrote: > Straw man anyone? I know Guy Fawkes night is coming up here in the UK ... ;) I love you, but please, less trolling. This is a developer discussion venue, not a place for cheap-shots like reddit. pgpVMFPNhhCyl.pgp Description: OpenPGP digital signature
