Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

the QuantumDepth change[1], but the C library package name change is strongly advised. Will do it today with appending q16 to the library name (as seen with imagemagick which also done the QuantumDepth=16 change) if there's no objections. Cheers, Laszlo/GCS [1] https://release.debian.org/transitions/html/auto-graphicsmagick.html

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

't create this then why should I be such pedantic. >> - dh_shlibdeps -a -L libgraphicsmagick3 \ >> - -l debian/libgraphicsmagick3/usr/lib >> + dh_shlibdeps -a -L libgraphicsmagick-q16-3 \ >> + -l debian/libgraphicsmagick-q16-3/usr/lib > > These days -l and -L shouldn't be needed. OK. Thanks! Will act when I get back home. Laszlo/GCS

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

On Tue, Sep 22, 2015 at 7:17 PM, Jakub Wilk <jw...@debian.org> wrote: > * László Böszörményi (GCS) <g...@debian.org>, 2015-09-22, 08:25: >> >> [2] dget -x http://www.barcikacomp.hu/gcs/graphicsmagick_1.3.21-4.dsc > > You changed the package name, but not the SONAM

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

would like and then load the library that provides the specified QD to process the images. Regards, Laszlo/GCS

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

providing multiple libraries later. It was just a question for future upstream releases. Life is easier - my slowness is due to IRL things, just got back home recently and need to get up early in the morning. But working on the fix / update and going to upload it soon. Laszlo/GCS

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

On Mon, Sep 21, 2015 at 9:22 AM, László Böszörményi (GCS) <g...@debian.org> wrote: > Correct. It seems all dependencies could be built with the > QuantumDepth change[1], but the C library package name change is > strongly advised. Will do it today with appending q16 to the library

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

On Tue, Sep 22, 2015 at 8:10 PM, Julien Cristau <jcris...@debian.org> wrote: > On Tue, Sep 22, 2015 at 19:40:42 +0200, László Böszörményi (GCS) wrote: >> Yes, I know that. Still the packages can be tracked during a >> transition via the package name if those were compiled a

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

. It was a bit harsh, but no problem. I guess we all have enough things to do. The updated package is now in NEW, hopefully will be accepted to the archives soon. Kind regards, Laszlo/GCS

Bug#825800: graphicsmagick: CVE-2016-5118 on jessie

lready updated; so it is supported. Regards, Laszlo/GCS [1] https://packages.qa.debian.org/g/graphicsmagick/news/20160530T232158Z.html

Bug#821676: graphviz: Disable PHP bindings

disable the PHP5 bindings in the afternoon. Thanks for the heads-up, Laszlo/GCS [1] http://www.graphviz.org/mantisbt/view.php?id=2584 [2] https://github.com/swig/swig/issues/571

Bug#813247: python*-greenlet*: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

' --tmpdir /mnt/1/piuparts --arch amd64 -b [PATH]/jessie-amd64-base.tgz -d stable -d sid --apt python-greenlet-dbg=0.4.9-2 It fails that can't find 0.4.9-2 version of python-greenlet-dbg. May you check the proposed package update[1]? Thanks in advance, Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/python-greenlet_0.4.10-1.dsc

Bug#813756: libsodium: FTBFS on non-x86: missing crypto_aead_aes256gcm_*

On Fri, Feb 5, 2016 at 1:17 AM, Aaron M. Ucko wrote: > Source: libsodium > Version: 1.0.8-3 > Severity: serious > Justification: fails to build from source > > Builds of libsodium for non-x86 architectures all failed due to missing > nearly all crypto_aead_aes256gcm_* symbols

Bug#813756: libsodium: FTBFS on non-x86: missing crypto_aead_aes256gcm_*

On Fri, Feb 5, 2016 at 1:44 AM, Aaron M. Ucko <u...@debian.org> wrote: > "László Böszörményi (GCS)" <g...@debian.org> writes: >> Strange, because -2 was built correctly on all arch for experimental. > > Huh. Do you know what may be the difference betw

Bug#813756: libsodium: FTBFS on non-x86: missing crypto_aead_aes256gcm_*

