- Arch-general - lists.archlinux.org

[arch-general] Problem starting vsftpd service. (Don't Panic)
by Nigel Henry 19 Jun '08

19 Jun '08

On the new instance of Archlinux, that I've installed on my new machine, I wanted to avoid downloading all the updates again on my dialup connection, so thought I'd just FTP the pkg directory from the first install to the new install. For some reason I cannot start the vsftp daemon, just giving me a fail. The capability module is in the modules section of /etc/rc.conf, as is vsftpd in the daemons section. I looked on my first install of Don't Panic, and see the same thing there, and do remember that I had problems with vsftpd, but worked around it by starting gftp in Archlinux, and FTP'ing from another machine FC2, that did have the daemon running. I've worked around it by using fish in KDE's Konqueror on the first install, and have successfully moved the files over to the new install, but would like to find out why vsftpd won't start, and how I can fix it. Thanks for any help. Nigel.

2 2

[arch-general] Problem with Transient resolver failure with pacman (Don't Panic)
by Nigel Henry 19 Jun '08

19 Jun '08

I have Archlinux running on one machine with no problems, but the install was done a while back. I've just installed it on a new machine that I've built, but am having problems running pacman -Sy. The network setup is ok. I use static IP addresses, and everything is correctly set. /etc/resolv.conf has the correct nameserver set, and the gateway 192.168.0.1 in /etc/rc.conf is active by removing the "!". Running pacman -Sy though is constantly giving me a "Transient resolver failure" . Pacman -Sy is trying every mirror on the planet, and must have worked it's way through at least 30 up to now. There must be some setting that I havn't got right. Any suggestions would be most definately gratefully received. Nigel.

3 3

Re: [arch-general] [arch-dev-public] [signoff] initscripts 2008.05-1
by RedShift 19 Jun '08

19 Jun '08

Thomas Bächler wrote: > I think it is time to release this, here are the changes: > > - Remove usbfs special handling from rc.sysinit, for explanation see > http://localhost/git/?p=arch/initscripts/.git;a=commit;h=f3e064ec822b3dae19… > > - Make USEDIRECTISA default to no - this is a change in behaviour > compared to what we had in the past, but it makes more sense like this > - Remove the initrd hacks, this has all been solved more elegantly > with initramfs > - Fix some bug in the network daemon > - Remove the screen blanking setting from rc.sysinit, we don't usually > hardcode such things > - Fix some weird udev issues, hopefully (I have no idea why the fix > works, but it has been confirmed) > - Some random cosmetics/fixes in code and output > > If you want to know it all, look at the git repository. > I was too slow to notice the new initscripts release, but there's a small trivial bug still open for initscripts: http://bugs.archlinux.org/task/10493 "missing depends for initscripts" kbd and findutils need to be added to the depends=() in initscripts. Glenn

3 2

[arch-general] Will Firefox 3 be brought into extra ?
by Allie Daneman 19 Jun '08

19 Jun '08

Will Firefox 3 replace Firefox 2 in a future release ?

12 15

[arch-general] ion3 policy
by Sergej Pupykin 19 Jun '08

19 Jun '08

Hi, All! I forgot which decision was made about ion3 Can I add it into community if I'll update it quickly?

7 7

[arch-general] Dealing with Info documentation
by Frédéric Perrin 17 Jun '08

17 Jun '08

Hello Archlinux, I like reading documentation in the Info format (especially when it is the prefered / only form of documentation). However, Archlinux decides to strip by default the Info documentation from its packages. I am not going to contest that decision, but I'd like to install Info docs. Now, what would be the "good" way to do it ? Installing mannually Info packages ? Patching and locally rebuilding the packages for which I want the documentation ? Creating a PKGBUILD that will install a bunch of docs ? It seems this is the way to go. But what will happen if Arch ever decides to include Info files, how are conflicting files going to be handled ? -- Fred

4 6

[arch-general] Dropping lots of packages
by Vesa Kaihlavirta 16 Jun '08

16 Jun '08

(Answering to Simo Leone's packagedrops in arch-dev-public) > darcs > ghc > happy I can take these to community, although I think ghc should really be in extra. --vk

1 0

[arch-general] Can we use the "Firefox" name?
by Alessio Bolognino 15 Jun '08

15 Jun '08

There is a thing that I have never understood: we ship the Firefox package not branded, for the well known issues with the licensing of the artwork, and that's fine; but are we sure we can name that package "firefox" ? If you ask it to me, I think we can not: Mike Connor (a Mozilla guy :) said here [1]: "Firefox (the name) is equally protected and controlled by the same trademark policy and legal requirements as the Firefox logo. You're free to use any other name for the browser bits, but calling the browser Firefox requires the same approvals as are required for using the logo and other artwork. [...] If you are going to use the Firefox name, you must also use the rest of the branding." Mozilla may say that we are "lying" to users, because the name is named firefox, but it doesn't contain Firefox. Discuss! P.S. I didn't filed a bug report yet because I want to discuss this here. P.P.S Please don't hate me. References: [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354622 -- Alessio (molok) Bolognino Please send personal email to themolok(a)gmail.com Public Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFE0270FB GPG Key ID = 1024D / FE0270FB 2007-04-11 Key Fingerprint = 9AF8 9011 F271 450D 59CF 2D7D 96C9 8F2A FE02 70FB

12 18

[arch-general] [arch-dev-public] maintainers wanted
by Daenyth Blank 15 Jun '08

15 Jun '08

>Take this as a mini-announcement too. I figure that anyone I'd >actually want on board is already following the arch-dev-public list >anyway, so if anyone is interested in maintaining a handful of >packages in [extra], let me know. I'm up for it. I have only i686 boxes at the moment though. Also, would you want me to be using [testing], or is that more on a case-by-case basis? Thanks for your consideration --Daenyth

6 5

[arch-general] Xen for Arch Linux
by RedShift 14 Jun '08

14 Jun '08

Hi all, I've been keeping busy today with Xen for Arch Linux. I've created the following packages: -> This package contains the userland tools to administer a Xen dom0 host. xen-3.2.1-1-i686.pkg http://archserver.be/packages-devel/xen-3.2.1-1-i686.pkg.tar.gz -> This package contains the Xen hypervisor/dom0 kernel. linux-xen-2.6.18_xen_3.2.0-1-i686.pkg http://archserver.be/packages-devel/linux-xen-2.6.18_xen_3.2.0-1-i686.pkg.t… As Xen uses a heavily modified linux kernel, it cannot easily be ported to more current kernel versions. So: 1) You're stuck with whatever hardware 2.6.18 supports 2) We have to use GCC 3.4 to compile this 3) It needs a patch because of using GCC 3.4 (xentime-gcc34.patch) :-( The kernel configuration is currently the default one that comes with Xen. Most drivers are compiled in statically. I plan to update the configuration to match Arch Linux's stock kernel. The kernel package does NOT provide support for running AS A paravirtualized* GUEST. The goal of these packages is make the system run guest OS'es without any modifications. This means you need hardware virtualization support. You can check for hardware VT if you have either vmx or svm (respectively Intel's and AMD's virtualization technology) in /proc/cpuinfo. I do not intend to support paravirtualization (see TODO). I've only tested i686. I can natively run m$ windoze (with networking) on these packages, so the basics work. The xen package should compile and work on x86_64. The linux-xen package has not even been compiled on x86_64 and will not work ATM. I've started a wiki article for Xen too, http://wiki.archlinux.org/index.php/Xen You can grab the PKGBUILDs here: * linux-xen: http://archserver.be/packages-devel/linux-xen.tar * xen: http://archserver.be/packages-devel/xen.tar Still TODO: * x86_64 support * update kernel config to match Arch Linux's stock kernel * finish the wiki article, create an example scenario * fix initscripts for xen package (they are currently in etc/init.d) * paravirtualization: from what I've read, the kernel can be configured to function both as hypervisor and guest. The traditional way is to have two kernels in the distro: one for dom0 and one for domU. It would be great to combine these two - but I'd like some advice on this one. Does it have performance implications? -> If having both dom0 and domU support in the same kernel has no negative side-effects I will support paravirtualization. If it does have side-effects that are unacceptable I will not support paravirtualization. (Paravirtualization is virtualization without hardware support from the CPU. This means the guest OS has to be made compatible with Xen in order to run. This is why you see for example xenU or domU kernels: these are meant to be used inside a Xen domain if the Xen host doesn't have hardware VT) Any feedback is appreciated. Glenn

2 2