Re: [gentoo-dev] Re: ecompress heads up
On Fri, 2007-01-26 at 19:56 -0600, Ryan Hill wrote: Mike Frysinger wrote: On Friday 26 January 2007 17:19, Mike Frysinger wrote: i purposefully choose to not go this route because i dont want to start adding handling for arbitrary compression types ... when such a list exists, we always get people who want use to add support for their $favorite-compression that said, i would entertain the notion of auto uncompressing just .bz2, .gz, .Z and telling everyone else to toss off ... What about .zip? Not apart of the base-system. *runs away* -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] It is Bugday time once again!
Hi All! In one week it will be time for our monthly Bugday event! This is a reminder for you to buy your girlfriend some flowers, pay your parents to clean your room and make sure you have power for the computer and the net cable is plugged in! Join #Gentoo-Bugs on the Freenode IRC network and help us make Gentoo the best distribution ever! You can hang out; learn from others and try to fix as many bugs as possible. As usual a big team of developers will be there to assist you if you have any questions! Feel free to contact me directly if you have any questions about the Bugday event :) Remember, February the third is reserved for Bugday -- No matter what! Best regards, Alexander -- Alexander Færøy Bugday Lead Alpha/IA64/MIPS Architecture Teams User Relations, Quality Assurance pgpqpjtMdbnqg.pgp Description: PGP signature
[gentoo-dev] Last rites: www-client/mozilla[-bin]
# Raúl Porcel [EMAIL PROTECTED] (27 Jan 2007) # Masked for removal 26 Feb 2007, bug 135257, security issues # Replaced by www-client/seamonkey[-bin] www-client/mozilla www-client/mozilla-bin -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites: www-client/mozilla[-bin]
Raúl Porcel wrote: # Raúl Porcel [EMAIL PROTECTED] (27 Jan 2007) # Masked for removal 26 Feb 2007, bug 135257, security issues # Replaced by www-client/seamonkey[-bin] www-client/mozilla www-client/mozilla-bin How about not breaking the tree? !!! All ebuilds that could satisfy www-client/mozilla have been masked. !!! One of the following masked packages is required to complete your request: - www-client/mozilla-1.7.13 (masked by: package.mask) # Raúl Porcel [EMAIL PROTECTED] (27 Jan 2007) # Masked for removal 26 Feb 2007, bug 135257, security issues # Replaced by www-client/seamonkey[-bin] Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: GIT vs? SVN (was: Re: Re: [RFC] Some sync control)
Ned Ludd wrote: On Thu, 2007-01-25 at 23:37 +0100, Markus Ullmann wrote: So to avoid thread hijacking, starting a new one. What exactly is this thread you are starting about? Just letting us know you did some random testing? I think this is a reference to news:[EMAIL PROTECTED] where I was asking about what would be a good distributed scm. Thanks for testing jokey. There was a massive thread on the git/bzr lists which marienz pointed out, which has TBH given me a massive headache ;) The gist of what I read was that both use UUIDs, but bzr leans towards local rev ids for styles of development where full distribution is not required (ie star topographies.) Additionally, bzr makes a new rev every time there is a merge, even if nothing has changed. I like the bzr approach of providing a framework, but I guess I'm still leaning towards git, as I'm not really after a framework per se. So it's good to know you can set up a repo which will commit to a svn parent. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] DB vs SCM (was Re: [RFC] Some sync control)
Hi, Since this is a different question which got buried in the other discussion, I appreciate it should be a new thread: I'm a bit confused about all the portage tree stuff. There's just under 25,000 ebuilds, which are maintained by about 100 devs (not sure of exact number, taken from a forum post.) I guess what I'm asking is why this isn't just a database. Please note, I'm not talking about applications like portage or pkgcore, just the ebuild text files, which I understand have one maintainer? I appreciate that source control is needed to maintain files over a period of time and to roll back changes. Does that happen with ebuilds? I'm thinking in any case that a db app can save old revisions or use a svn backend. I'm looking at this from a workflow perspective, in terms especially of the security issue around giving commit access to the whole tree. If the individual maintainer only has permission for those ebuilds s/he is responsible for, it might make it easier to allow new people write access. Sorry if this has all been discussed before. (Please note: I'm not discussing the mechanisms by which software might be installed for the end-user, rather the back-end which you devs use, of which I admittedly have no experience.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] DB vs SCM (was Re: [RFC] Some sync control)
Steve Long wrote: Hi, Please note, I'm not talking about applications like portage or pkgcore, just the ebuild text files, which I understand have one maintainer? Many ebuilds are in maintained by a bunch of people via herds. I appreciate that source control is needed to maintain files over a period of time and to roll back changes. Does that happen with ebuilds? Rolling back changes does not happen that often but a history is useful. I'm thinking in any case that a db app can save old revisions or use a svn backend. I'm looking at this from a workflow perspective, in terms especially of the security issue around giving commit access to the whole tree. If the individual maintainer only has permission for those ebuilds s/he is responsible for, it might make it easier to allow new people write access. I fail to see any benefit from a layer above svn. svn has good access control if we want use that built in. Sorry if this has all been discussed before. Most likely the access control has been discusses some times before. To summarize having access to everything is quite useful. (Please note: I'm not discussing the mechanisms by which software might be installed for the end-user, rather the back-end which you devs use, of which I admittedly have no experience.) So please let people who actually use/know how source control work discuss the issue. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] DB vs SCM (was Re: [RFC] Some sync control)
On Sat, 27 Jan 2007 13:11:07 + Steve Long [EMAIL PROTECTED] wrote: Hi, Since this is a different question which got buried in the other discussion, I appreciate it should be a new thread: I'm a bit confused about all the portage tree stuff. There's just under 25,000 ebuilds, which are maintained by about 100 devs (not sure of exact number, taken from a forum post.) I guess what I'm asking is why this isn't just a database. Please define database. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] DB vs SCM (was Re: [RFC] Some sync control)
Steve Long wrote: I'm thinking in any case that a db app can save old revisions or use a svn backend. I'm looking at this from a workflow perspective, in terms especially of the security issue around giving commit access to the whole tree. If the individual maintainer only has permission for those ebuilds s/he is responsible for, it might make it easier to allow new people write access. The idea of restricting access to specific parts of gentoo-x86 has come up many times. It doesn't fix anything and actually makes some things worse. Committers still have access to wherever they can commit, so they can work whatever evil they want there without needing the rest of the tree. If we trust people to commit anywhere, we should trust them to commit everywhere. If we don't trust them to commit, why do they have commit access? This implies a basic lack of trust within our development team, which means it can never be a true team. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] matrox.eclass
Hi,
besides a deprecated call to check_KV, matrox.eclass sets
SLOT=${KV}
which breaks the metadata cache. Any objections to change it
to
SLOT=0
anyone?
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GPL-2 vs GPL-2+
Diego 'Flameeyes' Petten wrote: What I propose is to copy licenses/GPL-2 to license/GPL-2+ and adding the following notes at the start of the two files: GPL-2: Note: this license states that the software is licensed under GNU General Public License version 2, and you might not be able to consider it licensed under any later version. GPL-2+: Note: this license explicitly allows licensing under GNU General Public License version 2 or, at your option, any later version. Was there ever a consensus on this? I think it's an important issue and am willing to help with an audit. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] matrox.eclass
Danny van Dyk napsal(a): which breaks the metadata cache. Any objections to change it to SLOT=0 As noted on the relevant bug [1], the eclass is a complete no-op and nothing can be installed using this eclass (has been so for quite some time). Fixing it doesn't make sense, making it dummy or even removing it (plus the unusable single ebuild which inherits it) does. [1] http://bugs.gentoo.org/show_bug.cgi?id=162960 -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] matrox.eclass
Jakub Moc wrote: Danny van Dyk napsal(a): which breaks the metadata cache. Any objections to change it to SLOT=0 As noted on the relevant bug [1], the eclass is a complete no-op and nothing can be installed using this eclass (has been so for quite some time). Fixing it doesn't make sense, making it dummy or even removing it (plus the unusable single ebuild which inherits it) does. [1] http://bugs.gentoo.org/show_bug.cgi?id=162960 And we already told you, removing it isn't a good solution (even if it technically works within the bounds of the current api). The bug is that the SLOT invalidates cache entries and it's trivial to fix. -- gentoo-dev@gentoo.org mailing list
