[gentoo-project] Re: [gentoo-dev-announce] Call for Council Agenda Items - 14 Oct 2014

[gentoo-project] Re: [gentoo-dev-announce] Call for Council Agenda Items - 14 Oct 2014

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

>>>>> On Tue, 30 Sep 2014, Rich Freeman wrote:

> The next Gentoo Council meeting is on 14 Oct 2014 at 19:00 UTC.
> The draft agenda is posted and will be updated at:
> http://dev.gentoo.org/~rich0/council/council_agenda_20141014.txt

> If you'd like to contribute another agenda item, please reply to
> this email.

Let's vote on removal of the einstall function in EAPI 6, please.

Discussion reference:
http://thread.gmane.org/gmane.linux.gentoo.devel/92713

Quoting mgorny:

| 1. einstall is confusing to new developers and contributors who
| often see it as the 'proper' way of installing software -- mostly
| because of the name matching econf/emake/einstall scheme. Likely
| that scheme was desired in the past.
|
| 2. The use for it is pretty scarce. Major build systems and most of
| the common custom Makefiles support DESTDIR. For the few remaining
| cases, it's rather optimistic throwing of variables into make, and
| hoping they would work.

Furthermore:
- Addition of --docdir and --htmldir to econf would require extending
  the existing einstall function, i.e. docdir and htmldir would have
  to be passed as additional variables. Otherwise, docdir and htmldir
  from configure would override the prefix passed to make.
- einstall is conceptionally strange. As noted by mgorny in item 2
  above, it assumes on the one hand that the build system doesn't
  support DESTDIR (so must be something other than autotools based).
  On the other hand, it assumes that the Makefile supports variables
  like prefix and libdir (which are autotools variables).
- As of 2014-09-13, only 218 ebuilds were using einstall, which is
  less than 0.6 % of all ebuilds in the tree. Such scarce usage
  doesn't justify a shortcut function in the package manager. It is
  trivial to change the remaining ebuilds to call the expanded "emake
  install" instead (and typically, only a subset of variables will be
  needed).

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-project] Re: Call for Council Agenda Items - 14 Oct 2014

[Rich Freeman]

On Tue, Sep 30, 2014 at 10:08 PM, Rich Freeman <rich0@gentoo.org> wrote:
>
> If you'd like to contribute another agenda item, please reply to this email.
>

I'll offer up a further topic for the git migration.

I propose that we're basically ready to go with the git migration.  We
have a proposed workflow, we have a reasonable migration path for
history, and a "perfect" migration process for the current tree, and
we now have back-end scripts for adding metadata, manifests, etc and
creating an rsync tree.

There are open questions around things like news and changelogs
already on the agenda.

I'm not quite sure how to frame the question I'd like the council to
answer, but I'd really like to get this down to, "is anything left or
can we do this already?"

The biggest concerns I see as pending are changelogs which have
already been hashed out, and whether we need a better migration of the
cvs history before we go.  Changelogs have already been hashed out so
I'll summarize where migration of history stands.

Right now the migration process generates a full cvs history in git,
with a number of caveats:
1.  CVS tracks history at the file level, git at the tree level.  The
migration process tries to match up corresponding changes, but this is
far from perfect.  So, many commits will contain non-matching
manifests and files, which means manifests will not pass.  The only
place we can be sure there won't be manifest issues (other than those
already in cvs) is in the final commit, which matches the active tree.

2.  CVS keywords are a mess in general.  There are a bunch of
situations which cause them to not match.  This could be improved, but
I'm really wondering if we should bother.

I'd propose that we really make the requirement be that the final tree
with manifests matches.  We're actually going to ditch the manifests
anyway, and likely even header keywords and changelogs (likely in
later commits).  Many projects have migrated to git without setting a
goal of a perfect history migration, and our heavy use of keywords and
manifests makes our case particularly tricky if we want a "perfect"
migration.

Now that git has the "replace" function I'd suggest that we view the
tree moving forward and the historical tree as separate problems.  We
can migrate the active tree to git and move forward, and then we can
make a pretty useful git migration for those who want to look
backwards.  If anybody wants to further improve the historical tree
they could do so at any time - all the code is open source and we can
make the data available.  However, I just don't know much interest
there really is in a "perfect" historical migration and certainly
there isn't an army of volunteers working to improve cvs2svn/etc.  In
fact, half the issues I do run into involve digging up 10-year-old
mailing list posts since that was when most of the rest of the world
was interested in ditching cvs.

