#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.