Re: HEADS UP: xorg upgrade plans
On Fri, 18 May 2007, James Snyder wrote: Regarding the trials and tribulations. I did not, at first, get the message that one shouldn't overlay the testing tree on top of the older tree, and did the first libXft upgrade at that point. That failed and subsequently I needed to do a series of pkgdb -F portupgrade -a commands along with a few make deinstalls to make everything happy. I could post the log of going Oh dear. My xfce4 is broke and I am thinking this procedure might be what i need to do. I have freeBSD-STABLE 6.2 and just was in the middle of trying to update for the first time maybe a month ago, and I haven't really recovered from the experience yet, I think. I am sort of new to being an admin on a UNIX system, but I first learned EVAX in 1985. I was sort of in a haitus of sorts while concentrating on a MS degree in Physiology and Biophysics from about 1990-1998. Right now I can't run any non character based GUIs on this puter. I could really use a complete rundown of the steps in an email, which I read with pine. through all that, however, it's incredibly long, and likely a bit on the confusing side due to not giving up on any dead-ends :-) as long as I have all the steps.. I can go to kinkos and print them out. I have no printer. Merge executed, had to then manually do the simlink. After that, I had trouble with the default font fixed and cursor not being found. I needed to install the appropriate misc-misc misc-cursor fonts to get that going appropriately. I also had to manually install mouse and keyboard input drivers after the new xorg drivers directory was initially created during the upgrade process as a file rather than a directory. Oh dear. I am really going to need steps on this part. Best. -jsnyder ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
So, I've upgraded one more machine, an X60 Tablet, and have run into some issues on this one. First and most important, my ability to use the 1920x1200 resolution has disappeared. I've been using the 915resolution tool to add this mode to the 945GM bios, but Xorg now insists there is no mode of this name. Also, in 7.2, the wacom driver seems to have disappeared. Seems like this is intentional by the Xorg folks, but any suggestions as to where to get a replacement driver would be appreciated. Compositing is also now incredibly slow, much more so than in X11R6. Not a big deal, I don't really need it. Log is at: http://redundancy.redundancy.org/Xorg.0.log Note that I've currently been trying to get Xinerama working, but the same problems appear without Xinerama. Any suggestions or experiences on similar hardware would be welcome. Thanks, David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
Another successful upgrade to report, although not without some trials and tribulations. The end result is that I have things going with the NVIDIA drivers, compositing works (I've even fired up Compiz and though that's not 100% stable, it's quite usable so long as a few things are avoided. Window decorations died once while switching back and forth to another virtual terminal and GL screensavers hang up (first frame rendered, subsequent ones do not). Regarding the trials and tribulations. I did not, at first, get the message that one shouldn't overlay the testing tree on top of the older tree, and did the first libXft upgrade at that point. That failed and subsequently I needed to do a series of pkgdb -F portupgrade -a commands along with a few make deinstalls to make everything happy. I could post the log of going through all that, however, it's incredibly long, and likely a bit on the confusing side due to not giving up on any dead-ends :-) Merge executed, had to then manually do the simlink. After that, I had trouble with the default font fixed and cursor not being found. I needed to install the appropriate misc-misc misc-cursor fonts to get that going appropriately. I also had to manually install mouse and keyboard input drivers after the new xorg drivers directory was initially created during the upgrade process as a file rather than a directory. Best. -jsnyder ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Fri, May 18, 2007 at 03:24:02PM -0500, James Snyder wrote: Window decorations died once while switching back and forth to another virtual terminal and GL screensavers hang up (first frame rendered, subsequent ones do not). I've been meaning to post on this subject, though have been looking for an appropriate nvidia forum or list to have a better chance of making them aware of the problem. So far I'm 0 for 2 on FreeBSD machines using the nvidia driver with GL and Composite. For clients using direct rendering, it behaves as you said -- rendering one frame at most and then hanging. For clients using _indirect_ rendering, it's slightly better. They will render but just be choppy. The weird thing is that the client _thinks_ it's rendering normally (they report normal FPS), but only every 4th or 5th frame actually gets displayed on the screen. If you do something that causes the screen to refresh, such as moving a window or rotating the cube in compiz, then it displays the missing frames and renders pretty much normally -- until you stop the action that's causing it to refresh :) It doesn't seem to make any difference whether the composite manager is using GL or not -- I tried both beryl and xcompmgr. You can force the NVidia libGL to use indirect rendering by setting __GL_FORCE_INDIRECT=1 in the environment. I'm using that as a workaround, though GL clients still look pretty terrible even with it. Craig ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Saving old shared libs (Was: Re: HEADS UP: xorg upgrade plans)
Kris Kennaway wrote: On Tue, May 08, 2007 at 12:06:59AM +0200, Thierry Thomas wrote: Le Lun 7 mai 07 ? 22:58:50 +0200, Brooks Davis [EMAIL PROTECTED] ?crivait?: The other problem is that if you're going to automatically update all the dependencies for a port, you need to upgrade all the stuff that depends on them as well. For example the gettext upgrade got triggered on my laptop by upgrading something the used gmake. The result was that virtually nothing outside the base worked any more. Saving the shared library would have prevented this and allowed a more graceful upgrade over a few weeks. The fact that a basic desktop setup takes days to build on fairly fast hardware seems to be an indication that we need a workaround here. There are other possible solutions, but saving copied of libraries seems to be the accepted one at the moment. For this kind of upgrades, it's possible to add libgettextpo.so.1 libgettextpo.so.3 libintl.so.6libintl.so.8 in your /etc/libmap.conf. Just delete these lines after the storm... It is possible, but this is not something that non-technical users will think of (nor should they have to). The question is whether portmaster is to be considered as a tool for advanced users only (those who are capable of cleaning up and repairing damage themselves when an upgrade fails), or if it is intended as a tool for ordinary users who don't want to (or are not capable of) doing this kind of manual repair work. That's a fair question, and the answer in terms of how it got started is definitely more the former than the latter. As feature requests have come in and as a wider audience has been interested in the tool I've tried to lower the bar quite a bit however. At the same time, I think it's probably worthwhile to examine what the goals of the ports system are in this regard. If the goal is to always provide a fail-safe upgrade path for users then perhaps we should be talking about moving that support into the ports infrastructure, rather than talking about adding it to all the different upgrade tools. That said, I have seen a fair bit of interest in adding the save old shared libs feature, so I'll take a look at that after I'm done with the restart an aborted upgrade stuff I'm working on now. What might be useful in this regard is if someone were to start a new thread describing exactly what the desired behavior is, and ideally to include a description of how portupgrade does it now. Thanks, Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Saving old shared libs (Was: Re: HEADS UP: xorg upgrade plans)
On Thu, May 17, 2007 at 01:06:02PM -0700, Doug Barton wrote: At the same time, I think it's probably worthwhile to examine what the goals of the ports system are in this regard. If the goal is to always provide a fail-safe upgrade path for users then perhaps we should be talking about moving that support into the ports infrastructure, rather than talking about adding it to all the different upgrade tools. This is true, and some first steps are already in progress. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
Would you please inform the progress (or, schedule), so far? port tree looks very quiet in these few days and I cannot see any xorg7.2 in my cvsup'd port tree... ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
2007/5/8, Ken Yamada [EMAIL PROTECTED]: Would you please inform the progress (or, schedule), so far? port tree looks very quiet in these few days and I cannot see any xorg7.2 in my cvsup'd port tree... Currently most development happens in the git repository. You can look at http://git.xbsd.org/?p=freebsd/ports.git;a=summary to see what goes on. Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) It won't fit on the line. -- me, 2001 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
From: Rene Ladan [EMAIL PROTECTED] Currently most development happens in the git repository. You can look at http://git.xbsd.org/?p=freebsd/ports.git;a=summary to see what goes on. No, http://wiki.freebsd.org/ModularXorg; says; --Quote-- Disclaimer If you read about the git repository, forget about it and hold your breath a couple days again. Everything should be merged back to the FreeBSD within a few days. --Unqote-- git may be maintained, but the page already does not show any of git pages and information, anymore. That is the reason why I am asking... ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
Ken Yamada wrote: From: Rene Ladan [EMAIL PROTECTED] Currently most development happens in the git repository. You can look at http://git.xbsd.org/?p=freebsd/ports.git;a=summary to see what goes on. No, http://wiki.freebsd.org/ModularXorg; says; --Quote-- Disclaimer If you read about the git repository, forget about it and hold your breath a couple days again. Everything should be merged back to the FreeBSD within a few days. --Unqote-- git may be maintained, but the page already does not show any of git pages and information, anymore. That is the reason why I am asking... We're committing a last round of fixes and will submit a tarball for testing hopefully tonight or tomorrow. As soon as we'll get enough success reports, we'll go all-in. -- Florent Thoumie [EMAIL PROTECTED] FreeBSD Committer signature.asc Description: OpenPGP digital signature
Re: HEADS UP: xorg upgrade plans
Thank you, Florent. I understand that we need to be patient another two days... ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
Kris Kennaway wrote: Hi all, After many months of hard work (mostly by flz@, as well as others) we are approaching readiness of the xorg 7.2 upgrade. Because this is a huge and disruptive change, we're going to approach it very carefully. Good news that this is moving forward! Congrats to all involved. The current plan is the following: 2) Final prep work in git repository. We need a day or two to confirm the upgrade method for users. Unfortunately testing has exposed a critical deficiency in portupgrade so 'portupgrade -a' will not be enough to give a working upgrade, and some pre-upgrade steps will be required. Has portmaster been evaluated as an upgrade tool? I'm in a better position atm to be able to address any deficiencies if that will help speed this along. Also a post-upgrade step is required to deal with merging remaining files from /usr/X11R6 into /usr/local. 3) Once the proposed upgrade method is in place, we will publish a tarball of the prepared ports tree and request that *all* our ports developers test the upgrade on their own machines before it is committed to CVS. There are many things that can go wrong and we need to make sure that the upgrade goes as smoothly as possible for our less technical users. In particular all ports committers are expected to participate in this process of eating our own dogfood :) Any updates on a timeline for this? 4) Once a suitable number of success reports (e.g. 50) are received and all reported issues are resolved, we'll proceed with importing into CVS. 5) CVS will stay frozen for a period to be evaluated (probably another couple of weeks) to deal with the inevitable remaining fallout as users encounter yet more problems with the upgrade. Do you intend to keep the entire ports tree frozen for weeks? Perhaps I misunderstand? Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Mon, May 07, 2007 at 11:38:46AM -0700, Doug Barton wrote: Kris Kennaway wrote: Hi all, After many months of hard work (mostly by flz@, as well as others) we are approaching readiness of the xorg 7.2 upgrade. Because this is a huge and disruptive change, we're going to approach it very carefully. Good news that this is moving forward! Congrats to all involved. The current plan is the following: 2) Final prep work in git repository. We need a day or two to confirm the upgrade method for users. Unfortunately testing has exposed a critical deficiency in portupgrade so 'portupgrade -a' will not be enough to give a working upgrade, and some pre-upgrade steps will be required. Has portmaster been evaluated as an upgrade tool? I'm in a better position atm to be able to address any deficiencies if that will help speed this along. No, at a minimum I am not comfortable recommending its use until it saves old shared libraries across updates (I sent you email about this a while ago), which is a vital safety and robustness mechanism. Also a post-upgrade step is required to deal with merging remaining files from /usr/X11R6 into /usr/local. 3) Once the proposed upgrade method is in place, we will publish a tarball of the prepared ports tree and request that *all* our ports developers test the upgrade on their own machines before it is committed to CVS. There are many things that can go wrong and we need to make sure that the upgrade goes as smoothly as possible for our less technical users. In particular all ports committers are expected to participate in this process of eating our own dogfood :) Any updates on a timeline for this? Some time this week 4) Once a suitable number of success reports (e.g. 50) are received and all reported issues are resolved, we'll proceed with importing into CVS. 5) CVS will stay frozen for a period to be evaluated (probably another couple of weeks) to deal with the inevitable remaining fallout as users encounter yet more problems with the upgrade. Do you intend to keep the entire ports tree frozen for weeks? Perhaps I misunderstand? Yes, that is the plan. This is an all hands event, and keeping it frozen is the best way to focus developers onto those tasks. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Mon, 07 May 2007 13:42:31 -0500, Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, May 07, 2007 at 11:38:46AM -0700, Doug Barton wrote: Kris Kennaway wrote: Hi all, After many months of hard work (mostly by flz@, as well as others) we are approaching readiness of the xorg 7.2 upgrade. Because this is a huge and disruptive change, we're going to approach it very carefully. Good news that this is moving forward! Congrats to all involved. The current plan is the following: 2) Final prep work in git repository. We need a day or two to confirm the upgrade method for users. Unfortunately testing has exposed a critical deficiency in portupgrade so 'portupgrade -a' will not be enough to give a working upgrade, and some pre-upgrade steps will be required. Has portmaster been evaluated as an upgrade tool? I'm in a better position atm to be able to address any deficiencies if that will help speed this along. My plan is to run 'portmaster -r pkg-config\*'. I think it should do fine as 'portmaster -r' will do it in order very well. No, at a minimum I am not comfortable recommending its use until it saves old shared libraries across updates (I sent you email about this a while ago), which is a vital safety and robustness mechanism. I am one of people that dislike this and it is not required to get build function. ;-) I think this option should be disable by default, because put stuff in lib/compat/pkg hides the problems. Also: http://www.freebsd.org/gnome/docs/faq2.html#q2 == [...] Prevent two versions of the same library. A common source of build failures is the existence of multiple versions of the same library. This can happen if you have two different versions of a port installed, or can even happen through normal portupgrade use. You can back up the libraries in /usr/local/lib/compat/pkg and remove them, and then run portupgrade -u -rf pkg-config. This will force a rebuild of all GNOME-related apps (and a fair number of other apps) without retaining old versions of libraries in /usr/local/lib/compat/pkg. == Cheers, Mezz Also a post-upgrade step is required to deal with merging remaining files from /usr/X11R6 into /usr/local. 3) Once the proposed upgrade method is in place, we will publish a tarball of the prepared ports tree and request that *all* our ports developers test the upgrade on their own machines before it is committed to CVS. There are many things that can go wrong and we need to make sure that the upgrade goes as smoothly as possible for our less technical users. In particular all ports committers are expected to participate in this process of eating our own dogfood :) Any updates on a timeline for this? Some time this week 4) Once a suitable number of success reports (e.g. 50) are received and all reported issues are resolved, we'll proceed with importing into CVS. 5) CVS will stay frozen for a period to be evaluated (probably another couple of weeks) to deal with the inevitable remaining fallout as users encounter yet more problems with the upgrade. Do you intend to keep the entire ports tree frozen for weeks? Perhaps I misunderstand? Yes, that is the plan. This is an all hands event, and keeping it frozen is the best way to focus developers onto those tasks. Kris -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote: No, at a minimum I am not comfortable recommending its use until it saves old shared libraries across updates (I sent you email about this a while ago), which is a vital safety and robustness mechanism. I am one of people that dislike this and it is not required to get build function. ;-) I think this option should be disable by default, because put stuff in lib/compat/pkg hides the problems. Also: No, it is required when dealing with shared library bumps (which happen about once a week). Otherwise all of the installed ports using the library break if the new library build fails. Talk to Brooks about how annoying this is with e.g. gettext. http://www.freebsd.org/gnome/docs/faq2.html#q2 == [...] Prevent two versions of the same library. A common source of build failures is the existence of multiple versions of the same library. This can happen if you have two different versions of a port installed, or can even happen through normal portupgrade use. You can back up the libraries in /usr/local/lib/compat/pkg and remove them, and then run portupgrade -u -rf pkg-config. This will force a rebuild of all GNOME-related apps (and a fair number of other apps) without retaining old versions of libraries in /usr/local/lib/compat/pkg. == I dispute the correctness of this entry. The old libraries in lib/compat/pkg are not linked to directly by new builds. The only situation in which something might end up being linked to 2 versions of the library is if it pulls in a library dependency from an existing port that is still linked to the old library. In this situation the build would be broken with or without lib/compat/pkg (in the latter case, you have an installed port linked to a library that is entirely missing, so that port will be nonfunctional). Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Mon, 07 May 2007 15:14:48 -0500, Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote: No, at a minimum I am not comfortable recommending its use until it saves old shared libraries across updates (I sent you email about this a while ago), which is a vital safety and robustness mechanism. I am one of people that dislike this and it is not required to get build function. ;-) I think this option should be disable by default, because put stuff in lib/compat/pkg hides the problems. Also: No, it is required when dealing with shared library bumps (which happen about once a week). Otherwise all of the installed ports using the library break if the new library build fails. Talk to Brooks about how annoying this is with e.g. gettext. portmaster has a feature to backup the old package before the upgrade. I think it is better than put in lib/compat/pkg. When I used portupgrade and I always have lib/compat/pkg disabled until I switched to portmaster. I never have that problem when ports tree is flexible enough to downgrade and wait until someone fix it. Cheers, Mezz http://www.freebsd.org/gnome/docs/faq2.html#q2 == [...] Prevent two versions of the same library. A common source of build failures is the existence of multiple versions of the same library. This can happen if you have two different versions of a port installed, or can even happen through normal portupgrade use. You can back up the libraries in /usr/local/lib/compat/pkg and remove them, and then run portupgrade -u -rf pkg-config. This will force a rebuild of all GNOME-related apps (and a fair number of other apps) without retaining old versions of libraries in /usr/local/lib/compat/pkg. == I dispute the correctness of this entry. The old libraries in lib/compat/pkg are not linked to directly by new builds. The only situation in which something might end up being linked to 2 versions of the library is if it pulls in a library dependency from an existing port that is still linked to the old library. In this situation the build would be broken with or without lib/compat/pkg (in the latter case, you have an installed port linked to a library that is entirely missing, so that port will be nonfunctional). Kris -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Mon, May 07, 2007 at 03:35:48PM -0500, Jeremy Messenger wrote: On Mon, 07 May 2007 15:14:48 -0500, Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote: No, at a minimum I am not comfortable recommending its use until it saves old shared libraries across updates (I sent you email about this a while ago), which is a vital safety and robustness mechanism. I am one of people that dislike this and it is not required to get build function. ;-) I think this option should be disable by default, because put stuff in lib/compat/pkg hides the problems. Also: No, it is required when dealing with shared library bumps (which happen about once a week). Otherwise all of the installed ports using the library break if the new library build fails. Talk to Brooks about how annoying this is with e.g. gettext. portmaster has a feature to backup the old package before the upgrade. I think it is better than put in lib/compat/pkg. When I used portupgrade and I always have lib/compat/pkg disabled until I switched to portmaster. I never have that problem when ports tree is flexible enough to downgrade and wait until someone fix it. Well, is this feature enabled by default and does it completely back out the upgrade if it fails? I may be wrong, but I doubt it is going to do a complete recursive backout of the upgrade if e.g. one of the ports depending on the new library fails to build after the library was updated. If it just restores the old version of this port then it will be restoring a nonfunctional port, since it links to the version of the library that was already deleted. The issue is about providing seat-belts for our users who just want failed upgrades not to destroy their system. Even if you think that backing up the package is a better solution than preserving the shared libraries, it seems to me that portmaster still falls short here because it doesn't provide a rollback mechanism to restore the system to a working state when an upgrade fails. I dispute the correctness of this entry. The old libraries in lib/compat/pkg are not linked to directly by new builds. The only situation in which something might end up being linked to 2 versions of the library is if it pulls in a library dependency from an existing port that is still linked to the old library. In this situation the build would be broken with or without lib/compat/pkg (in the latter case, you have an installed port linked to a library that is entirely missing, so that port will be nonfunctional). Kris I guess your silence means you agree with me here :) Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Mon, May 07, 2007 at 04:44:14PM -0400, Kris Kennaway wrote: On Mon, May 07, 2007 at 03:35:48PM -0500, Jeremy Messenger wrote: On Mon, 07 May 2007 15:14:48 -0500, Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote: No, at a minimum I am not comfortable recommending its use until it saves old shared libraries across updates (I sent you email about this a while ago), which is a vital safety and robustness mechanism. I am one of people that dislike this and it is not required to get build function. ;-) I think this option should be disable by default, because put stuff in lib/compat/pkg hides the problems. Also: No, it is required when dealing with shared library bumps (which happen about once a week). Otherwise all of the installed ports using the library break if the new library build fails. Talk to Brooks about how annoying this is with e.g. gettext. portmaster has a feature to backup the old package before the upgrade. I think it is better than put in lib/compat/pkg. When I used portupgrade and I always have lib/compat/pkg disabled until I switched to portmaster. I never have that problem when ports tree is flexible enough to downgrade and wait until someone fix it. Well, is this feature enabled by default and does it completely back out the upgrade if it fails? I may be wrong, but I doubt it is going to do a complete recursive backout of the upgrade if e.g. one of the ports depending on the new library fails to build after the library was updated. If it just restores the old version of this port then it will be restoring a nonfunctional port, since it links to the version of the library that was already deleted. The issue is about providing seat-belts for our users who just want failed upgrades not to destroy their system. Even if you think that backing up the package is a better solution than preserving the shared libraries, it seems to me that portmaster still falls short here because it doesn't provide a rollback mechanism to restore the system to a working state when an upgrade fails. For a number of failure modes, the use of pkg_create -b can't do this. In particularly, pkg_create -b can't ignore missing files (because tar can't in turn) so you can't make a package of anything with a missing file. The latest versions of portmaster allow you to ignore this error by default since it's not as if there's anything else you could do, but in that situation there's no backing out. Fixing pkg_create would help here. The other problem is that if you're going to automatically update all the dependencies for a port, you need to upgrade all the stuff that depends on them as well. For example the gettext upgrade got triggered on my laptop by upgrading something the used gmake. The result was that virtually nothing outside the base worked any more. Saving the shared library would have prevented this and allowed a more graceful upgrade over a few weeks. The fact that a basic desktop setup takes days to build on fairly fast hardware seems to be an indication that we need a workaround here. There are other possible solutions, but saving copied of libraries seems to be the accepted one at the moment. -- Brooks pgpW9BCsehkrk.pgp Description: PGP signature
Re: HEADS UP: xorg upgrade plans
On Mon, 07 May 2007 15:44:14 -0500, Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, May 07, 2007 at 03:35:48PM -0500, Jeremy Messenger wrote: On Mon, 07 May 2007 15:14:48 -0500, Kris Kennaway [EMAIL PROTECTED] wrote: On Mon, May 07, 2007 at 03:09:06PM -0500, Jeremy Messenger wrote: No, at a minimum I am not comfortable recommending its use until it saves old shared libraries across updates (I sent you email about this a while ago), which is a vital safety and robustness mechanism. I am one of people that dislike this and it is not required to get build function. ;-) I think this option should be disable by default, because put stuff in lib/compat/pkg hides the problems. Also: No, it is required when dealing with shared library bumps (which happen about once a week). Otherwise all of the installed ports using the library break if the new library build fails. Talk to Brooks about how annoying this is with e.g. gettext. portmaster has a feature to backup the old package before the upgrade. I think it is better than put in lib/compat/pkg. When I used portupgrade and I always have lib/compat/pkg disabled until I switched to portmaster. I never have that problem when ports tree is flexible enough to downgrade and wait until someone fix it. Well, is this feature enabled by default and does it completely back out the upgrade if it fails? Default.. I am not sure, but I just know that there has option and I have disable backup in my configure. As for the second question, no, I don't think it doesn't. The users have to do it by manual to reinstall it. Correct me if I am wrong. [read other replied from Brooks] Brooks said that pkg_create has problems that need to be solve. I guess, it has shoot this down. I may be wrong, but I doubt it is going to do a complete recursive backout of the upgrade if e.g. one of the You are right, it doesn't. I don't think it will be easy to add this feature. ports depending on the new library fails to build after the library was updated. If it just restores the old version of this port then it will be restoring a nonfunctional port, since it links to the version of the library that was already deleted. I think it is rare and will get fix quickly (most of time). It shows real problem rather than hide it by using old library. This is what I like it. It helps our package to be more stable in both build and runtime. The issue is about providing seat-belts for our users who just want failed upgrades not to destroy their system. Even if you think that backing up the package is a better solution than preserving the shared libraries, Yes, I think backing up is a better solution. For example, when library has been bumped but also the plugins, format of configure file or whatever have been complete revamp. The lib/compat/pkg won't help and the backup will. As Brooks said, 'There are other possible solutions, but saving copied of libraries seems to be the accepted one at the moment.' The 'accepted' is opposite for me. It's why I am suggesting to disable it by default if someone is going to add it in portmaster for any users that don't want or have time to help. ;-) it seems to me that portmaster still falls short here because it doesn't provide a rollback mechanism to restore the system to a working state when an upgrade fails. I dispute the correctness of this entry. The old libraries in lib/compat/pkg are not linked to directly by new builds. The only situation in which something might end up being linked to 2 versions of the library is if it pulls in a library dependency from an existing port that is still linked to the old library. In this situation the build would be broken with or without lib/compat/pkg (in the latter case, you have an installed port linked to a library that is entirely missing, so that port will be nonfunctional). Kris I guess your silence means you agree with me here :) Yeah, I guess and unsure at the same time since I didn't write this entry. :-) Cheers, Mezz Kris -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
Le Lun 7 mai 07 à 22:58:50 +0200, Brooks Davis [EMAIL PROTECTED] écrivait : The other problem is that if you're going to automatically update all the dependencies for a port, you need to upgrade all the stuff that depends on them as well. For example the gettext upgrade got triggered on my laptop by upgrading something the used gmake. The result was that virtually nothing outside the base worked any more. Saving the shared library would have prevented this and allowed a more graceful upgrade over a few weeks. The fact that a basic desktop setup takes days to build on fairly fast hardware seems to be an indication that we need a workaround here. There are other possible solutions, but saving copied of libraries seems to be the accepted one at the moment. For this kind of upgrades, it's possible to add libgettextpo.so.1 libgettextpo.so.3 libintl.so.6libintl.so.8 in your /etc/libmap.conf. Just delete these lines after the storm... -- Th. Thomas. pgpcLe3529wST.pgp Description: PGP signature
Re: HEADS UP: xorg upgrade plans
On Tue, May 08, 2007 at 12:06:59AM +0200, Thierry Thomas wrote: Le Lun 7 mai 07 ? 22:58:50 +0200, Brooks Davis [EMAIL PROTECTED] ?crivait?: The other problem is that if you're going to automatically update all the dependencies for a port, you need to upgrade all the stuff that depends on them as well. For example the gettext upgrade got triggered on my laptop by upgrading something the used gmake. The result was that virtually nothing outside the base worked any more. Saving the shared library would have prevented this and allowed a more graceful upgrade over a few weeks. The fact that a basic desktop setup takes days to build on fairly fast hardware seems to be an indication that we need a workaround here. There are other possible solutions, but saving copied of libraries seems to be the accepted one at the moment. For this kind of upgrades, it's possible to add libgettextpo.so.1 libgettextpo.so.3 libintl.so.6 libintl.so.8 in your /etc/libmap.conf. Just delete these lines after the storm... I did found out too late that it works in this case, but it's not a general solution since it only works if the bump was pointless and thus there aren't prototype mismatches. -- Brooks pgpg9rU33rfws.pgp Description: PGP signature
Re: HEADS UP: xorg upgrade plans
On Tue, May 08, 2007 at 12:06:59AM +0200, Thierry Thomas wrote: Le Lun 7 mai 07 ? 22:58:50 +0200, Brooks Davis [EMAIL PROTECTED] ?crivait?: The other problem is that if you're going to automatically update all the dependencies for a port, you need to upgrade all the stuff that depends on them as well. For example the gettext upgrade got triggered on my laptop by upgrading something the used gmake. The result was that virtually nothing outside the base worked any more. Saving the shared library would have prevented this and allowed a more graceful upgrade over a few weeks. The fact that a basic desktop setup takes days to build on fairly fast hardware seems to be an indication that we need a workaround here. There are other possible solutions, but saving copied of libraries seems to be the accepted one at the moment. For this kind of upgrades, it's possible to add libgettextpo.so.1 libgettextpo.so.3 libintl.so.6 libintl.so.8 in your /etc/libmap.conf. Just delete these lines after the storm... It is possible, but this is not something that non-technical users will think of (nor should they have to). The question is whether portmaster is to be considered as a tool for advanced users only (those who are capable of cleaning up and repairing damage themselves when an upgrade fails), or if it is intended as a tool for ordinary users who don't want to (or are not capable of) doing this kind of manual repair work. If the goal is the former, then that's OK, but if it is the latter, then an honest evaluation leads one to conclude that portmaster is still in the process of maturing towards achieving this goal. Kris pgp0Jm7l6IJZa.pgp Description: PGP signature
Re: HEADS UP: xorg upgrade plans
On Mon, 2007-05-07 at 18:26 -0400, Kris Kennaway wrote: I dispute the correctness of this entry. The old libraries in lib/compat/pkg are not linked to directly by new builds. The only situation in which something might end up being linked to 2 versions of the library is if it pulls in a library dependency from an existing port that is still linked to the old library. In this situation the build would be broken with or without lib/compat/pkg (in the latter case, you have an installed port linked to a library that is entirely missing, so that port will be nonfunctional). Kris I guess your silence means you agree with me here :) Yeah, I guess and unsure at the same time since I didn't write this entry. :-) OK. I didn't write it either, but it holds some truth. Yes, not having the library at all would cause a build failure, but having multiple versions of the same library can lead to runtime failures. It's much easier to troubleshoot a missing .so that it is to hunt down strange runtime failures (usually). I'm not arguing for or against portmaster, or the keeping old shared objects functionality. I'm just putting this FAQ entry in context. Yes, perhaps it could be re-worded for clarity. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
HEADS UP: xorg upgrade plans
Ok, no worries then. I have no plans to add that feature at this time, partly because there has been no user demand for it, and mostly because I don't like the idea. I recognize however that reasonable minds may differ on that topic. if you don't like the idea, that's fine, but since you say there's been no user demand, i just thought i should note that I tried portmaster a few months ago. while there were things i like, i ultimately switched back to portupgrade specifically because it lacked old library preservation. /brian Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
Brian Gruber wrote: Ok, no worries then. I have no plans to add that feature at this time, partly because there has been no user demand for it, and mostly because I don't like the idea. I recognize however that reasonable minds may differ on that topic. if you don't like the idea, that's fine, but since you say there's been no user demand, i just thought i should note that I tried portmaster a few months ago. while there were things i like, i ultimately switched back to portupgrade specifically because it lacked old library preservation. /brian Just a thought, but have people considered pushing nVidia and (gasp), maybe ATI for driver support in 7.2? I would think that AMD would at least consider FreeBSD if we moved to 7.2 because it seems like they want to get on the bandwagon with more recent versions of Linux nowadays with their OpenGL driver support. Cheers, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
/usr/local Hello. Why is FreeBSD using /usr/local instead of /usr/X11R7? thanks, MC ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
mal content wrote: /usr/local Hello. Why is FreeBSD using /usr/local instead of /usr/X11R7? thanks, MC A version dependant directory structure hasn't been a good idea in the first place. No one was really able to tell weather to put a port into /usr/X11R6 or /usr/local anyway. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Thu, May 03, 2007 at 05:43:47PM +0100, mal content wrote: /usr/local Hello. Why is FreeBSD using /usr/local instead of /usr/X11R7? /usr/local is the new de facto standard, AFAIK no-one is using /usr/X11R7. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On 03/05/07, Kris Kennaway [EMAIL PROTECTED] wrote: On Thu, May 03, 2007 at 05:43:47PM +0100, mal content wrote: /usr/local Hello. Why is FreeBSD using /usr/local instead of /usr/X11R7? /usr/local is the new de facto standard, AFAIK no-one is using /usr/X11R7. Kris Oh, OK. thanks, MC ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Thursday 03 May 2007 19:12:45 [LoN]Kamikaze wrote: mal content wrote: /usr/local Hello. Why is FreeBSD using /usr/local instead of /usr/X11R7? thanks, MC A version dependant directory structure hasn't been a good idea in the first place. No one was really able to tell weather to put a port into /usr/X11R6 or /usr/local anyway. And it's virtually impossible to make a clean pkg-plist if a port/pkg needs to put stuff in *both* LOCALBASE and X11BASE. Let alone make it PREFIX safe (you have to choose either as default and cwd to the other halfway the plist). /usr/X11R6 was a long standing bug about to be fixed once and for all. IIRC it originated from fixed paths in the old XFree. It won't be missed or mourned :) Dan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
Danny Pansters writes: /usr/X11R6 was a long standing bug about to be fixed once and for all. IIRC it originated from fixed paths in the old XFree. It won't be missed or mourned :) While I understand why this is going to happen, I've been of the opinion it ought to be retained with contents limited to the installed X Windows distribution. Robert Huff ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Thu, 2007-05-03 at 15:37 -0400, Robert Huff wrote: Danny Pansters writes: /usr/X11R6 was a long standing bug about to be fixed once and for all. IIRC it originated from fixed paths in the old XFree. It won't be missed or mourned :) While I understand why this is going to happen, I've been of the opinion it ought to be retained with contents limited to the installed X Windows distribution. Robert Huff This move was also already done on a number of Linux distros... -- Coleman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: xorg upgrade plans
Hi all, After many months of hard work (mostly by flz@, as well as others) we are approaching readiness of the xorg 7.2 upgrade. Because this is a huge and disruptive change, we're going to approach it very carefully. The current plan is the following: 1) Tag ports with PRE_XORG_7 and freeze the ports tree. This will give a stable base from which to prepare the final patchset in the secondary git repository that has been used for xorg integration. This will probably happen in the next day or two; sorry for the short notice but I don't want to artificially delay any longer (this has already been delayed for months by other reasons). 2) Final prep work in git repository. We need a day or two to confirm the upgrade method for users. Unfortunately testing has exposed a critical deficiency in portupgrade so 'portupgrade -a' will not be enough to give a working upgrade, and some pre-upgrade steps will be required. Also a post-upgrade step is required to deal with merging remaining files from /usr/X11R6 into /usr/local. 3) Once the proposed upgrade method is in place, we will publish a tarball of the prepared ports tree and request that *all* our ports developers test the upgrade on their own machines before it is committed to CVS. There are many things that can go wrong and we need to make sure that the upgrade goes as smoothly as possible for our less technical users. In particular all ports committers are expected to participate in this process of eating our own dogfood :) 4) Once a suitable number of success reports (e.g. 50) are received and all reported issues are resolved, we'll proceed with importing into CVS. 5) CVS will stay frozen for a period to be evaluated (probably another couple of weeks) to deal with the inevitable remaining fallout as users encounter yet more problems with the upgrade. Thanks for your support, and get ready for xorg 7.2! :-) Kris pgpS2lTb1nFBc.pgp Description: PGP signature
Re: HEADS UP: xorg upgrade plans
On Wed, May 02, 2007 at 02:40:26PM -0500, Stephen Montgomery-Smith wrote: On Wed, 2 May 2007, Kris Kennaway wrote: Hi all, After many months of hard work (mostly by flz@, as well as others) we are approaching readiness of the xorg 7.2 upgrade. Because this is a huge and disruptive change, we're going to approach it very carefully. I tried X 7.2 about a week ago, and I can report some minor problems. First, pkg_delete -a took far too long. X7.2 has so many dependencies, that I sense that it is beginning to overload the ports structure. My guess is that pkg_delete -a spends a huge amount of time just checking out all the dependencies before it even starts. To some extent this is true. It's not something we can fix now though. Secondly, X7.2 as I tried it wouldn't startx if some other login had created a .Xauthority file. While rm .Xauthority solved the problem completely, I don't think this is user friendly. I think I ran into this once a while back, I don't know what is the correct solution. Kris pgpurBEdVnCN1.pgp Description: PGP signature
Re: HEADS UP: xorg upgrade plans
On Wed, 2 May 2007, Kris Kennaway wrote: On Wed, May 02, 2007 at 02:40:26PM -0500, Stephen Montgomery-Smith wrote: Secondly, X7.2 as I tried it wouldn't startx if some other login had created a .Xauthority file. While rm .Xauthority solved the problem completely, I don't think this is user friendly. I think I ran into this once a while back, I don't know what is the correct solution. Perhaps you could put in some kind of setenv XAUTHORITY .Xlocalauthority in a script somewhere. Actually this one can bite you quite badly. If you are running X, and then you login from somehwere else, and then go back to the X session, then suddenly all your X commands like xterm will completely stop working. It can be really disconcerting if you don't know what caused it, and I can see a large number of help messages being generated on the various bulletin boards. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Wed, 2 May 2007, Martin Tournoij wrote: On Wed 02 May 2007 14:05, Stephen Montgomery-Smith wrote: On Wed, 2 May 2007, Kris Kennaway wrote: Hi all, After many months of hard work (mostly by flz@, as well as others) we are approaching readiness of the xorg 7.2 upgrade. Because this is a huge and disruptive change, we're going to approach it very carefully. I tried X 7.2 about a week ago, and I can report some minor problems. First, pkg_delete -a took far too long. X7.2 has so many dependencies, that I sense that it is beginning to overload the ports structure. My guess is that pkg_delete -a spends a huge amount of time just checking out all the dependencies before it even starts. Secondly, X7.2 as I tried it wouldn't startx if some other login had created a .Xauthority file. While rm .Xauthority solved the problem completely, I don't think this is user friendly. But I might be a little out of sate, and all this has since been fixed. Stephen Doesn't this do the same as pkg_delete -a: rm -r /var/db/pkg /usr/local /usr/X11R6 The main difference is that pkg_delete checks the file's checksums, and leaves files with changed checksums alone. Yes. And indeed this is more or less what I did (I had various config files in /usr/local/etc that I didn't want deleted). But this is most definitely not a user friendly solution! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Wed, May 02, 2007 at 03:26:25PM -0600, Coleman Kane wrote: On Wed, 2007-05-02 at 15:43 -0400, Kris Kennaway wrote: On Wed, May 02, 2007 at 02:40:26PM -0500, Stephen Montgomery-Smith wrote: On Wed, 2 May 2007, Kris Kennaway wrote: Hi all, After many months of hard work (mostly by flz@, as well as others) we are approaching readiness of the xorg 7.2 upgrade. Because this is a huge and disruptive change, we're going to approach it very carefully. I tried X 7.2 about a week ago, and I can report some minor problems. I've been following the xorg 7.2 tree for some time, and recently around the time of either the move to /usr/local or the ruby18 update (they happened pretty close together for me) portupgrade -na seems to have broken for me. It just hangs there forever, seemingly doing something in the background and never actually starts checking for updated ports. Tried rebuilding INDEX, INDEX.db, and pkgdb.db to no avail... Once I let it go overnight and the process died with an Illegal Instruction signal... One of the effects of portupgrade -a using the wrong upgrade order is that is possible to introduce cycles into the dependency graph (A depends on B, B depends on A, where I have seen A = xorg-libraries and B = libXft). In my case it was pkg_create and a cycle in the +REQUIRED_BY lists (pkg_create looped for an hour between these two ports but eventually gave up and proceeded). It is possible that portupgrade might get itself into a similar state somehow. pkgdb -L might fix it for you. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Wed, 2 May 2007, Kris Kennaway wrote: In particular all ports committers are expected to participate in this process of eating our own dogfood :) Our marketing folks educated me to use the phrase drinking our own champagne instead. :) 5) CVS will stay frozen for a period to be evaluated (probably another couple of weeks) to deal with the inevitable remaining fallout as users encounter yet more problems with the upgrade. Does this freeze apply to the whole ports tree, or only (relatively directly) affected parts of the tree? For example, does this also apply to lang/gccXY? Gerald -- Gerald (Jerry) Pfeifer [EMAIL PROTECTED] http://www.pfeifer.com/gerald/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Wed, 2007-05-02 at 15:43 -0400, Kris Kennaway wrote: On Wed, May 02, 2007 at 02:40:26PM -0500, Stephen Montgomery-Smith wrote: On Wed, 2 May 2007, Kris Kennaway wrote: Hi all, After many months of hard work (mostly by flz@, as well as others) we are approaching readiness of the xorg 7.2 upgrade. Because this is a huge and disruptive change, we're going to approach it very carefully. I tried X 7.2 about a week ago, and I can report some minor problems. I've been following the xorg 7.2 tree for some time, and recently around the time of either the move to /usr/local or the ruby18 update (they happened pretty close together for me) portupgrade -na seems to have broken for me. It just hangs there forever, seemingly doing something in the background and never actually starts checking for updated ports. Tried rebuilding INDEX, INDEX.db, and pkgdb.db to no avail... Once I let it go overnight and the process died with an Illegal Instruction signal... First, pkg_delete -a took far too long. X7.2 has so many dependencies, that I sense that it is beginning to overload the ports structure. My guess is that pkg_delete -a spends a huge amount of time just checking out all the dependencies before it even starts. To some extent this is true. It's not something we can fix now though. Secondly, X7.2 as I tried it wouldn't startx if some other login had created a .Xauthority file. While rm .Xauthority solved the problem completely, I don't think this is user friendly. I think I ran into this once a while back, I don't know what is the correct solution. Kris -- Coleman Kane ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Wed, May 02, 2007 at 11:36:03PM +0200, Gerald Pfeifer wrote: On Wed, 2 May 2007, Kris Kennaway wrote: In particular all ports committers are expected to participate in this process of eating our own dogfood :) Our marketing folks educated me to use the phrase drinking our own champagne instead. :) ;-) 5) CVS will stay frozen for a period to be evaluated (probably another couple of weeks) to deal with the inevitable remaining fallout as users encounter yet more problems with the upgrade. Does this freeze apply to the whole ports tree, or only (relatively directly) affected parts of the tree? For example, does this also apply to lang/gccXY? It will apply to everything. It will be basically the same procedure we usually use for a release cycle, since this event is easily comparable in scope (probably bigger in fact). The good news is that if we all jump in to help, the freeze will be over sooner. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Wed, May 02, 2007 at 11:36:03PM +0200, Gerald Pfeifer wrote: Does this freeze apply to the whole ports tree, or only (relatively directly) affected parts of the tree? The latter is basically most of the tree :-) mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Wed, May 02, 2007 at 03:31:59PM -0400, Kris Kennaway wrote: 3) Once the proposed upgrade method is in place, we will publish a tarball of the prepared ports tree and request that *all* our ports developers test the upgrade on their own machines before it is committed to CVS. There are many things that can go wrong and we need to make sure that the upgrade goes as smoothly as possible for our less technical users. In particular all ports committers are expected to participate in this process of eating our own dogfood :) You're talking about the software which gets installed and configured only once on my machine (that is when it is removed from the box), being fiddled with for days to get it working in 1280x1024 in 16bpp (because 24bpp only works in 1024x768), caused me hundreds of hangs and reboots because I enter the wrong values in some obscure register somewhere and cause frightened looks of my wife and son when I come outside my study because the computer is fsck()ing again after an unexpected hang? You are asking a lot of me :-) Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://www.mavetju.org/weblog/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg upgrade plans
On Wed, May 02, 2007 at 03:31:59PM -0400, Kris Kennaway wrote: Hi all, After many months of hard work (mostly by flz@, as well as others) we are approaching readiness of the xorg 7.2 upgrade. Because this is a huge and disruptive change, we're going to approach it very carefully. The current plan is the following: 1) Tag ports with PRE_XORG_7 and freeze the ports tree. This will give a stable base from which to prepare the final patchset in the secondary git repository that has been used for xorg integration. This will probably happen in the next day or two; sorry for the short notice but I don't want to artificially delay any longer (this has already been delayed for months by other reasons). The freeze will begin at 0400 UTC on 04 May, i.e. a little over 24 hours from now. Kris pgpV2smwM4MNc.pgp Description: PGP signature
