Re: [gentoo-dev] [RFC] new eselect module: compiler

[M. J. Everitt]

On 10/08/16 06:08, Michał Górny wrote:
> On Wed, 10 Aug 2016 01:52:29 +0100
> "M. J. Everitt" <m.j.ever...@iee.org> wrote:
>
>> On 10/08/16 01:39, Lei Zhang wrote:
>>> 2016-08-09 13:58 GMT+08:00 Fabian Groffen <grob...@gentoo.org>:
>>>> As a question to Lei, I'm wondering why you chose eselect compiler, and
>>>> not gcc-config to manage the links.  In a way, gcc-config is tailored
>>>> towards gcc, but it does a lot of things also for the environment.  With
>>>> clang, from my experience, you just want it as drop-in replacement for
>>>> gcc as it doesn't give you too much issues (on Darwin at least).
>>> In its current form, gcc-config specializes in handling different
>>> versions of gcc. If we extend it to cover other compilers (and rename
>>> it to cc-config as James suggested), should it handle different
>>> versions of clang? What about different versions of icc?
>>>
>>> I'm just afraid gcc-config would become too complex that way, so I
>>> prefer a simpler approach: let eselect-compiler be version-agnostic.
>>> Then we can have clang-config to handle the versioning of clang,
>>> icc-config to handle icc, etc.
>>>
>>>
>>> Lei
>>>
>> Extending the ideas presented in this thread .. you could introduce
>> cc-config, and which utility script it runs would then be governed by
>> eselect compiler .. eg. gcc would have gcc-config, clang would run
>> clang-config ..
> .. to switch between the one version of clang that can be installed?
>
Tis early days Mr Gorny .. who knows what the future holds .. and Gentoo
is all about choice, right?!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] new eselect module: compiler

[M. J. Everitt]

On 10/08/16 01:39, Lei Zhang wrote:
> 2016-08-09 13:58 GMT+08:00 Fabian Groffen :
>> As a question to Lei, I'm wondering why you chose eselect compiler, and
>> not gcc-config to manage the links.  In a way, gcc-config is tailored
>> towards gcc, but it does a lot of things also for the environment.  With
>> clang, from my experience, you just want it as drop-in replacement for
>> gcc as it doesn't give you too much issues (on Darwin at least).
> In its current form, gcc-config specializes in handling different
> versions of gcc. If we extend it to cover other compilers (and rename
> it to cc-config as James suggested), should it handle different
> versions of clang? What about different versions of icc?
>
> I'm just afraid gcc-config would become too complex that way, so I
> prefer a simpler approach: let eselect-compiler be version-agnostic.
> Then we can have clang-config to handle the versioning of clang,
> icc-config to handle icc, etc.
>
>
> Lei
>
Extending the ideas presented in this thread .. you could introduce
cc-config, and which utility script it runs would then be governed by
eselect compiler .. eg. gcc would have gcc-config, clang would run
clang-config ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Package up for grab

[M. J. Everitt]

On 02/08/16 23:43, Matthew Thode wrote:
> On 08/02/2016 04:15 PM, Amy Winston wrote:
>> net-im/skype
>>
>> Anyone interested?
>>
>>
> I feel like this is a trick question :P
>
+2



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] OpenAFS on Gentoo Hardened

[M. J. Everitt]

On 18/06/16 00:08, Deven Lahoti wrote:
> I wrote a patch to make OpenAFS work with grsecurity kernels. I'm
> working on getting it submitted upstream, but for now it would be nice
> to have it in portage.
>
> http://web.mit.edu/deywos/www/openafs-grsec.patch
>
> deven
At the risk of stating the obvious, have you filed a bug at
bugs.gentoo.org, so that the right projects can be notified and progress
easily tracked by all concerned?
Cheers,
MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Killing VERIFIED state, possibly introducing STABILIZED

[M. J. Everitt]

On 16/06/16 14:19, James Le Cuirot wrote:
> On Thu, 16 Jun 2016 15:14:44 +0200
> Kristian Fiskerstrand  wrote:
>
>>> What I'd like to introduce instead is a new STABILIZED state. It
>>> would -- like VERIFIED now -- be only available for bugs already
>>> RESOLVED, and it could be used to signify that the fix has made it
>>> into stable.
>>>
>>> While this wouldn't be really obligatory, it would be meaningful for
>>> trackers that need to ensure that fixes in packages have made it to
>>> stable -- like the functions.sh use tracker.
>> The description of InVCS keyword in bugzilla is:
>> InVCSFix has been added to a VCS(either CVS, SVN, Git, ...)
>> repository. Will be closed when fixes are applied to a stable level
>> package.
>>
>> A bug isn't resolved until it is fixed in a stable package (for
>> packages ever in stable to begin with), but InVCS keyword can be used
>> by developers to filter out the bugs for issues to work with. I
>> oppose a change to that behavior, although I would like to see it
>> being used more consistently as it seems quite a few developers are
>> neglecting the stable tree.
> I currently set InVCS for pending-stable fixes in conjunction with the
> IN_PROGRESS state. I would like to keep InVCS at least.
>
Possibly a 'COMMITTED' tag would fit this slightly better? There is room
for some QA 'VERIFIED' tag too, but don't know whether this is
absolutely necessary for Gentoo .. thoughts welcomed, though.

I prefer this Lifecycle diagram to that published in the latest docs:
https://www.bugzilla.org/docs/3.6/en/html/lifecycle.html .



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[M. J. Everitt]

On 16/06/16 14:22, Andrew Savchenko wrote:
> On Thu, 16 Jun 2016 14:26:47 +0200 Michał Górny wrote:
>> Hello, everyone.
>>
>> Here's my second RFC wrt bugs.gentoo.org redesign.
>>
>> Right now we have separate UNCONFIRMED and CONFIRMED states for bugs.
>> However, we use the two scarcely. I believe it would be beneficial to
>> replace the two with a single NEW state.
>>
>> Rationale:
>>
>> 1. Most of developers don't care about the two states, and which one
>> bugs are in.
>>
>> 2. All bugs need to be handled the same, whether they were marked as
>> confirmed or not.
>>
>> 3. We stage bugs through bug-wranglers@ which kinda has a similar
>> purpose to the UNCONFIRMED state in other Bugzillas.
>>
>> 4. Some people who actually care about the two states change them,
>> causing unnecessary bugspam.
>>
>> 5. Some users who think that the state matters get furious about bugs
>> staying in UNCONFIRMED for long.
>>
>> Your thoughts?
>  
> CONFIRMED state is useful, it means that dev or powerful user
> confirmed this bug and gives it more value. I'd like to keep it.
>
> Best regards,
> Andrew Savchenko
I think CONFIRMED is useful too, particularly if it shows that the
problem is easily reproducible (ie. either a wrangler/dev/proxy has
actually run the sequence of command as per report, and has replicated
the issue).

ASSIGNED should be the 'default' phase for a bug, after is has been
wrangled. See https://www.bugzilla.org/docs/3.6/en/html/lifecycle.html
for some useful (but not all necessary) states.

I suggest an approximate workflow of NEW->ASSIGNED->CONFIRMED->IN
PROGRESS->RESOLVED/CLOSED/etc.

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization

[M. J. Everitt]

On 16/06/16 13:04, Michał Górny wrote:
> On Wed, 15 Jun 2016 21:11:30 +0200
> Michał Górny  wrote:
>
>> Right now we have the following components:
>>
>> - Applications,
>> - baselayout,
>> - Core system,
>> - Development,
>> - Eclasses and Profiles,
>> - Games,
>> - GCC Porting,
>> - GNOME,
>> - Hardened,
>> - Java,
>> - KDE,
>> - Keywording & Stabilization,
>> - Library,
>> - New packages ('New ebuilds' previously),
>> - Printing,
>> - SELinux,
>> - Server,
>> - Unspecified.
> Revision two:
>
> - Current packages [bug-wranglers@],
> - Eclasses [bug-wranglers@],
> - Hardened [hardened@],
> - New packages [bug-wranglers@],
> - Overlays [overlays@],
> - Profiles [bug-wranglers@],
> - SELinux [selinux@].
>
> Major changes:
>
> 1. collapsed all category-like components into a single 'Current
> packages' that is the default component for pretty much every bug
> related to 'standard' configurations of Gentoo Linux -- making it easy
> to choose the correct one and ensuring everything goes through
> bug-wranglers;
>
> 2. split 'eclasses & profiles' into two separate categories -- mainly
> intended for developer use;
>
> 3. left 'Hardened' and 'SELinux' (also the whole separate Gentoo/Alt
> product) as the non-standard system configurations that desire staging
> the bugs through respective teams,
>
> 4. left 'New packages' as-is, as category for requesting addition
> of packages not yet in Gentoo,
>
> 5. added 'Overlays' component for bugs filed against packages
> in third-party repositories (right now some of them got filed pretty
> randomly, and having them in Infra->Overlays is kinda wrong),
>
> 6. removed 'Keywording & stabilization'. As pointed out, those can be
> handled via keywords and we already do stabilizations in other places
> (e.g. security bugs).
>
> Your thoughts about this one?
>
Looks good. +1 here.



signature.asc
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[M. J. Everitt]

On 15/06/16 07:42, Andrew Savchenko wrote:
> On Wed, 15 Jun 2016 05:15:03 +0200 Michał Górny wrote:
>> On Wed, 15 Jun 2016 00:12:40 +0200
>> "Andreas K. Huettel"  wrote:
>>
>>> Am Dienstag, 14. Juni 2016, 02:32:41 schrieb Peter Stuge:
>>>
 I would personally be super happy to have my overlay hosted at Gentoo -
   
>>> So what precisely is keeping you from that?
>>>
>>> https://wiki.gentoo.org/wiki/Project:Overlays/Overlays_guide
>> Don't encourage people to create more work for me when we have GitHub!
> Github is propietary and I don't see why someone have a right to
> enforce its usage on people.
>
> If someone want to use github — go ahead, but if not — in no way
> you can force people to do that (e.g. by refusing to create on
> overlay, or review patch on bugzilla, or whatever).
>
> Best regards,
> Andrew Savchenko
+1



signature.asc
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[M. J. Everitt]

On 13/06/16 09:04, Alexander Berntsen wrote:
> On 11/06/16 09:00, Michał Górny wrote:
> > If you are not going to maintain your contribution, we can't
> > guarantee it will be accepted. I'm certainly not interested in
> > having to worry about 20 more maintainer-needed packages next month
> > because someone contributed an ebuild that seemed good enough.
> This is a good point. Contributions that no devs are willing to
> maintain would not make it into the curated and reviewed repositories
> I am referring to.
>
> As an aside, perhaps we should start featuring third-party overlays
> more prominently, as this is where these ebuilds belong.

Excuse me .. and this thread emerged from deprecating the EXACT thing
you are suggesting!?



signature.asc
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[M. J. Everitt]

On 13/06/16 08:50, Alexander Berntsen wrote:
>
> > I still think you're underestimating the need for centralization.
> > What you call a "core/base" package is probably going to end up
> > being anything listed in a dependency.  That is a LOT of packages,
> > actually - we're not just talking about libc and zlib.
> It's not a lot compared to how many we have today.

I really think someone needs to do a bit of portageq and see what the
Tree *actually* contains 

Likewise .. a trek through bugzilla would also be enlightening for those
not familiar ...

Once you've seen those two .. perhaps you'd be a little more qualified
to make generalised statements about the state of Gentoo.

Just sayin' ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs

[M. J. Everitt]

On 12/06/16 18:57, Mike Frysinger wrote:
> please avoid html e-mails
> -mike
And PGP/MIME is your friend :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] dev-util/nsis: Maintainer request

[M. J. Everitt]

I'll see what I can do .. possibly not today ..
Cheers,
Michael.

