- Arch-dev-public - lists.archlinux.org

Re: [arch-dev-public] Next Developer Meeting
by Jeff Mickey 05 Jun '07

05 Jun '07

Wrong address... On 6/5/07, Jeff Mickey <j(a)codemac.net> wrote: > On 6/5/07, Roman Kyrylych <roman.kyrylych(a)gmail.com> wrote: > > I'm fine with any date. > > But can we please speak about time in UTC/GMT timezone? > > Does "at noon EST" == 17 UTC? > > Noon EST = 12 EST = 16 UTC, because UTC isn't on daylight savings ( > summertime period, whatever ). Convert to your own local time from > that. > > Sorry about the father's day thing, I totally forgot. Which reminds > me, I need to find a card or something... > > > // jeff > -- > . : [ + carpe diem totus tuus + ] : . > -- . : [ + carpe diem totus tuus + ] : .

2 1

[arch-dev-public] Random tests.
by eliott 05 Jun '07

05 Jun '07

Just some random information, that I thought I would share. I was taking a look at how much traffic different protocols take to accomplish 2 things. 1) Sync the abs tree with a fresh pull 2) Perform a 'sync-check' (test to see if there are any new changes) with no updates available. http://stdout.cactuswax.net/cactus/tests.txt I was using fresh checkouts, so I don't have any other data other than what appears above. I would like to test some of the protocols against trees that have updates, git repos with more history than fresh imports, and for potential degradation as size increases. I don't know if I will get around to it though. If anyone else is interested in testing such things, then let me know. I would be very interested in the results.

2 1

[arch-dev-public] KVM & Paravirtualization
by Alexander Baldeck 03 Jun '07

03 Jun '07

Hey all, some of you may have noticed that we have a couple of feature requests on flyspray [1] [2] regarding a new KVM and paravirtualization. I've been messing with KVM on Linuxtag. So far it works well but there's a few issues with it: 1) makes no sense to port to non-x86_64 - i686 has kqemu - the kqemu on x86_64 is pretty much useless btw - I have never heard of a 32bit CPU that actually supports this - correct me if I'm wrong 2) it comes with a modified version of Qemu that only provides qemu-system-$CARCH and thus conflicts with qemu itself - merge with qemu package? - strip qemu-system-$CARCH off of qemu package? 3) KVM modules in our kernel26 are very outdated and should be removed in favor of the ones provided by the KVM source tarball 4) split KVM into kvm-qemu & kvm-modules? I have not yet tried to enable options like suggested in [2] yet but will do so soon. What do you think? Cheers, -H [1] http://bugs.archlinux.org/task/7331 [2] http://bugs.archlinux.org/task/7337

6 6

[arch-dev-public] [networking] autowifi
by Thomas Bächler 02 Jun '07

02 Jun '07

With my new laptop and working wireless, I am now able to announce the "autowifi" scripts I wrote a few weeks ago. Requirements: - wpa_supplicant - wifi driver that is supported by wpa_supplicant - dhclient Features: - Automatically select the best network (done by wpa_supplicant) and configure it according to configuration files (done by autowifi) - wifi configuration via wpa_supplicant.conf - dhcp,static or "custom" network configuration via /etc/autowifi/networks/ - default configuration for unknown networks (if a network is not configured, the default behaviour is using dhcp) - same configuration for networks whose essid matches a regex - once configured, it works completely without user interaction, but it _can_ be controlled by wpa_gui (or any other wpa_supplicant client), so that you can access networks without changing wpa_supplicant.conf. I am still unsure whether and how this can be integrated into James' netcfg, that's a question that I'd rather let him answer. That said, autowifi is VERY simple. It doesn't reinvent the wheel by using wpa_supplicant for selecting networks - parsing iwlist outputs doesn't work very well, does it? As all wifi drivers will be moved to mac80211 in the near future, wpa_supplicant-support will not be a restriction anymore. I tested it on iwl3945 and rt2x00-git. The latter has problems scanning and shows very few networks, therefore didn't work very well. I couldn't test it with iwl3945 in an environment with many wireless networks yet, but I trust it works better. HOWTO: - Install the package from http://www.archlinux.org/~thomas/autowifi-svn/ or from svn at http://projects.archlinux.org/svn/autowifi/ - Create /etc/wpa_supplicant.conf and configure all your networks (you can configure anything here, open, WEP, WPA-PSK, WPA-EAP and so on). - Read /etc/autowifi/regex and map ESSIDs to profile names if necessary. - Read /etc/autowifi/networks/example and configure /etc/autowifi/networks/default and /etc/autowifi/networks/profilename if necessary. If you only use dhcp on all networks, no configuration is necessary here. - Adjust the interface and config file name in /etc/conf.d/autowifi properly. - /etc/rc.d/autowifi start (can of course be done via rc.conf) Possible bugs: In my first test, dhcp wouldn't work when I changed networks, maybe I need to delete the dhclient lease file. Any feedback is welcome Thomas

3 6

[arch-dev-public] Flyspray's default project
by Roman Kyrylych 01 Jun '07

01 Jun '07

Is is just me, or Flyspray really shows Pacman project by default? AFAIR it started more than a week ago. That causes users to report bugs in wrong project. Please someone with admin rights fix this. -- Roman Kyrylych (Роман Кирилич)

4 5

Re: [arch-dev-public] nfs-utils 1.1.0
by Tom K 01 Jun '07

01 Jun '07

