Re: [gentoo-dev] Re: Git commit mails/CIA.vc notifications
On Fri, 4 Feb 2011 22:41:57 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Jeroen Roovers posted on Fri, 04 Feb 2011 16:08:24 +0100 as excerpted: > > > On Fri, 04 Feb 2011 03:26:16 +0100 Christian Ruppert > > wrote: > > > >> Hey guys, > > > > Only half of people? :) > > That's just /begging/ a reply. (In reference to "begging the > question" and the controversy surrounding it. Linguists and > perscriptivists vs. descriptivists, etc. An entirely different topic > but look up language log for some /hours/ of interesting reading, if > you're ever bored. =:^) > > On wictionary, "guys" has three definitions: First of all, wikctionary. Get real. Second of all, most of us don't need a dictionary to be in the right. Either you respectfully address all users and developers on the announce list, or you don't even respond like the original writer didn't. :) jer
Re: [gentoo-dev] Re: Git commit mails/CIA.vc notifications
On 04/02/2011 22:41, Duncan wrote: Jeroen Roovers posted on Fri, 04 Feb 2011 16:08:24 +0100 as excerpted: On Fri, 04 Feb 2011 03:26:16 +0100 Christian Ruppert wrote: Hey guys, Only half of people? :) That's just /begging/ a reply. No. It wasn't. Please stop filling up my inbox. Yes I know what the next reply is.
Re: [gentoo-dev] Re: Lastrite: lince and slmodem
On 02/04/2011 05:24 PM, Diego Elio Pettenò wrote: This said, I'd suggest users and developers alike to add themselves (or ask to be added) to the metadata.xml files for packages requiring specific hardware support, so that even if one maintainer ends up not being active, we have a list of people who can actually tell us whether a given package works or not. And don't simply avoid doing so because there is someone else on that list already; we don't have a limit of one, two or three people listed in metadata.xml. The more people we know are ready to test a given package on actual hardware, the better (and you can be listed as "just a tester" after all). What's true of developers is also true of users; a user may add themselves to the list, forget they are on it, and a year from now be asked to test something they no longer have hardware for. Not saying that this isn't worth doing, merely pointing out that we may discover that we don't have anyone to test even WITH the list of willing users. Later, Chris
[gentoo-dev] Re: Lastrite: lince and slmodem
Il giorno mer, 02/02/2011 alle 01.33 +, Matt Turner ha scritto: > > Maybe you did this already, but it seems like the amount of time spent > masking a package could have been spent poking whoever is supposed to > be maintaining it (Alin Năstac > I can't obviously speak for Alin, but I'd like to point out one particular issue here: Alin has been maintaining for a long time the whole net-dialup herd alone, and has been doing a very good job, considering the amount of different packages in that. On the other hand, packages that require specific hardware to be tested cannot really be maintained by developers that don't have them (any longer). What does that mean? Mostly it means that a lot of packages for hardware devices that are no longer commonly used (such as softmodems) cannot be easily kept up-to-date, unless we have people using them on a daily basis who can step up to maintain them. Furthermore, for the packages that are implemented in kernel-space or mixed in kernel- and user-space, each kernel version will be a further problem. This said, I'd suggest users and developers alike to add themselves (or ask to be added) to the metadata.xml files for packages requiring specific hardware support, so that even if one maintainer ends up not being active, we have a list of people who can actually tell us whether a given package works or not. And don't simply avoid doing so because there is someone else on that list already; we don't have a limit of one, two or three people listed in metadata.xml. The more people we know are ready to test a given package on actual hardware, the better (and you can be listed as "just a tester" after all). -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
[gentoo-dev] Re: Git commit mails/CIA.vc notifications
Jeroen Roovers posted on Fri, 04 Feb 2011 16:08:24 +0100 as excerpted: > On Fri, 04 Feb 2011 03:26:16 +0100 Christian Ruppert > wrote: > >> Hey guys, > > Only half of people? :) That's just /begging/ a reply. (In reference to "begging the question" and the controversy surrounding it. Linguists and perscriptivists vs. descriptivists, etc. An entirely different topic but look up language log for some /hours/ of interesting reading, if you're ever bored. =:^) On wictionary, "guys" has three definitions: http://en.wiktionary.org/wiki/guys 1. plural form of guy 2. (colloquial) Persons, irrespective of their genders. 3. (colloquial) A form of address for a group of male persons or a group of mixed male and female persons. All three of those are potentially gender neutral. There's two sets of synonyms listed, the first gender neutral (people, persons, folks), the second "male persons" (blokes, chaps, dudes, fellows, gents). Following thru on the first def, guy (and disregarding the other meaning, noun/verb related to an anchor or support cable), we find that the original reference was to Guy Fawkes, an Englishman hanged in 1606 for his role in the Gunpowder Plot. Here, we have five definitions: 1. (UK) (In direct reference to the origin.) An effigy of a man burned... 2. A male. 3. (colloquial, in plural) people. 4. (colloquial, of animals and sometimes objects) thing, creature. 5. (colloquial, technology) thing, unit. This usage is not always seen as accurate or correct. (The example quotes are interesting but omitted for brevity.) Of particular interest here is the usage note, mentioning "Hey guys" in particular: In plural, guys is not completely gender-neutral but it may refer to people of either sex in some circumstances and forms; "Hey guys" can generally refer to either gender, as a greeting in its plural form. [R]eferring to a group of people as "guys" usually means a group of men or a mixed group[.] So while it /could/ refer to only half of people (males), alternatively and in the wider sense, it /could/ refer to a /superset/ of all people instead, including not only animals but even things! (Usage: "This guy here, measures the voltage.) Just in case someone has a problem with wictionary, Merriam-webster.com has similar definitions, including specifically the person usage, and individual/creature usage. http://www.merriam-webster.com/dictionary/guy[3] -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Unused eclasses
I assume (1) that Yannick is not subscribed to gentoo-dev, and (2) that his mail is not private to him so I dare to forward his mail to you. Yannick, thanks for investigating. >From the output he shares I conclude that the only eclasses truly not used anymore are: - games-q3mod - ruby-gnome2 - mozreconf See details below. Sebastian On 02/04/11 19:13, Yannick Chabanois wrote: > The answer (dirty) : > eclipse-ext : > gentoojp/dev-util/pleiades/pleiades-1.2.0.ebuild:inherit eclipse-ext > pentoo/dev-util/eclipse-pydev-bin/eclipse-pydev-bin-0.9.8.7.ebuild:inherit > eclipse-ext > pentoo/dev-util/eclipse-pydev-bin/.svn/text-base/eclipse-pydev-bin-0.9.8.7.ebuild.svn-base:inherit > eclipse-ext > sunrise/dev-util/eclipse-epic-bin/.svn/text-base/eclipse-epic-bin-0.3.0.ebuild.svn-base:inherit > eclipse-ext > sunrise/dev-util/eclipse-epic-bin/eclipse-epic-bin-0.3.0.ebuild:inherit > eclipse-ext > > fortan : > bgo-overlay/sci-physics/avl/avl-3.27.ebuild:inherit toolchain-funcs fortran > bgo-overlay/sci-libs/cgnslib/cgnslib-2.5.3.ebuild:inherit fortran > versionator multilib > dberkholz/sci-chemistry/espresso/espresso-4.0_pre2.ebuild:inherit > autotools eutils fortran toolchain-funcs > dberkholz/sci-chemistry/refmac/refmac-5.6.0069.ebuild:inherit fortran > base toolchain-funcs versionator > dberkholz/sci-physics/abinit/abinit-5.7.3.ebuild:inherit fortran > multilib toolchain-funcs > dberkholz/sci-physics/exciting/exciting-0.9.74.ebuild:inherit fortran > dberkholz/sci-physics/campos-dacapo/campos-dacapo-2.7.7.ebuild:inherit > distutils fortran multilib > dberkholz/sci-physics/octopus/octopus-3.0.0.ebuild:inherit fortran > dberkholz/sci-libs/etsf_io/etsf_io-1.0.2.ebuild:inherit autotools eutils > fortran flag-o-matic multilib > dberkholz/sci-libs/bigdft/bigdft-1.2.0.ebuild:inherit eutils fortran > multilib > dberkholz/sci-libs/fox/fox-4.0.3.ebuild:inherit eutils fortran > dberkholz/sci-libs/wannier90/wannier90-1.1.ebuild:inherit eutils > multilib fortran > dberkholz/sci-libs/libxc/libxc-0.9.ebuild:inherit fortran multilib > dberkholz/sci-biology/TMalign/TMalign-.ebuild:inherit fortran > dberkholz/sci-biology/mmult/mmult-1.0.ebuild:inherit autotools eutils > fortran > dev-zero/sci-mathematics/octave/octave-3.2.2.ebuild:inherit flag-o-matic > fortran xemacs-elisp-common > gentoojp/dev-ml/lacaml/lacaml-3.0.20.ebuild:inherit findlib fortran > toolchain-funcs > pentoo/sys-cluster/openmpi/openmpi-1.3.3.ebuild:inherit eutils multilib > flag-o-matic toolchain-funcs fortran > pentoo/sys-cluster/openmpi/.svn/text-base/openmpi-1.3.3.ebuild.svn-base:inherit > eutils multilib flag-o-matic toolchain-funcs fortran > science/sci-libs/libxc/libxc-1.0.ebuild:inherit fortran multilib > science/sci-libs/libxc/libxc-.ebuild:inherit fortran eutils multilib > toolchain-funcs flag-o-matic autotools subversion > sunrise/media-radio/wspr/wspr-2.00.ebuild:inherit autotools distutils > flag-o-matic multilib python fortran > sunrise/media-radio/wspr/.svn/text-base/wspr-2.00.ebuild.svn-base:inherit > autotools > distutils flag-o-matic multilib python fortran > > mozconfig-2 : > maggu2810-overlay/www-client/flock/flock-1.0.1.ebuild:inherit > flag-o-matic toolchain-funcs eutils mozconfig-2 makeedit multilib > fdo-mime mozextension autotools > > php-pear-r1 : > funroll-loops/dev-php/PEAR-XML_RPC/PEAR-XML_RPC-1.5.4.ebuild:inherit > php-pear-r1 > funroll-loops/dev-php/PEAR-XML_RPC2/PEAR-XML_RPC2-1.0.6.ebuild:inherit > php-pear-r1 > kolab/dev-php/Horde_NLS/Horde_NLS-0.0.2.ebuild:inherit php-pear-r1 eutils > kolab/dev-php/Horde_NLS/.svn/text-base/Horde_NLS-0.0.2.ebuild.svn-base:inherit > php-pear-r1 eutils > kolab/dev-php/PEAR-Net_IMAP/PEAR-Net_IMAP-1.1.0_beta1.ebuild:inherit > php-pear-r1 eutils > kolab/dev-php/PEAR-Net_IMAP/.svn/text-base/PEAR-Net_IMAP-1.0.3-r2.ebuild.svn-base:inherit > php-pear-r1 eutils > kolab/dev-php/PEAR-Net_IMAP/.svn/text-base/PEAR-Net_IMAP-1.1.0_beta1.ebuild.svn-base:inherit > php-pear-r1 eutils > kolab/dev-php/PEAR-Net_IMAP/PEAR-Net_IMAP-1.0.3-r2.ebuild:inherit > php-pear-r1 eutils > kolab/dev-php/Horde_Auth/Horde_Auth-0.1.1.ebuild:inherit php-pear-r1 eutils > kolab/dev-php/Horde_Auth/.svn/text-base/Horde_Auth-0.1.1.ebuild.svn-base:inherit > php-pear-r1 eutils > kolab/dev-php/Horde_LDAP/Horde_LDAP-0.0.2.ebuild:inherit php-pear-r1 eutils > kolab/dev-php/Horde_LDAP/.svn/text-base/Horde_LDAP-0.0.2.ebuild.svn-base:inherit > php-pear-r1 eutils > kolab/dev-php/PEAR-CodeSniffer/.svn/text-base/PEAR-CodeSniffer-1.1.0.ebuild.svn-base:inherit > php-pear-r1 > kolab/dev-php/PEAR-CodeSniffer/PEAR-CodeSniffer-1.1.0.ebuild:inherit > php-pear-r1 > kolab/dev-php/Horde_Kolab_Filter/Horde_Kolab_Filter-0.1.3.ebuild:inherit > php-pear-r1 eutils > kolab/dev-php/Horde_Kolab_Filter/.svn/text-base/Horde_Kolab_Filter-0.1.3.ebuild.svn-base:inherit > php-pear-r1 eutils > kolab/dev-php/Horde_Date/.svn/text-base/Horde_Date-0.1.0.ebuild.svn-base:inherit > php-pear-r1 eutils > kolab/dev-php/Horde_Date/Horde_Date-0.1.0.ebuild:inherit php-pear-r1 eu
Re: [gentoo-dev] Git commit mails/CIA.vc notifications
On Fri, 04 Feb 2011 03:26:16 +0100 Christian Ruppert wrote: > Hey guys, Only half of people? :) jer
[gentoo-dev] Re: Unused eclasses
Il giorno mar, 01/02/2011 alle 19.57 +0100, Tomáš Chvátal ha scritto: > > ruby-gnome2.eclass Please proceed, it'll be a while before gems.eclass is removed but at least this one can be killed now. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] Unused eclasses
On 02/01/11 19:57, Tomáš Chvátal wrote: > Hello ladies, > Following cleanup of eclasses in main tree there still are few eclasses > that are not used at all. I guess that applies to the main tree. If we do care if any of them are used in an overlay, Ycarus of gpo.zugaina.org may find an answer rather quickly. > I would like to ask you to reply to this mail that you want them to > survive or I will just mark them as @DEAD in 30 days and remove from the > tree in another 30. > > The list of sad lonely things: > eclipse-ext.eclass > fortran.eclass > games-q3mod.eclass > mozconfig-2.eclass > mozreconf.eclass > php-pear.eclass > php5_2-sapi.eclass > poppler.eclass > ruby-gnome2.eclass > tla.eclass > > > Cheers > > Your favorite treecleaning gremlin
Re: [gentoo-dev] Git commit mails/CIA.vc notifications
Ah, btw. it is also possible to exclude files from commit mails/cia. This is useful for e.g. Manifest files. I'll try to enable it by default for gentoo overlays. -- Regards, Christian Ruppert Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 signature.asc Description: OpenPGP digital signature
