Re: Apology to german users required in the release notes
Frankly, I am getting tired of discussing this issue. I can't understand why you, gotom, are that stubborn and can't respect a decision taken by the German translation team. You already stated at the very beginning of this bug report, that you find it not well inspected [6]... To me your reluctance rather seems like a personal/social quirk. It's a pity :-( I am sorry that I have to say that, I don't intend to offend Well, I must say that even if you're right (you seem), yes you should be sorry for saying that. I've been lucky enough for meeting Masanori Goto at Debconf and I never felt him as a stubborn guy. We even quite widely discussed about the addition of new locales to Debian and I felt him quite well opened to enhancements in this fieldas well as very aware of the hidden implications of locales changes. Certainly very careful at working on his tasks in Debian. Maybe too careful in your opinion but certainly not stubborn. Changing the behaviour of the german locale is certainly something that should not be done without deep thinking. The german team seems to have done this with the help of others like Denis. That's fine. Re-opening this issue was probably a good idea and re-trying to convince gotom also. But this can probably be done without falling into personal stuff, imho.
Re: Apology to german users required in the release notes
Christian Perrier [EMAIL PROTECTED] writes: Changing the behaviour of the german locale is certainly something that should not be done without deep thinking. The german team seems to have done this with the help of others like Denis. That's fine. At some point, gotom needs to either accept that the German team has *done* the deep thinking, or else do it himself. So far he declared it a wishlist item (AFAICT) and refused to either think about it *or* take the German team's word for it. And now, it does seem a terrible shame that we aren't able to ship with a fixed version because of this. Thomas
Re: Apology to german users required in the release notes
At some point, gotom needs to either accept that the German team has *done* the deep thinking, or else do it himself. So far he declared it a wishlist item (AFAICT) and refused to either think about it *or* take the German team's word for it. Well, maybebut being rude in words towards him doesn't help that much. Most involved parties are non-native English people and words must be very cerfully chosen in such arguments. My point was just enhancing this...deciding who is right and who isn't is not possible for me as I didn't follow the whole discussion. My other point was just sharing my feeling of Masanori Goto certainly not being a stubborn man
Temporary removal of cyphesis-cpp package from sarge/testing
Hi, Can you please temporary remove cyphesis-cpp package from sarge/testing to make a newer version of it (not build on arm yet), mercator and sear (also not build on arm yet) migrate to it ? Thanks for your time, Michael
Re: Temporary removal of cyphesis-cpp package from sarge/testing
On Wed, Sep 01, 2004 at 09:20:47AM +0200, Michael Koch wrote: Can you please temporary remove cyphesis-cpp package from sarge/testing to make a newer version of it (not build on arm yet), mercator and sear (also not build on arm yet) migrate to it ? Removing the package from testing has no bearing on whether the new version will get in. Is there some reason that the version in testing is unreleasable? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Temporary removal of cyphesis-cpp package from sarge/testing
* Michael Koch ([EMAIL PROTECTED]) [040901 09:40]: Can you please temporary remove cyphesis-cpp package from sarge/testing to make a newer version of it (not build on arm yet), mercator and sear (also not build on arm yet) migrate to it ? For testing migration, it doesn't matter if a old version of it is in sarge or not. If it is not built on all archs in unstable, it does not go in[1]. So, to achive this goal, the outdated version in unstable needs to be removed. However, removing outdated binaries happens only if the package does not work on that archs any more, and also then only by ftp-masters. So, removing a package from testing does not help at all its propagation back into testing. (This seems to be a common misunderstanding about how britney works.) Cheers, Andi [1] Except if the RMs use a big enough hammer, like the force-hint. -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Temporary removal of cyphesis-cpp package from sarge/testing
Am Mittwoch, 1. September 2004 09:40 schrieb Steve Langasek: On Wed, Sep 01, 2004 at 09:20:47AM +0200, Michael Koch wrote: Can you please temporary remove cyphesis-cpp package from sarge/testing to make a newer version of it (not build on arm yet), mercator and sear (also not build on arm yet) migrate to it ? Removing the package from testing has no bearing on whether the new version will get in. Is there some reason that the version in testing is unreleasable? The current version in testing prevents sear from migrating into testing and I would like to have sear released. cyphesis-cpp in testing depends on libmercater-0.2, cyphesis-cpp and sear in unstable depend on libmercator-0.2-1. cyphesis-cpp in testing exits on arm, the version in unstable does not yet. Michael
Re: Temporary removal of cyphesis-cpp package from sarge/testing
On Wed, Sep 01, 2004 at 09:59:51AM +0200, Michael Koch wrote: Am Mittwoch, 1. September 2004 09:40 schrieb Steve Langasek: On Wed, Sep 01, 2004 at 09:20:47AM +0200, Michael Koch wrote: Can you please temporary remove cyphesis-cpp package from sarge/testing to make a newer version of it (not build on arm yet), mercator and sear (also not build on arm yet) migrate to it ? Removing the package from testing has no bearing on whether the new version will get in. Is there some reason that the version in testing is unreleasable? The current version in testing prevents sear from migrating into testing and I would like to have sear released. cyphesis-cpp in testing depends on libmercater-0.2, cyphesis-cpp and sear in unstable depend on libmercator-0.2-1. cyphesis-cpp in testing exits on arm, the version in unstable does not yet. $ grep-excuses sear sear (- to 0.5.0-3) Maintainer: Michael Koch 23 days old (needed 10 days) out of date on arm: sear (from 0.4.6-3) Not considered Depends: sear mercator Depends: sear sear-media (not considered) $ Removing cyphesis-cpp will have no effect on sear's eligibility for sarge. If and when sear is built on arm, we can reevaluate whether cyphesis-cpp needs to be removed -- but this is only likely if there is a bug in *cyphesis-cpp* causing it to not be built on arm. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Temporary removal of cyphesis-cpp package from sarge/testing
Am Mittwoch, 1. September 2004 10:21 schrieb Steve Langasek: On Wed, Sep 01, 2004 at 09:59:51AM +0200, Michael Koch wrote: Am Mittwoch, 1. September 2004 09:40 schrieb Steve Langasek: On Wed, Sep 01, 2004 at 09:20:47AM +0200, Michael Koch wrote: Can you please temporary remove cyphesis-cpp package from sarge/testing to make a newer version of it (not build on arm yet), mercator and sear (also not build on arm yet) migrate to it ? Removing the package from testing has no bearing on whether the new version will get in. Is there some reason that the version in testing is unreleasable? The current version in testing prevents sear from migrating into testing and I would like to have sear released. cyphesis-cpp in testing depends on libmercater-0.2, cyphesis-cpp and sear in unstable depend on libmercator-0.2-1. cyphesis-cpp in testing exits on arm, the version in unstable does not yet. $ grep-excuses sear sear (- to 0.5.0-3) Maintainer: Michael Koch 23 days old (needed 10 days) out of date on arm: sear (from 0.4.6-3) Not considered Depends: sear mercator Depends: sear sear-media (not considered) $ Removing cyphesis-cpp will have no effect on sear's eligibility for sarge. If and when sear is built on arm, we can reevaluate whether cyphesis-cpp needs to be removed -- but this is only likely if there is a bug in *cyphesis-cpp* causing it to not be built on arm. Okay. I dont understand it but thanks for your help. Michael
Re: Upgrade report: woody-sarge
On Sun, Aug 01, 2004 at 03:52:54PM -0400, Joey Hess wrote: It seems that our perl upgrade from woody to sarge is not robust if it dies in the middle. The X problem below caused the first apt run to fail with various parts of perl unpacked and not configured. Then it looks like debconf (which uses Iconv) was unable to run. Probably a dpkg --configure -a would have cleared this up; reinstalling perl manually had the same result. [...] Preparing to replace x-dev 4.3.0.dfsg.1-0.woody.1 (using .../x-dev_4.3.0.dfsg.1-4_all.deb) ... Unpacking replacement x-dev ... dpkg: error processing /var/cache/apt/archives/x-dev_4.3.0.dfsg.1-4_all.deb (--unpack): trying to overwrite `/usr/X11R6/include/X11/DECkeysym.h', which is also in package xlibs-dev dpkg-deb: subprocess paste killed by signal (Broken pipe) Please note that version number. 4.3.0.dfsg.1-0.woody.1 is some sort of unofficial backport. My versioned conflicts/replaces/provides/etc. cannot be expected to take into account the crazy things backporters do. I will support upgrades from woody systems. I don't think it's reasonable to expect any Debian developer to support upgrades from loony hybrid installations using all manner of unofficial packages we've never even shipped. -- G. Branden Robinson|If a man ate a pound of pasta and a Debian GNU/Linux |pound of antipasto, would they [EMAIL PROTECTED] |cancel out, leaving him still http://people.debian.org/~branden/ |hungry? -- Scott Adams signature.asc Description: Digital signature
Re: Bug#247176: Preparing a autobuildable package of perl for testing-proposed-updates
On 2004-08-29 Andreas Metzler [EMAIL PROTECTED] wrote: On 2004-08-09 Brendan O'Dea [EMAIL PROTECTED] wrote: On Thu, Aug 05, 2004 at 01:19:24PM +0200, Andreas Metzler wrote: [...] http://www.logic.univie.ac.at/~ametzler/debian/NMU/perl_5.8.4-2.1.NMU.diff All this has happened almost three weeks ago without further comment yet[1] by Brendan, therefore I have decided to go for the NMU, time is starting to become a pressing issue for sarge. Dear release-managers: Are you interested in a autobuildable perl-package for sarge? Do you want me to upload to tpu? The interdiff is quite small (see URL) and the package builds successfully on i386 and ia64 (ia64 is one of the broken architectures.) [...] I've received a slight encouragment on IRC and intend to go ahead. However I'll need to upload to sid instead of sarge. - I cannot fullfill the requirement version in sarge tpu sid as perl is up-to-date in sarge. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Quality of nagios packages in Sarge
Hi, I want to raise some concern about the quality of the nagios-text package in testing. There are a number of bug reports (at least #239174, #257702, and #265467) that are fixed with the suggestion mentioned in #239174. I also see that Madarasz Gergely has made a suggestion about this bug in the changelog of #257702. I've contacted Guido Trotter informally about this bug, as I had noticed that he had done some NMUs for some nagios packages recently. Apparently, this bug will not be fixed in time for the Sarge release. I just want to ask around on this list if there is absolutely no way around this ? None of those reported bugs are filed as grave, but maybe they should have been: eg. if state retention doesn't work, it is impossible to make any change to Nagios and even kill -HUP the main process (as is done via /etc/init.d/nagios reload) without Nagios losing all its state data. Surely this qualifies as a grave bug ? I've compiled my own nagios-text package with this suggested fix, and can confirm that it does indeed solve the problems reported. However, I have not tested the nagios-pgsql package. If there is any change of getting this bug fixed before the Sarge release, I'd be willing to test things. I am more interested in Sarge shipping with a workable nagios package than filing a grave bug about this, so this is why I am asking around on this list what could be done ... Thanks in advance for any feedback... While I am at it, I am also running with this /etc/init.d/nagios script extra: --- /home/sneppef/nagios-orig-package/nagios-1.2/debian/init.d 2004-08-30 22:59:45.0 +0200 +++ /etc/init.d/nagios 2004-08-31 02:06:40.0 +0200 @@ -42,10 +42,14 @@ fi else # Try discovering if nagios is alive checking its pid - if kill -CHLD $( cat /var/run/nagios/$NAME.pid ) ; then - return 1# Isn't started + if [ -f /var/run/nagios/$NAME.pid ]; then + if kill -CHLD $( cat /var/run/nagios/$NAME.pid ) ; then + return 1# Isn't started + else + return 0# Is started + fi else - return 0# Is started + return 1# Isn't started fi fi } Regards, Filip
Re: Apology to german users required in the release notes
Frankly, I am getting tired of discussing this issue. I can't understand why you, gotom, are that stubborn and can't respect a decision taken by the German translation team. You already stated at the very beginning of this bug report, that you find it not well inspected [6]... To me your reluctance rather seems like a personal/social quirk. It's a pity :-( I am sorry that I have to say that, I don't intend to offend Well, I must say that even if you're right (you seem), yes you should be sorry for saying that. I've been lucky enough for meeting Masanori Goto at Debconf and I never felt him as a stubborn guy. As I said, I did not intend to offend gotom (though I might have :-(. I am very grateful for everybody spending her/his free time working for Debian and its users (e.g.: me). My statement was not in general but regarding this issue, where imho it is hard to see any reason why there is (still) so much reluctance on applying the patch and why the German translation team has been ignored. Sorry, if I offended gotom or anybody else. Jens
Re: Upgrade report: woody-sarge
On Mittwoch, 1. September 2004 11:33, Branden Robinson wrote: On Sun, Aug 01, 2004 at 03:52:54PM -0400, Joey Hess wrote: It seems that our perl upgrade from woody to sarge is not robust if it dies in the middle. The X problem below caused the first apt run to fail with various parts of perl unpacked and not configured. Then it looks like debconf (which uses Iconv) was unable to run. Probably a dpkg --configure -a would have cleared this up; reinstalling perl manually had the same result. [...] Preparing to replace x-dev 4.3.0.dfsg.1-0.woody.1 (using .../x-dev_4.3.0.dfsg.1-4_all.deb) ... Unpacking replacement x-dev ... dpkg: error processing /var/cache/apt/archives/x-dev_4.3.0.dfsg.1-4_all.deb (--unpack): trying to overwrite `/usr/X11R6/include/X11/DECkeysym.h', which is also in package xlibs-dev dpkg-deb: subprocess paste killed by signal (Broken pipe) Please note that version number. 4.3.0.dfsg.1-0.woody.1 is some sort of unofficial backport. My versioned conflicts/replaces/provides/etc. cannot be expected to take into account the crazy things backporters do. I will support upgrades from woody systems. I don't think it's reasonable to expect any Debian developer to support upgrades from loony hybrid installations using all manner of unofficial packages we've never even shipped. Many thanks for providing this excellent system, aside the upgrade issues I had not a single problem since then I agree for all X related problems. That perl felt down that much was surprising for me. Somebody mentioned that I should have done a 'dpkg --configure -a' and then the problems should have been resolved for me. If that is true, this should be at the top of a troubleshooting section in the installation and (at least at that time not existing) upgrade manual. Thanks, Rainer
Including sed 4.1.2 into sarge
Hi everybody, I am the maintainer for GNU sed. As the Debian package maintainer Clint Adams may have already told this list, I have asked him to push sed 4.1.2 into Sarge. The reason for doing so is that 4.1.1 has a couple of particularly nasty bugs, and I would not be in favor of a Debian release with them; one of them is also spotted by the LSB internationalization tests. Given the long release cycle of Debian, I'd prefer that 4.0.9 were put in sarge rather than 4.1.1, since it has been in use for a while and only has a few well-known POSIX-compliancy problems, of secondary importance. Of course, 4.1.2 (already in sid) would be the best choice. Paolo
Re: Non-US CDs no more for sarge?
On Wed, Sep 01, 2004 at 05:27:46PM +0100, Steve McIntyre wrote: On Mon, Aug 30, 2004 at 10:52:15AM -0700, Steve Langasek wrote: Not any that are in non-US/main in any case, AIUI, which means they probably wouldn't be released as part of a CD set. I believe getting non-US into working order again is still considered a blocker for release, but I think the concern here is non-US/non-free and getting non-US/main operational to the point that *removals* can be processed for sarge. (At least, britney thinks that all of the above-listed non-US/main packages should be removed.) OK. It would make life much easier for CD/DVD production if we can just drop the non-US stuff, and there's clearly very little left there. Shall we just drop it? I tend to think that would be a good idea, yes. -- Colin Watson [EMAIL PROTECTED]
Re: Temporary removal of cyphesis-cpp package from sarge/testing
Andreas Barth [EMAIL PROTECTED] writes: For testing migration, it doesn't matter if a old version of it is in sarge or not. If it is not built on all archs in unstable, it does not go in[1]. So, to achive this goal, the outdated version in unstable needs to be removed. However, removing outdated binaries happens only if the package does not work on that archs any more, and also then only by ftp-masters. The net effect of this is that some packages (two in QA that I'm fretting about) are blocked because the ftp-masters haven't processed the relevant remove requests for the sid archive. I don't know what the correct course of action is here, but it's a shame to have the release delayed on this account. Is it possible for the release managers for sarge to override this problem, and migrate things to sarge even if the ftp-masters haven't cleaned up sid first? Thomas
Re: problem in buildd?
On Mon, Aug 30, 2004 at 11:24:03AM +0100, Mark Brown wrote: On Mon, Aug 30, 2004 at 11:39:46AM +0200, Giuseppe Sacco wrote: I am waiting fot hylafax to migrate into testing. The grep-excuses says that it is not compiled in Alpha, while it has been compiled by buildd 4 days ago. May someone please check it? What's the problem? After packages have been built by the buildd there is an additional manual step where the package must be signed by the buildd admin. Who, in this case, happens to be James Troup... -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
New version of libpqxx for upload
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've packaged the newest stable release of libpqxx, 2.3.0. It's available here: http://people.debian.org/~rleigh/libpqxx-2.3.0/ Currently this does not have any other packages depending upon it in the archive. This is a C++ PostgreSQL client library. Is it OK to upload this before the release of Sarge? It adds a new package to the archive, libpqxx-2.3.0 (upstream don't yet do proper versioning). Many thanks, Roger BTW, I'm not subscribed to debian-release, so I'd appreciate a CC. Thanks! - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFBNkoPVcFcaSW/uEgRAnaeAJ0fapZBkIYPZZ2BfOllhqg2s3XVQQCeM68j Tc9tuCrsaxOaSCNGUGS34sg= =d45s -END PGP SIGNATURE-
FTFBS in sarge
I've done a test build of sarge. About 250 arch any packages failes to build. I attached the lists of packages which failes because of - generic errors, - non-resolvable Build-Depends. The lists are not completely accurate as one buildd built against sid by accident. Also a lot of builds fails because of an uninstallable gcc. The logs of the failed builds will be available after I got some sleep. Bastian -- Where there's no emotion, there's no motive for violence. -- Spock, Dagger of the Mind, stardate 2715.1 abiword_2.0.1+cvs.2003.11.07-2.2 acl2_2.8-4 alsaplayer_0.99.76-0.1 altgcc_1:2.7.2.3-2 am-utils_6.0.9-3 apache_1.3.31-4 aranym_0.8.7beta-2 bayonne_1.2.8-2 bochs_2.1.1-5 camera_0.8-4 cdrtools_4:2.0+a34-1 chan-capi_0.3.4b-1 chrootuid_1.3-3 cuyo_1.8.3-4 debian-installer_20040801 digikamplugins_0.6.2-1 dvgrab_1.5deb-2 e2tools_0.0.16-1 ebview_0.3.5-1 etherboot_5.2.5-2 etoken_0.3.9-2 firedns_0.9.9-1 firestring_0.9.9-1 flite_1.2-release-1 freqtweak_0.6.0-1 gal_0.24-1.3 gccchecker_0.9.9.1.20011205-15 gconf_1.0.9-5.1 gdis_0.81-2 gdm_2.4.4.7-3 geneweb_4.09-25 ggcov_0.2.2-2 giftui_0.4.1-1 gimageview_0.2.25-1 gnomemeeting_0.98.5-8 gnomesword_2.0.0-3 gnometab_0.7.4-3 gnotime_2.2.0-1 goats_2.2-2 gps_1.1.0-1 gpsim_0.20.14-7 gworkspace_0.6.3-4 hspell_0.8-3 hydrogen_0.8.2-1 ibod_1.5.0-3 ifd-gempc_0.9.1-2 imageviewer_0.6.3-0.1 jack-rack_1.4.3-1 kbd_1.06-2 kernel-image-2.4.26-hppa_2.4.26-6 kernel-image-2.4.26-i386_2.4.26-4 kernel-patch-2.4.25-mips_2.4.25-0.040415.1 kernel-patch-2.4.25-powerpc_2.4.25-8 kernel-patch-2.4.27-mips_2.4.27-2.040815 kernel-patch-powerpc-2.4.26_2.4.26-1 kernel-patch-powerpc-2.6.7_2.6.7-5 kernel-patch-powerpc-2.6.8_2.6.8-1 kimagemapeditor_0.9.5.3-1 kino_0.71-2 kissme_1:0.0.31-1 lacheck_1.26-7 lavaps_2.2-1.1 libexif-gtk_0.3.3-4 libg++27_2.7.2.1-19 libgimp-perl_2.0.dfsg-3 libmrproject_0.10-4 libsigsegv_2.1-1 libxml++_1.0.4-1 lids-2.4_1.1.1r2-5 lineak-defaultplugin_0.8beta3-4 longrun_0.9-14 lprng_3.8.27-1 lsb-release_1.4-7.1 lslk_1.29-2 lsof_4.71-1 luxman_0.41-19.1 matrem_1.0-6 mozilla-thunderbird_0.5-4 mozilla_2:1.6-5 mysql-dfsg_4.0.18-5 nagios-plugins_1.3.1.0-4 nana_2.5-8.1 ncbi-tools6_6.1.20040616-1 normalize-audio_0.7.6-4 normalize_0.7.6-3 noteedit_2.5.3-3 nqc_2.5.r3-2 octave2.0_2.0.17-8 openmosix_1:0.3.4-7 panorama_0.13.2-3.1 php4-pecl-ps_1.1.0-2 php4-ps_1.2.2-1 predict_2.2.2-4 pretzel_2.0n-2 pyslide_0.4-1 python-opengl_1.5.7-6 qgo_0.2.1-1 quantlib-python_0.3.6-1 r-cran-mapdata_2.0-11-1 regina-normal_4.0.1-1 remem_2.11-10 replicator_3.1-sarge-1 revelation_0.3.0-1 rivet_0.4.0-1 rosegarden4_0.9.6-2 rtai_3.1-test4-1 rtf2latex_1.0fc2-3 rubrica_1.0.12-2 scm_5d6-3.2 sendmail_8.12.11.Final-5 smarteiffel_1.1-4 speech-dispatcher_0.2-8 sqlrelay_1:0.34.3-2 stardict_2.4.3-3 startalk_0.4-3 straw_0.24-2 syslinux_2.10-1 tagcolledit_0.5-2 teleport_0.32-2 tkrplot_0.0.9.1-1 trang_20030619-2 ttcn3parser_20011019-1 unison_2.9.1-1 wesnoth_0.7.7-1 wings3d_0.98.23b-2.1 wmcoincoin_2.5.0c-1 workrave_1.4.1-1 worlded_0.1.3-4 xball_3.0-5 xpenguins-applet_2.1.0-2 xprobe_0.2rc1-1 zapping_0.6.8-1 zsh-beta_4.2.1-dev-1+20040816-1 zsh_4.2.0-18 alogg_1.3.3-3 fpc_1.9.4-1 gdb_6.1-3 ghc5_5.04.3-6 gnuradio_0.9-1 gpm_1.19.6-12.1 gprolog_1.2.9-3 gst-plugins_0.6.4-5 gtkglextmm_1.0.1-1 java-gnome_0.8.1-1 libbonobomm1.3_1.3.8-2 libcaca_0.9-3 libgtkada2_2.2.1-4 m2crypto_0.13-1 mcvs_1.0.8-4 pyopengl_2.0.0.44-4 qt-x11_3:2.3.2-14 re2c_0.9.1-4 snacc_1.3bbn-5 swfdec_0.2.2-5 util-linux_2.12-3 advi_1.4.0-7 binutils-avr_2.14-1 binutils-m68hc1x_2.14.90.0.7-2 binutils-sparc_2.11.92.0.12.3-4 camera_0.8-2 capi4hylafax_1:01.02.02-1.1 ccs_0.cvs20040703-2 coq_7.3.1-3 cursel_0.2.2-1 djvulibre_3.5.13.pre14-4 fontforge_0.0.20040703-1 fragrouter_1.6-2 gcc-3.0_1:3.0.4ds3-16 gcc-avr_1:3.4.0-1 gcc-m68hc1x_3.2-10 gdb-m68hc1x_6.0-1 ggz-gnome-client_0.0.7-2 ggz-kde-client_0.0.7-2 ggz-kde-games_0.0.7-1 ghfaxviewer_0.22.0-4 gimp1.2_1.2.3-2.4 gnustep-antlr_0.0.20040228-1 gnustep-gd_0.0.20040228-2 gthumb_3:2.3.2-1 gtkam_0.1.2-2 gtkhtml_1.0.4-5.1 hylafax_1:4.1.8-13 intuitively_0.6 kdebase_4:3.2.2-1 kdegraphics_4:3.2.2-1 kdelibs_4:3.2.3-2 kdemultimedia_4:3.2.2-1 kdenetwork_4:3.2.2-1 kernel-kbuild-2.6-2_2.6.5-2 kinoplus_0.3.2-1 libapache-mod-security_1.8.4-1.1 libapache2-mod-encoding_20040616-3.1 libgdiplus_1.0-2 libnids_1.18-2 lightspeed_1.2-4 lilypond_2.1.0-2 lusernet_0.4.1-2 missinglib_0.4.8 mlview_0.6.3-3 mtink_1.0.1-2 multisync_0.82-1 mysql-admin_1.0.9-4 mywiki_0.9-1 nemesis_1.32+1.4beta3-1 ocaml-sqlite_0.3.5.arch.4-2 ocamldsort_0.14.1-2 pfaedit_0.0.20040111-1 php4-interbase_4.3.6-1 pike7.4_7.4.35-1 pike_0.6.131-12 preferences_1.2.100-1 pycaml_0.81-8 python-kinterbasdb_3.0.1-4 python2.1_2.1.3-25 qgis_0.3.0-1 qtstalker_0.26-3 quiteinsane_0.10-5 quiteinsanegimpplugin_0.2-2 renaissance_0.8.0-4 rezound_0.9.0beta-2 roxen_1.3.122-29 showimg_0.9.3-1 stepbill_2.3-1 steptalk_0.8.0-2 talksoup_0.0.20032712-3 tcptraceroute_1.4-5 tetex-bin_2.0.2-15 thy_0.9.3-2 toshutils_2.0.1-5 uclibc_0.9.20-2 viewmol_2.4-4 vrweb_1.5-10 xen_1.2-4.1 xpcd_2.08-10
Re: New version of libpqxx for upload
On Wed, Sep 01, 2004 at 11:15:45PM +0100, Roger Leigh wrote: I've packaged the newest stable release of libpqxx, 2.3.0. It's available here: http://people.debian.org/~rleigh/libpqxx-2.3.0/ Currently this does not have any other packages depending upon it in the archive. This is a C++ PostgreSQL client library. Is it OK to upload this before the release of Sarge? It adds a new package to the archive, libpqxx-2.3.0 (upstream don't yet do proper versioning). It's certainly ok to upload it, but from what I see this library isn't actually used by any packages in Debian. Are there other reasons why this library would be important to include in a stable release, if there's no software depending on it? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: FTFBS in sarge
On Thu, Sep 02, 2004 at 12:39:25AM +0200, Bastian Blank wrote: I've done a test build of sarge. About 250 arch any packages failes to build. The same test for arch all packages would be nice too. We've come across several of those when building the amd64 archive and most should have bugs filed against them, atleast for the version in sid. Kurt
Re: FTFBS in sarge
On Thu, Sep 02, 2004 at 12:39:25AM +0200, Bastian Blank wrote: I attached the lists of packages which failes because of - generic errors, - non-resolvable Build-Depends. Please, could you group this by maintainer? /* Steinar */ -- Homepage: http://www.sesse.net/
Re: New version of libpqxx for upload
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Langasek [EMAIL PROTECTED] writes: It's certainly ok to upload it, but from what I see this library isn't actually used by any packages in Debian. Are there other reasons why this library would be important to include in a stable release, if there's no software depending on it? I'm aware of several people using it for their own software, but none of this is yet available or packaged, as far as I'm aware. I think they would appreciate having it in stable. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFBNlRJVcFcaSW/uEgRApiDAKCTWaKDZ5VEjLf40Pn4zJJ2p96mDwCfbTnw DPjo7McZy56wmh42qMA+ZGQ= =u3lZ -END PGP SIGNATURE-
Re: FTFBS in sarge
Hi Bastian, On Thu, Sep 02, 2004 at 12:39:25AM +0200, Bastian Blank wrote: I've done a test build of sarge. About 250 arch any packages failes to build. I attached the lists of packages which failes because of - generic errors, - non-resolvable Build-Depends. The lists are not completely accurate as one buildd built against sid by accident. Also a lot of builds fails because of an uninstallable gcc. The logs of the failed builds will be available after I got some sleep. How long of a period does the archive rebuild cover? I recognize a number of these packages as being fixed by tiff-related updates. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: another failed removal hint
On Wed, Sep 01, 2004 at 01:40:57AM +0200, Adeodato Simó wrote: this hint from vorlon seems to not have worked (Bug#260508): # 20040826; done 20040828 # RoM remove sympa/3.4.4.3-6 Re-queued. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
