- Arch-general - lists.archlinux.org

[arch-general] Archlinux hypervisor
by C Anthony Risinger 23 Nov '10

23 Nov '10

fellow patrons, i am moving my company's in house platforms off of a mix of deprecated soft virtualization solutions like openvz and bare metal installs -- i have decided on using libvirt + kvm (in conjunction with cgroups for qemu and possibly other uses). i'm trying to use Arch for the host/hypervisor setups, for a couple reasons: ) very easy to roll custom initramfs builds ) shooting for a < 128MB 100% in-RAM diskless image (RHEV-H or ESXi) ) host is changed infrequently, and all-at-once (no need for ongoing/stable repo support) ) i'm very familiar with Arch's initramfs setup, and with Arch in general the other possibility i'm considering is Gentoo, but it's been quite some time since i've used it :-/. neither arch nor gentoo will be used for guests (likely debian/ubuntu here). does anyone have any experience/insight here? the comparable technology for RHEV-H for redhat, or ESXi for vmware. i am looking into the `archboot` setup for inspiration on a custom initramfs build system. primarily i'm just look for any pointers/information anyone may find useful, not only on the image itself but also management and configuration techniques. thanks, C Anthony

2 2

[arch-general] Acceptable for AIF to copy files?
by Matthew Gyurgyik 21 Nov '10

21 Nov '10

Hello I want to add extlinux support in AIF. However, unlike grub, where grub-install takes care of everything, extlinux requires /boot/syslinux to be created and some files from /usr/lib/syslinux to be copied to /boot/syslinux. Initially I though that creating a extlinux pkg that would include the needed file in /boot would be a good idea. Needless to say, there is mixed opinion on this. See link for more info: https://bugs.archlinux.org/task/21766 So... Is it acceptable for AIF to create /boot/syslinux and copy files from /usr/lib/syslinux to /boot/syslinux? Do we only want to let pacman and upstream install tools create directories and copy files during the install process? ~pyther

2 1

[arch-general] [signoff] lvm2/device-mapper 2.02.76-1
by Eric Bélanger 21 Nov '10

21 Nov '10

Hi, lvm2/device-mapper 2.02.76-1 are in testing. Please test and signoff. Signoffs from users are welcome. - Minor upstream update. ChangeLog below. Version 2.02.76 - 8th November 2010 =================================== Clarify error messages when activation fails due to activation filter use. Add pacemaker script VolumeGroup.ocf with configure --enable-ocf. Import make.tmpl into include/ Makefile. Fix handling of online filesystem resize (using new fsadm return code). Add DIAGNOSTICS section to fsadm man page. Modify fsadm to return different status code for check of mounted filesystem. Update VG metadata only once in vgchange when making multiple changes. Allow independent vgchange arguments to be used together. Automatically unmount invalidated snapshots in dmeventd. Suppress some superfluous messages from clang static analysis. Fix a deadlock caused by double close in clvmd. Fix NULL pointer dereference on too-large MDA error path in _vg_read_raw_area. Use static for internal _align_chunk() and _new_chunk() from pool-fast.c. Fix vgchange to process -a, --refresh, --monitor and --poll like lvchange. Add lvm2app functions to query any pv, vg, or lv property / report field. Version 1.02.57 - 8th November 2010 =================================== Fix regex optimiser not to ignore RHS of OR nodes in _find_leftmost_common. Add dmeventd -R to restart dmeventd without losing monitoring state. (1.02.56) Fix memory leak of field_id in _output_field function. Allocate buffer for reporting functions dynamically to support long outputs.

2 1

[arch-general] Wireshark 1.4.2 stops capturing packets
by mwnn 21 Nov '10

21 Nov '10

Hi all, After capturing a random number of packets, the new wireshark-1.4.2 stops capturing packets. Regards, mwnn

3 3

[arch-general] netcfg update & bug fixes
by James Rayner 21 Nov '10

21 Nov '10