Obviously the actual migration requires some coordination with
infra/etc, but I'd like to shift the bias towards action and ask "why
not now?"  If there are good reasons to wait, let's discuss them,
agree whether they're issues, and then work out a plan to resolve
them.

--
Rich

Re: [gentoo-project] Re: Call for Council Agenda Items - 14 Oct 2014

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]

Dnia 2014-10-01, o godz. 13:30:55
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Tue, Sep 30, 2014 at 10:08 PM, Rich Freeman <rich0@gentoo.org> wrote:
> > If you'd like to contribute another agenda item, please reply to this email.
> 
> I'll offer up a further topic for the git migration.

I think that there are a few issues that the Council may actually want
to discuss.


1. Security
-----------

Right now, all the 'mainline' commits in dev repo need to be signed
by Gentoo developers. However, the 'B' (and further) branches of merge
commits are allowed to be unsigned (or signed using non-Gentoo key)
-- which makes it possible to merge pull requests while preserving
original commits. We have server-side verification of signatures on
pushes; we don't have portage-side verification of incoming commits but
I don't think that's a major blocker.

The user syncing repo uses merge commits to preserve original dev tree
signatures. Both the merges and extra metadata commits are signed using
automated signing key.

The rsync repository contains thick Manifests signed using automated
signing key. Here, the signature verification is implemented completely
in Portage. We may want to use MetaManifests in the future but I doubt
that would be a blocker.

Also, the gentoo-keys project mentioned that we are disallowing Gentoo
developers to push commits signed using another developer's key. Not
sure if that's something really beneficial, so Council may want to
revisit that as well. And anyway, we always have merge commits for
double-signing.


2. ChangeLogs
-------------

The matter of ChangeLogs is still not entirely clear. Right now, we are
removing them completely and keeping old ones in history. From a little
insight we did, users are completely content with having the access to
history of changes via the historical repo and/or
gitweb/cgit/github/... The fact is that most of those tools provide
much better and more complete tools for analyzing changes than
ChangeLogs had.

In particular, this means that changes are supposed to be described
properly in commit messages. In case of necessity, 'git notes' can be
used to amend the messages.

It is possible to generate ChangeLogs in rsync. However, this seems
mostly pointless (and unnecessarily complex to implement) since most of
the users don't use them, and for the remaining uses cases they are not
good enough. Especially that we have git syncing repo that preserves
post-migration history, including commit messages and ability to lookup
the changes.


3. CVS Headers
--------------

The hateful thing. We could supposedly somehow fill them in rsync but
that's complex and very dangerous (think of all the broken patch files
currently in gx86). I think we should kill them.

And while at it, I think it'd be good to actually remove most of them
from our files -- changing header templates and so on. While not
strictly useful, it decreases the size of the repo a bit and avoids any
future nightmares :).

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

[gentoo-project] Re: [gentoo-dev-announce] Call for Council Agenda Items - 14 Oct 2014

[Andreas K. Huettel]

Here's another item suggestion:

"
Since the following both projects seem to be "stuck" at the moment, and since 
it is useful to finish pending big projects before starting new ones, the 
council would like to ask for a general update from involved parties on

1) the multilib porting and subsequent disposal of emul-... packages
2) the migration of project web pages to our wiki
"

Cheers, Andreas


Am Mittwoch, 1. Oktober 2014, 04:08:18 schrieb Rich Freeman:
> The next Gentoo Council meeting is on 14 Oct 2014 at 19:00 UTC.
> 
> The draft agenda is posted and will be updated at:
> http://dev.gentoo.org/~rich0/council/council_agenda_20141014.txt
> 
> If you'd like to contribute another agenda item, please reply to this
> email.
> 
> As usual, please discuss agenda items in separate threads, though I
> suspect that as usual this will be ignored.  :)
> 
> --
> Rich


-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for Council Agenda Items - 14 Oct 2014

[Rich Freeman]

On Fri, Oct 3, 2014 at 4:23 PM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> Here's another item suggestion:
>
> "
> Since the following both projects seem to be "stuck" at the moment, and since
> it is useful to finish pending big projects before starting new ones, the
> council would like to ask for a general update from involved parties on
>
> 1) the multilib porting and subsequent disposal of emul-... packages
> 2) the migration of project web pages to our wiki

To clarify, are you asking the council to debate whether we want to
ask for an update, or are you just asking for an update (which doesn't
really require a council discussion)?

