Any input for some talk about usage of Debian in HPC
Hi, I have an invitation to have some talk with the title Debian GNU/Linux for Scientific Research Abstract: Over the past decade, Enterprise Linux has dominated large-scale research computing infrastructure. However, recent developments have sparked increased interest in community-led alternatives. Debian GNU/Linux, a long-standing choice among researchers for supporting scientific work, is experiencing a renewed interest for High-Throughput Computing (HTC) and High-Performance Computing (HPC) applications. This presentation will provide an overview of how Debian is being utilized to support scientific research and will include a case study showcasing the migration of HTC operations from Enterprise Linux 7 (EL7) to Debian. While I could talk about Debian Science and Debian Med in general it would be cool to reference to some real life examples where Debian is used in Science and what might be the reason to use Debian. I personally would like to stress the "we package what we use" aspect and the "we mentor upstream to merge competence of the program with packaging skills" idea. Any input would be welcome to cover more ideas. Kind regards Andreas. -- https://fam-tille.de
Re: Action needed for R-pkg Uploaders
Hi again, I would be *really* happy if those who are in CC could clarify their intention to maintain the packages that have their names set as Uploader. Julian Gilbey and Joost van Baal-Ilić where the only ones who responed to the initial mail from two months ago. I just realised that there is a new version of r-cran-amelia which has Chris Lawrence as Uploader. Chris, according to UDD did the last uploads of other packages at 2023-08-19 so you seem to be active in Debian in some way. It would help if you could give us some update about your R packages, if you think these make sense inside Debian or whether some can be removed and you intend to care for the others or not. I also realised that Jonathon Love had his last changelog entry r-cran-rprotobuf | 0.4.5-1 | 2016-09-06 16:15:13+00 Jonathon, it would be great if you give some status update about your interest in the packages where you are listed as Uploader. I did not checked other uploaders yet, but it would be great to clarify the status of your involvement. This would help me a lot to save my time and concentrate on more important things. As a general remark: You can add your ID / replace my ID by yours in any package where I'm listed as Uploader. I'd be really happy about this. Kind regards Andreas. Am Mon, Mar 11, 2024 at 03:47:42PM +0100 schrieb Andreas Tille: > Hi R-pkg team members, > > as you might have possibly read I nominated myself for DPL for the next > term[1]. I will pronounce in my platform clearly that I will stop my > uploading activity to rather concentrate on my DPL tasks. I hope I will > be able to really stop myself from uploading in case I might be elected. > > I will also express that I'm a bit afraid about the effect on the teams > where I'm very active in. This is specifically true for the R-pkg team. > I did lots of team uploads in this team as you might have observed for > those packages where you are listed as Uploader (see below). I simply > worked down the list of packages needing an update[2] if I have some > spare minutes - no matter whether I'm Uploader or not. The > `routine-update` script was of great help here since it basically does > what it says. > > The fact that the list[2] became a bit longish is simply a sign that I > was focussing on other things the last weeks - drafting my DPL platform > etc. I might upload some packages from list if other things like > cleaning up after time_t transition in some packages might occupy all my > time. However, you need to expect that this list will grow even longer > if nobody will stand up and fulfill the task I more or less silently > did the last couple of years. > > I've put all those contributors in CC who had a hit in the UDD query > >SELECT DISTINCT uploaders FROM sources WHERE maintainer_email = > 'r-pkg-t...@alioth-lists.debian.net' AND release = 'sid'; > > which means the package is maintained by R-pkg team and the package is > in sid (so no old Uploaders). Below you see a list of the actual > package which is listing you as Uploader. Please note that some people > are mentioned with different e-mail addresses. BTW, this list also > contains Nilesh Patra who declared to leave the team[3]. We need to > replace him as Uploader (and he is not mentioned in To-Field). > > What I would like you to do is: > > 1. Verify the list of packages whether you want to keep on working > on this/these package(s) (and if you have different e-mail > addresses please stick to only one) > 2. If you do not want to serve as Uploader any more please try to > find a different Uploader (in the best case) and let this > contributor replace your ID or simply remove your ID to not > nurish the false hope that someone will care for this package > actively > 3. Make sure you are uploading your packages regularly for new > upstream versions and check for potential bugs (listed at the > end of[2]) > 4. I'd be happy if you would do me the favour to upload those > packages that are listing me as Uploader as long as I might > serve as DPL (I do not plan to do so more than one year) > > Thanks a lot for your cooperation inside R-pkg team >Andreas. > > [1] https://lists.debian.org/debian-vote/2024/03/msg2.html > [2] > https://salsa.debian.org/r-pkg-team/maintenance-utilities/-/blob/master/outdated_r-packages.txt > [3] https://lists.debian.org/debian-r/2023/11/msg00054.html > > Packages maintained by Uploaders in R-pkg team. > > Alba Crespi : > r-cran-data.table > r-cran-fastmatch > r-cran-metamix > r-cran-nmf > r-cran-nnls > r-cran-phangorn > r-cran-pkgmaker > r-cran-registry > r-cran-rngtools > > Andrius Merkys : > r-cran-cyclocomp > r-cran-lintr
Could someone have a look into bali-phy [notificati...@github.com: Re: [bredelings/BAli-Phy] Test suite error in 4.0-beta7 (Issue #17)]
Hi folks, this is residing since some time in my inbox but I will not be able to deal with this. It would be great if someone might subscribe the issue below and update the bali-phy package accordingly. Kind regards Andreas. - Weitergeleitete Nachricht von Benjamin Redelings - Date: Mon, 01 Apr 2024 07:32:34 -0700 From: Benjamin Redelings To: bredelings/BAli-Phy Cc: Andreas Tille , Author Subject: Re: [bredelings/BAli-Phy] Test suite error in 4.0-beta7 (Issue #17) Hi Andreas, I finally did a beta9 release, so the issue should be fixed. Would you be able to build beta9 for experimental? -BenRI -- Reply to this email directly or view it on GitHub: https://github.com/bredelings/BAli-Phy/issues/17#issuecomment-2029850883 You are receiving this because you authored the thread. Message ID: - Ende weitergeleitete Nachricht - -- https://fam-tille.de
Re: Binary conflict between Midnight Commander and MinIO Client
Hi, Am Mon, Apr 22, 2024 at 09:28:29AM +0200 schrieb Philip Hands: > >> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli > > Might I suggest that the link goes the other way, so that the symlink > lives in /usr/bin? That way the existence of the lib directory is > somewhat self-documenting. That's an interesting hint. In Debian Med we are using a common directories /usr/lib/debian-med/bin/ /usr/lib/debian-med/man/ where those binaries will be moved to and have some kind of a README.Debian template[1]. Changing this to have the real executable / manpage to /usr/lib/debian-med/* makes sense. We simply advise Debian Med users to set PATH to that dir and have all the name-clashed binaries inside Debian Med without additional interaction. Kind regards Andreas. [1] https://salsa.debian.org/med-team/ea-utils/-/blob/master/debian/README.Debian?ref_type=heads -- https://fam-tille.de
If someone might care for raxml-ng this would be great (Was: [amkozlov/raxml-ng] What libpll code is really needed (Issue #164))
Hi, I never managed to finish raxml-ng packaging which would be a great thing to have. Some hints about its preconditions can be found inn the issue linked below. Kind regards Andreas. - Weitergeleitete Nachricht von Alexey Kozlov - Date: Fri, 18 Aug 2023 14:17:07 -0700 From: Alexey Kozlov To: amkozlov/raxml-ng Cc: Andreas Tille , Author Subject: Re: [amkozlov/raxml-ng] What libpll code is really needed (Issue #164) > If I simply would package libpll-2 in the very place where libpll was > packaged and I keep *that* name (without the -2) this would be pretty > convenient since its not a new Debian package and does not need any new > processing. Do you think this is the correct way to go? Yes, I think this is the way to go. In fact, in the next major raxml-ng release, both `libpll-2` and `pll-modules` will be superseded by the new lib `coraxlib`: https://codeberg.org/Exelixis-Lab/coraxlib This should hopefully solve the long-lasting historical name confusion. -- Reply to this email directly or view it on GitHub: https://github.com/amkozlov/raxml-ng/issues/164#issuecomment-1684443628 You are receiving this because you authored the thread. Message ID: - Ende weitergeleitete Nachricht - -- https://fam-tille.de
Re: Status of the t64 transition
Hi Sebastian, thank you for your work on t64 transition. Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher: I've spotted these Debian Med packages. > gentle > jellyfish > quorum > sbmltoolbox No idea how we can help here. Please let us know if we can do something. > anfo We like to fix gcc-12 issues (#1012893) in anfo but so far nobody managed to do so since it seems to be quite complex. If we are blocking progress with this package its probably a sign that it should be removed from Debian. > blasr We try to work on #1067374. > freebayes Upstream is working on bug #1067271. > vg This package is in a bad state in any case and we are aware of this. However, could you explain in how far is this affecting t64 transition since 32bit architectures are excluded? > If you maintain any of the packages above, please check their status and > help get them fixed. Any help in filing bugs, fixing packages, > requesting removals, etc. is appreciated so that we can look into > unblocking the whole stack and migrate it to testing. I fixed two packages of Debian Python Team and pinged about some packages in Debian Science Team. Kind regards Andreas. -- https://fam-tille.de
Re: Emboss not migrating due to autopkgtest error on s390x
Am Wed, Apr 17, 2024 at 03:20:27PM +0300 schrieb Andrius Merkys: > I have added the build-time test and filed the needed RM bugs + removed > python-biopython test-dependency on emboss on s390x. Thanks a lot Andreas. -- https://fam-tille.de
Re: Emboss not migrating due to autopkgtest error on s390x
Am Tue, Apr 16, 2024 at 07:33:15PM +0530 schrieb Nilesh Patra: > > I would suggest the following course of action for emboss: > > > > 1. Add a build-time test calling emboss executable(s). This way builds will > > fail on s390x (and possibly other architectures) until #1069098 is fixed. > > > > 2. RM emboss for s390x without excluding s390x from build architectures. > > > > This way emboss will be able to migrate and there will be no action needed > > if/when #1069098 is fixed. > > Makes sense to me. +1 Kind regards Andreas. -- https://fam-tille.de
We are currently maintaining exactly 1000 packages in main
Hi folks, by chance I looked at https://qa.debian.org/developer.php?email=debian-med-packaging%40lists.alioth.debian.org and realised: main (1000) ;-) Kind regards Andreas. -- https://fam-tille.de
Emboss not migrating due to autopkgtest error on s390x
Hi, according to tracker[1] emboss is not migrating due to a test suite error on s390x[2]. IMHO the appropriate thing to do is to also remove s390x architecture - but we also need to care for all rdepends (again after removing these for 32bit). Any volunteer to file the according bugs? I guess adding architecture-is-little-endian to Build-Depends will to the trick to prevent building on s390x. Kind regards Andreas. [1] https://tracker.debian.org/pkg/emboss [2] https://ci.debian.net/packages/e/emboss/testing/s390x/43624748/ -- https://fam-tille.de
Re: Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Hi, Am Wed, Apr 10, 2024 at 03:33:53PM -0700 schrieb Steven Eker: > I like that solution since I believe there are 64-bit platforms where long > is 32-bits. I've updated my development version thus: > > // > // timeValue.tv_sec is 64-bit since Linux kernel 5.6 but GMP doesn't > yet have support > // for long long which is a problem on platforms where long is less > than 8 bytes. > // > #if SIZEOF_LONG < 8 > double seconds = timeValue.tv_sec; > #else > long seconds = timeValue.tv_sec; > #endif > mpz_class nanoSeconds(seconds); Sounds like some working solution. It would help if you could tag a new released to enable us fetching a fresh tarball incorporatinig this change. > Of course I expect to drop support for 32-bit before 2038 - certainly when > one our dependencies drops support. But I've gotten a bug report for > building Maude on a Raspberry Pi. Raspian is based on Debian and if the 32bit ARM architectures fail here Raspian people have a problem. Kind regards Andreas. -- https://fam-tille.de
Re: Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Hi, I'd suggest to set Build-Depends: architecture-is-64-bit, architecture-is-little-endian and remove 32bit architectures of maude. Kind regards Andreas. -- https://fam-tille.de
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Hi, Am Mon, Apr 01, 2024 at 09:12:49PM +0200 schrieb Sascha Steinbiss: > > > If there is agreement with this, then I would like an amend the > > Debain-Med team policy to make it clear that we, as a community of > > package maintainers and users, are okay with removing support for 32-bit > > and/or big-endian systems without discussion. > > I'd probably not go as far as to eagerly _remove_ all support for 32-bit > as in RM'ing existing packages that still build and work fine. ACK. Finally also removing packages creates some work we finally want to save. I think we should simply apply this policy to new packages and those who start failing for whatever reason with no obvious fix / patch provided. > I know that many others in Debian care about their specific niche > architecture and would be offended at some random maintainer just > dismissing their subjectively reasonable request to fix things. Making > it known beforehand where Debian Med puts its focus would help in making > such situations feel less personal. Fully ACK. > > New packages that aren't "Architecture: all": 1. Add > > "architecture-is-64-bit" and "architecture-is-little-endian" to the > > "Build-Depends" list in "debian/control". > > Nice, didn't know about these virtual packages before. Makes sense for > new packages -- would this result in an equivalent effect as restricting > the "Architecture" list in all binary packages? If we agree about the policy to restrict new packages to the said architectures I'd recommend adding this to our package template[1]. > > Removing architectures in existing packages: > [...] > > This approach looks good. As I said, I'd rather only go this way if the > maintainer in question notices that there is a need to do so. > > I agree that if it turns out that for a package to be removed there are > reverse dependencies outside of Debian Med's maintainership which would > be affected, we would need to coordinate with the maintainers of these > reverse dependencies. My gut feeling says these cases will be > exceptional though. Sure. > I think it could also make sense to think of what to do for other > architectures that are not yet covered in Michael's proposal, such as > (subjectively) obscure archs that still are considered official release > architectures (riscv64, mips64el, ...) or As long as these do not create any trouble its perfectly fine to support these. > all the non-official architectures > (alpha, hurd-*, m68k, ...)? Hurd will be available next year. ;-P Kind regards Andreas. [1] https://salsa.debian.org/med-team/community/package_template/-/blob/master/debian/control?ref_type=heads -- https://fam-tille.de
Re: Upgrading fis-gtm and closing CVE-2021-44496 CVE-2021-44504
Ping? Am Sat, Dec 09, 2023 at 06:13:24PM +0100 schrieb Andreas Tille: > Hi Amul, > > I realised that fis-gtm is lagging behind upstream some versions and the > Debian packaged fis-gtm is featuring CVE-2021-44496 and CVE-2021-44504. > It would be great if you could upgrade the Debian package to the latest > upstream version. > > Kind regards, > Andreas. > > -- > http://fam-tille.de > > -- https://fam-tille.de
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Hi Charles, Am Fri, Mar 29, 2024 at 03:48:07PM +0900 schrieb Charles Plessy: > > For the moment it would be easy to make sure at least new r-bioc-* > > packages are restricted to the said architectures by adding this to > > dh-r. > > I fully agree. I've pushed an (only weakly tested) patch to dh-r[1] implementing this. If you think this is fine, feel free to upload a new version of dh-r which enables wider testing. > By the way the next Bioconductor is scheduled for May 1st, shortly after > the R 4.4 release. Thanks for the information. I'd be super happy if this would be managed without my help in case I might become elected as DPL. I'm willing to take part but I have no idea how much my Debian time will be occupied. Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/dh-r/-/commit/72571478f4bc889675a60a9a05d7ef31e8bbba15 -- https://fam-tille.de
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Hi, I'm personally fine with Michaels suggestion in general. Am Fri, Mar 29, 2024 at 10:13:40AM +0530 schrieb Nilesh Patra: > > > On 28 March 2024 7:21:01 pm IST, "Michael R. Crusoe" > wrote: > > There are also packages inside debian med umbrella which are not necessarily > related to medicine or bioinformatics. These include some general purpose > python packages, some C/C++ libraries et. al. There are packages that > reverse-depend on the same. I don't think it's a good idea to remove 32 bit > support in *all* the packages that are under our umbrella, but probably only > the ones that are end-user applications. When reading Michaels proposal I also was thinking about generic libraries we are packaging as pre-dependencies for our end-user applications. I'd be fine with mentioning those as exceptions from what I consider perfectly sensible for the packages that are really targeting at our user base. > It may be good to move packages not related to medicine to different teams > over time but some of them actually don't fit into any availability team as > per my understanding and may have to be moved to debian/ namespace. > > What do you think? I'm not convinced that moving package out of our focus is a good idea. When we did so in the past these packages somehow went out of our focus and we hear back from them only by testing removal warnings. I have no problem with moving packages if there is some request from somewhere else and thus there is some convincing interest that the package is maintained properly. But I would not browse the packages maintained by our team, check which might be of general interest, seek in what other team it might be appropriate, become a member of that team and maybe learn that this team has quite a different policy than we have (as I learned in DPT recently). In short: Keep on maintaining what we have and apply common sense where to restrict the architectures sensibly. BTW. actively restricting the architectures for existing packages just creates work for no use. I think we should simply focus on new packages and those that create some troublesome bug reports that we can deal with by removing unused architectures. One other hint: I consider it a good idea to forward our proposed change of policy to debian-devel@l.d.o (once we agreed upon the change - maybe in some MR) for two reasons: 1. There might be a chance we have overlooked something. 2. There might be other teams that are interested in a similar change of policy. > >and on the Debian-Med Matrix channel for instant discussions: > >https://app.element.io/#/room/#debian-med:matrix.org > > I'll be happy to open another thread about it, but while we are at it, do you > think it makes sense to make this as our official communication media? > > Most of us don't hang out on #debian-med IRC and it would be a little > misleading for someone wanting to contact us. >From my perspective the main drawpack of IRC is that you can't search in history. What about setting the title of #debian-med IRC pointing to our matrix channel? This would make easily clear what we prefered as communication channel. > Should we just close the IRC channel and endorse the matrix channel as the > official one? I do not use it but it makes sense to ask on IRC whether people like this channel for whatever reason. BTW, the Debian Med team is maintaining lots of packages in R pkg team - most prominently r-bioc-* packages but there are more packages dedicated to our user base. We should probably also write a R pkg policy (which is long overdue). For the moment it would be easy to make sure at least new r-bioc-* packages are restricted to the said architectures by adding this to dh-r. Kind regards Andreas. -- https://fam-tille.de
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Hi Emanuele. Am Tue, Mar 19, 2024 at 12:16:16PM +0100 schrieb Emanuele Rocca: > I've uploaded a NMU to DELAYED/2: https://bugs.debian.org/1067147 Thanks a lot for your attempt to help. In principle we have a team wide low threshold NMU - so undelayed NMUs are fine. The kind of race condition in uploads might imply that some ping in advance might be helpful to avoid duplicated work. > With those changes dcmtk builds fine on both armel and armhf. I've > dropped the graphviz build-depend on those arches too, it can of course > be reintroduced once graphviz become installable again. Meanwhile your patch is imported and was uploaded by Michael - thanks to all who helped solving this. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Hi again, sorry, I did not checked the situation. Am Tue, Mar 19, 2024 at 10:34:13AM +0100 schrieb Andreas Tille: > Testing removals are happening automatically if some RC bug exists > for a certain time without pinging. Just writing some additional > information to the bug in question would have prevented this but > nobody of us had sufficient capacity. That's a shame but will be > healed over time (which is hopefully not that long). Since you all pinged that bug we now have another 4 weeks of time before anything gets removed from testing. So we just need to bear the noise from testing removal warnings of quite some packages (which I'd love to get rid of thus uploading a fix would be great). Kind regards Andreas. -- http://fam-tille.de
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Am Tue, Mar 19, 2024 at 09:52:49AM +0100 schrieb Jörg Riesmeier: > Dear all, > > > Indeed, and there is a simple fix too, which has been uploaded to > > experimental only so far: > > yes, there is a simple fix (that disables the error), but there is also a > more fundamental fix that (hopefully) solves the issue at its core: > > > https://git.dcmtk.org/?p=dcmtk.git;a=commit;h=bdc18c85b7fca130464dd745ea3efef3c9b8b94e Thanks for the additional pointer. > Furthermore, it feels kind of strange that the DCMTK package was about to be > removed because a rather insignificant test tool causes problems on a single > platform, and this test tool is even not part of any Debian package (see > "debian/rules" file): Testing removals are happening automatically if some RC bug exists for a certain time without pinging. Just writing some additional information to the bug in question would have prevented this but nobody of us had sufficient capacity. That's a shame but will be healed over time (which is hopefully not that long). Kind regards Andreas. -- http://fam-tille.de
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Hi Sébastien, Am Tue, Mar 19, 2024 at 09:44:04AM +0100 schrieb Sébastien Jodogne: > > > > > > On 2024-03-19 06:24, Sébastien Jodogne wrote: > > > > Because of bug #1060104, a large majority of the packages related to > > > > medical imaging have just disappeared from Debian Unstable. To be precise s/Unstable/Testing/ (but its a shame anyway). > > > > But, if I correctly understand #1060104, it is specific to one single > > > > platform (armel). > > > > > > Indeed, and there is a simple fix too, which has been uploaded to > > > experimental only so far: > > > https://salsa.debian.org/med-team/dcmtk/-/commit/42583dfe9fd344a63cdbc278268d4176d4a22ec4 > > > > > > Mathieu (or someone else from debian-med), could you please apply that > > > to unstable as well? It seems that with the current state of unstable > > > the transition will take a while anyways. > > > > I will be away from any Debian tasks for at least another month > > unfortunately. The patch was suggested by an armel porter so I believe > > this is the right thing to do. Thanks for confirming. > > > Worth pointing out that right now dcmtk cannot be built in sid/armel due > > > to a missing build depend, namely graphviz. It seems worth applying the > > > fix to unstable anyways so that it does not fall through the cracks, and > > > we can schedule a binNMU later when graphviz is available again. > > I could try to upload this patch by myself to unstable. Unfortunately, I'm > not an uploader of the dcmtk package, so an intervention from a Debian > Developer is required to give me the proper access rights: > https://tracker.debian.org/pkg/dcmtk Upload permission granted. Feel free to keep on asking if something might not work as expected. Kind regards Andreas. -- http://fam-tille.de
Re: Action needed for R-pkg Uploaders
Hi Joost, Am Mon, Mar 18, 2024 at 08:51:27AM +0100 schrieb Joost van Baal-Ilić: > Andreas: thanks a lot for this heads-up, and thanks HUGELY for maintaining the > bulk of the r-cran ecosystem in Debian for such a long time. Thanks to you. I just want to stress again the fact that it is extremely questionable that this will continue in case in my DPL term in case I might become elected. If you all as team members want to profit from up to date r-* packages you not only need to care for those packages you are mentioned as Uploader but care for team wide updates. In other words: "Any team member can and *should* upload team maintained packages no matter who is specified as Uploader." BTW, its perfectly welcome to add additional IDs to Uploaders. > Op Mon, Mar 11, 2024 at 03:47:42PM +0100 schreef Andreas Tille: > > > > > > > Joost van Baal-Ilić : > > r-cran-bdgraph > > r-cran-corpcor > > r-cran-d3network > > r-cran-farver > > r-cran-fdrtool > > r-cran-formatr > > r-cran-ggforce > > r-cran-ggm > > r-cran-ggrepel > > r-cran-glasso > > r-cran-highr > > r-cran-httpuv > > r-cran-huge > > r-cran-hunspell > > r-cran-knitr > > r-cran-lavaan > > r-cran-lisreltor > > r-cran-markdown > > r-cran-matrixcalc > > r-cran-mi > > r-cran-mime > > r-cran-nfactors > > r-cran-qgraph > > r-cran-rcppparallel > > r-cran-rockchalk > > r-cran-sem > > r-cran-semplot > > r-cran-semtools > > r-cran-statcheck > > r-cran-tweenr > > r-cran-yaml > > I'm afraid I won't have time to take care of those in the near > future. However, I _do_ plan to keep maintaining: > > r-cran-lavaan > r-cran-hunspell > r-cran-markdown > r-cran-httpuv > r-cran-statcheck > > (And I've just managed to do upload new upstream of r-cran-statcheck; > routine-update indeed makes life much easier :) Good. > So, would it be usefull to do an upload of the 31 - 5 = 26 other packages > dropping my name from Uploaders: so changing: > > Maintainer: Debian R Packages Maintainers > > Uploaders: Joost van Baal-Ilić > > into > > Maintainer: Debian R Packages Maintainers > > > in debian/control? I'm not really sure what might be the best way to go. Definitely it is not good to have somehow false information about Uploaders who do not intend to Upload the package in question. Technically its the easiest way to spot those packages who need an Uploader if there is nobody mentioned. We get a linitan warning (error?) about it and UDD will return the results quickly. It might possibly make sense as well to decide about droping some packages with no rdepends and low popcon to reduce the workload. For R packages there are several ways for users to install (either in plain R or cran2deb). If we realise interest in some package was lost and it just keeps us busy for no visible advantage for users, cleaning up our package pool might make sense. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#1065841: Taking over datalad to either Debian Med or Debian Science team
Hi Yaroslav, Am Tue, Mar 12, 2024 at 03:50:22PM -0400 schrieb Yaroslav Halchenko: > Let's keep DataLad under our (NeuroDebian) umbrella for now, since we > are also upstream there and project is active. We are also > working with Vasyl (CCed) to experiment with some semi-automation for > package updates/backports (for neurodebian) and datalad (and some of its > ecosystem) packages are the target. Packaging will be on salsa. We > might move them under larger Med or Science teams, but not just yet. That's perfectly fine and all I would like to see. No presure. > Re #1065841 specifically -- while trying to build updated package I > experienced some odd side-effect (pip started to try to install > tqdm) and didn't see immediate reason.I will see how well it goes on > debian infra after source only upload (did now). I perfectly trust you to maintain this package properly. I simply was querying this type of bug and thought datalad would nicely fit into Debian Science scope. Kind regards Andreas. -- http://fam-tille.de
Re: How is autopkgtest working in Perl packages
Am Mon, Mar 11, 2024 at 10:29:30PM +0100 schrieb Étienne Mollier: > The change turns out to be much more involved than I initially > thought: we need to account for the build dependencies as well > as the recommends, and tests don't go skipped that easily, > because the control on skippable entries occurs after the > testbed is installed, which cannot occur since recommended > packages are uninstallable. I'll probably continue having a > look at bioperl-run during the week. Cool. It would be great if we could get rid of 32bit emboss related packages to get back all those packages in testing which were removed now. Kind regards Andreas. -- http://fam-tille.de
Taking over datalad to either Debian Med or Debian Science team
Hi Yaroslav, once we agreed that we should probably move all Neurodebian packages to Debian Med to make it accessible for a bigger team. I was not really active for some time in this attempt. However, bug #1065841 brought datalad on my screen. I would love to see it maintained on Salsa either in Debian Science team (since it has wider usage) or Debiam Med (since we moved Neurodebian packages there). I'd volunteer to do the move if you agree to and by doing so also fix the two open bugs and run some `routine-update` on the packaging. What do you think? Kind regards AndreasI'd volunteer to do the move if you agree to and by doing so also fix the two open bugs and run some `routine-update` on the packaging. What do you think? Kind regards Andreas. -- http://fam-tille.de
How is autopkgtest working in Perl packages
Hi, when trying to exclude clustalw and emboss from bioperl-run I learned that its autopkgtest is failing for all architectures but amd64. The reason is that the test wants to install pftools which is only available on amd646. Thus all autopkgtests for other architectures are failing with Broken autopkgtest-satdep:ppc64el Depends on pftools:ppc64el < none @un mH > (and other not installable dependencies.) Unfortunately I do not see any debian/tests/control file which is hidden by some Perl test magic I do not know. Any hint how to relax the depencency from non-existent packages? Kind regards Andreas. -- http://fam-tille.de
Action needed for R-pkg Uploaders
Hi R-pkg team members, as you might have possibly read I nominated myself for DPL for the next term[1]. I will pronounce in my platform clearly that I will stop my uploading activity to rather concentrate on my DPL tasks. I hope I will be able to really stop myself from uploading in case I might be elected. I will also express that I'm a bit afraid about the effect on the teams where I'm very active in. This is specifically true for the R-pkg team. I did lots of team uploads in this team as you might have observed for those packages where you are listed as Uploader (see below). I simply worked down the list of packages needing an update[2] if I have some spare minutes - no matter whether I'm Uploader or not. The `routine-update` script was of great help here since it basically does what it says. The fact that the list[2] became a bit longish is simply a sign that I was focussing on other things the last weeks - drafting my DPL platform etc. I might upload some packages from list if other things like cleaning up after time_t transition in some packages might occupy all my time. However, you need to expect that this list will grow even longer if nobody will stand up and fulfill the task I more or less silently did the last couple of years. I've put all those contributors in CC who had a hit in the UDD query SELECT DISTINCT uploaders FROM sources WHERE maintainer_email = 'r-pkg-t...@alioth-lists.debian.net' AND release = 'sid'; which means the package is maintained by R-pkg team and the package is in sid (so no old Uploaders). Below you see a list of the actual package which is listing you as Uploader. Please note that some people are mentioned with different e-mail addresses. BTW, this list also contains Nilesh Patra who declared to leave the team[3]. We need to replace him as Uploader (and he is not mentioned in To-Field). What I would like you to do is: 1. Verify the list of packages whether you want to keep on working on this/these package(s) (and if you have different e-mail addresses please stick to only one) 2. If you do not want to serve as Uploader any more please try to find a different Uploader (in the best case) and let this contributor replace your ID or simply remove your ID to not nurish the false hope that someone will care for this package actively 3. Make sure you are uploading your packages regularly for new upstream versions and check for potential bugs (listed at the end of[2]) 4. I'd be happy if you would do me the favour to upload those packages that are listing me as Uploader as long as I might serve as DPL (I do not plan to do so more than one year) Thanks a lot for your cooperation inside R-pkg team Andreas. [1] https://lists.debian.org/debian-vote/2024/03/msg2.html [2] https://salsa.debian.org/r-pkg-team/maintenance-utilities/-/blob/master/outdated_r-packages.txt [3] https://lists.debian.org/debian-r/2023/11/msg00054.html Packages maintained by Uploaders in R-pkg team. Alba Crespi : r-cran-data.table r-cran-fastmatch r-cran-metamix r-cran-nmf r-cran-nnls r-cran-phangorn r-cran-pkgmaker r-cran-registry r-cran-rngtools Andrius Merkys : r-cran-cyclocomp r-cran-lintr r-cran-rlinsolve r-cran-xmlparsedata Benjamin Eikel : r-cran-ggplot2 r-cran-munsell r-cran-scales Carlos Borroto : r-cran-plyr Charles Plessy : r-bioc-genomeinfodb r-bioc-genomeinfodbdata r-bioc-genomicalignments r-bioc-hdf5array r-bioc-iranges r-bioc-matrixgenerics r-bioc-rtracklayer r-bioc-s4arrays r-bioc-s4vectors r-bioc-summarizedexperiment r-bioc-xvector r-bioc-zlibbioc r-cran-biocmanager r-cran-epitools r-cran-genetics Chris Lawrence : r-cran-aer r-cran-amelia r-cran-bayesm r-cran-coda r-cran-eco r-cran-gam r-cran-geepack r-cran-gmaps r-cran-jsonlite r-cran-mapdata r-cran-mapproj r-cran-maps r-cran-matchit r-cran-mcmc r-cran-mcmcpack r-cran-mnp r-cran-pscl r-cran-psy r-cran-rjags r-cran-vgam r-cran-zelig Christopher Hoskin : r-bioc-rbgl Dirk Eddelbuettel : r-cran-rocr Doug Torrance : r-cran-m2r r-cran-orthopolynom r-cran-partitions r-cran-r.devices r-cran-r.rsp r-cran-sets Doug Torrance : r-cran-latte r-cran-mpoly Dylan Aïssi : r-cran-fitbitscraper r-cran-fitcoach r-cran-leaps r-cran-prettyr Dylan Aïssi : dh-r r-bioc-bioccheck r-bioc-biocviews r-bioc-impute r-bioc-mergeomics r-bioc-rhdf5filters r-bioc-tcgabiolinksgui.data r-bioc-zlibbioc r-cran-ape r-cran-beeswarm r-cran-bigmemory r-cran-bigmemory.sri r-cran-biocmanager r-cran-calibrate r-cran-clipr r-cran-clisymbols r-cran-devtools r-cran-factominer r-cran-flashclust r-cran-gee r-cran-ggsci r-cran-gh r-cran-ini r-cran-isoband r-cran-isospecr r-cran-locfit r-cran-lubridate r-cran-metamix r-cran-modeldata r-cran-qqman r-cran-ranger r-cran-rcmdcheck r-cran-rematch2 r-cran-remotes r-cran-reprex r-cran-reticulate r-cran-rstatix r-cran-rvest r-cran-selectr
clustalw lost in debian/dists/sid/main/binary-i386/Packages.{gx}z ?
Hi, I'm working on some time_t side effects on the emboss package and by doing so stumbled I upon the fact that i386 builds of packages with a Build-Dependency on clustalw are failing. You can see an example in Salsa CI for libbio-tools-run-alignment-clustalw-perl[1] which contains The following packages have unmet dependencies: builddeps:. : Depends: clustalw but it is not installable E: Unable to correct problems, you have held broken packages. When checking the package pool[2] I can find clustalw_2.1+lgpl-7_i386.deb which is easily installable in some chroot I created using sudo debootstrap --arch=i386 sid i386-chroot http://deb.debian.org/debian Debci seems to be fine in testing clustalw on all architectures[3] and according to build logs[4] all should be fine. Unfortunately wget -q -O - http://ftp.debian.org/debian/dists/sid/main/binary-i386/Packages.xz | xzgrep "Package: *clustalw" Packages.xz is empty and I wonder why. Is the Packages file for i386 just broken or is it me? Kind regards Andreas. [1] https://salsa.debian.org/perl-team/modules/packages/libbio-tools-run-alignment-clustalw-perl/-/jobs/5431253 [2] http://ftp.debian.org/debian/pool/main/c/clustalw/ [3] https://ci.debian.net/packages/c/clustalw/unstable/i386/ [4] https://buildd.debian.org/status/package.php?p=clustalw -- http://fam-tille.de
Build-Dependencies from emboss-lib for bioperl-run and python-biopython (Was: reverse dependencie)
Control: block -1 by 1065782 Hi Thorsten, Am Mon, Mar 04, 2024 at 06:41:28PM + schrieb Thorsten Alteholz: > there are still reverse dependencies that need to be taken care of: > > Checking reverse dependencies... > # Broken Depends: > emboss: jemboss I think this is a false positive since jemboss is built from the emboss source. > emboss-explorer: emboss-explorer Bug filed. > # Broken Build-Depends: > bioperl-run: emboss This needs further investigation. > embassy-domainatrix: emboss-lib (6.6.1~ <) Fixed Build-Depends. > embassy-domalign: emboss-lib (6.6.1~ <) Fixed Build-Depends. > embassy-domsearch: emboss-lib (6.6.0-1~ >=) >emboss-lib (6.6.1~ <) Fixed Build-Depends. > python-biopython: emboss This needs further investigation. > In case they matter, this needs to be addressed first. Please remove the > moreinfo tag once that is done. Thanks for checking. Once bioperl-run and python-biopython is fixed we reset moreinfo. Kind regards Andreas. -- http://fam-tille.de
Re: regarding filtering architectures
Hi Michael, Am Thu, Mar 07, 2024 at 12:23:15PM +0100 schrieb Michael R. Crusoe: > This is a great tip, thanks! > > I've pushed commits that use the provisions from the > architecture-properties package to clean up d/control for the following > packages: > > abyss > bazel-bootstrap > bowtie > bowtie2 > canu > diamond-aligner > gmap > jellyfish > kallisto > mmseqs2 > pbcopper > python-skbio > subread Very nice! That way we will not forget this in the next upgrade. I guess there are more candidates - my strategy would be to seek for loong in the list of architectures. Thanks for this effort Andreas. -- http://fam-tille.de
Re: regarding filtering architectures
Hi, Paul has sent me a valuable hint. I totally missed this information but will try to fix all our packages that are only available for 64 bit architectures according to this. I'm just bouncing this information to the list in case I'm not the only one who missed this simple option to exclude 32bit. Kind regards Andreas. Am Sun, Mar 03, 2024 at 07:28:57AM +0100 schrieb Paul Gevers: > Hi Andreas, > > I just spotted two of you packages [1] where you stopped supporting 32 bits. > I'm not going to judge on that (I don't even look at the reason), but > instead of hard-coding the list of architectures, could you use a > Build-Dependens on architecture-is-64-bit (from > https://packages.debian.org/unstable/architecture-properties). > > Rationale: https://lists.debian.org/debian-devel/2022/09/msg00105.html > > Paul > > [1] https://tracker.debian.org/media/packages/e/emboss/control-6.6.0dfsg-13 > [2] > https://tracker.debian.org/media/packages/r/r-bioc-rhtslib/control-2.4.1dfsg-2 > > Paul -- http://fam-tille.de
Re: Bug#1064291: marked as done (ITP: python-awkward -- manipulate JSON-like data with NumPy-like idioms)
Hi Sascha,
Am Sun, Feb 25, 2024 at 08:32:52PM +0100 schrieb Sascha Steinbiss:
> > nox > Creating virtual environment (virtualenv) using python3 in
> > .nox/prepare
> > nox > python -m pip install build numpy packaging PyYAML requests tomli
> > nox > Command python -m pip install build numpy packaging PyYAML requests
> > tomli failed with exit code 1:
> > WARNING: The directory '/nonexistent/.cache/pip' or its parent directory is
> > not owned or is not writable by the current user. The cache has been
> > disabled. Check the permissions and owner of that directory. If executing
> > pip with sudo, you should use sudo's -H flag.
> > ...
> Hmm, I never had that.
Sounds good. Maybe something is broken on my side?
> The buildd builds also seem to pass this step with no
> errors.
Even better.
> I am wondering if nox wants to pull anything from PyPI using pip and
> either your DNS configuration is weird or your build container cannot access
> the Internet (which than again it shouldn't)... but if buildds are not
> supposed to access the Internet why don't the builds fail there? On the
> buildds the issue there seems to be related to a script using an old(?)
> Python YAML library syntax:
> https://buildd.debian.org/status/package.php?p=python-awkward
I admit I'm fine with the situation that the build works everywhere
except for me as long as I have no reason to build it. ;-)
> > Even worse: It requires pyarrow
>
> It does? The project metadata, where all other dependencies are listed, does
> not mention it, and the dependencies that are listed there are all from
> Debian:
>
> ...
> dependencies = [
> "awkward_cpp==29",
> "importlib_metadata>=4.13.0;python_version < \"3.12\"",
> "numpy>=1.18.0",
> "packaging",
> "typing_extensions>=4.1.0; python_version < \"3.11\"",
> "fsspec>=2022.11.0"
> ]
> ...
>
> Grepping through the test requirements though seems to indicate that the
> tests in the awkward package need pyarrow:
Its not only the tests:
$ grep -Rl pyarrow src/* | wc -l
76
> ❯ grep pyarrow *requi* pyproject.toml
> requirements-test-full.txt:pyarrow>=7.0.0;sys_platform != "win32" and
> python_version < "3.12"
> requirements-test-minimal.txt:pyarrow==7.0.0
>
> But I disabled the Python unit tests (mostly because I couldn't get them to
> work with the combined C++ and Python package built here) so I didn't catch
> it.
> I was also under the impression that awkward working with data from pyarrow
> would just be one use case, but not a hard requirement for awkward to work.
> Probably too optimistic given your observations :/
Seems so. Maybe we finally need to tackle pyarrow.
> > ERROR collecting tests/test_awkward.py
> >
> > ImportError while importing test module
> > '/tmp/autopkgtest.sD3d5G/autopkgtest_tmp/tests/test_awkward.py'.
> > Hint: make sure your test modules/packages have valid Python names.
> > Traceback:
> > /usr/lib/python3.12/importlib/__init__.py:90: in import_module
> > return _bootstrap._gcd_import(name[level:], package, level)
> > tests/test_awkward.py:205: in
> > ak.str.to_categorical(ak.Array([["a", "b", "c"], ["a", "b"]])),
> > /usr/lib/python3/dist-packages/awkward/_dispatch.py:62: in dispatch
> > next(gen_or_result)
> > /usr/lib/python3/dist-packages/awkward/operations/str/akstr_to_categorical.py:53:
> > in to_categorical
> > return _impl(array, highlevel, behavior, attrs)
> > /usr/lib/python3/dist-packages/awkward/operations/str/akstr_to_categorical.py:60:
> > in _impl
> > pc = import_pyarrow_compute("ak.str.to_categorical")
> > /usr/lib/python3/dist-packages/awkward/_connect/pyarrow.py:60: in
> > import_pyarrow_compute
> > raise ImportError(error_message.format(name))
> > E ImportError: to use ak.str.to_categorical, you must install pyarrow:
>
> In that case it looks like anndata needs a feature of awkward that also
> needs pyarrow. Which is, yeah, a problem, given that we don't have anything
> form Arrow in Debian (yet). Since pyarrow is just bindings that need the
> rest of the library (https://arrow.apache.org/docs/python/index.html) then
> this pulls in another large dependency.
That's correct.
> > Since python-anndata is the last package with Python3.12 issues there is
> > some work
> > left on this front.
>
> True. I am afraid that Arrow would be too much for me to take care of at the
> moment, sorry. I started it a while ago but quickly found that that I bit
> off more than I can chew without it becoming a full-time task.
> (See my ITP and the thread on it)
I'm aware of this. Thank you for your work on this anyway.
Kind regards
Andreas.
--
http://fam-tille.de
Re: Bug#1064291: marked as done (ITP: python-awkward -- manipulate JSON-like data with NumPy-like idioms)
ng data, using > NumPy-like idioms. Arrays are dynamically typed, but operations on them > are compiled and fast. Their behavior coincides with NumPy when array > dimensions are regular and generalizes when they're not. > > This is packaged as a dependency for another package under the umbrella > of the Debian Med packaging team. > Date: Sat, 24 Feb 2024 13:06:34 + > From: Debian FTP Masters > To: 1064291-cl...@bugs.debian.org > Subject: Bug#1064291: fixed in python-awkward 2.6.1-1 > > Source: python-awkward > Source-Version: 2.6.1-1 > Done: Sascha Steinbiss > > We believe that the bug you reported is fixed in the latest version of > python-awkward, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 1064...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Sascha Steinbiss (supplier of updated python-awkward > package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Mon, 19 Feb 2024 18:28:57 +0100 > Source: python-awkward > Binary: python3-awkward python3-awkward-dbgsym > Architecture: source amd64 > Version: 2.6.1-1 > Distribution: unstable > Urgency: medium > Maintainer: Debian Med Packaging Team > > Changed-By: Sascha Steinbiss > Description: > python3-awkward - manipulate JSON-like data with NumPy-like idioms > Closes: 1064291 > Changes: > python-awkward (2.6.1-1) unstable; urgency=medium > . >[ Andreas Tille ] >* Initial release (Closes: #1064291) > Checksums-Sha1: > e835fc60616da3330a380ca105e75bbec149cfa5 2366 python-awkward_2.6.1-1.dsc > a4ef295e085c7c58ec1f2a28290f13da42132bdc 6040868 > python-awkward_2.6.1.orig.tar.gz > 91af6573bfdd76139113e93f54143f79b7c3b654 3292 > python-awkward_2.6.1-1.debian.tar.xz > 277224034e7f5452fb4fc00191f8553dcc25ac75 9409 > python-awkward_2.6.1-1_amd64.buildinfo > 7f35255f4e0e28de704b43ef7020b035cac46c59 5174496 > python3-awkward-dbgsym_2.6.1-1_amd64.deb > 2b24ffdfc4f6030fcfaf86d4edc780cf4731fc5a 882204 > python3-awkward_2.6.1-1_amd64.deb > Checksums-Sha256: > d3ea8befdebc2a6e24965ee1fbd235669c7c558c97c1f359f342cb889729ef69 2366 > python-awkward_2.6.1-1.dsc > 4c17354edae1bf4a5701e2a5b949043b8f358895718712e0720ba1be9dabbce6 6040868 > python-awkward_2.6.1.orig.tar.gz > 5befc650dc06b79040802fd8da693894918a5162076ebad46fcc45f978a016dd 3292 > python-awkward_2.6.1-1.debian.tar.xz > 23f92d9578aa35ae164bc4cd72d81a9bb3e3f68ab27d792a7002772c8501f313 9409 > python-awkward_2.6.1-1_amd64.buildinfo > 557768ad12a871641aeef664829d6b476c2e6620ec51b1608cf553e7676d2db5 5174496 > python3-awkward-dbgsym_2.6.1-1_amd64.deb > fea0101f0d78ff16ddb3a00d03f11ff493bbac5a24d70b98a87f6fd814fdeee8 882204 > python3-awkward_2.6.1-1_amd64.deb > Files: > a1714dda9f9e9fa20d0584e12e54107a 2366 python optional > python-awkward_2.6.1-1.dsc > 4985e5efc79105640d5718931eebab33 6040868 python optional > python-awkward_2.6.1.orig.tar.gz > a1e6d04386e251fe0328470de85897b6 3292 python optional > python-awkward_2.6.1-1.debian.tar.xz > d205149ace149bf2de2a3b844811d476 9409 python optional > python-awkward_2.6.1-1_amd64.buildinfo > 378ae2d1514d3afada7cd93760dafe1d 5174496 debug optional > python3-awkward-dbgsym_2.6.1-1_amd64.deb > ad082dfeacaee9dd9b04bfa6683096dd 882204 python optional > python3-awkward_2.6.1-1_amd64.deb > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEEWzS6WqtVB+kDQm6F6NN64vCfSHIFAmXTt0MACgkQ6NN64vCf > SHLdbxAAnX9oiBgUwB0NCbh6JPSo+JQr/shB6OLdwEp5rqpjkKJyJUzim4secHZ2 > 5dr2sIqIoUvVdayW6QyNcOt53ncL0CD1qt88A6Hl/bpabDaHLHBdk+ltr+Axqcek > G2V9mrOoOddt+obakrdrM6g4Ts3TwuDvshqJs9EA351SZeEVCP3+Glq8pc0Cfmsl > r7qX+vHI9su/k6PFpmH66qqZbzi9sIUnkxSLmsxFyVX+ZTaP85T2rxp4HdqrDagh > dqSMA8lptt9uWbXua+2PLifmmh9wMRvJUsiMByCRNhRu5T/4h2WYMfEtrTGpVs0d > JRvTMpe9bsdm2/+ffV2fXK6E6/9Wl6dbg8aoLmqIVFkdfyMlpsowSCgE+KlAKrxG > rHmOkFYeaFtWDeASwa15vPut33KZlkf5HFtRV+jeCUgWa4IQJJq6NznmS7K3e1p9 > YZbIfCpMjO3qAaKaFcVtRuvA2CM9/HxROmO3BLsRVvkS5mZMOi8g+xOjX8xZttIC > EOrslMcfQ3djAIebQ20ZeqJHohvKSRKRygYXDW9UR8jv390KvGfi/S9eTKyrlBQb > lZFvnf8QoDKrFHsyefLiojsZgG948/fN7RsM4i32SxLWtGwIZ+qbfMaG6IQPIP2Q > Rn5y2fjJ0G+VAbrCeypJ4zJVARXfhYQOKGMeUqUex/OsgXkX9Ig= > =CdJG > -END PGP SIGNATURE- > -- http://fam-tille.de
Re: New CamiTK 5.2.0 release
Dear Emmanuel, Am Thu, Feb 22, 2024 at 04:07:25PM +0100 schrieb Emmanuel Promayon: > Thank for your time, patience and explanations! You are welcome. > Thank you very much for the explanation, the wiki update and the link to > routine-update, that will probably my saviour in the future! Routine-update is saving me a lot of time and I hope it will do so for others. ;-) > > The repository has the line with "lib/x86_64-linux-gnu" while the > > downloaded tarball has only "lib". If you really need to adapt the > > original tarball to some Debian specific things this needs to be done in > > a quilt patch. Please also note: This change only works for amd64 > > architecture which currently is the only architecture where the Debian > > package is built. However, this restriction is only due to the fact > > that libinsighttoolkit5-dev is only available for this architecture. In > > case it might be available for other architectures as well your patch > > above will fail on those. > Understood. Now that the correct libDir variable is set back to just "lib", > the multiarch support should be taken into account directly in the > debian/rules. > The first instruction of the target override_dh_auto_configure target is: > sed -i 's+libDir = "lib";+libDir = "lib/$(DEB_HOST_MULTIARCH)";+g' > sdk/libraries/core/CamiTKVersion.h Just a general think I do not understand: Why is it necessary that a header file knows about the location of the (shared/static?) library? > Which, from what I understand, should replace the libDir variable with the > specific architecture version, hopefully making it ready for when/if > libinsighttoolkit5-dev supports other architectures. > Let me know if that sounds correct for you. Using the correct lib dir on different architectures is probably the right way to support these architectures. But its the first time I see that a header file needs to know the location of the lib. > I pushed the fix to salsa, let me know if that solved the problem. I've uploaded yesterday. > Best > regards, Emmanuel PS : I added Manik Bhattacharjee in cc who joined me in > the CamiTK project team. Welcome Manik. Kind regards Andreas. -- http://fam-tille.de
Re: New CamiTK 5.2.0 release
Hi Emmanuel, Am Thu, Feb 22, 2024 at 07:48:53AM +0100 schrieb Emmanuel Promayon: > I hope you had a great sprint (seems a lot was done, congrats!). All was fine, thank you. > I was wondering if any of you had any time to check the new CamiTK version > package in between all of the bug fixing and python transition? I admit I was avoiding doing larger builds on my laptop and wanted to do this at home. Thanks for pinging in any case. > On 16/02/2024 11:01, Emmanuel Promayon wrote: > > Dear all, > > > > First of all, I'd like to wish the whole team a great sprint in Berlin. > > > > As far as CamiTK is concerned, version 5.2.0 has been released upstream > > and I have updated the package on salsa. > > I did not tag the master branch with the debian/5.2.0 tag, as I am not > > 100% sure that everything is valid. > > The pristine-tar branches were updated this time (hopefully the right > > way!). Hmmm, sorry, no. If you check that branch[1] you see the names for the two last releases are the original download names with camel case letters, a '-' instead of '_' separating the name and the version and lacking the '.orig' string inside the tarball name. I would have fixed this by doing uscan --verboe --force-download pristine-tar commit ../camitk_5.2.0.orig.tar.gz but after doing so I got: dpkg-source: info: local changes detected, the modified files are: camitk-5.2.0/sdk/libraries/core/CamiTKVersion.h dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/camitk_5.2.0-1.diff.LLSDXq So it seems there are some differences inside the tarball. I try to repeat what you need to do when there is a new upstream version: uscan --verbose gbp import-orig --pristine-tar --no-interactive camitk_VERSION.orig.tar.gz dch -i "New upstream version" I also tried to write the according paragraph in Debian Med policy[2] more verbosely. Maybe even the hint to `routine-update` is helpful. It simply does all you want to do (including the steps above). If there would not have been the conflict between the repository and the original tarball I would have went on after fixing pristine-tar branch. But I don't know what to do with this diff: --- camitk-5.2.0.orig/sdk/libraries/core/CamiTKVersion.h +++ camitk-5.2.0/sdk/libraries/core/CamiTKVersion.h @@ -32,5 +32,5 @@ const char * Core::version = "CamiTK 5.2 const char * Core::shortVersion = "camitk-5.2"; const char * Core::soVersion = "5"; const char * Core::debugPostfix = "-debug"; -const char * Core::libDir = "lib"; +const char * Core::libDir = "lib/x86_64-linux-gnu"; } The repository has the line with "lib/x86_64-linux-gnu" while the downloaded tarball has only "lib". If you really need to adapt the original tarball to some Debian specific things this needs to be done in a quilt patch. Please also note: This change only works for amd64 architecture which currently is the only architecture where the Debian package is built. However, this restriction is only due to the fact that libinsighttoolkit5-dev is only available for this architecture. In case it might be available for other architectures as well your patch above will fail on those. Please let me know if you need further hints. Thanks a lot for working on camitk package Andreas. [1] https://salsa.debian.org/med-team/camitk/-/tree/pristine-tar?ref_type=heads [2] https://med-team.pages.debian.net/policy/#updating-a-source-package-managed-with-git -- http://fam-tille.de
Help needed to port qiime to Python3.12
Hi, as reported in a qiime2 issue[1] there is some problem with Python3.12 in the tests of the q2-* packages which are all using the qiime package. This problem is currently hidden from the tests made by Python3.12 porters but it became obvious now on Salsa CI[2]. I tried to fiddle around a bit with the qiime code but with no success at all. Any help would be welcome. Kind regards Andreas. [1] https://github.com/qiime2/qiime2/issues/751 [2] https://salsa.debian.org/med-team/q2-types/-/jobs/5313640#L900 -- http://fam-tille.de
For the sprint attendees: Dinner tomorrow evening
Hi folks, I'd suggest to have dinner tomorrow evening 18:00 at Viet Kitchen (as last year): https://www.openstreetmap.org/?mlat=52.47994=13.35216#map=19/52.47994/13.35216 (I've added this also to the Wiki) See you either tomorrow or on Saturday Andreas. PS: For those who need to join from remote: Should we keep some kind of live connection open all the time or do we want to agree to somme common sessions at certain times? -- http://fam-tille.de
Re: Should we restrict libtread-pool to 64bit only
Am Mon, Feb 12, 2024 at 10:09:43PM -0500 schrieb Aaron M. Ucko: > Andreas Tille writes: > > >Build-Depends libthread-pool 4.0.0 which does not build > >for 32bit architectures[1] > > I see a fix in experimental: > > https://buildd.debian.org/status/package.php?p=libthread-pool=experimental > > Why not just reupload it to unstable? Done. Thanks a lot for the reminder Andreas. -- http://fam-tille.de
Should we restrict libtread-pool to 64bit only (Was: Bug#1063800: src:pinfish: fails to migrate to testing for too long: not installable on armel, armhf and i386)
Hi, the chain of dependencies for pinfish which creates the problem is pinfish depends racon which in turn can't install its Build-Depends libthread-pool 4.0.0 which does not build for 32bit architectures[1] My suggestion to solve the issue is to explicitly set Architecture: any-amd64 arm64 mips64el ppc64el riscv64 s390x alpha ia64 loong64 ppc64 sparc64 x32 and ask ftpmaster for removing 32bit architectures for libthread-pool, racon and pinfish. Does anybody think we should ask libthread-pool upstream to support 32bit or do we just want to go on to remove 32bit (which also solves time_t bug easily). Kind regards Andreas. [1] https://buildd.debian.org/status/package.php?p=libthread-pool Am Mon, Feb 12, 2024 at 09:35:34PM +0100 schrieb Paul Gevers: > Source: pinfish > Version: 0.1.0+ds-3 > Severity: serious > Control: close -1 0.1.0+ds-4 > Tags: sid trixie > User: release.debian@packages.debian.org > Usertags: out-of-sync > > Dear maintainer(s), > > The Release Team considers packages that are out-of-sync between testing and > unstable for more than 30 days as having a Release Critical bug in testing > [1]. Your package src:pinfish has been trying to migrate for 31 days [2]. > Hence, I am filing this bug. It seem the version in unstable isn't > installable on our 32 bit architectures. It seems like the version in > testing doesn't have binaries on these architectures, while the buildd > history shows they were built for the previous version, so you probably had > them removed. You probably need to do this again, but I suggest to add a > Build-Depends on racon to prevent accidental builds on architectures where > racon isn't available (and thus the package becomes not installable). > > If a package is out of sync between unstable and testing for a longer > period, this usually means that bugs in the package in testing cannot be > fixed via unstable. Additionally, blocked packages can have impact on other > packages, which makes preparing for the release more difficult. Finally, it > often exposes issues with the package and/or > its (reverse-)dependencies. We expect maintainers to fix issues that hamper > the migration of their package in a timely manner. > > This bug will trigger auto-removal when appropriate. As with all new bugs, > there will be at least 30 days before the package is auto-removed. > > I have immediately closed this bug with the version in unstable, so if that > version or a later version migrates, this bug will no longer affect testing. > I have also tagged this bug to only affect sid and trixie, so it doesn't > affect (old-)stable. > > If you believe your package is unable to migrate to testing due to issues > beyond your control, don't hesitate to contact the Release Team. > > Paul > > [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html > [2] https://qa.debian.org/excuses.php?package=pinfish > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de
Lets do the video conference next week
Hi folks, today we should schedule our video conference but I will not make it today and I think its better to meet next week at the sprint and invite those who are not at site via Jitsi. See you next week Andreas. -- http://fam-tille.de
Re: Do we need the Python interface of ghmm
Hi Steffen, Am Wed, Feb 07, 2024 at 02:23:22PM +0100 schrieb Steffen Möller: > Hi Andreas, > it will be best to remove it, I suggest. I just had the idea whe can do something inbetween: Add some README.Debian that Python3 interface is "probably broken since the test we added fails." Users who might *really* use this interface might possibly provide a solution we have no capacity to seek for. I simply move the Python part of the autopkgtest to this README.Debian. > I do not have any personal contact to upstream, somehwat unfortunate since > this looks very nice and educational, but ... unless someone enjoys such a > transition, I suggest to just wait for a version 0.10. Well, waiting for some version 0.10 sounds not very realistic, The package is on SourceForge which somehow smells very agy. Given that 0.9-rc3 is from 2013-08-09 we can safely assume that the world will not see any version 0.10, IMHO. Kind regards Andreas. > > Gesendet: Mittwoch, 07. Februar 2024 um 14:02 Uhr > > Von: "Andreas Tille" > > An: "Debian Med Project List" > > Cc: "Steffen Möller" > > Betreff: Re: Do we need the Python interface of ghmm > > > > Hi again, > > > > if there is no response of kind "Yes, please try to keep the Python > > interface of ghmm" it will be removed soon. > > > > Kind regards > >Andreas. > > > > Am Tue, Jan 30, 2024 at 07:58:34AM +0100 schrieb Andreas Tille: > > > Hi Steffen (and two whom it might concern), > > > > > > when Israel has written the autopkgtest for ghmm it turned > > > out that there are several issues with the Python3 interface. > > > In Matrix Nilesh raised the perfectly valid question: > > > > > >The py interface is living off a patch from py2to3 and is (very) > > >broken. It needs quite a lot of patching. Maybe it's a sensible thing > > > to > > >evaluate if we even need it? > > > > > > Could you please state your opinion about this? > > > > > > We should respond in a timely manner to the atlas removal > > > effort (patch in Git) and currently it is blocked by the > > > test suite issue of the Python3 interface. > > > > > > Kind regards > > >Andreas. > > > > > > -- > > > http://fam-tille.de > > > > > > > > > > -- > > http://fam-tille.de > > > > -- http://fam-tille.de
Re: Do we need the Python interface of ghmm
Hi again, if there is no response of kind "Yes, please try to keep the Python interface of ghmm" it will be removed soon. Kind regards Andreas. Am Tue, Jan 30, 2024 at 07:58:34AM +0100 schrieb Andreas Tille: > Hi Steffen (and two whom it might concern), > > when Israel has written the autopkgtest for ghmm it turned > out that there are several issues with the Python3 interface. > In Matrix Nilesh raised the perfectly valid question: > >The py interface is living off a patch from py2to3 and is (very) >broken. It needs quite a lot of patching. Maybe it's a sensible thing to >evaluate if we even need it? > > Could you please state your opinion about this? > > We should respond in a timely manner to the atlas removal > effort (patch in Git) and currently it is blocked by the > test suite issue of the Python3 interface. > > Kind regards >Andreas. > > -- > http://fam-tille.de > > -- http://fam-tille.de
Re: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)
Hi again, I've filed bug #1062371 RM: emboss [armel armhf i386 hppa m68k powerpc sh4] -- ROM; No support of 32 bit architectures any more Kind regards Andreas. Am Wed, Jan 31, 2024 at 07:53:26AM +0100 schrieb Andreas Tille: > Hi again, > > besides my suggested solution to split up emboss-lib again (and when > doing so make the package emboss-lib a metapackage depending from single > packages to match all its rdepends) I wonder whether we should provide > EMBOSS for 64 bit architectures only. While we probably need to file a > lot of removal requests to 32 bit packages of its rdepends it somehow > fits the reality that these days nobody seriously runs emboss on 32bit > architectures. As explained in the according wiki page[1] other binary > distros are dropping 32-bit at all and Debian rather cares for > automotive, IOT, TVs, routers, plant control, building > monitoring/control, cheap Android phones - nothing that is using EMBOSS. > > I would really like to get some input from *our users* here on the > Debian Med list since I need your response to draw a sensible decision. > > Kind regards > Andreas. > > [1] https://wiki.debian.org/ReleaseGoals/64bit-time > > Am Fri, Jan 26, 2024 at 10:44:09AM +0100 schrieb Andreas Tille: > > Hi Charles, > > > > I wonder how we can properly solve this bug. In the early stage of > > Emboss packaging obviously the packages > > > >libajax6, > >libajax6-dev, > >libnucleus6, > >libnucleus6-dev > > > > existed (thus the remaining Conflicts/Replaces on emboss-lib which can > > probably be removed right now). I wonder whether we should restore those > > single library package per shared library + devel package, merge > > static+shared library in one package or even merge > > > >libacd 6 emboss-lib (>= 6.6.0+dfsg) > >libajax 6 emboss-lib (>= 6.6.0+dfsg) > >libajaxdb 6 emboss-lib (>= 6.6.0+dfsg) > >libajaxg 6 emboss-lib (>= 6.6.0+dfsg) > >libensembl 6 emboss-lib (>= 6.6.0+dfsg) > >libnucleus 6 emboss-lib (>= 6.6.0+dfsg) > > > > in libemboss6 > > > >libepcre 7 emboss-lib (>= 6.6.0+dfsg) > > > > in libemboss-pcre7 (ugly since its a code copy of pcre3 but well, > > that's another battle field) and > > > >libeplplot 3 emboss-lib (>= 6.6.0+dfsg) > > > > in libemboss-plplot3 to express the proper sonames inside the library > > package names. Any more sensible suggestion is pretty welcome. > > > > Kind regards > > Andreas. > > > > -- > > http://fam-tille.de > > -- > http://fam-tille.de > > -- http://fam-tille.de
Re: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)
Hi Tony, Am Wed, Jan 31, 2024 at 09:57:32AM + schrieb Tony Travis: > The only people I know still using 32-bit software are doing BLAST etc on > older Raspberry Pi's. However, AFAIK, the default Raspberry Pi OS (based on > Debian Bullseye) is 32-bit even though the newer Raspberry Pi have 64-bit > processors. Personally, I don't think it's worth the effort to support > 32-bit software these days. I don't use EMBOSS any longer. Thanks a lot to your insight. Do you have any contact to those people running 32bit systems? Can you forward this question to them? Or more generally: Wouldn't it make sense if people doing Debian based bioinformatics would subscribe this list and speak here? Kind regards Andreas. -- http://fam-tille.de
User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)
Hi again, besides my suggested solution to split up emboss-lib again (and when doing so make the package emboss-lib a metapackage depending from single packages to match all its rdepends) I wonder whether we should provide EMBOSS for 64 bit architectures only. While we probably need to file a lot of removal requests to 32 bit packages of its rdepends it somehow fits the reality that these days nobody seriously runs emboss on 32bit architectures. As explained in the according wiki page[1] other binary distros are dropping 32-bit at all and Debian rather cares for automotive, IOT, TVs, routers, plant control, building monitoring/control, cheap Android phones - nothing that is using EMBOSS. I would really like to get some input from *our users* here on the Debian Med list since I need your response to draw a sensible decision. Kind regards Andreas. [1] https://wiki.debian.org/ReleaseGoals/64bit-time Am Fri, Jan 26, 2024 at 10:44:09AM +0100 schrieb Andreas Tille: > Hi Charles, > > I wonder how we can properly solve this bug. In the early stage of > Emboss packaging obviously the packages > >libajax6, >libajax6-dev, >libnucleus6, >libnucleus6-dev > > existed (thus the remaining Conflicts/Replaces on emboss-lib which can > probably be removed right now). I wonder whether we should restore those > single library package per shared library + devel package, merge > static+shared library in one package or even merge > >libacd 6 emboss-lib (>= 6.6.0+dfsg) >libajax 6 emboss-lib (>= 6.6.0+dfsg) >libajaxdb 6 emboss-lib (>= 6.6.0+dfsg) >libajaxg 6 emboss-lib (>= 6.6.0+dfsg) >libensembl 6 emboss-lib (>= 6.6.0+dfsg) >libnucleus 6 emboss-lib (>= 6.6.0+dfsg) > > in libemboss6 > >libepcre 7 emboss-lib (>= 6.6.0+dfsg) > > in libemboss-pcre7 (ugly since its a code copy of pcre3 but well, > that's another battle field) and > >libeplplot 3 emboss-lib (>= 6.6.0+dfsg) > > in libemboss-plplot3 to express the proper sonames inside the library > package names. Any more sensible suggestion is pretty welcome. > > Kind regards > Andreas. > > -- > http://fam-tille.de -- http://fam-tille.de
Do we need the Python interface of ghmm
Hi Steffen (and two whom it might concern), when Israel has written the autopkgtest for ghmm it turned out that there are several issues with the Python3 interface. In Matrix Nilesh raised the perfectly valid question: The py interface is living off a patch from py2to3 and is (very) broken. It needs quite a lot of patching. Maybe it's a sensible thing to evaluate if we even need it? Could you please state your opinion about this? We should respond in a timely manner to the atlas removal effort (patch in Git) and currently it is blocked by the test suite issue of the Python3 interface. Kind regards Andreas. -- http://fam-tille.de
Re: ClonalFrameML: Dataset with less computational resourses
Hi Xavier, Am Mon, Jan 29, 2024 at 06:34:54PM +0100 schrieb Komolehin Israel: > > Would it be useful for you if I added these files to the github > > repository? > > Yes. That would be great. I consider this specifically helpful since you could add a test in the upstream archive which is helpful not only for Debian but in general. We could simply call this test. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#1043240: transition: pandas 1.5 -> 2.1
Hi Rebecca, Am Sun, Jan 21, 2024 at 03:29:21PM + schrieb Rebecca N. Palmer: > > Hence, doing this transition now would involve breaking some reverse > dependencies with no known fix, but given the number of packages involved, > trying to wait until they're all fixed is rather likely to instead end in > pandas 1.5 being broken by a new Python/numpy/etc. Just go for it and lets try to fix issues as soon as possible. Thanks a lot for all your work on pandas Andreas. -- http://fam-tille.de
Debian Med video meeting today Saturday 2024-01-13 19:00 UTC
Hi, this is the call for the next video meeting of the Debian Med team that are an established means to organise the tasks inside our team. Meetings usually take us only 15-20min depending what we are talking about and how many people are joining. The next meeting is tomorrow https://www.timeanddate.com/worldclock/fixedtime.html?iso=20240113T19 The meeting will happen at the Debian Social channel https://jitsi.debian.social/DebianMedCovid19 The topic is what contributors have done in the past period and to coordinate the work until the next meeting. For those who are interested in hot topics we want to tackle, here are some items: - Python 3.12 transition - Evaluation of advent bug squashing - Status outreachy project Newcomers are always welcome. See you today Andreas. -- http://fam-tille.de
Debian Med sprint February 16.-18. 2024 in Berlin (in person meeting)
Hi, the Debian Med team will held its yearly in person meeting from Friday, February 16 (evening) until Sunday, February 18 (evening) in Berlin. For more detailed information please visit the Wiki page[1] and if you like to join our small meeting with bug squashing (may be Python 3.12 bug fixing etc.) you are perfectly welcome to add your name to the list of attendees. Looking forward to see you all Andreas. [1] https://wiki.debian.org/Sprints/2023/DebianMed2024 -- http://fam-tille.de
Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)
Hi, Am Wed, Jan 03, 2024 at 12:41:23PM +0100 schrieb Sascha Steinbiss: > > This would be very convenient. I'd take over to ask DPL for budget > > confirmation once the list of attendees needing travel support is > > fixed. > > Done: https://wiki.debian.org/Sprints/2023/DebianMed2024 Thanks a lot. I've added myself. Please let me know how many people might join the evening session on top of the water tower. If we might be maximum three people we can simply use the accomodation room I've booked with my wife and can save the extra Debian money for the bigger and fancier room. See you all Andreas. -- http://fam-tille.de
Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)
Am Wed, Jan 03, 2024 at 10:44:03AM +0100 schrieb Sascha Steinbiss: > > I can see in our internal calendar that the room has been booked for > 17./18.2. > > > We should setup an according Wiki page quickly (but I will not be > > possible to do this today). > > Should I just clone the previous page, just updating the year and > resetting the registration list? This would be very convenient. I'd take over to ask DPL for budget confirmation once the list of attendees needing travel support is fixed. Kind regards Andreas. -- http://fam-tille.de
Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)
Hi, Am Sat, Dec 30, 2023 at 11:39:35PM +0100 schrieb Étienne Mollier: > > > I'd love to fix 17-18. February (or lets meet at 16.2. February evening > > > inside the water tower like last year.) Just lets fix it on this 16.2. water tower whoever will make it and 17-18 inside the kacher space provided by Saschas company. We should setup an according Wiki page quickly (but I will not be possible to do this today). > I don't really have constraints on these dates. It may depend > on how well it plays with my dayjob calendar, but it is not the > best moment of the year to look it up. I will come back on this > topic next week if I happen to have blockers. > > > I will probably not be able to join in the water tower on the 16th, but no > > worry about this. That's fine. I did not even checked whether the water tower is available but I hope we will find either this or some other space for a hand full of people. See you Andreas. -- http://fam-tille.de
Re: Please help fixing meson/cmake code of btllib to use Debian packaged libargparse
Am Sat, Dec 30, 2023 at 04:28:39PM +0100 schrieb Étienne Mollier: > > autopkgtest-pkg-python can be requested to use only one python3 > version by specifying the X-Python3-Version field in d/control, > first paragraph. It is a consequence of autopkgtest-pkg-python > using `py3versions --requested`. Uhmm, I was not aware of this. > That being said, routine-update looks to drop this field without > checking the python3 version selected. I assume there was a > good reason to drop this field extension in the past, but > py3versions(1) manual does not really hint that this field is > obsolete. Perhaps switching the build dependency to enforce > python3.11 (or python3.12) over generic python3 would be a > working alternative. In any case, both methods will require > manual work on python3 version upgrades. I've fixed routine-update to not remove that field. I do not have more time now - so if you feel like fixing libsbml that would be great. Kind regards Andreas. -- http://fam-tille.de
Re: Please help fixing meson/cmake code of btllib to use Debian packaged libargparse
Am Sat, Dec 30, 2023 at 04:27:31PM +0530 schrieb Nilesh Patra: > > I can try to do so but I'm afraid we will run into the same issue as > > for libsbml[1]. > > No, we won't. There are no autopkgtests for the python wrapper. If > autopkgtests for this > are added, we should just run the same for default python3 and not all > supported versions. > > libsbml tests fail due to us running it for supporter pyvers[1]. I don't > think it should be an issue. But this is due to Testsuite: autopkgtest-pkg-python by simply loading the module with any pyvers. Loading libsbml would be a sensible test as well but I have no idea how to tell autopkgtest-pkg-python to use simply default Python3 version. Kind regards Andreas. > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059650#20 -- http://fam-tille.de
Re: Please help fixing meson/cmake code of btllib to use Debian packaged libargparse
Am Sat, Dec 30, 2023 at 01:19:32PM +0530 schrieb Nilesh Patra: > > Sure. Feel free to implement this - I'm just not available for the next > > couple of days. > > This is the currently existing solution itself. Only additional change needed > is to > replace python3-all-dev with python3-dev in d/control. I can try to do so but I'm afraid we will run into the same issue as for libsbml[1]. Kind regards Andreas. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059650#20 -- http://fam-tille.de
Re: [Advent bug squashing] Bugs from the past couple weeks
Hi Lance, Am Fri, Dec 29, 2023 at 10:36:54PM +0700 schrieb Lin Qigang: > While I do not plan to close any more before the new year, I enjoyed joining > this year's bug squashing advent. Thank you again to all of my sponsors and > those who offered help. It was a pleasure to work with you. In future I'd prefer to grant you DM upload permissions for the packages you worked on. > I hope everyone is enjoying their holidays. I wish > you all a Happy New Year! Same to you Andreas -- http://fam-tille.de
Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)
Am Wed, Dec 27, 2023 at 09:43:19PM +0100 schrieb Steffen Möller: > > for teaching and meeting reasons. > > > > But as I just wrote, 17-18 also works. > > I'd opt for the earlier date, so we have a bit of a break before some of us I > expect to bump into each other again in Hamburg if Holger's event > materialises a month later. Well, but there is FOSDEM 3+4. February - so this is even more dense. I'd love to fix 17-18. February (or lets meet at 16.2. February evening inside the water tower like last year.) Kind regards Andreas. -- http://fam-tille.de
Re: Please help fixing meson/cmake code of btllib to use Debian packaged libargparse
Am Fri, Dec 29, 2023 at 11:35:41AM +0530 schrieb Nilesh Patra: > On a brief look, it does not seem easy and would mean maintaining a debian > specific > patch for ever which maybe non-trivial for future versions. > > Can we not support just the default python3-dev? Sure. Feel free to implement this - I'm just not available for the next couple of days. Kind regards Andreas. -- http://fam-tille.de
Re: Please help fixing meson/cmake code of btllib to use Debian packaged libargparse
Hi, Am Thu, Dec 28, 2023 at 03:28:54PM +0530 schrieb Nilesh Patra: > > Fixed the build. Now it fails at dh_missing due to python stuff not being > installed. > I am not sure if you want to create a new bin pkg with python wrapper or not > - so I > leave the onus of finalizing it onto you. I've added python3-btllib but its not that easy since we obviously need to add different modules for Python3.11 and Python3.12. I have no spare cycles to implement this and leave it to someone who might be faster than I (probably not before 9. January). Kind regards Andreas. -- http://fam-tille.de
Please help fixing meson/cmake code of btllib to use Debian packaged libargparse
Hi, libargparse was accepted by ftpmaster. Now meson code needs to be adjusted to create a proper cmake input file to use the Debian packaged version of libargparse (may be even that needs some cmake helper to be detected properly). Currently I do not have time to care for this[1]: ../meson.build:57:35: ERROR: Unknown variable "argparse_subproject". Any help would be welcome Andreas. [1] https://salsa.debian.org/med-team/btllib/-/jobs/5088102 -- http://fam-tille.de
[Advent bug squashing] Thanks to all who joined the fun
Hi, I think bug #1059214 was my last one in this years Advent bug squashing. Thanks to all who joined. For those who missed the fun for whatever reason there are some "add build support for loongarch64" and some "Fails to build source after successful build" low hanging fruits left. ;-) For those who live in those parts of the world where Christmas matters I wish a merry Christmas. I'm looking forward work together with all of you next year Andreas. -- http://fam-tille.de
Re: Python-iow Autopkgtest Review (Bug #1035258)
Hi Israel, Am Sat, Dec 23, 2023 at 08:07:22PM +0100 schrieb Komolehin Israel: > I worked on Python-iow package by providing autopkgtest and providing a > patch to fix some issues with the upstream test. CI was successful. Nice. > I would like this package to be reviewed as the test fails with Python3.12. > I have provided a readme in debian/tests to document the source of the test > failure which is pandas, however test passes with python3.11 and CI was > successful. For the next time please add a DEP3 header to your patches. > I look forward to review and upload if all looks good. I will submit a bug > report for test failure with Python3.12. Uploaded. Thanks a lot for your preparation Andreas. -- http://fam-tille.de
Re: Do we need pynwb - if yes please care for its new dependency
Hi Yaroslav, Am Thu, Dec 21, 2023 at 03:52:26PM -0500 schrieb Yaroslav Halchenko: > So a solution would be to revert going to monitor github and then reimport > source. I do not think it is worthwhile packaging nwb-schema at this point > since small and unlikely we would bother packaging any other package which > would use it directly. > > Do you agree to such changes -- then I could do the needed dance with git repo > , just let me know. I was more or less blindly following DPT advise to prefer Github over PiPY. Just feel free to do whatever seems the most efficient solution for you. Thanks a lot for your quick response Andreas. -- http://fam-tille.de
Do we need pynwb - if yes please care for its new dependency
Hi Yaroslav, I bumped pynwb to its latest upstream version a couple of times. It was not release in any stable release since o-o-stable since the package was always in a bad state. Popcon is pretty low[1] - but we do not see any Ubuntu users here so may be that's a weak metric. My recent update in Git to latest upstream has uncovered that it needs a new predepends[2]. If you consider this package a good citizen inside Debian it would be great if you would care for this new package. Other bugs should be fixed in Salsa, thought. Kind regards Andreas. [1] https://qa.debian.org/popcon.php?package=pynwb [2] https://github.com/NeurodataWithoutBorders/nwb-schema -- http://fam-tille.de
Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)
Hi Sascha, Am Thu, Dec 21, 2023 at 03:13:04PM +0100 schrieb Sascha Steinbiss: > > Absolutely! See [1] -- for February or early March we could have the room on > weekends without a problem. I am now waiting for you guys to come up with a > suggestion for possible specific dates so I can finalize the booking. > > How about Feb 10-11, for example? My weekends are still free for now so it's > your choice. I admit I'd prefer Feb. 17-18 over 10-11. Other opinions? We could setup some poll if needed, but may be we can find a date the easy way. ;-) Kind regards Andreas. -- http://fam-tille.de
Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)
Hi Sasccha, did you managed to reserve a room for our sprint? It would be nice if we know in advance to arrange travel for those who do not come from close by. Kind regards and have a nice CHristmas Andreas. Am Mon, Nov 20, 2023 at 06:12:47PM +0100 schrieb Andreas Tille: > Hi Sascha, > > thanks a lot for checking the know venue. > > Am Mon, Nov 20, 2023 at 03:27:35PM +0100 schrieb Sascha Steinbiss: > > > I wouldn't mind going somewhere else for a change... but i can > > > surely ask if we can have another weekend in February. > > Same for me - I would like to meet at any location but we need some > volunteer who will care for the venue. So far nobody volunteered to do > the work. Lets wait until the upcoming weekend for someone to volunteer > to do the actual work (not suggesting where it could be nice - we all > know the world has some nice places ;-) ) If this is not the case I > think Berlin is fixed and we should decide for a date. > > > I have made some inquiries and as long we're only there on the weekend, > > there are no blockers for at least February, likely also March. > > I'd be happy to take care of the preparations once we come up with a > > date, should we choose to meet in Berlin again. > > We might do the same as last year: Booking the room on top of the water > tower for a Friday evening meeting and use the office of Saschas company > for Saturday and Sunday. > > See you in February > Andreas. > > -- > http://fam-tille.de > > -- http://fam-tille.de
Re: [Advent bug squashing] newer bmtk version, and other niceties
Hi Étienne, Am Wed, Dec 20, 2023 at 08:51:34PM +0100 schrieb Étienne Mollier: > And with this, I will probably wind down my activity for the > remaining of the year Thanks a lot for all your work and have a nice Christmas Andreas. -- http://fam-tille.de
needs-internet restriction (Was: Bug#1010653: closed ...) (Bug#1010653: fixed in busco 5.5.0-2)
Hi Andrius, Am Wed, Dec 20, 2023 at 08:27:31AM +0200 schrieb Andrius Merkys: > On 2023-12-19 18:51, Debian Bug Tracking System wrote: > > [ Komolehin Israel Timilehin ] > > * Added autopkgtest to check hmmer and prodigal integration (Closes: > > #1010653) > > Thanks for working on this. I see that the added autopkgtest uses network to > download the dataset. It is done properly, with 'needs-internet' > restriction, which is good. However, does Debian CI enable internet access > for such autopkgtests? Isn't it exactly what needs-internet restriction was invented for? May be I'm to naive here but I used it exactly for those cases and it worked. Kind regards Andreas. -- http://fam-tille.de
Re: Thanks a lot [ftpmas...@ftp-master.debian.org: ugene_49.1+dfsg-1_amd64.changes ACCEPTED into unstable]
Hi Pierre, Am Tue, Dec 12, 2023 at 09:09:46PM +0100 schrieb Pierre Gruet: > You're welcome! I am astonished to see it cleared NEW in one hour anf a half, Yes, I had to double check when I've seen this. Very nice > I had not even the time to prepare my Advent Calendar email related to it. :- > That said, I am always very happy when we move software out of non-free! That's definitely the best we can do! I've adde Ugene to our SoftwareLiberation Wiki page[1] > Bug #1032688 was solved by you, and bug #1010358 by Michael :) Well, I'm perfectly fine if these go on your account in team metrics (which works per changelog owner). ;-) Kind regards Andreas. [1] https://wiki.debian.org/DebianMed/SoftwareLiberation -- http://fam-tille.de
Thanks a lot [ftpmas...@ftp-master.debian.org: ugene_49.1+dfsg-1_amd64.changes ACCEPTED into unstable]
Hi Pierre, this is really good and important work. Thanks a lot for it Andreas. - Weitergeleitete Nachricht von Debian FTP Masters - Date: Tue, 12 Dec 2023 19:00:13 + From: Debian FTP Masters To: Debian Med Packaging Team , Pierre Gruet Subject: ugene_49.1+dfsg-1_amd64.changes ACCEPTED into unstable Thank you for your contribution to Debian. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 12 Dec 2023 14:49:53 +0100 Source: ugene Binary: ugene ugene-data ugene-dbgsym Architecture: source all amd64 Version: 49.1+dfsg-1 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team Changed-By: Pierre Gruet Description: ugene - integrated bioinformatics toolkit ugene-data - required data for UGENE - integrated bioinformatics toolkit Closes: 1010358 1018252 1032688 Changes: ugene (49.1+dfsg-1) unstable; urgency=medium . * Team upload * New upstream version 49.1+dfsg * Refreshing patches * Shipping to main instead of non-free (Closes: #1018252): - Excluding files with non-free license (*.so and psipred) - Rewriting d/copyright * Updating install paths * Setting the runpaths so that private shared libraries can be found * Fixing spelling mistakes * Using python3 instead of python in shebangs * Fixing Lintian override syntax * Overriding Lintian warnings about spelling errors due to false positives . [ Andreas Tille ] * Fix watch file * Standards-Version: 4.6.2 (routine-update) * Build-Depends: s/libprocps-dev/libproc2-dev/ (Closes: #1032688) . [ Michael R. Crusoe ] * debian/patches/Fix-for-non-constant-SIGSTKSZ.patch: from Ubuntu, Closes: #1010358 Checksums-Sha1: 94b7823fb1fc97799fbfe4df06950b8651d6ae7c 2290 ugene_49.1+dfsg-1.dsc 5a8f61ab1ef8a884ffd57cd5ee8f8c2cb4a8c594 16227828 ugene_49.1+dfsg.orig.tar.xz f7c9a78fda51e047a8c1630d98c5b9deb9d4e39b 40636 ugene_49.1+dfsg-1.debian.tar.xz 024ec6144aecdde337e85fd01371704ab0bdd4b0 7612600 ugene-data_49.1+dfsg-1_all.deb 3581df8eda69842e4d996c76428bf4384c85bd6d 608828980 ugene-dbgsym_49.1+dfsg-1_amd64.deb 8513bc897a1929f09f843b28f9460adf1f99ad67 13359 ugene_49.1+dfsg-1_amd64.buildinfo c5361fc2e28811066b4f6d687437d66b0b8ed183 22210740 ugene_49.1+dfsg-1_amd64.deb Checksums-Sha256: d6b50935c791298da631f297312be1a56f97684acefb2f462152d4f9cb544feb 2290 ugene_49.1+dfsg-1.dsc 0e84cb5ebc26bacddd0d538b9ccf0906c49ac867a39cc81c033f8d3adf796b6d 16227828 ugene_49.1+dfsg.orig.tar.xz 8dfa17a74603f24075957774dd602d7bf1e27c5c3494aca5fbb690f7fd5ac793 40636 ugene_49.1+dfsg-1.debian.tar.xz 73a0e7773901fc7bf59488ace2ef35c5d04dba0db5af8fbb9912da4cbe1560b2 7612600 ugene-data_49.1+dfsg-1_all.deb f627e3ca06edc61b7fff9ff33af4f5b0da70e7b1ae9e45d6e4220351c3fa5030 608828980 ugene-dbgsym_49.1+dfsg-1_amd64.deb 954a1daca20405613f306cdbba456a469ebab70b3a94711e33d56dbd4515582b 13359 ugene_49.1+dfsg-1_amd64.buildinfo 18b07770fb8abd57a756f2454386e1df0c0290b239923b21ac14b40832b204c3 22210740 ugene_49.1+dfsg-1_amd64.deb Files: 4741a35a40dff8d6a425ea8d2772e62f 2290 science optional ugene_49.1+dfsg-1.dsc c2423d8701dc5fb5a007684882d3d167 16227828 science optional ugene_49.1+dfsg.orig.tar.xz 8a36134d6fed4abd7e1424770ec7 40636 science optional ugene_49.1+dfsg-1.debian.tar.xz 5be3f6a848d90b76512e81251b53cd83 7612600 science optional ugene-data_49.1+dfsg-1_all.deb c31a479dfc5ba8d9b8982ac92662e1ea 608828980 debug optional ugene-dbgsym_49.1+dfsg-1_amd64.deb f336fa8fdc484f38d594f6d1784fdab2 13359 science optional ugene_49.1+dfsg-1_amd64.buildinfo 180f6b1502a223163062a95437b1bd96 22210740 science optional ugene_49.1+dfsg-1_amd64.deb -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEM8soQxPpC9J9y0UjYAMWptwndHYFAmV4kFcACgkQYAMWptwn dHYEhRAAlbfyripVaCFyMh1w3S1E+LtpMnXAuH97NfaX6aQ0rOxLlKIj8rXifFzv 308w8/EXks+EbenRPqXcCwXgtasntaOfJZ2r2ENzl/avGmTg3DQ/TD6YDYb5zeSC 5RoQcZ7SF+UmMi5/jS6fphROzjbsTvg+7tH4N4W0bxF1Y3ARRnz+20ytbuORhgHz F+5zA9VVvsYr/enVb62FZBcn0ATAM9b8B3TAhlwShWRQXVDx3ylpca9vi+u2DwWz 4xoA0HayspzoEXiOh7Rx7dq1GeKWjkp69OL/Vs5u6gzY21Iw7VFDFifww2JwfNJS jDW3EqZiGnBu4t4Zz4xYodgCkAbCtTJbhxRL+LCeaD8OtbSglg9bsCfQOC8geyBd LExivKjCyroFe3Pd6K6vbI2o5XdWTkQM07r2Qwpg/Fh3FikEhfvi0AhFJJJIbunj M18QRYtidz7mBgkKi4p8rVKVuS665Eag1+hjVvzcU3Qij6qe3TD9MzJON+OEnMUP 2kUKZ+J+U1sRo09PwEYtBkj6845PSRbFxeLpv51hnxqcWbiOR52j+9imhqBVL2gn UB0bb5bF297FmCmKxxmRczkeUlZy6A49el+iD8UG1hSrBzrWGRI0qsmhqaO3fu3s qIiOTa/2/34aj4QJ1WcNyqB/uv8x36kCJsZ07PB0oSrirQL4GK8= =1Bbg -END PGP SIGNATURE- ___ Debian-med-packaging mailing list debian-med-packag...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging - Ende weitergeleitete Nachricht - -- http://fam-tille.de
Re: Attempt to upgrade sra-sdk
Hi Aaron, Am Sun, Dec 10, 2023 at 06:30:01PM -0500 schrieb Aaron M. Ucko: > > Because env/common.cmake doesn't actually try to use a system > installation: > > #check_include_file_cxx(mbedtls/md.h HAVE_MBEDTLS_H) > set(HAVE_MBEDTLS_H 0) # TODO: disabling system mbedtls since it may be > outdated > > Patching that logic to enable and honor the check reveals that its > concerns are legitimate, with upstream bundling and evidently relying on > a 3.x version whereas Debian still ships 2.28.5; arranging to use the > Debian version yields several compilation errors in libs/cloud/gcp.c's > Sign_RSA_SHA256, and quite possibly more errors elsewhere. > > Per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036231, Debian > packaging of mbed TLS 3.x is waiting on a long-term-support release > series thereof, so our options are either backporting ncbi-vdb to build > against 2.28. (perhaps with the help of reverse cherry-picks) or > reinstating the bundled 3.x copy. Thanks a lot for your analysis. I admit I stumbled for no important reason over sra-sdk and friends. I'm perfectly fine with delaying the upgrade until Debian packaged mbed is catching up. Kind regards Andreas. -- http://fam-tille.de
Re: Attempt to upgrade sra-sdk
Hi Aaron, Am Sat, Dec 09, 2023 at 08:23:26PM -0500 schrieb Aaron M. Ucko: > > AFAICT, the immediate problem is that label_online_tests.patch refers to > at least one removed or renamed test: > > CMake Error at test/internal/vdb-diff/CMakeLists.txt:42 > (set_tests_properties): > set_tests_properties Can not find test to add properties to: > Test_VDB_Diff_Check_success > > Temporarily disabling this patch will let you focus on compilation > issues for the time being. We'll probably leave this for later > Please also bear in mind that upstream maintains this code in > conjunction with ncbi-vdb (lower-level) and ngs-sdk (higher-level), so > it may help to update ncbi-vdb first and you may want to update ngs-sdk > afterwards. I should have known this but unfortunately I forgot. I've pushed the latest version of ncbi-vdb with patches adapted but get: No mbedtls libs found installed in the system, using local copy... -- Configuring done (1.1s) CMake Error at libs/ncbi-vdb/CMakeLists.posix.txt:56 (add_library): Error evaluating generator expression: $ Objects of target "mbedx509" referenced but no such target exists. Call Stack (most recent call first): libs/ncbi-vdb/CMakeLists.txt:84 (include) CMake Error at build/common.cmake:185 (add_library): Error evaluating generator expression: $ Objects of target "mbedx509" referenced but no such target exists. which is strange since libmbedtls-dev is in Build-Depends. I'll leave this to someone who is more educated with cmake than I. > I'll take a closer look when I get a chance. Hope my preparation is some welcome kick-start. I wonder whether some of our patches could be forwarded upstream to reduce the number of edits for any new version. Kind regards Andreas. -- http://fam-tille.de
Attempt to upgrade sra-sdk
Hi Aaron, I've spent some time into the new version of sra-sdk and tried to adapt the patches to the new upstream version. Salsa CI was not working at the time of pushing so there is no build log but if you might like to try on your side you will notice that my attempt failed. I'd be super happy if you might find some time to get the build working again. Kind regards Andreas. -- http://fam-tille.de
Upgrading fis-gtm and closing CVE-2021-44496 CVE-2021-44504
Hi Amul, I realised that fis-gtm is lagging behind upstream some versions and the Debian packaged fis-gtm is featuring CVE-2021-44496 and CVE-2021-44504. It would be great if you could upgrade the Debian package to the latest upstream version. Kind regards, Andreas. -- http://fam-tille.de
Debian Med video meeting tomorrow Saturday 2023-12-09 19:00 UTC
Hi, this is the call for the next video meeting of the Debian Med team that are an established means to organise the tasks inside our team. Meetings usually take us only 15-20min depending what we are talking about and how many people are joining. The next meeting is tomorrow https://www.timeanddate.com/worldclock/fixedtime.html?iso=20231209T19 Despite technical issues of the last meeting I think we stick to the known Debian Social channel https://jitsi.debian.social/DebianMedCovid19 The topic is what contributors have done in the past period and to coordinate the work until the next meeting. For those who are interested in hot topics we want to tackle, here are some items: - Status of BioConductor transition - Python 3.12 transition - Advent bug squashing Newcomers are always welcome. See you tomorrow Andreas. -- http://fam-tille.de
Wrong calls of snpEff in snippy (Was: Could some SnpEff user from the community please ping authors)
Control: reassign -1 snippy Control: retitle -1 Wrong calls of snpEff Control: tags -1 upsteam Control: forwarded -1 https://github.com/pcingola/SnpEff/issues/510 Thanks to snpEff upstream I've found a solution[1] for the problem reported above. I've also added a conscise test case[2] which was exposing the problem above (which is solved) but in a later call to snpEff with a different command a new problem occures. I have reported this to snpEff[3] since I hope to get quick help there for another patch to snippy to simply get rid of some single line in some output file. If all fails we can remove this manuall inside the snippy Perl code but I'm striving for a clean solution here. Kind regards Andreas. [1] https://salsa.debian.org/med-team/snippy/-/blob/master/debian/patches/snpeff_v5.1%2B.patch [2] https://salsa.debian.org/med-team/snippy/-/blob/master/debian/tests/test_for_working_snpeff_v5.1%2B [3] https://github.com/pcingola/SnpEff/issues/510 -- http://fam-tille.de
Re: Could some SnpEff user from the community please ping authors
Hi Nilesh, Am Wed, Dec 06, 2023 at 02:00:52AM +0530 schrieb Nilesh Patra: > Sometimes just tagging upstream author does wonders :) I hope I'll keep that trick in mind! ;-) > They have replied and the (upstream) bug has been closed. > BTW, are you able to still reproduce (without any fixes for snpeff/snippy) > #1031465? Confirming snippy builds nicely and bug can be closed. > For me, it is working fine in an unstable chroot (including autopkgtests) > and maybe could be closed. I've just pushed a patch for snippy that works with the options suggested by snpEff upstream. I need to do some further tests but I think the problem is solved. Kind regards Andreas. -- http://fam-tille.de
Re: [Advent bug squashing] 9 bugs + 1 bug = 10 bugs
Hi Étienne, Am Sun, Dec 03, 2023 at 03:54:57PM +0100 schrieb Étienne Mollier: > > Please leave some low hanging fruits for me! ;-P > > I see at least four screenful worth of low hanging fruits in the > bug tracking system affecting Debian Med packages, if not more. > That should be plenty for everyone. ;) Pt, don't tell here on a public list. You are uncovering the reason why I was able to close so many bugs in the past. Newcommers might step in and start closing bugs ... Or even people claiming to have to less time find out it just takes less than 5min to close a bug. > > Honestly, if you both as well as Nilesh would not have joined the team > > we would not manage to do all the work. Its a great pleasure for me to > > work together with you all. > > You're welcome! Thanks again Andreas. -- http://fam-tille.de
Re: [Advent bug squashing] 9 bugs + 1 bug = 10 bugs
Hi Pierre and Étienne, Am Sun, Dec 03, 2023 at 11:55:05AM +0100 schrieb Étienne Mollier: > Hi, > > Pierre Gruet, on 2023-12-03: > > Fixing minor bugs #1043696, #1045612, #1046315, #1046647, #1046802, > > #1046809, #1047000, #1048408, #1049745. Not crucial, but they offer the > > opportunity to do some housekeeping in our packages! > > Agreed, now is the good time to unclutter the bugs panel and > sort the low hanging fruits. On my end I just sorted #1040588, > which is also more or less an easy bug in the same spirit. Please leave some low hanging fruits for me! ;-P Honestly, if you both as well as Nilesh would not have joined the team we would not manage to do all the work. Its a great pleasure for me to work together with you all. Kind regards Andreas. -- http://fam-tille.de
[Advent bug squashing] #1057132 and #1057253 done
Hi, closed #1057132 yesterday and #1057253 today. For those who might consider reporting closed bugs here too much noise we can also report it on our Matrix channel[1]. In any case I'd like to announce here that Étienne has fixed this year more bugs than I in Debian Med team. I'm absolutely happy to be beaten and hope more people will follow Étienne's example and fix more bugs! Feel free to pick your bug of choice - there are a lot more targets. Kind regards Andreas. [1] https://app.element.io/#/room/#debian-med:matrix.org [2] http://blends.debian.net/liststats/bugs_debian-med.png -- http://fam-tille.de
[Advent bug squashing] Bug#1057127: marked as done (jellyfish1: add support for loongarch64 in d/control)
Hey, this was a pretty simple one but I was extremely busy with Bioconductor transition. So that simple one with patch came pretty convenient. I guess there are at least 24 similarly simple ones. Just pick these if you are a beginner. ;-P Happy bug squashing Andreas. - Weitergeleitete Nachricht von Debian Bug Tracking System - -- 1057127: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057127 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems Date: Thu, 30 Nov 2023 16:18:31 +0800 From: zhangdandan To: sub...@bugs.debian.org Subject: jellyfish1: add support for loongarch64 in d/control Source: jellyfish1 Version: 1.1.11-8 Severity: wishlist Tags: patch User: debian-loonga...@lists.debian.org Usertags: loong64 Dear maintainers, We need to add support for loongarch64 in d/control. Please refer to the following changes in d/control, ``` Package: jellyfish1 Architecture: amd64 arm64 loong64 mips64el ppc64el hppa ia64 kfreebsd-amd64 riscv64 ``` Applying the above modifications, the jellyfish1 source package was compiled successfully on my local loong64 rootfs environment. Would it be possible to include the support for LoongArch in the next upload? If you have any questions, you can contact me at any time. thanks, Dandan Zhang Date: Fri, 01 Dec 2023 12:49:19 + From: Debian FTP Masters To: 1057127-cl...@bugs.debian.org Subject: Bug#1057127: fixed in jellyfish1 1.1.11-9 Source: jellyfish1 Source-Version: 1.1.11-9 Done: Andreas Tille We believe that the bug you reported is fixed in the latest version of jellyfish1, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1057...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Andreas Tille (supplier of updated jellyfish1 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 01 Dec 2023 11:51:12 +0100 Source: jellyfish1 Architecture: source Version: 1.1.11-9 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team Changed-By: Andreas Tille Closes: 1057127 Changes: jellyfish1 (1.1.11-9) unstable; urgency=medium . * Add support for loongarch64 in d/control Closes: #1057127 * Standards-Version: 4.6.2 (routine-update) Checksums-Sha1: 2502f1332e6951af0a9b3e577149dc6cca77a2f1 2170 jellyfish1_1.1.11-9.dsc 7712fe8f75d7792bc4a121a9da68900bc15011ce 6376 jellyfish1_1.1.11-9.debian.tar.xz 1983c1e5601c687126486f699d8320fe6557454e 6349 jellyfish1_1.1.11-9_amd64.buildinfo Checksums-Sha256: 9f0305481a81fe3f2db05e152cc98d09ad48516e129fdb4b5707ba0c4e1259ba 2170 jellyfish1_1.1.11-9.dsc 2248b754a1afcc2e6e2df8860ca3a1d7241a839f958735538c4712146a322884 6376 jellyfish1_1.1.11-9.debian.tar.xz dba95ec124d97d01387678b68749022b83b2d2521549c4554d0865ffe15d1256 6349 jellyfish1_1.1.11-9_amd64.buildinfo Files: b1899fc5601fb26e17308465fd21f232 2170 science optional jellyfish1_1.1.11-9.dsc bce2ccdb4cdb2adda667c22486945eab 6376 science optional jellyfish1_1.1.11-9.debian.tar.xz 12e9adc14a1ba692d6184cf58a6f1e6a 6349 science optional jellyfish1_1.1.11-9_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmVp0bMRHHRpbGxlQGRl Ymlhbi5vcmcACgkQV4oElNHGRtGBxQ//QtH88VeFggVtzGlnsw3s/rWcQJS4h36j DEwtUxZ2ysV2G9pBwJU6/6JtMbvNAqxFYCvF7QGen65hp1KALe9LDvz0+XRC7l41 8MTFD1ITut7BUA2hkYyjFVU/Jp0m59RET+AMiPQkNRGAem703uKgLK4KRyStRjMm QTmLTf2XDA0Mz6Uvus54lSPYqOiv0sgmAPdqWhcOqqYwFg795d9PCPrZT5LBjXhA G1uOoRW+kzFqB+x5XZB726wrRGl16lzhCCcivAO+2wN3RlidAWiSsBGbxmQy+JSK Zvr/APWyKfZKv4ekjb/WcfTZSIfiF+dIPwBA3L74OqD/GASXmW7O4mcvLRwDK/vd WftYMo738ff9qbreHCCo04XX/Pjhb8YphVVLeR7BExOxszuDm5BfP1cvXHME2E03 Jp6415z7CUg3m5AfP0/EN3qTCoNxc/NXaeKSEKRXr5F9HKG4C/ieraSS4vjEOL2J /3GP9cOuwXDthXrHwA3T6g+/O/ZY/kESarF8eejFeTJZXD3ejQZSbSKM4k7Z5Chy 6wUjsKyotbS9yVXR4M7BoWPjoDSNRZ0pEyUEt015ghx7UqL7peC0JHuiSrnY7WzU ylo5HHWLJs5pg2qgDj5FHoZGys84oykVZRSzTTpTdMy7kUtbV1b6Qeqhb11Br3Ur 3qURv0jExJM= =KRs4 -END PGP SIGNATURE- ___ Debian-med-packaging mailing list debian-med-packag...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging - Ende weitergeleitete Nachricht - -- http://fam-tille.de
December is bug squashing month
Hi folks, until 2021 we had the nice bug squashing advent calendar manually maintained by Thorsten Alteholz. Since Thorsten confirmed that this manual work is draining time from his other tasks for Debian mainly his ftpmaster task. I'd like to thank Thorsten again for all his effort - even mor for the ftpmaster work than the calendar. So last year we went without the graphical gimmick but I've posted my bug(s) of the day to the list. I'd like to invite everybody to do the same here. For those who want to squash bugs I recommend the following resources: 1. Classical BTS: https://bugs.debian.org/debian-med-packag...@lists.alioth.debian.org Please note that at the end is a list of "Forwarded bugs" which also might need fixing. 2. Maintainer dashboard https://udd.debian.org/dmd/?email1=debian-med-packaging%40lists.alioth.debian.org=html#todo It also notes testing migration is an issue we want to fix and caring for this is also worth mentioning here in a posting. 3. Blends pages Bugs: https://blends.debian.org/med/bugs/ Testing migration and autopkgtest issues https://blends.debian.org/med/qa/ Any contribution to increase the quality of our packages is really welcome. Thanks in advance for your contributions Andreas. -- http://fam-tille.de
Could some SnpEff user from the community please ping authors
Hi, we tried to package snippy which has uncovered a bug in SnpEff which we have reported upstream[1] with some easily verificable data set and command line. Unfortunately we did not had any response from upstream. We even would consider to revert SnpEff version to a working one without this regression (like 5.0e). However, we would like to have the correct code base for this release but even asking for proper tagging of the code was ignored inside the issue. I wonder whether some people from the community might be able to join our attempt to get this issue fixed and raise their voice inside the Github issue (or use other channels) to get this finally fixed. I guess the problem does not only occure in snippy test suite but also in other pipelines so the community might be affected by this issue. Kind regards and thanks for your support Andreas. [1] https://github.com/pcingola/SnpEff/issues/455 -- http://fam-tille.de
genomicsdb not migrating and new upstream version
Hi Pierre, I realised that you've fixed bug #1054675 (thanks for doinig so) but that several architectures are failing to build[1] which I do not understand when looking at the build logs. Since there was a new upstream version I imported this and tried to adapt the patches. Unfortunately the new version does not build. I've switched on Salsa CI to late so we do not have build logs there but I guess you will be able to reproduce the failure at your site. It would be great if you could have a look. Thanks a lot for your work on this package Andreas. [1] https://buildd.debian.org/status/package.php?p=genomicsdb -- http://fam-tille.de
Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)
Hi Sascha, thanks a lot for checking the know venue. Am Mon, Nov 20, 2023 at 03:27:35PM +0100 schrieb Sascha Steinbiss: > > I wouldn't mind going somewhere else for a change... but i can > > surely ask if we can have another weekend in February. Same for me - I would like to meet at any location but we need some volunteer who will care for the venue. So far nobody volunteered to do the work. Lets wait until the upcoming weekend for someone to volunteer to do the actual work (not suggesting where it could be nice - we all know the world has some nice places ;-) ) If this is not the case I think Berlin is fixed and we should decide for a date. > I have made some inquiries and as long we're only there on the weekend, > there are no blockers for at least February, likely also March. > I'd be happy to take care of the preparations once we come up with a > date, should we choose to meet in Berlin again. We might do the same as last year: Booking the room on top of the water tower for a Friday evening meeting and use the office of Saschas company for Saturday and Sunday. See you in February Andreas. -- http://fam-tille.de
Re: Any suggestions for next Debian Med sprint (in person meeting)?
Am Thu, Nov 16, 2023 at 11:07:11AM +0100 schrieb Steffen Möller: > > I wouldn't mind going somewhere else for a change... but i can surely > > ask if we can have another weekend in February. > > Hamburg would also be fine with me. Important for the med team is > increasingly also what the ML team gets up to and the GPU acceleration > fronts. Should we somehow reach out? I'm perfectly fine if there is room that fits our needs (and requires a similar budget which is zero in the case of Saschas company). Kind regards Andreas. -- http://fam-tille.de
Debian Med video meeting tomorrow Saturday 2023-11-11 19:00 UTC
Hi, this is the call for the next video meeting of the Debian Med team that are an established means to organise the tasks inside our team. Meetings usually take us only 15-20min depending what we are talking about and how many people are joining. The next meeting is tomorrow https://www.timeanddate.com/worldclock/fixedtime.html?iso=2023T19 Despite technical issues of the last meeting I think we stick to the known Debian Social channel https://jitsi.debian.social/DebianMedCovid19 The topic is what contributors have done in the past period and to coordinate the work until the next meeting. For those who are interested in hot topics we want to tackle, here are some items: - BioConductor transition - Python 3.12 transition - Outreachy candidates Newcomers are always welcome. See you tomorrow Andreas. -- http://fam-tille.de
Re: Any suggestions for next Debian Med sprint (in person meeting)?
Hi Pierre, Am Fri, Nov 10, 2023 at 05:48:13PM +0100 schrieb Pierre Gruet: > > its autumn so we should prepare for winter. For Debian Med winter is > > the time where we usually do our in person meeting. The last meetings > > were in a perfectly fitting location in Berlin and I for myself would > > be fine to meet there again. If someone knows better option (also > > better for *you* to reach *your* location) do not hesitate to make to > > propose alternatives. > > No better idea from my part. The location in Berlin was actually fine and I > cannot propose a better (also closer to me) place. > Last time we discussed this, you evoked a place in Hamburg. Which would not > change a lot of things for me compared to Berlin. I remember someone suggested Hamburg but it was not me. If the person who suggested this would speak up it would be nice. Otherwise I would ask Sascha to make suggestions when the known venue is open for our sprint. > > I'd be happy if we could find some decision in the next 2-3 weeks since > > we probably need some time to organise the travel for people coming from > > a distant. I'd love if Nilesh would manage to come this year and visa > > things would be more successfully than last year. Kind regards Andreas. -- http://fam-tille.de
Re: migration to htslib ecosystem 1.18
Am Wed, Nov 08, 2023 at 06:50:25PM +0100 schrieb Étienne Mollier: > > I reran three or four times the autopkgtest on arm64 on my host > with no issues. The rerun on official CI also went fine in a > very reasonable time[1]. CI history of jellyfish[2] reveals two > occurrences of this issue lately, and the run from 2023-10-09 > happens to have a mismatching run time reported in the test > log[3]. There is one much older occurrence from last year, on > 2022-10-02, but no log associated given its age. The hundreds > of other runs were not affected by this issue. I'm tempted to > put that on a momentary hardware glitch at this point. OK, so nothing to worry about hopefully. Do you have time to look for the metabat issue I've posted on matrix (in contrast to my habit to post relevant things here, sorry about this). Thanks a lot for your investigation Andreas. > [1]: > https://ci.debian.net/data/autopkgtest/testing/arm64/j/jellyfish/39695945/log.gz > [2]: https://ci.debian.net/packages/j/jellyfish/testing/arm64/ > [3]: > https://ci.debian.net/data/autopkgtest/testing/arm64/j/jellyfish/38825944/log.gz -- http://fam-tille.de
Re: migration to htslib ecosystem 1.18
Hi Étienne, Am Wed, Nov 08, 2023 at 09:44:22AM +0100 schrieb Étienne Mollier: > > I'd like to rewrite bcftools autopkgtest according to the model of > > samtools. However, we need a new binary package bcftools-test which I > > rather delay util the set of packages has migrated to testing. > > Great, thanks for bumping all these! :) No problem. I also dived into the rdepends of libhts3 and stubled upon kallisto which has a new upstream version. I tried to upgrade to this but there is a cmake issue[1]: CMake Error at src/CMakeLists.txt:20 (ExternalProject_Get_Property): Unknown CMake command "ExternalProject_Get_Property". -- Configuring incomplete, errors occurred! I guess it is connected to the internal code copy of bifrost which I just packaged[2] (will try a short autopkgtest before uploading to new) We probably also need to talk to debci people since the upload of htslib has triggered a failing test for jellyfish on arm64[3]. When looking at the log[4] it ends with ... 182s [ RUN ] CooperativePool/CooperativePoolTest.Ints/9 10051s autopkgtest [06:02:56]: ERROR: timed out on command "su -s /bin/bash debci -c set -e; exec /tmp/autopkgtest-lxc.xayqrapq/downtmp/wrapper.sh --artifacts=/tmp/autopkgtest-lxc.xayqrapq/downtmp/run-unit-test-artifacts --chdir=/tmp/autopkgtest-lxc.xayqrapq/downtmp/build.N8X/src --env=DEB_BUILD_OPTIONS=parallel=4 --env=DEBIAN_FRONTEND=noninteractive --env=LANG=C.UTF-8 --unset-env=LANGUAGE --unset-env=LC_ADDRESS --unset-env=LC_ALL --unset-env=LC_COLLATE --unset-env=LC_CTYPE --unset-env=LC_IDENTIFICATION --unset-env=LC_MEASUREMENT --unset-env=LC_MESSAGES --unset-env=LC_MONETARY --unset-env=LC_NAME --unset-env=LC_NUMERIC --unset-env=LC_PAPER --unset-env=LC_TELEPHONE --unset-env=LC_TIME --script-pid-file=/tmp/autopkgtest_script_pid --source-profile --stderr=/tmp/autopkgtest-lxc.xayqrapq/downtmp/run-unit-test-stderr --stdout=/tmp/autopkgtest-lxc.xayqrapq/downtmp/run-unit-test-stdout --tmp=/tmp/autopkgtest-lxc.xayqrapq/downtmp/autopkgtest_tmp --make-executable=/tmp/autopkgtest-lxc.xayqrapq/downtmp/build.N8X/src/debian/tests/run-unit-test -- /tmp/autopkgtest-lxc.xayqrapq/downtmp/build.N8X/src/debian/tests/run-unit-test" These timeout thingies are really hard to debug. Maybe we should simply shorten the jellyfish test suite to avoid this. For instance droping the `/usr/lib/jellyfish/bin/test_all` call at the end makes the test more sensible (also in terms of not stressing debci infrastructure to much? What do you think? Kind regards Andreas. [1] https://salsa.debian.org/med-team/kallisto/-/jobs/4901979#L1704 [2] https://salsa.debian.org/med-team/bifrost [3] https://tracker.debian.org/pkg/htslib [4] https://ci.debian.net/data/autopkgtest/testing/arm64/j/jellyfish/39674223/log.gz -- http://fam-tille.de
Re: migration to htslib ecosystem 1.18
Am Tue, Nov 07, 2023 at 10:27:04PM +0100 schrieb Étienne Mollier: > > Yup, there may be some tight coupling between samtools and Samtools and bcftools uploaded. > python-pysam, but the latter's upgrade will be needed for the > upcoming python 3.12 transission anyway. I've seen the bug report and will check this now. > If someone wants to > beat me at having a look at these while I sleep, they may be > good targets for help. htslib 1.18 has been accepted in > unstable, so once it's built, this should facilitate things for > whoever who wants to have a look. I'd like to rewrite bcftools autopkgtest according to the model of samtools. However, we need a new binary package bcftools-test which I rather delay util the set of packages has migrated to testing. Kind regards and thanks for starting with htslib Andreas. -- http://fam-tille.de
Re: migration to htslib ecosystem 1.18
Hi Étienne, Am Mon, Nov 06, 2023 at 10:30:04PM +0100 schrieb Étienne Mollier: > I kind of forgot an htslib upload to experimental in version > 1.18 for like two months, and which had no excuses[1] for > lingering like that. I will have some time on Wednesday to do > things, and I considered the idea of bumping the htslib and > related packages ecosystem to version 1.18 to spend the time. > > [1]: https://qa.debian.org/excuses.php?experimental=1=htslib > > There may be turbulences in this package ecosystem if I badly > anticipate corner issues, but nothing outstanding stood out in > the past two months, so time for larger distribution I guess. Thanks a lot for caring about this. Just ping here if you need some help for uploads of htslib rdepends to experimental if you think this might be needed. Thanks again Andreas. -- http://fam-tille.de
Any suggestions for next Debian Med sprint (in person meeting)?
Hi, its autumn so we should prepare for winter. For Debian Med winter is the time where we usually do our in person meeting. The last meetings were in a perfectly fitting location in Berlin and I for myself would be fine to meet there again. If someone knows better option (also better for *you* to reach *your* location) do not hesitate to make to propose alternatives. I'd be happy if we could find some decision in the next 2-3 weeks since we probably need some time to organise the travel for people coming from a distant. I'd love if Nilesh would manage to come this year and visa things would be more successfully than last year. Kind regards Andreas. -- http://fam-tille.de
Re: canu
Hi Tony, Am Wed, Nov 01, 2023 at 05:11:41PM + schrieb Tony Travis: > > Sorry, the attached screenshot with your picture on it is what I read, but I > didn't notice that it was the upstream README.md. O, dear, if I would have written all the stuff where Github instances put my picture on it, I would probably need a couple of life times. ;-P > > BTW, should we take the message that it makes sense to suggest > > slurm-client for canu from your observation? > > No, because "canu" works without "Slurm": Yes, it works without slurm. If it would really need slurm we would use Recommends or even Depends. Suggests means that it might work better under some circumstances. I'm just undecided because slurm itself needs a bit more than just install the client package and you have immediate advantage without more administration. > Our problem was that the saved > state of the Slurm controller was incompatible with the upgraded version of > Slurm. I'm not sure how that happened, but this is not my server and I was > simply helping to diagnose why "canu" crashed. > > Unfortunately, I didn't save the error messages, but I saw that "canu" was > reporting problems submitting a job to "Slurm". I installed "canu" in a > Bioconda env so that my colleague could continue his work, then I removed > the stale job-state information and restarted "Slurm". > > At some point, I'll reinstall "canu" from the Med-Bio package, but at > present I don't want to disrupt the work on someone else's server. I'll use > the Ubuntu Bug-Tracker to report any issues after reinstalling. Thanks a lot for the precise report Andreas. -- http://fam-tille.de
Re: canu
Am Wed, Nov 01, 2023 at 10:02:24AM + schrieb Tony Travis: > I didn't say that you gave advice "to use bioconda": I said that I had > followed your advice 'about installing "canu" under "bioconda3"'. > > I needed to fix the problem we encountered with "canu" installed from the > Debian-Med package quickly and adopted a pragmatic solution. This is what I > read in your notes about packaging "canu" for Debian-Med: > > > Installing with a 'package manager' is not encouraged, but if you have no > > other choice: > > > > Conda: conda install -c conda-forge -c bioconda -c defaults canu > > > > Homebrew: brew install brewsci/bio/canu I keep on insisting that these are *not* my notes. Its Upstream README.md what you are quoting. I'm pretty sure I will not write such advise since I'm literally uneducated about conda and have no idea about such command lines. > At the time, I believed that had no other choice... > > > > However, I would be interested to know if you have any plans to package it > > > again for Debian-Med? > > > > Canu is and remains packaged for Debian Med. Since you are using Ubuntu > > which derives from Unstable you will not even miss it even if the package > > might be removed from testing (which the bug you read is about). > > > > In short: Please be more verbose about your problem. > > Upon further investigation, it seems that the problems were caused by a > broken "Slurm" instance on the system in question due to an upgrade (the > saved state of the job queue was inconsistent with the new version of > "Slurm"). I didn't know that "canu" automatically detects the presence of a > job scheduler and will try to use it by default. In any case I'd recommend to add command line and output to give some context for your readers. > I keep forgetting that this is a Debian forum and you prefer me to send bug > reports to the Ubuntu Bug-Tracker. I will refrain from posting about > Debian-Med issues that I encounter under Ubuntu here in future. Please understand me correctly: I'd love to help you - but you need to provide context. Writing something in the sense of "canu is broken under Debian thus I had to use conda" is neither sufficient information to help you nor helpful for our project. Our bug tracker gathers some context (installed packages) and asks you for details which is helpful. If you can't use `reportbug` for whatever reason using this mailing list is a fallback we like to provide since Debian Med people like to care about their users. BTW, should we take the message that it makes sense to suggest slurm-client for canu from your observation? Kind regards Andreas. -- http://fam-tille.de
Re: canu
Hi Tony, Am Tue, Oct 31, 2023 at 11:13:13AM + schrieb Tony Travis: > What's the status of "canu"? Since canu has a test suite issue on arm64 a bug was filed[1]. Since we have no idea about this issue the forwarded the problem upstream[2]. > The "canu" package in Debian-Med appears to be broken under Ubuntu 22.04 and Sorry "broken under Ubuntu 22.04" is not a helpful information. While on several Debian forums you get the answer "this is Debian if you have a problem with Ubuntu ... blabla" you know that you are welcome here with questions. However, we do not have a magic ball to guess what exactly is broken. Please provide as minimum some command line and the output to enable us reproducing what exactly is broken. Under Debian on amd64 architecture its definitely not "obviously" broken since it is passing its CI test on this architecture which you are most probably using. > I see that it has been marked for removal in Nov 2023: This is due to a CI test issue on arm64 (see also discussion with upstream[2] which explains, that this issue seems to occure only under specific CI circumstances). This again raises the question: What is broken for you and do you possibly want to report this in an upstream issue? > > https://tracker.debian.org/pkg/canu > > @Andreas, I've now removed the "canu" package and followed your advice about > installing "canu" under "bioconda3": I *never ever* gave any advise to use bioconda. > > https://salsa.debian.org/med-team/canu > > However, I would be interested to know if you have any plans to package it > again for Debian-Med? Canu is and remains packaged for Debian Med. Since you are using Ubuntu which derives from Unstable you will not even miss it even if the package might be removed from testing (which the bug you read is about). In short: Please be more verbose about your problem. Kind regards Andreas. [1] https://bugs.debian.org/1052347 [2] https://github.com/marbl/canu/issues/2271 -- http://fam-tille.de
Re: Orthanc Integration Test using Orthanc-wsi
Hi Sébastien, Am Tue, Oct 31, 2023 at 10:46:15AM +0100 schrieb Sébastien Jodogne: > > Please however could you explain me how to execute autopkgtests on my > development Debian, without having to recompile the package from scratch > everytime I try to modify the "debian/test/*" files? Generally we try to support users by copying the run-unit-test script to /usr/share/doc/PKG. However, in the orthanc-wsi package this is not the case since it seems, that the large TIFF file would blow up the package size too much. You might like to try running sh debian/tests/run-dicom-image-transcode-test on your local machine. Please note: If you would include a sensible test suite image right into your upstream tarball we could drop that extra image from somewhere else which would be way more sensible (also for other distributions). > I have strictly no experience with autopkgtests, and I don't have much time > to gather all the pieces by myself. Hope this helps Andreas. -- http://fam-tille.de
Re: Use of "UNRELEASED" in debian/changelog
Hi Santiago, Am Fri, Oct 20, 2023 at 02:43:57PM +0200 schrieb Santiago Vila: > One more question: I didn't get the hang of gbp to build > the package at first, so I put the orig.tar.xz below the working > directory and used good old "dpkg-buildpackage -S", since > I know dpkg-buildpackage is smart enough to ignore > the .git directory. > > To be sure everything was ok, I did a debdiff > between old and new *.dsc afterwards. If this is your workflow that's fine for me. > If I have already tagged the package and pushed commit and tags, > what are the potential bad effects of using plain "dpkg-buildpackage -S" > in a project which is setup to use gbp? I do not see any bad effects (but I did not used plain dpkg-buildpackage so I might overlook something). I simply have a gbp based workflow with pbuilder which I consider very important - actually pbuilder/sbuild are so important to me that I never consider the plain old build on local machine any more. This fits well into my gbp setup but I can't really imagine any conflict. > This is a question I always wanted to know but were afraid to ask... Not sure whether you are meeting the experts for this question here. Kind regards Andreas. -- http://fam-tille.de
Re: Use of "UNRELEASED" in debian/changelog
Am Fri, Oct 20, 2023 at 04:51:57PM +0530 schrieb Nilesh Patra: > > > (B) Yes, but only if you don't keep the package in a half-fixed state, > > i.e. only if you do all that at nearly the same time, including the tag > > and the new upload, so that we don't have changes in master > > without their debian/changelog entries. > > If I am not uploading the package even after fixing the bug in salsa, > I add changelog and leave it as UNRELEASED and also write some reasoning > as TODO for not doing so. I think Andreas does something similar. > Thus far, it has worked out well. ACK The main point of creating some changelog entry if there are some commits following the latest upload is to make sure another team member is aware that development has proceeded. Targeting "UNRELEASED" is just to make sure these changes were not uploaded. If you do things in one rush anyway I don't mind if you use one or two commits. > > To fix this in stable, I would create a branch called "bookworm" > > from the master commit matching the stable version and put > > the appropriate changes there. > > > > Just to be sure: The name of the branch would be "bookworm", > > not "master/bookworm" or anything like that, right? > > I do exactly this (no master/bookworm). Maybe you could consider using > debian/bookworm but just bookworm is also OK. I've used the latter in > the past, without issues. ACK Kind regards Andreas. -- http://fam-tille.de
Re: Adding autopkgtest to Orthanc-python
Hi, Am Fri, Oct 20, 2023 at 08:44:26AM +0100 schrieb Oyindamola Olatunji: > I am working on adding autopkgtest to the orthanc-python package. Whenever > I run the test locally, it gets stuck in execution and doesn't seem to give > an output. > > Here is the autopkgtest: > https://salsa.debian.org/med-team/orthanc-python/-/commit/9e751a67614e90d383956f400906ce8121bcfc81 > > I look forward to your feedback. @Sebastian: An other outreachy intern has just written a test for main orthanc package. It seems to work so far. Please have a look and add some comments here. Regarding orthanc-python: I confirm I also can't run this test successfully. (@Oyindamola: It was important to set "Restrictions: needs-root" to make sure Orthanc will be found in Salsa CI.) The CI test in Salsa[1] ends with: ... I1020 09:35:19.401658 ServerIndex.cpp:510] Closing the monitor thread for stable resources I1020 09:35:19.402890 ServerIndex.cpp:308] Stopping the database flushing thread E1020 09:35:19.409488 main.cpp:2091] Uncaught exception, stopping now: [The TCP port of the DICOM server is privileged or already in use] (code 2004) W1020 09:35:19.409584 main.cpp:2122] Orthanc has stopped I have no idea what this might mean. Could you have a look at the test? I also realised that you are installing debian/configuration/sample.py Is it possible that even this script can be used as example? Kind regards Andreas. [1] https://salsa.debian.org/med-team/orthanc-python/-/jobs/4831625 -- http://fam-tille.de
