Re: [gentoo-dev] [RFC] News item: app-portage/gentoolkit-dev deprecation/removal
On 9/20/17 2:22 PM, Paul Varner wrote: On 9/20/17 2:49 AM, Martin Gysel wrote: Am Dienstag, 19. September 2017, 19:10:23 CEST schrieb Paul Varner: emerge --deselect app-portage/gentoolkit-dev emerge --depclean app-portage/gentoolkit-dev why deselect it first? From man emerge, --depclean: "When given one or more atoms, it will unmerge matched packages that have no reverse dependencies." Mainly as an extra precaution. However, just --depclean should work. This is the update with the typo pointed out by ulm corrected and changing the command to just be depclean. Regards, Paul I just realized that the devmanual says to copy PR on the news items, so they are copied on this message. This should be what gets committed after three days as there have been no more comments on the item. Regards, Paul Title: app-portage/gentoolkit-dev deprecation and removal Author: Paul Varner Posted: 2017-09-19 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: app-portage/gentoolkit-dev The app-portage/gentoolkit-dev package has been deprecated and the ebump, ekeyword and imlate have been moved to the app-portage/gentoolkit-0.4.0 package. With the upcoming marking of >=app-portage/gentoolkit-0.4.0 stable, users will need to take action since gentoolkit-dev and those versions of gentoolkit block each other. In order to upgrade to the new version of gentoolkit, you will need to resolve the blocks. The following command will remove gentoolkit-dev from your world set and uninstall gentoolkit-dev. This will then allow the installation of >=app-portage/gentoolkit-0.4.0. emerge --depclean app-portage/gentoolkit-dev Once >=app-portage/gentoolkit-0.4.0 is stabilized, the remaining gentoolkit-dev releases will be masked for removal and subsequent tree-cleaning.
Re: [gentoo-dev] [RFC] News item: app-portage/gentoolkit-dev deprecation/removal
On 9/20/17 2:49 AM, Martin Gysel wrote: Am Dienstag, 19. September 2017, 19:10:23 CEST schrieb Paul Varner: emerge --deselect app-portage/gentoolkit-dev emerge --depclean app-portage/gentoolkit-dev why deselect it first? From man emerge, --depclean: "When given one or more atoms, it will unmerge matched packages that have no reverse dependencies." Mainly as an extra precaution. However, just --depclean should work. This is the update with the typo pointed out by ulm corrected and changing the command to just be depclean. Regards, Paul Title: app-portage/gentoolkit-dev deprecation and removal Author: Paul Varner Posted: 2017-09-19 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: app-portage/gentoolkit-dev The app-portage/gentoolkit-dev package has been deprecated and the ebump, ekeyword and imlate have been moved to the app-portage/gentoolkit-0.4.0 package. With the upcoming marking of >=app-portage/gentoolkit-0.4.0 stable, users will need to take action since gentoolkit-dev and those versions of gentoolkit block each other. In order to upgrade to the new version of gentoolkit, you will need to resolve the blocks. The following command will remove gentoolkit-dev from your world set and uninstall gentoolkit-dev. This will then allow the installation of >=app-portage/gentoolkit-0.4.0. emerge --depclean app-portage/gentoolkit-dev Once >=app-portage/gentoolkit-0.4.0 is stabilized, the remaining gentoolkit-dev releases will be masked for removal and subsequent tree-cleaning.
Re: [gentoo-dev] [RFC] News item: app-portage/gentoolkit-dev deprecation/removal
On 9/18/17 3:09 PM, Paul Varner wrote: Please provide any feedback on the upcoming deprecation and removal of app-portage/gentoolkit-dev with the upcoming stabilization of app-portage/gentoolkit-0.4.0 (Bug 627350) Regards, Paul Updated to just tell the user to remove gentoolkit-dev from the world set and depclean the package. Regards, Paul Title: app-portage/gentoolkit-dev deprecation and removal Author: Paul Varner Posted: 2017-09-19 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: app-portage/gentoolkit-dev The app-portage/gentoolkit-dev package has been deprecated and the ebump, ekeyword and imlate have been moved to the app-portage/gentoolkit-0.4.0 package. With the upcoming marking of >=app-portage/gentoolkit-0.4.0 stable, users will need to take action since gentoolkit-dev and those versions of gentoolkit block each other. In order to upgrade to the new version of gentoolkit, you will need to resolve the blocks. The following commands will remove gentoolkit-dev from your world set and uninstall gentoolkit-dev. This will then allow the installation of >=app-portage/gentoolkit-0.4.0 emerge --deselect app-portage/gentoolkit-dev emerge --depclean app-portage/gentoolkit-dev Once >=app-portage/gentoolkit-0.4.0 is stabilized, the remaining gentoolkit-dev releases will be masked for removal and subsequent tree-cleaning.
[gentoo-dev] [RFC] News item: app-portage/gentoolkit-dev deprecation/removal
Please provide any feedback on the upcoming deprecation and removal of app-portage/gentoolkit-dev with the upcoming stabilization of app-portage/gentoolkit-0.4.0 (Bug 627350) Regards, Paul Title: app-portage/gentoolkit-dev deprecation/removal Author: Paul Varner Posted: 2017-09-19 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: app-portage/gentoolkit-dev The app-portage/gentoolkit-dev package has been deprecated and the ebump, ekeyword and imlate have been moved to the app-portage/gentoolkit-0.4.0 package. With the upcoming marking of >=app-portage/gentoolkit-0.4.0 stable, users will need to take action since gentoolkit-dev and those versions of gentoolkit block each other. In order to upgrade to the new version of gentoolkit, you will need to resolve the blocks. In many cases, removing app-portage/gentoolkit-dev from the world set will allow Portage to automatically resolve the blockers and remove gentoolkit-dev. You can remove it from world using the following command. emerge --deselect app-portage/gentoolkit-dev If that fails to work, then unmerge the gentoolkit-dev package with emerge --unmerge app-portage/gentoolkit-dev Once >=app-portage/gentoolkit-0.4.0 is stabilized, the remaining gentoolkit-dev releases will be masked for removal and subsequent tree-cleaning.
Re: [gentoo-dev] why is the security team running around p.masking packages
On 07/06/2016 10:11 AM, Rich Freeman wrote: > On Wed, Jul 6, 2016 at 10:02 AM, Kristian Fiskerstrand > wrote: >> On 07/06/2016 03:49 PM, Rich Freeman wrote: >> >>> I understand that. However, I just sometimes wonder whether that >>> approach makes sense. The result of the current system is that we >>> don't release GLSAs until well after a bug is fixed, sometimes after >>> months. >> It makes sense for long term server management where you don't want to >> update the full tree too often, but I agree GLSAs needs to be put out >> more timely >> > Another way to do it is to have a system like this: > 1. Vulnerability is logged into database. > 2. After embargo period (if any), entry is published. Tools > available to the user make them aware they have a vulnerable package > installed and the realtime status of whether a fix is available. > 3. Once a package is stable, the tools let the user auto-update the package. > 4. Once all archs are cleaned up, publish the GLSA by email as usual. > > So, this is like the current state, except tools like glsa-check use a > realtime-updated database (or at least one as up-to-date as the latest > sync) and not a database that is only updated after the last arch is > stable. We don't need to send users 14 emails as archs are > stabilized. But, the tools they likely would want to use do use the > latest info. > > Sure, in the early days it would just tell them they're vulnerable > with no suggested fix, since we don't have a fix yet. But, that is > still information the user can use to their advantage. > > Ideally the early phases of this would be tied into bugzilla so that > somebody isn't manually updating GLSA xml files every time something > changes. > (Speaking with my tools-portage lead hat on) While I don't like touching glsa-check within gentoolkit, due to the nature of what it does. I will fully support and work with the security team on updating the tool if something like this is desired. Regards Paul
Re: [gentoo-dev] Uncoordinated changes
On 02/11/2016 07:34 PM, Rich Freeman wrote: > Ultimately, the only way anybody can be assured that their favorite > Gentoo tool will work in a year is if they're maintaining it. It > sounds like nobody was really paying attention to it, which is why > nobody noticed that it was going to break. Not completely true in this case. Gentoolkit is maintained, just slowly due to lack of time. For this migration, there is a bug for it (Bug 573030) that was filed by me before the migration was complete. The problem here is that there are two devs that primarily work on the package and both of us currently are busy with other things in our work/life balance. With that said, Patrick has attached a patch to the bug and I will take a look at it and if it works, put it in and generate a release. As a side note, any Gentoo developer is authorized to work on Gentoolkit, the restrictions are don't make a new release without asking, and fix any accidental breakage. With regards to releases, it is fine to release a rev-bumped ebuild with patches as long as the patch is in the git repository and you follow the second rule of fixing accidental breakage. Regards, Paul
[gentoo-dev] The Beauty of Unix
On 2/9/16 7:44 AM, Rich Freeman wrote: I thought the whole beauty of unix was the everything-is-a-file design? No, the beauty of Unix has always been the architectural philosophy of loose-coupling of the components of the system. The "everything is a file" is a result of that philosophy. The end result of this is that you can switch out components of the system without redesigning other aspects of the system. That is the philosophy that allows Gentoo to exist as meta-distribution and to provide choice for what you want. On the other side you have Windows which tightly-couples everything in the system. This does have the advantage of making everything have the same look and feel and "just work". And I fully understand why Microsoft went that route, it made things easy for people who don't care and is what made them the huge company that they are today. Sidebar, the reason you have to reboot a Windows box so much during updates is because of the tight-coupling. With Unix, you typically only need to reboot if you update the kernel. However, tight-coupling has big issues for people who do care or don't like the design that is being given to them. I switched from Windows to Linux and OS X solely because I got very tired of fighting the design forced on to me and the fact that a bug in one piece of software would often kill the entire system. And that is the reason that I don't care for systemd. They are tightly-coupling everything together under their design approach. It is intended to be a one size fits all. While it will have the benefit of "just working", and does fit in with where Red Hat, etc, want to go with Linux. It will have the same disadvantages that Windows has. Regards, Paul
Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4
On 01/21/2016 06:52 AM, Lars Wendler wrote: > Hi Dirkjan, > > make it part of the news item please. > > Kind regards > Lars > > On Wed, 20 Jan 2016 13:16:19 +0100 Dirkjan Ochtman wrote: > >> On Wed, Jan 13, 2016 at 6:13 PM, Dirkjan Ochtman >> wrote: >>> After what feels like ages, we're just about ready to stabilize >>> apache-2.4. Since this is a major upgrade that in many cases require >>> configuration changes, we wanted to do a news item. After some >>> discussion with Lars (Poly-C), here's an initial attempt at a >>> draft. >> I'm currently attempting this upgrade on a stable system I run. It >> mostly just works, although I run into trouble when trying to load >> modules that are not part of www-server/apache (e.g. mod_wsgi). I >> resolved this by reemerging all packages listed in `equery b >> /usr/lib/apache2/modules/*`, but maybe there's a different way? Should >> this be in an elog message, or part of the news item? >> The simple command to do this is: emerge -av1 /usr/lib/apache2/modules --exclude=www-servers/apache Regards, Paul
Re: [gentoo-dev] Lastrites: app-misc/secure-delete, app-misc/ccal, www-apache/mod_vhs, app-portage/epm, www-apps/online-bookmarks, sys-apps/i2c
On 01/17/13 13:21, Pacho Ramos wrote: > # Pacho Ramos > # Multiple bugs (#449458). No maintained at all and upstream > # dead. Removal in a month. > app-portage/epm Peter Weilbacher has stepped up to maintain this package and I am acting as his proxy. app-portage/epm-1.40 has been added to the tree that fixes most of the bugs. I have removed the package mask entry and updated metadata and bugzilla appropriately. Regards, Paul Varner tools-portage lead
[gentoo-dev] revdep-rebuild bikeshedding
All: Time for some bikeshedding :) For the gentoolkit-0.3.0 series, I removed any filtering of emerge options set in EMERGE_DEFAULT_OPS for revdep-rebuild. This has caused some people to complain because some of the flags in their EMERGE_DEFAULT_OPTS are not suitable for a revdep-rebuild run. I am not going to go back to filtering any of the emerge options, however, I just added support for a make.conf variable called REVDEP_DEFAULT_OPTS which currently gets appended to the list of options after the EMERGE_DEFAULT_OPTS and before the command line options. Here is where the bikeshedding begins: 1. What variable name do we prefer? REVDEP_DEFAULT_OPTS or REVDEP_EMERGE_DEFAULT_OPTS 2. What behavior do we want? append to EMERGE_DEFAULT_OPTS or replace EMERGE_DEFAULT_OPTS Regards, Paul
Re: [gentoo-dev] tools-portage herd unmaintained packages
On 12/26/12 11:00, Paul Varner wrote: > On 12/25/12 08:09, Pacho Ramos wrote: >> El mar, 06-11-2012 a las 12:35 -0600, Paul Varner escribió: >>> All: >>> >>> The following packages in the tools-portage herd are effectively >>> unmaintained packages and need a maintainer to step up and maintain them. >>> >>> app-portage/deltup >>> app-portage/epm >>> app-portage/maintainer-helper >>> app-portage/splat >>> app-portage/ufed >>> >>> If no one steps up in the next 30 days, I will be moving them out of the >>> herd and to maintainer-needed and they will be candidates for the >>> treecleaners. >>> >>> Regards, >>> Paul Varner >>> tools-portage lead >>> >>> >> What did occur finally with them? > Nothing has occurred with them yet, but since nobody has stepped up for > any of them, they will be moved to maintainer-needed. This will probably > be within the next couple of days since work has calmed down due to the > holidays. I have moved everything except app-portage/ufed to maintainer-needed in metadata.xml. I still need to go through and reassign any bugs for these packages. I'm going to hold off on app-portage/ufed since there is interest in it being proxy maintained. Regards, Paul
Re: [gentoo-dev] tools-portage herd unmaintained packages
On 12/25/12 12:03, Sven Eden wrote: > Hi all, > > what has happened to app-portage/ufed? I could take care of it. I am > no official dev, but maybe via a proxy maintainership? Would that be > possible? Yes, I'm willing to proxy maintain app-portage/ufed. The sources are available from overlays.gentoo.org. See http://git.overlays.gentoo.org/gitweb/?p=proj/ufed.git;a=summary. Initially, you would need to send me patches or point me to your copy of the project to pull from. However, once I'm comfortable with your work, I can grant direct access to the project for pushing commits. If you do want to proxy maintain it, please send me in private email, the email address that you use in Gentoo's bugzilla, so I can update the metadata.xml file appropriately. Regards, Paul
Re: [gentoo-dev] tools-portage herd unmaintained packages
On 12/25/12 08:09, Pacho Ramos wrote: > El mar, 06-11-2012 a las 12:35 -0600, Paul Varner escribió: >> All: >> >> The following packages in the tools-portage herd are effectively >> unmaintained packages and need a maintainer to step up and maintain them. >> >> app-portage/deltup >> app-portage/epm >> app-portage/maintainer-helper >> app-portage/splat >> app-portage/ufed >> >> If no one steps up in the next 30 days, I will be moving them out of the >> herd and to maintainer-needed and they will be candidates for the >> treecleaners. >> >> Regards, >> Paul Varner >> tools-portage lead >> >> > What did occur finally with them? Nothing has occurred with them yet, but since nobody has stepped up for any of them, they will be moved to maintainer-needed. This will probably be within the next couple of days since work has calmed down due to the holidays. Regards, Paul
[gentoo-dev] tools-portage herd unmaintained packages
All: The following packages in the tools-portage herd are effectively unmaintained packages and need a maintainer to step up and maintain them. app-portage/deltup app-portage/epm app-portage/maintainer-helper app-portage/splat app-portage/ufed If no one steps up in the next 30 days, I will be moving them out of the herd and to maintainer-needed and they will be candidates for the treecleaners. Regards, Paul Varner tools-portage lead
Re: [gentoo-dev] Proposal to move use.local.desc somewhere in /var
On 04/24/12 11:21, Robin H. Johnson wrote: > On Tue, Apr 24, 2012 at 04:11:44PM +0200, Theo Chatzimichos wrote: >> log from #gentoo-portage: zmedico: (random idea) would >> it make sence to generate local.use.desc in /var/cache, or >> somewhere in /var, but out of the tree? > Why are we keeping it? I move that we remove it. It's been replaced > by USE flags in metadata.xml for several years now. > euse from gentoolkit still uses it since it is written in bash and XML parsing in bash can be problematic. We really need to get euse rewritten in python so it can use the portage and gentoolkit API's before we get rid of the file. Additionally, if we move the file, euse will need to be updated as well and get pushed out to a stable version of gentoolikit. The euse rewrite is on the roadmap for gentoolkit-0.3.1 which doesn't have a release date yet since the primary contributors have been busy with other things. Regards, Paul PS: The gentoolkit overlay (http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=summary) is open to all Gentoo developers. The only requirement for committing to the gentoolkit branch is to pick up any pieces if you break something. Note: the gentoolkit-dev branch has tighter restrictions and access to it is controlled by idl0r.
Re: [gentoo-dev] Packages up for grabs due jokey retirement
On 3/19/12 2:26 PM, Pacho Ramos wrote: El lun, 19-03-2012 a las 10:56 -0500, Paul Varner escribió: On 03/18/12 13:50, Pacho Ramos wrote: Due his retirement the following packages need a new maintainer: app-portage/maintainer-helper Thanks for taking them I've added app-portage/maintainer-helper to the tools-portage herd, however, I've left it as maintainer-needed. So if anyone wants to take it, feel free. The tools-portage herd will fix bugs for it as we find the time. I disagree with leaving maintainer-needed as default assign, if you will fix bugs when you have time it's better than what I will do with maintainer-needed packages. Okay, I've taken out the maintainer-needed as the maintainer and have just left it assigned to the herd. However, in reading through http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=4, I don't see a good mechanism to convey that the package is up for grabs, but in the meantime go ahead and assign any bugs to the herd. Regards, Paul
Re: [gentoo-dev] Packages up for grabs due jokey retirement
On 03/18/12 13:50, Pacho Ramos wrote: > Due his retirement the following packages need a new maintainer: > > app-portage/maintainer-helper > > > Thanks for taking them I've added app-portage/maintainer-helper to the tools-portage herd, however, I've left it as maintainer-needed. So if anyone wants to take it, feel free. The tools-portage herd will fix bugs for it as we find the time. Regards, Paul
Re: [gentoo-dev] preserve_old_lib and I'm even more lazy
On Wed, 2012-02-29 at 09:45 +0100, "Paweł Hajdan, Jr." wrote: > On 2/27/12 10:37 PM, Brian Dolbec wrote: > >> I think somebody pointed some "revdep-rebuild" versions where exiting > >> with successful code even when failed, was fixed version stabilized? > > > > No, it is only in - so far. It has not been released in a -0.3* > > ebuild yet. > > > > The last patch to revdep-rebuild fixing return codes is: > > > > http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=commit;h=3e51df74595c535656ef9f38bf7a577a4f64d0f5 > > > > from 11 days ago. > > If the maintainers of the package in question do not consider it > important enough to do a release (not even mentioning stabilization), I > don't think this is blocking. > > Any further objections? (I'm going to listen) > Yes, you are going to break systems if you do this change. If you really want to do this before we have a fixed gentoolkit to support it, then put yourself in the tools-portage herd and handle all of the bugs that arise out of the change. I just did a new release of gentoolkit-0.3.0.5 with the fixes in them so that you could do this change once it gets stable. Regards, Paul
Re: [gentoo-dev] Packages looking for proxy as ian no longer has commit access
On Thu, 2011-11-24 at 17:25 +0100, Ulrich Mueller wrote: > > On Thu, 24 Nov 2011, Pacho Ramos wrote: > > > Due https://bugs.gentoo.org/show_bug.cgi?id=99016 ian doesn't > > have commit access and, then, his packages need a proxy maintainer: > > app-portage/autounmask > > app-portage/demerge > > I would volunteer to proxy maintain these packages, if Christian still > wants to be maintainer for them (his last commit was in 2009). If not, > proxy maintainership doesn't make much sense. > Ulrich, If we decide to proxy maintain these two packages, go ahead and add tool-portage as the herd to back you up. Regards, Paul
Re: [gentoo-dev] Re: rfc: news item for png15
On Fri, 2011-10-14 at 23:03 +0200, Pacho Ramos wrote: > It shouldn't, I am sure I have used this some times before and it worked > as expected, but I don't know when revdep-rebuild cache files are > removed (and then, broken packages recalculated) :-/ > > Any revdep-rebuild maintainer here to clarify this please? Thanks :) Actually all of the current versions of revdep-rebuild are broken and always remove the cache files after completion. The exception to this is when --pretend is used. When it is fixed in the next version of gentoolkit, the behavior is to keep the files if it is a pretend run or if emerge exits with a non-zero status. Note: emerge will exit with a non-zero status if --keep-going is used and there is a build failure. Regards, Paul
Re: [gentoo-dev] Packages up for grabs due truedfx retirement
On Wed, 2011-07-20 at 18:34 +0200, Pacho Ramos wrote: > Due truedfx retirement the following packages need a new maintainer: > > app-editors/le > app-editors/nvi > app-editors/ted > app-misc/glastree > app-portage/cfg-update > dev-libs/librep > dev-libs/tvision > dev-util/dialog > x11-apps/xkbset Additionally, the tools-portage team would be very appreciative if someone would be willing to do active maintenance on app-portage/ufed. The repository for it is at: http://git.overlays.gentoo.org/gitweb/?p=proj/ufed.git;a=summary Regards, Paul
[gentoo-dev] tools-portage herd status
On Mon, 2009-04-27 at 09:08 -0500, Paul Varner wrote: > All: > > The tool-portage herd is currently understaffed and as such is not > making updates in a timely fashion. Currently the herd consists of > zmedico and myself. While Zac has done a good job where he can, he has > a full time job with maintaining and updating portage. In my case, my > real life job has me working 60 - 80 hour work weeks which severely > limits the time I have to work on Gentoo. We are in the process of > recruiting another member of the herd, however, he has a full time job > as well which also limits the amount of time he has available for > Gentoo. > > Because of this, I am publicly announcing that any Gentoo developer who > wants to touch stuff belonging to the tools-portage herd is welcome to > do so. The only requirement is if you accidentally break it, please fix > it as well. Back in April of last year I wrote the above message. Since then the tools-portage team has added idl0r as well as several community developers. However, we are now in the process of losing truedfx who was the main maintainer of ufed. If a current Gentoo developer wants to join the herd to become the ufed maintainer, please let us know. Additionally, since I don't like touching and breaking glsa-check, it would be appreciated if someone would be willing to act as the primary maintainer for that piece of gentoolkit as well. Finally, we have migrated the gentoolkit source code from subversion to git. Gentoo developers can access the repository at: git+ssh://g...@git.overlays.gentoo.org/proj/gentoolkit.git Gentoo Developers have full priviledges to the repository. As before, any Gentoo developer can do work on the gentoolkit source. We only have several requirements. If you want to do a major change (i.e rewrite/refactor something), please talk to us before pushing any commits. If you break something, please fix it. Finally, if you want a new release of gentoolkit or gentoolkit-dev, please coordinate it with either myself or idl0r. Any non Gentoo developers who wish to assist, the best way to get started is by pulling a copy of the repository and submitting patches to bugzilla. Additionally, we can be found in the #gentoo-portage IRC channel. On behalf of the tools-portage team. Paul signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last Rites: app-text/manedit
# Paul Varner (26 Apr 2010) # Masking for removal (bug #315947). # It doesn't compile with newer versions of zlib, still uses gtk1+, and # upstream is unresponsive. Unfortunately, there is not a suitable # replacement. app-text/manedit
Re: [gentoo-dev] Re: Requiring two sets of eyes for all eclass commits
On Sun, 2010-04-25 at 13:11 +0300, Petteri Räty wrote: > On 04/25/2010 01:06 PM, Ryan Hill wrote: > > On Sat, 24 Apr 2010 20:40:54 +0300 > > Petteri Räty wrote: > > > >> What do you think about not allowing commits to eclasses without > >> mentioning an another developer who has reviewed and approved the diff > >> in the commit message? There's enough people on gentoo-dev for urgent > >> stuff too. > > > > I think it's a good idea to strongly encourage it, but actually forcing it > > through cvs? No thanks. I'm not tracking down another dev just to fix a > > spelling mistake. :P > > > > > > How did the spelling mistake get there in the first place? A review > system should reduce having them in the first place. Because the reviewer missed it. gentoolkit-0.3.0 is currently being developed by the user community and I review everything before I commit to the gentoolkit repository. It is amazing, how much still gets through the review process (including spelling errors). While reviews will catch a lot of stuff, they won't catch everything. Finally, my opinion is in line with Ryan's. Strongly encourage it, but do not force it through cvs. Regards, Paul
[gentoo-dev] tools-portage herd status
All:
The tool-portage herd is currently understaffed and as such is not
making updates in a timely fashion. Currently the herd consists of
zmedico and myself. While Zac has done a good job where he can, he has
a full time job with maintaining and updating portage. In my case, my
real life job has me working 60 - 80 hour work weeks which severely
limits the time I have to work on Gentoo. We are in the process of
recruiting another member of the herd, however, he has a full time job
as well which also limits the amount of time he has available for
Gentoo.
Because of this, I am publicly announcing that any Gentoo developer who
wants to touch stuff belonging to the tools-portage herd is welcome to
do so. The only requirement is if you accidentally break it, please fix
it as well.
The gentoolkit repository is in Subversion and can be checked out by a
developer with the following:
svn co svn+ssh://${us...@svn.gentoo.org/var/svnroot/gentoolkit
If any developer has questions, I can always be reached by email. I am
on IRC when I can, but that time is limited by work.
Regards,
Paul
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Last Rites: app-portage/udept
# Paul Varner (14 Dec 2008) # Dead upstream, masked for removal in ~30 to 60 days. app-portage/udept Additionally, it doesn't play well with EAPI's greater than zero. The removal bug is Bug #250839. If upstream comes back alive or someone forks and actively maintains, I will unmask or re-add to the tree. Regards, Paul Varner signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Tue, 2008-08-26 at 13:40 -0700, Robin H. Johnson wrote: > Q: How much have you utilized the primary use case? Not at all > Q: Are there any other use-cases you have and actively use? No
Re: [gentoo-dev] Packages up for grabs
On Sun, 2008-07-20 at 08:44 +0200, Christian Faulhammer wrote: > Hi, > > packages that are in a herd, but could need someone dedicated to it: > > app-portage/elogv, elogviewer, kelogviewer (tools-portage) -- low > maintenance I'll take care of these packages. Regards, Paul
[gentoo-dev] echangelog maintainer needed
All: I need a Gentoo developer to apply some loving care to echangelog. There have been several requests to add git and subversion support to echangelog and the basics are already in place. However, it has bugs and since I don't have the setup to test that support, I have not done a good job at getting the bugs fixed and resolved. The code for echangelog is in the gentoolkit repository in subversion and any developer should have access to the repository. I can walk you through how to cut a new gentoolkit-dev release, or if you are not comfortable with that, I can continue to cut the new releases whenever it needs to be done. Regards, Paul Varner Lead, Gentoo Portage Tools -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New developer: Bo Ørsted Andresen (zlin)
On Thu, 2008-02-28 at 14:28 +0200, Petteri Räty wrote: > He has been breaking the tree for a while now but as Calchan has been > having availability problems I get to insult him a little bit later than > usual. Bo hails from Aalborg, Denmark. He studies to become a control > engineer. On the Gentoo side he is one of the people who enabled KDE4 > coming to our main tree via contributing to their overlays. He has also > contributed to Paludis. Let the usual mud slinging begin. Welcome aboard. If you have the time and inclination, you are more than welcome to join me over in tools-portage. Regards, Paul -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Projects and subproject status
On Mon, 2008-01-07 at 22:31 +0100, Luca Barbato wrote: > Here is a list of interesting questions: "Are we fine?" "What are we > going to do?" > > Please project leaders try to reply in short. tools-portage: Are we fine? The short answer is no. We need more developers. Unfortunately, real life work is consuming all of my time and what free time is left is going to my family. mpagano has started to step up and work bugs, but we definitely need more help. I am on email and IRC so I can answer questions and work with any developer who would like to step up and help (even temporarily). Marius (genone) stepped down as team lead on December 3rd and asked for help for the team at that time. I have not seen any reponses to that request. What are we going to do? Due to lack of time and participation, I currently don't have a good answer for that. On my short list is to get revdep-rebuild fixed. The current state leaves much to be desired and while it works for most people, it is definitely a visible turn off for people when it fails. Regards, Paul -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-portage/gentoolkit: ChangeLog gentoolkit-0.2.4_rc1.ebuild
On Wed, 2007-09-26 at 18:39 -0700, Donnie Berkholz wrote:
> On 00:18 Thu 27 Sep , Paul Varner (fuzzyray) wrote:
> >
> > pkg_postrm() {
> > python_mod_cleanup "${ROOT}"usr/lib/gentoolkit
>
> Shouldn't gentoolkit go into get_libdir() instead of lib? Portage
> appears to...
It probably should, it is going to require changes to the python source
code and Makefile as well though.
Regards,
Paul
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] That time again...
On Wed, 2007-04-25 at 20:12 -0400, Michael Cummings wrote: > G-cpan-0.15 was put out last night; 99% bug fixes, a few easter eggs, and some > tweaks. Any other cool updates in the last few weeks? (it's been 20 days since > the last time I started this thread - at this rate, we might make enough input > to make Chris' job on the gwn easier). I'll use this to send out the message that I was going to send anyways :) I have just placed gentoolkit-dev-0.2.6.5 in the tree which contains an echangelog that supports subversion and git (thanks to antarus and genstef). It is currently package masked so that it can be fully tested. Anyhow, consider this a call for people to test. If you run into any bugs please report them on bug #136048. Secondly, the next pre-release of gentoolkit (gentoolkit-0.2.4_pre6) will have two new utilities in the path (thanks to solar), genpkgindex and epkginfo. genpkgindex creates metadata for binary packages and is suitable for use with qmerge from portage-utils. epkginfo is a small program that will display metadata information about packages in portage. Regards, Paul -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] *DEVELOPMENT* mail list, right?
On Thu, 2007-04-05 at 19:03 -0400, Michael Cummings wrote: > So, fellow devs, what's new with development? For those interested, genlop has > migrated into gentoo as a project with the permission of upstream, which no > longer maintain it. Um...any new tools or projects people are working on? When my systems at work are not kicking my butt, I've been working on shortening the list of bugs assigned to the tools-portage herd. (BTW, thank you for taking genlop). On that note the equery depends/depgraph should work a lot better in the gentoolkit-0.2.4 series of releases than it has in the past. I would appreciate if people would test and look at it. Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Everyone developer should downgrade back to gentoolkit-dev-0.2.6.2
On Sat, 2007-03-24 at 21:56 -0400, Mike Frysinger wrote: > On Saturday 24 March 2007, Petteri Räty wrote: > > Joshua Baergen kirjoitti: > > > It appears to be a problem with gentoolkit-dev-0.2.6.3. 0.2.6.2 > > > produces proper changelogs. > > > > Until the problem is solved everyone should downgrade back to 0.2.6.2. I > > package.masked 0.2.6.3 in the meanwhile. > > isnt this what package mask is for ? and/or just put out a quick -r1 that > reverts echangelog Both have occurred. The bad version has been package masked and removed from the tree. Additionally, the newer version reverts to the same echangelog from 0.2.6.2 Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Introducing Daniel Robbins (drobbins)
On Tue, 2007-02-27 at 19:06 +0200, Petteri Räty wrote: > It's my please to introduce to you Daniel "drobbins" Robbins. Welcome back Daniel, it is good to see you back. Regards, Paul -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last Rites for app-portage/abeni
>From Bug #159329 "abeni was pmasked by pythonhead in April 2005, waiting on a version that supported wxpython-2.6. no release was ever made, and upstream (pythonhead) is MIA. we're starting to phase out wxpython-2.4 support now, so these ebuilds should be removed (too bad, looks like a cool project)." If no one steps up to take ownership, I will be removing it on February 4, 2007 Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users
On Mon, 2006-10-09 at 23:30 -0400, Kari Hazzard wrote: > The point is that if you build Gentoo to be developer-friendly rather than > user-friendly, Gentoo will be replaced by something else. > > User-centric design is why Gentoo is/was different from everything else. Take > away choices that people want and you take the Gentoo philosophy out of > Gentoo itself. However, all developers are users first. If you have an itch to scratch that the current development team isn't meeting, then get involved. There are lots of ways to do that. Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Not offering help to certain parts of society
On Sat, 2006-04-01 at 16:41 +, George Prowse wrote: > The problem is that we are in no way helping our Amish friends. If we > made it easier to use linux then i'm sure they'd embrace FOSS straight > away! I suggest some measures that would help them integrate better > because it may be frowned upon at first. We could start by implementing RFC 1149. http://www.faqs.org/rfcs/rfc1149.html Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] bootstrapping since gcc 3.4 is stable
On Thu, 2006-01-26 at 16:55 -0600, MIkey wrote: > Jan Kundrát wrote: > > > Those are bugs against the revdep-rebuild package. > > Which is one of the suggested methods to migrate gcc. Not necessary from > stage1... How does the listing of revdep-rebuild bugs have anything to do with this topic? None of those bugs are relevant to either a stage 1 install, stage 3 install, or gcc upgrade. Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.11.14 stabilization
> since we have baselayout-1.12.x in ~arch, the new stable candidate > (1.11.14) isnt getting much air time ... can people try upgrading to > it and post any feedback they have with it ? it should mostly be a > bugfix release over 1.11.13 since we arent doing any more real features > for the 1.11.x branch ... Looking good here on a stable x86 system. The only thing that I noted is that >=sys-apps/sysvinit-2.86-r3 will have to go stable at the same time due to it being a dependency. Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving GCC-3.4 to stable on x86
On Tue, 2005-11-29 at 18:37 +0100, Andreas Proschofsky wrote: > It's not that easy for every package. For instance openoffice and > openoffice-bin need to got to the same location, cause OOo does a user > install and this will break when changing between them (and all the > settings / paths and so on). > > So either we would have both in /opt which then means that the source > based OOo is ignored too, or we have them in /usr/lib which results in > the ooo-bin annoyance. I would say the second one is less harmful. > > Btw, there is a long running bug about the revdep-rebuild, which also > has a solution for this: > > https://bugs.gentoo.org/show_bug.cgi?id=32276 While we are talking about this, I would like to point out the following message that I sent here on November 3rd: http://article.gmane.org/gmane.linux.gentoo.devel/32556/ To summarize, in order for revdep-rebuild to ignore binary packages, it needs help from the package maintainers. This is done, by the package installing a file into /etc/revdep-rebuild/ that tells revdep-rebuild what directories to ignore. Regards, Paul -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Binary packages and revdep-rebuild
One of the common complaints with revdep-rebuild is that it wants to constantly rebuild binary packages (most notably openoffice-bin). To assist in resolving this issue, I have released gentoolkit-0.2.1_pre9 which adds the capability for an ebuild maintainer to adjust how revdep-rebuild behaves towards binary packages. The latest revdep-rebuild allows the user to control the following variables: LD_LIBRARY_MASK - Mask of specially evaluated libraries SEARCH_DIRS - List of directories to search for executables and libraries SEARCH_DIRS_MASK - List of directories to not search With the capability that I just added, a package maintainer can now adjust the same variables. To use this capability do the following: 1. Install a file into /etc/revdep-rebuild (I'm using the same convention as /etc/env.d and prefixing the files with a number) 2. Inside of the file, place the appropriate changes to the variables. For example: I have the following file /etc/revdep-rebuild/10openoffice-bin on my system # openoffice-bin revdep-rebuild configuration file SEARCH_DIRS_MASK="/usr/lib/openoffice" 3. revdep-rebuild will accumulate the variables in the following order: environment, /etc/make.conf, /etc/revdep-rebuild/* This means that a user can override your changes if desired, but your changes will be honored by default. Finally, one other change that I am considering is to add a PACKAGE_MASK variable that will only be read from the files in /etc/revdep-rebuild and cannot be overridden by the user (except by editing the file). The purpose will be to tell revdep-rebuild to never attempt to rebuild that package. Before I implement that I would like to get some feedback on if that is a desired feature. Regards, Paul signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] revdep-rebuild
On Sun, 2005-08-14 at 16:32 +0200, Diego 'Flameeyes' Pettenò wrote: > On Sunday 14 August 2005 16:20, Stefan Jones wrote: > > But you could use "ldconfig -p" to gain a list of all the libraries, put > > them in a hash table and then use scanelf. > Please don't. FreeBSD's ldconfig is *not* the same and this would mean > breaking (again) revdep-rebuild on Gentoo/FreeBSD. > Actually, for the next major revision, I am planning on some major collaboration between myself, the Gentoo/FreeBSD team, the OSX team, solar/vapier, and anyone else that is interested. The biggest complaint right now is lack of speed and that means investigating and exploring the different ways of determining library breakage. Some of those solutions are definitely not portable. Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] revdep-rebuild
On Sun, 2005-08-14 at 07:20 -0700, Stefan Jones wrote: > On Sat, 2005-08-13 at 23:26 -0400, Mike Frysinger wrote: > > i've already contacted fuzzray about utilizing two packages solar put > > together > > (and can be found in portage already): > > pax-utils: scanelf > > portage-utils: qfile > > Thanks for the ideas. > > I had a quick look at the programs; > > qfile: This would be useful in cleaning up the the last part of finding > which package the file belongs to. But that part is already fairly quick > compared to the rest. > > scanelf: > > >From what I can see scanelf can print what libraries a file needs but it > cannot say if the libraries are present. For example: > > /usr/bin/scanelf /bin/ls -n > TYPE NEEDED FILE > ET_EXEC librt.so.1,libncurses.so.5,libc.so.6 /bin/ls > > So you would need to keep a list of all libraries to check against. > Thus I prefer using: > LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 /bin/ls > > But you could use "ldconfig -p" to gain a list of all the libraries, put > them in a hash table and then use scanelf. All of this is on my todo list for the next major revision of revdep-rebuild. The one bug that I haven't found an easy, quick, reliable method to fix is Bug 63643 (revdep-rebuild does not rebuild libraries with unresolved symbols). If anyone has suggestions for that one, I would highly appreciate it. Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: gcc-config 2.0 development
On Tue, 2005-08-09 at 18:14 -0400, Daniel Ostrow wrote: > On Tue, 2005-08-09 at 15:12 -0700, Jeremy Huddleston wrote: > > On Tue, 2005-08-09 at 22:19 +0100, Ciaran McCreesh wrote: > > > | but I think having the xml configuration files allows a much more > > > | robust configuration. > > > > > > How so? Using XML doesn't magically make your data files any different. > > > It simply makes them much harder to parse. > > > > That's a matter of opinion. I see it as a way to abstract away the > > configuration and utilize an existing library to handle the parsing. If > > we do want to eliminate outside dependencies (which I think is an > > extremely valid point and concern), then we could internally implement a > > different configuration format that is easier to parse. I'd probably go > > for something similar to the samba/gdm config files if we were to go > > down this road: > > > > I've always been a fan of samba style config files..unlike xml they tend > to be both easy to parse and are human readable. I'd far rather see this > over XML. It's especially attractive as this is also the way that > portage is moving (at the moment) as well. me too I highly prefer the samba style config file over an XML file. It is easy to read, parse, and edit by both human and machine. Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Unmasking of gentoolkit-0.2.1_pre3
On Fri, 2005-06-24 at 14:47 +0200, Sven Köhler wrote: > Last time i used revdep-rebuild, i saw that revdep-rebuild does check > things twice, since therere symlinks like /usr/X11R6/lib to /usr/lib. > > It this "fixed" in the new version? Yes it is. Here is the list of bug fixes and enhancements: * Delete temporary files if the environment does not match the previous environment (bug 95274) * Imported revdep-rebuild release from bug 62644 * Major changes to the functionality when using --package-names/-X The script should now update slotted packages correctly. (bug 22161) * Customizable searching controlled through environment variables. This removes the need for end users to directly modify the script. (bugs 32276, 38011, 59803) * The directories to search are no longer hard coded into the script. revdep-rebuild now determines the directories to search based upon/etc/profile.env and /etc/ld.so.conf. (bugs 32276, 38011, 89781) * --ignore option to ignore temporary files left from previous runs. Automatically ignore temporary files older than 24 hours. (bug 34052) * Always return an exit status based upon success or failure. (bug 38472) * Fixed to only emerge packages with direct missing dependencies. (bug 38487) * New man page. (bug 40042) * emerge is no longer called with --nodeps. This allows for needed dependencies to be pulled in. (bug 62893) * Cleaned up grammatical errors (bug 85278) * Added support for revdep-rebuild --soname /path/to/library.so (bug 91503) * Removed symbolically linked directories from search (bug 93574) * --nocolor option to turn off colored output, the script also obeys the NOCOLOR setting from /etc/make.conf. * Removed dependency on qpkg * Script uses PORTAGE_NICENESS from /etc/make.conf * Undocumented --keep-temp option. This is primarily for debugging/testing. This option prevents temporary files from being deleted. * Changed --soname --soname-regexp options to --library and treat all arguments as basic regular expressions. --soname and --soname-regexp can still be used as options for backwards compatability. * Removed requirement to keep revdep-rebuild and emerge options distinct. Options that are unrecognized by revdep-rebuild are passed directly to emerge. Regards, Paul -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Unmasking of gentoolkit-0.2.1_pre3
Unless there are objections, I am planning on unmasking gentoolkit-0.2.1_pre3 this weekend. This build of gentoolkit contains the new version of revdep-rebuild. This version has been in the tree and package masked since 12 June. During that time, I have not received any bug reports and the feedback that I have seen from the gentoo-user mailing list has been positive. Even though I am unmasking the package, I still need the following architectures to test and keyword the ebuild as requested in bug #62644 mips arm hppa ia64 ppc64 s390 ppc-macos Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Paul Varner (FuzzyRay)
On Thu, 2005-06-16 at 06:41 -0400, Michael Cummings wrote: > wait a sec - i've been taking bugs and such from fuzzyray and only now he's a > dev?? Does that mean I should expect even *more* pain from texas > But of course! You actually been taking bugs from me for awhile and have even accepted some of my patches :) > =:D > > welcome officially fuzzyray, promise not to make to many fuzzball jokes ;) > Actually, I expect to hear fuzzball or worse when I break something. Since ka0ttic didn't pull it from my quiz, here is where FuzzyRay came from: My nickname was given to me by my coworkers. It came from the fact that I rarely show emotions when I'm at work (i.e. my happy face and mad face both look the same). The first part of the nickname came since I had such a "warm and fuzzy" demeanor. The second part comes from being a "ray of sunshine" Several years ago, a coworker put the two together and came up with "Fuzzy Ray Valentine" Thanks for the welcome! Regards, Paul -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Request for testing revdep-rebuild (gentoolkit-0.2.1_pre3)
All: I have bumped gentoolkit to 0.2.1_pre3 and package masked it for architecture testing and general testing of the new improved revdep-rebuild. This version contains lots of bug fixes and I would like give it a workout before unmasking. There are some major changes in identifying the broken links and since I only have access to x86, I want to make sure that I have not broken portability to other achitectures. Because of this, I have keyworded this ebuild with "-* ~x86". I have CC'ed the architecture teams on bug #62644. However, if you are interested in helping to test, please add gentoolkit to your /etc/portage/package unmask and let me know of your results. Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers
On Wed, 2005-06-01 at 21:59 -0400, Mike Frysinger wrote: > On Wednesday 25 May 2005 06:20 pm, Mike Frysinger wrote: > > yes, it's finally that time ... after months of hearing us say 'we want to > > get new baselayout stable asap', we're serious > > last chance ! > > can someone forward the original e-mail here to gentoo-user ? The comments back from gentoo-user have been that it works fine. One was a glowing endorsement of all the changes. Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.11.12-r2 request for testers
On Wed, 2005-05-25 at 18:20 -0400, Mike Frysinger wrote: > yes, it's finally that time ... after months of hearing us say 'we want to > get > new baselayout stable asap', we're serious > > so can people please try out baselayout-1.11.12-r2+ and see if they notice > any > regressions ? the 'best' tests are simply rebooting and seeing if your > system comes up :) > Works fine here on a fairly basic ~x86 desktop. Regards, Paul -- My Gentoo stuff: http://varnerfamily.org/pvarner/gentoo -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] module-rebuild
On Wed, 2005-05-04 at 00:00 +0100, John Mylchreest wrote: > Can I please introduce into the tree sys-kernel/module-rebuild. > This tracks linux-mod installed kernel modules, and also gives you the > ability to remove/add/toggle the list of modules to rebuild. > > Basically.. following a kernel upgrade running: module-update rebuild, > will install all modules installed via portage. > > If you experience any problems, please file a bug at bugzilla. Likewise, > please file a bug and assign it to [EMAIL PROTECTED] if you have any > ideas about the tool. Thanks! I'm installing and playing with it as I type. The code looks a lot cleaner than the code I had plagiarized from revdep-rebuild to do the same thing. Regards, Paul -- My Gentoo stuff: http://varnerfamily.org/pvarner/gentoo -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New apache stuff in testing -> please package.mask it
On Thu, 2005-04-21 at 05:48 +0100, Elfyn McBratney wrote: > I've filed a bug[1] requesting that ebuilds with updated apache stuff > (anything using the new apache-module or depend.apache eclass/the new install > layout) be package.mask'd due to the regressions and breakages in testing. I > may have missed packages in the bug, hence this mail - you know best if your > using new stuff. :) > > Please package.mask said ebuilds ASAP so we can get apache itself into > package.mask. Even though I stated my opinion that I would like to see the new changes package masked again, the consensus that I read on the thread disagreed with that approach. My unsolicited opinion based upon the previous thread is since it is already out of the bag, leave it in ~arch and actively work the bugs so that you can get it to the point of being able to mark it stable. Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [Bug 89729] configure always print a warning message about possibly mistaking build system type
On Wed, 2005-04-20 at 09:52 -0400, Mike Frysinger wrote: > On Wednesday 20 April 2005 08:27 am, Harald van DÄk wrote: > > Perhaps > > make.conf.example (that's provided by portage, right?) should include > > CBUILD, assuming it doesn't cause problems? > > i'm afraid the possibility of users botching this makes it not worth the > effort > > better to keep the definition of CBUILD 'hidden' from most eyes As a user, I had the same thought. Why not have portage set it appropriately unless the user has explicitly defined it? That of course is making the assumption that someone who has explictly set the CBUILD variable knows what they are doing, since they had to go through the trouble of learning about it and the fact that they could set it. Regards, Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Moving the updated apache and associated ebuilds back into package.mask
On Sat, 2005-04-16 at 06:56 +0100, Elfyn McBratney wrote: > The way I see it, we have three options: > - package.mask (downgrades for those early adopters) > - keep the same layout (/etc/apache2/conf, etc.) and wait until 2.2 is out to >change it > - have the newer apache ebuilds migrate from old-style to new-style config >(very hard to do, but possible) > As a user whose apache install is completely hosed at the moment due to these changes, my recommendation is all the above, with it being package masked immediately. Regards, Paul -- gentoo-dev@gentoo.org mailing list