I don't mind putting it on the agenda, per se, but just what were you
looking for the council to provide?

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for Council Agenda Items - 14 Oct 2014

[Andreas K. Huettel]

Am Samstag, 4. Oktober 2014, 00:41:44 schrieb Rich Freeman:

> To clarify, are you asking the council to debate whether we want to
> ask for an update, or are you just asking for an update (which doesn't
> really require a council discussion)?
> 
> I don't mind putting it on the agenda, per se, but just what were you
> looking for the council to provide?

I'm happy if the update is magically triggered by this mail and appears on the 
mailing list even before the meeting. :)

Otherwise the council could ask for one. 

Either case doesn't really require a discussion.

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for Council Agenda Items - 14 Oct 2014

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

Dnia 2014-10-04, o godz. 14:30:02
"Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):

> Am Samstag, 4. Oktober 2014, 00:41:44 schrieb Rich Freeman:
> 
> > To clarify, are you asking the council to debate whether we want to
> > ask for an update, or are you just asking for an update (which doesn't
> > really require a council discussion)?
> > 
> > I don't mind putting it on the agenda, per se, but just what were you
> > looking for the council to provide?
> 
> I'm happy if the update is magically triggered by this mail and appears on the 
> mailing list even before the meeting. :)

It won't be magically triggered since the team lead is waiting for this
clarification :P.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for Council Agenda Items - 14 Oct 2014

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

Dnia 2014-10-03, o godz. 22:23:10
"Andreas K. Huettel" <dilfridge@gentoo.org> napisał(a):

> 1) the multilib porting and subsequent disposal of emul-... packages

Ok, I finally have some free time, so I'm going to do a short update on
our progress:

1. package porting: almost done, there are two major blockers:

1a. Qt4 [1], the Qt team is still working on multilib support in their
overlay,

1b. samba-4 -- the new version is simply insane and hard-masked now.
Not sure if and when we're going to port it.

2. Dependency updates [2] are stuck midway games. With no help from
games team, the fact that most of the current dependencies don't
make sense and that most of the games are proprietary, you shouldn't
expect much sane progress anytime soon. Likely we're just going to end
up updating the current dependencies knowing they're likely wrong.

3. Mis-synced stabilizations [3] are almost fixed. We're waiting for
arch teams to finish stabilizing jasper & gtest.

Once all of that is done, we will need to request stabilizations on
remaining multilib packages.

[1]:https://bugs.gentoo.org/show_bug.cgi?id=498010
[2]:https://wiki.gentoo.org/wiki/Multilib_porting_status#Dependency_update_status
[3]:https://bugs.gentoo.org/show_bug.cgi?id=513718

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for Council Agenda Items - 14 Oct 2014

[Pacho Ramos]

El lun, 13-10-2014 a las 11:04 +0200, Michał Górny escribió:
[...]
> 1b. samba-4 -- the new version is simply insane and hard-masked now.
> Not sure if and when we're going to port it.
> 

Not porting samba-4 wouldn't be a regression over current emul packages
that only include 32bits libs for stable samba anyway :/

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for Council Agenda Items - 14 Oct 2014

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

Dnia 2014-10-13, o godz. 11:59:10
Pacho Ramos <pacho@gentoo.org> napisał(a):

> El lun, 13-10-2014 a las 11:04 +0200, Michał Górny escribió:
> [...]
> > 1b. samba-4 -- the new version is simply insane and hard-masked now.
> > Not sure if and when we're going to port it.
> > 
> 
> Not porting samba-4 wouldn't be a regression over current emul packages
> that only include 32bits libs for stable samba anyway :/

But it would explicitly prevent people from upgrading to samba-4.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for Council Agenda Items - 14 Oct 2014

[Pacho Ramos]

El lun, 13-10-2014 a las 12:06 +0200, Michał Górny escribió:
> Dnia 2014-10-13, o godz. 11:59:10
> Pacho Ramos <pacho@gentoo.org> napisał(a):
> 
> > El lun, 13-10-2014 a las 11:04 +0200, Michał Górny escribió:
> > [...]
> > > 1b. samba-4 -- the new version is simply insane and hard-masked now.
> > > Not sure if and when we're going to port it.
> > > 
> > 
> > Not porting samba-4 wouldn't be a regression over current emul packages
> > that only include 32bits libs for stable samba anyway :/
> 
> But it would explicitly prevent people from upgrading to samba-4.
> 

