[arch-releng] from now on: automatic testbuilds + heads-up on changes
Hi, I want to inform you of two things: 1) new testbuilds available! A whole bunch of changes, both in the actual build environment, as well as AIF itself, where the changes are mostly related to how we automatically export configuration to the target system (locales, networking, initcpio, etc). for users, the main thing to remember is that we now always export the network config to the target system, whereas we used to ask for confirmation before. actually, so much has changed that despite my own tests it would suprise me if i already found/fixed all the regressions. for hackers: the aif code is now more readable :) Please have a look at the changelog: http://releng.archlinux.org/isos/Changelog Known issues: - when selecting source 'net', "install packages" won't realize the step has completed successfully. so you can do only do core installs, but the fix is already in git and will be on the next images. - some kind of kernel/vbox bug wrt virtual memory: http://mailman.archlinux.org/pipermail/arch-general/2011-January/017713.html - btrfs-progs, nilfs-utils and dosfstools packages cannot be installed to the target system (although you should be able to use those FS'es fine) 2) automatic builds: from now on, there will be automatic builds available @ http://releng.archlinux.org/isos/ i'm still playing around with the parameters, probably the builds will be daily or weekly. I would appreciate it if people could test these images and post their findings. Checklist of things which need to be verified. (when you test, you can obviously verify as many things as you want in one run) * dual arch image boot (pick your arch of preference at boot) * i686 image boot * x86_64 image boot * pxe boot * automatic install generic example * automatic install fancy example * net install manual spec (check that it works + rc.conf, resolv.conf, mirrorlist) * net install dhcp (check that it works + rc.conf) * core install * autoprepare (check the installed system, incl fstab) * manual partitioning/FS (with optionally: encryption, nilfs2, lvm,btrfs). (check also fstab, menu.lst, initcpio.conf and crypttab if appropriate) * doing a rollback and re-doing autoprepare or manual config TODO: - some kind of web app /wiki page where users can mark things in the checklist as "working with testbuild $version" ? that would give a good indication of when we can promote testbuilds to official releases - some way to give these more visibility (post to al.org frontpage? can we mirror first?..?) Dieter
Am 03.01.2011 16:31, schrieb Dieter Plaetinck:
Known issues: - some kind of kernel/vbox bug wrt virtual memory: http://mailman.archlinux.org/pipermail/arch-general/2011-January/017713.html
Vbox always did weird and unexplainable things that I could never work around, other than upgrading either Linux or Vbox.. You will probably notice that KVM works fine.
- btrfs-progs, nilfs-utils and dosfstools packages cannot be installed to the target system (although you should be able to use those FS'es fine)
That reminds me, I was going to reply to the whole core-repo definition discussion. Anyway, those need to go to core if you want to install them upon installation. I am confused about dosfstools, there is no fsck tool that does anything useful, so installing them is not really a requirement.
2) automatic builds: from now on, there will be automatic builds available @ http://releng.archlinux.org/isos/ i'm still playing around with the parameters, probably the builds will be daily or weekly.
In the long run, I'd say weekly.
- some kind of web app /wiki page where users can mark things in the checklist as "working with testbuild $version" ? that would give a good indication of when we can promote testbuilds to official releases
Official releases? I thought we'd be rolling (=snapshotting) releases from now on.
- some way to give these more visibility (post to al.org frontpage? can we mirror first?..?)
Following what I said above, revamp the download page to point to releng.al.org for ISO downloads.
On Mon, 03 Jan 2011 16:39:21 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
Am 03.01.2011 16:31, schrieb Dieter Plaetinck:
Known issues: - some kind of kernel/vbox bug wrt virtual memory: http://mailman.archlinux.org/pipermail/arch-general/2011-January/017713.html
Vbox always did weird and unexplainable things that I could never work around, other than upgrading either Linux or Vbox.. You will probably notice that KVM works fine.
I don't have virtualisation extensions on my cpu. last time i tried qemu it was much buggier then vbox ;)
- btrfs-progs, nilfs-utils and dosfstools packages cannot be installed to the target system (although you should be able to use those FS'es fine)
That reminds me, I was going to reply to the whole core-repo definition discussion. Anyway, those need to go to core if you want to install them upon installation.
please tell the responsible package maintainers.
I am confused about dosfstools, there is no fsck tool that does anything useful, so installing them is not really a requirement.
2) automatic builds: from now on, there will be automatic builds available @ http://releng.archlinux.org/isos/ i'm still playing around with the parameters, probably the builds will be daily or weekly.
In the long run, I'd say weekly.
- some kind of web app /wiki page where users can mark things in the checklist as "working with testbuild $version" ? that would give a good indication of when we can promote testbuilds to official releases
Official releases? I thought we'd be rolling (=snapshotting) releases from now on.
It is very easy to break an image, be it a change (~git commit) in the releng env, in archiso or in aif. I think this is fine (it allows me to develop quickly), but this also means there can be big differences in quality between builds. I only want selected high-quality releases as default download option for the large audience, because $random_build might be buggy or not even boot. there needs to be a way to separate crappy builds from good ones. call it staging vs production, or testing vs main, or autobuilds vs releases, but there needs to be a way to separate them. this approach would allow that in a non-intrusive and relatively elegant way, I think. It's basically the same as we did before (send mails where you say "please test these builds and check item foo and bar" and people reply), but improved because 1)you can see the current state of things more clearly 2)if feature X worked 2 builds ago, and only unrelated things have changed, that's still valid as a "signoff". Last time I spoke with Aaron, he also said there should be a way to promote images when they deserve it, and offer those as official images.
- some way to give these more visibility (post to al.org frontpage? can we mirror first?..?)
Following what I said above, revamp the download page to point to releng.al.org for ISO downloads.
where did all the "please build new images", "when will you build new images with btrfs/nilfs/..-support" folks go to? Please test the images and let me know how you like them. Dieter
participants (2)
-
Dieter Plaetinck
-
Thomas Bächler