On 12/06/16 12:50, Alon Bar-Lev wrote:
> Can you please check it out?
> I had no time nor setup.
>
> On 12 June 2016 at 14:49, M. J. Everitt <m.j.ever...@iee.org> wrote:
>> Cheers Alon,
>>
>> Michael.
>> On 12/06/16 12:43, Alon Bar-Lev wrote:
>>> Hi,
>>> I've revbumped this package.
>>> Regards,
>>> Alon
>>>
>>> On 6 June 2016 at 03:23, M. J. Everitt <m.j.ever...@iee.org> wrote:
>>>> On 05/06/16 22:55, Kristian Fiskerstrand wrote:
>>>>> dev-util/nsis curretly has no maintainer. It has a [critical security
>>>>> bug filed against it]. Does anyone want to pick it up? if not we'll
>>>>> start a last rite process for it.
>>>>>
>>>>> [critical security bug filed against it]
>>>>> https://bugs.gentoo.org/show_bug.cgi?id=568398
>>>> Per conversation in #g-p-m I'll take this on via proxy if nobody else
>>>> volunteers in the next 7 days (w/e 12th June) to start with, as I'm
>>>> pretty sure a colleague is using it on a project, and we could do
>>>> without losing it from the tree .. !
>>>>
>>>> Quick glance at the project page, and bug suggests revbump, stabilise
>>>> and drop old version might cure the existing issue, but will investigate
>>>> further.
>>>> Cheers,
>>>> Michael.
>>>>
>>




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] dev-util/nsis: Maintainer request

[M. J. Everitt]

Cheers Alon,

Michael.
On 12/06/16 12:43, Alon Bar-Lev wrote:
> Hi,
> I've revbumped this package.
> Regards,
> Alon
>
> On 6 June 2016 at 03:23, M. J. Everitt <m.j.ever...@iee.org> wrote:
>> On 05/06/16 22:55, Kristian Fiskerstrand wrote:
>>> dev-util/nsis curretly has no maintainer. It has a [critical security
>>> bug filed against it]. Does anyone want to pick it up? if not we'll
>>> start a last rite process for it.
>>>
>>> [critical security bug filed against it]
>>> https://bugs.gentoo.org/show_bug.cgi?id=568398
>> Per conversation in #g-p-m I'll take this on via proxy if nobody else
>> volunteers in the next 7 days (w/e 12th June) to start with, as I'm
>> pretty sure a colleague is using it on a project, and we could do
>> without losing it from the tree .. !
>>
>> Quick glance at the project page, and bug suggests revbump, stabilise
>> and drop old version might cure the existing issue, but will investigate
>> further.
>> Cheers,
>> Michael.
>>




signature.asc
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[M. J. Everitt]

On 12/06/16 04:53, james wrote:
>
> So I read this bug, but it did not illuminate an active archive, but the
> requests and subsequent problems encountered, or did i miss it? It
> looks  like the kinks are being worked out. PM having a ML is a great
> idea.
>
>
> Interesting. I found the ML @ game::
>
> http://thread.gmane.org/gmane.linux.gentoo.proxy-maint/
>
> I post a problem there but it has not shown up yet. I use
> gmane extensively, often to just passively follow a list
> Posting usually causes gmane to send me a notice.
>
> I justd subscribed to the mailing list directly, then perhaps gmane
> will grant me posting wrights access?
>
>
> I only see (2) posts in the ML, so is it active?
>
>
> James
>
>
>
If you are struggling to find/subscribe to the gentoo Mailing-lists, and
the Information/FAQ page appears to be missing information, please file
Bugs at bugs.gentoo.org, so that these matters get picked up, tracked
and addressed.

james, you may find this page:
https://www.gentoo.org/get-involved/mailing-lists/instructions.html helpful.

 Thanks.



signature.asc
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[M. J. Everitt]

On 10/06/16 17:16, james wrote:
> 
> And this effort needs a documentation collection to support users,
> post installation to their target (ideal stage-4?) collection of
> packages; many of which they maintain themselves even if a strong-user
> or dev
> helps them assimilate those final packages. Then they can use stage-4
> snapshots for periodic backups on complete systems. or for quick
> installs of new systems. (that would super-charge my cluster dev work)!
>
>
> It just seems to me that we have all of that now, but it is::
> 1) not organized
> 2) needs documentation so folks do not have to use irc to ask the same
> questions over and over and over again (gentoo wiki is maturing in
> this direction too, imho.
> 3) needs (desires) gentoo managed repos, not github
>
> For now, we can use github for users. A glep or 2 can solved 1 and
> (2), well I was politely turned down, so suggestions on documentation
> to achieve this? Data-mining of emails and irc could easily provide
> the first-draft of the docs for need (2).
>
>
>
> James
>
(2) any user can edit wiki pages not governed by Projects. Even Project
pages I'm sure could be updated by means of patches submitted to the
appropriate team, with some basic follow-up to ensure action.

(3) until some enthusiastic sponsors come forward to host/maintain these
systems, I don't think its fair to overburden the already stretched
Infra guys (no offence, guys! you're doin a great job).

MJE



signature.asc
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[M. J. Everitt]

On 10/06/16 08:33, Alexander Berntsen wrote:
> On 09/06/16 12:28, Igor Savlook wrote:
> > Ok how coordinate? Example: I install packageA in exherbo from
> > repository1 and packageA denend on packageB on repository2. Now
> > packageB removed from repository2 and exherbo crash on install
> > package or on rebuild world (epic fail). Exherbo user need wait
> > when return packageB or create new repository for this package.
> This (as I understand what you're writing) doesn't happen. That's kind
> of the point of curated and reviewed repositories.
So forgive me for being blind .. but we were talking about going -away-
from central, curated repositories, and now we've come full circle to
the situation we have now with overlays, mostly controlled in some way
by gentoo .. so, do tell me .. what's the difference?!



signature.asc
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[M. J. Everitt]

On 09/06/16 10:58, Alexander Berntsen wrote:
> On 09/06/16 11:55, Daniel Campbell wrote:
> > According to Enigmail, it expired April 19th.
> I suggest you refresh your keys. My signing subkey was signed April
> 20th and expires in 2017.
>
Indeed, cache error, thanks. All square now.

MJE




signature.asc
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[M. J. Everitt]

On 09/06/16 10:48, Alexander Berntsen wrote:
> On 09/06/16 11:45, M. J. Everitt wrote:
> > Btw, your key is showing up as expired, Alex.
> It doesn't expire until next year.
>
>

I'll blame it on Enigmail, but this is the information I'm seeing:

"EXPIRED KEY Good signature from "Alexander Berntsen <berna...@gentoo.org>
Key ID: 0x705073B5 / Signed on: 09/06/16 10:48"


signature.asc
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[M. J. Everitt]

On 09/06/16 10:37, Alexander Berntsen wrote:
> On 08/06/16 16:39, Zac Medico wrote:
> > The first obstacle that comes to my mind is how to discover the
> > packages. There needs to be a central index of repositories which
> > includes searchable metadata for all of the packages provided by
> > those repositories. It will be something like gpo.zugaina.org, with
> > the ability to download the whole database, and update the local
> > copy incrementally.
> This falls under the tooling side of things, and I agree that it is
> very useful.
>
We should be thinking about bringing the gpo.zugaina.org under the
Gentoo umbrella .. it -is- a *very* useful resource, and should belong
with the main sites, perhaps with a refactorage of the 'overlays.g.o' site?!

Btw, your key is showing up as expired, Alex.





signature.asc
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[M. J. Everitt]

On 09/06/16 00:08, Andreas K. Huettel wrote:
>
> > This could lead to a future where the Gentoo tree is largely
> > superseded. Every user would just have their own repository, where
> > they could pick and choose packages from other users. The Gentoo tree
> > would just focus on a high-quality repository of the basic/core things
> > that everybody needs. Gentoo devs would spend most of their time
> > maintaining curated small and useful repositories.
>
> [...]
>
> > The final step is the most difficult (but then again we might never
> > get so far). It is two-fold. First we make the core/base repository.
> > Then we identify important subsets that can be logically separated
> > into repositories, and do this.
>
>
> Sigh. Every 2 years somebody else comes up with the same silly idea.
>
> 1) Who defines what everybody needs?
> 2) How do you enforce security and/or qa requirements on the rest?
> 3) Will you allow non-core dependencies? What guarantees are made there?
> 4) How do you make sure that different split-out repos actually work
> together?
> 5) "logically separated subsets" means either "loss of functionality" or
> "impossible to do"
>
> Independent of how many magic tools you whip up this will be a
> significant
> step down in functionality and quality, and a big step towards a big
> unmanageable steaming pile of cr...
>
>

+2


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] The future of the Sunrise project

[M. J. Everitt]

On 08/06/16 04:13, Matthew Marchese wrote:
> On 06/07/2016 02:29 AM, Anthony G. Basile wrote:
>
>> Its time to retire the project.  Put out a last call for anyone to adopt
>> it.  If not, then freeze commits but leave the repo open as an archive.
>> Anyone who wants to scavenge ebuilds from it can do so.
> I agree. We should be a better job at trimming the fat in various ways.
> I just looked at this project recently and was scared.
> -maffy
>
It's fair to say, it is pretty scary, maff ... :D



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Default DOCS for einstalldocs and HACKING file

[M. J. Everitt]

On 07/06/16 23:50, NP-Hardass wrote:
> From what I've seen, HACKING is a fairly common doc in FOSS projects.
> It doesn't seem to have been included in the default DOCS for
> einstalldocs in EAPI6.  While going through the MATE packages, I noticed
> that we have quite a few packages that include HACKING in DOCS, so I
> cannot delete the DOCS array and take advantage of the automagic doc
> detection feature of einstalldocs.
>
> Does anyone know why we omitted this file from the default DOCS?  A
> quick grep of the main repo shows ~370 ebuilds with HACKING listed.   Is
> this file no longer considered worthy of being included by default in
> our installed docs?  If so, looking for advice on whether it is worth
> keeping or dropping that file from my packages?
>
I made the suggestion a while back in IRC that it would be nice if there
was a way to append to the DOCS array in an ebuild, rather than have to
override it, and remember the standard list every time, or just lose the
extra file(s). Unfortunately I was laughed out of the channel. So,
whilst it would probably be something for another EAPI change .. what do
readers think of the idea of an EXTRA_DOCS variable or similar method
for doing this, for exactly this reason/purpose??

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] The future of the Sunrise project

[M. J. Everitt]

On 07/06/16 16:37, Michał Górny wrote:
> I'm against keeping it in repos.xml for more than a month, considering
> the current (huge) state of breakage it is in. Other repositories with
> similar breakage were already removed.
>
In which case, we should get a notice out post-haste ...

My concern is for those people using sunrise packages (in whatever
broken state) who might suddenly discover they have completly lost
access to the overlay 'overnight'. Whilst I'm not expecting the
server/repo suddenly to disappear .. there should be a planned migration
path for any users lingering on packages in this overlay to get the
package into maintainership of some form if at all possible. As such it
remains a semi-official Gentoo repository ..

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] The future of the Sunrise project

[M. J. Everitt]

On 07/06/16 16:44, james wrote:
> On 06/07/2016 09:25 AM, Michał Górny wrote:
>> Wouldn't removing it from repositories.xml have pretty much the same
>> effect?
>>
>> Also, i think we should make the unreviewed repo public then, so
>> people can get the newest ebuilds.
>
> Perhaps a deprecation period of a year, with a gentoo wiki page that
> lists the packages found @sunrise, is a good idea?
>
>
A year is a very short time in software terms .. maybe 5 years ... !!
But freezing it, with the intention of removing from repos.xml in 5
years time seems reasonable to me.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] The future of the Sunrise project

[M. J. Everitt]

On 07/06/16 10:29, Anthony G. Basile wrote:
> Its time to retire the project.  Put out a last call for anyone to adopt
> it.  If not, then freeze commits but leave the repo open as an archive.
> Anyone who wants to scavenge ebuilds from it can do so.
>
>
+1 - This sounds like a fairly sensible solution.

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] dev-util/nsis: Maintainer request

[M. J. Everitt]

On 05/06/16 22:55, Kristian Fiskerstrand wrote:
> dev-util/nsis curretly has no maintainer. It has a [critical security
> bug filed against it]. Does anyone want to pick it up? if not we'll
> start a last rite process for it.
>
> [critical security bug filed against it]
> https://bugs.gentoo.org/show_bug.cgi?id=568398
Per conversation in #g-p-m I'll take this on via proxy if nobody else
volunteers in the next 7 days (w/e 12th June) to start with, as I'm
pretty sure a colleague is using it on a project, and we could do
without losing it from the tree .. !

Quick glance at the project page, and bug suggests revbump, stabilise
and drop old version might cure the existing issue, but will investigate
further.
Cheers,
Michael.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [gentoo-dev-announce] Last rites: dev-util/{...}

[M. J. Everitt]

