Re: [gentoo-dev] Re: [RFC] First (experimental) 17.1 profiles news item for review (v2)

2017-12-20 Thread Matthew Thode
On 17-12-21 08:34:31, Michał Górny wrote:
> W dniu czw, 21.12.2017 o godzinie 05∶29 +, użytkownik Duncan
> napisał:
> > Michał Górny posted on Wed, 20 Dec 2017 14:40:27 +0100 as excerpted:
> > 
> > In all this I don't see an answer to one question:
> > 
> > Will this eventually be the only supported choice, or is the 
> > compatibility-symlinked version going to be supported going forward too?  
> > If it's to be only-supported, what's the timeline?
> 
> The former. We'll make a timeline when the profiles are tested
> and stable.
> 

What group are the ones making this decision?

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: [RFC] First (experimental) 17.1 profiles news item for review (v2)

2017-12-20 Thread Michał Górny
W dniu czw, 21.12.2017 o godzinie 05∶29 +, użytkownik Duncan
napisał:
> Michał Górny posted on Wed, 20 Dec 2017 14:40:27 +0100 as excerpted:
> 
> > A new set of 17.1 amd64 profiles has been added to the Gentoo
> > repository. Those profiles switch to a more standard 'no SYMLINK_LIB'
> > multilib layout,
> > and require explicit migration as described below. They are considered
> > experimental at the moment, and have a fair risk of breaking your
> > system. We would therefore like to ask our users to test them on their
> > non-production ~amd64 systems.
> > 
> > In those profiles, the lib->lib64 compatibility symlink is removed.
> > The 'lib' directory becomes a separate directory, that is used for
> > cross-arch and native non-library packages (gcc, clang) and 32-bit
> > libraries on the multilib profile (for better compatibility with
> > prebuilt x86 packages).
> 
> 
> In all this I don't see an answer to one question:
> 
> Will this eventually be the only supported choice, or is the 
> compatibility-symlinked version going to be supported going forward too?  
> If it's to be only-supported, what's the timeline?

The former. We'll make a timeline when the profiles are tested
and stable.

> Here's why I'm asking:  I'm on nomultilib and already have usrmerge (tho 
> reverse, with / being canonical and /usr -> .), and (s)bin merge, so I 
> already have a single canonical /bin and a single canonical /lib64, with 
> various symlinks making the other paths work as well.
> 
> So there's no reason or benefit to me splitting /lib and /lib64 again, as 
> that would go against the concept of the usr and sbin merges I've already 
> done, and the long-time lib merges that gentoo has had on amd64 since 
> before I switched to gentoo in 2004.  I've found I quite /like/ having a 
> single bin dir and a single lib dir for everything, and this would undo 
> that, forcing me to mentally track separate lib locations once again.

Custom setups were never really supported. It may work, it may not.
If you report a bug, it may be fixed or someone may close it as INVALID
or UPSTREAM. In particular, you'll probably have to deal with upstreams
yourself.

-- 
Best regards,
Michał Górny




[gentoo-dev] Re: [RFC] First (experimental) 17.1 profiles news item for review (v2)

2017-12-20 Thread Duncan
Michał Górny posted on Wed, 20 Dec 2017 14:40:27 +0100 as excerpted:

> A new set of 17.1 amd64 profiles has been added to the Gentoo
> repository. Those profiles switch to a more standard 'no SYMLINK_LIB'
> multilib layout,
> and require explicit migration as described below. They are considered
> experimental at the moment, and have a fair risk of breaking your
> system. We would therefore like to ask our users to test them on their
> non-production ~amd64 systems.
> 
> In those profiles, the lib->lib64 compatibility symlink is removed.
> The 'lib' directory becomes a separate directory, that is used for
> cross-arch and native non-library packages (gcc, clang) and 32-bit
> libraries on the multilib profile (for better compatibility with
> prebuilt x86 packages).


In all this I don't see an answer to one question:

Will this eventually be the only supported choice, or is the 
compatibility-symlinked version going to be supported going forward too?  
If it's to be only-supported, what's the timeline?


Here's why I'm asking:  I'm on nomultilib and already have usrmerge (tho 
reverse, with / being canonical and /usr -> .), and (s)bin merge, so I 
already have a single canonical /bin and a single canonical /lib64, with 
various symlinks making the other paths work as well.

So there's no reason or benefit to me splitting /lib and /lib64 again, as 
that would go against the concept of the usr and sbin merges I've already 
done, and the long-time lib merges that gentoo has had on amd64 since 
before I switched to gentoo in 2004.  I've found I quite /like/ having a 
single bin dir and a single lib dir for everything, and this would undo 
that, forcing me to mentally track separate lib locations once again.


So I'll probably keep my merged lib here, managing it much like I do my 
merged bin and root/usr, but it'd be nice to know whether that's going to 
remain an official layout or not, and if not, what the timeframe for 
removing it is.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




Re: [gentoo-dev] Projects up for grabs: cron, m68k

2017-12-20 Thread Jason Zaman
On Wed, Dec 20, 2017 at 06:29:57PM +0100, Hans de Graaff wrote:
> On Wed, 2017-12-20 at 18:02 +0100, Michał Górny wrote:
> > 
> >   sys-process/vixie-cron
> 
> My understanding is that vixie-cron is no longer maintained and sys-
> process/cronie is the drop-in replacement that is now also suggested as
> the default cron in the handbook.
> 
> https://archives.gentoo.org/gentoo-dev/message/d898f86f805909eb72aba61d
> 2dca8523
> 
> I seem to recall a more recent discussion about this as well, but can't
> find it at the moment.
> 
> Perhaps it is time to mask vixie-cron for removal?

I just updated the SELinux patch on vixie-cron and stabilized it a while
ago, it works fine and doesnt need all that much maintenance. I vote
keep it, i'll look after it. If it has some big architectural issues
later then we can last-rite it but its been reliable so far.

I added myself to the Cron project with blueness.

-- Jason




Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

2017-12-20 Thread R0b0t1
On Sat, Dec 16, 2017 at 9:42 AM, Aaron W. Swenson  wrote:
> According to Merriam-Webster:
>
> self-evident
>  adjective | self-ev·i·dent | ˌself-ˈe-və-dənt , -ˌdent
>  evident without proof or reasoning
>

