aphic error
>
> My guess is that this is linked to the CVE-2025-27809 fix.
Just found, it is [1]. I will do other tests if I can fix it without
upstream involvement.
Thanks for the confirmation,
Laszlo/GCS
[1]
https://github.com/Mbed-TLS/mbedtls/commit/20c7748575320ff721d99ab64456532c0205c8d3
Hi Bastian,
Thanks for your pointers. Might you check the work in progress update
of socat if the copyright file is now correct and complete?
Thanks,
Laszlo/GCS
[1] dget -x https://people.debian.org/~gcs/socat_1.8.0.3-1.dsc
still broken. I'm going to retest it, but
sure something strange is going on.
Regards,
Laszlo/GCS
Control: unmerge -1
Control: reassign -1 src:loggedfs
Control: tags -1 +patch
Hi,
Your package forces C++11 standard during compilation. However it uses
ICU which is C++17 now. I attached a patch to use the C++17
standard and make your package compile again.
Regards,
Laszlo/GCS
Description: fix
Control: unmerge -1
Control: reassign -1 src:libxml++2.6
Control: tags -1 +patch
Hi,
Your package forces C++11 standard during compilation. However it uses
ICU which is C++17 now. I attached a patch not to force the C++
standard and make your package compile again.
Regards,
Laszlo/GCS
and uses that C++ standard. Then if you still would like to
force the C++ standard, compile with this: "g++ test.cpp -o test
-std=c++17".
I attach a patch for both cases, choose the one that you want and fix
_your_ source.
Regards,
Laszlo/GCS
Description: fix FTBFS with ICU 75.1+
Do not f
ith the former, might use different flags / values with FUSE v3.17.1
- need to check.
But if this is the reason, gvfs will need a binNMU with the final FUSE
v3.17.1 release.
Regards,
Laszlo/GCS
[1]
https://github.com/libfuse/libfuse/commit/3ae5ca7443348aabad9bc71b9d5b0999f8292379
;fuse: use
> fuse_(un)set_feature_flag instead of setting manually" from
> <https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/248>?
Yes, exactly commit 77581bc4 which can be viewed only at:
https://gitlab.gnome.org/GNOME/gvfs/-/commit/77581bc426025bd04bd7ccb3b61e9c20114bc44b?merge_request_iid=248
Laszlo/GCS
posed fix is already provided [4].
In very short, gvfs needs to be fixed. I can't do anything on the FUSE side.
Regards,
Laszlo/GCS
[1]
https://github.com/libfuse/libfuse/blob/fuse-3.17.x/include/fuse_common.h#L596
[2]
https://github.com/libfuse/libfuse/blob/fuse-3.17.x/include/fuse
.
Regards,
Laszlo/GCS
[1] https://github.com/libexpat/libexpat/issues/980#issue-2922101832
[2] https://github.com/libexpat/libexpat/issues/980#issuecomment-2734559744
[3] https://github.com/libexpat/libexpat/issues/980#issuecomment-2735149399
ou could take the approach from my previous patch, and
> upgrade to a newer upstream release.
That would require a double transition, starting with protobuf first.
I need to check it with the new abseil version in Sid.
Regards,
Laszlo/GCS
build
dependencies. Basically in d/control:
python3-all-dev:any (>= 3.5) ,
+ python3-setuptools ,
rename,
Please do apply this soon.
Regards,
Laszlo/GCS
t; deferred upload. debdiff attached, and also sent as PR:
>
> https://github.com/gcsideal/syslog-ng-debian/pull/13
Merged. Uploaded with other fixes, you can cancel the NMU.
Laszlo/GCS
are explained below:\fR
.IP "Around line 234:" 4
.IX Item "Around line 234:"
Unterminated L<...> sequence
I've fixed it and you can check my iteration [1] if it meets your approval.
Thanks for your contribution,
Laszlo/GCS
[1] dget https://people.debian.org/~gcs/apt-src_0.25.4.dsc
Hi Helge,
On Wed, Feb 26, 2025 at 7:47 PM Helge Kreutzmann wrote:
> So at the weekend I'll prepare the NMU. You can fine tune it
> afterwards, but this way apt-src is in Trixie.
Please send it to me when it's ready. I'll check and sponsor the upload.
Regards,
Laszlo/GCS
ue at least. Can you retry your testing if
this issue still affects you or not?
Thanks for your work,
Laszlo/GCS
t it also help to add Provides: python3-google-api-python-client
to my package? This way it would be visible as it is available from
that binary package.
Laszlo/GCS
status.
OK, I will disable the mentioned tests in the next few days.
Regards,
Laszlo/GCS
h the
maintainers first. As several upstream releases packaging is a big
change and would be an NMU. Then he reported no success, no answer of
any kind and things stand as it is for two weeks. I do not have the
capacity now to further go with this situation.
Regards,
Laszlo/GCS
n ruby-vips. Already reported upstream and got a fix. The actual
patch is this [1]. Unfortunately it seems this package is not
maintained, at least the last upload was two years ago. Meanwhile
three upstream releases were tagged, including a somewhat big (v2.2.0)
one.
Cheers,
Laszlo/GCS
[1]
https:/
'.
> Error - Machine initialization failed.
>
> So, the vice package is unusable.
As noted by Spiro, this bug is invalid. Package documentation states
that ROM files can't be distributed due to their non-free licence. You
need to get those by yourself.
Regards,
Laszlo/GCS
On Sun, Sep 1, 2024 at 3:39 PM László Böszörményi (GCS) wrote:
> Please try the proposed package update [1]. Can you confirm that all
> Ruby parts are in place now?
Friendly ping Praveen, what's your status on this?
he NMU, I'm just going to
upload the update as is - crediting you of course.
Regards,
Laszlo/GCS
you
> tar up the the current state and make it available somewhere?
That's also there [1].
Regards,
Laszlo/GCS
[1] https://people.debian.org/~gcs/apt-src_0.25.4.tar.xz
On Sun, Sep 1, 2024 at 6:33 PM Helge Kreutzmann wrote:
> If anything is unclear, I'm happy to resolve this.
I started the update back then. Soon I got stuck, the current state
is online [1]. The pod can't be processed and in the next few days I
don't have time to look at it.
R
Hi Praveen,
Please try the proposed package update [1]. Can you confirm that all
Ruby parts are in place now?
Of course, I will remove protobuf_c.so from
/usr/lib/ruby/vendor_ruby/google/ , the other installed place should
be the official location.
Regards,
Laszlo/GCS
[1] dget -x https
ad the package, giving you all the credits of course.
Thanks,
Laszlo/GCS
pied into the source tree missing something else. This
is what SIGABRT suggests, probably some binary or library can't be
dlopen-ed as it's (those are) not copied over.
It's the tracker autopkg testing that needs fixing.
Regards,
Laszlo/GCS
[1] https://sqlite.org/releaselog/3_45_3.h
without problems. Do you experience any odd behaviour?
Regards,
Laszlo/GCS
point of this. Can you please recheck the current
graphviz package state and report back to me?
Regards,
Laszlo/GCS
eclaration' is going to be set? I'm a bit
confused, you may mix it with '-Werror=implicit-function-declaration'
which was already patched five days ago.
Can you recheck your findings and add more information?
Thanks,
Laszlo/GCS
mental as 0.43-1~exp1 over your
changes of course?
Regards,
Laszlo/GCS
r intention with keeping pyro4 in
the archives? It is no longer developed and superseded with pyro5.
Should be removed sooner than later.
Regards,
Laszlo/GCS
sr/share/doc/graphviz-tools/copyright (Thu Jan 1 00:01:00 1970)
Seems I updated my Bookworm system too soon and hit the ext4
corruption bug in the kernel as noted in #1057843. Luckily an fsck
corrected my filesystem and package update is in progress.
Regards,
Laszlo/GCS
ortant for you? Pyro4 is dead for a while. Last update was for
Python 3.10 (the archive has the default of 3.11). See upstream note
that development halted, repository is archived [1].
Regards,
Laszlo/GCS
[1]
https://github.com/irmen/Pyro4/commit/8ec0db055d76ae1512239710b1e30883ee6bd74b
r
correctly it is something uncommon. I think I will let git-cola go.
Regards,
Laszlo/GCS
I don't know why this is happening, as if I check the intermediate dot
file then only the node font settings cause this error. Other uses of
the Helvetica font are fine. As per source change, you will need this
patch for enblend-enfuse.
Please check if the resulting package works as you expec
ll a
work in progress, not fully ready for user consumption.
enblend-enfuse will still not build. Please give me some time to clear
all graphviz issues.
Regards,
Laszlo/GCS
been declared
53 |uint64_t number_total_read,
|^~~~
It seems the mentioned header moved to
/usr/include/concurrentqueue/moodycamel/concurrentqueue.h ; please
update your package.
Regards,
Laszlo/GCS
ned
patch removed Python package version.
Regards,
Laszlo/GCS
[1]
https://tracker.debian.org/news/1458326/accepted-python311-3115-3-source-into-unstable/
out!
[...]
> Fwiw, there is a new 0.18.1 upstream version. Perhaps that works
> better.
It is already packaged for experimental and has the same build
problem. Upstream knows this bug [1], assigned major priority to it
but has not touched the issue since february.
Regards,
Laszlo/GCS
[1] https://issues.apache.org/jira/browse/THRIFT-5680
idec', required by 'gnutls', not found
-- cut --
It is gnutls which needs brotli, not ntfs-3g.
3) Official gnutls28 packages don't build with brotli so it seems you
have an unofficial one or you tampered with that as well.
Regards,
Laszlo/GCS
guage binding package
version relate to the protobuf-compiler version? I don't follow the
internals of Protobuf, but I would say it's more related to the
library soname and its provided API version.
Regards,
Laszlo/GCS
subscribed to the tracker-commits.
Regards,
Laszlo/GCS
[1]
https://tracker.debian.org/news/1422194/accepted-tiff-450-5-source-into-unstable/
The first package version uploaded with it is
2.1.dfsg-1 from March, 2009.
Cheers,
Laszlo/GCS
x27;m quite surprised this was realized so late. You are probably not
the only person using Ceph. How others can use, how they upgraded
their Ceph clusters?
Regards,
Laszlo/GCS
nly tests that are detected on buildds, but
there's at least one which hangs ('Build killed with signal TERM after
150 minutes of inactivity').
Any IPv6 porterbox available?
Regards,
Laszlo/GCS
e also include the source files for the font from the
> referenced project.
Err, what do you mean source files for a font?
Regards,
Laszlo/GCS
[1] https://www.dafont.com/commodore-64-pixelized.font
cially with a non-free licence?
Regards,
Laszlo/GCS
family for hostname not
> supported)
Is there a way to detect such buildds as a maintainer? What can I do
except notifying upstream and / or disable such tests?
Cheers,
Laszlo/GCS
nds} already generates a correct dependency
> on libtiff6.
Indeed and already reported. Will fix this shortly.
Regards,
Laszlo/GCS
I have to check if a contrib package can or should depend on a
non-free one. At the moment I don't like the idea and switch back to
the previous free one instead.
Thanks for the note anyway,
Laszlo/GCS
it makes sense.:)
Do you have packaging experience? Can you do it in a day or two?
Regards,
Laszlo/GCS
** [debian/rules:126: binary-indep] Error 25
Please take care of it soon as the Bookworm freeze is approaching.
Regards,
Laszlo/GCS
p.h as the
include path when it's QuaZip-Qt6-1.3/quazip/quazip.h (i.e. one more
directory deep).
Regards,
Laszlo/GCS
[1]
https://salsa.debian.org/debichem-team/libodsstream/-/blob/master/debian/control#L11
willing to do a sourceful upload Jeremy?
Just for the record, he asked for a evolution-data-server binNMU [1]
for this issue. No sourceful upload will be needed.
Regards,
Laszlo/GCS
[1] https://bugs.debian.org/1024726
Control: tags -1 -experimental
Hi,
On Sun, Nov 13, 2022 at 10:45 AM Adrian Bunk wrote:
> Source: protobuf
> Version: 3.12.3-2
> Severity: serious
> Tags: ftbfs
Thanks for the heads-up. Package in experimental is fixed, hopefully
its transition [1] will happen soon.
Regards,
L
s2 v2.14 soon anymore.
Thanks to everyone involved,
Laszlo/GCS
ner to backport it to the Debian package
instead?
Thanks,
Laszlo/GCS
hey have
> packages we don't.)
[...]
> Happy to NMU a fix for this.
Thanks, but libwxsqlite3-3.0-dev is about to stay for a little
longer. Then a fixed package is already uploaded and waiting to be
accepted.
Thanks,
Laszlo/GCS
where the additional local subdirectory comes from.
Regards,
Laszlo/GCS
lation path, but will move back
binaries directly after installation.
Regards,
Laszlo/GCS
at tomorrow.
Regards,
Laszlo/GCS
se let me know if it
> doesn't or there is some new problem.
I'm going to upload this Mercurial snapshot and will see how it
builds and works.
Thanks,
Laszlo/GCS
et 16712:acb5f7fa99cf:
>
> "colorMapSize() method for returning the number of colormap entries
> should be a const method."
>
> Apparently this change impacts the ABI.
How do you plan to solve this problem? Seems you either revert it or
the library needs a soname bump.
Regards,
Laszlo/GCS
itecture.
> gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0:
> undefined symbol: _ZN6Magick5Image12colorMapSizeEv
Strange, I might think it's somehow related to GCC 12 changes.
Regards,
Laszlo/GCS
yself, let's speed up and I'll
upload your changes immediately.
Regards,
Laszlo/GCS
p it anymore.
> If its gone from di-i, at least no new installs can spring into
> existence "by accident", i.e. where mdraid would have been the
> better choice.
Exactly.
Regards,
Laszlo/GCS
to close this
bug report.
Laszlo/GCS
ice update which disables FFmpeg support, not
to fail with 5.y until then. I let this bug report open until the
support lands for that.
Regards,
Laszlo/GCS
Tried in several ways. Do you
have time to repeat your build process and see if it builds this time?
Thanks,
Laszlo/GCS
Control: merge 1013877 1013878
On Sun, Jun 26, 2022 at 2:18 PM László Böszörményi (GCS)
wrote:
> See the attached patch, basically it's a one liner. Sergei just needs
> to add it to the libtk-img package source.
Then it's just one bug, sorry for the duplication. As soon as Ser
entioned removed function is a one liner, being a wrapper for another
function. If libtk-img needs that function, right. Copy it to their
code like it copied others already.
See the attached patch, basically it's a one liner. Sergei just needs
to add it to the libtk-img package source.
Regards,
s details to their source tree. They already done copying with
the _TIFFsetString() function declaration.
Then I can add a break for its older versions for tiff.
Regards,
Laszlo/GCS
[1] https://gitlab.com/libtiff/libtiff/-/blob/master/libtiff/tif_dir.c#L43
sion type LZ4 is not
> linked with the binary.`
Thanks, but it's a duplicated bug report. I'm going to fix this soon.
Regards,
Laszlo/GCS
1] and _TIFFDataSize() became
a public API but with a different function signature. It's now
TIFFFieldSetGetSize(const TIFFField* fip).
It seems your upstream is dead, but try to get it fixed.
Regards,
Laszlo/GCS
[1]
https://gitlab.com/libtiff/libtiff/-/commit/11f3f279608ae9e68f014717393197f430f9be58
.0.0), [...]
Regards,
Laszlo/GCS
[1]
https://buildd.debian.org/status/fetch.php?pkg=thrift&arch=amd64&ver=0.16.0-5&stamp=1652635345&raw=0
[2]
https://buildd.debian.org/status/fetch.php?pkg=thrift&arch=mipsel&ver=0.16.0-5&stamp=1652668192&raw=0
[3]
https://buildd.debian.
load for its reverse dependencies (adopt for the new
packages).
As I don't want to delay the OpenSSL transition, I am going to fix the
building of the Sid (4.0.20) version. Then will do the 4.3.1
transition.
Regards,
Laszlo/GCS
311 | ucnv_setFallback(m_converterICU, TRUE);
> | ^~~~
> ...
My bad, submitting the required patch only now.
Regards,
Laszalo/GCS
Description: replace old ICU TRUE / FALSE constants
For some time ICU (since 68.1+ for sure) no longer specify nonstandard
TRUE / FALSE
ill close this bug report when I
upload thrift to Sid.
Regards,
Laszlo/GCS
[1] https://bugs.debian.org/1008458
[2] https://bugs.debian.org/1008823
/ It seems upb is not fully
mature and recently I can't install it with cmake. Might be the reason
gRPC started to bundle upb and build with that exact snapshot version.
Regards,
Laszlo/GCS
sel:
For a bug in src:libwebp which is filed and has an upstream fix. Diff
is at:
https://chromium.googlesource.com/webm/libwebp/+/e4cbcdd2b5ff33a64f97fe49d67fb56f915657e8%5E%21/
Hope the package maintainer will apply it soon.
Laszlo/GCS
h updates the source
accordingly.
Regards,
Laszlo/GCS
Description: fix build with SQLite3 3.38.0+
It changed the error message for creating an already existing table.
Forwarded: no
Author: Laszlo Boszormenyi (GCS)
Last-Update: 2022-03-01
---
--- emacsql-sqlite3-1.0.2.orig/emacsql-sqlite3.el
+++ e
mode so returning the profiles
> does not incur any additional cost.
Thanks for the explanation and for the fix itself.
Regards,
Laszlo/GCS
On Fri, Feb 25, 2022 at 4:35 PM Bob Friesenhahn
wrote:
> On Fri, 25 Feb 2022, László Böszörményi (GCS) wrote:
> > Wild guess only, as I'm away from home right now. But that image can
> > be exif.jpg [1] or any other from the 'fixtures' directory.
> > [1]
&g
ick?
>
> Is the specific JPEG file which caused the issue available?
Wild guess only, as I'm away from home right now. But that image can
be exif.jpg [1] or any other from the 'fixtures' directory.
Hope this helps,
Laszlo/GCS
[1]
https://salsa.debian.org/ruby-team/ruby-mini-magick/-/blob/master/spec/fixtures/exif.jpg
package the
latter for you if you want.
Will contact upstream about this and see what he finds.
Regards,
Laszlo/GCS
gt;
> I will hold of the planned expat security release until this is
> addressed.
ACK, watching this GitHub issue and will update the package accordingly.
Thanks,
Laszlo/GCS
;m going to upload Helmut's fix, thanks for that!
Regards,
Laszlo/GCS
mn type
[2].
Then golang-github-facebook-ent only checks for lowercase [3] values.
Meaning it was wrong for previous SQLite3 versions even.
The attached patch fixes this.
Hope this helps,
Laszlo/GCS
[1] https://github.com/sqlite/sqlite/blob/version-3.37.0/src/global.c#L388
[2] https://github.co
as text and returned in a case it was defined.
As I broke it, I've created a fix for you, patch is attached.
Sorry for the inconvenience,
Laszlo/GCS
Description: SQLite3 3.37.0+ use uppercase column tupe names
Starting with SQLite3 3.37.0 it stores column type names as a value and
always disp
stored as text and returned in a case it was defined.
As I broke it, I've created a fix for you, patch is attached. Couldn't
make it work with older SQLite3 versions thus you will need to build
depend on SQLite3 3.37.0 and newer.
Sorry for the inconvenience,
Laszlo/GCS
Description: SQLite3 3
e tomorrow I
can check it. But of course, any help is appreciated.
Regards,
Laszlo/GCS
the wrong version number.
Indeed, a bad typo went in finally. Thanks for catching that.
Cheers,
Laszlo/GCS
-march=armv7-a because
> armv7-a does not guarantee floating-point support, and libcrypto++
> hard-codes -march=armv7-a in its makefile:
Thanks, confirmed the problem and the fix as well on armhf in a Sid
chroot. Still need to check it on armel.
Cheers,
Laszlo/GCS
Control: severity -1 important
On Sat, Nov 13, 2021 at 9:12 AM László Böszörményi (GCS)
wrote:
> Control: tags -1 important
Right, important is a bug severity. Sorry for the noise.
probably gbp. It didn't check in the empty directory of
third_party/protobuf which otherwise exists in the source tarball.
Decreasing the severity and will investigate the possibility to fix
the Git tree and its tags to include the mentioned empty directory.
Regards,
Laszlo/GCS
at latest version I would like to
> build). If you don't have time to address this RC bug, would you allow
> an NMU to fix this, as per the debdiff at [1] ?
I will arrive home in a few hours. Going to do a normal package
update immediately.
Regards,
Laszlo/GCS
x27; into jpeglib.h after the JPEGLIB_H
definition (ie, to line twenty) that fixes this problem.
Regards,
Laszlo/GCS
ed. Going to use GCC 10 for odb soon.
Cheers,
Laszlo/GCS
1 - 100 of 446 matches
Mail list logo