On Fri, Feb 5, 2016 at 2:05 AM, Aaron M. Ucko <u...@debian.org> wrote: > "László Böszörményi (GCS)" <g...@debian.org> writes: >> I should buy buy an ARM based board at least for local testing. I've a >> qemu based build root but on my old machine it's

Bug#812935: openjdk-7-jdk: Missing openjdk-7_7u95-2.6.4-1 build on amd64 for Debian unstable

it. I send a Cc to the buildd admins who may check what's the further status. Admins: please close this bug when the package is accepted to the pool. Thanks for your mail, Laszlo/GCS

Bug#815736: graphicsmagick: FTBFS: debian/rules:138: recipe for target 'check-stamp' failed

that have ghostscript as build dependency. Anyway, uploading the updated graphicsmagick package soon. Thanks for the heads-up, Laszlo/GCS

Bug#811433: Not a fix, but a workaround

Uploading my version with other fixes and changes. Laszlo/GCS

Bug#797961: How to proceed?

the problem is not even with ecryptfs-utils but > rather with cryptsetup. I'm busy with other things, but I do hope that I can reproduce this next week or so. Then I can do tests and debugging. Cheers, Laszlo/GCS

Bug#815494: zeromq3: FTBFS, with test suite errors

ave some restriction that make tests fail, to be aborted to be exact. I've already disabled some, but then other ones failed. At the moment I have a plan to run those, but make the fails non fatal. Then upstream may know something about the reason. Cheers, Laszlo/GCS

Bug#817274: python-gevent: FTBFS: can't read debian/python-gevent-doc/...

upload is pending. While not a real issue, but is there any reason why you fire bugreports immediately? Cheers, Laszlo/GCS

Bug#817274: python-gevent: FTBFS: can't read debian/python-gevent-doc/...

On Thu, Mar 10, 2016 at 4:47 AM, Aaron M. Ucko <u...@debian.org> wrote: > "László Böszörményi (GCS)" <g...@debian.org> writes: >> Then I have to update the changelog closing the bugreport and rebuild >> the package. :) > > I do see how that could get

Bug#818187: zeromq3 migrated without any transition being done

r reports says that 'pip install pyzmq --install-option="--zmq=/usr/lib"' forces the linking. I don't know how pass it to setup.py (not using pip directly) and the path should be multiarch aware for us. Hope this helps, Laszlo/GCS [1] https://github.com/zeromq/pyzmq/issues/391 [2] https://

Bug#818318: git: CVE-2016-2324 and CVE-2016-2315 (currently unpublished) server and client RCE, fixed in 2.7.1

ixed in Stretch and Sid[2] with the 2.7.0 version. Laszlo/GCS [1] https://github.com/git/git/commit/13e0b0d3dc76353632dcb0bc63cdf03426154317 [2] https://security-tracker.debian.org/tracker/CVE-2016-2315

Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

On Tue, Mar 15, 2016 at 11:24 PM, Julian Taylor <jtaylor.deb...@googlemail.com> wrote: > On 15.03.2016 22:48, László Böszörményi (GCS) wrote: >> This is known to pyzmq upstream[1] for about three years. It happens >> on Ubuntu, Red Hat, CentOS and with ZeroMQ 4.0.x as well.

Bug#725629: vice: sometimes FTBFS: error while opening "src/arch/win32/res.rc.po.c" for reading: No such file or directory

, forcing the sequence it should be built. Regards, Laszlo/GCS

Bug#818187: zeromq3 migrated without any transition being done

On Mon, Mar 14, 2016 at 8:13 PM, Matthias Klose <d...@debian.org> wrote: > On 14.03.2016 20:04, László Böszörményi (GCS) wrote: >> I've noted all depending package maintainers back then. Yes, didn't >> prevent the testing migration of zeromq3. But some maintainers did the &g

Bug#818187: zeromq3 migrated without any transition being done

e added for the packages that changed, since their > build-deps are not versioned. After libzmq5-dev is decrufted, they will be > fine. > > Then the transition can complete. > > How does that sound? I see and agree. Attached the next upload just to be sure. Please ACK it and I'll