The version I used is taken from http://dd.pangyre.org/s/self-evident.html.

> You have been a part of the conversations that devolved into the
> non-technical, and even started your own decidedly non-technical
> discussion on this list[1] where you’ve seen that rules for moderation,
> or at least defining the expectations of moderators and participants,
> would have been beneficial.
>

Yes, it was non-technical, but it was related to Gentoo and most
importantly the stability of my operating system, which is why I
bothered to comment. I want to stress I am not opposed to moderation,
but so far the reason why things are happening and the specific things
being proposed do not seem to be well justified.

If, like in the past, decisions will be enforced more or less
arbitrarily and opaquely, I can only see this causing more problems. I
suppose the problems may be quieter.

Cheers,
 R0b0t1



Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

2017-12-20 Thread R0b0t1
On Sun, Dec 17, 2017 at 10:53 AM, Nils Freydank  wrote:
> There is a specific RFC about splitting the mailing list because of a
> problematic style of conversation.
>

Well, yes - but what is problematic? Certain parties keep vaguely
alluding to past actions, which is what I am inquiring about.

> Even if that split won’t happen -- I don’t know if mgorny has the "right" or
> support to do that and I personally want to stay out of these discussions -- I
> really *do* think that a moderation of a frequented mailing list like gentoo-
> dev is a generally good idea. Therefore we need properly documented rules
> (beside moderators).
>

I don't like being here either, but after using Gentoo for a while
arbitrary actions taken by developers have broken my system, and poor
commit discipline has in cases made it very hard to figure out what
was changed and why.

This is an outgrowth of those things. If arbitrary choices are made
here and now arbitrary choices will keep being made elsewhere in the
future.

For some reason a lot of people seem to think my questions are
annoying. They're not supposed to be annoying. If a decision is
happening with purpose, then spending 30s to type out that purpose
should not be annoying.

> To answer you question: I think the RFC introduces either a "time pressure" or
> should be seen as sign that this list needs an improvement.
>

See reply to first paragraph; I mean specific events that make the OP
feel this is necessary.

Cheers,
 R0b0t1



Re: [gentoo-dev] The problem of unmaintained packages in Gentoo

2017-12-20 Thread William Hubbs
On Wed, Dec 20, 2017 at 07:12:45PM -0500, Michael Orlitzky wrote:
> On 12/20/2017 06:58 PM, William Hubbs wrote:
> > 
> > There already is an overlay for dying packages, it is called graveyard,
> > but no one is putting things there.
> > 
> > This email conflates old dying packages with new versions, which are a
> > completely separate issue.
> > 
> 
> Lack of new versions *is* dying. But I can make a package not-dying in a
> few seconds by merging a PR, so long as you don't expect me to do the
> (relatively high) level of QA required for ~arch.
> 
> 
> > If a new version of a package is known to cause wide scale breakage, it
> > goes in package.mask until the breakage is resolved. Otherwise, putting
> > it in ~ is fine. I don't see the need for another level of keywords.
> 
> The quality of ~arch is its own worst enemy; these days, stable packages
> are just old ~arch packages. Users and developers expect ~arch to work,
> and we have no real policy or documentation stating that it won't. Many
> people will tell you that ~arch works better than stable, because it
> gets fixed faster.

~arch *will* have breakages from time to time, sometimes major
breakages, until they are masked or fixed. We are not supposed to leave
major breakages there, but ~arch is definitely not for the faint of
heart. If you are using ~arch, you are expected to be a power user at
leasst and be able to recover if your system breaks. Production servers
should not be running ~arch at all. That's the whole reason ~arch
exists.

Yes, ~arch gets fixed faster than stable, but that is to be expected.
However, it is definitely not a good reason to put your production system on
full ~arch.

So, I guess this means that the quality of the ~arch tree is supposed to
be somewhat lower than the quality of the stable tree.

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] The problem of unmaintained packages in Gentoo

2017-12-20 Thread Michael Orlitzky
On 12/20/2017 06:58 PM, William Hubbs wrote:
> 
> There already is an overlay for dying packages, it is called graveyard,
> but no one is putting things there.
> 
> This email conflates old dying packages with new versions, which are a
> completely separate issue.
> 

Lack of new versions *is* dying. But I can make a package not-dying in a
few seconds by merging a PR, so long as you don't expect me to do the
(relatively high) level of QA required for ~arch.


> If a new version of a package is known to cause wide scale breakage, it
> goes in package.mask until the breakage is resolved. Otherwise, putting
> it in ~ is fine. I don't see the need for another level of keywords.

The quality of ~arch is its own worst enemy; these days, stable packages
are just old ~arch packages. Users and developers expect ~arch to work,
and we have no real policy or documentation stating that it won't. Many
people will tell you that ~arch works better than stable, because it
gets fixed faster.

The new level of keyword would avoid screwing all of those ~arch users
at once, by not suddenly murdering the quality of their tree. From the
outset, the new level of keyword would have to have a description like
"only use this if you are stupid" to fulfill its intended role.



Re: [gentoo-dev] The problem of unmaintained packages in Gentoo

2017-12-20 Thread William Hubbs
On Wed, Dec 20, 2017 at 06:33:21PM -0500, Michael Orlitzky wrote:
> On 12/20/2017 02:41 PM, Virgil Dupras wrote:
> > 
> > Maybe some kind of official overlay for packages needing love? We
> > could send outdated packages there to die or to be born again if the
> > right person picks it up.
> > 
> > The overlay could have more relaxed rules (not malicious and looking
> > good? no need to test this, merge!) for PR merging. If the package
> > degrades through bad PRs, fine, let's let it die. If it improves,
> > good, it can be born again.
> > 
> > ...
> > 
> > (my apologies if this idea is not new, I haven't been following the
> > ML for very long.)
> 
> It's not a bad idea, but personally I'd like to see it as a third level
> of stability in the tree for users to opt into with ACCEPT_KEYWORDS.

There already is an overlay for dying packages, it is called graveyard,
but no one is putting things there.

This email conflates old dying packages with new versions, which are a
completely separate issue.

If a new version of a package is known to cause wide scale breakage, it
goes in package.mask until the breakage is resolved. Otherwise, putting
it in ~ is fine. I don't see the need for another level of keywords.

William


signature.asc
Description: Digital signature


