#11246: flint-1.5.0.p5's extraneous #includes break typedef ulong in sys/types.h
-----------------------------------+----------------------------------------
   Reporter:  dimpase              |          Owner:  tbd            
       Type:  defect               |         Status:  positive_review
   Priority:  major                |      Milestone:  sage-4.7.1     
  Component:  packages             |       Keywords:                 
Work_issues:                       |       Upstream:  N/A            
   Reviewer:  Karl-Dieter Crisman  |         Author:  Dima Pasechnik 
     Merged:                       |   Dependencies:                 
-----------------------------------+----------------------------------------

Comment(by leif):

 Replying to [comment:20 dimpase]:
 > Replying to [comment:19 kcrisman]:
 > > Interestingly, I was just chewed out on another ticket for having cut
 some lines in that file down to size!   It's true that the new lines are
 just a little over that, apparently.

 Of course you shouldn't cut them, but reformat the text such that none of
 the lines will exceed 80 characters (same for longer, i.e. all but the
 first line of commit messages). ;-)

 If doing so would dominate other, more important changes in the diff, you
 can still provide a separate patch for that. (There is no patch or spkg-
 diff for review attached to this ticket anyway.)

 Dave, me, and others have reformatted any `SPKG.txt` we came across in the
 past in case it was necessary. Once overlong lines are eliminated, it's
 much more likely people will intuitively adhere without ever looking at
 their editor's status bar.

 [[BR]]

 > > >  * the patches are applied without any error checking.
 > > You mean
 {{{
 +for j in `ls patches/*.patch` ; do
 +   patch -p0 < $j
 +done
 }}}
 > > Do we ever do error checking for these?  Most spkg-install files seem
 to have just "cp" or "patch".   What should be added?
 >
 > IMHO there is no need to check in `spkg-install` that patches apply
 correctly  --- going this way, one woud also could start asking for a
 check that tar worked correctly, etc...

 We do of course check exit codes (or indirectly the success) of `tar` and
 other commands that can spectacularly fail...

 Fortunately, we now use `patch` rather than `cp`, which at least spits out
 warning or error messages in case upstream and `patches/*` get out of sync
 (or someone made another mistake), but these messages are easily missed -
 even by a reviewer, which can lead to all kinds of obscure errors or
 misbehavior ''any time later'', so we should IMHO check `$?` there.

 `bash`'s not Python, where we would (hopefully) get a nice, instructive
 traceback.

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11246#comment:21>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sage-trac?hl=en.

Reply via email to