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

[Nathan Zachary]

On 09/05/16 19:12, M. J. Everitt wrote:
> 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 ?
>
+1.  Arch would probably be the best choice for a systemd-based rescue disc.

Cheers,
Nathan Zachary

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] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Doug Goldstein]

On 5/7/16 4:25 PM, Michał Górny wrote:
> On Sat,  7 May 2016 21:19:31 + (UTC)
> "Joerg Bornkessel"  wrote:
> 
>> commit: 66afcab271f65b97330e610040ad3acc1b812a03
>> Author: Joerg Bornkessel  gentoo  org>
>> AuthorDate: Sat May  7 21:18:48 2016 +
>> Commit: Joerg Bornkessel  gentoo  org>
>> CommitDate: Sat May  7 21:18:48 2016 +
>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66afcab2
>>
>> fixed einstall vs. emake install for eapi=6
>>
>>  eclass/vdr-plugin-2.eclass | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/eclass/vdr-plugin-2.eclass b/eclass/vdr-plugin-2.eclass
>> index ae09a34..65f1409 100644
>> --- a/eclass/vdr-plugin-2.eclass
>> +++ b/eclass/vdr-plugin-2.eclass
>> @@ -571,7 +571,11 @@ vdr-plugin-2_src_install() {
>>  local SOFILE_STRING=$(grep SOFILE Makefile)
>>  if [[ -n ${SOFILE_STRING} ]]; then
>>  BUILD_TARGETS=${BUILD_TARGETS:-${VDRPLUGIN_MAKE_TARGET:-install 
>> }}
>> -einstall ${BUILD_PARAMS} \
>> +if [[ ${EAPI} == 6 ]]; then
>> +emake install ${BUILD_PARAMS} \
>> +else
>> +einstall ${BUILD_PARAMS} \
>> +fi
>>  ${BUILD_TARGETS} \
>>  TMPDIR="${T}" \
>>  DESTDIR="${D}" \
>>
> 
> Do you seriously expect this code to work? How about testing? Or
> reading diffs before committing?
> 

Michal,

How about trying a different tone?

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature

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

[Rich Freeman]

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...


-- 
Rich

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

[Anthony G. Basile]

On 5/9/16 4:20 PM, M. J. Everitt wrote:
> 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.
> 

oh okay.  sorry if i misunderstood.  nonetheless, doesn't the fedora
installation cd double as a rescue cd?  i think that uses systemd.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

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] amd64 and x32 systemd stages should be ready

[Anthony G. Basile]

On 5/9/16 8:43 AM, Rich Freeman wrote:
> On Mon, May 9, 2016 at 1:21 AM, Matthew Marchese  
> wrote:
>> Looks good. Nice work, fellas.
> 
> ++
> 
>>
>> I'll do some testing of my own on those stage tarballs so that I can write
>> some docs, unless you'd like to write them, blueness. This should ease the
>> path on the systemd "Handbook extension" idea I've been throwing around.
>>
> 
> While there is no question that having systemd stage3s is a major
> improvement, it actually is likely to make the handbook more
> complicated.
> 

i don't like writing docs because when i do, i go all out and then get
criticized for doing too good a job :P

> 
> 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.

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

Re: [gentoo-dev] What is the procedure for requesting a new eselect module?

[waltdnes]

On Mon, May 09, 2016 at 04:17:06PM +0200, Ulrich Mueller wrote
> > On Mon, 9 May 2016, waltdnes  wrote:
> 
> >   I've cobbled together a bash script that resembles an eselect
> > module, to list/set cpu speeds on my netbook and notebook. It may be
> > useful to a lot of other people. The script is a bit ugly looking,
> > but it has done the job for me for several months. Some may prefer
> > to treat it as "proof of concept" and do a re-write in python or C
> > or whatever. Given its function, it seems logical to make it an
> > eselect module. Anyhow, what is the procedure to follow up this
> > idea?
> 
> We have a developer guide:
> https://wiki.gentoo.org/wiki/Project:Eselect/Developer_guide

  Thanks for the pointer.  I see that modules are stored in directory
/usr/share/eselect/modules/ with a ".eselect" extension.  Nice to have
a bunch of working examples.  I'll modify my script to module format.

  Should I email you offline when I'm finished?  One
cpu-governor-related question, is there any real difference between...

"powersave" governor versus
"userspace" mode with the lowest speed selected?

  Similarly is there any real difference between...

"performance" governor versus
"userspace" mode with the highest speed selected?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] What is the procedure for requesting a new eselect module?

[Ulrich Mueller]

> On Mon, 9 May 2016, waltdnes  wrote:

>   I've cobbled together a bash script that resembles an eselect
> module, to list/set cpu speeds on my netbook and notebook. It may be
> useful to a lot of other people. The script is a bit ugly looking,
> but it has done the job for me for several months. Some may prefer
> to treat it as "proof of concept" and do a re-write in python or C
> or whatever. Given its function, it seems logical to make it an
> eselect module. Anyhow, what is the procedure to follow up this
> idea?

We have a developer guide:
https://wiki.gentoo.org/wiki/Project:Eselect/Developer_guide

Ulrich


pgptzXEOU9wA7.pgp
Description: PGP signature

[gentoo-dev] What is the procedure for requesting a new eselect module?

[waltdnes]

  I've cobbled together a bash script that resembles an eselect module,
to list/set cpu speeds on my netbook and notebook.  It may be useful to
a lot of other people.  The script is a bit ugly looking, but it has
done the job for me for several months.  Some may prefer to treat it as
"proof of concept" and do a re-write in python or C or whatever.  Given
its function, it seems logical to make it an eselect module.  Anyhow,
what is the procedure to follow up this idea?

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] On banning merge commits

