Re: [arch-general] [arch-dev-public] grub/grub2 final
On 06/24/2012 10:51 PM, Ronald van Haren wrote: I'd like to move 2.00 to [core] via [testing] when it is released, letting the grub-bios (atm grub2-bios) replace the old grub package. Adding an install message and a news item is probably a good idea at the time. I'll be pushing grub2 rc1 to [testing] in a moment if you want to give it a try. Final 2.00 release should be in one of the next days. GRUB 2.00 released - https://lists.gnu.org/archive/html/grub-devel/2012-06/msg00093.html Regards. Keshav
Re: [arch-general] Nvidia/vesafb/GRUB2
No, it supports the vesa standard. All cards do. But that's completely different from vesafb, a linux driver. Your right and you cleared up the confusion somewhbut that's a little unfair. I believe all cards MUST support VESA. The vesafb driver isn't supported directly but it uses the VESA standard as do many embedded drivers so it is supported indirectly. They certainly don't support running both but then on the 172 driver mentioned they don't support the recent xorg servers new abi either. If I was the OP I wouldn't waste time if there's is no problem beyond a log from a closed source driver unless uvesafb offers benefits as that won't be supported either as it's not Nvidia's code is it? -- Why not do something good every day and install BOINC.
[arch-general] Pacman behaviour comparing numerical versions for package upgrades
I have a question about pacman's behaviour regarding packges to be updated. According to $: man pacman You can also use pacman -Su to upgrade all packages that are out of date. See Sync Options below. When upgrading, pacman performs version comparison to determine which packages need upgrading. Alphanumeric: 1.0a 1.0b 1.0beta 1.0p 1.0pre 1.0rc 1.0 1.0.a 1.0.1 Numeric: 1 1.0 1.1 1.1.1 1.2 2.0 3.0.0 That's very clear and makes sense. Here's where I'm confused. I build some of my perl pacakges with cpanpkgbuild -f XXX::XXX::YYY. The package from the official repos is: perl-datetime-format-strptime-1.5000-1-any.pkg.tar.xz the package I built is: perl-datetime-format-strptime-1.51-1-any.pkg.tar.xz I'm used to the warning package ??? local is newer than extra ???. But with the above referenced package I had to list it in the [ IgnorePkg ] line to keep pacman from trying to upgrade the package and still get this warning. Ignoring upgrade from perl-datetime-format-strptime from 1.51-1 to 1.5000-1 No complaints as it's easy to fix, I was just wondering about the reasoning. I'll jump out on a limb here and assume it's because the repo package has 4 digits then the package version after the decimal point and my package has two digits then the package version after the decimal point. The developer changed his numbering scheme after 1.5000 to 1.51. Is this the correct behaviour for pacman? -- Life's fun when your sick and psychotic!
Re: [arch-general] Pacman behaviour comparing numerical versions for package upgrades
On 29/06/12 15:50, Myra Nelson wrote: I have a question about pacman's behaviour regarding packges to be updated. According to $: man pacman You can also use pacman -Su to upgrade all packages that are out of date. See Sync Options below. When upgrading, pacman performs version comparison to determine which packages need upgrading. Alphanumeric: 1.0a 1.0b 1.0beta 1.0p 1.0pre 1.0rc 1.0 1.0.a 1.0.1 Numeric: 1 1.0 1.1 1.1.1 1.2 2.0 3.0.0 That's very clear and makes sense. Here's where I'm confused. I build some of my perl pacakges with cpanpkgbuild -f XXX::XXX::YYY. The package from the official repos is: perl-datetime-format-strptime-1.5000-1-any.pkg.tar.xz the package I built is: perl-datetime-format-strptime-1.51-1-any.pkg.tar.xz I'm used to the warning package ??? local is newer than extra ???. But with the above referenced package I had to list it in the [ IgnorePkg ] line to keep pacman from trying to upgrade the package and still get this warning. Ignoring upgrade from perl-datetime-format-strptime from 1.51-1 to 1.5000-1 No complaints as it's easy to fix, I was just wondering about the reasoning. I'll jump out on a limb here and assume it's because the repo package has 4 digits then the package version after the decimal point and my package has two digits then the package version after the decimal point. The developer changed his numbering scheme after 1.5000 to 1.51. Is this the correct behaviour for pacman? 5000 51
