Please unblock cfortran
Hi RMs, Could you please unblock cfortran 4.4-13 once it has exceeded the 10-day waiting period? > cfortran (4.4-13) unstable; urgency=low > > * Bump Standards-Version to 3.8.0 (no changes). > * Make the default behavior on CYGWIN, Linux (with gcc) and OS X be to > assume gfortran (rather than g77/f2c) if the FORTRAN compiler has > otherwise been left unspecified. Thanks Davide Mancusi for the prod. > * Fix a buffer overrun bug found by Jean-Guillaume Piccinali in one of > the example programs (fd/fd.c). (Closes: #489886.) > > -- Kevin B. McCarty <[EMAIL PROTECTED]> Tue, 26 Aug 2008 20:55:16 -0700 This upload should be extremely low risk. Changing the default behavior of cfortran.h to assume that the FORTRAN compiler is gfortran instead of g77 matches the default to the current default FORTRAN compiler in Lenny. Thanks for your consideration, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Re: New ftgl-dev seems to cause breakage
Hi Sam, Bastian, Christian, On Sun, Jun 22, 2008 at 11:42 AM, Bastian Blank <[EMAIL PROTECTED]> wrote: > On Sun, Jun 22, 2008 at 10:58:24AM -0700, Kevin B. McCarty wrote: >> It has apparently caused breakage in a package I'm sponsoring, see >> http://buildd.debian.org/build.php?arch=&pkg=root-system . > > There is no sign of a sucessfull build, so how do you compare them? It built OK in my pbuilder a few days ago, when I built it for i386 for the upload. That must have been before the new FTGL hit unstable. > amd64, mipsen and sparc fails with undefined functions: > | gl/src/TGLText.cxx:88: error: 'glPushMatrix' was not declared in this scope > > gl* is part of OpenGL, not ftgl. Most likely it lacks the > include. Maybe they ftgl headers included that on its own before. I think you're right, and that must be the case. I added a #include to the one file (ROOT's gl/src/TGLText.cxx) where the compiler errored out, and then things continued successfully in my updated Sid chroot. So I guess the Release Team would characterize this as something akin to g++-4.3 being more strict about include files, and therefore something that must be fixed on the client side rather than changed back in FTGL? Anyway, after that fix, the ROOT build proceeded until this point: /usr/bin/ld: cannot find -lftgl_pic collect2: ld returned 1 exit status make[1]: *** [lib/libRGL.so] Error 1 but I imagine that since FTGL now builds a shared lib there is no longer a need for the PIC library. We can pretty easily fix these two items in ROOT and make a new upload, so my apologies to Sam and the Release Team for the noise. I may have overreacted -- it was just an unpleasant surprise to see that a package I sponsored (and that we hope can get into Lenny before the freeze) had FTBFSed everywhere. Christian, is it the right fix to add the #include to that file? Also, are you easily able to change the ROOT configure script so it can search for (in decreasing order of preference) libftgl.so, libftgl_pic.a and libftgl.a in order to try to remain Etch-compatible? If not, I guess don't worry about it and just use -lftgl. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
New ftgl-dev seems to cause breakage
Hi Release Team, apparently a new API-changing version of ftgl-dev was recently uploaded to unstable (which strikes me as a bad idea at this point!). It has apparently caused breakage in a package I'm sponsoring, see http://buildd.debian.org/build.php?arch=&pkg=root-system . Maybe this also causes problems for other rdepends? Wanted to give you a heads-up. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: expat transition or update - before or after lenny?
Adeodato Simó wrote: > However, I'm not sure who mentioned this possibility, but shipping > /usr/lib/libexpat.so.0 within wink sounds very ugly to me. It was me that suggested it ... > If upstream > won't update their binary, and you want to drop the symlink, on possible > solution is that wink ships a symlink in /usr/lib/wink/libexpat.so.0, > and uses LD_LIBRARY_PATH=/usr/lib/wink from the /usr/bin/wink wrapper > script. ... but I agree that this proposal is much better, especially since /usr/bin/wink is already a wrapper script anyway. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Re: RFC: expat transition or update - before or after lenny?
(Sent from my old Princeton account since Gmail is being broken)
Frank Lichtenheld wrote:
> On Wed, May 28, 2008 at 11:06:21AM +0600, Alexander E. Patrakov wrote:
>> Adeodato Simó wrote:
>> >Regarding the libexpat0-compat package, note that it is only needed for
>> >stuff that we *can't* rebuild, since stuff that we can will be rebuilt
>> >anyway.
>>
>> As a quick-and-dirty solution for some non-free software, won't running a
>> sed substitution ("libexpat.so.0" -> "libexpat.so.1") on the problematic
>> binary help?
>
> AFAICT we do not have the permission to modify the binary.
>
> So someone would have to contact upstream either way.
Could the sed be done in the postinst of the package? Then Debian would
at least not be *distributing* a modified binary. Would that change the
legality any?
If that still isn't permissible, here's another thought: Since wink
appears to most probably be the ONLY package in Debian that needs
libexpat.so.0 (as I wrote in [1]), it might make some sense to just ship
the compatibility symlink in the wink package, with an appropriate
"Replaces: libexpat1 (<= [last version with compat symlink])"
line.
The wink package would also need to have an explicit Depends: libexpat1
(which it really ought to do anyway, even before any transition).
[1] http://lists.debian.org/debian-release/2008/05/msg00428.html
best regards,
--
Kevin B. McCarty <[EMAIL PROTECTED]>
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751
signature.asc
Description: OpenPGP digital signature
Re: RFC: expat transition or update - before or after lenny?
> Adeodato Simó wrote:
>> So, to get this moving, who does the archive inspection?
I wrote:
> As it happens, I already had a script prepared that did something very
> similar (for the purpose of looking for mis-compiled gfortran code on
> mips*). I've modified it to look for r-depends of libexpat1 containing
> ELF files having a NEEDED libexpat.so.0 and it's running now. (At the
> moment it's processing packages in Etch; on i386, amd64 and powerpc
> architectures; main, contrib and non-free components). Should be done
> in a few hours, and I'll post the results and the script here. Let me
> know if you'd like me to search additional architectures or distributions.
I've finished with the script run (the script is attached for
completeness although it is pretty straightforward), and the conclusion
is this: of the packages with a direct dependency on libexpat1, NONE of
them (in Etch on i386, amd64, or powerpc; looking at main, contrib and
non-free) contain an ELF file with NEEDED libexpat.so.0.
What about the wink package, you ask? It turns out that wink doesn't
declare a package dependency on libexpat1. It avoids an RC bug because
the dependency still exists indirectly through the chain
wink -> libgtk2.0-0 -> libfontconfig1 -> libexpat1.
How is it that wink doesn't pick up libexpat1 via ${shlibs:Depends}?
The only Build-Dep of wink source package is debhelper, since the
"source" package actually ships a tarball of pre-compiled binaries (wink
being in non-free). So libexpat1 wasn't installed on the build system
at the time dh_shlibdeps was run from wink's debian/rules. I guess this
may be a general weakness of non-free "source" packages that ship
pre-compiled binaries. (There does not seem to be a Lintian check for
this, presumably because such a check would require Lintian to know the
mapping from the library sonames in NEEDED to package names.)
This implies that it is also necessary to examine non-free packages with
an *indirect* dependency on libexpat1. I did so on Etch/i386 by taking
the output of "apt-cache --recurse rdepends libexpat1" and extracting
the subset of packages which are in non-free with Arch: i386 (rather
than Arch: all), and also missing a direct libexpat1 dependency (since
the packages with direct libexpat1 dependency were already checked).
There are 101 such binary packages on Etch/i386. The only one which has
an ELF file with NEEDED libexpat.so.0 is wink.
Of course it's conceivable that there is a pre-compiled binary packaged
on some non-i386 architecture that needs libexpat.so.0. But the vast
majority of pre-compiled binaries for Linux are made available only for
i386, so I think it's quite unlikely. Thus I'd suggest just contacting
wink upstream about a fix, and not bothering about a libexpat0
compatibility package.
best regards,
--
Kevin B. McCarty <[EMAIL PROTECTED]>
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751
libexpat0-detector.sh
Description: application/shellscript
signature.asc
Description: OpenPGP digital signature
Re: RFC: expat transition or update - before or after lenny?
Hi, Adeodato Simó wrote: > Hello again, excuse me that I don't reply inline. > > If, as it seems, you really want to get rid of the symlink, then the > first step is to find out what stuff uses the old name. > > As you suggest, this can be done by unpacking every r-dependency of > libexpat1, and running objdump -p on all ELF archives. If you'd rather > not do that yourself, I can do it for you. (Note that when picking what > version to unpack, stable should be preferred over testing, and testing > over unstable.) [...] > So, to get this moving, who does the archive inspection? As it happens, I already had a script prepared that did something very similar (for the purpose of looking for mis-compiled gfortran code on mips*). I've modified it to look for r-depends of libexpat1 containing ELF files having a NEEDED libexpat.so.0 and it's running now. (At the moment it's processing packages in Etch; on i386, amd64 and powerpc architectures; main, contrib and non-free components). Should be done in a few hours, and I'll post the results and the script here. Let me know if you'd like me to search additional architectures or distributions. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Re: Please consider bin-NMUs of certain gfortran-using packages on mips/mipsel
Luk Claes wrote: > Kevin B. McCarty wrote: >> Hi Release Team, > > Hi > >> as I mentioned previously [1], a bug in gfortran 4.3 [2,3] caused some >> FORTRAN code using SIN() / COS() functions to be miscompiled on mips and >> mipsel with -O1 or greater. Thanks to Jakub Jelinek and Matthias Klose, >> this bug should now be fixed in version 4.3.0-4 of Debian's gfortran-4.3 >> package. [...] > Scheduled. Thanks! Just to keep the Release Team up-to-date on this issue: nearly all of the relevant packages now have fixed mips and mipsel versions (either due to bin-NMUs or to new maintainer uploads in the meantime) in both unstable and testing. The single exception is raster3d, which has fixed versions in unstable but still has an older version (2.7d+0-1) in testing, due to a dependency [0] on the new "ghostscript" binary package which has not yet entered testing. I guess these will enter testing together in a few days [1]. [0] http://bjorn.haxx.se/debian/testing.pl?package=raster3d [1] http://bjorn.haxx.se/debian/testing.pl?package=ghostscript best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Re: SRMs: Should maxdb-related packages be removed from Etch?
Philipp Kern wrote: > On Wed, May 14, 2008 at 05:19:26PM +0200, Moritz Muehlenhoff wrote: >> Please file a removal bug for stable against ftp.debian.org >> (latest versions of reportbug make that very easy) > > For the record: release.debian.org. It's not really documented yet and > the bugs are reassigned to us by the ftpteam, but still, as removals > can only be done at point release time anyway... Bug filed as #481231 against pseudopackage release.debian.org. Thanks and best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Bug#481231: RM: maxdb-7.5.00/stable -- ROST; Unfixable security bug, upstream went non-free
Package: release.debian.org Severity: important Dear Stable Release Managers, as discussed on debian-release [1] and acked by Security Team [2], please remove source package "maxdb-7.5.00" and related packages (listed below) from Etch. Maxdb has a serious security bug [3,4] which is basically unfixable according to the erstwhile maintainer [5], and has already been removed from Sid [5]. No support from upstream is expected as they took the package closed-source. [1] http://lists.debian.org/debian-release/2008/05/msg00136.html [2] http://lists.debian.org/debian-release/2008/05/msg00234.html [3] http://bugs.debian.org/461444 [4] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0244 [5] http://bugs.debian.org/461456 The following source packages have dependencies on maxdb and should also be removed from Etch (as has already occurred in Sid). (Numbers in parentheses are the bug number for the removal request from Sid.) libdbd-maxdb-perl (#461479) php-maxdb (#461480) The following source packages have no reason to be shipped in Etch once maxdb is removed, so they should also probably be removed: maxdb-doc (#461481) maxdb-buildtools (#461482) libsapdbc-java (#461483) Thanks and best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
SRMs: Should maxdb-related packages be removed from Etch?
Hi SRMs, I just noticed this in http://ftp-master.debian.org/removals.txt : > [Date: Sun, 20 Jan 2008 00:44:40 +] [ftpmaster: Joerg Jaspert] > Removed the following packages from unstable: [snip] > maxdb-7.5.00 | 7.5.00.44-2 | source [snip] > Closed bugs: 461456 > > --- Reason --- > RoM; security issues, upstream closed source > -- Should the maxdb-7.5.00 source package perhaps also be removed from Etch for these reasons? The security bug is #461444 and has CVE number CVE-2008-0244. Upstream has taken the package closed-source and apparently there is no easy fix for the security problems. I don't see any indication that there is an intent to release a security update for the Etch packages. If you decide to remove maxdb-7.5.00 source package from Etch, the following dependent source packages should also be removed: libdbd-maxdb-perl (#461479) php-maxdb (#461480) The following would not need to be removed for dependency reasons, but they would no longer have any reason to be shipped: maxdb-doc (#461481) maxdb-buildtools (#461482) libsapdbc-java (#461483) best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Testing migration doesn't check build-depends?
Hi, paw 1:2.14.04.dfsg.2-4 has just migrated to testing, but it Build-Depends on debhelper (>= 6.0.12) while debhelper in testing is still only 6.0.11. So paw in testing would now FTBFS if an attempt was made to rebuild it there. Is this normal behavior? Sorry if this is an FAQ or something. Seems to be related to #145257 but I find it surprising that hasn't been fixed by now. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Please consider bin-NMUs of certain gfortran-using packages on mips/mipsel
Hi Release Team, as I mentioned previously [1], a bug in gfortran 4.3 [2,3] caused some FORTRAN code using SIN() / COS() functions to be miscompiled on mips and mipsel with -O1 or greater. Thanks to Jakub Jelinek and Matthias Klose, this bug should now be fixed in version 4.3.0-4 of Debian's gfortran-4.3 package. The following source packages in "main" were built with gfortran-4.3 prior to 4.3.0-4 and appear to be affected by the bug. Could you please consider scheduling bin-NMUs of these packages, with a dep-wait on gfortran-4.3 4.3.0-4? # a bin-NMU is apparently only needed on mips: apbs/0.5.1-2 # a bin-NMU appears to be needed on both mips and mipsel: abinit/5.3.4.dfsg-3 atlas/3.6.0-21.4 blacs-mpi/1.1-28 blacs-pvm/1.1-19 fasianoptions/260.72-4 lapack/3.1.1-0.4 mn-fit/5.13-6 octave2.1/1:2.1.73-19 octave3.0/1:3.0.1-2 python-scipy/0.6.0-11 saods9/4.0b7-2 scalapack/1.8.0-2 wsjt/5.9.7.r383-1.2 The following packages in "contrib" and "non-free" also appear to be affected, but I don't know whether packages in those sections can be automatically bin-NMUed. Therefore I also CC their maintainers. Please keep them in CC regarding this question. # In contrib (only on mips; ifeffit has never been built on mipsel) ifeffit/2:1.2.10a-4 # Note: a newer version of ifeffit, 2:1.2.10a-5, needs to be built on # mips anyway so there is no point in doing a bin-NMU of ifeffit. # In non-free on both mips and mipsel: pgplot5/5.2.2-14 raster3d/2.7s-1 scilab/4.1.2-4 # Note: a newer version of scilab, 4.1.2-5, needs to be built on # mips and mipsel anyway so there is no point in doing a bin-NMU of # scilab. The above lists are based on re-running my script from [1], plus manual review of the buildd logs for packages that are newer than they were at the time of my previous email. Uninteresting caveats: It is conceivable there could be a few false positives (for binaries that combine FORTRAN and C code and use sincos() within the C portion) but I think this is unlikely and not worth the trouble to weed them out. There may also be a couple other false positives for packages whose buildd logs were not available but which were already built with gfortran-4.3 4.3.0-4. But it shouldn't hurt anything to do a bin-NMU in either of those cases. Finally, note that I would not have detected any source package that is affected but which builds only object files (*.o), static libraries, and/or binaries statically linked against libm or libgfortran. Again, I think it's unlikely that there exists such a source package. [1] http://lists.debian.org/debian-release/2008/04/msg00267.html [2] http://gcc.gnu.org/PR35662 [3] http://bugs.debian.org/476427 best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Re: question about propagation of testing packages to new arch (armel)
Andreas Barth wrote: > * Andreas Barth ([EMAIL PROTECTED]) [080423 21:36]: >> * Kevin B. McCarty ([EMAIL PROTECTED]) [080423 18:20]: >>> Would you be able to tell me how long I need to wait before they get >>> into testing on armel? (I'd like to upload a new release of one of them >>> soon.) Or does it require a manual hint from the Release Team? >> It requires a bug fix in our testing migrating script which is hopefully >> deployed for tonights run. I'll review your packages after that run - >> might be that there is more to do for some of them. Let's see ... > > All five are now migrated. OK, thanks for the checking and the bug fix! best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
question about propagation of testing packages to new arch (armel)
Hi Release Team, I have a question about when some of my packages will propagate into testing on armel. They had never been built on armel before, so they got into testing on all other release architectures, while still missing armel builds, several days ago. Since then, the armel buildds have finally caught up with them. But the packages are (at this moment) listed on packages.debian.org for armel only under unstable, not under testing. Would you be able to tell me how long I need to wait before they get into testing on armel? (I'd like to upload a new release of one of them soon.) Or does it require a manual hint from the Release Team? The packages in question are these: cernlib/2006.dfsg.2-13 paw/1:2.14.04.dfsg.2-3 mclibs/2006.dfsg.2-5 geant321/1:3.21.14.dfsg-8 mn-fit/5.13-6 Thanks for your time, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
List of packages most probably affected by PR35662
I wrote: > I will post the list of packages that appear to be affected by PR35662 > later today in a follow-up message to [EMAIL PROTECTED] For your information, here is a list of source packages for which current mips(el) binary packages in Sid are almost certainly affected by gfortran PR35662 [1], as of 2008-04-16 at roughly 17:00 UTC. The list may be incomplete; see remarks below. The versions of these packages in Lenny are also most likely affected unless otherwise noted. [1] http://gcc.gnu.org/PR35662 Please do not take any action on this list just yet. ==> On both mips and mipsel, in "main": abinit/5.3.4.dfsg-3 atlas/3.6.0-21.3 blacs-mpi/1.1-28 blacs-pvm/1.1-19 lapack/3.1.1-0.4 mn-fit/5.13-6 octave2.1/1:2.1.73-19 octave3.0/1:3.0.0-11 python-scipy/0.6.0-11 [version 0.6.0-10 on mipsel] saods9/4.0b7-2[not in testing] scalapack/1.8.0-2 [not in testing] wsjt/5.9.7.r383-1.1 ==> Only on mips, in "main": apbs/0.5.1-2 [mipsel binary has no sincos reference] ==> Only on mips, in "contrib": ifeffit/2:1.2.10a-3 [never built on mipsel; version in testing was built with gfortran-4.2 so unaffected] ==> On both mips and mipsel, in "non-free": pgplot5/5.2.2-14 raster3d/2.7d+0-2 [version 2.7s-1 on mipsel; version in testing was built with gfortran-4.1 so unaffected] scilab/4.1.2-4 Caveats: I only checked binary packages with a direct dependency on libgfortran3. Since the script I used to do the checking used "nm -D", static libraries, statically linked binaries, and object files (*.o) were also not checked. So most probably any libdevel source package that generates only a static library (but no shared lib) did not get checked. After a fixed gfortran-4.3 package is available, I will recreate the above list in order to request bin-NMUs. Ideally, a fixed gfortran-4.3 package should be permitted to migrate into Lenny. Otherwise, later security builds of these packages in Lenny would re-break things. The script I wrote to do the checks is attached. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 sincos-and-gfortran-detector.sh Description: application/shellscript signature.asc Description: OpenPGP digital signature
Bug#476427: gfortran-4.3: Please include patch for PR35662 to fix problem on mips(el)
Package: gfortran-4.3
Severity: important
Tags: patch
Hi gcc-4.3 maintainers,
Could you please include the patch fixing gfortran PR35662 [1] available
from [2]? This issue is likely to break a fairly large amount of
FORTRAN code that has been compiled with optimization level -O1 or
greater with gfortran-4.3 on mips and mipsel.
[1] http://gcc.gnu.org/PR35662
[2] http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134352
(I apologize for not requesting this earlier, but the patch from gcc
upstream was not available until today.)
Release team: if such a release of gcc-4.3 is prepared, is there any
possibility of getting it into Lenny?
If it is possible to include this patch in a version of gfortran-4.3
that can be included in Lenny, then I will request bin-NMUs on mips and
mipsel for all packages containing libraries or binaries that both
(a) are linked against libgfortran.so.3 and (b) appear to use sincos{,f,l}.
I will post the list of packages that appear to be affected by PR35662
later today in a follow-up message to [EMAIL PROTECTED]
best regards,
--
Kevin B. McCarty <[EMAIL PROTECTED]>
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751
signature.asc
Description: OpenPGP digital signature
Re: please give-back cernlib/2006.dfsg.2-13 on arm
Steve Langasek wrote: > On Thu, Mar 27, 2008 at 11:38:20AM -0700, Kevin B. McCarty wrote: >> Hi release team, > >> Cernlib 2006.dfsg.2-13 did not build on arm [0] due to a segfault in ld. >> However, previous versions built successfully on arm, and -13 has no >> arm-visible code changes relative to -12. Would it be possible for you >> to give-back cernlib to the arm buildds, maybe trying to have it build >> on a different machine than "europa"? > > Given back. (Getting it to a buildd other than europa is a crapshoot, but > the odds are good.) Thank you, it built successfully on toffee. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
please give-back cernlib/2006.dfsg.2-13 on arm
Hi release team, Cernlib 2006.dfsg.2-13 did not build on arm [0] due to a segfault in ld. However, previous versions built successfully on arm, and -13 has no arm-visible code changes relative to -12. Would it be possible for you to give-back cernlib to the arm buildds, maybe trying to have it build on a different machine than "europa"? [0] http://buildd.debian.org/build.cgi?pkg=cernlib;ver=2006.dfsg.2-13;arch=arm Thanks and best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Re: Please give-back cernlib on mipsel
Steve Langasek wrote: > On Tue, Mar 04, 2008 at 09:25:43AM -0800, Kevin B. McCarty wrote: > >> Could you please give-back cernlib version 2006.dfsg.2-11 on mipsel? It >> previously failed to build on Feb. 29 [1] due to an attempt to compile >> it before a build-dependency (liblapack-dev) was available. (Not sure >> why it wasn't just dep-wait'ed.) The needed build-dependency >> liblapack-dev is now built and available for all release-candidate >> architectures. > > The most recent build failure of this package is caused by a buildd timeout > instead: > http://buildd.debian.org/fetch.cgi?pkg=cernlib&arch=mipsel&ver=2006.dfsg.2-11&stamp=1204661434&file=log&as=raw Hmm, I didn't see that one yet when I wrote the email. Thanks for calling it to my attention. It looks like a number of the test suite programs failed anyway, so back to the drawing board. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please give-back cernlib on mipsel
Hi release team, Could you please give-back cernlib version 2006.dfsg.2-11 on mipsel? It previously failed to build on Feb. 29 [1] due to an attempt to compile it before a build-dependency (liblapack-dev) was available. (Not sure why it wasn't just dep-wait'ed.) The needed build-dependency liblapack-dev is now built and available for all release-candidate architectures. Thank you! [1] http://buildd.debian.org/build.php?&pkg=cernlib&ver=2006.dfsg.2-11&arch=mipsel -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Please give-back mclibs on ia64
Hi release team, Please retry building "mclibs" source package 2006.dfsg.2-3 on ia64. The previous build failed in a strange way [1], most likely because it was simply interrupted [2]. [1] http://buildd.debian.org/build.php?&pkg=mclibs&ver=2006.dfsg.2-3&arch=ia64 [2] http://lists.debian.org/debian-ia64/2008/01/msg00012.html (Note that the build failure mentioned at [2] is what is supposed to have been fixed by -3.) Thanks and best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 signature.asc Description: OpenPGP digital signature
Re: fw: gfortran transition release goal proposal
George N. White III wrote: > This transition should not be a tied to gfortran and the gcc toolchain. When > the code has to change, it should be made to conform to current standards, > or in a few years we will doing it all over yet again. One approach would be > to adopt the POSX Fortran bindings, the other is to use the current Fortran > standard. The former has pxf_getarg(), while the latter provides: > > call GET_COMMAND_ARGUMENT(iarg, buf, ilen, ierror) > > There was an open source implementation of the POSIX fortran bindings > by Ron Shepard at ANL, and at least one independent implementation has > been mentioned on c.l.f. > What do you suggest for *C/C++* code that, for whatever reason, needs to call GETARG() or whatever the modern equivalent is from a FORTRAN library? best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fw: gfortran transition release goal proposal
On 7/26/07, Christian Holm Christensen <[EMAIL PROTECTED]> wrote: If developers write their `configure' script properly, it shouldn't be too much of a problem. The idea is, check for libraries, adding them to the `LIBS' variable (AC_CHECK_LIB does that), and at the end you check for missing functions (at this point you will link your test against the LIBS) and implement them, if any, via replacement code. Of course, if you have two orthogonal libraries, both implementing the fix, you could still get into trouble. Right, that's exactly what I'm concerned about. It could easily happen that some user wants to link his/her FORTRAN program against two independent trees of FORTRAN libraries, e.g. cernlib + MPICH, each including this hack, and then boom! conflicting getarg_ symbols. Anyone know offhand if this causes a linker failure (and if there is any difference depending on whether one or both of the libraries is linked statically), or if the compiler / runtime linker just arbitrarily picks one of the two dummy getarg_'s? -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fw: gfortran transition release goal proposal
Adam C Powell IV wrote: > So it seems getarg, which is needed for mpich, is missing from gfortran, > as are other variants used by other fortran compilers. Is there a > gfortran equivalent? > > Thanks, > -Adam I've been using this hack for getarg, building it into the base Cernlib library "libkernlib" only in the case of compiling with gfortran: * Begin getarg.F * Wrapper GETARG routine for gfortran, * originally written by Harald Vogt * SUBROUTINE GETARG (JARG, CHARG) * The following stuff is required to use gfortrans inline routine * It is required to avoid the calling GETARG here which conflicts * to the Fortran rules CHARACTERCHARG*(*) CALL MYGETARG (JARG, CHARG) END SUBROUTINE MYGETARG (JARG, CHARG) CHARACTERCHARG*(*) * gfortran translates the following line to a call * to its library routine _gfortran_getarg_i4 * therefore it will not clash in the linking step CALL GETARG (JARG, CHARG) END * End getarg.F Note, I haven't checked that this still works with gfortran-4.2. Of course, this won't help your configure script not to fail. Also, in the long run this is not a good solution, since there could be problems if this object code appears in several different linked libraries (especially if there are different versions). Would be better if the missing getarg_ symbol could be put into libgfortran. N.B. I want to emphasize that since I haven't uploaded a version of Cernlib compiled against gfortran yet, this hack doesn't exist in any object code already in Debian (to the best of my knowledge). best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fw: gfortran transition release goal proposal
Riku Voipio wrote: > Hi, > > The proposal to transition from the outdated g77 to gfortran did > not result any comments. Which rises the suspicion that the maintainers > of affected packages are not reading debian-release or debian-toolchain. > > If you have suggestions, critique, or you are busy but accept NMU'ing > your packages for gfortran transition.. please speak now. Hi Riku, I did see it and it seemed very reasonable. I am waiting to hear about a suggested order in which the blas-depending packages should be uploaded. Cernlib-related components can be uploaded in the following order once blas, lapack (and ideally atlas) are taken care of: cernlib mclibs / paw (these two are independent) geant321 / mn-fit (these are independent but must each follow paw) I'd prefer to do the uploads myself since these packages are rather finicky. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please give-back geant321 on mips, mipsel, sparc
Dear RMs, Could you please give-back geant321 on mips, mipsel and sparc? Those architectures all tried to build it before one of the build dependencies (libpawlib-lesstif3-dev) was available, and they have not re-attempted the build since. I also notice that the geant321 m68k debs are missing even though it was built successfully on "crest" and supposed to have been uploaded on June 11 according to http://buildd.debian.org/pkg.cgi?pkg=geant321 Whom should I contact about that? Thank you, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Latest OOo Etch update -7etch1 depends on different libneon
Hi, I noticed that the latest OpenOffice.org security update in Etch (version 2.0.4.dfsg.2-7etch1, which fixed DSA 1307) depends on libneon25 whereas the previous Etch version (2.0.4.dfsg.2-5etch1) depended instead on libneon26. Are changes in the depended package names, which require a dist-upgrade, in security updates considered a bug? If so, should I bother filing it? (For what it's worth, OOo packages in testing and unstable depend on libneon25.) regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SRMs: Possible to get a fix for viewcvs in Etch so it works with Etch cvs?
Dear SRMs, Following up to http://blog.zobel.ftbfs.de/debian/packages-considered-for-40r1 (and repeating my comment from there so the whole stable release team will see it): Is there any chance to get in a fix for #422141, in which the viewcvs and cvs packages in Etch don’t play well together, into Etch 4.0r1? I don’t see a patch anywhere in the bug log, but since the problem is caused by a single extra line in CVS’ version control files, I can’t imagine it is hard to fix. I understand this fix may not be a high priority without a patch, and if I have time in the future (not necessarily a safe assumption) I will endeavor to provide one. Thanks and best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#423136: apt-move: built against experimental libgcc1 and libstdc++6
Chuan-kai Lin wrote: > On Wed, May 09, 2007 at 10:05:04PM -0700, Kevin B. McCarty wrote: >> apt-move is currently uninstallable in unstable (at least on i386) since >> it depends on libgcc1 (>= 1:4.2-20070208) and libstdc++6 (>= >> 4.2-20070208). Maybe it was by accident built against gcc 4.2 on the >> maintainer's machine? If so, a bin-NMU should suffice to fix it, >> assuming it's bin-NMU safe. > > Good catch -- it never occurred me to check that before uploading the > i386 binary. I can probably whip up an unstable chroot environment and > rebuild the package this weekend, but a bin-NMU is also quite welcome. Release team, would you have any objection to scheduling a bin-NMU for apt-move on i386? best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423136: apt-move: built against experimental libgcc1 and libstdc++6
Package: apt-move Version: 4.2.27-1 Severity: serious Hi, apt-move is currently uninstallable in unstable (at least on i386) since it depends on libgcc1 (>= 1:4.2-20070208) and libstdc++6 (>= 4.2-20070208). Maybe it was by accident built against gcc 4.2 on the maintainer's machine? If so, a bin-NMU should suffice to fix it, assuming it's bin-NMU safe. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412006: dvidvi: Please Replace texlive-extra-utils (<< 2005.dfsg.2-12)
Package: dvidvi Version: 1.0-8etch1 Severity: important Hello, On upgrading texlive in Sid, which no longer provides a dvidvi binary and now Recommends the dvidvi package instead, I got the following: Selecting previously deselected package dvidvi. Unpacking dvidvi (from .../dvidvi_1.0-8etch1_i386.deb) ... dpkg: error processing /var/cache/apt/archives/dvidvi_1.0-8etch1_i386.deb (--unpack): trying to overwrite `/usr/bin/dvidvi', which is also in package texlive-extra-utils This happens because at the time dvidvi was unpacked, the older version of texlive-extra-utils was still installed. This is the companion bug to #411537. The issue could be worked around if dvidvi had a line like Replaces: texlive-extra-utils (<< 2005.dfsg.2-12) in its control file. If this fix could be targeted for etch-proposed-updates (e.g. version number 1.0-8etch2) and if that version of dvidvi, and version 2005.dfsg.2-12 of texlive-bin, make it into Etch, then it will be possible to upgrade texlive-extra-utils from earlier versions of Sid or Etch with no troubles. (Severity "important" rather than RC, since this issue won't affect people upgrading to Etch or Sid from Sarge where there are no texlive packages. X-Debbug-CC'ed to release and tex-maint teams.) -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-3-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages dvidvi depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries dvidvi recommends no packages. -- no debconf information best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unblock requests for young packages
Neil McGovern wrote: > On Thu, Feb 08, 2007 at 08:27:18PM +0100, Bart Martens wrote: >> Hi Debian-Release, >> >> These packages entered Debian recently. It would be nice to see them >> added to Etch, if they match your criteria. > All new packages, ie: not in etch, so unlikely. These three look like they would be unlikely to cause trouble, since they have already been in Sid for at least 32 days each, with a single wishlist bug filed between the three of them: > gmorgan 0.25-2 > http://packages.qa.debian.org/g/gmorgan.html > 41 days old (needed 10 days) > 0 bug reports > popcon 25 > Comment: For musicians. Looks nice. I'm still learning how to use it. > gamazons 0.83-2 > http://packages.qa.debian.org/g/gamazons.html > 32 days old (needed 10 days) > 1 wishlist bug report > popcon 27 > Comment: I packaged this game for the AI to be wrapped in a "gtp-engine" > for "quarry", see the open wishlist bug. > > kcheckers 0.8.1-1 > http://packages.qa.debian.org/k/kcheckers.html > 59 days old (needed 10 days) > 0 bug reports > popcon 34 > Comment: Just another board game. I packaged this game because someone > requested a package (RFP). The only Lintian/Linda complaint about the binary .debs is that none of them ship a manpage, which seems minor. But I'm not a release manager; if the RMs judge these unacceptable to go in Etch, then so be it. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please unblock geant321 1:3.21.14.dfsg-4
Dear release team, Please consider unblocking geant321 version 1:3.21.14.dfsg-4. It has fixes for two bugs (that are unreported but I would consider them priority "important") relative to the current version -1 in Etch. The other changes are trivial (minor aesthetic or build improvements). Details are in my original unblock request for version -3 at [1]. The only difference from 1:3.21.14.dfsg-3 to -4 is that I decided the fix to one of the two main bugs (the one initially fixed in -2) needed to be done in a different and more thorough way. [1] http://lists.debian.org/debian-release/2007/01/msg01178.html Thank you for your consideration! best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: Please unblock geant321 1:3.21.14.dfsg-3
My apologies, I discovered some more issues relating to the main fix that went into version -2 of geant321. Please ignore this unblock request for now. I have uploaded a new -4 version and I will make a new request once it's been available for 5 days... best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Please unblock geant321 1:3.21.14.dfsg-3
Dear release team, Please consider unblocking geant321 version 1:3.21.14.dfsg-3 so it may propagate into Etch if and when (there is an alpha build available) OR (alpha is dropped from Etch). Since the current version in Etch, 1:3.21.14.dfsg-1, the following changes have been applied. Important changes: Both of the below fix what I consider severity "important" bugs, although not reported in the BTS. * Add widget geometry constraints to the Geant++ app-defaults conffile to work around an underlying library bug that caused Geant321 client programs to have missing widgets. This is the exact same issue as the one I mentioned in the unblock request for paw. * Add a one-line patch in dpatch "001-fix-missing-fluka.dpatch" that fixes a client program abort if a user would request cross-sections for all kinds of nuclear physics processes. The abort occurred because this request would make the Geant library try to call functions from FLUKA code that has been purged for DFSG reasons. The patch causes the calls to FLUKA functions to be skipped over. Trivial changes: * Coloring of icons in the app-defaults conffile, same as with paw. * Apply a small upstream patch for gfortran support; this has no effect on the binary packages since they are still compiled with g77. * Remove an unneeded empty directory from the source package. > geant321 (1:3.21.14.dfsg-3) unstable; urgency=medium > > * Add some color to certain icons in the Geant++ browser widget, > copying from the Paw++ app-defaults. > * Add widget geometry constraints in the Geant++ browser widget > app-defaults. This fixes an (unreported) important bug that caused > some of the UI widgets in GEANT 3.21 client programs to be missing. > Hence urgency medium. > > -- Kevin B. McCarty <[EMAIL PROTECTED]> Fri, 19 Jan 2007 15:44:24 -0500 > > geant321 (1:3.21.14.dfsg-2) unstable; urgency=medium > > * Urgency medium since this fixes what I consider to be an important > (unreported) bug while having minimal impact on anything else. > * Patch 001: If the user asks for cross sections by "ALL" methods, > skip over the FLUKA methods (which otherwise cause the program to > abort when the dummy FLINIT function is reached). However, > specifically asking for a FLUKA-generated cross-section will still > cause the program to abort after directing the user to README.Debian > (which remarks on the FLUKA code having been purged). > * New patch 321: Pull in the only change that upstream made to geant321, > a small patch to an Imakefile to support gfortran, in the Cernlib 2006 > release. This patch is not in itself worth putting together a new > orig.tar.gz for geant321. > * Remove empty directory debian/patches/optional from source package. > > -- Kevin B. McCarty <[EMAIL PROTECTED]> Fri, 12 Jan 2007 17:35:24 -0500 Thanks for your consideration! -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Please unblock paw 1:2.14.04-7
Dear release team, Please consider unblocking paw version 1:2.14.04-7 so it may propagate into Etch if and when (there is an alpha build available) OR (alpha is dropped from Etch). The only changes in this release are what I consider very low-risk edits to the conffile "/etc/X11/app-defaults/Paw++". One set of changes is to add colors to icons, improving the aesthetic appearance of the paw++ program. The other set of changes fixes missing widgets in the program's GUI by including geometric specifications for them in the app-defaults file. Putting these geometric specifications into the app-defaults works around an underlying bug in one of the libraries used by paw++, that caused it not to use reasonable fallbacks when an app-defaults file exists. Fixing that library bug might be more potentially intrusive so I will wait to do so until post-Etch. > paw (1:2.14.04-7) unstable; urgency=medium > > * debian/add-ons/app-defaults/Paw++: Two categories of fixes to the > app-defaults shipped in /etc/X11/app-defaults/Paw++. > - Add some colors to improve the appearance of icons in the browser. > - Add geometry constraints on certain widgets, fixing an important GUI > bug (not filed in the BTS) that was causing parts of the Paw++ UI not > to be displayed. Hence urgency set to medium. > > -- Kevin B. McCarty <[EMAIL PROTECTED]> Fri, 19 Jan 2007 15:13:37 -0500 Thanks for your consideration! -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: #379288 release-critical?
Jérôme Warnier wrote [on debian-release [0]]: [0] http://lists.debian.org/debian-release/2007/01/msg00759.html > I'm wondering if bug #379288 (lapack3 still depends on libg2c0 while > gfortran is now the default fortran compiler) shouldn't be tagged as > release-critical? As Matthias said [1], gfortran is not yet (to the best of my knowledge) an acceptable Fortran77 compiler, although GNU is working in that direction. [1] http://lists.debian.org/debian-release/2007/01/msg00760.html Please additionally see previous emails I've written about g77 vs. gfortran, e.g.: http://lists.debian.org/debian-science/2005/09/msg00071.html To summarize, because g77 and gfortran produce different ABIs by default, there will need to be a coordinated library transition to switch completely from g77 to gfortran, similar to the various g++ transitions, if we are not to have complete chaos among Fortran libraries and apps that use them. This isn't going to be possible for the Etch timeframe. Post-Etch, I am going to see whether I have time to work on this. My preliminary efforts indicate it's going to be rather complicated. > It is indirectly needed by OOo Calc, and is the only reason left on my > Desktop PCs for keeping gcc-3.x packages. Really? Aren't there a number of GNOME packages that use FFTW? best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sarge -> Etch upgrade: no way to prevent removal of running kernel
Hi release team and initrd-tools maintainer, One issue that seems problematic for people currently upgrading from Sarge to Etch is that there is currently no initrd-tools package in Etch. (I guess it's been removed because of #395181 and/or #393092. Why can't #395181 just be fixed already?) The problem is that on a dist-upgrade, the new libc6 in Etch Conflicts against initrd-tools (<< 0.1.84.1). (This conflict was added in libc6 2.3.6-8.) Since there is no new initrd-tools in Etch to which we can upgrade, apt/aptitude is forced to decide to remove initrd-tools 0.1.81.1 to perform the upgrade. But all the 2.4 and 2.6 kernels in Sarge (at least on i386) Depend upon initrd-tools. So in order to dist-upgrade, one would be forced first to install a new kernel from Etch, in order not to have the package containing the running kernel removed out from under the system. However, if we look at the dependencies of the 2.6.18 kernel images in Etch, we see that they Depend: initramfs-tools | yaird | linux-initramfs-tool. The first of these Depends on udev (>= 0.086-1) which in turn Depends on the libc6 in Etch. The second directly Depends on the Etch libc6. The last is a virtual package that (at least in Etch/i386) is provided only by the first two. Hence there is currently *no way* to upgrade Sarge -> Etch without the package manager insisting to remove the running kernel package! Possible fixes: 1) Fix #395181 so initrd-tools can get back into Etch 2) Make available 2.4.27/2.6.8 kernel images for a new Sarge point release that don't depend on initrd-tools 3) Make available udev and/or yaird packages built against the Sarge libc6 4) Remove the initrd-tools conflict from libc6 in Etch (might not work due to #364338) 5) Others? regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: Packages rename and conffiles
Steve Langasek wrote: > On Sun, Nov 26, 2006 at 09:03:06PM +0100, Bill Allombert wrote: >> A fair number of conffiles have changed of packages. > > [...] > >> Unfortunately, I know how to avoid spurious dpkg conffiles handling >> with either of them separately, but not with both of them at once. > >> So we have to take a position on this issue. I can provide the list >> of affected packages. There is at least openssh, vim and openoffice. > > What position do you think we should take on this issue? If there's no > known solution that avoids conffile prompts with both the old and new > versions, and given that there's no good systematic way to arrange for one > version of dpkg or the other to be installed at the time of upgrade, > perhaps it's best to favor the new dpkg? Is it possible simply to tell people "upgrade dpkg first" along with aptitude in the Sarge->Etch upgrade release notes? That would at least take care of everyone who bothers to read the instructions :-) best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please hint lilypond 2.8.7 into testing
Thomas Bushnell BSG wrote: > I would like to officially ask for an exception to the usual testing > rules for lilypond, to allow 2.8.7 into testing, on those architectures > where guile-1.8 works. The architectures currently losing for guile-1.8 > are alpha, amd64, and ia64. > > I believe that alpha and ia64 are release candidates, as well, which > means that the relevant guile-1.8 bugs *are* release critical, though > they were marked "important". This is an inconsistency. > > If no exceptions are made for guile-1.8 and lilypond, then we will be > stuck with lilypond 2.6 in etch and no guile-1.8 at all. Hi Thomas, I'm not a release manager and I don't know anything about Lilypond, so maybe this is a naive question, but ... could you build it against guile-1.6 instead of guile-1.8? Guile-1.6 is apparently available on all arches in both testing and unstable. It looks like the last Lilypond built against guile-1.6 (version 2.6.5-3) compiled OK on the three problematic arches. Hope this helped, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396331: upgrade-reports: sarge to etch removes kernels
Steve Langasek wrote: > On Tue, Oct 31, 2006 at 03:04:49PM -0800, Kevin B. McCarty wrote: >> Sorry, maybe I didn't make myself understood well, or else I didn't >> understand the bug report. If I read correctly, the submitter is >> complaining that his dist-upgrade wanted to remove the package >> containing the **currently running** kernel. > > That's correct. > >> Wouldn't that be a problem?? > > Yes, but how do you think the new aptitude is going to fix it? By always considering linux-image-* to be manually installed, apparently: aptitude (0.4.4-1) unstable; urgency=low [snip] - Change the default settings to leave unused Linux kernel images on the system. (Closes: #386307) (Sorry, it wasn't clear to me whether that was a rhetorical question or not.) Hmm, I looked at #386307 and apparently the kernel-image-* packages themselves have a method to prevent removal of a running kernel. It's not nearly as nice as a fix in aptitude would be, though; it just amounts to a scary question in the kernel prerm script, "Remove the running kernel image?". (This question is not even debconf'ized in the Sarge kernels.) If one answers no (the default), the removal fails. (For further confusion later, in the Etch kernel packages, the corresponding Debconf question has the sense of the yes/no answer reversed ...) If aptitude is trying to do a lot of other things in the same run, as is typical in a dist-upgrade, the kernel package prerm failure may leave many other packages temporarily unconfigured, and the user will probably have to re-run the operation after marking the old kernel-image package as not to be removed. > Why *should* aptitude try to fix it? IMO, the benefits of users not having to see the scary kernel removal message, answer the right thing to it, and then have to re-run aptitude after explicitly marking the old kernel package to remain installed, outweigh the annoyance of having old kernel packages remain installed on their systems. If you disagree, though, I doubt I can say anything to change your mind. Then I guess the release notes should be adjusted to suggest the best order of operations. However the release note change suggested by the original submitter of this bug doesn't seem to help the situation any. Tested on my sarge system: > benjo[1]:/home/kmccarty# vim /etc/apt/sources.list [add line for etch] > benjo[2]:/home/kmccarty# apt-get update [...] > benjo[3]:/home/kmccarty# aptitude -f install linux-image-2.6-k7 [...] > The following packages will be REMOVED: [...] > initrd-tools kernel-image-2.6.8-3-k7 lapack-dev lesstif2-dev ^^^ [...] > Do you want to continue? [Y/n/?] n > Abort. > benjo[4]:/home/kmccarty# uname -a > Linux benjo 2.6.8-3-k7 #1 Thu Sep 7 05:09:40 UTC 2006 i686 GNU/Linux ^^ So that's not going to work so well. (There's also an issue with libfam0/libfam0c102 that I'll report as a separate bug to upgrade-reports.) best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396331: upgrade-reports: sarge to etch removes kernels
Steve Langasek wrote: > On Tue, Oct 31, 2006 at 08:57:25AM -0800, Kevin B. McCarty wrote: >> This problem (automatic removal of old kernel packages) is apparently >> fixed in the version of aptitude in Sid, 0.4.4-1. If this version was >> allowed to pass into Etch (currently aptitude in Etch is only one >> version behind Sid, at 0.4.3-1), then the release notes would only have >> to say something to the effect of "Install the aptitude from Etch >> *before* dist-upgrading." (The Sarge release notes contained a similar >> instruction, BTW.) > > Wow, what? First of all, how is there anything buggy in the current > aptitude removal to justify "fixing"? If the old kernel-image package is > marked in aptitude as auto-installed, aptitude is *supposed* to remove it, > this is a feature not a bug! (It's a feature which has non-obvious > consequences to many users, but I don't believe there's any sane way to > "fix" it.) Sorry, maybe I didn't make myself understood well, or else I didn't understand the bug report. If I read correctly, the submitter is complaining that his dist-upgrade wanted to remove the package containing the **currently running** kernel. Wouldn't that be a problem?? -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396331: upgrade-reports: sarge to etch removes kernels
Argh. Sorry, this was of course supposed to go to debian-release@LISTS.debian.org ... Original Message Subject: Re: Bug#396331: upgrade-reports: sarge to etch removes kernels Date: Tue, 31 Oct 2006 08:57:25 -0800 From: Kevin B. McCarty <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> Ryan Finnie wrote: > Package: upgrade-reports > Severity: important > > Upgrade went well, except for one rather big problem. If I do a > straight "aptitude -f dist-upgrade", it removes kernel-image-* (IE, > kernel-image-2.6.8-3-686; I didn't try a 2.4 installation->upgrade). > Now, I understand why older kernels must be removed for etch (udev, > etc), but this is probably a problem for the average user. For the > release notes, I would recommend the following procedure: > > 1. Edit sources.list > 2. apt-get update > 3. aptitude -f install linux-image-2.6-[arch] > 4. dpkg --purge hotplug > 5. reboot > 6. aptitude -f dist-upgrade > > Installing the new kernel first means the old kernels will be removed, > udev will be installed, only a few necessary packages are upgraded > (libc6, etc), and a new, hopefully working kernel is installed in its > place. The user can then reboot and verify the new kernel works before > completely upgrading to etch. Of course, if the new kernel DOESN'T > work, the user doesn't have anything to fall back on, but at least he > knows early on. This problem (automatic removal of old kernel packages) is apparently fixed in the version of aptitude in Sid, 0.4.4-1. If this version was allowed to pass into Etch (currently aptitude in Etch is only one version behind Sid, at 0.4.3-1), then the release notes would only have to say something to the effect of "Install the aptitude from Etch *before* dist-upgrading." (The Sarge release notes contained a similar instruction, BTW.) CC'ed to debian-release and aptitude maintainer for their consideration. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#394332: sysvinit: Please remove NEWS.Debian entries for 2.86.ds1-18 and -19
LENHOF Jean-Yves wrote: > >> Incidentally, it would be nice to have some sort of tool that could be >> used to track the versions of a package that had appeared in the current >> "testing" release, although obviously that's beyond the scope of this >> bug report. Currently one has to browse for the package of interest in >> http://snapshot.debian.net/archive//MM/DD/debian/dists/testing/SECTION/binary-ARCH/Packages.gz >> for the desired SECTION and ARCH through possibly relevant dates >> /MM/DD. >> > > On packages site you see this type of information (on the right) > > http://packages.qa.debian.org/s/sysvinit.html Thanks! Don't I feel dumb now. (CC'ed to debian-release for the benefit of anyone reading the archives later.) regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394332: sysvinit: Please remove NEWS.Debian entries for 2.86.ds1-18 and -19
Package: sysvinit Version: 2.86.ds1-20 Severity: wishlist Hello, I think it might be a good idea to remove the NEWS.Debian entries for sysvinit for versions 2.86.ds1-18 and 2.86.ds1-19, and try to get this changed package into etch (maybe via etch-proposed-updates). The versions of sysvinit having bug #386500 (and friends), specifically 2.86.ds1-16 and 2.86.ds1-17, were never part of Etch, as I determined by checking snapshot.debian.net. (Etch jumped from -15 to -20 on about September 22, and that is still the sysvinit version in Etch as of October 20.) Therefore these NEWS.Debian entries that explain how to deal with repercussions from that bug are unnecessary, and their appearance will be confusing to anyone tracking Etch or upgrading from Sarge to Etch. Further, anyone tracking Sid should have seen them by now since sysvinit 2.86.ds1-19 was available in unstable on Sept. 13 (again, according to snapshot.debian.net), more than a month ago. CC'ing to debian-release in case the Release Managers wish to comment. Incidentally, it would be nice to have some sort of tool that could be used to track the versions of a package that had appeared in the current "testing" release, although obviously that's beyond the scope of this bug report. Currently one has to browse for the package of interest in http://snapshot.debian.net/archive//MM/DD/debian/dists/testing/SECTION/binary-ARCH/Packages.gz for the desired SECTION and ARCH through possibly relevant dates /MM/DD. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please bin-NMU mn-fit on alpha, amd64, ia64
Wondering if this message was just overlooked, or if the release team has a reason to ignore it? Thanks, and sorry for the bother. best regards, Original Message Subject: Please bin-NMU mn-fit on alpha, amd64, ia64 Date: Mon, 02 Oct 2006 10:52:32 -0700 From: Kevin B. McCarty <[EMAIL PROTECTED]> To: debian-release@lists.debian.org Hi release team, Could you please bin-NMU mn-fit on the three 64-bit architectures? Unfortunately, code of its build-dependencies in the cernlib and paw source packages is very old and not 64-bit clean; mn-fit must be linked against them statically on 64-bit arches in order to work. (The static linking is taken care of automatically by debian/rules and is already known to work.) I recently uploaded a new version of cernlib (2005.dfsg-5) with some minor 64-bit-related fixes. It would be nice to get mn-fit 5.13-4 rebuilt against that version on 64-bit arches, ASAP, so the bin-NMU'ed version can incorporate those fixes and go into etch. mn-fit is bin-NMU safe, to the best of my knowledge, so this should not cause any problems. Thanks in advance! best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Bug#392818: ext3 corruption issue in 2.6.18 found by RedHat
Package: linux-2.6 Version: 2.6.18-1 Severity: critical Justification: possible filesystem corruption Hi release and kernel teams, Following up to http://lists.debian.org/debian-release/2006/10/msg00183.html : Steve Langasek wrote: > On Thu, Oct 12, 2006 at 10:11:06AM -0700, Kevin B. McCarty wrote: >> Is this ext3 corruption issue also on the kernel team's radar? > >> http://lwn.net/Articles/203536/ >> http://kernelslacker.livejournal.com/55309.html > >> Apologies if it's a known and/or fixed issue. >> best regards, > > That would seem to warrant an RC bug? > > Please, if you know of such issues that should prevent pushing the current > 2.6.18 packages into testing, file them as bugs of the appropriate severity. Unfortunately I know nothing about this issue beyond what's written in the above URLs -- I don't even have any machines running on a 2.6.18 kernel. This probably makes me not the best person to file a bug. But here goes anyway... The last URL above includes a link to the issue in RedHat's bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209005 Apparently they are still trying to create a good test case for it. Note that Fedora felt strongly enough about the problem that they are delaying the release of FC6 in order to fix it: http://fedoranews.org/cms/node/1668 -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: Serious issues with linux-2.6 (was: Re: Scheduling linux-2.6 2.6.18-3)
Bastian Blank wrote: > On Tue, Oct 10, 2006 at 01:53:58PM +0200, Frederik Schueler wrote: >> I would like to schedule the upload of linux-2.6 2.6.18-3 for next >> Thursday, 12th October. > > Now we have the desired date, nothing happened to the following issues. > >> Two big issues are still open: >> - hppa FTBFS >> - alpha gcc-4.0 build dependency > > What should we do with them? Finally disable alpha and hppa(64)? Is this ext3 corruption issue also on the kernel team's radar? http://lwn.net/Articles/203536/ http://kernelslacker.livejournal.com/55309.html Apologies if it's a known and/or fixed issue. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
apt-listbugs unusable in Sarge
Hi Junichi, you wrote (in #389903): >> > Unfortunately apt-listbugs was neglected for such a long time that >> > apt-listbugs in stable is broken without hope of repair. >> > >> > Please remove apt-listbugs package and then install after upgrade to >> > sid is finished. 389903 submitter: >> There is also the issue where the package for apt-listbugs does not >> appear to be any different in Testing, as in Sarge. (running `aptitude >> -t testing install apt-listbugs` made absolutely no difference). Maybe >> I should make this an RC bug? A testing package which is broken? N.B. this is because the apt-listbugs package does not exist in testing (it was previously removed from testing due to RC bugs). Junichi Uekawa: > There is no point in making this bug report a RC bug. > > Backporting apt-listbugs to sarge may help. > > It was neglected for the past two years or so, and I've just been > wading through the list of bugs for the past two weeks to get things > remotely working. > > If you think apt-listbugs was working a few weeks ago, you were > dreaming; what it showed you is a snapshot of bug reports back in May > 2005 or something; since the job to update the indices was broken and > nobody fixed it. Should the apt-listbugs package be removed from stable since it's no longer at all usable there? (possibly with an announcement to [EMAIL PROTECTED] or something like that?) CC'ing to debian-release to see what the SRMs think. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hypothetical bin-NMU versioning question
Andreas Metzler wrote: > On 2006-10-02 "Kevin B. McCarty" <[EMAIL PROTECTED]> wrote: >> I have a hypothetical bin-NMU versioning question (this is asked only >> for my curiosity, so don't give it a high priority). Suppose that >> package X (version 1.0-1) is bin-NMU'ed on architectures A and B. At a >> later time it needs to be bin-NMU'ed on architectures B and C. [snip] > It was at > 0.2.12-1+b1: amd64 s390 > 0.2.12-1: alpha arm hppa i386 ia64 kfreebsd-i386 m68k mips mipsel > powerpc sparc > previously and is now > 0.2.12-1+b2: amd64 > 0.2.12-1+b1: alpha arm hppa i386 ia64 kfreebsd-i386 m68k mips mipsel > powerpc s390 sparc > Afaict the numbering is simply increased for each upload. Thanks for the clear and decisive answer! best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
hypothetical bin-NMU versioning question
I have a hypothetical bin-NMU versioning question (this is asked only for my curiosity, so don't give it a high priority). Suppose that package X (version 1.0-1) is bin-NMU'ed on architectures A and B. At a later time it needs to be bin-NMU'ed on architectures B and C. Will the bin-NMUs be numbered incrementally independently on each arch, or grouped by round? That is, will the arch:any binary packages of X on arch C get version 1.0-1+b1 or 1.0-1+b2? (I'm pretty sure that arch A will end up with 1.0-1+b1 and arch B with 1.0-1+b2, but correct me if that's wrong.) And does this numbering depend upon whether the reasons for the first and second rounds of bin-NMUs are the same or different? Thanks and best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please bin-NMU mn-fit on alpha, amd64, ia64
Hi release team, Could you please bin-NMU mn-fit on the three 64-bit architectures? Unfortunately, code of its build-dependencies in the cernlib and paw source packages is very old and not 64-bit clean; mn-fit must be linked against them statically on 64-bit arches in order to work. (The static linking is taken care of automatically by debian/rules and is already known to work.) I recently uploaded a new version of cernlib (2005.dfsg-5) with some minor 64-bit-related fixes. It would be nice to get mn-fit 5.13-4 rebuilt against that version on 64-bit arches, ASAP, so the bin-NMU'ed version can incorporate those fixes and go into etch. mn-fit is bin-NMU safe, to the best of my knowledge, so this should not cause any problems. Thanks in advance! best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: Preparation of the next stable Debian GNU/Linux update (I)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Zobel-Helas wrote: > Hi Kevin, > > On Fri, Aug 25, 2006 at 09:59:53AM -0700, Kevin B. McCarty <[EMAIL > PROTECTED]> wrote: >>Second, is it planned to include the next round of security updates to >>the Mozilla family by Alexander Sack? (cf. [0] [1]) For some reason >>these don't seem to have gone into security.d.o yet and it would be very >>nice to ship mozilla* packages that are up-to-date with security fixes. > > Not for r3 anymore. I know that these packages are in preparation, but i > would like to publish r3 rather soon, and we usually let DSA packages wait > about one week in p-u-new before adding them to proposed-updates. This > way, we can catch up with debian-security or the BTS if a DSA is > seriously broken (like mozilla-thunderbird on i386 or libfreetype6). OK. >>Third, please note that even if those updates don't get into Sarge r3, >>the existing mozilla-thunderbird security update needs a bin-NMU on i386 >>[2]. > > I have prepared a binNMU on i386 for mozilla-thunderbird, availible on > http://people.debian.org/~zobel/packages/3.1r3/ > > Could you please check, if these packages work for you? Yes, I'm writing this email with the updated bin-NMU package you provided. I've used it to read ~100 emails now, together with the Enigmail extension, and found no problems. best regards, - -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE8cdcfYxAIk+Dx1ERAlF3AJ9O+DbsEy1JS3LDbkU6Gr+h++oFSQCffHiy vudHnEdu7zvSjs7GW53P0yw= =tvst -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Preparation of the next stable Debian GNU/Linux update (I)
stable1.0.2-2.sarge1.0.7 alpha arm > hppa i386 ia64 m68k mips mipsel powerpc s390 sparc > mozilla-thunderbird-offlineupdates 1.0.2-2.sarge1.0.8a alpha arm > hppa i386 ia64 m68k mips mipsel powerpc s390 sparc > mozilla-thunderbird-typeaheadfind stable1.0.2-2.sarge1.0.7 alpha arm > hppa i386 ia64 m68k mips mipsel powerpc s390 sparc > mozilla-thunderbird-typeaheadfind updates 1.0.2-2.sarge1.0.8a alpha arm > hppa i386 ia64 m68k mips mipsel powerpc s390 sparc > mozilla-thunderbirdstable1.0.2-2.sarge1.0.7 alpha arm > hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source > mozilla-thunderbirdupdates 1.0.2-2.sarge1.0.8a alpha arm > hppa i386 ia64 m68k mips mipsel powerpc s390 sparc source > > DSA 1051 mozilla-thunderbird - several vulnerabilities First of all, the above should also mention DSA 1134. Second, is it planned to include the next round of security updates to the Mozilla family by Alexander Sack? (cf. [0] [1]) For some reason these don't seem to have gone into security.d.o yet and it would be very nice to ship mozilla* packages that are up-to-date with security fixes. Third, please note that even if those updates don't get into Sarge r3, the existing mozilla-thunderbird security update needs a bin-NMU on i386 [2]. CC'ed to Alexander. [0] http://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/2006-August/000399.html [1] http://www.asoftsite.org/s9y/archives/113-Please-test-firefoxthunderbirdmozilla-security-packages.html [2] http://lists.debian.org/debian-security/2006/08/msg00023.html regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packages that ought to be kicked out of testing
This is a follow-up to my email to debian-qa about packages that it would be nice to remove from unstable, http://lists.debian.org/debian-qa/2006/05/msg00026.html Two related packages and one of those on the list are also in testing: # No point in having interchange-doc without interchange # (not currently in testing). remove interchange-doc/5.2.0-1 # The most commonly installed binary package from gforge, gforge-common, # has only 12 installations in popcon. One of its packages has been # uninstallable for 64 days. There is also a possible security-related # bug, #328224 (it is not RC only because no one has yet # checked if it applies to the version in Debian, even though the bug # was submitted 253 days ago). The versions in stable/testing/unstable # are identical. remove gforge/3.1-31 # gforge has one reverse depends, gforge-theme-starterpack. remove gforge-theme-starterpack/3.1-1 -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages that ought to be kicked out of testing
Steve Langasek wrote: > On Thu, May 25, 2006 at 03:04:25PM -0400, Kevin B. McCarty wrote: >># No point in having interchange-doc without interchange >># (not currently in testing). >>remove interchange-doc/5.2.0-1 > > Then the correct procedure is to first file a serious bug against > interchange-doc so that it doesn't wander back in on its own after the hint > is removed. Done, #368905. >># gforge has one reverse depends, gforge-theme-starterpack. >>remove gforge-theme-starterpack/3.1-1 > > Removing these has been previously suggested on the list, so this is > somewhere on the TODO stack already. Oops, I forgot Nathanael Nerode covered this. Sorry for the redundancy. best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Easy removals B-G reminder
Here's some possibly useful information about some of these bugs: Nathanael Nerode wrote: > # 365680, security > remove cgiirc/0.5.4-6 This bug is fixed by 0.5.4-6sarge1 which was uploaded to stable-security, and (according to Joey in that bug log) will propagate to testing and unstable automatically since the versions in Sarge/Etch/Sid were all initially 0.5.4-6. > # 365181 > remove s-http-server/20051218-1 Fixed in a new version uploaded to unstable, 20060516-1. > # 366128 > remove ding/1.4-3 This has been tagged "unreproducible" by the maintainer. > # 364264 > remove directvnc/0.7.5-7.1 Fixed in a new version uploaded to unstable, 0.7.5-8. > # 365186 > remove fml/4.0.3-2 Fixed in a new version uploaded to unstable, 4.0.3.dfsg-1. > remove gparted/0.0.9-1 > # 362533 This bug may be a fluke - see Bill Allombert's email at the end of the log. > # 362533 > remove gr-usrp/0.6-1 Fixed in a new version uploaded to unstable, 0.8-1. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: draft of announcement for sarge r2
Andreas Barth wrote: > as we're now directly moving towards sarge r2, we drafted an > announcement. Please see the attachement for more details. We will > notify you as soon as the mail can be sent out. I see that something about the kernel updates is written on the release preparation page http://release.debian.org/stable/3.1/3.1r2/ as "About Kernel Updates", but IMO it should also be mentioned in the actual announcement. Maybe include a note like the following? "Due to some technical difficulties with Debian installation methods, the most recent security updates to the Linux kernel packages, DSA 1017 and 1018, are not included with this revision. They may be installed afterward instead by ensuring that the usual security entries are present in APT's /etc/apt/sources.list file, deb http://security.debian.org/ sarge/updates main contrib non-free deb-src http://security.debian.org/ sarge/updates main contrib non-free running apt-get update, and following the steps described in the security advisories." On another topic, why isn't wzdftpd (DSA 1006) included in the release announcement? It is listed as OK on the wiki page http://wiki.debian.org/DebianReleases/PointReleases but not listed at all on the release preparation page http://release.debian.org/stable/3.1/3.1r2/ For some reason it has also gone missing from the security front page http://www.debian.org/security/ even though it can be found at the direct URL http://www.debian.org/security/2006/dsa-1006 regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 signature.asc Description: OpenPGP digital signature
Re: xlibs-dev removal and RC bug fun
David Martínez Moreno wrote: > El sábado, 7 de enero de 2006 23:53, Kevin B. McCarty escribió: > >>Looks like xlibs-dev is now officially gone, which instantly creates a >>hell of a lot of RC (FTBFS) bugs that will manifest the next time >>rebuilds are attempted of xlibs-dev Build-Depending packages. (Maybe >>someone on the X team should mention this on debian-devel-announce?) >> >>I've been trying to keep on top of them at the wiki page: >>http://wiki.debian.org/DependsXlibsDev > All right, Kevin, but Adeodato Simó has just filed about 360 bugs > because of > this issue, so it will be much easier to track. :-) Oh, that does make it a lot easier than getting everyone to remember to edit the wiki page :-) regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
xlibs-dev removal and RC bug fun
Looks like xlibs-dev is now officially gone, which instantly creates a hell of a lot of RC (FTBFS) bugs that will manifest the next time rebuilds are attempted of xlibs-dev Build-Depending packages. (Maybe someone on the X team should mention this on debian-devel-announce?) I've been trying to keep on top of them at the wiki page: http://wiki.debian.org/DependsXlibsDev I reviewed the list there that was created last month, down through packages starting with "R", upgrading existing bugs to "serious" as I went, but I've ran out of stamina. If you are NMUing, mass-bug-filing, or doing other things related to dealing with this issue, could you please try to keep the wiki page up-to-date? Thanks! -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xorg 6.9
On the same note, here is a list of source packages containing one or more binary packages that Depend: xlibs-dev. I've already removed packages from the list that give it as an alternative (e.g. Depends: libx11-dev | xlibs-dev). I'll add this list to http://wiki.debian.org/DependsXlibsDev shortly. Ryuichi Arafune <[EMAIL PROTECTED]> imagemagick Thomas Bushnell, BSG <[EMAIL PROTECTED]> gnome-libs imlib A. Maitland Bottoms <[EMAIL PROTECTED]> vtk Martin Buck <[EMAIL PROTECTED]> xview Guenter Geiger <[EMAIL PROTECTED]> ivtools Debian QA Group <[EMAIL PROTECTED]> ubit Christian Hudon <[EMAIL PROTECTED]> icon Aurelien Jarno <[EMAIL PROTECTED]> lineakd Gerd Knorr <[EMAIL PROTECTED]> openmotif Siggi Langauf <[EMAIL PROTECTED]> xine-lib Steve M. Robbins <[EMAIL PROTECTED]> soqt Jeff Teunissen <[EMAIL PROTECTED]> libdockapp Chris Waters <[EMAIL PROTECTED]> itcl3.0 itcl3.1 tk8.0 tk8.3 Florian M. Weps <[EMAIL PROTECTED]> libooc-x11 Mathias Weyland <[EMAIL PROTECTED]> beep-media-player regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please consider wmakerconf 2.11-2 for Sarge
Dear RMs, Would it be possible to allow wmakerconf 2.11-2 into Sarge? This is a very minor change from 2.11-1 (currently in Sarge) fixing bug #307850. That bug is an upgrade issue that causes apt-get to remove wmakerconf, wmaker and wmakerconf-data in an upgrade from Woody to Sarge. (Aptitude in Sarge currently does the right thing, but lots of people are going to try "apt-get dist-upgrade" even though the release notes say to use aptitude.) The changelog is as follows: > wmakerconf (2.11-2) unstable; urgency=high > > * debian/control: Depend upon wmaker (>= 0.90.0) instead of Conflicting > against wmaker (<< 0.90.0); this prevents woody->sarge upgrade problems. > (closes: #307850) > * debian/control: Change maintainer address. > > -- Kevin B. McCarty <[EMAIL PROTECTED]> Sat, 7 May 2005 19:04:07 -0400 wmakerconf 2.11-2 has been built on all arches and has waited the requisite 2 days for an "urgency=high" upload, so the only thing it needs is your approval. Thank you for your consideration, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please push cernlib 2004.11.04-3 into testing despite missing arm build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear release managers, Could you please push the latest version of cernlib into testing without waiting for the missing arm build? All other arches have it up-to-date (the most recent, sparc, uploaded it this morning: http://buildd.debian.org/stats/sparc-all.txt , so it should be in the archive this afternoon). As I mentioned in private email to one of you (SL) already, this release fixes a number of tempfile-related local vulnerabilities. Thanks, - -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCW7B3fYxAIk+Dx1ERAiUYAJ9A8UEt9ukmCChkgz+eJ1zLvIBx4ACglRrZ Re9laZrcgCIwJ8jhqKTgC0s= =JQdT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wmaker, wsound* and libdockapp.
Romain Francoise wrote: > Do we really want the new wmaker in sarge? It's the result of several > months of upstream development and it's apparently a bit rough around > the edges, and it's even unusable for me because of bug #283240. This > is by no means a critical bug by Debian standards but as a mere user I > would prefer sarge to ship with version 0.80. As maintainer (currently also upstream) of wmakerconf, I second this opinion. It looks like wmaker 0.90 has switched to UTF-8, but wmakerconf (being based on GTK+ 1.2) has not yet, leading to bugs like #282807. I'm trying to port wmakerconf to GTK+ 2.x but there are some weird problems that will take a little while to solve, and I won't have much free programming time before Christmas. -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544
Re: Upload of GNOME 2.8 to unstable
Wouter Verhelst wrote: >> magicdev | g-v-m [!powerpc], g-v-m | magicdev [powerpc] allowed ? > > It is for build-depends, but not for plain depends. If you need that, > you need to generate your depends header at build time, and need > arch:any packages instead of arch:all ones (which isn't impossible, > although quite ugly). It seems to me that you might be able to use type-handling in this situation. Having in the Depends the following, in order: type-handling magicdev | g-v-m | powerpc-linux-gnu g-v-m | magicdev | not+powerpc should (not tested!) do what you want and allow you to keep the metapackages Arch: all. Once type-handling is installed, on powerpc the second dependency is satisfied (type-handling Provides powerpc-linux-gnu), so apt should look at only the third dependency; on non-powerpc, the third dependency is satisfied (type-handling provides not+powerpc), so apt should look at only the second dependency. Whether this works in practice, I don't know, because it requires that apt is smart enough to know what type-handling Provides before looking at the second and third dependencies. Might be worth trying, though. The other downside is of course that type-handling depends on dpkg-dev, which recommends c-compiler, so many apt front ends will cause gcc to be installed. IMO this is really a flaw in the type-handling package, and a dummy package that Provides appropriate per-arch virtual packages should be split off from it. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544
Packages not entering testing due to version inconsistencies between arches
Dear all, There are a number of source packages whose current versions cannot propagate into testing because they have previously been compiled on arches that the maintainer cannot or does not want to support, and has asked via the BTS to have removed. Some of these bugs have been around for months. Some of the packages, if they could enter testing, would fix RC bugs in sarge. Is there anything we (i.e. anyone not an FTP master) can do to help, other than point out the specific packages affected? Thanks should go to Jeroen van Wolffelaar for already retitling and tagging most of the bugs against ftp.debian.org. Below is a list by maintainer of affected source packages. This list may be a few days out-of-date. Full disclosure: I maintain cernlib, one of the source packages held up by this problem, and feel it's important that the current version propagate into sarge. Does anyone else think it would be reasonable for some script to run over the archive and remove binary packages from unstable that are (a) out-of-date, and (b) no longer intended to be built for that arch by the maintainer (determined via the arch list in debian/control)? This would reduce workload on the FTP masters and prevent inconsistent versioning in sid due to packages built for unwanted arches. Format of this list: - First field is source package name; - Second field is the bug number(s) against ftp.d.o; - Third and fourth fields are the version in testing, and the most recent version in unstable. If the package is not in testing, then the third field is the earliest version present in unstable if there are out-of-sync arches; - Remaining fields are any RC bugs closed between the two version numbers listed, plus those that would be "fixed" by removal of the unwanted arches. Alberto Gonzalez Iniesta <[EMAIL PROTECTED]> xmbmon 256796 2.04-3 2.05-1 252282 Amaya Rodrigo Sastre <[EMAIL PROTECTED]> lirc 260565,267323 0.6.6-7 0.6.6-12 243195 259978 Aurelian Jarno <[EMAIL PROTECTED]> i2c-old 270481 1:2.7.0-10 1:2.7.0-15 274618 lm-sensors-old 270482 1:2.7.0-11 1:2.7.0-13 274620 Colin Watson <[EMAIL PROTECTED]> trn4 276956 4.0-test76-8 4.0-test76-9 none Debian Mono Group <[EMAIL PROTECTED]> mcs 268061 0.30.2-1 1.0.2-1 none mono 269523 1.0-3 1.0.2-1 256755 257412 262023 272846 259680 # this has other problems; see the email I sent to bug #269523. Debian QA Group <[EMAIL PROTECTED]> lush 267494 1.0+cvs.2004.02.02 1.0+cvs.2004.05.16 243501 Dirk Eddelbuettel <[EMAIL PROTECTED]> octave2.0 271648 2.0.17-7 2.0.17-9 none Ian Lynagh (wibble) <[EMAIL PROTECTED]> ghc6 276608 6.2.1-4 6.2.2-2 277585 Kevin B. McCarty <[EMAIL PROTECTED]> cernlib 255970 2004.01.20-1 2004.01.20-8 none Mark Purcell <[EMAIL PROTECTED]> linuxvideostudio 241019 0.1.4-3 0.1.7-1 none Martin Buck <[EMAIL PROTECTED]> xview 271313 4.4.3.2p1.4-16 4.4.3.2p1.4-18 167054 Mike Furr <[EMAIL PROTECTED]> vegastrike 233942 0.3.1-5 0.4.1-12 246299 Peter Eisentraut <[EMAIL PROTECTED]> postgresql-plruby 271019 0.4.2-1 0.4.2-2 none Sergio Rua <[EMAIL PROTECTED]> partimage 276329 0.6.4-7 0.6.4-10 268248 259523 Stephen Stafford <[EMAIL PROTECTED]> distributed-net 177134,258401 2.8015.46-10 2.9008.490-2 162891 251760 Sven Luther <[EMAIL PROTECTED]> unicorn 267730,270530 0.8.7-1 0.8.7-1.1 none Volker Ossenkopf <[EMAIL PROTECTED]> workman 271313 1.3.4-16 1.3.4-17 none regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544
Re: Bug#273734: education-common: con't fulfill the Recommends on !i386
Steve Langasek wrote: > Do the library packages not have dependencies on the data packages? In > general, it doesn't seem like people are going to select data packages > for installation by themselves anyway; which of course also means that > the impact of an incorrect relationship is also reduced. The lib packages do depend on the -data packages, and suggest -doc packages. I'm therefore going to follow your suggestion and remove the Recommends statements from the -data and -doc packages. There is also a "paw-demos" package containing example files to be used with PAW, so I changed it from Recommending paw to Depending upon it (on the assumption that no one would be playing with the example PAW scripts without having PAW installed anyway). That takes care of the Recommends. A lot of the Depends in cernlib are from Arch: all scripts and metapackages that can't be satisfied on 64-bit arches, but I guess this is OK. Thank you for the advice, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544
Re: Bug#273734: education-common: con't fulfill the Recommends on !i386
Martin Michlmayr wrote:
> FWIW, I agree with Adrian's interpretation [*]. "the packages in
> main" "must not require a package outside of main" for "execution"
> (... "Recommends"). While this sentence is fulfilled on i386, it is
> violated on !i386 which imho is a Policy violation.
What would you say about the case of a source package that produces some
Arch: any packages and some Arch: all packages, but which is only
compiled for certain architectures? For instance, cernlib isn't
supported on 64-bit, so I've had it added to Packages-arch-specific. It
has some Arch: all packages that depend or recommend Arch: any packages,
==> said Arch: all packages are uninstallable (or have an unsatisfiable
Recommends) on {alpha,amd64,ia64}. Is this considered to be against policy?
If so, I am not quite sure what to do about it, since making some of the
data packages Arch: any would tremendously bloat the archive. I guess
they could just Suggest the relevant libraries, but this sort of twists
the meaning of Recommends vs. Suggests -- no one would want to have a
data package installed without the corresponding library package.
regards,
--
Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544
New upload of cernlib planned to fix (unfiled) RC bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear release team, My sponsor (Bas) and I are planning an upload of cernlib to unstable with priority medium. The upload fixes an (unfiled) possibly RC bug similar to #245915, but affecting the libgeant1-dev binary package. The problem is that the current library cannot be linked against dynamically due to some undefined symbols. The symbols are undefined due to the necessity of removing non-DFSG code (the "FLUKA" library) from the cernlib source package. The new upload of cernlib will solve the problem by defining dummy symbols to replace the missing ones. Since cernlib takes some time to compile on slower architectures, we would like to ask for people's help in building and uploading the new release, especially on mips, mipsel, arm and m68k, in order to make the August 27 deadline and not overload the buildds. If the deadline is not met, we will plan to upload to t-p-u if the Release Managers approve. Finally, note that cernlib will not automatically transition to testing in any case until its broken ia64 and alpha binary packages are removed from testing; please see (and, if you have the ability, fix :-) bug # 255970 against ftp.debian.org. thanks and regards, - -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBI30GfYxAIk+Dx1ERAgivAKCsdPS+gOBgedBIJ3VEH1NUuafSFACfXZTw QkJuSnfUYDbW9j2OAQKfBNU= =uuJK -END PGP SIGNATURE-
Bad interaction between sed and a2ps breaks apsfilter
I thought it could be informative to forward this email to the
debian-release list, in case any NMUs may be needed. See
http://bugs.debian.org/258042 for the background...
-- Forwarded message --
Date: Fri, 13 Aug 2004 14:19:52 -0400 (EDT)
From: Kevin B. McCarty <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Is this bug the fault of sed or psset? Please reply quickly.
Hi,
The first attachment to this email, psset.sed, is a sed script is created
on-the-fly by psset (in the a2ps package). As you see, lines 5 and 17 of the
script begin with the characters "\countdictstack" (without quotes). However,
versions 4.1-1 and higher of sed treat the "\co" as an escape sequence
representing Ctrl+O (ASCII 15), which breaks the output of psset, and in turn
causes Bug# 258042 that is currently filed against gs. Versions 4.0.9-5 and
earlier of sed do not do anything special with the "\co".
Now, the Info sed manual describes the "\cX" escape sequence, but I am not
intimately familiar with sed so I don't know under what circumstances the
escape is substituted in. If the escape should NOT be substituted in, this is
a bug in sed that should be fixed. On the other hand, if current versions of
sed are behaving correctly, I will reassign it to a2ps.
The second attachment to this email, a2ps.patch, is a trivial patch to fix
psset to work with the current behavior of sed. (The patch is harmless if the
sed behavior is reverted.) I think it should be applied in any case, since sed
is in Base and therefore already frozen, while a2ps is not yet.
Please look after this quickly, because this problem makes apsfilter
essentially unusable as a print filter in sarge.
thanks and regards,
--
Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544:start
/^%%EndSetup$/{
i\
\% Pagedevice definitions:\
\countdictstack\
\% Push our own mark, since there can be several PS marks pushed depending\
\% where the failure really occured.\
\/psset_mark\
\{\
\%%BeginFeature: *Duplex false\
\ (<<) cvx exec /Duplex (false) cvx exec (>>) cvx exec\
\ systemdict /setpagedevice get exec\
\%%EndFeature\
\} stopped\
\% My cleartomark\
\{ /psset_mark eq { exit } if } loop\
\countdictstack exch sub dup 0 gt\
\{\
\ { end } repeat\
\}{\
\ pop\
\} ifelse
b end
}
n
b start
:end
n
b end
diff -ur a2ps-4.13b.old/contrib/psset.in a2ps-4.13b/contrib/psset.in
--- a2ps-4.13b.old/contrib/psset.in Sun Oct 24 08:41:46 1999
+++ a2ps-4.13b/contrib/psset.in Fri Aug 13 14:12:56 2004
@@ -221,7 +221,7 @@
done
pspagedevice="% Pagedevice definitions:
-countdictstack
+ countdictstack
% Push our own mark, since there can be several PS marks pushed depending
% where the failure really occured.
/psset_mark
@@ -229,7 +229,7 @@
} stopped
% My cleartomark
{ /psset_mark eq { exit } if } loop
-countdictstack exch sub dup 0 gt
+ countdictstack exch sub dup 0 gt
{
{ end } repeat
}{
Re: Please remove cernlib from testing
On 07/20/2004 05:14 PM, Colin Watson wrote: > No, removing cernlib from testing will have no effect on this. Your > problem is that the binaries for alpha, hppa, ia64, m68k, and mips are > out of sync in *unstable*. You'll need to arrange for the relevant ones > to be built and the others to be removed by ftpmaster, and then the new > version will propagate to testing. Then I need to wait for ftpmaster to take care of # 255970 and the buildds to catch up, I suppose. Thank you for setting me straight. regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544
Please remove cernlib from testing
Hi all, Could someone please remove cernlib from testing? The latest release is blocked because there are ia64 and alpha .debs in testing, but I have excluded ia64 and alpha from the Arch list recently since cernlib is not 64-bit compatible. Once these are removed, the version of cernlib in unstable should in principle propagate to testing almost immediately. Whoever does so, please also close bug # 255970. Thanks a lot! -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544
