Re: [Fink-devel] First thoughts about "universal binaries"
On Mon, Jun 06, 2005 at 11:32:52PM -0400, Daniel Macks wrote: > This may sound naive, but while fat binaries would be important if our > distribution mechanism were "one binary package file, works > everywhere", do we actually expect to have users with a single /sw > that will be used cross-platform? I'm not sure a single /sw will even work cross platform. I'm thinking of config files which may have different settings, paths which have architectures in them, etc. With this in mind, /sw should be thin, and I'd use the existing apt mechanism to handle different architectures, and skip fat entirely. This will cause some heart burn for people who want to cross compile, but will be the simplest approach. Rob --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] First thoughts about "universal binaries"
On Tue, Jun 07, 2005 at 09:01:02AM +0900, Peter O'Gorman wrote: > > I advise against the fat approach, I know Rob Braun tried it at some point > and had issues (I cc'ed him). My experience has mostly been with ppc and i386 fat building. Going all fat isn't terrible. It'll cause problems in a few packages (notably gmp), but for the most part its not that bad. However, it does raise the bar a bit for port maintainers. The real headache is mixing fat and thin. It should be all or nothing. Having dependencies on specific architectures (required for building and such). Building fat is fundamentally different than building thin for each architecture and merging the results. Neither is "better", just different. In some cases building fat may be the desired way, other times it may be better to build thin and intelligently merge the results. Some of the generated files may be different. It's not just merging fat binaries. Anyway, I'd suggest that if supporting fat is a goal, going all fat or no fat would be my vote. Going all fat will be a hassle but doable. Adding/removing an architecture in the future would still raise the partial fat problems. In any case, fat is "hard", and if it is a goal, we can start keeping a list of known issues somewhere, deciding what will and won't be solved immediately, and then start prototyping it to find other issues. Rob --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] libdnet/libdnet1
While trying to build nessus-ssl, I came across an interesting problem with libdnet. The root of the problem is 10.4-transitional/stable libdnet installs the shlibs as libdnet-shlibs and unstable installs them as libdnet1-shlibs with no provides, or other compatibility tags. So, when I have unstable satisfying deps prior to unstable, and things depend on both libdnet and libdnet-shlibs, unstable libdnet is found, which depends on libdnet1-shlibs, and the stable libdnet gets pulled in to satisfy libdnet-shlibs, but they conflict. I solved this little problem by having everything that depends on libdnet-shlibs, depend on libdnet1-shlibs | libdnet-shlibs. This probably isn't the right solution. Rob --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] dp/fink md5 mismatches
One of the fringe benefits of having a unified Fink/DarwinPorts distfile fetching system is a comparison of MD5's for files listed in both projects. The fetching script complains when there is a mismatch in what the desired MD5 of the distfile is. I've mentioned this on IRC from time to time, but no one seemed particularly concerned since usually this is a project maintainer doing something evil and either the Fink .info file or the DarwinPorts Portfile needs to be updated. However, I was talking with olegb on irc today, and we found Eterm had a mismatched MD5. Upon further investigation, Fink uses sourceforge as the sole source of the Eterm sources, but DP uses eterm.org, and then falls back to using sourceforge. Eterm.org is distributing a different tarball from what sourceforge distributes. This is a bad thing, and eterm.org has been notified of the discrepancy. Anyway, that's just an example of why checking up on these things is a good thing. Here is the list of current mismatched md5's: ERROR: X11R6.8.1-src3.tar.gz appeared more than once with different md5's ERROR: icecast-1.3.12.tar.gz appeared more than once with different md5's ERROR: mp3splt-2.0-src.tar.gz appeared more than once with different md5's ERROR: X11R6.8.1-src1.tar.gz appeared more than once with different md5's ERROR: fnlib-0.5.tar.gz appeared more than once with different md5's ERROR: X11R6.8.1-src6.tar.gz appeared more than once with different md5's ERROR: X11R6.8.1-src7.tar.gz appeared more than once with different md5's ERROR: X11R6.8.1-src5.tar.gz appeared more than once with different md5's ERROR: X11R6.8.1-src4.tar.gz appeared more than once with different md5's ERROR: X11R6.8.1-src2.tar.gz appeared more than once with different md5's ERROR: Eterm-0.9.2.tar.gz appeared more than once with different md5's ERROR: p4 appeared more than once with different md5's icecast and p4 (and possibly fnlib) have had mismatched md5's since this distfile script first started running (over a year ago?). I'm not sure who needs to update what, so I'm sending this to both the darwinports and fink mailing lists. Ideally, the respective maintainers will check up to make sure they are doing the right thing, whatever that may be. FYI, this information is available to anyone who wants it, although not in a nice form. The output of the distfiles mirroring script gets sent to [EMAIL PROTECTED] Anyone can subscribe, and the archives are available. Rob --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fink using apt-get
On Mon, Sep 06, 2004 at 04:31:33PM -0700, Rob Braun wrote: > > I've come up with a patch that does this. I've been testing the > patch locally, but have not tested it extensively. I'll test it with > larger dependency chains later, when I get access to better connectivity. > Known issues: it is not controllable by a switch (command line or > otherwise). The plan is to not have this on by default, but use > a switch of some sort to enable it. I'm open to suggestions on how > best to toggle this. Also, it does not run apt-get update from > fink index, so you'll need to do that seperately. It should update > apt-get's notion of reality. I just tested this on larger sets, and it fails miserably. I have some ideas on how to fix it though, so stay tuned. Any helpful comments/code would be appreciated. ;-) Rob --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fink using apt-get
On Mon, Sep 06, 2004 at 06:31:48PM -0600, TheSin wrote: > > so the description is true but the implementation isn't that difficult. > and using the download only option in apt-get will fix the problem in > your 2nd step/requirement. As you can see in the patch, that is what it does. Uses the download only option. And the requirement I put forth (guideline, really, but hey), in #2 was to not download anything that wasn't needed. apt-get in download or install mode will still download the same things. So, running apt-get in download only or in install mode doesn't really affect guideline #2. Rob --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] fink using apt-get
Something I have been toying with for a while now is fink being able
to use apt-get-able packages. Sometimes when building something large,
many of the dependency packages are already in a bindist somewhere, and
I'd rather not build each and every one, just the packages newer than
what is in the bindist. So, I thought about using apt-get to get the
ones that I could.
My requirements were:
1) Don't break what currently works. If a package can't be fetched
from apt-get, then fall back to building from scratch.
Also as a result of this requirement, fink's dependency engine must
be used instead of apt-get's. Fink also must perform all package
installations instead of apt-get.
2) Don't download things that won't be used to satisfy the request.
apt-get has its own dependency engine and it might not necissarily
agree with what fink wants to install. We don't want apt-get going
off and downloading everything, and then fink not using it later on.
As a result of these, this patch may end up not downloading things
that it might otherwise be able to. Part of the problem here is apt-get
does not allow downloading arbitrary files. It wants all dependencies
installed to satisfy the requirements of the file it is downloading,
even if its not actually going to install the file.
I've come up with a patch that does this. I've been testing the
patch locally, but have not tested it extensively. I'll test it with
larger dependency chains later, when I get access to better connectivity.
Known issues: it is not controllable by a switch (command line or
otherwise). The plan is to not have this on by default, but use
a switch of some sort to enable it. I'm open to suggestions on how
best to toggle this. Also, it does not run apt-get update from
fink index, so you'll need to do that seperately. It should update
apt-get's notion of reality.
Rob
diff -udr Fink.orig/Engine.pm Fink/Engine.pm
--- Fink.orig/Engine.pm Mon Sep 6 11:34:09 2004
+++ Fink/Engine.pm Mon Sep 6 11:41:26 2004
@@ -1382,6 +1382,20 @@
foreach $pkgname (sort keys %deps) {
$item = $deps{$pkgname};
next if $item->[OP] == $OP_INSTALL and $item->[PKGVER]->is_installed();
+ if (!$item->[PKGVER]->is_present() && $item->[OP] != $OP_REBUILD) {
+ my ($aptcmd, $pkgg, $package);
+ $package = $item->[PKGVER];
+ if (exists $package->{_relatives}) {
+ foreach $pkgg (@{$package->{_relatives}}){
+ if (!$pkgg->is_present() &&
$pkgg->is_aptgetable()) {
+ $pkgg->apt_fetch();
+ &real_install($OP_INSTALL, 0, 1,
$pkgg->get_name());
+ }
+ }
+ }
+ $item->[PKGVER]->apt_fetch();
+ }
+
if ($item->[OP] == $OP_REBUILD or not $item->[PKGVER]->is_present()) {
$item->[PKGVER]->phase_fetch(1, 0);
}
diff -udr Fink.orig/Package.pm Fink/Package.pm
--- Fink.orig/Package.pmMon Sep 6 11:34:09 2004
+++ Fink/Package.pm Mon Sep 6 16:15:08 2004
@@ -44,6 +44,7 @@
our $essential_valid = 0;
our $db_outdated = 1;
our $db_mtime = 0;
+our $aptdb = {};
END { }# module clean-up code here (global destructor)
@@ -221,6 +222,19 @@
return 0;
}
+### Find a specific package name/version in aptdb
+
+sub is_in_apt{
+ my $self = shift;
+ my $name = shift;
+ my $version = shift;
+
+ if (defined $aptdb->{$name}{$version}) {
+ return 1;
+ }
+ return 0;
+}
+
### get version object by exact name
sub get_version {
@@ -340,6 +354,7 @@
if (not $db_outdated) {
$packages =
Storable::retrieve("$basepath/var/db/fink.db");
}
+ $aptdb = Storable::retrieve("$basepath/var/db/finkapt.db");
}
}
@@ -407,6 +422,33 @@
? 1 : 0;
}
+### update the apt-get db file
+
+sub update_aptdb {
+ shift;
+
+ my ($pkg, $ver);
+ open(APTDUMP, "apt-cache dump |") || die "Can't run apt-cache dump: $!\n";
+ $aptdb = {};
+ while() {
+ if (grep(/Package:/,$_)) {
+ chomp;
+ $pkg = $_;
+ $pkg =~ s/.*Package:[\ ]*//;
+ }
+ if (grep(/Version:/,$_)) {
+ my $count;
+ chomp;
+ $ver = $_;
+ $ver =~ s/.*Version:[\ ]*//;
+ $aptdb->{$pkg}{$ver}++;
+ }
+ }
+ close APTDUMP;
+
+ Storable::lock_store($aptdb, "$basepath/var/db/finkapt.db");
+}
+
### read th
Re: [Fink-devel] problem with rsync - every file gets sucked every time
On Tue, Feb 24, 2004 at 12:13:40PM -0800, Randal L. Schwartz wrote: > > During "fink selfupdate-cvs", I'm seeing a series of 10.3/unstable/... > entries (scrolling by for a minute, probably a few hundred files) on > *EVERY SINGLE UPDATE*. Well, since I'm probably the one that made this change, I thought I'd jump in here. First, is it just printing the file name, updating only the timestamp, or copying over the whole file? Just because it prints the filename does not mean it is transfering the whole file. It just means that rsync flagged it for some kind of update. Identifying the update that rsync flagged it for would help in debugging. The change that is suspected of causing your grief is a change from using "rsync -a" to using "rsync -r". -a according to the man page is equivalent to -rlptgoD. To simplify, it recursivly transfers files files preserving links, ownership, group, permissions, devices, and timestamps. Most of those are not needed for the finkinfo files. As a test, could you modify your /sw/lib/perl/Fink/SelfUpdate.pm file so that instead of having an "rsync -rz" you have "rsync -rtz"? The timestamp flag is the only other one I can see affecting this. Thanks, Rob --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] kexts in fink
On Thu, Feb 12, 2004 at 06:05:54PM -0500, David R. Morrison wrote: > For the unloading issue, I believe that we should require any package which > has a kext to do the following: > 1) in a pre-remove script, have a dialog with the user in which the user > is told that an immediate reboot will occur if this package is removed, > and if the user says "no", the removal operation is cancelled > 2) in a post-remove script, (gently) force a reboot. I'm not really a fan of forced reboots in general, but I'd go along with it if that's what it'll take to get fink to allow kexts (particularly ones that can't unload). Letting the user know that the kext is still loaded and a reboot will be required to get rid of it should be good enough. It's kind of like deleting a file that someone could still have an open reference to. The only way to be sure there are no more references to the files you've just deleted would be to reboot. > As far as where to put it: does Apple have a recommended place (default > search path?) to install third-party kexts? /Library/Extensions, maybe? > If so, along the lines of earlier discussions, we should consider expanding > our rules to allow /sw/Library/Extensions as the location for kexts. There is no real recommendation. kexts that are not auto-loaded are loaded by explicit paths (or bundle relative paths). The only implicit paths when doing kext loading are those for resolving the kext's dependencies, and then only /S/L/E is used. Regardless of where fink put it's kexts, the loading process would need to specify the explicit path to the kext, as well as the fink location for kexts to resolve dependencies. So, the issue of kexts is somewhat decoupled from the issue of having %p/Library, %p/Frameworks, %p/Applications, etc. Except that we'll need *someplace* to put the kexts. For those that enjoy the old days, I'll throw %p/stand in there. ;-) Rob --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] kexts in fink
On Thu, Feb 12, 2004 at 10:05:33AM -0800, Rob Braun wrote: > > Apple has gotten really draconian about how kexts can be installed > on the system. I believe the kext actually has to be in /S/L/E, and > can't be a symlink. I'll need to test, but I'm pretty sure a symlink > won't suffice. I'll also go ask the kext folks how they would like > to see such a situation handled. After talking with some of the people that actually know something about kexts, I'm completely wrong here. kexts can be loaded from anywhere. They only need to be in /S/L/E if they are going to be "hot plugged", or automatically loaded when a device is inserted or some such. If this is not the case, it is recommended that kexts NOT be placed in /S/L/E. A case in point is the filesystem kexts. These are in /S/L/CoreServices/... So, we can install kexts in /sw/, and everything should be fine. The only other things that would need addressing would be 1) a startup item to load the kext, 2) if the kext supports unloading, unload it on package removal. And that seems like about it. If the kext is going into /sw, and not touching anything outside of there anymore, how much do we need the big flashy warnings about the package installation? Should there be a warning on package removal if the kext doesn't support unloading? Something saying "warning, the kext is still loaded and will be until you reboot"? Rob --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] kexts in fink
On Thu, Feb 12, 2004 at 11:05:13PM +0900, Peter O'Gorman wrote: > > 3) would not install anything in /System/Library/Extensions, but would > install somewhere in /sw and in a postinstscript add a symlink. This way a > user who does sudo rm -rf /sw would be left with a dangling symlink in > /System/Library/Extensions, but would not otherwise "damage" a users system. Apple has gotten really draconian about how kexts can be installed on the system. I believe the kext actually has to be in /S/L/E, and can't be a symlink. I'll need to test, but I'm pretty sure a symlink won't suffice. I'll also go ask the kext folks how they would like to see such a situation handled. Some people also raised concerns about the uninstall case of the kext. Many kexts have problems unloading, so doing a kextunload may (or may not) cause a kernel panic. For the short term, I think just having the kext removed would suffice (along with any appropriate user warnings). We could even rebuild the mkext cache for them after removing the kext, just to make sure it won't load on the next reboot. If there get to be a few kexts in fink, adding infrastructure to handle this case would probably be good. Having some way to let the package know whether to attempt an unload or not would be nice, but it's probably not worth going too far down that road until it's actually an issue. I'm fine with adding tons of user warnings and such. I never listen to those anyway. =) Requiring interaction (with the default to abort) would be fine as well. Debian has many instances of that. There's a lot of cases where the user needs to actually pay attention, and if they are just picking the defaults, it's safe to assume they aren't. Rob --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] "WARNING: Unable to parse ..." after upgrade
You're right, it probably should. What is currently in 0.17.1 should work with virtually all versions of rsync (as long as 'rsync' is really rsync). But, an explicit path is more reliable. Rob On Wed, Nov 19, 2003 at 10:35:20PM -0800, Ben Hines wrote: > Really fink should not be calling 'rsync'. It should be using > /usr/bin/rsync in any case, just like every single other external call > in fink does. I see no reason to deviate and trust whatever program a > user has that might be called rsync. > > -Ben --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unstable/crypto tree not updating with rsync
On Tue, Nov 18, 2003 at 07:44:24AM +0100, Christian Schaffner wrote: > Dear Fink Main Developers > > Um 20:05 Uhr -0800 am 17.11.2003, > [EMAIL PROTECTED] schrieb: > >From: Rob Braun <[EMAIL PROTECTED]> > >Subject: fink/perlmod/Fink ChangeLog,1.417,1.418 SelfUpdate.pm,1.55,1.56 > >Date: Mon, 17 Nov 2003 16:38:28 -0800 > > > >Update of /cvsroot/fink/fink/perlmod/Fink > >In directory sc8-pr-cvs1:/tmp/cvs-serv18496 > > > >Modified Files: > > ChangeLog SelfUpdate.pm > >Log Message: > >Fix an rsync problem with the crypto/ directory. > > Quite a few people reported this problem. Would it be possible to > release a bug fix to fink? Like 0.17.1? It appears it's coming: diff -u -d -r1.174.2.2 -r1.174.2.3 --- ChangeLog 16 Nov 2003 22:02:33 - 1.174.2.2 +++ ChangeLog 18 Nov 2003 16:32:41 - 1.174.2.3 @@ -1,3 +1,8 @@ +2003-11-18 Dave Morrison <[EMAIL PROTECTED]> + + * VERSION: Bumped package manager version to 0.17.1, a bugfix + release on branch_0_17 + Rob --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: A few issues with the new TIMESTAMP code in SelfUpdate.pm
On Wed, Nov 12, 2003 at 05:39:59PM +0100, Darian Lanx wrote:
>
> First of all, thank you for adding this Rob, but there are a few
> concerns I have.
>
> 537 # If there's no TIMESTAMP file, then we haven't synced
> from rsync
> 538 # before, so there's no checking we can do. Blaze on past.
> 539 if ( -f "$descdir/TIMESTAMP" ) {
> 540 open TS, "$descdir/TIMESTAMP";
> 541 $oldts = ;
> 542 close TS;
> 543 chomp $oldts;
>
> While this makes sense it introduces a logical problem. Because ideally
> the code would simply reject the mirror if there is no timestamp
> present. why? Well our policy states that the mirror may only sync the
> timestampt AFTER all of the info files were synced successfully. So if
> there is no TIMESTAMP, something has gone wrong on the mirror and we
> should not poll any data from it.
This part of the code is checking for the timestamp on the local machine,
not the server. If it doesn't exist on the local machine, it's probably
because we haven't run a version of fink that did the timestamp checking.
This isn't an indication of anything being wrong on the server side.
> Furthermore on:
>
> 609 $cmd = "rsync -az --delete-after $verbosity $nohfs $rinclist
> - --include='VERSION' --exclude='**' '$rsynchost' '$basepath/fink/'";
>
> and on
>
> 533 $timecmd = "rsync -az $verbosity $nohfs $rsynchost/TIMESTAMP
> $descdir/TIMESTAMP.tmp";
>
> While I do notice that the files are written into different locations,
> would it not be better to simply do:
>
> "rsync -az --delete-after $verbosity $nohfs $rinclist
> - --include='VERSION' --INCLUDE='TIMESTAMP' --exclude='**' '$rsynchost'
> '$basepath/fink/'";
>
> While that might not be the actual command or line it is at, my point
> is. Even if we do not decide to use the mirror we pulled the TIMESTAMP
> and VERSION file from, we do safe us a system() call and a rsync
> connect. To unlink the VERSION should be drop that mirror because of
> TIMESTAMP issues should not be time consuming.
No, this can't be done in one rsync. The problem is this:
If we pull down the timestamp file with everything else, then do the
compare, we may have just trashed our .info files. We need to pull
down the timestamp first, compare, decide if it's safe to pull down
the .info files, then do it. I've been trying to think of a way to
do it in a single rsync that 1) doesn't pull down the entire tree
more often than it needs to, and 2) doesn't trash your files. I just
haven't come up with a way yet.
Doing this in a single rsync is preferable not just for speed reasons,
but it enables a whole host of other possibilities.
> And just a question:
>
> 561 # error out complaining that we're trying
> to update
> 562 # from something older than what we
> already have.
> 563 unlink("$descdir/TIMESTAMP.tmp");
> 564 print "The timestamp of the server is
> older than what you already have.\n";
> 565 exit 1;
> 566 }
> 567
> 568 }
>
> once that is executed, does it throw the user back into the "choose
> another mirror" routine or does the user have to type fink selfupdate
> again ?
As you will see, there is currently no mirroring support at all in
the rsync code. So, no, this doesn't throw the user into a choose
another mirror routine. It simply exits.
However, I am about to commit a bunch of code that does enable
mirroring for the rsync updates. Please be patient.
> My idea is, that there is some function like &get_next_mirror_from_group();
>
> That way the logical flow is as follows:
>
> Look up in fink.conf what is set e,g, eur-DE
>
> look what is in eur-DE pick the first mirror.
> check if the mirror fails
> if so, pick next until the end of the mirror list is reached or success.
> once the end of eur-DE is reached without success
>
> dump the user into
> "Which mirror would oyu like to use all your countries mirrors failed"
I have done my best to have the rsync mirroring code use the
same system as the distfiles. I don't see much point in duplicating
a site mirroring system for each transport mechanism. Once that is
in, you can start discussing any changes you would like to make to the
fink mirroring code in general terms. It should be there soon.
Rob
---
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
___
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: setsid error message
It appears that xdvi is trying to call setsid() after vfork(). Just about the only valid thing to do after vfork() is exec(). I'll bet this is your problem. You may try examining xdvi's usage of setsid() after the vfork(). However, it looks like the parent is simply exiting after the vfork. In that case, you can change the vfork to a fork, and all will be well. Rob On Fri, Nov 07, 2003 at 10:53:07AM +0800, [EMAIL PROTECTED] wrote: > Yes, I can read the setsid manpage, too, but it doesn't provide much > edification as to precisely why mktexpk fails with that message when > run from xdvi, but when run from the command line with the same arguments > seems to work perfectly. In fact, I'm not actually convinced that > mktexpk is being called at all. > > I have put a copy of the decoded ktrace on the web at > > http://www.rattus.net/~packrat/software/files/xdvi.trace.gz(360kb) > > with the trace all decendants flags on so that the location of the > setsid stuff is visible. > > The relevant parts are of the following form: > > 11520 xdvi.xdvi GIO fd 1 wrote 79 bytes >"- mktexpk --mfmode ljfour --bdpi 600 --mag 'magstep(0)' --dpi 600 cmmi\ > 10 '>&3' >" > 11520 xdvi.xdvi RET write 79/0x4f > 11520 xdvi.xdvi CALL vfork > 11521 xdvi.xdvi RET vfork 11521/0x2d01 > 11521 xdvi.xdvi CALL close(0x6) > 11521 xdvi.xdvi RET close 0 > 11521 xdvi.xdvi CALL dup2(0x7,0x3) > 11521 xdvi.xdvi RET dup2 3 > 11521 xdvi.xdvi CALL close(0x7) > 11521 xdvi.xdvi RET close 0 > 11521 xdvi.xdvi CALL setsid > 11521 xdvi.xdvi RET setsid -1 errno 1 Operation not permitted > 11521 xdvi.xdvi CALL writev(0x2,0xb350,0x4) > 11521 xdvi.xdvi GIO fd 2 wrote 32 bytes >"setsid: Operation not permitted >" > 11521 xdvi.xdvi RET writev 32/0x20 > 11521 xdvi.xdvi CALL exit(0x1) > 11520 xdvi.xdvi RET vfork 11521/0x2d01 > 11520 xdvi.xdvi PSIG SIGCHLD caught handler=0xa2e4 mask=0x0 code=0x0 > > > What precisely was the function of the setsid call in xdvi and why > is xdvi being killed by a return code which is (from the point of view > of setsid) hardly fatal? > > B> > -- > Packrat (BSc/BE;COSO;Wombat Implementor) > Nihil illegitemi carborvndvm. > > > > --- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > ___ > Fink-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/fink-devel --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gimp mirrors , 9/49
On Sat, May 31, 2003 at 11:54:22AM -0700, Ben Hines wrote: > > It is supposed to be updated nightly, actually. If it didn't update for > 10 days it is probably just a kink in the new system. Anyway, last > updated today, now. I was actually in hawaii for the last week and something went wrong while I was gone. The automated updating should be better now. Rob --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