Bug#818187: zeromq3 migrated without any transition being done

gs against packages that not transitioned yet. Does it still stand? Regards, Laszlo/GCS

Bug#818222: libzeromq-perl: uses old libzmq1, should switch to libzmq5

from libzmq-dev to libzmq5-dev is not enough > it seems: [...] This is expected. Please note that zeromq is 2.x, while zeromq3 went through 3.x -> 4.0.x -> 4.1.x evolution. Please ask your upstream to port the code to the latest (4.1) zeromq version. Regards, Laszlo/GCS

Bug#817274: python-gevent: FTBFS: can't read debian/python-gevent-doc/...

On Wed, Mar 9, 2016 at 11:30 PM, Aaron M. Ucko <u...@debian.org> wrote: > "László Böszörményi (GCS)" <g...@debian.org> writes: > I prefer to follow this whole procedure fairly frequently so that I > don't have too many reports to file at any one time. OK, it just

Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

Hi Julian, On Sun, Mar 20, 2016 at 12:27 PM, Julian Taylor <jtaylor.deb...@googlemail.com> wrote: > On 20.03.2016 11:11, László Böszörményi (GCS) wrote: >> Sorry, my life was chaotic. Yes and no, checked it. First, there's a >> new upstream version of pyzmq (15.2) for

Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure

Control: forwarded -1 http://sqlite.1065341.n5.nabble.com/sqlite3-column-decltype-change-td88530.html On Wed, Apr 6, 2016 at 8:46 AM, Niko Tyni <nt...@debian.org> wrote: > On Wed, Apr 06, 2016 at 08:36:51AM +0200, László Böszörményi (GCS) wrote: >> I still don't know, but will

Bug#819787: libdbix-class-schema-loader-perl: FTBFS: t/10_01sqlite_common.t failure

inion of the main SQLite3 developer[1]: "This could easily be considered a bug fix rather than a regression." There are examples in his mail which demonstrate why a type of view is unambiguous and should not be depend on. Hence they chose to return an empty string for these queries

Bug#820225: libsqlite3-0: Segmentation fault (core dumped)

libsqlite3.so.0 #4 0x7f5fd7642714 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 #5 0x7f5fd7669b5b in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 Do you have libsqlite3-0-dbg installed? Regards, Laszlo/GCS

Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure

t upstream says about this. I've reported this issue[1], but the mailing list is private (online bug reporting is not possible). :( All I know they've read it. Laszlo/GCS [1] http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/2016-April/065842.html

Bug#725629: vice: sometimes FTBFS: error while opening "src/arch/win32/res.rc.po.c" for reading: No such file or directory

to push things (especially the libpng1.6 transition) forward, I > will NMU if successful. If possible, please send a patch instead. I can do a normal upload fast. Cheers, Laszlo/GCS

Bug#725629: vice: sometimes FTBFS: error while opening "src/arch/win32/res.rc.po.c" for reading: No such file or directory

On Wed, Apr 13, 2016 at 11:32 AM, Tobias Frost <t...@frost.de> wrote: > Am 13. April 2016 10:33:28 MESZ, schrieb "László Böszörményi (GCS)" > <g...@debian.org>: >> On Wed, Apr 13, 2016 at 9:39 AM, Tobias Frost <t...@debian.org> wrote: >>> As

Bug#819787: libdbix-class-schema-loader-perl: FTBFS: t/10_01sqlite_common.t failure

me after today's upload of sqlite3 3.12.1-1. Confirmed, compiles normally on amd64. You can close this bug as you are the package maintainer. Laszlo/GCS

Bug#725629: vice: racy build

