Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On 2/13/06, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: But... If INVALID is renamed, could we get a new GOAWAY resolution for people who really deserve it? Like others here, I've also felt a bit stunned at an INVALID bug. Personally, I don't think anything needs to be renamed, but I would like to see a simple, short comment about why such a decision was made. This adds a bit more time for people handling the bugs, but it saves confusion on the part of the person bugging, more time for an explanation to be given when/if the person asks why it was marked the way it was, and creating a whole host of new, specific tags. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: /etc/rc.conf
On Monday 13 February 2006 20:07, Forrest Voight wrote: > How is that wrong? If it isn't, eselect would be a great way to switch > EDITOR and XSESSION. jesus, talk about over engineering using eselect to manage some default variables instead of simply editing your ~/.bashrc file is like using a backhoe to dig a hole for a bonsai tree ... sure it'll work, but who the hell wants a goddamn bonsai tree -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: /etc/rc.conf
How is that wrong? If it isn't, eselect would be a great way to switch EDITOR and XSESSION. On 2/13/06, Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Monday 13 February 2006 19:01, Alec Warner wrote: > > Forrest Voight wrote: > > > What happens if two env.d files set the same variable? > > > > You write an eselect module to choose between them :) > > brr wrong > -mike > -- > gentoo-dev@gentoo.org mailing list > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: /etc/rc.conf
On Monday 13 February 2006 19:01, Alec Warner wrote: > Forrest Voight wrote: > > What happens if two env.d files set the same variable? > > You write an eselect module to choose between them :) brr wrong -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: /etc/rc.conf
Forrest Voight wrote: > What happens if two env.d files set the same variable? > You write an eselect module to choose between them :) > On 2/13/06, Olivier Crete <[EMAIL PROTECTED]> wrote: > >>On Mon, 2006-13-02 at 16:51 -0500, Forrest Voight wrote: >> >>>What about env.d? Gnome could install and env file that by default >>>sets XSESSION to gnome. >> >>Can't do... you can have gnome, kde, xfce, etc all installed at the same >>time. >> >> -Alec Warner signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: /etc/rc.conf
On Monday 13 February 2006 14:24, Forrest Voight wrote: > What happens if two env.d files set the same variable? AFAIK, the env.d files processed in lexicographic order, and later entries override earlier ones, except for certain variables (such as PATH) which are added to instead. -- # # electronerd, the electronerdian from electronerdia # pgpZbycadNUR0.pgp Description: PGP signature
[gentoo-dev] Re: /etc/rc.conf
What happens if two env.d files set the same variable? On 2/13/06, Olivier Crete <[EMAIL PROTECTED]> wrote: > On Mon, 2006-13-02 at 16:51 -0500, Forrest Voight wrote: > > What about env.d? Gnome could install and env file that by default > > sets XSESSION to gnome. > > Can't do... you can have gnome, kde, xfce, etc all installed at the same > time. > > > On 2/13/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > > On Monday 13 February 2006 13:19, Forrest Voight wrote: > > > > Why doesn't it make sense to split DISPLAYMANAGER and XSESSION up? > > > > They are related, but in different contexts. XSESSION is for the user > > > > and DISPLAYMANAGER is used at boot time. > > > > > > > > On 2/13/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > > > > On Monday 13 February 2006 03:33, Donnie Berkholz wrote: > > > > > > And even then, it's only copied over when you specify the -m > option > > > > > > to useradd. It isn't done by default. > > > > > > > > > > Users might further decide they use a .bashrc from a different > > > > > system, or to clean all percieved cruft from the > > > > > .bashrc/.bash_profile. Having a sane default is probably better. > > > > > > I was just arguing why one should not keep XSESSION in .bashrc only, and > > > rely on skel. It's too easy to break. > > > > > > Paul > > > > > > -- > > > Paul de Vrieze > > > Gentoo Developer > > > Mail: [EMAIL PROTECTED] > > > Homepage: http://www.devrieze.net > > > > > > > > -- > Olivier Crête > [EMAIL PROTECTED] > Gentoo Developer > > > -- > gentoo-dev@gentoo.org mailing list > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: /etc/rc.conf
On Mon, 2006-13-02 at 16:51 -0500, Forrest Voight wrote: > What about env.d? Gnome could install and env file that by default > sets XSESSION to gnome. Can't do... you can have gnome, kde, xfce, etc all installed at the same time. > On 2/13/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > On Monday 13 February 2006 13:19, Forrest Voight wrote: > > > Why doesn't it make sense to split DISPLAYMANAGER and XSESSION up? > > > They are related, but in different contexts. XSESSION is for the user > > > and DISPLAYMANAGER is used at boot time. > > > > > > On 2/13/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > > > On Monday 13 February 2006 03:33, Donnie Berkholz wrote: > > > > > And even then, it's only copied over when you specify the -m option > > > > > to useradd. It isn't done by default. > > > > > > > > Users might further decide they use a .bashrc from a different > > > > system, or to clean all percieved cruft from the > > > > .bashrc/.bash_profile. Having a sane default is probably better. > > > > I was just arguing why one should not keep XSESSION in .bashrc only, and > > rely on skel. It's too easy to break. > > > > Paul > > > > -- > > Paul de Vrieze > > Gentoo Developer > > Mail: [EMAIL PROTECTED] > > Homepage: http://www.devrieze.net > > > > -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: /etc/rc.conf
What about env.d? Gnome could install and env file that by default sets XSESSION to gnome. On 2/13/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote: > On Monday 13 February 2006 13:19, Forrest Voight wrote: > > Why doesn't it make sense to split DISPLAYMANAGER and XSESSION up? > > They are related, but in different contexts. XSESSION is for the user > > and DISPLAYMANAGER is used at boot time. > > > > On 2/13/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > > On Monday 13 February 2006 03:33, Donnie Berkholz wrote: > > > > And even then, it's only copied over when you specify the -m option > > > > to useradd. It isn't done by default. > > > > > > Users might further decide they use a .bashrc from a different > > > system, or to clean all percieved cruft from the > > > .bashrc/.bash_profile. Having a sane default is probably better. > > I was just arguing why one should not keep XSESSION in .bashrc only, and > rely on skel. It's too easy to break. > > Paul > > -- > Paul de Vrieze > Gentoo Developer > Mail: [EMAIL PROTECTED] > Homepage: http://www.devrieze.net > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 47: Creating 'safe' environment variables
I've made some modifications to the GLEP, see:
http://www.gentoo.org/proj/en/glep/glep-0047.html
The modifications are based on all comments raised on the previous
version.
Many pieces rewritten, reworded and explained in more detail.
- clarified 'safeness' of CHOST variable
- note on USE-expansion variables and use of variables separate +
example
- defined semantics env-map file interpreter
- defined requirements for env-map file expressiveness
- added precise specification of allowed characters in keywords
Constructive comments are welcome.
On 09-02-2006 22:48:32 +0100, Grobian wrote:
> Please find attached GLEP 47: "Creating 'safe' environment variables".
>
> The GLEP is a Gentoo/Alt initiative. Constructive comments are welcome.
--
Fabian Groffen
Gentoo/Alt
GLEP: 47
Title: Creating 'safe' environment variables
Version: $Revision: 1.4 $
Last-Modified: $Date: 2006/02/13 21:00:50 $
Author: Diego Pettenò, Fabian Groffen
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 14-Oct-2005
Post-History: 09-Feb-2006
Credits
===
The text of this GLEP is a result of a discussion and input of the
following persons, in no particular order: Mike Frysinger, Diego
Pettenò, Fabian Groffen and Finn Thain.
Abstract
In order for ebuilds and eclasses to be able to make host specific
decisions, it is necessary to have a number of environmental variables
which allow for such decisions. This GLEP introduces some measures that
need to be made to make these decisions 'safe', by making sure the
variables the decisions are based on are 'safe'. A small overlap with
GLEP 22 [1]_ is being handled in this GLEP where the use of 2-tuple
keywords are being kept instead of 4-tuple keywords. Additionally, the
``ELIBC``, ``KERNEL`` and ``ARCH`` get auto filled starting from
``CHOST`` and the 2-tuple keyword, instead of solely from they 4-tuple
keyword as proposed in GLEP 22.
The destiny of the ``USERLAND`` variable is out of the scope of this
GLEP. Depending on its presence in the tree, it may be decided to set
this variable the same way we propose to set ``ELIBC``, ``KERNEL`` and
``ARCH``, or alternatively, e.g. via the profiles.
Motivation
==
The Gentoo/Alt project is in an emerging state to get ready to serve a
plethora of 'alternative' configurations such as FreeBSD, NetBSD,
DragonflyBSD, GNU/kFreeBSD, Mac OS X, (Open)Darwin, (Open)Solaris and so
on. As such, the project is in need for a better grip on the actual
host being built on. This information on the host environment is
necessary to make proper (automated) decisions on settings that are
highly dependant on the build environment, such as platform or C-library
implementation.
Rationale
=
Gentoo's unique Portage system allows easy installation of applications
from source packages. Compiling sources is prone to many environmental
settings and availability of certain tools. Only recently the Gentoo
for FreeBSD project has started, as second Gentoo project that operates
on a foreign host operating system using foreign (non-GNU) C-libraries
and userland utilities. Such projects suffer from the current implicit
assumption made within Gentoo Portage's ebuilds that there is a single
type of operating system, C-libraries and system utilities. In order to
enable ebuilds -- and also eclasses -- to be aware of these
environmental differences, information regarding it should be supplied.
Since decisions based on this information can be vital, it is of high
importance that this information can be trusted and the values can be
considered 'safe' and correct.
Backwards Compatibility
===
The proposed keywording scheme in this GLEP is fully compatible with the
current situation of the portage tree, this in contrast to GLEP 22. The
variables provided by GLEP 22 can't be extracted from the new keyword,
but since GLEP 22-style keywords aren't in the tree at the moment, that
is not a problem. The same information can be extracted from the CHOST
variable, if necessary. No modifications to ebuilds will have to be
made.
Specification
=
Unlike GLEP 22 the currently used keyword scheme is not changed.
Instead of proposing a 4-tuple [2]_ keyword, a 2-tuple keyword is chosen
for archs that require them. Archs for which a 1-tuple keyword
suffices, can keep that keyword. Since this doesn't change anything to
the current situation in the tree, it is considered to be a big
advantage over the 4-tuple keyword from GLEP 22. This GLEP is an
official specification of the syntax of the keyword.
Keywords will consist out of two parts separated by a hyphen ('-'). The
part up to the first hyphen from the left of the keyword 2-tuple is the
architecture, such as ppc64, sparc and x86. Allowed characters for the
architecture name are in ``a-z0-9``. The remaining part on the right of
the first hyphen from the left indicates the operating system or
distribution, such as linux, macos, darwin, obsd, et-
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On 13-02-2006 21:02:28 +0100, Carsten Lohrke wrote: > On Monday 13 February 2006 20:29, Grobian wrote: > > Maybe that has to change then? Like getting more bug wranglers that > > also handle canned responses as a first-line helpdesk? > > Wrangle bugs a few months and you'll see how hard it can be to stay friendly > sometimes... That's what I said two posts ago. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On Monday 13 February 2006 20:29, Grobian wrote: > Maybe that has to change then? Like getting more bug wranglers that > also handle canned responses as a first-line helpdesk? Wrangle bugs a few months and you'll see how hard it can be to stay friendly sometimes... And no, bugzilla is not a helpdesk. We have mailing lists and forums.g.o for this. btw.: I think the idea to give someone credit for requesting a version bump is pretty much ridiculous. There're helpful requests/bug reports, where credit is due, but the usual case of a request for a new version isn't. Carsten pgpRt7TKZBV5m.pgp Description: PGP signature
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On Monday 13 February 2006 19:49, Ciaran McCreesh wrote: > They also deserve it if they stick it in their CXXFLAGS... In that case even more, as it actually does something: break stuff. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpfahXwtGVQg.pgp Description: PGP signature
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On 13-02-2006 19:21:57 +, Ciaran McCreesh wrote: > On Mon, 13 Feb 2006 20:07:51 +0100 Grobian <[EMAIL PROTECTED]> wrote: > | If these frustrations get so apparent that they require a solution > | flag in Bugzilla for a developer, then it might be a better solution > | to just leave the bugzilla work to someone else and try to work a bit > | more away from the users for a while. > > Most of us don't have the luxury of being able to ignore real users... Maybe that has to change then? Like getting more bug wranglers that also handle canned responses as a first-line helpdesk? -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On Mon, 13 Feb 2006 20:07:51 +0100 Grobian <[EMAIL PROTECTED]> wrote: | If these frustrations get so apparent that they require a solution | flag in Bugzilla for a developer, then it might be a better solution | to just leave the bugzilla work to someone else and try to work a bit | more away from the users for a while. Most of us don't have the luxury of being able to ignore real users... -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Bugzilla etiquette suggestions
Ciaran McCreesh wrote: > On Sun, 12 Feb 2006 23:32:39 + Daniel Drake <[EMAIL PROTECTED]> wrote: > | It may feel a little harsh to give someone a canned response just by > | pasting a URL in the comment field, but curious readers will find his > | faq.txt which explains nicely that we aren't evil/lazy, we just have > | a lot of work to do. Thanks Ciaran! > > And some users throw a hissy fit when given a detailed link to a canned > response and demand that in future they get personally typed out > explanations rather than a link to a detailed pre-written resource that > goes into far more depth than anyone could possibly manage in a > personalised response. Hence why I no longer spend much time helping in > maintainer-wanted bugs unless a submitter specifically asks me to take > a look at something for them -- all it takes is for one user to escalate > their hissy fit to a devrel bug... > > Oh, and don't think that this behaviour is limited to end users. Sadly > the same thing has been observed in certain Gentoo developers. Perhaps pasting the response into the bug itself would prevent most of this. It just takes a few seconds, but feels more personal. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On 13-02-2006 18:49:18 +, Ciaran McCreesh wrote: > On Mon, 13 Feb 2006 19:39:06 +0100 Simon Stelling <[EMAIL PROTECTED]> > wrote: > | NOTABUG sounds good, but as Ciaran said, we need another replacement > | for those bugs who really deserve it. If a user sticks > | -fvisibility=hidden into his CFLAGS (instead of CXXFLAGS), > | PLEASEGOAWAYKTHXBYE would be much more appropriate. > > They also deserve it if they stick it in their CXXFLAGS... I don't agree on such solution, because getting rid of personal frustrations of a developer should *not* be supported by Gentoo's Bugzilla. These kind of emotions give a rather weak signal, and do not really show any kind of profesionalism IMHO. If these frustrations get so apparent that they require a solution flag in Bugzilla for a developer, then it might be a better solution to just leave the bugzilla work to someone else and try to work a bit more away from the users for a while. It is a well known issue that people who have to work with others get frustrated (e.g. call-center employees). -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On Mon, Feb 13, 2006 at 02:00:48PM -0500, Patrick McLean wrote: > > How about RICER or RICERFLAGS :) +1. "RESOLVED RICER" has such a nice ring to it :) -- Marien. pgp70IcstDKz0.pgp Description: PGP signature
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Mon, 13 Feb 2006 19:39:06 +0100 Simon Stelling <[EMAIL PROTECTED]> > wrote: > | Are you being serious about this? > > Sadly, even if he is, there're enough people around here that're taking > that kind of thought seriously (see, for example, my sarcastic post on > the 0day -core thread that so many people took as genuine)... > > | NOTABUG sounds good, but as Ciaran said, we need another replacement > | for those bugs who really deserve it. If a user sticks > | -fvisibility=hidden into his CFLAGS (instead of CXXFLAGS), > | PLEASEGOAWAYKTHXBYE would be much more appropriate. > > They also deserve it if they stick it in their CXXFLAGS... > How about RICER or RICERFLAGS :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD8NdgWt/XSf2CZdkRAlUQAJ99NlKvRVK3zvqX+R8iZH07LvTpoACfS+sW EtylhPAKUZ9qaxm6Jv3o1gk= =UDkC -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On Mon, 13 Feb 2006 19:39:06 +0100 Simon Stelling <[EMAIL PROTECTED]> wrote: | Are you being serious about this? Sadly, even if he is, there're enough people around here that're taking that kind of thought seriously (see, for example, my sarcastic post on the 0day -core thread that so many people took as genuine)... | NOTABUG sounds good, but as Ciaran said, we need another replacement | for those bugs who really deserve it. If a user sticks | -fvisibility=hidden into his CFLAGS (instead of CXXFLAGS), | PLEASEGOAWAYKTHXBYE would be much more appropriate. They also deserve it if they stick it in their CXXFLAGS... -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
Duncan wrote: > Consider this: INVALID is strong enough, under the wrong circumstances, > that it /could/ set an emotionally unstable user off, causing them to > commit suicide or something. I /know/ it was deeply depressing here, > that first time, altho the effect on me would have been to simply push me > back to Mandrake and cause me to become another anti-Gentoo activist, as I > wasn't already suicidal. Some people /might/ be! One never knows the > emotional state of someone filing a bug, so consider carefully the effect > INVALIDating the bug might possibly have on their entire life. Would > /you/ want that on your conscience, that it had been /your/ action, the > marking of that one last bug they filed as INVALID, that finally tipped > them over? I know I wouldn't! Are you being serious about this? I dont' find it particularly funny in case it's a joke. In case it's not, i find it ridiculous. If a person is that emotionally unstable that he'd commit suicide because of an INVALID resolution, he'd probably commit suicide everytime only the slightest negative event occurs too. I really feel sorry for those people who are depressive, but I wouldn't feel guilty because I closed a bug as INVALID instead of WORKSFORME. > Obviously, I like the idea of NOTABUG better, or consider using WORKSFORME > or WONTFIX. Those get the same general message across, without having the > implication of INVALIDating the user's bug, possibly/likely conveying the > message that they are not welcome as a Gentoo user, or worse yet to > someone already unstable, that their whole life is INVALID. NOTABUG sounds good, but as Ciaran said, we need another replacement for those bugs who really deserve it. If a user sticks -fvisibility=hidden into his CFLAGS (instead of CXXFLAGS), PLEASEGOAWAYKTHXBYE would be much more appropriate. -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On 2/13/06, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > But... If INVALID is renamed, could we get a new GOAWAY resolution for > people who really deserve it? I would tend to agree with this. I myself was the 'victim' of an aggressively worded INVALID resolution to a bug report I filed due to my screwing up an upgrade to java 1.5. Even though I didn't particularly /like/ the response, I did learn that: 1. It was my own fault. 2. I needed to be really damn sure about future bug reports, particularly when I unmask things! So even if INVALID is watered down to be gentle to new (or easily offended) users, you do occasionally need to smack abusers or people who should know better (like me). -Richard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: Bugzilla etiquette suggestions
Daniel Drake posted <[EMAIL PROTECTED]>, excerpted below, on Mon, 13 Feb 2006 16:11:51 +: > Duncan wrote: >> I'd /not/ really wish to encourage version bump requests "overnight". >> That's jumping the gun, and indeed, could encourage "first post" like >> behavior. >> > That is precisely what was being discussed on the private list which > prompted me to finish off this post and publish it. > > One point I was trying to make (as Mike and myself suggested on the > private list) is that if you *do* receive a bump request too soon after > release, then you ask the user nicely to wait 1 week (or whatever) after > release in the future before filing bump requests. > > You should *also* leave the bug open until the ebuild is in portage, > then mark the bug as FIXED in the normal way, *and* you thank them by > name in the commit message. > > By showing them some basic respect for the fact they were trying to > contribute, hopefully they will understand your position better and take > up your advice. WORKSFORME =8^) -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla etiquette suggestions
Diego 'Flameeyes' Pettenò wrote: In amaroK's case, anyway, there's no problem to know if it has relesed: upstream releases always in time, providing packagers with candidates to release, allowing to prepare stuff before actual release.. the release is also broadcasted in their homepage, on [EMAIL PROTECTED], on KDE-Apps, on kde-extra-gear mailing list, usually on Planet KDE, too Really, I don't need bugs to remember me to bump it. Mostly the same for k3b.. it's released and then announced on kde-extra-gear, KDE-Apps, SourceForge, .. I can be very thankful if someone would let me know when ALSA gets released as the upstream send mail to -announce once in a blue moon instead.. After contributing to the suggestions on -core I forgot to explain myself very clearly on this point. I'm not suggesting a mechanism for handling or encouraging "0-day" bump requests - I'm giving a suggestion which I believe will help *reduce* those requests. By leaving a nice comment (asking that they give us a little more room to breathe in future) *and* crediting the user, maybe they will take your advice to heart. It's not up to the user to know how closely the maintainer tracks the upstream release (or even who the maintainer is in the first place), but in general we prefer to be left for a week or so before being notified via Gentoo bugzilla, right? I try to explain why I did some changes before committing or why I didn't use a given fix usually, I also try to provide documentation of what I do and why I do it that way (see maintainers' guides, that nobody else seems to want). OK - thats a good compromise if you can't afford to spend the full amount of time guiding the user through it. I have never heard of your maintainer guides before but will check them out now. If I start thinking "this bug I'll fix later and provide just pointers to users, I'm sure I'm going to forget about it. I actually did that already :) Fair enough - I guess it depends on your workflow. Perhaps you could just try this for a couple of bugs: reassign them to yourself and leave the appropriate comments,then observing the users reaction. That way the bug is hard to lose since it is on your "My Bugs" list. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
Duncan wrote: I'd /not/ really wish to encourage version bump requests "overnight". That's jumping the gun, and indeed, could encourage "first post" like behavior. What I'd do with such bugs is thank the user, but say next time, please give me a few days, at least a week (or whatever a dev feels comfortable with for that package, again, it'll vary) -- if it's /just/ a bump request. That is precisely what was being discussed on the private list which prompted me to finish off this post and publish it. One point I was trying to make (as Mike and myself suggested on the private list) is that if you *do* receive a bump request too soon after release, then you ask the user nicely to wait 1 week (or whatever) after release in the future before filing bump requests. You should *also* leave the bug open until the ebuild is in portage, then mark the bug as FIXED in the normal way, *and* you thank them by name in the commit message. By showing them some basic respect for the fact they were trying to contribute, hopefully they will understand your position better and take up your advice. You can argue that that *may* encourage "overnight" bump requests (which certainly isn't the intention), but in practice I think that won't happen too much if you treat the contributor in the proper manner. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Portage staging question
I am contemplating the migration of all of my source code management from a hacked up in-house system to subversion. I currently use overlays to house ebuilds and install the actual packages on my target systems. Instead of re-inventing the wheel, I would like to implement as much as possible the same tools that gentoo is using to maintain my overlays. What I have not been able to find in the various gentoo developer documents/blogs is certain higher level particulars. For example, what tool is used by gentoo to generate the staged cvs sources to the actual mirrors? What, if any, pre/post-commit scripts are used by the gentoo cvs system? If anyone can point me to the pertinent documentation or sources, it would be highly appreciated. pgp0UpqOf8j50.pgp Description: PGP signature
Re: [gentoo-dev] where to install source files for c++ templates
On Monday 13 February 2006 15:38, William Hubbs wrote: > All, > > I am working on version bumping app-accessibility/festival and > app-accessibility/speech-tools. > > I can get them to build outside an ebuild fine, but I have found that > festival #includes actual source files from speech-tools to instantiate > c++ templates. > > If I keep speech-tools as a separate package, where should these source > files be installed in the file system? /usr/share/speech-tools? > > The other option would be to not keep speech-tools as a separate > ebuild, but have the festival ebuild build speech-tools then build and > install festival. > > Any suggestions would be appreciated. Templates should be defined in header files as they need to be evaluated at usage time. Aparently those tools didn't really get that and made them .cpp files. Treat them as header files anyway, because they should be, and have to be included as header files, regardless of the name. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpfbX4Ec1CIV.pgp Description: PGP signature
Re: [gentoo-dev] where to install source files for c++ templates
William Hubbs <[EMAIL PROTECTED]> wrote: > I can get them to build outside an ebuild fine, but I have found that > festival #includes actual source files from speech-tools to > instantiate c++ templates. [snip] > The other option would be to not keep speech-tools as a separate > ebuild, but have the festival ebuild build speech-tools then build and > install festival. Consider this: Build and install speech-tools as you normally do. Write the ebuild for festival such that it requires and unpacks all the source that it needs, including the source for speech-tools. I figure that should work, unless festival needs the speech-tools source after installation. -- That is not dead which can eternal lie, And with strange eons even death may die. -- The Call of Cthulu, II. The Tale of Inspector Legrasse pgpbmTYYgMR0r.pgp Description: PGP signature
Re: [gentoo-dev] where to install source files for c++ templates
On Mon, 13 Feb 2006 08:38:39 -0600 William Hubbs <[EMAIL PROTECTED]> wrote: | I can get them to build outside an ebuild fine, but I have found that | festival #includes actual source files from speech-tools to | instantiate c++ templates. | | If I keep speech-tools as a separate package, where should these | source files be installed in the file | system? /usr/share/speech-tools? No. /usr/include/speech-tools. Treat them as header files. Have a look at libebt for an example. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
[gentoo-dev] where to install source files for c++ templates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, I am working on version bumping app-accessibility/festival and app-accessibility/speech-tools. I can get them to build outside an ebuild fine, but I have found that festival #includes actual source files from speech-tools to instantiate c++ templates. If I keep speech-tools as a separate package, where should these source files be installed in the file system? /usr/share/speech-tools? The other option would be to not keep speech-tools as a separate ebuild, but have the festival ebuild build speech-tools then build and install festival. Any suggestions would be appreciated. William -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD8JnvblQW9DDEZTgRAukLAJ0X7VbH84N/PeJ/4Em8imOrohUs4ACfSmKc 6NklAdfappcX6NyVZ5AtYsU= =pcsG -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: /etc/rc.conf
On Monday 13 February 2006 13:19, Forrest Voight wrote: > Why doesn't it make sense to split DISPLAYMANAGER and XSESSION up? > They are related, but in different contexts. XSESSION is for the user > and DISPLAYMANAGER is used at boot time. > > On 2/13/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > On Monday 13 February 2006 03:33, Donnie Berkholz wrote: > > > And even then, it's only copied over when you specify the -m option > > > to useradd. It isn't done by default. > > > > Users might further decide they use a .bashrc from a different > > system, or to clean all percieved cruft from the > > .bashrc/.bash_profile. Having a sane default is probably better. I was just arguing why one should not keep XSESSION in .bashrc only, and rely on skel. It's too easy to break. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpGkH146Y4Oq.pgp Description: PGP signature
[gentoo-dev] Re: /etc/rc.conf
Why doesn't it make sense to split DISPLAYMANAGER and XSESSION up? They are related, but in different contexts. XSESSION is for the user and DISPLAYMANAGER is used at boot time. On 2/13/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote: > On Monday 13 February 2006 03:33, Donnie Berkholz wrote: > > > > And even then, it's only copied over when you specify the -m option to > > useradd. It isn't done by default. > > Users might further decide they use a .bashrc from a different system, or > to clean all percieved cruft from the .bashrc/.bash_profile. Having a > sane default is probably better. > > Paul > > -- > Paul de Vrieze > Gentoo Developer > Mail: [EMAIL PROTECTED] > Homepage: http://www.devrieze.net > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla etiquette suggestions
On Monday 13 February 2006 00:24, Daniel Drake wrote: > Maybe not if you have already done the work. I was thinking more of the > scenario, upstream does a release. You are on the mailing list so you > know about the new version. You decide you'll bump it in portage tomorrow. > > Overnight, someone files a request for a version bump. Maybe they attach > a new ebuild or state that the existing one needs bumping. This is a scenario quite good... if it wasn't that at least myself I see it rarely :) Rarely because if I see a bump, I'm already starting testing it usually. Yesterday I finished amaroK's bump while I was eating dinner :P In amaroK's case, anyway, there's no problem to know if it has relesed: upstream releases always in time, providing packagers with candidates to release, allowing to prepare stuff before actual release.. the release is also broadcasted in their homepage, on [EMAIL PROTECTED], on KDE-Apps, on kde-extra-gear mailing list, usually on Planet KDE, too Really, I don't need bugs to remember me to bump it. Mostly the same for k3b.. it's released and then announced on kde-extra-gear, KDE-Apps, SourceForge, .. I can be very thankful if someone would let me know when ALSA gets released as the upstream send mail to -announce once in a blue moon instead.. > That is a fair point, and if you can't afford to spend the time on it > then I'm not complaining. However, there are situations where this can > *save* you time. I try to explain why I did some changes before committing or why I didn't use a given fix usually, I also try to provide documentation of what I do and why I do it that way (see maintainers' guides, that nobody else seems to want). But really, if I get a bug for a thing to be fixed, I try to fix it right away... sometimes if I don't have time in that moment I leave a comment telling where or what to look for..not like there's always someone ready to fix :) If I start thinking "this bug I'll fix later and provide just pointers to users, I'm sure I'm going to forget about it. I actually did that already :) -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpaCy0O4P7CY.pgp Description: PGP signature
Re: [gentoo-dev] Re: Duplicated entries in use.desc and use.local.desc
Le Sun, 12 Feb 2006 23:28:05 -0500, Mark Loeser <[EMAIL PROTECTED]> a écrit : > By allowing duplicate entries we just allow people to put useless > information in two places instead of one. > Maybe i'm a bit naive, but that sounds very pessimistic to me. I would rather think that devs who will add a use.local.desc entry for a global flag and their package will only do it when they have something more useful than the default "Adds foobar support" to say. Otherwise, why would they do so? -- TGL. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Duplicated entries in use.desc and use.local.desc
Le Sun, 12 Feb 2006 21:39:22 -0600,
R Hill <[EMAIL PROTECTED]> a écrit :
> TGL did some work on this under bug #84884, though his changes are
> more invasive than what i had in mind. I don't see the need for
> portage to dig through use.*desc when euse already works and equery
> can pretty easily be made to.
If this "special" USE descriptions (the one in use.local.desc when the
flag is also global) are allowed, then it's in "emerge -pv" output
that displaying them is the most useful. Nobody wants to manually call
euses for each package he's about to emerge/update just in case one of
the well known flags they use has a special description. That's
something that should simply come to his attention when it's the case,
it's much easier this way.
IIRC, the behavior of my patch was that when the "--use-desc-special"
option was used, and some packages/flags in the list had special
descriptions, the relevant informations were displayed at the end of
the usual output:
% emerge -puvD --use-desc-special world
...
[ebuild U ] net-ftp/pure-ftpd-1.0.20-r2 -caps -ldap mysql pam
-postgres ssl -vchroot
[ebuild U ] ...
...
These USE flags have a package-specific description:
pure-ftpd:mysql - Allow storing accounts infos in a MySQL DB
...
Note that this patch doesn't makes portage diging through use.*desc when
this option is not used.
As for the two other patches (repoman and equery), it was just some code
cleanup (remove their own duplicate implementation of use*.desc parsers,
to replace it with some shared code).
> Anyways I just like anything that makes use.desc more useful than
>
> foo - adds support for foo
In many cases, you just can't give a better description for a global
flag, because it has two much different purposes depending on the
context (the package using it).
Take the "mysql" flag, i think it's a typical example of global flag
with different meanings: many users will enable it thinking of the PHP
bindings, whereas they don't care about using a MySQL DB to store
their FTP accounts or their music collection metadatas.
Or even take some less widely used flags, like "sqlite3"; on just six
packages using it, it can be:
- add sqlite support (which happens to be v3 only)
- add support for sqlite3 (may be in addition to the v2 controlled by
the "sqlite" flag)
- use sqlite3 for backend (but v2 has priority if "sqlite" is enabled)
- use sqlite3 for backend (and die if "sqlite" is enabled too)
Again, the global description ("Adds support for sqlite3") is vague
enough to seem ~correct in all cases, but actually gives no clue about
what turning on the flag means.
--
TGL.
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Bugzilla etiquette suggestions
Daniel Drake posted <[EMAIL PROTECTED]>, excerpted below, on Sun, 12 Feb 2006 23:24:45 +: > Henrik Brix Andersen wrote: [Danial Drake wrote...] >>> 3. Always record contributions by name >>> >>> If you commit something in response to a bug report that has been filed, >>> always thank the user by full name (and bug number) in the ChangeLog and >>> commit message. >>> >>> This also applies for [...] version bump requests/submissions. Might >>> sound pointless for 'trivial' reports/requests but it is important to >>> credit the user if they have gone to the trouble of filing a bug. >> >> I don't really get this part. Why should I give credit to someone else >> for providing a fix for a bug which I already fixed myself locally? > > Maybe not if you have already done the work. I was thinking more of the > scenario, upstream does a release. You are on the mailing list so you > know about the new version. You decide you'll bump it in portage > tomorrow. > > Overnight, someone files a request for a version bump. Maybe they attach > a new ebuild or state that the existing one needs bumping. > > Even though you knew about it, I was suggesting that you credit the user > for filing the bug. I don't recall where I read it, but it sounded reasonable to me then, and deals with a possible issue, so I'll repeat it. Somewhere I read a recommendation for bump requests, addressed to users thinking of making one, suggesting that they give the devs a week or two to do the bump themselves, as they likely know about it because they are following the list for that app, since they are the Gentoo maintainer for it, and just need time to get something worked up and tested locally. If after two weeks, the bump isn't in portage, /then/ it's time to post the bug about it. Now, two weeks may be a bit long, but I'd say a week, anyway, of course depending on the app (something big like gcc or gnome/kde bumps would be different, but they are often in the tree even before the package is publicly released and sources publicly available -- good job!). I'd /not/ really wish to encourage version bump requests "overnight". That's jumping the gun, and indeed, could encourage "first post" like behavior. What I'd do with such bugs is thank the user, but say next time, please give me a few days, at least a week (or whatever a dev feels comfortable with for that package, again, it'll vary) -- if it's /just/ a bump request. If I take over a week (or whatever), then maybe I need reminding, so let me know! OTOH, if the bug includes "I tried bumping the last ebuild to use the new sources and it worked fine", or "... and it broke at ", that's far more valuable than just a bump request, and I'd treat it so. (In fact, that sounds like possible AT/HT material, maybe ultimately leading to a new dev, to me.) -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: /etc/rc.conf
On Monday 13 February 2006 03:33, Donnie Berkholz wrote: > > And even then, it's only copied over when you specify the -m option to > useradd. It isn't done by default. Users might further decide they use a .bashrc from a different system, or to clean all percieved cruft from the .bashrc/.bash_profile. Having a sane default is probably better. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgptggFYcJHDe.pgp Description: PGP signature
Re: [gentoo-dev] Bugzilla etiquette suggestions
On Sun, 12 Feb 2006 23:32:39 + Daniel Drake <[EMAIL PROTECTED]> wrote: | It may feel a little harsh to give someone a canned response just by | pasting a URL in the comment field, but curious readers will find his | faq.txt which explains nicely that we aren't evil/lazy, we just have | a lot of work to do. Thanks Ciaran! And some users throw a hissy fit when given a detailed link to a canned response and demand that in future they get personally typed out explanations rather than a link to a detailed pre-written resource that goes into far more depth than anyone could possibly manage in a personalised response. Hence why I no longer spend much time helping in maintainer-wanted bugs unless a submitter specifically asks me to take a look at something for them -- all it takes is for one user to escalate their hissy fit to a devrel bug... Oh, and don't think that this behaviour is limited to end users. Sadly the same thing has been observed in certain Gentoo developers. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Bugzilla etiquette suggestions
On Sun, 12 Feb 2006 15:53:37 -0700 Duncan <[EMAIL PROTECTED]> wrote: | Consider this: INVALID is strong enough, under the wrong | circumstances, that it /could/ set an emotionally unstable user off, | causing them to commit suicide or something. Some people go around setting fire to embassies when they don't understand a joke. Doesn't mean we should care about or cater to such people. INVALID doesn't necessarily mean it was wrong for the user to file the bug. Heck, I've closed the occasional bug as INVALID (and sometimes have even had the reporter do it) after massive debugging sessions and discussions that go on for dozens of pages. But... If INVALID is renamed, could we get a new GOAWAY resolution for people who really deserve it? -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Bugzilla etiquette suggestions
On Mon, 13 Feb 2006 00:57:33 + (UTC) Ferris McCormick <[EMAIL PROTECTED]> wrote: | Well, the user did the work, too, and doesn't know that you did it | (if I understand your case correctly). So the user deserves as much | credit as you do. What? No, that's silly. The one who does the work gets the credit. If you take all or a significant part of a user contribution, credit the user. If you don't use the user contribution because their proposed fix is lousy (a rather too common occurrence...), they just get credit for reporting the issue. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
