Re: [gentoo-dev] New global USE flag mp4
Samuli Suominen a écrit : description: Support for MP4 container format [+ C ] mp4 (media-sound/amarok): Build the TagLib plugin for writing tags in Mp4 container files (m4a). Please note that by enabling this USE flag, the resulting package will not be redistributable, as it links to media-libs/libmp4v2, distributed under a GPL-incompatible license. amarok could have USE=bindist too, couldn't it? Thanks
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
2009/8/21 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org: Portage documentation has been properly fixed (and the fix will be released in next version) and this feature can now be used in 10.0 profiles. No. Changing the documentation does not retroactively change existing EAPIs.
Re: [gentoo-dev] New global USE flag mp4
Rémi Cardona wrote: Samuli Suominen a écrit : description: Support for MP4 container format [+ C ] mp4 (media-sound/amarok): Build the TagLib plugin for writing tags in Mp4 container files (m4a). Please note that by enabling this USE flag, the resulting package will not be redistributable, as it links to media-libs/libmp4v2, distributed under a GPL-incompatible license. amarok could have USE=bindist too, couldn't it? Thanks It's MPL-1.1 and Open Source and apparently FSF and OSI APPROVED as well. It's only KDE3 version of amaroK that is using the flag and unused in 2.1 (KDE4 version). Just trying to say we don't care, it will fade away. :) (short version) gentoo-x86/profiles/license_groups: FSF-APPROVED @GPL-COMPATIBLE MPL-1.1 OSI-APPROVED MPL-1.1
[gentoo-dev] another new global use flag zsh-completion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 will...@linux1 ~ $ euse -i zsh-completion global use flags (searching: zsh-completion) no matching entries found local use flags (searching: zsh-completion) [-] zsh-completion (app-text/wgetpaste): Install zsh command completion [-] zsh-completion (dev-util/mercurial): Install zsh command completion for hg. [-] zsh-completion (media-sound/cmus): enable zsh completion support [-] zsh-completion (sci-chemistry/gromacs): Enable zsh completion support [-] zsh-completion (sys-apps/paludis): Enable zsh completion support [-] zsh-completion (sys-auth/policykit): Install zsh command completion. [-] zsh-completion (www-client/pybugz): Enables zsh completion for pybugz will...@linux1 ~ $ I would like to migrate 'zsh-completion' to a global use flag with the following description: 'enable zsh completion support' If there is not an objection to this I will do so one week from today (august 28), or sooner if that is ok. What do you think? - -- William Hubbs gentoo accessibility team lead willi...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqO5gEACgkQblQW9DDEZTgNiwCeLCwX/F6k50syNO0jVTu3KRjo UUIAoLs75Y3SqhbM3bq3tMOjJldJLcGV =KxRM -END PGP SIGNATURE-
[gentoo-dev] Re: New global USE flag mp4
Samuli Suominen posted on Fri, 21 Aug 2009 20:09:10 +0300 as excerpted: Rémi Cardona wrote: Samuli Suominen a écrit : description: Support for MP4 container format [+ C ] mp4 (media-sound/amarok): Build the TagLib plugin for writing tags in Mp4 container files (m4a). Please note that by enabling this USE flag, the resulting package will not be redistributable, as it links to media-libs/libmp4v2, distributed under a GPL-incompatible license. amarok could have USE=bindist too, couldn't it? Thanks It's MPL-1.1 and Open Source and apparently FSF and OSI APPROVED as well. It's only KDE3 version of amaroK that is using the flag and unused in 2.1 (KDE4 version). Just trying to say we don't care, it will fade away. :) (short version) gentoo-x86/profiles/license_groups: FSF-APPROVED @GPL-COMPATIBLE MPL-1.1 OSI-APPROVED MPL-1.1 Yes, but FLOSS isn't the point. The point is it's mixing GPL FLOSS with GPL incompatible FLOSS, thus is not legally redistributable, and that's what the bindist flag is for. But with local and global USE flags available together now, and in view of the fact that 3.5 is dying anyway, I'd say go for the global flag, and just make sure the local flag info remains in place for amarok until the 3.5 packages get killed. The other alternative would be to tie the plugin to both USE flags on the older amaroks, with an ewarn if the two flags don't agree, but of course that requires touching the ebuild AND has the implication of causing a needless remerge for anyone using --newuse. For something that's dying anyway, I don't believe it's worth it. -- 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] Test request: Bugzilla load balancer
On Wed, Jul 29, 2009 at 1:29 PM, Robin H. Johnsonrobb...@gentoo.org wrote: Hi folks, I've been doing some more mucking with the Bugzilla code and setup, and I think I've got most of the issues worked out that previously prevented it from being fully load balanced. So, please test at: http://bugs-web-lb.gentoo.org/ HTTP and HTTPS available. Robin, Thanks for your work. I see that it has been made the default now. Seems more responsive in general, with the added redundancy bonus! -Jeremy
[gentoo-dev] EAPI 3 and nonfatal die
In EAPI 3, most commands and functions provided by the package
manager automatically call die if they fail. There's also a
new nonfatal function that can be used to suppress this
behaviour: by prefixing a function/command call with nonfatal,
the automatic die behaviour is suppressed during the executation
of that function/command.
The difficulty here is that it's not clear what nonfatal should
do to explicit die and assert calls. On the one hand, if
nonfatal does suppress these functions, then nonfatal can be
usefully used with eclass functions - silly hypothetical example:
# eclass
escons() {
scons $...@} || die scons failed
}
# ebuild
nonfatal escons || do_something_else
On the other hand, it could be risky to change the behaviour of
existing functions like that:
do_foo() {
cd foo || die cd failed
# something that would be dangerous if run in some other directory
}
If called as nonfatal do_foo and the cd failed, do_foo
/wouldn't/ return a failure code - it would proceed with the rest
of its body and wreak all manner of havoc.
One way around this would be to add either an option to die to
explicitly tell it to respect nonfatal, or an alternative die
function. This would allow eclasses to choose to respect
nonfatal when it's safe to do so, but without changing existing
behaviour. The disadvantage of this is that it would require
changes to all eclass functions that could potentially use it,
plus the slight ugliness of making them handle older EAPIs as
well.
Another option would be to make die respect nonfatal by default,
and add an option that doesn't. This wouldn't require changes to
eclasses that want the nonfatal behaviour, but it would require
some care to make sure that it was used when necessary. A
potential advantage of this over the previous solution is that if
the force option is implemented with an environment variable,
it can be used regardless of EAPI - the previous example could be
changed to something like
do_foo() {
cd foo || DIE_FORCE=1 die cd failed
# something that would be dangerous if run in some other directory
}
Does anyone have any opinions on which of the four options (#1
make die respect nonfatal, #2 make die always die, #3 add a new
die variant that respects nonfatal, #4 make regular die respect
nonfatal, and add a new variant that doesn't) we should go with?
We should definitely get this resolved and agreed on before EAPI
3 is finalised.
Re: [gentoo-dev] EAPI 3 and nonfatal die
On Friday 21 of August 2009 22:56:41 David Leverton wrote:
Does anyone have any opinions on which of the four options (#1
make die respect nonfatal, #2 make die always die, #3 add a new
die variant that respects nonfatal, #4 make regular die respect
nonfatal, and add a new variant that doesn't) we should go with?
We should definitely get this resolved and agreed on before EAPI
3 is finalised.
I suggest #5 - drop the idea of 'nonfatal'.
Quoting devmanual:
The die function should be used to indicate a fatal error and abort the
build. Its parameters should be the message to display.
Period.
In such case, following code:
nonfatal some_function
when:
some_function() {
so_sth || die sth failed
}
only means, that some_function shouldn't have been equipped with 'die'
mechanism, as use case appeared that demands it being non-fatal.
And in this case some_function should be fixed to be nonfatal instead (and
all existing invocations suffixed by || die.
Simple as this.
Please refrain from adding silly workarounds like this - only thing they add
is unnecessary complexity and thus maintenance/debugging burden.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 and nonfatal die
On Fri, 21 Aug 2009 23:09:33 +0200 Maciej Mrozowski reave...@poczta.fm wrote: I suggest #5 - drop the idea of 'nonfatal'. Then how do you plan to handle all the standard utilities that die on failure in EAPI 3? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Fri, 21 Aug 2009 16:25:35 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2009-08-13 07:55:22 Ryan Hill napisał(a): On Wed, 12 Aug 2009 19:46:56 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 12 Aug 2009 20:41:30 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: Also we should allow the stuff as directory thingus (portage already handles it right). That's a seperate thing that needs EAPI control. You'll need to propose it for EAPI 4 if you want that. Why is that (seriously curious, not disagreeing)? Portage has supported this for quite a while now. Does the current PMS disallow it? Portage documentation has been properly fixed (and the fix will be released in next version) and this feature can now be used in 10.0 profiles. How does changing the portage documentation magically add this to the PMS? -- fonts, Character is what you are in the dark. gcc-porting, wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: EAPI 3 and nonfatal die
On Friday 21 August 2009 21:56:41 David Leverton wrote: A potential advantage of this over the previous solution is that if the force option is implemented with an environment variable, it can be used regardless of EAPI ...except that the previous solution could use an environment variable too, of course.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
2009-08-21 23:17:56 Ryan Hill napisał(a): On Fri, 21 Aug 2009 16:25:35 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: 2009-08-13 07:55:22 Ryan Hill napisał(a): On Wed, 12 Aug 2009 19:46:56 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 12 Aug 2009 20:41:30 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: Also we should allow the stuff as directory thingus (portage already handles it right). That's a seperate thing that needs EAPI control. You'll need to propose it for EAPI 4 if you want that. Why is that (seriously curious, not disagreeing)? Portage has supported this for quite a while now. Does the current PMS disallow it? Portage documentation has been properly fixed (and the fix will be released in next version) and this feature can now be used in 10.0 profiles. How does changing the portage documentation magically add this to the PMS? PMS developers are unwilling to fix many bugs in PMS. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Fri, 21 Aug 2009 23:42:11 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: How does changing the portage documentation magically add this to the PMS? PMS developers are unwilling to fix many bugs in PMS. This is not a bug in PMS. PMS accurately reflected the Portage documentation at the time it was written and at the time it was approved. In addition, there was no real world use of this feature so there was no grounds to consider making it part of the specification despite it being undocumented. Thus, the way PMS was written was correct. What you are asking for would be like retroactively updating the HTML 4 specification to mandate a particular undocumented quirk of Internet Explorer 6's behaviour. The correct way to proceed is to use EAPI 4 to move this to be a specified feature, and to permit it only for profiles marked as using EAPI 4. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 3 and nonfatal die
2009-08-21 22:56:41 David Leverton napisał(a):
In EAPI 3, most commands and functions provided by the package
manager automatically call die if they fail. There's also a
new nonfatal function that can be used to suppress this
behaviour: by prefixing a function/command call with nonfatal,
the automatic die behaviour is suppressed during the executation
of that function/command.
The difficulty here is that it's not clear what nonfatal should
do to explicit die and assert calls. On the one hand, if
nonfatal does suppress these functions, then nonfatal can be
usefully used with eclass functions - silly hypothetical example:
# eclass
escons() {
scons $...@} || die scons failed
}
# ebuild
nonfatal escons || do_something_else
On the other hand, it could be risky to change the behaviour of
existing functions like that:
do_foo() {
cd foo || die cd failed
# something that would be dangerous if run in some other directory
}
If called as nonfatal do_foo and the cd failed, do_foo
/wouldn't/ return a failure code - it would proceed with the rest
of its body and wreak all manner of havoc.
One way around this would be to add either an option to die to
explicitly tell it to respect nonfatal, or an alternative die
function. This would allow eclasses to choose to respect
nonfatal when it's safe to do so, but without changing existing
behaviour. The disadvantage of this is that it would require
changes to all eclass functions that could potentially use it,
plus the slight ugliness of making them handle older EAPIs as
well.
Another option would be to make die respect nonfatal by default,
and add an option that doesn't. This wouldn't require changes to
eclasses that want the nonfatal behaviour, but it would require
some care to make sure that it was used when necessary. A
potential advantage of this over the previous solution is that if
the force option is implemented with an environment variable,
it can be used regardless of EAPI - the previous example could be
changed to something like
do_foo() {
cd foo || DIE_FORCE=1 die cd failed
# something that would be dangerous if run in some other directory
}
Does anyone have any opinions on which of the four options (#1
make die respect nonfatal, #2 make die always die, #3 add a new
die variant that respects nonfatal, #4 make regular die respect
nonfatal, and add a new variant that doesn't) we should go with?
I think that 'DIE_FORCE=1 die ${die_message}' (which was invented by me)
would be the
best option. It will allow to use nonfatal() with eclass functions with the
smallest
number of required changes in eclasses.
I would like to also notice that (not yet approved by Council) definition of
nonfatal()
in PMS was recently drastically changed without proper discussion with
developers of
other package managers. [1] was sent about 20 minutes after discussion about
nonfatal()
started in #gentoo-portage in about 2009-08-06 19:45 UTC.
(I'm attaching IRC log from #gentoo-portage (in UTC+02 timezone).)
I think that such drastic changes should be first discussed on gentoo-dev
mailing list.
[1]
http://archives.gentoo.org/gentoo-pms/msg_5ae501394eaeff148cfc349f84d960c9.xml
--
Arfrever Frehtes Taifersar Arahesis
### Log session started at 2009-08-06T13:57:20 ###
[13:57:20] Arfrever [n=arfre...@gentoo/developer/arfrever] has joined #gentoo-portage
[13:57:20] Channel topic is: This is not a help/support channel || Ebuild dev questions go to #gentoo-dev-help and usage questions go to #gentoo || Portage resources: http://www.gentoo.org/proj/en/portage/index.xml#doc_chap6
[13:57:20] Topic was set by zmedico on 2009-06-07T06:54:17
[13:57:20] pratchett.freenode.net [...@*] has set channel mode +tnc
[13:57:20] Channel was created at 2006-11-26T07:42:44
[14:07:37] scarabeus [n=sca...@gentoo/developer/scarabeus] has quit IRC: No Ping reply in 90 seconds.
[14:11:27] scarabeus [n=sca...@net-2-2.jaw.cz] has joined #gentoo-portage
[14:37:51] sping_ [n=sp...@e179008226.adsl.alicedsl.de] has joined #gentoo-portage
[14:54:07] reavertm [n=reave...@gentoo/contributor/reavertm] has quit IRC: Remote closed the connection
[15:05:30] few [n=...@gibbs.nat.uni-magdeburg.de] has joined #gentoo-portage
[15:05:34] few [n=...@gibbs.nat.uni-magdeburg.de] has quit IRC: Remote closed the connection
[15:05:50] few [n=...@gibbs.nat.uni-magdeburg.de] has joined #gentoo-portage
[15:06:05] few [n=...@gibbs.nat.uni-magdeburg.de] has quit IRC: Client Quit
[15:08:02] slonopotamus [n=slono...@83.149.10.164] has quit IRC: Read error: 110 (Connection timed out)
[15:08:10] FuzzyRay [n=pvar...@gentoo/developer/FuzzyRay] has joined #gentoo-portage
[15:21:01] noisebleed [n=noise...@piggy.inescn.pt] has quit IRC: Remote closed the connection
[15:41:22] sping_ [n=sp...@gentoo/user/sping] is now known as sping_afk
[16:07:53] ali_bush [n=alist...@gentoo/developer/alibush] has quit IRC:
Re: [gentoo-dev] EAPI 3 and nonfatal die
On Sat, 22 Aug 2009 00:40:04 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: I would like to also notice that (not yet approved by Council) definition of nonfatal() in PMS was recently drastically changed without proper discussion with developers of other package managers. [1] was sent about 20 minutes after discussion about nonfatal() started in #gentoo-portage in about 2009-08-06 19:45 UTC. (I'm attaching IRC log from #gentoo-portage (in UTC+02 timezone).) I think that such drastic changes should be first discussed on gentoo-dev mailing list. There was no change to the definition of nonfatal. There was a clarification of the wording after it became clear that there was room to misinterpret the intent of the original wording, and it went through the usual Council-mandated process for such a change. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Gentoo stats server/client @ 2009-08-22
Hello! Arrivals The third peport table on installed packages most-unmasked has just arrived: http://smolt.hartwork.org:45678/static/stats/gentoo.html#installed_packages_most_unmasked Questions = Before adding the forth least-installed table, I'd like to take the chance to ask for input from the treecleaner team, as it may be of most interest to you in the future. - Do you need anything that a dumb linear-with-counter approach cannot offer? - Would zero-install packages be more interesting than almost-zero ones or the other way around? What's next === Besides before-mentioned table the task Collect FEATURES variables in three sets (conf, defaults, globals), not merged http://soc.gentooexperimental.org/issues/show/58 is next on my list. Sebastian
Re: [gentoo-dev] EAPI 3 and nonfatal die
On Friday 21 of August 2009 23:12:23 Ciaran McCreesh wrote: On Fri, 21 Aug 2009 23:09:33 +0200 Maciej Mrozowski reave...@poczta.fm wrote: I suggest #5 - drop the idea of 'nonfatal'. Then how do you plan to handle all the standard utilities that die on failure in EAPI 3? #1 make die respect nonfatal The most obvious. About consequences - when you override behaviour of die-on- failure function (that has been marked as fatal for reason) you're supposed to know what you're doing, so all codepaths should be checked in that case, otherwise one should be really ready to grab the pieces in such case. #2 make die always die In such case nonfatal is useless as it's supposed to surpass die-on-failure EAPI3 functions, am I right? Correct me if I'm wrong, bug there are just two ways to mark function invocation as 'failed': - return nonzero value - soft way - abort further execution of script, so call die function - hard way In such case nonfatal works against its purpose (it cannot interfere in arbitrary function's flow control, and return value only affects this, so the only mean for it is to interfere in general-purpose-die-function). This could be fixed by introducing 'even-more-fatal' way of aborting script execution, like function 'really-die-seriously-this-time' that ignores 'nonfatal' :P (which leads us to #3 and #4). #3 add a new die variant that respects nonfatal Seems the most reasonable to me, but should be introduced with caution (if at all). It's very old question how to approach flow control: whether to: - maintain in using 'do_it_now_think_later' approach (exceptions' handling, nonfatal) - 'do_it_now_think_now' (checking return values) Ideally would be to have just one. And if the goal is to implement exception-handling-like (actually catching and ignoring) approach in flow control for EAPI3 instead of relying on return value (|| die) with runtime errors throwing (current 'die'), one would need not just one or two die functions, but maybe whole family, with different fatality levels (for example controlled by environment variable, so that one could ignore those with level 0 or could be more strict and only ignore those with level 2, when 0 would be the most fatal, 1 less-lethal and so on). #4 make regular die respect nonfatal, and add a new variant that doesn't) we should go with? All existing 'die' invocations now are supposed to be fatal (according to definition in devmanual), so making them maybe-fatal in EAPI3 is wrong imho. General problem is defining what's really fatal and what's not - and I can assure that someone in a future will find some use case for preventing aborting of execution of some fatal function that failed. That being said I don't like refraining from return value approach towards exception handling approach (and I'm ebuild/eclass developer and I don't see adding || die very disturbing) that has been proposed for EAPI3 in die-on- failure utility functions, and thus I don't like nonfatal (which is of course needed for them). -- regards MM signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22
On 08/22/2009 01:55 AM, Sebastian Pipping wrote: Hello! Arrivals The third peport table on installed packages most-unmasked has just arrived: http://smolt.hartwork.org:45678/static/stats/gentoo.html#installed_packages_most_unmasked Is there something special required to use smolt? I get to a page that tells me this after I submit my profile: Error: Critical: New versions of smolt use a public UUID. Yours is: pub_----
Re: [gentoo-dev] EAPI 3 and nonfatal die
On Sat, 22 Aug 2009 01:01:48 +0200 Maciej Mrozowski reave...@poczta.fm wrote: That being said I don't like refraining from return value approach towards exception handling approach nonfatal's not an exception handling approach. Think of it as a utility like 'nice', 'ionice', 'xargs', 'env' or 'hilite'. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Friday 21 of August 2009 23:46:38 Ciaran McCreesh wrote: On Fri, 21 Aug 2009 23:42:11 +0200 PMS accurately reflected the Portage documentation at the time it was written and at the time it was approved. Agreed, but I think it was supposed to reflect Portage 'behaviour' at the time. Of course it's hard to blame anyone for it, especially after all these years. The correct way to proceed is to use EAPI 4 to move this to be a specified feature, and to permit it only for profiles marked as using EAPI 4. It's true, but being able to modularize profile may outweights the need to be strict-with-the-book here - it's a matter of usefulness. I think it should be decided by those who actually do the work in profile, whether it's worthy to push this now instead of waiting for EAPI approval. So, can profile developers share their view? -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22
Nikos Chantziaras wrote: Is there something special required to use smolt? I get to a page that tells me this after I submit my profile: Error: Critical: New versions of smolt use a public UUID. Yours is: pub_---- What version/edition of Smolt are you trying to commit with? Thanks for asking. Sebastian
Re: [gentoo-dev] EAPI 3 and nonfatal die
2009-08-22 00:51:14 Ciaran McCreesh napisał(a): On Sat, 22 Aug 2009 00:40:04 +0200 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote: I would like to also notice that (not yet approved by Council) definition of nonfatal() in PMS was recently drastically changed without proper discussion with developers of other package managers. [1] was sent about 20 minutes after discussion about nonfatal() started in #gentoo-portage in about 2009-08-06 19:45 UTC. (I'm attaching IRC log from #gentoo-portage (in UTC+02 timezone).) I think that such drastic changes should be first discussed on gentoo-dev mailing list. There was no change to the definition of nonfatal. There was a change regardless of what you think. There was a clarification of the wording after it became clear that there was room to misinterpret the intent of the original wording, and it went through the usual Council-mandated process for such a change. This sentence contradicts your first sentence. Additionally you had deceived Christian Faulhammer by not presenting negative consequences of your patch and your interpretation of original wording of definition of nonfatal(). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 and nonfatal die
On Saturday 22 of August 2009 01:06:30 Ciaran McCreesh wrote: On Sat, 22 Aug 2009 01:01:48 +0200 Maciej Mrozowski reave...@poczta.fm wrote: That being said I don't like refraining from return value approach towards exception handling approach nonfatal's not an exception handling approach. Think of it as a utility like 'nice', 'ionice', 'xargs', 'env' or 'hilite'. Le sigh.. Replacing return value with die (throw) *and* providing 'nonfatal' as mechanism to catch and ignore what's been thrown is obviously exception handling approach (not literally that is, I don't have to recall the semantics of \ character) - every respected software engineer will see that. But on topic, if you want to participate in discussion, please refer to suggestions given by David, please. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI 3 and nonfatal die
On Sat, 22 Aug 2009 01:20:36 +0200 Maciej Mrozowski reave...@poczta.fm wrote: That being said I don't like refraining from return value approach towards exception handling approach nonfatal's not an exception handling approach. Think of it as a utility like 'nice', 'ionice', 'xargs', 'env' or 'hilite'. Le sigh.. Replacing return value with die (throw) *and* providing 'nonfatal' as mechanism to catch and ignore what's been thrown is obviously exception handling approach (not literally that is, I don't have to recall the semantics of \ character) - every respected software engineer will see that. That isn't what nonfatal does. It does not in any way catch and ignore what's been thrown. It prevents the fatal notification from being sent in the first place. die is not a throw operation, never has been a throw operation (see the whole die in subshells mess) and isn't going to be a throw operation. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI 3 and nonfatal die
On Sat, 22 Aug 2009 01:15:18 +0200
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote:
There was no change to the definition of nonfatal.
There was a change regardless of what you think.
No, you were misreading the original wording (which I quite happy
admit was wide open for misreading), hence the need for the
clarification.
There was a clarification of the wording after it became clear that
there was room to misinterpret the intent of the original wording,
and it went through the usual Council-mandated process for such a
change.
This sentence contradicts your first sentence.
No, it doesn't.
The original wording used the phrase abort the build process due to a
failure. The intent was that this would cover commands that had
language like Failure behaviour is EAPI dependent as per
section~\ref{sec:failure-behaviour}..
The language for 'die' does not say due to a failure, and so was not
supposed to be affected by 'nonfatal'.
However, that wasn't explicit, so your misreading of the intent of the
document is entirely understandable. That is why we fixed it.
Additionally you had deceived Christian Faulhammer by not presenting
negative consequences of your patch and your interpretation of
original wording of definition of nonfatal().
The only consequence of the patch was to clarify what was already
stated.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
[gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22
On 08/22/2009 02:11 AM, Sebastian Pipping wrote: Nikos Chantziaras wrote: Is there something special required to use smolt? I get to a page that tells me this after I submit my profile: Error: Critical: New versions of smolt use a public UUID. Yours is: pub_---- What version/edition of Smolt are you trying to commit with? The only available one: app-admin/smolt-1.2
Re: [gentoo-dev] EAPI 3 and nonfatal die
On Sat, 22 Aug 2009 01:39:41 +0200
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote:
There was a change regardless of what you think.
No, you were misreading the original wording
The original wording didn't disallow affecting die(). Not disallowed
things are always allowed.
Er, no. The wording describes the extent of what die and nonfatal do.
There's nothing in the die description about it being affected by
nonfatal, and nothing in the nonfatal description about affecting die,
so neither affect each other.
PMS doesn't say nonfatal must not chmod +s ${D}/bin/sh, so do you
believe that nonfatal would be allowed to do that too?
There was a clarification of the wording after it became clear
that there was room to misinterpret the intent of the original
wording, and it went through the usual Council-mandated process
for such a change.
This sentence contradicts your first sentence.
No, it doesn't.
it went through the usual Council-mandated process for such a
change clearly contradicts There was no change.
There was a change in wording to better convey the original intent.
There was no change in behaviour.
The original wording used the phrase abort the build process due
to a failure. The intent was that this would cover commands that
had language like Failure behaviour is EAPI dependent as per
section~\ref{sec:failure-behaviour}..
The language for 'die' does not say due to a failure, and so was
not supposed to be affected by 'nonfatal'.
However, that wasn't explicit, so your misreading of the intent of
the document is entirely understandable. That is why we fixed it.
You broke it.
I made the wording more clearly present the original intent. That is
all.
Additionally you had deceived Christian Faulhammer by not
presenting negative consequences of your patch and your
interpretation of original wording of definition of nonfatal().
The only consequence of the patch was to clarify what was already
stated.
It wasn't stated as I said above in my 2 first sentences in this
e-mail.
It was. The extent of the behaviour of nonfatal is described in PMS.
You can't go around inventing magic new behaviour for it that isn't
specified.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Saturday 22 August 2009, Maciej Mrozowski wrote: It's true, but being able to modularize profile may outweights the need to be strict-with-the-book here - it's a matter of usefulness. I think it should be decided by those who actually do the work in profile, whether it's worthy to push this now instead of waiting for EAPI approval. So, can profile developers share their view? We have kept SLOT dependencies and other EAPI-0 features out of the tree profiles, introduced profile EAPI versioning to foster interoperability. Now what you propose is to break this deliberate upgrade process to introduce a feature no one proposed for the profiles directory in the last years? I wonder what the value of the PMS specification is if every time an inconsistency comes up the argument is raised that it should document portage behavior. EAPI 1, 2 and 3 have been agreed by the council and PMS is in a stage where Portage should obey its definitions and not the other way around. I am not saying that this is the *fastest* way to innovate (although in my opinion it is a good way to keep interoperability). However this PMS process is what council has chosen for Gentoo, and either you follow it, or you try to improve it (working with the PMS subproject people), or you bring up a proposal to redefine how we handle standards within the tree. Trying to ignore the fact this standard exists is a way to breakage. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
2009/8/21 Robert Buchholz r...@gentoo.org: On Saturday 22 August 2009, Maciej Mrozowski wrote: It's true, but being able to modularize profile may outweights the need to be strict-with-the-book here - it's a matter of usefulness. I think it should be decided by those who actually do the work in profile, whether it's worthy to push this now instead of waiting for EAPI approval. So, can profile developers share their view? We have kept SLOT dependencies and other EAPI-0 features out of the tree profiles, introduced profile EAPI versioning to foster interoperability. Now what you propose is to break this deliberate upgrade process to introduce a feature no one proposed for the profiles directory in the last years? I wonder what the value of the PMS specification is if every time an inconsistency comes up the argument is raised that it should document portage behavior. EAPI 1, 2 and 3 have been agreed by the council and PMS is in a stage where Portage should obey its definitions and not the other way around. I am not saying that this is the *fastest* way to innovate (although in my opinion it is a good way to keep interoperability). However this PMS process is what council has chosen for Gentoo, and either you follow it, or you try to improve it (working with the PMS subproject people), or you bring up a proposal to redefine how we handle standards within the tree. Trying to ignore the fact this standard exists is a way to breakage. Robert When the PMS subproject is overwhelmingly ruled by a single person who doesn't have official Gentoo developer status and yet it is allowed to remove features from portage (the reference implementation) that predated PMS at the direction of this same non-dev, you start to have a very big problem. If you were building a house, and the blueprints had been signed off on calling for 1 meter high doors, but the builder had built in 2 meter high doors, would you then go back to the builder and require him to do something that makes those doors unusable for the vast majority of people entering the house? If this feature, which HAD been documented (in bugzilla and commitlogs) prior to the first RFC for PMS, had instead been added yesterday, I would completely agree that we should revert it and it should be part of a future specification. Since this is instead a situation where the blueprints were wrong and the builder was correct, let's not go throwing away our normal sized doors. Since I, as well as the only person who's loudly having an issue with portage and PMS not matching up in this respect, are both USERS and NOT Gentoo developers, it's my opinion that portage should be left alone and PMS should be corrected to align with the spirit, if not the letter of what was documented WELL after the initial commit that added the feature. And, since I and the main contributor to PMS are both users, it's also my opinion that NEITHER of us should have anything to do with the policy/specification defining package manager behavior for the most prolific package manager in use today.
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Fri, 21 Aug 2009 17:29:12 -0700 Chip Parker infowo...@gmail.com wrote: If this feature, which HAD been documented (in bugzilla and commitlogs) prior to the first RFC for PMS As I've already explained to you on bugzilla, this is untrue. You're confusing user configuration with the tree. PMS has nothing to say about user configuration, and nothing is being done to take away the feature you're concerned about. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22
Nikos Chantziaras wrote: What version/edition of Smolt are you trying to commit with? The only available one: app-admin/smolt-1.2 Smolt 1.2 does not have the Gentoo-specific client code you need, yet. Please try again with app-admin/gentoo-smolt- from my sping overlay. Sebastian
[gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Fri, 21 Aug 2009 17:29:12 -0700 Chip Parker infowo...@gmail.com wrote: If you were building a house, and the blueprints had been signed off on calling for 1 meter high doors, but the builder had built in 2 meter high doors, would you then go back to the builder and require him to do something that makes those doors unusable for the vast majority of people entering the house? Package managers can implement whatever extra bells and whistles they like, but they still have to follow the spec. Your metaphor is flawed in that you're talking about a single house here. If it doesn't match the plan you do an as-built and file a deviation with the registrar. The situation here is more like if you build a hundred houses to code, and then one above code, and then change code to match the one house and bulldoze the rest for not meeting minimal requirements. You're punishing anyone who implements a package manager to spec if you keep changing the spec in incompatible ways. -- fonts, Character is what you are in the dark. gcc-porting, wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Diff between Funtoo and Gentoo as an overlay
Sebastian Pipping wrote: Commits are done automatically, triggering and pushing is manual at the moment. By now a cron-based setup is running syncing the pure-funtoo overlay (and therefore also its atom and rss feeds) every 24 hours. Sebastian
[gentoo-dev] Re: EAPI 3 and nonfatal die
On Fri, 21 Aug 2009 21:56:41 +0100 David Leverton levert...@googlemail.com wrote: Does anyone have any opinions on which of the four options (#1 make die respect nonfatal, #2 make die always die, #3 add a new die variant that respects nonfatal, #4 make regular die respect nonfatal, and add a new variant that doesn't) we should go with? We should definitely get this resolved and agreed on before EAPI 3 is finalised. I'd like die to respect nonfatal. People using nonfatal should check beforehand that the functions they're calling won't do anything stupid if die's are ignored. If there's something that absolutely has to die, nonfatal or not, then use a variable. I guess that's #4? -- fonts, Character is what you are in the dark. gcc-porting, wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay
On 08/22/2009 05:39 AM, Sebastian Pipping wrote: Sebastian Pipping wrote: Commits are done automatically, triggering and pushing is manual at the moment. By now a cron-based setup is running syncing the pure-funtoo overlay (and therefore also its atom and rss feeds) every 24 hours. There seems to be a bit of (minimal) duplication between pure-funtoo and sunrise: app-office/thinking-rock-bin dev-tex/mimetex x11-drivers/xf86-video-nouveau And since sunrise is the most popular overlay, it might be a good idea to also omit packages found in sunrise.
[gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay
On 08/22/2009 05:59 AM, Nikos Chantziaras wrote: On 08/22/2009 05:39 AM, Sebastian Pipping wrote: Sebastian Pipping wrote: Commits are done automatically, triggering and pushing is manual at the moment. By now a cron-based setup is running syncing the pure-funtoo overlay (and therefore also its atom and rss feeds) every 24 hours. There seems to be a bit of (minimal) duplication between pure-funtoo and sunrise. Uhm, I just discovered that there are conflicts with portage too. That is not good. After I added pure-funtoo, it messed up my emerge -u world (stuff like wanting to upgrade to sys-apps/baselayout-2.1.5). pure-funtoo should not offer packages available in portage (sunrise is the lesser evil).
[gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22
On 08/22/2009 04:07 AM, Sebastian Pipping wrote: Nikos Chantziaras wrote: What version/edition of Smolt are you trying to commit with? The only available one: app-admin/smolt-1.2 Smolt 1.2 does not have the Gentoo-specific client code you need, yet. Please try again with app-admin/gentoo-smolt- from my sping overlay. Done. Seems to work OK. Though there's no info about the scanning of packages and my profile page only lists hardware.
Re: [gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay
Nikos Chantziaras wrote: On 08/22/2009 05:59 AM, Nikos Chantziaras wrote: On 08/22/2009 05:39 AM, Sebastian Pipping wrote: Sebastian Pipping wrote: Commits are done automatically, triggering and pushing is manual at the moment. By now a cron-based setup is running syncing the pure-funtoo overlay (and therefore also its atom and rss feeds) every 24 hours. There seems to be a bit of (minimal) duplication between pure-funtoo and sunrise. Uhm, I just discovered that there are conflicts with portage too. That is not good. After I added pure-funtoo, it messed up my emerge -u world (stuff like wanting to upgrade to sys-apps/baselayout-2.1.5). pure-funtoo should not offer packages available in portage (sunrise is the lesser evil). Huh? This is true of all overlays. If my overlay had baselayout-5.0 in it, you would be upgrading to that version if you had my overlay... By nature of overlays themselves, you should know what you are doing and how to handle it (ie. mask =sys-apps/baselayout-2.0.1) -Jeremy
Re: [gentoo-dev] Re: Diff between Funtoo and Gentoo as an overlay
Nikos Chantziaras wrote: There seems to be a bit of (minimal) duplication between pure-funtoo and sunrise: app-office/thinking-rock-bin dev-tex/mimetex x11-drivers/xf86-video-nouveau And since sunrise is the most popular overlay, it might be a good idea to also omit packages found in sunrise. Sunrise ebuilds are subtracted already. The reason app-office/thinking-rock-bin ends up in pure-funtoo is that newer version of existing ebuilds are also taking into account: Sunrise: 2.0_pre2-r2 Funtoo: 2.0.1 That's why app-office/thinking-rock-bin-2.0.1 is in pure-funtoo. Sebastian
[gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Robert Buchholz posted on Sat, 22 Aug 2009 01:44:51 +0200 as excerpted: I wonder what the value of the PMS specification is if every time an inconsistency comes up the argument is raised that it should document portage behavior. EAPI 1, 2 and 3 have been agreed by the council and PMS is in a stage where Portage should obey its definitions and not the other way around. Trying to ignore the fact this standard exists is a way to breakage. There are, as I see it, two issues here. 1) This feature can be reasonably argued to have fallen thru the cracks, since it was actually implemented before PMS. Yes, the committing documentation said it was for user config only, but the implementation was in general, and in general, EAPI-0 was to document existing behavior, so we have a problem. It's thus one of a very limited number of candidates, and it's not like there's going to be hundreds more where this came from. 2) If I'm not mistaken, EAPI-0 has never been fully finalized anyway. It has gotten to preliminary approval, where bugs are supposed to be filed where there's a conflict, and a resolution worked out. All other approved EAPIs have been defined as differences from previous versions, but due to the way EAPI-0 came about, nobody has really been sure enough it's 100% defined, and final approval hasn't happened as a result. Given that this feature was there before PMS. despite what the documentation actually said, it's precisely the type of bug that was intended to be covered by the preliminary approval, and hammering it out as that preliminary approval outlined is where we're at right now. If #2 is indeed correct, then we don't have a loophole, we have a legitimate bug that's we're in the process of hashing out, and it's not at all clear cut whether the bug is in portage and arguably the original documentation or in PMS. That's a matter of viewpoint that will likely take a council vote to solve. However, as I pointed out on the bug, either way it's not particularly difficult to solve it. Should council decide to run with the existing portage behavior, since it has been there for years, the old pre-PMS wait- a-year before changes can be allowed in tree need not apply. I suggested 30-90 days before it's allowed in official overlays, and 90-180 days before it's allowed in-tree, altho using it only in the new profiles works too. If it goes the other way, then as Zac points out, it's a simple matter to change the portage documentation once again, and since it's not in-tree yet (well, at least before the new-profile announcement, and anything that new and limited to them can be reverted fairly easily too), not a big deal. It can then wait for EAPI-4 But regardless, it /does/ appear it'll take a council vote on this, one way or the other. The matter has been requested for the next council meeting. I'd hope everybody can agree to just slow down a bit until then. (Zac just committed a portage documentation note mentioning it's not in PMS yet, and no intervening releases have been made with the questioned wording /without/ that clause, AFAIK, so that end's covered.) If at that point it's postponed, that too is effectively a decision, but I should hope it won't be postponed, as it's relatively simple either way, and we need a resolution from council, as the authoritative body designated to resolve such issues, both in general, and if I'm not mistaken, in the preliminary EAPI-0 approval. -- 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: Diff between Funtoo and Gentoo as an overlay
Nikos Chantziaras wrote: Uhm, I just discovered that there are conflicts with portage too. That is not good. After I added pure-funtoo, it messed up my emerge -u world (stuff like wanting to upgrade to sys-apps/baselayout-2.1.5). Hopefully fixed http://git.goodpoint.de/?p=pure-funtoo.git;a=commitdiff;h=341663321f0cf876390fff5967105e403ed3fcbc Sebastian
Re: [gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22
Nikos Chantziaras wrote: Done. Seems to work OK. Though there's no info about the scanning of packages and my profile page only lists hardware. I cannot find any new entries in the database. Have you been using --server=http://smolt.hartwork.org:45678/ on submission? I mentioned that in previous threads and didn't think of a need mentioning it again, sorry. Before submission you can view all the data you submit. Near the bottom should be a long list of package details, right above the privacy metrics table. Sebastian
Re: [gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22
Jeremy Olexa wrote: - Would zero-install packages be more interesting than almost-zero ones or the other way around? I don't really understand this question. Does zero-install mean that they are not installed at all? This isn't really useful, because the ommition of a package from the page can mean that no one has it installed. ;) By zero-install I mean a package from the main tree (gentoo) that none of the submitters has installed. To detect such packages I plan to collect the list of currently in-tree packages from rsync and query the submission database against it. I'm aware that with currently ~13,000 packages in tree and ~4,000 packages in the Gentoo Smolt database the zero-install list holds ~7,000 packages. With more submission I expect that number to decrease strongly in the future. With that in mind, what do you think? Sebastian
[gentoo-dev] Re: Gentoo stats server/client @ 2009-08-22
On 08/22/2009 07:06 AM, Sebastian Pipping wrote: Nikos Chantziaras wrote: Done. Seems to work OK. Though there's no info about the scanning of packages and my profile page only lists hardware. I cannot find any new entries in the database. Have you been using --server=http://smolt.hartwork.org:45678/ on submission? I mentioned that in previous threads and didn't think of a need mentioning it again, sorry. Oops, never saw that, sorry. I simply followed the advice of the ebuild: * Call smoltSendProfile as root in order to initialize your profile. and thought that's enough. Perhaps the ebuild should mention the --server parameter, or even better install a config file that sets molt.hartwork.org:45678 as default (so that smoltGui can actually be used at all since it doesn't take a --server parameter.) Before submission you can view all the data you submit. Near the bottom should be a long list of package details, right above the privacy metrics table. No, I don't get anything like that. I get a *lot* of errors at the beginning; a *big* stream of: ERROR:dbus.proxies:Introspect error on :1.0:/org/freedesktop /Hal/Manager: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type=method_call, sender=:1.27 (uid=0 pid=17288 comm=/usr/bin/python) interface=org.freedesktop.DBus.Introspectable member=Introspect error name=(unset) requested_reply=0 destination=:1.0 (uid=0 pid=1668 comm=/usr/sbin/hald)) [...several hundreds more snipped...] And at the end: Smolt has collected four types of information: General Default run level: 3 Language: en_US.UTF-8 OS: Gentoo Base System release 2.0.1 ... Devices [...snipped...] File system-related [...snipped...] Distribution-specific No data, yet The v answer also doesn't show anything Gentoo related. I don't know if it submitted them nonetheless. My profile is: http://smolt.hartwork.org:45678/client/show_all/pub_55c08510-d9f6-4cb0-832f-263e554e76ec
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
Ryan Hill wrote: On Fri, 21 Aug 2009 17:29:12 -0700 Chip Parker infowo...@gmail.com wrote: If you were building a house, and the blueprints had been signed off on calling for 1 meter high doors, but the builder had built in 2 meter high doors, would you then go back to the builder and require him to do something that makes those doors unusable for the vast majority of people entering the house? Package managers can implement whatever extra bells and whistles they like, but they still have to follow the spec. Your metaphor is flawed in that you're talking about a single house here. If it doesn't match the plan you do an as-built and file a deviation with the registrar. The situation here is more like if you build a hundred houses to code, and then one above code, and then change code to match the one house and bulldoze the rest for not meeting minimal requirements. You're punishing anyone who implements a package manager to spec if you keep changing the spec in incompatible ways. Right, this is called punishing innovation. It's a hobby of bureaucrats everywhere. It could also be said to be punishing excellence. We've had a lot of political systems which try to implement a design which weeds out both the mediocre, and the excellent, leaving us with the average all have been failures. The reason why they fail is that it is the above average who do the heaviest lifting. Andrew D Kirch Funtoo.org
