Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[Kent Fredric]

On Mon, 30 Jan 2017 14:04:06 -0600
William Hubbs  wrote:

> As I said on the bug, the downside is the addition of py3 and ninja as
> build time dependencies, but I think the upside (a build system where
> we don't have to worry about parallel make issues or portability)
> outweighs that.

On principle I would discourage this course of action.

Critical infrastructure should be built on proven and established technology
that has practically become boring to the point of almost-stagnation.

Building things atop of newer technology ends up being like building upon
shifting sands.

And all this is doubly important if you're ever needing to bootstrap.

ie: It might be justifiable to build openrc on top of meson on an established
system which already has a working openrc, but building openrc on meson
when you're installing your first Gentoo install is going to be much more 
painful
than it should be.

And we should be keeping the @system essentials set required for new 
installations
to be as minimal as possible without losing functionality.

And here, I think the objectives of being parallel-make friendly are small
in compare with the overhead for ensuring the dependencies are present and 
working
and usable on a clean install.

But a package that has only been in tree a measly 7 months seems far, far
too premature to switch to being a mandatory part of the critical path.




pgpWmHATLEQhC.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[Robin H. Johnson]

On Mon, Jan 30, 2017 at 02:04:06PM -0600, William Hubbs wrote:
> As I said on the bug, the downside is the addition of py3 and ninja as
> build time dependencies, but I think the upside (a build system where
> we don't have to worry about parallel make issues or portability)
> outweighs that.
Could you please link or otherwise explain the portability issue?

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[gentoo-dev] Last rites: app-crypt/cryptkeeper

[Matthias Maier]

# Matthias Maier  (31 Jan 2017)
# Dead upstream (no development since 2010) [1,2], outstanding security
# issue with newer encfs versions [3], oustanding Gentoo bugs [4,5].
# Mask for removal in 30 days.
# [1] https://github.com/tomm/cryptkeeper/commits/master
# [2] https://github.com/tomm/cryptkeeper/issues/
# [3] https://bugs.gentoo.org/show_bug.cgi?id=607772
# [4] https://bugs.gentoo.org/show_bug.cgi?id=448360
# [5] https://bugs.gentoo.org/show_bug.cgi?id=596832
app-crypt/cryptkeeper

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[Matt Turner]

On Mon, Jan 30, 2017 at 12:04 PM, William Hubbs  wrote:
> All,
>
> I have been looking at the meson build system [1] [2], and I like what I
> see.
>
> I have opened an issue on OpenRC's github wrt migrating OpenRC to the
> meson build system [3].
>
> As I said on the bug, the downside is the addition of py3 and ninja as
> build time dependencies, but I think the upside (a build system where
> we don't have to worry about parallel make issues or portability)
> outweighs that.
>
> What do folks think here?

This seems like a bad idea, for most of the reasons given by @skarnet.

The additional build-time dependencies are bad for such a small and
core project. And for what? Faster build times? OpenRC builds in less
than 4 seconds on my system.

You claimed parallel make check is broken, citing [1], but that
actually occurs with -j1 as well, making me question whether you've
investigated the bug at all.

Cart before the horse...

[1] https://bugs.gentoo.org/show_bug.cgi?id=374191

[gentoo-portage-dev] [PATCH] sync.py: add warning when sync-type is not set

[Alexandru Elisei]

---
 pym/portage/emaint/modules/sync/sync.py | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/pym/portage/emaint/modules/sync/sync.py
b/pym/portage/emaint/modules/sync/sync.py
index 076297a..b4d65e7 100644
--- a/pym/portage/emaint/modules/sync/sync.py
+++ b/pym/portage/emaint/modules/sync/sync.py
@@ -205,9 +205,15 @@ class SyncRepos(object):
k = "--" + k.replace("_", "-")
self.emerge_config.opts[k] = v

-   selected_repos = [repo for repo in selected_repos if 
repo.sync_type
is not None]
msgs = []
-   if not selected_repos:
+   valid_repos = []
+   for repo in selected_repos:
+   if repo.sync_type is None:
+   msgs.extend([warn(" * ") + "Missing sync-type 
for repo: " + \
+   repo.name +  ", skipping...\n"])
+   else:
+   valid_repos.append(repo)
+   if not valid_repos:
msgs.append("Emaint sync, nothing to sync... returning")
if return_messages:
msgs.extend(self.rmessage([('None', os.EX_OK)], 
'sync'))
@@ -223,7 +229,7 @@ class SyncRepos(object):
if 'parallel-fetch' in self.emerge_config.
target_config.settings.features else 1)
sync_scheduler = SyncScheduler(emerge_config=self.emerge_config,
-   selected_repos=selected_repos, 
sync_manager=sync_manager,
+   selected_repos=valid_repos, sync_manager=sync_manager,
max_jobs=max_jobs,
event_loop=global_event_loop() if 
portage._internal_caller else
EventLoop(main=False))
-- 
2.10.2

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[Joshua Kinard]

On 01/30/2017 15:04, William Hubbs wrote:
> All,
> 
> I have been looking at the meson build system [1] [2], and I like what I
> see.
> 
> I have opened an issue on OpenRC's github wrt migrating OpenRC to the
> meson build system [3].
> 
> As I said on the bug, the downside is the addition of py3 and ninja as
> build time dependencies, but I think the upside (a build system where
> we don't have to worry about parallel make issues or portability)
> outweighs that.
> 
> What do folks think here?
> 
> Thanks,
> 
> William
> 
> [1] https://mesonbuild.com
> [2] https://www.youtube.com/watch?v=ae9_rNuFaQM
> [3] https://github.com/OpenRC/openrc/issues/116

dev-util/ninja is hosed at the moment on a hardened/amd64 system built using
gcc-6.x.  See Bug #604198.  This one package is holding up my dev box from
updating clang/llvm and several other dependent packages.  I've given up trying
to debug it, too.  It's something gcc-6.x is doing, code-generation-wise, that
is beyond my ability to troubleshoot.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] Last rites: leechcraft

[David Seifert]

On Tue, 2017-01-31 at 17:34 +0100, Kristian Fiskerstrand wrote:
> On 01/31/2017 03:50 PM, Georg Rudoy wrote:
> > I'll make a new release of leechcraft itself and bump the version
> > to
> > that new one, so they'll naturally be dropped to unstable, 0.6.70
> > and
> > earlier (if any) indeed could be removed. Most of the bugs, as I
> > saw
> > them, are due to the current last released version being 2.5 years
> > old
> > and obviously bitrotten somewhat since then.
> 
> I'd still recommend spending a bit of time to consider whether this
> doesn't fit better in an overlay, which would also make it easier to
> maintain without overburdening proxy maint given the number of
> packages
> involved.
> 

I really second this - we can ask infra to get you an overlay. Should
it turn out that you are truly maintaining stuff, we can then merge it
into the tree.

Re: [gentoo-dev] Last rites: leechcraft

[Kristian Fiskerstrand]

On 01/31/2017 03:50 PM, Georg Rudoy wrote:
> I'll make a new release of leechcraft itself and bump the version to
> that new one, so they'll naturally be dropped to unstable, 0.6.70 and
> earlier (if any) indeed could be removed. Most of the bugs, as I saw
> them, are due to the current last released version being 2.5 years old
> and obviously bitrotten somewhat since then.

I'd still recommend spending a bit of time to consider whether this
doesn't fit better in an overlay, which would also make it easier to
maintain without overburdening proxy maint given the number of packages
involved.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: dev-python/mwlib

[Mike Gilbert]

# Mike Gilbert  (31 Jan 2017)
# Depends on old version of dev-python/pyparsing.
# Removal in 30 days.
dev-python/mwlib
dev-python/mwlib-rl

Re: [gentoo-dev] Last rites: leechcraft

[Davide Pesavento]

On Tue, Jan 31, 2017 at 9:50 AM, Georg Rudoy <0xd34df...@gmail.com> wrote:
> 2017-01-31 3:22 GMT-05:00 David Seifert :
>> Proxy-maint has always been there, so no real excuse for all those bugs
>> rotting away.
>
> I didn't bother with finding another maint who'd proxy it for me,
> yeah, that's my bad.
>
>
>> Here's the deal: If you fix all those bugs within the 30
>> day time period, we'll keep it in the tree. Please also modernize the
>> eclass a bit, and preferably drop all ebuilds to unstable.
>
> I'll make a new release of leechcraft itself and bump the version to
> that new one, so they'll naturally be dropped to unstable, 0.6.70 and
> earlier (if any) indeed could be removed. Most of the bugs, as I saw
> them, are due to the current last released version being 2.5 years old
> and obviously bitrotten somewhat since then.
>
> The ebuilds I have around use multibuild to build both qt4 and qt5
> versions according to use flags. Is that still relevant, or the world
> has migrated to qt5 and the benefit of still supporting qt4 is not
> worth the effort and clumsiness?

Yeah, drop qt4 please.

Thanks,
Davide

Re: [gentoo-dev] Last rites: leechcraft

[Georg Rudoy]

2017-01-31 3:22 GMT-05:00 David Seifert :
> Proxy-maint has always been there, so no real excuse for all those bugs
> rotting away.

I didn't bother with finding another maint who'd proxy it for me,
yeah, that's my bad.


> Here's the deal: If you fix all those bugs within the 30
> day time period, we'll keep it in the tree. Please also modernize the
> eclass a bit, and preferably drop all ebuilds to unstable.

I'll make a new release of leechcraft itself and bump the version to
that new one, so they'll naturally be dropped to unstable, 0.6.70 and
earlier (if any) indeed could be removed. Most of the bugs, as I saw
them, are due to the current last released version being 2.5 years old
and obviously bitrotten somewhat since then.

The ebuilds I have around use multibuild to build both qt4 and qt5
versions according to use flags. Is that still relevant, or the world
has migrated to qt5 and the benefit of still supporting qt4 is not
worth the effort and clumsiness?

> Send all your PRs via Github, mentioning my handle @SoapGentoo.

Thanks, will do.


-- 
  Georg Rudoy

Re: [gentoo-dev] Last rites: leechcraft

[David Seifert]

On Mon, 2017-01-30 at 17:43 -0500, Georg Rudoy wrote:
> 2017-01-30 13:35 GMT-05:00 David Seifert :
> > Please do not resurrect leechcraft unless you're willing to fix the
> > bugs with GCC 5 (and GCC 6) and newer dependencies. Personally, I
> > feel
> > leechcraft should probably live in an overlay instead of the tree.
> 
> I was previously proxy-maintaining it via Maxim Koltsov aka
> maksbotan.
> What's the best way for me to step up and maintain it more directly?
> Would PRs on github work?
> 
> 

Proxy-maint has always been there, so no real excuse for all those bugs
rotting away. Here's the deal: If you fix all those bugs within the 30
day time period, we'll keep it in the tree. Please also modernize the
eclass a bit, and preferably drop all ebuilds to unstable. Send all
your PRs via Github, mentioning my handle @SoapGentoo. Given that this
leechcraft ecosystem has a very small, dedicated community, I think
maintaining it in a separate overlay, pulled in by layman or whatever
would still be a better approach.