Re: [arch-general] [pacman-dev] pyqt packages confusion
On Sunday 08 May 2011 02:52:26 kachelaqa wrote: by pyqt developers, do you mean phil thompson, the author/maintainer of pyqt? Yes. Also see https://bugs.archlinux.org/task/22391 and http://www.riverbankcomputing.com/pipermail/pyqt/2011-January/thread.html -- Andrea
Re: [arch-general] [pacman-dev] pyqt packages confusion
On Sun, May 08, 2011 at 02:15:51AM +0200, Andrea Scarpino wrote: I changed this because we are going to remove python2 a day. Are you serious? Do you really want to get rid of python2? That's impossible. Python Wiki[1] says: The downside of breaking backwards compatibility in 3.x is that a lot of that [quality] software doesn't work on 3.x yet. [1]: http://wiki.python.org/moin/Python2orPython3 Should I use Python 2 or Python 3 for my development activity? -- Cheers, -- Kwpolska (http://kwpolska.co.cc) O ascii ribbon campaign - stop html mail - www.asciiribbon.org pgpHua5SIWTis.pgp Description: PGP signature
Re: [arch-general] Drop non-free ?! (Was: Commit in ffmpeg/trunk)
On 8 May 2011 02:43, Ionut Biru ib...@archlinux.org wrote: now i understand the question. It won't be removed. I did it for ffmpeg because it has a big warning after ./configure License: nonfree and unredistributable How are we keeping FAAC/FAAD2 in [extra] then? If we redistribute FAAC/FAAD2 (which are redistributed in source form via sourceforge), then we shouldn't have problems building other stuff with them. There are questionable patent infringements and possibilities, but all upstream (in this case) does is remain on the safe side by not providing any binaries themselves, since they would be liable first. FFMPEG follows suit by displaying warnings, which is useful to distributors who have strict packaging policies (like Ubuntu with their multiverse repository). -- GPG/PGP ID: 8AADBB10
Re: [arch-general] [pacman-dev] pyqt packages confusion
On 8 May 2011 17:59, Andrea Scarpino and...@archlinux.org wrote: On Sunday 08 May 2011 11:06:14 Kwpolska wrote: Are you serious? Do you really want to get rid of python2? That's Why are you trolling guys? I said a day, not tomorrow. Why the python3 version has to depend on python2, if we remove python2 in the year 2030? I believe what you meant is one day, or more precisely, one fine day in the future :) Anyway, would it not be possible to provide a pyqt-common package instead of making one depend on the other? -- GPG/PGP ID: 8AADBB10
Re: [arch-general] [arch-dev-public] Anyone want to maintain acpid?
For some reason, I am assigned as a maintainer for acpid, but I never actually touched it. It is out of date and has a number of bugs. Any takers? I though this had been deprecated for years? Are there still some relevant use cases? If so, there is a new version in AUR: https://aur.archlinux.org/packages.php?ID=33871. People still use it. What has been deprecated is the /proc/acpi/event interface. Though, most acpi events are now translated to input events. Even when they are, acpid still has its use to handle these events on a system level, no matter if you have a user session (*DE) running or if you even have X running. My use case is to handle the suspend and hibernate buttons. -- дамјан
Re: [arch-general] Pruning the bugtracker
On Wed, 4 May 2011 20:43:27 +0200, JM wrote: I have browsed through all High and Medium severity bugreports and categorized some of them here: https://wiki.archlinux.org/index.php/User:Fijam . Maybe we should also consider a more aggressive approach. There are currently more than 600 open bugs. Instead of reviewing each of them we could look for a way to automatically close quite old bugs and ask the reporter to request a re-open if the bug is still valid. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-general] [pacman-dev] pyqt packages confusion
On 08/05/11 14:01, kachelaqa wrote: On Sunday 08 May 2011 02:52:26 kachelaqa wrote: by pyqt developers, do you mean phil thompson, the author/maintainer of pyqt? Yes. Also see https://bugs.archlinux.org/task/22391 and http://www.riverbankcomputing.com/pipermail/pyqt/2011-January/thread.html thanks for the links i assume the thread from the pyqt mailing-list is this one: http://www.riverbankcomputing.com/pipermail/pyqt/2011-January/029094.html that mainly discusses various sip issues, but i cannot see any discussion about compatibility regarding pyuic, pyrcc, etc for clarity, i have now asked a more specific question here: http://www.riverbankcomputing.com/pipermail/pyqt/2011-May/029791.html the maintainer of pyqt has now confirmed that pyuic is compatible between python 2 and 3. nevertheless, i still think it is an ugly solution to have python3 as a dependency of a python2 package. many users will have removed python3 from their systems, as there are currently relatively few other packages that depend on it.
Re: [arch-general] [arch-dev-public] Anyone want to maintain acpid?
On 8 May 2011 14:52, Damjan gdam...@gmail.com wrote: For some reason, I am assigned as a maintainer for acpid, but I never actually touched it. It is out of date and has a number of bugs. Any takers? I though this had been deprecated for years? Are there still some relevant use cases? If so, there is a new version in AUR: https://aur.archlinux.org/packages.php?ID=33871. People still use it. What has been deprecated is the /proc/acpi/event interface. Though, most acpi events are now translated to input events. Even when they are, acpid still has its use to handle these events on a system level, no matter if you have a user session (*DE) running or if you even have X running. My use case is to handle the suspend and hibernate buttons. -- дамјан Yup, I use acpid for suspend functions bound to button and lid events as well as running scripts depending if on ac or power. -- Jason Steadman http://www.meyithi.com/ http://twitter.com/meyithi
[arch-general] Display Manager rc.d scripts
Hello, can anyone think of a reason the rc.d scripts are added to kdm, gdm and slim? They are not recommended by anyone they are to be blame for occasional weird problems. The standard and IMO only way is to start them from inittab. They dont come from upstream i dont know when they were added, i remember them being there ever since i started using Arch, they may come from CRUX or something. I am considering requesting them removal from all display managers. In [0] Pierre said some people want to keep them for backwards compatibility. Backwards compatibility is desired only when something works correctly. Thoughts? [0]: https://bugs.archlinux.org/task/20109 -- () against html e-mail | usenet email communication netiquette /\ www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
Re: [arch-general] Display Manager rc.d scripts
On Sun, May 8, 2011 at 12:19 PM, Grigorios Bouzakis grb...@xsmail.com wrote: Hello, can anyone think of a reason the rc.d scripts are added to kdm, gdm and slim? They are not recommended by anyone they are to be blame for occasional weird problems. The standard and IMO only way is to start them from inittab. They dont come from upstream i dont know when they were added, i remember them being there ever since i started using Arch, they may come from CRUX or something. I am considering requesting them removal from all display managers. In [0] Pierre said some people want to keep them for backwards compatibility. Backwards compatibility is desired only when something works correctly. Thoughts? [0]: https://bugs.archlinux.org/task/20109 -- () against html e-mail | usenet email communication netiquette /\ www.asciiribbon.org | www.netmeister.org/news/learn2quote.html I agree with you and you bring up a valid point. We should be using only one system if the other one doesn't provide any useful benefits. Also, what is meant by backwards compatible backwards compatible with what?
Re: [arch-general] Display Manager rc.d scripts
On Sun, May 8, 2011 at 7:19 PM, Grigorios Bouzakis grb...@xsmail.com wrote: Hello, can anyone think of a reason the rc.d scripts are added to kdm, gdm and slim? They are not recommended by anyone they are to be blame for occasional weird problems. The standard and IMO only way is to start them from inittab. They dont come from upstream i dont know when they were added, i remember them being there ever since i started using Arch, they may come from CRUX or something. I am considering requesting them removal from all display managers. In [0] Pierre said some people want to keep them for backwards compatibility. Backwards compatibility is desired only when something works correctly. Thoughts? While I don't have a firm opinion about this, I tend to disagree with you. I have always been using the rc.d scripts and find they work fine. We don't really implement runlevels in Arch, so the half-way approach of using the runlevels to control only one daemon seems strange to me. Why is kdm/gdm/slim different from all the othe daemons we have. How would you make sure e.g. kdm was started before (or after) another daemon if you use the runlevel approach? The specific bug you pointed out is not particular to KDM/GDM/slim, but should be fixed for all daemons (proper inheritance of LOCALE), and it is on our TODO list. Just my two cents, -t
Re: [arch-general] Display Manager rc.d scripts
On Sun, May 08, 2011 at 07:53:49PM +0200, Tom Gundersen wrote: How would you make sure e.g. kdm was started before (or after) another daemon if you use the runlevel approach? If you use the runlevel approach, DMs start after all DAEMONS. This is usually the right behavior. You start DBUS and other crap and then go for Xorg. -- -- Kwpolska (http://kwpolska.co.cc) stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html GPG KEY: 5EAAEA16 | Arch Linux x86_64, zsh, mutt, vim. pgppNYURbK9uD.pgp Description: PGP signature
Re: [arch-general] Display Manager rc.d scripts
While I don't have a firm opinion about this, I tend to disagree with you. I have always been using the rc.d scripts and find they work fine. As far as I know the only problem that the daemon method has is the boot to runlevel S to fix problem. So if you edit your xorg.conf file impropelly, so that its contains errors, or you get powerloss during update/install f X components, so that the xorg cant start. You need to boot into single-user mode so that you can remove ?gdm? from daemons list, so that you can boot propelly to console. If your xorg wont start on boot you wont get a console, only a infinite loop of xorg trying to start. But if you use runlevel 5 for ?gdm? it will only try to start the xorg 5 times and if it fails it will fall back to console, so that you ?can? fix the problem. :D -- (\_ /) copy the bunny to your profile (0.o ) to help him achieve world domination. ( ) come join the dark side. /_|_\ (we have cookies.)
Re: [arch-general] Display Manager rc.d scripts
On Sun, May 08, 2011 at 08:05:34PM +0200, Kwpolska wrote: On Sun, May 08, 2011 at 07:53:49PM +0200, Tom Gundersen wrote: How would you make sure e.g. kdm was started before (or after) another daemon if you use the runlevel approach? If you use the runlevel approach, DMs start after all DAEMONS. This is usually the right behavior. You start DBUS and other crap and then go for Xorg. But it's still added complication to a system that is simple and not very contentious[1]. /M [1] As an Arch user for a couple of years this is the first time I've heard using runlevels being suggested. -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay pgprDYRSad5zL.pgp Description: PGP signature
Re: [arch-general] Display Manager rc.d scripts
Am Sun, 8 May 2011 19:53:49 +0200 schrieb Tom Gundersen t...@jklm.no: While I don't have a firm opinion about this, I tend to disagree with you. I have always been using the rc.d scripts and find they work fine. We don't really implement runlevels in Arch, so the half-way approach of using the runlevels to control only one daemon seems strange to me. Why is kdm/gdm/slim different from all the othe daemons we have. How would you make sure e.g. kdm was started before (or after) another daemon if you use the runlevel approach? kdm etc. should only be started as the last rc script as far as I know, at least it doesn't make much sense to start it before other scripts. The same is done with the inittab method. The reason why I prefer and need the inittab method is if there are issues with xorg which prevents from switching to a text console which already happened in the past. With the rc scripts it's only possible to having started xorg at boot time if the script is in the DAEMONS array. So if xorg fails for a reason and doesn't allow you to switch to console you need a LiveCD to first remove it from the DAEMONS to be able to use the system again. With the inittab method you can easily add two entries to the bootloader's config. One which boots into runlevel 3 and one which boots into runlevel 5. So if xorg makes problems you still can easily boot into the text console and fix the problem. And it doesn't make any difference if you start or stop xorg at runtime by running `/etc/rc.d/kdm stop` resp. `/etc/rc.d/kdm start` or `telinit 3` resp. `telinit 5`. So the inittab method must be kept while I don't have an opinion whether the rc scripts shall be kept or not. Heiko
Re: [arch-general] Display Manager rc.d scripts
Am Sun, 8 May 2011 21:08:39 +0300 schrieb jesse jaara jesse.ja...@gmail.com: But if you use runlevel 5 for ?gdm? it will only try to start the xorg 5 times and if it fails it will fall back to console, so that you ?can? fix the problem. :D Unfortunately there's no automatic fall back to console (runlevel 3), at least not in any case. Heiko
Re: [arch-general] Display Manager rc.d scripts
Am Sun, 8 May 2011 19:10:59 +0100 schrieb Magnus Therning mag...@therning.org: [1] As an Arch user for a couple of years this is the first time I've heard using runlevels being suggested. Isn't this recommended in the Beginner's Guide or somewhere else in the Wiki? Heikol
Re: [arch-general] Display Manager rc.d scripts
On Sun, May 08, 2011 at 08:15:27PM +0200, Heiko Baums wrote: Am Sun, 8 May 2011 19:53:49 +0200 schrieb Tom Gundersen t...@jklm.no: While I don't have a firm opinion about this, I tend to disagree with you. I have always been using the rc.d scripts and find they work fine. We don't really implement runlevels in Arch, so the half-way approach of using the runlevels to control only one daemon seems strange to me. Why is kdm/gdm/slim different from all the othe daemons we have. How would you make sure e.g. kdm was started before (or after) another daemon if you use the runlevel approach? kdm etc. should only be started as the last rc script as far as I know, at least it doesn't make much sense to start it before other scripts. The same is done with the inittab method. The reason why I prefer and need the inittab method is if there are issues with xorg which prevents from switching to a text console which already happened in the past. With the rc scripts it's only possible to having started xorg at boot time if the script is in the DAEMONS array. So if xorg fails for a reason and doesn't allow you to switch to console you need a LiveCD to first remove it from the DAEMONS to be able to use the system again. Another, arguably easier solution is to pass 'init=/bin/bash' in order to get a terminal to modify DAEMONS. But that's not pertinent to this discussion. With the inittab method you can easily add two entries to the bootloader's config. One which boots into runlevel 3 and one which boots into runlevel 5. So if xorg makes problems you still can easily boot into the text console and fix the problem. This has actually never happened to me, but I can imagine the irritation. Is there really no way to make the /etc/rd.c-script fail and return the user to a terminal if xorg (or the display manager) fails? And it doesn't make any difference if you start or stop xorg at runtime by running `/etc/rc.d/kdm stop` resp. `/etc/rc.d/kdm start` or `telinit 3` resp. `telinit 5`. So the inittab method must be kept while I don't have an opinion whether the rc scripts shall be kept or not. I think the argument of OP was that the inittab method should be the *only* method. If both methods are available, which one should be the default? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay pgpT9sFwtdkhD.pgp Description: PGP signature
Re: [arch-general] Display Manager rc.d scripts
On Sun, May 8, 2011 at 8:05 PM, Kwpolska kwpol...@gmail.com wrote: On Sun, May 08, 2011 at 07:53:49PM +0200, Tom Gundersen wrote: How would you make sure e.g. kdm was started before (or after) another daemon if you use the runlevel approach? If you use the runlevel approach, DMs start after all DAEMONS. This is usually the right behavior. You start DBUS and other crap and then go for Xorg. This is indeed the safe behavior, and then the two approaches would be equivalent. However, if you use the DAEMONS array you have the flexibility (if you know what you are doing) to optimise it (a lot). Essentially the only thing you need before kdm is dbus (maybe also syslog-ng). I run with DAEMONS=(syslog-ng dbus @kdm ...) If you run a service that relies on the network being up (ssh, netfs, ...), then you need to block on the network daemon, which might take a long time to start. However, it might not be necessary to start kdm after network, so we are loosing a lot of boot time for nothing. As to the problem of a broken system: This is what single user mode is for. No need for a livecd. From my point of view there is no benefit to the inittab method and some benefit to the daemon method. Cheers, Tom
Re: [arch-general] Display Manager rc.d scripts
On Sun, May 08, 2011 at 08:20:40PM +0200, Heiko Baums wrote: Am Sun, 8 May 2011 19:10:59 +0100 schrieb Magnus Therning mag...@therning.org: [1] As an Arch user for a couple of years this is the first time I've heard using runlevels being suggested. Isn't this recommended in the Beginner's Guide or somewhere else in the Wiki? I don't think so. The word runlevel doesn't exist on https://wiki.archlinux.org/index.php/Beginners%27_Guide It does mention adding display managers to the daemons line. I have not read all of the documentation on the wiki though, so I'd be grateful to be pointed to something I've missed. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay pgp4Mq3roSbdQ.pgp Description: PGP signature
Re: [arch-general] Display Manager rc.d scripts
I don't think so. The word runlevel doesn't exist on https://wiki.archlinux.org/index.php/Beginners%27_Guide It does mention adding display managers to the daemons line. I have not read all of the documentation on the wiki though, so I'd be grateful to be pointed to something I've missed. /M https://wiki.archlinux.org/index.php/Display_Manager includes both methods. Does this really matter? The inittab method isn't going anywhere and I don't see any reason to remove the daemon method unless it becomes a problem for the developers. Arch doesn't come with X pre-installed so there is no default, only what's recommended in the wiki, which covers both methods as well as many of the issues mentioned in this thread..
Re: [arch-general] Display Manager rc.d scripts
Am Sun, 8 May 2011 19:33:09 +0100 schrieb Magnus Therning mag...@therning.org: I don't think so. The word runlevel doesn't exist on https://wiki.archlinux.org/index.php/Beginners%27_Guide It does mention adding display managers to the daemons line. I have not read all of the documentation on the wiki though, so I'd be grateful to be pointed to something I've missed. It's the only or first explained method in: https://wiki.archlinux.org/index.php/Xorg https://wiki.archlinux.org/index.php/Display_Manager https://wiki.archlinux.org/index.php/Start_X_at_boot And when I switched to Arch Linux I somewhere read in the Wiki that the inittab method is the recommended one. Heiko
Re: [arch-general] Display Manager rc.d scripts
Am Sun, 8 May 2011 19:28:11 +0100 schrieb Magnus Therning mag...@therning.org: I think the argument of OP was that the inittab method should be the *only* method. If both methods are available, which one should be the default? I'd suggest keeping both methods. Is there a need for a default? I mean the user has to edit /etc/inittab or /etc/rc.conf after the basic installation anyway, because by default there's no active entry for starting xorg at boot time, neither in /etc/inittab nor in /etc/rc.conf. There are only commented examples in /etc/inittab. So it's the user's choice which method he wants to use. And I don't think this needs to be changed. In fact I think not starting xorg at boot time should be the default as it is already. Only both methods should be explained in the Wiki pages with their pros and cons. Heiko
Re: [arch-general] Display Manager rc.d scripts
Am Sun, 8 May 2011 20:29:59 +0200 schrieb Tom Gundersen t...@jklm.no: As to the problem of a broken system: This is what single user mode is for. No need for a livecd. Is this really what single user mode is for? I haven't used it, yet. And how do I switch or boot into single user mode? From my point of view there is no benefit to the inittab method and some benefit to the daemon method. I see it the other way round, because I still see no benefit from starting daemons in the background. In fact I only saw regressions. And under Gentoo I once tried to start the login manager before some other scripts and only got problems with xorg. So xorg should be started as the last application, if the user doesn't know what he is doing. Heiko
Re: [arch-general] Display Manager rc.d scripts
Tom Gundersen wrote: The specific bug you pointed out is not particular to KDM/GDM/slim, but should be fixed for all daemons (proper inheritance of LOCALE), and it is on our TODO list. Indeed, but i didnt point to this report to prove that the rc.d way doesnt work. Its a 10 month old bug report, which means theres been 9-10 upgrades to KDE. The KDE maintainer didnt fix the problem all this time. Both responces to it have been by Arch developers one of which said the rc.d way sucks and inittab is the proper way and the other who said inittab is the only way and thats what the user should be using. To me that means the rc.d way, even if on most occasions may work, it is unsupported. Additionally its more error prone, while the inittab method always works, and always works reliably. Greg -- () against html e-mail | usenet email communication netiquette /\ www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
Re: [arch-general] Display Manager rc.d scripts
On Sun, May 8, 2011 at 9:00 PM, Heiko Baums li...@baums-on-web.de wrote: Am Sun, 8 May 2011 20:29:59 +0200 schrieb Tom Gundersen t...@jklm.no: As to the problem of a broken system: This is what single user mode is for. No need for a livecd. Is this really what single user mode is for? I haven't used it, yet. And how do I switch or boot into single user mode? Same as booting into runlevel 3, just use 1 (or S) instead. I.e. append 1 to your kernel parameters in grub/syslinux. From my point of view there is no benefit to the inittab method and some benefit to the daemon method. I see it the other way round, because I still see no benefit from starting daemons in the background. In fact I only saw regressions. My point was that with using DAEMONS you can do either. [...] xorg should be started as the last application, if the user doesn't know what he is doing. Agreed. Cheers, Tom
Re: [arch-general] Display Manager rc.d scripts
On Sun, May 8, 2011 at 9:26 PM, Grigorios Bouzakis grb...@xsmail.com wrote: Tom Gundersen wrote: The specific bug you pointed out is not particular to KDM/GDM/slim, but should be fixed for all daemons (proper inheritance of LOCALE), and it is on our TODO list. Indeed, but i didnt point to this report to prove that the rc.d way doesnt work. Its a 10 month old bug report, which means theres been 9-10 upgrades to KDE. The KDE maintainer didnt fix the problem all this time. Both responces to it have been by Arch developers one of which said the rc.d way sucks and inittab is the proper way and the other who said inittab is the only way and thats what the user should be using. To me that means the rc.d way, even if on most occasions may work, it is unsupported. If it is unmaintained that is indeed a problem. I have added myself to the bug report you pointed out, and will help with finding a solution (if the people who observe it will answer the questions I put there ;-) ). If there are more kdm rc.d script related bugs, please let me know (I couldn't find any). Additionally its more error prone, while the inittab method always works, and always works reliably. This is strange. The kdm rc.d script must be among the simplest in existence, and as far as I can tell it does the same as putting kdm into inittab. I would be interested to see bugs that are confirmed to work with inittab and not with rc.d script (because then I think we might have something weird going on)...
Re: [arch-general] Display Manager rc.d scripts
Heiko Baums wrote: https://wiki.archlinux.org/index.php/Start_X_at_boot Thats the worst wiki page i've ever seen, on any wiki. -- () against html e-mail | usenet email communication netiquette /\ www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
Re: [arch-general] Display Manager rc.d scripts
On 05/08/2011 04:21 PM, Grigorios Bouzakis wrote: Heiko Baums wrote: https://wiki.archlinux.org/index.php/Start_X_at_boot Thats the worst wiki page i've ever seen, on any wiki. You have not seen mine then!
Re: [arch-general] Display Manager rc.d scripts
On 05/08/2011 08:19 PM, Grigorios Bouzakis wrote: Hello, can anyone think of a reason the rc.d scripts are added to kdm, gdm and slim? They are not recommended by anyone they are to be blame for occasional weird problems. The standard and IMO only way is to start them from inittab. They dont come from upstream i dont know when they were added, i remember them being there ever since i started using Arch, they may come from CRUX or something. I am considering requesting them removal from all display managers. In [0] Pierre said some people want to keep them for backwards compatibility. Backwards compatibility is desired only when something works correctly. Thoughts? [0]: https://bugs.archlinux.org/task/20109 So, lemme get this straight. You don't like the daemon method, therefore it should be removed? they are to be blame for occasional weird problems — not good enough. On 05/08/2011 08:19 PM, Grigorios Bouzakis wrote: The standard and IMO only way is to start them from inittab. Well obviously it's not the only one, whether you like it or not. Nobody is forcing you to use the daemon method, there is no default (as someone already said). On 05/08/2011 04:21 PM, Grigorios Bouzakis wrote: Heiko Baums wrote: https://wiki.archlinux.org/index.php/Start_X_at_boot Thats the worst wiki page i've ever seen, on any wiki. It's a public wiki, fix it, if you think it's bad. -- cantabile Jayne is a girl's name. -- River
Re: [arch-general] Display Manager rc.d scripts
On Sun, May 08, 2011 at 08:54:15PM +0200, Heiko Baums wrote: Am Sun, 8 May 2011 19:33:09 +0100 schrieb Magnus Therning mag...@therning.org: I don't think so. The word runlevel doesn't exist on https://wiki.archlinux.org/index.php/Beginners%27_Guide It does mention adding display managers to the daemons line. I have not read all of the documentation on the wiki though, so I'd be grateful to be pointed to something I've missed. It's the only or first explained method in: https://wiki.archlinux.org/index.php/Xorg https://wiki.archlinux.org/index.php/Display_Manager https://wiki.archlinux.org/index.php/Start_X_at_boot And when I switched to Arch Linux I somewhere read in the Wiki that the inittab method is the recommended one. Same here. Having X fail to start correctly is all too common when installing a new system (or after an update). If you're lucky it drops back into a terminal, if not you're left with a system that doesn't work and provides no way to modify it (except by using a rescue image, manually mounting disks etc.). I've adopted the habit to add '3 nomodeset' to the Fallback boot options while installing. This way there's allways an easy way back into the sytem. Starting X from the DAEMONS array really seems like the very last thing I'd ever consider. -- FA
Re: [arch-general] Display Manager rc.d scripts
On 05/08/2011 02:21 PM, Grigorios Bouzakis wrote: Heiko Baums wrote: https://wiki.archlinux.org/index.php/Start_X_at_boot Thats the worst wiki page i've ever seen, on any wiki. That wiki page needs a wiki page methinks. -eyes crossed. C
[arch-general] makepkg openjd ca-certificates-java
Hi, I've tried building openjdk, but it has a make dependency upon ca-certificates-java, and ca-certificates-jave also has a make dependency upon openjdk: http://projects.archlinux.org/svntogit/packages.git/plain/openjdk6/repos/extra-x86_64/PKGBUILD http://projects.archlinux.org/svntogit/packages.git/plain/ca-certificates-java/repos/extra-any/PKGBUILD How is that resolved when building? Reson for asking is building on non x86 architecture... Thanks, -- Javier.
Re: [arch-general] Need for debug - can do i do?
2011/5/6 Sven-Hendrik Haase s...@lutzhaase.com: On 07.05.2011 01:18, rafael ff1 wrote: HI there! I'm trying to update PCSX2 with some help of its dev team [1], but it is crashing all the time. According to 'gdb' output, it is somehow related to lib32-glibc, but it is omitting some information. I was hoping to be able to activate more verbosity, which AFAIK I can get by compiling it with some debug flags. [2] Is it correct or there is another better way to do it ? Thanks, Rafael. [1] http://code.google.com/p/pcsx2/issues/detail?id=1019 [2] https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces No, that's exactly the way to do it to make gdb happy. Get it from abs as always and enable debug flags. -- Sven-Hendrik I added '-g -O1' to the CFLAGS in the PKGBUILD [1] and it seems to provide zero information [2], just like before compiling with debug flags [3]. Did I do something wrong? Any other ideas to debug this binary? Thanks, Rafael [1] http://pastebin.com/iBYJ30vp [2] http://pastebin.com/eCWRNd2X [3] http://pastebin.com/mFE6QGDd
Re: [arch-general] Need for debug - can do i do?
On 09/05/11 11:17, rafael ff1 wrote: 2011/5/6 Sven-Hendrik Haases...@lutzhaase.com: On 07.05.2011 01:18, rafael ff1 wrote: HI there! I'm trying to update PCSX2 with some help of its dev team [1], but it is crashing all the time. According to 'gdb' output, it is somehow related to lib32-glibc, but it is omitting some information. I was hoping to be able to activate more verbosity, which AFAIK I can get by compiling it with some debug flags. [2] Is it correct or there is another better way to do it ? Thanks, Rafael. [1] http://code.google.com/p/pcsx2/issues/detail?id=1019 [2] https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces No, that's exactly the way to do it to make gdb happy. Get it from abs as always and enable debug flags. -- Sven-Hendrik I added '-g -O1' to the CFLAGS in the PKGBUILD [1] and it seems to provide zero information [2], just like before compiling with debug flags [3]. Did I do something wrong? Any other ideas to debug this binary? Not that the glibc PKGBUILD manually strips its files. Commment out all that stuff at the end. Allan
Re: [arch-general] Need for debug - can do i do?
On 2011/5/7 rafael ff1 rafael.f...@gmail.com wrote: HI there! I'm trying to update PCSX2 with some help of its dev team [1], but it is crashing all the time. According to 'gdb' output, it is somehow related to lib32-glibc, but it is omitting some information. I was hoping to be able to activate more verbosity, which AFAIK I can get by compiling it with some debug flags. [2] Is it correct or there is another better way to do it ? I don't think recompiling glibc with debugging flags is going to help you in any way. Are you sure that your pcsx executable is compiled with debugging symbols? A debug version of glibc is usually of no use except to debug glibc itself. In the backtrace linked at http://pastebin.com/eCWRNd2X, it is *Thread1* that segfaulted. Rémy.
