1270
Comment:
|
10841
ports category
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
See also: http://unstable.buildd.net/index-m68k.html |
|
Line 5: | Line 7: |
== Buildds == ||Buildd||Machine||Admin||Buildd Admin|| ||arrakis||Amiga 3000/060||IngoJuergensmann||?|| ||elgar||Amiga 4000/060||IngoJuergensmann||?|| ||vivaldi||Amiga 4000/060||IngoJuergensmann||?|| |
== List of Buildds == ||Buildd||where?||DNS||Machine||Host Admin||Buildd Admin|| ||aahz||private||aahz.debian.net||Amiga 2000, Blizzard2060+SCSI||ChristianSteigies||ChristianSteigies|| ||akire||[[FU-Berlin]]||akire.buildd.net||Amiga 2000, Blizzard2060+SCSI||IngoJuergensmann||JohnPaulAdrianGlaubitz|| ||ara5||[[GPLHost]]||ara5.mirbsd.org||ARAnyM||ThorstenGlaser||ThorstenGlaser|| ||arrakis||private||arrakis.buildd.net||Amiga 3000, Cyberstorm Mk2, SCSI||IngoJuergensmann||WouterVerhelst|| ||crest||[[NMMN]]||crest.debian.net||Amiga4000T, ?||ChristianSteigies||ChristianSteigies|| ||elgar||[[FU-Berlin]]||elgar.debian.net||Amiga 4000, Blizzard2060+SCSI||IngoJuergensmann||JohnPaulAdrianGlaubitz|| ||kullervo||[[NMMN]]||kullervo.debian.net||Amiga 3000UX, Cyberstorm Mk2+SCSI||ChristianSteigies||ChristianSteigies|| ||vivaldi||private||vivaldi.buildd.net||Amiga 4000, Cyberstorm Mk2, A4000 SCSI||IngoJuergensmann||WouterVerhelst|| |
Line 15: | Line 22: |
IngoJuergensmann wrote a blog entry about upgrading from etch-m68k to unstable: [[http://blog.windfluechter.net/content/blog/2011/07/26/1189-upgrading-m68k-etch-m68k-unstable]] The information there is a little bit outdated because of newer packages. You'll need to tweak every now and then with different dependencies and maybe force packages with dpkg --force-depends or --force-all to get installed. It may be necessary, too, that you'll need to download a certain package version from archive.debian.org and even unpack it with ar -x and copy the files to your filesystem. As this is really not recommended and only experienced users should do this: make a backup! It's best to use a second partition on your harddisk, copy over your system and work on that copy/second partition! |
There are these possible ways: * IngoJuergensmann wrote a blog entry about upgrading from etch-m68k to unstable: [[http://blog.windfluechter.net/content/blog/2011/07/26/1189-upgrading-m68k-etch-m68k-unstable]] The information there is a little bit outdated because of newer packages. You'll need to tweak every now and then with different dependencies and maybe force packages with dpkg --force-depends or --force-all to get installed. It may be necessary, too, that you'll need to download a certain package version from archive.debian.org and even unpack it with ar -x and copy the files to your filesystem. As this is really not recommended and only experienced users should do this: make a backup! It's best to use a second partition on your harddisk, copy over your system and work on that copy/second partition! ThorstenGlaser still says that this is '''absolutely not supported by Debian''' and ''will'' most likely fail. Use debootstrap or copy an image instead! * [[M68k/Installing#Debootstrap||Use debootstrap]] on another partition to install a unstable system and boot into it. * [[M68k/Installing#pre-made_filesystems|Get a tarball]] and untar it on one of your partitions. Make the necessary changes to the system like writing an fstab and /etc/hostname, generating SSH keys, create a user and such. == HowTo Setup buildd chroot == On kullervo the system has been set up in partition /dev/sda5. Partition /dev/sda7 is a big empty partition, that we want to use with LVM for the buildd. apt-get install lvm2 # create physical volume pvcreate /dev/sda7 pvscan pvdisplay # create volume group vgcreate kullervo /dev/sda7 vgdisplay # create logical volume lvcreate -L 4G -n buildd kullervo lvscan lvdisplay Now we can use /dev/kullervo/buildd as device in the chroot config below. Note that I chose the VolumeGroup to be called "kullervo" and not "vg" so that I do not run into problems when I swap harddisks and suddenly have two different volumegroups with the same name on the system. == HowTo configure dupload == The upload queue "dports" is not predefied in /etc/dupload.conf (at least in dupload 2.7.0) $cfg{'dports'} = { fqdn => "ports-master.debian.org", incoming => "/incoming", dinstall_runs => 1, passive => 1, }; == HowTo configure schroot & sbuild == * You'll need to install sbuild, schroot and (for later) buildd * create a chroot as described above, for this example we assume it's being located on a LVM under ''/dev/vg/buildd-sid'' (naming the VolumeGroup vg is not recommended if you switch harddisks with a different machine) * create a config entry for that chroot under ''/etc/schroot/chroot.d/sid-m68k-sbuild'': {{{ [sid-m68k-sbuild] type=lvm-snapshot description=Debian sid LVM snapshot groups=sbuild,root,ij root-users=ij,sbuild,buildd root-groups=root,sbuild,ij,buildd source-root-users=ij,sbuild,buildd device=/dev/vg/buildd mount-options=-o atime,sync,user_xattr lvm-snapshot-options=--size 4G }}} * configure ''/etc/sbuild/sbuild.conf'' as needed, i.e. setting the arch to m68k * configure ''˝/.sbuildrc'' as this (example): {{{ # # example for ~/.sbuildrc # commented out stuff are defaults # # $Id: example.sbuildrc,v 1.2 2000/03/09 13:13:16 rnhodek Exp $ # Require chrooted building? #$chroot_only=1; $fakeroot = "fakeroot"; # Directory for writing build logs to $log_dir = "$HOME/logs"; # Mail address where logs are sent to (mandatory, no default!) # this moved to .builddrc... $mailto = '%%buildd-admin%%@example.org,logs@buildd.debian.org'; $mailfrom = "buildd\@%%yourhost%%.example.org"; # Maintainer name to use in .changes files (mandatory, no default!) $maintainer_name='debian/m68k buildd <buildd@%%yourhost%%.example.org>'; # When to purge the build directory afterwards; possible values are "never", # "successful", and "always" $purge_build_directory="successful"; # After that time (in minutes) of inactivity a build is terminated. Activity # is measured by output to the log file. $stalled_pkg_timeout = 600; # Some packages may exceed the general timeout (e.g. redirecting output to # a file) and need a different timeout. Below are some examples. require "/home/buildd/globals/sbuildrc-timeout"; $sbuild_mode = "buildd"; #%alternatives = ( # svgalibg1-dev => svgalib-dummyg1, # libmotif-dev => lesstif2-dev #); $apt_update = 0; $apt_distupgrade = 0; $apt_upgrade = 0; # don't remove this, Perl needs it: 1; }}} * generate an sbuild key with ''sbuild-update --genkey''. I did this as root as well as buildd user, because I didn't know which key is used and I wanted to be safe. But I guess you'll just generate the system sbuild key as root. * try to build by using ''sbuild -d unstable -c sid-m68k-sbuild <package_version>'' and keep an eye on the build logs. * if package built fine without problems, you may proceed to configure the buildd itself: == HowTo configure buildd == Wouter wrote in a mail to debian-68k list this: {{{ Now, while it's still fresh in my memory, for those of you who want to set things up, here's a (not so) short HOWTO: - First, set up sbuild so it can build packages. This has changed fairly significantly since the old days, so you'll have to learn all over again. Since Ingo set that up on arrakis, I'm afraid I can't help here, but he said he'd mail his explanation some time soon. Important: make sure the 'schroot' chroot name follows the following pattern: <dist>-<arch>-sbuild e.g., sid-m68k-sbuild otherwise buildd won't find the chroot and can't build. - Install buildd. Note that 'buildd.conf' has been renamed, you should now use ~buildd/.builddrc instead. A template configuration file looks like this: --->8--->8--- @distributions = ( { dist_name => [ "sid" ], built_architecture => 'm68k', wanna_build_ssh_host => "buildd.debian.org", wanna_build_ssh_user => "buildd_m68k", wanna_build_ssh_socket => "buildd.debian.org.ssh", wanna_build_ssh_options => [], wanna_build_db_user => "buildd_m68k-arrakis", dupload_local_queue_dir => "upload", no_auto_build => [], weak_no_auto_build => [], logs_mailed_to => 'wouter@debian.org,logs@buildd.debian.org', sign_with => "96DC703F", }, ); @upload_queues = ( { dupload_local_queue_dir => "upload", dupload_archive_name => "dports", }, ); my $autoclean_interval = 86400; my $secondary_daemon_threshold = undef; $admin_mail = "wouter\@debian.org"; $statistics_mail = $admin_mail; # How many days until archiving build logs my $buildd_log_keep = 7; # Log successful messages from upload queue daemon? my $log_queued_messages = 1; # Send rotated daemon.log files? $daemon_log_send = 1; # Arrakis is a dedicated daemon, it shouldn't need nice $nice_level = 0; my $max_build = 1; # Ask whether packages should be built if they failed earlier? $should_build_msgs = 0; # Don't remove this, Perl needs it 1; ---8<---8<--- Yes, that means we can specify more than one distributions with more than one target upload queue. On debian.org machines, this is used to build for unstable, experimental, backports, and security, all from the same host. Obviously you'll want to change the values of logs_mailed_to, wanna_build_db_user, and $admin_mail :-) - Add a cronjob for schroot -c source:sid-m68k-sbuild -- apt-get update and have it run every six hours, but *not* at 6-12-18-24, because that's just *before* the archive run. This is because 'apt-get update' takes about 25 minutes these days, and otherwise it'll try to do that for *every* build, which isn't always necessary. With this, it'll do it as often as debian-ports gets updated; much more useful. Note the source: bit in the schroot command line, it means you don't want schroot to create a snapshot that it'll throw away after you log out (fairly crucial for what we want to do here) - Patch /usr/share/perl5/Buildd/Daemon.pm, find the line that says '--apt-update' and change it into '--no-apt-update'. I'll file a bugreport in a minute so that isn't hardcoded anymore, but for now you'll have to do that. - Generate a GPG key with: - 4096 bits RSA - expiry set to 1 year - no password You do *not* want to do this on the m68k; generate it on a faster machine, and use 'gpg --export-secret-key' to copy it over to the m68k. Otherwise you'll be at it for hours. Note that --export-secret-key doesn't export the public key, you have to use --export-key for that. Use --import on the m68k machine to import both files there. Don't forget to gpg --delete-secret-key it from your other machine (don't want to needlessly increase the attack surface) - Sign the GPG key with your own GPG key (the one that you can use to do debian.org uploads with) - Change the value of 'sign_with' in .builddrc to the key ID of the GPG key that you just generated. - Upload the GPG key to some keyserver somewhere. - Generate an SSH key (if that has not already been done) - Send a mail to aurelien with GPG fingerprint, SSH public, and mail forward address - Install buildd-watcher and buildd-uploader in cron, as before. - Profit! }}} ---- CategoryPorts |
See also: http://unstable.buildd.net/index-m68k.html
Information about M68k Autobuilder
Autobuilder (aka Buildds) are machines that automatically build packages from source packages. The M68k port is using several autobuilders for that purpose.
List of Buildds
Buildd |
where? |
DNS |
Machine |
Host Admin |
Buildd Admin |
aahz |
private |
aahz.debian.net |
Amiga 2000, Blizzard2060+SCSI |
?ChristianSteigies |
?ChristianSteigies |
akire |
?FU-Berlin |
akire.buildd.net |
Amiga 2000, Blizzard2060+SCSI |
?IngoJuergensmann |
?JohnPaulAdrianGlaubitz |
ara5 |
ara5.mirbsd.org |
ARAnyM |
|||
arrakis |
private |
arrakis.buildd.net |
Amiga 3000, Cyberstorm Mk2, SCSI |
?IngoJuergensmann |
|
crest |
?NMMN |
crest.debian.net |
Amiga4000T, ? |
?ChristianSteigies |
?ChristianSteigies |
elgar |
?FU-Berlin |
elgar.debian.net |
Amiga 4000, Blizzard2060+SCSI |
?IngoJuergensmann |
?JohnPaulAdrianGlaubitz |
kullervo |
?NMMN |
kullervo.debian.net |
Amiga 3000UX, Cyberstorm Mk2+SCSI |
?ChristianSteigies |
?ChristianSteigies |
vivaldi |
private |
vivaldi.buildd.net |
Amiga 4000, Cyberstorm Mk2, A4000 SCSI |
?IngoJuergensmann |
HowTo Setup/Upgrade A Buildd from Etch-m68k to Unstable
There are these possible ways:
?IngoJuergensmann wrote a blog entry about upgrading from etch-m68k to unstable: http://blog.windfluechter.net/content/blog/2011/07/26/1189-upgrading-m68k-etch-m68k-unstable The information there is a little bit outdated because of newer packages. You'll need to tweak every now and then with different dependencies and maybe force packages with dpkg --force-depends or --force-all to get installed. It may be necessary, too, that you'll need to download a certain package version from archive.debian.org and even unpack it with ar -x and copy the files to your filesystem. As this is really not recommended and only experienced users should do this: make a backup! It's best to use a second partition on your harddisk, copy over your system and work on that copy/second partition!
ThorstenGlaser still says that this is absolutely not supported by Debian and will most likely fail. Use debootstrap or copy an image instead!
M68k/Installing#Debootstrap on another partition to install a unstable system and boot into it.
Get a tarball and untar it on one of your partitions. Make the necessary changes to the system like writing an fstab and /etc/hostname, generating SSH keys, create a user and such.
HowTo Setup buildd chroot
On kullervo the system has been set up in partition /dev/sda5. Partition /dev/sda7 is a big empty partition, that we want to use with LVM for the buildd.
apt-get install lvm2
# create physical volume pvcreate /dev/sda7 pvscan pvdisplay
# create volume group vgcreate kullervo /dev/sda7 vgdisplay
# create logical volume lvcreate -L 4G -n buildd kullervo lvscan lvdisplay
Now we can use /dev/kullervo/buildd as device in the chroot config below. Note that I chose the ?VolumeGroup to be called "kullervo" and not "vg" so that I do not run into problems when I swap harddisks and suddenly have two different volumegroups with the same name on the system.
HowTo configure dupload
The upload queue "dports" is not predefied in /etc/dupload.conf (at least in dupload 2.7.0)
$cfg{'dports'} = {
fqdn => "ports-master.debian.org", incoming => "/incoming", dinstall_runs => 1, passive => 1,
};
HowTo configure schroot & sbuild
- You'll need to install sbuild, schroot and (for later) buildd
create a chroot as described above, for this example we assume it's being located on a LVM under /dev/vg/buildd-sid
(naming the ?VolumeGroup vg is not recommended if you switch harddisks with a different machine)
create a config entry for that chroot under /etc/schroot/chroot.d/sid-m68k-sbuild:
[sid-m68k-sbuild] type=lvm-snapshot description=Debian sid LVM snapshot groups=sbuild,root,ij root-users=ij,sbuild,buildd root-groups=root,sbuild,ij,buildd source-root-users=ij,sbuild,buildd device=/dev/vg/buildd mount-options=-o atime,sync,user_xattr lvm-snapshot-options=--size 4G
configure /etc/sbuild/sbuild.conf as needed, i.e. setting the arch to m68k
configure ˝/.sbuildrc as this (example):
# # example for ~/.sbuildrc # commented out stuff are defaults # # $Id: example.sbuildrc,v 1.2 2000/03/09 13:13:16 rnhodek Exp $ # Require chrooted building? #$chroot_only=1; $fakeroot = "fakeroot"; # Directory for writing build logs to $log_dir = "$HOME/logs"; # Mail address where logs are sent to (mandatory, no default!) # this moved to .builddrc... $mailto = '%%buildd-admin%%@example.org,logs@buildd.debian.org'; $mailfrom = "buildd\@%%yourhost%%.example.org"; # Maintainer name to use in .changes files (mandatory, no default!) $maintainer_name='debian/m68k buildd <buildd@%%yourhost%%.example.org>'; # When to purge the build directory afterwards; possible values are "never", # "successful", and "always" $purge_build_directory="successful"; # After that time (in minutes) of inactivity a build is terminated. Activity # is measured by output to the log file. $stalled_pkg_timeout = 600; # Some packages may exceed the general timeout (e.g. redirecting output to # a file) and need a different timeout. Below are some examples. require "/home/buildd/globals/sbuildrc-timeout"; $sbuild_mode = "buildd"; #%alternatives = ( # svgalibg1-dev => svgalib-dummyg1, # libmotif-dev => lesstif2-dev #); $apt_update = 0; $apt_distupgrade = 0; $apt_upgrade = 0; # don't remove this, Perl needs it: 1;
generate an sbuild key with sbuild-update --genkey. I did this as root as well as buildd user, because I didn't know which key is used and I wanted to be safe. But I guess you'll just generate the system sbuild key as root.
try to build by using sbuild -d unstable -c sid-m68k-sbuild <package_version> and keep an eye on the build logs.
- if package built fine without problems, you may proceed to configure the buildd itself:
HowTo configure buildd
Wouter wrote in a mail to debian-68k list this:
Now, while it's still fresh in my memory, for those of you who want to set things up, here's a (not so) short HOWTO: - First, set up sbuild so it can build packages. This has changed fairly significantly since the old days, so you'll have to learn all over again. Since Ingo set that up on arrakis, I'm afraid I can't help here, but he said he'd mail his explanation some time soon. Important: make sure the 'schroot' chroot name follows the following pattern: <dist>-<arch>-sbuild e.g., sid-m68k-sbuild otherwise buildd won't find the chroot and can't build. - Install buildd. Note that 'buildd.conf' has been renamed, you should now use ~buildd/.builddrc instead. A template configuration file looks like this: --->8--->8--- @distributions = ( { dist_name => [ "sid" ], built_architecture => 'm68k', wanna_build_ssh_host => "buildd.debian.org", wanna_build_ssh_user => "buildd_m68k", wanna_build_ssh_socket => "buildd.debian.org.ssh", wanna_build_ssh_options => [], wanna_build_db_user => "buildd_m68k-arrakis", dupload_local_queue_dir => "upload", no_auto_build => [], weak_no_auto_build => [], logs_mailed_to => 'wouter@debian.org,logs@buildd.debian.org', sign_with => "96DC703F", }, ); @upload_queues = ( { dupload_local_queue_dir => "upload", dupload_archive_name => "dports", }, ); my $autoclean_interval = 86400; my $secondary_daemon_threshold = undef; $admin_mail = "wouter\@debian.org"; $statistics_mail = $admin_mail; # How many days until archiving build logs my $buildd_log_keep = 7; # Log successful messages from upload queue daemon? my $log_queued_messages = 1; # Send rotated daemon.log files? $daemon_log_send = 1; # Arrakis is a dedicated daemon, it shouldn't need nice $nice_level = 0; my $max_build = 1; # Ask whether packages should be built if they failed earlier? $should_build_msgs = 0; # Don't remove this, Perl needs it 1; ---8<---8<--- Yes, that means we can specify more than one distributions with more than one target upload queue. On debian.org machines, this is used to build for unstable, experimental, backports, and security, all from the same host. Obviously you'll want to change the values of logs_mailed_to, wanna_build_db_user, and $admin_mail :-) - Add a cronjob for schroot -c source:sid-m68k-sbuild -- apt-get update and have it run every six hours, but *not* at 6-12-18-24, because that's just *before* the archive run. This is because 'apt-get update' takes about 25 minutes these days, and otherwise it'll try to do that for *every* build, which isn't always necessary. With this, it'll do it as often as debian-ports gets updated; much more useful. Note the source: bit in the schroot command line, it means you don't want schroot to create a snapshot that it'll throw away after you log out (fairly crucial for what we want to do here) - Patch /usr/share/perl5/Buildd/Daemon.pm, find the line that says '--apt-update' and change it into '--no-apt-update'. I'll file a bugreport in a minute so that isn't hardcoded anymore, but for now you'll have to do that. - Generate a GPG key with: - 4096 bits RSA - expiry set to 1 year - no password You do *not* want to do this on the m68k; generate it on a faster machine, and use 'gpg --export-secret-key' to copy it over to the m68k. Otherwise you'll be at it for hours. Note that --export-secret-key doesn't export the public key, you have to use --export-key for that. Use --import on the m68k machine to import both files there. Don't forget to gpg --delete-secret-key it from your other machine (don't want to needlessly increase the attack surface) - Sign the GPG key with your own GPG key (the one that you can use to do debian.org uploads with) - Change the value of 'sign_with' in .builddrc to the key ID of the GPG key that you just generated. - Upload the GPG key to some keyserver somewhere. - Generate an SSH key (if that has not already been done) - Send a mail to aurelien with GPG fingerprint, SSH public, and mail forward address - Install buildd-watcher and buildd-uploader in cron, as before. - Profit!