On 05/06/16 20:04, Robin H. Johnson wrote:
> On Sun, Jun 05, 2016 at 01:47:48PM +0200, Patrice Clement wrote:
>> dev-util/cdecl
>> dev-util/dwarves
>> dev-util/intel2gas
>> dev-util/lsuio
>> dev-util/mock
>> dev-util/par
>> dev-util/tinlink
>> dev-util/usb-robot
> I've used the above subset of these, so I'll review the upstreams to see
> if they just moved or what.
>
Did Patrice join the Treecleaners project whilst we weren't looking ...
?! ;]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Repo mirror & CI project news: 'stable' gentoo branch, new repo stats, faster CI

[M. J. Everitt]

On 05/06/16 18:09, rindeal wrote:
> On 5 June 2016 at 18:53, M. J. Everitt <m.j.ever...@iee.org> wrote:
>> On 05/06/16 17:49, rindeal wrote:
>>> On 5 June 2016 at 18:40, Kent Fredric <kentfred...@gmail.com> wrote:
>>>> On 6 June 2016 at 04:31, rindeal <dev.rind...@gmail.com> wrote:
>>>>> Isn't no commit approach better than having broken commit + revert
>>>>> commit?
>>>> Huh?
>>>>
>>>> Its doing "replicate to github on pass using a merge commit".
>>> I'd like to see the master branch free of commits which do not pass
>>> CI, instead of having broken commits and holding master back until
>>> revert commits are introduced.
>>>
>> Which is the whole idea  'stable' becomes fully CI parsed good
>> 'green light' whereas master is a 'holding bay' until the CI script can
>> do its stuff ..
>>
> It is not, unless CI filters the broken commits in some miraculous
> way. With the current approach, both stable and master branch will
> contain the pollution of broken commits + their fixes, instead of
> having good commits only.
To eliminate errors completely, you also remove any form of progression.
As the old proverb goes "you can't make an omelette without breaking
eggs"

This way, at least the bad commits /get/ fixed *before* they are pushed
out to unsuspecting users ... ok so its not perfect, but this _is_ the
real world here ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New global USE flag: webp

[M. J. Everitt]

On 04/06/16 21:17, Michael Orlitzky wrote:
> We've still got 5.x stable, but that's because there's a security bug
> for PHP every 20 days and it takes 30 days to stabilize an ebuild.
>
> Here's a status report:
>
>   * We've got the "eselect php..." stuff sorted out already so you can
> easily switch between 5.6 and 7.0 on-the-fly.
>
>   * Most extensions have a version that works with php-7.0.
>
>   * Some PECL extensions only work with certain versions of PHP, yet are
> not slotted. This will probably cause some headaches, but it's
> pretty late in the game and I don't have the time to overhaul the
> way we do extensions at the last minute. We may have to tell people
> that they can't switch between php-5 and php-7 with certain
> extensions (there are around 8 that cause problems).
>
>   * The PHP upgrade itself is pretty harmless. Check your logs for
> deprecation warnings. If there aren't any, you can probably just
> switch to 7.0 with eselect and have everything work. It's a lot
> faster and a bit less stupid than previous versions.
>
> In any case, to bring this back on-topic, dev-lang/php now has a webp
> USE flag too, so +1 for making it global.
>
>
Thanks for that - keeps the sysadmin side of me abreast of looming changes !



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New global USE flag: webp

[M. J. Everitt]

On 04/06/16 20:59, Michael Orlitzky wrote:
> On 06/04/2016 03:50 PM, M. J. Everitt wrote:
>> What's the migration path/timeline look like .. I'da thought it would be
>> months/years to move everything that's centred on php5 up to php7 if
>> that's the way things are going. What happened to php6 ?!?
> v5 and v7 are mostly compatible, and the few big changes have had
> deprecation warnings for years.
>
> What happened to 6: you know how some elevators don't have a 13th floor?
>
>
>
LOL - that still happens?!

I still see php5 installed as stable everywhere .. so perhaps php7 still
has a little way to go (not that I would be *so* stupid to suggest that
something like 'debian' was a barometer of such things, nooo..!!!)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New global USE flag: webp

[M. J. Everitt]

On 04/06/16 20:45, Kristian Fiskerstrand wrote:
> would a REQUIRED_USE in newer versions make sense to force the new use
> flag for people upgrading as a deprecation period?
>
What's the migration path/timeline look like .. I'da thought it would be
months/years to move everything that's centred on php5 up to php7 if
that's the way things are going. What happened to php6 ?!?

Personally I'da thought an ewarning would be sufficient based on the old
flag, and perhaps a news item if considered important enough?!

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New global USE flag: webp

[M. J. Everitt]

On 04/06/16 20:39, Michael Orlitzky wrote:
> On 06/04/2016 03:30 PM, M. J. Everitt wrote:
>> The existing use description might be considered slightly confusing,
>> potentially ..
>>
> I changed them to,
>
>   Enable webp support for GD in php-5.x
>   Enable webp support for GD in php-7.x
>
>
Ok so this is really OCD I know .. but might be worth adding the libs, e.g.

Enable webp support for GD in php-5.x via libvpx
Enable webp support for GD in php-7.x via libwebp
[[not checked for syntax]]

for example, but what do I know ... [ie. links the flag to the lib]

:]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New global USE flag: webp

[M. J. Everitt]

On 04/06/16 18:14, Michael Orlitzky wrote:
> On 06/04/2016 12:29 PM, waltd...@waltdnes.org wrote:
>> dev-lang/php:vpx - Enable webp suppoprt for GD
>>
>> ?!?!?!?!  Is that a typo?
>>
> Half and half. The "suppoprt" is obviously a typo, but unfortunately,
> PHP uses a bundled copy of GD, so that isn't.
>
> ...and there's more. In php-7.x, they've dropped libvpx in favor of
> libwebp. Our existing USE=vpx (to pull in libvpx) therefore does nothing
> in php-7.x, so I'm going to change it to USE=webp and have it pull in
> libwebp instead. It takes forever to compile-test, but I'll push a fix
> afterwards. Thanks for noticing!
>
>
php *7* now?!!

The existing use description might be considered slightly confusing,
potentially ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[M. J. Everitt]

On 03/06/16 21:13, Alan McKinnon wrote:
> Walter,
>
> I think you're missing where the devs want to take this and what USE
> is all about. It's about *features*, not about dependencies.
>
> USE="gtk" is a dependency.
> USE="gui" is a feature.
> You only need enable a specific graphics lib flag when there is
> ambiguity about what "gui" means for a package.
>

> Most apps support one toolkit, often either gtk2/3 or qt4/5. It's a
> minority that support both and we have special means to handle those.
> For that small set of apps that do support several toolkits, what
> exactly are you going to force? If you can have one of gtk 2 or 3 but
> not both, which one is it? Well you'd need a USE="gtk2" or USE="gtk3"
> to find out what the user wants.
>
> This proposal makes things simpler and reduces flags and their usage.
> "gui" means build the gui the thing supports.
> "X" stops meaning "gui" or maybe "XLibs" or perhaps "usually RDP but
> also supports magic X11" and starts to mean "X11 Window System" as
> opposed to Wayland or Mir.
> The other toolkit flags start to mean specific versions of toolkits
> and only need be used when things get ambiguous and portage wants you
> you tell it what you want.
>
> In short, flags will get simpler (as cruft will be removed) and flags
> gain clearer distinct names. Think of it as a code refactor after
> years of accumulating rubbish due to no clear plan.
>
> Alan
>
>
>
+1, thanks for the sensible explanation.

I guess it's going to take a while to push the update through the tree,
but I think the clarification is useful where other USE flags have been
previously abused ... use flag abuse is bad generally !



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[M. J. Everitt]

On 27/05/16 16:40, William Hubbs wrote:
> On Fri, May 27, 2016 at 05:21:06PM +0300, Mart Raudsepp wrote:
>> Hello,
>>
>> Despite it being 2016 and gtk2 pretty much dead, buried and forgotten
>> upstream, many applications still support only gtk2, have subtle issues
>> with their gtk3 port, or support both, with some of our userbase
>> clinging to gtk2 for dubious political or aesthetical reasons.
>>
>> For the latter cases, despite GNOME teams policy and strong preference
>> on not providing a choice and just choosing gtk2 or gtk3 (gtk3 if it's
>> working as good as gtk2), some cases exist where the maintainers want
>> to provide such choice. In some cases it is understandable for a short
>> while during transition, e.g firefox. In other cases, it is purely for
>> the sake of providing the choice of working with a deprecated toolkit,
>> apparently.
>>
>> My highly biased essay aside, we need to finally globally agree on what
>> we do in this situation. If we allow this choice at all, only for
>> special cases, or widespread. And if this choice is provided, how do we
>> name the USE flag.
> (qa hat in place)
>
> There is a qa policy about this. All packages in the tree should
> move away from the non-versioned gtk use flag to versioned use flags,
> like the ones the qt team uses [1] [2].
>
> This seems to be the best compromise. It allows the maintainers of the
> packages to decide which toolkit they want to support. If there is too
> much work involved in maintaining a package with dual support, don't do
> the work, just make it support the appropriate toolkit version.
>
> I have not seen any reason why something like this couldn't work. After
> all, it seems to work for the qt team.
>
> William
>
> [1]
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#gtk.2Fgtk2.2Fgtk3_USE_flag_situation
> [2]
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#GTK_flag_situation
Having read the QA policies, surely the route forwards is fairly obvious
thus:-

- gtk is deprecated and discouraged for any new ebuilds
- we add a QA check to repoman to ensure that the 'gtk' use flag is not
used in any new ebuilds
- existing packages using 'gtk' will get updated to use 'gtk2' or 'gkt3'
in the normal cycle

Any edge cases here, or is this something that could be workable?

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] please remove me off your mailing list

[M. J. Everitt]

On 23/05/16 22:37, Kent Fredric wrote:
> On 24 May 2016 at 09:22, Kristian Fiskerstrand  wrote:
>> give a man a fish and he has food for a day, teach a man to fish and he
>> has food for a lifetime
>
> But if you feed a man while you teach him, he's better equipped to learn. :p
>
> Hence, the suggestion includes both.
>
> - Solve the immediate issue.
> - Include information to solving the issue in future.
>
+1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Proposal for enhancement to PMS/EAPI7+

[M. J. Everitt]

On 18/05/16 07:43, Michał Górny wrote:
> On Wed, 18 May 2016 04:07:07 +0100
> "M. J. Everitt" <m.j.ever...@iee.org> wrote:
>
>> I've just been party to a discussion over in the Proxy Maintainers
>> channel .. and the subject of correct ways to install documentation
>> popped up. It seems to me rather quirky, that there is no middle ground
>> in (for example) EAPI6 to have the default documentation installed per
>> https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-144003r4 , PLUS maybe
>> another folder or file(s). The existing framework ONLY allows *either*
>> /only/ the default documentation *or* an override through the DOCS=
>> variable.
>>
>> My idea thus, was inspired by the simple bash DOCS+= ( ) statement, that
>> would allow you to append files/folders to the installdocs list,
>> assuming that DOCS was pre-populated with an existing set of files.
>> Obviously the status quo is set for EAPI6 and algorithms defined, but
>> wondered if it could be considered for a future update/improvement cycle?!
> How is this going to work? In order to pre-populate it, you need to
> know the list of files. And the list of files isn't known until
> src_install(). In fact, with the current behavior it's not even known
> before einstalldocs is actually called, and changing that could break
> stuff.
>
At present the DOCS to be installed in the default function are
hard-coded into the PMS in 'einstalldocs' .. not exactly very good if
you decided later to change it?!



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Proposal for enhancement to PMS/EAPI7+

[M. J. Everitt]

I've just been party to a discussion over in the Proxy Maintainers
channel .. and the subject of correct ways to install documentation
popped up. It seems to me rather quirky, that there is no middle ground
in (for example) EAPI6 to have the default documentation installed per
https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-144003r4 , PLUS maybe
another folder or file(s). The existing framework ONLY allows *either*
/only/ the default documentation *or* an override through the DOCS=
variable.

My idea thus, was inspired by the simple bash DOCS+= ( ) statement, that
would allow you to append files/folders to the installdocs list,
assuming that DOCS was pre-populated with an existing set of files.
Obviously the status quo is set for EAPI6 and algorithms defined, but
wondered if it could be considered for a future update/improvement cycle?!

There are methods (Again, quite clunky) to invoke the default method,
amend the variable, repeat installdocs .. and/or do additional dodoc's
manually, but I would have thought it was possible to incorporate into
the core functions, and keep the ebuild tidy and clean (and short!).

