Re: [gentoo-dev] amd64 and x32 systemd stages should be ready
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
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/
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
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
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
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
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?
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?
> 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?
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
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
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
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
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
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
