Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
On Sat, 2008-06-07 at 14:46 +0100, Alex Howells wrote: I agree with both of these and also think both agaffney and wolf31o2 would serve us excellently on Council. Consider them nominated too :) Thanks, but I no longer have the time nor the desire to dedicate to the Council. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Fri, 2008-06-13 at 11:14 +0100, Ciaran McCreesh wrote: But some EAPI-0 accepting Portage versions don't accept inline comments. Using inline comments in the tree will break those Portage versions. Yes, and EAPI=0 accepting Portage versions also didn't accept things like package.use and use.mask in the profiles, considering that EAPI=0 doesn't have a set definition and was based upon a particular portage version that did have the required support. So should we ban those from the tree, too? Oh yeah, PMS isn't approved, anyway, so there's no policy *at all* within Gentoo that denies a package manager from being used that doesn't conform to your idea of how things should work. This one's especially an issue when you consider how long it's been since Gentoo has released official stage tarballs... Wow. Your second stab at my team in 3 days, without me even responding. I should probably be blushing if it weren't for the fact that I really don't give a damn about you or anything that you say. Quite honestly, the same goes for pretty much anybody who works with you. You are a poisonous person to Gentoo and I sincerely wish that some day people around here will grow a pair and realize that your incessant self-absorbed bullshit simply isn't something we really want around here. I mean, we've already thrown out you and three of your cronies because your attitude sucks and you're all a pain in the ass to work with. What exactly do we need to do here? Ban you all? I find it massively amusing that most of the traffic on this list over the past 3 days has come from people that have been *FORCIBLY* removed from the Gentoo project. Oh yeah, don't bother responding to me. I've decided to put you and all of your little cohorts into my killfile so I no longer have to read your constant barrage of bullshit. Seriously, you're a complete fucking waste. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Fri, 2008-06-13 at 11:22 +0100, David Leverton wrote: PS: An example of something in PMS that is different from Portage: inline comments are disallowed. The only reason I can think for doing this is to not make Paludis change it's behaviour. Fortunately you don't have to think, you can just read Ciaran's explanation. Yes, because we all should stop thinking for ourselves and let Ciaran tell us what to think. After all, we all want to be like the cool Paludis developers. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Fri, 2008-06-13 at 12:22 +0200, Luca Barbato wrote:
David Leverton wrote:
On Friday 13 June 2008 11:10:46 Nirbheek Chauhan wrote:
Interesting to note, however, that Paludis doesn't accept inline
comments, and this behaviour predates PMS.
There's a reason for Paludis not accepting them, and the same reason
applies
to the question of allowing them in PMS or not, therefore PMS doesn't allow
them. There's no evil conspiracy here, just pure logic.
Care to share the logic and wise reasoning ?
[ ${IDEA_ORIGIN} != Ciaran ] die
--
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Fri, 2008-06-13 at 11:23 +0100, Ciaran McCreesh wrote: Did you check whether Portage that's included in current Gentoo releases supports inline comments in profiles? Yeah, the version in 2008.0_beta2 surely does. Perhaps you meant something else? Well, either that, or you're just posting more of your bullshit where you obscure or otherwise lie about the facts to suit yourself. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Fri, 2008-06-13 at 11:27 +0100, Ciaran McCreesh wrote: Well, then it should be updated to match current Portage behaviour. PMS is not supposed to document How portage worked at one point of time or The intersection of the capabilities of Portage and Paludis. It should follow the current portage's behaviour as closely as possible. Do you really want to make it impossible to install Gentoo using the most recent official release? Because that's what will happen if we do what you're suggesting... Considering that the most recent official release is 2008.0_beta2, I don't see where you have a point, at all. Sure, you're going to mention something about being labeled a beta, to which my response will be that you're simply backpedaling and changing the facts to suit your needs. After all, looking at /releases on the mirrors, I see a nice and shiny 2008.0_beta2 on all of the officially-supported arches. Isn't it about time that you gave up on your little mission to consistently undermine the hard work put in by a community of volunteers? Of course not... You need to stroke your ego some more. Pfft... -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Fri, 2008-06-13 at 12:44 +, Duncan wrote: Ciaran's right on this one. It may have been a bug in portage, now fixed, but at least until a stable current release media set, a working PMS can't change the EAPI-0 definition to fail with portage on the old release media, however stale it might be. If a current release happens before PMS EAPI-0 finalization, this could possibly be subject to debate, but until then, it just doesn't work, however much we might wish it could. No, he isn't. For one, we're talking make.conf, not the profiles. Second, there's a newer official (and stable) media set. Sorry if you don't like the beta moniker, which applies to the media set. After all, does a package suddenly become less stable because it is included in a tarball that has beta in the *FILE NAME* ? I don't think so. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Sun, 2008-06-15 at 15:50 +0100, Ciaran McCreesh wrote: Do you think that the differences between the proportion of patches from 'Paludis people' that are accepted or rejected and the proportion of patches from 'Portage people' or 'Pkgcore people' indicates a problem? Nope. What I see as a problem is that the primary author and current de facto maintainer is so much of an asshole that he was forcibly removed from the Gentoo project, which PMS is supposed to be written for, and has ostracized (at least) one of the package manager's development team with his constant not-so-subtle attacks. Quite frankly, I'd prefer see Gentoo take control over the specification that defines the most important single feature of Gentoo and remove the non-Gentoo developers from its development. No offense, but you're not a Gentoo developer any longer and you shouldn't have a say in how *we* manage ourselves. You're more than welcome to contribute code, fork, or whatever the hell you want. This is open source, after all, but that doesn't mean you should be allowed to hold the position of power over Gentoo that you've been granted. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Sun, 2008-06-15 at 16:04 +0100, David Leverton wrote: On Sunday 15 June 2008 15:42:28 Peter Volkov wrote: For example, currently, PMS team does not include anybody from portage team - official PM team and thus this team can't represent Gentoo interests. The Portage team is perfectly welcome to contribute if they wish. zmedico is on the alias, although he seems to have been focussing on working on Portage itself. genone, from what I've seen, seems to be indifferent at best to the idea of PMS. I'm curious as to why you think the actively contributing members of the PMS team aren't acting in Gentoo's interests, though. Maybe because they were booted from Gentoo for not acting in Gentoo's best interest? -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages broken by phase ordering change
On Sat, 2008-06-14 at 15:09 +0100, Ciaran McCreesh wrote: On Fri, 13 Jun 2008 21:55:29 +0200 Santiago M. Mola [EMAIL PROTECTED] wrote: As discussed in bug #222721, portage has changed the execution order of phases. It seems the change was introduced in portage-2.1.5 and it makes that, when upgrading a package, pkg_postinst is run after the old version has been removed. This breaks packages which use has_version in pkg_postinst to detect upgrades/downgrades. It can also break packages in more subtle ways. Given that the number of affected ebuilds is so high, I'd say Portage should have to revert the changes... Of course, you would. What else would we expect from you? This is an EAPI scope change, if anything. Although even then the implications are a bit messy since you're talking the interaction of two different EAPIs. It seems that everything these days is an EAPI scope change. That's not very useful for Gentoo, considering it's been quite some time since PMS was proposed and we've not seen approval for either EAPI=0 or EAPI=1 (or PMS, for that matter). What we have gotten is a half-assed you can use EAPI=1 in the tree to get these enumerated features from the Council, but that's nothing like acceptance of a spec. Perhaps if you spent a little more time doing something more constructive than being an asshat on the lists, PMS would have been approved long ago. Of course, that doesn't mesh well with your apparent need to be a complete dick to people, so continue on with the status quo. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] OT Foundation - Council was - Nominations for council
Can you take this off-topic thread to the appropriate list? I'm pretty tired with hearing the Foundation's self-promotional comments on how important it is to development on this list. You guys have your own list for that crap, as it is. Thanks, -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: lzma tarball usage
On Wed, 2008-05-07 at 16:23 +0300, Mart Raudsepp wrote: I do realize one would remove build-time dependencies and the toolchain on an embedded system on deployment anyway, but this means gcc USE=nocxx USE flag is pretty much useless, while it would be nice to use it to ensure that nothing sneaks in during development that depends on the C++ standard library easily instead of finding things break later. It's a pain in the ass for Release Engineering, too. At this point, we're looking into how we need to modify the bootstrap sequence to accommodate people using lzma for system (and lower) packages. http://bugs.gentoo.org/show_bug.cgi?id=220074 We're already getting reports of this due to someone deciding that it'd be a good idea to use lzma for our daily portage snapshots without any discussion here. Luckily, we still have the other tarballs to use, too. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] config_eth0 deprecated - new name?
On Wed, 2008-04-23 at 16:21 +0100, Roy Marples wrote: address_eth0? addresses_eth0? I think one of these two is the most obvious to people. Since most people will likely only have one address per interface, I'd say that address_eth0 sounds good. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Tue, 2008-04-22 at 08:09 +0100, Ciaran McCreesh wrote: We definitely don't want to install DEPEND at the pkg_* stages, so I'd say the requirement there, if you're asking, is prior to src_*, if that matters. If the alternatives are not being able to install from a binary at all due to circular dependencies, or being able to install from a binary using DEPEND to satisfy circular dependencies, which would you take? Given the trouble that we have every release with trying to cram everything our users want into a limited space, I'd rather the damned thing not install than pull in a bunch of packages we don't need, just to satisfy a dependency that isn't even used during execution of the package. I'd love to have some kind of functionality to allow some kind of optional dependencies. The only real way that I could see this working is if we tracked what was installed as an optional dependency, and not reinstall it if it has been removed the next time the depending package is merged. Sort of like what kdebuild has for suggested dependencies, but less strong? Pretty much, yeah. The main difference that I would see from the current *DEPEND variables, besides what was said above, would be that a lack of visibility wouldn't stop the package merge. If sys-apps/foo had ODEPEND=dev-libs/bar and dev-libs/bar was masked, it simply wouldn't be installed. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Sat, 2008-04-19 at 06:33 +0100, Ciaran McCreesh wrote: On Fri, 18 Apr 2008 22:27:21 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: My interpretation is pkg_* counts as runtime (I can imagine a package wanting to run itself at this point), so packages in RDEPEND should be usable at that point. Which would be fine, except it makes the tree unusable. Really, it seems to be an additional type of dependency that neither DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND idea isn't quite capturing it either. Yup, and for future EAPIs labels can fix this. But we have to have a sound solution for current EAPIs. I would agree that RDEPEND should likely be installed prior to pkg_preinst to satisfy the dependency. After all, PDEPEND is good enough for doing packages that aren't required at pkg_preinst/pkg_postinst. We definitely don't want to install DEPEND at the pkg_* stages, so I'd say the requirement there, if you're asking, is prior to src_*, if that matters. I'd love to have some kind of functionality to allow some kind of optional dependencies. The only real way that I could see this working is if we tracked what was installed as an optional dependency, and not reinstall it if it has been removed the next time the depending package is merged. Simple example: ODEPEND=video_cards_nvidia? ( x11-drivers/nvidia-drivers) would install x11-drivers/nvidia-drivers the first time it's ran with VIDEO_CARDS=nvidia, but if I removed x11-drivers/nvidia-drivers, it wouldn't get reinstalled. This would probably need some kind of --newuse like capability to allow for installing only *new* optional dependencies, but I think that the tracking would already allow that. The idea here would be to allow for installing recommended software along with others. We could even have --ask ask for the dependencies, since they are optional, after all. This way, we could ship a more robust configuration/setup for many popular applications without forcing software on people. It's an idea, anyway, and I hope that I didn't hijack the thread. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Early stabilisation
On Wed, 2008-04-16 at 11:49 +0200, Vlastimil Babka wrote: thirty days is the norm for the minimal period between an ebuilds last It is the norm. It is not a requirement. In fact, it is specifically a guideline rather than a hard rule. It is up to the maintainer's discretion when to ask for stabilization, just like it is up to the arch team's discretion when to actually *do* the stabilization. If you don't think that it's ready on your arch, say so, but be prepared to defend why you think so when the package maintainer, who should be much more familiar with the package, thinks that it is ready. On the other hand, maybe these early stabilisation bug reports are a sign of the times and we need to shorten the normal thirty day period, become even more of a cutting edge distro - or at least discuss the options. I'd say leave the current norm and smack the misbehaving maintainers :) Who says that they're misbehaving? Again, the maintainers probably know their packages better than anyone else, so why are we not trusting their judgement again? -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] New profiles
Please remember to sync gentoo-x86/profiles before doing any further commits. The new profiles need as much checking as possible. There have been several commits made by people who have masked things and such but forgot the new profiles. Also, if you make changes to any of the new profiles, please let me know so I can sync the changes into the snapshot tree. Thanks, -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 2008-04-03 at 13:49 +0200, Arfrever Frehtes Taifersar Arahesis wrote: If we used git, proxy maintaining would be easier. True, but with some acls we could also have a different model where people worked on parts of the tree and where commit privileges didn't pose so many security risks. With the current practice of doing work in overlays it would also be simpler to merge the work back into the Portage tree. Also Subversion would be sufficient. Release Engineering has been using subversion for the 2008.0 snapshot tree. The repository is running in tmpfs on a dual Opteron box. IT's still quite painfully slow. Of course, we're doing commits at the top-level since we have a single top-level ChangeLog for the repository, but we don't even have history. We literally just pulled ebuilds from the tree. Once the release is done, we can play around with the repository all that we want to get some real numbers, but unless there's some magic bullet that I'm missing, subversion might simply be too damned slow for our needs. As an anecdotal example, I've had a single commit of several profiles take up to 6 minutes to complete, and that's not with repoman or anything. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 2008-04-03 at 09:21 -0400, Richard Freeman wrote: Regardless, as long as devs actually follow policy I don't see any need to boot them. Maybe very long periods of inactivity should result in having accounts locked as a security measure (so that we don't end up with hundreds of ssh keys with commit access floating around who knows where). Booting out lots of devs just takes a limited set of resources and limits them further. If anything we want to find a way to let more people contribute in a significant way - not less... I think many people seem to forget that it isn't the number of developers or the number of commits. It is all about the amount of actual work that gets done. We need more work being done. Period. It doesn't matter how that gets accomplished, but it is what we need. Removing less active developers would be perfectly fine once we had a good proxy maintainer program in place that would allow people to contribute easily without having to have commit access. A developer who only commits rarely isn't any more valuable to Gentoo than a regular user who contributes at the same pace. The only difference is the commit access and the Gentoo resources used by the individual. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Help offered - Portage tree
On Thu, 2008-03-13 at 17:22 +0100, Fabio Erculiani wrote: [gio mar 13 2008] [02:54:56] lxnay agaffney: I don't think it's worth it wasting my time insulting you, I've something better to do [gio mar 13 2008] [02:55:07] agaffney lxnay: oh, burn! [gio mar 13 2008] [02:55:11] * agaffney cries in the corner [gio mar 13 2008] [02:55:40] lxnay what stupid are you Thanks for reminding me once again how you like to interact with the people that you're trying to help out. You wonder why people respond negatively to your demands and this is how you react to people. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Help offered - Portage tree
On Thu, 2008-03-13 at 17:48 +0100, Fabio Erculiani wrote: On 3/13/08, Chris Gianelloni [EMAIL PROTECTED] wrote: I'm a distro builder, too, and I haven't been hitting any of these problems. Would you care to point out the actual problems, or will the close to useless comment be our only indication of the perceived problems? Yeah, but IIRC you are a SOURCE distro builder. Arent't you? (I am just asking!) No. I build binary packages. Hell, catalyst uses the binary package support *heavily* for its caching. Do people really think that a pre-compiled stage tarball is source? How about a pre-compiled LiveCD? Anyone? -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Help offered - Portage tree
On Thu, 2008-03-13 at 14:48 -0400, Caleb Tennis wrote: As much as I hate to say it, your example was rather bunk, because openssl changed SONAME during that time. Keeping the package You're right here. After review, the problem was the difference between 0.9.8e and 0.9.8g, the latter of which provided some form of newer symbol that wasn't in e. But the concept is the same. Correct. That would not have been caught and would be an issue, still. Uhh... = in RDEPEND does that, already... Also, this wouldn't have resolved your openssl issue, at all. Your machine scenario above would have still failed, since the minimum version was 0.9.7 on your build host. I'm not talking about meeting the minimum required by the ebuild, I'm talking about the minimum that were installed at the time of the emerge. Well, I sincerely hope that you do not file such a bug, as it would royally screw over the one team in Gentoo that *does* consistently use our binary package support. I don't plan on filing the bug, but if it was an optional emerge option to use the actual version deps vs. the DEPEND of the ebuild, it wouldn't affect you would it? If it were optional, it wouldn't affect us. I'd have no issue with some kind of optional support for this sort of thing. I would definitely like to see the support improved, but not at the expense of doing very stupid things like locking to specific versions/revisions of packages. No offense, but that screams of RPM hell. I'm not trying to lock to any specific version. I'm trying to reproduce on machine 2 the same state of packages that package A was compiled against on machine 1. And even make it optional to do so, via an emerge flag. This is likely usually done by controlling the binrepo. At least, that's how I do it. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RE: Mesa on i965 (DRI)
On Thu, 2008-02-28 at 20:19 +0100, Mateusz Mierzwinski wrote: Ok, I've try i810 and... no DRI. Please take this off the general development mailing list and to one of the support lists, or, even better, to our bug tracker at http://bugs.gentoo.org instead. Thanks, -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: What is bump request?
On Tue, 2008-02-26 at 20:47 -0600, Ryan Hill wrote: Shaochun Wang wrote: I see the phrase bump request in bugzilla of Gentoo. What does it mean? A request to update the version of a package in portage to a later one, usually the latest released. It is also done by many people as an attempt to get the developer to look at an issue. This is usually done by people used to web forums, where things are sorted by the most recent and things disappear off the front page over time. Most of these people either do not realize that bugs do not act the same as a web forum, or they're simply rude and trying to tell the developer that they think that their issue is more important than others. ;] Generally, bump request means to bump the version of a package, whereas just bump is for bumping the thread... -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] MESA i965 SUPPORT PLEASE!
On Wed, 2008-02-27 at 20:11 +0100, Mateusz Mierzwinski wrote: Another day with non compatible DRI on X. After 3 days of discover I've saw that Xorg must be compiled with same NPTL flag setting as MESA but guess what? Someone don't insert i965 card from VIDEO_CARD variable but Mesa sources allready provide that card's drivers. If I want to install Mesa with i965 card support I must download source from www.intellinuxgraphics.com by git and compile it by myself. But what should I do if I cannot enable NPTL flag in make compiled source without ./configure script?. Better to add i965 to mesa VIDEO_CARD variable. I don't want to change compile profile to non-NPTL. This belongs in a bug report. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] MESA i965 SUPPORT PLEASE!
On Wed, 2008-02-27 at 20:11 +0100, Mateusz Mierzwinski wrote: Another day with non compatible DRI on X. After 3 days of discover I've saw that Xorg must be compiled with same NPTL flag setting as MESA but guess what? Someone don't insert i965 card from VIDEO_CARD variable but Mesa sources allready provide that card's drivers. If I want to install Mesa with i965 card support I must download source from www.intellinuxgraphics.com by git and compile it by myself. But what should I do if I cannot enable NPTL flag in make compiled source without ./configure script?. Better to add i965 to mesa VIDEO_CARD variable. I don't want to change compile profile to non-NPTL. Even better... i965 support is added by VIDEO_CARDS=i810 already. You don't need to do anything by hand... -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] clean deprecated eclasses(?) (was: missing quotes in eclasses)
On Thu, 2008-02-14 at 16:52 +0300, Peter Volkov wrote:
The check was done with the following script:
find /usr/portage \( -name '*.ebuild' -o -name '*.eclass' \) \
-exec awk /inherit.*[[:blank:]]+${eclass}([[:blank:]]+.*|$+)/{print FILENAME
} \{\} \;
For inherit eclass I've searched manually.
There's also games-etmod games-ut2k4mod and games-q3mod which were all
replaced by games-mods quite some time ago. There isn't anything in the
tree using these.
--
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] clean deprecated eclasses(?)
On Thu, 2008-02-14 at 16:03 +0200, Petteri Räty wrote: Peter Volkov kirjoitti: May be we should punt them from the tree? Eclasses can't be removed... Well, this isn't really true anymore thanks to bug #46223 being resolved. I'd say that it only makes sense that we keep them around for a long time from here on out, but they *can* be safe to move in the future. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Removing default-darwin profiles
On Thu, 2008-02-14 at 20:21 +0100, Fabian Groffen wrote: Before doing so I'd like to hear if anyone has objections to removing it, and the keyword + profile from arch.list and profiles.desc. Also, do I forget anything? Let me know if/when you do this so I can do the same in my snapshot. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [RFC] Adding two USE flags to 2008.0's profiles
On Sat, 2008-02-02 at 09:45 +0100, Christian Faulhammer wrote: Chris Gianelloni [EMAIL PROTECTED]: If adding bluetooth seems to be a bit much, how about just the usb USE flag? After all, my UPS won't work with apcupsd without USE=usb on my server... ;] I don't know how badly needed bluetooth is (no need here), but I remember we had to mask USE=bluetooth two times in the last week (KDE and something else, pulseaudio I think) to not break stable users...so I consider it a bit of a cruft. Understandable, bluetooth isn't the most mature thing in Linux. It tends to either work or it doesn't. OK, then I'll just add usb across the board. We can hold off until later for bluetooth support. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Changes to some profiles
On Sat, 2008-02-02 at 09:45 +, Duncan wrote: How about just some elog If you use make install, emerge --noreplace debianutils in the kernel's postinst or something. Well, that doesn't help those who get their kernels elsewhere, which IMO are the ones most likely to have their own scripted solutions using make install and thus debianutils in the first place, thus the general announcement suggestion, but a kernel-2.eclass einfo as proposed is a start and certainly won't hurt. =8^) (Also, as I've said, folks with such site-customized scripts are precisely the ones advanced enough they /should/ catch it and be well able to make the necessary changes themselves, regardless of warning, but should != will, and a GMN/GWN/ upgrade-guide warning is a nice touch in any case.) Well, we can hold off adding it to the actual tree until after the next GMN, so that's not really an issue. My main question was if there was any opposition, and it appears that there is none, so long as information is provided to our users. I'm in total agreement. If I don't hear any complaints, I'd like to go ahead and get a GMN article together. Do we really need a front-page news item for this? I don't think the impact would be terribly great, as I suspect this affects a very small number of people whom are likely to be more advanced users. I think adding the info to GMN/gentoo-dev-announce/gentoo-user should suffice. If someone thinks we need to do a front-page article, we can do that, too. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Changes to some profiles
On Sat, 2008-02-02 at 14:21 +0100, Vlastimil Babka wrote: Chris Gianelloni wrote: Do we really need a front-page news item for this? I don't think the impact would be terribly great, as I suspect this affects a very small number of people whom are likely to be more advanced users. I think adding the info to GMN/gentoo-dev-announce/gentoo-user should suffice. If someone thinks we need to do a front-page article, we can do that, too. IIRC it will affect only 2008 profiles, and not older, so people have to switch profiles first? Which already involves knowing what you're doing? So what about putting up a GMN/front page article announcing all such changes in new profiles, and not just for debianutils removal. I don't recall there was this kind of article/documentation before, but might be wrong. Ehh, I didn't say I was only doing it for 2008.0's profiles. I *could* but there's not really much point. The package isn't needed in system for anything to compile/run, so why should we force it onto everyone's machines? -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Changes to some profiles
OK, so I built a complete set of stages (with no circular dependencies!)
on amd64 for testing, using both the default-linux/amd64/dev/2008.0
and the default-linux/amd64/dev/2008.0/desktop profiles with the
following changes and everything worked perfectly. I would like to
replicate this to the tree before the snapshot today. If nobody has any
objections in the next 12 hours or so, I'm going to do it.
base/packages:
removed debianutils
removed perl
removed python
changed sys-apps/portage to virtual/portage
default-linux/packages.build:
removed perl
removed python
changed sys-apps/baselayout to virtual/baselayout
changed sys-apps/portage to virtual/portage
Even without perl/python in packages.build, we still end up with both in
stage1's tarball. We pull in perl via auto{conf,make} and python via
portage (duh). I'd like to also try removing autoconf and automake from
packages and packages.build above, since things *should* now be
depending on them if they need them. Of course, I won't commit that
until after posting here again after testing it and being sure it's
good.
--
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for February
On Fri, 2008-02-01 at 19:59 +0100, Tiziano Müller wrote: GLEP46, as discussed on Januar 21-24. I'd say it's ready. The only minor thing is where to keep the list of available tags. As far as I understood neysx we should keep it in metadata.dtd itself. http://www.gentoo.org/proj/en/glep/glep-0046.html for anybody wanting to know what GLEP49 entails. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Changes to some profiles
On Fri, 2008-02-01 at 23:47 +0200, Petteri Räty wrote: Chris Gianelloni kirjoitti: base/packages: removed debianutils I don't think we reached a decision on whether debianutils should go to kernel-2.eclass before this is done. Actually, it isn't very important if it happens or not (to me/release), and doesn't change that I'll be testing with it, either way. After all, it's a rather simple change to revert. That being said, you've got until March 10th (final snapshot freeze) to decide. ;] -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] [RFC] Adding two USE flags to 2008.0's profiles
I'm thinking of adding both the bluetooth and usb USE flags to the 2008.0 profiles for amd64/x86. I'll be adding just usb for everybody else, unless they want bluetooth, also. So why am I asking about this? Well, I'm wanting to add it to the 2008.0 profiles, not the desktop or server sub-profiles. This means it'll hit pretty much everybody. That being said, this normally enables hardware support, so I see it as a good thing. If adding bluetooth seems to be a bit much, how about just the usb USE flag? After all, my UPS won't work with apcupsd without USE=usb on my server... ;] -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] debianutils: system worthy ?
On Wed, 2008-01-30 at 12:35 -0500, Philip Webb wrote: 'equery d debianutils' gives me app-admin/sysklogd-1.4.2_pre20061230 (sys-apps/debianutils) app-portage/gentoolkit-0.2.3-r1 (userland_GNU? sys-apps/debianutils) sys-apps/mktemp-1.5 (=sys-apps/debianutils-2.16.2) The 2nd cb ignored, but the others seem important. I have Mktemp-1.5 installed, so what do you mean by your lines 1-2 ? Funny enough, mktemp is included in newer coreutils. Sysklogd seems to be an important pkg too. Unless you use metalog, or syslog-ng, or... What am I missing (smile) ? That nothing that you've said counters the package not being needed in the system target. In fact, the packages that you list all explicitly depend on debianutils, so they wouldn't break if we removed it from system. The problem is packages which require debianutils but do *not* depend on it, because it's in system now. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] debianutils: system worthy ?
On Wed, 2008-01-30 at 10:32 -0800, Chris Gianelloni wrote: That nothing that you've said counters the package not being needed in the system target. In fact, the packages that you list all explicitly depend on debianutils, so they wouldn't break if we removed it from system. The problem is packages which require debianutils but do *not* depend on it, because it's in system now. I'm running a stage build with debianutils removed from system. I'll let everyone know the results. If it works, I'll do the same for a LiveDVD build, which covers most of the major packages in the tree. Sure, there might be a few stragglers after that, but I doubt that there would be too many. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: removal of digest files from the tree
On Thu, 2008-01-31 at 00:45 +0100, Santiago M. Mola wrote: On Jan 31, 2008 12:32 AM, Robin H. Johnson [EMAIL PROTECTED] wrote: On Thu, Jan 31, 2008 at 12:05:26AM +0100, Vlastimil Babka wrote: Chris Gianelloni wrote: I think throwing up an announcement today/tomorrow for Thursday/Friday should be sufficient for this sort of a change, as it won't affect any user who has a version of portage released in the past ~1.5 years. So, since it seems nobody objected it, time for the announcement? And the removal (server-side by robbat2) would be best done right before the snapshot? It's pretty much irrelevant to the snapshot. wolf31o2 has my patch to exclude digests in the snapshot anyway. Then I guess it could be done as soon as the doc patch is prepared... It really is best done in the tree first, so everything is correct for the snapshot. We didn't have much issue last time because we push manifest1_obsolete into the snapshot, so digests are removed, anyway, but I'd *really* prefer if this were done prior to the snapshot being made. The less fudging I have to do with the snapshot, the better. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] archives.gentoo.org linking brokenness
On Sun, 2008-01-27 at 01:49 -0800, Robin H. Johnson wrote: sequential numbers), but it will be a day or two - restoring the old ones is not possible at all. Umm... OK. What's the new format? Do we just have to go an manually change every single link we've ever made to anything on archives? How are we going to find the articles if the old links don't work? -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: removal of digest files from the tree
On Sun, 2008-01-27 at 06:27 -0800, Robin H. Johnson wrote: Due to how CVS hooks operate, it's not quite possible. You wouldn't be able to block the entire commit, only the contents of the files/ directory would get totally blocked. If you were committing an ebuild along with a patch, this would be very bad, as the ebuild+Manifest would get committed, but the patch wouldn't. Bleh... CVS vs. SVN. There's no pre-commit equivalent on CVS? Also, wouldn't the second Manifest run fix the missing digest commit? -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: removal of digest files from the tree
On Sat, 2008-01-26 at 17:08 -0800, Zac Medico wrote: If there are no objections then I don't so any reason not to go ahead and add the manifest1_obsolete sometime in the near future. Thoughts? 1. Add blocking of commit of files/digest-* in CVS pre-commit hook 2. Add manifest1_obsolete to tree 3. Remove all files/digest-* files from tree (on CVS server side) 4. Remove all files dirs that are empty (on CVS server side) This should be all that we need. The 2007.1 snapshot was done without any digest files, and it worked just fine, also the default settings have been to not sync the digest files for some time, so only people with an older/unsupported portage have been getting digest files, at all. I do have one question, though. What does an older portage version do when it hits a package with a missing digest file? Let's say I've got portage prior to 2007.0's, so it doesn't support Manifest2 only. I want to emerge --oneshot portage to get to the latest version. What do I need a digest on? Just portage? portage and its dependencies? Which dependencies? All of them, or just the ones I'll actually need to merge? I guess what I'm asking is if it is possible to have repoman create a digest for sys-apps/portage only, for the slow upgraders. Of course, this assumes its even possible on the portage side to bother. If not, just ignore this part. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: removal of digest files from the tree
On Sun, 2008-01-27 at 17:11 -0800, Zac Medico wrote: If there are no objections then I don't so any reason not to go ahead and add the manifest1_obsolete sometime in the near future. Thoughts? Let's do it. I look forward to a lot less inodes on my disks. Let's schedule a date for it then and we can have a big announcement to let everyone know. Dammit. I wanted this before January 31st, so it would make it into the 2008.0 snapshot. Do we think we can get this done by January 31st? I think so. One reason that I think that we don't need to wait very long is rather simple. People running very old versions of portage that will be affected by this are also not likely to read our news or see our front page on a regular basis. They're likely to get broken, no matter what we do. Hell, even posting it to the GMN/forums/lists/planet/front page, we'll still end up getting complaints from these people when they come back $months from now and the news is no longer sticky in the forums, has rotated off the front page, isn't even a distant memory on the lists, and is in a several month old newsletter. When gauging impact/scope of a problem, always look at who it affects and the situation. You only need to take as much precaution as necessary to cover the cases worth spending the time to cover. There will *always* be corner cases. You just try to minimize them. I doubt much of anything aside from portage/paludis/pkgcore use the digest files, and I'd bet that paludis/pkgcore don't use them, at all. I think throwing up an announcement today/tomorrow for Thursday/Friday should be sufficient for this sort of a change, as it won't affect any user who has a version of portage released in the past ~1.5 years. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: removal of digest files from the tree
On Sun, 2008-01-27 at 18:01 -0800, Robin H. Johnson wrote: On Sun, Jan 27, 2008 at 05:34:14PM -0800, Chris Gianelloni wrote: On Sun, 2008-01-27 at 06:27 -0800, Robin H. Johnson wrote: Due to how CVS hooks operate, it's not quite possible. You wouldn't be able to block the entire commit, only the contents of the files/ directory would get totally blocked. If you were committing an ebuild along with a patch, this would be very bad, as the ebuild+Manifest would get committed, but the patch wouldn't. Bleh... CVS vs. SVN. There's no pre-commit equivalent on CVS? There is pre-commit, but it's not recursive. It gets applied to only a single directory and in isolation from the other directories. OK. So we could block on commits of digest-* files to files, right? What else would we need? Also, wouldn't the second Manifest run fix the missing digest commit? In what way? the problem I was concerned about was non-digest files not being committed leading to broken ebuilds. Ahh, never mind... I was thinking of something else. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] archives.gentoo.org linking brokenness
On Sun, 2008-01-27 at 17:57 -0800, Robin H. Johnson wrote: Do we just have to go an manually change every single link we've ever made to anything on archives? How are we going to find the articles if the old links don't work? Unfortunately the hard way, by hand. Ouch. The new ones use a hash of (salt, Received, Date, Message-ID, From, Subject, List-Id), and it's guaranteed to be the same regardless of mhonarc deciding to ignore it's existing database. OK. At least now they're designed so that this cannot happen again. Thanks for taking the time to code that part up. I hope that you sent that patch upstream! ;] -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Concerns about WIPE_TMP change [offtopic]
On Mon, 2008-01-21 at 20:34 -0500, Caleb Cushing wrote: On Jan 20, 2008 8:43 AM, Richard Freeman [EMAIL PROTECTED] wrote: Stefan de Konink wrote: ..very offtopic but how are you all compiling stuff like firefox on a ram disk. Or is 8GB of ram very cheap suddenly? not to mention, last time I checked open office only required ~2GB of space to compile and it takes more than firefox. Most apps can be done in less than 512MB The largest abuser of space in the tree that I am aware of is games-fps/ut2004-data which weighs in at nearly 7GB to install. I'm pretty sure that games-strategy/nwn-data is pretty close with USE=hou sou enabled. ;] -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: USE flag documentation
On Tue, 2008-01-15 at 17:00 -0600, Ryan Hill wrote: My expectation is that `grep flag use.local.desc` will give me a list of packages using that flag (or having it in the description), one per line. Putting paragraphs in there doesn't seem right. A single long line still fills this requirement for us. However, it does bring up the point. Why even have use.local.desc (or metadata.xml's use tag) at all? Is there really a need for a *global* list of flags that are ebuild-specific? (I don't care or have much opinion, either way, I'm merely presenting some topic for discussion on this.) -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Available hardware
On Tue, 2008-01-15 at 16:25 -0800, Daniel Ostrow wrote: 1x HP ZX2000 1.4 GHz Itanium2 I know that you said off-list, but I'm stating this here simply because I want to make sure people know that I have dibs if this meets my needs. Can this box be upgraded to SMP? If not, I rescind my dibs since mine is more powerful. I just want to be able to have decent video so I can do games on IA64. As you know, my Itanium box is a server without AGP and with only PCI-X (so PCI video is my only choice). -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Seeking questions for a user survey
On Mon, 2008-01-14 at 04:33 -0800, Robin H. Johnson wrote: Release-related questions: - Should CD media be released at a different rate than stage tarballs? - Desired release frequency for minimal/livecd/GRP/stages (annual, bi-annual, quarterly, monthly, weekly?) - Do you use the installer or install by hand? (need an other field here) This question would be interesting, though a little moot. With future releases, we're making the Installer binary-only. The reason is simple, there are too many possible failure opportunities in the live tree or when building from source. The number of installer bugs that are simply compilation bugs (many of which are already fixed in newer versions/revisions in the tree) is overwhelming compared to the actual number of bugs in the Installer. By making it binary only, we only allow the Installer to use known-good input for producing a user's system. All networked installs will be manual, and will follow the Handbook. I've thought of producing a simple default source-based install script that allows someone to still use a source-based and current installation, without having to type in a bunch of commands. I don't know how well this would be received, but it could be something that you could ask here. - How often do you use the media? Which media do you use? (minimal, universal, livecd, livedvd) Which version do you use? (So many people tell me things like, I still use a $version CD, so I think it would be useful...) - How often do you install Gentoo (using the stage tarballs or the installer)? - Do you use GRP? - Would you like to use GRP in future? - Binhost questions maybe? - Do you use the portage snapshot associated with the release or the latest available snapshot or other? - Do you use a Gentoo derivative? (give a list with an other option) What features do you think are lacking on Gentoo install media? (free form) -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Seeking questions for a user survey
On Mon, 2008-01-14 at 22:53 +, likewhoa wrote: Which DE/WM would you prefer for the gentoo livecd instead of the one provided? Kde Xfce Fluxbox E16 Fvwm Gnome Other Can I suggest that we not ask anything that we likely won't change? I have a strong feeling that KDE would win out here, but there's *NO WAY* that we can fit KDE on a LiveCD with the other stuff. When we were planning 2007.1, we had decided to switch to Xfce, simply because of the space savings. Cramming a lot of useful stuff onto 700MB is *not* an easy task. Space is our biggest enemy here. Were we to drop the LiveCD fully in favor of the LiveDVD, then I could see this as (somewhat) valid, as all of those Window Managers/Desktop Environments are already shipped on the LiveDVD (except FVWM). I'm not too interested in people's opinions for the defaults on a media set that includes them all and each is only a click or two away, though, as it doesn't really add anything to what we provide. If it weren't for the size constraints, I'd love to know what people prefer on the CD, so I don't want anyone to think that we don't care. We do. We just are limited by a hard size limit than we cannot do anything about and have to act accordingly. Do they use grp packages? Yes No What is grp? Sometimes Never Definitely word this in a manner so people know what you're referring to. I would say something more along the lines of Do you use the Installer in Networkless mode or GRP packages when installing your system? Which livecd(s) do they prefer? Gentoo livecd-2007.0 Sabayon livecd Sysresccd Knoppix My own Other Be sure to list the Minimal CD and the Universal CD, as well as the LiveCD, and also list the LiveDVD. We'll have to relate this data to the architecture used when we try to make anything useful out of it, but it'll be more accurate, as I definitely want to know *which* Gentoo media people are using. I would also add something like an older Gentoo CD to the mix. Do you think commercial packages should be part of the main tree? Yes No Why not Never! in unofficial overlay Dunno Is this something that we really even want to ask? I mean, if we're all about trying to provide the best user experience, then binary packages are almost a requirement, especially with binary packages that were originally targeted at specific binary distributions. I tend to see this as one of those religious issues that is best left alone, like emacs versus vi. How often should GWN be updated? once a week everyday every month every six months what is GWN? Again, you're asking something that I don't think that we should be asking. We couldn't get content even though we begged and pleaded for it. No offense meant to anyone, but I don't care if people want a daily newsletter. If we cannot get enough content, we cannot get enough content. No survey is going to change that, and asking a question like this gives the impression that the user's opinion will make a difference, when it likely will not. I'd much rather not ask questions that the users are going to feel like they were ignored than ask them and not make any changes based on the answers. Of course, if you're volunteering to pick up the slack and write any necessary articles to make it happen at the interval decided by our users, well, I completely welcome it, then... ;] Do you like the Gentoo Linux Installer (GLI)? Yes No Never heard of it I'd like to see the answers to this one, but I have a feeling that everybody has a love/hate relationship with this. They either love it, or they hate it. I also tend to think that *many* people have an opinion on the Installer without ever even using it. As such, I don't think that we'd get any usable results out of this, but it'll still be fun to ask. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Seeking questions for a user survey
On Tue, 2008-01-15 at 00:34 +, likewhoa wrote: Do you think commercial packages should be part of the main tree? Yes No Why not Never! in unofficial overlay Dunno Is this something that we really even want to ask? I mean, if we're all about trying to provide the best user experience, then binary packages are almost a requirement, especially with binary packages that were originally targeted at specific binary distributions. I tend to see this as one of those religious issues that is best left alone, like emacs versus vi. Yea commercial packages should maybe be part of overlays.gentoo.org so that the tree can stay clean from these types of packages. But I agree if it's decided not to included in the user survey. I look at it very differently. One of the main advantages to Gentoo is being source-based. This allows us to ship packages in our repository for binary and commercial packages that would otherwise be impossible in a binary distribution. Remember, we don't actually ship the commercial software. We ship a bash script (essentially) that tells how to install the software. As much as I like to appeal to zealots (hahaha, right), I don't consider shipping a bash script telling how to install a product to be *anything* like shipping said product, endorsing it, or anything else license zealots will try to spout to justify the removal of GPL-2 code from our repository. Many people don't consider overlays, even Gentoo-run ones, to be of sufficient quality/support/whatever to be used on production systems. These are the same systems and people that would most likely utilize these commercial ebuilds. Basically, it is removing the *option* to install these packages from the people who would like to use them for the sake of the people who *REFUSE* to use the packages and insist on their removal from the tree simply because they don't like the license under which is was released. I'm sorry, but if that's not against the idea of a free and open community, I don't know what is. You have the right to chose what licenses you wish to support and use software which agrees with your ideals, but that doesn't give you the right to *DENY* others to do the same. Sorry, I just don't see it as a valid question, at all. Do you like the Gentoo Linux Installer (GLI)? Yes No Never heard of it I'd like to see the answers to this one, but I have a feeling that everybody has a love/hate relationship with this. They either love it, or they hate it. I also tend to think that *many* people have an opinion on the Installer without ever even using it. As such, I don't think that we'd get any usable results out of this, but it'll still be fun to ask. I for one never used it so I can't really love or hate it but from what people who have used it tells me to stay away from it because I'll eventually hate it. Well, anybody who dislikes it because of bugs or a bad experience, I can completely understand. I was really speaking mostly of the people who dislike the *idea* of an Installer for Gentoo, and then go and bash it as much as they can without providing any real evidence or reasons, except for the old faithful it's against the spirit of Gentoo reason, which is a complete fallacy. Again, Gentoo is about empowering the users to make their own decisions. No, I won't say Gentoo is about choice, because that is *STUPID* in that it gives people an excuse to argue about even the biggest piece of junk being added to our tree or supported, as if we have to, to give them the choice. Instead, I prefer the concept of empowering the user to make their own choices, where they can choose to add anything that they want in their personal overlay, as we have given them the tools to do so. Now, if a user wants to use an Installer and someone wants to write the code, who are you (or I) to say that they are in the wrong? After all, isn't it that idea of empowering the user *really* the spirit of Gentoo? I think so. Thanks for the great feedback Chris Gianelloni You're totally welcome. Take what I've said here as my own opinion, of course. Fernando -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RE: Re: Item for 10 Jan 2008 Council meeting
(Didn't really have anything specific to reply to, so just picking this) On Sat, 2008-01-12 at 05:39 +, Steve Long wrote: Mr McCormick Ehh, Ferris and I resolved our issues after a couple emails and just a little time to chill out. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] extend profiles.desc to include experimental profiles
On Sat, 2008-01-12 at 00:40 -0500, Mike Frysinger wrote: On Friday 11 January 2008, Chris Gianelloni wrote: For one, a way to mark a profile as deprecated in profiles.desc so repoman doesn't scan it (currently, we remove tend to remove them from the list). is this really needed ? i'm trying to see why this would be useful, and not coming up with much ... profiles.desc exists for two reasons: - for qa tools to scan - so people have a list of valid profiles if a profile is deprecated and on the way out, neither of these two things apply to it, so what's the use of having it listed ? we can already mark profiles deprecated for users who already have it selected ... I guess I was thinking more for the package manager. As I said, I would love for it to enforce a valid profile as defined in profiles.desc, even if it is a deprecated one, until the user switches. This means the deprecated profile needs to be listed in profiles.desc, but we don't want to run QA on it, as you said. The second would be a change to repoman that's more invasive in that it changes current behavior a good bit, but having repoman only scan stable profiles, by default, with options to scan the other types. i think by moving our most annoying profiles out of the dev to the exp state would mean that any warnings left while in the dev state are something we want to be seeing and addressing. the problem right now is that we have two types of profiles listed in dev: ones that people should care about and shouldnt be breaking and ones that people shouldnt care about and are free to break. package maintainers obviously dont (and shouldnt) know which are which. Indeed. I can see that with the profiles reassigned there's no need for this. I've always wanted to have *every* valid profile listed in profiles.desc so we can do things like have portage not allow someone to use a profile that isn't listed in profiles.desc (of course, overlay users crazy enough could do their own profiles.desc and it would be stacked with the in-tree one). The main problem with doing this has been the effect on repoman, since it scans every listed profile every time. I know that most of the profile selection tools out there already only show profiles that are listed in profiles.desc, so it wouldn't really be a change for them, but I think it would be useful elsewhere, too. All in all, having profiles.desc actually showing the status of all of the profiles would be great. i could see it tied to FEATURES=strict. if you have this enabled, then you're only allowed to use declared profiles (which means if you use a non-standard one, you'd need to declare it). Sure. I see no reason to not allow someone to turn it off. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: GMN (was: Re: Projects and subproject status)
On Fri, 2008-01-11 at 11:30 +0530, Anant Narayanan wrote: Thanks Chris. I just went through the Gentoo Weekly News guide (which is a little outdated, but still quite helpful). Are there any other scripts other than glsa2gwn.py and bugs2gwn.py that need to be run? Yeah, there's other scripts. If you check gentoo/src/gwn, you'll find them all. Basically, you need get_glsas.py (which needs glsa2gwn.py) which you run against the last GWN and it gives you all GLSA since. Of course, you'll have to modify the first one manually, since it'll give you everything since October 15th. Speaking of which, it might be a good idea for us to put out at least one stats-only GWN with all of the stats since October 15th until the newest edition (whenever that may be). Taking Robin's output for the adds/removes, you feed the file to gwn_adds_removes.py which does all the good stuff like formatting and pulling dev names automatically. The gwn_bugzilla_report_en.py pulls the bugzilla stats. If you run it on its own, it'll give you the stats for the last week, starting from the previous day. It also accepts a date range so you can specify the dates. If we switch to a monthly newsletter, it would probably be best to change it to simply pull all the stats for a given month (like December). Ryan's last rites stuff was always properly formatted, so a simple paste is all you need there. It would be nice to get Robin's adds/removes to be processed automatically through gwn_adds_removes.py and sent to gwn-feedback already formatted. That covers the stats. Aside from that, there is the gwn_to_text.sh and gwn2txt.xsl, which does the XML - text conversion for emailing. Something that I always wanted was something in the XSL which would allow us to mark a GWN as published and disallow further changes. Basically, you would do something like put in a published tag (or whatever) and a few things would happen: #1 - That GWN would no longer be editable. This is actually a good thing, as changes after publishing has been something that's bitten us a few times, especially given the nature of the emailed editions of the GWN. Rather than change the GWN after it is published, I planned on doing a Corrections type section where we would list any mistakes (worth mentioning, not typos and such) in the previous GWN. #2 - That GWN gets automatically converted to plain text via a post-commit hook and automatically emailed to the GWN list. #3 - That GWN is published to the front page. How this would be done is still something up in the air. Perhaps adding a summary tag which would allow you to set the summary, which would show up on the front page, in the GWN itself, even if it is never displayed directly in the GWN edition. The idea is to take all of the steps which could be easily automated and do so, saving the GWN editor a lot of time doing manual/menial copy and pasting. I'll try and co-ordinate with infra to get them running automatically on a monthly basis. Is there anything else I need to know? A few points: 1) I'm going to create a sub-project called 'GMN' under the PR project, which will supersede the GWN project. That sounds like a good idea. 2) I'm planning to get the first issue out by 21st of this month, and subsequently on the third monday of every month. Are you planning on having the 21st edition show stats for December, or... ? 3) Can we have email aliases [EMAIL PROTECTED] and [EMAIL PROTECTED] for purposes of this project? (It sounds silly to ask for feedback on the GMN at [EMAIL PROTECTED]) Sounds good to me. What is the purpose of 2 aliases, though? We found that people had enough problems with only one email to send to, so I'm just curious what your thinking is here. 4) Can we 'move' the gentoo-gwn mailing list to gentoo-gmn? Definitely. @Christian, William and Ryan: Please do resume sending your articles as soon as I get the gmn email alias setup. I'll get in touch with you shortly after the necessary arrangements have been made. Let me know once the alias is up and I'll forward along all of the stuff people have submitted since October. Whether you use it all (or none of it) at least you'll have it. Any suggestions/tips/comments on the new venture, are of course, more than welcome. Feel free to ask me any questions that you have along the way. I tried to make publishing the GWN easier, but I still didn't get nearly as much accomplished as I had wished. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] extend profiles.desc to include experimental profiles
On Fri, 2008-01-11 at 09:59 -0500, Doug Klima wrote: Mike Frysinger wrote: after dealing with m68k, mips, and the *-fbsd ports, i think we could do with a new state for profiles.desc. the new field would simply be exp to indicate that the profile is experimental and that qa tools should generally not issue warnings about them. so in repoman's default mode, you wouldnt get any warnings, but if you were to run it in full mode, you'd see stuff like normal. this is useful for new projects which are still in the process of merging (like *-fbsd, m68k, and any new hardware i get my hands on) and are not really ready for dev marking. there are plenty of warnings in packages right now due to these profiles being labeled as dev that are the sole problem of the keyword maintainer in question and not the package maintainer. -mike I've very much been a proponent of properly listing out all of our profiles in profiles.desc. This sounds very reasonable and logical. And hopefully if the tools in question are coded properly, it should be compatible with older versions until users upgrade. To go along with this, I've always wanted a few other minor changes. For one, a way to mark a profile as deprecated in profiles.desc so repoman doesn't scan it (currently, we remove tend to remove them from the list). The second would be a change to repoman that's more invasive in that it changes current behavior a good bit, but having repoman only scan stable profiles, by default, with options to scan the other types. I've always wanted to have *every* valid profile listed in profiles.desc so we can do things like have portage not allow someone to use a profile that isn't listed in profiles.desc (of course, overlay users crazy enough could do their own profiles.desc and it would be stacked with the in-tree one). The main problem with doing this has been the effect on repoman, since it scans every listed profile every time. I know that most of the profile selection tools out there already only show profiles that are listed in profiles.desc, so it wouldn't really be a change for them, but I think it would be useful elsewhere, too. All in all, having profiles.desc actually showing the status of all of the profiles would be great. Good stuff Mike. Indeed. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Thu, 2008-01-10 at 07:08 +, Ciaran McCreesh wrote: On Wed, 09 Jan 2008 12:33:40 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: This is why I find it funny that people even bother to listen to Ciaran, at all. All he cares about is his little pet projects/teams and doesn't care if it increases workload for everybody else. I mean, where would Gentoo be if not for our support of mips? Oh dear, we'd definitely be nowhere near as popular... *cough* Ah yes, you're entirely right. We should all listen to you instead, because of the brilliant job you're doing on your pet projects, 2007.1 and the GWN. I'm afraid that once again, you simply don't have a clue what you're talking about. I've not been doing the GWN for a few months now, nor was it *ever* a pet project of mine. Keep it coming. You're entertaining the *hell* out of me. *grin* In the mean time, I'll just say that if you don't drop the personal attacks and apologise, I'll have no choice but to take it up with devrel. You're supposed to be arguing technically here, but all you do is go around name calling. Feel free to bring up an issue with Developer Relations. They'll likely throw it out because YOU ARE NOT A DEVELOPER. Also, you'll notice that rather than call you names, which is really your forte, I have instead pointed out why I think your opinion is completely worthless to Gentoo. If you feel insulted by people pointing out things like you being fired from the project due to your attitude, perhaps you shouldn't have gone and gotten yourself fired? I mean, you made your bed, now lie in it. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Projects and subproject status
On Thu, 2008-01-10 at 23:35 +0530, Anant Narayanan wrote: If nobody has a problem with making the GWN a GMN (Monthly newsletter), then I am willing to volunteer to get this project back on track. Even if few people actually submit anything, I think there is enough activity going on this list, the planet and -commits to fill up a newsletter every month. And I'm willing to invest 12, even 15, hours a month to get this thing rolling again. That's great! I am afraid that it'll likely take you much longer than you anticipate, as it took me that long every *week* when I was doing it. Some of the scripts would need to be updated to work on a monthly-basis rather than weekly. Also, I still think that it would be good to automate the scripts that run by putting them on infra somewhere and having just the output mailed to gwn-feedback as it'll save a little bit of time for the person doing the GWN and also it'll make sure you don't forget to run it. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting
On Wed, 2008-01-09 at 14:00 +, Ferris McCormick wrote: they get to devrel because you ensured there would be no one to catch them --- you are the one who wanted to kill off the proctors, after all. ...and the finger-pointing starts... Bravo! I never have been able to figure out what the hell I did to you to make you feel like you need to personally attack me every step of the way, but I'm not putting up with it, anymore. I'm adding Developer Relations to this email and will be filing a formal complaint against you. Have a good day. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 09:25 -0500, Caleb Tennis wrote: I never even mentioned any specific arch in my original request, nor did I call any developer out. So please, nobody needs to take this personally. Correct, you did not. What I find absolutely *damning* is the fact that as soon as any arches *were* mentioned, everybody was talking about the same one. It's rather funny that everybody seems to have the exact same impression of what architecture might be a slacker and would be affected by this. I wonder why that is? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 14:44 +, Ciaran McCreesh wrote: We want the Council to do something about this issue. You can deny the issue all that you want or try to deflect conversation from the actual issue, but your opinion isn't very important to the much of the current developer pool, seeing as how it doesn't affect you in any way, having been thrown from the project, and all. Ah, so now what matters is who says something, not whether or not it's true. Well, when a non-developer who was thrown out of the project because his attitude and approach was unwanted points out something and makes statements as if he actually were still involved in the process of maintaining packages or working on an architecture team and is unable to get others to agree with him and insists that there isn't a problem but is unable to back it up, then yes, it definitely does matter. I'm just making sure that people are aware of the situation, as you like to portray yourself as important to the Gentoo project, when the project has deemed you as not important and forcibly removed you. Thanks for playing, but you fail. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 15:11 +, Ciaran McCreesh wrote: Heck, most of the repoman messages people are moaning about are caused by developers doing exactly this. No, most of the ones we're complaining about have nothing to do with KEYWORDS, at all, and everything to do with changes to policy and such that have been enacted since the ebuild was last touched. See, repoman doesn't care if you're just making a KEYWORD change or if you're making coding changes to an ebuild. It still will fail if something fails a QA check, even if the failure is on an ebuild you're not touching. As such, it is a serious pain in the ass for architecture teams and developers who are *not* slacking when one particular architecture only has ebuilds that are ancient marked stable. It increases the support burden for *EVERYONE* else to keep this one architecture's stable tree as it currently sits. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 18:56 +0100, Jan Kundrát wrote: Chris Gianelloni wrote: I have foo 1.0, which is mips. There is foo 2.0, which is stable everywhere else. The foo 1.0 ebuild does not conform to current ebuild standards. I want to commit changes to foo 2.0, and repoman won't allow me due to problems in foo 1.0, but I don't want to WASTE MY TIME on foo 1.0, because it's been EOL for 2 years Why don't fix repoman not to scream about such issues, then? What, have repoman complain only about problems in ebuilds that have been changed unless someone does repoman full ? Honestly, that coupled with dropping all KEYWORDS except for the arch in question (in other words, marking something KEYWORDS=mips and then ignoring it, as a maintainer) would be enough to keep package maintainers and other architecture teams from having to deal with the crap left all over the tree due to slacker arches. Of course, tree quality would probably go down even more, since these QA issues would likely never be fixed on said architectures, but who really cares, anyway. The support burden gets lain on the people who are slacking, and not on the package maintainers or other architecture teams. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 18:11 +, Ciaran McCreesh wrote: On Wed, 9 Jan 2008 10:07:31 -0800 Alec Warner [EMAIL PROTECTED] wrote: Actually if they dump kde-3.5.5 and anything depending on it, then they don't break the tree and everyone is happy, no? Everyone except the users, who end up with pages and pages of horrible Portage output... What, all six of them? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 18:45 +, Ciaran McCreesh wrote: On Wed, 9 Jan 2008 19:29:53 +0100 Wulf C. Krueger [EMAIL PROTECTED] wrote: On Wednesday, 09. January 2008 19:16:24 Ciaran McCreesh wrote: So what happens if a flaw is discovered in KDE 3.5.5 that allows root access? Then the one particular part of 3.5.5 that's affected gets fixed and priority keyworded. So you suggest that mips keeps doing nothing and expect others to work *more* in exchange for that? Well, most users will simply ignore or postpone the mass upgrade, so yes. Forcing a mass upgrade is rarely if ever the correct solution to any security issue. This is why I find it funny that people even bother to listen to Ciaran, at all. All he cares about is his little pet projects/teams and doesn't care if it increases workload for everybody else. I mean, where would Gentoo be if not for our support of mips? Oh dear, we'd definitely be nowhere near as popular... *cough* -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 20:50 +0200, Petteri Räty wrote: Ciaran McCreesh kirjoitti: On Tue, 08 Jan 2008 18:59:29 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: The issue that was raised is that certain arch teams are incapable of keeping up with the minimal workload they already have and what should be done about it. The issue was raised, with absolutely no proof or justification, and every previous time said issue has been raised it's turned out to be somewhere between highly misleading and utter bollocks. So you just ignore for example my post about CIA activity for the mips team? Of course, it is common practice to ignore any factual data that supports the opposing side of a discussion. This is Gentoo, man! Where've you been? :P -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Projects and subproject status
On Mon, 2008-01-07 at 22:31 +0100, Luca Barbato wrote: Here is a list of interesting questions: Are we fine? What are we going to do? Please project leaders try to reply in short. About the stuff I'm involved: Are we fine? GWN: The GWN is currently in a permanent state of hiatus. I have no intentions on spending another minute working on the GWN. While many, many improvements have been made in the processes for getting the automated data, getting articles has been pulling teeth, at best. This was taking me upwards of 12 hours a week, which was impacting the time I had available to work on things like releases and my day job. As such, the GWN is abandoned and will likely stay that way until someone steps up and decides they're ready and willing to give up their lives to work on this publication. Yes, I think switching to a monthly newsletter would *help* the problem, but it still won't resolve it. The GWN needs articles more than anything, and few people are submitting anything. Release Engineering: We dropped the 2007.1 release due to many issues which I won't go into here, since it really isn't appropriate at this time. As such, we're deciding on what our plan is for 2008 and beyond. We are working on finalizing the latest versions of genkernel/catalyst. PR: Well, I'm not the lead here, but since the lead is AWOL, I guess that I can give my input. This project is essentially dead. There are a couple people who occasionally respond to user queries to the alias, but otherwise, nothing is going on here. Nobody is really active. I sent in some news about 2007.1 a few weeks back and nobody's posted anything or even responded. I'd say the project is dead if we can't even get out pertinent information like the cancellation of a release to our users. Trustees: Well, the Foundation no longer exists, legally, so it's pretty obvious that things are not fine here. What are we going to do: GWN: no clue, looks like nothing RelEng: work on catalyst/genkernel, no further plans PR: no clue, looks like nothing Trustees: I retired as a Trustee since there's not much point without a Foundation to run, leaving us with one (or possibly two) trustees. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 18:56 +, Ciaran McCreesh wrote: On Wed, 09 Jan 2008 20:50:38 +0200 Petteri Räty [EMAIL PROTECTED] wrote: So you just ignore for example my post about CIA activity for the mips team? That falls into the highly misleading category. Yes, hard numbers are always misleading, especially when they show that the entire team is barely active, at all, and only one of those people is doing *any* mips work. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 20:45 +0100, Vlastimil Babka wrote: Ciaran McCreesh wrote: a) Drop all keywords but those of mips. Leaves mips and, more importantly, its users with a vulnerable and unmaintained set of packages. ...and break the tree spectacularly, causing huge amounts of pain for your fellow developers when they encounter horrible repoman output when they try to do anything. Can somebody clarify to me why would it cause this? Maybe I just miss something. He's making the assumption that this sort of thing would be done improperly and would cause other developers issues. I went and created a tiny script[1] to change mips KEYWORDS to ~mips in the tree, and created a patch[2] against the current CVS tree. Were the Council to choose this course of action, the work is mostly done. [1] http://dev.gentoo.org/~wolf31o2/killmips.sh [2] http://dev.gentoo.org/~wolf31o2/mips_to_testing.patch -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Reducing the size of the system package set
On Wed, 2008-01-09 at 15:51 -0500, Mike Frysinger wrote: Anyway, as having a complete dependency tree is almost impossible because of that, I have an alternative proposal: reducing the size of the system package set. Right now system contains stuff like ncurses, readline, zlib, autoconf, automake and m4, perl, gnuconfig, and so on. Those are packages that certainly would be part of any base Gentoo system, but are those actual part of the system set of packages? I sincerely doubt it. for ncurses/readline, they certainly are part of the system set. that doesnt mean they should not show up in depend strings, it just means they are system packages that every Gentoo system should have installed. Well, one solution for some of this would be to move said things to a higher level profile. Rather than have them all in base/packages, move some to default-linux/packages (or even further down, if appropriate). When the stages get built against these profiles, we would end up with the complete system set, but other profiles inheriting from the lower profiles like base won't have to negate things. i have no problem with shunting the rest. the only thing you need to keep in mind is that if we do move all of these things to build-only depend (which they are logically), then people who like to depclean their system would constantly be removing/adding them. Well, unless they were added to another profile. I think the main reason for Diego's request is for non-Linux non-default profiles that inherit from base. not really. the system package set is what went into releases and we wanted all of these things in our stage tarballs. it is nigh impossible to emerge anything on a Gentoo system without any of these packages, so forcing them all by default didnt cause any problems. Exactly. I just think that we can still accomplish what Diego is asking by shifting where things get added to system in the profiles. The end-result would be the same (for default Linux installs) but everybody else would have a cleaner common base from which to start. i'd say quite the opposite ... requiring perl in system blows. it's there for two reasons: autotools and openssl. but both are build time requirements only. Indeed. We ended up having to get perl into the stage1 because of exactly these problems. It sucks. I'd love to be able to remove perl (and anything else not necessarily required) out of the base system set. If they're required in other profiles, they should be added in said profiles. So there are more things that were brought to my attention, like ssh, flex, bison, e2fsprogs, and so on. We should probably look into what to keep, rather than what to remove. flex/bison are in the exact same boat as autotools. dont know why you separated them out. openssh and e2fsprogs are part of the system set because every Gentoo system out there should have them installed. if you dont like it, feel free to tweak your files locally, but to attempt to account for a few people at the detriment of 99.9% of the people out there makes no sense at all. Well, openssh has always been questionable. Sure, *I* think it should be on any Gentoo system I'd want to touch, but it really isn't necessary for a lot of people. Moving this to, say, the server profiles only would be acceptable to me, but then again, so is leaving it how it is now. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting
On Wed, 2008-01-09 at 22:42 +0100, Fabian Groffen wrote: On 09-01-2008 13:03:13 -0800, Chrissy Fullam wrote: You have a negative history with wolf31o2, and the details of which quite frankly should be kept off this mailing list. His negative experiences throughout all of 2007 with Conflict Resolution and consequently Developer Relations justify any of your alleged 'attacks on devrel.' Let's take this discussion elsewhere. Kind regards, Christina Fullam Gentoo Developer Relations Lead | Gentoo Public Relations IMHO, you have a very big conflict of interest in this issue. Why do Umm... and? Where in policy does it say that someone *must* remove themselves from a *conversation* where there *might* be a conflict of interest or bias? See, I had assumed that we all were supposed to respect each other's ability to look at the *facts* and *evidence* and make decisions based on said facts and evidence. I mean, if we all stopped participating in conversations where we had our own personal bias, there'd be no need for this list, our IRC channels, or any shared communications medium. See, it is *expected* that people are going to be biased. Everyone will have their own bias. It is how people *act* that makes the difference. Of course, I guess that only applies when it has nothing to do with me, huh? you (for the second time) handle a case like this one, and not someone else from devrel? Like who, exactly? Can you even tell who is active in Developer Relations? The Conflict Resolution team is *exactly* Christel, who is pretty much AWOL (not that I blame her... :P) and Ferris. I have a hard time to take your message as an objective and unbiased one. So? You mean the fact that I've had numerous verifiable issues with Developer Relations is somehow a matter of opinion that is being based on bias? I guess the emails that I sent to Developer Relations about issues that I was having *long before Chrissy ever became a developer* are all a part of her bias towards me and completely fabricated? What about the fact that several other members of Developer Relations have been reviewing and agreeing with all of her determinations? I find this whole thing humorous. None of you know a damn thing about Chrissy and my relationship, yet you make your assumptions. Keep on assuming. I really couldn't care less. It's this exact form of double standard and using things only when they fit what you want that keeps things from actually getting done, especially when they're untrue or based on faulty assumptions. I guess that's just business as usual around here, though. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Reducing the size of the system package set
On Wed, 2008-01-09 at 16:42 -0500, Mike Frysinger wrote: Indeed. We ended up having to get perl into the stage1 because of exactly these problems. It sucks. I'd love to be able to remove perl (and anything else not necessarily required) out of the base system set. If they're required in other profiles, they should be added in said profiles. i often debate simply chucking the perl build requirements of openssl in favor of autoconf ... maybe i'll set up a git tree on Gentoo's git for this ... i think that'd solve the perl required in stages issue ? As far as I know, only openssl would really be affected. If that were fixed, we very likely could drop perl from system. I'd have to check. I *know* that we could drop it from stage1/stage2, though. Well, openssh has always been questionable. Sure, *I* think it should be on any Gentoo system I'd want to touch, but it really isn't necessary for a lot of people. Moving this to, say, the server profiles only would be acceptable to me, but then again, so is leaving it how it is now. i'd argue pretty vehemently against removing openssh from any default official Gentoo install. ssh is defacto standard for loginning into any other machines. it should be on all Gentoo desktops/severs/etc... specialized/embedded/whatever are certainly free to cull openssh (and doing so is actually beyond trivial). whether we express this requirement in base/ or frags or something is certainly open for discussion, but i believe removing it from a stage3 in any of our standard releases is a huge disservice to everyone. Well, I wasn't really saying that it wouldn't end up in the stages. More that by moving it into the sub-profiles, it allows people to choose a profile where it isn't in system anymore. Of course, most of this is rather moot considering you can override parts of the profile and someone could quite easily just remove this one package, if they so desired. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] OpenRC available for testing.
On Wed, 2008-01-09 at 16:26 -0500, Mike Frysinger wrote: that's fair. i'd also add that forcing the value into conf.d/clock forces a reliance on openrc and prevents alternative init packages (which we've seen people use). i know debian uses /etc/localtime, any one know what other distro conventions are in use out there ? Well, RH/RHEL/Fedora/CentOS/Mandrake/Mandriva all use /etc/localtime -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Item for 10 Jan 2008 Council meeting
On Wed, 2008-01-09 at 23:27 +0100, Jan Kundrát wrote: and you signed it as a Gentoo Developer Relations Lead. Umm... because that's her .sig? Wow. I'm really surprised that this concept is foreign to people. Are you saying that you need beer from the pub because of your signature? Are you speaking on behalf of pubs? Beer? Maybe mouths? (Yes, you can quickly see just how asinine the assumption is...) -- Chris Gianelloni Release Engineering Strategic Lead Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sat, 2008-01-05 at 04:32 +, Ciaran McCreesh wrote: On Fri, 04 Jan 2008 20:20:18 -0800 Chris Gianelloni [EMAIL PROTECTED] wrote: No offense to anyone, but holding back hundreds of developers and thousands of users for a handful of developers ...and how exactly are hundreds of developers and thousands of users being held back? So far as I can see, in cases where anyone really is being held back, the arch teams are quite happy to prioritise -- the people who go around moaning about 'slacker archs' rarely if ever actually have anything holding them back. If anyone has any examples of where they really are being held back and where they really have given the arch teams plenty of time to do something, I'd like to see them... Somehow I doubt it happens very often, if at all. It happened several times during the 2007.1 release cycle. Of course, I don't feel like wasting my time searching bugs to justify myself to you, so if you're interested, feel free to search on your own. Pretending it doesn't happen doesn't make it go away. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sun, 2008-01-06 at 23:34 +, Ciaran McCreesh wrote: Ok, so explain: * How perpetually open bugs are a maintenance burden. They don't generate emails and they don't require any work on the maintainer's part. Is the mere fact that they show up in queries all you're concerned about, and if so, have you considered either adapting your queries or requesting a special keyword to make such bugs easier to filter? I have foo 1.0, which is mips. There is foo 2.0, which is stable everywhere else. The foo 1.0 ebuild does not conform to current ebuild standards. I want to commit changes to foo 2.0, and repoman won't allow me due to problems in foo 1.0, but I don't want to WASTE MY TIME on foo 1.0, because it's been EOL for 2 years and I've had an open bug for mips to test the newer version for 2 years. I've asked several mips team developers, who all give me the same we don't have enough manpower/horsepower to test that right now excuse. * How unmaintained ebuilds are a maintenance burden. Doesn't that contradict itself? When repoman keeps me from being able to commit due to an ebuild that remains in the tree only for an architecture hardly anyone uses or cares about, that affects me. Now, I know that you're just being your usual self-absorbed argumentative self and I likely shouldn't feed you, but I thought that answering this might clear it up for the people who don't understand this as well as you do. This is especially true since you've been pretty much the main proponent for keeping things as they are with these slack arches. I mean, if vapier can maintain arm/sh/s390, by himself, to a better degree than the mips *TEAM* can do, that should be an indication of a problem. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sun, 2008-01-06 at 23:35 +, Ciaran McCreesh wrote: On Sun, 06 Jan 2008 14:09:24 +0100 Matthias Langer [EMAIL PROTECTED] wrote: This kind of conversation is not technical at all... Ciaranm, are you a MIPS user? If so, do you think that running KEYWORDS=mips is less likely to result in breakage than running KEYWORDS=~mips? I think you'd need a much larger sample than one to get any meaningful answer there (and it might be worth doing it across all other archs too, to find out whether mips is in any way anomalous). Are there even enough users to get a larger sample? Other than the like 3 devs still working on mips, I thought you were the only actual user. I mean, I've watched things in system get broken on mips and nobody even notices for several weeks. There simply can't be that many people who actually care if nobody even notices when *system* breaks. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Sun, 2008-01-06 at 11:36 -0600, Ryan Hill wrote: that has both sides happy here, but that won't happen if you don't admit there's a problem. He doesn't have to admit anything. He is neither an ebuild maintainer nor an arch team developer. Basically, his opinion is useless in this case, as *his* work flow is not affected. As such, I think we can simply just ignore him. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Reducing the size of the system package set
On Tue, 2008-01-08 at 00:30 -0800, Donnie Berkholz wrote: On 00:42 Tue 08 Jan , Diego 'Flameeyes' Pettenò wrote: Anyway, as having a complete dependency tree is almost impossible because of that, I have an alternative proposal: reducing the size of the system package set. Right now system contains stuff like ncurses, readline, zlib, autoconf, automake and m4, perl, gnuconfig, and so on. Those are packages that certainly would be part of any base Gentoo system, but are those actual part of the system set of packages? I sincerely doubt it. What is your goal? Is there something you're trying to accomplish that's impossible? It's clear that changing this would be a fair amount of work, and I don't understand the benefits. Come work on a Gentoo release some time. Implicit dependencies waste more time than pretty much anything else. Almost all circular dependency issues we currently have are due to implicit dependencies. Also, several things have been added either to system or (more commonly) packages.build, to try to work around these deficiencies in the tree. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Item for 10 Jan 2008 Council meeting
On Tue, 2008-01-08 at 19:59 +, Ferris McCormick wrote: 3) Most devrel requests seem really to relate to CoC violations. Would you like us to bounce those to the CoC people, process them using CoC rules, or keep doing what we are doing now (generally, close them with a note explaining why or mediate them)? (I'm talking about the He's being rude/sarcastic/disrespectful sorts of things which really need to be processed immediately and merit a warning or brief suspension if anything.) How hard is it to realize that the CoC is a superset of DevRel (and other) policies? If someone breaks DevRel policy (be good to each other) that also happens to be a CoC rule and someone reports it to DevRel, they should actually *do* something about it, rather than trying to pass it off onto someone else or spend months engaging in witless banter about whether there's even an issue or not. After all, when the CoC was enacted, never once was it said that it would override DevRel or otherwise make DevRel invalid. If someone comes to DevRel with a problem, you're supposed to try to work out the issue with them. It really is that simple. There's no need for some kind of territorial pissing match or passing the buck. Someone came to DevRel for help because they think DevRel can help them and it is DevRel's job to do so. The CoC was put in place to allow for catching bad behaviors *before* they would get to DevRel, without requiring someone to necessarily report the issue. Once a developer has reported an issue to DevRel, it's their job to work it using their own policies, as it then becomes a DevRel issue. The two things serve somewhat different purposes. The CoC was designed to curb or prevent bad behavior, where DevRel's job is to prevent bad behavior from recurring, or taking disciplinary action when necessary for repeat offenders. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Reducing the size of the system package set
On Tue, 2008-01-08 at 21:49 +0200, Petteri Räty wrote: Stefan Hellermann kirjoitti: I've tried to not use the system-set and set up a virtual called virtual/minimal-system which depends on all the packages I need (no gcc or perl, only coreutils, glibc, baselayout and some packages that are really needed for booting up). This is what I think should be the system-set. And there would be a development-set which most people would use, but don't have to. And maybe a set with packages like man, texinfo ... Probably would be useful to separate DEPEND and RDEPEND base systems. So things like gcc would only be needed for the DEPEND part. Be careful with this one. Lots of things end up linking with libstdc ++.so.* from GCC. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Wed, 2008-01-09 at 02:47 +, Ciaran McCreesh wrote: On Tue, 8 Jan 2008 18:44:22 -0800 Alec Warner [EMAIL PROTECTED] wrote: Uh... So where do the original problems come from? Are you saying that packages mysteriously start breaking on their own because no-one's maintaining them? Of course they do Ah, right. Because of the magical elf that lives in the CVS server that mysteriously goes around breaking dependencies when no-one's looking. Yes, a magical elf. Much more plausible than the theory that it's actually developers screwing up by dropping keywords or best keyworded version on a package's deps. Actually, nobody ever said anything about things that magically break. It's more the things like ebuilds with bad code that can't really be changed without a revision bump, which would also require the arch team in question to ACTUALLY DO SOMETHING to make stable. Seriously, your thinly-veiled attempts at deflecting the conversation to something that supports your pithy points is laughable. The issue that was raised is that certain arch teams are incapable of keeping up with the minimal workload they already have and what should be done about it. We want the Council to do something about this issue. You can deny the issue all that you want or try to deflect conversation from the actual issue, but your opinion isn't very important to the much of the current developer pool, seeing as how it doesn't affect you in any way, having been thrown from the project, and all. Now, if you have something possibly constructive to add to this conversation, as a user, feel free, but don't pretend like you're still a member of the mips team. You're not. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Fri, 2008-01-04 at 21:02 +, Ciaran McCreesh wrote: X and Y are pretty much irrelevant. The important factor is Z, the impact of leaving things the way they are. ...and the idea is to let the Council decide what level of Z is acceptable. Currently, it appears as if the issue is maintainers being forced to keep abhorrently old versions of packages, including security-vulnerable packages, simply because a security-unsupported architecture hasn't had time to test/update/whatever. This has been an issue for quite some time. Of course, the impact is debatable, but it seems that we cannot agree ourselves on what is agreeable, so I see this as a point to bring to the Council simply so it can be resolved once and for all and things can resume normal operation. I know that I, as an ebuild developer, would be much more comfortable/accepting of having to keep around old versions of packages, if the Council had deemed it to be something important enough. No offence to any alternative architectures or their hard-working team members, but there are some times when we have to look at the common good, and forcing maintainers to spend time keeping older ebuilds that are possibly using older ebuild code and other idiosyncrasies versus the current versions for the more mainstream architectures simply might not be worth it for architectures with a very minimal number of users. I've heard some suggestions for removing stable KEYWORDS on arches that aren't security supported. I see this as a possible solution to such issues, since ~arch packages aren't security-supported in the sense of GLSA and such, so why not keep arches which aren't security-supported from having stable KEYWORDS? Of course, this is a global change which affects multiple architectures, so it should be deferred to the Council. I don't really think it requires a large amount of discussion simply because it is simple to see how it would come to a swift stand-still. The arch teams affected will want nothing to change, the package maintainers will want to make things easier on themselves. This is to be expected. We elect the Council for a reason. Making decisions like this is one of them. Let's let them do their job and follow their leadership. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
On Fri, 2008-01-04 at 22:37 +, Ciaran McCreesh wrote: Really, I'd like to see some genuine examples of cases where people think they have a legitimate value of Z... How about we base X Y and Z on the number of verifiable users of said arch? That's just as arbitrary and fits with the normal pink ponies philosophy of pulling complete bullshit out of the air and using it as a justification or argument. Maybe we'll base it on how many months they've been security-supported? No offense to anyone, but holding back hundreds of developers and thousands of users for a handful of developers, who could do their jobs just as well without stable KEYWORDS, and an nearly as small number of users, just isn't worth it to us all. How many users do you really think breaking some of these arches affects? If the architecture (or its team) is incapable of maintaining stable KEYWORDS in a timely manner, why should we care about them, again? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [RFC] Some new global USE-flags
On Fri, 2007-12-28 at 05:53 +, Steve Long wrote: Chris Gianelloni wrote: branding: Enable Gentoo specific branding [questionable, as used for splashes/shortcuts/artwork] Well, my personal opinion here is that we should enable this by default on *at least* the desktop profiles, as providing sensible defaults and branding isn't outside the scope of the project. We still stay as close to upstream as possible with this stuff and only use it for branding or optional Gentoo-specific minor config changes. Also, it can still be disabled for people who want everything as upstream intended. I have no objection to it being flagged on by default in desktop profiles, but Gentoo-specific minor config changes concerns me, since I take it as given that installing for a specific distro implies config changes to work with that distro, and not having those because I have turned branding off sounds bad for me as a user and seems a confusion of purpose. (It could lead to more optional config changes bundled in future which wouldn't be apparent without knowledge of the ebuild.) Well, by this I meant something like bug #170059 which would mean changing the default home page (minor config change) to something Gentoo-specific. Not all config changes are for required functionality. Sorry, I had assumed that people on this list would be technical and able to realize this without it being explicitly spelled-out. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Thu, 2007-12-27 at 18:11 +, Ciaran McCreesh wrote: On Thu, 27 Dec 2007 18:03:27 + Roy Marples [EMAIL PROTECTED] wrote: On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote: Or to put it another way, you're objecting to painting the house pink rather than green because you don't like pink (because your last house was green too), ignoring that it's been demonstrated that when painted green, it's impossible to add a conservatory and central heating because the green paint will catch fire and kill everyone. Using your analogy you should then recognise that there is a strong dislike for pink and should seek a new colour that allows the building of said extensions. And what colour would that be? We've already ruled out purple, brown and yellow, and no-one has yet found any other colour of paint. Any chance we can back on, you know, the actual topic, rather than these useless analogies? Thanks, -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Some new global USE-flags
On Thu, 2007-12-20 at 19:57 +0100, Markus Meier wrote: novideo 5 These should probably really go away and use package.use and such to use the already-existing videos USE flag. branding: Enable Gentoo specific branding [questionable, as used for splashes/shortcuts/artwork] Well, my personal opinion here is that we should enable this by default on *at least* the desktop profiles, as providing sensible defaults and branding isn't outside the scope of the project. We still stay as close to upstream as possible with this stuff and only use it for branding or optional Gentoo-specific minor config changes. Also, it can still be disabled for people who want everything as upstream intended. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Patch make_desktop_entry to produce entries that validate better
On Sun, 2007-11-18 at 02:59 +0100, Daniel Pielmeier wrote: I have attached an updated patch. Thanks, Daniel. The patch has been applied. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Reminder: Set your Reply-To (was Re: [gentoo-dev] packages.gentoo.org lives!)
On Wed, 2007-11-14 at 13:22 -0700, Joe Peterson wrote: (Sorry for the previous reply to announce..) Let me take this opportunity to remind people to set a reply-to when sending anything to gentoo-dev-announce so people replying will reply to the proper place. Thanks, -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild
On Sun, 2007-11-11 at 21:01 +0200, Petteri Räty wrote: I plan to make the java eclasses use the EAPI 1 Any chance we can *at least* wait until we have a release out the door that has a portage version which supports these features *before* we start trying to use them in the tree? Our general rule was to not use features for 1+ years since it was added to a *stable* portage before we started using them. Now, this isn't so much of an issue with individual ebuilds, but you're talking about changing how the Java eclasses work, essentially blocking *anyone* using an older portage (including everyone installing from 2007.0 media) from using any package which inherits the eclass. Also, we should really think about this sort of thing before we start using it. How are we going to support EAPI changes in eclasses? What if I have an eclass with EAPI=1 features and I want to add some EAPI=2 features? I think allowing EAPI=* globally in an eclass should be prohibited, unless the *entire* eclass is planned for EAPI=* ebuilds, only. In other words, you'd need new EAPI=1 eclasses for your EAPI=1 ebuilds. Either that, or some way to say something like: execute code path A for EAPI=0 and execute code path B for EAPI=1 or something similar. I would suspect that the best current solution is to check EAPI in the individual functions and perform the right actions based on those functions, rather than marking an entire eclass. After all, only EAPI=* functions need to be hidden behind EAPI. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild
On Tue, 2007-11-13 at 20:31 +, Ciaran McCreesh wrote: That was only the case because previously, using new features that Portage didn't support would cause horrible breakage. Now, instead, the ebuilds show up as being masked. ...which is just as good as broken when it happens to a new user first installing Gentoo and wondering why he can't even follow the directions in the Handbook. What brought me to bring this up was the mention of changing of eclasses which support a large number of ebuilds, effectively masking a significant portion of the tree from our users. Let's say that I added EAPI=1 to eutils.eclass because I wanted to use some new EAPI=1 feature in one of the functions. Guess what? I've now managed to mask *portage* for users of older portage versions. In fact, I've managed to mask paludis and pkgcore, too. Yes, this is an extreme example. Yes, it is completely possible. Yes, that user would be completely screwed. Now, this isn't so much of an issue with individual ebuilds, but you're talking about changing how the Java eclasses work, essentially blocking *anyone* using an older portage (including everyone installing from 2007.0 media) from using any package which inherits the eclass. They just need to upgrade their package manager first. Easy. Expecting users to do pretty much anything on their own is broken behavior and should not be relied on for package manager compatibility. Also, we should really think about this sort of thing before we start using it. How are we going to support EAPI changes in eclasses? What if I have an eclass with EAPI=1 features and I want to add some EAPI=2 features? I think allowing EAPI=* globally in an eclass should be prohibited, unless the *entire* eclass is planned for EAPI=* ebuilds, only. Doing an entire eclass for one specific EAPI generally isn't a good idea since it's fairly likely that EAPI bumps will be a fairly common thing. In other words, you'd need new EAPI=1 eclasses for your EAPI=1 ebuilds. Either that, or some way to say something like: execute code path A for EAPI=0 and execute code path B for EAPI=1 or something similar. I would suspect that the best current solution is to check EAPI in the individual functions and perform the right actions based on those functions, rather than marking an entire eclass. After all, only EAPI=* functions need to be hidden behind EAPI. A solution with EAPI-agnostic code in foo-common.eclass and EAPI-specific code in foo.eclass, foo-eapi1.eclass etc is probably more readable and maintainable in most cases. Umm... So in the paragraph above, you say an EAPI-specific eclass isn't a good idea, and here you push it as the proposed solution. Huh? Consistency, please... I guess my real point is that we need to be *really* careful when using this stuff. It is *not* as simple as you make it out to sound. All it takes is one person adding an EAPI into an eclass somewhere to completely screw over a *huge* number of our users. I am just trying to point this out and hopefully get discussion going on how to utilize these great new features without potentially causing damage to our user's machines and our reputation. I still think that EAPI should not be allowed to be set in an eclass globally. All I can see is it causing problems for tons of users who don't have a clue what is happening to their systems. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Place of EAPI variable in ebuild
On Wed, 2007-11-14 at 00:39 +, Ciaran McCreesh wrote: Umm... So in the paragraph above, you say an EAPI-specific eclass isn't a good idea, and here you push it as the proposed solution. Huh? Consistency, please... Read it (and my explanation of it earlier in the thread) until you understand it. There is nothing consistent in what I'm saying. You are *so* correct. There really is nothing consistent in your replies. Rather, you've decided to pick and choose how you respond to maximize insult. It's *so* much easier to simply avoid any potential issues than to actually discuss them. As such, I've decided to quit responding to this thread until someone who wishes to actually participate in a discussion, rather than trying to win it comes along. Thank you for your input and have a nice day. I still think that EAPI should not be allowed to be set in an eclass globally. All I can see is it causing problems for tons of users who don't have a clue what is happening to their systems. EAPI *can't* be set in an eclass correctly anyway because EAPI is allowed to (and likely will in the future) change the behaviour of inherit. ...and this proves my point. Rather than simply stating this, you decided to post $diety knows how many lines of completely worthless information again and again. Had you simply said *exactly this* at the beginning, the thread/discussion would have been over. This is exactly what people mean when they say that they feel that you are not participating in discussions fairly. It's like you specifically hold back information that you know and bait people into saying things simply so you call put out the ace from your sleeve and point out how someone else is wrong. Yay! You win. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-print/cups: ChangeLog cups-1.3.4-r1.ebuild cups-1.3.4.ebuild
On Sat, 2007-11-10 at 16:14 +, Ciaran McCreesh wrote: On Sat, 10 Nov 2007 14:58:42 +0100 Daniel Pielmeier [EMAIL PROTECTED] wrote: Lucky you are that your native language is one of the world's most widely spoken languages. Imagine to express yourself in a language you are not familiar with! And when not speaking in my native language, I made damned sure I'm not just misunderstanding something before going around making all sorts of unfounded accusations in public. Please try to be the better man here and discontinue this current line of thinking. I ask you, instead, to look at Denis' email as a friendly reminder to keep things on a more civil level. As a native English speaker, I didn't see anything wrong with your comments, as they were directed towards code, not a person. Were the same comments made towards a person, yes, it would be offensive. Since not all of us are native speakers, sometimes just the simple replacement of a word can help change the tone to those of us not born in an English speaking country. I've noticed your civility of late and want to encourage you to continue. I would like to apologize if you feel ass if you've been baited or anything. I know Denis and know that wasn't really his intention, but rather to remind you (and others) to try to think about the word choices we make. Had you said odd instead of perverse, we wouldn't likely be having this conversation, though you and I know the functional meaning of the two words in that context are nearly identical. This is mostly the case with words with multiple meanings, where non-native speakers might not know all of the alternate meanings and can misinterpret your words. I know it has happened to me quite a few times. Thanks, -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Kolab2/Gentoo project
On Sun, 2007-10-14 at 00:05 +0200, Wulf C. Krueger wrote: On Saturday, 13. October 2007 19:27:05 Chris Gianelloni wrote: On Thu, 2007-10-11 at 13:11 +0200, Gunnar Wrobel wrote: The project has advanced far enough though that I feel it is a good time point to declare this a real Gentoo project. http://www.gentoo.org/proj/en/kolab/index.xml Umm... why? Why does a package need a project? Is this not just a mail server? It's a full-blown collaboration/groupware server and it will likely need a fair bit of coordination between different herds and maintainers as it uses several major F/OSS components which (at least until recently) need patches and integration changes to be usable with Kolab. http://kolab.org/about-kolab-server.html I don't mean any offense. I just want to know. Why do we need to create a project, which should normally be reserved for wide-sweeping changes or things that require massive amounts of coordination? Indeed. Having tried to use Kolab on Gentoo before, I assume it will be the latter that makes a Kolab project reasonable. Cool. In the future (this is to everyone), can we say this kind of information in the announcement message so we don't end up having to ask such questions? Thanks, -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: lame use flag, local to global
On Sat, 2007-10-13 at 10:37 +, Duncan wrote: Chris Gianelloni [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 12 Oct 2007 17:22:54 -0700: Steve Long wrote: Duncan wrote: Steve Dibb posted: there is more than one mp3 encoder. [S]houldn't the description mention that? How about: Prefer using LAME for MP3 encoding support It doesn't mention anything else, so it'll work in all cases. WORKSFORME =8^) InCVS... :P I've gone ahead and changed this. It isn't a harmful change, so I just went ahead and did it. Enjoy your newly modified description. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Kolab2/Gentoo project
On Thu, 2007-10-11 at 13:11 +0200, Gunnar Wrobel wrote: The project has advanced far enough though that I feel it is a good time point to declare this a real Gentoo project. http://www.gentoo.org/proj/en/kolab/index.xml Umm... why? Why does a package need a project? Is this not just a mail server? I don't mean any offense. I just want to know. Why do we need to create a project, which should normally be reserved for wide-sweeping changes or things that require massive amounts of coordination? Why is this not just a part of the net-mail herd? It *is* a mail system, is it not? -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: lame use flag, local to global
On Fri, 2007-10-12 at 07:26 +0100, Steve Long wrote: Duncan wrote: Steve Dibb [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 10 Oct 2007 07:55:01 -0600: The reason we have mp3 and lame use flag is because there is more than one mp3 encoder. In almost every case of the use flag being applied above, there is already support for another mp3 codec (ffmpeg). So, lame adds support for lame, not for mp3, which is also provided. In that case, shouldn't the description mention that? Something like: MP3 encoding support using LAME (as opposed to ffmpeg) What about when the next one gets added-- would it need to say as opposed to ffmpeg or lame? I agree where there's a choice, the ebuild should offer lame or ffmpeg or w/e, and where not simply mp3 (along with the encode/decode being orthogonal.) How about: Prefer using LAME for MP3 encoding support It doesn't mention anything else, so it'll work in all cases. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] lame use flag, local to global
On Wed, 2007-10-10 at 07:55 -0600, Steve Dibb wrote: Mart Raudsepp wrote: On T, 2007-10-09 at 21:03 -0600, Steve Dibb wrote: The little lame use flag has started showing up more in local use flags, and all for the same purpose, MP3 support using LAME libraries. I vote we move it into a global use flag. Any objections, let me know. $ quse -D lame local:lame:media-libs/libquicktime: Support LAME mp3 encoding local:lame:media-libs/mlt: Support LAME mp3 encoding local:lame:media-sound/abcde: Support LAME mp3 encoding local:lame:media-sound/gnusound: Enable lame support local:lame:media-video/mpeg4ip: Support LAME mp3 encoding in the server/mp4live Any reason to not use something like mp3enc flag instead at that point? mp3 USE flag is already global, and appears to mean mp3 decoding, so how about a general mp3 encoding USE flag? I guess merging decoding and encoding behind the same USE flag might be an option too. Ah, I knew this question was gonna come up, should have addresed it first time around. The reason we have mp3 and lame use flag is because there is more than one mp3 encoder. In almost every case of the use flag being applied above, there is already support for another mp3 codec (ffmpeg). So, lame adds support for lame, not for mp3, which is also provided. When there is just one mp3 codec used in an ebuild, then it makes sense to use just the mp3 use flag. Actually, the encode USE flag makes more sense, if encoding support is optional. Basically, it should be like so: A is a mp3 program/library, which can do both encoding and decoding. It doesn't use USE=mp3, at all, since it is solely an mp3 program. Encoding support is enabled via USE=encode. B is a media program/library, which can do both encoding and decoding for multiple formats. It would use USE=mp3 to enable mp3 support. It would use USE=encode (with mp3 support enabled) to enable mp3 encoding support. C is an encoder for multiple formats. It uses USE=mp3 for enabling mp3 encoding. D is an encoder for mp3. It uses no USE flags, since it is always a mp3 encoder. I'm sure I missed other cases, but you get the point. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/ncdu: ChangeLog ncdu-1.3.ebuild
On Sun, 2007-10-07 at 07:57 -0700, Alec Warner wrote: What about those of us suffering with Outlook!??! Umm... woodpecker has procmail on it. Every developer has access to procmail. Also, nobody forces you to use Outlook. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] new-style virtual/editor
On Fri, 2007-10-05 at 14:57 -0400, Olivier Crête wrote: On Fri, 2007-05-10 at 11:46 -0700, Donnie Berkholz wrote: How many packages depend on virtual/editor? Should it be a virtual at all? Tester_ !rdep virtual/editor jeeves virtual/editor - app-admin/sudo sys-process/fcron I think the answer is none that really should, I would favor just removing virtual/editor. Ehh... system also requires it. Removing the virtual means everybody, no matter what, will get nano and won't be able to remove it without portage bitching up a storm. Currently, you can replace nano with any editor that meets the virtual and it'll satisfy the system target. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: controlling src_test
On Thu, 2007-10-04 at 13:47 -0600, Ryan Hill wrote:
I usually disable tests on a per-package basis using /etc/portage/env
entries.
[EMAIL PROTECTED] ~ $ cat /etc/portage/env/sci-libs/fftw
NEWFEATURES=
for f in ${FEATURES}; do
if [[ ! $f == test ]]; then
NEWFEATURES=${NEWFEATURES} $f
fi
done
FEATURES=${NEWFEATURES}
here's a crappy little script to automate it.
See, I think this sort of thing is what we should be adding into
gentoolkit. It is something that is very useful, but not required for
running a Gentoo system.
--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Foundation Trustee
Gentoo Foundation
signature.asc
Description: This is a digitally signed message part