RedShift wrote: > Tobias Powalowski wrote: >> Am Freitag 01 Juni 2007 schrieb Tom K: >>> RedShift wrote: >>>> I run an NFS server at home, I have no problems testing this for you. I >>>> run arch x86-64 on the server, but a quick makepkg should be no >>>> problem? >>>> >>>> Glenn >>> Thanks Glenn. Yes, x86_64 should not be a problem. You'll find >>> everything you need here: >>> >>> http://www.archlinux.org/~tom/packages/nfs-utils/ >>> >>> If you do have any build problems, I can ask one of the 64 devs to check >>> it out. Otherwise, let me know how you get on after the upgrade. >>> >>> Regards >>> Tom. >>> > > /etc/rc.d/netfs reports failed, but when I look at the mounts no NFS > volumes are mounted anymore. So mount must be returning a non-fatal, but > non-zero exit code. Anyone know how you can echo the return value of a > command from the shell? (bash) > > Glenn > Thanks again. netfs is working as designed on both my clients here, so I have nothing I can work on to debug that. Anything relevant in the server logs? T.

1 0

Re: [arch-dev-public] nfs-utils 1.1.0
by Tom K 01 Jun '07

01 Jun '07

RedShift wrote: > I run an NFS server at home, I have no problems testing this for you. I > run arch x86-64 on the server, but a quick makepkg should be no problem? > > Glenn > Thanks Glenn. Yes, x86_64 should not be a problem. You'll find everything you need here: http://www.archlinux.org/~tom/packages/nfs-utils/ If you do have any build problems, I can ask one of the 64 devs to check it out. Otherwise, let me know how you get on after the upgrade. Regards Tom.

2 1

[arch-dev-public] Goals / Mission Statement
by Aaron Griffin 01 Jun '07

01 Jun '07

Hey all, This has been brought up a few times by Andy, but it seems it's fallen on deaf ears recently. I want to make sure we get this done this time. One of our recent "growing pains" we've had is that there is a certain sense of direction that is unclear. We don't have a clear set of "goals" defined. So lets do that now. Our dev wiki (for the benefit of the subscribed users) contains some ideas which are rather raw. I will strip the names to make things anonymous. Below you will find the points listed in our dev wiki. What I want to do, right now, is flesh this out. We need to define ourselves a clear set of goals. It's important to note that a goal is not "make sure packages go to testing" - that's an implementation detail. A goal is something more ethereal, such as "provide stable, up-to-date software". I would like all of you to read through these (feel free to add your own) and try and list 3-5 of these that you feel are important. On Thursday, I'd like to compile a list of the responses, and we can go through and cherrypick our goals from this subset from everyone - yes this includes those of you without write access to this list. Email me directly, if you want to remain anonymous. Please look these over, and reply with anything you feel is important. Thanks, Aaron ----------------- Dev Wiki Entries ----------------- * Provide the latest software as is practical, while aiming to achieve a reasonable level of stability * Not be dependent on any graphical interface for any system function * Remain a lightweight, general purpose distribution that is simple in it's implementation * Continue to be a strongly community oriented distribution * Provide a good set of reliable and modern Linux technologies for desktop, server and portable PCs * Be equally suitable for home, educational, small business and corporate use * Provide a solid base for creating custom Arch (ISOs and repos) variants for users specific purposes * Remain a "install once, run forever" distribution * Provide good i18n and l10n support * Simple design. Reasoning: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." – Brian W. Kernighan * Vanilla. As few patches as is reasonable to make things play together in the ways necessary, and then primarily as stopgap solutions until things get fixed upstream. This creates predictability and allows smart people with general GNU/Linux knowledge to pick up Arch instantly. It also keeps us from maintaining more and more custom patches over time. * Easy packaging with pacman. The SINGLE thing that will probably keep me from ever leaving Arch is how simple it is to create packages with Pacman. The thought of ever having to write another RPM spec file or something else as obtuse or complicated or ill-conceived as that makes me want to toss my lunch. When I find new software on the Web to help me do my work, I can have it packaged and integrated into my bag of tricks usually in less than an hour. As a result of this simplicity, we have a Community who understands what's going on and can be productively helpful and supportive of each other. * Binary distribution. Unlike Gentoo, we can download and install Firefox on a reasonably fast machine with a reasonably fast link in less than a minute. Also, we test and certify binaries, so quirks of people's machines don't bugger up their compile processes. The result is that after a pacman -Syu, on any machine, most things just work. * This might not be exactly where or what we are, but someone once called Arch a "meta distribution". That is, it gives you tools and a very nice base with which you can do whatever you want. I think this also coincides with 2 of the "goals" I would like to see - that is, (a) like Andy said, we provide a very nice base system and not much more, and (b) "Slackware with pacman" - we get likened to Slackware enough, and I think the simplicity that slackware strives for is ideal for us as well. * I say focus more on the core packages.. the underlying fundamentals. Push the addons higher into the stack. I liken Arch to one of the BSD's, oddly enough. The BSD team focuses on handling the core. They deal with things that come about when the system goes from poweroff to running a base network os. Then ports managers handle the packages that lay on top of this core system. Just a thought.

6 7

[arch-dev-public] problem with community repo db files
by eliott 30 May '07

30 May '07

There is some problem with the script that updates the community db file. I couldn't figure out exactly what the breakage is..other than the script itself not working. As a temporary measure, I manually regenerated the i686 and x86_64 repo db's.

3 3

[arch-dev-public] glibc-2.6/gcc-4.2.0 migration status
by Jan de Groot 29 May '07

29 May '07

Hi all, gcc-4.2.0 and glibc 2.6 have been in testing for a while now. I haven't received many bugs for this one and we still have some small todos open. Please test these packages very carefully, as these packages are very important for everyones system. I added a bug-catcher in flyspray: http://bugs.archlinux.org/task/7295 Please add new bugs for anything new you find that isn't linked to that one. If possible, link it to this bug-catcher. I hope to see gcc 4.2.0 and glibc 2.6 in current very soon after the bugs on that list are fixed.

4 3