Re: [gentoo-dev] The problem of unmaintained packages in Gentoo

2017-12-20 Thread Michael Orlitzky
On 12/20/2017 02:41 PM, Virgil Dupras wrote:
> 
> Maybe some kind of official overlay for packages needing love? We
> could send outdated packages there to die or to be born again if the
> right person picks it up.
> 
> The overlay could have more relaxed rules (not malicious and looking
> good? no need to test this, merge!) for PR merging. If the package
> degrades through bad PRs, fine, let's let it die. If it improves,
> good, it can be born again.
> 
> ...
> 
> (my apologies if this idea is not new, I haven't been following the
> ML for very long.)

It's not a bad idea, but personally I'd like to see it as a third level
of stability in the tree for users to opt into with ACCEPT_KEYWORDS.
Right now ~arch means,

  * I've built and tested this

and, because of how our package manager works,

  * I think this is more reliable than the previous ~arch version

Often that's a pretty high bar to meet.

For example, we have a pull request open right now[0] that adds an alpha
version of dev-php/xdebug-client to get php-7.2 support. It's probably
fine. The ebuild contains some minor, expected changes. Whatever, it
probably works. But, I don't use xdebug-client, and I don't think the
other member of the PHP team does either. Building php-7.2 takes a
while, and I'd have to do that and figure out how to do a basic "does
this work" test on the package to make sure it doesn't die immediately,
because otherwise the alpha version is going to ruin life for the people
who are using php-7.1 with the existing ~arch version.

But it's probably fine! It would be great if there was a third level of
stability called "whatever, it probably works." Then I could just merge
that PR and let the crazy people who have that in their ACCEPT_KEYWORDS
tell me if it breaks. Instead, it has to wait until one of two people
has the time to test/review it.


[0] https://github.com/gentoo/gentoo/pull/6586



Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

2017-12-20 Thread Nils Freydank
Am Mittwoch, 20. Dezember 2017, 17:48:54 CET schrieb kuzetsa:
> On 12/16/2017 10:14 AM, Nils Freydank wrote:
> > Am Dienstag, 5. Dezember 2017, 23:41:45 CET schrieb kuzetsa:
> >> On 12/05/2017 05:18 PM, Nils Freydank wrote:
> >>> 5. Reasons for warnings and bans
> >>> 
> >> 
> >> --snip--
> >>  --- other snip ---
> > 
> > Could you write a short paragraph for this?
> 
> Haven't been paying much attention to this thread.
> (I was quoted here - Point #c versus #d)
> 
> Am I being asked to write something up?
Yes, exactly that is what I’m asking for. I think your point c vs. d statement 
was that good it might be best if you’d write two or three sentences.

I’m not sure if the whole moderation approach will be followed anyway, but 
IMHO we should still give it a try.

-- 
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] The problem of unmaintained packages in Gentoo

2017-12-20 Thread Ilya Tumaykin
qlist -Iv $(portageq --repo gentoo --orphaned)

On Wednesday, 20 December 2017 23:54:27 MSK Christopher Head wrote:
> On December 20, 2017 8:49:03 AM PST, "Michał Górny"  wrote:
> >Ad. 1. We currently have over 1650 m-n packages [1] and the list keeps
> >growing. The advantage of this type is that we have an explicit list
> >and everyone clearly sees that the packages need a new maintainer. We
> >also have some dedicated people who try to help fixing worst issues
> >but they're obviously not capable of doing all the work themselves.
> 
> Is there an easy way to check whether any packages I have installed on my 
> system are m-n? I checked “man q” and “man equery” but neither seemed to 
> support searching by maintainer. The closest I found was “equery meta”, but 
> that requires a specific package name on the command line.
> 
> I read the last rites and it’s quite easy to notice if a package I actively 
> use is shown there, but that doesn’t help with the hundreds of libraries and 
> other dependencies whose names I don’t even really recognize but I have 
> installed.
> 
-- 
Best regards.
Ilya Tumaykin.



Re: [gentoo-dev] The problem of unmaintained packages in Gentoo

2017-12-20 Thread Christopher Head
On December 20, 2017 8:49:03 AM PST, "Michał Górny"  wrote:
>Ad. 1. We currently have over 1650 m-n packages [1] and the list keeps
>growing. The advantage of this type is that we have an explicit list
>and everyone clearly sees that the packages need a new maintainer. We
>also have some dedicated people who try to help fixing worst issues
>but they're obviously not capable of doing all the work themselves.

Is there an easy way to check whether any packages I have installed on my 
system are m-n? I checked “man q” and “man equery” but neither seemed to 
support searching by maintainer. The closest I found was “equery meta”, but 
that requires a specific package name on the command line.

I read the last rites and it’s quite easy to notice if a package I actively use 
is shown there, but that doesn’t help with the hundreds of libraries and other 
dependencies whose names I don’t even really recognize but I have installed.
-- 
Christopher Head

signature.asc
Description: PGP signature


Re: [gentoo-dev] The problem of unmaintained packages in Gentoo

2017-12-20 Thread Virgil Dupras
On Wed, 20 Dec 2017 17:49:03 +0100
Michał Górny  wrote:

> So does anyone have any ideas on what we could realistically do right
> now to improve things?

Maybe some kind of official overlay for packages needing love? We could send 
outdated packages there to die or to be born again if the right person picks it 
up.

The overlay could have more relaxed rules (not malicious and looking good? no 
need to test this, merge!) for PR merging. If the package degrades through bad 
PRs, fine, let's let it die. If it improves, good, it can be born again.

I'm under the impression that such an overlay could release pressure on 
proxy-maint, allow treecleaners to clean more aggressively while keeping users 
happy.

As a bonus, it could be an interesting path to becoming a gentoo developer. 
More relaxed rules could mean that anyone could assume maintainership of a 
dying package without having to wait for someone from proxy-maint to review 
every little change. This allows the would-be developer to be bolder with 
changes and prove herself better.

(my apologies if this idea is not new, I haven't been following the ML for very 
long.)

Regards,
Virgil Dupras



[gentoo-dev] Package up for grab

2017-12-20 Thread Anthony G. Basile
Hi everyone,

I was maintaining the following package

net-p2p/tribler

but I just dropped it to maintainer-needed.  Someone asked me for it,
but it needs work on bumping and its not that interesting/important to me.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Projects up for grabs: cron, m68k

