You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(14) |
Dec
|
From: Sturle S. <stu...@us...> - 2004-11-25 09:25:54
|
Did we get to a conclusion about this? Is Store going to use the generic term, or a vendor specific one? Here is a another good discussion of the issue: http://kerneltrap.org/node/view/2466 Another solution, perhaps better, would be to expand the architecture to contain a "bitness" value. Like i386-64 as a 64 bit expansion to i386, and i.e. sun4u-64 as a 64 bit expansion to sun4u. -- Sturle ~~~~~~ |
From: Petter R. <pe...@hu...> - 2004-11-24 16:32:55
|
The recent years, more and more source packages started to support DESTDIR during installation, to install the files in a different location than their final resting place. The build-all script in CVS didn't support this. It only supported directinstall, which changed prefix during installation instead of keeping prefix and only adding an extra path. I got tired of the lack of DESTDIR support in build-all a few days ago, and implemented it. I had to hack around the fact that the toplevel prefix have to be ignored during installation, to avoid files ending up in ver-X/local/. I solved this by adding a symlink local->. before 'make install', and removing it after the install. The following patch is now in CVS. Should we drop support for directinstall? I believe it is a waste of code. Index: lib/buildsubs =================================================================== RCS file: /cvsroot/storeadm/buildall/lib/buildsubs,v retrieving revision 1.32 retrieving revision 1.36 diff -u -3 -p -u -r1.32 -r1.36 --- lib/buildsubs 13 Jun 2003 16:47:49 -0000 1.32 +++ lib/buildsubs 22 Nov 2004 14:20:00 -0000 1.36 @@ -1,5 +1,5 @@ # -# $Id: buildsubs,v 1.32 2003/06/13 16:47:49 pere Exp $ +# $Id: buildsubs,v 1.36 2004/11/22 14:20:00 pere Exp $ # # Simple build routines. Construct a wrapper script which sources @@ -34,6 +34,7 @@ # unitedalgoritm=y if you want to test the united do_master and do_slave # removecompiledirfirst=y if you want to remove compiledir before shadowing # directinstall=(if set, install directly into version tree using prefix) +# destdirinstall=(if set, install directly into version tree using DESTDIR) # hostdir=$HOME/lib @@ -203,6 +204,13 @@ do_master () { postinstprefix="-p $directinstall" targets="prefix=$directinstall $targets" fi + if [ "$destdirinstall" ]; then + destdirinstall="$topdir/store/$masterstore/$appname/ver-$version" + postinstprefix="-p $destdirinstall" + targets="DESTDIR=$destdirinstall $targets" + # Add symlink to work around prefix=/local + ln -s . $destdirinstall/local + fi if [ "$buildtype" = "pm" ]; then cmd="rm -f $topdir/lib/perl5/$PMA/$curperlvers/perllocal.pod" @@ -212,6 +220,10 @@ do_master () { installcmd="$cmd" fi (set -x; eval SARCH=$masterarch GNUARCH=$GNUARCH EXTRA=$extraparam $installcmd $targets) + + if [ "$destdirinstall" ]; then + rm $destdirinstall/local + fi fi echo ...running postinst @@ -376,6 +388,13 @@ do_slave () { postinstprefix="-p $directinstall" targets="prefix=$directinstall $targets" fi + if [ "$destdirinstall" ]; then + destdirinstall="$topdir/store/$slavestore/$appname-c/ver-$version" + postinstprefix="-p $destdirinstall" + targets="DESTDIR=$destdirinstall $targets" + # Add symlink to work around prefix=/local + $rsh -n $slavehost "$bashinit; ln -s . $destdirinstall/local" + fi if [ "$buildtype" = "pm" ]; then cmd="rm -f $topdir/lib/perl5/$PMA/$curperlvers/perllocal.pod" @@ -388,6 +407,10 @@ do_slave () { $rsh -n $slavehost "$bashinit; cd $compiledir; \ export SARCH=$slavearch; export GNUARCH=$GNUARCH; \ export EXTRA=$extraparam; $installcmd $targets" + + if [ "$destdirinstall" ]; then + $rsh -n $slavehost "$bashinit; rm $destdirinstall/local" + fi fi echo ...running postinst @@ -587,6 +610,13 @@ do_store () { postinstprefix="-p $directinstall" targets="prefix=$directinstall $targets" fi + if [ "$destdirinstall" ]; then + destdirinstall="$topdir/store/$mystore/$myappname/ver-$version" + postinstprefix="-p $destdirinstall" + targets="DESTDIR=$destdirinstall $targets" + # Add symlink to work around prefix=/local + $myrsh "$bashinit; ln -s . $destdirinstall/local" + fi if [ "$buildtype" = "pm" ]; then cmd="rm -f $topdir/lib/perl5/$PMA/$curperlvers/perllocal.pod" @@ -598,6 +628,10 @@ do_store () { $myrsh "$bashinit; cd $compiledir; \ export SARCH=$myarch; export GNUARCH=$GNUARCH; export EXTRA=$extraparam; $installcmd $targets" + + if [ "$destdirinstall" ]; then + $myrsh "$bashinit; rm $destdirinstall/local" + fi fi echo ...running postinst |
From: Sturle S. <stu...@us...> - 2004-11-12 13:07:21
|
Per Kristian Hove <per...@ma...> writes: > [Sturle Sunde, 2004-11-11] > > | AMD called the architecture x86-64 when they first documented it > | (which is the documentation Intel used to implement their version), > | but called their own implementation AMD64 when it was released. > > That's a good point. > > I had the impression that it wasn't only AMD's implementation that was > called AMD64, but that they had renamed the architecture (that's what > the amd.com website makes me believe). At http://www.x86-64.org/ (the official site for x86-64/AMD64) they still use both names. Under Documentation you'll find "Gentle Introduction to x86-64 Assembly" and "AMD64 Application Binary Interface". Under news they sometimes refer to it as x86_64, sometimes to AMD64, and they didn't stop using x86_64 after they started using AMD64. So I can't tell if they renamed the whole architecture or their own implemetation of the architecture. Fedora (RedHat) writes that their x86_64 version is "For x86_64 (64-bit AMD64, EM64T)." If AMD stops refering to it as x86-64, that would be even better. Then x86_64 would be completely independent of vendor. > If EM64T and AMD64 are two different implementations of an > architecture named x86-64, and they're compatible enough that OSes > only come in one version for these two CPUs, it would make sense to > use another (common) name instead of amd64. They are compatible enough (Intel just used an earlier specification), and rumours say Intel will make the next version of their EM64T to the new specification. (Except for extensions like 3DNow!, of course.) > But "x86-64" and "x86_64" are both a little clumsy, and they're still > AMD's (previous) name for this architecture (did Intel ever call its > "amd64 version" for x86-64? No I'm sure Intel wouldn't mention any name AMD is or have been using. > | I lost you there. Why should we name a GNU/Linux architecture > | after a BSD naming scheme, and not what GNU/Linux already use? > > I meant we're naming a hardware architecture (subarch of litend), > not just a GNU/Linux architecture. What makes GNU/Linux so special > in this picture? FreeBSD, Solaris, NetBSD (and possibly others) will > be subarchs of this architecture equal to GNU/Linux. How many machines in the world would run NetBSD on x86_64 for the next ten years or so, vs GNU/Linux or Solaris? GNU/Linux is special and more important because it is the most common platform. Btw, Solaris on x86_64 (or AMD64) reports i386 as architecture. Only isainfo will reveal that the OS and CPU is capable of running 64 bit binaries. Just like Solaris on UltraSparc. > What GNU/Linux uses is of no greater significance than what > e.g. Solaris or the BSDs use. (I said this assuming we wouldn't > have to separate between AMD's and Intel's implementation in > genarchs). > > On the other side, it's not like we're 100% consistent today. On > IA-32, solaris uses "i386" (i386sol2, etc.) and everybody else uses > "386" (386freebsd etc.). Of course we could have I have wondered about that.. Why not i386 on all, or at least where uname reports it? -- Sturle We know that dictators are quick to choose aggression, ~~~~~~ while free nations strive to resolve differences in peace -- George W. Bush |
From: Per K. H. <per...@ma...> - 2004-11-11 19:49:26
|
[Sturle Sunde, 2004-11-11] | AMD called the architecture x86-64 when they first documented it | (which is the documentation Intel used to implement their version), | but called their own implementation AMD64 when it was released. That's a good point. I had the impression that it wasn't only AMD's implementation that was called AMD64, but that they had renamed the architecture (that's what the amd.com website makes me believe). If EM64T and AMD64 are two different implementations of an architecture named x86-64, and they're compatible enough that OSes only come in one version for these two CPUs, it would make sense to use another (common) name instead of amd64. But "x86-64" and "x86_64" are both a little clumsy, and they're still AMD's (previous) name for this architecture (did Intel ever call its "amd64 version" for x86-64? I thought Intel's old name for this architecture was IA-32e), so I'm not sure that even "x86-64" would be the correct name in that case, even though it's the Linux name for the port that runs on both amd64 and em64t. But you obviously know a lot more about the details in this than I do, so please correct me if I'm wrong. | > As for differentiating between incompatible extensions, I see your | > point, but I'm not sure if we need to do this in Store. | | Probably not now, but this may change in the future. I'm not sure we can do this in a decent way in Store. If they're compatible enough that OSes only come in one version for both of them (i.e. we don't want to take it all the way to "litend: pmax i386 vax alpha amd64 em64t"), they should be of the same storearch. And if they're not compatible, they should be separate (as should Intel PIII and AMD K7 then, but what we do today works better in Store). Hardware architecture, OS name and e.g. libc version are all orthogonal, and we can only code a limited number of combinations of these into the genarchs tree. | I lost you there. Why should we name a GNU/Linux architecture | after a BSD naming scheme, and not what GNU/Linux already use? I meant we're naming a hardware architecture (subarch of litend), not just a GNU/Linux architecture. What makes GNU/Linux so special in this picture? FreeBSD, Solaris, NetBSD (and possibly others) will be subarchs of this architecture equal to GNU/Linux. What GNU/Linux uses is of no greater significance than what e.g. Solaris or the BSDs use. (I said this assuming we wouldn't have to separate between AMD's and Intel's implementation in genarchs). On the other side, it's not like we're 100% consistent today. On IA-32, solaris uses "i386" (i386sol2, etc.) and everybody else uses "386" (386freebsd etc.). Of course we could have =09litend: "amd64&em64t" (or whatever) =09"amd64&em64t": amd64freebsd amd64solaris amd64netbsd x86-64linux Was this what you meant, or did I misunderstand? --=20 Per Kristian Hove <Per...@ma...> Overing. Institutt for matematiske fag http://www.math.ntnu.no/~perhov/ NTNU Gl=F8shaugen, Trondheim tel://73550234/ fax://73593524/ |
From: Sturle S. <stu...@us...> - 2004-11-11 14:22:35
|
Per Kristian Hove <per...@ma...> writes: > [Sturle Sunde, 2004-11-11] > | *Bomb* No, wait... And Intel calls it EM64T. So what? > If AMD invented it, it would be reasonable that they get to name it > even though Intel has copied it under a different name. AMD called the architecture x86-64 when they first documented it (which is the documentation Intel used to implement their version), but called their own implementation AMD64 when it was released. Probably following a discussion with the marketing department. AMD64 is the implementation specific name, x86-64 is the generic name. GNU use x86_64 as architecture because the hyphen is used as a separator between architecture and the rest. Debian couldn't use x86_64 because _ is used as a separator in package file names, and chose amd64. (Ref: http://lists.debian.org/debian-ctte/2004/06/msg00115.html) RedHat, Fedora and SuSE use x86_64. > I don't know the details, but I thought EM64T was Intel's > implementation of the AMD64 architecture, which Intel copied because > of its success (and Itanium's lack of success). This is correct except that Intel implemented x86-64 according to an early specification by AMD. (AMD changed the specification a little after Intel started their implementation, which is the reason why there are a few subtle differences between the two implementations.) Intel called their implementation IA-32e first, but changed the name to EM64T. > As for differentiating between incompatible extensions, I see your > point, but I'm not sure if we need to do this in Store. Probably not now, but this may change in the future. > the need arise. Until then, I'm still with the BSDs on this one. I lost you there. Why should we name a GNU/Linux architecture after a BSD naming scheme, and not what GNU/Linux already use? -- Sturle We know that dictators are quick to choose aggression, ~~~~~~ while free nations strive to resolve differences in peace -- George W. Bush |
From: Per K. H. <per...@ma...> - 2004-11-11 13:25:53
|
[Sturle Sunde, 2004-11-11] | *Bomb* No, wait... And Intel calls it EM64T. So what? If AMD invented it, it would be reasonable that they get to name it even though Intel has copied it under a different name. I don't know the details, but I thought EM64T was Intel's implementation of the AMD64 architecture, which Intel copied because of its success (and Itanium's lack of success). As for differentiating between incompatible extensions, I see your point, but I'm not sure if we need to do this in Store. We've run Cyrix and AMD "x86"-cpus using 386freebsd etc. without needing a separate storearch for them. i486linuxelf/i586linuxelf/i686linuxelf were added to the genarchs file in 1996 because of this, but I don't think these were ever used. But we can always do something similar for amd64/em64t, should the need arise. Until then, I'm still with the BSDs on this one. --=20 Per Kristian Hove <Per...@ma...> Overing. Institutt for matematiske fag http://www.math.ntnu.no/~perhov/ NTNU Gl=F8shaugen, Trondheim tel://73550234/ fax://73593524/ |
From: Stian <sti...@nt...> - 2004-11-11 13:13:55
|
On 2004-11-11 12:38:55, Petter Reinholdtsen wrote: > A quick search on google give me 2.54 mill hits on amd64, 2.23 mill > hits on x86_64 and 0.523 mill hits on x86-64. Mandrake seem to call > the architecture x86-64, while RedHat calls it x86_64. Debian, > OpenBSD and SuSe calls it amd64. I think "amd64" is "the old name". SuSE has switched: : stain@shrek ~;cat /etc/SuSE-release SuSE Linux 9.1 (x86-64) VERSION =3D 9.1 I think we can conclude that the whole thing is a mess =3D)=20 (let's not get started with how to mess up things even more with having dual-32bit-64bit libaries installed) --=20 Stian S=F8iland ITEA systemdrift, NTNU or...@nt... Tlf: 735 91500 =3D/\=3D |
From: Petter R. <pe...@hu...> - 2004-11-11 11:39:16
|
[Per Kristian Hove] > AMD calls it amd64. The BSDs have gotten this right, I don't know > what's up with Linux:-). A quick search on google give me 2.54 mill hits on amd64, 2.23 mill hits on x86_64 and 0.523 mill hits on x86-64. Mandrake seem to call the architecture x86-64, while RedHat calls it x86_64. Debian, OpenBSD and SuSe calls it amd64. I believe it is wise to avoid a name with - and _, as it confuses some systems. Because of this, I prefer amd64 among the three proposed alternatives. |
From: Sturle S. <stu...@us...> - 2004-11-11 11:26:17
|
Per Kristian Hove <per...@ma...> writes: > [Petter Reinholdtsen, 2004-11-10] > | As far as I know, the linux distributions and software modules call > | it different things. :( > AMD calls it amd64. *Bomb* No, wait... And Intel calls it EM64T. So what? > The BSDs have gotten this right, I don't know what's up with > Linux:-). Since then at least one more popular CPU vendor which ship CPUs with an identical instruction set called EM64T, I'm not sure that BSD got this right. They might have got it wrong for historical reasons. It is certainly not right anymore. AMD64 makes sense when AMD extensions like 3DNow! are used. EM64T makes sense if Intel extensions like SSE3 are used. When using only compatible instructions, x86_64 makes the most sense. Othewise, how do you specify which, if any, incompatible extensions are used? -- Sturle We know that dictators are quick to choose aggression, ~~~~~~ while free nations strive to resolve differences in peace -- George W. Bush |
From: Petter R. <pe...@hu...> - 2004-11-11 10:57:25
|
[Per Kristian Hove] > AMD calls it amd64. The BSDs have gotten this right, I don't know > what's up with Linux:-). Well, I don't care, as long as we agree on one name for it. :) > On stash.ntnu.no however, linux is a subarch of i386. I don't know > anything about the CVS stuff. You should probably be listed as a project member on Sourceforge. the CVS is available from <URL: http://sourceforge.net/projects/storeadm/ >. I'll add linux as a subarch of i386 in CVS, to fix that problem too. > Looks fine. I'll add the same thing to genarchs on stash.ntnu.no if > noone else comes up with a better suggestion. I've commited the change. |
From: Per K. H. <per...@ma...> - 2004-11-11 10:47:33
|
[Petter Reinholdtsen, 2004-11-10] | As far as I know, the linux distributions and software modules call | it different things. :( AMD calls it amd64. The BSDs have gotten this right, I don't know what's up with Linux:-). | Fine with me. So amd64 should be a subarch of litend, or | standalone as 'linux' is at the moment? | | (Hm, is this a bug in genarchs? i386 is a subarch of litend, but | linux is not a subarch of i386). If so, Linux is obviously the oddball in this picture:-). On stash.ntnu.no however, linux is a subarch of i386. I don't know anything about the CVS stuff. | I think I will use this: | | expand arch litend pmax i386 amd64 vax alpha | expand arch amd64 amd64linux amd64freebsd | | OK to commit to CVS? Looks fine. I'll add the same thing to genarchs on stash.ntnu.no if noone else comes up with a better suggestion. Does anybody have any opinions on the name for Solaris 10 on amd64? On i386 we use "sol2" and on sun4 "os5". The Solaris 2.x days are over, so what about =09amd64=09=09amd64linux amd64freebsd amd64sol =09amd64sol=09amd64sol10 [amd64sol11 ...] or is =09amd64=09=09amd64linux amd64freebsd amd64solaris =09amd64solaris=09amd64solaris10 [amd64solaris11 ...] better? A little longer to type though, but I think I'd prefer the last one. --=20 Per Kristian Hove <Per...@ma...> Overing. Institutt for matematiske fag http://www.math.ntnu.no/~perhov/ NTNU Gl=F8shaugen, Trondheim tel://73550234/ fax://73593524/ |
From: Petter R. <pe...@hu...> - 2004-11-10 14:54:59
|
[Per Kristian Hove] > As far as I know, the architecture of the Opteron CPU is called > amd64 (and amd64 was previously known as x86-64). As far as I know, the linux distributions and software modules call it different things. :( > I'd suggest using > > amd64freebsd5 > amd64netbsd > amd64linux{,whatever} > > etc. as store archs. Fine with me. So amd64 should be a subarch of litend, or standalone as 'linux' is at the moment? (Hm, is this a bug in genarchs? i386 is a subarch of litend, but linux is not a subarch of i386). >> Should it be a subarch of 386linuxlibc6 or not? > > I don't have a strong opinion on this, but I'd guess "no". OK, lets make it separate for now. > amd64 -> amd64linux amd64freebsd amd64netbsd > amd64linux -> amd64linuxlibc6 > amd64freebsd -> amd64freebsd5 amd64freebsd6 I think I will use this: expand arch litend pmax i386 amd64 vax alpha expand arch amd64 amd64linux amd64freebsd OK to commit to CVS? |
From: Per K. H. <per...@ma...> - 2004-11-10 14:10:12
|
[Petter Reinholdtsen, 2004-11-10] | Which architecture name should I use for Opteron? Several names | are used for this arch already: amd64, x86_64 and x86-64. As far as I know, the architecture of the Opteron CPU is called amd64 (and amd64 was previously known as x86-64). I'd suggest using amd64freebsd5 amd64netbsd amd64linux{,whatever} etc. as store archs. | Should it be a subarch of 386linuxlibc6 or not? I don't have a strong opinion on this, but I'd guess "no". In the past, we've tried to keep the genarchs file architecturally and OS-wise sane (i.e. not binary compatible-wise), and solved problems like this one by hardlinking. 386freebsd4 can also run 386linuxlibc6 binaries, but it is not a subarch of 386linuxlibc6 (nor should it be, as it can also run 386linuxlibc5 binaries). By this reasoning, we should separate i386 and amd64 and have: =09386 -> 386linux 386freebsd =09386linux -> 386linuxlibc6 =09386freebsd -> 386freebsd4 386freebsd5 386freebsd6 =09amd64 -> amd64linux amd64freebsd amd64netbsd =09amd64linux -> amd64linuxlibc6 =09amd64freebsd -> amd64freebsd5 amd64freebsd6 etc., instead of: =09386 -> 386linux 386freebsd 386netbsd =09386linux -> 386linuxlibc5 386linuxlibc6 =09386linuxlibc6 -> amd64linux =09386freebsd -> 386freebsd4 386freebsd5 386freebsd6 =09386freebsd5 -> amd64freebsd5 =09386freebsd6 -> amd64freebsd6 (that is, not have the amd64 cpu spread around the genarchs tree in suitable places depending on OS). However, if we were to separate between SPARC and UltraSPARC binaries, it would make sense to have "sparcv9-solaris" as a subarch of "sparc-solaris". So the most correct way to do this probably depends on how similar amd64 is to 386 (or rather, the second most correct way, as the _most_ correct way would be to change Store's ideas of what an architecture is). Currently, the store architectures are represented in a tree structure. In order to express which architectures can run which binaries, we'd need the store architecture to be a non-cyclic directed graph. I don't think anyone is ever going to fix Store in that respect, however. --=20 Per Kristian Hove <Per...@ma...> Overing. Institutt for matematiske fag http://www.math.ntnu.no/~perhov/ NTNU Gl=F8shaugen, Trondheim tel://73550234/ fax://73593524/ |
From: Petter R. <pe...@hu...> - 2004-11-10 13:04:35
|
Which architecture name should I use for Opteron? Several names are used for this arch already: amd64, x86_64 and x86-64. Should it be a subarch of 386linuxlibc6 or not? |
From: Petter R. <pe...@hu...> - 2003-08-28 09:19:13
|
[Petter Reinholdtsen] > OK, I got no reply to this, so I will try to fix it myself. I'll > add two fields in the summary file, user name and group name. I > want to use the name instead of the uid to make it possible to have > different system uids on different hosts. I gave up trying to use the user name. It would give surprising results if the summary file is missing, and it is probably good enough to require uid/gid synchronization across a Store installation. > I'm not sure how to do this, so good suggestions are welcome. The changes are now in CVS, and I'm doing large scale testing now to make sure no surprises left. :) |
From: Petter R. <pet...@us...> - 2003-08-27 11:38:56
|
[Petter Reinholdtsen] > Do anyone know why STORE work like this? Should it be changed? I > believe it should. OK, I got no reply to this, so I will try to fix it myself. I'll add two fields in the summary file, user name and group name. I want to use the name instead of the uid to make it possible to have different system uids on different hosts. Any objections? I'm not sure how to do this, so good suggestions are welcome. |
From: Petter R. <pe...@hu...> - 2003-08-14 16:16:35
|
Recently we ran into a problem with cslave not reporting the need to run chown. The problem is that incorrect owner on the file is ignored as long as the file mode is correct. This make it hard to track down the slave stores with incorrect uid/gid on the files. Here is an example: The file on the master: -rwsr-xr-x 1 root root 531703 Jun 5 21:25 sbin/exim@386linuxlibc62 The file on the slave -rwsr-xr-x 1 store store 531703 Jun 5 21:25 sbin/exim@386linuxlibc62 When I run slaveapp for this package, there is no message about the need to change the owner/group to root: Which slavestore [sanfrancisco] ? Which application [.exim] ? (Trace) <exim@sanfrancisco> Running for application (Trace) <exim@sanfrancisco> New-style-metrics findmaster (Trace) (findmaster) <exim@sanfrancisco> Will mostly try 'storeslem' first (Trace) (findmaster) <exim@sanfrancisco> Considering storeslem (Trace) Using master storeslem (Trace) <exim@storeslem v4.12> slaving to sanfrancisco... (Trace) <.exim@sanfrancisco v4.12> slave OK. The reason is simply that the owner and group is ignored in lib/slaveit.pl when it is decided if the file need to be updated. If I remove the suid bit, the correct message is displayed: Which slavestore [sanfrancisco] ? Which application [.exim] ? (Trace) <exim@sanfrancisco> Running for application (Trace) <exim@sanfrancisco> New-style-metrics findmaster (Trace) (findmaster) <exim@sanfrancisco> Will mostly try 'storeslem' first (Trace) (findmaster) <exim@sanfrancisco> Considering storeslem (Trace) Using master storeslem (Trace) <exim@storeslem v4.12> slaving to sanfrancisco... (Trace) <exim@storeslem v4.12> slaving to sanfrancisco... (Error) (SuidFiles) Need to set correct set-uid/gid for file: orig /local/store/storeslem/exim/ver-4.12/sbin/exim@386linuxlibc62 was mode 4755, uid 0, gid 0 chown 0 /local/store/sanfrancisco/.exim/ver-4.12/sbin/exim@386linuxlibc62 chgrp 0 /local/store/sanfrancisco/.exim/ver-4.12/sbin/exim@386linuxlibc62 chmod 4755 /local/store/sanfrancisco/.exim/ver-4.12/sbin/exim@386linuxlibc62 (Info) <exim@storeslem v4.12> Differences on slave sanfrancisco: sbin ==> exim@386linuxlibc62 (Trace) <.exim@sanfrancisco v4.12> linking into sanfrancisco (Trace) <.exim@sanfrancisco v4.12> Finding files for sanfrancisco (Trace) done (17 files / 0 seconds). Now checking each ... (Trace) (linkup) <.exim@sanfrancisco v4.12> done The uid/gid info is also missing from the summary file, so it is not too easy to add support for this either. Do anyone know why STORE work like this? Should it be changed? I believe it should. |
From: Petter R. <pe...@hu...> - 2002-09-23 14:38:05
|
I've made a new mailing list storeadm-commits where all the changes to CVS is logged. You should subscribe if you want to keep track of the development. <URL:https://lists.sourceforge.net/lists/listinfo/storeadm-commits> |