Re: [gentoo-dev] Gentoo Council Reminder for February 26
On Tue, Feb 24, 2009 at 6:47 PM, Brian Harring ferri...@gmail.com wrote: At the very least I'm after having the non-pms repos marked in some fashion so that alt implementations don't have to assume the portage standard (rather then the *agreed to* pms standard) to avoid exploding, but that's a rather short sighted solution- something is needed long term. And/or make Portage noisy on PMS violations. Regards, -- Santiago M. Mola Jabber ID: cooldw...@gmail.com
Re: [gentoo-dev] when the music's over
On Mon, Mar 9, 2009 at 12:03 AM, Ali Polatel hawk...@gentoo.org wrote: Hey everyone, It's my turn to say goodbye. It's been really nice for two years. I've had great fun and have no bad feelings as I leave. This mail is meant as an apology to people who are awaiting my return. I'm sorry to let you down. So when the fun^Wmusic's over, turn off gentoo^Wthe lights. Ah.. the reasons? there are no reasons, who needs reasons when you got exherbo? Good luck with Exherbo and Sydbox ;-) Regards, -- Santiago M. Mola Jabber ID: cooldw...@gmail.com
Re: [gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives
On Tue, Mar 10, 2009 at 4:58 PM, Christian Faulhammer fa...@gentoo.org wrote: Having the EAPI stored outside the ebuild's scope is generally a bad idea, because someone has to tell you that the ebuild you just downloaded from Bugzilla is EAPI x. And the package manager will be totally confused when assuming an EAPI that is wrong. So the EAPI should be stored inside (best solution regarding giving ebuilds away) or in the file name (best compromise regarding the whole situation. Most ebuilds in Bugzilla have a proper name. I suggest you to download them with pybugz: $ bugz attachment ATTACHMENT-ID that will download it with the proper name. Regards, -- Santiago M. Mola Jabber ID: cooldw...@gmail.com
Re: [gentoo-dev] Real multilib support for Gentoo
On Sat, Apr 4, 2009 at 2:59 PM, Thomas Sachau to...@gentoo.org wrote: Hi folks, i would like to hear about other opinions about real multilib support within our tree and package managers. From what i know, there are mainly 2 different ideas: The proposals are not exactly these. 1. Make package managers multilib-aware [1][2]. Package managers would be able to have a default ABI (say, x86_64) and optional ones (x86). Everything would be built for the default ABI, and the package manager could build things for optional ABIs on an as needed basis. That is, if I install a 32bit binary package, the package manager will build any 32bit libraries it needs automatically. Package managers will have to expose to ebuilds a mechanism to iterate over enabled ABIs and build anything needed for each one. Pros: - Any package can be made multilib aware, getting rid of the emul-* packages. - 32bit libraries are built automatically and as needed. - This system can be extended to support other kind of ABIs. Making it possible to build packages for various versions of Python/GHC/etc simultaneously. Cons: - Needs to be implemented on the PM-side and needs a new EAPI. 2. Implement multilib on the ebuild level. For amd64, this would mean adding a 'lib32' USE flag to every multilib ebuild, and use it for building 32bit libs as needed. Pros: - Any package can be made multilib aware, getting rid of the emul-* packages. - Doesn't need PM changes. Cons: - Package manager won't be multilib-aware, so it won't be able to build 32bit libraries automatically and as needed. - Users will have to enable 'lib32' USE flag manually for every library they needed. Enabling 'lib32' by default is not an option since it would build tons of unneeded 32bit libraries for every user. [1] http://dev.exherbo.org/~pioto/abi-ideas.html [2] http://bugs.gentoo.org/show_bug.cgi?id=145737 Regards, -- Santiago M. Mola Jabber ID: cooldw...@gmail.com
Re: [gentoo-dev] =dev-lang/{tcl,tk}-8.5* unmask
On Fri, Apr 17, 2009 at 11:07 PM, Federico Ferri mescali...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's been long time since tcl-8.5 is sitting in tree p.masked. a number of bugs have been fixed in the past (last bugs I've fixed this evening: itcl-3.3, tix, tclpython; one I can't fix is otcl - moreover, it's damn obsolete (last commit 2 years ago)) the remaining bugs in the tracker [1] are mostly applications (not tcltk's herd) with (mostly) no rdeps. ++ Two years is enough. That's even more than what took Python 2.5 to get out p.mask ;-) After various heads up on the bug and on @g-dev, I think it's time to unmask. Incompatible packages should be fixed ASAP (after unmasking) or punted from the tree if they can't keep up with tcl/tk development. Best regards, -- Santiago M. Mola Jabber ID: cooldw...@gmail.com
Re: [gentoo-dev] Possible USE=gnome abusing in ebuilds.
On 10/12/07, Doug Goldstein [EMAIL PROTECTED] wrote: Kinda like the GNOME herd does themselves? I've pointed this one out a few times just cause it annoys me... gnome-mount has USE=gnome... well... DUH! it's a gnome-volume-manager specific and GNOME Desktop specific wrapper for HAL based mounting. Obviously it's used by GNOME and only does and can function within a GNOME Destkop environment. But what does this USE flag mean? Oh, it simply means you want to build the Nautilus extension! Do we already have a USE=nautilus? Yes, yes we do. It's a local USE flag used in 3 packages, 2 of those 3 are GNOME herd packages. I've been told (although as an opinion, not a policy) that USE=-gnome means put as few gnome packages as possible and USE=gnome means the opposite. So I'm going to use this USE flag for a GNOME app which can use only a few gnome packages at the minimun, and some others for extra features. GNOME users certainly want to take advantage of those extra features, and other users don't want to install so many GNOME packages. I don't think it's an optimal solution, but adding a new local USE for every tiny feature would be annoying, and USE=gnome-panel or USE=gnome-applets flag is pretty senseless. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Looking for a developer with Logitech Quickcam Messenger (using media-video/qc-usb-messenger)
On 10/21/07, Samuli Suominen [EMAIL PROTECTED] wrote: Hi, I've recently sold my webcam and replaced it by another so I don't have hardware to maintain media-video/qc-usb-messenger anymore. It's easy to maintain and I've used media-video/camorama to test it. If you own this hardware, please take maintainership of this package. I took its maintainership. Regards, Santiago -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: EAPI feature suggestion: OBSOLETES (was: gentoo-x86 commit in profiles/updates: 4Q-2007)
On Nov 7, 2007 3:09 PM, Steve Long [EMAIL PROTECTED] wrote: Jim Ramsay wrote: 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 really like that idea. (A RECOMMENDS thing similar to debian would be nice too.) Agreed. Recomendation could be queried in a standarised way and at any time (not only after installing a package). It'd be more reliable than current pkg_postinst messages. Regards, Santiago -- Santiago M. Mola -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-print/cups: ChangeLog cups-1.3.4-r1.ebuild cups-1.3.4.ebuild
On Nov 9, 2007 12:08 PM, Rémi Cardona [EMAIL PROTECTED] wrote: Either way, those are just runtime deps. Wouldn't it be best to drop them from the ebuild and add an einfo printing out this list of possible driver packages and let users decide which one they are going to use? Are they inconditional runtime deps? This looks like another case where RECOMMENDS would be useful. -- Santiago M. Mola
Re: [gentoo-dev] [RFC] Features and documentation
On Nov 29, 2007 1:43 AM, Alec Warner [EMAIL PROTECTED] wrote: Forcing people to write documentation won't get it written, people will continue to act like we just saw and either the rule will get ignored, or someone will change the rule, or people will leave because the rule is enforced aggressively and it has ruined the ability to contribute to the project. This is why I offered to write the GLEP for Diego and Cardoe, because I know they are not interested in writing it themselves. Thats why we have a doc-team that for some sick reason enjoy writing and maintaining documentation. It would be reasonable to require devs to: a) Document changes before commiting when it's possible. b) When a) is not applicable, ask doc project to document it before commiting. c) When neither a) or b) are possible, file a bug asking for doc update for the commited changes. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [RFC] Features and documentation
On Nov 29, 2007 7:06 PM, Duncan [EMAIL PROTECTED] wrote: Something must have motivated you to present this now. What was it, or to put it a different way, how would have things been different in your view had this policy been in effect? Point to other examples as well if you believe they'll help clarify the effect you intend this policy to have. I don't know what kind of changes meant Donnie (I hope he clarify that) but a couple of examples came to my mind when I read his proposal: bugs #182253 and #181897. I'm sure there are much better examples, but those are the ones I have right now. Regards, Santiago -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] .desktop file cleanup
On Dec 6, 2007 6:48 PM, Petteri Räty [EMAIL PROTECTED] wrote: In celebration of the Finnish Independence Day let's cleanup the .desktop files we have in the three. * desktop-file-validate /usr/portage/x11-misc/ifpgui/files/ifpgui.desktop * desktop-file-validate /usr/portage/net-p2p/bittornado/files/bittornado.desktop * desktop-file-validate /usr/portage/net-p2p/mldonkey/files/mldonkey-gui.desktop Fixed. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] New USE flags documentation
On Nov 24, 2007 4:19 PM, Doug Goldstein [EMAIL PROTECTED] wrote: Jose Luis Rivero wrote: I'm not asking for an extra overhead of 'bureaucracy' (write specs, mailling @dev, send to the council, etc.) but a bit more of communication would be appreciated: All the above is completely unnecessary and I would be happy to discuss details with you off list. I'm not against the changes in metadata but I felt a bit angry when the changes were made bypassing established processes and skipping the feedback-rethinking cycle (as other people pointer out... ignoring the community). So, I agree with people asking for freezing the use of the new features until a GLEP is proposed, discussed and approved. Regards, Santiago -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Handling branch strings
On Dec 10, 2007 10:21 AM, Donnie Berkholz [EMAIL PROTECTED] wrote:
On 00:26 Mon 10 Dec , Robin H. Johnson wrote:
What I've got for my Xorg testing setup, is foo--rX, with a number
of different -X values that I just select from via package.{un,}mask
while testing - this saves altering everything else in the tree to pick
some package that has a different name just to satisfy a branch (which
also requires lots of ${MY_PN} mockery for some packages.
You'd also need to put '!cat/pn-feat' in the base cat/pn package and
vice-versa.
While we're getting a bit off the original topic here, it occurred to me
that using SLOTs for this, in combination with various SLOT deps and
SLOT blockers, might work. Then one could use a search tool that would
display SLOTs to show you which branch you're getting.
Too tricky. It would confuse package managers and would break the
meaning of SLOT. An use expanded SCM_BRANCH combined with use
dependencies makes more sense and, hopefully, would be something
manageable.
Regards,
Santiago
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Handling branch strings
On Dec 11, 2007 9:11 AM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 10 Dec 2007 11:42:38 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: You've made these assertions about confusion and breakage, and I would like to understand the reasoning behind them. [...] For my reasoning... just read Ciaran's reply ;-) -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
On Dec 12, 2007 1:21 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 11 Dec 2007 16:59:28 -0500 Doug Klima [EMAIL PROTECTED] wrote: discuss. * EAPI may only be set before the 'inherit' in an ebuild. * Eclasses may not set EAPI. * Eclasses may not assume a particular EAPI. * If an eclass needs to work with multiple EAPIs, EAPI-specific code should be split out into foo-eapiBLAH.eclass, and EAPI-agnostic code and a conditional inherit should remain in foo.eclass. It seems the most reasonable option I've read until now. Would it be possible to have eclass/eapiBLAH/foo.eclass? * Eclasses cannot be made not to work with any given EAPI. If such functionality is desirable, someone needs to file an EAPI request for permitting an alternative to 'die' that is legal in global scope. So is it desirable? If portage masks ebuilds with an unsupported EAPI, what's the point? It'd be enough to be able to check EAPI compatibility in eclasses quickly so repoman and others can print a nice error. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] gnupg-2 stable plans
On Dec 12, 2007 4:08 PM, William L. Thomson Jr. [EMAIL PROTECTED] wrote: On Wed, 2007-12-12 at 14:26 +0200, Alon Bar-Lev wrote: On 12/12/07, Jan Kundrát [EMAIL PROTECTED] wrote: Alon Bar-Lev wrote: As I told you before, I wont slot these two. Could you provide a link to reasons that lead you to this decision so that interested readers can make their own opinion? http://bugs.gentoo.org/show_bug.cgi?id=159623 Again while there might not be technical issues, what is not covered there in the bug is why rob users of a choice? Why make users mask a 2.0 version that's in the same slot as a 1.4.x version. Given that both will be actively maintained. In short: * It's upstream's choice. * 2 is actively maintained and there's no deprectation planned. * It's not a true drop-in replacement, even if it's fully compatible with all packages in the tree. * In some cases, people could get a benefit of using gpg-1, instead of gpg-2. * There's no need of an eselect module, since gpg2 is supposed to be called gpg2 and not just gpg. * Again, it's upstream choice and, after considering the possibilities, there's no major reason for not following it. What else is needed for using SLOTs? -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] EAPI placement
On Dec 12, 2007 11:14 PM, Carsten Lohrke [EMAIL PROTECTED] wrote: On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote: * Eclasses may not set EAPI. * Eclasses may not assume a particular EAPI. I disagree here. It would be annoying and possibly even hindering in future not being able to use higher EAPI features in eclasses. Point is the eclass has to check, if the author of an ebuild sets another EAPI and throw an error, in this case. Nobody said that eclasses can't use new features. Just that they cannot _set_ EAPI or assume they are working with any EAPI. But an eclass can check which EAPI is set in the environment (that's which EAPI the ebuild set) and act accordingly, using features available on that EAPI. The most basic issue, which we didn't even discuss yet, afaik, is how to make every developer aware which feature belongs to which EAPI. I freely admit, I do not know that. Is there a list somewhere? EAPIs are defined in PMS [1] although I don't find an officla copy at gentoo.org (only the one in dev.g.o/~spb). EAPI issues may lead to a lot of confusion and eclass bloat, especially since we still can't remove stale eclasses afaik. Yep, that issue should be addresses as it is in paludis and pkgcore. [1] http://www.gentoo.org/proj/en/qa/pms.xml -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Ebuilds I lastrited month ago for treecleaners, time to look at them once more.
On Dec 15, 2007 8:00 AM, Samuli Suominen [EMAIL PROTECTED] wrote: x11-wm/flwm (Coldwind promised to take a look at this, it needs a patched fltk.) Both fltk and flwm fixed. x11-wm/flwm should go out of p.mask when fltk and flwm get proper keywords again. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 18, 2007 6:37 PM, Ulrich Mueller [EMAIL PROTECTED] wrote: On Tue, 18 Dec 2007, Fernando J Pereda wrote: It seems to me that this will inconvenience the users, in order to solve a technical problem of the package manager. Absolutely, +1. This does indeed sound like a technical issue; how would requiring a dev to manually mirror the EAPI in the filename extension provide any benefit over caching it behind the scenes (using the Manifest file or similar mechanism)? You are yet to show what kind of inconvenience to the users this proposal will cause. One example was mentioned in this thread before: You cannot use find -name '*.ebuild' anymore. So people could use a bit more elaborated expression to find them. Things like this shouldn't be a reason for not applying EAPI/GLEPs/PM-behaviour changes. If this GLEP is approved, it would be fine to publish a quick guide of recipes to migrate scripts which rely on the old naming convention and that should be enough. IMO, keeping us away from improvements to Gentoo because they break backwards compatibility with third party scripts is a no-go. Of course, this kind of changes can't happen once a month, but they can happen from time to time. Regards, Santiago -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Some new global USE-flags
On Dec 20, 2007 7:57 PM, Markus Meier [EMAIL PROTECTED] wrote: raw: Add support for raw image formats keyring: Enable gnome-keyring support for storing passwords These are potentially ambiguos. I have no objections for the others. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 20, 2007 8:01 PM, Zhang Le [EMAIL PROTECTED] wrote: How many EAPI's do we have now? In Portage tree we have 0 (default) and 1. There are others in external projects, for example prefix (in Gentoo/Alt:Prefix) or paludis-1 (used in paludis repositories). Where is the detailed definition of those EAPI's? 0, 1 and any further official EAPI are defined in PMS. There's a svn repository at http://svn.repogirl.net/pms How can we produce a new EAPI? I can't tell you the exact process, but look at EAPI bug trackers or search for bugs assigned to [EMAIL PROTECTED] Also, search in @-dev's archive. IMO, we can not have more than two EAPI's simultaneously. The only situation in which we can have two EAPI is in the transition period of those two EAPI's. And we should set a time constraint on the transition. Quite the opposite. EAPI's are designed to live happily together in the same repository. A current example: most (or lots...) ebuilds in the tree don't need EAPI=1 and it's pointless to migrate all of them. We can switch EAPI on an as needed basis. Other than that we can only have one working EAPI which all package managers conforms to. Read above, and other discussions. That's also pointless because we don't need to force all third party overlays to upgrade EAPI everytime we have a new one... -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Some new global USE-flags
On Dec 20, 2007 10:48 PM, Jan Kundrát [EMAIL PROTECTED] wrote: Santiago M. Mola wrote: These are potentially ambiguos. Could you please elaborate a bit about the raw one? Just that raw could mean more things. Anyway, I have no problem with that since current packages in the tree use it as raw image format and new packages which need such flag for a different meaning could set it to something more meaningful. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 28, 2007 1:03 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: There's no particular reason that new version formats can't be introduced in a new EAPI so long as the version strings don't appear in ebuilds using older EAPIs or in profiles. Ditto for naming rules. Errr... so should we use new files in profiles for such new formats? (for example, p.masking an ebuild with a new version format). -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 28, 2007 1:28 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Fri, 28 Dec 2007 13:25:13 +0100 Santiago M. Mola [EMAIL PROTECTED] wrote: On Dec 28, 2007 1:03 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: There's no particular reason that new version formats can't be introduced in a new EAPI so long as the version strings don't appear in ebuilds using older EAPIs or in profiles. Ditto for naming rules. Errr... so should we use new files in profiles for such new formats? (for example, p.masking an ebuild with a new version format). Possibly. Currently there's simply no way of doing it, nor of using non-EAPI-0 features anywhere in profiles (you can't, for example, use slot deps in package.mask). It'd be nice to agree a new profile format before accepting version format changes. In the case of slot deps, it'd be desirable to use them in package.mask, just desirable. But with version format changes we're introducing ebuilds which can't be handled in package.mask, that's a great loss of functionality. GLEPs 54 and 55 could wait until we have figured out how to apply them properly and without loss of current functionality. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Improving use.desc
scripts. +vim-syntax - Pulls in related vim syntax scripts Regards, Santiago -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Improving use.desc
On Jan 4, 2008 6:31 AM, Donnie Berkholz [EMAIL PROTECTED] wrote: Are there any programs (make.conf / USE editors) that manage to read and set that stuff? Paludis read and show them. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] USE flag documentation
On 1/14/08, Yuri Vasilevski [EMAIL PROTECTED] wrote: [ebuild R ] media-video/mplayer-1.0_rc2_p24929-r2 USE=X cdio -aac#1 -cdparanoia#2 -encode ... #1 aac needs encode #2 cdio conflicts with cdparanoia This can be implemented with use.desc/use.local.desc. Paludis already does that by default. But this logic will have to be exposed on a .ebuild level. I don't think this is worth an EAPI change, or adding new variables to ebuilds. metada.xml USE flag documentation could be extended to cover such cases if it's really needed... but is it? -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] USE flag documentation
On 1/14/08, Santiago M. Mola [EMAIL PROTECTED] wrote: On 1/14/08, Yuri Vasilevski [EMAIL PROTECTED] wrote: [ebuild R ] media-video/mplayer-1.0_rc2_p24929-r2 USE=X cdio -aac#1 -cdparanoia#2 -encode ... #1 aac needs encode #2 cdio conflicts with cdparanoia This can be implemented with use.desc/use.local.desc. Paludis already does that by default. Sorry. Paludis shows USE flags, and overrides definitions with use.local.desc. But stuff like aac needs encode and cdio conflicts with cdparanoia should be something separate from USE flag documentation. As you said, it should be handled at ebuild level. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Seeking questions for a user survey
On Jan 14, 2008 1:33 PM, Robin H. Johnson [EMAIL PROTECTED] wrote: Ok, so per the one discussion in #-dev this evening, I'm looking for questions to put on a new user survey. An interesting question would be Which package manager do you use?. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
On Jan 19, 2008 2:07 PM, Tiziano Müller [EMAIL PROTECTED] wrote: Current state: Deferred Wanted state: Accepted/Implemented (at least by me) The GLEP should be updated. Motivation section does not seem to justify the changes. IMO Meatoo [1] (and its hipothetical rewrite using Doapspace [2]) would be the right tool to detect version bumps. Maybe metadata.xml should contain a Freshmeat or DOAP entry so meatoo could get more automation. Anyway, I don't know how much would take the new version of meatoo. Pythonhead, could you give us some news about it? Or it's just planned for the long-term future? [1] http://meatoo.gentooexperimental.org/ [2] http://blog.doapspace.org/ -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml
On Jan 19, 2008 4:13 PM, Tiziano Müller [EMAIL PROTECTED] wrote:
Possibilities:
An element: status{active/inactive}/status
Status of what? seeing you have proposed a upstream-status and a
maintainer status. what else is there left to status :P
There will be a maintainer tag within the upstream/upstream, not the
same as our already existing maintainer
But the question I tried to express (probably not clear enough) is:
Should (if at all) the status being tracked for upstream or for
maintainer (within upstream).
As an example dev-libs/xmlwrapp: The original maintainer is inactive, but
there is a new one who took the package to sourceforge and it's not a fork
since the original maintainer agreed up on this. Should such a case be
tracked at all?
I think we don't want to track if previous maintainer is active or
not, or if it's changed. In your example, the important data is who
is the current maintainer and how to contact him and is she
active?. Keeping an entry for the old maintainer as inactive when
there's a new one is not like an useful piece of info.
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
���^�X��� ��(��j)b�b�
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
On Jan 19, 2008 4:24 PM, Denis Dupeyron [EMAIL PROTECTED] wrote: On Jan 19, 2008 2:07 PM, Tiziano Müller [EMAIL PROTECTED] wrote: Your oppinion? Would this be the right time to discuss about moving other variables to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those hardly change and if they ever do we can restrict them to specific versions. I know there could be technical hurdles, but what do you think of the idea at least ? I'm not sure about HOMEPAGE and DESCRIPTION, but I think LICENSE should be per-ebuild variable. A license change is not so strange (GPL-3, double licensing the source, or adding new artwork licensed with a more restrictive license). Moreover, a license change does not need to be retroactive, so using a global variable in metadata.xml could lead to accidentally show a wrong license for old versions. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] Packages up for grabs
On Dec 25, 2007 7:19 PM, Christian Heim [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]: - x11-misc/xdesktopwaves desktop-misc takes this, if someone wants to get maintainership go ahead. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: removal of digest files from the tree
On Jan 28, 2008 2:44 AM, Chris Gianelloni [EMAIL PROTECTED] wrote: I think throwing up an announcement today/tomorrow for Thursday/Friday should be sufficient for this sort of a change, as it won't affect any user who has a version of portage released in the past ~1.5 years. +1, too. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] debianutils: system worthy ?
On Jan 30, 2008 6:35 PM, Philip Webb [EMAIL PROTECTED] wrote: 'equery d debianutils' gives me app-admin/sysklogd-1.4.2_pre20061230 (sys-apps/debianutils) app-portage/gentoolkit-0.2.3-r1 (userland_GNU? sys-apps/debianutils) sys-apps/mktemp-1.5 (=sys-apps/debianutils-2.16.2) The 2nd cb ignored, but the others seem important. I have Mktemp-1.5 installed, so what do you mean by your lines 1-2 ? Sysklogd seems to be an important pkg too. What am I missing (smile) ? Removing debianutils from the system _set_ doesn't mean to completely remove it from the portage tree or user systems. It'll be a dependency of sysklogd and mktemp anyway. This change does not affect you. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: removal of digest files from the tree
On Jan 31, 2008 12:32 AM, Robin H. Johnson [EMAIL PROTECTED] wrote: On Thu, Jan 31, 2008 at 12:05:26AM +0100, Vlastimil Babka wrote: Chris Gianelloni wrote: I think throwing up an announcement today/tomorrow for Thursday/Friday should be sufficient for this sort of a change, as it won't affect any user who has a version of portage released in the past ~1.5 years. So, since it seems nobody objected it, time for the announcement? And the removal (server-side by robbat2) would be best done right before the snapshot? It's pretty much irrelevant to the snapshot. wolf31o2 has my patch to exclude digests in the snapshot anyway. Then I guess it could be done as soon as the doc patch is prepared... -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] gentoo-commit messages for SVN
On Feb 4, 2008 12:54 PM, Robin H. Johnson [EMAIL PROTECTED] wrote: Included: pybugz If you think a repo is on the wrong side, please respond here! This is no longer in use and can be even removed. It's now an external project, hosted on http://code.google.com/p/pybugz/ -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: I want to steal your tools
On Feb 5, 2008 4:21 AM, Ryan Hill [EMAIL PROTECTED] wrote:
Heath N. Caldwell wrote:
On 2008-02-04 14:51, Ryan Hill wrote:
Can someone provide a tool that given a package name simply prints the
category or cat/pkg, or if ambiguous, prints the multiple cat/pkgs or
returns an error code? I don't care what it's written in as long as it's
relatively quick. I'm sick of depending on udept (which is an incredible
tool but a lot heavy for a simple shell script) just to get a simple
category.
What about something like this:
--
#!/bin/bash
source /etc/make.globals
source /etc/make.conf
for i in ${PORTDIR} ${PORTDIR_OVERLAY}; do
(cd $i; a=(*/$1); [ -e ${a[0]} ] ls -1 -d */$1)
done | sort | uniq
--
It's really fast, at least.
Also very good, thanks. Instead of sourcing, we can instead use
$ portageq envvar PORTDIR
$ portageq portdir_overlay
How do paludis and pkgcore make this info available?
You can get PORTDIR with:
paludis --configuration-variable gentoo location
AFAIK, PORTDIR_OVERLAY is more tricky:
for r in $(paludis --list-repositories | sed -e s/^*\ //g) ; do
if [[ $(paludis --configuration-variable ${r} format) = ebuild ]] ; then
paludis --configuration-variable ${r} location
fi
done
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] The future of ebuild
On Sun, Feb 24, 2008 at 12:02 PM, Felipe Contreras [EMAIL PROTECTED] wrote: On Thu, Feb 21, 2008 at 2:29 PM, Duncan Coutts [EMAIL PROTECTED] wrote: Why not create a new build system with a state of the art programming language, and an advanced DSL that actually other distributions could use? I would like to hear your opinions on this matter. Take a look at Nix. It's a distribution-agnostic package manager that uses a purely functional DSL for package specifications. http://nix.cs.uu.nl/index.html That's exactly what I'm taking about :) I'll try it out. Thanks for sharing the link. Is there any interest in the Gentoo community to migrate to Nix? This is not going to happen. Migrating to Nix means rewriting the distro from scratch. If you´re interested in a distro built on top of Nix, you can try NixOS (which looks really nice IMO). Regards, Santiago -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] ���^�X��� ��(��j)b�b�
Re: [gentoo-dev] Keyword request interface (SoC candidate?)
On Thu, Feb 28, 2008 at 10:43 PM, Alec Warner [EMAIL PROTECTED] wrote: cvs.gentoo.org:/var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/index2008.xml Add it ;) I'm not 100% sure this is a good idea, that's why I'm asking for opinions here ;-) Also, I doubt I can mentor. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for March
On Sat, Mar 1, 2008 at 7:45 PM, Christian Faulhammer [EMAIL PROTECTED] wrote: What we propose is proper testing and keywording by anyone around...not just team members. Writing test plans like emacs team does really helps too. I waste too much time figuring out how to test properly some packages, and I'm sure me and other ATs miss a lot of important use cases. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
On Wed, Mar 5, 2008 at 6:11 PM, Anant Narayanan [EMAIL PROTECTED] wrote: Some of you may argue that we already have proxy-maintainers. That's a great idea, all I'm asking for is for us to formalize the position. Giving a proxy-maintainer an official acknowledgement will definitely attract more users to contribute. IMO the problem with proxy-maintainers is that most users don't know such a thing exists. I bet some users could proxy-maintain a lot of orphaned packages if we potentiate proxy-maint. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New keyword monkey: Kenneth Prug (ken69267)
On Sat, Mar 8, 2008 at 9:33 PM, Thomas Anderson [EMAIL PROTECTED] wrote: On Saturday 08 March 2008 12:30:17 Petteri Räty wrote: Joining us from the zoos of Florida, we have Kenneth keninsert random numbers here Prugh. Ken did such a fine job testing all those random packages for amd64 that it will be the sole purpose of his life from now on. He tells me his hobby is to learn new programming languages so I guess he doesn't get bored easily. Time for the usual spanking everyone. Regards, Petteri use adjutrix || die failee! And goodbye most active Arch Tester! And hello most active amd64 dev (I hope) ;-) -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] ���^�X��� ��(��j)b�b�
Re: [gentoo-dev] New developer: Tobias Klausmann (klausman)
On Mon, Mar 10, 2008 at 10:13 PM, Petteri Räty [EMAIL PROTECTED] wrote: One of those people working on those weird paper weights. This time our monkey comes from the world of alphas. Tobias hails from Germany (there seems to be no end). He works as a sysadmin so perhaps he will some idea about stability. He is the author of pymetar and carl (emerge and try). Here's how he tells about himself: I'm an avid motorbike rider (*not* a biker!), I enjoy electronic music and good SF literature and graphic novels. Photography is another hobby (which I find too little time for). I've been the admin of the Alpha Arch Team's main dev machine since it was donated (mid-May 2007). Also, I run rsync5.de.g.o and have been doing so since about mid-2002. Welcome Tobias! -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
[gentoo-dev] Re: [gentoo-dev-announce] New developer: Thomas Sachau (tommy)
On Thu, Mar 20, 2008 at 7:07 PM, Petteri Räty [EMAIL PROTECTED] wrote: Part of the ever growing German conspiracy, we have Thomas (tommy) Sachau. He will be joining us to help with the pile of broken ebuilds that some people call the Sunrise overlay. He has previously contributed to the Freenet project. On his free time he likes listening to music and attending concerts. On IRC you can find him as Tommy[D]. Welcome Tommy! -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] escaping variables in sed expressions
On Tue, Apr 15, 2008 at 1:14 PM, Marijn Schouten (hkBst)
[EMAIL PROTECTED] wrote:
Hi list,
it seems I have been using some fragile sed expression and I'd like to tap
the collective
wisdom for avoiding doing that in the future.
dev-scheme/slib-3.1.5-r1 currently does
sed s_prefix = /usr/local/_prefix = ${D}/usr/_ -i Makefile
to make it not violate the sandbox. However a user had set
PORTAGE_TMPDIR=/home/gentoo_overflow/tmp causing the sed expression to
contain too may
underscores and failing.[1]
There are several option to handle this. I could use a less common
delimiter or I could
escape it: ${D//_/\_} instead of ${D}. I could use a sed expression that
doesn't suffer
from this problem (thanks to dleverton):
sed -ne '\_^prefix = /usr/local_!{p;d}' -e iprefix = ${D} -i Makefile
Comments?
Currently is use ':' as sed delimiter when paths are involved. I'd
also like to hear from you about proper delimiters if you think ':' is
not safe enough.
AFAIK, the only corner case which would make this fail would be
Windows paths (C:/gentoo-prefix).
Regards,
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: escaping variables in sed expressions
On Thu, Apr 17, 2008 at 6:31 AM, Duncan [EMAIL PROTECTED] wrote: While you are almost certainly correct on POSIX/Unix filenames and the shell won't accept / in a filename, IIRC (from reading) it's often possible for C programs to code a literal / in a filename, and possible for some filesystems (also written in C, generally) to accept it. Thus, while POSIX/Unix standards don't allow it, in practice, it's sometimes possible, if rare. If that's possible, we shouldn't support it anyway. If someone wants to use /var/tmp/port\/age we'll just stab him, if someone releases a tarball with such filenames we'll stab him, too. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Early stabilisation
On Thu, Apr 17, 2008 at 2:33 PM, Samuli Suominen [EMAIL PROTECTED] wrote: Thu, 17 Apr 2008 09:43:59 +0200 Vlastimil Babka [EMAIL PROTECTED] kirjoitti: Okay. So we can just agree it's better if the maintainer tells his reasons when opening the bug, to spare the later clarifications? It works. Do it. While I agree with you, and I think we are free to request stabilization before the 30 days window, I also love when people give details about the stabilization and not just a do it. Emacs team's test plans [1] are the better example. Thanks to them I'm able to save a _lot_ of time figuring out how a package works and which features should test. Some details about changes since last stable are usually useful too. In latest wgetpaste stabilization [2] we are told that this is a trivial bugfix release fixing osl support, so we can just test osl support and skip most of other tests. Also, when a program needs a sample file with some obscure format, I really appreciate when maintainers give a URL to a sample file so I don't need to search for suitable files and can strictly focus on testing. Of course, everyone could continue with the do it style, but keep in mind that adding info like I described above can save a lot of AT work and, as a result, make stabilization process faster. [1] http://overlays.gentoo.org/proj/emacs/wiki/test%20plans [2] http://bugs.gentoo.org/show_bug.cgi?id=211894 Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Sun, Apr 20, 2008 at 10:36 AM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Sat, 19 Apr 2008 18:29:10 -0700 Brian Harring [EMAIL PROTECTED] wrote: Stop name dropping labels until you tell folk about what labels are. I know, but I'd rather not have the notion labels solves all pushed forth w/ out people knowing what it is, please. Labels are already documented and discussable in the appropriate place. This is not supposed to be a discussion about future direction. It's supposed to be about one specific issue regarding how we word things for current implementations. The two wordings in the original email do not have equivalent implications, and selecting the correct one affects whether certain problems are solvable. Let's discuss that, not what we're going to do six years from now. http://bugs.gentoo.org/show_bug.cgi?id=201499 -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: New global USE flag: keyring
On Sun, Apr 20, 2008 at 6:17 PM, Peter Weller [EMAIL PROTECTED] wrote:
On Sun, 2008-04-20 at 18:06 +0200, Tiziano Müller wrote:
I'd say we should convert it to a global use flag now with a good
description and change it to gnome-keyring later in case we really have a
package which needs 'keyring' for something else.
I agree with what dev-zero just wrote there.
That's unlikely to happen. When a program needs 'keyring' for
something else, the maintainer will see that 'keyring' is used for
'gnome-keyring' and will choose another name ('foo-keyring').
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
���^�X��� ��(��j)b�b�
Re: [gentoo-dev] lastrite: sys-apps/systrace (security/treecleaners)
On Mon, Apr 21, 2008 at 9:01 PM, Samuli Suominen [EMAIL PROTECTED] wrote: # Samuli Suominen [EMAIL PROTECTED] (21 Apr 2008) # Masked for removal in 30 days. Doesn't build # wrt bug 178036 and has open CVE-2007-4773 wrt # security bug 203195. sys-apps/systrace -- gentoo-dev@lists.gentoo.org mailing list http://www.citi.umich.edu/u/provos/systrace/systrace-1.6e.tar.gz 1.6e solves the security problem. Just in case someone wants to fix it. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Nazi symbols on Gentoo (and other offending content)
Hi there, Other devs and me have been worried about the use of Nazi symbols on forums.gentoo.org [1]. While some find it specially a problem because of German laws (which it seems make illegal to visit webs with such symbols), I'm more worried because these symbols, as well as others related to recent dictatorships or hate-promoting movements, are offending for a good amount of people in the community. The offending nature of Nazi symbols, and their total irrelevance in a distro community makes me wonder why the hell should we have this on our communication channels?. The fact that political and religious discussions are also irrelevant in this context makes me wonder also why the hell should we keep any of this potentially offending and flame-maker? Gentoo is a community made of people of all around the world, with different cultures and political views, and we have to work together. So why don't put the politics aside and continue the work respecting each other? The Internet is plenty of forums where people can flame about politics or create a Nazi alter-ego and offend each other, Gentoo should not be a place for this purpose. Thoughts? Isn't there anyone else willing to keep Nazi symbols outside forums? If yes, at the expense of punting all politics or just as a special case? Regards, PS.1 - An apology for forum mods because the avatar I've been using may offend them, my purpose was to raise awareness of the issue of using extremely offending content on the forums. While I think my avatar is valid, I prefer to calm things down and try to work out the issue with forum mods without attacking. I decided to remove the avatar. PS.2- Before someone says Godwin, this is not using Nazis in a discussion about something else, this is directly a discussion about Nazi symbols. [1] http://forums.gentoo.org/viewtopic-t-480537.html -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: OT: [gentoo-dev] Nazi symbols on Gentoo (and other offending content)
On Mon, Apr 28, 2008 at 1:57 AM, Petteri Räty [EMAIL PROTECTED] wrote: Santiago M. Mola kirjoitti: Thoughts? Isn't there anyone else willing to keep Nazi symbols outside forums? If yes, at the expense of punting all politics or just as a special case? Again this is the wrong mailing list. I don't see this thread having any technical content. Actually I thought about it, but it seems @-project has no attention from developers, and what I want to know if is more developers see this as a problem, or not, or just don't care (if the later is the case, the thread will just die shortly). Anyway, next time I'll use @-project, and let's see if someone actually cares about that mailing list. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] RFC: language bindings as separate packages
On Thu, May 1, 2008 at 5:09 PM, Enrico Weigelt [EMAIL PROTECTED] wrote: Hi folks, while building yum, I again ran into trouble because one dependency has to be rebuilt with an specific useflag first (in this case it was libxml2 + python useflag). Actually, there are *lots* of these cases and (AFAIK) portage has no way for properly handling this - it's up to the individual ebuilds to check for those situations and artifically breaking the build. Of coure, breaking builds are ugly. The proper solution for these cases is implementing USE dependencies, which would obsolete pkg_setup checks, and would provide portage with info about which USE flags are needed for each dependency. This feature is already implemented in other package managers (it's in Paludis, maybe in pkgcore too?) and I think we all look forward its inclusion in portage. My suggestion: make those language bindings being separate packages. So, other packages can depend on them directly, instead of the current, build-breaking hack. I'm not advocating gentoo should do this step alone, but instead join in the upstream and solve it there. Yes, sometimes it makes sense for upstream to split packages, anyone is free to push them for doing so. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] One-Day Gentoo Council Reminder for May
On Thu, May 8, 2008 at 1:15 PM, Brian Harring [EMAIL PROTECTED] wrote: If PMS is going to be discussed in some form, it's a fair request that folks have an easily readable version. Here you have latest pms revision built without kdebuild-1 spec: http://dev.gentoo.org/~coldwind/pms.pdf It's not that hard to extract the relevant paragraph from the tex sources, though. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] One-Day Gentoo Council Reminder for May
On Thu, May 8, 2008 at 2:01 PM, Brian Harring [EMAIL PROTECTED] wrote: On Thu, May 08, 2008 at 01:44:53PM +0200, Santiago M. Mola wrote: Here you have latest pms revision built without kdebuild-1 spec: http://dev.gentoo.org/~coldwind/pms.pdf Already did (hence the bash 3.0 comment), that said having a live copy of the doc for ebuild devs to review, or portage tree tool developers to review isn't exactly a bad idea. I've updated it now to: http://dev.gentoo.org/~coldwind/pms.pdf http://dev.gentoo.org/~coldwind/pms-without-kdebuild.pdf Someone may want to automate it. At the moment, ping me if you want me to update them. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
On Thu, May 8, 2008 at 9:09 PM, Fabian Groffen [EMAIL PROTECTED] wrote: e) It has been suggested the support should have been added with new EAPI instead of local build deps (some of which are missing, for instance in the hand-rolled for-no-reason-whatsoever .tar.lzma format net-tools doesn't have a dep in addition to using lzma for no good reason) Chill, relax and cool down. Instead, just ask those who decided to follow upstream why and if they have even thought about the issues you brought up. Note that we're also speaking about downstream lzma archives. Like in sys-apps/net-tools, where lzma hasn't been adopted even by upstream. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: dedicated USE-flag is inconsequent and confusing
On Fri, May 16, 2008 at 3:07 AM, Duncan [EMAIL PROTECTED] wrote: However, AFAIK USE defaults are an EAPI=1 feature, and thus not quite yet encouraged for the general tree. EAPI-1 is approved for use in the tree. People are encouraged to use it whenever they need any feature provided by it. IIRC, system packages are an exception, but it's perfectly ok for the rest. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] am I ready to step into Gentoo?
On Tue, May 20, 2008 at 7:20 PM, Federico Ferri [EMAIL PROTECTED] wrote: my computer-related hobbies (or I should say time-killers!) are Tcl (scripting language) and Pure-Data (multimedia dataflow environment). I regularly use Pd to create audio/video apps, and Tcl for everything else that doesn't fit Pd, I've also developed a Tcl-Pd loader, that allows to code externals for Pd in Tcl. see my Pd page at [3]. perhaps that's the category I should belong to...(?) I keep occasional contact with Tcl developers, so I could bring some love to the Tcl/Tk Gentoo herd (yes, I am a Tcl/Tk fan, as you can see on my wikipage at [4]) I've also set up an overlay (pd-overlay, [5]) and used to develop together with ColdWind (actually a Gentoo dev) ebuilds for EVERY pd external! [...] so what's going to be my next step into Gentoo? perhaps finding a mentor? ColdWind would you...? any one else? I'm in contact with Federico, we agreed that the recruitment process will start when the exams are over, but he's going to start slowly working on it before. I think he can do good work on tcltk, and who knows if he'll work on bringing PureData to Gentoo too! Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: About herds and their non-existant use
On Fri, May 23, 2008 at 10:39 AM, Tiziano Müller [EMAIL PROTECTED] wrote: Marijn Schouten (hkBst) wrote: While we're changing things around, perhaps we can then also standardize the mail alias to [EMAIL PROTECTED] What Marius is saying though is that there are two files that handle people and their herds. One XML for saying who is in a herd and one for each herd mail alias on woodpecker with a list of developer email prefixes. Which could be generated out of the XML file, right? It could, but it would be nice to preserve a method for allowing lurkers on aliases. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
On Fri, May 30, 2008 at 9:16 AM, Mike Auty [EMAIL PROTECTED] wrote: Peter Volkov wrote: | Is there any reason why --as-needed is not enabled by default? There's still about 18 open bugs on the tracker[1] for it. You can see how many problems it had been causing by the huge number of blocking bugs. I've been using it for a pretty long time now (probably a couple weeks after Diego first blogged about it) and don't have many problems at all (now), but every once in a while a version bump or a new package will just fail to compile properly and the problem leads back to as-needed. I'm not sure whether ~arch users would be able to catch all the as-needed bugs before they hit stable, so I couldn't say whether it should be enabled by default or not. That's not a problem at all. If we choose to support --as-needed by default we'd get testing from maintainers when adding new ebuilds, and from arch teams before ebuilds hit stable. --as-needed breaking legitimate code is a problem, though. I wonder if we have that kind of code in any application in the tree and if we have some way to detect it. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for June
On Mon, Jun 2, 2008 at 11:18 AM, Raúl Porcel [EMAIL PROTECTED] wrote: Ryan Hill wrote: On Sun, 01 Jun 2008 19:41:28 +0200 Raúl Porcel [EMAIL PROTECTED] wrote: IMHO the packages should be keyworded if an arch team member or an user of that arch requests it. Keywording something if an user of said arch doesn't request it, is a waste of resources. How is making things available to your users a waste of resources? Anyways, if you're so far behind that you don't think you can manage keywording another package then just say so and deny the request. What does this have to do with council? And whats the point of having some package keyworded if nobody is going to use it? I don't care anyway, i just want an official clarification, personally i tend to keyword stuff if i think its going to be useful. Thing is, whats the difference in a maintainer asking for a package to be keyworded and keywording all the packages in the tree? You're not going to be asked to keyword the whole tree, that's the difference ;-) I think we have not enough feedback from users about this. Either Bugzilla is not the right tool, or we don't encourage users enough to ask for keywords when they need them. Currently, some people assume that if a user from $arch needed this package, he'd have requested keywords, but that's wrong. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] ���^�X��� ��(��j)b�b�
Re: [gentoo-dev] Nominations for council
On Thu, Jun 5, 2008 at 9:44 AM, Fernando J. Pereda [EMAIL PROTECTED] wrote: I'd like to nominate: ColdWind ferdy, thanks for the nomination. astinus, thanks for your support and inspiration, which almost convinced me for running for Council. I decline. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] die/QA notice for do* failure?
On Sun, Jun 8, 2008 at 4:48 PM, Arun Raghavan [EMAIL PROTECTED] wrote: Hello All, We were just discussing if it makes sense to either die or issue a QA notice if one of the do* functions fail. It turns out that there's already a bug for this [1]. This potentially applies to all helper functions that don't currently die on failure. That's indeed a good idea, and we can do a step further. We can define a new EAPI which makes all do* functions die on error, and provide non-fatal versions as trydo* where it makes it sense. emake could also die since we currently add die calls for all emake occurences. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] die/QA notice for do* failure?
On Sun, Jun 8, 2008 at 7:19 PM, Arun Raghavan [EMAIL PROTECTED] wrote: On Sun, Jun 8, 2008 at 10:21 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: [...] That's not how it works. We've seen plenty of times in the past that forcing QA by making users' systems break (which is how far these things get before they're fixed) just leads to lots of annoyed users. EAPI, plus slowly moving things towards new EAPIs on version bumps once newer EAPIs are widely supported, is the clean way of doing this. This might be the clean way to do it, but the unfortunate truth is that new EAPIs seem to be becoming standard pretty darn slowly, and counting on one to implement a feature that is definitely very useful for QA seems to be miring ourselves in unnecessary bureaucracy. (Replying to a random snippet) There has been previous discussion on https://bugs.gentoo.org/show_bug.cgi?id=138792 Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Tue, Jun 10, 2008 at 10:20 PM, Federico Ferri [EMAIL PROTECTED] wrote: The so-called shebang; very good in my opinion! Works very well for true shell scripts. why it can't work for ebuilds? This option was already discussed when GLEP 55 was proposed, and in my opinion it's totally discarded. The concept of shebang doesn't apply here at all. Plus /usr/bin/ebuild is a binary provided by portage which has nothing to do with the process of sourcing ebuilds nor even with the internals of portage (not to speak of other package managers). Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
On Wed, Jun 11, 2008 at 7:53 AM, Luca Barbato [EMAIL PROTECTED] wrote: A whole bunch of science packages have upstreams that say If you're building from source, run 'make check' and if it fails don't carry on. Their rationale behind that is that their code is severely broken, using experimental features from their language of choice or, simply, that they are paranoid and couldn't think better ways to annoy people? It's not as simple as that. A package may fail tests because compiler bugs, build environment misconfiguration, problems in a library which is being used, a setup problem or, of course, a bug in the package which shows up in rare cases and haven't been spoted by upstream yet. When the package can be critical for the system, upgrading to a buggy version will eat people's dogs. I feel a bit safer when I run the test phase for my package manager, and I wouldn't install it if it's failing any test. I don't think that's too paranoid. Also let's put a real example: gmplib. From www.gmplib.org on the front page: IMPORTANT INFORMATION FOR ALL GMP USERS: GMP is very often miscompiled! We are seeing ever increasing problems with miscompilations of the GMP code. It has now come to the point where a compiler should be assumed to miscompile GMP. Please never use your newly compiled libgmp.a or libgmp.so without first running make check. If it doesn't complete without errors, don't trust the library. Please try another compiler release, or change optimization flags until it works. If you have the skill to isolate the problem, please report it to us if it is a GMP bug; else to the compiler vendor. (The compilers that cause problems are HP's unbundled compilers and GCC, in particular Apple's GCC releases.) Upstream clearly states that a gmp build which tests have failed shouldn't be used. I bet they deny support for users who fail to follow that indication ;-) Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Wed, Jun 11, 2008 at 12:05 PM, 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. If the extension was based on the fact that ebuilds are bash scripts, they'd have .bash extension. The .ebuild extension means a specific kind of bash script and it doesn't seem wrong to change the extension if that specific kind changes, even if bash is still the interpreter. Even if we switched to sh or zsh I doubt we'd use the .sh or .zsh extension. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
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. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-council] Re: [gentoo-dev] One-Day Gentoo Council Reminder for June
On Thu, Jun 12, 2008 at 7:14 PM, Mike Frysinger [EMAIL PROTECTED] wrote: On Thursday 12 June 2008, Donnie Berkholz wrote: On 04:11 Wed 11 Jun , Brian Harring wrote: Reiterating the early request, I'd like the council to please discuss the current status of PMS, People actually working on the PMS would be better-placed to discuss its current status, if by that you mean progress toward an approved spec. The last I heard was a couple months ago when Ciaran asked us whether there were any further major issues and removed kdebuild-1 from the PDF to be approved. he was told to remove kdebuild-1 from the repo and this has yet to happen This shouldn't block PMS discussions. There's an up to date copy in pdf of PMS built without kdebuild at http://dev.gentoo.org/~coldwind/pms-without-kdebuild.pdf Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Packages broken by phase ordering change
Hi all, As discussed in bug #222721, portage has changed the execution order of phases. It seems the change was introduced in portage-2.1.5 and it makes that, when upgrading a package, pkg_postinst is run after the old version has been removed. This breaks packages which use has_version in pkg_postinst to detect upgrades/downgrades. It can also break packages in more subtle ways. The following ebuilds are affected by has_version problem. There may be some affected ebuilds missing, and also ebuilds broken in a different way. app-pda/libopensync-0.22 app-portage/conf-update-1.0 dev-libs/libotf-0.9.4 dev-libs/libotf-0.9.5 dev-libs/libotf-0.9.6 dev-libs/libotf-0.9.7 dev-util/scons-0.97 dev-util/scons-0.98.3 dev-util/scons-0.98.4 mail-filter/dspam-3.8.0-r11 media-gfx/splashutils-1.5.2.1 media-gfx/splashutils-1.5.3.4 media-gfx/splashutils-1.5.4 media-gfx/splashutils-1.5.4.1 media-gfx/splashutils-1.5.4-r1 media-libs/libdvbpsi-0.1.5 media-libs/libdvbpsi-0.1.6 media-libs/libexif-0.6.16 media-libs/libexif-0.6.16-r1 media-libs/pdflib-7.0.2 media-libs/pdflib-7.0.2_p8 media-plugins/vdr-epgsearch-0.9.19 media-plugins/vdr-epgsearch-0.9.20 media-plugins/vdr-epgsearch-0.9.21 media-plugins/vdr-epgsearch-0.9.22 media-plugins/vdr-epgsearch-0.9.23 media-plugins/vdr-epgsearch-0.9.24 media-plugins/vdr-epgsearch-0.9.24_beta19 media-plugins/vdr-epgsearch-0.9.24_beta22 media-plugins/vdr-epgsearch-0.9.24_beta23 media-plugins/vdr-epgsearch-0.9.24_beta26 media-plugins/vdr-epgsearch-0.9.24_rc2 media-tv/gentoo-vdr-scripts-0.4.0 media-tv/gentoo-vdr-scripts-0.4.1 media-tv/gentoo-vdr-scripts-0.4.2 media-tv/gentoo-vdr-scripts-0.4.3 media-tv/gentoo-vdr-scripts-0.4.3-r1 media-tv/gentoo-vdr-scripts-0.4.4 media-tv/vdrplugin-rebuild-0.2 media-video/vdr-1.4.6 media-video/vdr-1.4.7-r10 media-video/vdr-1.6.0 media-video/vdr-1.6.0_p1 media-video/vdr-1.6.0_p1-r1 media-video/vdr-1.6.0-r1 media-video/vdr-1.6.0-r2 net-analyzer/fail2ban-0.8.0-r1 net-analyzer/fail2ban-0.8.1 net-analyzer/fail2ban-0.8.2 net-dialup/ppp-2.4.4-r14 net-dialup/ppp-2.4.4-r15 net-firewall/iptables-1.3.5-r4 net-firewall/iptables-1.3.6 net-firewall/iptables-1.3.6-r1 net-firewall/iptables-1.3.7 net-firewall/iptables-1.3.8 net-firewall/iptables-1.3.8-r1 net-firewall/iptables-1.3.8-r2 net-firewall/iptables-1.3.8-r3 net-firewall/iptables-1.4.0 net-mail/getmail-4.7.6 net-mail/getmail-4.7.7 net-mail/getmail-4.7.8 net-mail/getmail-4.8.1 net-mail/mailgraph-1.14 net-misc/asterisk-1.2.13 net-misc/asterisk-1.2.13-r1 net-misc/asterisk-1.2.14 net-misc/asterisk-1.2.14-r1 net-misc/asterisk-1.2.14-r2 net-misc/asterisk-1.2.17 net-misc/asterisk-1.2.17-r1 net-misc/asterisk-1.2.21.1 net-misc/asterisk-1.2.21.1-r1 net-misc/asterisk-1.2.27 net-misc/freenet6-4.2.2 net-misc/freenet6-5.0 net-misc/freenet6-5.1 net-misc/ser-0.9.4 net-misc/ser-0.9.6 net-misc/ser-0.9.7 net-print/cups-1.2.12-r4 net-print/cups-1.2.12-r7 net-print/cups-1.2.12-r8 net-print/cups-1.3.7-r1 net-print/cups-1.3.7-r2 sys-cluster/util-vserver-0.30.214 sys-cluster/util-vserver-0.30.215 sys-fs/udev-114 sys-fs/udev-114-r1 sys-fs/udev-114-r2 sys-fs/udev-115 sys-fs/udev-115-r1 sys-fs/udev-115-r5 sys-fs/udev-115-r6 sys-fs/udev-116 sys-fs/udev-116-r1 sys-fs/udev-117 sys-fs/udev-118 sys-fs/udev-118-r1 sys-fs/udev-118-r2 sys-fs/udev-118-r3 sys-fs/udev-119 sys-fs/udev-119-r1 sys-fs/udev-120 sys-fs/udev-121 sys-fs/udev-122 sys-fs/udev-122-r1 sys-fs/udev-124 sys-process/vixie-cron-4.1-r10 www-client/surfraw-2.1.5 www-servers/apache-2.2.8 www-servers/apache-2.2.8-r3 www-servers/apache-2.2.8-r4 If the new phase order is staying, then all those packages should be fixed. It's possible to use has_version in pkg_setup or other phase and cache the result in a global variable. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: A few questions to our nominees
On Sat, Jun 14, 2008 at 10:19 AM, Luca Barbato [EMAIL PROTECTED] wrote: Ryan Hill wrote: I'm guessing the dev would need to change 0.26.live to 0.26.1.live when 0.26 was released. I already need to do this with my live ebuilds. Of course, with some projects you never know if the next version will be 0.26.1, 0.27, or 0.3, or 1.0... That's an upstream issue, all we should care is about getting a version value that makes sense for us, better if it does for them. I think upstream use release branches correctly here, and it's the most widespread use. There's some real examples where .live = _pre has problems. * media-video/mplayer: I'd expect 1.0.live to be higher than 1.0_rc2, but it doesn't. I'd also expect 1.0.live to be higher than 1.0 when it's released. * media-video/ffmpeg: Pretty much the same that mplayer, but a bit worse. * x11-wm/enlightenment: latest release is 0.16.8.13, current live ebuild is 0.16.. If we use .live here we'd need either 0.16..live (which is quite pointless) or 0.16.8.14.live which would need to be updated after every minor release. 0.17.live is not a possibility at all since 0.17 is a rewrite from scratch and an entire different application. * media-sound/amarok: live version is 1.4.. Next version is 2.0, but that's a different branch so I'd expect 2.0.live to give me the latest 2.0 version available, not 1.4's. With the current proposal, .live ebuilds should be changed after every minor release, unless we use the number of the next release. Next release isn't always known, and it's doesn't always make sense. This puts us in a worse situation than with GLEP 54, or even with the current use of . components. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Packages broken by phase ordering change
On Sun, Jun 15, 2008 at 12:32 PM, Matthias Schwarzott [EMAIL PROTECTED] wrote: On Freitag, 13. Juni 2008, Santiago M. Mola wrote: Hi all, As discussed in bug #222721, portage has changed the execution order of phases. It seems the change was introduced in portage-2.1.5 and it makes that, when upgrading a package, pkg_postinst is run after the old version has been removed. This breaks packages which use has_version in pkg_postinst to detect upgrades/downgrades. It can also break packages in more subtle ways. So someone that has access permissions here: Please do fix the devmanual http://devmanual.gentoo.org/ebuild-writing/functions/pkg_postinst/index.html https://bugs.gentoo.org/show_bug.cgi?id=226419 Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: What to do when Python 2.5 is blocking your package from entering stable? (Agenda for next council meeting?)
On Fri, Jun 20, 2008 at 9:34 AM, Tiziano Müller [EMAIL PROTECTED] wrote: Rob Cakebread wrote: Samuli Suominen wrote: I don't know about you, but when a package can't be stabled because it's depending on Python 2.5 and current stable is broken I'd like to start reverting stable keywords back to ~arch as noone wants to maintain broken junk. Latest being app-cdr/gtkcdlabel, and media-video/gaupol. Perhaps it should be a council agenda? Not much different from slacking arches, it's simple, lack of active devs. What I would prefer, of course, is a list from one of python members to get it into stable but have no expetations, since I've asked it many times past 1-2 years. Unless there are any objections from the rest of the Python project, I'll try to get this done within the next 24 hours. I think it's good to go. There are a few things which need some kind of action before/during python 2.5 stabilization: Needs stabilization: * dev-python/python-bibtext-1.2.3 * dev-python/pyvorbis-1.4-r3 (a bit buggy, debian has patches for 1.3, some of them can be ported) * tinyerp? http://qa.mandriva.com/show_bug.cgi?id=31554 * dev-libs/xapian-1.0.6 * dev-libs/xapian-bindings-1.0.6 * dev-python/pygame-1.8.0 (buggy, I have patches from trunk, we might want to wait to 1.8.1) * dev-python/soappy-0.12.0 (bug #216385) Needs fix: * x11-misc/qterm (bug #216466) * dev-db/rekall (bug #141068) - needs bump, probably this is going to be p.masked and eventually removed from the tree Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] ���^�X��� ��(��j)b�b�
Re: [gentoo-dev] When the version scheme changes
On Sun, Jun 29, 2008 at 9:41 PM, Marijn Schouten (hkBst)
[EMAIL PROTECTED] wrote:
The benefit is being able to automatically reversion an ebuild. Reversioning
may
not be necessary very often, but it's annoying when it is and there is no good
reason that it should. There is no benefit in keeping the version variables
read-only.
Marijn
I think that doing PV=${PV/0./} is asking for trouble, even if we
had a function for reseting it after the change. In any case it should
be a function like reset_pv ${PV/0./} which keeps other variables (P,
S...) consistent. Also, this would imply an EAPI bump.
I doubt this change is worth the trouble.
Regards,
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Multislot dependencies
On Tue, Jul 1, 2008 at 2:47 PM, Enrico Weigelt [EMAIL PROTECTED] wrote: Well, some of you might still remember what I said about gtk and slots long time ago. Just to summarize my point: * the use of slots should be MINIMIZED. IMHO, the kernel is one of the few valid uses, gtk is NOT (1.* and 2.* are *different* packages and so should be treated differently). * at runtime an most packages need that variant/slot they were built for (and gtk1'ed package needs gtk-1.x, NOT gtk-2.* and vice versa) This is not going to change. We already unified the gtk USE flag, we have SLOT dependencies now, and, generally, prior discussion, decisions and common practices shows that we're not going to follow that path. We are talking about multislot dependencies. At this point, your arguments are noise. So, please, don't continue with these points in this thread. Thanks, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Tags vs. categories (was: sci-libs/scipy - dev-python/scip)
On Tue, Jul 8, 2008 at 9:31 AM, Josh Saddler [EMAIL PROTECTED] wrote: Tags instead of categories . . . Now here's a very interesting idea, indeed. Has there ever been a proposal like this for Gentoo? Tags . . . I like the idea. I like it a lot. Thoughts? Exciting? Or is it an old issue, and I'm 5 years late to the party. :) Exherbo will change its category system at some point. There has been some discussion about it which may be interesting for people thinking about possible replacements in Gentoo: http://lists.exherbo.org/pipermail/exherbo-dev/2008-May/000149.html There was similar discussions in @g-dev but I'm too lazy to start serching the relevant threads. Best regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Council meeting summary for 10 July 2008
On Mon, Jul 14, 2008 at 5:32 AM, Jeroen Roovers [EMAIL PROTECTED] wrote: What GLEP 55 fails to address right now is the very development process it is seemingly supposed to alleviate. It addresses the issue of EAPI implementation from the viewpoint of the package manager's developer, but it doesn't begin to address the viewpoint of the package maintainer or architecture developer at all. It looks to me like a lot of problems are moved out of the package manager(s) and into this already huge tree of files, with different EAPI-suffixed files addressing different problems, and that indicate be a non-trivial increase in the number of files in the tree - files which would address the equal purpose of installing exactly one =cat/pkg-ver. GLEP 55 says: Note that it is still not permitted to have more than one ebuild with equal category, package name, and version. In other words, disregarding its other real world deficiencies like an immediate goal, GLEP 55 fails to describe a keywording policy for architecture developers Keywording policy wouldn't change. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
On Sat, Aug 2, 2008 at 12:26 PM, Zac Medico [EMAIL PROTECTED] wrote: Mike Auty wrote: If there's need for a new class of ebuild information (such as a new way of categorizing ebuilds by feature), perhaps we should add an ebuild features variable specifically for the purpose? That requires an EAPI bump, which also means that it can't be used in ebuilds with EAPI 0 or 1. The RESTRICT solution is simpler and we can use it right now in any ebuild. I don't think we're in a hurry for this feature, so I don't see the need of using suboptimal hacks in order to avoid an EAPI bump. Furthermore, EAPI 2 is supposed to be done in the near future, right? Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
On Sun, Aug 3, 2008 at 12:25 AM, Zac Medico [EMAIL PROTECTED] wrote: Santiago M. Mola wrote: I don't think we're in a hurry for this feature, so I don't see the need of using suboptimal hacks in order to avoid an EAPI bump. Furthermore, EAPI 2 is supposed to be done in the near future, right? Regards, I don't view the RESTRICT=live idea as suboptimal or a hack in any way. I see it as a legitimate use of an existing ebuild variable that's already used for lots of other legitimate purposes. Let me rephrase the point as that this method should not be favoured over others just because it doesn't require an EAPI bump. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] Gentoo Council Reminder for August 7
On Tue, Aug 5, 2008 at 1:06 AM, Alec Warner [EMAIL PROTECTED] wrote: On Mon, Aug 4, 2008 at 11:29 AM, Stephen Bennett [EMAIL PROTECTED] wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know! Simply reply to this e-mail for the whole Gentoo dev list to see. I would like to put forward the following suggestion for the Council's consideration: While the current state of PMS is not perfect, it is a reasonably close approximation to existing and historical behaviour of EAPI 0. Given this, and that getting a perfect definition is not feasible on a timescale shorter than several years, it should be treated as a draft standard, and any deviations from it found in the gentoo tree or package managers should have a bug filed against either the deviator or PMS to resolve the differences. [...] Is there some reason why this needs to be stated explicity (eg. are you having difficulty getting things fixed in the tree?) Currently it can't be referenced from other official documentation. There's already one GLEP which had to get references to PMS removed because of this. And it will become a bigger problem when we have more EAPIs and we can't rely on any spec except short summaries posted to @dev-announce. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] Retirement
On Sun, Aug 10, 2008 at 10:56 PM, Ingmar Vanhassel [EMAIL PROTECTED] wrote: There're other projects in the Free-Software world that I currently enjoy putting my time into more, I'm sure it's more than obvious to those of you who know me which... Good luck with that project! -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] Retirement
On Mon, Aug 11, 2008 at 12:26 AM, Bo Ørsted Andresen [EMAIL PROTECTED] wrote: My retirement is probably long overdue as I haven't really been active for several months. It is now clear to me that Gentoo is not moving in the direction I had wished for and the last council election indicates that most current Gentoo developers appear to be satisfied with this current direction. Therefore farewell. If anybody wants to reach me I can be reached at bo.andresen at zlin.dk. So long, and see you on the evil side ;-) -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] [GLEP 56] metadata.xml USE flag descriptions [Clarifications]
On Wed, Aug 13, 2008 at 7:11 PM, Doug Goldstein [EMAIL PROTECTED] wrote: Howdy all, Further questions regarding use.desc have come up with regard to this GLEP. My proposed solution would be a potential amendment to the GLEP to state that flag name='png' / Would be allowed. This syntax is not actually disallowed or allowed by the current GLEP, but mentioning it would allow a metadata.xml contain all the USE flags that appear in IUSE, even the global ones. By using the above syntax, it would simply state that there is no additional descriptions or details but to just use the use.desc description. Further more, it would allow us in the future to make that mandatory and repoman would only have to check metadata.xml for your USE flag. Comments, Suggestions, Input are all welcome. What is the benefit? Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] The Plethora of Patches
On Thu, Aug 14, 2008 at 4:17 AM, Andrew D Kirch [EMAIL PROTECTED] wrote: Patches in the metadata.xml should have some sort of status tracking for each patch, repoman should flag any that don't, and warn on any that have not been submitted upstream unless the status is signed off on by a herd leader (such as Gentoo specific patches). This would provide visual feedback for users and developers with regard to a pretty important metric on how successful Gentoo is at getting patches pushed back to developers. It was proposed recently to add some standarized headers to all new patches for maintenance purposes. Something like: Source: patch by John Foo, backported from upstream, whatever. Upstream: In revision 245, rejected, foo. Reason: Build system sucks I think that's all we need in order to know how were things when the patch was added and if it needs to be pushed/tracked upstream, removed in the next version of the package, etc. Some of us already put these kind of headers, or at least an URL to upstream bug or a meaningful source of info about the patch. However, tracking the status of every patch since its inclusion in portage until it's removed would be a huge work overhead... and I doubt it's worthy. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] The Plethora of Patches
On Tue, Aug 19, 2008 at 12:02 AM, Tobias Scherbaum [EMAIL PROTECTED] wrote: Santiago M. Mola wrote: However, tracking the status of every patch since its inclusion in portage until it's removed would be a huge work overhead... and I doubt it's worthy. I don't think it's a huge work overhead, it'll take an additional minute per included patch to include a minimal description into the ebuild(s) and use a standardized header for the patch. Compared to the time one needs to spend when searching for information on that patch somewhen later on it's worth every minute. Of course, puting a header with info in every patch is not a work overhead and I'd say it should be policy. What I meant is that it's no worth to track the status of every patch after it's added, as was suggested. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Sat, Sep 6, 2008 at 9:00 PM, Alec Warner [EMAIL PROTECTED] wrote:
On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson [EMAIL PROTECTED] wrote:
Hi,
Currently we have a lot of:
src_configure() {
econf $(use_enable dvdr) \
$(use_with ipv6 ssl) \
--with-system-zlib
}
Introducing(Idea shamelessly taken from Exherbo):
DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS
The code from above could be rewritten like so:
DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )
That's much simpler.
It saves you 1 line and reduces readability and intuitiveness by a
fair margin; how is it simpler?
In the given example it's not a big deal. However, when you're dealing
with more arguments it simplifies things.
For example, this (based on an existing ebuild, but simplified a bit
for brevity):
--
src_compile() {
local myconf=
--sysconfdir=/etc/${PN}
--without-xgrid
--enable-pretty-print-stacktrace
--enable-orterun-prefix-by-default
--without-slurm
if use threads; then
myconf=${myconf}
--enable-mpi-threads
--with-progress-threads
fi
econf ${myconf} \
$(use_enable !nocxx mpi-cxx) \
$(use_enable romio io-romio) \
$(use_enable heterogeneous) \
$(use_with pbs tm) \
$(use_enable ipv6) \
|| die econf failed
emake || die emake failed
}
--
becomes
--
SRC_DEFAULT_CONFIGURE_WITHS=( pbs tm ipv6 threads progress-threads
SRC_DEFAULT_CONFIGURE_ENABLES=(
cxx mpi-cxx
romio io-romio
heterogeneous
threads mpi-threads
SRC_DEFAULT_CONFIGURE_EXTRA_PARAMS=(
--sysconfdir=/etc/${PN}
--without-xgrid
--enable-pretty-print-stacktrace
--enable-orterun-prefix-by-default
--without-slurm )
--
You save some lines, but also you keep out all the use_* calls with
their backslashes, myconf=$myconf crap, econf/emake || die...
Regards,
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Sat, Sep 6, 2008 at 10:10 PM, Ben de Groot [EMAIL PROTECTED] wrote:
Alec Warner wrote:
On Sat, Sep 6, 2008 at 10:36 AM, Thomas Anderson [EMAIL PROTECTED] wrote:
Hi,
Currently we have a lot of:
src_configure() {
econf $(use_enable dvdr) \
$(use_with ipv6 ssl) \
--with-system-zlib
}
Introducing(Idea shamelessly taken from Exherbo):
DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS
The code from above could be rewritten like so:
DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )
That's much simpler.
It saves you 1 line and reduces readability and intuitiveness by a
fair margin; how is it simpler?
It may be 2 lines less, but it is 42 characters more.
Plus, I dislike caps. :-p
In the example I posted it's 339 characters less. Almost half of the
original ;-)
Regards,
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Sun, Sep 7, 2008 at 6:50 PM, Ciaran McCreesh
[EMAIL PROTECTED] wrote:
On Sun, 07 Sep 2008 12:46:45 -0400
Marcus D. Hanwell [EMAIL PROTECTED] wrote:
The proposal is not designed to replace all cases. It's designed to
replace the common 50%.
I personally agree with several others who have replied to this
thread. The reduction in lines of code/characters seems to introduce
an uglier syntax which is harder to read with questionable benefits.
Try using it for a few weeks. Once you're used to it it's considerably
nicer than going through and implementing pointless src_configures all
over the place...
Yes. And here another point should be brought up. This proposal should
be wider and consider similar changes for the most common used
operations on all phases. Implementing it only for
src_{configure,compile} won't feel so useful as implementing similar
variables for most phases.
Regards,
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Mon, Sep 8, 2008 at 9:48 AM, Vaeth [EMAIL PROTECTED] wrote: But it doesn't do this well, because it is incompatible with any other case. Assume, for example, that you have an ebuild in this manner and that for the new release or for a bugfix you need a small non-included thing - then this means that you have to rewrite the ebuild almost completely. The suggestion violates in an extreme way the golden design rule that small changes in effect should require small changes in source. Moreover, a second syntax is introduced which everybody has learn, although it could be done as easily by the standard commands. Yes, you're right. That would be really tedious and stupid... but we're lucky, and EAPI-2 introduced the 'default' function. So if you need to do a small change not covered by this method, you just define the phase, make the little change, and then call the 'default' function. Clean and simple. In any case, I guess people are not considering this change for EAPI-2. I think we'll come up with a more extense proposal which could be targeted for EAPI-3. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Mon, Sep 8, 2008 at 10:44 AM, Alec Warner [EMAIL PROTECTED] wrote:
Most obvious failure cases these days have build logs and the build
logs will specify what the configure command
was, so the only problematic area is looking at the ebuild to
determine what will happen during execution. Arguably having
an ebuildshell would assist here. However, ebuilds are already
sufficiently complicated by eclass inheritance that reading
many ebuilds is already difficult and I think this extension does not
make that significantly worse.
If you're just dealing with the default phases, it's not too hard to
say in advance the exact command that will be executed. Default phases
are well-defined in PMS. So you can look at them to see what will
happend if you define some variable.
For example, for the proposed arguments for src_configure, a
definition would be something like this (taken from Exherbo, just
pretend it says USE instead OPTION and you're done):
default_src_configure()
{
if [[ -x ${ECONF_SOURCE:-.}/configure ]] ; then
econf \
[EMAIL PROTECTED] \
$(for s in ${DEFAULT_SRC_CONFIGURE_OPTION_ENABLES} ; do \
option_enable ${s} ; \
done ) \
$(for s in ${DEFAULT_SRC_CONFIGURE_OPTION_WITHS} ; do \
option_with ${s} ; \
done )
fi
}
It's quite straightforward.
Regards,
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
On Mon, Sep 8, 2008 at 1:56 PM, Vaeth [EMAIL PROTECTED] wrote: Santiago M. Mola wrote: Vaeth [EMAIL PROTECTED] wrote: [...] The suggestion violates in an extreme way the golden design rule that small changes in effect should require small changes in source. [...] Yes, you're right. That would be really tedious and stupid... but we're lucky, and EAPI-2 introduced the 'default' function. So if you need to do a small change not covered by this method, you just define the phase, make the little change, and then call the 'default' function. Clean and simple. How does this little change look like if you have to call ./autogen.sh instead of ./configure? Most of the time you don't call autogen.sh, but eautoreconf. And when you have to call ./autogen.sh you usually do it in src_unpack (or src_prepare if it's introduced in EAPI-2). Or if you want to call a second ./configure in some subdirectory with the same options but one option changed? This is not a small change that happens on any package too often (if ever). For such cases you can define a custom src_configure/src_compile which fits your needs. These are just some examples, I hope that the point becomes clear: You simply cannot cover all natural modifications which might be necessary unless you really can access the commands themselves; You can access the commands themselves,I think no one said ever in this thread that use_with, use_enable or econf are going to be deprecated. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] Bug wrangling
On Mon, Sep 8, 2008 at 10:38 PM, Dawid Węgliński [EMAIL PROTECTED] wrote: On Monday 08 of September 2008 22:22:12 Joe Peterson wrote: Christian Faulhammer wrote: everyone working on bugs, please add all people from metadata.xml to the assignee or cc field, I regularly have to search for bugs where a team and I maintain a package because only the team has been added. Second, please use full atoms (cat-egory/package) in the Summary field, so searching is easier. Sorry if this answer can be found elsewhere, but if one has a proxy maintainer (i.e. not a Gentoo dev) for a package, can/should this person be added to metadata.xml? Is there a special tag for this? I can certainly see this being helpful (so that person automatically gets on the cc list at least). Thanks, Joe Yes, and usually that's how it's done. Eg eix' metadata.xml says: maintainer email[EMAIL PROTECTED]/email nameMartin Väth/name /maintainer Yep. And for more completeness you can add something like descriptionProxied maintainerdescription/. Although, it's quite obvious when it's a non-Gentoo email. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] One-Day Gentoo Council Reminder for September
On Thu, Sep 11, 2008 at 4:55 PM, Robert Buchholz [EMAIL PROTECTED] wrote: On Thursday 11 September 2008, Ciaran McCreesh wrote: On Wed, 10 Sep 2008 23:43:54 -0700 Zac Medico [EMAIL PROTECTED] wrote: [2] http://dev.gentoo.org/~zmedico/portage/eapi/eapi-2-draft.html By table 6.11, are you implying that you consider the new pkg_ phase order to be part of EAPI 2? Really, Portage needs to revert the order and go back to the way it used to be for all EAPIs. The change breaks lots of existing ebuilds (you claim you've probably fixed everything in ::gentoo, but you don't know that and you've definitely not fixed overlays), including ebuilds using a common documented technique recommended by the devmanual. If you want the new pkg_* ordering to go through at all, it really needs a lengthy discussion on its own and it mustn't apply to any action that involves any existing EAPI. I'd like the Council to say that for anything involving EAPIs 0, 1 or 2 we stick to the pkg_* phase ordering we've used years. What is the change of order you witnessed in table 6.11 of the draft? Comparing that to the PMS on [3], the order looks identical to me (except for the two new phases). Am I missing something? Robert [3] http://dev.gentoo.org/~coldwind/pms.pdf Section 10.2 Previously, the order was different for upgrading/downgrading packages. You can see a summary of the problem in bug #235020 [1]. I sent a note to @-dev [2] with a list of all packages *in the tree* which were affected by the most common problem of the order change (using has_version in pkg_postinst), all of them were quickly fixed by Zac. But there may be more packages affected not included there. [1] https://bugs.gentoo.org/show_bug.cgi?id=226505 [2] http://archives.gentoo.org/gentoo-dev/msg_27feec8fc563e406b174386d24c39fdc.xml Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] Preventing $ARCH flags in USE
On Mon, Sep 15, 2008 at 9:45 PM, Vlastimil Babka [EMAIL PROTECTED] wrote: I think it's better to prevent this rather than waste time with bug reports like that. I asked Zac on IRC whether portage could filter such flags. He suggested using use.mask in profiles. Well since ARCH is also set by a profile, why not. Although a really persistent and stupid user could use.unmask, it's better than no protection. And then we can think how to replace the current ARCH-USE flag system with e.g. USE_EXPAND. What do you think? Seems like an acceptable workaround. For future EAPIs, ARCH could be a regular USE_EXPANDed flag as you suggest, and package managers could filter any flag in USE which is not listed in IUSE. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] Re: Request for feedback on GNU Patch change
On Wed, Sep 17, 2008 at 9:59 AM, C. Bergström [EMAIL PROTECTED] wrote: Ulrich Mueller wrote: On Wed, 17 Sep 2008, C. Bergström wrote: Here's another idea and I don't know why I didn't think of it sooner.. Instead of any system change to the patch ebuild.. Inside the eutils.eclass do a quick check for gpatch and if it exists use that vs patch. Why not simply alias patch=gpatch in profile.bashrc? See the FreeBSD profile for an example. I'd like to package portage for OpenSolaris and have it just drop-in work so modifications like what you suggest wouldn't be required. You'd still need to create an OpenSolaris profile. While you're at it, you can create a profile.bashrc with the required modifications. I don't see any reason to not do the gpatch change, but it looks like unecessary to me because you already have simpler ways to solve the problem. So, requiring others to do a significant useless amount of work when you can solve it with just a line is not fair. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
El mié, 24-09-2008 a las 02:35 +0200, Robert Buchholz escribió:
Let's go with an even simpler default implementation:
default_src_install() {
if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
emake DESTDIR=${D} install || die emake install failed
fi
if [ -n ${DOCS} ]; then
dodoc ${DOCS} || die dodoc failed
fi
}
It addresses the following issues:
* Do not run einstall if emake fails
* Run dodoc even if no Makefile is present, this might come in handy for
ebuilds calling default()
* die dodoc failure case
* hopefully fix the flaws (not really) pointed out by zlin
Looks far better. In my opinion, that would be an acceptable
implementation of default_src_install.
Regards,
--
Santiago Moisés Mola
Jabber: [EMAIL PROTECTED] | GPG: AAD203B5
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] Re: Slacking arches - which are stable, which aren't?
El lun, 06-10-2008 a las 23:13 +, Duncan escribió: Jeremy Olexa [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 06 Oct 2008 15:07:14 -0500: AFAIK, it is incorrect right now to exclude s390, arm, sh, etc on stablereqs right now..But, I ask this question to the dev community: Why? There are ~190 open bugs with s390 as assignee or on the CC list. Does it *really* matter if these under-staffed odd arches have a stable tree or not? Having been an amd64 user back when it was much smaller, and having followed the previous discussion on this here, including the mips - experimental move, yes, it does matter. With the bugs there's at least some info on a package and its stabilization potential when/if someone gets around to doing something about it. Without them, the job of bringing them back to unsupported and then to full supported, if there's suddenly a leap in interest, becomes much harder as there's that much less info on what /was/ stable at one point, and on anything in the ~arch versions that might need checked before they go stable again. I fully agree. I think bringing some understaffed arches back to ~arch is an option, but should be avoided if possible. I wonder how many of these 190 open bugs in s390 are actually bugs about brokenness, and not just regular stabilizations... And by the way, amd64 had a similar amount of open bugs by the end of 2007. Regards, -- Santiago Moisés Mola Jabber: [EMAIL PROTECTED] | GPG: AAD203B5 signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] Stabilize ebuilds which use EAPIs only supported by ~arch PMs
El mar, 14-10-2008 a las 18:24 -0700, Alec Warner escribió: On Tue, Oct 14, 2008 at 3:34 PM, Petteri Räty [EMAIL PROTECTED] wrote: There's no need to commit straight to stable. Just make two different new revisions for each EAPI. Then the arch teams can test it like usual. Aha a perfect canidate use case for GLEP 55[1] that fends off 'why are there multiple versions of the same package' questions and complexities. If you're thinking about having two equal versions with different EAPIs, that's not allowed by GLEP 55: Note that it is still not permitted to have more than one ebuild with equal category, package name, and version. Although it would have the advantage of allowing authors to provide backwards compatible ebuilds, it would introduce problems too. The first is the requirement to have strict EAPI ordering, the second is ensuring that all the ebuilds for a single category/package-version are equivalent, i.e. installing any of them has exactly the same effect on a given system. Regards, -- Santiago Moisés Mola Jabber: [EMAIL PROTECTED] | GPG: AAD203B5 signature.asc Description: Esta parte del mensaje está firmada digitalmente
