Re: [arch-general] Netbook recommendations
On Tue, Sep 29, 2009 at 3:16 AM, Aaron Griffin wrote: > So in the next few weeks, I would like to buy a netbook. The market is > saturated, so I'd like to ask for some advice here. > > What do you guys think of the current offerings? What's considered > "the best" now-a-days? What kinds of netbooks do Arch users have? > I think Asus are ending this model, so there might be some good sales, but the 1000HE is pretty awesome. Epic battery life (advertised 9.5, real usage ~7-8), surprisingly well built, ok keyboard (not mushy). I'm pretty happy with mine. Only downside is the glossy shell which attracts fingerprints, and the touchpad click button is a little bit stiff, but softens up. Though you dont use touchpad, so no big deal. Comes with a case. If you're looking for a mouse to go with it, logitech have some awesome laser mouse with this tiny little 'nano receiver' that you can just leave plugged into the computer, as it only extends out about 3-4mm. James
Re: [arch-general] CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
> Sascha Siegel schrieb:
>> Hi,
>>
>> can someone tell my whats the reason for building the arch-kernel with
>> "# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set"?
>>
>> Thank you!
>
> Optimizing for size sacrifices performance. Read the gcc documentation
> about the -O{1,2,3,s} options.
I remember a few kernel devs recommending size. It was to reduce the
number of cache misses and improve CPU cache utilisation, avoiding RAM and
L2 cache. Fedora/RHEL appears to optimize for size.
That was a while ago when I was doing some kernel stuff so I could be
wrong.
[arch-general] netcfg v2.5 in [testing] - auto wireless configuration has changed
netcfg v2.5rc1 This is easily the biggest release since 2.0. Many new features and some significant changes under the hood. There are also a few features which have had changed options and this needs to be noted. The most notable is that net-auto has been removed in favour of the net auto wireless setup. # Move to new auto-wireless The new automatic connection has proper roaming support and will prove more reliable than the old setup - particularly with more complicated wireless configurations. To migrate to the new automatic wireless setup: 1. pacman -S core/wpa_actiond 2. Set WIRELESS_INTERFACE="" to your wireless interface in /etc/rc.conf. For example WIRELESS_INTERFACE="wlan0" 3. Add net-auto-wireless to your DAEMONS=() array. # New features: - net-auto-wireless/wpa_actiond - Real wireless roaming/auto connection. Based on same principle as autowifi. Requires optional dependency: wpa_actiond - net-auto-wired - automatic ethernet configuration. Requires optional dependency: ifplugd - Interface configurations - set options for all profiles using an interface - Radio Kill switch awareness - requires enabling, see wiki. - Output hooks - Significant internal cleanup & improvement # Internal changes: - Uses wpa_supplicant for all wireless configuration by default, including wep/none security. This adds improves support for most and should improve reliability. - Uses iproute by default for all static configuration. net_tools which contains ifconfig is effectively obsolete and hasnt seen a release for over 8 years. The 'ethernet-iproute' and 'ethernet' connection types have been merged together to simply 'ethernet'. All options are still supported and existing configurations will continue to work for both types. A symlink has been made to ensure that profiles using 'ethernet-iproute' will continue to function. # Changes in configuration options - net-auto and AUTO_NETWORKS is now deprecated in favour of net-auto-wireless/net-auto-wired. - wireless: If you were previously specifying the wpa_supplicant driver in WPA_OPTS, you now need to specify it in WPA_DRIVER. - wireless: iwconfig based configuration for wep/none can be used by changing to wep-old or none-old. This should not be necessary and is left in place only for the possibility of very old drivers that do not support wpa_supplicant. - ethernet-iproute: Now that 'ethernet' is iproute based, those using 'ethernet-iproute' can change the name back. There is a symlink in place however, so existing configurations of either name will continue to function regardless. - wireless-dbus: This idea didn't really go anywhere and is now unsupported. The wpa_supplicant dbus interface is a huge pain and it doesn't fit well into the netcfg codebase. It is no longer included, however netcfg will automatically use 'wireless' for any 'wireless-dbus' configurations as the supported options are effectively the same. # Download: netcfg 2.5rc1 is in [testing]. The source is on the Arch Linux ftp and latest PKGBUILD in svn. ftp://ftp.archlinux.org/other/netcfg/netcfg-2.5.0rc1.tar.gz # Documentation: The wiki has been updated to reflect this release. For 2.5, the documentation can be found at: http://wiki.archlinux.org/index.php/Network_Profiles_development When it is released this will be moved to the Network Profiles page. There's also some updated documentation of the supported options for 'wireless' and 'ethernet' here: http://www.rayner.id.au/netcfg/ Keep in mind that wireless supports all the options of 'ethernet'. If options are not documented, then it's a bug and they should be (or it's deprecated, but should be mentioned anyway for completeness). # Contributors: I had a few big contributors to this release: Jim Pryor: Many internal changes and improvements Thomas Bächler: wpa_actiond based auto roaming/connection Thanks guys! That's all for now, please file any bug reports on the bug tracker. James
Re: [arch-general] Setting LD_PRELOAD cripples Firefox
On Thu, 03 Dec 2009 21:57 +0100, "ndlarsen" wrote: > Mojn. > > Strange issue here. Intended to use libtrash on my system. I added > export LD_PRELOAD=/usr/lib/libtrash.so.3.2 to /etc/profile to set it > systemwide, LD_PRELOAD pointing to /usr/lib/libtrash.so.3.2 is needed in > order to get libtrash to work - and it did. Here's the bummer, though. > Doing so causes firefox to hang at startup. Any of you ot experinced > this or know the reason? Cheers. > > /ndlarsen https://bugzilla.mozilla.org/show_bug.cgi?id=435683 I've had the same issue with libetc.
Re: [arch-general] suggestion for pacman: Recommended packages.
On Fri, 11 Dec 2009 10:40 +0200, "Hussam Al-Tayeb" wrote: > The current case for many packages that use optdepends is as follows. > Let's say a package called package1 installs some extra binaries or > plugins. Those extra not so used binaries or plugins have extra > dependencies (let's call them libsomething) marked as optdepends. > so on installation pacman will say something: > optional dependency: libsomething needed for package1 plugins to work. > > How about instead those extra binary files or plugins are split into > another package called package1-plugins and have libsomething as plain > dependency? > Then on package1 installation, pacman should say something like: > Recommended packages: package1-plugins for blah blah functionality. This is known as 'debian'. I think it's overkill and offers no practical benefit.
Re: [arch-general] Yet another step toward Arch evil plan
On Wed, 13 Jan 2010 08:00 -0500, "Daenyth Blank" wrote: > On Wed, Jan 13, 2010 at 07:51, ianux wrote: > > They provide ArchLinux 2009.08 in both 32 and 64 bit with > > their own kernel with grsecurity (2.6.31.5-grs) > How well does this integrate? Arch doesn't have any > officially-endorsed grsecurity kernel. Does it require userspace > modifications? Have they submitted their package to Arch so the devs > can look at it and check for flaws? In general, kernel's don't need to integrate with anything, and no changes whatsoever should be necessary in userspace. The exception is when the kernel is too old to be compatible with our udev version. I build my own kernels, not via PKGBUILDs/pacman. They work fine and it's tidy too. Kernels keep to their own directories with the kernel itself a single file in /boot and modules in /lib/modules. James
Re: [arch-general] Netcfg after resume from suspend
On Sun, 31 Jan 2010 00:34 +0100, f...@kokkinizita.net wrote: > On Fri, Jan 29, 2010 at 05:00:04PM +0100, Thomas Bächler wrote: > > > You should try the testing version of netcfg instead: > > http://mirrors.kernel.org/archlinux/testing/os/any/netcfg-2.5.0rc2-1-any.pkg.tar.gz > > Will this allow to specify additional routes (apart > from GATEWAY) as well ? It's one thing I need e.g. > at home where the gateway to the world is the ISP > modem (192.168.1.1), but one of the machines on that > net is also a router to second local network. Yes. That's already available in the current [core] release too. Have a look at /etc/network.d/examples/ethernet-iproute. You can pass an array of iproute options. The example there only sets a static ip and default route, but you can pass as many routes as you like. James
Re: [arch-general] Netcfg after resume from suspend
On Sun, 31 Jan 2010 12:36 +0100, f...@kokkinizita.net wrote: > On Sun, Jan 31, 2010 at 11:37:54AM +1100, James Rayner wrote: > > On Sun, 31 Jan 2010 00:34 +0100, f...@kokkinizita.net wrote: > > > On Fri, Jan 29, 2010 at 05:00:04PM +0100, Thomas Bächler wrote: > > > > > > > You should try the testing version of netcfg instead: > > > > http://mirrors.kernel.org/archlinux/testing/os/any/netcfg-2.5.0rc2-1-any.pkg.tar.gz > > > > > > Will this allow to specify additional routes (apart > > > from GATEWAY) as well ? It's one thing I need e.g. > > > at home where the gateway to the world is the ISP > > > modem (192.168.1.1), but one of the machines on that > > > net is also a router to second local network. > > > > Yes. That's already available in the current [core] release too. > > > > Have a look at /etc/network.d/examples/ethernet-iproute. You can pass an > > array of iproute options. The example there only sets a static ip and > > default route, but you can pass as many routes as you like. > > Yes, but I'm using netcfg for the wireless connection of the > laptop, and AFAICS the "IPCFG" command used in ethernet-iproute > does not work when using the 'wireless' profile. I may be wrong > but have not been able to add any routing to a wireless config. > > The examples seem to assume that wireless implies 1. dhcp, and > 2. just a default gw and not other routes. > > For (1) it is just the examples lacking. But (2) seems to be a > hard-wired limitation. > Oops, you're completely right for the version in [core] - it's been a while since I have used that version. In [testing] you can now use any of the ethernet-iproute options in wireless. Effectively 'ethernet-iproute' doesn't exist, they have been merged into a single 'ethernet' which handles both ifconfig/iproute, with preference for iproute. ifconfig based options are provided purely for backward compatibility. James
Re: [arch-general] EEE 1000H - control of Wifi device
On Thu, 18 Feb 2010 02:19 +0100, f...@kokkinizita.net wrote: > On Wed, Feb 17, 2010 at 05:36:31PM -0600, Aaron Griffin wrote: > > > Isn't this what rfkill is for? > > http://linuxwireless.org/en/users/Documentation/rfkill > > You're right: /sys/devices/platform/eeepc/rfkill/rfkill0/state > controls the wifi device. Problem solved. > > Thanks ! > > -- > FA > > O tu, che porte, correndo si ? > E guerra e morte ! There is some weak support for this in netcfg [testing] that uses that sysfs location. However that sysfs location is deprecated, so I have some lofty plans to update netcfg to the rfkill tool in the next version. James
[arch-general] netcfg v2.5.2 in [core]
netcfg v2.5.2 This release brings a completely new auto wireless/wired configuration. The old net-auto is deprecated and no longer included. There are also some very minor configuration changes that may affect a few people. Move to new auto-wireless/wired The new automatic connection has proper roaming support and will prove more reliable than the old setup - particularly with more complicated wireless configurations. To migrate to the new automatic wireless setup: 1. pacman -S testing/wpa_actiond 2. Set WIRELESS_INTERFACE="" to your wireless interface in /etc/rc.conf. For example WIRELESS_INTERFACE="wlan0" 3. Add net-auto-wireless to your DAEMONS=() array. Note: wpa-config profiles do not work with this, convert them to wpa-configsection profiles. An example is included in /etc/network.d/examples/ The new auto-wired uses similar configuration - follow the above instructions except use the net-auto-wired daemon, and WIRED_INTERFACE configuration option. New features: - net-auto-wireless/wpa_actiond - Real wireless roaming/auto connection. Based on same principle as autowifi. Requires optional dependency: wpa_actiond - net-auto-wired - automatic ethernet configuration. Requires optional dependency: ifplugd - Interface configurations - set options for all profiles using an interface - Output hooks - Internal cleanup & improvement Internal changes: - Uses wpa_supplicant for all wireless configuration by default, including wep/none security. This adds improves support for most and should improve reliability. - Uses iproute by default for all static configuration. net_tools which contains ifconfig is effectively obsolete and hasnt seen a release for over 8 years. The 'ethernet-iproute' and 'ethernet' connection types have been merged together to simply 'ethernet'. All options are still supported and existing configurations will continue to work for both types. A symlink has been made to ensure that profiles using 'ethernet-iproute' will continue to function. Changes in configuration syntax - net-auto and AUTO_NETWORKS is now deprecated in favour of net-auto-wireless/net-auto-wired. - wireless: If you were previously specifying the wpa_supplicant driver in WPA_OPTS, you now need to specify it in WPA_DRIVER. - wireless: iwconfig based configuration for wep/none can be used by changing to wep-old or none-old. This should not be necessary and is left in place only for the possibility of very old drivers that do not support wpa_supplicant. - ethernet-iproute: As 'ethernet' is now iproute based, those using 'ethernet-iproute' can revert the name. There is a symlink in place, so existing configurations of either name will continue to function regardless. - wireless-dbus: Unsupported. The wpa_supplicant dbus interface isn't particularly well documented and it doesn't fit well into the netcfg codebase. There is a symlink in place so that configurations using wireless-dbus will continue to function using the 'wireless' connection scripts. Download: netcfg 2.5.2 is in [core]. Source: ftp://ftp.archlinux.org/other/netcfg/netcfg-2.5.2.tar.gz PKGBUILD: In subversion Documentation: http://wiki.archlinux.org/index.php/Network_Profiles Contributors: I had a few big contributors to this release: Jim Pryor: Many internal changes and improvements Thomas Bächler: wpa_actiond based auto roaming/connection Thanks guys! Bugs: On the bug tracker as always.
Re: [arch-general] [arch-dev-public] initscripts hack-a-thon?
On Tue, 02 Mar 2010 23:29 +0100, "Xavier Chantry" wrote: > On Tue, Mar 2, 2010 at 11:40 AM, Pierre Schmitz > wrote: > > Am Dienstag, 2. März 2010 09:39:19 schrieb Thomas Bächler: > >> Personally, I would like to > >> remove everything but basic ethernet support from initscripts (that > >> would also include removing wireless, but some people were too strictly > >> against that). What I am saying is, investing time into integrating more > >> network stuff into initscripts is time wasted, as complex setups like > >> bonding or bridging can be much better implemented in netcfg and the > >> work should be spent on that instead. > > > > I second this. We should concentrate on netcfg for network setup in future. > > Initscripts will just get too complicated (e.g. they don't support ipv& atm) > > while the same functionality is already provided by another package n core. > > > > I would even completely remove the network and netfs deamon from > > initscripts; > > but I guess there wont be much support for this. :-) > > > > I was saying that already back in 2007, took me just one minute to > find the post :) > http://bbs.archlinux.org/viewtopic.php?pid=274397#p274397 > > Here is what iphitus answered : > "Profiles came after INTERFACES, and INTERFACES will definitely not be > removed. Many people still find them useful, particularly on desktops > with static configurations - myself even. I do intend to increase the > code share between these two, as there's a lot of duplication already, > but that'll come later." > Still think that too, though code-share is not really practical now. rc.d/network has it's place as it is so simple - I still use it on my desktop. I agree with restraining rc.d/network. The wireless support is very outdated already. Bridging/bonding can lead to complexities that rc.d/network is too simple to handle, which is reflected in some of the bug reports.
Re: [arch-general] HAL depreciation
On Wed, 17 Mar 2010 11:16 +0530, "Nilesh Govindarajan" wrote: > > I don't have seven mouse buttons. > The mouse and keyboard is already configured in xorg.conf using > drivers mouse and kbd. > If I stop hal, and then start Xorg, it doesn't work. I've to hard reset > my box. That's because you haven't configured Xorg. Without HAL, you need to create entries in your Xorg.conf regarding mouse/keyboard. This is documented all over the internet, and a new config using Xorg -configure will probably also contain the appropriate lines.
[arch-general] netcfg update & bug fixes
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
Re: [arch-general] [arch-announce] Deprecation of net-tools
That is correct. net-utils could be made an optdepend, or the support could just be removed entirely. IIRC the iproute/netutils code was separate and equivalent. It's been a while since I've looked though. On Thu, 09 Jun 2011 15:11 -0600, "Thomas S Hatch" wrote: > Does netcfg still need net-tools? or can it be an opt depends? It was my > understanding that it only used ip unless specified otherwise. >
Re: [arch-general] [arch-announce] Deprecation of net-tools
On Fri, 10 Jun 2011 08:19 +0200, "Rémy Oudompheng" wrote: > On 2011/6/9 Thomas S Hatch wrote: > > Does netcfg still need net-tools? or can it be an opt depends? It was my > > understanding that it only used ip unless specified otherwise. > > Actually, I think it only depends on net-tools because there is some > obscure option that allows users to make it run ifconfig with certain > options. Of course, it could be replaced by an option that runs ip > with custom options... All the remaining things are indeed done with > iproute2 > > Rémy. netcfg has an option that runs ip/iproute with any custom option (routes, IPs anything), the option is "IPCFG". It may be seen in the example ethernet-iproute[1]. IFCFG is the obscure command you mention, unfortunately it's not too obscure, as this was how static IPs were set before iproute configuration was added. It was retained for backwards compatibility. The only reason net-tools was still a requirement was setting hostname. A change similar to initscripts [2] at line 121 of src/connections/ethernet [3] would suffice. After that it ought to be safe to make net-tools an optional dependency. Systems already using net-tools will keep functioning, and a notice could be placed in code that handles IFCFG to advise those users to migrate to the iproute configuration. [1] http://projects.archlinux.org/initscripts.git/commit/?id=f262299928f1aca454a0bbadbcda144b3fb2e7e2 [2] http://projects.archlinux.org/netcfg.git/tree/src/connections/ethernet#n121 [3] http://projects.archlinux.org/netcfg.git/tree/examples/ethernet-iproute
Re: [arch-general] [arch-announce] Deprecation of net-tools
On Fri, 10 Jun 2011 15:05 +0200, "Tom Gundersen" wrote: > On Fri, Jun 10, 2011 at 2:51 PM, James Rayner > wrote: > > The only reason net-tools was still a requirement was setting hostname. > > A change similar to initscripts [2] at line 121 of > > src/connections/ethernet [3] would suffice. > > What is the reason the hostname is set in netcfg? Do we ever want it > to change from what was set on boot? > > -t > Hostname is only set if someone specifies one in the configuration, otherwise it is left as is. I've never heard of anyone using this option. Judd's original netcfg script from 2005 included this option so I retained it when I wrote netcfg. James
Re: [arch-general] netcfg 2.6 release
On Mon, 20 Jun 2011 03:34 +0200, "Rémy Oudompheng" wrote: > On 2011/6/20 Loui Chang wrote: > > On Sun 19 Jun 2011 23:23 +0200, Rémy Oudompheng wrote: > >> > >> netcfg 2.6 has been released and pushed in [testing]. > >> > >> - /etc/conf.d/netcfg is a new configuration file, currently only used > >> by net-auto-wireless: it is used to configure the name of the wireless > >> interface you want to use (also possible in /etc/rc.conf, but > >> discouraged), and to configure a list of preferred networks you want > >> wpa_actiond to manage (FS#23169) > > > > Should the syntax for this documented in the package somewhere? > > I try to keep the docs/ syntax as updated as possible. Are there > official webpages for projects? other than projects.archlinux.org? > > Rémy. The wiki[1] was the official "how to use netcfg" documentation, while docs/ generally covered the syntax. Regards, James [1] https://wiki.archlinux.org/index.php/Netcfg
Re: [arch-general] [netcfg] Getting rid of wireless_tools
On Sun, 19 Jun 2011 18:13 +0200, "Rémy Oudompheng" wrote: > Hello, > > wpa_supplicant is supposed to provide most of the wireless_tools > functionality. I have set up a branch of netcfg that replaces all uses > of wireless_tools by wpa_supplicant. > > http://projects.archlinux.org/users/remy/netcfg.git/log/?h=no-iwconfig > > iwconfig is still used by the deprecated IWCONFIG option, but there is > still one thing I don't really understand. > > In src/connections/wireless, there is block that calls "iwconfig mode > Managed" before starting wpa_supplicant. The log is not really > explicit about why this was added (it merely says it was necessary for > iwl3945), and wpa_supplicant man page only says it's necessary for the > hostap driver, which we do not use. Does anybody knows the reason why > it is needed? At that time the iwl3945 driver was very new and wpa_supplicant didn't work unless you put the card into managed mode beforehand. Hopefully that's no longer the case - it should be fine to remove that line now. Awesome work with netcfg, it's great to see someone working on it again!
Re: [arch-general] Anything to manage user daemons?
On Mon, 20 Jun 2011 15:15 +0800, "XeCycle" wrote: > Hello. I need to start several programs after login and > after startx. Now I write these directly in my .bash_profile > and .xinitrc; but I'm not satisfied with this. They cannot > be easily stopped after logout. To do that I think I'd > record their PID and kill them in .bash_logout, also need to > take care when they're manually stopped, and all these > related problems. > > So I think a set of scripts like the daemon managing from > initscripts will be nice. But I can't write /etc/rc.d > daemons, as they must be executed by a normal user. > > Has anyone written such a tool? > > Thank you. > Instead of doing exec startx, you can background startx and wait for it, allowing your script to complete and clean things up. I don't know of a specific tool for managing user processes though, however you could "copy" rc.d/? files and amend them for your own usage. ~/.xinitrc: #! /bin/bash start stuff startx & wait $? stop stuff
Re: [arch-general] Change kernel version or module dir at bootprompt?
On Sat, December 1, 2007 04:46, Gerhard Brauer wrote: > Hello, > > i've searched a while and found nothing. And AFAIK there isnt't an > chance to do this. But maybe one of you know a trick, a magic... > > Is it possible to change either the kernel version (what uname -r says) > or the location of the kernel modul dir at boottime? > > I think about an easy solution to backup an arch kernel with it's > modules. > But since the kernel version is fix and releated to the module dir one > could not simply copy /lib/modules/foo.bar to ex. > /lib/modules/foo.bar-backup. > > Anyone knows a trick? the kernel version is also embedded into the individual modules, so you'd have to modify the kernel and every module. You might be able to do some ugly sed trickery, but I really discourage it -- you're asking for trouble.. and it probably won't work. For a 2.6.22 to 2.6.23 type change though, yes you could just backup the kernel and modules before upgrading, upgrade, rename the kernel vmlinuz and put them back again -- though they'd then be out of pacman's control. Why would you want to do something like this anyway?
Re: [arch-general] out-of-date python-cheetah, python-formencode
On Tue, January 29, 2008 10:52, adam wrote: > > The maintainers were contacted but I haven't heard back in several > days. Can we please orphan these packages so that I may have them > updated? > Saturday evening to now isn't long. Nor have you contacted me regarding my package (python-cheetah). It'll be updated soon.
Re: [arch-general] out-of-date python-cheetah, python-formencode
On Tue, January 29, 2008 23:44, adam wrote: > On Jan 28, 2008 11:01 PM, James Rayner <[EMAIL PROTECTED]> wrote: >> On Tue, January 29, 2008 10:52, adam wrote: >> > >> > The maintainers were contacted but I haven't heard back in several >> > days. Can we please orphan these packages so that I may have them >> > updated? >> > >> >> Saturday evening to now isn't long. Nor have you contacted me regarding >> my >> package (python-cheetah). >> >> It'll be updated soon. >> >> >> > > Very well then -- but I assumed using the 'flag-out-of-date' option on > the website and adding additional comments was enough. It was. But give me a chance to update the package before you ask for it to be orphaned!
Re: [arch-general] network manager cannot connect to AP with a hidden ssid
On Fri, Jun 20, 2008 at 6:54 AM, metin <[EMAIL PROTECTED]> wrote: > ? It's just an inherent bit of suckyness with networkmanager. You can try filing a bug with them, but don't expect much response. Or give the 0.7 SVN a go. James
Re: [arch-general] Archlinux Gaming Repository
On Sat, Jun 28, 2008 at 8:02 PM, DaNiMoTh <[EMAIL PROTECTED]> wrote: > 2008/6/28 Chris Bolton <[EMAIL PROTECTED]>: >> Hey all! >> >> A few of us have put together an arch gaming repo, which is basically a >> collection of some of some of the popular games in [unsupported], to >> save archers compilation time. Visit our wiki >> (http://arch-games.twilightlair.net) for more information. >> >> > > Nice project, but I think you should try to be a TU and using community. Some of these aren't able to be put in community. Also... if he hasn't got credentials or demonstrated experience, he'll have a hard time becoming a TU, so this is a good way to get that too! Cheers, James
Re: [arch-general] [arch-dev-public] Multilib on Archlinux x86_64
> It's about the technical purity. It's this that makes us different from the > other distro's. Otherwise we're just on the road to the next ubuntu. And if > you really want 32 bit stuff running on x86-64, just use a 32 bit chroot and > don't bother with the multilib stuff. It's not at all about technical purity. This makes no changes to Arch 64, it's separate. Arch64 remains pure. Technically, it's better than the existing lib32 efforts too. Let's be realistic here. A computer is a tool to be used. Not that great a tool if it doesnt do what you need it to. Some people need flash and other closed source things. +1
Re: [arch-general] [SPAM] [arch-dev-public] two patches for rc.d/network
On Wed, Jul 16, 2008 at 8:12 PM, RedShift <[EMAIL PROTECTED]> wrote: > James Rayner wrote: >> >> 1) 0001-add-some-useful-error-messages-to-wireless-code.patch >> Makes the wireless code in rc.d/network output some useful errors and >> a tad more robust, rather than failing and giving no useful error at >> all. >> >> Not tested yet, I don't have an insecure or WEP network to try it on, >> and the family won't be impressed if I start messing with dd-wrt. I'll >> try tomorrow morning when they're sleeping. >> >> 2) 0002-Added-connection-state-info-to-rc.d-network.patch >> Makes rc.d/network create a file for an interface if it manages to >> connect. Useful for scripts. >> Also needs the directory /var/run/network/interfaces/ created in the >> initscripts PKGBUILD. > > Scripts should use ifconfig or other networking tools that directly read > from the kernel's configuration for network interface information. What if a > user manually modifies his configuration without using the initscripts? Or > does some advanced networking configuration in rc.local? The information in > "/var/run/network" will not be correct. > > I'm going to be blunt, it's a stupid idea. I'm fine with that, and sort of expected it. It's something I've lazily used locally for a little, so I thought I might as well push it upstream. And the other patch? I don't see any reason that shouldn't be merged. James
Re: [arch-general] Anyway to revert back to KDE 3.5.9? (Don't Panic)
On Sat, Aug 9, 2008 at 8:20 AM, Nigel Henry <[EMAIL PROTECTED]> wrote: > Some days ago I ran the updates for my Don't Panic install, which said that > KDE 3.5.9 was being upgraded to KDE4. I let this go ahead having asked on the > list if there were likely to be any problems with KDE4. > > I also have recently installed Fedora 9 which comes with KDE4 as default, so > this is not a pop at Archlinux, but more with KDE4, which I'm finding is > virtually unuseable. I'm posting this from Fedora Core 2, which has KDE > 3.2.2-14.FC2.2.legacy Red Hat, and apart from the odd konqueror crash when > accessing certain web sites, there are no problems. KDE4 is a whole different > ball game. I hear a lot of this, but never any specifics. And a search for KDE or even KDE4 on the bug tracker doesn't bring many bugs up. Not ideal search terms given the amount of apps, but you'd expect more than 10 results for something "virtually unusable" So maybe it'd be a good idea to file bugs about this "virtually unusable" DE.
Re: [arch-general] Anyway to revert back to KDE 3.5.9? (Don't Panic)
On Sun, Aug 10, 2008 at 1:08 AM, Attila <[EMAIL PROTECTED]> wrote: > On Samstag, 9. August 2008 03:35 James Rayner wrote: > >> So maybe it'd be a good idea to file bugs about this "virtually unusable" >> DE. > > I can speak only for me and the whole problems be kde4 at itself why i still > use kdemod3. So if you want bug reports about problems from changes or > problems of the mainstream than you have to say it but i don't think that the > arch bug tracker is the right place for this.-) I don't recall specifying what bug tracker. At least Shridhar got the point, filing bugs at the KDE tracker (they have one too!) *shrug* I'm running KDE4.1 now to see what the fuss is about. I used KDE3 pretty extensively last year, so it'll be an interesting comparison. James
Re: [arch-general] Outdated Wicd
On Mon, Sep 1, 2008 at 8:26 AM, Pyther <[EMAIL PROTECTED]> wrote: > > I have updated the wicd package build, daemon script, and install script. > > All the files are now in /usr /etc and /var using standard paths > > /usr/bin/wicd-client contains both the tray and gui elements now and > /usr/lib/wicd/daemon.py is the daemon. > > I have included the update tar file. > > Hopefully Varun (the maintainer) can use this as a base for the new package. > Anyone who wants the new version of wicd can also use this package. I have > the pkgrel set to 0 so that when an official package comes out pacman will > pick it up. This package works on my system, but of course I can not > guarantee it won't blow up your system! I adopted wicd after Varun dropped it, though I havn't had a chance to familiarise myself with it. If any other devs want it, i'm happy to pass it on. In the meantime, I'll look through your changes and adopt them, thanks! James
[arch-general] netcfg v2.1
netcfg v2.1 is mostly a bug fix release, however there are some important changes and new features. - Remove driver specific hacks/quirks. They now need to be enabled manually using the QUIRKS=() array. - auto-wireless has been moved from net-profiles to a separate daemon net-auto. - A new option (IWCONFIG) to run iwconfig with set arguments before connecting - Various minor fixes Details can be found on the wiki for all these options http://wiki.archlinux.org/index.php/Network_profiles Development details for netcfg can also be found on the wiki http://wiki.archlinux.org/index.php/Network_Profiles_development
Re: [arch-general] netcfg 2.1.1 problem
2008/9/28 Ondřej Kučera <[EMAIL PROTECTED]>: > Hello, > > after upgrading netcfg from 2.0.6 to 2.1.1 I can no longer connect to my > wireless router (luckily downgrading back solves it). I know I should file a > bug report and I will, I only wanted to ask what information is relevant, > for output of which programs I should look, etc. Unfortunately I know almost > nothing about wireless networks or how netcfg really works but when I was > trying to manually do the interesting steps that I found in > /usr/lib/network/wireless.subr, it seemed to me that the problem occurs in > wpa_check() where wpa_cli status always returns SCANNING until it all times > out. For some reason this doesn't happen with netcfg 2.0.6 so I suppose the > previous steps that prepare everything do something in a different way. What driver? http://archlinux.org/news/410/ The major change between 2.1 and 2.0 is that any driver specific workarounds/hacks have been disabled by default. You can re-enable them using the QUIRKS array documented on the wiki. http://wiki.archlinux.org/index.php/Network_Profiles#Driver_Quirks_.28netcfg_2.1_and_later.29
Re: [arch-general] [arch-dev-public] request for dbus in core
On Sun, Oct 12, 2008 at 3:53 PM, Paulo Matias <[EMAIL PROTECTED]> wrote: > On Sun, Oct 12, 2008 at 2:49 AM, James Rayner <[EMAIL PROTECTED]> wrote: >> my support for [core], as an upcoming netcfg version will take >> advantage of the wpa_supplicant dbus interface. >> > > Please avoid using dbus in netcfg. I like it because it's clean, KISS, > and uses only default/native stuff. I can help integrating with UNIX > domain sockets or UDP sockets if needed. > > [1] http://hostap.epitest.fi/wpa_supplicant/devel/wpa__ctrl_8c-source.html It wasn't an immediate decision to use dbus and I did evaluate other options such as the aforementioned sockets interface. dbus is just as "default/native" if not more "native" than a custom control interface. These days, you'll struggle to find a system out there which doesnt at least have dbus installed. I picked the dbus setup as it's quicker for me to implement, easier to maintain in the long term, more KISS and easily the future for linux wireless configuration. dbus should be available in 2.2 and default in 3.0. In 3.0 the old interface will not be removed, instead renamed to "wireless-old" and so available for those who dislike dbus for some odd reason. If you want to implement a sockets interface, go for it. netcfg is designed to be modular, allowing a range of different interfaces implemented in any programming language (more in 2.2). James
Re: [arch-general] New 2008.10 archboot test iso/img files
On Mon, Oct 20, 2008 at 10:05 PM, Tobias Powalowski <[EMAIL PROTECTED]> wrote: > Am Montag 20 Oktober 2008 schrieb Roman Kyrylych: >> 2008/10/20 Victor Quinault <[EMAIL PROTECTED]>: >> > Hi just found that the link was broken. The good one should be (I >> > guess) http://downloads.archlinux.de/iso/archboot/2008.10/ >> >> Yes, it was moved there after it was released. >> The subdirectory was created to not mix isos generated with >> archboot and archiso (official since previous release) > It's also still in testing phase so it's only hosted there, im waiting for > some feedback before pushing it to the main mirrors. why the Arch main mirrors? archboot is not the official install CD and it'll just generate confusion. Some people are testing it because it's dressed up like the official disc and they're under the impression it is.
Re: [arch-general] [arch-dev-public] Election Night
On Wed, Nov 5, 2008 at 9:36 PM, Gerhard Brauer <[EMAIL PROTECTED]> wrote:
> Am Mittwoch 05 November 2008 11:26:28 schrieb RedShift:
>> Aaron "Hussein" Griffin wrote:
>> > So no one break the server tonight! Allan, I'm looking in your
>> > direction :)
>>
>> Obama has won. But the real challenge has yet to come.
>
> You mean: So that we can blame Barrack for further server breakage?
> "Barrack has broken it", IMHO something Allan like to hear...
>
>> Glenn
>
> Gerhard ("Merkel hat's kaputt gemacht")
>
>
ok, fun's over people, get back to work :p
Re: [arch-general] problems with ivman? hal? pmount?
On Thu, Dec 4, 2008 at 3:56 PM, Ryan Sims <[EMAIL PROTECTED]> wrote: > I'm working on switching from KDE to openbox, and I'm playing around > with ivman automounting. After reading the wiki page[1] & following > the instructions, I find that I still can't get USB devices to > automount as a user. I can run ivman as a daemon, and it automounts > just fine, except that it creates the mount points as root:root, so I > can't access them. If I run ivman as a user, nothing gets > automounted. > > When I run ivman -d, or when I run a pmount-hal > '/path/listed/in/ivman/debug/output' I get a lot of these messages: > process 17673: The last reference on a connection was dropped without > closing the connection. This is a bug in an application. See > dbus_connection_unref() documentation for details. > Most likely, the application was supposed to call > dbus_connection_close(), since this is a private connection. > D-Bus not built with -rdynamic so unable to print a backtrace ivman has been unmaintained upstream for over 18 months. I now use the thunar volman plugin instead. Install thunar, and the thunar-volman plugin, then run thunar --daemon & in your startup scripts. James
[arch-general] netcfg testing and git packages
Hi The release beta cycle wasn't working well for netcfg. Small changes, bugs and many FR's got held up far too long while other work happened. To try and help get netcfg development going smoothly again I've uploaded some netcfg git PKGBUILDs to the AUR to use instead of -beta releases. This way I can make those small changes, push it to git, and it can be tested immediately, while larger things can be safely done in another branch locally. When it's ready, rc's will be released. http://aur.archlinux.org/packages.php?ID=23953 http://aur.archlinux.org/packages.php?ID=23954 There's some fairly substantial changes in this release. - Moving from net-tools to iproute - iproute is the way forward. net-tools is long unmaintained, nor as capable. - Moving from wireless_tools to pure wpa_supplicant - More reliable, less quirks required. Hopefully more stable. - As part of this, wireless moves into netcfg-wireless (dependency issues) Both of these require config changes. Once they're both stabilised I can release 2.2.x to give people time to migrate, and eventually 2.5 which will use them by default. There are example configs included. More details on the wiki: http://wiki.archlinux.org/index.php/Network_Profiles_development The wpa_supplicant move needs a significant amount of testing. I havn't tested WEP (testing hardware is gone), and net-auto may not work presently. WPA and custom WPA configs work in my testing. If there's any criticisms or comments about the way this is going, the code, netcfg, etc, please let me know. I'd like to make 2.2 a good release and I think these changes are important. I'm hoping they'll make netcfg simpler and more reliable. Cheers, James
Re: [arch-general] closed bugs, open comments?
On Fri, Feb 20, 2009 at 10:12 AM, Baho Utot wrote: > I know the bug tracker is for bugs and not help, when I used to file bug > reports I did so because some thing didn't work (for example compiling a > package under the current arch gcc version). Yes maybe I didn't fully > understand the issue. You can look at your favorite package klibc* :), ( > klibc-udev to be exact) which I did file. (remember we found a flea in > pacman/makepkg using makeworld with the --log flag). > > Although I did not file a bug report for this here is an example > > I had opensp that I found a solution for and tried to get my patch applied > and the response (The way I saw it maybe not as it was intended) was go > adopt the package followed by a piss off. Well the package was in extra I > couldn't adopt it and I can not fix it in any way. I the problem still > exists with opensp. My intention was to simply get it fixed, all that > needed to be done was for someone who has access to update the PKGBUILD and > add the patch which I received from comp.os.linux.misc and it will build. I > did file a upstream bug report. No developers are telling anyone to piss off. I'm sure phrakture won't hesitate to hurl a car/bus/jet at anyone who did. If you're getting this impression, it's certainly not at all intended. We're busy, and some of us have a lot of bugs assigned to us. Often when updating a package there might be multiple bug reports to close, so it's quite normal to close without a message - this is not intended as a rude gesture, rather the reality of limited time and energy. Most of us are human (except Phrak) and we screw up sometimes (except Allan). If we do close a bug report incorrectly or misunderstand your issue, that's what the request to re-open option exists for. If you really disagree and think it's worth discussion, send an email right to this list _right here_ (this list is the newsgroup you want) where more people can see it than the handful assigned to the bug report. It's been done before, nobody complained, and will help clarify any decision made. Cheers! James
Re: [arch-general] Problems with netcfg
On Thu, Feb 26, 2009 at 1:47 PM, Cristopher Thomas wrote: > > networkmanager definitely isn't controlling wireless. I uninstalled it and > disabled the daemon in /etc/rc.conf. > I've tried wep, but switching to wap was the only way I could get a > connection at all. > > Not gonna lie. I wouldn't even know where to begin with a mac filter. I'm > just happy I got the router set up correctly with wap (which I though was > wep at the time). > > I'm using the ath9k wireless driver, installed using the compat-wireless > package. > > Not sure what kernel version I'm using. Whatever installed when I ran > pacman -Syu day before yesterday. I'll have to log into my Arch partition > to check later. > > I'm definitely using the right ESSID. I set that router up myself. SECURITY="wap" wap is not a valid security type, try either wpa, wep or wpa-config depending on your router configuration. James
Re: [arch-general] Problems with netcfg
On Thu, Feb 26, 2009 at 7:26 PM, Vincent Van Houtte wrote: > During my tests I also tried the wpa_supplicant in testing, and since > this version is not compatible with netcfg, I cannot use netcfg at the > moment. Fixed in git. For 2.1.2, just remove the -w argument from wpa_supplicant in the function start_wpa in /usr/lib/network/wireless.subr
Re: [arch-general] Problems with netcfg
The problem appeared to be a simple typo in the config file, however the OP has given up. *shrug* On 2/27/09, Geir Erikstad wrote: > 2009/2/26 Cristopher Thomas : >> I'm giving up on this for now. I set up wicd to verify that my driver was >> not >> to blame and it worked on the first try, so I'm not going to fight with it >> anymore. I would still like to no have to log into X to get wireless >> running, >> but for now I can make do. Thanks. > > Have you tried any of the driver quirks with netcfg? > Check out: > http://wiki.archlinux.org/index.php/Netcfg#Driver_Quirks_.28netcfg_2.1_and_later.29 > > I had to add: > > QUIRKS=(prescan preessid) > > to get my connection working. > > -geirr >
Re: [arch-general] Problems with netcfg
On Sat, Feb 28, 2009 at 2:35 PM, Cristopher Thomas wrote: > On Friday 27 February 2009 19:13:47 James Rayner wrote: >> The problem appeared to be a simple typo in the config file, however >> the OP has given up. *shrug* >> > > I don't know about it being a typo. Setting the encryption type to 'wap' > instead of 'wep' was the only way for me to ever get a connection. Here's the > error I got trying to use 'wep': > > [~]$ sudo netcfg home > :: home up - Could not set wireless configuration > [FAIL] > for wireless request "Set Mode" (8B06) : > SET failed on device wlan0 ; Device or resource busy. > I got that error everytime, whereas when I switched to 'wap' I would > occasionally get a connection. Usually after I had spent a while online in my > windows partition researching the problem. I know for a fact that the router > is set up for wep security, which is why I'm baffled about the profile not > working oh ok, i see the problem. In /usr/lib/network/wireless.subr search for "mode managed" and remove just that text. Theres a fix for this in netcfg git, but it needs testing and nobody is testing it, so I cant make a release. James.
Re: [arch-general] On rolling release system and its benefits.
On Wed, Mar 18, 2009 at 9:19 AM, Ali H. Caliskan wrote: > Hi, > > I've been using Arch since few months and I enjoy using it everyday that > goes by. However, during that time, while helping Arch users on the forum, > I've encountered some issues concerning upgrades and broken packages. I > personally think Arch is stable and well maintained compared to other big > distros, but that's a rolling release stability, that lasts only few days or > weeks. What I would like Arch developers is to extend the rolling release > into a snapshot release of an entire list of officially maintained packages, > comprising both core and extra branches. At least it would be a great way of > using Arch for 5 to 6 moths and then upgrade to a next snapshot release. I'm > not talking about stable releases, just a snapshot of a rolling state. > Snapshot releases does also benefit the natural need of closing bugs. Not to > mention, it does make it easy to maintain orphaned packages as well. If your system is running fine, with no bugs or issues that concern you, would you consider that stable? If so, have you ever experienced that with Arch? That's your snapshot. Just wait 6 months and -Syu, it works. Sometimes I've got boxes that I forget to Syu, or can't because of bandwidth. These days even my main machines only get a -Syu when I'm going to do some developer work James
Re: [arch-general] [arch-dev-public] ttf-ms-fonts (WAS: Re: [pacman-dev] [PATCH] New feature: files verification)
On Tue, Mar 31, 2009 at 6:47 PM, Thomas Bächler wrote: > Eric Bélanger schrieb: >> >> If the packaging problem is simply the files being installed in >> /tmp, that can be easily fixed. Instead of installing the files in >> /tmp, just install them somewhere else (/usr/share/ttf-ms-fonts/ ?) >> where they won't be deleted. > > The problem is that files are installed at run-time and cannot be tracked by > pacman. That is a no-go for packages! We've allowed it in the past when the package has been of significance. Like nvidia and fglrx before those were rewritten. Though I have all the fonts in my own ~/.fonts, I'd prefer to keep the package in the repos. Installation was at 70% in pkgstats. James
Re: [arch-general] Proposed netcfg expansion
On Tue, Apr 21, 2009 at 6:41 AM, Andrei Thorp wrote: > Ah, I see. > > Well, in that case, guess there isn't really anything to be done, > aside from perhaps updating a netcfg example to include this. > > This is why I like to ask first :) > I have an FR to add an example for this. I believe I have one in git, but not the current release. I _think_ it might also be mentioned on the wiki page somewhere too. James
Re: [arch-general] WPA2 - How to set with ACX card??
On Wed, Apr 29, 2009 at 7:22 PM, David C. Rankin wrote: > Listmates, > > My second Arch box is now complete (well almost:-) This time a desktop > box > with a zytel wireless lan adapter using the TI acx chipset and its firmware 2 > is the acx111_2.3.1.31/tiacx111c16 firmware slice. The card is detected and > works fine it think... I can open kwifimanager and it has my access point > associated and I can watch the generic packets blip by and watch the strength > meter do its thing, but I cannot authenticate :-( > > My system is WPA, and no matter how hard I looked, I couldn't find > anything in > Arch that would all me to configure the wireless as anything other than WEP. > Bummer. Wep isn't allowed within 500 feet of anything I deal with. After > spending a little time playing with aircrack, if you haven't already, you will > definitely feel the same. Most wep secured wireless networkss can be cracked > in > less than 30 seconds. (why do you think I'm never without a wireless > connection > -- no matter where I go;-) > > So what tools are available to configure this acx111 card to use > WPA-TKIP or > WPA2? In that other Linux OS, the knetworkmanager utility did a great job with > the Atheros bashed card in my laptop, XP has no problems with the card (this > box is dual boot) so I know the hardware works fine. Any suggestions? netcfg, it's in core and is recommended on the Wireless Setup page... http://wiki.archlinux.org/index.php/Netcfg
Re: [arch-general] Bugs again
On Thu, May 14, 2009 at 9:46 PM, Damjan Georgievski wrote: > Sorry to bring this again, but something has to change in the way > bugs are handled in Arch. > > I've open this bug report http://bugs.archlinux.org/task/13905 about > the awesome package in community. > > The package maintainer just closes the bug, not solving it, claiming > it's upstream, and not even investigating the problem. He suggests I > ask upstream. > > Ok, I play a good citizen, I do ask upstream, we find the problem, a > sollution is found - it turns out the PKGBUILD was wrong from the > begining - but still I submit a patch to awesome so that building it > is much easier. > > I request reopening the bug .. it's a small text-area, not very > usable, so I just write "New information" .. since the bug was closed > with "You may want to ask upstream why they install those files by > default.". > > And then I get the answer: > Reason for denial: > You need to be more specific that "New information" in a reopen request... > > Now, it's not like I enjoy hanging out in the bug system opening bugs, > investigating them, hoping to improve ArchLinux's packages.. and I > don't see how I could've deserved this behaviour. > > The bug report shouldn't have been closed in the first place, since > the problem was not even solved. I don't think bugs should never be closed as "upstream". I think we have some responsibility to ensure any upstream bug that we receive is at the least reported upstream. As soon as an upstream bug is closed as "upstream", then there's an untracked bug, that may or may not be properly reported upstream. At the very least, I think some sort of evidence that it has been reported upstream or an attempt to fix it has been made before closing such a bug. This way we avoid misunderstandings and the bug remains tracked. James
Re: [arch-general] Eee binary repo?
On Sun, Jul 5, 2009 at 2:29 AM, Magnus Therning wrote: > I've seen quite a few Eee-related packages on AUR. Is there a > recommended repo with binary versions I can use? > > Ideally I'd like to avoid havig to compile on my Eee, I'd also like to > avoid having to install a 32-bit desktop system just to compile for my > Eee :-) Which packages are you thinking about? - laptop-mode-tools-superhe, acpi-eeepc-generic, acpi-eee* - shell script, no compilation - eee-control - python, no compilation (afaik it has no binary components). - kernel: Atom based eee: Use the kernel in [core], it has everything. Celeron based eee: Dan's repository[1]. - kernel modules: Most in the AUR are outdated or already merged to vanilla - kernel26 in [core]. Even then, most packages in the are a few minutes compile. I'm using my eee as my primary dev machine at the moment. James [1] http://www.toofishes.net/blog/arch-eee-repository/ Best for Celeron based eees (700 and some 900?) only. Last time I checked there was no HT support which the Atom gains significant benefits due to it's in-order architecture.
Re: [arch-general] [arch-dev-public] [idea] global link database for all packages
On Thu, Jul 2, 2009 at 3:00 AM, Thomas Bächler wrote: > > I collected it together from several (old) HOWTOs back in 2001 and there's a > wiki page on Arch (originally written by your's truly) - sad that netcfg > doesn't include support (or does it?). > There's some vague support, though I have no idea how well/if it still works. Nor is it documented well. btw, I've been meaning to contact you to work out some way to make autowifi and netcfg work well together. James
Re: [arch-general] makepkg security
On Fri, Jul 10, 2009 at 11:39 AM, Alessandro Doro wrote: > ¹ Really theoretical, assuming that the user: > · read the PKGBUILD, > · trust the package source. Yeah... I think I'd be somewhat suspicious if I saw a PKGBUILD calling sudo. sudo -k wouldn't be very effective either. What if I run sudo elsewhere on my system during the build process, the hole is open again. As long as you're running an untrusted script on your system, there's infinitely many other possibilities. An rm -rf ~/* is pretty damaging and doesn't need sudo. Allesandro is spot on. James
Re: [arch-general] Arch Linux on Freerunner
On Fri, Jul 10, 2009 at 4:43 AM, Alper KANAT wrote: > Hey There, > > I've never heard of BeagleBoard. As a user of it, have you tried playing HD? > I really would like to have one if can play various formats of digital video > and of course on Arch! Apparently HD capable: http://beagleboard.org/hardware It looks really cool! It'd be a great replacement for the crappy laptop mpd/backup/print server I have setup.