Already been shot down in flames in the IRC channel .. but going for a
second round, to see if there's anyone else similarly insane, who might
agree with me?!

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Proposal for changes for the next EAPI version

[M. J. Everitt]

On 18/05/16 01:44, Kent Fredric wrote:
> On 18 May 2016 at 12:35, M. J. Everitt <m.j.ever...@iee.org> wrote:
>> Yes, whilst that's a special case, it would be desirable to collaborate
>> with another maintainer/team/project to devise a test schedule that was
>> independent from the target language, if possible. But there will always
>> be exceptions and issues and such with these things .. :/
>
> In some of these cases, the things I'd be testing have to rely on Perl
> Modules *because* it has to track how those specific modules respond
> to the code in question.
>
> For instance, to check we're doing our version normalisation
> correctly, we have to use the upstream reference version of Perl's
> version handling code directly.
>
> *NOT* doing this results in significant problems, both in our failure
> to perfectly map upstreams implementation in a different language, and
> in our ability to keep our implementation in consistency with upstream
> changes.
>
> And we have already suffered this problem specifically in euscan,
> where the euscan project implemented the version interpretation logic
> manually, and did so hilariously wrong, and as a result, thinks newer
> versions are older versions a lot of the time, and vice versa. I've
> attempted my own implementation of upstreams logic *better* than I
> think euscan does it, but I'm trapped in the reality where I have *no*
> objective way of knowing if it in fact, represents upstreams logic
> correctly.
>
> The simplest thing to say here is "implementing it in a non-target
> language is often enough the wrong choice".
>
> Similarly, I've made the mistake of trying to understand and interpret
> ebuilds statically without using bash  that's a road to nowhere.
> Even using bash is a bit tortured because I can't understand how an
> ebuild works without reimplementing all the EAPI parts in bash or
> relying on some portage version of the same ( which is extremely not
> easy to use outside of the portage tools ).
>
Yes, I get where you're coming from. I think many of the language and
language-plugin ebuilds are going to suffer from similar problems for
exactly the reasons you describe. It does make the prospect of a good,
over-arching QA/CI system quite challenging (but not impossible) to
achieve .. !!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Proposal for changes for the next EAPI version

[M. J. Everitt]

On 18/05/16 01:14, Kent Fredric wrote:
> On 18 May 2016 at 04:05, Sébastien Fabbro  wrote:
>> Basically CI for ebuilds: it could be implemented as a script living
>> in the package directory, something like a .travis.yml in the GitHub
>> repositories or may be an EAPI change. Debian has a similar project
>> [1]. Upstream could provide CI tests and sometimes they do, but we
>> want to make sure the package integrates well in an installed Gentoo
>> distribution.
>
> Something like $CAT/$PN/maintainers/tests/<*>
>
> or something like that I could live with, the idea being to keep as
> much of this content *out* of the main ebuild flow as possible.
>
> I'd much rather however not to require files in $CAT/$PN to be
> changed, but to have a schema for code that can be run conditionally
> on any suitable package via matching ( CAT, PN, inherit, project=,
> maintainer= ) properties.
>
> Mostly, because there are a lot of places where you'd never want to
> implement the logic for a single package, you'd want to employ it for
> a whole bunch.
>
> Unfortunately, at present, the *sorts* of logic I personally see
> myself implementing would require additional dependencies to perform.
>
> This is why we're not already doing it in src_test(), because it would
> expand the dependency graph for end users without benefit, ( and in
> the way I'm thinking, results in risking a circular dependency, as
> some of the tests I'm wanting to do would require Perl modules
> installed, but these tests are to check things about Perl modules,
> which risks requiring itself to validate itself , and exposing
> users to that is inexcusable )
>
Yes, whilst that's a special case, it would be desirable to collaborate
with another maintainer/team/project to devise a test schedule that was
independent from the target language, if possible. But there will always
be exceptions and issues and such with these things .. :/



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] NEW: split portage/repoman releases now in the tree

[M. J. Everitt]

On 16/05/16 02:39, Brian Dolbec wrote:
> portage-2.3.0_rc1 and repoman-2.3.0_rc1 are now in the tree.
w00t :D
> portage-2.3.0_rc1 is essentially the portage 2.2.28 release with only a
> few small patches applied.  It mostly just installs less code, namely
> the repoman code.
>
> So, now servers and other systems that do not require repo Q/A ability
> will no longer get repoman installed anyway.
>
> repoman-2.3.0_rc1 is the stage2 rewrite code. The checks are now
> modular, and using the portage plugin system. The system is not yet
> fully plug and play. Those changes will take place in the stage3
> re-writes.
Sounds promising :]
> The two packages will remain in the same portage git repo, although the
> repoman code has been moved into it's own pkg directory.  It is too
> tied into portage api's to be on it's own just yet.  An that
> is not likely to happen until we get a stable portage API.  This new
> system does allow for semi-independant releases for both repoman and
> portage.  When important API's change, it will require both to be
> release at the same time.  So you can look forward to seeing the minor
> version number to get more frequent bumps than it has this last decade.
>
> Currently, the portage ebuild does not RDEPEND on the repoman ebuild.
> You will have to explicitly emerge it for it to be installed. It has
> been suggested to add a use flag enabled RDEPEND (default on) for the
> dev profile.  I will also be adding that to the portage- release
> for all profiles in the coming days.
'repoman' use flag for portage? something I'll need to add, since I
don't make (proper) use of profiles ..
> NOTES:  Repoman now depends on lxml for it's xml parsing and error
> checking along with now using metadata.xsd.  It now will report a lot
> more errors than the previous buggy code everyone has been using.
Uh-oh, breakage alert .. you mean repoman now enforces more rules, I
like .. :D
> I want to thank the following people for their help and contributions
> to make these releases:
>
>   Zac Medico 
>   Alexander Bernsten 
>   Dirkjan Ochtman  for the base xml re-write code
>   Michal Gorny  for the metadata.xsd changes
>   Göktürk Yüksek  for the metadata.xml test ebuilds
>   patches.
>   Mike Gilbert  for all the testing on the rewite code,
>   and a number of gen-b0rk repo test ebuilds.
>   
>   Coacher for the recent testing, bug reports and patches.
>   And anyone else I missed ;)
>
> So, please report any issues with either the ebuilds or installs, bugs,
> etc... you know the drill ;)
>
> Don't forget, please contribute more test case ebuilds to the gen-b0rk
> repo.  The better the test ebuild coverage we have, the better our Q/A
> tools (like repoman) will be and the less often things will be released
> broken.
>
> Thank you
Great job to Brian and all the other contributors! Keep up the good work.

Did we find a mechanism to trap updates to the EAPI not being in sync
with portage updates necessarily (I found an edge case bug #577546 - zac
has already given some useful thoughts)?

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 15/05/16 23:55, Duncan wrote:
> Daniel Campbell posted on Sun, 15 May 2016 04:04:57 -0700 as excerpted:
>
>> If the dev in question hasn't done that before, then it's entirely
>> possible they *thought* they tested, or tested it *before* making some
>> other edit and absent-mindedly committed.
> Again, legacy CVS thought pattern.  In git, commit != push, and it's the 
> push that's critical.
>
> Commit all you want without testing.  Just test (and fix if necessary) 
> before you push those commits up to the gentoo master repo. =:^)
>
> (Of course, rebasing to fold the broken commit and its fix into one 
> before pushing doesn't hurt, either.)
>
Surely it should be possible to fire some QA scripts on pre-commit on
the central gentoo repos (ie. at the push target end)?!
Or am I being a bit optimistic ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 15/05/16 02:04, Rich Freeman wrote:
> On Sat, May 14, 2016 at 8:23 PM, Aaron Bauman  wrote:
>> On Sunday, May 15, 2016 12:48:12 AM JST Ciaran McCreesh wrote:
>>> On Sun, 15 May 2016 08:40:39 +0900
>>>
>>> Aaron Bauman  wrote:
 Please enlighten me as to what was impolite here?  The strong
 language of "seriously" or definitively stating that the individual
 did not perform the necessary QA actions before committing?  Both of
 which are completely called for and appropriate.  No vulgarity,
 insults, or demeaning words were used. How would you have responded
 professionally?
>>> It's important to remember that Gentoo is run by volunteers. Expecting
>>> a professional standard when it comes to the quality of commit
>>> criticism is unfair.
>> Applying that same rationale, it would be unfair to say that an undescribed
>> level of professionalism in communication is required as well.  Nothing here
>> violates the CoC.
>>
> If you're only able to behave in a professional manner if the
> standards of professionalism are explicitly spelled out, I think
> you're missing the point.
>
> Ultimately it is an attitude.  When you point out a mistake make it
> either about:
> 1.  Helping the person who made the mistake to improve because you
> want to see them make better contributions (which they aren't going to
> do if you drive them off).
> 2.  If you feel that somebody simply isn't going to cut it, then by
> all means report them so that their commit access can be revoked.
>
> Either of these has the potential to make Gentoo better.  Simply
> posting flames isn't likely to change the behavior of people who need
> #2, and it is likely to discourage people who need #1.  Either is
> against all of our interests in making the distro we benefit from
> better.
>
+1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 15/05/16 01:59, Rich Freeman wrote:
> On Sat, May 14, 2016 at 7:40 PM, Aaron Bauman  wrote:
>> Please enlighten me as to what was impolite here?  The strong language of
>> "seriously" or definitively stating that the individual did not perform the
>> necessary QA actions before committing?
> He actually didn't "state" anything at all - he posted a set of
> rhetorical questions.  And the use of "seriously" was inflammatory.
> In fact, if you're trying to avoid injecting passion into a discussion
> it is worth thinking carefully about just about any word ending in
> "ly" that you put into a sentence.  Nine times out of ten the word
> isn't necessary and can cause more harm than good.
>
>> Both of which are completely called
>> for and appropriate.  No vulgarity, insults, or demeaning words were used.
> I disagree.  The tone was uncivil and demeaning.
>
>> How would you have responded professionally?
>>
> How about this:
>
> You inserted this code snippet into the middle of a command line, so
> it is certain to break in either case.  This should have been detected
> during testing; please be sure to test changes to ebuilds/eclasses
> before committing them.  Additionally eclass changes should be
> submitted to the lists for review in any case prior to being
> committed.
>
> Or by all means refer the issue to QA/Comrel if you want to escalate it.
>
> I'm in no way suggesting that we should accept bad commits.  IMO when
> we see bad commits we should:
>
> 1.  Just point them out politely if it is a one-off.  ANYBODY can make
> a mistake.
> 2.  If they're a trend or show signs of bad practices like not testing
> changes then escalate to QA/Comrel.
> 3.  Let QA/Comrel do their job and block commit access or refer the
> dev for more mentoring/etc as appropriate.  Then we actually fix the
> problem instead of just yelling at each other.
>
+1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 14/05/16 18:52, Rich Freeman wrote:
> On Sat, May 14, 2016 at 1:07 PM, landis blackwell
>  wrote:
>> No fun allowed
>>
> Are you saying that you don't want people to have fun developing
> Gentoo?  Or are you trying to say that it is impossible to have fun
> developing Gentoo without insulting strangers?  I don't think anybody
> minds two friends teasing each other.
>
I think my gut feeling would go "there's a time and a place..." .. and
err on the g-dev ML probably not being it .. unless everyone else is in
on the 'joke' ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 14/05/16 18:06, Rich Freeman wrote:
>
> While this is certainly sensible, the irony here is that this whole
> discussion was started by somebody making a sarcastic remark when
> simply pointing out a mistake would have been just as functional.
>
> Nobody thinks it is ok to commit broken code.  What it seems like
> we'll be debating until there is only one of us left is how
> unprofessional we should be when pointing that out.
>
+1 .. is it time to add  tags too?! :]

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 14/05/16 17:53, Chí-Thanh Christopher Nguyễn wrote:
> Gordon Pettey schrieb:
>
>> So, it's perfectly okay to make direct commits of obviously broken
>> code that
>> has no chance of working, because community something mumble...
>
> You may have missed some sarcasm in the post which you replied to.
> Plus, I don't think anybody said or implied that committing broken
> things is ok.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
I think the time is coming, given the diversity of members of this list,
to add  tags when we are not describing something
literally. It becomes very difficult to follow the thread of
conversation when people are (not) communicating their true thoughts!!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[M. J. Everitt]

