On Jul 5, 2007, at 16:50, Peter Farsinsen wrote:
Ryan Schmidt wrote:
Please "sudo port sync" and try again. It may take up to 12 hours for the change to become available.
That's just great!
Should I just do the "port sync" or should I upgrade the port to? And when will I know when the change is available? Just tried "port sync" and it didn't give any output.
The change is committed to the Subversion repository, but changes only get copied to the rsync server a couple times a day. I'm not sure what schedule it's currently on, but if you wait 12 hours, then you'll be sure the change is available. Then you "sudo port sync" to retrieve the fixed portfile, then "sudo port -ncuf upgrade mysql5" to reinstall mysql5 with the fix. That should do it. I'm not sure what output "port sync" is supposed to print, actually. I have my MacPorts set to use Subversion, not rsync, for the ports tree, so I see different output than you would.
I have MacPorts 1.4.2 on OSX 10.4.10 Whenever I've done a port sync recently (and I do it most days), I seem to be downloading the whole heirarchy every time, and none of my ports are outdated when I do a port outdated. I used to just get a listing of the ports that had changed when I did a sudo port -d selfupdate, I can't believe that everything is updated every day. Maybe it is subtly changing every day, but it just seems to be the same long list every day ... For instance Last login: Thu Jul 5 00:13:06 on ttyp1 Welcome to Darwin! powerbook:~ user$ sudo port -d selfupdate Password: DEBUG: Rebuilding the MacPorts base system if needed. DEBUG: Synchronizing dports tree(s) Synchronizing from rsync://rsync.darwinports.org/dpupdate/dports receiving file list ... done ./ aqua/ aqua/Affiche/ aqua/AppKiDo/ aqua/AquaLess/ aqua/ArpSpyX/ aqua/AssignmentTrackerX/ aqua/BigSQL/ aqua/BigSQL/files/ ... and so on ... zope/zope-zphotoslides/files/ zope/zope-zsyncer/ PortIndex aqua/Growl/files/patch-Growl.xcodeproj__project.pbxproj.i386 aqua/Growl/files/patch-Growl.xcodeproj__project.pbxproj.powerpc aqua/Growl/files/patch-Makefile databases/mysql5/Portfile databases/sqlite3/Portfile databases/sqlite3/files/patch-Makefile.in devel/dialog/Portfile ... and so on ... textproc/libmrss/Portfile textproc/libnxml/Portfile deleting textproc/libmrss/files/patch-src-mrss_parser.c deleting directory textproc/libmrss/files sent 9951 bytes received 287107 bytes 13202.58 bytes/sec total size is 14699706 speedup is 49.48 DEBUG: MacPorts base dir: /opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate1/base DEBUG: Setting user: root DarwinPorts base version 1.442 installed DEBUG: Updating using rsync receiving file list ... done ./ Mk/ config/ doc/ doc/exampleport/ portmgr/ portmgr/bots/ portmgr/dmg/ src/ src/cflib1.0/ src/darwinports1.0/ src/darwintracelib1.0/ src/package1.0/ src/pextlib1.0/ src/pextlib1.0/tests/ src/port/ src/port1.0/ src/port1.0/resources/ src/port1.0/resources/fetch/ src/port1.0/resources/group/ src/port1.0/resources/package/ src/port1.0/tests/ src/portindex/ src/programs/ src/programs/daemondo/ src/registry1.0/ tests/ tests/test/ tests/test/checksums-1/ tests/test/cvs-and-patchsites/ tests/test/dependencies-a/ tests/test/dependencies-b/ tests/test/dependencies-c/ tests/test/envvariables/ tests/test/site-tags/ tests/test/trace/ tests/test/universal/ tests/test/universal-2/ tests/test/xcodeversion/ sent 77 bytes received 4957 bytes 2013.60 bytes/sec total size is 2093103 speedup is 415.79 Downloaded MacPorts base version 1.442 The MacPorts installation is not outdated and so was not updated DEBUG: Setting ownership to root selfupdate done!
On 07/05/2007 16:14, "Mark Hattam" <mark@dxradio.demon.co.uk> wrote:
Whenever I've done a port sync recently (and I do it most days), I seem to be downloading the whole heirarchy every time, and none of my ports are outdated when I do a port outdated. I used to just get a listing of the ports that had changed when I did a sudo port -d selfupdate, I can't believe that everything is updated every day. Maybe it is subtly changing every day, but it just seems to be the same long list every day ...
Consider this: $ denbuen[509] > sudo port -d sync [ lots of output, lots of packages seemingly updated ] $ denbuen[510] > sudo port install erlang ---> Activating erlang R11B-5_0 ---> Cleaning erlang $ denbuen[511] > sudo port -d sync DEBUG: Synchronizing dports tree(s) Synchronizing from rsync://rsync.darwinports.org/dpupdate/dports receiving file list ... done lang/erlang/ sent 77 bytes received 268885 bytes 28311.79 bytes/sec total size is 14699737 speedup is 54.65 $ denbuen[512] > Note that I had the latest erlang before doing that `sudo port install erlang`. So presumably many port operations cause rsync to pull an update. Probably any time you upgrade, activate, or install a package (or any dependency), you will see an rsync update. -Denis
The reason why you now see the full list of ports when you sync your tree, as opposed to a delta with only the files that have seen changes since your last sync, is that I changed the way in which the rsync repos feeding your ports and base trees are populated. The operation used to involve an svn checkout of the ports and base trees and then an rsync (excluding certain files and dirs) from that checkout onto the rsync repos, wherefrom users get them through sync/ selfupdate. Now we don't just rsync the svn checkout onto the rsync server with some particular flags to exclude files we don't want in there, like .svn control dirs, but instead we "svn export" the trees to prepare them in a more formal fashion before pushing them to the rsync server. That operation presumably resets a timestamp on each file and dir and that's why you pull the entire thing again when you sync/selfupdate after each half an hour (the periodicity of the rsync server re-population). In other words, we were preparing the rsync repos rather manually before and now we let "svn export" do that for us. The entire process is described in the script I re-wrote and in the config file detailing the rsync server setup: http://trac.macports.org/projects/macports/browser/trunk/base/portmgr/ mprsyncup http://trac.macports.org/projects/macports/browser/trunk/base/portmgr/ rsync.repos Improvements to the mprsyncup script are welcome, I personally don't like pulling the entire thing over and over again after every half an hour either, but I do like relying on "svn export". I'm sure there are rsync flags we could use to recover the delta part of the old behavior while still keeping "svn export", but I just haven't had the time to investigate. Again, suggestions/improvements are welcome! ;-) Regards,... -jmpp On Jul 5, 2007, at 6:14 PM, Mark Hattam wrote:
I have MacPorts 1.4.2 on OSX 10.4.10
Whenever I've done a port sync recently (and I do it most days), I seem to be downloading the whole heirarchy every time, and none of my ports are outdated when I do a port outdated. I used to just get a listing of the ports that had changed when I did a sudo port -d selfupdate, I can't believe that everything is updated every day. Maybe it is subtly changing every day, but it just seems to be the same long list every day ...
For instance
Last login: Thu Jul 5 00:13:06 on ttyp1 Welcome to Darwin! powerbook:~ user$ sudo port -d selfupdate Password: DEBUG: Rebuilding the MacPorts base system if needed. DEBUG: Synchronizing dports tree(s) Synchronizing from rsync://rsync.darwinports.org/dpupdate/dports receiving file list ... done ./ aqua/ aqua/Affiche/ aqua/AppKiDo/ aqua/AquaLess/ aqua/ArpSpyX/ aqua/AssignmentTrackerX/ aqua/BigSQL/ aqua/BigSQL/files/
... and so on ...
zope/zope-zphotoslides/files/ zope/zope-zsyncer/ PortIndex aqua/Growl/files/patch-Growl.xcodeproj__project.pbxproj.i386 aqua/Growl/files/patch-Growl.xcodeproj__project.pbxproj.powerpc aqua/Growl/files/patch-Makefile databases/mysql5/Portfile databases/sqlite3/Portfile databases/sqlite3/files/patch-Makefile.in devel/dialog/Portfile
... and so on ...
textproc/libmrss/Portfile textproc/libnxml/Portfile deleting textproc/libmrss/files/patch-src-mrss_parser.c deleting directory textproc/libmrss/files
sent 9951 bytes received 287107 bytes 13202.58 bytes/sec total size is 14699706 speedup is 49.48 DEBUG: MacPorts base dir: /opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate1/base DEBUG: Setting user: root DarwinPorts base version 1.442 installed DEBUG: Updating using rsync receiving file list ... done ./ Mk/ config/ doc/ doc/exampleport/ portmgr/ portmgr/bots/ portmgr/dmg/ src/ src/cflib1.0/ src/darwinports1.0/ src/darwintracelib1.0/ src/package1.0/ src/pextlib1.0/ src/pextlib1.0/tests/ src/port/ src/port1.0/ src/port1.0/resources/ src/port1.0/resources/fetch/ src/port1.0/resources/group/ src/port1.0/resources/package/ src/port1.0/tests/ src/portindex/ src/programs/ src/programs/daemondo/ src/registry1.0/ tests/ tests/test/ tests/test/checksums-1/ tests/test/cvs-and-patchsites/ tests/test/dependencies-a/ tests/test/dependencies-b/ tests/test/dependencies-c/ tests/test/envvariables/ tests/test/site-tags/ tests/test/trace/ tests/test/universal/ tests/test/universal-2/ tests/test/xcodeversion/
sent 77 bytes received 4957 bytes 2013.60 bytes/sec total size is 2093103 speedup is 415.79 Downloaded MacPorts base version 1.442 The MacPorts installation is not outdated and so was not updated DEBUG: Setting ownership to root selfupdate done! _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
On Jul 5, 2007, at 6:04 PM, Ryan Schmidt wrote:
On Jul 5, 2007, at 16:50, Peter Farsinsen wrote:
Ryan Schmidt wrote:
Please "sudo port sync" and try again. It may take up to 12 hours for the change to become available.
That's just great!
Should I just do the "port sync" or should I upgrade the port to? And when will I know when the change is available? Just tried "port sync" and it didn't give any output.
The change is committed to the Subversion repository, but changes only get copied to the rsync server a couple times a day. I'm not sure what schedule it's currently on, but if you wait 12 hours, then you'll be sure the change is available. Then you "sudo port sync" to retrieve the fixed portfile, then "sudo port -ncuf upgrade mysql5" to reinstall mysql5 with the fix. That should do it.
You should really beat that guy who broke the mysql5 port, I mean really! :-P In any case, the rsync repos feeding sync/selfupdate re-populate every half hour, on the hour, so the wait is surely much shorter than 12 hours. Regards,... -jmpp
On 06/07/2007, at 16:07, Juan Manuel Palacios wrote:
I'm sure there are rsync flags we could use to recover the delta part of the old behavior while still keeping "svn export"
Alternatively, if there aren't any options to suppress just the output of changed directories (I don't think there are, but I may have missed something), we could just regex out any output that is just a directory name. Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Email: boeyms at macports dot org
On Jul 6, 2007, at 01:07, Juan Manuel Palacios wrote:
The reason why you now see the full list of ports when you sync your tree, as opposed to a delta with only the files that have seen changes since your last sync, is that I changed the way in which the rsync repos feeding your ports and base trees are populated.
The operation used to involve an svn checkout of the ports and base trees and then an rsync (excluding certain files and dirs) from that checkout onto the rsync repos, wherefrom users get them through sync/selfupdate.
Now we don't just rsync the svn checkout onto the rsync server with some particular flags to exclude files we don't want in there, like .svn control dirs, but instead we "svn export" the trees to prepare them in a more formal fashion before pushing them to the rsync server. That operation presumably resets a timestamp on each file and dir and that's why you pull the entire thing again when you sync/selfupdate after each half an hour (the periodicity of the rsync server re-population).
Ah, I see now: the list printed is the list of items with differing modification timestamps. Because the svn export is recreated every half hour, the modification timestamps of all items vary every half hour as well.
In other words, we were preparing the rsync repos rather manually before and now we let "svn export" do that for us. The entire process is described in the script I re-wrote and in the config file detailing the rsync server setup:
http://trac.macports.org/projects/macports/browser/trunk/base/ portmgr/mprsyncup http://trac.macports.org/projects/macports/browser/trunk/base/ portmgr/rsync.repos
Improvements to the mprsyncup script are welcome, I personally don't like pulling the entire thing over and over again after every half an hour either, but I do like relying on "svn export". I'm sure there are rsync flags we could use to recover the delta part of the old behavior while still keeping "svn export", but I just haven't had the time to investigate. Again, suggestions/ improvements are welcome! ;-)
So, why are you so keen on using svn export, when it causes the above issue? I recommend using an rsync command instead of svn export. It should work the same, except that it will avoid the above issue. See this message: http://svn.haxx.se/users/archive-2006-06/0971.shtml Or, is that what the script was doing before? If so, again, why did you want to change it?
participants (5)
-
Boey Maun Suang
-
Denis Bueno
-
Juan Manuel Palacios
-
Mark Hattam
-
Ryan Schmidt