Bug#1029931: pushpin: build-dependencies unsatisfiable on mips*, ppc64el and s390x.

On Sun, Jan 29, 2023 at 01:10:17PM +0200, Adrian Bunk wrote: > Keeping it "Architecture: any" will automatically (re)add it on > architectures whenever they gain ring support. [...] > Yes, since there are no reverse (build) dependencies > "reportbug ftp.debian.org" to remove the stale binaries >

Bug#1029931: pushpin: build-dependencies unsatisfiable on mips*, ppc64el and s390x.

On Sun, Jan 29, 2023 at 04:28:54AM +, Peter Michael Green wrote: > Package: pushpin > Version: 1.36.0-1 > Severity: serious > > The new version of pushpin added a dependency on jsonwebtoken, > unfortunately jsonwebtoken depends in ring, which is only available > on x86* and arm*. There is

Bug#1005629: zurl: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2

severity 1005629 normal thanks On Tue, Jun 07, 2022 at 09:57:35PM +0200, Lucas Nussbaum wrote: > I tried again and confirmed that it builds fine now. > > When doing those archive rebuilds, I retry failed builds and only file > bugs when they failed two times. Maybe there was an error on the

Bug#1005629: zurl: FTBFS: dh_auto_test: error: make -j1 check VERBOSE=1 returned exit code 2

Hi, I'm unable to reproduce this build error. As it happens in a network related test, I also tried it inside a container with networking blocked. https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/zurl.html shows that automated builds do work, in general. I still suspect that

Bug#975206: zurl: FTBFS: Error: need libzmq >= 2.0!

Control: reassign -1 libzmq3-dev 4.3.3-3 Control: forcemerge 975151 -1 This FTBFS was caused by a missing dependency in libzmq3-dev 4.3.3-3, which was already fixed in libzmq3-dev 4.3.3-4. On Thu, Nov 19, 2020 at 10:57:00AM +0100, Lucas Nussbaum wrote: > Source: zurl > Version: 1.11.0-2 >

Bug#956691: fixed in psi 1.3-6

Hi Laurent, On Thu, Jul 02, 2020 at 10:03:06AM +0200, Laurent Bigonville wrote: > Just for my understanding, why did you switch to libhunspell instead of > libenchant-2? > > As said it seems to have support for enchant-2 in the code (there are > references to HAVE_ENCHANT2) Mainly to be

Bug#863650: Fix available

Hi, I submitted a patch for this issue upstream: https://github.com/pam-pgsql/pam-pgsql/pull/16 Jan

Bug#859841: Bug#891872: transition: curl

Hi Emilio, On Mon, Apr 23, 2018 at 08:38:30PM +0200, Emilio Pozuelo Monfort wrote: > Hmm, I just realised libcurl3 ships libcurl.so.4, so that explains the > conflict. > I just found the rationale for this in > https://salsa.debian.org/debian/curl/merge_requests/2. That means this will > have >

Bug#859841: zurl: Please migrate to openssl1.1 in Buster

