Re: [arch-general] apache 2.4
On 2013-11-19 22:21:13 -0600, Caleb Cushing wrote: > I'm just curious as to why we're still on apache-2.2, at one point I think > I assumed it was a php thing, but php-5.5 got lauched a bit ago and I can > think of at least one php application I tried to run which wouldn't work on > it, so that's probably not it. From Jan de Groot[0]: > Just dropping the default choice of DNS resolving utilities because > you don't like a new version of a server and its build system is I > don't like Apache 2.4 either, but instead of dropping Apache from the > repos and replacing it with nginx I chose to keep 2.2.x and support > that instead. 0: https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024690.html pgpVYTtFBmjmS.pgp Description: PGP signature
Re: [arch-general] Audio distro
On 2013-10-17 15:46, Ralf Mardorf wrote: > sometimes I'm thinking about an audio distro based on Arch. I'm > uncertain, if I'm really willing to spend my time to contribute to such > a distro and I've got no doubts, that I don't have the skills to do it > alone. "Audio distro" is not very descriptive and doesn't describe your intent clearly. Are we talking about audio editing, audio playing, or what? pgpXwDtDe6IIP.pgp Description: PGP signature
Re: [arch-general] How to show (kernel) messages by journalctl?
On 2013-10-13 01:51, Ralf Mardorf wrote: > [rocketmouse@archlinux ~]$ journalctl -k > -- Logs begin at Wed 2013-08-28 22:06:09 CEST, end at Sat 2013-10-12 20:36:06 > CEST. -- Your user needs to have the right privileges to view kernel messages, or run as root. chris@gopher:~$ journalctl -k | wc -l 1 chris@gopher:~$ sudo journalctl -k | wc -l 957 pgp6bW4rbBoGe.pgp Description: PGP signature
Re: [arch-general] glibc 2.18-5 question
On 2013-09-27 16:36, Thomas Bächler wrote: > In his 'Aren’t statically linked executables huge?' section, he wants to > say that statically linked binaries are not as big as people think. For > that, he compares two binaries of ksh: > > Static uclibc: 170KB > Dynamic glibc: 234KB > > This comparison is entirely worthless. glibc is not optimized for size > and has lots of overhead (as he correctly states). Compile and link the > same code dynamically against uclibc and you will get something in the > tens of kilobytes. > > I use OpenWRT on an embedded device, and they use uclibc and dynamically > linked libraries/binaries everywhere - the size difference to statically > linked binaries is incredibly huge here, to the point that using static > linking will result in a firmware image too large to even flash. > > In fact, statically linked executables ARE huge and he is wrong. > > He wants to criticise dynamic linking, but in fact only compares uclibc > to glibc. You've missed the point, which is about the currently tolerated size vs. the actual size of linking with uclibc. It's not a direct comparison. > > That wording seems lost in translation (it was written by Anselm, who > > is not a native English speaker). I suspect it is supposed to read > > "statically linked executables aren't affected by vulnerabilities in the > > dynamic libraries installed on your system". I'll rewrite that. > > Statically linked binaries are affected by the vulnerabilities in the > static libraries that were installed on your system _at build time_. > > That is what needs to be said here and it is the single strongest > argument against static linking. The language barrier is no excuse for > not saying that. I don't see how that wasn't implicit, even in his version... > >> It is even worse: There is no easy way to determine which version of the > >> library a specific binary was built against. This is a security nightmare. > > > > Well, there isn't any more of a way to do that with dynamic linking, > > There is no need to do it with dynamic linking: Any bugs (relevant to > security or not) are not in the binary, but only in the shared library. > Replacing the shared library with a fixed version solves the bug. There is a reason that there is package metadata. pgpyST9W35NZX.pgp Description: PGP signature
Re: [arch-general] glibc 2.18-5 question
On 2013-09-27 15:13, Thomas Bächler wrote: > Am 27.09.2013 14:56, schrieb Chris Down: > > Well, static libraries are not a waste of space if it was intentional. > > Static linking should be preferred for a number of reasons[0], they > > should be preferred in any sane Linux distribution (of which, > > unfortunately I can't name any at the moment until stali comes out). > > > > 0: http://sta.li/faq > > Nothing about using static libraries is sane. That FAQ seems to be about > some bitterness about glibc and its code, which has nothing to do with > static and dynamic linking. Not really. The releated references to glibc are more about refuting the "size" argument when linking against it (as opposed to a more sane libc). > Now, to the key point: > > > Aren’t statically linked executables less secure? > > > > Several people argue (with implicitly requiring ABI-stability) that > dynamically linked executables benefit from security fixes in libraries > they depend on. > > What "some people argue" is true. If there is a vulnerability in zlib > (which actually happened a few years back), all that is needed is to > rebuild zlib and be happy. A statically linked system would need to find > every single binary that incorporates zlib and rebuild it. IMO either way this is a non-argument (in both directions), because any sane distribution should be able to pinpoint what needs to be rebuilt. > > This is true to some extend, but if there is a security flaw in a > dynamically linked library, all programs are affected as well; whereas > statically executables aren’t. > > This is the biggest pile of nonsense I ever read. If there is a flaw in > a library, all programs that use it are affected - including statically > linked executables that were built using that library. That wording seems lost in translation (it was written by Anselm, who is not a native English speaker). I suspect it is supposed to read "statically linked executables aren't affected by vulnerabilities in the dynamic libraries installed on your system". I'll rewrite that. IMO this is again a non-argument either way. > It is even worse: There is no easy way to determine which version of the > library a specific binary was built against. This is a security nightmare. Well, there isn't any more of a way to do that with dynamic linking, really, other than the fact it allows you to use a filename in which you can store the version number. But this is the purpose of a package manager, and documenting your build process. We could also argue that there is no standard way of storing version information in many languages, but that kind of misses the point, which is that the version is arbitrary, and should be metadata stored by the package manager. pgpKrgkKY2A_w.pgp Description: PGP signature
Re: [arch-general] glibc 2.18-5 question
On 2013-09-26 08:53, Gaetan Bisson wrote: > Some Arch packages even provide static libraries for convenience, such > as gcc and glibc. And unfortunately a few higher-level packages also > provide static libraries because their maintainers did not notice the > waste of space... Well, static libraries are not a waste of space if it was intentional. Static linking should be preferred for a number of reasons[0], they should be preferred in any sane Linux distribution (of which, unfortunately I can't name any at the moment until stali comes out). 0: http://sta.li/faq pgpmCt2ZyCzUW.pgp Description: PGP signature
Re: [arch-general] Generate /etc/blkid.tab
On 2013-09-24 19:50, Chris Down wrote: > On 2013-09-24 11:45, Ricardo Catalinas Jiménez wrote: > > I need to update the content of this file because I modified my > > partition table, but I can't see how googling around. > > This cache file is generated by blkid, which is part of util-linux. Just > run blkid as root. Apparently this is now not true (did the default behaviour change?). That'll teach me to go off memory... Why do you think you need the blkid cache file, anyway? pgpJUrlr2NCkj.pgp Description: PGP signature
Re: [arch-general] Generate /etc/blkid.tab
On 2013-09-24 11:45, Ricardo Catalinas Jiménez wrote: > I need to update the content of this file because I modified my > partition table, but I can't see how googling around. This cache file is generated by blkid, which is part of util-linux. Just run blkid as root. pgpA4gE9WNWUP.pgp Description: PGP signature
Re: [arch-general] ot: Google spamming mails messages of archlinux.org and archlinux.de are different
On 2013-09-18 23:24, Guus Snijders wrote: > My apologies for that, i hit send too quick. It was meant as a personal > message to Chris Down. Agh, so this is getting even worse. (sorry, this is OT, I'll only send this once) If anyone working at Google is reading this list: Over the last few days, suddenly my e-mails to Google Apps groups (note: not individuals) started being marked as spam. It appears now that my e-mails to individuals outside of Google Apps are also being marked as spam. I reported this with all the relevant details when it first started, but it appears nothing has happened. On certain e-mails, I get a 250 from the Google mail servers, but then it hard bounces back with a message to review the bulk sender guidelines. On some it goes through, but gets put into the spam folder. I have never sent spam from this domain. *Nobody* but me uses this domain. This appears to be connected to my mail server's address (guthrie.chrisdown.name) rather than my e-mail domain, because I have managed to Bcc another e-mail address I own and bounce it to its intended recipient from there just fine. On this mailing list, DKIM fails because arch-general mangles the headers, but on 1-to-1 e-mail, SPF/DKIM/DMARC all pass, and I *still* get put in spam. Please e-mail me if you can help. I'll appreciate it a lot. So far using the available support options has got me nowhere in fixing this delivery issue (which I *only* have with Google mailboxes, I have no deliverability problems to other providers). pgpVbc6EK4gUG.pgp Description: PGP signature
Re: [arch-general] ot: spam recognition Re: sysctl.conf.pacsave messages of archlinux.org and archlinux.de are different
On 2013-09-18 23:14, Guus Snijders wrote: > Hey, i noticed that gmail marked your message as "spam". I think it has > something to do with you e-mail address. > just a heads-up. You sent this to the entire list... who were you replying to? pgp4dlhch32wK.pgp Description: PGP signature
Re: [arch-general] sysctl.conf.pacsave messages of archlinux.org and archlinux.de are different
On 2013-09-18 10:39, Ralf Mardorf wrote: > Hi, > > archlinux.org claims "If you never customized /etc/sysctl.conf, you > have nothing to do", while archlinux.de's claim is that only those > settings > > "# Protection from the SYN flood attack. > net.ipv4.tcp_syncookies = 1 > # Disable packet forwarding. > net.ipv4.ip_forward = 0 > net.ipv6.conf.all.forwarding = 0" > > were used by a /etc/sysctl.conf that never was customized. > > I never customized the /etc/sysctl.conf on my machine, but it contains > other enabled entries too. At least on my laptop and desktop, which are both fairly old installations, these are the only ones in there. $ grep -v '^#\|^$' /etc/sysctl.conf net.ipv4.tcp_syncookies = 1 net.ipv4.ip_forward = 0 net.ipv6.conf.all.forwarding = 0 Maybe it was modified without your knowledge? pgpnYT0C2LQrh.pgp Description: PGP signature
Re: [arch-general] Arch Linux
On 2013-09-16 13:14, Abdul Halim Mat Ali wrote: > Once you miss more than 6 months of update, the effort to update to a > working state is just too time confusing. Well, don't do that, for starters. pgpoQ52cvxKM_.pgp Description: PGP signature
Re: [arch-general] Kernel freeze on boot with kernel 3.10.x
On 2013-09-01 13:48, Nils Becker wrote: > I would be grateful for any pointers on this issue and/or some > suggestions how I can at least get a useful log from the crash to open > a bug report. > > I am using the standard arch linux packages (at least where the bootup > is involved). My system is using a raid1 with encrypted root partition. > And yes, it works flawlessly if I downgrade the linux package to > <3.10.x. Even if you can't get a decent log, you might want to consider git-bisect and reporting this upstream. pgpHMS_AJVp8f.pgp Description: PGP signature
Re: [arch-general] arch rollback machine
On 2013-08-23 12:59, Joe Eaves wrote: > That's a shame, do we know why? Well, it is quite clearly explained in the link that was referenced earlier in this thread... pgpU7XNkDphHq.pgp Description: PGP signature
Re: [arch-general] [Classroom] Beginners Guide to Package Maintenance
On 2013-08-12 13:35, Chris Down wrote: > That looks like a QP encoded newline (UTC.\n), if so it's UTC with no offset. > You shouldn't be seeing that though, maybe your client is not decoding it > properly. s/newline/space/ s/UTC\\n/UTC / pgpJe0Yq1IP9x.pgp Description: PGP signature
Re: [arch-general] [Classroom] Beginners Guide to Package Maintenance
On 2013-08-12 11:59, Leonidas Spyropoulos wrote: > On Sun, Aug 11, 2013 at 6:36 PM, William Giokas <1007...@gmail.com> wrote: > > All, > > > > manfred and I have both decided that we are going to finally be having > > this class. We'll be doing the first class on Sunday, September 14th at > > 17:00 UTC.=20 > > Is this UTC-20 or just mistype? (I just want to import that on my calendar) That looks like a QP encoded newline (UTC.\n), if so it's UTC with no offset. You shouldn't be seeing that though, maybe your client is not decoding it properly. pgpJVvAMbLZJH.pgp Description: PGP signature
Re: [arch-general] CLI diffing tool other than Vim?
On 2013-07-30 09:43, Paul Gideon Dann wrote: > I run a couple of Arch servers, and I'm trying to teach someone how to go > about maintaining it (for when I'm not around). The difficulty is that when > it comes to package updates that require merging .pacnew files, I always use > Vim to merge changes. That's quite a steep learning curve to impose on > someone who's not all that familiar with a UNIX environment yet. Does anyone > know of any good & simple(ish) alternative for merging files over SSH? Well, what merge programs are they familiar with? If it is vimdiff that poses the problem for this user, you might consider running meld instead. pgpzNer70lbCd.pgp Description: PGP signature
Re: [arch-general] Arch Linux on servers?
Hi Mike, On 2013-07-09 11:13, M Saunders wrote: > I'm writing a feature about Arch for Linux Format, a UK-based > newsstand Linux magazine. I've been using Arch myself for a while for > testing new app releases, and it's brilliant for that purpose. > > I'm still left wondering though: who uses it on production servers? I > mean, the distro's overall simplicity and trimmed-down base > installation are plus points here, but surely a rolling release poses > problems. After installation you just want security and critical bug > fix updates for software, and not major version bumps, right? I only use it to manage small production environments (although these are not corporate deployments). IMO it is suitable for servers in limited cases, where neither of the following are true: - The server will be running obscure services with limited eyes-on - You will be running a lot of services I ran my entire personal development infrastructure on Arch Linux for a good while, and only stopped because I've outsourced it all now so there's no need for the installation in the first place -- that being, a CI, git hosting, HTTP server, a few other things. > www.archserver.org seems to be on hold, and I've also seen this page: > https://wiki.archlinux.org/index.php/Enhancing_Arch_Linux_Stability The only thing I did was have linux-lts installed in addition to the linux package. I never had a problem, and I ran that server for years. > which has some useful tips. But it'd be interesting to hear from > people running Arch on production servers, how well it works for them > and what (if any) problems they've faced. I never had a problem that was due to the packaging, which limits the opportunities for breakage to upstream (mainly). That just means you have to have an eye on things. I was subscribed to the announcement mailing lists for all the stuff I was using (Jenkins, nginx, git, cgit, et al). If you're running a very complex server then it can become a bit complicated to go down this road, especially if you're used to your distribution providing deprecation guidance for you. Generally things don't just "break" on Arch, there is [testing] after all. If things break, it's usually because people didn't pay attention to configuration changes or important details prior to upgrading. If you aren't willing to keep an eye on upstream and on the Arch mailing lists, it will not end well. Good luck with the article. I'm not living in the UK any more, else I would still be buying Linux Format. Chris pgpNagVL4pYL1.pgp Description: PGP signature
Re: [arch-general] [arch-dev-public] /etc/shells should keep /bin/zsh
(changed recipient back to arch-general) On 2 July 2013 05:50, S=C3=A9bastien Luttringer wrote: > Have 2 paths will be painful with chsh as I describe in the bugreport. I think I might have not quite fleshed out option "a" fully. I'm talking about a&b, not a^b. >> a. both the old path and /usr/bin be acceptable >> b. only the old path be acceptable >> c. only the new path be acceptable There is also "d. allow either", which (I think) is what you believe I meant by a. I don't think having both would be confusing. It would allow people to use the new paths (which seems sane), but also use the old ones which have been used for years and years. I agree that "allow either" is not sane from any perspective. Preferentially I still think we should deprecate the old shell paths though, unless there are technical limitations.
Re: [arch-general] /etc/shells should keep /bin/zsh
On 1 July 2013 18:32, Allan McRae wrote: > On 01/07/13 20:11, Karol Blazewicz wrote: >> I know arch-general si not for reporting bugs and I'm not trying to >> rush anyone, but it's been already a month of confusion wrt >> https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/zsh&id=c84d9770988fdc0f2e6c7bd5fa748d5a18580fb4 >> >> https://bugs.archlinux.org/task/35724 > > If a bug is open that long, it is likely to be closed as "Won't Fix". I think that one reason the bug has been open so long is because it requires consensus to resolve rather than actual bug fixing. Specifically: for binaries involved in situations where the symlink does not make the transition transparent (in this case, because it's the path itself that matters in input), should they (ideally) have: a. both the old path and /usr/bin be acceptable b. only the old path be acceptable c. only the new path be acceptable I'm pretty sure nobody would argue in favour of option b preferentially. I am in favour of Arch continuing its long history of being first to deprecate and going for c as long as it doesn't pose any major technical problem.
Re: [arch-general] Failed to build mpd from source
On 19 June 2013 00:58, Jesse Jaara wrote: > Try to reinstall cdparanoia. Some randon error might have happaned sometime > during an updat and the file did not get written to the disk. In general (i.e. always) such things simply do not happen without pacman reporting the failure, cleaning up, and dying. Such inconsistencies simply do not happen. If you have evidence to the contrary, please share it.
Re: [arch-general] About /usr/local/sbin -> bin move
On 3 June 2013 21:01, Rodrigo Rivas wrote: > Dear ArchGeneral List, > > First of all, congratulations for another brave step forward with the /*bin > -> /usr/bin move. All my Arch boxes upgraded with no pain. > > But I've noticed that there has been some discussion about moving > /usr/local/sbin -> /usr/local/bin. > > Beware! There are packages out there that are distributed as tarballs and > install themselves on /usr/local. I don't know how frequent they are, but > I've seen them. And if they happen to contain any file in /usr/local/sbin, > when untarring, it will silently overwrite the symbolic link with the real > directlry breaking any application that depends on it, and making future > upgrades to `filesystem` impossible. > > Yes, it can be fixed simply running tar with the -h (--dereference) flag, > but who will remember that? > > Just my 0.02€. Tarballs can't really "install themselves". If they're being distributed with absolute paths, you shouldn't be untarring them to the root directory by default anyway, that's pretty much asking for trouble. Extract them to a sane directory and then install what you want to the system by hand.
Re: [arch-general] Find out the changes that has done
On 23 May 2013 23:44, Gopalakrishnan NavaneethaKannan wrote: > I was trying to find out the content of a file has been modified. Basically > two three peoples are keep on changing the file. And I want to know who has > changes and what content has been modified. This information is not stored anywhere. Use a versioning system.
Re: [arch-general] Integrating Virus Scanning for Packages Handled by Pacman (Mark Lee)
On 2013-04-24 13:47, Mark E. Lee wrote: > As seen by some malignant Android apps, trust in the > developer/maintainer does not always work towards the goals of the end > users. Packages downloaded from the main repos or built from the AUR > should be scanned for both windows and linux malware to ensure Arch > Linux pc's don't become carriers for malware. Pacman would benefit from > an additional line of package scanning (not just verifying); it's sort > of like a second opinion from another doctor. I am continuing on the assumption that this is serious... The Arch Way is all about handing the power to the user, such changes (which, regardless, are pointless) should be handled by the user directly. What a virus scanner says does not necessarily equal the actuality of whether a virus exists. Besides, what if I *want* to have a virus as part of a package on my computer, for analysis, unit tests, or some such? What if an AV vendor suddenly decides that they have a vendetta against someone, and blacklist them? That has happened many times before. AV vendors are evil, evil, evil. IMO: pointless. GPG verification is almost cost-free to the user. Virus scanning is not, and is just plain wrong. Chris pgpEZsW1PYwsw.pgp Description: PGP signature
Re: [arch-general] The "new" opensmtpd package
On 2013-04-18 14:26, Sébastien Luttringer wrote: > Emotional comments, like your and Hugo come time to time, usually on > aur-general, when packages are moved from AUR to community. AUR > PKGBUILD are _not_ the property of the maintainer (even if he's a good > guy who drink beer) and sending a mail can be automated by AUR to says > : "You're package have been removed. Thanks for you support :)" If you really think my completely detached comment was "emotional", then my meaning has been lost in translation. I was merely saying that I think it is common courtesy to notify in cases such as this. Chris pgpXN0fhNyXy0.pgp Description: PGP signature
Re: [arch-general] The "new" opensmtpd package
On 2013-04-17 22:04, Sébastien Luttringer wrote: > On Wed, Apr 17, 2013 at 1:28 PM, Hugo Osvaldo Barrera > > Finally, I'm a bit surprised as to how this happened. I planned to > > propose to move my own package from AUR to [community] at some point, > > but not yet, since it only has 7 votes (way less than what the wiki > > describes neccesary). > > Be delighted with this move. You will not have to maintain it yourself > anymore. > No need to thanks TUs and Developers for their work. It's free as beer. > > > Secondly, I'm confused as to how this is done. If > > there's a package in AUR, isn't that moved into [community] instead of > > writing a brand new one? > I'm sorry, I doesn't took your package. I was not "inspired" by what > you do and I started a new one from scratch. > No offense! I must say I do find it a bit off that a package with a conflicting name would be added without even attempting to contact the AUR maintainer. There was no rush to upload this package. You could have contacted him just to say what you were doing, but you didn't. > > Please don't take this as a rant of "You broke my email setup!", > > but rather as a "Hey, this isn't very transpart to the community; how > > do these thing happen? How do I contact the maintainer? What was the > > procedure to get this package into [community]? Is there any way I can > > participate in it's maintenence?" > Transpart? Probably should be "transparent". Chris pgpJYLbjddVQE.pgp Description: PGP signature
Re: [arch-general] The "new" opensmtpd package
On 2013-04-17 08:28, Hugo Osvaldo Barrera wrote: > At first, I though I'd contact the author, but I couldn't find out > how. The PKGBUILD does not include the maintainer's email, and he's not > listed as a TU or Dev. The maintainer is Sébastien Luttringer, as is shown by pacman -Si. $ pacman -Si opensmtpd | grep Packager Packager : Sébastien Luttringer I have CC'd him. I don't know how you found it difficult to find his e-mail. Chris pgpSJrQZRHGYW.pgp Description: PGP signature
Re: [arch-general] mdadm: RAID-5 performance sucks
On 10 April 2013 00:16, Karol Babioch wrote: > Hi, > > I've got four HDDs and added them into a RAID-5 array, which basically > works just fine. However the performance sucks quite hard. I get only > about 70 MB/s when it comes down to reading and writing speeds of about > 35 MB/s. > > The hardware itself is quite decent: Intel Xeon E31260L, 8 GB RAM and > four Samsung HD204UI's. With the same setup and a Ubuntu live > environment I get about 270 MB/s reading speed and 130 MB/s writing speed. > > Therefore there must be a fundamental difference. I've compared various > values from sysctl between both environments and set them accordingly, > but to no availability. > > Anyone else experiencing the same issues and/or can you point me in the > right direction? > > At least I would like to saturate my Gigabit Ethernet connection. > > Best regards, > Karol Babioch > > I assume you're using Linux software RAID, although you don't mention. I've experienced this when using RAID6 and a suboptimal stripe cache size. Try tinkering with /sys/block/mdX/md/stripe_cache_size. In my case adjusting it to 8192 increased read and write speeds dramatically. Chris
Re: [arch-general] SOLVED Re: Installing by remote control -- network trouble
On 2013-04-03 07:19, David Benfell wrote: > Oh, how absolutely embarrassing. Whoever heard of a network device > named enp3s2? Really. Here's the service file, complete with all the > commented out stuff I also tried: See here for the reason: https://mailman.archlinux.org/pipermail/arch-dev-public/2013-January/024231.html Chris pgpiXVFO3HyVr.pgp Description: PGP signature
Re: [arch-general] svntogit 500/missing branches
Thanks, didn't think it would be on the bug tracker. On 31 Mar 2013 16:40, "ushi" wrote: > Am 31.03.2013 10:21, schrieb Chris Down: > > Sorry, missed the error message: > > > > Premature end of script headers: cgit.cgi > > > > > > On 31 March 2013 16:15, Chris Down wrote: > > > >> Is it just me, or is svntogit returning 500 frequently? When it does > >> return a real page from cgit (which seems to be about 50% of the time), > it > >> is missing lots of branches and generally just displays nothing if > you're > >> looking at, say, the log for linux-lts (what I first was looking for > when I > >> encountered this). > >> > >> Sorry if this was already posted elsewhere, I didn't see it on > -dev-public > >> or -general. > >> > > There is an open bug report in Flyspray: > https://bugs.archlinux.org/task/34467 >
Re: [arch-general] svntogit 500/missing branches
Sorry, missed the error message: Premature end of script headers: cgit.cgi On 31 March 2013 16:15, Chris Down wrote: > Is it just me, or is svntogit returning 500 frequently? When it does > return a real page from cgit (which seems to be about 50% of the time), it > is missing lots of branches and generally just displays nothing if you're > looking at, say, the log for linux-lts (what I first was looking for when I > encountered this). > > Sorry if this was already posted elsewhere, I didn't see it on -dev-public > or -general. >
[arch-general] svntogit 500/missing branches
Is it just me, or is svntogit returning 500 frequently? When it does return a real page from cgit (which seems to be about 50% of the time), it is missing lots of branches and generally just displays nothing if you're looking at, say, the log for linux-lts (what I first was looking for when I encountered this). Sorry if this was already posted elsewhere, I didn't see it on -dev-public or -general.
Re: [arch-general] Western Digital external drives
On 15 March 2013 05:56, Ralf Mardorf wrote: > yes, if I stay in the BIOS configuration the drive spins down and keeps > sleeping. I'm more curious about the installer (or a bare bones Arch install) than sitting in the BIOS. That makes it easier to differentiate Xfce problems from problems in base packages or the kernel itself. > I tested it with a very old Suse, GNOME 2 and with Ubuntu Quantal, Xfce > 4, there I get the same issue as for Arch, it spins down and up and down > and up ... Both of these environments have a lot of daemons/etc running that may wish to periodically probe drives in a way that causes it to spin up for whatever reason. Best, Chris
Re: [arch-general] Western Digital external drives
Hi Ralf, On 14 March 2013 23:20, Ralf Mardorf wrote: > I'm aware that there's an Arch Wiki about WD drives. However, I need to > know if something is bad with Linux or a brand new WD drive. > > In the German WD forms I got a reply, with the claim, that once a WD > Elements is spin down, it will park, _not_ spin up again, if there's no > access. That's usual for most drives, it would surprise me if any modern consumer WD drive didn't do this. > For my updated Arch Linux, 64-bit with current kernel and current > kernel-rt, running current Xfce 4 the drive does spin down and up again > and again even when _no_ partition is mounted, I'm running a Xfce 4 > session without an application launched, while I don't use the computer. > So with completely no access by me, > > - Arch Linux _does_ access the drive, even if no partition is mounted > - or I got a brand new drive that's broken and should make use of the > warranty It's probably neither of these things, more than likely there is some program which spins up your drives periodically to try and get information about them. Have you tested in another environment (the installer, perhaps)? My first guess would be something to do with Xfce. Best, Chris
Re: [arch-general] Forced to run fsck manually on unattended system
Hi, On 6 March 2013 02:31, edd_smith wrote: > I have noticed that over time the boxes are showing file system errors and > getting stuck during the boot phase requiring manual intervention (Either > press Control-D to continue - resulting in failure or log in to the start up > shell using the root password and run fsck manually). I simply answer yes to > every prompt from fsck and the errors are resolved, the box reboots and runs > fine. It may *appear* fine, and technically it may be correct, but your data is more than likely not in the state that you're expecting. > I need to be able to force an 'fsck -y' type command at every boot as > visiting these boxes manually isn't an option. I have already moved the > partitions to ext2 as this seemed to show a mild improvement and also set 0 > 1 flags in /etc/fstab but still I'm seeing the freezing on boot. You can do this by creating /forcefsck on each boot. A systemd service like this should do (untested): [Unit] Description=Create /forcefsck to force fsck on next reboot [Service] Type=oneshot ExecStart=touch /forcefsck > First of all should I be re-partitioning my drives to something which can > handle these kinds of sudden power outages or removing the swap space or > something? If you want to avoid data loss at the cost of performance, don't do any disk write caching. If I recall correctly, you can do this with `hdparm -W 0'. Best, Chris
Re: [arch-general] Bluetooth with G-Grip Bluetooth Speaker...
On 2013-02-25 20:36, David McDow wrote: > I believe the answer is installing PulseAudio after searching this keyword > (I've never heard of PulseAudio, but after reading a little, I understand > it's the sound server for ALSA). Actually, PulseAudio is just a sound server, it's not the sound server "for ALSA". ALSA is perfectly capable of working by itself, it just has a different implementation and featureset. Chris
Re: [arch-general] Sound problems
On 6 February 2013 16:33, Frank Zimmermann < frank.zimmermann.ber...@freenet.de> wrote: > Am Sonntag, den 03.02.2013, 22:33 -0300 schrieb Martín Cigorraga: > > Have you tried running alsa-conf? (as root). > which package provides this? It was ditched: https://bugs.archlinux.org/task/28631 Chris
