Re: Creating packages for several distributions
On Wed, Mar 22, 2023 at 01:48:39PM +0100, Robin Alexander wrote: > Hi, > > I am in charge of creating debian packages for the Opendigitalradio mmbtools > (https://www.opendigitalradio.org/mmbtools) and as such, I: > - am proposing/pushing debian packages to unstable > - manage the Opendigitalradio debian repository > (http://debian.opendigitalradio.org) > > If I want to create a package (ex: odr-audioenc) for both unstable and > bullseye on both debian and odr repository, can I have 1 debian/changelog > file only where the first line would read: > odr-audioenc (3.3.1-1+deb11u1) unstable bullseye; urgency=medium > > or do I need 2 versions of debian/changelog (thus 2 branches: > debian/bullseye + debian/latest): one for each distribution (unstable and > bullseye)? For different distributions you should use different changelog entries, different version numbers and sometimes/often (depending on the package) you may have other differences. And even if you use the same changelog entry (as technically you can have anything in your 3rd-party repo) you still need to build it separately for every distribution you are targeting. I also wouldn't use the same versions for official unstable packages and 3rd-party packages targeting unstable.
Re: Creating packages for several distributions
On Wed, Mar 22, 2023 at 02:42:28PM +0100, Robin Alexander wrote: > Hi Mechtilde and Andrey, > > Got it for the official debian repository. In a nutshell: > - Push to mentors once the freeze is released (ie, after bookworm is > released) > - Once package in unstable/testing, push a backport to stable and oldstable Yes, though I'm not sure if a package not in stable can go to oldstable-backports or only to oldstable-backports-sloppy. Please also note "Please only upload package with a notable userbase. Backports is not a maintainer's PPA" from https://backports.debian.org/Contribute/#index2h3 > * debian/bullseye: debian official repository and bullseye Not sure what is this? Do you mean bullseye-backports?
Re: Maintaining a package across several debian codenames
On Mon, Apr 10, 2023 at 11:29:25AM +0200, Robin ALEXANDER wrote: > Hi, > > Let's assume I wish to maintain package_A across unstable and bullseye- > backports. I understand from > https://dep-team.pages.debian.net/deps/dep14/ that: > > 1. I need to create 3 branches in my git repository: > - upstream/latest > - debian/latest > - debian/bullseye-backports > > 2. Since I am using git-buildpackage, I presume I would generate 3 tags > when creating a new package version (ex: v3.0.0) > - upstream/3.0.0 (when running gbp import-orig) > - debian/3.0.0-1 (when running gbp buildpackage inside branch > debian/latest) > - ??? (when running gbp buildpackage inside branch debian/bullseye- > backports) > > If the above is correct, what should be the name of the last tag (the > one issued by gbp buildpackage inside branch debian/bullseye-backports > ? gbp buildpackage (or gbp tag) will create the correct tag name for you.
Re: Maintaining a package across several debian codenames
On Mon, Apr 10, 2023 at 08:14:39PM +0200, Robin ALEXANDER wrote: > In a nutshell, if I understood correctly the debian policy > > Branch debian/latest > File debian/changelog will show "...(3.0.0-1) unstable ..." > > Branch debian/bullseye-backports > File debian/changelog will show "... (3.0.0-1~bpo11u1) bullseye ..." It's "3.0.0-1~bpo11+1", see https://backports.debian.org/Contribute/ > Should I decide to setup a private repository on top to speed up things > , I could add a new branch to my git repository: > Branch debian/bullseye > File debian/changelog would show "... (3.0.0-1~deb11u1) ..." The versioning scheme for private repos is up to you, as long as it doesn't clash with schemes used by Debian repos.
Bug#1036020: RFS: lighttpd/1.4.70-1 [NMU] -- light, fast, functional web server
Control: retitle -1 RFS: lighttpd/1.4.70-1 -- light, fast, functional web server On Sat, May 13, 2023 at 04:27:36AM -0400, Glenn Strauss wrote: > (This is not actually an NMU, but a non-DD maintainer upload.) If it's not a NMU it shouldn't be tagged as a NMU. > Please help me to get lighttpd 1.4.70 into Debian Bookworm. The time to get new upstream versions into Debian Bookworm ended 3 months ago. Please check the freeze policy every time there is a freeze if you maintain packages in testing. If you want you can change this upload to target experimental instead, or just postpone it until the Bookworm release. You can make a backport for bookworm-backports after that. If, on the other hand, 1.4.70 fixes some serious bugs in the testing version, you should make an upload based on the testing version that includes these fixes.
Re: Questions about ITP in Debian
On Mon, May 29, 2023 at 01:24:12PM -0300, Tadeu Sampaio wrote: > Thx Robin for the fast response! So what is needed in order to proceed with > the ITP below, we need a sponsor? Unless it's your ITP you should contact the current ITP owner so that you don't make duplicate work.
Re: Build packages locally using containers
On Fri, Jun 02, 2023 at 12:56:03PM +0200, Rock Storm wrote: > I've been working on a small program to locally build packages in > containers. Sort of an alternative to `pbuilder`. Because I find > managing containers easier than managing base.tgz. In case anyone finds > it useful as well, full info in the README: > > https://github.com/rockstorm101/whalebuilder One of the 8 build-in-Docker tools listed on https://wiki.debian.org/SystemBuildTools#Package_build_tools is even called whalebuilder. It's also in Debian since 2016.
Re: New package: ITP or RFP ?
On Tue, Jun 20, 2023 at 05:15:05PM +0300, Ramūnas Keliuotis wrote: > 1. Is it ok for source code to be in Github? or do I need a Salsa account? It is OK for the source code to not have a VCS at all. It's also OK for the packaging to not have a VCS at all, and these are two separate questions, and packaging is usually stored in a separate VCS, usually on salsa, because usually the maintainer is not the same as the upstream. > 2. Do I need to create a source package? *.dsc Yes. > 3. How to implement build /scripts? Ideally your software should have them before you start working on the packaging, because ideally your software should be buildable by anyone who downloads its source. The packaging just does the same in a more controlled environment. > Now we are using bash scripts and preconfigured docker containers. > But dh scripts should be used, so, how to start using them? dh should just call the upstream build system. If you are not using any popular build system that dh can call you will need to write the necessary commands in debian/rules manually. It's also quite likely that those "bash scripts" are not suitable for this, in which case you will need to fix them and/or switch to a proper build system. > 5. Also, we are using OpenVPN - building from C code, > but this package is long ago open source, so, assume it should be > easy to package. openvpn is of course already packaged. > Would be good to get reference to sample package - observe its build > configuration. You can look at any source package in Debian unless you need more specific examples.
Re: Help with Lintian error in python3 (pybind11-wrapped) package
On Mon, Jul 10, 2023 at 01:19:38AM -0700, JOSE LUIS BLANCO CLARACO wrote: > [2]. I attach the output of "dpkg -I" for the final binary package, where > the "Depends: python3" is visible No, as it says "phyton3". (I would also expect that using appropriate substvars here is better than writing deps manually)
Re: Help with Lintian error in python3 (pybind11-wrapped) package
On Mon, Jul 10, 2023 at 11:22:05AM +0200, José Luis Blanco-Claraco wrote:
> On Mon, Jul 10, 2023 at 11:09 AM Andrey Rakhmatullin wrote:
> > No, as it says "phyton3".
> > (I would also expect that using appropriate substvars here is better than
> > writing deps manually)
>
> I know, and added ${python3:Depends} and ${shlibs:Depends}, but
> "dh-python" seems not to add any substvars, and "shlibs" does neither.
shlibs:Depends is indeed irrelevant here.
python3:Depends being empty is a problem that needs to be fixed. I've
built the package and it lacks postinst/prerm so I guess dh_python3 didn't
find any modules in the package. I also see that the package is named
python3-pymrpt while the top-level module is named myrpt, though I don't
know if this can cause any problems beside the autopkgtest not working.
> In fact, the "so" module built from the pybind11 wrapper seems not to
> list any python library in "ldd", which also puzzled me:
>
> ldd mrpt/pymrpt.cpython-310-x86_64-linux-gnu.so | grep py
> libsnappy.so.1 => /lib/x86_64-linux-gnu/libsnappy.so.1 (0x7facb732d000)
Python extensions indeed don't need to link libpython, which is (mostly?)
for embedding the interpreter, as extensions are loaded into an
interpreter themselves.
> I checked that other "*cpython.so" modules out there indeed list
> "libpython3.xxx.so" in their "ldd".
(I've checked two random extensiopns and they don't)
> I understand this is what is preventing "shlibs" to automatically list
> python3 as a substvar, but don't know how to fix it.
It's not, and shlibs:Depends won't list python3 anyway.
Re: Help with Lintian error in python3 (pybind11-wrapped) package
On Mon, Jul 10, 2023 at 05:11:39PM +0200, José Luis Blanco-Claraco wrote: > Thanks a lot, Andrey, for the time analyzing the problems here, and > for the clarifications. I thought libpython was like "libc" for > python... It is, but as extensions are loadable plugins, they are fine with symbols being provided by the executable instead of linking a library. If you check you will see that Py* symbols in the extensions are unresolved and that /usr/bin/python3 exports them. > So the main issue seems to be dh_python3 not recognizing the package > as "python"... > I attach the list of files and directories of the latest package > version just in case it's easy to spot problems from it (the > "__pycache__" are there for a test Ubuntu build, but are not in the > Debian build). TBH I don't think it's about the file list (though it's possible). > Note that I want to ship: > - A cpython .so module + its .pyi stubs. > - The corresponding py.typed file, which I understand is > recommended/mandatory when shipping .pyi stubs. > - Pure python scripts (right now, only "ros_bridge.py"). > > At present, I put everything under > "/usr/lib/python3/dist-packages/mrpt/" so everything is together, not > "polluting" the "dist-packages" directory. I don't think this makes sense. You should put them wherever the upstream puts them so that the module can be imported (and scripts can be run) in the way that is documented and expected by users. > Maybe the package should be named "python3-mrpt" instead? It should always be named for its top-level importable module, see https://www.debian.org/doc/packaging-manuals/python-policy/index.html#module-package-names > Any way to test dh_python3 manually? Perhaps just build the package > locally and run dh_python3 from the pkg root directory? Yes. And you should run it in the verbose mode.
Re: How to handle breakages when the size of a class in a shared lib increases?
On Tue, Jul 11, 2023 at 04:10:49PM +0200, Pierre Gruet wrote: > I maintain a package that builds a shared library. I uploaded a new upstream > version of it to Debian, with no removed symbols, no ABI change... Fine. Tobias already explained that there was actually an ABI change, but... > How should we handle such situation in Debian? Quoting Policy 8.1: > > The SONAME and binary package name need not, and indeed normally > should not, change if new interfaces are added but none are removed or > changed, since this will not break binaries linked against the old > shared library. Correct versioning of dependencies on the newer shared > library by binaries that use the new interfaces is handled via the > symbols or shlibs system. > > So my understanding is that no SONAME change and no transition are needed, > although the rdeps indeed have to be rebuilt as their binaries _are_ broken > by the new version of the library. ... I want to add that "the rdeps indeed have to be rebuilt" means, by definition, that an ABI change happened. It's not similar to adding a symbol when the same SONAME may mean different symbol lists but you can say "this binary needs at least this version of the library", it's a true ABI breakage like with removing a symbol, when old binaries only work with the old library, which the quote is about.
Re: dh_install by file suffix
On Sat, Jul 15, 2023 at 09:01:19PM +0200, Ole Streicher wrote: > Hi, > > I am upgrading one of my packages (iraf) to a new version. The new version > comes with a "make install", which installs everything under /usr/lib/iraf/ > (and some other places). > > The "iraf" source package needs to divide these files into user related > files (for the "iraf" and "iraf-noao" packages) and development related > files (for "iraf-dev" and "iraf-noao-dev"). The problem is now, that the > division is (mainly) by extension: > > - *.cl, *.hd, *.men, *.par (... and some other extensions) should go to > the user packages > > - *.a, *.h should go to the development packages > > (the "iraf" and "iraf-noao" package differ mainly by that "iraf" collects > them in the pkg/ subdir, and "iraf-noao" in the noao subdir). > > The main question here is: how can I do a dh_install selective by file > suffix? Otherwise, I would need to list the (~1000) files in the "install" > files, which is not very robust. You can always skip dh_install and do manual cp/mv/install/whatever commands in override_dh_install. Or you could probably use dh-exec.
Re: Question about upload
On Mon, Sep 04, 2023 at 12:28:01PM +0200, Preuße, Hilmar wrote: > Hi all, > > I'm trying to upload a new package for dvisvgm[1]. Unfortunately this does > not work: the dput command runs fine, but I did not even got the E-Mail that > the upload was successful and the package is processed. > In the meantime I could upload a new revision of texlive-bin, so there is no > general issue with my account. I'm using the upload server > "ftp.eu.upload.debian.org". >From usper:/srv/upload.debian.org/queued/run/log: Sep 3 22:22:33 processing /dvisvgm_3.1.1+ds-1_source.changes Sep 3 22:22:33 GnuPG signature check failed on dvisvgm_3.1.1+ds-1_source.changes Sep 3 22:22:33 (Exit status 2) Sep 3 22:22:33 /dvisvgm_3.1.1+ds-1_source.changes has bad PGP/GnuPG signature! Sep 3 22:22:33 Removing /dvisvgm_3.1.1+ds-1_source.changes, but keeping its associated files for now. Which is indeed the most frequent cause of "I did not even got the E-Mail".
Re: Q16 compile for the general CPU, and Illegal instruction
On Mon, Sep 04, 2023 at 10:33:12AM -0400, Tong Sun wrote: > With current cloud-compiling approaches, how should we make sure that > the built package works for the older x86_64 CPUs possible, and especially > about this Q16 compilation for ImageMagick? > > PS, the compilation is done via https://github.com/SoftCreatR/imei/. If it's not related to Debian packaging it shouldn't be on d-mentors@.
Re: Build #4787422: Build error log for mmlib package
On Tue, Oct 10, 2023 at 09:07:16PM +0100, Oyindamola Olatunji wrote: > Hello everyone, > > I am trying to update the mmlib package to upstream 1.4.2, however, I keep > getting this salsa build error log with sphinx. > > https://salsa.debian.org/med-team/mmlib/-/jobs/4787422#1219 > > The sphinx documentation builds locally. Do you mean the package builds locally in a minimal sid chroot?
Bug#1054423: RFS: python-art/6.1-1 [ITP] -- ASCII art
This ships a file named /usr/bin/art. I'm not sure if it's a good idea by itself, but also the artemis package also ships a file with this name (which I'm also not sure is a good idea) and so you should follow the first paragraph of https://www.debian.org/doc/debian-policy/ch-files.html#binaries
Re: Cannot create chroots with cowbuilder because of usr-is-merged
On Mon, Oct 30, 2023 at 06:18:42PM +0100, Santiago Vila wrote: > > W: See /var/cache/pbuilder/base.cow/debootstrap/debootstrap.log for details > > (possibly the package /var/cache/apt/archives/usr-is-merged_38_all.deb is > > at fault) > > Try > DEBOOTSTRAPOPTS="--merged-usr" > > in your ~/.pbuilderrc > > In trixie and sid, all chroots, including those to build packages, are > already supposed > to be usr-merged. What's the recommended way to convert ones created earlier? Recreate? Install usrmerge?
Re: Making packages binNMU safe
On Thu, Nov 02, 2023 at 07:54:16AM +0200, Tommi Höynälänmaa wrote: > WWW page https://wiki.debian.org/binNMU doesn't mention the case arch:all > package depending another arch:all package when it discussed making packages > binNMU safe. How is this case handled? arch: all packages arent rebuilt so I'm not sure what problems do you have in mind, can you elaborate?
Re: lintian error due to arm64 and aarch64 mismatch on raspberry pi
On Sat, Nov 11, 2023 at 07:36:07PM +0530, Shriram Ravindranathan wrote: > dpkg-deb: building package 'libmagicenum-dev' in > '../libmagicenum-dev_0.9.3-1_all.deb'. [...] > E: libmagicenum-dev: triplet-dir-and-architecture-mismatch is for arm64 > instead of all [usr/lib/aarch64-linux-gnu/] So you are shipping files in /usr/lib inside an arch:all package. You need to change it to arch:any.
Re: Questions about package dependencies with no upstream version
On Tue, Nov 21, 2023 at 04:39:42PM +, David James wrote: > A couple of these dependencies have no version upstream. Is there a > precedent for this? Can these dependencies be packaged? There are definitely packages like that in Debian and the usual practice is using date-based versions, probably something like 0+20231121.
Re: dh_missing and arch/indep
On Thu, Dec 14, 2023 at 04:53:50PM +0100, PICCA Frederic-Emmanuel wrote: > I found this solution. > > > execute_before_dh_missing-arch: > # rm remaining files (workaround FTBFS...) > rm -rf debian/tmp/usr/share > > execute_before_dh_missing-indep: > # rm remaining files (workaround FTBFS...) > rm -f debian/tmp/usr/bin/bornagain > rm -rf debian/tmp/usr/lib > rm -rf debian/tmp/usr/share/BornAgain/ > rm -f debian/tmp/usr/share/man/man1/bornagain.1 Just skipping dh_missing sounds easier and just as bad.
Re: Drop i386 architecture in texworks
On Tue, Dec 19, 2023 at 11:55:47PM +0100, Preuße, Hilmar wrote: > sorry to bother again. I was requested to stop building package on i386 > (#1057407) so libqt6 can drop the i386 support too. So, how do do I do that? > Do I have to specify (and maintain) the list of all supported arches in the > debian/control file Yes. On Tue, Dec 19, 2023 at 04:09:05PM -0700, Soren Stoutner wrote: > Based on the examples in 7.1 of the Policy Manual that syntax should work. > Those > examples are for defining relationships, but I would imagine it is the same > for the > Architecture field. > > https://www.debian.org/doc/debian-policy/ch-relationships.html[1] The Architecture field is not a relationships field. See https://www.debian.org/doc/debian-policy/ch-controlfields.html#architecture for its syntax.
Re: Help with GBP
On Sun, Dec 31, 2023 at 05:25:24PM +0100, Patrick ZAJDA wrote: > First of all, I switched to the branch debian/stable/master where last > bookworm backport is. > > Then I merged the tag debian/2.0.18-1 to have all commits until the version > I wish to backport. > > Firstly, when running gbp dch --bpo I cannot pass also the --commit-msg or > any commit related switch because "* unreleased" is added to the changes > list below "* Rebuild for bookworm-backports". > > How can I avoid it? > > To avoid it temporarily, I simply used dch --bpo which made things as usual > for me. > But I really want to use gbp in the cleanest way. I don't think using dch doesn't count as that. It's really optional. > In the VCS there is the commit for the changelog, then another commit which > contains the changes in its message, but this does not modify any file. > I use Git a lot but it is the first time I encounter a commit which modify > nothing. Do you mean c28a8d75ce3277b104cd195548e6252bf2dbd4e0, "Import Debian changes 2.0.15-2~bpo12+1"? I guess it's from running gbp-import-dsc, it's empty because the same package was imported that was built from the previous commit, and I don't think running it was intended or is needed.
Bug#1061111: RFS: dpkg-buildenv/1.0.0 [ITP] -- Builds debian packages in a docker container.
I see you added this tool to the list of similar tools on the wiki so you at least know about that list. So how is your tool better than other tools on that list, or at least than the ones packaged in Debian? Please also note that if you followed the procedure outlined at https://mentors.debian.net/intro-maintainers/ and filed an ITP bug before doing the packaging this discussion would happen there, not on the RFS bug.
Re: Is there a way to set up a sid environment at this time?
On Tue, Mar 12, 2024 at 07:25:56PM +0530, Shriram Ravindranathan wrote: > Dear Mentors, > > Unfortunately, my SD card got corrupted (SD Card moment) and I do not have > access to a sid environment right now. Is there a way to debootstrap a sid > environment for packaging (from trixie perhaps) while the time_t transition > is going on? You should be able to debootstrap testing and you also should be able to upgrade it to sid. This worked for me right now for amd64. -- WBR, wRAR signature.asc Description: PGP signature
Re: Is there a way to set up a sid environment at this time?
On Tue, Mar 12, 2024 at 08:54:49PM +0530, Shriram Ravindranathan wrote: > When I did a dist-upgrade from trixie it seemed to remove a bunch of > necessary packages with error messages like this: This is not my experience with a minimal debootstrapped chroot. > Although just now I noticed there are no errors when I replace trixie with > sid in sources.list and run `apt upgrade`. I suppose this would be > sufficient for packaging? If you mean upgrade instead of dist-upgrade then that's not a real sid chroot. -- WBR, wRAR signature.asc Description: PGP signature
Re: Uscan no longer works with GitLab tags
On Mon, Mar 25, 2024 at 11:57:19AM +0530, 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
uscan doesn't use grep though (at least by default?), and the matches are
not links but embedded JSON.
> 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
--
WBR, wRAR
signature.asc
Description: PGP signature
Bug#1067930: RFS: python-keep/2.10.1-1 [ITP] -- Personal shell command keeper and snippets manager
On Fri, Mar 29, 2024 at 12:52:03PM +0530, Shriram Ravindranathan wrote: > * Vcs : https://salsa.debian.org/debian/keep This doesn't exist. -- WBR, wRAR signature.asc Description: PGP signature
Re: Help on updating two python packages
On Sat, Mar 30, 2024 at 03:32:53PM -0400, Qianqian Fang wrote: > info: Hint: make sure the version in debian/changelog matches the unpacked > source tree You should do this. > for pybj, ci tasks finished ok, but the test-crossbuild-arm64 job failed > > https://salsa.debian.org/science-team/pybj/-/pipelines/659410 "/usr/bin/python3.11: Exec format error" is very weird and I cannot reproduce it on a porterbox. > also, I noticed that uscan downloads from pypi appear to include an > .egg-info folder that is not part of my git source repo. is this a problem? Why is it not a prt of your git source repo? Your upstream branch should match your orig tarball. > is monitoring github release/tag a better way or pypi is preferred? git is preferred in case PyPI tarballs are missing some files (most commonly tests). -- WBR, wRAR signature.asc Description: PGP signature
Bug#1058766: RFS: rdiffweb/2.8.7.dev41+g849af0c+dfsg-1 [ITP] -- web interface to rdiff-backup repositories
Control: tags -1 + moreinfo On Fri, Dec 15, 2023 at 03:36:19PM -0500, Patrik Dufresne wrote: > dget -x > https://mentors.debian.net/debian/pool/main/r/rdiffweb/rdiffweb_2.8.7.dev41+g849af0c+dfsg-1.dsc > > Changes for the initial release: > > rdiffweb (2.8.7.dev41+g849af0c+dfsg-1) unstable; urgency=medium > . >* Automated build Some problems I noticed after a short review: - The package FTBFS: "E: pybuild pybuild:389: test: plugin distutils failed with: exit code=5: cd /<>/.pybuild/cpython3_3.11/build; python3.11 -m pytest". - You should only have one changelog entry (also "Automated build" looks very suspicious there). - Versioned (build-)depends on gzip and coreutils are satisfiable even in oldoldstable so they shouldn't be versioned. - Standards-Version is outdated. - rdw.conf going into both examples and /etc looks incorrect. - Symlink stuff in postinst/postrm looks strange. - /etc/rdiffweb seems to be created both during the package build and in postinst. Note that some of these are detected by lintian and even shown on the mentors page. Please remove the moreinfo tag when these are addressed. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1058016: RFS: wasix-libc/0.0~git20230922.d0362cb-1 [ITP] -- wasix libc implementation for WebAssembly
Control: tags -1 + moreinfo Some issues found after a quick review: - It should have only one changelog entry. - Pre-built libclang_rt.builtins-wasm32.a should be removed from the orig.tar, assuming it's not used in the build process. - debian/rules hardcodes llvm-*-16 and clang-16 but B-D are llvm and clang, those should use versioned names too. - You should follow the comments in debian/rules and debian/watch. - An explicit build target looks unnecessary. Please remove the moreinfo tag after these are addressed. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1059643: RFS: wstroke/2.1-1 [ITP] -- Mouse gesture plugin for Wayfire.
Control: tags -1 + moreinfo Some issues found after a quick review: - There are many issues listed by lintian such as outdated compat level, outdated Standards-Version, an issue with the short description, missing Rules-Requires-Root. - There should be only one changelog entry, and in general changelog entries shouldn't list upstream changes. - Why is the package directed to experimental? - debian/copyright includes the same license texts several times instead of using common separate sections for them. - debian/patches/series is empty but present. Please remove the moreinfo tag after these are addressed. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1061051: RFS: notes-tree/1.2-1 -- a note taking app, which organizes notes in a hierarchical structure
Control: tags -1 + moreinfo There are quite a lot of issues reported by lintian so you should fix at least those before looking for sponsorship. The biggest problem is debian/changelog. Please remove the moreinfo tag after these are addressed. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1061087: RFS: bash-unit/2.1.0-1 [RFP] -- bash_unit - bash unit testing
Control: tags -1 + moreinfo
Control: retitle -1 RFS: bash-unit/2.1.0-1 [ITP] -- bash_unit - bash unit
testing
Some issues found after a quick review:
- The package should be arch:all and shouldn't use ${shlibs:Depends}.
- The GPL-3 snippet in d/copyright looks wrong.
- The upstream docs should be installed, especially the manpage.
- The manpage should be rebuilt at the package build time.
- The package has autopkgtests but no build-time tests, it should have
both if that's possible (and it should be possible in this case).
Please remove the moreinfo tag after these are addressed.
--
WBR, wRAR
signature.asc
Description: PGP signature
Bug#1062025: RFS: mistserver/3.3-1 [ITP] -- Streaming media toolkit
Control: tags -1 + moreinfo The shared libraries don't have versioned SONAMEs and so shouldn't be packaged as such until/unless the upstream fixes that or, if the upstream cannot or doesn't want to keep ABI stable, they should be packaged in the way that ensures that the dependencies track this ABI correctly. Note that lintian reports this. PLease remove the moreinfo tag after this is addressed. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1064975: RFS: k3conf/0.3-1 [ITP] -- Powerful Diagnostic Tool for Texas Instruments K3 based Processors
I have several suggestions for this: - Can you provide debian/watch? It should be possible. - debian/k3conf.1 has a *roff warning, lintian also catches it. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1066870: RFS: libudis86/0~20221013-1 [ITP] -- Disassembler for x86 and x86-64 class ISA
Control: tags -1 + moreinfo The package FTBFS: /bin/bash: line 1: /usr/bin/python3: No such file or directory Also, debian/watch is empty but present and I'm not sure about __AUTO_PERMISSIVE__ and __UNKNOWN__ in debian/copyright. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1067569: RFS: libsmb2/4.0.0-1 [ITP]-- SMB2/3 client library
Control: tags -1 + moreinfo You should provide a separate -dev package, currently the development files are shipped in the library package. There is a hardcoded Depends: libkrb5-3, why is this needed? There are unused files in debian/, such as libsmb2-dev.* and libsmb21.*. You should remove the .la file instead of fixing it, unless something needs it. You shouldn't call dh_installexamples in override_dh_install. Please remove the moreinfo tag after these are addressed. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1061087: RFS: bash-unit/2.1.0-1 [RFP] -- bash_unit - bash unit testing
On Fri, Apr 05, 2024 at 08:53:58PM +, Martin Dosch wrote: > Dear Andrey, > > thank you for the valuable feedback. I hope it is all properly settled now. > I just uploaded a new build to mentors and pushed the changes to the repo. Hi Martin, you added a B-D on itself, I assume it's to run build-time tests, buit the idea of build-time tests is to use the software being package, not the version from repos (also B-D on itself orevents it from being built). -- WBR, wRAR signature.asc Description: PGP signature
Bug#1066868: RFS: hyprland-protocols/0.2~20230811-1 [ITP] -- Wayland protocol extensions for Hyprland
Control: tags -1 + moreinfo
> The latest release of hyprland-protocols is v0.2 which is behind by a few
> commits.
Then the upstream version should be >> 0.2, e.g, 0.2+20230811, not << 0.2
as it is now.
Also, as the package is arch:all it shouldn't use ${shlibs:Depends} (which
will be emoty anyway).
--
WBR, wRAR
signature.asc
Description: PGP signature
Bug#1066873: RFS: tracy/0.10+ds-1 [ITP] -- Hybrid frame and sampling profiler
Control: tags -1 + moreinfo This FTBFS: "! LaTeX Error: File `lmodern.sty' not found." Also I think the additional notes in the changelog entry belong in README.Debian or README.source. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1066869: RFS: hyprpaper/0.6.0-1 [ITP] -- Wallpaper utility for Hyprland
Control: tags -1 + moreinfo $(MAKE) clear (as a replacement for $(MAKE) clean) should run in override_dh_auto_clean, not override_dh_clean. debian/watch is empty. There is a commented out override_dh_auto_configure. 002-add-fortify-flags.patch adds -D_FORTIFY_SOURCE=2 explicitly, but the proper fix is making the upstream build system respect the compile flags set by dpkg-buildflags. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1061087: RFS: bash-unit/2.1.0-1 [RFP] -- bash_unit - bash unit testing
On Sat, Apr 06, 2024 at 02:14:11PM +, Martin Dosch wrote: > > Hi Martin, you added a B-D on itself, I assume it's to run build-time > > tests, buit the idea of build-time tests is to use the software being > > package, > > Do you know how to achieve this? When I remove the build-dep on itself the > built fails as the test can not be performed: > >debian/rules override_dh_auto_test > > make[1]: Entering directory '/<>' > > bash_unit -f tap ./tests/test_* > > /bin/sh: 1: bash_unit: not found > > make[1]: *** [debian/rules:9: override_dh_auto_test] Error 127 You need to use bash_unit from the package. Likely as simple as "./bash_unit". -- WBR, wRAR signature.asc Description: PGP signature
Bug#1064975: RFS: k3conf/0.3-1 [ITP] -- Powerful Diagnostic Tool for Texas Instruments K3 based Processors
On Wed, Apr 10, 2024 at 12:39:47PM -0500, Andrew Davis wrote: > > - debian/k3conf.1 has a *roff warning, lintian also catches it. > > > > I don't see this warning, W: k3conf: groff-message error: automatically ending diversion 'an*link-text-div' on exit [usr/share/man/man1/k3conf.1.gz:3] Are you running lintian on the binary .changes? > it just shows "maintainer-manual-page" item. Which I know nothing about You should use lintian-explain-tags(1) to read tag descriptions. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1064975: RFS: k3conf/0.3-1 [ITP] -- Powerful Diagnostic Tool for Texas Instruments K3 based Processors
On Wed, Apr 10, 2024 at 03:05:04PM -0500, Andrew Davis wrote: > is that not right? Maybe my lintian version is old, I'm on v2.114, I'll > see if updating that helps. 2.114 is older than stable, and for packages aimed at unstable you need to use tools from unstable. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1066873: RFS: tracy/0.10+ds-1 [ITP] -- Hybrid frame and sampling profiler
On Mon, Apr 15, 2024 at 01:25:05AM +0530, Alan M Varghese wrote: > > This FTBFS: "! LaTeX Error: File `lmodern.sty' not found." > > lmodern.sty comes from the package `lmodern`. This package should be > > installed (as a transitive dep) when 'texlive-fonts-extra' is installed. No, see below. But this also means you haven't tried building your package in a minimal sid chroot. > What is the process for installing build-deps? Manually on a host system? `apt build-dep` or `mk-build-deps -ir` > `apt install texlive-fonts-extra`, the lmodern package also > gets installed. Recommends are not installed when installing build-deps. -- WBR, wRAR signature.asc Description: PGP signature
Re: Uscan no longer works with GitLab tags
On Thu, Apr 18, 2024 at 02:43:23AM +, Nilson Silva wrote: > Hey! > The purpose of this email is to contribute to the recent changes that > occurred in Gitlab with its > HTML that caused a series of errors in tracking new versions. > > Reading the wiki more specifically at this point: > https://wiki.debian.org/debian/watch#GitLab, > and trying to apply it to my case, there was no success. > > So, after some research, I came to this result: > > version=4 > opts="searchmode=plain, uversionmangle=s/\.(\d+\.\d+.\d+)//" \ > https://gitlab.com///tags?sort=updated_desc > -/archive/(\d+.\d+.\d+)/-(\d+.\d+.\d+).tar .gz Capturing the version twice and then removing the extra one via uversionmangle is really wrong (you tried to discuss this on IRC yesterday but ignored the suggestions). -- WBR, wRAR signature.asc Description: PGP signature
Re: packaging help
On Sat, May 04, 2024 at 03:44:45AM +, james smith wrote: > I am trying to package ly[1] I got everything up to the rules part, I am > stuck thinking on how to edit/make the makefile, if you have any tips or > tools that can make this a easier process, I would be much grateful You don't normally need to "edit/make the makefile". Do you have any specific problems you need hep with? -- WBR, wRAR signature.asc Description: PGP signature
Bug#1071755: RFS: open62541/1.4.1-1 [ITP] -- open62541 () is an open source implementation
Control: tags -1 + moreinfo On Fri, May 24, 2024 at 05:35:00PM +0200, Julius Pfrommer wrote: > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/open62541/ If you didn't run lintian locally (which you should), please visit this page, look at the lintian output and fix at least the big problems. Remove the moreinfo tag when you upload the fixed version. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1071821: RFS: vzlogger/0.8.6-2 Fixes FTBFS
Control: tags -1 + moreinfo On Sat, May 25, 2024 at 08:20:43AM +0200, Joachim Zobel wrote: > To access further information about this package, please visit the > following URL: > > http://www.heute-morgen.de/debian/repo/unstable/main/source/net/ > > Alternatively, you can download the package with 'dget' using this > command: > > dget -x > http://www.heute-morgen.de/debian/repo/unstable/main/source/net/vzlogger_0.8.6-2.dsc Both require authentication. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1071755: RFS: open62541/1.4.1-1 [ITP] -- open62541 () is an open source implementation
Control: tags -1 + moreinfo You shouldn't close the RFS in the changelog entry, you are expected to have an ITP and close it there. You should use the latest debhelper compat level. Why are you modifying the SONAME, and why are you doing it with patchelf? You should put the packaging repo, not the upstream repo, into the Vcs-* fields. Both libmbedtls12 and libmbedtls14 don't exist in unstable, and why are they listed explicitly in Depends? Installing .cmake files into -tools instead of -dev looks wrong. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1071755: RFS: open62541/1.4.1-1 [ITP] -- open62541 () is an open source implementation
On Tue, May 28, 2024 at 03:52:57PM +0200, Julius Pfrommer wrote: > > Why are you modifying the SONAME, and why are you doing it with patchelf? > > The intent was to do the SONAME patching entirely in the rules file. > Now we instead ship a small patch to the upstream CMakeLists.txt that > modifies the linker flags. This doesn't answer why are you changing the SONAME in a Debian-specific patch at all. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1071755: RFS: open62541/1.4.1-1 [ITP] -- open62541 () is an open source implementation
On Tue, May 28, 2024 at 05:48:10PM +0200, Julius Pfrommer wrote:
> > > The intent was to do the SONAME patching entirely in the rules file.
> > > Now we instead ship a small patch to the upstream CMakeLists.txt that
> > > modifies the linker flags.
> > This doesn't answer why are you changing the SONAME in a Debian-specific
> > patch at all.
>
> The upstream currently produces libopen62541.so.1.
>
> In order to allow the parallel installation of multiple versions it is better
> to have libopen62541.so.1.4.
ABI compatibility should drive SONAME changes, not the desire to install
multiple ABI-compatible libraries at the same time.
And Debian shouldn't deviate from the upstream unless really necessary.
> So a future version v1.5 gets libopen62541.so.1.5.
>
> The installed shared objects (and symbolic links) are now as follows.
>
> libopen62541.so -> libopen62541.so.1.4
> libopen62541.so.1.4 -> libopen62541.so.1.4.1
> libopen62541.so.1.4.1
>
> If this is acceptable we will change the upstream to always produce
> libopen62541.so.{major}.{minor} as the SONAME.
SONAME doesn't need to match the software version and shouldn't be bumped
when it's not necessary.
> This will take a few weeks until the next upstream minor release. The
> Debian-specific patch can then be removed.
>
> If you prefer a different SONAME and filename convention, just let me know.
The upstream should track the ABI compatibility properly and adjust the
SONAMEs accordingly. This is not what Debian prefers but a generic
requirement for Linux shared library projects.
--
WBR, wRAR
signature.asc
Description: PGP signature
Re: Creating packages with different configurations
On Mon, Jun 10, 2024 at 12:58:01PM +0200, Lorenzo wrote: > > If I wish to create two binary packages with different > > configurations from a single source package (e.g. to support > > different ISA levels), what's the best way to implement this? > > I'm not sure I understand, you want the same binary that uses two > different config files or you want to build from source twice with > different (mutually exclusive) configuration switch? > > If it's the latter you need to build, move the bin, clean and build > again; Or build in two dirs, like https://tracker.debian.org/media/packages/c/curl/rules-8.8.0-1 -- WBR, wRAR signature.asc Description: PGP signature
Re: Creating packages with different configurations
On Tue, Jun 11, 2024 at 07:09:15PM +, David James wrote: > These examples were exactly what I needed, thank you both. One more > thing: When running a package builder such as dpkg, does dh run once > for each item in DEB_BUILD_PROFILES? Are you really asking about DEB_BUILD_PROFILES? Because I don't think this makes sense, DEB_BUILD_PROFILES is basically a set of flags. -- WBR, wRAR signature.asc Description: PGP signature
Re: question about purge
On Sun, Jun 30, 2024 at 10:39:06AM +0200, lorenzo wrote: > Dear Mentors, > > in runit, services are defined as directories with files inside and > I'm not sure what exactly can or can't be done when a package has to > purge a service: > > if the service is below /etc, files provided by the package can > be removed even if modified, Normally no. > but the directory can't be removed if there are extra files inside. > Correct? Just leave this to dpkg. Unless by "files provided by the package" you don't mean files (and directories) actually shipped inside the package. > if the service is below /usr (or /var or /run) "/usr (or /var or /run)" sounds wrong, those are very different cases. > instead the directory can be removed entirely, disregarding extra files ? This sounds very wrong in general. > what if the service is in /home, like in user-services ? maybe symlinks > and empty directories (created by the package) can be removed, but not > files? Maintainer scripts must not touch /home. -- WBR, wRAR signature.asc Description: PGP signature
Re: question about purge
On Sun, Jun 30, 2024 at 08:08:58PM +0200, lorenzo wrote: > > > if the service is below /etc, files provided by the package can > > > be removed even if modified, > > > > Normally no. > > > > > but the directory can't be removed if there are extra files inside. > > > Correct? > > > > Just leave this to dpkg. > > Unless by "files provided by the package" you don't mean files (and > > directories) actually shipped inside the package. > > Yes that's the case, there are files, symlinks and subdirectories > created during runtime, and I need to clean up on purge. > I'm taking what dpkg does as a reference; also policy 10.7.3 and 6.8 > says something about purge, and it seems that what I described above > for /etc is correct, isn't it? Yes, it's fine to delete configuration files on purge. > > > if the service is below /usr (or /var or /run) > > > > "/usr (or /var or /run)" sounds wrong, those are very different cases. > > few runtime files are created below /run (ancient version of the > package used /var), think of something like a PIDfile or a socket, but > inside a directory. what should I do on purge? Those files should be created when a process starts and removed when it ends so it's not a job of a maintainer script to clean them. Even if for some reason they aren't cleaned properly after the process ended, they will be removed on the next reboot. > > > instead the directory can be removed entirely, disregarding extra > > > files ? > > > > This sounds very wrong in general. > > Can I set a runit policy that says that, under a very specific > directory, it will happen? I know nothing about runit or its policies. > Should I bring this to debian-devel, debian-policy or there is another > more appropriate list? Not sure what is the actual question you want to discuss there. If it's runit-specific a proper place is likely also runit-specific. > > > what if the service is in /home, like in user-services ? maybe > > > symlinks and empty directories (created by the package) can be > > > removed, but not files? > > > > Maintainer scripts must not touch /home. > > this is problematic too, as, for example, it imply that the package can > not enable or disable a user-service by default; for example, a desktop > environment with pipewire would come up with no sound by default, and > the user will have to manually stop/disable the pipewire service on > pipewire removal Is this some runit-specific problem too? It's obviously not a problem in the default installation with systemd and /usr/lib/systemd/user/pipewire.socket. -- WBR, wRAR signature.asc Description: PGP signature
Re: Just trying to run "Hello World!"
On Sun, Jun 30, 2024 at 08:56:59PM -0700, Kayven Riese wrote: > I'm the guy with the hokey cut -m thing. It was my friend's idea, and if I > would have tried a bit harder it would have occurred to me that an > additional POSIX pipe would accomplish the task. My friend keeps telling > me he got something to compile using the cut.c file, but I'm not interested > in that. Another friend has been wanting me to work on his website and in > the process I found myself mucked up on the tarballs.. so what this whole > project has sparked in me is improving my ability to work with large code > bases. On that front here, I went to this site: Please consider stopping sending these off-topic reports to Debian mailing lists. -- WBR, wRAR signature.asc Description: PGP signature
Re: Im stuck
On Thu, Jul 04, 2024 at 07:55:03AM -0300, Jeremy Theler wrote: > I'm pretty much in the same position. > > There is an RFP bug report at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068648 > but got no response. This is expected for RFPs. RFPs are "I want someone to package this" and thus they are unlikely to result in anything if nobody wants to package it. "I can maintain de package" also looks out of place in an RFP, if you actually want to package it yourself you should package it instead and I'm not sure what response you were waiting for. Please follow https://mentors.debian.net/intro-maintainers/ if you want to make a package yourself. -- WBR, wRAR signature.asc Description: PGP signature
Re: Im stuck
On Thu, Jul 04, 2024 at 01:22:29PM +0200, Daniel Gröber wrote: > > I'm pretty much in the same position. > > > > There is an RFP bug report at > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068648 > > but got no response. > > RFP means "someone else please do this", you need to file an RFS if you're > actively looking for a sponsor and want to package/maintain the package > yourself. I don't think they have a source package yet. > It also looks like you didn't CC debian-devel (sending to debian-science > instead) on the ITP I don't think they've filed an ITP. > In the future you might consider CC'ing debian-mentors on ITPs you want > sponsored anyway You don't need to CC debian-mentors on ITPs, you don't use ITPs to ask for sponsorship and RFSes are sent to debian-mentors automatically. Looks like you a very confused either by the abbreviations or by the concepts. -- WBR, wRAR signature.asc Description: PGP signature
Re: Im stuck
On Thu, Jul 04, 2024 at 02:04:01PM +0200, Daniel Gröber wrote:
> On Thu, Jul 04, 2024 at 04:30:43PM +0500, Andrey Rakhmatullin wrote:
> > You don't need to CC debian-mentors on ITPs, you don't use ITPs to ask for
> > sponsorship and RFSes are sent to debian-mentors automatically.
>
> It's complicated^{TM}. The sponsorship docs don't actually guide people on
> how to get others interested in their work
I don't think this is necessary or helpful: most RFSes are sponsored
because they are in a good shape and somebody decided to sponsor them, not
because a sponsor is actually interested in that software.
https://mentors.debian.net/sponsors/ makes sense to me: you either find a
relevant team or wait until people that sponsor random packages sponsor
yours. Knowing what does the package actually do is mostly useful to skip
ones that don't deserve sponsoring.
> Now I could have gone on a rant about how to do that properly, but figured:
> you know what, it's easier to just CC the ITP to d-mentors too since that
> ought to have the full description.
Having the ITP sent to d-mentors at some time in the past doesn't help a
sponsor looking at the RFS, especially if they do that via the
sponsorship-requests BTS page.
--
WBR, wRAR
signature.asc
Description: PGP signature
Re: Im stuck
On Thu, Jul 04, 2024 at 03:22:35PM +0200, Daniel Gröber wrote:
> > > It's complicated^{TM}. The sponsorship docs don't actually guide people on
> > > how to get others interested in their work
> >
> > I don't think this is necessary or helpful: most RFSes are sponsored
> > because they are in a good shape and somebody decided to sponsor them, not
> > because a sponsor is actually interested in that software.
> > https://mentors.debian.net/sponsors/ makes sense to me: you either find a
> > relevant team or wait until people that sponsor random packages sponsor
> > yours. Knowing what does the package actually do is mostly useful to skip
> > ones that don't deserve sponsoring.
>
> Andrey, when was the last time you requested sponsorship on a package with
> an identity that's not yet well established in the project? Perhaps you
> should try it next time you want to have something in Debian and see what
> happens.
Sorry? I know that we have a problem with not having enough sponsors and
that many RFSes, especially for new packages, are open for months, I'm
just saying that providing more info about a package won't help solve it.
--
WBR, wRAR
signature.asc
Description: PGP signature
Re: Ready stage for DD review/sponsoring - Too many DDs may spoil the broth. :-)
On Fri, Jul 12, 2024 at 05:54:59AM +0100, Phil Wyett wrote: > Morning all, > > As we embark on a new process where packages submitted to mentors are reviewed > and brought to a "Ready" stage for then busy DDs who are gracious enough to > give > their time to review and possibly sponsor into Debian. We have a unique > problem > (one which is now a nice one to have to be honest :-)) where more than one DD > may input on the same package review. > > Could submitters to mentors and DDs please ensure that only one DD is working > on > a package. This is to avoid conflicting info and also not waste valuable DD > time. If a package is taken, please find another to work on, as there are many > at the "Ready" stage. Do you also suggest to not review packages one isn't going to sponsor? Or how should this work? -- WBR, wRAR signature.asc Description: PGP signature
Re: Fwd: Looking for a mentor
On Wed, Jul 17, 2024 at 10:20:38AM -0400, Adam Danischewski wrote: > Thanks for the quick response - yes I'd like to add the package to Debian. > I have actually packaged it, but I really wasn't sure how the system > worked. Please look at https://mentors.debian.net/intro-maintainers/ to learn the procedure to add your package to Debian and maintain it there. -- WBR, wRAR signature.asc Description: PGP signature
Re: RFS or not - Was: Re: mentors review subject
On Tue, Jul 23, 2024 at 04:37:18AM +0100, Phil Wyett wrote: > > > Should we require all submissions to mentors file an RFS? > > > > > > Please discuss. :-) > > > > IMHO The existing documentation advocates already on using RFS bugs: > > > > https://mentors.debian.net/sponsors/rfs-howto/ > > "In general, sponsorship requests should be handled through the Debian > > Bug Tracking System." > > > > https://mentors.debian.net/intro-maintainers/ > > "You will be shown a RFS (request-for-sponsorship) template that you > > should send out as a bug report filed against the sponsorship-requests > > pseudo-package to draw attention to your package." > > > > There are corner cases (e.g sponsoree has already a sponsor) where an > > RFS is not needed, but as the rfs-howto says, generally it should be > > done as documented, and that is using RFS bugs. > > > > Have you experience cases where people do not file RFS bugs but should > > have? (/me only looking for RFS bugs, so I don't have that data.) > > > > Morning Tobias, > > I have experienced such cases, but usually get people to file an RFS > eventually. This takes time that I would prefer to be using for other things. > > I understand the documentation as you do, but needed wisdom to now know to be > able to advocate to mentors submitters that filing an RFS and add also the > fact that it is also likely to be looked at quicker. I don't see how is this related to *requiring* anything. There are, or at least were, basically two ways to get a sponsor if you need one: file an RFS and wait for someone to look at the RFS list or ping people/teams directly. You need to file an RFS for the former, you don't need it for the latter. In both cases it's clear in advance whether you need to file an RFS. I expect some people to be, let's say, uninformed enough to upload something to mentors, not read the docs provided on mentors and still expect to be sponsored but social problems shouldn't be solved by technical means. > No RFS because of having a sponsor. These can languish on mentors with no > ongoing information being present or added. Could an RFS also be required for > this case for clarity and we then know the supposed sponsor is aware, taken > ownership and marked as pending on bts? This sounds alien to me, but if you are going to change the meaning of an RFS then I don't have an opinion. -- WBR, wRAR signature.asc Description: PGP signature
Re: Preventing autoremoval of packages
On Thu, Aug 01, 2024 at 08:18:04AM +0300, Tommi Höynälänmaa wrote: > Hello > > Packages theme-d and theme-d-intr are to be autoremoved from testing on > August 30. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074756. I > think that this bug is a bug in guile and not in theme-d and I have filed > bug https://debbugs.gnu.org/cgi/bugreport.cgi?bug=72407 for guile. How can I > prevent the autoremoval of packages theme-d and theme-d-intr? If the bug is in guile you should reassign it accordingly. -- WBR, wRAR signature.asc Description: PGP signature
Re: Transfer foreign packaging into official repos
On Sun, Aug 04, 2024 at 01:40:16PM +, Kilian Romberg wrote: > I'm looking to include already existing Debian packaging for the > LibreWolf browser (instructions on how to obtain at > https://codeberg.org/librewolf/bsys5) in the Debian repositories. This doesn't have any Debian packaging as it used dpkg -b to build its debs. > Now I'm not sure whether any amendments need to be made to the source > package, or how the upload procedure works in general in such a case. It's not different from the normal case: you write a source package and get it sponsored. -- WBR, wRAR signature.asc Description: PGP signature
Re: watch file for Fiji
On Wed, Aug 07, 2024 at 03:25:25PM +0200, PICCA Frederic-Emmanuel wrote: > Hello, I am trying to write a watch file for Fiji > > All the version are available in this > > https://downloads.imagej.net/fiji/archive/@ANY_VERSION@/fiji-linux64.zip Where is the HTML page that lists these that uscan can download? You may need to add it to d/watch explicitly, assuming it exists. > > I tryed with the simple > > version=4 > https://downloads.imagej.net/fiji/archive/@ANY_VERSION@/fiji-linux64.zip This is malformed AFAIK. The format of the second line is "URL matching-pattern [version [script]]". -- WBR, wRAR signature.asc Description: PGP signature
Re: watch file for Fiji
On Wed, Aug 07, 2024 at 03:52:12PM +0200, PICCA Frederic-Emmanuel wrote: > i just need to download > > https://drive.switch.ch/index.php/s/WOVSIPMky2JsXsp/download [...] > Is it possible to ask for uncoditionnal download ? I don't think uscan is useful for this. -- WBR, wRAR signature.asc Description: PGP signature
Re: python-pyepics
On Thu, Aug 08, 2024 at 02:47:52PM +0200, PICCA Frederic-Emmanuel wrote:
> the python-pyepics depends on the libca-dev and libcom-deb provided by
> epics-base.
>
> The upstream hardcode the version of the API in the library name and so in
> the binary package name
>
> ii libca4.14.4:amd647.0.8.1+dfsg1-2
>amd64EPICS channel access client
> library
> ii libcom3.23.1:amd64 7.0.8.1+dfsg1-2
>amd64EPICS common library
>
>
> I would like to make python-pyepics binNMUable
>
> So I need to generate this dependency during the build of pyepics.
>
> for now the binary dependency is hardcoded like this and obviously wrong.
>
> Package: python3-pyepics
> Architecture: amd64
> Depends:
> ${python3:Depends},
> ${misc:Depends},
> python3-pkg-resources,
> libca4.14.2,
> libcom3.22.0
> Suggests: python-pyepics-doc
>
>
> what is the best way to solve this issue.
The best way to get dependencies on shared libraries is of course
dpkg-shlibdeps, but I assume there is a reason it's not used here so you
should explain why.
--
WBR, wRAR
signature.asc
Description: PGP signature
Re: python-pyepics
On Fri, Aug 09, 2024 at 11:00:27AM +0200, PICCA Frederic-Emmanuel wrote: > > The best way to get dependencies on shared libraries is of course > > dpkg-shlibdeps, but I assume there is a reason it's not used here so you > > should explain why. > > Yes but this a python binding which use ctypes, so the code is never linked > to the libraries... Then it doesn't need a specific libcaNNN. Though we cannot express this in package dependencies. -- WBR, wRAR signature.asc Description: PGP signature
Re: I would like to help
On Wed, Aug 28, 2024 at 08:35:06AM +, dblmr wrote: > So then I decided to forge ahead. I found the latest orphaned package, which > was > > png23d > > and installed it, which seemed to work, maybe. I got the following: > > Processing triggers for man-db (2.11.2-2) ... > == How can you help? (doc: https://wiki.debian.org/how-can-i-help ) == > > New packages where help is needed, including orphaned ones (from WNPP): > - png23d - https://bugs.debian.org/1079265 - O (Orphaned) > - Show old opportunities as well as new ones: how-can-i-help --old - > > at the end of the install messages. Then I went back to the instructions, and > it said to get the upstream source code in the form of a tar.gz file. My > question is this, wouldn't I just find a git repository and clone it these > days? No, Debian source packages still must include orig tarballs, and while you can clone the upstream repo to get one it's usually suboptimal. Also it looks like you are reading instructions for creating a new package from scratch, which is not relevant here. -- WBR, wRAR signature.asc Description: PGP signature
Re: Package removed from testing due to a bug not fixed in a dependency
On Sun, Sep 01, 2024 at 12:58:21PM +0200, Patrick ZAJDA wrote: > Hello, > > I maintain pidgin-skype, which depend on telepathy-haze. > telepathy-haze has been removed from testing due to #1075560 so Pidgin-Skype > is also removed. > > It looks this package has not been updated since 2022. > > What should I do? > I don't plan to fix Telepathy since I don't know it enough to do anything. > > I thought to upload a new version within removing dependency to telepathy > but I am not sure it is reasonable to do so, that's why I would need some > advice. I don't think there are other options than waiting until someone fixes it, fixing it and dropping the dep. And usually only you as the maintainer know whether it's reasonable to drop a specific dep. So the answer (not really specific to these packages) is "up to you". As more specific advice, telepathy-haze is clearly dead upstream, with the last release in 2020 and no upstream commits after it, so I would drop it if it's possible. -- WBR, wRAR signature.asc Description: PGP signature
Re: sbuild for experimental
On Thu, Sep 05, 2024 at 12:20:54PM +0200, Lorenzo wrote: > I would like to upload a package to mentors targeting experimental, > however: > > my existing experimental chroot is broken beyond repair after > sbuild-update; when I try to create a new one I get > > # # sbuild-createchroot experimental > /target/dir/experimental-amd64-sbuild If you need packages from experimental you should make a sid chroot and enable experimental in its sources.list, or just use --extra-repository. See also https://wiki.debian.org/sbuild#Enabling_experimental If you don't need packages from experimental you can build in the normal sid chroot. > > If I build on unstable chroot I get a lintian error > E: mplayer changes: distribution-and-experimental-mismatch You need to pass a correct -d. See https://wiki.debian.org/sbuild#Build_for_experimental -- WBR, wRAR signature.asc Description: PGP signature
Re: Declaring binNMU safe dependencies
On Tue, Sep 10, 2024 at 07:22:01AM +0300, Tommi Höynälänmaa wrote:
> Hello
>
> In https://wiki.debian.org/binNMU it says that declaring dependency between
> an arch: all to an arch: any package should be done by "Depends: foo (>=
> ${source:Version}), foo (<< ${source:Version}.1~)". What is the purpose of
> the latter condition?
Well, you need both the lower and the upper guard condition?
--
WBR, wRAR
signature.asc
Description: PGP signature
Re: should postrm script purge system-users?
On Fri, Dec 23, 2022 at 09:18:48PM +, Peymaneh wrote:
> Dear mentors list,
>
> a package that I maintain[1] creates a new system-user and -group ("caddy")
> and creates a homedirectory in /var/lib/caddy upon installation[2] intended
> for the systemd service file.
>
> When purging the package, all of these are currently left on the system.
>
> It was suggested to me that the not only the directories, but also user and
> group should be removed.[3] but i am unsure if purging even users from the
> system could maybe a bad idea, because they still might be owners of other
> files on the system?
>
> The debian wiki and policy only covers removal of files/dirs and does not
> seem to mention the handling of system users..
There is currently no policy on this but the project consensus is that
once created users shouldn't be removed.
See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228692
Re: Clean-room build of deb package?
On Thu, Dec 29, 2022 at 11:37:00AM -0600, Ryan Pavlik wrote: > For completeness, in addition to pbuilder/cowbuilder and sbuild, there is > also whalebuilder which uses Docker. If going for completeness, https://wiki.debian.org/SystemBuildTools#Package_build_tools lists more than these three (notably it lists 8 docker-based ones, and I'm sure there are more).
Re: gbp import-orig: how to choose compression (xz)
On Fri, Jan 27, 2023 at 06:02:34PM +0100, Lorenzo wrote: > Hello mentors, > > I want to import a new svn snapshot to update a Debian package, > the salsa git repo is already configured for gbp, so I did > > $ gbp import-orig -u1.5+svn38408 ../upstreamsvn/mplayer > > upstream/mplayer is a directory with the unpacked svn checkout. > Gbp creates a ../upstreamsvn/mplayer_1.5+svn38408.orig.tar.gz > archieve (not a tar.xz); it also uses tar.gz in the pristine-tar branch. As far as I can see this is not configurable, all locally-repacked tarballs are repacked as .tar.gz. > One problem with the tar.gz is that debian/gbp.conf has > compression = xz So this configuration is wrong ad you need to change it. > so when I push to salsa the salsa-ci fails because it searches for a > tar.xz archieve (I'm still surprised that people apparently don't build locally, only on salsa-ci)
Re: gbp import-orig: how to choose compression (xz)
On Fri, Jan 27, 2023 at 07:49:21PM +0100, Mechtilde Stehmann wrote: > Hello Lorenzo, > > please use a special gbp.conf. It would be much more useful if you provided the actual option for this. (as far as I know it doesn't exist) Unless you mean something else by "special". > More information you can get in the manpage of gbp.conf (that manpage doesn't even list actual options)
Re: gbp import-orig: how to choose compression (xz)
On Sun, Jan 29, 2023 at 03:45:26PM +0100, Lorenzo wrote: > > > One problem with the tar.gz is that debian/gbp.conf has > > > compression = xz > > So this configuration is wrong ad you need to change it. > I didn't write in my previous message, but the watch file of this > project looks for a tar.xz when downloading a new upstream release. Are you mixing released tarballs and contents of some SVN repo in the same package repo then? Or what is your workflow?
Re: gbp import-orig: how to choose compression (xz)
On Mon, Jan 30, 2023 at 12:53:24PM +0100, Lorenzo wrote: > > > > > One problem with the tar.gz is that debian/gbp.conf has > > > > > compression = xz > > > > So this configuration is wrong ad you need to change it. > > > I didn't write in my previous message, but the watch file of this > > > project looks for a tar.xz when downloading a new upstream release. > > Are you mixing released tarballs and contents of some SVN repo in the > > same package repo then? Or what is your workflow? > > Yes, the latest upstream release (mplayer 1.5) has CVEs and fails to > build, so I jumped from 1.4 to 1.5+svn Is this a one-time thing? If so, I would just create a tarball manually. But overall you need to make sure the SVN repo contains the same files as the published tarball, otherwise the compression difference is not the largest problem you could have. Also, the best way is probably submitting a patch for gbp to make the repacked tarball compression configurable.
Re: gbp import-orig: how to choose compression (xz)
On Mon, Jan 30, 2023 at 08:30:26PM +0100, Lorenzo wrote: > > But overall you need to make sure the SVN repo contains the > > same files as the published tarball, otherwise the compression > > difference is not the largest problem you could have. > right, I should have excluded the .svn directory from the source.. > apart from that I don't think there are other relevant difference. > Is there a document that describes the right steps to follow when > importing a git or svn snapshot in Debian? I couldn't find one. You normally don't need to do anything special when doing that as opposed to when importing tarballs, though you may need to run some additional commands (e.g. autoreconf) that are normally done when the source tarball is created in the software release process (this obviously depends on the project specifics and may not be needed at all). This is assuming the repo contains everything needed and the source tarball isn't e.g. created from the repo and some external files. And the need to run these additional commands is exactly because the contents of a repo and a tarball are different, in which case interleaved imports of both of them will have weird effects on the file history and may also require changing d/rules back and forth.
Re: pip install --user broken in debian testing?
On Sun, Feb 26, 2023 at 08:36:20PM +, Barry Scott wrote: > > That's the new intended behavior. I you want non-debian python packages, > > install them in a non-debian python via virtual environments. > > The idea is to prevent installing into /usr not preventing install in $USER I > hope. You can read the idea in the document that was linked in the message you got. To quote it, "This applies both to system-wide installs (sudo pip install) as well as user home directory installs (pip install --user), since packages in either location show up on the sys.path of /usr/bin/python3." Please aso note that debian-mentors@ is not a support channel, that would be debian-user@.
Re: autoconf injects strchr without including string.h
On Wed, Sep 25, 2024 at 11:47:09AM +0200, Andreas Tille wrote: > Hi, > > I intend to work on the latest version of xserver-xorg-input-keyboard/ since > it showed up as candidate for the Bug of the Day[1]. Unfortunately the latest > upstream version does not build[2]: > > ... > configure:12876: checking for gcc options needed to detect all undeclared > functions No, that's not the reason for the failure (failing conftest programs are normal and expected in certain checks and "detect all undeclared functions" definitely sounds like one). The reason for the failure is "configure: error: This is not the keyboard driver you are looking for. Use evdev or libinput.". Which makes sense. The actual check for that (see configure.ac) is literally """ case $host_os in linux*) """ . -- WBR, wRAR signature.asc Description: PGP signature
