Source: beancount
Version: 2.3.5-2build1
Severity: normal
Beancount 2.3.6-1 introduced a dependency on python3-oauth2client which
has unfortunately been deprecated for 7 years now. Unsurprisingly, there
are more and more issues popping up which is why I'm working on removing
it (especially from
Hi,
For the record, the latest releases now include signatures and 2.11.0 is
available: https://github.com/certbot/certbot/releases/tag/v2.11.0
Note that I was initially interested in newer released in order to be
able to remove dependency on python-oauth2client from
HI László,
Apologies, I was busy on other topics and I had gotten some initial
comments on the packaging too (d/copyright needing tweaks).
I can't upload and would appreciate sponsoring.
I've updated the packaging in the git repository:
I found https://tug.org/svn/texlive?revision=71214=revision this
morning. It only touches the win32 implementations however.
I did something similar for the non-win32 implementation and it fixed
the issue for me:
Hi Hilmar,
You're absolutely right, thanks for having a look and sorry for the
noise. Trying to go too fast was a bad idea yet another time. :)
I've straced the build and the file seems generated and I see some
interesting things. I've heavily edited the output because the original
is already
Hi,
I hit that issue while working on the vtk9 9.3 transition in Ubuntu and
I also tried to add 'texlive-fonts-recommended' as a dependency (at
least temporarily so that the transition can finish). Unfortunately it
only works on amd64. On arm64, armhf, ppc64el and s390x, the error is
still
Source: camitk
Version: 5.2.0-1
Severity: serious
Tags: ftbfs upstream
Justification: fails to build from source (but built successfully in the past)
While working on the vtk9 9.3 transition in Ubuntu, I found that the
package does not build with VTK 9.3 (at least one incompatibility was
/vtkgdcmpython.h
+
+ -- Adrien Nader Fri, 14 Jun 2024 17:04:24 +0200
+
gdcm (3.0.24-1build1) oracular; urgency=medium
* Rebuild against new libvtk9.3.
diff --git a/debian/control b/debian/control
index 648e47f..56a43dc 100644
--- a/debian/control
+++ b/debian/control
@@ -1,5 +1,6 @@
Source: gdcm
Hi,
I hadn't spotted your ITP until I had prepared
https://salsa.debian.org/adrien-n/python-google-api-core and was filling
an ITP myself.
Since it's ready and passing, I'd like to more forward with this. Do you
have any objection?
Thanks,
--
Adrien
Hi,
I attempted to dump the ABIs with a-c-c and the current script around it
but couldn't do so. The compiler complains that there is a type
definition inside sizeof() which is pretty accurate.
This happens through the following:
> RAFT__ASSERT_COMPATIBILITY(RAFT__RESERVED, RAFT__EXTENSIONS);
On Fri, Feb 16, 2024, Adrien Nader wrote:
> I was able to analyze the library after modifying auth.h (actually
> cyrus/*.h) to use cyrus/strarray.h and skipping bitvector.h. The
> analysis returns that the library is both time_t and LFS sensitive. I
> will publish a report soo
Hi,
I am trying to update the time_t analysis and I'm seeing a couple issues
in headers. Note that I may also be doing something wrong and/or stupid
since I'm approaching this through a-c-c rather than as a regular user.
The two issues:
- at least auth.h (IIRC) refers to lib/strarray.h but the
Hi,
I just ran the analysis again: the ABI was dumped without requiring
any quirk. After diff, the result is that the ABI is not affected by
either time_t or LFS. :)
I don't publish results after every update as that would be overwhelming
but I should do so by friday evening.
--
Adrien
On Fri, Feb 09, 2024, Christoph Berg wrote:
> Re: Adrien Nader
> > I think the most recent version of that script would be in my
> > repository: https://salsa.debian.org/adrien-n/armhf-time_t/
>
> Hi Adrien,
>
> I actually got the script running, I th
Hi Christoph,
The automated assessment uses a script which in turns uses
abi-compliance-checker.
I think the most recent version of that script would be in my
repository: https://salsa.debian.org/adrien-n/armhf-time_t/
The README.md file describes it (it doesn't describe other tools in that
repo
Hi Helmut,
Thanks for identifying and raising this issue.
After Graham mentioned this to me, I also looked at the reports and came
to the same conclusion: the change is actually LFS due to ino_t in
matchpathcon_filespec_add().
Providing two APIs makes me quite uneasy due to having core
I had a look at this and it appears that you can't build the gstreamer
element along the rest of the sources: you need to install svt-av1
first.
It doesn't look easy to integrate this into the current build
unfortunately. It might be better to create a separate package. Do you
have any thought on
Package: sslscan
Version: 2.0.16-1~ppa1
Severity: wishlist
Hi,
Can you update sslscan to the latest version? I have tried doing it
myself and it required no change. I didn't try to include a patch here
due to how simple the update actually is.
I also notice that you haven't updated the package
Hi,
Ssslcan does not use openssl for the ssl/tls protocols anymore. It still
uses it for some things but not for the protocols themselves.
This is explained by the following in README.md:
> sslscan version 2 has now been released. This includes a major rewrite
> of the backend scanning code,
Source: svt-av1
Version: 1.4.1+dfsg-1
Severity: wishlist
Hi,
There is a gstreamer element in the "gstreamer-plugin" directory. Can
you package it? At the moment the only gstreamer element available to
encode using AV1 is libaom.
Thanks.
On Wed, Jun 21, 2023, julien.pu...@gmail.com wrote:
> Le mardi 20 juin 2023 à 22:38 +0200, Adrien Nader a écrit :
> >
> >
> > The patch seems to fix the issue. I say "seem" because the build
> > compiled the file that was failing to build but the build is n
On Tue, Jun 20, 2023, julien.pu...@gmail.com wrote:
> Hi,
>
> Le mardi 20 juin 2023 à 15:35 +0200, Adrien Nader a écrit :
> > I was looking at the migration for coq on Ubuntu and a build failure
> > on armhf is preventing it.
> >
> > I expect that this issue
Source: gnustep-base
Version: 1.29.0-4
Severity: normal
Tags: patch upstream
Hi,
While working on Ubuntu's migrations, I noticed gnustep-base would
FTBFS due to network tests failing.
There's an upstream commit to improve this:
Hi,
I was looking at the migration for coq on Ubuntu and a build failure on
armhf is preventing it.
I expect that this issue is fixed by the following commit:
https://github.com/UniMath/UniMath/commit/1716c078b00c18dcabf63f671e414d7ba33cb23c
Split the proof of associators_equiv to make
Hi,
I was looking at this FTBFS in Ubuntu and noticed that upstream has
migrated to github, away from bitbucket. You can see a link from the
current upstream page to pypi and then land on github. It is not the
same person though but both of them are listed on the pypi page.
I'm going to email
Package: datefudge
Version: 1.24
Severity: important
Dear Maintainer,
When updating coreutils to version 9.1 in Ubuntu, we noticed that
datefudge autopkgtests started failing on armhf.
As far as I can tell, the reason is that coreutils now uses a 64-bit
time_t and functions with a "64" suffix.
26 matches
Mail list logo
