Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Hi all, first of all thanks Michael for this idea and also for the elaborate proposal email that outlines the intended way to go quite well. [...] Support Debian-Med packages for 32-bit and/or big-endian architectures is not a good use of our limited resources. Agreed. [...] However, I think it is okay if an individual Debian-Med maintainer wishes to support extra architectures, especially if upstream is supportive. Also, agreed. I am very likely not that maintainer. Various times already I have been struck by bug reports and failing builds for release platforms that are probably irrelevant for most users of the affected software. I pushed through to fix the issue while knowing that the typical user would not be using this specific software on, say, s390x or a Raspberry Pi. Yes, I am aware that having all that variety at our fingertips promotes experimentation, but does that really justify the extra effort? But if that maintainer can't keep up, and the package is causing problems for other Debian-Med packages, then we should be okay with removing the extra architectures again. ACK. 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. I'd rather like to see such a policy change to illustrate a common position that we'd rather disable an architecture and RM its binaries rather than fix a non-trivial issue on that platform, which might block a testing transition or cause some other roadblocks for the archs we actually care about. 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. How to make implement this policy with the tools available to us in 2024. 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? 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. 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 all the non-official architectures (alpha, hurd-*, m68k, ...)? Cheers Sascha OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#1064291: marked as done (ITP: python-awkward -- manipulate JSON-like data with NumPy-like idioms)
Hi Andreas,
[...]
debian/rules override_dh_auto_build
make[1]: Entering directory '/build/python-awkward-2.6.1'
nox -s prepare
nox > Running session prepare
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.
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None,
status=None)) after connection broken by
'NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution')': /simple/build/
WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None,
status=None)) after connection broken by
'NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution')': /simple/build/
WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None,
status=None)) after connection broken by
'NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution')': /simple/build/
WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None,
status=None)) after connection broken by
'NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution')': /simple/build/
WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None,
status=None)) after connection broken by
'NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary
failure in name resolution')': /simple/build/
ERROR: Could not find a version that satisfies the requirement build (from
versions: none)
ERROR: No matching distribution found for build
nox > Session prepare failed.
make[1]: *** [debian/rules:18: override_dh_auto_build] Error 1
Hmm, I never had that. The buildd builds also seem to pass this step
with no errors. 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
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:
❯ 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 :/
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. Whi
Bug#1064291: ITP: python-awkward -- manipulate JSON-like data with NumPy-like idioms
Package: wnpp Severity: wishlist Owner: debian-med@lists.debian.org X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-awkward Version : 2.6.1 Upstream Contact: Jim Pivarski * URL : https://github.com/scikit-hep/awkward * License : BSD-3-clause Programming Lang: Python, C++ Description : manipulate JSON-like data with NumPy-like idioms Awkward Array is a library for nested, variable-sized data, including arbitrary-length lists, records, mixed types, and missing 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.
Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)
Hi Andreas, 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. Done: https://wiki.debian.org/Sprints/2023/DebianMed2024 Also linked on the main sprints page. Cheers Sascha OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)
Hi all, [...] 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. 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? Cheers Sascha OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)
Hi all, I hope you have all had nice holidays, if that's a thing where you live :) 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). OK, I'll communicate this date to our office management team so they can arrange the necessary things with our security company. 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. Will you take care of the meeting room there (since you might be booking accommodation in the water tower again) or should I reach out to them? Thanks, and a happy new year Sascha OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)
Hi, [...] 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? Fine with me! Cheers Sascha OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)
Hi Andreas, [...] did you managed to reserve a room for our sprint? 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. Cheers Sascha OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Any suggestions for next Debian Med sprint (in person meeting)?
Hi all, [...] 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 wouldn't mind going somewhere else for a change... but i can surely ask if we can have another weekend in February. 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. Cheers Sascha
Re: Any suggestions for next Debian Med sprint (in person meeting)?
Hi all, [...] 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 wouldn't mind going somewhere else for a change... but i can surely ask if we can have another weekend in February. Cheers Sascha OpenPGP_signature Description: OpenPGP digital signature
Re: Unable to find source code for pbsv which would be helpful for cutesv autopkgtest
Hi Andreas, Unfortunately the upstream repository of pbsv does not contain any code and the issue tracker to contact upstream is deactivated. Any idea how to get the pbsv code? It looks like they are not distributing the code :/ There is a binary in the release section of the GitHub project [1] so it looks like that is indeed the official place to get the software from. So if they don't have the code there, my assumption is that it is not open source. Maybe contact Armin Toepfer [2], who is listed as having made the most recent changes to the repo and who also works for PacBio? Cheers Sascha [1] https://github.com/PacificBiosciences/pbsv/releases/tag/v2.9.0 [2] https://github.com/armintoepfer OpenPGP_signature Description: OpenPGP digital signature
Re: Sprint can start Friday evening - who would like to join
Hi all, FYI the Vietnamese place (Viet Kitchen) around the corner has many vegan options and is quite good. https://goo.gl/maps/M7gwo7S97qpqs6ms6 See you on Friday! Sascha On 17.01.23 17:40, Andreas Tille wrote: Am Tue, Jan 17, 2023 at 04:05:59PM + schrieb Matus Kalas: I'll hopefully be in Berlin already around 14:00, happy to join you (for me after dinner, as I'll probably opt for an early dinner, not managing a proper lunch that day) Do you want to suggest a vegan restaurant in possibly closest walking distance where we might meet 18:00 (or is even 18:00 to late for you)? Kind regards Andreas. OpenPGP_signature Description: OpenPGP digital signature
Re: Sprint can start Friday evening - who would like to join
Hi Andreas, [...] So we have two options: 1. Meet 18:00 at Campus and go for dinner later 2. Have dinner at 18:00 and book the room starting at 19:00 I don't really have a preference here, whatever suits the others best. Cheers Sascha OpenPGP_signature Description: OpenPGP digital signature
Re: Sprint can start Friday evening - who would like to join
Hi Andreas, thanks for getting things started! on top of the small hotel at EUREF-Campus 22 there is a lounge for 8 persons. I can book this with Debian sponsored money for the evening - so we can meet there. Who would like to join and at what time do we want to meet? I would like to join, but likely not before 18:00 on Friday. They hotel asked whether we would like to have catering in this room. Alternatively we could have dinner in a nearby restaurant (there is a vietnamese restaurant nearby). There are various options, yes. I am sure we will find something within walking distance from the campus :) See you all soon Sascha OpenPGP_signature Description: OpenPGP digital signature
Re: sprint 2023
Hi Andreas and Olivier, thanks for the info! Question is who the sprint 'organizer' is ;) We do not have such a role, but I volunteer to contact DPL. Thanks a lot for taking care of this. I'm sorry but there's quite a bit of stuff on my plate at the moment. [...] So nothing more expected on your side :-) ACK. Excellent, good to know. Happy holidays to all of you! Best regards Sascha
Re: sprint 2023
Hi all, did sprint organizer asked for DDs funding? Question is who the sprint 'organizer' is ;) I am providing the space, so are you also considering me the organizer in the sense of official communication? I was not aware of that, but if that's the case then please let me know how much you will be asking for in terms of funding. I'd be happy to bundle these requests send an email to the DPL for pre-approval as in [1]. Do you think there is a deadline for that? A word of caution: As you could see in the previous email thread [2] I might not be the best person to guesstimate such costs so please even state any 'obvious' amounts :) Cheers Sascha [1] https://lists.debian.org/debian-sprints/2020/01/msg0.html [2] https://lists.debian.org/debian-sprints/2020/01/msg9.html OpenPGP_signature Description: OpenPGP digital signature
Re: Possibility of In-person sprints in 2023?
Hi again, [...] Thanks for confirming. Sascha, did you had any success when asking for rooms we could use? I will bring it up again and let you know ASAP. I have been in touch with our front desk and it looks like a meeting at my employer here is doable in principle, given the same conditions as last time. So I guess Berlin could be an option. I'd prefer to wait until I have some confirmation in writing before making a reservation -- do we already have some idea of a timeframe I can communicate? Cheers Sascha
Re: Possibility of In-person sprints in 2023?
Hi all, [...] Thanks for confirming. Sascha, did you had any success when asking for rooms we could use? I will bring it up again and let you know ASAP. Cheers Sascha
Re: Possibility of In-person sprints in 2023?
Hi all, just returned from a weekend of travel with no email and now catching up. I suppose sprints in 2021 and 2022 have been virtual so far due to COVID. There were some COVID related sprints in 2020 as well. Is there a possibilty to have an in-person debian-med sprint in 2023? Would someone be interested in it, or so? I would be up for it, sure! Sascha, would it be possible again in the rooms of your employer in Berlin? I will make some inquiries and find out if that's posssible! Just as an option... Cheers Sascha
Re: 20 years of Debian Med list :-) and suggested sprint date
Hi all, > on Mon, 21 Jan 2002 11:59:11 +0100 the first mail to this list was > sent[1]. So somehow we can celebrate some anniversary. :-) Yay! =) [...]> I'd be happy if people who intend to join would confirm joining > the sprint and what date might be prefered. I don't really have a big agenda of things to do, but I might join in for some bug squashing and would also be happy to continue working on Arrow, if maybe someone would be interested in co-maintaining it. I don't really have a preference regarding the date, both would be fine for me so far. 18-20/2 is OK for me any way. Cheers Sascha
Re: apache arrow anyone?
Hi Steffen, [...] > I also think that the science-team's repository is where it should go. Done, now in https://salsa.debian.org/science-team/arrow. I have also added a README.Debian to summarize what is still open. I'd be more than happy to join in with some remaining tasks if there's a chance to get the package a safe home :) Cheers Sascha
Re: apache arrow anyone?
Hi Andreas, [...] > I'd recomment to move the packaging from satta to one of the > interested teams (either science or med or something that is close to > that audience). I'd be very happy to do that as I am a maintainer in both med and science. Just did not see the relevance for one of these teams back then when I did the first packaging. Sooo, which one would you recommend? I can move the repo as soon as we decide where to. My use case is not of a scientific nature, so Steffen if yours is not primarily med-focused, do we want to simply use `science-team`? Cheers Sascha
Re: apache arrow anyone?
Hi Andreas, On 23.08.21 13:3 [...] > I'd recomment to move the packaging from satta to one of the interested > teams (either science or med or something that is close to that audience). > > Kind regards and thanks a lot for your work on this > > Andreas. >
Re: apache arrow anyone?
Hi again, [...] > The rest of the story is that I considered my package ready to upload Ah, probably not -- taking a second look I apparently did not do the d/copyright yet. So not really ready to upload, some metadata polishing is still needed. Cheers Sascha
Re: apache arrow anyone?
Hi Steffen and Etienne, [...] >> Apache Arrow https://arrow.apache.org/faq/ knows how to efficiently >> handle large tabular data. And, while not in our distribution, it blocks >> some workflows for Debian Med. Arrow comes with interfaces to all the >> prominent languages, for the Med-workflows it is typically the Python >> interface pyarrow that is needed. I am also facing a project [1] that now made a dependency on Arrow (the C++ interface, for me) mandatory and that a missing Arrow in Debian prevented me from updating the packaging to the latest upstream version, leaving it stuck at some version from May. >> I am not using Arrow myself, but I presume just like me you all know >> some project that should be using it :) Yep :) > Thank you for the prospective! I see Sasha filed an RFP some > time ago [1], so there is definitely interest in Apache Arrow. > I don't know whether there is a packaging effort at the moment, > but if there is, I haven't found it by doing a research on > Salsa. I have prepared a first show of packaging for Arrow that works well for my case [2]. It replicates almost all binary packages built by upstream's own packaging pipeline (for version 4, at least, that's when I stopped looking at it) and I only had to tweak the build parameters a little bit. FYI they are doing their own Debian debs via JFrog and their own Ruby-based packaging tooling [3, 4]. The rest of the story is that I considered my package ready to upload, but a project partner familiar with using Arrow let me know that their development cycle is quite fast, with several breaking new major versions recently, support for new languages being added all the time (Rust, ...) and with adopting other code as well (Parquet, ...). This made me a bit uneasy as I only needed it as a dependency and I did not really bite off more than I could chew. I contacted upstream to ask for support [5] but it looked to me that they would rather not like to help out with Debian packaging directly. They would probably consider specific patches form us but in general stick to their own packaging tools. See the linked thread for more information. I must admit I did not really have the time so far to follow up with explaining how things are done in Debian and that they and us are probably using too different approaches for packaging. Long story short: I have finished packaging for Arrow 4 which looks good (someone might want to double-check the long d/copyright though) but I am not sure I want to track and maintain it _on my own_ in the long run. If someone from the Debian Med team wants to collaborate on this, be it packaging or upstream interaction, I would be willing to reconsider =) Cheers Sascha [1] https://tracker.debian.org/pkg/vast [2] https://salsa.debian.org/satta/arrow [3] https://apache.jfrog.io/ui/native/arrow/debian [4] https://github.com/apache/arrow/tree/master/dev/tasks/linux-packages [5] https://lists.apache.org/thread.html/rcd366cf9bde72d69e942ea31f3a0f1066727f6c7e8915bfdda6f009a%40%3Cdev.arrow.apache.org%3E
Re: Autopkgtest fails for new upstream version of gubbins
Hi, > I injected latest version of Gubbins into Git. Some new Build-Depends were > needed > to run build time tests. I have no time to check the autopkgtest failures > right > now but it would be great if somebody could have a look. Looking at the release notes [0] and the Dockerfile [1], it looks like Gubbins now wants or at least tests raxml-ng (which does not look packaged [2]) and rapidnj (also not in Debian). Since the names of the failing tests mention these, I would suspect that this might be related to that. Sorry for the quick glance but I haven't been following Gubbins development for years :/ These could be a sprint candidate...? Cheers Sascha [0] https://github.com/sanger-pathogens/gubbins/releases/tag/v3.0.0 [1] https://salsa.debian.org/med-team/gubbins/-/blob/master/Dockerfile#L66 [2] https://salsa.debian.org/med-team/raxml-ng/-/blob/master/debian/changelog
Re: Debian Med Sprint from February 18. to 21.
Hi all, [..] > I'd be happy if many members of the team would be able to take vaccation > from day job and free their time to > > * Lurk online face to face on our Jitsi channel[3] > * Lurk on IRC #debian-med > * May be other direct communication channels > * Be available for some ad hoc meetings Sure, even though I may not be too up-to-date w.r.t. the rest of the team's COVID efforts, I will keep this timeframe in mind to be available and hopefully be able to dedicate some time to address time consuming tasks on (my and other) Debian Med relevant packages. Thanks for the reminder :) Cheers Sascha
Re: Kmc might cause iva autopkgtest fail on arm64
Hi, > run_kmc.sh: line 2: 5046 Segmentation fault kmc -fa -m4 -k95 -sf1 -ci25 > -cs100 -cx100 > /tmp/tmp.GkQzyocbDU/test/iva.out/tmp.common_kmers.8oo5afnl/reads.fa kmc_out > $PWD > /dev/null [...] > There are more Segmentation faults in connection with kmc later. > I think a Segmentation fault is just not good. Is anybody up for > this issue? This is on ARM, and tests on amd64 are OK... could this just be a RAM issue on the test box? I very vaguely remember that kmc needs quite a bit of RAM, which I'm not sure all of the ARM CI boxes have? Just guessing. Cheers Sascha
Re: [RFS] codonw
Hi Nilesh, >> I have added autopkgtests for codonw. It builds in a clean chroot with >> passing tests. >> My changes are pushed here[1]. >> Needs review and sponsorship. > > Cool, thanks! I will take a look. Uploaded, thanks! I have only added an additional d/changelog entry about the autopkgtest. Cheers Sascha signature.asc Description: Message signed with OpenPGP
Re: [RFS] codonw
Hi Nilesh, > I have added autopkgtests for codonw. It builds in a clean chroot with > passing tests. > My changes are pushed here[1]. > Needs review and sponsorship. Cool, thanks! I will take a look. Best regards Sascha signature.asc Description: Message signed with OpenPGP
Re: @DebianMed twitter account?
Hi again, some news regarding this: > Does anyone know who owns and/or set up the @DebianMed twitter > account? At the moment it only tweets blog entry links, but it might > be useful to use it for other purposes as well.>> Trying to do account > recovery only revealed that the associated email address is: > > vg@m.*** After sifting through the public mailing list archives, it looks like that according to [1] this was done by Vanessa Gutierrez in 2011. If you want I can contact her (using the above and other email addresses) and try to find out more. Cheers Sascha [1] https://lists.debian.org/debian-med/2011/04/msg00089.html
@DebianMed twitter account?
Hi all, Does anyone know who owns and/or set up the @DebianMed twitter account [1]? At the moment it only tweets blog entry links, but it might be useful to use it for other purposes as well. Trying to do account recovery only revealed that the associated email address is: vg@m.*** but I can not think of anybody in the team who fits this address scheme. Any ideas? Cheers Sascha [1] https://twitter.com/debianmed signature.asc Description: Message signed with OpenPGP
Re: 2020 sprint travel cost reimbursement
Hi Steffen, > Hi Sascha, please reserve some ... 300? ... Euros for me - Travel plus > three nights. Okay, thanks for the information :) Anyone else? Otherwise I'd ask for approval of 600 EUR in total later today. Cheers Sascha > On 02.02.20 22:35, Sascha Steinbiss wrote: >> Hi all, >> >> This is just another kind reminder. Since the date is rapidly >> approaching I would like to finalise the pre-approval. >> So please let me know how much you would like to claim for this sprint >> in terms of travel expenses (primarily @DDs). >> >> Thanks >> Sascha >> >>> On 24. Jan 2020, at 17:49, Sascha Steinbiss >>> wrote: >>> >>> Hi all, >>> >>> coming back to my earlier question about travel costs reimbursements >>> from Jan 08: >>> >>>> If you are coming and looking to be reimbursed for your travels, it >>>> would be very helpful to get some cost estimates from your side so I >>>> know what to ask for -- thanks! >>> Just a reminder that if you want to request reimbursement via Debian for >>> hotel costs, flights, or similar expenses, please let me know ASAP how >>> much that will be so I can have the total amount pre-approved by the >>> DPL. Thanks! >>> >>> Olivier, I have already noted your request -- anyone else? >>> >>> Thanks! >>> Sascha >>> >>>> On 23.11.19 22:56, Sascha Steinbiss wrote: >>>>> Dear team, >>>>> >>>>> after some quick discussions with Andreas and Michael, I would be >>>>> happy to propose Berlin as the next location for the annual sprint. >>>>> I have checked with my employer [1] and they agreed to let us use >>>>> their space for the weekend. The location would be the same as in >>>>> the 2019 Berlin BSP [2]. It is a modern office building in >>>>> Berlin-Schöneberg, within walking distance to various restaurants >>>>> and pubs. It is also close to two major S-Bahn (city train) >>>>> stations, allowing one to get anywhere in Berlin relatively >>>>> quickly. Hotels and hostels are available a couple of S-Bahn >>>>> stations away, for example near Anhalter Bahnhof or Potsdamer Platz >>>>> [3]. >>>>> >>>>> Possible dates I have been discussed with our office management >>>>> team would be in mid-February: >>>>> >>>>> - 8./9., or >>>>> - 15./16. >>>>> >>>>> The space will be available from Saturday morning until Sunday >>>>> evening. We will have access to one large (~15 people) and one >>>>> small (~ 5 people) meeting room, so working in separate groups from >>>>> time to time is definitely possible. There will be fast wifi and >>>>> power for laptops, as well as large displays on the walls of each >>>>> room. There is also an open space with a coffee machine. >>>>> >>>>> I have opened a poll to find out which weekend would suit you >>>>> better. If you have other suggestions or preferences, please let me >>>>> know — this was just a first shot and other options can be >>>>> discussed. However, the weekends directly before and after the >>>>> dates above are unlikely to work because on these I will not be >>>>> able to be present for the event, which would be a prerequisite. >>>>> >>>>> Here is the link to the poll: >>>>> >>>>> https://dudle.inf.tu-dresden.de/debianmed2020/ >>>>> >>>>> If we agree to have the sprint in Berlin and also agreed on a date, >>>>> I would be happy to set up a wiki page. >>>>> >>>>> Best regards >>>>> Sascha >>>>> >>>>> >>>>> [1] https://www.dcso.de >>>>> [2] https://wiki.debian.org/BSP/2019/02/de/Berlin >>>>> [3] >>>>> https://www.google.com/maps/search/hotels+near+euref-campus/@52.4884989,13.3415758,14z/data=!3m1!4b1!4m5!2m4!5m3!5m2!4m1!1i2 >>>>> >>>>>
Re: 2020 sprint travel cost reimbursement (was: Debian Med Sprint 2020 in Berlin?)
Hi all, This is just another kind reminder. Since the date is rapidly approaching I would like to finalise the pre-approval. So please let me know how much you would like to claim for this sprint in terms of travel expenses (primarily @DDs). Thanks Sascha > On 24. Jan 2020, at 17:49, Sascha Steinbiss wrote: > > Hi all, > > coming back to my earlier question about travel costs reimbursements > from Jan 08: > >> If you are coming and looking to be reimbursed for your travels, it >> would be very helpful to get some cost estimates from your side so I >> know what to ask for -- thanks! > > Just a reminder that if you want to request reimbursement via Debian for > hotel costs, flights, or similar expenses, please let me know ASAP how > much that will be so I can have the total amount pre-approved by the > DPL. Thanks! > > Olivier, I have already noted your request -- anyone else? > > Thanks! > Sascha > >> On 23.11.19 22:56, Sascha Steinbiss wrote: >>> Dear team, >>> >>> after some quick discussions with Andreas and Michael, I would be happy to >>> propose Berlin as the next location for the annual sprint. I have checked >>> with my employer [1] and they agreed to let us use their space for the >>> weekend. The location would be the same as in the 2019 Berlin BSP [2]. It >>> is a modern office building in Berlin-Schöneberg, within walking distance >>> to various restaurants and pubs. It is also close to two major S-Bahn (city >>> train) stations, allowing one to get anywhere in Berlin relatively quickly. >>> Hotels and hostels are available a couple of S-Bahn stations away, for >>> example near Anhalter Bahnhof or Potsdamer Platz [3]. >>> >>> Possible dates I have been discussed with our office management team would >>> be in mid-February: >>> >>> - 8./9., or >>> - 15./16. >>> >>> The space will be available from Saturday morning until Sunday evening. We >>> will have access to one large (~15 people) and one small (~ 5 people) >>> meeting room, so working in separate groups from time to time is definitely >>> possible. There will be fast wifi and power for laptops, as well as large >>> displays on the walls of each room. There is also an open space with a >>> coffee machine. >>> >>> I have opened a poll to find out which weekend would suit you better. If >>> you have other suggestions or preferences, please let me know — this was >>> just a first shot and other options can be discussed. However, the weekends >>> directly before and after the dates above are unlikely to work because on >>> these I will not be able to be present for the event, which would be a >>> prerequisite. >>> >>> Here is the link to the poll: >>> >>> https://dudle.inf.tu-dresden.de/debianmed2020/ >>> >>> If we agree to have the sprint in Berlin and also agreed on a date, I would >>> be happy to set up a wiki page. >>> >>> Best regards >>> Sascha >>> >>> >>> [1] https://www.dcso.de >>> [2] https://wiki.debian.org/BSP/2019/02/de/Berlin >>> [3] >>> https://www.google.com/maps/search/hotels+near+euref-campus/@52.4884989,13.3415758,14z/data=!3m1!4b1!4m5!2m4!5m3!5m2!4m1!1i2 >>> >> >
2020 sprint travel cost reimbursement (was: Debian Med Sprint 2020 in Berlin?)
Hi all, coming back to my earlier question about travel costs reimbursements from Jan 08: > If you are coming and looking to be reimbursed for your travels, it > would be very helpful to get some cost estimates from your side so I > know what to ask for -- thanks! Just a reminder that if you want to request reimbursement via Debian for hotel costs, flights, or similar expenses, please let me know ASAP how much that will be so I can have the total amount pre-approved by the DPL. Thanks! Olivier, I have already noted your request -- anyone else? Thanks! Sascha > On 23.11.19 22:56, Sascha Steinbiss wrote: >> Dear team, >> >> after some quick discussions with Andreas and Michael, I would be happy to >> propose Berlin as the next location for the annual sprint. I have checked >> with my employer [1] and they agreed to let us use their space for the >> weekend. The location would be the same as in the 2019 Berlin BSP [2]. It is >> a modern office building in Berlin-Schöneberg, within walking distance to >> various restaurants and pubs. It is also close to two major S-Bahn (city >> train) stations, allowing one to get anywhere in Berlin relatively quickly. >> Hotels and hostels are available a couple of S-Bahn stations away, for >> example near Anhalter Bahnhof or Potsdamer Platz [3]. >> >> Possible dates I have been discussed with our office management team would >> be in mid-February: >> >> - 8./9., or >> - 15./16. >> >> The space will be available from Saturday morning until Sunday evening. We >> will have access to one large (~15 people) and one small (~ 5 people) >> meeting room, so working in separate groups from time to time is definitely >> possible. There will be fast wifi and power for laptops, as well as large >> displays on the walls of each room. There is also an open space with a >> coffee machine. >> >> I have opened a poll to find out which weekend would suit you better. If you >> have other suggestions or preferences, please let me know — this was just a >> first shot and other options can be discussed. However, the weekends >> directly before and after the dates above are unlikely to work because on >> these I will not be able to be present for the event, which would be a >> prerequisite. >> >> Here is the link to the poll: >> >> https://dudle.inf.tu-dresden.de/debianmed2020/ >> >> If we agree to have the sprint in Berlin and also agreed on a date, I would >> be happy to set up a wiki page. >> >> Best regards >> Sascha >> >> >> [1] https://www.dcso.de >> [2] https://wiki.debian.org/BSP/2019/02/de/Berlin >> [3] >> https://www.google.com/maps/search/hotels+near+euref-campus/@52.4884989,13.3415758,14z/data=!3m1!4b1!4m5!2m4!5m3!5m2!4m1!1i2 >> > signature.asc Description: OpenPGP digital signature
Debian Med Sprint, 8/9 Feb 2020, Berlin, Germany
Dear Debianistas, I am happy to announce that the next Debian Med sprint will take place in Berlin. The location would be the same as in the 2019 Berlin BSP. - when: Feb 8/9, 2020 - where: DCSO GmbH, EUREF-Campus 22, 10829 Berlin, Germany The venue is a modern office building in Berlin-Schöneberg, within walking distance to various restaurants and pubs. It is also close to two major S-Bahn (city train) stations, allowing one to get anywhere in Berlin relatively quickly. Hotels and hostels are available a couple of S-Bahn stations away, for example near Anhalter Bahnhof or Potsdamer Platz. The wiki page for the sprint [1] contains more information, accommodation suggestions and a list to sign up for the event. We have space for 10-15 people and only 5 confirmed sign-ups so far. I will follow up with more details on participation and an estimate for travel budget pre-approval closer to the date. If you have questions, feel free to get in touch. See you there! Sascha [1] https://wiki.debian.org/Sprints/2020/Debian%20Med%20Sprint%20Feb%202020%2C%20Berlin signature.asc Description: OpenPGP digital signature
Re: Debian Med Sprint 2020 in Berlin?
Dear all, since this seems to be a fixed date now, I am going to announce the sprint publicly on the debian-sprint list and, in that process, also ask for potential reimbursement. If you are coming and looking to be reimbursed for your travels, it would be very helpful to get some cost estimates from your side so I know what to ask for -- thanks! I have also added some accommodation options to the wiki page [1] Cheers Sascha P.S. Sadly there haven't been that many signups _yet_, maybe someone knows some channel to broaden the audience? ;) [1] https://wiki.debian.org/Sprints/2020/Debian%20Med%20Sprint%20Feb%202020%2C%20Berlin On 23.11.19 22:56, Sascha Steinbiss wrote: > Dear team, > > after some quick discussions with Andreas and Michael, I would be happy to > propose Berlin as the next location for the annual sprint. I have checked > with my employer [1] and they agreed to let us use their space for the > weekend. The location would be the same as in the 2019 Berlin BSP [2]. It is > a modern office building in Berlin-Schöneberg, within walking distance to > various restaurants and pubs. It is also close to two major S-Bahn (city > train) stations, allowing one to get anywhere in Berlin relatively quickly. > Hotels and hostels are available a couple of S-Bahn stations away, for > example near Anhalter Bahnhof or Potsdamer Platz [3]. > > Possible dates I have been discussed with our office management team would be > in mid-February: > > - 8./9., or > - 15./16. > > The space will be available from Saturday morning until Sunday evening. We > will have access to one large (~15 people) and one small (~ 5 people) meeting > room, so working in separate groups from time to time is definitely possible. > There will be fast wifi and power for laptops, as well as large displays on > the walls of each room. There is also an open space with a coffee machine. > > I have opened a poll to find out which weekend would suit you better. If you > have other suggestions or preferences, please let me know — this was just a > first shot and other options can be discussed. However, the weekends directly > before and after the dates above are unlikely to work because on these I will > not be able to be present for the event, which would be a prerequisite. > > Here is the link to the poll: > > https://dudle.inf.tu-dresden.de/debianmed2020/ > > If we agree to have the sprint in Berlin and also agreed on a date, I would > be happy to set up a wiki page. > > Best regards > Sascha > > > [1] https://www.dcso.de > [2] https://wiki.debian.org/BSP/2019/02/de/Berlin > [3] > https://www.google.com/maps/search/hotels+near+euref-campus/@52.4884989,13.3415758,14z/data=!3m1!4b1!4m5!2m4!5m3!5m2!4m1!1i2 > signature.asc Description: OpenPGP digital signature
Re: debianmed sprint hotel
Hi all, > has anyone made an hotel choice for the sprint so that we can start > reservertions to be together if possible? FYI, here are some recommendations (from our wiki): - Within walking distance: https://www.google.com/maps/place/Hotel+Sch%C3%B6neberg/@52.4838617,13.3538017,17.5z/data=!4m8!3m7!1s0x0:0x7cbdc6094eb22597!5m2!4m1!1i2!8m2!3d52.4849925!4d13.3545083 - Few S-Bahn stations away: https://www.google.com/maps/place/Hotel+Novotel+Suites+Berlin+City+Potsdamer+Platz/@52.5048022,13.3817308,16.54z/data=!4m8!3m7!1s0x0:0x1c4720a47f155c71!5m2!4m1!1i2!8m2!3d52.50457!4d13.38312 and others in the area - On campus: https://euref.de/en/euref-campus_en/campus-life/#overnight (only few spaces available, might go quickly) Cheers Sascha
Bug#947954: ITP: vmatch -- large scale sequence analysis software
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: vmatch Version : 2.3.0 Upstream Author : Stefan Kurtz * URL : http://vmatch.de * License : ISC Programming Lang: C Description : large scale sequence analysis software Vmatch is an index-based, versatile software tool for efficiently solving large scale sequence matching tasks. Vmatch subsumes the software tool REPuter, but is much more general, with a very flexible user interface, and improved space and time requirements. It has recently been freed after being closed-source for a long time. I am packaging this under the Debian Med umbrella, partly as a dependency of the GenomeThreader gene prediction tool.
Re: [Debian-med-packaging] Bug#938565: Autopkgtest failing - any takers for Segmentation fault in bowtie (Was: Bug#938565: sspace: Python2 removal in sid/bullseye)
Hi, I've had another look at: > autopkgtest [15:40:05]: test example-tests: [--- > + which python > /usr/bin/python > + python > + which bowtie-build > /usr/bin/bowtie-build > + bowtie-build --help > Segmentation fault > autopkgtest [15:40:06]: test example-tests: ---] > autopkgtest [15:40:06]: test example-tests: - - - - - - - - - - results - - > - - - - - - - - > example-testsFAIL non-zero exit status 139 > autopkgtest [15:40:06]: summary > example-testsFAIL non-zero exit status 139 > autopkgtest [15:40:06]: Binaries: resetting testbed apt configuration > > > I'm worried about > > > $ bowtie-build --help > Segmentation fault > > > which does NOT happen on a local machine where the test suite > runs successfully. Anybody volunteering to check that issue? And I can confirm that this does no longer happen on my sid autopkgtest setup, see attached log. I will do a new upload with debugging code removed soon. Cheers Sascha $ sudo autopkgtest ../sspace_2.1.1+dfsg-5_amd64.changes -- lxc autopkgtest-sid autopkgtest [14:35:13]: version 5.10 autopkgtest [14:35:13]: host XX; command line: /usr/bin/autopkgtest ../sspace_2.1.1+dfsg-5_amd64.changes -- lxc autopkgtest-sid autopkgtest [14:35:19]: testbed dpkg architecture: amd64 autopkgtest [14:35:19]: testbed running kernel: Linux 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) autopkgtest [14:35:19]: source ../sspace_2.1.1+dfsg-5.dsc dpkg-source: warning: extracting unsigned source package (/tmp/autopkgtest-lxc.37vrddgj/downtmp/sspace_2.1.1+dfsg-5.dsc) dpkg-source: info: extracting sspace in src dpkg-source: info: unpacking sspace_2.1.1+dfsg.orig.tar.xz dpkg-source: info: unpacking sspace_2.1.1+dfsg-5.debian.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying shebangs.patch dpkg-source: info: applying 2to3.patch dpkg-source: info: applying debug.patch autopkgtest [14:35:20]: testing package sspace version 2.1.1+dfsg-5 autopkgtest [14:35:20]: build not needed autopkgtest [14:35:20]: test example-tests: preparing testbed Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libapt-inst2.0 The following NEW packages will be installed: apt-utils libapt-inst2.0 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 632 kB of archives. After this operation, 1,683 kB of additional disk space will be used. Get:1 http://deb.debian.org/debian sid/main amd64 libapt-inst2.0 amd64 1.8.4 [204 kB] Get:2 http://deb.debian.org/debian sid/main amd64 apt-utils amd64 1.8.4 [428 kB] Fetched 632 kB in 0s (2,141 kB/s) debconf: delaying package configuration, since apt-utils is not installed Selecting previously unselected package libapt-inst2.0:amd64. (Reading database ... 12394 files and directories currently installed.) Preparing to unpack .../libapt-inst2.0_1.8.4_amd64.deb ... Unpacking libapt-inst2.0:amd64 (1.8.4) ... Selecting previously unselected package apt-utils. Preparing to unpack .../apt-utils_1.8.4_amd64.deb ... Unpacking apt-utils (1.8.4) ... Setting up libapt-inst2.0:amd64 (1.8.4) ... Setting up apt-utils (1.8.4) ... Processing triggers for libc-bin (2.29-6) ... Get:1 file:/tmp/autopkgtest-lxc.37vrddgj/downtmp/binaries InRelease Ign:1 file:/tmp/autopkgtest-lxc.37vrddgj/downtmp/binaries InRelease Get:2 file:/tmp/autopkgtest-lxc.37vrddgj/downtmp/binaries Release [816 B] Get:2 file:/tmp/autopkgtest-lxc.37vrddgj/downtmp/binaries Release [816 B] Get:3 file:/tmp/autopkgtest-lxc.37vrddgj/downtmp/binaries Release.gpg Ign:3 file:/tmp/autopkgtest-lxc.37vrddgj/downtmp/binaries Release.gpg Get:4 file:/tmp/autopkgtest-lxc.37vrddgj/downtmp/binaries Packages [1,174 B] Reading package lists... Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies...Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done Done Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done The following additional packages will be installed: bowtie libmpdec2 libpython3-stdlib libpython3.7-stdlib libtbb2 mime-support python3 python3.7 sspace Suggested packages: bowtie-examples python3-doc python3-tk python3-venv python3.7-venv python3.7-doc Recommended packages: file The following NEW packages will be installed: bowtie libmpdec2 libpython3-stdlib libpython3.7-stdlib libtbb2 mime-support python3 python3.7 sspace 0 upgraded, 9 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 4,283 kB/5,521 kB of archives. After this operation, 22.8 MB of additional disk space will be used. Get:1 file:/tmp/autopkgtest-lxc.37vrddgj/downtmp/binaries sspace 2.1.1+dfsg-5 [1,238 kB] Get:2 http://deb.debian.org/debian sid/main
Re: Debian Med Sprint 2020 in Berlin?
Hi all, > If we agree to have the sprint in Berlin and also agreed on a date, I would > be happy to set up a wiki page. Wiki page is open! -> https://wiki.debian.org/Sprints/2020/Debian%20Med%20Sprint%20Feb%202020%2C%20Berlin Cheers Sascha signature.asc Description: OpenPGP digital signature
Debian Med Sprint 2020 in Berlin?
Dear team, after some quick discussions with Andreas and Michael, I would be happy to propose Berlin as the next location for the annual sprint. I have checked with my employer [1] and they agreed to let us use their space for the weekend. The location would be the same as in the 2019 Berlin BSP [2]. It is a modern office building in Berlin-Schöneberg, within walking distance to various restaurants and pubs. It is also close to two major S-Bahn (city train) stations, allowing one to get anywhere in Berlin relatively quickly. Hotels and hostels are available a couple of S-Bahn stations away, for example near Anhalter Bahnhof or Potsdamer Platz [3]. Possible dates I have been discussed with our office management team would be in mid-February: - 8./9., or - 15./16. The space will be available from Saturday morning until Sunday evening. We will have access to one large (~15 people) and one small (~ 5 people) meeting room, so working in separate groups from time to time is definitely possible. There will be fast wifi and power for laptops, as well as large displays on the walls of each room. There is also an open space with a coffee machine. I have opened a poll to find out which weekend would suit you better. If you have other suggestions or preferences, please let me know — this was just a first shot and other options can be discussed. However, the weekends directly before and after the dates above are unlikely to work because on these I will not be able to be present for the event, which would be a prerequisite. Here is the link to the poll: https://dudle.inf.tu-dresden.de/debianmed2020/ If we agree to have the sprint in Berlin and also agreed on a date, I would be happy to set up a wiki page. Best regards Sascha [1] https://www.dcso.de [2] https://wiki.debian.org/BSP/2019/02/de/Berlin [3] https://www.google.com/maps/search/hotels+near+euref-campus/@52.4884989,13.3415758,14z/data=!3m1!4b1!4m5!2m4!5m3!5m2!4m1!1i2
Re: Bug#944299: ITP: phylonium -- Fast and Accurate Estimation of Evolutionary Distances
Hi Fabian, you should be able to push now. Cheers Sascha On 11/8/19 10:41 AM, Fabian Klötzl wrote: > Hi all, > > I started packaging phylonium locally. However, I can't push to salsa > because of some "default branch" issue. As I am only a "Developer" for > that repo, I can't change it my self. Could someone fix that for me or > make me a maintainer so that I can do it? > > Best > Fabian > > https://salsa.debian.org/med-team/phylonium > > > On 07.11.19 13:34, Fabian Kloetzl wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Fabian Klötzl >> >> * Package name : phylonium >> Version : 1.1 >> Upstream Author : Fabian Klötzl >> * URL : https://github.com/evolbioinf/phylonium >> * License : GPL >> Programming Lang: C++ >> Description : Fast and Accurate Estimation of Evolutionary >> Distances >> >> This is the phylonium program for estimating the evolutionary distances >> between closely related genomes. It is much faster than alignment based >> approaches for phylogeny reconstruction and usually more accurate than >> competing alignment-free methods. >> >> This package will be co-maintained in the Debian Med Team. >
Re: Bug#944299: ITP: phylonium -- Fast and Accurate Estimation of Evolutionary Distances
Sorry, I meant: I made you a maintainer so you can set up the repo by yourself. Cheers S. On 11/8/19 11:12 AM, Sascha Steinbiss wrote: > Hi Fabian, > > you should be able to push now. > > Cheers > Sascha > > On 11/8/19 10:41 AM, Fabian Klötzl wrote: >> Hi all, >> >> I started packaging phylonium locally. However, I can't push to salsa >> because of some "default branch" issue. As I am only a "Developer" for >> that repo, I can't change it my self. Could someone fix that for me or >> make me a maintainer so that I can do it? >> >> Best >> Fabian >> >> https://salsa.debian.org/med-team/phylonium >> >> >> On 07.11.19 13:34, Fabian Kloetzl wrote: >>> Package: wnpp >>> Severity: wishlist >>> Owner: Fabian Klötzl >>> >>> * Package name : phylonium >>> Version : 1.1 >>> Upstream Author : Fabian Klötzl >>> * URL : https://github.com/evolbioinf/phylonium >>> * License : GPL >>> Programming Lang: C++ >>> Description : Fast and Accurate Estimation of Evolutionary >>> Distances >>> >>> This is the phylonium program for estimating the evolutionary distances >>> between closely related genomes. It is much faster than alignment based >>> approaches for phylogeny reconstruction and usually more accurate than >>> competing alignment-free methods. >>> >>> This package will be co-maintained in the Debian Med Team. >>
Re: Source uploads not processing?
Hi Mattia, [...] >> I've gotten no error messages about my GPG signatures or emails about lack >> of authorization. > > That's the clear sign of a gpg problem. Indeed from the queued log: > Jul 23 17:13:34 processing /prokka_1.13.7+dfsg-1_source.changes > Jul 23 17:13:34 GnuPG signature check failed on > prokka_1.13.7+dfsg-1_source.changes > Jul 23 17:13:34 (Exit status 2) > Jul 23 17:13:34 /prokka_1.13.7+dfsg-1_source.changes has bad PGP/GnuPG > signature! > Jul 23 17:13:34 Removing /prokka_1.13.7+dfsg-1_source.changes, but > keeping its associated files for now. I am curious... are these logs available anywhere (for a non-ftpmaster ;)? They would be quite helpful to track the progress of an upload and elucidate situations in which a package appears 'stuck' to an uploader. Cheers Sascha signature.asc Description: OpenPGP digital signature
Re: Pizzly keeps complaining about missing pthreads library - any idea anyone?
Hi Steffen,
> Please someone help me out. Pizzly is lintian clean when built
> "regularly" on my desktop but fails with
>
> /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_8a4be.dir/link.txt
> --verbose=1
> /usr/bin/c++ -g -O2 -fdebug-prefix-map=/build/pizzly-0.37.3=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wall
> -pedantic -Wdate-time -D_FORTIFY_SOURCE=2
> -DCHECK_FUNCTION_EXISTS=pthread_create -Wl,-z,relro -Wl,-z,now
> -Wl,--as-needed -rdynamic
> CMakeFiles/cmTC_8a4be.dir/CheckFunctionExists.cxx.o -o cmTC_8a4be
> -lpthreads
> /usr/bin/ld: cannot find -lpthreads
>
> in pbuilder.
Interesting. I get a different problem when building in a recent
unstable chroot (there's a long list of unrelated debug stuff after the
original root cause message):
$ gbp buildpackage -uc -us --git-pbuilder --git-pristine-tar
--git-ignore-new
gbp:info: Building with (cowbuilder) for unstable
Building with cowbuilder for distribution unstable
[...]
dh build
dh_update_autotools_config
dh_autoreconf
dh_auto_configure
install -d obj-x86_64-linux-gnu
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON
-DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix Makefiles"
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu ..
-- The CXX compiler identification is GNU 8.3.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR)
-- Looking for C++ include pthread.h
-- Looking for C++ include pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
CMake Error: The following variables are used in this project, but they
are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the
CMake files:
ZLIB_LIBRARY
linked by target "pizzly" in directory /build/pizzly-0.37.3
After simply adding a build-dep to zlib1g-dev, everything built fine for
me. See the attached build log.
Cheers
Sascha
gbp:info: Building with (cowbuilder) for unstable
Building with cowbuilder for distribution unstable
[0mI: using cowbuilder as pbuilder[0m
dpkg-checkbuilddeps: error: Unmet build dependencies: libseqan2-dev cmake
[1;33mW: Unmet build-dependency in source[0m
dh clean
debian/rules override_dh_auto_clean
make[1]: Entering directory '/home/satta/pkg/deb-med/pizzly'
dh_auto_clean
rm -f debian/pizzly.1
make[1]: Leaving directory '/home/satta/pkg/deb-med/pizzly'
dh_clean
rm -f debian/debhelper-build-stamp
rm -rf debian/.debhelper/
rm -f -- debian/pizzly.substvars debian/files
rm -fr -- debian/pizzly/ debian/tmp/
find . \( \( \
\( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o -path
.\*/.hg -o -path .\*/CVS -o -path .\*/.pc -o -path .\*/_darcs \) -prune -o
-type f -a \
\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
-o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
-o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
-o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
\) -exec rm -f {} + \) -o \
\( -type d -a -name autom4te.cache -prune -exec rm -rf {} + \)
\)
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building pizzly using existing ./pizzly_0.37.3.orig.tar.xz
dpkg-source: info: building pizzly in pizzly_0.37.3-1.debian.tar.xz
dpkg-source: info: building pizzly in pizzly_0.37.3-1.dsc
[0mI: Generated dsc will be overwritten by build result; not generating
changes file[0m
[0mI: Copying COW directory[0m
[0mI: forking: rm -rf /var/cache/pbuilder/build/cow.22563[0m
[0mI: forking: cp -al /var/cache/pbuilder/base-unstable.cow
/var/cache/pbuilder/build/cow.22563[0m
[0mI: removed stale ilistfile /var/cache/pbuilder/build/cow.22563/.ilist[0m
[0mI: forking: chroot /var/cache/pbuilder/build/cow.22563
cowdancer-ilistcreate /.ilist 'find . -xdev -path ./home -prune -o \( \( -type
l -o -type f \) -a -links +1 -print0 \) | xargs -0 stat --format '%d %i ''[0m
[0mI: Invoking pbuilder[0m
[0mI: forking: pbuilder build --debbuildopts --debbuildopts ' '-uc' '-us''
--buildplace /var/cache/pbuilder/build/cow.22563 --buildresult
/home/satta/pkg/deb-med --mirror http://ftp.us.debian.org/debian/
--distribution unstable --extrapackages 'debhelper fakeroot apt-utils'
--no-tar
Re: Wham aligner package name - just wham? wham-align?
Hi Steffen, > I have no exact idea why alignment tools are all given such short names. > We have http://last.cbrc.jp/ as last-align with is. Should I do the same > for wham and name the package wham-align? That's what I did for lambda [1] and lambda2 [2] as well. Keeps the namespace clean and users can still search for the name and pick the correct one. > I am not aware of any particular naming conflict. Not yet... ;) Cheers Sascha [1] https://tracker.debian.org/pkg/lambda-align [2] https://tracker.debian.org/pkg/lambda-align2
Re: Sprint preparation
Hi Andrius, hi all, first of all thanks for your quick reply! > To reach the apartments [1] one has to take the bus 3G at the airport > terminal (the airport is very small, bus station is just outside). A > paper ticket has to be bought from the driver, it should cost €1. > It's better to pay in coins or via €5 bill, as cards or larger bills > are not accepted. The stop for the apartments is "Mikalojaus > Konstantino Čiurlionio" (usually abbreviated to "M. K. Čiurlionio"), > the 5th stop from the airport. The apartments are on 1 M. K. > Čiurlionio OK, sounds good. > Alternatively, one can grab a taxi. We have Uber, Taxify is also fine. > Most drivers speak basic English (am I right, Michael?). Michael offers > everyone €6 discount for Taxify [2]. I wouldn't mind sharing a taxi/Uber with Andreas (and anyone else arriving at the airport at that time) either. Good to know that we have some options ;) >> Sascha and I will arrive 18:15 at the airport. What's the best >> strategy to meet others (at the airport / in the venue / in the >> appartment house / restaurant for dinner)? > > It would be great to go out for the dinner on Friday evening. I suggest > us meet at the apartments at 20:30 and go somewhere nearby. Michael > recommended "FoodHall", which is open till 23:00, I suggest us go there. So be it. Since we now have EU-wide roaming at least I will also be able to read and write email on the road, so just drop me a line if we happen to miss each other. Looking forward to meeting all of you! Cheers Sascha signature.asc Description: OpenPGP digital signature
Re: Should lambda-align v2 replace v1 or be its own Debian package?
Hi Michael,
[...[
> Other than the lack of full test suite that we had with v1.0.x [1], I
> think this is ready for sponsorship for the NEW queue.
Hmm, but the rest of the tests (the ones currently run in your package
on salsa) are supposed to succeed? They fail for me:
[...]
debian/rules override_dh_auto_test
make[1]: Entering directory '/build/lambda-align2-2.0.0'
for md5 in debian/*.md5sums; do gzip --keep ${md5}; done
cp --backup debian/*md5sums.gz tests/
cd build/tests && ctest . -j8 -I 1,10
Test project /build/lambda-align2-2.0.0/build/tests
Start 1: test_mkindex_blastn_sa
Start 2: test_mkindex_blastn_fm
Start 3: test_mkindex_blastp_sa
Start 4: test_mkindex_blastp_fm
Start 5: test_mkindex_blastx_sa
Start 6: test_mkindex_blastx_fm
Start 7: test_mkindex_tblastn_sa
Start 8: test_mkindex_tblastn_fm
1/10 Test #4: test_mkindex_blastp_fm ...***Failed0.48 sec
Start 9: test_mkindex_tblastx_sa
2/10 Test #3: test_mkindex_blastp_sa ...***Failed0.49 sec
Start 10: test_mkindex_tblastx_fm
3/10 Test #6: test_mkindex_blastx_fm ...***Failed0.65 sec
4/10 Test #5: test_mkindex_blastx_sa ...***Failed0.72 sec
5/10 Test #1: test_mkindex_blastn_sa ...***Failed1.23 sec
6/10 Test #2: test_mkindex_blastn_fm ...***Failed1.25 sec
7/10 Test #8: test_mkindex_tblastn_fm ..***Failed1.26 sec
8/10 Test #7: test_mkindex_tblastn_sa ..***Failed1.29 sec
9/10 Test #9: test_mkindex_tblastx_sa ..***Failed0.83 sec
10/10 Test #10: test_mkindex_tblastx_fm ..***Failed0.82 sec
0% tests passed, 10 tests failed out of 10
Total Test time (real) = 1.31 sec
The following tests FAILED:
1 - test_mkindex_blastn_sa (Failed)
2 - test_mkindex_blastn_fm (Failed)
3 - test_mkindex_blastp_sa (Failed)
4 - test_mkindex_blastp_fm (Failed)
5 - test_mkindex_blastx_sa (Failed)
6 - test_mkindex_blastx_fm (Failed)
7 - test_mkindex_tblastn_sa (Failed)
8 - test_mkindex_tblastn_fm (Failed)
9 - test_mkindex_tblastx_sa (Failed)
10 - test_mkindex_tblastx_fm (Failed)
Errors while running CTest
[...]
Any ideas?
Cheers
Sascha
Re: Should lambda-align v2 replace v1 or be its own Debian package?
Hi Michael, [...] > Pursuant to that I split off the v2.0.0 packaging: > https://salsa.debian.org/med-team/lambda-align2 [...] > I think this is ready for sponsorship for the NEW queue. Could you please make sure that we have an ITP for that? I'll take a look tomorrow then, try to address Hannes' comments and get it uploaded if everything works out. Cheers Sascha signature.asc Description: OpenPGP digital signature
Re: Should lambda-align v2 replace v1 or be its own Debian package?
Hi, just my 2 cents. I introduced Lambda into Debian some time ago just out of interest but looking at the uploads, Michael has done more work recently... So here are just a few comments from me. [...] >> However, there are no references from other Debian packages to >> lambda-align's binaries, so upgrading to v2 without changing the package >> name won't break any packages, but it will break user scripts. > > From a plain Debian point of view adding a file debian/NEWS.Debian > explaining the issue will show the change in the new version. From a > user perspective it might be interesting to have the old version as > well. I would also advise to create a new package for v2 in order not to silently break users' pipelines when they upgrade their lambda-align package to version 2 (or just do an 'apt upgrade' without checking in detail whether lambda is in the -- potentially tens of packages long -- list of packages to update). > If you volunteer to maintain the old version as lambda-align1 > some users might be happy. I'd rather use 'lambda-align2' and 'lambda-align'... due to the reasons above. For me this is not much different than an ABI change that would require bumping a version number. > PS: In any case I'd stick with the lambda-align package name for the > new version. Otherwise we might need to wait for ftpmaster > acceptance until after freeze and thus the latest version will > not make it into Buster. IMHO I'd rather not have the newest version in buster (which was released just a couple of days ago anyway) than breaking user pipelines. If we're lucky then v2 may even make it through NEW until the freeze affecting new packages which starts in about a month. I can maintain lambda-align 1.x for the time being -- Hannes, do you still provide updates for the old version (I'm thinking of things like ensuring compatibility with gcc updates, C++ standards quirks, etc.)? Cheers Sascha
Re: htslib: FTBFS on i386: 2 tests fail
Hi all, >> test_vcf_api: >> /<>/test/test-vcf-api /tmp/JMIB5wVvT_/test-vcf-api.bcf >> bcf_get_format_float didn't produce the expected output. >> >> .. failed ... >> >> test_vcf_sweep: >> /<>/test/test-vcf-sweep /tmp/JMIB5wVvT_/test-vcf-api.bcf >> >> The outputs differ: >> /<>/test/test-vcf-sweep.out >> /<>/test/test-vcf-sweep.out.new >> .. failed ... I wonder if this is still https://github.com/samtools/htslib/issues/565 -- in this GitHub ticket Graham Inggs mentioned there was some kind of workaround for it? Maybe it is enough to adjust this if it's just a newer gcc version breaking the workarounds? Cheers Sascha signature.asc Description: OpenPGP digital signature
Re: DebianMed Sprint in Vilnius?
Hi all, > This sounds awesome, I'm already looking forward! :-D So am I :) [...] > 2019 Mar 09-11 best, with the additional advantage of 3 free days in > Lithuania (if that is the requirement from the co-working facility) I would probably welcome doing this a bit later this yeas as well, to make a bit of room in between FOSDEM and the DebianMed sprint. So +1 for Mar 9-11 (but also open for other options, depending on what is best for others). Cheers Sascha > On 2018-09-28 11:58, Olivier Sallou wrote: >> On 09/27/2018 10:56 AM, Andreas Tille wrote: >>> Hi Michael, >>> >>> On Tue, Sep 25, 2018 at 06:35:07PM +0300, Michael Crusoe wrote: În mar., 21 aug. 2018 la 15:24, Michael Crusoe a scris: > Howdy y'all, > > My co-working place has confirmed that we can have the common room > and a > conference room for free any weekend plus one week day (and more, > if it > overlaps a with a public holiday like All Saints Day on 2019-03-11) > > http://www.nvoavilys.lt/ > > http://www.nvoavilys.lt/wp-content/uploads/2018/06/susitikimu-kambarys.jpg > > > Travel wise you can fly into the VNO with many low cost flights; > Lithuania's second city, Kaunas, also has an airport (KUN) and is > https://www.rome2rio.com/map/My-hometown/Tauro-g-12-Vilnius-01114-Lituania > > > There is free coffee & espresso (freshly ground) and decent (but not > perfect) WiFi. >>> Thanks for offerring this nice venue. What about a time. Usually we >>> meet >>> end of January / beginning of February. So what about >>> >>> 25.-27. Januar 2019 >>> 08.-10. February 2019 >>> >>> (I intentionally skipped the first weekend of Feburary since I have >>> no time >>> at this date.) >>> >>> Opinions about a date to have some progress in the sprint planing? >> both are ok for me >> >>> >>> Kind regards >>> >>> Andreas. >>> >> >> -- >> Olivier Sallou >> Univ Rennes, Inria, CNRS, IRISA >> Irisa, Campus de Beaulieu >> F-35042 RENNES - FRANCE >> Tel: 02.99.84.71.95 >> >> gpg key id: 4096R/326D8438 (keyring.debian.org) >> Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 >
Re: Who will go to DebConf 18 in Taiwan?
Hi Andreas, > I'll be there. Who else from the team? I won't this year. Maybe next? :) > A Debian Med BoF with life stream is scheduled > > https://debconf18.debconf.org/talks/39-debian-med-bof/ Will watch it -- will check when to set my alarm. Cheers Sascha
CMake help: pthread linking issue
Hi again,
[...]
> I am trying to update salmon [1] to the latest upstream version, but it
> won't build for reasons I can not really track down well. It uses CMake
> as the build system, which I am really not familiar with and to me feels
> a bit like magic incantations to me that mostly work if you use the
> right spells ;)
Someone showed me how I waved my hand in the wrong direction while
spellcasting ;) So I managed to get around that particular issue now and
also updated the embedded copy of RapMap that is sadly still required to
build to the same version currently in unstable.
Unfortunately I am now stuck with another fairly cryptic (to me) build
failure regarding spdlog:
/usr/include/c++/7/bits/shared_ptr.h:703:5: note: template argument
deduction/substitution failed:
/build/salmon-0.8.0+ds1/src/SalmonQuantifyAlignments.cpp:1575:69: error:
no matching function for call to 'create(const char [11],
)'
auto consoleLog = spdlog::create("consoleLog", {consoleSink});
^
In file included from /usr/include/spdlog/spdlog.h:192:0,
from /build/salmon-0.8.0+ds1/include/SalmonOpts.hpp:7,
from /build/salmon-0.8.0+ds1/include/SalmonUtils.hpp:25,
from /build/salmon-0.8.0+ds1/include/Transcript.hpp:10,
from /build/salmon-0.8.0+ds1/include/ClusterForest.hpp:7,
from
/build/salmon-0.8.0+ds1/src/SalmonQuantifyAlignments.cpp:41:
/usr/include/spdlog/details/spdlog_impl.h:179:40: note: candidate:
std::shared_ptr spdlog::create(const string&, const
sink_ptr&)
inline std::shared_ptr spdlog::create(const
std::string& logger_name, const spdlog::sink_ptr& sink)
^~
/usr/include/spdlog/details/spdlog_impl.h:179:40: note: no known
conversion for argument 2 from '' to
'const sink_ptr& {aka const std::shared_ptr&}'
/usr/include/spdlog/details/spdlog_impl.h:186:40: note: candidate:
std::shared_ptr spdlog::create(const string&,
spdlog::sinks_init_list)
inline std::shared_ptr spdlog::create(const
std::string& logger_name, spdlog::sinks_init_list sinks)
^~
/usr/include/spdlog/details/spdlog_impl.h:186:40: note: no known
conversion for argument 2 from '' to
'spdlog::sinks_init_list {aka
std::initializer_list >}'
/usr/include/spdlog/details/spdlog_impl.h:201:40: note: candidate:
template std::shared_ptr spdlog::create(const
string&, const It&, const It&)
inline std::shared_ptr spdlog::create(const
std::string& logger_name, const It& sinks_begin, const It& sinks_end)
^~
Full build log attached. I have also pushed the modified WIP code to
Salsa's salmon master.
Also, to get his far I had to disable building the unit tests as
apparently the rest of the Salmon code wasn't linked against the test
code at build time. Maybe someone could take another look?
I am afraid that my current lack of time for diving into CMake/C++
specific stuff and the fact that I do not use Salmon at all myself are
not the best foundations for doing this package correctly and at a high
standard. Does anyone care a bit more about Salmon and might want to
step in? (probably Kevin or Michael? ;))
Cheers and thanks
Sascha
buildlog.txt.bz2
Description: application/bzip
signature.asc
Description: OpenPGP digital signature
CMake help: pthread linking issue
Dear mentors, I am trying to update salmon [1] to the latest upstream version, but it won't build for reasons I can not really track down well. It uses CMake as the build system, which I am really not familiar with and to me feels a bit like magic incantations to me that mostly work if you use the right spells ;) Here's the last snippet of build log right before the failure: [...] Determining if the function pthread_create exists in the pthreads failed with the following output: Change Dir: /build/salmon-0.8.0+ds1/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/make" "cmTC_14592/fast" make[2]: Entering directory '/build/salmon-0.8.0+ds1/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' /usr/bin/make -f CMakeFiles/cmTC_14592.dir/build.make CMakeFiles/cmTC_14592.dir/build make[3]: Entering directory '/build/salmon-0.8.0+ds1/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_14592.dir/CheckFunctionExists.c.o /usr/lib/ccache/cc -g -O2 -fdebug-prefix-map=/build/salmon-0.8.0+ds1=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DCHECK_FUNCTION_EXISTS=pthread_create -o CMakeFiles/cmTC_14592.dir/CheckFunctionExists.c.o -c /usr/share/cmake-3.11/Modules/CheckFunctionExists.c Linking C executable cmTC_14592 /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_14592.dir/link.txt --verbose=1 /usr/lib/ccache/cc -g -O2 -fdebug-prefix-map=/build/salmon-0.8.0+ds1=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DCHECK_FUNCTION_EXISTS=pthread_create -Wl,-z,relro -Wl,-z,now -rdynamic CMakeFiles/cmTC_14592.dir/CheckFunctionExists.c.o -o cmTC_14592 -lpthreads /usr/bin/ld: cannot find -lpthreads collect2: error: ld returned 1 exit status make[3]: *** [CMakeFiles/cmTC_14592.dir/build.make:87: cmTC_14592] Error 1 make[3]: Leaving directory '/build/salmon-0.8.0+ds1/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' make[2]: *** [Makefile:126: cmTC_14592/fast] Error 2 make[2]: Leaving directory '/build/salmon-0.8.0+ds1/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' It looks like CMake can not find the POSIX threads libs (just the headers? or a library?) and tries various spellings and variations of the library to autodetect the correct situation on the platform? At least there seems to be some automagically created code involved that the build process is trying to compile... Maybe someone more familiar with CMake could give me some pointer where to continue looking? I'm a bit lost. I've tried to add libpthread-stubs0-dev to the build-deps but no success. I have also attached a full build log. Thanks in advance Sascha [1] https://salsa.debian.org/med-team/salmon buildlog.txt.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Re: salsa.d.o merge_requests for pristine-tar and upstream?
Hi Steffen, if I see that correctly this is just a default hook that GitLab does -- offer to open merge requests for each pushed branch. I don't think that fits too well with how we do things: for example, proposing an upstream update via regular merge requests would require all three separate branches to be merged (and MRs to be opened!). >From my point of view, the merge request mechanism in Debian and GitLab feels more like a replacement or alternative for sending patches: it makes it easy to propagate small, attributable changesets that do not touch more than one branch at a time. Cheers Sascha On 04/27/2018 02:30 PM, Steffen Möller wrote: > Hello, > > does that piece of magic have any particular practial meaning? The > uploads seem to have happened. > > Many thanks > > Steffen > > ~/git/grabix$ git push --all > Counting objects: 27, done. > Delta compression using up to 2 threads. > Compressing objects: 100% (26/26), done. > Writing objects: 100% (27/27), 5.45 KiB | 1.36 MiB/s, done. > Total 27 (delta 13), reused 0 (delta 0) > remote: > remote: To create a merge request for pristine-tar, visit: > remote: > https://salsa.debian.org/med-team/grabix/merge_requests/new?merge_request%5Bsource_branch%5D=pristine-tar > remote: > remote: To create a merge request for upstream, visit: > remote: > https://salsa.debian.org/med-team/grabix/merge_requests/new?merge_request%5Bsource_branch%5D=upstream > remote: > To salsa.debian.org:med-team/grabix.git > 4ae746a..7ab4f4f master -> master > 1079721..9a1d581 pristine-tar -> pristine-tar > 974be90..4a49cae upstream -> upstream >
Re: uploading libzstd...
Hi Mattia, thanks for diving into this! Just quickly replying as my name was mentioned... [...] > Alex Mestiashvili, Sascha Steinbiss, Kevin Murray: there are a bunch of > patches without Forwarded header, that seems like have been there for a > while. Please do some upstreaming work there. There are two patches with my name in the Author field. One can be removed (0009-Add-shebang-for-scripts.patch) as upstream seems to have made the fix already and the patch would only duplicate the shebang line now. As for the other one (0008-Address-embedded-zlib.patch), this was merely a workaround for zlibWrapper not to build its examples with the embedded gz*.c zlib copies -- something specific to the Debian policy which I usually do not consider mandatory to forward to upstream. The patch description could use some love though. I'll address these minor issues later today, thanks for the heads-up. When do you want to make the upload? Cheers Sascha
Re: pynast did not migrate to salsa?
Hi Steffen and Andreas, >> I cannot find the pynast repository on salsa. Any ideas? The entry on the >> med/bio task page points to its previous location on alioth and I cannot >> find it on salsa. > > I simply forgot to push after the local SVN to Git migration. So the > package never existed on git.debian.org (despite the Vcs fields said so > after my upload. Ah, I see. Good to see this is not an result of some error in the automated migration. Please let me know if there are other unexplained cases, I'd be happy to take a look. Cheers Sascha
Re: RFS: andi
Hi Fabian, > I prepared a new package for andi, now on salsa [1]. However, I am sure, > I must have done something wrong, because the packaging was surprisingly > smooth. I can sponsor this, but it seems that the 0.12 orig tarball is missing in the pristine-tar branch. Could you please push this as well -- thanks :) Cheers Sascha signature.asc Description: OpenPGP digital signature
Re: Salsa migration of Debian Med team packages
Hi all, >>> I think all R packages (r-*) can be removed from the Debian Med >>> repository, they moved into the Debian R team repository [1] some >>> weeks ago [2]. >> >> Thanks for the hint. I will remove those repositories from the Debian >> Med namespace tomorrow if there are no objections from the team. > > No objections and thanks to Dylan for bringing this up (I just missed > this). Done. All "r-*" projects have been removed now from the med-team namespace. Cheers Sascha signature.asc Description: OpenPGP digital signature
Re: Salsa migration of Debian Med team packages
Hi Dylan, [...] > I think all R packages (r-*) can be removed from the Debian Med > repository, they moved into the Debian R team repository [1] some > weeks ago [2]. Thanks for the hint. I will remove those repositories from the Debian Med namespace tomorrow if there are no objections from the team. Best regards Sascha signature.asc Description: OpenPGP digital signature
Re: Salsa migration of Debian Med team packages
Hi all, [...] >> Do we also want the automatic tag-pending assignment hook? > > I would say so. I think the only reason we didn't have them before was > that nobody got around to adding it. OK, I see. I'm currently enabling this hook on all repositories migrated yesterday. Cheers Sascha signature.asc Description: OpenPGP digital signature
Re: Salsa migration of Debian Med team packages
Hi all, >> Picking a random repository, I noticed no integration was enabled. >> Can I suggest: >> + email on push to dipa...@tracker.debian.org ¹ >> + irc notification to #debian-med >> + tagpending hook > > Cool, didn't know these were already existing and usable. :) > Will look into this right away. Done. The first two are indeed very useful and now active on all current projects in the med-team space. I have also added email-on-push notifications to the traditional mailing list [1] on request of the sprinters. Do we also want the automatic tag-pending assignment hook? Note that these integration services are not enabled by default for new GitLab projects created via the web interface. To create new projects with these enabled out of the box, one can, for example, use [2] or get inspired by a variety of other tools out there from other teams. Cheers Sascha [1] debian-med-com...@lists.alioth.debian.org [2] https://salsa.debian.org/satta/salsa-migration-tools/blob/master/setup-repository.rb signature.asc Description: OpenPGP digital signature
Re: Salsa migration of Debian Med team packages
Hi Mattia, yay, thanks for your hints! > Picking a random repository, I noticed no integration was enabled. > Can I suggest: > + email on push to dipa...@tracker.debian.org ¹ > + irc notification to #debian-med > + tagpending hook Cool, didn't know these were already existing and usable. :) Will look into this right away. Cheers Sascha
Salsa migration of Debian Med team packages
Dear Debian Med team, here's a quick hello from the Debian Med sprint in Barcelona! I used the first day of the sprint to migrate the team packaging repositories from Alioth to Salsa, resulting in almost 1200 new Salsa repos in the Debian Med group [1]. The Alioth repositories are now locked, any attempt to push there should be rejected with a notice message. In general, there was no need to change repository names during the migration. There were two notable exceptions, related to the fact that some characters are forbidden in GitLab repository names: - ncbi-blast+, whose repository was renamed to ncbi-blastplus [2], and - socket++, whose repository was renamed to socketplusplus [3]. This change only affected the repository name, source and binary package names were left untouched. I have also filed a merge request [4] to enable redirections from anonscm HTTPS URLs (such as the ones in our current Vcs-Git tags) to their counterparts on Salsa. If there are any additional questions or suggestions, please do not hesitate to get in touch. Best regards Sascha [1] https://salsa.debian.org/med-team [2] https://salsa.debian.org/med-team/ncbi-blastplus [3] https://salsa.debian.org/med-team/socketplusplus [4] https://salsa.debian.org/salsa/AliothRewriter/merge_requests/142 signature.asc Description: OpenPGP digital signature
Re: Hotel for Debian Med Sprint
Hi Steffen,I just need to call in tomorrow morning again for special conditions forus as a group. If you cannot wait then book tonight, otherwise I proposeyou wait for the official green light tomorrow. I'll then also update the website.Great, I will wait — thanks for taking care of this!CheersSascha
Re: Date shift: Sprint moving to 10-12/2/2018, was: Debian Med Sprint 26-28/1/2018 in Barcelona
Hi all, [...] >> I wonder whether it would be possible to have our Sprint *before* the >> ELIXIR meeting. I do not question your point above but I have strong >> private reasons to keep the weekend 10./11. February 2018 free. If >> anybody else would be in a similar situation (and the ELIXIR meeting >> would last the whole week so that we can profit from the attached dates) >> I would welcome to shift it to the weekend before. > That would be in parallel with FOSDEM, which I had hoped to avoid this time > since that complaint came up a few times before. Just for the record: I will definitely be at FOSDEM which means I would not be able to attend the sprint in case of a collision. > And how about having a second retreat with a summer-in-mountains-theme > (which is a bit of an inside joke since this pretty much describes the area > Andreas lives in, while I started this water-theme close to my home at the > Baltic sea, so I am basically asking if we could compensate should Andreas > miss parts of this Sprint)? I keep thinking that every of our meetings > has done something good to our Debian Blend, so maybe we can double that? Agreed. I would like that as well :) If not an Andreas' place, then maybe somewhere more accessible? Cheers Sascha signature.asc Description: OpenPGP digital signature
Re: [Debian-med-packaging] Bug#871513: muscle FTCBFS: hard codes the build architecture compiler g++
Hi Helmut, > Updating the patch to use $(CXX) fixes the build. Please consider > applying the attached patch. Thanks, I would be happy to take a look and upload this. However, it looks like the git repo on Alioth doesn't seem to have the latest commits/tags for the latest uploaded version. I'd be on it as soon as these are pushed. Thanks again, and kind regards Sascha signature.asc Description: OpenPGP digital signature
Re: [Help] Failed to upgrade bcftools to version 1.5
Hi all, > Well, I was going to branch off a separate branch from the > debian/1.4.1-2 tag, add the patches, build and upload 1.4.1-3 from > there, and then just add the changelog entry to the current master (as > the patches should already been in the latest upstream code, right?). > If one wants to reproduce the exact 1.4.1-3 state it should still be > possible via the branch. I guess I'm going to do that for now. > Anyway, a more acute problem is that even with the patches [1] I can't > get bcftools 1.4.1 to build in a recent i386 sid chroot. I get some new > failed tests that you did not encounter in the original bug report: > > Number of tests: > total .. 617 > passed .. 561 > failed .. 56 Oops, just noticed that i386 never built in the first place, and the patches addressed getting the currently out-of-date builds on armel and mipsel to work. I can confirm from builds on porterboxes that these now finish, so I'm going to upload a new bcftools 1.4.1 version with the patches but leave the bug (#868958) open since not all 32-bit archs are building yet. OK with everyone? Cheers Sascha
Re: [Help] Failed to upgrade bcftools to version 1.5
Hi all, [...] >> The remaining bugs blocking the transition are augustus (bug #869126) and >> bcftools (bug #868958). Sascha has already pushed the augustus changes to >> git, and it just needs an upload. The two fixes for bcftools are in the bug >> report, someone should review them and upload. > > Sascha, will you care for this? Good timing, indeed I was going to finish up the augustus package tonight. I took some time to finally include all the little executables that come with the main tool, and I wanted to take another close look to make sure they all have man pages etc. Once I'm at it I can also take a shot at bcftools. Never worked on that before though, let's see how it goes. Cheers Sascha signature.asc Description: OpenPGP digital signature
Bug#869969: ITP: gfapy -- flexible and extensible software library for handling sequence graphs
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: gfapy Version : 1.0.0 Upstream Author : Giorgio Gonnella * URL : https://github.com/ggonnella/gfapy * License : ISC Programming Lang: Python Description : flexible and extensible software library for handling sequence graphs The Graphical Fragment Assembly (GFA) are formats for the representation of sequence graphs, including assembly, variation and splicing graphs. Two versions of GFA have been defined (GFA1 and GFA2) and several sequence analysis programs have been adopting the formats as an interchange format, which allow the user to easily combine different sequence analysis tools. This library implements the GFA1 and GFA2 specification. It is possible to create a Gfa object from a file in the GFA format or from scratch, to enumerate the graph elements (segments, links, containments, paths and header lines), to traverse the graph (by traversing all links outgoing from or incoming to a segment), to search for elements (e.g. which links connect two segments) and to manipulate the graph (e.g. to eliminate a link or a segment or to duplicate a segment distributing the read counts evenly on the copies). The GFA format can be easily extended by users by defining own custom tags and record types. In Gfapy, it is easy to write extensions modules, which allow one to define custom record types and datatypes for the parsing and validation of custom fields. The custom lines can be connected, using references, to each other and to lines of the standard record types.
Re: CI for probalign needs sponsoring from other sponsor [Outreachy]
Hi Nadiya, > I added autopkgtest test-suite for probalign package. > I would really appreciate your help in uploading. Done, thanks for your contribution! :) Cheers Sascha signature.asc Description: OpenPGP digital signature
Re: CI for abyss needs sponsoring from other sponsor [Outreachy]
Hi Nadiya, > I added simple autopkgtest test for abyss package. > Your help in uploading will be very much appreciated. Cool, many thanks! I just took a look and I’m going to upload with some minor modifications. BTW, your autopkgtest revealed that there apparently still was a missing dependency on bsdmainutils (providing /usr/bin/column, which abyss-tabtomd needs). I wonder why that wasn't picked up — are you running your autopkgtests in a chroot or LXC container? Thanks again and best regards Sascha signature.asc Description: Message signed with OpenPGP
Re: Please fix bugs
Hi all, > On 6/27/17 9:34 PM, Andreas Tille wrote: >> as I stated on debian-private list I will not be able to fix bugs in the >> next two weeks. I have the feeling we are currently receiving way more >> than we are fixing. It would be really cool if you could run some kind >> of inofficial first bug squashing party for the upcoming release. :-) >> > > how about having a physical Debian Med BSP as a regular summer event? Sounds good, I wouldn't object :) Cheers Sascha signature.asc Description: OpenPGP digital signature
Re: [Debian-med-packaging] Bug#863159: zstd: New upstream version with multithreading support
Hi, > On 24 May 2017, at 14:57, Olivier Sallou wrote: > > I updated in git repo but did not pushed. Thanks for that! I had a look at this this morning as well but given that I am traveling at the moment I also only found the time to merge the new version locally but didn’t follow through. I did notice, though, that there seems to be some new additional embedded code that looks suspicious (contrib/linux-kernel/* etc.) so d/copyright probably needs to be updated? Cheers Sascha > Forwarded Message > Subject: [Debian-med-packaging] Bug#863159: zstd: New upstream version > with multithreading support > Resent-Date: Mon, 22 May 2017 19:03:20 + > Resent-From: Andreas Kotes , Andreas Kotes > > Resent-To:debian-bugs-d...@lists.debian.org > Resent-CC:Debian Med Packaging > > Date: Mon, 22 May 2017 21:00:50 +0200 > From: Andreas Kotes , Andreas Kotes > > Reply-To: Andreas Kotes , Andreas Kotes > , 863...@bugs.debian.org > To: Debian Bug Tracking System > > Package: zstd > Version: 1.1.2-1 > Severity: wishlist > > Dear Maintainer, > > > https://github.com/facebook/zstd/releases > has a new release (1.2.0), > sporting Multi-Threading support directly in zstd (instead of just via > pzst), making it worth bugging you about it for a moment *cough* :) > > The code present there can also far either be dpkg-buildpackaged on > older Debian & Ubuntu versions, making this a very selfish ask ... > > Please consider packaging it sometime soon - thank you :) > > Thanks in advance! > > count > > -- System Information: > Debian Release: 8.8 > APT prefers stable > APT policy: (990, 'stable'), (500, 'testing'), (500, 'oldstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) > Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages zstd depends on: > ii libc6 2.24-10 > ii libgcc1 1:6.3.0-18 > ii libstdc++6 6.3.0-18 > ii libzstd11.1.2-1 > > zstd recommends no packages. > > zstd suggests no packages. > > -- no debconf information > > -- > Andreas 'count' Kotes > Taming computers for humans since 1990. > "Don't ask what the world needs. Ask what makes you come alive, and go do it. > Because what the world needs is people who have come alive." -- Howard Thurman > > ___ > Debian-med-packaging mailing list > > debian-med-packag...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging signature.asc Description: Message signed with OpenPGP
Re: spades updated to 3.10.1 in git
Hi Michael, > It will need sponsoring once sketch has been released Thanks! I was taking a shot at this myself a while ago but ran into random segfaults after adjusting patches. Nice to see that there's some progress. Would be happy to take a look and sponsor the upload when it's time. Cheers Sascha signature.asc Description: OpenPGP digital signature
Re: upload to unstable during freeze ?
Hi Olivier, > I see some uploads to unstable during the freeze. I understood it was > not expected as fixes that need to go to "next stable" go through > uploads to unstable. > > While this should not be an issue for packages that do not present > issues at this time, I'd like to know if we should anyway push to unstable ? just my 2 cents, but I've done it like this so far: - If there is a new version of a package which is not in testing (e.g. entered unstable after the NEW freeze) then I upload straight to unstable as there's no need to stay close to the frozen testing for fixes. - If there's a frozen version in testing, I open a new 'next' or 'experimental' branch in git with the new version and upload it to experimental. Since experimental is separate, once the freeze is over it should just be a matter of rebuilding and re-uploading the new version to unstable. - If a package is completely NEW, then it's fine to upload directly to unstable since there's no way it will affect the frozen stretch. Any comments or suggestions from the others? I didn't to this out of habit for ariba (uploading to unstable) and of course now there's an (upstream related) RC bug for the stretch version with a newer version in unstable :/ This would have been more of a routine if unstable would have been clean... Cheers Sascha
Re: Patching fermi-lite to enable packaging libSeqLib
Hi Andreas, as a previous uploader of ariba and fermi-lite, I'll see if I can contribute to this discussion. > to package the latest version of freebayes (version 1.0.2 is in new, > latest upstream is 1.1) a new library libSeqLib is needed. I started > with the packaging[1] and managed to build it without the patched code > copy of fermi-lite. SeqLib upstream was doing some patching since bwa > and fermi-lite are using the same variable bseq1_t which is defined > differently. I patched fermi-lite in Git by renaming it to fml_seq1_t > (and some other code changes + additions by libSeqLib author). OK. This sounds like a reasonable change (as long as there are no other packages depending on it). > I have not yet uploaded fermi-lite since ariba depends from fermi-lite > and needs to be adapted to the patched fermi-lite (as I did in commit > 92be90993f020d5d2395f083a42a48cebd5bab49) and wanted to discuss this > here. While I have opened an issue at Github for fermi-lite[2] there > was no response until now. The change to ariba's C++ code looks OK to me. > What do you suggest to do? My proposal would be to upload the patched > fermi-lite as well as the patched ariba to experimental (which is > advisable in freeze anyway) and keep on working with libseqlib. Agreed as far as I am concerned. However, might one probably argue that the symbol clash is worth a RC bug? If so then it might even qualify for unstable? What do the others think? Cheers Sascha
Re: pbcommand new upstream
Hi Afif, >> OK, thanks for the confirmation. I’ll update to the latest version of >> pbcommand then. > > Many thanks for updating pbcommand--but don't forget to push the final > changes and tag. :) [x] Done. BTW, I've seen that you updated and uploaded kineticstools -- I just finished getting its autopkgtests to work again when I had to leave the sprint ;) Thanks for taking care of this! Best regards Sascha signature.asc Description: OpenPGP digital signature
Re: libzstd 1.1.2 contains embedded zlib fork
Hi Kevin, thanks for your email. >> I was looking to update libzstd to the current upstream version 1.1.2. >> Besides some minor changes to the patches I had to make, I also noticed that >> it now includes an embedded copy of some zlib code, which -- according to the >> inline comments -- was adapted to be ready to compile with the zlibwrapper. >> It wasn’t clear to me whether this was really necessary; when these files are >> removed from the affected Makefile (and some minor adjustments are made) the >> build still finishes fine. > > That's been there since 1.1 I think, and is AFAICT example code for an > alternative, non-packaged API that mimics the zlib API. It could be packaged > under libzstd-dev:usr/share/doc/libzstd-dev/examples or something, like I've > seen with a few development packages. Otherwise, I think nuking the sources or > just removing them from the makefile is fine. Though from memory, anything > compiled from these is not installed, so no action is probably also OK. OK. I've checked that the new packages contain (at least) the same files as the 1.1.1 version, which is the case. So this indeed doesn’t touch the installed contents and I also agree that there shouldn’t be a problem. […] > What does the DFSG say about sources that are > not compiled? They're in d/copyright anyway, IIRC FTPMASTER bounced me last > update for this exact issue, and I added them. There are some new sources in zlibWrapper/ under zlib license by M. Adler. They are actually new in 1.1.2 and also compiled in the Makefile — thats why I was asking about them as I disabled them. To be on the safe side license-wise have added them to d/copyright as well, so I guess we should be fine. Preparing an upload as we speak. Cheers Sascha signature.asc Description: Message signed with OpenPGP
Re: pbcommand new upstream
Hi Afif, thanks for getting back to me so quickly. >> What would you suggest, package the current version now that we need it? You >> have got more experience with the PB tools and how likely they are to break >> APIs across versions — do you think it’s a good idea? > > Yes, I think it should be safe to use the latest versions of the > different PacBio tools together. If it breaks anything, then that just > points out something else that should be updated. OK, thanks for the confirmation. I’ll update to the latest version of pbcommand then. Cheers Sascha signature.asc Description: Message signed with OpenPGP
pbcommand new upstream
Hi Afif, at the sprint I’m currently trying to update kineticsTools to a recent version. However, it also requires a newer version of pbcommand, which we missed to keep up-to-date as upstream are not tagging their GitHub releases [1]. It is possible to manually track the upstream versions by watching the history of pbcommand/__init__.py in the repo [2], which contains the version number that is used in the setup.py. They're currently at 0.5.4 while we only carry 0.3.x. What would you suggest, package the current version now that we need it? You have got more experience with the PB tools and how likely they are to break APIs across versions — do you think it’s a good idea? Cheers Sascha [1] https://github.com/PacificBiosciences/pbcommand/issues/116 [2] https://github.com/PacificBiosciences/pbcommand/commits/master/pbcommand/__init__.py signature.asc Description: Message signed with OpenPGP
libzstd 1.1.2 contains embedded zlib fork
Hi Kevin, here on the Debian Med sprint I was looking to update libzstd to the current upstream version 1.1.2. Besides some minor changes to the patches I had to make, I also noticed that it now includes an embedded copy of some zlib code, which -- according to the inline comments -- was adapted to be ready to compile with the zlibwrapper. It wasn’t clear to me whether this was really necessary; when these files are removed from the affected Makefile (and some minor adjustments are made) the build still finishes fine. TBH I don’t feel I should upload this after consulting with you. I have pushed my changes (tagged as UNRELEASED) and would be happy if you could take a second look. Many thanks Sascha signature.asc Description: Message signed with OpenPGP
Re: Sprint organisation
Hi all, > I did a walk through of the space today, a snowy 10 minute walk from the > hotel. Yay! > Good news on the Wi-Fi! > > http://www.speedtest.net/my-result/a/2527663676 Sounds good. It looks like most of you will already be arriving on Thursday... so I guess I will meet you at the sprint site on Friday then? I can contact Michael in time or take a taxi from the airport/hotel. All the best, and see you all on Friday! Cheers Sascha
Re: DebianMed sprint hotel proposal
Hi Andreas, >> I have also just booked a room at that hotel. They’re really inexpensive and >> it looks like there are still rooms left :) > > I also tried a reservation and while the page lists empty rooms I failed > in registering using their web interface. I've just send an e-mail and > guess this will work as well. I had the same experience and tried booking.com afterwards, it worked there with no problems. I now have a printed booking confirmation and I hope I will get some keys for that once I arrive ;) Cheers Sascha
Re: DebianMed sprint hotel proposal
Hi all, > > So, I have made a reservation at an hotel not far from the Faculty of > > Biology and quite well located. It is not expensive and has twin bed rooms > > for those willing to share rooms. It also has a restaurant if needed. > > Thanks a lot for steping in. Indeed, thanks Olivier for taking charge of this research. > > Hotel Trianon > > Cobalcescu Grigore 9, Sector 1, 010191 Bucarest, Roumanie > > > > There is free wifi and it seems it has some places with sofa where we could > > meet and work together if needed in the evening or time where we are not at > > the faculty (based on hotel description and photo, could not get > > confirmation)/ > > > > This is a proposal, I can still cancel my reservation if needed. If it is > > ok for you, i suggest you make a reservation at the same place so that we > > are all in the same location (will be easier to meet and discuss). > > Everything sounds good. I'm fine with sharing a room. > I personnaly took a single room as it is not expensive and paid by my > institute. I have also just booked a room at that hotel. They’re really inexpensive and it looks like there are still rooms left :) See you there Sascha
Re: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: Fails to build from source since bioperl upgrade has broken libbio-graphics-perl)
BTW, [1] here was: https://github.com/sanger-pathogens/Roary/issues/196 Cheers Sascha > On 17 Dec 2016, at 23:28, Sascha Steinbiss wrote: > > Hi all, > > thanks for checking these. > >>> roary >> >> Build, however when trying to simulate the test suite via >> >> cd t/data/genbank_gbff >> roary -f out *.gff >> >> Please cite Roary if you use any of the results it produces: >> Andrew J. Page, Carla A. Cummins, Martin Hunt, Vanessa K. Wong, Sandra >> Reuter, Matthew T. G. Holden, Maria Fookes, Daniel Falush, Jacqueline A. >> Keane, Julian Parkhill, >> "Roary: Rapid large-scale prokaryote pan genome analysis", >> Bioinformatics, 2015 Nov 15;31(22):3691-3693 >> doi: http://doi.org/10.1093/bioinformatics/btv421 >> Pubmed: 26198102 >> >> Use of uninitialized value in require at >> /usr/lib/x86_64-linux-gnu/perl/5.24/Encode.pm line 61. >> >> >> This does not look good even if it does not look related to BioPerl. > > In fact, it doesn’t look related to Roary either. It’s apparently a missing > Encode/ConfigLocal.pm in the coded provided by libencode-perl, but not a > fatal issue here as it doesn’t seem to impact the result or performance of > Roary. It’s been reported before [1] and I will let upstream know that the > warning is back. Not a blocker AFAICS. > > Cheers > Sascha
Re: Urgent call to BioPerl users (Was: Bug#848236: src:gbrowse: Fails to build from source since bioperl upgrade has broken libbio-graphics-perl)
Hi all, thanks for checking these. >> roary > > Build, however when trying to simulate the test suite via > > cd t/data/genbank_gbff > roary -f out *.gff > > Please cite Roary if you use any of the results it produces: >Andrew J. Page, Carla A. Cummins, Martin Hunt, Vanessa K. Wong, Sandra > Reuter, Matthew T. G. Holden, Maria Fookes, Daniel Falush, Jacqueline A. > Keane, Julian Parkhill, >"Roary: Rapid large-scale prokaryote pan genome analysis", > Bioinformatics, 2015 Nov 15;31(22):3691-3693 >doi: http://doi.org/10.1093/bioinformatics/btv421 >Pubmed: 26198102 > > Use of uninitialized value in require at > /usr/lib/x86_64-linux-gnu/perl/5.24/Encode.pm line 61. > > > This does not look good even if it does not look related to BioPerl. In fact, it doesn’t look related to Roary either. It’s apparently a missing Encode/ConfigLocal.pm in the coded provided by libencode-perl, but not a fatal issue here as it doesn’t seem to impact the result or performance of Roary. It’s been reported before [1] and I will let upstream know that the warning is back. Not a blocker AFAICS. Cheers Sascha
Re: Sponsoring request: beagle
Hi Dylan, I just took a look and uploaded. Thanks, Sascha > On 4 Oct 2016, at 22:01, Dylan wrote: > > Hi, > I have updated beagle. Could someone upload it to unstable? > > Thank you. > > Best regards, > Dylan >
Bug#838856: ITP: ruby-rgfa -- Ruby library for handling GFA files
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: ruby-rgfa Version : 1.2 Upstream Author : Giorgio Gonnella * URL : https://github.com/ggonnella/rgfa * License : ISC Programming Lang: Ruby Description : Ruby library for handling GFA files The Graphical Fragment Assembly (GFA) format is a proposed file format to describe the product of a genome sequence assembly process. rgfa implements the proposed specifications for the GFA format described under https://github.com/pmelsted/GFA-spec/blob/master/GFA-spec.md as closely as possible. The library allows one to create an RGFA object from a file in the GFA format or from scratch, to enumerate the graph elements (segments, links, containments, paths and header lines), to traverse the graph (by traversing all links outgoing from or incoming to a segment), to search for elements (e.g. which links connect two segments) and to manipulate the graph (e.g. to eliminate a link or a segment or to duplicate a segment distributing the read counts evenly on the copies).
Re: Again help needed to upgrade picard-tools
Hi Vincent, thanks for your quick reply! >> I was a bit confused by the ‘-gradle’ version suffix used in the previous >> version that was compensated for in an jh_installlibs override. If this >> suffix is not part of a new version string, jar renaming is broken during >> the installation. I removed the jh_installlibs override to make the current >> version work, but not being a core Java guy I was wondering whether this was >> a commonly used thing…? > > Just after the release of 2.5.0, upstream changed its build system > (starting to use gradle) and released a 2.5.0-gradle upstream version > with the same code but a different gradle-based build system. I see, that explains it. > So the -gradle suffix have been here only for one upstream > release. All things done to handle it can be removed now. OK, great. The override is gone now and javahelper’s default mechanism works perfectly. Kind regards Sascha
Re: Again help needed to upgrade picard-tools
Hi, >> ... >> Results: FAILURE (1833 tests, 1832 successes, 1 failures, 0 skipped) >> ... >> Any ideas from someone with more detailed insight? > > We needed to exclude some tests since internet access is needed. I have > not checked the lot of output but this might be the case here as well > (if a debuild on your local machine that's most probably the case). So > excluding another test would be no big deal. It seemed to have been related to the method creating the test data not matching the method consuming it. Fixed it and tests complete now, also did some housekeeping. If you want to take a look, it’s in git. Should be ready for upload IMHO. I was a bit confused by the ‘-gradle’ version suffix used in the previous version that was compensated for in an jh_installlibs override. If this suffix is not part of a new version string, jar renaming is broken during the installation. I removed the jh_installlibs override to make the current version work, but not being a core Java guy I was wondering whether this was a commonly used thing…? Cheers Sascha
Re: Again help needed to upgrade picard-tools
Hi all,
> seems I always have trouble with picard-tools. I have injected new
> upstream version in Git but it fails to build. The upgrade of
> libhtsjdk-java went fine but it would be great if somebody could have a
> look at picard-tools.
Something in the build system changed; I patched it slightly to work again.
Builds now with libhtsjdk-java 2.6, but one test fails at the moment:
Gradle Test Executor 1 finished executing tests.
Results: FAILURE (1833 tests, 1832 successes, 1 failures, 0 skipped)
Here’s the output from the test’s HTML report:
org.testng.internal.reflect.MethodMatcherException:
Data provider mismatch
Method: runCollectTargetedMetricsTest([Parameter{index=0,
type=java.lang.String, declaredAnnotations=[]}, Parameter{index=1,
type=java.lang.String, declaredAnnotations=[]}, Parameter{index=2,
type=java.lang.String, declaredAnnotations=[]}, Parameter{index=3,
type=java.lang.String, declaredAnnotations=[]}, Parameter{index=4, type=int,
declaredAnnotations=[]}, Parameter{index=5, type=int, declaredAnnotations=[]},
Parameter{index=6, type=boolean, declaredAnnotations=[]}, Parameter{index=7,
type=int, declaredAnnotations=[]}, Parameter{index=8, type=int,
declaredAnnotations=[]}, Parameter{index=9, type=double,
declaredAnnotations=[]}, Parameter{index=10, type=double,
declaredAnnotations=[]}, Parameter{index=11, type=double,
declaredAnnotations=[]}, Parameter{index=12, type=double,
declaredAnnotations=[]}, Parameter{index=13, type=int, declaredAnnotations=[]}])
Arguments:
[(java.lang.String)testdata/picard/analysis/directed/CollectHsMetrics/lowmapq.sam,(java.lang.String)testdata/picard/analysis/directed/CollectHsMetrics/chrM.fasta,(java.lang.String)testdata/picard/analysis/directed/CollectHsMetrics/chrM.interval_list,(java.lang.String)NONE,(java.lang.Integer)2,(java.lang.Integer)0,(java.lang.Boolean)true,(java.lang.Integer)2,(java.lang.Integer)202,(java.lang.Integer)0,(java.lang.Double)0.0,(java.lang.Double)0.505,(java.lang.Double)0.0,(java.lang.Integer)1000]
at
org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52)
at org.testng.internal.Invoker.injectParameters(Invoker.java:1225)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1123)
at
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112)
at org.testng.TestRunner.privateRun(TestRunner.java:746)
at org.testng.TestRunner.run(TestRunner.java:600)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:366)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319)
at org.testng.SuiteRunner.run(SuiteRunner.java:268)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1264)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1189)
at org.testng.TestNG.runSuites(TestNG.java:1104)
at org.testng.TestNG.run(TestNG.java:1076)
at
org.gradle.api.internal.tasks.testing.testng.TestNGTestClassProcessor.runTests(TestNGTestClassProcessor.java:133)
at
org.gradle.api.internal.tasks.testing.testng.TestNGTestClassProcessor.stop(TestNGTestClassProcessor.java:83)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.stop(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.stop(TestWorker.java:120)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(Ref
Re: Build directories sneaking into Makefiles installed as examples
Hi, >> I have found some more instances, and I have added some workarounds removing >> these problematic fields from the Makefile [2] to let them use the default >> if required — however, I am wondering whether these Makefiles should be >> installed at all. Cleaning them up would add quite a bit of overhead to the >> d/rules in each case and I am quite doubtful users would ever touch these >> Makefiles (if they even work at all). >> Any opinions or ideas? > > Cleaning up the Makefile is fine after checking if it might have any > use. To me it looked more like the automake-generated ones would be used mainly in the build time tests (the directories in there sometimes don’t make sense outside the build source tree). I’ll keep an eye open if there are other examples. > If it might make sense (for instance when running checks on > libraries as I'm doing in cimg-dev package) to use the Makefile we > should check for such pathes and normalise to some default. I propose that in this case we just replace the build directory after dh_install by ‘.’ - that’s what we do in other build directory-related reproducibility issues. Cheers Sascha signature.asc Description: Message signed with OpenPGP using GPGMail
Build directories sneaking into Makefiles installed as examples
Hi all, when trying to fix some packages that have recently become unreproducible after adding build path variations, I have noticed that a common case is that some of these variations make it into Makefiles that have been generated by automake from upstream’s Makefile.in. Some of these Makefiles are included in the packages in question, for instance to automate tests that most likely were intended by upstream to be run at build time. However, since with the introduction of the new autopkgtests upstream’s test cases are often also installed in /usr/share/doc/…/examples, we see some cases of Makefiles containing build-specific directories ending up in binary packages, since the values for C(XX|PP)FLAGS etc. are propagated from the build environment into these files. An example is [1] where the value of CFLAGS is modified. I have found some more instances, and I have added some workarounds removing these problematic fields from the Makefile [2] to let them use the default if required — however, I am wondering whether these Makefiles should be installed at all. Cleaning them up would add quite a bit of overhead to the d/rules in each case and I am quite doubtful users would ever touch these Makefiles (if they even work at all). Any opinions or ideas? Cheers Sascha [1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/hmmer2.html HMMER3 (package hmmer) is also affected. [2] https://anonscm.debian.org/cgit/debian-med/toppred.git/commit/?id=8e5b443c66d60de5487c6e526a57828ec5e6a19e signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Could somebody please check ncbi-tools6 (Was: [GSOC] Todo List)
Hi Andreas, > On Mon, Aug 22, 2016 at 02:20:08PM +0200, Sascha Steinbiss wrote: >> BTW you don’t need to install your test data to be used in the autopkgtest, >> as tests will always be run with an decompressed source tree present, >> including the debian directory. > > I think I have influenced Canberk here with my habit to enable users > using the autopkgtest as usage example at the same time. This requires > to have the example data installed in a binary package as well as the > script that is called by debci. Ah, I see — this makes sense, thanks. In cases such as this the example set would need to be split up across multiple binary packages though — some would need to go into blast2 and some into ncbi-tools-bin (or ncbi-data, that would work as well…). Anyway, I understand the motivation now and while I’m usually more of a minimalist I completely respect that approach! Canberk, please don’t let that keep you from including examples :) Cheers Sascha signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Could somebody please check ncbi-tools6 (Was: [GSOC] Todo List)
Hi Canberk, > Main problem is package dont provide a binary named ncbi-tools6 :) There are > different binaries inherited from this package like blast2 and ncbi-tools-bin > so my test must work on two binaries from ncbi-tools6 package. Am i clear now > ? I see. I have always found it easiest in such cases to make a single test for all binary packages in the whole source package, especially if they are thematically related. This is absolutely fine as long as you require both binary packages (or ‘@‘) in your d/tests/control file. BTW you don’t need to install your test data to be used in the autopkgtest, as tests will always be run with an decompressed source tree present, including the debian directory. Your new ncbi-tools6.examples file wouldn’t have been used anyway since there is no binary package ‘ncbi-tools6’. BTW, I have also made a few adjustments to the test, see git repo. Cheers Sascha > > Best Regards > > > Canberk Koç > about.me/canberkkoc > > > 2016-08-22 13:49 GMT+03:00 Sascha Steinbiss : > Hi Andreas, > > I’ll take a look. > > Cheers > Sascha > > > On 22 Aug 2016, at 11:29, Andreas Tille wrote: > > > > Hi, > > > > On Sat, Aug 20, 2016 at 10:16:14AM +0300, Canberk Koç wrote: > >> I'll commit a test for tools6 but there is a problem ncbi-tools6 not come > >> from apt-get install so test broke . There is 2 package i have blast2 and > >> tools-bin i made tests for them but i cannot make it work can you look at > >> it . > > > > For me the current Git archive does not build using gbp. I get: > > > > ... > > dpkg-source -i.git -I.git -b ncbi-tools6-6.1.20120620 > > dpkg-source: warning: no source format specified in debian/source/format, > > see dpkg-source(1) > > dpkg-source: info: using source format '1.0' > > dpkg-source: info: building ncbi-tools6 using existing > > ncbi-tools6_6.1.20120620.orig.tar.gz > > dpkg-source: info: building ncbi-tools6 in > > ncbi-tools6_6.1.20120620-12.diff.gz > > dpkg-source: error: cannot represent change to > > debian/ncbi-tools6.tests/nc0615.aso: binary file contents changed > > dpkg-source: warning: the diff modifies the following upstream files: > > api/alignmgr2.c > > api/aliread.c > > api/pgppop.c > > api/txalign.c > > corelib/ncbienv.c > > ... > > > > > > Since I'm currently busy with some real life things it would be great if > > somebody could have a look and check the tests Canberk has created. > > Sponsering of the package would be welcome. > > > > Kind regards > > > > Andreas. > > > > -- > > http://fam-tille.de > > > > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Could somebody please check ncbi-tools6 (Was: [GSOC] Todo List)
Hi Andreas and Canberk, the problem was that ncbi-tools6 is still an old-style 1.0 format package, which can not contain binary files (such as the binary ASN.1 file in the test data) as part of the /debian directory. Either the file would need to be encoded as a text file, or (perhaps the better option) the package needs to be migrated to the newer 3.0 (quilt) format. For now I have base64-encoded the binary file to include it in the package and adjusted the test script to decode it back to binary before feeding it into asn2xml. I guess that’s OK for one file, but if we’d like to keep adding test data then it might be helpful to migrate. I will upload the package including the tests soon — thanks Canberk for adding the tests! Cheers Sascha > On 22 Aug 2016, at 12:49, Sascha Steinbiss wrote: > > Hi Andreas, > > I’ll take a look. > > Cheers > Sascha > >> On 22 Aug 2016, at 11:29, Andreas Tille wrote: >> >> Hi, >> >> On Sat, Aug 20, 2016 at 10:16:14AM +0300, Canberk Koç wrote: >>> I'll commit a test for tools6 but there is a problem ncbi-tools6 not come >>> from apt-get install so test broke . There is 2 package i have blast2 and >>> tools-bin i made tests for them but i cannot make it work can you look at >>> it . >> >> For me the current Git archive does not build using gbp. I get: >> >> ... >> dpkg-source -i.git -I.git -b ncbi-tools6-6.1.20120620 >> dpkg-source: warning: no source format specified in debian/source/format, >> see dpkg-source(1) >> dpkg-source: info: using source format '1.0' >> dpkg-source: info: building ncbi-tools6 using existing >> ncbi-tools6_6.1.20120620.orig.tar.gz >> dpkg-source: info: building ncbi-tools6 in >> ncbi-tools6_6.1.20120620-12.diff.gz >> dpkg-source: error: cannot represent change to >> debian/ncbi-tools6.tests/nc0615.aso: binary file contents changed >> dpkg-source: warning: the diff modifies the following upstream files: >> api/alignmgr2.c >> api/aliread.c >> api/pgppop.c >> api/txalign.c >> corelib/ncbienv.c >> ... >> >> >> Since I'm currently busy with some real life things it would be great if >> somebody could have a look and check the tests Canberk has created. >> Sponsering of the package would be welcome. >> >> Kind regards >> >>Andreas. >> >> -- >> http://fam-tille.de >> > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Could somebody please check ncbi-tools6 (Was: [GSOC] Todo List)
Hi Andreas, I’ll take a look. Cheers Sascha > On 22 Aug 2016, at 11:29, Andreas Tille wrote: > > Hi, > > On Sat, Aug 20, 2016 at 10:16:14AM +0300, Canberk Koç wrote: >> I'll commit a test for tools6 but there is a problem ncbi-tools6 not come >> from apt-get install so test broke . There is 2 package i have blast2 and >> tools-bin i made tests for them but i cannot make it work can you look at >> it . > > For me the current Git archive does not build using gbp. I get: > > ... > dpkg-source -i.git -I.git -b ncbi-tools6-6.1.20120620 > dpkg-source: warning: no source format specified in debian/source/format, see > dpkg-source(1) > dpkg-source: info: using source format '1.0' > dpkg-source: info: building ncbi-tools6 using existing > ncbi-tools6_6.1.20120620.orig.tar.gz > dpkg-source: info: building ncbi-tools6 in ncbi-tools6_6.1.20120620-12.diff.gz > dpkg-source: error: cannot represent change to > debian/ncbi-tools6.tests/nc0615.aso: binary file contents changed > dpkg-source: warning: the diff modifies the following upstream files: > api/alignmgr2.c > api/aliread.c > api/pgppop.c > api/txalign.c > corelib/ncbienv.c > ... > > > Since I'm currently busy with some real life things it would be great if > somebody could have a look and check the tests Canberk has created. > Sponsering of the package would be welcome. > > Kind regards > > Andreas. > > -- > http://fam-tille.de > signature.asc Description: Message signed with OpenPGP using GPGMail
