orpheus does not build on mips64

  • Done
  • quality assurance status badge
Details
4 participants
  • Andreas Enge
  • Carlos Pita
  • Leo Famulari
  • Mark H Weaver
Owner
unassigned
Submitted by
Andreas Enge
Severity
normal

Debbugs page

Andreas Enge wrote 10 years ago
(address . bug-guix@gnu.org)
20150202222819.GA26430@debian
Hello,

the orpheus package fails to build on mips64 with the following message:

checking build system type... ./config.guess: unable to guess system type
This script, last modified 2001-07-12, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from
ftp://ftp.gnu.org/pub/gnu/config/

Orpheus itself seems to be unmaintained (the last release dates from 2006).
I would suggest to either drop the package, or to disable it on mips.

Andreas
Mark H Weaver wrote 10 years ago
(name . Andreas Enge)(address . andreas@enge.fr)(address . 19749@debbugs.gnu.org)
87a90vcyyx.fsf@netris.org
Andreas Enge <andreas@enge.fr> writes:

Toggle quote (10 lines)
> the orpheus package fails to build on mips64 with the following message:
>
> checking build system type... ./config.guess: unable to guess system type
> This script, last modified 2001-07-12, has failed to recognize
> the operating system you are using. It is advised that you
> download the most up to date version of the config scripts from
> ftp://ftp.gnu.org/pub/gnu/config/
>
> Orpheus itself seems to be unmaintained (the last release dates from 2006).

The config.guess problem can be easily worked around by passing
--build=<triplet> to configure. I would suggest something similar to
what I did in the gmp package to get it working on armhf:

(arguments `(#:configure-flags
'(;; Build a "fat binary", with routines for several
;; sub-architectures.
"--enable-fat"
"--enable-cxx"

;; FIXME: gmp-6.0.0a's config.guess fails on
;; multi-core armhf systems.
,@(if (%current-target-system)
'()
(let ((triplet
(nix-system->gnu-triplet (%current-system))))
(list (string-append "--build=" triplet)))))))

Would you like to try this?

Toggle quote (2 lines)
> I would suggest to either drop the package, or to disable it on mips.

Please, let's not disable builds on MIPS unless it is clear that it
would be a very difficult job to get it working.

Mark
Andreas Enge wrote 10 years ago
(name . Mark H Weaver)(address . mhw@netris.org)(address . 19749@debbugs.gnu.org)
20150204162021.GA23747@debian.eduroam.u-bordeaux.fr
On Tue, Feb 03, 2015 at 01:04:38AM -0500, Mark H Weaver wrote:
Toggle quote (18 lines)
> The config.guess problem can be easily worked around by passing
> --build=<triplet> to configure. I would suggest something similar to
> what I did in the gmp package to get it working on armhf:
> (arguments `(#:configure-flags
> '(;; Build a "fat binary", with routines for several
> ;; sub-architectures.
> "--enable-fat"
> "--enable-cxx"
>
> ;; FIXME: gmp-6.0.0a's config.guess fails on
> ;; multi-core armhf systems.
> ,@(if (%current-target-system)
> '()
> (let ((triplet
> (nix-system->gnu-triplet (%current-system))))
> (list (string-append "--build=" triplet)))))))
> Would you like to try this?

Alternatively, could we not simply copy a newer config.guess as a patch
into the source tree? If yes, what would be preferable?

Andreas
Mark H Weaver wrote 10 years ago
(name . Andreas Enge)(address . andreas@enge.fr)(address . 19749@debbugs.gnu.org)
878ugcwdck.fsf@yeeloong.lan
Andreas Enge <andreas@enge.fr> writes:

Toggle quote (22 lines)
> On Tue, Feb 03, 2015 at 01:04:38AM -0500, Mark H Weaver wrote:
>> The config.guess problem can be easily worked around by passing
>> --build=<triplet> to configure. I would suggest something similar to
>> what I did in the gmp package to get it working on armhf:
>> (arguments `(#:configure-flags
>> '(;; Build a "fat binary", with routines for several
>> ;; sub-architectures.
>> "--enable-fat"
>> "--enable-cxx"
>>
>> ;; FIXME: gmp-6.0.0a's config.guess fails on
>> ;; multi-core armhf systems.
>> ,@(if (%current-target-system)
>> '()
>> (let ((triplet
>> (nix-system->gnu-triplet (%current-system))))
>> (list (string-append "--build=" triplet)))))))
>> Would you like to try this?
>
> Alternatively, could we not simply copy a newer config.guess as a patch
> into the source tree? If yes, what would be preferable?

The patch would be quite large. I think it's cleaner to pass --build.

In fact, I think we should pass --build to _all_ builds by default,
because on several architectures config.guess looks at /proc/cpuinfo and
the output of uname to optimize for the particular CPU in the build
machine, which I think we don't want. However, Ludovic resisted and I
haven't yet had time to follow up on that.

Thanks,
Mark
Carlos Pita wrote 10 years ago
(address . 19749@debbugs.gnu.org)
CAELgYhc5+xf3zM5mTKix48Qz02-5wYbbXp3bU_2wG0mYAcU2hA@mail.gmail.com
Sorry for reopening this, Fabián. You're right in pointing that this
bug was introduced by my fix to 19665. But AFAICS 19665 is indeed a
bug: you want to go to the end of the defun line when the search is
backward, in order to match arg defun including the current one.

There is a more difficult problem here. Say * is the point:

1) You want C-M-a to move the point from def* to *def.

2) You want C-M-a to mode the point from *def to the previous definition.

(1) is addressed by 19665.
(2) is addressed by this report.

Still, there is:

3) You want C-M-h both in def* and in *def to select the current
defun. 19665 was intended to correct both cases (*def and def*), but
my patch here breaks again the case *def (because for *def the
selection reverts now to the pathological behavior described in 19665,
just because of the additional condition in the guard, which should be
kept anyway because of (2)).

Note: I'm checking my assertions 1, 2 and 3 against the standard
behavior of elisp mode, which I take as a reference. That's indeed the
behavior there.

More briefly: for C-M-a you want to distinguish between def* and *def,
but for C-M-h you don't. The previous fix here and 19665 correctly
address (1) and (2), and mostly address (3) except for the corner case
*class, which I address in what follows.

Looking at the definition of mark-defun one could clearly see what the
problem is. Starting from *class, say, mark-defun will mark the
previous defun and then check (if (> (point) opoint) to see that the
selected defun was not the desired one. So it goes through the else
part sending the point to the end of the class block and then moving
backward one defun to select just the last method. I think we could
fix this tweaking a bit the behavior of mark-defun, but -unusually-
mark-defun allows for no local extension points. A simple advice could
do the trick but I don't feel like adding an advice just for python
sake to a globally and often used function. The last option I'm able
figure out is to replace mark-defun in the python keymap. This is not
perfect, as mark-defun could be used programatically also, but I
believe it's good enough:

(define-key map [remap mark-defun] 'python-mark-defun)

(defun python-mark-defun ()
(interactive)
(when (python-info-looking-at-beginning-of-defun)
(end-of-line 1))
(mark-defun))

Besides that, I want to emphazise that you still need:

- (when (and (< arg 0)
+ (when (and (> arg 0)

and

+ (> (current-column) (current-indentation))

Cheers
--
Carlos
Carlos Pita wrote 10 years ago
(address . 19749@debbugs.gnu.org)(name . Fabián Ezequiel Gallina)(address . fgallina@gnu.org)
CAELgYhf9fQ4Y-iT-5V0=X0w5aVNEACjrR4RPLKcixFa4SfTgfA@mail.gmail.com
Also, you could want to set allow-extend for mark-defun.

I will post a patch to 19665 including the original change and the
mark-defun fix.

The (> (current-column) (current-indentation)) fix in this report
remains valid except you worked out a cleaner solution for 1, 2 and 3
above.


On Mon, Feb 9, 2015 at 1:10 PM, Carlos Pita <carlosjosepita@gmail.com> wrote:
Toggle quote (66 lines)
> Sorry for reopening this, Fabián. You're right in pointing that this
> bug was introduced by my fix to 19665. But AFAICS 19665 is indeed a
> bug: you want to go to the end of the defun line when the search is
> backward, in order to match arg defun including the current one.
>
> There is a more difficult problem here. Say * is the point:
>
> 1) You want C-M-a to move the point from def* to *def.
>
> 2) You want C-M-a to mode the point from *def to the previous definition.
>
> (1) is addressed by 19665.
> (2) is addressed by this report.
>
> Still, there is:
>
> 3) You want C-M-h both in def* and in *def to select the current
> defun. 19665 was intended to correct both cases (*def and def*), but
> my patch here breaks again the case *def (because for *def the
> selection reverts now to the pathological behavior described in 19665,
> just because of the additional condition in the guard, which should be
> kept anyway because of (2)).
>
> Note: I'm checking my assertions 1, 2 and 3 against the standard
> behavior of elisp mode, which I take as a reference. That's indeed the
> behavior there.
>
> More briefly: for C-M-a you want to distinguish between def* and *def,
> but for C-M-h you don't. The previous fix here and 19665 correctly
> address (1) and (2), and mostly address (3) except for the corner case
> *class, which I address in what follows.
>
> Looking at the definition of mark-defun one could clearly see what the
> problem is. Starting from *class, say, mark-defun will mark the
> previous defun and then check (if (> (point) opoint) to see that the
> selected defun was not the desired one. So it goes through the else
> part sending the point to the end of the class block and then moving
> backward one defun to select just the last method. I think we could
> fix this tweaking a bit the behavior of mark-defun, but -unusually-
> mark-defun allows for no local extension points. A simple advice could
> do the trick but I don't feel like adding an advice just for python
> sake to a globally and often used function. The last option I'm able
> figure out is to replace mark-defun in the python keymap. This is not
> perfect, as mark-defun could be used programatically also, but I
> believe it's good enough:
>
> (define-key map [remap mark-defun] 'python-mark-defun)
>
> (defun python-mark-defun ()
> (interactive)
> (when (python-info-looking-at-beginning-of-defun)
> (end-of-line 1))
> (mark-defun))
>
> Besides that, I want to emphazise that you still need:
>
> - (when (and (< arg 0)
> + (when (and (> arg 0)
>
> and
>
> + (> (current-column) (current-indentation))
>
> Cheers
> --
> Carlos
Carlos Pita wrote 10 years ago
(address . 19749@debbugs.gnu.org)
CAELgYhcdsFSX46tsfKr5yKmVy7ghmKUZzsJtEknFr-SyFV5PoA@mail.gmail.com
Sorry for the typo, the last two comments were intended to be for
19748. I don't know if it's possible to delete them from debbugs
control interface. Shame on me.
Andreas Enge wrote 6 years ago
Progress
(address . 19749@debbugs.gnu.org)(name . Mark H Weaver)(address . mhw@netris.org)
20190219225341.GB2828@jurong
Hello,

this bug dates from a time where it was still almost realistic to reach
zero non-building packages... Should we close it, since mips has been
removed from the release architectures?

Andreas
Leo Famulari wrote 6 years ago
(name . Andreas Enge)(address . andreas@enge.fr)(address . 19749-done@debbugs.gnu.org)
20190220055253.GA10187@jasmine.lan
On Tue, Feb 19, 2019 at 11:53:41PM +0100, Andreas Enge wrote:
Toggle quote (6 lines)
> Hello,
>
> this bug dates from a time where it was still almost realistic to reach
> zero non-building packages... Should we close it, since mips has been
> removed from the release architectures?

Yes, I've closed it.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlxs6zUACgkQJkb6MLrK
fwh2gA/8DghyadNTmhmuFDn4CpJkYprVpLCa0yU7aMBRSapDbD41ihiek62sW4cp
vEmC4wfofS79sS4fVV4El5DIdudthL76qqnzvTuk8DCxy46nqSq9cBAmw4bCaBPo
AZEK1nlEmIG09KPXtqNLEj96EonWfmTKp3lL2tRsmBQfEQfhjE3VUBGlOfq8ZSLB
Geky1Ci37Y9b+4hxIfaK3/DfkKQsWg6+tnIegwU52a+M6UA3T9NaxT89gJA5XNhx
tjbOONKMRPJaPGXHU3vfm2224I0/xwn/ezqsT75eLnZesIxyJc2P2juqKTSONLLn
mEfZ06A3DAmnbXW0DksdLeWhQ+zR425pU5V0wi+VRdixaPw6oyz+kOZt6lXjtPQi
IAN0HFzd86HMeEI/W+ePnUVmHowlPZ2r8RJQ2ThFtciohGxrtVyq+qFEG/nwAW8Y
XI+wTrCmJFJHX0U06ku1Vmdtd2+Qr4JfpsKWxL5xQY5mCPUSxoo7HKZ95N0D30I3
3oSPOUzCc5pUyPu4bCTHiHIE36RVUhEmj75k/2pSYR4lpt/EoOoEK16pIsByNpxX
G2fTrQJGIejr2JSYNNtYN0cyvTJ/XBzHhpIDQwOJV4om0c9igAF54OmKQ3IH6sAW
7+0nFxzeo3r6AGFsW8Xt7ZIggZ2E92AGG01PJUBCfSJyM53mY7g=
=D5Pl
-----END PGP SIGNATURE-----


Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 19749@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 19749
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help