Hi all, I've fixed most (~14) of the bugs from flyspray for netcfg. I have not implemented any feature requests yet. The code is available here: git://github.com/iphitus/netcfg-updates.git PKGBUILD and package here: http://rayner.id.au/~iphitus/netcfg-git/ I have yet to test many of them, but net-auto-wireless works on my laptop. James

1 0

Re: [arch-general] [arch-dev-public] Boot loaders in core/base
by Matthew Gyurgyik 20 Nov '10

20 Nov '10

On 11/20/2010 05:27 AM, Pierre Schmitz wrote: > Hi, > > while reviewing the core rebuild list I wondered if we should think > about chaining our default boot loader. Note: that wont affect existing > setups and people will still be able to use whatever they like. > > ATM. we have grub1 in core/base and install that by default. The > problem is that this project is virtually dead for a long time now and > also not available on x86_64. Technically it has to be in the multilib > repo. > > Grub2 is currently in extra. Upstream development is still in flux. > Imho its quite heavy and complex. > > An alternative successor would be extlinux from the syslinux package. > It's very simple, easy to configure, actively maintained and reliable. > Sure, it only supports booting from ext* and btrfs afaik but to be > honest, if you use any other FS you should have a separate /boot even > when using grub. > > Summing up my suggestion for some time in the future would be: > * move extlinux/syslinux to core/base > * move grub1 to extra/multilib and remove it from base group > * keep grub2 in extra > * maybe also move lilo to extra > * of course keep all of them on the install cd > > What do you think about this? At some point it might not be > sane/possible to keep grub1 as our default boot loader. > > Greetings, > > Pierre > I was thinking about how we could integrate extlinux into the installer and have suggested creating an additional package called extlinux. This package would would include an example config and a few *.c32 file needed to make the config work. As a result, the installer would just have to modify the example config and run extlinux --install /boot/syslinux. As an added bonus, it makes things easier for the end user (/boot/syslinux doesn't need to be created and *.c32 files don't need to be copied to /boot/syslinux). I have all the juicy details and an explanation here: https://bugs.archlinux.org/task/21766 ~pyther

1 0

Re: [arch-general] [arch-dev-public] Boot loaders in core/base
by Heiko Baums 20 Nov '10

20 Nov '10

Am Sat, 20 Nov 2010 11:27:35 +0100 schrieb Pierre Schmitz <pierre(a)archlinux.de>: > ATM. we have grub1 in core/base and install that by default. The > problem is that this project is virtually dead for a long time now and > also not available on x86_64. Technically it has to be in the multilib > repo. I'm running a x86_64 system and have grub1 installed without any lib32 dependencies. So, of course it's available on x86_64. Why shall this be moved to [multilib]? > An alternative successor would be extlinux from the syslinux package. > It's very simple, easy to configure, actively maintained and reliable. > Sure, it only supports booting from ext* and btrfs afaik but to be > honest, if you use any other FS you should have a separate /boot even > when using grub. This would be a massive regression because there are several people who are using reiserfs and other filesystems. And what has a separate /boot partition to do with the bootloader and the filesystem? You can use almost every filesystem on the /boot partition. The best would be if every available bootloader would be moved to [core] and supported by AIF, so that the user can decide during the installation which bootloader fits best to him and which bootloader shall be installed, because there's currently no bootloader which can do everything. Depending on the partition scheme and the used filesystem a different bootloader is needed. And simultaneously every filesystem related package incl. btrfs-utils e.g. should be moved to [core] and supported by AIF, too. So that the user can decide during the installation how he wants to partition and format his drives and which filesystem he wants to use. > Summing up my suggestion for some time in the future would be: > * move extlinux/syslinux to core/base Good idea. > * move grub1 to extra/multilib and remove it from base group Bad idea and doesn't make much sense until there is a real equivalent alternative. It's still the most used bootloader I guess. > * keep grub2 in extra Should go to [core], too. > * maybe also move lilo to extra Not the best idea, too. > * of course keep all of them on the install cd Good idea again. But on the install CD there are only [core] packages as far as I know which makes sense. So all these packages should be moved to [core]. > What do you think about this? At some point it might not be > sane/possible to keep grub1 as our default boot loader. But I don't see this point, yet. It will be sometime in the future when there's a real alternative which can boot from every possible partition scheme and filesystem. Heiko