On Sun, Apr 10, 2016 at 8:51 AM, Tobias Frost <t...@debian.org> wrote: > Happened again :( ... and again. Strange that it happens mostly on kFreeBSD, on Hurd from time to time, but rarely on other architectures. Laszlo/GCS

Bug#725629: vice: racy build

randomly even if it's rare. May you have information on the kFreeBSD-386 buildd? CPU and memory, but its average load may be enough alone. Laszlo/GCS

Bug#725629: vice: racy build

more suspect a filesystem time resolution problem. Maybe even a bug > in make itself. > IIRC the file systems used by kfreebsd and hurd only have second resolution, > while (most) Linux filesystems have (up to) nanosecond resolution. That would explain why the breakage happens way too often on Hurd and kFreeBSD machines. Thanks, Laszlo/GCS

Bug#804297: graphviz: dot on mipsel fails with emit.c:3873: bezier_bb: Assertion `bz.size > 0' failed

l do it in the afternoon. Thanks for the tip, Laszlo/GCS

Bug#819787: libdbix-class-schema-loader-perl: FTBFS: t/10_01sqlite_common.t failure

s): zType = columnType() and if( zType... ). Then if the check succeeds, the type gets used: memcpy(>zName[n+1], zType,...) (copying the type) pCol->colFlags |= COLFLAG_HASTYPE; (flagging that it has a known type) But I don't know the SQLite3 source, just read what it seems to be. Laszlo/GCS [1] http://article.gmane.org/gmane.comp.db.sqlite.general/100898

Bug#725629: vice: racy build

e/cpufunc.h) +AC_CHECK_HEADERS(unistd.h sys/io.h machine/pio.h) +case "$host_os" in + *kfreebsd*) +;; + *) +AC_CHECK_HEADERS(machine/cpufunc.h) +;; +esac -- cut -- Still seems to be the correct way for me. Regards, Laszlo/GCS

Bug#725629: vice: racy build

> > snippet: > > /usr/include/i386-kfreebsd-gnu/machine/cpufunc.h:42:2: error: #error > "This header must not be used in combination with ." > #error "This header must not be used in combination with ." > ^ Easy to test; what happens if you compile the vanilla package without Andreas' patch? Laszlo/GCS

Bug#810349: linux-patch-grsecurity2: removal of linux-patch-grsecurity2?

f at > one point, unless you really want to keep it and have it updated. Sure, I've failed big to keep it up-to-date. But I would like to keep this fresh in the archive. Hope upstream will release testing kernels every now and then. Regards, Laszlo/GCS

Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

