[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1041485: RFS: spades/3.15.5+dfsg-2.1 [NMU] [RC] -- genome assembler for single-cell and isolates data sets



Hi Bo,

Bo YU, on 2023-07-20:
> On Thu, Jul 20, 2023 at 2:27 AM Étienne Mollier <emollier@debian.org> wrote:
> > Bo YU, on 2023-07-19:
> > > I am looking for a sponsor for my package "spades":
> > […]
> > > Changes since the last upload:
> > >
> > >  spades (3.15.5+dfsg-2.1) unstable; urgency=medium
> > >  .
> > >    * Non-maintainer upload.
> >
> > If you happen to go by the Salsa login vimerbf-guest, then you
> > should have direct access to push directly to the team
> > maintained repository.  Don't hesitate to work there, and ping
> > the debian-med[1] list once you are happy with your changes and
> > they are ready for "Team upload.".  ;)
> >
> Yeah, it is me. I just got access at yesterday so I am not sure I can
> follow the workflow of Debian med team. But now I can try after your
> confirmation.:)

In case your haven't come by it yet, you can have a look and
bookmark the Debian Med policy manual here[1].  These guidelines
ensure rough consistency between packages under Debian Med
umbrella; there are about one thousand and a half.

[1]: https://med-team.pages.debian.net/policy/

If you agree to it, please feel free to proceed, git easily
allows reverting changes anyway; just don't force push without
discussing the matter on the mailing list first.

> > >    * Fix ftbfs on gcc-13. (Closes: #1037863)
> >
> > Thanks for your help fixing that bug, and also for the forward
> > upstream.  My only matter for head scratching is the following
> > hunk in your patch:
> >
> > --- a/assembler/ext/src/llvm/Signals.inc
> > +++ b/assembler/ext/src/llvm/Signals.inc
> > @@ -43,6 +43,7 @@
> >  #include "llvm/Support/Program.h"
> >  #include "llvm/Support/SaveAndRestore.h"
> >  #include "llvm/Support/raw_ostream.h"
> > +#include "llvm/Support/Signals.h"
> >  #include <algorithm>
> >  #include <string>
> >  #include <sysexits.h>
> >
> > Including cstdint would have probably been less intrusive, and
> > solves the build failure as far as I could test.  Was there a
> > specific reason to include the whole llvm/Support/Signals.h
> > instead of just cstdint?
> >
> Okay, I rebuild the package again without the change, it works.
> I recalled the background, maybe it messed up due to previous
> error I ignored. In fact, maybe I overlooked the log:
> ```
> [ 46%] Building CXX object ext/llvm/CMakeFiles/llvm-support.dir/StringMap.cpp.o
> In file included from /<<PKGBUILDDIR>>/assembler/ext/src/llvm/Signals.cpp:219:
> /<<PKGBUILDDIR>>/assembler/ext/src/llvm/Signals.inc:347:50: error:
> 'void llvm::sys::CleanupOnSignal(uintptr_t)' should have been declared
> inside 'llvm::sys'
>   347 | void llvm::sys::CleanupOnSignal(uintptr_t Context) {
> ```
> 
> I will clean up the change for here and upstream.

Sounds good, let us know once you pushed your modification.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier <emollier@debian.org>
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-    on air: Neal Morse - So Many Roads

Attachment: signature.asc
Description: PGP signature


Reply to: