Re: [gentoo-dev] matrox.eclass
Alec Warner napsal(a): Jakub Moc wrote: Danny van Dyk napsal(a): which breaks the metadata cache. Any objections to change it to SLOT=0 As noted on the relevant bug [1], the eclass is a complete no-op and nothing can be installed using this eclass (has been so for quite some time). Fixing it doesn't make sense, making it dummy or even removing it (plus the unusable single ebuild which inherits it) does. [1] http://bugs.gentoo.org/show_bug.cgi?id=162960 And we already told you, removing it isn't a good solution (even if it technically works within the bounds of the current api). The bug is that the SLOT invalidates cache entries and it's trivial to fix. The eclass is not trivial to fix, to be fixed, this eclass would require a complete rewrite from scratch. There's no usable ebuild for this eclass and the eclass is completely moot. Still fail to see what are you trying to fix as opposed to removing a broken non-functional cruft from the tree. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] matrox.eclass
Jakub Moc wrote: Alec Warner napsal(a): Jakub Moc wrote: Danny van Dyk napsal(a): which breaks the metadata cache. Any objections to change it to SLOT=0 As noted on the relevant bug [1], the eclass is a complete no-op and nothing can be installed using this eclass (has been so for quite some time). Fixing it doesn't make sense, making it dummy or even removing it (plus the unusable single ebuild which inherits it) does. [1] http://bugs.gentoo.org/show_bug.cgi?id=162960 And we already told you, removing it isn't a good solution (even if it technically works within the bounds of the current api). The bug is that the SLOT invalidates cache entries and it's trivial to fix. The eclass is not trivial to fix, to be fixed, this eclass would require a complete rewrite from scratch. There's no usable ebuild for this eclass and the eclass is completely moot. Still fail to see what are you trying to fix as opposed to removing a broken non-functional cruft from the tree. See the bug? It says 'slot is being set to $KV, which breaks the metadata cache. Also, portage may fail to set $KV to a valid slot value (typically 0) and thus the package may end up with SLOT= which is also invalid'. Thats what we are trying to fix. The fact that the eclass sucks balls is irrelevant, I could say the same of a dozen other old as hell eclasses. But they remain in the tree, as will this one. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] matrox.eclass
Alec Warner napsal(a): See the bug? It says 'slot is being set to $KV, which breaks the metadata cache. Also, portage may fail to set $KV to a valid slot value (typically 0) and thus the package may end up with SLOT= which is also invalid'. Thats what we are trying to fix. There's absolutely no package that could be installed via this crappy eclass, already tried to explain about 4 times but you don't listen. Oh well, I give up; go fix the slot, never mind that it's utterly useless. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] matrox.eclass
On Sun, Jan 28, 2007 at 12:02:39PM +0100, Jakub Moc wrote: Alec Warner napsal(a): See the bug? It says 'slot is being set to $KV, which breaks the metadata cache. Also, portage may fail to set $KV to a valid slot value (typically 0) and thus the package may end up with SLOT= which is also invalid'. Thats what we are trying to fix. There's absolutely no package that could be installed via this crappy eclass, already tried to explain about 4 times but you don't listen. Oh well, I give up; go fix the slot, never mind that it's utterly useless. Jakub, please stop making a fool of yourself with your endless rants. Quite a few experienced ebuild developers have already told you why it's not being removed. As such your rants are only wasting time. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] matrox.eclass
Bryan Østergaard napsal(a): On Sun, Jan 28, 2007 at 12:02:39PM +0100, Jakub Moc wrote: Jakub, please stop making a fool of yourself with your endless rants. Quite a few experienced ebuild developers have already told you why it's not being removed. As such your rants are only wasting time. Regards, Bryan Østergaard Yay, rants... - Folks, this car won't go any more, the engine has blown. Help. -- No worries, we'll fix the scratched paint on your left door and everything will be cool... Sigh. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] matrox.eclass
Jakub Moc wrote: - Folks, this car won't go any more, the engine has blown. Help. -- No worries, we'll fix the scratched paint on your left door and everything will be cool... the ebuild remains since it could be necessary to uninstall old packages... so fixing SLOT is the correct solution. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] matrox.eclass
Luca Barbato wrote: Jakub Moc wrote: - Folks, this car won't go any more, the engine has blown. Help. -- No worries, we'll fix the scratched paint on your left door and everything will be cool... the ebuild remains since it could be necessary to uninstall old packages... so fixing SLOT is the correct solution. Mixing ebuild and eclass here, are you? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] matrox.eclass
Petteri Räty napsal(a): Luca Barbato wrote: the ebuild remains since it could be necessary to uninstall old packages... so fixing SLOT is the correct solution. Those packages that couldn't be installed since X.org (as opposed to XFree) did hit the tree because the eclass just dies and for which no driver can be downloaded? Lots of people must have those installed apparently. :) You know, I already mentioned a couple of times that is will work just fine with a dummy eclass (if someone has this crap installed by some miracle) but we are so drowned in policies that this doesn't go anywhere. Maybe someone could at least punt the single unusable ebuild that remains in the tree so that something marginally useful would come out of this. Thanks, bye. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] matrox.eclass
Hi,
besides a deprecated call to check_KV, matrox.eclass sets
SLOT=${KV}
which breaks the metadata cache. Any objections to change it
to
SLOT=0
anyone?
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] matrox.eclass
Danny van Dyk napsal(a): which breaks the metadata cache. Any objections to change it to SLOT=0 As noted on the relevant bug [1], the eclass is a complete no-op and nothing can be installed using this eclass (has been so for quite some time). Fixing it doesn't make sense, making it dummy or even removing it (plus the unusable single ebuild which inherits it) does. [1] http://bugs.gentoo.org/show_bug.cgi?id=162960 -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] matrox.eclass
Jakub Moc wrote: Danny van Dyk napsal(a): which breaks the metadata cache. Any objections to change it to SLOT=0 As noted on the relevant bug [1], the eclass is a complete no-op and nothing can be installed using this eclass (has been so for quite some time). Fixing it doesn't make sense, making it dummy or even removing it (plus the unusable single ebuild which inherits it) does. [1] http://bugs.gentoo.org/show_bug.cgi?id=162960 And we already told you, removing it isn't a good solution (even if it technically works within the bounds of the current api). The bug is that the SLOT invalidates cache entries and it's trivial to fix. -- gentoo-dev@gentoo.org mailing list
