Re: binnmus for #477751
Dear release team, On Mon, May 28, 2012 at 10:34:08PM +0200, Helmut Grohne wrote: The following set of packages can be updated using binNMUs: festival jade linuxdoc-tools metacity-common:metacity mutter openjade openjade1.3 Please hold on. The rebuilt packages are currently causing FTBFS for other packages. See #675613 for details. TL;DR: The triggers are executed too early. Guillem Jover intends to solve this in dpkg. Helmut -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120603080656.ga...@alf.mars
RM: clojure1.3/testing -- ROM; obsolete; newer version in the archive
I have uploaded the Clojure1.4 package, which obsoletes the previous version Clojure1.3. Could you remove Clojure1.3 from testing and unstable? Regards, Daigo -- Daigo Moriwaki daigo at debian dot org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAH79Gv9rvnj9c=fss_ffymjufre3+z1cje2ty0w3j11pm0a...@mail.gmail.com
Bug#672142: transition: allegro4.4
allegro4.4 is now in unstable, installed for all architectures except ia64 and mips. ia64 failed with an internal compiler error and mips is building for 12 hours now. Am I supposed to file RM requests now or does the Release Team take care of that? I prepared a NMU for open-invaders that should be uploaded later instead of a binNMU: http://mentors.debian.net/debian/pool/main/o/open-invaders/open-invaders_0.3-3.2.dsc Best regards, Tobias signature.asc Description: OpenPGP digital signature
Re: exim4 and the mysqlclient transition
Cyril Brulebois k...@debian.org wrote: Andreas Metzler ametz...@downhill.at.eu.org (02/06/2012): [...] version. Is this correct or should I refrain from uploading exim 4.80 to unstable? It's probably OK to upload. I'll deal with consequences if there's anything going wrong. Please upload, and thanks for checking with us. Thank you very much. I have just uploaded. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/3fbs99-ndt@argenau.downhill.at.eu.org
Re: Transition of rpm package
libextractor3 is missing from the list of rdpends. I've stumbled upon this as well. vdr-plugin-xineliboutput doesn't build anymore because it depends on libextractor3 which depends in librpm2 which depends on rpm-common (= 4.9.1.3-2) which isn't available after the upload of the new rpm anymore. Tobias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fcb9170.7050...@e-tobi.net
Re: Request removal for gnunet-fuse
Hello, Thank you Holger for cc:ing me. Le 02/06/2012 23:21, Holger Levsen a écrit : cc:ing the gnunet maintainer as he told me he was thinking of adoptiong these packages... (he's also aware of the upstream situation..) I can confirm I am also interested in adopting gnunet-*. On Samstag, 2. Juni 2012, Artur Rona wrote: I'm requesting removal for package gnunet-fuse. It's orphaned, outdated and doesn't work anymore with gnunet 0.9.2. Also, there is a FTBFS bug (http://bugs.debian.org/674342). It doesn't make sense to keep it in testing. I've got in touch with upstream. They are going to re-work gnunet-fuse, but no at this moment. The next question is, whether we want to keep it in unstable as well? I didn't file an ITA for gnunet-fuse (or gnunet-qt) yet, since they are both outdated and I cannot do anything about it. But IMHO they should not be testing. As soon as upstream will release a version compatible with GNUnet 0.9.2 I'll adopt these and update the version in unstable. It will probably be after the freeze though. Cheers, Bertrand PS please CC me (or gnu...@packages.debian.org) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fcb9ac6.7080...@gmail.com
Processed: blocker
Processing commands for cont...@bugs.debian.org: block 671115 by 675836 Bug #671115 [release.debian.org] transition: mysql-5.5 671115 was blocked by: 674328 673528 667428 673263 650058 660686 674122 649955 651110 674309 672714 650060 666331 672619 672950 672716 673264 651317 674210 673262 640818 672765 661422 673260 673183 673161 649638 668232 673153 672824 672621 672816 672207 672588 671115 was blocking: 672928 Added blocking bug(s) of 671115: 675836 End of message, stopping processing here. Please contact me if you need assistance. -- 671115: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671115 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13387590979786.transcr...@bugs.debian.org
Re: RM: clojure1.3/testing -- ROM; obsolete; newer version in the archive
Hello, Daigo Moriwaki da...@debian.org (03/06/2012): I have uploaded the Clojure1.4 package, which obsoletes the previous version Clojure1.3. Could you remove Clojure1.3 from testing and unstable? get it removed from unstable, that'll propagate to testing: http://wiki.debian.org/ftpmaster_Removals Mraw, KiBi. signature.asc Description: Digital signature
Bug#675740: marked as done (unblock: ffgtk/None)
Your message dated Sun, 3 Jun 2012 23:34:42 +0200 with message-id 20120603213442.ga8...@mraw.org and subject line Re: Bug#675740: unblock: ffgtk/None has caused the Debian Bug report #675740, regarding unblock: ffgtk/None to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 675740: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675740 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package ffgtk I've been trying for a while to find a sponsor for ffgtk. The mentor who said they would do it informed me yesterday that it likely won't happen in time for the freeze. D'uh. Please grant a freeze exception or better yet, sponsor it ;-) http://bugs.debian.org/602723 (ITP) http://mentors.debian.net/debian/pool/main/f/ffgtk/ffgtk_0.8.1-1.dsc http://qa.debian.org/developer.php?login=f...@rolf.leggewie.biz unblock ffgtk/None ---End Message--- ---BeginMessage--- Hello, Rolf Leggewie debian-b...@rolf.leggewie.biz (03/06/2012): Please unblock package ffgtk I've been trying for a while to find a sponsor for ffgtk. The mentor who said they would do it informed me yesterday that it likely won't happen in time for the freeze. D'uh. try debian-ment...@lists.debian.org? Please grant a freeze exception or better yet, sponsor it ;-) http://bugs.debian.org/602723 (ITP) http://mentors.debian.net/debian/pool/main/f/ffgtk/ffgtk_0.8.1-1.dsc http://qa.debian.org/developer.php?login=f...@rolf.leggewie.biz unblock ffgtk/None This makes little sense. There's nothing blocked yet, we don't unblock packages without reviewing them (or trying to anyway), so I'll just close this bug report. Mraw, KiBi. signature.asc Description: Digital signature ---End Message---
Bug#653903: qt4-x11 multiarch NMUs
Hi, Pino Toscano p...@debian.org (02/06/2012): A fixed qt4-x11 has been uploaded few hours ago and compiled fine on s390x; thanks. FTBFS on ia64 though, which I'll file right away. a few KDE sources among the failing ones have been given back (building fine) already, the only missing bits I can see are - kde-runtime (so we end the exiv2 transition for real) - kmymoney - kraft so could you (r-t or CCed s390x buildd admins) please binNMU kde-runtime for the exiv2 transition and give the other two back? just binNMUd kde-runtime; last two are Installed for 21 hours at the time of this writing. Cyril, I remember you did a couple of days ago a list of the s390 - s390x differences; after updating it and considering the packages above, which other Qt/KDE sources are left? Sure; please ping back tomorrow (noonish), and I'll have a look. Mraw, KiBi. signature.asc Description: Digital signature
Bug#673488: marked as done (transition: ctemplate libctemplate0 - libctemplate2)
Your message dated Mon, 4 Jun 2012 00:02:04 +0200 with message-id 20120603220204.gd8...@mraw.org and subject line Re: Bug#673488: transition: ctemplate libctemplate0 - libctemplate2 has caused the Debian Bug report #673488, regarding transition: ctemplate libctemplate0 - libctemplate2 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 673488: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673488 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition debian-release, ctemplate has some RC bugs regarding gcc-4.7, the new upstream release, bumps the soname and fixes gcc-4.7 build. It has been uploaded to experimental: ctemplate (2.2-1) experimental; urgency=low * New upstream release - Fixes ftbfs with GCC-4.7 (Closes: #667145) - Fixes New Upsstream, Watch File (Closes: #658404) - Fix g++-4.7 -std=c++0x issue (Closes: #665360) * --program-prefix=ctemplate- * NEW package libctemplate2 - match-soname -- Mark Purcell m...@debian.org Sat, 19 May 2012 07:55:00 +1000 Affected packages: libctemplate0 Reverse Depends: l2tp-ipsec-vpnunrelated FTBFS #672005 mysql-workbench binNMU OK kraft unrelated FTBFS multiarch -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ---End Message--- ---BeginMessage--- Cyril Brulebois k...@debian.org (30/05/2012): kraft/s390x is FTBFSing, due to qt's multiarchification. A fixed qt should appear soon, so once it's uploaded, and binNMUs for some reverse dependencies are ready too, we should be able to perform a give back. That should get us rid of the old binary left in testing: | libctemplate0: s390x That has happened, closing accordingly. Mraw, KiBi. signature.asc Description: Digital signature ---End Message---
Bug#666126: transition: poppler 0.18
Hello Pino, Pino Toscano p...@debian.org (02/06/2012): Thanks, I've uploaded poppler 0.18.4 to unstable yesterday, and it compiled fine everywhere. thanks. I've pinged this morning Chow Loong Jin, and later he kindly uploaded the arch:all poppler-sharp. ACK. I guess you could also exclude gambas3 and luatex for few days (to let the, migrate to testing first), and calligra (will get an upload of a new upstream release soon, and would be a waste to rebuild). Did that on all archictectures: kibi@grieg:~$ wb nmu apvlv calibre cups-filters epdfview gdcm gimp gle-graphics gnome-commander gpdftext gummi inkscape libextractor pdf-presenter-console pdf2djvu pdf2svg pdfcube pdftoipe python-poppler referencer tracker tumbler webkit2pdf xournal xpdf zathura . ALL . -m 'Rebuild for the poppler transition.' Arch-specific: kibi@grieg:~$ wb nmu texlive-bin . ALL -sparc . -m 'Rebuild for the poppler transition.' wb nmu popplerkit.framework . ALL -amd64 -ia64 . -m 'Rebuild for the poppler transition.' Others: - didn't do gambas3 for now, - calligra, luatex are in level 2 anyway. (the former has been uploaded now, too) Hopefully I didn't forget too much… Mraw, KiBi. signature.asc Description: Digital signature
Bug#675886: pu: package eglibc/2.11.3-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu
Hi,
We would like to fix some bugs in the stable eglibc version.
One bug was supposed to be fixed in the previous upload, but it was
not due to the patch not being added to patches/series. It seems this
bug is quite important to be fixed given the number of bug report or
mails we get about it.
The remaining two other bugs are security issues that the security team
asked to be fixed in stable.
Please see the corresponding debdiff below.
Aurelien
diff -u eglibc-2.11.3/debian/changelog eglibc-2.11.3/debian/changelog
--- eglibc-2.11.3/debian/changelog
+++ eglibc-2.11.3/debian/changelog
@@ -1,3 +1,15 @@
+eglibc (2.11.3-4) stable; urgency=low
+
+ * Enable patches/any/cvs-dlopen-tls.diff, not enabled by mistake. Closes:
+#637239.
+ * patches/any/cvs-FORTIFY_SOURCE-format-strings.diff: new patch from
+upstream to fix FORTIFY_SOURCE format string protection bypass. Closes:
+#660611.
+ * patches/any/local-sunrpc-dos.diff: fix a DoS in RPC implementation
+(CVE-2011-4609). Closes: #671478.
+
+ -- Aurelien Jarno aure...@debian.org Sun, 03 Jun 2012 22:42:42 +0200
+
eglibc (2.11.3-3) stable; urgency=low
* patches/any/cvs-tzfile.diff: fix integer overflow in timezone code.
diff -u eglibc-2.11.3/debian/patches/series eglibc-2.11.3/debian/patches/series
--- eglibc-2.11.3/debian/patches/series
+++ eglibc-2.11.3/debian/patches/series
@@ -274,0 +275,3 @@
+any/cvs-dlopen-tls.diff
+any/cvs-FORTIFY_SOURCE-format-strings.diff
+any/local-sunrpc-dos.diff
only in patch2:
unchanged:
--- eglibc-2.11.3.orig/debian/patches/any/cvs-FORTIFY_SOURCE-format-strings.diff
+++ eglibc-2.11.3/debian/patches/any/cvs-FORTIFY_SOURCE-format-strings.diff
@@ -0,0 +1,86 @@
+2012-03-02 Kees Cook keesc...@chromium.org
+
+[BZ #13656]
+* stdio-common/vfprintf.c (vfprintf): Check for nargs overflow and
+possibly allocate from heap instead of stack.
+
+--- a/stdio-common/vfprintf.c
b/stdio-common/vfprintf.c
+@@ -235,6 +235,9 @@ vfprintf (FILE *s, const CHAR_T *format, va_list ap)
+ 0 if unknown. */
+ int readonly_format = 0;
+
++ /* For the argument descriptions, which may be allocated on the heap. */
++ void *args_malloced = NULL;
++
+ /* This table maps a character into a number representing a
+ class. In each step there is a destination label for each
+ class. */
+@@ -1647,9 +1650,10 @@ do_positional:
+determine the size of the array needed to store the argument
+attributes. */
+ size_t nargs = 0;
+-int *args_type;
+-union printf_arg *args_value = NULL;
++size_t bytes_per_arg;
++union printf_arg *args_value;
+ int *args_size;
++int *args_type;
+
+ /* Positional parameters refer to arguments directly. This could
+also determine the maximum number of arguments. Track the
+@@ -1698,13 +1702,38 @@ do_positional:
+
+ /* Determine the number of arguments the format string consumes. */
+ nargs = MAX (nargs, max_ref_arg);
++/* Calculate total size needed to represent a single argument across
++ all three argument-related arrays. */
++bytes_per_arg = sizeof (*args_value) + sizeof (*args_size)
+++ sizeof (*args_type);
++
++/* Check for potential integer overflow. */
++if (__builtin_expect (nargs SIZE_MAX / bytes_per_arg, 0))
++ {
++ __set_errno (ERANGE);
++ done = -1;
++ goto all_done;
++ }
+
+-/* Allocate memory for the argument descriptions. */
+-args_type = alloca (nargs * sizeof (int));
++/* Allocate memory for all three argument arrays. */
++if (__libc_use_alloca (nargs * bytes_per_arg))
++args_value = alloca (nargs * bytes_per_arg);
++else
++ {
++args_value = args_malloced = malloc (nargs * bytes_per_arg);
++if (args_value == NULL)
++ {
++done = -1;
++goto all_done;
++ }
++ }
++
++/* Set up the remaining two arrays to each point past the end of the
++ prior array, since space for all three has been allocated now. */
++args_size = args_value[nargs].pa_int;
++args_type = args_size[nargs];
+ memset (args_type, s-_flags2 _IO_FLAGS2_FORTIFY ? '\xff' : '\0',
+- nargs * sizeof (int));
+-args_value = alloca (nargs * sizeof (union printf_arg));
+-args_size = alloca (nargs * sizeof (int));
++ nargs * sizeof (*args_type));
+
+ /* XXX Could do sanity check here: If any element in ARGS_TYPE is
+still zero after this loop, format is invalid. For now we
+@@ -1973,8 +2002,8 @@ do_positional:
+ }
+
+ all_done:
+- if (__builtin_expect (workstart != NULL, 0))
+-free (workstart);
++ free (args_malloced);
++ free (workstart);
+ /* Unlock the stream. */
+ _IO_funlockfile (s);
+ _IO_cleanup_region_end (0);
only in patch2:
unchanged:
---
Bug#672142: transition: allegro4.4
Hello Tobias, Tobias Hansen tobias@gmx.de (03/06/2012): allegro4.4 is now in unstable, installed for all architectures except ia64 and mips. ia64 failed with an internal compiler error and mips is building for 12 hours now. now installed on mips. Previously I tried a give back on ia64, just in case it was bad luck, but that didn't help. Am I supposed to file RM requests now or does the Release Team take care of that? Hmm, what do you want to see RM'd? Mraw, KiBi. signature.asc Description: Digital signature
Bug#664681: transition: KDE's 4.8 release of platform, applications and workspace
Hello, Modestas Vainius mo...@debian.org (02/06/2012): With qt4-x11 multiarch done [1] and KDE Plasma Workspaces ready in experimental [2], when could we expect a transition slot? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653903 [ bug not closed though ] [2] http://pkg-kde.alioth.debian.org/redir/kde-sc-buildd-experimental?compact=1 I just replied to [1], should be done quite soon; do we need to set up a tracker for [2], or will you just be able to monitor everything on your end? I /think/ you should be able to go ahead right now. A ben file would help us spot what could be entangled with other ongoing transitions. Mraw, KiBi. signature.asc Description: Digital signature
Bug#672142: transition: allegro4.4
Hi, Am 04.06.2012 00:26, schrieb Cyril Brulebois: Am I supposed to file RM requests now or does the Release Team take care of that? Hmm, what do you want to see RM'd? I thought removing allegro4.2 would be the next step. But now that you say it, that's not necessary, because liballegro4.2-dev was replaced, right? Also alogg and allegro-demo-data, but they're also no obstacle for the transition, except that alogg will FTBFS with allegro4.4. Best regards, Tobias signature.asc Description: OpenPGP digital signature
Uncoordinated rpm transition
Hi Michal, here's an extract of Artur's mail, telling us about the uncoordinated rpm transition you started: Artur Rona ari-tc...@tlen.pl (02/06/2012): I've noticed that new revision of rpm source package has been uploaded this week and introduced new binary packages names. However, maintainer of rpm didn't let us know about that fact. The list of changed SONAME: librpm2 - librpm3 librpmio2 - librpmio3 librpmbuild2 - librpmbuild3 librpmsign0 - librpmsign1 Mehdi has set a tracker for those: http://release.debian.org/transitions/html/rpm.html This is very unfortunate to have (yet another) uncoordinated transition, *this late* in the release cycle… Especially since there was a libextractor transition, which (thankfully) just finished, but that was a really near miss… and since that package is also involved in the poppler transition… Next time, please coordinate with us, we have been trying to get the message across during the past few years through messages to dda@, and we have documentation on the process: https://wiki.debian.org/Teams/ReleaseTeam/Transitions Mraw, KiBi. signature.asc Description: Digital signature
Bug#675890: transition: owfs
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to upload the new release of owfs. As always for this software, upstream does not really take care of symbols (some are removed) but they always bump the soname, so there should not be any problems with other programs. owfs provides three library packages, currently libow-2.8-14 libowcapi-2.8-14 libownet-2.8-14 and next will be -15. Note that all reverse-dependencies are package built from owfs itself (same source package) so the upload of this new upstream version should not change anything for the rest of the Debian archive. Is it ok for me to upload the new release? (and do I need to fill such a bug when all reverse dependencies are in the same source package?) Regards, Vincent -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.3.0-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120603230236.27994.430.report...@eyak.imag.fr
Bug#672142: transition: allegro4.4
Tobias Hansen tobias@gmx.de (04/06/2012): I thought removing allegro4.2 would be the next step. But now that you say it, that's not necessary, because liballegro4.2-dev was replaced, right? Also alogg and allegro-demo-data, but they're also no obstacle for the transition, except that alogg will FTBFS with allegro4.4. Since that's a new source package, there are no “out-of-date” binaries, which is the usual case (source packages dropping binaries, meaning they need to be removed from unstable once packages are binNMUd to link against new packages). That can be checked on the excuses page: http://release.debian.org/britney/update_excuses.html#allegro4.4 As for alogg/allegro-demo-data, we'll see what to do with those when allego4.4 becomes a candidate for migration. Right now, I'm a little worried about the ia64 FTBFS. allegro4.2 was building fine there, so we're likely to have packages that won't be buildable any more. That should be solvable by getting those packages removed on ia64 only, until the ICE (Internal Compiler Error) is fixed; but we'll have to check what happens with reverse dependencies… There might be better ways, though. (Trying to reproduce the ICE and filing a bug report in both the debian/upstream bug tracker would be nice in any case.) Mraw, KiBi. signature.asc Description: Digital signature
Bug#675890: transition: owfs
tag 675890 pending thanks Hi, Vincent Danjean vdanj...@debian.org (04/06/2012): Note that all reverse-dependencies are package built from owfs itself (same source package) so the upload of this new upstream version should not change anything for the rest of the Debian archive. thanks for checking with us. Please go ahead with your upload. (and do I need to fill such a bug when all reverse dependencies are in the same source package?) As long as your package doesn't get caught in another “real” transition, that's fine. If it does, that might delay other transitions, which isn't a good idea when we're trying to get them all done. In other words, it's appreciated, though not mandatory. Your transition might happen a little quicker this way since we usually keep a close eye on the excuses page, and since we usually request packages to be decrufted a bit before the ftpmasters' semi-removal happens. (So your package isn't blocked from migrating due to the out-of-date binaries.) Mraw, KiBi. signature.asc Description: Digital signature
Processed: Re: Bug#675890: transition: owfs
Processing commands for cont...@bugs.debian.org: tag 675890 pending Bug #675890 [release.debian.org] transition: owfs Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 675890: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675890 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13387653855260.transcr...@bugs.debian.org
Re: Bug#674587: transition: mapnik
David Paleino da...@debian.org (01/06/2012): However, I'd still like the transition to be put in the tracker, in the planned section. There, milord: http://release.debian.org/transitions/html/mapnik.html Mraw, KiBi. signature.asc Description: Digital signature
Re: binnmus for #477751
Hi Helmut, and thanks for your work on this. Helmut Grohne hel...@subdivi.de (29/05/2012): title = sgml-base #477751; is_affected = .depends ~ /sgml-base \(/; FWIW: using /sgml-base/ is OK. is_bad = .depends ~ /sgml-base \(= 1\.1[0-9]\)/; is_good = .depends ~ /sgml-base \(= 1\.26\+nmu2\)/; Tracker is at: http://release.debian.org/transitions/html/sgml-base.html linuxdoc-tools is good everywhere but i386 (maintainer upload), so the bad/good combination looks about right. Holding off with binNMUs per: https://lists.debian.org/debian-release/2012/06/msg00046.html Mraw, KiBi. signature.asc Description: Digital signature
Bug#672142: transition: allegro4.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 04.06.2012 01:05, schrieb Cyril Brulebois: Tobias Hansen tobias@gmx.de (04/06/2012): I thought removing allegro4.2 would be the next step. But now that you say it, that's not necessary, because liballegro4.2-dev was replaced, right? Also alogg and allegro-demo-data, but they're also no obstacle for the transition, except that alogg will FTBFS with allegro4.4. Since that's a new source package, there are no âout-of-dateâ binaries, which is the usual case (source packages dropping binaries, meaning they need to be removed from unstable once packages are binNMUd to link against new packages). That can be checked on the excuses page: http://release.debian.org/britney/update_excuses.html#allegro4.4 As for alogg/allegro-demo-data, we'll see what to do with those when allego4.4 becomes a candidate for migration. Right now, I'm a little worried about the ia64 FTBFS. allegro4.2 was building fine there, so we're likely to have packages that won't be buildable any more. That should be solvable by getting those packages removed on ia64 only, until the ICE (Internal Compiler Error) is fixed; but we'll have to check what happens with reverse dependencies⦠There might be better ways, though. (Trying to reproduce the ICE and filing a bug report in both the debian/upstream bug tracker would be nice in any case.) Mraw, KiBi. I have just requested access to an ia64 porterbox. Best regards, Tobias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJPy/kNAAoJEIyCFp2Ozs0q/2EP/0MevAWdkLXKgdXy+lN9dIl/ LqWSIov1X9LYEHbxZkG1cp/hQrs7RO0gLkwUaozGAcJ48U09+PSGQJQGCtvwQqDM zB1irksZpYMMLreqWvwLyCcgYoHdpWw3LR7uEaUR5zWAH21qRHICsL82KPTTNEbA 70BhZ5kLiTyxHlH2UuYEbqYjLxW7dKO0Z0BOYISuMt4YdV9oMprcYfzFYjKUjBhs UanQajiqbcmKlLU8Fvd+oLTEvVfiIMTB/uWBWvnqK5+kkiXntjxfLIzRSQlf9mxs o6D/QT+d86QWddmI/rYTafqyHw/6lXPR29L2tAo8F9DPFGfMpUk0aYIkMf1j1jXk wHqzpb+G+iADze/MYI1h6DWjTlJG95HjFEcDbGVY7LXeG/DrHg/Fw5TkeuGUebx0 LQFW6Drl1nkOVWoj8GsJgUe4737xqC7AEMf2lsyYpNxOb305tSYAKbRhYI9UAH/1 ZWjkmQip7xKaQVW7QOvoMr7fkugMi1G37E3lHkZooFjal1NeDC+xOXd68HhE2giH rLmeKnYV0Qm0+TMtP1kCokCdWEpV61tEnnhdFkynX5vnudfU9kOhtQRrOUPxMXcE lX+yAi7HQWesc5/LQH8e10Yy8iul4kQBxz0KAelG1XtqMT9XMvwia+UAQZLKqdtZ cJr9J1WaxNw7+fPts3kd =SknU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fcbf90d.3030...@gmx.de
Re: Please binNMU python-ufc against latest swig
(Adding the bug report to the loop.) Hello, Johannes Ring joha...@simula.no (31/05/2012): python-ufc needs to be rebuilt against the latest swig (2.0.7). Please binNMU it. nmu python-ufc_2.0.5-2 . ALL . -m 'Rebuild against swig 2.0.7, see #675207.' if this package has such strict dependencies on swig, why aren't they exposed through strict package dependencies? Mraw, KiBi. signature.asc Description: Digital signature
Re: Wheezy Freeze
Hello Brian and others, brian.thoma...@gmail.com brian.thoma...@gmail.com (31/05/2012): I'm hoping to get your blessing, or seal of approval, or at least an ah, go ahead! to upload Eucalyptus to Sid in mid-June. the safest course of actions is to get packages uploaded before mid-June (possibly in good shape, since release critical bugs would prevent migration to testing, so don't rush them either ;)), even if those are not in their final shape. Letting small updates flow into testing during the freeze is something that can be considered. Looking at huge chunks isn't. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bits from the Release Team: Freeze approaching!
This is resent from something I sent to Cyril Brulebois. He told me to send it to the main release team list: Do as you can, I guess that dealing with such a problem might be within the scope of a freeze. Next time, please contact debian-release@ directly so that the discussion can be public from the beginning. (Feel free to quote the public part of this mail there if you wish.) Mraw, KiBi. Hi, I probably should have contacted you about this earlier, and I'm sorry that I didn't. I'm currently working on renaming openclipart to openclipart2, because the newest openclipart package takes about 1 GB of space. After the rename, users can choose a small or large version of openclipart. I think it's important that we don't release wheezy with such a huge package. There is a good chance that I will be able to finish this on time, but I wanted to mention this to the release team so that, in case I am not able to, I can get a few days extension. That way, if I do need extra time, you all will know now rather than later. Thanks, Martin Kelly -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fcc0d03.4060...@gmail.com
Re: Bug#675207: Please binNMU python-ufc against latest swig
On Mon, Jun 4, 2012 at 2:05 AM, Cyril Brulebois k...@debian.org wrote: (Adding the bug report to the loop.) Hello, Johannes Ring joha...@simula.no (31/05/2012): python-ufc needs to be rebuilt against the latest swig (2.0.7). Please binNMU it. nmu python-ufc_2.0.5-2 . ALL . -m 'Rebuild against swig 2.0.7, see #675207.' if this package has such strict dependencies on swig, why aren't they exposed through strict package dependencies? If I may, I believe this is due to: http://bugs.debian.org/674263 Any binary build with swig 2.0.5 or 2.0.6 should be rebuild IMHO. -- Mathieu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ca+7wusxx8q2rfldyen9zpwtwnai0ynguu0zxdhdqffe13tv...@mail.gmail.com
