I would like to downgrade from xorg-server 1.7.3 as psb-kmod only works with version 1.6. Any version I try between 1.5.3-r6 and 1.6.5 always gives me the same result: P -MF .deps/dispatch.Tpo -c dispatch.c -fPIC -DPIC -o .libs/dispatch.o In file included from ../Xext/panoramiX.h:43, from dispatch.c:134: /usr/include/X11/extensions/panoramiXext.h:49: error: expected ')' before '*' token /usr/include/X11/extensions/panoramiXext.h:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XPanoramiXQueryVersion' /usr/include/X11/extensions/panoramiXext.h:64: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XPanoramiXGetState' /usr/include/X11/extensions/panoramiXext.h:70: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XPanoramiXGetScreenCount' /usr/include/X11/extensions/panoramiXext.h:76: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'XPanoramiXGetScreenSize' dispatch.c: In function 'ProcCloseFont': dispatch.c:1123: warning: 'SecurityLookupIDByType' is deprecated (declared at ../include/resource.h:269) make[2]: *** [dispatch.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... mv -f .deps/colormap.Tpo .deps/colormap.Plo mv -f .deps/devices.Tpo .deps/devices.Plo make[2]: Leaving directory `/var/tmp/portage/x11-base/xorg-server-1.5.3-r6/work/xorg-server-1.5.3/dix' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/portage/x11-base/xorg-server-1.5.3-r6/work/xorg-server-1.5.3/dix' make: *** [all-recursive] Error 1 * ERROR: x11-base/xorg-server-1.5.3-r6 failed: * emake failed Also wouldn't it make sense to install a dependency so that version 1.7 is not installed in the first place? Thank you for your Feedback. Best Zeno
Most likely INVALID (and a dupe of other invalid in this topic). when you downgrade between major xorg-server versions, you need to downgrade some of the libs/protos too.
What are the exact packages that you should downgrade? Shouldn't that be in the dependencies? I do not think that this is invalid. This is a very valid bug. Just declaring this invalid is neither useful to Gentoo nor helpful to the user.
Limitation of portage (you can't declare a range of versions) and too much work for the maintainers (packages check for minimum version required, in x11 case, backward compatility is broken with major releases by design (at least for ABI) as without that no real progress could be made in development)
Hmm, Thank you for the reply. That is sad. As far as I know old kernels do compile as well. You would not have to define a range. You would only have to say what version of other software is needed if you i.e. want xorg-server 1.6.5. That is not a range. That is an exact number and with that should go a list of all the library numbers that do compile with that version. Downgrades and upgrades will become a lot more popular in the future I believe. So it should be easy to down and upgrade as the user pleases.
No, it would be a range - ebuild for the sever declares minimal version that works, you want to add a maximum version that still works.
Well range or not a range - both is fine for me as long as it compiles correctly. With Ubuntu you have these Milestones (strange animal names) and then you know that everything from that release just works. So you can always downgrade or upgrade without a problem.
(In reply to comment #4) > Hmm, Thank you for the reply. That is sad. As far as I know old kernels do > compile as well. You would not have to define a range. You would only have to > say what version of other software is needed if you i.e. want xorg-server > 1.6.5. That is not a range. That is an exact number and with that should go a > list of all the library numbers that do compile with that version. And so if xorg-server, say, 1.6.6 is ever released, we would have to update all our ebuilds to say which versions work together? Madness. We don't have ranged dependencies and that's a shame. We'll have to work with that. (In reply to comment #6) > Well range or not a range - both is fine for me as long as it compiles > correctly. With Ubuntu you have these Milestones (strange animal names) and > then you know that everything from that release just works. So you can always > downgrade or upgrade without a problem. That's a fine model for Ubuntu, not for Gentoo. We do continuous integration and we expect users to continuously keep their systems up-to-date. Downgrading should only happen when we (devs) decide it, for instance with a package.mask entry. So like all the other users who want to stick with xorg-server 1.6, please head over to https://bugs.gentoo.org/show_bug.cgi?id=291312#c12 Thanks *** This bug has been marked as a duplicate of bug 291312 ***
Well thanks for being arrogant! So gentoo is only about the developers and not about the users or what? That would be very stupid. But I know that it is not like that. Thank you for pointing out Bug 291312 I tried that with package.mask - it did not help. I get the exact same error. I tried that before I opened this bug-report. I am reopening until I have a solution that is user-friendly and more importantly that works. And also: please read why I need to downgrade: Because I want to use psb-kmod. That only works with Version 1.6. So please just start making Gentoo a bit more user friendly. Thank you.
(In reply to comment #8) > Well thanks for being arrogant! So gentoo is only about the developers and not > about the users or what? That would be very stupid. But I know that it is not > like that. "arrogant", "stupid". Please keep your tone down, bugzilla is a work tool, not a soap box to vent your frustrations. > Thank you for pointing out Bug 291312 > > I tried that with package.mask - it did not help. I get the exact same error. I > tried that before I opened this bug-report. > > I am reopening until I have a solution that is user-friendly and more > importantly that works. That package.mask entry works fine for dozens of other users who have used it to stick with xorg-server 1.6 until nvidia released a driver that was compatible with 1.7. It's been very well tested. If it doesn't work for you, then there's something else that's wrong on your system. Maybe you still have some left overs in /etc/portage/package.unmask? > And also: please read why I need to downgrade: Because I want to use psb-kmod. > That only works with Version 1.6. Yes, and I pointed out to you a _valid_ solution to stay with 1.6. You're blaming me for trying to help you? > So please just start making Gentoo a bit more user friendly. I'd say you don't have the faintest idea about the amount of work we all put into Gentoo. If it were entirely up to me, there would be _no_ binary drivers in Gentoo because they cause so much pain, for users and developers alike. But given their popularity, I try my best to make do. Hence the package.mask entry in the other bug, to help stranded users such as you. Don't forget we're a community distro. We're here to help as best as we can, but we're not your string puppets. And don't reopen this bug. If there is a legitimate bug, we'll reopen it. Thanks *** This bug has been marked as a duplicate of bug 291312 ***
As I said. Obviously you are not interested in helping so go away please. I am reopening as until my problem is solved. I tried your solution and it does not work. Let me know if you want to see my package mask file. Closing bugs by pretending to help does not help. It is just bureaucracy.
I am on xorg-server 1.7 and I need to downgrade to 1.6. I do not want to stay with 1.6 I want to go back to 1.6 because I am on 1.7.
Why are you talking about Nvidia? I am talking about Poulsbo (gma500) that only works with xorg-server 1.6. This is a new bug report and it is not a duplicate. Could you respect that please!
Wow, you obviously aren't reading what I'm writing. I mentioned nvidia users because they needed to stay with xorg-server 1.6 _just_like_you_ with psb. And FYI, I _am_ interested in helping out users. Just not when they're acting like jerks. I'll just stop helping you right now and will let you calm down. If you keep insulting other users and/or developers, I will not hesitate to contact User Rel.
I called you arrogant you called me a "jerk"! So who is insulting who! You should be helping and not be calling your users a "jerks"! I never called you an *diot. I would not do that. I called you arrogant. That is a big difference. And I reopened the bug report. That may have insulted you personally. But lets clam down. This is what I get with package.mask as mentioned in 291312 emerge -p =xorg-server-1.6.5 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] x11-base/xorg-server-1.6.5 [1.7.3] USE="-hal*" !!! The following installed packages are masked: - x11-proto/xf86driproto-2.1.0 (masked by: package.mask) - x11-proto/xineramaproto-1.2 (masked by: package.mask) - x11-base/xorg-drivers-1.7 (masked by: package.mask) - x11-libs/libXext-1.1.1 (masked by: package.mask) - x11-libs/libX11-1.3.2 (masked by: package.mask) - x11-proto/xf86vidmodeproto-2.3 (masked by: package.mask) - x11-proto/bigreqsproto-1.1.0 (masked by: package.mask) - x11-proto/xextproto-7.1.1 (masked by: package.mask) - x11-proto/xf86dgaproto-2.1 (masked by: package.mask) - x11-proto/fixesproto-4.1.1 (masked by: package.mask) - x11-proto/inputproto-2.0 (masked by: package.mask) - x11-proto/recordproto-1.14 (masked by: package.mask) - x11-libs/libXi-1.3 (masked by: package.mask) - x11-proto/scrnsaverproto-1.2.0 (masked by: package.mask) - x11-proto/xcmiscproto-1.2.0 (masked by: package.mask) - x11-libs/libXtst-1.1.0 (masked by: package.mask)
Please everyone come back to a professional level. Zeno, as Rémi pointed out, the list in bug 291312 is supposed to help you to stay with the older xorg-server. The fact that it works for many other users leads to the conclusion that there is something in your system (possibly old package.unmask entries) that prevents it from working. Bugzilla is not the right place to sort those out. Please use one of the support channels mentioned at [1] to get assistants. Thank you. [1] http://www.gentoo.org/main/en/support.xml *** This bug has been marked as a duplicate of bug 291312 ***
(In reply to comment #14) > This is what I get with package.mask as mentioned in 291312 > > emerge -p =xorg-server-1.6.5 Try : emerge -DuNa world Portage should try to downgrade everything gracefully.
My system is new. There is no old package.unmask there. There is no such file on my system. I want straight to 1.7. I never touched 1.7 now I need to downgrade. Why are you making assumptions without helping?
(In reply to comment #16) > (In reply to comment #14) > > This is what I get with package.mask as mentioned in 291312 > > > > emerge -p =xorg-server-1.6.5 > > Try : emerge -DuNa world > > Portage should try to downgrade everything gracefully. Thanks. I will try that!
> > Try : emerge -DuNa world > > > > Portage should try to downgrade everything gracefully. Sorry for insisting but: Is this really the easiest way? There is no simpler solution to this problem? I mean: Why do I have to recompile gimp, git, wicd etc to downgrade to xorg-server 1.6?
(In reply to comment #19) > > > Try : emerge -DuNa world > > > > > > Portage should try to downgrade everything gracefully. > > Sorry for insisting but: > > Is this really the easiest way? There is no simpler solution to this problem? > > I mean: Why do I have to recompile gimp, git, wicd etc to downgrade to > xorg-server 1.6? > You don't - you just had pending changes that have not yet been accounted for, probably from a change in USE flags, etc. The only changes needed specifically to x-server are those listed in the bug report to which you have been linked.
(In reply to comment #19) > Sorry for insisting but: > > Is this really the easiest way? There is no simpler solution to this problem? > > I mean: Why do I have to recompile gimp, git, wicd etc to downgrade to > xorg-server 1.6? Probably because : 1) they were out of date 2) or there were USE flag changes Either way, you should definitely update those packages as well. If portage wants to emerge them, there's a reason. Btw, that command I gave you is the proper way to update your system after an emerge --sync, this will keep your system to the latest bits we want users to have.
> You don't - you just had pending changes that have not yet been accounted for, > probably from a change in USE flags, etc. The only changes needed specifically > to x-server are those listed in the bug report to which you have been linked. Ok, understood. And that I have to do manually if I do not want to upgrade the "whole" world. I will try that then. Thank you for your reply.
> Btw, that command I gave you is the proper way to update your system after an > emerge --sync, this will keep your system to the latest bits we want users to > have. Thanks for your help. I understand. Just sometimes I do not want to update the "whole" world. As I may need one or the other package in that version. So it would be nice if there where one command with which I could just downgrade to xorg-server 1.6 after setting those package.mask entries. That in fact would be cooool! Gentoo used to be famous for its flexibility.
And just for the record: That is why I switched from Debian to Gentoo 8 years ago.
Only doing downgrades is easily possible with portage-2.2 release candidates with emerge -1va @downgrade or similar. I presume you use portage-2.1.x though, but am not sure as you never have posted emerge --info as requested by default. To do it with portage-2.1, one can just list all the packages that need downgrades, preferably with --oneshot (-1 for short) to not record them to world file, such as this: emerge -1va xf86driproto xineramaproto xorg-drivers libXext libX11 xf86vidmodeproto bigreqsproto xextproto xf86dgaproto fixesproto inputproto recordproto libXi scrnsaverproto xcmiscproto libXtst This list I retrieved from your very own comment #14 where portage had complained that it doesn't see the newer versions you have on anymore (suggesting a downgrade of them needs to happen).
(In reply to comment #25) > Only doing downgrades is easily possible with portage-2.2 release candidates > with emerge -1va @downgrade or similar. I presume you use portage-2.1.x though, > but am not sure as you never have posted emerge --info as requested by default. > > To do it with portage-2.1, one can just list all the packages that need > downgrades, preferably with --oneshot (-1 for short) to not record them to > world file, such as this: > > emerge -1va xf86driproto xineramaproto xorg-drivers libXext libX11 > xf86vidmodeproto bigreqsproto xextproto xf86dgaproto fixesproto inputproto > recordproto libXi scrnsaverproto xcmiscproto libXtst > > This list I retrieved from your very own comment #14 where portage had > complained that it doesn't see the newer versions you have on anymore > (suggesting a downgrade of them needs to happen). Wow! Now this is really helpful. Thank you so much! Why was this not in the other bug report. Anyway thank you so much! This bug report has become more valuable with this information! Thanks so much!
I am on portage 2.2 rc56
So if I understand you correctly with portage 2.2 it would be: emerge -1va xorg-server with the according package mask? I will try that then.
(In reply to comment #25) > Only doing downgrades is easily possible with portage-2.2 release candidates > with emerge -1va @downgrade or similar. I presume you use portage-2.1.x though, emerge -1va results in the same error as it emerges xorg-server-1.6.5 first: -MP -MF .deps/dispatch.Tpo -c -o dispatch.lo dispatch.c In file included from dispatch.c:134: ../Xext/panoramiX.h:44:41: error: X11/extensions/panoramiXext.h: No such file or directory dispatch.c: In function 'ProcCloseFont': dispatch.c:1117: warning: 'SecurityLookupIDByType' is deprecated (declared at ../include/resource.h:268) make[2]: *** [dispatch.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... mv -f .deps/colormap.Tpo .deps/colormap.Plo mv -f .deps/devices.Tpo .deps/devices.Plo make[2]: Leaving directory `/var/tmp/portage/x11-base/xorg-server-1.6.5-r1/work/xorg-server-1.6.5/dix' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/portage/x11-base/xorg-server-1.6.5-r1/work/xorg-server-1.6.5/dix' make: *** [all-recursive] Error 1 * ERROR: x11-base/xorg-server-1.6.5-r1 failed:
LibXext 1.0.5 also fails: XAppgroup.c:332: error: 'app_group_return' undeclared (first use in this function) XAppgroup.c: At top level: XAppgroup.c:340: warning: no previous prototype for 'XagCreateAssociation' XAppgroup.c:373: warning: no previous prototype for 'XagDestroyAssociation' make[2]: *** [DPMS.lo] Error 1 make[2]: *** [XAppgroup.lo] Error 1 make[2]: Leaving directory `/var/tmp/portage/x11-libs/libXext-1.0.5/work/libXext-1.0.5/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/x11-libs/libXext-1.0.5/work/libXext-1.0.5' make: *** [all] Error 2 * ERROR: x11-libs/libXext-1.0.5 failed: * emake failed * Trying the other packages manually now.
Try to downgrade the proto packages first, then the others. I'd hope emerge -1va @downgrade would order them as such
(In reply to comment #31) > Try to downgrade the proto packages first, then the others. Ok will try that. >I'd hope emerge -1va @downgrade would order them as such Obviously not. ;) In the mean time I got another error: so does libXtst-1.0.3: XRecord.c: In function 'XRecordDisableContext': XRecord.c:1071: error: expected declaration specifiers before 'XRecordContext' XRecord.c: In function 'XRecordFreeContext': XRecord.c:1091: error: expected declaration specifiers before 'XRecordContext' make[2]: *** [XRecord.lo] Error 1 make[2]: Leaving directory `/var/tmp/portage/x11-libs/libXtst-1.0.3/work/libXtst-1.0.3/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/x11-libs/libXtst-1.0.3/work/libXtst-1.0.3' make: *** [all] Error 2 * ERROR: x11-libs/libXtst-1.0.3 failed: * emake failed *
Ok and this one I will kick out manually with "emerge -C"
emerge inputproto recordproto scrnsaverproto * IMPORTANT: 1 news items need reading for repository 'funtoo'. * Use eselect news to read news items. Calculating dependencies... done! [ebuild UD] x11-proto/inputproto-1.5.1 [2.0] [ebuild UD] x11-proto/recordproto-1.13.2 [1.14] [ebuild UD] x11-proto/scrnsaverproto-1.1.0 [1.2.0] [blocks B ] <x11-proto/scrnsaverproto-1.2 ("<x11-proto/scrnsaverproto-1.2" is blocking x11-libs/libXScrnSaver-1.2.0)
Ok, but recordproto gives me some file collisions: >>> Failed to install x11-proto/recordproto-1.13.2, Log file: >>> '/var/tmp/portage/x11-proto/recordproto-1.13.2/temp/build.log' * Messages for package x11-proto/recordproto-1.13.2: * This package will overwrite one or more files that may belong to other * packages (see list below). You can use a command such as `portageq * owners / <filename>` to identify the installed package that owns a * file. If portageq reports that only one package owns a file then do * NOT file a bug report. A bug report is only useful if it identifies at * least two or more packages that are known to install the same file(s). * If a collision occurs and you can not explain where the file came from * then you should simply ignore the collision since there is not enough * information to determine if a real problem exists. Please do NOT file * a bug report at http://bugs.gentoo.org unless you report exactly which * two packages install the same file(s). Once again, please do NOT file * a bug report unless you have completely understood the above message. * * Detected file collision(s): * * /usr/include/X11/extensions/record.h * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * x11-libs/libXtst-1.1.0 * /usr/include/X11/extensions/record.h Will move the file manually.
(In reply to comment #35) > Will move the file manually. NO! Don't do this! Let portage manage files. If there's a collision, remove the offending packages.
Oh and, please, try to group your messages a bit, you're sending emails to a lot of people every time you post here.
Ok, another collision: emerge xcmiscproto xextproto xf86bigfontproto xf86dgaproto xf86driproto xf86vidmodeproto * IMPORTANT: 1 news items need reading for repository 'funtoo'. * Use eselect news to read news items. >NO! Don't do this! Let portage manage files. If there's a collision, remove the > offending packages. Will try to remember that. Thank you for the hints. Calculating dependencies... done! [ebuild UD] x11-proto/xextproto-7.0.5 [7.1.1] [ebuild UD] x11-proto/xcmiscproto-1.1.2 [1.2.0] [ebuild UD] x11-proto/xf86bigfontproto-1.1.2 [1.2.0] [ebuild UD] x11-proto/xf86dgaproto-2.0.3 [2.1] [ebuild UD] x11-proto/xf86driproto-2.0.4 [2.1.0] [ebuild UD] x11-proto/xf86vidmodeproto-2.2.2 [2.3] [blocks B ] <x11-proto/xextproto-7.1.1 ("<x11-proto/xextproto-7.1.1" is blocking x11-libs/libXext-1.1.1) Doing another emerge -C I am getting so many errors. I want to report them all from the users point of view. Please bear with me.
(In reply to comment #36) > (In reply to comment #35) > > Will move the file manually. > > NO! Don't do this! Let portage manage files. If there's a collision, remove the > offending packages. I just removed /usr/include/X11/extensions/XTest.h manually because emerge -C xextproto did not help. After that it worked.
Another file I had to move manually to my home directory /usr/include/X11/extensions/xf86vmode.h so that xf86vidmodeproto-2.2.2 would go through.
libXext-1.0.5 just went trough as first package after doing the *proto. and not xorg complains again: checking for GL... configure: error: Package requirements (glproto >= 1.4.9 gl >= 7.1.0) were not met: Package 'FixesProto' requires 'xextproto >= 7.0.99.1' but version of XExtProto is 7.0.5
Ok, uninstalling fixesproto-4.1.1 and then installing it new again so it meets 4.0. That helped.
Ok, xorg-server-1.6.5-r1 is compiling now and went past the previous error of dispatch.c:1117: warning: 'SecurityLookupIDByType' is deprecated (declared at ../include/resource.h:268) keeping fingers crossed.
It worked! Thanks for all your help. Let me know if you need a user who should test portage and emerge -1va @downgrade a bit more for you. Now if I could turn a bug-report into a feature-request then it would be getting emerge -1va to work to downgrade Xorg from 1.7 to 1.6! And that would have been the bug-report in the first place.
Ok, and obviously some modules have to get fixed as well, als X -configure results in: (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "ati" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "vmware" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "glint" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "intel" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "mach64" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "mga" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "neomagic" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "nv" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "openchrome" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "psb" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "r128" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "radeon" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "savage" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "sis" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "tdfx" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "trident" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "fbdev" (module requirement mismatch, 0) (EE) module ABI major version (6) doesn't match the server's version (5) (EE) Failed to load module "vesa" (module requirement mismatch, 0) No devices to configure. Configuration failed. Any hints for the stupid user?
Go through the modules step by step. Unmerge them with -C and emerge them.
Not sure why you have so many video drivers if you are using poulsbo, but xorg-server package says after upgrade/downgrade how to rebuild all necessary modules. These messages are meant for reading and following. In short, qlist -I -C x11-drivers/ gives a list, qlist is found in portage-utils package.
(In reply to comment #47) > Not sure why you have so many video drivers if you are using poulsbo, but > xorg-server package says after upgrade/downgrade how to rebuild all necessary > modules. These messages are meant for reading and following. > > In short, qlist -I -C x11-drivers/ gives a list, qlist is found in > portage-utils package. Thanks for the command! I must have missed that in the heat of the moment (as the process wasn't exactly straightforward.
Ok, so in the end, I'll be closing this bug since, like the duped bug, there was no bug per se. Thanks *** This bug has been marked as a duplicate of bug 291312 ***
Not so fast please. I am not yet through. I still get this error: (EE) module ABI major version (7) doesn't match the server's version (4) (EE) Failed to load module "kbd" (module requirement mismatch, 0) (EE) No input driver matching `kbd' And downgrading "per se" was not solved alone with the package.mask entry. Call it what you like but don't call it user-friendly.
Ok, closing, I am using evdev instead.
Reopening
And closing with the proper resolution. *** This bug has been marked as a duplicate of bug 291312 ***
Sorry could you please explain why it is a duplicate? I expect an explanation from you.
If you look closely, _you_ did all the work. _I_ changed nothing in portage. The package.mask entry was correct all along. And you somehow managed to downgrade all the packages manually instead of doing a world update that would have been much easier (but that was your choice). So again, and again, and _again_, this is a dupe of the other bug, whether you agree or not. The issues are the same (keeping xorg-server 1.6) and the solutions are the same (package.mask entry + downgrading). The only difference was that other users wanted to downgrade because of nvidia or ati drivers, and you want to downgrade because of psb... So _again_, this is a dupe. Please let _us_ manage bugzilla. The resolution of a bug in bugzilla have _meanings_ to us and we use them properly. So please, for the love of $DIETY, stop reopening this bug. You can still comment on it if you wish to, but please stop reopening it. Thanks *** This bug has been marked as a duplicate of bug 291312 ***
Thank you for the comment. So why did this command not work: emerge -1va @downgrade. Just to make it clear. This may be a duplicate from the the developers point of view. This for sure is not a a duplicate from the users point of view. Doing an emerge world to downgrade is never and option for me. Doing an emerge -1va @downgrade is always a very good option for me. Could you please take notice of that. Not all the users are the same and I always prefer the directer way. The reason why this bug should stay open is because emerge -1va @downgrade did not work and because that was the reason I opened this Bug-Report in the first place. So this bug is neither a duplicate nor is it solved except that you want it that way - because you may think that user feedback is not valuable. If you would think that user feedback is valuable then you would only close this bug when the user is happy. And that should be your goal: To make the user happy. Solving problems by closing bug reports and calling users "jerks" is a dead end street. So back to my question: Why did emerge -1va @downgrade. with the according package.mask not work? Why where the x11-proto packages not taken first by that command? Why did I have to do everything manually? Why where the x11-libs package not emerge in second place and why where there so many files I had to move manually to get this thing to work? Now if you are a real developer then you can answer those questions and those answers will improve Gentoo. And that again would help the user.
Let me preface this by saying I'm a Gentoo user, not a Gentoo developer, but I am a developer for my day-to-day job. Geez Zeno, you started the "name-calling" all the way back in comment #8 where you used the word "arrogant". Why make it personal? The other thing you need to understand is that Bugzilla is not a support forum, but you're using it like one. This issue would be much better handled in the forums where you have the eyes of hundreds or thousands of knowledgeable Gentoo users able to see and respond to your questions. Here... you only have the eyes of the small groups of *very busy* devs. I just happened on it because of the numerous "duplicate" messages in the other bug.
Not helpful. Why does emerge -1va @downgrade not work? If you are a user you should open your own bug-reports that concern you. If you are a developer you should help to build a better product together with the user.
(In reply to comment #56) > Thank you for the comment. > > So why did this command not work: > > emerge -1va @downgrade. > > Just to make it clear. TBH, I didn't know @downgrade even existed. As you know, the portage version you're currently using (2.2_rcX) is masked because it's a development version which may still have bugs. That's why I suggested @world, since this command worked fine for all the other users in the duped bug. > This may be a duplicate from the the developers point of > view. This for sure is not a a duplicate from the users point of view. Bugzilla is a developer tool, not an end-user tool. Of course it's opened to everyone, we're a community distro, but it's definitely not a forum. > Doing an emerge world to downgrade is never and option for me. You _should_ keep your system fully up-to-date at all times, that's what the Portage Handbook advises. > Doing an emerge > -1va @downgrade is always a very good option for me. Could you please take > notice of that. Not all the users are the same and I always prefer the directer > way. Again, @downgrade is an experimental feature, with bugs and shortcomings. > The reason why this bug should stay open is because > > emerge -1va @downgrade > > did not work and because that was the reason I opened this Bug-Report in the > first place. Then maybe you should have said so. At no point did you say what you'd tried prior to opening the bug report. You can't reasonably expect us to guess all that. > So this bug is neither a duplicate nor is it solved except that you want it > that way - because you may think that user feedback is not valuable. User feedback is very valuable. The problem was the _scope_ of this whole bug report. It started out as _one_ issue (the downgrading) but then exploded as a dozen other issues as you went. That's not how we work, it's just not possible. The Golden Rule of Bugzilla : One Issue, One Bug Report. (and that's not just our bugzilla) > If you > would think that user feedback is valuable then you would only close this bug > when the user is happy. And that should be your goal: To make the user happy. Nope, that's not how Open Source works. You're not a customer. I'm doing this on my free time, and _nobody_ gets to tell me how I'm supposed to work on Gentoo. Please always keep that in mind. > Solving problems by closing bug reports and calling users "jerks" is a dead end > street. And telling me to "go away" was not such a good idea either, as I'm one of the very few people who can actually help you here. You might be angry, you might be pissed off, but your attitude towards Rafał and me was downright _rude_. As for closing the bug, again, that's how we work with bugzilla. A closed bug doesn't mean we don't care or don't want to talk to you. It has a meaning to _us_. Please accept that. > So back to my question: Why did > > emerge -1va @downgrade. > > with the according package.mask not work? Why where the x11-proto packages not > taken first by that command? Why did I have to do everything manually? > Why where the x11-libs package not emerge in second place and why where there > so many files I had to move manually to get this thing to work? Ok, back to the technical part. Like I said earlier, @downgrade is an experimental feature and it might be a good idea to open a new bug for that issue (this one has grown too much to be of any use). Portage is a complex beast and it's outside my competence. As for manually moving the files, you shouldn't have done that. The reason was that some headers have moved between the proto package and the lib package between versions, so by doing the downgrade manually, you ended up with collisions. If @downgrade had worked properly, or if you'd done @world like I suggested, portage would have spotted the collisions but would have ignored them because everything would have been back in order at the end of the emerge phase. > Now if you are a real developer then you can answer those questions and those > answers will improve Gentoo. I think the time I've spent trying to help you fix this will speak for itself. As for improving Gentoo, that's my one and only goal and I do hope you'll realize that. Thanks
Thank you for your time and extended answer and effort. So to get off to a better start: Where shall I open this one then: Why did emerge -1va @downgrade for portage 2.2 rcx not work when downgrading xorg-server from version 1.7 to 1.6? That is what I would also expect that some developers are happy to pick up what one user like me found; one or several bugs in one bug report. Lets just try to improve Gentoo. So in a way this Bug-Report also helped you to get to know a new feature: emerge -1va @downgrade for downgrading any package with portage after version 2.2 As for Gentoo vs Ubuntu vs any other Linux distro. I think we can all learn from each other. And if we can just improve that downgrading process a bit in Gentoo, that would be great. Lets try to make it less of a version-bumping kind of thing and more of a "I can bump to any version I exactly choose". And if that is not in the Handbook I suggest putting it there. Why? Because we will always have the issue with closed source drivers that only work with certain older versions of open-source software. So lets get used to that. Poulsbo (gma500) will not be the last closed-source driver that causes havoc as so happened here with this Bug-Report.
