le.
Regards,
Laszlo/GCS
me to answer if you feel it
> necessary), provided my current mentor's review comes with no issue.
>
> Should you prefer to manage the reviewing/upload of the patch by yourself,
> please notify me, and we'll interrupt the process.
I don't have time for this today, but will handle it and do notify
you of course.
Thanks,
Laszlo/GCS
Hi,
On Mon, Jul 9, 2018 at 2:12 PM Pierre-Elliott Bécue wrote:
> Le dimanche 08 juillet 2018 à 19:35:13+0200, László Böszörményi (GCS) a écrit
> :
> > On Sun, Jul 8, 2018 at 5:51 PM Pierre-Elliott Bécue wrote:
> > > I've prepared an NMU for python-gevent (versi
On Wed, Jul 11, 2018 at 12:10 AM Pierre-Elliott Bécue wrote:
> Le 10 juillet 2018 23:54:31 GMT+02:00, "László Böszörményi (GCS)"
> a écrit :
> > I do not get your point, what's funny in that you committed even more
> >to the repository without asking. But read
n this case
the worst solution.
Then, please at least send valid URLs. The mentioned part of the
Policy lives at a different URL[1].
Thanks,
Laszlo/GCS
[1]
https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces
t; command for more info.' line?
> I am attaching here the output of the debian package version. I am available
> to
> help to solve this issue.
Thanks in advance. I'm also interested if you have a non-free display
driver installed and/or may you have a dual monitor display.
Regards,
Laszlo/GCS
RSION_NUMBER.
This is just a friendly ping if you have time for this issue or
should I use the other patch from Sebastian?
Kind regards,
Laszlo/GCS
le, which hand to bite: have an old
zeromq version maybe without security support or lose tango from
Stretch. :(
Regards,
Laszlo/GCS
[1] https://bugs.debian.org/743508
e
only notable change that if OpenSSL 1.1+ is used for compilation, I
have to print that egd is not supported by the OpenSSL version - you
protected the function only, but not its call.
Thanks,
Laszlo/GCS
Description: fix build with OpenSSL 1.1.0+
Makes compilation work with both OpenSSL 1.0 a
ppens if you try the
build say three - four times?
Thanks,
Laszlo/GCS
_x86_64/GDETEMPL.o
> CMake Error at cmake_install.cmake:763 (file):
> file INSTALL cannot find
> "/build/fis-gtm-6.3-005/obj-x86_64-linux-gnu/utf8/GDEGET.o".
This might be a different issue. Going to check it as well.
Laszlo/GCS
--- fis-gtm-6.3-005.orig/CMakeLists.txt
+++ fis-gtm-6.3
patch can build your package. Consult the gtm_dist issue with your
upstream if you want.
Laszlo/GCS
d pkg-config
to your build dependencies.
Postfix is build tested very closely. Now it builds _without_ the
NO_EAI flag and links to ICU correctly. Still can't run it (I don't
have a server nor VM), but if you may give me a test case showing it
might still not work then I will do everything to fix
onf | grep utf
> smtputf8_autodetect_classes = sendmail, verify
> smtputf8_enable = ${{$compatibility_level} < {1} ? {no} : {yes}}
> strict_smtputf8 = no
I get the same output with my local NMU in a chroot. If I understand
you correctly, then this is the correct behavior showing SMTPUTF8 is
in place.
Regards,
Laszlo/GCS
-crypto' did not solve
> it.
What do you get if you do:
$ python -c 'from Crypto.Util.randpool import RandomPool'
Did you install anything from experimental or mixed your Stretch with
some Sid packages? I use Stretch for a while, constantly updating it.
I don't experience any problem with revelation.
Regards,
Laszlo/GCS
re must
> have been an update in the meanwhile, since I used to be able to use it just
> a few days ago.
As unreproducible and asked for more information, but none given yet,
I lower the severity.
Please give me at least pointers how may I reproduce this issue.
Thanks,
Laszlo/GCS
atic library since the share one was not available.
It's used only dmraid itself, no third party programs link with it.
Regards,
Laszlo/GCS
[1] https://packages.qa.debian.org/d/dmraid/news/20091126T110215Z.html
[3]: Entering directory '/<>/tests'
> | cd .. && /bin/bash /<>/build-aux/missing automake-1.15 --gnu
> tests/Makefile
> | /<>/build-aux/missing: line 81: automake-1.15: command not
> found
Good catch, thanks! I plan to fix it a bit different way.
Cheers,
Laszlo/GCS
over the entire package
> carefully and address these on your next upload.
I've update the package to its 2.8.0 version and it's in the NEW
queue with corrected debian/copyright.
If you have time, please review it.
Thanks,
Laszlo/GCS
with priority high, so that the fixed version can reach buster
> early next week and fix the FTBFSes.
OK, I'll skip other changes and going to do a normal upload soon with
the change you proposed only.
Thanks,
Laszlo/GCS
ult with Python maintainers about this.
Thanks,
Laszlo/GCS
7;t have
to install it via pip. But if you do, according to the PyICU
maintainer can use environmental variables to help its installation.
Regards,
Laszlo/GCS
[1] https://packages.qa.debian.org/i/icu/news/20190124T064926Z.html
[2] http://site.icu-project.org/download/63
[3] https://github.com/oval
-nosyslog -b 2
Thanks in advance,
Laszlo/GCS
..rewritten version is To: r...@example.com.
> fetchmail: about to deliver with: /usr/bin/procmail -Y -d 'me'
> #*** flushed
> fetchmail: POP3> DELE 1
> fetchmail: POP3< +OK Marked to be deleted.
> Segmentation fault
Thanks! Do you get the message via procmail and / or does it get
deleted from your server?
Cheers,
Laszlo/GCS
DELE' command is received but
was not acted upon.
> I've tried to downgrade to fetchmail 6.4.0~beta4-1 (from
> snapshot.debian.org), tried to upgrade to glibc 2.28-6, tried to reboot
> with another version of Linux kernel, and the problem is still there.
Do you mean 6.4.0~beta4-1 worked right previously?
Thanks,
Laszlo/GCS
was binNMUed with the
current libsidplayfp package version.
Regards,
Laszlo/GCS
[1] https://release.debian.org/transitions/html/auto-libsidplayfp.html
s necessary if needed. Also as I know we don't
close transition bugs from changelog, but reassign it to
release.debian.org and tag it transition. What may I miss?
Thanks,
Laszlo/GCS
[1] https://packages.qa.debian.org/libs/libsidplayfp/news/20150812T213902Z.html
On Tue, Aug 18, 2015 at 10:32 AM, Julien Cristau wrote:
> On Mon, Aug 17, 2015 at 23:28:55 +0200, László Böszörményi (GCS) wrote:
>> On Mon, Aug 17, 2015 at 9:04 PM, Julien Cristau wrote:
>> > I've prepared a NMU for libsidplayfp, to deal with the libstdc++
>>
built with it. There was a confusion from one
of the users[2], but as I see, audacious-plugins is still need a
binNMU to be rebuilt with this libsidplayfp version.
Cheers,
Laszlo/GCS
[1] https://release.debian.org/transitions/html/auto-libsidplayfp.html
[2] https://bugs.debian.org/cgi-bin
change is inevitable.
Regards,
Laszlo/GCS
rrectly. On the other hand I don't think
static linking is mandatory as libdevmapper.so.* exists and is under
/lib (no need to have /usr mounted, can be used in emergency shells as
well). Can be a cmake issue? Will investigate further.
Laszlo/GCS
Control: severity -1 important
On Thu, Mar 17, 2016 at 5:14 PM, Yves-Alexis Perez wrote:
> On jeu., 2016-03-17 at 14:22 +0100, László Böszörményi (GCS) wrote:
>> But as mentioned above, I think six months
>> updates may be enough for advanced users. You get new features while
&
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
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
The first package version uploaded with it is
2.1.dfsg-1 from March, 2009.
Cheers,
Laszlo/GCS
subscribed to the tracker-commits.
Regards,
Laszlo/GCS
[1]
https://tracker.debian.org/news/1422194/accepted-tiff-450-5-source-into-unstable/
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
nds} already generates a correct dependency
> on libtiff6.
Indeed and already reported. Will fix this shortly.
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
cially with a non-free licence?
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
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
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
** [debian/rules:126: binary-indep] Error 25
Please take care of it soon as the Bookworm freeze is approaching.
Regards,
Laszlo/GCS
it makes sense.:)
Do you have packaging experience? Can you do it in a day or two?
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
ears to be 3.28.0, as best as I
can tell"[1]. Anyone can interpret this as s/he would like. :-/
Regards,
Laszlo/GCS
[1]
https://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg115515.html
o an incremental change in bison and as
such this is expected, _not_ a bug in it.
I might fix it in a day or two, until then I may disagree with the
severity - sure, it would affect binNMUs but otherwise not a problem
now.
Regards,
Laszlo/GCS
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
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
ur packages.
Cheers,
Laszlo/GCS
ton, please finish packaging in the next few days or I plan to take
over it. Benjamin, do you want to package and maintain instead?
Regards,
Laszlo/GCS
On Sun, May 3, 2020 at 10:21 PM Benjamin Barenblat wrote:
> On Sunday, May 3, 2020, at 8:16 PM +0200, László Böszörményi (GCS) wrote:
> > Benjamin, do you want to package and maintain [Abseil] instead?
Indeed, I meant packaging _Abseil_.
> I’ve been working on packaging it for
CS} -qEW -b man
+ -j 1 -qEW -b man
-c "${CMAKE_CURRENT_SOURCE_DIR}"
"${CMAKE_CURRENT_SOURCE_DIR}"
"${SPHINX_MAN_DIR}"
Regards,
Laszlo/GCS
ory: "/usr/share/zoneinfo/", e.what() = Exception
You need to add tzdata to your build dependencies, that will fix it.
Regards,
Laszlo/GCS
col-c while Sid has version 2.3.3 of that now. It
is fixed by your upstream [1], so please apply that when time permits.
Thanks,
Laszlo/GCS
[1]
https://github.com/dino/dino/commit/fbd70ceaac5ebbddfa21a580c61165bf5b861303#diff-b72423348b22dce8958ce45d7deff4fa
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
.]
> 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
; | ^~~
> > 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
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 fix. Fe
upstream version, 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 appare
nce to `dlsym'
> collect2: error: ld returned 1 exit status
Strange. Build 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
ns listed
> must be the actual versions of the packages installed when the package is
> built.
Thanks for the heads-up. Can the 'Built-Using' be auto generated?
Will check it or otherwise update the list.
Regards,
Laszlo/GCS
t 100% sure it's the same bug. At
least the ICU changeset 39671 [3] mentions only the latter ticket.
> Still think both affect icu back to 52.1, but please double check if
> I'm wrong possibly.
Still on my TODO list.
Regards,
Laszlo/GCS
[1] https://cve.mitre.org/cgi
s built with OpenSSL 1.0+ just like
syslog-ng; but recently it switched to build with OpenSSL 1.1+.
Currently syslog-ng doesn't build with the newer OpenSSL, but an
upstream patch exists[1] which needs porting.
Thanks for the report,
Laszlo/GCS
[1]
https://github.com/balabit/syslog-ng/commit/55f1b97fd699a925db1bd8ea4201432b66484a42
Thanks,
Laszlo/GCS
d the libfl-dev build dependency and
upload will happen very soon.
Regards,
Laszlo/GCS
idn't have time. Now I'm on holidays
for three days - I may need to go home sooner, but I can share the
packaging then.
Regards,
Laszlo/GCS
RROR
>>> Error: Cannot find module 'requirejs'
Package is upadted and this is fixed.
> Also consider using pkg-javascript alioth repo for this package (there
> is a repo there, but it is outdated), so we can fix these kind of issues
> faster.
Thanks, will consider it. I try to act fast, package is going to be
uploaded soon.
Regards,
Laszlo/GCS
On Fri, Dec 9, 2016 at 9:15 AM, Michał Milanowski wrote:
> It also breaks Cinnamon:
[...]
> After downgrading libmozjs-24 all is ok again. Please take a look at it.
Sorry for the trouble. I'm going to look into it as soon as I arrive
home in the afternoon.
Regards,
Laszlo/GCS
tion(s) fail and what error message may you get?
If you use a graphical system, tried logout and login again with -5 installed?
Regards,
Laszlo/GCS
compile the mozjs24 source package for
your box? There can be an incompatibility with GCC 6 as well and your
GCC 7 compilation would help.
Kind regards,
Laszlo/GCS
Hi Michael,
2016-12-11 19:29 GMT+01:00 Michael Ott :
> I found it.
> It looks like #847747
Please test it with downgrading your policykit-1 package as well.
Thanks,
Laszlo/GCS
find the way yet.
> This is causing the following FTBFS in apitrace:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/apitrace.html
Ouch. Investigating for solutions.
Cheers,
Laszlo/GCS
unknown type name 'SBGString'
> SBGString *str = sb_gstring_acquire();
> ^
I've fixed it locally, wanted to ask upstream for confirmation first,
but will upload it in the afternoon.
Regards,
Laszlo/GCS
committed by Salvatore (carnil), right?
Regards,
Laszlo/GCS
ent
in some way than the source has any known problem.
Can you reschedule the build, first on ppc64el-unicamp-01, then on
ppc64el-osuosl-01 and see the results? Maybe the former is not up to
date and has some inconsistent package set installed?
Regards,
Laszlo/GCS
vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2017-4
[1] http://seclists.org/fulldisclosure/2017/Jul/76
Regards,
Laszlo/GCS
Control: reopen -1
The fix in 4.53-2 is not enough, as the selectors34 module is needed
for the multiplexer server.
Fix is pending.
On Tue, Jan 10, 2017 at 12:37 AM, grin wrote:
> The fix is hopefully at
> https://github.com/balabit/syslog-ng/pull/1316
Bazsi asked for review at the bottom. To help testing the fix, I've
created a package with the patch[1]. Please report back if it fixes
the issue for you.
Regards,
ian Andrzej Siewior's patch? I plan to use
if no one objects.
Laszlo/GCS
this on your
> end?
Nope. Tried in a loop of ten with -j2, other ten with -j4 and another
ten with -j8 and it was working correctly. What's the result / current
problem at your end?
Laszlo/GCS
On Thu, Nov 3, 2016 at 11:16 PM, Sebastian Andrzej Siewior
wrote:
> On 2016-11-03 22:02:23 [+0100], László Böszörményi (GCS) wrote:
>> Nope. Tried in a loop of ten with -j2, other ten with -j4 and another
>> ten with -j8 and it was working correctly. What's the result / c
package:
$ dpkg -S /usr/lib/graphviz/libgvplugin_gd.so.6
libgvc6: /usr/lib/graphviz/libgvplugin_gd.so.6
What's the output of:
$ ls -l /usr/lib/graphviz/libgvplugin_gd.so*
on your system?
I'm interested why do you get segmentation fault error during apt-get.
Regards,
Laszlo/GCS
Control: severity -1 important
On Sat, Aug 5, 2017 at 3:44 PM, Adrian Bunk wrote:
> On Mon, Jul 31, 2017 at 06:12:54PM +0200, László Böszörményi (GCS) wrote:
>> But the most important thing is that the fail always happened on
>> ppc64el-unicamp-01 - the other buildd, ppc64el-osuo
ll need a stable distributed
filesystem in the future.
I'd a discussion with Dmitry and if I understood correctly, he no
longer wants to be a close contributor - but I let him speak about his
intentions.
Regards,
Laszlo/GCS
hat you want to build?
I would like to be sure there's no more headers I might have missed to
install.
Thanks,
Laszlo/GCS
way and will be uploaded once I'm at home from work.
Regards,
Laszlo/GCS
llseye) add a
break to libprotobuf10.
Regards,
Laszlo/GCS
diff -Nru protobuf-3.6.1.3/debian/control protobuf-3.6.1.3/debian/control
--- protobuf-3.6.1.3/debian/control 2018-12-09 12:45:11.0 +
+++ protobuf-3.6.1.3/debian/control 2019-04-16 22:12:03.0 +
@@ -66,6 +66,7 @@
Mult
ffec68)
at dl-init.c:119
preinit_array =
preinit_array_size =
i = 1
#14 0x77fd60ca in _dl_start_user () at /lib64/ld-linux-x86-64.so.2
#15 0x0001 in ()
#16 0x7fffee4c in ()
#17 0x in ()
Sorry for my brevity, it's almost morning here. Should rest before my
working hours. But I hope this helps something.
Regards,
Laszlo/GCS
its START_MAGICK macro. Please
apply this to your package Ole.
Thanks,
Laszlo/GCS
Description: initialize GraphicsMagick on library load
GNU Data Language library uses GraphicsMagick via static variables as well.
These get initialized and used on its library load and initialization. For
this rea
t as I consider that unwelcomed as Ole is
alive and well. But please, do a fixed upload of gnudatalanguage soon.
Thanks,
Laszlo/GCS
[1] https://bugs.debian.org/927307
[2] https://bugs.debian.org/927307#39
Hi Ole,
On Mon, Apr 22, 2019 at 3:45 PM Ole Streicher wrote:
> On 21.04.19 12:46, László Böszörményi (GCS) wrote:
> > I do _not_ want to NMU it as I consider that unwelcomed as Ole is
> > alive and well. But please, do a fixed upload of gnudatalanguage soon.
>
> Thanks for
rc/info/1e16d3e8fc60d39c
Can be, but not sure. At least four sqlite 3.x issues reported
recently and as I know, usually upstream is not informed about these.
:-/
> > [1] https://www.talosintelligence.com/vulnerability_reports/TALOS-2019-0777
Regards,
Laszlo/GCS
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
;m going to upload Helmut's fix, thanks for that!
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
package the
latter for you if you want.
Will contact upstream about this and see what he finds.
Regards,
Laszlo/GCS
1 - 100 of 448 matches
Mail list logo