Bug#988058: RFS: xsane/0.999-11 -- featureful graphical frontend for SANE (Scanner Access Now Easy)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "xsane": Package name: xsane Version : 0.999-11 Upstream Author : Oliver Rauch URL : License : GPL-2+, public-domain, Artistic-1.0 Vcs : https://jff.email/cgit/xsane.git Section : graphics It builds those binary packages: xsane-common - xsane architecture independent files xsane - featureful graphical frontend for SANE (Scanner Access Now Easy) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/xsane/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/x/xsane/xsane_0.999-11.dsc or from git https://jff.email/cgit/xsane.git?h=release%2Fdebian%2F0.999-11 Changes since the last upload: xsane (0.999-11) experimental; urgency=medium . * Fix FTBFS on hppa (Closes: #987841). - Thanks to John David Anglin . * Fix Docs need symlink to be found from GUI (Closes: #983734). * Check build with autoconf 2.71-1 (Closes: #978925). * Remove deprecated full menu path for gimp (Closes: #982828). CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype: joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Re: avoiding autoremoval for what seems like a spurious build error
Thanks for the responses and attempts to build! Yes, it takes quite a bit of memory unfortunately, due to some very large auto-generated swig wrappers combined with some complicated boost usage. In any case, I was not so much asking for help building/reproducing, as I was asking what I can do other than to reply to the bug, which seems not to be eliciting a response, to either avoid or delay the auto-removal process. Is auto-removal policy documented somewhere? Unfortunately all my searches turn up "apt-get autoremove" help instead. I am really worried the package will get removed from the upcoming Debian release because of this. regards, Steve On Thu, Apr 29, 2021 at 11:47 PM Eriberto Mota wrote: > > I used a trivial jail with chroot. I can't reproduce the issue. > > Regards, > > Eriberto > > > Em qui., 29 de abr. de 2021 às 18:30, Tobias Frost escreveu: > > > > On Thu, Apr 29, 2021 at 05:25:28PM +0200, Stephen Sinclair wrote: > > > Hi Mentors, > > > > > > My package siconos currently has a bug filed [1] and has been marked > > > for autoremoval from testing. > > > > > The problem is that I cannot reproduce it. The failure is on a test > > > that depends on another package, so I am wondering if there was just a > > > glitch here? I have replied to the bug report with working build > > > logs, but there has been no further activity, so I am not sure what > > > further action I can take to avoid that the package gets removed. > > > > > > Thanks for any help. > > > Steve > > > > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986515 > > > > I could also not reproduce it in a pbuilder chroot. Might indeed be a glitch > > or some other dependency causing this… > > I'd either downgrade it to non RC and tag it unreproducible or close it with > > the request to reopen if it pops up again. > > > > -- > > tobi > > >
Re: avoiding autoremoval for what seems like a spurious build error
On Tue, May 4, 2021 at 7:48 PM Stephen Sinclair wrote: > > In any case, I was not so much asking for help building/reproducing, > as I was asking what I can do other than to reply to the bug, which > seems not to be eliciting a response, to either avoid or delay the > auto-removal process. Is auto-removal policy documented somewhere? For that you'd follow Tobias' suggestion: > I'd either downgrade it to non RC and tag it unreproducible or close it with > the request to reopen if it pops up again. Practically, that means you'd either downgrade the bug's severity [1] to "important" or below to make it non-RC [2], or close it [3]. The connection between RC bugs and auto-removal is documented here [4]. [1] https://www.debian.org/Bugs/server-control#severity [2] https://www.debian.org/Bugs/Developer#severities [3] https://www.debian.org/Bugs/Developer#closing [4] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#removals-from-testing