2017-12-20 Thread Anthony G. Basile
On 12/20/17 12:07 PM, Anthony G. Basile wrote:
> On 12/20/17 12:02 PM, Michał Górny wrote:
>> Hello, everyone.
>>
>> Due to prolonged inactivity of Mike Frysinger (vapier), the following
>> projects have had effectively no members for 6 months already:
>>
>> https://wiki.gentoo.org/wiki/Project:Cron
>>
>>   sys-process/anacron [m]
>>   sys-process/at
>>   sys-process/bcron
>>   sys-process/cronbase
>>   sys-process/cronie [m]
>>   sys-process/dcron
>>   sys-process/fcron [m]
>>   sys-process/vixie-cron
>>   virtual/cron
>>
>> https://wiki.gentoo.org/wiki/Project:M68k
>>
>>   sys-apps/zorroutils [m]
>>   sys-fs/atari-fdisk
>>
>> The packages listed with '[m]' have other maintainers. The remaining
>> packages are solely maintained by the listed projects.
>>
>> If you are interested in helping out with some of those packages, please
>> consider joining the appropriate project and/or co-maintaining the
>> individual packages.
>>
>> If the projects see no activity within the next month, I will disband
>> them and move the appropriate packages to maintainer-needed.
>>
> 
> Those are very important packages.  I use fcron and at and I can help
> take care of those.  I should probably take a look a t cronbase and
> virtual/cron too.
> 

Okay a followup on my last email, I added myself to the project and will
try to take care of all cron packages.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Projects up for grabs: cron, m68k

2017-12-20 Thread Hans de Graaff
On Wed, 2017-12-20 at 18:02 +0100, Michał Górny wrote:
> 
>   sys-process/vixie-cron

My understanding is that vixie-cron is no longer maintained and sys-
process/cronie is the drop-in replacement that is now also suggested as
the default cron in the handbook.

https://archives.gentoo.org/gentoo-dev/message/d898f86f805909eb72aba61d
2dca8523

I seem to recall a more recent discussion about this as well, but can't
find it at the moment.

Perhaps it is time to mask vixie-cron for removal?

Hans

signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Projects up for grabs: cron, m68k

2017-12-20 Thread James Le Cuirot
On Wed, 20 Dec 2017 18:02:22 +0100
Michał Górny  wrote:

> Hello, everyone.
> 
> Due to prolonged inactivity of Mike Frysinger (vapier), the following
> projects have had effectively no members for 6 months already:
> 
> https://wiki.gentoo.org/wiki/Project:M68k
> 
>   sys-apps/zorroutils [m]

Aww, if only my (t)rusty old Amiga actually had a Zorro bus.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer



Re: [gentoo-dev] The problem of unmaintained packages in Gentoo

2017-12-20 Thread nado
Hi,

December 20, 2017 5:46 PM, "Michał Górny"  wrote:

> E. Some of the unmaintained packages are dependencies of other
> maintained packages in Gentoo. However, developers usually don't want
> to take them, even if their package is the only revdep.
> 
> F. We are usually treecleaning packages as they become severely outdated
> and broken. However, that takes serious amount of work too and usually
> results in a lot of hostility from other developers (who don't want to
> maintain the package in question) and users.
> 
> G. In the past, I've attempted to evaluate the status of projects and to
> clean some dead up. However, it's a lot of manual labor and it meets
> with hostility from some of the Gentoo developers.
> 
> H. For most things related to determining developer inactivity, we have
> little to no automation. It's easy to tell when a developer stops
> committing altogether but we have no special help in e.g. determining
> that some packages are effectively unmaintained (and that would of
> course meet with hostility).

I believe there was some work in progress about automating check for new 
upstream version (via
repology api I think).
Couldn't this be used to check for maintainer abandon? Some bugs can't always 
be solved easily, so
you can't take that into account to check for inactivity, but not adding new 
versions is, IMO, a
sign that the maintainer doesn’t check often enough for updates.
We could also send automatic mail a month (arbitrary choice) after a new 
version has been released
upstream to the maintainer for the related ebuild with such a system, so that 
maintainers don't
have to bother about that part anymore.

I can't remember what was called the project but what's its current status?
I don't know if a solution like that would change much to the situation, but I 
believe it should
give us better insights about the state of the tree.

Best regards,
--
Corentin “Nado” Pazdera



Re: [gentoo-dev] Projects up for grabs: cron, m68k

2017-12-20 Thread Lars Wendler
Am Wed, 20 Dec 2017 18:02:22 +0100
schrieb Michał Górny :

> Hello, everyone.
> 
> Due to prolonged inactivity of Mike Frysinger (vapier), the following
> projects have had effectively no members for 6 months already:
> 
> https://wiki.gentoo.org/wiki/Project:Cron
> 
>   sys-process/anacron [m]
>   sys-process/at

sys-process/at is lacking the [m]

>   sys-process/bcron
>   sys-process/cronbase
>   sys-process/cronie [m]
>   sys-process/dcron
>   sys-process/fcron [m]
>   sys-process/vixie-cron
>   virtual/cron
> 
> https://wiki.gentoo.org/wiki/Project:M68k
> 
>   sys-apps/zorroutils [m]
>   sys-fs/atari-fdisk
> 
> The packages listed with '[m]' have other maintainers. The remaining
> packages are solely maintained by the listed projects.
> 
> If you are interested in helping out with some of those packages,
> please consider joining the appropriate project and/or co-maintaining
> the individual packages.
> 
> If the projects see no activity within the next month, I will disband
> them and move the appropriate packages to maintainer-needed.
> 




Re: [gentoo-dev] Projects up for grabs: cron, m68k

2017-12-20 Thread Anthony G. Basile
On 12/20/17 12:02 PM, Michał Górny wrote:
> Hello, everyone.
> 
> Due to prolonged inactivity of Mike Frysinger (vapier), the following
> projects have had effectively no members for 6 months already:
> 
> https://wiki.gentoo.org/wiki/Project:Cron
> 
>   sys-process/anacron [m]
>   sys-process/at
>   sys-process/bcron
>   sys-process/cronbase
>   sys-process/cronie [m]
>   sys-process/dcron
>   sys-process/fcron [m]
>   sys-process/vixie-cron
>   virtual/cron
> 
> https://wiki.gentoo.org/wiki/Project:M68k
> 
>   sys-apps/zorroutils [m]
>   sys-fs/atari-fdisk
> 
> The packages listed with '[m]' have other maintainers. The remaining
> packages are solely maintained by the listed projects.
> 
> If you are interested in helping out with some of those packages, please
> consider joining the appropriate project and/or co-maintaining the
> individual packages.
> 
> If the projects see no activity within the next month, I will disband
> them and move the appropriate packages to maintainer-needed.
> 