Dear readers of this long-standing bug ticket, durign the last 3 weeks there was no real progress, but the release team at least noticed the open transition request (#891872). Unfortunately, there are some conflicts with other transitions. ("That means this will have to wait until there are no

Bug#859841: zurl: Please migrate to openssl1.1 in Buster

Current state of affairs: - curl built against openssl 1.1 was uploaded to experimental https://tracker.debian.org/news/937117/accepted-curl-7580-3-source-amd64-all-into-experimental-experimental/ - zurl built against that version of curl and openssl 1.1 was uploaded to experimental

Bug#859841: zurl: Please migrate to openssl1.1 in Buster

To keep this BTS entry up to date: Unfortunately, I didn't see any progress regarding the status of libcurl3 during the last ~3 weeks. :-( References: https://salsa.debian.org/debian/curl/merge_requests/2 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858398

Bug#859841: zurl: Please migrate to openssl1.1 in Buster

To keep this BTS entry up to date: There seems to be some progress towards a solution at https://salsa.debian.org/debian/curl/merge_requests/2 On Fri, Dec 29, 2017 at 01:58:05PM +0100, Jan Niehusmann wrote: > After another 3 weeks, the status of libcurl3 unfortunately didn't > change

Bug#859841: zurl: Please migrate to openssl1.1 in Buster

After another 3 weeks, the status of libcurl3 unfortunately didn't change at all. The discussion on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858398 continues really slowly, and there is no sign of actual progress :-( Jan

Bug#859841: zurl: Please migrate to openssl1.1 in Buster

Just a small update to people following this issue: The qt5 already updated to openssl 1.1, so the only remaining blocker is curl. In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858398 there is some discussion about the right way to update curl, but I hope some agreement will be reached,

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

Hi, On Sun, May 28, 2017 at 07:54:33PM +0200, Ivo De Decker wrote: > On Sun, May 28, 2017 at 02:39:00PM +0200, Jan Niehusmann wrote: > > May I suggest only removing runit-init from the runit source package, if > > the bug can't be fixed in time for the stretch release? > >

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

May I suggest only removing runit-init from the runit source package, if the bug can't be fixed in time for the stretch release? Because runit itself doesn't cause the issue discussed here, is useful on its own, and several packages depend on it. Thanks, Jan

Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.

BTW, I really think this doesn't need to be RC. (Or, at least, should be stretch-ignore, because removing all the reverse-dependencies would be worse than just shipping with runit-init.) I agree it's bad to leave a user with a broken system. But in this case, the user gets an appropriate

Bug#834088: What's up with mongrel2?

Hi Niels, On Sun, Feb 05, 2017 at 10:44:00AM +, Niels Thykier wrote: > On Sat, 27 Aug 2016 20:16:57 +0300 Dmitry Bogatov wrote: > > Jan, could you please provide more information? I did not follow. As > Are there any news on this bug? It is listed as a possible blocker for

Bug#850881: zurl: Please B-D on "libssl1.0-dev | libssl-dev (<< 1.1)" for stretch

Hi Niels, On Tue, Jan 10, 2017 at 10:20:32PM +0100, Jan Niehusmann wrote: > Am I missing something? Is this a good way to handle the situation? > Would it be possible to speed up the propagation of zurl/1.7.1-3 to > testing so I can upload zurl/1.7.1-4? Even though I didn't get an ans

Bug#850881: zurl: Please B-D on "libssl1.0-dev | libssl-dev (<< 1.1)" for stretch

Hi Niels, On Tue, Jan 10, 2017 at 09:36:57PM +0100, Niels Thykier wrote: > Package: zurl > Version: 7.51.0-1 > Severity: grave > Tags: sid stretch > > Hi, > > Please use ssl1.0 for stretch. > > We have requested the curl also reverts to ssl1.0 (please see > #850880). Since zurl is using a curl

Bug#844018: libcurl3: Building with OpenSSL 1.1 breaks packages using both OpenSSL 1.0 and curl

On Mon, Nov 21, 2016 at 01:03:19AM +0400, Stepan Golosunov wrote: > So far I do not know why using libssl1.1 together with a > libssl1.0.2-using Qt wouldn't work. Well I don't know enough about the dynamic linker and about the internals of openssl to know if (indirectly) linking to both libraries

Bug#844018: libcurl3: Building with OpenSSL 1.1 breaks packages using both OpenSSL 1.0 and curl

On Mon, Nov 21, 2016 at 12:02:45AM +0400, Stepan Golosunov wrote: > It would be a grave bug in such application if it does not have a > working version, yes. Whether or not it would be a serious bug in > lubcurl3 depends on how many and how important such applications are. > (And how difficult

Bug#844018: libcurl3: Building with OpenSSL 1.1 breaks packages using both OpenSSL 1.0 and curl

On Sun, Nov 20, 2016 at 11:38:49PM +0400, Stepan Golosunov wrote: > > Still, for 1.1 the SONAME change is definitely necessary. > > Breaks: against applications using CURLOPT_SSL_CTX_FUNCTION and > compiled with OpenSSL 1.0 will probably suffice in that case. Wouldn't this still be a serious bug

Bug#844018: libcurl3: Building with OpenSSL 1.1 breaks packages using both OpenSSL 1.0 and curl

On Sun, Nov 20, 2016 at 07:40:22PM +0400, Stepan Golosunov wrote: > If SONAME change is needed it is needed when linking libcurl with > libssl1.0.2 too. (But when linking libcurl with libssl1.0.2 more > applications are affected due to the need of explicit initialization.) Upstream documentation

Bug#844018: libcurl3: Building with OpenSSL 1.1 breaks packages using both OpenSSL 1.0 and curl

Package: libcurl3 Version: 7.51.0-1 Severity: serious Justification: Policy 8.1 Dear Maintainer, the curl ABI contains structs inherited from OpenSSL, e.g. in calls like: curl_easy_setopt(easy, CURLOPT_SSL_CTX_FUNCTION, _cb); Here, sslCtxFunction_cb is a function which takes an SSL_CTX * as a

Bug#840177: Set INSTALL_ROOT to fix issue

It seems like dh_auto_install used to set INSTALL_ROOT (works in jessie), but now it doesn't, so the build fails in sid. But it's easy to set INSTALL_ROOT, manually. Just add it to the call of dh_auto_install in debian/rules: --- a/debian/rules +++ b/debian/rules @@ -22,7 +22,7 @@

Bug#834088: update-service doesn't work as expected

Control: reassign -1 runit Control: retitle -1 update-service doesn't work as expected mongrel2-run, from it's postinst script, just calls: update-service --add /etc/sv/mongrel2 >From the manpage of update-service, this looks like a valid command to add mongrel2 to the system-wide service

Bug#817708: uml-utilities marked for removal

On Wed, Jul 06, 2016 at 07:05:05AM -0700, Mattia Dongili wrote: > No. At the moment it doesn't make much sense to keep uml-utilities in > the archive. Even if/when UML is re-added, it should be considered > whether uml-utilities are all that useful. I saw uml-utilities installed on many systems

Bug#801413: fixed in polarssl 1.3.14-0.1

Hi, as polarssl is is marked for autoremoval from testing on 2015-12-09 because of bug #801413, I wonder why the upload fixing the issue is only in experimental. Is there a reason for not pushing it to unstable? I'm asking because I'm the maintainer of two reverse dependencies. Jan

Bug#804331: mongrel2: FTBFS in jessie - FAILED: failed to verify m2-cert.pem

Hi, On Sat, Nov 07, 2015 at 02:30:09PM +, James Cowgill wrote: > I know. I was wondering if it could be fixed in stable? Well, for stable I'd just disable the failing test, instead of backporting the upstream fix. Commenting out the mu_assert line containing the error message would be

Bug#759952: Build failure is caused by parallel build

Hi, it seems like #759952 is caused by the parallel build. The output shows the following sequence of events: 1) the debian/rules target 'build-prep' executes cd hun-eng; make hun-eng.tei 2) make hun-eng.tei runs: cp hun-eng.tei.header hun-eng.tei ./szotar-dbf2tei.pl hun-eng.tei 3)

Bug#736066: Allow encfs into jessie?

Hi Holger, On Thu, Sep 11, 2014 at 06:42:32PM +0200, Holger Levsen wrote: I (probably too briefly) skimmed though the bug report, but couldn't find a usecase where an encrypted filestem container with broken crypto could be useful. Could you elaborate, please? As far as I understand the

Bug#736066: Allow encfs into jessie?

Hi, due to bug #736066, encfs was removed from jessie. I'd think it would be better to allow encfs into jessie for the following reasons: The bug report is about security issues, but these are not security issues of the software (as in: you can somehow hack into the computer wich is running the

Bug#604514: Preparations for the removal of the KDE3 and Qt3 libraries

I guess qca-tls can just be removed from unstable/testing now: $ apt-cache rdepends qca-tls qca-tls Reverse Depends: mailody kopete AFAIKT mailody was already removed between lenny and squeeze, and kopete switched from qt3 to qt4 and uses libqca2-plugin-ossl now instead of qca-tls. --

Bug#602288: proftpd-basic: Remote Code Execution Vulnerability in TELNET_IAC processing

Package: proftpd-basic Version: 1.3.3a-4 Severity: grave Tags: security patch Justification: security hole According to http://bugs.proftpd.org/show_bug.cgi?id=3521 and http://www.proftpd.org/docs/RELEASE_NOTES-1.3.3c, there is a remote code execution vulnerability in proftpd since version

Bug#586273: adobe flash download link

Hi, I found the 64bit flash plugin at http://labs.adobe.com/downloads/flashplayer10.html The file http://download.macromedia.com/pub/labs/flashplayer10/flashplayer_square_p1_64bit_linux_091510.tar.gz contains a libflashplayer.so which does work on my amd64 squeeze system. (Tested with a single

Bug#485597: lowering severity of psi bug

severity 485597 normal thanks I decided to lower the severity, because there is an easy workaround (disable spell checking). The reason for the segfault seems to be that the following code in qt4-x11-4.4.0/src/gui/painting/qpainter.cpp results in angle being NaN, which in turn later leads to

Bug#485597: Acknowledgement (psi: Segmentation fault upon typing in chat window)

On Tue, Jun 10, 2008 at 02:41:54PM +0200, Stefan Schmidt wrote: I just realized the kernel log has some additional info on the segfault: psi[15177]: segfault at bfaec008 eip b72b17ff esp bfae68f0 error 6 psi[15543]: segfault at bfc3e008 eip b7278813 esp bfc39000 error 6 psi[15869]: segfault at

Bug#475825: FTBFS: ERROR: could not build a simple Qt program.

I just reproduced this problem. First, I got the following problem: Checking Qt version...no! ERROR: incorrect Qt version found: **Unknown** The **Unknown** strings comes from a call to qmake -query QT_VERSION. This seems to be a problem of qt3: [EMAIL PROTECTED]:/tmp/qbrew-0.4.0$ qmake-qt4

Bug#475418: psi: symbol lookup error on start

On Thu, Apr 10, 2008 at 07:20:07PM +0200, [EMAIL PROTECTED] wrote: Package: psi Version: 0.11-4 Severity: grave Justification: renders package unusable [EMAIL PROTECTED]:~% psi psi: symbol lookup error: /usr/lib/libQtNetwork.so.4: undefined symbol: _ZN14QObjectPrivate15checkWindowRoleEv

Bug#437815: Patch to add alternatives support

Here is a simple patch to add alternatives support for traceroute6. It's minimally tested (builds and allows installation of traceroute and iputils-tracepath at the same time on my system): diff -urN traceroute-2.0.7.dist/debian/control traceroute-2.0.7/debian/control ---

Bug#434561: libqca2-dev: Missing file qca.pc

Package: libqca2-dev Version: 2.0.0~beta7-1 Severity: grave Justification: renders package unusable Due to some changes in the build procedure the package is missing some files necessary to compile software using libqca2. I should have noticed that before uploading the package :-( Update follows

Bug#432620: psi_0.11~beta2-1(hppa/experimental): FTBFS: build-depends on removed package

On Wed, Jul 11, 2007 at 03:11:18AM +0200, Frank Lichtenheld wrote: Package: psi Version: 0.11~beta2-1 Severity: serious Hi, your package build-depends on libqt4-debug-dev which doesn't exists anymore. You are, of course, right. While the fix is trivial, I hold off uploading a new

Bug#404611: Could easily be fixed in mozilla-imagezoom

(Cc: to the imagezoom maintainers) I did a short investigation on this bug: It's caused by the fact that mozilla-imagezoom does contain a file (or, more correctly, a symlink) at usr/lib/iceweasel/defaults/pref/imagezoom-defaults.js This makes mozilla-imagezoom own the directory

Bug#400450: doc-base can handle only one document per file

This bug is caused by debian/xterm.doc-base containing descriptions for two documents. According to dh_installdocs, If your package needs to register more than one document, you need multiple files. To accomplish this, you can use files named debian/package.doc-base.* Therefore, to fix this

Bug#393451: linux-image-2.6.17-2-xen-k7: similar problems here - versions from unstable are fine

Package: linux-image-2.6.17-2-xen-k7 Followup-For: Bug #393451 Yesterday, when upgrading an old xen installation to testing, I saw similar kernel panics. I didn't take screen shots, so I can't tell if it was really the same bug, bug it also panicked during startup of the domUs. I solved the

Bug#376366: POSIX patch is causing the problem

Hi, the observation that IFS is causing the problem looks plausible, and if it's true, the offending change is this one: --- /etc/init.d/rcS 2004-08-14 18:47:29.0 +0200 +++ rcS 2005-10-30 11:05:07.0 +0100 @@ -55,9 +55,6 @@ trap : INT QUIT TSTP element() { -local

Bug#350783: xpdf: Buffer overflow vulnerability in Splash.cc; CVE-2006-0301

Package: xpdf-reader Version: 3.01-5 Severity: grave Tags: security Justification: user security hole xpdf is probably vulnerable due to the bug described in http://www.frsirt.com/english/advisories/2006/0389 (I didn't actually check if it's really vulnerable - but I guess it is) -- System

Bug#341011: Intention to NMU

On Mon, Jan 02, 2006 at 03:52:48PM +0100, Luk Claes wrote: Hi Attached the patch for the version I intend to upload. Please respond if you don't want this NMU to happen, if you are working yourself on a patch or if you think that the attached patch won't work. Feel free to NMU. Do you

Bug#342852: Cogito 0.16.1 contains bash-3.1 fixes

The latest released version of cogito, 0.16.1, also contains bash-3.1 fixes. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#342337: xpdf: Security hole CAN-2005-3193

Package: xpdf-reader Version: 3.00-13 Severity: grave Tags: security patch Justification: user security hole CAN-2005-3193 lists a security hole of xpdf. A fix is available at http://www.foolabs.com/xpdf/download.html (the patch seems to be suitable for a security update - only overflow

Bug#342337: xpdf: Security hole CAN-2005-3193

On Wed, Dec 07, 2005 at 11:42:08PM +1100, Hamish Moffatt wrote: merge 342281 342337 Oops - I'm sorry, I missed that report. The fixed version is an update to 3.01, not 3.00. I know, but the patch applies to 3.00 without much trouble. #342281 is already fixed in unstable. sarge and woody

Bug#342337: xpdf: Security hole CAN-2005-3193

On Thu, Dec 08, 2005 at 12:12:09AM +1100, Hamish Moffatt wrote: On Wed, Dec 07, 2005 at 02:00:55PM +0100, Jan Niehusmann wrote: Ok, so you noticed that my analysis was not completely correct - while the woody version indeed doesn't contain JPXStream.cc (and consequently, the JPX stream

Bug#328010: qssl will be removed

Package: qssl Followup-For: Bug #328010 I just filed bug #333527 on ftp.debian.org and asked for removal of qssl. Jan -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'oldstable'), (500, 'testing'), (500, 'stable'), (101,

Bug#330247: same problem with passwd.5

I get the same problem with the package passwd, containing passwd.5 which is also in manpages-de. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#328010: qssl: uninstallable; needs rebuild for the Qt/KDE transition

On Tue, Sep 13, 2005 at 11:07:18PM +0200, Adeodato Simó wrote: * Jan Niehusmann [Tue, 13 Sep 2005 09:25:09 +0200]: On Tue, Sep 13, 2005 at 01:47:49AM +0200, Adeodato Simó wrote: Finally, if there's a strong reason for which your package should not be NMUed, please note so

Bug#328010: qssl: uninstallable; needs rebuild for the Qt/KDE transition

On Tue, Sep 13, 2005 at 01:47:49AM +0200, Adeodato Simó wrote: Finally, if there's a strong reason for which your package should not be NMUed, please note so in this bug report. Prospective NMUers will read your reasoning, and will decide if it's strong enough to delay their upload.

Bug#326607: libqca1c2: shares files with libqca1 without conflicts

On Mon, Sep 05, 2005 at 04:09:22PM +0200, Peter Palfrader wrote: On Mon, 05 Sep 2005, Jan Niehusmann wrote: I don't think this is really serious, as both packages depend on different versions of the qt libraries, which in turn do conflict, so it's not possible to accidentally install both

Bug#326607: libqca1c2: shares files with libqca1 without conflicts

On Sun, Sep 04, 2005 at 03:09:03PM +0200, Peter Palfrader wrote: Package: libqca1c2 Version: 1.0-7 Severity: serious And the packages don't conflict/replaces. I don't think this is really serious, as both packages depend on different versions of the qt libraries, which in turn do conflict,

Bug#290455: waiting for g++ transition

I just want to let you know that I'm not ignoring this bug. But I'm waiting on qt-x11-free to do the g++ transition, before I do a new upload of psi. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#316273: kwiki: copyright file doesn't say where the upstream sources were obtained

Package: kwiki Version: 0.18-2 Severity: serious Justification: Policy 12.5 debian/copyright doesn't mention where kwiki sources were obtained. This is a violation of policy 12.5. Fix should be trivial, as I guess the maintainer knows where he finds the upstream sources. -- System Information:

Bug#311264: kwiki 0.36-1 uninstallable due to missing libkwiki-perl

On Wed, Jun 29, 2005 at 08:30:55PM +0200, Mohammed Adnène Trojette wrote: 4/ I have tried to make a submittable patch, but I noticed that 0.36-1 was using upstream's 0.18 release (I may have been mistaken). You're right, although the package version is 0.36-1, it contains upstream version 0.18,

Bug#311264: kwiki 0.36-1 uninstallable due to missing libkwiki-perl

Package: kwiki Version: 0.36-1 Severity: grave Justification: renders package unusable # apt-get install kwiki [...] The following packages have unmet dependencies: kwiki: Depends: libkwiki-perl (= 0.36-2) but it is not installable E: Broken packages I think the subject together with the