[arch-general] ALSA volume control
My sound card has two sockets each for mic & output. One set in the front & another in the rear. I connect headphone to the front one and the rear one is connected to a power amplifier. I can see headphone control in alsamixer, kmix, but I can't adjust its volume separately, only mute/unmute it. What tweaks are needed to get this feature? -- Regards, Nilesh Govindarajan Facebook: http://www.facebook.com/nilesh.gr Twitter: http://twitter.com/nileshgr Website: http://www.itech7.com VPS Hosting: http://www.itech7.com/a/vps
Re: [arch-general] /etc/profile PATH variable wrong
On Sun, 15 Aug 2010, Chris Brannon wrote: Jude DaShiell writes: In order for that to be correct it needs to also have :/usr/local/bin inside of the quote marks. The /usr/local/bin directory on Linux systems like slackware and debian is where stuff gets put that anyone can execute that's on the system. I suspect that /usr/local/bin is excluded from the default $PATH to encourage good system administration habits. I.E., all of the software installed on a system should be managed by the package manager. When I used Slackware, /usr/local was the dumping ground where I placed all of the software that I built from source. It was an uncontrolled mess. I'm really ashamed to admit it. Keeping /usr/local/bin out of $PATH discourages people from using ./configure, make, make install as their package "management" procedure. The hand-written, system-specific scripts pose a problem, though. Does anyone use makepkg + pacman to manage these? Is it worth the extra effort? -- Chris Production systems probably don't need /usr/local/ hierarchy let alone paths to it. Development and testing systems would find them very useful for building foreign tar balls though. Use of standards enables everyone in a community to sit down at another machine and have a pretty good idea where things ought to be located and what paths ought to be set. That in itself can properly be viewed as a security check because when things just don't look right anymore on a system they may have to be restored from a backup (script kitties) may have been having fun. As for my own uses, I put development systems up because when new packages become available they're not always available for the particular Linux in use and I want to find out can these work and what needs to be done to get them working.
Re: [arch-general] rankmirrors and new mirrrorlist format
The only reason I bought this up at all was because on more than one Linux distro site there's requests for people to use mirrors that are geographically close to them since the admins of those sites apparently check logs and kick off people that are very far away from the download sites. I agree with you in these days of broad band connections and ethernet cards such things maybe ought not to matter all that much but apparently they do to other webmasters and ftpadmins. On Sat, 14 Aug 2010, C Anthony Risinger wrote: On Sat, Aug 14, 2010 at 8:27 PM, Jude DaShiell wrote: One of the more important fields missing from many Linux distros mirror lists is the geographical location field that would provide a country and a state/province for each mirror. That information is stored in some data base on the internet, but not everybody who looks at a mirror list for the first time is necessarily going to know which tool to send the list through to get all those geographical locations appended to that mirror list. A guess on my part would be the whois data base but what command to run to get the capacity the url, and the geographic locations out in a mirror list and only get that information I don't yet know. i think the geographic info would be somewhat superfluous; while i don't know of a command offhand to provide this information, the IP address of mirrors can be geolocated. additionally, geographic location has little to do with your network location... when i lived in montana (USA), every single packet i sent was routed through salt lake city, utah, several hundred miles away, before going anywhere else. if anything, rankmirrors itself could provide this information; but it wouldn't be that useful in deciding on a mirror. just get the top 6 or so, pick one that works well, and forget about it :-) kernel.org works fine for me. C Anthony
[arch-general] "Configuring System Clock" event FAIL at start-up
This a strange one: I left my system running for about 8 hours today (had a brainstorm session for upcoming Software Freedom Day) and when I came back I noticed some weird behaviour with the mouse pointer, so I decided reboot. Now I have a red FAIL notice when "Configuring System Clock". I already check BIOS and there seems to no problem there, ¿what can be happen? (already tried serching the forum but haven't found any related issue) Greetings. -Martín
Re: [arch-general] [arch-dev-public] [signoff] make-3.82-1
On 22/08/10 06:11, Florian Pritz wrote: On 15.08.2010 00:20, Tobias Powalowski wrote: Am Sonntag 15 August 2010 schrieb Allan McRae: On 15/08/10 04:37, Tobias Powalowski wrote: Am Donnerstag 12 August 2010 schrieb Allan McRae: Upstream release announcement: http://groups.google.com/group/gnu.announce/browse_thread/thread/d6a3f56 91a b08a0a# kernel breaks with this make version. Don't think we should move it. Any chance of slightly more details than "breaks"? Allan Stops while trying to copy firmware, cannot create $pkgdir/lib/firmware/./ I haven't tested that much, but on my box the MAKEFLAGS are sort of ignored. Though it's a bit complicated: in the PKGBUILD: MAKEFLAGS="-j12" make bzImage modules -> 1 thread make -j12 bzImage modules -> 12 threads on the shell: both -> 12 threads Downgrading to 3.81-5 fixes the 1 thread problem. Maybe this has to do something with the env? I do not see this... My environmental makeflags are definitely being applied. Allan
[arch-general] K3b
I am having some issues with K3b Under KDE4 ( yes I hate it) When I start K3b it detects a blank dvd in the dvd writer but when selecting the burn image tool from the menu it does not reconize the blank dvd. I looked into the frums and the wiki but didn't find anything that was helpful
Re: [arch-general] [arch-dev-public] [signoff] make-3.82-1
On 15.08.2010 00:20, Tobias Powalowski wrote:
> Am Sonntag 15 August 2010 schrieb Allan McRae:
>> On 15/08/10 04:37, Tobias Powalowski wrote:
>> > Am Donnerstag 12 August 2010 schrieb Allan McRae:
>> >> Upstream release announcement:
>> >> http://groups.google.com/group/gnu.announce/browse_thread/thread/d6a3f56
>> >> 91a b08a0a#
>> >
>> > kernel breaks with this make version.
>> > Don't think we should move it.
>>
>> Any chance of slightly more details than "breaks"?
>>
>> Allan
> Stops while trying to copy firmware, cannot create $pkgdir/lib/firmware/./
I haven't tested that much, but on my box the MAKEFLAGS are sort of
ignored. Though it's a bit complicated:
in the PKGBUILD:
MAKEFLAGS="-j12" make bzImage modules -> 1 thread
make -j12 bzImage modules -> 12 threads
on the shell:
both -> 12 threads
Downgrading to 3.81-5 fixes the 1 thread problem. Maybe this has to do
something with the env?
--
Florian Pritz -- {flo,bluewi...@server-speed.net
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] 2.6.35-ARCH panic in VirtualBox 3.2.8-1
@Madhurya: actually I was ironic about that - please note I didn't wanted to talk bad about *buntu-land, I myself get started in GNU/Linux thanks to Ubuntu. Of course adding features isn't wrong, but I used that word to name an automatic process that goes straight against Arch's spirit if implemented at a core level, and only realized that after reading Thomas reply - see this link please [0]. There's a direct relationship between automation and simplicity: you can't get both at the same time all the time. While an automatic system don't have to be complicated per-se, it *will* take away your freedom and control over the processes it executes again going against Arch's way. One ot the things I like most of this distro is the plenty space it gives the user to do virtually anything while remaining ultra poweful and easy enough to use without stumbling with too much low level tasks in your daily use. Personally I *allways* backup before any important/huge update/upgrade. Anthony's proposed solution is cool, but until that finally arrives I think that creating a simple script and putting it in the path will be enough to backup kernels (also you'll need to add manually the menu entry to whatever boot manager you use). Regards, -Martín [0] http://wiki.archlinux.org/index.php/The_Arch_Way
Re: [arch-general] 2.6.35-ARCH panic in VirtualBox 3.2.8-1
On Aug 21, 2010, at 8:25 AM, Madhurya Kakati wrote: > On Sat, Aug 21, 2010 at 6:24 PM, Martín Cigorraga > wrote: >> Hi Thomas, >> >> In fact I agree with you. If we start adding one 'feature' after >> another we >> will end with a *buntu system in the near future. >> List, please forgot my mail, thanks. >> > > Whats wrong with adding features? This functionality [kernel backup] could be provided by a pacman addon via the (proposed) libalpm hooks mechanism, but it doesn't belong in pacman core. If one were to implement such hooks (hello out there there there...), a package could be created providing this facility. C Anthony [mobile]
Re: [arch-general] [signoff] kernel26 2.6.35.2-1
On 08/21/2010 06:17 PM, Ng Oon-Ee wrote: On Sat, 2010-08-21 at 18:51 +0530, Madhurya Kakati wrote: On Sat, Aug 21, 2010 at 4:53 PM, Lauri Niskanen wrote: On 08/21/2010 01:33 PM, Lukáš Jirkovský wrote: noob question: what does this signoff means? Basically it means that it works OK for you and you are willing to "sign off the declaration the package is OK and can be moved to [core]." Usually it's not used for packages from [extra] or [community]. Generally packages only need signoffs from developers on arch-dev mailing list. Sometimes (like with kernel26) public signoffs are wanted. -- Ape Thanks! :D I wasn't actually aware that public signoffs are wanted for kernel26. As far as I can remember some packages specifically request user signoffs due to lack of usage among devs (and those eventually get dropped from core in my observation). Any simple list as to which packages users should help signoff? Users should signoff only when requested on this mailing list. -- Ape
Re: [arch-general] [signoff] kernel26 2.6.35.2-1
On Sat, 2010-08-21 at 18:51 +0530, Madhurya Kakati wrote: > On Sat, Aug 21, 2010 at 4:53 PM, Lauri Niskanen wrote: > > On 08/21/2010 01:33 PM, Lukáš Jirkovský wrote: > >>> > >>> noob question: what does this signoff means? > >>> > >> > >> Basically it means that it works OK for you and you are willing to > >> "sign off the declaration the package is OK and can be moved to > >> [core]." Usually it's not used for packages from [extra] or > >> [community]. > > > > Generally packages only need signoffs from developers on arch-dev mailing > > list. Sometimes (like with kernel26) public signoffs are wanted. > > > > -- > > Ape > > > > Thanks! :D I wasn't actually aware that public signoffs are wanted for kernel26. As far as I can remember some packages specifically request user signoffs due to lack of usage among devs (and those eventually get dropped from core in my observation). Any simple list as to which packages users should help signoff?
Re: [arch-general] 2.6.35-ARCH panic in VirtualBox 3.2.8-1
On Sat, Aug 21, 2010 at 6:24 PM, Martín Cigorraga wrote: > Hi Thomas, > > In fact I agree with you. If we start adding one 'feature' after another we > will end with a *buntu system in the near future. > List, please forgot my mail, thanks. > Whats wrong with adding features?
Re: [arch-general] [signoff] kernel26 2.6.35.2-1
On Sat, Aug 21, 2010 at 4:53 PM, Lauri Niskanen wrote: > On 08/21/2010 01:33 PM, Lukáš Jirkovský wrote: >>> >>> noob question: what does this signoff means? >>> >> >> Basically it means that it works OK for you and you are willing to >> "sign off the declaration the package is OK and can be moved to >> [core]." Usually it's not used for packages from [extra] or >> [community]. > > Generally packages only need signoffs from developers on arch-dev mailing > list. Sometimes (like with kernel26) public signoffs are wanted. > > -- > Ape > Thanks! :D
Re: [arch-general] 2.6.35-ARCH panic in VirtualBox 3.2.8-1
Hi Thomas, In fact I agree with you. If we start adding one 'feature' after another we will end with a *buntu system in the near future. List, please forgot my mail, thanks.
Re: [arch-general] [signoff] kernel26 2.6.35.2-1
On 08/21/2010 01:33 PM, Lukáš Jirkovský wrote: noob question: what does this signoff means? Basically it means that it works OK for you and you are willing to "sign off the declaration the package is OK and can be moved to [core]." Usually it's not used for packages from [extra] or [community]. Generally packages only need signoffs from developers on arch-dev mailing list. Sometimes (like with kernel26) public signoffs are wanted. -- Ape
Re: [arch-general] Referencing $srcdir in PKGBUILD?
On 19 August 2010 22:53, Heiko Baums wrote: > Am Tue, 17 Aug 2010 19:52:11 +0800 > schrieb Ray Rashif : > >> Just run this from the makepkg build dir: >> >> grep -R "$(pwd)/src" pkg/ > > I've done this with my package kernel26-fbcondecor, which is kernel26 > with just one additional patch and with slightly modified config files, > and it gave me a lot of matches in modules and several scripts, which > are not related to the fbcondecor patch and the modifications. > > So is there a bug in kernel26? Or can this be ignored? Can be safely ignored. Some (or most) builds record the build-time directories for informational/referential purposes. A user brought up this one in an AUR comment: $ strings /lib/modules/2.6.35-ARCH/kernel/arch/x86/kernel/cpu/cpufreq/mperf.ko /home/tobias/Arch/svn/svn-packages/kernel26/trunk/src/linux-2.6.35/arch/x86/include/asm/processor.h If it's not a binary, you can edit it to remove that information (if you happen to see it during runtime; otherwise leave it alone). Other cases where this is actually significantly annoying is when a warning about the directory not being found is output to stderr unnecessarily. That is when we should really file an upstream report. -- GPG/PGP ID: B42DDCAD
Re: [arch-general] [signoff] kernel26 2.6.35.2-1
> > noob question: what does this signoff means? > Basically it means that it works OK for you and you are willing to "sign off the declaration the package is OK and can be moved to [core]." Usually it's not used for packages from [extra] or [community].
Re: [arch-general] [signoff] kernel26 2.6.35.2-1
On Sun, Aug 15, 2010 at 3:16 AM, Tobias Powalowski wrote: > Latest kernel is in testing, > please signoff for both arches. > > greetings > tpowa > -- > Tobias > Powalowski > Archlinux Developer & Package Maintainer > (tpowa) > http://www.archlinux.org > tp...@archlinux.org > > noob question: what does this signoff means?
