Control: retitle -1 ITA: rpy2 -- Python3 interface to GNU R
I'm planning to work on this, possibly in debian-science.
Do you have any existing work on 3.6, and if so where? (Salsa looks
like you don't.)
Thank you.
On 05/05/2025 01:20, Charles Plessy wrote:
So please feel free too go ahead.
I intend to leave this until after release, since Normal bugs aren't
supposed to be fixed during freeze.
I have seen a value of 30 at the following line.
https://github.com/r-lib/httr2/blob/main/test
Control: tags -1 patch
I agree this is probably caused by the timeout being too short for slow
hardware (such as the current riscv64 test runners). My (untested)
attempt to increase the timeout is below.
It's *not* an urgent problem, as retrying failures usually works.
> Indeed it seems tha
On 01/05/2025 10:47, Chris Hofstaedtler wrote:
Is this a known bug in some older test runner? If so, is that fixed,
so future failures will be correctly treated as failures?
Yes, that's the r-cran-testthat issue mentioned earlier (*possibly*
https://github.com/r-lib/testthat/issues/1997 ), fix
Control: tags -1 pending
On 30/04/2025 19:40, Rebecca N. Palmer wrote:
In the longer term, we probably also want a mechanism to remind us to do
that if libjs-bootstrap4 is updated; I vaguely remember there being a
static linking register for that purpose.
It's
https://salsa.debia
I've seen two more instances of this, r-bioc-keggrest/arm64
(https://ci.debian.net/packages/r/r-bioc-keggrest/testing/arm64/57700381/
listed as reference, underlying problem is #1104334) and
r-cran-rmarkdown/arm64
(https://ci.debian.net/packages/r/r-cran-rmarkdown/testing/arm64/57691211/
liste
Control: tags -1 fixed-upstream patch
It looks like this is because the service this connects to started
adding a blank line between entries, which this can't handle. This is
known upstream and easy to fix:
https://github.com/Bioconductor/KEGGREST/commit/b9132b53ecc8ba501e5976994fa7429568cd1
Control: tags -1 patch
It passes on Salsa (i.e. after rebuilding the package) but fails on
debci. It looks like the reason is that this package uses a patched
_variables.scss created at build time, but a link to _transitions.scss,
so it's seeing the build-time (libjs-bootstrap4 4.6.1) _variab
Control: severity -1 wishlist
This package can't migrate during the soft freeze because the new
version adds a dependency on r-cran-cards, which is not currently in
testing at all.
Since there are no other Debian bugs in the testing version, and we can
do a +really revert if it does become n
Package: r-cran-bslib
Version: 0.9.0+dfsg-2
Severity: serious
Control: affects -1 r-cran-rmarkdown
Since twitter-bootstrap4 4.6.2 added transition-collapse-width, some
r-cran-bslib and r-cran-rmarkdown tests are failing with
Error in `compile_data(sass_input, options)`: Error: Undefined variab
Package: dh-r
Version: 20241218
R 4.5 added at least one symbol (R_getVar) to the C API, but did not
increment r-api.
Some R packages (that can be built against either R 4.4 or 4.5) link to
this symbol when built against R 4.5. Hence, if such a package is built
against R 4.5, attempting to
Control: reopen -1
Control: retitle -1 r-cran-timechange: should depend on R>=4.5
Control: reassign -1 r-cran-timechange
Control: affects -1 r-cran-caret r-cran-dbitest r-cran-epir
Control: affects -1 + r-cran-lubridate r-cran-recipes
Control: affects -1 + r-cran-themis r-cran-tidyverse
This isn'
Package: r-cran-plotly
Version: 4.10.4+dfsg-2
Severity: serious
r-cran-plotly test-Depends (and runtime Recommends) r-cran-dendextend,
which is not in testing.
Because of this, it's migration-reference autopkgtests are failing as
uninstallable, which is RC by
https://release.debian.org/testi
My understanding of this policy is that you *can* download *data*, but
can't download and run executable code:
https://sources.debian.org/src/autopkgtest/5.49/doc/README.package-tests.rst/#L569
pandas has network-using tests and they're passing.
Hence, the Forbidden in this particular test is pr
Package: release.debian.org
The testing excuses list sometimes shows an autopkgtest as 'Regression',
with the reference link going to an old (often old enough that the log
is no longer available) passing migration-reference, when a newer
migration-reference exists and failed (i.e. when the fai
Package: r-bioc-keggrest
Version: 1.46.0+dfsg-2
Severity: serious
The autopkgtest is failing with this error:
ERROR in test_keggGet: Error in if (.self$lastField == "REFERENCE") { :
missing value where TRUE/FALSE needed
I have not yet investigated why.
It's r-base 4.5 that's blocking r-cran-fansi, not the other way round.
It looks like the reason is that r-cran-fansi's tests (possibly
unintentionally) assert that it doesn't produce warnings, while loading
a package built in R 4.5 into R 4.4 triggers a warning.
https://salsa.debian.org/release-team/britney2/-/blob/master/etc/britney.conf
Thanks. (The britney-in-general documentation giving the name of the
setting was easier to find than the britney-in-Debian configuration, and
I'd probably mistaken it for a conf.d directory where all the files are
Control: retitle -1 autopkgtest fails on a 32-bit architecture
As discussed in #1099927, the new r-cran-testthat didn't break these, it
just started noticing that they were already broken. As only 32-bit
architectures are affected, we intend to remove/ignore them.
Thanks, and I agree with the above analysis: the buildd logs confirm
that r-cran-svglite was binNMUd recently on armhf only, and debci says
r-cran-svglite/armhf is currently broken in testing but working in
testing + R 4.5.0,
https://ci.debian.net/packages/r/r-cran-svglite/testing/armhf/
r-bas
Package: dh-r
Version: 20241218
Tags: patch
The 'generic' test runner (but not 'run-unit-test') runs tests/*.R with
the current directory at the package root. This fails for tests that
refer to other files and expect to be run from the tests directory (e.g.
this is standard for tests that use
In addition to the 3 packages mentioned here, there are 11-13 other R
packages that are broken only on less common architectures; these are
*not* blocking r-cran-testthat / r-base, but need to be dealt with (e.g.
by partial removal) at some point if we want to keep them on amd64.
https://bugs.
r-cran-testthat 3.2.1.1-1 had a bug (*possibly*
https://github.com/r-lib/testthat/issues/1997 ) where some kinds of test
failure would print a failure message but return a non-error state,
causing autopkgtests to "pass" when they shouldn't. r-cran-testthat
3.2.3-1 fixes this bug.
This expose
Those all look like rounding errors (probably due to x87 excess
precision, since they only happen on i386). This suggests that the
appropriate response is either to ignore these tests on i386, or
possibly (the graph object output by gdf_to_nx has (x: float, y: float)
node keys, so rounding iss
This has failed twice on reproducible-builds, and started failing
between 2025-02-23 and 2025-04-20:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/skimage.html
No other architectures have been tried since 2025-03-26, so we don't
actually know whether it's arm64-specific.
T
This passes its tests in unstable but still fails them in testing. I
don't know whether this is caused by R 4.5.0 vs 4.4.3 or by some other
package.
As far as I know, nothing is actually wrong with the old (testing)
version other than that it's old, so just accepting that the new version
won
Package: r-cran-sparsevctrs
Version: 0.2.0-1
Severity: serious
Tags: patch
The autopkgtest is failing with
Error in `coerce_to_sparse_matrix(mtcars)`: The package "Matrix" is
required.
(I'm not sure why this is only now actually failing, when it's always
had that error message: possibly a re
Package: python3-lmfit
Version: 1.3.3-1
test_manypeaks_speed has a time limit which usually, but not always,
fails on riscv64:
https://ci.debian.net/packages/l/lmfit-py/testing/riscv64/
The obvious fix would be to either raise the time limits (there are 3,
at tests/test_manypeaks_speed.py:33-
Unfortunately not: those always were "ignore these tests to not block an
unrelated transition" workarounds, not actual fixes (which is why I
didn't close this bug).
As far as I'm aware, the status of this bug hasn't changed since the
description earlier in this thread.
Control: reassign -1 python3-billiard
Control: tags -1 patch upstream
Control: retitle -1 '_Code' object has no attribute 'co_qualname'
This is also happening in CI since around 20 March.
The trigger appears to be python 3.13.2-2 adding this patch from
upstream git:
https://sources.debian.org/
Control: tags -1 - pending
That didn't work, but in a way that suggests that's the wrong syntax to
ignore a warning, not that it's going to take more than that. I intend
to try again today.
Control: tags -1 pending
The part you refer to isn't the autopkgtest failure - pandas' pymysql
and psycopg2 tests are known not to work in our test environments, so
the main autopkgtest doesn't install these. To monitor this, an extra
'ignoredtests' does install them but ignores the resulting
Control: tags -1 patch
This suggests that updating Debian's python3-moto to 5.1.1 will fix this
bug.
Doing that the straightforward way does build, but I haven't yet tried
building smart-open with it:
https://salsa.debian.org/rnpalmer-guest/python-moto/-/pipelines/829615
(The Lintian errors
Control: reassign -1 python3-moto
Control: found -1 5.0.11-3
Control: tags -1 fixed-upstream
Control: retitle -1 smart-open FTBFS: tests hang/fail - moto too old
*Possibly* we have a bad combination of boto* and moto
versions?
Looks like we do - when botocore/boto3/moto are installed via pip,
Control: tags -1 - patch
Control: tags -1 - pending
Control: retitle -1 smart-open: tests fail, S3 possibly broken
That no longer looks like a real solution, as it's not just tests
looking at the underlying binary representation that fail: there are
also tests (e.g. test_readline, test_s3_iter_
Control: tags -1 patch
In addition to the hangs, several tests fail.
It looks like the trigger is botocore enabling checksums by default:
https://sources.debian.org/src/python-boto3/1.36.0%2Bdfsg-1/CHANGELOG.rst/#L12
Turning them off with AWS_REQUEST_CHECKSUM_CALCULATION=when_required
makes th
This also hangs in debci, and began doing so between 2025-01-29 and
2025-02-01 (in unstable):
https://ci.debian.net/packages/s/smart-open/unstable/amd64/
Looking at what changed version between those, the obvious guess is
python3-botocore 1.35 -> 1.36 (which did not trigger an autopkgtest
beca
]
+ * Drop myself from uploaders.
+
+ [ Andrej Shadura ]
+ * Switch to team maintenance.
+
+ -- Rebecca N. Palmer Sat, 08 Mar 2025
13:51:17 +
+
gulkan (0.15.1-2.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru gulkan-0.15.1/debian/control gulkan-0.15.1/debian/control
+
+++ tint2-17.0.1/debian/changelog 2025-03-08 13:54:41.0 +
@@ -1,3 +1,10 @@
+tint2 (17.0.1-1.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Link tint2conf against libm. (Closes: #1082699)
+
+ -- Rebecca N. Palmer Sat, 08 Mar 2025
13:54:41 +
+
tint2 (17.0.1
-0.15.1/debian/changelog 2025-03-08 13:13:58.0 +
@@ -1,3 +1,10 @@
+gxr (0.15.1-4.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Be compatible with gcc 14. (Closes: #1075057)
+
+ -- Rebecca N. Palmer Sat, 08 Mar 2025
13:13:58 +
+
gxr (0.15.1-4.1) unstable; urgency
Control: retitle -1 snakemake: tests randomly failing or hanging
The autopkgtest has also failed several times recently, usually on
pipe-related tests, with either an unexpected number of outputs (race
condition??) or a timeout.
I don't yet know what causes this.
Control: tags -1 patch
The fix992793 branch in Salsa updates this manpage, and also adds one
for isort-identify-imports.
It has the lintian warning
groff-message troff::23: warning [p 1, 2.8i]: cannot
adjust line [usr/share/man/man1/isort.1.gz:1]
which probably refers to the long line withou
On 28/01/2025 14:21, Andrey Rakhmatullin wrote:
It failed the arch:all build ("dh_installdocs: error: Cannot find (any
matches for) "doc/build/html"")
Probably because I typed the path wrong.
(If you're wondering why I didn't upload the previous Salsa commit, that
did build: it had a no-copyr
Uploaded something, but without time to check if it builds. If it
doesn't, you have my permission to try fixing it, or I'll try again tonight.
Package: python3-pandas,python3-dask
Version: 2.2.3+dfsg-6,2024.12.1+dfsg-1
The pandas test test_frame_setitem_dask_array_into_new_col is failing in
Salsa; it looks like assigning a dask array to a DataFrame used to make
a copy and now does not.
I'm not sure yet whether this is an actual prob
It's not going to be tonight, because my first few attempts didn't work.
If current Salsa builds, I intend to upload it in the morning.
(It did get far enough to find that there are two new test failures, one
that should now be fixed and one that I'll file a separate bug about.)
pandas needs to skip some tests *anyway* if you want it built now
(because of #1088988), so it probably makes most sense for me to just do
a sourceful upload of pandas that temporarily drops the dependency and
skips/ignores whatever tests would otherwise fail. (This isn't a _fix_,
but it shoul
The build log shows that the .so files are getting installed but the .py
files (including Image.py, hence this error) aren't.
The Debian build includes 'rm pyproject.toml', so this *might* mean
upstream has started putting something essential in there.
Package: pagure
Version: 5.14.1+dfsg-1
test_dumping_reloading_ticket and test_install_plugin*/test_plugin* are
currently skipped because they fail.
Package: pagure
Version: 5.14.1+dfsg-1
Control: block 1059933 by -1
On 17/01/2025 14:48, Alexandre Detiste wrote:
This thing showed up on my radar because it still depends on six & mock.
On 02/01/2025 08:11, Rebecca N. Palmer wrote:
I'm not yet sure whether it will be reasonably possible to get [pagure] into a
state that we want to keep, or whether I will end up deciding to remove it.
My version in Salsa appears to be working except for plugins and
dump+reload, which is
On 12/01/2025, Simon McVittie wrote:
Normally we keep the patch's upstream authorship when applying patches,
So do I when using DEP-3 (Author:) tags, which is my more usual format.
(because it looked like you've taken the patch directly from upstream
rather than writing any code yourself).
Control: retitle -1 pandas<->xarray data conversion issues
Control: affects -1 python3-xarray
After fixing the easy parts (see Salsa), there are 3 remaining issues:
- Datetime-with-timezone, categorical, python-string, and nullable
indices lose this dtype (becoming object dtype, keeping their v
These are testing conversion between DataFrame and xarray, and are
probably failing because xarray now handles extension types in some
places it previously didn't, but not everywhere -
https://github.com/pydata/xarray/issues/9661 .
"Attributes of DataFrame.iloc[:, 5] (column name="f") are differ
I suspect that the generate_archive patch has a bug: zf.writestr(zi,
path) sets the file contents of the symlink in the zip (i.e. the
filename it points to) to path (the filename of the original symlink,
not the filename it points to). Hence, it creates a symlink to itself,
not a symlink to wh
Control: retitle -1 ITA: pagure - git-centred forge
As you may have noticed, I have been fixing several bugs in pagure.
I'm not yet sure whether it will be reasonably possible to get it into a
state that we want to keep, or whether I will end up deciding to remove it.
(The linked Fedora notic
Control: tags -1 pending
As previously stated on #debian-security, there are actually four
security issues here, fixed by consecutive upstream commits:
- This issue: generate_archive() allows file access via symlinks
CVE-2024-47515
- Similar issues in _update_file_in_git() (with symlinks)
I take those to be a yes to wanting this option to *exist*, though if it
already exists in rebuilderd then it might make more sense to use that.
(It would probably also make sense to use rebuilderd instead of
reprotest on Salsa to save resources, i.e. requiring 1 extra build
instead of 2.)
H
Control: tags -1 patch
Control: tags 1085764 patch
Control: tags 1064530 patch
Control: tags 1046324 patch
These are all fixed in
https://salsa.debian.org/debian/pagure/-/merge_requests/2
(Caution: untested, beyond a CI run that doesn't run the upstream tests.)
I intend to look at pagure's othe
Control: tags -1 patch
(This is now RC because Python 3.13 tests are now run by default.)
The trigger for this is that __name__ (and possibly all objects that are
defined at startup???) is now in the set of objects that have the same
id between interpreter runs:
python3.12 -c
"print(__name_
Control: tags -1 patch
Using Path() as a context manager hasn't done anything since Python 3.9,
and is removed in 3.13:
https://docs.python.org/3/whatsnew/3.13.html#id4
Path.glob('**') now includes files as well as directories:
https://docs.python.org/3/whatsnew/3.13.html#pathlib
Fix:
https:/
Control: tags -1 patch
Control: retitle -1 parallel builds FTBFS - gtkdoc run too early
It is an ordering issue - disabling parallel builds avoids it.
Branches that do that are available here:
https://salsa.debian.org/rnpalmer-guest/libmbim/-/commits/fix1086284
https://salsa.debian.org/rnpalmer-
Control: tags -1 patch
That symbol is in libm, which main tint2 is linked against but tint2conf
isn't. (Possibly one of its other dependencies used to pull it in and
no longer does.)
Fix:
https://salsa.debian.org/debian/tint2/-/merge_requests/3
At least libmbim is caused by a meson upgrade - it succeeds with meson
1.5.2, and fails with 1.6.0.
*Possibly* an ordering issue - 1.5.2 always does the relevant step as
the last step, 1.6.0 doesn't.
I intend to investigate further.
Given the close timing and similar messages, these are probably the same
underlying bug. It does not appear to be known to either upstream.
Plausible triggers that were updated at the right time (Oct 19-24 in
unstable, 25-28 in testing) are meson and elfutils.
https://tests.reproducible-buil
Control: tags -1 fixed-upstream patch
This was probably triggered by python-attrs 24 removing the temporary
tuples from __eq__ (for efficiency):
https://sources.debian.org/src/python-attrs/24.2.0-1/CHANGELOG.md/#L46
This means that comparing an object to itself is no longer automatically
True
Control: tags -1 upstream patch
This is because Vulkan handles are always 64-bit, even when pointers aren't:
https://sources.debian.org/src/vulkan-loader/1.3.296.0-1/vulkan-headers/include/vulkan/vulkan_core.h/#L29
Hence, the fix is to use VK_NULL_HANDLE not plain NULL:
https://salsa.debian.org/
Control: tags -1 patch
This error correctly notes that subpass is an integer index, not a
pointer, in the underlying API:
https://sources.debian.org/src/vulkan-loader/1.3.296.0-1/vulkan-headers/include/vulkan/vulkan_core.h/?hl=3720#L3703
https://registry.khronos.org/vulkan/specs/latest/man/html
This is caused by ruby-attr-encrypted being updated to 4.x. (It was
known at the time that this would break ruby-devise-two-factor, but it
was needed for a new version of ruby-saml that contained a security fix,
#1081560.)
This is fixed upstream in 4.1.1:
https://github.com/devise-two-factor/
On 15/12/2024 14:06, Chris Hofstaedtler wrote:
Upstream repo apparently has disappeared:
https://gitlab.com/lyda/mmap 404s
The gemspec points there; the Debian metadata points to
https://gitlab.com/gitlab-org/mmap2 which does technically still exist,
but has had no commits for 7 years.
Control: tags -1 patch
This appears to be caused by libmagic 5.45 adding a new builtin test,
for SIMH tape files:
https://sources.debian.org/src/file/1:5.45-3/src/magic.h.in/?hl=80#L65
and the failing test checking that NO_CHECK_BUILTIN is exactly the
combination expected:
https://sources.de
This appears to be fixed - ruby-elasticsearch-model now builds in unstable:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/ruby-elasticsearch-model.html
(The log now instead says this package doesn't have a test suite, but
that appears to be true.)
It looks like the issue w
(Found while looking for semi-random RC bugs to work on, so I may be
missing context; if so, I apologize.)
This package appears to be abandoned upstream (no commits for 7 years),
does not appear to have any reverse dependencies (though be aware that
my checking methods are not perfect), and ha
(Found while looking for semi-random RC bugs to work on, so I may be
missing context; if so, I apologize.)
Should we be trying to fix this, or does it make more sense to update to
a newer upstream version?
Upstream have replaced this C extension by a Rust extension:
https://gitlab.com/gitlab-
Control: tags -1 patch
That is in golang-github-gogo-protobuf-dev, which was installed for the
buildd build (successful) but not for recent reproducible-builds
attempts (failed). Probably it used to be installed because some other
build-dependency was using it, but that package then switched
This appears to have been fixed: ruby-sanitize is now in testing, and
debci/autopkgtest is able to install this package in testing. This bug
should probably be closed.
(That autopkgtest fails; see
https://salsa.debian.org/ruby-team/ruby-gitlab-markup/-/merge_requests/1
to fix that.)
Control: tags -1 patch
The fix for this is to always export the symbols (but not actually run
the tests):
https://salsa.debian.org/qt-kde-team/kde/kxmlrpcclient/-/merge_requests/3
Making the symbols optional wouldn't be a full solution, because the
definition of nocheck (
https://wiki.debian
Should we merge #786644 and #1019742? Or should we consider #1019742 to
be "have the option" and #786644 to be "enable it by default"?
I'm willing to try implementing this, if we agree that having it is a
good idea. Maybe use _PROFILES rather than _OPTIONS and allow it to be
more general tha
Control: tags -1 patch
This looks similar to kimap #1086766: nocheck turns off BUILD_TESTING,
and this package ships some items that are only built with that on.
(nocheck is not allowed to change the contents of a package.) The
upstream code even notes (at src/KGantt/CMakeLists.txt:15) that t
Control: tags -1 patch
It needed ccb232e435ae3d83559486fce1fdb5866e07 as well, but now
builds and passes autopkgtests:
https://salsa.debian.org/qt-kde-team/extras/clazy/-/merge_requests/4
Alternatively, depending on llvm/clang 18 instead of unversioned, or
upgrading to an upstream git sna
Control: tags -1 patch
Since there's no DEB_*FLAGS_MAINT_APPEND for cmake and this package uses
BUILD_TESTING in only one place, it's possibly easier to patch out that use:
https://salsa.debian.org/rnpalmer-guest/kimap/-/tree/fix1086766?ref_type=heads
(This runs Salsa CI reprotest, though not
Control: tags -1 - patch
The above suggestion does not work:
In file included from
/builds/rnpalmer-guest/clazy/debian/output/source_dir/src/checks/manuallevel/container-inside-loop.cpp:8:
/builds/rnpalmer-guest/clazy/debian/output/source_dir/src/ClazyContext.h:
In member function 'bool ClazyC
Control: tags -1 fixed-upstream patch
The merged bug and the timing suggest that this was caused by LLVM/Clang 19.
Probably-this issue has also occurred in upstream's CI, though I don't
see an actual upstream bug report:
https://invent.kde.org/sdk/clazy/-/commit/5a86780f0db6969725bd1336b4914bc4
On 09/12/2024 21:13, Salvatore Bonaccorso wrote:
But what happens if built with --without-libsoup, I guess then TLS
certificate validation is absent as well what are the consequences?
When built --without-libsoup, the web functionality is disabled
entirely. (Implemented in providers/Makefile.
Control: forwarded -1
https://gitlab.freedesktop.org/xdg/startup-notification/-/issues/7
Control: tags -1 patch
Fixed by
https://salsa.debian.org/gnome-team/startup-notification/-/merge_requests/2
This *probably* doesn't affect Debian stable (5.2.10-3) and later, as
they were built --without-libsoup (to avoid an unrelated crash,
#1017528), and the description and upstream fix suggest that the
vulnerable functionality requires libsoup. Is this enough evidence to
mark it as non-vulnerable
This began failing between 2023-06-19 and 2023-07-01 in experimental
(unstable also has #1040746, experimental doesn't), which if the trigger
is gegl, means between gegl 0.4.44 and 0.4.46:
https://tests.reproducible-builds.org/debian/history/gnome-photos.html
It is still failing (gegl 0.4.50), i
On 08/12/2024 13:11, Rebecca N. Palmer wrote:
In particular, we may need https://salsa.debian.org/
gnome-team/railway-gtk/-/blob/debian/latest/debian/patches/gtk-
rs-0.9.patch?ref_type=heads
On closer inspection, we don't need that patch because this version of
railway-gtk doesn&
This package does build on amd64 in the reproducible-builds service. (It
sometimes fails on armhf but that's a different problem, where it thinks
it's in a cross environment.)
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/glib-networking.html
However, it's not entirely clear
Control: tags -1 patch
(but a risky one, see below)
This FTBFS is because Rust -dev packages are versioned: it's
librust-gdk4-0.9+default-dev now. Updating the versions makes it build:
https://salsa.debian.org/rnpalmer-guest/railway-gtk/-/tree/debian/trixie?ref_type=heads
However, I have *not
nautilus also FTBFS in reproducible-builds (on all architectures tested,
not just arm64) at around that time, but now builds successfully there:
https://tests.reproducible-builds.org/debian/history/nautilus.html
The logs aren't kept, so there's no proof that this was specifically
this bug, but i
gtk-doc also FTBFS in reproducible-builds from approximately 2024-05-30
to 2024-09-24 in unstable (but not in trixie, meaning the bug was in
something other than gtk-doc) but now builds successfully:
https://tests.reproducible-builds.org/debian/history/gtk-doc.html
The logs aren't kept, so there
This package no longer contains a gda-config-tool* (with or without this
bug). It does contain a gda-list-config, but as far as I can easily
find, neither that nor any of its other tools claim to have a --usage
option.
Hence, I suggest closing this bug.
That's the upstream source repository, not rendered documentation, but
there doesn't seem to be anything better (the
http://developer.gnome.org/gdl/ suggested in the documentation does not
exist; I have reported this as
https://gitlab.gnome.org/GNOME/gdl/-/issues/11 ) and it is common to use
t
Control: tags -1 patch
Now fixes them all and builds successfully, but I have not tested the
result. (gdl has no tests in the package.)
I maybe have a proper fix for this one, but there are more:
https://salsa.debian.org/rnpalmer-guest/gdl
I intend to look at that later.
Control: tags -1 patch
This (untested) patch may fix this bug, but given the more general
issues around caribou's obsolescence (see other bugs), it might be
better to just remove it.
--- caribou-0.4.21.orig/modules/gtk3/caribou-gtk-module.c
+++ caribou-0.4.21/modules/gtk3/caribou-gtk-module.c
On 03/12/2024 22:19, Jeremy Bícha wrote:
The Debian GNOME team uses git formatted patches since they apply more
cleanly with our git-buildpackage (gbp pq) workflow,
Sorry. Reformatted version here:
https://salsa.debian.org/rnpalmer-guest/brasero/-/tree/fix1074854v2?ref_type=heads
(Still can't
Not *obviously* known upstream. Some type mismatches (like this one),
some shape mismatches that suggest different handling of duplicates in
indexes.
(There's also two other apparently unrelated issues that can make pandas
FTBFS: test_spss_metadata, and parso not supporting python 3.13.)
I
This applies the above upstream patch to Debian brasero; it builds, but
that's all the testing it's had.
https://salsa.debian.org/rnpalmer-guest/brasero
(Not a real merge request because the above repository was created with
'git push' and hence isn't officially a fork.)
1 - 100 of 1136 matches
Mail list logo
