Re: [gentoo-dev] RFC: remove php4 from depend.php and others
On 07/10/2010 01:22 AM, Matti Bickel wrote: Hi, yet another patch from Ole in a bid to rid the php eclasses from some long forgotten code. The patches should be self-explanatory - just rip out everything related to dev-php4 :) Comments welcome. The standing policy is still not to remove any public functionality from eclasses. If we decide to start removing functionality the council should set common rules for it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: remove php4 from depend.php and others
On Sat, Jul 10, 2010 at 09:30:42AM +0300, Petteri RRRty wrote: On 07/10/2010 01:22 AM, Matti Bickel wrote: Hi, yet another patch from Ole in a bid to rid the php eclasses from some long forgotten code. The patches should be self-explanatory - just rip out everything related to dev-php4 :) Comments welcome. The standing policy is still not to remove any public functionality from eclasses. If we decide to start removing functionality the council should set common rules for it. Just adding a note on this one- the original technical reason for this policy (portage inability to run from just the saved env dump) is no longer an issue. If people want to allow eclasses to have fluid APIs (specifically removal of functionality), that's a discussion that needs to start on the dev level. Anyone got strong opinions on this one? ~brian pgpfuMWOFCFYA.pgp Description: PGP signature
Re: Allow eclasses to have fluid APIs (was: [gentoo-dev] RFC: remove php4 from depend.php and others)
On 07/10/2010 10:34 AM, Brian Harring wrote: If people want to allow eclasses to have fluid APIs (specifically removal of functionality), that's a discussion that needs to start on the dev level. Anyone got strong opinions on this one? The argument was presented a long time before: we can't care about things not in our tree, there might be thousands of twisted ways our eclasses are used we can't control. If nothing is broken in gentoo-x86, we as developers should be allowed to make the change. To ensure the change is indeed not breaking stuff, RFCs to -dev are a requirement. Everybody who copied and re-used our eclasses should be reading -dev (or at least -dev-announce), anyway. Not our fault if they run an open system (as in, I've not nailed all my versions down and use a static tree) and do not keep up with it. Now, I'm aware that RFC and implementation periods should depend on the impact of the change - if I'm proposing to alter eutils, I better wait some time AFTER a conclusion has been reached, so everybody can adapt. That 'should' above is intentional - prescribing a fixed time period for every possible change does not give devs enough flexibility and implementation time may be a subject during RFC anyway. To continue the eutils example: if I keep a custom overlay which depends on the removed functionality, I will speak up and ask you defer the change 14 days so I can fix my overlay. Similarly, if somebody still uses the php4 bits in depend.php eclass, please speak up and allow me to convince you of the php5 ways :-) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eqawarn for main tree
On 07/05/2010 09:19 PM, Mark Loeser wrote: As there was no further response and next EAPI isn't around the corner I propose getting the ball rolling with option 1. I will commit the patch next Sunday with needed documentation unless something comes up. Could you please give a description as to when you believe this function should be used. Preferably as a patch for devmanual :) Thanks, Attached is the patch I plan on pushing with the eclass commit. Regards, Petteri diff --git a/ebuild-writing/messages/text.xml b/ebuild-writing/messages/text.xml index 4720be4..2bb348a 100644 --- a/ebuild-writing/messages/text.xml +++ b/ebuild-writing/messages/text.xml @@ -95,6 +95,19 @@ is mainly used for displaying additional error details before bailing out. /section section +titleQA warnings/title +body + +p + The ceqawarn/c function can be used by eclass authors to notify ebuild writers about + deprecated functionality. eqawarn is defined in eutils. Portage doesn't log the qa message + class by default so users don't get annoyed by seeing messages they can't do much about. +/p + +/body +/section + +section titleMessage function reference/title body diff --git a/function-reference/message-functions/text.xml b/function-reference/message-functions/text.xml index 97c86e6..24f4b82 100644 --- a/function-reference/message-functions/text.xml +++ b/function-reference/message-functions/text.xml @@ -77,9 +77,9 @@ displaying informational messages. /table p - The following are available from ceutils.eclass/c in EAPIs 0, 1 and 2. - They are deprecated in favor of GLEP 42 news items and package manager - message logging functionality. + The following are available from ceutils.eclass/c . ebeep and epause + are deprecated in EAPIS 0, 1 and 2 in favor of GLEP 42 news items and + package manager message logging functionality. /p table @@ -108,6 +108,14 @@ displaying informational messages. Beep the specified number (must be a positive integer) of times. Defaults to a sane value. /ti /tr + tr +ti + ceqawarn/c +/ti +ti + Used by eclass authors to notify ebuild writers that they are using deprecated functionality. +/ti + /tr /table p signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [bugzilla-dae...@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]
* Robin H. Johnson robb...@gentoo.org schrieb: Hi, It's an improved version of procmail, which automatically creates missing maildir directories. Stock procmail does this already. From procmailrc: If the mailbox is specified to be an MH folder or maildir folder, procmail will create the necessary directories if they don't exist, rather than treat the mail??? box as a non-existent filename. Only applies to maildir mailboxes, not mbox. The problem is: if you have mbox'es in subdirs which dont exist yet, procmail fails. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-dev] svga useflag (media-libs/svgalib)
* Tomá?? Chvátal scarab...@gentoo.org schrieb: Hi, there are few left packages that still have svga useflag and depend on svgalib. To my best knowledge that stuff has been deprecated to not be used. So my question is which one of the following we should start: Well, if there still are packages where libsvga stuff works, it IMHO should stay. Nobody knows who's still using it. But it probably doesnt have to be a global useflag. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-dev] [bugzilla-dae...@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]
* Samuli Suominen ssuomi...@gentoo.org schrieb: On 07/08/2010 01:56 AM, Enrico Weigelt wrote: Hi folks, YFYI: yet another of my ebuilds kicked-down. It's an improved version of procmail, which automatically creates missing maildir directories. Provide your patches as plain/text attachments like everyone else does, I've already explained the strategy behind the git repo (and not doing plaintext patches). Please refer to my paper, and my other mails posted recently on this list. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
[gentoo-dev] RFC: making revdep-rebuild more quiet
Hi folks, i'd like to suggest an option for making revdep-rebuild more silent: Passing -q twice should make it output only if it really has something to do (found broken stuff and wants to emerge), so we can simply put it into an crontab entry to get a mail when something really happens. What do you think about this ? (I admit, I didnt have the time to dive into portage codebase yet and hack up something ... ;-o) cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-dev] eqawarn for main tree
On 7/10/10 4:15 AM, Petteri Räty wrote: Attached is the patch I plan on pushing with the eclass commit. Just making sure... will the developer profile print the eqawarn messages by default on exit? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eqawarn for main tree
On 07/10/2010 08:40 PM, Paweł Hajdan, Jr. wrote:
On 7/10/10 4:15 AM, Petteri Räty wrote:
Attached is the patch I plan on pushing with the eclass commit.
Just making sure... will the developer profile print the eqawarn
messages by default on exit?
Doesn't look like it. I use this in my make.conf:
PORTAGE_ELOG_SYSTEM=${PORTAGE_ELOG_SYSTEM} echo:qa save:qa
Probably someone who maintains developer profiles (if such a person
exists) can add something like that there after testing.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: making revdep-rebuild more quiet
Hey Enrico, On 07/10/2010 06:21 PM, Enrico Weigelt wrote: i'd like to suggest an option for making revdep-rebuild more silent: Passing -q twice should make it output only if it really has something to do (found broken stuff and wants to emerge), so we can simply put it into an crontab entry to get a mail when something really happens. What do you think about this ? I've already started to improve the quiet part of revdep-rebuild take a look at http://bugs.gentoo.org/97073#c11 -- Regards, Christian Ruppert Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: 9B50 01DF E873 A0E4 126D 6C16 8B17 B68E 7FAE 7D38 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: RFC: remove php4 from depend.php and others
On Sat, 10 Jul 2010 01:34:37 -0700
Brian Harring ferri...@gmail.com wrote:
On Sat, Jul 10, 2010 at 09:30:42AM +0300, Petteri RRRty wrote:
The standing policy is still not to remove any public functionality from
eclasses. If we decide to start removing functionality the council
should set common rules for it.
Just adding a note on this one- the original technical reason for
this policy (portage inability to run from just the saved env dump)
is no longer an issue.
If people want to allow eclasses to have fluid APIs (specifically
removal of functionality), that's a discussion that needs to start on
the dev level.
Anyone got strong opinions on this one?
I don't believe there ever was such a policy, except for pkg_{pre,post}rm
because of the mentioned technical limitations (which were fixed in portage
2-3 years ago now). If there is such a policy then I've violated it on
several occasions :). In fact, isn't the generally accepted method of
deprecating an eclass to remove all functionality and replace it with a
message in global scope and a # @DEAD tag?
I don't see the advantage of keeping unmaintained broken code no one should
use around in eclasses. You can argue that removing eclass functionality can
potentially break ebuilds in overlays, but if you follow that line of
reasoning then really we should never remove any package from the tree
because it may be a dependency of something, somewhere.
So I'd like to see a policy that treats public functions in eclasses the same
as the last rites policies for package removal: minimum 30 day deprecation
period, mail to dev-announce, etc.
--
fonts, gcc-porting, and it's all by design
toolchain, wxwidgetsto keep us from losing our minds
@ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: RFC: remove php4 from depend.php and others
On Sat, Jul 10, 2010 at 10:02 PM, Ryan Hill dirtye...@gentoo.org wrote:
On Sat, 10 Jul 2010 01:34:37 -0700
Brian Harring ferri...@gmail.com wrote:
On Sat, Jul 10, 2010 at 09:30:42AM +0300, Petteri RRRty wrote:
The standing policy is still not to remove any public functionality from
eclasses. If we decide to start removing functionality the council
should set common rules for it.
Just adding a note on this one- the original technical reason for
this policy (portage inability to run from just the saved env dump)
is no longer an issue.
If people want to allow eclasses to have fluid APIs (specifically
removal of functionality), that's a discussion that needs to start on
the dev level.
Anyone got strong opinions on this one?
I don't believe there ever was such a policy, except for pkg_{pre,post}rm
because of the mentioned technical limitations (which were fixed in portage
2-3 years ago now). If there is such a policy then I've violated it on
several occasions :). In fact, isn't the generally accepted method of
deprecating an eclass to remove all functionality and replace it with a
message in global scope and a # @DEAD tag?
I don't see the advantage of keeping unmaintained broken code no one should
use around in eclasses. You can argue that removing eclass functionality can
potentially break ebuilds in overlays, but if you follow that line of
reasoning then really we should never remove any package from the tree
because it may be a dependency of something, somewhere.
So I'd like to see a policy that treats public functions in eclasses the same
as the last rites policies for package removal: minimum 30 day deprecation
period, mail to dev-announce, etc.
--
fonts, gcc-porting, and it's all by design
toolchain, wxwidgets to keep us from losing our minds
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
To be honest, the MythTV eclasses have been an ever evolving set of
eclasses for ages now. Ever since it was declared that its now safe to
remove eclasses from the tree since Portage saves eclasses and its
env, therefore it wouldn't cause a problem.
If I really need to go to the council with every change, considering
it must be debated on the ML for at least X number of days prior to
going to the council, I'd more likely just remove MythTV from the tree
and maintain it in an overlay. I don't invest a lot of time in the
MythTV ebuilds, but they work for a large majority of people. And when
a new version comes out it requires some retooling and it just works
for everyone.
So basically, you guys decide.. am I pulling them out of the tree or
am I leaving them in?
--
Doug Goldstein
Re: [gentoo-dev] [bugzilla-dae...@gentoo.org: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]
On Sat, Jul 10, 2010 at 12:13, Enrico Weigelt weig...@metux.de wrote: I've already explained the strategy behind the git repo (and not doing plaintext patches). Please refer to my paper, and my other mails posted recently on this list. I'm not quite sure I understand your response here. He didn't ask for you to explain the strategy. He asked for you to provide plain-text patches. I think a point has been made pretty clear at this point: they need plain-text patches. Requiring developers to learn an entirely new work-flow just to get your patches into the tree is time-consuming and bothersome, at the least. This isn't a discussion about whether or not your system is better. It's about how best to integrate your work into Gentoo. The developers have decided the best way is through plain-text patches. That's really all there is to it. Take it or leave it. The discussion about how best to join multiple branches of development across the open-source world together really does not belong in this thread, as far as I can tell. -- Jacob For then there will be great distress, unequaled from the beginning of the world until now — and never to be equaled again. If those days had not been cut short, no one would survive, but for the sake of the elect those days will be shortened. Are you ready?
Re: [gentoo-dev] 'State of Gentoo' BoF session, Linux Symposium 2010.
On Fri, Jul 9, 2010 at 13:19, Robin H. Johnson robb...@gentoo.org wrote: Hi all, I had hoped to send this before now, but the exact scheduled timeslot keeps changing. It was already on the PR events calendar. I'm running a BoF session during the Linux Symposium 2010 in Ottawa next week, entitled 'State of Gentoo'. I've had my own uneducated ideas about this exact topic. I'd love to hear more about this. Will notes or a recording be posted anywhere? -- Jacob For then there will be great distress, unequaled from the beginning of the world until now — and never to be equaled again. If those days had not been cut short, no one would survive, but for the sake of the elect those days will be shortened. Are you ready?