ylor.deb...@googlemail.com> wrote: >> > On 15.03.2016 22:48, László Böszörményi (GCS) wrote: >> While I was checking the failing build logs, I see: >> build/temp.linux-armv7l-2.7/scratch/tmp/timer_createOfMQXG.o: In >> function `main': >> timer_createOfMQXG.c:(.tex

Bug#818187: zeromq3 migrated without any transition being done

s the right >> thing. > > Yes that'd be fine, but there's no rush. I still would be happier with libzmq5-dev to keep it consistent with the library name. Sure, once zeromq is removed, it can be libzmq-dev - I do not see a reason to switch back to libzmq3-dev meanwhile. Cheers, Laszlo/GCS

Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

On Sun, Mar 20, 2016 at 12:27 PM, Julian Taylor <jtaylor.deb...@googlemail.com> wrote: > On 20.03.2016 11:11, László Böszörményi (GCS) wrote: >> On Sun, Mar 20, 2016 at 10:56 AM, Emilio Pozuelo Monfort >> <po...@debian.org> wrote: >>> Got a chance to look at

Bug#810349: linux-patch-grsecurity2: removal of linux-patch-grsecurity2?

On Thu, Mar 17, 2016 at 1:43 PM, Yves-Alexis Perez <cor...@debian.org> wrote: > On jeu., 2016-03-17 at 10:20 +0100, László Böszörményi (GCS) wrote: >> It seems linux-grsec will remain i386 and amd64 only. > > There's no reason to, actually. It's just that right now I don't

Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure

On Sat, Apr 2, 2016 at 11:40 AM, Niko Tyni <nt...@debian.org> wrote: > On Sat, Apr 02, 2016 at 11:20:02AM +0200, László Böszörményi (GCS) wrote: >> I think libdatabase-dumptruck-perl upstream should be noted about this >> issue. May check it locally, but please don't take my w

Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure

"Not a Compatibility Break" / "The only thing that is changing is some default settings. This should result in a performance increase for many applications.". I think libdatabase-dumptruck-perl upstream should be noted about this issue. May check it locally, but please don't take my word on it. Regards, Laszlo/GCS [1] http://sqlite.org/pgszchng2016.html

Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure

ainer, but will ask upstream. The only change I've found states[1]: "The sqlite3_column_decltype() routine should return NULL, not an empty string, if the column has no declared type." Thanks for the test cases, Laszlo/GCS [1] http://www.sqlite.org/src/info/605eba4a756e7185

Bug#822866: new vips lets nip2 fail to build

e VIPS 8.3.1 with bugfixes in the next few days. I'll update the dependencies with that upload. Regards, Laszlo/GCS

Bug#821079: syslog-ng json-c transition

() with json_tokener_errors[] if the json-c library is an old version (#ifndef JSON_C_VERSION). As this helps backporting, I don't see a reason to remove this piece of code. Regards, Laszlo/GCS [1] https://sources.debian.net/src/syslog-ng/3.5.6-2.1/modules/json/jsonparser.c/#L168

Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure

est with the just uploaded sqlite3 3.12.2-1 package version. Works now on my box, but waiting for your confirmation. Regards, Laszlo/GCS

Bug#823702: Should qpid-cpp be removed?

otally outdated. Agreed. > Please reassign this to ftp.debian.org for removal or update the package. Already working on the update, but I need time with it. A week, maybe more. :( The new version contains new binary packages while removed others. Thanks for the heads-up, Laszlo/GCS

Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file

or long time, I know as others should know: - don't run sensitive services on a machine which can be accessed by untrusted users, - even on your regular box set your $HOME to 0700 and your umask to 0077. In short, always expect the worst case and be prepared. Regards, Laszlo/GCS

Bug#811606: FTBFS with GCC 6: multiple errors

to Martin F. Krafft and Jeffrey Walton for hardware donations, Wouter Verhelst and Gustavo Panizzo for installer related helping. I owe you guys! While my hardware problems don't end here, it's highly softened. Thanks, Laszlo/GCS diff -Nur mongodb-2.6.11/debian/changelog mongodb-2.6.12/debian/changelog -

Bug#831677: [Syslog-ng-maintainers] Bug#831677: syslog-ng: breaks reverse-dependencies

enter the NEW queue, it needs some days to be accepted. But then everything will be back to normal. Thanks for your report, Laszlo/GCS

Bug#825800: graphicsmagick: CVE-2016-5118

y the first set of patches, release it as a DSA, then add the others, a new DSA... But it's also not the best idea. I include the Security Team to this discussion, what they say about this. Regards, Laszlo/GCS

Bug#812041: thrift-compiler: diff for NMU version 0.9.1-2.1

ould be interested in collaborating on an update to a newer > version of the thrift compiler. Please let me know if you are amenable > to that. Did you try the experimental package version from 'thrift' source? It has a self-test issue on several architectures, but otherwise should be fine and up-to-date. Cheers, Laszlo/GCS

Bug#827806: pyevolve: FTBFS: Program terminated with status: 1. stderr follows: Format: "jpeg" not recognized

On Sun, Jul 3, 2016 at 10:52 AM, Christian Kastner <c...@debian.org> wrote: > On 2016-07-03 09:26, László Böszörményi (GCS) wrote: >> Was it part of the 'Format' output? Do you still see advertised jpeg >> support via 'loadimage' when you issue 'dot -v notexist'? > &g

Bug#827806: pyevolve: FTBFS: Program terminated with status: 1. stderr follows: Format: "jpeg" not recognized

ted to the Jasper (JPEG2000 support) removal[1]? Cheers, Laszlo/GCS [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=jasper-rm;users=j...@debian.org

Bug#827806: pyevolve: FTBFS: Program terminated with status: 1. stderr follows: Format: "jpeg" not recognized

On Sun, Jul 3, 2016 at 1:46 PM, Christian Kastner <c...@debian.org> wrote: > On 2016-07-03 12:30, László Böszörményi (GCS) wrote: >> In that clean chroot, may you rebuild -13 from source? Then install >> it still in that chroot and see the output of 'dot'. > > You wer

Bug#852245: reopen pyro4 bug "selectors34 module is not available"

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.

Bug#850743: [Syslog-ng-maintainers] Bug#850743: patch

ssue for you. Regards, Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/syslog-ng_3.8.1-10.dsc

Bug#855455: revelation: ImportError: No module named randpool (python-crypto)

'sudo dpkg-reconfigure python-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

Bug#855455: revelation: ImportError: No module named randpool (python-crypto)

am now unable to run revelation. There 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

Bug#782005: ovirt-guest-agent spu

Hi, On Wed, Jul 13, 2016 at 4:03 PM, Alexis HAUSER <alexis.hau...@telecom-bretagne.eu> wrote: > Is it possible for you to add the fixes for the 2 bugs mentioned on #811481 > in stable-proposed-updates ? May you have time to check if the proposed update[1] work for you? Thanks, L

Bug#782005: ovirt-guest-agent spu

On Wed, Aug 24, 2016 at 12:56 PM, Milan Zamazal <mzama...@redhat.com> wrote: > "László Böszörményi (GCS)" <g...@debian.org> writes: >> Please use the following: dget -x >> http://www.barcikacomp.hu/gcs/ovirt-guest-agent_1.0.10.2.dfsg-2+deb8u1.dsc [...

Bug#835983:

or some reason you are the sole maintainer. > If you need an NMU to help you, let me know. I'm going to upload a new package revision soon. Regards, Laszlo/GCS [1] https://packages.qa.debian.org/p/pypdf2/news/20141010T113501Z.html [2] http://pybrary.net/pyPdf/ [3] https://github.com/mfenniak/pyPdf/co

Bug#796298: tcplay: FTBFS: CMake Error at CMakeLists.txt:30 (message): Could not find the devmapper library

N} > ${CFLAGS_VER}") > > it indeed compiles for me. Indeed, this fixes the current issue. > Can you please take care of an according fixed package upload? Sure, it's in its way. Thanks for the heads-up, Laszlo/GCS

Bug#837719: graphicsmagick: FTBFS on ppc64el: PerlMagick test failures

.3.24 builds fine in the same environment. As previously noted the broken change happened before 08th of August and it's not the MAGICK_CACHE_LINE_SIZE value. Cheers, Laszlo/GCS

Bug#837719: graphicsmagick: FTBFS on ppc64el: PerlMagick test failures

witch to GCC 6. Definitely not. A code change in GraphicsMagick triggers it. I could tighten it down, but don't know the exact cause yet. Regards, Laszlo/GCS

Bug#837280: Dependency problem

9.6 version - it's finished yesterday and all packages are 9.6 now. This means libdbi-drivers builds fine again. Closing this bugreport, Laszlo/GCS

Bug#839454: [Syslog-ng-maintainers] Bug#839454: syslog-ng-incubator: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2

and it was built on several architectures including amd64. It seems the FTBFS was a transient one or may you give me more information about your setup, etc? Regards, Laszlo/GCS

Bug#839418: libdbi-drivers: FTBFS: make[4]: *** [dbd_mysql/c98.html] Aborted

n...@lists.debian.org > Usertags: qa-ftbfs-20161001 qa-ftbfs > Justification: FTBFS on amd64 > > During a rebuild of all packages in sid, your package failed to build on > amd64. Again, this is unreproducible. Tried several ways, please give me more information how can I check this issue. Thanks, Laszlo/GCS

Bug#837280: Dependency problem

unrelated to its current version number. > As the last choice is least intrusive, I will probably NMU it unless > there will be some objections. See attached diff. Can be, but the worst solution as you can see above. Let me ask what the PostgreSQL maintainers say. Regards, Laszlo/GCS

Bug#825800: graphicsmagick: CVE-2016-5118

. In this case I'm not sure it should be the path. Regards, Laszlo/GCS

Bug#837719: graphicsmagick: FTBFS on ppc64el: PerlMagick test failures

this issue? > I haven't found the exact optimization that's triggering it yet, > and I haven't looked at the code GCC generates. It seems to be a GCC code defect, as you noted that even GCC 5 fails to generate a working code. I think I'll use the -O0 compilation workaround, don't want to further delay the Perl transition. Thanks again, Laszlo/GCS

Bug#837719: graphicsmagick: FTBFS on ppc64el: PerlMagick test failures

ate bad assembly code on ppc64el for your code, not because your source has any problem. > Are you able to easily change the optimization of semaphore.c or log.c > (maybe by injecting an optimization pragma into the code)? Yes, just done. Tested on ppc64el, now it compiles correctly. Currently testing on amd64 and uploading the fixed package version soon. Cheers, Laszlo/GCS

Bug#835669: wxsqlite3: FTBFS when built with dpkg-buildpackage -A (samples/minimal: not found)

S". > > You don't need any special tools or uploading to a special queue. I do know how to prepare it. What I don't know if it's a mandatory or not to do source-only uploads. Thanks, Laszlo/GCS

Bug#782005: ovirt-guest-agent spu

On Mon, Aug 22, 2016 at 4:45 PM, Milan Zamazal <mzama...@redhat.com> wrote: > László Böszörményi (GCS) <g...@debian.org> writes: >> [1] dget -x >> http://http.debian.net/debian/pool/main/o/ovirt-guest-agent/ovirt-guest-agent_1.0.10.2.dfsg-2.dsc > > Is the URL c

Bug#843380: libgvc6 fail to install on stretch

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

Bug#841443: hmqv.h is missing: refered to by /usr/include/cryptopp/eccrypto.h

fix. May you share the program that you want to build? I would like to be sure there's no more headers I might have missed to install. Thanks, Laszlo/GCS

Bug#845687: [Pkg-protobuf-devel] Bug#845687: protobuf: FTBFS on ppc64el: testMergeFrom segmentation fault

ne? What happens if you try the build say three - four times? Thanks, Laszlo/GCS

Bug#844479: zeromq3: zeromq 4.2.0 breaks tango

r Stetch. It's a bit hard to be equitable, 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

Bug#828550: socat: FTBFS with openssl 1.1.0

the adopted patch, attached. The 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 wo

Bug#828550: socat: FTBFS with openssl 1.1.0

results instead of > OPENSSL_VERSION_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

Bug#828550: socat: FTBFS with openssl 1.1.0

l > 1.1.0 bugs are RC)? thanks! Anything wrong with Sebastian Andrzej Siewior's patch? I plan to use if no one objects. Laszlo/GCS

Bug#828299: fetchmail: FTBFS with openssl 1.1.0

itled the bug. Can you reproduce 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

Bug#828299: fetchmail: FTBFS with openssl 1.1.0

On Thu, Nov 3, 2016 at 11:16 PM, Sebastian Andrzej Siewior <sebast...@breakpoint.cc> 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 correct

Bug#839454: [Syslog-ng-maintainers] Bug#839454: syslog-ng-incubator: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2

ata, it > builds fine. The package probably needs a build-depends on tzdata (and maybe a > depends as well). Needs checking, now I don't think it needs a depends on tzdata. Regards, Laszlo/GCS

Bug#839138: Ceph maintainership status

d 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

Bug#847369: Error: Cannot find module 'requirejs' (missing package.json)

;requirejs.js" tasks...ERROR >>> 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

Bug#847542: libmozjs-24-0 24.2.0-4 breaks gnome-shell, preventing gdm3 from starting

ards, Laszlo/GCS

Bug#847542: New packages does not fix the problem on my system

your system? Which application(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

Bug#847542: #847542

fi6 and/or may you try to 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

Bug#847542: #847747

Hi Michael, 2016-12-11 19:29 GMT+01:00 Michael Ott <mich...@king-coder.de>: > I found it. > It looks like #847747 Please test it with downgrading your policykit-1 package as well. Thanks, Laszlo/GCS

<    1   2   3   4   5   >