Re: [arch-general] Another rant on arch way abuse and false promises
On Wed, 2009-12-02 at 08:38 +0100, Arvid Picciani wrote: > Ray Kohler wrote: > > > What I personally am in support of, in the general case, is > > "suckless.org-style" minimalism, rather than following upstream's > > direction. > > So if upstream changes the default to enable the hal and > > dbus bits, I will then be in favor of Arch disabling them, and we'll > > be in disagreement then. (That said, if that actually does happen, I > > won't asking the Arch devs to implement my wishes, since they'd > > clearly be in violation of the Arch way.) > > Indeed. As brought up by others, forcing minimalism is as much violation > as forcing bloat. > However, arch has been built around the idea that users are capable of > customizing packages to non-upstream settings. > I urge you to do exactly that. Fair enough > > I have posted and will continue to post various bugs to the tracker to > restore upstream defaults in favor for minimalism. If these reverts get > rejected in favor for bloat, the clear bias is a disregard of the very > core ideas of arch, and I will eventually fork arch entirely, given > enough support. Implying a bias if things do not go the way you want is just a bit of a stretch, don't you think? What's the percentage which would tip you off? 50%? 40%? In the end, the devs make a decision and (if they're nice) explain it, and that should be that. All this 'fork this fork that' threatening is really quite sad. I know its common in open source and linux in particular, but I certainly don't see threatening a fork and dilution of resources as in an way beneficial to Arch as a distro and to us individually as users. > > Either way, i'd welcome if you contribute, in order to get the user > experience you (and others including me) desire. That is, either > contribute packages to aur, to fix insane upstream defaults, or > contribute to an eventual fork to restore upstream defaults. > Will you? :) I see dbus/hal and the rest of this bloat as part of a good user experience. This is a difference in opinion, not a heresy. Having said all that, contributing the appropriate packages to the AUR is a very good initiative. Expand the choice of the user, I know some, maybe many, agree with you on minimalism w.r.t dbus/hal/the like. Forking is ridiculous and non-practical, and it would be better for everyone involved in Arch if its not used as a proverbial hammer to get one's way.
Re: [arch-general] Another rant on arch way abuse and false promises
Ray Kohler wrote: What I personally am in support of, in the general case, is "suckless.org-style" minimalism, rather than following upstream's direction. So if upstream changes the default to enable the hal and dbus bits, I will then be in favor of Arch disabling them, and we'll be in disagreement then. (That said, if that actually does happen, I won't asking the Arch devs to implement my wishes, since they'd clearly be in violation of the Arch way.) Indeed. As brought up by others, forcing minimalism is as much violation as forcing bloat. However, arch has been built around the idea that users are capable of customizing packages to non-upstream settings. I urge you to do exactly that. I have posted and will continue to post various bugs to the tracker to restore upstream defaults in favor for minimalism. If these reverts get rejected in favor for bloat, the clear bias is a disregard of the very core ideas of arch, and I will eventually fork arch entirely, given enough support. Either way, i'd welcome if you contribute, in order to get the user experience you (and others including me) desire. That is, either contribute packages to aur, to fix insane upstream defaults, or contribute to an eventual fork to restore upstream defaults. Will you? :) -- Arvid Asgaard Technologies
Re: [arch-general] [arch-dev-public] Qt 4.6.0
At Mittwoch, 2. Dezember 2009 05:03 Gerardo Exequiel Pozzi wrote: > Installed here (i686 at this moment). Font looks a bit bigger than with > previus qt. Do you have a vertical LCD display perhaps? I ask because of this elder discussion about problems in qt 4.5.0 with fonts and certain monitors: http://bbs.archlinux.org/viewtopic.php?id=67031 I hope this will not be the same story.-) See you, Attila
[arch-general] Problem updating system
Hello All, I am having trouble doing a system upgrade. --- r...@presario pacman.d]# pacman -Sy :: Synchronizing package databases... core is up to date extra is up to date community is up to date [r...@presario pacman.d]# pacman -Su :: Starting full system upgrade... local database is up to date --- Following is my /etc/pacman.conf --- [options] HoldPkg=pacman glibc SyncFirst=pacman [core] #Include=/etc/pacman.d/mirrorlist Server=ftp://mirror.aarnet.edu.au/pub/archlinux/$repo/os/x86_64 [extra] #Include=/etc/pacman.d/mirrorlist Server=ftp://mirror.aarnet.edu.au/pub/archlinux/$repo/os/x86_64 [community] #Include=/etc/pacman.d/mirrorlist Server=ftp://mirror.aarnet.edu.au/pub/archlinux/$repo/os/x86_64 --- The mirror is updated on nov 29, according to https://users.archlinux.de/~gerbra/mirrorcheck.html but I have not updated the system since nove 16-18(somtime that week). I followed into http://bbs.archlinux.org/viewtopic.php?pid=660210, and forced a package refresh but of no use. Any ideas? -- Shridhar
Re: [arch-general] [arch-dev-public] Qt 4.6.0
Pierre Schmitz wrote:
> Hi there,
>
> I am still not sure if we can move Qt 4.6 to [testing] or even [extra]. In
> theory it should be comptabile with all previous 4.x releases but my
> experience tells me that there might be broken things.
>
> So it would be nice if you have a look at my packages and give some feedback.
> https://users.archlinux.de/~pierre/packages/{i686,x86_64}/
>
> Pierre
>
Installed here (i686 at this moment). Font looks a bit bigger than with
previus qt.
http://archlinux.djgera.com.ar/screenshoots/qt45.png
http://archlinux.djgera.com.ar/screenshoots/qt46.png
--
Gerardo Exequiel Pozzi ( djgera )
http://www.djgera.com.ar
KeyID: 0x1B8C330D
Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Re: [arch-general] udev replacing hal? WAS xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
It seems that devicekit will replace some functions of hal, while udev replaces some other parts. But I don't know much further details either. Maybe a roadmap would make all these stuff clear~ Regards 2009/12/2 Ng Oon-Ee : > On Wed, 2009-12-02 at 03:09 +0100, vlad wrote: >> Why is hal dead? >> More information on this and on "libudev"? >> >> Vlad > > I'd like to know more about this as well. The articles I've found online > seem more marketing than details orientated (udev will cook your lunch > while paying your income tax stuff). > > -- LI Ye M.S. Student School of Information Science and Engineering Southeast University, P.R. China l...@seu.edu.cn
Re: [arch-general] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
On Tue, 2009-12-01 at 19:57 -0600, Aaron Griffin wrote: > On Tue, Dec 1, 2009 at 7:26 PM, Xavier wrote: > > I have yet to see someone serious and informed saying input hotplug > > sucks. All xorg developers I have seen (on the web : ML, blogs, irc, > > ...) seem to agree this new infrastructure is much better. > > Just to be clear, I am one of the "whiners". I never once claimed that > the hal integration is useless, and such is the reason I never > attempted to get rid of it from the Arch package. However, the hal > integration is 100% useless *for me*. There's an important distinction > there Seems to be the most reasonable approach.
[arch-general] udev replacing hal? WAS xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
On Wed, 2009-12-02 at 03:09 +0100, vlad wrote: > Why is hal dead? > More information on this and on "libudev"? > > Vlad I'd like to know more about this as well. The articles I've found online seem more marketing than details orientated (udev will cook your lunch while paying your income tax stuff).
Re: [arch-general] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
Why is hal dead? More information on this and on "libudev"? Vlad --
Re: [arch-general] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
On Tue, Dec 1, 2009 at 7:26 PM, Xavier wrote: > I have yet to see someone serious and informed saying input hotplug > sucks. All xorg developers I have seen (on the web : ML, blogs, irc, > ...) seem to agree this new infrastructure is much better. Just to be clear, I am one of the "whiners". I never once claimed that the hal integration is useless, and such is the reason I never attempted to get rid of it from the Arch package. However, the hal integration is 100% useless *for me*. There's an important distinction there
Re: [arch-general] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
On Tue, Dec 1, 2009 at 8:02 PM, Aaron Griffin wrote: > > Oh shit, seriously? Looks like I'll have to rebuild this as well. > > Serious question: does ANYONE have a keyboard that didn't > automatically work before this debacle? External keyboard always Just > Worked without needing to do anything. The same with mice if I used > /dev/input/mice. Sure, I didn't have a crazy Xtreme Gaming Mouse 9000 > or anything, but it never once failed for me under ordinary usage... > I just noticed there is a decent section on the wiki about this subject : http://wiki.archlinux.org/index.php/Xorg_input_hotplugging#Rationale Digging a bit more, I also found a similar page on debian wiki which might be even more interesting : http://wiki.debian.org/XStrikeForce/InputHotplugGuide The fun part is that the end of the article actually gives a reference to arch wiki page. Debian also have a bunch of "we do not need hal" whiners, which lead to a bug report. And for example this answer from a developer is also informative : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515214#91 I have yet to see someone serious and informed saying input hotplug sucks. All xorg developers I have seen (on the web : ML, blogs, irc, ...) seem to agree this new infrastructure is much better. Anyway hal is dead : http://wiki.x.org/wiki/Events/XDC2009/Notes?highlight=%28hal%29|%28udev%29#head-754e4968dd043dcf2166dff61afd7d0d06c5 But since that functionality is definitely needed, it will have to be replaced.. somehow.
Re: [arch-general] [arch-dev-public] [signoff] patch-2.6
On Wed, Dec 2, 2009 at 1:40 AM, Xavier wrote: > On Tue, Dec 1, 2009 at 3:44 PM, Alexander Duscheleit > wrote: > > > > Does this [1] affect arch? I guess it does for users building from aur > > or abs, but I'm not really familiar with most build-environments. > > > > [1] > > > http://blog.flameeyes.eu/2009/12/01/gentoo-service-announcement-keep-clear-of-gnu-patch-2-6 > > > > I don't see what differences it makes, whether you use aur or abs or not. > It has nothing to do with the build environment. makepkg will use > whatever patch command you specified in the PKGBUILD. > > That said, the above problem seems to be related to using -F3. I had > never seen that option anywhere before, I had no idea what it was. > Actually I am still a bit confused now even after reading the man page > :) > > Some quick scanning over abs tree did not reveal anything : > find /var/abs/ -name PKGBUILD | xargs grep "fuzzy" > find /var/abs/ -name PKGBUILD | xargs grep " -F" > find /var/abs/ -name PKGBUILD | xargs grep "patch.* -[^ ]*F" > > So I would guess we do not care, but I might be missing something. > Or maybe the problem does not even only exist with -F3. The > description of the problem in the above link is awfully poor. > The gentoo bugtracker describe issues using patch with fuzz factor. Refer to the link below. http://bugs.gentoo.org/show_bug.cgi?id=293570
Re: [arch-general] leafnode-svn and zoneminder
On Tue, Dec 1, 2009 at 18:56, Geoffrey Lane wrote: > Anybody know of a repo or a template for making a arch package out of a > svn/git repo? http://wiki.archlinux.org/index.php/VCS_PKGBUILD_guidelines "newpkg" in pkgtools does a little bit of the work for you.
Re: [arch-general] Another rant on arch way abuse and false promises
On Tue, Dec 1, 2009 at 6:46 PM, Arvid Picciani wrote: > Ray Kohler wrote: >> >> 2009/12/1 Ng Oon-Ee : >>> >>> When I started on here the mantra was "Arch is what you make it". >>> Packagers strive to make packages which are as vanilla as possible >>> (without breaking) and provide the utility expected of such packages. Of >>> course, if you want a system without hal/dbus, there's ABS and AUR. I >>> don't see why your dislike of particular implementations implies that >>> every user of Arch should forgo those implementations. >> >> I've been thinking about this particular part of the "Arch way". I >> think what causes the conflict in some of these cases is that >> "trusting upstream" - one of our major principles - only works when >> upstream is sane. Wacky things (like what freedesktop.org has been >> doing to Xorg for a while now) make me begin to think this assumption >> is violated in some important cases. When upstream ceases to really >> care about Arch-like systems and only support more Ubuntu-like >> systems, we have a problem with our "don't patch" philosophy. > > This implies that you're not ok with what happened to X. So you support my > position. What you did not realize, however, is that these things are not > upstream defaults. They have been specifically enabled downstream by the > arch maintainers. Actually, I did notice that. I didn't intend my comments to apply directly to this particular case. I am, however, in support of the particular changes you want for this case, though not strongly enough to get excited about it. > It is likely that the upstream will, as a reaction to my suggestion to reset > to upstream defaults, add these options as default. I then suggest to still > keep the upstream defaults, and maintain a fixed version of the package on > aur. > > The "sanity" here is very biased, hence there is no non-biased correct > solution, other then that suggested by the founder Judd. What I personally am in support of, in the general case, is "suckless.org-style" minimalism, rather than following upstream's direction. So if upstream changes the default to enable the hal and dbus bits, I will then be in favor of Arch disabling them, and we'll be in disagreement then. (That said, if that actually does happen, I won't asking the Arch devs to implement my wishes, since they'd clearly be in violation of the Arch way.)
[arch-general] leafnode-svn and zoneminder
I'm having two seperate issues here, one is simply a question or request for an AUR, but the other is dependancy hell and I can't resolv without removing some components. For several reasons I'd like to try leafnode 2 (beta), they have a git repo which should be easy enough - But I'd like to make a pkg out of THAT so it can be removed in future. Anybody know of a repo or a template for making a arch package out of a svn/git repo? zoneminder is kind of a security application, it allows you to monitor webcam over the net or record pictures/video. If I try to install the package it says it requires mmpeg-svn and a few others. mmpeg-svn also requires x264-git, which will remove x264, mmpeg (reg), and vlc. Vlc has no package that seems to depend on mmpeg-svn so if I remove it I get rid of my favorite video player. I'd appreciate the help getting fustrated on the second Geo -- "'Bill Gates can't guarantee Windows, so how in the HELL can you guarantee our safety!' --John Crichton (Farscape)"
Re: [arch-general] Another rant on arch way abuse and false promises
Ray Kohler wrote: 2009/12/1 Ng Oon-Ee : When I started on here the mantra was "Arch is what you make it". Packagers strive to make packages which are as vanilla as possible (without breaking) and provide the utility expected of such packages. Of course, if you want a system without hal/dbus, there's ABS and AUR. I don't see why your dislike of particular implementations implies that every user of Arch should forgo those implementations. I've been thinking about this particular part of the "Arch way". I think what causes the conflict in some of these cases is that "trusting upstream" - one of our major principles - only works when upstream is sane. Wacky things (like what freedesktop.org has been doing to Xorg for a while now) make me begin to think this assumption is violated in some important cases. When upstream ceases to really care about Arch-like systems and only support more Ubuntu-like systems, we have a problem with our "don't patch" philosophy. This implies that you're not ok with what happened to X. So you support my position. What you did not realize, however, is that these things are not upstream defaults. They have been specifically enabled downstream by the arch maintainers. It is likely that the upstream will, as a reaction to my suggestion to reset to upstream defaults, add these options as default. I then suggest to still keep the upstream defaults, and maintain a fixed version of the package on aur. The "sanity" here is very biased, hence there is no non-biased correct solution, other then that suggested by the founder Judd. -- Arvid Asgaard Technologies
Re: [arch-general] Another rant on arch way abuse and false promises
2009/12/1 Ng Oon-Ee : > When I started on here the mantra was "Arch is what you make it". > Packagers strive to make packages which are as vanilla as possible > (without breaking) and provide the utility expected of such packages. Of > course, if you want a system without hal/dbus, there's ABS and AUR. I > don't see why your dislike of particular implementations implies that > every user of Arch should forgo those implementations. I've been thinking about this particular part of the "Arch way". I think what causes the conflict in some of these cases is that "trusting upstream" - one of our major principles - only works when upstream is sane. Wacky things (like what freedesktop.org has been doing to Xorg for a while now) make me begin to think this assumption is violated in some important cases. When upstream ceases to really care about Arch-like systems and only support more Ubuntu-like systems, we have a problem with our "don't patch" philosophy.
Re: [arch-general] Another rant on arch way abuse and false promises
On Tue, Dec 1, 2009 at 5:30 PM, Arvid Picciani wrote: > Aaron Griffin wrote: >> >> On Tue, Dec 1, 2009 at 5:03 PM, Arvid Picciani wrote: >>> >>> I take that as an invite to post packages to the tracker that adhere to >>> the >>> arch way. If this turns out to be another false promise, i will add that >>> to >>> the next iteration. >> >> Assuming you meant "packages to the tracker that DON'T adhere to the >> arch way", then that is fine. Assuming of course it isn't just a bug >> report saying "package foobar doesn't adhere to the arch way". I'd >> hope there's be some "why" and "how to fix" parts > > my sentence was stating exactly that, condensed and in inverse order. > i was saying, i will post my fixed packages, which i manage downstream > anyway. > > Let me know if this bugformat works for you: > > http://bugs.archlinux.org/task/17341 Looks ok to me. Thanks.
Re: [arch-general] Help - Sound Disappeared -- Really! All modules -> Gone?? (kernel bug?)
> Flavio, > > It was installed on 11/6 along with "emovix, libmms, cdrdao, > libmodplug, > speex, libshout, mpg123, libasyncns, pulseaudio, wavpack and quanta". I'm not > sure which recommended it as an option. The weird part is that sound continued > working as normal until just this past week. From 11/6 through ~ 11/20, sound > worked fine. Then another install or update evidently brought the issue to > life. All is good now. Thank you for your help. > Did you reboot during this time frame? Perhaps the alsa modules were loaded, and when you finally rebooted (on the 20th?), they weren't there to be re-loaded.
Re: [arch-general] Another rant on arch way abuse and false promises
On 02.12.2009 00:22, Ng Oon-Ee wrote: > On Wed, 2009-12-02 at 00:03 +0100, Arvid Picciani wrote: > >> Aaron Griffin wrote: >> >>> If you have legitimate, actionable fixes for anything you take issue >>> with, please post them to the bug tracker. Until then, this is just >>> hot air. >>> >> I take that as an invite to post packages to the tracker that adhere to >> the arch way. If this turns out to be another false promise, i will add >> that to the next iteration. >> >> > I'm not sure exactly what 'Arch Way' you're referring to here. I fail to > see any reference in http://wiki.archlinux.org/index.php/The_Arch_Way to > "The Arch Way means choosing against anything developed in the last > decade or so which doesn't conform to my idea of minimalism". > > As I understand it properly, Arch provides a minimalist Base you can > then build on (or change as necessary). Build it up in a minimalist > manner, fine. Some of us prefer Gnome/KDE, and all the associated > 'bloat', and posting up (for example) an xorg-server which would cripple > those packages (and probably necessitate xorg-server-hal to compensate) > is needlessly complicating things. > > When I started on here the mantra was "Arch is what you make it". > Packagers strive to make packages which are as vanilla as possible > (without breaking) and provide the utility expected of such packages. Of > course, if you want a system without hal/dbus, there's ABS and AUR. I > don't see why your dislike of particular implementations implies that > every user of Arch should forgo those implementations. > > > Indeed. If anything, the Arch way says "Keep shit simple". Minimalism comes out of this by nature. However, enforced minimalism does more harm than good. Simplicity is the most important guideline of the Arch way. If including HAL or other integral features of other source packages means stuff will get less complicated at a small to no cost, then this should be the preferred way as opposed to enforcing minimalism no matter what. Just my 0.0135€. -- Sven-Hendrik
Re: [arch-general] Another rant on arch way abuse and false promises
Aaron Griffin wrote: On Tue, Dec 1, 2009 at 5:03 PM, Arvid Picciani wrote: I take that as an invite to post packages to the tracker that adhere to the arch way. If this turns out to be another false promise, i will add that to the next iteration. Assuming you meant "packages to the tracker that DON'T adhere to the arch way", then that is fine. Assuming of course it isn't just a bug report saying "package foobar doesn't adhere to the arch way". I'd hope there's be some "why" and "how to fix" parts my sentence was stating exactly that, condensed and in inverse order. i was saying, i will post my fixed packages, which i manage downstream anyway. Let me know if this bugformat works for you: http://bugs.archlinux.org/task/17341 -- Arvid Asgaard Technologies
Re: [arch-general] Another rant on arch way abuse and false promises
On Tue, Dec 1, 2009 at 5:27 PM, Arvid Picciani wrote: > Giovanni Scafora wrote: >> >> 2009/12/1, Ng Oon-Ee : >>> >>> When I started on here the mantra was "Arch is what you make it". >>> Packagers strive to make packages which are as vanilla as possible >>> (without breaking) and provide the utility expected of such packages. Of >>> course, if you want a system without hal/dbus, there's ABS and AUR. I >>> don't see why your dislike of particular implementations implies that >>> every user of Arch should forgo those implementations. >> >> I totally agree here. >> >> > > glad we all agree on that :) > i'm about to post packages which work for both of us. They have been > stripped of dbus and happen to be the upstream default. Oh, I misread the intent previously. I was expecting bug reports of the form "foo is broken, remove X and Y", but you're actually planning on posting new-and-improved PKGBUILDs? It might be nice to include diffs in that case, so it's easier to see what was done on a change-by-change basis.
Re: [arch-general] Another rant on arch way abuse and false promises
Giovanni Scafora wrote: 2009/12/1, Ng Oon-Ee : When I started on here the mantra was "Arch is what you make it". Packagers strive to make packages which are as vanilla as possible (without breaking) and provide the utility expected of such packages. Of course, if you want a system without hal/dbus, there's ABS and AUR. I don't see why your dislike of particular implementations implies that every user of Arch should forgo those implementations. I totally agree here. glad we all agree on that :) i'm about to post packages which work for both of us. They have been stripped of dbus and happen to be the upstream default. -- Arvid Asgaard Technologies
Re: [arch-general] Another rant on arch way abuse and false promises
2009/12/1, Ng Oon-Ee : > When I started on here the mantra was "Arch is what you make it". > Packagers strive to make packages which are as vanilla as possible > (without breaking) and provide the utility expected of such packages. Of > course, if you want a system without hal/dbus, there's ABS and AUR. I > don't see why your dislike of particular implementations implies that > every user of Arch should forgo those implementations. I totally agree here. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
Re: [arch-general] Another rant on arch way abuse and false promises
On Wed, 2009-12-02 at 00:03 +0100, Arvid Picciani wrote: > Aaron Griffin wrote: > > If you have legitimate, actionable fixes for anything you take issue > > with, please post them to the bug tracker. Until then, this is just > > hot air. > > I take that as an invite to post packages to the tracker that adhere to > the arch way. If this turns out to be another false promise, i will add > that to the next iteration. > I'm not sure exactly what 'Arch Way' you're referring to here. I fail to see any reference in http://wiki.archlinux.org/index.php/The_Arch_Way to "The Arch Way means choosing against anything developed in the last decade or so which doesn't conform to my idea of minimalism". As I understand it properly, Arch provides a minimalist Base you can then build on (or change as necessary). Build it up in a minimalist manner, fine. Some of us prefer Gnome/KDE, and all the associated 'bloat', and posting up (for example) an xorg-server which would cripple those packages (and probably necessitate xorg-server-hal to compensate) is needlessly complicating things. When I started on here the mantra was "Arch is what you make it". Packagers strive to make packages which are as vanilla as possible (without breaking) and provide the utility expected of such packages. Of course, if you want a system without hal/dbus, there's ABS and AUR. I don't see why your dislike of particular implementations implies that every user of Arch should forgo those implementations.
Re: [arch-general] Another rant on arch way abuse and false promises
On Tue, Dec 1, 2009 at 5:03 PM, Arvid Picciani wrote: > I take that as an invite to post packages to the tracker that adhere to the > arch way. If this turns out to be another false promise, i will add that to > the next iteration. Assuming you meant "packages to the tracker that DON'T adhere to the arch way", then that is fine. Assuming of course it isn't just a bug report saying "package foobar doesn't adhere to the arch way". I'd hope there's be some "why" and "how to fix" parts
Re: [arch-general] Another rant on arch way abuse and false promises
Giovanni Scafora wrote: 2009/12/1, Arvid Picciani : I take that as an invite to post packages to the tracker that adhere to the arch way. If this turns out to be another false promise, i will add that to the next iteration. is this a threat? :-) if patches are lethal, YES :D -- Arvid Asgaard Technologies
Re: [arch-general] Another rant on arch way abuse and false promises
2009/12/1, Arvid Picciani : > I take that as an invite to post packages to the tracker that adhere to the > arch way. If this turns out to be another false promise, i will add that to > the next iteration. is this a threat? :-) -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
Re: [arch-general] Another rant on arch way abuse and false promises
Aaron Griffin wrote: On Tue, Dec 1, 2009 at 4:51 PM, Arvid Picciani wrote: ...stuff... Not sure what just happened here. I thought we were having a legitimate discussion about xorg-server and this ballooned into something crazy. You wanted detailed proof, here you are. i doubt you have grasped the essence of it in the 5 minutes you bothered to invest. Apparently, you've been holding onto this for some time. for 3 years now. iterating each 6 months. If you have legitimate, actionable fixes for anything you take issue with, please post them to the bug tracker. Until then, this is just hot air. I take that as an invite to post packages to the tracker that adhere to the arch way. If this turns out to be another false promise, i will add that to the next iteration. -- Arvid Asgaard Technologies
Re: [arch-general] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
Jan de Groot wrote: On Tue, 2009-12-01 at 19:45 +0100, Arvid Picciani wrote: nope. The hal crap has been added to X a while ago as "optional" (meaning X would just freeze without it, but at least pretend to start) , but the forced dependency is new (as in, it doesnt start when compiled with hal, but no hal present). The difference is that previously you could get get away with a hack in xorg.conf without having to rebuild xorg without --enable-config-hal Looks like nobody ever reads documentation. Read the freaking wiki link posted when upgrading/installing xorg-server and you'll know you can disable hal interaction from xorg.conf with one single option. Is it that hard? hah there he is seeking the frontal battle. counter point: Looks like no one ever reads mails completely before assuming the other side is a complete moron. Where did i say i have a problem related to that upgrade? In fact, let me requote that to prove you didnt read it. > On Tue, 2009-12-01 at 19:45 +0100, Arvid Picciani wrote: >> The difference is that previously you could get get away with a hack >> in xorg.conf Jan de Groot wrote: > and you'll know you can > disable hal interaction from xorg.conf with one single option. Thanks for being so smart and education me though! -- Arvid Asgaard Technologies
Re: [arch-general] Another rant on arch way abuse and false promises (was: xf86-input-evdev conflicts with xorg-server. Remove xorg-server?)
On Tue, Dec 1, 2009 at 4:51 PM, Arvid Picciani wrote: > ...stuff... Not sure what just happened here. I thought we were having a legitimate discussion about xorg-server and this ballooned into something crazy. Apparently, you've been holding onto this for some time. If you have legitimate, actionable fixes for anything you take issue with, please post them to the bug tracker. Until then, this is just hot air.
Re: [arch-general] packages installed to /usr/x86_64-unknown-linux-gnu and x86_64-unknown-uclibc -- broken??
Aaron Griffin wrote: On Tue, Dec 1, 2009 at 2:27 PM, David C. Rankin wrote: On Tuesday 01 December 2009 14:10:20 and regarding: Those packages are not essential to your system. binutils-uclibc and cross-arm-elf-binutils are primarily developer tools. Yes, I loaded them because there are a couple of apps that I want to try and cross compile. I guess they are fine where they are, but shouldn't the install packages have put them somewhere else? I don't think so. It's common practice to put cross compilation tools in non-standard places, so you don't accidentally end up compiling something on your x86 system for an arm processor. A while back, there was some discussion about cross-compliers and trying to be more FHS compliant. The suggestion was to put them in /usr/lib/cross-. See: http://wiki.archlinux.org/index.php/Cross_Compiling_Tools_Package_Guidelines_Proposal I posted a set of PKGBUILDs for the mingw32 cross compiler. Allan
Re: [arch-general] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
On Tue, 2009-12-01 at 19:45 +0100, Arvid Picciani wrote: > nope. The hal crap has been added to X a while ago as "optional" > (meaning X would just freeze without it, but at least pretend to > start) > , but the forced dependency is new (as in, it doesnt start when > compiled > with hal, but no hal present). > The difference is that previously you could get get away with a hack > in > xorg.conf without having to rebuild xorg without --enable-config-hal Looks like nobody ever reads documentation. Read the freaking wiki link posted when upgrading/installing xorg-server and you'll know you can disable hal interaction from xorg.conf with one single option. Is it that hard?
[arch-general] Another rant on arch way abuse and false promises (was: xf86-input-evdev conflicts with xorg-server. Remove xorg-server?)
Aaron Griffin wrote: > Which package has patches to add these features? Looking at > xorg-server, I only see one extraneous patch that simple replaces the > default grey stipple pattern with black. The rest seem (at a glance) > to fix real bugs You have a point here, in that i have used a fuzzy description of the problem, in the assumption you and possible other readers remember the numerous rants on this ML. At very least I'd except You to remember your own blog. I'm going to post some hard facts to your convenience. a...@andariel: ~ egrep 'enable|disable|patch -N' /var/abs/extra/xorg-server/PKGBUILD | wc -l 24 > Jan has always done a good job in the past of keeping Xorg as > impartial as possible without breaking things, and I'm assuming he did > the same here. i was about to state that i didnt target him at all. Then i ran this: a...@andariel: ~ (for i in $(grep "Jan de Groot" /var/abs/ -r | cut -d ':' -f 1); do egrep "enable|disable|patch -N" $i; done) | wc -l 543 Now you're propably saying numbers of downstream decisions doesn't say anything. Very true, which is why i prefer arguing about "intent" a...@andariel: ~ grep Maintainer /var/abs/core/dbus-core/PKGBUILD # Maintainer: Jan de Groot and "bias" a...@andariel: ~ (for i in $(grep "Jan de Groot" /var/abs/ -r | cut -d ':' -f 1 | cut -d '/' -f 5); do if (pacman -Si $i | grep gnome >/dev/null); then echo $i; fi; done) | wc -l 149 The point is, just because *I* prefer something > one way doesn't mean it's a good decision at the distro level. So there is the name of some guy, who approves the unix philosophy, on this distro, but that guy decides it's a good idea that people who prefer ubuntu make the vital decisions. I claim, You are leading a project whichs developers mainly disprove what You stand for, or claim to stand for. Which is why, ... You'd be perfectly suited to throw the first stone, Aaron. I'm confused by this. It seems rather standoffish and I'm not sure what you're trying to say here. .. i have offered my support numerous times. I can see how the daily nuisance of fixing upstream bugs can blur the own goals. Alternatively, You lie about your goals. The very reason, for me to again zombify this minor issue into an open attack, is that you have responded to it, agreeing to the user base you promised to support, but not taken action. we have maintainers we can generally trust about these decisions. Your opinions on trust vary, depending on topic. Last time we had this, You promised to kick out tpowa. You didn't. I don't track if the abuse is ongoing, since I maintain all these packages myself now. -- Arvid Asgaard Technologies
Re: [arch-general] Help - Sound Disappeared -- Really! All modules -> Gone?? (kernel bug?)
On Tuesday 01 December 2009 15:23:22 and regarding: > You could try to check /var/log/pacman.log to see why "oss" was installed. > (If it was still installed pacman -Qi would give you this sort of info I > guess) > Flavio, It was installed on 11/6 along with "emovix, libmms, cdrdao, libmodplug, speex, libshout, mpg123, libasyncns, pulseaudio, wavpack and quanta". I'm not sure which recommended it as an option. The weird part is that sound continued working as normal until just this past week. From 11/6 through ~ 11/20, sound worked fine. Then another install or update evidently brought the issue to life. All is good now. Thank you for your help. -- 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] SBCL orphaned for i686?
On 12/01/2009 11:17 PM, Leslie P. Polzer wrote: > >> We have noticed that SBCL i686 in extra is now marked as "orphaned". >> >> Adopted. "orphan" was by accident. > If this is true, what are the implications of it? Will SBCL for i686 >> move to AUR/Community? And can we do anything to remedy this situation >> in order to get SBCL 1.0.32/.33 in soon? >> >> We need to fix this bug: http://bugs.archlinux.org/task/16761 Any contribution appreciated. Jürgen
Re: [arch-general] Help - Sound Disappeared -- Really! All modules -> Gone?? (kernel bug?)
You could try to check /var/log/pacman.log to see why "oss" was installed. (If it was still installed pacman -Qi would give you this sort of info I guess) On Tue, Dec 1, 2009 at 5:18 PM, David C. Rankin < drankina...@suddenlinkmail.com> wrote: > On Tuesday 01 December 2009 12:48:02 and regarding: > > > > > Remove (1): oss-4.2_2002-1.1 > > > > Total Removed Size: 5.82 MB > > > > Do you want to remove these packages? [Y/n] > > OSS not loaded. > > (1/1) removing oss > > [#] 100% > > > > - > > Open Sound System was now removed, and the ALSA kernel > > modules were restored. > > > > Please note that OSS stores some of its configuration files > > at /usr/lib/oss. If you don't plan to use OSS anymore, you > > can remove this directory. > > - > > > > now let us see if this box will make noise again... > > > > > Bingo -- The box makes noise once again! And... as a bonus, learning has > occurred as to how oss handles alsa kernel modules. I don't know what > wanted > oss, but oss does a good job wiping out alsa. But, the oss removal script > that > restores alsa works as it is supposed to. Alsa restored, module loaded and > sound is back to normal (although with a cool mixer in kde 4.3.4) > > Thanks again DR. Next time, just send me back the following link: > > http://www.justfuckinggoogleit.com/ > > :p > > -- > 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 > -- Flávio Coutinho da Costa
Re: [arch-general] SBCL orphaned for i686?
On 12/01/2009 11:17 PM, Leslie P. Polzer wrote: Hi, I'm part of the Paktahn development team; Paktahn is a yaourt-like frontend to Arch package management written in Common Lisp. At the moment SBCL is our main deployment Lisp, and we depend on the 1.0.32 release of SBCL because this release includes a critical patch. We have noticed that SBCL i686 in extra is now marked as "orphaned". If this is true, what are the implications of it? Will SBCL for i686 move to AUR/Community? And can we do anything to remedy this situation in order to get SBCL 1.0.32/.33 in soon? Thank you! Leslie a package being orphaned doesn't really imply that is not maintained. I see that x86_64 has a maintainer and i think that he forgot to adopt it or this package was a part on a massive orphaning that happened couples of days ago(some bug in the interface). If you want to help, send an updated version of PKGBUILD to the maintainer email, maybe he didn't have time. Eventually will be updated
[arch-general] SBCL orphaned for i686?
Hi, I'm part of the Paktahn development team; Paktahn is a yaourt-like frontend to Arch package management written in Common Lisp. At the moment SBCL is our main deployment Lisp, and we depend on the 1.0.32 release of SBCL because this release includes a critical patch. We have noticed that SBCL i686 in extra is now marked as "orphaned". If this is true, what are the implications of it? Will SBCL for i686 move to AUR/Community? And can we do anything to remedy this situation in order to get SBCL 1.0.32/.33 in soon? Thank you! Leslie -- http://www.linkedin.com/in/polzer
Re: [arch-general] packages installed to /usr/x86_64-unknown-linux-gnu and x86_64-unknown-uclibc -- broken??
On Tue, Dec 1, 2009 at 2:27 PM, David C. Rankin wrote: > On Tuesday 01 December 2009 14:10:20 and regarding: > >> Those packages are not essential to your system. binutils-uclibc and >> cross-arm-elf-binutils are primarily developer tools. >> > > Yes, > > I loaded them because there are a couple of apps that I want to try > and cross > compile. I guess they are fine where they are, but shouldn't the install > packages have put them somewhere else? I don't think so. It's common practice to put cross compilation tools in non-standard places, so you don't accidentally end up compiling something on your x86 system for an arm processor.
Re: [arch-general] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
On Tue, Dec 1, 2009 at 2:14 PM, Arvid Picciani wrote: > Aaron, > >> Oh shit, seriously? Looks like I'll have to rebuild this as well. > > It's your distro. I fail to see the whole reason why you have always been in > support of KISS and the arch way, but never seem to take action to enforce > it. Maybe it's something social, which i tend to be ignorant towards. Well, I'm not an Xorg authority, nor am I the packager of it. I imagine removing this will have a detrimental effect to all those people using the large monolithic desktop environments, but cannot make a factual claim either way. The point is, just because *I* prefer something one way doesn't mean it's a good decision at the distro level. Jan has always done a good job in the past of keeping Xorg as impartial as possible without breaking things, and I'm assuming he did the same here. > I find it hard to argue about the mentioned user base, since its supposed > favorite distro archlinux, does in fact add downstream patches to ADD the > very features i am opposing. I assume, for now, removing those again via abs > is acceptable for most power users, including me and you, until someone > finally forks arch. You'd be perfectly suited to throw the first stone, > Aaron. I'm confused by this. It seems rather standoffish and I'm not sure what you're trying to say here. As I alluded to early, I do not watch each and every single package change that is made. No one has the time for that. That is why we have maintainers we can generally trust about these decisions. Which package has patches to add these features? Looking at xorg-server, I only see one extraneous patch that simple replaces the default grey stipple pattern with black. The rest seem (at a glance) to fix real bugs
Re: [arch-general] packages installed to /usr/x86_64-unknown-linux-gnu and x86_64-unknown-uclibc -- broken??
On Tuesday 01 December 2009 14:10:20 and regarding: > Those packages are not essential to your system. binutils-uclibc and > cross-arm-elf-binutils are primarily developer tools. > Yes, I loaded them because there are a couple of apps that I want to try and cross compile. I guess they are fine where they are, but shouldn't the install packages have put them somewhere else? -- 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] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
Aaron, Oh shit, seriously? Looks like I'll have to rebuild this as well. It's your distro. I fail to see the whole reason why you have always been in support of KISS and the arch way, but never seem to take action to enforce it. Maybe it's something social, which i tend to be ignorant towards. Serious question: does ANYONE have a keyboard that didn't automatically work before this debacle? External keyboard always Just Worked without needing to do anything. The same with mice if I used /dev/input/mice. Sure, I didn't have a crazy Xtreme Gaming Mouse 9000 or anything, but it never once failed for me under ordinary usage... Xorg had and still has decent hardware detection. I do have crazy gaming hardware and it isn't correctly detected on ubuntu while it works just fine here on my customized arch without hal ever since X.org. Without any xorg.conf i might add. I'm not going to go as far as claiming the hal/dbus thing is social engineering, but it sure as hell smells like it. However, some chatter on their mailing list suggests it actually has a positive effect for some users, while the negative effect remains undiscovered by the (majority of gnu/linux)~(ubuntu) users. I guess the new way is better, since it seperates the ubuntu aproach from power user systems in a clean way. If my source is reliable (some dude on irc), X.org will continue to support both versions and seperate them clearly, maybe even with modules. That'd be _nice_! Oh a module would be wonderful There is hope. Mostly due to the fact that X is used on embedded systems. Beware though, that argument is fading, as embedded devices get more powerful and users expectations shift from usable to shiny. Even your toaster is going to run kde in the long run. It won't do toasts anymore, but at least it has the latest fashionable widgets. The solution to this political problem is indeed political. Some people can't be educated at all, but the average arch user proves to be capable of learning the basic unix, kiss, and arch philosophies. Back to the point. As long as the X.org upstream is reminded, that the arch/unix/kiss user base is still worth supporting, i'm positive they will continue to support it. In fact we're probably the reason they fixed xft? No one else is using it. I find it hard to argue about the mentioned user base, since its supposed favorite distro archlinux, does in fact add downstream patches to ADD the very features i am opposing. I assume, for now, removing those again via abs is acceptable for most power users, including me and you, until someone finally forks arch. You'd be perfectly suited to throw the first stone, Aaron. -- Arvid Asgaard Technologies
Re: [arch-general] Installing Arch Linux w/ RAID
Yes, no matter where you mount a raid partition to, you will necessarily need the raid modules loaded. Accessing hardware requires drivers. Jackson On Tue, 2009-12-01 at 11:25 -0500, Carlos Williams wrote: > On Fri, Oct 30, 2009 at 9:19 AM, toomanymirrors > wrote: > > I agree, with /dev/md0 being your home directory there should not be any > > kernel panic even if it's not being properly mounted at boot. It sounds > > like there is another issue going on. Try the suggestion above for grub > > and I didn't notice you mentioning you'd added md_mod and raid1 to the > > MODULES list in your rc.conf file either. You will need to do that. > > If I have my system configured as follows: > > /dev/sda1 = /boot (bootable) > /dev/sda2 = / > /dev/sda3 = RAID > > /dev/sdb1 = swap > /dev/sdb2 = /var > /dev/sdb3 = RAID > > mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3 > > Once that is done, since I am not using RAID on anything but my /home > partition, do I need to add 'md_mod' & 'raid1' in the rc.conf section? > Is this a requirement because the Wiki mentions nothing about it...
Re: [arch-general] packages installed to /usr/x86_64-unknown-linux-gnu and x86_64-unknown-uclibc -- broken??
On Tue, Dec 1, 2009 at 1:54 PM, David C. Rankin wrote: > On Tuesday 01 December 2009 07:33:17 and regarding: >> Does "pacman -Qo " return anything? >> > > Flavio, > > Strangely, yes: > > 13:49 alchemy:/usr/x86_64-unknown-linux-uclibc/bin> for i in $(ls); do pacman > -Qo $i; done > ar is owned by binutils-uclibc 2.19.1-2 > as is owned by binutils-uclibc 2.19.1-2 > ld is owned by binutils-uclibc 2.19.1-2 > nm is owned by binutils-uclibc 2.19.1-2 > objcopy is owned by binutils-uclibc 2.19.1-2 > objdump is owned by binutils-uclibc 2.19.1-2 > ranlib is owned by binutils-uclibc 2.19.1-2 > strip is owned by binutils-uclibc 2.19.1-2 > > 13:51 alchemy:/usr/x86_64-unknown-linux-gnu/arm-elf/lib> for i in $(ls); do [[ > ! -h $i ]] && pacman -Qo $i; done > libbfd-2.20.so is owned by cross-arm-elf-binutils 2.20-1 > libbfd.a is owned by cross-arm-elf-binutils 2.20-1 > libopcodes-2.20.so is owned by cross-arm-elf-binutils 2.20-1 > libopcodes.a is owned by cross-arm-elf-binutils 2.20-1 > > It looks like all the binutils files are unknown for some reason? > > Do you want me to post anything else? I guess I'll uninstall and try to > reinstall these packages and see if it happens again. Strange. Those packages are not essential to your system. binutils-uclibc and cross-arm-elf-binutils are primarily developer tools.
Re: [arch-general] packages installed to /usr/x86_64-unknown-linux-gnu and x86_64-unknown-uclibc -- broken??
On Tuesday 01 December 2009 07:33:17 and regarding: > Does "pacman -Qo " return anything? > Flavio, Strangely, yes: 13:49 alchemy:/usr/x86_64-unknown-linux-uclibc/bin> for i in $(ls); do pacman -Qo $i; done ar is owned by binutils-uclibc 2.19.1-2 as is owned by binutils-uclibc 2.19.1-2 ld is owned by binutils-uclibc 2.19.1-2 nm is owned by binutils-uclibc 2.19.1-2 objcopy is owned by binutils-uclibc 2.19.1-2 objdump is owned by binutils-uclibc 2.19.1-2 ranlib is owned by binutils-uclibc 2.19.1-2 strip is owned by binutils-uclibc 2.19.1-2 13:51 alchemy:/usr/x86_64-unknown-linux-gnu/arm-elf/lib> for i in $(ls); do [[ ! -h $i ]] && pacman -Qo $i; done libbfd-2.20.so is owned by cross-arm-elf-binutils 2.20-1 libbfd.a is owned by cross-arm-elf-binutils 2.20-1 libopcodes-2.20.so is owned by cross-arm-elf-binutils 2.20-1 libopcodes.a is owned by cross-arm-elf-binutils 2.20-1 It looks like all the binutils files are unknown for some reason? Do you want me to post anything else? I guess I'll uninstall and try to reinstall these packages and see if it happens again. Strange. -- 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] Help - Sound Disappeared -- Really! All modules -> Gone?? (kernel bug?)
On Tuesday 01 December 2009 12:48:02 and regarding: > > Remove (1): oss-4.2_2002-1.1 > > Total Removed Size: 5.82 MB > > Do you want to remove these packages? [Y/n] > OSS not loaded. > (1/1) removing oss > [#] 100% > > - > Open Sound System was now removed, and the ALSA kernel > modules were restored. > > Please note that OSS stores some of its configuration files > at /usr/lib/oss. If you don't plan to use OSS anymore, you > can remove this directory. > - > > now let us see if this box will make noise again... > Bingo -- The box makes noise once again! And... as a bonus, learning has occurred as to how oss handles alsa kernel modules. I don't know what wanted oss, but oss does a good job wiping out alsa. But, the oss removal script that restores alsa works as it is supposed to. Alsa restored, module loaded and sound is back to normal (although with a cool mixer in kde 4.3.4) Thanks again DR. Next time, just send me back the following link: http://www.justfuckinggoogleit.com/ :p -- 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] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
On Tue, Dec 1, 2009 at 12:45 PM, Arvid Picciani wrote: > Aaron Griffin wrote: >> >> On Tue, Dec 1, 2009 at 10:51 AM, Daenyth Blank >> wrote: >>> >>> 2009/12/1 Arvid Picciani : Arvid Picciani wrote: > warning: cannot resolve "hal>=0.5.13", a dependency of "xorg-server" never mind my bitching. rebuilding xorg-server without hal was a matter of abs,edit,makepkg <3 arch >>> Are you using -Syu or are you trying to just randomly -S things? >>> Normally a full upgrade should not have conflicts to this degree. >> > > -Syu > >> Unless his system is fairly old and he hasn't updated in a while. >> xorg-server depending on hal happened a fairly long time ago, didn't >> it? > > nope. The hal crap has been added to X a while ago as "optional" (meaning X > would just freeze without it, but at least pretend to start) , but the > forced dependency is new (as in, it doesnt start when compiled with hal, but > no hal present). > The difference is that previously you could get get away with a hack in > xorg.conf without having to rebuild xorg without --enable-config-hal Oh shit, seriously? Looks like I'll have to rebuild this as well. Serious question: does ANYONE have a keyboard that didn't automatically work before this debacle? External keyboard always Just Worked without needing to do anything. The same with mice if I used /dev/input/mice. Sure, I didn't have a crazy Xtreme Gaming Mouse 9000 or anything, but it never once failed for me under ordinary usage... > I guess the new way is better, since it seperates the ubuntu aproach from > power user systems in a clean way. If my source is reliable (some dude on > irc), X.org will continue to support both versions and seperate them > clearly, maybe even with modules. That'd be _nice_! Oh a module would be wonderful
Re: [arch-general] Help - Sound Disappeared -- Really! All modules -> Gone?? (kernel bug?)
On Tuesday 01 December 2009 12:39:23 and regarding: > > Google is your friend: > > http://www.lmgtfy.com/?q=sound-preoss.tar.bz2 > > Click the first link and it'll shed some light. > > DR > Oh brother Thank you DR: checking dependencies... Remove (1): oss-4.2_2002-1.1 Total Removed Size: 5.82 MB Do you want to remove these packages? [Y/n] OSS not loaded. (1/1) removing oss [#] 100% - Open Sound System was now removed, and the ALSA kernel modules were restored. Please note that OSS stores some of its configuration files at /usr/lib/oss. If you don't plan to use OSS anymore, you can remove this directory. - now let us see if this box will make noise again... -- 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] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
Aaron Griffin wrote: On Tue, Dec 1, 2009 at 10:51 AM, Daenyth Blank wrote: 2009/12/1 Arvid Picciani : Arvid Picciani wrote: warning: cannot resolve "hal>=0.5.13", a dependency of "xorg-server" never mind my bitching. rebuilding xorg-server without hal was a matter of abs,edit,makepkg <3 arch Are you using -Syu or are you trying to just randomly -S things? Normally a full upgrade should not have conflicts to this degree. -Syu Unless his system is fairly old and he hasn't updated in a while. xorg-server depending on hal happened a fairly long time ago, didn't it? nope. The hal crap has been added to X a while ago as "optional" (meaning X would just freeze without it, but at least pretend to start) , but the forced dependency is new (as in, it doesnt start when compiled with hal, but no hal present). The difference is that previously you could get get away with a hack in xorg.conf without having to rebuild xorg without --enable-config-hal I guess the new way is better, since it seperates the ubuntu aproach from power user systems in a clean way. If my source is reliable (some dude on irc), X.org will continue to support both versions and seperate them clearly, maybe even with modules. That'd be _nice_! -- Arvid Asgaard Technologies
Re: [arch-general] Help - Sound Disappeared -- Really! All modules -> Gone?? (kernel bug?)
On 12/01/2009 01:31 PM, David C. Rankin wrote: If you want to check which files are inside kernel26 , you have to do : pacman -Ql kernel26 pacman -Ql kernel26 | grep snd-hda-intel would be much more interesting and meaningful than pacman -Q kernel26 | grep snd-hda-intel which was just a small typo or overlook of Flavio. Agreed, 12:28 alchemy:~/dt/kdm/themes> pacman -Ql kernel26 | grep snd-hda-intel kernel26 /lib/modules/2.6.31-ARCH/kernel/sound/pci/hda/snd-hda-intel.ko It's there, it's just sitting in sound-preoss.tar.bz2 right now. How to proceed?? Google is your friend: http://www.lmgtfy.com/?q=sound-preoss.tar.bz2 Click the first link and it'll shed some light. DR
Re: [arch-general] Help - Sound Disappeared -- Really! All modules -> Gone?? (kernel bug?)
On Tuesday 01 December 2009 09:11:00 and regarding: > > Maybe you also need to understand what you are doing and what the > commands mean instead of brainless copy/paste. > Xavier, I appologize if I sounded flippant in my approach to copying files back to replace the sound modules, but rest assured that I understand fully what I'm doing when I do it and if not, I read until I do. (now granted, I have misunderstood a man page or two in my days ;-) This issue is just so off-the- wall that it has caught me somewhat off guard. It seems so narrowly tailored to the sound system that it is like the last kernel install just omitted the sound modules (and I think it did -- see below) > if /lib/modules/2.6.31-ARCH/kernel/sound/pci/hda/snd-hda-intel.ko does > not exist, you need to go all the way up to /lib/modules to see what > exist, if anything at all. > You can also just 'find /lib/modules' to display all files in there. > I picked through the modules previously and missed what I think is the whole problem with the sound -- and it does look like the last kernel install simply failed to install the modules. I think this split screen view from konqueror provides the evidence of what is going on (sound-preoss.tar.bz2 was never extracted and installed). In the konqueror screenshot, my laptop is shown in the left vertical pane and another Arch x86_64 box is shown in the right pane. Now I do not understand why sound-preoss.tar.bz2 wasn't installed on my laptop, but it contains all the sound files: http://www.3111skyline.com/download/Archlinux/bugs/sound-preoss-bz2.jpg [12:11 alchemy:/lib/modules/2.6.31-ARCH] # tar -tjf sound-preoss.tar.bz2 | grep intel kernel/sound/pci/snd-intel8x0m.ko kernel/sound/pci/hda/snd-hda-intel.ko kernel/sound/pci/hda/snd-hda-codec-intelhdmi.ko kernel/sound/pci/snd-intel8x0.ko Where can I look to try and find the reason sound-preoss-bz2.jpg was left uninstalled? Can you think of a reason this could have happened during an update? The only way I update packages for the system is throught "pacman -Syu" when doing an update and that shouldn't have said don't install the sound. Not knowing more about the way Arch handles the sound-preoss.tar.bz2 file or what post processing is needed, I'm unclear how to proceed. Is it safer to attempt a reinstall of the kernel, or is it safe to just extract the sound modules and then use modprobe? > and pacman -Q kernel26 tells you whether kernel26 is installed or not. > It's probably a good idea to check that too, maybe you removed it ? > > You also need to check running kernel (uname -r) matches the one installed. > 12:08 alchemy:~/dt/kdm/themes> uname -r 2.6.31-ARCH 12:28 alchemy:~/dt/kdm/themes> pmq | grep kernel kernel-headers 2.6.31.5-1 kernel26 2.6.31.6-1 kernel26-firmware 2.6.31-1 Hmm, kernel headers is a minor version behind, but that's the latest with the current updates. That shouldn't have done it, should it? > If you want to check which files are inside kernel26 , you have to do : > pacman -Ql kernel26 > > pacman -Ql kernel26 | grep snd-hda-intel > would be much more interesting and meaningful than > pacman -Q kernel26 | grep snd-hda-intel > which was just a small typo or overlook of Flavio. > Agreed, 12:28 alchemy:~/dt/kdm/themes> pacman -Ql kernel26 | grep snd-hda-intel kernel26 /lib/modules/2.6.31-ARCH/kernel/sound/pci/hda/snd-hda-intel.ko It's there, it's just sitting in sound-preoss.tar.bz2 right now. How to proceed?? -- 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] Help - Sound Disappeared -- Really! All modules -> Gone?? (kernel bug?)
On Tue, Dec 1, 2009 at 5:19 PM, Flavio Costa wrote: > On Tue, Dec 1, 2009 at 1:11 PM, Xavier wrote: > >> On Tue, Dec 1, 2009 at 10:32 AM, David C. Rankin >> wrote: >> > >> > 03:26 alchemy:~/dt/kdm/themes> ls -la /lib/modules/2.6.31- >> > ARCH/kernel/sound/pci/hda/snd-hda-intel.ko >> > ls: cannot access /lib/modules/2.6.31-ARCH/kernel/sound/pci/hda/snd-hda- >> > intel.ko: No such file or directory >> > >> > 03:26 alchemy:~/dt/kdm/themes> pacman -Q kernel26 | grep snd-hda-intel >> > You have mail in /var/mail/david >> > >> >> Maybe you also need to understand what you are doing and what the >> commands mean instead of brainless copy/paste. >> >> if /lib/modules/2.6.31-ARCH/kernel/sound/pci/hda/snd-hda-intel.ko does >> not exist, you need to go all the way up to /lib/modules to see what >> exist, if anything at all. >> You can also just 'find /lib/modules' to display all files in there. >> >> and pacman -Q kernel26 tells you whether kernel26 is installed or not. >> It's probably a good idea to check that too, maybe you removed it ? >> >> You also need to check running kernel (uname -r) matches the one installed. >> > > I was under the impression he was not using a custom kernel (since he didn't > mentioned) that why I didn't bother to check. > > That is possible but in that case, reinstalling kernel26 will not really help :) He needs to fix his custom kernel instead. >> >> If you want to check which files are inside kernel26 , you have to do : >> pacman -Ql kernel26 >> >> pacman -Ql kernel26 | grep snd-hda-intel >> would be much more interesting and meaningful than >> pacman -Q kernel26 | grep snd-hda-intel >> which was just a small typo or overlook of Flavio. >> > > Indeed it was a typo. > > I image /lib/modules contains some stuff, otherwise his system would be > totally f***'ed up and prolly wouldn't boot (or just would have no devices > like network cards working at all, which doesn't appear to be the case). > Actually , it is possible to build a kernel with everything built-in and no modules, isn't it ? In that case, you can have a perfectly working system with nothing in /lib/modules :) But yeah, I doubt David did that. And if he did it (correctly), he would still have sound.
Re: [arch-general] [arch-dev-public] [signoff] patch-2.6
On Tue, Dec 1, 2009 at 3:44 PM, Alexander Duscheleit wrote: > > Does this [1] affect arch? I guess it does for users building from aur > or abs, but I'm not really familiar with most build-environments. > > [1] > http://blog.flameeyes.eu/2009/12/01/gentoo-service-announcement-keep-clear-of-gnu-patch-2-6 > I don't see what differences it makes, whether you use aur or abs or not. It has nothing to do with the build environment. makepkg will use whatever patch command you specified in the PKGBUILD. That said, the above problem seems to be related to using -F3. I had never seen that option anywhere before, I had no idea what it was. Actually I am still a bit confused now even after reading the man page :) Some quick scanning over abs tree did not reveal anything : find /var/abs/ -name PKGBUILD | xargs grep "fuzzy" find /var/abs/ -name PKGBUILD | xargs grep " -F" find /var/abs/ -name PKGBUILD | xargs grep "patch.* -[^ ]*F" So I would guess we do not care, but I might be missing something. Or maybe the problem does not even only exist with -F3. The description of the problem in the above link is awfully poor.
Re: [arch-general] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
On Tue, Dec 1, 2009 at 10:51 AM, Daenyth Blank wrote: > 2009/12/1 Arvid Picciani : >> Arvid Picciani wrote: >> >>> warning: cannot resolve "hal>=0.5.13", a dependency of "xorg-server" >> >> >> never mind my bitching. rebuilding xorg-server without hal was a matter of >> abs,edit,makepkg >> >> <3 arch >> > Are you using -Syu or are you trying to just randomly -S things? > Normally a full upgrade should not have conflicts to this degree. Unless his system is fairly old and he hasn't updated in a while. xorg-server depending on hal happened a fairly long time ago, didn't it?
Re: [arch-general] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
2009/12/1 Arvid Picciani : > Arvid Picciani wrote: > >> warning: cannot resolve "hal>=0.5.13", a dependency of "xorg-server" > > > never mind my bitching. rebuilding xorg-server without hal was a matter of > abs,edit,makepkg > > <3 arch > Are you using -Syu or are you trying to just randomly -S things? Normally a full upgrade should not have conflicts to this degree.
Re: [arch-general] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
Arvid Picciani wrote: warning: cannot resolve "hal>=0.5.13", a dependency of "xorg-server" never mind my bitching. rebuilding xorg-server without hal was a matter of abs,edit,makepkg <3 arch -- Arvid Asgaard Technologies
Re: [arch-general] Installing Arch Linux w/ RAID
On Fri, Oct 30, 2009 at 9:19 AM, toomanymirrors wrote: > I agree, with /dev/md0 being your home directory there should not be any > kernel panic even if it's not being properly mounted at boot. It sounds > like there is another issue going on. Try the suggestion above for grub > and I didn't notice you mentioning you'd added md_mod and raid1 to the > MODULES list in your rc.conf file either. You will need to do that. If I have my system configured as follows: /dev/sda1 = /boot (bootable) /dev/sda2 = / /dev/sda3 = RAID /dev/sdb1 = swap /dev/sdb2 = /var /dev/sdb3 = RAID mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda3 /dev/sdb3 Once that is done, since I am not using RAID on anything but my /home partition, do I need to add 'md_mod' & 'raid1' in the rc.conf section? Is this a requirement because the Wiki mentions nothing about it...
Re: [arch-general] Help - Sound Disappeared -- Really! All modules -> Gone?? (kernel bug?)
On Tue, Dec 1, 2009 at 1:11 PM, Xavier wrote: > On Tue, Dec 1, 2009 at 10:32 AM, David C. Rankin > wrote: > > > > 03:26 alchemy:~/dt/kdm/themes> ls -la /lib/modules/2.6.31- > > ARCH/kernel/sound/pci/hda/snd-hda-intel.ko > > ls: cannot access /lib/modules/2.6.31-ARCH/kernel/sound/pci/hda/snd-hda- > > intel.ko: No such file or directory > > > > 03:26 alchemy:~/dt/kdm/themes> pacman -Q kernel26 | grep snd-hda-intel > > You have mail in /var/mail/david > > > > Maybe you also need to understand what you are doing and what the > commands mean instead of brainless copy/paste. > > if /lib/modules/2.6.31-ARCH/kernel/sound/pci/hda/snd-hda-intel.ko does > not exist, you need to go all the way up to /lib/modules to see what > exist, if anything at all. > You can also just 'find /lib/modules' to display all files in there. > > and pacman -Q kernel26 tells you whether kernel26 is installed or not. > It's probably a good idea to check that too, maybe you removed it ? > > You also need to check running kernel (uname -r) matches the one installed. > I was under the impression he was not using a custom kernel (since he didn't mentioned) that why I didn't bother to check. > > If you want to check which files are inside kernel26 , you have to do : > pacman -Ql kernel26 > > pacman -Ql kernel26 | grep snd-hda-intel > would be much more interesting and meaningful than > pacman -Q kernel26 | grep snd-hda-intel > which was just a small typo or overlook of Flavio. > Indeed it was a typo. I image /lib/modules contains some stuff, otherwise his system would be totally f***'ed up and prolly wouldn't boot (or just would have no devices like network cards working at all, which doesn't appear to be the case). -- Flávio Coutinho da Costa
Re: [arch-general] usable browser?
Dieter Plaetinck wrote: can you give some examples of sites worth reading that don't work in webkit? actually it looks like webkit wins over opera right now. The only quirks i found were worse in opera. I'm amazed. going for uzbl. yey. -- Arvid Asgaard Technologies
Re: [arch-general] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
Ng Oon-Ee wrote: On Tue, 2009-12-01 at 12:43 +0100, Arvid Picciani wrote: obviously i do NOT want to remove xorg-server. i don't need evdev, but: :: xorg-server: requires xf86-input-evdev>=2.2.5 so no removing it either. the mirror i'm using has been updated today (December 1th), and i'm not using testing. mirrors package versions: xorg-server 1.7.2-2 xf86-input-evdev 2.3.1-1 thanks What about your own package versions (the ones currently installed)? xorg-server: 1.6.3.901-1 xf86-input-evdev : 2.2.5-something on irc the idea came up that the local versions conflict with the repo versions, hence pacman is confused about the dependencies. i removed evdev, and all the other drivers localy. Which turned out to be a very bad idea. Now i'm left with a half dead system. warning: cannot resolve "hal>=0.5.13", a dependency of "xorg-server" THAT is the actual problem. It now depends on HAL, which doesn't work. Anyone got a hack available for this? Patch? Maybe it's just a configure option. I'll have to build my own xorg anyway then i guess. *sigh* archlinux vs lfs 0:1 -- Arvid Asgaard Technologies
Re: [arch-general] [arch-dev-public] [signoff] patch-2.6
On Thu, 26 Nov 2009 00:42:33 -0500 Eric Bélanger wrote: > On Wed, Nov 25, 2009 at 11:12 PM, Allan McRae > wrote: > > Allan McRae wrote: > >> > >> Ionut Biru wrote: > >>> > >>> On 11/20/2009 07:24 AM, Allan McRae wrote: > > Upstream update. Signoff both. > > >>> > >>> signoff x86_64 > >>> > >> > >> Anyone for i686? > >> > > > > Anyone? > > > > > > > > > > signoff i686 Does this [1] affect arch? I guess it does for users building from aur or abs, but I'm not really familiar with most build-environments. [1] http://blog.flameeyes.eu/2009/12/01/gentoo-service-announcement-keep-clear-of-gnu-patch-2-6 --
Re: [arch-general] Help - Sound Disappeared -- Really! All modules -> Gone?? (kernel bug?)
On Tue, Dec 1, 2009 at 10:32 AM, David C. Rankin wrote: > > 03:26 alchemy:~/dt/kdm/themes> ls -la /lib/modules/2.6.31- > ARCH/kernel/sound/pci/hda/snd-hda-intel.ko > ls: cannot access /lib/modules/2.6.31-ARCH/kernel/sound/pci/hda/snd-hda- > intel.ko: No such file or directory > > 03:26 alchemy:~/dt/kdm/themes> pacman -Q kernel26 | grep snd-hda-intel > You have mail in /var/mail/david > Maybe you also need to understand what you are doing and what the commands mean instead of brainless copy/paste. if /lib/modules/2.6.31-ARCH/kernel/sound/pci/hda/snd-hda-intel.ko does not exist, you need to go all the way up to /lib/modules to see what exist, if anything at all. You can also just 'find /lib/modules' to display all files in there. and pacman -Q kernel26 tells you whether kernel26 is installed or not. It's probably a good idea to check that too, maybe you removed it ? You also need to check running kernel (uname -r) matches the one installed. If you want to check which files are inside kernel26 , you have to do : pacman -Ql kernel26 pacman -Ql kernel26 | grep snd-hda-intel would be much more interesting and meaningful than pacman -Q kernel26 | grep snd-hda-intel which was just a small typo or overlook of Flavio.
Re: [arch-general] packages installed to /usr/x86_64-unknown-linux-gnu and x86_64-unknown-uclibc -- broken??
Does "pacman -Qo " return anything? On Tue, Dec 1, 2009 at 6:28 AM, David C. Rankin < drankina...@suddenlinkmail.com> wrote: > Guys, > > Picking though /usr/ (because I've nothing better to do...) I ran across > two > directories that look like they do not belong where they are. The > directories > are: > > 02:19 alchemy:/usr> find x86_64-unknown-linux-gnu/ -type d > x86_64-unknown-linux-gnu/ > x86_64-unknown-linux-gnu/arm-elf > x86_64-unknown-linux-gnu/arm-elf/lib > x86_64-unknown-linux-gnu/arm-elf/include > x86_64-unknown-linux-gnu/i486-mingw32 > x86_64-unknown-linux-gnu/i486-mingw32/lib > x86_64-unknown-linux-gnu/i486-mingw32/include > > 02:20 alchemy:/usr> find x86_64-unknown-linux-uclibc/ -type d > x86_64-unknown-linux-uclibc/ > x86_64-unknown-linux-uclibc/lib > x86_64-unknown-linux-uclibc/lib/ldscripts > x86_64-unknown-linux-uclibc/bin > x86_64-unknown-linux-uclibc/include > x86_64-unknown-linux-uclibc/include/net > x86_64-unknown-linux-uclibc/include/sys > x86_64-unknown-linux-uclibc/include/neteconet > x86_64-unknown-linux-uclibc/include/bits > x86_64-unknown-linux-uclibc/include/arpa > x86_64-unknown-linux-uclibc/include/netinet > x86_64-unknown-linux-uclibc/include/netipx > x86_64-unknown-linux-uclibc/include/netpacket > x86_64-unknown-linux-uclibc/include/rpc > x86_64-unknown-linux-uclibc/include/scsi > x86_64-unknown-linux-uclibc/include/netax25 > x86_64-unknown-linux-uclibc/include/protocols > > I have an understanding of the files in x86_64-unknown-linux-gnu, but I > don't > know what the uclibc files are specifically (I mean I know libc, just not > the > uc part). There are a large number of files here: > > 02:20 alchemy:/usr> find x86_64-unknown-linux-uclibc/ -type f | wc -l > 367 > > Full file list at: > > http://www.3111skyline.com/download/Archlinux/bugs/usr-x86-64-unknown.txt > > The file dates on the files are November 5th. > > These directories look like they should be somewhere else, so I'm putting > it > to the brain-trust, bug or feature?? > > -- > 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 > -- Flávio Coutinho da Costa
Re: [arch-general] Help - Sound Disappeared -- Really! All modules -> Gone?? (kernel bug?)
You can simply reinstall the package by issuing "pacman -S kernel26" But I'd also try to investigate why where those files erased. On Tue, Dec 1, 2009 at 7:32 AM, David C. Rankin < drankina...@suddenlinkmail.com> wrote: > On Monday 30 November 2009 18:08:21 and regarding: > > I'd guess that you have a corrupt filesystem and due to an fsck (or > > something else) the modules are gone. > > > > Thank you for your help Flavio! > > fsck was fine, but see my other post about files in > /usr/x86_84-unknown-linux- > gnu and /usr/x86_84-unknown-linux-uclibc?? > > > Try doing a "ls -la > > /lib/modules/2.6.31-ARCH/kernel/sound/pci/hda/snd-hda-intel.ko". > > And this: "pacman -Q kernel26 | grep snd-hda-intel" > > > > 03:26 alchemy:~/dt/kdm/themes> ls -la /lib/modules/2.6.31- > ARCH/kernel/sound/pci/hda/snd-hda-intel.ko > ls: cannot access /lib/modules/2.6.31-ARCH/kernel/sound/pci/hda/snd-hda- > intel.ko: No such file or directory > > 03:26 alchemy:~/dt/kdm/themes> pacman -Q kernel26 | grep snd-hda-intel > You have mail in /var/mail/david > > > Yep, they're gone... WTF? How can I reinstall them? Hardly seems like a > problem to warrant a wipe-and-reinstall, but at least I have all the > current > packages if that becomes necessary. I bet it was gnome that did it :p. I > think > I have another x86_64 Arch install for my laptop, maybe I could pull the > missing files from there. But how to tell what I need to copy? > > > > -- > 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 > -- Flávio Coutinho da Costa
Re: [arch-general] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
On 12/01/2009 01:43 PM, Arvid Picciani wrote: obviously i do NOT want to remove xorg-server. i don't need evdev, but: :: xorg-server: requires xf86-input-evdev>=2.2.5 so no removing it either. the mirror i'm using has been updated today (December 1th), and i'm not using testing. mirrors package versions: xorg-server 1.7.2-2 xf86-input-evdev 2.3.1-1 thanks why you want to remove evdev? if you use autodetecting thing from xorg you need that. in other case just install xf86-input-keyboard and xf86-input-mouse.
Re: [arch-general] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
On Tue, 2009-12-01 at 12:43 +0100, Arvid Picciani wrote: > obviously i do NOT want to remove xorg-server. > > i don't need evdev, but: > :: xorg-server: requires xf86-input-evdev>=2.2.5 > so no removing it either. > > the mirror i'm using has been updated today (December 1th), and i'm not > using testing. > mirrors package versions: > xorg-server 1.7.2-2 > xf86-input-evdev 2.3.1-1 > > thanks > What about your own package versions (the ones currently installed)?
[arch-general] xf86-input-evdev conflicts with xorg-server. Remove xorg-server?
obviously i do NOT want to remove xorg-server. i don't need evdev, but: :: xorg-server: requires xf86-input-evdev>=2.2.5 so no removing it either. the mirror i'm using has been updated today (December 1th), and i'm not using testing. mirrors package versions: xorg-server 1.7.2-2 xf86-input-evdev 2.3.1-1 thanks -- Arvid Asgaard Technologies
Re: [arch-general] Single Person ISP?
On Thursday 19 November 2009 01:44:06 and regarding: > So recently Verizon has stopped letting me do free tethering and I've > been looking for a replacement. Apparently all of the free ISPs I can > find all require that you use their shitty Windows program to connect, > so I decided, "I have a phone line, a modem and an internet connection, > maybe I can make my own ISP". > > Basically, I want to take a computer with a dialup modem and an ethernet > connection to a cable modem and make it so whenever someone calls, the > computer picks up and acts like an ISP (requests username/password, then > forwards all requests to the cable modem). > > Obviously, it wouldn't be that great (added latency, phone line won't > work while it's active), but it's at least theoretically possible. I'm > just wondering if there's software designed to do it. > > -Brendan Long > Brendan, I have done this for years, but for the past six months the ppp package has been screwed up and will not pass the ppp session off to the dial in line. Currently, I have this as my /etc/ppp/options file with the modem on ttyS1 and the cable connection rounted through eth0: debug kdebug 7 crtscts lock modem nodetach lcp-echo-interval 30 lcp-echo-failure 4 lcp-max-configure 60 lcp-restart 2 idle 600 noipx file /etc/ppp/filters asyncmap 200a proxyarp login # Note there is a current dispute whether login will prevent the ppp # connection from being established on some systems. Try with and # without it and see what you get. ms-dns 192.168.6.17 ms-wins 192.168.6.17 netmask 255.255.255.0 192.168.6.17:192.168.6.11 The last good working config I had was on a suse 10.3 box. Since then nothing has worked on suse 11.0 - 11.1 or Arch. I'm still digging into the issue time permitting. -- 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] Help - Sound Disappeared -- Really! All modules -> Gone?? (kernel bug?)
On Monday 30 November 2009 18:08:21 and regarding: > I'd guess that you have a corrupt filesystem and due to an fsck (or > something else) the modules are gone. > Thank you for your help Flavio! fsck was fine, but see my other post about files in /usr/x86_84-unknown-linux- gnu and /usr/x86_84-unknown-linux-uclibc?? > Try doing a "ls -la > /lib/modules/2.6.31-ARCH/kernel/sound/pci/hda/snd-hda-intel.ko". > And this: "pacman -Q kernel26 | grep snd-hda-intel" > 03:26 alchemy:~/dt/kdm/themes> ls -la /lib/modules/2.6.31- ARCH/kernel/sound/pci/hda/snd-hda-intel.ko ls: cannot access /lib/modules/2.6.31-ARCH/kernel/sound/pci/hda/snd-hda- intel.ko: No such file or directory 03:26 alchemy:~/dt/kdm/themes> pacman -Q kernel26 | grep snd-hda-intel You have mail in /var/mail/david Yep, they're gone... WTF? How can I reinstall them? Hardly seems like a problem to warrant a wipe-and-reinstall, but at least I have all the current packages if that becomes necessary. I bet it was gnome that did it :p. I think I have another x86_64 Arch install for my laptop, maybe I could pull the missing files from there. But how to tell what I need to copy? -- 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] Pretty Cool Dark Blue Arch Linux kdm/xdm greeter theme for your box
On Tuesday 01 December 2009 03:22:44 and regarding: > Guys, > > I cannibalized a cool dark blue gradient kdm/xdm greeter theme for Arch > from kubuntu (it's GPL). Works great. Just unzip the file (it has full > path information to /usr/share/apps/kdm/themes). Then I just used kde > systemsettings -> System -> login manager -> themes to select it and then > log out and you should have it looking at you. Enjoy: > > (~401k due to the svg dialogs..) > > http://www.3111skyline.com/download/Archlinux/kdm/ArchSpotLight.tar.gz > P.S. the site may be a bit slow for the next hour, I'm pulling down kde 4.3.4 :p -- 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] Pretty Cool Dark Blue Arch Linux kdm/xdm greeter theme for your box
Guys, I cannibalized a cool dark blue gradient kdm/xdm greeter theme for Arch from kubuntu (it's GPL). Works great. Just unzip the file (it has full path information to /usr/share/apps/kdm/themes). Then I just used kde systemsettings -> System -> login manager -> themes to select it and then log out and you should have it looking at you. Enjoy: (~401k due to the svg dialogs..) http://www.3111skyline.com/download/Archlinux/kdm/ArchSpotLight.tar.gz -- 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] packages installed to /usr/x86_64-unknown-linux-gnu and x86_64-unknown-uclibc -- broken??
Guys, Picking though /usr/ (because I've nothing better to do...) I ran across two directories that look like they do not belong where they are. The directories are: 02:19 alchemy:/usr> find x86_64-unknown-linux-gnu/ -type d x86_64-unknown-linux-gnu/ x86_64-unknown-linux-gnu/arm-elf x86_64-unknown-linux-gnu/arm-elf/lib x86_64-unknown-linux-gnu/arm-elf/include x86_64-unknown-linux-gnu/i486-mingw32 x86_64-unknown-linux-gnu/i486-mingw32/lib x86_64-unknown-linux-gnu/i486-mingw32/include 02:20 alchemy:/usr> find x86_64-unknown-linux-uclibc/ -type d x86_64-unknown-linux-uclibc/ x86_64-unknown-linux-uclibc/lib x86_64-unknown-linux-uclibc/lib/ldscripts x86_64-unknown-linux-uclibc/bin x86_64-unknown-linux-uclibc/include x86_64-unknown-linux-uclibc/include/net x86_64-unknown-linux-uclibc/include/sys x86_64-unknown-linux-uclibc/include/neteconet x86_64-unknown-linux-uclibc/include/bits x86_64-unknown-linux-uclibc/include/arpa x86_64-unknown-linux-uclibc/include/netinet x86_64-unknown-linux-uclibc/include/netipx x86_64-unknown-linux-uclibc/include/netpacket x86_64-unknown-linux-uclibc/include/rpc x86_64-unknown-linux-uclibc/include/scsi x86_64-unknown-linux-uclibc/include/netax25 x86_64-unknown-linux-uclibc/include/protocols I have an understanding of the files in x86_64-unknown-linux-gnu, but I don't know what the uclibc files are specifically (I mean I know libc, just not the uc part). There are a large number of files here: 02:20 alchemy:/usr> find x86_64-unknown-linux-uclibc/ -type f | wc -l 367 Full file list at: http://www.3111skyline.com/download/Archlinux/bugs/usr-x86-64-unknown.txt The file dates on the files are November 5th. These directories look like they should be somewhere else, so I'm putting it to the brain-trust, bug or feature?? -- 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
