I'll attach a patch, which fixes/adjusts misc stuff, and is used by SuSE since a long time. At least some of the hunks might be useful in X.Org upstream as well. Needs to be discussed. The Component should be "Other".
Created attachment 1046 [details] [review] p_suse.diff
Misch stuff?
reopen.
Created attachment 1112 [details] [review] p_suse.diff.new
.
Comment on attachment 1112 [details] [review] p_suse.diff.new sndirscg: COuld you please split the Xprint changes into a seperate bug ? They may be interesting for the X11R6.8.x stable branch...
I don't think so. These patches only fix warnings. This is only something for CVS HEAD.
Stefan Dirsch write: > I don't think so. These patches only fix warnings. This is only something for > CVS HEAD. Depends... the PsCreateColorMap() fix is something critical as it may cause application failure and the fix in .../Xprint/oid.c falls into the "can-crash-Xprt"-category. Only the fix for "attributes.c" is currently of cosmetic nature - unless one of the DDXs starts to check for that value. Anyway... I filed (and commiteed patches to "trunk") the following spin-off bug reports: - Bug 1637 ("switch default handling is missing, generates warning") (filed by Egbert) - Bug 1646 ("PsCreateColormap() returns random value") - Bug 1647 ("XpSubmitJob()| returns a random value instead of a status return code")
(Dumb ?!) question: > --- programs/xman/vendor.h.old 2003-10-27 15:02:29.000000000 +0100 > +++ programs/xman/vendor.h 2003-10-27 15:06:53.000000000 +0100 > @@ -167,8 +167,8 @@ > # elif defined(BSD) && (BSD >= 199103) > # define FORMAT "| eqn | tbl | nroff -man"> > # elif defined(linux) > -# define FORMAT "| eqn | tbl | GROFF_NO_SGR= groff -Tlatin1 -mandoc" > +# define FORMAT "| pic | eqn -Tlatin1 | tbl | GROFF_NO_SGR= groff -Tlatin1 > -mandoc" > # else > # define FORMAT "| neqn | nroff -man" /* The format command. */ > # endif What will happen in the case that the manual page returns chars outside ISO-Latin1 (for example: japanese manual pages) ? Currently "xman" doesn't support multibyte locales but it's on my ToDo list to fix that. How will the patch affect processing of such manual pages ?
> Anyway... I filed (and commiteed patches to "trunk") the following spin-off bug > reports: Great! Now I can revert all the changes I have prepared for commit! Thanks a lot to you two for generating even more work for me! The fixes I have planned to commit were exactly identical to what Roland has committed. Before I commit patches that I have not made I try to review them. I have changed all Xprint patches exactly the way Roland has done (except that I didn't remove the breaks in 1637 after talking to Roland about it. There is no use in duplicating my work and generating even more work for me by *forcing* me to undo the changes in my commit tree.
I'm sorry, this was not my intention. Roland, please stop committing any patches in bugreports, which are assigned to Egbert or me, i.e. Bugreports 1568 1569 1571 1573 1574 1576 1577 1578 1579 1580 1584 Thanks.
I've prepared this for commit already. Please don't take any chunks from here to commit them. If there are any comments please add them here.
Egbert Eich wrote: > > Anyway... I filed (and commiteed patches to "trunk") the following spin-off > > bug reports: > > Great! Now I can revert all the changes I have prepared for commit! > Thanks a lot to you two for generating even more work for me! Erm... that's completly my fault, sndirsch is innocent in this case... Sorry... ;-((( > The fixes I have planned to commit were exactly identical to what Roland has > committed. Before I commit patches that I have not made I try to review them. > I have changed all Xprint patches exactly the way Roland has done (except that > I didn't remove the breaks in 1637 after talking to Roland about it. I've asked around on IRC and it seems none of the vendor compilers (Solaris, IRIX) complains anymore in the |return foo; break;| case (it's more likely that some day you'll get complains for the redundant |break| these days... :) > There is no use in duplicating my work and generating even more work for me by > *forcing* me to undo the changes in my commit tree. Sorry... it wasn't my intention to cause any trouble or problems for you... I thought that splitting the patches from this one would even reduce your workload and would help to seperate things for the stable branch...
OK, committed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.