Re: [arch-general] pacman message: too much happens:: ...
On Sun, Feb 7, 2010 at 11:00 PM, Aaron Griffin aaronmgrif...@gmail.comwrote:
On Sun, Feb 7, 2010 at 2:32 PM, clemens fischer
ino-n...@spotteswoode.dnsalias.org wrote:
Daenyth Blank wrote:
On Fri, Feb 5, 2010 at 18:07, clemens fischer
ino-n...@spotteswoode.dnsalias.org wrote:
Sorry. It's an fcrontab entry:
{ pacman --noprogressbar -Sy pacman --noprogressbar -Qu || :; }
21
Try it with --debug for more info?
No chance. 'Cause it went away by itself. How about checking the
servers? Does any component of them contain that string too much
happens? I can imagine many people accessed the package servers due to
the libpng* updates.
Could it be a message from cron itself?
I did a quick grep on the pacman sources and it found no occurences of that
string.
[arch-general] KMS and external monitor resolution
Hi all, I'm sorry if it has already been discussed here, but I couldn't find anything with the keywords I was using. I even had a bad time choosing this message subject. I bought a new, bigger monitor to use with my notebook. I've already configured X, but sometimes I like to write on the tty (there are less distractions there) and I'm having a little problem with it. The native resolution of the notebook screen is 1280x800 and the native resolution of the external monitor is 1920x1080, so when I'm on the tty, the external monitor uses only a box on the top left side with a size of 1280x800. What I would like to do is turn off the notebook monitor and use only the external monitor with its native resolution, without, of course, messing with my X setup, as it's already set. I'm using a Intel GMA965 with KMS. TIA Bye, Andre
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, Dec 03, 2009 at 04:42:25PM -0200, Denis A. Altoé Falqueto wrote: (...) 4. There are other IPC mechanisms Yes, there are. But I think that each one has some drawbacks too. CORBA, for example, is too heavy for simple use (Gnome developers can tell a good story about that). XMLRPC needs a HTTP server or something like that and the overhead of the communication protocol is not very efficient for local use. Maybe there's another IPC mechanism that is good, but maybe it doesn't have everything that DBus have (for example, activation of daemons on demand). (...) I believe these aren't the 'other IPC mechanisms' they were talking about. What about FIFOs and sockets?
Re: [arch-general] [OT] What is wrong with DBus anyway?
On Thu, Dec 03, 2009 at 05:05:18PM -0200, Denis A. Altoé Falqueto wrote: On Thu, Dec 3, 2009 at 4:53 PM, André Ramaciotti da Silva andre.ramacio...@gmail.com wrote: I believe these aren't the 'other IPC mechanisms' they were talking about. What about FIFOs and sockets? In fact, DBus is implemented over Unix sockets. FIFOs and sockets don't define the format that will be used over them, they are just channels of communication. DBus is a wire protocol, as they say in the home page. It defines the format the methods and parameters should be converted to make the communication viable, as well as an event system so that applications can register interest in some activity. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? --- Denis A. Altoe Falqueto --- I didn't know that. Thanks for clarification. :)
Re: [arch-general] conclusion: Another rant on arch way abuse and false promises
On Thu, Dec 03, 2009 at 01:54:10AM +0530, Raghavendra Prabhu wrote: One thing I don't understand here is - why people crib that package B should not have feature X. If you don't want that, ABS is for that. There are plenty of packages which have additional dependencies like that mplayer(like smbclient) or vlc(hal :) or lua). (snipped) The problem is that using ABS is impracticable if you have a big number of custom PKGBUILDs. OTOH, having packages with minimal dependencies isn't so great. During the (short) time I've used Gentoo, I noticed the consume of RAM is a little lower, but there isn't a big difference in performance. The problems arise when you compile packages with way to minimal dependencies, and later realize it was a mistake, and now you have to recompile lots of packages.
Re: [arch-general] Frustrating Dependencies
On Mon, Nov 23, 2009 at 01:36:15PM -0200, André Ramaciotti da Silva wrote: On Mon, Nov 23, 2009 at 04:06:34PM +0100, Heiko Baums wrote: Am Mon, 23 Nov 2009 12:16:46 -0200 schrieb André Ramaciotti da Silva andre.ramacio...@gmail.com: I know, I know, they always come back. :P My Arch installation is still in my HD, just in case. About disk usage, don't forget that arch keeps a cache of downloaded packages. So I don't think Gentoo is in disadvantage here. My installation uses 1GB less than Arch (both have basically the same packages). It may not sound like a lot, thinking of the size most HD have nowadays, but it's a 20% improvement. But you can delete the cached packages in Arch (pacman -Sc or pacman -Scc). ;-) If this is useful is a different question. And you can delete the sources in Gentoo. Both distros are pretty OK here. I don't think compiling takes that much. If you're in a hurry, then yes, it'll seem like forever. I installed in a weekend, basically the same time I took to install Arch (because I install some packages, then I remember of others, then others...). But it wasn't 48h compiling, it was way, way less. On my old i686 1,3 GHz CPU with 1 GB RAM it took me a week to compile and install the complete Gentoo system inkl. Xorg, KDE, OpenOffice etc. while I only need 1 or 2 days for Arch. And KDE alone took me 1 day and OpenOffice 12 hours. I did this several years until I had enough of this waste of time and found Arch Linux. Even if compiling only takes 48 hours. Installing it on Arch takes only a few seconds or maximum a few minutes. And compiling uses more ressources and thus more energy. Indeed, if I used KDE, I wouldn't use Gentoo. OTOH, Gentoo offers binary packages of OpenOffice, Firefox and some other apps. However, from what emerge tells me, firefox sources are one third the size of firefox-bin. As Brazil isn't famous for its ultra-fast broadband, I can imagine certain cases that compiling is faster. I agree with most of what you wrote, and I don't have the slightest idea of how maintaining a Gentoo system in the long run is. I'm just trying it and I like it so far, but keep in mind I've been using it for only one week. This wasn't the first time I thought of trying Gentoo, so I installed it to see how it is or I would be always thinking about it. When I get tired of compiling, I'll go back to Arch with a better idea of its strengths. :) Just in case I left some of you wondering, yes, I'm back. I predicted it myself and I guess most of you also did. USE flags are nice, when they're playing along with you. When they're not, and you mixed packages from the stable and the unstable branch, then you have a problem. Though I resist to learn this, KISS is always better. It's good to be back :).
Re: [arch-general] Frustrating Dependencies
On Mon, Nov 23, 2009 at 02:49:19PM +0100, Heiko Baums wrote: Am Mon, 23 Nov 2009 11:17:13 -0200 schrieb André Ramaciotti da Silva andre.ramacio...@gmail.com: I don't want to flame, but that's why I recently moved to Gentoo. Arch is one of the best distros I've used, but when you use a (primarily) binary distro, the number of choices you have is reduced. I don't blame the devs, though. They must make packages that appeal to a large number of users and Arch ends up with packages with a big number of dependencies. If you think about it, using a little bit more of disk space isn't a big problem compared to the problem some people would have if the default packages weren't compiled with these extra dependencies, because they would have to compile their own packages, defeating the reason to use a binary-based distro. I know, Arch has ABS, which is a great improvement compared to others binary-based distros, but it's still not perfect. Pacman doens't look for custom PKGBUILDs and automatically create the new packages based on them, and I guess it won't. Pacman wasn't meant to do that. You can make scripts based on pacman and ABS that will do this (I've made one shortly before changing distros), but then I realised I don't know all the ./configure options a package has, and I find documentation on this a little scarce. Using the 'USE' flags with emerge is much simpler in this aspect. I don't think that you will stay too long with Gentoo. ;-) It is right that you can reduce the dependencies a bit and that you are more flexible by setting USE flags. As far as I recall the difference between Gentoo and Arch Linux regarding the disk space is not significant if there's a difference at all, but you will need a lot more temporary disk space for compiling and it takes several days to compile the whole system and every update takes much longer than on Arch Linux. So I think wasting a bit disk space for dependencies which aren't needed is better than wasting too much time for compiling the whole system. That's why I switched from Gentoo to Arch Linux a while ago. On Arch Linux you still have the same control over the installed packages as you have on Gentoo. Don't overvalue the USE flags. There's optdepends to reduce the dependencies a bit as long as a dependency can be made optionally. Otherwise more comfort for the common users is better I think. And pacman and ABS are good as they are. There's still the NoUpgrade option in pacman.conf if you build a package from ABS. Heiko I know, I know, they always come back. :P My Arch installation is still in my HD, just in case. About disk usage, don't forget that arch keeps a cache of downloaded packages. So I don't think Gentoo is in disadvantage here. My installation uses 1GB less than Arch (both have basically the same packages). It may not sound like a lot, thinking of the size most HD have nowadays, but it's a 20% improvement. I don't think compiling takes that much. If you're in a hurry, then yes, it'll seem like forever. I installed in a weekend, basically the same time I took to install Arch (because I install some packages, then I remember of others, then others...). But it wasn't 48h compiling, it was way, way less. I agree that with Arch you still have control over your packages, but USE flags make it easier. Somebody already went into the ./configure of all packages and put it in an easier way to do it. If programs could talk, emerge would be like: - I want my mplayer with samba and lirc support. - OK, I'll configure it this way, but then you also need to install this and this packages. While pacman would be something like: - I want my mplayer without samba support. - Wakka wakka wakka. Make a custom PKGBUILD then, wakka wakka. And finally, yes, there are optdeps, but pacman don't handle them as nicely it handles obligatory dependencies. If I install an optdep as an explicit installed package, when I uninstall the other package, the optdep will stay in my system. If I install it as a dependency, pacman will list it as an unnecessary dependency when I run pacman -Qdt. Andre
Re: [arch-general] Frustrating Dependencies
On Mon, Nov 23, 2009 at 04:06:34PM +0100, Heiko Baums wrote: Am Mon, 23 Nov 2009 12:16:46 -0200 schrieb André Ramaciotti da Silva andre.ramacio...@gmail.com: I know, I know, they always come back. :P My Arch installation is still in my HD, just in case. About disk usage, don't forget that arch keeps a cache of downloaded packages. So I don't think Gentoo is in disadvantage here. My installation uses 1GB less than Arch (both have basically the same packages). It may not sound like a lot, thinking of the size most HD have nowadays, but it's a 20% improvement. But you can delete the cached packages in Arch (pacman -Sc or pacman -Scc). ;-) If this is useful is a different question. And you can delete the sources in Gentoo. Both distros are pretty OK here. I don't think compiling takes that much. If you're in a hurry, then yes, it'll seem like forever. I installed in a weekend, basically the same time I took to install Arch (because I install some packages, then I remember of others, then others...). But it wasn't 48h compiling, it was way, way less. On my old i686 1,3 GHz CPU with 1 GB RAM it took me a week to compile and install the complete Gentoo system inkl. Xorg, KDE, OpenOffice etc. while I only need 1 or 2 days for Arch. And KDE alone took me 1 day and OpenOffice 12 hours. I did this several years until I had enough of this waste of time and found Arch Linux. Even if compiling only takes 48 hours. Installing it on Arch takes only a few seconds or maximum a few minutes. And compiling uses more ressources and thus more energy. Indeed, if I used KDE, I wouldn't use Gentoo. OTOH, Gentoo offers binary packages of OpenOffice, Firefox and some other apps. However, from what emerge tells me, firefox sources are one third the size of firefox-bin. As Brazil isn't famous for its ultra-fast broadband, I can imagine certain cases that compiling is faster. I agree with most of what you wrote, and I don't have the slightest idea of how maintaining a Gentoo system in the long run is. I'm just trying it and I like it so far, but keep in mind I've been using it for only one week. This wasn't the first time I thought of trying Gentoo, so I installed it to see how it is or I would be always thinking about it. When I get tired of compiling, I'll go back to Arch with a better idea of its strengths. :)
Re: [arch-general] Cannot set xattr
Thank you Thomas and Xavier. I just got a little worried though. Is there any reason for user_xattr not being enabled by default?
Re: [arch-general] Cannot set xattr
On Sun, Nov 08, 2009 at 09:23:11PM +0200, Priit Kivisoo wrote: On Sun, Nov 8, 2009 at 9:14 PM, André Ramaciotti da Silva andre.ramacio...@gmail.com wrote: Thank you Thomas and Xavier. I just got a little worried though. Is there any reason for user_xattr not being enabled by default? I think it's because Arch doesn't use SELinux by default, as it's mostly for ACLs. Priit I'm sorry, I think I wasn't very clear in my question. It isn't the default in Arch Linux because it isn't the default upstream, but why it isn't the default upstream? My worry is that it's somehow related to dataloss, but I couldn't find any search result about it, so I'll assume it's secure. In the worst case, I have my (daily) backups :) Thank you all.
Re: [arch-general] CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
On Thu, Oct 22, 2009 at 11:06:32PM +0200, Thomas Bächler wrote:
Sascha Siegel schrieb:
Hi,
can someone tell my whats the reason for building the arch-kernel
with # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set?
Thank you!
Optimizing for size sacrifices performance. Read the gcc
documentation about the -O{1,2,3,s} options.
I don't know if it is as simple as that. I recall reading somewhere that
under certain circumstances a binary optimized with -Os is faster than a
binary optimized with -O2.
The reason for this is that a smaller binary may load faster than a big
one and cause less page faults.
Re: [arch-general] A little weirdness at boot time
On Sat, Aug 29, 2009 at 3:54 PM, Daenyth Blank daenyth+a...@gmail.comdaenyth%2ba...@gmail.com wrote: On Sat, Aug 29, 2009 at 13:51, Juan Diegojuantas...@gmail.com wrote: about the network card problem, have you tried adding: QUIRKS=predown to your netcfg config file I thought that quirks were removed? That's what I thought too. Anyway, it didn't work, but I found out what the real problem was. For some reason, sometimes I got: Wireless - eth0 Ethernet - eth1 and other times I got: Ethernet - eth0 Wireless - eth1 so netcfg would fail reporting that eth0 doesn't support scanning. I think I solved the problem loading both modules manually so now I always have: Ethernet - eth0 Wireless - eth1
Re: [arch-general] [arch-dev-public] [signoff] kbd-1.15-2
On Thu, Jul 23, 2009 at 10:07 AM, Roman Kyrylychroman.kyryl...@gmail.com wrote: Знак-Off: i686+x86_64 Wrong translation. :-P Znak does sound good, though. :)
Re: [arch-general] [arch-dev-public] [signoff] vc/* - tty* transition
I have to agree with pyther. You, devs, have been doing all you can to warn the users. There is the arch-announce mailing list, there are messages from pacman when it installs something that might break others, there is the forum, there are announcements on Arch's home page... Damn! there are even RSS feeds! Even though, many users will complain, just like when X got updated and HAL needed to be running. IMHO, you should say We're sorry, but we did try to warn you. I mean, what else could you do? Call every user and tell them that there'll be a big update? You're doing a great job, don't let the few people from the Arch community that don't know how to read upset you.
Re: [arch-general] [arch-dev-public] [signoff] + help needed readline rebuilds
Oh, right. Sorry about that. :) On Thu, Jun 18, 2009 at 8:03 PM, Gerardo Exequiel Pozzivmlinuz...@yahoo.com.ar wrote: André Ramaciotti wrote: Maxima doesn't use by default, but if you run 'rmaxima', it uses. Nope, rmaxima is a shell script that runs community/rlwrap. rlwrap is listed here: http://bugs.archlinux.org/task/15165 FILE /usr/bin/rlwrap ... NEEDED libreadline.so.5 ... ;) On Thu, Jun 18, 2009 at 7:28 PM, Gerardo Exequiel Pozzivmlinuz...@yahoo.com.ar wrote: These package don't use readline maxima mono-debugger koffice And these are missing in this list: mysql ratpoison I created a ticket for [community] http://bugs.archlinux.org/task/15165 -- 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] Firefox bug that may be Arch specific
It seems to be a problem with Firefox 3.5 beta only. (I can't confirm it, though) On Tue, May 19, 2009 at 1:50 PM, Kurt J. Bosch kjb-temp-2...@gmx.de wrote: On 2009-05-19 04:50, Emmanuel Benisty wrote: Hi List, Just for information, there has been already two bug reports in Bugzilla that mention a bug in the display size of textboxes. Until now, only Archers seems to suffer from this bug and one of the mozilla developers has marked this issue as specific to Arch. Therefore, I thought it could be interesting to let Arch developers and users to be informed about this. https://bugzilla.mozilla.org/show_bug.cgi?id=491114 Hi, i tried the URL from the first screenshot provided there with my vanilla Firefox on Arch. The textboxes look normal here.
Re: [arch-general] New vi/vim/gvim in testing requires intervention
I was thinking more about the installation/recuperation process than the daily usage, because it's not always possible to install vim in such cases. That's why I was questioning only vi being in [core], though having vim in [core] would add lots of dependencies, so I guess it's better the way it is. Especially if other distros are using the same vi package, and still there is nano. On Wed, May 6, 2009 at 8:07 AM, Jan de Groot j...@jgc.homeip.net wrote: On Wed, 2009-05-06 at 07:54 -0300, André Ramaciotti wrote: Hi, Just a question about this new vi package. Am I the only one having problems when openning UTF-8 files? I can't even type words with diacritics or vi will abort. For example, try to create a file with the following and then open it with the new vi package: This line will render fine Mas essa aqui não (but this one won't in Portuguese). I know that config files from Arch don't have diacritics, but I don't think that putting this vi package in core will be a good idea. (The new vim package is working fine, though.) vi is just a bare editor which has its limits. One of them is not being able to use the cursor keys while you're in insert mode for example. This issue is known on many platforms: other linux distributions, FreeBSD, OpenBSD, etc. They all have nvi or some other vi clone in the base system. If you want support for non-ASCII charsets and other things offered by vim, just install vim.
Re: [arch-general] network WTF
I know this isn't of great help, but in the forum there are lots of people complaining that iwlist isn't working as non-root user with the new kernel (2.6.29) On Wed, Apr 15, 2009 at 5:48 AM, Jaime Oyarzun Knittel joyar...@alumnos.inf.utfsm.cl wrote: David Rosenstrauch wrote: Got a bit of network weirdness going on here. 2 different Arch laptops, an old one and a new one, with completely different hardware (and also i686 vs. x86_64), but both are completely up to date with the latest repos. On the old (i686) one, iwlist scan works fine from the command line, as a non-root user. On the new one, no dice - I need to be root to get back results. Normally 'iwlist wlanX scan' as user just reads a previous scan, and with root privileges it does actually scan for networks. What makes this even more annoying is that apparently some of the wireless tools I'm using suffer from this restriction as well. So on the old laptop, kwifimanager and knemo show accurate info about the current connection (bit rate, link quality, etc.) while on the new laptop these come up empty. Maybe it's a group issue? Are the users in the 'network' group? Can you associate manually to an access point? Anyone have any idea what's causing this and/or how to work around it? Surely I don't need to run kwifimanager and knemo as root to do it. I'm guessing there's some obscure setting that's different between the 2 machines that's controlling this, but I have no clue what it could be. If it's not a permission issue, my guess is that the wireless cards send different results (assuming they're different cards). Maybe you should start the 'broken' machine with a LiveCD from another distro or ArchLinux i686 LiveCD to see if it's Arch failing or your hardware. I hope it helps. -- mitoyarzun http://www.archlinux.cl/
Re: [arch-general] x hotplugging probs
Do you have hal running when you start X? (/etc/rc.d/hal start) On Mon, Dec 1, 2008 at 2:11 PM, David Rosenstrauch [EMAIL PROTECTED]wrote: Having major probs after the upgrade to the latest X w/hotplugging. X starts, but keyboard and mouse are dead. The wiki page is really vague - I'm not really sure what/how I'm supposed to configure to make this work. It says I want to update the entries for things like input.xkb.layout, input.xkb.variant, input.xkb.rules, input.xkb.model, input.xkb.options, etc. in the 10-keymap.fdi file. But update them to what? I'm not sure what the values should be. Also, that only explains keyboard. Why isn't mouse working? Xorg.0.log tells me: (II) Cannot locate a core pointer device. (II) Cannot locate a core keyboard device. (II) The server relies on HAL to provide the list of input devices. If no devices become available, reconfigure HAL or disable AllowEmptyInput. I have these packages installed, and HAL running: xf86-input-evdev 2.0.7-1 xf86-input-keyboard 1.3.1-1 xf86-input-mouse 1.3.0-1 xf86-video-ati 6.9.0-5 xf86-video-vesa 2.0.0-2 Also, I can't currently disable hotplugging, since I don't have an xorg.conf file. (X has always been able to start fine without one; I believe it uses its own stock/internal one.) Do I really need to go through the pain of generating a conf file just to get this turned off??? There's got to be SOME way to get this to work. Help appreciated! DR
Re: [arch-general] [arch-dev-public] Xorg-server 1.5RC6 enters testing
When I installed, it did appear as a dependence. On 9/2/08, Xavier [EMAIL PROTECTED] wrote: On Mon, Sep 1, 2008 at 2:23 AM, Allan McRae [EMAIL PROTECTED] wrote: After upgrading, X failed to start with a message about libpciaccess. Installing that fixed the problem... Is this a missing dep somewhere? The dep is not missing, so this might be a pacman bug.. http://bugs.archlinux.org/task/11367 To anyone who did not upgrade yet to the latest xorg-server (currently in testing) : Please check that when you upgrade, libpciaccess is indeed in the target list. If anyone sees that it is missing, canceling the operation and running it again with --debug would be very helpful.