Those are very important packages.  I use fcron and at and I can help
take care of those.  I should probably take a look a t cronbase and
virtual/cron too.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] Projects up for grabs: cron, m68k

2017-12-20 Thread Michał Górny
Hello, everyone.

Due to prolonged inactivity of Mike Frysinger (vapier), the following
projects have had effectively no members for 6 months already:

https://wiki.gentoo.org/wiki/Project:Cron

  sys-process/anacron [m]
  sys-process/at
  sys-process/bcron
  sys-process/cronbase
  sys-process/cronie [m]
  sys-process/dcron
  sys-process/fcron [m]
  sys-process/vixie-cron
  virtual/cron

https://wiki.gentoo.org/wiki/Project:M68k

  sys-apps/zorroutils [m]
  sys-fs/atari-fdisk

The packages listed with '[m]' have other maintainers. The remaining
packages are solely maintained by the listed projects.

If you are interested in helping out with some of those packages, please
consider joining the appropriate project and/or co-maintaining the
individual packages.

If the projects see no activity within the next month, I will disband
them and move the appropriate packages to maintainer-needed.

-- 
Best regards,
Michał Górny




Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

2017-12-20 Thread kuzetsa
On 12/16/2017 10:14 AM, Nils Freydank wrote:
> Am Dienstag, 5. Dezember 2017, 23:41:45 CET schrieb kuzetsa:
>> On 12/05/2017 05:18 PM, Nils Freydank wrote:
>>> 5. Reasons for warnings and bans
>>> 
>> --snip--
>>
>>> c) spamming, i.e. flooding discussions with lots of messages in a row
>>> d) constant postings off topic, i.e. disrupting discussions with unrelated
>>> questions
>>>
>>> (constant means more than two times in a row)
>> Point #c versus #d
>>
>> #c - there can (and often are) good faith reasons for
>> multiple postings "in a row", such as when responding
>> to multiple threads, and/or to multiple posters within
>> the same thread. Even just people who are awake (and
>> would respond) at a time when other participants in the
>> list would be sleeping could complicate this rule.
> Valid point.
>
>> #d - definition for constant seems unnecessary. For an
>> alternative, maybe refine the definition to either
>> use a 72 hour window or similar, or even just a basic
>> expectation for discussion to be germane (on-topic)
>> with refusal to stay on-topic (when warned) being the
>> measure. Perhaps three strikes (per day?) are when
>> the enforcement could start. parliament / congress
>> and other formal assemblies have models for this.
> Sounds good to me. As spamming is *always* off topic
> this should even catch point c).
>
> Could you write a short paragraph for this?

Haven't been paying much attention to this thread.
(I was quoted here - Point #c versus #d)

Am I being asked to write something up?

Clarification would be appreciated.

- kuzetsa



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] The problem of unmaintained packages in Gentoo

2017-12-20 Thread Michał Górny
Hello, everyone.

Jalus Bilieyich has submitted the following for the last Council
meeting:

| Discuss the lack of enough package maintainers to update ebuilds. Many
| ebuilds in the Portage tree can be easily marked outdated.

Given that the item didn't see any real discussion in the mailing lists,
and that it is a non-trivial problem, the Council has decided to bounce
it back to the mailing lists in a separate discussion thread.


The problem
===

The problem could be summarized shortly: the ebuilds need much more love
than they are given right now. This results in some packages being
outdated, half-broken and/or using obsolete constructs. In the end, some
of the packages start effectively blocking other developers from doing
their job (e.g. they can't solve one problem without fixing some other
pile of existing problems first).

I think we can list a few kinds of packages that need help in Gentoo:

1. Packages explicitly listed as not having a maintainer
   (maintainer-needed) [1].

2. Packages whose maintainer is MIA (including 'dead' projects).

3. Packages whose maintainer is not interested in maintaining them
   (or in some cases even unaware that he is the maintainer).

4. Packages whose maintainer is not capable of maintaining them 
   properly (or unwilling to, in some cases).

Now, for some details:

Ad. 1. We currently have over 1650 m-n packages [1] and the list keeps
growing. The advantage of this type is that we have an explicit list
and everyone clearly sees that the packages need a new maintainer. We
also have some dedicated people who try to help fixing worst issues
but they're obviously not capable of doing all the work themselves.

Ad. 2. This is somewhat problematic, developers usually notice
inactivity after some time and sometimes help out but things are rather
suboptimal right now. It can take 3-6 months from developer's
disappearance before his packages are announced 'up for grabs'
and someone actually interested can take them.

Things are even harder when the packages are maintained by projects
whose developers are no longer active.

Ad. 3. Sometimes developers lose interest or otherwise forget that they
maintain some package. This may result in some degradation but the
developer usually notices that when a new bug is reported and abandons
the package. This is the easier part.

The harder part is when packages are maintained by projects who aren't
really interested in them. This is especially a problem in herd-style
projects that collect large number of packages by a specific topic but
the individual project members are really interested in only a subset of
them.

Ad. 4. This is the hardest part. We have some packages which are
maintained but whose maintainers can't really keep up with work. In this
case it's usually hard to determine that the maintainer needs help with
a specific package, and/or whether he wishes to accept it.

What's even worse, there were historical cases when maintainers
'claimed' packages but were rather interested in prevented others
from  the maintenance work ('breaking them') or removing them.
At the same time weren't really interested in fixing bugs or updating
the packages.


Solutions?
==

So does anyone have any ideas on what we could realistically do right
now to improve things? Few notes from what I've seen:

A. Recruiters process new recruits quite smoothly but we don't have many
candidates interested in package management. Even then, I don't see
every new recruit taking 50+ packages...

B. Proxy-maint constantly lacks manpower to process contributions.
However, once again we can't expect a lot of packages per maintainer,
and we need to account for doubled manpower cost.

