Re: [arch-general] libgl conflict with ati-dri, intel-dri, mach64-dri, ...
On 03/26/2012 07:01 AM, Karol Błażewicz wrote: > Please do at least some research yourself before firing an e-mail to the list, > e.g. https://bugs.archlinux.org/task/28938 should have given you a clue on > what's going on: some of these *-dri drivers have been dropped, they're not in > the repos anymore and they don't work with the current libgl 8.0.2-1. > > If you do need ati-dri or intel-dri, you can still use them with the current > libgl. > Karol, I checked www.archlinux.com and I checked packages. Usually it is just a timing issue when these things pop up - thus my question "is it just a timing issue?" There are times when any user can miss something in a bug report, etc.. Please don't take that as an open invitation to berate them openly. That is a large part of the reason the Arch list has a negative reputation for being open to users asking for help. There is a fine line between being helpful and being sarcastic. A simple see: https://bugs.archlinux.org/task/28938 would have sufficed. I appreciate your help, but I won't, nor should anyone else, tolerate abusive behavior on this list. -- David C. Rankin, J.D.,P.E.
Re: [arch-general] libgl conflict with ati-dri, intel-dri, mach64-dri, ...
On Mon, 26 Mar 2012 14:01:40 +0200 Karol Błażewicz wrote: > On Mon, 26 Mar 2012 01:35:57 +0200, David C. Rankin > wrote: > > > Guys, > > > > On update today of an i686 box, I get the following unresolved error > > with > > pacman -Syu: > > > > error: failed to prepare transaction (could not satisfy dependencies) > > :: ati-dri: requires libgl=7.11.2 > > :: intel-dri: requires libgl=7.11.2 > > :: mach64-dri: requires libgl=7.11.2 > > :: mga-dri: requires libgl=7.11.2 > > :: r128-dri: requires libgl=7.11.2 > > :: savage-dri: requires libgl=7.11.2 > > :: sis-dri: requires libgl=7.11.2 > > :: tdfx-dri: requires libgl=7.11.2 > > > > Is this just a timing issue with the dri files? > > > > > Please do at least some research yourself before firing an e-mail to the > list, e.g. https://bugs.archlinux.org/task/28938 should have given you a > clue on what's going on: some of these *-dri drivers have been dropped, > they're not in the repos anymore and they don't work with the current > libgl 8.0.2-1. > > If you do need ati-dri or intel-dri, you can still use them with the > current libgl. In addition, why on earth would you have all *-dri files installed? You don't know your graphics card? -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] fsck on each boot?
On Mon, Mar 26, 2012 at 3:09 PM, gt wrote: > I recently added the fsck hook to mkinitcpio.conf after seeing it being > recommended in the forums. I don't have a separate /usr though. > > Anyway, now after every boot i see: > > performing fsck on > > It shows up clean, and happens in a flash of a second. > > So my question is that is the hook supposed to perform fsck everytime? > Earlier (without the hook), it used to happen only on unclean shutdowns. We always perform fsck on all partitions on every boot. The difference with the fsck hook in initramf is that it fsck's the rootfs (and potentially /usr) before mounting them. The reason for wanting to do this is that otherwise you would be "out of luck" if your root could not be mounted, or your fsck binary i broken due to issues on the rootfs. The reason fsck happens in a flash of a second is that it in most cases does nothing. The exemption is if you shutdown uncleanly, or you have booted a certain number of times without fscking. -t
Re: [arch-general] fsck on each boot?
On 03/26/2012 03:09 PM, gt wrote: > I recently added the fsck hook to mkinitcpio.conf after seeing it being > recommended in the forums. I don't have a separate /usr though. > > Anyway, now after every boot i see: > > performing fsck on > > It shows up clean, and happens in a flash of a second. > > So my question is that is the hook supposed to perform fsck everytime? > Earlier (without the hook), it used to happen only on unclean shutdowns. > Yes, it's supposed to be like this. I think the main intention is to guarantee a clean root filesystem before trying to mount e.g. a seperate /home or /usr, which may depend on content of the rootfs (keyfiles, configuration files, ...). This all adds up to be a precaution taken by the devs to guarantee a smooth experience IMO :) Greetings, Christoph signature.asc Description: OpenPGP digital signature
[arch-general] fsck on each boot?
I recently added the fsck hook to mkinitcpio.conf after seeing it being recommended in the forums. I don't have a separate /usr though. Anyway, now after every boot i see: performing fsck on It shows up clean, and happens in a flash of a second. So my question is that is the hook supposed to perform fsck everytime? Earlier (without the hook), it used to happen only on unclean shutdowns. -- O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Re: [arch-general] libgl conflict with ati-dri, intel-dri, mach64-dri, ...
On Mon, 26 Mar 2012 01:35:57 +0200, David C. Rankin wrote: Guys, On update today of an i686 box, I get the following unresolved error with pacman -Syu: error: failed to prepare transaction (could not satisfy dependencies) :: ati-dri: requires libgl=7.11.2 :: intel-dri: requires libgl=7.11.2 :: mach64-dri: requires libgl=7.11.2 :: mga-dri: requires libgl=7.11.2 :: r128-dri: requires libgl=7.11.2 :: savage-dri: requires libgl=7.11.2 :: sis-dri: requires libgl=7.11.2 :: tdfx-dri: requires libgl=7.11.2 Is this just a timing issue with the dri files? Please do at least some research yourself before firing an e-mail to the list, e.g. https://bugs.archlinux.org/task/28938 should have given you a clue on what's going on: some of these *-dri drivers have been dropped, they're not in the repos anymore and they don't work with the current libgl 8.0.2-1. If you do need ati-dri or intel-dri, you can still use them with the current libgl.
Re: [arch-general] Grub2
On Monday 26 Mar 2012 02:18:53 Saurav Modak wrote: > Have you tried manually adding it in grub.cfg BTW? Editing grub.cfg is a naughty thing to do with Grub2 :p The "correct" thing to do would be to add the fallback to /etc/grub.d/41_custom. However, Grub previously automatically detected the fallback correctly. I'm wondering why it doesn't now. Paul
