[gentoo-dev] Packages formerly maintained by myself
The following packages are now maintainer-needed, if anyone wants to pick them up feel free to do so. app-mobilephone/x70talk app-admin/flexlm app-misc/scope app-misc/linuxspa sys-devel/bin86 sys-devel/dev86 sys-apps/yum sys-boot/raincoat sys-boot/cromwell-bin sys-boot/cromwell app-emulation/domi net-fs/ccxstream sci-electronics/balsa sci-electronics/gplcver sci-electronics/petrify app-cdr/extract-xiso app-cdr/xdvdfs-tools -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for August
Hi, On 03/08/06, Lance Albertson [EMAIL PROTECTED] wrote: You have no concept of where the bottle neck is. The webserver hosting the cgi part isn't being loaded hardly at all. The database server is a pretty beefy box, and again, its not so much a specific hardware limitation, just more a limitation on the design of bugzilla and its ties to mysql. We're having to 'fix' the problem by getting a master/slave mysql db server setup which the OSL didn't have setup at the time. This is apparently the 'solution' upstream suggests which I think is daft, but its what we have to do. I'm curious what the problem is with bugzilla and it's db interactions? You're suggesting a specific issue rather than general db performance issues like fs, io scheduling, raid1, hyperthreads, etc.? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo activity graphs
On 07/07/06, Alin Nastac [EMAIL PROTECTED] wrote: I am aware those characteristics are quantitative and don't say anything about the quality of the distribution. However, judging after those graphs, even the worst basher will recognize that we are far from being dead. It may be a better metric to look at the bugzilla stats. How has the number of bugs being filed changed? What ratio of filed bugs are resolved, vs the ones that are left open? bugs.gentoo.org has some facilities for graphing stats back to December 2005... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Virtualization Herd
On 03/07/06, Benedikt Böhm [EMAIL PROTECTED] wrote: On Monday 03 July 2006 21:56, Nick Devito wrote: Okay, in that case, extend the vserver herd to include a larger range of virtualization stuff, including Xen, Bochs, and so on. It just seems more fitting to group those packages together. not really, bochs, qemu and vmware is emulation, merely used in virtualization environments Qemu (with the kqemu module) and vmware both directly execute the native bytecode. Bochs is the only real emulator. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
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. 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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On 09/06/06, Edward Catmur [EMAIL PROTECTED] wrote: And what if they do know what they're doing, and what they're doing is subverting Gentoo systems en masse? You're proposing to hand out commit access to anyone who makes a case on IRC; you have no way to tell that they aren't an attacker. This is the way the system currently works. I'm sure any decent motivated hacker would be able to fix a few ebuilds, hang out on irc, do the quiz, and gain cvs commit access. There are no identity checks when you become a gentoo developer; it's all about reputation. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
On 08/06/06, Matteo Azzali [EMAIL PROTECTED] wrote: Hum, maybe my little english is not good to explain my thoughts. I already have a /usr/local/portage overlay bigger than 500Kb. I can beat that, try 23MB :-/ Anyway, back to your point - yes, there are lots of bugs with patches attached that aren't being added to the main tree. And there are lots of bugs where the ebuild or fix is ending up in an overlay rather than the main tree. It's getting complicated to keep track - all I can really advise is that if you'd like to see fixes and ebuilds being added to the main tree, then become a developer and start doing it (although it is complex for something like gcc compile fixes which are spread across packages owned by multiple developers who will get upset if you touch their package). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
On 30/05/06, Mark Loeser [EMAIL PROTECTED] wrote: Basically, it would be something that allowed you to browse the current tree of submitted ebuilds. This way users that submit something can categorize it for devs to easily look for ebuilds they may be interested in, and we can make it so we could easily grab the ebuilds from this hacked up idea of a tree. Hmm something like a tree, containing ebuilds, that people can check out and browse... :) Comments on this idea are appreciated. I wouldn't mind helping write it and maintain it, but having interest and support in doing something like this is definately going to be needed :) The idea of an unmaintained tree has come up before and been shot down because (paraphrasing) 1. nobody will check the ebuilds 2. nobody will maintain it 3. nobody will bother marking stuff stable and 4.it will be a security nightmare. Personally I think it would be fun to just throw open the gates and have an open git (or other dscms) no-guarantees repository that pulls from the main tree every day, and which anyone with an email address can sign up for and then push their own stuff to. Or maybe some wiki-frontend to a branch of the portage tree. Yeah there would be some security issues and vandalism just like any open content system. Nevertheless, It would be a very interesting experiment in opening ebuild development and maintenance to a larger audience. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 49 - take 2
On 22/05/06, Thomas Cort [EMAIL PROTECTED] wrote: Since Gentoo will never depend upon a piece of non-Free software[1], it is safe to assume that the package manager is Free software (aka open source). Because of this, we will never be locked-in, helpless, or under the control of an external project. If we dislike the direction in which it is going or want to add our own features, then we are free to do so either by submitting patches upstream, adding our own custom gentoo patches to the stock sources, or by forking the project entirely. Exactly. It's the license that matters. By the definition some people have used, Gentoo has no full control over the kernel, gcc, glibc, or python, and yet still depends on them. While it might hurt some people's pride to have a non-Gentoo controlled package manager, it really is no different to Ubuntu using apt. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 49 - take 2
On 22/05/06, Paul de Vrieze [EMAIL PROTECTED] wrote: There are serious costs involved with forking something. For gentoo this would include image problems by being seen as evil forkers. Surely such decisions should be based on technical merit, and not political? The technical cost of forking is small. Also mandriva, suse, ubuntu etc. distinguish themselves from the pack in which packages are offered in which configuration. Gentoo differs from that in that users can determine the configuration. The package manager directly influences the freedom available for the users. Making binary and source distros not easilly comparable. I'm not sure I follow this line of reasoning - other distros can have external package managers because their users have less freedom? Are you concerned about the political effect of there being less to distinguish Gentoo from clones, or the fact that an external package manager might somehow seek to limit users freedom to determine configurations? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Signing everything, for fun and for profit
On 20/05/06, Peter [EMAIL PROTECTED] wrote: snip Thanks for the clarification. That scheme looks fine. The master manifest will add about ~700k to the tree, but since it can be rsynced the actual bandwidth usage day to day should be reasonable. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Signing everything, for fun and for profit
On 20/05/06, Peter [EMAIL PROTECTED] wrote: PMFJI, but as a user, not a security expert, I had a few thoughts that I'd like to throw in. Thanks to Patrick, he helped me to drill down some of the ideas and I present them for consideration. It's just a framework, so I will be brief Thanks for your input. From a security point of view your scheme is fine, but as pointed out by others you won't be able to selectively rsync parts of the tree. That will require a signature for each manifest, and a manifest for every directory. The problem I see is that the manifest is going to have to include a hash for each subdirectory - otherwise you open the possibility of someone replacing a directory with one from the past that contains some known insecurity, or corrupting the tree by swapping random directories, and yet the signatures remain valid. Of course, that hash changes if you allow people to rsync_exclude directories, and hence the signature changes. So you can either accept that if you selectively rsync then you won't be able to verify the signed tree, or accept that there is a known security problem with having no signed link between parent and child directories, or come up with a different scheme. Obviously the manifests also have to be checked to make sure they're valid - this is currently done for package directories at emerge time, it would need to be extended to all other directories. I'd prefer the checks done at sync time since that's a one time cost and you don't have to figure out exactly what files will be used by each emerge operation. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Signing everything, for fun and for profit
The only attack most people really care about is a compromised rsync server. There is no practical way to protect against the other attacks - and at the end of the day, if a developer gets compromised it doesn't matter whether it's a gpg key or ssh key, the effect is the same. The discussion about which files to sign is pointless - the extra computational cost of signing all files in the tree is insignificant, and how are we supposed to know how future tools will handle things like the licenses? Just do it properly now and sign every file. We already trust the master cvs server admins (and they could just replace the whole tree anyway), so what benefit does a distributed signing system like gpg actually give to the developers or users? I can't see any that are worth the costs of key management (and there are costs, otherwise a system would've been put into place years ago). So my simple proposal would be to use a single key, and a post-commit cvs hook to sign the whole tree. It takes me 1.5 seconds with gnupg to generate a signature covering the whole tree on my desktop here. I don't know how many commits per day there are (and maybe that would be reduced with an atomic commit system like svn), so I don't know if this is an acceptable cost. I think it probably is, but if not, then signing could be done per-directory. The benefits of this would be that changes are minimised - developers and users act the same, the impact on the tree is a 191 byte signature, and yet it will protect against the most likely and most practical form of attack. I was much more pro-distributed trust system in 2003 (or whenever this was last discussed), but I think the right solution now is the practical, easy to implement one.
Re: [gentoo-dev] Signing everything, for fun and for profit
On 19/05/06, Patrick Lauer [EMAIL PROTECTED] wrote:
On Fri, 2006-05-19 at 10:46 +0100, Chris Bainbridge wrote:
We already trust the master cvs server admins (and they could just
replace the whole tree anyway), so what benefit does a distributed
signing system like gpg actually give to the developers or users? I
can't see any that are worth the costs of key management (and there
are costs, otherwise a system would've been put into place years
ago).
No central authority -- no single point of failure
Give me a central server and I will focus on hacking that ... hacking 50
developers is much harder ;-)
There are now several hundred gentoo developers. It is more likely
that one of them has a security lapse than cvs.gentoo.org.
So my simple proposal would be to use a single key, and a post-commit
cvs hook to sign the whole tree. It takes me 1.5 seconds with gnupg to
generate a signature covering the whole tree on my desktop here. I
don't know how many commits per day there are (and maybe that would be
reduced with an atomic commit system like svn), so I don't know if
this is an acceptable cost. I think it probably is, but if not, then
signing could be done per-directory.
I don't see what that gains you ... what exactly does this signature
express?
and 1.5sec doesn't appear realistic to me, I'd expect it to take ~1
minute even on a fast system
It is a single signature across the entire portage tree. It means that
after rsync emerge can check the signature against the retrieved tree
to validate the whole tree (or overlay).
Instead of guessing performance, test it. We can assume that disk
activity is negligible - we have a dedicated server, and the portage
tree is ~115MB, so most of it will be cached in main memory. In
particular there is no disk seek latency. To simulate that we can
gather everything into a single file (which also has the side effect
of pulling into the cache) and then gpg sign that file:
find /usr/portage -path '/usr/portage/metadata' -prune -o -path
'/usr/portage/distfiles' -prune -o -path '/usr/portage/packages'
-prune -o -type f -exec cat {} /tmp/blah \;
time gpg --detach-sign -a /tmp/blah
I get 1.5 seconds on a desktop and 6.5 seconds on a laptop.
The benefits of this would be that changes are minimised - developers
and users act the same, the impact on the tree is a 191 byte
signature, and yet it will protect against the most likely and most
practical form of attack.
So ... DoS scenario
I just add one byte to the tree and the signature fails ... what then?
Emerge informs the user that the rsync server has been corrupted and
terminates. How would this be any different with distributed file
signing? You have to rsync the entire tree, and then verify it - at
that point the tree is already corrupt. Ideally overlayfs (or just
plain old keeping a backup) could be used to restore the pre-sync
tree.
I was much more pro-distributed trust system in 2003 (or whenever this
was last discussed), but I think the right solution now is the
practical, easy to implement one.
I think I'd prefer a hybrid.
It could be done in stages. Start with the (easier) central key, then
later add distributed keys. I think a hybrid system would be the ideal
system, but realistically, bug #5902 has been around since March 2003
and no real progress has been made. The main sticking point seems to
be disagreements over key management and policies. I would hope that
most people could agree that a single key with a post-commit signing
is better than what we have now, and could be easily implemented,
whilst leaving open the option of a hybrid system implementation at a
later date.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Signing everything, for fun and for profit
On 19/05/06, Andrew Gaffney [EMAIL PROTECTED] wrote: Chris Bainbridge wrote: It is a single signature across the entire portage tree. It means that after rsync emerge can check the signature against the retrieved tree to validate the whole tree (or overlay). This idea has been brought up before and shot down. Signing the whole tree does not work, since we allow users to only sync parts of the tree. We do? What option to emerge enables this behaviour? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Signing everything, for fun and for profit
On 19/05/06, Patrick Lauer [EMAIL PROTECTED] wrote: On Fri, 2006-05-19 at 15:13 +0100, Chris Bainbridge wrote: There are now several hundred gentoo developers. It is more likely that one of them has a security lapse than cvs.gentoo.org. One is a local bug, the other one global. I'd prefer a system that is resilient against two devs going crazy - right now the right persons could stage a manipulation that would be hard to detect and where your (single central) signature fails quite nicely. Realistically, you have to trust the gentoo devs. The only system that won't fail against the rogue developer threat is to have multiple sign-off on commits. Most developers don't want that. Even if it were required, it would only raise the bar slightly - all a rogue developer would have to do is to establish a new id, fix some bugs, and recruit themselves. It's very coarse - Yes / No Doesn't tell you what failed how ... so I DoS it by inserting one bit on any rsync mirror and it will fail. You don't know what fails where ... You can't upgrade and you don't know what fails where ... Right, but ... what caused the error? It doesn't matter which bit in which file was changed - if an attacker has access to corrupt the tree, then the whole tree is suspect and can't be trusted. From a users point of view - they don't care what caused the error, they just sync again with a different server.. From a developers point of view - you can just diff the corrupt server against your local tree and look for exploit code. It could be done in stages. Start with the (easier) central key, then later add distributed keys. I think a hybrid system would be the ideal system, but realistically, bug #5902 has been around since March 2003 and no real progress has been made. That bug appears quite unrelated to me ... how does FEATURES=userpriv relate to signing? #5902 is emerge security - running as root and digital signatures. Digital signatures have something to do with signing ;-) Actually, the bug has been open since August 2002... The main sticking point seems to be disagreements over key management and policies. I would hope that most people could agree that a single key with a post-commit signing is better than what we have now, debatable It's debatable that a centralised signing the tree is better than not having any security at all? and could be easily implemented, yes whilst leaving open the option of a hybrid system implementation at a later date. yes but that's not a cure. You'd have to sign _each file_ to get a reasonable tampering detection, or at least per-directory. You add a single point of failure and give attackers a high-profile target. It depends... what is the purpose of signing individual files? If it's to find the point of corruption, then you can just diff the corrupt tree against a good one and look for any exploit like code. Look at it this way - when emerge detects a corrupt tar.gz in distfiles, it doesn't tell you exactly what file in the package is corrupt. It just downloads it from someplace else. The same principle can be applied to the portage tree. I'm open to the possibility of signing every file/directory individually if there's a good reason, but I don't see one at the moment. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Signing everything, for fun and for profit
On 19/05/06, John Myers [EMAIL PROTECTED] wrote: On Friday 19 May 2006 08:17, Chris Bainbridge wrote: We do? What option to emerge enables this behaviour? RSYNC_EXCLUDES is the name, IIRC... Well, that would be incompatible with a single signature. I don't really see that point, but then I've been spoiled with broadband for years. Do we really have many users on dialup that it would inconvenience? Surely the massive size of the distfiles you have to download makes the impact of rsyncing the portage tree negligible compared to actually fetching everything you want to install? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Signing everything, for fun and for profit
On 19/05/06, Peter [EMAIL PROTECTED] wrote: Who signs the Manifests? Why are some unsigned? Is there a single Gentoo Security Key (like I know Slackware has and some other distros to ensure the authenticity of their files)? Individual developers sign the manifests with their own gpg keys. Some are unsigned because there is no policy or techical requirement for them to be signed, so many developers don't. There is no single Gentoo key. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: When will KDE 3.5 be marked as stable?
On 05/05/06, Jakub Moc [EMAIL PROTECTED] wrote: Philip Webb wrote: 060504 Chris Gianelloni wrote: If we followed others blindly, as so many users suggest, then we would have stabilized KDE 3.5 ages ago, and every single one of you KDE users would be complaining about how our QA sucks because KDE doesn't compile or breaks badly in so many places. This is rubbish: I'm now using 3.5.2 have had no problems whatsoever; nor did I have problems earlier with 3.5.0 3.5.1 . Oh, sure it's complete rubbish... there are only ~40 bugs open right now about KDE 3.5 (on a quick and definitely incomplete search). The fixed/upstream ones would definitely be well over 100, don't have any good query for that. http://tinyurl.com/rg55l But yeah, you know better, no problems whatsoever. :P KDE 3.4 has at least 31 open bugs on a quick and incomplete search. http://tinyurl.com/mzzoo -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Having fun with compression
On 30/04/06, Patrick Lauer [EMAIL PROTECTED] wrote: Hi all, I had this random idea that many of our distfiles are .tar.gz while more efficient compression methods exist. So I did some testing for fun: If you already have an old copy of the distfile it's much more bandwidth efficient to transfer deltas. Many Gentoo users rarely clean out /usr/portage/distfiles so it could be quite a bandwidth saving to use something like zsync http://zsync.moria.org.uk/ . I did some tests a long time ago and found that a version bump of a package like kdegraphics produced a 300k uncompressed diff, which was 25x more bandwidth efficient to transfer with rsync than to download the full bz2 file. I haven't played with zsync yet, but the technical paper suggests it is close to 'rsync -z' in terms of bandwidth efficiency, and it removes some of the drawbacks of rsync, such as high server load and the requirement to run a special daemon. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On 30/04/06, Henrik Brix Andersen [EMAIL PROTECTED] wrote: On Sun, Apr 30, 2006 at 12:50:45AM -0700, Donnie Berkholz wrote: While we're posting useful links, here's another one from the cairo project on switching from CVS to some distributed SCM: All this talk about switching to a more powerful SCM I can understand - but what would the purpose of switching the portage tree to a distributed SCM be? The main purpose that comes to mind is to help the groups working in overlays (layman -L shows 28 current overlays; there may be more). It should enable easier merging of trees, local tree management, sharing experimental changes between devs without commiting to the main tree, while still retaining the possibility of easily pushing changes back to the main gentoo tree. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Purpose of USE=doc
On 25/04/06, Jakub Moc [EMAIL PROTECTED] wrote: Hello here, I'd like to see some clarification of intended doc use flag usage, so that we wouldn't force users to download/install 40+ megs of docs for a ~3 meg package, with the only reason being that USE=doc is for developer documentation only. [1] The handbook states that doc is for package documentation. I've never heard of it being restricted to developer docs only, and if that's true, there are many packages which break that policy. As I always understood it, doc is there for all optional documentation such as manuals, APIs etc. Non-optional documentation would be things like online docs accessible from within the program (eg. help menu items for gui apps), which if missing generate run-time errors. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for dev-util/cccc
On 18/04/06, foser [EMAIL PROTECTED] wrote: On Sun, 2006-04-16 at 16:42 -0400, Mike Frysinger wrote: well the logical thing would be to go to bugzilla and search for ... and guess what ? no more open bug reports I already did that when I wrote it, actually there still is an open bug for it. So I guess you didn't actually go trough these proposed steps yourself. Anyway, it is completely besides the point, because you or anyone else won't check a week or a month from now if there's bug filed against , that is what maintenance is about. Are you suggesting that all packages with long standing open bug reports should be removed? There are thousands that fit that description. If not, then what is your definition of maintained? It could be argued that since Mike fixed the bug, it is maintained, even though he isn't the maintainer. Likewise, there are hundreds of packages that have a maintainer listed, or are assigned to a herd, where bug reports are essentially ignored. Should those also be removed? I mean, you aren't the maintainer. And there is still the outstanding issue that it is unmaintained in Gentoo, are you going to fix that or not ? Otherwise it should be masked and removed. this is the same argument as already made and rejected ... Where was this rejected and by whom ? By you I guess ? That just doesn't cut it, errors made in the past are no reason to make them again in the future. Did you read the previous discussion link I provided? The argument has been rejected in the past because it would lead to hundreds of otherwise working packages being removed. feel free to mask and remove the hundreds of other packages that have no maintainer So now we do have your blessing ? is then up for removal as of this moment. Maybe you aren't a native English speaker; it was clear from Mike's post that he would rather you didn't go ahead with removing hundreds of packages. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for dev-util/cccc
On 15/04/06, Mark Loeser [EMAIL PROTECTED] wrote: foser [EMAIL PROTECTED] said: I still say it should be removed in 30 days. I agree. There is a lot of stuff that suffers from being unmaintained, and I think we should strive towards cleaning that up. It helps no one if there isn't anyone to claim responsibility for the package when there is a problem. This discussion comes up every six months or so. See http://article.gmane.org/gmane.linux.gentoo.devel/32484 for the beginnings of a list of unmaintained packages... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] When will KDE 3.5 be marked as stable?
On 04/04/06, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: usable state-, KDE 3.5.1 was a bit better but stills some patches were needed, KDE 3.5.2 is in portage since less than a month, and already had a few patches with revbumps to few memleaks and crashes, a new kdelibs revbump is also planned, and umbrello 3.5.2 is regressed compared to 3.5.1 (that still, vanilla, wasn't usable for activity diagrams at all). Surely the question isn't whether the upgrade is perfect, but whether it's better than the current stable release? 'find /usr/portage/kde-base -name '*3.4.3*.patch' |wc -l' shows 15 patches, 3.5.1 has 11 patches, and 3.5.2 has 6 patches. (I realise that isn't a perfect patch count...) From the handbook: The use of ~arch denotes an ebuild requires testing. The use of package.mask denotes that the application or library itself is deemed unstable. As far as I can see the *ebuilds* for kde work fine. If the newer versions of kde have the problems you describe, then they should be package.masked. I think at this point it does more harm than good to be lagging behind the current upstream kde - last time I checked the kde bugzilla wouldn't even accept bug reports for the kde currently marked stable as it was too old, and if bugs can't be filed then it's clearly unsupported upstream and time to upgrade. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] overlay support current proposal?
On 27/03/06, Ryan Phillips [EMAIL PROTECTED] wrote: Aron Griffis [EMAIL PROTECTED] said: Have you followed the threads in the past regarding using other version control systems for portage? Some devs have done benchmarks and found that there are blocking issues with subversion, particularly because of its repo-wide revisions that prevent multiple commits from happening simultaneously. In actuality, Subversion does 98% of the commit in an initial transaction, and the blocking only occurs in the last 2% with the FSFS filesystem. It really isn't an issue and shouldn't prevent us from adopting it. All svn commits are atomic, and that requires some kind of global lock. I'd say the (slight) performance penalty is worth it for that feature alone. I'd also point out that the KDE project have everything in a single svn repository and can manage 10,000 commits per month with no problems. There are various testimonials around from people claiming to be running svn on multiple GB repositories with 17,000 commits a month. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Official overlay support
On 23/03/06, Stuart Herbert [EMAIL PROTECTED] wrote: The vision I have for overlays.g.o is one official home for all Gentoo overlays run by projects and by individual Gentoo devs. I see the Also for Arch/Herd Testers? The discussion seems to have moved from the original how can we become more open to enable our users to contribute? to how to provide testing overlays for existing gentoo devs. I think that the use of overlays is more a symptom of a problem with portage. Overlay problems: They remove ebuilds from the tree Users have to add yet another overlay / retrieve the ebuilds somehow Conflicts between overlays Increases time to moving packages into the tree Overlay becomes a developers personal space making it difficult to contribute if package is neglected (though that is also a problem now...) Lose repository metadata moving a package from overlay to tree Reduced responsibility for package QA (I expect we don't care about overlays to become a standard response on bugs.g.o) And what do we gain: Eases testing - can push in alpha quality ebuilds Developers feel safer because they can't break the tree Surely the solution is to provide that safety net within the tree? Rather than pushing changes into a live tree, push them into a testing tree, then after they pass repoman/QA checks, and a build check, apply the changes to the live tree, otherwise email a rejection. And allow developers to add their own testing ebuilds to the tree (for a start, they will be more widely tested). The current system of overlay usage is very annoying for users, particularly when bugs are hanging around with packages in the tree, and after filing bug reports the user is told that the bug is already fixed in the overlay. Or when new packages are added to overlays instead of the tree. How are users expected to find them? Another thing that needs fixing is the massive number of packages that aren't really maintained. Either the maintainer doesn't respond to bugs, or the package is maintained by a herd and so no one feels it's actually their responsibility to deal with the boring bugs, and when some developer outside of the herd comes across it, they feel like they can't fix the bug without stepping on someone's toes. What's worse is that in a lot of these cases there will be a user on bugs.g.o posting fixes and new ebuilds, and yet they never make it into the tree. A system where developer ebuilds are kept in the tree, and users have a way to automatically contribute ebuilds, either human reviewed, or in some reputation based system, would be very useful. Users also need feedback - how many times does a user submit an ebuild via bugzilla to be told that it doesn't meet QA standards? Why isn't there a system in place to run repoman/QA/build checks on user ebuilds/patches to make sure they are fixed *before* being submitted for inclusion into the tree? And if this could be linked to a bug reporting system where people report/fix individual ebuilds or packages, and I can just type 'gbugs -l pkgname' and get a list of problems and fixes that other people have proposed, even better. I'm not sure whether the answer is more openness of the existing system, some custom submission flow system, or a distributed SCM, but I do think there's a lot that could be changed to make things better. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Official overlay support
On 23/03/06, Stuart Herbert [EMAIL PROTECTED] wrote: Developers are already using overlays, and some teams (including ones I've been involved in) are actively and successfully using them to help with recruitment and to provide a way to access ebuilds that would otherwise still be rotting in Bugzilla. Developers are using overlays, however, the majority of users aren't. If the usage of overlays is to increase, then remote overlay support should be added to emerge. Additionally, in order for users to be able to contribute to the overlays, it would help if they had anonymous read access. Surely the solution is to provide that safety net within the tree? I cannot imagine a day when non-devs are given commit access to the Portage tree. As long as that limitation remains in place, if we're going to reach out beyond our developer community, we have to reach out beyond the Portage tree too. The safety net was intended for developers. Packages often get broken in unexpected ways - something depends on it, a patch is conditional on some USE flag or arch etc. It would be useful to get an email 5 minutes after a commit saying you broke something, rather than a bug report being filed a week later. The current system of overlay usage is very annoying for users, particularly when bugs are hanging around with packages in the tree, and after filing bug reports the user is told that the bug is already fixed in the overlay. Or when new packages are added to overlays instead of the tree. How are users expected to find them? Users have pre-conceived ideas about the contents of the Portage tree. I've seen first-hand how badly users react when a hard-masked package in the tree is withdrawn because it was an experimental approach that ultimately failed. Users have unrealistic expectations about the tree. I don't think it is unrealistic to expect that if a user puts a lot of work into an ebuild, and it works, then it should somehow end up in the tree. Unfortunately the options at the moment are to either reject the ebuild, leave it to rot in bugzilla, or recruit the user as a developer. Rejecting isn't very nice, the amount of effort and barriers to become a dev are too great, so we end up with good ebuilds not being added. Adding the ebuilds to overlays is one option, but then other users will be expected to find an overlay with their package in, and then add it to make.conf. As the number of overlays increases, the amount of effort in synchronising dependencies and dealing with other problems between them will increase. Maybe in the real world managing the relationships between overlays won't be as big a problem as it appears it could be. [snip] You have good ideas. What are you doing to make them happen? Not much - time is a great constraint, and writing emails takes much less time than writing code... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Official overlay support
On 23/03/06, Chris Gianelloni [EMAIL PROTECTED] wrote: On Thu, 2006-03-23 at 14:41 +, Stuart Herbert wrote: Your nightmare scenario seems unavoidable. Enabling per-overlay bug tracking doesn't stop users posting bugs in bugzilla. It just causes confusion for users, because they're not sure where to go. Normally, it's not a problem - because the overlay contributors are normally the owners of the real package. No, it does not stop them, but it sure will curb the number of users posting their bugs to the wrong place. Remember that only more advanced users are the ones using overlays. We won't have Joe Sixpack using an overlay. Instead it'll be Bob Developer-to-be. If the software a user wants is in an overlay, then the user will be forced to install the overlay. Another thing that some people may not have considered - with many developers using various permutations of overlays, how can you guarantee that what is being checked into the main tree will build for a normal user? In order to test that, a developer would have to disable all overlays, unemerge everything provided by the overlays, and then build and test with a plain non-overlay gentoo. That's a lot of work; I doubt most developers are doing it. There is a discussion on the forums at the moment along a similar topic http://forums.gentoo.org/viewtopic-t-443469.html - the vote seems to indicate 58% of users are not really happy with the way the portage tree is handled. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Official overlay support
On 23/03/06, Rumen Yotov [EMAIL PROTECTED] wrote: Hi, Using a remote overlays is rather simple, just do emerge layman. Read the einfo and then man layman. It works flawlessly, just tested this with one remote overlay. Beside that man layman explains pretty much of it's innerwork. PS:There's an article in gentoo-wiki.com with a list of overlays. HTH.Rumen What is the status of those overlays? I believe the php, webapps, and java ones (at least) are official (in that they're run by gentoo devs) and bugs are to be reported to bugs.g.o, no? But the wiki page http://gentoo-wiki.com/Portage_Overlay_Listing says NEVER report bugs at bugs.gentoo.org for these ebuilds. So where should users report bugs? And how are they to know that? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] last rites for dev-libs/btparse
On 31/12/05, Carsten Lohrke [EMAIL PROTECTED] wrote: It's - broken Works for me, and I can't see any bugs in bugzilla? - dead upstream Not true, mailing list is active, last post Dec 27th, and the author responds to emails. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
On 19/12/05, Peter Johanson [EMAIL PROTECTED] wrote: Or maybe not, I dunno. The point being I don't think we should immediately write off any of the distributed SCMs without pondering how they might make a difference or be usable. It would be very useful for people who aren't devs but only if they have access to the repository. It would also be useful for devs to have a standard way of publishing their testing/development portage overlays. On the first point, would any of the alternative SCMs prove to be better than CVS resource wise for providing anonymous access to users? It might also be useful to facilitate non-devs contributing patches to the tree - rather than posting files into bugzilla they could point towards whereever they publish their current tree (or changes), and developers can then work with their changes directly instead of the bugzilla upload/download dance we do now. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for media-video/dvdrip
On 08/12/05, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: Another package is taking a long long way that goes out of portage. I'm running out of openings for these mails, you know? Alternative dvd-ripping software is present in portage, starting from mencoder and its frontends, and they usually works better (look at winki for example). Er, isn't dvdrip the most popular ripping software on Linux? I haven't even heard of winki.. stable version is only 0.3.2 and it's described on it's homepage as alpha software. It seems a bit premature to remove dvdrip. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] grub reiser4
On 03/10/05, Mike Doty [EMAIL PROTECTED] wrote: I'd prefer if the patch was left out for amd64 users, or included via a use flag. reiser4 isn't yet stable or proven on amd64. A quick search found this quote: The topic in channel #gentoo-amd64 on irc.freenode.net has said Reiser4 is evil for more than a year. However http://gentoo-wiki.com/HOWTO_AMD_64 and the forum threads it links to seem to suggest that people are successfully using reiser4 on amd64 with recent kernels? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: grub reiser4
On 02/10/05, R Hill [EMAIL PROTECTED] wrote: The grub maintainer's stance was that reiser 4 support would not be included in grub until it was included in gentoo-sources, not any kernel in portage. The grub maintainer has been AWOL for the last 9 months or so however, so i guess it's now up to the base-system herd. I was under the impression that feature-adding patches should be sent upstream. I still think it's retarded to have a reiser 4 boot partition, but whatever stirs your pot. ;P It makes sense if you're actually using reiser4 for everything else. Why bloat your kernel with an extra FS just for /boot? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: grub reiser4
On 02/10/05, Alec Warner [EMAIL PROTECTED] wrote: Chris Bainbridge wrote: On 02/10/05, R Hill [EMAIL PROTECTED] wrote: I still think it's retarded to have a reiser 4 boot partition, but whatever stirs your pot. ;P It makes sense if you're actually using reiser4 for everything else. Why bloat your kernel with an extra FS just for /boot? Because most people want a tried and true fs on /boot, because if that tanks your system doesn't boot. I'm not trying to bash reiser here, I still use ext2 on /boot even if xfs is my main fs of choice for this reason. Being able to boot a kernel isn't much use without a root fs. If I can't boot, I have a livecd sitting on my desk. I guess if I had a ramdisk on /boot with a shell and some recovery tools then I might care, but I don't. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: grub reiser4
On 02/10/05, Dan Meltzer [EMAIL PROTECTED] wrote: On 10/2/05, Chris Bainbridge [EMAIL PROTECTED] wrote: On 02/10/05, Alec Warner [EMAIL PROTECTED] wrote: Chris Bainbridge wrote: On 02/10/05, R Hill [EMAIL PROTECTED] wrote: I still think it's retarded to have a reiser 4 boot partition, but whatever stirs your pot. ;P It makes sense if you're actually using reiser4 for everything else. Why bloat your kernel with an extra FS just for /boot? In addition, why bloat your fs by having a journaled filesystem for essentially static files? Because it's easier to have a single fs for / than have multiple partitions, and try to isolate all of the things that are essentially static and move them over to unjournalled file systems. Journalling operations on /boot are responsible for filling a very, very small percentage of my hard disk. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] grub reiser4
Hi, I was wondering if there's any chance of having the reiser4 patch for grub (or even the whole grub-reiser4 distfile) added to the ebuild. There are various bugs where people have posted patches for 0.96x ebuilds which were never added and the bugs have been WONTFIXed or left dangling. I've been using grub+reiser4 for about 9 months now with no problems. The last reason I heard it wouldn't be added was that no kernels in portage support it; I believe that's not true anymore, at least mm-sources has reiser4. Thanks, Chris -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] why does gcc-3.4.x depend on gcc-3.3.x / libstdc++?
Subject says it all - is there any reason why 3.4.4 installs either gcc-3.3* or libstdc++-v3 built with gcc-3.3? Is it possible to compile a native 3.4 system without the old gcc if I don't need binary compatibility? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Keys and words: ways to fail your team
On 28/06/05, Ilya A. Volynets-Evenbakh [EMAIL PROTECTED] wrote: Peter Johanson wrote: it wasn't even *him* who introduced the keywords in question, he did a by the book bump moving arch - ~arch for all arches listed in keywords. Book in question sort of presumes that ones who change keywords *personally* tested that package in question works. Really? I thought the policy was When upgrading, drop all existing keywords from arch to ~arch, and leave any existing ~arch keywords intact.. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Panda 3D licensing issues
On 17/06/05, Joshua Baergen [EMAIL PROTECTED] wrote: An electronic copy of the source code for all modifications made to the Software are to be forwarded to Licensor at [EMAIL PROTECTED] within 90 days of the date of the modifications. I didn't notice anything in the license that says they'll reject changes. I bet they just want to benefit from the open-source community without looking around themselves. Yup. One of the GPL avoidance techniques I've seen is to distribute software to a customer whilst making it clear that if they ask for the source they will lose support and updates. The idea of enforcing redistribution in stronger terms than the GPL isn't new - the Affero GPL uses similar terms to extend the GPL for network services. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] i have an idea ! (erescue)
I've been in this position more than once, and had to go through the bootcd+binaries (thanks to http://dev.gentoo.org/~avenj/bins/) restore. Argh. I've often thought that atomic updates and rollback within portage would be useful - maybe it could just be done as a layer over subversion for Gentoo updated binary packages. Or maybe rebuilding from source is preferable. Anyway, it would be very useful to be able to revert to a known good state with a single command. -- gentoo-dev@gentoo.org mailing list
