On Mon, 15 Jul 2019 at 14:53, Fabio Valentini <decatho...@gmail.com> wrote:
> On Mon, Jul 15, 2019, 19:33 Kevin Fenzi <ke...@scrye.com> wrote: > >> On 7/15/19 5:43 AM, Fabio Valentini wrote: >> >> > (I for one am still semi-regularly building stuff in the mock >> > fedora-rawhide-i686 chroots, especially for testing if things still >> > work on 32bit systems (be it armv7hl or i686) - I know that this will >> > probably continue to work somehow, but making it more complicated is >> > hostile to developers and packagers who care about their packages >> > working on all architectures.) >> >> Well, it wouldn't be more complicated. Mock would just download from a >> different repo in that case. >> >> Also, if it's 32bit you are testing, perhaps some cheap armv7 device >> would be a better platform moving forward? >> >> kevin >> > > I have a Raspberry Pi 2 Model B somewhere, but the experience of trying to > build some packages on it a while ago was ... testing my patience, let's > say. Maybe a faster SD card would help, but I'm guessing that using > "--forcearch armv7hl" to force qemu emulation in mock on my main PC's > pretty beefy CPU would still be a better experience. Additionally there's > no 32bit arm chroots supported in COPR, which complicates the situation for > 32bit support even more. > > But that's a bit beside the point I wanted to make. I've been struggling > to keep the Java stack building at all (mostly Stewardship SIG packages), > and the removal of 32bit support in eclipse has made that even more > difficult. > > Even still, dozens of Java packages either won't build or won't install on > 32bit arches because of that (mostly because gradle isn't installable > anymore, because jgit is gone on 32bit). Even the modular Java packages > don't support 32bit arches anymore. > > If we start to relegate i686 to a tertiary architecture only intended for > multilib use (which is basically the effect of this proposal), there'll be > even fewer reasons to fix things or keep things working on 32bit. I mean, > I'm already tempted to just start dropping things ... because, well, it's > not like anybody seems to care about those packages anyway. > > The problem is that most upstreams have lost interest in 32 bit anymore so the only people who are banging the drum on it are the maintainers who seem to feel they have to keep it going. We are trying to say 'you don't have to keep it going on an arch if you don't want to.' Anyone who starts complaining that it is the maintainers job to make 32 bit work for them needs to take the package over completely. You aren't paid to do this, and it is meant to be something you enjoy doing. If there is no joy.. then don't do it. > Fabio > > >> >> _______________________________________________ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Stephen J Smoogen.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
