Re: [gentoo-dev] List of User projects
René 'Necoro' Neumann wrote: Am 28.03.2010 10:30, schrieb Luis Francisco Araujo: himerge Hey :P - you are a gentoo dev :P I think probably most of the app-portage category falls in here (as portage is the only gentoo-specific thing one can develop stuff for): eix, etc-proposals, gpytage, ... But himerge is not an official Gentoo project. So I guess it falls into the category of user developed projects :P -- Luis F. Araujo araujo at gentoo.org Gentoo Linux
[gentoo-dev] Re: [gentoo-dev-announce] List of User projects
Alistair Bush wrote: I was just thinking how nice it could be if we acknowledged some of the projects that contribute to gentoo but are actually developed primarily outside of gentoo's dev community. How about a page on gentoo.org So lets me start with a couple of obvious ones. kportagetray pkgcore paludis There must be more than these or else gentoo really is dead. - Alistair ps. I would like the packages to be specifically for gentoo, but there are exceptions to this. as an example openrc (and even paludis to a degree). If you think that there is a package not specifically targetting gentoo that deserves a mention please make it clear why. The set of graphical front-ends for portage: portato porthole himerge And yes, it'd be nice to have a page listing these kind of projects. -- Luis F. Araujo araujo at gentoo.org Gentoo Linux
[gentoo-dev] libffi situation
Hello there, This email is to ask for suggestions about bug #163724 , I am myself one of the maintainer of several packages depending upon such a library, and the current situation isn't helping too much to decide how to handle such a packages. As we all know, the independent libffi project was long time unmaintained , but it seems like the developers have started to work on it again; I _think_ the best approach would be to give it preference instead of the gcc option. So, I ask, what road should we take? Also, can we probably unmask the dev-libs/libffi package?, it seems to me a bit exaggerated that it is masked. Thanks and Regards, -- Luis F. Araujo araujo at gentoo.org Gentoo Linux
Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins
Luis Francisco Araujo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: | Hi folks, | | Sorry that it's taken this long to get completed, but the Jeeves | replacement, Willikins, is finally 99% done, and ready to join lots of | channels. | Please join #gentoo-bo , /me is the channel contact Thanks! -- Luis F. Araujo araujo at gentoo.org Gentoo Linux
Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: | Hi folks, | | Sorry that it's taken this long to get completed, but the Jeeves | replacement, Willikins, is finally 99% done, and ready to join lots of | channels. | | Getting the bot out there | - | If you would like to have the new bot in your #gentoo-* channel, would | each channel founder/leader please respond to this thread, stating the | channel name, and that they are the contact for any problems/troubles. | | Bug reports | --- | Please open a bug in the Gentoo Infrastructure product, using the | 'Other' component, and assign it directly to me. | | Custom bot functionality: | - | Here's all the functionality that we have assembled, beyond the standard | rbot stuff. | Bugzilla | | !bug [ZILLA] ID | Looks up bug #ID in the per-channel default or specified bugzilla. | | !bugstats [ZILLA] | Totals of bugs per the bugzilla 'status' field. | | !archstats [ZILLA] [STATUS] [RESO] | Totals of bugs per architecture, optionally with some specific set of | status or resolution values, comma delimited. | | status = OPEN, DONE, UNCONFIRMED,NEW,ASSIGNED,REOPENED, RESOLVED, VERIFIED, CLOSED | Reso = FIXED, INVALID, WONTFIX, LATER, REMIND, DUPLICATE, WORKSFORME, |CANTFIX, NEEDINFO, TEST-REQUEST, UPSTREAM | zilla = gentoo xine sourcemage redhat mozilla kernel fdo abisource | apache kde gnome | If you want another bugzilla, file a bug. | | Gentoo-specific | === | !meta [-v] [CAT/]PACKAGE | Print the metadata and optionally herd members for a given package. | | !changelog [CAT/]PACKAGE | Changelog stats for a package | | !devaway list | List all away developers. | | !devaway DEVNAME | Display .away message for a single developer. | | !herd HERD | Show herd members | | !expn NAME | Show the expansion of any public Gentoo mail alias | | !glsa GLSAID | Shows the title and external IDS for any given GLSA ID. | | !earch [CAT/]PACKAGE | Earch output for a given package | | !rdep [CAT/]PACKAGE | Reverse RDEPEND for a given package | | !ddep | Reverse DEPEND for a given package | | What isn't supported yet | | 1. !glsa -s TEXT | This used to search for GLSAs that matched that string in their title or | external IDS. | | 2. New bug announcements | Jeeves used to announce brand new bugs to #gentoo-bugs as well as | targeted channels or users, depending on the product, component, | assignee, cc and a number of other factors (deeply nested if/else | trees). The old implementation had this in code entirely, and it would | be nice to avoid having to modify the code whatsoever, and instead have | some domain-specific language for doing this. | | Source availability | --- | Gentoo specific: | http://git.overlays.gentoo.org/gitweb/?p=proj/rbot-gentoo.git | Bugzilla support: | http://git.overlays.gentoo.org/gitweb/?p=proj/rbot-bugzilla.git | (flameeyes has his own tree as well, but he's been sick lately, so it | was lagging behind my development) | | Right now, if you want to run your own instance of the bot, you will | need the latest Git tree of the rBot itself, as upstream only fixed the | last remaining issue a couple of hours ago. | | Thanks to | - | solar: | Running the old Jeeves Eggdrop till now, and helping to document all of | the Eggdrop functionality we used. | | flameeyes: | Bugzilla plugin development | | halcy0n: | Gentoo-specific stuff | | tango_, jsn-: | (rbot upstream developers) For fixing the bugs as I found them :-). | Please, join the bot to: #gentoo-guis #gentoo-haskell - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiaXg8ACgkQNir3WYj9aLrkygCfdTbOYOtO0mjyk3JxGuzsuTIl IJQAn0Hz7M91Xk6KSHtD2AuCXOMVYbQy =Eokl -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 René 'Necoro' Neumann wrote: | Zac Medico schrieb: | Well, RESTRICT has long since evolved into a rather generic set of | boolean flags and it's quite useful as such. I don't see any need | for artificial limitations on what types of flags go there. | | For you it is just one variable amongst others - and you really don't | care about the relation between its name and its content. But perhaps | just for the sake of easier understanding of ebuilds, this relation | should be kept. Otherwise you'll read in future documentation: The name | is just for historical reasons and does not reflect the content. -- And | this is nearly always a stumbling block for the non-experienced. | | Perhaps in a later EAPI RESTRICT might be renamed to something like | FLAGS - and then can really be used as a pool of flags. Can the RESTRICT=live value be interpreted as , 'restrict this ebuild to live repositories' or , if you want, 'this package will only build from live repos'? In either case, I don't see the fuss regarding this naming thing, considering RESTRICT is already being used for similar functionality. Regards, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiU9e8ACgkQNir3WYj9aLpH0wCfS0t7t9md+kPmVZsppiekybe4 TNUAoIsGXS+wnGTpqZRNLpRTLwSGG7vk =xLIG -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: | Hi everyone, | | It might good to add support for a new RESTRICT=live value in | ebuilds. By specifying this value, an ebuild would be able to | indicate that it uses src_unpack() to download sources from some | type of live repository such as cvs, darcs, git, mercurial, or svn. | | This new RESTRICT=live value would be useful in at least a couple of | ways. One is that it could be used to implement a @live-rebuild | package set that's based on RESTRICT instead of INHERITED [1]. It | could also be used to implement a more accurate LIVEVCS.stable check | in repoman, again based on RESTRICT instead of INHERITED [2]. | | We already have plans for more advanced live ebuild support, | including live update detection, that will involve an EAPI bump [3]. | However, the RESTRICT=live value is a simple enhancement that we can | add now, without the need for an EAPI bump. Thoughts? | | Zac | | [1] | http://planet.gentoo.org/developers/zmedico/2008/07/31/live_rebuild_package_set | [2] http://sources.gentoo.org/viewcvs.py/portage?view=revrev=3457 | [3] http://bugs.gentoo.org/show_bug.cgi?id=182028 +1 - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiT6XwACgkQNir3WYj9aLrhlwCfdmyhqPLSSSgH68UvE7KopAkD siYAnjEANXpkbuTA83yRIsIztp9kDVL7 =dJiJ -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: 0-day bump requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeroen Roovers wrote: | - | 1) How do you feel when you receive an early version bump request? | | It's generally fine with me; though I would handle it differently depending upon the situation. For example, sometimes these version bumps require some researching or testing for some fix or feature, and I really like to test or check out that first by myself, in such a cases, it could take a while for me to version bump and I also try to keep the user informed about it through the bug report (it has worked fine for me so far). If it is a straight bump with minimal changes, I could take care of it immediately , in either cases, I don't care the user filing an early request ... as long as they don't care how long it might take for me to get it into portage :-) | 2) If you had your way, would you discourage users from filing early | version bump requests? | No. It's fine with me. | - | | I know, it's not a particularly good survey, but I hope the plenty and | diversity of your answers will shed more light on the matter. :) | | | Thank you and kind regards, | JeR | | | [1] In fact I regularly use the opportunity to check on the HOMEPAGE | whether the release was security related, and I assign directly to | security@ when that is the case (CC'ing the package's maintainers) and | perhaps pasting ChangeLog or advisory info in a comment. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhteEsACgkQNir3WYj9aLrrjgCfZZMejTL8o0VtHCWnD1s48SuJ ZjkAn3X0aW0uq3cwF7gSl8aZv8HVB309 =L06A -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Leverton wrote: | On Thursday 05 June 2008 19:21:24 Albert Zeyer wrote: | Are you sure that Squeak really depends on libffi? | | I just compiled it (squeak-3.9.7) fine without having libffi on my | system and with disabled libffi USE-flag. | | According to my reading of the code, it doesn't use libffi on x86-linux, | ppc-linux and ppc-darwin, but does on all other platforms. In any case, it | should be fine with the libffi in gcc, it's just a case of the maintainer | finding time to update the ebuild. It used to strictly depend on libffi for some earlier versions of squeak, so the DEPEND was there long before I added myself as the maintainer of the package. It isn't needed right now _unless_ you have squeak packages requiring so (and we don't have those in the tree), so it is safe to remove such a dependency and probably add a libffi USE flag conditional for those willing to use the GCC one. Regards, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhI5VQACgkQNir3WYj9aLro2QCbBm14/mBTjL0UEuSSBZwP1BSm KJEAn0EA4mzQZutzefHfsGEWIDg6LbKF =q2lC -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Samuli Suominen wrote: | # Samuli Suominen [EMAIL PROTECTED] (05 Jun 2008) | # Masked for removal in ~30 days by treecleaners. | # Replaced by USE libffi in sys-devel/gcc. Bug 163724. | dev-libs/libffi | dev-lang/squeak | x11-libs/gtk-server | | Squeak and gtk-server maintainers still have time to rescue their | ebuild, just enough time has passed for handling this (one and half | year) Hello, I already have an updated version of the Squeak ebuild with the necessary changes; the problem has been lack of time and of a proper x86 environment to test it. So, if anyone is interested on testing this ebuild, please, send me an email, it'd be a matter of just polishing some details and committing then. In any case, you can keep it masked for now, but I expect to commit this fix today, I can unmask it afterwards. Thanks, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhISUgACgkQNir3WYj9aLrjUQCfUcqq/tmHMovjWsDpJOmad+IU sXsAnA2SD2hncrHJ8ikS/2fs5qN1qI5o =Xvwh -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: About herds and their non-existant use
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tiziano Müller wrote: | Marius Mauch wrote: | | Moving the discussion to -dev per leios request. | | On Wed, 21 May 2008 23:42:19 +0200 | Marius Mauch [EMAIL PROTECTED] wrote: | | As this topic jus came up in #-dev, and most people there seemed to | agree with me I thought it might be worth to bring this topic up | again. The topic is that I think that the whole 'herd' concept we're | using is a huge mess and should be removed. Now before eveyone starts | screaming, lets look at what this concept actually is, as many people | are quite confused by it: | | 1) a herd is a group of packages (not a group of people) | 2) the herds.xml file is used to assign people and mail aliases as | maintainers of a given herd. Unfortuntely the syntax there give | the impression that those people/mail aliases actually form the herd | 3) the herd tag in metadata.xml is used to assign a package to a | certain group. | 4) the maintainer tag in metadata.xml can be used to assign | individual maintainers for a package in addition to/instead of the | herd maintainers | 5) the combination of 2), 3) and 4) is used to determine the | maintainers of a given package | | Now most people will be familiar with 5) to some degree, and that is | actually the only valid use case for the herd concept that I'm aware | of. Or has anyone some use case where you'd like to know what herd a | package belongs to, but don't care about by whom that herd is | maintained? | If we can agree that this is the only real use case for the herd | concept, then I think the concept is quite useless as it's just a | redundant layer of indirection. You could just list mail aliases | directly as maintainers, without having to consult herds.xml first. | While I think the herds concecpt is somewhat useless, I'd rather like to see | something like this instead: | | maintainer | teamfoobar/team | /maintainer | | This makes it clear that it is a team instead of a person (where name | would have been used) | | And the herds.xml isn't completely useless, but I'd rather name it teams.xml | and list the teams there. This way we can validated the team mentioned in | team.../team against the list of available teams and make sure the | complete thing is valid (can be done in the current metadata.dtd or in a | future metadata.xsd). | (If we're gonna re-use the email.../email element for the herd-alias, we | can never validate it. And I'm personally for the: if something can be | automatically validated, it should be) | I am also for renaming or making clear that these are 'teams' instead f 'herds'[0]. Unless a team can maintain several herds, I find the term 'herd' confusing and better understood as 'team' instead. My 2 cents. [0]http://www.gentoo.org/proj/en/metastructure/herds/herds.xml - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkg1HX4ACgkQNir3WYj9aLp6xQCghXkp7wZS4XMjx/xKtinOMzRk xpkAoI9TqpYukYUQZ8FD3HmiyLSFs8W+ =xAMS -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Prioritising contact information in metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ulrich Mueller wrote: | On Thu, 24 Apr 2008, Luis Francisco Araujo wrote: | | | One other thing is that it is sometimes difficult to figure out to | | whom a bug should be assigned, because metadata.xml for many packages | | simply isn't clear. If you list a few developers as well as a herd, | | does that mean you want bugs assigned to the herd or to a single | | developer who happens to be in that list? Some packages list several | | herds in metadata.xml. Bugs can be assigned to just one address | | I'd say that in the case of a herd listed , the bug should be sent | there. | | A common case is a herd plus a specific maintainer, and I think then | it should be assigned to the maintainer, with a CC to the herd's team. | | If it doesn't specify a herd but several developers, sending the bug | to any or all of them should be the rule. | | In this case, it should be assigned to the first developer listed, and | all others in CC. | If this is the case, I think this should be stated somewhere in the docs , since the order of listed maintainers don't have any priority, and I personally would prefer to keep it so. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkgRUVIACgkQNir3WYj9aLoEjQCeIvFaInENgCOhz65K9CaywFa4 C7gAnjjQAT82gerNwWmModYBVEpVHBrF =V6VD -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] What are blocks used for?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: | On Wed, 16 Apr 2008 07:54:48 +0200 | Mateusz A. Mierzwin'ski [EMAIL PROTECTED] wrote: | And I strongly suggest to leave old mechanism of portage, because we | saw couple times what _GREAT_ automatic makes with distro - eg. | Mandriva with all creators and cheap installer - couple apps not | running, low performance. | | Don't get me wrong - I also have that problems, and they make me | nervous, but when I think what could I done by automatic replace | package or binary then I get to thinking that everything is ok... | | I'm not suggesting automatic anything. Here's what I am suggesting. | | Case A, Current Behaviour: User tries to install superfoo. User has | foobar installed. User is presented with a big red blocking message, | with no explanation. User has to work out that he is expected to | uninstall foobar, then install superfoo (which is a problem if superfoo | fails). | | Case A, Suggested New Behaviour: User is instead presented with | something like this: | | [block] app-misc/foobar is blocking app-misc/superfoo. | Explanation: foobar and superfoo both provide /usr/bin/foo | More information: http://www.gentoo.org/blah/blah.xml | [install] app-misc/superfoo | [uninstall] app-misc/foobar | | Error: the above resolution will uninstall 1 package. To accept | this uninstall, use --permit-uninstalls. | | Case B is similar to Case A in resolution, but it's probably nice to | make the distinction. | | Case C, Current Behaviour: User tries to upgrade foo. User is presented | with a big red blocking message saying foo blocks libfoo or libfoo | blocks foo, with no explanation (assuming it's not one of the subset of | issues that can be solved automatically). | | Case C, Suggested New Behaviour: The package manager realises that so | long as both foo and libfoo are upgraded during the same session, | there's no real block, and the block is merely a way of getting around | limitations in collision detection. No block is shown to the user. | | Case D, Current Behaviour: User tries to upgrade coreutils. User gets a | big flashy block error saying coreutils blocks mktemp. User doesn't | realise that the safe upgrade path is to force the package manager to | ignore the block, then manually uninstall mktemp straight afterwards. | User instead uninstalls mktemp, which is a moderately critical binary. | | Case D, Suggested New Behaviour: User is presented with something like | this: | | [block] sys-apps/coreutils is blocking sys-apps/mktemp | Explanation: mktemp is now part of coreutils | More information: http://www.gentoo.org/blah/blah.xml | [upgrade] sys-apps/coreutils | [uninstall] sys-apps/mktemp | Very good idea. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkgFl1AACgkQBCmRZan6aeg9wwCdE0tOEUtinfV5iUyxqQbuKFG5 O1MAoIgUmY5HTLNMgDAaYtgKvm4Me4ru =T31v -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Last rites - dev-lang/smalltalkx
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, a package that probably most of you didn't even know it existed anyway. I am currently masking (just for protocol) this package and will be removing it from portage within 30 days. This is a binary and annoying package introducing many bugs, with barely any updating from upstream in the last years. You can check bug http://bugs.gentoo.org/show_bug.cgi?id=208666 for further info. Thanks, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFH038KBCmRZan6aegRAhw0AJsGGzz4BdIwQELdROjtnwad54E8sQCffNIC gWZHhBNctayTUTUN0YT53ao= =errl -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer: Ricardo Mendoza (ricmm)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: | Hailing from the Venezuela, more precisely Caracas, we have Ricardo | ricmm Mendoza. When he's not fighting in the jungles, he likes to play | around with those expensive paper weights that some people call mips | computers. Luckily for him he will be soon moving to the comfort of | Europe. Now it's time to release all that anguish on ricardo (yes jakub, | I mean you) and bash him into a keywording spree: | http://tinyurl.com/2acoqd | | Regards, | Petteri | Bienvenido Ricardo! , it's always good to increase our south-america conspiracy around here ... even if it is for mips :-] Regards and Welcome! - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFH0JlWBCmRZan6aegRAt7uAKDK3qVEFXrajm+uZ5SPEPW3IPhBfgCgqACC pT+0y5OKydA3/0duYu6Yabo= =/acc -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] The future of ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Felipe Contreras wrote: | On Sat, Feb 23, 2008 at 10:45 PM, Alec Warner [EMAIL PROTECTED] wrote: | On 2/20/08, Felipe Contreras [EMAIL PROTECTED] wrote: |b) Error are difficult to handle since bash doesn't have exceptions | | I disagree here: most errors are fatal anyway any non fatal errors can | be printed and saved via the elog facility. | | Yes, for the most common usage that's true, but that think about this | example: I'm compiling gstreamer-plugins-good, which needs libraw1394, | but the compilation fails, perhaps that user is not interested in that | particular plugin so a dialog can pop up and the user can choose if to | continue without the libraw stuff or fail. | | I'm sure that can be done without exceptions but as the complexity | increases properly checking/passing around error values/messages | becomes tedious. | That's what USE flags are for. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHwbyIBCmRZan6aegRArK/AJ9wBvqPZ9PErpxiVHgpkSLuCZIixQCdGiEB wvdMli4taTHJFVBoHYIzyLs= =/1k7 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Projects and subproject status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, A brief summary about the Gentoo GUIs project: 1 - Markus (jokey) recently released a new version of Maintainer-Helper. It already has the basic operations running and some people are working in a Gtk+ port. http://dev.gentoo.org/~jokey/maintainer-helper 2 - Donnie (dberkholz) is currently working on a pkgcore back-end for packagekit. This will allow to easily connect graphical interfaces to this package manager. Contact him for further information. http://www.pkgcore.org http://www.packagekit.org 3 - Me (araujo) released a new version of Himerge. It has some bug fixes and a few new operations added. Check the Changelog or web-site. http://www.haskell.org/himerge We also expect to upload a few screen-shots of these projects somewhere in the coming days; for further details about any progress, please check #gentoo-guis or the gentoo-guis mailing list. Thanks - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHjPUcBCmRZan6aegRAt1UAKDcmGHQY2FSEp1w9dqpkXgOHoKtGACgoAA+ rQVum/VrWiz7dQ1QXZeAUkE= =SKGW -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] eselect_zenity: alpha eselect GUI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: Hey all, I've been wanting a GUI for eselect lately, so tonight I hacked up the start of one called eselect_zenity [1]. It only works for the most trivial modules so far -- it has to parse eselect output, so special parsers need to be written for each type. eselect_zenity uses (surprise!) Zenity, a shell-scripting interface to GTK+. I'd appreciate any patches you'd like to contribute to add functionality or fix bugs. Thanks, Donnie 1. http://dev.gentoo.org/~dberkholz/eselect_zenity/ Nice work, you should announce it too at the gentoo-guis ml. :-) Regards, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHMyVKBCmRZan6aegRAq51AKDGK606Kms7RR06mR0uGD95NtEvRgCeL+Rk UX948bV08q/nN5ryBVt8dlg= =XVMM -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Gentoo Graphical User Interfaces Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin Gramlich wrote: From what I can tell the goal is to make GUIs to programs like equery, rc-update, eclean, etc., right? Is there a formal design process here, or could we all just take a stab at it? Ciao, bg Yes, plus any other program that can benefit Gentoo systems (for example to edit configuration files). The project is just starting, so, i guess we will just keep stabbing for now and getting a proper formal process on the way :-) The best way to cooperate so far is subscribing to the [EMAIL PROTECTED] list and joining us at #gentoo-guis in any case. Thanks and Regards, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG3zdOBCmRZan6aegRAvLCAKDIq5E2PDcsO8FoI8CMU/bCF7ubZQCgsTQp 6Z4rFsJVK58MQkNM7OZpGJY= =0yJ/ -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Gentoo Graphical User Interfaces Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: On 04:53 Mon 03 Sep , Luis Francisco Araujo wrote: Our main idea is to develop and collect all the necessary applications to offer GUI's (keeping Gentoo flexibility) for most of our system tasks, offering an alternative for those users who like these kind of interfaces. Please keep in mind all the GUI apps I added in app-admin/system-config-* some time ago, so you don't need to duplicate them. Thanks, Donnie Of course, Thanks - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG3SQSBCmRZan6aegRAoHWAJ9RHlqGheCyCjcoYbL7ORaaOC0xNQCgkyDD 3R635k5n6bxDBx6ZUr3f5lE= =aO4C -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Gentoo Graphical User Interfaces Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, A group of our developers and i have felt the need of working around a new goal inside Gentoo: Graphical User Interfaces (GUI). Though Gentoo has been considered a very command line interface oriented system; we believe there is always room for new 'ways' of doing things in this distribution that helps our users to have a better Gentoo experience. Our main idea is to develop and collect all the necessary applications to offer GUI's (keeping Gentoo flexibility) for most of our system tasks, offering an alternative for those users who like these kind of interfaces. So we have started the Gentoo-GUI's project to work around the goal of making Gentoo more 'GUIzed' :-) Please visit the site http://www.gentoo.org/proj/en/guis/ for further information. Note that we are just in the early stage of the project right now, but anybody is welcome to participate on what we currently have so far. Thanks and Regards, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG28tsBCmRZan6aegRAtQrAJ9xjymmw49BQNezznjbzg/hdJW1TQCgjBRO HSeHAahhPehzecaxPzOKx3Y= =+CBK -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Gentoo Graphical User Interfaces Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Mauch wrote: You should rename 'himerge' to YAPG (yet another portage GUI). Is there a particular reason why you couldn't reuse one of the already established ones (kuroo, porthole, portato, ...)? Marius himerge is not really new ; it's been around for a good while now. Its name stands for 'Haskell Interface for Emerge' ; plus i think some of those GUI's you are mentioning didn't exist when i started himerge or they don't offer all that himerge does. Thanks and Regards, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG3EulBCmRZan6aegRArZoAKCqkoHpQJAEDlyAyBwOeW3riiSdLgCffFk4 GZFl2BIO6AJQlbdnPoR9N3E= =hx/D -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Porting app-portage/maintainer-helper to GTK+
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Faulhammer wrote: Hi, Maybe some of you have already seen app-portage/maintainer-helper from Jokey. It is written for Qt, but I was just happy to replace the last Qt app with something agnostic/GTK+ based on my system. Unluckily I have no real idea about GTK+ and it would be nice, if someone could help Jokey to port it to GTK+. URL:http://dev.gentoo.org/~jokey/screenies/mhelper-versionbump.png URL:http://dev.gentoo.org/~jokey/screenies/mhelper.png V-Li Count me in! o/ - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) iD8DBQFGwzMuBCmRZan6aegRApAWAKC8abj3Ny2ChmyOZuwJyzbo1JmpOQCgxkuW hnHsKhPYY7AjYWqlliwaAoo= =YKBN -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: More and more, I am finding developers who are afraid to touch packages for even minor things if they're not the maintainer. This is a sad state of affairs and not the reason we have maintainers. We have maintainers to assure that a package is being taken care of, not to establish some kind of territory over that package. Because of this misconception, I would like to come up with and document a listing of things that any ebuild developer can feel free to do to any package *without* maintainer consent. These are generally all minor things, but things that I think are important. I'm going to list off the things that I can think of, and encourage everyone else to speak up if I've missed something. - HOMEPAGE changes - LICENSE changes - arch-specific patches/dependencies - If someone is requesting KEYWORD changes on a package and it requires a patch or additional dependencies for your architecture, you are not only permitted, but really are required to make the necessary changes to add support for your architecture. I am not sure about this last one ... what if for example this patch is only for supporting a special option of the package for that architecture, but the maintainer of the package found out that such a patch is unnecessary and/or will cause other kind of problems in the package, therefore preferring avoiding such a patch ... or he just wouldn't like to apply the patch for X or Y; or even further, he just wouldn't like to have such a package available for that architecture just yet for Z or W. - Typo fixes - SRC_URI changes - If the source has moved, feel free to fix it. We shouldn't have to wait on the maintainer to fix something this simple. - *DEPEND changes due to changes in your packages - If a package that you maintain moves, splits, or otherwise changes in a manner that requires dependency changes on any other packages in the tree, you should make those changes yourself. You're free to ask for assistance, of course, but you have the power to make the changes yourself without asking permission. After all, you're the one breaking the package, so you should be the one to fix it. - Manifest/digest fixes - metadata.xml changes There's a couple more that I wouldn't mind seeing as things developers can do without the maintainer, but I can see how these might be a bit more controversial, so I'm asking for input. - Version bumps where the only requirement is to cp the ebuild - (for arch teams) Stabilization of new revisions of an already stable package - An example of this would be being able to stabilize foo-1.0-r2 if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is stable. I think these two cases should still be handled by the herd or maintainer of the package. The stabilization idea sounds good and it could free maintainers from filing similar bugs over and over ; but wouldn't this be more and harder work for arch teams?. For example, they should carefully track the history of all the packages to know when and if they should stabilize it yet. So, what do you guys think? The other list of things look fine and safe to be changed by any maintainer. Regards, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) iD8DBQFGs9KfBCmRZan6aegRAtK7AJ94CDovLQu51QmZy6TW69rMK4Tz1QCgm3C9 tKDsHyNAWsliFCx0MMzcIpA= =RGhM -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Nominations open for the Gentoo Council 2007/08
Kumba wrote: Ryan Hill wrote: Torsten Veller wrote: | for the quick low down: | - nominations are from July 1 through July 31 | - anyone can nominate | - only Gentoo devs may be nominated | | so get with the nominating people ! I noticed Kumba isn't nominated, so I'll throw him into the ring. I'll decline for this year; I'm content to hide over in MIPS land and toss out random ideas from behind the safe shadows of an Origin 2000 cluster... Thanks for the nomination, though! --Kumba Admit it, you just wii all the time. :-) -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: New developer: Pierre-Yves Rofes (p-y)
Steve Long wrote: Petteri Räty wrote: It's a joint pleasure for me and diox to introduce to you Pierre-Yves py Rofes. Instead of the snake people he will be joining our security team. Py originates from Paris, France, and has just finished his studies in computer science. He'll be hired soon (or maybe already was?) as a security network engineer for a small consulting company. YAY! aiui there's only 4 or 5 people in the security team, so well done for getting another sucker^H^H^H volunteer, Tavis. Can you please stop sending these kind of harmful emails? Thanks, -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New developer: Santiago M. Mola (coldwind)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Denis Dupeyron wrote: Please everybody welcome our new developer Santiago M. Mola, aka coldwind. He is joining us from Alicante, Spain and is studying Computer Science in Valencia. His main interests are hanging out with friends at obscure pubs, music and reading. I am told he has extensive experience with such games^H^H^H^H^Hsimulation software as Gate88, Parsec47 and BomberClone. He will start with working on VOIP stuff, so please give him a warm welcome. Denis. Bienvenido Santiago! One more developer from our #gentoo-es conspiracy! - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGgdQCaTNpke9pJcURAi9lAJ9RPX0LO3tM8pvmaNG1+IkHiLtVyQCfeMfP 3Ww1JItHswsslMEW8nG+Bbw= =JSVm -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Determining ebuild stability and the 30 day suggestion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mart Raudsepp wrote: Hey, On E, 2007-06-18 at 11:34 -0700, Chris Gianelloni wrote: Also, remember that stabilization is *supposed* to be about the stabilization of the *ebuild* and not the *package* itself. This sentence made me personally start looking at the policy in a different way as far as stabilization and waiting for a set amount of days is concerned. Does this mean that, when for example there are pure bug fix releases in GNOME packages with no ebuild changes whatsoever, then we can consider, without hesitation so much, to ask stabilization of these much sooner than 30 days? Or the new version just has updated translations, which is cool too (unless it's a very long building package) to get into the hands of our world-wide users earlier with no practical chance of breakage. Right now it is a rare exception to ask stabilization earlier than 30 days, but should we do that more often for cases like I made an example of (upstream following a strict bug-fixes/translations only rule as well for the versions in question)? I use to ask for stabilization of the new version of a package immediately if it is supposed to fix an *important* security problem in the package, so that way we spread as soon as possible the new fix to our users. Not sure if this is documented somewhere as an exception to the 30 days rule, but i have not had problems so far and the stabilization teams have been willing to help me in such a cases. Regards, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGd15QaTNpke9pJcURAiIeAJ9IP9To0xwSU86eWyjOO+N6WQCQjwCeIXxG +wFGE1phct8Dtzg/0P33+Dk= =tcgj -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] multiple compile-install phases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 George Shapovalov wrote: Sunday, 17. June 2007, Marijn Schouten (hkBst) Ви написали: I've encountered a few cases where the build process requires building and installing something and then using that to build something else. Is there a standard way to do this? I'd say - split the package in two (or how many pieces there are). Such procedure implies that the parts are already well isolated, so the split should not be that hard to do. Trying to force it in one go is not trivial usually, unless what you are talking about is some bootstrap procedure. However in that case there should be a certain way of proper bootstrapping for the package described in its install docs. George Splitting the package is a good idea indeed. If it is needed a bootstrapping , you could build a binary version of the necessary components of the package, that's what we do with ghc and many of the languages packages inside dev-lang. Regards, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGdbYfaTNpke9pJcURAmm6AKCMZQZC6tvFbgHu9dUb0c8ahpQfIgCgiLMU YnKpHz22OvjdyYLlF8l7+9k= =99fq -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 cilly wrote: On Jun 12, 2007, at 12:46 PM, Fernando J. Pereda wrote: Known to be buggy versions. Of course, there are bugs in every version. Sometimes a user must be able to choose which bug is more problematic, i.e. the bug in the newer ebuild which makes the package unusable for them or the older bug which has a security issue the users are aware of but not present, i.e. prevented by firewall. A timeline of two weeks would allow the user to easily downgrade and if necessary put the ebuild in overlay. Hello, We (developers) won't immediately remove old packages versions if there is no a good reason for it, at least in my case. One of the main motivation for fast removal are security concerns, they sometimes happen and they don't even get into our bugzilla database , but the maintainer of the package is aware of it from upstream reports, so these might be unknown problems for our users. Best recommendation is that you trust the package maintainer and report bugs in the new packages if you find them. Regards, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGbsQ8aTNpke9pJcURAugPAJ9MuOmIFMzNNAx7DqKCm/ZuxLj5mACfcOf/ W3oxNo4aXWZLGlT9D5HblQ4= =GLS5 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC]: gentoo-politics ML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kumba wrote: So I'm told debian has one of these types of MLs, probably where the flames burn bright enough to have earned a star designation from the IAU. Given what's been going on lately, and with calls from myself and others (i.e., mcummings) to get back on track and actually like, you know, develop something, I think it's high time we create this list ourselves. Anyways, thoughts? --Kumba I like the idea. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGZ6p3aTNpke9pJcURAkiEAJ0YK3dO0h4182ZHLN91NTK8YiKzBACfbdji XYxB8IyKtqcvjMA+jIJxp3Q= =X3lK -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Bye Gentoo!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bryan Østergaard wrote: It's with a bit of sadness but also a bit of relief that I'm finally retiring from Gentoo. I've been a Gentoo developer for nearly 4 years now and I like to at least pretend that I've made some important contributions to Gentoo during that time. I've had a lot of fun but my frustrations have grown these past several months and I've been entertaining the idea about retiring from Gentoo for probably 6 months now. The past couple months the desire to leave Gentoo have become much stronger and I think it's finally time for me and Gentoo to go our separate ways. I think I've put my fingerprint on Gentoo in quite a few important ways but lately I've come to the realization that I probably can't do any more for Gentoo. No matter how hard I try fighting for what I feel is right we seem to end up with petty fights, flamewars or what I consider even worse - people simply ignore what I'm working hard towards. So I think it's high time that I leave the project and start looking for another project where I can contribute something important and not just try to keep afloat in a project that I seem to be at odds with to an ever increasing degree. I'll try to reach all the projects I'm leaving over the next few days and see if I can pass on my work in a reasonable manner. I probably won't be around much on irc but if you really need to contact me you can do so at [EMAIL PROTECTED] Good luck to all of you and may Gentoo development be as much fun for you as it used to be for me. Best regards, Bryan Østergaard Sad to see you go Bryan, You were one of the first Gentoo developers i met, and you were really a great help to get me started in this community; i bet many people owe you the same Thanks and i wish you luck in your future projects, P.S: Wouldn't you just like to take the Gentoo-one-month-off vacation to relax a bit? - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGXiiVaTNpke9pJcURAifyAJ9w7SqqRxk1a6WLOV0bKXwx7N74TQCfV7fV vBb/0K7ygzOjWcPzejSdY8E= =cdel -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Increasing contributions and interest via personal project aggregation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: Hi all, I'm sure I'm not the only one with a number of projects I'll never get to, but I'd really like them to happen anyway. I suggest we create some sort of page that aggregates all of these personal projects together, so anyone can browse through them and look for stuff that sounds fun. The goal is to increase contributions from outside by giving them a ready list of projects of all sizes and difficulty levels to work on, projects that go beyond what happens at Bugday. Further, it could also help current Gentoo developers who are bored or have lost interest in what they're doing by helping them to find somewhere new to contribute. A prototype with just my projects is at http://dev.gentoo.org/~dberkholz/proj/ Thanks for your comments! Donnie Nice idea. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) iD8DBQFGQjXzaTNpke9pJcURAiQ+AJ4rwnb1Dt0bWZC4hNCkIQuDEuEDtQCfcbjt NsZoRjf4rPrPTAtAKqHHtH0= =Dn/b -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Hardened USE flag
Mike Frysinger wrote: On Monday 05 February 2007, Luis Francisco Araujo wrote: I am usually very hesitant to add new use flags to the tree (unless they are *really* necessary or imply a great advantage.) ; though i am not sure here if anybody else would consider this a good recommendation for handling textrels. why not just build pic for everyone on x86 ? define it'll hurt performance ... of course you take a small penalty for code being PIC, but i dont exactly see smalltalk being such a performance hardcore language to justify making it special I was thinking more of a simple 'use hardened myconf= .. ' specific line for this ebuild; but it's probably a good idea offering to more developers the easy choice of this feature through a USE flag? you would utilize the pic USE flag ... php does this because it, unlike smalltalk, is very performance critical, and so by default it builds as non-pic on x86 -mike Thank everyone; I will go with the pic USE flag option then. -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Hardened USE flag
Hello World! I want to ask for suggestions and opinions for the best way to handle this bug: http://bugs.gentoo.org/show_bug.cgi?id=158434 I am usually very hesitant to add new use flags to the tree (unless they are *really* necessary or imply a great advantage.) ; though i am not sure here if anybody else would consider this a good recommendation for handling textrels. I was thinking more of a simple 'use hardened myconf= .. ' specific line for this ebuild; but it's probably a good idea offering to more developers the easy choice of this feature through a USE flag? If it looks enough useful for many people; then i think we can proceed to implement it; if it will only be used by this ebuild; then i am already against it ;-) Thanks; -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Test
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Test .. ignore - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFSSYTaTNpke9pJcURAgjUAJ4vqegitzaO6Kk5b9Zwm53WwTcm6ACfX/fz EoLOlEtCHk0RkUSEaG5lfIY= =aw+F -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Is there a tool to manage USE flags? (use-config?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 m h wrote: Other than a text editor? I'd like to have a tool that can add USE flags on a per package or global level. (I'm doing this in some build scripts and would prefer just to have a tool, rather than sed or some other shell hackery). I couldn't find anything via a quick search on google. Here's my interface: use-config --add --component sys-devel/gcc --flag fortran (adds the fortran USE flag to package.use for gcc) A --remove would remove the fortran USE flag, and --unset would put -fortran instead. A --global would update make.conf instead of package.use. Make sense? Are there other features that people would want? Unless this already exists, I'll probably create a tool for this. -matt Hello there, I have been developing a GUI portage interface in my free time since the beginning of the year, called [1]Himerge, that includes a use flag editor [2](UFED GUI) , which allows you to do this kind of things very easily (or at least it should :-). I still don't even release a tarball for it, so you will have to get it with darcs if you want to try it out. Suggestions and criticisms welcome. Regards, [1] http://www.arjox.org/himerge.html [2] http://www.arjox.org/screenshots/himergeflags.jpg NOTE: This is a personal project, not a Gentoo one. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFQW4yaTNpke9pJcURAqixAJ9IMvA/8bZVSIkO1qNyTTJlFNTzNACfb5+a UKmUaqDHa0YhmNH+7urqVfU= =dmbM -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Gentoo Commitfests
Luca Barbato wrote: Ciaran McCreesh wrote: It's offering incentives to get as many commits as possible. The easiest way to get as many commits as possible is to go on a mass keywording or stabling spree. It'd be very easy for someone to do a Manson -- do you really think no-one would? Even if no-one does take it to that extreme, it's offering a reward for people who commit two things rather than doing QA and committing on one thing. fixing the mess left by others (given we could commit slightly off stuff in 8 hours) is a pretty equivalent way to raise the commits level. Anyway I'd slow down mirror propagation a bit the first times in order to mitigate the issue pointed by Ciaranm. lu Though it seemed to me like a fun idea, i also thought the QA of the tree could be in danger when i read it. -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo World Domination. a 10 step guide (Proxy-dev)
Chris Gianelloni wrote: On Wed, 2006-10-04 at 13:20 -0400, Caleb Tennis wrote: With the increase in developer and project overlays, I see the possibility for reducing work needed to maintain many packages. As Natanael Copa, it would be nice for him to be able to maintain packages without having CVS access. The idea of formalizing and promoting proxy developers has come up a few times before, and I think it is a great idea. Work is done in the overlays, tested, improved, then committed into the main tree once the kinks have been worked out. We get a stronger core tree with fewer developers and a better interaction with the community. http://article.gmane.org/gmane.linux.gentoo.devel/40744 I am still willing to cooperate with this project idea if there exist enough interest in our users and devels base. -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] (Not so) New Developer - The Paya
John Mylchreest wrote: Hi Guys, I've been very slack about announcing some of our new guys recently, and not least Javier Villavicencio. Javier, known on IRC as The_Paya, joined us to work on all aspects Gentoo/FreeBSD plus anything else he can throw his skills at! Coming from Argentina he has an interest in fishing, high end hardware and playing with imaging apps. Javier has also done a great job of infiltrating yet another company with production servers running Gentoo :) I'm sure I'm not the only one to throw thank-you's and welcome him on board! Here's to a long and enjoyable involvement with Gentoo! Bienvenido! The south-america conspiracy is growing up! -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Democracy: No silver bullet
Richard Fish wrote: On 9/2/06, Wiktor Wandachowicz [EMAIL PROTECTED] wrote: I suppose that there is a way that Gentoo can follow, only that its leaders, developers and users need to see it clearly. Is there a publicly visible page that contains current goals for new releases? Where all sub-project leaders could add their own goals, coherent with the general vision? I couldn't find it, but maybe I haven't looked in the right places? The problem I see is that for Gentoo the releases are not really useful milestones for most projects. A release is really significant for a few core packages, but what is the real downside for users if Xorg 7.2 is stabilized one week after a release? Outside of the fact that they have to compile it themselves instead of using the GRP package...not much that I see. That is not a problem. That is a feature. -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: The Age of the Universe
Wiktor Wandachowicz wrote: Simon Stelling wrote: Edgar Hucek wrote: I know my tools but not necessarly the normal user who wanna use gentoo and is ending frustrated. If the users are too lazy to read the documentation, why should we care about them? Because we risk that Gentoo may receive the user-UN-friendly label and become irrelevant in the long run? I know it ain't gonna happen, but still. Both Edgar and you have some valid points. He refers mostly to the out-of-box experience, which includes compiling GNOME and its dependencies at the install time. With USE=accessibility enabled, which makes perfect sense for people with disabilities. And then the first-ever Gentoo installation breaks on the speech-tools and festival. How would *you* feel in such case? You OTOH bring to the table a fact that developers shouldn't be that much concerned with the stabilization/testing of packages before new release of installation media. But new releases *ARE* targeted specifically at new users and it's them who suffer the most. Next to it is the reputation of Gentoo and its developers. Edgar's call was targeted mostly at releng and QA teams, who should poke developers to decrease number of similar problems. I maintain a bunch of Debian/sparc, Debian/i386, Gentoo/amd64, Gentoo/x86, Solaris/sparc, Ubuntu/i686 boxes and mind you, out-of-box experience at install time means A LOT. More respect to the users = more respect to Gentoo. Let's see... Several points (misunderstandings) need to be clarified. 1) Gentoo is not intended to be an out-of-the-box distro, but instead, a customizable distro. Can see the difference?.. There are many, one of them is that users should 'make' the process of using Gentoo _friendly_ partially by themselves through reading documentation and tutorial when needed (and sometimes going through a list of bugs to know what it is going on). 2) Gentoo releases are very.touppercase different to most of the other distros. Gentoo releases are mainly intended to be used as a tool to get you started building your _own_ system in an automatic way through scripts/metadata, this being very different to other distros, where they simply force you to use version 6.6.6 as a bunch of dead packages that won't likely suffer any major changes within the next 6 months until upgrading (which can be a very painful process) to the next 6.6.7 release. This is precisely why i say Gentoo is an incremental meta-distro. 3) Considering the two points above, i therefore think , there is no point (and actually makes no sense) to bitch at our releng team (which did a great job) because two packages don't currently compile. 4) Gentoo is more a community than anything else. So we indeed all deserve respect. Some developers put into this project (the releng team being one of them) a lot of effort, so making comments like this thread might be very insulting for many people; apart of making false claims that could lead to a bunch of misconceptions. Now who is being disrespectful? If neither of those points are convincing enough, then remember free software comes with *NO-WARRANTY* Thanks, My 0.2bs -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Xmms needs to die.
Alec Warner wrote: Paul de Vrieze wrote: On Thursday 24 August 2006 20:46, Alec Warner wrote: Robert Cernansky wrote: What bothers me also, is that it has not plugin design like xmms. Support for plugins is very good because lot of people can write plugins for lot of things. This is why people do not want to switch from xmms because thanks to plugins it have so many features that currently no player is able to overcome it. So port the plugins from xmms to $NEW_CLIENT, since xmms is an old piece of crap. Who cares. It works (mostly), it is lightweight, and there are enough people using it to keep it in the tree. As long as things don't break beyond repair I see no reason whatsoever to remove xmms (or any other largely unmaintained package in the tree). Paul This is one of those things (along with qa and security) that the community needs to decide. Does stuff that works but has terrible qa stay in the tree? Does security stuff stay in the tree, but masked? Should xmms be masked? We have no real way of deprecating a package, aside from leaving it in the tree with a masking reason saying deprecated and unsupported. at which point not everything in the tree becomes supported. The Treecleaner project that I run is based on the assumption that broken stuff in the tree is bad, and I try to remove the really old stuf broken stuff first. However I aspire to eventually catch up and get to the currently broken packages. So which way will you have it? Or is this more of a pragmatic stance on the tree? Broken stuff but still maintained upstream, mask it. Broken stuff and unmaintained upstream , send it to the overlay (probably with a note warning about it on the ebuild?). I would opt for that. So, about the xmms ebuild, i agree with sending it to the overlay. -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
Lance Albertson wrote: I thought of that while I was walking to a meeting..heh Basically, Appoint two people to co-lead, or appoint one Lead and one Vice Lead. That way there's some kind of accountability on the bare minimum level and good coverage (hopefully). I was also thinking about turning the Council into a Leaders Group , or probably to create a new Core Team. Difference being that they would be empowered to take decisions; mainly technical ones. I already can hear some of you worried with questions like You mean, to have people with no clue of $add-you-favorite-team-here to take decisions about $add-you-favorite-subject-here?. Well, first at all, we need to understand and moreover, accept something. If we want to bring real and important changes to the way Gentoo works, we will also need to assume 'real' and important risks. I think that we all pretty much know this, but we are scared of facing this reality and therefore we have incurred to just get a more passive body and 'try' to assume we have already addressed the issue with the Council (nothing against you guys, it is just that the body isn't designed for this). So, now straight to the point, we could elect a Core Team , including people from each team. And those will be the responsible to take Gentoo into new 'realms' , with its 'risks' included. I am also scared about this model .. it might not work , it actually might create the next armageddon for many. But what if it does? , it might help solving this stagnation state Gentoo is facing right now, and bring more new ideas into play. i would give it a chance because my friend, it is the only way to solve the issue. I personally see the Council as a very passive democratic body, which might be good at times; but not always. It is not definitely good for taking new changes and innovations into our community. Something like that anecdote of a tribe invading an island.. after they landed on it, the captain ordered to burn all of the ships.. his soldiers asked him why? .. he said there was only two ways of ending the battle ... death .. or conquering the island. This .. or let's keep running away forever. My two Bs. cents. PS: This was just a general idea. If you are interested about it, let's discuss its implementations details in a constructive way instead of flames about its already possible details. -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
Marius Mauch wrote: On Thu, 24 Aug 2006 12:53:32 -0400 Luis Francisco Araujo [EMAIL PROTECTED] wrote: Lance Albertson wrote: I thought of that while I was walking to a meeting..heh Basically, Appoint two people to co-lead, or appoint one Lead and one Vice Lead. That way there's some kind of accountability on the bare minimum level and good coverage (hopefully). I was also thinking about turning the Council into a Leaders Group , or probably to create a new Core Team. [snip] Before everyone start posting solutions please *clearly* define the perceived problem first, otherwise all attempts to fix it are futile. Gentoo current state of stagnation. (re-read some posting of this thread, the first one made by Donnie mainly) PS: is it really already time again for the annual Gentoo restructuring debate? That's what happens when you 'try' to evade the real problems. They will get back, stronger than ever every time. -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
Marius Mauch wrote: On Thu, 24 Aug 2006 14:15:18 -0400 Luis Francisco Araujo [EMAIL PROTECTED] wrote: Marius Mauch wrote: On Thu, 24 Aug 2006 12:53:32 -0400 Luis Francisco Araujo [EMAIL PROTECTED] wrote: Lance Albertson wrote: I thought of that while I was walking to a meeting..heh Basically, Appoint two people to co-lead, or appoint one Lead and one Vice Lead. That way there's some kind of accountability on the bare minimum level and good coverage (hopefully). I was also thinking about turning the Council into a Leaders Group , or probably to create a new Core Team. [snip] Before everyone start posting solutions please *clearly* define the perceived problem first, otherwise all attempts to fix it are futile. Gentoo current state of stagnation. (re-read some posting of this thread, the first one made by Donnie mainly) That's about as vague as you can get. Marius http://marc.theaimsgroup.com/?l=gentoo-devm=115637880223243w=2 *sighs* -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] General info
sHadoW MaN wrote: Hi I am never has programmed on Linux but I looked on the net about hardware interrupts library I wanted to make a program as Fdisk using C++ ( I have kdevelop installed) Is there a web site who has all general I/O headers Any idea please This list is for specific gentoo development, not this kind of questions. -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Gentoo's Social Contract Bugzilla
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lance Albertson wrote: Peter Gordon wrote: Matthew Marlowe wrote: If we could get a license donated, my vote would be to switch to Atlassian Jira, http://www.atlassian.com/software/jira. It seems to be gaining mindshare rather quickly, and the company I work for just shelled out $2,400 because they liked it so much more than RT/Bugzilla. I believe it supports multiple DB backends, including all the usual suspects. Maybe it's just me, but I think that having such a core component of the distribution be proprietary is in complete violation of Gentoo's Social Contract[1] (if not the letter of it, then its spirit of openness). It states: Gentoo will never never depend upon a piece of software or metadata unless it conforms to the GNU General Public License, the GNU Lesser General Public License, the Creative Commons - Attribution/Share Alike or some other license approved by the Open Source Initiative (OSI). Isn't this one of the driving reasons why our forums run phpBB instead of something like vBulletin, for example? :) [1] http://www.gentoo.org/main/en/contract.xml I'm not entirely sure if this is directed towards the supporting web applications or of Gentoo itself. To me its directed towards the meta distribution and not any of the underlying support mechanisms of Gentoo. If we were to use some non-gpl webapp, the underlying Gentoo system you run does not depend on a non-gpl piece of software. A bug tracking system is not an underlying component of Gentoo. Its just a tool that helps with development of Gentoo. But anyways, some people view it in the strict sense and they're entitled to it. That's just how I view it when I read it. Its a bit vague on what Gentoo really is. Is it talking only about the meta distribution? Or that plus the underlying supporting systems that help run Gentoo? I think it is perfectly valid we use this kind of tools for development; as far as i know, our SC refers to those components (in form of software and metadata) to be free software upon which a user depend to build a Gentoo system, and this isn't one of those components. Though i admit it might bring some kind of 'controversy' . /me remenbers bitkeeper - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE1ESYdZ42PGEF17URApflAKCAkBVcgD5hgS0ASFyNXz3wS1Mx5ACg6Tov IjDaN+ENPP1t9nckRAsf2ZA= =6fxU -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruno wrote: Through proxy-dev I may contribute ebuild for a few packages and maintain them over the time period I have use for them. E.g. drivers as long as I have given hardware (in use). That is great! What would be useful is to have the option for a few users to maintain the same ebuild through one proxy-dev, this way when one user stops having usecase for the ebuild others can continue maintainership. Even maintaining while initial user lacks of time or is away would then not stop or fallback to the dev. I think this perfectly could be done,since it is going to be like a team, many users could help with one single ebuild. Thanks for your suggestions! - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEy+LYdZ42PGEF17URAgVUAJ98u6T8OLhwruQyysZPMZAqdkBdYwCeK8ZB 0t5NqlzI3f2FsOMB/D7EEc8= =b1yA -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Hill wrote: So far the only difference between this and doing a query on b.g.o for maintainer-wanted is that it's on mailing list. Which (as a side note), increase the flow of communication between developers and users, giving an alternative bugzilla. Here it comes the trick or 'trap' ;-) The user _has_ to compromise to take care of those previous commented three points that some of us might be afraid of, besides of giving us a centralized way of keeping informed about new ebuilds. _Has_ to? How do we enforce that? Nobody forces anybody here to do anything. In the same way we (by ourselves) compromise as developer to cooperate with Gentoo , we also need the same degree of compromise from the users. That simple. This is a project for people who wants to cooperate under these requirements. The users will need to read the guidelines of the project (when posted), and all these points would be explained as better as possible, so he/she might know what kind of work they need to do inside the proxy project. So basically, the user does all the work in exchange for the ebuild being in portage. Once it's in they disappear off the face of the earth. I still don't see how this is any different than the status quo. Please (re^10e)-read the point 4. (the most important one by the way) This evidently brings some developers responsibilities too, we will need to review, and test the ebuilds. we sometimes will have to check with upstream, and comment on the ebuild, or fixing some details. But it should be a far minimimal effort than the developer taking care of the package(s) by his own, in the better of the cases, he even shouldn't do anything but to test, review and commit, from there on, the ebuild will be under the standard procedures of maintenance (arch testing to stabilize, bug reports to notify problems, etc). The developer should also take care of any internal developer communication if needed. Right, just like now. Not for those packages we fully maintain. I don't think it's necessary to formalize it. If you find a user who wants to help then great. Go ahead. You're free to define whatever relationships that work for you. It doesn't have to be officially stamped and sealed, it's just everyday social interaction. --de. It is organizing more than formalizing. I actually can see it might help to spread the word about this technique that many of us have been using for quite a time now. And even if we gain only one more user interested to help with this, i think it is worthy. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEy+YAdZ42PGEF17URAkhrAKDe7BNWY1yhOJibXoNBMu4ZbJYZqwCfZ32Q 2nKjQcISUdErK0jx7cVs5U0= =Y8YL -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Schweizer wrote: Luis Francisco Araujo wrote: 3 - Users ask on this mailing list if there exist any developer interested to include X, or Y ebuild into the tree. (Probably we could create a template for this?) The user should send the ebuild changes together with the mail. Make it look like on LKML including diffstat and the actual diff. This way you can quote and give review comments on the mailing list - visible for everyone. Of course diffing needs a good script so that the user does not have to generate the diff and the stat manually You mean, when the user initially submit the request to the mailing list? , or this one should always be used for the maintenance of the package? The user _has_ to compromise to take care of those previous commented three points that some of us might be afraid of, besides of giving us a centralized way of keeping informed about new ebuilds. The users explicitly compromise to (just to make it clear)[1,2,3,4]: How are we going to reach this? Currently the bugs for ebuilds which have both developer and user in metadata get assigned to the developer and then the developer puts the user on CC. The proposed solution is to put in metadata: maintainer-needed as herd and the user as maintainer. Thus the user can take care of the package but when he leaves or is unavailable it is still considered maintainer-neeeded which means that every developer can take it over or fix bugs. In my opinion it does not matter which developer reviews a specific version bug for a package - so the developer should not be noted in metadata.xml. Of course developers can personally commit themselves to take care of the package and add themselves to metadata too. Well, my idea is more focused on getting closer the developer with the user, in the sense that they would be like a team (as i already said) , where the developer is the official figure in the group. So, at some degree, it does matter who is the proxy-developer in this case. The main idea is that he _indeed_ would be maintaining the package from a Gentoo perspective, and that is where the user will need to compromise with the developer. We could even create a new herd (proxy), so we can differentiate between these ebuilds inside maintainer-needed and those under the control of a specific proxy developer. This idea is heavily based on 'trust' and 'constant' communication between the user and the developer. And that is the way we can get the 'isolation' effect i commented earlier on. This evidently brings some developers responsibilities too, we will need to review, and test the ebuilds. we sometimes will have to check with upstream, and comment on the ebuild, or fixing some details. But it should be a far minimimal effort than the developer taking care of the package(s) by his own, in the better of the cases, he even shouldn't do anything but to test, review and commit, from there on, the ebuild will be under the standard procedures of maintenance (arch testing to stabilize, bug reports to notify problems, etc). The developer should also take care of any internal developer communication if needed. internal developer communication turns out to be CCing arches on stable bugs. Giving ok to stabilize some new version. This should be done by the maintaining user since he knows the package best. What exactly do you mean with internal developer communication? - Stefan Many things, for example, if one of the package affects other(s) herd(s) (for example, some package dependency), i think that the right person to coordinate this work with the rest of the developers would be the proxy-developer. And yes, the proxy-devel also would file stabilization bugs , CCing the user too, so he can keep track of the process. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEydx/dZ42PGEF17URAtQXAKDTfcHhXthFw7cRS4Ko9p00mTYCkgCg2omJ JaoyxDew0HETTJxZ8ZrLrvk= =lfn9 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Enrico Weigelt wrote: The gentoo devs currently do much of the upstream's work. Fixing bugs or even adding new stuff which does not directly have to do w/ gentoo should be done exlusively by the upstream. Not true at all. We (as developers) won't be able to avoid helping upstream (it is actually in our social contract). For example, we have dealt with packages inside our herd where we are able to reproduce and detect a bug before upstream does; or even found a better way of doing something, and upstream (lucky for us) has always been happy of receiving our suggestions/fixes , included even patches. I personally think there is nothing wrong with this, i see it actually as one of the goal of gentoo. For an oss-qm + gentoo connection I imagine the following workflow: (should also work w/ other distros this way) * gentoo user files an bug - gets assigned to the devs. * dev inspects the bug whether its gentoo-specific or general @ general: * dev pushes the bug to oss-qm (files a bug there), * oss-qm tries to solve this bug and releases a new hotfix * the gentoo dev then takes in the hotfix and gives the patched package into the QM cycle. @ gentoo: * works as currently As for the suggested user contribution: The users willing to contribute simply join the oss-qm team and do their works there. This at least would cope evrything that's not gentoo specific. What remains to gentoo would be just the contents of the ebuild file (ie. useflags and dependencies okay, etc). I fail to see a border line between what you call 'gentoo specific' problems, and upstream problems. Really, it is not _that_ simple. Also, i don't see how this might be an alternative to my current proposal. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEykgrdZ42PGEF17URAhleAKDgRx+zMNomW+UUUbg3dCvJmHdtggCbB25s hGHkKFzMQmA6q9tMIaz3IhU= =y4MH -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Cernansky wrote: Oh, if I can speak for me as a user I'll not like it. One of the major advantage of Gentoo is easy maintenace (not mindless, but easy if you know what you are doing) thanks to portage system. Another is availability of large number of software in distribution. These two together gives easily maintanable operating system - because of portage and because I do not need to maintain lot of packages by myself. I don't know what it is your point here. But i guess, yes, as an user you shouldn't be worried about it. This is just another way for cooperating with the project for those interested in doing so. If I have some application that is not included in portage why I decide to make an ebuild? Because I hope that then it will be accepted and included to portage, so maintained by developers (big thanks for this). If I have to take care of package + ebuild + dependencies, I'll rather choose not to make an ebulid but compile package right from .tar.gz archive. Dependencies are not 'magically' solved. Somebody needs to initially takes care of them. Sorry for being such a bad user. But I'm pretty busy mostly so I'm glad If I find time to make an initial ebuild and submit. In that case, I see no problem to submit right to bugzilla and dicuss/fix/test the ebuild there. That is a different way to cooperate with us. I would agree with your points of user responsibilty to solve bugs, dependencies and so on, but only until package is accepted and included to portage. We need to know before committing this stuff to the tree that the user will compromise at some degree. And this kind of work is a good sign of it. We already have too many unmaintained stuff. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEylbXdZ42PGEF17URAiJ8AJ4hhP8DN5W6eRa9MTBA5md+qaLyRQCfW2Oe jhsfuMDxntw7okoD4qI1Zrg= =4ms8 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Cernansky wrote: On Fri, 28 Jul 2006 11:51:46 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Robert Cernansky wrote: If I have some application that is not included in portage why I decide to make an ebuild? Because I hope that then it will be accepted and included to portage, so maintained by developers (big thanks for this). If I have to take care of package + ebuild + dependencies, I'll rather choose not to make an ebulid but compile package right from .tar.gz archive. Many people disagree with you here, that's why overlays exist. Somebody wants to use Portage to manage ebuilds that aren't yet in the actual tree. Yes, it have sense for a larger set of packages (maybe) with complicated depenencies. But I'm talking about few single packages. An ebuild offer several advantages even for tiny packages. - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEymTtdZ42PGEF17URAnCRAJ0VD++qAN6/ivZAsaMFvdbuibelJwCfSus1 H9CeyZgw3G36Mfedej1hOrU= =rPeN -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello everyone,
Here, with this email, i propose (after a brief discussion on irc with
gensteaf)an alternative or at least a new model to address a few issues
with our maintainers needs and the inclusion of new packages into the
tree. Probably an alternative (temporary?) as well to the sunrise
project as the subject of this email suggest.
The idea is very simple, i will generally describe it here.
In my opinion, most of the developers are usually afraid of taking care
of maintainer-{needed-wanted} packages because of the following reasons:
1 - To fix bugs of the package: this might be a very easy task, or a
whole nightmare. Many of these packages got bunch of open bugs, so, a
developer think twice before going after a package that probably he even
doesn't know what it is for, besides that, this task might become very
time-consuming , the developer might prefer to invest this time with the
packages/herd he already maintains instead.
2 - To keep track of upstream: Though it sounds as an easy task, it
might become tedious sometimes, mainly if the developer isn't interested
at all on the project, and, this is definitely, another important point
when maintaining a package.
3 - Interesting packages: Which packages should we pick? , There exist
interested users/developers to maintain/use such a package?. We don't
have an easy way to keep track of this either.
These are the main points i have personally faced when picking
maintainer-{needed,wanted} ebuilds from bugzilla. So, i am pretty much
assuming from a personal point-of-view that others developers might be
also finding these problems (sorry if it is not the case). I don't
believe we all are happy with the current status of packages in need of
maintainers, something must be happening, and i think these three points
are part of the problem.
Ok, after detecting the problem, we need to solve it right? , the idea
is to create a proxy developer structure/mechanism/model/project , where
the developers could let all these three points at the hands of the
user wanting to get the ebuild included into the tree.
The 'modus-operandi' would go like this:
1 - We setup a mailing list (yes, yet another one, but this one is gonna
be useful!) , call it , [EMAIL PROTECTED] , or [EMAIL PROTECTED]
2 - Developers interested to serve as a proxy , subscribe to the list.
3 - Users ask on this mailing list if there exist any developer
interested to include X, or Y ebuild into the tree. (Probably we could
create a template for this?)
4 - An interested developer says 'yes' on the list (so the rest of devel
can see him too) , and from there on, the developer and the user work
off-list.
Or a developer can say 'no'. Explaining the reason (if any) of why
this ebuild shouldn't be included into the tree.
I think this would be solving some bugzilla communication annoyances,
and opening the doors of another 'feedback' way between developers and
users.
This is pretty much the general behaviour , simple right?
Now .. most of you must already be thinking, well .. isn't this the
same that going and picking maintainer-wanted ebuilds after all?
Here it comes the trick or 'trap' ;-)
The user _has_ to compromise to take care of those previous commented
three points that some of us might be afraid of, besides of giving us a
centralized way of keeping informed about new ebuilds.
The users explicitly compromise to (just to make it clear):
1 - To fix *all* bugs and problems of the package: The user will need to
take care of all the bugs and problems of the specific package.
Including all dependencies if needed, in the case that the package need
dependencies that are not in the tree yet. (All these requirements
should of course be explicitly stated in the user request email)
2 - To keep track of upstream: The user needs to know the package's
project, and all the communication with upstream should be
responsibility of the user. we also sometimes find developers of a
specific project who would like to cooperate with gentoo , in my opinion
this model would give them an easy and organized opportunity to do so
either.
3 - This will give us a nice way to officially include into the tree
those packages that are more interesting for our users community. After
all they are the ones maintaining them.
4 - These users will need to keep constant and fluent communication with
the developers , you can even call it a 'team' , where the gentoo
developer is the official representation of the project. This also would
give a nice 'isolated' environment , where Gentoo as a project only
would see one developer , so we don't need any internal changes to our
current way of working. /me knock infra doors :-)
This evidently brings some developers responsibilities too, we will need
to review, and test the ebuilds. we sometimes will have to check with
upstream, and comment on the ebuild, or fixing some details. But it
should be a far minimimal effort than the
Re: [gentoo-dev] Last rites for some CD/DVD-recording applications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin F. Quinn wrote: On Sat, 8 Jul 2006 13:09:29 +0200 Lars Weiler [EMAIL PROTECTED] wrote: app-cdr/xcdroast: A nice rustical application, which reminds me to my first CD-burnings on Linux... But there was no upstream update within 2,5 years. Also there are now a lot of other gtk2-based applications which are bettter than xcdrtools. If there's nothing actually broken with xcdroast, why remove it? It does provide a cd-burning app for those who want something with few dependencies. Are there other CD-burning apps that don't depend on qt or gtk2?gre Just my opinion too. Or what if just preserve it for nostalgic purposes? :-) /me used it as my first GUI CD-burn application - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEr6H5dZ42PGEF17URAmAQAKDN7Mrm4dqTrCSiw6qokPLsCFXA9wCgyHzM db5+X3xVQjitm+Dpo1AybJk= =4zAO -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] IMPORTANT: bugs performance issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lance Albertson wrote: All- Just thought I'd update you on some of issue's we've been having with bugzilla.g.o lately. Yes, its been slow in the last few months, but today has been even slower than normal. The primary reason being another large OSS project's database was added to the same server which appeared to cause a larger load than the OSL had expected. I have notified the OSL about the issue and they are working on bringing up another server to handle the load. I don't expect this to be done till tomorrow or the day after that so please be patient. On the plus side, thanks to the generosity of one of our great sponsors, GNI [1], we should be getting a cluster of blade servers in the next week or so to help with the on going bugzilla issues. I hope to finally get this resolved soon as its annoying me as well. Please thank GNI for helping us out! They really deserve a lot for helping us :). Thanks- [1] http://www.gni.com/ Thanks GNI ! - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFErGpldZ42PGEF17URAsbPAJ9mcQml25olNBOUZ94MWJ9onhPgHwCgrCoH WhFoxxCJEVPU6FoJ8rDYb80= =glZL -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Defining the Tree: a proto-GLEP.
Stephen Bennett wrote: On Mon, 12 Jun 2006 19:04:39 -0400 Luis Francisco Araujo [EMAIL PROTECTED] wrote: I like the idea. This would be some kind of portage-tree standard? This would be, in essence, a formal definition of the layout of the tree, and the format of and assumptions made by every file contained within it. Thanks, i do like the idea. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Defining the Tree: a proto-GLEP.
Stephen Bennett wrote: Continuing in the series of issues raised during the previous package manager discussions, I'd like to continue by mentioning the tree format. At present, it isn't defined beyond what the current portage supports, which is frankly a fairly silly way to do things. Following discussion in #gentoo-portage, I'd like to set out to change that. My current idea is to draw up a formal specification of what ebuilds are allowed to do, and what to assume about the environment in which they run, as well as defining the formats of everything under profiles/, metadata.xml files, and other auxiliary information in the tree. I would envision the first version of this document to more or less codify existing practise, perhaps excluding some dubious tricks that are known to break in some cases. Generally, it should be possible to make the tree conform to the first version of the specification by changes no more significant than currently have QA bugs filed for them. It seems fairly obvious that any effort of this kind could potentially have implications, albeit hopefully very minor, across more or less all aspects of the tree, and so I'd like to seek as wide a range of input as possible before going ahead with it. The QA and Portage teams, based on my enquiries in IRC, seem broadly in favour, and I would imagine that this could be very helpful to Gentoo/ALT as well, so I'd like opinions from others at this point. Would you support such an effort, whether passively or actively? Would you oppose it? If so, why? Final implementation of it would I assume require the Council's approval; while I won't ask at this stage for a formal discussion I'd appreciate the views of its members on whether such an initiative is likely to pass. Any input is gratefully received. I like the idea. This would be some kind of portage-tree standard? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Patrick Lauer wrote: On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote: How exactly is it easier to manage a large number of ebuilds versus a small number? It is easier to manage one large overlay than managing 35 small overlays. Communication overhead, duplication of effort, ... How many people will manage the big overlay? , How many ebuilds will this overlay have? , now compare that to the amount of people maintaining the small overlays and their number of ebuilds. Which one is easier now? Note: And i am omitting all that part of who are maintaining the ebuilds?, how they are maintaining them?, what kind of ebuilds they are maintaining?, and many many other details that probably immediately kill the assumption of a big overlay being easier than 35, 40, 90, 500 smaller overlays. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Donnie Berkholz wrote: Chris Gianelloni wrote: Since when was overlays.gentoo.org supposed to even be a service to our users? As I understand it, the goal was to ease development, not to provide an easy method for half-working ebuilds to make it to our user's machines. Our users are our biggest base of testers, and the point of overlays is to develop and test, so of course one of the goals is to get overlays onto users' (testers') machines. Making testing as easy as possible is important. But it should be clear that it is testing, and if the apps were ready for the real Portage tree, they'd be in it. Thanks, Donnie That's already being done very well with per-team overlays. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Stefan Schweizer wrote: Luis Francisco Araujo wrote: Fine. I highly agree on that, now my question is, why this needs to be officially supported? See Why does this have to be on official gentoo hardware? http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq The FAQ is offline due to ongoing discussion on this matter - expect a reworked FAQ when it has been reviewed. ? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
Chris Gianelloni wrote: On Fri, 2006-06-09 at 22:05 +0100, Stuart Herbert wrote: On 6/9/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Gentoo's standard operating procedure is to build packages as they were intended and packaged from upstream. +1 This means if the client and the server for a particular package is in a single package, we should build both by default. No thanks. That doesn't match the standard operating procedure mentioned above. By default, why don't we just build whatever $UPSTREAM intended built by default? That is *exactly* what I said. It means that different packages will behave differently throughout the tree, but that's okay, and is more Gentoo-like than your proposal. Except that you're just saying exactly what I said, just in different words. To facilitate building the client portions only, the use of the local minimal USE flag is allowed. How will you support building the server-only portions of the package? I honestly never bothered to consider it, and really don't care. Someone else can come up with that idea. The problem with using two USE flags is what do you do when someone chooses neither? It will build the $UPSTREAM default? And btw, i like the server and client use flag idea. +1 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] July Council Meeting: Requested Agenda Item
George Shapovalov wrote: субота, 10. червень 2006 04:28, Christel Dahlskjaer Ви написали: I would like to ask that the Council discuss the current state and future of the GWN at their next meeting. Hah? What has concil to do with this? Is it going to mandate GWN be better and it magically turns into some other thing? Why do you think there is malicious intent here at all? [skipping the listing] All these problems can be explained very simply - a lack of manpower. As I understand, GWN now is a one-man endeavour and Ulrich was pointing this out himself and literally yelling for help! Many many times! Over approx last 6 month or so.. Do we want a more reliable and representative GWN? Of course! How we can get there? Well, stand up and help! Involving council is not going to do anything besides starting yet another pointless burocratic endeavor. Well, I suspect it won't do even that - I am pretty sure council is going to just throw out this claim even if you officially start it. They can of course mandate some more action, but what would be the point? If there are no people willing to stand up, then who will listen to it? So, to conclude this thing. The only way GWN is going to improve, is if some more people will join the ranks and start writing/editing GWN entries. I'd say a team of 3 people is usually sufficient, but we need more like 7 so that three are available for more than a first month :) (this is based on my experience with organazing Russian transation team in its early days), plus a steady stream of at least one new dev joining/two month, to compensate for people droppig out. This should also have an effect of draft GWN published at least a day in advance, instead of a few hours, so that the rest of us will be able (and will ;)) take a look at it and make corrections.. George That's true. Ulrich has been asking desperately for help since a few months now. I propose we ask for contributors in the staffing-needs section instead or before taking this council way. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] What is official?
Everything maintained by the Gentoo project, instead than for the Gentoo project. Stuart Herbert wrote: Hi, One of the issues that the o.g.o project has brought to a head is the definition of what is official and what is not official when it comes to Gentoo. The term is already being thrown about in the Project Sunrise thread; I'm sure it'll come up again in future. It's an issue I think we should discuss and find an agreement on. Personally, I think what makes something official or not is 100% down to who does it. I think something is official if it is done by the project (where a project matches the definition in the metastructure project) responsible for whatever we're applying the label official to, then that's all that matters. So (picking something entirely at random for an example), if the Java project had an overlay somewhere (say, on gentooexperimental.org), because it's their overlay, the overlay is official. Doesn't matter where it is hosted - all that matters is that it is run by the Java project. Equally (because it is the hot topic of the moment), Project Sunrise's overlay would be official because they're a Gentoo project. The way to stop them being official is simply to have the Council pass a resolution to shut down the project. I think the other side of the term official is clarifying the scope of how far something can be official. Using the Java project as an example again (sorry guys :), the Java team can put in place official policies and procedures for what their team does, but that doesn't make them mandatory for the whole Gentoo project. Other developers remain free to form competitive projects, and put their own official policies and procedures in place if they wish. (I hope I explained that last bit properly. What I'm trying to do is keep in mind the terms of the metastructure document, which explicitly allow for two or more teams to be competing with each other). What are the alternatives? If a project's activities are not automatically official, then who gets to decide, and how is that decision made? How can that decision be made fairly, without contradicting the metastructure, and without giving rise to any accusations of 'cabals'? Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Chris Bainbridge wrote: On 09/06/06, Luis Francisco Araujo [EMAIL PROTECTED] wrote: Chris Bainbridge wrote: There are already loads of semi-official overlays. Besides the stuff actually hosted by gentoo (random example http://dev.gentoo.org/~flameeyes/bzr/overlay/) there are official groups (again, not picking on anyone but exampes would be java, php, webapps...) with semi-official overlays. I don't know if the overlays are actually hosted on gentoo hardware, but when they're run by gentoo devs, publically available, and referred to in forums, bugzilla, mailing lists etc. then that at least makes them semi-official. I don't agree with that semi-official term. We for example have an overlay for the Haskell project. Nevertheless, we consider it the official overlay for our group, but not for Gentoo. So that way we can use it as our sand-box, to play with it as much as we can, and giving commit access to even non-developers, the advantage The Haskell overlay isn't publically available (at least, layman doesn't know about it). That makes it quite different from the semi-official overlays I gave as examples. I really don't know what semi-official means. And our overlay has always been publically available, http://haskell.org/~gentoo/gentoo-haskell/ But we don't have it as a way to offer extra ebuilds. We have it for testing, and experimental works and it has been used as playground for new developers too. Whether something is semi-official or not is all about perception. If people see that a project is run by gentoo developers, possibly formed into a gentoo group, using gentoo resources (bugzilla, forums, mailing lists etc) to discuss and organise, then there will be a perception that the project has some semblance of officiality. I am not against the overlay idea, i like it very much!, and we have been using it successfully in our team. I just don't see the point of having another official portage tree with maintainer-wanted packages as an overlay. Don't you see that what you are asking for is to have another portage tree, but now, with bunch of unmaintained and orphaned stuff, plus the extra sugar of *dangerous* consequences as some developers have already pointed out in this thread? I think we already have LOT of work with only one tree. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Chris Bainbridge wrote: On 09/06/06, Luis Francisco Araujo [EMAIL PROTECTED] wrote: Yes, i agree, writting and maintaining ebuilds is a hard and *time-consuming* task. So if an user can't even take the time to fix a digest, why we should support him officially?. The point is that there are lots of users who are interested in niche packages that no developers use or are interested in. These users have the skills to write an ebuild, and other users of the package have the skills to fix and maintain that ebuild over time. These guys don't mind downloading ebuilds from bugzilla and fixing digests. But there are a larger class of users of niche packages that don't have the ebuild skills, and don't want the hassle of bugzilla and digest fixing. This larger group of users are the ones that would benefit from an overlay. Fine. I highly agree on that, now my question is, why this needs to be officially supported? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Peter wrote: On Thu, 08 Jun 2006 02:42:03 +0200, Stefan Schweizer wrote: Hi, I have founded a new Gentoo Project for the Gentoo User Overlay. The intention is to give contributors a single place to put their ebuilds - a place where they can be downloaded, updated and be moved to portage more easily than through bugzilla. It is also a good place for users who would like to become developers to learn how to commit and how to not break the tree. I think this answers an important shortcoming of the bugzilla approach: vis, some bugs will never make it to the tree -- for any number of reasons. Take, for example, http://bugs.gentoo.org/show_bug.cgi?id=103354, which has an enhancement request for what is now called beyond-sources. A amalgamation of the arch, ck, tiger, nitro, and suspend2 sources. While on the kernel, IRC, I enquired about it, since I had just updated an ebuild for it, and was told unequivocally that there was no interest on the kernel team's part for adding this source tree to sys-kernel. Not maybe, not let's have a look at it, not come back in a month after testing. Just NO. And, I'm fine with that. That's their job -- to protect the quality of their project, and to keep things relatively safe and manageable. Nonetheless, the bug is active, with a good number of people subscribing to it and contributing to it. The sunshine overlay would be an ideal place to store a kernel source tree or any project which would never find a home in portage. If the ebuild will never find a home in portage, then it shouldn't be officially supported. What you are proposing is like to setup a parallel portage tree. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Chris Bainbridge wrote: On 08/06/06, foser [EMAIL PROTECTED] wrote: I don't think the problem with maintainer-wanted ebuilds is that they are crappy, but that there is no dev willing to maintain them and ensure their quality over time. 'sunrise' (who came up with that name ? cheap asian poetry attempt) doesn't change that by adding it to an 'official' overlay. One of the problems is that developer interest is transitory. The current system suggests that a developer take personal responsibility for ebuilds they maintain, and they maintain them until another developer steps up. It would be nice (and I guess this is one of the aims of sunrise) if there were a way for people to contribute ebuilds that they are interested in at the time, but don't want to promise to maintain forever. Think about wikipedia - how many pages would there be if every page creator had to guarantee that they would maintain each page indefinately? The time it takes to actually apply fixes etc. is another point. Bugzilla is a poor system for sharing and managing the flow of ebuilds and patches. It would be nice if there were a way for non-devs to publish ebuilds/fixes using a VCS so that they could be shared and easily pulled and applied to the main tree. It takes too long to browse bugzilla, find bugs, find ebuilds and patches, download them, copy to an overlay, fix digests, emerge, etc. and most users will figure it's not worth the hassle. Yes, i agree, writting and maintaining ebuilds is a hard and *time-consuming* task. So if an user can't even take the time to fix a digest, why we should support him officially?. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Chris Bainbridge wrote: On 08/06/06, Jon Portnoy [EMAIL PROTECTED] wrote: I do very much object to using any gentoo.org infrastructure or subdomains to do so. If someone is going to tackle that, it should be done outside of Gentoo proper. We don't need to be stuck maintaining and supporting a semiofficial overlay. There are already loads of semi-official overlays. Besides the stuff actually hosted by gentoo (random example http://dev.gentoo.org/~flameeyes/bzr/overlay/) there are official groups (again, not picking on anyone but exampes would be java, php, webapps...) with semi-official overlays. I don't know if the overlays are actually hosted on gentoo hardware, but when they're run by gentoo devs, publically available, and referred to in forums, bugzilla, mailing lists etc. then that at least makes them semi-official. I don't agree with that semi-official term. We for example have an overlay for the Haskell project. Nevertheless, we consider it the official overlay for our group, but not for Gentoo. So that way we can use it as our sand-box, to play with it as much as we can, and giving commit access to even non-developers, the advantage with this model, is that at some degree we compromise ourselves as a group with the little base users who dare to test experimental stuff (that probably will *never* find its way into portage), but we keep Gentoo as project excluded from such a responsibility. And.. isn't that the real sense behind the overlay concept?, to have an official overlay wouldn't break the main goal of it?, and even more, an official maintainer-wanted overlay sounds more crazy to me. Regards, -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Peter wrote: On Thu, 08 Jun 2006 15:51:25 -0400, Chris Gianelloni wrote: First, let me say that I'm approaching this from a user's perspective. I have no insight or knowledge as to the history of the overlay project or any of the people involved. I _do_ know that since late 2004 when I first switched to Gentoo, each week there are more bugs opened than closed. There are also many open bugs that go back years. In my particular frame, I want ebuilds I need or have contributed to get into the tree. Having to download new ebuilds into local, and then have no way to emerge update them is frustrating. My point was about two things: 1) ebuilds that will never be committed to portage, and 2) ebuilds that have been orphaned due to lack of interest. As for breakmygentoo, here is my thought. As a user, I would prefer to do all my shopping in one place. Gentoo has portage and uses ebuilds as a package distribution mechanism. I would prefer to use gentoo's facilities to get additional off-tree ebuilds. I don't want to have to sync all over the place to get ebuilds of unknown origin. I would prefer to have a sanctioned alt-gentoo ebuild repository where I know some q/a is applied and standards adhered to. My inference of the sunshine project was that there would be oversight and control. That if _I_, for example wished to contribute, then I would have to meet standards. And, on the flip side, anyone who would care to download an ebuilt from o.g.o would be confident that the ebuild at least meets certain quality standards. o.g.o, of course would have to disclose that these packages are testing, and possibly experimental, but it's a terrific opportunity to find a home for many orphaned and ignored packages. Using the example I brought up, about the kernel-sources, o.g.o would be a perfect home for such a project. snip. As I see it, there are really two main issues with bugzilla. One, is to resolve open ebuild enhancement bugs. Mark them somehow so it's clear the bug has been reviewed and an action determined. CANTFIX/WONTFIX is harsh, but if that's what it is, then mark it! The second issue is the orphaning of packages which have merit, but no maintainer. Again, the sunshine overlay would provide a home for those packages. It will also allow the user to take ownership of a project, get some experience, and maybe decide to become a dev. And, should that occur, then, lo, the orphaned package may have a maintainer someday. This is something that I do not get. Why exactly does everything have to be resolved in some specific time frame? Is when I get to it not good enough? I mean, it works for Linus, right? ;p Why? Because having two year old bugs is simply inexcusable. You are always free to fix them. Or even better, free to become a dev and maintain them. Especially when many have not had any activity for a long time. Having maintainer-wanted bugs for months on end is silly. Giving a user who files a ebuild request or submits an ebuild deserves the chance to take ownership of it. It's a good way to get a more experienced user, and hopefully one day, a future dev. I agree. It depends at the end upon the user interest to submit/maintain an ebuild. Though that is our current situation with bugzilla too, so i don't see what is the advantage of the overlay here. As for packages that have merit, this is quite simple. If the package has enough of a good following, it will get picked up. The likely reason why many of the maintainer-wanted packages are in the state they're in is simply because there isn't enough interest in the package. In this particular instance, I can see an external overlay being useful. However, there already is one. It is called breakmygentoo. Do we really need to duplicate their functionality? Well as for packages getting picked up, this is not completely accurate. Some will never get picked up, either because they are inappropriate (hot-babe, for example), or too experimental (the kernel-source example I cited). As for bmg, which I have to admit I had never heard about before today, as a user, I would prefer to have everything genoo-sanctioned and controlled. So, hopefully, as the overlay project moves forward, it will help take some of the heat off bugzilla and allow for the offering of more ebuilds to userland. I sincerely hope it doesn't effect bugzilla in any way. I have no problem with users getting access to ebuilds, but many of these ebuilds simply are not ready for anyone to get them automatically. Having an ebuild on a bug makes it easily searchable. Having an ebuild on a bug makes it easy to peer review. Having an ebuild on a bug means the user needs to explicitly add the ebuild to their overlay. Users would not be getting o.g.o ebuilds automatically. They would have to actively emerge layman, and then select the ebuilds they want. I agree with you that the o.g.o and the main portage tree should never
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Stuart Herbert wrote: On 6/8/06, Henrik Brix Andersen [EMAIL PROTECTED] wrote: Will you also review the code each and every ebuild pull down over the internet? The policy for overlays.gentoo.org hosting [1] is hopefully clear: as the project leads, they're ultimately responsible (and therefore accountable) for what goes into their project overlay - no matter whether it's committed by a dev or by a user who has been entrusted with commit rights to the overlay. The policy for what can go into an overlay is also hopefully clear: overlays are for package trees, their patchsets, any docs, and any downloadable tarballs that have nowhere else to be hosted. It's not there to be $UPSTREAM, except for eselect modules, -config scripts and the like that exist purely to support ebuilds in the package tree. I expect projects and developers who are using overlays to be respectful of others. The whole point of the overlays project is to continue our work in trying to get our users much more involved in developing Gentoo. It's there to be a stepping stone for getting packages into the tree - although I do not expect every package in overlays to end up in the tree. Any hostile hijacking of other people's packages doesn't fit into that vision, and there's no place for it on o.g.o. I also expect projects and developers who are not using overlays to be equally respectful of those who are. There are projects and developers who find overlays an excellent way of safely testing and developing ebuilds, and who find overlays to be a good way to help train and develop the next generation of Gentoo developers (good developers are something we really need more of). That is being done with the per-group overlays. No need to have a maintainer-wanted official overlay for it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Diego 'Flameeyes' Pettenò wrote: On Tuesday 13 June 2006 20:27, Stephen Bennett wrote: They're rather minimal, and still an order of magnitude larger than what I'm proposing here. Right, the point is not the change in itself but the way people are going to experimenting with it. Sorry if i am confusing things here, but isn't this just _yet_ another profile that the user can choose to use?, And if it is so, i think it'd be nice for both developers and our user base to have such an alternative. It will be at the end up to the final user to give it a try or not, assuming their respective risks (if any). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Diego 'Flameeyes' Pettenò wrote: On Tuesday 16 May 2006 22:13, Jan Kundrát wrote: See /usr/portage/profiles/default-linux/x86/dev/README :) You think the phrase RTFM would have ever been forged if people actually read that stuff? This is pretty much true for trying out any new stuff. -- gentoo-dev@gentoo.org mailing list
