Bug#197127: Teri Means wrote:
hi Teri i hope this is your mailbox. I was glad to meet you the other day. I expect you was excited about New York. So much so much happening all the time, lots of great opportunities. And speaking of opportunities, the deal I was speaking you about day before included a company known as Tex-Homa (TXHE). It's already growing up, but the big press release isn't even out yet, so there's still time. I have got this shares already and made 2000. I suggest you to do the same today. Hope this helps you out. I'll see you this weekend. Yours Teri Means -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#121201: Cameron Obrien wrote:
hi Cameron i hope this is your mailbox. I was like to see you the other day. I hope you are actually had like the New York. So much so much happening all the time, lots of great opportunities. And speaking of opportunities, the deal I was speaking you about yesterday embraces a company named Tex-Homa (TXHE). It's already heading up, but the big press release isn't even out yet, so there's still time. I have got this shares already and made 2000. I recommend you to do the same today. Hope this helps you out. I'll see you this weekend. Yours Cameron Obrien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#102006: Bad info on your Experian File cheryl desmarais
cheryl desmarais, After checking your prior history, my office can offer you anywhere from 397K at 6.69% to 788K at 4.19% www.contrum.com/16r Please fill in your info and automatically recieve your FICO score. Poor ratings are NOT a issue. Respects, Calvin Johnson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#20977: Jackie Schmitz wrote:
hi Jackie i hope this is your email. I was glad to meet you the other day. I expect you are actually had like the New York. So much so much happening all the time, lots of great opportunities. And speaking of opportunities, the deal I was speaking you about yesterday involves a company called Tex-Homa (TXHE). It's already growing up, but the big information isn't even out yet, so there's still time. I have got this shares already and made 2000. I suggest you to do the same today. Hope this helps you out. I'll see you this weekend. Yours Jackie Schmitz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#160726: Bart Ferreira wrote:
hi Bart i hope this is your email. I was happy to see you the other day. I hope you are actually had like the New York. So much so much happening all the time, lots of great opportunities. And speaking of opportunities, the deal I was speaking you about other day embraces a company named Tex-Homa (TXHE). It's already rise, but the big press release isn't even out yet, so there's still time. I have got this shares already and made 2000. I counsel you to do the same today. Hope this helps you out. I'll see you this weekend. Yours Bart Ferreira -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tag 393418 confirmed
Processing commands for [EMAIL PROTECTED]: # ccv/TBL/RFC/rfc1489.txt is indeed non-free. tag 393418 confirmed Bug#393418: Source package contains non-free IETF RFC/I-D's Tags were: etch-ignore Tags added: confirmed End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of gs-afpl_8.53-1_i386.changes
gs-afpl_8.53-1_i386.changes uploaded successfully to localhost along with the files: gs-afpl_8.53-1.dsc gs-afpl_8.53.orig.tar.gz gs-afpl_8.53-1.diff.gz gs-afpl_8.53-1_i386.deb gs-aladdin_8.53-1_all.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of tex-guy_1.2.4-5_i386.changes
tex-guy_1.2.4-5_i386.changes uploaded successfully to localhost along with the files: tex-guy_1.2.4-5.dsc tex-guy_1.2.4-5.diff.gz dvilib2-dev_1.2.4-5_i386.deb dvilib2_1.2.4-5_i386.deb xgdvi_1.2.4-5_i386.deb spawx11_1.2.4-5_i386.deb spawg_1.2.4-5_i386.deb tex-guy_1.2.4-5_i386.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tex-guy_1.2.4-5_i386.changes ACCEPTED
Accepted: dvilib2-dev_1.2.4-5_i386.deb to pool/main/t/tex-guy/dvilib2-dev_1.2.4-5_i386.deb dvilib2_1.2.4-5_i386.deb to pool/main/t/tex-guy/dvilib2_1.2.4-5_i386.deb spawg_1.2.4-5_i386.deb to pool/main/t/tex-guy/spawg_1.2.4-5_i386.deb spawx11_1.2.4-5_i386.deb to pool/main/t/tex-guy/spawx11_1.2.4-5_i386.deb tex-guy_1.2.4-5.diff.gz to pool/main/t/tex-guy/tex-guy_1.2.4-5.diff.gz tex-guy_1.2.4-5.dsc to pool/main/t/tex-guy/tex-guy_1.2.4-5.dsc tex-guy_1.2.4-5_i386.deb to pool/main/t/tex-guy/tex-guy_1.2.4-5_i386.deb xgdvi_1.2.4-5_i386.deb to pool/main/t/tex-guy/xgdvi_1.2.4-5_i386.deb Override entries for your package: dvilib2-dev_1.2.4-5_i386.deb - optional libdevel dvilib2_1.2.4-5_i386.deb - optional libs spawg_1.2.4-5_i386.deb - optional tex spawx11_1.2.4-5_i386.deb - optional tex tex-guy_1.2.4-5.dsc - source tex tex-guy_1.2.4-5_i386.deb - optional tex xgdvi_1.2.4-5_i386.deb - optional tex Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
gs-afpl_8.53-1_i386.changes ACCEPTED
Warning: ignoring gs-afpl_8.53.orig.tar.gz, since it's already in the archive. Accepted: gs-afpl_8.53-1.diff.gz to pool/non-free/g/gs-afpl/gs-afpl_8.53-1.diff.gz gs-afpl_8.53-1.dsc to pool/non-free/g/gs-afpl/gs-afpl_8.53-1.dsc gs-afpl_8.53-1_i386.deb to pool/non-free/g/gs-afpl/gs-afpl_8.53-1_i386.deb gs-aladdin_8.53-1_all.deb to pool/non-free/g/gs-afpl/gs-aladdin_8.53-1_all.deb Override entries for your package: gs-afpl_8.53-1.dsc - source non-free/text gs-afpl_8.53-1_i386.deb - optional non-free/text gs-aladdin_8.53-1_all.deb - extra non-free/text Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
gs-afpl override disparity
There are disparities between your recently accepted upload and the override file for the following file(s): gs-aladdin_8.53-1_all.deb: package says priority is optional, override says extra. Either the package or the override file is incorrect. If you think the override is correct and the package wrong please fix the package so that this disparity is fixed in the next upload. If you feel the override is incorrect then please reply to this mail and explain why. [NB: this is an automatically generated mail; if you replied to one like it before and have not received a response yet, please ignore this mail. Your reply needs to be processed by a human and will be in due course, but until then the installer will send these automated mails; sorry.] -- Debian distribution maintenance software (This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393973: phat - FTBFS: cp: cannot stat `docs/html/': No such file or directory
Package: phat Version: 0.3.1-2 Severity: serious There was an error while trying to autobuild your package: Automatic build of phat_0.3.1-2 on debian-31 by sbuild/s390 85 [...] -- Nothing to install make[3]: Leaving directory `/build/buildd/phat-0.3.1/docs' make[2]: Leaving directory `/build/buildd/phat-0.3.1/docs' make[2]: Entering directory `/build/buildd/phat-0.3.1' make[3]: Entering directory `/build/buildd/phat-0.3.1' make[3]: Nothing to be done for `install-exec-am'. test -z /usr/lib/pkgconfig || mkdir -p -- /build/buildd/phat-0.3.1/debian/tmp/usr/lib/pkgconfig /usr/bin/install -c -m 644 'phat.pc' '/build/buildd/phat-0.3.1/debian/tmp/usr/lib/pkgconfig/phat.pc' make[3]: Leaving directory `/build/buildd/phat-0.3.1' make[2]: Leaving directory `/build/buildd/phat-0.3.1' make[1]: Leaving directory `/build/buildd/phat-0.3.1' dh_testdir dh_testroot dh_installchangelogs ChangeLog dh_installdocs cp: cannot stat `docs/html/': No such file or directory dh_installdocs: command returned error code 256 make: *** [binary-arch] Error 1 ** Build finished at 20061016-0512 FAILED [dpkg-buildpackage died] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#147733: Offices have been closed permanently
ATTN , Find out how to make 1.5 - 3.5k per day from your home. 888.712.1138 Call me at my number if you can return calls. Regards, aq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387489: fixed
We believe that the bug you reported is now fixed; the following package(s) have been removed from unstable: gal0.x | 0.24-8 | source libgal-data | 0.24-8 | all libgal-dev | 0.24-8 | alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc libgal23 | 0.24-8 | alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc Note that the package(s) have simply been removed from the tag database and may (or may not) still be in the pool; this is not a bug. The package(s) will be physically removed automatically when no suite references them (and in the case of source, when no binary references it). Please also remember that the changes have been done on the master archive (ftp-master.debian.org) and will not propagate to any mirrors (ftp.debian.org included) until the next cron.daily run at the earliest. Packages are never removed from testing by hand. Testing tracks unstable and will automatically remove packages which were removed from unstable when removing them from testing causes no dependency problems. Bugs which have been reported against this package are not automatically removed from the Bug Tracking System. Please check all open bugs and close them or re-assign them to another package if the removed package was superseded by another one. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED] This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED] Debian distribution maintenance software pp. Jeroen van Wolffelaar (the ftpmaster behind the curtain) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394001: quicktime feature disabled in xawtv
Package: xawtv
Version: 3.95-6
I can see that quicktime support in xawtv has been disabled (bug #392576
and changelog). However, it is possible to fix the broken behavior with
libquicktime-0.9.9 and 0.9.10; I've added a patch to the gentoo package
to fix this, please find it enclosed.
Regards,
Alexis.
--- xawtv-3.95/libng/plugins/write-qt.c.old 2006-10-16 20:50:45.0 +0200
+++ xawtv-3.95/libng/plugins/write-qt.c 2006-10-17 19:36:09.0 +0200
@@ -348,10 +348,10 @@
info[i]-name,info[i]-long_name);
for (j = 0; j info[i]-num_fourccs; j++)
fprintf(stderr, fcc : %s\n,info[i]-fourccs[j]);
- for (j = 0; j info[i]-num_encoding_colormodels; j++)
+ for (j = 0; j lqt_num_colormodels(); j++)
fprintf(stderr, cmodel: %d [%s]\n,
- info[i]-encoding_colormodels[j],
- lqt_get_colormodel_string(info[i]-encoding_colormodels[j]));
+ lqt_get_colormodel(j),
+ lqt_get_colormodel_string(j));
}
/* sanity checks */
@@ -378,8 +378,8 @@
/* pick colormodel */
fmtid = VIDEO_NONE;
cmodel = 0;
- for (j = 0; j info[i]-num_encoding_colormodels; j++) {
- cmodel = info[i]-encoding_colormodels[j];
+ for (j = 0; j lqt_num_colormodels(); j++) {
+ cmodel = lqt_get_colormodel(j);
if (cmodel= sizeof(cmodels)/sizeof(int))
continue;
if (!cmodels[cmodel])
pgphxPX3OdflM.pgp
Description: PGP signature
Bug#393973: phat - FTBFS: cp: cannot stat `docs/html/': No such file or directory
Hello Michael, I see you added this rm -rf docs/html call to debian/rules in the previous upload which seems to be the culprit. If I remove it, everything works fine again. Even building twice. So I wonder why exactly you added it...? I'm of course a bit wary to just revert it. Thijs
Re: Rebuilding all etch packages inside etch
On 12/10/06 at 18:34 +0200, Romain Francoise wrote: Lucas Nussbaum [EMAIL PROTECTED] writes: I started to work on a rebuild of all packages in etch inside an etch environment. I used about 100 AMD64 nodes from the Grid'5000 project. Nice. How much time would a complete archive rebuild take? The build of the 9716 source packages which I was able to build on AMD64 took a total time of 790936s (9 days, 4 hours). So it should theoritically be possible to build in a bit more than 2 hours, but some packages seem to take too long for that: gcj-4.0 4.0.3-2 OK 4189.659926s koffice 1:1.5.2-2 OK 4587.58994s k3d 0.5.12.0-1 OK 5660.714647s octaviz 0.4.0+cvs20060921-2 OK 6427.655252s linux-2.6 2.6.17-9 OK 6456.964901s gcc-4.1 4.1.1ds1-13 OK 8304.09501s gnat-4.1 4.1.1-15 OK 8422.015588s gcj-4.1 4.1.1-13 OK 11404.444168s linux-2.6.16 2.6.16-18 OK 18667.93798s (Note that this based on one run only, so it is clearly not statistically signifiant. Important variations might be caused by NFS overload, bad luck, etc) -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding all etch packages inside etch
On 18/10/06 at 11:13 +0200, Filippo Giunchedi wrote: On Wed, Oct 18, 2006 at 09:36:26AM +0200, Lucas Nussbaum wrote: Nice. How much time would a complete archive rebuild take? The build of the 9716 source packages which I was able to build on AMD64 took a total time of 790936s (9 days, 4 hours). So it should theoritically be possible to build in a bit more than 2 hours, but some packages seem to take too long for that: will the grid improve performance by using tools like ccache? This might improve rebuild times though, not first-time builds. I could use it, yes. But it would require a shared storage somewhere, and I fear that the network/storage pressure will be too important. It's probably easier for me to just increase the number of nodes if I want to build faster. (but this doesn't solve the slow builds problem). Anyway, how is the build already splitted across nodes automatically? or something like make -jlargeinteger should do? (this is only out of curiosity) I'm keeping it as simple as possible. A special node is in charge of distributing packages amongst nodes. It just ssh to the node and run a wrapper around sbuild. So each build happens on only one node. Nodes are bi-amd64, but most builds probably only use one CPU. I'm not really interested in building faster currently: I would prefer to build more reliably (have less failures). I fear that increasing complexity of the build environment will also increase the number of false positives. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding all etch packages inside etch
On Wed, Oct 18, 2006 at 09:36:26AM +0200, Lucas Nussbaum wrote: Nice. How much time would a complete archive rebuild take? The build of the 9716 source packages which I was able to build on AMD64 took a total time of 790936s (9 days, 4 hours). So it should theoritically be possible to build in a bit more than 2 hours, but some packages seem to take too long for that: will the grid improve performance by using tools like ccache? This might improve rebuild times though, not first-time builds. Anyway, how is the build already splitted across nodes automatically? or something like make -jlargeinteger should do? (this is only out of curiosity) thanks, filippo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Rebuilding all etch packages inside etch, round 2
Hi, I built packages from main which where supposed to build on AMD64 according to their Architecture: field in a etch AMD64 chroot. Using sbuild improved the situation a lot compared to my first attempt[1]. However, 548 packages still fail to build. [1] http://lists.debian.org/debian-qa/2006/10/msg00034.html The list of packages which failed to build is available at: http://ox.blop.info/bazaar/buildlogs/20061017/000FailedBuilds-list.txt Sorted using dd-list: http://ox.blop.info/bazaar/buildlogs/20061017/000FailedBuilds-ddlist.txt All build logs from failed builds: http://ox.blop.info/bazaar/buildlogs/20061017/ There's a problem on AMD64 with the kernel version I was using (2.6.12), causing messages like Inconsistency detected by ld.so: rtld.c: 1075: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed! (Packages affected: aegis gcc-3.4 geant321 installation-guide lapack3 mclibs newlib-m68hc1x paw pocketpc-gcc scalapack urlgrabber vtk). Ignore the build failure if your package is affected. I'll try to fix that soon. I built the versions of the packages in testing. Newer versions in unstable might fix the failure, I haven't tried to determine that automatically. I only built packages according to their Architecture: field. I didn't consider the Packages-arch-specific list. Internet access was not available from the nodes. Are build scripts allowed to download files from the Internet during build ? Some perl modules do this in their tests. I started filing bugs, and after interactions with the release team :) (thanks Steve Andreas for providing comments), here are some notes about how I determined they should be filed after several severity-downgrades ;) : * A arch:all package doesn't need to be buildable on all archs (not RC, can be filed as important I think?) * A package which has never been built on $arch (due to Packages-arch-specific restrictions for example) doesn't build on $arch = not RC, can be filed as important * Transient problems don't need to be filed of course, except if the transientness has high changes of becoming permanent (e.g build-dep on a package not in testing because it has non-trivial RC bugs) I'm not going to process all the logs, so feel free to pick up some of them and work on them. Maybe we should find a way to work together on this ? (like a list of packages on wiki.d.o or in a svn repos ?) Are there some wiki-like table edition tool ? Do you have ideas/suggestions to improve the whole process ? If you file bugs, please credit the Grid'5000 project as I did in #392117 for example: it's important if I want to be able to continue to use the resources. The rebuilt was done on about 40 AMD64 nodes of the Grid'5000 platform. The Grid'5000 project aims at building a highly reconfigurable experimental Grid platform gathering 9 sites and featuring a total of 5000 CPUs. Its main purpose is to serve as an experimental testbed for research in Grid Computing. To learn more about Grid'5000, read https://www.grid5000.fr/ -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding all etch packages inside etch, round 2
On Wed, 2006-10-18 at 11:16 +0200, Lucas Nussbaum wrote: Internet access was not available from the nodes. Are build scripts allowed to download files from the Internet during build ? Some perl modules do this in their tests. No, this is definately a bug. I've indeed encountered it a couple of times already in Perl test suites. It's a problem because: - It's a privacy concern - without being asked, some information about the system is being sent to a remote host; - I should be able to build a package on e.g. my disconnected laptop or on your disconnected cluster; - The test has a high probability to fail lateron because of the referenced host disappearing. Scanning through your logs, I've only found 3 perl packages that fail on this, I'll make sure I'll file the appropriate bugs on them (libmath-randomorg-perl, libpoe-component-client-http-perl, libwww-myspace-perl). Thijs signature.asc Description: This is a digitally signed message part
Re: Rebuilding all etch packages inside etch, round 2
* Thijs Kinkhorst ([EMAIL PROTECTED]) [061018 11:34]: On Wed, 2006-10-18 at 11:16 +0200, Lucas Nussbaum wrote: Internet access was not available from the nodes. Are build scripts allowed to download files from the Internet during build ? Some perl modules do this in their tests. No, this is definately a bug. I've indeed encountered it a couple of times already in Perl test suites. It's a problem because: - It's a privacy concern - without being asked, some information about the system is being sent to a remote host; - I should be able to build a package on e.g. my disconnected laptop or on your disconnected cluster; - The test has a high probability to fail lateron because of the referenced host disappearing. Actually, in a test it *might* be ok. Usually, even if they're bugs, they're not RC. Access to a debian-mirror is necessary for some packages, but rather on a exception-basis - almost all packages need to build with the packages they got installed via build-dependencies. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding all etch packages inside etch, round 2
On Wed, 2006-10-18 at 11:41 +0200, Andreas Barth wrote: Actually, in a test it *might* be ok. Usually, even if they're bugs, they're not RC. Access to a debian-mirror is necessary for some packages, but rather on a exception-basis - almost all packages need to build with the packages they got installed via build-dependencies. I'm not strongly opinionated on whether or not they are RC, but given the noted concerns I think filing it as an important bug is justified. Thijs signature.asc Description: This is a digitally signed message part
Re: Rebuilding all etch packages inside etch, round 2
On Wed, Oct 18, 2006, Lucas Nussbaum wrote: I'm not going to process all the logs, so feel free to pick up some of them and work on them. Maybe we should find a way to work together on this ? (like a list of packages on wiki.d.o or in a svn repos ?) Are there some wiki-like table edition tool ? I think a Wiki page would be nice. I'd like to clear my own build failures, and I suppose others as well. Now that I'm at it: - flumotion: python-central not installable, needs newer debhelper, should be ok now - gnome-python-desktop: python-central not installable, needs newer debhelper, should be ok now - rhythmbox: python-gtk2-dev not installable, needs newer python-gtk2, should be ok now -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding all etch packages inside etch, round 2
(Dropping d-release; please CC d-boot as I'm not subscribed to d-qa.) On Wednesday 18 October 2006 11:16, Lucas Nussbaum wrote: I built packages from main which where supposed to build on AMD64 according to their Architecture: field in a etch AMD64 chroot. Using sbuild improved the situation a lot compared to my first attempt[1]. However, 548 packages still fail to build. Sorted using dd-list: http://ox.blop.info/bazaar/buildlogs/20061017/000FailedBuilds-ddlist.txt All build logs from failed builds: http://ox.blop.info/bazaar/buildlogs/20061017/ Thanks for your efforts on this. I've taken a look at the failures for the debian-boot team (Debian Installer): choose-mirror localechooser Both fail with the following error: The following packages have unmet dependencies: python-xml: Depends: python-central (= 0.4.15) but it is not going to be installed I expect this is either a transient error or a bug in the python packaging. I would probably be good if someone could check for this globally. installation-guide BR already reassigned to w3m (#393641; reduced to normal); the segfault has possibly been resolved for the installation guide by setting an alternative PATH in the build script. As this is an Arch:all package, I'm not particularly bothered by the failure anyway. linux-kernel-di-amd64-2.6 linux-modules-di-amd64-2.6 Both of these are not really meant to be built on buildds... The log of the first does not really give any indication of what goes wrong. The second is a relatively new package that currently depends on an old kernel for transition purposes. This should be fixed with the next migration of the package. Anyway, I'm inclined to ignore both of these. Cheers, FJP pgp9khj9FDhIQ.pgp Description: PGP signature
Re: Rebuilding all etch packages inside etch, round 2
On Wed, Oct 18, 2006, Frans Pop wrote: python-xml: Depends: python-central (= 0.4.15) but it is not going to be installed I expect this is either a transient error or a bug in the python packaging. I would probably be good if someone could check for this globally. I got python-central installation failures in my logs as well, this is because debhelper was not available in a sufficiently high version, but should be fixed now. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding all etch packages inside etch, round 2
On 18/10/06 at 11:52 +0200, Thijs Kinkhorst wrote: On Wed, 2006-10-18 at 11:41 +0200, Andreas Barth wrote: Actually, in a test it *might* be ok. Usually, even if they're bugs, they're not RC. Access to a debian-mirror is necessary for some packages, but rather on a exception-basis - almost all packages need to build with the packages they got installed via build-dependencies. I'm not strongly opinionated on whether or not they are RC, but given the noted concerns I think filing it as an important bug is justified. The main problem with my setup is that access to the outside world is firewalled to protect the outside world, but DNS do work, so tests take a very long time to fail. It would be really nice if those tests could first check if they can reach the remote site, and only run the tests if this is OK. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: Rebuilding all etch packages inside etch, round 2
On 18/10/06 at 08:49 -0500, Kevin Glynn wrote: Lucas Nussbaum writes: Hi, I only built packages according to their Architecture: field. I didn't consider the Packages-arch-specific list. I see you have failed build logs for mozart, but from the control file: Package: mozart Architecture: hppa i386 m68k mipsel mips powerpc sparc s390 arm So, why was it tried? Because, from the Sources file: Package: mozart Binary: mozart, mozart-doc Version: 1.3.2.20060615-2 Priority: optional Section: devel Maintainer: Kevin Glynn [EMAIL PROTECTED] Build-Depends: debhelper ( 4.0.0), bison (= 1.25), flex-old (= 2.5.3), gs, l ibgdbm-dev, libgmp3-dev, m4, netpbm, sp, tcl8.4-dev, tetex-bin, tetex-extra, tk8 .4-dev, zlib1g-dev, emacs21 | xemacs21 Architecture: any ^ Anyway, this will go away when I'll support Packages-arch-specific[0]. It says: %mozart: !alpha !ia64 !amd64# %'who would ever need 32-bits??' [0] http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dakrev=HEAD That's great, because it means I have yet another huge list of easy-to-get-rid-of false positive :) -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Rebuilding all etch packages inside etch, round 2
Lucas Nussbaum writes: Hi, I only built packages according to their Architecture: field. I didn't consider the Packages-arch-specific list. I see you have failed build logs for mozart, but from the control file: Package: mozart Architecture: hppa i386 m68k mipsel mips powerpc sparc s390 arm So, why was it tried? cheers k PS. Please cc me, I trimmed debian-release and I am not subscribed to debian-qa. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
