From symbiont at berlios.de Sun Sep 11 12:39:10 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sun, 11 Sep 2005 20:39:10 +0800 Subject: Recommend different location for yum.conf in mock Message-ID: <200509112039.11742.symbiont@berlios.de> Hi: When dealing with building yum itself inside of a mock chroot, it's better to do this: yumconf = os.path.join(self.rootdir, 'etc', 'yum.repos.d', 'mock.conf') Instead of messing with rpmsave/rpmnew. -- -jeff From symbiont at berlios.de Sun Sep 11 16:19:49 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 12 Sep 2005 00:19:49 +0800 Subject: Recommend different location for yum.conf in mock In-Reply-To: <200509112039.11742.symbiont@berlios.de> References: <200509112039.11742.symbiont@berlios.de> Message-ID: <200509120019.50554.symbiont@berlios.de> On Sunday 11 September 2005 20:39, Jeff Pitman wrote: > ? ? ? ? yumconf = os.path.join(self.rootdir, 'etc', 'yum.repos.d', > 'mock.conf') FYI: I changed this to /builddir/mock.conf instead and passed "-c /builddir/mock.conf" to the yum command. There were just too many perm issues ridden with a config in /etc... -- -jeff From fedora at leemhuis.info Wed Sep 28 13:20:25 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 28 Sep 2005 15:20:25 +0200 Subject: Once again: kernel-modules in the buildsystem Message-ID: <1127913625.3098.12.camel@localhost.localdomain> Hi All! The last discussion how to handle kernel-modules in the buildsys stuck at some point (for those who can't remember it see https://www.redhat.com/archives/fedora-buildsys-list/2005-August/msg00030.html for the start and https://www.redhat.com/archives/fedora-buildsys-list/2005-August/msg00036.html for one of the ends. I really would like it if we could get this discussion to life again to solve this problem. I made a quick hack against mock 0.4 so it passes a "--define kernel\ some-kernel-version-here" to the rpmbuild-calls that build the pgk. This required a new mock command-line option ("--kernel put-some-kernel-version-here"). I included a quick check so this option only works with packages whose name starts with "kernel" so nobody sane can abuse it for other packages. Warning, I'm not programming very often, but the patch WORKSFORME. Seth, is something like that acceptable for you? Dan, if something like that goes into mock -- what would be the best way to make this new mock-option usable in plague for kernel-modules in fedora-extras? Should plague automatically build the modules for all kernels available (the one that was shipped and those currently in updates-released)? Or only for the newest kernel available? Or should the packager say something like "make plague KERNEL=put-kernel-ver-here" when requesting build of a fdr-extras-kernel-module-pkg? -- Thorsten Leemhuis -------------- next part -------------- A non-text attachment was scrubbed... Name: mock-support-for-kernel-modules-0.1.patch Type: text/x-patch Size: 3316 bytes Desc: not available URL: From dcbw at redhat.com Wed Sep 28 20:50:24 2005 From: dcbw at redhat.com (Dan Williams) Date: Wed, 28 Sep 2005 16:50:24 -0400 Subject: Once again: kernel-modules in the buildsystem In-Reply-To: <1127913625.3098.12.camel@localhost.localdomain> References: <1127913625.3098.12.camel@localhost.localdomain> Message-ID: <1127940624.24429.78.camel@dcbw.boston.redhat.com> On Wed, 2005-09-28 at 15:20 +0200, Thorsten Leemhuis wrote: > Dan, if something like that goes into mock -- what would be the best way > to make this new mock-option usable in plague for kernel-modules in > fedora-extras? Should plague automatically build the modules for all > kernels available (the one that was shipped and those currently in > updates-released)? Or only for the newest kernel available? Or should > the packager say something like "make plague KERNEL=put-kernel-ver-here" > when requesting build of a fdr-extras-kernel-module-pkg? I recognize the need for this, there are a few questions that need answering here though. First, methods. 1) have plague automatically build for all kernels Requires a large amount of work with yum to essentially list all kernel-* packages in a given repository, then queue up builds for them. That's a chunk of work. 2) have plague build for latest kernel Still requires work to ask yum about a certain repository to get latest kernel package. Slightly easier, but not very much so. Given that we are not guaranteed that the kernel-* package will be in the server's repository (it might be in the upstream "official" mirror instead) we pretty much have to use yum. 3) have the packager do it Pretty much the status quo right now, not much of a win IMHO. In any case, you're going to have to get some form of argument passing through Seth and into mock. I don't like the "allow packager to pass random args" thing, since that's a direct impact on the security of the build system. In the short term though, limiting such things to automatic rebuilds of kernel modules seems sane. Ideally, yes, plague should be doing some depsolving on the server side. That's going to take a while to build in. In the mean time, we could build in some kernel-module specific stuff, I'm not against that. Most likely post 0.4.x work (1). Some nice things that could go along with depsolving in the server: - Store mock configs on the server and push them out to builders on-demand. Bonus: we use same yum configs on server & builders. - Don't build packages until their deps are satisfied, waiting a max of 8 or 10 hours before failing the package. Dan (1) That doesn't mean "a year from now" and work could start on that fairly soon after 0.4.x comes out, which is "in a few weeks" From symbiont at berlios.de Thu Sep 29 03:31:14 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 29 Sep 2005 11:31:14 +0800 Subject: Convenience option: disablerepo Message-ID: <200509291131.15116.symbiont@berlios.de> I have repos set up for the base system and also the "built" packages. Instead of manually commenting these out when the need arises, it can automatically be scripted using the --disablerepo option to mock. This is then forwarded to the yum command. enjoy, -- -jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: mock.py-disablerepo.patch Type: text/x-diff Size: 1430 bytes Desc: not available URL: From skvidal at phy.duke.edu Thu Sep 29 04:40:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 29 Sep 2005 00:40:49 -0400 Subject: Convenience option: disablerepo In-Reply-To: <200509291131.15116.symbiont@berlios.de> References: <200509291131.15116.symbiont@berlios.de> Message-ID: <1127968850.26377.3.camel@cutter> On Thu, 2005-09-29 at 11:31 +0800, Jeff Pitman wrote: > I have repos set up for the base system and also the "built" packages. > Instead of manually commenting these out when the need arises, it can > automatically be scripted using the --disablerepo option to mock. This > is then forwarded to the yum command. > > enjoy, why would we need to add this option to mock? Is it terribly common to need to disable a repo for some specific package build? Why not just have another config file? -sv From symbiont at berlios.de Thu Sep 29 05:03:06 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 29 Sep 2005 13:03:06 +0800 Subject: Convenience option: disablerepo In-Reply-To: <1127968850.26377.3.camel@cutter> References: <200509291131.15116.symbiont@berlios.de> <1127968850.26377.3.camel@cutter> Message-ID: <200509291303.06462.symbiont@berlios.de> On Thursday 29 September 2005 12:40, seth vidal wrote: > why would we need to add this option to mock? Is it terribly common > to need to disable a repo for some specific package build? Why not > just have another config file? Ties into the obsoletes question I had on the yum list. With "built" in the config, then I cannot init a chroot. So, it's common in that I need it when the root gets re-initialized. But, if mock's only target audience is FE, then I guess it doesn't matter that much since FE doesn't participate in the cardinal sin of updating Core packages (or worse: renaming them :D). Another config file would work; but, I guess the same argument could be used for yum itself, too: Why not just have another config file in yum? Anyway, patch is FYI. No expectations for upstream adoption. (I realize that feature rot needs to be reigned upon.) thanks, -- -jeff From fedora at leemhuis.info Thu Sep 29 09:54:22 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 29 Sep 2005 11:54:22 +0200 Subject: Once again: kernel-modules in the buildsystem In-Reply-To: <1127940624.24429.78.camel@dcbw.boston.redhat.com> References: <1127913625.3098.12.camel@localhost.localdomain> <1127940624.24429.78.camel@dcbw.boston.redhat.com> Message-ID: <1127987662.4188.10.camel@localhost.localdomain> Hi! Dan, thanks for taking the time for your reply. Am Mittwoch, den 28.09.2005, 16:50 -0400 schrieb Dan Williams: > On Wed, 2005-09-28 at 15:20 +0200, Thorsten Leemhuis wrote: > > Dan, if something like that goes into mock -- what would be the best way > > to make this new mock-option usable in plague for kernel-modules in > > fedora-extras? Should plague automatically build the modules for all > > kernels available (the one that was shipped and those currently in > > updates-released)? Or only for the newest kernel available? Or should > > the packager say something like "make plague KERNEL=put-kernel-ver-here" > > when requesting build of a fdr-extras-kernel-module-pkg? > > I recognize the need for this, there are a few questions that need > answering here though. First, methods. > > 1) have plague automatically build for all kernels > [...] Some people think that should be done. But building it for the latest kernel should be enough IMHO. In the past I also thought we should build the module for the kernel that was released with core, cause it seems a lot of people with slow modems or systems that are not directly connected to the internet don't update their kernels. If we build for more then one kernel this is the second important one. > 2) have plague build for latest kernel > Still requires work to ask yum about a certain repository to get latest > kernel package. Slightly easier, but not very much so. Given that we > are not guaranteed that the kernel-* package will be in the server's > repository (it might be in the upstream "official" mirror instead) we > pretty much have to use yum. In the build system of another 3rd-party repo we had a file that listed for which kernel modules should be build. Could that be a short term solution for plague es well? > 3) have the packager do it > Pretty much the status quo right now, not much of a win IMHO. I disagree. We have no "status quo" right now because - plague developer(s) - mock developer(s) - people on fedora-packaging that want to specify kernel-module-packaging - fedora-extras packagers with packages like qemu, OpenAFS (and probably more) - yum developers all wait for each other (since months) to standardize packaging and building of kernel-module-packages for extras. This is a real pity :| I really would like to get this sorted out somehow. > In any case, you're going to have to get some form of argument passing > through Seth and into mock. Seth, is something like the patch I posted yesterday acceptable for you? If you don't like part of it just tell me and I can see if I can fix it with my python knowledge (and improve that while at it) > I don't like the "allow packager to pass > random args" thing, For other packages I agree. > since that's a direct impact on the security of the > build system. In the short term though, limiting such things to > automatic rebuilds of kernel modules seems sane. Just out of curiosity: What do you suggest in the long term? -- Thorsten Leemhuis