Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 19:22:32 -0500 William Hubbs wrote: > We could probably also turn gcc-config into an eselect module if we > want to use that argument. Someone did, but unfortunately gcc-config is a big pile of poorly understood voodoo, so eclectic gcc ended up being abandoned. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 19:22:32 -0500 William Hubbs wrote: > > For the same reason we have all the other eselect modules. > > We could probably also turn gcc-config into an eselect module if we > want to use that argument. Looking at Duncan's reply, that has already happened in the past. Really, think about it, why do we have all those eselect modules at all? Why be inconsistent and not introduce one here? Why keep them around? Well, the answer is simple: Remember that eselect init is optional and an opt-in by emerging it, this is in no way suggested anywhere to become a default on all systems. If you don't want it, fine, but that doesn't stop us from pursuing it... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
Tom Wijsman wrote: > For the same reason we have all the other eselect modules. > http://www.gentoo.org/proj/en/eselect/ Ironically, that project description even mentions init system... :) As someone else pointed out, not the same thing. Quoting: William Hubbs wrote: > Yes, but the init system module that project refers to is already there. > Check out eselect rc. It has nothing to do with switching init systems. > It appears to be a wrapper around rc-update and a couple of other things > to manage init scripts and runlevels. > > Thanks, > > William > In case you missed the post, thought I would provide it to clear up the matter. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 22:52:58 -0400 "Walter Dnes" wrote: > If users can already do it themselves, then why this entire thread? > Why do we need eselect/whatever? The big argument in favour of eselect is that when the procedure for switching things changes, there's no need to worry about users doing the old thing. (That, and if eselect doesn't have it, there will be something far worse showing up on the forums anyway...) -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On 05/29/2013 10:55 PM, William Hubbs wrote: > On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote: >>> There are a couple of other possible approaches... >>> >>> 1) If the 2 systems can achieve peacefull co-existance (i.e. no >>> identically-named files with different contents) then simply have 2 >>> boot entries in /etc/lilo.conf (or grub equivalant)... >>> >>> [SNIP to shorten mail] >> >> Users can already do this, this isn't a solution. >> >> We want to make this easier towards the user, therefore doing heavy >> discussion to exhaust all the alternatives and maybe someone's >> interested in implementing one of them that appears most feasible. > > Since users can already do this, why are we bothering with re-inventing > the wheel? How does running an eselect init command make it easier for > the user than telling them to edit their boot loader config file? Because to me and many other EFI users is quite annoying having to rebuild the kernel or do something ugly such as editing a binary file. Because it isn't just editing a file or rebuilding the kernel but also have a short trip in single mode to switch back and forth inittab. Because addons such as bootchart2 or e4rat would be much simpler to use through eselect init than doing the whole bootloader or kernel-rebuild dance. > Gentoo users are expected to build their kernel and write their boot > loader config file initially, so why are we trying to dumb this down? Because usually we aren't linux from scratch and we try to automate as much as we could, leaving the options there to be selected =) lu
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 22:52:58 -0400 "Walter Dnes" wrote: > > > In order for a different init system to come up, some file(s) > > > somewhere *MUST* be different, no ifs/ands/ors/buts. > > > > How true is this in general? It is usually only a change of the init > > parameter. > > Where is the init parameter changed? Wherever it needs to be changed. > [... SNIP] byte-identical hard drives [SNIP ...] You either change it at boot time or on the hard drive. > > > The problem with an eselect approach is that it's like asking a > > > brain surgeon to operate on himself. > > > > eselect and wrappers don't operate on themselves, please elaborate. > > The operating system is changing itself. The world is changing itself. > > > [SNIP to shorten mail] > > > > Users can already do this, this isn't a solution. > > If users can already do it themselves, then why this entire thread? > Why do we need eselect/whatever? For the same reason we have all the other eselect modules. http://www.gentoo.org/proj/en/eselect/ Ironically, that project description even mentions init system... :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote > "Walter Dnes" wrote: > > > In order for a different init system to come up, some file(s) > > somewhere *MUST* be different, no ifs/ands/ors/buts. > > How true is this in general? It is usually only a change of the init > parameter. Where is the init parameter changed? Even if it's only the "append" line in /etc/lilo.conf, my above statement still holds true. If you've got two identical machines with byte-identical hard drives, they can not boot two different OS's or init systems. > > The problem with an eselect approach is that it's like asking a brain > > surgeon to operate on himself. > > eselect and wrappers don't operate on themselves, please elaborate. The operating system is changing itself. > > [SNIP to shorten mail] > > Users can already do this, this isn't a solution. > > [SNIP to shorten mail] > > Again: Users can already do this, this isn't a solution. See above... If users can already do it themselves, then why this entire thread? Why do we need eselect/whatever? -- Walter Dnes I don't run "desktop environments"; I run useful applications
[gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
William Hubbs posted on Wed, 29 May 2013 19:22:32 -0500 as excerpted: > We could probably also turn gcc-config into an eselect module if we want > to use that argument. IIRC it actually was, at one point. The eselect gcc module even allowed separate configs for 32-bit and 64-bit on at least amd64/multilib. However, the gentoo dev, Jeremy Huddleston IIRC (tho I used to get him and another dev with I believe the same initials mixed up, so I might have gotten the wrong one), that developed and maintained the package moved on (IIRC to Apple... looks like he's still there if I'm googling the same one?), and nobody cared to take it up so it rotted until it was masked and I guess eventually removed. Since then I guess nobody's dared (or simply didn't have the prioritized time if they dared) mess with the existing gcc-config enough to try to turn it into an eselect module again. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Thu, May 30, 2013 at 02:06:42AM +0200, Tom Wijsman wrote: > On Wed, 29 May 2013 15:55:23 -0500 > William Hubbs wrote: > > > > We want to make this easier towards the user, therefore doing heavy > > > discussion to exhaust all the alternatives and maybe someone's > > > interested in implementing one of them that appears most feasible. > > > > Since users can already do this, why are we bothering with > > re-inventing the wheel? How does running an eselect init command make > > it easier for the user than telling them to edit their boot loader > > config file? > > > > Gentoo users are expected to build their kernel and write their boot > > loader config file initially, so why are we trying to dumb this down? > > For the same reason we have all the other eselect modules. We could probably also turn gcc-config into an eselect module if we want to use that argument. > http://www.gentoo.org/proj/en/eselect/ > > Ironically, that project description even mentions init system... :) Yes, but the init system module that project refers to is already there. Check out eselect rc. It has nothing to do with switching init systems. It appears to be a wrapper around rc-update and a couple of other things to manage init scripts and runlevels. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 15:55:23 -0500 William Hubbs wrote: > > We want to make this easier towards the user, therefore doing heavy > > discussion to exhaust all the alternatives and maybe someone's > > interested in implementing one of them that appears most feasible. > > Since users can already do this, why are we bothering with > re-inventing the wheel? How does running an eselect init command make > it easier for the user than telling them to edit their boot loader > config file? > > Gentoo users are expected to build their kernel and write their boot > loader config file initially, so why are we trying to dumb this down? For the same reason we have all the other eselect modules. http://www.gentoo.org/proj/en/eselect/ Ironically, that project description even mentions init system... :) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Suggested packages option in portage
El mié, 29-05-2013 a las 11:46 -0400, Ian Stakenvicius escribió:
> On 29/05/13 11:43 AM, Vadim A. Misbakh-Soloviov wrote:
> > I think, it'll be nice to have a way to suggest some packages to
> > user, when (s)he installs something. For now it is only way to do
> > that by something like:
> >
> > pkg_postinst() { if ! has_version dev-lua/iluajit; then einfo
> > "You'd probably want to install dev-lua/iluajit to"; ewarn "get
> > fully functional interactive shell for LuaJIT"; fi if has_version
> > app-editors/emacs || has_version app-editors/xemacs; then einfo
> > "You'd probably want to install app-emacs/lua-mode to"; ewarn "get
> > Lua completion in emacs."; fi }
> >
> > but some people find that way annoying and some devs also thinks it
> > is bad way. Another way (use USEflags-related PDEPs — is a bad way
> > too).
> >
> > Any thoughts? :)
> >
>
>
> There are many thoughts, iirc there was at least one 100+ long thread
> in august/september 2012. Search for "SDEPEND" and "IUSE_RUNTIME" in
> the mailing list logs.
>
Also:
https://bugs.gentoo.org/show_bug.cgi?id=373323
https://bugs.gentoo.org/show_bug.cgi?id=453618
But I cannot remember what was finally blocking them (specially solution
pointed in second bug report)
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote: > > There are a couple of other possible approaches... > > > > 1) If the 2 systems can achieve peacefull co-existance (i.e. no > > identically-named files with different contents) then simply have 2 > > boot entries in /etc/lilo.conf (or grub equivalant)... > > > > [SNIP to shorten mail] > > Users can already do this, this isn't a solution. > > We want to make this easier towards the user, therefore doing heavy > discussion to exhaust all the alternatives and maybe someone's > interested in implementing one of them that appears most feasible. Since users can already do this, why are we bothering with re-inventing the wheel? How does running an eselect init command make it easier for the user than telling them to edit their boot loader config file? Gentoo users are expected to build their kernel and write their boot loader config file initially, so why are we trying to dumb this down? William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 14:15:54 -0400 "Walter Dnes" wrote: > In order for a different init system to come up, some file(s) > somewhere *MUST* be different, no ifs/ands/ors/buts. How true is this in general? It is usually only a change of the init parameter. As far as I heard there is only one exception, /etc/inittab being different between just two init systems; if you know more exceptions, feel free to list them. So, please prove your statement. > The problem with an eselect approach is that it's like asking a brain > surgeon to operate on himself. eselect and wrappers don't operate on themselves, please elaborate. > The proper procedure is to have another brain surgeon operate on him > while the patient is under anesthesia. Actually no, we're going a step further. The eselect doesn't touch the wrapper, but only its config; it's like actually changing brain memory. > There are a couple of other possible approaches... > > 1) If the 2 systems can achieve peacefull co-existance (i.e. no > identically-named files with different contents) then simply have 2 > boot entries in /etc/lilo.conf (or grub equivalant)... > > [SNIP to shorten mail] Users can already do this, this isn't a solution. We want to make this easier towards the user, therefore doing heavy discussion to exhaust all the alternatives and maybe someone's interested in implementing one of them that appears most feasible. > > Having an initr* as a requirement for being able to switch init > > system is maybe a bit too much to ask; same as above, iff nothing > > else ... > > 2) We already have such a solution; it's called the Gentoo minimal > install ISO. I agree, I have mine always available; yet some people are consistent in coming up with solutions for when all hell breaks lose. > If the 2 init systems conflict over identically-named > files, I strongly recommend that the changes be done while booted > from a gentoo minimal install ISO. > > [SNIP to shorten mail] Again: Users can already do this, this isn't a solution. See above... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, May 29, 2013 at 10:52:49AM +0200, Tom Wijsman wrote > On Wed, 29 May 2013 00:36:58 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: > > > 3b) Except... at that point root isn't writable > > Let me stop you here. Does it need to be writable at that point? > > We're reading the path of the init file to boot from a file, we start > the executable at that path; no writes are involved here. > > The only problem left here is that some init systems need a specific > version of the inittab file, although this can likely be changed in > late shutdown as the only exception to this approach. In order for a different init system to come up, some file(s) somewhere *MUST* be different, no ifs/ands/ors/buts. The problem with an eselect approach is that it's like asking a brain surgeon to operate on himself. The proper procedure is to have another brain surgeon operate on him while the patient is under anesthesia. > It sounds very feasible for init systems that are an exception to just > being able to switch init alone or have conflicting files to fix up > whatever is inconsistent; either by scheduling changes till when the > disk is writable, or by doing it on shutdown... > > > But it occurred to me that we actually do have a demonstrated > > workable and long used in actual practice exception to the normal > > boot case as precedent, where such maintenance tasks traditionally > > occur, single user mode. > > Iff nothing else is feasible enough, this makes a lot of sense to me. There are a couple of other possible approaches... 1) If the 2 systems can achieve peacefull co-existance (i.e. no identically-named files with different contents) then simply have 2 boot entries in /etc/lilo.conf (or grub equivalant)... append = "init=/etc/foo" append = "init=/etc/bar" ...and select whichever one you want from the boot menu. This guarantees a) the system shuts down properly with the old init b) the system starts up properly with the new init c) if the new files are incorrect/unbootable, you can simply reboot to the old version and try to figure out what went wrong > > [initr* SNIP] > > Having an initr* as a requirement for being able to switch init system > is maybe a bit too much to ask; same as above, iff nothing else ... 2) We already have such a solution; it's called the Gentoo minimal install ISO. If the 2 init systems conflict over identically-named files, I strongly recommend that the changes be done while booted from a gentoo minimal install ISO. This guarantees a) the system shuts down properly with the old init b) the system starts up properly with the new init c) if the new files are incorrect/unbootable, you can simply chroot into the machine and send pleas for help to the Gentoo user mailing list ;) -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] [RFC] Suggested packages option in portage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29/05/13 11:43 AM, Vadim A. Misbakh-Soloviov wrote:
> I think, it'll be nice to have a way to suggest some packages to
> user, when (s)he installs something. For now it is only way to do
> that by something like:
>
> pkg_postinst() { if ! has_version dev-lua/iluajit; then einfo
> "You'd probably want to install dev-lua/iluajit to"; ewarn "get
> fully functional interactive shell for LuaJIT"; fi if has_version
> app-editors/emacs || has_version app-editors/xemacs; then einfo
> "You'd probably want to install app-emacs/lua-mode to"; ewarn "get
> Lua completion in emacs."; fi }
>
> but some people find that way annoying and some devs also thinks it
> is bad way. Another way (use USEflags-related PDEPs — is a bad way
> too).
>
> Any thoughts? :)
>
There are many thoughts, iirc there was at least one 100+ long thread
in august/september 2012. Search for "SDEPEND" and "IUSE_RUNTIME" in
the mailing list logs.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iF4EAREIAAYFAlGmIs0ACgkQ2ugaI38ACPCzcQD/bANxbOhGaxwNhdXJ7Nxhw3Ld
yZr96dhlKwfp6I1D2pIA+gPO0eYRGo4FDkbMQ1z72lawQgufTKbXpHwobjCTUVlb
=c6wc
-END PGP SIGNATURE-
[gentoo-dev] [RFC] Suggested packages option in portage
I think, it'll be nice to have a way to suggest some packages to user,
when (s)he installs something. For now it is only way to do that by
something like:
pkg_postinst() {
if ! has_version dev-lua/iluajit; then
einfo "You'd probably want to install dev-lua/iluajit to";
ewarn "get fully functional interactive shell for LuaJIT";
fi
if has_version app-editors/emacs || has_version
app-editors/xemacs; then
einfo "You'd probably want to install app-emacs/lua-mode
to";
ewarn "get Lua completion in emacs.";
fi
}
but some people find that way annoying and some devs also thinks it is
bad way.
Another way (use USEflags-related PDEPs — is a bad way too).
Any thoughts? :)
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE
On 30/05/2013 01:06, hasufell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/2013 04:51 PM, Michael Palimaka wrote: Would it be possible to add repoman checks for this, and other common failures like missing PYTHON_USEDEP? The latter is impossible. Repoman has no way to figure out if PYTHON_USEDEP is necessary. You have to keep in mind that PYTHON_USEDEP does _not_ apply to every python dependency. If your application just runs a python script of another application, then it might not care under which implementation that is executed. If it's about importing modules, then we always need PYTHON_USEDEP. But how should repoman know? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRphl3AAoJEFpvPKfnPDWzKvkIAK9KTyK6bAjLMz7xD2xaC5lD QJptr5mEWH3MR+rTyyTSF0YJdPpDR0R3lJDDmUUqqE+xlCSO1kKaEYdJ1bNzQ/Kv fMxJEi99UA90Znn+G0gIzBOuqECOk9KZkuhkgCqZAatGgIJ6dc7sboVS7c8pZo8x vwbSvhKw8iJEY26HENspZQSmWupsYy++JG6iERU0GBnpSRDxvTbquanZ6zdo/og7 GbbDYbGA8OVICNBwhpIgDeStxRtpBaLw9c6BDtN+6FXf33s/hR2nAPpwX/3kLHrD thb+/Xf17G8Ao8JJdNns0gAA5ivzDZvETgQTvh8QH4wFzrlDH4MVcoeuLdhhlUU= =EwlO -END PGP SIGNATURE- Sorry, I meant to write PYTHON_DEPS.
Re: [gentoo-dev] Re: PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/2013 04:51 PM, Michael Palimaka wrote: > Would it be possible to add repoman checks for this, and other > common failures like missing PYTHON_USEDEP? > > The latter is impossible. Repoman has no way to figure out if PYTHON_USEDEP is necessary. You have to keep in mind that PYTHON_USEDEP does _not_ apply to every python dependency. If your application just runs a python script of another application, then it might not care under which implementation that is executed. If it's about importing modules, then we always need PYTHON_USEDEP. But how should repoman know? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRphl3AAoJEFpvPKfnPDWzKvkIAK9KTyK6bAjLMz7xD2xaC5lD QJptr5mEWH3MR+rTyyTSF0YJdPpDR0R3lJDDmUUqqE+xlCSO1kKaEYdJ1bNzQ/Kv fMxJEi99UA90Znn+G0gIzBOuqECOk9KZkuhkgCqZAatGgIJ6dc7sboVS7c8pZo8x vwbSvhKw8iJEY26HENspZQSmWupsYy++JG6iERU0GBnpSRDxvTbquanZ6zdo/og7 GbbDYbGA8OVICNBwhpIgDeStxRtpBaLw9c6BDtN+6FXf33s/hR2nAPpwX/3kLHrD thb+/Xf17G8Ao8JJdNns0gAA5ivzDZvETgQTvh8QH4wFzrlDH4MVcoeuLdhhlUU= =EwlO -END PGP SIGNATURE-
[gentoo-dev] Re: PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE
On 28/05/2013 01:35, Jonathan Callen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
A quick reminder for anyone using python-r1.eclass or
python-single-r1.eclass:
These eclasses provide a ${PYTHON_REQUIRED_USE} variable that should
be included in REQUIRED_USE under the same USE conditionals (if any)
that ${PYTHON_DEPS} is included in DEPEND/RDEPEND.
For example, if your ebuild has:
RDEPEND="
python? ( ${PYTHON_DEPS}
"
then you should also have:
REQUIRED_USE="
python? ( ${PYTHON_REQUIRED_USE} )
"
And if your ebuild just has:
RDEPEND="${PYTHON_DEPS}"
then you should also have:
REQUIRED_USE="${PYTHON_REQUIRED_USE}"
Failure to include these in REQUIRED_USE may cause the eclass to die
very late in the build process.
Thank you,
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJRo309AAoJELHSF2kinlg4dVcP/2t3v1t8CId8jK/c4VG8HLWL
zTEvTI3d8wQILuHydI9VkOZllo3dPWhhUhg/1qJjwEXXnKQXiYNUiVzbtwdkGro/
OlkCrrpDstHgawHiovIZjgyEG9Y+Nz2Z5nKorZIAMFSFepaFsIkihVR3VkeHiG9Q
7XOOVaH8mqGuj7JWZNqikCmB11a6t08jVM68tzwtTZUuil1IRE2qjO5akMPczsvk
3ndoMsv5hQwUE4wmmTH4ffiz+wp/JUylK2Ypy6p/UWlMw+oq8IusyvQdKztF2rU4
SyjnEOHcPtbLXMA24NHSAUov5L3xVcSu4he5A+QnY0Ghn0dZ7Wbk72aRZQP+MOk+
e18tdPRaXE35ux8s0ogLeuD04lju6z5/esJbP8LF8H6loiKCURxVOfYEhUugIMIc
ihb6h4o4cflz2tYV6USOHxUQ6pA78X7ftXGJhOOR1sf1/2GZcg7ZQvD0WqjNLbAo
U52yQl3/bKMVpezYLhkLxgzmRAdwbBdBFdiav8dX+QNYabLPG/0y6mkqK0pc59sS
Lsse/dXCPrxfI6MVbsSQAaFt4s/YNrf9NLabdPHShRlWX8pRc16feQFb7FoTCmWe
BzwBwG63Mvw2OOS0GrXIfXdFs9klbezoZ8Ql8Zb3CIZPWaBPAOYfCqZDHkDDAyQL
UYQyPJdIntHmxKbtMQr9
=frSU
-END PGP SIGNATURE-
Would it be possible to add repoman checks for this, and other common
failures like missing PYTHON_USEDEP?
[gentoo-dev] Re: Review Board for Gentoo
On 29/05/2013 21:18, Alexey Shvetsov wrote: Yep I'm thinking about gerrit like workflow. But seems it doesnt make sense with RB and CVS. Yes, Review Board and Gerrit target different things.
Re: [gentoo-dev] Re: Review Board for Gentoo
Yep I'm thinking about gerrit like workflow. But seems it doesnt make sense with RB and CVS. В письме от 29 мая 2013 10:22:29 пользователь Tomáš Chvátal написал: > He is probably thinking about buildtests and automatic commit merges which > are not possible with reviewboard. > > Dne 29.5.2013 9:09 "Michael Palimaka" napsal(a): > > On 29/05/2013 02:07, Alexey Shvetsov wrote: > >> Hi! > >> > >> Cool! I didnt use RB before, but i use gerrit. Do you pan to integrate it > >> to > >> g.o.g.o? It seems can be done by git commit hooks > > > > What sort of integration did you have in mind? -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, NRC Kurchatov Institute, Gatchina, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/20/2013 08:29 PM, Tom Wijsman wrote: > We have `iamlate` for this in app-portage/gentoolkit-dev. /usr/bin/imlate , nice ;-) - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlGlyLAACgkQknrdDGLu8JDJ3QEAhYrgzLHT5NCINaXBVYCNs1PH 12+nHNMy9V+6BQ4EMi8A/RLvadt7RndQPk8m5BuDlzRuwaO05WNVfkArMOxovd1v =7eoE -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init
On Wed, 29 May 2013 00:36:58 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > 3b) Except... at that point root isn't writable Let me stop you here. Does it need to be writable at that point? We're reading the path of the init file to boot from a file, we start the executable at that path; no writes are involved here. The only problem left here is that some init systems need a specific version of the inittab file, although this can likely be changed in late shutdown as the only exception to this approach. It sounds very feasible for init systems that are an exception to just being able to switch init alone or have conflicting files to fix up whatever is inconsistent; either by scheduling changes till when the disk is writable, or by doing it on shutdown... > But it occurred to me that we actually do have a demonstrated > workable and long used in actual practice exception to the normal > boot case as precedent, where such maintenance tasks traditionally > occur, single user mode. Iff nothing else is feasible enough, this makes a lot of sense to me. > [initr* SNIP] Having an initr* as a requirement for being able to switch init system is maybe a bit too much to ask; same as above, iff nothing else ... > 4) Finally, the fact that each init-system package gets to control > its own switcher-mode script keeps control of it with the init-system > package maintainers, allowing them to choose as complex or simple a > script as they need/wish, reasonably addressing the whole maintainer > control problem so evident in another current thread. We should avoid maintenance burden where we can; we can't also force things upon them, as you can see in other ML threads here. Init systems are quite necessary in Gentoo, let's not risk losing their maintainers. That being said; if there are exceptions to the approach we end up taking, we need to put these somewhere. It kind of depends on how we will integrate the init system approach in the Portage tree. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Review Board for Gentoo
He is probably thinking about buildtests and automatic commit merges which are not possible with reviewboard. Dne 29.5.2013 9:09 "Michael Palimaka" napsal(a): > On 29/05/2013 02:07, Alexey Shvetsov wrote: > >> Hi! >> >> Cool! I didnt use RB before, but i use gerrit. Do you pan to integrate it >> to >> g.o.g.o? It seems can be done by git commit hooks >> > > What sort of integration did you have in mind? > > > >
[gentoo-dev] Re: Review Board for Gentoo
On 29/05/2013 02:07, Alexey Shvetsov wrote: Hi! Cool! I didnt use RB before, but i use gerrit. Do you pan to integrate it to g.o.g.o? It seems can be done by git commit hooks What sort of integration did you have in mind?
