Bug#873569: ITP: libmediawiki -- KDE C++ interface for MediaWiki based web service
Package: wnpp Severity: wishlist Owner: "Steve M. Robbins" * Package name: libmediawiki Upstream Author : Team maintained; see https://github.com/KDE/libmediawiki/blob/master/AUTHORS * URL : https://cgit.kde.org/libmediawiki.git * License : GPL Programming Lang: C++ Description : KDE C++ interface for MediaWiki based web service This framework provides access to the API of MediaWiki (http://www.mediawiki.org) based web services such as wikipedia (http://www.wikipedia.org). This package is an optional dependency of DigiKam, needed to allow photo export to a MediaWiki site. Will maintain this within the Debian KDE Extras Team.
Re: HEADSUP: mails sent to n...@bugs.debian.org are NOT sent to the submitter
Fully support Ian's proposed change. I've been around Debian for 16 years and I STILL find this behaviour irritating because it is contrary to my expectations. -Steve signature.asc Description: This is a digitally signed message part.
Re: "PIE by default" transition is underway -- wiki needs updating
On Wed, Oct 26, 2016 at 05:26:24AM +0200, Guillem Jover wrote: > My point was that, yes we have changed to generating relocatable code > but that is still targetted for executables only, which preserves the > current behavior, [...] But something must have changed with how a static lib is now compiled, because (a) I see bug reports saying "foo broke because static libbar is not -fPIC" and (b) the recommended fix is to rebuild libbar with the new toolchain -- with no source changes. So what's going on with static libs? Thanks, -Steve signature.asc Description: PGP signature
"PIE by default" transition is underway -- wiki needs updating
Hi, I haven't been paying close attention to the "PIE by default" [1] discussions, so I may have missed the memo, but: it seems the transition is underway? I've seen two bugs already claiming "static library foo must be compiled with -fPIC" -- because some reverse dependency now fails to build. But I think this advice is misplaced. The Ubuntu page [2] says that all you need to do is rebuild the library foo with the PIE-enabled compiler, then rebuild the depending code: Relocation Linking Failure A dynamically linked program that pulls in a static library that was not built with -fPIC. These give an error like: relocation R_X86_64_32 against '[SYMBOL]' can not be used when making a shared object; recompile with -fPIC To address these types of issues, the package providing the static object needs to be rebuilt (usually just a no-change rebuild against the pie-by- default compiler) before rebuilding the failed package. So it seems to me that this should be emphasized on the wiki [1]. Secondly, it seems that the proposal to change policy to encourage -fPIC on static libraries [3] is misplaced and should be withdrawn.Are both these statements accurate? Thanks, -Steve [1] https://wiki.debian.org/Hardening/PIEByDefaultTransition [2] https://wiki.ubuntu.com/SecurityTeam/PIE [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837478 signature.asc Description: This is a digitally signed message part.
uscan download from sourceforge doesn't download what you expect!
... at least not for boost. I downloaded the latest release manually by following the links from boost.org to https://sourceforge.net/projects/boost/files/boost/1.62.0/ boost_1_62_0.tar.bz2/download Then I remembered that Dimitri had written a watch file to use the Files- Excluded facility. So I ran uscan. This leaves me the original download as well as the re-packed tarball. Comparing the original download to my manual download indicated many differences. Running uscan with --verbose led me to the reflector page https:// qa.debian.org/watch/sf.php/boost/ used by uscan. The boost_1_62_0.tar.bz2 link on that page leads to https://sourceforge.net/projects/boost/files/boost/ snapshots/master/boost_1_62_0.tar.bz2/download Notice the crucial difference: the reflector is using "boost/snapshots/master" whereas the correct URL uses "boost/1.62.0". The snapshots are pulled from the branch tip and are NOT actual releases. So the reflector is listing bad URLs. Who can I contact to get https://qa.debian.org/watch/sf.php/boost/ fixed? Note: I didn't look, so I have no idea if this is a widespread problem with the watch reflector. I'd suggest that people do a spot-check on their own packages to see. Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Bug#838150: ITP: itktools -- command line tools based on the ITK, intended for image processing
Package: wnpp Severity: wishlist Owner: "Steve M. Robbins" * Package name: itktools Version : 0.3.2 Upstream Author : Marius Staring, Stefan Klein, David Doria * URL : https://github.com/ITKTools/ITKTools * License : Apache 2.0 Programming Lang: C++ Description : command line tools based on the ITK, intended for image processing Practical command line tools based on the ITK, intended for image processing. These tools are designed to take one or more input image(s) from the command line, perform a single operation, and produce an output image. For example smoothing of an image can be done with the tool pxgaussianimagefilter. Note: these tools (specifically pxcastconvert) are required to run the Elastix test suite.
Bug#808434: ITP: libkgeomap -- Libkgeomap is a wrapper around different world-map components, to browse and arrange photos over a map.
Package: wnpp Severity: wishlist Owner: "Steve M. Robbins" * Package name: libkgeomap Version : 15.12.0 Upstream Author : Several; part of Digikam/KDE project * URL : https://github.com/KDE/libkgeomap * License : GPL v2+ Programming Lang: C++ Description : Libkgeomap is a wrapper around different world-map components, to browse and arrange photos over a map. Libkgeomap is a wrapper around world map components as Marble, OpenstreetMap and GoogleMap, for browsing and arranging photos on a map This library is used by kipi-plugins, digiKam and other kipi host programs. This is a dependency for digikam. It used to be part of digikam's source but has been split out.
GCC 5 / libstdc++ abi wiki: can FIXMEs be fixed?
Hi, I've heard rumours that GCC 5 is coming :-) I help maintain several C++ libraries and expect some work is required to get through this GCC transition. I'd like to understand what I'm doing and do it right the first time. I'm just an average C++ programmer, not an avid follower of GCC nor even of debian lists. So below are lots of questions asked out of ignorance. Please don't shoot the messenger/questioner. :-) Posts here and bug reports reference the wiki page https://wiki.debian.org/GCC5 . I've read that page and there are a bunch of notes embedded within it that just confuse me: 1. "The good news is, that GCC 5 now provides a stable libcxx11 ABI, and stable support for C++11 (GCC version before 5 called this supported experimental). This required some changes in the libstdc++ ABI, and now libstdc++6 provides a dual ABI, the classic libcxx98 ABI, and the new libcxx11 (FIXME: GCC 5 (<< 5.1.1-20) only provides the classic libcxx98 ABI)." What does the FIXME refer to? That the correct statement is "The good new is, that GCC 5 (post 5.1.1-20) now provides .."? Or something else? 2. "libstdc++ doesn't change the soname, provides a dual ABI. Existing C++98 binary packages will continue to work. Building these packages using g++-5 is expected to work after build failures are fixed. FIXME: Will they only work when built with _GLIBCXX_USE_CXX11_ABI set to 0? By default they will use the new libstdc++ ABI." What's the answer to this FIXME? What does the last sentence mean? Does it mean that code built using g++5 by default uses the new libstdc++ ABI? But if not rebuilt, existing code will use the existing libcxx98 ABI? The next paragraph says "GCC 6 is expected to change the c++ standard default ..." -- but doesn't GCC 5 change the standard default already? 3. "Library packages built using -std=c++0x or -std=c++11 may have an ABI change (unknown yet how many). How to find out about these?" What does this mean? Why would they have an ABI change? And how do we find out? 4. "If the library exports some symbols having either _cxx11 or B5cxx11 in the symbol name, it may be incompatible, if these are symbols which form part of the public API. To find out if these are part of the public API, you would need to build all reverse dependencies and see if any of these new symbols are referenced." Being pedantic: isn't that a signal of ABI (rather than API) change? More importantly: supposing my library does export some such symbols. Checking reverse deps in Debian is of course helpful: if any are referenced, then we know the interface changed (or does it? what if the reverse-dep uses the symbol itself internally -- might this show a false-positive?) But if none are found, can we conclude the interface has NOT changed? I wouldn't think so: it may simply be that the code in Debian simply doesn't exercise the relevant part of the interface. If that is the case: how then can one convince themself that there really is no change in interface? Additionally, there are some places where the text confuses me even without FIXME or README: * "Using different libstdc++ ABIs in the same object or in the same library is allowed, as long as you don't try to pass std::list to something expecting std::cxx11::list or vice versa. We should rebuild everything with g++-5 (once it is the default). Using g++-4.9 as a fallback won't be possible in many cases." The first sentence doesn't seem connected to the second two sentences. What does "Using g++-4.9 as a fallback ..." mean? Why isn't it possible? What cases fail? * In "Roadmap for libstdc++", it says "Depending on which libstdc++ ABI is configured as default ...". What is the plan now? Which ABI will be default? * Section "libstdc++ c++11 incompatibilities (4.9 and 5)" has a short list of incompatibilities. Is this the complete list or just examples? * "Passing std::list to something expecting std::cxx11::list or vice versa." Is this an incompatibility just regarding C++11 in 4.9 and 5? What if C++11 code (built with GCC5) passes a list to an old library built using the libcxx98 ABI? Wouldn't that also fail? Thanks for reading this far! -Steve signature.asc Description: This is a digitally signed message part.
Re: Debian upload but no email response ?
On June 10, 2015 12:26:22 AM Gert Wollny wrote: > at least geomview is still in the upload queue [1]. It seems that the > *.changelog file is missing. Maybe your upload didn't finish properly? The problem turned out to be that I mistakenly used my old key. Thanks to Ansgar for pointing me in the right direction. I've uploaded both again with the proper key and they were duly processed. -Steve signature.asc Description: This is a digitally signed message part.
Debian upload but no email response ?
Hi, It used to be that after I "dput" an upload, I'd get an email within the hour saying my upload was received. I have made two uploads this week but saw no such email. I can see that the emails are still being generated [1]. This is my first upload since the last release freeze started. Has something changed in the meanwhile? Both uploads were new sources so I'd also expect to see them in the NEW queue [2] but they aren't there. The source packages are ipe-tools and geomview. Any hints? Thanks, -Steve [1] http://lists.alioth.debian.org/pipermail/debian-science-maintainers/2015-June/030854.html [2] https://ftp-master.debian.org/new.html signature.asc Description: This is a digitally signed message part.
Re: Non-source Javascript files in upstream source (was: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699)
On April 25, 2014 11:02:29 PM Ben Finney wrote: > Neil Williams writes: > > On Fri, 25 Apr 2014 01:16:04 +0100 > > > > Manuel A. Fernandez Montecelo wrote: > > > I don't think that we should go and do the tedious work of repack > > > thousands of packages because of this, with no real benefit in terms > > > of freedom (or any other) for our users -- provided that we depend > > > and link to the canonical versions in the binary packages. > > We promise the source for everything any recipient downloads as part of > Debian. If non-source files are distributed in Debian source packages, > without a way to confidently guarantee the corresponding source is > what's already available in Debian, then that is a definite impact on > the freedom of Debian recipients: it threatens the freedom promises in > the Social Contract. That is certainly not a universally held view. Some of us [1] regard random trash littering the source distribution -- but not used in generating the actual software (binary distribution) -- as merely a nuisance that can be tolerated. I have to say that this absolutist zeal in scrubbing the source package grates on me for two reasons. FIrst, it introduces an undocumented difference between upstream source and Debian source. Second, it adds a bunch of busywork that distracts and, frankly, de-motivates me from working on packaging. [1] https://lists.debian.org/debian-devel/2014/03/msg00270.html -Steve signature.asc Description: This is a digitally signed message part.
Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
On April 25, 2014 04:40:26 PM Neil Williams wrote: > Jeroen Dekkers wrote: > > part. But if the minified javascript files in the upstream tarball > > aren't used when building the binary packages because the javascript > > libraries are already packaged in Debian, then it isn't possible that > > something bad sneaks in our packages. So why repack the upstream > > tarball? > > > > I don't really see any value in repacking every upstream tarball that > > has a minified copy of jQuery. > > For one thing it makes it *a lot* simpler to scan the archive for > exactly the kind of problem you describe and we all need to avoid. That sounds like you you're asking N developers to do a bunch of extra busywork so that 1 person's job is made easier. Here's an alternative: if you can indeed scan the archive for bad files, add that detector to the archive- rebuilding project and do this: 1. Unpack 2. Remove bad files 3. Build If it still builds after removal, you have proved the bad file is not used. > Secondly it makes it simple for people working from the Debian source > package to check and debug the package without needing a build step and > without possible confusion about which file gets used. Perhaps, but again there's a simpler alternative: remove the bad file in the "clean" target. That proves to the reader of debian/rules that the bad file is not used. > Finally, there is the issue that these minified JS files are not source > code and we should not be distributing files in source packages for > which there is no source code in that same source package. I think this absolutist view was eloquently debunked by Russ Allbery recently; see https://lists.debian.org/debian-devel/2014/03/msg00270.html In summary: yes, such files should not be used to generate the binary and they are a nuisance to have in the source package, but a nuisance is all it is. -Steve signature.asc Description: This is a digitally signed message part.
Re: jquery debate with upstream
On March 12, 2014 03:29:52 PM Didier 'OdyX' Raboud wrote: > Le mercredi, 12 mars 2014, 12.58:51 Ian Jackson a écrit : > > If an interpretation of the DFSG suggests that we should be doing work > > which does not further those objectives, then I think that > > interpretation is a misreading. > > SC§1 states that we want Debian to remain 100% free; the common > interpretation of that is that one can download anything from Debian > main and only get DFSG-free material; I think our sources are held to > the same expectation. That's never been my expectation, FWIW. I do agree with Ian that this is stretching the goals of the project, at least as I perceive them. -Steve signature.asc Description: This is a digitally signed message part.
Re: jquery debate with upstream
On Tue, Mar 11, 2014 at 02:34:47PM -0400, Paul Tagliamonte wrote: > You may think a line is somewhere, but the DFSG is interpreted by the > ftp-masters, so the question isn't what paultag or ian says, but what > the ftp-masters say :) I don't accept that. The interpretation must come from a concensus of Debian Developers. Regards, -Steve signature.asc Description: Digital signature
Re: jquery debate with upstream
On March 11, 2014 10:50:10 AM Paul Wise wrote:
> On Tue, Mar 11, 2014 at 7:43 AM, Ben Finney wrote:
> > I'd love to see clarification of the ftp-team's position on obfuscated
> > files in source packages, preferably in an official location for future
> > reference.
Recalling that the context of the question was whether "it is acceptable to
leave ${some file} in a tarball if it is unused" ...
> Source missing
>
> Your package contains files that need source but do not have it. These
> include PDF and PS files in the documentation, or auto-generated
> files.
... I guess if a file is not needed for the build, then that file does not
"need source" either.
> Generated files
>
> Your package contains generated files (such as compressed .js
> libraries) without corresponding original form. They're not considered
> as the preferred form of modification,
Nor would it need to be modified, so it shouldn't matter that it's not the
"preferred form for modification".
I can understand that it is nicer if upstream can be persuaded to clean things
up and not do either of the above. I also realize that some folks may prefer
to re-pack a tarball for "cleanliness" objectives. But are you really
suggesting a distributable but "non source" file in the tarball can't simply be
ignored? What objective would that serve?
Regards,
-Steve
signature.asc
Description: This is a digitally signed message part.
Re: jquery debate with upstrea
On March 10, 2014 06:27:01 PM Joachim Breitner wrote: > Also, am I too pragmatic in suggesting that we should accept non-source > files in tarballs if they are legally distributed and not used during > the build (especially not included in the binary packages)? I generally take that approach. If there's a concern about tainting the binary package, then I put a rule in debian/rules to make sure the offending file is removed before building. -Steve signature.asc Description: This is a digitally signed message part.
Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing
On September 21, 2013 09:04:23 PM Bernhard R. Link wrote: > * Kees Cook [130921 17:08]: > > In a theoretical sense, sure. In this particular case, why bother breaking > > it when it's a trivial 1 line fix? My original approach was to fix it in > > libc and do a mass bug filing. Everyone wins. If we want to reject the > > undefined behavior, we should modify the compiler to reject it. Seems to > > me > > it's a bug to even allow undefined behavior. > > The whole point of undefined behaviour in C is that the > compiler/implementor/... does not have to care. I strongly suspect the "whole point" of undefined behaviour is simply that at least two parties on the committee simply couldn't agree on "correct" behaviour. > Checking every time would > make it slower, What are you referring to as "it"? The compiler? Checking that two arguments to a function are the same doesn't strike me as terribly expensive. > requesting any specific behaviour would make it slower. Nonsense -- it has a specific behaviour now. Since the standard says it is undefined, there's nothing stopping us from reverting back to its old behaviour which, arguably, better mached people's expectations -- else they wouldn't have written the "buggy" code. Moreover, it is the same behaviour used when NOT compiled with _FORTIFY_SOURCE=2. -Steve signature.asc Description: This is a digitally signed message part.
Re: Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Philipp Kern wrote: > Thanks for trading the R release cycle with Debian's and for > delaying the release. The harm has already been done, so somebody > should probably go and create a transition tracker for it? Rather than accept the harm, surely the release team could simply roll back the upload in some manner? Wonderingly, -Steve signature.asc Description: Digital signature
Re: pbuilder + ccache suddenly fails
On Sat, Jun 02, 2012 at 12:08:24PM -0500, Steve M. Robbins wrote: > How do I disable ccache inside pbuilder? OK, I figured this out. The workaround is detailed in #675691. Cheers, -Steve signature.asc Description: Digital signature
Re: pbuilder + ccache suddenly fails
On Sun, May 06, 2012 at 05:33:10PM -0400, Andres Mejia wrote: > On Sun, May 6, 2012 at 2:40 PM, Steve M. Robbins wrote: > > On Sun, May 06, 2012 at 01:21:57PM -0400, Andres Mejia wrote: > >> On Sat, May 5, 2012 at 9:57 PM, Steve M. Robbins wrote: > >> > I've routinely used pbuilder to build packages for years. > >> > Yesterday, I have started to see the following failure: > >> > > >> > ccache: FATAL: Failed to create /var/cache/pbuilder/ccache/0/f: > >> > Permission denied This hit me again. Is no-one else experiencing this? > Part of the reason to use pbuilder or sbuild is to build packages in a > clean chroot. Providing ccache support in this way isn't clean and > apparently it's prone to problems such as the bug you pointed out. See > also [1]. > > If you're going to upload to the archive, simply disable ccache. As I explained: I have neither enabled nor disabled ccache within pbuilder, nor have I changed my pbuilder practices. This had never happened to me prior to a month ago. Has something changed in pbuilder or ccache in the last few months to account for this? How do I disable ccache inside pbuilder? Thanks, -Steve > > 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430765#35 > > -- > ~ Andres > signature.asc Description: Digital signature
Re: Bug#675577: libgmp-dev: arch-dependent files in "Multi-Arch: same" package
On Sat, Jun 02, 2012 at 10:54:13AM +0200, Jakub Wilk wrote: > Package: libgmp-dev > Version: 2:5.0.5+dfsg-2 > User: multiarch-de...@lists.alioth.debian.org > Usertags: multiarch > > libgmp-dev is marked as "Multi-Arch: same", but the following files > are architecture-dependent: > > /usr/include/gmp-arm.h > /usr/include/gmp-i386.h > /usr/include/gmp-mips.h > /usr/include/gmp-x86_64.h True, but only one such file exists in each arch's build. I was told this is acceptable as long as any file name that is shared among architectures has the same contents [1] (which is the case). Who is right? [1] http://lists.alioth.debian.org/pipermail/debian-science-maintainers/2012-May/013450.html Thanks, -Steve signature.asc Description: Digital signature
Re: pbuilder + ccache suddenly fails
On Sun, May 06, 2012 at 01:21:57PM -0400, Andres Mejia wrote: > On Sat, May 5, 2012 at 9:57 PM, Steve M. Robbins wrote: > > I've routinely used pbuilder to build packages for years. > > Yesterday, I have started to see the following failure: > > > > ccache: FATAL: Failed to create /var/cache/pbuilder/ccache/0/f: Permission > > denied > You should instead not enable ccache inside builds using pbuilder or > sbuild since the directories where these builds occur end up being > deleted, thus deleting the output generated from ccache. I haven't been explicitly using ccache inside pbuilder. In fact, I just put a build-conflict against ccache to avoid using it (#671173). Two years ago, pbuilder itself added support for ccache: pbuilder (0.197) unstable; urgency=low * Add builtin support for using ccache in pbuilder and enable it by default. Ship a new /var/cache/pbuilder/ccache dir and bind-mount and chown it to BUILDUSERID at build time. Install/remove ccache automatically on create/update if CCACHEDIR is set/unset. Update docs and remove old ccache config example. Add a NEWS entry featuring the change. Stop intalling ccache sample config -- Junichi Uekawa Wed, 23 Jun 2010 07:21:11 +0900 I haven't done anything different recently so I'm quite mystified by my recent trouble. To work around this, I simply gave the world write permissions on /var/cache/pbuilder/ccache. Thanks, -Steve signature.asc Description: Digital signature
pbuilder + ccache suddenly fails
I've routinely used pbuilder to build packages for years. Yesterday, I have started to see the following failure: ccache: FATAL: Failed to create /var/cache/pbuilder/ccache/0/f: Permission denied Any idea what's going on? Google found only one other mention of this [1]. Thanks, -Steve [1] http://lists.debian.org/debian-mentors/2012/02/msg00490.html signature.asc Description: Digital signature
Time to remove 32/64-bit variants of GMP?
Similar to a recent question from J. Berkenbilt [1], I'd like to understand whether there is still value in producing 32- and 64-bit variants of the GMP packages. GMP is already Multi-Arch enabled, but it still produces a 32-bit library for certain 64-bit architectures and, similarly, a 64-bit library for certain 32-bit architectures. Can a package from 32-bit i386 be used on amd64 instead of lib32gmp? And similarly for other architectures? Recently, I've been given a patch set to build lib64gmp10 on sparc. I'd rather rely on multiarch for this, if possible. Thanks, -Steve [1] http://lists.debian.org/debian-devel/2012/03/msg00762.html signature.asc Description: Digital signature
Re: Bug#657949: Cannot install libhdf5-mpi-dev and libnetcdf-dev
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't understand why netcdf can't offer multiple variants, > > just as hdf5 does. Or, at least, one package libnetcdf-mpi-dev that > > links with the "default" MPI implementation. > I am not involved in the netcdf. You should report a bug on this > package. I'm prepared to do so, but I'd first like to get agreement that netcdf is where the problem lies. Netcdf maintainers, please chime in! On Wed, Feb 01, 2012 at 05:44:49PM +0100, Francesco P. Lovergine wrote: > On Tue, Jan 31, 2012 at 04:41:06PM +0100, Sylvestre Ledru wrote: > > Even if I am not happy about this change, it is expected. > > libnetcdf-dev depends on libnetcdf7 which depends on libhdf5-7. > > libhdf5-openmpi-7 conflicts with libhdf5-7. > > > > Before I had the silly idea to become a hdf5 maintainer, I reported this > > bug myself #591346. > > For now, I haven't find the right solution to tackle this issue ... > > Suggestions are welcome. > > > > The solution is having upstream adopting a sane naming scheme for mpi-enabled > flavor libraries instead of using always the same names for all. Francesco, please clarify: are you speaking of the hdf5 upstream or the netcdf upstream? (Both?) What problem are you trying to solve with that: co-installable -dev packages or just coinstallable lib packages? > Unfortunately they were still not available for that at the time of > my last poking. Diverging from upstream is not a good idea, so we > still have to live in a non perfect world... I think we can no longer live in the status quo (see all the blockers of #631019), so something has to give. Even if it is painful, perhaps Debian could pioneer something and pass patches back to upstream? Thoughts? -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Boost defaults change (1.46.1 --> 1.48)
On Wed, Dec 28, 2011 at 12:47:34PM +0100, Rene Engelhard wrote: > But what worries me more is that you AGAIN ignored > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652681. I was working off a rebuild of SID. Perhaps my last message didn't clearly state that. So all the bugs reported were for the SID versions of the package. 652681 concerns a newer version found only in experimental as far as I know. That's not to say that I don't think the bug is important. It is important. > Ignoring > #652681 doesn't make the build failure on the version which is > supposed to be in wheezy go away... Of course. So if you want my advice, here is what I would do about it. First, to help the gcc maintainers, complete the bug report according to . Second, when the time comes to upload libreoffice 3.5 to unstable, select one of the two following options: 1. If 652681 is fixed, upload as-is. 2. If not, change boost build-deps to 1.46 version and upload. Hope this helps, -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Boost defaults change (1.46.1 --> 1.48)
On Tue, Dec 27, 2011 at 11:20:16AM -0600, Steve M. Robbins wrote: > On Tue, Dec 27, 2011 at 04:45:21PM +0100, Lucas Nussbaum wrote: > > On 26/12/11 at 22:40 -0600, Steve M. Robbins wrote: > > > > It would be quite helpful to do a rebuild of the 237 boost reverse > > > dependencies. Lucas Nussbaum seems to be able to do this: can you run > > > a rebuild with updated boost-defaults? > > > > I already did that, since i did a rebuild while boost-defaults was > > pointing to .46. You can find the results in collab-qa svn, in > > archive-rebuilds/2011-12-20-lsid64-amd64 OK, with thanks to Lucas Nussbaum for the build results, I can report that only the following 23 of 237 boost rdep packages failed to build with boost-defaults pointing to 1.48. This shouldn't take a lot of effort to bring down to a manageable level and it looks like bugs are already filed. I'm bcc'ing this email to maintainers of the list of packages, below. Each of you, I'd appreciate it if you could check with the upstream authors whether a fix is already available. Please send an update to the appropriate bug with the upstream response or mark the bug forwarded to the upstream issue. I'm hoping that some of these can be fixed very quickly and we'll shortly know the true impact of a boost defaults change. Thanks very much, -Steve agave 0.4.7-2 Failed [GCC_ERROR] #564850 RECHECK anytun 0.3.3-2.1 Failed [GCC_ERROR] #652767: anytun: FTBFS: syncServer.cpp:112:92: error: 'boost::asio::ip::tcp::acceptor' has no member named 'io_service' drizzle 2011.03.13-1 Failed [UNKNOWN] #647743 ember 0.5.7-1.1 Failed [BUILDDEPS] #629767: ember: FTBFS: build-dependency not installable: libceguiogre-dev RECHECK fgrun 1.6.0-1 Failed [UNKNOWN] #652775: fgrun: FTBFS: Singleton.hxx:4:43: fatal error: boost/pool/detail/singleton.hpp: No such file or directory flightgear 2.4.0-1 Failed [UNKNOWN] #652797: flightgear: FTBFS: Singleton.hxx:4:43: fatal error: boost/pool/detail/singleton.hpp: No such file or directory gnuradio 3.2.2.dfsg-1.1 Failed [UNKNOWN] #642716: gnuradio: FTBFS: gr_vmcircbuf_createfilemapping: createfilemapping is not available RECHECK gpsdrive 2.10~pre4-6.dfsg-5.1 Failed [GCC_ERROR] #646446: gpsdrive: FTBFS: mapnik.cpp:33:15: error: 'mapnik::Image32' has not been declared RECHECK libreoffice 1:3.4.4-2 Failed [GCC_ERROR] #652784: libreoffice: FTBFS: acceleratorcache.cxx:64:29: error: no match for 'operator=' in '((framework::AcceleratorCache*)this)->framework::AcceleratorCache::m_lCommand2Keys = rCopy.framework::AcceleratorCache::m_lCommand2Keys' openvrml 0.18.8-5 Failed [GCC_ERROR] #652790: openvrml: FTBFS: scope_guard.hpp:122:29: error: 'boost::mpl' has not been declared ovito 0.9.2-1 Failed [UNKNOWN] #652795: ovito: FTBFS: usr/include/boost/type_traits/detail/has_binary_operator.hp:50: Parse error at "BOOST_JOIN" pinot 0.96-1.1 Failed [GCC_ERROR] #652786: pinot: FTBFS: Memory.h:184:11: error: 'singleton_default' in namespace 'boost::details::pool' does not name a type python-visual 1:5.12-1.3 Failed [GCC_ERROR] #652798: python-visual: FTBFS: random_device.cpp:30:63: error: 'const result_type boost::random::random_device::min_value' is not a static member of 'class boost::random::random_device' qt-gstreamer 0.10.1-2 Failed [UNKNOWN] TODO NEWFAIL salome 5.1.3-12 Failed [BUILDDEPS] #629765: salome: FTBFS: build-dependency not installable: sip4 RECHECK scenic 0.6.3-1 Failed [UNKNOWN] #615772 RECHECK simgear 2.4.0-1 Failed [UNKNOWN] #652788: simgear: FTBFS: ../../simgear/structure/Singleton.hxx:4:43: fatal error: boost/pool/detail/singleton.hpp: No such file or directory smc 1.9-4 Failed [UNKNOWN] #646464: smc: FTBFS: audio/../core/../objects/../objects/../video/video.h:26:62: fatal error: RendererModules/OpenGLGUIRenderer/openglrenderer.h: No such file or directory RECHECK spring 0.82.7.1+dfsg1-3 Failed [GCC_ERROR] #652768: spring: FTBFS: FPUSettings.h:322:15: error: expected unqualified-id before '__const' sslsniff 0.8-2 Failed [GCC_ERROR] #652756: sslsniff: FTBFS: SSLConnectionManager.cpp:47:74: error: 'boost::asio::ip::tcp::acceptor' has no member named 'io_service' strigi 0.7.6-2 Failed [UNKNOWN] #618118: strigi: FTBFS: dh_makeshlibs: dpkg-gensymbols -plibsearchclient0 -Idebian/libsearchclient0.symbols.amd64 -Pdebian/libsearchclient0 returned exit code 1 RECHECK wesnoth-1.8 1:1.8.6-1 Failed [GCC_ERROR] #652765: wesnoth-1.8: FTBFS: noncopyable.hpp:27:7: error: 'boost::noncopyable_::noncopyable::noncopyable(const boost::noncopyable_::noncopyable&)' is private witty 3.1.10-1 Failed [GCC_ERROR] #642674: witty: FTBFS: WPdfImage.C:74:30: error: 'HPDF_UseUTFEncodings' was not declared in this scope RECHECK signature.asc Description: Digital signature
Re: Boost defaults change (1.46.1 --> 1.48)
On Tue, Dec 27, 2011 at 06:32:16PM +, Adam D. Barratt wrote: > On Tue, 2011-12-27 at 10:52 -0600, Steve M. Robbins wrote: > > On Tue, Dec 27, 2011 at 10:42:07AM +0100, Rene Engelhard wrote: > > > Will 1.46 be around long enough that reverting to 1.46 is an option there? > > > > Absolutely, 1.46 is an option. That's why I suggested it. Debian has > > been releasing with at least two boost versions for a while now. The > > less-up-to-date version is often dictated by needs of other packages, > > such as libreoffice. > > fwiw, Squeeze shipped with only one boost version (1.42). I stand corrected. [I mostly pay attention to unstable, which has generally had two versions available for a long while. I'm going to avoid making absolute statements now :-)] -Steve signature.asc Description: Digital signature
Re: Boost defaults change (1.46.1 --> 1.48)
On Tue, Dec 27, 2011 at 04:45:21PM +0100, Lucas Nussbaum wrote: > On 26/12/11 at 22:40 -0600, Steve M. Robbins wrote: > > It would be quite helpful to do a rebuild of the 237 boost reverse > > dependencies. Lucas Nussbaum seems to be able to do this: can you run > > a rebuild with updated boost-defaults? > > I already did that, since i did a rebuild while boost-defaults was > pointing to .46. You can find the results in collab-qa svn, in > archive-rebuilds/2011-12-20-lsid64-amd64 Great, thanks! > If it's only 237 packages, I would prefer if you rebuilt them manually: > the time taken to organize the rebuild is likely to be higher than the > time it would take to just rebuild them locally. Note that I am starting from scratch. I know how to use pbuilder and how to manually download and build a package. At my present rate of 1-2 per week, it would take me several years to rebuild them all locally. Are there scripts &etc to automate this somewhere? Thanks, -Steve signature.asc Description: Digital signature
Re: Boost defaults change (1.46.1 --> 1.48)
On Tue, Dec 27, 2011 at 11:28:14AM +0100, Thomas Krennwallner wrote: > As long as something depends on 1.46, I assume that it should be > around. The current situation is sub-optimal, because almost everything > depends on the non-versioned boost libs of boost-defaults, despite > boost's tendency to break packages when switching to a new version. In fairness, boost doesn't break everything on each release, though it often feels like it :-). One issue with boost is that it is really a conglomeration of several dozen libraries, some of which are quite stable. Others are less so, sometimes by intention, sometimes inadvertently. The other big issue with boost is they have an agressive release schedule of 4 times/year. > The question is, which strategy is better? > > (1) Clearly record the dependencies in packages that depend on boost, > i.e., Build-Depends on libboost-foo1.46-dev instead of > libboost-foo-dev, or > (2) let boost-defaults decide which version of boost is the currently > stable boost. > > IMHO (2) just hides FTBSes of the packages. I will offer a third strategy: (3) Offer boost-defaults for: advanced users, for packages that generally stick to the stable parts of boost, for packages that or have upstream authors that track the latest boost. Other packages can build to versioned boost dev packages known to work. Due to the frequent boost releases, there is a large cost to using the versioned dependencies, so I encourage using the non-versioned packages when possible. This is an evolving process and I think we're still learning which category a given package might fall into. So it's not a surprise that some adjustments are necessary with each boost release. And, of course, there are the standard number of bugs in a given boost release so even if "unversioned devs" is the right strategy for a given package, a new boost may still break it until a boost bug is fixed. Regards, -Steve signature.asc Description: Digital signature
Re: Boost defaults change (1.46.1 --> 1.48)
On Tue, Dec 27, 2011 at 10:42:07AM +0100, Rene Engelhard wrote: > Hi, > > > I'd like to point out that any resulting build failures are quite easy > > to fix: either > > (a) contact package upstream for boost 1.48 changes; or > > It is? #652681 doesn't look like it. I'll just note that an Internal Compiler Error is always a bug in the compiler, by definition. It may be true that boost exposed it, but boost is not the cause of the compiler bug. It would be helpful if you provided more details for the gcc folks. > Will 1.46 be around long enough that reverting to 1.46 is an option there? Absolutely, 1.46 is an option. That's why I suggested it. Debian has been releasing with at least two boost versions for a while now. The less-up-to-date version is often dictated by needs of other packages, such as libreoffice. > At least libreoffice is affected by > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652784. > The upstream bug reports a "one-liner" fix of building with "-std=c++0x". Does that work for Debian? Cheers, -Steve signature.asc Description: Digital signature
Boost defaults change (1.46.1 --> 1.48)
Hello, The latest Boost (1.48) is now in testing, and I'd like to switch the defaults. My first plan was to simply announce the switch then make it. I did so and got an immediate email from the release team asking to revert the default change, which I did. On Tue, Dec 20, 2011 at 08:00:15PM -0600, Steve M. Robbins wrote: > On Mon, Dec 19, 2011 at 10:33:26PM +0100, Julien Cristau wrote: > > I heard of at least two failures in the last couple of hours: > > libreoffice (#652681), and wesnoth (#652677). As such, I'd appreciate > > if you could: > > - revert boost-defaults to 1.46 for the time being > > Done. > > > - test-build at least the most prominent reverse deps against 1.48 > > before bumping it again > > - contact debian-release before that bump, so we can coordinate a timing > > that doesn't suck with regards to other ongoing transitions. Now I'd like to coordinate a time for the change. I'd like to point out that any resulting build failures are quite easy to fix: either (a) contact package upstream for boost 1.48 changes; or (b) change the build-dependency from libboostfoo-dev to libboostfoo1.46-dev. It would be quite helpful to do a rebuild of the 237 boost reverse dependencies. Lucas Nussbaum seems to be able to do this: can you run a rebuild with updated boost-defaults? Thanks, -Steve signature.asc Description: Digital signature
Re: Heads-up: Boost defaults changing from 1.46 to 1.48
On Mon, Dec 19, 2011 at 10:33:26PM +0100, Julien Cristau wrote: > On Sat, Dec 10, 2011 at 21:23:49 -0600, Steve M. Robbins wrote: > > > Hi, > > > > Boost 1.48 was uploaded to sid about 9 days ago so it should > > transition to "testing" in the next day or so. > > > > My plan is to update the default boost version to 1.48 immediately > > following this transition. > > > > I'd appreciate feedback on any build failures with 1.48 for > > boost-using packages. > > > I heard of at least two failures in the last couple of hours: > libreoffice (#652681), and wesnoth (#652677). As such, I'd appreciate > if you could: > - revert boost-defaults to 1.46 for the time being Done. > - test-build at least the most prominent reverse deps against 1.48 > before bumping it again > - contact debian-release before that bump, so we can coordinate a timing > that doesn't suck with regards to other ongoing transitions. OK, will do. -Steve signature.asc Description: Digital signature
Heads-up: Boost defaults changing from 1.46 to 1.48
Hi, Boost 1.48 was uploaded to sid about 9 days ago so it should transition to "testing" in the next day or so. My plan is to update the default boost version to 1.48 immediately following this transition. I'd appreciate feedback on any build failures with 1.48 for boost-using packages. Thanks, -Steve signature.asc Description: Digital signature
Re: buildd machines vs. resource-hungry packages (ITK)
On Fri, Sep 16, 2011 at 10:06:58PM -0500, Steve M. Robbins wrote: > The main culprit behind the resource usage is the wrappers for Tcl, > Java, and Python. The underlying ITK codebase consists of heavily > templated C++ libraries. The wrapping process generates a huge amount > of code since many variants of each templated class are instantiated > and compiled. So after sending this, I think I have hit upon a solution by splitting into multiple source packages. It seems that the wrapping can be done by using the installed headers and libraries. So I can have the core source package build only the C++ libraries and also install the cmake files for wrapping (to /usr/src/WrapITK). Then I can create three new source packages, say: wraptitk-python, wraptitk-tcl, wraptitk-java that build-depends on the ITK -dev package (which provides /usr/src/WrapITK). Each wrapping package builds just one set of wrappers so the disc usage is only a third (maybe 3-4 GB if I don't use -g). The remaining stumbling block then would be memory and I may have to resort to other options mentioned in this thread: removing optimization or simply not building the wrappers for the less-capable architectures. Thoughts? -Steve signature.asc Description: Digital signature
buildd machines vs. resource-hungry packages (ITK)
Hi, I am having a huge problem getting insighttoolkit (ITK) to build due to the fact that it takes a huge amount of disk, memory, and time to build. In fact, the build is now generally failing because either disk or memory is exhausted. The main culprit behind the resource usage is the wrappers for Tcl, Java, and Python. The underlying ITK codebase consists of heavily templated C++ libraries. The wrapping process generates a huge amount of code since many variants of each templated class are instantiated and compiled. Up until the most recent upload, about 10 GB disk was required, which exceeds the capacity of several of the buildd machines, so builds were failing. Builds were also failing due to exhausting the buildd memory. Recently, it was suggested (#640667) that the memory issue was due to building the huge amount of wrapping code using -O3 and that it would be better to use -O2 instead; so upload (3.20.0-14) switched to -O2. However, I also turned on -g (as a side effect) and doubled the disk usage to 22 GB! Now it basically won't build anywhere :-( I can continue to fiddle with the compiler flags to reduce disk requirements. For example, I can remove -g again; however, ITK would still need 10 GB or so, more than some buildds provide. So something more is required. Any ideas? Thanks, -Steve signature.asc Description: Digital signature
Re: Anonymous read-only access and Vcs-* [Re: Alioth status update, take 3]
Tollef, > ]] Ben Finney > > | Neither the VCS repository link nor the VCS browse link work for > | http://packages.qa.debian.org/c/comixcursors.html>. > > These have been fixed now. > > | The VCS browse link doesn't work for > | http://packages.qa.debian.org/l/lojban-common.html>. > > Ditto. Great! Can the SVN ones be similarly fixed; e.g. http://packages.qa.debian.org/i/insighttoolkit.html Thanks, -Steve signature.asc Description: Digital signature
Re: glibc: causes segfault in Xorg
On Sat, May 07, 2011 at 12:25:15PM +0200, Aurelien Jarno wrote: > On Wed, May 04, 2011 at 02:30:35PM +0200, Aurelien Jarno wrote: > > Le 04/05/2011 07:42, Steve M. Robbins a écrit : > > > P.S. I tried rebuilding glibc myself locally, but gcc also segfaults > > > in the process :-( > > > > Are you sure it is something related? Which gcc version are you using? > > Do you have a backtrace point to the same issue? I was careless in my initial report; I should have specified that I tried rebuilding the *old* glibc and got a segfault. At this point, all I really know is that building the eglibc 2.11.2-11 Debian source package on my up-to-date sid amd64 machine fails: make[3]: Entering directory `/home/steve/tmp/old-eglibc/eglibc-2.11.2/sunrpc' CPP='gcc-4.4 -E -x c-header' /home/steve/tmp/old-eglibc/eglibc-2.11.2/build-tree/amd64-libc/elf/ld-linux-x86-64.so.2 --library-path /home/steve/tmp/old-eglibc/eglibc-2.11.2/build-tree/amd64-libc:/home/steve/tmp/old-eglibc/eglibc-2.11.2/build-tree/amd64-libc/math:/home/steve/tmp/old-eglibc/eglibc-2.11.2/build-tree/amd64-libc/elf:/home/steve/tmp/old-eglibc/eglibc-2.11.2/build-tree/amd64-libc/dlfcn:/home/steve/tmp/old-eglibc/eglibc-2.11.2/build-tree/amd64-libc/nss:/home/steve/tmp/old-eglibc/eglibc-2.11.2/build-tree/amd64-libc/nis:/home/steve/tmp/old-eglibc/eglibc-2.11.2/build-tree/amd64-libc/rt:/home/steve/tmp/old-eglibc/eglibc-2.11.2/build-tree/amd64-libc/resolv:/home/steve/tmp/old-eglibc/eglibc-2.11.2/build-tree/amd64-libc/crypt:/home/steve/tmp/old-eglibc/eglibc-2.11.2/build-tree/amd64-libc/nptl /home/steve/tmp/old-eglibc/eglibc-2.11.2/build-tree/amd64-libc/sunrpc/rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o /home/steve/tmp/old-eglibc/eglibc-2.11.2/build-tree/amd64-libc/sunrpc/xbootparam_prot.T make[3]: *** [/home/steve/tmp/old-eglibc/eglibc-2.11.2/build-tree/amd64-libc/sunrpc/xbootparam_prot.stmp] Segmentation fault (core dumped) The segfault is actually in the "ld-linux-x86-64.so.2" binary produced during the build, not gcc as I had earlier written. The backtrace is: (gdb) bt full #0 0x in ?? () No symbol table info available. #1 0x2b4d84d7e990 in call_init (l=, argc=7, argv=0x7fff26bf50a0, env=0x7fff26bf50e0) at dl-init.c:85 j = 1 jm = 4 init_array = 0x2b4d852ebb50 #2 0x2b4d84d7ea87 in _dl_init (main_map=0x2b4d84f90178, argc=7, argv=0x7fff26bf50a0, env=0x7fff26bf50e0) at dl-init.c:134 preinit_array = preinit_array_size = 0x0 i = 0 #3 0x2b4d84d71b2a in _dl_start_user () from /home/steve/tmp/old-eglibc/eglibc-2.11.2/build-tree/amd64-libc/elf/ld-linux-x86-64.so.2 No symbol table info available. #4 0x7fff26bf6574 in ?? () No symbol table info available. #5 0x0007 in ?? () No symbol table info available. #6 0x7fff26bf6825 in ?? () No symbol table info available. #7 0x7fff26bf6872 in ?? () No symbol table info available. #8 0x7fff26bf6875 in ?? () No symbol table info available. #9 0x7fff26bf6880 in ?? () No symbol table info available. #10 0x7fff26bf6883 in ?? () No symbol table info available. #11 0x7fff26bf689b in ?? () No symbol table info available. #12 0x7fff26bf689e in ?? () No symbol table info available. #13 0x in ?? () No symbol table info available. Hope this clarifies the issue somewhat. Thanks, -Steve signature.asc Description: Digital signature
Re: glibc: causes segfault in Xorg
On Wed, May 04, 2011 at 01:34:15PM +0200, sean finney wrote: > And furthermore, even if Debian chooses to "fix" this, upstreams will > be forced to eventually cater to the default glibc behavior for every > other libc distro out there that does not have their own "fix" (and > non-libc OS's where this behavior already exists), That's fine: let others be the guinea pigs, then introduce the optimized memcpy later when the rest of the world has adapted. > so gains would be potentially limited. For me, having a working system would be a great gain! > That said, regressions do suck, especially when they take the form of > heisenbugs. But one could easily hack something LD_PRELOAD'able check > for stuff like this without forcing a global change. Sounds interesting. What do you have in mind? -Steve signature.asc Description: Digital signature
Re: glibc: causes segfault in Xorg
On Wed, May 04, 2011 at 12:29:50PM +0200, Julien BLACHE wrote: > "Steve M. Robbins" wrote: > > Hi, > > > I'm with Linus on this: let's just revert to the old behaviour. A > > tiny amount of clock cycles saved isn't worth the instability. > > Tiny amount?! The optimized memcpy() variants that break shitty code > bring a 4 to 5x speedup on the processors they've been written for! Though I didn't see any actual time measurements in the bug thread, I am sure there is a speedup of some kind for the memcpy() call itself. I'm not interested in that. I am interested to know the speedup -- measured in real-world conditions -- for actual, popular applications. But I'm really not interested that much. I'm really interested in having a running system. Yes, even one with buggy software that happens to be important to me. Cheers, -Steve signature.asc Description: Digital signature
Re: glibc: causes segfault in Xorg
On Wed, May 04, 2011 at 12:10:48AM -0500, Jonathan Nieder wrote: > Sounds like http://sourceware.org/bugzilla/show_bug.cgi?id=12518 > which is fixed (sort of) by commit 0354e355 (2011-04-01). Oh my word. So glibc 2.13 breaks random binaries that happened to incorrectly use memcpy() instead of memmove()? What's wrong with the glibc developers (and Ulrich Drepper in particular)? I'm with Linus on this: let's just revert to the old behaviour. A tiny amount of clock cycles saved isn't worth the instability. Thanks, -Steve P.S. I tried rebuilding glibc myself locally, but gcc also segfaults in the process :-( signature.asc Description: Digital signature
Re: Static libraries in development packages
On Sat, Apr 16, 2011 at 09:55:34AM +0200, Goswin von Brederlow wrote: > "Steve M. Robbins" writes: > > >> As I've come to understanding, nowadays many libraries doesn't allow > >> trivial static linkage, > > > > I don't follow; it's generally as simple as using -static on > > the link line. Pretty trivial. > > Which a) might not be simple to get the build system to do and b) is far > from enough to build a static library. I see that we read the original comment differently. I was reacting to the claim "libraries can't be LINKED TO statically". You read it as "libraries can't be BUILT statically". With your reading, I agree that it's not *always* possible. At the end of my remarks, I agreed with the statement A development package should provide a static library *if possible*. > >> and that it's generally not recommended to > >> link statically in packages. > > > > That is completely separate from the question of whether Debian should > > provide static libraries for users to link with. I don't see that it > > should have any bearing. > > I think the better question is wether static linking even works at > all? > > There are many libraries that use plugins, most importantly libc6. The > probability that you invoke one of the plugin functions in libc6 in any > non trivial programm is high and then the static binary crashes and > burns if the dynamic libc6 on the system is incompatible. And if the > dynamic libc6 on the system is compatible then why would you ever want > to link it static? > > Static linking of libc6 basically never makes sense. The same can be > said for many other libs. Possibly that's true for many libraries, but surely not all of them. > On the other hand, even assuming the build system supports a static lib, > building a static lib means building the library twice. That complicates > the rules file and packaging. It also increases package size. Our priorities are our users. There are many things that complicate life for a packager, but are important to do because they benefit our users. > >> Thus I think we should consider updating the policy to either > >> specify that a development package should provide a static library > >> if possible, > > > > I agree with this sentiment. > > > > > > -Steve > > Given the cost that involves and that nobody has screamed about it in > the last 10 years I would opt for rephrasing it to "as needed". The > would reflect the current practice best. I don't accept either of your premises. For my part, I haven't surveyed our users to understand how important static linking is. However, I do know of communities that routinely build static binaries in order to guarantee reproducibility of data analysis results over time -- part of the so-called Reducible Research movement [1]. Secondly, in my packaging of libraries -- including the monstrous Boost -- I supply static libs whereever possible, not "as needed". This is how I've always read the current policy and I believe that phrase best reflects current practice. Regards, -Steve [1] http://www.rrplanet.com/reproducible-research-librum/ signature.asc Description: Digital signature
Re: Static libraries in development packages
> As I've come to understanding, nowadays many libraries doesn't allow > trivial static linkage, I don't follow; it's generally as simple as using -static on the link line. Pretty trivial. > and that it's generally not recommended to > link statically in packages. That is completely separate from the question of whether Debian should provide static libraries for users to link with. I don't see that it should have any bearing. > Thus I think we should consider updating the policy to either > specify that a development package should provide a static library > if possible, I agree with this sentiment. -Steve signature.asc Description: Digital signature
Boost packages status
Hi, I'm cc-ing to debian-devel since I expect others are wondering about the Boost status. On Sat, Mar 12, 2011 at 05:43:11PM +0100, Olaf van der Spek wrote: > Hi Steve, > > 1.42 still appears to be the latest version available in Debian (unstable). > Could 1.46.1 be uploaded? I assume you're speaking of boost-defaults -- the unversioned libboost-dev packages. Yes, these are still pointing to Boost v1.42. I always wait for the boostX.Y package to transition to "testing" before updating boost-defaults. Boost 1.46 just transitioned this week, so normally I would be uploading a new boost defaults. However, Boost is planning to make a point release (v1.46.1) -- the first time in years -- to fix a few troubling bugs so I had planned to skip 1.46 and update defaults directly to 1.46.1. In fact, I tried to keep boost 1.46 out of unstable by filing a bug but I was a bit late and it made the transition already. I see now that Boost 1.46.1 is now out, so I'll build and upload it today. When it transitions to unstable, I'll update the boost-defaults. Does this plan work for everyone? Thanks, -Steve signature.asc Description: Digital signature
What's up with buildd logs?
Hi, The buildd system is generally quite fabulous, but why does https://buildd.debian.org/build.cgi?pkg=insighttoolkit show version 3.8.0-1? This version is neither sid, not stable, nor oldstable. Thanks, -Steve signature.asc Description: Digital signature
RFH: kseg migration to qt4
tags 604479 + help thanks The Debian Qt/KDE team is planning to remove the KDE3 and Qt3 libraries from Debian shortly. The package kseg uses Qt3 presently and needs to be modified to build with Qt4. I'm not actively using kseg and don't have time to spend modifying it. I'm looking for someone to patch kseg to use Qt4 and upload it. Kseg is team-maintained by Debian Science Team; see svn://svn.debian.org/svn/debian-science/packages/kseg/trunk Thanks, -Steve signature.asc Description: Digital signature
how come the buildd machines can't find python-vtk?
I uploaded insighttoolkit the other day, but the buildd machines refuse to build it, claiming an installability problem [1]: insighttoolkit/alpha dependency installability problem: insighttoolkit (= 3.20.0-8) build-depends on one of: - python-vtk (= 5.4.2-8) This is repeated for all architectures. Two things puzzle me: 1. python-vtk is still in the archive according to the PTS and "rmadison" 2. the above output says "(= 5.4.2-8)", but the build-dep isn't versioned What's going on? Thanks, -Steve [1] https://buildd.debian.org/status/package.php?p=insighttoolkit signature.asc Description: Digital signature
Re: patch removal of --unified-reject-files breaks quilt
On Sun, Feb 13, 2011 at 03:53:34AM +0100, gregor herrmann wrote:
> On Sat, 12 Feb 2011 20:17:35 -0600, Steve M. Robbins wrote:
>
> > Suddenly, I can't apply my quilt patches:
> >
> > steve@riemann{insighttoolkit-3.20.0}quilt push -a
> > Applying patch metaio-test-vtk_source.patch
> > patch: unrecognized option '--unified-reject-files'
> > patch: Try `patch --help' for more information.
> > Patch metaio-test-vtk_source.patch does not apply (enforce with -f)
> >
> > Patch 2.6.1 has removed this "lenny compatibility option" deliberately.
> > How can we get quilt working again?
>
> In my case by fixing ~/.quiltrc:
>
> #QUILT_PATCH_OPTS="--unified-reject-files"
>
> Since commenting out the option quilt works again :)
Aha! I have the same option in .quiltrc. Thanks, I'll remove
it and try again.
Cheers,
-Steve
signature.asc
Description: Digital signature
Re: [Insight-developers] ITK 3.20.0 python WrapITK wrappers fail to build: too big?
On Wed, Feb 09, 2011 at 10:15:12AM +0100, Ga?tan Lehmann wrote: > > Steve, Luis, > > Splitting ImageToImageFilterB into smaller modules seems to be the > way to go in ITK v3. The attached patch should help! Thanks, Gaetan! I'm building ITK with this patch now for upload to Debian so we'll know in a few days whether it does the trick. Thanks again, -Steve signature.asc Description: Digital signature
patch removal of --unified-reject-files breaks quilt
Hi,
Suddenly, I can't apply my quilt patches:
steve@riemann{insighttoolkit-3.20.0}quilt push -a
Applying patch metaio-test-vtk_source.patch
patch: unrecognized option '--unified-reject-files'
patch: Try `patch --help' for more information.
Patch metaio-test-vtk_source.patch does not apply (enforce with -f)
Patch 2.6.1 has removed this "lenny compatibility option" deliberately.
How can we get quilt working again?
(for now, I've downgraded back to patch 2.6)
Thanks,
-Steve
signature.asc
Description: Digital signature
ITK 3.20.0 python WrapITK wrappers fail to build: too big?
Hi, The Debian build of ITK 3.20.0 fails to build on the powerpc build daemon [1] with the diagnostic: [ 23%] Building CXX object Wrapping/WrapITK/Modules/Base/CMakeFiles/_BasePython.dir/wrap_itkImageToImageFilterBPython.o cd /build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/obj-powerpc-linux-gnu/Wrapping/WrapITK/Modules/Base && /usr/bin/g++ -D_BasePython_EXPORTS -DSWIG_GLOBAL -Wno-deprecated -Wno-deprecated -ftemplate-depth-50 -Wall -Wno-deprecated -w -ftemplate-depth-50 -Wall -Wno-deprecated -O3 -DNDEBUG -fPIC -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Code/Review/Statistics -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Code/Review -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/obj-powerpc-linux-gnu/Utilities/vxl/core -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/obj-powerpc-linux-gnu/Utilities/vxl/vcl -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/obj-powerpc-linux-gnu/Utilities/vxl/v3p/netlib -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Utilities/vxl/core -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Utilities/vxl/vcl -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Utilities/vxl/v3p/netlib -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Utilities -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/obj-powerpc-linux-gnu/Utilities -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Utilities/itkExtHdrs -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Utilities/nifti/znzlib -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Utilities/nifti/niftilib -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Utilities/expat -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/obj-powerpc-linux-gnu/Utilities/expat -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/obj-powerpc-linux-gnu/Utilities/DICOMParser -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Utilities/DICOMParser -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/obj-powerpc-linux-gnu/Utilities/NrrdIO -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Utilities/NrrdIO -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Utilities/MetaIO -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Code/SpatialObject -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Code/Numerics/NeuralNetworks -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Code/Numerics/FEM -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Code/IO -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Code/Numerics -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Code/Common -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Code/BasicFilters -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Code/Algorithms -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/obj-powerpc-linux-gnu -I/usr/include/gdcm-2.0 -I/usr/include/vtk-5.4 -I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi -I/usr/include/tcl8.5 -I/usr/include/python2.6 -I/usr/lib/jvm/default-java/include -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/lib/jvm/java-6-openjdk/include -I/build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/Wrapping/WrapITK/Modules/Base -o CMakeFiles/_BasePython.dir/wrap_itkImageToImageFilterBPython.o -c /build/buildd-insighttoolkit_3.20.0-6-powerpc-m2NGDH/insighttoolkit-3.20.0/obj-powerpc-linux-gnu/Wrapping/WrapITK/Modules/Base/wrap_itkImageToImageFilterBPython.cxx /tmp/cchG87Lf.s: Assembler messages: /tmp/cchG87Lf.s:2649452: Error: operand out of range (0x8008 is not between 0x8000 and 0x7fff) /tmp/cchG87Lf.s:2649474: Error: operand out of range (0x8004 is not between 0x8000 and 0x7fff) [ ... repeated dozens of times ... ] Google suggests [2] this is a symptom of some table overflowing. Any suggestions on how to work around this? [1] https://buildd.debian.org/fetch.cgi?pkg=insighttoolkit&arch=powerpc&ver=3.20.0-6&stamp=1297198904&file=log&as=raw [2] https://bugzilla.redhat.com/show_bug.cgi?id=427700 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28904 Thanks, -Steve signature.asc Description: Digital signature
How to build a 32-bit package in Debian?
Hi, I've recently adopted a package (nyquist) that only builds in 32-bit mode. I'm struggling with supporting it on amd64 and other 64-bit architectures in Debian. First: yes, clearly the code should be migrated to 64-bits. Upstream is aware of that and it's a nontrivial effort. I'm interested in supporting the package as it exists today. The solution adopted at present is that upstream packages 3 required libraries (libsndfile, liblo, and portaudio) which are all built in 32-bit mode. This generates a working binary, but is sub-optimal for all the usual reasons: we don't benefit from fixes and upgrades. I'd like to link to the Debian-provided libsndfile, but of course it is 64-bit on my amd64 machine and the link fails. What is the recommended course of action for such a package? I just learned about the ia32-libs package. It doesn't contain the libraries I need (yet) but I imagine it may be possible to add them. Is there an equivalent package for other 64-bit architectures? Thanks, -Steve signature.asc Description: Digital signature
Re: Release Update: deep freeze, remaining bugs, schedule, themes and Wheezy
Hi, This release update announced: As hinted in the previous release update, now is the time to decide exactly what is going in to squeeze and what isn't. Here's what we're going to propose regarding the remaining RC bugs. We'll be working against the list of RC bugs affecting Squeeze that are not fixed in unstable: http://udd.debian.org/bugs.cgi?release=squeeze¬squeeze=ign&merged=ign&rc=1&sortby=id&sorto=asc Members of the Release Team will be considering bugs in that list, in the form: Squeeze: can-defer Squeeze: will-remove Squeeze: is-blocker Has this work started? I ask because there seem to be bugs on that list that can easily be deferred -- for example 147832 -- that are not so tagged. Is the tagging to be done by anyone or only by the release team? Do you want suggestions sent to you? Thanks, -Steve signature.asc Description: Digital signature
Bug#607030: ITP: elastix -- toolbox for rigid and nonrigid registration of images
Package: wnpp Severity: wishlist Owner: "Steve M. Robbins" * Package name: elastix Version : 4.4 Upstream Author : Stefan Klein and Marius Staring * URL : http://elastix.isi.uu.nl/ * License : BSD Programming Lang: C++ Description : toolbox for rigid and nonrigid registration of images Image reigstration based on the well-known Insight Segmentation and Registration Toolkit (ITK). The software consists of a collection of algorithms that are commonly used to solve (medical) image registration problems. The modular design of elastix allows the user to quickly configure, test, and compare different registration methods for a specific application. A command-line interface enables automated processing of large numbers of data sets, by means of scripting. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101214041905.29964.87721.report...@localhost
What to do about Bug #557495?
The list of RC squeeze bugs in the UDD http://udd.debian.org/bugs.cgi is growing alarmingly. However, I found one that doesn't seem like it belongs there so I'd like to ask what to do about it. Bug #557495 describes an undeclared conflict between packages: libctapimkt0-dev/1.0.1-1 libtowitoko-dev/2.0.7-8+b1 However package libctapimkt0-dev is not in squeeze, and the maintainer, Andreas Tille, does not feel it should be: On Mon, Nov 15, 2010 at 08:03:13AM +0100, Andreas Tille wrote: > I think libctapimkt is not fit for Squeeze release and thus I remove the > pending tag. The package was removed from testing anyway so I see no > further action necessary for the moment until the issue is settled with > the new upstream version. Should the bug be tagged, removed, have version information set differently, or something in order to remove it from the UDD query for "squeeze bugs"? Thanks, -Steve signature.asc Description: Digital signature
Oops: I broke the lenny --> squeeze update
Hi, I just received notice (bug 603579) that upgrade lenny to squeeze will break if a boost package containing an "rtupdate" script is installed. In stable there are four such packages: libboost-python-dev libboost-dbg libboost-python1.35-dev libboost1.35-dbg The issue is that the rtupdate script in stable only recognizes python 2.4 and python 2.5, and dies if any other version is supplied. Squeeze python default is 2.6 and so this blocks the upgrade of python, which is very bad. The rtupdate script has since been changed (in unstable) to avoid this problem, but I'm not sure what can be done for stable users other than recommending to purge the above four packages prior to upgrade. Is there any way to do this automatically? Brown-paper-bagged-ly yours, -Steve signature.asc Description: Digital signature
Re: bits from the DPL: sprints, events, delegations, assets
On Sat, Nov 13, 2010 at 09:34:02PM +0100, Julien Cristau wrote: > On Sat, Nov 13, 2010 at 14:26:39 -0600, Steve M. Robbins wrote: > > > So I looked at [2], clicked through to the Universal Debian Database > > [3], selected Sort By "last modified", and clicked Search. The very > > first bug on the result [4] is #545911, which is already fixed. > > > It's marked as fixed in lilypond 2.12.3-1. Squeeze has lilypond > 2.12.2-1. So it does affect squeeze. Aha! I suspected I was missing some detail like that. Thanks, -Steve signature.asc Description: Digital signature
Re: bits from the DPL: sprints, events, delegations, assets
Hi,
On Sat, Nov 13, 2010 at 04:49:04AM +0100, Stefano Zacchiroli wrote:
> Squeeze Release
> ===
>
> The monthly RFH section is once more for the Squeeze Release. Trying to
> read Release Team minds, I get something like: ? the RC bug count [1] is
> proceedings in the right direction, but it is still not (fast) enough to
> release ?. At the time of writing, the most recent stats [2] speak of
> 126 bugs that need to be fixed ... and we are about 1'000 developers!
> Please consider devoting some of your Debian time to fix RC bugs, no
> matter if you are the maintainer of the affected packages or not.
> Release is inherently a collaborative activity and not something up to
> the Release Team only; collaboration is also the only way to keep up
> with the high quality standards Debian has delivered in the past.
>
> [1] http://bugs.debian.org/release-critical/
> [2] http://blog.schmehl.info/Debian/rc-stats/2010-45
So I looked at [2], clicked through to the Universal Debian Database
[3], selected Sort By "last modified", and clicked Search. The very
first bug on the result [4] is #545911, which is already fixed.
This surprised me greatly, since I thought I was searching for bugs
"affecting" squeeze.
I later noticed that among the list of filters is "marked as done"
which was not considered. So the default search appears to be "bugs
that affected squeeze at some point in time", which is slightly
different from what I had first imagined ("bugs affecting squeeze
NOW").
So, a tip for others: be sure to "ignore" bugs marked as done.
Cheers,
-Steve
[3] http://udd.debian.org/bugs.cgi
[4]
http://udd.debian.org/bugs.cgi?release=squeeze&patch=&pending=&security=&wontfix=&upstream=&forwarded=&claimed=&deferred=¬main=¬squeeze=&base=&standard=&merged=ign&done=&outdatedsqueeze=&outdatedsid=&needmig=&newerubuntu=&fnewer=&fnewerval=7&rc=1&sortby=last_modified&sorto=asc
signature.asc
Description: Digital signature
Re: try to rebuild base.tgz (re: Does not install in pbuilder)
On Wed, Nov 10, 2010 at 11:25:50PM +0900, Hideki Yamane wrote: > Hi, > > I got the same issue with ca-certficates-java and pbuilder, but after > re-create base.tgz, it has gone away. Could you try to do that, please? Thanks for the tip! Indeed, re-creating base.tgz using "pbuilder --create" did the trick. Oddly, simply doing "pbuilder --update" (which is what I had been trying) did not work. I'm a little surprised, since I figured that whatever transient brokenness existed in my base.tgz would be fixed when said broken packages got replaced by updating. Whatever happened, it seems fixed now and I can build insighttoolkit in pbuilder. Cheers, -Steve signature.asc Description: Digital signature
two new annoying svn-buildpackage behaviours
Hi,
I was working on gmp and insighttoolkit packages today and ran into
two new behaviours of svn-buildpackage that are very annoying. I
checked the obvious candidates that I could think of
(svn-buildpackage, pbuilder, dpkg, devscripts) but didn't see any
recent changelog messages that appear alarming.
I'm hoping someone else might have already run into this and
could point me in the right direction.
I follow the "merge with upstream" methodology and put only the debian
subdir in source control. All of this is on an up-to-date amd64 "sid"
machine.
1. Initially the trunk directory has only a "debian" subdir. Running
"svn-buildpackage" in the trunk directory now leaves behind the
skeleton of the upstream source tree; e.g. alongside the debian
directory there is now a directory called "gmp-5.0.1+dfsg" that
contains only the directories -- all the files have been removed.
It is annoying, however, because I have to remove it before I
can run "svn-buildpackage" again:
st...@riemann{5.0.0-experimental}ls
debian gmp-5.0.1+dfsg
st...@riemann{5.0.0-experimental}svn-buildpackage
Complete layout information:
buildArea=/home/steve/Packages/debian-science/packages-svn/gmp/branches/build-area
origDir=/home/steve/Packages/debian-science/packages-svn/gmp/branches/tarballs
trunkDir=/home/steve/Packages/debian-science/packages-svn/gmp/branches/5.0.0-experimental
trunkUrl=svn+ssh://s...@svn.debian.org/svn/debian-science/packages/gmp/branches/5.0.0-experimental
dpkg-checkbuilddeps
E: Found unresolved issues:
? gmp-5.0.1+dfsg
E: Resolve them manually before continuing
2. When using pdebuild (--svn-builder="pdebuild ..."), the resulting diff file
is broken.
st...@riemann{bogus}dpkg-source -x gmp_5.0.1+dfsg-3.dsc
dpkg-source: info: extracting gmp in gmp-5.0.1+dfsg
dpkg-source: info: unpacking gmp_5.0.1+dfsg.orig.tar.gz
dpkg-source: info: applying gmp_5.0.1+dfsg-3.diff.gz
patching file debian/FAQ
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file debian/FAQ.rej
patching file debian/watch
Hunk #1 FAILED at 1.
... etc ...
Now, since I'm only adding files to debian/, all the diffs should have
only insertions ("+" lines). Looking at the diff, I see that each
file diff starts with a deletion:
-tail: cannot open `.pc/applied-patches' for reading: No such file or
directory
This problem occurs only when I try to use pbuilder. The complete
command line (that I've used for years) is "svn-pdebuild-final", which
is an alias for
st...@riemann{5.0.0-experimental}type svn-pdebuild-final
svn-pdebuild-final is aliased to `svn-pdebuild --auto-debsign --svn-tag
--svn-noautodch'
st...@riemann{5.0.0-experimental}type svn-pdebuild
svn-pdebuild is aliased to `svn-buildpackage --svn-dont-purge --svn-lintian
--svn-builder="pdebuild --buildresult `pwd`/../build-area"'
The problem does not occur when I build without pbuilder using
svn-buildpackage --svn-lintian --svn-tag --svn-noautodch
As always, any help is appreciated.
Thanks,
-Steve
signature.asc
Description: Digital signature
Re: ca-certificates-java does not install in pbuilder
More information ...
On Sat, Nov 06, 2010 at 02:54:22PM -0500, Steve M. Robbins wrote:
> > failed (VM used: java-6-openjdk).
> > dpkg: error processing ca-certificates-java (--configure):
> > subprocess installed post-installation script returned error exit status 1
> > configured to not write apport reports
I did a little digging into the post-install script. It
is failing on the "keytool" invocation, as follows:
if ! grep -q "^${alias}$" $pregenerated; then
if LANG=C LC_ALL=C keytool -importcert -trustcacerts
-keystore $KEYSTORE \
-noprompt -storepass "$storepass" \
-alias "$alias" -file "$cacertdir/$pem" > $log 2>&1
then
echo " added certificate $pem"
elif LANG=C LC_ALL=C keytool -importcert -trustcacerts
-keystore $KEYSTORE \
-providerClass sun.security.pkcs11.SunPKCS11 \
-providerArg '${java.home}/lib/security/nss.cfg' \
-noprompt -storepass "$storepass" \
-alias "$alias" -file "$cacertdir/$pem" > $log 2>&1
then
echo " added certificate $pem (using NSS provider)"
elif grep -q 'Signature not available' $log; then
echo " ignored import, signature not available:
${line#+*}"
sed -e 's/^/ -> /' $log
else
echo >&2 " error adding ${line#+*}"
errors=$(expr $errors + 1)
fi
fi
Note that there are two attempts at "keytool", the difference is only
that the second attempt adds "-providerClass" and "-providerArg"
options.
Keytool is obviously failing both times since I see the "error adding
..." output. By adding a "-v" option to keytool and "type $log" at
the appropriate places, I captured the following output from keytool.
First keytool attempt
-
keytool error: java.security.ProviderException: Could not initialize NSS
java.security.ProviderException: Could not initialize NSS
at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:201)
at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:103)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
at sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:262)
at sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:244)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:244)
at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:224)
at sun.security.jca.ProviderList.getProvider(ProviderList.java:232)
at sun.security.jca.ProviderList.getService(ProviderList.java:330)
at sun.security.jca.GetInstance.getInstance(GetInstance.java:157)
at java.security.Security.getImpl(Security.java:696)
at
java.security.AlgorithmParameters.getInstance(AlgorithmParameters.java:130)
at sun.security.x509.AlgorithmId.decodeParams(AlgorithmId.java:121)
at sun.security.x509.AlgorithmId.(AlgorithmId.java:114)
at sun.security.x509.AlgorithmId.parse(AlgorithmId.java:381)
at sun.security.x509.X509Key.parse(X509Key.java:168)
at
sun.security.x509.CertificateX509Key.(CertificateX509Key.java:75)
at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:705)
at sun.security.x509.X509CertInfo.(X509CertInfo.java:169)
at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1747)
at sun.security.x509.X509CertImpl.(X509CertImpl.java:196)
at
sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:107)
at
java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:322)
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:763)
at
sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:55)
at java.security.KeyStore.load(KeyStore.java:1201)
at sun.security.tools.KeyTool.doCommands(KeyTool.java:647)
at sun.security.tools.KeyTool.run(KeyTool.java:194)
at sun.security.tools.KeyTool.main(KeyTool.java:188)
Caused by: java.io.I
ca-certificates-java does not install in pbuilder
Hi, I just ran into a problem with ca-certificates-java and reported the enclosed bug. In brief: it installed in the pbuilder environment as recently as a few weeks ago but fails today. However, ca-certificates-java has not changed in months, so perhaps the bug lies elsewhere -- either with pbuilder itself or a third package. Has anyone else seen/solved this? Thanks, -Steve On Sat, Nov 06, 2010 at 02:24:51PM -0500, Steve M. Robbins wrote: > Package: ca-certificates-java > Version: 20100412 > Severity: important > > I routinely build insighttoolkit using pbuilder. Insighttoolkit has > java bindings so pbuilder ultimately ends up installing > ca-certificates-java and this has worked fine for years. It worked as > recently as a couple of weeks ago. > > Today, ca-certificates-java fails to install in pbuilder, > which is an up-to-date sid distribution. This sequence: > > sudo pbuilder login > apt-get install ca-certificates-java > > results in: > > Setting up openjdk-6-jre-lib (6b18-1.8.2-4) ... > Setting up ca-certificates-java (20100412) ... > creating /etc/ssl/certs/java/cacerts... > error adding brasil.gov.br/brasil.gov.br.crt > error adding cacert.org/cacert.org.crt > error adding debconf.org/ca.crt > error adding gouv.fr/cert_igca_dsa.crt > ... > failed (VM used: java-6-openjdk). > dpkg: error processing ca-certificates-java (--configure): > subprocess installed post-installation script returned error exit status 1 > configured to not write apport reports > Errors were encountered while processing: > ca-certificates-java > > > In my regular sid environment, "apt-get install --reinstall > ca-certificates-java" works fine. > > > > -- System Information: > Debian Release: squeeze/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages ca-certificates-java depends on: > ii ca-certificates20090814+nmu2 Common CA certificates > ii default-jre-headless [java 1:1.6-40 Standard Java or Java compatible > R > ii openjdk-6-jre-headless [ja 6b18-1.8.2-4 OpenJDK Java runtime, using > Hotspo > > Versions of packages ca-certificates-java recommends: > ii libnss3-1d3.12.8-1 Network Security Service > libraries > > ca-certificates-java suggests no packages. > > -- Configuration Files: > /etc/default/cacerts [Errno 13] Permission denied: u'/etc/default/cacerts' > > -- no debconf information signature.asc Description: Digital signature
Bug#599880: ITP: mriconvert -- medical image file conversion utility that converts DICOM files to other formats
Package: wnpp Severity: wishlist Owner: "Steve M. Robbins" * Package name: mriconvert Version : 2.0 Upstream Author : Jolinda Smith joli...@uoregon.edu * URL : http://lcni.uoregon.edu/~jolinda/MRIConvert/ * License : GPL Programming Lang: C++ Description : converts DICOM files to other formats MRIConvert is a medical image file conversion utility that converts DICOM files to NIfTI 1.1, Analyze 7.5 , SPM99/Analyze, BrainVoyager, and MetaImage volume formats. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101012043217.25065.361.report...@localhost
Bug#598556: ITP: insightapplications -- InsightToolKit (ITK) based medical imaging applications
Package: wnpp Severity: wishlist Owner: "Steve M. Robbins" * Package name: insightapplications Version : 3.20.0 Upstream Author : The Insight Consortium and Contributors * URL : http://itk.org/ITK/resources/applications.html * License : BSD (http://www.itk.org/ITK/project/license.html) Programming Lang: C++, Python, Tcl Description : InsightToolKit (ITK) based medical imaging applications A variety of applications providing segmentation, registration, and other medical image processing algorithms such as MRI bias field correction. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100930041912.32281.42105.report...@localhost
Seeking machines for nightly builds of ITK
Hi, The insighttoolkit package is a large and active code base. They use a system of nightly build/test on a variety of machines [1] to ensure that the code works on all supported platforms. I run a build on my amd64 machine -- configured as the Debian ITK packages -- to expose issues early. I'd like to add some more Debian machines to cover all the architectures. This issue has some urgency now since ITK is presently embarking on an overhaul of the code that includes removing "obsolete" code, including support for old compilers & systems, such as SGI. I'd like to ensure they don't break compilation for some of the lesser-used machines such as mips, arm, etc. Ideally, I'd like one machine that runs "sid" of each architecture. I already run the amd64 build. Can I use the official Debian developer machines for this task? If you have a non-amd64 machine with spare cycles each night that you can either set up a build [2] or let me log in to do it, please reply. Thanks, -Steve [1] http://public.kitware.com/dashboard.php?name=itk [2] http://www.itk.org/Wiki/ITK/Git#Dashboard signature.asc Description: Digital signature
Priority dependence
Hi, The discussion surrounding why aptitude is priority 'important' [1] is very enlightening. Thanks to all contributors. With respect to the priority of libboost-iostreams, the consensus seems to be to raise it. On Sun, Jul 18, 2010 at 02:18:52AM +0200, Steve Langasek wrote: > [ ... ] on balance, I would > conclude that raising the priority of libboost-iostreams to important is > actually the right solution. This is due to Debian Policy 2.5: Packages must not depend on packages with lower priority values (excluding build-time dependencies). In order to ensure this, the priorities of one or more packages may need to be adjusted. Why is this the policy? Why does it matter? Surely installing all the "important" packages will pull in their dependencies regardless of the depended-upon package's priority. Thanks, -Steve [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588608 signature.asc Description: Digital signature
Re: aptitude (priority important) depends on libboost-iostreams (priority optional)
Folks, The package "aptitude" is priority "important" and depends on libboost-iostreams, which is "optional". This is a violation of Policy section 2.5. The request of Bug #588608 is to raise the priority of libboost-iostreams to "important". Reading Policy, I note that "important" means: `important' Important programs, including those which one would expect to find on any Unix-like system. If the expectation is that an experienced Unix person who found it missing would say "What on earth is going on, where is `foo'?", it must be an `important' package.[1] Other packages without which the system will not run well or be usable must also have priority `important'. This does _not_ include Emacs, the X Window System, TeX or any other large applications. The `important' packages are just a bare minimum of commonly-expected and necessary tools. I wouldn't place any of Boost in that category. In fact, I wouldn't place "aptitude" in that category, either. So while raising Boost will "solve" the issue, it seems to me to be a recipe for runaway priority inflation. Is there any central authority to vet priority changes? Thanks, -Steve signature.asc Description: Digital signature
Re: Confused by .la file removal vs static linking support
I'm a little alarmed at the attitude that "no one cares about static linking" so that it's okay to drop the .a files. Likely relatively few people care, but there are some that do. One example is scientific users that need to ensure reproducibility of computer experiments [1] over many years: one technique used is to statically link the code and quarantine it so that it isn't disturbed by system library upgrades. It's not the only technique used, of course, but "our priorities are our users" so let's think hard before removing this option for them. To the original poster's question, it seems to me that [2] is reasonably clear that the request is to drop the .la file. I wouldn't necessarily downgrade the -dev package dependencies: often they are there not only for the static lib, but also because your library's includes will #include files from other libs it depends on, so all users of your -dev package may need the depended-upon -devs. So it will depend on the situation at hand. -Steve [1] http://lists.debian.org/debian-science/2010/04/msg00037.html [2] http://lists.debian.org/debian-devel/2009/08/msg00808.html signature.asc Description: Digital signature
Re: Re: Flag images
Paul, I read through the links you provided. There was a cogent argument against using flags to symbolize a language. I would accept that. However, while I understand your argument about losing contributors, I'm not completely convinced that using a flag chosen by country X to represent country X is a bad idea. Moreover, I didn't see a resolution on the question of Fedora's flag policy. The link http://lwn.net/Articles/334519/ says the committee voted to * revert/suspend the policy approved the prior week * have people look into the issues and gather data (requirements of * various locales, number of packages affected, etc.) * craft a policy based on further data, or decide that one is not * required at all This vote dates from May 2009. Do you know what was ultimately decided? Thanks, -Steve signature.asc Description: Digital signature
experimental buildd link gone?
Hi, The "links" box of the PTS used to have a link to the experimental buildd logs. I think I used it last week but today it is not there; c.f. http://packages.qa.debian.org/g/gmp.html How can I see the logs? Thanks, -Steve signature.asc Description: Digital signature
New GMP version 5.0.0 available in experimental: please test
Upstream released a new GMP version 5.0.0 with a scary-sounding caveat: The 5.0.0 release contain a very large amount of new code, and countless improvements to existing code, please see below for the complete list. No past GMP release has contained more new code than 5.0.0. Most of the new code is at the "mpn level", i.e., the low-level used by other part of the library. CAUTION: The amount of new code means that there might be more bugs in this release than in most GMP releases in the past. We therefore release the stable GMP 4.3.2 at about the same time as this release. If you are concerned about possible bugs in the present release, consider using GMP 4.3.2 instead. [...] So I uploaded GMP 4.3.2 to unstable and 5.0.0 to experimental. It would be helpful to have some folks (GMP power users especially) try out 5.0. Feel free to report bugs upstream (I follow gmp-bugs), or to the BTS. I've been using 5.0 for a day and haven't seen any ill effects. Please let me know your experience, good or bad. Thanks, -Steve signature.asc Description: Digital signature
renamings to remove extensions
Hi, I agree with Charles: this is unncessary, unproductive busy-work. On the other hand, Section 10.4 says only "the script name should not include an extension". So you can leave the extension for compatibility with the rest of the world. It is a bug, but Section 1.1 says: Non-conformance with guidelines denoted by should (or recommended) will generally be considered a bug, but will not necessarily render a package unsuitable for distribution. -Steve signature.asc Description: Digital signature
Bug#547611: RFH: geomview -- interactive geometry viewing program
Package: wnpp Severity: normal Hi, I'd appreciate someone to help with maintenance of geomview. The package description is: Geomview is interactive geometry software which is particularly appropriate for mathematics research and education. In particular, geomview can display things in hyperbolic and spherical space as well as Euclidean space. . Geomview allows multiple independently controllable objects and cameras. It provides interactive control for motion, appearances (including lighting, shading, and materials), picking on an object, edge or vertex level, snapshots in SGI image file or Renderman RIB format, and adding or deleting objects is provided through direct mouse manipulation, control panels, and keyboard shortcuts. External programs can drive desired aspects of the viewer (such as continually loading changing geometry or controlling the motion of certain objects) while allowing interactive control of everything else. Homepage: http://www.geomview.org. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Mon, Aug 03, 2009 at 03:31:57PM +0200, Paul Wise wrote: > On Mon, Aug 3, 2009 at 3:24 PM, Steve M. Robbins wrote: > > On Wed, Jul 29, 2009 at 03:08:02AM +0200, Meike Reichle wrote: > >> Debian decides to adopt time-based release freezes > > > > I believe this is a positive step. ??However, I'm used to Debian having > > long drawn out conversations about decisions such as this. ??I've > > checked on debian-devel, debian-release, and debian-project but I have > > missed such pre-decision discussion. ??Can you point me to the right > > place? > > The discussion was post-decision and post-decision-reconsideration: Yes, thanks for the references. I don't have any desire to be drawn into the long discussions; many have made the points I agree with better than I could. But for anyone keeping track, put me down in the column of "those very disheartened by the lack of prior consultation". I'm also persuaded by those who suggest freezing much later than December 2009 (like December 2010) is a better option. Actually, since I tend to get a fair amount of work done during December holidays, I'd vastly prefer to freeze in mid-January. -Steve signature.asc Description: Digital signature
Re: Debian decides to adopt time-based release freezes
Hi, On Wed, Jul 29, 2009 at 03:08:02AM +0200, Meike Reichle wrote: > - > The Debian Project http://www.debian.org/ > Debian adopts time-based release freezes pr...@debian.org > July 29th, 2009 http://www.debian.org/News/2009/20090729 > - > > Debian decides to adopt time-based release freezes I believe this is a positive step. However, I'm used to Debian having long drawn out conversations about decisions such as this. I've checked on debian-devel, debian-release, and debian-project but I have missed such pre-decision discussion. Can you point me to the right place? Thanks, -Steve signature.asc Description: Digital signature
Re: Who uses @packages.d.o mail?
I use b...@packages.debian.org to contact the maintainer of "blah". I use this to alert maintainers of reverse build-deps when I do something drastic to one of the libraries I maintain. I'm open to other options, of course. What is the recommended practice for this scenario? Thanks, -Steve signature.asc Description: Digital signature
NEW processing
Is the NEW queue going to get processed any time soon? There are 215 packages waiting [1] about half of which have been there 3 or more weeks. Last time I asked [2], the result was a large thread discussing what manual work is done in processing NEW. I suggest reading through that thread before adding a follow-up message here. Just one pet peeve of mine: In the case of a SONAME bump of an already-accepted library package, I can't personally see any value in passing through NEW again. Surely it's possible to change the infrastructure to simply accept this just as we would a new version of the library that doesn't change SONAME. Wouldn't that make sense? Regards, -Steve [1] http://ftp-master.debian.org/new.html [2] http://lists.debian.org/debian-devel/2008/12/msg00112.html signature.asc Description: Digital signature
NEW processing
Hello, Is the NEW queue going to get processed any time soon? There's a load of packages that are 3 weeks or more old. Thanks, -S signature.asc Description: Digital signature
Re: can buildd logs be sorted (again)?
On Mon, Nov 24, 2008 at 08:04:46PM +0100, Adeodato Sim?? wrote: > * Steve M. Robbins [Wed, 29 Oct 2008 01:42:06 -0500]: > > > Hi, > > > The buildd log pages, e.g. [1], used to be sorted by package version > > (or maybe build date). However that is no longer the case. > > > Can this be fixed? The current situation is less than useful since > > the latest build is buried in other output. > > > Thanks, > > -Steve > > > [1] http://buildd.debian.org/build.php?pkg=boost > > I fixed this to sort entries by age, HTH. Yes! Thanks very much. -Steve signature.asc Description: Digital signature
canonical list of port-specific CPP symbols
Hi, Is there a canonical list of symbols defined by each of the Debian architectures, e.g. do I test for Sparc using __sparc or __sparc__ ? How about m68k, hppa, etc? My first guess was that would be contained on http://ports.debian.org/ but no such luck. Thanks, -Steve signature.asc Description: Digital signature
Who owns /etc/default/locale?
I have two systems. Both track unstable, and have package locales at version 2.0.16. On one system, package locales owns /etc/default/locale, on the other, it doesn't. Should the file be owned by locales or not? Could the situation arise by upgrades? One system is 4 years old (upgraded weekly or better), the other just two months old. Surely it isn't architecture dependent (one is x86, the second is amd64)? SYSTEM 1 [EMAIL PROTECTED] --list locales Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== ii locales 2.7-16GNU C Library: National Language (locale) data [support] [EMAIL PROTECTED] --search /etc/default/locale locales: /etc/default/locale SYSTEM 2 [EMAIL PROTECTED] --list locales Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=-=-== ii locales 2.7-16GNU C Library: National Language (locale) data [support] [EMAIL PROTECTED] --search /etc/default/locale dpkg: /etc/default/locale not found. -Steve signature.asc Description: Digital signature
can buildd logs be sorted (again)?
Hi, The buildd log pages, e.g. [1], used to be sorted by package version (or maybe build date). However that is no longer the case. Can this be fixed? The current situation is less than useful since the latest build is buried in other output. Thanks, -Steve [1] http://buildd.debian.org/build.php?pkg=boost The database contains build logs for the following versions of boost: * 1.31.0-3 (alpha) (latest build at Apr 12 15:49: maybe-successful) * 1.31.0-3 (powerpc) (latest build at Apr 12 15:51: maybe-successful) * 1.31.0-3 (hppa) (latest build at Apr 12 17:13: maybe-successful) * 1.31.0-3 (ia64) (latest build at Apr 12 15:42: maybe-successful) * 1.31.0-3 (m68k) (latest build at Apr 13 01:05: maybe-successful) * 1.31.0-3 (arm) (latest build at Apr 12 18:08: maybe-successful) * 1.31.0-3 (mips) (latest build at Apr 12 19:11: maybe-successful) * 1.31.0-3 (sparc) (latest build at Apr 12 18:16: maybe-successful) * 1.31.0-3 (mipsel) (latest build at Apr 12 17:08: maybe-successful) * 1.31.0-3 (s390) (latest build at Apr 12 15:54: maybe-successful) * 1.26.0-3 (powerpc) (latest build at Jan 27 00:21: maybe-successful) * 1.26.0-3 (arm) (latest build at Jan 27 00:50: maybe-successful) * 1.26.0-3 (alpha) (latest build at Feb 2 21:57: maybe-failed) * 1.26.0-3 (sparc) (latest build at Jan 27 00:15: maybe-successful) * 1.33.1-5 (ia64) (latest build at Jul 20 17:24: maybe-successful) * 1.33.1-5 (alpha) (latest build at Jul 20 22:27: maybe-successful) * 1.33.1-5 (mips) (latest build at Jul 20 18:52: maybe-successful) * 1.33.1-5 (arm) (latest build at Jul 22 11:24: maybe-failed) * 1.33.1-5 (mipsel) (latest build at Jul 20 18:47: maybe-successful) * 1.33.1-5 (hppa) (latest build at Jul 20 20:38: maybe-successful) * 1.33.1-5 (powerpc) (latest build at Jul 20 18:55: maybe-successful) * 1.33.1-5 (amd64) (latest build at Jul 20 16:31: maybe-successful) * 1.33.1-5 (s390) (latest build at Jul 20 17:13: maybe-successful) * 1.33.1-5 (m68k) (latest build at Jul 25 01:09: maybe-successful) * 1.33.1-5 (sparc) (latest build at Jul 20 20:10: maybe-successful) * 1.29.0-1 (powerpc) (latest build at Oct 29 19:32: maybe-successful) * 1.29.0-1 (arm) (latest build at Oct 29 22:05: maybe-successful) * 1.29.0-1 (s390) (latest build at Oct 31 18:45: maybe-successful) * 1.29.0-1 (alpha) (latest build at Oct 29 21:44: maybe-successful) * 1.29.0-1 (ia64) (latest build at Oct 29 20:02: maybe-successful) * 1.29.0-1 (hppa) (latest build at Oct 29 19:05: maybe-successful) * 1.29.0-1 (m68k) (latest build at Oct 30 07:43: maybe-successful) * 1.29.0-1 (sparc) (latest build at Oct 29 21:32: maybe-successful) * 1.33.0-5 (arm) (latest build at Nov 23 18:05: maybe-successful) * 1.33.0-5 (ia64) (latest build at Nov 23 02:31: maybe-successful) * 1.33.0-5 (hppa) (latest build at Dec 14 18:33: maybe-failed) * 1.33.0-5 (sparc) (latest build at Nov 23 01:40: maybe-successful) * 1.33.0-5 (s390) (latest build at Nov 23 00:56: maybe-successful) * 1.33.0-5 (alpha) (latest build at Nov 23 09:25: maybe-successful) * 1.33.0-5 (m68k) (latest build at Nov 27 17:59: maybe-successful) * 1.33.0-5 (mipsel) (latest build at Nov 23 03:51: maybe-successful) * 1.33.0-5 (mips) (latest build at Nov 23 13:19: maybe-successful) * 1.33.0-5 (powerpc) (latest build at Nov 23 00:27: maybe-successful) * 1.31.0-4 (powerpc) (latest build at Apr 15 10:55: maybe-successful) * 1.31.0-4 (sparc) (latest build at Apr 15 11:33: maybe-successful) * 1.31.0-4 (ia64) (latest build at Apr 15 10:44: maybe-successful) * 1.31.0-4 (hppa) (latest build at Apr 15 10:55: maybe-successful) * 1.31.0-4 (m68k) (latest build at Apr 15 22:37: maybe-successful) * 1.31.0-4 (mipsel) (latest build at Apr 15 12:02: maybe-successful) * 1.31.0-4 (arm) (latest build at Apr 15 13:21: maybe-successful) * 1.31.0-4 (mips) (latest build at Apr 15 12:50: maybe-successful) * 1.31.0-4 (alpha) (latest build at Apr 15 10:49: maybe-successful) * 1.31.0-4 (s390) (latest build at Apr 15 11:07: maybe-successful) * 1.33.1-2 (m68k) (latest build at Jan 21 06:48: maybe-successful) * 1.33.1-2 (mips) (latest build at Jan 11 19:46: maybe-successful) * 1.33.1-2 (sparc) (latest build at Jan 14 21:09: maybe-successful) * 1.33.1-2 (mipsel) (latest build at Jan 11 19:26: maybe-successful) * 1.33.1-2 (arm) (latest build at Jan 13 10:54: maybe-successful) * 1.33.1-2 (hppa) (latest build at Jan 11 21:04: maybe-successful) * 1.33.1-2 (s390) (latest build at Jan 11 18:09: maybe-successful) * 1.33.1-2 (powerpc) (latest build at Jan 11 19:22: maybe-successful) * 1.33.1-2 (ia64) (latest build at Jan 11 18:09: maybe-successful) * 1.33.1-2 (alpha) (latest build at Jan 11 18:41: maybe-successful) * 1.33.1-4 (m68k) (latest build at May 8 22:20: maybe-successful) * 1.33.1-4 (sparc) (latest build at Mar
parallel builds using DEB_BUILD_OPTIONS
Hi, The Policy Manual [1] gives the following recipe for supporting parallel make: ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) MAKEFLAGS += -j$(NUMJOBS) endif Unfortunately, for packages that use recursive makefiles (the most common practice) this results in the following warning make[1]: warning: -jN forced in submake: disabling jobserver mode. which apparently is sub-optimal [2]. The issue in that MAKEFLAGS is applied to each recursive make. The recommended practice is to supply -jN *only* to the initial invocation of make. It strikes me, therefore, that the policy manual should be updated, removing MAKEFLAGS and instead showing an explicit "make -J$(NUMJOBS) ...". However, my problem is with cdbs: how can I supply -jN to only the initial make? Thanks, -Steve [1] http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options [2] http://make.paulandlesley.org/jobserver.html signature.asc Description: Digital signature
Debian tcl/tk policy: where to put shared libs?
Hi,
I need some help packaging Tcl language bindings for ITK [1]. I've
read the policy (in package tcl-doc) but I'm not sure whether
I'm doing the right thing.
I am essentially tcl illiterate, so please explain things in full.
Examples help.
ITK generates about 9 shared libs and 4 .tcl files, including a
pkgIndex.tcl. I'm only building for the default version of tcl right
now, so I created a package tcl8.4-insighttoolkit3 and installed the
tcl files into /usr/share/tcltk/tcl8.4/insighttoolkit3. Does that
sound right?
Now: where do the shared libs go? If this is covered in the policy, I
have missed it. I decided to put them into /usr/lib.
The pkgIndex.tcl file contains the following
proc ConfigureTclPackage {libName version} {
set libPrefix "lib"
set libPath "[file dirname [file dirname [info script]]]"
set libExt [info sharedlibextension]
set libFile [file join $libPath "$libPrefix$libName$libExt"]
set package [string tolower $libName]
package ifneeded $package $version "
namespace eval ::itk::loader {
set curDir \[pwd\]
cd {$libPath}
if {\[catch { load \"$libFile\" } errorMessage \]} { puts
\$errorMessage }
cd \$curDir
}
"
}
With some puts-style debugging (as mentioned, I'm tcl illiterate), I
concluded that this snippet is expecting the shared libs in the parent
directory of that containing pkgIndex.tcl; i.e. libPath is set to
/usr/share/tcltk/tcl8.4. Is this common practice or is it an upstream
quirk? It doesn't strike me as a good idea to put shared objects into
/usr/share/...
My current plan is simply to patch this to read
set libPath "/usr/lib"
But that just as well could be "/usr/lib/tcltk/" or somesuch.
Hence my question about where to put shared libs.
Any additional insights or pointers are most welcome. This is
my first attempt at packaging Tcl bindings.
Thanks,
-Steve
[1] http://packages.qa.debian.org/i/insighttoolkit.html
The Tcl bindings are not yet present; it will be a new package
appearing with version 3.6.0.
P.S. I searched in vain for a debian-tcl mailing list, so I'm sending
this to debian-devel as well as the two names listed in the Tcl/Tk
policy package and the pkg-tcltk-devel list. If this is not the right
place, please advise and do feel free to forward this email to the
right place.
signature.asc
Description: Digital signature
Re: [pkg-boost-devel] Bug#473752: Bug#473752: Bug#473752: Boost 1.35 has been released
On Mon, May 05, 2008 at 06:16:04PM +0200, Domenico Andreoli wrote: > On Sat, May 03, 2008 at 12:15:39AM -0500, Steve M. Robbins wrote: > > My headache now is that there are 13 -dev packages in Boost. One > > (libboost1.35-dev) contains 60+ header-only libraries, while the > > others each contain 1 library that happens to build a shared object. > > > > This overhead creates a nonnegligible amount of complexity and > > generates bugs (e.g. #457654, #478782). Is there any value to this > > granularity? I can't see any. If there are no objections, I'm > > leaning towards collapsing all the -dev packages into libboost1.35-dev > > -- and rolling bcp into it, as well. I'll probably keep > > libboost-python1.35-dev separate (with pyste rolled into it). > > > > Your thoughts? > > please, proceed. I'm making progress :-) However, the long build times makes fixing the packaging errors quite drawn out. So far I have rolled bcp into libboost1.35-dev and pyste into libboost-python1.35-dev. Then I realized the following. Each Boost component that builds a shared library has both a libfoo1.35.0 and a libfoo1.35-dev package. If I roll up the -dev packages into libboost1.35-dev, then it will ship with dangling "link name" symlinks (libfoo.so) unless I also roll up all the shared libs into liboost1.35.0. I don't think the former (dangling links) will pass muster; so if we collapse the -dev packages, we must also collapse the shared library packages. I see some value in the granularity of having each shared lib live on its own: a system that needs only Boost.Regexp doesn't have to pay the disk space for also having Boost.Python. But maybe it's not so important. Does anyone care? A compromise position is to keep the 2 Python packages separate -- since they pull in heavier dependencies (python et al) -- but roll the rest of the boost shared libs together. At this point, I must admit that I'm sick of boost packaging and am leaning towards fixing the remaining package bugs and uploading 1.35 with all the 29 or so existing packages. Even if we do that, we can always revisit this decision for 1.36, so I'm interested in hearing your thoughts. Cheers, -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Bug#473752: Bug#473752: Bug#473752: Boost 1.35 has been released
On Tue, Apr 29, 2008 at 01:14:45PM +0200, Domenico Andreoli wrote: > On Tue, Apr 29, 2008 at 12:22:24AM -0500, Steve M. Robbins wrote: > > > > In contrast, the alternative strategy of having all the libfoo-dev > > (1.34.1) packages conflict with libfoo1.35.0-dev packages has just a > > single negative: that you can't develop simultaneously with 1.34.1 and > > 1.35.0. On the positive side, however, you can install the 1.35 -devs > > and the existing build scripts will work because the include path and > > the simplified link library names are preserved. > > > > So unless anyone (Domenico?) has a strong preference for the > > first option, I'm planning to pursue the second. > > second option, absolutely. Good. I'm planning to assume that the 1.35.x releases are all approximately API-compatible, so I'm naming the packages libboost-foo1.35-dev. Any objection to that? My headache now is that there are 13 -dev packages in Boost. One (libboost1.35-dev) contains 60+ header-only libraries, while the others each contain 1 library that happens to build a shared object. This overhead creates a nonnegligible amount of complexity and generates bugs (e.g. #457654, #478782). Is there any value to this granularity? I can't see any. If there are no objections, I'm leaning towards collapsing all the -dev packages into libboost1.35-dev -- and rolling bcp into it, as well. I'll probably keep libboost-python1.35-dev separate (with pyste rolled into it). Your thoughts? Thanks, -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Bug#473752: Bug#473752: Bug#473752: Boost 1.35 has been released
On Sat, Apr 19, 2008 at 03:43:35PM -0500, Steve M. Robbins wrote: > On Fri, Apr 18, 2008 at 12:20:39PM +0200, Domenico Andreoli wrote: > > > I think new and separate boost-1.35 package is the best option we have: > > > > 1. It may be uploaded now and released with lenny without touching > > any reverse dependency > > 2. Never more huge transitions, reverse dependencies take 1.35 as > > they like > > I think we might as well support multiple boost versions. As you > point out, there is a big advantage in not forcing a transition each > time Boost releases. > > The remaining question is whether we support co-installation of > multiple -dev packages. The fact that Boost upstream *does* support > this -- by embedding the boost version into both the link library and > the include directory names -- makes me lean towards this option. ... but now that I've thought a little harder, I've realized it brings several negatives: * The simplified link library names (i.e. -lboost_wave rather than -lboost_wave-gcc42-1_35) are difficult to manage. I can think of a couple of poor options: drop them completely; or use alternatives. * Ditto for the simplified include directory structure: /usr/include/boost rather than /usr/include/boost-1_35/boost. * The tools "bcp" and "pyste" suffer from a similar problem: they are currently installed into /usr/bin. For these tools to coexist in 1.34.1 and 1.35.0 versions, they'd need a suffix added, or the like. In contrast, the alternative strategy of having all the libfoo-dev (1.34.1) packages conflict with libfoo1.35.0-dev packages has just a single negative: that you can't develop simultaneously with 1.34.1 and 1.35.0. On the positive side, however, you can install the 1.35 -devs and the existing build scripts will work because the include path and the simplified link library names are preserved. So unless anyone (Domenico?) has a strong preference for the first option, I'm planning to pursue the second. Thanks, -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Bug#473752: Bug#473752: Boost 1.35 has been released
On Sat, Apr 19, 2008 at 10:53:35PM +0200, Olaf van der Spek wrote: > Steve M. Robbins wrote: >> If we do decide to have co-installable -dev packages, the next >> question is how do we handle the current non-versioned includes and >> link libraries? Do we follow what gcc and python do, providing a >> defaults that change from time to time? Or should we not attempt to >> provide such defaults? I fear the first option will bring us back to >> the same misery we currently suffer with transitions. So I'm fine >> with not providing defaults, which is in line with upstream practices >> anyway. > > What would that imply? > Would users have to modify the build script to add the Boost include > directory to the include path? Likely, yes. > At the moment this is not necessary and I think requiring it is a bad > idea (for users that have to compile third-party code) Noted. On the other hand, some might like the flexibility of deciding which Boost version to build with, similar to the ability to choose between Qt3 and Qt4. >> I also removed the Boost library version from the link library names. >> However, reflecting upon what you say, I suppose we really prefer to >> have version X-dev and version (X+1)-dev co-installable. If so, we >> would revert that change and adjust the rules accordingly. > > Is there documentation about the incompatibilities between 1.34 and 1.35? No, not that I'm aware of. Chimo, -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Bug#473752: Bug#473752: Boost 1.35 has been released
On Fri, Apr 18, 2008 at 12:20:39PM +0200, Domenico Andreoli wrote: > I think new and separate boost-1.35 package is the best option we have: > > 1. It may be uploaded now and released with lenny without touching > any reverse dependency > 2. Never more huge transitions, reverse dependencies take 1.35 as > they like I think we might as well support multiple boost versions. As you point out, there is a big advantage in not forcing a transition each time Boost releases. The remaining question is whether we support co-installation of multiple -dev packages. The fact that Boost upstream *does* support this -- by embedding the boost version into both the link library and the include directory names -- makes me lean towards this option. I'd appreciate hearing any concerns regarding this. Olaf van der Spek has already voiced one: Can a process load 1.34 and 1.35 at the same time? Otherwise maybe you've got a problem if one lib uses 1.34 and another lib uses 1.35 and parts are exposed. I think you're right that there could be a problem. I'm not sure what can be done about it besides having the two boost-using libs upgrade together. If we do decide to have co-installable -dev packages, the next question is how do we handle the current non-versioned includes and link libraries? Do we follow what gcc and python do, providing a defaults that change from time to time? Or should we not attempt to provide such defaults? I fear the first option will bring us back to the same misery we currently suffer with transitions. So I'm fine with not providing defaults, which is in line with upstream practices anyway. > I could make sush package but I need the point about the SVN repository. > Steve, I saw the transition of boost-jam to merge-upstream-mode, which > are your plans for boost? I have already changed boost to merge-upstream-mode; hope you're OK with that. I've finished the initial packaging of 1.35.0 and checked it in to SVN. It currently uses the same scheme we've always used, with unversioned -dev packages. I did, however, patch upstream to remove the toolset from the library names so there are fewer symlinks. It's not uploaded to experimental; I'm reconsidering the wisdom of doing so, since we should be able to get 1.35 packages (co-installable with 1.34.1) uploaded directly to unstable. I also removed the Boost library version from the link library names. However, reflecting upon what you say, I suppose we really prefer to have version X-dev and version (X+1)-dev co-installable. If so, we would revert that change and adjust the rules accordingly. By the way, before starting to fiddle with 1.35, I branched the trunk to pkg-boost/boost/branches/1.34.1. My thought is that any further development for 1.34.1 would live there. When the next boost version is released, we would again branch the trunk to branches/1.35.0 and work there for 1.35.0. Chimo, -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Bug#473752: Boost 1.35 has been released
On Fri, Apr 11, 2008 at 03:13:15PM -0400, Joshua Judson Rosen wrote: > Samuel Tardieu <[EMAIL PROTECTED]> wrote: > > > > Package: boost > > Severity: wishlist > > > Boost 1.35 has been released and contains great enhancements. Could you > > please update the Debian package? > > Seconded--I've been building my own boost packages for a while to get > Boost.Asio, which has been included in the mainline Boost distribution > as of 1.35.0. It'll be great to stop building my own and just use > Debian's :) > > If you guys need some help, I can try updating the packaging for 1.35. Help would be most welcome! Packaging is not the issue, however. I think I can do that over the weekend. The real issue is whether it can be uploaded this close to a freeze; for example, does it break any existing reverse dependencies? c.f. http://lists.debian.org/debian-devel/2008/03/msg00930.html So, assuming I can produce the packages, what would help is to have volunteers to test build all the things that build-depend on boost. If interested, please email. Thanks, -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Should we have two versions of Boost in the archive?
On Sun, Mar 30, 2008 at 07:38:14PM +0200, Pierre Habouzit wrote: > On Sun, Mar 30, 2008 at 05:22:45PM +0000, Steve M. Robbins wrote: > > Hello, > > > > A new version (1.35) of the Boost library collection was released > > yesterday. I'd like to get it packaged for Debian ASAP. > > You're aware that we're trying to release and that you shouldn't > upload things you are not sure will transition in time without > disturbing other transitions too much ? I'm aware of the release, yes. I should have spelled this out in more detail previously: to me, the "P" in "ASAP" means "possible, given the impact of a Boost transition on the impending Debian release." If the release folks consider it too risky, it will happen post-release. > Is there any immediate gain to those new libraries over 1.34.1 that > warrant such a haste ? There are a number of interesting new libraries; e.g. asio, fusion, math, mpi, and significant updates to existing libraries [1]. That is compelling to me, but I concede others may have a different view. [1] http://www.boost.org/users/news/version_1_35_0 > > The question is: whether to simply replace the existing version > > (1.34.1) as we have always done, or to have the old and new both > > available in the library? > > There should definitely be one only given that if I read the version > number correctly, 1.35 shouldn't be *that* disruptive wrt 1.34.1. Unfortunately, this is not the case. Boost is not guaranteeing ABI compatibility across releases, i.e. from 1.34 to 1.35. So don't read this as "major.minor" in the traditional sense. The SONAME has the complete version in the string; i.e. "1.34", "1.35". So with this in mind, let me ask my question slightly differently: Is the API change dramatic enough to warrant keeping two versions of Boost sources in the archive? Thanks, -Steve signature.asc Description: Digital signature
Should we have two versions of Boost in the archive?
Hello, A new version (1.35) of the Boost library collection was released yesterday. I'd like to get it packaged for Debian ASAP. The question is: whether to simply replace the existing version (1.34.1) as we have always done, or to have the old and new both available in the library? In the past, we've always supported a single version of boost. But changing versions seems to cause a lot of convulsions, so Domenico recently proposed that we have two versions of Boost sources in the archive and version each of the 13 -dev packages. On Wed, Feb 27, 2008 at 11:40:30AM +0100, Domenico Andreoli wrote: > It may sound even better if multiple Boost versions were considered, > packaging them in versioned source packages (ie boost-1.34.1, > boost-1.35.0). Respective -dev packages should then be also versioned > and conflicting each other, as the mostly undecorated symlinks there > provided. Having boost-defaults driving the default Boost and Python > versions and the completely undecorated symlinks. > > This, for instance, would allow Boost 1.35.0 in lenny while 1.34.1 > being the default one. I frankly doubt a full transition to 1.35.0 > would happen before the release of lenny. For some large systems (e.g. GCC, Qt, VTK), I see the utility of this approach in that each major version typically brings with it significant source incompatibility and forces client code to adopt. Some client code may not adapt immediately and can continue to build with the older version. I don't have a good sense whether this is the case with Boost. It may simply be that a Boost transition is a nuisance because it forces the recompilation of many client libraries, which in turn are widely used and therefore ends up involving a lot of packages. Or, indeed, whether this distinction makes no difference in deciding how to proceed. I'd appreciate your thoughts on whether having two Boost source versions in Debian is worth the packaging effort. Thanks, -Steve P.S. For the new version of Boost, I plan to remove the compiler version from the library SONAMES. signature.asc Description: Digital signature
Re: Bug#459511: Consider adding Perl License to common-licenses
On Wed, Jan 09, 2008 at 10:28:27AM -0800, Russ Allbery wrote: > "Steve M. Robbins" <[EMAIL PROTECTED]> writes: > > On Tue, Jan 08, 2008 at 11:18:24PM -0800, Russ Allbery wrote: > > >> I don't think it makes sense to include in common-licenses something > >> that's just a reference to other common licenses. It's not like the > >> boilerplate text for Perl modules is long; it's only about six lines, > >> and you'd still need to include at least a couple of lines to refer to > >> the file in common-licenses anyway. > > > True. But as I carefully explained: in my view, it's not about saving > > bytes; it's about labelling. And about avoiding copying errors, which > > manifestly take place. > > Wouldn't http://wiki.debian.org/Proposals/CopyrightFormat be a better way > to address the labelling concern? Thanks for the link. I like the proposal from the point of view of labelling. However: (1) This is only a proposal; common-licenses exists today. (2) I didn't grasp from the proposal whether the fully license text must appear in the copyright file (or in common-licenses). If we can simply put "License: GPL-1+ | Artistic" for a perl module, then I'm happy. If we have to put that PLUS the prose of the Perl license, then we're no further ahead. > As for copying errors, I don't disagree, but there are also a lot of Perl > modules that *aren't* covered under the same terms as Perl or that have > little niggling variations. We should also be including the copyright > statements from the authors in the Debian copyright file. At present, yes I agree that we should include the authors' copyright statements. Perhaps I should mention what started this whole bug report. I uploaded a package that included a Perl module with the following license. # Copyright (c) 1995-98 Greg Ward. All rights reserved. This package is # free software; you can redistribute it and/or modify it under the same # terms as Perl itself. When I tried to upload the package with *the author's* copyright statement in debian/copyrights (together with a reference to /usr/share/doc/perl/copyright), it was rejected by the ftp admins on the grounds of the following lintian error: copyright-file-lacks-pointer-to-perl-license If your package is released under the same terms as Perl itself, it should refer to the Artistic and GPL license files in the /usr/share/common-licenses directory. Refer to Policy Manual, section 12.5 for details. This forces me to REPLACE or AUGMENT the author statement with my own text. This is how the aforementioned copying errors arise. > I guess I'm a > bit skeptical that we gain that much in overall correctness in the > copyright file by providing easy access to boilerplate for people to refer > to. I'm worried that we'd just trade one form of errors (copying > mistakes) for another (referring to the boilerplate when it isn't > appropriate or without including sufficient information about the > non-boilerplate parts, like the copyright statement). I agree that someone might be sloppy about the license and inappropriately point to the boilerplate. But it is also true that today someone could be sloppy and inappropriately copy the text of /usr/share/doc/perl/copyright. I don't imagine that the presense of Perl's license in common-licenses would make it more likely; do you? To be clear: In all cases, the author copyright would be copied into debian/copyright. In those cases where it mentions something about "the same terms as perl", you can simply add a line to the effect "The Perl license may be found in /usr/share/common-licenses/Perl" rather than cutting and pasting the contents of /usr/share/doc/perl/copyright. Cheers, -Steve signature.asc Description: Digital signature
Re: Bug#436267: linux-image-2.6.22-1-686: IEEE1394 modules unbuilt in packaged kernel
On Thu, Dec 13, 2007 at 04:59:37PM +0100, maximilian attems wrote: > On Thu, Dec 13, 2007 at 09:50:56AM -0600, Steve M. Robbins wrote: > > > > Git repos are not relevant here. > > they are fucking important, but it seems that the firewire > lib maintainers are quite lame. I'm sad to read a response that seems to be blaming and finger-pointing. Debian is about building a *system* and we all need to work together to that end. It seems to me that if you make a change that in turn requires a change in other packages -- indeed, it explicitly *breaks* other packages -- then it is incumbent on you to work with the other package maintainers to achieve the required changes. In the present case, it appears that the libraw maintainer, for one, wasn't informed (c.f. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453358). -Steve signature.asc Description: Digital signature
Boost libraries name change (again)
**NOTE** **NOTE** **NOTE** **NOTE** **NOTE** **NOTE** **NOTE** The boost library short name has changed semantics in Debian. Prior to 1.34.0-1, the short name was multi-threaded. Now it is single threaded. **NOTE** **NOTE** **NOTE** **NOTE** **NOTE** **NOTE** **NOTE** Hello, A new version of the Boost C++ libraries was been uploaded to unstable last night, so I thought I'd send an update on the state of boost -- particularly the library names. Boost library names encode the SOVERSION and build characteristics of the library, including the compiler used (gcc41) and whether multi-threading is enabled (-mt if so). This leads to long names like libboost_wserialization-gcc42-mt-1_34_1.so.1.34.1 [http://www.boost.org/more/getting_started/unix-variants.html#library-naming] that are hard to discover in the build system of boost-using software. Prior to 1.34.0-1, the previous upload to unstable, the Debian packages provided a NON-PORTABLE short form of the library name as a convenience. The short form (e.g. libboost_wserialization.so) did not have the compiler or "-mt" strings in the name, even though it was the multi-thread flavour. Other distributions, e.g. Fedora, use the so-called "layout=system" install and also have shorter-named boost libraries. However, the short-named libraries are the single-threaded flavour. The multi-threaded flavour has "-mt" appended, e.g. libboost_wserialization-mt.so). On the last upload to unstable (in May), we replaced the single shorter-named library with a pair: the multithreaded version with -mt suffix and the singlethreaded version with -st suffix. The removal of the shortcut library name broke several dependent packages and, understandably, caught folks off-guard. We apologize for that confusion. After some discussion, both internal and on bug reports #429533, #424038, #425264, #428419, #431502, and #425992, we decided to remove the "-st" suffix, restoring the short-name library and bringing our names in line with "layout=system", hence compatible with other distributions. This means that the short name has changed semantics from being the multi-threaded flavour to being now the single-threaded flavour. We realize this is going to cause some upheaval yet again, and we apologize for that. Hopefully we can agree that keeping API compatibility across distributions is worthwhile. To summarize what this means for you: 1. If you're linking to libboostX for a multi-threaded application, append "-mt". 2. If you're linking to libboostX-st, remove the "-st". Otherwise, relax. Other changes with this upload -- * It is built with the current python, version 2.4. There is no python 2.5 packages at present. We intend to seek upstream support for parallel installs Boost.Python. Email if you have any suggestions. * No pkgconfig support yet. We intend to work with upstream and other * distributions on this. Email if you have any suggestions. On behalf of the Debian Boost Team, -Steve signature.asc Description: Digital signature
libsoqt change Qt3 -> Qt4: change package?
Hi, I need some guidance from library packaging gurus. Libsoqt is a library that is currently linked with Qt3. I've had a request to rebuild it with Qt4 instead (#415382) which can be done by simply changing the configuration. Can I simply upload the reconfigured shared library package, which now depends on the qt4 packages rather than qt3 packages? Or do I need to change the SONAME? Or do I keep the SONAME but put it into a new package, like we do for the gcc ABI transitions? If so, is there a convention or do I just pick a suffix I like (e.g. qt4)? Thanks, -Steve signature.asc Description: Digital signature
Re: uninstallable despite satisfying dependencies
On Tue, Jul 10, 2007 at 08:40:31PM -0700, Steve Langasek wrote: > Hi Steve, > > On Tue, Jul 10, 2007 at 10:03:16PM -0500, Steve M. Robbins wrote: > > > How do I debug this situation: ipe won't install, yet I have the > > dependencies that "apt-get install" complains about. > > > Below, you will see that my attempt to install libipe1c2a claims to > > have three unmet dependencies. However, as you see by "dpkg --list", > > I *do* have these three packages at a version that seemingly satisfies > > the dependencies. > > > > What gives? > > Hmm, I was all ready to file an RC bug about this, only to find that you're > the maintainer... :) > > Can you explain why libipe1c2a gives the behavior described in bug #369244? Ah, yes. I added a Conflicts: libfreetype6 (>= 2.2.2) to libipe1c2a and forgot about it :-/ OK. That explains my problem: faulty memory. > This looks like ipe is misusing freetype, if it refuses to work with newer > versions when these versions are ABI-compatible. The short answer is -- this is the claim of Ipe's author, not me -- libfreetype frequently breaks ABI compatibility even with minor-version updates. So ipe has an explicit check of the freetype version. Thanks Steve, -Steve signature.asc Description: Digital signature
uninstallable despite satisfying dependencies
Hi, How do I debug this situation: ipe won't install, yet I have the dependencies that "apt-get install" complains about. Below, you will see that my attempt to install libipe1c2a claims to have three unmet dependencies. However, as you see by "dpkg --list", I *do* have these three packages at a version that seemingly satisfies the dependencies. What gives? [EMAIL PROTECTED] install libipe1c2a Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: libipe1c2a: Depends: libfreetype6 (>= 2.2) but it is not going to be installed Depends: libqt4-core (>= 4.2.3) but it is not going to be installed Depends: libqt4-gui (>= 4.2.3) but it is not going to be installed E: Broken packages [EMAIL PROTECTED] --list libfreetype6 libqt4-core libqt4-gui Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++--- ii libfreetype6 2.3.5-1 FreeType 2 font engine, shared library files ii libqt4-core 4.3.0-2+b1 Qt 4 core non-GUI functionality runtime library ii libqt4-gui 4.3.0-2+b1 Qt 4 core GUI functionality runtime library Thanks, -Steve signature.asc Description: Digital signature
Re: Bug#430266: ldbl128 transition for alpha, powerpc, sparc, s390
On Sat, Jun 23, 2007 at 03:48:06PM +0200, Matthias Klose wrote: > Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html There's not a lot of discussion there -- just an announcement really. > With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double' > data type did change from a 64bit representation to a 128bit > representation on alpha, powerpc, sparc, s390. The referenced message, above, is over three weeks old. Is that when the change went in? Does that mean any package on the list built since then is buggy? > To allow partial upgrades of packages, we will need to rename all > packages holding libraries with the long double data type in their > API. So what upgrades are we worried about? If packages built in the last three weeks are buggy, they may already be in "testing". So we're not to worry about upgrades from testing versions? If we're only worried about upgrades from the version in stable, then we don't need to rename a package that has never been in stable, correct? > Both libc and libstdc++ do not need to be renamed, because they > support both representations. We rename the library packages on all > architectures to avoid name mismatches between architectures (you > can avoid the renaming by supporting both datatype representations > in the library as done in glibc and libstdc++, but unless a library > is prepared for that, it does not seem to be worth the effort). How is it that libc and libstdc++ support both representations? How would another library support both? Thanks, -Steve signature.asc Description: Digital signature
project machine architecture aliases
Hi,
I have another "wishful thinking" idea for build machines to float.
Suppose I get a bug report saying my package has failed to build on
architecture glooble. I don't personally have a globle machine. To
debug the problem, I need to fire up www.debian.org/devel, find the
link to the list of project machines, scan the list for the name of a
glooble machine (which is likely to be the name of a completely
unrelated composer of music). Finally, I can log in.
Wouldn't it be nice if I could just do: "ssh glooble.dev.debian.org"
and have that be an alias to some machine of architecture glooble?
I'm assuming that there's a way to do fancy DNS load balancing amongst
the machines of type glooble that are currently available.
My idea is that there be one alias for each architecture, preferably
something easy to remember, such as ${arch}.dev.debian.org. It would
be an alias for "any available machine of class ${arch}". It's not
intended to be a replacement for the list on www.debian.org/devel, so
if I need to get to a specific machine, I still can consult the list.
Thoughts?
-Steve
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
