Re: [arch-general] dmraid wiki wrong on chroot proceedure??
On 01/17/10 09:54, David C. Rankin wrote: Guys, I was helping someone on installing grub and I noticed the following on: http://wiki.archlinux.org/index.php/Installing_with_Fake_RAID under Install Grub that does not look correct: # mount -o bind /dev /mnt/dev # mount -t proc none /mnt/proc # mount -t sysfs none /mnt/sys # chroot /mnt /bin/bash That should be: # mount -o bind /dev /mnt/dev # mount -o bind /proc /mnt/proc # mount -o bind /sys /mnt/sys # chroot /mnt /bin/bash shouldn't it?? I know there wasn't a sysfs involved the last time I did this. Eh no? Both examples stated above are correct. Glenn
[arch-general] Tiny webserver to run as root
Hi all Does anyone have a suggestion for some software, a tiny webserver that is able to run as root and execute CGI scripts? It should be smaller than apache and preferably even smaller than lighttpd. It doesn't need a whole lot of features, it only needs to be able to execute CGI scripts. I have tried a few: nanoweb (which is written in php as well) but has some problems with CGI scripts and when it runs in multi process mode it brings the system load up to exactly 1.00. Nullhttpd, but it's old and unmaintained. Tinyhttpd isn't up for the job as well (kept crashing at times). Thanks, Best regards, Glenn
[arch-general] A universal Operating System API - why don't we have it?
Hi all It dawned on my that lots of industries have standards and companies generally keep to them. For example slabs of aluminium have standard sizes, building materials have well defined specifications, or take electrical components: there's a huge list of standardized components. You can expect between 220 and 240 VAC from your wall socket, fuses have standard formats and ratings, 1 meter here is exactly the same as 1 meter in another country, etc... Even CD's, which have been around for decades by now, have always been created using the same format (albeit extended somewhat, over time, but a normal CD pressed now should still play in a CD player that's 20 years old). It allows for a very competitive market where choices are made based on price, quality, availability, etc... Why doesn't the computer business have something similar? Sure processors are interchangeable in a limited way, we use standardized RAM, standard interfaces for accessing our peripherals, etc... But not when it comes to software. Why don't we have one universal API that works on every operating system? Yes there is libc, the language C is defined in some way, but I'm talking about stuff that would make applications 100% portable. Things like enumerating all hardware devices, configuring a network interface, drawing a window, ejecting the CD-ROM drive, getting notified about new hardware plugged in, etc... It's different on every operating system. You cannot write a driver for Linux and expect it to work on FreeBSD. You cannot write an application for windows and expect it to work on Linux. When you buy a piece of hardware you usually hope for the best that it'll work out-of-the-box including all extra features. So why is that? Why hasn't someone stepped up and even try and create a universal operating system API? Is it because the computer business is still a child in some way, compared to other industries? Just a thought. Glenn
Re: [arch-general] Help - Sound Disappeared -- Really! All modules - Gone?? (kernel bug?)
David C. Rankin wrote: Guys, This is really strange. Sound used to work on my laptop, now it is just -- gone. The hardware hasn't changed (obviously): David Just an observation I'm making here, when I sift through the e-mail archives of the Arch e-mailinglist about every 7th or 8th post is yours... That's quite a lot compared to how many members are subscribed. When reading back those post most issues are trivial and solved 2 or 3 posts later... It also occurs to me you run testing as well - which will definitely break stuff as that is the nature of testing. The issue you've had right now would also have been prevented if you would have paid closer attention to pacman's output. I'm not talking about your right to post to this list, I'm merely suggesting maybe you should take more time analyzing your problem instead of immediately posting your problem here. Best regards, Glenn
Re: [arch-general] ftp.archlinux.org rate limiting
Phillip Smith wrote: *anon_max_rate* The maximum data transfer rate permitted, in bytes per second, for anonymous clients. Good luck! Ah, I didn't think about doing it in the daemon... That would definitely be easiest, I think I'll do it this way! :) You don't need tc to do traffic shaping, you can use iptables as well for this. It is more primitive though, but for simple tasks it's easier than using tc. Now I'm curious... Everything I've seen points to using tc to be able to rate-limit in kbps... The only rate-limiting I know you can do in iptables by itself is packets-per-timeframe (second, minute etc) limiting? You can use hashlimit for it. And how is rate limiting in kbps not the same as packets-per-timeframe? It's exactly the same. Glenn
Re: [arch-general] ftp.archlinux.org rate limiting
Phillip Smith wrote: Hi all, Could someone share the details of how the 50kbps rate-limit is implemented on ftp.archlinux.org? I know Google gives me plenty of results for rate-limiting with iptables and tc but I've never had much success with tc, and the ftp.archlinux.org rate-limiting seems to work perfectly... So why try reinventing the wheel? :) Cheers, ~p You don't need tc to do traffic shaping, you can use iptables as well for this. It is more primitive though, but for simple tasks it's easier than using tc. Glenn
Re: [arch-general] The ultimate Home Theater / media center computer
So I finally got around to spending some time again on this project. I ordered the Silverstone LC-19 case discussed below but for the motherboard, I went with a Zotac IONITX-D-E [1]. Though I'm still having some small issues and the system is not complete (it doesn't meet all the requirements yet I set below), I can already tell it's an awesome hardware combination. As the mediacenter software, I chose XBMC (because I think it works the best and has built-in support for VDPAU). I'm writing a full review and intend on writing a wiki page to achieve the perfect setup in combination with ArchLinux. [1] http://pden.zotac.com/index.php?page=shop.product_detailsflypage=flypage_images.tplproduct_id=175category_id=15option=com_virtuemartItemid=1 Best regards, Glenn RedShift wrote: Hi list Somehow I got it into my head that I want a home theater PC. I'm growing tired of having to watch television and movies on my computer's 17 LCD screen. At the shop I used to work at, once in a while we'd build a media center computer, but the concept never really took off here (Belgium). There are many reasons for that, such as: * Television is major suckage here (thanks to That Big Company and Government-Not-Governing). The entire country is split into very small regions where broadcast frequencies differ, there's no unified TV guide system, not all regions can receive all channels. Digital television is even worse: That Big Company forces you to buy one of their proprietary decoders. The only way to receive digital television without restrictions is DVB-T with a very limited number of channels (basically nothing). * At that time, the hardware sucked (noisy, too big, not stylish enough to put it along your other hi-fi components, not powerful enough, limited digital outputs, etc...). The software wasn't much better (too complicated, took a long time to start, etc...). Anyway, my goal is to build the *ULTIMATE* HTPC. As such, strong demands must be met: The hardware: * It should be stylish, a timeless look which fits with your other hi-fi components. * It must be entirely silent. Zero moving components. No exceptions. * Unrestricted fully digital outputs. * Must be able to play at least 720p MKV's using x264 encoded video. * Easy remote control. No remote controls with more buttons than there are stars in the sky and certainly no dual function buttons (those functions in a different color which you need to flick a switch or are context dependent). * Able to receive DVB-C. The software: * There is no room for Digital Rights Management fascism. All content must play flawless and in the highest quality possible. In some cases this will mean circumventing protections. That'll probably make the device illegal in some countries, but I don't care. * Easy user interface (also see hardware remote control point). * Can connect to NAS or other storage devices such as USB sticks. In total: * Must be a complete replacement for your DVD player and other media devices. The goal here is keeping the number of remote controls down. Ideally you should only have two: one for controlling your HTPC and one for your hi-fi set. * It is geared towards modern television, that means stuff like HDTV and no legacy connector stuff (like composite). With those goals set, I started looking for hardware. Here's what I've come up with: * Case: Silverstone LC19 http://www.silverstonetek.com/products/p_spec.php?pno=lc19area=usa + Fanless PSU. + Casefans can be removed + Comes with PCI-e and PCI risercards + Integrated cardreader and slimline optical slot + Available in black and silver + Accommodates standard ATX I/O shield + Room for a 3.5 storage device (SSD?) + Vents right above the CPU + Slim - Fits only small motherboard sizes - Only 120 watt PSU - No infrared receiver, no remote control * Motherboard: Asus P5N7A-VM http://www.asus.com/product.aspx?P_ID=8YiUFvK51IergAqYtemplete=2 + Powerful on-board graphics (nVidia 9300) + Supports 16 GB of RAM + eSATA port + Optical audio output + HDMI, DVI and VGA video output + Gigabit ethernet + Solid caps - nVidia on-board graphics (requiring proprietary driver) - On-board graphics use system memory - Crappy realtek audio codec * DVB-C receiver: ? I have zero experience with DVB-C receivers for computers. I've come across the DVBWorldDTV Cable (http://www.worlddvb.com/product/htm/pcic.htm) which seems to provide what I'm looking for. Anyone know how good this hardware actually is and how well it's supported by linux? I have an old hauppauge PVR-350 card which works well, unfortunately hauppauge doesn't seem to have DVB-C products. * Remote control: ? I want to have something simple here. Maybe a small USB infrared receiver and a simple remote control with buttons up, down, left, right, enter? Anyone know if such hardware exists? * Processor: Intel Celeron? No idea how much processing power would be required for a decent HTPC
Re: [arch-general] pam settings INSECURE
Caleb Cushing wrote: so here's the problem I've discovered http://xenoterracide.blogspot.com/2009/11/bypassing-disabled-accounts-with-kdm.html links to arch bug included posting here because I believe both kde's and arch's developers responses are less than satisfactory. This is a security bug an easy to fix without making users lives more difficult. Who said that setting the user's shell to /bin/false means disabling a user?
[arch-general] We have lost the desktop war. The reason? Windows 7.
This thread will probably erupt in a massive flamewar, yet I decided to post my story anyway. I am talking about the desktop experience in general, not the technical details behind it. Keep that in mind. I've been working these past few months with KDE 4.3 and it feels very sluggish and incomplete. I can't enable the desktop effects because that makes things even slower. I'm doing this on a fairly decent setup, an AMD Sempron 2 Ghz with an nVidia FX5500. My laptop suffers from this sluggishness as well. On top of that, lots of things annoy me in KDE 4.3, see the end of this post for my top annoyances. Yesterday I had to reboot to my Windows XP installation on this computer and I was shocked when I arrived in XP's userland. Everything was ridiculously fast. When returning to my linux desktop everything felt even more sluggish. That's when I decided to go back to KDE 3.5. I restored my old KDE 3.5 profile, installed the necessary packages and logged back in. WOF, everything is fast again. Opening new windows is instantaneous, hell even bringing up context menus is faster. If Linux is that much better, why does the current Linux desktop (KDE 4.3) still suck compared to an operating system that's 8 years old? Last week I also had the chance to check out Windows 7, and I was stumped. I was genuinly impressed by Windows 7's GUI. It feels fast, works fluently, it has nice effects which just work and work FAST. When browsing around it felt like a very solid desktop environment. I am jealous. I really am. The thought of using Windows 7 in favor of KDE 4.3 has occured to me much more than I like. And it's little things like dragging the windows to the top of the screen makes them maximized, dragging them to the left makes the take exactly 50% of the screen. How many times have you been manually resizing windows to fit next to each other? I have, too many times. These are things that really improve your productivity. So when should we have started working at a better desktop environment for Linux? When Mac OS X came out. When was that again? 2001. Yes, it really was that long ago. It already had awesome desktop effects that just work on (compared to these days) VERY modest hardware. And it worked fast as well. It was and still is a solid desktop environment. From that point on the Linux community should have recognized the threat Mac OS X was for the desktop environment. Unfortunately nobody did and we went on creating a big mess, fighting over implementations and technical details instead of attempting to create a solid desktop environment. Yet we did have a second chance in 2007. Microsoft obviously screwed up with Windows Vista, we had the chance to win back alot of terrain here until the release of Windows 7. So what did we come up with? KDE 4. Yes, a big dissapointment. We still don't have something that's comparable. So basically, where are we at? KDE 3.5 is Windows XP KDE 4.3 is Windows Vista ??? is Windows 7 When are we getting to the Windows 7 stage? Microsoft didn't do a big advertising campaign for the launch of Windows 7, nevertheless they delivered a big slap in the face to the Linux desktop environments. The numbers speak for themselves, Windows 7 has already sold more copies in its first week than Windows Vista did in its first month. And with good riddance, Windows 7 really is better than Windows Vista. Microsoft recognized the problems with Windows Vista and dealt with them. And dealt with them swiftly if you ask me, doing it in less then 3 years. Conclusion We are losing ground. We are losing it fast. Our competitors recognize what the user wants and delivered. If we are comparing enterprise desktops, there's no going around Red Hat. The current Red Hat desktop (5.4) ships with KDE 3.5, while its succesor RHEL 6 will be, if looking what Fedora brings now, shipped with KDE 4.2 or 4.3. That means KDE 4.2/4.3 will be the main desktop for enterprises for at least the next 3 years. A disgrace if you ask me. Users will be comparing desktop environments and they will find Windows 7 or Mac OS X to be better. After the damage RHEL 6 will have done to the reputation of the Linux desktop, it will take again as many years to rectify the damage done. Granted if we will have a solid desktop environment comparable to Windows 7 by the time RHEL 7 gets released. Which I can't help but doubt. My top KDE 4.3 annoyances: * Slo. Logging in takes a multifold of times it did under KDE 3.5, repainting windows takes up a lot of time * The battery status applet is buggy, it only shows the actual percentage after you've hovered it with the mouse, even when you've set it to always display. The scale it uses is also difficult to interpret. These bugs have been reported a long time ago and are still not fixed. * The run dialog is useless. The reason is the history function. It can't display a full history when you start typing, you have to type alot more. Having a pull down menu and using the
Re: [arch-general] We have lost the desktop war. The reason? Windows 7.
Allan McRae wrote: RedShift wrote: This thread will probably erupt in a massive flamewar, yet I decided to post my story anyway. I am talking about the desktop experience in general, not the technical details behind it. Keep that in mind. So you posted in both the forums and here... Seriously, get a blog. Yes I did, because I feel the more technical people roam the mailinglists and the more casual user the forums. I want to hear all the sides. Glenn
Re: [arch-general] We have lost the desktop war. The reason? Windows 7.
Jozsef wrote: I guess you are right about everything. As a desktop Windows is better than KDE. If desktop is all that is matter for you then you should go for it :) By the way Alt+F2 is something I like in KDE4.3.2 for example. What about you? Is there anything you like in KDE4.3? I think it's always good to see things you like and to try to be positive even if KDE4.3 sucks. Of course there are things I like about KDE 4.3. A few examples: * The desktop effects are integrated into the window manager. No more messing around with compiz * When those effects are enabled, you do have cool things like a window preview when hovering the taskbar. This is what I miss most * You can fetch external themes, backgrounds, color schemes, etc... directly from within the applets that are responsible for those settings. No more searching around the web for nice themes, no more installing in obscure locations, it's now all done for you * I really like the concept plasma brings to the desktop * The KDE team has provided measures to turn back the clock (classic start menu, classic desktop) * Lots of KDE software runs under windows. This brings kate, my favorite editor, to the windows desktop * KDE still has better abstraction of file locations than windows or gnome However, for me, the negatives unfortunatly outweigh the positives. For the most part, because they don't really enhance my productivity. Glenn
Re: [arch-general] We have lost the desktop war. The reason? Windows 7.
Stefan Erik Wilkens wrote: A general rule in life is that nothing is ever free. Perhaps a bold remark to use in an open-source mailing list, but cost doesn't have to be defined by money. We simply pay for using Linux by coping with slightly lower performance in some (certainly not all) areas of the desktop experience, furthermore by dealing with a lack of certain features and compatabillity with the rest of the world (office and other indistry standard applications not being available to us, the open source counterparts not being up to par with the standard due to closed-source or licencing). I haven't thought about the money aspect and yes this world does revolve around you get what you pay for. Though I see this in a different light, just because we chose to be Free, we have to settle for less? Though we try to stay on par, I think determining that we have lost implies that we must outperform other operating systems in every way to be considered a real alternative. This point has come up in the forums as well. Don't we want linux/Free software to succeed in all facets of computing? Certainly because the desktop is a big chunk. KDE 4.x is in active developement, GNOME is renewing the desktop experience (albeit slowly). Things are moving along in the open source desktop world. Thankfully, linux != just desktop Yes and KDE 4 has made huge improvements over the releases. But my peers do feel similar and the most common response is, how can the community be so unresponsible for doing flawed releases? However, for me, the negatives unfortunatly outweigh the positives. For the most part, because they don't really enhance my productivity Behind != different? I don't consider being behind as being different Glenn
Re: [arch-general] We have lost the desktop war. The reason? Windows 7.
Rafa Griman wrote: (note, lots of things cut) I've been working these past few months with KDE 4.3 and it feels very sluggish and incomplete. I can't enable the desktop effects because that makes things even slower. I'm doing this on a fairly decent setup, an AMD Sempron 2 Ghz with an nVidia FX5500. I've got a Dell Latitude D610 with an Intel VGA: $ lspci | grep -i vga 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) 1 GB RAM $ cat /proc/cpuinfo model name : Intel(R) Pentium(R) M processor 1.86GHz Using KMS for my Intel VGA. I've got to say I've got a very snappy KDE running. Doesn't feel slow, response is immediate, ... I have about the same setup running here (Intel 915 VGA and a Pentium M processor), yet it distinctively feels slow compared to for example Windows XP or KDE 3.5. My guess is that there's something wrongly configured or installed in your KDE 4 installation. Check this: - deactivate nepomuk and Akonadi - delete /tmp/k* /var/tmp/k* - delete your .kde4 and .kde and .local dirs (you can also choose creating a new account and see if it's faster) Already did those. Doesn't help. So basically, where are we at? KDE 3.5 is Windows XP KDE 4.3 is Windows Vista ??? is Windows 7 When are we getting to the Windows 7 stage? KDE 4.5? ;) I hope so. Maybe I should have waited with my response and give KDE 4 project more time to mature, but there's also chance I would be writing this same e-mail two years in the future. Microsoft didn't do a big advertising campaign for the launch of Windows 7, nevertheless they delivered a big slap in the face to the Linux desktop environments. The numbers speak for themselves, Windows 7 has already sold more copies in its first week than Windows Vista did in its first month. And with good riddance, Windows 7 really is better than Windows Vista. Microsoft recognized the problems with Windows Vista and dealt with them. And dealt with them swiftly if you ask me, doing it in less then 3 years. MS _DOES_ have some help from IHVs ;) Those IHVs preinstall Windows on their laptops, netbooks, ... + MS also has some very deep pockets (filled with $) to convince those IHVs to preinstall MS-Windows. Not only that, their deep pockets help them talk with polititians (at least here in Spain that helps a lot ;) That is true, but even that's not unlimited. Look at windows vista. Most OEMs still ship XP upgrades with business desktops. Though that'll rapidly diminish now that 7 is out. Conclusion We are losing ground. We are losing it fast. Our competitors recognize what the user wants and delivered. This reminds me of a time (long ago) when MS prooved that Win2k was faster serving files that Linux+Samba. While the FLOSS Community was shouting and arguing whether the benchmark was well done, Mr. Torvalds said that was good news since now we would know where we have to apply fixes and what fixes would have to be applied. I think this situation is similar. Than it is a good thing that I spoke up. I am worried about the future of Linux. * Double clicking the system icon in the titlebar doesn't always work to close an application (the system icon is the left-most icon in the titlebar). This bug has also been reported a long time ago and still not fixed. Never tried that, TBH, always use the X on the far right. Partially agreed, however, my reasoning here is don't provide features that don't work. * I get a full 10 minutes of extra runtime on my laptop when I switched back to 3.5 Not here. On the forums the response was, well duh. That being due to the fact that KDE 4 makes more intensive use of the graphics card, which I can understand. But I would have expected by optimizing hardware usage, the system would be faster as well, which is not the case. Glenn
Re: [arch-general] let's discuss /srv again
Sergej Pupykin wrote: Hi, I want to discuss using /srv directory in packages (For reference: http://bugs.archlinux.org/task/16410) Of course I can easy sed and rebuild all my web packages, but I want to know reason why we disable /srv in packages? (Did I skip something?) **cut** /srv and /home are different cases /home often network or --bind mounted. for example I use 4 chrooted environment to build packages with single /home (mounted with --bind key) Most of distros I know (for example suse, alt, debian) use /srv (or /var/www) in packages. (I can not remember distro which disable it) **cut** I do not want to split packages into /etc, /usr/share and /var folders with kludge symlinking. Would it be good if I replace /srv/http with /var/www/package or something like this? If packages start putting stuff in /srv as well, where are we supposed to put OUR data? You don't want to put your data where packages put data as well. Glenn
[arch-general] Request for hpacucli output from people running HP Smart Array controllers
Hello all I'm gathering the output of the hpacucli program from as much configurations as possible. If you can find some free time for me, can you send me the output of: hpacucli ctrl all show detail hpacucli ctrl slot=1 show config hpacucli ctrl slot=1 array all show hpacucli ctrl slot=1 array A show hpacucli ctrl slot=1 physicaldrive all show hpacucli ctrl slot=1 physicaldrive 2I:1:1 show hpacucli ctrl slot=1 logicaldrive all show hpacucli ctrl slot=1 logicaldrive 1 show Replace the slot=, array, physicaldrive and logicaldrive entries with what matches your specific setups (if possible, for all slots, arrays, physical and logical drives). I need as much as possible, normal working configurations and exotic setups like failed drives, arrays in rebuilding or failed state, hot-spares, etc... Much appreciated! Thanks, Best regards, Glenn
Re: [arch-general] Howto adjust font scaling in Arch? All fonts look a bit big and fat?
David C. Rankin wrote: Listmates, I'm looking for a way to adjust the font size scaling (no not the control center font size) so all the fonts in my kde4 desktop look right. Basically, in Arch kde4 on my laptop, all fonts look 1pt too big. Case in point, on suse, I have all my desktop fonts set to 9pt, but with Arch, I have the size set at 8pt and they still look bigger than the suse fonts (same fonts of course, same subpixel hinting setting, etc...). Is there somewhere that some type of scaling is done that I can tweak to try and fix this? The effect of the larger scaling makes everthing from the kmail message list to the basket notepad fonts look cramped. Any thoughts? This thread is useless without pics... Glenn
Re: [arch-general] introducing kernel26-lts
Andreas Radke wrote: Today I've added a 2nd kernel to our svn called kernel26-lts. It should help to make you less caring about kernel updates. The intention is to 1) have a 2nd choice for the kernel pkg that suits better in certain situations and 2) it can be a fallback when a reboot after updating the core kernel26 fails Having a stable unpatched kernel is definately a Good Thing. The constant kernel changes and the associated lava-pants was getting a real nuisance on my Arch servers. I wouldn't bother including Xen though, IMO it's on its last legs since Red Hat took KVM under their wings. KVM is definately the way to go. Glenn
Re: [arch-general] The vsftpd only starts at the second attempt
Lucas Salies Brum wrote: (r...@abraham ~):# ps -A | grep vsftpd (r...@abraham ~):# /etc/rc.d/vsftpd start :: Starting vsftpd FTP Daemon [FAIL] (r...@abraham ~):# /etc/rc.d/vsftpd stop :: Stopping vsftpd FTP Daemon [DONE] (r...@abraham ~):# /etc/rc.d/vsftpd start :: Starting vsftpd FTP Daemon [DONE] (r...@abraham ~):# ps -A | grep vsftpd 6453 pts/300:00:00 vsftpd This has happened to someone? /etc/vsftpd.conf - http://paste.archlinux-br.org/1241 /etc/rc.conf - http://paste.archlinux-br.org/1242 Arch Linux i686. Thanks. --- Lucas Saliés Brum http://sistematico.org lsbrum @ irc.freenode.org Not having this problem with the default vsftpd.conf. Instead of starting it via the initscripts, can you start vsftpd manually? Does it fail as well? Can you try strace the process? Glenn
Re: [arch-general] Bind 9.6.1-1 patched against dynamic update ddos?
Fredrik Eriksson wrote: Hi, I've seen that there's a dynamic update ddos attack that is widely available on the net and after looking for the solution it seems that bind's latest patch (9.6.1-P1) solves this problem. So my question is more like this, is extra/bind 9.6.1-1 in the repository the same as bind 9.6.1-P1? The build date of the current package in extra/ says the 18 July but the homepage of BIND says the latest patch was published the 28 July. Best regards Fredrik Eriksson According to a commenter on the slashdot news article about this issue, this should provide a temporary countermeasure: iptables -A INPUT -p udp --dport 53 -j DROP -m u32 --u32 '30270xF=5' haven't tested it myself though... Glenn
[arch-general] PCI modems
Hi all, I'm currently searching for a PCI modem that will be used to receive faxes. I've tried out a few modems but they all use conexant chipsets, which need out-of-tree kernel drivers and currently doesn't work here (kernel oops when the installation script modprobes the driver). Does anyone know of a PCI modem that works out of the box with in-tree kernel drivers? Thanks, Glenn
Re: [arch-general] PCI modems
Gerardo Exequiel Pozzi wrote: RedShift wrote: Hi all, I'm currently searching for a PCI modem that will be used to receive faxes. I've tried out a few modems but they all use conexant chipsets, which need out-of-tree kernel drivers and currently doesn't work here (kernel oops when the installation script modprobes the driver). Does anyone know of a PCI modem that works out of the box with in-tree kernel drivers? Thanks, Glenn Hi Any PCI _real_ modem (not soft/win modem) will work without any special driver, just the driver for serial ports. No need to fight with special drivers ;) Modems like US Robbotics 0727 is ideal. The only problem maybe is find where to buy today. Search for 0727 modem in ebay: http://preview.tinyurl.com/l7d9xj Good Luck! Hi, I don't think using second hand modems is a good idea, I really need something I can buy in a store... Thanks, Glenn
Re: [arch-general] Kompare
richard terry wrote: Still using kde3 and don't seem to have kompare on my disk. Not in the Archlinux or AUR packages, can one still get a kde3 package for arch? Regards Richard [gl...@polaris ~]$ pacman -Qo /opt/kde/bin/kompare /opt/kde/bin/kompare is owned by kdemod3-kdesdk-kompare 3.5.10-1 See http://kdemod.ath.cx/ for kde 3.5 packages. Glenn
Re: [arch-general] Light-weight SMTP server
Magnus Therning wrote: Any good suggestions for a light-weight SMTP server? All email goes off-box to my ISP for remote delivery, I don't require any local delivery. Things like exim/sendmail/postfix feels like overkill. It would even be enough if all that's available is something like an /usr/lib/sendmail executable. Is there something suitable and light-weight? /M I'd use postfix. Use this basic main.cf for sending only: queue_directory = /var/spool/postfix command_directory = /usr/sbin daemon_directory = /usr/lib/postfix myhostname = CHANGE.THIS.TO.SOME.RESOLVABLE.FQDN mynetworks_style = host home_mailbox = Maildir/ alias_database = $alias_maps alias_maps = hash:/etc/postfix/aliases # relayhost = [my.relay.host] Comment out relayhost if you want to relay your e-mail via another server (for example your ISP's SMTP server). Glenn
Re: [arch-general] Fix or not fix? install scriptlets with user handling.
Gerardo Exequiel Pozzi wrote: Hi, Many package manage user/groups in many differents ways. (no much problem here) Many do things like: @ when installed 1) check if not user foo exists then create it 2) check if not group foo exists then create it @when removed 1) remove the user foo (without check) 2) remove the group foo (without check) Because by default the option USERGROUPS_ENAB is set to yes, when user foo is removed also the group foo is removed, so the groupdel command will fail, then pacman show the message: error: scriptlet failed to execute correctly. The solution is trivial, check with getent before remove, just like some packages do it before create the user. My question here, is there interest in resolving this? Currently I have the choice of those who fail (both extra and comunity). Do you send a report to everyone who fail to flyspray with the patch (low priority)? Also I can unify the user creation step, some .install check with grep and others with getent. I prefer the proper getent method. The only package in [core] that have this issue is dbus-core [#1] and is actually reported. [#1] http://bugs.archlinux.org/task/14810 Hi IMNSHO .install scripts should never ever add users or groups, let alone remove them. Everything that would need a user for itself should default to nobody. Yes, this imposes, though small, a security risk but any decent server admin will move that stuff to its own user. I've even seen packages that start and stop daemons themselves (shrug!), if it were up to me there would be no such things. But many believe that automatically adding and removing users is OK. A package should install its program files, and THAT'S IT. Nothing more. It may be a bit a spartan way, but it's reliable (no unexpected surprises) and leads to an uncluttered passwd and group file. Glenn
Re: [arch-general] The ultimate Home Theater / media center computer
Marq Schneider wrote: * Motherboard: Asus P5N7A-VM http://www.asus.com/product.aspx?P_ID=8YiUFvK51IergAqYtemplete=2 + Powerful on-board graphics (nVidia 9300) + Supports 16 GB of RAM + eSATA port + Optical audio output + HDMI, DVI and VGA video output + Gigabit ethernet + Solid caps - nVidia on-board graphics (requiring proprietary driver) - On-board graphics use system memory - Crappy realtek audio codec As i mentioned, i use this motherboard in my HTPC. Works nice, but i'm afraid the heat dissipation from the nvidia chipset is a bit much for a fanless solution. If you are still considering this motherboard and want some numbers, i can turn off the fans and measure the case temperature to give you a ballpark figure. Could you provide us those figures? If the nVidia chipset gets too hot, I'd try the intel board (the DG45FC discussed earlier). If it still gets too hot, we'll probably have to start looking at VIA solutions. But I'm affraid those will be underpowered and I have bad experiences with VIA grahpics chipsets and linux. Thanks, Glenn
Re: [arch-general] The ultimate Home Theater / media center computer
Christopher Daley wrote: That board doesn't seem to have a PCI/PCI-E slots, so you'd have to splurge on a USB tv tuner card. But you could probably shove that motherboard into anything. It has an x1 PCI-express slot. The on-board graphics is an Intel X4500HD, how good is Linux support on this in the multimedia field? The article says it has hardware accelerated MPEG2, AVC and VC1, does Xorg make use of this? The board definitely looks like a good candidate to me, it will probably use less power than the Asus board I was looking at. It has a bigger brother too, the DG45ID (http://www.intel.com/products/desktop/motherboards/DG45ID/DG45ID-overview.htm) which has more expansion slots and supports more memory. Glenn On Mon, May 4, 2009 at 8:07 AM, Roberto Malinverni roberto.malinve...@dico.coop.it wrote: -Messaggio originale- Message: 2 Date: Sun, 03 May 2009 21:33:14 +0200 From: RedShift redsh...@pandora.be Subject: [arch-general] The ultimate Home Theater / media center computer To: General Discusson about Arch Linux arch-general@archlinux.org Message-ID: 49fdf17a.8040...@pandora.be Content-Type: text/plain; charset=ISO-8859-1; format=flowed * Motherboard: Asus P5N7A-VM http://www.asus.com/product.aspx?P_ID=8YiUFvK51IergAqYtemplete=2 + Powerful on-board graphics (nVidia 9300) + Supports 16 GB of RAM + eSATA port + Optical audio output + HDMI, DVI and VGA video output + Gigabit ethernet + Solid caps - nVidia on-board graphics (requiring proprietary driver) - On-board graphics use system memory - Crappy realtek audio codec I just stumbled upon this: http://hometheatrepcguide.com/mini-itx-motherboard-and-case-how-small-can-a- htpc-get/http://hometheatrepcguide.com/mini-itx-motherboard-and-case-how-small-can-a-%0Ahtpc-get/ Roberto
[arch-general] The ultimate Home Theater / media center computer
Hi list Somehow I got it into my head that I want a home theater PC. I'm growing tired of having to watch television and movies on my computer's 17 LCD screen. At the shop I used to work at, once in a while we'd build a media center computer, but the concept never really took off here (Belgium). There are many reasons for that, such as: * Television is major suckage here (thanks to That Big Company and Government-Not-Governing). The entire country is split into very small regions where broadcast frequencies differ, there's no unified TV guide system, not all regions can receive all channels. Digital television is even worse: That Big Company forces you to buy one of their proprietary decoders. The only way to receive digital television without restrictions is DVB-T with a very limited number of channels (basically nothing). * At that time, the hardware sucked (noisy, too big, not stylish enough to put it along your other hi-fi components, not powerful enough, limited digital outputs, etc...). The software wasn't much better (too complicated, took a long time to start, etc...). Anyway, my goal is to build the *ULTIMATE* HTPC. As such, strong demands must be met: The hardware: * It should be stylish, a timeless look which fits with your other hi-fi components. * It must be entirely silent. Zero moving components. No exceptions. * Unrestricted fully digital outputs. * Must be able to play at least 720p MKV's using x264 encoded video. * Easy remote control. No remote controls with more buttons than there are stars in the sky and certainly no dual function buttons (those functions in a different color which you need to flick a switch or are context dependent). * Able to receive DVB-C. The software: * There is no room for Digital Rights Management fascism. All content must play flawless and in the highest quality possible. In some cases this will mean circumventing protections. That'll probably make the device illegal in some countries, but I don't care. * Easy user interface (also see hardware remote control point). * Can connect to NAS or other storage devices such as USB sticks. In total: * Must be a complete replacement for your DVD player and other media devices. The goal here is keeping the number of remote controls down. Ideally you should only have two: one for controlling your HTPC and one for your hi-fi set. * It is geared towards modern television, that means stuff like HDTV and no legacy connector stuff (like composite). With those goals set, I started looking for hardware. Here's what I've come up with: * Case: Silverstone LC19 http://www.silverstonetek.com/products/p_spec.php?pno=lc19area=usa + Fanless PSU. + Casefans can be removed + Comes with PCI-e and PCI risercards + Integrated cardreader and slimline optical slot + Available in black and silver + Accommodates standard ATX I/O shield + Room for a 3.5 storage device (SSD?) + Vents right above the CPU + Slim - Fits only small motherboard sizes - Only 120 watt PSU - No infrared receiver, no remote control * Motherboard: Asus P5N7A-VM http://www.asus.com/product.aspx?P_ID=8YiUFvK51IergAqYtemplete=2 + Powerful on-board graphics (nVidia 9300) + Supports 16 GB of RAM + eSATA port + Optical audio output + HDMI, DVI and VGA video output + Gigabit ethernet + Solid caps - nVidia on-board graphics (requiring proprietary driver) - On-board graphics use system memory - Crappy realtek audio codec * DVB-C receiver: ? I have zero experience with DVB-C receivers for computers. I've come across the DVBWorldDTV Cable (http://www.worlddvb.com/product/htm/pcic.htm) which seems to provide what I'm looking for. Anyone know how good this hardware actually is and how well it's supported by linux? I have an old hauppauge PVR-350 card which works well, unfortunately hauppauge doesn't seem to have DVB-C products. * Remote control: ? I want to have something simple here. Maybe a small USB infrared receiver and a simple remote control with buttons up, down, left, right, enter? Anyone know if such hardware exists? * Processor: Intel Celeron? No idea how much processing power would be required for a decent HTPC. Preferably as low powered as possible, as the CPU will have to be passively cooled. * Processor cooling: ? I was thinking of a big block with small fins which you see a lot in 1U rackservers. Copper would be the logical choice but from what I've read, aluminum allows for better heat transfer to the environment. So a copper base with alu fins would be ideal. * Storage: ? For storing the operating system I was thinking of those IDE compact flash cards. Downside is that they are very slow. An SSD can be considered but I want to leave the option open to use the 3.5 bay for a hard drive for people that don't have the luxury of a NAS or don't want to leave a NAS running all times. Moving along. The most annoying aspect: software. Obviously we want all our software to be open source. A shortlist
Re: [arch-general] [Fwd: [arch-announce] Dropping i686 support]
Thomas Bohn wrote: On Wed, April 1, 2009 10:09, Dieter Plaetinck wrote: This was posted in march. And it's discussed on the developer mailing list and voted for. Personally I also agree they made a good choice. Okay, what is the alternative? Especially if you don't want end up with Debian-based distributions? Thomas Let's make things frugal! http://www.frugalware.org/. There's also a product called windows on the market, they say it's good and it should run lots of software. You have to turn in a part of your brain to use it though.
Re: [arch-general] [Fwd: [arch-announce] Dropping i686 support]
Rafa Grimán wrote: For x86 based models, I guess we'll have to switch for the time being to another distro, which IMHO isn't too much of an issue. Sooner or later we'll have to switch over to x86-64 based systems since x86 is used on old hardware: hard to get replacements, doesn't scale, less performance, ... x86_64 is just x86 with more registers with 64 bit address space instead of 32 bit. Architecturally there is not much difference so all the shortcomings of x86 still exist on x86_64. Unfortunately.
Re: [arch-general] (no subject)
Agus Setiawan wrote: -- Regards, Agus Setiawan http://mysetiawan.net Censorship by the governments? Conspiracy theories please. Glenn
[arch-general] Computer blocking due to kernel - userspace incompatibility?
Hello list Is it possible a computer gets stuck (not responding to keyboard, the only way to bring it back alive is a hard reset) because of a incompatibility between the kernel and userspace? The cursor is still flickering though, that is what leads me to believe it's software crash, not a hardware crash. This is the software in question: glibc 2.9-4 kernel-headers 2.6.27.6-2 kernel26 2.6.25.10-1 Thanks, Best regards, Glenn Matthys
Re: [arch-general] pacman bug? (can't replace dir with file)
Aaron Griffin wrote: On Mon, Mar 23, 2009 at 1:30 PM, Jan de Groot j...@jgc.homeip.net wrote: On Mon, 2009-03-23 at 19:08 +0100, Damjan Georgievski wrote: error: failed to prepare transaction (conflicting files) test: /test exists in filesystem I think it has to do something with this: [...@server ~]$ pacman -Qo /usr/share/vte error: cannot determine ownership of a directory The point with directories is that there's no real ownership, as lots of packages can store files in such a location. Now, what would have happened if your directory on the filesystem contained files not belonging to the package that is upgraded? True, but pacman should probably check to see if the dir is empty, and replace it if it is. That seems like something dangerous to do, what if package A installed for example, /var/lock/mysoftware/ to keep locks for multiple purposes, and you install package B, which replaces /var/lock/mysoftware/ with a file called /var/lock/mysoftware (because /var/lock/mysofware/ happens to be empty at that point), causing package A to break. Not only does it give the potential to break software (bad) instead of erroring out (good), it gives inconsistent results across multiple systems. I wonder what would happen in the case of: packageA: /foo/bar normal file packageB: /foo/bar/baz normal file With packageA installed, attempting to install packageB. I'd hope it would error out somehow
Re: [arch-general] OpenOffice.org on Acer Aspire One
solsTiCe d'Hiver wrote: I'm trying to use OpenOffice.org on my Acer Aspire One. OpenOffice.org is known to behave badly on Acer hardware. bad luck for you. try it on another hardware. Lol? @op: try install the bitstream TTF fonts. Glenn
Re: [arch-general] [arch-dev-public] mailman hiccup
Geoffroy Carrier wrote: On Tue, Jan 20, 2009 at 09:10, RedShift redsh...@pandora.be wrote: I've been working on my own mailing list manager, it's completely written in PHP and uses SQL as a backend, but at this point a bit specific to our setup. Because our company is all about open source I intend on releasing it as such. It's in need of an overhaul anyway, I'll get hacking at it again ASAP. I'd love to be an early adopter :) Plus I'd be happy to contribute... Ok so here's what I've got so far: When I was designing my anti-SPAM filter, I noticed you're just running a series of code after each other. To keep everything nice and tidy I split up the various routines into small pieces of code designed to do one thing and then pass on to the next filter. My project has the codename redsky. Yes, it's cliché but I couldn't think of anything else. By itself, redsky is pretty useless. It's only capable of running a series of filters after each other. The real power is in the filters itself. The 3 filters that come shipped with redsky are designed to interface with another piece of software called proxsmtpd (but can be used in other ways as well, they just use STDIN and STDOUT), but there's no reasons you could write your own input/output filters and make redsky a mini-SMTP server. Here are the packages that are of interest: * phpemailtoolbox (http://aur.archlinux.org/packages.php?ID=22237) This is a small set of email related functions and classes. It is required by redsky. * redsky (http://aur.archlinux.org/packages.php?ID=22261) This is the main redsky code. It contains three filters: * redsky_read: this reads the email in question from STDIN. It is designed for interfacing with proxsmtpd, but can be used in a generic manner as well. * redsky_discard: when the discard flag is set on an email, this filter will log this event. * redsky_out: this outputs the email to STDOUT, again designed to interface with proxsmtpd but is suitable for general purpose as well. In the mailinglist * redsky-filters (http://aur.archlinux.org/packages.php?ID=24393) This is a set of complementary filters for redsky, it has for example SMTP blacklist checking, whitelisting, autoreplies, etc... They are mainly designed to use in a postfix content scanner context. Only the redsky_sqlconn filter is required for mailinglist manager. * mlm-filters (http://aur.archlinux.org/packages.php?ID=24399) This is the most interesting set of filters. Mlm stands for Mailing List Manager. There's a queueing part and a sending part. For the queueing part: * mlm_getinfo: Fetch information for a certain list using SQL * mlm_loopdetect: Check if a message is looping or not * mlm_bouncehandler: If the message received was sent to a bounce address, store it in an SQL table * mlm_getsubscribers: Get the subscribers from SQL for the current list * mlm_access: Determine if a sender has access to the list. It currently supports 4 methods: use an ACL, only allow subscribers, require a passphrase or no limitations * mlm_subjecttag: Tag the subject if the mailinglist is configured for that * mlm_addfooter: Add a footer to the emails if the mailinglist is configured for that * mlm_queuer: Write a spoolfile and put all the recipients into an SQL table For the sending part: * mlm_singleinstance: Only allow a single instance of redsky to be run * mlm_queuebuilder: Build a queue of messages to be sent and their respective recipients * mlm_queuerunner: Process the earlier built queue using sendmail to send messages redsky is written to support multiple configurations. In the MLM case, you would have two configuration files (examples are shipped with mlm-filters), one for the queuer and one for the sender. The queuer would be called by the MTA while to sender could be executing with a cronjob. Use -c to supply an alternate config, for example: redsky -c /etc/redsky.queuerunner.config.php You will notice that the redsky-filters and mlm-filters come shipped with example configuration files. You will find them in /usr/share/php/redsky/. Some filters depend on each other, so it is important in which order they are executed. For example, the mlm_access cannot determine if the sender is a subscriber when mlm_getsubscribers hasn't run first, because it uses the information from mlm_getsubscribers for this. Now maybe the hardest part, integration with an email server. I'll only handle postfix. Our entire infrastructure is based on MySQL, however all redsky code is written to use PDO, so it should be compatible with any databaseserver that PDO supports. You can get our database schema from http://projects.webmind.be/redsky/mail.sql In postfix terms, you would add entries to your alias table to send certain addresses to the mlm. The examples below are made to work with the database schema above, but all queries can be modified in the configuration files. virtual_alias_maps = mysql:/etc/postfix/mysql/lists.cf
Re: [arch-general] arch way for ip aliasing
Adam Stokes wrote: Does one exist or are we still putting them in rc.local? Thanks Use your brains next time, it took me exactly 1 second to come up with this. In rc.conf: eth0=eth0 192.168.1.5 netmask 255.255.255.0 broadcast 192.168.0.255 eth0_1=eth0:1 192.168.0.5 netmask 255.255.255.0 broadcast 192.168.0.255 INTERFACES=(eth0 eth0_1) Glenn
Re: [arch-general] [PATCHES] About /var/run/ and /var/lock/ checks in daemons
Gerardo Exequiel Pozzi wrote: Hi people! I interested to make Arch Linux suitable for use with a /var/run and /var/lock that are mounted as tmpfs. But this also helps, in the case that not mounted as tmpfs, to make more simple purge function for these directories at rc.sysinit step. In my case this is just for fun!, but other users can be benefited by this, for example netbook users. OK, i initially created rc-script patches for the packages in the extra repo that use /var/run/program-name-directory and fails if not exists. (these list was obtained with for x in $(find /usr/share/pkgtools/lists -type f); do egrep -l var/run/.+ $x;done @@NOTE@@: I will send the patches to the FL individualy per package now, reference to this email in FL, and then copy the links to response in this email. ;) Please review it, thanks in advance. :) What exactly are the advantages of running /var/run and /var/lock on tmpfs? Glenn
Re: [arch-general] HTML email will be rejected
Aaron Griffin wrote: Hello all, I am writing to inform you that I have changed all the Arch lists to reject HTML formatted email. Please send messages in plain text only. Note: This is true of all lists, but I am only sending this message to the higher trafficked lists. Cheers, Aaron Good riddance. When customers of me send me HTML email they can always expect a plaintext reply. Glenn
Re: [arch-general] Moonlight 1.0
Amanai wrote: The final Version from Moonlight 1.0 released on January 20th. Will this be avaible in the Archlinux repo's extra? http://www.go-mono.com/moonlight/ Moonlight is an open source implementation of Microsoft Silverlight for Unix systems. It's avaible for 32/64 bit! Release Notes Final release of Moonlight 1.0 Support for the Microsoft Media Pack Quick and easy installation of media codecs Several media releate bug fixes I hope one of the dev's like to pick this up. Use the force: http://aur.archlinux.org/index.php Glenn
Re: [arch-general] Dovecot imap processes pinning CPU
Hello David Rosenstrauch wrote: In recent days, dovecot's imap processes keep getting stuck. Each time I check my server there's a bunch of imap processes (sometimes 2 of them, sometimes 4, sometimes 6) that are using all of the box's CPU. And worse, there's no way to kill the processes either (neither kill -15 or kill -9 works), which means that I wind up having to reboot the box every time this happens. REALLY irritating. I don't normally even *see* the imap processes in htop, as I think they're pretty short lived. And I'm not sure what they're looping trying to do. My debugging skills on Linux are a bit weak, and so I don't know how to look at the process and see what it's doing. I see quite a few imap (and imap-login) processes hanging around, always have. But they are generally idling, not using 100% CPU like in your case. Also, not sure what's changed on my system to cause this, as this is definitely a recent problem. Maybe the upgrade to Thunderbird 2.0.0.18 (since I usually use T'Bird to access my email). I don't seem to run into this problem when I use Squirrelmail. Interesting. If this really is a fault then a bugreport must be sent to the dovecot developper with high priority (as this could lead to a DoS attack) and to the mozilla team indicating something's wrong with how they talk to certain IMAP servers. Anyone have any idea what the problem might be? Or, if not, then suggestions on how I might be able to debug the situation myself? Start here: http://www.dovecot.org/bugreport.html Glenn
Re: [arch-general] Kernel PKGBUILD proposition: Ease custom kernel compilation.
Nicolas Bigaouette wrote:
Hi all!
* lots of text here *
Whoah, that PKGBUILD is HUGE. Take a look at mine, which I use for my custom
configs. It doesn't do one thing though, and that's install the kernel headers.
You need those if you want to compile out-of-tree modules like nvidia. I'm not
sure if it's 100% OK because I haven't used it in a long time, but the logic I
like to follow is there.
Glenn
pkgname=linux
pkgver=2.6.28
pkgrel=1
pkgdesc='Linux is a clone of the operating system Unix'
arch=(
'i686'
)
url='http://www.kernel.org/'
license=GPL
depends=(
'coreutils'
'mkinitcpio'
'module-init-tools'
)
makedepends=('gcc')
backup=(etc/mkinitcpio.d/$pkgname.preset)
install=linux.install
source=(
http://www.kernel.org/pub/linux/kernel/v2.6/testing/$pkgname-$pkgver.tar.bz2;
config-$pkgver.i686
'linux.preset'
)
build() {
# Apply configuration
cat config-$pkgver.$CARCH $startdir/src/$pkgname-$pkgver/.config
# cd to the kernel build directory
cd $startdir/src/$pkgname-$pkgver/
# Process the configuration to get CONFIG_LOCALVERSION
. ./.config
# Make necessary directories
mkdir -p $startdir/pkg/boot
mkdir -p $startdir/pkg/etc/mkinitcpio.d
mkdir -p
$startdir/pkg/usr/src/${pkgname}-${pkgver}${CONFIG_LOCALVERSION}/
# Make the boot image and kernel modules
make vmlinux bzImage
make modules
# Install boot image and kernel modules
make INSTALL_MOD_PATH=$startdir/pkg modules_install
if [ $CARCH = x86_64 ]; then
cp $startdir/src/$pkgname-$pkgver/arch/x86_64/boot/bzImage
$startdir/pkg/boot/linux
else
cp $startdir/src/$pkgname-$pkgver/arch/i386/boot/bzImage
$startdir/pkg/boot/linux
fi
# Setup mkinitcpio
echo ALL_kver='${pkgver}${CONFIG_LOCALVERSION}'
$startdir/pkg/etc/mkinitcpio.d/$pkgname.kver
install -m664 -D $startdir/src/$pkgname.preset
$startdir/pkg/etc/mkinitcpio.d/$pkgname.preset
}
Re: [arch-general] Welcome Geoffroy Carrier!
Geoffroy Carrier wrote: Many thanks to all of you. On Fri, Dec 5, 2008 at 18:12, Thayer Williams [EMAIL PROTECTED] wrote: Welcome aboard, Geoffroy! Is it pronounced JEFF-roy, jeff-ROY or neither? On this particular concern, let me give you a few of my nicknames to avoid you this issue: - Google or Linux (seems irrevelant here) - Chewbacca/Chewy - Mr Muscle or Bucheron (woodcutter in French) If you still insist on using my name, it's something like Geoffrey, by removing the d sound from the initial dj and replacing ey by wa like in war. Already assigned you your first bugreports. Get hacking ;-). Glenn
Re: [arch-general] [arch-dev-public] Grub2
Ronald van Haren wrote: Hi all, Grub2 is now in my staging dir for both architectures. I'll move it into extra shortly. Things to know: - config file changed to /boot/grub/grub.cfg - config syntax changed a bit - most information can be found on the grub2 archwiki page [1] If you have any experience with grub2 and know your way around, the wiki page still needs some attention for some more special options. The basic stuff should be covered. If you have a more exotic configuration than I have, give it a try. I can't test a lot of use cases myself. Ronald [1] http://wiki.archlinux.org/index.php/GRUB2 What's the deal with grub2 anyway, why is it taking so long for them to make a release? Glenn
Re: [arch-general] remove HWD from extra and wiki!
Pierre Chapuis wrote: Le Wed, 3 Dec 2008 01:10:34 +0100, Pierre Schmitz [EMAIL PROTECTED] a écrit : Well, it does not produce working xorg.conf files. However: X -configure should be prefered; so there is no need for hwd (anymore). It doesn't provide working xorg.conf files only since xorg 1.5 was moved to extra. That was less than 5 days ago... I believe it will be updated to take the changes into account. To me, hwd is a very useful tool, so please don't remove it from extra without a second thought. Well I got to say about this that hwd has never produced a 100% accurate result for me on all kinds of systems. Even my old soundblaster live is wrongly detected as an audigy card. Let alone that I would trust this tool before the official Xorg tools to generate an X config. Glenn
Re: [arch-general] [arch-dev-public] [signoff] device-mapper 1.02.29-1 lvm2 2.02.43-1
Tim Gelter wrote: Thomas Bächler wrote: Dieter Plaetinck schrieb: I'm a user, not a dev, running on i686. I couldn't find a definition of a 'signoff', but I updated abs, built the 2 new packages, they compiled fine, i installed them, rebooted my system and everything came up fine (dm_crypt+lvm based system). I also tested the basic commands (pvdisplay,lvdisplay) and even did an lvextend and resize2fs on a volume. everything still works fine. (didn't try making new/deleting LV/PV's etc though) Does this count as a signoff ? The point of the signoff is not that you can build the package, but that the package provided in the repositories is working. If you can build the package, you still won't know if (for example) one of the executables inside the binary package is corrupted. Other than that, your tests are sufficient. PS: Users cannot send to [EMAIL PROTECTED], so fwiw I cc'd arch-general. Indeed they can't, you can always reply on arch-general if you feel the need to comment on a developer discussion. I believe that all answers to this question have been given so hopefully you don't mind if I hijack this thread... Since we're in the middle of discussing LVM, I've got a request. Not too long ago, I had my root partition / on an LVM physical volume. It was actually pretty easy to set up and worked like a charm until I created a snapshot of one of my other PVs. As soon as I did so, I could no longer boot the system because the dm_snapshot kernel module was not loaded. I was told by several people that I needed to add a hook for it, but never did figure out how to do so. It seems to me that if we are going to support booting from logical volumes, we also need to make sure that users who do so are still able to boot if they decide to take a snapshot of any logical volumes, including booting from a snapshot of /. I'll be glad to help test and even work on the hook if anyone gives me instructions detailing how to do so. Thanks! -Tim Put dm_snapshot in the MODULES array in /etc/mkinitcpio.conf and then rebuild the initial ramdisk using mkinitcpio -p kernel26 (assuming you are using the kernel26 package from core). Glenn
Re: [arch-general] 22 fan site
Jeffrey Lynn Parke Jr. wrote: http://ruger22.com/newpages/newindex.htm You cost me 5 minutes of my productivity, I'm invoicing you for that! ;-) Glenn
Re: [arch-general] [arch-dev-public] pkgstats: first results
Pierre Schmitz wrote: Hi all, I think you all are interested in the result of Allan's crazy idea to get some stats about package usage. I spent some/alot time this weekend to present you some stats. At first: I played a bit with gettext and some usefull pages are available in German and English (depends on your browser's config): * http://www.archlinux.de/?page=ArchitectureDifferences * http://www.archlinux.de/?page=MirrorStatus * http://www.archlinux.de/?page=PackageStatistics (That's the one; be warnded: atm it loads 2MB of pure HTML!) For those who want to play with some sql queries, I have uploaded a (reduced) db-snapshot: http://users.archlinux.de/~pierre/tmp/pkgdb-stripped.sql.gz Before announcing this we should discuss the results and talk about what we learn about them. I'll make a start: (topdown) * extra and community have similar size * more than 1200 submissions since friday. Thanks! :-) * installation size varies from 126 to amazing 2800 * 1/4 use x86_64 * Nearly 70% of packages are from extra. Nice. * Only 7% are installed from community and a similar amount is in no official repo (Might be a sign that there is something wrong with priorities in [community]) * About 2% from extra and 3% from community aren't used by anybody! The unused kde-l10n pacakges are no problem; I create them automatically * Nearly 20% of all users (that includes 3/4 i686) use lib32 packages. * There are lots of rarly used packages in all repos * kdemod-kdelibs is installed by 14,26 % while kdelibs fomr [extra] is installed by 34,05 %. Maybe splitting support in makepkg and devtools should get a higher priority ...that should do it for a start. Just a warning, generalizing based on these numbers (and on any numbers in fact) is very dangerous. Glenn
Re: [arch-general] [arch-dev-public] Election Night
Aaron Hussein Griffin wrote: I'm assuming it will be quiet around here tonight. Many of us will be glued to our TVs/radios/internet waiting for election results. So no one break the server tonight! Allan, I'm looking in your direction :) Obama has won. But the real challenge has yet to come. Glenn
[arch-general] test
test
Re: [arch-general] bftp denyhosts
Sergey Manucharian wrote: On Mon, 13 Oct 2008 17:04:54 + Jon Kristian Nilsen [EMAIL PROTECTED] wrote: Is ther any reason you are using bftp, instead of for example sftp? Actually there is no specific reasons, it was installed 2 years ago, and now services a whole bunch of users with complex chroot directories structure. Maybe I'll replace bftp with something else anyway. The only strange thing for me that I believed that hosts.deny/allow files are system-wide and I can rely on them, but it's not so. Sergey hosts.allow hosts.deny is only effective on programs that implement tcp_wrappers. Glenn
Re: [arch-general] 32-bit glibc package?
David Rosenstrauch wrote: I use Arch x86_64 - so far without a problem. But I've found recently that there's a few AUR packages that I'm unable to compile. (e.g., virtualbox-modules) Seems like the build needs the /usr/include/gnu/stubs-32.h file, which isn't installed on my Arch64 system. (glibc installs stubs-64.h instead.) But according to this thread, it appears that many distros work around this by having a 32-bit glibc package for this purpose: http://gcc.gnu.org/ml/gcc-help/2007-12/msg00055.html Does Arch have such a thing? Didn't look like it from surfing the packages in the repos (and AUR), but thought I'd ask anyway. If not, I'm not opposed to writing a new packages for this, but I'm not sure quite how to build a 32-bit glibc package that doesn't conflict with the 64-bit one. Anyone have any advice here? Thanks, DR Use a 32 bit chroot for 32 bit stuff. Arch doesn't (and hopefully will never ever) support multilib. Glenn
Re: [arch-general] running sybase under arch linux
Scott Weisman wrote: Hello everyone, I've got a big problem I hope someone can help with. I've been a huge fan and user of Arch since early 2004. I really like it and it works great for me. I have several production servers also running it, with no problem whatsoever. However, I have one ancient server running a creaky version of Red Hat Linux that I would love to replace, but can't. This is running Sybase 11.0.3.3, and I simply can't get it working on my replacement server. First of all, for those who are shaking their heads, this is a legacy server dating to 1998. Second, I had nothing to do with the original design. Third, I hate Sybase. Even though a free version has been available for years, it is absolutely hostile to Linux in general. It needs a very specific configuration or it simply won't run. And good luck figuring that out, unless you use one of their supported configurations. My new server is running Arch x86_64. I have no choice about this. I have the old 11.0.3.3 RPMs and extracted them to /opt/sybase. I installed the following packages: local/libstdc++5 3.3.6-2 local/emul32-compat 1.0-3 local/lib-compat 1.4.1-1 No matter what I try though, I get segfaults when trying to run Sybase. Has anyone had any success getting ANY version of Sybase running on Arch? Please let me know if you have, or if you have any suggestions at all! VERY much appreciated. Thanks, Scott You could try copying that whole red hat installation to somewhere else, chroot to it and run programs from there. But pretty good chance that won't work because arch's GCC, kernel, etc... is too new to support that old stuff. An other option would be to do a fresh redhat 9 install or copy the existing redhat installation to somewhere on the new server, and run the install in a virtual machine using qemu, vmware or insert your favorite virtualization software. Make sure you use hardware VT (qemu can make use of the kernel's KVM layer - ideal!). My choice would be copy the entire redhat install and run it in a virtual machine with qemu-kvm. Glenn
Re: [arch-general] [arch-dev-public] Snort UID / GID
Aaron Griffin wrote: On Thu, Jul 17, 2008 at 10:40 AM, Hugo Doria [EMAIL PROTECTED] wrote: Thus this way snort can work out of the box with less privileges. Anyone who wants can put snort to run with another user. And, in any case, this email was just a question. I don't see why people have such an issue with creating UIDs/GIDs out of the box. I don't have a problem with it, as long as we don't do it on every flippin package under the sun. Is it possible to use 'nobody' for snort, or is there a security risk there too? What if I want to run snort under for example security_user. Now I have a cluttered passwd file due to the post-install script. And if I manually remove the snort user, the pre-remove will probably error out too. Glenn
Re: [arch-general] [arch-dev-public] Snort UID / GID
Hugo Doria wrote: On Thu, Jul 17, 2008 at 10:27 AM, RedShift [EMAIL PROTECTED] wrote: Why can't the users themselves create a snort uid/gid... As the snort itself will run with the snort user/group is better create them during the installation. -- Hugo Why is it better to create them during installation? Glenn
Re: [arch-general] [SPAM] [arch-dev-public] two patches for rc.d/network
James Rayner wrote: 1) 0001-add-some-useful-error-messages-to-wireless-code.patch Makes the wireless code in rc.d/network output some useful errors and a tad more robust, rather than failing and giving no useful error at all. Not tested yet, I don't have an insecure or WEP network to try it on, and the family won't be impressed if I start messing with dd-wrt. I'll try tomorrow morning when they're sleeping. 2) 0002-Added-connection-state-info-to-rc.d-network.patch Makes rc.d/network create a file for an interface if it manages to connect. Useful for scripts. Also needs the directory /var/run/network/interfaces/ created in the initscripts PKGBUILD. Scripts should use ifconfig or other networking tools that directly read from the kernel's configuration for network interface information. What if a user manually modifies his configuration without using the initscripts? Or does some advanced networking configuration in rc.local? The information in /var/run/network will not be correct. I'm going to be blunt, it's a stupid idea. Glenn (patches are not dependent) Cheers, James
Re: [arch-general] [arch-dev-public] Multilib on Archlinux x86_64
Thomas Bächler wrote: Andreas Radke schrieb: You must have mixed the mailing lists! Actually, no. Arch64 was founded to never have support for 32bit compatibilty. So move this into the community/AUR list. Yeah, maybe, and I am extending it. I give you a strict -1 for any 32bit compat stuff in our officially supported repos as I already told you in private discussions. I've spent several weeks if not even months to make it as clean as possible. What you are saying is that by adding an extra capability (again, separate repository, nothing to pollute core or extra in any way), we destroy the clean-ness of your so clean (and yeah, it is clean) system. That's just irrational. The fact that you don't quote a single line from my posting tells me that you haven't even read any of my propositions. Why don't you give technical arguments instead of making this personal? The reason I want to maintain this on our ftp is that I want it to be easily accessible to our devs and users, as I can't maintain it alone. The reason I don't want this (at least the core of it) in community is that I want it to be separate from the rest. Besides, unless you want to maintain the packages or use them by activating the repository in pacman.conf, you won't even notice it's there. It would be a reason for me to stepdown here! Now you're just being childish! 100% agree with Andreas, again this is about principles. And I think Andreas has the same principles as me, either you go full x86-64 or you don't. A middle road is messy. If it were up to me the kernel wouldn't even have support for executing 32 bit stuff (right now that option is enabled). Glenn
Re: [arch-general] [arch-dev-public] Multilib on Archlinux x86_64
Thomas Bächler wrote: Andreas Radke schrieb: It's more a question what Arch64 was founded for: to be the bleading edge leading _pure_ 64bit distro around. That's been its goal since the project has started. And I think we did a good job. You may have missed the early discussions when we made decisions that we don't want (though we have could have) multilib compatibility and bi-arch gcc. That was a strict law. It was our way to push the efforts to once get it the same level where the x86 world is. I missed the discussions, maybe. But this is not a discussion we had a few years ago, this is the discussion we are having now. And just saying A few years ago, we wanted it this way is not a good reason. Offering 32bit compat stuff always means to make it easy for users No, not to make it easy, but make it possible. As I said in my reply to Daniel, I need a 64 bit OS, but I also need mixed 32/64 bit environments. but takes much pressure from companies and opensource developers give the x86_64 architecture the time and responsibility it is worth. You can compare it to the question to support closed source stuff or not. We made our decision long ago. So please respect it. We never denied closed source software out of principle. We always made things just work. I want standard applications to just work, without having to bother about which architecture I am on. Now, again, you gave me a list of ideological reasons not to do it, but where exactly is the point where this damages your pure system technically? It's about the technical purity. It's this that makes us different from the other distro's. Otherwise we're just on the road to the next ubuntu. And if you really want 32 bit stuff running on x86-64, just use a 32 bit chroot and don't bother with the multilib stuff. Glenn
Re: [arch-general] /etc/resolv.conf and /etc/resolc.conf.tail
timetrap wrote: Hi, this is my first message to arch-general. I have been helping a user on the forums who needs multiple search domains in his /etc/resolv.conf file. His original question was this: Our DHCP isolates clients to a separate subnet than the servers. As such, unless you fully qualify the server name, you can't find the server. A work around is to put the IP in the hosts file, but there are just too many servers to do that with. Another option is to add the search domain(s) in the to the end of the search line in resolv.conf, however that file is re-written by dhcpcd, so changes are quickly lost. Is there a way to add on search domains to what DHCP hands your system? I have done some research and found that the BSDs have a particularly nice solution to this; /etc/resolv.conf.tail Basically, it does this: #!/bin/bash if [ -f /etc/resolv.conf.tail ]; then cat /etc/resolv.conf.tail /etc/resolv.conf fi I am still new to arch, and I don't know who exactly deals with this portion of the distro. Is this something that can be made standard? It seems like a very simple fix. Very useful too. Here is the forum posting: http://bbs.archlinux.org/viewtopic.php?pid=388345#p388345 --timetrap Something like that is totally unecessairy. That's why we have /etc/conf.d/dhcpcd. Also see man dhcpcd. Glenn
Re: [arch-general] /etc/resolv.conf and /etc/resolc.conf.tail
timetrap wrote: dhcpcd is fine. But this is a patch for dhclient. Which is a totally different dhcp client. When I installed wicd, dhclient was a dependency, if you want to use wicd, you need to use dhclient. If you want to have multiple search domains with dhclient (through wicd), you need to edit your /etc/resolv.conf and append those search domains. Rather than edit by hand, or run an external script. Why not just patch the dhclient-script? So yes, something like this SHOULD be unecessairy. But it isn't. Oops. Didn't notice it was for dhclient. Anyways, dhclient-script is provided by upstream, so either apply your patch everytime the package is upgraded or build your own dhclient package. Glenn
Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.25.10
Thomas Bächler wrote: Just a bump to .10 and a minor configuration change (AOE added). It is built with gcc 4.3.1, so if any binary modules break, please tell me. It may be smart to wait for GCC 4.3.2 to come out, because of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=451068 Glenn
Re: [arch-general] Need to mount 2nd SATA drive
Allie Daneman wrote: I can't figure out how to mount my 2nd SATA drive...my primary disk is mounted by uuid in my current fstab but disk 2 doesn't seem like it's being found correctly. Can anyone help out...how do I figure out the uuid of my 2nd drive ? [EMAIL PROTECTED] etc]# ls -la /dev/disk/by-id/ total 0 drwxr-xr-x 2 root root 0 Jun 28 09:49 . drwxr-xr-x 5 root root 0 Jun 28 09:49 .. lrwxrwxrwx 1 root root 9 Jun 28 09:49 ata-WDC_WD1600AAJS-75PSA0_WD-WMAP98331746 - ../../sda lrwxrwxrwx 1 root root 10 Jun 28 09:49 ata-WDC_WD1600AAJS-75PSA0_WD-WMAP98331746-part1 - ../../sda1 lrwxrwxrwx 1 root root 10 Jun 28 09:49 ata-WDC_WD1600AAJS-75PSA0_WD-WMAP98331746-part2 - ../../sda2 lrwxrwxrwx 1 root root 10 Jun 28 09:49 ata-WDC_WD1600AAJS-75PSA0_WD-WMAP98331746-part3 - ../../sda3 lrwxrwxrwx 1 root root 10 Jun 28 09:49 ata-WDC_WD1600AAJS-75PSA0_WD-WMAP98331746-part4 - ../../sda4 lrwxrwxrwx 1 root root 9 Jun 28 09:49 ata-WDC_WD1600AVJS-63SWA0_WD-WCAP9C579547 - ../../sdb lrwxrwxrwx 1 root root 9 Jun 28 09:49 scsi-SATA_WDC_WD1600AAJS-_WD-WMAP98331746 - ../../sda lrwxrwxrwx 1 root root 10 Jun 28 09:49 scsi-SATA_WDC_WD1600AAJS-_WD-WMAP98331746-part1 - ../../sda1 lrwxrwxrwx 1 root root 10 Jun 28 09:49 scsi-SATA_WDC_WD1600AAJS-_WD-WMAP98331746-part2 - ../../sda2 lrwxrwxrwx 1 root root 10 Jun 28 09:49 scsi-SATA_WDC_WD1600AAJS-_WD-WMAP98331746-part3 - ../../sda3 lrwxrwxrwx 1 root root 10 Jun 28 09:49 scsi-SATA_WDC_WD1600AAJS-_WD-WMAP98331746-part4 - ../../sda4 lrwxrwxrwx 1 root root 9 Jun 28 09:49 scsi-SATA_WDC_WD1600AVJS-_WD-WCAP9C579547 - ../../sdb [EMAIL PROTECTED] ls -la /dev/disk/by-path/ total 0 drwxr-xr-x 2 root root 0 Jun 28 09:49 . drwxr-xr-x 5 root root 0 Jun 28 09:49 .. lrwxrwxrwx 1 root root 9 Jun 28 09:49 pci-:00:1f.1-scsi-1:0:0:0 - ../../sr0 lrwxrwxrwx 1 root root 9 Jun 28 09:49 pci-:00:1f.2-scsi-0:0:0:0 - ../../sda lrwxrwxrwx 1 root root 10 Jun 28 09:49 pci-:00:1f.2-scsi-0:0:0:0-part1 - ../../sda1 lrwxrwxrwx 1 root root 10 Jun 28 09:49 pci-:00:1f.2-scsi-0:0:0:0-part2 - ../../sda2 lrwxrwxrwx 1 root root 10 Jun 28 09:49 pci-:00:1f.2-scsi-0:0:0:0-part3 - ../../sda3 lrwxrwxrwx 1 root root 10 Jun 28 09:49 pci-:00:1f.2-scsi-0:0:0:0-part4 - ../../sda4 lrwxrwxrwx 1 root root 9 Jun 28 09:49 pci-:00:1f.2-scsi-1:0:0:0 - ../../sdb [EMAIL PROTECTED] etc]# ls -la /dev/disk/by-uuid/ total 0 drwxr-xr-x 2 root root 0 Jun 28 09:49 . drwxr-xr-x 5 root root 0 Jun 28 09:49 .. lrwxrwxrwx 1 root root 10 Jun 28 09:49 24898ead-1493-4544-a69b-9aa873df4eb8 - ../../sda4 lrwxrwxrwx 1 root root 10 Jun 28 09:49 944d5302-9d85-422a-8aab-dd38606ee224 - ../../sda2 lrwxrwxrwx 1 root root 10 Jun 28 09:49 b0746ca3-76e3-4428-9898-74d46f638722 - ../../sda1 lrwxrwxrwx 1 root root 10 Jun 28 09:49 d71891a3-aff1-4696-9c43-8ada3f0d4c00 - ../../sda3 Your second disk doesn't have any partitions. Although you can create a filesystem on a whole disk without partitioning, it may be favourable to partition your drive. Use cfdisk to partition your drive. It's registered as sdb. Glenn
Re: [arch-general] apache-/httpd-config files (was: [arch-dev-public] cleaned-up apache package)
Finkregh wrote: On Sun, 22 Jun 2008 00:31:50 +0200 Pierre Schmitz [EMAIL PROTECTED] wrote: Btw: does anybody know why the previous maintainer has used /etc/httpd/conf instead of /etc/httpd? Why is that directory used at all? Doesn't it make more sense to use something like '/etc/apache/' like e.g. lighttpd does? Or is there already a policy on that i overlooked? Actually, apache is not called apache, but is called httpd. It has been called httpd ever since 2.0. (The 2.0 series used apache as name, that's why people generally call httpd apache). The usage of /etc/httpd (with a conf subdirectory below) is because it allows you to set the serverroot to /etc/httpd. That's why there is a log and modules symlink in there. If we didn't do it like that, what whould we set the serverroot to? If you've been using httpd for a long time, then the way it's currently set up makes perfect sense and is the most logical one too (I wouldn't know any better way to set it up). Glenn
Re: [arch-general] [arch-dev-public] adding http user/group to filesystems
Pierre Schmitz wrote: Hi, as mentioned in the apache thread I would like to use a dedicated user/group for our different webserver packages. To achieve this I'd like to add the user/group http to our filesystem package. (It allready contains them for mail and ftp) According to http://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database uid/gid 33 should be free for use. An install script to add those for upgraders have to be added, too. Another approach would be adding an install script creating those groups to the webserver packages. What do you think is best? Pierre Why not just use nobody for programs that need their own user, as a sane default. Any smart admin should create any groups and users himself when necessairy. And prevents cluttering of unnecessairy users/groups. For example in my httpd setups, the http users would never be used. IMO. Glenn
Re: [arch-general] [arch-dev-public] [signoff] filesystem-2008.06-1
Aaron Griffin wrote: On Thu, Jun 19, 2008 at 8:09 AM, RedShift [EMAIL PROTECTED] wrote: Why does this package mess around in /usr/local? IIRC there are no Arch packages that use /usr/local and it's meant for local deviations, so wouldn't it be wise not to touch /usr/local? http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY I stand corrected.
Re: [arch-general] Xen for Arch Linux - Update 1
Hi all, Time for an update! Changelog linux-xen0: * linux-xen is renamed to linux-xen0. This way someone can create a linux-xenU package if he/she wants * 64 bit build * Kernel configurations based on stock Arch Linux kernel as far as is allowed Get the packages at: http://archserver.be/packages-devel/linux-xen0-2.6.18_xen_3.2.0-2-i686.pkg.tar.gz http://archserver.be/packages-devel/linux-xen0-2.6.18_xen_3.2.0-2-x86_64.pkg.tar.gz xen: * 64 bit build * Updated initscripts: the scripts are now in rc.d. - xend: archified - xendomains: Don't touch what you don't know. Script looks pretty complex so other than a changed path I did not modify the script Get the packages at: http://archserver.be/packages-devel/xen-3.2.1-2-i686.pkg.tar.gz http://archserver.be/packages-devel/xen-3.2.1-2-x86_64.pkg.tar.gz You can find the updated PKGBUILDs at: http://archserver.be/packages-devel/linux-xen0.tar http://archserver.be/packages-devel/xen.tar Glenn RedShift wrote: Hi all, I've been keeping busy today with Xen for Arch Linux. I've created the following packages: - This package contains the userland tools to administer a Xen dom0 host. xen-3.2.1-1-i686.pkg http://archserver.be/packages-devel/xen-3.2.1-1-i686.pkg.tar.gz - This package contains the Xen hypervisor/dom0 kernel. linux-xen-2.6.18_xen_3.2.0-1-i686.pkg http://archserver.be/packages-devel/linux-xen-2.6.18_xen_3.2.0-1-i686.pkg.tar.gz As Xen uses a heavily modified linux kernel, it cannot easily be ported to more current kernel versions. So: 1) You're stuck with whatever hardware 2.6.18 supports 2) We have to use GCC 3.4 to compile this 3) It needs a patch because of using GCC 3.4 (xentime-gcc34.patch) :-( The kernel configuration is currently the default one that comes with Xen. Most drivers are compiled in statically. I plan to update the configuration to match Arch Linux's stock kernel. The kernel package does NOT provide support for running AS A paravirtualized* GUEST. The goal of these packages is make the system run guest OS'es without any modifications. This means you need hardware virtualization support. You can check for hardware VT if you have either vmx or svm (respectively Intel's and AMD's virtualization technology) in /proc/cpuinfo. I do not intend to support paravirtualization (see TODO). I've only tested i686. I can natively run m$ windoze (with networking) on these packages, so the basics work. The xen package should compile and work on x86_64. The linux-xen package has not even been compiled on x86_64 and will not work ATM. I've started a wiki article for Xen too, http://wiki.archlinux.org/index.php/Xen You can grab the PKGBUILDs here: * linux-xen: http://archserver.be/packages-devel/linux-xen.tar * xen: http://archserver.be/packages-devel/xen.tar Still TODO: * x86_64 support * update kernel config to match Arch Linux's stock kernel * finish the wiki article, create an example scenario * fix initscripts for xen package (they are currently in etc/init.d) * paravirtualization: from what I've read, the kernel can be configured to function both as hypervisor and guest. The traditional way is to have two kernels in the distro: one for dom0 and one for domU. It would be great to combine these two - but I'd like some advice on this one. Does it have performance implications? - If having both dom0 and domU support in the same kernel has no negative side-effects I will support paravirtualization. If it does have side-effects that are unacceptable I will not support paravirtualization. (Paravirtualization is virtualization without hardware support from the CPU. This means the guest OS has to be made compatible with Xen in order to run. This is why you see for example xenU or domU kernels: these are meant to be used inside a Xen domain if the Xen host doesn't have hardware VT) Any feedback is appreciated. Glenn
Re: [arch-general] top posting
I guess you /don't/ like HTML email as well :-( Xavier wrote: http://www.catb.org/jargon/html/T/top-post.html What about using a consistent style, at least for one given ML? arch-general is really painful to read sometimes. Thanks!
Re: [arch-general] top posting
I guess you don't like HTML email as well :-( Xavier wrote: http://www.catb.org/jargon/html/T/top-post.html What about using a consistent style, at least for one given ML? arch-general is really painful to read sometimes. Thanks!
Re: [arch-general] pacman changes libcrypt.so.1 symlink
Xavier wrote: Lukáš Jirkovský wrote: Hi I don't know if it's bug or feature, but it makes me crazy. It begun probably after some pacman upgrade. I'm using blowfish passwords with my archlinux, so my /lib/libcrypt.so.1 points to libxcrypt.so.1 instead of libcrypt-2.7.so from glibc. In my pacman.conf I have NoExtract = lib/libcrypt.so.1. But even though I've made this arrangements everytime when I run pacman -S some_interesting_package (it doesn't have to be glibc, eg libpng is enough) the link gets changed. Any suggestions? From what I can tell, it's ldconfig who does this (try running it, it should overwrite your symlink). And pacman runs ldconfig when installing packages. Maybe someone can clarify further why ldconfig does this and if it's possible to prevent it. ldconfig makes sure you are using the most recent version of a certain library and provides a cache for the runtime linker. See man 8 ldconfig. Glenn
Re: [arch-general] [arch-dev-public] initscripts changes
Jan de Groot wrote: On Mon, 2008-04-07 at 00:24 +0200, RedShift wrote: Thomas Bächler wrote: RedShift schrieb: Thomas Bächler wrote: I am hacking initscripts and can't quite decide on two issues: 1) I'd like to hardcode /dev/pts/ mounting in rc.sysinit. What's wrong with putting that in fstab? What if I don't want to have that mounted? So instead of modified fstab I'd have to mess with rc.sysinit everytime the initscripts get upgraded? This is the same discussion as with moving lo to rc.sysinit instead of leaving it in rc.conf. Uterly pointless. The point is, everyone needs it mounted. Your system will be completely useless without devpts (as it is without the lo interface). However, I know your opinion on these issues. Are there any rational reasons not to hardcode devpts? Yes. It's not logical. fstab was made for mounting filesystems, why even consider moving it to rc.sysinit? It's not because it makes the system unusable without it, that it should be moved to rc.sysinit. Why the change anyway? What's the benefit? Now we're going to see Heeey stuff's being mounted that's not in fstab? wtf?. This change is just plain irrational, fstab was _specifically made_ for mounting filesystems. If you're going to hardcode stuff like that you might as well throw away fstab. Glenn /proc and /sys are already hardcoded. About your system being broken without these filesystems mounted: - SSH (both server and client) won't work without devpts mounted - None of the virtual X terminal things will work without devpts mounted It doesn't prevent the system from booting and having a working virtual console. So people can fix it if they decided to mess with the default entries in fstab. You guys just don't get it. This is about _principle_. And its not because there already are some filesystems hardcoded, that the rest should be. In fact, these should be moved from hardcoding to fstab. But that will probably never happen. Wether these are virtual or real filesystems, it doesn't matter: the fs in fstab stands for FileSystem, period. If something needs to be mounted, it should go there. This is exactly as what happened with the lo moving to rc.sysinit, hiding stuff so the newbies won't remove it because they think they don't need it. And the fact is, if you remove lo from the system, you can *still* boot your system and most stuff works without lo. So they can still fix lo if they removed it. I'm sick and tired of complaining about issues like these, that shouldn't be discussed in the first place. Do you think I like complaining? Since when do we assume the user is stupid? All that's been accomplished here is create a big mess. One sidenote though: I don't think users will break their system, the /dev/shm and /dev/pts mounts are in fstab during setup and I think most people don't remove them. I haven't seen bugs about hey my system doesn't boot, but when I add these lines to /etc/fstab it works
Re: [arch-general] [arch-dev-public] initscripts changes
Jan de Groot wrote: On Mon, 2008-04-07 at 11:12 +0200, RedShift wrote: I'm sick and tired of complaining about issues like these, that shouldn't be discussed in the first place. Do you think I like complaining? Since when do we assume the user is stupid? All that's been accomplished here is create a big mess. I think these things shouldn't be discussed in public anymore. Your use of language makes me sick. This is the same for that thread aaron opened about the direction archlinux is going, some people personally attacked several devs. Yes, I'm sorry for my language, I can be a bit harsh at times, haven't allowing myself to cool down. But that's no excuse for avoiding this discussion. You may see this as some little change with small importance, but this sets a precedent for Arch Linux in the future. It's now that has to be decided that changes like these are acceptable or not. And the fact that developers attacked other developers personally, isn't that expected? They did create the packages, so if there is something wrong, they are the ones to go to? Glenn
Re: [arch-general] [arch-dev-public] initscripts changes
Thomas Bächler wrote: RedShift schrieb: /proc and /sys are already hardcoded. About your system being broken without these filesystems mounted: - SSH (both server and client) won't work without devpts mounted - None of the virtual X terminal things will work without devpts mounted It doesn't prevent the system from booting and having a working virtual console. So people can fix it if they decided to mess with the default entries in fstab. That's correct. You guys just don't get it. This is about _principle_. YOUR principle. Yes, and guess where I got them from. Arch, 3 years ago. And its not because there already are some filesystems hardcoded, that the rest should be. I'm not talking about the rest, I'm talking about things that are mandatory for basic system operation. It is not mandatory for basic system operation. With basic system operation I mean getting a virtual console working and that's it. You know, the thing the users aren't supposed to be afraid of? Having some working xterm's or whatever in X is not basic system operation. In fact, these should be moved from hardcoding to fstab. But that will probably never happen. You're right, it won't, because it is impossible. If you would care to even read rc.sysinit, you would know why. Yes, there are things that need to be hardcoded because there is no way around them. I have no problem with those. /dev/pts doesn't fall in this exception. Wether these are virtual or real filesystems, it doesn't matter: the fs in fstab stands for FileSystem, period. If something needs to be mounted, it should go there. Says you? Yes. It's logical. This is exactly as what happened with the lo moving to rc.sysinit, hiding stuff so the newbies won't remove it because they think they don't need it. And the fact is, if you remove lo from the system, you can *still* boot your system and most stuff works without lo. So they can still fix lo if they removed it. This is not about hiding things, it is about keeping it simple. What is simple about having to configure something that everybody needs, always needs it and will break everything if it is configured differently? It is unnecessary to even be able to configure it. So simplicity tells me to hardcode it. I'm sick and tired of complaining about issues like these, that shouldn't be discussed in the first place. Do you think I like complaining? Then don't complain, I'm sick of it. These changes do not decrease your flexibility, nor do they break anything. Believe me, I am all against changes that remove control from the user. But this is about things a user doesn't have to control, doesn't even want to control. What I want is a system that is flexible on the one hand, robust and unbreakable on the other hand. The 'lo' change (as well as the devpts change) is about increasing robustness without removing any flexibility. I cannot see how this is not a good thing. *everything* should be in the user's control. That includes things that can shoot him in his own foot. You don't know if there are out there that want to control lo or devpts. Now they'll have to apply a patch every time the initscripts get upgraded. Since when do we assume the user is stupid? All that's been accomplished here is create a big mess. This is rule number one of development, always assume the user is stupid. The result of that is, that I have less emails with complaints to answer, less forum posts to unbreak user's systems, one less bugreport to close. It essentially means that I have more time doing things that actually benefit the Arch community. Yah, that's kind of like exactly the opposite of what Arch stands (stood?) for.
Re: [arch-general] [arch-dev-public] initscripts changes
RedShift wrote: Jan de Groot wrote: On Mon, 2008-04-07 at 00:24 +0200, RedShift wrote: Thomas Bächler wrote: RedShift schrieb: Thomas Bächler wrote: I am hacking initscripts and can't quite decide on two issues: 1) I'd like to hardcode /dev/pts/ mounting in rc.sysinit. What's wrong with putting that in fstab? What if I don't want to have that mounted? So instead of modified fstab I'd have to mess with rc.sysinit everytime the initscripts get upgraded? This is the same discussion as with moving lo to rc.sysinit instead of leaving it in rc.conf. Uterly pointless. The point is, everyone needs it mounted. Your system will be completely useless without devpts (as it is without the lo interface). However, I know your opinion on these issues. Are there any rational reasons not to hardcode devpts? Yes. It's not logical. fstab was made for mounting filesystems, why even consider moving it to rc.sysinit? It's not because it makes the system unusable without it, that it should be moved to rc.sysinit. Why the change anyway? What's the benefit? Now we're going to see Heeey stuff's being mounted that's not in fstab? wtf?. This change is just plain irrational, fstab was _specifically made_ for mounting filesystems. If you're going to hardcode stuff like that you might as well throw away fstab. Glenn /proc and /sys are already hardcoded. About your system being broken without these filesystems mounted: - SSH (both server and client) won't work without devpts mounted - None of the virtual X terminal things will work without devpts mounted It doesn't prevent the system from booting and having a working virtual console. So people can fix it if they decided to mess with the default entries in fstab. You guys just don't get it. This is about _principle_. And its not because there already are some filesystems hardcoded, that the rest should be. In fact, these should be moved from hardcoding to fstab. But that will probably never happen. Wether these are virtual or real filesystems, it doesn't matter: the fs in fstab stands for FileSystem, period. If something needs to be mounted, it should go there. This is exactly as what happened with the lo moving to rc.sysinit, hiding stuff so the newbies won't remove it because they think they don't need it. And the fact is, if you remove lo from the system, you can *still* boot your system and most stuff works without lo. So they can still fix lo if they removed it. I'm sick and tired of complaining about issues like these, that shouldn't be discussed in the first place. Do you think I like complaining? Since when do we assume the user is stupid? All that's been accomplished here is create a big mess. Besides, they can just as well remove it from rc.sysinit. But it's more hidden, and that's what we're going for right? Hide things from the users so they don't mess with it? (Yes, that was sarcasm) One sidenote though: I don't think users will break their system, the /dev/shm and /dev/pts mounts are in fstab during setup and I think most people don't remove them. I haven't seen bugs about hey my system doesn't boot, but when I add these lines to /etc/fstab it works
Re: [arch-general] [arch-dev-public] initscripts changes
There is in fact a valid reason why we should not hardcode devpts and I am thinking of dropping the thought, but none of you even cared to bring it up, instead you bitch about your weird principles, which you claim to be Arch's principles, insulting developers and being an ass on the way. I am following KISS and trying to make things simpler, while you want to keep things more complicated, because you think that's what Arch is about. Obviously we have a different view of what Simple actually means. There is no common ground anymore.
Re: [arch-general] [arch-dev-public] initscripts changes
Thomas Bächler wrote: I am hacking initscripts and can't quite decide on two issues: 1) I'd like to hardcode /dev/pts/ mounting in rc.sysinit. 2) I'd like to remove the (hardcoded) line /usr/bin/setterm -blank 15 from rc.sysinit. Can I get opinions on these? Thomas, Having read your last e-mail you are right, I should have *pointed out* my opinion instead of going omgwtf. The thread resulted in savagery - nowhere near civilized. I apologize for that. I will try and keep my e-mails more professional. Glenn
Re: [arch-general] [arch-dev-public] initscripts changes
Thomas Bächler wrote: RedShift schrieb: Thomas Bächler wrote: I am hacking initscripts and can't quite decide on two issues: 1) I'd like to hardcode /dev/pts/ mounting in rc.sysinit. What's wrong with putting that in fstab? What if I don't want to have that mounted? So instead of modified fstab I'd have to mess with rc.sysinit everytime the initscripts get upgraded? This is the same discussion as with moving lo to rc.sysinit instead of leaving it in rc.conf. Uterly pointless. The point is, everyone needs it mounted. Your system will be completely useless without devpts (as it is without the lo interface). However, I know your opinion on these issues. Are there any rational reasons not to hardcode devpts? Yes. It's not logical. fstab was made for mounting filesystems, why even consider moving it to rc.sysinit? It's not because it makes the system unusable without it, that it should be moved to rc.sysinit. Why the change anyway? What's the benefit? Now we're going to see Heeey stuff's being mounted that's not in fstab? wtf?. This change is just plain irrational, fstab was _specifically made_ for mounting filesystems. If you're going to hardcode stuff like that you might as well throw away fstab. Glenn
Re: [arch-general] Custom kernel compile fails
CtM wrote: Happy April everyone! I was just wondering if anyone else was having issues building a recent custom kernel. I find that it fails on the make command. Here is the output I get: LD .tmp_vmlinux1 kernel/built-in.o: In function `getnstimeofday': (.text+0x205d3): undefined reference to `__umoddi3' kernel/built-in.o: In function `getnstimeofday': (.text+0x205f6): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x20718): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x20736): undefined reference to `__umoddi3' kernel/built-in.o: In function `timekeeping_resume': timekeeping.c:(.text+0x209e6): undefined reference to `__umoddi3' timekeeping.c:(.text+0x20a06): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x20d5a): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x20d7a): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': (.text+0x211f6): undefined reference to `__umoddi3' kernel/built-in.o: In function `update_wall_time': (.text+0x21216): undefined reference to `__udivdi3' make: *** [.tmp_vmlinux1] Error 1 I have tried kernel 2.6.24 and 2.6.24.4 on two different machines with two different cpu's (one intel dual core and one AMD 64 bit). I've tried using my previous config (make oldconfig) and also tried without it. I even ran make clean make mrproper on the new extracted kernel directory before attempting to build it. Usually upgrading a kernel is very routine for me, but this time it isn't working. All kernel sources were downloaded from kernel.org as usual for me. Any ideas would be appreciated. Thanks, CtM Linux 2.6.24 is broken with GCC 4.3. Either wait for the next release (which will most likely include a fix) or see this bugreport: http://bugs.archlinux.org/task/9801 it includes a link to a patch to compile linux with GCC 4.3. Glenn
Re: [arch-general] html messages on this list.
** 1. /Oh/ don't be *such* a square® Keith Richie wrote: On Sun, 30 Mar 2008 15:25:30 +0200, Arvid Ephraim Picciani wrote: please stop sending broken html from dialup machines. I can't believe arch-general is the only list where people do that. Even the default sa from the arch packges filters those with up to 8 points. Seriously,... archers should be able to read RFCs and setup their MUA correctly. Sadly it is not only this list. There's quite a few I subscribe to that have this issue. If only people could see what a mess it creates when the list is read with a proper reader. I can't stand the msn, hotmail, live, or yahoo spam that gets sent along with so many messages. (enable html for best performance)
Re: [arch-general] [arch-dev-public] Processor Generation++
Pierre Schmitz wrote: Am Montag, 17. März 2008 10:11:15 schrieb Tobias Powalowski: My opinion on this, why to desupport something which might be still used, also we all know that x86_64 is the future and therefore i don't think the benefit is worth the trouble. In addition to this MMX would not really boost anything. SSE would be much superior. And further more: You would only notice such improvements on heavy multimedia encoding stuff and such things you would not do on an 10 years old computer. You could say the same thing between using march=i386 vs. march=i686. I'm for this idea, and I would even suggest bumping from i686 to pentium3. But not any further than that, because I'm still using an ArchLinux install on my Pentium 3 500 Mhz testbox... Glenn
Re: [arch-general] Boot sequence stops at modules (rc.sysinit)
Stephen Wilkinson wrote: Hello everyone, After upgrading the kernel alone (and after fixing some kernel panics -- see postscript) the boot sequence now stops at loading the modules ([DONE]) and goes no further: the cursor blinks and I can type characters, but I never get a shell prompt. It seems the boot sequence doesn't go beyond rc.sysinit The only reference I found to a similar problem is in the forum: http://bbs.archlinux.org/viewtopic.php?pid=323775 where it was suggested to try the fallback image and removing modules from the rc.conf. I've tried both, but hasn't helped (as expected: the kernel loads properly, so not an ramdisk problem, and the modules also load as I get [DONE] status...). Before this problem, I knew nothing at all about the boot sequence in linux so I read this: http://wiki.freegeek.org/index.php/The_Linux_Boot_Sequence The next step after Loading modules is loading standard ACPI modules. Try adding these to the module blacklist in rc.conf: ac battery button fan processor thermal Glenn
Re: [arch-general] where is kde 3.5.9 ?
solsTiCe d'Hiver wrote: Have you read the changelog? It's hardly worth being excited for... yes you're right. i was hoping a part of it was missing or hidden somewhere else on there site... but it does not seem so. is it this ? http://www.kde.org/announcements/changelogs/changelog3_5_8to3_5_9.php That is the official changelog, I don't see any else around?
Re: [arch-general] where is kde 3.5.9 ?
solsTiCe d'Hiver wrote: hi kde 3.5.9 is out since the 19th february i was used to have the latest kde release the day before the offical release on arch ! now we are almost 10 days after the official release and nothing. what's happening ? even if arch switch to kde 4 (too soon for me) i prefer to wait Kde 4.1 will we have a kde 3.5.9 release in arch ? Have you read the changelog? It's hardly worth being excited for... Glenn
