Re: binNMU request generation script
Joachim Breitner writes: > [...] @debian-release: I have tried to merge equal lines for different > arches. [...] > > # Architecture: i386 > # Architecture: amd64 > # Architecture: powerpc Do such rebuild requests need to list all the wacky architecture variants, like i386-kfreebsd? If so, type-handling(1) will help you generate a comprehensive list. $ type-handling Known cpus: alpha amd64 arm armeb armel avr32 hppa i386 ia64 lpia m32r m68k mips mipsel powerpc ppc64 s390 s390x sh3 sh3eb sh4 sh4eb sparc Known systems: darwin freebsd hurd kfreebsd knetbsd kopensolaris linux netbsd openbsd solaris -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Mon, Jul 06, 2009 at 09:47:09PM -0400, John David Anglin wrote: > > If I remember correctly, there's still some issues with the L2 cache on > > pa8800 that we haven't quite bothered to work out yet, since it's "good > > enough" for now. James probably knows more. It would be interesting to > > see if you could reproduce it with a UP 64-bit kernel on your C3750 to > > discount the L2 problems. > > Googling, I see Grant had trouble with RCU_TORTURE_TEST=y. Probably, > I should test current kernel to see if the problem is still present. > > I guess you are referring to this change: > http://fossplanet.com/linux.debian.devel.kernel.cvs/thread-4378354-r7141-patches/ > > I'm thinking we must be missing a flush... Maybe in clear_user_page > as for copy_user_page? > > Do the problematic debian buildd machines have pa8800/pa8900 processors? da...@penalosa:~$ cat /proc/cpuinfo processor : 0 cpu family: PA-RISC 2.0 cpu : PA8700 (PCX-W2) cpu MHz : 750.00 model : 9000/785/J6700 model name: Duet W2 hversion : 0x5dd0 sversion : 0x0491 I-cache : 768 KB D-cache : 1536 KB (WB, direct mapped) ITLB entries : 240 DTLB entries : 240 - shared with ITLB bogomips : 1495.04 software id : 2001606322 > My sense is that some change (probably to the core memory management > code) made the coherence issue worse post 2.6.22.x. > > Dave -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
> If I remember correctly, there's still some issues with the L2 cache on > pa8800 that we haven't quite bothered to work out yet, since it's "good > enough" for now. James probably knows more. It would be interesting to > see if you could reproduce it with a UP 64-bit kernel on your C3750 to > discount the L2 problems. Googling, I see Grant had trouble with RCU_TORTURE_TEST=y. Probably, I should test current kernel to see if the problem is still present. I guess you are referring to this change: http://fossplanet.com/linux.debian.devel.kernel.cvs/thread-4378354-r7141-patches/ I'm thinking we must be missing a flush... Maybe in clear_user_page as for copy_user_page? Do the problematic debian buildd machines have pa8800/pa8900 processors? My sense is that some change (probably to the core memory management code) made the coherence issue worse post 2.6.22.x. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
first try at actions of suiteparse/openmpi transition (was: Re: SuiteSparse 3.2.0->3.4.0 transition)
Kurt Roeckx wrote: > > petsc itself is a problem, though, segfaults on hppa :(. > > (Can this be ignored please given the general hppa problems and this > > stuff hinted in?) > > Given back too, this ussually helps. It failed to some new error (#535276). NMUed it. Unfortunately it failed on hppa again[1].. (#529485, this according to the maintainer seems spuious, though) Can the RM team then please: a) add a hint hint freemat/3.6+dfsg-8+b1 illuminator/0.11.0-3 hypre/2.4.0b-2 openmpi/1.3.2-4 lp-solve/5.5.0.13-6 octave3.0/1:3.0.5-6+b1 octave3.0/1:3.0.5-6+b2 openoffice.org/1:3.1.0-5 petsc/3.0.0.dfsg-5 trilinos/9.0.3.dfsg-1 python-scipy/0.7.0-1+b1 pysparse/1.0.1-5.1 pysparse/1.0.1-5.1+b1 [2] (no idea about the correct version specifiers for bin-NMUs and what do to in the ocave3.0 case where different archs have different +bX) together with the (already existing) remove libmesh/0.6.2.dfsg-1 Maybe that even should be removed from sid or orphaned? $ grep-excuses libmesh libmesh (0.6.2.dfsg-1 to 0.6.3.dfsg~rc1-1) Maintainer: Debian Scientific Computing Team 306 days old (needed 10 days) libmesh0.6.3/i386 unsatisfiable Depends: libscotch-5.0.6 libmesh0.6.3/alpha unsatisfiable Depends: libscotch-5.0.6 libmesh0.6.3/amd64 unsatisfiable Depends: libscotch-5.0.6 libmesh0.6.3/ia64 unsatisfiable Depends: libscotch-5.0.6 libmesh0.6.3/powerpc unsatisfiable Depends: libscotch-5.0.6 libmesh0.6.3/sparc unsatisfiable Depends: libscotch-5.0.6 libmesh (source) has new bugs! Updating libmesh introduces new bugs: #513814, #534057, #529477 Not considered I tried to NMU it but without knowleeg of the build system And maybe even age-days mono/petsc/trillinos b) block packages involved in the transition from being uploaded to *sid*? freemat illuminator hypre openmpi lp-solve octave3.0 openoffice.org [2] petsc trilinos python-scipy pysparse mono libmesh and c) try to get petsc into a working/built state or just force in without... Grüße/Regards, René [1] can we please ignore hppa failures for at least failures which are not the packages' fault? [2] Thankfully, due to consequent use of -Wl,--as-needed the 3.1.1 püackages won't have direct deps on libcolamd2.7.1 anymore, see http://packages.debian.org/experimental/openoffice.org-calc -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Mon, Jul 06, 2009 at 02:45:37PM -0400, John David Anglin wrote: > I have to think that this has something to do with the machine > being a rp3440 (large memory and cache). I have never seen this > on my c3750 with 32-bit UP kernel. Also, this was with a 64-bit > UP kernel. > If I remember correctly, there's still some issues with the L2 cache on pa8800 that we haven't quite bothered to work out yet, since it's "good enough" for now. James probably knows more. It would be interesting to see if you could reproduce it with a UP 64-bit kernel on your C3750 to discount the L2 problems. regards, Kyle -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: unblock request: krb5
2009/7/6 Jurij Smakov : > On Mon, Jul 06, 2009 at 03:19:18PM +0300, Martin-Éric Racine wrote: >> Greetings, >> >> Would it be possible to unblock krb5 and allow it to transit to >> Testing? We need CUPS 1.3.10-5 to go into Testing ASAP to compensate >> for changes in dependencies resulting from the recent repackaging of >> necessary Ghostcript's PPD components into a separate ghostscript-cups >> package. >> >> This new GS package's introduction has generate a lot of bug reports >> from people whose printer requires raster support that was previously >> provided by the main ghostscript package and is now provided by >> ghostscript-cups instead, simply because the components they need are >> not a dependency of the 1.3.10-2 that is currently sitting in Testing, >> which momentarily broke support for their printer. >> >> Allowing 1.3.10-5 into Testing fixes this issue, but this is dependent >> upon krb5 being allowed into Testing first. >> >> Please don't hesitate in contacting me if you have any additional >> question about this request. > > krb5 transition is almost done, as you can see at > > https://buildd.debian.org/transitions/summary.html > > with only 3 problematic packages remaining. We attempted to resolve them > over the weekend, with partial success. Once they are fixed, krb5 will > propagate to testing. Thanks for the explanation on the current situation. Best Regards, Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: binNMU of haskell-haskeline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Mon, 6 Jul 2009 19:52:46 +0100 Jurij Smakov wrote: > On Sun, Jul 05, 2009 at 09:13:32PM +0100, Iain Lane wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Hello, > > > > Can you please schedule a binNMU of haskell-haskeline? It is needed > > to build my package agda. > > I can potentially take care of it, but as I'm new here, you would need > to convince me that it's a right thing to do :-). For example, I see > at > > https://buildd.debian.org/~luk/status/package.php?p=haskell-haskeline&suite=unstable > > that haskell-haskeline is dep-waiting on some packages on armel and > ia64, so binNMU will be inefficient at least on those arches. It > would also help if you could explain what you are trying to achieve. > > Best regards, You can disregard my mail now. Joachim has asked for a much more complete set of binNMUs which supersede (and contain) what I asked for. Regards, Iain -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpSTSkACgkQPy0SnCC/zcdH6QCeL1GyLox+BKV6wGmB+uL+XtEc 2TEAoJUihA9Hee4GkI51tTpag440ow9L =YxgK -END PGP SIGNATURE-
Re: haskell givebacks (manual, I promise :-))
On Mon, Jul 06, 2009 at 04:20:44PM +0200, Joachim Breitner wrote: > Hi, > > unrelated to the automatic binNMUs I have spotted some build-failures > that will work now, so here are the give-backs. I hope that these > problems become less frequent when we can automatically schedule binNMus > with complete Dep-Wait lines. > > gb hdbc-sqlite3_2.1.0.2-1 . amd64 sparc . -m 'Try with a working hdbc' > dw hdbc-sqlite3_2.1.0.2-1 . amd64 sparc . -m 'libghc6-hdbc-dev (>= 2.1.0-3)' > gb hdbc-odbc_2.1.0.0-3 . amd64 sparc . -m 'Try with a working hdbc' > dw hdbc-odbc_2.1.0.0-3 . amd64 sparc . -m 'libghc6-hdbc-dev (>= 2.1.0-3)' Done. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: unblock fontconfig?
On Mon, Jul 06, 2009 at 06:40:19PM +0800, Paul Wise wrote: > Hi all, > > fontconfig has been waiting 21 days for migration, perhaps it should be > unblocked? No RC bugs were filed during that time. debian-boot, please approve, this is blocked due to a udeb. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
> I will reiterate my point here that the dynamic linker the first user > of mmap in a newly started process, and the first program to read and > process data from the mmap'd files. Therefore the dynamic linker is > always the first to suffer if a mapped region of memory is not > correct. That is true to a certain extent. However, there are large portions of code and initialized data that it doesn't touch. I don't think that I've ever seen an invalid instruction fault. So, I'm not fully convinced that we understand the cause of these segvs. As far as I can tell, the mmap'd data appears correct (at least as far as what was recorded in the core file). What is wrong is the l_info field in the linker map. Prior to failing on processing libdl.so.2, it had successfully processed itself and libncurses.so.5 (see NEEDED entries for /bin/sh). There isn't a lot that happens between mmap'ing the file and the access to the STRTAB entry in the l_info field. The NEEDED entry at l_info[1] seems ok in the dump. I doubt this is a TLB issue as the data is a long way from page boundaries. Possibly, there is a cache line issue in the mmap'd file, or as I suggested before a race condition and the file isn't fully mapped when the mmap call returns. In any case, the extraction of the dynamic data failed after doing the first NEEDED entry. I have to think that this has something to do with the machine being a rp3440 (large memory and cache). I have never seen this on my c3750 with 32-bit UP kernel. Also, this was with a 64-bit UP kernel. > What we need to do here is create a test case. > > I tried this: > > 1. cp /lib/libc.so.6 original.so > 2. cp /lib/libc.so.6 map.so > 3. gcc -O2 -g -o test-mmap test-mmap.c > 4. while true; do ./test-mmap ./original.so ./map.so; done; > > The test mmap's a file and compares it to the original, aborting if > the comparison fails. I've yet to see it abort on my a500, and I've > run 20-30 instances of the test simultaneously. Then again I don't see > any serious segv's like others do (2.6.26-1-parisc64-smp). > > What might be a better testcase? I typically run my GCC builds with `make -j 4'. So, there's a mix of other stuff actively running at any time. I'll give the testcase a try tonight. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian 5.02 install
On Mon, Jul 06, 2009 at 03:55:22PM +0100, Allan Fearon wrote: > after doing clean install of Debian 5.02 desktop found that > network-manager and update-manager no longer included by default. is > there a reason for this. Rerouting to debian-boot, where this discussion is more appropriate, debian-release -> bcc. -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: unblock request: krb5
On Mon, Jul 06, 2009 at 03:19:18PM +0300, Martin-Éric Racine wrote: > Greetings, > > Would it be possible to unblock krb5 and allow it to transit to > Testing? We need CUPS 1.3.10-5 to go into Testing ASAP to compensate > for changes in dependencies resulting from the recent repackaging of > necessary Ghostcript's PPD components into a separate ghostscript-cups > package. > > This new GS package's introduction has generate a lot of bug reports > from people whose printer requires raster support that was previously > provided by the main ghostscript package and is now provided by > ghostscript-cups instead, simply because the components they need are > not a dependency of the 1.3.10-2 that is currently sitting in Testing, > which momentarily broke support for their printer. > > Allowing 1.3.10-5 into Testing fixes this issue, but this is dependent > upon krb5 being allowed into Testing first. > > Please don't hesitate in contacting me if you have any additional > question about this request. krb5 transition is almost done, as you can see at https://buildd.debian.org/transitions/summary.html with only 3 problematic packages remaining. We attempted to resolve them over the weekend, with partial success. Once they are fixed, krb5 will propagate to testing. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: binNMU of haskell-haskeline
On Sun, Jul 05, 2009 at 09:13:32PM +0100, Iain Lane wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > > Can you please schedule a binNMU of haskell-haskeline? It is needed to > build my package agda. I can potentially take care of it, but as I'm new here, you would need to convince me that it's a right thing to do :-). For example, I see at https://buildd.debian.org/~luk/status/package.php?p=haskell-haskeline&suite=unstable that haskell-haskeline is dep-waiting on some packages on armel and ia64, so binNMU will be inefficient at least on those arches. It would also help if you could explain what you are trying to achieve. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: HPPA and Squeeze
On Mon, Jul 6, 2009 at 9:28 AM, John David
Anglin wrote:
> Not that I am aware of. The situation is essentially the reverse of
> the above. Data is written from a region of memory. Then, in another
> instance of gcc, it needs to be mmap'ed back to the same location in
> memory. In theory, it could be brought back to a different location
> but this would require a fairly complex set of relocations.
GCC does not read() and write to the mmap()'d file.
The dynamic loader uses MAP_DENYWRITE to avoid writing into the mmap()'d memory.
I will reiterate my point here that the dynamic linker the first user
of mmap in a newly started process, and the first program to read and
process data from the mmap'd files. Therefore the dynamic linker is
always the first to suffer if a mapped region of memory is not
correct.
What we need to do here is create a test case.
I tried this:
1. cp /lib/libc.so.6 original.so
2. cp /lib/libc.so.6 map.so
3. gcc -O2 -g -o test-mmap test-mmap.c
4. while true; do ./test-mmap ./original.so ./map.so; done;
The test mmap's a file and compares it to the original, aborting if
the comparison fails. I've yet to see it abort on my a500, and I've
run 20-30 instances of the test simultaneously. Then again I don't see
any serious segv's like others do (2.6.26-1-parisc64-smp).
What might be a better testcase?
Cheers,
Carlos.
#include
#include
#include /* mmap */
#include /* open */
#include /* open */
#include /* open */
#include /* lseek */
#define BMAX 4096
int
main (int argc, char **argv)
{
void *mappref;
int fd, fdc;
off_t maplength, index, j;
char *original = argv[1], *copy = argv[2];
char buf[BMAX], *mbuf;
ssize_t ret;
/* Open original file to compute size. We open the original
file to simulate having the fd open before mmap as the
dynamic loader does. */
fd = open (original, O_RDONLY);
if (fd == -1)
{
perror ("open");
abort ();
}
maplength = lseek (fd, 0, SEEK_END);
if (fd == -1)
{
perror ("lseek");
abort ();
}
/* Now mmap the open file. */
mappref = mmap ((void *)mappref,
maplength,
PROT_READ | PROT_EXEC,
MAP_PRIVATE | MAP_DENYWRITE | MAP_FILE,
fd,
0);
if (mappref == (void *)-1)
{
perror ("mmap");
abort ();
}
mbuf = (char *)mappref;
/* Compare mmap to copy. */
fdc = open (copy, O_RDONLY);
if (fdc == -1)
{
perror ("open #2");
abort ();
}
for (index = 0; index < maplength; index += BMAX)
{
ret = read (fdc, &buf[0], BMAX);
if ((ret != BMAX) && (ret == -1))
{
perror ("read");
abort ();
}
for (j = 0; ((j < BMAX) && ((index + j) < maplength)); j++)
{
if (mbuf[index + j] != buf[j])
{
fprintf(stderr, "Mismatch at %ld, read %d, expected %d\n",
index + j, (unsigned int)mbuf[index + j], (unsigned int)buf[j]);
abort ();
}
if (DEBUG)
printf ("Match at %ld, read %d, expected %d\n",
index + j, (unsigned int)mbuf[index + j], (unsigned int)buf[j]);
}
}
return 0;
}
debian 5.02 install
after doing clean install of Debian 5.02 desktop found that network-manager and update-manager no longer included by default. is there a reason for this. regards, Allan Fearon -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: xcftools stable and olstable update
Jan Hauke Rahm wrote: On Mon, Jul 06, 2009 at 02:19:28PM +0100, Adam D. Barratt wrote: > Jan Hauke Rahm wrote, Mon, 6 Jul 2009 14:32:14 +0200 http://downloads.jhr-online.de/xcftools/xcftools_1.0.4-1+etch1.dsc http://downloads.jhr-online.de/xcftools/xcftools_1.0.4-1+lenny1.dsc Please go ahead for stable. As far as I can see, the oldstable packages don't actually contain the fix... Yes, I'm sorry, the clean chroot was too clean :) Rebuild and uploaded to the same place: http://downloads.jhr-online.de/xcftools/xcftools_1.0.4-1+etch1.dsc Please re-check. KiBi offered sponsoring. Yep, that looks better. :-) Please go ahead with the oldstable package as well. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: xcftools stable and olstable update
Jan Hauke Rahm (06/07/2009): > Please re-check. KiBi offered sponsoring. JFTR: Both uploaded. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
haskell givebacks (manual, I promise :-))
Hi, unrelated to the automatic binNMUs I have spotted some build-failures that will work now, so here are the give-backs. I hope that these problems become less frequent when we can automatically schedule binNMus with complete Dep-Wait lines. gb hdbc-sqlite3_2.1.0.2-1 . amd64 sparc . -m 'Try with a working hdbc' dw hdbc-sqlite3_2.1.0.2-1 . amd64 sparc . -m 'libghc6-hdbc-dev (>= 2.1.0-3)' gb hdbc-odbc_2.1.0.0-3 . amd64 sparc . -m 'Try with a working hdbc' dw hdbc-odbc_2.1.0.0-3 . amd64 sparc . -m 'libghc6-hdbc-dev (>= 2.1.0-3)' Dear haskellers: The key to avoid these things is to keep the Build-Dependencies (which can not be updated by haskell-devscripts automatically) as high as possible. In this concrete example, John has uploaded haskell-hdbc_2.1.0-3 before hdbc-sqlite3_2.1.0.2-1, but the Build-Deps specify "libghc6-hdbc-dev (>= 2.1.0-2)", causing some buildds to build the packages in the wrong order, trying to build hdbc-sqlite3 with the old, uninstallable hdbc. If this were changed to "libghc6-hdbc-dev (>= 2.1.0-3)", all buildds would have waited for a working version, and no manual interaction were required. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: xcftools stable and olstable update
On Mon, Jul 06, 2009 at 02:19:28PM +0100, Adam D. Barratt wrote: > Jan Hauke Rahm wrote, Mon, 6 Jul 2009 14:32:14 +0200 > >I've been working (QA) on xcftools' bug #533361 > >which upstream kindly provided a small fix for. I'd > >like to see this bug disappear from stable and > >oldstable. I discussed this with the security team > >and they suggested going through (o-)s-p-u. > > >There are packages prepared (and build in appropriate > >clean chroots) available at > > > >http://downloads.jhr-online.de/xcftools/xcftools_1.0.4-1+etch1.dsc > >http://downloads.jhr-online.de/xcftools/xcftools_1.0.4-1+lenny1.dsc > > Please go ahead for stable. > > As far as I can see, the oldstable packages don't actually contain > the fix... Yes, I'm sorry, the clean chroot was too clean :) Rebuild and uploaded to the same place: http://downloads.jhr-online.de/xcftools/xcftools_1.0.4-1+etch1.dsc Please re-check. KiBi offered sponsoring. Hauke signature.asc Description: Digital signature
Re: binNMU request generation script
Hi Marco, hi everyone else. Am Montag, den 06.07.2009, 08:58 -0300 schrieb Marco Túlio Gontijo e Silva: > Em Sun, 05 Jul 2009 23:16:39 +0200 Joachim Breitner > escreveu: > > # Architecture: amd64 > > # Needs binNMus for these sources: > > # missingpy, haskell-haskeline, hdbc-odbc, haskell-hsh, > > hdbc-postgresql, hdbc-sqlite3, haskell-anydbm, hdbc dw > (...) > > Does this script informs about packages that should be binNMU because of a new > GHC version, or is it only about libraries dependencies? I'm asking because > haskell-fgl and haskell-glut were not listed. Right, I missed these. Here is an improved output, with much more results. @debian-release: I have tried to merge equal lines for different arches. All the lines are at the end, until then there are only informational comments. Also, a lot of these add dep-waits for haskell-network which is unbuildable until haskell-parsec2 finally gets out of NEW, where it has been holding up Haskell stuff in Debian for 5 weeks now. It should be ok to apply these deb-wait’s though, so that things get rolling once parsec2 is out of NEW. # Found ghc6 version 6.10.3-3 # Found 116 haskell library source packages # ... of which 116 are buildable and 0 are not buildable. # Architecture: i386 # Needs binNMus for these sources: # haskell-hlist, haskell-vty, haskell-hsql-mysql, haskell-hsql-sqlite3, haskell-tagsoup, haskell-configfile, highlighting-kate, haskell-hsql-postgresql, missingh, haskell-hsh, haskell-arrows, haskell-src-exts, haskell-cgi, haskell-irc, haskelldb-hsql-odbc, hdbc-postgresql, hs-plugins, haskell-fgl, ldap-haskell, haskell-glut, haskell-pcre-light, hslogger, hat, haskell-haskeline, haskelldb-hsql-mysql, haskell-uulib, listlike, haskell-hsql-odbc, washngo, haskelldb-dynamic, ftphs, haskell-hsql, missingpy, haskelldb, haskelldb-hsql-postgresql, pandoc, haskell-http, haskelldb-hsql, haskell-diff, magic-haskell, haxml, haskell-anydbm, haskelldb-hsql-sqlite3, haskell-edison # Architecture: amd64 # Needs binNMus for these sources: # haskell-hlist, haskell-vty, haskell-hsql-mysql, haskell-curl, haskell-hsql-sqlite3, haskell-tagsoup, haskell-network, haskell-configfile, highlighting-kate, haskell-hsql-postgresql, missingh, haskell-hsh, haskell-hsql, haskell-src-exts, haskell-cgi, haskell-irc, haskelldb-hsql-odbc, hdbc-postgresql, hs-plugins, haskell-fgl, ldap-haskell, haskell-glut, haskell-pcre-light, hslogger, hat, haxml, haskell-haskeline, haskelldb-hsql-mysql, haskell-uulib, listlike, hdbc-odbc, washngo, haskelldb-dynamic, ftphs, haskell-arrows, missingpy, haskelldb, haskelldb-hsql-postgresql, pandoc, haskell-http, haskelldb-hsql, haskell-diff, magic-haskell, hdbc-sqlite3, haskell-anydbm, haskelldb-hsql-sqlite3, haskell-hsql-odbc, haskell-edison # Dep-Wait for haskell-hsql-mysql_1.7-2 already up-to-date # Dep-Wait for haskell-curl_1.3.5-2 already up-to-date # Dep-Wait for haskell-hsql-sqlite3_1.7-1 already up-to-date # Dep-Wait for haskell-hsql-postgresql_1.7-2 already up-to-date # Replacing a Dep-Wait in the wanna-build database: # haskell-hsh_2.0.0-1 on amd64 before: 'libghc6-hslogger-dev (>> 1.0.8-1)' now: 'libghc6-hslogger-dev (>> 1.0.8-1), libghc6-missingh-dev (>> 1.1.0-1)' # Replacing a Dep-Wait in the wanna-build database: # haskelldb-hsql-odbc_0.10-1 on amd64 before: 'libghc6-hsql-dev (>> 1.7-2), libghc6-haskelldb-hsql-dev (>> 0.10-2), libghc6-hsql-odbc-dev (>> 1.7-1)' now: 'libghc6-haskelldb-dev (>> 0.10-5+b1), libghc6-haskelldb-hsql-dev (>> 0.10-2), libghc6-hsql-odbc-dev (>> 1.7-1)' # Dep-Wait for hs-plugins_1.2-2 already up-to-date # Replacing a Dep-Wait in the wanna-build database: # haskelldb-hsql-mysql_0.10-1 on amd64 before: 'libghc6-hsql-dev (>> 1.7-2), libghc6-hsql-mysql-dev (>> 1.7-2), libghc6-haskelldb-hsql-dev (>> 0.10-2)' now: 'libghc6-haskelldb-dev (>> 0.10-5+b1), libghc6-haskelldb-hsql-dev (>> 0.10-2), libghc6-hsql-mysql-dev (>> 1.7-2)' # Replacing a Dep-Wait in the wanna-build database: # haskelldb-dynamic_0.10-2 on amd64 before: 'libghc6-plugins-dev (>> 1.2-2)' now: 'libghc6-haskelldb-dev (>> 0.10-5+b1), libghc6-plugins-dev (>> 1.2-2)' # Replacing a Dep-Wait in the wanna-build database: # missingpy_0.10.0.2 on amd64 before: 'libghc6-anydbm-dev (>> 1.0.5.4)' now: 'libghc6-anydbm-dev (>> 1.0.5.4), libghc6-missingh-dev (>> 1.1.0-1)' # Replacing a Dep-Wait in the wanna-build database: # haskelldb-hsql-postgresql_0.10-1 on amd64 before: 'libghc6-hsql-dev (>> 1.7-2), libghc6-hsql-postgresql-dev (>> 1.7-2), libghc6-haskelldb-hsql-dev (>> 0.10-2)' now: 'libghc6-haskelldb-dev (>> 0.10-5+b1), libghc6-haskelldb-hsql-dev (>> 0.10-2), libghc6-hsql-postgresql-dev (>> 1.7-2)' # Replacing a Dep-Wait in the wanna-build database: # haskelldb-hsql_0.10-2 on amd64 before: 'libghc6-hsql-dev (>> 1.7-2)' now: 'libghc6-haskelldb-dev (>> 0.10-5+b1), libghc6-hsql-dev (>> 1.7-2)' # Replacing a Dep-Wait in the wanna-build database: # haskelldb-hsql-sqlite3_0.10-1 on amd64 before: 'libghc6-hsql-dev (>> 1.7-2), libg
Re: HPPA and Squeeze
> > I seem to recall that the kernel mmap implementation on hppa is somewhat > > unique. > > > I don't recall anything, Kyle? > > >>> This came up with respect to the GCC PCH implementation for parisc. See > >>> comments in host-hpux.h. At the moment, we do have a PCH related bug. > >>> See PR 39355. While I know the problem is present in the PCH file, I > >>> haven't been able to figure out how wrong data gets in the file. > >>> > There are some limitations on hppa if a file is both opened for reading > (via read()) and written to via a mmap'ed mapping. This came up a few > years ago. > > Does gcc do this? Not that I am aware of. The situation is essentially the reverse of the above. Data is written from a region of memory. Then, in another instance of gcc, it needs to be mmap'ed back to the same location in memory. In theory, it could be brought back to a different location but this would require a fairly complex set of relocations. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: xcftools stable and olstable update
Jan Hauke Rahm wrote, Mon, 6 Jul 2009 14:32:14 +0200 I've been working (QA) on xcftools' bug #533361 which upstream kindly provided a small fix for. I'd like to see this bug disappear from stable and oldstable. I discussed this with the security team and they suggested going through (o-)s-p-u. There are packages prepared (and build in appropriate clean chroots) available at http://downloads.jhr-online.de/xcftools/xcftools_1.0.4-1+etch1.dsc http://downloads.jhr-online.de/xcftools/xcftools_1.0.4-1+lenny1.dsc Please go ahead for stable. As far as I can see, the oldstable packages don't actually contain the fix... Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
unblock request: krb5
Greetings, Would it be possible to unblock krb5 and allow it to transit to Testing? We need CUPS 1.3.10-5 to go into Testing ASAP to compensate for changes in dependencies resulting from the recent repackaging of necessary Ghostcript's PPD components into a separate ghostscript-cups package. This new GS package's introduction has generate a lot of bug reports from people whose printer requires raster support that was previously provided by the main ghostscript package and is now provided by ghostscript-cups instead, simply because the components they need are not a dependency of the 1.3.10-2 that is currently sitting in Testing, which momentarily broke support for their printer. Allowing 1.3.10-5 into Testing fixes this issue, but this is dependent upon krb5 being allowed into Testing first. Please don't hesitate in contacting me if you have any additional question about this request. Best Regards, Martin-Éric -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
xcftools stable and olstable update
Dear release team, I've been working (QA) on xcftools' bug #533361 which upstream kindly provided a small fix for. I'd like to see this bug disappear from stable and oldstable. I discussed this with the security team and they suggested going through (o-)s-p-u. There are packages prepared (and build in appropriate clean chroots) available at http://downloads.jhr-online.de/xcftools/xcftools_1.0.4-1+etch1.dsc http://downloads.jhr-online.de/xcftools/xcftools_1.0.4-1+lenny1.dsc There is also the latest upstream release[1] on mentors http://mentors.debian.net/debian/pool/main/x/xcftools/xcftools_1.0.7-1.dsc Note two things: a) I am not a DD and need a sponsor for all uploads (I'd appreciate if you could the upload from mentors as well). b) This is my first preparation of packages for (old)stable, so don't kill me if it's wrong. Thanks, Hauke [1] Upstream provided a new release for this fix and during his work he notived two minor bugs which he fixed literally minutes after that in an again new release. Due to license changes (which didn't go entirely right) he released another version on the very same day. Nothing big but confusing. :) signature.asc Description: Digital signature
unblock fontconfig?
Hi all, fontconfig has been waiting 21 days for migration, perhaps it should be unblocked? No RC bugs were filed during that time. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
