Re: [arch-general] Authorized Resume Devices and Linux 3.2
May not be much help, but Prior to 3.2 I had to use "echo USB0 > /proc/acpi/wakeup" to allow my keyboard/mouse to wake up the computer (USB0 was disabled by default). Now with 3.2 this no longer the case (USB0 is enabled by default). In my case, I want it disabled since I have my keyboard + mouse attached with a KVM. With USB0 enabled, the keyboard & mouse will wake up the system. All it takes is a bump of the mouse and next thing I know the system is back on. TLDR; Something changed, in regards to the suspend code, in 3.2 ~pyther On 01/19/2012 02:17 PM, Bastien Dejean wrote: Hi, My '/etc/rc.local' contains the following lines: echo EHC1> /proc/acpi/wakeup echo EHC2> /proc/acpi/wakeup Those commands were working fine before Linux 3.2. But now, they seem to be ineffective (i.e. the corresponding devices are marked as '*disabled' in the output of `cat /proc/acpi/wakeup`). Greetings,
Re: [arch-general] Authorized Resume Devices and Linux 3.2
On 01/19/2012 02:17 PM, Bastien Dejean wrote: Hi, My '/etc/rc.local' contains the following lines: echo EHC1> /proc/acpi/wakeup echo EHC2> /proc/acpi/wakeup Those commands were working fine before Linux 3.2. But now, they seem to be ineffective (i.e. the corresponding devices are marked as '*disabled' in the output of `cat /proc/acpi/wakeup`). Greetings, I can't believe I topped posted! Argh! So so sorry! May not be much help, but Prior to 3.2 I had to use "echo USB0 > /proc/acpi/wakeup" to allow my keyboard/mouse to wake up the computer (USB0 was disabled by default). Now with 3.2 this no longer the case (USB0 is enabled by default). In my case, I want it disabled since I have my keyboard + mouse attached with a KVM. With USB0 enabled, the keyboard & mouse will wake up the system. All it takes is a bump of the mouse and next thing I know the system is back on. TLDR; Something changed, in regards to the suspend code, in 3.2 ~pyther
Re: [arch-general] KDE 4.8
On 01/26/2012 03:27 AM, Jelle van der Waa wrote: On 26/01/12 01:14, G. Schlisio wrote: Am 26.01.2012 00:01, schrieb Paulo Roberto P. Evangelista: Hi, When kde 4.8 will be available in extra repossitories?? hey, dont put pressure on the great people compiling, testing and packing for us. i think, we arch users really cant complain about not beeing fed with fresh updates. btw: dont forget, these people are volunteers and kde does not compile in a minute… It's already in [testing] And a cautionary warning about testing... "*Warning*: Be careful when enabling [testing]. Your system may break after you perform an update with the [testing] repository enabled. Only experienced users who know how to deal with potential system breakage should use it." https://wiki.archlinux.org/index.php/Testing#.5Btesting.5D
Re: [arch-general] Updates
On 01.31.2012 04:38, Myra Nelson wrote: On Tue, Jan 31, 2012 at 03:13, Ionut Biru wrote: Thanks for the info. There are many things I still don't know. I figured by rebuilding them it would tell me if something was wrong on my machine. Another reason for me not to file a bug report. The problem was between the keyboard and the chair and I don't think the devs can fix that one. Myra If you are going to use testing, you should subscribe/read arch-dev-public.
Re: [arch-general] backing up a blackberry phone
On 02/07/2012 04:31 PM, P Nikolic wrote: Hi .. I have a Balckberry Curve i could do with backing up again on suse i used to use BarryBackup has anyone provided this for Arch or what do people use to backup their Balckberrys .. Cheers Pete . Search AUR. If it isn't in AUR, then likely not. Create your own pkgbuild or compile from source. Alternatively, you can make a request on the BBS[1]. [1] https://bbs.archlinux.org/viewforum.php?id=38
Re: [arch-general] 'Local mirror' page was removed from wiki
On 09/15/2010 12:20 AM, Fess wrote: On 19:13 Tue 14 Sep , C Anthony Risinger wrote: On Tue, Sep 14, 2010 at 2:27 PM, Nathan Wayde wrote: here's what I'd(and I imagine most others who know about sharing the cache) use a local mirror for: to be able to sync all other systems from it. plain and simple. if my systems don't have internet connection or something like that then i simply get the packages from the master, cache sharing doesn't and cannot solve that problem at all, that's a fact. shared cache won't solve that sure... but there are better solutions: ) if you can get it from master, then it sounds like you have a LAN connection; tunnel a connection thru master... ) if you have a LAN, what can't some machines have access anyway? ) if you don't have a LAN, you are manually moving packages? you could do that without a local mirror ) if you have a LAN, but _cannot_ allow some access to the net, then use a different method like a caching proxy local mirror = quick/easy crutch to avoid better utilization of local/peer resources i use a homebrew proxy/cache solution for my home, works fine. one machine pretends to be a repo, others look to it for packages... easy. i'm not using this exact version now, but i implemented this (rather crappily) while first learning python: "pacproxy (or something that vaguely resembles an apt-proxy clone)" https://bbs.archlinux.org/viewtopic.php?id=87115 now to the bandwidth issue. it's obviously bogus, because: 1) they assume everyone/(lots of people) is going to create a local mirror. 2) they assume that they're all going to sync from the same server. 3) they assume this extra bandwidth waste actually causes a problem for all the mirrors - i.e that there's only 1 mirror. now, if my assumptions are wrong thus leading to false conclusions then please correct me, but so far all I've heard is whining about local mirror causing problems for the mirrors but nothing about what these problems actually are, in the meantime the original wiki was deemed bad with not much of a valid reason and nothing being done to further educate us the users. i don't think it's even about whether or not it _is_ causing a problem, and more a preemptive move to discourage naive implementations. sure, if you have a heterogeneous environment of 200 machines, then a local mirror probably isn't too bad an idea... but it still isn't needed, as faster/better/cheaper methods are available. in my opinion, if you're not publicly seeding your mirror, then you don't need it; else you probably only want it due to an extreme case of laziness. sure maybe mirror XYZ can handle constant sync's from everyone looking at it... but really, do them a favor, and don't; it might piss them off :-). You can probably tell that I'm annoyed by this and the simple fact is that ARM sync script was based off the script on that wiki, it's not the same as I changed a lot of options to cater to my own needs but as have been said the script was bad, no-one is telling us what was bad about it and these alternative methods are wholly inadequate at best. yeah i don't really know the politics here, or have even seen the script. in my own experience back in the day syncing ubuntu repos (for easy install at remote locations from large USB key when client requirements are unknown)... you likely flat out don't need it, and there are _very_ few legitimate use cases for it (the parenthesized use case above is about the best one i know). all i'm suggesting is that just because you can and it's easy doesn't mean you should. but hey, i don't run a mirror, and extreme leeching won't affect me, so ultimately i could care less; if i did though, i would monitor for this kind of crap... i mean, doesn't the official arch mirror impose similar restrictions? just do you part to not be excessive. does one check out the entire library on the possibility of reading 10 books? C Anthony I think, i know(and others, who use this method) better what i'm doing, and why i am doing it. So, i tell you once more - community think, that this is useful. People, who say "Hey, man! I have server, and rsync installed, add me please to the list of 3rd party mirrors" know what they do. If they offer this service - they think it helps. If they would have 'tiny pipe'(or something else tiny) they wouldn't do it. So, i still don't understand why opinion of community ignored. Ok a few things here 1. There are a *few* instances where having a local mirror is warranted 2. There are many, many, many packages that are in the repos that *you* don't use! Every time you download one of these packages it is wasted bandwidth! 3. Mirror bandwidth is not free! Every time you are downloading unused packages you are wasting the mirrors money! Why waste money? (Keep point 1 in mind) 4. @Fess you and a few other people do not make the community. 5. The majority of the community will agree that hosting a local mirror is silly considering that there a
Re: [arch-general] 'Local mirror' page was removed from wiki
On 09/16/2010 02:59 PM, Nathan Wayde wrote: On 16/09/10 19:39, Matthew Gyurgyik wrote: [..] Ok a few things here 1. There are a *few* instances where having a local mirror is warranted not sure where you were going with that but i feel like you've left a bit off of that sentence. 2. There are many, many, many packages that are in the repos that *you* don't use! Every time you download one of these packages it is wasted bandwidth! you don't get to tell anyone how to use their bandwidth. 3. Mirror bandwidth is not free! Every time you are downloading unused packages you are wasting the mirrors money! Why waste money? (Keep point 1 in mind) since i already payed for that bandwidth and utilize it for other purposes it is in fact free. You most certainly do not pay for the Mirror's bandwidth! Just look at this article: http://lwn.net/Articles/178618/ 4. @Fess you and a few other people do not make the community. not sure what point you're trying to make here 5. The majority of the community will agree that hosting a local mirror is silly considering that there are alternatives! the majority of people at least in the western cultures will agree that paedophilia is sick. the majority of these people don't know what paedophilia is. again not sure where you're going with that so i thought I'd make some wild pointless claims as well. 6. I am quite sure that mirror operators are not and will not be happy with users downloading gigs of data a month so they can have their own local mirror. when you become a mirror operator or bring actual evidence to the table you will have a say in this. Again look here: http://lwn.net/Articles/178618/ or ask any admin in charge of bandwidth operations. Aaron if you are reading this, would mind sharing the bandwidth cost for the arch servers? 7. Remember, the local mirrors are generously mirroring for us. They are under *no obligation* to do so! Treat them with respect! this doesn't make any sense. 8. If point 1 applies, then those people should be more than capable of producing their own scripts. we are. but you see, the point you decided to side-step is that we're being told that the existing script was bad, now, if it was bad fair enough but no-one can(or will) tell us what was so wrong about it; result: you're now forcing everyone that needs to create their own script to do so and thus risk causing the same problems the old script cause because as I've stated multiple times - no-one is telling us(me) what the problems are with that script. it's all well and good to say this or that is bad but if you're not going to tell anyone what's bad about it then we'd all be better off if you hadn't opened your mouth at all.
Re: [arch-general] 'Local mirror' page was removed from wiki
On 09/18/2010 05:44 PM, f...@kokkinizita.net wrote: On Sat, Sep 18, 2010 at 02:50:17PM -0500, C Anthony Risinger wrote: which seems an appropriate question, given the circumstances of removal; if the only reason was to discourage the creation of local mirrors... well, to me at least, that seems a poor reason. i sympathize with some of the reasons for creating localized mirrors. in particular, when the mirror is located on a removable device it is especially useful... i did this to perform off-site installations, in addition to installing packages i needed when a connection wasn't available (ie. Nathan's train example) I'd agree. I have to maintain 7 and soon 11 machines which do not have have any internet access at all. In the past I've been able to get away with taking them home for installation/updates, but that will not be possible anymore. So what is the solution for this if you can't have a local mirror on a portable device ? Ciao, There is nothing preventing you from creating a local mirror. If you can't figure out how to create a local mirror using the resource available, you probably shouldn't be using arch.
Re: [arch-general] 'Local mirror' page was removed from wiki
On 09/19/2010 11:45 AM, Steve Holmes wrote: On Sat, Sep 18, 2010 at 10:46:13PM -0400, Matthew Gyurgyik wrote: There is nothing preventing you from creating a local mirror. If you can't figure out how to create a local mirror using the resource available, you probably shouldn't be using arch. Now, there's a supportive answer if I ever heard one. That's the way to get more people interested in using arch. Most distros like to build up their presence and increase the numbers and usage. Obviously if everyone goes out there and attempts to build local mirrors and all, that would put a big drain on the arch package update process. I don't think many people are doubting that and maybe it should be discouraged however. But the withholding of technical knowledge with such arrogance is in poor taste if you ask me. Like others have been saying all along now, the original information was pulled and no technical explanation was ever offered for why it was wrong. Now because of all this "secrecy" (in appearance), I've increased my curiosity and may look into building a local mirror just so I know how to do it. Had the thing on the wiki site been corrected, I would have probably just read it and kept it in the back of my mind for a day when I would really need to do it. As I posted on the forum... How hard is it to run rsync and look at the man page for rsync? rsync is the *only* command that is needed to create a local mirror. We want to discourage this behavior as much as possible and it is really quite trivial to setup a mirror. Setup a local mirror 1. rsync to local dir (look at the developer's wiki for mirrors and the proper rysnc arguments) 2. Set up webserver to serve local dir (if on a lan) 3. Set local mirror url in mirrorlist 4. Alternatively use Server = file:///mnt/media/mirror/$repo/os/x86_64 in pacman.conf or mirrorlist That is all that has to be done. If one is going to be creating a local mirror, he/she should really have this basic knowledge.
Re: [arch-general] 'Local mirror' page was removed from wiki
On 09/19/2010 12:16 PM, Mauro Santos wrote: On 09/19/2010 04:45 PM, Steve Holmes wrote: Most distros like to build up their presence and increase the numbers and usage. Obviously if everyone goes out there and attempts to build local mirrors and all, that would put a big drain on the arch package update process. I don't think many people are doubting that and maybe it should be discouraged however. But the withholding of technical knowledge with such arrogance is in poor taste if you ask me. Like others have been saying all along now, the original information was pulled and no technical explanation was ever offered for why it was wrong. Now because of all this "secrecy" (in appearance), I've increased my curiosity and may look into building a local mirror just so I know how to do it. Had the thing on the wiki site been corrected, I would have probably just read it and kept it in the back of my mind for a day when I would really need to do it. You have a point when you say that all this discussion will increase the interest in creating a local mirror (for the people that read the mailing list). Some people will think about it a bit more but never try it (too much hassle for something they don't need or use), the ones that really need it will either find a way to do it or have already created a local mirror. It seems to me that the major point here is the difference between the wiki sort of endorsing a method to do it (which may put an higher load on a mirror, which the maintainer needs to pay for) or the user to come up with a way to do it. I don't have any doubts that any half decent arch user can do so if he/she wishes/needs to do it (these are the users most likely to need it anyway), but having an example on the wiki that can possibly tax a mirror because the procedure is not the most appropriate and the user trying it just copies the procedures verbatim is just wrong. Well stated. My feelings 100%
Re: [arch-general] 'Local mirror' page was removed from wiki
On 09/19/2010 02:02 PM, Nathan Wayde wrote: On 19/09/10 17:26, Matthew Gyurgyik wrote: [...] As I posted on the forum... How hard is it to run rsync and look at the man page for rsync? rsync is the *only* command that is needed to create a local mirror. We want to discourage this behavior as much as possible and it is really quite trivial to setup a mirror. Setup a local mirror 1. rsync to local dir (look at the developer's wiki for mirrors and the proper rysnc arguments) 2. Set up webserver to serve local dir (if on a lan) 3. Set local mirror url in mirrorlist 4. Alternatively use Server = file:///mnt/media/mirror/$repo/os/x86_64 in pacman.conf or mirrorlist That is all that has to be done. If one is going to be creating a local mirror, he/she should really have this basic knowledge. This elitist attitude is what pisses me off most about the Arch community but I must admit that you sir just took it to the next level. I'll answer your question anyway. It's pretty easy to create a local mirror. But in your haste to show off your holyness you forgot that the issue isn't about creating a mirror, it's about doing it properly without causing issues for upstream. Your idea about throwing an rsync command at is does things like sync the entire mirror(as-is recommended in the NewMirrors wiki) which I'm sure isn't what you actually want if you're going to create a local mirror and this will undoubtedly just waste bandwidth for the mirror, after-all, if it's the packages you want then why would you go and sync the ISOs or even the sources? Now, I've stated my personal use-case and I' sure other have similar and other use-cases for having a local mirror, so I guess you have no argument against it other than it's something else that isn't useful to you so should be available to anyone else... Now, If you think it's a good idea to keep trolling as opposed to go and read what the actual issues are then please continue you are free to do so. You can use the --exclude-from=/path/to/excludefile.txt rsync argument - it exclude directories that you don't need. I have updated the wiki to include some basic information on setting up a local mirror. I believe it provides enough information to help someone set up local mirror while still holding them accountable for a certain amount of knowledge. Please take a look at it and improve it where you see fit. Since I have no need for a local mirror I might be over looking something. http://wiki.archlinux.org/index.php/Local_Mirror If you don't like the attitude don't use arch. Arch isn't here to babysit you and hold your hand. This is truly what sets arch apart. The users who have been here for 4-5+ years know exactly what I'm talking about. However, I digress as this isn't the time or place to discuss this.
Re: [arch-general] 'Local mirror' page was removed from wiki
On 09/19/2010 08:02 PM, f...@kokkinizita.net wrote: On Sun, Sep 19, 2010 at 03:22:27PM -0400, Matthew Gyurgyik wrote: I have updated the wiki to include some basic information on setting up a local mirror. I believe it provides enough information to help someone set up local mirror while still holding them accountable for a certain amount of knowledge. Please take a look at it and improve it where you see fit. Since I have no need for a local mirror I might be over looking something. http://wiki.archlinux.org/index.php/Local_Mirror Thanks. I know how to use rsync, set up a server (not even needed in my case) etc. The interesting info is what should be excluded. It may be a good idea to provide a full repo / top level directory list for a tier-1 mirror (or a link to it if already available on the wiki) so users can create a complete --exclude-from list from the start instead of incrementally adding to it when they discover they are downloading things they don't need. I know you can use rsync to get such a listing, but still. Ciao, I added this pointer: Take look at the top level directory of the mirror that you choose and *make sure* to exclude anything you do no not need The example for /path/to/exclude.txt includes uncommon/unneeded top level dirs (iso, staging, kde/gnome-unstable, etc...)
[arch-general] Repo Structure - Pool Dir
Hello. Currently I see that there are some packages in /archlinux/extra/os/i686/ and some symlinks to ../../../pool/packages/. I was hoping a dev would be able to answer the following the questions? Eventually, will all packages (from core/extra/community) end up in pool? Repos like multilib, gnome-unstable, kde-unstable will not end up, right? Thanks, ~pyther
[arch-general] Local Mirror - Wiki Article
Since the other thread is huge and hard to follow, I am creating a new
thread.
I would like to use this thread to talk strictly about the Local Mirror
wiki article.
I have updated the wiki article to reflect the new pool directory.
Currently there are some packages that are in pool/ while others are still
in {$repo}/os/${arch}. Those in pool have symlinks to {$repo}/os/${arch}
>From my understanding, eventually, all packages will be in pool/
http://wiki.archlinux.org/index.php/Local_Mirror
I am hoping someone who runs a Local Mirror can try this out. I do not
have a need for a local mirror nor do I want to pull Gigs of data from a
mirror to test this. However, I have done dry runs on the rsync command.
@Devs: Maybe someone can update the Mirror Section in the NewMirrors wiki
article
http://wiki.archlinux.org/index.php/DeveloperWiki:NewMirrors#Mirror_size
Re: [arch-general] How do AUR packages get new maintainers?
On 09/21/2010 04:53 PM, David C. Rankin wrote: Guys, I've seen recent "Request to Ophan package XYZ" posts, and I've found some fairly large AUR packages that are orphaned (like RPM5). But, how do AUR packages get new maintainers? Does somebody monitor the orphans and then divvy them out among those with write privileges in AUR or does somebody have to say I'll take package X on? http://wiki.archlinux.org/index.php/AUR Really dude? You've been using arch for how long and still have these elementary questions? Think about you questions and try to find answer before you post to the list. Alternatively hire an arch tutor.
Re: [arch-general] How do AUR packages get new maintainers?
On 09/21/2010 06:17 PM, Matthew Gyurgyik wrote: On 09/21/2010 04:53 PM, David C. Rankin wrote: Guys, I've seen recent "Request to Ophan package XYZ" posts, and I've found some fairly large AUR packages that are orphaned (like RPM5). But, how do AUR packages get new maintainers? Does somebody monitor the orphans and then divvy them out among those with write privileges in AUR or does somebody have to say I'll take package X on? http://wiki.archlinux.org/index.php/AUR Really dude? You've been using arch for how long and still have these elementary questions? Think about you questions and try to find answer before you post to the list. Alternatively hire an arch tutor. EDIT: Think about your questions and try to find an answer before you post to the list.
Re: [arch-general] How do AUR packages get new maintainers?
On 09/21/2010 10:07 PM, Mario Figueiredo wrote: On 21-09-2010 23:17, Matthew Gyurgyik wrote: On 09/21/2010 04:53 PM, David C. Rankin wrote: Guys, I've seen recent "Request to Ophan package XYZ" posts, and I've found some fairly large AUR packages that are orphaned (like RPM5). But, how do AUR packages get new maintainers? Does somebody monitor the orphans and then divvy them out among those with write privileges in AUR or does somebody have to say I'll take package X on? http://wiki.archlinux.org/index.php/AUR Really dude? You've been using arch for how long and still have these elementary questions? Think about you questions and try to find answer before you post to the list. Alternatively hire an arch tutor. And who on earth are you? Well I'm pyther and I've been around since '05. You? It is extremely annoying to see these elementary and many times unrelated emails on this list. David has had a history of not bothering to do simple searches to find answers to his questions. Arch is a do-it-yourself type of distro. I don't mind helping folks when they run into problems, but they have to show that they have made some attempt to help themselves. Just having a general idea of how the AUR works would have answered David's question. If you use arch you should be able to use the wiki, man pages, and google, at the minimum.
Re: [arch-general] Local Mirror - Wiki Article
On 09/22/2010 01:20 PM, Fess wrote:
On 09:18 Tue 21 Sep , Matthew Gyurgyik wrote:
Since the other thread is huge and hard to follow, I am creating a new
thread.
I would like to use this thread to talk strictly about the Local Mirror
wiki article.
I have updated the wiki article to reflect the new pool directory.
Currently there are some packages that are in pool/ while others are still
in {$repo}/os/${arch}. Those in pool have symlinks to {$repo}/os/${arch}
> From my understanding, eventually, all packages will be in pool/
http://wiki.archlinux.org/index.php/Local_Mirror
I am hoping someone who runs a Local Mirror can try this out. I do not
have a need for a local mirror nor do I want to pull Gigs of data from a
mirror to test this. However, I have done dry runs on the rsync command.
@Devs: Maybe someone can update the Mirror Section in the NewMirrors wiki
article
http://wiki.archlinux.org/index.php/DeveloperWiki:NewMirrors#Mirror_size
Thank you for recovering this page.
The page was *not* recovered. It was updated with new, correct information.
Re: [arch-general] How do AUR packages get new maintainers?
On 09/22/2010 01:52 PM, David C. Rankin wrote: On 09/21/2010 05:17 PM, Matthew Gyurgyik wrote: On 09/21/2010 04:53 PM, David C. Rankin wrote: Guys, I've seen recent "Request to Ophan package XYZ" posts, and I've found some fairly large AUR packages that are orphaned (like RPM5). But, how do AUR packages get new maintainers? Does somebody monitor the orphans and then divvy them out among those with write privileges in AUR or does somebody have to say I'll take package X on? http://wiki.archlinux.org/index.php/AUR Really dude? You've been using arch for how long and still have these elementary questions? Think about you questions and try to find answer before you post to the list. Alternatively hire an arch tutor. OK, now I have read the entire document. What part of it are you relying on to answer my original question? The only mention of 'orphan' in the entire document is the following -- Q: Foo in AUR is outdated; what do I do? A: For starters, you can flag packages out-of-date. If it stays out-of-date for an extended amount of time, the best thing to do is email the maintainer. If there is no response from the maintainer, *you could mail to the aur-general mailing list* to have a TU orphan the PKGBUILD if you're willing to maintain it yourself. emphasis between the '*'s is mine. Well I think you picked out the line. "if there is no response from the maintainer, you could mail to the aur-general mailing list to have a TU orphan the PKGBUILD *if you're willing to maintain it yourself.*" (I added the emphasis) An user with basic knowledge of the AUR should be able to figure out that he/she would be able to maintian an orphaned package. Now I might be able to see some difficulty in interpreting this if you are a non-native speaker. However, since you are a Texan lawyer, I would imagine that you speak fluent English. Also, the section 'Sharing PKGBUILDs in UNSUPPORTED' and 'Submitting Packages to AUR' would help you understand how the AUR works. Does somebody monitor the orphans and then divvy them out among those with write privileges in AUR or does somebody have to say I'll take package X on? That statement, at least to me, would indicate that you are not familiar with how the AUR works and operates. Therefore, that wiki article in general would have given you some very good, fundamental, knowledge. if you had asked "How can I maintained an orphan package?" then it would be a different story.
Re: [arch-general] update to kde 4.5.2 - no sound - tri es to remove my devices??
On Wed, 06 Oct 2010 22:05:05 -0500, "David C. Rankin" wrote: > Guys, > > I updated to 4.5.2 today and on start, kde4 asked to remove all my sound > devices. So I chose - 'manage devices'. All of my sound devices are grayed > out > and the 'default' doesn't work. (screenshot of devices dialog here): > > [81k] > http://www.3111skyline.com/dl/Archlinux/bugs/kde4-nosound.png > > The sound is "HDA Nvidia (ALC888 Analog)" and the same for digital and > HDMI. I > looked through dmesg to see if there was anything glaring, but there > wasn't. > (dmesg output here): > > [44k] > http://www.3111skyline.com/dl/Archlinux/bugs/dmesg-20101006.txt > > Has anyone else seen this with the new kde4? If so any ideas how best to > troubleshoot? Thanks for any help you can provide. I am not a kde user, but I did a google search for "phonon sound device grayed out" http://www.google.com/search?q=phonon+sound+device+grayed+out&ie=utf-8&oe=utf-8 I found the following two links which may be helpful: http://forum.kde.org/viewtopic.php?f=19&t=88436 http://linux.derkeiler.com/Mailing-Lists/Fedora/2008-09/msg01853.html
Re: [arch-general] Anybody else having trouble with Virtualbox after upgrade
On 10/15/2010 10:20 AM, Pico Geyer wrote: On Fri, Oct 15, 2010 at 3:56 PM, Nilesh Govindarajan wrote: On Fri, Oct 15, 2010 at 5:38 PM, Pico Geyer wrote: Hi all. I hope this is the right place for me to raise my issue. After doing a pacman -Syu and then rebooting I noticed that I could no longer start my VirtualBox vms I get the following error: Failed to open a session for the virtual machine My_VM Callee RC: NS_ERROR_INVALID_ARG (0x80070057) Virtualbox then crashes (segmentation fault). I had the testing repo enabled, so I thought that one of the packages from testing might have broken it. So I disabled the testing repo in pacman.conf and removed all testing packages with: pacman -Syy pacamn -Suu I then recompiled my virtualbox drivers and rebooted. But that did not help at all. I created a core dump file by following these instructions: http://www.virtualbox.org/wiki/Core_dump So the stack trace is 41000 lines long :-| I'll paste just the first and last few lines: #0 0xb5cad825 in ?? () from /usr/lib/libQtGui.so.4 #1 0xb5ca7b27 in ?? () from /usr/lib/libQtGui.so.4 #2 0xb5ca9760 in QTextEngine::itemize() const () from /usr/lib/libQtGui.so.4 #3 0xb5caeca8 in QTextLayout::beginLayout() () from /usr/lib/libQtGui.so.4 #4 0xb5b9b550 in ?? () from /usr/lib/libQtGui.so.4 #5 0xb5b9c1b1 in ?? () from /usr/lib/libQtGui.so.4 [snip] #41537 0xb5a36407 in QApplication::exec() () from /usr/lib/libQtGui.so.4 #41538 0xb6b5405b in TrustedMain () from /usr/lib/virtualbox/VirtualBox.so #41539 0x08048d9f in ?? () #41540 0xb76ccc76 in __libc_start_main () from /lib/libc.so.6 #41541 0x08048c81 in ?? () Any advice? Should I file a bug in the arch bug tracker? Thanks in advance. Pico Did you rebuild the module using /etc/rc.d/vboxdrv setup? Yeah, that's the first thing I tried. Pico Did you reload the modules after rebuilding them? rmmod vboxdrv; rmmod vboxnetflt; modprobe vboxdrv; modprobe vboxnetflt; etc...
Re: [arch-general] Python 3 Rationale?
On 10/20/2010 10:58 AM, Max Countryman wrote: That is fine unless the Python development team has decide that python3 will not become python. Python 2.7.x will be maintained for quite some time. (In excess of four more years.) Even after it is dropped in the future there's no indication that the python3 binary is intended to become the python binary. The link I posted earlier to the thread on the Python mailing list seems to indicate the opposite. On Oct 20, 2010, at 10:32, C Anthony Risinger wrote: I think what Arch is doing is perfectly reasonable; if you, as a developer, or even a user, run the `python` binary, you should not expect any assurances, as you are making assumptions about the target environment. If your app requires a particular major or minor version to operate correctly, then make this clear in the shebang, throw an exception, etc... imo, catering to sluggish apps that are not py3k compatible and not active enough to even acknowledge the onset of py3k, is a waste of time. Please don't top post. http://www.river.com/users/share/etiquette/
Re: [arch-general] Python 3 Rationale?
On 10/20/2010 11:45 AM, maxc wrote: There is an excellent post by Guido here, Hilton: http://mail.python.org/pipermail/python-3000/2008-February/011910.html Guido seems to favor using /usr/bin/python3.0 or /usr/bin/python3 and /usr/bin/python as symlinks to the respective versions of Python. 'Perhaps we should only install "python3.0" and not "python".' We're not here to discussion semantics ofc. :) There is a much broader concern which I hope we can address through friendly discourse. On Oct 20, 2010, at 11:26 AM, Hilton Medeiros wrote: On Wed, 20 Oct 2010 10:58:42 -0400 Max Countryman wrote: > That is fine unless the Python development team has decide that > python3 will not become python. > > Python 2.7.x will be maintained for quite some time. (In excess of > four more years.) Even after it is dropped in the future there's no > indication that the python3 binary is intended to become the python > binary. > > The link I posted earlier to the thread on the Python mailing list > seems to indicate the opposite. A 'python' binary doesn't and won't ever exist, it is only a symlink, Max. Since you have seemed to miss my previous post. I'll post again! Really please, please don't top post. http://www.river.com/users/share/etiquette/
Re: [arch-general] Radeon HD 5xxx
On 11/08/2010 08:22 PM, Andrew Allen Barkley wrote: I am now an owner of a Radeon HD 5870. But... lspci reports it as: VGA compatible controller: ATI Technologies Inc Device 6898 I am running testing. Also, the feature matrix linked to by the ATI page on the wiki indicates that HD 5xxx cards are supported by xf86-video-ati, as does the wiki. What's the situation on this? How about you try and find out? Is there a reason why you can't?
Re: [arch-general] wicd startup issues
On 11/17/2010 02:18 PM, Evangelos Foutras wrote: On Wed, Nov 17, 2010 at 9:08 PM, Samuel Baldwin wrote: Same error. I'm not updated to the point where python3 is the default anyways. `python' still runs 2.6.5. We don't support partial upgrades. You should never use -Sy if not followed by -Su (or combined, -Syu). Now, go ahead and do a full upgrade. :) To explain what happened... the wicd modules got installed in /usr/lib/python2.7/site-packages/, however python2 is looking for the modules in /usr/lib/python2.6/site-packages/ As stated above you should always do full upgrades. Failing to do so, results in no support from us.
Re: [arch-general] [arch-dev-public] Boot loaders in core/base
On 11/20/2010 05:27 AM, Pierre Schmitz wrote: Hi, while reviewing the core rebuild list I wondered if we should think about chaining our default boot loader. Note: that wont affect existing setups and people will still be able to use whatever they like. ATM. we have grub1 in core/base and install that by default. The problem is that this project is virtually dead for a long time now and also not available on x86_64. Technically it has to be in the multilib repo. Grub2 is currently in extra. Upstream development is still in flux. Imho its quite heavy and complex. An alternative successor would be extlinux from the syslinux package. It's very simple, easy to configure, actively maintained and reliable. Sure, it only supports booting from ext* and btrfs afaik but to be honest, if you use any other FS you should have a separate /boot even when using grub. Summing up my suggestion for some time in the future would be: * move extlinux/syslinux to core/base * move grub1 to extra/multilib and remove it from base group * keep grub2 in extra * maybe also move lilo to extra * of course keep all of them on the install cd What do you think about this? At some point it might not be sane/possible to keep grub1 as our default boot loader. Greetings, Pierre I was thinking about how we could integrate extlinux into the installer and have suggested creating an additional package called extlinux. This package would would include an example config and a few *.c32 file needed to make the config work. As a result, the installer would just have to modify the example config and run extlinux --install /boot/syslinux. As an added bonus, it makes things easier for the end user (/boot/syslinux doesn't need to be created and *.c32 files don't need to be copied to /boot/syslinux). I have all the juicy details and an explanation here: https://bugs.archlinux.org/task/21766 ~pyther
[arch-general] Acceptable for AIF to copy files?
Hello I want to add extlinux support in AIF. However, unlike grub, where grub-install takes care of everything, extlinux requires /boot/syslinux to be created and some files from /usr/lib/syslinux to be copied to /boot/syslinux. Initially I though that creating a extlinux pkg that would include the needed file in /boot would be a good idea. Needless to say, there is mixed opinion on this. See link for more info: https://bugs.archlinux.org/task/21766 So... Is it acceptable for AIF to create /boot/syslinux and copy files from /usr/lib/syslinux to /boot/syslinux? Do we only want to let pacman and upstream install tools create directories and copy files during the install process? ~pyther
Re: [arch-general] archlinux hardware question
On 11/28/2010 05:59 PM, Jude DaShiell wrote: A sled drive puts an internal drive into a sled case. Then the user slides the sled case along tracks installed for that purpose into the computer and in order to use it must lock the drive with a key. You can put operating systems on different hard drives that way and if one gets compromised pull it out and replace disk to keep running. On Sun, 28 Nov 2010, Damjan wrote: Has anyone managed to get archlinux up and running on either a sled drive or a full-sized usb drive yet. Another Linux system I have couldn't even detect the disk drive was in the machine and I gave it my best hard drive too. Slackware has no problem with the drive, but Debian squeeze or an earlier edition of lenny squeeze had problems too. What's a "sled drive"? Anyway, when the LCD broke on my main laptop, and I sent it for a repair, I took out the hard drive, put it in an external USB box and hooked it up on an Asus EEEpc 701. Except that I had to update the initramfs to include the usb drivers (ehci_hcd, uhci_hcd, usb_storage, sd_mod) I don't remember doing anything else special. fstab was already configured to mount by uuid, grub2 too. -- ?? Please do not top post. It sounds as if you are describing a hot-swappable drive. Something like this: http://www.newegg.com/Product/Product.aspx?Item=N82E16817994054 If that is the case then the kernel should just have to support your SATA chipset. As with a USB drive you should just need to provide the needed usb kernel modules as Damjan stated in yoru initrd file. Edit /etc/mkinitcpio.conf and run mkinitcpio -p kernel26
Re: [arch-general] postfix/procmail unable to write to /var/spool/mail/$USER
On 12/18/2010 08:42 PM, David C. Rankin wrote: Guys, I'm stuck on mail setup with a procmail error saying it can't write to /var/spool/mail/$USER. It is a postfix error, but it is complaining about procmail. An example of the error is: Dec 18 19:10:37 localhost postfix/local[2104]: E238BE7E78: to=, relay=local, delay=1.2, delays=0.14/0.04/0/1, dsn=5.2.0, status=bounced (can't create user output file. Command output: procmail: Error while writing to "/var/spool/mail/david" ) I'm fairly certain it is a user permission problem, but I can't recall ever changing anything before on my other setups to get procmail working. In this current config, /etc/postfix/main.cf has: mailbox_command = /usr/bin/procmail -a "$EXTENSION" The permission for /var/spool/mail are the exact same I have on my x86_64 Arch server at home where procmail is working just fine: [19:27 phoenix:/var/spool/mail] # l total 386772 drwxrwxrwt 2 root root4096 Dec 18 19:13 . drwxr-xr-x 8 root root4096 Dec 18 16:54 .. -rw--- 1 david dcr362640748 Dec 18 19:05 david Just as with that box, I moved the mail spool from the suse install to the new install, so I don't think that would be the issue here. Anybody have any idea why postfix/procmail can't write to /var/spool/mail? Maybe you could use LOGFILE=$MAILDIR/from (read man procmail) to get a better idea of what is going on. Maybe you can get rid of the annoyingly long signature. arch-general is a public list for crying out loud! Maybe you need to spend a bit more time with your problems before posting on the ML. Use the bbs for general support questions. You've had 4 threads in the past 3 days! You by far are responsible for the most new topics each month! Spend more time thinking about how you can troubleshoot things and provide more information when you do post. In many of your threads you reply to your orginal within 15-30 minutes! BTW maybe you should use something on your servers you can manage. Your http server has been broken for at least two days. Lastly many of things you post about are upstearm bugs (your dhcp thread). Look at http://projects.archlinux.org/svntogit/packages.git/tree/ see if the package in question uses any patches and if not report upstream, not downstream! Please stop spamming the list.
[arch-general] Syslinux Installer / Update Script - Testers Needed
Hello Community, Over the last few weeks I have been working on Syslinux support for the installer. With the help Thomas and Dieter I am nearing the completion of this project. As part of this project, I have written a script that will help install and update Syslinux (similar to that of grub-install). Some key features of the script: syslinux-install_update.sh * Install Syslinux to the FS + Partition Boot Loader (extlinux --install /boot/syslinux) * Install Syslinux MBR * Detect and optionally set the boot flag on the boot partition * Update Syslinux – copy files and execute (extilnux --update /boot/syslinux) * Support for GPT disks * Support for RAID configurations The goal is to include this script in the official Syslinux package. Therefore we need your help to test it. syslinux-install_update.sh -i -a -m . install Syslinux, set the boot flag (if needed), and install the MBR We need tests for the following setups: / + /boot on the *same* partition / + /boot on the *same* partition - RAID /boot + root on *separate* partition /boot + root on *separate* partition - RAID All of the above using but using the GPT partition layout NOTE: This is an alpha/beta stage script. The script modifies the first 440 bytes of the disk (using dd) and the partition table (using either sfdisk or sgdisk). Although the script should be safe to run, I am not responsible for any data loss that may occur. Let us know the following: * Did the script work for you? * What was your partition setup? (see above) * What version did you use? * If the script did not work, please provide as much information as possible Get the script here: https://gist.github.com/772138 Syslinux Sample Config File: http://projects.archlinux.org/svntogit/packages.git/plain/syslinux/trunk/syslinux.cfg The Syslinux package in testing includes the above configuration file. Cheers, pyther
Re: [arch-general] Syslinux Installer / Update Script - Testers Needed
On 01/19/2011 08:54 AM, Madeye wrote: Just ran the script on my virtualbox archserver. And afterwards on a virtualbox archlinux. Unfortunately it's not working. I get the error: Could not find /boot/syslinux is /boot mounted? Is syslinux installed? I only installed package syslinux and then ran the script. ./syslinux.sh -i -m -a The usage mentions the use of a -c switch, but this does not change anything. Actually I can see it tries to find the path //boot/syslinux when using -c / Guess the switch is only used when you want to install on a mounted chroot system. I am running the script from within the system I wish to install it on. pacman -Q syslinux returns syslinux 4.03-1 The folder /boot/syslinux in reality does not exist in the system yet. So that is probably the reason for the error I get. Is it intentional that the script checks for /boot/syslinux? or should that have been just /boot? If you need additional information, just let me know. BR The script intentionally checks for /boot/syslinux because com32 modules get copied their. Syslinux from testing contains an example config file, /boot/syslinux/syslinux.cfg, therefore creating /boot/syslinux. You can either install the syslinux package from testing or you can mkdir /boot/syslinux and create syslinux.cfg (http://projects.archlinux.org/svntogit/packages.git/plain/syslinux/trunk/syslinux.cfg). Make sure to edit the kernel options (root, nomodeset, etc..) in the config file. pyther
Re: [arch-general] Syslinux Installer / Update Script - Testers Needed
On 01/15/2011 09:52 PM, Matthew Gyurgyik wrote: Hello Community, Over the last few weeks I have been working on Syslinux support for the installer. With the help Thomas and Dieter I am nearing the completion of this project. As part of this project, I have written a script that will help install and update Syslinux (similar to that of grub-install). Some key features of the script: syslinux-install_update.sh * Install Syslinux to the FS + Partition Boot Loader (extlinux --install /boot/syslinux) * Install Syslinux MBR * Detect and optionally set the boot flag on the boot partition * Update Syslinux – copy files and execute (extilnux --update /boot/syslinux) * Support for GPT disks * Support for RAID configurations The goal is to include this script in the official Syslinux package. Therefore we need your help to test it. syslinux-install_update.sh -i -a -m . install Syslinux, set the boot flag (if needed), and install the MBR We need tests for the following setups: / + /boot on the *same* partition / + /boot on the *same* partition - RAID /boot + root on *separate* partition /boot + root on *separate* partition - RAID All of the above using but using the GPT partition layout NOTE: This is an alpha/beta stage script. The script modifies the first 440 bytes of the disk (using dd) and the partition table (using either sfdisk or sgdisk). Although the script should be safe to run, I am not responsible for any data loss that may occur. Let us know the following: * Did the script work for you? * What was your partition setup? (see above) * What version did you use? * If the script did not work, please provide as much information as possible Get the script here: https://gist.github.com/772138 Syslinux Sample Config File: http://projects.archlinux.org/svntogit/packages.git/plain/syslinux/trunk/syslinux.cfg The Syslinux package in testing includes the above configuration file. Cheers, pyther Hello again. I have not received much feedback about this script. Over the last few weeks I have been working on improving this script. Huge thanks to falconindy! He has written code which uses hexdump to determine if a disk is using the GPT partition table and code which detects if a partition is marked as active. Prior to those code I was greping and awking the output of fdisk! Notable Changes * Use hexdump to determine if boot flag is set * Use hexdump to determine partition type (GPT) * Copy/Symlink pci.ids to /boot/syslinux * Lots of rewritten code Much of the detection code has changed. So if you tested before, please test again! Syslinux-install_update: https://gist.github.com/772138 Sample Usage: syslinux-install_update -iam (install, set /boot part(s) as active, install mbr) The syslinux package in testing has a sample config. If you don't want to use the package from testing you can get the config from here: http://projects.archlinux.org/svntogit/packages.git/plain/syslinux/trunk/syslinux.cfg Tell us as much information as possible about your setup (see original message) and whether or not the script worked. Thanks, pyther P.S. Thanks to e36freak who has greatly helped improve my bash syntax and the syntax in this script!
Re: [arch-general] who wants to write me a relatively simple webapp?
On 02/07/2011 06:41 PM, Magnus Therning wrote: On 07/02/11 22:52, Dieter Plaetinck wrote: Hi, for Arch releng, we have recently started automatically building test builds (http://releng.archlinux.org/isos/). These images are built from the archiso and aif git repositories, and the current state of the repos. The idea is that people can test these images, and once in a while, I will promote a set of testbuilds and make them the officially supported media. Because everything evolves all the time, a lot of different things can cause regressions or new bugs, but at the same time it would be too much work to try to test all possible scenarios for each specific testbuild version. So I would like a web application that gives me "a pretty good idea" of the quality of current/recent images. I request someone other then me to make this app for me, I do not have the time. (I do have time for feedback or making adjustments to the codebase you provide) I'm not sure which is best, php or python, or whatever. I think both will be fine (Dan? Pierre?) Basically it would have 2 modes: 1) the "input" mode (after logging in with your wiki or forum account, not sure what's best here. Dan?): the user would select a version (maintain a cached list of the directories at http://releng.archlinux.org/isos/ the format will always be .MM.DD[suffix]) and select a list of options which are verified to be working fine. that is: (between braces are additional instructions for the user) = image arch = * dual, option i686 * dual, option x86_64 * i686 * x86_64 = image type = * core * net = image boot = * optical * usb * pxe = hardware type = * virtualbox * qemu * physical intel i686 * physical intel x86_64 * physical amd i686 * physical amd x86_64 = install type = * automatic install generic example * automatic install fancy example * automatic install custom config (specify in comments) * interactive install = source selection = * net install manual networking config (check that it works + rc.conf, resolv.conf, mirrorlist) * net install dhcp (check that it works + rc.conf) * core = clock = * left as is * reconfigured manually * reconfigured ntp = partitioning/filesystems = * autoprepare (check the installed system, incl fstab) * manual * from config file = fancy stuff (checklist, not selection) = * lvm2 * dm_crypt * softraid * nilfs2 * btrfs (check also fstab, menu.lst, initcpio.conf and crypttab if appropriate) = rollback tested = * yes * no = if rollback done, another partitioning/filesystems list and another "fancy stuff" list (same options as before) for after the rollback = = bootloader = * grub * syslinux * other/manual = result = * everything works fine * something failed (elaborate in comments) = comments = Then, a second interface would need to represent the "current state of things.. (sort of)" that is, for every important thing (like, all image arches, image types, image boots, install types, source selections, clock, partitioning/filesystems, fancy stuff, rollback tested, grub/syslinux bootloader) it needs to show the last recent tests (or the last images for which it worked), along with which user tested it. (note: not all combinations of all variables, just any test with the given variable). if there was any failed test for a specific feature for an as recent (or more recent) image then the last successful one, there should be a warning about that. I'm not sure yet how exactly this page would look like, but basically I need to know all important features are tested with recent images, and that they all performed well. other factors (like hardware type, bootloader other/manual bootloader option) are not very important, they are more for reference. Thanks, Dieter How much are you willing to pay for this piece of bespoke software? /M First: I really, really, hope this was a poor attempt at humour! Second: Please don't top post. http://idallen.com/topposting.html
Re: [arch-general] Howto properly set LD_LIBRARY_PATH to /opt/trinity/lib from PKGBUILD (postbuild)
On 02/07/2011 07:10 PM, David C. Rankin wrote: Guys, After building trinity-kdelibs, I need to create an entry and set LD_LIBRARY_PATH to /opt/trinity/lib. I manually created: '/etc/ld.so.conf.d/trinity.conf' containing "/opt/trinity/lib" and then ran ldconfig. That worked. What I need to know is how to properly do this from the kdelibs PKBUILD. I can do it by creating the file in $pkgdir, but is there a standard way to do it? Also, what about calling ldconfig after install? Is there a standard (post-install) snippet to add? Thanks. Well David lets see this might be a good start: tux:~ $ ls /etc/ld.so.conf.d/ fakeroot.conf lib32-glibc.conf *qt3.conf* *xulrunner.conf* tux:~ $ cat /etc/ld.so.conf.d/qt3.conf /opt/qt/lib tux:~ $ pacman -Qo /etc/ld.so.conf.d/qt3.conf /etc/ld.so.conf.d/qt3.conf is owned by qt3 3.3.8-18 http://projects.archlinux.org/svntogit/packages.git/tree/qt3/trunk/PKGBUILD Look at lines 116 & 117 http://projects.archlinux.org/svntogit/packages.git/tree/xulrunner/trunk/PKGBUILD Look at lines 67 & 68 A little bit of self help could go a long way... pyther
[arch-general] Default Bootloader for AIF
Arch Devs, In November Pierre wrote a mail to arch-dev-public about bootloaders in core. http://mailman.archlinux.org/pipermail/arch-dev-public/2010-November/018445.html Pierre wrote: Summing up my suggestion for some time in the future would be: * move extlinux/syslinux to core/base * move grub1 to extra/multilib and remove it from base group * keep grub2 in extra * maybe also move lilo to extra * of course keep all of them on the install cd Now that there is Syslinux support in AIF, should AIF select Syslinux as the "Default" bootloader? Users are asked to select which bootloader package they would like to install. They can either pick from Grub or Syslinux. Since Grub is listed first it is selected as the "Default". ~pyther
Re: [arch-general] Default Bootloader for AIF
On 03/13/2011 02:44 PM, David Campbell wrote: Excerpts from Matthew Gyurgyik's message of 2011-03-13 14:01:16 -0400: Now that there is Syslinux support in AIF, should AIF select Syslinux as the "Default" bootloader? Does Syslinux play nicely with parted and GPT disklabels? Should Arch be trying to move toward a default bootloader that seamlessly supports GPT disklabels? Yes, Syslinux supports GPT as does the syslinux-install_update script that is included in the arch package. With the issues stated in Pierre's mail about grub1 I think it makes sense to make Syslinux the "default". However, I want to know what the devs think as the "default" bootloader will likely have more new users using it.
Re: [arch-general] Default Bootloader for AIF
On 04/04/2011 12:04 AM, Brendan Long wrote: On 03/27/2011 01:47 AM, KESHAV P.R. wrote: On a side note, I think it is also useful to have GPT partitioning as default now since it is way superior to MBR (see logical partitions linked-list info) and supports multiple primary partitions. I'm not sure that it's a good idea to make GPT the default any time soon, since most tools don't support it very well yet, and most versions of Windows won't boot of it (much as I hate holding things back for worse operating systems, having a default that makes it impossible to boot Windows seems like a bad idea). Having it available in the installer would be really nice though. Even just including gdisk and syslinux on the install disk would make things a lot easier in some situations. FYI the installer/live installer already includes gptfdisk (gdisk) and syslinux. I don't believe that "lets worry about windows" is a good argument. If a user is installing arch they should be able to read documentation and determine which is the best for them MBR or GPT.
Re: [arch-general] [signoff] kernel26-2.6.38.2-1
On Mon, 4 Apr 2011 10:08:09 +0200, Adrian C. wrote: On Thu, 31 Mar 2011, Tobias Powalowski wrote: Hi guys, please signoff 2.6.38 series for both arches. Can't signoff i686. LILO can not boot it. # /sbin/lilo -v ... Fatal: Setup length exceeds 31 maximum; kernel setup will overwrite boot loaer Machines would be left in a constant state of reboot if it is missed by a user. I don't think Lilo should be a show stopper. Use a more modern bootloader such as Syslinux (if you want simple), Grub 1 or Grub 2.
Re: [arch-general] [signoff] kernel26-2.6.38.2-1
On 04/04/2011 03:08 PM, Adrian C. wrote: On Mon, 4 Apr 2011, Matthew Gyurgyik wrote: > I don't think Lilo should be a show stopper. Use a more modern > bootloader such as Syslinux (if you want simple), Grub 1 or Grub 2. Modern, like grub? LILO is in [core], and is actively being developed. It was also a part of the Arch installation from which i got it in the first place. Now, I agree it doesn't have to be a show stopper, but some serious warnings are needed at least. There are many more users out there, be sure of that. In fact, here they are already, saying pretty much the same things I am going to say below: https://bbs.archlinux.org/viewtopic.php?id=116077 Grub1 is considered obsolete? It has bugs, lacks features, it has many forks, all of them now pretty much forgotten. Last time I considered grub2 it was still "development grade" and I also got a feeling of frequent user problems from the list, bug tracker and BBS. LILO on the other hand never failed to boot. I would never trade LILO for grub, but I am contemplating a switch to syslinux since I saw a video of Dieter's talk at FOSDEM. > Just out of interest, are you only booting this kernel with lilo or > others too? Just LILO, I haven't tried grub, but did wrote a menu.lst in advance if I had to. -- Adrian C. (anrxc) | anrxc..sysphere.org | PGP ID: D20A0618 PGP FP: 02A5 628A D8EE 2A93 996E 929F D5CB 31B7 D20A 0618 Didn't realize that Lilo was still being developed. A lot of people seem to think Syslinux is older than pie too! I would highly encourage looking at Syslinux. It has a simple configuration like Lilo and it is as light or heavy as you want to make it. Without any com32 modules you are given just a boot prompt and you can load the menu.c32 (basic menu like lilo) or vesamenu.c32 modules. Also, you can edit the boot parameters on the fly and modify the config without updating Syslinux.
Re: [arch-general] Gnome 3 + KDE 4 are both large disappointments.
On 04/10/2011 03:50 PM, Dennis Beekman wrote: I use linux becuase i think that windows is just to bloated to even be considered ... but lately Linux has been going in the same direction when it comes to the desktop enviroments Gnome 3 & KDE 4. Gnome 2 was brilliant just a simple easy to use system with load off good looking features, gnome 3 however is useless in all respects as far as i can tell from whats in testing. 1. You cannot change the panels anymore you stuck with the 2 given by gnome 3. 2. Changing themes also is inpossible.. or so it seems. 3. Why do we need a system settings menu with all the options in one menu ? where are my seperate icons i love so much ? why can we choose wich icons or options we want ? 4. What about the people ho don't have or don't wich to use they're video hardware to run the these stupid graphics ... are we stuck with "fallback mode" wich is even more stupid and backward ? 5 Where did all the nice applets go ? and why can i not add them to my taskbar anymore [flaming] I though KDE 4 was bad and bloated and that i couldn't get any worse... it seems i was wrong. Boy this new Gnome version is even more bloated and buggy then KDE 4 wich is quite the atchievement from the gnome team... Now i finnaly understand why the Ubuntu guys decided to use they're netbook unity system rather then this shit, eventhough unity sucks it better then Gnome 3 in all respects. [/flaming] Can we not just keeps using the old version and ignore the new version of gnome for now until they get they act together ? or hopefully decide to go back to the old interface and develop that further instead ... Sir, 1. Get a Blog 2. Next time, please create a new mail, instead of replying to an existing thread and changing the topic In terms of Arch: *To answer your question, no gnome 3 is staying and we wont see gnome2 in the official repos. There is nothing than prevents you or someone else from creating a unofficial gnome2 repo. In terms of Upstream: *Seems as if upstream doesn't care much about gnome2 any more... you or someone else can fork it ~pyther
Re: [arch-general] Gnome3 and Gnome2
On 04/10/2011 09:02 PM, Nephyrin Zey wrote: I think removing Gnome2 from arch's repositories would be a mistake. Even gentoo is maintaining gnome2 support until "At least Gnome 3.2". If myself and others volunteered to help maintain a [gnome2] repo, would it be considered for official mirrorage? - Neph Answer: It breaks the flow of the conversation Question: Why is topping posting bad? To answer your question, no. You'd have to find your own mirrors to host a gnome2 repo and it would be considered unofficial.
Re: [arch-general] trinity-kdevelop corrupted
On 04/26/2011 11:51 AM, vilares wrote: Hi, I'm tring to install kde from: http://www.kiwilight.com/trinity/i686/ During instalation following error appears: "File trinity-kdevelop-1222477-1-i686.pkg.tar.xz is corrupted. Do you want to delete it? [Y/n]" Is this file correct, or is it something on my side? BR, Mateusz This is very offtopic for the list. Please contact the maintainer of the *unofficial* repo privately.
Re: [arch-general] [arch-dev-public] [signoff] initscripts-2011.04.1-2
On 04/29/2011 06:46 AM, Heiko Baums wrote: Am Fri, 29 Apr 2011 11:02:22 +0200 schrieb Thomas Bächler: Every recent operating system I know can handle UTC, even Windows Vista (bugs before SP1, works with SP1 or later) and Windows 7, and Windows XP is so old, it shouldn't be used anyway. But there's a problem with Windows. Updating Windows is not as easy for everybody as Linux is. There's a substantial buying resistance. So most Windows users stay with their Windows version they once bought their whole life, at least for the whole lifetime of their computer. And as far as I know Windows XP shall be much better than Windows Vista. Heiko I'm with Thomas here. If it bugs you that much submit some patches. It seems as if you always have an opinion, but rarely have a solution and/or patches. Folks, don't forget, arch isn't a democracy. The developers do what they want. pyther
Re: [arch-general] Ethernet stopped working after update
On 06/26/2011 08:32 PM, Damjan wrote: 2: eth0: mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 link/ether 00:30:67:8f:7c:a8 brd ff:ff:ff:ff:ff:ff Which maybe means something to someone. ;) means it's configured to be up, but it doesn't sense an ethernet connectivity. Check the cables, and the kernel driver. Sounds like you might have the same problem as me and a few others... https://bugzilla.kernel.org/show_bug.cgi?id=33782
Re: [arch-general] Waking from Suspend by Keyboard Activity
On 09/08/2011 01:49 PM, Bastien Dejean wrote: Hi, How can I let my USB keyboard be a waker? I tried to add echo USB0> /proc/acpi/wakeup to rc.local but, after boot, /proc/acpi/wakeup doesn't contain any USB related line. Regards, I'm not sure how much you've played with /proc/acpi/wakeup but I wrote about this in my blog a year and half ago. The short and sweet: try the different devices. dmesg can be useful for identifying them (see the blog post). http://pyther.net/blog/index.php/2010/03/use-keyboard-to-resume-from-standby/ ~pyther
Re: [arch-general] [signoff] linux-3.0.6-2
On 10/07/2011 08:26 AM, Tobias Powalowski wrote: Latest kernel is in testing, - fixed archiso support - revert to performance governor please signoff both arches, greetings tpowa Looked in the tracker and didn't see anything. Just curious, why are we reverting back to the performance governor? ~pyther
Re: [arch-general] [arch-dev-public] nvidai 285.05.09 and xorg-server 1.11.1
On 10/10/2011 04:56 AM, Jan de Groot wrote: I have decided to revert this commit in our packages. There's a 1.11-2 package with some additional upstream patches and this reverted commit on its way to testing. If nobody has any objections, I'd like to move this to extra tomorrow. I had issues with 1.11-1 (nvidia 9400 GT). No problems with -2. For what it's worth, I have no objections. ~pyther
Re: [arch-general] [arch-dev-public] syslinux 5.00 in [testing]
On 12/08/2012 06:37 AM, Tobias Powalowski wrote: Hi, seems syslinux changed some things more than I expected, could thomas or gerado look at the changes? http://www.syslinux.org/archives/2012-December/018747.html I don't have time this afternoon. If it keeps broken, I'll remove it this evening from testing repository. greetings tpowa The default modules that we place into /boot (menu.c32 vesamenu.c32 chain.c32 hdt.c32 reboot.c32 poweroff.com) depend on libutil_com.c32, libcom32.c32, libmenu.c32, libcom32gpl.c32 (new with syslinux 5.0) The syslinux-install_update script will need to be updated to include these extra modules. I will provide a patch in the next day or two, since I'm the original author. Simply adding the new modules to the script should work, but I want to test the following (thus the delay for the patch): 1) upgrade from syslinux4 -> syslinux5 2) new install using syslinux 5 Regards, Matthew Gyurgyik
Re: [arch-general] [arch-dev-public] syslinux 5.00 in [testing]
On 12/08/2012 10:59 AM, Matthew Gyurgyik wrote: On 12/08/2012 06:37 AM, Tobias Powalowski wrote: Hi, seems syslinux changed some things more than I expected, could thomas or gerado look at the changes? http://www.syslinux.org/archives/2012-December/018747.html I don't have time this afternoon. If it keeps broken, I'll remove it this evening from testing repository. greetings tpowa The default modules that we place into /boot (menu.c32 vesamenu.c32 chain.c32 hdt.c32 reboot.c32 poweroff.com) depend on libutil_com.c32, libcom32.c32, libmenu.c32, libcom32gpl.c32 (new with syslinux 5.0) The syslinux-install_update script will need to be updated to include these extra modules. I will provide a patch in the next day or two, since I'm the original author. Simply adding the new modules to the script should work, but I want to test the following (thus the delay for the patch): 1) upgrade from syslinux4 -> syslinux5 2) new install using syslinux 5 Regards, Matthew Gyurgyik Unfortunately I have been battling a cold all weekend and have not had time to look into this. Like I said the change should be fairly simple, and I will attempt to get a patch (tested) out by mid-week. Matthew Gyurgyik
Re: [arch-general] [arch-dev-public] syslinux 5.00 in [testing]
On 12/08/2012 10:59 AM, Matthew Gyurgyik wrote: On 12/08/2012 06:37 AM, Tobias Powalowski wrote: Hi, seems syslinux changed some things more than I expected, could thomas or gerado look at the changes? http://www.syslinux.org/archives/2012-December/018747.html I don't have time this afternoon. If it keeps broken, I'll remove it this evening from testing repository. greetings tpowa The default modules that we place into /boot (menu.c32 vesamenu.c32 chain.c32 hdt.c32 reboot.c32 poweroff.com) depend on libutil_com.c32, libcom32.c32, libmenu.c32, libcom32gpl.c32 (new with syslinux 5.0) The syslinux-install_update script will need to be updated to include these extra modules. I will provide a patch in the next day or two, since I'm the original author. Simply adding the new modules to the script should work, but I want to test the following (thus the delay for the patch): 1) upgrade from syslinux4 -> syslinux5 2) new install using syslinux 5 Regards, Matthew Gyurgyik Below you will find the links to the patches for the syslinux-install_update script, PKGBUILD, and syslinux.cfg During an install, the syslinux-install_update script will copy all .c32 modules to /boot/syslinux. This is recommended by upstream [1]. The size cost is minimal, 996K. For updates, I added an array called core_modules. During an update, we only copy modules that already exist in /boot/syslinux. However, if any core_module does not exist in /boot/syslinux it will be copied/symlinked. With these modifications, when a user upgrades from 4.06 -> 5.00, ldlinux.c32 will be copied/symlinked to /boot/syslinux as it is core_module. Other modules such as libutil_com.c32 and libcom32.c32 will not be copied/linked. On boot, if a menu is being used, the menu will fail to load (missing depends: libutil_com.c32, etc...). However, the user will be given a syslinux shell they can boot by entering a label that corresponds to a defined label in syslinux.cfg. A post_install message or a news item suggesting users to copy / symlink all modules to /boot/syslinux would be ideal. Users who miss this message, will still be able to boot, but instead of the menu loading, they will be dropped to a syslinux shell (as explained above). cp /usr/lib/syslinux/*.c32 /boot/syslinux (/ and /boot on seperate fs) or ln -s /usr/lib/syslinux/*.c32 /boot/syslinux (/ and /boot on same fs) In my opinion, we shouldn't add new modules during an update to /boot/syslinux unless, without, the module, the system becomes unbootable. The rational here being - the user knows best. Lastly, since com modules are no longer supported and no one has ported poweroff.com, I have removed the poweroff section from the syslinux.cfg [2]. Patches: http://pyther.net/a/syslinux-5.00-patches-v1/PKGBUILD.diff http://pyther.net/a/syslinux-5.00-patches-v1/syslinux-install_update.patch http://pyther.net/a/syslinux-5.00-patches-v1/syslinux.cfg.patch [1] "In general, unless you have a reason *not* to install all the .c32 files, it is probably a good idea." - hpa [2] #syslinux @freenode: pyther : Hello. Is there a poweroff module for syslinux 5? Ady2 : pyther: no. all .com modules are not supported in 5.00. someone needs to create a new poweroff.c32 compatible with 5.00. Regards, Matthew Gyurgyik
Re: [arch-general] [arch-dev-public] syslinux update to 5.01
On 01/31/2013 12:49 PM, Tobias Powalowski wrote: Am 31.01.2013 18:43, schrieb Pierre Schmitz: Am 31.01.2013 16:09, schrieb Tobias Powalowski: Hi, ok syslinux 5.0 series should come to testing again. The problem with this release: You need to copy all .c32 modules to your /boot/syslinux path. - Those who used our shipped install script, will end up in a none menu based syslinux shell. As long as we ship this install script we should maintain it. So this script needs to be altered to copy the needed files. The script has already been modified to at least to syslinux shell. If it should do more, Pyther needs to change it. greetings tpowa I'll copy and paste from my previous message (Re: [arch-dev-public] syslinux 5.00 in [testing]). - Below you will find the links to the patches for the syslinux-install_update script, PKGBUILD, and syslinux.cfg During an install, the syslinux-install_update script will copy all .c32 modules to /boot/syslinux. This is recommended by upstream [1]. The size cost is minimal, 996K. For updates, I added an array called core_modules. During an update, we only copy modules that already exist in /boot/syslinux. However, if any core_module does not exist in /boot/syslinux it will be copied/symlinked. With these modifications, when a user upgrades from 4.06 -> 5.00, ldlinux.c32 will be copied/symlinked to /boot/syslinux as it is core_module. Other modules such as libutil_com.c32 and libcom32.c32 will not be copied/linked. On boot, if a menu is being used, the menu will fail to load (missing depends: libutil_com.c32, etc...). However, the user will be given a syslinux shell they can boot by entering a label that corresponds to a defined label in syslinux.cfg. A post_install message or a news item suggesting users to copy / symlink all modules to /boot/syslinux would be ideal. Users who miss this message, will still be able to boot, but instead of the menu loading, they will be dropped to a syslinux shell (as explained above). cp /usr/lib/syslinux/*.c32 /boot/syslinux (/ and /boot on seperate fs) or ln -s /usr/lib/syslinux/*.c32 /boot/syslinux (/ and /boot on same fs) In my opinion, we shouldn't add new modules during an update to /boot/syslinux unless, without the module, the system becomes unbootable. The rational here being - the user knows best. Lastly, since com modules are no longer supported and no one has ported poweroff.com, I have removed the poweroff section from the syslinux.cfg [2]. Patches: http://pyther.net/a/syslinux-5.00-patches-v1/PKGBUILD.diff http://pyther.net/a/syslinux-5.00-patches-v1/syslinux-install_update.patch http://pyther.net/a/syslinux-5.00-patches-v1/syslinux.cfg.patch [1] "In general, unless you have a reason *not* to install all the .c32 files, it is probably a good idea." - hpa [2] #syslinux @freenode: pyther : Hello. Is there a poweroff module for syslinux 5? Ady2 : pyther: no. all .com modules are not supported in 5.00. someone needs to create a new poweroff.c32 compatible with 5.00. Regards, Matthew Gyurgyik
[arch-general] patch for syslinux install script
There is a slight change in behaviour. When preforming an update, all
c32 modules in /usr/lib/syslinux/bios/ will get copied/symlinked.
Previously we only updated/copied modules that were already in
/boot/syslinux.
Patches can also be found here:
http://pyther.net/archlinux/syslinux/6/20130706/
Matthew Gyurgyik
PKGBUILD:
--- /tmp/syslinux/PKGBUILD 2013-07-06 08:55:21.0 -0400
+++ syslinux/PKGBUILD 2013-07-06 07:45:18.811510802 -0400
@@ -4,7 +4,7 @@
pkgname="syslinux"
pkgver="6.01"
-pkgrel="2"
+pkgrel="3"
arch=('x86_64' 'i686')
pkgdesc="Collection of boot loaders that boot from FAT, ext2/3/4 and
btrfs filesystems, from CDs and via PXE"
url="http://syslinux.zytor.com/";
@@ -29,62 +29,62 @@ source=("https://www.kernel.org/pub/linu
sha1sums=('d7bc1b188677f77ac2d7060d25491dc29877a9c4'
'b0f174bcc0386fdf699e03d0090e3ac841098010'
- 'b1d915045fe3094f5359df043c53e73a4dc32745')
+ '2a7c1abe9816f6f702f425499a10582eebf94632')
_build_syslinux_bios() {
-
+
rm -rf "${srcdir}/${pkgname}-${pkgver}-bios/" || true
cp -r "${srcdir}/${pkgname}-${pkgver}"
"${srcdir}/${pkgname}-${pkgver}-bios"
cd "${srcdir}/${pkgname}-${pkgver}-bios/"
-
+
## Do not try to build syslinux with our default LDFLAGS, it will fail
unset LDFLAGS
-
+
make PYTHON="python2" bios
make PYTHON="python2" bios installer
-
+
}
_build_syslinux_efi64() {
-
+
rm -rf "${srcdir}/${pkgname}-${pkgver}-efi64/" || true
cp -r "${srcdir}/${pkgname}-${pkgver}"
"${srcdir}/${pkgname}-${pkgver}-efi64"
cd "${srcdir}/${pkgname}-${pkgver}-efi64/"
-
+
## Unset all compiler FLAGS for efi64 build
unset CFLAGS
unset CPPFLAGS
unset CXXFLAGS
unset LDFLAGS
unset MAKEFLAGS
-
+
make PYTHON="python2" efi64
make PYTHON="python2" efi64 installer
-
+
}
_build_syslinux_efi32() {
-
+
rm -rf "${srcdir}/${pkgname}-${pkgver}-efi32/" || true
cp -r "${srcdir}/${pkgname}-${pkgver}"
"${srcdir}/${pkgname}-${pkgver}-efi32"
cd "${srcdir}/${pkgname}-${pkgver}-efi32/"
-
+
## Unset all compiler FLAGS for efi32 build
unset CFLAGS
unset CPPFLAGS
unset CXXFLAGS
unset LDFLAGS
unset MAKEFLAGS
-
+
make PYTHON="python2" efi32
make PYTHON="python2" efi32 installer
-
+
}
build() {
-
+
cd "${srcdir}/${pkgname}-${pkgver}/"
-
+
## Do not try to build the Windows or DOS installers and DIAG files
sed 's|diag libinstaller dos win32 win64 dosutil txt|libinstaller
txt|g' -i "${srcdir}/${pkgname}-${pkgver}/Makefile" || true
sed 's|win32/syslinux.exe win64/syslinux64.exe||g' -i
"${srcdir}/${pkgname}-${pkgver}/Makefile" || true
@@ -92,73 +92,73 @@ build() {
sed 's|dos/syslinux.com||g' -i
"${srcdir}/${pkgname}-${pkgver}/Makefile" || true
sed 's|INSTALLSUBDIRS = com32 utils dosutil|INSTALLSUBDIRS = com32
utils|g' -i "${srcdir}/${pkgname}-${pkgver}/Makefile" || true
sed 's|install -m 644 -c $(INSTALL_DIAG)
$(INSTALLROOT)$(DIAGDIR)|# install -m 644 -c $(INSTALL_DIAG)
$(INSTALLROOT)$(DIAGDIR)|g' -i "${srcdir}/${pkgname}-${pkgver}/Makefile"
|| true
-
+
## Fix FHS manpage path
sed 's|/usr/man|/usr/share/man|g' -i
"${srcdir}/${pkgname}-${pkgver}/mk/syslinux.mk" || true
-
+
## Build syslinux-efi
if [[ "${CARCH}" == "x86_64" ]]; then
_build_syslinux_efi64
fi
-
+
if [[ "${CARCH}" == "i686" ]]; then
_build_syslinux_efi32
fi
-
+
## Build syslinux-bios
_build_syslinux_bios
-
+
}
_package_syslinux_bios() {
-
+
cd "${srcdir}/${pkgname}-${pkgver}-bios/"
-
+
## Install Syslinux bios
make INSTALLROOT="${pkgdir}/" AUXDIR="/usr/lib/syslinux/bios/"
bios install
-
+
## Remove syslinux.exe,syslinux64.exe,syslinux.com and dosutil dir
rm "${pkgdir}/usr/lib/syslinux/bios"/syslinux.{com,exe} || true
rm "${pkgdir}/usr/lib/syslinux/bios/syslinux64.exe" || true
rm -rf "${pkgdir}/usr/lib/syslinux/bios/dosutil/" || true
-
+
## Remove com32 and diag dirs
rm -rf "${pkgdir}/usr/lib/syslinux/bios/diag/" || true
rm -rf "${pkgdir}/usr/lib/syslinux/bios/com32/" || true
-
+
## Move extlinux binary to /usr/bin
install -d "${pkgdir}/usr/bin"
mv "${pkgdir}/sbin/extlinux" "${pkgdir}/usr/bin/extlinux"
rm -rf "${pkgdir}/sbin/"
-
+
## Install docs
install -d "${pkgdir}/usr/