On 14/05/16 12:35, Ciaran McCreesh wrote:
> On Sat, 14 May 2016 11:55:42 +0200
>> Am Freitag, 13. Mai 2016, 10:52:09 schrieb Ian Delaney:
>>> On Sat, 7 May 2016 23:25:58 +0200  
 Do you seriously expect this code to work? How about testing? Or
 reading diffs before committing?  
>>> Do you seriously expect us to sit and absorb this form of pious
>>> put down? From one who knows far better who is entitled to speak
>>> down to colleagues as is completely lacking a cerebral cortex?
>>> Those times are drawing to an end. Did anyone ever teach you to
>>> treat folk in such manner and expect them to respect it? I don't
>>> think so Not over my dead cvs perhaps  
>> Well, we still do need some commit quality, you know...
> Why? Gentoo is about the community. Requiring a basic standard of commit
> quality a) reduces the number of community members who are able to
> contribute, 2) leads to fewer forums posts discussing how to fix
> problems, iii) hurts Gentoo's DistroWatch statistics by reducing the
> volume of commits, and fourthly, discriminates unfairly against
> competency-challenged developers by imposing subjective interpretations
> of the value of source code from a position of unearned authority. This
> is against the code of conduct, and is bad for the community!
>
In defense of Gentoo at large .. the entry-level to contribute is really
quite low .. and all the documentation for gentoo 'standards' is widely
documented in both the Devmanual (under revision currently) and the
Package Manager Spec. Not only this, but there are active projects
within gentoo to welcome, nurture and develop devs and contributors
alike so that there is a sustainable level of man-power available to
keep up with the demands of users and pace of code development. Ok, it
can be off-putting to those looking in from the outside, but really I
think it benefits more than it costs.

I agree broadly with the ethos of the QA team, gentoo tends to focus on
quality over quantity where commits are concerned. It's better to retain
a stable, reliable set of packages, with additional untested/unstable
packages available via overlays, rather than a massive, unwieldy number
of packages in a broadly unknown state. As it is, there is a deficit of
active people maintaining the less-widely used packages, and also people
able to add new packages to the tree, and this means that resources are
inevitably spread more thinly.

As always there will be a balance, but this thread did start out with
some tit-for-tat between devs, totally unnecessary either in private or
public. So, ditch that bike-shed, and get on with fixing bugs, closing
issues, adding, updating and deprecating packages, folks :]. Thank you.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] ebuild-writing/variables: better describe ROOT

[M. J. Everitt]

On 10/05/16 16:08, Michael Orlitzky wrote:
> On 05/08/2016 01:42 PM, Mike Gilbert wrote:
>> The current description of ROOT makes no sense and just confuses people.
>> The new description is paraphrased from PMS.
> The current version is bad, but the PMS version isn't great either.
>
> We really need examples for D, ROOT, ED, EROOT, and EPREFIX.
> When/where/why should they (not) be used? How do they compare/contrast?
> A lot of people just guess. Our invocation of emake DESTDIR="${D}"
> pretty well explains $D, but how the rest of them interact is left up to
> your imagination.
Agreed .. the devmanual doesn't expand a lot on this, and many of the
other ebuild variables A, S, etc and how to properly use them.

The 'emake' statement is part of default phases in EAPI5+ so this
may/should(?) not appear in newer ebuilds I would have thought, but
perhaps someone could clarify on this.

Michael.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] amd64 and x32 systemd stages should be ready

[M. J. Everitt]

On 10/05/16 00:08, Rich Freeman wrote:
> On Mon, May 9, 2016 at 6:34 PM, Anthony G. Basile
>  wrote:
>> oh okay.  sorry if i misunderstood.  nonetheless, doesn't the fedora
>> installation cd double as a rescue cd?  i think that uses systemd.
>>
> It might - no idea.  I'm not sure if it is as loaded with useful
> utilities, X11, a package manager, and so on.  Ugh - and it would use
> rpm I guess...
>
>
Did a quick google .. https://wiki.archlinux.org/index.php/Archboot ..
looks like a potentially safer bet ?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] amd64 and x32 systemd stages should be ready

[M. J. Everitt]

On 09/05/16 21:08, Anthony G. Basile wrote:
>
>> Is there actually a decent systemd-based rescue CD out there?
>>
> while i can see some merits to this, eg. running systemd-nspawn from a
> live cd, this is a lower priority.  i don't have any desire to maintain
> this.
>
I rather thought this question was meant as "is it out there (in the
wilderness)" rather than "shall Gentoo generate one" along the lines,
perhaps of the SystemRescueCD .. but with systemd instead of openRC. I
would err that, at this stage (pun excused!) that Gentoo doesn't worry
about a 'System_D_rescueCd' and leaves it to another 'project' although
if any dev wishes to contribute, I'm sure that would be welcomed to it.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] On banning merge commits

[M. J. Everitt]

On 08/05/16 12:13, Andreas K. Hüttel wrote:
> Am Sonntag, 8. Mai 2016, 07:09:31 schrieb Michał Górny:
>>> What is the correct course of action? I would very much like it to be
>>> worded in a document (GLEP and/or Wiki page) so that confusion is
>>> avoided and we all are on the same page on this topic.
>> You start by accepting my retirement.
> I think you should take a vacation for a while... Preferably somewhere 
> tropical, with no internet access and lots of beach... 
>
+5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] amd64 and x32 systemd stages should be ready

[M. J. Everitt]

On 07/05/16 16:09, Anthony G. Basile wrote:
> Hi everyone,
>
> I've been pushing out systemd stage3s for amd64 and x86 and putting them
> under our official releases at [1] and [2].  I think all the bugs are
> out and those stages are pretty tight.  The next step is for me to
> advertise them at [3].
>
> So this is just a heads up.  Let me know if I overlooked anything.
> Otherwise in a week or so, I'll add the links at [3].
>
>
>
> Ref.
>
> [1]
> http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-amd64-systemd/
>
> [2]
> http://distfiles.gentoo.org/releases/x86/autobuilds/current-stage3-i686-systemd/
>
> [3] https://www.gentoo.org/downloads/
>
*gasp* you turned to The Dark Side .. ?! jk .. good work! :]

Re: [gentoo-dev] Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

[M. J. Everitt]

On 05/05/16 08:53, Patrick Lauer wrote:
>
> This ignores the externalized cost for potentially thousands of users
> that have to fix stuff because it was actively broken.
>
To quote an old proverb .. "you can't make an omelette without breaking
eggs" .. if you wish me to explain, I'll do it privately ;)


I don't think anyone (gentoo-wide) is out to make users life difficult,
or make significant work for the precious few package maintainers there
are. There will always be a certain amount of 'change for change's sake'
and whilst there may not always be a direct benefit, there are often
desirable side-effects. I'm not saying this is necessarily a case in
point, though.

I hear the arguments that we are upholding upstream's progression, and I
think that remains one of Gentoo's overriding goals. Sure if its really
a problem for you, fork openrc, maintain it or leave it to bit-rot if
you really think that 'runscript' is the only way to start services.
We/I can't get inside the maintainers head (and wouldn't wish to .. mine
is spaghetti enough already, tyvm!) but rest assured I don't think this
is a debian/fedora/systemd/ issue,
and I think we should just let them get on with it, and be grateful we
have been warned, and this isn't an epic surprise that will generate a
whole stack of reverts down-the-line where someone hasn't done a
reasonable impact assessment of their change...

ok, that's $2 now .. I'll shut up .. I got Real Work to do too ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

[M. J. Everitt]

On 05/05/16 08:32, Patrick Lauer wrote:
> To summarize: Lots of churn, no visible benefit, except that some OCD
> people could feel better: except that we can't actually fix the core
> 'issue' without making lots of other people very sad.
>
>
> Y'all have too much free time ... ;)
>
I'm inclined to say, that provided there *is* someone doing it .. let
them be. Whatever the motives.

We have enough problems with painting the bike shed not to stifle
activity and contribution ...

Just my 2c ... ;]

MJE

Re: [gentoo-dev] Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

[M. J. Everitt]

On 05/05/16 08:17, Duncan wrote:
> Patrick Lauer posted on Thu, 05 May 2016 07:13:00 +0200 as excerpted:
>
>> So again, because I feel like either I'm too stupid to understand this,
>> or too smart to let such an obviously bad idea continue:
>>
>> What problem is being solved here?
> For one thing, the namespace issue of runscript being generic, while 
> openrc-run is properly namespaced and thus much less likely to conflict 
> with anything else.
>
> That would be why openrc's upstream maintainer is changing the name, with 
> appropriate deprecation notice for the old one.  Given that, what gentoo 
> has to decide is how it's going to respond to that.  Sure, we /could/ 
> rename the executable to runscript here and be done with it, but that 
> would violate gentoo's policy of defaulting to consistency with upstream 
> unless there's a very good reason not to.
>
> The fact that the packages upstream maintainer happens to be a gentoo dev 
> and that gentoo happens to host the project and be its primary testing 
> ground and user base shouldn't change that.
>
> Of course if upstream policy is thought by devs willing to do the work to 
> be irrational, they can of course fork the package.  There's certainly 
> precedent for that.  But someone's gotta be willing to do the work 
> necessary to create and maintain that fork, so...
>
+1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New gen-b0rk repository specifically for Q/A tools testing

[M. J. Everitt]

On 02/05/16 00:53, Brian Dolbec wrote:
> In order to further improve the chances of Q/A tools catching
> errors.  I have created a new repo (overlay) which will contain minimal
> test case ebuilds.  The idea is to have test case ebuilds to run
> repoman code against.  The outcome of these runs should be comparable
> to pre-recorded output.  In that way as more code changes are applied
> as part of the stage3 re-write as well as new test cases and checks to
> be added to it's capabilities.  It should minimize the bugs introduced
> in releases.
>
> Repoman does have some unit tests, but it is far from 100% coverage.
> Also with the major structural changes that the code has been
> undergoing, it is not always possible for the unit tests to be
> compatible with the new code.
>
> This new repository is open to all Gentoo developers to contribute to.
> All we ask is that you follow some simple common sense rules for adding
> additional test ebuilds.
>
> The repo is located at:
>
> https://gitweb.gentoo.org/repo/proj/gen-b0rk.git/
>
> Here is the README included in the base directory.
>
> This repository is for the primary purpose of testing Q/A tools like repoman.
>
> The ebuilds it contains are for testing specific areas of tests that are
> performed as part of the normal operation of that Q/A tool.
>
> This repository is open to all Gentoo developers under the following rules:
>
> 1) The master branch is to remain the stable Q/A testing branch.
>
> 2) All ebuilds are to be minimal test cases.
>
> 3) All ebuilds in it are to have no more than 3 or 4 flaws to detect.
>This makes it easier to spot errors during code development.  Simply 
> running
>repoman in a category should be enough to test everything the module tests.
>This excludes some commit only checks which can be run in a local only 
> branch.
>
> 4) All category names are to represent the Q/A category being tested.
>   ie:
>   ebuild-test - tests various aspects of the ebuild repoman module
>   eclass-test - various eclass module tests
>   ...
>
> 5) like the category naming, the package naming will follow the test
>being performed.
>ie:
>eclass-test/live-keywords - test the eclass module LiveEclassChecks
>keywords check
>ebuild-test/invalid - test for invalid package name detection
>
> 6) Profiles ... Not sure about this one, but probaly will have masters=gentoo
>That should ensure it maintains co-ordination with the main gentoo repo.
>All new or modified eclasses that affect pkg metadata should be validated 
> in
>a branch.
>
> 7) New module development and test ebuilds will be done in a branch or 
> personal
>repo and submitted to the gentoo-portage-dev email list for review and
>approval to merge into master.
>NOTE: This rule is lifted for the initial creation and population of
>  test ebuilds to use to test out the repoman code.  An anouncemnt to
>  the gentoo-project email list will be made when this initial 
> population
>  period is being ended.
>
> 8) Signed commits only, also signed-pushes are mandatory
>
> 9) The metadata category will get files of validated output that can be used
>to verify code changes in the various categories and repo wide runs.
>Diffing the output, should help to verify code changes did not break 
> anything.
>
> 10) See rules 1-9 :-)
>
+1 be good to have somewhere central for this stuff :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

[M. J. Everitt]

On 20/04/16 19:17, Mike Frysinger wrote:
> agreed ... we have kernel_Winnt & elibc_Winnt already.  i think
> those represent a mingw environment (vs a cygwin env).
Surely 'winnt' is a somewhat out-of-date and potentially confusing flag?
Can't we migrate to a win32 and win64 as pertaining to current/recent
architectures, and directly relating to mingw32 and mingw64 or such-like?!

