Re: [gentoo-dev] Re: Re: eselect init
El lun, 03-06-2013 a las 00:35 +0200, Luca Barbato escribió: [...] > To not make this a waste of time here a summary of the whole thing: > > - eselect init will be opt-in for the time being, people can be left on > their own tools if the want it > - the default init will stay sysvinit. Discussion ongoing if is better > to have it installed in a secondary fallback path is open (e.g. /bin/init). > - I still need to send patches to busybox and sysvinit upstream to add a > command line switch to locate the inittab. > - people wanting to switch init or enable/disable init addons using > eselect init might have to refer to /sbin/einit or such custom path > (assuming we fail to come to an agreement regarding /bin/init) > > The wrapper in /sbin/init is mostly needed to get to the point of a > clean reboot. > > The first time you boot on a new system it is executed picking the new > init and just that. > > For addons such as bootchart2 and e4rat it would do slightly more. > > Assuming upstream doesn't accept custom paths for the inittab, for my > specific usecase I might bake something that would remount r/w and pivot > the inittabs. > > Anybody willing to do something more extreme could even consider having > /sbin/init as a symlink and have the boot-time configuration switch the > symlink, thus making the whole script run just a single boot per switch. > > Not necessary but surely feasible. > > lu > > Thanks for the summary :)
[gentoo-dev] Re: eselect init
Luca Barbato posted on Mon, 03 Jun 2013 00:35:29 +0200 as excerpted: > To not make this a waste of time here a summary of the whole thing: > > - eselect init will be opt-in for the time being, people can be left on > their own tools if the want it - the default init will stay sysvinit. > Discussion ongoing if is better to have it installed in a secondary > fallback path is open (e.g. /bin/init). > - I still need to send patches to busybox and sysvinit upstream to add a > command line switch to locate the inittab. > - people wanting to switch init or enable/disable init addons using > eselect init might have to refer to /sbin/einit or such custom path > (assuming we fail to come to an agreement regarding /bin/init) > > The wrapper in /sbin/init is mostly needed to get to the point of a > clean reboot. > > The first time you boot on a new system it is executed picking the new > init and just that. > > For addons such as bootchart2 and e4rat it would do slightly more. Thanks for the summary. In the muddle of a contentious thread it's not easy to figure out which points have been settled on and which are still considered under discussion, so a summary by someone suitably involved as to be authoritative can be valuable indeed, even for those who (like me) have read the entire thread. And valuable it was to me here. =:^) The only concern I had with the above is the one Walter D. brought up, that "for the time being" caveat. But rich0 well addressed that, so... I'm good! =:^) Meanwhile, Walter D: Thanks for your work too. I'm not using your bb-init work ATM, but I deeply appreciate having the alternative available, should I find the need for it in the future, and am thus very thankful that /someone/ was suitably motivated to create it. I haven't seen a lot of direct thanks on-list for your work, but I suspect there's others who seriously appreciate it as well, whether we're already using it or may actually never use it but deeply value having the alternative should we have need of it, so let this be a thanks from all of us. It's projects like yours, someone seeing a need and addressing it for themselves, then simply making that work available for use by others, that form the "grassroots" of FLOSS. =:^) -- 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: Re: eselect init
On Sun, Jun 2, 2013 at 8:37 PM, Walter Dnes wrote: > On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote > >> - eselect init will be opt-in ***FOR THE TIME BEING***, people can >> be left on their own tools if the want it > > This statement should bring the same reaction as the posting that udev > source was being rolled into the systemd tarball. It implies that > eselect init will eventually become mandatory. I don't get why it would ever become mandatory, or why people are worried about this. The only packages that tend to touch anything like inittab are the packages that implement init in the first place. I'm not aware of any init packages that would require otherwise. That being the case, there isn't going to be any tight coupling here. If you want a simple config just point your grub/etc to the init implementation of your choice and it is hard-coded. Or, install the fancy switcher script/initramfs/whatever and use it. People get way to panicky every time somebody posts a new idea on -dev. Half of these ideas never get implemented, and 90% of those which are don't become defaults. Heck, the intent was always to make OpenRC the default and it took YEARS for that to happen on stable. When you see two random developers post a crazy idea on -dev, keep in mind that we're a distro that fosters innovation by letting any developer start a project based solely on personal initiative. Generally things don't become defaults until it becomes fairly obvious that this is the appropriate course of action. Rich
[gentoo-dev] Draft news item: preserve-libs default for portage-2.1.12
Please review the attached news item which announces the preserve-libs default for portage-2.1.12. Note that our council has discussed this change in their 2013-05-14 meeting [1], and they were in favor of allowing it. [1] http://thread.gmane.org/gmane.linux.gentoo.project/2448/focus=2452 -- Thanks, Zac Title: Portage preserve-libs default Author: Zac Medico Content-Type: text/plain Posted: 2012-06-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: >=sys-apps/portage-2.1.12 Beginning with sys-apps/portage-2.1.12, FEATURES=preserve-libs is enabled by default. This feature will preserve libraries when the sonames change during upgrade or downgrade. Libraries are preserved only if consumers of those libraries are detected. Preserved libraries are automatically removed when there are no remaining consumers. Run `emerge @preserved-rebuild` in order to rebuild all consumers of preserved libraries. If you would like to disable this behavior by default, then set FEATURES="-preserve-libs" in make.conf. See the make.conf(5) man page for more information about this feature.
Re: [gentoo-dev] Re: Re: eselect init
On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote > - eselect init will be opt-in ***FOR THE TIME BEING***, people can > be left on their own tools if the want it This statement should bring the same reaction as the posting that udev source was being rolled into the systemd tarball. It implies that eselect init will eventually become mandatory. Your situation is a special use-case, i.e. a developer who wants to switch between a "production" init system, and a "test" init system, possibly multiple times a day. You're a developer, you know which files to change, put together your own scripts, and run them as necessary. Set up your own overlay and write your own eselect init ebuild. No problem. But why should this eventually be a part of mainstream Gentoo? BTW, I'm a bigger fan of busybox than most Gentoo users. Remember the announcement of systemd/udev tarball integration, and supposed deprecation of a separate /usr? I was the -disturber who started up the https://wiki.gentoo.org/wiki/Mdev wiki page on how to replace udev with mdev. I also did a page on automounting at... https://wiki.gentoo.org/wiki/Mdev/Automount_USB/automount Having said that, I don't see how busybox development justifies an additional layer of complexity for everybody's bootup. -- Walter Dnes I don't run "desktop environments"; I run useful applications
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-06-02 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-06-02 23h59 UTC. Removals: media-sound/timidity-shompatches2013-05-27 05:32:45 ulm sys-apps/kuroevtd 2013-05-27 05:36:06 ulm app-admin/addpatches2013-05-27 06:12:07 ulm app-text/duconv 2013-05-27 06:14:59 ulm games-emulation/psemu-gpupetexgl2 2013-05-28 23:42:45 mr_bones_ games-emulation/psemu-gpupetemesagl 2013-05-28 23:42:45 mr_bones_ dev-util/jedi 2013-05-30 01:22:21 radhermit www-apache/mod_watch2013-05-30 15:21:10 ulm www-apache/mod_loopback 2013-05-30 15:21:32 ulm www-plugins/diamondx2013-06-01 11:55:38 jer Additions: dev-python/python-tvrage2013-05-27 01:28:30 floppym www-apache/mod_spdy 2013-05-28 00:21:25 vapier net-misc/cbugzilla 2013-05-28 04:24:01 yac www-apps/liquid_feedback_frontend 2013-05-28 12:51:56 tupone kde-misc/homerun2013-05-28 15:57:46 johu sci-libs/deap 2013-05-29 08:42:32 slis dev-libs/qtkeychain 2013-05-29 23:20:33 johu dev-python/jedi 2013-05-30 01:16:11 radhermit gnome-extra/zeitgeist-explorer 2013-05-30 08:40:23 jlec sci-chemistry/xdsgui2013-05-30 09:14:15 jlec sci-chemistry/xdsstat-bin 2013-05-30 09:32:50 jlec mail-client/geary 2013-05-30 13:41:21 hasufell profiles/default/bsd/fbsd/amd64/9.1/clang 2013-05-30 21:26:47 aballier dev-python/django-discover-runner 2013-05-31 02:28:10 floppym dev-python/xvfbwrapper 2013-05-31 04:17:24 floppym dev-python/flake8 2013-05-31 07:29:52 idella4 dev-python/mccabe 2013-05-31 07:53:17 idella4 net-libs/nacl 2013-05-31 07:59:22 xmw dev-python/pbr 2013-05-31 15:05:48 prometheanfire dev-java/bcpkix 2013-06-01 15:09:20 tomwij virtual/python-imaging 2013-06-01 19:24:37 floppym dev-python/defusedxml 2013-06-02 10:44:08 idella4 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: media-sound/timidity-shompatches,removed,ulm,2013-05-27 05:32:45 sys-apps/kuroevtd,removed,ulm,2013-05-27 05:36:06 app-admin/addpatches,removed,ulm,2013-05-27 06:12:07 app-text/duconv,removed,ulm,2013-05-27 06:14:59 games-emulation/psemu-gpupetexgl2,removed,mr_bones_,2013-05-28 23:42:45 games-emulation/psemu-gpupetemesagl,removed,mr_bones_,2013-05-28 23:42:45 dev-util/jedi,removed,radhermit,2013-05-30 01:22:21 www-apache/mod_watch,removed,ulm,2013-05-30 15:21:10 www-apache/mod_loopback,removed,ulm,2013-05-30 15:21:32 www-plugins/diamondx,removed,jer,2013-06-01 11:55:38 Added Packages: dev-python/python-tvrage,added,floppym,2013-05-27 01:28:30 www-apache/mod_spdy,added,vapier,2013-05-28 00:21:25 net-misc/cbugzilla,added,yac,2013-05-28 04:24:01 www-apps/liquid_feedback_frontend,added,tupone,2013-05-28 12:51:56 kde-misc/homerun,added,johu,2013-05-28 15:57:46 sci-libs/deap,added,slis,2013-05-29 08:42:32 dev-libs/qtkeychain,added,johu,2013-05-29 23:20:33 dev-python/jedi,added,radhermit,2013-05-30 01:16:11 gnome-extra/zeitgeist-explorer,added,jlec,2013-05-30 08:40:23 sci-chemistry/xdsgui,added,jlec,2013-05-30 09:14:15 sci-chemistry/xdsstat-bin,added,jlec,2013-05-30 09:32:50 mail-client/geary,added,hasufell,2013-05-30 13:41:21 profiles/default/bsd/fbsd/amd64/9.1/clang,added,aballier,2013-05-30 21:26:47 dev-python/django-discover-runner,added,floppym,2013-05-31 02:28:10 dev-python/xvfbwrapper,added,floppym,2013-05-31 04:17:24 dev-python/flake8,added,idella4,2013-05-31 07:29:52 dev-python/mccabe,added,idella4,2013-05-31 07:53:17 net-libs/nacl,added,xmw,2013-05-31 07:59:22 dev-python/pbr,added,prometheanfire,2013-05-31 15:05:48 dev-java/bcpkix,added,tomwij,2013-06-01 15:09:20 virtual/python-imaging,added,floppym,2013-06-01 19:24:37 dev-python/defusedxml,added,idella4,2013-06-02 10:44:08 Done.
Re: [gentoo-dev] Re: Re: eselect init
On 06/02/2013 08:20 PM, Steven J. Long wrote: > On Sun, Jun 02, 2013 at 11:15:37AM +0200, Luca Barbato wrote: >> On 06/01/2013 11:23 AM, Steven J. Long wrote: >>> That's not an argument for using a symlink switcher or the >>> equivalent across the board, by any means. >> >> Your opinion. > > That's not an argument for it either. Had been explained in the thread, please read it. >>> Firstly, we should be recommending people install Gentoo with enough >>> flexibility to configure and use their system how they choose. In the >>> UEFI arena, why not simply recommend something like rEFIt instead of >>> making everyone go through a load of development effort, to restrict >>> us all to a crippled use-case? >> >> Beside rEFIt being deprecated and rEFInd being in early stage of >> development (thus working great on some platforms and not working at all >> on some other) and with a good chunk of documentation to read before >> being able of deploying it? > > The typical thing Gentoo users get told is "this is a new thing, it will > take some time to work out, bear with us" as their production servers go > tits-up around them. So in this case too, work with upstream to implement > better solutions you, and the wider ecosystem, can all use. I'm afraid you never used those nor you are in one of those situation in which you have less options. > And STILL the best interim solution till your EFI setup has a bootloader. Again you should read the whole thread, please do, the whole eselect init stuff should stay opt-in for the time being so all this discussion is close to pointless. Consider this email a friendly warning, please do not pollute the Gentoo media with pointless email when you had been already politely told that your concern had been addressed in the previous email in the thread. > You're free to work on whatever you want. You just haven't made any > case for why the rest of the ecosystem should be crippled to allow for a > use-case that would be better served by an existing, far more robust > solution. Had it been the case we wouldn't had spent some weeks picking our brains on it. > Then it can be runit or whatever else takes your fancy. You are ignoring > the point of that paragraph though: someone has to put the install together. > > Or it isn't a Gentoo install. And you seem to miss the point that all you are telling had been discussed, taken in consideration and in some part agreed with already... > Wrt to the first, funnily enough the kernel developers have been here before, > just like they had with ethN and wlanN. It's a basic requirement for > developing > an OS that you be able to switch init and fallback to other options. Again you didn't ready or you forgot. I said already I don't care about systemd many times, yet you failed to remember that. My specific use-case would require a trip to single mode and a second reboot, the way I want to do spares that. On an EFI-stub only system it would require at least a kernel rebuild or a trip to the efi shell if available. > Honestly, my goal is a saving of time so people can focus on making the > eselect module work properly, and be of real value to an end-user who wants > to switch init. To not make this a waste of time here a summary of the whole thing: - eselect init will be opt-in for the time being, people can be left on their own tools if the want it - the default init will stay sysvinit. Discussion ongoing if is better to have it installed in a secondary fallback path is open (e.g. /bin/init). - I still need to send patches to busybox and sysvinit upstream to add a command line switch to locate the inittab. - people wanting to switch init or enable/disable init addons using eselect init might have to refer to /sbin/einit or such custom path (assuming we fail to come to an agreement regarding /bin/init) The wrapper in /sbin/init is mostly needed to get to the point of a clean reboot. The first time you boot on a new system it is executed picking the new init and just that. For addons such as bootchart2 and e4rat it would do slightly more. Assuming upstream doesn't accept custom paths for the inittab, for my specific usecase I might bake something that would remount r/w and pivot the inittabs. Anybody willing to do something more extreme could even consider having /sbin/init as a symlink and have the boot-time configuration switch the symlink, thus making the whole script run just a single boot per switch. Not necessary but surely feasible. lu
Re: [gentoo-dev] Draft news item: MySQL/MariaDB packages dropping support for PrimeBase (PBXT) engine
On Sun, Jun 02, 2013 at 02:32:53PM +0200, viv...@gmail.com wrote:
> On 06/01/13 02:37, Robin H. Johnson wrote:
> > Hi all,
> >
> > See attached the draft news item for MySQL/MariaDB dropping PBXT
> > support.
> from the draft:
> "All users who have data stored in PBXT-backed tables should convert the
> tables to another format before upgrading to MySQL/MariaDB 5.5, as the
> tables will otherwise become inaccessible. "
> s/before/BEFORE/
> it should be very visible.
Will do.
> Also, is it possible to halt the merge into filesystem if some PBXT
> tables exists in ${MY_DATADIR}?
> Not that I like it but maybe users prefer this to be forced to downgrade
> after.
I'll meet in the middle, and display a big warning if there are any .xt
files in MY_DATADIR. I will NOT halt the upgrade.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Re: Re: eselect init
On Sun, Jun 2, 2013 at 8:20 PM, Steven J. Long wrote: > [...] > The whole symlink/boot/fallback thing is simply a waste of technical effort. > And blanket "your opinion" and "you didn't comment a week ago, so I don't > have to deal with the substance of your points" don't change that. Waste? We have multiple use cases for that as stated in several places (here, bugzilla, IRC, etc). If such use cases are of no interest for you, then you shouldn't be bothered. > > Please, make a better case next time. > > -- > #friendly-coders -- We're friendly, but we're not /that/ friendly ;-) > -- Fabio Erculiani
[gentoo-dev] Re: Re: eselect init
On Sun, Jun 02, 2013 at 11:15:37AM +0200, Luca Barbato wrote: > On 06/01/2013 11:23 AM, Steven J. Long wrote: > > That's not an argument for using a symlink switcher or the > > equivalent across the board, by any means. > > Your opinion. That's not an argument for it either. > > Firstly, we should be recommending people install Gentoo with enough > > flexibility to configure and use their system how they choose. In the > > UEFI arena, why not simply recommend something like rEFIt instead of > > making everyone go through a load of development effort, to restrict > > us all to a crippled use-case? > > Beside rEFIt being deprecated and rEFInd being in early stage of > development (thus working great on some platforms and not working at all > on some other) and with a good chunk of documentation to read before > being able of deploying it? The typical thing Gentoo users get told is "this is a new thing, it will take some time to work out, bear with us" as their production servers go tits-up around them. So in this case too, work with upstream to implement better solutions you, and the wider ecosystem, can all use. And in the meantime: > > NOTE: If you still wish to pursue a fixed config, then it's easy > > enough to build it with init=/sbin/einit since presumably you want > > that setup for your users. > > Had been considered And STILL the best interim solution till your EFI setup has a bootloader. "Your opinion" of rejection is just that: your opinion. You're free to work on whatever you want. You just haven't made any case for why the rest of the ecosystem should be crippled to allow for a use-case that would be better served by an existing, far more robust solution. > > All I'm saying is: can we please stop trying to reinvent the kernel, > > which accepts a bootloader parameter from initramfs as well, and > > focus instead on the difficult part: making sure the system is in a > > fit state to switch in the first place. > > ... > > > That's where the development effort is needed, if you are to provide > > a mechanism to switch. The symlink and hooks etc is a total dead-end, > > imo. It's simply reinventing the wheel using octagons instead of > > circles. > > IMHO you hadn't read enough about it. Believe me I've read lots. And you _still_ are not presenting any arguments. There are 6 options to hook in an init, and to fallback in case of error, already. > > There's nothing to stop systemd being the default init, should you > > want to put the install together like that. Because let's be honest: > > someone has to put this install together, irrespective of how > > incapable the end-user is of editing a file by themselves. And just > > because the user can do it simply, that's no reason to make our > > method to do it any more complex (I've never heard such a bizarre > > argument.) Just edit the file via script. > > I do not care about systemd. Then it can be runit or whatever else takes your fancy. You are ignoring the point of that paragraph though: someone has to put the install together. Or it isn't a Gentoo install. So given that you're putting it together, or it's an automated script to do the same, you can hook in an init wrapper or alternative wherever you want, without needing anything from anyone else. > > FOCUS on getting the system safe to switch. Not on reinventing > > init/main.c, badly. > > You should read the whole thread before commenting like this that late. I have actually. I responded to WilliamH a while back, CC'ed to him since he prefers that, but the mail didn't get through to the list. It was marked TLDNR so no doubt it hit a filter somewhere, and I didn't see the point in reiterating it. I've seen two weeks of discussion about how to reimplement init/main.c with "ooh it needs to be early in init" and "what about fallbacks", interleaved with less and less discussion of the actual problem: making sure the system is safe to switch in the first place; sine qua non. Wrt to the first, funnily enough the kernel developers have been here before, just like they had with ethN and wlanN. It's a basic requirement for developing an OS that you be able to switch init and fallback to other options. You should consider the points made, and whether you really need to implement this part of the setup at all. Your premise is still flawed, however long you've been discussing the implications of working round it. Stuff happens. Honestly, my goal is a saving of time so people can focus on making the eselect module work properly, and be of real value to an end-user who wants to switch init. The whole symlink/boot/fallback thing is simply a waste of technical effort. And blanket "your opinion" and "you didn't comment a week ago, so I don't have to deal with the substance of your points" don't change that. Please, make a better case next time. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: evar_push/pop helpers
On Sat, Jun 01, 2013 at 11:03:20PM -0400, Mike Frysinger wrote:
> simple set of helpers to save/restore a variable in a limited section of code
>
> you can see an example of it in action at the end of the file where i need to
> tweak epatch (and no, doing `LC_COLLATE=C set -- ` does not work).
> -mike
>
> --- eutils.eclass 22 May 2013 05:10:29 - 1.421
> +++ eutils.eclass 2 Jun 2013 03:00:46 -
> @@ -146,6 +146,77 @@ estack_pop() {
> eval unset ${__estack_name}\[${__estack_i}\]
> }
Just in passing, one of the places you don't want nullglob messing things up.
> +# @FUNCTION: evar_push
> +# @USAGE: [more vars to save]
> +# @DESCRIPTION:
> +# This let's you temporarily modify a variable and then restore it (including
> +# set vs unset semantics). Arrays are not supported at this time.
> +#
> +# For example:
> +# @CODE
> +#evar_push LC_ALL
> +#export LC_ALL=C
> +#... do some stuff that needs LC_ALL=C set ...
> +#evar_pop
> +#
> +## You can also save/restore more than one var at a time
> +#evar_push BUTTERFLY IN THE SKY
> +#... do stuff with the vars ...
> +#evar_pop # This restores just one var, SKY
> +#... do more stuff ...
> +#evar_pop 3 # This pops the remaining 3 vars
> +# @CODE
> +evar_push() {
> + local var val
> + for var ; do
> + [[ ${!var+set} == "set" ]] \
> + && val=${!var} \
> + || val="${___ECLASS_ONCE_EUTILS}"
> + estack_push evar "${var}" "${val}"
> + done
> +}
> +
> +# @FUNCTION: evar_push_set
> +# @USAGE: [new value to store]
> +# @DESCRIPTION:
> +# This is a handy shortcut to save and temporarily set a variable. If a
> value
> +# is not specified, the var will be unset.
> +evar_push_set() {
> + local var=$1
> + evar_push ${var}
> + case $# in
> + 1) unset ${var} ;;
> + 2) eval ${var}=\$2 ;;
I wish you wouldn't use eval for this. I know it's technically okay here, or
would be
if you verified the parameter, but bash has printf -v for this purpose:
printf -v "$1" '%s' "$2" 2>/dev/null || die "unable to set: '$1' to: '$2'"
Note you should verify the variable name, ime, irrespective of a die on the
printf
(or eval in sh.) It's much better feedback to the developer using the routine.
Here's what we currently use in sh:
# lib_key_ok "$input_name"
# is the input name ok as a variable or key identifier
lib_key_ok(){
case $1 in
''|[![:alpha:]_]*|*[![:alnum:]_]*) return 1
;; *) return 0
esac
}
# lib_check_key foo bar..
# die if any param is not lib_key_ok
lib_check_key() {
local i
for i; do
lib_key_ok "$i" || die "bad key: '$i'"
done
}
So I'd probably just use: lib_key_ok "$1" || die "$FUNCNAME: bad varname: '$1'"
in this context, or amend the check_key function to use:
.. || die "${FUNCNAME[1]}: bad key '$i'"
- since you're working in bash by definition.
printf -v also works with array members btw, if you do decide to extend in that
direction:
$ set -- 'foo[2]' 'array madness'
$ printf -v "$1" %s "$2"
$ echo "'${foo[2]}'"
'array madness'
And yeah, you can compose the variable name, eg:
set -- foo 'array 1' 1
printf -v "$1${3:+[$3]}" %s "$2"
echo "'${foo[1]}'"
So long as the developer using the routines knows about quoting, that works
fine.
(If they don't, you have bigger problems.)
> + *) die "${FUNCNAME}: incorrect # of args: $*" ;;
> + esac
> +}
> +
> +# @FUNCTION: evar_pop
> +# @USAGE: [number of vars to restore]
> +# @DESCRIPTION:
> +# Restore the variables to the state saved with the corresponding
> +# evar_push call. See that function for more details.
> +evar_pop() {
> + local cnt=$1
might as well use: cnt=${1:-bad}
> + case $# in
> + 0) cnt=1 ;;
> + 1)
and lose this line.
> + : ${cnt:=bad}
> + [[ -n ${cnt//[0-9]} ]] && die "${FUNCNAME}: first arg must be a
> number: $*"
> + ;;
Though a generic is_int function comes in much handier, ime.
is_int() {
[[ $1 && $1 != *[^0-9]* ]]
}
1) is_int "$1" || die ..
cnt=$1
(I tend to guard against 0? as well, as octal inputs tend to mess things up
later. I'm
sure you can see the case for sh.)
> + *) die "${FUNCNAME}: only accepts one arg: $*" ;;
> + esac
> +
> + local var val
> + while (( cnt-- )) ; do
> + estack_pop evar val || die "${FUNCNAME}: unbalanced push"
> + estack_pop evar var || die "${FUNCNAME}: unbalanced push"
> + [[ ${val} == "${___ECLASS_ONCE_EUTILS}" ]] \
> + && unset ${var} \
> + || eval ${var}=\${val}
again: printf -v "$var" %s "$val"
Though I'd rather this were in an if, so you can test for error better:
if [[ $val = "$___ECLASS_ONCE_EU
Re: [gentoo-dev] evar_push/pop helpers
Am Sonntag, 2. Juni 2013, 17:40:45 schrieb Mike Frysinger: > > i snipped the rest of your e-mail because it wasn't worth responding to > -mike Please. Save your social skills for other people. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] evar_push/pop helpers
On Sunday 02 June 2013 04:39:32 Michał Górny wrote: > Dnia 2013-06-02, o godz. 03:29:33 Mike Frysinger napisał(a): > > On Sunday 02 June 2013 03:16:53 Michał Górny wrote: > > > Dnia 2013-06-02, o godz. 03:09:31 Mike Frysinger napisał(a): > > > > On Sunday 02 June 2013 02:51:34 Michał Górny wrote: > > > > > Dnia 2013-06-01, o godz. 23:03:20 Mike Frysinger napisał(a): > > > > > > simple set of helpers to save/restore a variable in a limited > > > > > > section of code > > > > > > > > > > > > you can see an example of it in action at the end of the file > > > > > > where i need to tweak epatch (and no, doing `LC_COLLATE=C set -- > > > > > > ` does not work). > > > > > > > > > > Why the ugly hackery instead of proper 'local' scope? > > > > > > > > there's no way to undo the local thus it affects the rest of the > > > > func. this makes sure the change is actually localized to where it > > > > is needed. > > > > > > By use of global variables and a bunch of additional code and evals. > > > > the implementation details of estack_* doesn't matter > > It's not beautiful language with proper local scopes, so it *does* > matter. then go ahead and propose something different. otherwise you're pointlessly twisting in the wind. > > > Also, do you really want the collation to be changed only in this one > > > place? This looks weird to me. > > > > yes, i only want to force it here, because it's the only place where > > collation matters in the func currently. > > So, effectively, changing it once in the beginning of the function > would be simpler and wouldn't cost anything. most likely, *today*, yes. in the future, who knows. but since this is the only place in the func where we need to force a specific sorting, it makes sense to localize the change to that. i snipped the rest of your e-mail because it wasn't worth responding to -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/02/2013 07:02 AM, Pacho Ramos wrote: > Due c1pher lack of time the following packages are now up for grabs: > net-analyzer/ostinato > net-wireless/mdk I'll take these. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRq2IEAAoJEKXdFCfdEflKwpQQALQu5TBK0O5Mv+e+3UenA0gZ JEeSUSqWJRasg16B97jTNHO6lJ+UvqaAdFqj6eS4a9selyxztlTLTy8EoxlVrxDA 4NlJjyXDyibFlT0hTskQguRyM90VxQxekHpfQdSf00cXEz/hoDrBCXIemrqtt2Ut w3qMACrepbyA2EiCo4w2muFDGSUt6dT+LiEIsYlfrUjTJshjoIs4gCXyRipSIxpf KLYWcfOqoSw3gYrBLXwy+HjFEholCePoB/kcDVdhZ0WwHhmGqYDU+MUYLxrzFNux fbbz6GRoAo86CoGvZWQcPPt1lfY/5ksz1y4oWLVhguaoT4iO6IHnvQupj54IkHUf v8Of3sS1Qc8UQbCVxmNKZCVgwn8rDy1XXZ5clFg/nJWJdqL8I3Euq4QTNSFrqmc3 JM28+2sTrI14aA9b/E4RWwhukNkQwLQKZc5iXCh7gyRomSalltgUT2zzdh8f+Agu Se9xr4JMFZ8CdE2aUSsGus++30mUVt2KJX2gMG+gWf9ti1RWvlNlnYjcVvp9PPlt e6f4X0D42/16sG6CyG//TMzxBi9IXoYOcGF7kUYtO0f+Gbw3p1vfFmaT/bdlkUpj VTJmd0MMF2NcwFKSMkUEOCJWw9c3TjQM7M+s08imuFZve1kM8pLc69dUqid3j+Qh Qu8WJ4gSNBabvXjOwxJ1 =iknG -END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs
On 06/02/2013 07:02 AM, Pacho Ramos wrote: Due c1pher lack of time the following packages are now up for grabs: app-benchmarks/ramspeed I'm the last person to have done some maintenance on ramspeed. I can take care of it. -- 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] Draft news item: MySQL/MariaDB packages dropping support for PrimeBase (PBXT) engine
On 06/01/13 02:37, Robin H. Johnson wrote:
> Hi all,
>
> See attached the draft news item for MySQL/MariaDB dropping PBXT
> support.
from the draft:
"All users who have data stored in PBXT-backed tables should convert the
tables to another format before upgrading to MySQL/MariaDB 5.5, as the
tables will otherwise become inaccessible. "
s/before/BEFORE/
it should be very visible.
Also, is it possible to halt the merge into filesystem if some PBXT
tables exists in ${MY_DATADIR}?
Not that I like it but maybe users prefer this to be forced to downgrade
after.
>
> I would like to drop the blocks into the tree not later than June 3rd.
> I think it should affect very few users, as PBXT was a niche feature.
>
> This should clear us to get MySQL/MariaDB 5.5 into stable.
>
nice!
[gentoo-dev] Packages up for grabs
Due c1pher lack of time the following packages are now up for grabs: app-benchmarks/ramspeed app-text/mht-rip net-analyzer/ostinato net-wireless/mdk
Re: [gentoo-dev] Re: eselect init
On 06/01/2013 11:23 AM, Steven J. Long wrote: > That's not an argument for using a symlink switcher or the > equivalent across the board, by any means. Your opinion. > Firstly, we should be recommending people install Gentoo with enough > flexibility to configure and use their system how they choose. In the > UEFI arena, why not simply recommend something like rEFIt instead of > making everyone go through a load of development effort, to restrict > us all to a crippled use-case? Beside rEFIt being deprecated and rEFInd being in early stage of development (thus working great on some platforms and not working at all on some other) and with a good chunk of documentation to read before being able of deploying it? > NOTE: If you still wish to pursue a fixed config, then it's easy > enough to build it with init=/sbin/einit since presumably you want > that setup for your users. Had been considered > All I'm saying is: can we please stop trying to reinvent the kernel, > which accepts a bootloader parameter from initramfs as well, and > focus instead on the difficult part: making sure the system is in a > fit state to switch in the first place. ... > That's where the development effort is needed, if you are to provide > a mechanism to switch. The symlink and hooks etc is a total dead-end, > imo. It's simply reinventing the wheel using octagons instead of > circles. IMHO you hadn't read enough about it. > There's nothing to stop systemd being the default init, should you > want to put the install together like that. Because let's be honest: > someone has to put this install together, irrespective of how > incapable the end-user is of editing a file by themselves. And just > because the user can do it simply, that's no reason to make our > method to do it any more complex (I've never heard such a bizarre > argument.) Just edit the file via script. I do not care about systemd. > FOCUS on getting the system safe to switch. Not on reinventing > init/main.c, badly. You should read the whole thread before commenting like this that late. lu
Re: [gentoo-dev] evar_push/pop helpers
Dnia 2013-06-02, o godz. 03:29:33
Mike Frysinger napisał(a):
> On Sunday 02 June 2013 03:16:53 Michał Górny wrote:
> > Dnia 2013-06-02, o godz. 03:09:31 Mike Frysinger napisał(a):
> > > On Sunday 02 June 2013 02:51:34 Michał Górny wrote:
> > > > Dnia 2013-06-01, o godz. 23:03:20 Mike Frysinger napisał(a):
> > > > > simple set of helpers to save/restore a variable in a limited section
> > > > > of code
> > > > >
> > > > > you can see an example of it in action at the end of the file where i
> > > > > need to tweak epatch (and no, doing `LC_COLLATE=C set -- ` does
> > > > > not work).
> > > >
> > > > Why the ugly hackery instead of proper 'local' scope?
> > >
> > > there's no way to undo the local thus it affects the rest of the func.
> > > this makes sure the change is actually localized to where it is needed.
> >
> > By use of global variables and a bunch of additional code and evals.
>
> the implementation details of estack_* doesn't matter
It's not beautiful language with proper local scopes, so it *does*
matter.
> > Is:
> >
> > local _epatch_foo=${foo}
> > local foo
> > ...
> > foo=${_epatch_foo}
> >
> > really that hurtful?
>
> except you aren't handling edge cases (like set vs unset), and i've
> replicated
> this pattern before (in fact, you've filed bugs where the set/unset case
> wasn't
> handled). API 101: implement it once correctly to simplify everyone else.
Edge cases matter where they actually matter. Inventing use cases just
to prove we need something doesn't help anyone.
And we can't implement it correctly since we're talking about bash.
Bash doesn't provide means to implement it correctly.
> > Also, do you really want the collation to be changed only in this one
> > place? This looks weird to me.
>
> yes, i only want to force it here, because it's the only place where
> collation
> matters in the func currently.
So, effectively, changing it once in the beginning of the function
would be simpler and wouldn't cost anything.
>
> > Much like fixing tiny bug and trying to
> > avoid checking whether anything else is affected.
>
> yeah, because forcing specific behavior for an entire function is always the
> correct answer. it's like telling people to export LC_ALL=C in make.conf so
> they never hit locale related problems.
Feel free to try that. But on yourself, not our users. Or just grep
bugzie.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] evar_push/pop helpers
On Sun, 2 Jun 2013 03:29:33 -0400 Mike Frysinger wrote: > except you aren't handling edge cases (like set vs unset) You've got me there, though this is quite an exception; I don't see why we have to introduce something that's barely used... `qgrep -eH '^\s*\bset\b' | wc -l` yields 150 `qgrep -eH '^\s*\bset\b' | sed 's/:.*//g' | sed 's/\/[a-zA-Z0-9_.-]*$//g' | sort -u | wc -l` yields 34 Only 34 packages, and do these all _really_ need a 'set'? I doubt it. > API 101: implement it once correctly to simplify everyone else. For set this would make sense, unless someone finds a way to deal with that too; any Bash experts around here? > > Much like fixing tiny bug and trying to > > avoid checking whether anything else is affected. > > yeah, because forcing specific behavior for an entire function is > always the correct answer. it's like telling people to export > LC_ALL=C in make.conf so they never hit locale related problems. Actually, bug wranglers stopped asked for English build logs because setting LC_ALL=C ended up breaking things. -- 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] evar_push/pop helpers
On Sun, 2 Jun 2013 03:09:31 -0400
Mike Frysinger wrote:
> there's no way to undo the local thus it affects the rest of the
> func. this makes sure the change is actually localized to where it
> is needed. -mike
In other languages you can freely introduce local scopes { ... }, this
isn't possible in Bash since a local corresponds to a function; but
it's not really that hard to replicate, now consider this instead:
test()
{
local test="FUNCTION"
echo ${test}
x(){
local test="LOCAL SCOPE 1"
echo ${test}
};x
echo ${test}
x(){
local test="LOCAL SCOPE 2"
echo ${test}
};x
echo ${test}
}
test
Now 'x' is vague, you could replace 'x' by a name documenting the scope.
I consider this to be more clean than using a variable to remember it,
especially when multiple local scopes are to be used after each other.
--
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] evar_push/pop helpers
On Sunday 02 June 2013 03:16:53 Michał Górny wrote:
> Dnia 2013-06-02, o godz. 03:09:31 Mike Frysinger napisał(a):
> > On Sunday 02 June 2013 02:51:34 Michał Górny wrote:
> > > Dnia 2013-06-01, o godz. 23:03:20 Mike Frysinger napisał(a):
> > > > simple set of helpers to save/restore a variable in a limited section
> > > > of code
> > > >
> > > > you can see an example of it in action at the end of the file where i
> > > > need to tweak epatch (and no, doing `LC_COLLATE=C set -- ` does
> > > > not work).
> > >
> > > Why the ugly hackery instead of proper 'local' scope?
> >
> > there's no way to undo the local thus it affects the rest of the func.
> > this makes sure the change is actually localized to where it is needed.
>
> By use of global variables and a bunch of additional code and evals.
the implementation details of estack_* doesn't matter
> Is:
>
> local _epatch_foo=${foo}
> local foo
> ...
> foo=${_epatch_foo}
>
> really that hurtful?
except you aren't handling edge cases (like set vs unset), and i've replicated
this pattern before (in fact, you've filed bugs where the set/unset case wasn't
handled). API 101: implement it once correctly to simplify everyone else.
> Also, do you really want the collation to be changed only in this one
> place? This looks weird to me.
yes, i only want to force it here, because it's the only place where collation
matters in the func currently.
> Much like fixing tiny bug and trying to
> avoid checking whether anything else is affected.
yeah, because forcing specific behavior for an entire function is always the
correct answer. it's like telling people to export LC_ALL=C in make.conf so
they never hit locale related problems.
feel free to read the whole func yourself if you think there are other places
where this matters.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] evar_push/pop helpers
Dnia 2013-06-02, o godz. 03:09:31
Mike Frysinger napisał(a):
> On Sunday 02 June 2013 02:51:34 Michał Górny wrote:
> > Dnia 2013-06-01, o godz. 23:03:20 Mike Frysinger napisał(a):
> > > simple set of helpers to save/restore a variable in a limited section of
> > > code
> > >
> > > you can see an example of it in action at the end of the file where i
> > > need to tweak epatch (and no, doing `LC_COLLATE=C set -- ` does not
> > > work).
> >
> > Why the ugly hackery instead of proper 'local' scope?
>
> there's no way to undo the local thus it affects the rest of the func. this
> makes sure the change is actually localized to where it is needed.
By use of global variables and a bunch of additional code and evals.
Is:
local _epatch_foo=${foo}
local foo
...
foo=${_epatch_foo}
really that hurtful?
Also, do you really want the collation to be changed only in this one
place? This looks weird to me. Much like fixing tiny bug and trying to
avoid checking whether anything else is affected.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] evar_push/pop helpers
On Sunday 02 June 2013 02:51:34 Michał Górny wrote: > Dnia 2013-06-01, o godz. 23:03:20 Mike Frysinger napisał(a): > > simple set of helpers to save/restore a variable in a limited section of > > code > > > > you can see an example of it in action at the end of the file where i > > need to tweak epatch (and no, doing `LC_COLLATE=C set -- ` does not > > work). > > Why the ugly hackery instead of proper 'local' scope? there's no way to undo the local thus it affects the rest of the func. this makes sure the change is actually localized to where it is needed. -mike signature.asc Description: This is a digitally signed message part.
