ke-dfsg while upstream will work
on a better one. Another way is to report this misbehaviour to GNU to
fix.
Which way to go first?
Regards,
Laszlo/GCS
[1] https://bugs.debian.org/963335
Control: severity -1 normal
Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: qpid-python -- RoM; deprecated upstream, no
reverse-dependencies
On Tue, Jun 9, 2020 at 8:00 PM Moritz Mühlenhoff wrote:
> On Fri, Aug 30, 2019 at 07:49:29AM +, Matthias Klose wrote:
>
Control: severity -1 normal
Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: linux-user-chroot -- RoM; deprecated upstream,
no reverse-dependencies
On Thu, Jun 25, 2020 at 1:42 PM Simon McVittie wrote:
> On Mon, 25 Jun 2018 at 13:16:20 +0100, Simon McVittie wrote:
> I don't think an
Control: tags -1 +pending
On Mon, Jun 15, 2020 at 10:18 PM Moritz Mühlenhoff wrote:
> On Thu, May 14, 2020 at 04:56:01PM -0400, Scott Talbert wrote:
> > Does it make sense to just remove the python-ecrpyptfs bindings? They don't
> > seem to have any reverse dependencies and popcon is very low.
don't think it can be reintroduced to stable, but backports would
be possible. First if you can, please test the new package revision
and report back how it works.
Regards,
Laszlo/GCS
[1] dget -x https://people.debian.org/~gcs/ecryptfs-utils_111-5.dsc
Control: tags -1 +patch
Hi,
It seems your upstream is inactive. It was me who patched sword for
ICU 63.1 and here is the patch for the ICU 67.1 version. Please apply
this soon.
Thanks,
Laszlo/GCS
Description: fix ICU checking
Let still search for icu-config but use pkg-config method after
had years for that.
Going to ask for its removal.
Regards,
Laszlo/GCS
[1] https://github.com/mhagger/cvs2svn
the issue. Hopefully
Matthias will add it to its packaging soon.
Regards,
Laszlo/GCS
[1] https://bugs.python.org/issue40784
[2]
https://github.com/python/cpython/commit/c610d970f5373b143bf5f5900d4645e6a90fb460
Control: severity -1 serious
On Fri, Dec 25, 2020 at 2:39 PM László Böszörményi (GCS)
wrote:
> Crypto++ 8.3.0 transition will happen (hopefully) soon. Your package
> fails to build with this version. Your upstream has the fix [1],
> please be prepared to apply it to the packaging.
T
n, but as it switches to CMake build system it
needs more testing.
Cheers,
Laszlo/GCS
On Mon, Dec 7, 2020 at 1:00 PM Paul Gevers wrote:
> On 07-12-2020 08:11, László Böszörményi (GCS) wrote:
> > Yeah, it's a bit confusing why someone tagged this as affecting
> > experimental.
>
> That's because you fixed this bug in experimental. So the BTS apparently
&
ld tested balboa at least twice on pbuilder with the new
rocksdb version and it was compiled correctly.
Going to look into it and fix this soon.
Regards,
Laszlo/GCS
you don't mind sending your
login information on an now unsecure channel, you can restore the
previous behaviour. You need to edit /etc/ssl/openssl.cnf and set
"CipherString = DEFAULT@SECLEVEL=2" to one instead. But then again,
it's definitely NOT recommended for your security.
Regards,
Laszlo/GCS
On Wed, Nov 11, 2020 at 9:23 PM Kurt Roeckx wrote:
> On Tue, Nov 10, 2020 at 08:54:22PM +0100, László Böszörményi (GCS) wrote:
> > Thanks for possibly the best solution. Meanwhile OpenSSL 1.1.1h-1
> > migrated to testing; closing this bug report.
>
> That is not a
> | ^~~
> > compilation terminated.
It's an overlook in src:gcc-10 as it adds the pr95842.diff patch
which contains common/config/i386/i386-cpuinfo.h and noted as a "new
file" [1][2].
Also noted that i386.h is going to include it [3][4], bu
.]
> This is a bit unfortunate that it's happening so late in the developpement
> cycle.
Indeed, my fault. Investigating. Hope this can be resolved easily.
Thanks,
Laszlo/GCS
il[846499]: fetchmail: lock creation failed,
> pidfile "/run/fetchmail/fetchmail.pid": File o directory non esistente
Thanks for the report and the proposed fix! Can you please check if
the updated package[1] is fine for you now?
Cheers,
Laszlo/GCS
[1] dget -x https://people.debian.org/~gcs/fetchmail_6.4.16-2.dsc
ory
>
> This is fixed in gcc-10 10.3 in experimental, according to doko the
> workaround is to build with g++-9 for bullseye. (#986519)
Meaning GCC 10 is still broken on amd64, its gcc-10-plugin-dev has a
regression for Bullseye over GCC 9.
But OK, not my business. Will build odb with GCC 9.
Regards,
Laszlo/GCS
to use GCC 10 for odb soon.
Cheers,
Laszlo/GCS
bug also seems to be fixed with newer protobuf/grpc versions in
> experimental).
You know, my question is, how and why it was and still working for
3.12.4 but nor for 3.17.3?
Regards,
Laszlo/GCS
after the JPEGLIB_H
definition (ie, to line twenty) that fixes this problem.
Regards,
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
eed, a bad typo went in finally. Thanks for catching that.
Cheers,
Laszlo/GCS
I
can check it. But of course, any help is appreciated.
Regards,
Laszlo/GCS
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
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.
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
ebook-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.com/sqlite/sqlite/blob/version-3.37.0
ackage the
latter for you if you want.
Will contact upstream about this and see what he finds.
Regards,
Laszlo/GCS
going to upload Helmut's fix, thanks for that!
Regards,
Laszlo/GCS
523
>
> 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
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
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]
> > https:/
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
+++ emacsql-sqlite3-1.0.2
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
> does not incur any additional cost.
Thanks for the explanation and for the fix itself.
Regards,
Laszlo/GCS
ion. :-/ 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
lose this bug report when I
upload thrift to Sid.
Regards,
Laszlo/GCS
[1] https://bugs.debian.org/1008458
[2] https://bugs.debian.org/1008823
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 displayed
this was 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.37.0+ use
thon package version.
Regards,
Laszlo/GCS
[1]
https://tracker.debian.org/news/1458326/accepted-python311-3115-3-source-into-unstable/
|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
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
s 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 expected or not and
report back you
mething uncommon. I think I will let git-cola go.
Regards,
Laszlo/GCS
t 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
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
.0.0), [...]
Regards,
Laszlo/GCS
[1]
https://buildd.debian.org/status/fetch.php?pkg=thrift=amd64=0.16.0-5=1652635345=0
[2]
https://buildd.debian.org/status/fetch.php?pkg=thrift=mipsel=0.16.0-5=1652668192=0
[3]
https://buildd.debian.org/status/fetch.php?pkg=thrift=armel=0.16.0-5=1652637646=0
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
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,
Laszlo/GCS
Description: add _TIFFse
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 Sergei
u
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
() 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
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
d in several ways. Do you
have time to repeat your build process and see if it builds this time?
Thanks,
Laszlo/GCS
to close this
bug report.
Laszlo/GCS
ies (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
.
> 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
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
> 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
morrow.
Regards,
Laszlo/GCS
the additional local subdirectory comes from.
Regards,
Laszlo/GCS
e back
binaries directly after installation.
Regards,
Laszlo/GCS
ave
> 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
an package
instead?
Thanks,
Laszlo/GCS
.14 soon anymore.
Thanks to everyone involved,
Laszlo/GCS
, let's speed up and I'll
upload your changes immediately.
Regards,
Laszlo/GCS
/rules:126: binary-indep] Error 25
Please take care of it soon as the Bookworm freeze is approaching.
Regards,
Laszlo/GCS
sense.:)
Do you have packaging experience? Can you do it in a day or two?
Regards,
Laszlo/GCS
s 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
e 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
.
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
nds} already generates a correct dependency
> on libtiff6.
Indeed and already reported. Will fix this shortly.
Regards,
Laszlo/GCS
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
ly 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
cially with a non-free licence?
Regards,
Laszlo/GCS
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
r-commits.
Regards,
Laszlo/GCS
[1]
https://tracker.debian.org/news/1422194/accepted-tiff-450-5-source-into-unstable/
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
age version uploaded with it is
2.1.dfsg-1 from March, 2009.
Cheers,
Laszlo/GCS
s 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
dds, 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
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
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
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
h keeping pyro4 in
the archives? It is no longer developed and superseded with pyro5.
Should be removed sooner than later.
Regards,
Laszlo/GCS
mental as 0.43-1~exp1 over your
changes of course?
Regards,
Laszlo/GCS
claration' 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
the point of this. Can you please recheck the current
graphviz package state and report back to me?
Regards,
Laszlo/GCS
in changelogs, see some quick examples[2][3][4].
About the SIGHUP change, you mentioned '[varacanero]', that I couldn't
parse. On the other hand, you are noted in couchdb_sighup.patch as it
was your work and I do honor it.
Regards,
Laszlo/GCS
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682172
Hi Dane,
On Fri, 2012-12-07 at 09:07 +, Dane Elwell wrote:
This bug seems to still exist in CouchDB 1.2.0-3 update that was pushed out
recently in Wheezy.
It's caused by -2 . If you install -3 from scratch or delete
/var/run/couchdb/ after -2 is stopped, it'll start normally.
Laszlo/GCS
that particular architecture,
then the effect is similar. I just put a job on buildds that it won't
even start.
In short, what's the leveldb plans for Wheezy? Will it build on all
archs?
Regards,
Laszlo/GCS
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject
are RMs say?
Regards,
Laszlo/GCS
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556573
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
there are multiple viewpoints for example about
application/x-httpd-* types. One may do more harm with a commit if not
consulted by a group of more advanced people.
But I'm fine with normal collab-maint as well if you and Charles would
like that.
Cheers,
Laszlo/GCS
signature.asc
Description
On Mon, 2012-07-16 at 23:35 +0200, Cyril Brulebois wrote:
Laszlo Boszormenyi (GCS) g...@debian.org (16/07/2012):
My intention was to limit people who can commit to mime-support. It
seems there are multiple viewpoints for example about
application/x-httpd-* types. One may do more harm
On Tue, 2012-07-17 at 09:27 +0900, Charles Plessy wrote:
how about the following (inspired by http://dep.debian.net/deps/dep2/)
Maintainer: mime-supp...@packages.debian.org
Uploaders:
Laszlo Boszormenyi (GCS) g...@debian.org,
Charles Plessy ple...@debian.org,
Hope Brian will also join
Answering to my own mail.
On Tue, 2012-07-17 at 05:38 +, Laszlo Boszormenyi (GCS) wrote:
On Tue, 2012-07-17 at 09:27 +0900, Charles Plessy wrote:
2) Install in Alioth's collab-maint a git repository made with the --debsnap
option of git-import-dscs, unless we try to go deeper in time
-updates.
Regards,
Laszlo/GCS
[1] http://www.barcikacomp.hu/gcs/python-greenlet_0.3.1-2.1.dsc
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
to 'reason, closes: #xxx' ones.
It's a bit unclear for me if it's advised or not. Can't recall any
policy about this, but AFAICR, it should not be changed. In short, may I
upload the package despite the altering of changelog wording?
Regards,
Laszlo/GCS
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ
301 - 400 of 417 matches
Mail list logo
