[gentoo-dev] The deal with epkgmove
For those who aren't devs; epkgmove is a tool to move and rename packages around in CVS. It lives here: [1] As it stands currently, epkgmove is likely to mess up the tree for anything but simple package moves/renames with only a couple of minor deps. The code is hideous, and needs a rewrite. However, I don't think we should even be using such a tool. Package moves are best done on the server where it can keep track of all dependency and package references as they're committed. For epkgmove to perform 100% accurate moves, it needs to do a full tree scan plus reverse dep checking, which would make it too slow to be useful. There are a handful of other non-trivial checks it has too perform. SVN in combination with the mentioned server side caching would probably be the best solution, though obviously CVS -> SVN transition for gentoo-x86 is no minor task. For the time being and near future, I think moves should be done by hand. What are your thoughts on this, infra? 1: http://dev.gentoo.org/~port001/DevTools/epkgmove/ Regards, Ian Leitch -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] x86 Architecture Team
OK, so forming an arch team for x86 seems to have won out over merging with amd64 (for the time being anyway), so lets get things underway. I have created bug #104525 for interested devs to add their names to (please CC also). Interested users may also show interest, I think tester and hparker are interested in possibly recruiting a few able fellows. Regards, Ian Leitch -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] combining x86 and amd64
I think myself and tester are the only members who can be considered active at the moment. I'm happy with creating an arch team, though I don't think we'll end up with an abundance of members (x86 is far from the most popular arch among devs). Chris Gianelloni wrote: So would just making an x86 arch team. It would also be much less of a problem than merging x86 and amd64. How about this? I proclaim and x86 arch team now exists. It already has a security liason. $ cat /var/mail/alias/arch/x86 avenj solar tester port001 azarah -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Updating package.use automatically
For those of you who like having only a small amount of USE flags defined in make.conf along with -*, keeping package.use updated (as to not break --newuse, etc) can be a laborious task (assuming you even bother in the first place). Portage isn't supposed to touch users configuration files, so you can consider this one a hack. The following bashrc will do all the work for you, enjoy. http://dev.gentoo.org/~port001/configs/bashrc Regards, Ian. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
Donnie Berkholz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: | The new categories are x11-apps, x11-proto and x11-drivers. Of these, | the name for x11-proto (the protocol headers) is debatable. The upstream | module they're all in is called "proto," and their pkg-config (*.pc) | files are called fooproto. But I'm also open to names such as | x11-protocol or x11-headers, so let me know what you think makes the | most sense, both in understanding the meaning and in combination with | upstream's naming. I'm still awaiting any solid arguments against x11-proto, and they had best be expedited (read below for why). I don't dislike x11-proto, x11-headers is just a little more descriptive from the perspective of an ignorant user. More informed users know that X is the actual protocol, so x11-proto could read to them as "protocol protocols", or "protocols of a protocol". Besides, we have category metadata anyway. Regards, Ian. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] src_configure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Wegener wrote: > Hi all! > > I'm writing this mail to bring you a thought we had over on freenode in > the #gentoo-portage channel. We would like to split up src_compile. The > new src_configure should just do the econf part and src_compile should > do the emake part. This represents the general 3-step[1] installation in > a much better way. > > Regards, > Sven > > [1] ./configure && make && make install I made some patches[1] to do this years ago, I was told by the portage devs at the time (can't remember who) that they should probably be includes some time in the future. Maybe now is the time? 1: http://dev.gentoo.org/~port001/Patches/configure-ebuild.sh.patch http://dev.gentoo.org/~port001/Patches/configure-portage-py.patch (NOTE: these probably don't apply anymore, seeing as they were made in december 2003). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCzIYXefZ4eWAXRGIRAuNNAKCQHoEqZ/vsMiOORxt27veqar4gkQCfdFLT daFN7flKJXqo7eCEDfMYJGQ= =fhld -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal: sys-pam category
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Diego 'Flameeyes' Pettenò wrote: > Currently pam stuff (implementations, modules) are organized in the worst way > I ever seen. > Most of them are in sys-libs, some of them in app-admin, other in app-crypt, > pam_smb in net-misc and so on. > > I think we should reorganize them and have a sys-pam category with > implementations (Linux-PAM and OpenPAM) and the modules needed. > > Such a change would require a lot of work and we can't count on epkgmove I > think, but if someone is going to help me or at least tell me how to do such > a change without breaking everything (always if such a change is accepted, > obv.).. > > Comments? I made a bugfix release of epkgmove just the other day. It should now move packages correctly, though you'll still need to check it's actions like a hawk. See http://dev.gentoo.org/~port001/DevTools/epkgmove/Testing/ Take a look at #84015 also. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCoyFjefZ4eWAXRGIRAuUJAJ9PZZ5bOrDswXdqz5vLrvMWQmukVACeJA7b /Fw1l1GsrrjWITG8MrtIwE8= =ZfrV -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
