Bug#982654: RFS: qtractor/0.9.20-1 - MIDI/Audio multi-track sequencer application
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "qtractor": * Package name: qtractor Version : 0.9.20-1 Upstream Author : Rui Nuno Capela * URL : https://qtractor.sourceforge.io/ * License : GPL-2+, other, FSFAP * Vcs : https://salsa.debian.org/multimedia-team/qtractor Section : sound It builds those binary packages: qtractor - MIDI/Audio multi-track sequencer application To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qtractor/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qtractor/qtractor_0.9.20-1.dsc Changes since the last upload: qtractor (0.9.20-1) unstable; urgency=medium . * New upstream version 0.9.20 + Fix FTCBFS (Closes: #982462) * d/copyright: Update year and add myself * Drop gtk Depends for now, gtk3 still not supported * Fix build without gtk2 Regards, Dennis
Re: Failed build for seqan2 on i386
Andreas Tille writes:
> But other 32bit architectures like armel and armhf are passing[2]. So I
> fail to see why exactly i386 is failing. Is this possibly an effect of
> bug #917851?
Probably not; dropping the bug to a Bcc. Experimentation in an i386
chroot reveals the problem to be specifically with yara_mapper, which
https://salsa.debian.org/med-team/seqan2/-/blob/master/debian/patches/skip-some-apps-on-some-archs
explicitly excludes (along with yara_indexer) on several other 32-bit
platforms. We could go the same route for i386, but AFAICT it suffices
to drop the optimization level back down to -O2 for this specific
application, by adding
# Drop back from global -O3 on i386 to avoid
# "virtual memory exhausted: Operation not permitted"
if ("$ENV{DEB_BUILD_ARCH}" STREQUAL "i386")
target_compile_options (yara_mapper PRIVATE "-O2")
endif ()
to apps/yara/CMakeLists.txt following the add_executable call for
yara_mapper. (If and when debian/rules honors noopt, we should further
conditionalize this call accordingly, but I'm not familiar enough with
cmake to come up with the correct syntax offhand.) We could perhaps try
doing the same for other affected platforms in an upload to
experimental.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager
Hi Thomas, i've successfully built paperwork 2.0.2 in a clean sid chroot, using gbp buildpackage (and sbuild). The package is lintian clean. However, i don't quite understand the usefulness of these packages: - openpaperwork-core - openpaperwork-core-doc - openpaperwork-gtk - openpaperwork-gtk-doc I've installed openpaperwork-gtk and it seems it doesn't depend on paperwork-gtk, but maybe i'm missing some documentation, and the long package description of openpaperwork-gtk doesn't help either. Manually i had to do dpkg -i paperwork-gtk_2.0.2-1_all.deb paperwork-backend_2.0.2-1_all.deb openpaperwork-core_2.0.2-1_all.deb to get it, and that somehow looks wrong. On the other hand, once installed, it seems to be working all right. I'll try to do actual scanning with it later. Jérémy PS: i really think it would be a bonus to Bullseye to have paperwork 2. Maybe debian-release will allow it if we ensure the debian packaging is all right very quickly.
Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager
Hi, Sorry I only checked (and answered) to your comment on mentors.d.n. I just saw now you left the same message here. First, thanks for reviewing my package. The sphinxdoc debhelper extension[1] helps to install documentation build with sphinx (python3-sphinx package). Can you check you installed all build dependencies, especially python3-sphinx which depends on sphinx-common which itself provides the dh_sphinxdoc command? Well, I guess that now Bullseye soft freeze is gone, it's less urgent matter. Best regards, Thomas [1]: https://manpages.debian.org/buster/sphinx-common/dh_sphinxdoc.1.en.html
Bug#982542: RFS: flowblade/2.8-1 -- non-linear video editor
Hi, On Thu, 11 Feb 2021 12:54:11 +0100 =?UTF-8?Q?G=C3=BCrkan_Myczko?= wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "flowblade": > > * Package name : flowblade > Version : 2.8-1 > Upstream Author : https://github.com/jliljebl/flowblade/issues > * URL : https://github.com/jliljebl/flowblade > * License : GPL-3+, GPL-2+, CC-BY-3.0 > * Vcs : https://salsa.debian.org/multimedia-team/flowblade > Section : video > > It builds those binary packages: > > flowblade - non-linear video editor > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/flowblade/ > > Alternatively, one can download the package with dget using this > command: > > dget -x > https://mentors.debian.net/debian/pool/main/f/flowblade/flowblade_2.8-1.dsc > > Changes since the last upload: > > flowblade (2.8-1) experimental; urgency=medium > . > * New upstream version. > * Bump standards version to 4.5.1. > * d/control: added Rules-Requires-Root. > * d/upstream/metadata: added. > * d/copyright: update paths. Please also consider fixing https://bugs.debian.org/980219 , merging https://salsa.debian.org/multimedia-team/flowblade/-/commit/45cd180a40d8263ceb58cd7270f33fdaf351574b and https://salsa.debian.org/multimedia-team/flowblade/-/commit/72801397d1c257b62d4f39c32707b36ce011d09d . Thanks! Best, Boyuan Yang signature.asc Description: This is a digitally signed message part
Re: Sending gpg keys to keyserver
Thanks for the tips everyone - it wasn't the silver bullet I was after, but that has given me some clues to investigate. It turned out to be faster to fix my laptop and upload from there :-) I will hopefully get some time to fully investigate what is wrong with the desktop machine soon. On 10/02/2021 01:30, Paul Wise wrote: > On Tue, Feb 9, 2021 at 6:48 PM Ross Gammon wrote: > >> I have an upload stuck in the upload queue due to an expired key, and I >> would like upload my newly unexpired key to the Debian keyservers so >> that it is eventually unblocked. >> >> But I get this error: >> $ gpg -v --keyserver keyring.debian.org --send-key 'fingerprint' >> gpg: sending key 0x to hkp://keyring.debian.org >> gpg: keyserver send failed: Connection refused >> gpg: keyserver send failed: Connection refused > > That command works for me and looks like the correct one according to: > > https://keyring.debian.org/ > >> 6. Today, realise the upload has silently failed due to expired key. >> 7. Extend expiry date of keys forward two more years. > > It is a good idea to set a calendar appointment or at/systemd-run job > to give you a reminder before the date. I'm doing the expiry update 3 > months before my expiry. > > https://riseup.net/en/security/message-security/openpgp/best-practices#set-a-calendar-event-to-remind-you-about-your-expiration-date > >> Any ideas on what configuration I might need to update? > > Maybe look at your firewalls, network or proxy setup, or use wireshark > and tcptraceroute to see what is blocking the connection. Or try > creating a temporary user on your machine, logging in as that, > creating a new key with a test name/email and try sending that to the > server, the result will give some more info on where the problem is. > Also do that from another machine on the same network, or from a > Debian Live system booted on your machine. > -- Regards, Ross Gammon FBEE 0190 904F 1EA0 BA6A 300E 53FE 7BBD A689 10FC signature.asc Description: OpenPGP digital signature
Re: Failed build for seqan2 on i386
On Fri, Feb 12, 2021 at 04:30:48PM +0500, Andrey Rahmatullin wrote: > On Fri, Feb 12, 2021 at 11:21:38AM +0100, Hilmar Preuße wrote: > > > But other 32bit architectures like armel and armhf are passing[2]. So I > > > fail to see why exactly i386 is failing. Is this possibly an effect of > > > bug #917851? > > > > > Maybe the memory of the whole builder is exhausted. > > Then it would get an OOM, not a *virtual* memory error. Seems the best idea is to ask ftpmaster to remove seqan2 i386 since chances that this software is used here is extremely low anyway. Kind regards Andreas. -- http://fam-tille.de
Re: Failed build for seqan2 on i386
On Fri, Feb 12, 2021 at 11:21:38AM +0100, Hilmar Preuße wrote: > > > You can't adjust anything to get more than 4GB virtual memory on 32-bit > > > architectures. > > > You can try adjusting compilation/linking parameters to make the > > > compiler/linker use less memory though (not sure if the suggestions are > > > documented anywhere). > > > > But other 32bit architectures like armel and armhf are passing[2]. So I > > fail to see why exactly i386 is failing. Is this possibly an effect of > > bug #917851? > > > Maybe the memory of the whole builder is exhausted. Then it would get an OOM, not a *virtual* memory error. -- WBR, wRAR signature.asc Description: PGP signature
Re: Failed build for seqan2 on i386
Hi Hilmar, On Fri, Feb 12, 2021 at 11:21:38AM +0100, Hilmar Preuße wrote: > > But other 32bit architectures like armel and armhf are passing[2]. So I > > fail to see why exactly i386 is failing. Is this possibly an effect of > > bug #917851? > > > Maybe the memory of the whole builder is exhausted. In this case it may help > to limit the amount of parallel running processes. On i386 we have "make > -j4" on armel just "make -j1" . Do you suggest I should enforce this in d/rules or is it possible to ask autobuild maintainers to trigger a rebuild with this setting? Kind regards Andreas. -- http://fam-tille.de
Re: Failed build for seqan2 on i386
Am 12.02.2021 um 11:01 teilte Andreas Tille mit: On Fri, Feb 12, 2021 at 02:39:25PM +0500, Andrey Rahmatullin wrote: Hi, You can't adjust anything to get more than 4GB virtual memory on 32-bit architectures. You can try adjusting compilation/linking parameters to make the compiler/linker use less memory though (not sure if the suggestions are documented anywhere). But other 32bit architectures like armel and armhf are passing[2]. So I fail to see why exactly i386 is failing. Is this possibly an effect of bug #917851? Maybe the memory of the whole builder is exhausted. In this case it may help to limit the amount of parallel running processes. On i386 we have "make -j4" on armel just "make -j1" . H. Kind regards Andreas. [2] https://buildd.debian.org/status/package.php?p=seqan2 -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Re: Failed build for seqan2 on i386
Hi, On Fri, Feb 12, 2021 at 02:39:25PM +0500, Andrey Rahmatullin wrote: > > I wonder whether this could be simply solved by adjusting the hardware / > > emulation parameters of the according autobuilder. > > > > Am I missing something? > You can't adjust anything to get more than 4GB virtual memory on 32-bit > architectures. > You can try adjusting compilation/linking parameters to make the > compiler/linker use less memory though (not sure if the suggestions are > documented anywhere). But other 32bit architectures like armel and armhf are passing[2]. So I fail to see why exactly i386 is failing. Is this possibly an effect of bug #917851? Kind regards Andreas. [2] https://buildd.debian.org/status/package.php?p=seqan2 -- http://fam-tille.de
Re: Failed build for seqan2 on i386
On Fri, Feb 12, 2021 at 10:17:06AM +0100, Andreas Tille wrote: > in the build log[1] I found > >virtual memory exhausted: Operation not permitted > > I wonder whether this could be simply solved by adjusting the hardware / > emulation parameters of the according autobuilder. > > Am I missing something? You can't adjust anything to get more than 4GB virtual memory on 32-bit architectures. You can try adjusting compilation/linking parameters to make the compiler/linker use less memory though (not sure if the suggestions are documented anywhere). -- WBR, wRAR signature.asc Description: PGP signature
Failed build for seqan2 on i386
Hi, in the build log[1] I found virtual memory exhausted: Operation not permitted I wonder whether this could be simply solved by adjusting the hardware / emulation parameters of the according autobuilder. Am I missing something? Kind regards Andreas. [1] https://buildd.debian.org/status/fetch.php?pkg=seqan2=i386=2.4.0%2Bdfsg-13=1613071965=0 -- http://fam-tille.de
