Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog
On Wed, May 02, 2012 at 11:23:48AM -0400, Matt Turner wrote: Jim? Sorry, I am behind on my gentoo-dev reading, thanks Matt for bringing this thread to my attention. Here are the two main concerns I've gathered from the rest of the thread: On Wed, Apr 25, 2012 at 11:04:08PM -0600, Ryan Hill wrote: Arg, no. Please just print the warning if the host doesn't do SSE2. There's no reason to have a USE flag here (and _really_ no reason to make it fatal), especially for an instruction set that every system has supported for over a decade. It's true that probably most people have sse2. And this change won't affect all those people that have sse2. It only affects people that don't have sse2. The run-time failure case (flash just doesn't work) is tricky to diagnose, so I want the user to be aware of this at install time. Thus I feel the check should (1) be fatal and (2) provide instructions that 10.3 can still be used. The reason there's a USE flag is so that binary packagers can forcibly skip the 'die' if they know they're building for an sse2 SYSTEM. This is only needed if you're running on a machine without sse2, packaging for a machine with sse2. On Thu, Apr 26, 2012 at 05:06:45PM -0300, Alexis Ballier wrote: wouldnt adding a sse2 useflag and putting it in REQUIRED_USE solve the problem ? afaik portage wont even try to upgrade if people have -sse2 This is an interesting idea, as it could automatically downgrade users to 10.3 without requiring any masking. I like that. However, the problem I have with this approach is that it doesn't address people who do have sse2 instructions available but have not set the USE flag. I noticed that our amd64 profile does set USE=sse2 automatically. That's good. But x86 users would still have to set this manually. And people without the flag will be forcibly downgraded to 10.3 for no good reason. And as Ryan accurately points out, most people *do* have sse2 instructions available. I prefer checking /proc/cpuinfo because that way I'm *sure* that the user's system has the required instruction set. The only way I think that this decision can really be made would be to have some sort of usage statistics on how many x86 setups there are where the CPU has sse2 available but the user has not set USE=sse2. Any idea how we can know how many this is? Hmmm... I suppose the other thing I could do is put the /proc/cpuinfo check into the 10.3 ebuild, and warn users if they're installing 10.3 and *should* be setting USE=sse2 to get 11.2 instead Maybe that's the best solution! Thanks for the suggestions, I'll try to get at this change soon. -- Jim Ramsay
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog
On Thu, May 10, 2012 at 01:10:48PM -0400, Jim Ramsay wrote: On Thu, Apr 26, 2012 at 05:06:45PM -0300, Alexis Ballier wrote: wouldnt adding a sse2 useflag and putting it in REQUIRED_USE solve the problem ? afaik portage wont even try to upgrade if people have -sse2 This is an interesting idea, as it could automatically downgrade users to 10.3 without requiring any masking. I like that. Hmmm... After some testing, I don't think this is how it works. It looks to me like if I try to do an upgrade on a system that has USE=-sse2, it doesn't downgrade automatically. Nor does it simply skip the upgrade. At least with portage 2.1.10.57, I get the following fatal output: --- # USE=-sse2 emerge -uDN world -p ... !!! Problem resolving dependencies for www-plugins/adobe-flash from @selected ... done! !!! The ebuild selected to satisfy www-plugins/adobe-flash has unmet requirements. - www-plugins/adobe-flash-11.2.202.235::local USE=64bit (multilib) -32bit -kde -sse2 -vdpau The following REQUIRED_USE flag constraints are unsatisfied: sse2 (dependency required by @selected [set]) (dependency required by @world [argument]) --- So in light of this, I think I'm going to keep the fatal pkg_pretend with /proc/cpuinfo check in the 11.2 ebuild, since that's the only way I can do the check in a way that meets my 3 requirements: - No annoyance for users who have sse2 instructions present - runs at install time in a non-ignorable (fatal) way - provides useful downgrade instructions to the user Too bad pkg_pretend doesn't fire during 'emerge -p' - That would be even better. Any other suggestions on how I can make this work better? -- Jim Ramsay
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: vim.eclass
Samuli Suominen wrote: eclass has ChangeLog file now. any particular reason why you skipped it? Completely oblivious to its existence, that's all :) I'll (hopefully) remember it next time. or is it not meant to be used yet / not mandatory to use yet? since most people seem to skip it. In my case it was entirely ignorance, and with no statistical evidence to base my assertion I'll say that most other omissions come from the same cause. Though on the other hand you could argue that a Changelog for all eclasses may be a bit overkill. Most eclasses are not related to one another, so reading the CVS history of the changes to a single file is much more useful than having a big list of unrelated changes. A changelog becomes much more useful when you need to make related commits to multiple files with a non-atomic-commit system like CVS. -- Jim Ramsay Gentoo/Linux Developer (rox/fluxbox/gkrellm)
Re: [gentoo-dev] Re: rejecting unsigned commits
On Tue, May 10, 2011 at 08:19:27AM +0200, Paweł Hajdan, Jr. wrote: On 5/10/11 4:08 AM, Jim Ramsay wrote: - Does this tree signing key have to be DSA? Or is RSA okay too? No idea, I'd probably just try and see if signing works. /me plugs his ears and presses GO... Looks like it works fine! - If I have a key already, should I generate a new subkey just for manifest signing, make a whole new primary key, or just use the same key I use to sign my emails? See http://archives.gentoo.org/gentoo-dev/msg_bdc24ba33036ef413e620dc94532e080.xml, I think no separate key should be needed. You know, I even remember reading this email, but focused more on the SSL Cert recommendation part than immediate answer. Thanks :) -- Jim Ramsay
Re: [gentoo-dev] Re: rejecting unsigned commits
On Fri, Mar 25, 2011 at 02:30:20PM -0400, Mike Frysinger wrote: for people who dont have a key yet: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=6 I'm pretty new to advanced gpg usage and management, and so had a couple questions not answered by that page: - Does this tree signing key have to be DSA? Or is RSA okay too? - If I have a key already, should I generate a new subkey just for manifest signing, make a whole new primary key, or just use the same key I use to sign my emails? -- Jim Ramsay
[gentoo-dev] Lastrite: x11-plugins/gkrellm-hddtemp
No longer works (Bug #284182), and no longer needed since app-admin/gkrellm with USE=hddtemp supports reading drive temperatures natively. Removal in 30 days. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) signature.asc Description: PGP signature
[gentoo-dev] Lastrite: net-misc/amazonmp3
# Jim Ramsay l...@gentoo.org (26 Jul 2010) # Deprecated in favour of opensource alternatives: # net-misc/pymazon # net-misc/clamz # # net-misc/amazonmp3 has been masked since 2008 # Removal 30 Jul 2010 net-misc/amazonmp3 net-misc/amazonmp3-libcompat -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) signature.asc Description: PGP signature
Re: [gentoo-dev] Over using preserve_old_lib, don't do that
On Thu, Jul 15, 2010 at 07:28:40PM +0200, Markus Hauschild wrote:
On Thu, Jul 15, 2010 at 10:49 AM, Mike Auty ike...@gentoo.org wrote:
Ideally, these calls should either adhere to FEATURES=-preserve-libs,
or there should be a tool that can identify which files portage has
preserved, and allow easy rebuilding of dependent packages, and removal.
At the moment, I'm having to manually grep ebuilds, ls the libraries
and run revdep-rebuild over them one at a time...
Such a tool which can at least identify files that remain on the
system from preserved-libs or similar would be really useful in my
opinion!
What if preserve_old_libs did the following:
mv ${oldlib} ${oldlib}.preserved
ln -s ${oldlib}.preserved ${oldlib}
Cons: 2 files to delete once you're done revdep-rebuilding
Pros: Easy to tell at a glance which libs are the preserved libs.
--
Jim Ramsay
Re: [gentoo-dev] Adding AdobeFlash-10{,.1} licenses to EULA group
Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: I propose that this license be added to the EULA group. The previous AdobeFlash-10 license is similar in this regard, and could possibly also be added to that group. Agreed, on both points, and done. Thanks for finding and airing this issue! One notable section is 7.6 in which Adobe reserves the right to download and install additional Content Protection software on the user's PC. Not like anyone will actually *read* the license before adding it to their accept group, but if they did this would indeed be an important thing of which users should be aware. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) signature.asc Description: PGP signature
Re: [gentoo-dev] app-editors/vim and USE=vim-with-x - Rename to USE=X?
Mike Frysinger vap...@gentoo.org wrote: people want it and i havent seen any compelling reason to avoid it anymore, so let's rock For the record: It is now rocked. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) signature.asc Description: PGP signature
[gentoo-dev] app-editors/vim and USE=vim-with-x - Rename to USE=X?
There is an ancient bug[1] dealing with the vim-with-x USE flag. I think it makes sense to rename this flag from 'vim-with-x' to just 'X', but thought I'd raise the issue here since this USE flag has been around since before time began. Does anyone care? References: [1] http://bugs.gentoo.org/94171 -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) signature.asc Description: PGP signature
Re: [gentoo-dev] app-editors/vim and USE=vim-with-x - Rename to USE=X?
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 7 Jun 2010 23:05:27 +0400 dev-ran...@mail.ru wrote: On Mon, Jun 07, 2010 at 07:53:22PM +0100, Ciaran McCreesh wrote: It's there because if you break your X you probably want a usable editor to help you fix it. vim, compiled with vim-with-x works correctly when X is broken. It doesn't enable X11-based UI, like flag X suggests. It just enables optional connection to x-server to use its clipboard, and vim still works if that connection fails. It does not, however, work if your X libraries are broken. I certainly agree with you that removing the linkage to a handful of X libraries makes vim more robust if those particular libraries fail. However even with USE=-vim-with-x, there are a number of other libraries that, if broken, will still render vim useless, such as ncurses, perl, python, and ruby. I suspect if one really wants a fail-proof editor, one would either be building vim with USE=minimal which will ignore the 'vim-with-x' or 'X' USE flag (regardless of what we call it) and also ignore any perl/python/ruby libraries, or one would want something more trim, like busybox vi. Or even better yet, busybox vi with USE=static. Of course changing the USE flag name to 'X' would still let users decide to *not* link their app-editors/vim against any X libraries via per-package USE flags. The main difference in changing the name from 'vim-with-x' to 'X' is that instead of enforcing a default behaviour of Vim will not link against X unless explicitly told to do so, we will be enforcing a policy of Vim will link against X when USE='X'. I suppose this is a bit like a transition from an opt-in policy to an opt-out policy, with the caveat that by enabling USE=X globally, a user has already declared their intent: opt-in to linking against X in all packages where there is a choice to do so. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) signature.asc Description: PGP signature
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
Peter Volkov wrote: ?? ??, 13/04/2010 ?? 17:18 +0530, Nirbheek Chauhan ??: The traditional ChangeLog that is currently employed in gentoo-x86 (and in other projects) is simply an ugly hack The difference between gentoo-x86 ebuild ChangeLogs and ChangeLogs used in other projects is I think another very important distinction (that you imply below, but I want to specifically point out here) is that we have *many* per-project ChangeLogs whereas most other projects have a *single* monolithic ChangeLog. Think of it like this: if you make a typo in a commit message, or forget to add something; you can't change it after you've published the commit (cvs/svn commit or git push) to the world. And then it's better to keep ChangeLogs. For developers it was never a problem to script `echangelog log repoman commit -m log` and conflict resolution is really not that hard with git. In spirit of Gentoo, it's better to write some tool to update Manifests after conflict resolution instead of making ChangeLogs less useful for those who uses them. This is a very good point regarding ease of conflict resolution. Further to my other point above, the traditional ChangeLog ugliness really only hits you with a centralized setup+git if *everyone* is editing the *same* ChangeLog: If every commit touches the same file in the same place (ie, prepending to a ChangeLog file in the same location), you are guaranteed to have collisions every time you pull a new version of the file. This is why most projects with a single monolithic changelog auto-generate them, or perhaps just craft them at release time. Our case, though it is a centralized repository model, is quite different. The chance of collisions in a package-specific ChangeLog is, as it is today with CVS, pretty unlikely. In fact, I think the only time it usually happens to me is when an arch stabilizes my package while I'm making a change, and these are very easy to fix. (In fact, it may be possible to help git out with this specific ChangeLog situation by using a custom merge driver, see GITATTRIBUTES(5) for details, though deployment of a custom merge driver can be tricky) BTW as for profiles ChangeLogs... May be it's better to generate them. That's another important distinction and probably a good idea. I think those profile ChangeLogs are also not as user-facing as the per-package ones, so an autogenerated one makes a lot of sense. -- Jim Ramsay Gentoo/Linux Developer (rox/fluxbox/gkrellm) pgpnnsBkS27K2.pgp Description: PGP signature
Re: [gentoo-dev] 2009 Council Elections
Richard Freeman ri...@gentoo.org wrote: I suspect most devs just avoid the drama. ++ Less worrying, more working -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) signature.asc Description: PGP signature
Re: [gentoo-dev] net-www category
Ulrich Mueller u...@gentoo.org wrote: Another question is if the existing ones should still be moved to some www-* category? Should? I have no idea. Where exactly would we move these packages? The quasi-more-usefully-named www-misc? Though I seriously have no objection to either keeping things where they are or moving them around. My only request is that if someone does this I'd like to take the opportunity to rename 'netscape-flash' to 'adobe-flash' at the same time. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: EAPI cheat sheet for your desktop
Christian Faulhammer fa...@gentoo.org wrote: Ulrich Mueller u...@gentoo.org: On Tue, 31 Mar 2009, Christian Faulhammer wrote: Have a look at URL:http://v-li.de/temp/eapi_cheatsheet.pdf, print it, fold it and tell me if you like or not (and especially what exactly). The Gentoo store should have a coffee mug with this. ;-) That way my business plan to finally benefit financially from Gentoo. Millions of copies sold for sure. :) Especially if I have to buy a new mug every time a new EAPI comes out! -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) signature.asc Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Petteri Räty betelge...@gentoo.org wrote: 2) EAPI in file extension - Allows changing global scope and the internal format of the ebuild a) .ebuild-eapi - ignored by current Portage c) .eapi.new extension - ignored by current Portage Any of the above are fine with me, there is a demonstrated need for this to introduce changes that current portage could not handle. 3) EAPI in locked down place in the ebuild - Allows changing global scope - EAPI can't be changed in an existing ebuild so the PM can trust the value in the cache - Does not allow changing versioning rules unless version becomes a normal metadata variable * Needs more accesses to cache as now you don't have to load older versions if the latest is not masked a) new extension 3.a is just like glep-55, except that the filename extension doesn't change all the time. I like that this will have the benefits of glep-55 plus the benefits of making happy the people who don't want the EAPI in the filename or the extension to change very often. This will effectively change a single EAPI number into a major/minor pair. The major part (the extension name) would only ever change when a major feature is introduced that breaks the current portage rules. The internal EAPI, specified however we like in the major format specification, could be in a fixed location or otherwise easily parseable. Then small changes would alter this minor/internal EAPI value. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim)
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 24 Feb 2009 12:25:27 -0500 Jim Ramsay l...@gentoo.org wrote: ...and it means we can't change name or version rules. ...and it means over doubling the best possible time to work out a dependency tree in the common case where the metadata cache is valid. ...and it means we can't make arbitrary format changes. Those would all land in the category of backwards compatibility mentioned below, as they would all break current sourcing rules. No, they're also future issues. Without glep 55, every time they come up we have to go through the whole mess again. This minor/major EAPI scheme is exactly equivalent to glep 55 in the ways that it addresses the non-implementation-specific details - It could even be added as a caveat to glep-55 that says something like: You should not change filename extension (ie, major-EAPI version, or EPARSE version, or whatever we want to call it...) except when you *have to* because of changes such as name or version rules, arbitrary format changes, or anything else that breaks the sourcing rules of the existing filename extensions. Simpler feature improvements can be done using whatever internal minor-EAPI version is defined by the major-EAPI version. This doesn't prevent you from changing the filename extension when you have to do so, it just suggests that maybe you don't have to do it for every single feature-set you may want to implement. Developers already have to stop and think and consult the conveniently available table of features for EAPIs. By splitting the EAPI concept in two you're doubling the amount of data to be learnt. I would think that this is a very small cost, and the benefit would be (I hope) that more people would agree on the solution and then we can go forward. Is that not a valid consideration? I'd expect to see changes that would warrant a major bump in every other EAPI or so anyway, so it's not really worth the complexity. If that is indeed the case, then adding this caveat to glep-55 is basically a nop. If every EAPI includes a non-backwards-compatible change that breaks existing PMs, the filename extension will be changed every time. But when you say worth the complexity, I'm not exactly sure what your standards of worthiness are. I don't think the human cognition of a 2-level versioning scheme is that tricky, so I assume you must mean complexity in the internals of package managers - but this should just be a Simple Matter Of Programming. I'll further qualify this response by mentioning that I am not a package manager maintainer. I don't know beans about metadata and cacheing and what the tradeoffs may be between a two-level EAPI and a single-level EAPI stored in the filename. I understand that parsing two-level EAPI is more expensive than a single-level stored in the filename. I don't however know how to figure out if it is too expensive, or whose subjective scale we should use to measure this. I personally feel the complexity that you say is too costly is a fair tradeoff for a proposal that people will accept. (Of course I have no idea if people actually would accept a two-level EAPI any more than glep-55 as-is... I just think it addresses the concerns I've heard in this thread in a way that does not break the valid solutions to real problems presented in glep-55) -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) signature.asc Description: PGP signature
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: People are struggling with the one level scheme we have now. We're already having to produce fancy tables and summaries for new EAPIs because people can't keep track of when features came along. Two levels just means no-one will remember any of it. I disagree with your assertion that people are struggling - I think things are very nicely documented in PMS and the devmanual, which are where all EAPI changes should be documented in the future, regardless if you specify the EAPI in the file, the extension, or both. Two levels really just means that any fancy tables will have to have one extra row (or perhaps a series of fancy tables) and any summaries will have to have an extra section added whenever a new filename extension becomes necessary. For the package manager, it's just a bit of added mess, not any major difficulty. This is good to know, thank you for the clarification. People are opposed to 55 because of a knee-jerk reaction against changing file extensions and against doing anything that comes from the great Satan and all his little minions... If you're going to throw an equivalent but supposedly compromising solution at people, go for '.eapi3.eb' instead. I can't speak to anyone's motivations or religious beliefs other than my own here, but the opposition I have heard most often in this thread is something like: I don't like it when the file extension changes so often. Some people site historical president or the way other software does things, or whatever - doesn't really matter. What does matter is that some people don't like it when the file extension changes very often. I think my solution is a valid compromise because it balances, in my opinion, the two camps, whose arguments I summarize as: glep-55'ers: I don't care if the file extension changes all the time, I just want a solution that works and is reasonably future-proof Anti-55'ers: I don't want the file extension to change ever, but I would agree that for major-enough changes it may be required sometimes If I understand the '.eapi3.eb' to which you make passing reference, this is just a fancy hand-wavy way to say Look, the true .eb extension won't ever change, just the .eapi3 part which isn't technically the extension... which isn't a compromise at all - It's an attempt to (cleverly?) obfuscate where in the filename the EAPI is stored. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 24 Feb 2009 15:07:29 -0500 Jim Ramsay l...@gentoo.org wrote: I think things are very nicely documented in PMS and the devmanual, which are where all EAPI changes should be documented in the future, regardless if you specify the EAPI in the file, the extension, or both. They only ended up nicely documented after people moaned a lot that they were having a hard time keeping track of EAPIs... You can't possibly be suggesting that everyone will be able to keep an ever-increasing number of feature sets in his or her mind, or that changing from a two-level to a one-level EAPI definition will remove the need for documentation going forward, so I'm not sure what you mean by this. Two levels really just means that any fancy tables will have to have one extra row (or perhaps a series of fancy tables) and any summaries will have to have an extra section added whenever a new filename extension becomes necessary. It'll mean people will carry on having to use the tables, and won't start remembering things as time goes on. See comment above. The need for documentation will only increase going forward as new and varied EAPI definitions are created. If I understand the '.eapi3.eb' to which you make passing reference, this is just a fancy hand-wavy way to say Look, the true .eb extension won't ever change, just the .eapi3 part which isn't technically the extension... which isn't a compromise at all - It's an attempt to (cleverly?) obfuscate where in the filename the EAPI is stored. Yup. And yet there're people who are perfectly happy with .eapi3.eb who hate GLEP 55. That should tell you all you need to know about what's going on here... Seriously? That's scary. But hey, if that's actually going to get more people behind this, let's do it instead. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) signature.asc Description: PGP signature
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 24 Feb 2009 15:37:36 -0500 Jim Ramsay l...@gentoo.org wrote: They only ended up nicely documented after people moaned a lot that they were having a hard time keeping track of EAPIs... You can't possibly be suggesting that everyone will be able to keep an ever-increasing number of feature sets in his or her mind, or that changing from a two-level to a one-level EAPI definition will remove the need for documentation going forward, so I'm not sure what you mean by this. That's exactly what I mean. Developers can probably just about keep up with the two or three EAPIs they'll ever be working with on a regular basis, but they probably can't keep up with that if you double it. Well, if you're assuming only two or three EAPIs in 'mental cache' at any one time under glep-55, I'm not sure how this changes wrt. a two-level system. A two-level system doesn't change the number of EAPIs in the tree or available to developers, it just changes how they are named. Regardless, this does not remove the need for documentation. All the EAPIs should be documented in both the PMS and the devmanual. This makes it possible for new developers to learn about the current features available, and also helps existing devs who may need to recover from 'mental page faults' from time to time. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Alistair Bush ali_b...@gentoo.org wrote: Tiziano Müller wrote: Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Doesn't that just add extra complexity for no gain. Actually, I think there would be a huge gain. The gain would be that suddenly all those who oppose glep-55 because they're afraid the filename suffix will change too often will suddenly have nothing to worry about. For those who think glep-55 is the right thing to do, it really *is* glep-55, but with a small caveat that we shouldn't just change the filename extension for every single little feature enhancement. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm,fluxbox,vim)
Re: [gentoo-dev] EAPI-2
Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 9 Sep 2008 22:14:57 -0400 Jim Ramsay [EMAIL PROTECTED] wrote: I was personally expecting to see some sort of section called EAPI-1 that contains something like: EAPI-1 consists of EAPI-0 with the following features added... Have a look at the eapi-differences-summary branch on git://git.overlays.gentoo.org/proj/pms.git . Is that roughly what you're after? From what I could make out of the raw latex code, yes! Unrelated topic: What packages are actually required to 'make pms.pdf' so I can actually read it? I get: ! LaTeX Error: File `appendix.sty' not found. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] EAPI-2
Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 09 Sep 2008 16:31:08 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Jorge Manuel B. S. Vicetto kirjoitti: and cardoe's earlier request to the council ml, can the council members discuss this proposal and consider voting it? Does anyone have any objections to this proposal? I won't approve it for use in the tree before it's written as a GLEP in order to avoid the fiasco with EAPI 1 (it's still not documented properly). I can however approve the list of items. What about the PMS EAPI 1 documentation do you consider 'not proper'? I was personally expecting to see some sort of section called EAPI-1 that contains something like: EAPI-1 consists of EAPI-0 with the following features added... Then an explanation of each change and the appropriate syntax. I did see how EAPI-1 is integrated throughout the document, which is valuable in a different way - but it's harder to answer the question What exactly does EAPI-1 add to EAPI-0? Perhaps I'll try sending you a patch with something like that, if I have time, and if it would be appreciated. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
[gentoo-dev] New license for inclusion in the tree: 'amazonmp3'
This license governs a single piece of software, the mp3.amazon.com download utility, which I would like to add to the tree shortly. I don't think there's anything exceedingly wrong about this license, just a standard closed-source thou shalt not... license that RESTRICT=fetch deals with nicely. Thought I'd post it here to double-check it looks okay. Original source is: http://www.amazon.com/gp/help/customer/display.html?ie=UTF8nodeId=200154280 -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) *Amazon MP3 Music Service: Terms of Use* THIS IS AN AGREEMENT BETWEEN YOU AND AMAZON DIGITAL SERVICES, INC. (WITH ITS AFFILIATES, AMAZON OR WE). BEFORE USING THE AMAZON MP3 MUSIC SERVICE (THE SERVICE), PLEASE READ THESE TERMS OF USE, ALL RULES AND POLICIES RELATED TO THE SERVICE (INCLUDING, BUT NOT LIMITED TO, ANY PRODUCT-SPECIFIC RULES OR USAGE PROVISIONS SPECIFIED ON ANY PRODUCT DETAIL PAGE OR IN ANY LINK FROM A PRODUCT DETAIL PAGE), THE AMAZON.COM PRIVACY NOTICE, AND AMAZON.COM CONDITIONS OF USE (COLLECTIVELY, THIS AGREEMENT). IF YOU USE THE SERVICE, YOU WILL BE BOUND BY THE TERMS OF THIS AGREEMENT. 1. The Service 2. Digital Content 3. Software 4. Reservation of Rights 5. Territorial Restrictions 6. General *1. The Service* The Service offers downloads of digitized versions of audio recordings, artwork and information relating to such audio recordings, and other content (individually and collectively, Digital Content) and other services under the terms and conditions in this Agreement. *2. Digital Content* *2.1 License. *Upon your payment of our fees for Digital Content, we grant you a non-exclusive, non-transferable license to use the Digital Content for your personal, non-commercial, entertainment use, subject to and in accordance with the terms of this Agreement. You may copy, store, transfer and burn the Digital Content only for your personal, non-commercial, entertainment use. *2.2 Restrictions. *You represent, warrant and agree that you will use the Service only for your personal, non-commercial, entertainment use and not for any redistribution of the Digital Content or other use restricted in this Section 2.2. You agree not to infringe the rights of the Digital Content's copyright owners and to comply with all applicable laws in your use of the Digital Content. Except as set forth in Section 2.1 above, you agree that you will not redistribute, transmit, assign, sell, broadcast, rent, share, lend, modify, adapt, edit, sub-license or otherwise transfer or use the Digital Content. You are not granted any synchronization, public performance, promotional use, commercial sale, resale, reproduction or distribution rights for the Digital Content. You acknowledge that the Digital Content embodies the intellectual property of a third party and is protected by law. *2.3 Explicit Content. *You agree that we have no liability to you for Digital Content you find to be offensive, indecent or objectionable. *2.4 All Sales Final; Downloading and Risk of Loss; Availability of Digital Content. *All sales of Digital Content are final. We do not accept returns of Digital Content. Once you have purchased Digital Content, we encourage you to download it promptly and to make back-up copies of it. If you are unable to complete a download after having reviewed our online help resources, please contact Amazon customer service. You bear all risk of loss after purchase and for any loss of Digital Content you have downloaded, including any loss due to a computer or hard drive crash. We may, from time to time, remove Digital Content from the Service without notice. *3. Software* *3.1 General. *We may make available to you, from time to time, software for your use in connection with the Service (any and all such software, individually and collectively, the Software). *3.2 Use of the Software. *You may use the Software only in connection with the Service. You may not separate any individual component of the Software for use other than in connection with the Service, may not incorporate any portion of it into your own programs or compile any portion of it in combination with your own programs, may not transfer it for use with another service, or use it, or any portion of it, over a network and may not sell, rent, lease, lend, loan, distribute or sub-license the Software or otherwise assign any rights to the Software in whole or in part. We may discontinue some or all of any Software we provide, and we may terminate your right to use any Software at any time and in such event may modify it to make it inoperable. *3.3 No Reverse Engineering, Decompilation, or Disassembly; Updates. *You may not, and you will not encourage, assist or authorize any other person to, modify, reverse engineer, decompile or disassemble the Software, whether in whole or in part, or create any derivative works from or of the Software. We may offer
Re: [gentoo-dev] License Interpretation
Good news everyone! This has become a non-issue, at least in the next version of flash player[1]. Thanks again for all your input! [1] http://blogs.adobe.com/penguin.swf/2008/08/curl_tradeoffs.html -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm) signature.asc Description: PGP signature
[gentoo-dev] License Interpretation
IANAL, and I'm sure most of us aren't either, but I would appreciate some opinions on Bug https://bugs.gentoo.org/234542 and whether the binary patch proposed there conflicts with section 2.5.1 of the license agreement from Adobe: http://www.adobe.com/products/eulas/pdfs/Reader_Player_WWEULA-Combined-20060724_1430.pdf Specifically, here is the passage I'm wondering about: 2.5.1 You may not modify, adapt, translate or create derivative works based upon the Software. You may not reverse engineer, decompile, disassemble or otherwise attempt to discover the source code of the Software except to the extent you may be expressly permitted to decompile under applicable law, it is essential to do so in order to achieve operability of the Software with another software program, and you have first requested Adobe to provide the information necessary to achieve such operability and Adobe has not made such information available. I *think* I would be okay using this binary patch since: 1) This is specifically to make it operable with libcurl.so.4 2) I have (and others have) asked Adobe to recompile it with support for libcurl.so.4 instead of libcurl.so.3, but they have not done so (or responded to any of these requests, as far as I am aware). Anyone care to weigh in, lawyer or not? -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] metadata.xml USE flag descriptions
Doug Goldstein [EMAIL PROTECTED] wrote: If people wish to take specific categories, please let this thread know. I just did the rox-base and rox-extra categories. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm) signature.asc Description: PGP signature
[gentoo-dev] RFC: Should 'imlib' USE flag be on by default in x86 and amd64 desktop profiles?
I've run into it a few times now that fluxbox users running Gentoo wonder why they can't get icons to work in the fluxbox menus. The short answer is that 'imlib' is off by default in many profiles, including default-linux/amd64/2007.0/desktop and default-linux/x86/2007.0/desktop I know that I could turn it on by default for fluxbox only using EAPI-1, but since it's a global USE flag, the profiles may be a better place. I think imlib is something most desktop users would want, since it lets them see all those pretty graphics. Comments? Concerns? -- Jim Ramsay Gentoo/Linux Developer (rox/gkrellm/fluxbox) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: 0-day bump requests
Ryan Hill [EMAIL PROTECTED] wrote: On Mon, 7 Jul 2008 10:10:14 -0400 Jim Ramsay [EMAIL PROTECTED] wrote: Here's an interesting solution for those who find it annoying though: Just file your own 0-day bump request in bugzilla. In theory some users would find this and just CC themselves on it. Other users could be shushed with the shame of the DUPLICATE. Everyone wins! I try to do this whenever there's some reason why I can't add a package right away. I also don't see the point of yelling at someone for trying to help in whatever way they can, even if that's in the form of a poke when a new version is released. I wonder if a special Version Bump template for bugzilla could be a useful thing to make this easier for both users and devs? -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] [v3] Planning for automatic assignment of bugs
Mark Loeser [EMAIL PROTECTED] wrote: Its a good idea, but since our users don't always provide useful reports, it seems like we are just shifting work around. I'd suggest that this would /spread/ work around - Instead of a few folks wrangling bugs, everyone would be doing it. That said, I have no idea how many duplicate / incomplete bugs I have never seen due to the wonderful work of the wranglers. In some ways it would be a shame to lose that quality pre-reading of the bugs. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
Joe Peterson [EMAIL PROTECTED] wrote: As for why it would be more useful than eerror/ewarn without an argument: it would potentially allow for intelligent context-based coloring of the * (based on surrounding lines). Well, this is true and it isn't... In the case of: ewarn line one eblank ewarn line two Obviously it would be the same as ewarn. However, what about here: ewarn line one eblank elog line two eblank einfo line three I'm not sure how you could make a function like that smart enough to really know what to do... so perhaps since the author is the only one who can really know what colour they intend, they should just use the appropriate ewarn/elog/einfo without args. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
Benedikt Morbach [EMAIL PROTECTED] wrote: On Sun, Jun 15, 2008 at 12:02 PM, Peter Volkov [EMAIL PROTECTED] wrote: But speaking about names of options - -A and -B are easier to remember as -A stands for above and -B for below and grep users already knew that. for grep -A means after and -B before ;) Maybe we could have '-^' and '-v' then? I do kind of like the idea of making these flags available for people who think it makes their ebuilds prettier... I just don't think I'll even use them. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
Vlastimil Babka [EMAIL PROTECTED] wrote:
I would prefer something that
doesn't add extra lines to ebuild.
I think I would disagree with you here. I think that having a special
'eblank' or 'eseparator' command is much more readable in an ebuild.
Consider:
pkg_postinst() {
elog Knock knock
eblank
ewarn Who's there?
eblank
elog Interrupting Cow
eblank
ewarn Interrup...
elog Moo!
}
Versus:
pkg_postinst() {
elog -p Knock knock
ewarn Who's there?
elog -pt Interrupting Cow
ewarn Interrup...
elog Moo!
}
I think that in the former case it's much more obvious how the actual
output is going to look. If the cost is an ebuild that's 3 lines
longer, I think that's reasonable.
--
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)
signature.asc
Description: PGP signature
Re: [gentoo-dev] EAPI-2 - Let's get it started
David Leverton [EMAIL PROTECTED] wrote: Since at least one ebuild has already been modified specifically to work around the bug, I'd say it's pretty real. For those of us trying to play along at home, which one is this? -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
Olivier Galibert [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 03:14:47PM +0100, Ciaran McCreesh wrote: !-- EAPI=3 -- *Then* would be the time to change the extension. As long as the ebuild is bash-parseable with an appropriate environment, it doesn't make sense to change the extension because a env-variable set or a comment are more natural methods. If/when the format changes to something not parseable by bash, then it will be time to change the extension. And then how to mark (sub-)version will depend on the chosen new format, in case of xml that would be the dtd information. I suspect the rejection of the extension change will be there as long as the fundamental format (bash script) doesn't change. Well said. This is something that I've heard bandied about on IRC now and then, and sounds to me (notably *not* a package manager developer) like a fairly reasonable compromise. To the proponents of GLEP55: Is there some reason that GLEP55 is preferable to this? Are there reasons why a particular filename extension could not apply to a range of EAPIs? Why not just bump the filename suffix when it is required to support a new EAPI that breaks the sourcing rules of previous EAPIs? Or will backwards-incompatible changes be happening so frequently that the package suffix will have to change for every EAPI bump anyway, which would make this proposal equivalent to GLEP55? -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55
Santiago M. Mola [EMAIL PROTECTED] wrote: On Thu, Jun 12, 2008 at 4:07 AM, Jim Ramsay [EMAIL PROTECTED] wrote: Why not just bump the filename suffix when it is required to support a new EAPI that breaks the sourcing rules of previous EAPIs? Or will backwards-incompatible changes be happening so frequently that the package suffix will have to change for every EAPI bump anyway, which would make this proposal equivalent to GLEP55? That works. Although, we'd have to keep track of two parameters when setting our EAPI. One being the EAPI itself and the suffix needed for that EAPI. So this doesn't seem to make the problem simpler. I agree that it doesn't make things simpler. Though it doesn't make things that much more complex. That said, I'm becoming more convinced that a lot of the changes that really need to be made will indeed break EAPI sourcing rules, so maybe the latter part of my original quote above will indeed be the case - This would be equivalent to GLEP55. I should add that I am not personally opposed to having the EAPI in the filename, but this may find slightly more acceptance from the folks who think that solution is incorrect. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] New developer : Markus Duft (mduft)
Denis Dupeyron [EMAIL PROTECTED] wrote: Please everybody, give a very warm welcome to mduft. Lay on, mduft, And damn'd be him that first cries, 'Hold, enough!' Exeunt, fighting. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
[gentoo-dev] Last rites: x11-plugins/gkrellm-bfm
# Jim Ramsay [EMAIL PROTECTED] (31 Jan 2008) # Masked for removal in 30 days. Replaced by # x11-plugins/bfm with USE=gkrellm. Bug #207720 x11-plugins/gkrellm-bfm -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in rox-base/rox: ChangeLog rox-2.7-r2.ebuild
Donnie Berkholz [EMAIL PROTECTED] wrote:
On 15:05 Mon 17 Dec , Jim Ramsay (lack) wrote:
lack07/12/17 15:05:57
IUSE=+svg +video
svg already defaults on for all the desktop profiles, so I'm not
really sure what that's gaining you.
Good point, removed '+' there
RDEPEND==x11-libs/gtk+-2.4
=dev-libs/glib-2.2
=dev-libs/libxml2-2.4.23
=x11-misc/shared-mime-info-0.14
svg? ( gnome-base/librsvg )
!ppc? ( rox-base/mime-editor
rox-base/thumbs
video? ( rox-extra/videothumbnail ) )
PPC users aren't supposed to get this stuff? If not, is it even a
real dependency?
I'm waiting on bug 201983 for ppc to keyword those ebuilds. They are
semi-optional runtime dependencies. I'll explain further:
There are buttons in the ROX application's options window which
launch each of these applications. Thus they are not *strictly*
required for basic operation, but are required for all the buttons in
the app to actually work. videothumbnail is USE-dependent because it
needs either mplayer or totem, neither of which are very quick to
install. The other two however (mime-editor and thumbs) are reasonably
simple python apps that really only take a second or so to download and
install.
(cd src; make clean) /dev/null
Subshells are icky.
I agree, replaced them all with pushd/popd instead.
chmod 0755 ${D}/usr/bin/${WRAPPERNAME}
chmod 0755 ${D}/usr/bin/${WRAPPERNAME}uri
fperms?
Ah yes. Done.
make_desktop_entry ${WRAPPERNAME} ${APPNAME} ${APPNAME}.png
System;Utility;Core;ROX
Thought I saw something about desktop entries dropping the suffix for
the icon, but I don't recall the details.
Yes, this is correct. I have removed it. Also technically speaking
there is no 'ROX' category (any more?) so I have removed it as well and
made it better match the defined menu categories.
--
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Fernando J. Pereda [EMAIL PROTECTED] wrote: On Wed, Dec 19, 2007 at 04:17:21PM +0100, Luca Barbato wrote: Piotr Jaroszyński wrote: Mixing EAPIs can't work. Why? Because EAPIs can define colliding features. The sense I've gotten from this discussion so far is that if you want features from two EAPIs you know *can* be combined without collisions, you should define a third EAPI that is a superset of the other 2. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Luca Barbato [EMAIL PROTECTED] wrote: How would it be different than having EAPI=string put in a defined position of the file? It's not - It is just defining that position to be in the name of the file instead of the contents :) -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in rox-base/rox-clib: ChangeLog rox-clib-2.1.10.ebuild
Donnie Berkholz [EMAIL PROTECTED] wrote: Instead of these subshells to save the original directory, a more common technique is pushd/popd. Another possibility is 'cd foo; stuff; cd -', but that doesn't stack. That's an excellent idea, I'll update these to not use subshells in the future. Is there some sort of equivalent way to back-out of whatever 'insinto' does to the environment? -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: rox-0install.eclass
Donnie Berkholz wrote:
I don't remember this going by gentoo-dev. Always send eclasses to
gentoo-dev before committing them.
My apologies, I was just so excited that I'd finally finished it!
Apparently I missed a few things, thanks very much for catching
it.
0install_native_feed() {
local src=${1}; shift
local path=${1}; shift
This is a rather strange paradigm to me, instead of:
local src=$1 path=$2
shift 2
This is cleaner, thanks. In fact, I don't even really need the
shift at all.
local feedfile=$(basename ${src})
You could do this in pure bash, although it doesn't really matter:
local feedfile=${src##*/}
Sure, may as well, save a subshell.
local dest=${path}/$feedfile
How do you decide when not to use braces { } around variables?
In general I've used them everywhere... except there :) Fixed.
0distutils ${src} tmp.native_feed || die 0distutils feed edit
failed
if [[ ${ZEROINSTALL_STRIP_REQUIRES} ]]; then
# Strip out all 'requires' sections
sed -i -e '/requires.*\//d' \
-e '/requires.*\/,/\/requires/d' tmp.native_feed
What happens if the contents of a requires section are on a separate
line? Is this a concern?
It hasn't been so far - The convention in all known cases is
either it's all on one line, or a multi-line as is caught by the
second sed expression. This is just a stopgap measure until I
rework 0distutils to do this optional stripping on its own.
local feedname
You could just declare feedname local and set it in the same line.
Not if I want to potentially die on the assignment. As I found
out in #gentoo-dev-help today, try this:
$ t() { local a=$(false) || echo Die; }; t
Versus this:
$ t() { local a; a=$(false) || echo Die; }; t
Die
feedname=$(0distutils -e ${src}) || 0distutils URI escape failed
What's the || doing? You've got a string sitting there. Is 'die'
missing?
Verily - nice catch!
if ! $installed; then
This is kind of a weird way to do it. I'd check instead for
[[ -n ${installed} ]] and initialize it to empty.
Sure, that looks nicer.
I'll be committing these changes right away, since the die ones
at least are very important. But I'll be submitting further
changes to the list first. Sorry about that :)
Luckily only 1 ebuild so far which uses this eclass has actually
hit the tree!
--
Jim Ramsay
Gentoo/Linux Developer (rox/fluxbox/gkrellm)
pgp2FsjDFSTI0.pgp
Description: PGP signature
Re: [gentoo-dev] Changes to rox.eclass
Petteri Räty [EMAIL PROTECTED] wrote: Next time could you please use a text/plain diff as the attachment. I thought about doing that, but because of all code movement, the unified diff was kind of ugly. As I'm sure you'll see on the cvs list, now that I've committed the thing. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Changes to rox.eclass
Ryan Hill [EMAIL PROTECTED] wrote: Looks good here. Thanks, former fellow Saskatchewanain. I've committed it. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
[gentoo-dev] EAPI feature suggestion: OBSOLETES (was: gentoo-x86 commit in profiles/updates: 4Q-2007)
Whether or not 'move' was the correct action in the recent compiz example, perhaps we need to consider that some times one package does actually make another obsolete. The correct thing for the PM to do is to first uninstall the obsolete package, then install the new one. Now, it has been my experience that blocking dependencies are currently used to imply this No, you have to remove cat/foo first before installing cat/bar instead situation. This is somewhat annoying for me when I want to upgrade a bunch of packages, but I have to manually uninstall a few blockers first before this is possible. This could be automated by the PM in those cases with some sort of thing like this in the cat/bar-1.0.ebuild: OBSOLETES=cat/foo Of course this would be a regular package atom (or list thereof), so it could be tied to specific versions of cat/foo. I suppose this could be seen as a special case of blocking deps which would automate a specific cat/bar is to be preferred over cat/foo However, I'm not exactly sure what you would do if you have pkg1 which depends on cat/foo and pkg2 which depends on cat/bar... -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use
Robin H. Johnson [EMAIL PROTECTED] wrote: how soon can we start to use it to replace the old crufty no* flags So what's going on here? Do we need to wait for EAPI=1 and use the new IUSE defaults? Or can we use package.use right now? I also have some 'disablefoo' USE flags I want to clear out for the 1.0.0 release of fluxbox. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: net-im/pidgin protocols
fire-eyes wrote: Duncan wrote: OTOH, if enabling those protocols pulls in all sorts of additional packages to support them, shipping with everything on just because it's possible is not the Gentoo way. That's what USE flags are for. If indeed additional dependencies are pulled in, IMO the USE flags should remain, and maybe someone needs to explain the Gentoo way to upstream. ++; from a user. I prefer to leave them off. However I can understand the other sides point of view, too. I believe one of the main philosophies of Gentoo is to try to have an app be as close to upstream as possible. I personally believe that this means the we should try to enable enough USE flags by default that it is roughly equivalent to running upstream's './configure' with no arguments. USE flags then give the advanced user the ability to disable those features normally on, or enable those features normally off, but we want a freshly installed package by default to just work[1] and to be as close to upstream as possible[2]. With this in mind, enabling most of the default protocols makes sense to me. [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3chap=1#doc_chap1 [2] looking for actual references to this, but couldn't find it... I think it's _somewhere_ in the required new-developer reading... -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007/08
Jan Kundrát wrote: lack (he's a bit fresher, but his mails are good) Thanks very much, I appreciate the nomination! But I must decline. I don't feel that I have enough experience in Gentoo land yet. Plus I'll be starting a new job next month and am not yet sure how much time I can commit. Ask me again in a year :) -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] ML changes
Seemant Kulleen wrote: Thanks for expressing your point of view that clearly. I stand with you. snip: More clear arguments I'm just adding one more comment that I don't think I've seen yet in this thread. (Although it's been a long thread, and I don't remember all the points from all the other mails this late in the game...) To my recollection, the recent flame wars have for the most part been between devs and non-devs. Now, this proposed moderation only addresses one half (the non-dev side) of that problem, by moderating it away. I personally think that a better solution would be to address the @gentoo.org side of the problem, since that is, in theory, something that we already have control over via devrel. If we have our own house in order and provide leadership and direction on the list by not replying to personal attacks (or perceived personal attacks) with more personal attacks (or perceived personal attacks), and always keeping our side of the technical discussions purely technical and non-sarcastic, I really believe that flame wars will just flicker and die. Maybe this just means that we need more people to report developers acting badly to devrel. In closing, I also disagree with the Moderation Proposal. I think that it may stop the flame wars at the cost of stopping valuable discussions. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] ML changes
Mike Doty wrote: devs who moderate in bad posts will be subject to moderation themselves. Will this be monitored/enforced by the proctors? -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] glibc-2.6 / gcc-4.2 going into ~arch
Mike Frysinger [EMAIL PROTECTED] wrote: get your waaait dont do it votes in now, i plan on pushing: glibc-2.6 ~amd64 ~ppc ~ppc64 ~x86 gcc-4.2.0 ~amd64 ~x86 Are there any crazy upgrade paths like the good old libstdc++ bump? -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] glibc-2.6 / gcc-4.2 going into ~arch
Mike Frysinger [EMAIL PROTECTED] wrote: On Friday 06 July 2007, Jim Ramsay wrote: Are there any crazy upgrade paths like the good old libstdc++ bump? no And there was great rejoicing. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] gentoo-dev-announce list
Mike Doty wrote: or you could ask infra to work it's magic making any post to -dev-announce post to -dev as well and set the replt-to address for -dev-announce to -dev. that way it's all automagic. I hope you meant the List-Post header... unless we would like to have another discussion on the merits/evils of reply-to munging :) -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] gentoo-dev-announce list
Mike Doty wrote: Jim Ramsay wrote: Mike Doty wrote: or you could ask infra to work it's magic making any post to -dev-announce post to -dev as well and set the replt-to address for -dev-announce to -dev. that way it's all automagic. I hope you meant the List-Post header... unless we would like to have another discussion on the merits/evils of reply-to munging :) As an announce list, you're NEVER EVER supposed to reply to the list, so reply-to munging in this case is appropriate IMO. Reply-To is supposed to let you reply to the author, in case they need to use a different return address than what is in the From header. Which I grant is very rare for Gentoo developers. But I do agree with you that if reply-to munging is done it should indeed point at -dev and never the -announce list. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
[gentoo-dev] Help with libflashsupport for amd64
I have just added net-www/libflashsupport-1.2 for ~x86, and would like to get the help of at least one amd64 dev to ensure it also works for ~amd64 before I add it as an optional dependency to net-www/netscape-flash So, any amd64 dev who can give me a hand, please do so, and/or contact me! Thank you. For those who do not know already, libflashsupport adds pulseaudio, oss, esd, and/or ssl/gnutls support to the netscape-flash binary. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Optional Package Dependencies for netscape-flash - libflashsupport
Olivier Crête wrote: On Thu, 2007-10-05 at 14:20 -0400, Patrick McLean wrote: Jim Ramsay wrote: 1) Create a single local USE flag (flashsupport or something) that will just pull in this dependency. 2) Use the same set of USE flags as libflashsupport has, with any of them adding libflashsupport to the dep list, since these are all global flags and will most likely be enabled for both netscape-flash and libflashsupport I'm personally thinking (1) is the better of the 2 options, but I'd like to know if anyone has any other wondrous solutions to this. Does/will anything else dep on flashsupport? If not, why not just add the USE flags to netscape-flash and install libflashsupport as part of the netscape-flash install instead of a separate package. If its a separate package that will be updated separately, then it doesn't make sense to put it in the separate package and I support option 1. Otherwise, if they'll always be together, then just put it in the same package. Yes, libflashsupport is distributed separately and is on a different release schedule than netscape-flash. I suppose I could also propose: 4) netscape-flash just RDEPENDS on libflashsupport all the time. It's certainly not a large library to be added on. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Optional Package Dependencies for netscape-flash - libflashsupport
Josh Saddler wrote: Jim Ramsay wrote: I suppose I could also propose: 4) netscape-flash just RDEPENDS on libflashsupport all the time. It's certainly not a large library to be added on. That is a terrible idea. Don't make it depend on something that it clearly does *not* depend on. Flash works just fine without the optional add-ons, and those are *definitely* optional. I've never needed libflashsupport and would prefer not seeing useless cruft attached to a perfectly working Flash installation. Point taken - If you don't want the extra features you don't want libflashsupport at all. I could make it so that if all of the USE flags for libflashsupport are turned off it doesn't actually install the library at all, just gets added to the list of installed packages. If you're going to add it to USE, then make sure it's *not* on by default, thanks. This way it will adhere to your current set of global USE flags. If you have pulseaudio, esd, oss, ssl, or gnutls on globally, it will install libflashsupport with the appropriate hooks in it. If they are all off (either globally or specifically for libflashsupport) you will just get the same old netscape-flash with no add-ons. Is this a worthy compromise? -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Optional Package Dependencies for netscape-flash - libflashsupport
Olivier Crête wrote: On Fri, 2007-11-05 at 12:12 -0600, Jim Ramsay wrote: Josh Saddler wrote: Jim Ramsay wrote: I suppose I could also propose: 4) netscape-flash just RDEPENDS on libflashsupport all the time. It's certainly not a large library to be added on. That is a terrible idea. Don't make it depend on something that it clearly does *not* depend on. Flash works just fine without the optional add-ons, and those are *definitely* optional. I've never needed libflashsupport and would prefer not seeing useless cruft attached to a perfectly working Flash installation. Point taken - If you don't want the extra features you don't want libflashsupport at all. I could make it so that if all of the USE flags for libflashsupport are turned off it doesn't actually install the library at all, just gets added to the list of installed packages. If you're going to add it to USE, then make sure it's *not* on by default, thanks. This way it will adhere to your current set of global USE flags. If you have pulseaudio, esd, oss, ssl, or gnutls on globally, it will install libflashsupport with the appropriate hooks in it. If they are all off (either globally or specifically for libflashsupport) you will just get the same old netscape-flash with no add-ons. Is this a worthy compromise? This seems even worse.. I think either having one local use flag in netscape-flash is probably the best solution.. The second best is to have all of the use flags and RDEPEND on flash-support if any is enabled. Can you explain what you mean by even worse? I think my latest solution is more correct than any of the others yet proposed. In fact, here's another small improvement on it: Have netscape-flash with IUSE=vanilla (by default it is off), which when enabled will not pull in libflashsupport. This meets the following goals: 1) It makes it easy for regular users to get netscape-flash with any additions required by any global USE flags in exactly one step: - emerge netscape-flash This is my #1 goal, otherwise I'd just have 'libflashsupport' as its own separate package and those in the know would install it separately if they want any of the extra features. But users should not have to have special knowledge to get the features they have already enabled in their global USE flags. 2) It makes it easy for power users to not have libflashsupport actually install anything by disabling all the USE flags. This will take 3 steps: - Notice at upgrade or install time that there's this new 'extra' package being installed - Enable the 'vanilla' flag for netscape-flash - Continue with upgrade or install Also, having all of the ssl/gnutls/pulseaudio/esd/oss flags turned off for libflashsupport will have the effect of not actually installing the library, so the only added cost there is one more entry in the list of installed packages, which I hope you will agree is basically zero. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Optional Package Dependencies for netscape-flash - libflashsupport
Thomas Rösner wrote: Jim Ramsay wrote: [snip] Have netscape-flash with IUSE=vanilla (by default it is off), which when enabled will not pull in libflashsupport. I don't quite see why this is necessary? Or why you do have this discussion? I started this discussion to find out the best way to add libflashsupport to netscape-flash for users who want the extra features that it offers. This meets the following goals: 1) It makes it easy for regular users to get netscape-flash with any additions required by any global USE flags in exactly one step: - emerge netscape-flash So, in netscape-flash: RDEPEND= ssl? ( foo/libflashsupport ) pulseaudio? ( foo/libflashsupport ) esd? ( foo/libflashsupport ) oss? ( foo/libflashsupport ) and IUSE=ssl pulseaudio esd oss gnutls in libflashsupport (which, as already said, has it's own ebuild)? Yes, I considered this, it is option (2) in the original post in this thread. However, I do not believe this is the best solution. Consider the case where: - A user has 'ssl' disabled globally - A user sees that netscape-flash now has 'ssl' support, so he/she enables 'ssl' just for the netscape-flash ebuild. - The ebuild would then install libflashsupport, but do so without actually adding ssl support, which would be quite frustrating to the user, and probably generate unnedded bug traffic. It would be much more clear to only use the ssl USE flag when it actually affects ssl support. 2) It makes it easy for power users to not have libflashsupport actually install anything by disabling all the USE flags. This will take 3 steps: - Notice at upgrade or install time that there's this new 'extra' package being installed - Enable the 'vanilla' flag for netscape-flash - Continue with upgrade or install It's still easy enough to disable it via -* in package.use? I'm not sure I understand what you are saying here. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Optional Package Dependencies for netscape-flash - libflashsupport
Olivier Crête wrote: On Fri, 2007-11-05 at 13:19 -0600, Jim Ramsay wrote: Olivier Crête wrote: On Fri, 2007-11-05 at 12:12 -0600, Jim Ramsay wrote: Josh Saddler wrote: Jim Ramsay wrote: I suppose I could also propose: 4) netscape-flash just RDEPENDS on libflashsupport all the time. It's certainly not a large library to be added on. That is a terrible idea. Don't make it depend on something that it clearly does *not* depend on. Flash works just fine without the optional add-ons, and those are *definitely* optional. I've never needed libflashsupport and would prefer not seeing useless cruft attached to a perfectly working Flash installation. Point taken - If you don't want the extra features you don't want libflashsupport at all. I could make it so that if all of the USE flags for libflashsupport are turned off it doesn't actually install the library at all, just gets added to the list of installed packages. If you're going to add it to USE, then make sure it's *not* on by default, thanks. This way it will adhere to your current set of global USE flags. If you have pulseaudio, esd, oss, ssl, or gnutls on globally, it will install libflashsupport with the appropriate hooks in it. If they are all off (either globally or specifically for libflashsupport) you will just get the same old netscape-flash with no add-ons. Is this a worthy compromise? This seems even worse.. I think either having one local use flag in netscape-flash is probably the best solution.. The second best is to have all of the use flags and RDEPEND on flash-support if any is enabled. Can you explain what you mean by even worse? I think my latest solution is more correct than any of the others yet proposed. In fact, here's another small improvement on it: Have netscape-flash with IUSE=vanilla (by default it is off), which when enabled will not pull in libflashsupport. flashsupport should be disabled by default. I still think you should add a positive use flag to netscape-flash (call it flashsupport or or a combination of esd/ssl/gnutls/etc). I disagree with you here. I believe it should be installed by default because it would then install by default any optional features that a user has enabled in his/her global USE flags. Which I argue is the expected outcome of installing any package. I guess I still don't see what the benefit would be of having it disabled by default - It would just be making more work for users who want the added features. If you have a compelling argument for your side that I'm not seeing, please let me know what it is. This meets the following goals: 1) It makes it easy for regular users to get netscape-flash with any additions required by any global USE flags in exactly one step: - emerge netscape-flash This is my #1 goal, otherwise I'd just have 'libflashsupport' as its own separate package and those in the know would install it separately if they want any of the extra features. But users should not have to have special knowledge to get the features they have already enabled in their global USE flags. 2) It makes it easy for power users to not have libflashsupport actually install anything by disabling all the USE flags. This will take 3 steps: - Notice at upgrade or install time that there's this new 'extra' package being installed - Enable the 'vanilla' flag for netscape-flash - Continue with upgrade or install Also, having all of the ssl/gnutls/pulseaudio/esd/oss flags turned off for libflashsupport will have the effect of not actually installing the library, so the only added cost there is one more entry in the list of installed packages, which I hope you will agree is basically zero. Installing a package without really installing it is EVIL. The db should represent whats installed on the system, otherwise it will become very very confusion for users. Well, I was actually going to have it install a single README file explaining why the package didn't install very much. I could of course leave in the 'libflashsupport.so' library that would basically do nothing... Really, this is just a shortcut so that if you don't want any of the features libflashsupport provides you will not have the small overhead of having the plugin load libflashsupport.so when it starts up. For added information, here is what I understand happens when you load the existing Adobe flash plugin: - Check for a plugin called /usr/lib/libflashsupport.so - If found, load it, and use any of the functions provided there to support alternate audio, video, or ssl features. - If not found, carry on and use the default set of features: ALSA sound output and no SSL support. So the possibilities for people not wanting the added features are: - Have no such file called /usr/lib
Re: [gentoo-dev] Re: [gentoo-core] [POLICY] Keywording/Stabilizing Bug Assignment Policy
Vlastimil Babka [EMAIL PROTECTED] wrote: Or maybe implement new bugzilla keywords, like STABLEREQ and KEYWORDREQ which would be added to the respective bugs. Then you (the maintainer) can easily create (and save) an advanced search that will filter them out, while still being able to check them in a different search. Might be also useful for arch teams to separate stabling and keywording bugs? I think that's a great idea. Who do we bug to get this in there? -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] [POLICY] Keywording/Stabilizing Bug Assignment Policy
Chris Gianelloni wrote: On Wed, 2007-04-18 at 07:39 -0600, Jim Ramsay wrote: Vlastimil Babka [EMAIL PROTECTED] wrote: Or maybe implement new bugzilla keywords, like STABLEREQ and KEYWORDREQ which would be added to the respective bugs. Then you (the maintainer) can easily create (and save) an advanced search that will filter them out, while still being able to check them in a different search. Might be also useful for arch teams to separate stabling and keywording bugs? I think that's a great idea. Who do we bug to get this in there? File a bug in the Bugzilla component. I hear and obey: http://bugs.gentoo.org/show_bug.cgi?id=175103 -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
Ciaran McCreesh wrote: If something's supposed to be transparent, it shouldn't be on -core. And, conversely, if something's on -core, it's not supposed to be transparent. Opening up -core just makes it harder to handle those rare cases where things really are required to be restricted. I agree - this is precisely the reason why I personally prefer a private archive of -core. There's also the issue of whether this can legitimately be made retroactive. As Ned already pointed out, some developers only posted things to -core because they believed that it was not public. I'm fairly sure the consensus is that this would not be retroactive. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
Kevin F. Quinn wrote: People reporting bugs often get annoyed when their bug is marked INVALID; especially when they're relatively new to the Gentoo Experience. We've all seen it many times, I'm sure. I know I'm coming in late on this one, but I can see how having a bug marked as INVALID with no explanation could be hurtful to the reporter. However, if you add a comment to the effect of: Marking this as 'invalid' because it's not really a bug, just unexpected. For a longer discussion of the issue, see [[some reference link]]. and then mark the bug as INVALID, maybe that's all that would be needed. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: moving USE=server to global
Steve Long wrote: I don't see what is so dangerous about a server flag. After all I don't set doc globally, but it is a useful global flag, with clear intent, as would be server. Does it mean: A) Compile just the server, as leaving it off compiles both client AND server B) Compile the client AND server, as leaving it off compiles ONLY the client C) All of the above -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] My turn to wear the cursed medalion of retirement
/me reads one Scroll of Blessing -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: How others handle bad behaviour on mailinglists
Stephen Bennett wrote: On Fri, 9 Mar 2007 10:41:57 -0500 Philip Webb [EMAIL PROTECTED] wrote: Always be parliamentary; never be personal; have a point to make; know when to stop. 'Parliamentary' means 'follow the rules for MPs in Ottawa or Westminster'. If you've seen what goes on in the House of Commons on occasion, you'd know that those two are contradictory. I have only one response to this: Fuddle duddle [1]. [1] http://tinyurl.com/25cwu7 -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
[gentoo-dev] New eclass: gkrellm-plugin
I'm tired of maintaining essentially the same code in 20-odd ebuilds,
so I am wanting to condense the common bits into a single eclass.
Most of you probably don't care, but it may be of interest to those few
who maintain gkrellm plugin ebuilds.
I have attached my first draft of the eclass. As you can see, there
are 3 main important benefits to using this eclass:
1 - Sets up the basic dependencies shared by all gkrellm plugins
2 - New pkg_setup check to ensure gkrellm was built with USE=X (see
bug 167227 for more info on why this is necessary for 99.9% of plugins)
3 - The plugin install location is now centralized, and available via
the gkrellm-plugin_dir function, instead of each ebuild hard-coding
'/usr/$(get_libdir)/gkrellm2/plugins'
As an added benefit, the most common variant of src_install was
centralized here too.
If there are no major objections, I will add this eclass shortly, at
which point anyone is free (and encouraged!) to use it for their gkrellm
plugin ebuilds. I will begin converting all my ebuilds shortly
thereafter.
--
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# Original Author: Jim Ramsay [EMAIL PROTECTED]
#
# Purpose:
# Provides common methods used by (almost) all gkrellm plugins:
#- Sets up default dependencies
#- Adds pkg_setup check to ensure gkrellm was built with USE=X (bug
#167227)
#- Provides 'gkrellm-plugin_dir' function in lieu of hard-coding the plugins
#directory (which *may* change in the future)
#- Provides the most common src_install method to avoid code duplication.
#
# Utility Routines:
# gkrellm-plugin_dir - Returns the gkrellm-2 plugin directory
#
# Environment:
# For src_install:
# PLUGIN_SO - The name of the plugin's .so file which will be installed in
# the plugin dir. Defaults to ${PN}.so
# PLUGIN_DOCS - An optional list of docs to be installed.
#
inherit multilib eutils
ECLASS=gkrellm-plugin
INHERITED=$INHERITED $ECLASS
RDEPEND==app-admin/gkrellm-2*
DEPEND=${RDEPEND}
dev-util/pkgconfig
gkrellm-plugin_dir() {
echo /usr/$(get_libdir)/gkrellm2/plugins
}
gkrellm-plugin_pkg_setup() {
if ! built_with_use app-admin/gkrellm X \
! has X ${IUSE}; then
eerror This plugin requires the X frontend of gkrellm.
eerror Please re-emerge app-admin/gkrellm with USE=\X\
die Please re-emerge app-admin/gkrellm with USE=\X\
fi
}
gkrellm-plugin_src_install() {
insinto $(gkrellm-plugin_dir)
doins ${PLUGIN_SO:-${PN}.so}
DDOCS=README* ChangeLog AUTHORS COPYING FAQ TODO INSTALL
for doc in ${DDOCS}; do
[ -s $doc ] dodoc $doc
done
[ -n ${PLUGIN_DOCS} ] dodoc ${PLUGIN_DOCS}
}
EXPORT_FUNCTIONS pkg_setup src_install
signature.asc
Description: PGP signature
Re: [gentoo-dev] New eclass: gkrellm-plugin
Ciaran McCreesh wrote: On Thu, 8 Mar 2007 11:19:20 -0600 Jim Ramsay [EMAIL PROTECTED] wrote: I have attached my first draft of the eclass. As you can see, there are 3 main important benefits to using this eclass: You shouldn't dodoc COPYING. You don't need to set ECLASS manually any more. Good points, and thanks :) -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] New eclass: gkrellm-plugin
Petteri Räty wrote:
Jim Ramsay wrote:
ECLASS=gkrellm-plugin
INHERITED=$INHERITED $ECLASS
No need to set INHERITED yourself any more either. Ciaran already
pointed out ECLASS.
Indeed, thanks for that!
They just appeared automagically when I did 'vim foo.eclass' I wonder where
that comes from...
gkrellm-plugin_pkg_setup() {
if ! built_with_use app-admin/gkrellm X \
! has X ${IUSE}; then
eerror This plugin requires the X frontend of
gkrellm. eerror Please re-emerge app-admin/gkrellm with USE=\X\
die Please re-emerge app-admin/gkrellm with
USE=\X\ fi
}
How useful is the X use flag in gkrellm? Just thinking if it would be
better to just remove the use flag and always build that code.
Well, gkrellm consists of two optional parts:
- gkrellmd which is a monitoring daemon, which does not require X
support at all. It is meant for headless machines you would want to
monitor remotely.
- gkrellm2 which is the front-end which can monitor the local machine
and/or any machine running gkrellmd.
USE=X builds both parts.
USE=-X builds only the monitoring daemon.
I believe this is a useful distinction.
The plugins are only relevant when you have the GUI front-end in place,
except that there may be some plugins that have a gkrellmd-equivalent
part, in which case that ebuild should set IUSE=X and do its own
checking.
I suppose the alternative would be to split the ebuild into 'gkrellm'
and 'gkrellmd' ebuilds, which would indeed remove the need for the
'built_with_use' check. How is this normally done for other packages
that have, for example, both a client and server part?
--
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)
signature.asc
Description: PGP signature
Re: [gentoo-dev] New eclass: gkrellm-plugin
Marien Zwart wrote:
On Thu, Mar 08, 2007 at 11:19:20AM -0600, Jim Ramsay wrote:
gkrellm-plugin_pkg_setup() {
if ! built_with_use app-admin/gkrellm X \
! has X ${IUSE}; then
eerror This plugin requires the X frontend of
gkrellm. eerror Please re-emerge app-admin/gkrellm with USE=\X\
die Please re-emerge app-admin/gkrellm with
USE=\X\ fi
}
Any chance of plugins existing (or appearing in the future) that work
with a USE=-X gkrellm and a USE=X gkrellm the same way? In that case
that check will not do the right thing. Perhaps add a var the plugin
ebuild can set to indicate it does not need gkrellm built with X even
though the plugin has no X USE flag?
This will also error out if you try to build a plugin that has the X
USE flag with both the plugin and gkrellm itself built with -X, you
probably meant to check for use X too?
Well, my intention was that such a plugin would do its own
built_with_use checking, but I see your point, and I think that having a
Don't check for X variable the ebuild can optionally set would be a
better approach than mine - That way such an ebuild could do its own
magic based on 'built_with_use gkrellm X' without having to have
IUSE=X.
Thanks!
--
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)
signature.asc
Description: PGP signature
Re: [gentoo-dev] New eclass: gkrellm-plugin
Attached is version 2 of my draft eclass. I have incorporated the
excellent changes suggested here, and it seems to be working great on
my local overlay.
--
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# Original Author: Jim Ramsay [EMAIL PROTECTED]
#
# Purpose:
# Provides common methods used by (almost) all gkrellm plugins:
#- Sets up default dependencies
#- Adds pkg_setup check to ensure gkrellm was built with USE=X (bug
#167227)
#- Provides 'gkrellm-plugin_dir' function in lieu of hard-coding the plugins
#directory (which *may* change in the future)
#- Provides the most common src_install method to avoid code duplication.
#
# Utility Routines:
# gkrellm-plugin_dir - Returns the gkrellm-2 plugin directory
#
# Environment:
# For pkg_setup:
# PLUGIN_NO_XCHECK - If set, the default check ensuring that gkrellm2 is
# built with USE=X is skipped, allowing plugins to build with the
# gkrellmd-only case. Defaults to unset.
# For src_install:
# PLUGIN_SO - The name of the plugin's .so file which will be installed in
# the plugin dir. Defaults to ${PN}.so.
# PLUGIN_DOCS - An optional list of docs to be installed. Defaults to
# unset.
#
inherit multilib eutils
RDEPEND==app-admin/gkrellm-2*
DEPEND=${RDEPEND}
dev-util/pkgconfig
gkrellm-plugin_dir() {
echo /usr/$(get_libdir)/gkrellm2/plugins
}
gkrellm-plugin_pkg_setup() {
if [[ -z ${PLUGIN_NO_XCHECK} ]]
! built_with_use app-admin/gkrellm X; then
eerror This plugin requires the X frontend of gkrellm.
eerror Please re-emerge app-admin/gkrellm with USE=\X\
die Please re-emerge app-admin/gkrellm with USE=\X\
fi
}
gkrellm-plugin_src_install() {
insinto $(gkrellm-plugin_dir)
doins ${PLUGIN_SO:-${PN}.so} || die Plugin shared library was not
installed
DDOCS=README* Change* AUTHORS FAQ TODO INSTALL
for doc in ${DDOCS}; do
[ -s $doc ] dodoc $doc
done
[ -n ${PLUGIN_DOCS} ] dodoc ${PLUGIN_DOCS}
}
EXPORT_FUNCTIONS pkg_setup src_install
signature.asc
Description: PGP signature
[gentoo-dev] Last Rites: All gkrellm-1 plugins
# Jim Ramsay [EMAIL PROTECTED] (22 Feb 2007) # Pending removal 24 Mar 2007, bug 151446 # These gkrellm-1 plugins have no gkrellm-2 equivalent x11-plugins/gkrellm-console x11-plugins/gkrellmitime x11-plugins/gkrellm-logwatch x11-plugins/gkrellmouse x11-plugins/gkrellm-sensors x11-plugins/gkrellmwho (Well, except for gkrellmwho, which is replaced by a different package: gkrellmwho2) This is in preparation for banishing gkrellm-1 from the tree, which in turn is because it depends on gtk+-1.2, which is apparently going away some time. -- Jim Ramsay Gentoo/Linux Developer (rox) signature.asc Description: PGP signature
Re: [gentoo-dev] Last Rites: All gkrellm-1 plugins
Jim Ramsay wrote: x11-plugins/gkrellmitime My mistake, this should not have been masked, and is no longer masked. -- Jim Ramsay Gentoo/Linux Developer (rox) signature.asc Description: PGP signature
Re: [gentoo-dev] app-admin/gkrellm + x11-plugins/gkrell* stuff needs a maintainer
Jakub Moc wrote: The maintainer has been MIA for quite some time and has a retirement bug open, so the bugs are piling up. Please, have a look at the tracker Bug 165185 if you are interested in taking over this. Basically, gkrellm-1* and ebuilds that depend on it need to be removed (Bug 151446), couple of version bumps and couple of other bugs that need some loving. Well, no one else has taken this yet, so I suppose I will, since I still use the beast :) Not sure what herd I should throw it/them in, though, as most of these packages (er, the ones that even *have* a metadata.xml) have 'no-herd' in them... Maybe 'desktop-dock' is most appropriate? -- Jim Ramsay Gentoo/Linux Developer (rox) signature.asc Description: PGP signature
[gentoo-dev] A major change coming in the rox packages
I am planning on moving the install locations of all the rox-base/* and rox-extra/* applications from their current location (/usr/lib/rox) to something a little more FHS-correct[1] and tolerant of multilib support. The main reason for this change is that I got a bug from amd64 because the /usr/lib path is hard-coded all over the place (ie, not multilib compliant), but it's always sort of bugged me that these packages are in /usr/lib - They're not actually libaries (except for rox-clib). These rox applications are a new special case that don't fit into the FHS, called Application Directories[2], and I need a good place to put them. Please note that every rox application creates a symlink in /usr/bin which runs the application regardless of where it exists in the filesystem, so from an end-user perspective this doesn't really matter. (Except a small bit of migration when I actually do move these packages, which will be the topic for another day). I'd like input from any interested parties on where the proper location may be. Here are some ideas with their justifications and problems, as I see them: /usr/libexec/rox - libexec isn't actually in the FHS (that I could see), and /usr/libexec is usually assumed to contain executable code, so it may be a safe place to put things. That said, libexec is considered by some to be dead or about to disappear[3], so it may not be the right place to go. /usr/rox - This isn't in the FHS either, I would be creating it. The problem is that the FHS specifically says Large software packages must not use a direct subdirectory under the /usr hierarchy. /opt/rox - This is FHS-safe, but the gentoo convention is to reserve /opt for binary packages only, and these appdirs are not. /usr/bin/rox-desktop - This may be the most correct, since the FHS does allow subdirectories here, and doesn't explicitly prohibit new ones. Also, these are actually executable commands. The problem is that (at least considering my currently installed packages) no one else has created any subdirectories in /usr/bin. I don't know if that's a problem. Also, I can't use the name 'rox' in this place because that conflicts with a filename from rox-base/rox. I'm currently tending toward one of the last two, but am open to suggestions to persuade me toward or away from any of these, or any other, better suggestion. Inside this new location I will be further reorganizing the packages so most apps will be inside an 'Apps' subdirectory of this new location, and rox-lib will be in a 'lib' subdirectory. Now, one last thing to consider is rox-clib, which is actually a C library. However, thanks to the way rox software works with application directories, it doesn't need to be in the normal library search path at all to function properly. I think that it would make sense then for me to also take it out of /usr/lib altogether, and instead put it alongside rox-lib in the new location. It already has an internal directory structure that provides a unique location for any 32- versus 64-bit versions of itself. Thanks for your help! [1] http://www.pathname.com/fhs/ [2] http://rox.sourceforge.net/desktop/AppDirs [3] http://article.gmane.org/gmane.linux.gentoo.devel/44751 (and others) -- Jim Ramsay Gentoo/Linux Developer (rox) signature.asc Description: PGP signature
Re: [gentoo-dev] A major change coming in the rox packages
Diego 'Flameeyes' Pettenò wrote: On Thursday 08 February 2007, Thomas Rösner wrote: AFAIR App Dirs provide internal arch distinction, so why not just put it in /usr/share/rox? /usr/share is not a good place for any kind of executable. Also, after compiling the AppDirs (in the few cases where these aren't just python source) I remove the src directory, so it will not be recompiled for other archs. The only thing you get in the appdir as installed by portage is the binary for your arch. In the case of python, maybe this wouldn't matter as much. /usr/lib is more suitable for the purpose. How would you then reconcile the issues raised in this bug[1] regarding /usr/lib and multilib support? I suppose I still don't know enough about multilib support to know if putting things in /usr/$(get_libdir)/rox would be correct, or if I should just hardcode to /usr/lib and close that bug as INVALID. Then I would have to somehow deal with the special case of rox-clib[2], since it really is a library but it does not have to be in the normal ld search path. I suppose that could actually go in /usr/$(get_libdir) without much trouble. [1] http://bugs.gentoo.org/show_bug.cgi?id=164816 [2] http://bugs.gentoo.org/show_bug.cgi?id=155983 -- Jim Ramsay Gentoo/Linux Developer (rox) signature.asc Description: PGP signature
Re: [gentoo-dev] A major change coming in the rox packages
Ed Catmur wrote: On Thu, 2007-02-08 at 11:05 -0600, Jim Ramsay wrote: I am planning on moving the install locations of all the rox-base/* and rox-extra/* applications from their current location (/usr/lib/rox) to something a little more FHS-correct[1] and tolerant of multilib support. Have you considered /usr/lib/misc/rox? Hmmm... that's actually not a bad alternative to /usr/libexec I suppose (though it's also not in the FHS), but will features=multilib-strict complain when I put rox-clib in /usr/lib/misc/rox/? I suspect it will.[1] So then all I need to do is somehow deal with rox-clib, which may be safe to put in /usr/$(get_libdir), which would satisfy the multilib folks... [1] http://bugs.gentoo.org/show_bug.cgi?id=155983 -- Jim Ramsay Gentoo/Linux Developer (rox) signature.asc Description: PGP signature
Re: [gentoo-dev] A major change coming in the rox packages
Diego 'Flameeyes' Pettenò wrote: On Thursday 08 February 2007, Jim Ramsay wrote: How would you then reconcile the issues raised in this bug[1] regarding /usr/lib and multilib support? /usr/lib/misc most likely, or /usr/libexec as you prefer, considering that the policy about that is still unwritten and probably will not appear in the next few months either. My only fear with going with /usr/lib/misc or /usr/libexec is that the actual move won't be pretty (I'll have to come up with some way for users to migrate some config files), so I'd prefer to only have to do it once. That's why I want to be sure I consider every viable option and pick the best location: so it's less likely I have to do it all again in 6 months. Then again, maybe my migration strategy will be so good it will be easy to do a second time :) -- Jim Ramsay Gentoo/Linux Developer (rox) signature.asc Description: PGP signature
Re: [gentoo-dev] make_desktop_entry in eutils.eclass
Thomas de Grenier de Latour wrote:
On Wed, 31 Jan 2007 23:30:53 -0500, Mike Frysinger [EMAIL PROTECTED]
wrote:
about the only thing that'd work is an additional parameter called
cruft that'd be passed unfiltered into the .desktop file
You can also imagine a -v switch, which would make this function print
the full path (with its $D prefix) of the file.desktop it has created.
This way, people could do:
src_install() {
...
local desktop_file=$(make_desktop_entry -v ...) || die
echo MimeType=... ${desktop_file}
...
}
I don't say this solution is better than the cruft parameter though,
it's really a matter of taste.
Nice. I like this idea, and humbly request that someone implement it
in this way, or give me permission to do so.
--
Jim Ramsay
Gentoo/Linux Developer (rox)
signature.asc
Description: PGP signature
Re: [gentoo-dev] make_desktop_entry in eutils.eclass
Mike Frysinger wrote:
On Tuesday 30 January 2007 16:10, Jim Ramsay wrote:
In other words, I propose that this function should probably do
'basename' on $exec before using it for the .desktop filename.
no ... the point of using $exec is to make sure the .desktop file is unique
i'll change it to sanitize the filename and turn them into underscores
Sure, but the name is already based on $exec AND ${PN} (and
SLOT too if SLOT != 0), so the uniqueness is already guaranteed
per-package, it would just be a matter of the package maintainer not
using the same exec twice in the same package, which probably
wouldn't even happen anyway. I still think basename would be
sufficient.
I propose an optional environment variable an ebuild can set before
calling make_desktop_entry, called DESKTOP_BASENAME, which would be
the basename of the file (not including the .desktop suffix) that the
function would use (if set) to create the file.
env vars to functions are lame
In that case it could be another optional parameter instead.
3 - Allow me to add other important settings like 'NoDisplay',
'OnlyShowIn', and/or 'MimeType'.
at this point, you might as well write your own .desktop file
Personally I'd rather just add one line to my ebuild as opposed to
creating and maintaining a .desktop file in the files directory. This
would just add a useful feature for those who want that level of
flexibility.
--
Jim Ramsay
Gentoo/Linux Developer (rox)
signature.asc
Description: PGP signature
[gentoo-dev] make_desktop_entry in eutils.eclass
I have a few suggestions for the make_desktop_entry function in eutils.eclass: 1 - Allow me to pass in a full application path. If you pass in the full path to an executable as the first argument, it comes up with a crazy filename like this: /var/tmp/portage/rox-base/mime-editor-0.5/temp//usr/lib/rox/MIME-Editor/AppRun-mime-editor.desktop When a more appropriate name would be: /var/tmp/portage/rox-base/mime-editor-0.5/temp/AppRun-mime-editor.desktop In other words, I propose that this function should probably do 'basename' on $exec before using it for the .desktop filename. 2 - Allow me to explicitly set the name of the .desktop file. This would perhaps solve #1 above as well. I propose an optional environment variable an ebuild can set before calling make_desktop_entry, called DESKTOP_BASENAME, which would be the basename of the file (not including the .desktop suffix) that the function would use (if set) to create the file. 3 - Allow me to add other important settings like 'NoDisplay', 'OnlyShowIn', and/or 'MimeType'. I propose an optional environment variable 'DESKTOP_EXTRAS' that the ebuild could set before calling make_desktop_entry. This would be an actual verbatim (newline-delimited) copy of the extra lines to be added to the desktop file, for example: DESKTOP_EXTRAS=OnlyShowIn=Yes or DESKTOP_EXTRAS=MimeType=text/plain NoDisplay=Yes Any objections? Suggestions? I would be willing to add these myself if no one else is. -- Jim Ramsay Gentoo/Linux Developer (rox) signature.asc Description: PGP signature
Re: [gentoo-dev] local use flag cleanup
Steve Dibb wrote: I've gone through some of them and here are the ones I suggest get moved to global, since the use flag description / functionality is the same or similar enough to mean support for $x: What about 'libnotify'? As far as I can see all 11 entries in use.local.desc amount to the same thing, though the descriptions vary slightly. (The one for gnome-extra/zenity is a typo: it says it uses 'libinotify' but actually RDEPENDs on =x11-libs/libnotify-0.4.1) -- Jim Ramsay Gentoo/Linux Developer (rox) signature.asc Description: PGP signature
Re: [gentoo-dev] The Dreaded herd tag
On Mon, Oct 30, 2006 at 11:09:53AM -0500, Chris Gianelloni wrote: On Sat, 2006-10-28 at 08:28 +0200, George Shapovalov wrote: Wanna guess how many of those happen to be stale? I would suspect fewer than you think. As an example, I have a few packages which belong to no herd, but have me listed as maintainer. Many of the no-herd packages are the same. Not being grouped with other packages doesn't mean it is unmaintained. I agree. All my rox stuff (rox-base/* and rox-extra/*) kind of fits into many different herds. Or no herd. Or maybe its own new herd. So this bears the question, what is the proper solution? Make herd optional? Force the maintainer's email into herd for packages without a herd? Or force each maintainer of herdless packages to create their own special herd. Which I may end up doing with my rox packages anyway. -- Jim Ramsay Gentoo/Linux Developer (rox) pgpzXvQNKPJtw.pgp Description: PGP signature
Re: [gentoo-dev] Re: Global USE flags (Was: mplayer global use flag)
On Sat, Oct 28, 2006 at 05:23:50PM +0200, arfrever wrote: In connection with latest globalization of mplayer USE flag I would like to ask for globalizing cairo, openexr and udev USE flags. These flags are used by enough amount of packages. I vote for a 'libnotify' global USE flag. It is used now by 11 packages in use.local.desc and does the same thing in all of them - Allows popups via libnotify (or dbus+notification-daemon, which amounts to the same thing). -- Jim Ramsay Gentoo/Linux Developer (rox) pgppPbZjuRCvZ.pgp Description: PGP signature
