Bug#935808: RFS: dbacl 1.14.1-2 [QA upload]
On Monday, August 26 2019, Fabian Wolff wrote: > On 8/27/19 12:20 AM, Sergio Durigan Junior wrote: >> On Monday, August 26 2019, Fabian Wolff wrote: >> >>> Dear mentors, >>> >>> I am looking for a sponsor for a QA upload of the dbacl package. >>> >>> This upload attempts to fix a FTBFS bug (#916182), and I have also >>> performed some standard package maintenance tasks. >>> >>> I will push to the proper repository (in the Debian group on Salsa) as >>> soon as I have the required permissions on Salsa; in the meantime, you >>> can find my changes here: https://salsa.debian.org/wolff-guest/dbacl >>> >>> And also on Mentors: https://mentors.debian.net/package/dbacl >> >> Hm, I wasn't able to generate the orig tarball; maybe you forgot to push >> the pristine-tar branch? > > No, I forgot to add --pristine-tar when doing gbp import-orig, and I > don't know how to do it retroactively; I guess that whoever imports > the next upstream version can create the branch (or somebody more > knowledgeable about git-buildpackage can do it now for the current > version). Ah, fair enough. >> While at it, please follow the standard being used to organize the build >> deps (1 item per line): >> >> + flex, bison >> >> Out of curiosity, why do you have to regenerate the parser/lexer files? > > Hm, somebody else already uploaded the package now, so I can't change it > anymore for this upload. Hm. Second time today. I wish we had a better way to sync this. > As for why I have to regenerate the lexer and parser, I think some of > the arguments from [0] apply, but in particular, just including > in dbacl.h did not fix the FTBFS issue; I actually had to > regenerate the lexer and parser for my changes to take effect (or > maybe I just made a mistake somewhere - I don't have much experience > with flex/bison). Ah, I see. Thanks for explaining. > In any case, thank you very much for having a look at my changes (and also > for creating the Salsa repositories!). My pleasure. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Re: Salsa repository request (aj-snapshot, dbacl, ffe)
On Sunday, August 25 2019, Fabian Wolff wrote: > Hi, Hi Fabian, > I am currently preparing QA uploads for the 'aj-snapshot', 'dbacl', and 'ffe' > packages [0, 1, 2]. Thanks for doing this. > I would like to create packaging repositories for these projects in > the Debian group on Salsa [3], but since I am not a Debian Developer, > I don't have the necessary permissions on Salsa to create them myself. > > > So, could somebody please create these three repositories for me and give me, > wolff-guest, write access to them? Done for all three. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Re: Salsa repository request (aj-snapshot, dbacl, ffe)
On Monday, August 26 2019, Fabian Wolff wrote: > Thank you! > > Unfortunately, when I tried to push to these repositories, I ran into the > following issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/51484 Ops. > In other words, it seems that you need Maintainer permissions to be able to > push to an empty Gitlab repository, but you've given me only Developer > permissions. Sure thing. Done. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Re: uscan watch for gitlab.gnome.org
On Wednesday, August 07 2019, Andreas Ronnquist wrote: > Hi > > Does anybody have an example on a watch-file that works for > gitlab.gnome.org, but works on files there, and not on Git tags? Heya, This is what I came up with: version=4 https://gitlab.gnome.org/World/lollypop/-/tags \ /World/lollypop/uploads/[0-9a-f]+/lollypop-@ANY_VERSION@@ARCHIVE_EXT@ > In my case the files look like this, and I have a hard time getting a > watch file working properly. > > https://gitlab.gnome.org/World/lollypop/uploads/1d87588d659e720e70d08e6e945fe317/lollypop-1.1.4.11.tar.xz The trick is looking at the page's source code, and noticing that the href tags are in this format: lollypop-1.1.4.11.tar.xz which means you can look for the "/World/lollypop/..." pattern. > [Please don't CC me, if I mail to a mailinglist, I am subscribed to it.] You might want to set Mail-Followup-To :-). Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Re: I want to collaborate with materia-gtk-theme
On Friday, February 14 2020, Roberto De Oliveira wrote: > Hi Everyone! Hey Alberto, > I realized materia-gtk-theme could be easily update with latest > upstream version, actually I did a test with gbp and installed on my > computer and it's working just fine. I sent an email to Sagar > Ippalpalli but I haven't received a response. How can I help with this > package (and star a path to become my self into a Debian Contributor). Thank you for your interest! If you've already tried contacting the current maintainer, waited for at least 2 weeks, and hasn't received any replies from him, then I'd say it's pretty safe to go ahead and start working on the package yourself. You can prepare an NMU (Non-Maintainer Upload) and ask for sponsorship here. Someone will review your package, and will be able to upload it to a DELAYED queue (probably after trying to contact the maintainer again). Don't stop yourself from improving a package just because of an unresponsive maintainer. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Re: Advice on packaging new upstream releases.
On Saturday, February 15 2020, Inaki Malerba wrote: > Hi everyone! Hey Inaki, > I'm looking for some advice on how to fix some problems on 2 different > packages I've been trying to update with no luck so far. > > # python-icecream. [0][1] > > The new release includes a dependency to a very small repository [2] > that's not packaged. > > My first thought was to open an ITP and try to package it, but it turns > out to be a single python script and I'm not sure if it's reasonable to > create a whole package for that. > > Should I package the new dependency? The README[3] even suggests that > it's ok to copy that single file. Would it be OK if I patch it into my > package? It's not uncommon to see small Python packages out there, often with only a single file, like this one. IMO, you should go ahead and package it properly. Other packages might depend on it, and it seems like an easy package to make anyway. > # doit [4][5] > > The latest release of this package contains a huge change on the > documentation, which breaks the linting. It contains a lot of external > javascripts and stuff. > > As python-icecream, doit made a change to depend on a custom sphinx > theme that's not packaged but I managed to fix that patching it to use > the default theme[6]. > > Having changed the theme and fixed one of lintian suggestions (the > node-html5shiv one), there are still a lot of problems with the docs > package[7]. I even thought of removing the python-doit-doc package. This one is more complicated... Apparently upstream decided to write an index.html documentation page full of minified, non-Free JS: https://github.com/pydoit/doit/commit/e7717d705d60731f750f1e27e0f633c3d0502678 If you look at index.html's header, you'll see references to things under the _static/vendor directory, or links to fonts.googleapis.com. Both are problematic: https://github.com/pydoit/doit/blob/master/doc/index.html#L10-L26 We have almost everything packaged in Debian that is needed to replace these. You will have to remove the files from the tarball (using d/copyright's Files-Excluded, plus using +dfsg in the package's version). These are the replacements that already exist in Debian: libjs-bootstrap (for bootstrap.min.js) fonts-font-awesome (for font-awesome.min.css) fonts-roboto (for the googleapis.com Roboto font) We're missing packages for "bootstrap-select.min.css" and "owl.carousel". The good thing about "owl.carousel" is that python-doit ships the non-minified JS version, which means that you can minify it during build time. The problematic part is the "bootstrap-select.min.css" file, which is only shipped in its minified version. The ideal scenario would be to package bootstrap-select and then depend on it, but I don't think it's fair to make you go through this (the package seems a bit complicated, and packaging JS is not easy sometimes). Another "good enough" approach (IMO) would be to copy a version of "bootstrap-select.js" (non-minified) into python-doit's code (using a patch under d/patch, of course), and then minify it during the build. This is not very elegant, but solves the problem (it's similar to what you proposed above, for python-icecream). All in all, it will demand a bit of work, unfortunately. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Re: cannot allocate memory in static TLS block
On Saturday, March 14 2020, Andreas Tille wrote:
> On Fri, Mar 13, 2020 at 11:09:31PM +0100, Paul Gevers wrote:
>>
>> raise RuntimeError(('Could not find drmaa library. Please specify
>> its ' +
>> RuntimeError: Could not find drmaa library. Please specify its full
>> path using the environment variable DRMAA_LIBRARY_PATH
>
> I've fixed this in Git. Unfortunately I get a new issue when importing
> drmaa
>
> $ python3
> Python 3.7.6 (default, Jan 19 2020, 22:34:52)
> [GCC 9.2.1 20200117] on linux
> Type "help", "copyright", "credits" or "license" for more information.
import drmaa
> Traceback (most recent call last):
> File "", line 1, in
> File
> "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/__init__.py",
> line 65, in
> from .session import JobInfo, JobTemplate, Session
> File
> "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/session.py",
> line 39, in
> from drmaa.helpers import (adapt_rusage, Attribute,
> attribute_names_iterator,
> File
> "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/helpers.py",
> line 36, in
> from drmaa.wrappers import (drmaa_attr_names_t, drmaa_attr_values_t,
> File
> "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/wrappers.py",
> line 58, in
> _lib = CDLL(libpath, mode=RTLD_GLOBAL)
> File "/usr/lib/python3.7/ctypes/__init__.py", line 364, in __init__
> self._handle = _dlopen(self._name, mode)
> OSError: /usr/lib/x86_64-linux-gnu/libjemalloc.so.2: cannot allocate memory
> in static TLS block
>
>
> Any help would be welcome
This is an issue with jemalloc's handling of the TLS model when being
dlopened.. See:
https://github.com/jemalloc/jemalloc/issues/1237
The recommended way to build a libjemalloc that is suitable for being
dlopened is to use '--disable-initial-exec-tls' when building it. Take
a look at the INSTALL.md file, and look for this option:
https://github.com/jemalloc/jemalloc/blob/dev/INSTALL.md
There is a way to workaround this bug by doing an LD_PRELOAD of
libjemalloc when invoking python, but this will only mask the problem
and we can't expect users to do/know this.
The way I see it, you can try to convince jemalloc's maintainer to
enable that flag.
BTW, the reason 'find_library' can't find drmaa's library is because the
.so is being installed in a non-standard directory. I don't know why
the package was made like this, though.
Thanks,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/
signature.asc
Description: PGP signature
Re: How to ignore some versions for watch file?
On Thursday, August 06 2020, Roger Shimizu wrote: > Dear mentors list, > > I maintain a package that previously used vMMDD as version, but > now changed to v1.y.z > - https://tracker.debian.org/pkg/shadowsocks-v2ray-plugin > - https://github.com/shadowsocks/v2ray-plugin/tags > > So my question is how to ignore the old version vMMDD, and only > detect v1.y.z as latest version for d/watch file? > > BTW. I already read a few posts regarding on d/watch file [1][2], but > still didn't find a proper solution. This did it for me version=4 opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%shadowsocks-v2ray-plugin_$1.orig.tar.gz%,\ uversionmangle=s/(\d)[_\.\-\+]?(RC|rc|pre|dev|beta|alpha)[.]?(\d*)$/\$1~\$2\$3/" \ https://github.com/shadowsocks/v2ray-plugin/tags .*/v?(\d\.\S*)\.tar\.gz debian ^^ The only thing I changed is the extra "\.", which I tried to "highlight" above. This assumes that every version will contain at least one dot, which I think is a safe assumption given upstream's history. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/ signature.asc Description: PGP signature
Re: How to suppress "source-is-missing" lintian error?
On Thursday, August 13 2020, Ángel wrote: > On 2020-08-13 at 12:47 -0700, A. Lewenberg wrote: >> I am trying to suppress some lintian errors in my package build. I see >> this error when running lintian: >> -- >> E: stanford-spdb source: source-is-missing >> usr/share/spdb/vendor/assets/javascripts/bootstrap-4.4.1.min.js >> (...) >> How do I get lintian to be quiet about this? > > Add a depends on libjs-bootstrap and remove this minified file from your > package? This is the right way to go, except that he will want libjs-bootstrap4 instead, based on the lintian error. If you have other JavaScript dependencies that are not package yet, you need to either (a) package them (this is the preferred way, but not always feasible), or (b) remove any minified JS and regenerate them. For (b), you will need to tweak d/copyright's Excluded-Files directive and remove the *.min.js (note that you may also need to remove the *.min.css files) that are not package in Debian, and then use yui-compressor to generate them from the unminified files that should be present in the source package. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
Bug#981022: RFS: ticker/1.13 [QA] -- configurable text scroller
On Monday, January 25 2021, Leandro Cunha wrote: > ticker (1.13) unstable; urgency=medium > . >* QA upload. >* FTCBFS: uses the build architecture compiler. (Closes: #979732) >* ticker.spec: updated version to 1.13. >* debian/control: > - Bumped Standards-Version to 4.5.1. > - Removed Vcs in Salsa nonexistent. >* debian/copyright: > - Updated contribution year. The package was uploaded before I could review it, but in your previous upload you added Vcs-* fields to d/control. In this one, you removed them. Why didn't you push the repository to salsa? -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/ signature.asc Description: PGP signature
Bug#981022: RFS: ticker/1.13 [QA] -- configurable text scroller
On Monday, January 25 2021, Leandro Cunha wrote: > Em seg., 25 de jan. de 2021 às 21:16, Sergio Durigan Junior < > sergi...@debian.org> escreveu: > >> On Monday, January 25 2021, Leandro Cunha wrote: >> >> > ticker (1.13) unstable; urgency=medium >> > . >> >* QA upload. >> >* FTCBFS: uses the build architecture compiler. (Closes: #979732) >> >* ticker.spec: updated version to 1.13. >> >* debian/control: >> > - Bumped Standards-Version to 4.5.1. >> > - Removed Vcs in Salsa nonexistent. >> >* debian/copyright: >> > - Updated contribution year. >> >> The package was uploaded before I could review it, but in your previous >> upload you added Vcs-* fields to d/control. In this one, you removed >> them. Why didn't you push the repository to salsa? >> >> -- >> Sergio >> GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 >> Please send encrypted e-mail if possible >> https://sergiodj.net/ >> > > This can be resolved with gbp import-dscs --debsnap ticker after creating > the > repository in the Debian group on Salsa with permission. I know that. My question was why didn't you do it? -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
Bug#980727: RFS: grap/1.46-1 [QA] -- program for typesetting graphs
Control: owner -1 ! On Thursday, January 21 2021, Leandro Cunha wrote: > Changes since the last upload: > > grap (1.46-1) unstable; urgency=medium > . >* QA upload. >* New upstream release. >* Added debian/gbp.conf. I don't see a reason to add a gbp.conf given that the package is not maintained in git. Moreover, the settings you're proposing seem personal choices more suitable for a local ~/.gbp.conf than for a project one. >* Added debian/upstream/metadata. >* Added debian/docs. While at it, please add a newline at the end of d/docs. >* debian/copyright: > - Added Upstream-Contact optional field according DEP-5. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/ signature.asc Description: PGP signature
Bug#980562: RFS: shellingham/1.3.2-1 [ITP] -- Tool to Detect Surrounding Shell
Control: owner -1 ! On Wednesday, January 20 2021, Emmanuel Arias wrote: > shellingham (1.3.2-1) unstable; urgency=medium > . >* Initial release (Closes: #980483) Thanks for the interest in packaging. Some things I'd like you to fix before the upload: 1) You don't need to specify "--test=pytest" on d/rules. 2) python3-shellingham is Suggesting python3-shellingham-doc, which doesn't exist. 3) The package ships with a README.rst. I prefer installing it as part of the documentation. Just add README.rst to a debian/docs file. 4) You're licensing the contents under debian/ as GPL-3+, which is a different license than what upstream is using. Is there any particular reason that made you choose to do this? Do you understand the implications of choosing a different license than the one upstream is using here? 5) On d/copyright, the text of the ISC license should be formatted with one leading space only. I'd also prefer if you could include the full text of the license. 6) There's an empty line at the end of d/watch. Please remove it. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/ signature.asc Description: PGP signature
Re: sbuild dh: error: unable to load addon python3
On Thursday, July 01 2021, Geert Stappers wrote: > Invoking sbuild with just 'sbuild' gives me: > > $ sbuild > dh clean --with python3 --buildsystem=pybuild > dh: error: unable to load addon python3: Can't locate > Debian/Debhelper/Sequence/python3.pm in @INC > (you may need to install the Debian::Debhelper::Sequence::python3 module) > > > Doing `apt-file search Debian/Debhelper/Sequence/python3.pm` yields > dh-python: /usr/share/perl5/Debian/Debhelper/Sequence/python3.pm > > > Why doesn't sbuild fetch and install build dependencies? This happens because sbuild runs the "dh clean" (actually, the "debian/rules clean" target) step *outside* of the chroot, before the build actually starts. This means that sbuild expects you to have the build deps installed on your host. This is usually not desirable/required, so you can tell sbuild to not clean the source tree by passing the --no-clean-source option to it, or by adding the line "$clean_source = 0;" to your ~/.sbuildrc. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/ signature.asc Description: PGP signature
Bug#1064087: RFS: asn/0.75.3-1 [ITP] -- network OSINT CLI ASN, RPKI, BGP, Geo, Recon, Trace
On Friday, February 16 2024, Marcos Rodrigues de Carvalho wrote: > Dear mentors, > > I am looking for a sponsor for my package "asn": Thanks, Marcos. Here's my review. * d/copyright: The full name of the package author is available in the LICENSE file. You need to use it when writing the d/copyright entry. * d/control: I've never seen X-Lintian-Overrides before, and I don't think it's recognized by Lintian. Please remove it (and add a proper lintian-overrides file if necessary). * d/watch: Minor nitpick, but the file doesn't end with a newline. * d/manpage/asn.1 Thanks for writing a manpage! Did you write it manually, or did you use some software to generate it? If the latter, then I'd suggest adding the original source for the manpage and generating it during build time. I have a few comments about its style: - I believe the "TARGET" section needs be better organized. I think you should itemize each possible target and separate them with a newline or something. - Same comment for "SERVER OPTIONS". In fact, according to the README file, there are a few more server options than what you're listing. - You forgot to edit the "AUTHOR" section :-). * General comments: You're using gbp, and you chose a non-standard branch name for the master (Debian) branch. Therefore, you need to provide a d/gbp.conf which teaches gbp how to find your Debian branch. Also, unless you have a very good reason not to, this package should be placed under the "debian" namespace on Salsa. I can create a repository there and give you permissions if you want. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
Re: Uscan no longer works with GitLab tags
On Tuesday, March 26 2024, Soren Stoutner wrote: > https://wiki.debian.org/debian/watch#Gitlab[1] > > "From 2024/03 above solution do not work anymore since Gitlab changed their > tag > ordering. You can use direct API access:” > > version=4 > opts=\ > searchmode=plain,\ >https://gitlab.com/api/v4/projects/PROJECTID/releases > archive/v?\d[\d.]+//-v? > ([\d.]+)@ARCHIVE_EXT@ My initial (successful) attempt was to use the API directly, but some people might be confused about the PROJECTID part (it needs to be URL-encoded unless you're specifying the actual integer ID directly). Either way, here are the two options: version=4 opts=searchmode=plain \ https://gitlab.com/saalen/highlight/-/tags?sort=updated_desc /archive/@ANY_VERSION@/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ # Using the API: # https://gitlab.com/api/v4/projects/saalen%2Fhighlight/releases /archive/@ANY_VERSION@/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/ signature.asc Description: PGP signature
Re: Uscan no longer works with GitLab tags
On Monday, March 25 2024, Shriram Ravindranathan wrote:
> Dear Mentors,
>
> I noticed from the past couple of days, uscan seems to be having trouble
> finding files from the gitlab tags page.
>
> ```
> $ uscan
> uscan warn: In debian/watch no matching files for watch line
> https://gitlab.com/saalen/highlight/tags?sort=updated_desc
> .*/archive/(\d\S+)/.*\.tar\.gz.*
> ```
>
> Checking the same pattern with grep shows that it does find a match
>
> ```
> $ curl -L "https://gitlab.com/saalen/highlight/tags?sort=updated_desc; | grep
> -E ".*/archive/([0-9]\S+)/.*\.tar\.gz.*"
> % Total% Received % Xferd Average Speed TimeTime Time
> Current
> Dload Upload Total SpentLeft Speed
> 100 126 100 1260 0287 0 --:--:-- --:--:-- --:--:-- 287
> 0 00 00 0 0 0 --:--:-- 0:00:01 --:--:--
> 0 data-download-artifacts="[]"
> data-download-links="[{text:zip,path:/saalen/highlight/-/archive/4.11/highlight-4.11.zip},{text:tar.gz,path:/saalen/highlight/-/archive/4.11/highlight-4.11.tar.gz},{text:tar.bz2,path:/saalen/highlight/-/archive/4.11/highlight-4.11.tar.bz2},{text:tar,path:/saalen/highlight/-/archive/4.11/highlight-4.11.tar}]">
> 100 85448 100 854480 0 51822 0 0:00:01 0:00:01 --:--:-- 401k
> ```
>
> It seems like a few other packages are also having similar troubles with
> uscan, for example lomiri
>
> Is there a way to fix this?
I don't know if there's an "official" way to fix this, but the problem
seems to be the fact the actual download link is embedded inside an
element of the page, like this:
https://sergiodj.net/
signature.asc
Description: PGP signature
