- Arch-general - lists.archlinux.org

[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

[arch-general] Junior Developers
by Chris Bannister 18 Nov '10

18 Nov '10

Hi, I remember (a while ago!) reading about junior developers, and at the time I was interested but wasnt using Arch much and busy wish uni, but now I was wondering if there are any further information ? Chris

1 0

[arch-general] wicd startup issues
by Samuel Baldwin 18 Nov '10

18 Nov '10

After a fresh install of wicd (I pacman -Sy'd yesterday), it won't seem to start; not really sure what to do here. arrakis^samuel# wicd Traceback (most recent call last): File "/usr/share/wicd/daemon/wicd-daemon.py", line 56, in <module> from wicd import wpath ImportError: No module named wicd arrakis^samuel# wicd-gtk ** Message: pygobject_register_sinkfunc is deprecated (GtkWindow) ** Message: pygobject_register_sinkfunc is deprecated (GtkInvisible) ** Message: pygobject_register_sinkfunc is deprecated (GtkObject) Traceback (most recent call last): File "/usr/share/wicd/gtk/wicd-client.py", line 61, in <module> from wicd import wpath ImportError: No module named wicd -- Samuel Baldwin - logik.li

5 9

Re: [arch-general] [arch-dev-public] [signoff] openssl 1.0.0.b-2
by Thorsten Töpper 17 Nov '10

17 Nov '10

On Wed, 17 Nov 2010 17:41:59 +1000 Allan McRae <allan(a)archlinux.org> wrote: > On 17/11/10 16:43, Pierre Schmitz wrote: > > On Tue, 16 Nov 2010 18:40:27 +0100, Pierre Schmitz > > <pierre(a)archlinux.de> wrote: > >> Side note: make test does no longer pass with this version. It > >> might be just the test itself that is broken though (tested > >> different arches and also on Ubuntu). But I need to look into this > >> though. > > > > This is now fixed in 1.0.0.b-2. So please sign off that one. > > > > signoff i686. > > Allan Also signoff i686 Thorsten -- Jabber: atsutane(a)freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4

1 1

[arch-general] C++ program compiliation failed
by Nilesh Govindarajan 17 Nov '10

17 Nov '10

Hi, I have three c++ files: main.cpp, and querystring.{h,cpp} querystring.h contains the definition for the QueryString class and querystring.cpp contains the implementation. querystring.cpp and main.cpp both have the statement #include "querystring.h" Now when I run the compiler, I get a weird error- $ g++ main.cpp querystring.cpp -o out /tmp/ccxJ7C28.o: In function `main': main.cpp:(.text+0x3e): undefined reference to `QueryString::QueryString()' collect2: ld returned 1 exit status How am I supposed to compile the program? i.e. in general a multifile program having .hs and .cpps -- Regards, Nilesh Govindarajan Facebook: http://www.facebook.com/nilesh.gr Twitter: http://twitter.com/nileshgr Website: http://www.itech7.com VPS Hosting: http://www.itech7.com/a/vps

4 13