Re: [arch-general] BASH no longer does 'for i in $(ls); do ls $i; done'??
On 05/18/2010 03:23 PM, Daenyth Blank wrote: > On Tue, May 18, 2010 at 16:17, David C. Rankin > wrote: >> Guys, >> >>I'm usually quite good at one-liners, but my simple ones no longer >> work in >> Arch. Same cli works fine in suse. What have I messed up? To wit: > > In short, you're doing it wrong. > > http://mywiki.wooledge.org/ParsingLs > Thanks Daenyth, Yes, I agree with the article, but the concerns are limited to Internal File Separator ($IFS) issues. If you properly handle $IFS issues, like: OLDIFS=$IFS # (default is : IFS=$' \t\n') IFS=$'\n' for i in $(ls); do echo "whatever $i"; done IFS=$OLDIFS # not really required if run in a script because your present # environment will be protected by execution in a subshell. If used # as a one-liner, just enclose your cli in parenthesis for the # same protection. i.e. '( your code )' forces your code to execute # in a subshell. In my instance: 01:13 alchemy:~/dt/compiz/compiz_11.0> l total 24 drwxr-xr-x 6 david dcr 4096 2010-05-17 23:56 ./ drwxr-xr-x 9 david dcr 4096 2010-05-18 10:28 ../ drwxr-xr-x 2 david dcr 4096 2010-05-18 10:24 i586/ drwxr-xr-x 2 david dcr 4096 2010-05-17 23:56 noarch/ drwxr-xr-x 2 david dcr 4096 2010-05-18 10:22 src/ drwxr-xr-x 2 david dcr 4096 2010-05-18 10:21 x86_64/ I would still expect my original command line to work. Aaron and Sergey nailed down where I messed up by putting my alias in /etc/bash.bashrc.local. Though I still don't understand why having it in /etc/bash.bashrc.local instead of ~/.bashrc makes a difference. That's what I need to learn. I'll poke around and report back if somebody doesn't answer it first. That's something I want to understand. Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] BASH no longer does 'for i in $(ls); do ls $i; done'??
On Wed, 2010-05-19 at 01:41 -0500, David C. Rankin wrote: > So the bottom line is don't alias 'ls'. And, I guess, the next > question would > be, how or where can I safely customize the behavior of ls without > screwing > myself again. Solution is simple: don't use ls for the for loops you're doing. I just tested it on my system, the colored files and directories give "No such file or directory", which makes sense, as the variable contains ascii chars for color information. I would suggest using globbing, why would you use for i in $(ls); while you can use for i in *;
Re: [arch-general] BASH no longer does 'for i in $(ls); do ls $i; done'??
On 05/18/2010 03:58 PM, Aaron Griffin wrote:
> On Tue, May 18, 2010 at 3:47 PM, Sergey Manucharian
> wrote:
>> Excerpts from Linas's message of Tue, 18 May 2010 22:31 +0200:
>>
>>> David C. Rankin wrote:
Guys,
I'm usually quite good at one-liners, but my simple ones no
longer work in Arch. Same cli works fine in suse. What have I
messed up? To wit:
What could keep the simple cli from working on Arch? I know
this stuff worked before updates this morning... What should I look
at?
>>> Bash was updated from 4.1.5(2) to 4.1.7(2).
>>> I can't reproduce it, though.
>>
>> I cannot reproduce it either and suspect that your "ls" under $() is
>> not the real ls, but an alias. I've played with some, and they indeed
>> produce bad output.
>
> If this is the case, replace "ls" with "/bin/ls" in the above and try again
>
01:28 nirvana:/home/backup/rpms/compiz_X11.0> for i in $(/bin/ls); do echo -e
"'ls ${i}'\n"; /bin/ls ${i}; done
'ls i586'
compiz-0.8.6-46.1.i586.rpm
compiz-plugins-extra-devel-0.8.6-5.2.i586.rpm
Wohoo! It works
So the bottom line is don't alias 'ls'. And, I guess, the next question
would
be, how or where can I safely customize the behavior of ls without screwing
myself again. I had thought that setting a system wide alias for ls would be OK
by setting it in /etc/bash.bashrc.local. The contents were:
01:30 nirvana:/home/backup/rpms/compiz_X11.0> cat /etc/bash.bashrc.local.sav
alias ls='ls --color --group-directories-first'
Just tinkering, here is what I've found. If I make the changes in
~/.bashrc,
the everything works fine, but if I make the same change in
/etc/bash.bashrc.local, then the problem occurs. If you want to re-create my
problem, just include the following alias:
alias ls='ls --color --group-directories-first'
in:
/etc/bash.bashrc.local
Then find a simple directory and try to run:
for i in $(ls); do ls ${i}; done
It will bomb. Then delete the alias from /etc/bash.bashrc.local and put
the
'same' alias in your ~/.bashrc. The for loop works fine ... and ... you get the
customized 'ls' behavior.
What I do not understand is why the difference whether you put the
alias in
/etc/bash.bashrc.local or ~/.bashrc?
--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com
Re: [arch-general] BASH no longer does 'for i in $(ls); do ls $i; done'??
On 05/18/2010 03:47 PM, Sergey Manucharian wrote:
> Excerpts from Linas's message of Tue, 18 May 2010 22:31 +0200:
>
>> David C. Rankin wrote:
>>> Guys,
>>>
>>> I'm usually quite good at one-liners, but my simple ones no
>>> longer work in Arch. Same cli works fine in suse. What have I
>>> messed up? To wit:
>>>
>>>
>>> What could keep the simple cli from working on Arch? I know
>>> this stuff worked before updates this morning... What should I look
>>> at?
>> Bash was updated from 4.1.5(2) to 4.1.7(2).
>> I can't reproduce it, though.
>
> I cannot reproduce it either and suspect that your "ls" under $() is
> not the real ls, but an alias. I've played with some, and they indeed
> produce bad output.
>
> Cheers,
> Sergey
>
Ahah! I bet you are right. I have aliased ls as:
alias ls='ls --color --group-directories-first'
which is the way I like ls to work. Let's do a test:
[01:19 nirvana:/home/david] # mv /etc/bash.bashrc.local
/etc/bash.bashrc.local.sav
[01:19 nirvana:/home/david] # x
exit
01:19 nirvana:~> su
[01:20 nirvana:/home/backup/rpms/compiz_X11.0] # for i in $(ls); do echo "dir:
$i"; done
dir: i586
dir: noarch
dir: repodata
dir: repoview
dir: src
dir: x86_64
now dropping back to my user shell where the alias is still applied:
01:21 nirvana:/home/backup/rpms/compiz_X11.0> for i in $(ls); do echo "dir: $i";
done
dir: i586
dir: noarch
dir: repodata
dir: repoview
dir: src
dir: x86_64
Double Huh??? Now it works?? I haven't altered the environment for this shell
yet?? Let's use my original command line:
01:22 nirvana:/home/backup/rpms/compiz_X11.0> for i in $(ls); do ls ${i}; done
ls: cannot access i586: No such file or directory
ls: cannot access noarch: No such file or directory
ls: cannot access repodata: No such file or directory
ls: cannot access repoview: No such file or directory
ls: cannot access src: No such file or directory
ls: cannot access x86_64: No such file or directory
Ah hah! I knew I was screwing myself, I just didn't know how. Let's find out:
01:23 nirvana:/home/backup/rpms/compiz_X11.0> for i in $(ls); do echo "'$i'";
done
'i586'
'noarch'
'repodata'
'repoview'
'src'
'x86_64'
01:24 nirvana:/home/backup/rpms/compiz_X11.0> for i in $(ls); do echo "'ls
${i}'"; done
'ls i586'
'ls noarch'
'ls repodata'
'ls repoview'
'ls src'
'ls x86_64'
01:25 nirvana:/home/backup/rpms/compiz_X11.0> for i in $(ls); do echo "'ls
${i}'"; ls $i; done
'ls i586'
ls: cannot access i586: No such file or directory
'ls noarch'
ls: cannot access noarch: No such file or directory
'ls repodata'
ls: cannot access repodata: No such file or directory
'ls repoview'
ls: cannot access repoview: No such file or directory
'ls src'
ls: cannot access src: No such file or directory
'ls x86_64'
ls: cannot access x86_64: No such file or directory
... I give up :-( ...
--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com
[arch-general] Fwd: testing kernel crashes on bootup
-- Weitergeleitete Nachricht -- Betreff: testing kernel crashes on bootup Datum: Dienstag 18 Mai 2010, 23:57:44 Von: Kris An: t.p...@gmx.de on i686. kernel 2.6.34. just replying to this: http://mailman.archlinux.org/pipermail/arch-dev-public/2010-May/016872.html image of crash: http://imgur.com/RDLN5 - -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
Re: [arch-general] starting network:fail[eth0 wasn't connected] How to enable without reboot?
On 18 May 2010 12:45, Joe(theWordy)Philbrook wrote: > > Currently my pc is a laptop. I don't use a wireless interface. I > connect to the Internet via cable broadband with a wired Ethernet > connection and DHCP... This id very reliable. I can usually disconnect > the laptop from the Ethernet cable and bring it into the livingroom > for various offline use. Then when I bring it back to my desk, all I > usually have to to is plug the Ethernet cable back in and wait a few > seconds and the Internet will start to work again. > > BUT that is contingent on the Ethernet cable having been connected > during boot up. So if for example I were to boot up my laptop in the > livingroom where there isn't an Ethernet connection the boot process > will delay at the point where it's screen message says its starting > the network. Then it says it failed and continues setting everything > else up. > > At this point, if I bring the laptop back to the desk, and plug in the > Ethernet cable, it doesn't automatically connect. I tried: > > # ifconfig eth0 up > > but ping still doesn't find my ISP > > What am I missing > > -- > | ~^~ ~^~ > | Joe (theWordy) Philbrook > | ^ J(tWdy)P > | \___/ <> > > http://wiki.archlinux.org/index.php/Netcfg#net-auto-wired -- Tavian Barnes
Re: [arch-general] PulseAudio package group
On Tue, May 18, 2010 at 11:41 PM, Jan Steffens wrote: > The problem with doing that is some packages will indeed have to > *depend* and not just optdepend on PA. > > PulseAudio installs some desktop files that causes it to autostart > together with Gnome or KDE. > > The PA client library will start the PA server if it's not running, > instead of failing. That means output libraries like sdl (which, by > default, tries pulse before alsa) will start the server instead of > failling back to other output methods. > > gnome-media, when compiled with PulseAudio support, will be > inseparable from it. E.g., gnome-volume-control will only control > PulseAudio. > > So as I see it, it would be hard to make PulseAudio part of ArchLinux > without making it mandatory. In this situation, we should go with a case by case approach. If adding pulseaudio support to a package doesn't force the use of a pulseaudio setup, then we build with it and add a pulseaudio optdepends (or depends as required). In cases like gnome-media, we provide a pulse and non-pulse version of the package. Having both of these versions in extra would enable us to use split PKGBUILD to build them. So it will add no extra work for you. Of course, we have to wait what the other devs have to say. IIRC the past pulseaudio discussions, the main stumbling block (I don't recall other issues) was that no dev wanted to maintain it. As you are interested in it and with the jr dev scheme, that issue seem to be resolved. > > On Wed, May 19, 2010 at 2:58 AM, Eric Bélanger > wrote: >> On Tue, May 18, 2010 at 6:25 PM, Jan Steffens wrote: >>> I could make PulseAudio installation significantly easier by putting >>> specially-built packages (e.g. sdl-pulse, openal-pulse) into >>> [community] and grouping them in a "pulse" group. >>> >>> This group would also include a "pulse-asoundrc" package containing a >>> pulse-configured asound.conf, as well as depending on alsa-plugins. >>> >>> Should I go ahead with this? Any suggestions? >>> >> >> I would suggest to apply for a jr. dev position so that the pulseaudio >> stuff could be moved to extra. That would save us from duplicating >> work by having both pulse and non-pulse packages. >> >> BTW, does adding pulse support make it a depends or optdepends? I >> would guess it depends on the package. >> >
[arch-general] Fw: A question regarding the ifdplug and wireless interfaces
Hopefully this gets to you folks. In edition, I've insured that this will be in plain-text, I received a content type was not allowed error message previously. thanks! Regards, --Keith From: Keith Hinton Sent: Wednesday, May 19, 2010 12:21 AM To: Arch-General Subject: A question regarding the ifdplug and wireless interfaces Hi all, I have an interesting setup presently. One of these days I hope to move permanently to Arch-however, I'm on Windows presently so am running Arch in a VMware virtual machine by using VMware workstation 7 on Windows. I still do make use of tools such as the NetCFG tool, especially. As a blind Arch user, and one who does a lot of repetitive tasks, I like the use of netcfg personally. I have used it, especially rather than say, configuring WPA_Supplicant manually, even after reading all the documentation. While I do appreciate and value Arch Linux for most of the manual configuration, I still believe in my heart that automation of some tasks is an okay thing to do. What do you folks think? I for instance, tend to love pre-configuring specific files, such as Pacman.conf, and other various small files, and just cary them on a small USB 4GB thumb-drive of mine. That way, if and when I install Arch regardless of a VM or real environment, I have the various files to work with a head of time, already configured by me in the first place, avoiding the need to do that all over again. Usually, after that, I just need to cp the files for use in whatever they're intended to be used for. My first question though is this: does the ifdplug interface tool only work with Ethernet cards? Or is wireless Ethernet cards also supported? Also, when it comes to Arch and the various uses of the system environment, how was Arch designed so as to be so flexible? It amazes me at how light Arch Linux really is-it performed without a problem on my Intel Pentium III, 930MHZ, 256MB RAM Del desktop computer for two years. Of course, at the time I had a secondary Windows machine for the tools I use like Skype, that still remain unaccessible to the blind/visually impared community, whare as Skype in windows/Apple Mac remains the most accessible. Similar issues of accessibility/bugs occur in Mozilla's Firefox. presently, I find that Arch is one of the most interesting distrobutions of Linux available out there. Thanks for making such a fine distro, and I hope that you folks continue to develop Arch as you folks have for the passed what..99 years? LOL. Have fun, and happy Arching. If you folks wish to chat with me-you can occasionally find me on irc.freenode.net #ArchLinux as Keith-BlindUser For you Archers that use Twitter, if you wish to contact me that way besides the Arch-General or Arch-Releng mailing lists or Irc, you may follow keithint1234 on Twitter. Or send me an email off-list if you want at: keithint1...@gmail.com I can be reached on Skype by adding skypedude1234 to your Skype contacts lists. Thanks! Regards, --Keith
Re: [arch-general] starting network:fail[eth0 wasn't connected] How to enable without reboot?
It would appear that on May 18, Dan McGee did say: > Your dhcp process didn't start either, so you need to start one of > those. Something as simple as `dhcpcd -i eth0` might work. That makes sense Dan, Thanks! While it looks like woldra's suggestion may be the best one, yours gives me a clue as to why ifconfig didn't do it for me... Thanks again. You also made me curious, I will likely try the dhcpcd method at least once to see if it works... It would appear that on May 18, C Anthony Risinger did say: > You may need to modprobe the module for your Ethernet card. Try lsmod > to get it's name. I'm hoping I don't need that because lsmod produces pages of output, none of which sounds like an ethernet card to me... But thanks for pointing out the possibility... It would appear that on May 18, Rafael Correia did say: > Man, I don't that's the point, but here I need to do this: > > ifconfig eth0 0.0.0.0 Thanks Rafael, A look at 'man ifconfig' seems to indicate that you are telling it to set the ip address of the interface to 0.0.0.0 though I haven't a clue why you need to do that. If all else fails I'll try it. It would appear that on May 18, wol...@fsfe.org did say: > ifplugd is your friend it detects the calble being plugged in and brings > the interface up. Thanks woldra, I never heard of ifplugd before... have to admit, what I learned with a quick scroogle search on it tells me that it's probably my best option. Especially if it really only affects the ethernet connection. But 'man ifplugd' is rather terse. After doing a 'pacman -S ifplugd' will I need to add it to the daemons list in my rc.conf??? It would appear that on May 18, Kaiting Chen did say: > Um should he just /etc/rc.d/network restart? That performs everything that > happens when the network interface is brought up on system start. Thank you Kaiting. This might even turn out to be necessary, the boot up screen messages don't specify what "starting the network" failed to do. So if ifplugd doesn't do it, I'll probably go this route... It would appear that on May 19, wol...@fsfe.org did say: > > Um should he just /etc/rc.d/network restart? That performs everything that > > happens when the network interface is brought up on system start. > > > sure you can do that, but why not let the little tool do that for you? A > little automagic doesn't harm as long as you know whats going on;) > Apart from that ifplugd just controls one interface where the network script > starts/stops the whole networking (including 127.0.0.1)... So then I'm guessing that means that if a process is using the local loopback interface when a "/etc/rc.d/network restart" is issued, then that process my crash or hang etc... ??? It would appear that on May 18, Kaiting Chen did say: > I see I've never heard of ifplugd but it looks like the best solution. What > I was referring to was that /etc/rc.d/network restart is preferable to > ifconfig in that it will start up dhcpcd for you. Well Kaiting, While woldra's ifplugd suggestion does sound like the best solution, YOUR suggestion, and that of Dan McGee, seem to explain what I was missing with my ifconfig idea... Which is what I actualy asked... I'd like to thank all of you very much for the kind suggestions. This thread will definitely be copied to my "LinuxClues" folder for future reference. -- | ~^~ ~^~ | <*> <*> Joe (theWordy) Philbrook | ^J(tWdy)P | \___/ <>
Re: [arch-general] PulseAudio package group
The problem with doing that is some packages will indeed have to *depend* and not just optdepend on PA. PulseAudio installs some desktop files that causes it to autostart together with Gnome or KDE. The PA client library will start the PA server if it's not running, instead of failing. That means output libraries like sdl (which, by default, tries pulse before alsa) will start the server instead of failling back to other output methods. gnome-media, when compiled with PulseAudio support, will be inseparable from it. E.g., gnome-volume-control will only control PulseAudio. So as I see it, it would be hard to make PulseAudio part of ArchLinux without making it mandatory. On Wed, May 19, 2010 at 2:58 AM, Eric Bélanger wrote: > On Tue, May 18, 2010 at 6:25 PM, Jan Steffens wrote: >> I could make PulseAudio installation significantly easier by putting >> specially-built packages (e.g. sdl-pulse, openal-pulse) into >> [community] and grouping them in a "pulse" group. >> >> This group would also include a "pulse-asoundrc" package containing a >> pulse-configured asound.conf, as well as depending on alsa-plugins. >> >> Should I go ahead with this? Any suggestions? >> > > I would suggest to apply for a jr. dev position so that the pulseaudio > stuff could be moved to extra. That would save us from duplicating > work by having both pulse and non-pulse packages. > > BTW, does adding pulse support make it a depends or optdepends? I > would guess it depends on the package. >
Re: [arch-general] PulseAudio package group
On Tue, May 18, 2010 at 6:25 PM, Jan Steffens wrote: > I could make PulseAudio installation significantly easier by putting > specially-built packages (e.g. sdl-pulse, openal-pulse) into > [community] and grouping them in a "pulse" group. > > This group would also include a "pulse-asoundrc" package containing a > pulse-configured asound.conf, as well as depending on alsa-plugins. > > Should I go ahead with this? Any suggestions? > I would suggest to apply for a jr. dev position so that the pulseaudio stuff could be moved to extra. That would save us from duplicating work by having both pulse and non-pulse packages. BTW, does adding pulse support make it a depends or optdepends? I would guess it depends on the package.
Re: [arch-general] PulseAudio package group
On Wednesday 19 May 2010 00:25:41 Jan Steffens wrote: > I could make PulseAudio installation significantly easier by putting > specially-built packages (e.g. sdl-pulse, openal-pulse) into > [community] and grouping them in a "pulse" group. I think its a great idea to provide more "pulse" packages, so the installation of PulseAudio would be easier. However I don't think that the "pulse" group is a good idea at all, because by installing the whole group you force people to install applications they don't use (or need). "openal-pulse" and "sdl-pulse" would be great. I've had also some struggle to recompile "phonon-gstreamer" with PulseAudio support, so "phonon-gstreamer- pulse" would be another nice package to have. I guess there are plenty of packages that support PulseAudio, but haven't been compiled to do so yet. -- Best regards, Karol Babioch signature.asc Description: This is a digitally signed message part.
Re: [arch-general] PulseAudio package group
2010/5/19 Isaac Dupree : > also I wonder why the group name to be "pulse" and not "pulseaudio". This was an upstream decision.
Re: [arch-general] [arch-dev-public] kernel 2.6.34-1
Am 19.05.2010 00:47, schrieb Thomas Bächler: > Am 18.05.2010 21:49, schrieb Nezmer: >> FYI, I had this discussion with the radeon guys months ago in IRC. >> Apparently, kernel guys (maybe Linus) decided to not add new firmware >> files to the kernel tree. That's why we have all those firmware packages >> for in-tree modules. > > So, they ship firmware files with the kernel, but only SOME firmware > files? And arbitrarily, others are not being shipped? In particular, old > ones are shipped, and new ones aren't? This annoys me already - but > before I start any discussion, I want to have a source for that. It > might be time to annoy the lkml with this. > Okay, this is confusing. It seems that linux-firmware is a superset of the firmware in kernel26 and includes lots of files, including the intel iwlwifi firmware and the ralink firmware. This file lacks some conflicts/provides, but you should be able to install it instead of kernel26-firmware. http://dev.archlinux.org/~thomas/linux-firmware-git-20100519-1-any.pkg.tar.xz Let me know what you think. Also, there have been some reports about missing ralink firmware files, those might be in here as well. signature.asc Description: OpenPGP digital signature
Re: [arch-general] BASH no longer does 'for i in $(ls); do ls $i; done'??
Using ls for something like this is never a good idea, as Daenyth's link
repeatedly points out. Use bash's globbing to get the job done.
for i in *; do
foo $i
done
Also unlike ls, this won't fail because of aliases or white spaces, either.
It just works(tm).
d
On Tue, May 18, 2010 at 5:40 PM, Samuel Martín Moro wrote:
> you may want to try
> for i in $(`which ls` -d .) ; do `which ls` $(`which pwd`)/$i; done
> it does work here
>
> Samuel Martín Moro
> {EPITECH.} tek4
> CamTrace S.A.S
>
> "Nobody wants to say how this works.
> Maybe nobody knows ..."
> Xorg.conf(5)
>
>
> On Tue, May 18, 2010 at 10:58 PM, Aaron Griffin >wrote:
>
> > On Tue, May 18, 2010 at 3:47 PM, Sergey Manucharian
> > wrote:
> > > Excerpts from Linas's message of Tue, 18 May 2010 22:31 +0200:
> > >
> > >> David C. Rankin wrote:
> > >> > Guys,
> > >> >
> > >> > I'm usually quite good at one-liners, but my simple ones no
> > >> > longer work in Arch. Same cli works fine in suse. What have I
> > >> > messed up? To wit:
> > >> >
> > >> >
> > >> > What could keep the simple cli from working on Arch? I know
> > >> > this stuff worked before updates this morning... What should I look
> > >> > at?
> > >> Bash was updated from 4.1.5(2) to 4.1.7(2).
> > >> I can't reproduce it, though.
> > >
> > > I cannot reproduce it either and suspect that your "ls" under $() is
> > > not the real ls, but an alias. I've played with some, and they indeed
> > > produce bad output.
> >
> > If this is the case, replace "ls" with "/bin/ls" in the above and try
> again
> >
>
Re: [arch-general] PulseAudio package group
On Tue, 2010-05-18 at 18:44 -0400, Isaac Dupree wrote: > On 05/18/10 18:25, Jan Steffens wrote: > > I could make PulseAudio installation significantly easier by putting > > specially-built packages (e.g. sdl-pulse, openal-pulse) into > > [community] and grouping them in a "pulse" group. > > > > This group would also include a "pulse-asoundrc" package containing a > > pulse-configured asound.conf, as well as depending on alsa-plugins. > > > > Should I go ahead with this? Any suggestions? > > Sounds neat! (disclaimer: i haven't used PA on Arch, only on Ubuntu in > the past.) Question: OK this would make it easy to transition *to* a > PulseAudio based system, but suppose I later decide I don't like it-- is > it easy to transition back to a non-PA system?(wait, it's trivial if > those packages don't conflict with 'sdl' etc. -- do they?) > > also I wonder why the group name to be "pulse" and not "pulseaudio". The only thing this would make simpler is not requiring user-compilation (and the packages must conflict with sdl/openal I believe, in most cases). I'd be happy with this if only for the reason that I wouldn't have to wait for the REALLY slow mplayer downloads to compile mplayer-pulse. You may have difficulty selecting which packages though (would gnome-media-pulse qualify?).
Re: [arch-general] [arch-dev-public] kernel 2.6.34-1
Am 18.05.2010 21:49, schrieb Nezmer: > FYI, I had this discussion with the radeon guys months ago in IRC. > Apparently, kernel guys (maybe Linus) decided to not add new firmware > files to the kernel tree. That's why we have all those firmware packages > for in-tree modules. So, they ship firmware files with the kernel, but only SOME firmware files? And arbitrarily, others are not being shipped? In particular, old ones are shipped, and new ones aren't? This annoys me already - but before I start any discussion, I want to have a source for that. It might be time to annoy the lkml with this. signature.asc Description: OpenPGP digital signature
Re: [arch-general] starting network:fail[eth0 wasn't connected] How to enable without reboot?
I see I've never heard of ifplugd but it looks like the best solution. What I was referring to was that /etc/rc.d/network restart is preferable to ifconfig in that it will start up dhcpcd for you. Kaiting. On Tue, May 18, 2010 at 6:32 PM, wrote: > Hi > > > Um should he just /etc/rc.d/network restart? That performs everything that >> happens when the network interface is brought up on system start. >> >> > sure you can do that, but why not let the little tool do that for you? A > little automagic doesn't harm as long as you know whats going on;) > Apart from that ifplugd just controls one interface where the network > script starts/stops the whole networking (including 127.0.0.1)... > > > -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [arch-general] PulseAudio package group
On 05/18/10 18:25, Jan Steffens wrote: I could make PulseAudio installation significantly easier by putting specially-built packages (e.g. sdl-pulse, openal-pulse) into [community] and grouping them in a "pulse" group. This group would also include a "pulse-asoundrc" package containing a pulse-configured asound.conf, as well as depending on alsa-plugins. Should I go ahead with this? Any suggestions? Sounds neat! (disclaimer: i haven't used PA on Arch, only on Ubuntu in the past.) Question: OK this would make it easy to transition *to* a PulseAudio based system, but suppose I later decide I don't like it-- is it easy to transition back to a non-PA system?(wait, it's trivial if those packages don't conflict with 'sdl' etc. -- do they?) also I wonder why the group name to be "pulse" and not "pulseaudio".
Re: [arch-general] starting network:fail[eth0 wasn't connected] How to enable without reboot?
Hi Um should he just /etc/rc.d/network restart? That performs everything that happens when the network interface is brought up on system start. sure you can do that, but why not let the little tool do that for you? A little automagic doesn't harm as long as you know whats going on;) Apart from that ifplugd just controls one interface where the network script starts/stops the whole networking (including 127.0.0.1)...
[arch-general] PulseAudio package group
I could make PulseAudio installation significantly easier by putting specially-built packages (e.g. sdl-pulse, openal-pulse) into [community] and grouping them in a "pulse" group. This group would also include a "pulse-asoundrc" package containing a pulse-configured asound.conf, as well as depending on alsa-plugins. Should I go ahead with this? Any suggestions?
Re: [arch-general] starting network:fail[eth0 wasn't connected] How to enable without reboot?
Um should he just /etc/rc.d/network restart? That performs everything that happens when the network interface is brought up on system start. Kaiting. On Tue, May 18, 2010 at 5:57 PM, wrote: > On 2010-05-18 20:45, Joe(theWordy)Philbrook wrote: > >> Currently my pc is a laptop. I don't use a wireless interface. I >> connect to the Internet via cable broadband with a wired Ethernet >> connection and DHCP... This id very reliable. I can usually disconnect >> the laptop from the Ethernet cable and bring it into the livingroom >> for various offline use. Then when I bring it back to my desk, all I >> usually have to to is plug the Ethernet cable back in and wait a few >> seconds and the Internet will start to work again. >> >> BUT that is contingent on the Ethernet cable having been connected >> during boot up. So if for example I were to boot up my laptop in the >> livingroom where there isn't an Ethernet connection the boot process >> will delay at the point where it's screen message says its starting >> the network. Then it says it failed and continues setting everything >> else up. >> >> At this point, if I bring the laptop back to the desk, and plug in the >> Ethernet cable, it doesn't automatically connect. I tried: >> >> # ifconfig eth0 up >> >> but ping still doesn't find my ISP >> >> What am I missing >> >> >> > ifplugd is your friend it detects the calble being plugged in and > brings the interface up. > > -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [arch-general] starting network:fail[eth0 wasn't connected] How to enable without reboot?
On 2010-05-18 20:45, Joe(theWordy)Philbrook wrote: Currently my pc is a laptop. I don't use a wireless interface. I connect to the Internet via cable broadband with a wired Ethernet connection and DHCP... This id very reliable. I can usually disconnect the laptop from the Ethernet cable and bring it into the livingroom for various offline use. Then when I bring it back to my desk, all I usually have to to is plug the Ethernet cable back in and wait a few seconds and the Internet will start to work again. BUT that is contingent on the Ethernet cable having been connected during boot up. So if for example I were to boot up my laptop in the livingroom where there isn't an Ethernet connection the boot process will delay at the point where it's screen message says its starting the network. Then it says it failed and continues setting everything else up. At this point, if I bring the laptop back to the desk, and plug in the Ethernet cable, it doesn't automatically connect. I tried: # ifconfig eth0 up but ping still doesn't find my ISP What am I missing ifplugd is your friend it detects the calble being plugged in and brings the interface up.
Re: [arch-general] BASH no longer does 'for i in $(ls); do ls $i; done'??
you may want to try
for i in $(`which ls` -d .) ; do `which ls` $(`which pwd`)/$i; done
it does work here
Samuel Martín Moro
{EPITECH.} tek4
CamTrace S.A.S
"Nobody wants to say how this works.
Maybe nobody knows ..."
Xorg.conf(5)
On Tue, May 18, 2010 at 10:58 PM, Aaron Griffin wrote:
> On Tue, May 18, 2010 at 3:47 PM, Sergey Manucharian
> wrote:
> > Excerpts from Linas's message of Tue, 18 May 2010 22:31 +0200:
> >
> >> David C. Rankin wrote:
> >> > Guys,
> >> >
> >> > I'm usually quite good at one-liners, but my simple ones no
> >> > longer work in Arch. Same cli works fine in suse. What have I
> >> > messed up? To wit:
> >> >
> >> >
> >> > What could keep the simple cli from working on Arch? I know
> >> > this stuff worked before updates this morning... What should I look
> >> > at?
> >> Bash was updated from 4.1.5(2) to 4.1.7(2).
> >> I can't reproduce it, though.
> >
> > I cannot reproduce it either and suspect that your "ls" under $() is
> > not the real ls, but an alias. I've played with some, and they indeed
> > produce bad output.
>
> If this is the case, replace "ls" with "/bin/ls" in the above and try again
>
Re: [arch-general] [arch-dev-public] kernel 2.6.34-1
On Tue, May 18, 2010 at 10:49 PM, Nezmer wrote: > FYI, I had this discussion with the radeon guys months ago in IRC. > Apparently, kernel guys (maybe Linus) decided to not add new firmware > files to the kernel tree. That's why we have all those firmware packages > for in-tree modules. Depending on what direction the kernel guys have taken, there is another option worth considering. If firmware is now only added to a separate repository, namely linux-firmware.git [1], it probably wouldn't be a bad idea to switch our kernel firmware package to that [2]. Fedora has done something similar with their linux-firmware [3] package. Anyway, I'm not really sure what the best course of action is here. The above option does seem like a more general and future-proof solution to this kind of issues. As a bonus, it also covers several Intel wireless cards, thus making their respective -ucode packages [4] in [core] redundant. @Devs: The final decision is yours. :) [1] http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=summary [2] http://www.kernel.org/pub/linux/kernel/people/dwmw2/firmware/ [3] http://cvs.fedoraproject.org/viewvc/rpms/linux-firmware/ [4] http://www.archlinux.org/packages/?q=-ucode
Re: [arch-general] BASH no longer does 'for i in $(ls); do ls $i; done'??
On Tue, May 18, 2010 at 3:47 PM, Sergey Manucharian wrote: > Excerpts from Linas's message of Tue, 18 May 2010 22:31 +0200: > >> David C. Rankin wrote: >> > Guys, >> > >> > I'm usually quite good at one-liners, but my simple ones no >> > longer work in Arch. Same cli works fine in suse. What have I >> > messed up? To wit: >> > >> > >> > What could keep the simple cli from working on Arch? I know >> > this stuff worked before updates this morning... What should I look >> > at? >> Bash was updated from 4.1.5(2) to 4.1.7(2). >> I can't reproduce it, though. > > I cannot reproduce it either and suspect that your "ls" under $() is > not the real ls, but an alias. I've played with some, and they indeed > produce bad output. If this is the case, replace "ls" with "/bin/ls" in the above and try again
Re: [arch-general] BASH no longer does 'for i in $(ls); do ls $i; done'??
Excerpts from Linas's message of Tue, 18 May 2010 22:31 +0200: > David C. Rankin wrote: > > Guys, > > > > I'm usually quite good at one-liners, but my simple ones no > > longer work in Arch. Same cli works fine in suse. What have I > > messed up? To wit: > > > > > > What could keep the simple cli from working on Arch? I know > > this stuff worked before updates this morning... What should I look > > at? > Bash was updated from 4.1.5(2) to 4.1.7(2). > I can't reproduce it, though. I cannot reproduce it either and suspect that your "ls" under $() is not the real ls, but an alias. I've played with some, and they indeed produce bad output. Cheers, Sergey
Re: [arch-general] BASH no longer does 'for i in $(ls); do ls $i; done'??
David C. Rankin wrote: > Guys, > > I'm usually quite good at one-liners, but my simple ones no longer work > in > Arch. Same cli works fine in suse. What have I messed up? To wit: > > > What could keep the simple cli from working on Arch? I know this stuff > worked > before updates this morning... What should I look at? > Bash was updated from 4.1.5(2) to 4.1.7(2). I can't reproduce it, though. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [arch-general] BASH no longer does 'for i in $(ls); do ls $i; done'??
On Tue, 18 May 2010 22:17:48 +0200, David C. Rankin wrote: 15:10 nirvana:~/dt/compiz/compizX11> l total 24 drwxr-xr-x 6 david david 4096 May 18 15:04 . drwxr-xr-x 9 david dcr 4096 May 18 15:04 .. drwxr-xr-x 2 david david 4096 May 18 15:03 i586 drwxr-xr-x 2 david david 4096 May 18 15:03 noarch drwxr-xr-x 2 david david 4096 May 18 15:03 src drwxr-xr-x 2 david david 4096 May 18 15:03 x86_64 15:14 alchemy:~/dt/compiz/compiz_11.0> l total 24 drwxr-xr-x 6 david dcr 4096 2010-05-17 23:56 ./ drwxr-xr-x 9 david dcr 4096 2010-05-18 10:28 ../ drwxr-xr-x 2 david dcr 4096 2010-05-18 10:24 i586/ drwxr-xr-x 2 david dcr 4096 2010-05-17 23:56 noarch/ drwxr-xr-x 2 david dcr 4096 2010-05-18 10:22 src/ drwxr-xr-x 2 david dcr 4096 2010-05-18 10:21 x86_64/ You probably did check the aliases. (and I see a difference in the first and second '> l' with the trailing slash. -- Jeroen Op 't Eynde - jer...@xprsyrslf.be - http://xprsyrslf.be To read: http://en.wikipedia.org/wiki/Posting_style#Bottom-posting
Re: [arch-general] BASH no longer does 'for i in $(ls); do ls $i; done'??
On Tue, May 18, 2010 at 16:17, David C. Rankin wrote: > Guys, > > I'm usually quite good at one-liners, but my simple ones no longer > work in > Arch. Same cli works fine in suse. What have I messed up? To wit: In short, you're doing it wrong. http://mywiki.wooledge.org/ParsingLs
[arch-general] BASH no longer does 'for i in $(ls); do ls $i; done'??
Guys,
I'm usually quite good at one-liners, but my simple ones no longer work
in
Arch. Same cli works fine in suse. What have I messed up? To wit:
15:10 nirvana:~/dt/compiz/compizX11> l
total 24
drwxr-xr-x 6 david david 4096 May 18 15:04 .
drwxr-xr-x 9 david dcr 4096 May 18 15:04 ..
drwxr-xr-x 2 david david 4096 May 18 15:03 i586
drwxr-xr-x 2 david david 4096 May 18 15:03 noarch
drwxr-xr-x 2 david david 4096 May 18 15:03 src
drwxr-xr-x 2 david david 4096 May 18 15:03 x86_64
15:11 nirvana:~/dt/compiz/compizX11> for i in $(ls); do ls ${i}; done
ls: cannot access i586: No such file or directory
ls: cannot access noarch: No such file or directory
ls: cannot access src: No such file or directory
ls: cannot access x86_64: No such file or directory
15:11 nirvana:~/dt/compiz/compizX11> for i in $(ls -d ./*); do ls ${i}; done
ls: cannot access ./i586: No such file or directory
ls: cannot access ./noarch: No such file or directory
ls: cannot access ./src: No such file or directory
ls: cannot access ./x86_64: No such file or directory
Huh? Same thing on a suse box:
15:14 alchemy:~/dt/compiz/compiz_11.0> l
total 24
drwxr-xr-x 6 david dcr 4096 2010-05-17 23:56 ./
drwxr-xr-x 9 david dcr 4096 2010-05-18 10:28 ../
drwxr-xr-x 2 david dcr 4096 2010-05-18 10:24 i586/
drwxr-xr-x 2 david dcr 4096 2010-05-17 23:56 noarch/
drwxr-xr-x 2 david dcr 4096 2010-05-18 10:22 src/
drwxr-xr-x 2 david dcr 4096 2010-05-18 10:21 x86_64/
15:15 alchemy:~/dt/compiz/compiz_11.0> for i in $(ls); do ls -1 ${i}; done
compiz-0.8.6-46.1.i586.rpm
compiz-bcop-0.8.4-6.1.i586.rpm
compizconfig-settings-manager-0.8.4-4.4.i586.rpm
compiz-plugins-extra-0.8.6-8.3.i586.rpm
compiz-plugins-extra-devel-0.8.6-8.3.i586.rpm
What could keep the simple cli from working on Arch? I know this stuff
worked
before updates this morning... What should I look at?
--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com
Re: [arch-general] [arch-dev-public] kernel 2.6.34-1
On Tue, May 18, 2010 at 04:28:43PM +0200, Thomas B?chler wrote: > Am 18.05.2010 16:06, schrieb Evangelos Foutras: > > In particular, notice Alex's reply stating: > > > > --8< > > In general, microcode is slowly being moved out of the kernel and into > > the Linux firmware tree: > > http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree > > Eventually all of the radeon microcode will end up out up in that tree. > > --8< > > > > I'm not sure what this means for our kernel26-firmware package, but I > > believe we would want to ship the files included in the "Linux firmware > > tree". > > No, we don't. We want to and will ship all the firmware files that are > included in the current Linux release (make install_firmware). > > If the developers are not capable of ensuring that the driver and > firmware versions in the Linux releases work together, that is a bug on > their end. In this case, it seems they move code out of the radeon > driver more quickly than into the firmware files - I am not willing to > fix this screwup for them. > FYI, I had this discussion with the radeon guys months ago in IRC. Apparently, kernel guys (maybe Linus) decided to not add new firmware files to the kernel tree. That's why we have all those firmware packages for in-tree modules.
Re: [arch-general] [arch-dev-public] kernel 2.6.34-1
Am Tue, 18 May 2010 17:55:12 +0200 schrieb Thomas Bächler : > > However, these firmware files are needed for R600/R700/Evergreen > > cards [1], therefore I see two options: > > > > 1) radeon_ucode [2] can be brought to [extra] and an announcement > > added to the front page informing users about this. (The package > > should also be renamed to radeon-ucode in order for it to be > > consistent with the rest of the firmware packages.) > > This sounds like a good idea. This could even be included in core AND > installed on the installation ISO. Andy, this seems like your area, > what do you think? The firmware belongs more to the kernel. At least I don't have a card to test it. If you want to bring it to the official repos go on. But I think it's not in the kernel for good reasons. Probably license issues. I haven't checked that. I don't see a problem keeping the firmware in AUR until the kernel guys pick it up. We could also add an optional dependency or post an install msg in the kernel pkg or radeon ddx pkg. Your choice. -Andy signature.asc Description: PGP signature
Re: [arch-general] starting network:fail[eth0 wasn't connected] How to enable without reboot?
On May 18, 2010, at 1:53 PM, Dan McGee wrote: > On Tue, May 18, 2010 at 1:45 PM, Joe(theWordy)Philbrook > wrote: >> >> Currently my pc is a laptop. I don't use a wireless interface. I >> connect to the Internet via cable broadband with a wired Ethernet >> connection and DHCP... This id very reliable. I can usually >> disconnect >> the laptop from the Ethernet cable and bring it into the livingroom >> for various offline use. Then when I bring it back to my desk, all I >> usually have to to is plug the Ethernet cable back in and wait a few >> seconds and the Internet will start to work again. >> >> BUT that is contingent on the Ethernet cable having been connected >> during boot up. So if for example I were to boot up my laptop in the >> livingroom where there isn't an Ethernet connection the boot process >> will delay at the point where it's screen message says its starting >> the network. Then it says it failed and continues setting everything >> else up. >> >> At this point, if I bring the laptop back to the desk, and plug in >> the >> Ethernet cable, it doesn't automatically connect. I tried: >> >> # ifconfig eth0 up >> >> but ping still doesn't find my ISP >> >> What am I missing > > Your dhcp process didn't start either, so you need to start one of > those. Something as simple as `dhcpcd -i eth0` might work. > > -Dan You may need to modprobe the module for your Ethernet card. Try lsmod to get it's name.
Re: [arch-general] starting network:fail[eth0 wasn't connected] How to enable without reboot?
Man, I don't that's the point, but here I need to do this: ifconfig eth0 0.0.0.0 -- * R*afael *C*orreia 2010/5/18 Joe(theWordy)Philbrook > > Currently my pc is a laptop. I don't use a wireless interface. I > connect to the Internet via cable broadband with a wired Ethernet > connection and DHCP... This id very reliable. I can usually disconnect > the laptop from the Ethernet cable and bring it into the livingroom > for various offline use. Then when I bring it back to my desk, all I > usually have to to is plug the Ethernet cable back in and wait a few > seconds and the Internet will start to work again. > > BUT that is contingent on the Ethernet cable having been connected > during boot up. So if for example I were to boot up my laptop in the > livingroom where there isn't an Ethernet connection the boot process > will delay at the point where it's screen message says its starting > the network. Then it says it failed and continues setting everything > else up. > > At this point, if I bring the laptop back to the desk, and plug in the > Ethernet cable, it doesn't automatically connect. I tried: > > # ifconfig eth0 up > > but ping still doesn't find my ISP > > What am I missing > > -- > | ~^~ ~^~ > |Joe (theWordy) Philbrook > | ^J(tWdy)P > |\___/ <> > >
Re: [arch-general] starting network:fail[eth0 wasn't connected] How to enable without reboot?
On Tue, May 18, 2010 at 1:45 PM, Joe(theWordy)Philbrook wrote: > > Currently my pc is a laptop. I don't use a wireless interface. I > connect to the Internet via cable broadband with a wired Ethernet > connection and DHCP... This id very reliable. I can usually disconnect > the laptop from the Ethernet cable and bring it into the livingroom > for various offline use. Then when I bring it back to my desk, all I > usually have to to is plug the Ethernet cable back in and wait a few > seconds and the Internet will start to work again. > > BUT that is contingent on the Ethernet cable having been connected > during boot up. So if for example I were to boot up my laptop in the > livingroom where there isn't an Ethernet connection the boot process > will delay at the point where it's screen message says its starting > the network. Then it says it failed and continues setting everything > else up. > > At this point, if I bring the laptop back to the desk, and plug in the > Ethernet cable, it doesn't automatically connect. I tried: > > # ifconfig eth0 up > > but ping still doesn't find my ISP > > What am I missing Your dhcp process didn't start either, so you need to start one of those. Something as simple as `dhcpcd -i eth0` might work. -Dan
[arch-general] starting network:fail[eth0 wasn't connected] How to enable without reboot?
Currently my pc is a laptop. I don't use a wireless interface. I connect to the Internet via cable broadband with a wired Ethernet connection and DHCP... This id very reliable. I can usually disconnect the laptop from the Ethernet cable and bring it into the livingroom for various offline use. Then when I bring it back to my desk, all I usually have to to is plug the Ethernet cable back in and wait a few seconds and the Internet will start to work again. BUT that is contingent on the Ethernet cable having been connected during boot up. So if for example I were to boot up my laptop in the livingroom where there isn't an Ethernet connection the boot process will delay at the point where it's screen message says its starting the network. Then it says it failed and continues setting everything else up. At this point, if I bring the laptop back to the desk, and plug in the Ethernet cable, it doesn't automatically connect. I tried: # ifconfig eth0 up but ping still doesn't find my ISP What am I missing -- | ~^~ ~^~ |Joe (theWordy) Philbrook | ^J(tWdy)P |\___/ <>
Re: [arch-general] [arch-dev-public] kernel 2.6.34-1
Am 18.05.2010 17:26, schrieb Evangelos Foutras: > I see your point. It seems that upstream kernel developers don't wish to > ship firmware files, which is... not ideal for downstream (e.g. Arch). That is weird. Many other firmware files are being shipped with Linux and it would make sense here. > However, these firmware files are needed for R600/R700/Evergreen cards > [1], therefore I see two options: > > 1) radeon_ucode [2] can be brought to [extra] and an announcement added > to the front page informing users about this. (The package should also > be renamed to radeon-ucode in order for it to be consistent with the > rest of the firmware packages.) This sounds like a good idea. This could even be included in core AND installed on the installation ISO. Andy, this seems like your area, what do you think? > 2) Alternately, the radeon firmware files could be included in the > kernel26-firmware package. I don't like that, as the kernel26-firmware package is supposed to ship the firmware files included in the Linux source. > I like the first option better because it keeps things separate. Agreed. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] kernel 2.6.34-1
On 18/05/10 17:28, Thomas Bächler wrote: Am 18.05.2010 16:06, schrieb Evangelos Foutras: In particular, notice Alex's reply stating: --8< In general, microcode is slowly being moved out of the kernel and into the Linux firmware tree: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree Eventually all of the radeon microcode will end up out up in that tree. --8< I'm not sure what this means for our kernel26-firmware package, but I believe we would want to ship the files included in the "Linux firmware tree". No, we don't. We want to and will ship all the firmware files that are included in the current Linux release (make install_firmware). If the developers are not capable of ensuring that the driver and firmware versions in the Linux releases work together, that is a bug on their end. In this case, it seems they move code out of the radeon driver more quickly than into the firmware files - I am not willing to fix this screwup for them. I see your point. It seems that upstream kernel developers don't wish to ship firmware files, which is... not ideal for downstream (e.g. Arch). However, these firmware files are needed for R600/R700/Evergreen cards [1], therefore I see two options: 1) radeon_ucode [2] can be brought to [extra] and an announcement added to the front page informing users about this. (The package should also be renamed to radeon-ucode in order for it to be consistent with the rest of the firmware packages.) 2) Alternately, the radeon firmware files could be included in the kernel26-firmware package. I like the first option better because it keeps things separate. [1] http://wiki.x.org/wiki/radeonBuildHowTo#TroubleshootingExtraFirmwareforR600.2BAC8-R700.2BAC8-Evergreen [2] http://aur.archlinux.org/packages.php?ID=33016
[arch-general] nut-2.4.3-1 still having problems with usbhid-ups driver after update to kernel26-2.6.33.4-1
Listmates, The network-ups-tools-2.4.3-1 package is still having problems with the usbhid-ups driver. I opened http://bugs.archlinux.org/task/19351 on 5/3, but it still isn't assigned to anyone. I don't know if that's normal or not? After update to kernel26-2.6.33.4-1, I thought I would re-try network-ups-tools-2.4.3-1 to see if it might have been related to the last kernel. No luck, the current nut package fails in the same way. Returning to network-ups-tools-2.4.1-2, it works fine with kernel26-2.6.33.4-1. I have specified the details and log errors in task/19351 and updated it with the latest info after install of kernel26-2.6.33.4-1. Is there anything else you would like me to provide? If so, just let me know. Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] [arch-dev-public] kernel 2.6.34-1
Am 18.05.2010 16:06, schrieb Evangelos Foutras: > In particular, notice Alex's reply stating: > > --8< > In general, microcode is slowly being moved out of the kernel and into > the Linux firmware tree: > http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree > Eventually all of the radeon microcode will end up out up in that tree. > --8< > > I'm not sure what this means for our kernel26-firmware package, but I > believe we would want to ship the files included in the "Linux firmware > tree". No, we don't. We want to and will ship all the firmware files that are included in the current Linux release (make install_firmware). If the developers are not capable of ensuring that the driver and firmware versions in the Linux releases work together, that is a bug on their end. In this case, it seems they move code out of the radeon driver more quickly than into the firmware files - I am not willing to fix this screwup for them. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] kernel 2.6.34-1
On 17/05/10 22:24, Mauro Santos wrote: I have noticed that if I don't have radeon_ucode [1] installed then early or late KMS don't work and I get just a black screen. However I didn't wait 1 minute to check if after a while the boot process resumes. [1] http://aur.archlinux.org/packages.php?ID=33016 My experience with an integrated Radeon HD 4200 card and KMS is similar. Without radeon_ucode, everything will work fine until I need to resume from suspend-to-ram. The screen will then just stay in standby mode for about a minute (a couple of seconds, give or take) before it'll come to life again. With either KMS disabled or radeon_ucode installed, this problem doesn't occur. It appears that, in my case, the card requests a firmware file named R600_rlc.bin which is included in radeon_ucode. If you google this file, you'll find several instances in which this file has been discussed. Some insightful discussion is here: http://lkml.org/lkml/2010/1/26/169. In particular, notice Alex's reply stating: --8< In general, microcode is slowly being moved out of the kernel and into the Linux firmware tree: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree Eventually all of the radeon microcode will end up out up in that tree. --8< I'm not sure what this means for our kernel26-firmware package, but I believe we would want to ship the files included in the "Linux firmware tree". What do you think? :)
Re: [arch-general] pkg-proxy ?
On Mon, May 17, 2010 at 8:46 PM, Wolfgang wrote: > > Hi, > >>> >> - not usable from arch installer. i assume i cant use it as proxy >>> >> setting what is asked in the installer. but maybe i can somehow else >>> >> use it from the installer? > > I'm doing something like this for a couple of centos machines... using > apache as a caching reverse proxy (also serving kickstart files). > > > # the usual servername, logfile, etc... > LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so > LoadModule disk_cache_module /usr/lib/apache2/modules/mod_disk_cache.so > CacheRoot /home/sites/ks/cache > CacheEnable disk / > CacheDirLevels 2 > CacheDirLength 8 > CacheMaxFileSize 2097152000 > > ProxyRequests off > ProxyPass /centos/ http://ftp.halifax.rwth-aachen.de/centos/ > > > it should just work with something like: > ProxyPass /archlinux/ http://some.mirror/path_to/archlinux/ > point your installers there and you should be fine > > I know you said squid is to much hassle... maybe your more comfortable > with apache ;) > > Regards, > Wolfgang sounds like a nice workaround. but does this cache the packages twice ? (apache cache and pacman cache)
Re: [arch-general] pkg-proxy ?
On Mon, May 17, 2010 at 7:35 PM, C Anthony Risinger wrote: > On May 17, 2010, at 12:22 PM, Gregory Eric Sanderson > wrote: > >> On Mon, May 17, 2010 at 10:45 AM, Rogutės Sparnuotos > m >>> wrote: >> >>> Andre Osku Schmidt (2010-05-16 13:33): 2010/5/16 Ng Oon-Ee : > On Sat, 2010-05-15 at 23:47 +0200, Andre "Osku" Schmidt wrote: >> 2010/5/15 Ng Oon-Ee : >>> Check out 'pkgd' >> >> thanks, works nicely! >> >> only couple issues that would be nice if it could do too (or >> already >> does, and i just didn't find out how) >> >> - not usable from arch installer. i assume i cant use it as proxy >> setting what is asked in the installer. but maybe i can somehow >> else >> use it from the installer? > > You would need (AFAIK) to install some packages first to start > using >>> it. >> >> - if the package is not found on the pkgd server, it will be >> loaded >> from internet to the client machine. is there a way to tell the >> pkgd >> server to download it and serve it to the client ? > > Not that I'm aware off. Talk to Xyne. > > Perhaps you'd just want to set up your own mirror. There's > projects for > that as well in the AUR, just search. do you mean a general mirroring tool ? as i didn't found anything pkg specific mirror tool... and wouldn't a mirror tool require my server to have ALL core/extra/community packages ? how big are those repos ? >>> <...> >>> >>> I don't really remember your initial question, but I use one package >>> directory for 3 computers by simply having a central /var/cache/ >>> pacman, >>> which I then mount read-write with samba. To use it from the >>> installer, >>> you would have to install 'smbclient' after booting. >>> >> >> That solution is also mentioned on the wiki, but I see 2 >> disadvatages to >> mounting /var/cache/pacman through the network. >> 1. If you're on a laptop and not at home, you don't have access to >> your >> packages, and If you want to install packages anyway you have to >> manually >> unmount, install, and remove the packages from the directory to to >> cause >> problems for when it will be remounted. >> 2. Although rare, if or have frequent network connectivity problems >> (for >> example, your connection goes dead in the middle of copying a file) >> then it >> becomes a hassle > > This is the same conclusion I came to, and why I started the > "pacproxy" app... My sshfs mount would be down without me knowing; I > just don't think it's a very good/elegant solution. > > I intended pacproxy to be an apt-proxy clone, with ABS "auto > repository" support, and foriegn ABS support (so I could have separate > build machines, and be able to broadcast their ABS tree as an > independent repo) right now though, it works well for simple proxying > and caching, and is a viable solution to the OP's problem. > > Perhaps we could make it more feature complete, and include it in the > official repos as a more comprehensive solution to fickle network > mounting. > > Else I will finish it eventually :-) > > C Anthony > hi, this sounds perfect! http://bbs.archlinux.org/viewtopic.php?id=87115 could you put it in a VCS (like gitorious.org) ? and a more verbose howto ? like: - does the code in "how to use" box at the forum post go in the pacproxy machine configs ? - what/where do i set/use this in the client(s) ? - whats /archlinux dir ? should i create it, how ? - can't i use /var/cache/pacman/pkg/ ? - does this work with the arch installer ? these may be "stupid" questions, but i'm still pretty new to Arch way of things. cheers .andre
Re: [arch-general] Question regarding the ArchLinux iso core image
Am 18.05.2010 13:42, schrieb vlad: > Though "-r" was set to "/mnt/root" the install script seems to update > /etc/ssl/certs. > I am not really sure if it actually applied to the new root "/mnt/root" > or only to /etc/ssl. It was some time ago. > I remember I reran "/usr/sbin/update-ca-certificates --fresh" > when I booted into the new system. Before executing the install scriptlet, pacman chroots into /mnt/root. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Question regarding the ArchLinux iso core image
On Tue, May 18, 2010 at 09:26:51PM +1000, Allan McRae wrote: > On 18/05/10 21:21, Matthew Monaco wrote: > >On 05/18/2010 03:34 AM, Jan de Groot wrote: > >>On Tue, 2010-05-18 at 03:17 -0400, Keith Hinton wrote: > >>>Hi. > >>>I've recently seen threads on this list pertaining to interesting > >>>issues with the Arch Linux core isos. > >>>I haven't had that problem in my primary tests of those Isos in > >>>particular. > >>>Is there any reason why a successful installation may occur in one > >>>environment over another? Or is this a common Linux problem. > >>>Thanks for answering my question. > >>>I hope that the rest of you folks have successful Core installations, > >>>however a net-install is the only real way to isntall Arch Linux. > >>>I do not see the point of the core installer media, personally. Why > >>>would one wish to use that? A snapshot will become outdated in a > >>>flash, and all of you archers know this. As soon as a newer package > >>>version is available the entire snapshot is outdated instantly. Or > >>>will be, given a few weeks/months/years/whatever. > >>>I therefore have always installed from what I believe to be the > >>>Arch-Way, wich is installing via the Internet alone to have an > >>>updated system. > >>>Does anyone agree/disagree with my idea on the proper way to install > >>>Arch? :D > >>>Regards, --Keith > >> > >>My prefered way of installing any linux distribution is using bootstrap > >>tools. For Debian this is debootstrap, for Archlinux this is pacman -r. > >>The point of having an installer with packages on the ISO is that you > >>don't always have the possibility to do a network installation. > >> > >> > > > >What about the install scripts then? pacman -r (and -b) don't > >necessarily assure that the install scripts behave properly. > > > > Really... they should do. They do? from pacman.log: " [2010-04-29 23:15] warning: /mnt/root/etc/ssl/openssl.cnf installed as /mnt/root/etc/ssl/openssl.cnf.pacnew │ [2010-04-29 23:15] upgraded openssl (0.9.8l-1 -> 1.0.0-2) │ [2010-04-29 23:15] Clearing symlinks in /etc/ssl/certs...done. │ [2010-04-29 23:15] Updating certificates in /etc/ssl/certs... 141 added, 0 removed; done. │ [2010-04-29 23:15] Running hooks in /etc/ca-certificates/update.ddone. │ [2010-04-29 23:15] upgraded ca-certificates (20090814-2 -> 20090814-3) " Though "-r" was set to "/mnt/root" the install script seems to update /etc/ssl/certs. I am not really sure if it actually applied to the new root "/mnt/root" or only to /etc/ssl. It was some time ago. I remember I reran "/usr/sbin/update-ca-certificates --fresh" when I booted into the new system. --
Re: [arch-general] Question regarding the ArchLinux iso core image
Am 18.05.2010 13:26, schrieb Allan McRae: >> What about the install scripts then? pacman -r (and -b) don't >> necessarily assure that the install scripts behave properly. >> > > Really... they should do. There are certain problems if you don't create $BASE/dev/null beforehand or bind-mount a fully-populated /dev folder into $BASE. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Question regarding the ArchLinux iso core image
On 18/05/10 21:21, Matthew Monaco wrote: On 05/18/2010 03:34 AM, Jan de Groot wrote: On Tue, 2010-05-18 at 03:17 -0400, Keith Hinton wrote: Hi. I've recently seen threads on this list pertaining to interesting issues with the Arch Linux core isos. I haven't had that problem in my primary tests of those Isos in particular. Is there any reason why a successful installation may occur in one environment over another? Or is this a common Linux problem. Thanks for answering my question. I hope that the rest of you folks have successful Core installations, however a net-install is the only real way to isntall Arch Linux. I do not see the point of the core installer media, personally. Why would one wish to use that? A snapshot will become outdated in a flash, and all of you archers know this. As soon as a newer package version is available the entire snapshot is outdated instantly. Or will be, given a few weeks/months/years/whatever. I therefore have always installed from what I believe to be the Arch-Way, wich is installing via the Internet alone to have an updated system. Does anyone agree/disagree with my idea on the proper way to install Arch? :D Regards, --Keith My prefered way of installing any linux distribution is using bootstrap tools. For Debian this is debootstrap, for Archlinux this is pacman -r. The point of having an installer with packages on the ISO is that you don't always have the possibility to do a network installation. What about the install scripts then? pacman -r (and -b) don't necessarily assure that the install scripts behave properly. Really... they should do.
Re: [arch-general] Question regarding the ArchLinux iso core image
On 05/18/2010 03:34 AM, Jan de Groot wrote: On Tue, 2010-05-18 at 03:17 -0400, Keith Hinton wrote: Hi. I've recently seen threads on this list pertaining to interesting issues with the Arch Linux core isos. I haven't had that problem in my primary tests of those Isos in particular. Is there any reason why a successful installation may occur in one environment over another? Or is this a common Linux problem. Thanks for answering my question. I hope that the rest of you folks have successful Core installations, however a net-install is the only real way to isntall Arch Linux. I do not see the point of the core installer media, personally. Why would one wish to use that? A snapshot will become outdated in a flash, and all of you archers know this. As soon as a newer package version is available the entire snapshot is outdated instantly. Or will be, given a few weeks/months/years/whatever. I therefore have always installed from what I believe to be the Arch-Way, wich is installing via the Internet alone to have an updated system. Does anyone agree/disagree with my idea on the proper way to install Arch? :D Regards, --Keith My prefered way of installing any linux distribution is using bootstrap tools. For Debian this is debootstrap, for Archlinux this is pacman -r. The point of having an installer with packages on the ISO is that you don't always have the possibility to do a network installation. What about the install scripts then? pacman -r (and -b) don't necessarily assure that the install scripts behave properly.
Re: [arch-general] Question regarding the ArchLinux iso core image
Am 18.05.2010 11:56, schrieb Fons Adriaensen: > I agree (with Ng Oon-Ee). In one of the situations I work in > the install is going through an http proxy that systematically > corrupts some packages (always the same, IIRC perl, man-pages, > and another one) Just a side remark: In my opinion, whenever you provide internet access to a "client" (whatever that means), altering the traffic should be illegal and punishable by imprisonment. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Question regarding the ArchLinux iso core image
On Tue, May 18, 2010 at 05:37:38PM +0800, Ng Oon-Ee wrote: > > Does anyone agree/disagree with my idea on the proper way to install Arch? > > :D > > Regards, --Keith > > > I disagree. Some of us do not have fast/reliable internet connections, > and would rather postpone the search for reliable download speeds till > after the machine is bare-bones working (can boot, has network, > basically has all of core) instead of in between the install process. I agree (with Ng Oon-Ee). In one of the situations I work in the install is going through an http proxy that systematically corrupts some packages (always the same, IIRC perl, man-pages, and another one), making the netinstall fail. No chance to get this fixed, unless you have months of time to waste discussing with city IT officials who think that Linux is evil. Once a basic system is set up it's possible to work around this, with the installer it isn't. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
Re: [arch-general] Question regarding the ArchLinux iso core image
On Tue, May 18, 2010 at 3:17 PM, Keith Hinton wrote: > Hi. > I've recently seen threads on this list pertaining to interesting issues with > the Arch Linux core isos. > I haven't had that problem in my primary tests of those Isos in particular. > Is there any reason why a successful installation may occur in one > environment over another? Or is this a common Linux problem. > Thanks for answering my question. > I hope that the rest of you folks have successful Core installations, however > a net-install is the only real way to isntall Arch Linux. > I do not see the point of the core installer media, personally. Why would one > wish to use that? A snapshot will become outdated in a flash, and all of you > archers know this. As soon as a newer package version is available the entire > snapshot is outdated instantly. Or will be, given a few > weeks/months/years/whatever. > I therefore have always installed from what I believe to be the Arch-Way, > wich is installing via the Internet alone to have an updated system. > Does anyone agree/disagree with my idea on the proper way to install Arch? :D > Regards, --Keith > I disagree. Some of us do not have fast/reliable internet connections, and would rather postpone the search for reliable download speeds till after the machine is bare-bones working (can boot, has network, basically has all of core) instead of in between the install process.
Re: [arch-general] Fw: NDN: Question regarding the ArchLinux iso core image
On Tue, 2010-05-18 at 05:04 -0400, Keith Hinton wrote: > Hey guys, I wanted to forward this message. > Has anyone ever gotten this? I get this consistently when posting messages to > Arch-General, from the following email adddress. > Hope someone can tel me why this happens-or talk to whomever owns > Arch-general, and update it. > Is this a problem with the mailman configuration on Arch Linux's server that > runs Arch-general? Thanks. > Obviously my post was delivered but I don't know why this happens. > Note: this doesn't happen with Arch-Releng. > Sorry for posting this hear, but there you are. > > > From: Post Office > Sent: Tuesday, May 18, 2010 3:17 AM > To: Keith Hinton > Subject: NDN: [arch-general] Question regarding the ArchLinux iso core image > > > Sorry. Your message could not be delivered to: > > > Joey Kingery (Mailbox has been deleted. Try re-entering the address.) That's because you have the reply-to header set. Mailman replaces this field with arch-general@archlinux.org, but if you already have it set in the mails you send, it just appends the address. When the mail bounces, you'll get the bounce too.
[arch-general] Fw: NDN: Question regarding the ArchLinux iso core image
Hey guys, I wanted to forward this message. Has anyone ever gotten this? I get this consistently when posting messages to Arch-General, from the following email adddress. Hope someone can tel me why this happens-or talk to whomever owns Arch-general, and update it. Is this a problem with the mailman configuration on Arch Linux's server that runs Arch-general? Thanks. Obviously my post was delivered but I don't know why this happens. Note: this doesn't happen with Arch-Releng. Sorry for posting this hear, but there you are. From: Post Office Sent: Tuesday, May 18, 2010 3:17 AM To: Keith Hinton Subject: NDN: [arch-general] Question regarding the ArchLinux iso core image Sorry. Your message could not be delivered to: Joey Kingery (Mailbox has been deleted. Try re-entering the address.)
Re: [arch-general] Question regarding the ArchLinux iso core image
On Tue, 2010-05-18 at 03:17 -0400, Keith Hinton wrote: > Hi. > I've recently seen threads on this list pertaining to interesting issues with > the Arch Linux core isos. > I haven't had that problem in my primary tests of those Isos in particular. > Is there any reason why a successful installation may occur in one > environment over another? Or is this a common Linux problem. > Thanks for answering my question. > I hope that the rest of you folks have successful Core installations, however > a net-install is the only real way to isntall Arch Linux. > I do not see the point of the core installer media, personally. Why would one > wish to use that? A snapshot will become outdated in a flash, and all of you > archers know this. As soon as a newer package version is available the entire > snapshot is outdated instantly. Or will be, given a few > weeks/months/years/whatever. > I therefore have always installed from what I believe to be the Arch-Way, > wich is installing via the Internet alone to have an updated system. > Does anyone agree/disagree with my idea on the proper way to install Arch? :D > Regards, --Keith My prefered way of installing any linux distribution is using bootstrap tools. For Debian this is debootstrap, for Archlinux this is pacman -r. The point of having an installer with packages on the ISO is that you don't always have the possibility to do a network installation.
[arch-general] Question regarding the ArchLinux iso core image
Hi. I've recently seen threads on this list pertaining to interesting issues with the Arch Linux core isos. I haven't had that problem in my primary tests of those Isos in particular. Is there any reason why a successful installation may occur in one environment over another? Or is this a common Linux problem. Thanks for answering my question. I hope that the rest of you folks have successful Core installations, however a net-install is the only real way to isntall Arch Linux. I do not see the point of the core installer media, personally. Why would one wish to use that? A snapshot will become outdated in a flash, and all of you archers know this. As soon as a newer package version is available the entire snapshot is outdated instantly. Or will be, given a few weeks/months/years/whatever. I therefore have always installed from what I believe to be the Arch-Way, wich is installing via the Internet alone to have an updated system. Does anyone agree/disagree with my idea on the proper way to install Arch? :D Regards, --Keith
