Re: FWD: Copyright in LGPL projects
On Tue, Mar 05, 2024 at 03:50:27AM +0530, Alan M Varghese wrote: > What I meant was that upstream does not know where to put the copyright > information or > how it should be formatted. Or, to rephrase, is there a preferred format for > a COPYRIGHT file > in a project that uses LGPL? There are no special formats for copyright files and the license shouldn't matter so I'm still not sure what's the actual question they have. In most software the top-level copyright is simply stated as one line in the top-level LICENSE or whatever file or even in the top-level README, and separate per-file copyrights are stated in the files themselves. The calibre one you linked is very unusual. -- WBR, wRAR signature.asc Description: PGP signature
Re: FWD: Copyright in LGPL projects
On Tue, Mar 05, 2024 at 12:38:00AM +0530, Alan M Varghese wrote: > Hello Soren, > > Thank you for answering my queries. > > I will share this with the upstream project. The project authors are unsure > how > to do this for an LGPL project. I will see tomorrow if I can find an example > of > an LGPL project that includes the copyright information in the root of the > project. > (I found a project that does this for GPL[1], but not for LGPL). Why would that make a difference? -- WBR, wRAR signature.asc Description: PGP signature
Re: Maintaining a Package as a Non-Software Developer
On Wed, Feb 28, 2024 at 06:28:15AM +0100, earache_curtsy...@simplelogin.com wrote: > Hello Debian Mentors, > > I am a sysadmin who manages dozens of Debian servers. I also use Debian for > my personal computing. I am very thankful to the Debian project and would > love to give back to it somehow. > > I was thinking that maintaining one or more packages would be a great way to > do this. I know a bit of Java and C but do not write code on a regular basis > (other than bash scripts). > > I am asking for a sanity check on whether or not this is a good idea, or if > the work of maintaining a package is only plausible for highly skilled > software engineers. There are many packages that don't contain code or contain some simple things. There are also many software projects that are trivial to package and maintain because they are written using all the best practices and never get serious breakages requiring the maintainer to study and fix the code. -- WBR, wRAR signature.asc Description: PGP signature
Re: HELP - package not arrived
On Fri, Nov 25, 2022 at 10:23:26PM +1100, David Bannon wrote: > OK, my dput.cf has "fqdn = mentors.debian.net", I assumed that was that was > for. It has it in a section named "mentors" and you didn't tell dput to use that section. And https://mentors.debian.net/intro-maintainers/ tells to both create the section and pass its name to dput. -- WBR, wRAR signature.asc Description: PGP signature
Re: mix upstream files from git tag and git branch to build orig.tar
On Sat, Nov 05, 2022 at 10:27:47AM +0100, Fab Stz wrote: > Hello, > > While packaging php-codeigniter-framework [1], I wanted to run the test suite > specifically on PHP 8.2. > > Although I use the git repository as source of upstream as stated here in [2] > I just noticed that the test suite is not shipped on the tag. > > However the test suite is available on the git branches. > > Any idea on how I could update the package from the git tags by still using d/ > watch for the released tags and also get the "tests" directory from the > branches of the git repository? Make a patch that adds them, or ship them in debian/something and copy them to the necessary location (if needed) at the build time. > It guess doing that way would mean that we build a version name with a +ds > suffix like "3.1.13+ds.1-1". Yes if you create the tarball manually. I don't think existing tools can help you with this and so you won't be able to use uscan to recreate it. > Or should I use the "components" feature of uscan and have a tarball named > php-codeigniter-framework_3.1.13.orig-test.tar.xz? But how to exclude the > unwanted directories then? I wouldn't recommend this. -- WBR, wRAR signature.asc Description: PGP signature
Re: Debian source file name update
On Wed, Nov 02, 2022 at 06:52:10PM +0530, probal basak wrote: > I need one small help regarding debian packaging. Do you intend to upload this to the official Debian archive? > I have a watch file like this: > version=4 > > opts="mode=git, pgpmode=none" \ > https://github.com/zynthbox/zynthbox-z2-setup HEAD > > And the changelog file like: > zynthbox-z2-setup (0.5-1) buster; urgency=medium > > * Initial release > > The source that is being generated by uscan is > zynthbox-z2-setup_0.0~git20220914.01d0f64.orig.tar.xz This indeed sounds like a correct outcome for mode=git with HEAD requested. > How can I achieve so that the orig tar xz has 0.5 instead of 0.0 in the > version without the git hash? > Like: zynthbox-z2-setup_0.5.orig.tar.xz There is no 0.5, (or v0.5 or something like that) tag in the upstream repo, only "v0.5-1" so there is no clean way to do that unless the upstream fixes their tag naming. -- WBR, wRAR signature.asc Description: PGP signature
Re: Self dependent package, build profiles and buildd servers
On Tue, Sep 20, 2022 at 01:20:19PM +0200, Fab Stz wrote: > Ok I just tried this by adding dependent targets in d/rules. You don't really need "dependent targets in d/rules" for this, just making sure both builds run from the usual dh targets. In many cases this is done by calling two build commands from override_dh_auto_build. > The d/rules actually configures/builds first the host-build, which I'm able > to > use directly in the configuration parameters when configuring/building the > android-build (which is the second build performed automatically). Good, so the thing you said isn't possible is actually possible? Then it solves the original problem. -- WBR, wRAR signature.asc Description: PGP signature
Re: Re: Self dependent package, build profiles
On Sat, Sep 17, 2022 at 01:12:07AM +0500, Andrey Rahmatullin wrote: > On Fri, Sep 16, 2022 at 09:57:31PM +0200, Fab Stz wrote: > > > Why do you need bin-pkg-A for this? You already build it during the same > > > build process. Do you 100% need the files installed into the system > > > locations? > > > > Unfortunately that's the way upstream works (it is to build Qt for Android > > which requires what they call a host-build that I named bin-pkg-A). > And does it always need the same version? (so every upload must be dome > twice)? (well, at least every new upsream version upload, I guess, but still) -- WBR, wRAR signature.asc Description: PGP signature
Re: Re: Self dependent package, build profiles
On Fri, Sep 16, 2022 at 09:57:31PM +0200, Fab Stz wrote: > > Why do you need bin-pkg-A for this? You already build it during the same > > build process. Do you 100% need the files installed into the system > > locations? > > Unfortunately that's the way upstream works (it is to build Qt for Android > which requires what they call a host-build that I named bin-pkg-A). And does it always need the same version? (so every upload must be dome twice)? -- WBR, wRAR signature.asc Description: PGP signature
Re: Self dependent package, build profiles & buildd servers
On Fri, Sep 16, 2022 at 07:53:57PM +0200, Fab Stz wrote: > Hello, > > I already read a few times the page on the DEB_BUILD_PROFILES [1] but I still > don't really get it on how it actually works when one package has a self > dependency. > > I have a package, let's name it "src-pkg", that needs to be built first to > create the binary package, let's name it "bin-pkg-A". > > Once this "bin-pkg-A" is ready, I have to build another binary package (still > from src-pkg but with other configure options) that would be named "bin-pkg- > B". Why do you need bin-pkg-A for this? You already build it during the same build process. Do you 100% need the files installed into the system locations? -- WBR, wRAR signature.asc Description: PGP signature
Re: how to manage packages that require native acceleration code
On Mon, Sep 12, 2022 at 05:25:27PM -0400, Aaron Boxer wrote: > Thanks, Andrey. I have fixed this problem. v10.0,0 has just been uploaded > to unstable - would you > recommend releasing a new version 10.0.1 with these fixes, or is there a > way of updating v10.0.0 ? You can upload 10.0.0-2. -- WBR, wRAR signature.asc Description: PGP signature
Re: how to manage packages that require native acceleration code
On Mon, Sep 12, 2022 at 10:05:36AM -0400, Aaron Boxer wrote: > My codec project uses SIMD code for x86 and AArch64 architectures. Also, as > there are different versions of SIMD i.e. SSE vs AVX vs AVX2, the project > uses a library that builds multiple versions of the accelerated code and > chooses which version to use at runtime. This sounds good. > My package currently has a `march-native` error logged for certain > architectures. -march=native is not compatible with the approach you just described. And you indeed must not use it when building packages. -- WBR, wRAR signature.asc Description: PGP signature
Re: lintian warning on libgrokj2k: executable-stack-in-shared-library
On Mon, Sep 12, 2022 at 08:49:53AM -0400, Aaron Boxer wrote: > mips66el is not a target platform What do you mean? -- WBR, wRAR signature.asc Description: PGP signature
Re: lintian warning on libgrokj2k: executable-stack-in-shared-library
On Mon, Sep 12, 2022 at 08:37:34AM -0400, Aaron Boxer wrote: > Here is the warning report > > https://udd.debian.org/lintian/?packages=libgrokj2k It happens on mips* in other packages too. > I ran `readelf -l` on the .so, and I noticed that there is no E flag > on the GNU_STACK entry. So, it looks like this is a false positive. On the .so from mips64el? -- WBR, wRAR signature.asc Description: PGP signature
Re: Defer postinst after a given package
On Fri, Sep 09, 2022 at 10:32:18AM +0200, Fab Stz wrote: > Hi, > > I have a package B that depends on gradle, which depends on Java. > B doesn't have a dependency to Java set in d/control. > > B runs a postinst script which requires Java. "The Depends field should also be used if the postinst or prerm scripts require the depended-on package to be unpacked or configured in order to run." https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends -- WBR, wRAR signature.asc Description: PGP signature
Re: Free component in a non-free tarball
On Wed, Aug 31, 2022 at 07:44:55AM +0200, Thomas Dettbarn wrote: > Chipping in my 2 cents here... > > > > > On the "policy"/legal question of whether it's permissible to package > > the internal open source in this larger source for the Debian project, I > > have no specific opinion but it sounds complicated. You might > > I do. Remember the GPL's mantra: "Free as in speech". The software should be > available for anyone, > without any obstacles in obtaining it. To me, it is clearly a violation of > its own license. That's not what the licenses, including GPL, usually say, no. > Having to register to download software is not free software. It is open > source. That is a difference. No. -- WBR, wRAR signature.asc Description: PGP signature
Re: Package does not show up and no REJECT e-mail
On Sat, Aug 27, 2022 at 09:34:57AM -0700, Steve M wrote: > > > > > Successfully uploaded swift_5.6.2-1.dsc to mentors.debian.net for > > > > > mentors. > > > > Note that there is already a package called "swift" in the archive. > > > > > > This made me go look at the REJECTED e-mail again and I noticed it says > > > "Unfortunately your package "swift" was rejected". That's not right. My > > > package > > > is "swiftlang" > > No, your source package is named "swift". > So then maybe I did it all correctly to have my package named "swiftlang" and > my > upstream named "swift"? It took me a while to get the build tools to be happy > so > I thought I must have. You didn't, as, like as I said and the quote line proves, your source package name is "swift". > > > something correctly there. I am aware of the existing package "swift" and > > > my > > > package is marked as being a conflict with it due to both packages having > > > binaries named "swift". > > This is wrong as well, see > > https://www.debian.org/doc/debian-policy/ch-files.html#binaries > > I had to read that policy a few times, but now I see that I am not allowed to > use the "conflicts" mechanism is this situation. My "swift" binary is actually > just a symbolic link to "swift-frontend", but it is the main mechanism by > which > the compiler and REPL is called. Also, "swiftc" is also a symbolic link to > that > same "swift-frontend" so it might be possible to simply drop "swift" and > depend > on "swiftc" which would then only be an issue for people trying to follow > documentation that tells then to run the "swift" command. Should I now reach > out > to debian-devel to ask about it? You can try that, yes, but generally it should be an upstream decision. -- WBR, wRAR signature.asc Description: PGP signature
Re: Package does not show up and no REJECT e-mail
On Sat, Aug 27, 2022 at 12:23:51AM -0700, Steve M wrote: > > > Successfully uploaded swift_5.6.2-1.dsc to mentors.debian.net for mentors. > > Note that there is already a package called "swift" in the archive. > > This made me go look at the REJECTED e-mail again and I noticed it says > "Unfortunately your package "swift" was rejected". That's not right. My > package > is "swiftlang" and the upstream name is "swift" so I've clearly not done > something correctly there. I am aware of the existing package "swift" and my > package is marked as being a conflict with it due to both packages having > binaries named "swift". Also, what is the ITP bug number for this package? -- WBR, wRAR signature.asc Description: PGP signature
Re: Package does not show up and no REJECT e-mail
On Sat, Aug 27, 2022 at 12:23:51AM -0700, Steve M wrote: > > > Successfully uploaded swift_5.6.2-1.dsc to mentors.debian.net for mentors. > > Note that there is already a package called "swift" in the archive. > > This made me go look at the REJECTED e-mail again and I noticed it says > "Unfortunately your package "swift" was rejected". That's not right. My > package > is "swiftlang" No, your source package is named "swift". > something correctly there. I am aware of the existing package "swift" and my > package is marked as being a conflict with it due to both packages having > binaries named "swift". This is wrong as well, see https://www.debian.org/doc/debian-policy/ch-files.html#binaries -- WBR, wRAR signature.asc Description: PGP signature
Re: Package does not show up and no REJECT e-mail
On Fri, Aug 26, 2022 at 11:30:09PM -0700, Steve M wrote: > My apologies for making another "my package won't show up" thread, but that is > my problem and I can't figure it out. My package "swiftlang" takes about 3 > hours > to build and uses about 23GiB of disk space, so that may play a role. Mentors doesn't build binary packages, no. > My first upload on Tuesday afternoon resulted in a REJECT e-mail due to an > error > in the d/copyright file. Oh, does mentors do REJECTs now? > Successfully uploaded swift_5.6.2-1.dsc to mentors.debian.net for mentors. Note that there is already a package called "swift" in the archive. -- WBR, wRAR signature.asc Description: PGP signature
Re: Looking for a sponsor for bandcamp-dl
On Tue, Aug 23, 2022 at 11:41:06PM +0100, scupake wrote: > Hello! > > I recently packaged bandcamp-dl and I am looking for someone to review > and sponsor it, it is my first package for a Python program, so there > might be some mistakes. > Here's the link: https://salsa.debian.org/Scupake/bandcamp-dl > And thank you for taking time to read this. Please follow https://mentors.debian.net/sponsors/ -- WBR, wRAR signature.asc Description: PGP signature
Re: Should I give up?
On Mon, Aug 15, 2022 at 02:32:43PM +, Thomas Ward wrote: > When there's a rejected package there should be a rejection reason. > That's where you should start. Don't be discouraged, I've had my > packages rejected before (note: I'm not a mentor / DD, but I have been > through this process before), it hasn't stopped me from contributing > anywhere yet. Usually, when there's a rejection, there's a *reason* for > it and that reason should be documented somewhere and sent to you via > email - I would look for those rejection emails and see what the > reasoning was for the rejection. That's not the stated reason though: > the thought of having to wait several months again to see if everything is > acceptable is really discouraging -- WBR, wRAR signature.asc Description: PGP signature
Re: Automated uploading of packages?
On Mon, Jul 18, 2022 at 08:25:05PM +0200, David Given wrote: > At first glance this seems a bit problematic, as it would require uploading > packages which haven't been reviewed by a human. I'd be relying on the > automation to spot any potential problems. But, if the packaging's not > changing --- which should be detectable --- I'm not sure that a human > review adds much value. Ideally, though I have no idea how often this happens in practice, you should actually test your package manually before uploading it. -- WBR, wRAR signature.asc Description: PGP signature
Re: Error when building using iconv to convert problematic encondings to UTF-8
On Mon, Jul 11, 2022 at 08:18:43PM +0200, Jose G. López wrote: > I'm working on importing a new upstream version for scid package and I want > to get rid of "national-encoding" lintian warning. Are you sure converting that file is useful and won't break the software for the use cases when this file is used? > --- Output --- > iconv -f ISO-8859-15 -t UTF-8 -o > /home/josgalo/devel/debian/packaging/scid/build-area/scid-4.7.4+dfsg1/debian/tmp/scid/usr/share/scid/tcl/lang/hungary.tcl > \ > > /home/josgalo/devel/debian/packaging/scid/build-area/scid-4.7.4+dfsg1/debian/tmp/scid/usr/share/scid/tcl/lang/hungary.tcl Your input and output file is the same. Looks like iconv crashes with SIGBUS in this case, instead of just silently truncating the file or something like that, as many other tools would do in this case. If you really want to convert the file, you need to output the result to a different file and then move it to the old location. > make[1]: *** [debian/rules:23: override_dh_auto_install] Error del bus Please run your commands with LANG=C if you intend to show the output when asking for help. -- WBR, wRAR signature.asc Description: PGP signature
Re: memory consumption in deb9 vs deb10.
On Sat, Jul 02, 2022 at 08:04:15PM +0100, Emyr Williams wrote: > Hi Anu, > > How can we replicate the conditions? Your e-mail isn't clear, what compiler > arguments did you use? And what metrics are you using to measure memory > usage? Please note that debian-mentors is not a good place for such questions. I will even say that the question is most likely not specific to Debian at all. -- WBR, wRAR signature.asc Description: PGP signature
Re: Can I know how to resolve the error "No public key found for key"
On Sat, Jul 02, 2022 at 07:53:40PM +0900, Makoto Yamashita wrote: > Dear whom it may concern, > > Thank you very much for reading my email. > I am a maintainer of the SDPA package and I am trying to > upload a modified file, but I received the following mail. Upload where? -- WBR, wRAR signature.asc Description: PGP signature
Bug#1013315: RFS: workflow/0.10.1-1 [RC] -- Parallel computing and asynchronous web server engine
On Wed, Jun 22, 2022 at 02:56:14PM +, Lance Lin wrote: > Hi Bastian, > > > You need Breaks: and Replaces: on the libworkflow0 package. > > Sorry to bother you about this but I am still having a very hard time. > > I've tried to search on my own and look at Debian resources: > https://wiki.debian.org/PackageTransition > > I've tried: > Breaks/Replaces: (<= libworkflow1 0.9.10) - the previous version > Breaks/Replaces: (<< libworkflow1 0.9.10-1) > Breaks/Replaces: (<< libworkflow1 0.9.10~) > Breaks/Replaces: (<< libworkflow1 0.9.10) > > And none of it seems to work. What am I missing? I will still have this > problem on SRPC that will need to be fixed before it is uploaded as well. How are you testing this? And where are you adding these fields? libworkflow0 or libworkflow-dev? -- WBR, wRAR signature.asc Description: PGP signature
Re: Preventing a broken release arch from blocking testing migration
On Fri, Jun 17, 2022 at 02:01:42PM +0200, Daniel Gröber wrote: > my package yosys has a test failure on mips64el that I can't figure out and > consequently got removed from testing. I'm wondering how to deal with this? > > From reading the policy it seems I can use the Architecture field to list > all arches except mips64el. Is that the right thing to do here? Well, ideally you should fix the test or the software. If that's impossible then yeah. > I also wonder if there is a way to specify "everything except mips64el" > instead of listing all arches explicitly? Unfortunately no. -- WBR, wRAR signature.asc Description: PGP signature
Re: Specifying "Build Type: all" using sbuild
On Wed, Jun 01, 2022 at 03:54:05PM +0200, Hilmar Preuße wrote: > I'm very sorry! Looking at the build log I don't see a line containing the > string "Arch type". Exactly. > Please Could you go into detail? I think you should re-read your previous emails. -- WBR, wRAR signature.asc Description: PGP signature
Re: Specifying "Build Type: all" using sbuild
On Wed, Jun 01, 2022 at 01:43:12PM +0200, Hilmar Preuße wrote: > > > I had a look at the manual page. The build log (see both links) > > > makes a difference between "Arch type" and "Build type". > > Does it? > > Do you mean "Build Architecture" instead? > > > > No. Have a look at the links I posted: I did that before askingI did that before asking. > Package: texlive-bin > Version: 2022.20220321.62855-3 > Source Version: 2022.20220321.62855-3 > Distribution: sid > Machine Architecture: amd64 > Host Architecture: amd64 > Build Architecture: amd64 > Build Type: all > > vs. > > Package: texlive-bin > Version: 2022.20220321.62855-3 > Source Version: 2022.20220321.62855-3 > Distribution: sid > Machine Architecture: amd64 > Host Architecture: amd64 > Build Architecture: amd64 > Build Type: any > > Hilmar Can you please point at the "Arch type" lines? -- WBR, wRAR signature.asc Description: PGP signature
Re: Specifying "Build Type: all" using sbuild
On Wed, Jun 01, 2022 at 01:20:34PM +0200, Hilmar Preuße wrote: > > You can use the "--arch-all --no-arch-any" combination of options > > (--no-arch-any being the important part). Generally speaking, sbuild > > provides a lot of useful options, I encourage you to read its man page > > so you get an idea of what's available. > > > > I had a look at the manual page. The build log (see both links) makes a > difference between "Arch type" and "Build type". Does it? Do you mean "Build Architecture" instead? > I'm wondering if the switch "--arch-all" impacts the Arch or the build type. --arch-all enables building "Architecture: all" packages, as the manpage says. That's the thing that matters, not log lines. -- WBR, wRAR signature.asc Description: PGP signature
Re: Few questions about updating the dia package
On Thu, May 26, 2022 at 11:31:22PM +0200, Philippe SWARTVAGHER wrote: > - dpkg-shlibdeps: warning: can't extract name and version from library > name 'libdia.so' I think you can ignore these. > - W: dia source: debian-rules-sets-DEB_BUILD_OPTIONS (line 10) > > Parallel builds may cause a build error with dia (a header file isn't > found). To disable parallel builds, I added in d/rules: > > export DEB_BUILD_OPTIONS = parallel=1 > > lintian says I should rename DEB_BUILD_OPTIONS to > DEB_BUILD_MAINT_OPTIONS, but when I add parallel=1 to > DEB_BUILD_MAINT_OPTIONS, the parallel=1 instruction is ignored... You should pass --no-parallel to dh(1) instead. > - W: dia-dbgsym: elf-error In program headers: Unable to find program > interpreter name > [usr/lib/debug/.build-id/82/7909d9da4f9c6253d5235a76b6fe4513c8ebf7.debug] > > I don't even know how to start investigating on this warning since the > mentioned file doesn't exist once the package is built... This is a lintian false positive. -- WBR, wRAR signature.asc Description: PGP signature
Re: quilt patch (hunk ignored)
On Thu, May 19, 2022 at 07:17:11PM +0800, Bo YU wrote: > > > But if use the same way to apply patch into d/*, sometime it will get: > > Patches shouldn't patch files in debian/. Edit the files directly. > > > Understood it. here is SO[0] to hint it. > > But this is inconvenient: *shrug* > * if to modify many files in d/* or code snip and want to keep a clean status > to watch different parts on many times modify. Not sure what does this mean but it's possible that a VCS can help here. > * send these modify to the package's maintainer You should send a debdiff, not a patch from debian/patches/. -- WBR, wRAR signature.asc Description: PGP signature
Re: quilt patch (hunk ignored)
On Thu, May 19, 2022 at 06:57:27PM +0800, Bo YU wrote: > Hi, > > I followed the instructions[0]&[1] to generate/apply patch. It is ok if i > the patch file be applied out of debian/*.: > > // for people who if need it > *quilt push -a > * quilt new fix-issue.patch > * quilt add source-code-file(out of the d/*) > * quilt refresh > * quilt header -e > * quilt pop -a > > But if use the same way to apply patch into d/*, sometime it will get: Patches shouldn't patch files in debian/. Edit the files directly. -- WBR, wRAR signature.asc Description: PGP signature
Re: Backport version number problem.
On Mon, May 02, 2022 at 09:45:56AM +0200, Alec Leamas wrote: > I'm about to backport opencpn from Sid to backports-sloppy, running into > versioning problems. > > The Sid version is 5.6.2+dfsg-1. The sloppy version should then be something > like 5.6.2+dfsg-1~bpo10.1. > > However, it has been necessary to repack the backport. This is a about a > dependency which is available in Bullseye+, but not in Buster. Put the dep into buster-backports-sloppy? -- WBR, wRAR signature.asc Description: PGP signature
Re: Might failed builds for unofficial ports block migration?
On Fri, Apr 29, 2022 at 08:17:15AM +0200, Markus Blatt wrote: > I am currently preparing/testing Debian packages of the upcoming OPM release > by uploading them to experimental. I noted that packages for both hppa and > riscv64 > are failing for this release of opm-common [1] that did build before. riscv64 > [2] might > be a compiler issue of g++-12 and hence not happen unstable. For hppa [3] it > is due > to added tests which fail because wrong treatment of endianness. > > Both are "unofficial ports". Would these failing builds block migration to > testing > if uploaded to unstable? No. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [RFP] -- Open the system file manager and optionally select files in it
On Sun, Apr 24, 2022 at 10:32:05PM +0200, Tino Mettler wrote: > > You have actually configured it in the package, so it would be better if > > it actually works. :) Try just running `autopkgtest` in the source > > directory.. > > > > https://wiki.debian.org/ContinuousIntegration/autopkgtest > > Hi, > > I was not aware that the package defines any test specific bits. Can you > point me to the relevant part? I had the impression that a package needs to > define the tests in debian/tests/, and the showinfilemanager package does not > have a debian/tests directory. All Python module packages have a minimal automatic autopkgtest that tries to import the module. Make sure the module name used by the test is correct, and if it isn't you should set the correct one in debian/tests/autopkgtest-pkg-python.conf (see e.g. python-xlib and the relevant documentation in autodep8(1)). -- WBR, wRAR signature.asc Description: PGP signature
Bug#1009658: RFS: ncdu/1.16-0.1 [NMU] -- ncurses disk usage viewer
On Thu, Apr 21, 2022 at 02:49:42PM +0200, Santiago Ruano Rincón wrote: > > ncdu (1.16-0.1) unstable; urgency=medium > > Is it really urgency=medium? low wouldn't fit? medium is the default urgency since Nov 2013. -- WBR, wRAR signature.asc Description: PGP signature
Re: Debuild question
On Wed, Apr 20, 2022 at 10:53:53AM +0800, あきら wrote: > Hellow, > I'm new to debian packaging, so I have a question troubling me for a long > time, which is about debuild -Inothing, what does this do, and its effect. What is the context of this question? If you don't know what is this, don't use it? -- WBR, wRAR signature.asc Description: PGP signature
Bug#1009313: RFS: nginx/1.18.0-10 -- small, powerful, scalable web/proxy server
On Tue, Apr 12, 2022 at 04:02:14PM +0800, Miao Wang wrote: > >> I intended to leave it UNRELEASED so it can serve as a request for > >> comment. However, every time I upload an UNRELEASED package, it gets > >> deleted automatically. As a result, I have to set the codename to unstable > >> for successful uploading. > > > > You misunderstood. You left a -9 revision UNRELELEASED and skipped it while > > publishing a -10 revision. > > Yes, it is intended, because currently the version number of nginx is -9 in > https://salsa.debian.org/nginx-team/nginx/-/blob/master/debian/changelog No, the current version of nginx in the archive is -8. Normally you are supposed to update an UNRELEASED entry in a VCS with your changes and release it. -- WBR, wRAR signature.asc Description: PGP signature
Re: Soname bumps, new binary packages - NEW/BY-HAND queue uploading?
On Wed, Apr 06, 2022 at 03:36:31PM +0100, Philip Wyett wrote: > > > Could someone point me to the documentation that relates to upload of > > > packages that have new > > > binary > > > packages i.e. name change during an update? Specifically to the > > > new/by-hand queue. > > Can you explain the context for this? You never need to do anything > > special to put a package into NEW. > This was just related to libfilezilla that has regular API soname bumps. > > My question was answered by Adam (kilobyte) that upload of such packages need > to be a sponsored > upload even if a DM. Please note that your question didn't mention the DM context. -- WBR, wRAR signature.asc Description: PGP signature
Re: Soname bumps, new binary packages - NEW/BY-HAND queue uploading?
On Wed, Apr 06, 2022 at 03:37:33PM +0100, Philip Wyett wrote: > > > Could someone point me to the documentation that relates to upload of > > > packages that have new > > > binary > > > packages i.e. name change during an update? Specifically to the > > > new/by-hand queue. > > > > Dunno where the docs are, but in short: > > > > * rename the binary package: > > + edit debian/control > > + mv debian/libfoo42.* → libfoo43.* > > + "git grep libfoo42" elsewhere, just to be sure > > * [optional but strongly recommended] test the library's users > > * request a sponsored upload even if you're a DM > > * once it passes NEW, its users might need a binNMU to rebuild with the new > > soname > > > > For a sane library, that's it. > > > > On the other hand, if the -dev package name changes as well, it's > > effectively a new package; usually co-installable with the old version. > > > > > > Meow! > > Thanks Adam, that answered it for me. I will do a mentors upload later on. If you were actually asking about the whole procedure, and not about NEW, please read and follow https://wiki.debian.org/Teams/ReleaseTeam/Transitions -- WBR, wRAR signature.asc Description: PGP signature
Re: Soname bumps, new binary packages - NEW/BY-HAND queue uploading?
On Wed, Apr 06, 2022 at 03:02:07PM +0100, Philip Wyett wrote: > Could someone point me to the documentation that relates to upload of > packages that have new binary > packages i.e. name change during an update? Specifically to the new/by-hand > queue. Can you explain the context for this? You never need to do anything special to put a package into NEW. -- WBR, wRAR signature.asc Description: PGP signature
Re: Feedback on post{inst,rm}-scripts?
On Mon, Apr 04, 2022 at 07:56:20AM +, Peymaneh wrote: > Originally, the app would download the whole container image at first use > after Installation. For the new version upstream has decided to include > build a whole Container-Image at build time and include the 700MB image in > the .deb package. > > The absurd package size set aside, building the image on the Debian build > servers would not be possible because a network connection is required for > pulling the docker image. > Therefore I moved the building of the image from build time into > dangerzone.postinst[2], which is basically the build-script from upstream[3] > only with some very basic error-handling added to it. I am not sure if in > its current state it is very robust. If you download external files on install, the package should go to contrib and, I think, prominently say that it will do this. I also don't think you should keep the downloaded files in /usr instead of e.g. /var. -- WBR, wRAR signature.asc Description: PGP signature
Re: toshiba video
On Sat, Apr 02, 2022 at 02:25:37PM -0400, Noah Sombrero wrote: > I installed deb 11.3 on my old toshiba satellite laptop (p25 s509), > yes p4, 1.25 gb ram. It should work, and it does except that the > display is offset to the top and the right. I have not found any > reference on the web that shows how to adjust that, although there are > some before xrandr when xorg.conf was still used, that might have done > it. Since then, everything is supposed to be automatic and simply > work. No workee. > > I suspect it is a video driver issue, but there doesn't seem to be a > source for the NVIDIA® GeForce FX Go5200, not even from nvidia. I > did find a good online source for the original toshiba laptop drivers > but they are for win xp, nothing for linux. > > Is there some way to fix this? Am I asking in the right place? No, the support ML is debian-user@. -- WBR, wRAR signature.asc Description: PGP signature
Re: Dealing with library using upstream version as SOVERSION
On Fri, Apr 01, 2022 at 03:54:35PM +0200, Daniel Gröber wrote: > Hi debian-mentors, > > I'm working on packaging [vpp] which installs a number of shared libraries > that may want to be used by other Debian packages in the future. > > [vpp]: https://github.com/fdio/vpp/ > > However upstream just uses their release version in SONAME which doesn't > seem very useful. This suggests they don't know or don't care about ABI stability. > Is it good form to override this in the Debian package No, both because Debian-specific sonames are often a bad idea and because to do this correctly you need to track the ABI yourself. > or should I conform to what upstream is doing and deal with the fallout > once a reverse dependency is actually introduced and a new release comes > out? Ideally this should be fixed at the upstream side, unless they explicitly declare that they don't keep the ABI stable. -- WBR, wRAR signature.asc Description: PGP signature
Re: Re: Fixes that would close ITP bugs 671296 and 1006705
On Wed, Mar 30, 2022 at 02:41:08PM +, Eivind Naess wrote: > Hi Andrey, > > I don't mind becoming a debian maintainer at all. In fact, I've maintained > these packages for Ubuntu over almost a decade. It would indeed be simpler > for me to maintain these for Debian and it to be adopted by downstream > distributions like Ubuntu. I was working with somebody, but he's been quite > busy. Hoping someone else could chime in and help here. > > I think the next step would be to review, then upload? Ideally, I'd be > maintaining this with my own credentials on Salsa, right? Please follow https://mentors.debian.net/intro-maintainers and https://mentors.debian.net/sponsors/ -- WBR, wRAR signature.asc Description: PGP signature
Re: Fixes that would close ITP bugs 671296 and 1006705
On Tue, Mar 29, 2022 at 11:01:07PM +0500, Andrey Rahmatullin wrote: > On Tue, Mar 29, 2022 at 05:34:57PM +, Eivind Naess wrote: > > I have a packages made ready which would close both 1006705 and 671296 > > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671296 > > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006705 > > > > The GIT repository is here: > > - git clone https://git.launchpad.net/~eivnaes/+git/sstp-client-package > > - git clone > > https://code.launchpad.net/~eivnaes/+git/network-manager-sstp-package > > > > For the respective bugs. Would anyone be able to help me with a review > > and an upload of these packages? I've previously hosted a repository for > > Ubuntu out of launchpad, but I've gotten a handful of request from > > people wanting this to be a package for Debian 11. > Are you going to be the maintainer for these packages in Debian or just > want someone to upload them once? OK, I've read the first bug report and it seems that you indeed don't intend to maintain these packages in Debian. In that case the answer is still "you need to wait for someone to volunteer" and you should retitle both ITPs into RFPs. -- WBR, wRAR signature.asc Description: PGP signature
Re: Fixes that would close ITP bugs 671296 and 1006705
On Tue, Mar 29, 2022 at 05:34:57PM +, Eivind Naess wrote: > I have a packages made ready which would close both 1006705 and 671296 > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671296 > - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006705 > > The GIT repository is here: > - git clone https://git.launchpad.net/~eivnaes/+git/sstp-client-package > - git clone > https://code.launchpad.net/~eivnaes/+git/network-manager-sstp-package > > For the respective bugs. Would anyone be able to help me with a review > and an upload of these packages? I've previously hosted a repository for > Ubuntu out of launchpad, but I've gotten a handful of request from > people wanting this to be a package for Debian 11. Are you going to be the maintainer for these packages in Debian or just want someone to upload them once? Note that Debian 11 was already released and so adding new packages to it is not possible. They can be uploaded to backports though, once they are in testing. -- WBR, wRAR signature.asc Description: PGP signature
Re: Help to package the jimtcl
On Tue, Mar 22, 2022 at 06:31:27PM +0800, Bo YU wrote:
> > > > > vimer@debian:~/git/jimtcl$ sudo dpkg-gensymbols -pjimtcl0.79 >
> > > > > symbols.diff
> > > > > dpkg-gensymbols: warning: new libraries appeared in the symbols file:
> > > > > libjim.so.0.81
> > > > > dpkg-gensymbols: warning: some libraries disappeared in the symbols
> > > > > file: libjim.so.0.79
> > > > If the SONAME was changed, the old symbols file should be dropped and a
> > > > new one generated from scratch.
> > > > Also you don't need sudo here.
> > > I am sure the libjimtcl SONAME from 0.79 change to 0.81. And the old
> > > symbols
> > > file should be removed also.
> > >
> > > But how to generate one new file from scratch?
> > dpkg-gensymbols
> >
> > > [0]:
> > > https://salsa.debian.org/vimerbf-guest/jimtcl/-/commit/f9e050fd1bc71192c3e37d04a8e830dc826fdc71#21078f6fededf24bfff78a1c7b9faa8297d896b7
> > It doesn't make sense to specify versions older than the first version
> > with this soname.
> My work is reproduced as below:
>
> sudo dpkg-deb -x libjim0.81_0.81+dfsg0-1_amd64.deb /tmp/jimctl
You don't need sudo here either.
> sudo dpkg-gensymbols -v0.81 -plibjim -P/tmp/jimctl/ -Olibjim.symbols # sudo
> :-(
>
> Then, drop the version string from libjim.symbols and old libjim0.79.symbols:
>
> cat libjim.symbols | awk '{print $1}' > libjim0.81.txt
> cat libjim0.79.symbols | awk '{print $1}' > libjim0.79.txt
>
> diff libjim0.81.txt libjim0.79.txt
>
> And the last result is +13 and -5 symbols entiries applied for
> libjim0.81.symbols,
> that is moved from libjim0.79.symbols by manual.
>
> Is that OK?
I think so?
Note that you don't really need to compare the symbols with the older
ones.
--
WBR, wRAR
signature.asc
Description: PGP signature
Re: Help to package the jimtcl
On Tue, Mar 22, 2022 at 04:32:32PM +0800, Bo YU wrote: > > > vimer@debian:~/git/jimtcl$ sudo dpkg-gensymbols -pjimtcl0.79 > > > > symbols.diff > > > dpkg-gensymbols: warning: new libraries appeared in the symbols file: > > > libjim.so.0.81 > > > dpkg-gensymbols: warning: some libraries disappeared in the symbols file: > > > libjim.so.0.79 > > If the SONAME was changed, the old symbols file should be dropped and a > > new one generated from scratch. > > Also you don't need sudo here. > I am sure the libjimtcl SONAME from 0.79 change to 0.81. And the old symbols > file should be removed also. > > But how to generate one new file from scratch? dpkg-gensymbols > [0]: > https://salsa.debian.org/vimerbf-guest/jimtcl/-/commit/f9e050fd1bc71192c3e37d04a8e830dc826fdc71#21078f6fededf24bfff78a1c7b9faa8297d896b7 It doesn't make sense to specify versions older than the first version with this soname. -- WBR, wRAR signature.asc Description: PGP signature
Re: Help to package the jimtcl
On Tue, Mar 22, 2022 at 02:50:48PM +0800, Bo YU wrote: > vimer@debian:~/git/jimtcl$ sudo dpkg-gensymbols -pjimtcl0.79 > symbols.diff > dpkg-gensymbols: warning: new libraries appeared in the symbols file: > libjim.so.0.81 > dpkg-gensymbols: warning: some libraries disappeared in the symbols file: > libjim.so.0.79 If the SONAME was changed, the old symbols file should be dropped and a new one generated from scratch. Also you don't need sudo here. > Special diff file is here: https://paste.debian.net/1235207/ The first line of the new file suggests the library is now in the jimtcl0.79 package. It should be in libjim0.81. > And there are any chance to use `dpkg-gensymbols` with sbuild? It's used by default and a diff is printed. -- WBR, wRAR signature.asc Description: PGP signature
Re: Looking for a new maintainer for the "rush" package
On Mon, Mar 21, 2022 at 10:02:03AM +0800, Bo YU wrote: > But there are some situations that are unclean for me: > If you file an ITS bug, that is mean the package's new(co-) packages are > you. Sure, ITS means you want to maintain the package. "I want the package to be updated but don't want to maintain it" doesn't really have a solution. Even NMUing it to a new upstream version is not a solution, and is usually frowned upon. -- WBR, wRAR signature.asc Description: PGP signature
Re: CRLF in upstream source code
On Mon, Mar 14, 2022 at 12:25:53PM -0300, Lourisvaldo Figueredo Junior wrote:
> I have a doubt. In cases where the upstream uses the MS-DOS pattern CRLF
> ("\r\n") to end of line, instead Unix pattern LF ("\n").
> In this situation, should the maintainer make a patch converting this files
> to
> the Unix pattern LF?
No.
> Or to Debian is 'acceptable' to build a package from source keeping the
> MS-DOS
> pattern CRLF?
Why should it matter to anything, including Debian, unless there are
technical problems caused by that?
--
WBR, wRAR
signature.asc
Description: PGP signature
Re: Automake issues on pngnq
On Mon, Mar 07, 2022 at 08:59:38PM +0100, Andreas Tille wrote: > For whatever reason automake puts LDFLAGS before "-o pngcomp" This is correct. > instead of after and the last options are obtained from the LIBS variable. This is correct. > I have no idea how to tweak this sequence. You don't need to tweak the sequence. You need to put libs into LIBS. -- WBR, wRAR signature.asc Description: PGP signature
Re: A question about "non official" debian packages
On Thu, Mar 03, 2022 at 04:30:35PM +0100, Albert van der Horst wrote: > Dear mentors, > I plan to publish (at least) 4 Debian packages. > > The format is ideal for my users to install, and the .deb format takes care > of installing .info files at the right place, something I find impossible to > do. > > Is it frowned upon by the Debian community to use the .deb format to publish > these packages? No, you may do anything you want. > (And what are the sanctions?) Huh? -- WBR, wRAR signature.asc Description: PGP signature
Re: Question about building a deb package
On Fri, Feb 25, 2022 at 11:44:46AM +0800, Yunmei Li wrote: > I am new to building deb packages, and I would like some help with a > question. > I am trying to build a deb package for Milvus(https://milvus.io/) on > Ubuntu18.04 or Ubuntu 20.04. Building Milvus requires Cmake 3.18 or higher, > but the latest version of cmake is 3.16 on Ubuntu 20.04 (golang has the > same situation). Could I directly use the cmake binary when building my > package? Or is there any other solution? As this mailing list is specifically about Debian contributions, this is offtopic here (both because the question is about Ubuntu and because it's about packaging for local use). For official packages the only common option would be to not build it on systems where the required dependency versions are not available. -- WBR, wRAR signature.asc Description: PGP signature
Re: Package upload failed only due GPG expiration?
On Wed, Feb 02, 2022 at 11:50:47AM +0100, Filip Hroch wrote: > I'm attempting to upload Fitspng into ftp-master, unfortunately, without any > success. Moreover, I haven't received any message why the upload has been > rejected, or anything else. When a valid signature is not found the uploader indeed doesn't get any notifications. From coccia.debian.org:/srv/ftp-master.debian.org/log/current: 20220202110344|process-upload|dak|fitspng_2.0-1_amd64.changes|Error while loading changes file fitspng_2.0-1_amd64.changes: No valid signature found. (GPG exited with status code 0) gpg: Signature made Mon Jan 31 21:59:10 2022 UTC gpg:using RSA key 50329FD7732E2AB08161435F1E625DF64972FF9A gpg:issuer "hr...@physics.muni.cz" gpg: Good signature from "Filip Hroch " [expired] gpg: WARNING: Using untrusted key! > By following of suggestions related on the post, and knowing that > my GPG key has expired 2022-01-25, I uploaded renewed key > on hkp://keyring.debian.org during Sunday. However, keycheck > https://nm.debian.org/process/867/keycheck/ still indicates > the expiration, and rsync confirms that the last keyring > update was, accidentally, 25. January. > > Now, I'm in doubts if the problem is related on the expiration, > or if there is something different which should be investigated > as well as. Yes, it's because of key expiration. Unfortunately I have no idea anymore which is the source of key data for the upload processing as that's inconsitent and I don't know if it's documented anywhere. -- WBR, wRAR signature.asc Description: PGP signature
Re: Deleting accepted upload?
On Mon, Jan 24, 2022 at 09:14:08AM +0100, Hilmar Preuße wrote: > yesterday I uploaded dvisvgm_2.13-1 to the archive. For any unknown reason I > deleted the changelog entry for version 2.12-4 from the d/changelog file, > this version is currently in testing. I tried to cancel the upload using > dcut, but this does not work. How to proceed? > > - Can we remove that version 2.13-1 from unstable? We shouldn't. And we can't remove it from user machines. > - Should I simply upload 2.13-2 and re-add that entry? Yes. -- WBR, wRAR signature.asc Description: PGP signature
Re: lib package name of dependency changed after ftpmaster acceptance (was Re: How to resolve unsatisfied dependency (verisoned) after ftpmaster acception)
On Fri, Jan 21, 2022 at 10:31:38AM +0100, Markus Blatt wrote: > > When I look at the package tracker https://tracker.debian.org/pkg/opm-common > > I see "unsatisfied dependency on libfmt7 (>= 7.1.3+ds1)" that is blocking > > migration to testing. Current version of libfmt in unstable is 8.1.1+ds1-2. > > And the current library package of libfmt source package is called libfmt8 > and not libfmt7. > > To resolve this I guess the package needs to be rebuilt. Does that require > reuploading > or is there another way? You need to rebuild it anyway for it to migrate (and the excuses say that). And a reupload is the only way as it includes arch:all subpackages, otherwise it would be possible to binNMU it. -- WBR, wRAR signature.asc Description: PGP signature
Re: Why bother with ITP bugs?
On Mon, Jan 17, 2022 at 10:23:51PM -0800, Ross Vandegrift wrote: > I guess ITP bugs are common practice for new packages... but are they > *required* by anything? No. But your sponsor is likely to request you to file one before sponsoring. > It seems like fairly high-friction, low-value work - especially if > you're talking about more than a single package. So I'd like to avoid > it, but I'm not sure what the costs would be. Main benefits of an ITP: - It is supposed to act like a mutex, signalling that someone is already packaging this. But this often doesn't work as intended because people learn about ITPs only when they first run lintian, not before starting the work, so there are multiple cases of several people working on the same package separately. - After it's announced on d-devel@, people can look at it and send their thoughts (up to, as happens from time to time, telling the packager that the software is already in Debian). - The packager may decide to send the progress/status reports to the bug, which can help other people. -- WBR, wRAR signature.asc Description: PGP signature
Re: salsa git workflows - import or mirror or?
On Wed, Jan 05, 2022 at 11:43:21AM +, Gavin Henry wrote: > > > Brilliant, thank you Juri! Did you add this to the UpstreamGuide wiki at > > > all? > > Why would it be useful on that page? > > For me it was like the difference between reading a computer science > book and source code. Juri's examples clearly showed the practical > steps of the workflow. I was asking why would it be useful on the UpstreamGuide page which is explicitly for upstreams, not packagers. -- WBR, wRAR signature.asc Description: PGP signature
Re: salsa git workflows - import or mirror or?
On Tue, Jan 04, 2022 at 07:21:47PM +, Gavin Henry wrote: > Hi all, > > I've created https://salsa.debian.org/ghenry/sentrypeer as an import > from my main GitHub repo. > > If I wanted to follow the pattern of: > > https://salsa.debian.org/pkg-voip-team/libosip2 > https://salsa.debian.org/vagrant/librecast (my friends project) These use two different workflows. libosip2 uses gbp and gbp-import-orig, importing upstream tarballs. librecast adds the upstream repo as a remote and merges upstream tags directly. It's not clear if it implies using gbp as there is no gbp.conf that would set the correct upstream tag pattern. > How best do I start? Thre are many different workflows and you need to choose one. If you decide to use gbp you can read https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.upstream-git.html for some of the possible ones. I think gbp-import-orig+pristine-tar is the most popular among those. > I note the debian folder is in the repo too, > where as I have mine as a branch: > > https://github.com/SentryPeer/SentryPeer/tree/debian-packaging In both cases the debian folder is in a packaging branch (master and debian/latest respectively). -- WBR, wRAR signature.asc Description: PGP signature
Re: salsa git workflows - import or mirror or?
On Tue, Jan 04, 2022 at 09:31:18PM +, Gavin Henry wrote: > > Sorry, it's just small overview, how I do it. > > Brilliant, thank you Juri! Did you add this to the UpstreamGuide wiki at all? Why would it be useful on that page? -- WBR, wRAR signature.asc Description: PGP signature
Bug#1001759: RFS: qt6/6.2.2+ds-1 -- Qt for Android (x86_64)
Having a source package named "qt6" build Android-specific packages sounds wrong to me. Is this intended to contain the normal Qt source code and so be a duplicate of normal Qt packages? This question would be asked in the ITP bug for this package but it doesn't seem to have one... -- WBR, wRAR signature.asc Description: PGP signature
Re: zekr project and new version of Debian
On Mon, Dec 13, 2021 at 05:47:19PM +0330, Mohsen Pahlevanzadeh wrote: > > > https://packages.debian.org/stretch/zekr Project is a powerful and useful > > > project in Quran. But its maintainer was released it. I contact with him, > > > and decide to build deb for debian repo and rpm for fedora and zst for > > > archlinux. > > Do you mean you are trying to build the same old source that was removed > > from Debian because it depended on obsolete libs? In that case it may be > > impossible to do that on modern Debian. Also, if you want to reintroduce > > the package in Debian it will be impossible as well, and if you are trying > > to build it just for yourself or for a non-Debian repo then you shouldn't > > ask on this mailing list, which is only for questions about contributions > > to Debian. > > Oh, no, I compiled from original source from sourceforge: > https://sourceforge.net/projects/zekr/ "Last Update: 2014-01-13" My email still applies. -- WBR, wRAR signature.asc Description: PGP signature
Re: zekr project and new version of Debian
On Mon, Dec 13, 2021 at 08:56:30AM +0330, Mohsen Pahlevanzadeh wrote: > https://packages.debian.org/stretch/zekr Project is a powerful and useful > project in Quran. But its maintainer was released it. I contact with him, > and decide to build deb for debian repo and rpm for fedora and zst for > archlinux. Do you mean you are trying to build the same old source that was removed from Debian because it depended on obsolete libs? In that case it may be impossible to do that on modern Debian. Also, if you want to reintroduce the package in Debian it will be impossible as well, and if you are trying to build it just for yourself or for a non-Debian repo then you shouldn't ask on this mailing list, which is only for questions about contributions to Debian. > I googled and find the following answer: > > 'YOU HAVE TO INSTALL libwebkitgtk-1.0-0' > > > But libwebkitgtk-1.0-0 isn't on the repository. > > By the way, I install dependencies of zekr even via new name. But didn't > find any package for libwebkitgtk-1.0-0. The last Debian release with that package was stretch. -- WBR, wRAR signature.asc Description: PGP signature
Re: How to troubleshoot conffile files problems
On Tue, Dec 07, 2021 at 01:56:26PM -0500, Tong Sun wrote: > > > But I was told to "using rm_conffile directive from .maintscript file" > > This is wrong. rm_conffile is only for cases when a conffile is no longer > > shipped. This is explained in dpkg-maintscript-helper(1). But > > /etc/dnsmasq.d/dbab.*, or /etc/dnsmasq.d/dbab, or > > /etc/dnsmasq.d/dbab-map.*, are not even conffiles, as far as I can see (as > > they are not shipped in the package, as far as I can see). > > So you are saying that the correct way to do it is this -- > https://salsa.debian.org/debian/dbab/-/blob/master/debian/dbab.postrm > right? Right. > > > > So I did, see -- > > > https://salsa.debian.org/debian/dbab/-/commit/eca5bf35dc20843907b3eb0078a7926117bdf0e8 > > Yup, this is wrong. And /etc/dbab is a dir, so that line is doubly wrong. > > what's the correct way for the fix then? > > remove the dbab.maintscript file, i.e., > https://salsa.debian.org/debian/dbab/-/blob/master/debian/dbab.maintscript, > right? Right. -- WBR, wRAR signature.asc Description: PGP signature
Re: maintainer-script-should-not-use-dpkg-maintscript-helper
On Tue, Dec 07, 2021 at 01:03:10PM -0500, pkgoyq@neverbox.com wrote: > On Tue, Dec 7, 2021 at 12:53 PM Andrey Rahmatullin wrote: > > > > On Tue, Dec 07, 2021 at 12:40:06PM -0500, wrote: > > > > > Why `maintainer-script-should-not-use-dpkg-maintscript-helper` is a > > > > > warning? > > > > Have you read its description? > > > > > > Please don't overestimate my ability to decrypt the description. > > > If I understand what it is saying, I won't be asking such a question. > > Do you know that lintian tags have descriptions and not just names? > > I've read > > https://lintian.debian.org/tags/maintainer-script-should-not-use-dpkg-maintscript-helper?version=2.112.18 > > and still unable to decrypt the description. Which parts of "The maintainer script seems to make manual calls to the dpkg-maintscript-helper(1) utility. Please use package.maintscript files instead" are you unable to decipher? -- WBR, wRAR signature.asc Description: PGP signature
Re: How to troubleshoot conffile files problems
On Tue, Dec 07, 2021 at 12:57:37PM -0500, pkgoyq@neverbox.com wrote: > > > > > How to do that please? > > > > The correct way, it seems, would be to follow the suggestion in the > > > > original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in > > > > the 1.3.3-1 postrm. > > > > > > I still don't quite understand what you actually mean, > > I just mean the original bug report already had a suggestion that seems > > correct to me. > > Can you give me a simple example package showing how it should be done please? > > It is not that I didn't try my best but the case is I've already tried > my best to guess what the above means but it seems I guessed wrong > each time. Thus I need detailed help, those few words only get me > going around the circles. Sorry, I'm not going to make an upload a package for this. Here are the instructions I meant and I don't know what can be clearer than that short of an actual debdiff: """ I see the postrm has /etc/dnsmasq.d/dbab.* which I take it would have to be dbab-map.* """ > OK, let's start from the beginning: > > > > How to properly handle conffile files in such a case? > > > You should remove them manually in postrm, but only on > > purge. > > That's actually what I've been doing, removing them manually in postrm > and on purge -- > > https://salsa.debian.org/debian/dbab/-/commit/0acfe617f064c5907f999707e37be12c7b9f8328 But #958900 was about files that were not affected by that. > But I was told to "using rm_conffile directive from .maintscript file" This is wrong. rm_conffile is only for cases when a conffile is no longer shipped. This is explained in dpkg-maintscript-helper(1). But /etc/dnsmasq.d/dbab.*, or /etc/dnsmasq.d/dbab, or /etc/dnsmasq.d/dbab-map.*, are not even conffiles, as far as I can see (as they are not shipped in the package, as far as I can see). > So I did, see -- > https://salsa.debian.org/debian/dbab/-/commit/eca5bf35dc20843907b3eb0078a7926117bdf0e8 Yup, this is wrong. And /etc/dbab is a dir, so that line is doubly wrong. > and that's what I did, instead removing them manually in postrm with > `rm`, I used > `dpkg-maintscript-helper rm_conffile` instead. > > And now I'm at > > W: maintainer-script-should-not-use-dpkg-maintscript-helper > > I.e., I've gone through a full circle. That's not even a circle, these are multiple separate problems, some of them unrelated. -- WBR, wRAR signature.asc Description: PGP signature
Re: maintainer-script-should-not-use-dpkg-maintscript-helper
On Tue, Dec 07, 2021 at 12:40:06PM -0500, pkgoyq@neverbox.com wrote: > > > Why `maintainer-script-should-not-use-dpkg-maintscript-helper` is a > > > warning? > > Have you read its description? > > Please don't overestimate my ability to decrypt the description. > If I understand what it is saying, I won't be asking such a question. Do you know that lintian tags have descriptions and not just names? -- WBR, wRAR signature.asc Description: PGP signature
Re: maintainer-script-should-not-use-dpkg-maintscript-helper
On Tue, Dec 07, 2021 at 11:49:32AM -0500, Tong Sun wrote: > Why `maintainer-script-should-not-use-dpkg-maintscript-helper` is a warning? Have you read its description? -- WBR, wRAR signature.asc Description: PGP signature
Re: How to troubleshoot conffile files problems
On Sun, Dec 05, 2021 at 10:19:44AM -0500, pkgoyq@neverbox.com wrote: > > > > You should remove them manually in postrm, but only on > > > > purge. > > > > > But now you will need to also recover from a bad state > > left by upgrades to 1.5.7-1. > > Ah... it is getting more and more complicated. Nobody would be able to > upgrade to 1.5.7-1 normally, so it is OK to use next good version as > the fix please? Are you asking whether you can assume that no system had 1.5.01-1 and then 1.5.7-1 installed, because in that cause it would be impossible to have 1.5.7-1 configured? That's probably a valid assumption, though I don't think what can you assume about systems that tried to update to 1.5.7-1 and then were rolled back in some unknown way. > Else, all the upgrade related problems can be easily fixed by purging > the old version, and installing a brand new version. I don't think you can assume this is what was done though. Downgrading to the version from testing and pinning it is also a valid way to make the apt state consistent again. > > > How to do that please? > > The correct way, it seems, would be to follow the suggestion in the > > original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in > > the 1.3.3-1 postrm. > > I still don't quite understand what you actually mean, I just mean the original bug report already had a suggestion that seems correct to me. -- WBR, wRAR signature.asc Description: PGP signature
Re: How to troubleshoot conffile files problems
On Sat, Dec 04, 2021 at 11:29:58PM -0500, Tong Sun wrote: > > You should remove them manually in postrm, but only on > > purge. > > How to do that please? The correct way, it seems, would be to follow the suggestion in the original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in the 1.3.3-1 postrm. But now you will need to also recover from a bad state left by upgrades to 1.5.7-1. > > Unrelated, but is the package doesn't function without files downloaded > > from Internet, and even downloads them in postinst, then it should go to > > contrib. Should I file a bug about this? > > Please don't yet, as I totally don't understand what you want me to > do, now. Unless you can send me a patch, please let me get this thing > over first. I've already filed #1001009. It says what needs to be done. The relevant Policy section is 2.2.2. -- WBR, wRAR signature.asc Description: PGP signature
Re: How to troubleshoot conffile files problems
On Sat, Dec 04, 2021 at 11:09:35PM -0500, Tong Sun wrote: > OK, I want to remove all conffile files and reinstall the new ones > when doing package upgrade, as there isn't much user intervention to > those conffile files. All are provided by the package. Then they shouldn't be conffiles and shouldn't be in /etc. And if you want to drop user modifications you are just breaking the Policy requirements. > So I do `rm_conffile` to the old conffile files when doing package > upgrade, rm_conffile is about preserving user modifications. And, again, calling it with a dir is wrong. > How to properly handle conffile files in such a case? If they shouldn't be modified by the user, they should be in /usr. -- WBR, wRAR signature.asc Description: PGP signature
Re: How to troubleshoot conffile files problems
On Thu, Dec 02, 2021 at 10:46:43AM -0500, Tong Sun wrote: > Hi, > > I'm having problem with my conffile files, see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769 > > I.e., > > > grep: /etc/dbab/dbab.list-: No such file or directory > cat: /etc/dbab/dbab.addr: No such file or directory > > > They should be there but I have no idea why they are not. I guess it was removed by your "dpkg-maintscript-helper rm_conffile /etc/dbab" call, which I already pointed at in the reply to your previous email about this bug? I have no idea how does it work when passed a directory but I wouldn't be surprised if it removes or moves it too. -- WBR, wRAR signature.asc Description: PGP signature
Bug#1000554: RFS: libfm-qt/0.16.0-3.1 [NMU] [RC] -- Language package for libfm-qt
On Sun, Nov 28, 2021 at 03:23:34PM -0500, S. 7 wrote: > I have decided to package the newest version of LXQt (including libfm-qt), > as such, this bug report no longer has relevance. In that case you should close it. -- WBR, wRAR signature.asc Description: PGP signature
Re: My package is marked for autoremoval from testing
On Thu, Nov 25, 2021 at 03:45:37PM -0500, Tong Sun wrote: > My package cannot be upgraded from current version to latest version > -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769 > > It might have something to do with obsoleted conffile files or it > might even not. The problem is, I've been trying to understand how the > conffile files work, and I think I'm doing the right thing, yet my > package cannot be properly upgraded. > > - I don't understand what breaks and why, from the output of the > package upgrade log (see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769). Well those errors are clearly caused by dbab.maintscript saying "rm_conffile /etc/dbab", while /etc/dbab is indeed a directory and not a file. So it would be helpful if you told us what were you trying to do by this. If this is about #958900 then rm_conffile is *not* about removing files on purge. You should remove them manually in postrm, but only on purge. Unrelated, but is the package doesn't function without files downloaded from Internet, and even downloads them in postinst, then it should go to contrib. Should I file a bug about this? -- WBR, wRAR signature.asc Description: PGP signature
Re: Suggestion needed on test failures due to double arithmetics
On Thu, Nov 25, 2021 at 01:45:49PM +0100, Giulio Paci wrote: > Moreover I am still wondering if the compiler behavior is correct in this > case and why it is so unstable. It's correct when you don't care about the amount of precision, and it's unstable for the reasons described in gcc(1) for the options you mentioned, e.g. "This option prevents undesirable excess precision on machines such as the 68000 where the floating registers (of the 68881) keep more precision than a "double" is supposed to have. Similarly for the x86 architecture. For most programs, the excess precision does only good, but a few programs rely on the precise definition of IEEE floating point.", as in different circumstances the temporary values will have or not have the x87 80-bit precision, leading to different calculation results. -- WBR, wRAR signature.asc Description: PGP signature
Re: Suggestion needed on test failures due to double arithmetics
On Thu, Nov 25, 2021 at 01:13:20PM +0100, Giulio Paci wrote: > The double values refer to timing information. The specific format, > known as CTM, stores information in seconds in decimals (e.g. "30.66" > seconds) from the beginning of the stream. > The failing tool reads this information into double variables Sounds like it just shouldn't read this data into a float type but use some fixed-point data type instead. -- WBR, wRAR signature.asc Description: PGP signature
Re: Suggestion needed on test failures due to double arithmetics
On Wed, Nov 24, 2021 at 06:38:07PM +0100, Giulio Paci wrote: > Dear mentors, > while updating SCTK package I enabled the execution of the test suite > which was previously disabled. The tests are working fine on x86_64 > architecture, but a couple of them are failing on i386. > After investigation [1] I found out that tests are failing because they > rely on the assumptions that, when a and b have the same double value: > 1) "a < b" is false; > 2) "a - b" is 0.0. What do they actually test, why do they use these assumptions? -- WBR, wRAR signature.asc Description: PGP signature
Re: Semv
On Tue, Nov 02, 2021 at 01:21:24PM +, Lars Gohr wrote: > Hi, > > I would like to publish semv (https://github.com/elgohr/semv). > > Semv is a CLI tool, written in Go, that makes it easy to work with semantic > versions. > In this way semantic versions can be compared and incremented (which is > sometimes interesting in CI/CD environments). How is it better than e.g. /usr/bin/pysemver from python3-semver? > It would be great if somebody could help me to publish it. Are you going to maintain the package in Debian yourself? If no, you need to find some one who will (which is usually hard for a project with no users). -- WBR, wRAR signature.asc Description: PGP signature
Re: Override dh_builddeb destdir causes dpkg-genbuildinfo to fail
On Mon, Nov 01, 2021 at 09:24:29PM +, Kerry wrote: > I get a binary .deb in the parent directory of my application directory. > I would like to change this so that all .debs are placed in a different > directory so I tried overriding 'dh_builddeb' in 'rules': d/rules is a wrong place for this, for several reasons. Don't do this. > Renaming skriblr-dbgsym_0.1-1_amd64.deb to skriblr-dbgsym_0.1-1_amd64.ddeb And this isn't even Debian. -- WBR, wRAR signature.asc Description: PGP signature
Re: How to include the .git folder in a source package's .tar.xz archive?
On Thu, Oct 28, 2021 at 09:02:21PM -0500, Hunter Wittenborn wrote: > Part of the packaging process for our program includes running Git > commands to get things like the timestamp for when some files were last > modified, which are used in things like the building of man pages via > Asciidoc to set the last modified time [1]. This is a bad idea for several reasons. It also seems to mean your software doesn't have a published source tarball. > The problem is that whenever I (and the other guy) build the program > with something like debuild, the resulting .tar.xz archive doesn't > contain the .git repository in which the 'debian/' folder is contained. Putting .git into the orig tarball is very wrong and you shouldn't do that. You should find a way how to make a source distribution for your software that allow building from a tarball without .git. Please also consider the reproducible builds initiative and https://reproducible-builds.org/docs/source-date-epoch/ -- WBR, wRAR signature.asc Description: PGP signature
Re: Advice needed for a strange request about getmail vs. getmail6
On Mon, Oct 18, 2021 at 08:27:51PM +0100, Sudip Mukherjee wrote: > Hi All, > > To give a brief history, Debian had "getmail" which was based on > Python2 and was removed. Then there was a fork available named > "getmail6" which was based on Python3. A transitional package linked > them by #979060. > > Now, the upstream of "getmail" has raised a bug in Debian asking > "getmail6" to be removed or renamed and he claims that users of > getmail6 are imposing a support burden on him as users are thinking it > to be getmail and mailing the getmail mailing list. #996569 > > I went through the getmail mailing list archive and could find only > one such mail. I am not sure what to reply to him, and need your > suggestions about what to do now please. Debian is a wrong place to do this. And if not for the trademark violation claims I'd suggest ignoring this. But the claims should be directed to the upstream first. -- WBR, wRAR signature.asc Description: PGP signature
Re: WNPP Update Package source source of gjiten
On Tue, Oct 05, 2021 at 06:35:34PM +0900, notebook wrote: > > > > [Me] > > > It looks like becoming a maintainer requires 40+ hours to go through all > > > the "must read" articles and becoming accustomed to every procedure and > > > guideline. > > > [Andrey] > > Actually, even providing a source package for a one-time upload requires > > that. Becoming a maintainer requires more, and is not a one-time action. > > And so my hopes of ever getting the new source in place drop away. > > That sounds like a very lot of time for deploying. Is there a reason for > having a system that time-consuming? Many of them. > It feels like the deploy takes away valuable that could be spend > developing... Maintainers are usually not developers of the same project so this is irrelevant. > Or are you talking about the time for "first-timers"? Mostly. -- WBR, wRAR signature.asc Description: PGP signature
Re: WNPP Update Package source source of gjiten
On Tue, Oct 05, 2021 at 06:20:11PM +0900, notebook wrote: > > [Andrey Rahmatullin:] > > If, on the other hand, you just want > > that the package in Debian uses your updated code, you don't need to (and > > can't) do anything in addition to what you already did. > > Just for future reference: > > "what you did" means > (1) Writing here in debian-mentors and hoping for someone to do the job? > or > (2) Filing the bug (#982343) on bugs.debian? (2) > > [Tobias Frost:] > > Otherwise, we have the ITS procedure if you want to take over package > > maintainership: > > https://wiki.debian.org/PackageSalvaging (from a very quick look at the > > package, it seems to be eligible for ITS) > > > > It's not really clear to me what the result of package salvaging is. I > guess it would make me a maintainer? Yes. > Background: > It looks like becoming a maintainer requires 40+ hours to go through all > the "must read" articles and becoming accustomed to every procedure and > guideline. Actually, even providing a source package for a one-time upload requires that. Becoming a maintainer requires more, and is not a one-time action. -- WBR, wRAR signature.asc Description: PGP signature
Re: WNPP Update Package source source of gjiten
On Tue, Oct 05, 2021 at 04:25:44PM +0900, notebook wrote: > Hello Andrey: > > Thank you for your reply! > > > As the package is already in Debian, you need to contact its current > > maintainer(s) (though I see you already filed #982343). > > I contacted the current maintainers. They are too busy to do any work in this > regard. > So I guess whatever is in place must be replaced. If you want to become a co-maintainer of the package in Debian you should get an agreement for this from the current maintainers, then prepare a new source package and seek sponsorship. If, on the other hand, you just want that the package in Debian uses your updated code, you don't need to (and can't) do anything in addition to what you already did. -- WBR, wRAR signature.asc Description: PGP signature
Re: WNPP Update Package source source of gjiten
On Tue, Oct 05, 2021 at 03:58:16PM +0900, notebook wrote: > Hello, > > > I'm working on the "Gjiten" package* ([1]). It was kind of abandoned and used > Gtk2. > I upgraded it to Gtk3 and did some further development on it (see [2]). > > I'd like to get the new codebase into the debian repos. If I understand > correctly, I need a sponsor for that(?) Is there anyone willing to sponsor > the package? As the package is already in Debian, you need to contact its current maintainer(s) (though I see you already filed #982343). -- WBR, wRAR signature.asc Description: PGP signature
Re: How to load a kernel module when packaging?
On Wed, Sep 15, 2021 at 05:26:42PM +0800, clay stan wrote: > I'm packaging a package. This package requires the kernel to load the > zram module to use it. > How can I implement it? One option is documenting it in a README.Debian. > The way I can think of is to use "modporbe -r zram" in postinst to > load the module during installation, I don't think this is a good idea. Also modprobe only works until a reboot. Also -r is "unload". > or add a module-load.d conf file > >[1] https://manpages.debian.org/unstable/systemd/modules-load.d.5.en.html This can work, and I see a lot of packages in Debian already doing this, but is loading the zram module enough for you or do you also need some configuration for it? -- WBR, wRAR signature.asc Description: PGP signature
Re: Help With debian/rules File Without Build Tool
On Mon, Aug 30, 2021 at 10:20:48AM +, Ryan McClue wrote: > Upon running dpkg-buildpackage, I get: dh: error: Unknown sequence > application (choose from: binary binary-arch binary-indep build > build-arch build-indep clean install install-arch install-indep) How are you running it? -- WBR, wRAR signature.asc Description: PGP signature
Re: Understanding Rules File
On Sat, Aug 28, 2021 at 05:22:26AM +, Ryan McClue wrote: > At a high level I understand that the debian/rules file instructs > debhelper as to how to build your package. However, I'm confused > regarding these two points: This may be true in some way but to me it sounds like a wrong layering. debian/rules is a file that, when run in a certain ways, generates a .deb. To do this it will most likely (but not necessarily) call some helpers, most of those are a part of the debhelper suite, but most of the helpers just move files around or call other commands, and the lowest level are the upstream build system for the compilation part and dpkg-* commands from dpkg-dev for the building .deb, .changes etc. part. > 1. Why is debhelper used? Why not just explicitly state in the > debian/rules file how to build your package with either direct shell, > e.g. gcc file.c -o file, or with a buildtool, e.g. cmake --build . etc. > Why the level of indirection? So that you don't need to write specific commands for each package. > 2. How does debhelper work? Is there a way I can see what specific > commands it is executing, Yes, just read the build log. dh(1) prints which commands it executes. If you set DH_VERBOSE=1 in the rules you should also see what do debhelper helpers do in more details. > e.g. what does the default %: dh $@ actually > equate to? You can run `dh --no-act` for each you want (build, clean, binary etc.) to see what will dh(1) run for that target. -- WBR, wRAR signature.asc Description: PGP signature
Re: Question regarding adding my application to Debian
On Wed, Aug 11, 2021 at 02:41:03PM +0200, Leon Styhre wrote: > Thank you for your quick reply! > > Yes there is a software package automatically generated when creating a > release on GitLab. > For example > https://gitlab.com/leonstyhre/emulationstation-de/-/archive/v1.1.0/emulationstation-de-v1.1.0.tar.gz > It's as simple as running "cmake . && make" to build it, assuming all > dependencies (which are all part of Debian) are fulfilled. > There are also detailed build instructions available at > https://gitlab.com/leonstyhre/emulationstation-de/-/blob/master/INSTALL.md Yup, that doesn't use Debian source packages. > I'm not sure what "good enough" means in this context In the contex of Debian source packages "good enough to be ready for reviewing" means "mostly conformant to Debian packaging practices. But you don't have a Debian source package. > The reason I mention that there is already a .deb package available is that > the software is working fine on Debian-based systems, is following the > Debian directory structure, contains a proper man page etc. Sure, but until you have a Debian source package that builds those debs you have nothing to be reviewed and uploaded, so you should start with making one. > I will then proceed to file a WNPP bug report of the type RFP. > It is good quality software and there is currently nothing equivalent on > Debian so I hope someone will be able to support with maintaining the > package! > > If I understood the documentation correctly, since I'm asking for help for > someone to maintain the Debian package, I should not proceed with the other > steps such as publishing the package, look for a sponsor etc? > Thanks! It wasn't clear from your initial message that you don't intend to maintain it yourself. In this case you indeed can only file an RFP (though that doesn't mean anybody will act on it and an RFP is not needed for someone to package something). -- WBR, wRAR signature.asc Description: PGP signature
Re: Question regarding adding my application to Debian
On Wed, Aug 11, 2021 at 11:25:05AM +0200, Leon Styhre wrote: > I'm a little bit lost though regarding the process, should I go ahead and > create a Request For Sponsor report right away, or should I first get in > contact with someone in the Debian Games team for example? First you should create a source package that is good enough to be ready for reviewing. Finding a sponsor is only the next step. Please follow https://mentors.debian.net/intro-maintainers and then https://mentors.debian.net/sponsors/ > FYI, I already distribute the application as a .deb package via the project > website Unless you already have a source package (which you didn't mention) this is not that useful. -- WBR, wRAR signature.asc Description: PGP signature
Re: Getting accepted changes into Salsa
On Sat, Aug 07, 2021 at 05:22:46PM -0500, Brian Thompson wrote: > TL;DR How do I get an accepted change into Salsa? > > About a month ago I got my first package change accepted on > mentors.debian.net. The sponsor pushed it to the Debian FTP server, and > I can see that the package is available on > https://tracker.debian.org/pkg/apt-listchanges. However, the change > hasn't been pushed to Salsa. How can I go about getting this done? There is no such process, you need to push the commits yourself. -- WBR, wRAR signature.asc Description: PGP signature
Re: Missing Hardening Flags (freefem++)
On Sun, Jul 04, 2021 at 10:42:06PM +0500, Andrey Rahmatullin wrote: > Unrelated to this, the package uses -mmmx -avx, is this an RC bug or is > all code compiled with those flags only enabled at the run time on CPUs > supporting them? I see this is already filed as #924009. I'll fix the severity. -- WBR, wRAR signature.asc Description: PGP signature
Re: Missing Hardening Flags (freefem++)
On Sun, Jul 04, 2021 at 01:28:05PM +0200, François Mazen wrote: > > Can you publish the build log or at least make the repo buildable? > > Unless I'm mistaken, the repo is buildable. See salsa CI [1] and > associated build-log [2]. Not sure how does that work, as gbp requires the upstream/4.9+dfsg.1 tag which is not pushed. Anyway, some (I guess all) of those libs are compiled with ff-c++ which just doesn't pass LDFLAGS from the environment. The sid version was at least compiled with -Wl,-z,relro -Wl,--as-needed, because as, I presume, a workaround for that ff-c++ problem these flags were passed in $CC (which of course is not *that* sane) in debian/patches/gmm_cxxflags.patch, which is deleted in this version. Though even for the sid version blhc still reports lots of missing flags. Unrelated to this, the package uses -mmmx -avx, is this an RC bug or is all code compiled with those flags only enabled at the run time on CPUs supporting them? -- WBR, wRAR signature.asc Description: PGP signature
Re: Missing Hardening Flags (freefem++)
On Sat, Jul 03, 2021 at 09:59:30PM +0200, François Mazen wrote: > Dear Mentors, > > I'm updating the freefem++ package to 4.9 release [1] and I get > hardening-no-bindnow lintian warnings on several binary outputs [2]. > > Of course the appropriate variable is set in debian/rules (export > DEB_BUILD_MAINT_OPTIONS = hardening=+all), see [3]. According to [4] it > means that some flags like CPPFLAGS/CXXFLAGS/LDFLAGS are overridden > somewhere in the configuration. > > I can't find where these flags are overridden. Could you please help? Can you publish the build log or at least make the repo buildable? -- WBR, wRAR signature.asc Description: PGP signature
Re: ITP: fii -- find identical images
On Wed, Jun 23, 2021 at 12:11:04PM +0100, Abhishek Dutta wrote: > * Package name: fii > Version : 1.0.0 > Upstream Author : Abhishek Dutta > * URL : https://www.robots.ox.ac.uk/~vgg/software/fii/ > * License : BSD-2-clause > Description : FII is a command line tool to find all identical images > (i.e. exact duplicate images that have same image dimension and same pixel > values) > > I am resending this message as I realized that my previous email was not in > the expected format for "Intent To Package" (ITP) requests. Note that the previous email said "I am writing to request if one of the Debian package maintainers are willing to create a Debian package for this software tool.", which sounds like an RFP, not an ITP. In any case, WNPP requests should be filed with reportbug, not by mailing d-mentors@, see https://www.debian.org/devel/wnpp/ -- WBR, wRAR signature.asc Description: PGP signature
Re: Adopting a package
On Tue, Jun 15, 2021 at 03:30:41AM -0500, Brian Thompson wrote: > What is the typical way one would go about adopting a package? If you mean an orphaned one, just upload it with you as the maintainer, in addition to the O bug management described at https://www.debian.org/devel/wnpp/#l3 > I've heard that writing a patch and proposing it might be a good >starting point. Proposing it where? Orphaned packages don't have a maintainer so maybe you confused that with something else. -- WBR, wRAR signature.asc Description: PGP signature