Sooner or later win32 is going to be EOL (as the operating systems
themselves soon will be) ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-qt/qtmultimedia/

[M. J. Everitt]

On 18/04/16 16:47, Michał Górny wrote:
> This is invalid. Replacing invalid package names with other invalid
> names is no fix. It is ugly Gentoo-style hackery which proves that
> developers prefer trying randomly changing something until QA check
> doesn't trigger over reading the documentation. As a result, now
> a number packages with visible QA issues have been turned into a number
> of packages with QA issues that aren't caught by the schema due to
> regexp limitations.
>
> Please go over all the packages you've touched and fix the silent
> issues you introduced. I can't afford to waste more time writing more
> complex QA checks that are going to cover all the ways Gentoo
> developers can screw up such a simple thing as package *name*.
>
I can't help but want to write .. "If you want a job doing ... "

+1 monp.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [warning] the bug queue has 82 bugs

[M. J. Everitt]

On 13/04/16 07:49, Austin English wrote:
> On 04/11/2016 04:00 PM, Alex Alexander wrote:
> > Our bug queue has 82 bugs! > > If you have some spare time, please help 
> > assign/sort a few bugs.
> > > To view the bug queue, click here: http://bit.ly/m8PQS5 > > Thanks!
> I got it down to 6. Enjoy.
>
> -Austin
Austin+++


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New eclass: mate

[M. J. Everitt]

On 11/04/16 06:09, NP-Hardass wrote:
> Greetings all,
>
> As all potential new eclasses are supposed to be discussed here, I
> thought I'd file a message and see if anyone had anything to
> contribute on the matter.
>
> I'm in the midst of a major version bump for the entirety of the MATE
> desktop environment, consisting of 40-50 packages.  There is a huge
> amount of repetition in my ebuilds, and a lot of things are formulaic
> (SRC_URI, HOMEPAGE, EGIT_REPO_URI, inherits, src_prepare, etc).  As
> such, I think that moving all of that to an eclass would greatly
> simplify my life and my ebuilds, so I thought I'd look into creating
> an eclass.
>
> Any opinions either way?   Thanks in advance.
>
>
I say go for it .. post up any milestones for review, of course... :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 04:49, Rich Freeman wrote:
> 1. As you point out, its not a package.  That means it works
> differently than everything else, and it can't be used as a
> dependency/etc.
> 2. Genkernel's initramfs isn't all that great.  Don't get me wrong -
> it was very good back when it was new.  However, I find it hard to
> compare it to the likes of dracut.
>
> However, if it were all that serious of an issue somebody would have
> fixed it by now.  Manually building a kernel and using dracut is easy
> enough, and of course some prefer to not use an initramfs if their
> configuration allows it.
>
I haven't dared explore dracut because last I heard it was still
experimental. That people are actively using it (presumably in
production and not just experimental/development suggests at the very
least that the appropriate Gentoo wiki article needs updating (no
surprise there!).

Perhaps indeed genkernel needs some updating. When I last looked at the
best means of creating an initramfs, it was the least of the evils, but
there did seem a genuine lack of tools to accomplish it, which is where
I assume dracut came about.

Fundamentally, acknowledging a tangent of the original thread, I'd say
the jury remains out on whether Gentoo should be forcing the need of an
initramfs/rd on its users by default anyway. That kind of thing,
however, is of course, subject to a Council ruling if appropriate :) .



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 04:08, Rich Freeman wrote:
> I think the bigger issue with the kernel is the huge configuration
> space it has.  Chromium may have a ton of USE flags compared to most
> packages, but those pale in comparison to the kernel.  Obviously it
> would not make sense to try to create a USE flag for every
> configuration option.  Now, a package that built and installed a
> kernel might have a few USE flags.  For example, it might have flags
> equivalent to the gentoo config add-ons (for openrc/systemd, and so
> on).  It might also have flags that give it some default
> configuration, or an all-modules configuration, or an all-builtin
> configuration.  I imagine that most distros ship something close to an
> all-modules config.
>
> In any case, that isn't really any kind of policy issue.  For whatever
> reason nobody has bothered to create a package.  Certainly nobody
> would object to somebody adding a new kernel package that builds and
> installs a fully configured kernel.  It might even become the
> recommended default in the kernel (without getting rid of the other
> options).
>
Ok I'm gonna push the Big Red Button here, and assume you may not have
met 'genkernel' .. ok its not a package, but its the nearest thing to
Gentoo's solution to what you're suggesting ... And it's in the Handbook
.. so, where's the issue, again?!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 03:06, Rich Freeman wrote:
>
> By that argument, when you run emerge chromium shouldn't it just dump
> the chromium sources in /usr/src, so that you can build and install
> your own chromium?
>
> The whole point of a source-based package manager is that it actually
> BUILDs the packages.  Why do we treat the kernel differently from
> every single other package?
>
> I get that users often want to build their own, and that is fine.  We
> SHOULD have a package that dumps sources in /usr/src (though to be
> honest I prefer to just fetch mine using git).  However, why shouldn't
> emerge virtual/kernel not just give you a /boot/vmlinux-x.y.z the same
> way that emerge vim gives you a /usr/bin/vim?
>
I take your point, but I would argue that the kernel and boot subsystem
really are special cases .. you don't go hacking around the chromium
sources to fundamentally alter the way/order it works, right?! Likewise,
if you don't like chromium, you might install firefox .. cf. say, Lilo
and grub. It is the flexibility (and, I concede, the complexity, and
hence 'power') that defines Gentoo here.

This also applies to the whole /usr debate .. and yes, I agree there are
caveats with both our existing setup and many of the others discussed on
this thread. I think there is a debate to be had, and whilst it has born
the inevitable bike-shedding, I think there could be some merit in a
'flattened' system. I suppose the natural follow-on question from this,
is "how best to achieve it?".



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 02:14, Rich Freeman wrote:
> Part of me also wonders if Gentoo would be better off having emerge
> gentoo-sources actually BUILD the kernel and initramfs and not just
> dump a bunch of sources on the disk.  Most distros consider an
> initramfs a no-brainer because it just ships already setup, and an
> initramfs is a lot more forgiving when you add a new drive and your
> firmware/kernel decides to re-number everything.  Just label your
> filesystems or store UUIDs and the initramfs will figure out what
> happened.
>
I think that is the potential for a stage4-style install. I think
previous list discussions have maintained that the flexibility of gentoo
is maintained by having a very basic install image, and a stage3 to
bootstrap into, and have the user compile their own kernel.

Otherwise, go install debian/ubuntu/choose-your-own-ready-boxed-linux
... gentoo isn't that kinda distro. Imho.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 10/04/16 00:53, William Hubbs wrote:
>
> The original discussion was about the usr merge [1], which is taking the
> binary parts of / and putting them in /usr, then inserting symlinks in /
> to preserve backward compatibility. Yes, I'm pointing to a document on
> fdo, but the systemd guys have nothing to do with the /usr merge; it
> originally happened in Solaris.
>
> I never supported the reverse merge that has been discussed, it was just
> brought up I guess as an example of a Gentoo user being able to do his
> own setup. Reverse merge meaning moving everything from /usr to /.
>
I may have contributed to the latter point, but addressing the former
specifically, I, like others, have /usr mounted on an NFS server for
thin clients (not in the full-true sense, but with a very minimal /
currently residing on USB).
What you propose moving binaries from / to /usr would render them
completely unbootable without early mounting via initramfs. Granted,
what I have now is rather a bodge, but it's working fine, and provided I
am meticulous about any rare changes from the host build system to /,
this is a small problem in the grander scheme of things, and I have one
maintained 'install' on my build system. Ok, so a full thin-client would
probably be a better* option, but I'm running with what I got, rather
than investing a lot (of/more) time/energy in getting that solution
working, which failed on (several) previous attempts (hence *).



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 09/04/16 23:50, Philip Webb wrote:
> 160409 Canek Peláez Valdés wrote:
>> On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb  wrote:
>>> I've always used Lilo, which is simple + reliable :
>>> I never see questions re it here, but there are many re Grub.
>>> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
>>> When setting it up, I suppressed UEFI in the BIOS settings :
>>> isn't that what anyone not running M$ would do ?
>> I just disabled secure boot, although it's possible to use it with Linux.
>> However, it would require to manually sign everything from boot loader
>> to kernel modules, since Gentoo has no infrastructure to do that.
>> I don't "supress" UEFI, since it's *obviously* so much better than BIOS
>> and since bootctl (the program formerly known as gummiboot)
>> it's incredible easy to use. You don't even notice it's there.
> Sorry, I meant "suppress secure boot".  My mobo doesn't have UEFI.
>
>> I believe there are motherboards where you don't have the option
>> to "supress" UEFI, since they simply don't have BIOS anymore.
>> Seriously, UEFI is s much better.
> Thanks for the enlightment (smile).
>
> Can you or anyone else answer my other question re the origin of the thread ?
> -- ie is this a revival of not putting  /usr  on its own partition
> or is it a new proposal to alter the file system in some other way ?
>
Philip, the discussion was prompted from this original message by WilliamH:

https://archives.gentoo.org/gentoo-dev/message/df3c1494ea49191d4e3d442e37eb8ca2

Basically there is a desire to either (1) move /bin, /sbin to /usr/bin,
/usr/sbin or (2) the reverse (ie. eliminate /usr) for a variety of
reasons, but predominately to offer "more users more choice", and uphold
the principle of Gentoo being a distro of flexibility.

Whilst there is some good pros/cons being aired, there is also the usual
amount of gentoo bike-shedding, and personal preference distorting the
discussion :) .



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 09/04/16 20:53, Rich Freeman wrote:
> On Sat, Apr 9, 2016 at 3:49 PM, Philip Webb  wrote:
>> I've always used Lilo, which is simple + reliable :
>> I never see questions re it here, but there are many re Grub.
>> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
>> When setting it up, I suppressed UEFI in the BIOS settings :
>> isn't that what anyone not running M$ would do ?
> That depends on how much you care about rootkits...  :)
>
Rootkits in linux ... why?!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 08/04/16 16:02, Rich Freeman wrote:
>
> The only mandatory component in a linux system, by definition, is the
> Linux kernel.
>
> A linux system could consist of nothing but a kernel with
> init=/usr/local/bin/hello-world.
>
> Most traditional linux distros are going to run policykit though.  Of
> course you can have a mostly-traditional distro that doesn't, at least
> until everything wants to use dbus or whatever ends up replacing it
> once son-of-kdbus comes along and gets accepted.
>
Being serious though, and playing Devil's Advocate of course, assuming
you have no use for a desktop manager, etc, hence no need for dbus or
it's 'friends' and policykit or it's pals, and you're not a "systemd
fan" etc .. how are we granting the correct permissions for binaries ..
just relying now on the owner and execute bits being set perfectly for
each binary, assuming everything is arbitrarily moved to /xbin ...

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 08/04/16 16:02, Rich Freeman wrote:
> On Fri, Apr 8, 2016 at 10:33 AM, M. J. Everitt <m.j.ever...@iee.org> wrote:
>> I'll come back to the links a bit later, but is policykit and its
>> predecessor/derivatives now a mandatory part of a linux system?
>>
> The only mandatory component in a linux system, by definition, is the
> Linux kernel.
>
> A linux system could consist of nothing but a kernel with
> init=/usr/local/bin/hello-world.
>
> Most traditional linux distros are going to run policykit though.  Of
> course you can have a mostly-traditional distro that doesn't, at least
> until everything wants to use dbus or whatever ends up replacing it
> once son-of-kdbus comes along and gets accepted.
>
Surely, Rich, you mean init=/bin/hello-world ... ;]

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 08/04/16 15:20, William Hubbs wrote:
> On Fri, Apr 08, 2016 at 03:44:06AM +0100, M. J. Everitt wrote:
>> 3) I still believe there is merit in distinguishing between binaries
>> that can/should be run as root, and those that can/should not. Those
>> that run as root 100% of the time, or use VMs, don't really 'use' linux
>> in the original sense of the OS ..
> Here is more info about the split and why it exists. It turns out it hs
> nothing to do with system admininistration or permissions.
>
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
> http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split/
> https://news.ycombinator.com/item?id=3519952
>
> In short, this is all a historical artifact with justifications thought
> up after the fact.
>
> William
I'll come back to the links a bit later, but is policykit and its
predecessor/derivatives now a mandatory part of a linux system?

