Re: [arch-general] Howto handle poppler conflict with poppler-qt3
On 03/09/10 18:03, David Rosenstrauch wrote: poppler-qt3 doesn't even seem to exist in any of the repos anymore. And KDE3 is pretty much a dead project at this point anyway. (I don't even think it's possible to build it on Arch anymore.) Probably best if you don't rely on it for anything. installing SoundKonverter put some parts of KDE 3 in /opt . Which seemed a little odd. Additionally, I'm not sure that SoundKonverter actually worked in this setup. (SoundKonverter's author is working on a KDE/QT 4 based version that s/he decided to rewrite the code significantly. and has been at alpha stage for a while. alas. It was the best sound conversion & ReplayGain-adding software.) -Isaac
Re: [arch-general] Bad attitude in flyspray again!
On 03/12/10 10:34, Aaron Griffin wrote: More-over, I think it is a bad idea. The only reason people want commenting on closed bugs is so that they can argue with the developers - give reasons why the bug shouldn't be closed. That's what a reopen request is for. If that fails, then it's time to discuss it directly with the developer in question Okay, here's my example (of a different reason to comment on a closed bug). I found bug #18022 that affected me, http://bugs.archlinux.org/task/18022 . It was marked "closed" with "Reason for closing: Fixed Additional comments about closing: Assuming fixed with libdrm 2.4.17-4 + xf86-video-intel 2.10.0-1." I requested to re-open, saying that I was running libdrm 2.4.17-4 and xf86-video-intel 2.10.0-1 and it was not fixed with those versions. I got an e-mail response from FlySpray saying that the "assigned-to" person (JGC) denied my request, with the justification being "There's already an open bug for this." I didn't see any obvious polite way to respond ( -- which is a Flyspray issue. See below for what I did next/why.). Replying in another re-open request seemed rude. If bug #18022 was a duplicate, I couldn't see anywhere on the bug that said *which* open bug it was a duplicate of, so I couldn't go make a comment "there" instead. Also, I searched, and in my judgment no other bug in bugs.archlinux.org besides #18022 seemed to quite match my symptoms. Also, I could have opened yet another bug, but that seemed rude. (Also, it's an upstream bug, albeit a bug that makes one's machine unusable, so it isn't even one that I'd submit to Arch. But, the bug existed in bugs.archlinux.org with inaccurate information that would bother future bug seekers/reporters, so I wanted it to be marked some way that's accurate, and would have liked to update it with my progress at reporting the bug upstream.) So I poked around and found JGC's email address according to bugs.archlinux.org and e-mailed in response (although I didn't get a response to my e-mail, so I don't know if it got to JGC successfully). I wrote to JGC: (I hope e-mailing your archlinux address is an okay way to reply, since your reply to my reopen-request didn't appear anywhere on the Web that I could find) If this bug is a duplicate, can you mark it as such, and say clearly which bug it is a duplicate of? All I want to do is to leave a comment about my progress reporting the bug upstream, so that other people who search and find this archlinux bug will be less confused... This text is also a bit confusing given that the described bug is not fixed, (nor even affected by upgrading to the mentioned versions) " Reason for closing: Fixed Additional comments about closing: Assuming fixed with libdrm 2.4.17-4 + xf86-video-intel 2.10.0-1. " thanks? -Isaac
Re: [arch-general] Hacking into HAL's mount process
On 03/14/10 12:30, Ray Rashif wrote: Anyway, a slightly off-topic complaint I have is that my 32GB Cruzer is slow as hell to write to at just a measly 3MB/s. My SanDisk Sansa Clip in mass-storage mode is excessively slow (also, Linux used to have difficulty mounting it in USB 2.0 mode and either fell back to 1.1 or failed). So maybe it's SanDisk's fault. A layman benchmark with two other similar smaller-sized drives, and switching between fat16 and 32, provides a hypothesis that> size ==< speed&& > fat16 ==< speed. A friend has even tried exFat but (1) Linux has only experimental read support for that and (2) its speed is as worse as the worst I am used to. Try UDF filesystem. It was originally invented for data DVDs, but I read that*, these days, Linux, Windows and Mac can all read *and write* to it (maybe due to DVD+RAM?) and that it is therefore a better successor to FAT than a newfangled Microsoft format. *there was an article I can't find again, but Wikipedia says, http://en.wikipedia.org/wiki/Universal_Disk_Format#Native_OS_support read support has been around for a while, and write support since Windows Vista, Linux 2.6, Mac OS X 10.5 -Isaac
Re: [arch-general] Bad attitude in flyspray again!
On 03/14/10 13:05, Aaron Griffin wrote: On Fri, Mar 12, 2010 at 6:18 PM, Heiko Baums wrote: Am Fri, 12 Mar 2010 17:58:34 -0600 schrieb Aaron Griffin: So you wanted to add a comment totally unrelated to the bug itself to the bug? Isn't that polluting the bug report? What happened here is exactly what I'd expect - you contacted the developer. ... See the bug referenced and the final comment in the bug. It links to two upstream bug reports OK, so the thing is... *I* knew it was considered duplicate, because I'd gotten a private response from the developer saying so (via the annoyingly tiny reopen-request-box communication mechanism). But the publicly displayed bug-resolution said "fixed in so-and-so package versions" -- versions in which it wasn't fixed (the dev and I seem to agree). Any of the following would satisfy me: - I contact dev privately, dev switches resolution to "closed - duplicate of upstream report" - I or the dev adds a comment to the Arch bug-report that says the bug is closed because it's an upstream bug (see link). (The current final comment doesn't do this because it seems to say just, hi, these bugs might be related: quote of that comment: http://bugs.freedesktop.org/show_bug.cgi?id=26266 Found more bugs that were posted here for example: http://bugs.freedesktop.org/show_bug.cgi?id=14693 Sounds like some serious problems over there. - there are probably other resolutions that would be satisfying too. For example, I'd be fine with the bug being re-opened (since it's not fixed, even if it is an upstream xorg and/or kernel bug, and since it does make graphical Arch-Linux nigh unusable for some people, aside from hacky workarounds, and since it does/did interact with packaging decisions like whether to enable KMS by default). -Isaac
Re: [arch-general] on rolling release / reinstallation
On 03/16/10 14:12, David Rosenstrauch wrote: On 03/16/2010 01:58 PM, Thayer Williams wrote: Welcome aboard and glad you're getting things sorted out. Once you have used a rolling release distro, everything else just seems silly. Reinstall every six months? No thanks! I enjoyed the 6-month reinstalls... for a while. They reminded me how my system was set up ; to make backups ; etc. When I hear about issues people run into when upgrading to, say, the latest version of Ubuntu, my thinking is usually some combination of: 1) "What's an OS upgrade?" 2) "What's an OS version?" true. and on the occasion that Ubuntu breaks something in a stable upgrade, it's awful (although I'm not sure this ever actually happened to me). I still reckon it's useful to reinstall Arch every few years, as "/" gets cluttered with old layouts, .pacnew files, miscellaneous stuff from de-installed packages, packages that are accidentally still installed due to upgrade sequences or forgetfulness, enabled daemons that are no longer part of the mainstream Linux stack (e.g. I hear HAL may be slowly going out of fashion), new advice in the Official Install Guide that you haven't checked in ages, new filesystem formats (or at least, making a new filesystem eliminates any fragmentation in the old one), decaying personal knowledge about how Linux works (due to complacency, if it's all still working, or just not having an all-in-one chance to get a "big picture")... Just don't delete your old "/" until a while after the new one is working, if you can manage it. 3) "If you were running Arch, you wouldn't be running into so many bugs on upgrade ... because you'd never wind up upgrading so many packages all at the same time." yes and no. Workarounds are easier, but need to be done more often than once every six months. It was nice to be able to do upgrades during my school-vacation-time rather than when I have a paper due shortly (there's ALWAYS a paper due, or an e-mail to get back to, at my college..) 4) "You're still running into *that* bug? That was fixed in Arch *months* ago!" :) -Isaac
Re: [arch-general] Ignoring packages and piecemeal updates
On 03/17/10 14:42, Denis Kobozev wrote: Hi archers, It has been repeated a lot of times that doing piecemeal updates with pacman -Sy pkgname is not a very good idea. What about ignoring packages? Is it as dangerous? the most likely danger with small version skews is if a library is upgraded, and a program depends on that library, and the library's new version is not binary-compatible with the library's old version. And a more general question: is it even theoretically possible to have a bleeding edge distro with piecemeal updates and with no required manual intervention during updates or is it just a pipe dream? Gentoo does some, (use revdep-rebuild. hope it works.).* NixOS does better (at least at the theoretical stuff, though it has fewer users..it was born in academia..Basically it is archtected so that you can have multiple versions of any package installed and they inherently won't conflict with each other.). *side-note: gentoo doesn't have bleeding-edge packages as often as it used to. but none are perfect. Large version skews tend to make everything somewhat incompatible at runtime. -Isaac
Re: [arch-general] patch command not working?
On 03/19/10 01:17, Preston C. wrote: My mistake. So I just 'pacman -S patch'? That works! so does 'pacman -S base-devel' which will get you some other miscelleneous tools that you have man-pages for too :) -Isaac
Re: [arch-general] Arch Linux Release Question
On 04/08/10 07:21, Joe(theWordy)Philbrook wrote:
My take on it is that while it's always a good idea to be using a
current install medium, with Arch it only matters that your system is
able to become current via update. The release of a new install set in
itself should never be a reason to reinstall a working system.
Good description (although I'm willing to bet there's some little bit of
unimportant cruft on a system originally installed several years ago,
due to various organizational updates, in addition to you as admin
forgetting which files you've left around in /etc...)
All I know for sure is that while Arch takes a bit more work to get a
running desktop system than some other distros, The idea of not having
to start from scratch every 6 months makes it "way worth it..."
if you don't mind running old versions of software... which I do...
there are always the distros with longer release cycles (some people
even run Ubuntu 8.04 (Long-Term-Support release) on their desktop still.
Although I think I'd pick Debian in that case.)
I've learned that if I can only find the right wiki entry, there is
usually a good comprehensive walk through of whatever I need to do to my
system. And this way, I wind up with a better understanding of my system.
oh indeed! Over the years, the Gentoo wiki has been a pretty good
source of info too (whatever distro you're on), and even the Ubuntu wiki
has some nice info for specific hardware (MacBooks at least), etc. Arch
has a pretty good wiki now also!
So as long as the rolling release process turns out to be consistently
more reliable than updating a 'buntu system to the next release {by
editing the sources list and doing an "apt-get dist-upgrade" (2 out of 5
such upgrades really hosed my my 'buntu installs...)}
You did it wrong, according to Ubuntu documentation. Ubuntu (unlike
Debian) (well, I'm not sure about ubuntu-server...) only supports the
GUI update manager as an update path (I believe it does a few more
things than a mere dist-upgrade, depending on the particular upgrade;
and by not doing those things, you're asking for trouble...). On the
other hand, I can't vouch for the official upgrade path being terribly
reliable (I usually reinstalled in a separate partition because there
was no way to roll back on the same partition if the new release had
different hardware problems that I didn't yet figure out how to solve).
-Isaac
Re: [arch-general] Arch Linux Release Question
On 04/10/10 01:36, Joe(theWordy)Philbrook wrote: if you don't mind running old versions of software... which I do... I take it that you don't feel that "pacman -Syu" or if applicable something like "yaourt -Syu –aur" Will bring your Arch system as fully up to date as installing the latest Ubuntu release, followed by an apt-get dist-upgrade would??? Oh, I meant that... um... you missed the rest of the quote. I was saying that people who don't mind running old versions of software can use Ubuntu Long-Term-Support releases or Debian Stable (or late-cycle Testing) or the like. Then those people only have to upgrade once every few years. Which is less frequent than 6 months. Thus, they get one advantage of rolling-release systems (namely, not having to upgrade every six months!). At the expense of using two-or-three-year-old software a lot. I'll agree that there's good stuff in the other wiki(s). But the Arch wiki impressed me with how it approaches how-to instructions with regard to helping users who really don't have a clue yet, work their way through it. I agree! I guess. I learned Linux around five or six years ago by installing Gentoo based on its wiki instructions. There is no realistic way for me to compare that to my Arch experience. Installing Ubuntu first would've been easier but I would've not come to understand nearly as quickly how my system really "works". (And so I've been able to witness HAL coming and going (affecting X configuration file formats), and D-Bus becoming nigh on mandatory, and other neat stuff (sort of a.k.a. bloat! -- of course it has purposes).) I guess I've always tried to use cli methods because I've never been comfortable attempting major upgrades while depending on the X server. Oh, I agree that upgrading from CLI feels much safer! In fact, once upon a time an Xubuntu GUI-based upgrade broke X and had to be fixed from the console. It's nice to know that there is at least a semi-supported way to do it... Incidentally Isaac, if you've got the spare partition to do a 'parallel' fresh install, you could still do an upgrade without risking the existing installation... 1) Duplicate current installation on the separate partition. 2) edit target fstab to reflect it's new location. 3) add an appropriate entry to grub 4) assuming the cloned installation works properly, you can upgrade one, while keeping the the other untouched... ooh! clever! Possibly even worth it in some cases. -Isaac
Re: [arch-general] HAL dependencies
On 04/18/10 10:13, Arvid Picciani wrote: On Sat, 17 Apr 2010 16:22:28 -0700, Rob Bean wrote: Has anyone else stripped HAL completely out of their Arch install? Thats exactly why heresy was started. ( http://hereticlinux.org/ ) Its archlinux minus hal/dbus/rapekit. Search the list for "Whats wrong with dbus anyway" under the thread "xf86-input-evdev conflicts with xorg-server. Remove xorg-server" findable here: http://mailman.archlinux.org/pipermail/arch-general/2009-December/009351.html
Re: [arch-general] stability from pm-suspend ?
On 04/20/10 10:51, Ray Kohler wrote: One thing you must avoid is to boot on one kernel version, install a kernel upgrade, then suspend and resume on the newer kernel. That will cause problems, so if you upgrade the kernel, you need to do a real reboot next time. Other than that, it seems to work well. Really?? I've never had that problem IIRC... Is it to do with suspend-fixing-hacks that unload a module before suspend and reload it upon resume?(I think none of those are needed for my machine anymore).
Re: [arch-general] stability from pm-suspend ?
On 04/20/10 10:37, Ian-Xue Li wrote: I've been using pm-suspend for temporarily shutting down the computer for later use, but now I raised the question whether it is safe or stable to do so at a constant basis. That is, seldom real reboots and often just suspend. me too, sometimes As you know that suspend don't really unmount the drives to read-only before it goes into suspension, when resumption had failed, you usually need to repair it and check for errors. This is at least the case for me when I use ext4. It's no worse than power failure, or system crash where you kill it with the power button! Actually I think it's better, because Linux does sync filesystems before suspending, so at least you won't have loss of recent data. Besides, I get more crashes when it's running normally than when it's suspended. However, restarting frequently tends to increase stability. It makes you restart your applications such as Firefox (which definitely benefits from a restart now and then). If you've upgraded (-Syu), it makes sure the running version of everything is the current version, including system libs. If there was corrupted memory due either to a bug or a hardware glitch, it cleans that up. Suspend/resume doesn't do any of these -- but then, leaving your computer on constantly is at least as bad as suspend/resume, probably worse. On the other hand, sometimes suspend is broken for some hardware. You should be able to observe this pretty easily for yourself. If, on the other hand, it looks like it's working, and if the system post-resume seems to be working just as well as the system pre-resume, then you should feel comfortable using it. After all, it's a great convenience! (modulo security considerations, if you keep an encrypted disk and don't want people who get their hands on your computer to be able to read your data! Or just login-password-wise if you're dealing with tech-ignorant friends.) -Isaac
Re: [arch-general] BTRFS integration
On 05/02/10 15:27, C Anthony Risinger wrote: rollback support and friends are very cool (this just saved me the other day actually) and i think would provide a great benefit to the arch rolling model. it could save one from pacman running out of disk space when installing something (which presently leads to unpredictable behavior that might necessitate a re-install). On the other hand, by keeping the older snapshot files (which take space), it's more likely that you do run into out-of-disk when you upgrade something in a way that's protected by a snapshot, and you have a different sort of problem to deal with then... -Isaac
Re: [arch-general] [arch-dev-public] lts kernel bump to .32 series?
On 05/05/10 13:55, Guilherme M. Nogueira wrote: If I remember correctly, the .32 series has a bug with Intel cards that causes screen flickering and the patch that corrects this was only merged in the .33 series my Intel card (945) has flickering bugs with .32 as well as .33 . (Sure it is true they merged *some* fixes to .33...the fixes that existed so far...maybe they merged some fixes to the stable branch too?) There are no flickering bugs with non-KMS mode in .32 (except that Arch userspace doesn't support it anymore since upstream X intel drivers since 2.9.1 dropped support) see http://bugs.freedesktop.org/show_bug.cgi?id=26266
Re: [arch-general] BTRFS integration
On 05/05/10 19:10, C Anthony Risinger wrote: subvolumes can be mounted two ways via a mount option: 1) subvol= 2) subvol= 1 can only be used if the subvolume is in the root of the FS, i.e. /__active would work, but /root/__active would NOT... the mount option cannot have slashes and i don't know if this will change. since we control the structure, why not the (slightly uglier) /root__active /root__rollback /root__20090807 /home__active /home__... just remove the slashes or replace them with some other character like dash or underscore. `ls` will still sort things alphabetically so there will still be some semblance of order for the humans, and it would behave nearly the same to the machine. And it will be easier for debugging purposes if all these subvolumes are accessible by name. (Do you think you can ask upstream whether they want to change or keep the restriction on slashes(i.e. volumes in subdirectories), in light of our '.' organizational ideas?) -Isaac
Re: [arch-general] intel video & suspend
On 05/06/10 11:49, Sergey Manucharian wrote: Hi folks, Regularly I put my ThinkPad R61 into suspend twice a day, and everything worked perfectly until 2.6.32 and 2.6.33 kernels. Now from time to time (≈ once a week) when I wake it up, the screen remains black in both X and text console. Nothing can bring it back, What about suspending again, perhaps waiting a few seconds, and resuming again? Does that have a chance to help? (It helps me on my Intel card's graphic glitches sometimes. I can do it easily because closing the laptop lid causes suspend, and opening it causes wake-up...)
Re: [arch-general] intel video & suspend
On 05/07/10 04:13, Christoph Rissner wrote: Now from time to time (≈ once a week) when I wake it up, the screen remains black in both X and text console. Nothing can bring it back, What about suspending again, perhaps waiting a few seconds, and resuming again? Does that have a chance to help? (It helps me on my Intel card's graphic glitches sometimes. I can do it easily because closing the laptop lid causes suspend, and opening it causes wake-up...) I have a Pineview Integreted Controller (i915) in my eeepc and this happened to me twice (in the last month) after closing the lid, but I just issue "xset dpms force off" without suspending. please inform us, what does "xset dpms force off" do? And for what circumstances/purpose do you use it? I looked in the man-page of 'xset' and found it, but I wasn't sure enough to risk using it in case it did something I didn't know how to get out of* *like blanking my screen (see "off" + mentioning suspending), or like turning on "DPMS Energy Star Features" (see man-page, "Setting these values implicitly enables the DPMS features."), or something. Please tell us :-) and did you mean -it's a preventative measure to screen-glitches? -it's a remedy for screen glitches after they happen? -it's an alternative to suspending for the purpose of saving power? -... sorry :0) -Isaac
Re: [arch-general] kernel 2.6.34-1
On 05/17/10 06:13, Tobias Powalowski wrote: Hi guys, kernel 2.6.34 first test run ... kernel is working fine for me (graphics = Intel 945) , in fact somewhat improved from the 2.6.33 version.
Re: [arch-general] PulseAudio package group
On 05/18/10 18:25, Jan Steffens wrote: I could make PulseAudio installation significantly easier by putting specially-built packages (e.g. sdl-pulse, openal-pulse) into [community] and grouping them in a "pulse" group. This group would also include a "pulse-asoundrc" package containing a pulse-configured asound.conf, as well as depending on alsa-plugins. Should I go ahead with this? Any suggestions? Sounds neat! (disclaimer: i haven't used PA on Arch, only on Ubuntu in the past.) Question: OK this would make it easy to transition *to* a PulseAudio based system, but suppose I later decide I don't like it-- is it easy to transition back to a non-PA system?(wait, it's trivial if those packages don't conflict with 'sdl' etc. -- do they?) also I wonder why the group name to be "pulse" and not "pulseaudio".
Re: [arch-general] Burning From Command Line
On 05/21/10 04:29, Joerg Schilling wrote: "Armando M. Baratti" wrote: Arch Linux Wiki: http://wiki.archlinux.org/index.php/CD_Burning#Command-line_CD-burning (see "Burning an iso image") The URL you mention gives bad advise as it encourages you to use software that is unmaintained since many years and full of bugs (wodim, genisoimage, ...). It's last updated in October 2009, and used in many distros... Wikipedia contains info and history, http://en.wikipedia.org/wiki/Cdrkit -Isaac
Re: [arch-general] intel video & suspend
oh by the way, I started using 2.6.34 kernel and haven't personally had any graphical issues since (it's in Testing -- make sure to get both kernel and firmware, but AFAICT it works fine to download/install those two packages without using any other part of Testing, at least this time around) -Isaac
Re: [arch-general] A question about Arch Sixty Four
On 05/24/10 23:48, Adriano Moura wrote: This is actually normal. 64 bits systems uses 64bits per memory address, by default. That alone would make 64bits systems eat twice as much memory than a 32bit systems. Only for the memory-address part of the data (a.k.a. "pointers"). UTF-8 text will still take up the usual number of bytes for any given piece of text. Integer values will frequently take up the same amount of space. (Programmers *can*, if they're crazy, make any differences they want in their program depending on number of bits, but typically don't.) According to this logic (which is mostly correct), programs should use somewhere between 1x and 2x as much memory depending what fraction of their data is addresses. (Probably never as much as 2x because malloc() keeps some bookkeeping data that probably isn't all addresses; because executable code isn't made of addresses; because any external data such as on the disk or the Web won't be made of addresses; and so on.) Of course you can program can be coded to use 32bit variables, not possible for memory addresses under 64-bit binary ABI, as far as I know.. but hey, isn't the larger number representation one of the 64bits advantage? not really, not for integers. The advantage for integers is that operations are faster on integers that can hold values up to about 2^64. Integers that hold up to about 2^32 are the same speed. (Compilers can emulate 64-bit ints with 32-bit ints.) I don't see the point of C's volatile-size integers like "long" sometimes being 32bits and sometimes 64bits (except for the purpose of being exactly the same size as an address, essentially in order to hold an address... silly programs...), because people have to write their code to be correct at all possible integer sizes, which basically means constraining possible legitimate values to the lower size anyway. The address space advantage of 64-bits is that your program can address more than 4 virtual GB of information at once (per executable, RAM+swap used = data+code+miscellaneous). If you have less than three or four gigabytes of RAM, this 32-bit limitation is unlikely to be of importance. Well, it affects 'mmap' of several-gigabyte-large files... (there are always obscure effects :-) On x86 architectures, the 64-bit code also has access to more CPU registers, which tends to make code run faster (although code can suffer when you use all your RAM, or if bigger data fills up CPU caches quicker). There are other little differences like this too. Also, if you want 64bit systems, you may want huge quantities of memory. More than 3GB, which makes most of the memory consumption somewhat useless. No 3 GB doesn't make memory consumption useless. Web browser with 100 tabs eats RAM. Video editing application eats RAM. Heck, even Amarok eats 80 MB RAM, and uses some CPU when it's not even playing music, these days. Also check out 'df /'. However many gigabytes you're currently using for installed software, if you were using your software all at once, well it can make your system faster for software to remain cached in RAM... But if your system is fast enough for you, don't waste time tweaking it, because if you do, it will *still* be fast enough for you! Personally, I've went back and forth between 64bit and 32bit systems several times on my 2 GB machine, and I don't think there's a very detectable performance difference. Maybe 64bit uses a bit more RAM yet uses the CPU a bit more efficiently. On the other hand, there is a binary compatibility effect (proprietary code and viruses might work a bit better on 32bit x86, I dunno, I don't try them much). 2010/5/24 Dan McGee: On Mon, May 24, 2010 at 8:13 PM, Gary Wright wrote: 2010/5/24 Frédéric Perrin: On a 64 bit machine, in « char *p; », p will use 64 bits (8 bytes), instead of 4 bytes in a 32 bits machine [I'm talking about p, not about *p which doesn't look like it exists]. Gary Wright seems to be saying that the impact is negligible. Nicky726 seems to be saying that there is a difference of up to 80%. I am surprised by such a claim, but there seems to be anecdotes on Google of people seeing the same thing. As I don't have a 64 bits machine, I can't test for myself. -- Fred Well, heres something vaguely empirical. Just downloaded the two latest netinstall medias and threw them on a usb stick. I ran precisely four commands after logging in as root on each netinstall arch: 1) mkdir /mnt/tmp 2) mount /dev/sda3 /mnt/tmp #my home partition 3) uname -a>> /mnt/tmp/gary/memcomp 4) free -m>> /mnt/tmp/gary/memcomp results to be seen here: http://aur.pastebin.com/YwTJA6cR short story: ~29 MB more used on x86_64... or about 30 percent. But when installing a whole system, many more variables come into play. It might have just been my dumb luck that ram usage ended up within 1-2 mb of eachother. 47 MB - 21 MB (for a difference of 26 MB) is what you wa
Re: [arch-general] Problems suspending since 2.6.33
I think ATI KMS (kernel mode-setting) was merged or enabled in 2.6.33? That would explain why this kernel; why the same issue happens suspending from the console; why that graphics-quirk doesn't work the same (I don't have s2ram installed since I use pm-suspend (via GNOME), but I guess that's what you meant in regards to -f, -p or -m). Suspend ought to work though (did you try testing 'echo mem > /sys/power/state' too? I think that's mostly the same as pm-suspend nowadays, maybe), but it's understandable since there are new code-paths, if indeed it's graphics that are at issue. If you want to debug I'd suggest try grabbing 2.6.34 kernel26 and -firmware from testing (e.g. you can download the packages from online), as there's a chance it's been fixed there (my Intel KMS-related issues were, for example) Also Did you search? A quick search for 2.6.33 suspend ATI Radeon HD 3600 led me to e.g. a bug here that links to an archlinux thread that contains a couple suggested workarounds to try (e.g. does disabling networking before suspending fix your resume?) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573118#10 -- those may be completely unrelated issues or then again they may not.
Re: [arch-general] regression in nouveau ?
On 05/26/10 17:01, Philipp Überbacher wrote: KMS was advertised mainly with he following features: - TTY in native resolution and hence nicer to look at - shorter delay when switching from X to TTY - can implement power-saving features - ability to run X as non-root - ...probably some more things that google would tell us quickly
[arch-general] Communication
On 05/30/10 04:50, Madhurya Kakati wrote: @nilesh you might try out #archlinux on irc.freenode.net. Its realtime chat and a great way of getting problems sorted out. yes, Nilesh, you should try use the IRC channel, it's probably a better place to ask lots of questions without annoying people (with lots of little separate e-mails) as much. And there tend to be people there who throw you various answers too! (It's a pity your bandwidth makes it hard for you to just try softwares... maybe some of your questions can be answered by Google-searching though?) -Isaac
Re: [arch-general] Compiling Firefox
On 05/31/10 00:18, Nilesh Govindarajan wrote: Nope. I have 24 addons in Firefox. Just cannot leave firefox. :) then a thought-- Do you use very many tabs or windows simultaneously? If so, check Firefox's RAM usage -- e.g. for me, firefox making my system slow is all about it using up a large fraction of my RAM. The only way to avoid this, if it's an issue for you, is... - Get more RAM - use less tabs, or restart firefox every so often (this helps hugely..I suppose this means that firefox has memory leaks or such), or maybe avoid sites that slow down firefox (I think facebook is one of them) - think about addons. Some addons can make things worse. On the other hand, I bet Adblock Plus makes things better, because then the ads don't have to fill up your computer's memory, and maybe NoScript too. Optimizing the code won't help RAM usage at all! GTK vs. QT might, but likely they both have to be loaded into your RAM already for other programs. Just check a system monitor like 'top' and see whether Firefox has lots of RAM usage, or CPU usage, or whatever you notice there. -Isaac
Re: [arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.
On 06/22/10 19:49, Allan McRae wrote: Also, as established earlier in the thread, some of our packages have patches for security issues that a a couple of years old because upstream has not made a new release. So the whole probably be fixed by upstream in less that a week and a point release made is just naive. On 06/22/10 15:21, C Anthony Risinger wrote: i just am having a hard time believing that you are not only going to track down holes, but have the competence to properly fix them, for all the reasons i've already specified. part of the situation is, lots of upstreams don't have security competence either -- especially volunteer-run projects, but I bet some commercial undertakings don't either. So they don't make point-releases as soon as an important security issue is discovered; or they make a patch but the patch is incorrect (often established distros have, in some ways, a better sense of how to patch a security flaw than a individual upstream because the distros see a lot of security flaws -- like buffer overruns, etc). It's clear that spreading more information more quickly about security issues sounds productive, (as long as the information is as correct as can be, which a volunteer team may be able to have some fair amount of competence at, I'm guessing) -Isaac
Re: [arch-general] Bashification of initscripts for moderate speedup
On 06/28/10 09:35, Victor Lowther wrote: On Jun 28, 2010, at 7:42 AM, Caleb Cushing wrote: On Sun, Jun 27, 2010 at 11:10 PM, Victor Lowther wrote: Questions, comments, flames, etc. welcome. why go this way instead of the other? (clarification why go deeper into bash instead of trying to posix-ify the scripts) ...and the main source of slowdowns in the boot sequence is I/O based -- mounting filesystems and launching programs. IIRC, Busybox shell can get notable speed boost by incorporating versions of tools like sed into the same busybox executable, such that it often doesn't have to fork and load other short-lived programs. (I believe it doesn't do bash-array-syntax.) -Isaac
Re: [arch-general] kernel26-2.6.34.1 - won't boot - stuck at "Setting up UTF-8 mode" or craters with kernel NULL pointer
On 07/13/10 10:26, David C. Rankin wrote: Can anyone think of the possible mechanism that would cause a kernel to boot once after rebuilding the initramfs, but then be corrupt for every boot thereafter?? Do you rebuild the initramfs on 2.6.32? Do you let the machine sit for a minute, shut-down, between each boot? Yes, I can think of a mechanism. I'll tell it by example: My machine has a built-in webcam that the OS has to upload firmware to on every boot. Sometimes when I boot it ends up in a screwed-up state somehow (so the webcam doesn't work), and sometimes rebooting doesn't help: shutting down and waiting a few minutes sometimes helps: booting into MacOSX then shutting down also can change things a bit, often for the better (after all this hardware and OSX were made for each other). I believe it has some sort of volatile memory that decays randomly and slowly when not powered (like RAM does). I guess that when it boots with its memory containing partly corrupted firmware, it causes some kind of trouble depending on the exact state of the memory that interferes with just fixing it by uploading new firmware. That's an example of how something could possibly persist across reboots. Maybe if you build on 2.6.32, the actual effect is that you were just booted into a good kernel that initialized some piece of hardware into some reasonable state, and this state is likely to persist across a reboot, but 2.6.34 screws up the state such that the next boot of 2.6.34 doesn't like it but 2.6.32 is a good enough kernel to nevertheless re-initialize it properly. (It could be non-volatile memory too, and the randomness could be part of linux boot process being nondeterministic as it is) Or...maybe the explanation is entirely different. -Isaac
Re: [arch-general] coping with damaging updates
On 10/27/2011 04:15 AM, Heiko Baums wrote: Am Thu, 27 Oct 2011 17:49:13 +1000 schrieb Mick: Following yet another update that has disabled user control of USB sticks, cameras, etc. and blocked user from shutting down from the desktop (in my case xfce4), I am at the end of my tether. Remove ck-launch-session from your ~/.xinitrc again. Change "exec ck-launch-session startxfce4" back to "exec startxfce4" and your user should be able to shut down from Xfce4 again. I don't know if this will fix your USB issues. Is that true? I don't see it in the Arch announcements (also shown as news on the website), which I would hope it would be if it was a newly required change. (Also I last updated two days ago, still am using "exec ck-launch-session startxfce4", and haven't noticed anything being broken. Of course, I manually mounted my USB sticks with "sudo mount" anyway so I might not have noticed...) ~isaac
Re: [arch-general] pacman new generation
On 11/22/2011 02:41 PM, Karol Blazewicz wrote: I using testing / staging repos does this already: you try out [testing], if it doesn't work, you disable it and run 'pacman -Suu'. Would using different sync dbs and a separate cache turned into a local repo make it easy enough to be practical? Also, pacsnap[1] does a good enough job for me. Which is to take maybe 70% of the risk out of upgrading -- sure, a reversion won't work all the time, but I need it rarely enough that the low overhead of pacsnap is more convenient for me than the risk of living with a partly-broken system until it's fixed upstream is bad. That being said, if someone polishes btrfs snapshots, I might use that instead. (Once I switch to btrfs, that is.) [1] http://aur.archlinux.org/packages.php?ID=34290
Re: [arch-general] pacman/libalpm/libfetch do not honor TMPDIR
On 11/29/2011 05:20 PM, clemens fischer wrote:
With tmpwatch one gets to choose files not accessed or modified for
a certain period, and it needs no config file. Arch-tmpfiles, OTOH,
would require such a thing.
Then again, a simple "find -atime + -exec /bin/rm
'{}' +" does about the same as tmpwatch.
Use -execdir instead, for security reasons (to protect against race
conditions at least a little bit better). Or even better, just use
-delete, which is built into find and also does everything to make the
command able to delete long-unaccessed directories too.
Still, for something this sensitive to mistakes*, I'd be more likely to
trust a command made specifically for the purpose. For example, web
search found me a tmpwatch man-page that says various things it's
careful about: "When changing directories, tmpwatch is very sensitive to
possible race conditions and will exit with an error if one is detected.
It does not follow symbolic links in the directories it's cleaning (even
if a symbolic link is given as its argument), will not switch
filesystems, and only removes empty directories and regular files." ...
and I think there's more.
(disclosure: I don't need it personally, as tmpfs /tmp meets my needs.)
-Isaac
* at least: shared /tmp is a bit of a security disaster ; programs like
X keep socket-type files there ; perhaps more: how many people know all
of these parts well enough to write robust generic /tmp-related code?
Re: [arch-general] [mkinitcpio] support for /usr on a separate partition
On 01/13/2012 09:48 PM, Dave Reisner wrote: The fsck hook is highly recommended for everyone, not just those with a separate /usr. Running fsck in early userspace means the device can be checked before it's even mounting -- any and all repairs can be performed without the need for a reboot. Currently my mkinitcpio.conf contains BINARIES="fsck fsck.ext4". I forget whether I put it there (probably did). Can/must I remove those from the BINARIES line to add this new fsck hook? Thanks -Isaac
Re: [arch-general] qtwebkit and html5 video
On 02/01/2012 03:40 PM, Tim Stella wrote: Do videos on the youtube site itself work? I don't think that embedded videos will work with html5. Embedded videos from youtube do work (sometimes; increasingly often as Google/YouTube becomes more confident about its HTML5 support, I think, but it seems a bit random). I know because I see them in Chromium on Arch Linux with no Flash plugin installed.
Re: [arch-general] What broke ctrl+c ??
On 07/17/10 01:49, David C. Rankin wrote: On 07/17/2010 12:01 AM, Corey Johns wrote: Try a new keyboard to help isolate the problem. I would, but this is a laptop :p For the record: All laptops I've seen have USB ports, and all modern separate-keyboards I've seen have USB plugs [unless they're Bluetooth based, which might also work with your laptop] -- so why not test with an external keyboard if you have one around? They *work* on my laptop, even if I don't use them for everyday use. [since you already found Ctrl-C works in Konsole, there's probably no use to do that test anymore though] -Isaac
Re: [arch-general] [signoff] kernel26 2.6.35.2-1
On 08/14/10 17:46, Tobias Powalowski wrote: Latest kernel is in testing, please signoff for both arches. Signoff x86_64 , it seems to be working fine for me (I had the impression that it might be heating up my laptop more than normal, but then I was doing backups last night, and I'm feeling a part of my laptop that I'm not sure if it's normally warm anyway. Is there a way to measure this? The estimated battery life from GNOME looks pretty normal, if that's an indication of heating by way of power-usage.) -Isaac
Re: [arch-general] [signoff] kernel26 2.6.35.2-1
On 08/15/10 13:07, Isaac Dupree wrote: On 08/14/10 17:46, Tobias Powalowski wrote: Latest kernel is in testing, please signoff for both arches. Signoff x86_64 , it seems to be working fine for me Also, I think the ath9k regressions (randomly losing the wireless connection) that .33 and .34 kernels had for me are resolved in .35! Yay! -Isaac
Re: [arch-general] [signoff] kernel26 2.6.35.2-1
On 08/15/10 17:45, David C. Rankin wrote: What type of video card do you have? Intel 945 class -- it's one of the first to get KMS and the support is excellent by now. I never ever get slow graphics (although I don't play games much... IIRC extremetuxracer works fine...) If you can identify anything on your box that seems to influence the idle temps or fan noise Actually, my fan mostly didn't speed up, instead the temp (if this is real) got hotter, so I manually adjusted it up a bit (via some macbook-fan-specific mechanism), but maybe it's the same thing (macbook linux are long known to run the fan a little slower than might be nice, by default, anyway). Check your battery life. My battery life isn't noticeably lower than before, which makes me doubt whether more energy is actually being used (and correspondingly turned into heat).
Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.35.2-1
On 08/16/10 12:55, Martín Cigorraga wrote: I'm having fan noise issue since latest kernel update. While system does run smooth, there's a notable increment of noise from the fan that seems to be running a little faster. On the other hand the videocard cooler seems to run as silent as ever. Kernel: 2.6.34.3-1 from [core] Catalyst: 10.7-3 from [catalyst] My system: Linux archbox 2.6.34-ARCH #1 SMP PREEMPT Wed Aug 11 00:23:15 CEST 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz GenuineIntel GNU/Linux ATI Radeon 5750HD Do you mean that 2.6.34.3 has increased fan-noise from an earlier 2.6.34 release? 2.6.34.3 is not the same as 2.6.35.* but may have some of the same patches... -Isaac
Re: [arch-general] [signoff] kernel26 2.6.35.2-1
On 08/15/10 16:57, Isaac Dupree wrote: On 08/15/10 13:07, Isaac Dupree wrote: On 08/14/10 17:46, Tobias Powalowski wrote: Latest kernel is in testing, please signoff for both arches. Signoff x86_64 , it seems to be working fine for me Also, I think the ath9k regressions (randomly losing the wireless connection) that .33 and .34 kernels had for me are resolved in .35! Yay! Actually nevermind, I still have moderate wireless issues (but they're no worse than the .34 and .33 kernels, so my signoff is still valid). -Isaac
Re: [arch-general] HAL .fdi files stopped working
On 08/31/10 17:31, Thomas Bächler wrote: I wonder why we write news announcements about these things. People don't seem to read them and ask anyway, so why bother writing the news? How about because I read and therefore ask less, and same for several other people? And am informed ahead-of-time what is likely to break -- an irreplaceable service. Also the news means that when people *do* ask, you can answer with a one-line link to the news instead of explaining it again. Seems like a most efficient system. (Not that questions about things that were recently in the news are a good thing!) -Isaac
Re: [arch-general] Hard disc clicks
On 09/01/10 00:25, Rafael Beraldo wrote: The thing is, 128 keeps the hard disc spinning down a lot. In fact, 254 is quite noiseless, but as from 253 the clicking sound returns. I read this bug page [3] but found nothing new. It is worth remembering that, sometimes, when I'm watching a movie or TV show with mplayer, it stops for less than I second, then I hear the disc spinning faster and the video continues. Some hard drives, such as yours, unfortunately don't have an intermediate setting. The hdparm -B values aren't in practice standardized. So, how did you guys set the power manager with hdparm in your laptops? Does anybody else have this problem? Since I move my netbook often, should I set it to 128 even if it spins down more than four times a minute? Depends whether you want your netbook to break (A) when you drop it or (B) after e.g. three years (or however long, depending on the frequency, more clicks = less lifetime). Some disks have sudden acceleration sensors that will also try to park the disk head when the disk feels itself being thrown across the room, making break-when-you-drop-it somewhat less likely. Since you have audible clicks, this might also weigh in favor of avoiding the clicks, if the noise bothers you or others... -Isaac
Re: [arch-general] Replace dcron once again?
On 11/07/10 13:57, Kaiting Chen wrote: I'd like to go with fcron because it seems to work very well for most people, has a lot of features while having a small dependency tree. I think fcron is kind of heavy for most users. looking at various recent x86_64 from [core], group 'base', in kilobytes from pacman -Si Installed Size, kernel26 - 114716 coreutils - 13076 binutils - 13272 util-linux-ng - 6992 bash - 3176 texinfo - 2392 udev - 1944 grub - 1900 reiserfsprogs - 1032 jfsutils - 1016 mdadm - 996 sed - 804 attr - 380 fcron - 1240 dcron - 152 While dcron is small, fcron is also small IMHO. I don't use texinfo, grub (that's the GRUB Legacy package), reiserfsprogs, jfstools, mdadm, etc. They're still part of [core]/base. It's harder to guess at the typical RAM usage of the different crons, though it's worth noting that only about 200 kB of fcron is the executables (the daemon executable itself is 86 kB), and the rest is documentation files (yay harmless documentation!). Someone who needs to shrink their system more will probably have to choose packages manually, configure their own kernel, etc. I think this amount of "heaviness" is an okay price to pay for a Unix system with a high quality cron daemon. -Isaac
Re: [arch-general] [signoff] kernel 2.6.36-3
On 11/07/10 18:23, Matthew Monaco wrote: Anyone have issues changing from Xorg to one of the tty's? I've got a radeon r600. No problems on my Intel 945 (aside from the long-standing "sometimes randomly, on boot after mode-setting but before entering X for the first time, it doesn't display anything"). Wireless is still working alright so far ( = 2 hours usage), suspend/resume worked, and nothing else seems odd about my system either. Signoff x86_64. (Is that too hasty? Should I wait a day? I'll report back if anything goes wrong, anyway.) -Isaac
Re: [arch-general] dmraid boot fail (grub errors 5 & 24) - follow up
On 11/10/10 00:40, David C. Rankin wrote: Normally that is a "Hey stupid, you have a drive failing... go fix it" issue. But it's not. smartctl is fine on all drives -- "no errors logged". Nothing in syslog or dmesg, and the disks are clean. I suppose you've looked around the smartctl FAQ and documentation to see whether smartctl being okay guarantees that the disk is okay? http://sourceforge.net/apps/trac/smartmontools/wiki I didn't find my answer within a minute, but you know your system better, the type of disk, etc., and you can also use google combining this stuff. -Isaac
Re: [arch-general] Replace dcron once again?
On 11/11/10 20:26, Alex Matviychuk wrote: Thanks to this thread I decided to look at both dcron and fcron. First google result for dcron led me to this: (As Loui noted, many of those points are changed by the passage of seven years. Distros probably use different crons now; and fcron has improved in the meantime; and dcron might have changed, I'm not sure.) In response to the initial concern about a bug in dcron, don't we have anyone in our userbase that could take a look at the dcron code? As far as updates, I wouldn't expect a basic mature package to be updated more than once or twice a year. Update frequency alone says nothing about the quality of the code. I dispute that something that doesn't always schedule jobs at the frequency the user requests (this user often being root) -- and that we as a community don't even understand when/why -- is secure. (It leaves me somewhat wondering about mature too, if no one's noticed (or fixed anyhow) this bug before. I wouldn't assume it's the only bug (although it might be).) -Isaac
Re: [arch-general] python3 thoughts
On 11/12/10 01:51, Auguste Pop wrote: ... I hope python3 won't die this way, so that all the previous efforts in transition to python3 will not go in vain. Maybe we just took the transitional leap too early when nobody is ready except us. As you note, "nobody is ready except us" -- we are ready -- the pain is not very much. On the flip side, the little pain that we do feel is a really valuable offering to the other more conservative distros: they get to see how it was for us and what the biggest pain points are in practice. You're also (I think?) making a good point that, at least where upstream projects written in python can run on python3, we as packagers should proactively package them to do so. We should be conscious if we're letting them languish in the doldrums of 2-ness untended. -Isaac
Re: [arch-general] Replace dcron once again?
On 11/14/10 09:32, Jim Pryor wrote: ... I would certainly understand and could not reasonably object to any distro's demoting dcron to an unofficial package. But as I said, I I will fix dcron anyway, I hope within the very near future. I'll announce here when I believe the git version has the necessary fixes, and if feedback sounds good, will make a new official release. Extra hands might not help right at this particular moment, but they would help the package be more reliably maintained going forward. I'd be glad to give other interested developers git-push privileges. Thank you for your efforts! I am sure it is a service to many people to have a dcron that works well. Even if Arch devs decide a different default cron daemon for Arch some day.
Re: [arch-general] dropping go-openoffice/icu-4.6 rebuilds
On 12/06/10 12:43, Andreas Radke wrote: The former ooo-build project "go-openoffice" is deprecated by upstream developers in favor of the upcoming LibreOffice (LibO). It's time to drop it from our repos while we are rebuilding all OpenOffice branches for the icu-4.6 .so-bump. Please use the vanilla Oracle openoffice-base packages or try out the new and already very stable libreoffice packages. The Oracle office beta and devel packages will get rebuilt when new upstream releases will happen. Don't expect them to work when we move icu-4.6. They are of low interest. Hmm, this should probably have gone (should go?) in announcements / archlinux.org homepage. I upgraded and forgot about this until I ran 'soffice' and it didn't start.* (I'd been using go-openoffice. Installing extra/libreoffice made it work again.) *unsurprisingly, the error is, (put here for the sake of googlers) : /usr/lib/go-openoffice/program/soffice.bin: error while loading shared libraries: libicuuc.so.44: cannot open shared object file: No such file or directory -Isaac
Re: [arch-general] When will Arch switch to Upstart
On 01/19/11 14:03, Yaro Kasear wrote: And comments about Ubuntu and their competence are entirely relevant to this discussion, as Upstart is entirely their creation. Would you rather I talk about people who had nothing to do with its code? The Ubuntu devs are behind Upstart, they're not that great at what they do when it comes to the actual system side of Ubuntu. Therefore why should we consider Upstart an improvement. Argument ad hominem. We can be precise; it's more obviously rude that way. Scott James Remnant wrote Upstart. I can't speak for Ubuntu, but I've seen Remnant presenting and he seemed quite competent. Software is hard; Upstart was the first attempt at changing 'init' in decades, so there was little experiential knowledge of Linux 'init' development when it started in 2006. In fact, in the process of writing Upstart, Remnant and his co-workers made Ubuntu boot faster largely by working with Xorg and Linux kernel developers. There are now upstream changes due to the risk Ubuntu took with Upstart. *Arch* therefore now boots faster because of Remnant. He's a pretty smart guy who knows what he's doing even if some of us disagree with what he's doing; I was at his presentation "How We Made Ubuntu Boot Faster" http://events.linuxfoundation.org/linuxcon2010/remnant That is equally no reason to switch to Upstart. We can be grateful to Remnant and choose the best (technically & socially) solution *for Arch* *in 2011*. Of course he's enthusiastic about Upstart but I'm sure he wouldn't mind. (I don't pretend to know which solution this is, though it sounds like Arch's current init system, or systemd, are likely to be default in the next year or two.) After writing the above, I checked my assumptions and Google found me Remnant's entirely reasonable blog post about systemd. http://netsplit.com/2010/04/30/on-systemd/ -Isaac
Re: [arch-general] Question about automated builder
On 01/28/11 09:32, Jakob Gruber wrote: Another aspect of this is security. Right now, any dev / TU could theoretically check in a correct PKGBUILD but upload a binary package with *insert malicious content* in it to the repos with a very low probability of anyone ever noticing. A (mandatory) central build server could guarantee that the package is actually built with the specified publically available PKGBUILD. I'm not a security expert so please call me out if I'm talking nonsense. You have to trust all servers that are used for building. (and the servers need to collectively have enough processing power to build everything!) If we take random volunteers then it's not secure. But it can certainly help security in certain ways if done right. ~Isaac
Re: [arch-general] Howto - tell pacman -S (-U) to overwrite existing file in filesystem?
On 02/20/11 18:28, David C. Rankin wrote: The question is "Can I do something in the PKGBUILD to tell pacman - if the file is already there -> overwrite it?" Please don't. Put it in your release notes instead. Don't silently overwrite user-written files! You might look into configuration management too (the thing that generates *.pacnew files among other things) -- I'm not sure if it'd be useful, but that research might tell you what's been done/discussed before when making /etc files be newly pacman-managed. -Isaac
Re: [arch-general] audio skipping frequently with vlc
On 03/02/11 12:37, Divan Santana wrote: On Wednesday 02 March 2011 08:18:06 Matthew Monaco wrote: I recently noticed then when playing DVDs and other audio files through VLC that the audio skips frequently. It doesn't get out of sync, just goes mute for a split second. I tried the past few versions of VLC but it still happens, so I guess it's one of the dependencies, but I'm not sure which. Has anyone noticed/fixed this? I've also this, specifically when playing music via amarok and KDE setup using phonon-vlc as preferred and specifically just before and after song change. I use both VLC, and Amarok with phonon-vlc, (on Arch; since phonon-vlc emerged around June or August) and it's been working fine the whole time. (Except that Amarok with any backend, for me, (-xine, -gstreamer, -vlc) used to sometimes crash around song-change and now sometimes just does weird-but-predictable things around song-change. I think that's unrelated.) -Isaac
Re: [arch-general] audio skipping frequently with vlc
On 03/03/11 00:08, Matthew Monaco wrote: What output are you using? I'm on HDMI. Here is what happens in VLC with a verbosity of 2 for every skip: Built-in laptop output (both internal speakers and headphone jack work). lspci calls it "Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)". Working with either plain ALSA or Pulseaudio in force. (Modulo an unrelated default-muted-channel issue that I fix every boot so I can hear anything.) My laptop has a Mini-DVI port for which I have no adapters, and USB and Firewire ports but e.g. I have no USB Audio devices, so I don't think there are any other output modes I can test. [0x3415df0] main audio output debug: audio output is starving (21344), playing silence [0x3415df0] alsa audio output debug: recovered from buffer underrun Is that log output from VLC? Kernel? Something else? I've found some forum postings on this, but can't find any definitive solutions, certainly nothing that's worked for me. Certainly you're having a problem! I'm just hoping that the info that not everyone has the problem is helpful for debugging (or I could post some log if you think it'd help). FYI, sometimes I get skipping due to system load (additionally DVDs, being optical media - high latency -, are often a bit more annoying) -- but I can deal with these whenever they occur by closing other open programs. -Isaac
Re: [arch-general] knotify4 is eating 90%+ of the CPU in gnome - can it be reniced or something?
On 03/02/11 17:37, David C. Rankin wrote: Guys, Running Gnome, knotify 4 is killing my system. From top, it is taking over 90% of the cpu: 13123 david 20 0 155m 40m 17m S 91 1.3 60:06.32 knotify4 Can this 'feature' be turned off when I'm in a desktop other than kde4? I don't think you want the "feature" of 90% CPU usage when you're running KDE either. It sounds like a bug. Try Googling. Just googling knotify4 gave me two Arch Linux posts and an upstream KDE bug that collectively offered at least three workarounds to suit your fancy.
Re: [arch-general] [signoff] kernel26-2.6.38.1-1
On 03/25/11 02:46, Tobias Powalowski wrote: Hi guys, please signoff 2.6.38 series for both arches. It's a security update too so it would make sense, to move in .38.1 to [core] soon. Or try/upload 2.6.37.5 for those security reasons! Given the amount of hardware that I have that people reported subtly broken with 2.6.38, I'm nervous about rushing the 2.6.38.1 into [core] any faster just because of security. sorry for the gripes -Isaac
Re: [arch-general] New Kernel - Virtualbox VM kernel crash on shutdown
On 03/29/11 20:00, David C. Rankin wrote: On 03/29/2011 06:56 PM, David C. Rankin wrote: On 03/29/2011 12:26 PM, C Anthony Risinger wrote: doesn't vbox have to be rebuilt everytime the kernel changes or something? or the guest additions? or both? Oh, yes, If not rebuilt - you won't be able to get the started. Here, the vm runs, but there are shared folder issues and it crashes on shutdown. This all *started* with kernel26-3.7.4. I can reload kernel26-3.7.3 and all is good. There is something new that vbox doesn't like... And just to be clear -- this is Arch installed as the "guest". There is something that is causing problems with Arch running inside vbox with kernel26-2.7.4 and kernel26-2.7.5. Sorry for the "3" kernel typos above :p Kernel versions resemble 2.6.33.2. Or kernel26 package versions resemble 2.6.33.2-1 . Your typoes are much worse than 2 vs 3. :-D
Re: [arch-general] Can a ISP modify incoming http traffic to display ads using transparent proxy server ?
On 04/02/11 02:45, Partha Chowdhury wrote: My ISP is running a transparent proxy server on port 80 as I found out from this thread http://mailman.archlinux.org/pipermail/arch-general/2011-March/019172.html Now from last two or three days, I keep getting pop-up ads from a particular domain on every website i go to - even on text only websites ! If i choose another proxy server in firefox , then that does not appear on any site. What happens if you go to an https: site? The data generally cannot be modified between the server and your browser in that case. Also... your in-browser proxy choice works around the ISP proxy? Interesting. (Is the cable operator trying to be unpopular while making ad-money?) -Isaac
Re: [arch-general] What happened to Powerpill?
On 04/04/11 00:00, Brendan Long wrote: On 03/28/2011 03:43 AM, Cédric Girard wrote: On Mon, Mar 28, 2011 at 11:07 AM, Oon-Ee Ng wrote: If you have 10 files to download, powerpill allows for 1 file from mirror A, another from mirror B, and chunks of that large 68MB file from mirrors C, D, and E at the same time. With the other solutions, you'd still wait for file 1 to finish downloading before downloading file 2. I understand this as being more flexible. But bandwith-wise, I do not see why the Powerpill solution is more efficient. Or maybe this come useful only when downloading small files where file content transfert itself is negligible compared to connection opening and other protocol handling... For me the benefit came in two parts: * When you download a bunch of small files, most of your "download time" is actually just starting connections. Powerpill starts a bunch of connections at once so you can actually use your bandwidth. * A lot of Arch's mirrors are really slow. Powerpill lets you not worry about the speed of individual mirrors, because it's only their combined speed that matters. I found both of these are heavily mirror-dependent (and occasionally a given mirror changes to be worse or better than it used to be). It's dramatic enough that it feels like "some have problems, and some don't". I've got a good mirrorlist currently... check https://www.archlinux.de/?page=MirrorStatus , and I think there was a command-line tool... also the kernel.org one likely works well everywhere (?) so if overwhelmed by the options could check if that changes anything - http://mirrors.kernel.org/archlinux/$repo/os/$arch -Isaac
Re: [arch-general] Future of 'kernel26'
On 05/25/11 11:42, Heiko Baums wrote: Am Wed, 25 May 2011 17:38:33 +0200 schrieb Heiko Baums: I guess the best name is kernel30. Forgot to mention that the kernel package is called kernel... in every distro I know. BTW, Debian and Ubuntu switched to calling their linux-kernel-related packages 'linux' (previously 'kernel') a few years ago. For example, there is http://packages.debian.org/stable/kernel/linux-image-686 -Isaac
Re: [arch-general] [signoff] linux-3.0-2
On 08/02/11 12:52, C Anthony Risinger wrote: On Tue, Aug 2, 2011 at 11:45 AM, Tom Gundersen wrote: On Tue, Aug 2, 2011 at 6:38 PM, C Anthony Risinger wrote: ... out of curiosity, if the original reason for having a `kernel26` package was to also have a `kernel24` (from what i read -- wasn't around then) how is this handled with the `linux` package? or is this a non-issue? We no longer support linux 2.4... How would this be an issue? sorry i wasn't clear -- i meant when the time comes that dual support would be desirable, eg. linux 4.7 or whatever :-) kernel26-lts / linux-lts (side note -- are we renaming that package now or later?) That's our current dual kernel. It's not difficult to add back version numbers if they become really necessary - it happens here and there (e.g. python - which was obviously much more complicated because it relates to hundreds of packages rather than one or two). There might be some AUR packages with specific kernel versions - having the main package be 'linux' doesn't hurt that either.
Re: [arch-general] Forums search interval
On 10/18/2011 03:59 PM, Heiko Baums wrote: And does Google really need to know everything? The forum content is public - Google already knows that. Your search isn't - I am using DuckDuckGo now for that reason - they have an excellent non-tracking policy. I used to use "Scroogle" but DuckDuckGo's results seem at least as good as Google's to me now. And what is the forums' search function for? Speculation: If it was phpBB, I'd definitely say "because Google hadn't become ubiquitous by then" (Google only started in 1997!). In fact it's FluxBB, which started in 2008 as a fork of PunBB, which might be as old as 2002 or 2003 judging by the footers of these PunBB-related forums: http://www.punres.org/ http://punbb.informer.com/forums/ . ~isaac
Re: [arch-general] Default value of "j" in makeflags of makepkg.conf
On 01/03/2014 10:37 AM, Anatol Pomozov wrote: Using -j$(cpunum) is a sane default that saves a lot of time to users. I agree, but for the record, 'nice' and scheduling are no panacea in my experience. It's fine for CPU loads, but compilations are also disk-heavy (which mattered when I used a spinning disk) and sometimes RAM-heavy (-j8 on my pet C++ project uses 2GB of RAM, which could push other programs I'm using into swap). -Isaac
Re: [arch-general] Default value of "j" in makeflags of makepkg.conf
On 01/03/2014 04:10 PM, Karol Blazewicz wrote: On Fri, Jan 3, 2014 at 9:55 PM, Isaac Dupree wrote: On 01/03/2014 10:37 AM, Anatol Pomozov wrote: Using -j$(cpunum) is a sane default that saves a lot of time to users. I agree, but for the record, 'nice' and scheduling are no panacea in my experience. It's fine for CPU loads, but compilations are also disk-heavy (which mattered when I used a spinning disk) and sometimes RAM-heavy (-j8 on my pet C++ project uses 2GB of RAM, which could push other programs I'm using into swap). -Isaac Have you tried using ionice? I think I tried ionice once, but now I have an SSD that's fast enough that I wouldn't be able to tell the difference. Does it work well for you? -Isaac
Re: [arch-general] Default value of "j" in makeflags of makepkg.conf
On 01/03/2014 04:03 PM, Mark Lee wrote: On Fri, 2014-01-03 at 15:55 -0500, Isaac Dupree wrote: On 01/03/2014 10:37 AM, Anatol Pomozov wrote: Using -j$(cpunum) is a sane default that saves a lot of time to users. I agree, but for the record, 'nice' and scheduling are no panacea in my experience. It's fine for CPU loads, but compilations are also disk-heavy (which mattered when I used a spinning disk) and sometimes RAM-heavy (-j8 on my pet C++ project uses 2GB of RAM, which could push other programs I'm using into swap). -Isaac Salutations, I got to ask why you are running make with 8 threads on a system with only 2 GB of ram? Heh. Well, I have 8 GB of RAM, but I'm often using most of it already. $(nproc) is 8 because there are 4 cores with each with hyperthreading (Intel Core i7). The project builds roughly at the same speed on this box at anywhere from -j4 to -j8; if that generalizes to other projects and there's an easy way to count cores not hyperthreads, cores might be a better Arch default. Shrugs. There are quite a few 4GB i7 systems out there too. Quad core ARM systems are another point on the cores-to-RAM-ratio spectrum. Probably most code doesn't consume 256 MB RAM per GCC invocation. C++'s templates and lack of module system... -Isaac
Re: [arch-general] [arch-dev-public] GHC 7.8.1 packaging decisions for Arch Linux
On 04/09/2014 01:27 AM, Thomas Dziedzic wrote: Problem 2: Users are confused whether they should install packages from the repos or using cabal-install. This in turn sometimes causes them to install some packages from official repos, some from the aur, and some using cabal-install Explanation: Packages should ideally be installed from one place, either using repos/aur or cabal-install. Said that, it is entirely possible to use both repos/aur and cabal-install but for simplicity, one source is preferred. Doesn't every language with its own package manager have this problem? For example, Python. Is there a good solution? Users knowing about this issue and making their own decisions is the current solution on every distro I'm familiar with. Change 2: Make a news item stating that cabal-install is now the recommended way to install haskell packages. This wouldn't pollute the filesystem since cabal-install installs packages to the ~/.cabal directory by default. We might need to include a tip sheet about how you would handle ghc updates since it requires extra user steps. This is the way I do it on my personal computer, FWIW. If there were any packages in the repo written in Haskell that are used by non-Haskellers, then all those packages' deps would have to be in the repos too. (e.g. darcs and pandoc, which are in AUR currently). Cheers, -Isaac
Re: [arch-general] Trust This Computer?
On 06/30/2014 08:54 PM, Hunter Jozwiak wrote: > How on Earth do I import all my tunes in an orderly and organized > manner? Windows is out of the question here, since my computer doesn't > have enough metal to run it properly. If Apple kept the ID3 metadata in the files intact, a program (such as EasyTag) should be able to use that metadata to sort the files into a sensible structure. -Isaac