6 6

Re: [arch-general] [arch-dev-public] mailx package
by Marek Otahal 19 Nov '10

19 Nov '10

On Friday 19 of November 2010 21:44:13 Allan McRae wrote: > Hi, > > I was looking at the mailx package and was wondering what we should do > with it. > > We grab the package source for "mailx-8.1.1-fixed" on > ftp.archlinux.org... but I have no idea what is "fixed" about it and we > still patch the Makefile and for gcc-4. It also does not use our > CFLAGS/LDFLAGS when building. > > There are options here: > > 1) grab "updated" cvs snapshot from OpenBSD, which is apparently where > Debian gets it from. I'm not sure where exactly the cvs repo is though... > > 2) use heirloom-mailx (a.k.a. nail). At least I can find a tarball from > that, even if it has not seen a release in a couple of years. This was > requested in the bug tracker but was closed dues to no-one being > motivated to change it after several years. > > 3) use GNU mailutils. It looks actively developed (had a release in > September), and is apparently fully compatible. However, it also has > more features and so is not as lightweight... probably going from 100KB > to 1MB. > Personally I'd like the actively developed mailutils the best. Btw, thank you Allan for doing the [core] rebuild, i've read the thread and feels good to me that someone rebuilds the old packages with new tools. Mark > Opinions? > > Allan -- Marek Otahal :o)

1 0

[arch-general] MIT Kerberos?
by Kaiting Chen 19 Nov '10

19 Nov '10

Does anyone know if MIT kerberos is a drop-in replacement for Heimdal? It seems more actively developed and more featureful than Heimdal these days. I'm pretty sure cryptographic export as munitions is no longer an issue for the US. Perhaps it would even make sense to try to transition to MIT? --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

3 3

Re: [arch-general] [arch-dev-public] [extra] repository cleanup
by Heiko Baums 19 Nov '10

19 Nov '10

Am Sat, 13 Nov 2010 14:46:30 +0100 schrieb Andrea Scarpino <andrea(a)archlinux.org>: > On Thursday 11 November 2010 22:54:36 Roman Kyrylych wrote: > > I adopted some (and edited the page). > Nice, today we have 291 orphans packages in [extra] (they were 352 > three days ago). 62 will be moved to [community]. 127 to AUR. > > I didn't expect this success. I can start moving them today if you > agree. > <AUR> > ding > galculator > gift > gift-fasttrack > gift-gnutella > gift-openft > gimp-fourier > gtklp > hexcurse > httrack > pan > screem > tcptraceroute Nice, then I would need to install 110 packages from AUR and compile them manually. When I switched to Arch Linux about 3 years ago it was less than 50. When will the so called "binary distribution" Arch Linux become a second Gentoo, a pure source based distribution, because "no developer is interested in maintaining" anything anymore? Btw., PKGBUILDs also in AUR need to be maintained. Really sad this progress and this massive and pointless cleanup. Those packages are also quite common and important: > eboard > gdesklets > lincity > pure-ftpd > tcsh > tin I guess there are some more in your list. Also squashfs-utils which is "degraded" to community belongs to [extra] because it is necessary for building LiveCDs as far as I know. You really should reconsider this cleanup. You should consider that such a distribution - and Arch Linux isn't a small and unimportant distro anymore - is not only about some personal preferences of the developers. Developers of such a binary distro should also maintain packages which they are not using themselves. And, btw., funny enough was ding updated recently although it was orphaned. I wouldn't say anything if you would cleanup the official repos from unnecessary, unimportant and unused or hardly used packages like some ttf fonts, GTK1 themes, etc. But there are too many, too important packages in your list which definitely belong into the official binary repos and which are in the official binary repos of every other binary distribution. Heiko

12 22