[Rich Freeman]

On Mon, May 9, 2016 at 8:36 AM, Kent Fredric  wrote:
>
> While you can in theory rebase merge commits with rebase --preserve,
> my experience has shown me that its very difficult to get right, and
> the presence of merge collisions in the "preserved" rebase risks
> getting the conflict resolution lost mid-rebase, which is not entirely
> helpful.
>
> If there was something we could feasibly put hard software policy
> constraints against without any subjective "but but but" cases, it
> would be these cases of "merge included conflicts".
>

Is there any way to tell git to rebase everything but the conflicts
themselves, and then resolve those in the merge commit?  That might be
the cleanest solution as it filters out all the noise, and then has a
merge commit which clearly shows how the conflict was resolved.

Now, for non-trivial conflicts I think it is better to rebase or merge
into the branch, test, and then do a non-conflicting merge back into
the main tree.  How else will you know that you resolved the conflict
correctly?  By non-trivial I mean stuff other than keywords and
descriptions and such.

-- 
Rich

Re: [gentoo-dev] On banning merge commits

[Kent Fredric]

On 10 May 2016 at 00:23, Rich Freeman  wrote:
> which introduces some of the uncleanliness of non-rebased
> merge commits.  In general I'm a fan of rebasing merge commits.


Non-rebased merge commits are worst when the merge involves  a
collision resolution.

While you can in theory rebase merge commits with rebase --preserve,
my experience has shown me that its very difficult to get right, and
the presence of merge collisions in the "preserved" rebase risks
getting the conflict resolution lost mid-rebase, which is not entirely
helpful.

If there was something we could feasibly put hard software policy
constraints against without any subjective "but but but" cases, it
would be these cases of "merge included conflicts".

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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

[Rich Freeman]

On Mon, May 9, 2016 at 1:21 AM, Matthew Marchese  wrote:
> Looks good. Nice work, fellas.

++

>
> I'll do some testing of my own on those stage tarballs so that I can write
> some docs, unless you'd like to write them, blueness. This should ease the
> path on the systemd "Handbook extension" idea I've been throwing around.
>

While there is no question that having systemd stage3s is a major
improvement, it actually is likely to make the handbook more
complicated.

I've been too lazy to make the changes, but in my testing it is
actually very simple to use the openrc handbook to install systemd.
You just pick a systemd profile, configure the entire system using
openrc per the handbook, and then emerge -u @world.  That will install
systemd and the Gentoo systemd ebuilds port-over the openrc
configuration.

If you start out with systemd then you need to use the systemd
configuration tools.  So, instead of using the existing procedure for
eselect locale or setting the timezone you're going to use localectl
and timedatectl.  That means a lot more openrc and systemd-specific
steps in the guide.  Likewise, if you have a systemd-based install CD
then you're going to want to use nspawn to mount the "chroot."  I
don't know if there is a good systemd-based rescue CD out there
though, and ironically having systemd on the installer makes the most
sense for both systemd and openrc installations simply because nspawn
is so handy.  Also, if you don't boot into systemd then you'll either
need to do the configuration after rebooting, or you'll need to follow
the steps to get dbus/etc running so that the systemd configuration
tools work.

The overall workflow will be identical.  You just need to change the
commands at many of the steps, unless they're all turned into eselect
modules that are smart enough to call the right tool.

Is there actually a decent systemd-based rescue CD out there?

-- 
Rich

Re: [gentoo-dev] On banning merge commits

[Rich Freeman]

On Mon, May 9, 2016 at 7:27 AM, Kristian Fiskerstrand  wrote:
> On 05/08/2016 07:07 PM, Kent Fredric wrote:
>> On 9 May 2016 at 05:03, Alexis Ballier  wrote:
>>> I was under the impression that merging is needed in order to preserve
>>> commit signatures when e.g. merging someone else's work.
>>
>>
>> Correct, but if the person applying the commits to tree is in fact
>> reviewing them as they go, then the fact they re-sign it with their
>> own signature
>> ( and changing the commits "Committed by" in the process ) pretty much
>> means the chain of custody is preserved.
>
> And it is a requirement in particular in the case where the author is
> not a gentoo dev as the certificate used for the signature otherwise
> isn't recognized. The committing developer will need to have a local
> framework in place for certificate validation to ensure that the author
> is authentic, after that the committing author is responsible for all
> behavior of the commit.
>

Keep in mind that you can have both.  You can both preserve the
original commit with its signature, and introduce it as a merge commit
with a Gentoo signature.

I'm not saying we necessarily should do this, but certainly git makes
this possible, and it is a potential benefit of merge commits.

However, in this case it would not be possible to rebase the original
commit, which introduces some of the uncleanliness of non-rebased
merge commits.  In general I'm a fan of rebasing merge commits.

-- 
Rich

Re: [gentoo-dev] On banning merge commits

[Kristian Fiskerstrand]

On 05/08/2016 07:07 PM, Kent Fredric wrote:
> On 9 May 2016 at 05:03, Alexis Ballier  wrote:
>> I was under the impression that merging is needed in order to preserve
>> commit signatures when e.g. merging someone else's work.
> 
> 
> Correct, but if the person applying the commits to tree is in fact
> reviewing them as they go, then the fact they re-sign it with their
> own signature
> ( and changing the commits "Committed by" in the process ) pretty much
> means the chain of custody is preserved.

And it is a requirement in particular in the case where the author is
not a gentoo dev as the certificate used for the signature otherwise
isn't recognized. The committing developer will need to have a local
framework in place for certificate validation to ensure that the author
is authentic, after that the committing author is responsible for all
behavior of the commit.

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



signature.asc
Description: OpenPGP digital signature