Re: Question about license
Hi, On 2024-09-18 00:56, Preuße, Hilmar wrote: before pushing a broken package to the NEW queue: I started again working on #698886 and have a here a package, which is quite lintian clean. What causes headache is the license "Modified MIT license". The following paragraph has been added by the author: If you copy or distribute a modified version of this Software, the entire resulting derived work must be given a different name and distributed under the terms of a permission notice identical to this one. Except that it is a pure MIT license. Could that cause issues? I was involved in at least two similar occurrences of "must rename if modified" license clauses: https://lists.debian.org/debian-legal/2018/02/msg00026.html (InChI library) https://lists.debian.org/debian-devel/2016/03/msg00092.html (Protein DataBank files) For InChI library it was decided against uploading it, but Protein DataBank files were not prevented from entering the archive. In the end both clauses were resolved upstream. HTH, Andrius
Open "NMU diff for 64-bit time_t transition" bugs
Hello, I care for tree packages which still have open "NMU diff for 64-bit time_t transition" bugs: libccp4, macromoleculebuilder and rdkit. All of them have NMU diffs applied in experimental, but not in unstable yet. What should I do about them - apply NMU diffs to unstable as well, or wait for someone performing the time_t64 transition to do that? Best, Andrius
Re: Help with a watchfile for MUT
Hi Soren, On 2024-05-03 01:12, Soren Stoutner wrote: I am very much not a uscan expert, but the attached watch file appears to do what you want. Key changes are: 1. Adding a dversionmangle line to each entry that modifies the Debian version number to extract the information that should be used for each upstream tarball. Your case is a little interesting because one of the tarballs has a different numbering scheme. 2. Change the version entries to remove `group` and use `ignore` on the last entry. 3. Add `uupdate` as the script at the end of the file. There are probably many other ways you could accomplish this. Many thanks for giving this a look. I managed to sort out the watchfile myself by merely removing 'same', which seems to be affected by bug #891047 in uscan. Best wishes, Andrius
Help with a watchfile for MUT
Hello, I am writing a watchfile for vst3sdk, you can find it on salsa [1]. I cannot get 'same' components downloaded, 'uscan --download-current-version' fails with the following: uscan warn: In debian/watch no matching hrefs for version in watch line https://github.com/steinbergmedia/vst3_base/tags (?:.*?/)?v([0-9\.]+_build_\d+)(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz)) same It is strange that uscan does not seem to know the version to download (notice the empty space after 'no matching hrefs for version' in the error message). I would appreciate any help with this. [1] https://salsa.debian.org/merkys/vst3sdk/-/raw/master/debian/watch Best, Andrius
Re: Lintian 'privacy-breach-generic' warning for installed examples
Hi Shriram, On 2024-02-09 16:16, Shriram Ravindranathan wrote: I am packaging a C++ TUI library called FTXUI in which there's an examples/ folder which I am installing to /usr/share/doc/ftxui-dev/examples/ One of these examples is for using the library with webassembly is a HTML file that loads the JS version of xterm from a CDN. I was wondering if this is a false-positive that I should override or whether I need to create a patch and edit the HTML files to remove these links. This is not a false-positive. A CDN gets a call each time a user opens an example, so strictly speaking this is a privacy breach. So it should not be overridden. I would suggest patching out such links. Best, Andrius
Re: pkgconfig multiarch installation woes
Hi Shriram,
On 2023-11-18 10:26, Shriram Ravindranathan wrote:
I am packaging magic_enum, a header-only C++ library which uses CMake
with GNUInstallDirs. AFAIK the package should be arch-independent as
there is no architecture dependent code in it.
[...]
W: libmagicenum-dev: pkg-config-unavailable-for-cross-compilation
[usr/lib/pkgconfig/magic_enum.pc]
N:
N: The specified pkg-config(1) file is installed to /usr/lib/pkgconfig. As
the cross-compilation wrapper of pkg-config does not search this directory
N: the file is unavailable under cross-compilation.
N:
N: Please install the file to /usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
instead.
N:
N: For projects that use GNU Autotools, a simple method is moving to a
debhelper compat level of 9 or higher. In the rare case that this file is
N: architecture independent it can be installed to /usr/share/pkgconfig
instead.
N:
N: Visibility: warning
N: Show-Always: no
N: Check: files/pkgconfig
This lintian warning suggests installing architecture independent
pkg-config files under /usr/share/pkgconfig, have you tried doing so?
Hope this helps,
Andrius
Re: New package: ITP or RFP ?
Hi, On 2023-06-20 17:15, Ramūnas Keliuotis wrote: 4. Also, we are using our own open source rust libraries https://github.com/NordSecurity/libtelio https://github.com/NordSecurity/libdrop Maybe there is there a Debin Rust packaging team as well? Yes, there is Debian Rust packaging team [1]. According to the linked wiki page, Rust crate packaging is largely automated. If NordVPN depends on libdrop and libtelio, I would suggest starting from packaging them. [1] https://wiki.debian.org/Teams/RustPackaging Best wishes, Andrius
Re: Packaging a header-only library with frequent breaking changes
Hello, On 2023-01-17 15:04, David Kalnischkies wrote: I would suggest talking to maintainers of similar packages, they can probably give you more practical advice in this matter. I maintain a couple of similar header-only packages. Developers unwilling to provide stable API are a challenge, but usually not much can be done about it. I usually package such headers in libfoo-dev binary packages without versions in their names. Whenever a new upstream version arrives, I use ratt to rebuild all reverse dependencies to detect possible API breaks. If found, I bug the upstreams of such reverse dependencies to adjust to the API changes. Best, Andrius
Re: Processing uploads stalled?
Hi Hilmar, On 2022-12-19 20:36, Hilmar Preuße wrote: yesterday I uploaded latexml_0.8.7-1_source.changes to Debian FTP. Until now I just got the information that the package was received, no reject or accept. I requested a package rebuild (#1026239), which was approved, but the builders did not even start to work? Is there a general problem in package processing? See thread: https://lists.debian.org/debian-infrastructure-announce/2022/12/msg2.html Andrius
Re: Watch file github mode pointing to certain branch issue (Was: cmake help for minimac4 needed)
Hi Andreas, On 2022-10-27 12:37, Andreas Tille wrote: Am Thu, Oct 27, 2022 at 12:00:59PM +0300 schrieb Andrius Merkys: I have just pushed a fix. Please check if that works for you as well. Hmmm, this results in uscan info: Newest version of libomp-jonathonl on remote site is 0.0+git20181221.506f3e5, local version is 0.0+git20181221.506f3e5 while I would expect uscan info: Newest version of libomp-jonathonl on remote site is 0.0+git20211216.5228495, local version is 0.0+git20181221.506f3e5 since commit 5228495 is from 2021-12-16. Right, this does not seem correct... However, I am out of ideas about how to deal with this. Best wishes, Andrius
Re: Watch file github mode pointing to certain branch issue (Was: cmake help for minimac4 needed)
Hi Andreas, On 2022-10-27 11:31, Andreas Tille wrote: Unfortunately its not just omp but the latest commit from the development branch. Thus I tried gitmode[1] according to the docs: $ cat debian/watch version=4 opts="mode=git,gitmode=full,pgpmode=none,pretty=0.0+git%cd.%h" \ https://github.com/jonathonl/omp refs/heads/develop but I do not get any helpful result: $ uscan --verbose uscan info: uscan (version 2.22.2) See uscan(1) for help uscan info: Scan watch files in . uscan info: Check debian/watch and debian/changelog in . uscan info: package="libomp-jonathonl" version="0.0+git20181221.506f3e5-1" (as seen in debian/changelog) uscan info: package="libomp-jonathonl" version="0.0+git20181221.506f3e5" (no epoch/revision) uscan info: ./debian/changelog sets package="libomp-jonathonl" version="0.0+git20181221.506f3e5" uscan info: Process watch file at: debian/watch package = libomp-jonathonl version = 0.0+git20181221.506f3e5 pkg_dir = . uscan info: opts: mode=git,gitmode=full,pgpmode=none,pretty=0.0+git%cd.%h uscan info: line:https://github.com/jonathonl/omp refs/heads/develop uscan info: Parsing mode=git uscan info: Parsing gitmode=full uscan info: Parsing pgpmode=none uscan info: Parsing pretty=0.0+git%cd.%h uscan info: line:https://github.com/jonathonl/omp refs/heads/develop uscan warn: Tag pattern missing version delimiters () in debian/watch, skipping: https://github.com/jonathonl/omp refs/heads/develop uscan info: Scan finished Any idea what might went wrong? I have just pushed a fix. Please check if that works for you as well. Best, Andrius
Re: Free component in a non-free tarball
Hello, Thanks everyone for your answers! On 2022-08-30 21:39, Mattia Rizzolo wrote: > On Tue, Aug 30, 2022 at 12:00:39PM -0500, Ryan Pavlik wrote: >> The easiest way to do the tarball cleaning is with Files-Excluded in the >> copyright file, uscan will involve something (mkorigtargz?) that uses it to >> repack. That's a technical answer to the technical side of the question. > > Even better, probably: > > Files-Excluded: * > Files-Included: AmberTools I was not aware of Files-Included. This would greatly simplify repacking the tarball, provided policy/legal side permits. >> On the "policy"/legal question of whether it's permissible to package the >> internal open source in this larger source for the Debian project, I have >> no specific opinion but it sounds complicated. You might gauge upstream's >> feelings by asking if they can provide a tarball with just the open source >> parts. If not, even if your interpretation of the license situation is that >> you can package the inner code, it may not be worth it if it's fought by >> upstream. > > Exactly. > It wouldn't be the first time that we package something that the > original developers never intended to, only to find ourself in some sort > of passive-agressive situation, with some sort of hostile upstream. At > which point, I would wholeheartedly recommend you don't even start... > > Instead, if they are happy with you packaging this, they might just be > happy enough to extract AmberTools and distribute it in some nicer way > not requiring identification on a website… Asking upstream seems a good way to start. This is what I will do. Thanks again, Andrius
Re: Free component in a non-free tarball
Hi Niels, Thanks for prompt reply. On 2022-08-30 17:40, Niels Thykier wrote: > From the description you have provided, I would assume yes with the > following assumptions: > > 1) By "Extract AmberTools" you mean repackage the orig tarball. Yes, that is what I meant. > 2) AmberTools consists entirely of open sourced files that have a > compatible license. Probably it does, but I would double check that > no non-free files made their way into AmberTools. Absolutely. > (Plus of course that AmberTools does not Depend or Build-Depend on any > non-free components whether third-party or from ambermd.org) Right, this was implied. > For reference, I did not check the upstream site. ACK. Best, Andrius
Free component in a non-free tarball
Hello, I am looking into packaging AmberTools [1], suite of tools for molecular dynamics simulation. AmberTools is GPL, but it is shipped inside a tarball of a larger piece of software called Amber [2]. To get the tarball one has to put in their name and institution in a form [2], but there is no text implying agreeing with any licensing requirements or similar next to the "Download" button. In addition, details entered in the form are not stored in the downloaded tarball (otherwise checksums would not match). Inside the tarball, AmberTools are localized in AmberTools/ directory. Top-level README says: Except as noted below, Amber 22 is provided under a license that has restrictions on its use and redistribution. You should not use Amber 22 unless you have executed a license agreement with UCSF. Consult that license to see the provisions that apply. The files in the "AmberTools" subdirectory are covered by a separate, open source, license; see ./AmberTools/LICENSE for more information. My question: Is it OK to extract AmberTools from Amber tarball and package for Debian main? [1] https://ambermd.org/AmberTools.php [2] https://ambermd.org/GetAmber.php#ambertools Best, Andrius
Re: Handling upstream versioning scheme 2.40c >> 2.40b >> 2.40
Hi Mattia, On 2022-02-27 19:21, Mattia Rizzolo wrote: > On Wed, Feb 23, 2022 at 08:53:26AM +0200, Andrius Merkys wrote: >> The naming scheme could be adjusted to add '.' before the letter in >> version string (2.40c -> 2.40.c), but I cannot craft a watch file which >> could perform this. > > I'm not sure if that's the correct answer to your problem, but this > extra rule seems to work on src:c2x: > > uversionmangle=s#([a-z])$#\.\1# This worked, thanks a lot! Best wishes, Andrius
Handling upstream versioning scheme 2.40c >> 2.40b >> 2.40
Dear Mentors, I am maintaining package c2x, which has the following versioning scheme: 2.40c >> 2.40b >> 2.40 This is correct order as per 'dpkg --compare-versions'. However, if I add '+ds' repack suffix (I need to), the order becomes reversed. Thus 'uscan' behaves as expected because it knows how to remove the '+ds' suffix, but 'dpkg-genchanges' complains: dpkg-genchanges: warning: the current version (2.40c+ds-1) is earlier than the previous one (2.40+ds-1) The naming scheme could be adjusted to add '.' before the letter in version string (2.40c -> 2.40.c), but I cannot craft a watch file which could perform this. Any pointers are welcome. Best, Andrius
Re: Removing repositories from salsa.debian.org/debian
On 2021-09-24 16:14, Mattia Rizzolo wrote: > On Fri, Sep 24, 2021 at 03:16:34PM +0300, Andrius Merkys wrote: >> I have created repositories under salsa.debian.org/debian, and later >> pushed their contents to repositories in another group (I should have >> transferred instead). Could someone with appropriate privileges remove >> them?: > The process is to open a ticket in > https://salsa.debian.org/salsa/support Thanks for the pointer! Best, Andrius
Removing repositories from salsa.debian.org/debian
Hello, I have created repositories under salsa.debian.org/debian, and later pushed their contents to repositories in another group (I should have transferred instead). Could someone with appropriate privileges remove them?: debian/libemf2svg debian/libuemf Best, Andrius OpenPGP_signature Description: OpenPGP digital signature
Bug#979592: RFS: openrct2/0.3.3+ds-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
On 2021-03-25 20:47, Mathias Gibbens wrote: > Thank you Andrius! I appreciate the time you've taken to sponsor my > packages. > > I've pushed a signed tag to each repository. > > As new releases are made, or if there's any feedback from ftpmasters, > I'll contact you directly. Thank you Mathias for your contribution! Best, Andrius
Bug#979592: RFS: openrct2/0.3.3+ds-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
On 2021-03-25 03:07, Mathias Gibbens wrote: > On Wed, 2021-03-24 at 07:58 +0200, Andrius Merkys wrote: >> 3. Upstream copyright entry in debian/copyright lacks years. If the >> upstream do not limit their copyright in years, I usually take the >> year >> range spanning commits in the upstream Git repository (spotted in >> openrct2-objects). > > OK, I've done as you suggest and looked at the git history to put > some years in the d/copyright file. Looks good. Thanks! >> 4. In debian/rules of openrct2-title-sequences, there is a hard-coded >> upstream version of the package. This may easily get forgotten when >> packaging new upstream versions. I suggest replacing the hard-coded >> version with $(DEB_VERSION_UPSTREAM) from /usr/share/dpkg/pkg- >> info.mk, >> see [1] for example. > > That is indeed a nicer way to get the version. The upstream > developers have released a few revisions of the current "version" that > have a sequential letter appended, but the actual path for some of the > files doesn't have that extra letter in it. I've updated the shell > script so there's no longer a hard-coded value. I was about to suggest using sed to drop these sequential letters, but I see you already implemented this. >> You have indicated that you are going to be the sole maintainer for >> the >> packages, which is OK. But have you considered team-maintaining your >> packages in Debian Games Team? Team maintenance has its advantages, >> for >> example, team members would be able to commit and upload the packages >> fixing bugs and uploading new upstream versions. But of course the >> choice to team-maintain or not is yours. > > For now I'm planning to be the sole maintainer, but I'd be happy to > eventually transition to a team setup as well. Beyond just getting > openrct2 into Debian, I wanted to do all the work myself for the > learning experience, and after going through the process of releasing > updated versions as they become available once or twice, I'd be fine > with bringing things under a team umbrella. Sounds reasonable. In the meantime you may join the Debian Games Team if you have not done that before. >> [1] https://sources.debian.org/src/byteman/4.0.12-2/debian/rules/ > I uploaded new versions of all three packages to mentors.d.n, and > pushed corresponding commits with the changes to the repositories: > > > https://salsa.debian.org/gibmat/openrct2/-/commit/8bb65232c57b63c9ca18912772e4e78742a7cff7 > > https://salsa.debian.org/gibmat/openrct2-objects/-/commit/4e67cc2bac4b263c4a74c889923d2ba0e2f8effb > > https://salsa.debian.org/gibmat/openrct2-title-sequences/-/commit/8bbc6367390dd14e063fceb0a1346306eb30fdb5 > > If things are good, I believe the packages are ready. I've built them > locally for my buster system, and everything that I've tested is > working correctly. > > Also, once the packages are uploaded to NEW, I'll push a tag to each > repository to properly record which commit corresponds to the uploaded > version of each package. I have uploaded all three packages, and they have appeared in NEW. Please push git tags for the commits you have mentioned (I use 'gbp tag --sign-tags'), and let's wait for ftpmaster's response. As said earlier, let me know should you need later sponsoring of these packages. Best, Andrius
Bug#979592: RFS: openrct2/0.3.3+ds-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
owner 979592 ! owner 985806 ! owner 985807 ! thanks Hi Mathias, On 2021-03-24 03:47, Mathias Gibbens wrote: > retitle 979592 RFS: openrct2/0.3.3+ds-1 [ITP] -- Open-source > re-implementation of RollerCoaster Tycoon 2 > thanks > > I have uploaded a revised version of openrct2 to mentors.d.n: > >dget -x > https://mentors.debian.net/debian/pool/contrib/o/openrct2/openrct2_0.3.3+ds-1.dsc > > Packaging changes since my previous upload can be viewed on salsa: > https://salsa.debian.org/gibmat/openrct2/-/commit/5856cfd2595580d4873b71c4dbfa7955729ecebd > > I have also started two related RFS bugs for openrct2-objects and > openrct2-title-sequences: > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985806 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985807 I will happily sponsor all three packages. I have cloned out your packaging repositories and gave the packaging a look. There are a couple minor issues: 1. In debian/upstream/metadata, Bug-Database value has to be an URL. Most likely these will be GitHub issue trackers, in particular, links ending with '/issues' (spotted in openrct2-objects). 2. In debian/upstream/metadata, Bug-Submit value has unneeded '/choose' (spotted in openrct2-objects). 3. Upstream copyright entry in debian/copyright lacks years. If the upstream do not limit their copyright in years, I usually take the year range spanning commits in the upstream Git repository (spotted in openrct2-objects). 4. In debian/rules of openrct2-title-sequences, there is a hard-coded upstream version of the package. This may easily get forgotten when packaging new upstream versions. I suggest replacing the hard-coded version with $(DEB_VERSION_UPSTREAM) from /usr/share/dpkg/pkg-info.mk, see [1] for example. You have indicated that you are going to be the sole maintainer for the packages, which is OK. But have you considered team-maintaining your packages in Debian Games Team? Team maintenance has its advantages, for example, team members would be able to commit and upload the packages fixing bugs and uploading new upstream versions. But of course the choice to team-maintain or not is yours. [1] https://sources.debian.org/src/byteman/4.0.12-2/debian/rules/ Best, Andrius
Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
On 2021-03-23 02:08, Mathias Gibbens wrote: > On Tue, 2021-03-16 at 12:57 +0200, Andrius Merkys wrote: >> On 2021-03-15 19:28, Mathias Gibbens wrote: >>>> I have reviewed your packaging, and saw libcurl4-openssl-dev >>>> among >>>> the build dependencies. Do you know what does openrct2 need it >>>> for? >>>> My concern here is that in-game network access/downloads may >>>> interfere with Debian policies. >>> >>> Grepping through the code, it appears that openrct2 uses the >>> libcurl >>> dependency primarily in two places. The first is to automatically >>> download missing objects referenced in a scenario or save game. >>> There's >>> a vibrant community of openrct2 fans who create custom scenery >>> objects, >>> and it looks like this is a helper to fetch missing custom objects. >>> I've not gotten into this aspect of the game, so I haven't >>> personally >>> used it. The second place libcurl is used is in support of >>> multiplayer >>> connection making. >>> >>> Both of these only happen when the end-user is running the >>> program, >>> so I think that shouldn't run afoul of Policy. (I know network >>> access >>> during build is verboten, which is why there's an >>> override_dh_auto_configure in d/rules and corresponding component >>> source tars [more below].) >> >> Thanks for checking this out. Both use cases are indeed not violating >> the policy. >> >> However, we need to make sure the downloader for missing objects >> knows >> the right place to put them. It must not attempt writing outside >> user's >> home directory. > > Yes, by default openrct2 places all config, save games, objects, etc > in ~/.config/OpenRCT2/. It also respects the XDG_CONFIG_HOME > environment variable. Good then. Thanks for confirming. >>>> I fail to build the package as of >>>> e6e4103971b570a179ef5a59a709c24b2fcc5d68 on clean sid chroot with >>>> the >>>> following error log (only the last lines): >>>> >>>> [snip] >>>> >>>> Any ideas what might have gone wrong? >>> >>> This is the first package I've created that contains multiple >>> upstream tarballs as described in uscan(1). The normal openrct2 >>> build >>> downloads a handful of pre-generated metadata (the "objects" >>> component >>> tarball) and custom scenarios for the opening sequence (the "title- >>> sequences" component tarball) at build time, but we can't do that >>> in >>> Debian. So I added them as additional sources. The error you're >>> seeing >>> indicates that for some reason they aren't being properly extracted >>> into the source directory prior to starting the build. >> >> Indeed, this must be the problem on my side, due to incorrectly >> created >> upstream tarball. I admit I know very little about multiple upstream >> tarballs (MUTs). >> >> However, in this case it looks like the split of the MUT to >> individual >> source packages would make sense. They seem to have version numbers >> on >> their own, and I notice no signs in them being released in a >> lockstep. >> For example, it might happen that at some point objects or >> title-sequences are released more often that the main game, and >> bumping >> Debian version of the MUT just to update the components will become >> tedious. What do you think about splitting? > > It would certainly be easy enough to split the components out into > three distinct source packages: > > openrct2 > openrct2-objects > openrct2-title-sequences > > And then have openrct2 depend on the other two to properly bring in > all the required bits of the program. I would suggest exactly the same. > I set things up using MUTs to try to reflect upstream's build process > as closely as possible, but as you point out having three distinct > packages will allow more flexibility when updating in the future. > > My only question would be if having three different packages would > make the RFS process any harder, and if I should then file two more RFS > bugs for the two new source packages. I do not think this would make RFS process any harder. As the releases of these three packages do not happen in a lockstep, you would probably want to upload the MUT whenever any of them is released anyway. MUT might save extra RFSes in case of simultaneous release, but I do not think this is worth optimizing for. In practice, instead of filing RFSes I used to ping my initial sponsor(s) with a list of packages I want to get uploaded. RFS is a formal request, but I see people directly mailing packaging teams with requests for uploads. And maybe at some point you will become a DD and will be able to upload packages yourself. > Thanks for helping me build a better package(s)! Thank you for working on openrct! Best wishes, Andrius
Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
Hi Mathias, On 2021-03-15 19:28, Mathias Gibbens wrote: >> I have reviewed your packaging, and saw libcurl4-openssl-dev among >> the build dependencies. Do you know what does openrct2 need it for? >> My concern here is that in-game network access/downloads may >> interfere with Debian policies. > > Grepping through the code, it appears that openrct2 uses the libcurl > dependency primarily in two places. The first is to automatically > download missing objects referenced in a scenario or save game. There's > a vibrant community of openrct2 fans who create custom scenery objects, > and it looks like this is a helper to fetch missing custom objects. > I've not gotten into this aspect of the game, so I haven't personally > used it. The second place libcurl is used is in support of multiplayer > connection making. > > Both of these only happen when the end-user is running the program, > so I think that shouldn't run afoul of Policy. (I know network access > during build is verboten, which is why there's an > override_dh_auto_configure in d/rules and corresponding component > source tars [more below].) Thanks for checking this out. Both use cases are indeed not violating the policy. However, we need to make sure the downloader for missing objects knows the right place to put them. It must not attempt writing outside user's home directory. >> I believe uploads to unstable are discouraged only for packages >> already in testing, so targeting unstable here should be OK. > > OK, I've switched back to unstable and staged it locally. I'll bundle > that with any other changes that come from the package review process > before openrct2 gets uploaded to NEW. Good, thanks. >> I fail to build the package as of >> e6e4103971b570a179ef5a59a709c24b2fcc5d68 on clean sid chroot with the >> following error log (only the last lines): >> >> [snip] >> >> Any ideas what might have gone wrong? > > This is the first package I've created that contains multiple > upstream tarballs as described in uscan(1). The normal openrct2 build > downloads a handful of pre-generated metadata (the "objects" component > tarball) and custom scenarios for the opening sequence (the "title- > sequences" component tarball) at build time, but we can't do that in > Debian. So I added them as additional sources. The error you're seeing > indicates that for some reason they aren't being properly extracted > into the source directory prior to starting the build. Indeed, this must be the problem on my side, due to incorrectly created upstream tarball. I admit I know very little about multiple upstream tarballs (MUTs). However, in this case it looks like the split of the MUT to individual source packages would make sense. They seem to have version numbers on their own, and I notice no signs in them being released in a lockstep. For example, it might happen that at some point objects or title-sequences are released more often that the main game, and bumping Debian version of the MUT just to update the components will become tedious. What do you think about splitting? > I personally use lxc containers which I can quickly spin up to get a > clean minimal build environment, and the following commands build the > openrct2 package for me: > >dget -x > https://mentors.debian.net/debian/pool/main/o/openrct2/openrct2_0.3.3+dfsg-1.dsc > dpkg-source -x openrct2_0.3.3+dfsg-1.dsc > cd openrct2-0.3.3+dfsg/ > debuild > > I know there's several additional tools for building packages (like > pbuilder), but I haven't really had a strong need to get those working > due to my use of lxc. I see. I have no knowledge about lxc builder, but somehow I imagine that it should have the same build sequence. Best, Andrius
Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
Hi again, I fail to build the package as of e6e4103971b570a179ef5a59a709c24b2fcc5d68 on clean sid chroot with the following error log (only the last lines): find ./debian -name libopenrct2.a -delete find ./debian -empty -type d -delete make[1]: Leaving directory '/<>' dh_install dh_install: warning: Cannot find (any matches for) "objects/*" (tried in ., debian/tmp) dh_install: warning: openrct2-data missing files: objects/* dh_install: warning: Cannot find (any matches for) "title-sequences/*" (tried in ., debian/tmp) dh_install: warning: openrct2-data missing files: title-sequences/* dh_install: error: missing files, aborting make: *** [debian/rules:8: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Any ideas what might have gone wrong? Best, Andrius
Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
Hi Mathias, Thank you for an interesting ITP. It would be nice to have openrct2 in Debian. I have reviewed your packaging, and saw libcurl4-openssl-dev among the build dependencies. Do you know what does openrct2 need it for? My concern here is that in-game network access/downloads may interfere with Debian policies. On 2021-03-13 20:21, Mathias Gibbens wrote: > Upstream released v0.3.3 earlier today, and I have updated my > packaging accordingly. Additionally, I updated the distribution to > experimental, as the bullseye freeze is in full swing. I believe uploads to unstable are discouraged only for packages already in testing, so targeting unstable here should be OK. Best, Andrius
Re: Does 32-bit arithmetic overflow mean arch incompatibility?
Hi Robin, On 2021-01-29 23:56, Robin Gustafsson wrote: > Does the possibility of arithmetic overflow on 32-bit systems mean > that the software is to be considered incompatible with 32-bit > architectures? > > A package I'm working on has some test failures on 32-bit due to > overflows. I only maintain architecture-independent packages and I'm > not sure how this scenario would usually be treated. I would say yes. The upstream most likely would confirm that. Best, Andrius
Re: Bug#957665: Fortran issue in paw (Was: paw: ftbfs with GCC-10)
Hi Andreas, On 2020-10-15 15:26, Andreas Tille wrote: > when trying to build paw with gcc / fortran 10 there are some FORTRAN > errors: > > > ... > Error: Type mismatch between actual argument at (1) and actual argument at > (2) (COMPLEX(4)/INTEGER(4)). > /<>/src/pawlib/comis/code/cs1200.F:138:24: > >76 | CALL CCOPYA(KOD(IPCP),KOD(IPCP+I),L) > |2 > .. > 138 | CALL CCOPYA(CX,KOD(IPCP-1),KLCMLX) > |1 I had the same problem with libccp4. Upstream has recommended turning off argument mismatch checks via FFLAGS, which I did in debian/rules [1]: FFLAGS += -fallow-argument-mismatch Of course this just silences the error, which should probably be fixed, especially if argument mismatch is not intentional. [1] https://salsa.debian.org/science-team/libccp4/-/commit/985597f71ee539e7e3242d43a60b271865e7672e Hope this helps, Andrius
Bug#971594: RFS: asciidoc/9.0.2-1 [ITA] -- Highly configurable text format for writing documentation
Hi Leon, On 2020-10-02 14:40, Leon Marz wrote: >* Remove vim-asciidoc (Closes: #954780) >* Remove asciidoc-base as it is unnecessary >* Put files from asciidoc-base to asciidoc >* Remove asciidoc-doc as there are no real docs So it seems that three binary packages are being dropped. Does this mean no other packages in main depend on them? Thanks, Andrius
Re: libdatetime-perl BD-Uninstallable although dependency is satisfied (?)
On 2020-08-25 10:48, Andrey Rahmatullin wrote: > On Tue, Aug 25, 2020 at 10:39:50AM +0300, Andrius Merkys wrote: >> Buildd status page for libdatetime-perl [1] says that on kfreebsd-* its >> build dependencies are uninstallable, citing the following dependency >> tree (for kfreebsd-amd64, for example): >> >> libdatetime-perl build-depends on: >> - libdatetime-locale-perl:kfreebsd-amd64 (>= 1:1.06) >> libdatetime-locale-perl depends on: >> - libnamespace-autoclean-perl:kfreebsd-amd64 >> libnamespace-autoclean-perl depends on: >> - libnamespace-clean-perl:kfreebsd-amd64 >> libnamespace-clean-perl depends on: >> - libsub-name-perl:kfreebsd-amd64 >> libsub-name-perl depends on missing: >> - perlapi-5.28.1:kfreebsd-amd64 >> >> libdatetime-locale-perl 1:1.26-1 is in unstable as arch:all, thus I do >> not understand how can it be uninstallable. > A package can be present in unstable yet be uninstallable, or what do you > mean? I didn't check if perlapi-5.28.1:kfreebsd-amd64 is indeed > unavailable but it seems like a valid reason. Indeed, libsub-name-perl:kfreebsd-amd64 was built in unstable using perl, but since then perl FTBFS on kfreebsd-amd64, thus libsub-name-perl:kfreebsd-amd64 is uninstallable. Thanks for pointing out! Andrius
libdatetime-perl BD-Uninstallable although dependency is satisfied (?)
Hello, Buildd status page for libdatetime-perl [1] says that on kfreebsd-* its build dependencies are uninstallable, citing the following dependency tree (for kfreebsd-amd64, for example): libdatetime-perl build-depends on: - libdatetime-locale-perl:kfreebsd-amd64 (>= 1:1.06) libdatetime-locale-perl depends on: - libnamespace-autoclean-perl:kfreebsd-amd64 libnamespace-autoclean-perl depends on: - libnamespace-clean-perl:kfreebsd-amd64 libnamespace-clean-perl depends on: - libsub-name-perl:kfreebsd-amd64 libsub-name-perl depends on missing: - perlapi-5.28.1:kfreebsd-amd64 libdatetime-locale-perl 1:1.26-1 is in unstable as arch:all, thus I do not understand how can it be uninstallable. I assume that buildd reevaluates BD-Uninstallable packages from time to time, but please let me know if I am wrong here. [1] https://buildd.debian.org/status/package.php?p=libdatetime-perl&suite=sid Best, Andrius
Re: Package not migrating due to missing build on i386, but i386 is excluded
On Fri, 20 Dec 2019, 12:30 Andrey Rahmatullin, wrote: > Thet testing package is built on i386. If you are no longer building it on > that arch, you need to file a bug to remove the i386 binary from testing. > Thanks for explanation! Best, Andrius
Package not migrating due to missing build on i386, but i386 is excluded
Hello, stringtie [1] is not migrating due to missing build on i386, although this arch is excluded from the arch list for the package. The delay is over. Is this transient, or is there a problem? Cheers, Andrius [1] https://tracker.debian.org/pkg/stringtie
Re: Removing incorrect upload from NEW
Hi Adam, On 2019-05-16 12:49, Adam Borowski wrote: > Once the package has been taken for NEW, it's out of your reach, and you > need to ask for a REJECT. Thanks for advice, I will turn to FTP people. Best, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Removing incorrect upload from NEW
Dear Mentors, I have recently uploaded incorrect package to the NEW (gversion-plugin_1.5.0-1_amd64.changes, should have been a repacked DFSG-compliant version). I would like to remove the incorrect upload from NEW and dput the right package. Neither of the following works for me: dcut cancel -f gversion-plugin_1.5.0-1_amd64.changes dcut rm -f 'gversion-plugin_1.5.0*' -f libgradle-gversion-plugin-java_1.5.0-1_all.deb Thanks in advance, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: Configure your PC to contribute to Debian community
Hi Vipul, On 2019-05-08 18:12, Vipul wrote: > Is there a way to get isolation for work & contribution purpose to > keep yourself organized? I personally run a VirtualBox VM with Debian unstable. I find this alternative to chroots more convenient for debugging. And snapshot feature of VirtualBox allows for reverting the system in case one inadvertently breaks it. Best, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#923683: RFS: python-pynetstring/0.1~dev2+git20180925.40cd4a61-1 [ITP] -- netstring library for Python 3
Hi Benjamin, thanks for updating the package. On 2019-04-28 21:02, Benjamin Hof wrote: > I am aware and my preference would be for vcs-git to be created by the > sponsor on salsa first (or be set to a different value). OK, this makes sense. > I figured out a way to deal with the version-but-no-tag situation and > uploaded a new package. Great! Two more things: 1. autopkgtest is unable to find and execute tests (you can see it from the output of 'autodep8'). It might be necessary to craft ad-hoc autopkgtest to invoke 'python3 setup.py test' without building the package. 2. It would be best to maintain your package together with Debian Python Modules Team [1]. See [2] on how to join the team and make your package team-maintained. Otherwise the package seems fine. Best wishes, Andrius [1] https://wiki.debian.org/Teams/PythonModulesTeam [2] https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: Need help with uscan
Hi Alex, On 2019-04-25 15:51, Alex Mestiashvili wrote: > have you found a solution? > I managed to craft the following d/watch: [snip] Thanks, I have already managed to put together something very similar, which also works fine. Best, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: Need help with uscan
Hi Paul, On 2019-04-25 04:09, Paul Wise wrote: > uscan now supports arbitrary mangling of the page HTML using the > pagemangle option. This combined with the downloadurlmangle option > could easily accommodate this website. Thanks for the directions. I will check this out. > I think that would be a workaround and the real fix is to talk > upstream into importing their code into a VCS and producing properly > signed and tagged releases (with signed versioned tarballs). Indeed. I will contact the upstream, but for the time being I'd like to have even this temporary solution. Best wishes, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: Need help with uscan
Hi Ben, On 2019-04-25 03:59, Ben Finney wrote: > So, for an upstream source tarball with timestamp “2013-03-12T12:16”, > mangle that to the version string “0+2013.03.12.12.16” (and hence the > first Debian release of that upstream source has the Debian package > version string “0+2013.03.12.12.16-1”). I was going for exactly this upstream version format. Thanks for the detailed description! Best wishes, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Need help with uscan
Hello, I want to package unversioned source. AFAIK, it should be possible to have timestamp of the last tarball change in lieu of upstream version. I am wondering if it would be possible to write uscan rules to extract the timestamp and download the upstream tarball by analyzing the following HTML excerpt (taken from [1]): reference-structures.tar.gz2013-03-12 12:16 6.4M where the "reference-structures.tar.gz" is the tarball I want and "2013-03-12" is the timestamp. Thanks in advance, Andrius [1] https://www2.mrc-lmb.cam.ac.uk/personal/pemsley/coot/dependencies/ -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: Updating a package & BTS
Hi, On 2019-04-19 16:21, Tong Sun wrote: > Oh, this is just a hypothetical question -- upstream release a new > version, and I want to repack/update my package, do I have to log a > bug in BTS, or it is OK to just update my package without a BTS#, then > send the RFS request? No, ITP bug number is required only for the initial version of the package. Best, Andrius
Bug#923683: RFS: python-pynetstring/0.1~dev2+git20180925.40cd4a61-1 [ITP] -- netstring library for Python 3
Hello,
while I am unable to sponsor your package, I have some comments that
might help improving it:
1. There are lintian errors. It seems that you have "UNRELEASED" target
in your debian/changelog. A finalized package should point to "unstable".
2. The debian/watch file is missing. As the source of the package is
hosted on GitHub, this should not be difficult to generate. Please see
'man uscan' for examples.
3. It would be wise to maintain this package together with the Debian
Python Modules Team [1].
By the way, just curious. Package python-tnetstring ("typed netstring")
is already in Debian. What is the difference between python-tnetstring
and python3-tnetstring? Are these packages related/overlap somehow?
Best wishes,
Andrius
[1] https://wiki.debian.org/Teams/PythonModulesTeam
--
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania
Re: Backwards-incompatible ABI change due to function rename
On 2019-03-04 16:56, Adam Borowski wrote: > But, are they actually available from the published API? Yes, they are; readelf --symbols prints them. > And do reverse dependencies use those functions? Not that I am aware of. The renamed functions were introduced for the development only. Thanks, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: Backwards-incompatible ABI change due to function rename
On 2019-03-04 13:32, Andrey Rahmatullin wrote: > What does the upstream say about this? The upstream says that the renamed functions are not documented, therefore they are private-ish. However, strictly speaking these functions are public, as they are accessible in the ABI. > The ideal way would be bumping the soname (or restoring the removed > names) upstream. I will check with the upstream. Thanks, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania signature.asc Description: OpenPGP digital signature
Backwards-incompatible ABI change due to function rename
Dear Mentors, I am maintaining a package which has recently endured a backwards-incompatible ABI change due to a couple of function renames. I could restore the ABI compatibility by providing aliases (via patches) for the renamed functions. My question is: would this be a viable solution, or should I change the SONAME? Best, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#923162: RFS: python-rfid/1.2 [ITP] -- friendly greeter
On 2019-02-28 18:35, Andrey Rahmatullin wrote: > I can't call this "the usual practice". The usual practice is publishing a > repo that allows building a Debian package but we don't require that. The > usual practice is publishing it on salsa but we don't require that either. > As for the repo contents, the usual practice is a branch with upstream > sources merged into a branch with upstream sources + debian. And when you > publish a packaging repo it should be an useful packaging repo and not > just something on salsa. Indeed. I was too quick to summarize here. Best, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania signature.asc Description: OpenPGP digital signature
Bug#923162: RFS: python-rfid/1.2 [ITP] -- friendly greeter
Hi Philipp, thanks for fixing the package. Please find my comments below. On 2019-02-28 15:35, Philipp Meisberger wrote: > thanks for your remarks, especially "pybuild". Really simple now. Sure, > removing files from "/usr/local/" was a fix for an ancient previous > version. I removed it. I also tried to fix all Lintian warnings. Great! It seems much cleaner now. > I am > not very familiar with all RFID protocols. So I cannot say EM4100 is > popular or not. I agree, that "python-em4100" would be a better package > name, but I maintain the project since 2014. So if the name changes > there must be at least the virtual package "python-rfid". Understood. Please notice that as "python-rfid" is not in Debian yet, there is no need for virtual packages there. Nevertheless I agree that it's better to have package's name as close to the upstream's name as possible. > I also heard, that Python 2 will be superseded completely by Python 3 > this year. What is your opinion about the Python 2 package? Is it still > necessary? It's true that Python 2 is going away soon. I suggest dropping Python 2 package it in favor for Python 3. Some additional remarks: 1. Please separate the packaging of your project (the src/debian/ directory) and place it in a packaging repository on salsa.debian.org. This is the usual practice now. 2. I see that the debhelper compatibility level and Standards-Version are outdated. Can you bump them to 12 and 4.3.0, accordingly? 3. Your package build-depends on python3. It isn't necessary, as dh-python brings it with itself. 4. Please add ITP bug number to your debian/changelog. 5. Is doc/RDM6300_doc.pdf your own creation, or taken from somewhere else? In the latter case, please take into consideration possible licensing restrictions on its usage. Let me know should you need any help. Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania signature.asc Description: OpenPGP digital signature
Re: Looking for a mentor -- multiscale molecular modeling package MMB (and molmodel)
Hi Samuel, On 2019-02-26 18:27, Samuel Flores wrote: > I would like some help packaging MacroMoleculeBuilder (MMB) for distribution > in Debian or Ubuntu. It is a mature piece of code, used to publish many > scientific articles in structural bioinformatics and structural and molecular > biology. It has been downloaded thousands of times. I would gladly help with the packaging of this modeling tool. > I would be happy to change MMB's license to be compatible with this process. You are absolutely right to start with the license check. Debian accepts only those licenses that are compatible with Debian Free Software Guides [1]. You can find (incomplete) list of DFSG-compatible licenses here [2]. [1] http://www.debian.org/social_contract#guidelines [2] https://wiki.debian.org/DFSGLicenses > MMB requires OpenMM, simbody, and SeqAn, I believe all of these are already > packaged. It also requires SimTK molmodel which is not packaged -- I am the > maintainer of molmodel and would like to package this as well. Molmodel is > not hard to compile, but it does use cmake. OpenMM and molmodel are not yet in Debian, AFAIK. Thus they have to be packaged before the MMB. To start with, I would suggest reading the introduction to packaging [3], as Andrey has advised. [3] https://mentors.debian.net/intro-maintainers Best wishes, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#923162: RFS: python-rfid/1.2 [ITP] -- friendly greeter
Hi Philipp, On Sun, 24 Feb 2019 17:16:16 +0100 Philipp Meisberger wrote: > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/python-rfid I gave your package a look and wrote some comments on the mentors.d.n (not sure if you are subscribed to notifications there, thus a ping). While the package seemingly builds and installs fine, there are some things that need to be fixed to make your package acceptable in Debian. Best wishes, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#910004: RFS: apache-opennlp/1.9.0-1 [ITP] -- machine learning based toolkit for the processing of natural language text
On 2019-02-12 04:58, Mo Zhou wrote: > Uploaded to unstable/NEW. Thanks a lot for sponsoring! > Please note that this package enters the NEW > queue too late, so it got no chance to enter Buster. Not a problem, I will be happy to have it sooner or later. Best regards, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#910004: RFS: apache-opennlp/1.9.0-1 [ITP] -- machine learning based toolkit for the processing of natural language text
On 2019-02-09 15:12, Mo Zhou wrote: > Why did you stopped maintaining this package here?: > https://salsa.debian.org/science-team/apache-opennlp Oh, I completely forgot about this. I have now switched from 'merkys-guest' (to be closed soon) to 'science-team' and pushed all commits here. > And I suggest you apply this patch to debian/control: Done, thanks. > The rest looks good to me. Please resolve the remaining issues > and I'll sponsor this package for you. Thank you! Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#910004: RFS: apache-opennlp/1.9.0-1 [ITP] -- machine learning based toolkit for the processing of natural language text
On 2019-02-08 04:08, Mo Zhou wrote: > Is this package useful enough without these components? I would say so. opennlp-tools is the core toolkit of the OpenNLP, while opennlp-brat-annotator and opennlp-morfologik-addon are merely add-ons to other software packages. Furthermore, language parsing and language detection examples execute successfully after having all binary packages installed, both using the CLI and Java compiler. Therefore, I assume that core functionality works as would be expected. Best wishes, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#910004: RFS: apache-opennlp/1.9.0-1 [ITP] -- machine learning based toolkit for the processing of natural language text
On 2019-02-05 03:49, Mo Zhou wrote: > However I guess you didn't install all the opennlp components: Indeed; this is intentional: > opennlp-brat-annotator > opennlp-distr > opennlp-docs > opennlp-morfologik-addon these components fail to build due to missing dependencies in Debian. For now I have listed them in d/todo list. > Besides, there are also some wrapper scripts under several directories. > Are they omitted intentionally? I overlooked these, thanks for pointing them out. I have added a new binary package 'opennlp' containing the wrapper script from opennlp-distr/src/main/bin/opennlp (opennlp-tools/bin/opennlp does quite the same, albeit using maven for execution). Best, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#910004: RFS: apache-opennlp/1.9.0-1 [ITP] -- machine learning based toolkit for the processing of natural language text
Hi Mo Zhou, On 2019-02-02 10:26, Mo Zhou wrote: > Thank you for the effort on apache-opennlp packaging. However it failed > to build (I cannot help you diagnose the failure because I know nothing > about Java): I have just fixed the issue. > BTW, 1.9.1 release is available. Updated. Could you please try building the package once more? Best wishes, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#910004: RFS: apache-opennlp/1.9.0-1 [ITP] -- machine learning based toolkit for the processing of natural language text
Hi Mo Zhou, thanks a lot for the interest in my RFS. At first glance the FTBFS issue seems to be related to #920020. I will investigate it further. Best wishes, Andrius [#920020] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920020 On Sat, 2 Feb 2019, 10:30 Mo Zhou control: tags -1 +moreinfo > > Hi Andrius, > > Thank you for the effort on apache-opennlp packaging. However it failed > to build (I cannot help you diagnose the failure because I know nothing > about Java): > > > http://debomatic-amd64.debian.net/distribution#unstable/apache-opennlp/1.9.0-1/buildlog > > BTW, 1.9.1 release is available. > >
Bug#919257: RFS: antlr4-cpp-runtime/4.7.2-1 [ITP] -- ANTLR Parser Generator - C++ runtime support
Package: sponsorship-requests Severity: normal Control: block 918109 by -1 Dear mentors, I am looking for a sponsor for my package "antlr4-cpp-runtime". Package is required to update mysql-workbench (#902798). * Package name: antlr4-cpp-runtime Version : 4.7.2-1 Upstream Author : Terence Parr * URL : http://www.antlr4.org * License : BSD-3-clause Section : libs It builds those binary packages: libantlr4-runtime-dev - ANTLR Parser Generator - C++ runtime support (development files) libantlr4-runtime4.7.2 - ANTLR Parser Generator - C++ runtime support (shared library) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/antlr4-cpp-runtime Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/antlr4-cpp-runtime/antlr4-cpp-runtime_4.7.2-1.dsc More information about antlr4-cpp-runtime can be obtained from https://www.example.com. Changes since the last upload: antlr4-cpp-runtime (4.7.2-1) unstable; urgency=medium * Initial release (Closes: #918109) -- Andrius Merkys Thu, 03 Jan 2019 03:14:46 -0500 Regards, Andrius Merkys -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: java: building interdependent artifacts with maven
Hi Andrej, I have seen your e-mail regarding morfologik, but I am not sure whether our issues are the same, though. In my case if I install the built opennlp-tools binary deb package, I am later able to build it with the opennlp-morfologik-addon successfully. (I could of course split them into separate source packages, but I wonder if there is a way to avoid it.) Have you tried building without morfologik-fsa-builders and installing built binary before build with morfologik-fsa-builders? Best, Andrius On Sun, 30 Dec 2018, 11:45 Andrej Shadura Hi Andrius, > > On Wed, 12 Dec 2018 at 10:30, Andrius Merkys > wrote: > > I am preparing a package for apache-opennlp [1]. Building it results in > six artifacts, one of them, > org.apache.opennlp:opennlp-morfologik-addon:jar:1.9.0, depends on another > artifact org.apache.opennlp:opennlp-tools:jar:debian which is built before > the former. However, opennlp-tools is not found by > opennlp-morfologik-addon, possibly because it is not installed in local > maven-repo, nor placed in CLASSPATH: > > > > [ERROR] Failed to execute goal on project opennlp-morfologik-addon: > Could not resolve dependencies for project > org.apache.opennlp:opennlp-morfologik-addon:jar:1.9.0: Cannot access > apache.snapshots (http://repository.apache.org/snapshots) in offline mode > and the artifact org.apache.opennlp:opennlp-tools:jar:debian has not been > downloaded from it before. -> [Help 1] > > > > Is there a standard way to deal with such problem? > > I also ran into this issue trying to update morfologik itself, and I > have so far been unable to find a solution. > > -- > Cheers, > Andrej >
java: building interdependent artifacts with maven
Dear Mentors, I am preparing a package for apache-opennlp [1]. Building it results in six artifacts, one of them, org.apache.opennlp:opennlp-morfologik-addon:jar:1.9.0, depends on another artifact org.apache.opennlp:opennlp-tools:jar:debian which is built before the former. However, opennlp-tools is not found by opennlp-morfologik-addon, possibly because it is not installed in local maven-repo, nor placed in CLASSPATH: [ERROR] Failed to execute goal on project opennlp-morfologik-addon: Could not resolve dependencies for project org.apache.opennlp:opennlp-morfologik-addon:jar:1.9.0: Cannot access apache.snapshots (http://repository.apache.org/snapshots) in offline mode and the artifact org.apache.opennlp:opennlp-tools:jar:debian has not been downloaded from it before. -> [Help 1] Is there a standard way to deal with such problem? Best regards, Andrius [1] https://salsa.debian.org/merkys-guest/apache-opennlp -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#910004: RFS: apache-opennlp/1.9.0-1 [ITP] -- machine learning based toolkit for the processing of natural language text
Package: sponsorship-requests Severity: wishlist Control: block 909501 by -1 Hello, I am looking for a sponsor for my package "apache-opennlp". * Package name: apache-opennlp Version : 1.9.0 Upstream Author : The Apache Software Foundation * URL : https://opennlp.apache.org * License : Apache-2.0 Programming Lang: Java Description : machine learning based toolkit for the processing of natural language text It builds these binary packages: libapache-opennlp-java - machine learning based toolkit for the processing of natural language text The Apache OpenNLP library is a machine learning based toolkit for the processing of natural language text. It supports the most common NLP tasks, such as tokenization, sentence segmentation, part-of-speech tagging, named entity extraction, chunking, parsing, and coreference resolution. These tasks are usually required to build more advanced text processing services. OpenNLP also included maximum entropy and perceptron based machine learning. The package is not in the Mentors (due to #901025). The packaging is done in Salsa repository [1] and can be reviewed there. I plan to maintain the package inside either the Debian Science or Debian Java teams, whichever seems more appropriate. [1] https://salsa.debian.org/merkys-guest/apache-opennlp -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#903904: RFS: wannier90/2.1.0 -- maximally localized Wannier functions
Hello Miroslav, thank you for the advice. Clean environment is surely beneficial, as I often run into such dependency problems. Best wishes, Andrius On 09/19/2018 09:01 AM, Miroslav Kravec wrote: > for testing dependencies of package, virtual machine is useful. I use VBox, > and create snapshot after clean install, plus base environment setup (ssh > key, VBox additions), but no other extra packages. Then, I can restore > snapshot and see what needs to be installed, and also I can test build on > almost clean install of system. -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#903904: RFS: wannier90/2.1.0 -- maximally localized Wannier functions
Hi Adam, On 09/17/2018 12:12 PM, Adam Borowski wrote: > ! LaTeX Error: File `subfigure.sty' not found. seems to a missing dependency again. This time I've tried dropping all texlive-* packages to detect ones needed. Could you please pull and try it one more time? Many thanks, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#903904: RFS: wannier90/2.1.0 -- maximally localized Wannier functions
Hi Adam, many thanks for spotting these problems! On 09/16/2018 12:31 AM, Adam Borowski wrote: > 1. The copyright file claims GPL-2+ with no authors outside "2017 Wannier > Developers' Group", yet I see at least test-suite/testcode being: > "Copyright (c) 2012 by James Spencer", license: BSD. I have overlooked this. Included now, as well as a bunch of other files. > 2. The package fails to build: > > ! LaTeX Error: File `ulem.sty' not found. I have missed one of texlive-* packages. Added now. Would you mind to pull and build it again? Thanks, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: Formal definitions of Provides and Replaces
Hello,
On 09/06/2018 07:12 AM, Russ Allbery wrote:
> As part of that transition, it looks like exactly what you said
> ("adaptation and rebuilding of all packages depending on blacs-mpi") was
> done for the packages in Debian.
many thanks for the explanation. I was not aware of #886711, thanks for
pointing it out to me. Surprisingly, espresso hasn't received a ping about the
transition or the bug, that's why it took so long for me to find out the reason.
Thanks again,
Andrius
--
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania
Re: Formal definitions of Provides and Replaces
Hi Paul, On 09/02/2018 12:44 PM, Paul Wise wrote: > The fields are defined in Debian Policy: > > https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides > https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces thanks for pointing this out. I was quite surprised that Provides/Replaces does not formally require the providing/replacing binaries to completely cover provided/replaced binaries. The reason I'm asking is the removal of binaries of blacs-mpi, which is indicated as provided/replaced by scalapack now. However, scalapack's libraries have other sonames, what requires adaptation and rebuilding of all packages depending on blacs-mpi. I have spent quite some time to figure this out when packaging espresso. Isn't this a bug in scalapack? Best wishes, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Formal definitions of Provides and Replaces
Dear Mentors, I fail to find the formal definitions (regarding API/ABI and files) of Provides and Replaces fields of d/control, could someone point it out to me please? In particular, if package A Provides/Replaces B, does that mean that A MUST have the same API/ABI and files as B? Many thanks, Andrius
Re: Debian package without VCS
Hi Andrey, On 08/30/2018 09:49 AM, Andrey Rahmatullin wrote: > The maintainer should do that. thanks for the explanation. I had the same feeling, though. Best, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania signature.asc Description: OpenPGP digital signature
Re: Debian package without VCS
Hi Muri, On 08/30/2018 09:23 AM, Muri Nicanor wrote: > There is an open ITP (#905853) for tao-pegtl-dev from bisco, who offered > to package the new and upcoming releases (upstream renamed the package > and changed the path of the header files, see the ITP for details). thanks for pointing this out! I was unaware of the new ITP, I will give it a look. Best, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Debian package without VCS
Dear Mentors, I have stumbled upon a source package 'pegtl', whose binary is in Debian, but the packaging files aren't on salsa.d.org. Moreover, d/control contains no VCS information. I would be happy to update the package to the newest upstream release. My questions: 1) I want package's source on salsa.d.org. Should I create a new repo on salsa.d.org and import 'pegtl' there with 'gbp import-dsc'? 2) The package is not maintained by any team (cc'ing Muri Nicanor, the maintainer of 'pegtl'). Am I allowed to even touch it? Best wishes, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#907456: RFS: pslibrary/1.0.0-1 [ITP] -- library of ultrasoft and PAW pseudopotentials
Package: sponsorship-requests Severity: wishlist Control: block 907412 by -1 Hello, I am looking for a sponsor for my package "pslibrary". * Package name: pslibrary Version : 1.0.0 Upstream Author : Andrea Dal Corso * URL : https://dalcorso.github.io/pslibrary/ * License : GPL-2+ Description : library of ultrasoft and PAW pseudopotentials It builds these binary packages: pslibrary - library of ultrasoft and PAW pseudopotentials PSlibrary is a library of scalar relativistic and fully relativistic PAW data sets and ultrasoft pseudopotentials for many elements in Unified Pseudopotential Format (UPF). UPFs can be used at least by Quantum ESPRESSO, Abinit and GPAW. PSlibrary paper [1] is widely cited (with ~60 citations during year 2018) [2]. The binary package consists of pseudopotentials built using Quantum ESPRESSO from upstream-supplied inputs, resulting in ~3 GB of pseudopotential files (~700 MB when compressed). The package is not in the Mentors (due to #901025). The packaging is done in Salsa repository [3] at and can be reviewed there. I plan to maintain the package inside the DebiChem team. [1] http://authors.elsevier.com/sd/article/S0927025614005187 [2] https://scholar.google.lt/scholar?as_ylo=2018&hl=en&as_sdt=2005&sciodt=0,5&cites=8672732540737765863&scipsc= [3] https://salsa.debian.org/merkys-guest/pslibrary <https://salsa.debian.org/science-team/wannier90> -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: Source repackaging workflow with git-buildpackage
On 07/18/2018 02:00 PM, Andrey Rahmatullin wrote: > Well, it's only for this version, as in the future you won't have > non-repacked tarballs in the repo? True indeed, it's just for this version. For new upstream releases uscan will work as expected. Thanks, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania signature.asc Description: OpenPGP digital signature
Re: Source repackaging workflow with git-buildpackage
On 07/18/2018 11:49 AM, gregor herrmann wrote: > Cf. also https://perl-team.pages.debian.net/howto/repacking.html Thanks, this link explains how the d/watch should look like. > I guess uscan needs --force-download (--force also works IME); not > sure if you can pass this via gbp-import-orig or if you need a manual > (1) uscan + (2) 'gbp import-orig --pristine-tar your-new-tarball'. Exactly, 'gbp import-orig --uscan' does not accept '--force'. Thus I'll probably have to use 'uscan' + 'gbp import'. I expected a single-command solution, alas. Many thanks, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Source repackaging workflow with git-buildpackage
Dear Mentors, I want to remove some files from upstream tarball foo-1.23 (already in Debian) to produce foo-1.23+ds using git-buildpackage following the recipe posted here [1]. I have added Files-Excluded stanza to d/copyright and added ' opts="repacksuffix=+ds,dversionmangle=s/\+ds//,repack"' to d/watch. However, 'gbp import-orig --pristine-tar --uscan' does not do anything telling "package is up to date, nothing to do". How should I proceed? Many thanks, Andrius [1] https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#dfsg -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#903904: RFS: wannier90/2.1.0 -- maximally localized Wannier functions
Package: sponsorship-requests Severity: normal Control: block 578829 by -1 Hello, I am looking for a sponsor for my package "wannier90". * Package name: wannier90 Version : 2.1.0 Upstream Author : Mostofi et al. * URL : http://www.wannier.org * License : GPL-2+ Programming Lang: Fortran Description : maximally localized Wannier functions It builds these binary packages: wannier90- Maximally Localized Wannier Functions - executables libwannier90-dev - Maximally Localized Wannier Functions - development files Relationships with other scientific packages already in Debian: * abinit: could be linked against wannier90 for Wannier function calculation * espresso: could be linked against wannier90 instead of a convenience copy * gpaw: wannier90 executables are used in examples (not installed, though) The packages are not in the Mentors (due to #901025). The packaging is done in Salsa repository at https://salsa.debian.org/science-team/wannier90 and can be reviewed there. The package could be maintained in either Debian Science or DebiChem team. Many thanks, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#901346: RFS: reentry/1.2.1a2-1 -- plugin manager based on setuptools entry points
Package: sponsorship-requests Severity: normal Hello, I am looking for a sponsor for my package "reentry". * Package name: reentry Version : 1.2.1a2 Upstream Author : Rico Haeuselmann * URL : https://pypi.org/project/reentry/ * License : MIT Programming Lang: Python Description : plugin manager based on setuptools entry points It builds these binary packages: python-reentry - plugin manager based on setuptools entry points (Python 2) python3-reentry - plugin manager based on setuptools entry points (Python 3) The packages are dependencies of AiiDA (http://www.aiida.net) and its plugins. As AiiDA currently is Python 2-only, python-reentry package is needed. The packages are not in the Mentors (due to #901025). The packaging is done in Salsa repository at https://salsa.debian.org/python-team/modules/python-reentry and can be reviewed there. Many thanks, Andrius
Bug#883840: RFS: spglib/1.10.3-1 [ITP]
On 04/23/2018 10:03 PM, Alex Mestiashvili wrote: > I think it is better to wait until it is either accepted or rejected. > Once it is in unstable you can upload the fixed version much easier. OK, I will wait for their response, then submit a RFS for -2 version with the recent fixes. Best, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#883840: RFS: spglib/1.10.3-1 [ITP]
On 04/23/2018 06:43 PM, Lumin wrote: > Oh, I forgot to tell you that the failure is due to output to stderr. > By redirecting > the stderr to e.g. stdout, this failure can be fixed. Thanks for pointing this out :) I had similar idea, but it would have taken me much longer to solve it. > Please let me know if you think the package is ready. Then I'll check > it again :-) I suppose it's ready now. By the way, the package is already in NEW queue -- should I close this bug? Or is it possible to update a package already in the NEW? Many thanks for help! Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#883840: RFS: spglib/1.10.3-1 [ITP]
Dear Lumin,
many thanks for reviewing the package! Please find my comments in-line.
On 04/23/2018 10:35 AM, Lumin wrote:
> 1. There seems to be ruby binding available, why isn't it packaged?
I have too little experience with Ruby. However, I will look at how to package
it.
> 2. control: Your -dev package should also depend on the lib package.
> Depends: ${misc:Depends}, libsymspg1 (= ${binary:Version})
Fixed.
> The python package should depend on it too.
Is it really so? As I understand, all objects are linked in Python SO file and
it alone is sufficient to use the Python binding. At least all Python tests
pass having python3-spglib installed only.
> 3. libsymspg1.install :
Done.
>Apart from that, this looks a bit weird:
>DEBIAN/symbols DEBIAN
Fixed.
> 4. the install file of -dev package could be simplified
Done.
> 5. I'd suggest you install the library in the multiarch directory.
> for example /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)
Done.
> 6. tests: your autopkgtest testsuite failed:
I will look into this. It is possible that I invoke the Python tests
incorrectly.
Thanks again!
Andrius
--
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania
Bug#883840: Retitling the bug report as per new upstream release of spglib
retitle 883840 RFS: spglib/1.10.3-1 [ITP] -- C library for crystal symmetry determination thanks I have updated the package as per new upstream patch release of "spglib". Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#883840: Retitling the bug report as per new upstream release of spglib
retitle 883840 RFS: spglib/1.10.2-1 [ITP] -- C library for crystal symmetry determination thanks I have updated the package as per new upstream patch release of "spglib". Andrius -- Andrius Merkys PhD student at Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#883840: RFS: spglib/1.10.1-1 [ITP] -- C library for crystal symmetry determination
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "spglib": * Package name: spglib Version : spglib/1.10.1-1 Upstream Author : Atsushi Togo * URL : https://atztogo.github.io/spglib/ * License : BSD-3-Clause Section : science It builds those binary packages: libsymspg0-dev - C library for crystal symmetry determination Spglib is a C library for crystal symmetry determination. Symmetry operations, space groups and other data can be obtained using this symmetry finder. Features include: * Identify space-group type * Find symmetry operations * Find a primitive cell * Search irreducible k-points * Refine crystal structure * Wyckoff position assignment The package implements symmetry determination algorithms by Grosse-Kunstleve (Acta Cryst., A55, 383-395 (1999)) and Grosse-Kunstleve and Adams (Acta Cryst., A58, 60-65 (2002)). There are language bindings for Python, Fortran and Ruby. Packaging of spglib was previously requested in RFPs #602113 and #674135 (merged). To access further information about this package, please visit the following URL: https://anonscm.debian.org/git/debian-science/packages/spglib.git Alternatively, a package can be GIT cloned from the packaging repository by: git clone git://anonscm.debian.org/git/debian-science/packages/spglib.git Best regards, Andrius Merkys
Bug#864713: Bug #864713: cod-tools package is ready
Dear maintainers, I have prepared the Debian package for cod-tools in its package repository of Debian Science (https://anonscm.debian.org/git/debian-science/packages/cod-tools.git/) and I am looking for a sponsor. I think the package is suitable for DebianScience/Chemistry metapackage. Sincerely, Andrius Merkys -- Andrius Merkys PhD student at Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#864713: RFS: cod-tools/2.0-5 [ITP] -- tools for manipulation of Crystallographic Information Format files
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "cod-tools" * Package name: cod-tools Version : 2.0-5 Upstream Author : Saulius Gražulis , Andrius Merkys , Antanas Vaitkus * URL : http://wiki.crystallography.net/cod-tools * License : GPL 2.0 Section : misc It builds those binary packages: cod-tools - tools for manipulating CIF format files codcif - error-correcting CIF parser libcexceptions0 - C exception handling library libcod-cif-parser-bison-perl - error-correcting CIF parser - Perl bindings libcod-cif-parser-yapp-perl - error-correcting CIF parser - YAPP implementation libcod-precision-perl - COD precision handling module for Perl language libcod-usermessage-perl - COD message formatting module for Perl language libgetoptions0 - Command line argument processing library for C python-pycodcif - error-correcting CIF parser - Python bindings To access further information about this package, please visit the following URL: https://mentors.debian.net/package/cod-tools Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/cod-tools/cod-tools_2.0-5.dsc More information about cod-tools can be obtained from http://wiki.crystallography.net/cod-tools. Regards, Andrius Merkys
