From dgregor at redhat.com Mon Apr 4 05:10:06 2005 From: dgregor at redhat.com (Dennis Gregorovic) Date: Mon, 04 Apr 2005 01:10:06 -0400 Subject: new mach+yum pkgs In-Reply-To: <1111395434.16997.74.camel@cutter> References: <1111394886.16997.70.camel@cutter> <20050321085236.GA7164@dudweiler.stuttgart.redhat.com> <1111395434.16997.74.camel@cutter> Message-ID: <1112591406.28541.29.camel@dhcp83-103.boston.redhat.com> On Mon, 2005-03-21 at 03:57 -0500, seth vidal wrote: > On Mon, 2005-03-21 at 09:52 +0100, Florian La Roche wrote: > > > At this point I'll probably check the code in as 'extras-buildsys-temp' > > > or something equally as obviously named. Can anyone here tell me if I > > > can even make new modules in /cvs/fedora? > > > > We should include this into Fedora Extras as rpm as well to get more > > people using it. > > we need to make a decision about separation or integration with upstream > mach cvs, esp wrt mach3. > > if we're not going to merge back to mach2 head (which notably could take > a lot of work b/c I've not focused on making that easy with these > patches) I'd rather rename this something innocuous so we don't annoy > thomas with bugs from this version. > > -sv > I finally got a chance to install and play around with the extras- buildsys-temp code. There were a couple hiccups, but it didn't take too long before I could start building packages. I hope to be able to pitch in and help out some with the upcoming build system work. I have a couple questions. First, are other people running into the "Bad owner/group" error when running mach with a uid != 500? http://sourceforge.net/mailarchive/forum.php? thread_id=4173173&forum_id=35925 describes the issue more. I got around it by creating a dummy user with uid equal to 500, but I'm wondering if I should try to get a real fix in upstream. That brings me to my next question: are there any more thoughts on the separation of integration of the hacked version of mach with the upstream version? Cheers -- Dennis From skvidal at phy.duke.edu Tue Apr 5 04:22:14 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 05 Apr 2005 00:22:14 -0400 Subject: new mach+yum pkgs In-Reply-To: <1112591406.28541.29.camel@dhcp83-103.boston.redhat.com> References: <1111394886.16997.70.camel@cutter> <20050321085236.GA7164@dudweiler.stuttgart.redhat.com> <1111395434.16997.74.camel@cutter> <1112591406.28541.29.camel@dhcp83-103.boston.redhat.com> Message-ID: <1112674934.6556.30.camel@cutter> > I finally got a chance to install and play around with the extras- > buildsys-temp code. There were a couple hiccups, but it didn't take too > long before I could start building packages. I hope to be able to pitch > in and help out some with the upcoming build system work. As soon as I finish off a couple more bits i'm going to check in my first shot at the automation mechanisms that we discussed last week. It's not beautiful but it should help use churn out packages faster and give us a place to work from. -sv From ville.skytta at iki.fi Sun Apr 10 07:30:12 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 10 Apr 2005 10:30:12 +0300 Subject: devpts in mach buildroots Message-ID: <1113118212.5228.157.camel@bobcat.mine.nu> perl-IPC-Run from Extras devel CVS fails its test suite when built with mach. It needs pseudo tty's and the mach chroot doesn't have devpts mounted, /dev/ptmx alone is not enough. The attached quick and dirty patch adds devpts mounting to mach buildroots. perl-IPC-Run builds fine here with it applied. What do you think, would this be an useful/acceptable addition to mach? -------------- next part -------------- A non-text attachment was scrubbed... Name: mach-devpts.patch Type: text/x-patch Size: 3163 bytes Desc: not available URL: From wtogami at redhat.com Sun Apr 10 19:23:18 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 10 Apr 2005 09:23:18 -1000 Subject: devpts in mach buildroots In-Reply-To: <1113118212.5228.157.camel@bobcat.mine.nu> References: <1113118212.5228.157.camel@bobcat.mine.nu> Message-ID: <42597D26.2020003@redhat.com> Ville Skytt? wrote: > perl-IPC-Run from Extras devel CVS fails its test suite when built with > mach. It needs pseudo tty's and the mach chroot doesn't have devpts > mounted, /dev/ptmx alone is not enough. > > The attached quick and dirty patch adds devpts mounting to mach > buildroots. perl-IPC-Run builds fine here with it applied. > > What do you think, would this be an useful/acceptable addition to mach? > Just go ahead and commit. Don't forget to bump the release or version or something too. Warren From ville.skytta at iki.fi Mon Apr 11 16:58:14 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 11 Apr 2005 19:58:14 +0300 Subject: devpts in mach buildroots In-Reply-To: <42597D26.2020003@redhat.com> References: <1113118212.5228.157.camel@bobcat.mine.nu> <42597D26.2020003@redhat.com> Message-ID: <1113238694.22499.50.camel@bobcat.mine.nu> On Sun, 2005-04-10 at 09:23 -1000, Warren Togami wrote: > Ville Skytt? wrote: > > perl-IPC-Run from Extras devel CVS fails its test suite when built with > > mach. It needs pseudo tty's and the mach chroot doesn't have devpts > > mounted, /dev/ptmx alone is not enough. > > > > The attached quick and dirty patch adds devpts mounting to mach > > buildroots. perl-IPC-Run builds fine here with it applied. > > > > What do you think, would this be an useful/acceptable addition to mach? > > > > Just go ahead and commit. Done. > Don't forget to bump the release or version > or something too. The buildsys-temp releases seem to be timestamp based, so apparently no need to do this. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Apr 11 18:30:22 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 11 Apr 2005 20:30:22 +0200 Subject: Strange i386/x86_64 behavior Message-ID: <20050411203022.36261edb@python2> Hi, I'm currently recompiling a bunch of packages for RHEL4 x86_64 and finally tried out the latest mach+yum snapshot. After quite a few problems with % pre scriplets failing, and packages being skipped, I finally got a build root working. I've rebuilt quite a few packages, no problems until I tried php... I get a few i386 packages installed, for a reason that is beyond me! It's 100% reproducible : - If I specify only the package names, the i386 versions get installed :-( $ mach yum install libstdc++-devel ncurses-devel zlib-devel pam-devel Setting up Install Process Setting up Repos mach-local 100% |=========================| 951 B 00:00 os 100% |=========================| 951 B 00:00 updates 100% |=========================| 951 B 00:00 groups 100% |=========================| 1.1 kB 00:00 egwn 100% |=========================| 951 B 00:00 Reading repository metadata in from local files mach-local: ################################################## 43/43 os : ################################################## 1591/1591 updates : ################################################## 138/138 egwn : ################################################## 40/40 Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package pam-devel.i386 0:0.77-65.1 set to be updated ---> Package zlib-devel.i386 0:1.2.1.2-1 set to be updated ---> Package libstdc++-devel.i386 0:3.4.3-9.EL4 set to be updated ---> Package ncurses-devel.i386 0:5.4-13 set to be updated --> Running transaction check Dependencies Resolved Transaction Listing: Install: libstdc++-devel.i386 0:3.4.3-9.EL4 - os Install: ncurses-devel.i386 0:5.4-13 - os Install: pam-devel.i386 0:0.77-65.1 - os Install: zlib-devel.i386 0:1.2.1.2-1 - os Total download size: 10 M Downloading Packages: Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: ncurses-devel 100 % done 1/5 Installing: pam-devel 100 % done 2/5 Installing: zlib-devel 100 % done 3/5 Installing: libstdc++-devel 100 % done 4/5 Completing update for libstdc++-devel - 5/5 Installed: libstdc++-devel.i386 0:3.4.3-9.EL4 ncurses-devel.i386 0:5.4-13 pam-devel.i386 0:0.77-65.1 zlib-devel.i386 0:1.2.1.2-1 Complete! - If I specify x86_64 for all packages, it works as expected : $ /usr/sbin/mach-helper rpm --root /var/lib/mach/roots/redhat-el4-x86_64- os '-e' 'ncurses-devel.i386' 'zlib-devel.i386' 'pam-devel.i386' 'libstdc++- devel.i386' error: Failed dependencies: libstdc++-devel = 3.4.3 is needed by (installed) gcc-c++-3.4.3-9.EL4.x86_64 $ mach rpm -Uvh /var/lib/mach/ roots/redhat-el4-x86_64-os/var/cache/mach/os/packages/libstdc++- devel-3.4.3-9.EL4.x86_64.rpm warning: /var/lib/mach/roots/redhat-el4- x86_64-os/var/cache/mach/os/packages/libstdc++- devel-3.4.3-9.EL4.x86_64.rpm: V3 DSA signature: NOKEY, key ID db42a60e Preparing... ################################################## libstdc++- devel ################################################## $ / usr/sbin/mach-helper rpm --root /var/lib/mach/roots/redhat-el4-x86_64-os '- e' 'ncurses-devel.i386' 'zlib-devel.i386' 'pam-devel.i386' 'libstdc++- devel.i386' $ mach yum install libstdc++-devel.x86_64 ncurses-devel.x86_64 zlib-devel.x86_64 pam-devel.x86_64 Setting up Install Process Setting up Repos mach-local 100% |=========================| 951 B 00:00 os 100% |=========================| 951 B 00:00 updates 100% |=========================| 951 B 00:00 groups 100% |=========================| 1.1 kB 00:00 egwn 100% |=========================| 951 B 00:00 Reading repository metadata in from local files mach-local: ################################################## 43/43 os : ################################################## 1591/1591 updates : ################################################## 138/138 egwn : ################################################## 40/40 Parsing package install arguments Nothing to do I'm really confused as to why yum chooses to install those i386 files when the arch isn't specified... I'll try to get yum to be more verbose and try to find out. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.40 0.25 0.31 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Apr 11 18:38:11 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 11 Apr 2005 20:38:11 +0200 Subject: Strange i386/x86_64 behavior In-Reply-To: <20050411203022.36261edb@python2> References: <20050411203022.36261edb@python2> Message-ID: <20050411203811.68410528@python2> Hi again, I'm really confused : "yum list pam-devel" tells me that the x86_64 version is installed, but "yum -d 5 install pam-devel" then says "No other pam-devel installed, adding to list for potential install", and goes ahead and installs the i386 package :-( Those i386 pam-devel and zlib-devel are causing my php build to fail miserably, and I don't know how to keep them from being installed. Matthias -- $ mach yum list pam-devel Setting up Repos mach-local 100% |=========================| 951 B 00:00 os 100% |=========================| 951 B 00:00 updates 100% |=========================| 951 B 00:00 groups 100% |=========================| 1.1 kB 00:00 egwn 100% |=========================| 951 B 00:00 Reading repository metadata in from local files mach-local: ################################################## 43/43 os : ################################################## 1591/1591 updates : ################################################## 138/138 egwn : ################################################## 40/40 Installed Packages pam-devel.x86_64 0.77-65.1 installed Available Packages pam-devel.i386 0.77-65.1 os $ mach yum -d 5 install pam-devel Yum Version: 2.2.1 COMMAND: yum --installroot /var/lib/mach/roots/redhat-el4-x86_64-os -c / var/lib/mach/states/redhat-el4-x86_64-os/yum.conf -d 5 install pam-devel Installroot: /var/lib/mach/roots/redhat-el4-x86_64-os Ext Commands: pam-devel Setting up Install Process Setting up Repos Baseurl(s) for repo: ['file:///var/lib/mach/roots/redhat-el4-x86_64-os/usr/ src/rpm'] mach-local 100% |=========================| 951 B 00:00 Baseurl(s) for repo: ['http://private///el4AS/x86_64/os'] os 100% |=========================| 951 B 00:00 Baseurl(s) for repo: ['http://private///el4AS/x86_64/updates'] updates 100% |=========================| 951 B 00:00 Baseurl(s) for repo: ['file:///home/egwn/buildroots///x86_64/'] groups 100% |=========================| 1.1 kB 00:00 Baseurl(s) for repo: ['http://private///el4AS/x86_64/egwn'] egwn 100% |=========================| 951 B 00:00 Reading repository metadata in from local files Setting up Package Sacks mach-local: ################################################## 43/43 os : ################################################## 1591/1591 updates : ################################################## 138/138 egwn : ################################################## 40/40 Reading Local RPMDB Parsing package install arguments No other pam-devel installed, adding to list for potential install reduced installs : pam-devel.i386 0:0.77-65.1 Resolving Dependencies 1113244465.75 --> Populating transaction set with selected packages. Please wait. Member: pam-devel.i386 0-0.77-65.1 - u Adding Package pam-devel - 0.77-65.1.i386 in mode u ---> Package pam-devel.i386 0:0.77-65.1 set to be updated --> Running transaction check Dependencies Resolved 1113244465.76 Transaction Listing: Install: pam-devel.i386 0:0.77-65.1 - os Total download size: 80 k Downloading Packages: Running Transaction Test Member: pam-devel.i386 0-0.77-65.1 - u Adding Package pam-devel - 0.77-65.1.i386 in mode u Finished Transaction Test Transaction Test Succeeded Member: pam-devel.i386 0-0.77-65.1 - u Adding Package pam-devel - 0.77-65.1.i386 in mode u Running Transaction Installing: pam-devel 100 % done 1/1 Installed: pam-devel.i386 0:0.77-65.1 Complete! $ mach yum list pam-devel Setting up Repos mach-local 100% |=========================| 951 B 00:00 os 100% |=========================| 951 B 00:00 updates 100% |=========================| 951 B 00:00 groups 100% |=========================| 1.1 kB 00:00 egwn 100% |=========================| 951 B 00:00 Reading repository metadata in from local files mach-local: ################################################## 43/43 os : ################################################## 1591/1591 updates : ################################################## 138/138 egwn : ################################################## 40/40 Installed Packages pam-devel.x86_64 0.77-65.1 installed pam-devel.i386 0.77-65.1 installed -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.28 0.25 0.24 From skvidal at phy.duke.edu Mon Apr 11 18:41:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 11 Apr 2005 14:41:33 -0400 Subject: Strange i386/x86_64 behavior In-Reply-To: <20050411203022.36261edb@python2> References: <20050411203022.36261edb@python2> Message-ID: <1113244893.3173.14.camel@cutter> On Mon, 2005-04-11 at 20:30 +0200, Matthias Saou wrote: > Hi, > > I'm currently recompiling a bunch of packages for RHEL4 x86_64 and finally > tried out the latest mach+yum snapshot. After quite a few problems with % > pre scriplets failing, and packages being skipped, I finally got a build > root working. > > I've rebuilt quite a few packages, no problems until I tried php... > > I get a few i386 packages installed, for a reason that is beyond me! It's > 100% reproducible : > > - If I specify only the package names, the i386 versions get installed :-( > > I'm really confused as to why yum chooses to install those i386 files when > the arch isn't specified... I'll try to get yum to be more verbose and try > to find out. it's intended behavior. yum will install the highest version and best arch of all packages for each multilib 'branch' available for the specified package name. so if you just specify foo and foo.i686, foo.x86_64 and foo.i386 are available then yum will install: foo.i686 foo.x86_64 yum resolves packages to install based on the multilib sets. so 64bit resolved against 64bit and 32bit against 32bit. They aren't compared against each other. -sv From skvidal at phy.duke.edu Mon Apr 11 18:43:31 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 11 Apr 2005 14:43:31 -0400 Subject: Strange i386/x86_64 behavior In-Reply-To: <20050411203811.68410528@python2> References: <20050411203022.36261edb@python2> <20050411203811.68410528@python2> Message-ID: <1113245011.3173.17.camel@cutter> On Mon, 2005-04-11 at 20:38 +0200, Matthias Saou wrote: > Hi again, > > I'm really confused : "yum list pam-devel" tells me that the x86_64 > version is installed, but "yum -d 5 install pam-devel" then says "No other > pam-devel installed, adding to list for potential install", and goes ahead > and installs the i386 package :-( Those i386 pam-devel and zlib-devel are > causing my php build to fail miserably, and I don't know how to keep them > from being installed. It does that b/c you're asking: install a pam-devel. Install it if it is no other is installed in that multilib set or if the one installed is older the one we would install. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Apr 11 18:56:47 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 11 Apr 2005 20:56:47 +0200 Subject: Strange i386/x86_64 behavior In-Reply-To: <1113244893.3173.14.camel@cutter> References: <20050411203022.36261edb@python2> <1113244893.3173.14.camel@cutter> Message-ID: <20050411205647.7bf442ca@python2> seth vidal wrote : > On Mon, 2005-04-11 at 20:30 +0200, Matthias Saou wrote: > > Hi, > > > > I'm currently recompiling a bunch of packages for RHEL4 x86_64 and finally > > tried out the latest mach+yum snapshot. After quite a few problems with % > > pre scriplets failing, and packages being skipped, I finally got a build > > root working. > > > > I've rebuilt quite a few packages, no problems until I tried php... > > > > I get a few i386 packages installed, for a reason that is beyond me! It's > > 100% reproducible : > > > > - If I specify only the package names, the i386 versions get installed :-( > > > > I'm really confused as to why yum chooses to install those i386 files when > > the arch isn't specified... I'll try to get yum to be more verbose and try > > to find out. > > it's intended behavior. > > yum will install the highest version and best arch of all packages for > each multilib 'branch' available for the specified package name. > > so if you just specify foo > > and foo.i686, foo.x86_64 and foo.i386 are available then yum will > install: > foo.i686 > foo.x86_64 > > yum resolves packages to install based on the multilib sets. so 64bit > resolved against 64bit and 32bit against 32bit. They aren't compared > against each other. I don't think I follow. How come I only have these few packages installed with both x86_64 and i386? I haven't told mach or yum anything special, and don't have glibc-devel.i386 installed for instance : $ mach yum list glibc-devel Setting up Repos mach-local 100% |=========================| 951 B 00:00 os 100% |=========================| 951 B 00:00 updates 100% |=========================| 951 B 00:00 groups 100% |=========================| 1.1 kB 00:00 egwn 100% |=========================| 951 B 00:00 Reading repository metadata in from local files mach-local: ################################################## 43/43 os : ################################################## 1591/1591 updates : ################################################## 138/138 egwn : ################################################## 40/40 Installed Packages glibc-devel.x86_64 2.3.4-2 installed Available Packages glibc-devel.i386 2.3.4-2 os Indeed, if I then do a "mach yum install glibc-devel", the i386 version gets installed in parallel, so I think I do understand what you mean, and my test wasn't relevant, but when all of the packages I listed are already installed in the build root in their x86_64 form, why did mach/yum install the i386 when nothing seems to depend explicitly on them? And why only those few ones? Maybe I have a clue : I did "mach -k build foo.spec" with the x86_64 packages already installed... so I guess mach told yum to install explicitly a bunch of packages, the explicit build dependencies, thus the i386 versions got installed in parallel to the already installed x86_64. Does that make sense? If that's it, then it's probably to be considered a bug since "-k" (keep) shouldn't change the installed set of packages if all the required ones were already installed. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.01 0.14 0.22 From wtogami at redhat.com Fri Apr 15 06:00:18 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 14 Apr 2005 20:00:18 -1000 Subject: Strange i386/x86_64 behavior In-Reply-To: <20050411203022.36261edb@python2> References: <20050411203022.36261edb@python2> Message-ID: <425F5872.7060009@redhat.com> Just one thought... is there any case where a x86_64 buildroot actually needs any i386 packages? Warren Togami wtogami at redhat.com From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Apr 19 14:03:18 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Apr 2005 16:03:18 +0200 Subject: Strange i386/x86_64 behavior In-Reply-To: <425F5872.7060009@redhat.com> References: <20050411203022.36261edb@python2> <425F5872.7060009@redhat.com> Message-ID: <20050419160318.1389665b@python2> Warren Togami wrote : > Just one thought... is there any case where a x86_64 buildroot actually > needs any i386 packages? I don't think so. Which is why mach w/ apt has always worked fine for me on my x86_64 build machine, as I only have x86_64 packages in the root. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 1.24 1.80 1.65 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Apr 19 14:08:29 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Apr 2005 16:08:29 +0200 Subject: Some runuser problems Message-ID: <20050419160829.493cca7a@python2> Hi, I'm having trouble setting up an FC2 root with the current mach/yum build system. First, it seems to configuration regarding "/sbin/runuser" being overwritten for FC3 and FC Dev roots it redundant, as runuser is the default in the main mach file. But the problem is that it's in there with "@SBINDIR@/runuser" whereas it's always installed as "/sbin/runuser". I think hardcoding it as "/sbin/runuser" in mach.in would be an acceptable solution, otherwise a new configure check and replace should probably be done. Now, I've added this to my "fedora-2-i386" file : config['fedora-2-i386-core'] = {'runuser': '/bin/su'} But it seems that it's not taken into account, and I really don't understand why. If I change the main runuser definition in /usr/bin/mach to /bin/su, then all works fine. I'm really puzzled on that one, and am wondering what I could be doing wrong. Any ideas? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.68 1.13 1.39 From skvidal at phy.duke.edu Tue Apr 19 14:12:11 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 19 Apr 2005 10:12:11 -0400 Subject: Some runuser problems In-Reply-To: <20050419160829.493cca7a@python2> References: <20050419160829.493cca7a@python2> Message-ID: <1113919931.15629.8.camel@cutter> On Tue, 2005-04-19 at 16:08 +0200, Matthias Saou wrote: > Hi, > > I'm having trouble setting up an FC2 root with the current mach/yum build > system. First, it seems to configuration regarding "/sbin/runuser" being > overwritten for FC3 and FC Dev roots it redundant, as runuser is the > default in the main mach file. But the problem is that it's in there with > "@SBINDIR@/runuser" whereas it's always installed as "/sbin/runuser". I > think hardcoding it as "/sbin/runuser" in mach.in would be an acceptable > solution, otherwise a new configure check and replace should probably be > done. > > Now, I've added this to my "fedora-2-i386" file : > > config['fedora-2-i386-core'] = {'runuser': '/bin/su'} > > But it seems that it's not taken into account, and I really don't > understand why. If I change the main runuser definition in /usr/bin/mach > to /bin/su, then all works fine. I'm really puzzled on that one, and am > wondering what I could be doing wrong. Any ideas? > Thomas might disagree but I think all the autoconf stuff in mach is overkill. It doesn't serve much purpose b/c the default use case is what should be the default. try setting that config in your /etc/mach/conf file. just for fun. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Apr 19 15:12:51 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 19 Apr 2005 17:12:51 +0200 Subject: Some runuser problems In-Reply-To: <1113919931.15629.8.camel@cutter> References: <20050419160829.493cca7a@python2> <1113919931.15629.8.camel@cutter> Message-ID: <20050419171251.60c90f99@python2> seth vidal wrote : > > Now, I've added this to my "fedora-2-i386" file : > > > > config['fedora-2-i386-core'] = {'runuser': '/bin/su'} > > > > But it seems that it's not taken into account, and I really don't > > understand why. If I change the main runuser definition in /usr/bin/mach > > to /bin/su, then all works fine. I'm really puzzled on that one, and am > > wondering what I could be doing wrong. Any ideas? > > > > Thomas might disagree but I think all the autoconf stuff in mach is > overkill. It doesn't serve much purpose b/c the default use case is what > should be the default. > > try setting that config in your /etc/mach/conf file. When I set any of these two in /etc/mach/conf it works as expected : config['runuser'] = '/bin/su' config['runuser'] = '/sbin/runuser' Next test, this line : config['fedora-2-i386-core'] = { 'runuser': '/sbin/runuser' } When it's in my ~/.machrc the build fails as expected (since /bin/su is my value in /usr/bin/mach and the expected value for FC2 to work), but when it's in /etc/mach/dist.d/fedora-2-i386 instead, the build works. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.93 1.08 1.14 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Apr 25 17:41:04 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 25 Apr 2005 19:41:04 +0200 Subject: Issues on x86_64 host Message-ID: <20050425194104.02697ddd@python2> Hi, When I try to install the latest yum modified mach on an x86_64 FC Development (as of last week, yum 2.3.2) it then tricks me into thinking that the roots I set up are fine (no errors in the output) when they're not ;-) I recall having had the same problem on an RHEL4 host for all roots too, which I worked around by manually installing all missing packages, most with --noscripts... and at one point things started to work. But now, although the "mach setup minimal" reported nothing unusual, here is what I get right after when trying "mach yum groupinstall build- minimal" : [dude at darkside easytag]$ mach setup minimal Preparing root Making /dev devices Installing group 'minimal' .................. [dude at darkside easytag]$ mach setup minimal [dude at darkside easytag]$ mach yum groupinstall build-minimal Setting up Group Process Setting up repositories core 100% |=========================| 1.1 kB 00:00 freshrpms 100% |=========================| 951 B 00:00 updates 100% |=========================| 951 B 00:00 groups 100% |=========================| 1.1 kB 00:00 Setting up repositories Reading repository metadata in from local files Passing package list to Install Process Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package rpm.x86_64 0:4.3.2-21 set to be updated ---> Package initscripts.x86_64 0:7.93.7-1 set to be updated --> Running transaction check --> Processing Dependency: fileutils for package: initscripts --> Processing Dependency: kernel >= 2.6 for package: initscripts --> Processing Dependency: sh-utils for package: initscripts --> Processing Dependency: fileutils for package: rpm --> Processing Dependency: /sbin/runuser for package: initscripts --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package kernel.x86_64 0:2.6.11-1.14_FC3 set to be installed ---> Package coreutils.x86_64 0:5.2.1-31 set to be updated --> Running transaction check --> Processing Dependency: pam >= 0.66-12 for package: coreutils --> Processing Dependency: libpam_misc.so.0()(64bit) for package: coreutils --> Processing Dependency: libpam.so.0()(64bit) for package: coreutils --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package pam.x86_64 0:0.77-66.2 set to be updated --> Running transaction check Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: initscripts x86_64 7.93.7-1 updates 1.1 M rpm x86_64 4.3.2-21 core 566 k Installing for dependencies: coreutils x86_64 5.2.1-31 core 2.9 M kernel x86_64 2.6.11-1.14_FC3 updates 17 M pam x86_64 0.77-66.2 updates 1.9 M Transaction Summary ============================================================================= Install 5 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 24 M Downloading Packages: Running Transaction Test warning: pam-0.77-66.2: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 Finished Transaction Test Transaction Test Succeeded Running Transaction error: %pre(coreutils-5.2.1-31.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping coreutils-5.2.1-31 error: %pre(kernel-2.6.11-1.14_FC3.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping kernel-2.6.11-1.14_FC3 error: %pre(pam-0.77-66.2.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping pam-0.77-66.2 error: %pre(rpm-4.3.2-21.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping rpm-4.3.2-21 error: %pre(initscripts-7.93.7-1.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping initscripts-7.93.7-1 Installed: initscripts.x86_64 0:7.93.7-1 rpm.x86_64 0:4.3.2-21 Dependency Installed: coreutils.x86_64 0:5.2.1-31 kernel.x86_64 0:2.6.11-1.14_FC3 pam.x86_64 0:0.77-66.2 Complete! [dude at darkside easytag]$ (sorry if things get all wrapped around :-/) Now the other weird thing is that if I "manually" use "mach rpm -ivh" for all those exact packages, it works fine. It seems that it fails only through yum :-( Given the trivial content of some of these scriplets, I'm really confused! The glibc-kernheaders which fails the same way is : preinstall scriptlet (using /bin/sh): [ -L /usr/include/linux ] && rm -f /usr/include/linux || : [ -L /usr/include/asm ] && rm -f /usr/include/asm || : exit 0 I really don't see how that manages to fail :-( If I try to "mach chroot" after manually installing what is missing from the "minimal" group, it works, but "yum groupinstall build-base" then fails with other packages, same for the main build group. Any ideas? Seth, you're building packages on an x86_64, aren't you? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 0.19 0.22 0.30 From skvidal at phy.duke.edu Mon Apr 25 18:11:10 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 25 Apr 2005 14:11:10 -0400 Subject: Issues on x86_64 host In-Reply-To: <20050425194104.02697ddd@python2> References: <20050425194104.02697ddd@python2> Message-ID: <1114452670.4945.1.camel@cutter> > (sorry if things get all wrapped around :-/) > > Now the other weird thing is that if I "manually" use "mach rpm -ivh" for > all those exact packages, it works fine. It seems that it fails only > through yum :-( Given the trivial content of some of these scriplets, I'm > really confused! The glibc-kernheaders which fails the same way is : > > I really don't see how that manages to fail :-( > If I try to "mach chroot" after manually installing what is missing from > the "minimal" group, it works, but "yum groupinstall build-base" then > fails with other packages, same for the main build group. > > Any ideas? Seth, you're building packages on an x86_64, aren't you? is selinux disabled? -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Apr 25 18:58:04 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 25 Apr 2005 20:58:04 +0200 Subject: Issues on x86_64 host In-Reply-To: <1114452670.4945.1.camel@cutter> References: <20050425194104.02697ddd@python2> <1114452670.4945.1.camel@cutter> Message-ID: <20050425205804.68f22966@python2> seth vidal wrote : > > (sorry if things get all wrapped around :-/) > > > > Now the other weird thing is that if I "manually" use "mach rpm -ivh" for > > all those exact packages, it works fine. It seems that it fails only > > through yum :-( Given the trivial content of some of these scriplets, I'm > > really confused! The glibc-kernheaders which fails the same way is : > > > I really don't see how that manages to fail :-( > > If I try to "mach chroot" after manually installing what is missing from > > the "minimal" group, it works, but "yum groupinstall build-base" then > > fails with other packages, same for the main build group. > > > > Any ideas? Seth, you're building packages on an x86_64, aren't you? > > is selinux disabled? Yes, it was set to "Warn" at installation time. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 1.87 1.28 0.72 From skvidal at phy.duke.edu Mon Apr 25 19:17:12 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 25 Apr 2005 15:17:12 -0400 Subject: Issues on x86_64 host In-Reply-To: <20050425205804.68f22966@python2> References: <20050425194104.02697ddd@python2> <1114452670.4945.1.camel@cutter> <20050425205804.68f22966@python2> Message-ID: <1114456632.4945.5.camel@cutter> On Mon, 2005-04-25 at 20:58 +0200, Matthias Saou wrote: > seth vidal wrote : > > > > (sorry if things get all wrapped around :-/) > > > > > > Now the other weird thing is that if I "manually" use "mach rpm -ivh" for > > > all those exact packages, it works fine. It seems that it fails only > > > through yum :-( Given the trivial content of some of these scriplets, I'm > > > really confused! The glibc-kernheaders which fails the same way is : > > > > > I really don't see how that manages to fail :-( > > > If I try to "mach chroot" after manually installing what is missing from > > > the "minimal" group, it works, but "yum groupinstall build-base" then > > > fails with other packages, same for the main build group. > > > > > > Any ideas? Seth, you're building packages on an x86_64, aren't you? > > > > is selinux disabled? > > Yes, it was set to "Warn" at installation time. > turn it off, entirely. do not even turn on 'warn' and tell me what you get, please. -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Apr 25 19:43:12 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 25 Apr 2005 21:43:12 +0200 Subject: Issues on x86_64 host In-Reply-To: <1114456632.4945.5.camel@cutter> References: <20050425194104.02697ddd@python2> <1114452670.4945.1.camel@cutter> <20050425205804.68f22966@python2> <1114456632.4945.5.camel@cutter> Message-ID: <20050425214312.4049ff71@python2> seth vidal wrote : > > > is selinux disabled? > > > > Yes, it was set to "Warn" at installation time. > > turn it off, entirely. > > do not even turn on 'warn' and tell me what you get, please. I upgraded the system to today's Rawhide, rebooted with "selinux=off"... and I get something that seems to be working as expected now! I guess "Warn" doesn't really work as advertised. Actually, I just got the machine to reboot instantly 3 times in a row while rebuilding a package and doing important nfs I/O... but that's a problem for another list ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.14_FC3 Load : 3.12 2.30 1.54 From pmatilai at welho.com Tue Apr 26 04:13:51 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 26 Apr 2005 07:13:51 +0300 (EEST) Subject: Issues on x86_64 host In-Reply-To: <20050425214312.4049ff71@python2> References: <20050425194104.02697ddd@python2> <1114452670.4945.1.camel@cutter> <20050425205804.68f22966@python2> <1114456632.4945.5.camel@cutter> <20050425214312.4049ff71@python2> Message-ID: On Mon, 25 Apr 2005, Matthias Saou wrote: > seth vidal wrote : > >>>> is selinux disabled? >>> >>> Yes, it was set to "Warn" at installation time. >> >> turn it off, entirely. >> >> do not even turn on 'warn' and tell me what you get, please. > > I upgraded the system to today's Rawhide, rebooted with "selinux=off"... > and I get something that seems to be working as expected now! I guess > "Warn" doesn't really work as advertised. Yeah - I've been playing around with this recently as well and for chroot installations you'll want selinux completely off, otherwise it'll fail. Haven't dug any deeper as to why is that (selinux still scares me :) - Panu - From enrico.scholz at informatik.tu-chemnitz.de Tue Apr 26 08:11:24 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 26 Apr 2005 10:11:24 +0200 Subject: Issues on x86_64 host In-Reply-To: <20050425214312.4049ff71@python2> (Matthias Saou's message of "Mon, 25 Apr 2005 21:43:12 +0200") References: <20050425194104.02697ddd@python2> <1114452670.4945.1.camel@cutter> <20050425205804.68f22966@python2> <1114456632.4945.5.camel@cutter> <20050425214312.4049ff71@python2> Message-ID: <87mzrmez4j.fsf@kosh.bigo.ensc.de> thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes: >> > > is selinux disabled? >> > >> > Yes, it was set to "Warn" at installation time. >> >> turn it off, entirely. >> >> do not even turn on 'warn' and tell me what you get, please. > > I upgraded the system to today's Rawhide, rebooted with "selinux=off"... > and I get something that seems to be working as expected now! I guess > "Warn" doesn't really work as advertised. afais, mach is using an LD_PRELOAD wrapper also. With Linux-Vservers, we are overriding rpm_execcon(3) and things seem to work fine. http://savannah.nongnu.org/cgi-bin/viewcvs/util-vserver/util-vserver/src/rpm-fake.c?rev=HEAD&content-type=text/vnd.viewcvs-markup Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From jkeating at j2solutions.net Wed Apr 27 18:25:39 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 27 Apr 2005 11:25:39 -0700 Subject: Suitable host for i386/x86_64 builds Message-ID: <1114626339.6151.75.camel@jkeating2.hq.pogolinux.com> So I'm watching and tracking this buildsys development for use with Fedora Legacy. I'm curious as to if we're in a state that we might be able to start building 32bit and 64bit packages for FC1/FC2 and pure 32bit packages for RHL 7.3/9. If so, what base OS is a good target for this build system? I would prefer something of Enterprise flavor, like CentOS4 so that I don't have to upgrade the base OS in a few years to keep up w/ security stuff (like when Legacy stops supporting a release). -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating