Re: Re-evaluating architecture inclusion in unstable/experimental
Svante Signell, le dim. 02 sept. 2018 23:39:08 +0200, a ecrit: > On Sun, 2018-09-02 at 19:46 +0200, Samuel Thibault wrote: > > Svante Signell, le dim. 02 sept. 2018 19:45:19 +0200, a ecrit: > > > On Sun, 2018-09-02 at 15:21 +0200, Samuel Thibault wrote: > > > > > > > > > > > > The statistics and graphs available on the debian-ports page[1] may > > > > > provide some objective statistics or reflection on the actual > > > > > suitability of your architecture's continued inclusion. > > > > > [1]: https://buildd.debian.org/stats/ > > > > > > > > Such statistics are really difficult to get any real conclusion from. > > > > Sometimes 10% packages are missing just for one tricky nonLinux-specific > > > > issue in one package. > > > > > > Correct: One example is cmake for both hurd-i386 and kfreebsd-any. > > > It does not even have to be tricky. > > > > If it's not tricky, a NMU should be able to fix it easily. > > I'm sorry Samuel, I asked both you and James Clarke, Cc:ed, for help on this > issue and you both said it was not possible to NMU cmake, even if you are both > DD's. For my part, I was not talking about that patch, but about the hurd-related patches. For others, I can simply quote what was said: Felix Geyer wrote: > I suggest that instead you respond to questions on bugs you opened. > I'm not interested in maintaining patches for things that clearly > belong upstream. Once upstream has reviewed the changes I'm happy to > cherry-pick them. And I agree with it (and also one of the reasons why I didn't just NMU-ed cmake with the hurd patch). > I think that the power of a package maintainer is far too big, making it > possible to reject/ignore important and other bugs, especially with patches, > for > non-released architectures (and effectively block NMUs). He is not rejecting things, he is saying that belongs to upstream, which is true. Help with that and things will flow. > I think the next step would be to bring the responsibilities and commitments > of > a Package Maintainer to the TC, Nope. > Maybe the recent salvaging of packages could be helpful in the future > regarding this problem. Nope. Samuel
Re: Re-evaluating architecture inclusion in unstable/experimental
Svante Signell, le dim. 02 sept. 2018 19:45:19 +0200, a ecrit: > On Sun, 2018-09-02 at 15:21 +0200, Samuel Thibault wrote: > > > > > > The statistics and graphs available on the debian-ports page[1] may > > > provide some objective statistics or reflection on the actual > > > suitability of your architecture's continued inclusion. > > > [1]: https://buildd.debian.org/stats/ > > > > Such statistics are really difficult to get any real conclusion from. > > Sometimes 10% packages are missing just for one tricky nonLinux-specific > > issue in one package. > > Correct: One example is cmake for both hurd-i386 and kfreebsd-any. > It does not even have to be tricky. If it's not tricky, a NMU should be able to fix it easily. Samuel
Re: Re-evaluating architecture inclusion in unstable/experimental
On Mon, 2018-09-03 at 01:07 +0200, Samuel Thibault wrote: > > > So has the debian patch been submitted in #900240 upstream by you or Petter > > Reinholdtsen yet? I don't believe so! > > I don't think so either, it'd be marked forwarded. That doesn't mean you > can't help with it. Regardless who is submitting patches upstream, two problem remains: 1) The delay until upstream makes a new release. 2) The delay until the Debian Maintainer creates an updated package from that release (if ever). Example: emacs26 And how many maintainers do cherry-pick patches accepted upstream, very few :(
Re: Re-evaluating architecture inclusion in unstable/experimental
On Sun, 2018-09-02 at 19:46 +0200, Samuel Thibault wrote: > Svante Signell, le dim. 02 sept. 2018 19:45:19 +0200, a ecrit: > > On Sun, 2018-09-02 at 15:21 +0200, Samuel Thibault wrote: > > > > > > > > > The statistics and graphs available on the debian-ports page[1] may > > > > provide some objective statistics or reflection on the actual > > > > suitability of your architecture's continued inclusion. > > > > [1]: https://buildd.debian.org/stats/ > > > > > > Such statistics are really difficult to get any real conclusion from. > > > Sometimes 10% packages are missing just for one tricky nonLinux-specific > > > issue in one package. > > > > Correct: One example is cmake for both hurd-i386 and kfreebsd-any. > > It does not even have to be tricky. > > If it's not tricky, a NMU should be able to fix it easily. I'm sorry Samuel, I asked both you and James Clarke, Cc:ed, for help on this issue and you both said it was not possible to NMU cmake, even if you are both DD's. See bugs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905140 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900240 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905138 I think that the power of a package maintainer is far too big, making it possible to reject/ignore important and other bugs, especially with patches, for non-released architectures (and effectively block NMUs). I think the next step would be to bring the responsibilities and commitments of a Package Maintainer to the TC, in addition to the full control of everything related to that package. Maybe the recent salvaging of packages could be helpful in the future regarding this problem.
Re: Re-evaluating architecture inclusion in unstable/experimental
Svante Signell, le lun. 03 sept. 2018 01:18:20 +0200, a ecrit: > On Mon, 2018-09-03 at 01:07 +0200, Samuel Thibault wrote: > > > > > So has the debian patch been submitted in #900240 upstream by you or > > > Petter > > > Reinholdtsen yet? I don't believe so! > > > > I don't think so either, it'd be marked forwarded. That doesn't mean you > > can't help with it. > > Regardless who is submitting patches upstream, two problem remains: > 1) The delay until upstream makes a new release. Nope, the maintainer said he was happy to cherry-pick. > 2) The delay until the Debian Maintainer creates an updated package from that > release (if ever). Example: emacs26 Again, cherry-pick don't need to wait for the introduction of the new release to Debian. > And how many maintainers do cherry-pick patches accepted upstream, very few > :( Here the maintainer explicitly said we would happily do it. Samuel
Re: Re-evaluating architecture inclusion in unstable/experimental
On Sun, 2018-09-02 at 15:21 +0200, Samuel Thibault wrote:
>
> > The statistics and graphs available on the debian-ports page[1] may
> > provide some objective statistics or reflection on the actual
> > suitability of your architecture's continued inclusion.
> > [1]: https://buildd.debian.org/stats/
>
> Such statistics are really difficult to get any real conclusion from.
> Sometimes 10% packages are missing just for one tricky nonLinux-specific
> issue in one package.
Correct: One example is cmake for both hurd-i386 and kfreebsd-any.
It does not even have to be tricky. For kfreebsd the patch(es) is attached
below!
Index: cmake-3.11.2/bootstrap
===
--- cmake-3.11.2.orig/bootstrap
+++ cmake-3.11.2/bootstrap
@@ -1352,7 +1352,7 @@ else
libs="${libs} -ldl -lrt"
;;
*BSD*)
- libs="${libs} -lkvm"
+ libs="${libs} -lkvm -lfreebsd-glue"
;;
*SunOS*)
# Normally libuv uses '-D_XOPEN_SOURCE=500 -std=c90' on Solaris 5.10,
--- a/debian/control 2018-05-19 10:51:17.0 +0200
+++ b/debian_control 2018-07-29 17:38:11.272777000 +0200
@@ -15,6 +15,7 @@
librhash-dev,
libuv1-dev (>= 1.10),
procps [!hurd-any],
+ freebsd-glue [kfreebsd-any],
python3-sphinx,
qtbase5-dev ,
zlib1g-dev
Re: Re-evaluating architecture inclusion in unstable/experimental
Svante Signell, le lun. 03 sept. 2018 01:06:11 +0200, a ecrit: > On Mon, 2018-09-03 at 00:19 +0200, Samuel Thibault wrote: > > Felix Geyer wrote: > > > I suggest that instead you respond to questions on bugs you opened. > > > I'm not interested in maintaining patches for things that clearly > > > belong upstream. Once upstream has reviewed the changes I'm happy to > > > cherry-pick them. > > This is a comment on the Hurd bug, #900200, not the kfreebsd one, #905138. That doesn't mean the comment doesn't hold generally. > And I did not open that bug, you did! That doesn't mean you can't help with it. > > And I agree with it (and also one of the reasons why I didn't just > > NMU-ed cmake with the hurd patch). > > So has the debian patch been submitted in #900240 upstream by you or Petter > Reinholdtsen yet? I don't believe so! I don't think so either, it'd be marked forwarded. That doesn't mean you can't help with it. Samuel