Possibly crossing posts here, so apologies in advance .. ! :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 08/04/16 03:36, Damien Levac wrote:
> Anybody who have this kind of misconception about 'usr merge' should
> read this:
>
> https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
>
> Signed,
>
> a user who got scared by this thread and documented myself before
> freaking out too much...
>
>>> Personally I think that merging things into /usr is a major policy >>
> decision that is likely to contravene upstream installation
>>> locations.  I wouldn't do it lightly, if at all.
>
Three points :-
1) systemd - not all gentoo users subscribe to this 'philosophy' .. but
no, I don't want get drawn into debates of yes/no of systemd ..
2) "Today, a separate /usr partition already must be mounted by the
initramfs during early boot, thus making the justification for a
split-off moot." - no, not all gentoo users have an initramfs and
need/want one .. so this is a false assumption.
3) I still believe there is merit in distinguishing between binaries
that can/should be run as root, and those that can/should not. Those
that run as root 100% of the time, or use VMs, don't really 'use' linux
in the original sense of the OS ..

*hides in his bike-shed, awaiting the flaming torches*

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 07/04/16 17:36, Alexis Ballier wrote:
> On Thursday, April 7, 2016 6:22:16 PM CEST, Rich Freeman wrote:
>> Again, I don't see this as a reason not to make it optional, but I
>> suspect that we will find bugs here from time to time which users who
>> run with the split /usr will have to report/fix.
>
>
> Considering the advantages of usr-merge are rather specific IMHO but
> risks during the migration are high, I think you're optimistic on the
> user base of usr-merged systems :)
>
> Heck, it hasn't happened yet because there hasn't been such a big need
> for it.
>
In the spirit of hearing arguments for/against .. could someone with the
appropriate 'fu' throw up a quick survey for those on this ML (and/or
possibly the g-users?) to indicate a preference for a change to a
flattened-/usr system?

I did think re: the eudev "debate" that it was really hard to quantify
the opinion for and against a change, and take it away from the  vocal
people that obviously feel passionately about their cause :) .



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News item: upgrading to Plasma 5

[M. J. Everitt]