C. We have a lot of overlays. Some of their maintainers are quite
capable. Can we do something about that?

D. All above considered, we still haven't dealt with the copyright
issues. The work on last draft was stalled one year ago [2].

E. Some of the unmaintained packages are dependencies of other
maintained packages in Gentoo. However, developers usually don't want
to take them, even if their package is the only revdep.

F. We are usually treecleaning packages as they become severely outdated
and broken. However, that takes serious amount of work too and usually
results in a lot of hostility from other developers (who don't want to
maintain the package in question) and users.

G. In the past, I've attempted to evaluate the status of projects and to
clean some dead up. However, it's a lot of manual labor and it meets
with hostility from some of the Gentoo developers.

H. For most things related to determining developer inactivity, we have
little to no automation. It's easy to tell when a developer stops
committing altogether but we have no special help in e.g. determining
that some packages are effectively unmaintained (and that would of
course meet with hostility).


[1]:https://qa-reports.gentoo.org/output/maintainer-needed.html

[gentoo-dev] Packages up for grabs

2017-12-20 Thread Amy Liffey
Hello,
The following packages are up for grabs:

x11-libs/libast
dev-cpp/gmock
sys-boot/cromwell-bin
sys-boot/cromwell
sys-boot/raincoat
dev-vcs/pwclient
dev-vcs/cvsync
app-cdr/extract-xiso
app-cdr/xdvdfs-tools
www-apache/mod_h2
app-crypt/osslsigncode
app-crypt/crackpkcs12
sys-auth/pam_bioapi
sys-auth/bioapi
sys-auth/google-authenticator
sys-auth/tfm-fingerprint
dev-python/pystdf
dev-python/python-evdev
app-portage/portage-utils
sys-apps/i2c-tools
sys-apps/iotools
sys-apps/superiotool
app-editors/curses-hexedit
app-editors/nano
net-libs/libhtp
net-libs/nghttp2
app-misc/evtest
app-misc/pax-utils
app-doc/linkers-and-loaders
app-doc/phrack
app-doc/linux-gazette
app-doc/phrack-all
app-doc/linux-gazette-all
app-text/nfoview
net-misc/tlsdate
net-misc/ssvnc
net-misc/gsutil
net-misc/chrome-remote-desktop
dev-lang/closure-compiler-bin
app-mobilephone/cobex
app-arch/cksfv
app-arch/lcab
app-arch/funzix
sys-fs/libfat
net-wireless/neard
sys-libs/libseccomp
sys-libs/libnih
dev-util/stressapptest
x11-terms/eterm
dev-libs/libsolv
dev-libs/liblzw
dev-libs/zziplib
dev-libs/crossguid

Best regards,
Amy Liffey



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB

2017-12-20 Thread Alexis Ballier
On Wed, 20 Dec 2017 08:34:14 -0500
Rich Freeman  wrote:

> On Wed, Dec 20, 2017 at 4:42 AM, Alexis Ballier 
> wrote:
> > On Tue, 19 Dec 2017 16:00:16 -0500
> > "Aaron W. Swenson"  wrote:
> >  
> >> However, what alternative do we have to throwing the patches up in
> >> a devspace?  
> >
> > mirror://gentoo, aka /space/distfiles-local/
> >  
> 
> That isn't a great option.  This has been discussed previously:
> 
>https://lists.gt.net/gentoo/dev/224673?do=post_view_threaded
> 
>
> https://devmanual.gentoo.org/general-concepts/mirrors/index.html#suitable-download-hosts
> 
> 
> I would point out that a devspace isn't the only alternative -
> anything stable would be reasonable.

So... 6 years later... still no solution ? Kid me not.

I don't see what any other hosting style changes here: next time infra
checks pecker homedirs, everyone will spend time manually removing old
distfiles. For archival of sources, there has always been
gentoo/src/patchsets. For extreme cases, there's distfiles-whitelist.




Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB

2017-12-20 Thread Thomas Deutschmann
Hi,

mysql project is using https://gitweb.gentoo.org/proj/mysql-extras.git/
(i.e. an own repository) to track patches.

What I like about it:

1) We track patches/changes due to using a VCS.

2) We can fetch directly from gitweb.gentoo.org, i.e. no need to adjust
SRC_URI when changing a patch. Just push your patch, create and push a
new tag, update the patch set variable and you are done.

Reminds me of
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/

What I don't like about this:

Cleanup is probably not that easy, the patch tarball size will increase
over the time because tracking which patches are still in use can become
a challenge.

If you use a patch tarball the ebuild will probably don't use EAPI's
default src_prepare function. You will use code like

