Stuff to look for in plague 0.4

[Dan Williams]

Quite a few things will change for plague 0.4:

o Single builder, multiple jobs: you'll only have to run one builder instance on 
a machine to run multiple build jobs; each builder will be able to build a set 
number of jobs at a time (usually equal to # of processors).
	- Architectures are autodetected

o New config file format: it's now using ConfigParser, which means more 
straightforward and text-friendly config files, for both the server and the 
builder.

o Targets get their own config files: each target, on the server and on the 
builder, gets its own config file.  This means a few things:
	- each target can have its own CVS settings
	- each target can be a different distribution

o Scratch/Testing targets: targets that don't contribute packages tothe 
repository, so you can test out your packages before you actually push them 
through.  Scratch targets also don't kill a job when one architecture fails.

If anyone has more thoughts, file some RFEs in bugzilla for Fedora Extras 
Infrastructure.

Dan

[Thorsten Leemhuis]

Am Freitag, den 19.08.2005, 21:40 -0400 schrieb Dan Williams:
>  Quite a few things will change for plague 0.4:
>  [...]
>  If anyone has more thoughts, file some RFEs in bugzilla for Fedora Extras 
>  Infrastructure. 
What is the current status of passing special options to the actual
rpmbuild call? We should have those for building kernel-modules because
building kernel-modules for a lot of different kernels would be much
easier if no changes to the actual kernel-module-specfile are needed. In
the current KernelModuleProposal-Example2 (*1) this is realized by:

%{!?kver:  %define  kver            %(uname -r)}
[...]
make KVERS=%{kver} KSRC="%{_usrsrc}/kernels/%{kver}-%{_target_cpu}" -C driver 

So if someone builds the src.rpm at home it is rebuild for the current
kernel. When build with mock the buildsystem should defined kver.
Something like:

for kernel in <list of target kernels [example: current-kernel.i586 current-kernel.i686
current-kernel-smp.i586]>
do
	mock build /path/to/srpm --define "kver $kernel"
done

AFACS we need support for this in both mock and plague (or is something
like that already possible? mach can pass options to rpmbuild, mock
can't iirc)

CU
thl

*1 - Current kernel-module-proposal:
http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal

-- 
Thorsten Leemhuis <fedora(a)leemhuis.info&gt;

[seth vidal]

On Sat, 2005-08-20 at 12:17 +0200, Thorsten Leemhuis wrote:
>  Am Freitag, den 19.08.2005, 21:40 -0400 schrieb Dan Williams:
>  > Quite a few things will change for plague 0.4:
>  > [...]
>  > If anyone has more thoughts, file some RFEs in bugzilla for Fedora Extras 
>  > Infrastructure.
>  
>  What is the current status of passing special options to the actual
>  rpmbuild call? We should have those for building kernel-modules because
>  building kernel-modules for a lot of different kernels would be much
>  easier if no changes to the actual kernel-module-specfile are needed. In
>  the current KernelModuleProposal-Example2 (*1) this is realized by:
>  
>  %{!?kver:  %define  kver            %(uname -r)}
>  [...]
>  make KVERS=%{kver} KSRC="%{_usrsrc}/kernels/%{kver}-%{_target_cpu}" -C driver 
>  
>  So if someone builds the src.rpm at home it is rebuild for the current
>  kernel. When build with mock the buildsystem should defined kver.
>  Something like:
>  
>  for kernel in <list of target kernels [example: current-kernel.i586
> current-kernel.i686 current-kernel-smp.i586]>
>  do
>  	mock build /path/to/srpm --define "kver $kernel"
>  done
>  
>  AFACS we need support for this in both mock and plague (or is something
>  like that already possible? mach can pass options to rpmbuild, mock
>  can't iirc)
>   
I do not think that adding this into mock or rpmbuild is a good idea,
honestly. If the package won't built w/o arbitrary defines then we'll
have a devil of a time figuring out how to REBUILD it later. We need
builds to be replayable and if we have to count on what someone inputted
into the cli then we can't replay them.

-sv

kernel-modules in the buildsystem (Was: Re: Stuff to look for in plague 0.4)

[Thorsten Leemhuis]

CC fedora-packaging because this concerns kernel-module-packaging

Am Dienstag, den 23.08.2005, 01:18 -0400 schrieb seth vidal:
>  On Sat, 2005-08-20 at 12:17 +0200, Thorsten Leemhuis wrote:
>  > Am Freitag, den 19.08.2005, 21:40 -0400 schrieb Dan Williams:
>  > > Quite a few things will change for plague 0.4:
>  > > [...]
>  > > If anyone has more thoughts, file some RFEs in bugzilla for Fedora Extras 
>  > > Infrastructure.
>  > 
>  > What is the current status of passing special options to the actual
>  > rpmbuild call? We should have those for building kernel-modules because
>  > building kernel-modules for a lot of different kernels would be much
>  > easier if no changes to the actual kernel-module-specfile are needed. In
>  > the current KernelModuleProposal-Example2 (*1) this is realized by:
>  > 
>  > %{!?kver:  %define  kver            %(uname -r)}
>  > [...]
>  > make KVERS=%{kver} KSRC="%{_usrsrc}/kernels/%{kver}-%{_target_cpu}" -C
> driver 
>  > 
>  > So if someone builds the src.rpm at home it is rebuild for the current
>  > kernel. When build with mock the buildsystem should defined kver.
>  > Something like:
>  > 
>  > for kernel in <list of target kernels [example: current-kernel.i586
> current-kernel.i686 current-kernel-smp.i586]>
>  > do
>  > 	mock build /path/to/srpm --define "kver $kernel"
>  > done
>  > 
>  > AFACS we need support for this in both mock and plague (or is something
>  > like that already possible? mach can pass options to rpmbuild, mock
>  > can't iirc)
>  
>  I do not think that adding this into mock or rpmbuild is a good idea,
>  honestly. 
For other packages I agree. Kernel-modules should be a exception IMHO.

>   If the package won't built w/o arbitrary defines then we'll
>  have a devil of a time figuring out how to REBUILD it later. 
It builds for the normal user without arbitrary defines. And even
better: It automatically builds what you probably want, because with the
above it builds the kernel-module for the currently running kernel. If
you get a random kernel-module.src.rpm where kver ist hardcoded you have
to edit it each time to get compile against a new kernel. 

BTW, this is in all three proposals in
http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal

If we all agree that we don't like passing arguments to rpmbuild then we
should restart the kernel-module-discussion on fedora-packaging.

CU
thl

kernel-modules in the buildsystem (Was: Re: Stuff to look for in plague 0.4)

[seth vidal]

>  For other packages I agree. Kernel-modules should be a exception
> IMHO. 
I worry that having them as the exception means we have to do the code
anyway which makes it a slippery-damn-slope to all packages using
arbitrary defines.

>  It builds for the normal user without arbitrary defines. And even
>  better: It automatically builds what you probably want, because with the
>  above it builds the kernel-module for the currently running kernel. If
>  you get a random kernel-module.src.rpm where kver ist hardcoded you have
>  to edit it each time to get compile against a new kernel. 
>   
why doesn't it automatically build for whatever the highest installed
kernel-devel or highest installed kernel package is?

-sv

kernel-modules in the buildsystem (Was: Re: Stuff to look for in plague 0.4)

[Thorsten Leemhuis]

Am Dienstag, den 23.08.2005, 01:59 -0400 schrieb seth vidal:
>  > For other packages I agree. Kernel-modules should be a exception
> IMHO.
>  
>  I worry that having them as the exception means we have to do the code
>  anyway which makes it a slippery-damn-slope to all packages using
>  arbitrary defines. 
:)

>  > It builds for the normal user without arbitrary defines. And
> even
>  > better: It automatically builds what you probably want, because with the
>  > above it builds the kernel-module for the currently running kernel. If
>  > you get a random kernel-module.src.rpm where kver ist hardcoded you have
>  > to edit it each time to get compile against a new kernel. 
>  > 
>  why doesn't it automatically build for whatever the highest installed
>  kernel-devel or highest installed kernel package is? 
And who decides when a module for a smp-kernel is build and when not?
Doing this with 

%build
buildfunc()
{
  make something
}
%ifarch i686 x86_64 ppc
build up
build smp
%else
build up
%endif

in the spec is really ugly (and not possible with our current scheme
afaics -- need to try, but i suspect it won't work).

CU
thl

kernel-modules in the buildsystem (Was: Re: Stuff to look for in plague 0.4)

[Warren Togami]

seth vidal wrote:
> >For other packages I agree. Kernel-modules should be a exception
> IMHO.
>  
>  
>  I worry that having them as the exception means we have to do the code
>  anyway which makes it a slippery-damn-slope to all packages using
>  arbitrary defines.
>   
I don't buy the slippery slope argument here.  Kernel is really the only 
messy case where you can have multiple versions installed 
simultaneously.  There are also no other valid cases where what is 
installed does not necessarily match what is running.

>  
>  
>  why doesn't it automatically build for whatever the highest installed
>  kernel-devel or highest installed kernel package is?
>   
The default spec "uname -r" makes it so a user can easily build it 
against their currently running kernel.  This is desirable to easily 
support users who use custom kernels.  For everyone else we provide 
packages against the official released kernels.  It is very desirable to 
be able to build both of these cases from the same SRPM without 
modification.

Defining only kver in the build environment is a simple and elegant way 
of supporting both of these requirements.  It also makes it much 
possible to automate kernel module rebuilds when a new kernel is released.

Warren Togami
wtogami(a)redhat.com

[Fedora-packaging] Re: kernel-modules in the buildsystem (Was: Re: Stuff to look for in plague 0.4)

[Matt Domsch]

On Tue, Aug 23, 2005 at 01:59:27AM -0400, seth vidal wrote:
>  why doesn't it automatically build for whatever the highest
> installed
>  kernel-devel or highest installed kernel package is? 
One of the problems is that the build system doesn't know what kernels
an end user may be running.  Therefore, you've got to

a) be able to have the end user rebuild for whatever kernel they're
running (easy, works that way today)

b) if the driver is needed at install time, the build system needs to
provide pre-builts for the installer (and CD media) kernel.

(optionally) c) have the build system build binaries for each of the
released errata kernels too, so you don't require a kernel upgrade in
order to get a given module that matches.

I'm not sure how optional c) really is though.  Depends on how easy
you want to make life for your system administrators to not have to do
a) themselves all the time.

-Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com