I discussed this issue upstream and it looks like the current behavior
when using `hostonly=no` may be a bug. See [1]. Setting `hostonly=yes
hostonly_mode=sloppy` might be the wrong thing to do.
[1] https://github.com/dracut-ng/dracut-ng/pull/1238#issuecomment-2814286818
pgpEiROfUxkQ3.pgp
Descri
Package: dracut
Version: 106-5
Severity: critical
X-Debbugs-Cc: adrela...@whonix.org, arraybo...@ubuntu.com
Unsure if the chosen severity is appropriate, but this bug renders
affected systems unbootable and the recovery procedure is a serious
headache, so I think this counts as "breaking the whole
Source: fltk1.3
Version: 1.3.11-1
Severity: serious
fluid should remain continuously available in testing.
-- System Information:
Debian Release: trixie/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'oldstable-securit
he diverted instance or its own code,
depending on usage. (Their syntax is conveniently very different.)
Likewise for einfo, as also found in epub-utils.
Thanks for checking, though!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cg
Somehow my email setup is b0rked and I'm only just now learning about
this bug. Mohammed Bilal graciously prepped an NMU to fix it, which he
sent me a debdiff of and which I reviewed and +1'd, so hopefully this
won't be a problem for much longer. I guess I'll figure out what I did
wrong with emails
* Add Breaks/Replaces against older versions of calamares-extensions.
+(Closes: #1087059)
+
+ -- Aaron Rainbolt Wed, 18 Dec 2024 17:48:25 -0600
+
calamares (3.3.12-1) unstable; urgency=medium
* New upstream release
diff -Nru calamares-3.3.12/debian/control calamares-3.3.12/debian/co
FYI, unless anyone has objections, I intend on proposing an NMU for
this later today, and will work to find a sponsor for it on Friday.
pgp_sLkuhCa62.pgp
Description: OpenPGP digital signature
This is because of a module that moved from calamares-extensions to
calamares. calamares-extensions 3.3.11 solves the issue, however a
tarball of it hasn't been published yet. I've pinged the Calamares
developers to see if a full release of calamares-extensions 3.3.11 can
be made. Once that's done
anyone on this thread is able, would you mind uploading this package ?
Many Thanks,
Aaron
Package: gzip
Version: 1.12-1.1
Severity: serious
Justification: Policy 3.8
X-Debbugs-Cc: arraybo...@gmail.com
gzip is a package with priority "essential". It currently suggests the
"less" package, which has priority "important". less is a hard
dependency of zless - if it is not installed, zless w
Hello,
Project maintainer here.
I will be releasing a new package for libgrokj2k in the coming week, which
should address this armhf bug.
Cheers,
Aaron
upload a fix when I get a
chance, probably over the weekend. Sorry for the noise about slated
autoremovals, meanwhile.
--
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
n overhead would be negligible in practice.
Thanks!
--
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
Andreas Tille writes:
>Build-Depends libthread-pool 4.0.0 which does not build
>for 32bit architectures[1]
I see a fix in experimental:
https://buildd.debian.org/status/package.php?p=libthread-pool&suite=experimental
Why not just reupload it to unstable?
--
Aaron M. Uc
arrange for unaffected architectures' dependency templates to read e.g.
libfltk1.3t64 #MINVER# | libfltk1.3 #MINVER#
Sorry if I missed any relevant discussion; I must confess I haven't
followed -devel in years. :-/
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
ht
Source: abinit
Version: 9.10.4-2
Severity: serious
Tags: ftbfs upstream
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: arraybo...@ubuntu.com
When building the abinit package on a system with Python 3.12 installed,
the build fails with a "ModuleNotFound
On 12/10/23 12:08, Bas Wijnen wrote:
On Sun, Dec 03, 2023 at 02:18:38AM -0600, Aaron Rainbolt wrote:
[Catch 2]
While it is definitely possible to port the
openMSX tests to use catch2 v3, we will be departing from what
upstream supports, and that seems like it could lead to way more work
than
ttern "Contrib/cbios" to "Contrib/cbios/*.rom" in
debian/copyright. The change is minor enough I don't think it warrants a whole new debdiff
attachment, though I'm happy to make one if it would make your life easier.
--
Aaron Rainbolt
Lubuntu Developer
Matrix: @array
Is this bug something we're still actively working on? It's been a few
days. If I missed something, feel free to let me know.
--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub: https://github.com/ArrayBolt3
s *are*
compiled from other source code. Perhaps there's some sort of
heuristic there though (I've not looked at the Lintian code and I
don't know Perl, so I'm not sure).
> Thanks,
> Bas
>
> On Wed, Nov 29, 2023 at 06:50:59PM -0600, Aaron Rainbolt wrote:
> > Alr
On 11/30/23 16:34, Gregor Riepl wrote:
Hi Aaron,
Simon is uploading the new packaging to the DELAYED/1 queue. It
should arrive in the archive on November 30.
If you are a maintainer of slic3r-prusa, you can review the new
packaging in the mean time and reject or fast-track it as you see fit
with me so we could come up with the best
solution possible for this! The debdiff is attached.
--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub: https://github.com/ArrayBolt3
Binary files /tmp/jiw28Q_kI0/openmsx-19.1/Contrib/cbios/cbios
On 11/29/23 14:40, Bas Wijnen wrote:
On Wed, Nov 29, 2023 at 01:52:46PM -0600, Aaron Rainbolt wrote:
It appears that the C-BIOS package in Debian only ships the most recent
C-BIOS files. I think we can't just depend on it for this reason, since the
older C-BIOS ROMs are needed to avoid
Simon is uploading the new packaging to the DELAYED/1 queue. It should arrive
in the archive on November 30.
If you are a maintainer of slic3r-prusa, you can review the new packaging in
the mean time and reject or fast-track it as you see fit.
--
Aaron Rainbolt
Lubuntu Developer
Matrix
o
get a Debian Developer (Simon Quigley) to help me NMU Gregor's patch so
we can get this fixed before December 1st. The packaging is complete and
has been submitted to Simon for review.
--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.liber
It appears that the C-BIOS package in Debian only ships the most recent C-BIOS
files. I think we can't just depend on it for this reason, since the older
C-BIOS ROMs are needed to avoid save state breakage. See
Contrib/cbios-old/README in the openMSX package.
--
Aaron Rainbolt
Lu
n't want to break people's old save states. If the C-BIOS
package only ships the latest version of C-BIOS, then this solution
will not work. If it ships all needed versions and has them in the
right spots, then this would probably work..
> Thanks,
> Bas
>
> On Mon, Nov 27, 2023
/ArrayBolt3/openmsx-packaging.
--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub: https://github.com/ArrayBolt3
On 11/27/23 15:02, Manuel Bilderbeek wrote:
On 27-11-2023 02:11, Aaron Rainbolt wrote:
Alright, I have fully rebuilt the copyright file. I also ended up
adding the source code for several releases of C-BIOS into the
packaging. As this code is in the form of zipped files for the sake
of size
ight file. I suspect a Lintian bug here.)
--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub: https://github.com/ArrayBolt3
Failed to reply to the right address, so forwarding.
-- Forwarded message -
From: Aaron Rainbolt
Date: Sun, Nov 26, 2023 at 1:30 PM
Subject: Re: Bug#1056780: openmsx: Source-less Windows binary in
source package (and other packaging issues)
To: Manuel Bilderbeek
Thanks! I was
Further investigation trying to rebuild the copyright file has revealed
more binaries without source code (the C-BIOS ROMs for instance). So
I'll have to find the sources for those also. Thanks for your patience.
--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.or
opyright file should be
rebuilt from scratch by auditing the entirety of the openMSX source
code licenses. I can do that if it would be helpful.
--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub: https://github.com/ArrayBolt3
"Thank you for contacting us" emails from apple.com.
--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub: https://github.com/ArrayBolt3
Binary files /tmp/phkMJNskDj/openmsx-19.1/Contrib/codec/Win32/zmbv.dll and /tmp/Cd74GNmEnl/openms
Lintian gripes.
+ * Created debian/upstream/metadata file.
+ * Switch back to using vendored catch2, the catch2 Debian package now
ships
+ catch2 v3 whereas openMSX uses catch2 v2.
+
+ -- Aaron Rainbolt Fri, 24 Nov 2023 13:47:59 -0600
+
openmsx (19.1-1) unstable; urgency=medium
* New up
Package: openmsx
Version: 19.1-1
Severity: serious
Justification: Policy 2.2.1
X-Debbugs-Cc: arraybo...@ubuntu.com
Packages in the Debian `main` archive area *must* comply with the DFSG, of
which section 2 states "The program must include source code, and must allow
distribution in source code as
ndencies, so the
package will still need a sourceful upload; copying its migration bug
accordingly.
> I am going to file a RM bug when this is autoremoved from testing.
Thanks! To confirm, I don't need to do anything active here, just leave
this bug open at RC severity and reencourage drawxt
Control: severity 891197 normal
u...@debian.org (Aaron M. Ucko) writes:
> For the time being, we can switch to an embedded copy of classic PCRE by
> dropping the build dependency on libpcre3-dev; that's of course not a
> proper fix, but should at least let us downgrade this bug
f classic PCRE by
dropping the build dependency on libpcre3-dev; that's of course not a
proper fix, but should at least let us downgrade this bug's severity.
--
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
led. I went with a minimal fix, in part to
facilitate getting it into a stable update if anyone considers that
warranted.
--
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
andom_value here and in the other unittests/*map.hpp headers to
match the corresponding containers' declarations, per the attached
patch. The relevant platform difference is whether plain char is
signed, as it notably is on x86 but not arm*. (There are other
architectures in each camp.)
--
r broke the
logic to honor FLTK_SKIP_FLUID (which I've confirmed remains present).
Thanks for the report (reminiscent of [1], FWIW), and sorry for the
trouble!
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855040
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
ere sra-sdk 3.x stands in
terms of architecture support, which may be clearer with upgrades to
3.0.1 in place. I've been working on them, but a power outage last
weekend delayed me; I'll try to wrap them up this weekend.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Andreas Beckmann writes:
> during a test with piuparts I noticed your package fails to upgrade from
> 'sid' to 'experimental'.
Good catch, thanks!
--
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
VAAPI works nicely now under wayland, but users need to export
LIBVA_DRIVER_NAME=
Cheers.
Aaron.
libva info: VA-API version 1.15.0
libva info: User environment variable requested driver 'radeonsi'
libva info: Trying to open
/usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.solibva i
ackaging fix (for #624130) and stayed there by inertia.
--
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
lue:
std::unique_ptr&& is
--
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
errors in the rare cases where its usage would be problematic.
--
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
Adrian Bunk writes:
> Makes sense.
Thanks.
> It would also be useful if fltk1.3 would FTBFS when an input file was
> not found.
Don't worry, I'm already planning to put in such a safeguard at this
point. Sorry for missing this possible failure mode earlier.
--
Aaron M
xport/*/FLTK-Targets-none.cmake \
Got it, thanks, though I'm inclined to use find(1) so I'm not
specifically tied to new cmake.
--
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
t have been to patch CMake's input, but I want to
make some across-the-board tweaks that are best centralized modulo this
sort of wrinkle.) I'll take a look when I get a chance.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.
rence to `nfftf_init_1d'
[...]
Please try listing simple_test.c ahead of the libraries, which the
linker otherwise discards as apparently unneeded.
--
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
golang-github-pbnjay-memory-dev now that
the latter exists.
--
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
akefile to drop
the T flag from LINK.A (line 72).
--
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
command line later on.
> Any idea how to specify the number of object files more sensibly
> to not explode the command line arguments too much?
You (or upstream) could consider using internal static libraries.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http
rely for its own use.)
--
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
Hi Salvatore,
Yes, you are correct - commit 3191336c0708 fixed the issue.
I like to use rebase to squash commits, so I must have
squashed away the commit that is logged in oss-fuz.
Cheers,
Aaron
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Wednesday, October 27th
know if you have any other questions.
Cheers,
Aaron
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Wednesday, October 27th, 2021 at 15:34, Salvatore Bonaccorso
wrote:
> Hi,
>
> On Wed, Oct 27, 2021 at 08:57:06AM +, Debian Bug Tracking System wrote:
&
Andreas Tille writes:
> I'm wondering why the makefile stopped working just because a new compiler
> version is used. :-(
Along the way, you pulled in a new upstream version, whose makefile
evidently wasn't quite right.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at
p,%.o,$(wildcard source/*.cpp))
OBJECTS+=$(patsubst %.c,%.o,$(wildcard source/*.c))
to match the relevant sources' actual location; sorry if that was unclear.
(The existing setup only covers subdirectories of source, missing that
directory's immediate contents.)
--
Aaron M. Ucko,
/uchime_src/makefile to add -std=c++14 to CXXFLAGS,
thereby suppressing std::byte for now.
I also found massive link errors, resolvable by correcting the top-level
Makefile to pick up source/*.cpp and source/*.c rather than the
nonexistent *.cpp and *.c.
[1] https://en.cppreference.com/w/cpp/types/byte
ll look into
doing so when I get a chance.
--
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
Étienne Mollier writes:
> the pieces of the puzzle together. Thanks for your explanation,
No problem; please feel free to ping me if there's anything else I can
clarify.
Also, sorry for the badly half-baked metadata update.
> Have a nice day, :)
Thanks, you too!
--
Aaron M. U
Yes, 990743, already granted. It doesn't appear to have reduced the delay below
what the autopkgtest already gave, though.
-- Aaron
On July 15, 2021 12:08:17 AM EDT, Andreas Tille wrote:
>Hi Aaron,
>
>did you filed an unblock request to release.debian.org bug report?
&
Control: tag -1 pending
Hello,
Bug #990741 in ncbi-entrez-direct reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/med-team/ncbi-entrez-direct/-/commit/1520ff4905
Package: ncbi-entrez-direct
Version: 14.6.20210224+dfsg-3+b2
Severity: serious
Justification: maintainer prerogative
In the course of checking whether
https://bugs.launchpad.net/ubuntu/+source/ncbi-blast+/+bug/1934402
affects ncbi-blast+ in testing and unstable, I observed -- *only* -- a
different
(include)
Please try adding a build dependency on libclfft-dev and replacing
src/backend/opencl/CMakeLists.txt's inclusion of build_clFFT with a call
to
find_package(clFFT)
> Thanks a lot for your initial hint
No problem.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at
in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
(ll. 1472-1480).
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | htt
broadening this
workaround accordingly.
Meanwhile, thanks for pinging me -- I'd optimistically skipped
subscribing to this bug (but will do so now).
--
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
.org/970344), kleborate already supports
retrying in single-threaded mode under some circumstances; kaptive just
needs to indicate that it should do so, which it currently does only for
much older versions. I'll extend the relevant version range shortly,
and am reassigning this bug accordingly.
-
ails, I wanted to make very sure I
wouldn't be able to lose them. Sorry for any resulting confusion.
--
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
u...@debian.org (Aaron M. Ucko) writes:
> Andreas Tille writes:
>
>> do you have possibly any hint what might be wrong here?
>
> Thanks for calling this bug to my attention! Based on reports I've seen
> upstream, I suspect the problem may lie in some relatively new
&
gardless, in retrospect. I'll look into it.
--
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
s/Ivor/Ivo/ :)
On Tue, Mar 16, 2021 at 11:04 AM Aaron Boxer wrote:
> Thanks, Ivor. How would you recommend I test on i386?
>
> On Fri, Mar 12, 2021 at 6:33 PM Ivo De Decker wrote:
>
>> package: src:libgrokj2k
>> version: 7.6.6-2
>> severity: serious
>> ta
Thanks, Ivor. How would you recommend I test on i386?
On Fri, Mar 12, 2021 at 6:33 PM Ivo De Decker wrote:
> package: src:libgrokj2k
> version: 7.6.6-2
> severity: serious
> tags: ftbfs
>
> Hi,
>
> The latest upload of libgrokj2k to unstable fails on i386:
>
> https://buildd.debian.org/status/pa
Hello,
I have created a patch for this bug:
https://mentors.debian.net/package/libgrokj2k/
Thanks,
Aaron
On Mon, Mar 1, 2021 at 12:21 PM Adrian Bunk wrote:
> Source: libgrokj2k
> Version: 7.6.6-1
> Severity: serious
> Tags: patch
>
>
> https://buildd.debian.org/status/fet
Hello,
I have a patch for this bug on the mentors site:
https://mentors.debian.net/package/libgrokj2k/
Thanks,
Aaron
Hi Adrian,
Thanks very much for the bug report. I will make these changes.
So, is it not possible to enable AVX2 acceleration for this package ?
Regards,
Aaron
On Mon, Mar 1, 2021 at 12:21 PM Adrian Bunk wrote:
> Source: libgrokj2k
> Version: 7.6.6-1
> Severity: serious
>
e liberty to open an issue in their VCS.
Thanks!
gregor herrmann writes:
> I still think that NO_NETWORK_TESTING=1 should be set in debian/rules
> to make sure there's no internet access attempted during the build,
> as that is a policy violation.
Right, we're just discussing wh
Whoops, I had a typo in that last command; if you go that route, please
make it
makeblastdb -dbtype prot -in "$<" -out "$(@:.psq=)" -blastdb_version 4
(I'd first try pushing forward, though.)
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.
Control: tags -1 + upstream
Andreas Tille writes:
> Aaron (or whoever might want to check), do you have any idea?
Due to metastudent-data's unwieldiness, I haven't tested thoroughly, but
AFAICT the immediate, and with any luck only, problem is more fallout
from the switch to BLAS
and
meanwhile listing uncompressed man (and cat!) pages in
debian/not-installed.
--
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
Hey,
Thanks for working this out guys! I think arch:all is a good solution
having the Lua paths fixed upstream.
Aaron
On Mon, Oct 26, 2020 at 1:45 PM Lucas Nussbaum wrote:
> Hi,
>
> On 26/10/20 at 11:19 +0100, Baptiste Jonglez wrote:
> > Hi,
> >
> > On Tue, 15 Sep
larification: This variable is an override, not a cap, so any
unconditional settings thereof should be low enough to work on 32-bit
systems.
--
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
working in HPC at the moment. The
bug should definitely reported upstream. Upgrading the package should be fairly
simple though - the dependencies are already in place, as are simple tests/git
integration etc.: https://github.com/azet/lmod-deb
Thanks,
Aaron
> On 15.09.2020, at 09:33, Luc
much more than upstream's trunk
allows on Windows:
https://www.ncbi.nlm.nih.gov/IEB/ToolBox/CPP_DOC/lxr/source/include/objtools/blast/seqdb_writer/writedb_lmdb.hpp#L51
--
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
last/seqdb_writer/writedb_lmdb.hpp:52:59:
warning: integer overflow in expression of type ‘int’ results in ‘-647710720’
[-Woverflow]
occurs only in the logs for 2.10.0-2.
--
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
d will test it out when
I get a chance, probably tomorrow or Monday.
--
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
t;>
>> /<>/obj-x86_64-linux-gnu/src/golang.org/x/sys/internal/unsafeheader
>> (from $GOPATH)
Thanks for the report! I've prepared a fix, and plan to issue an upload
incorporating it (and getting closer to the latest upstream release)
this evening.
--
Aaron
Étienne Mollier writes:
> Thank you for the workaround!
No problem; happy to have been of help (and that it in fact worked).
--
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
t might
>> exceed too easily 32 bits architectural limits.
That's entirely plausible; upstream tends to assume 64-bit systems
nowadays. Explicitly supplying -blastdb_version 4 (the default prior to
BLAST+ 2.10.x) may help.
Thanks for calling this report to my attention!
--
Aaron M. U
Control: tag -1 pending
Hello,
Bug #961347 in sra-sdk reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/med-team/sra-sdk/-/commit/b36b20cb22242853e29881740e1cdfc0
report.
FTR, libncbi-vdb2 does already install the schemas; the problem is
getting it to acknowledge our differences from upstream's layout
preferences. I already saw this failure and am working on a proper fix.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit
Control: tag -1 pending
Hello,
Bug #961049 in sra-sdk reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/med-team/sra-sdk/-/commit/8ef4c86e26989677717f8bbabf617f5f
vdb needs a small tweak to fix installation of a semi-private
header sra-sdk uses.)
--
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
gt; *.nnd
*.nsi -> *.nni
*.psd -> *.pnd
*.psi -> *.pni
Thanks for checking!
BTW, python-biopython's build dependency on emboss reminded me that
emboss-data is still probably overkill for emboss(-lib)'s needs and
could stand to be split up (#682042).
--
Aaron M. Ucko, KB1C
Andreas Tille writes:
>> protected branches. Could you please adjust the project's permissions?
>
> Done (hopefully), Andreas.
I was able to push now, thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.
> If any of the commits was not helpful just rebase.
Thanks! I've uploaded with your generic commits cherry-picked (and a
bunch of changes of my own), but Salsa rejected my force pushes to
protected branches. Could you please adjust the project's permissions?
--
Aaron M. Ucko, K
off on pushing anything so I could have more
freedom to rebase in case I belatedly discovered something I should have
done earlier.
--
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
ed. I uploaded a correction just now.
Thanks for the report, and sorry about that!
--
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
1 - 100 of 1418 matches
Mail list logo
