Discussion:
Bug#905940: Please resolve failing autopkgtests, preferably by converting to dh-elpa
(too old to reply)
Nicholas D Steeves
2018-08-12 01:40:01 UTC
Permalink
Package: tuareg-mode
Severity: important

Dear Debian OCaml Maintainers,

Thank you for maintaining tuareg-mode! Unfortunately it's
autopkgtests have been failing since emacsen-common 3.0.2 and
unversioned emacs were uploaded, and tuareg-mode is delaying their
migration to testing. Would you please adapt tuareg-mode to the new
infrastructure?

In the case of irony-mode, the quick fix for autopkgtest on LXC was to
add "ert_eval = (require 'cl)" to debian/elpa-test; this was not
required for tests to pass on a real system or in any type of chroot.
The use of d/elpa-test requires converting the package to use dh-elpa
rather than legacy debian/emacsen.scripts. In addition to the general
case of making src:packages maintenance less burdensome, using dh-elpa
appears to have insulated many packages from the breaking changes
recently introduced by emacs upgrades.

This action will also close #850071, #582981, because dh-elpa does not
support XEmacs.

Please let me know if I can be of any assistance :-)

Cheers,
Nicholas
Ralf Treinen
2018-08-16 08:20:02 UTC
Permalink
Hello,
Post by Nicholas D Steeves
Package: tuareg-mode
Severity: important
Dear Debian OCaml Maintainers,
Thank you for maintaining tuareg-mode! Unfortunately it's
autopkgtests have been failing since emacsen-common 3.0.2 and
unversioned emacs were uploaded, and tuareg-mode is delaying their
migration to testing.
This is done for now.
Post by Nicholas D Steeves
Would you please adapt tuareg-mode to the new
infrastructure?
In the case of irony-mode, the quick fix for autopkgtest on LXC was to
add "ert_eval = (require 'cl)" to debian/elpa-test; this was not
required for tests to pass on a real system or in any type of chroot.
The use of d/elpa-test requires converting the package to use dh-elpa
rather than legacy debian/emacsen.scripts. In addition to the general
case of making src:packages maintenance less burdensome, using dh-elpa
appears to have insulated many packages from the breaking changes
recently introduced by emacs upgrades.
This action will also close #850071, #582981, because dh-elpa does not
support XEmacs.
Please let me know if I can be of any assistance :-)
If moving to dh-elpa allows us to get rid of the debian/emacsen.*
scripts then I am all for it. However, I don't know anything about elpa
and probably won't have the time to look into it for the next future,
so patches are welcome!

-Ralf.
Nicholas D Steeves
2019-01-22 22:50:02 UTC
Permalink
Post by Ralf Treinen
Hello,
Post by Nicholas D Steeves
Package: tuareg-mode
Severity: important
Would you please adapt tuareg-mode to the new
infrastructure?
In the case of irony-mode, the quick fix for autopkgtest on LXC was to
add "ert_eval = (require 'cl)" to debian/elpa-test; this was not
required for tests to pass on a real system or in any type of chroot.
The use of d/elpa-test requires converting the package to use dh-elpa
rather than legacy debian/emacsen.scripts. In addition to the general
case of making src:packages maintenance less burdensome, using dh-elpa
appears to have insulated many packages from the breaking changes
recently introduced by emacs upgrades.
This action will also close #850071, #582981, because dh-elpa does not
support XEmacs.
Please let me know if I can be of any assistance :-)
If moving to dh-elpa allows us to get rid of the debian/emacsen.*
scripts then I am all for it. However, I don't know anything about elpa
and probably won't have the time to look into it for the next future,
so patches are welcome!
-Ralf.
Hi Ralf,

Done. Here's the MR:

https://salsa.debian.org/ocaml-team/tuareg-mode/merge_requests/1

Please note that autopkgtests for Tuareg require one of:

1. ocaml-mode being elpafied too.
2. a manual workaround to pull in ocaml-mode to the autopkgtestbed.

I'm also unable to confirm whether the LXC+autopkgtest cl/cl-lib fix
is needed because of this blocker.

I hope my changelog and commit history shows how easy it will be to
convert ocaml-mode to elpa-caml <- not a typo.

https://stable.melpa.org/#/caml

Cheers,
Nicholas
Ralf Treinen
2019-01-24 07:10:01 UTC
Permalink
Hi Nicholas,

thanks for working on this package.
Post by Nicholas D Steeves
https://salsa.debian.org/ocaml-team/tuareg-mode/merge_requests/1
1. ocaml-mode being elpafied too.
2. a manual workaround to pull in ocaml-mode to the autopkgtestbed.
I will look to your proposed changes soon. Though I do not see
why you mixed this up with unrelated cosmetic modifications. Renaming
tuareg-mode, however, is out of question.

-Ralf.
Nicholas D Steeves
2019-02-04 06:50:01 UTC
Permalink
Hi Ralf,
Post by Ralf Treinen
Hi Nicholas,
thanks for working on this package.
You're welcome :-)
Post by Ralf Treinen
Post by Nicholas D Steeves
https://salsa.debian.org/ocaml-team/tuareg-mode/merge_requests/1
1. ocaml-mode being elpafied too.
2. a manual workaround to pull in ocaml-mode to the autopkgtestbed.
I will look to your proposed changes soon. Though I do not see
why you mixed this up with unrelated cosmetic modifications. Renaming
tuareg-mode, however, is out of question.
I included the whitespace cleanup as a courtesy, and for the sake of
completeness. Is it unwanted? Unless I made a mistake somewhere
there should be one operation per commit so it will be easy to drop
any unwanted commits.

As for bin:tuareg-mode vs bin:elpa-tuareg-mode, the former requires
extra work (kind of like a "Provides: virtual-package", but for
Package.el rather than dpkg). Here is a brief case for
bin:elpa-tuareg

1. Compatibility with GNU ELPA/MELPA/Package.el without extra work. eg:
https://melpa.org/#/tuareg, and not https://melpa.org/#/tuareg-mode

2. The mode is named "tuareg.el", "tuareg.el" has "(provide 'tuareg)"
rather than "(provide 'tuareg-mode)".

3. Upstream README.md refers to the software as "Tuareg" rather than
"tuareg-mode". I edited the descriptions for consistency with MELPA
and upstream documentation.

Do you prefer consistency with historical/existing Debian package
names rather than consistency with what Emacs uses for its own
dependency resolution and with MELPA? That's fine with me, but please
share your rationale. Also affects bin:ocaml-mode vs bin:elpa-caml

I'd be happy to do a v2 MR asap, after learning what the contentious
issues/commits are. :-)

Cheers,
Nicholas
Nicholas D Steeves
2019-08-11 22:50:01 UTC
Permalink
Hi Ralf,

Gentle ping, any progress on that MR review.

Thanks,
Nicholas
Ralf Treinen
2019-08-15 19:40:01 UTC
Permalink
Hi Nicholas,
Post by Nicholas D Steeves
Gentle ping, any progress on that MR review.
sorry for the long non-reply. In fact I will first (hopefully tomorrow)
upload an elpa-fied version of caml-mode, which is the new name upstream
has chosen for the old ocaml-mode. Upstream has now separated this from the
ocaml distribution, so that makes things much easier. Since this is a
Recommends of elpa-tuareg it goes first. It will have to go through NEW
so it make take a bit. Then, tuareg will be next.

Cheers -Ralf.

Loading...