> eapply "${WORKDIR}"/patch/*.patch
> eapply_user

which makes it not an easy/clean task to just add *one* small/temporary
patch if you need to.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] First (experimental) 17.1 profiles news item for review (v2)

2017-12-20 Thread Michał Górny
Here's an update using Display-If-Profile header instead. The item
applies to users of 13.0 and 17.0 profiles, except for x32 profiles that
have been using the correct layout already.

===
Title: Experimental amd64 17.1 profiles up for testing
Author: Michał Górny 
Posted: 2017-12-xx
Revision: 1
News-Item-Format: 2.0
Display-If-Profile: default/linux/amd64/13.0
Display-If-Profile: default/linux/amd64/13.0/selinux
Display-If-Profile: default/linux/amd64/13.0/desktop
Display-If-Profile: default/linux/amd64/13.0/desktop/gnome
Display-If-Profile: default/linux/amd64/13.0/desktop/gnome/systemd
Display-If-Profile: default/linux/amd64/13.0/desktop/plasma
Display-If-Profile: default/linux/amd64/13.0/desktop/plasma/systemd
Display-If-Profile: default/linux/amd64/13.0/developer
Display-If-Profile: default/linux/amd64/13.0/no-multilib
Display-If-Profile: default/linux/amd64/13.0/systemd
Display-If-Profile: default/linux/amd64/17.0
Display-If-Profile: default/linux/amd64/17.0/selinux
Display-If-Profile: default/linux/amd64/17.0/hardened
Display-If-Profile: default/linux/amd64/17.0/hardened/selinux
Display-If-Profile: default/linux/amd64/17.0/desktop
Display-If-Profile: default/linux/amd64/17.0/desktop/gnome
Display-If-Profile: default/linux/amd64/17.0/desktop/gnome/systemd
Display-If-Profile: default/linux/amd64/17.0/desktop/plasma
Display-If-Profile: default/linux/amd64/17.0/desktop/plasma/systemd
Display-If-Profile: default/linux/amd64/17.0/developer
Display-If-Profile: default/linux/amd64/17.0/no-multilib
Display-If-Profile: default/linux/amd64/17.0/no-multilib/hardened
Display-If-Profile: default/linux/amd64/17.0/no-multilib/hardened/selinux
Display-If-Profile: default/linux/amd64/17.0/systemd

A new set of 17.1 amd64 profiles has been added to the Gentoo
repository. Those profiles switch to a more standard 'no SYMLINK_LIB'
multilib layout, and require explicit migration as described below. They
are considered experimental at the moment, and have a fair risk
of breaking your system. We would therefore like to ask our users to
test them on their non-production ~amd64 systems.

In those profiles, the lib->lib64 compatibility symlink is removed.
The 'lib' directory becomes a separate directory, that is used
for cross-arch and native non-library packages (gcc, clang) and 32-bit
libraries on the multilib profile (for better compatibility with
prebuilt x86 packages).

Migration from both 13.0 and 17.0 profiles is supported. In case
of the former, please read the news item for 17.0 upgrade first
and enable gcc 6.4.0 or newer first as explained there.

The migration is performed using app-portage/unsymlink-lib tool.
The following steps can be used to upgrade your system:

1. Sync and upgrade your system to the newest package versions
   to reduce the risk of issues.

2. Install the tool, e.g. via 'emerge -1v app-portage/unsymlink-lib'

3. Run 'unsymlink-lib --analyze' and check the output for obvious
   mistakes. If you need to perform any changes to the system, remember
   to run 'unsymlink-lib --analyze' again afterwards.

[past this point do not call emerge or modify /usr manually]

4. This is a very good time to make a backup.

5. Run 'unsymlink-lib --migrate'. You can add '--pretend' first to see
   what is going to happen.

6. Reboot your system and see if it still boots. Check if important
   programs work. In particular, check if e.g. 'emerge --info' works
   (but do not install anything). If you hit any serious problems,
   you can use 'unsymlink-lib --rollback' to revert the changes
   and return to step 3.

7. Run 'unsymlink-lib --finish'. You can add '--pretend' first to see
   what is going to happen but note that you're going to see a very long
   list of files to remove.

8. Switch the profile, e.g.:

 eselect profile set --force default/linux/amd64/17.1/desktop

[at this point you can start using emerge again]

9. Rebuild sys-devel/gcc. If you are switching from 13.0 profiles,
   rebuild sys-devel/binutils and sys-libs/glibc afterwards.

10. If you are using a multilib profile, rebuild all 32-bit packages.
This can be done using:

  emerge -1v /lib32 /usr/lib32

Alternatively, if you are switching from one of the 13.0 profiles
you can rebuild all packages as detailed in the 17.0 news item.

11. Once the last 32-bit package is rebuilt, your package manager
should remove the orphaned /lib32 and /usr/lib32 symlinks. If that
does not happen, remove them manually.

For known issues, please see bug #506276 [1]. If you have any problems
with the new profiles or the migration procedure, please report a bug
and make it block the tracker.

[1]:https://bugs.gentoo.org/506276

-- 
Best regards,
Michał Górny




Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB

2017-12-20 Thread Rich Freeman
On Wed, Dec 20, 2017 at 4:42 AM, Alexis Ballier  wrote:
> On Tue, 19 Dec 2017 16:00:16 -0500
> "Aaron W. Swenson"  wrote:
>
>> However, what alternative do we have to throwing the patches up in a
>> devspace?
>
> mirror://gentoo, aka /space/distfiles-local/
>

That isn't a great option.  This has been discussed previously:

   https://lists.gt.net/gentoo/dev/224673?do=post_view_threaded

   
https://devmanual.gentoo.org/general-concepts/mirrors/index.html#suitable-download-hosts


I would point out that a devspace isn't the only alternative -
anything stable would be reasonable.

Also, to avoid an additional reply I'll just comment on the
reservations about hosting stuff on github.  While a Gentoo archive
would certainly be preferable, keep in mind that when we're talking
about hosting a src_uri the only function github is actually
performing is to act as a webserver.  There are a lot of reasonable
objections to depending on github since it is closed-source, but most
of those objections pertain more to the issue/pull-request tracking
features of github.  If all you're using it to do is to host URLs or
repositories then I suspect that all the associated software is
open-source anyway, most likely (though I do not believe github
discloses what they actually use).  Most of us probably wouldn't
notice if a random src_uri in our repository is pointing at an IIS
server, for example.  I'd just be careful about knee-jerk reactions.
That aside, there are a lot of good reasons to host our own archives,
with the unreliability of ANY external host being one of them.

-- 
Rich



Re: [gentoo-dev] [RFC] First (experimental) 17.1 profiles news item for review

2017-12-20 Thread Michał Górny
W dniu śro, 20.12.2017 o godzinie 08∶28 -0500, użytkownik Brian Evans
napisał:
> On 12/18/2017 1:51 PM, Michał Górny wrote:
> > Hello, everyone.
> > 
> > The first news item I'd like to submit for 17.1 profiles follows.
> > The item is aimed at ~amd64 users who'd like to test the new profiles.
> > When they become stable, a separate news item for all our users will be
> > published.
> > 
> 
> I'm not sure if it is valid to put in the news item or modify the tool,
> but users of PostgreSQL will need to either 'mv /usr/lib/postgresql
> /usr/lib64' or, probably better, re-execute 'eselect postgresql'. The
> symlink will not be moved by the unsymlink-lib tool and build failures
> are likely to occur if libraries are searched for in this method
> 

Not sure if you got my message on IRC but the proper fix for this is for
eselect package to own the symlink. Orphan files are always a major PITA
for everyone.

-- 
Best regards,
Michał Górny




Re: [gentoo-dev] [RFC] First (experimental) 17.1 profiles news item for review

2017-12-20 Thread Brian Evans
On 12/18/2017 1:51 PM, Michał Górny wrote:
> Hello, everyone.
> 
> The first news item I'd like to submit for 17.1 profiles follows.
> The item is aimed at ~amd64 users who'd like to test the new profiles.
> When they become stable, a separate news item for all our users will be
> published.
> 

I'm not sure if it is valid to put in the news item or modify the tool,
but users of PostgreSQL will need to either 'mv /usr/lib/postgresql
/usr/lib64' or, probably better, re-execute 'eselect postgresql'. The
symlink will not be moved by the unsymlink-lib tool and build failures
are likely to occur if libraries are searched for in this method

Brian



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB

2017-12-20 Thread Alexis Ballier
On Tue, 19 Dec 2017 16:00:16 -0500
"Aaron W. Swenson"  wrote:

> On 2017-12-17 14:21, Michał Górny wrote:
> >   Total size of 'files' subdirectory of a package should not be
> > larger than 32 KiB. If the package needs more auxiliary files, they
> > should be put into SRC_URI e.g. via tarballs.  
> 
> I don’t have any strong opinions about this either way.

note that the announcement fails to mention why this has been a
self-imposed rule on some packages for a long time: tools like quilt or
git are made to track large patchsets. Once scripting is in place, it is
much more convenient to generate patch tarballs from those tools; epatch
supporting numbered patchsets and applying them all is great for that
too.

> However, what alternative do we have to throwing the patches up in a
> devspace?

mirror://gentoo, aka /space/distfiles-local/

> Having previously done so with dev-db/postgresql, it was annoying
> having to fix the SRC_URI because I wasn’t the one who did a slot
> bump.

or even that way: you can add several URIs for the same file, e.g.:
SRC_URI="pecker/~deva/patches.tar.bz2 pecker/~devb/patches.tar.bz2"

mirrors will pick the one available and usually users wont be impacted
by a 404 delay if devb hosts the patches; but I would still recommend
distfiles-local, esp. since it autocleans when the file is not used
anymore.



Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

2017-12-20 Thread Nils Freydank
Am Dienstag, 5. Dezember 2017, 23:41:45 CET schrieb kuzetsa:
> On 12/05/2017 05:18 PM, Nils Freydank wrote:
> > 5. Reasons for warnings and bans
> > 
> 
> --snip--
> 
> > c) spamming, i.e. flooding discussions with lots of messages in a row
> > d) constant postings off topic, i.e. disrupting discussions with unrelated
> > questions
> > 
> > (constant means more than two times in a row)
> 
> Point #c versus #d
> 
> #c - there can (and often are) good faith reasons for
> multiple postings "in a row", such as when responding
> to multiple threads, and/or to multiple posters within
> the same thread. Even just people who are awake (and
> would respond) at a time when other participants in the
> list would be sleeping could complicate this rule.
Valid point.

> #d - definition for constant seems unnecessary. For an
> alternative, maybe refine the definition to either
> use a 72 hour window or similar, or even just a basic
> expectation for discussion to be germane (on-topic)
> with refusal to stay on-topic (when warned) being the
> measure. Perhaps three strikes (per day?) are when
> the enforcement could start. parliament / congress
> and other formal assemblies have models for this.
Sounds good to me. As spamming is *always* off topic
this should even catch point c).

Could you write a short paragraph for this?

-- 
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

2017-12-20 Thread Nils Freydank
Am Freitag, 15. Dezember 2017, 17:59:59 CET schrieb Anton Molyboha:
> On Tue, Dec 5, 2017 at 5:18 PM, Nils Freydank  wrote:
> > [snip]
> > 
> > 
> > 
> > 3. Moderation
> > -
> > The moderation team has to consist of at least two developers. The
> > moderators
> > have to do join the moderation team voluntarily.
> > 
> > "have to do join" should probably be "have to join"
> > 
> > 
> > [snip]
Sure, thanks! I don’t know if this is really necessary anyway. Maybe I read 
too many company related docs :-D

-- 
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

2017-12-20 Thread Nils Freydank
Am Freitag, 15. Dezember 2017, 23:37:48 CET schrieb R0b0t1:
> Hello,
> 
> On Tue, Dec 5, 2017 at 4:18 PM, Nils Freydank  wrote:
> > Hello everyone,
> > 
> > with regards to the current mailing list (ML) split discussion, and one
> > specific message deep down there by mgorny asked for someone providing
> > moderator rules, I would like to propose the following ruleset for
> > gentoo-dev
> > 
> > Right now the situation escalated in a way that forces to actually do
> > something and I hope we can recreate an atmosphere where technical
> > improvements can happen.
> 
> To me, at least, this isn't self-evident. What specific actions make
> you think an immediate response is necessary?
> 
> self-evident
>   adj. Evident to one’s self and to nobody else.
> 
> Cheers,
>  R0b0t1
There is a specific RFC about splitting the mailing list because of a 
problematic style of conversation.

Even if that split won’t happen -- I don’t know if mgorny has the "right" or 
support to do that and I personally want to stay out of these discussions -- I 
really *do* think that a moderation of a frequented mailing list like gentoo-
dev is a generally good idea. Therefore we need properly documented rules 
(beside moderators).

To answer you question: I think the RFC introduces either a "time pressure" or
should be seen as sign that this list needs an improvement.

Regards,
Nils

--
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB

2017-12-20 Thread Kent Fredric
On Tue, 19 Dec 2017 20:11:04 -0600
R0b0t1  wrote:

> I forgot most files were mirrored. So the infrastructure that is the
> answer to my question is already in place. Consequently, I don't think
> there's any reason to argue against this, unless it ultimately ends up
> being a ton of work to package small files (which I can't comment on).

Biggest downsides I see of pushing patches to distfiles mirrors is it
greatly desynchronizes the state of tree, similar to how you'd get
desynchronization if parts of gentoo.git were sharded into different
repositories.

Comprehending changes made downstream require additional steps and
additional tooling.

Correlating patch changes against ebuild changes is even more effort.

The only upside is it makes it slightly harder to abuse patch-reuse and
have unintentional retroactive patching to existing ebuilds without -r
bumps.

But ... that's a double edged sword if that sort of thing is
occasionally useful and sane.

I don't know what the solution is here, but I don't think either
strategies of "discourage it" or "encourage it" are the ultimate way
forward.

Some other strategy must exist. But for now, sensible limits are an
acceptable compromise.


pgpNcakDxjHJ5.pgp
Description: OpenPGP digital signature