Re: Current and upcoming toolchain changes for jessie
On Wed, 2013-05-08 at 01:39 +0200, Matthias Klose wrote: [...] > - I didn't upload linux-libc-dev myself, but until today I didn't >see any announcement or a test rebuild done by the Debian kernel >maintainers, so I did add the note about what I did see in multiple >packages when doing a test rebuild in Ubuntu. > >And I think it's a normal change, and build failures can be reported >after a test rebuild. You may want to contact the kernel team, if >you think otherwise. [...] I must admit that it hadn't occurred to me to check this in advance. Sorry about that. If there are particular changes that cause a lot of breakage, they could be reverted temporarily. Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: This is a digitally signed message part
Re: re-thinking architecture qualification for jessie
Am 08.05.2013 02:31, schrieb Matthias Klose: > gabrielli as the porter box is now up again, but I don't see any real support > for mips, mipsel, s390, sparc, and maybe powerpc within Debian. Please > consider > toolchain maintenance when starting the architecture qualification for jessie. forgot to mention ia64 on this list. -- 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/5189ab49.5000...@debian.org
Re: Current and upcoming toolchain changes for jessie
On Tue, May 07, 2013 at 06:35:16PM -0600, Adam Conrad wrote: > On Wed, May 08, 2013 at 01:59:38AM +0200, Aurelien Jarno wrote: > > > > They weren't coordinated within the team. Furthermore I don't consider > > that eglibc was ready to go to unstable, as it was known that two > > architectures were going to FTBFS, without a real try to get that fixed > > (for example by contacting the porters). > > I'll absolutely take blame for not trying harder to contact more porters > than just you on IRC. On the flip side, I don't think I'm entirely off > my rocker in thinking that maybe porters with direct commit access to the > packaging might have cared that eglibc has been FTBFS in experimental for > four and a half months. This isn't new. And, as we've discovered today, This isn't something new, but people tends to be busy and have to set priorities. I personally didn't know that the deadline was two days after the release, and I think it was the same for other people who could have fix that. I still don't understand why this sudden rush. > most of the fixes required were really quite trivial (though we're not > quite done yet). True, but the build still fails early. And the testsuite hasn't run yet. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20130508005215.gk4...@ohm.aurel32.net
Re: Current and upcoming toolchain changes for jessie
On Wed, May 08, 2013 at 01:59:38AM +0200, Aurelien Jarno wrote: > > They weren't coordinated within the team. Furthermore I don't consider > that eglibc was ready to go to unstable, as it was known that two > architectures were going to FTBFS, without a real try to get that fixed > (for example by contacting the porters). I'll absolutely take blame for not trying harder to contact more porters than just you on IRC. On the flip side, I don't think I'm entirely off my rocker in thinking that maybe porters with direct commit access to the packaging might have cared that eglibc has been FTBFS in experimental for four and a half months. This isn't new. And, as we've discovered today, most of the fixes required were really quite trivial (though we're not quite done yet). Anyhow. Arguments are cheap and, generally, pointless. Hopefully Petr has some clever ideas to get us past the last kfreebsd/glibc snag, and I'll have another stab at it tomorrow if this flu subsides and lets me think straight. As I said before, I'm sorry for not coordinating this better outside of Matthias and I. It'll happen differently next time. I can't go back in time and make this time different, so discussing it ad nauseum does no one any good. ... Adam -- 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/20130508003516.gg29...@0c3.net
re-thinking architecture qualification for jessie
I'm not happy how the architecture qualification for wheezy did go (as
communicated in the session about the status of the release at DebConf 2012). I
did criticize the attitude of the release team as overly optimistic ("green
light attitude"), and I do see that at least GCC and binutils don't have any
support from some ports in Debian. I would like to see this qualification to
happen earlier in the jessie release cycle, and to be more honest, maybe in that
members of the release team which are port maintainers as well, are not involved
with the release qualification for that port. For wheezy, there are some green
crosses in the architecture qualification matrix which from my point of view are
not correct.
- At the time when the mips porter box was marked as available, it
was not available, and then again, during the freeze, it was about
five months down, without anything happening (yes, contacted debian-admin).
- The number of porters was marked as green for every architecture, but
when asking for help in GCC and binutils I never got this help. From
my point of view this includes addressing architecture specific issues
in the toolchain. Some people for ports do have access to the GCC
packaging, and do use it. Other port specific issues are addressed by
patches, and afaics no issues are outstanding. I do consider this
involvement as sufficient for non-release architectures like alpha,
hppa, m68k, x32, sh4, powerpcspe.
It's easy to remove java support for some architectures, but as long
as you don't have a replacement for the toolchain, it's difficult to
maintain such a port (haven't seen clang supported on these archs yet).
- Release critical issues are almost only searched on x86, and I assume
that some of these are ignored for other architectures if not found on
x86. A full archive rebuild for every release architecture doesn't
seem feasible, however defining a subset of packages which have to
be buildable on every architecture seems like a doable idea, at least
for some architectures. There seems to be fast enough hardware available
at least for s390x, ppc64, powerpc, and the arm architectures could
compensate with the numbers of build machines for such a test rebuilds.
gabrielli as the porter box is now up again, but I don't see any real support
for mips, mipsel, s390, sparc, and maybe powerpc within Debian. Please consider
toolchain maintenance when starting the architecture qualification for jessie.
As Roger Leigh noted, non-recent toolchain versions may cause extra work for
Debian maintainers.
Matthias
--
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/51899cee.1050...@debian.org
Re: Hurd and the archive
Steven Chamberlain, le Wed 08 May 2013 00:59:19 +0100, a écrit : > > Neil McGovern, le Tue 07 May 2013 11:14:01 +0100, a écrit : > >> a) A HP DL360 or similar > > The chipset has changed a bit between generations: > > G1: eepro (Linux) or fxp (*BSD) driver, requiring non-free microcode We haven't worked on microcode upload, since we don't necessarily target non-freeness... > G2: HP NC7780 aka BCM5701, tg3 driver (Linux) or bge (*BSD) tg3 should work then. > G3: HP NC7781, same? > G4: HP NC7782, same? > > G5: bce/bnx (*BSD) or bnx2 (Linux) driver, bnx2 is supported. > needs non-free blob? ditto. > >> c) A Lenovo Thinkpad X220 or similar > > I've seen e1000e mentioned, supported in wheezy by Linux 3.2.x, but not > by the version of the Intel drivers in squeeze: > 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network > Connection (rev 04) Ok. Could be a matter of upgrading the driver. Samuel -- 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/20130508002120.gi6...@type.wlan.youpi.perso.aquilenet.fr
Re: Current and upcoming toolchain changes for jessie
Hi, On 07/05/13 14:25, Matthias Klose wrote: > == (e)glibc 2.17 == > > We had hoped that leaving > it FTBFS in experimental for several months and gently pinging [...] That was a bit unexpected, and I haven't seen it brought up on debian-bsd@ until now. > == GCC 4.8 == > > It is planned to only keep GCC 4.8 and the upcoming GCC 4.9, and to > remove 4.4, 4.6 and 4.7 from jessie. At least this part was expected. If kfreebsd (kernels) are unable to build with these, we may be able to use clang-3.2 for that. In other packages we may see some GCC 4.8 issues in kfreebsd-specific bits of code, not noticed by rebuilds on linux, but should be easy to deal with. Regards, -- Steven Chamberlain ste...@pyro.eu.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/51899a7a.2060...@pyro.eu.org
Re: Hurd and the archive
Steven Chamberlain, le Wed 08 May 2013 00:59:19 +0100, a écrit : > >> d) VMWare/VBox etc. > > > > This already works. > > > > Also, Xen support just works [...] > > With network connectivity? Sure. > If so which NIC do they emulate? (rtl8139?) They don't emulate a nic, it's ParaVirtualization. > What kind of storage bus is used? ParaVirtualized, too. Samuel -- 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/20130508001618.gh6...@type.wlan.youpi.perso.aquilenet.fr
Bug#707182: RM: pidgin-facebookchat/1.69-2.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove pidgin-facebookchat from the Debian archives. It has been abadoned by upstream nearly three years ago [1] since Facebook has been implementing support for XMPP for some time now and it is no longer necessary to have the plugin installed in order to chat with Pidgin on Facebook. Removing the package will also close a couple of bugs [2]. Cheers, Adrian > [1] http://code.google.com/p/pidgin-facebookchat/wiki/Changelog > [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=pidgin-facebookchat -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.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/20130508001046.22713.80422.reportbug@localhost.localdomain
Re: Hurd and the archive
On 08/05/13 00:07, Samuel Thibault wrote: > I don't know what ethernet driver these would need. Should probably start a GNU/Hurd hardware status page on the Wiki... > Neil McGovern, le Tue 07 May 2013 11:14:01 +0100, a écrit : >> a) A HP DL360 or similar The chipset has changed a bit between generations: G1: eepro (Linux) or fxp (*BSD) driver, requiring non-free microcode G2: HP NC7780 aka BCM5701, tg3 driver (Linux) or bge (*BSD) G3: HP NC7781, same? G4: HP NC7782, same? G5: bce/bnx (*BSD) or bnx2 (Linux) driver, needs non-free blob? 004:00:0: Broadcom BCM5708 NetXtreme II 1000baseT Ethernet (ethernet network, revision 0x12) G6: HP NC382i aka BCM5709C, same driver >> b) A Dell inspiron 660s or similar Chipset isn't mentioned in their tech specs, perhaps varies. >> c) A Lenovo Thinkpad X220 or similar I've seen e1000e mentioned, supported in wheezy by Linux 3.2.x, but not by the version of the Intel drivers in squeeze: 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) >> d) VMWare/VBox etc. > > This already works. > > Also, Xen support just works [...] With network connectivity? If so which NIC do they emulate? (rtl8139?) What kind of storage bus is used? Regards, -- Steven Chamberlain ste...@pyro.eu.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/51899557.5090...@pyro.eu.org
Re: Current and upcoming toolchain changes for jessie
On Wed, May 08, 2013 at 01:39:25AM +0200, Matthias Klose wrote: > Am 07.05.2013 17:48, schrieb Aurelien Jarno: > > On Tue, May 07, 2013 at 03:25:29PM +0200, Matthias Klose wrote: > >> Up to today jessie did see updates for the kernel headers, eglibc, and > >> GCC. > > > > What a wonderful coordination with the release team. Quoting the last > > mail from them on the mailing list: > > > > | As for Squeeze, we'd ask that you co-ordinate particularly large > > | transitions or changes; if your plans involve major toolchain changes or > > | otherwise have the potential to cause problems in unstable for a long > > | time (e.g. due to FTBFS issues), please talk to us. > > I think you are over-reacting a bit here. My impression was that the eglibc > changes were coordinated within the team. So what about the other changes? They weren't coordinated within the team. Furthermore I don't consider that eglibc was ready to go to unstable, as it was known that two architectures were going to FTBFS, without a real try to get that fixed (for example by contacting the porters). > - a new version of GCC was uploaded, not as the default, but as a >separate version. I didn't want to split out the x32 multilibs >again. I didn't do a test rebuild of the archive, but this upload >shouldn't cause any additional build failures. I still don't fully see the point of having this x32 multilibs, given that: (a) It goes on the opposite direction of multiarch (b) It's completely useless on a Debian system, as the kernel doesn't support x32 binaries. >There is a mini transition involving ppl and cloog-ppl, however the >GCC packages are the only reverse dependencies, so this looks fine. > > - binutils was not uploaded, just the intent for the changes >communicated. > > - I didn't upload linux-libc-dev myself, but until today I didn't >see any announcement or a test rebuild done by the Debian kernel >maintainers, so I did add the note about what I did see in multiple >packages when doing a test rebuild in Ubuntu. > >And I think it's a normal change, and build failures can be reported >after a test rebuild. You may want to contact the kernel team, if >you think otherwise. > > As you see in the release announcement, the Debian release team was aware > about > the GCC 4.8 upload. Further I did contact the release team (Adam Barrat) > weeks As far as I know the release team was not aware of the broken eglibc upload before it happened. They seemed to not really like the fact that almost every package built against the new libc6 is now getting a dependency on libc6 >= 2.14, hence blocking all other transitions. > before the release how to better coordinate the opening of jessie. I assume > that > just didn't happen because people were busy with other things. Yes, seeing What about contacting the team instead of a random person of the team? Otherwise you coordinate with one person of the team, not the team. > people uploading random new library versions which did break at least the ppl > build did make me a bit nervous, so I wanted to get the required changes in > place for the upcoming transitions. > > There were rumours that the release would be delayed until May 15, so I tried > to > coordinate toolchain changes to be ready at this time. So, the rumours did > prove wrong, and Adam Conrad did upload eglibc and gcc packages today. What's the point of rushing so much these uploads, even if they are not ready? > >> For the Debian glibc maintainers, Adam Conrad > > > > Now I understand why I was not in the loop, I am not member of the team > > anymore. Glad to learn that in such an email. > > It would help to keep down the sarcasm. My intent was to describe that as an > coordinated upload of eglibc and GCC. You do have commit rights for some GCC > ports as well, so you can surely contact me if a port is broken or unusable. > But > according to test results, things look not worse for 4.8 than for 4.7. It was clearly a coordinated upload, but between Adam Conrad and you, not between the glibc maintainers and the gcc maintainers. Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20130507235938.go26...@hall.aurel32.net
Re: Current and upcoming toolchain changes for jessie
Am 07.05.2013 17:48, schrieb Aurelien Jarno: > On Tue, May 07, 2013 at 03:25:29PM +0200, Matthias Klose wrote: >> Up to today jessie did see updates for the kernel headers, eglibc, and >> GCC. > > What a wonderful coordination with the release team. Quoting the last > mail from them on the mailing list: > > | As for Squeeze, we'd ask that you co-ordinate particularly large > | transitions or changes; if your plans involve major toolchain changes or > | otherwise have the potential to cause problems in unstable for a long > | time (e.g. due to FTBFS issues), please talk to us. I think you are over-reacting a bit here. My impression was that the eglibc changes were coordinated within the team. So what about the other changes? - a new version of GCC was uploaded, not as the default, but as a separate version. I didn't want to split out the x32 multilibs again. I didn't do a test rebuild of the archive, but this upload shouldn't cause any additional build failures. There is a mini transition involving ppl and cloog-ppl, however the GCC packages are the only reverse dependencies, so this looks fine. - binutils was not uploaded, just the intent for the changes communicated. - I didn't upload linux-libc-dev myself, but until today I didn't see any announcement or a test rebuild done by the Debian kernel maintainers, so I did add the note about what I did see in multiple packages when doing a test rebuild in Ubuntu. And I think it's a normal change, and build failures can be reported after a test rebuild. You may want to contact the kernel team, if you think otherwise. As you see in the release announcement, the Debian release team was aware about the GCC 4.8 upload. Further I did contact the release team (Adam Barrat) weeks before the release how to better coordinate the opening of jessie. I assume that just didn't happen because people were busy with other things. Yes, seeing people uploading random new library versions which did break at least the ppl build did make me a bit nervous, so I wanted to get the required changes in place for the upcoming transitions. There were rumours that the release would be delayed until May 15, so I tried to coordinate toolchain changes to be ready at this time. So, the rumours did prove wrong, and Adam Conrad did upload eglibc and gcc packages today. >> For the Debian glibc maintainers, Adam Conrad > > Now I understand why I was not in the loop, I am not member of the team > anymore. Glad to learn that in such an email. It would help to keep down the sarcasm. My intent was to describe that as an coordinated upload of eglibc and GCC. You do have commit rights for some GCC ports as well, so you can surely contact me if a port is broken or unusable. But according to test results, things look not worse for 4.8 than for 4.7. Matthias -- 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/518990ad.2040...@debian.org
Re: Hurd and the archive
Neil McGovern, le Tue 07 May 2013 11:14:01 +0100, a écrit : > On Mon, May 06, 2013 at 10:27:54PM +0200, Samuel Thibault wrote: > > We have not worked too much on the hardware support in the past months, > > so it is basically network board drivers from linux 2.6.32, and IDE > > disk support. I for instance installed it on my Dell D430, and network > > just works fine. Working on a SATA driver should not be a problem. I > > just haven't put it high on my TODO list, and have rather worked on the > > Wheezy release whenever I had time to. > > Basically: in about 1 months time, will I be able to install it with a > default installation process, and have it working on: > a) A HP DL360 or similar > b) A Dell inspiron 660s or similar > c) A Lenovo Thinkpad X220 or similar I don't know what ethernet driver these would need. 2.6.32 linux kernels already have e1000, 8139*, tg3 etc. drivers. This is the usual issue of not-so-mature systems, just like Linux had in its early days. About disk support, I happen to have right now a few days of holiday with no RL plans (at last!), so I'll work on the SATA driver. Having it working within a month should just happen. > d) VMWare/VBox etc. This already works. Also, Xen support just works, which is not really like raw hardware support of course, but still better than full virtualization. Samuel -- 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/20130507230742.gf6...@type.wlan.youpi.perso.aquilenet.fr
Bug#707167: pu: package lapack/3.4.1+dfsg-1+deb70u1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu X-Debbugs-CC: sylves...@debian.org, mba...@debian.org Please find attached a proposed update for LAPACK. It fixes an issue with wrong numerical results in a multithreaded environment, so I consider this severe enough to warrant a stable update. Note that instead of adding the RECURSIVE keyword in the declaration of all affected routines, another fix could have been to add the gfortran flag -frecursive. The latter option would have given a smaller source diff, but would have actually been a bigger change, since it would be equivalent to adding the RECURSIVE keyword to *all* LAPACK functions. Thanks, -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 Index: debian/changelog === --- debian/changelog (révision 45845) +++ debian/changelog (copie de travail) @@ -1,3 +1,11 @@ +lapack (3.4.1+dfsg-1+deb70u1) stable; urgency=low + + * recursive.patch: fix some routines which produce incorrect results in +multithreaded environment. Thanks to Michael Banck for the fix +(Closes: #693269) + + -- Sébastien Villemot Tue, 07 May 2013 22:38:47 +0200 + lapack (3.4.1+dfsg-1) unstable; urgency=low * Repackage upstream tarball. Delete non-DFSG-free files: Index: debian/patches/recursive.patch === --- debian/patches/recursive.patch (révision 0) +++ debian/patches/recursive.patch (copie de travail) @@ -0,0 +1,525 @@ +Description: Ensure thread safety of functions with large local variables + Some LAPACK functions allocate large local variables. The default behavior of + gfortran is to allocate such variables statically, instead of using the heap. + This makes these functions thread unsafe. The fix consists in declaring these + functions as RECURSIVE, to force heap allocation. +Author: Michael Banck +Bug: http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=1930 +Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693269 +Reviewed-by: Sébastien Villemot +Last-Update: 2013-05-07 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- ./src/cgbtrf.f.orig 2013-05-06 00:43:02.302380624 +0200 ./src/cgbtrf.f 2013-05-06 00:44:23.910803548 +0200 +@@ -18,7 +18,8 @@ + * Definition: + * === + * +-* SUBROUTINE CGBTRF( M, N, KL, KU, AB, LDAB, IPIV, INFO ) ++* RECURSIVE SUBROUTINE CGBTRF( M, N, KL, KU, AB, LDAB, IPIV, ++*INFO ) + * + * .. Scalar Arguments .. + * INTEGERINFO, KL, KU, LDAB, M, N +@@ -142,7 +143,7 @@ + *> \endverbatim + *> + * = +- SUBROUTINE CGBTRF( M, N, KL, KU, AB, LDAB, IPIV, INFO ) ++ RECURSIVE SUBROUTINE CGBTRF( M, N, KL, KU, AB, LDAB, IPIV, INFO ) + * + * -- LAPACK computational routine (version 3.4.0) -- + * -- LAPACK is a software package provided by Univ. of Tennessee,-- +--- ./src/cgehrd.f.orig 2013-05-06 00:43:02.330380770 +0200 ./src/cgehrd.f 2013-05-06 00:44:48.006928485 +0200 +@@ -18,7 +18,8 @@ + * Definition: + * === + * +-* SUBROUTINE CGEHRD( N, ILO, IHI, A, LDA, TAU, WORK, LWORK, INFO ) ++* RECURSIVE SUBROUTINE CGEHRD( N, ILO, IHI, A, LDA, TAU, WORK, ++*LWORK, INFO ) + * + * .. Scalar Arguments .. + * INTEGERIHI, ILO, INFO, LDA, LWORK, N +@@ -166,7 +167,8 @@ + *> \endverbatim + *> + * = +- SUBROUTINE CGEHRD( N, ILO, IHI, A, LDA, TAU, WORK, LWORK, INFO ) ++ RECURSIVE SUBROUTINE CGEHRD( N, ILO, IHI, A, LDA, TAU, WORK, ++ $ LWORK, INFO ) + * + * -- LAPACK computational routine (version 3.4.0) -- + * -- LAPACK is a software package provided by Univ. of Tennessee,-- +--- ./src/cunmlq.f.orig 2013-05-06 00:43:02.342380830 +0200 ./src/cunmlq.f 2013-05-06 00:45:13.531060884 +0200 +@@ -18,8 +18,8 @@ + * Definition: + * === + * +-* SUBROUTINE CUNMLQ( SIDE, TRANS, M, N, K, A, LDA, TAU, C, LDC, +-* WORK, LWORK, INFO ) ++* RECURSIVE SUBROUTINE CUNMLQ( SIDE, TRANS, M, N, K, A, LDA, TAU, ++*C, LDC, WORK, LWORK, INFO ) + * + * .. Scalar Arguments .. + * CHARACTER SIDE, TRANS +@@ -167,8 +167,8 @@ + *> \ingroup complexOTHERcomputational + * + * = +- SUBROUTINE CUNMLQ( SIDE, TRANS, M, N, K, A, LDA, TAU, C, LDC, +- $ WORK, LWORK, INFO ) ++ RECURSIVE SUBROUTINE CUNMLQ( SIDE, TRANS, M, N, K, A, LDA, TAU, C, ++ $ LDC, WORK, LWORK, INFO ) + * + * -- LAPACK compu
Bug#670902: planning (a) hsqldb transition(s)
Hi, On Thu, Apr 25, 2013 at 11:22:05PM +0200, Rene Engelhard wrote: > openjpa failed to build (see #706176) [...] > Will upload the new version after wheezy release[1] as announced in > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670902#17 Done. Regards, Rene -- 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/20130507201938.gc4...@rene-engelhard.de
Bug#704465: will upload after release - pinot is OK
Hi, On Tue, Apr 30, 2013 at 11:32:41AM +0200, Rene Engelhard wrote: > as just discussed on IRC: > > 11:22 <_rene_> ping? > 11:23 pong > 11:23 <_rene_> would you mind if I uploaded libexttextcat 3.4.0 (quite) > directly after release? > 11:23 <_rene_> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704465 > 11:23 <_rene_> you're the only r-dep besides LO :) > 11:23 * _rene_ wants to get this done before the big(tm) transitions start - > like boost. > 11:24 I see no problem in that - since you mention in the bugreport > that it is binNMUable > 11:24 thanks for asking - but why do you? > 11:25 just to be extra cautious? > 11:25 <_rene_> yeah, but I'll be blocked then behing the whole combo (as LO > would depend on the new lib and thus the new -data >and ...) > 11:25 <_rene_> yes :) > 11:25 thanks > 11:25 you need not be so cautious with me :-) Done now. Bin-NMU reuqest filed: #707123 LO will get a source upload, no need to waste build cycles for it.. Regards, Rene -- 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/20130507201839.gb4...@rene-engelhard.de
Bug#707137: pu: package tasksel/3.14.1
On Tue, 2013-05-07 at 15:47 -0400, Joey Hess wrote: > Adam D. Barratt wrote: > > What's the plan for fixing this in unstable / jessie? (Partly because > > the preferred workflow is fix sid, propose fix, upload, and partly > > because dak requires that unstable >= stable.) > > The fix is in unstable, and was uploaded with urgency=high Indeed; I should have waited a little longer for a reply to the query on IRC before following up. Regards, Adam -- 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/1367956087.26753.11.ca...@jacala.jungle.funky-badger.org
Bug#707137: pu: package tasksel/3.14.1
Adam D. Barratt wrote: > What's the plan for fixing this in unstable / jessie? (Partly because > the preferred workflow is fix sid, propose fix, upload, and partly > because dak requires that unstable >= stable.) The fix is in unstable, and was uploaded with urgency=high -- see shy jo signature.asc Description: Digital signature
Re: lesstif2 to motif transition
Hi RT, On 06-05-13 23:01, Paul Gevers wrote: > So my question basically is, what would be the most appropriate order to > do things? > > My proposal would be (with your approval) to just get motif into > unstable/main and start converting the dependencies with the help of > their maintainers (the libraries can coexist). Because the -dev package > name has to change all build dependencies would have to get a > source-full update. I would have liked to stage everything in > experimental, but due to this (quoted from ftp-master) nasty dak bug, > that would leave unstable (non-free) without (open-)motif. Having thought about this again today, how about the following proposal: - Upload the latest packaging of motif to non-free to get the new packaging and rename of the source past the NEW queue. - Ask and help the current maintainers of reverse dependencies to try out building their packages in experimental with libmotif-dev in non-free. Yes, the policy does not allow this, but as ftp-master agrees that we move the package to main, I expect this could be acceptable, if at all possible. - When all packages are lined up, remove motif from non-free into main and start the transition in unstable. Do you think this works and do you find this acceptable? An alternative that I could come up with, but maybe it is an insane idea, is that I update the lesstif2 package to make the lesstif2-dev package a transitional package that depends on libmotif-dev. I believe only the packages that need the additional build dependencies (e-mail from Graham) would not be helped by this temporary solution, but that can be fixed in advance. So than we could upload motif and lesstif2 to unstable after your approval and start converting the packages to properly build-depend on libmotif-dev. Do you prefer that I file a proper transition bug for this issue now? Please advice on what you find acceptable. I propose that we start to inform the reverse dependent package maintainers about our intent to replace lesstif2 with motif when we have agreed on the proposed attack path from your point of view. Paul signature.asc Description: OpenPGP digital signature
Re: [Piuparts-devel] piuparts squeeze->wheezy [i386] tests
Hi Andreas, On Dienstag, 7. Mai 2013, Andreas Beckmann wrote: > ... But it showed that we > should run Ralf Treinen's edos file overwrite checks for more > architectures than just amd64 how to run them? Does it make sense to setup jobs on jenkins.d.n for this? (=will they ever^wusually result with 0 errors for one patricular architecture?) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: unblock-udeb hints
On Tue, 2013-05-07 at 19:23 +0100, Steven Chamberlain wrote: > Will the unblock-udeb hints be removed soon, or is it still necessary to > open unblock requests? I realise Cyril already replied, but for the record that's not our decision. The block-udeb hints are maintained by the release team because they form part of a britney hint file, but the ultimate decision as to what's blocked using them at any given point lies with the d-i team, particularly the d-i RM(s). Regards, Adam -- 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/1367952176.26753.8.ca...@jacala.jungle.funky-badger.org
Bug#707137: pu: package tasksel/3.14.1
On Tue, 2013-05-07 at 14:26 -0400, Joey Hess wrote: > Unfortunately, wheezy shipped with a tasksel that, on a desktop system, > selects both the desktop and the ssh server tasks for installation by > default. This was not intentional. The intent was to default to > selecting the desktop task on desktop systems, and the ssh server task > on all other systems. Thanks for the analysis and fix. > I have uploaded tasksel to s-p-u with this patch. I recommend it be > included in the next point release. What's the plan for fixing this in unstable / jessie? (Partly because the preferred workflow is fix sid, propose fix, upload, and partly because dak requires that unstable >= stable.) Regards, Adam -- 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/1367951850.26753.5.ca...@jacala.jungle.funky-badger.org
Re: unblock-udeb hints
Hi Steven, (cc-ing -boot@ or me would be nice when it comes to udeb things, even if the release team can forward requests; or if I happen to spot it on -release@.) Steven Chamberlain (07/05/2013): > Will the unblock-udeb hints be removed soon, or is it still > necessary to open unblock requests? > > Currently this blocks a src:kfreebsd-9 security update from entering > testing, because some udebs are built from it. > > src:linux also had an update recently which is blocked too. Currently debating whether all unblock-udebs should disappear at once. Should have an answer to that in 1-2 days at most. Mraw, KiBi. signature.asc Description: Digital signature
Bug#707137: pu: package tasksel/3.14.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu Unfortunately, wheezy shipped with a tasksel that, on a desktop system, selects both the desktop and the ssh server tasks for installation by default. This was not intentional. The intent was to default to selecting the desktop task on desktop systems, and the ssh server task on all other systems. A typo in the code prevented this from working correctly, and apparently I was the only one who was aware of how it was intended to work, and I was not able to participate in testing wheezy installations prior to release. I only learned of this issue on wheezy release day when observing users mentioning that both tasks were selected. This is not a good behavior to have in stable, because a user who is not paying much attention can end up with a ssh server installed unintentionally, and be vulnerable to automated password probes. We can assume that users who are installing servers a) intend to run ssh (or will notice and de-select it if not) and b) can take responsibility for using it securely. But not so for all desktop users. I have uploaded tasksel to s-p-u with this patch. I recommend it be included in the next point release. diff --git a/debian/changelog b/debian/changelog index 5e17347..2d20341 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +tasksel (3.14.1) stable; urgency=low + + * Fix broken test for non-desktop systems which caused the ssh server task +to be selected by default on systems with a desktop. + + -- Joey Hess Tue, 07 May 2013 13:57:43 -0400 + tasksel (3.14+nmu2) unstable; urgency=low * Downgrade network-manager-gnome from Depends to Recommends. It's diff --git a/tests/server b/tests/server index e8ca610..3aeff7c 100755 --- a/tests/server +++ b/tests/server @@ -1,7 +1,12 @@ #!/bin/sh + +if ! [ "$NEW_INSTALL" ]; then + exit 3 +fi + /usr/lib/tasksel/tests/desktop ret=$? -case ret in +case $ret in 0|2) # is desktop exit 3 # not server ;; -- see shy jo signature.asc Description: Digital signature
unblock-udeb hints
Dear Release Team, Will the unblock-udeb hints be removed soon, or is it still necessary to open unblock requests? Currently this blocks a src:kfreebsd-9 security update from entering testing, because some udebs are built from it. src:linux also had an update recently which is blocked too. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.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/51894689.10...@pyro.eu.org
Bug#706830: Mistake on my side
On Tue, May 7, 2013 at 12:22:58 +0200, Ondřej Surý wrote: > Hi, > > I did a mistake in the first Ben file, here's the correct one: > > title = "php 5.5"; > is_affected = .build-depends ~ "php5-dev"; > is_good = .depends ~ "phpapi-20121212"; > is_bad = .depends ~ "phpapi-20100525"; > notes = "#706830"; > Actually that doesn't work either, because 32bit archs have phpapi-20100525+lfs, not phpapi-20100525. Should be fixed now. Cheers, Julien signature.asc Description: Digital signature
Re: nbd update for stable r1
[Disclaimer: I am not part of the release team] On 07-05-13 17:59, Wouter Verhelst wrote: > What are my chances of that happening? Also, should I upload again, or > can the version that's currently in unstable be moved/copied to > stable(-proposed-updates) without problem? As far as I understand it, if you prepare the package to be uploaded to stable-proposed-updates, provide the debdiff in the bug report and advocate why it is needed, and convince the RT, it can very well happen. It needs somebody to do that first work though, i.e. most likely you. Paul signature.asc Description: OpenPGP digital signature
Re: status of ia64 for jessie and later
On Tue, May 7, 2013 at 12:08:18 -0500, Patrick Baggett wrote: > Is libunwind8 the major blocker here? That doesn't seem too bad if it is. > I'd rather ia64 creak along than to be dropped entirely. > No, the major problem is that exactly one person (Stephan Schreiber) is working on keeping the port alive, as far as I know. Cheers, Julien signature.asc Description: Digital signature
Re: piuparts squeeze->wheezy [i386] tests
On Tue, May 7, 2013 at 12:13:28 +0200, Andreas Beckmann wrote: > On 2013-05-02 13:17, Andreas Beckmann wrote: > > Hi, > > > > Julien asked me about running piuparts tests for i386 (especially for > > the multiarch-support libc6 dependency) ... I patched piuparts a bit to > > support doing this on an amd64 host and started running distupgrade > > tests now. squeeze2wheezy --with-recommends for amd64 took 5 days, so > > this here (without recommends) should be faster. 27500 binary packages > > to go ... :-) > > This took about 4 days and I had to file at most 5 new bugs (and prepare > some opu uploads) ... so nothing exploded here. But it showed that we > should run Ralf Treinen's edos file overwrite checks for more > architectures than just amd64 > I may try to add squeeze2wheezy --arch i386 --with-recommends later on, > but right now I need to catch up with jessie and all the uploads rushing > to sid - both in piuparts and dput :-) > Thanks a lot for this, Andreas. Much appreciated. Cheers, Julien signature.asc Description: Digital signature
Re: status of ia64 for jessie and later
I'm an ia64 user and I would love for the port to not be dropped because I don't like the idea of Gentoo. :( Is libunwind8 the major blocker here? That doesn't seem too bad if it is. I'd rather ia64 creak along than to be dropped entirely. Patrick Baggett On Tue, May 7, 2013 at 11:57 AM, Ansgar Burchardt wrote: > Hi, > > I remember talk about potentially dropping the ia64 port after wheezy > was released, but don't know about the current status. > > However if this is planned it might be worth doing so soon: on ia64 > about 2750 source packages depend on libunwind7 which changed its soname > to libunwind8. > > Regards, > Ansgar > > > -- > To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/874nee683i@eisei.43-1.org > >
status of ia64 for jessie and later
Hi, I remember talk about potentially dropping the ia64 port after wheezy was released, but don't know about the current status. However if this is planned it might be worth doing so soon: on ia64 about 2750 source packages depend on libunwind7 which changed its soname to libunwind8. Regards, Ansgar -- 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/874nee683i@eisei.43-1.org
Bug#707123: nmu: pinot_1.05-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, as said in #704465 I've now uploaded libexttextcat 3.4.0 so pinot needs a bin-NMU: dw pinot_1.05-1 . ALL . -m 'libexttextcat-dev (>= 3.4.0)' nmu pinot_1.05-1 . ALL . -m "rebuild against libexttextcat 3.4.0" Thanks, Rene -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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/20130507165307.gc30...@rene-engelhard.de
Re: Current and upcoming toolchain changes for jessie
On Tue, May 07, 2013 at 05:48:52PM +0200, Aurelien Jarno wrote: > > Even if I have to admit I currently don't have a lot of time, it would > have been nice to keep the other people in the team in the loop about > such an upload. You'd been fairly inactive of late, and I felt I'd take some initiative here instead of asking you about every upload. Apologies, no offense was meant. I'd been told that you're fairly busy with real life, so was trying to pull up some slack, that's all. > > The other unfortunate issue with the glibc bump to 2.17 is that it > > has left kfreebsd behind with some pthread mutex changes that need > > some love from BSD porters to untangle. We had hoped that leaving > > it FTBFS in experimental for several months and gently pinging would > > have been enough of a hint, but we can't wait forever either. For a > > porter who knows FreeBSD and pthreads inside out, the work to fix > > glibc 2.17 on kfreebsd should be trivial. Patches welcome. > > I haven't been able to find mails about that on the debian-bsd mailing > list. Could you please point me to them? It was discussed on IRC with both 2.16 and 2.17 with you, among other people. I gave a stab at fixing some of it, but my BSD/pthreads know- how wasn't up to the task. You're right that I didn't mail the list, however. > > For the Debian glibc maintainers, Adam Conrad > > Now I understand why I was not in the loop, I am not member of the team > anymore. Glad to learn that in such an email. You're clearly still a member of the team. That was just how doko signed the email from both of us, I imagine he also didn't ask all the GCC uploaders/committers for their permission on his uploads either. Again, no personal offense was meant here, and the beginning of a new release seemed like the optimal time to make major toolchain changes, rather than waiting several months. The bugs had been filed (and many fixed) long ago. Other than the kfreebsd situation, this isn't a particularly nasty transition, per se. ... Adam -- 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/20130507160358.gd29...@0c3.net
Re: Current and upcoming toolchain changes for jessie
On Tue, May 07, 2013 at 10:03:58AM -0600, Adam Conrad wrote: > On Tue, May 07, 2013 at 05:48:52PM +0200, Aurelien Jarno wrote: > > > > Even if I have to admit I currently don't have a lot of time, it would > > have been nice to keep the other people in the team in the loop about > > such an upload. > > You'd been fairly inactive of late, and I felt I'd take some initiative > here instead of asking you about every upload. Apologies, no offense > was meant. I'd been told that you're fairly busy with real life, so > was trying to pull up some slack, that's all. That's true that I have been inactive, and I don't think you should ask for permission about every upload. However for major toolchain changes, it seemed obvious to me that you should coordinate with other people in the team, as well as the release team. > > > The other unfortunate issue with the glibc bump to 2.17 is that it > > > has left kfreebsd behind with some pthread mutex changes that need > > > some love from BSD porters to untangle. We had hoped that leaving > > > it FTBFS in experimental for several months and gently pinging would > > > have been enough of a hint, but we can't wait forever either. For a > > > porter who knows FreeBSD and pthreads inside out, the work to fix > > > glibc 2.17 on kfreebsd should be trivial. Patches welcome. > > > > I haven't been able to find mails about that on the debian-bsd mailing > > list. Could you please point me to them? > > It was discussed on IRC with both 2.16 and 2.17 with you, among other > people. I gave a stab at fixing some of it, but my BSD/pthreads know- > how wasn't up to the task. You're right that I didn't mail the list, > however. The main glibc BSD developer is not on IRC, but is actively reading the mailing list. > > > For the Debian glibc maintainers, Adam Conrad > > > > Now I understand why I was not in the loop, I am not member of the team > > anymore. Glad to learn that in such an email. > > You're clearly still a member of the team. That was just how doko > signed the email from both of us, I imagine he also didn't ask all the > GCC uploaders/committers for their permission on his uploads either. He is the only uploader, so there is no really point to ask others... > Again, no personal offense was meant here, and the beginning of a new > release seemed like the optimal time to make major toolchain changes, > rather than waiting several months. The bugs had been filed (and many > fixed) long ago. Other than the kfreebsd situation, this isn't a > particularly nasty transition, per se. I love your way of thinking. eglibc and thousand of packages (the memcpy change makes every package using memcpy depends on libc6 >= 2.14) are blocked in sid until eglibc is fixed on kfreebsd. Yeah, this isn't a particulary nasty transition. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20130507163015.gk26...@hall.aurel32.net
nbd update for stable r1
Hi folks, So, nbd 1:3.2-4 did not make the cut for wheezy, mainly because it took some time for it to get ready; and when it finally was and I remembered to ask about it again, it was too late. It was hinted in the bugreport there that maybe I could still get it into r1. I'd like to explore that possibility, as some of the changes are fairly important IMO. What are my chances of that happening? Also, should I upload again, or can the version that's currently in unstable be moved/copied to stable(-proposed-updates) without problem? Thanks, -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- 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/518924e0.7000...@debian.org
Re: Current and upcoming toolchain changes for jessie
On Tue, May 07, 2013 at 03:25:29PM +0200, Matthias Klose wrote: > Up to today jessie did see updates for the kernel headers, eglibc, and > GCC. What a wonderful coordination with the release team. Quoting the last mail from them on the mailing list: | As for Squeeze, we'd ask that you co-ordinate particularly large | transitions or changes; if your plans involve major toolchain changes or | otherwise have the potential to cause problems in unstable for a long | time (e.g. due to FTBFS issues), please talk to us. > == (e)glibc 2.17 == > > glibc's version bump to 2.17 should be mostly uneventful, with the > exception of a few more compiler warnings and errors, and the long > overdue removal of gets() from the API. FTBFS bugs for the above > have already been filed, and patches submitted for many of the new > build failures. Even if I have to admit I currently don't have a lot of time, it would have been nice to keep the other people in the team in the loop about such an upload. > The other unfortunate issue with the glibc bump to 2.17 is that it > has left kfreebsd behind with some pthread mutex changes that need > some love from BSD porters to untangle. We had hoped that leaving > it FTBFS in experimental for several months and gently pinging would > have been enough of a hint, but we can't wait forever either. For a > porter who knows FreeBSD and pthreads inside out, the work to fix > glibc 2.17 on kfreebsd should be trivial. Patches welcome. I haven't been able to find mails about that on the debian-bsd mailing list. Could you please point me to them? [...] > For the Debian glibc maintainers, Adam Conrad Now I understand why I was not in the loop, I am not member of the team anymore. Glad to learn that in such an email. Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20130507154851.gi4...@ohm.aurel32.net
Re: Adding cloud-init in the next Wheezy point release
On 05/07/2013 08:16 PM, Adam D. Barratt wrote: > On 2013-05-06 17:19, Thomas Goirand wrote: >> In this thread: >> https://lists.debian.org/debian-cloud/2013/05/msg2.html >> >> we have been discussing how we could have cloud-init in the Debian cloud >> images. >> >> One solution is to enable wheezy-backports by default in the images. >> Though there are some concerns that we shouldn't do that, as this isn't >> the default in Debian right now. > > If it's just to pull the package in during image build, is that a > particular problem? The problem that was raised is that some users might want to do security updates, which then wouldn't be possible. A typical workflow would be: - A user uses a pre-build Debian official image, then customizes it - He uses the cloud, then decides to upgrade his image - He then makes a snapshot of the image using the cloud API If we don't provide a way so that cloud-init is also upgraded, then we have a problem (I'm not saying there will be a problem on cloud-init, but we should always prepare for the worst). > >> The other solution would be to add cloud-init in the next point release >> of Wheezy. We all know that there's some strong rules that we shouldn't >> add new things in the stable distribution, even more after the freeze. > > I assume you mean after the release? It's a little late to worry about > being after the freeze. A "than" is missing. I meant to write "even more than after the freeze". > If cloud-init is so mission-critical, why was this never noticed or > raised *before* the release? It was. But it took some time to get it into SID. According to the PTS, Charles Plessy uploaded it to Experimental in the 23rd of June. Then Julien Danjou uploaded it into SID last January, but it stayed in the NEW queue for a very long time. The main problem is that the interest for the cloud and building an official Debian cloud image is fairly recent. There is more and more people (including DDs) interested in it, and not having cloud-init in main is quite annoying for those of us who do desire to build cloud images. Anyway, I don't think that digging in the history of the package will help solving anything, so let's stop! :) We (at least Julien and I) thought it would be ok to use backports, but on the 2nd thought, it doesn't seem to be the best solution. I already explained that activating backports by default isn't desirable: since that isn't the default for Wheezy. The other argument is that cloud-init would be the only package which would be needed from backports. Which is why I wonder what the release team opinion was, and if we could do something about it. If there is a strong *no* from the release team, i guess we could live with the backports solution, though it is my opinion that it would be best if we could make an exception in this case. If staging cloud-init in backports for a few months is one of the things who can ease the decision of the release team, I think it could be a good temporary solution as well. If there are other things which could ease the decision, let us know. Waiting for a full release cycle (eg: 2 years) to get cloud-init in main would IMO not be desirable. Thomas Goirand (zigo) -- 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/51891d73.3030...@debian.org
Re: tiff 4.x (libtiff5) transition
Jay Berkenbilt debian.org> writes: > hoping Jessie will ship with only one version of the tiff library: […] > I'd obviously like to get on this as soon as possible, but I understand Agreed, but tiff depends on jpeg, and there are people who want to switch jpeg to “jpeg-turbo” (still being unclear whether it implements all jpeg functions or just these deemed “needed”) or, if not, jpeg might want a soname bump too. So it might make sense to wait for completion of that, or do them in one go (no idea what’s easier for Debian). You might want to talk to the jpeg maintainer for this. Just an outsider 2¢, //mirabilos -- 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/loom.20130507t134844-...@post.gmane.org
Re: Aw: Re: Adding cloud-init in the next Wheezy point release
Hello Steffan, Adam, I think the question for cloud images becomes: would we consider a Debian image with backports enabled in apt.sources *by default* and to have packages installed from backports to still be 'pure' Debian? I would think some would feel this is not. This was much discussed prior to release, but the deep freeze meant that the package maintainer chose to go the backports route rather than ask for a freeze exception, which I understand. I suppose we have three options before us at this stage: 1) Use backports by default in apt.source in cloud images, and we bless this as still being Debian 2) Wait until the next point release, and see if cloud-init can be transitioned to main 3) Stay as we are, and wait until the next release in 2+ years time Personally, I am happy with #1, so long as the rest of the community is. Appreciate input from others. James On 7/05/2013 9:05 PM, "Steffen Möller" wrote: > I am with Adam. Instead of changing what a release means to us by talking > about individual packages to somehow by some exception sneak in after the > release date, we should instead strengthen what backports.debian.org means to > us and offer those important packages immediately and officially through that > channel. However, I would tend to agree with a semi-automated transition from > backports to point releases. > > Cheers, > > Steffen > > > > Gesendet: Dienstag, 07. Mai 2013 um 14:16 Uhr > Von: "Adam D. Barratt" > An: "Thomas Goirand" > Cc: "Debian Release" , > debian-cl...@lists.debian.org > Betreff: Re: Adding cloud-init in the next Wheezy point release > On 2013-05-06 17:19, Thomas Goirand wrote: >> In this thread: >> https://lists.debian.org/debian-cloud/2013/05/msg2.html >> >> we have been discussing how we could have cloud-init in the Debian >> cloud >> images. >> >> One solution is to enable wheezy-backports by default in the images. >> Though there are some concerns that we shouldn't do that, as this >> isn't >> the default in Debian right now. > If it's just to pull the package in during image build, is that a > particular problem? > >> The other solution would be to add cloud-init in the next point >> release >> of Wheezy. We all know that there's some strong rules that we >> shouldn't >> add new things in the stable distribution, even more after the >> freeze. > I assume you mean after the release? It's a little late to worry about > being after the freeze. > >> However, there has been some exception, like for example for the >> kernel >> which includes new drivers. I believe we are in this kind of >> exception, >> where the package is a crucial piece, without which the Debian cloud >> images will never work. Building an official Debian cloud image >> without >> it is not an option, unfortunately. Cloud-init is indeed an industry >> standard, as described in the above thread, and is mandatory. > The kernel's slightly different; it's also changing content, not > packages. > > I'm sure someone will correct me if I'm wrong, but during the cycles > I've been involved with Debian one new package has been introduced after > a release and that was for a _very_ particular purpose - in fact, it was > introduced by the security team in a DSA (openssh-blacklist). > > If cloud-init is so mission-critical, why was this never noticed or > raised *before* the release? > > Regards, > > Adam > > > -- > To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > http://lists.debian.org/bed0e3745803b4d549b7cbc9cdf1b...@mail.adsl.funky-badger.org[http://lists.debian.org/bed0e3745803b4d549b7cbc9cdf1b...@mail.adsl.funky-badger.org] > > > -- /Mobile:/ +61 422 166 708, /Email:/ james_AT_rcpt.to
Re: Aw: Re: Adding cloud-init in the next Wheezy point release
On Tue, May 07, 2013 at 09:24:00PM +0800, James Bromberger wrote: > 1) Use backports by default in apt.source in cloud images, and we > bless this as still being Debian > > Personally, I am happy with #1, so long as the rest of the community > is. Given that backports are not installed by default, I don't think the matter of whether backports is *present* in sources.list alone is enough to define the problem. It's rather how many packages we have to install from it, and how relevant they are. Considering that, AFAICT, we're talking only about cloud-init, and considering its relevance for the cloud images, I think installing it from backports in the cloud images would be acceptable. (And, as we discussed earlier on, at that point you really want to have backports in sources.list, to avoid missing updates for the backported package.) What we should certainly do is have some Debian documentation specific for the cloud images, which include a list of differences from regular images. (But before talking about this, we should probably look into having a "get Debian" page for Debian cloud images :-)) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Aw: Re: Adding cloud-init in the next Wheezy point release
I am with Adam. Instead of changing what a release means to us by talking about individual packages to somehow by some exception sneak in after the release date, we should instead strengthen what backports.debian.org means to us and offer those important packages immediately and officially through that channel. However, I would tend to agree with a semi-automated transition from backports to point releases. Cheers, Steffen Gesendet: Dienstag, 07. Mai 2013 um 14:16 Uhr Von: "Adam D. Barratt" An: "Thomas Goirand" Cc: "Debian Release" , debian-cl...@lists.debian.org Betreff: Re: Adding cloud-init in the next Wheezy point release On 2013-05-06 17:19, Thomas Goirand wrote: > In this thread: > https://lists.debian.org/debian-cloud/2013/05/msg2.html > > we have been discussing how we could have cloud-init in the Debian > cloud > images. > > One solution is to enable wheezy-backports by default in the images. > Though there are some concerns that we shouldn't do that, as this > isn't > the default in Debian right now. If it's just to pull the package in during image build, is that a particular problem? > The other solution would be to add cloud-init in the next point > release > of Wheezy. We all know that there's some strong rules that we > shouldn't > add new things in the stable distribution, even more after the > freeze. I assume you mean after the release? It's a little late to worry about being after the freeze. > However, there has been some exception, like for example for the > kernel > which includes new drivers. I believe we are in this kind of > exception, > where the package is a crucial piece, without which the Debian cloud > images will never work. Building an official Debian cloud image > without > it is not an option, unfortunately. Cloud-init is indeed an industry > standard, as described in the above thread, and is mandatory. The kernel's slightly different; it's also changing content, not packages. I'm sure someone will correct me if I'm wrong, but during the cycles I've been involved with Debian one new package has been introduced after a release and that was for a _very_ particular purpose - in fact, it was introduced by the security team in a DSA (openssh-blacklist). If cloud-init is so mission-critical, why was this never noticed or raised *before* the release? Regards, Adam -- To UNSUBSCRIBE, email to debian-cloud-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bed0e3745803b4d549b7cbc9cdf1b...@mail.adsl.funky-badger.org[http://lists.debian.org/bed0e3745803b4d549b7cbc9cdf1b...@mail.adsl.funky-badger.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/trinity-2de3e053-f4e7-4e56-b65e-bf911a08e655-1367931937983@3capp-gmx-bs50
Re: Adding cloud-init in the next Wheezy point release
On 2013-05-06 17:19, Thomas Goirand wrote: In this thread: https://lists.debian.org/debian-cloud/2013/05/msg2.html we have been discussing how we could have cloud-init in the Debian cloud images. One solution is to enable wheezy-backports by default in the images. Though there are some concerns that we shouldn't do that, as this isn't the default in Debian right now. If it's just to pull the package in during image build, is that a particular problem? The other solution would be to add cloud-init in the next point release of Wheezy. We all know that there's some strong rules that we shouldn't add new things in the stable distribution, even more after the freeze. I assume you mean after the release? It's a little late to worry about being after the freeze. However, there has been some exception, like for example for the kernel which includes new drivers. I believe we are in this kind of exception, where the package is a crucial piece, without which the Debian cloud images will never work. Building an official Debian cloud image without it is not an option, unfortunately. Cloud-init is indeed an industry standard, as described in the above thread, and is mandatory. The kernel's slightly different; it's also changing content, not packages. I'm sure someone will correct me if I'm wrong, but during the cycles I've been involved with Debian one new package has been introduced after a release and that was for a _very_ particular purpose - in fact, it was introduced by the security team in a DSA (openssh-blacklist). If cloud-init is so mission-critical, why was this never noticed or raised *before* the release? Regards, Adam -- 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/bed0e3745803b4d549b7cbc9cdf1b...@mail.adsl.funky-badger.org
Bug#707085: transition: gmtk
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi release team, I'd like to request a slot for the transition of gmtk. libgmtk0 and libgmlib0 both bumped SONAME. gmtk and its reverse dependencies gnome-mplayer and gecko-mediaplayer are staged in experimental. No other packages are affected and thus this should only be a matter of uploading the versions of gmtk, gnome-mplayer and gecko-mediaplayer found in experimental to unstable. Regards Ben file: title = "gmtk"; is_affected = .build-depends ~ "libgmtk-dev" | .build-depends ~ "libgmlib-dev"; is_good = .depends ~ "libgmtk1" | .depends ~ "libgmlib1"; is_bad = .depends ~ "libgmtk0" | .depends ~ "libgmlib0"; -- Sebastian Ramacher signature.asc Description: Digital signature
Re: piuparts squeeze->wheezy [i386] tests
On 2013-05-02 13:17, Andreas Beckmann wrote: > Hi, > > Julien asked me about running piuparts tests for i386 (especially for > the multiarch-support libc6 dependency) ... I patched piuparts a bit to > support doing this on an amd64 host and started running distupgrade > tests now. squeeze2wheezy --with-recommends for amd64 took 5 days, so > this here (without recommends) should be faster. 27500 binary packages > to go ... :-) This took about 4 days and I had to file at most 5 new bugs (and prepare some opu uploads) ... so nothing exploded here. But it showed that we should run Ralf Treinen's edos file overwrite checks for more architectures than just amd64 I may try to add squeeze2wheezy --arch i386 --with-recommends later on, but right now I need to catch up with jessie and all the uploads rushing to sid - both in piuparts and dput :-) Andreas -- 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/5188d3c8.4040...@debian.org
Bug#706830: Mistake on my side
Hi, I did a mistake in the first Ben file, here's the correct one: title = "php 5.5"; is_affected = .build-depends ~ "php5-dev"; is_good = .depends ~ "phpapi-20121212"; is_bad = .depends ~ "phpapi-20100525"; notes = "#706830"; Sorry, -- Ondřej Surý -- 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/CALjhHG9x8EvVDHtDGP756=hk8pthqwb2-gqrifzklcwrdtb...@mail.gmail.com
Re: Hurd and the archive
On Mon, May 06, 2013 at 10:27:54PM +0200, Samuel Thibault wrote: > We have not worked too much on the hardware support in the past months, > so it is basically network board drivers from linux 2.6.32, and IDE > disk support. I for instance installed it on my Dell D430, and network > just works fine. Working on a SATA driver should not be a problem. I > just haven't put it high on my TODO list, and have rather worked on the > Wheezy release whenever I had time to. > Basically: in about 1 months time, will I be able to install it with a default installation process, and have it working on: a) A HP DL360 or similar b) A Dell inspiron 660s or similar c) A Lenovo Thinkpad X220 or similar d) VMWare/VBox etc. Neil -- signature.asc Description: Digital signature
Bug#706973: transition: audit
Le Mon, 6 May 2013 17:34:40 +0200, Cyril Brulebois a écrit : Hello, > Laurent Bigonville (06/05/2013): > > I just tried to rebuild xorg with the latest version and the build > > was successful, I didn't try the other rdeps yet. > > Whether it also starts successfully would be a good thing to check. Looks like both X and gdm3 are working properly when recompiled with the latest version of audit. Cheers Laurent Bigonville signature.asc Description: PGP signature
Processed: block 661958 with 707060 707061 707062 707063 707064 707065 707066
Processing commands for cont...@bugs.debian.org: > block 661958 with 707060 707061 707062 707063 707064 707065 707066 Bug #661958 [release.debian.org] transition: apache2 2.4 661958 was blocked by: 669755 669834 666854 669775 666817 669735 666832 669825 669856 670973 669777 669814 669743 669791 669840 666848 666850 666806 666857 666811 669782 669884 666838 666825 666855 669812 669747 666863 669844 666799 666829 669769 669738 669821 666815 669749 669828 669792 669842 669762 669785 666807 666862 666859 669823 666860 669745 669819 666796 669837 669733 666822 669757 669830 669854 666858 666820 666847 669959 666835 669804 669801 669741 669798 669767 666801 666833 669750 669761 666831 669788 669779 669808 669759 669832 666830 669827 666837 666814 666856 669787 669773 669737 666849 666852 666818 669826 669774 666810 669806 669855 669768 666809 666797 669796 669815 669742 666846 666805 669885 669752 669734 666802 669754 669820 669776 669813 669845 669746 669739 669833 666826 669846 669781 666804 666840 669783 666853 669817 669764 666794 669770 666844 669822 669851 669841 666800 669843 666834 669790 669748 666813 669824 669736 669794 669763 669800 666808 669780 669857 669292 666842 669802 666851 669839 669805 669729 669811 669818 669740 669803 669756 666836 669829 666864 666821 669772 669751 669809 669766 666839 669789 669799 669786 669797 669831 669836 669784 661958 was not blocking any bugs. Added blocking bug(s) of 661958: 707065, 707060, 707061, 707066, 707064, 707062, and 707063 > thanks Stopping processing here. Please contact me if you need assistance. -- 661958: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661958 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.13679164261381.transcr...@bugs.debian.org
Bug#661958: [php-maint] Reboot Apache2 2.4 transition
Arno, I have a question on default behaviour of apache2_invoke. If I do: apt-get install libapache2-mod-somemodule a2dismod somemodule apt-get update && apt-get upgrade # libapache2-mod-somemodule gets updated Will that get somemodule reenabled? # Automatically added by dh_apache2 if [ "$1" = "configure" ] && true; then if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then . /usr/share/apache2/apache2-maintscript-helper for conf in wsgi ; do apache2_invoke enmod $conf || exit $? done fi fi You probably need to change the inserted code to: for conf in ; do if [ -z "$2" ]; then apache2_invoke enmod $conf || exit $? else if a2query -q -m $conf; then apache2_reload restart || exit $? fi done (And why there's the "&& true" part?) O. On Sat, May 4, 2013 at 6:12 PM, Arno Töll wrote: > Hi there, > > Now that Wheezy is ehrm virtually released ..., we'd like to reboot the > Apache 2.4 transition process as soon as possible. In other words, we'd > like to break Sid - as far as Apache is involved - in a foreseeable > future. With your permission to proceed as suggested pending, we'd like > to propose this procedure to continue with the Apache 2.4 transition: > > *) Aim for an upload of Apache 2.4 in June. The exact date is not fixed > and determined by two factors: You approving the process itself, and the > availability of a 2.4 port for certain reverse dependencies (see next > point). > > *) Since this upload is going to break all existing module reverse > dependencies, this causes bad breakage to users of Apache in Sid. We're > aware of that, but it can't be avoided entirely since a transition in > Experimental only does not seem to work out that well, as we're trying > to prod the maintainers of affected packages for over a year. > > However, to smoothen the transition as much as possible, we'd like to > wait with an upload to Sid until these reverse dependencies have updated > packages available and then do a coordinated upload with the respective > maintainers (they're all CC:-ed): > > - mod_php > - mod_security > - mod_wsgi > - mod_dnssd (gnome-user-share) > - mod_jk > - mod_fcgid > - subversion > > This is a somewhat biased choice, based on the popularity of the > modules, and their relative importance in the Apache eco-system itself. > PHP, and WSGI for example have reverse dependencies on their own, which > are affected by our transition, too. Please maintainers of these > package, do help us so that we can do the upload in a timely manner. > > Maintainers, if you need help us to transition with these modules, let > the Apache maintainers know. We'll help you. > > *) Once the package is uploaded to Unstable together with a reasonably > small subset of reverse dependencies as defined above, we'd like to > successively increase the amount of transitioned packages to a larger > amount (see the full list in previous posts) before considering a > migration to Testing. > > It is up to decide together with you when exactly this is going to > happen, but I do not suspect this being the case until (end of) summer. > > At some point we'd like to ask you to remove remaining non-transitioned > packages from Testing so that we migrate the already transitioned > packages, including our own. Until then, we'd file a "testing migration > blocking bug" against our own package, so that it can't migrate to > Testing by accident. > > *) Once the package has reached Testing, we'd like to address a > transition of web-applications reverse depending on Apache. This cannot > be parallelized easily, because most of them are depending on some other > third party module, too. On the upside, web applications are somewhat > broken during the migration, but this may only affect the integration of > the Apache web server, whereas the application itself remains functional. > > Does this make sense to you? > > > -- > with kind regards, > Arno Töll > IRC: daemonkeeper on Freenode/OFTC > GnuPG Key-ID: 0x9D80F36D > > > ___ > pkg-php-maint mailing list > pkg-php-ma...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint -- Ondřej Surý -- 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/caljhhg94zhtspaus33vm7vppzkvqcmlsrqoc7n_thjr6vvo...@mail.gmail.com
