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=rev&rev=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 tag in metadata.xml is used to assign a package to a |>> certain group. |>> 4) the 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: | | | foobar | | | This makes it clear that it is a team instead of a person (where | 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 | ... 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 ... 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] Prioritising contact information in metadata.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeroen Roovers wrote: | Hi developers and other users, | | | since jakub[1] went completely missing a few weeks ago a few others and | I have been wrangling the bugs. I've heard rumours that this isn't | working smoothly yet. Of course most of that can be fully blamed on | bugzilla itself, but there are some things that need to be pointed out | or discussed. | | One thing I'd like to point out is that if you don't agree with a | specific mangle, just CC whoever did it on the bug and explain. | If you don't give me the feedback, I can never know how you would | rather have wanted to get bugs delivered. | | 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 | (or you get "Assignee: [EMAIL PROTECTED],[EMAIL PROTECTED] did not | match anything"). | I'd say that in the case of a herd listed , the bug should be sent there. If it doesn't specify a herd but several developers, sending the bug to any or all of them should be the rule. | All in all I guess we need to make the rules up as we go and decide | policy later. I suggest the first herd/address in the list should be | the primary contact. If you don't agree with that, please consult I agree. - -- Luis F. Araujo "araujo at gentoo.org" Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkgRBIoACgkQNir3WYj9aLp8UwCfeiHyHDQCDXd1nw0/oauctVVc UWkAn0Y4b1Be65A0ThXqDQIbTXRGbKSv =YVb7 -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] Re: Gentoo Graphical User Interfaces Project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jure Varlec wrote: > > Hello, > > > > I hope this post gets through, I just switched to using gmane, so I'm sorry > > if it gets posted incorrectly. > > > > I take it you intend to use GTK. May I suggest you also provide ncurses Yes, we expect to use mainly either Gtk+ or Qt; though any toolkit easily available on Gentoo would work too. > > interfaces to your programs? I'm not sure how much additional work that > > would be, as I don't program UIs. But an additional ncurses interface would > > provide users with the comfort of having the same tools available in case > > their Xorg fails for some reason, and on their X-less servers. > > This project is focused on 'Graphical Interfaces' (hence its name); therefore that's our main priority. Though a ncurse alternative could be nice for some users, that would imply take other roads that we are not willing to take, at least not yet. It could be possible in the future to re-use part of our work for ncurses and terminal based interfaces , but as i said, it is not our priority. > > Also, if a user modifies a tool-managed config file, the tool shouldn't get > > confused, and vice versa. I'm sure that goes without saying on Gentoo, but > > since I've only used GUI tools on Mandrake and Ubuntu and this is where > > they often fail, I feel the need to mention it. For example, Ubuntu's > > network config tool often didn't match what ifconfig said about the > > interfaces' status; I don't want to know what would happen to it if I used > > ifconfig to actually change configuration. > > Designing a GUI involves many layers , and therefore, many ways of communicating these layers .. it might sound an easy work, but in practice it's tough to do it right. One of this project's goals is to do it right on Gentoo systems. Thanks and Regards, - -- Luis F. Araujo "araujo at gentoo.org" Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG3zJGBCmRZan6aegRAqGLAJ4/JoYrGrTdJzjfoqgEGPvJJHBbWQCfU1Vb LLRKqzkk5qpNLP1ltxRmde8= =pk7v -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
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
[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] 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+. > > http://dev.gentoo.org/~jokey/screenies/mhelper-versionbump.png> > 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: > Ilya A. Volynets-Evenbakh wrote: >> We might need some sort of enforcement for that particular purpose. >> While I think that "behavior" proctors are inappropriate, I think that >> people with ability to say "move this thread to gentoo-politics or >> else.." >> for non-technical threads, as well as "stop failing to use logic in your >> technical discussion or else..." with power to temporarily ban people >> for non-compliance could be a useful thing. >> > > IMHO, any enforcement needs to come from the developer community > themselves. We have to be careful when designating small groups of > people with power, because the dark side of power is that can can be > misused. The model of developers collectively enforcing works well > already: the Portage Tree. While we've had small mishaps here and > there, largely, the honesty system used on the tree has worked quite > well. I think that can easily extend to keeping -dev technical in > nature only. After all, it already works for the wayward users who > posts a -user question to -dev. Just a simple, courteous note that such > a question is better asked on -user, and off they go. Nothing precludes > the same response for a fellow developer posting a non-technical mail > into -dev. > > But anyways, we've got unanimous support so far, so next up: What to > call it. > > My two choices are gentoo-politics or gentoo-project. After looking at > debian-project a bit, I think there's no harm in recycling the same > moniker[1] for our use as well. Amusingly enough, there's even a thread > on their ML today about discussion of of-topic topics. The rest of the > content there seems to be right in line with what's been on here too as > of late. > > So, what should we call it? Vote on this! I think the current popular > names are the following (in no particular order, just what I've already > seen suggested): > > gentoo-politics > gentoo-circuits > gentoo-soap > gentoo-project > gentoo-gossip > > > [1]: http://lists.debian.org/debian-project/ > > > --Kumba > gentoo-project++ - -- Luis F. Araujo "araujo at gentoo.org" Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGaYa6aTNpke9pJcURAgWwAKCArUbjNjofH4J5lD/8LBTTRHiIUQCfTkyy vygwEFjO9UlYh7xf2jwuiUs= =wsE2 -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] Suggestion
Chris Gianelloni wrote: On Thu, 2007-02-08 at 11:59 +0100, Jose San Leandro wrote: That is enough once you know how to write ebuilds. We were thinking of a GUI to soften the learning curve to non-experts. Probably not useful for a Gentoo developer, but could provide an easy way to write ebuilds to project maintainers themselves, not to Gentoo resources. I think what everyone means here is that if the default functions don't cover it, and an eclass doesn't cover it, then all of the code will have to be written by hand, anyway. No amount of pretty clicky interfaces will help this. The only thing I would really see as being useful would be a simple help system that is aware of all of the functions in ebuilds. This could be possible if there were some standardized way to document functions and their uses, so it could be parsed at run-time from the tree itself, but currently, I don't see it getting much traction. Don't get me wrong, I see lots of places where work could be done to make things easier, such as some way to easily determine dependencies. I just don't think it is possible to write up an IDE until more work is done defining the current eclasses and functions into something more static. It'd be very difficult to replace just 'opening a text editor' by an IDE. Though you might probably come up with very cool ideas ; like for example, an eclass browser that could search function based on name or descriptions of what the developer is looking for; probably with some hierarchy view for surfing them. At the end, i guess a text editor would be the best option; but that doesn't mean you can't try new methods/ideas. Regards, -- Luis F. Araujo "araujo at gentoo.org" Gentoo Linux -- gentoo-dev@gentoo.org 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 (Gentoo reports)
Chris Gianelloni wrote: - Project status reports once a month for every project Totally agree on this one! OK. I'll give you Release Engineering's "status reports" for September, October, and November: September: taking a well-deserved break October: taking a well-deserved break November: taking a well-deserved break How about other projects that rely on things like upstream's release cycle? What about projects that just maintain ebuilds? Here's the games team's "status reports" for every month: "Fixed more bugs, added more packages, cleaned up some ebuilds." Now, perhaps what everyone would like, instead, would be status reports *where necessary* from certain projects? In fact, the council has been discussing asking a few projects about the status on some of their tasks. The main reason for this is for communications purposes. Basically, we'd just get a "Hey, where are you at on $x?" response from the teams. I don't *want* to drown projects in bureaucracy and paperwork. I want them to *accomplish* things, instead. I think the problem with reports is "how often would they be posted?" , and exactly "what kind of info would they contain?". I propose the following: To post a Gentoo Project report every six months, (yes, accompanying every Gentoo release, *be careful*, i am not saying you releng guys should take care of this). This report would be like a way of ChangeLog for our Gentoo project, which could contain the following: - Herds news: Each herd could write a 1-2 page report about the main changes they have done in these last 6 months. Including news about interesting packages added, new eclasses for sustaining the herd packages, any useful comment for the users of the herds, etc etc. - Project news: This could include projects like releng, pr, userel. Which could post general news about the main things happening for these last 6 months too. For example, releng could post about some new techniques involved to release this new Gentoo release; which packages were more problematic for building it and why? , in other words, the kind of info our users (and devel too) would be interested on. Now, this kind of report could be very very useful, both for users as for our developers. And making its release every 6 months, i think the time and what-to-comment problem shouldn't be a concern at all. I already can hear some of you saying "No, i don't want to write anything for X or Y!" ; fine, just don't do it. Nobody would be forced to do it. This would be a paper for those herds/projects/developers willing to communicate their work during the past 6 months to our community, and which could become in a very informative source to give a general overview of what it is going on in Gentoo land. "Fine , i won't write anything .. but .. mm .. Who would read this anyway?" , i hear this question too ... Sorry, i can't give you names of who are going to read this. But i think a big portion of our community would do it, if we post it on gentoo.org every 6 months surely someone would pick it and read it, don't doubt it. (myself included.) "Ok .. mmm fine .. mm.. wait, this is the same than GWN, isnt this?"; no it isn't ; i don't see a common pattern of Herds/Projects reports (check, it is report, *not* news) released every week on GWN; and that's because, GWN is for general weekly news .. that is very evidently on its name indeed. Suggestions and constructive criticisms are welcome. Regards, -- 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: 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] 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] 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
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-dev&m=115637880223243&w=2 *sighs* -- 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
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 $ to take decisions about $?". 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] 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] 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] 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] 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
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] 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] 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] proxy-dev (an alternative to sunrise?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Cort wrote: > On Thu, 27 Jul 2006 22:19:14 -0400 > Luis Francisco Araujo <[EMAIL PROTECTED]> wrote: > >> The users explicitly compromise to (just to make it clear): [1,2,3,4] > > People who participate in open projects like Gentoo come and go. What > happens if/when the proxy maintainer decides to leave? Who will take > care of the package? Maybe the mailing list could also be used to find > users to proxy maintain abandoned packages? > Good point. Definitely, the mailing list could be used to address this case too. I see two possible situations in the best case: 1 - The developer sends the request to the mailing list asking for somebody interested to continue proxy-maintaining the packages. Any interested developer could step in. 2 - The proxy-user *could* be interested to become official developer to maintain this package too. As long as there exist an interested user to maintain the package i think it's a matter of time to find a proxy-developer. (Any mechanism to inform us which packages are in this state would be useful too, probably a monthly message to the list?) Now if the user isn't interested anymore , and i think this would be the 'worst' of the case, could be addressed in the following manner: 1- He could notify to the mailing list for any user interested to continue maintaining the package(s). 2- If no user steps in, the developer would still represent officially the package inside the tree. Now, this package _ideally_ shouldn't have any bug (the user should have taken care of all of them right?), so practically, this package shouldn't be any serious menace to the tree, and therefore, the developer doesn't need to update the package if he doesn't want to. If a bug appears , the developer can: a) Fix it , b) mask the package , c) After b, remove the package. This being the *worse* of the case as i said. Now, i also see an interesting problem here. I can notice we (as developers) make sort of an agreement when we become a developer, but not when we leave the project. This is the main cause we keep having so many packages unmaintained. I think that whatever we do, if we don't find a solution to this situation, gentoo will continue to suffer of this problem. And this idea is just an attempt to alleviate some of it. >> I know there already exist some developers working as proxy, well, i >> appreciate if they got any comment or observation about this idea. This >> is just a way of giving some organization to this kind of cooperative >> mechanism at some degree. And an 'official' representation inside Gentoo >> if we agree with it. > > I work with a user (Kai Huuhko) to maintain media-sound/quodlibet, > media-libs/mutagen, and media-plugins/quodlibet-*. I have a dev overlay > on overlays.gentoo.org where Kai and I both have commit access. We both > work on the ebuilds in the overylay and exchange ideas over e-mail. > After the ebuilds are complete and tested, I commit them to the official > tree. Kia helps with bugs too. So far it has worked very well for us > and we haven't had any problems with the arrangement. Having a helper > saves me time and energy, which allows me do other Gentoo related tasks. > > -Thomas Nice, we have something similar inside the Haskell herd. It looks like we are not the only ones doing good then. Probably making this mechanism more 'organized' and 'official', would encourage more developers to work with it. - -- Luis F. Araujo "araujo at gentoo.org" Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEyYr4dZ42PGEF17URAovbAKCwSlJ8657WQpLPhRamAZ4SRrUdSgCgvMS2 ZS8ybMME+hXrByoct5BQh8Y= =31YO -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 th
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] 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] [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] 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] 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] [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] [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] 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] 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] 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 n
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] [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] 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] 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
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
