Re: Restricting kma architectures to 64 bit?
On Mon, Aug 23, 2021 at 05:44:36PM +0200, Michael R. Crusoe wrote: > > > > > > Should I file removal bug for removals from all 32-bit arches for kma? > > No objection from me. Neither objections from me. I need to admit that in general our software will be used in practice most probably only on 64 bit architectures. So getting rid of 32bit architectures for any of our packages should not be a big deal and any slight reason to do so to get less work for us should trigger an according removal. Kind regards Andreas. -- http://fam-tille.de
Re: apache arrow anyone?
On Mon, Aug 23, 2021 at 03:33:02PM +0200, Sascha Steinbiss wrote: > > I also think that the science-team's repository is where it should go. > > Done, now in https://salsa.debian.org/science-team/arrow. > > I have also added a README.Debian to summarize what is still open. I'd > be more than happy to join in with some remaining tasks if there's a > chance to get the package a safe home :) Thanks a lot Andreas. -- http://fam-tille.de
Re: Source-only upload of debmutate 0.35 or 0.36
Hi Michael, On Mon, Aug 23, 2021 at 05:48:15PM +0200, Michael R. Crusoe wrote: > Can you make a source-only upload of debmutate 0.35-1 or later? This is > blocking lintian-brush & routine-updates's migration back into testing. > > I'm happy to make a NMU, if you wish. 0.36 should be on its way now. Jelmer signature.asc Description: PGP signature
simde fixes for last-align
Hi Michael, You did simde trick[1] for last-align a long time ago (which saw a major overhaul later), to make it building across multiple arches, many thanks for that! However, I had a conversation with the upstream maintainer here[2] and it seems like that patch might not be needed anymore - although for now I had uploaded w/ the patch applied. Would you mind checking once? [1]: https://salsa.debian.org/med-team/last-align/-/blob/master/debian/patches/simde [2]: https://gitlab.com/mcfrith/last/-/issues/5 Nilesh
Source-only upload of debmutate 0.35 or 0.36
Hello Jelmer, Can you make a source-only upload of debmutate 0.35-1 or later? This is blocking lintian-brush & routine-updates's migration back into testing. I'm happy to make a NMU, if you wish. Cheers,
Re: Restricting kma architectures to 64 bit?
On Mon, Aug 23, 2021 at 5:32 PM Nilesh Patra wrote: > > > On 8/23/21 9:00 PM, Nilesh Patra wrote: > > Recently I added autopkgtest to the latest version of resfinder, which > uses kma_index binary from src:kma package. That started failing on > > 32 bit architectures[1] > > > > I reported the same upstream, and upstream says that kma could never > work properly on 32-bit arches, see here[2] > > However, kma had been passing its own autopkgtests on 32 bit arches for > a while now -- now when I checked, for example this[3] > > I see that it actually throws an error, but the test passes because the > upstream did not exit with the right exit code, which they have fixed now. > > > > Should I file removal bug for removals from all 32-bit arches for kma? > No objection from me.
Re: Restricting kma architectures to 64 bit?
On 8/23/21 9:00 PM, Nilesh Patra wrote: > Recently I added autopkgtest to the latest version of resfinder, which uses > kma_index binary from src:kma package. That started failing on > 32 bit architectures[1] > > I reported the same upstream, and upstream says that kma could never work > properly on 32-bit arches, see here[2] > However, kma had been passing its own autopkgtests on 32 bit arches for a > while now -- now when I checked, for example this[3] > I see that it actually throws an error, but the test passes because the > upstream did not exit with the right exit code, which they have fixed now. > > Should I file removal bug for removals from all 32-bit arches for kma? $ reverse-depends kma Reverse-Recommends * med-bio Reverse-Depends * kmerresistance [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x] * resfinder * virulencefinder $ reverse-depends kma -b Reverse-Build-Depends * resfinder-db OpenPGP_signature Description: OpenPGP digital signature
Restricting kma architectures to 64 bit?
Recently I added autopkgtest to the latest version of resfinder, which uses kma_index binary from src:kma package. That started failing on 32 bit architectures[1] I reported the same upstream, and upstream says that kma could never work properly on 32-bit arches, see here[2] However, kma had been passing its own autopkgtests on 32 bit arches for a while now -- now when I checked, for example this[3] I see that it actually throws an error, but the test passes because the upstream did not exit with the right exit code, which they have fixed now. Should I file removal bug for removals from all 32-bit arches for kma? [1]: https://ci.debian.net/data/autopkgtest/testing/armhf/r/resfinder/14770939/log.gz [2]: https://bitbucket.org/genomicepidemiology/kma/issues/42/kma_index-problems-with-working-on-32-bits [3]: https://ci.debian.net/data/autopkgtest/testing/i386/k/kma/14709417/log.gz OpenPGP_signature Description: OpenPGP digital signature
Re: apache arrow anyone?
Hi Steffen, [...] > I also think that the science-team's repository is where it should go. Done, now in https://salsa.debian.org/science-team/arrow. I have also added a README.Debian to summarize what is still open. I'd be more than happy to join in with some remaining tasks if there's a chance to get the package a safe home :) Cheers Sascha
Re: apache arrow anyone?
On 23.08.21 14:47, Sascha Steinbiss wrote: Hi Andreas, [...] I'd recomment to move the packaging from satta to one of the interested teams (either science or med or something that is close to that audience). I'd be very happy to do that as I am a maintainer in both med and science. Just did not see the relevance for one of these teams back then when I did the first packaging. Sooo, which one would you recommend? I can move the repo as soon as we decide where to. My use case is not of a scientific nature, so Steffen if yours is not primarily med-focused, do we want to simply use `science-team`? I also think that the science-team's repository is where it should go. Nice! Steffen
Re: apache arrow anyone?
Hi Andreas, [...] > I'd recomment to move the packaging from satta to one of the > interested teams (either science or med or something that is close to > that audience). I'd be very happy to do that as I am a maintainer in both med and science. Just did not see the relevance for one of these teams back then when I did the first packaging. Sooo, which one would you recommend? I can move the repo as soon as we decide where to. My use case is not of a scientific nature, so Steffen if yours is not primarily med-focused, do we want to simply use `science-team`? Cheers Sascha
Re: apache arrow anyone?
Hi Andreas, On 23.08.21 13:3 [...] > I'd recomment to move the packaging from satta to one of the interested > teams (either science or med or something that is close to that audience). > > Kind regards and thanks a lot for your work on this > > Andreas. >
Re: apache arrow anyone?
Hi, On Mon, Aug 23, 2021 at 11:22:47AM +0200, Sascha Steinbiss wrote: > > but if there is, I haven't found it by doing a research on > > Salsa. > > I have prepared a first show of packaging for Arrow that works well for > my case [2]. ... > > [2] https://salsa.debian.org/satta/arrow I'd recomment to move the packaging from satta to one of the interested teams (either science or med or something that is close to that audience). Kind regards and thanks a lot for your work on this Andreas. -- http://fam-tille.de
Re: apache arrow anyone?
Hi again, [...] > The rest of the story is that I considered my package ready to upload Ah, probably not -- taking a second look I apparently did not do the d/copyright yet. So not really ready to upload, some metadata polishing is still needed. Cheers Sascha
Re: apache arrow anyone?
Hi Steffen and Etienne, [...] >> Apache Arrow https://arrow.apache.org/faq/ knows how to efficiently >> handle large tabular data. And, while not in our distribution, it blocks >> some workflows for Debian Med. Arrow comes with interfaces to all the >> prominent languages, for the Med-workflows it is typically the Python >> interface pyarrow that is needed. I am also facing a project [1] that now made a dependency on Arrow (the C++ interface, for me) mandatory and that a missing Arrow in Debian prevented me from updating the packaging to the latest upstream version, leaving it stuck at some version from May. >> I am not using Arrow myself, but I presume just like me you all know >> some project that should be using it :) Yep :) > Thank you for the prospective! I see Sasha filed an RFP some > time ago [1], so there is definitely interest in Apache Arrow. > I don't know whether there is a packaging effort at the moment, > but if there is, I haven't found it by doing a research on > Salsa. I have prepared a first show of packaging for Arrow that works well for my case [2]. It replicates almost all binary packages built by upstream's own packaging pipeline (for version 4, at least, that's when I stopped looking at it) and I only had to tweak the build parameters a little bit. FYI they are doing their own Debian debs via JFrog and their own Ruby-based packaging tooling [3, 4]. The rest of the story is that I considered my package ready to upload, but a project partner familiar with using Arrow let me know that their development cycle is quite fast, with several breaking new major versions recently, support for new languages being added all the time (Rust, ...) and with adopting other code as well (Parquet, ...). This made me a bit uneasy as I only needed it as a dependency and I did not really bite off more than I could chew. I contacted upstream to ask for support [5] but it looked to me that they would rather not like to help out with Debian packaging directly. They would probably consider specific patches form us but in general stick to their own packaging tools. See the linked thread for more information. I must admit I did not really have the time so far to follow up with explaining how things are done in Debian and that they and us are probably using too different approaches for packaging. Long story short: I have finished packaging for Arrow 4 which looks good (someone might want to double-check the long d/copyright though) but I am not sure I want to track and maintain it _on my own_ in the long run. If someone from the Debian Med team wants to collaborate on this, be it packaging or upstream interaction, I would be willing to reconsider =) Cheers Sascha [1] https://tracker.debian.org/pkg/vast [2] https://salsa.debian.org/satta/arrow [3] https://apache.jfrog.io/ui/native/arrow/debian [4] https://github.com/apache/arrow/tree/master/dev/tasks/linux-packages [5] https://lists.apache.org/thread.html/rcd366cf9bde72d69e942ea31f3a0f1066727f6c7e8915bfdda6f009a%40%3Cdev.arrow.apache.org%3E
