[gentoo-dev] gcc-8 will go into ~arch this weekend
For a few months unkeyworded gcc-8 was in the tree. I plan to unleash it into ~arch this weekend. 'gcc-8' tracker for known things, fixes to steal from and new bugs to pile on: https://bugs.gentoo.org/654766 Have fun! -- Sergei
Re: [gentoo-dev] Packages up for grabs
> app-shells/zsh-completions I am a proxied maintainer but I’d like to push arm stabilization on this one. I’ll make a PR (or send patch on bgo if you prefer) adding myself in the metadata.xml if it's alright. -- Corentin “Nado” Pazdera
[gentoo-dev] net-im/ejabberd, dev-erlang/*: Need help
Hi, I don't have enough time to keep up with ejabberd releases and its dependencies. It would be ideal if someone into Erlang would take care of those packages, but any help is highly appreciated. I'll provide any guidance needed. Thanks, -- aidecoe signature.asc Description: PGP signature
Re: [gentoo-dev] autotools.eclass and EAPI 7
Ühel kenal päeval, N, 16.08.2018 kell 14:27, kirjutas Brian Evans: > There are currently a handful of ebuilds using EAPI 7 and the > autotools > eclass. > > I believe that this eclass should be reviewed for adding BDEPEND or > having BDEPEND replace the DEPEND statement as the default action of > the > eclass. > > Other items might be needed, but that's doubtful. > > Someone please advise the best course of action and either do it or I > will propose a patch based on the discussion. > Could or did someone also check through all the other eclasses that don't have any global EAPI compatibility checks? For the future, maybe it's better to add such a check - just accepting 0-7 or so, but unsure about all these custom EAPIs out there, might force more eclass copying to some overlays. Mart signature.asc Description: This is a digitally signed message part
[gentoo-dev] autotools.eclass and EAPI 7
There are currently a handful of ebuilds using EAPI 7 and the autotools eclass. I believe that this eclass should be reviewed for adding BDEPEND or having BDEPEND replace the DEPEND statement as the default action of the eclass. Other items might be needed, but that's doubtful. Someone please advise the best course of action and either do it or I will propose a patch based on the discussion. Thanks. Brian signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: net-misc/dhcpcd-ui, net-misc/tipcutils
Dear all, The following packages are up for grabs: net-misc/dhcpcd-ui net-misc/tipcutils after retirement of the proxied maintainer. https://packages.gentoo.org/packages/net-misc/dhcpcd-ui https://packages.gentoo.org/packages/net-misc/tipcutils -- Best, Jonas signature.asc Description: OpenPGP digital signature
[gentoo-portage-dev] [PATCH] repoman.config: Make yaml loader optional
Make the yaml loader optional, delaying the failure until the user attempts to actually load a yaml file. Given that pyyaml is an external dependency, there is no real reason to fail as soon as repoman.config is loaded if YAML may not be used at all. --- repoman/lib/repoman/config.py | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/repoman/lib/repoman/config.py b/repoman/lib/repoman/config.py index 578bbccde..decf9b90a 100644 --- a/repoman/lib/repoman/config.py +++ b/repoman/lib/repoman/config.py @@ -6,7 +6,10 @@ import json import os import stat -import yaml +try: + import yaml +except ImportError: + yaml = None try: FileNotFoundError @@ -73,6 +76,9 @@ def _yaml_load(filename): Load filename as YAML and return a dict. Raise ConfigError if it fails to load. """ + if yaml is None: + raise ImportError('Please install pyyaml in order to read yaml files') + with open(filename, 'rt') as f: try: return yaml.safe_load(f) -- 2.18.0