Re: [gentoo-dev] Making the developer community more open
Well, I think a lot of what I've been thinking recently has already been said by Daniel. I'm actually in the middle of being inducted and I'm just concerned that I'm going to get extra responsibility without any real positive aspects for me. I don't really *want* access to check into portage, I don't know what I'm doing (yet) and I'm not certain I can invest the time to learn all the precise policy to ensure I don't make a mistake, or worse put up with the stress of worrying I'll do it wrong and affect the entire gentoo vmware-using userbase. What I tend to do is make ebuilds for things that I want to try out or things that are broken, and I'd really like to just keep on doing that, but have it more accessible to the rest of the userbase. I think the idea of a proxy is a good one. I don't know about a whole user repository though, because as Ciaran pointed out, one bad apple and everybody gets rooted. No one would trust it, so it wouldn't be worth it anyway. * It'd be a good idea to have a larger group of devs not dedicated to a particular project, but who can take user submitted ebuilds, vet them for nastiness, and submit them. They'll be officially contributed ebuilds, they won't get updated until either a dev offers to take them on, or the community offers to fix them. * I think also a larger number of bugzilla scouring devs could push through well tested (lots of positive feedback, no negative feedback) patches that the maintainers for whatever reason (aren't there, forgot about it, don't have the time) just aren't putting through. That would require bending the maintainer etiquette a bit though. * I guess a *quick* concise policy guide would help. Separate from the ebuild guide which is trying to teach you *how* to write ebuilds, this policy guide would tell you what MUST and MUST NOT happen in a good Quality Assured ebuild. For instance, if the various and sundry checks in repoman could be extracted for people to run over their own overlays without all the main portage cvs machinery in there, it would help them get *much* better trained in what makes a good ebuild and what doesn't. If it can already do that, then it needs better documentation. * Finally the mentoring scheme could perhaps be more streamlined. So rather than having an all-or-nothing gentoo developer membership. Those developers being mentored have a repoman-like interface that works almost exactly the same way, but instead of putting directly into0 the tree, it would submit to a holding area where an experienced ebuild writer can either send it back to them with comments, or put a tick next to it and pass it into the main overlay. This then would allow people to work up to becoming a full dev, and take their time over it. It would also offer a kind of buffer area for people who just want to help for a few months, their privilege levels don't have to rise too high. So these are some ideas. Sorry, I was trying to get these out concisely but tripped on my tongue somewhere along the way, hope they help generate some ideas... Mike 5:) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] coldplug and hotplug
I'd prefer, The first option (two yes/nos and a list) since it seems cleaner and more obvious. The only issue that I could see is where someone might want a service started by hotplug rather than coldplug or vice-versa. I honestly don't know anywhere near enough about the difference (up until udev starting using it, I'd always thought coldplug was just some random reimplementation of hotplug by someone outside the kernel). Anyway, if there's a legitimate reason why someone might want a service to be started by one but not the other then this won't work, otherwise I'd definitely go for it. Oh, and I'd like to re-iterate what Duncan said, Roy, your work on baselayout has made my time on ~x86 bearable. Whilst other packages may break, I've never not been able to boot my system. Thanks! 5:) Mike 5:) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] coldplug and hotplug
Roy, I think the complaint is the automatic loading of modules by udev. Seemingly in the udev Changelog this is referred to as "add udevtrigger to request events for coldplug", whereas it seems you're using coldplug to refer to the automatic starting of services. Is there another name for what udev's doing other than cold-plugging? If we can find one, perhaps that will help clarify the situation... Mike 5:) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Forgive me, I'm a little new at this and I really don't want to get involved, but since my inbox has seen nothing but this for the past day or two, I'm going to ask a few questions I'm interested in the answers to... First and foremost is, will adding this to the tree be used for function creep, whereby the next request to add to/alter the portage tree is backed up by "Well, the profile change was already added to the tree"? I wouldn't want a precedent like this set without the council reviewing it. Secondly, is that what's already being done by asking individual arch devs to add individual paludis profiles? Surely paludis would eventually require all archs to be there, or have I missed something (which I may have)? Having already added a file to the profiles directory, which caused a few posts on here earlier, and then having asked the question of all the devs so as to avoid a similar incident, and then received a mixed response, now specific people have been asked if individually they'll help get paludis in the tree. Doesn't that seem a little improper, perhaps? Thirdly has anything like this ever happened to Debian or the Sourcery group? If so how did they cope with it, and if not, how have they avoided it? As you may have guessed I'm of the, "You can do the same thing with an overlay, so why must it be in the tree". I am however willing to wait and see what the council says, why can't the changes to the tree wait until then, what is so urgent? I'm especially intrigued since all this is simply to no longer require portage as a dependency of system. Can't paludis peacefully co-exist with a portage installation for a little longer, until it's mature? Thanks, Mike 5:\ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Stephen Bennett wrote: > The > question is simply one of whether I can add a top-level paludis profile > without people complaining overmuch, or whether I have to go through > the arch teams and make sub-profiles in 4 different places under > default-linux/. That implies it's going to be added to the tree one way or another. You seem to have misplaced the third option of not adding anything to the tree. Mike 5:) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
Perhaps, The problem here is that the paludis team appear to have a conflict of interests due to their previous and/or current association with Gentoo. I know they've mentioned personal grudges, so despite not knowing who these people are, I'm going to assume they have a history with Gentoo. However, were a new package manager (such as Conary) to request on the Gentoo Developer list that the tree be changed to make their package manager would work slightly better, I have no doubt that they would meet a similarly mixed resistance. Whilst there may not be an easily explained technical reason not to make the change, there is no compelling reason *to* make the change either. Most likely the response to this message will be that Paludis isn't the same as Conary, and that it could eventually take over from portage. However, other portage replacements (such as pkgcore and the seemingly forgotten portage-C) have not required changes to the tree. No promises were made to the Paludis team concerning changes to the tree (as far as I'm aware), and I don't see how any external package management system could build their software *assuming* that they could eventually influence a distribution's package library. I am perfectly happy for Paludis to innovate in whatever manner it deems necessary, just as I am for Conary to develop, but (at the moment) as external entities to Gentoo. Hopefully the council meeting will clear all of this up, and I look forward to reading their decision... Mike 5:) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
Petteri Räty wrote: Defining required amount of activity for ebuild devs. I would like us to raise the required amount of activity for ebuild devs. Given that the low number of developers is ranked as our number one problem in Donnie's informal survey[1], taking any kind of action against infrequently-committing developers is likely to reduce the number of devs we have, and potentially make the problem worse. What benefits are you aiming to get from the suggestion? I can think og keeping the books tidy and reducing management time required to maintain the devs. Are there others I've missed? If they're worth the cost/effort involved with putting someone through the dev tests and getting them trained, then it seems a good idea, but otherwise probably not... Mike 5:) [1] http://dberkholz.wordpress.com/2008/02/21/redux-gentoos-top-3-issues/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
Petteri Räty wrote: If you can't manage weekly commits, you can't respond to security issues either. I can see your point, I was more thinking about developers who have maybe one or two small packages that don't have many version bumps or bugs. They may be entirely able to respond to security issues, but may not have reason to make the weekly commit quota. I don't know the habits of developers well enough to know if this is a reasonable scenario? I was under the impression that if a dev couldn't respond quickly enough to a security issue, the security team could take steps (mask the package, try to fix it) to ensure the package doesn't pose a problem (as is presumably the case now with devs who forget to mark themselves as away). Depending on the actions you envisaged (sending a warning email, marking as away or retiring) this could create a lot of extra work for little benefit. If it was simply a warning email it might not be very pointful, but marking them as away then it sounds like it could be useful and automated... 5:) Mike 5:) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: | Yeah, you only need access to one ebuild to do whatever you want to | user's systems. Perhaps then we should direct more of our efforts towards the GPG package signing system, so that when a dev becomes a libability, their keys can be revoked? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkf0xgsACgkQu7rWomwgFXrStgCglCcTvdRaEGMyOdU0qfhcG7w8 TuwAnj1Vmho+LPCqreZNKlNhSRBHUjQU =LjIi -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: | | Signing offers no protection against a malicious developer. | I had envisaged a system whereby when the tree was synced, as was some kind of master signed list of all acceptable dev-keys. Every package would also be signed, and would only be installed when signed. As soon as a dev becomes a liability their key is removed from the list/revoked. ~ On next sync any packages or package upgrades signed after the time of revocation would not be installed. There would be a window of vulnerability, but no bigger than with revoking a dev's access to the tree. Do you think this would offer suitable protection for users from a malicious dev or not? I understand there are difficulties with eclasses, etc, which is why the current implementation is still not widely used or mandated, but I'm more interested in the feasibility of the idea. Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkf0yu8ACgkQu7rWomwgFXrxOwCeKOdkiFhpknf/q/6jq1sPf70t 3xMAoJxlLYhweQspnIJe626TYdmeA3BQ =hKID -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 William L. Thomson Jr. wrote: | It's about quality not quantity maybe? It's about both, and getting the balance right is effectively what this boils down to (as do many discussions on -dev). There's those devs who want high levels of QA and those devs that want the latest/obscure/testing/rare packages. Generally the two sides play oppose each other. Personally I think having both super-devs (who do lots of commits, care deeply about QA and know their stuff intimately) and official-contributor type devs (those who maintain a few specialist packages when they can) is a good idea. Giving the undertakers more work by giving them more reports of potentially lax devs and requiring them to investigate seems a little wasteful to me. I'd far rather the undertakers spent the extra time on positive contributions to the actual distribution (rather than it's administration). So the still unanswered question appears to be, would we like Gentoo to have fewer packages and less choice but greater QA, stability and a feel of professionalism, or would we like to have more packages and choice but a worse QA record, make some mistakes, and have a more community-based feel? If you're going to try to answer this question please be delicate with your repsonses, in the past I can recall developers leaving over exactly this divide... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkf0y6wACgkQu7rWomwgFXoCRACdHKACZY9yjfetGKJ5JtRP6y6U YBkAniFzWanDJvUkXUe8XglBBBP9sXsk =mp9f -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: New global USE flag: keyring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alon Bar-Lev wrote: | If we know there may be a future problem, why make the next *VALID* | addition perform extra work? I think the reasoning is that whilst there may be a future problem, there currently isn't. If it gets changed to gnome-keyring, it will definitely requires all the users of the keyring USE flag to change it. ~ We could save them that hassle until there is actually a conflict? It's just a design decision, either we do, or we don't, but I don't think it's too big a deal. Depends if we want to be strictly correct, or delay a small headache for our users? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkgLdjAACgkQu7rWomwgFXrBDQCeJHUe52Czxdn41fyjmfSI7Fjt og4AoKhxy1B8rp6k/g8o2PFcBw2DLphm =RkIz -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] retirement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiya Duncs, Sorry to hear your time constraints have gotten the better of you finally. Best of luck with well-typed, I hope it proves interesting and that you bring much Haskelly joy to the world... 5;) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkgNxccACgkQu7rWomwgFXpiQgCgnQuYSH3lwN8UkPfJy+DQaFwW 57MAn2yeN2Ck4jC3OgIoGngg2eMW9aKL =umiM -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: new 'virtualization' project or herd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tiziano Müller wrote: | Hi everyone | | What do you think of creating a new 'virtualization' project or herd/team? Sounds like a good idea, there seem to be enough packages to warrant it. ~ Especially if you're finding shared packages and space for integration of components. | So, what do you think? As one of the primary vmware devs, I'm not sure that vmware easily fits into this group based on it's closed-source nature, and the complex (but just about workable) module system we've put in place. I also wouldn't want to muddy the virtualization email address with all the random vmware module bugs... 5:) I'm pretty happy for the vmware group to go under the virtualization herd, but I'd very much like to maintain the vmware email alias/assignment for bugs, and I'm not sure how much we'd be able to integrate with the larger group. Do you think it's worthwhile vmware joining the umbrella or should we just stay separate? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkglrH8ACgkQu7rWomwgFXo4EgCfRl05jk1I3jbfIXFdNtnaRRFB Up4AoKPc4t2OsIjI/4E+DCy2mRp4x8+b =uOzA -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: new 'virtualization' project or herd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tiziano Müller wrote: | That's true. How about having a virtualization project which takes care of | the common part, the docs and the coordination (if any) and have separate | herds for larger "subprojects"? Sounds ideal. 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkguUzwACgkQu7rWomwgFXrO0ACeIx8aTebKqkMKQe81bh/dm8mq wXMAnRUHPhfQJsaVy1shWRsdNUd1IP4w =bOB4 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: Should preserve-libs be enabled by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Mauch wrote: | The purpose of this is to keep the system operational after library | upgrades until all affected packages could be rebuilt and to simplify | the process, not to avoid the rebuilds. I couldn't find it mentioned in your email, but if portage is effectively doing reference counts, what happens when its reference count gets to 0? Once no ebuilds rely on the old library is it removed automatically, or do the "you need to rebuild these" message just go away? Is there a way to have portage delete the libraries once it's sure they're no longer necessary? If so, is that done by rebuilding the owning package itself, or by editing the owning pacakge's contents and removing the old library? Does @preserved-rebuild contain just the affected packages, or the package containing the old library as well? (i.e. Does an "emerge @preserved-rebuild" ensure that the old library will no longer exist on your system, or not?) Basically, if I can safely replace "revdep-rebuild" with "emerge @preserved-rebuild" then I'd be happy to keep it enabled. If it's going to leave cruft on the system (or then require manual rebuilds of packages containing preserved libraries to clear out the cruft) then I'd personally be inclined to turn it off and stick with revdep-rebuild... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkg+aSAACgkQu7rWomwgFXoR2ACeJnf+J/pd/GEEh5Ds/Q80sjOR vIkAoKEyLD2lTGfehoSoYLP6pH/R++2J =0sv1 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Volkov wrote: | Is there any reason why --as-needed is not enabled "by default"? There's still about 18 open bugs on the tracker[1] for it. You can see how many problems it had been causing by the huge number of blocking bugs. I've been using it for a pretty long time now (probably a couple weeks after Diego first blogged about it) and don't have many problems at all (now), but every once in a while a version bump or a new package will just fail to compile properly and the problem leads back to as-needed. I'm not sure whether ~arch users would be able to catch all the as-needed bugs before they hit stable, so I couldn't say whether it should be enabled by default or not. I also don't think it would completely eliminate the problems that Diego mentioned with preserve-libs (there could still be instances where bar and foo both NEEDED thing.so, but bar had been compiled more recently and needed thing.so.1 whilst foo needed thing.so.0, and starting bar would break trying to load both)... Mike 5:) [1] http://bugs.gentoo.org/show_bug.cgi?id=129413 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkg/qb4ACgkQu7rWomwgFXpl7wCdFhDuZbQOVy1b12dgXbZbSWtj dIMAn3Z6FDx5HW1KD83JxdboNrQOOap1 =Nca2 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: --as-needed to default LDFLAGS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ulrich Mueller wrote: | But maybe Emacs is an uncommon application, or I am looking for the | wrong things? Could one of the experts please shed some light on this? I think you're looking for the wrong things. I'm not an expert, but I think --as-needed means that if there are 20 libraries on your system that use libexpat.so.0 and 400 programs that use those 20 libraries, when libexpat is updated to libexpat.so.1, you only need to rebuild the 20 libraries, not all 420 packages (as you would do otherwise). I believe that's the main reason for using as-needed... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhBp9oACgkQu7rWomwgFXr8JQCfYFDwcebduPVaY3yqUIEfVOxp G80AoKV6SsAewxyyfv+fsiwbc6M1BHsc =12e5 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: | No, it results in a new open() on a file that's elsewhere on disk, which | results in two new seeks. You get about fifty seeks per second. The speed issues aren't really a concern, since the GLEP suggests that the ebuild must be sourced anyway. The GLEP allows for a .ebuild-2 file to contain EAPI="1". This requires the package manager to source the ebuild to find out exactly what EAPI should be being used. The GLEP doesn't strictly outline what happens to a .ebuild-1 containing EAPI="2" for a PM that supports EAPI="2" (which needs to be addressed before the GLEP gets put into action). It does say a developer should not specify both a pre- and post- source EAPI, but the GLEP says that if both exist the post-source one is used. ~ That means all package managers would have to source the ebuilds. Personally, as a developer, I don't want to be messing around with yet more numbers in the ebuild filenames, and I think it looks ugly. Not great arguments, granted. It also feels like a bad idea to separate information required to process the contents of the file from the contents of the file itself. P/PN/PV variables are used in clearly defined locations of the file, and the script could run under a different name and version (as proved by every version bump around). The suggestion seems to be that an ebuild could not run under a different EAPI. In that case, the EAPI version should be embedded in the contents of the file. As people have pointed out though, there's no need to rush this decision. We're simply not going to achieve backwards compatibility forever (we haven't in the past), so why not choose a time period to allow for upgrades (6 months, a year?) and implement a new EAPI definition mechanism that's present in the file and offers a slightly better compromise between the various parties than the current suggestion? It will require a little more patience, but it offers time for a thought out and well designed choice. What's the rush? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhOpDEACgkQu7rWomwgFXoFvgCeMxSfRiQLEZr3QyT+Bx4b5aNe /9EAnicrcCQTXxsliAeM4mdisgjO7abg =tGD8 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Kelly wrote: | Wrong. Thanks for that. I'm gonna assume you meant "I think you're wrong". | Sure, because of how the algorithm works, people could potentially do | both, but the GLEP makes it pretty clear that they shouldn't. It doesn't just say they shouldn't, it *says what happens if they do*: pkg-4.ebuild-2, EAPI="1" ~pre-source EAPI is 2, post-source EAPI is 1. EAPI 1 is used So to live up to the GLEP specification, package managers must source the ebuild to determine the correct EAPI. | Basically, you don't set the post-source EAPI. It is only supposed to | be used when the pre-source EAPI cannot be determined. If that's what was meant, the GLEP needs changing to say that. Something like: pkg-4.ebuild-2, EAPI="X" ~Pre-source EAPI is 2, post-source EAPI is X. In this instance the post-source EAPI is ignored, since a pre-source EAPI is set, so EAPI 2 is used. It's not a big deal, but it will need a change to the GLEP in its current form, if that's what's meant. Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkhPdRUACgkQu7rWomwgFXq1twCgqnFzBqQI8vl63faZ1cq27MF7 7ekAn0aA73nic1v/ovwAUuHsaL44MrTE =StC2 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: | And in amongst all of this, if you fight really really hard, you might, | after several months and a whole lot of people trying to kill you, | eventually get agreement upon some very minor technical point that's | necessary to start getting somewhere. So are you basically saying "You don't like fighting against Gentoo, and Gentoo doesn't like fighting against you?". I think I might have a mutually agreeable solution! 5:) And yet still you keep fighting? Why? What do you *need* from Gentoo that you can't get for yourself? A user base? A huge archive of ebuilds ready and working? A large set of mostly silent developers to maintain those ebuilds? There's a neat little project called Exherbo you might have heard of. It's trying to build up most of those things, and they don't put up with incompetent, unknowledgeable people, so I'm sure they'll let you in, and I'm sure you'll be happy there. Yet still, you seem to *need* something from Gentoo. Given that, it's bizarre that you're repeatedly disrespectful to members of its community. It seems an odd tactic to present yourself so poorly when you're in need of something... Obviously Gentoo is taking up a lot of your time (simply time writing replies to most every point raised on a thread), and you often seem frustrated by the level of people you have to work with. So perhaps you should direct your extensive energies exclusively at Exherbo? I'm quite happy to continue working in a friendly helpful environment, where simple questions are most often met with patient answers and people are given the chance to learn, improve and help out where they can. I'm happy to keep quietly maintaining my ebuilds and let the people whose packages I package come up with the new stuff. You don't seem to be, so perhaps this isn't the right place for you to contribute? ~ If you do want to contribute, perhaps you could consider the environment you're working in, and be more accommodating to it rather than fighting against it? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkha4OsACgkQu7rWomwgFXpdywCfQMLkDJTxJpEYbBbZcz0dTToC Nk8AoJU3SSKg1Iz7mqjhHRJDlHLwVNR1 =JegH -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seems, Slightly like an abuse of the RESTRICT variable. I had thought that RESTRICT was generally for when a normal ebuild needed a feature turning off (such as mirroring, strict checking and hopefully one day ccache). 5:) Overloading it with the live value doesn't seem to fit into that scheme... If there's need for a new class of ebuild information (such as a new way of categorizing ebuilds by feature), perhaps we should add an ebuild features variable specifically for the purpose? Are there many ebuilds where differentiating by inheritance is inaccurate? If so, I'd definitely suggest a new variable, if not then perhaps it's not worth the effort for the accuracy (there are eclasses for almost every type of live ebuild). If adding a new variable would require an EAPI bump (rather than simply being ignored by older versions of portage) then I'd still suggest against overloading a variable from its normal usage, especially if something better's already in the works. If we start adding bits and pieces against the naming convention for ease now, it has the potential to end up being ugly (and a problem that needs fixing) later down the line... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiUJIUACgkQu7rWomwgFXobdwCeJyvzTtdPLAC0AoqFM8O69ajl wwQAoLiFutlJw/LjHltw2uEAkCdPHNGU =gUMq -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: | Honestly I don't care what the existing scheme is. Fair enough, I don't maintain the code or have to deal with the complaints. It seems a waste to abandon an existing scheme though. Particularly since RESTRICT is an odd name for random boolean flags. Something like OPTIONS would be better, but it that can't be added/changed quickly. Is there an urgent pressing need for this? | primaryuri - Fetch from URLs in SRC_URI before GENTOO_MIRRORS. | Looking at the above list I say it's fair game to put just about any | boolean flag in RESTRICT. To me, almost every item in that list has "not", "disable", "restrict" or some other negative in it, which lets it fit into a restriction. Primaryuri is the only one that looks out of place. You did sound up for a name change though, and if nothing else please do change it. Our new users/developers that don't know RESTRICT is seen as a general purpose options flag will not find it intuitive and will definitely wonder what RESTRICT="live" means. Not everybody knows the ebuild format intimately, and allowing people to easily pick up what's going on is important... | That requires an EAPI bump, which also means that it can't be used | in ebuilds with EAPI 0 or 1. The RESTRICT solution is simpler and we | can use it right now in any ebuild. It is simpler, and as I say if there's an urgent need then go for it, but to me it feels like it's bolting on functionality into any space it'll go. Given that some time was spent changing all the "noblah" flags to "blah" to fit the RESTRICT name, it's a little disappointing to consider shoving extra flags in it now it all makes sense. This is a relatively minor point. In the long run, if people don't like it, it'll get QA bugged/ironed out, if they do it'll stay, you just asked for thoughts... 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiUT5cACgkQu7rWomwgFXqqdACfadwat4gS8/O4mX1zwcI+0VeU XawAnjbJa2LXHiK1VMN7ZBf9ICNK+dtl =572l -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] EAPI 2 Draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Buchholz wrote: > How is using the eclass better for bandwidth usage? It won't allow for > mirroring, and all users would have to checkout the repository from one > place. Furthermore, you cannot have (signed) Manifests that allow > integrity checks. - From what I understand of the idea, the eclass will just change the SRC_URI field from the first case (sf=tgz) to the second case (->). Eclasses have to be sourced before the SRC_URI is determined because they can already add (and presumably alter) elements of the SRC_URI variable. So I'm not sure how this would directly affect mirroring or manifests any more than simply using the -> notation? Could you explain what you mean when you say it won't allow for mirroring? Generating different tarballs is much more of an issue, and would impact on manifests too. I guess it's a try-it-and-see situation... Either way, it seems like the eclass idea would be a good compromise for those that don't want gitweb specific workarounds in the package manager, but would like to allow the flexibility for people who do? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjBJlYACgkQu7rWomwgFXowcACgt8wHN3OwRN9B19WHXVdn23BV xvYAn1URdx9VR3z3wFiRG3RqMTlAxaOC =crVS -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] EAPI 2 Draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Buchholz wrote: > How is using the eclass better for bandwidth usage? It won't allow for > mirroring, and all users would have to checkout the repository from one > place. Furthermore, you cannot have (signed) Manifests that allow > integrity checks. - From what I understand of the idea, the eclass will just change the SRC_URI field from the first case (sf=tgz) to the second case (->). Eclasses have to be sourced before the SRC_URI is determined because they can already add (and presumably alter) elements of the SRC_URI variable. So I'm not sure how this would directly affect mirroring or manifests any more than simply using the -> notation? Could you explain what you mean when you say it won't allow for mirroring? Generating different tarballs is much more of an issue, and would impact on manifests too. I guess it's a try-it-and-see situation... Either way, it seems like the eclass idea would be a good compromise for those that don't want gitweb specific workarounds in the package manager, but would like to allow the flexibility for people who do? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjBJlYACgkQu7rWomwgFXowcACgt8wHN3OwRN9B19WHXVdn23BV xvYAn1URdx9VR3z3wFiRG3RqMTlAxaOC =crVS -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Santiago M. Mola wrote:
> If you're just dealing with the default phases, it's not too hard to
> say in advance the exact command that will be executed.
If that's the case, why go so far as to define three new variables and
potentially put them out in the main variable area? If we've got
default_src_compile defined, we could do the following:
src_compile() {
default_conf="$(use_with blah)
$(use_enable flibble)"
default_src_compile
}
It then doesn't require *any* additional changes (except maybe to give
default_src_compile a well known variable name like $default_conf).
This is then only a single variable, and no more difficult to remember
than some of the eutils function names, and just as easy to look up.
It seems to allow the maximum flexibility, with the minimum changes to
package managers (assuming the defaults get into EAPI-2).
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkjE8vsACgkQu7rWomwgFXomRACgnvJZPSWEaSls4Fd+cy3T1cF5
UWQAoJ9fnZ82v5r2S/oz6GBo5Ot8iC9a
=pgRO
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: News item: World file handling changes in Portage-2.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marius Mauch wrote: > Maybe the best solution is to drop the non-prefixed versions of 'world' > and 'system' completely Deprecating the old syntax sounds like a sensible action to get people shifted onto the new system. I imagine it would work very similarly to "emerge info" at the moment? Speaking of which, when will that actually get removed (and does anyone know how long it's been hanging around)? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjHo78ACgkQu7rWomwgFXp5aQCdEmxjiguMc1qAszRPKE4dleYo VgoAnRuug4Or0kYPZgA3GylvPClkN5LK =iEfE -END PGP SIGNATURE-
Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeroen Roovers wrote:
> I spotted that too but didn't remember putting it in black and white. :)
>
> The order ("first maintainer as assignee" or "first maintainer/herd as
> assignee") is open to discussion and I think this is the proper forum to
> have that discussion.
It seems sensible to me. I would've thought that being more specific
would surely be better? Splitting them up means those who are mostly in
charge of a package see it easily, and it's also then easier to spot
packages that only have a herd, rather than them getting lost in all the
packages that do have individual maintainers...
I've attached a quick patch that should fix up assign.py to add all the
herds on the end. Since the order of the second item onwards doesn't
matter, all herds are added at the end. If we do need an ordering (like
maintainer1, herd1, maintainer2, maintainer3, herd2) then it'll need a
more complex patch...
Hope this helps,
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAklg7p8ACgkQu7rWomwgFXoDwACcCDBD5Dj/F//7Bxq+zIB1/GPZ
UHQAnA82J6UxuHva7uEXmEL9wuNDMkIk
=SRmT
-END PGP SIGNATURE-
diff --git a/assign.py b/assign.py
index 82d894b..c7c2c59 100644
--- a/assign.py
+++ b/assign.py
@@ -54,6 +54,7 @@ def get_pkg_cat(string):
def get_maintainer_for(directory):
""" returns a priority-sorted list of maintainers for a given CAT or
CAT/PN """
cc = []
+hcc = []
try:
if not heXML:
globals()['heXML'] = et.parse(HERDS)
@@ -65,7 +66,7 @@ def get_maintainer_for(directory):
if thisherd.findtext("name") == elem.text:
herdmail = thisherd.findtext("email")
if herdmail:
-cc.append(herdmail)
+hcc.append(herdmail)
elif elem.tag == "maintainer":
email = elem.findtext("email")
if not email:
@@ -75,6 +76,7 @@ def get_maintainer_for(directory):
cc.remove(email)
else:
cc.append(email)
+cc.extend(hcc)
except Exception:
pass
assign-patch.py.sig
Description: Binary data
Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Buchholz wrote: > Accepting the fact that different teams have different preferences, we > need to find a solution for them to set theirs individually. This could > either be the order of elements in metadata.xml (and would set the > preference on a per-package basis) or some attribute in herds.xml > (which would be a global setting per herd, and we'd need to find a > default). Ok, sounds like we've got some options: a) herds.xml per-herd priority flag (herd gets assigned) b) metadata.xml priority element (can be opt-in or opt-out) c) order of elements in metadata.xml I'm personally not keen on the order of elements, since adding meaning to the order might mean a fair number of misassignments until people fix the metadata.xml files. The herds.xml element isn't very specific, but if the herd-first rules apply to the whole herd, then it's probably the least-impact solution. Finally, if we think we'll ever need something more specific than herds.xml, we could add an extra element. or could be added to the minority case (I'm not sure which has fewer ebuilds, but if there's hard and fast rules this should be relatively automatable). More involved solutions could include wrapping the appropriate element in (what happens if there's no assignee tag), or adding an assignee attribute to one of the herd/maintainer tags (how can we ensure there's never two assignees). I'm up for whatever, with a slight preference toward not relying on ordering... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklg/AEACgkQu7rWomwgFXolAACgoujUIQs0AYRHK+JRoOsMiO41 HMkAoIHx5re/FOiD3GQNCR7fJ7xC3ebM =Sc4j -END PGP SIGNATURE-
Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Buchholz wrote: > * Order in metadata.xml is what dictates assignee, i.e.: The first herd > or maintainer listed in the metadata.xml of the first CAT or CAT/PN > is who is assignee, all other follow as CC. Great work, just wanted to double check the ordering though? According to [1], "When the file lists multiple entries, then you assign the bug to the first maintainer, and CC the other maintainer(s) and herd(s)." So it looks as though the file should go through the maintainers first and herds second? Should be pretty easy to fix... Keep up the good work! 5:) Mike 5:) [1] http://www.gentoo.org/proj/en/qa/bug-wranglers/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklg650ACgkQu7rWomwgFXpokwCgmocuZFPeNu6x9qXOml+DtI/a 3i0An0tGDd1va7VthoWrWyTyald9erxX =ksov -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Use full package atoms for bug reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: > Amarok2 - dev-db/mysql-community - ld: /usr/lib64/mysql/libmysqld.a > (client.o): relocation R_X86_64_32S against `client_errors' can not be > used when making a shared object; recompile with -fPIC Well, I fixed this individual instance. As Jer pointed out, it's in the bug-wrangling guide. Unfortunately the bug wranglers are only human, and sometimes some will slip through. If you find any more, it might be worth contacting a bug wrangler directly... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklhS6wACgkQu7rWomwgFXo5cwCePAVcKM2cJwY8SeXiDEHldzfl NycAn3JA5dtadT7Ip/4RDyoXODd8NEtY =PST+ -END PGP SIGNATURE-
Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: > Neither set of rules is ideal. Ordering makes a lot of sense when you > just read it. Consider metadata with multiple maintainers and multiple > herds. Either you have to start assigning explicitly (requires editing > metadata.xml), or you need to fall back to ordering. If you're going to > do ordering further down, why not do it from the start and be done with > it. Ok, I'm convinced. 5:) I tend not to prefer having "hidden" meanings, but as you point out XML is ordered, and you definitely made the case that it won't have a large impact. Fine by me... 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkljaG4ACgkQu7rWomwgFXq53gCeMRe+n+S6N2za00zuHjrge/gw nUIAniyeVK/RTlVUaR2Q3Eqw+5cCMIoU =01UN -END PGP SIGNATURE-
Re: [gentoo-dev] GLI Officially Deprecated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I realize it might be a bit obvious to us, but from reading it people might wonder how they're supposed to carry out installs now. When the notice finally goes out, it might be worth mentioning that just the LiveCDs are no longer supported, and mention how often the install media is produced, and basically how people should go about doing installs these days. It's so easy to misread these things and for people to start pushing out blogs and articles saying Gentoo's stopped producing release media, etc, etc... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkluG20ACgkQu7rWomwgFXqhlgCgn0W1kVdcA256EOpNIIozgkk/ 0y8An1ARvIFW8lFVjt78TmlkwU77W4gJ =/az4 -END PGP SIGNATURE-
Re: [gentoo-dev] Advice regarding backporting to Gentoo from Tin Hat.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiya Anthony, First off, it certainly sounds interesting and making it more accessible (simple ebuild setup and so on) seems like a good plan even if it doesn't get picked up officially. The best way to start development would probably be an overlay, which will make it easy to bring into the tree if/when a developer wants to pick it up officially. You might also want to look into integrating your "ramification" process into catalyst the gentoo release building tool (the release engineering team can probably tell you more about that than I can). Also, reading the TinHat front page and mention of ram dumping, you might be interested in [2]. It suggests not leaving the key in RAM when it's not necessary, but shoving it into the CPU cache... Mike 5:) [1] http://www.gentoo.org/proj/en/releng/catalyst/ [2] http://frozencache.blogspot.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmEcQgACgkQu7rWomwgFXp+3ACghLB+686vqMLqcEm9Ye3gM1JN KKQAoJ4R3dyx5KcVeg6+9OugRsCA0nha =MCQf -END PGP SIGNATURE-
[gentoo-dev] Last rites: app-emulation/vmware-esx-console
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Mike Auty (1 Feb 2009) # Masked for removal in 30 days. Old and unmaintained. # Vmware herd has no access to the product, and it's # for a very old version. See bug 143232. app-emulation/vmware-esx-console -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmGGYoACgkQu7rWomwgFXry8QCfangI+iJDf7QCdz19e//H+j7c VHkAn3p+BmdUVJHI1OgGO5xZiLykELAE =aqPd -END PGP SIGNATURE-
Re: [gentoo-dev] About prepalldocs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: > So until we have a decision on what the replacement will be I > don't see a need to remove current prepalldocs usage but any new usage > must be avoided. If it's simply discouraged, perhaps a repoman check, and some people to come forward with a better suggestion is all that's necessary? Once the new system's in place the repoman check can be made fatal, and suggest the new mechanism. That would save endless "do/don't" conversations on - -dev. It might also be worthwhile the council posting another official mail clarifying the position, so that we can all get on with our lives. Those that don't agree with the council can take the normal steps to bring their disagreement to their attention... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmcaWIACgkQu7rWomwgFXomBACeLkFewJjIieT0oA5uMcSWbJyO dO4AoKhF0PGFz//jWIH1FxhidJ6c9CEx =AKtW -END PGP SIGNATURE-
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: > 3) EAPI in locked down place in the ebuild > c) .ebuild in current directory > - needs one year wait I'm all for 1 or 3c, because we're not in any rush. I don't see why there's such an immediate need to make as drastic changes as are being suggested for GLEP-55, simply to allow for the possibility of future unknown ebuild mechanisms (like ebuilds not being bash scripts). If ebuilds change significantly from their current form, then and only then, would it be a good time to change the ebuild suffixes. I don't want to get an attachment from bugzilla and find I have to try four different file extensions because whilst the package and version were obvious from the bug, the eapi number wasn't. I also don't want to run into a situation where this package manager supports kdebuilds, whilst that package manager supports gnomebuilds, and a third one supports xfcebuilds. That's just recreating the browser wars, and will leave us with the likes of IE6. I'd be relatively happy with a shebang that specifies the parser or passes the ebuild version, as long as it was standardized, linear and supported by all the PMs (ie, some rogue PM can't suddenly start allowing a "myeapi" that only it can build)... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmlKQEACgkQu7rWomwgFXoRFACdHfDHuHhj7ojsQV5FvF+rRpRT PgQAoKTq6iAmNLC50a97JHrQghRZK6O0 =ELuP -END PGP SIGNATURE-
Re: [gentoo-dev] Git eclass update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tomáš Chvátal wrote: > I am throwing in full new eclass [1] and its diff [2]. Errr, maybe it's my eyes, but it looks as though the new eclass isn't the same as the existing eclass with the diff applied (for instance, git_src_prepare doesn't get called in the diff, but does in the new eclass). Also, base_src_prepare doesn't get exported if EAPI != 2, so I'm not sure what happens when it gets called from git_src_prepare (which can be called when EAPI = 0|1). Has anyone actually tried this on a non-EAPI2 ebuild? Lastly (and this happened in the old eclass, but I figured since it was getting an update now would be a good time to fix it), because checking out uses "--depth 1", it's possible for a checkout to fail (specifically if EGIT_BRANCH/EGIT_TREE is set on first checkout) since the required commitish may not exist in the shallow copy. The error messages thrown out are along the lines of "not a tar file", but I believe the ebuild continues, until it doesn't find the unpacked source. The possible fixes would be to: a) ask git to clone at a specific commitish (although I can see how to do that in git clone --help) b) see if there's a specific commit set, and then clone the whole tree c) see if there's a specific commit set, and if so trap the error message and offer a useful warning like "remove the repo and set EGIT_FETCH_CMD='git clone --bare'" Unfortunately a) and b) don't solve the problem of a specific commit being set by a user after the initial clone's taken place (in which case, if it's not in the clone there'll never be a way to get it from that checked out copy). Perhaps on an error during an update could clear out the git repository from distfiles/git-src and try again without a --depth? Clones made without a --depth entry that then fail would be an actual fail... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmuZk4ACgkQu7rWomwgFXoZ9wCbBh2BH7ERu+Ck/0W0IkLxHPU4 GW4An1DMBJ2rK+Hkb92U571QegW+VDhQ =aB2B -END PGP SIGNATURE-
Re: [gentoo-dev] Baselayout 2 stabilisation todo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Faulhammer wrote: > What else? As some of you might foresee, this can be as hard as a > major GCC stabilisation, so it must be well-planned and organised. Depends on which version of openrc gets stabilized in the process. We're currently working out some issues with 4.3.2-r2 in bug 270646 [1]. Mike 5:) [1] http://bugs.gentoo.org/270646 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoWfUgACgkQu7rWomwgFXpuVwCeLJRmQ4fparXM+fGzX4Ufr6Yj kkMAn1JzD8yGhiUUrEHaEJrDA0ZR8o75 =+r5R -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Baselayout 2 stabilisation todo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: > Or should I file the bugs? It seems no one else has and maybe the > maintainers don't have the config for what they're maintaining, or > otherwise don't see the warnings. I'm aware of the dm-crypt issue and will try and spend some time this weekend getting that into shape. If you do file bugs, please make them block bug 251730 [1], which is the deprecated warning tracker. Thanks... Mike 5:) [1] http://bugs.gentoo.org/251730 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoWoI8ACgkQu7rWomwgFXo0UgCeKTtnrZAR0y8rIdNSDOJRje1w F5MAoKr1jJIM/JtBJL+ibxmzkFIV96lB =AyNP -END PGP SIGNATURE-
[gentoo-dev] The VMware packages are in need of a maintainer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Everybody, Last week I stepped down from the vmware herd, and since I was the only member left, there are no more maintainers for the vmware packages in the tree. The current packages are vmware-workstation, vmware-server, vmware-player, vmware-modules, and open-vm-tools; and there are two more that should probably be masked and removed (vmware-dsp and vmware-gsx-console). All emails being delivered to vmw...@g.o and all bugs assigned to the vmware herd are going unread. The software is effectively in the maintainer-needed group, just with its own email address. As such, for vmware to continue to be supported under Gentoo we need some developers or new recruits to look after the packages. If you want to help look after these packages, please contact me (off-list) and I'll be happy to start training you in how the ebuilds/eclasses work and give you guidance about how vmware packages their software. If you're not a Gentoo developer yet, but are interested in becoming one to look after the vmware packages, do also feel free to contact me and we can look at getting you recruited. The sort of information you'll need to become a Gentoo developer is available at [1], [2] and [3]. The kinds of challenges you'll be dealing with are mostly kernel related, ensuring that the modules are working with various gentoo supported kernels, etc. The current vmware installer is written in python, whilst previously a perl script was used, so knowledge of both of these languages would be advantageous. If you've got any other questions or comments, again feel free to contact me. Mike 5:) [1] http://www.gentoo.org/doc/en/index.xml?catid=gentoodev [2] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml [3] http://devmanual.gentoo.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoYajUACgkQu7rWomwgFXo9lACdEnYCocadAGfMKKeXZFK7Rqni XK8An2P5Akzf4WzIVyIrlxPYXMSaEK3p =KmWx -END PGP SIGNATURE-
Re: [gentoo-dev] Baselayout 2 stabilisation todo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roy Marples wrote: > Attached is the new conf.d/net sample. Sorry, I missed those. Did lists.g.o remove them, or were they not attached? > As such, a side project I've started is a new ifconfig tool > [1] to handle everything from vlans, to bridging, to bonding, to > wireless (up to WEP) with a similar syntax to the BSD ifconfig. Also [1]'s missing, and I couldn't find it at http://roy.marples.name/. Where should I be looking? > This decision is heavily influenced by NetBSD (disclaimer - I'm now a > NetBSD dev). Congrats on becoming a NetBSD dev! 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoYdCoACgkQu7rWomwgFXq5NwCfdI7nIk7Am0goWcbip9eCWBE/ iHgAnjHS2V/HpvngD9EUmnBa3ZNCUk4D =aiQu -END PGP SIGNATURE-
[gentoo-dev] Adding Nipper license to the tree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiya guys,
One of the packages I maintain (nipper) has recently undergone a change
of license, from being GPLed to a new license that whilst mostly being
commercial features a non-commercial/personal use element.
Due to the new license (and the no redistribution of any kind bits) the
package will need mirror/fetch restrictions, which is fine. My concern
is with the copyright clause which states:
"Any patches or updates that the Licensee may develop for NIPPER must be
immediately submitted to the Licensor. In addition, the Licensee will
forthwith transfer without charge all current and future rights
including copyrights and other intellectual property rights relating to
such updates to the Licensor."
I'm wondering how this might affect any in-tree patching, because whilst
I'm aware of this clause and happy to send any patches upstream and/or
not patch at all, I can't say the same for every Gentoo dev that might
want to fix a problem.
I know the upstream author personally, and he's providing the
source-code primarily for Gentoo users (we can always use the existing
binary RPMs if patching is an issue), but I thought I should ask what
the best course of action would be here?
Thanks,
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
iEYEARECAAYFAko1XWYACgkQu7rWomwgFXpWYACfaJO7c77PVD4kuEsPrLOG7Qsx
Sw0An1JswTwSB0Asa2BEUQZyS4OBGbeE
=rinb
-END PGP SIGNATURE-
LICENCE AGREEMENT FOR NIPPER
This is a binding, legal agreement between you the end user (the "Licensee")
and
Titania Limited (Company Number 06870498) whose registered office is at 46
Cormorant
Rise, Worcester, WR2 4BA, United Kingdom (the "Licensor") for the use of the
Nipper
software products ("NIPPER") and electronic documentation (including the Nipper
SDK).
By installing, copying, downloading, accessing or otherwise using NIPPER you
agree to
be bound by the terms of this Agreement. If you do not agree to the terms of
this
agreement you may not download, install or use NIPPER.
1. Definitions
"Computer" shall mean a device that NIPPER is installed on/run from.
"Device" shall mean a device for which NIPPER is used to produce a report.
"Commercial Use" shall mean any use of Nipper for profit whether by or for the
Licensee or for any person, organisation, government or government department.
For
the avoidance of doubt Commercial Use includes the use by the Licensee in the
course
of research funded by a commercial organisation.
"Non-Commercial Use" shall mean any use of NIPPER (by an individual) which is
not
for profit.
"Subscription Fee" shall mean the fee payable for a Commercial Use Licence.
"Subscription Period" is the period renewable every 1, 2 or 3 years (as defined
by
the subscription) from the date the Subscription Fee is paid for which the
Licensee
may use NIPPER on a specified number of individual Devices.
2. Licensed Software
2.1 This Licence relates to all versions of NIPPER developed by the Licensor.
The
Licensor reserves all rights.
3. Grant Of Licence
3.1 End User Commercial Use Licence
3.1.1 The Licensee may only use NIPPER after paying the Subscription Fee. The
Subscription Fee shall be determined in accordance with the Licensor's (or the
Licensor's reseller's) price list which shall be available from the Licensor
(or
the Licensor's reseller's) on request.
3.1.2 The Licensor grants the Licensee a non-exclusive, non-transferable
licence
to use NIPPER during the Subscription Period.
3.1.3 The Licensee may only use NIPPER for the number of licensed Devices
during
the Subscription Period. Any additional use will require the payment of an
additional Subscription Fee.
3.1.4 The Licensee may only install NIPPER on Computers owned by the Licensee.
The Licensee may install NIPPER on any number of Computers owned by the
Licensee.
An exclusion is made where the Licensee provides a managed service, then the
Licensee may additionally install NIPPER on devices managed by the Licensee.
3.1.5 The Licensee may not sell or re-sell NIPPER or otherwise share, exploit
or
allow it to be transferred to any person for value or for Commercial Use.
3.1.6 The Licensee may not rent, lease, hire out or lend NIPPER.
3.2 System Integrator Commercial Use Licence
3.2.1 The Licensee may only use NIPPER after paying the Subscription Fee. The
Subscription Fee shall be determined in accordance with the Licensor's (or the
Licensor's reseller's) price list which shall be available from the Licensor
(or
the Licensor's reseller's) on request.
3.2.2 The Licensor licenses NIPPER for use in commercial products developed by
the Licensee where NIPPER comprises not more than 50% of the product's
functionality ("the Licensed Product").
3.2.3 The Licensor grants the Licensee the right to integrate NIPPER using only
the NIPPER API, library and executables developed by the Licensor.
3.2.4 The Licensor grants the Lic
Re: [gentoo-dev] Adding Nipper license to the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: > The website stills says GPL v3: > http://nipper.titania.co.uk/licensing.php Yep, the website's going to be updated for version 1.0 (with the license change). > ... I can't really comment on a lot of this, unfortunately. > Similar to the TrueCrypt issue, I'd say do NOT commit any ebuild covered > by this license until the matter is resolved. Yeah, that's what I was afraid of... > ... legal comments ... Again, I'm afraid I can't really comment on these, but thank you for the analysis, it was much appreciated to have a second pair of eyes look this stuff over. >> Any patches or updates that the Licensee may develop for NIPPER must >> be immediately submitted to the Licensor. In addition, the Licensee >> will forthwith transfer without charge all current and future rights >> including copyrights and other intellectual property rights relating >> to such updates to the Licensor. > Gentoo is NOT a licensee under any of the classes of use listed in the > license. We don't use it, and we're not a commercial integrator. Ergo > there is a loophole that allows us to patch it without losing our rights > to the patches. HOWEVER, I'd be concerned that the context > (non-modified) portions of the path are still bound by the original > license, and would violate non-distribution. I'm not keen on relying on loopholes. If I did still want to try and get a version of this into the tree, would packaging the binary RPM seem a reasonable solution? It's a shame given that the sources are potentially available (primarily released for Gentoo) and no real problem with making an ebuild, it's just the legalese... 5:( So I'll leave the source version out of the tree, but I'd like thoughts on using RPM as a solution? Also I don't know whether an exception could be made for Gentoo, but equally I don't know how to phrase one of them either (Gentoo Foundation or all Gentoo developers), so I'm hesitant to ask. If anyone has any other ideas or possibilities, do let me know. Thanks... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAko24AoACgkQu7rWomwgFXqEKACgsibF2QEaIB8t+flrhA0wHMMp Y0gAn3qesB0Li4DmRrquiXCEmUkDfbA6 =nvtn -END PGP SIGNATURE-
Re: [gentoo-dev] Standalone libstdc++
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Казанков Александр Владимирович wrote: > Hello. Hi, Could you please file all this information (and the output from "emerge - --info" at https://bugs.gentoo.org/. This mailing list is for technical discussions, whereas the bug tracker at https://bugs.gentoo.org/ is for problems such as compilation issues or when things go wrong. Thanks, Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkpFBX8ACgkQu7rWomwgFXpaeQCeNuRMyqZIjxMjFIT0nknMqjsz hhgAnRzw7ID7FUP2XKAzCffd6Na10RSg =LYVG -END PGP SIGNATURE-
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
On 08/02/18 20:55, Mike Gilbert wrote: > However, there are plenty of examples of commands that normal users > may run from sbin. Hiya, I'm not really for or against the idea, but whenever the justification for something is "there are plenty of examples" it's really helpful to have a number of them listed so that people can see what actual benefit is being provided by the change. Could you name a few of the most common/important examples so that it's part of the discussion please? Mike 5:) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On 10/03/18 14:52, Pacho Ramos wrote: > This packages are now up for grabs: > ... > dev-python/mypy > ... I can look after this one if nobody else wants it? Mike 5:) signature.asc Description: OpenPGP digital signature
[gentoo-dev] How to deal with git sources?
Hiya, I'm trying to update/package up mypy for the main tree which, whilst it provides a release tarball, relies upon a data library (typeshed) which does not provide releases. The recommended method of installation by upstream is to use git submodules (which the ebuild will do happily), but repoman rightly complains about LIVEVCS issues. Is the current recommended method for dealing with this to manually create a tarball and stash it on dev.gentoo.org somewhere accessible or are there updated guidelines for this kind of scenario? If so, where would they be documented? Searching for LIVECVS found a bunch of repoman change discussions, but no documentation as to how to deal with ebuilds that require this... Mike 5:) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] How to deal with git sources?
So, tldr; Github will tarball up specific commits (or master) for you to add to SRC_URI. I ended up using the github API to pull down a tarball of the git repo, rather than using git to pull it down. I suppose that offers the ability to Manifest it and check for changes, but I now have to encode the fixed commit into every version of the ebuild because the only location it's recorded is in the submodule commit hash of the package's repo. I could have it live in the PV, but I think that'd lead to potential version sorting errors if people try and use copies of the ebuild. Making typeshed its own package doesn't help because it's installed under /usr/share/mypy/typeshed, not /usr/share/typeshed so it really is part of mypy (for now). So I'll see how this goes and listen for feedback... Mike 5:) On 11/03/18 18:05, Mike Auty wrote: > Hiya, > > I'm trying to update/package up mypy for the main tree which, whilst it > provides a release tarball, relies upon a data library (typeshed) which > does not provide releases. The recommended method of installation by > upstream is to use git submodules (which the ebuild will do happily), > but repoman rightly complains about LIVEVCS issues. > > Is the current recommended method for dealing with this to manually > create a tarball and stash it on dev.gentoo.org somewhere accessible or > are there updated guidelines for this kind of scenario? If so, where > would they be documented? Searching for LIVECVS found a bunch of > repoman change discussions, but no documentation as to how to deal with > ebuilds that require this... > > Mike 5:) > signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-vcs/giggle
# Mike Auty (22 Jun 2018) # Not maintained upstream, at least one bug and three upstream bugs # Removal in 30 days. Bug #658264 dev-vcs/giggle Mike 5:) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Developer GitHub usernames
Hiya, It wasn't clear how to get added to the github team in the first place, but I've got the same username on github as I use for my gentoo handle (ikelos). I've also now got my ike...@gentoo.org GPG key verified on there if you're after confirmation. Thanks! Mike 5:) On 21/11/16 09:01, Michał Górny wrote: > Hi, everyone. > > I've finally found a little time to work on syncing our teams to > GitHub. For this reason, I've prepared a mapping from Gentoo developer > names to GitHub usernames: > > https://github.com/mgorny/dev2github/blob/master/devs.json > > I've filled it based on people in our GitHub developers team. Some of > the developers are certainly missing there. Since some of our people > don't want to admit they're using GitHub or otherwise want to pretend > they're not, and some of the developers are already retiring I didn't > go forward attempting to find more people. > > Please ping me if you're mapped to an empty string (i.e. no GitHub > account) and would like to get added to teams on GitHub. I'll invite > you to the developers team then and add you to the list. Thanks. > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Developer GitHub usernames
Sorry for the spam! Apparently the sender of list mails isn't the actual author of the message. 5:S Mike 5:) On 21/11/16 09:27, Mike Auty wrote: > Hiya, > > It wasn't clear how to get added to the github team in the first place, > but I've got the same username on github as I use for my gentoo handle > (ikelos). I've also now got my ike...@gentoo.org GPG key verified on > there if you're after confirmation. Thanks! > > Mike 5:) > > On 21/11/16 09:01, Michał Górny wrote: >> Hi, everyone. >> >> I've finally found a little time to work on syncing our teams to >> GitHub. For this reason, I've prepared a mapping from Gentoo developer >> names to GitHub usernames: >> >> https://github.com/mgorny/dev2github/blob/master/devs.json >> >> I've filled it based on people in our GitHub developers team. Some of >> the developers are certainly missing there. Since some of our people >> don't want to admit they're using GitHub or otherwise want to pretend >> they're not, and some of the developers are already retiring I didn't >> go forward attempting to find more people. >> >> Please ping me if you're mapped to an empty string (i.e. no GitHub >> account) and would like to get added to teams on GitHub. I'll invite >> you to the developers team then and add you to the list. Thanks. >> > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] bzipped manpages
Hiya Jan, The following snippet from Ingo is correct: > So, you want to hear something constructive? Your best option is to > just decompress that stuff on your system. (Gentoo is famous for > its excessive configurability - maybe there is even an option?) We are both famous for our excessive configurability and there is even an option already! 5:) If you look in the manpage (once you've decompress it somewhere, or online at [1]) for make.conf, you'll see the entry for PORTAGE_COMPRESS, which you can set as follows: PORTAGE_COMPRESS="" As mentioned in [2,3,others]. You'll then need to reinstall all packages. If you manually decompress the files, then the uncompressed manpages won't be registered with portage and won't get removed if the owning package is uninstalled. Hope that helps... Mike 5:) [1] https://dev.gentoo.org/~zmedico/portage/doc/man/make.conf.5.html [2] https://blog.flameeyes.eu/2007/12/a-word-against-ecompress/ [3] http://www.gossamer-threads.com/lists/gentoo/user/286024 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/08/13 11:38, Samuli Suominen wrote: > i'm not volunteering but I never really got why our GNOME > maintainers insisted on staying with it instead of going with the > distribution after it was clear logind is a dead end on non-systemd > systemd Ok, So there's lots of people that don't want systemd. Can't we group together and have some kind of an affect on upstream? Upstream appears to be suffering the same split we found with portage, in that the specification that people are working to is in fact the only implementation (as least, that's how I read the fact that a separate logind which follows the specification will no longer work without systemd explicitly?). We now have paludis, pkgcore and the PMS. Is there some way, we as the Gentoo Foundation, Developers or even just Users can form a petition, or an open letter, that might make enough impact on the Gnome foundation for them to reconsider their position? Perhaps if there were an "init system specification" project, separate from systemd, that systemd had to adhere to rather than deciding to change the rules at a random version (like 205), then Gnome could potentially have other options than just systemd? Does anyone know how Gnome is dealing with being run under non-linux systems given the new systemd hard dependency? Is it simply not shutting down, etc? Can we introduce a similar build capability so that people can have a "non-full" Gnome installation that still includes most of the apps? Either way, bickering amongst ourselves won't have any effect, fighting against upstream's changes seems similarly futile (they have no reason to improve the situation if we're happy to do the extra work when things are bad), so the best chance we have is communicating with upstream and asking them to reconsider. That's not guaranteed to work, but focusing our efforts on that, rather than lengthy arguments about time-intensive Gentoo solutions seems like a better option... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlIEAiAACgkQu7rWomwgFXpYUgCgk+XJynbo4MCRcFlqHrYtDgyV U+UAnAnn6tnrYYx/3ptOU7EGJF0efCyu =R4BF -END PGP SIGNATURE-
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/08/13 22:06, Pacho Ramos wrote: > Anyway, are you sure openRC is better than systemd for desktop > systems (for deserving the effort to keep maintaining consolekit, > that is currently orphan, cgroups stuff and any other things I am > probably forgetting now) ? In that case, if you decide to try to > suggest that to upstream, I would try to contact with Ubuntu/Debian > guys, openBSD maintainer and Solaris one (Brian Cameron I think) I'm not, systemd may be excellent for desktop systems, and for binary systems that can build it once and have it work fine it may fit the use case perfectly. I do believe that openrc is a more reliable init system (not least because, after having tried to swap to systemd, I was presented with a kernel panic and no rescue shell, which realized all my fears immediately). Cgroups, and other new features may be excellent, but I'm not in so much of a rush that I can't have things that need them started from a small reliable init, rather than instead of it. Thanks for your suggestions, I know the Gnome Gentoo guys and lxnay have tried hard to maintain the option of not using systemd, and I really appreciate all the hard work you guys put in. I'm more disappointed in Gnome itself for failing to be happy at being a great Desktop Environment, and instead dictating the rest of my operating system requirements for me... Mike 5:\ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlIENSQACgkQu7rWomwgFXr4zQCfejaFh0R2Dslx07E9zOeZT1mc IKwAnRsZwH7CHDoxHbIhk32g7SNn3O+A =kRAJ -END PGP SIGNATURE-
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/08/13 00:19, Greg KH wrote: > Become upstream developers and create fixes to remove the > dependancy either by working on openrc features to emulate the same > things that systemd has that GNOME requires, or split things out of > GNOME so that it does not require systemd dependencies. > > But to complain to upstream without providing patches is a bit > futile, don't you think? That's not how open source projects work, > we all know that. > > greg k-h > I would like to think that open source developers working on such a large and integral project might listen to their users. The way open source is supposed to work is that people write something, and if it's good people use it, and if it's not they don't. I would very much like to have seen systemd succeed, but based on its own merits, whereas it seems to have been accepted by being championed at certain distributions, made indispensable to desktop environments like Gnome, and by dropping the responsibility of developing udev in favour of developing systemd. I have heard the systemd developers say that no one has been forced to use systemd, and that in the open source world, if I don't like something I can write something different. That's a wholly selfish perspective, each and every person that contributes to open source does so in their own way, and we're entirely dependent upon each other to make the community and choices as vibrant as they are. I could be a KDE developer, or a Gentoo documenter, or work on mplayer. All those people are open source contributors and necessary ones, but that doesn't mean that any of them necessarily has the skills or the time to look after udev. Does that invalidate their opinion on the choices of upstream project they rely on? There are certain key projects (like the kernel, glibc and udev) which nearly every system has come to rely upon and, I believe, with that reliance comes responsibility. I wouldn't expect Linus to just one day and walk away to go developing a new kernel he thought was better, but he could. If he did though, I would expect him to leave infrastructure in place behind him to look after the project he made which people all over the world now depend upon, and I'd continue using that until his new kernel had proved its worth. I certainly wouldn't expect him to use his natural monopoly to force his new idea on everyone! I'm not trying to hinder advancement, the trying out of new ideas is what open source is all about. We've got source-based distributions because someone wanted to see if it would work, it did and there's a good community around it. However, that hasn't come at the cost of binary distributions, they both co-exist peacefully and people use whichever one they want. I don't have the skills to make a difference, so all I can do is vote with my feet. Even after sticking with Gnome 3 through its early phases, I don't think I can continue using it at this point and I am investigating alternatives, one of which is to try to remind the Gnome developers, if not the systemd ones, of why UNIX succeeded even with such a distributed development base; it was not because of enforced uniformity... Mike 5:\ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlIENyAACgkQu7rWomwgFXrv9wCdGHA4IhltnJBSt/2uY1XP6Xcs QM4AoKS2V5AWgfD+EAeyE43Jm1hwRaVT =DcNA -END PGP SIGNATURE-
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/08/13 10:35, Tom Wijsman wrote: > Listening comes at a price; you can't listen to everyone at the > same time, all you will hear is noise because all the voices clash. > So, you've got to listen to a selective bit of users and satisfy > them; after all you can't satisfy everyone. Resources are > finite... That's exactly why I'm trying to get all the frustrated voices on the Gentoo-dev mailing list making one single concerted comment to the developers, so that they only need to listen once, and can see from the number how many people feel the same way... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlIFcToACgkQu7rWomwgFXo0UgCfXYsL4VtS2HjWDxop5+E6mFJQ 6mQAnjM6fQqDSL6xGigE0AncqyqQjIhJ =Enah -END PGP SIGNATURE-
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/08/13 21:32, Tom Wijsman wrote: > On Sat, 10 Aug 2013 03:11:55 +0800 Ben de Groot > wrote: > >> On 9 August 2013 21:57, Michał Górny wrote: >>> This one is *so special* just because we have a few folks >>> which really have nothing useful to do and instead spit their >>> systemd hatred on gentoo-dev@ and expect others to join their >>> stupid vendetta. >> >> Please keep your insults off this list. You may want to deny >> them, but there are valid reasons why people oppose systemd. It >> doesn't help to keep so aggressively pushing it. > > Neither does it help to make statements like "People are free to > use a saner desktop environment..." which add nothing to the > discussion, which in fact can be seen as an insult as well; because > "sane" basically stands for "free from mental derangement" or "free > from being unreasonably, unsound judgment or bad sense" where both > come close to what people will perceive as the negative form of > "stupid". I'm not sure where you're quoting from, it doesn't appear to have been the thread Ben was commenting on. I'm glad someone stepped in and said something, Michael's comments appeared overly aggressive, as they would have even if the word hatred had read agenda. I'm not sure why there were so many rebuttals of his request to keep things civil. It wasn't a statement for or against systemd, it was a request to maintain a hospitable environment... Mike -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlIFe/gACgkQu7rWomwgFXr5sACeJkIl6rDKmyVdNmaQW9HupK35 s4MAn3EvU9agxaAOJI5Gf7uHUqcEJ7Mv =x6Dm -END PGP SIGNATURE-
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/08/13 23:42, Wulf C. Krueger wrote: > On 09.08.2013 02:26, Mike Auty wrote: >> I could be a KDE developer, or a Gentoo documenter, or work on >> mplayer. All those people are open source contributors and >> necessary ones, but that doesn't mean that any of them >> necessarily has the skills or the time to look after udev. Does >> that invalidate their opinion on the choices of upstream project >> they rely on? > > Yes, it does. In that situation then, developers are only developing for themselves? What's more likely is that they've taken a gamble that most users will simply accept their changes, which they deem as necessary to move forward. That would be fine if there were alternative options, but as more and more things are "vertically integrated" the choices made by one project are knocking over into others. Before I could simply ignore systemd and choose something else, now I'm having to choose between using both Gnome and systemd, or neither. It is a difficult choice, but just as Gnome has chosen to forsake my desire for a simplistic init system at the expense of a little boot speed and some "features" I've never needed in the past, I'm having to walk away to some other less well developed desktop environment. The cost of ignoring their users opinions is losing the users themselves. I don't know how many users they'll have to lose before someone decides to take the ship in a new direction, but I would like to see how many they stand to lose, by asking those who care to speak up and find a way of being heard before the damage is too much to repair... Mike 5:\ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlIGyGUACgkQu7rWomwgFXpeugCeMGQmjB7tcnpZd12DF8Baml0s xcsAn12+EXQwTSwTeK0lautDxJmwgC7r =tgWV -END PGP SIGNATURE-
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/08/13 00:45, Canek Peláez Valdés wrote: > They thought deeply about the changes that are being made to the > desktop, and they discussed it and reached a consensus about what > the direction of the project is; you can usually read about in the > mailing lists, Planet GNOME, or even watch the videos from the > GUADEC presentations. You can of course disagree with that > direction: but acting like they, poor things, don't know what they > are doing and need that someone go an tell them so they can know > "before the damage is much to repair", is quite condescending. I'm not trying to be condescending and I'm not suggesting they don't know what they're doing. If I were to suggest it, doing so on a Gentoo thread about stabilization would be futile. The only reason I'm responding on here is to find out from others in my community if there's a place that people are collecting their opinions such that it might be heard/discussed by the people at Gnome. > People have been predicting the dead of GNOME since before the 1.0 > version came out, but right now it has more contributors than ever > in the past, and at least half a dozen companies actually pay money > to people to work in it, so perhaps they actually know what they > are doing. But even if they don't, there are a couple forks you can > try or several alternatives you can switch to if "the damage is too > much to repair". Just because companies pour money into something does not mean they know what they're doing, or that they've done their market research into what their users want. I've tried several of the forks, and sadly Gnome, because of the backing it's had, hangs together as a Desktop Environment the best which is precisely why it's so disappointing they've chosen this strong a demand of their users. I have even tried systemd, which realized rather than allayed my fears, but this isn't the place for my personal experiences with that. I'm interested in solutions, specifically to get the most out of Gnome without being forced to make changes lower down my system's stack. If necessary, I'd at least like to have a logind that works distinct from systemd, according to a well defined specification that can be created separate to any one implementation (like the PMS provided for package managers), and ask Gnome to work to that specification. Until systemd-205, that was possible. The fact that systemd has the power to remove that ability in a single version bump, and did so without thought for the impact on Gnome, should be worrying to Gnome for the future, not just to the users that were affected now. The hope for a clear specification that can't be changed or dictated by a single implementation feels like a fair compromise, but unless I know where to suggest that, or where it has already been suggested, it won't help in the slightest. > And at the end of the day, all that code is 100% Free Software, > with public repositories with all the history of the components of > the project for all the world to see and use. I've already addressed how this doesn't help those who contribute to open source software, but don't have the skills to manage such a large and important project. > The GNOME developers already made their decision. The GNOME > maintainers in Gentoo followed through (like they have been doing > in almost every other distro). Now it's up to each user to decide > if she keeps using GNOME (and therefore switches, if necessary, to > systemd since 3.8), or if she stops using it. > > Arguing about it is quite useless. Having read my emails, you'll have seen that I haven't been arguing, I've been expressing a desire to collect together those who disagree with the decision and communicate it such that the decision might get discussed publicly. I have yet to be pointed to the processes and procedures whereby the decision to make systemd a hard dependency was carried out. In Gnome 2 there were specific meetings, well documented, to discuss and decide the "blessed dependencies", but those and several other key decision-making meetings now appear to happen outside of the public infrastructure. This is to the point where there were public emails saying systemd would not become a hard dependency for gnome-3.8 and yet here we are. The Gentoo Gnome herd tried their hardest to avoid the move to systemd, and I have mentioned my appreciation for their efforts in my previous emails. I am currently exploring my options, as you reiterated my point back to me, but one of those is to not give up hope on the Gnome project or their developers and to try to communicate with them. However, having people assume I'm arguing because I'm keen to get to the bottom of their decision making doesn't help... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlIG5ZQACgkQu7rWomwgFXrWVACeJakbnBmoJfYP91wOrC/EmG6W EMAAn1yZItvdNyz6AuPhcnbk9MBxcYVb =iOpy -END PGP SIGNATU
[gentoo-dev] Adding large files to the mirrors?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I'm updating the app-crypt/ophcrack-tables package to include the new tables available from their site. These are basically just additional data packages that can be useful with the app-crypt/ophcrack package, but they're very large. Including all of them will come just short of 30Gb. I don't know whether it's ok to add that to our mirrors, or add RESTRICT="mirror"? Also, these take up a lot of space in distfiles. Does anyone know of a clever way to allow them to be installed without also stashing a copy in distfiles (symlinking to the distfiles directory is a no go, because each "set" needs its own files to have the same name as the other sets)? I guess it's a bit of an infra question, but thought I'd ask here in case anyone else has found themselves in a similar situation. For more specifics about what the package is like/for see the test ebuild at [1]... Mike 5:) [1] http://git.overlays.gentoo.org/gitweb/?p=dev/ikelos.git;a=blob;f=app-crypt/ophcrack-tables/ophcrack-tables-1.1.ebuild -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlJdzaQACgkQu7rWomwgFXqq1wCePSA0S03pVVxeesqAbd2faO4h 2wgAn0P0y5dvhsArRnFdFajrApM5C4YV =fim1 -END PGP SIGNATURE-
Re: [gentoo-dev] Adding large files to the mirrors?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiya, First off, thanks everybody for the suggestions. It seems like people aren't keen to mirror the large tables on our mirrors, but no one's mentioned a reason for not doing so. Is there an infra reason behind that or did everyone just take my caution and run with it? On 16/10/13 02:40, Chí-Thanh Christopher Nguyễn wrote: > I suggest that you add a "large" USE flag, and if it is enabled, > download and install the whole thing. If disabled, just print the > URLs in a log message, so the user can download themselves if they > wish. So downloading them manually is a pain (the larger tables aren't in a single zip, they're split amongst 12 files for each table), and the ebuild to do the downloading is already built. I'll include a postinst note indicating that the tables are getting stored twice, and I should even be able to give them an indication of how much space they're wasting. I'll also provide a URL they can visit if they want to download manually instead. The question then becomes, do I split the ebuild into two (giving us three ebuilds for what is otherwise a tiny package) just so some SRCs are mirror-restricted and others aren't? All of that hinges on whether our servers can handle the extra size... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlJeWR4ACgkQu7rWomwgFXq8bQCfRde/Tg7sAirqT05d5spckC+s fUIAoIH1SlXvLmM3CqM0x1vQN0oPdiKi =qqsa -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Adding large files to the mirrors?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/10/13 12:01, Duncan wrote: > If it's a core requirement, no problem. But the further from core > requirement it gets the more sensitive infra seems to be about > non- trivial space requirements, and any way you look at it, 30 > gigs of rainbow tables are both non-core and non-trivial, > especially with the split package and no-mirror on the big package > solution, so... No, that's fine. I wanted to check, because I don't take the resources for granted, but I do see us as providing a mirroring service for open source projects (to a degree), and no one so far had put forward an opinion about how infra would feel about it. Anyway, Francesco made an excellent point, and I think I'll be going with the additional bash script for grabbing the large tables... Thanks for you help everyone! 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlJfGKkACgkQu7rWomwgFXo7dwCeIgp2WTS5vaBpG+zNTzdw0Q6g 4ocAoLUlnjIcZzcWzJ8Va1P5mdx65moP =Y1m5 -END PGP SIGNATURE-
Re: [gentoo-dev] Adding large files to the mirrors?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiya, On 16/10/13 12:54, Francesco R. wrote: > Il 16/10/2013 11:15, Mike Auty ha scritto: Add a bash script that > can download all the files and mention it in postinst. the script > will download all the files in current directory and put them in > the correct place. That's an absolutely awesome suggestion, I'll do that! Thanks! 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlJfGK8ACgkQu7rWomwgFXrUIACfTTUcmqbApW4CqMlNd3YLC5yp pLwAn0hUHOEoG+noOMtgHqhBtKFb6tbT =E9tY -END PGP SIGNATURE-
[gentoo-dev] Proposed eclasses: vmware and vmware-mod
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everybody, The Gentoo vmware team have been developing new ebuilds for vmware-workstation, vmware-player and vmware-server (and vmware-server-console), to help ease the maintenance of the shared modules and shared patches between these products. Since they all have a similar shared installer, and many use the same modules, it was a felt eclasses would be the best system for reducing the shared code between them. The first eclass is for installing the video and network modules that most vmware products use, but should also be able to deploy the modules used in a guest vmware, for the various tools packages. The second eclass if for installing the products themselves, which all tend to follow a similar install process, putting the files in similar locations, and maintaining a pseudo-installation-database used by the vmware configuration and init scripts. So, please take a look through the following proposed eclasses: http://overlays.gentoo.org/svn/proj/vmware/trunk/eclass/vmware-mod.eclass http://overlays.gentoo.org/svn/proj/vmware/trunk/eclass/vmware.eclass and feel free to post any comments, questions or suggestions relating to them so that we can get them fixed up and put in the tree. Once that happens we'll being migrating over the packages from the overlay to the main tree, and we'll be halfway towards having easily maintained and mess free vmware installations for all! 5:) Thanks very much! Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEyTrsu7rWomwgFXoRAtGvAJ9yQMtjTgWYabA8cR0+ydrKI8UwugCbBpiP ua+Udbyc0jIiaOQkBSKJUE0= =UFup -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Alon Bar-Lev (alonbl)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiya Alon! Congratulations, your bug contributions so far have been supremely helpful, I'm really glad to see you made the leap to developer. Welcome aboard! 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFJugfu7rWomwgFXoRAsxzAKCtHYOyWxag/UZlEw1aiWCav2ybbQCfQsRC ZVHIk5Erqu2fOif/AvoSaJc= =iQRX -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] 2.6.18 going stable in 1 week
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm not certain, That turning vanilla-sources into linux-sources is wise, since it would then follow that gentoo-sources become gentoo-linux-sources, and so on for all the other linux variants. Since everybody knows and understands what vanilla sources mean (the installation documentation I think explains it) it's probably not worthwhile. Does it provide any more advantages than being a more accurate title? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFOKBeu7rWomwgFXoRAhpoAJoCWRbLIr2Gb454WRySa379oAITGQCghbVa RsWPxoKQvh5TiQVUF7oZBXg= =jSGT -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
Or perhaps, Something a little more explicit might work? In instances such as the ifconfig lines, it's to create eth0 aliases (such as eth0:0), so perhaps that could look like: ifconfig_eth0:0 = "10.1.1.1 netmask 255.255.255.0" ifconfig_eth0:1 = "10.1.1.2 netmask 255.255.255.0" For uses that really do require a list (such as modules), something like: modules = "wpa_supplicant", "ifconfig" or redefinition: modules = "wpa_supplicant" modules = "ifconfig" might work? If the comma separated syntax is acceptable, it may be that brackets around it are acceptable too, in which case the bash syntax is fine. If the normal shells will still require *some* form of processing to deal with the list, could they not be given processing to deal with lists that bash already has builtin? Mike 5:) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [soc] Python bindings for Paludis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: > However, now that PMS is finally about to provide what should be a > definitive description of current generation package behavior, with the > announced intention to update this with new versions into the future as > required, the dependence on portage as the reference will soon be going > away. The announced intention for this, among other things, is to allow > alternate package managers, such that it can still be clear when it's the > package broken and when it's the package manager. From what I've read of the PMS, it currently only describes the input format it would accept (namely the format for ebuild files and their contents). This question can be delayed until the PMS defines the operation of the package manager, including but not limited to the recording of installed package data. If the package managers do not agree on which packages are installed or how to uninstall them, then they are not yet interchangeable. I apologize if this point has already been raised elsewhere in the thread. I try not to get involved in threads like this, but accidentally read a reply and thought this might be a valuable response. Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) iD8DBQFGD6/0u7rWomwgFXoRAiT9AKCV/+YGLba3owSWEt/cbOPbyC3YrgCfbboE +oqnTwPBGzD7ORY15VwOxoo= =I3ta -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [soc] Python bindings for Paludis
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: > The point being, however, that all this quarreling about "official" > package managers doesn't /really/ have to happen. [...] > I just don't see why so many are spending > so much time arguing over it, when regardless, people are going to make > their choices, and "official" status won't matter so much when people do > so, because the package spec and what works is going to be the defining > factor, not some "official" blessing, except indirectly as that affects > further package spec updates. I agree that the title "official" is nothing more than a title or label and will most likely be applied to the most common/popular manager. I think the reason for the discussion is that arguably Gentoo has been goal-less or at the very least major-project-less, and developers with vision are nervously looking for the direction to push the project. Personally, I'm very happy with Gentoo as is, it's flexible, I can add the packages I might find when browsing the web and it does everything I need. I don't need a major direction, or a big change, or an upheaval, or pretty much anything else, and I believe many of the less vocal developers feel similarly. However, for those that are looking for a change (and sunrise and seeds both seem recent evidence that a body of developers are looking for a change), then I think the alternative package manager is a nice big area with big uncertainty, given that it's well developed source-based package management is arguably the unique selling point of Gentoo. I think if someone were writing a "new" portage that simply took over from the old one one day, there would be nowhere near as much discussion. Therefore, the issue at the heart of these threads is the possibility of splintering of the project. There are quite clearly two sides. Those that would like to see multiple package managers: their reasoning is that they'd like to offer an alternative, with features and designs that would be difficult to integrate into the existing code, and some decisions that would break with the current design (albeit slightly). The other side doesn't necessarily fear another, better package manager, but fears that allowing multiple package managers will start to cause incompatibilities and will divide both the user group and the developer group. Overlays are a feature capable of this division, and already it's given rise to the "seeds" idea, which again met with the same dissent: that of divided time and resources spent on a number of smaller Gentoos, each with less popularity, less time devoted to each, and the difficulty of re-integration with the main branch. Nobody actively wants to break the main tree, but no one has yet figured out a way of ensuring that users do not encounter disruption if they decide to use a different package manager. The PMS is a step to overcome this by defining a standard, or interface, to ensure compatibility. So how can we smooth the way between the two sides? The best I can come up with is a more complete specification. One that includes both the package format, and the local state required to store data. The Pros for this, are that package managers could become interchangeable, to the point that it would never matter which package manager were in use at the time. The cons for this idea, are that it would slow down the development, changes and feature additions to the various managers, as the changes must first pass through the specification and then finally be implemented. We've already seen (with the introduction of Manifest2) that changes to the tree and distribution mechanism are slow at best (I believe manifest signing is over two years old and still not in place for every package?). Requiring adherence to a specification, and maintaining that specification will be even more difficult and slow, but it would allow both sides to move on, and work together towards the new direction. So now the question is, are we willing to accept the cons for the pros, or do we need to find a different solution. If not, then other package managers should invest their time in ratifying a specification quickly, so that they can get down to coding to the specification. Also, those against a new manager, should get down to agreeing the specification so that managers with the possibility of fracturing are bound within a framework of acceptability. As I see it, that leaves both sides working towards the same direction, and should give impetus to both groups to come to a common point as fast as possible. If not, then probably we should return to the drawing board, but I concur that bickering and worrying about the future without pinpointing the problem and trying to tackle it, is far more futile than working towards a viable solution... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) iD8DBQFGEDWOu7rWomwgFXoRA
Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It was my understanding, That minor QA violations like this, which affected the sanity of the tree, were simply added as checks to repoman - which all committing devs should use. This would (over time) stop new ebuilds of the broken form appearing, and would flag existing ones as a QA violation. It would also prevent the mistake from being made in future, and seems the best and easiest place to stem the flow from. Whilst not a conspiracy theorist, and whilst also agreeing with the decision to restrict multiple suffixes of certain types, I am a little concerned over the haste, announcement to -dev and general backlash that's been seen here. I'm sure other violations never featured such dramatic measures. How were they dealt with previously? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) iD8DBQFGLnsBu7rWomwgFXoRAt0qAJ0Y1c5pjV7QnCL4J3w02G7s81xVDQCfRcZh XtbTQNgAo9HV+hxCi3hG0rY= =BqdS -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Linux 2.6.21 plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiya, Reading over the discussion on lkml, it appears that it only affects x86_64 systems... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) iD8DBQFGQQlpu7rWomwgFXoRAhzPAJ94Dcg/S0a6dtHodXRyPRgRT4CS0gCdHSW2 kszd0QRaPlWLg8zhoTZlc/I= =2/I+ -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: phasing out app-accessibility/festival
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It can also, Be used by kismet, but it's not clear whether there are strong bindings there, or if espeak could easily be substituted using kismet.conf. Dunno if that's useful or not, but there you go... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGZbwEu7rWomwgFXoRAudDAKCUpJ9x0txA82bKkgG67TesMxl84ACfVmh0 Nx8uCQX1bhQMGj/sF/aujMw= =+CjA -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] What's it about, anyway?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tobias, As a mostly under-spoken developer, I'd like to say that there are many other developers in Gentoo than just those seen regularly on -dev. We also add ebuilds to the tree, but tend to be content minding our own little corner of Gentoo. The number of Gentoo developers, I believe, is in the range of 400, but I've never counted them all. We are all, at our own speeds and in our own ways contributing towards the public domain information that goes into making up Gentoo. Gentoo is not a group of people, it is not the servers or the hardware, it is the sheer amount of data that people have spent their time crafting, to give away for free, so that Gentoo users everywhere can run a good operating system. I cannot speak for the other seldom-seen developers, but I personally tend to accept the advice offered by those accused of inflaming situations. They say that if you can't take jokes, or seem to easily take offense at their words, you should simply ignore them. I have been ignoring most of the -dev goings on for quite some time, and I shall continue to do so for quite some time. Throughout this though, I will still go on maintaining the few ebuilds in the tree that I am care-taker for, until some other kindly soul steps up to take my place. Whilst there are those that want a vision for Gentoo, want to push it this way, or improve it that way, they do not in themselves comprise the entirety of Gentoo, and they too look after ebuilds entrusted to them. Whilst they may be frustrated, wanting a larger goal, some grand direction, there are many, many developers whose only goal is simply to maintain an operating system they like. I hope this offers you a slightly different perspective of this distribution, and perhaps even causes you to reflect on your decision. If you still wish to remove your support, I and I'm sure the other watching developers will understand. If, however, you can see past the frustrations from all those searching for a way to pour their nervous energy into Gentoo, there will be always be some developers in Gentoo who will appreciate your contributions and be thankful that you made them. Thank you for your thoughtful post, Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGZfOqu7rWomwgFXoRAkeLAJ4xv12hcGrmSNB62mSahGc71YqhrQCfez3S hB7Bu7D4TG63sdP5q2Yvml8= =/Qrr -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] automated extended information gathering
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kent Fredric wrote:
>
> Ok, I've re-thought some of my ideas and tried to come up with a more
> concise explanation
> with some practical example syntax. The basic concept of 'check' was
> 'this will work even if the package aint installed yet' and info was
> 'for working but bust packages only', but that can be superceded with
> a CHECKLIST and a conditional driven INFO function.
>
>
>
> CHECKLIST="
>a? ( some-cat/a-lib )
>b? ( some-cat/b-lib )
> "
>
> That would make building a checklist for lazy people as simple as
>
> CHECKLIST="${RDEPEND}"
>
This seems to be quite a heavy solution just to get a little more
information. Info seems much more simple and flexible. If you're
having to encode information in the ebuild about "what dependencies to
check when you break" then how will you diagnose missing dependencies?
From Mike's idea, I envisaged something more along the lines of:
Bug:
"Compilation failed as followed:
Package X failed to install
...stuff...
X.c: ../Y.h not found
X.c: ../Z.h not found
...stuff..."
Response:
"Could you please run emerge --info --verbose Y Z and paste the output here"
Counter-Response:
" Lots of useful standard info
Y was compiled with USE flags blah
Y was compiled from overlay BLAH
Y's manifest was not signed
Y's internal env included myconf='--disable-something-critical'
Z wasn't emerged"
Speedy response:
"Ah, your problem is that for some reason, something-critical was
disabled in package Y, and Z wasn't included in the dependencies.
Please try this to solve it..."
It's difficult to think of situations where you'd ask for information
from an uninstalled ebuild that you couldn't ask for from installed
dependencies, but I'd rather do that manually than try encoding it into
the ebuilds and then still have to ask the user to do it manually in
some circumstances.
Most of this could be in a default pkg_info, but it allows for
overriding by an eclass, and on a per package basis, without requiring
each package writing custom error-locating code. This is, after all,
just giving more information, it's not guaranteed to find the error.
I hope that makes some sense?
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (GNU/Linux)
iD8DBQFGkMBIu7rWomwgFXoRAghUAJ0a/EP6wRQlT2j+GcND5LZoNoqWMwCbBhbR
WwvnMHqEgmlz/auL00YvhIQ=
=kmNa
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC : New ebuild function pkg_create for creating corespondent sorce tarball
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vlastimil Babka wrote: > I think he wants to do exactly that, but having the code needed for this > right in the ebuild, so it can benefit from varibles like PV and > versionator eclass for converting PV to e.g. CVS tags... I think it's > quite elegant for this, and that you don't need another script > maintained somewhere else. If there was also switch in the respective > new 'ebuild foo.ebuild src_create' command to automatically scp files > specified by mirror://gentoo in SRC_URI to the right place... mmm :) It also means that if a developer has had to move files around or in some way create the specific layout of the tarball for the ebuild, they won't be lost if the dev goes away, or retires, etc. So attaching the specific package creation code to the specific package unpacking code seems fairly sensible. Although, I can see why there may be objections, given the very specific circumstances in which it's useful... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) iD8DBQFGnKUqu7rWomwgFXoRAsGzAJ9Qx8Qg4zInhXSJsoOy3C8L7ZVwjgCfS+dh fUx8fdYlqBTPX6TSgrSLQnQ= =kWPM -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Cryptsetup changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dirk, Could you please describe the problem you faced? From the detail you gave, it sounds as though you might not have moved /etc/conf.d/cryptfs to /etc/conf.d/dmcrypt. There's currently several ewarn lines saying that this must be done before the package will continue to work. The idea is that the package should work with both baselayout-1.12 and baselayout-2, so it therefore should not need hardmasking. Could you please provide a few more details and/or file a bug report so that we can figure out what exactly went wrong? If it was something other than the move from cryptfs to dmcrypt then we should investigate, and we'll need as much information as you can provide us to help get it solved. Thanks very much, Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) iD8DBQFGwtJQu7rWomwgFXoRAmvWAKCWqguvu98OVrV/CSUSU3Uz26jd5ACfZfNe UKrhItE7ETb7XVW3UWlwNIk= =7gz/ -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John R. Graham wrote: > But, hasn't anyone realized that bash is _broken_ if this file doesn't > exist? Quoting from the upstream-provided man page, "When an > interactive shell that is not a login shell is started, bash reads and > executes commands from ~/.bashrc, if that file exists." Is that really > the intention here? To break upstream-defined behavior? John, From the section you quoted there, there's absolutely no indication that a .bashrc file *must* exist, in fact, they even explicitly add the "if that file exists" to show acceptance of the fact that it might not... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFG8l6bu7rWomwgFXoRAvPwAJ9VFFL6rfLrIgtJw2h7F/WfK9ohwgCdEarz AtyrRbnXan5cAlCsOL1LL7I= =k/u0 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Why isn't /root/.bash_profile in the stage tarballs?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John R. Graham wrote:
> Mike, I agree. But, the file that _must_ exist isn't "~/.bashrc" but
> "~/.bash_profile". That's where the that particular bit of
> man-page-defined behavior is implemented. If "~/.bash_profile" doesn't
> exist, then "~/.bashrc" won't be sourced whether it exists or not.
Well, bash can't install a .bash_profile file into every user's home
directory for obvious reasons. That means they shouldn't rely on the
existence of one to source .bashrc, otherwise they could never guarantee
that functionality...
It appears as though you're looking for a location that is guaranteed to
be installed by bash and always executed when there's a non-login shell
start, from where you can source ${HOME}/.bashrc. I'm not familiar
enough with bash or Gentoo's setup of bash to comment on this I'm afraid
(possibly /etc/bash/bashrc?), but relying on .bash_profile so that you
can or can't source ${HOME}/.bashrc seems a little odd.
Moreover, however ${HOME}/.bashrc got into ${HOME}, presumably
.bash_profile could be put there at the same time if it doesn't already
exist?
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFG8mcFu7rWomwgFXoRAnIIAKCUC1ShfOYvKKt5SN4oGV1uYz8HkACfVkVU
72TtoVvFFI/RXR4WGy5ya4o=
=dxNr
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] retiring + looking maintainers for sendmail, tenshi, scapy, ftester
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry to see you leave, I can maintain scapy if no one else wants to? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHqglzu7rWomwgFXoRAismAJ4+4D50v0k6VSRfEfRV4mMiBP9QHACeLHJB 1IYpKEqzWFsdiFYXG7IJyhc= =16SE -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] iptables and libiptc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jo, It appears that bug 177978 answers your question. Apparently libiptc wasn't meant to be a public interface and is intended to be removed from the iptables pacakge[2]. Hope this helps answer your question. Please do have a good hunt through bugzilla when you've got a question, it's got a huge wealth of information stored in there in both open and closed bugs... 5:) Mike 5:) [1] http://bugs.gentoo.org/show_bug.cgi?id=177978 [2] http://www.netfilter.org/documentation/FAQ/netfilter-faq-4.html#ss4.5 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHvXasu7rWomwgFXoRAm84AKC06Ww9JJ3eQusx5du0SMYsJ3co6wCgryCV ydbBEAi1Y3IAIf8DEGgkdOw= =vB9r -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] About udev-145: new features / extras and kernel requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 William Hubbs wrote: > I agree here. The eclass should check /proc/config.gz. > Also, another reason to use the eclass is it respects KBUILD_OUTPUT if > it is set. - From the indenting I can't tell if you wrote this or not, however, we need to differentiate between running and build time environments. Ebuilding is a build-time process. That means the running kernel isn't important, since we're not running udev, we're just building it. When the machine is next rebooted, we could be using a completely different kernel (or even one that hasn't been installed yet). We should only care about the build-time kernel when we're building, which the user has to specify (which they do implicitly by using /usr/src/linux, or explicitly by using KBUILD_OUTPUT or another environment variable). If you go by the running kernel, then you're requiring people to reboot their computers before they can build software for a kernel they're about to run. That simply ensures downtime on a potentially critical service, and moreover it's an unnecessary constraint. The existing udev can continue running until the machine is rebooted without a problem. When the machine restarts *any* kernel could be chosen, and build time checks won't help prevent a bad kernel from being booted. That's why the linux-info.eclass does the checks it currently does, and *doesn't* check /proc/config.gz and *doesn't* check /$(uname -r)/ directories... So in summary: * Check the running kernel if you're about to run. * Check the kernel the user's chosen to build against if you're about to build, using linux-info. If the ebuild restarts the service (causing a reread off disk, rather than just a reread of the rules) then fine, use the check to disable the restart, and/or warn the user, but don't stop the user from building the software. You can also put a check in the init.d, but it just creates the possibility that the check is wrong when udev could potentially still run. I'd simply try running udev and check if it exits or errors as expected. Only if it doesn't exit or error when it should would I add checks to the initscript, and even then I'd suggest fixing the code to error correctly, over adding our own checks in... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqapk4ACgkQu7rWomwgFXqDbACgtYdXtmlgo6JA49o9on111XPE Y/QAnROtzEhAUg0ML9J+nd6rTvKfZeFz =pbOj -END PGP SIGNATURE-
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
> It does NOT check /proc/config.gz presently. The original logic against
> not checking /proc was that we were targeting the kernel being built,
> but that's moot given the use of `uname -r` in OUTPUT_DIR.
I might be reading the eclass wrong, but it looks as though OUTPUT_DIR
is only set to use uname -r if the KV_* variables match the output of
uname -r:
[ "${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}" == "$(uname -r)" ] && \
OUTPUT_DIR="${OUTPUT_DIR:-/lib/modules/${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}/build}"
Otherwise it's taken from the KBUILD_DIR and then it even checks inside
the KV_DIR's Makefile to find one. So not checking /proc/config.gz
isn't a moot point anymore, which is not to say it's not a good idea,
but the reason against doing it still stands. To deal with running
kernel's, there's a get_running_version function, that will use uname to
fill out the KV_* variables appropriately.
> Proposed solution:
> --
> We need to be able to reduce user error, so we cannot simply make it
> trust the user by default. So I propose that we add an environment
> variable (I'm not set on the name yet), eg:
> EXTERNALLY_BUILT_KERNEL=1
>
> This option will cause linux-info.eclass to consider ALL kernel option
> checks non-fatal. That way we still get the warnings and logs, but it
> does not stop the builds.
I'm not sure what this is solving? It doesn't seem to reduce user
error, it just allows users a way to override portage errors? It seems
unrelated to config.gz and the discussion going on in the previous
thread. I do like the idea of being able to override portage when it's
stopping us from building (incorrectly), but surely with the capability
to have non-fatal checks, we can try to minimize the times when
portage/the ebuild is wrong using that, instead of a whole new override?
> When is the above NOT enough?
> -
> The only time that ANY kernel sources are required is when you are
> building an out-of-tree module. For this purpose, they must be
> configured.
There's a lot of ebuilds that use linux-info, and they can't all be
out-of-tree modules. Are they misusing linux-info, or are you saying
there's a specific instance in which linux-info requires configured
kernel sources?
> The check for having configured kernel sources must only be executed
> when the modules are about to be compiled. Putting it in pkg_preinst
> would block use of binpkgs on (related) machines.
>
> - If a package builds modules AND userspace, we should offer a way to
> build the userspace only, as the user can build their modules
> externally (or patch them into the kernel) [1]
> - For packages that ONLY build modules, and no userspace at all, having
> EXTERNALLY_BUILT_KERNEL=1 means that they should error out? [2]
> (this case might be thrown into the above one).
That all seems fine, but again these just seem like standard guidelines.
Is there not already some "how to write kernel module ebuilds" page
somewhere that documents how you're supposed to use linux-info?
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
iEYEARECAAYFAkqa30QACgkQu7rWomwgFXo99gCfd8NbK9QkxtJ9BKalq/n1iBxn
l0QAoLiBsvKXZRzR4Dp8HEtoxrsONCtc
=ZK9i
-END PGP SIGNATURE-
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: > FYI: > get_running_version is used in one single ebuild, in the entire tree: > sys-fs/evms/evms-2.5.5-r10.ebuild > And there it's only for a warning. Ok, I was just suggesting that if there was an intention to implement config.gz checks, they should only apply when people ask about the running version rather than the build version. Since that doesn't seem popular or even necessary, perhaps neither is the need to check config.gz? > The great majority of CONFIG_CHECK usage in the tree is fatal already. > It only actually needs to be fatal only when it's being used to build a > module. Ok, I see what you're suggesting now. When people want to build packages, but portage knows their kernel isn't setup to run them properly, then it should still build them, but warn them strongly about it (as opposed to currently, where it'll just die). > This leaves us between hand-holding the basic user's kernel configuration > (exiting if the kernel config option is not enabled), and changing all > non-module instances in the tree to be non-fatal. Ok, so then the question is do we sacrifice correctness for fewer (invalid) bugs? Seems like a judgement call. For what it's worth, I'm not sure adding extra plumbing to allow smart users to bypass the checks is the right middle ground. I'd either leave it as is, or change the ebuilds to accurately reflect whether the userspace will build or not. >> That all seems fine, but again these just seem like standard guidelines. >> Is there not already some "how to write kernel module ebuilds" page >> somewhere that documents how you're supposed to use linux-info? > If you're building modules, most of the time you're using linux-mod, not just > linux-info. There's no document or recommended behavior in the tree for the > above actually, and I'd like to introduce one. Sounds like a good idea, it might also be worth adding to the quizes, if existing devs are asking how it should be done? I guess that's a call on how common it is to have kernel config requirements on userspace... Still, I think I'm on the right page, and even in agreement (which makes me happy). 5:) Thanks! Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqa9gkACgkQu7rWomwgFXq1PwCfTbp8hqsGZjDmsxKE21gKe1Y8 lYYAoI2EBCn5KwQdlm6Xd8u0q7KGl7gI =Jrsa -END PGP SIGNATURE-
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: > The existing state is: > - Force the user to install sources > > Our choices are: > - `uname -r` output. > - Create an override environment variable for all the checks. > > /proc/config.gz comes back here again, in that, we can use it as a > middle ground with `uname -r`, rather than having the environment > variable. Ok, that seems a very reasonable use. > So from our discussion, I propose the following: > Finding the kernel version: > --- > 0. (optional) give an env var to bypass entirely. > 1. Use existing logic of /usr/src/linux, KERNEL_DIR et al. > 2. Fall back to using the running version, with a warning. > > Checking a configuration option, for non-module use: > > 0. (optional) give an env var to make all checks non-fatal. > 1. Use existing logic of .config from /usr/src/linux, KERNEL_DIR et al. > 2. Fall back to /proc/config.gz if available. Where 2 also issues a warning, presumably? I've had a think and can't see any repercussions in changing the default behaviour, but I'm assuming people would only generally hit 2 with virtual machines and/or hardened servers. Can you see either of these suffering from defaulting to the running kernel? Do you know of many circumstances where 2 might get hit by normal users other than those situations? Also (and potentially off-topic), if we're using linux-info to detect kernel sources, whether installed or not, should we also check the tree for ebuilds that require a package which PROVIDES="sources"? I personally use a single git checkout, since I think (possibly mistakenly, I honestly haven't checked) that it will leave different checkouts of the kernel all over my /usr/src directory, whenever a new version's emerged. I've had to create a fake-sources package to trick ebuilds that need *some* sources installed, and I'm wondering if that should be necessary? > Two different cases here: > 1. Portage knows their kernel is not setup correctly. > 2. Portage cannot find out enough info. > > It's #2 that bites on virtual machines and hardened servers, and is what > I'd like to fix. Ok, I'm all for it, and the solution you've suggested sounds fine. > It's a one-liner to give an override making all checks non-fatal, with > the downside that it can't differentiate why the checks are being made. > So yes, in the case we should simply fix all of the ebuilds (after the > kernel source check is fixed as well). I'd definitely try and do things the right way, and a global override (whilst easy) doesn't sound like it. Fixing all the ebuilds (and the kernel source check) sounds like the way to go. > So I propose this as resolutions from the above: > 1. USE=modules added to the base profile. > 2. Every package that builds kernel modules must offer USE=modules, >which can be used to disable building the kernel modules, leaving a >pure userspace build of that package. > > Most of the changes to the above can be done in the linux-mod eclass, so > I don't think we'll have to touch that many packages directly. > Yep, although if the changes are in linux-mod, then those packages that *only* provide kernel modules will need a way to not present that use flag (no point installing a package is USE="-modules" and nothing gets installed). Also, I'd assume +modules would be added as a default. The whole plan sounds extremely sensible in general! 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqbC3oACgkQu7rWomwgFXpwywCeKzcB0Znzuul3wq9U9ew5+SuX scQAnjShkQTVQQrFABb8u2t0RsP9K34z =LFlY -END PGP SIGNATURE-
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: > Yes, a warning with using /proc/config.gz. > > I missed a bit for the config option. > If there is NO source of the config data, what do we do? > Error out or more warnings? Well, if we can't determine whether a config option's set or not, if it's not critical (ie, it's ~CHECK), then we warn. If there's any hard checks, then we error out I suppose. > This is what I use for my home workstation: > /etc/portage/profile/virtuals:virtual/linux-sources sys-kernel/git-sources > /etc/portage/profile/virtuals:virtual/alsa sys-kernel/git-sources > /etc/portage/profile/package.provided:sys-kernel/git-sources-2.6.30 > > Saves having any fake package like that. Ah cunning, I'll have to try that... > Want to lend a hand fixing up the ebuilds then? I'll work on the eclass > sources > check. Sure, as long as I sure I know how we're fixing them, I'd be glad to help. 5:) I'd just be fixing the userspace ones to make sure they're ~CHECK or would I be doing something else as well? Also should I do that via bugs and a week's grace period, or would you recommend I just dive right in? > There IS still a point of having the entirely empty kernel package installed: > - Split userspace/kernel packages where the userspace package has a dependency > on the module-providing package. > - other packages that might have a dependency on the module-providing package. > - /etc/modprobe.d/ files. > > USE=-modules will ONLY block files installed to /lib/modules/. Ok, presumably USE=-modules will also stop the kernel checks, otherwise the following could occur. Let's say the foobar package builds external modules and explicitly requires that foobar not be set in the kernel. With USE=-modules, there's no internal version and there's no external version, but the kernel package is installed, and the deps are happy, even though they'll bug out when it's showtime. Presumably there's also packages that aren't split, or depended on, where not installing the modules is never a good idea. Is there still a way to disable the USE flag, or will it be a requirement of the linux-mod package? > I'm not sure we can get away with USE-defaults for this change, due to the > amount of EAPI=0 stuff that will be changing, so it'll be in > profiles/base/make.defaults instead. That's fine, just so long as it's on and not off, I don't mind what system we use to do it. 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqbEqkACgkQu7rWomwgFXq53QCdFi8YlDrKwkh9b0g6EX2DBI35 0t0AnRRRV+oxqQaKPqzcWxGJDtW2lszQ =oia+ -END PGP SIGNATURE-
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: > If you feel like reviewing ~140 packages and filing bugs for them, I > won't stop you. But I'm just going to go and fix the ones that seem > simple enough to me, and only file bugs for the complex ones. Ok, I'll do what I can tomorrow. I'm off to bed now... 5:) > Err, I'm not following what you claim is the problem here? > > cat/foo-mod: > inherit linux-mod > CONFIG_CHECK="!option" > > ... > > The user sets USE=-modules because they have built cat/foo-mod on their > own, into the kernel. foo-mod installs nothing Just checking that it will actually install nothing, rather than failing out with an error because the kernel has "option" set. I'm just re-iterating that CONFIG_CHECK should only occur if USE="modules". If USE="-modules", then the CONFIG_CHECK options should probably be ignored shouldn't they? > It needs to be ALWAYS available. The ipset bug I linked earlier in the > thread was an example of that. The userspace is useless without the > kernel code, but there is nothing to stop the user patching it into > their kernel and not having it as a module at all (as is the case on a > couple of my work boxes, which is why the bug got filed). Ok, fair enough. However, in that instance, ipset is a userspace dependency, I was talking about kernel modules that have no userspace dependencies. I suppose there could be a case where someone is trying to custom build a userspace tool that isn't in portage yet, but I still think it might cause confusion to allow USE="modules" on kernel modules (without any dependencies) that then install nothing. I'm wondering which will cause more bugs to be filed? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqbHEEACgkQu7rWomwgFXrEpQCeIMWofCtvwHKJoZsb3/qUyLcP tTUAoIb3Sr645x6NY82LXK6i/3g75NF5 =uaOB -END PGP SIGNATURE-
Re: [gentoo-dev] linux-info.eclass: lacking sources, config checks and module building
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok,
Here's the list of ebuilds that feature a CONFIG_CHECK, and which ones
I've been through to check for either NONEED (already using ~option),
MODULE (builds a module so may really want to bomb out), and FIXED
(packages which I've fixed).
About half the list is done, I'm posting it here as a progress/grab 'em
if you want to do 'em type list (as requested by robbat2).
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
iEYEARECAAYFAkqcUhoACgkQu7rWomwgFXp3GwCfddJEgoKsDgaGTLzkouavCdVp
srQAoLUMEEwmobCBwWAHasrwJjjSt9k5
=iMAd
-END PGP SIGNATURE-
FIXED app-admin/longrun/longrun-0.9-r3.ebuild:CONFIG_CHECK="X86_MSR X86_CPUID"
FIXED app-cdr/nero/nero-3.5.2.3.ebuild:CONFIG_CHECK="CHR_DEV_SG"
FIXED app-cdr/nero/nero-3.5.3.1.ebuild:CONFIG_CHECK="CHR_DEV_SG"
FIXED app-crypt/truecrypt/truecrypt-6.2.ebuild: local
CONFIG_CHECK="BLK_DEV_DM DM_CRYPT FUSE_FS CRYPTO"
FIXED app-crypt/truecrypt/truecrypt-6.2a.ebuild: local
CONFIG_CHECK="BLK_DEV_DM DM_CRYPT FUSE_FS CRYPTO"
MODULE app-emulation/vmware-modules/vmware-modules-1.0.0.15-r2.ebuild:
CONFIG_CHECK=""
MODULE app-emulation/vmware-modules/vmware-modules-1.0.0.15-r2.ebuild:
CONFIG_CHECK="UNUSED_SYMBOLS"
MODULE app-laptop/acer_acpi/acer_acpi-0.10.ebuild:CONFIG_CHECK="LEDS_CLASS
BACKLIGHT_LCD_SUPPORT"
MODULE app-laptop/acer_acpi/acer_acpi-0.11.2.ebuild:CONFIG_CHECK="LEDS_CLASS
BACKLIGHT_LCD_SUPPORT"
MODULE app-laptop/acer_acpi/acer_acpi-0.8.2.ebuild:CONFIG_CHECK="LEDS_CLASS"
MODULE app-laptop/acpi4asus/acpi4asus-0.41.ebuild:
CONFIG_CHECK="LEDS_CLASS"
MODULE app-laptop/acpi4asus/acpi4asus-0.41.ebuild:
CONFIG_CHECK="~ASUS_LAPTOP"
DONEapp-laptop/hdapsd/hdapsd-20060409-r1.ebuild:CONFIG_CHECK="SENSORS_HDAPS"
DONEapp-laptop/hdapsd/hdapsd-20060409-r3.ebuild:
CONFIG_CHECK="SENSORS_HDAPS"
DONEapp-laptop/hdapsd/hdapsd-20060409.ebuild:CONFIG_CHECK="SENSORS_HDAPS"
MODULE
app-laptop/lenovo-sl-laptop/lenovo-sl-laptop-.ebuild:CONFIG_CHECK="HWMON
BACKLIGHT_CLASS_DEVICE"
MODULE app-laptop/tp_smapi/tp_smapi-0.37.ebuild:
CONFIG_CHECK="!SENSORS_HDAPS"
MODULE app-laptop/tp_smapi/tp_smapi-0.39.ebuild:
CONFIG_CHECK="!SENSORS_HDAPS"
MODULE app-laptop/tp_smapi/tp_smapi-0.40.ebuild:
CONFIG_CHECK="~INPUT_UINPUT"
MODULE app-laptop/tp_smapi/tp_smapi-0.40.ebuild:
CONFIG_CHECK="!SENSORS_HDAPS"
NONEED app-laptop/tpb/tpb-0.6.4.ebuild:CONFIG_CHECK="~NVRAM"
NONEED app-misc/actkbd/actkbd-0.2.8.ebuild:CONFIG_CHECK="~INPUT_EVDEV"
NONEED app-misc/dnetc/dnetc-2.9013.498.ebuild: local CONFIG_CHECK="~SYSVIPC"
NONEED app-misc/dnetc/dnetc-2.9015.504.ebuild: local CONFIG_CHECK="~SYSVIPC"
MODULE
app-misc/sdricoh_cs/sdricoh_cs-0.1.3_p20080521.ebuild:CONFIG_CHECK="MMC_BLOCK"
MODULE
app-misc/sdricoh_cs/sdricoh_cs-0.1.3_p20080525.ebuild:CONFIG_CHECK="MMC_BLOCK"
FIXED
app-mobilephone/gnokii/gnokii-0.6.27-r2.ebuild:CONFIG_CHECK="UNIX98_PTYS"
(STABLE)
FIXED
app-mobilephone/gnokii/gnokii-0.6.27-r4.ebuild:CONFIG_CHECK="UNIX98_PTYS"
FIXED app-mobilephone/gnokii/gnokii-.ebuild:CONFIG_CHECK="UNIX98_PTYS"
MODULE
dev-embedded/parapin-driver/parapin-driver-1.0.0.ebuild:CONFIG_CHECK="PARPORT"
FIXED dev-java/jusb/jusb-0.4.4-r1.ebuild:CONFIG_CHECK="USB_DEVICEFS"
MODULE dev-util/sysprof/sysprof-1.0.12-r1.ebuild: CONFIG_CHECK="PROFILING"
MODULE dev-util/sysprof/sysprof-1.0.12.ebuild: CONFIG_CHECK="PROFILING"
NONEED dev-util/systemtap/systemtap-0.7.ebuild:CONFIG_CHECK="~KPROBES ~RELAY
~DEBUG_FS"
NONEED dev-util/systemtap/systemtap-0.8.ebuild:CONFIG_CHECK="~KPROBES ~RELAY
~DEBUG_FS"
NONEED dev-util/systemtap/systemtap-0.9.5.ebuild:CONFIG_CHECK="~KPROBES ~RELAY
~DEBUG_FS"
NONEED dev-util/systemtap/systemtap-0.9.7.ebuild:CONFIG_CHECK="~KPROBES ~RELAY
~DEBUG_FS"
NONEED dev-util/systemtap/systemtap-0.9.8.ebuild:CONFIG_CHECK="~KPROBES ~RELAY
~DEBUG_FS"
NONEED dev-util/systemtap/systemtap-0.9.9.ebuild:CONFIG_CHECK="~KPROBES ~RELAY
~DEBUG_FS"
NONEED gnome-base/gnome-menus/gnome-menus-2.20.3.ebuild:
CONFIG_CHECK="~INOTIFY"
MODULE media-sound/alsa-driver/alsa-driver-1.0.20-r1.ebuild: local
CONFIG_CHECK="!SND SOUND ${CHECK_PNP} ${CHECK_ISA} ${CHECK_FW} ${CHECK_PARPORT}"
MODULE media-sound/alsa-driver/alsa-driver-.ebuild:local
CONFIG_CHECK="!SND SOUND ${CHECK_PNP} ${CHECK_ISA} ${CHECK_FW}"
MODULE media-sound/line6usb/line6usb-0.7.3.ebuild:CONFIG_CHECK="USB SOUND"
MODULE media-sound/line6usb/line6usb-0.8.1.ebuild:CONFIG_CHECK="USB SOUND"
MODULE media-sound/xfi-drivers/xfi-drivers-1.00.ebuild:CONFIG_CHECK="SND SOUND"
MODULE media-tv/ivtv/ivtv-1.0.1.ebuild:CONFIG_CHECK="EXPERIMENTAL KMOD
HAS_IOMEM FW_LOADER I2C I2C_ALGOBIT
MODULE media-tv/ivtv/ivtv-1.0.1.ebuild:
CONFIG_CHECK="${CONFIG_CHECK} FB FB_TRIDENT FRAMEBUFFER_CONSOLE FONTS"
MODULE media-tv/ivtv/ivtv-1.0.2.ebuild:CONFIG_CHECK="EXPERIMEN
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Lauer wrote: > At least I'm trying to keep these > packages alive, which noone else seems to do. If you spot that a new version is available, you're more than welcome to post a version bump bug assigned to the appropriate herd and developer (forensics and me, in this instance). I don't necessarily have time to stayed glued to exactly when new versions of a package come out, but that doesn't mean I'm not willing to spend the time to keep it up to date once I'm aware a new version's come out. If nobody tells me, it'll have to wait until I spot it myself. Foremost has a single bug open against it, which is a stabilization bug, that means it still compiles, and works, or that no one's bothered to complain about it. So I'd class the package as far from dead. Please don't claim no one else wants to keep the package alive, when you don't afford them the opportunity to demonstrate that they do. If you take responsibility for bumping a package from the appropriate maintainer, you can't then turn around and claim you're allowed to cut corners because no one was maintaining it. It's quite rude to the people who are willing to look after it... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkr25AYACgkQu7rWomwgFXrIxQCgnVdigpUJZnaW28HcJ2U8qQZy b9IAoJc2Afv0UfrrYu7xe7EdP1DCP2Ze =m8Os -END PGP SIGNATURE-
Re: [gentoo-dev] sudo vs su
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiya William, Sudo can be used to restrict access, so that only certain programs can be run using it. It asks for your password rather than the user you're trying to login to (unlike su). It also helps maintain a more accurate audit trail (although I don't have details on exactly how it does that). Also su I believe only allows access to people in the wheel group. Therefore, you'll see people using them in conjunction (particularly with systems like ubuntu that don't give you a root user), so that a user can enter their own password and be restricted to a particular program in this case su, and keep better audit logs all thanks to sudo. Whilst at the same time it still gives you complete access to the system/login shell through su (a simpler and therefore presumably easier to secure program). So they can achieve the same results, but it is the differences in the programs and the way they work that makes people choose one over the other (or try and combine their best qualities). That's the best of my understanding, hope it helps? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkuKyisACgkQu7rWomwgFXp6KQCfRGn4b10R8onUVIXlaMgGJ/1o gpQAn1wiKNrFzlHZLKozCgaJujSUkKH4 =55Bj -END PGP SIGNATURE-
Re: [gentoo-dev] Re: New global USE flag: introspection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/06/10 15:33, Arun Raghavan wrote: >> Why not just gintrospection? > > I still think "introspection" is easier to grok. It's unlikely that > it's going to be used in a completely different sense by other > packages in the future, so let's stick with "introspection" please. Gintrospection gives more information (things starting with g are generally gnome related, which this is), and grepping for introspection will still turn it up. It also solves the concerns that all the people on this thread have voiced about introspection being too generic. I can't see why introspection is that much easier for people to "grok"? Gintrospection seems like a good compromise that everyone can agree on... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkwg5d0ACgkQu7rWomwgFXqr+QCggMCbz0F9Jm/WxK080ZcVLLWV +bcAnj4A72j+T9iLmbyW+0uFDCyYg23o =vbNg -END PGP SIGNATURE-
Re: [gentoo-dev] Re: New global USE flag: introspection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/06/10 18:11, Arun Raghavan wrote: > It is not a GNOME-only flag. A general introspection flag may not be, but this isn't a general introspection flag, this is specific to gobject and the suggestions try to clarify that. People who want gobject-introspection (which concerns gobject, and is therefore appropriate for a "g" prefix) will not want to have to manually differentiate between arbitrary-library-introspection and gobject-introspection by fiddling around with a package.use file to individually turn it on and off. It should be an easy, global USE flag to enable once in make.conf and forget about. > Which should not be an issue since any library that has some sort of > introspection can use this flag (and the use.desc can be changed > appropriately at that time if it does not use gobject-introspection). Why have to change it in the future (and probably split it into two flags then), when the choice hasn't been made yet? Or, to put your own question to you, why are you vehemently for "introspection" when others have shown concern with the choice? As far as I can see, the only difference is requiring a slightly longer use_enable line. In the end, it's not a big issue and whichever is chosen it'll work out. I'm just trying to figure out why the compromise solutions aren't good enough to satisfy everyone? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkwhGkAACgkQu7rWomwgFXp0dQCePjaHQn6JeBO6OrzwsIHBp8f1 +2gAoJDD4MS1spuo1DiqD96uOfX8ZBj9 =TJvC -END PGP SIGNATURE-
Re: [gentoo-dev] Over using preserve_old_lib, don't do that
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry I'm a bit late to the thread, Just to add that empathy preserves libemapthy in this manner too. On 05/07/10 17:40, Gilles Dartiguelongue wrote: > > 1. How is it different than preserved-libs feature from > portage-2.2 ? The issue that I have with you argument is that > you encourage breaking user apps at build time instead of > leaving the user some time to run revdep-rebuild or any other > tool needed when user wishes so. This is different from preserve-libs because FEATURES="-preserve-libs" doesn't stop these calls from keeping old libraries around. Also, once preserve-libs has been used, a normal revdev-rebuild won't spot these issues, and cruft-checkers can't find them because they're classed as part of the new package. I understand we have users who want this feature, and also that we advise everybody to read through every single elog message ever made. Having said that, I personally know how to run revdep-rebuild, and I do it often so that when I'm upgrading 100+ packages in one go, I don't then have to sit around reading through every elog message to make sure that a library I didn't ask for doesn't accidentally get left on my system for all time. I can live with this for in places where it causes massive breakage (openssl/libpng/libjpg), because it's genuinely useful, but I think it should be restricted to such important packages, or at least disabled by FEATURES="-preserve-libs". Ideally, these calls should either adhere to FEATURES="-preserve-libs", or there should be a tool that can identify which files portage has preserved, and allow easy rebuilding of dependent packages, and removal. At the moment, I'm having to manually grep ebuilds, ls the libraries and run revdep-rebuild over them one at a time... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkw+y6oACgkQu7rWomwgFXoehQCgsrbUBRorY6J4rBmASh16t1eP YzoAnAhAi7kWd/bI9xhUh8UHMFfCR5xY =OOj9 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Over using preserve_old_lib, don't do that
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/07/10 14:57, Maciej Mrozowski wrote: > And what about using portage 2.2 and be done with it. I don't see the point > in > reinventing the wheel yet again. I'm using portage-2.2 and have been since it first came out. I find the @set notation invaluable. I didn't like the preserve-libs feature however, so I set FEATURES="-preserve-libs". Unfortunately the eutils function only checks for the presence of preserve-libs to drop out and let portage handle it, not the absence of it. So there's no way to get that function *not* to leave these extraneous files around, even with 2.2. As I said, that's fine, and I'm happy with that for extreme situations (toolchain breaking or libpng/jpg size changes), but I'm not for most of the other packages. If portage offers a way to turn off functionality (like preserving libraries), it should actually turn it off, rather than sometimes turn it off... > Imho, revdep-rebuild and all 'misc' tools requiring users' good will like > python-updater should be obsolete and phased out in favour of package manager > controlled mechanisms. You're just moving around the good will, but it's still required. Instead of typing "revdep-rebuild preserved-libs", you have to type "emerge @preserved-libs", but neither of those solutions is automatic. Also, if you feel that way, why not request that preserve-libs be made mandatory in portage-2.2? If the changes are big enough, and not-well-tested enough that they warrant making the feature optional, then why not ensure that the simpler fallback tools to correct problems (like revdep-rebuild) can still do the job... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkw/GgcACgkQu7rWomwgFXrY5QCeJha63SB9lpl1lLhgq9CqePj8 QsQAniLZpr0RymqtQlXAJVdoCa9eEEjW =5a5g -END PGP SIGNATURE-
Re: [gentoo-dev] app-editors/vim-7.3 and python[3] USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd thought that the new eclass was designed to ensure that if you asked for USE="python" it was built for as many different python ABIs as was installed on your system (so python2 and python3 if they're both installed). I believe it's possible to ask the eclass which ABIs are installed, and ask for the either in-use or highest versions of those. If they're not mutually exclusive, and if vim won't break if they go away, then why should the user choose which ones to enable and disable? Why not just get them to say whether they want python support or not, and try to accomodate them for as many python versions as installed/possible. I realize there may be some controversy surrounding the new python eclass, however that does seem to be how most python packages work these days, so I'd say it's better to keep everything working the same way. Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkxuRQEACgkQu7rWomwgFXrpJQCgiMBnn9bWdbwtE4xcFsNmmKkV IV0An3FC4w3eImueLxZ7bwC3tLkv8+YC =uCL+ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/08/10 18:26, Olivier Crête wrote: > > Other distributions are going one step further and are going for > shell-free boot. We should follow that lead. > Why? Presumably they're doing it by writing programs that do their own parsing and executing, which means they'll need a maintainer just for that program and they'll have to go through a few iterations to get the initial bugs out, and then people will have to learn how to use the different-yet-again language that goes with it. Why not rely on a prebuilt parser that devs already have to know to look after ebuilds? I'm happy to accept that there might be some very good reasons (respawning a shell for each script is time consuming/expensive?), but without describing what those reasons are, it's not a direction we should just be following blindly... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkxyuXMACgkQu7rWomwgFXrqSwCgjANV5zpo/uYrML+q1mCXHVgI ghcAn2oRJMUl4V+L4UHhEABYUs58e9c5 =jen/ -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Repoman to autogenerate ChangeLog entries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It should be possible to still maintain this distinction, something like: "Version bump. Added feature foo. - -- Feature foo required a complete rewrite of src_install." And then the ChangeLog generation can happen separately. The problem with this method is that if we later rely only on commit logs, users may see things developers hadn't intended them to see. So the question is, will we always generate changelogs from the version control system, or will we one day expect the user to directly read the commit logs? Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkyWKWsACgkQu7rWomwgFXoBoACcCAeaYpUzquKEyp09NHk7nrrK w9AAoKf8HtoAY68UMYSEwwvyqemV54M+ =iVC7 -END PGP SIGNATURE-
Re: [gentoo-dev] mercurial.eclass: change clone destination
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/11/10 02:40, Donnie Berkholz wrote:
> I read it more closely and realized I was a little confused by the way
> you listed all the bullet points mixing together benefits and problems.
>
> So I'll try again: if you really want to do this change, you might want
> to consider adding a mercurial-2.eclass instead. Eclasses of this nature
> (svn, git, hg, etc) tend to be broadly used outside the tree as well as
> within, so breaking backwards compatibility can be a real problem. A new
> versioned eclass allows for a much more gradual transition.
>
I've only just jumped into the conversation, but the obvious question
is, why not just use ${S} as the location of the working directory
(rather than "${WORKDIR}/${workdir}")? That way, if it's set old
ebuilds still work, and if it's not set, new ebuilds get the benefit of
using ${S}? I can only see a problem with this if there's somewhere
that the value of the working directory needs to be known before any of
the phases...
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
iEYEARECAAYFAkzWloYACgkQu7rWomwgFXosEACgiFBLbFABweQR0JrZqprBxdkT
10UAoJVESt/2T3Y1AXkBXu7qYPY4NBf2
=ULZu
-END PGP SIGNATURE-
Re: [gentoo-dev] acceptable alternatives to -Werror, was: Changing policy about -Werror
Hiya, On 13/09/2018 01:23, Chí-Thanh Christopher Nguyễn wrote: > Installation will proceed, but the user will get a big fat warning that > the sys-fs/zfs package is potentially broken. This seems like a sure-fire way to make users paranoid and/or desensitized? People will learn to ignore warnings if we make them big red and flashing but then say they're only potential breakages (and they subsequently discover that most everything runs fine). If they learn to ignore big red flashing warnings it'll be more difficult when they're not potential breakages but actual ones we've accurately identified... Mike 5:) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-dev-announce] crypto@ packages up for grabs
I'd like to claim: > app-crypt/ssdeep and > app-crypt/xca I'll add my information to the metadata.xml for them... Mike 5:) signature.asc Description: OpenPGP digital signature
