), but then I didn'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
Control: severity -1 important
On Thu, Mar 17, 2016 at 5:14 PM, Yves-Alexis Perez <cor...@debian.org> 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 g
adm2 was missed. Added the libfl-dev build dependency and
upload will happen very soon.
Regards,
Laszlo/GCS
t just got some other, transient problem.
Thanks,
Laszlo/GCS
now, libmongoc-dev was 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/G
these packages. The versions 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
ble to view, I'm not 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-b
against the
> static 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
d that different
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
the 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: severity -1 important
On Sat, Aug 5, 2017 at 3:44 PM, Adrian Bunk <b...@debian.org> 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
least didn't 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
nown 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
since 26th
of July, committed by Salvatore (carnil), right?
Regards,
Laszlo/GCS
but I would leave that to you
> as maintainer to decide.
For the moment I'll stick to the current, old rules format - I plan
to use the short debhelper style for the next release.
Cheers,
Laszlo/GCS
once I'm at home from work.
Regards,
Laszlo/GCS
t;" : : : REGS_TO_SAVE);
> ^~~
[...]
> http://gcc.gnu.org/gcc-7/changes.html
> - GCC now diagnoses inline assembly that clobbers register r2. This has
> always been invalid code, and is no longer quietly tolerated.
Already seen and found this, thanks. Solution is pending.
Laszlo/GCS
er is the
one I use. Sure, it doesn't have gennmtab.c but the generated
nametab.h file. Do you need to re-generate / modify it for some
reason?
Regards,
Laszlo/GCS
[1] https://libexpat.github.io/
[2] https://sourceforge.net/projects/expat/files/
e "About VICE" 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
lution.
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
> if you agree to it.
> Since you did not raised disagreement I uploaded on behalf of the
> DPMT and commited the package to Salsa[1].
I didn't agreed either. Possibly due to that I was not online for some
days. But no problem, I see you maintain it.
Thanks,
Laszlo/GCS
and its library) and for gRPC it's Google Portable Runtime
(for C). All I can do is a simple conflict between the mentioned
packages.
Regards,
Laszlo/GCS
Regards,
Laszlo/GCS
soname change.
Regards,
Laszlo/GCS
[1]
https://buildd.debian.org/status/package.php?p=protobuf=experimental
the build tree and chroot are discarded anyway.
> I was not able to reproduce this failure with a sequential (parallel=1)
> build, but with a paralle=2 and parallel=4 build it happened frequently:
Thanks for the correct QA testing, much appreciated.
Cheers,
Laszlo/GCS
ound in the
+// COPYING file in the root directory) and Apache 2.0 License
+// (found in the LICENSE.Apache file in the root directory).
-- cut --
That is, the compiled binaries are the same. As it's a RocksDB tool,
please remove it from MariaDB and depend on the rocksdb-tools where
you need it.
Thanks,
Laszlo/GCS
ing 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
cessary), 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 (versioned
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 on.
&
re command line in debian/rules will be sufficient to fix
> this, so no need for an ugly Build-Conflicts.
Thanks for your proper QAs.
By the way, aren't you a DD with a debian.org email address?
Regards,
Laszlo/GCS
licy.
> Is the SOVERSION 6 => 1 change really a wise idea?
> What happens after the next 5 SOVERSION bumps?
That would take years as the last SONAME bump was two years ago as
upstream tries to be API / ABI compatible between releases. But the
next upstream SONAME expected to be 7 anyway.
Regards,
Laszlo/GCS
et filed for the package updates for Jessie and Stretch as
I got confused: any of you want to review my patches first? Both
package update is ready and quick tested by the way.
Regards,
Laszlo/GCS
ithub.com/apache/thrift/commit/2007783e874d524a46b818598a45078448ecc53e
I don't really consider this as a fix, it disables the
format_go_output function instead of input sanitizing. :-(
Thanks anyway,
Laszlo/GCS
Control: severity 901015 normal
Control: severity 908854 serious
My bad, mixed bug numbers. Sorry for the noise.
On Fri, Oct 12, 2018 at 8:39 AM László Böszörményi (GCS)
wrote:
> Hi,
>
> The package ProtoBuf 3.6.1 is uploaded to Sid, effectively starting
> its transition. As
r, can you help
> fixing this?
I'll also check these, but help might be needed. My Java knowledge is
very rusty.
Regards,
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
t tomorrow after work.
Regards,
Laszlo/GCS
[1] https://www.sqlite.org/src/info/f44bc7a8b3fac82a
maintainers about this.
Thanks,
Laszlo/GCS
be achieved in this week.
Maybe a complete rewrite would be better then on the long run.
Cheers,
Laszlo/GCS
be fixed soon? I will remove this patch
on Monday in the afternoon as the release of Buster is getting close.
Regards,
Laszlo/GCS
for buster? This
> would be the only diff/change required.
You don't have to. Everything have been taken care of. It's going to
migrate to Buster tomorrow (ie, unblock is already in place).
Regards,
Laszlo/GCS
ore. I've realized it's rhapsodical,
sometimes all my CPU cores utilized on 100%, sometimes one on ~15%.
Should I wait for other fix(es)?
Thanks,
Laszlo/GCS
ldd and they could fix
it.
> Furthermore, this bug is RC, so may we close it now ?
It's up to you, after Adrian was aggressive about it I let it go. It
has no effect on the package (no migration problem or autoremoval).
Regards,
Laszlo/GCS
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870267#10
patch can build your package. Consult the gtm_dist issue with your
upstream if you want.
Laszlo/GCS
-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 it.
Regards,
L
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
ritten 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
ELE' 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
86_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-005/
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/ovalhub/pyicu/issues/92
[4] https://pac
ity 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
slog -b 2
Thanks in advance,
Laszlo/GCS
reak 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 @@
Multi-Arch: same
S
-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
s 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
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
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
it's due to 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
sider 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.
>
> Thank
2 support / use.
I'm working on it. A day or two and it will be uploaded.
Regards,
Laszlo/GCS
eue. That is, can I do a source only upload or do it
via experimental with a binary upload (otherwise it will not migrate
to testing due to not built on buildd). Please advise.
Thanks,
Laszlo/GCS
Usertags: qt4-removal
> >
> valkyrie is dead upstream for several years and won't get ported for Qt4,
> shall we remove it?
s/Qt4/Qt5/ but you are right. It's just a dead weight, will file for
its removal soon.
Laszlo/GCS
ke this one don't need to be fixed in both places?
For the time I will fix it independently. I can't promise when the
actual transition will take place.
But if you can, please check the proposed package update[1].
Thanks,
Laszlo/GCS
[1] dget -x http://www.barcikacomp.hu/gcs/fuse_2.9.9-2.dsc
and do a
binNMU on buildds.
But I've done it via experimental and just uploaded to Sid.
Regards,
Laszlo/GCS
e. At least it states:
E: thrift source: license-problem-php-license debian/copyright
Investigating how to resolve this. :-/
Cheers,
Laszlo/GCS
ted with
'pbuilder create' and I do have the fuse device in the chroot.
As noted above, if the fuse device is not there, the udevadm is not
run due to the check for that being false. One thing came into my mind
is that you have the chroot on a mount point that has the nodev
option. Can you check that please?
Regards,
Laszlo/GCS
lace when you did an NMU for a bug
which is _not_ RC without pinging the maintainer first and give some
hours to respond. But let me ask, is it a practice of yours to follow
to do a random NMU without any communication first? Especially that
you don't follow your own packages in the first place.
Laszlo/GCS
.4/orc/orctarget.h:28:
> multiple definition of `OrcTargetPowerPCFlags';
> resample/.libs/libresample.a(reducev.o):/usr/include/orc-0.4/orc/orctarget.h:28:
> first defined here
> collect2: error: ld returned 1 exit status
This is known, reported and fixing it depends on the orc maintainers.
Regards,
Laszlo/GCS
appen during the first build, since the tree is unconfigured and
> 'make distclean' does not get called.)
Please point me where's in the policy that a package must be
buildable several times from the same source tree and that
experimental is a supported branch (target for filing RC bugs).
Thanks,
Laszlo/GCS
sqlite3/3.4.1%7Edfsg-4/debian/control/#L46
Just to be exact sure. All you need is
s/libwxgtk3.0-dev/libwxgtk3.0-gtk3-dev/ right? I can do that with a
MU.
Cheers,
Laszlo/GCS
e upstream release can be a month away. Should I upload a Fossil
snapshot of that to experimental immediately?
In short, I don't get the importance of filing a FTBFS bug for a beta
release in experimental.
Regards,
Laszlo/GCS
te3 package to experimental if that helps for now.
Regards,
Laszlo/GCS
n archives since the fifth of October, this may narrow
down the issue a bit.
Regards,
Laszlo/GCS
[1] http://snapshot.debian.org/package/sqlite3/
/botan/2.12.1-2/src/lib/prov/pkcs11/pkcs11.h/
It's up to Jack, who develops Botan. I'm still not sure this text
snippet makes the code non-modifiable. But let me ask our FTP Masters
and Jack himself how to interpret it.
Thanks,
Laszlo/GCS
On Mon, Mar 2, 2020 at 7:54 PM Sean Whitton wrote:
> On Mon 02 Mar 2020 at 06:39PM +01, László Böszörményi (GCS) wrote:
> > On Mon, Mar 2, 2020 at 10:27 AM Alvin Chen wrote:
> >> https://sources.debian.org/src/botan/2.12.1-2/src/lib/prov/pkcs11/pkcs11.h/
> > It's up to
/bin/firefox
Without debug symbols it doesn't help. But just for the record, it
would be the following:
Thread 18 "Cookie" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe5cff700 (LWP 59805)]
(anonymous namespace)::DatabasePathFromWALPath
(zWALName=0x7fffeb8603a0
"
r: Package requirements (gmodule-2.0 gthread-2.0 gtk+-2.0 >=
> > 2.4.9 libxml-2.0 vips >= 7.30) were not met
> >
> > Package 'imagequant', required by 'vips', not found
As noted, it's a missing dev dependency on libvips-dev thus
reassigning and will be fixed soon.
Thanks,
Laszlo/GCS
On Sun, Dec 29, 2019 at 10:07 PM László Böszörményi (GCS)
wrote:
> On Sun, Dec 29, 2019 at 5:57 PM Chris Lamb wrote:
> > I don't fully understand the ramifications or risks of uploading the
> > current Fossil tree I'm afraid so I will have to leave that judgement
> > to you
an't test it. :-/
As I read, I should do the packaging nevertheless or Chris, may you solve
it with disabled tests?
Regards,
Laszlo/GCS
[1] https://blade.tencent.com/magellan2/index_en.html
[2] https://sqlite.org/draft/releaselog/3_31_0.html
or in upstream issues.
Regards,
Laszlo/GCS
ryptoki
version numbers are the same as well [4][5]. Some typedefs definied an
other way, see CK_BYTE and CK_CHAR for example [6][7]: OASIS define
the former as 'unsigned char' and the latter as the same as the former
- while p11-kit defines these individually to 'unsigned char'. Please
note that _s
On Sat, Apr 11, 2020 at 2:12 AM Sandro Tosi wrote:
> I've prepared an NMU for python-gevent (versioned as 1.4.0-1.2). The diff
> is attached to this message.
You know, I still don't get why immediate NMU was necessary. Why
don't give some time to the maintainer to respond.
> Please consider
you might backported protobuf incorrectly or simply
don't use that for the backported grpc package - needs checking of
course.
I say a third party project should be packaged independently and I
might do it if you really need it, but no intention to ship that from
gRPC itself. Correct me if
;, it's a clear derivation of the
OASIS one. It's even noted that "This file is a modified
implementation of the PKCS #11 standard by OASIS group". That means if
the OASIS implementation is non-free, then I don't see how it's
re-licensed (where the permission given for that) to be free softwa
ckages.
Cheers,
Laszlo/GCS
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
qEW -b man
+ -j 1 -qEW -b man
-c "${CMAKE_CURRENT_SOURCE_DIR}"
"${CMAKE_CURRENT_SOURCE_DIR}"
"${SPHINX_MAN_DIR}"
Regards,
Laszlo/GCS
;/usr/share/zoneinfo/", e.what() = Exception
You need to add tzdata to your build dependencies, that will fix it.
Regards,
Laszlo/GCS
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
kage unbuildable atm:
Indeed. Please look into the protobuf transition I filed if that's
allowed or not this time.
Cheers,
Laszlo/GCS
Hi Thomas,
On Wed, Sep 9, 2020 at 8:42 AM Thomas Goirand wrote:
> On 9/8/20 5:20 PM, László Böszörményi (GCS) wrote:
> > I even suspect the real bug is in GitLab itself, it
> > may not (correctly) handle the new gRPC version.
>
> If so, can we lower the severity of the bu
e best to drop Ruby support from
src:grpc and let Pirate maintain that from a separate source tree.
Cheers,
Laszlo/GCS
xed package if that works.
Regards,
Laszlo/GCS
r less proprietary,
> paxctld doesn't seem useful in Debian.
Ansgar is right. This package is a tool for GRSec kernel patches that
no longer open source. Hence I don't see the reason to maintain and
keep it in the archives.
Thanks,
Laszlo/GCS
ms using the Closure tools, we recommend they use the new
> | linter based on the Closure Compiler instead.
>
> Given that closure-compiler is already packaged, let's simply remove
> closure-linter?
You are right as always. Reassigning this as a removal bug as no
reason to keep this package around.
Thanks,
Laszlo/GCS
for the time being.
Regards,
Laszlo/GCS
[1] https://ftp-master.debian.org/new/abseil_0~20200225.2-1.html
[2] https://ftp-master.debian.org/new/grpc_1.29.1-1.html
of debian/rules ought to do the trick.
I did local builds for i386 and amd64 to test if the generated
changelog - those were same. But it seems some buildds may use
somewhat different locale setting. Strange.
Thanks for the help,
Laszlo/GCS
201 - 300 of 417 matches
Mail list logo
