Source: passwordsafe
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
I saw autopkgtest failure for passwordsafe
133s /usr/include/gtest/internal/gtest-port.h:270:2: error: #error C++ versions
less than C++14 are not supported.
133s 27
close 925702 1.9.0.20190831-1
thanks
Fixed with upload of new upstream 1.9.0.
gency=medium
+
+ * Non-maintainer upload
+ * Update build-deps for googletest. Closes: #897171.
+
+ -- Steve M. Robbins Tue, 01 May 2018 22:59:58 -0500
+
synergy (1.8.8-stable+dfsg.1-1) unstable; urgency=low
* New upstream version.
diff -Nru synergy-1.8.8-stable+dfsg.1/debian/control sy
On Sun, Apr 29, 2018 at 07:41:26AM -0500, Steve M. Robbins wrote:
> 1. Modify the build to look for headers in /usr/src/googletest.
Below is a patch to achieve this.
--- meson-0.46.0.orig/mesonbuild/dependencies/dev.py2018-03-03
16:02:02.0 -0600
+++ meson-0.46.0/mesonbu
On Sun, Apr 29, 2018 at 01:36:08PM +0200, David Kalnischkies wrote:
> Not really knowledgeable enough about cmake through to know if that is
> the best we can do ??? it looks kinda ugly/dirty.
Your patch looks fine to me. A slight improvement below avoids
repeating the /usr/src path.
> We cou
Package: src:cctz
Severity: serious
Justification: fails to build from source (but built successfully in the past)
control: block 897104 by -1
Hi,
The googletest package provides full sources -- including header files
-- in /usr/src/googletest. Prior to version 1.8.0-9, a second copy of
the hea
Package: src:fmtlib
Severity: serious
Justification: fails to build from source (but built successfully in the past)
control: block 897104 by -1
Hi,
The googletest package provides full sources -- including header files
-- in /usr/src/googletest. Prior to version 1.8.0-9, a second copy of
the h
Package: src:meson
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi,
The googletest package provides full sources -- including header files
-- in /usr/src/googletest. Prior to version 1.8.0-9, a second copy of
the headers was mistakenly installe
Package: src:synergy
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi,
The googletest package provides full sources -- including header files
-- in /usr/src/googletest. Prior to version 1.8.0-9, a second copy of
the headers was mistakenly instal
Package: src:aff4
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi,
The googletest package provides full sources -- including header files
-- in /usr/src/googletest. Prior to version 1.8.0-9, a second copy of
the headers was mistakenly installed
Hi,
The googletest package provides full sources -- including header files
-- in /usr/src/googletest. Prior to version 1.8.0-9, a second copy of
the headers was mistakenly installed into /usr/include.
All the listed packages rely on this behaviour and now fail to build
since googletest version 1
Package: src:flightcrew
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Subject: Package erroneously expects googletest headers in /usr/include
Package: apt
Version: 1.6.1
Severity: serious
Justification: fails to build from source (but built succes
Package: src:protobuf
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi,
The googletest package provides full sources -- including header files
-- in /usr/src/googletest. Prior to version 1.8.0-9, a second copy of
the headers was mistakenly insta
Package: apt
Version: 1.6.1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
control: block 897104 by -1
Hi,
The googletest package provides full sources -- including header files
-- in /usr/src/googletest. Prior to version 1.8.0-9, a second copy
Source: ros-catkin
Version: 0.7.11-1
Severity: serious
Justification: fails to build from source
Debian's googletest package used to ship only sources, not a compiled
libgtest. The ros-catkin package has a build-dep on libgtest-dev.
However: at build time libgtest is probed for, not found, and C+
* Non-maintainer upload.
+ * Tweak 00-tests.patch to ignore system libgtest (Closes: #895707)
+
+ -- Steve M. Robbins Sat, 14 Apr 2018 18:20:28 -0500
+
gumbo-parser (0.10.1+dfsg-2.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru gumbo-parser-0.10.1+dfsg/debian/patches/00-tests.patch
Source: boost1.61
Severity: grave
Package has been superceded by later Boost. Should not be in testing.
In fact, was removed from testing earlier [1] but returned because I
did not file this bug soon enough. Package is also marked for removal
from unstable [2].
-Steve
[1] https://packages.qa.de
On Tue, Nov 29, 2016 at 04:32:21PM +0100, Thorsten Alteholz wrote:
> building the alljoyn packages (alljoyn-core-1504, alljoyn-core-1509,
> alljoyn-core-1604) with googletest and gcc-6 gives the following compile
> error. I guess the "#include " jusst needs to be replaced by
> "#include " for gcc-
On Sunday, November 20, 2016 1:13:32 PM CST David Kalnischkies wrote:
> On Sat, Nov 19, 2016 at 10:06:17PM -0600, Steve M. Robbins wrote:
> > On Fri, Nov 18, 2016 at 01:29:07PM +0100, David Kalnischkies wrote:
> > > You should also update your README.Debian and the descriptions
On Wednesday, November 16, 2016 12:16:22 PM CST Thibaut Paumard wrote:
> Control: tags 844490 +pending
> Control: severity 844495 normal
>
> For the record, the bug appears when doing:
>
> acos(cos(alpha100)*cos(delta100));
>
> where the type of alpha100 and delta100 is
> boost::multiprecision::
On Fri, Nov 18, 2016 at 01:29:07PM +0100, David Kalnischkies wrote:
> libgtest-dev contains in 1.8.0-1 a symlink to the new on-disk location.
> That works for new installs, but doesn't on upgrades ??? a user ends up
> with an empty /usr/src/gtest in that case. You need to work with
> maintainersc
On Tuesday, November 15, 2016 1:02:10 AM CST Santiago Vila wrote:
> Package: librospack-dev,libgtest-dev,src:ros-image-common
> Severity: serious
>
> Dear maintainer:
>
> I tried to build ros-image-common in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do
My understanding is that you have to first build boost with the
pie-enabled compiler chain, then build your package with the new
boost.
c.f. https://wiki.ubuntu.com/SecurityTeam/PIE
Note that using -fPIC on static libs is against current Debian Policy.
-Steve
On Mon, Oct 24, 2016 at 08:19:13P
On Mon, Sep 12, 2016 at 01:18:32AM +0200, Balint Reczey wrote:
> /usr/bin/ld:
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/libPapyrus3.a(PapyError3.c.o):
> relocation
> R_X86_64_32 against `.rodata.str1.8' can not be used when making a
> shared object; recompile with -fPIC
> ...
The Ubuntu
On Mon, Sep 12, 2016 at 01:18:32AM +0200, Balint Reczey wrote:
> During a rebuild of all packages in sid, gdcm
> failed to build on amd64 with patched GCC and dpkg. The root
> cause seems to be that libPapyrus3.a is shipped as a non-PIC library.
That cannot be the root cause. Debian Policy [1] i
Hello,
Thanks for the bug report.
On Saturday, October 15, 2016 3:35:24 PM CDT you wrote:
> during a test with piuparts I noticed your package fails to upgrade from
> 'jessie'.
The output you quoted doesn't indicate WHY it was to be removed. Do you know?
> # ok, lets try to install it in str
Hi,
I'll switch it back shortly.
On Friday, August 12, 2016 7:37:33 PM CDT Mattia Rizzolo wrote:
> for some reason you swapped your build-dependency on the metapackage
> libboost-graph-dev to the versioned libboost-graph1.60-dev.
Here's the story: I worked on digikam 5.0.0 a month ago, when the
Help me reproduce the problem. I can't find "alljoyn" sources:
steve@riemann{NMU}apt source alljoyn
Reading package lists... Done
E: Unable to find a source package for alljoyn
-Steve
signature.asc
Description: This is a digitally signed message part.
Hi Mattia,
I can take care of this.
On June 27, 2016 01:11:57 PM Mattia Rizzolo wrote:
> Since we are pretty near the removal of jasper, I intend to NMU digikam
> disabling jasper support with the attached patch.
> I'm currently holding off the upload as I first need to have imagemagick
> done
el, powerpc,
ppc64el, s390x
libcableswig-dev | 0.1.0+git20150808-2 | amd64, arm64, armel, armhf, hurd-
i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc,
ppc64el, s390x
Maintainer: Steve M. Robbins
--- Reason ---
---
o fix CVE-2015-6673 (Closes:
+#798032). New patches 02-fix-CVE-2015-6673-upstream-147.patch and
+03-fix-CVE-2015-6673-upstream-148.patch.
+
+ -- Steve M. Robbins Sun, 03 Apr 2016 21:58:47 -0500
+
libpgf (6.14.12-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru libpg
On Tue, 22 Sep 2015 15:34:20 +0200 Etienne BRETTEVILLE
wrote:
> After upgrading from LinuxMintDebianEdition LMDE 1 (based on debian 7) to
LMDE2
> based on debian Jessie, digikam has been updated to 4.4.0 instead of 3.5.x.
>
> Since then I'm no longer able to import my pictures from my CanonEOS
On Fri, 30 Oct 2015 10:55:05 +0100 valette wrote:
> Package: digikam
> Severity: grave
> Justification: renders package unusable
>
> digikam is not installable anymore in unstable or testing.
That has just been fixed with upload of 4.14.
> The 5.0.0 is.
At this point, I expect we will wait fo
On December 10, 2015 09:20:52 PM you wrote:
> Package: clementine
> Version: 1.2.3+git1354-gdaddbde+dfsg-1
> Severity: grave
>
> Hi,
>
> I must have removed some package because clementine now fails to start:
>
> steve@riemann{Downloads}clementine
> clementine: error while loading shared librari
Package: clementine
Version: 1.2.3+git1354-gdaddbde+dfsg-1
Severity: grave
Hi,
I must have removed some package because clementine now fails to start:
steve@riemann{Downloads}clementine
clementine: error while loading shared libraries: libechonest.so.2.1: cannot
open shared object file: No such
Hi,
[Adding minc-development as follow-up to previous email;
http://www.bic.mni.mcgill.ca/pipermail/minc-development/2015-November/001223.html
]
On December 4, 2015 08:25:09 PM Jurica Stanojkovic wrote:
> User: debian-m...@lists.debian.org
>
> Hello,
>
> I have tried to build package libmin
severity 804575 normal
thanks
On Mon, Nov 09, 2015 at 07:28:38PM +0100, Emilio Pozuelo Monfort wrote:
> Source: insighttoolkit4
> Version: 4.8.1-1
> Severity: serious
>
> Your package build-depends on libdcmtk2-dev, which is no longer
> built by src:dcmtk. You should build-depend on libdcmtk-dev
Package: xserver-xorg-video-radeon
Version: 1:7.5.0-1+b1
Severity: grave
With the 4.2 kernel, X11 fails to start up. The log file Xorg.0.log
contains a diagnostic "[drm] failed to set drm interface version."
Workaround: downgrading to kernel 4.1 allows X11 to start.
Note that this bug report is
Control: tags -1 + pending
To update my progress: the packaging vcs [1] (slightly reorganized) has new
upstream development branch code that builds properly with the new NetCDF. I
am awaiting a new upstream release (in the coming week) to set the proper
version for minc-tools.
[1] http://ano
On September 2, 2015 02:48:01 PM Simon McVittie wrote:
> How long ago were maintainers of packages depending on insighttoolkit 3
> told that it was obsolete and going to be removed?
Most recently: on August 12th; see
https://lists.debian.org/debian-med/2015/08/msg00089.html
-Steve
signature.
On September 2, 2015 01:33:35 PM Simon McVittie wrote:
> Control: tags 797755 + wontfix
>
> On 02/09/15 13:05, Steve M. Robbins wrote:
> > On September 2, 2015 10:55:01 AM you wrote:
> >> In the case of insighttoolkit, std::string appears in installed headers,
> >&g
Thanks. The problem is known and fixed in 4.8.0 -- presently in experimental.
-Steve
signature.asc
Description: This is a digitally signed message part.
On September 2, 2015 10:55:01 AM you wrote:
> Source: insighttoolkit
> Version: 3.20.1+git20120521-6
> Severity: serious
> Justification: breaks ABI without a package rename
> Control: block -1 by 797738
> Tags: sid stretch
> User: debian-...@lists.debian.org
> Usertags: libstdc++-cxx11
>
> Backgr
On Wed, Aug 19, 2015 at 10:32:04PM +0200, Sebastiaan Couwenberg wrote:
> To fix this issue I've done an NMU of minc to DELAYED/2, see the
> attached debdiff for changes.
> +override_dh_auto_test:
> + dh_auto_test || echo "Ignoring test failures"
> +
I'm afraid that I can't agree that ignori
Hi,
The GCC 5 build failure is -- I think -- blocking the build of GDCM. The bug
is closed with an upload to Experimental. Any estimate on when we might see
this fix in Unstable?
Thanks,
-Steve
signature.asc
Description: This is a digitally signed message part.
On August 5, 2015 11:23:36 AM Nico Schlömer wrote:
> GCC-XML has been deprecated [1], it's developers recommend CastXML.
> Since this is already in Debian [2], we might think about dropping
> GCC-XML from Debian altogether.
Yes, as soon as the build-dep packages are modified to use CastXML, I'll f
On July 28, 2015 10:01:46 PM Rene Engelhard wrote:
> Given the test only does
>
> TEST(Writer, Int) {
> TEST_ROUNDTRIP("[-1]");
> TEST_ROUNDTRIP("[-123]");
> TEST_ROUNDTRIP("[-2147483648]");
> }
>
> I don't believe it's rapidjson at fault but gtest... Cc'ing gtests
> maintainer.
Thi
On July 20, 2015 02:55:56 PM you wrote:
> Package: castxml
> Severity: serious
> Justification: fails to build from source
>
> Dear maintainer,
>
> just want to let you know I'm working towards a fix for the FTBFS of castxml
> on mipsel [0].
>
> There are some tests that are failing.
Thanks for
reassign 777868 gdcm
thanks
On Sun, Jul 05, 2015 at 10:29:57AM +, Gianfranco Costamagna wrote:
> actually the problem on this bug is on gccxml, so I guess
> reassigning is the right thing to do.
Well, the original submitter was pretty clear:
Please keep this issue open in the bug tracke
Hi Gianfranco,
On July 4, 2015 11:51:19 AM Steve Robbins wrote:
> Hey. I was just planning to let v3 just die. But if the fix is just using
> the same patch it could be useful to apply it. Still has several
> dependancies.
So now that I'm home, I see on this bug report your message of 7 May 2
The recent build failure of elastix (#759945) is caused by the
libhdf5.so path having changed, presumably due to #755539. The path
is encoded into insighttoolkit4-dev's file
/usr/lib/cmake/ITK-4.6/ITKTargets-none.cmake so Elastix will need a
binnmu as soon as insighttoolkit is rebuilt.
-Steve
On August 21, 2014 09:50:56 AM Andreas Tille wrote:
> Hi,
>
> as you might have noticed igstk is RC buggy and also lagging behind
> upstream (5.2). If nobody has any interest in keeping the package alive
I don't use the package and have no intention of maintaining it, I'm afraid.
-Steve
--
T
On June 30, 2014 06:07:21 PM Gert Wollny wrote:
> The significant error is
>
> /usr/share/gccxml-0.9/GCC/4.9/bits/stl_algo.h: In function
> '_OutputIterator std::__unique_copy(_InputIterator, _InputIterator,
> _OutputIterator, _BinaryPredicate, std::input_iterator_tag,
> std::output_iterator_tag)'
On June 30, 2014 06:07:21 PM Gert Wollny wrote:
> The significant error is
>
> /usr/share/gccxml-0.9/GCC/4.9/bits/stl_algo.h: In function
> '_OutputIterator std::__unique_copy(_InputIterator, _InputIterator,
> _OutputIterator, _BinaryPredicate, std::input_iterator_tag,
> std::output_iterator_tag)'
You re-raised the severity without comment.
Did you attempt a build of insighttoolkit4?
Thanks,
-Steve
signature.asc
Description: Digital signature
Well,
Thank you.
On April 21, 2014 04:56:21 PM Niels Möller wrote:
> Magnus Holmgren writes:
> > Oh well, I went ahead and did it for you. However, as you can see, some
> > symbols went missing in both 5.1 and 6.0.
>
> Are those the ones in the #MISSING: lines in your file? They are all
> undoc
On April 20, 2014 06:59:31 PM Magnus Holmgren wrote:
> reassign 745233 libgmp10
> retitle 745233 libgmp10: Wrong shlibs information after 6.0.0 adds new
> symbols affects 745233 libhogweed2
> thanks
>
> söndagen den 20 april 2014 12.55.09 Ivo De Decker:
> > On Sun, Apr 20, 2014 at 01:14:18AM +0200
On April 1, 2014 09:12:24 AM Anton Gladky wrote:
> 2014-03-31 10:58 GMT+02:00 Mathieu Malaterre :
> > Typical scenarios that should not happen is an app linked against
> > vtkCommon and vtkCommonCore. This gets even worst with python
> >
> > $ python
> > import vtkCommon
> > import vtkCommonCore
>
On April 1, 2014 08:59:13 AM you wrote:
> As explained in details libs have different SONAME (vtkCommon !=
> vtkCommonCore) however they provide the same symbols (up to the ABI
> diff). This is bad (tm) !
Sorry, what details are you referring to?
-Steve
signature.asc
Description: This is a dig
On March 31, 2014 10:58:28 AM Mathieu Malaterre wrote:
> Package: libvtk6
>
> Clearly there is something missing here. libvtk6 can be co-installed
> with libvtk5.8. VTK API (ABI too) is completely incompatible in
> between those two versions.
Clearly I'm missing something, because it is routine t
On March 1, 2014 06:38:45 PM Cyril Brulebois wrote:
> Steve M. Robbins (2014-03-01):
> > tags 739807 + pending
> > thanks
>
> Just in case the upload doesn't happen, please find attached the tested
> patch I had been working on and testing during the past hour…
Tha
Hi Mathieu,
Clearly, there is a bug.
On February 8, 2014 03:35:58 PM Mathieu Malaterre wrote:
> Your point is correct, importing *solely* ITK 4.0 does work. However
> what does not work is clearly indicated at
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728121#10
>
> This is a ~4 line
On Wed, Jan 29, 2014 at 11:02:35AM +0100, Mathieu Malaterre wrote:
> Control: severity 728121 grave
>
> Marking as grave since render the package unusable.
How does this render the package unusable? As one counter-example,
the package 'elastix' builds fine using the ITK -dev package.
-Steve
s
Hi Mathieu,
I appreciate your interest and attention to ITK v3.
On December 29, 2013 12:48:14 PM Mathieu Malaterre wrote:
> I would appreciate if someone would double check this patch (1). Or
> the other solution (2) is to use the embedded TIFF lib. Since ITK 3.x
> is pretty much a branch dead-u
reassign 721577 cpp-netlib
thanks
On Mon, Nov 25, 2013 at 02:29:40PM +0100, Mathieu Malaterre wrote:
> Seems like #721577 is still present. As can be seen here:
>
> https://buildd.debian.org/status/fetch.php?pkg=cpp-netlib&arch=mips&ver=0.10.1-1&stamp=1385355483
> https://buildd.debian.org/statu
On October 22, 2013 07:28:51 AM Andreas Tille wrote:
> Hi Steve,
>
> the package wrapitk-python has two RC bugs (#701370, #713202) without
> any response, the homepage does not exist any more and even seeking
> itk.org for "Python wrapper" does not oncover any alternative. Since
> you are the onl
On October 19, 2013 11:51:14 AM Ivo De Decker wrote:
> Hi Steve,
>
> Thanks for all the info. That really helps!
Thank YOU (the Samba Team) for diligent analysis of bug reports! It can't be
easy on a complex configurable suite like Samba.
> It's not immediately clear why /var/lib/samba/privat
On October 19, 2013 04:34:55 PM Andrew Bartlett wrote:
> On Fri, 2013-10-18 at 20:41 -0500, Steve M. Robbins wrote:
> > > - the samba version you were running before the upgrade
> >
> > I was following the "samba" packages (not "samba4") so it would
> - do you have backups from before the upgrade? Could you get the contents of
> smb.conf and the directory listings mentioned above from before the upgrade?
So, actually I have /etc/samba, but no backups of /var/lib.
Old smb.conf:
# Samba config file created using SWAT
# from UNKNOWN ()
# Da
Hi,
On Fri, Oct 18, 2013 at 07:35:10PM +0200, Ivo De Decker wrote:
> In addition to the smb.conf (which Andrew asked in the other mail),
steve@riemann{~}cat /etc/samba/smb.conf
# Samba config file created using SWAT
# from UNKNOWN ()
# Date: 2010/01/17 16:53:25
[global]
workgroup = SUM
On Tue, Oct 15, 2013 at 11:44:47PM -0700, Steve Langasek wrote:
> Control: tags -1 moreinfo
>
> Hi Steve,
>
> > For the benefit of anyone else who got stuck: I ran "smbpasswd -a" to
> > create
> > each user/passwd in the new password database.
>
> What do you mean by "new password database"?
severity 724711 wishlist
thanks
On Fri, Sep 27, 2013 at 01:14:13AM +0200, Kurt Roeckx wrote:
> It seems that insighttoolkit4 4.4.2-2 restricted itself to support
> i386 and amd64. The only reason I can find for that is that the
> test suite had some errors on the other arches. I generally find
>
Hello Nobuhiro,
On July 3, 2013 12:10:59 PM Nobuhiro Iwamatsu wrote:
> 2013/7/1 Steve M. Robbins :
> > I'm considering removing the 32- and 64-bit "biarch" variants of gmp [1].
So I've gone ahead with removing lib32gmp. This means that #718108 can only
be fixed b
On August 23, 2013 01:44:12 PM Timur Birsh wrote:
> On Thu, Aug 22, 2013 at 08:54 -0500, Steve M. Robbins wrote:
> > > Perhaps I should put create_cache_dir() call in 'restart' command.
> >
> > Perhaps you can code it so that "restart" just calls &qu
On August 22, 2013 03:27:56 PM Timur Birsh wrote:
> On Wed, Aug 21, 2013 at 23:25 -0500, Steve M. Robbins wrote:
> > root@riemann{~}ls -la /run/inadyn
> > ls: cannot access /run/inadyn: No such file or directory
> > root@riemann{~}ls -la /var/log/inadyn
> > total 16
>
On August 20, 2013 02:58:27 PM Timur Birsh wrote:
> The package had installed w/o any errors?
I don't recall seeing any install errors.
> Would you please uninstall the package completely (w/ run/log dirs, config)
> and install it again.
OK.
> Right after install please run following comm
On Mon, Aug 19, 2013 at 02:09:48PM +0600, Timur Birsh wrote:
> Would you please show log messages
Attached in file inadyn.log.
> and output of the following commands:
>
> $ ls -la /run/inadyn
> $ ls -la /var/log/inadyn
> $ getent passwd debian-inadyn
> $ getent group debian-inadyn
Attached
Package: inadyn
Version: 1.99.4-1
Followup-For: Bug #711226
Hi,
I ran into this problem on a new install of 1.99.4-1.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3
Hi again,
I was incorrect in my last message when I said that
mu_authenticate_system() is not called. It is called.
The patch I provided completely fixes my problem.
-Steve
signature.asc
Description: Digital signature
So the immediate problem is that the crypt() call in system.c line 108 returns
NULL, so
the strcmp() naturally segfaults. Below is a patch to cure this issue. The
program now
just displays "-ERR Bad login" without a segfault.
What I don't yet understand is why mu_authenticate_generic() is used
Hi,
Below is a backtrace (password masked).
Program received signal SIGSEGV, Segmentation fault.
__strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:213
213 ../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory.
(gdb) bt
#0 __strcmp_ssse3 () at ../sysdeps/x86_64/multiar
Package: mailutils-pop3d
Version: 1:2.99.98-1
Severity: grave
File: /usr/sbin/pop3d
The pop3d daemon segfaults after receiving the USER and PASS commands.
This has been happening for quite some time, perhaps 6 months or more.
Running under gdb gives the following backtrace.
Program received sign
Package: kdevelop
Version: 4:4.3.1-3+b2
Severity: grave
KDevelop crashes when creating a new project. I got to the dialog
titled "Configure a build directory for ${project} - KDevelop" and
when I click OK, it crashes (segfault).
There is no useful backtrace, despite installing package kdevelop-d
On Tue, Jul 30, 2013 at 04:05:10PM +0200, Vincent Lefevre wrote:
> On 2013-07-30 08:25:20 -0500, Steve M. Robbins wrote:
> > On July 30, 2013 12:42:09 PM Vincent Lefevre wrote:
> > > (note that libmpfr-dev:i386 is not installable).
> >
> > I'm surprised you sa
On July 30, 2013 12:42:09 PM Vincent Lefevre wrote:
> On 2013-07-29 23:46:38 -0500, Steve M. Robbins wrote:
> > OK, how about "with standard abi, the compiler will find it";i.e.
> > without -m32. The lib32gmp package had to place its header in an
> > unusual location
On July 28, 2013 05:40:23 PM Vincent Lefevre wrote:
> On 2013-07-28 17:28:57 +0200, Vincent Lefevre wrote:
> > Currently I still don't understand
> > why -m32 would be a problem.
> On http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675577 it is said
> "My apologies -- it wasn't meant to be an int
On July 21, 2013 09:55:43 PM Aaron M. Ucko wrote:
> Source: ratpoints
> Version: 2.1.3+dfsg-1
> Severity: serious
> Justification: fails to build from source
>
> Builds of ratpoints in minimal environments (as on the autobuilders)
> have been failing:
>
> checking for GMP includes in /usr/inclu
severity 710210 minor
severity 710211 minor
thanks
Downgrading as discussed previously.
On July 2, 2013 03:57:46 AM Daniel Hartwig wrote:
> > I can guess you are concerned that this compiler warning causes a
> > build failure for other packages that treat errors as warnings. I
> > agree this i
Hi Daniel,
I'd like some more information regarding these two bugs, where Boost
has defined but not used a local typedef.
On Fri, Jun 14, 2013 at 09:24:20AM +0800, Daniel Hartwig wrote:
> severity 710210 serious
> severity 710211 serious
So a "serious" bug is defined as: a severe violation of De
On June 9, 2013 02:18:42 PM Yaroslav Halchenko wrote:
> Package: libinsighttoolkit4.3
> Version: 4.3.2-1
> Severity: grave
>
> dicom2nifti FTBFS because of
>
> The following packages have unmet dependencies:
> libinsighttoolkit4.3 : Depends: libminc2-1 which is a virtual package.
Thanks ... I h
On Fri, May 24, 2013 at 01:34:22AM +0600, Andrey Rahmatullin wrote:
> On Sat, May 18, 2013 at 07:39:48PM +0200, David Suárez wrote:
> > > PionScheduler.cpp:105:40: error: expected unqualified-id before numeric
> > > constant
> The code:
> boost::xtime_get(&wakeup_time, boost::TIME_UTC);
>
> Accor
On May 14, 2013 06:01:26 AM Petr Salinger wrote:
> tags 706984 +patch
> --
>
> > The last gmp upload failed to build on hurd-i386 and kfreebsd-i386
> > and I could use some help.
Petr: thanks!
Which architecture did you test with?
-Steve
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@l
severity 691635 normal
thanks
On October 27, 2012 02:35:38 PM Sebastian Ramacher wrote:
> Package: libboost-mpi-python1.49.0
> Version: 1.49.0-3.1
> Severity: grave
I did not see any information that would support "grave" severity (see
http://www.debian.org/Bugs/Developer#severities) in the repo
On August 31, 2012 06:47:07 PM Aaron M. Ucko wrote:
> The i386 build of insighttoolkit4 ran into test suite errors:
>
> The following tests FAILED:
> 619 - itkFFTWF_FFTTest (SEGFAULT)
> 620 - itkFFTWF_RealFFTTest (SEGFAULT)
> 621 - itkVnlFFTWF_FFTTest (SEGFAULT)
> 622 -
On Tue, May 08, 2012 at 09:26:40PM +0200, Julien Cristau wrote:
> > > As I'd like this fixed ASAP to get the buildds back in working
> > > condition, I'll be preparing a NMU with --disable-fat. Please yell if
> > > you think I shouldn't upload it.
Thanks for this.
-Steve
signature.asc
Descrip
On Mon, May 07, 2012 at 11:54:18PM +0200, Julien Cristau wrote:
> On Mon, May 7, 2012 at 21:35:58 +0200, Laurent Fousse wrote:
>
> > Hello,
> >
> > * Julien Cristau [Mon, May 07, 2012 at 06:08:40PM +0200]:
> > > it looks like the update from gmp 2:5.0.4+dfsg-1 to 2:5.0.5+dfsg-1
> > > causes gcc
reassign 664188 gdcm
thanks
Mathieu: this happens only on some architectures; see the buildd logs.
Can you help?
Thanks,
-Steve
On Fri, Mar 16, 2012 at 11:42:59AM +0100, Moritz Muehlenhoff wrote:
> Package: insighttoolkit
> Version: 3.20.1-5
> Severity: serious
>
> Your package fails to build f
Package: libgmp10
Version: 2:5.0.3+dfsg-1
Severity: grave
File: libgmp
Tags: upstream
Date: Tue, 31 Jan 2012 10:31:41 +0100
From: Torbjorn Granlund
To: gmp-annou...@gmplib.org
Subject: Buffer overrun in GMP 5.0.3
We have a buffer overrun in GMP 5.0.3, furthermore the functions
affected are mpz_p
Hi,
I'd like to contribute towards a solution for this. I'm forwarding to
debian-devel to get some others' ideas.
On Wed, Feb 01, 2012 at 09:57:39AM +0100, Sylvestre Ledru wrote:
> Le mardi 31 janvier 2012 à 21:56 -0600, Steve M. Robbins a écrit :
> > Naively, I don
52798.
+
+ -- Steve M. Robbins Tue, 31 Jan 2012 23:40:50 -0600
+
python-visual (1:5.12-1.3) unstable; urgency=low
* Non-maintainer upload.
diff -u python-visual-5.12/debian/patches/series python-visual-5.12/debian/patches/series
--- python-visual-5.12/debian/patches/series
+++ python-visual-5.12/d
1 - 100 of 331 matches
Mail list logo