Umm, I guess you are referring on people that can now rely on emul-linux
package providing the samba3 32 bits libs even allowing them to update
to samba4 for the rest. Wouldn't be possible to have some kind of
"compat" package (or slot) that would only build and install the samba3
32bits libs? (that shouldn't collide with the 64 bits libs provided by
plain samba packages as it's the case now with the mix of plain samba
and emul package?)

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for Council Agenda Items - 14 Oct 2014

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]

>>>>> On Mon, 13 Oct 2014, Michał Górny wrote:

> 2. Dependency updates [2] are stuck midway games. With no help from
> games team, the fact that most of the current dependencies don't
> make sense and that most of the games are proprietary, you shouldn't
> expect much sane progress anytime soon. Likely we're just going to
> end up updating the current dependencies knowing they're likely
> wrong.

"Il meglio è l'inimico del bene." -- Voltaire

You could start with the dependencies currently in ebuilds, and in
addition use tools like scanelf or lddtree for scanning the binaries
installed by the package. (Or even the old tools for porting packages
to modular X [4] could be used; it's a very similar task.)

IMHO this would give you a very reasonable approximation of the true
dependencies. Some details (like correct USE dependencies on libSDL)
might be missed, but these can be fixed later. In any case, the
updated dependencies will be an improvement over the current ones,
so I won't see any of these small imperfections as a blocker.

Ulrich


> [1]:https://bugs.gentoo.org/show_bug.cgi?id=498010
> [2]:https://wiki.gentoo.org/wiki/Multilib_porting_status#Dependency_update_status
> [3]:https://bugs.gentoo.org/show_bug.cgi?id=513718

[4] https://www.gentoo.org/proj/en/desktop/x/x11/porting-modular-x-howto.xml

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for Council Agenda Items - 14 Oct 2014

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

Dnia 2014-10-13, o godz. 14:54:56
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> >>>>> On Mon, 13 Oct 2014, Michał Górny wrote:
> 
> > 2. Dependency updates [2] are stuck midway games. With no help from
> > games team, the fact that most of the current dependencies don't
> > make sense and that most of the games are proprietary, you shouldn't
> > expect much sane progress anytime soon. Likely we're just going to
> > end up updating the current dependencies knowing they're likely
> > wrong.
> 
> "Il meglio è l'inimico del bene." -- Voltaire
> 
> You could start with the dependencies currently in ebuilds, and in
> addition use tools like scanelf or lddtree for scanning the binaries
> installed by the package. (Or even the old tools for porting packages
> to modular X [4] could be used; it's a very similar task.)

Proprietary games == no binaries for me.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for Council Agenda Items - 14 Oct 2014

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 413 bytes --]

On Mon, 13 Oct 2014 14:54:56 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> "Il meglio è l'inimico del bene." -- Voltaire

Usually when this gets waved around it's as an excuse for doing a
deliberately crappy job of something when doing it properly is only
slightly more difficult... Bad solutions are sometimes necessary, but
they're not something to be proud of or to advocate.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for Council Agenda Items - 14 Oct 2014

[Rich Freeman]

On Mon, Oct 13, 2014 at 8:59 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2014-10-13, o godz. 14:54:56
> Ulrich Mueller <ulm@gentoo.org> napisał(a):
>
>> >>>>> On Mon, 13 Oct 2014, Michał Górny wrote:
>>
>> > 2. Dependency updates [2] are stuck midway games. With no help from
>> > games team, the fact that most of the current dependencies don't
>> > make sense and that most of the games are proprietary, you shouldn't
>> > expect much sane progress anytime soon. Likely we're just going to
>> > end up updating the current dependencies knowing they're likely
>> > wrong.
>>
>> "Il meglio è l'inimico del bene." -- Voltaire
>>
>> You could start with the dependencies currently in ebuilds, and in
>> addition use tools like scanelf or lddtree for scanning the binaries
>> installed by the package. (Or even the old tools for porting packages
>> to modular X [4] could be used; it's a very similar task.)
>
> Proprietary games == no binaries for me.

My thought is that we should do what we can with what we have, give
notice to the maintainers, and pull the plugs on the emul packages (or
at least stop maintaining them, pulling them if they have security
issues).

I think the fact that we can have non-redistributable or even
proprietary software in portage is actually one of Gentoo's strengths.
However, it still needs to be maintained.  We can better tolerate
inactive maintainers for FOSS since anybody can step in and maintain
them.

If a proprietary package breaks, then it should be treecleaned.  I
don't think we have to tiptoe around them to keep this from happening.
They need to be maintained like any other package.