On 07/04/16 01:45, Jonathan Callen wrote:
> On 04/06/2016 07:46 AM, M. J. Everitt wrote:
>
> > In the event you're not explicitly using a desktop or KDE desktop
> > profile, can you provide a summary of the changes that should be
> > made manually when switching the the kde-plasma/* ebuilds please? I
> > can probably handle a display manager change over a network of
> > systems, but making a sensible transition to Plasma5 over many
> > systems could be a trial if a small step is overlooked Thanks!
>
> > Michael/veremit.
>
>
>
> The list of things that the plasma profiles add to the system can be
> found in ${PORTDIR}/profiles/targets/desktop/plasma/.  The
> make.defaults and package.use in there show which USE flags a default
> plasma install would need (in addition to the standard desktop profile
> and the flags enabled by default in the ebuilds).  Note that most of
> the changes are either a) disabling things in some old KDE 4 stuff
> that hasn't been ported completely, to just have the bits still
> required on a mostly-ported system, and b) choosing which
> implementation (Qt4/Qt5) on packages that require you to choose (the
> profile ends up enabling USE="qt4 qt5" for most packages, this turns
> off one of them for some packages).
>
Thanks, I'll dig over those and see if the wiki page can be tweaked
slightly :)

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

On 06/04/16 17:06, Richard Yao wrote:
>
> That does not address the problems of supporting this configuration in a
> rolling release.
>
> Formats in /etc can fall out of sync with software in /usr. If boot
> options change, the stuff in /etc/init.d is not updated. If you add
> software, the update to /etc/init.d is omitted. If you have a baselayout
> change, it is not propagated. Whether or not the package manager can be
> used is not discussed. It definitely can be in Solaris when this feature
> is used in Solaris zones, although I am not sure how that interacts with
> updates as I never looked. I do not have a VM with a member of the
> OpenSolaris family handy to check.
/usr/etc .. or /usr/local/etc *ew* ... ?!?!
> Solaris and RHEL will see the benefits described on the Fedora page
> because they handled many of those problems. In most cases, they handled
> it by being stale non-rolling releases that do not support major version
> upgrades. Fedora handled it by having a disclaimer that things should be
> expected to break across Fedora versions. Neither are things that I
> expect us to do, so if we adopt this, we will need to do something
> entirely new to be able to gain these benefits.
>




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] usr merge

[M. J. Everitt]

What, if any, is the benefit of squashing /usr out of the equation? I
happen to have a few workstations that load their /usr off an NFS share
presently, with some bodgery-workarounds I did pre the udev notification
about initramfs's which I have never got around to implementing
(although I'm pretty sure I have the tools now to do, along with UUIDs
for boot media).
Whilst these aren't currently scheduled for upgrade, I don't personally
see any merit, given discussions here about work needed to 'shore up' a
change to match some particular use case. I would therefore definitely
agree with those that have proposed that this is an Option and not a
standard gentoo install item unless there are some specific caveats that
this solves.

Michael/veremit.

On 05/04/16 02:19, William Hubbs wrote:
> All,
>
> I thought that since the usr merge is coming up again, and since I lost
> track of the message where it was brought up, I would open a
> new thread to discuss it.
>
> When it came up before, some were saying that the /usr merge violates
> the fhs. I don't remember the specifics of what the claim was at the
> time, (I'm sure someone will point it out if it is still a concern).
>
> I don't think creating usr merged stages would be that difficult. I
> think it would just be a matter of creating a new version of baselayout
> that puts these symlinks in place:
>
> /bin->usr/bin
> /lib->usr/lib
> /lib32->usr/lib32
> /lib64->usr/lib64
> /sbin->usr/bin
> /usr/sbin->bin
>
> Once that is in place in a new baselayout, I think portage's colission
> detection would be able to catch files that had the same names and were
> originally in different paths when building the new stages.
>
> I put some thought also in how to nigrate live systems, and I'm not sure
> what the best way to do that is. I wrote a script, which would do it in
> theory, but I haven't tested because I only have one system and if
> it breaks it the only way back would be to reinstall.
>
> The script is attached.
>
>
> Thoughts on any of this?
>
> William
>




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] GPG key

[M. J. Everitt]

For those having a minor panic, I've just imported my home email GPG key
to my work PC .. so that's the reason I've sent out an erroneous email.
Rest assured the key is -right- and thanks to K_F I have two properly
functional Thunderbird/Enigmail installs working with kwalletcli from
pinkbyte's overlay.

Ping pinkbyte .. there's an update for kwalletcli up now, I'll proxy it
into main tree if you don't mind.
Cheers,

Michael/veremit.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News item: upgrading to Plasma 5

[M. J. Everitt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/04/16 18:34, Michael Palimaka wrote:
> Hi,
>
> KDE team intends to stabilise Plasma 5 shortly, so please review the
> accompanying news items.
>
> Regards,
>
> Michael
>
> Title: KDE Plasma 5 Upgrade
> Author: Michael Palimaka 
> Content-Type: text/plain
> Posted: 2016-04-02
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed: kde-base/plasma-workspace:4
>
> KDE Workspaces 4.11 has reached end of life and is no longer supported
> by upstream. It is therefore recommended for all users to upgrade to
> KDE Plasma 5.
>
> A detailed upgrade guide is available[1], but in most cases it enough to
> switch to the new desktop/plasma profile, update @world, and
> emerge kde-plasma/plasma-meta:
>
> # eselect profile list
> # eselect profile set 
> # emerge --ask --changed-use --newrepo --deep world
> # emerge --ask --verbose kde-plasma/plasma-meta
>
> If you normally use KDM to launch Plasma, note that it is no longer
> supported.
> Upstream recommends x11-misc/sddm instead which is pulled in by
> plasma-meta by
> default. To switch, edit /etc/conf.d/xdm and update DISPLAYMANAGER.
>
> Due to an an evolution of KDE upstream's release process[2], the
traditional
> monolithic KDE 4 release is now split into three distinct components. This
> means that KDE Applications are now separate from the Plasma desktop and
> older KDE 4-based applications will continue to function as normal
> inside Plasma 5.
>
> KDE Workspaces 4.11 will remain in the tree for a reasonable time, but
> be warned that it is unmaintained and may cause conflicts with
> newer versions of KDE Applications.
>
> [1] https://wiki.gentoo.org/wiki/KDE/Plasma_5_upgrade
> [2] https://dot.kde.org/2013/09/04/kde-release-structure-evolves
>
>
>
In the event you're not explicitly using a desktop or KDE desktop
profile, can you provide a summary of the changes that should be made
manually when switching the the kde-plasma/* ebuilds please? I can
probably handle a display manager change over a network of systems, but
making a sensible transition to Plasma5 over many systems could be a
trial if a small step is overlooked Thanks!

Michael/veremit.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXBPb/AAoJEEwwM0+TwiNxxvAP/3+pJZdU+iQBwiGWep9iostE
mQFoIuP5uT4iraXBzxvZ9xzBPC8Tf0XegE9gXoLyWTEqc0/gtzGK+/Sfqv0TlQ0a
F3uUt8zRFZH45sdSrfHlbALCkhGpxeHe13WsIilNgS41u/0zIoV9+TszctbEQPam
XYt90iDT6eSfdVHfnL3vtaK5ymqe6gHFYVDuP4+08hcDn557IeVmKfZGZJOcVoFX
pk+p9zNrVP9971SGHJIjl/1DAcz34U4PmBrvXyE5/ziH5cgfAofuL1JulsPoldBy
RwJy3b0pCRYwoju+TxrkNtWxX9wFcG5J+ofTFTONO6Aez1vo/tP+WBiQD1MieDGN
2qyq4ATaIJhZj6hSuLZ2/GKws3eSihHLKMTRg+2WjeQnJNOHjJ2yFbHZ/1pCH4Gg
+Ql0KgIrcKkrwJdKVwP1FEsQPmAmAkS+7zgl987ITxqahJTB2bbqFWmwb8dudg/4
wjbH5YWLy6FRrFDkMqxF+//vMnpJ7TDssbsyAFXbVmFFuiBFCfgJ1lDjuy0anZH4
1VqYa3I4+ZrQy1LX0+pts28PUudLZgxArHotXd+hqdKmIUtyzppdgTdNMom3Ol2b
jSlTITqJePKa1HwOIt0G1eJMwRJy0P1mySJF0Uhi8NVZ0eT+he3J/KNnDsisB/ac
mGGHpOPmx8slMDQTLVg7
=ZRRc
-END PGP SIGNATURE-

Re: [gentoo-dev] [PATCH v1 1/3] general-concepts/herds-and-projects: update per GLEP 67 #572144 #549490

[M. J. Everitt]

On 04/04/16 05:57, NP-Hardass wrote:
> On 04/04/2016 12:34 AM, Göktürk Yüksek wrote:
>> +sufficient for adding or removing a developer. Note that
>> different +projects have different requirements and procedures for
>> recruiting +developers, which may require prior arrangements to be
>> made before +modifying the member list.
> I'm not particularly fond of this statement.  The implication is that
> most projects require permission, whereas I believe that the opposite
> is true.  To the best of my knowledge, most projects are open, and
> ones that have special requirements almost always list them explicitly
> on their project pages.  As far as I know, the only exception to this
> is new developers, as they are noobs and thus project lead approval is
> a slight quality control. I'd rather see it worded more like:
> 
> Seasoned developers, generally speaking, can join any project at their
> leisure, however, some projects explicitly list restrictions or
> requirements to join such as training, apprenticing, or approval of
> the project lead.  When in doubt, consulting the project/lead prior to
> joining a project.
> 
> 
Still needs some work, I think ... :)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grab

[M. J. Everitt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/03/16 19:48, Christian Ruppert wrote:
> app-forensics/lynis
> dev-libs/log4cplus
> dev-vcs/colorsvn
> dev-vcs/git-deploy
> dev-vcs/topgit
> sci-electronics/fritzing
> sys-auth/libnss-cache
> media-video/nvidia-settings
>
> Feel free. If you need some more info please poke me on IRC.
>
I'll proxy fritzing until such time as I get 'devs' if nobody has spoken
up by end of month and agreed by others.

Christian: Will drop you a msg on IRC for a quick heads-up :).

Michael aka 'veremit'.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJW6pS9AAoJEEwwM0+TwiNxXjcP/0TiMUeZWn3aB2VJ2hP6OYvC
mr6c1LHukq6mm6ZfC4hAyDyZjCTI9r+ukTNTBGqcoASljOy4kHsee1H77uU4OzGb
xQczK1bQoSK/88MMvflZPgWj7gIHwvFd8gkcqG1zlJpCZHA0OI+KBnmE2E7LqwSu
vEti1B1rho8vOAO03/++YnbfJ/A1JamcI1Im4hNDA8nP9LuLttTrTQR0qTpkoBG0
l4Y3qgH4zbCRFmkhD2XgvU/8bXB78AgkNhAL00k8CjjAeKcCujzhUL+uxIAUcttg
TlszEYSAKjW+EFJDRtowBIx66OUkwrjrodpPfaXlFomLatjTUYgAx1nOQsj08Xj2
BVvzEompbPlys25dV21+IDXsJjOnFTbrjOhWxo1hdttxlrw7iS91SMsPtzEKcX8v
pt6ni9yRSdMQcPS3fgjqP1COI9C3GrL/6AXUnVRAWy4IlEFMmAED/VmjKOunL602
y+Rx8NuKtY8WD3MDWOihfNHTOgyTEY32r2g869Qd/jCQpYzFE6ev91i/WrGqmbXN
fKteUokiTms5NaoW5h3Smnaw53uV3YWF6F1f2w7HTcBMJOBEKrNzKTN3lQZLeS1l
TNX2wgnGJKnDZPJR9pRUnt51hsGQT+QoLtVfiNtuuBARyWPcesNiJAhniZVLN6ZM
b8l40UazJ1n5HFl0lZKm
=FUvC
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Bug #565566: Why is it still not fixed?

[M. J. Everitt]

On 25/02/16 08:59, Kent Fredric wrote:
> On 25 February 2016 at 21:02, Consus  wrote:
>> Well, we do have one
>> 
>> https://gitweb.gentoo.org/repo/gentoo.git/log/dev-lang/perl
>> 
>> I bet folks want to check out what's new in their local copy of 
>> Portage tree.
> 
> 
> With a custom, portage oriented, on-demand log generator you could
>  produce a lot more detail ( and in a text format that doesn't 
> require a web browser to view ) , and potentially use
> understanding of portage conventions to generate change data
> outside those explicitly stated.
> 
> Though that would be a "later feature" you could potentially bolt 
> on after the main logic was sorted out.
> 
> The idea being you could request a changelog for a package with a 
> list of "interest aspects" and have the log reduced to changes
> that affect those interests.
> 
> For instance, you could do :
> 
> curl http://thing.gentoo.org/changes/dev-lang/perl?arch=~x86
> 
> And with a bit of effort, you could generate a changelog that is 
> only relevant for somebody who is on ~x86, eliding changes that
> x86 didn't get yet.
> 
> For instance, an ~x86 filter would elide stabilizations for ~x86, 
> because you don't care about stabilizations if you're assuming 
> ~arch. ( And it would elide changes that were only visible for 
> other arches )
> 
> And this filter wouldn't necessarily be implemented in "grep for 
> keywords in the commit message", but *analyse the change in the 
> directory* based, which would give the ability to do things that 
> would otherwise only be possible with a git clone.
> 
> 
> 
This idea is quite neat - you could do either some basic User-Agent
check and either render a web page for viewing online for changes, or
even have a specifier that gave you some other output options .. eg.
ChangeLog (rev. chron) or basic web or XML or JSON which you could
then post-process if you desired.

I know this is kind of bloating the idea, but the flexibility and such
would make it Really Useful .. I think, anyhow ...

MJE

Re: [gentoo-dev] Changing order of default virtual/udev provider

[M. J. Everitt]

On 17/02/16 13:38, Chí-Thanh Christopher Nguyễn wrote:
> Michał Górny schrieb:
>>> With the exception that Lennart Poettering is the lead developer of
>>> systemd/udev, while such a thing cannot be said about you and eudev.
>> He's lead developer of *systemd*. udev is a split part of systemd
>> codebase which has specific maintainers.
>
> systemd and udev share the same codebase. You can no longer build udev
> without systemd. udev is only a sub-project of systemd now, hence the
> name "systemd-udevd".
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>
How hard is it to understand that there really is no longer a standalone
udev .. it's part of another project .. therefore no longer separate.
One of the developers already works for systemd. The other is clearly
busy with kernel coding.

My two cents for today:

https://en.wikipedia.org/wiki/Udev
http://without-systemd.org/wiki/index.php/Main_Page

+5 for Chi-Thanh for keeping it factual and objective.

Re: [gentoo-dev] Changing order of default virtual/udev provider

[M. J. Everitt]

On 15/02/16 05:28, Mike Frysinger wrote:
> On 15 Feb 2016 02:31, M. J. Everitt wrote:
>> I think people are confusing the fact that there IS no separate
>> 'udev'
> 
> i'm fully aware of this fact and have been since it happened. i
> don't think it changes my point. -mike
> 
It wasn't necessarily aimed at you .. just clarifying the point that
for others the point may not have completely sunk in :)

Re: [gentoo-dev] Changing order of default virtual/udev provider

[M. J. Everitt]

On 15/02/16 02:16, Mike Frysinger wrote:
> On 14 Feb 2016 15:56, Anthony G. Basile wrote:
>> On 2/14/16 3:47 PM, Mike Frysinger wrote:
>>> On 14 Feb 2016 15:42, Anthony G. Basile wrote:
 On 2/14/16 3:23 PM, Mike Frysinger wrote:
> eudev: no one of any relevance outside of Gentoo runs it.
 that's not true, nor is it the central criticism, imo.
>>> can you list the projects that utilize eudev ?  the repo doesn't
>>> that i can see.  it is the central criticism imo when correct
>>> interaction with other projects is key.  people rely on rules being
>>> parsed & run correctly, as well as information provided by udev
>>> matching what they are running/testing everyday.
>> until patrick brought up the list of distros, i was only aware of
>> alpine which is a musl based distro.  then puppy and slack came
>> forward.  they build their entire system using eudev as the libudev
>> provider.  if there were issues, they would bring forward bug reports
>> like any other project.
>>
>> so when you say "people rely on rules being parsed ..." i don't know
>> why those user bases are dismissed.
> i'm not dismissing them per-se.  i'm being practical here: i think you
> can agree that the combined developer base of alpine/puppy/slack(ware?)
> is significantly smaller as compared to the distros using udev.
> -mike
by "udev" do you mean systemd (as they are losely one-and-the-same) or
the unsupported udev-severed-from-systemd ...
Of course there is no comparison between Anthony's work on eudev and the
systemd 'crowd' it's just a non-question.

I think people are confusing the fact that there IS no separate 'udev'
.. it is the work of a gentoo maintainer to make it work without
systemd. To this end, does it really matter that OpenRC users are
reliant on a gentoo developer applying heavy patching of 'upstream'
udev-for-systemd .. or another gentoo developer working on an
alternative that's roughly API-compatible. The discussion is how you
jump the inevitable shark, and perhaps by switching the default and
having a bit of time ahead to deal with issues, is surely better than
facing a large breakage ahead, when there remains an option to switch
back to the current udev if there are problems with eudev. It also gives
Anthony a chance to have a greater user-base to test and evaluate eudev
so that improvements can be made in a timely fashion before
udev-without-systemd becomes unavailable (for whatever set of reasons).

Re: [gentoo-dev] "Lazy" use flags?

[M. J. Everitt]

On 11/02/16 14:32, Kent Fredric wrote:
>> and has no support of per-category files (that I know of).
> # /etc/portage/package.use/dev-qt
> dev-qt/*  qt3support
>
> ^ Legal, works
>
>
Portage does, auto-unmask has a very inconsistent, unstable way of
working with a package.use folder not file ...

Re: [gentoo-dev] "Lazy" use flags?

[M. J. Everitt]

On 11/02/16 14:46, Kent Fredric wrote:
> On 12 February 2016 at 03:43, M. J. Everitt <m.j.ever...@iee.org> wrote:
>> auto-unmask has a very inconsistent, unstable way of
>> working with a package.use folder not file ...
>
> auto-unmask consistently adds items to the file with the highest
> dictionary sort.
>
> So if you name all the files with numerical prefixes, 00 .. 99, "99"
> is where auto-unmask will write to.
>
Well, that's obvious 

Re: [gentoo-dev] "Lazy" use flags?

[M. J. Everitt]

On 11/02/16 12:55, Rich Freeman wrote:
> On Wed, Feb 10, 2016 at 11:57 PM, Kent Fredric  wrote:
>> On 11 February 2016 at 15:51, Rich Freeman  wrote:
>>> In this case you just wouldn't enable python 2.7 support, but you
>>> wouldn't disable it either.  Portage would just pull it in where it is
>>> needed.
>> But you still need a mechanism in place if you *dont* want that to happen.
>> ...
>>> Unless of course you're suggesting "USE=-python_targets_python2_7"
>> would not be "auto-enableable"
> That is correct.
>
>> But then you're *still* requiring a tri-state USE.
> Sure - it would be the same as how package-versions work today.
>
> Stick it in world, and you're pulling it in.
>
> Stick in in mask, and you're keeping it out.
>
> Don't do anything, and portage does what it thinks is best, guided by
> profiles/etc.
>
>> USE="" + IUSE="foo" => "-foo" => autouse enables foo if required
> This is the only thing that would change.  In all the other scenarios
> you described the behavior would be the same as today.  If you set
> USE=-foo then you'll get the same errors you get today.
>
> Now, auto-unmask could still propose sticking USE=+foo in your
> package.use if you have USE=-foo in your make.conf, which is already
> the behavior today.  If you've made any explicit USE setting in your
> configuration, portage would never ignore it, but only suggest that
> you change it.
>
> Perhaps it might make sense to introduce a new ~foo setting which
> undoes a +/-foo in make.conf but doesn't set it either + or - in
> package.use, allowing the setting to revert to the default behavior.
> That would actually be useful independent of lazy use flags, but would
> be more useful with lazy use flags.
>
>> Mentally keeping track of this accounting magic would be complicating 
>> matters.
>>
> I think you're overthinking this.  It is completely analogous as to
> what portage already does with package-versions.  I don't have libjpeg
> in my world file, and yet portage installs it, and I don't think about
> it either way.  If I wanted to pin a specific version of it or mask it
> I could, but of course the preference of most users is to micromanage
> as little as possible.
>
> Basically lazy use flags is intended for users to minimize the size of
> their package.use files, just as they already minimize the size of
> their @world and package.mask files today.
>
I would avoid complicating the USE flag system .. it's straightforward
as it is, and has already been 'tweaked' by the auto-unmask feature,
leading to large package.use files and has no support of per-category
files (that I know of).

I would propose the introduction of a 'LUSE' flag (lazy-use or
lightweight-use) which serves as a fall-back if the main USE system
"fails" - ok this requires duplication of the existing checking system
(and hence integration with portage) but it would allow you to set USE
flags per system at install .. and you could 'tweak' LUSE flags to suit
package implementations instead.

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[M. J. Everitt]

On 09/02/16 23:38, Alex McWhirter wrote:
> On 02/09/2016 05:39 PM, Duncan wrote:
>> I'd agree, except that the way we're running udev is strongly discouraged 
>> and generally not supported by upstream, with a statement that it /will/ 
>> break in the future, it's simply a matter of time. 
>>
>> Which makes a big difference when supporting that same specific use-case 
>> is the primary and arguably only reason the considered alternative exists.
>>
>> IOW, it's not about not liking upstream.  It's about choosing a default 
>> that supports our default use-case.
>>
> My point exactly. When this happens we either make something like eudev
> default or we have to make systemd default. I don't really care which as
> long as i still have the option to change it.
>
+1

Re: [gentoo-dev] [warning] the bug queue has 82 bugs

[M. J. Everitt]

On 06/02/16 22:00, Alex Alexander wrote:
> Our bug queue has 82 bugs!
>
> If you have some spare time, please help assign/sort a few bugs.
>
> To view the bug queue, click here: http://bit.ly/m8PQS5
>
> Thanks!
>
Only 82? that's not, like, 4k ... :) http://tinyurl.com/maintainer-wanted .

Re: [gentoo-dev] Packages Up For Grabs

[M. J. Everitt]

On 24/01/16 10:39, Amadeusz Żołnowski wrote:
> Alex Brandt  writes:
>> * app-backup/rdiff-backup
> Wasn't it meant for removal?
>
> -- Amadeusz Żołnowski
Looks fine on p.g.o  stable too. Upstream site is present.