Re: [gentoo-dev] eselect_zenity: alpha eselect GUI
On 10:54 Thu 08 Nov , Ciaran McCreesh wrote: On Thu, 8 Nov 2007 02:48:13 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: it has to parse eselect output Part of the idea behind using standardised output functions was that they could be replaced. The thought was, rather than trying to parse console-centric output, you'd swap in a different implementation of the output functions that fed to, say, ncurses or a GUI. Then you'd swap the driver logic with something that calls multiple tasks in order rather than merely doing one thing and then exiting (there's proper environment isolation to allow that). Might be easier to do things that way... I'll look into that. Got any good starting points (files, functions, docs)? Thanks, Donnie -- [EMAIL PROTECTED] mailing list
[gentoo-dev] eselect_zenity: alpha eselect GUI
Hey all, I've been wanting a GUI for eselect lately, so tonight I hacked up the start of one called eselect_zenity [1]. It only works for the most trivial modules so far -- it has to parse eselect output, so special parsers need to be written for each type. eselect_zenity uses (surprise!) Zenity, a shell-scripting interface to GTK+. I'd appreciate any patches you'd like to contribute to add functionality or fix bugs. Thanks, Donnie 1. http://dev.gentoo.org/~dberkholz/eselect_zenity/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] eselect_zenity: alpha eselect GUI
On Thu, 8 Nov 2007 02:48:13 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: it has to parse eselect output Part of the idea behind using standardised output functions was that they could be replaced. The thought was, rather than trying to parse console-centric output, you'd swap in a different implementation of the output functions that fed to, say, ncurses or a GUI. Then you'd swap the driver logic with something that calls multiple tasks in order rather than merely doing one thing and then exiting (there's proper environment isolation to allow that). Might be easier to do things that way... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] eselect_zenity: alpha eselect GUI
On Thu, 8 Nov 2007 04:07:42 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:
I'll look into that. Got any good starting points (files, functions,
docs)?
Well, the whole of the eselect code is small enough that you should be
able to understand it pretty quickly... Then it'd just be a case of
making the main driver code a bit more flexible so that you can tell it
to swap in certain libraries.
Incidentally, I suspect it might be worth rewriting the core using some
of the techniques that we've discovered when writing Paludis. Things
like the fancier signalling die function and the cleaner module path
searching would be worth adopting. This would also be a good
opportunity to sneak in the more flexible driver that you probably
need. Might be worth speaking to whoever maintains Gentoo's branch of
eselect these days.
One thing in the code, by the way...
if [[ ${UID} -ne 0 ]]; then
We've always told people not to do that. Capabilities required by
eselect modules should be tested by attempting to perform the action,
not by some arbitrary query done on UIDs or groups. Being UID 0 doesn't
mean you're allowed to do something, and not being UID 0 doesn't mean
you're not allowed to do something.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] eselect_zenity: alpha eselect GUI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: Hey all, I've been wanting a GUI for eselect lately, so tonight I hacked up the start of one called eselect_zenity [1]. It only works for the most trivial modules so far -- it has to parse eselect output, so special parsers need to be written for each type. eselect_zenity uses (surprise!) Zenity, a shell-scripting interface to GTK+. I'd appreciate any patches you'd like to contribute to add functionality or fix bugs. Thanks, Donnie 1. http://dev.gentoo.org/~dberkholz/eselect_zenity/ Nice work, you should announce it too at the gentoo-guis ml. :-) Regards, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHMyVKBCmRZan6aegRAq51AKDGK606Kms7RR06mR0uGD95NtEvRgCeL+Rk UX948bV08q/nN5ryBVt8dlg= =XVMM -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New eclass: cmake-utils.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I just worked on a project using cmake. And I needed the cmake-utils_src_enable function... But it did not work as expected. This is because cmake arguments are in uppercase most of the time, and cmake is case sensitive. And unfortunately the cmake-utils_src_* functions just return the passed in flag literally: cmake-utils_src_enable python = -DENABLE_python=... Wanted would be that it returned -DENABLE_PYTHON=... I'm not into bash scripting that much, so I do not know a way to do so - but I guess someone else is ;) Regards, Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMzdk4UOg/zhYFuARAg92AJ4qpzuei0P+y+Wfy4dah/MWq4pBAACdG178 yEkbV4vpDx3CtFc9pdEfldw= =avlW -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: eselect_zenity: alpha eselect GUI
Ciaran McCreesh wrote:
if [[ ${UID} -ne 0 ]]; then
We've always told people not to do that. Capabilities required by
eselect modules should be tested by attempting to perform the action,
not by some arbitrary query done on UIDs or groups. Being UID 0 doesn't
mean you're allowed to do something, and not being UID 0 doesn't mean
you're not allowed to do something.
I've always used EUID for the root check, eg:
if ((EUID)); then
echo You must be root to run this script 2
exit 1
fi
This won't get round capabilities (so error status should still be checked
and the script bail with appropriate output, if it can't do something it's
supposed to) but it's sufficient for root privilege check, and is better
than UID which requires login as root. This doesn't, of course, deal with
non-root users, eg where users in group portage are allowed to carry out a
task.
You can check for that kind of thing with a writeable test, eg:
[[ -w $PORTDIR ]] || die 'Write access to portage dir required
While none of this stops you from needing to check errors, it does make it
nicer for users, imo, if scripts check early on for broader permissions
where it's appropriate.
Wrt signalling die, the correct way for a script to terminate on signal is
something like this code, taken from a SIG_INT handler:
trap INT
kill -INT $$
This ensures the parent process is correctly notified. So IOW just kill self
with the appropriate signal, ensuring any traps are cleared.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] death to mailer-config/mailwrapper
Robin H. Johnson wrote: [Fri Nov 02 2007, 08:35:50PM CDT] It was a good idea, but it just never took off, I think mainly because it required too many changes to MTAs, and also did not provide for one of the original goals - running two disparate MTAs on the same box. The mailwrapper program is only intended to allow users to have two MTAs _installed_ on the same box, not actually have them both running simultaneously. It works pretty well for that, but I agree that there seems to be little real need for it. I have no objection to it going away. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp6HnNFyf2aG.pgp Description: PGP signature
Re: [gentoo-dev] Re: eselect_zenity: alpha eselect GUI
On Thu, 08 Nov 2007 18:22:48 +
Steve Long [EMAIL PROTECTED] wrote:
if [[ ${UID} -ne 0 ]]; then
We've always told people not to do that. Capabilities required by
eselect modules should be tested by attempting to perform the
action, not by some arbitrary query done on UIDs or groups. Being
UID 0 doesn't mean you're allowed to do something, and not being
UID 0 doesn't mean you're not allowed to do something.
I've always used EUID for the root check, eg:
Which is just as bad.
This won't get round capabilities (so error status should still be
checked and the script bail with appropriate output, if it can't do
something it's supposed to) but it's sufficient for root privilege
check, and is better than UID which requires login as root. This
doesn't, of course, deal with non-root users, eg where users in group
portage are allowed to carry out a task.
Except you absolutely never should be checking for root. You should be
checking for capabilities.
You can check for that kind of thing with a writeable test, eg:
[[ -w $PORTDIR ]] || die 'Write access to portage dir required
-w is not reliable.
Wrt signalling die, the correct way for a script to terminate on
signal is something like this code, taken from a SIG_INT handler:
trap INT
kill -INT $$
This ensures the parent process is correctly notified. So IOW just
kill self with the appropriate signal, ensuring any traps are cleared.
No it isn't. When it comes to die, from bad implementations to good
implementations, the order goes: the original drobbins prefix die sucks
more than the original agriffis die, which sucks more than my original
signalling eselect die, which sucks more than the current signalling
paludis die. As time goes on we're finding better and better tricks to
work around bash's lack of exceptions; eselect is currently one
generation behind the best current known solution.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: New eclass: cmake-utils.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Long schrieb:
René 'Necoro' Neumann wrote:
cmake-utils_src_enable python = -DENABLE_python=...
Wanted would be that it returned -DENABLE_PYTHON=...
I'm not into bash scripting that much, so I do not know a way to do so -
but I guess someone else is ;)
Unfortunately BASH doesn't support ksh93 or zsh style casting to uppercase.
The best way really is via tr:
alias toUpper='tr [[:lower:]] [[:upper:]]'
alias toLower='tr [[:upper:]] [[:lower:]]'
(er aliases don't normally work in scripts, but you get the idea.) Bear in
mind that tr reads stdin and writes to stdout. It has the advantage of
being locale-safe. Every other method I've looked at is much slower and
only works with ASCII.
A function wouldn't be too hard:
toUpper() {
for i; do
echo $i |tr [[:lower:]] [[:upper:]]
done
}
Usage depends on the parameters you pass.
var=$(toUpper $var) # for single vars with no newlines in
This is right the version I've chosen ... so with the help of Steve: a
small patch ;)
Regards,
Necoro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD4DBQFHM5uv4UOg/zhYFuARAuELAJjnlDCFDMm3e2mJqYuyT4nkFoaaAJ4go9qp
Qca9r8Y7LpD0YSSylUh2BQ==
=517n
-END PGP SIGNATURE-
--- cmake-utils.eclass.old 2007-11-09 00:25:49.0 +0100
+++ cmake-utils.eclass 2007-11-09 00:14:47.0 +0100
@@ -23,11 +23,17 @@
EXPORT_FUNCTIONS src_compile src_test src_install
+# Internal funcion used by _use_me_now. Converts string to upper case.
+_to_upper() {
+ debug-print-function $FUNCNAME $*
+ echo $1 | tr [[:lower:]] [[:upper:]]
+}
+
# Internal function use by cmake-utils_use_with and cmake-utils_use_enable
_use_me_now() {
debug-print-function $FUNCNAME $*
[[ -z $2 ]] die cmake-utils_use-$1 USE flag [flag name]
- echo -D$1_${3:-$2}=$(use $2 echo ON || echo OFF)
+ echo -D$1_${3:-$(_to_upper $2)}=$(use $2 echo ON || echo OFF)
}
# @FUNCTION: cmake-utils_use_with
[gentoo-dev] Council meeting summary for 8 November 2007
Hi all, Here is the summary from today's council meeting. The complete log will show up at http://www.gentoo.org/proj/en/council/ shortly. Thanks, Donnie amnehere betelgeuse absent (1 hour late) dberkholz here flameeyes here lu_zero here vapier absent (no show) uberlordresigned jokey here (replacing uberlord) Agenda: http://thread.gmane.org/gmane.linux.gentoo.devel/52772 Also continuing discussion on CoC enforcement. Proposal: http://thread.gmane.org/gmane.linux.gentoo.council/82 == Empty council slot: vote for Jokey to happen on gentoo-council list --- Jokey is the candidate to replace uberlord [1], and it requires a unanimous council vote [2]. Since not all council members are present, we'll do this vote on the gentoo-council list. All 6 present council members supported Jokey's addition. 1. http://www.gentoo.org/proj/en/council/meeting-logs/20070208-summary.txt 2. http://www.gentoo.org/proj/en/council/voting-logs/council-2007-vote-distribution.txt Daylight savings change: no slacker marks - In the US and Europe, 2000 UTC shifted by an hour in local time. The email announcement was wrong, so we will not give slacker marks to the two absent council members. vapier needs to fix his script before the next announcement. EAPI=1 approved for use in the main tree Stable portage version 2.1.3.12 supports EAPI=1. It's now officially OK to start using it in the main tree. From the ebuild ChangeLog for portage: This release is the first to have support for EAPI-1 (#194876), which includes SLOT dependencies (#174405), IUSE defaults (#174410), and ECONF_SOURCE support for the default src_compile function (#179380). Package maintainers should carefully consider the backward compatibility consequences before defining EAPI=1 in any ebuilds, especially if other packages depend on those ebuilds. See the ebuild(5) and emerge(1) manual pages for EAPI related documentation. EAPI=1 features are documented in PMS as well as the man pages, but they are not yet documented in the devmanual or the dev handbook. Code of Conduct enforcement proposal: generally positive feedback - dberkholz sent out a proposal this morning [1], so we just discussed it today instead of voting. Initial feedback from council members was positive. Some concerns came up on the list about time zone differences and coverage, which were brought up again during the meeting. People generally agreed that although the environment is better now, it hasn't been before and won't always be good. lu_zero brought up the point that since things are fairly good now, we don't need to rush through this process and we can take our time and do things right. Council support for the team's actions should not be as controversial with the requirement that all actions be private. The team will need to create the tools to deal with the actions it needs to take (short-term moderation on IRC, mailing lists, and Bugzilla). This could happen during the initial training period suggested on the gentoo-council list. If there's already existing moderation somewhere (for example many of the #gentoo-* IRC channels or the forums), the team will first liaise with them rather than preempt them. All official Gentoo forums must adhere to the CoC, however; having their own moderation does not exclude them from following Gentoo's standards as a whole. The expectation is that successive actions against the same person will increase in length, eventually reaching the 3-day cutoff that requires council approval and forwarding to devrel/userrel. The idea is that if someone keeps violating the CoC after a given length of moderation, it apparently wasn't enough so it shouldn't be repeated. Next month, we will vote on a concrete proposal. 1. http://thread.gmane.org/gmane.linux.gentoo.council/82 Baselayout-2: uberlord will continue to maintain it --- lu_zero asked whether we had anything to do about baselayout-2 since uberlord resigned. He's continuing to maintain it in a git repository and will remain upstream for it. More details will emerge over time. kingtaco raised the question of trusting external releases and hosts. Some responses suggested that using git may prevent the malicious host, because of the possibility of GPG-signed tags. He mentioned the possibility of the infra team hosting Gentoo-critical repositories with access by non-Gentoo developers. It's just an idea at this point, but he's going to talk to the rest of the infra team.
[gentoo-dev] Re: New eclass: cmake-utils.eclass
René 'Necoro' Neumann wrote:
cmake-utils_src_enable python = -DENABLE_python=...
Wanted would be that it returned -DENABLE_PYTHON=...
I'm not into bash scripting that much, so I do not know a way to do so -
but I guess someone else is ;)
Unfortunately BASH doesn't support ksh93 or zsh style casting to uppercase.
The best way really is via tr:
alias toUpper='tr [[:lower:]] [[:upper:]]'
alias toLower='tr [[:upper:]] [[:lower:]]'
(er aliases don't normally work in scripts, but you get the idea.) Bear in
mind that tr reads stdin and writes to stdout. It has the advantage of
being locale-safe. Every other method I've looked at is much slower and
only works with ASCII.
A function wouldn't be too hard:
toUpper() {
for i; do
echo $i |tr [[:lower:]] [[:upper:]]
done
}
Usage depends on the parameters you pass.
var=$(toUpper $var) # for single vars with no newlines in
for i in $(toUpper $@); do # for multiple, if just simple flags with no
space, tabs or newlines.
IFS=$'\n'; before the above would deal with anything but newlines in the
vars. (We can get more complex but I doubt it's needed in this scope, much
as I hate leaving script in a technically unsafe state. If you're parsing
filenames, this is *not* safe.)
$ a='blah blah'
$ a=$(toUpper $a)
$ echo $a
BLAH BLAH
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: New eclass: cmake-utils.eclass
2007/11/9, René 'Necoro' Neumann [EMAIL PROTECTED]:
Steve Long schrieb:
René 'Necoro' Neumann wrote:
cmake-utils_src_enable python = -DENABLE_python=...
Wanted would be that it returned -DENABLE_PYTHON=...
I'm not into bash scripting that much, so I do not know a way to do so -
but I guess someone else is ;)
Unfortunately BASH doesn't support ksh93 or zsh style casting to
uppercase.
The best way really is via tr:
alias toUpper='tr [[:lower:]] [[:upper:]]'
alias toLower='tr [[:upper:]] [[:lower:]]'
(er aliases don't normally work in scripts, but you get the idea.) Bear in
mind that tr reads stdin and writes to stdout. It has the advantage of
being locale-safe. Every other method I've looked at is much slower and
only works with ASCII.
A function wouldn't be too hard:
toUpper() {
for i; do
echo $i |tr [[:lower:]] [[:upper:]]
done
}
Usage depends on the parameters you pass.
var=$(toUpper $var) # for single vars with no newlines in
This is right the version I've chosen ... so with the help of Steve: a
small patch ;)
Regards,
Necoro
Hi Necoro,
You can just use 'cmake-utils_use_enable python PYTHON'
It's mentioned in the cmake-utils.eclass manpage (app-portage/eclass-manpages),
as well as in the patch you just sent: cmake-utils_use_enable USE
flag [flag name]
:-)
Regards,
Ingmar Vanhassel
