Ieraksts vienas debešķīgas sievietes piezīmju blociņā. Nezinu, laikam jau pikants ieraksts.
Teksts vienas lieliskas pežiņas īpašnieces dinčenē: Otrdiena. Es piecēlos ar draiskulīgu sajūtu kājstarpē. Sajutu tādu kā tukšumu sevī. Man trakoti vajadzēja locekli. Lielu un stingru. Ļoti gribējās šim loceklim uzkāpt virsū. Es piepildīju savu vēlmi: http://www.centraltirg.us -- 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/201104070158.p371wjwh011...@vil.com.ua
Ieraksts vienas piselīgas kundzes dienasgrāmatā. Nočeko!
Teksts vienas debešķīgas jaunkundzes dienasgrāmatā: Februāris, 2011. Es izlīdu no gultas ar draiskulīgu sajūtu kājstarpē. Izjutu kaut ko līdzīgu tukšumam sevī. Man trakoti vajadzēja locekli. Lielu un stingru. Ļoti vajadzēja šim loceklim uzkāpt. Mans kaķēns ņaudēja aiz laimes: http://www.vilt.us -- 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/201104070209.p3729fcg009...@mail.quart-soft.com
NEW changes in oldproposedupdates
Processing changes file: vlc_0.8.6.h-4+lenny2.3_amd64.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny2.3_alpha.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny2.3_arm.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny2.3_armel.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny2.3_hppa.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny2.3_i386.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny2.3_ia64.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny2.3_mipsel.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny2.3_powerpc.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny2.3_s390.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny2.3_sparc.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny3_amd64.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny3_alpha.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny3_arm.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny3_armel.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny3_hppa.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny3_i386.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny3_ia64.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny3_mips.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny3_mipsel.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny3_powerpc.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny3_s390.changes ACCEPT Processing changes file: vlc_0.8.6.h-4+lenny3_sparc.changes ACCEPT -- 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/e1q7erx-00081b...@franck.debian.org
NEW changes in proposedupdates
Processing changes file: vlc_1.1.3-1squeeze4_amd64.changes ACCEPT Processing changes file: vlc_1.1.3-1squeeze4_armel.changes ACCEPT Processing changes file: vlc_1.1.3-1squeeze4_i386.changes ACCEPT Processing changes file: vlc_1.1.3-1squeeze4_ia64.changes ACCEPT Processing changes file: vlc_1.1.3-1squeeze4_kfreebsd-amd64.changes ACCEPT Processing changes file: vlc_1.1.3-1squeeze4_kfreebsd-i386.changes ACCEPT Processing changes file: vlc_1.1.3-1squeeze4_mips.changes ACCEPT Processing changes file: vlc_1.1.3-1squeeze4_mipsel.changes ACCEPT Processing changes file: vlc_1.1.3-1squeeze4_powerpc.changes ACCEPT Processing changes file: vlc_1.1.3-1squeeze4_s390.changes ACCEPT Processing changes file: vlc_1.1.3-1squeeze4_sparc.changes ACCEPT -- 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/e1q7eru-00080p...@franck.debian.org
Re: [SRU] non-free/clustalw and non-free/clustalx relicensed to LGPL-3+.
Le Wed, Apr 06, 2011 at 10:44:38PM +0100, Adam D. Barratt a écrit : > > clustalx: 288 files changed, 57040 insertions(+), 40805 deletions(-) > > I think that's far too large a change to be making in stable, even if it > would move the software out of non-free. > > clustalw is a bit better, once the build system noise is removed: > > 36 files changed, 295 insertions(+), 257 deletions(-) > > The changelog isn't exactly verbose as to what those changes represent, > however. Additionally, would the old clustalx continue to work as a GUI > to the new clustalw? > > > However, since the current clustalx and clustalw > > packages are not part of Debian, would it really be considered an upgrade ? > > If it's not an upgrade, then you're asking us to add two completely new > sources packages to a stable release. I can only recall one instance of > that happening in recent years, which was openssh-blacklist and > introduced via the security archive. Hi Adam, First of all, thank you for your answer. I know that I am asking for someting unusual and I am very pleased that you took the time to consider it. Given of how easy it is to use backports (that I can prepare), I think that one of the main points of adding clustalw and clustalx to Stable would be to say a big “thank you” to the upstream developers for freeing their code. Regarding the quality of the clustalw 2.1+lgpl-2 and clustalx 2.1+lgpl-1: - Their previous upstream release, 2.0.12, was uploaded to Debian since October 2009. No RC issues have been found, and the reason why clustalx did not make it in Squeeze related to difficulties with (auto)building on non-free. (This is not a complain). - Most of the diff between 2.0.12 and 2.1.0 is related to autoconf/automake. - clustalx does not need clustalw. They both implement the same algorithm, but… ahem… clustalx contains a copy of clustalw that does not have the necessary autoconf/automake bits to allow building both software from the same upstream tarball. I asked upstream if this could be corrected but their answer is that from 2.1 they want to limit further changes in the 2.x branch to the strict minimum. This is actually is good for us: only bug fixes, no new features. I understand your decision for clustalx. I think that there would still be a benefit to have clustalw in main for Squeeze, in particular for the generation of entirely Free Squeeze derivatives for science. While we offer a large number of alternatives, Clustal W is the reference in its field. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20110407013306.ga8...@merveille.plessy.net
Analysis of the gnome3 transitions
Hi again,
not all modules are ready, but I’ve had a closer look at what the GNOME
3 library transitions imply and how we can deal with their testing
migrations in a sane way.
First of all I think we should upload gtk+3.0 to unstable in the next
days. Together with it we can upload a lot of libraries that are
parallel-installable with their GTK 2.x versions. I don’t expect these
libraries to cause any trouble: their source packages were renamed, we
will just rename them back to remove the gtk2 version when all reverse
dependencies are fixed. Some of them have a -common package that was not
renamed (e.g. libgweather) but the new one should work with both
versions.
Once this is done, we will need slots to organize all transitions that
depend on it, and that makes quite a number of them. I’m not sure the
list is complete, but it should be a good start. I’ll send another mail
if I discover more.
1. libnotify
Once gtk3 is here, we can upload libnotify 0.6. This version is
binary-compatible with 0.5.0, except that it doesn’t depend on a
specific version of GTK+. This is the easy part, but it can be
skipped, since anyway we need a transition:
libnotify1→libnotify4.
Many packages will not build without source changes since
functions were removed, however the source changes are
independent from the GTK+ version. So we only need to ensure
this transition is handled independently from the rest - and
before the rest, since it is a prerequisite for most of the
others.
2. libchamplain
A first transition from 0.4 to 0.8 (still gtk2), with both
source package and binary packages changed, will first be
conducted in unstable. Then 0.10 (which is gtk3) will be handled
the same.
I don’t expect this package to cause trouble, but it will need
to be kept on the radar; depending on the state of this
transition we might have to temporarily disable libchamplain
support in some reverse dependencies.
3. devhelp
It is almost a self-contained transition (devhelp + anjuta).
AFAICT it can be done at any time.
4. gnome-keyring
It is almost a self-contained transition (gnome-keyring +
seahorse). However it needs to be done early because empathy
(involved in other transitions) will need it.
I think we can avoid updating seahorse-plugins at the same time;
if we cannot, we’ll want to disable some of the plugins to avoid
tying it to gedit and/or nautilus.
5. gedit
This transition should be contained within gedit and the
packages providing plugins.
There might be breakage with packages providing extra gedit
plugins together with other functionality, but I prefer to have
them not working for a while rather than tying gedit to a larger
transition.
6. gnome-bluetooth
This one is really fucked up. Upstream didn’t change the API
version with the switch to gtk3, in violation of the GNOME
guidelines.
The only fix I can think of is to rename the source package to
gnome-bluetooth3 and the -dev package to
libgnome-bluetooth8-dev, making it conflict with
libgnome-bluetooth-dev. Then it will take, later, another round
of source uploads to change back the -dev package name.
7. evolution
A big transition is expected for evolution. It involves, as
usual, evolution{-data-server,,-exchange,-rss}. gtkhtml has a
new source package (gtkhtml4.0) which is parallel-installable.
Binary rebuilds are needed for all packages depending on:
libcamel, libebackend, libedata-book, libedata-cal.
The API for libedataserverui has changed, and since it depends
on gtk3 now, we should really provide a way to have both
versions available at the same time. Here is what I propose:
* The new version for the evolution-data-server source
package is named evolution-data-server3.
* The binary package names are not changed; implying
evolution-data-server and -common will be the 3.0
version. However libraries will be
parallel-installable.
* We let both versions into testing.
* Once nothing remains of the old libedataserverui’s rdeps
(and that means after the end of other GNOME
transitions), we remove the old versions from unstable
by re-uploading e-d-s 3.0 with the old source name.
8. gnome-media + gnome-media-profiles
Due to the upstream split between the library and the binary, if
we upload gnome-media 3.x, the gtk2 library will disappear.
We can probably rename the source package to gnome-media3, so
that only the gnome-me
Re: widelands security fix, 617960
On Tue, 2011-03-22 at 21:35 +, Adam D. Barratt wrote: > Thanks for looking at resolving this issue in stable. So far as I can > see, the bug hasn't been fixed in unstable yet? If that's correct then > please upload a new package to unstable first; assuming no problems > related to the patch arise, we can then look at updating stable. The updated package has now reached testing and, so far as I can see, no issues with the patch have been reported; please feel free to go ahead with the stable upload. 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/1302126642.22008.988.ca...@hathi.jungle.funky-badger.org
Re: [SRU] non-free/clustalw and non-free/clustalx relicensed to LGPL-3+.
Hi, Apologies for the delay in getting back to you on this. On Sun, 2011-03-20 at 18:31 +0900, Charles Plessy wrote: > the programs Clustal W and Clustal X have been freed last December and > eventually made their way in Wheezy. I wonder if it would be possible to make > them available in Squeeze, that currently contains the old non-free version. > > The relicensing was done at the same time as a new upstream release, so it > would be an upgrade as well. Quite large upgrades, too :-/ clustalx: 288 files changed, 57040 insertions(+), 40805 deletions(-) I think that's far too large a change to be making in stable, even if it would move the software out of non-free. clustalw is a bit better, once the build system noise is removed: 36 files changed, 295 insertions(+), 257 deletions(-) The changelog isn't exactly verbose as to what those changes represent, however. Additionally, would the old clustalx continue to work as a GUI to the new clustalw? > However, since the current clustalx and clustalw > packages are not part of Debian, would it really be considered an upgrade ? If it's not an upgrade, then you're asking us to add two completely new sources packages to a stable release. I can only recall one instance of that happening in recent years, which was openssh-blacklist and introduced via the security archive. 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/1302126278.22008.965.ca...@hathi.jungle.funky-badger.org
Re: Proposed patch to aptitude in stable to fix a low-impact security bug
On Sun, 2011-04-03 at 07:44 -0700, Daniel Burrows wrote: > The version of aptitude in stable contains a security bug that could > theoretically allow a symlink attack in /tmp. However, it can only be > exploited in a very narrow set of circumstances: the user must have no > home directory, and they must invoke the "hierarchy editor" (an old and > mostly undocumented corner of the curses interface). For this reason, > the security team recommended that I ask -release to put the patch into > a point update, rather than releasing it via the security route. > > I've attached the patch that I'll add to the debian/patches in the > package in stable. > > Please let me know what the next step I need to do is. Also, do you > think it makes sense to patch the package in oldstable? Thanks. That does seem a rather narrow attack vector. :-) Nevertheless, assuming the patch has been tested in a squeeze environment and there aren't any other changes involved, please feel free to upload 0.6.3-3.2+squeeze1 to stable adding that patch. If the same patch also applies to oldstable and has been tested there, then uploading an updated package for lenny would also be okay. 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/1302125204.22008.896.ca...@hathi.jungle.funky-badger.org
Fwd: Bug#616482: strongswan-ikev1: virtual ips not released if xauth name does not match id
Dear stable release team, I have now integrated the cherry-picked upstream patch into my strongswan-sqeeze branch at the alioth git repository (ssh://alioth.debian.org/git/pkg-swan/strongswan.git). As mentioned in the bug report, it applies cleanly and is an isolated fix for a bug in version 4.4.1 that impacts some clients. We will integrate this patched version into our Gibraltar firewall release and will therefore test this package update for regressions within the next few days. I would then prepare an upload to "stable" to make it into squeeze proposed updates. Is this ok for you? If you can't directly look at the strongswan-squeeze git branch, I could send you the most current 4.4.1-7 package diff. best regards, Rene --- Begin Message --- Package: strongswan-ikev1 Version: 4.4.1-5.1 Severity: normal Tags: patch upstream In Strongswan version 4.4.1 as shipped in stable there is a known bug which prevents a virtual ip assigned via mode config to be released if the XAUTH name send from the peer does not match the peers id. Clients which offer no control over which peer id is send or extract it from the certificates subject will not be able to aquire a virtual ip after their first disconnect. One particular example of this peer behaviour are iphones. For theses clients the current strongswan-ikev1 package is not usable with the xauthrsasig method. Upstream has a patch for this at http://git.strongswan.org/?p=strongswan.git;h=2b3124c76d3897bccb4aa616fca1f7393f1b284e The patch applies cleanly to the debian source package and solves the problem described. -- System Information: Debian Release: 6.0 APT prefers squeeze-updates APT policy: (500, 'squeeze-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages strongswan-ikev1 depends on: ii bind9-host [host]1:9.7.2.dfsg.P3-1.1 Version of 'host' bundled with BIN ii bsdmainutils 8.0.13 collection of more utilities from ii debconf [debconf-2.0 1.5.36.1Debian configuration management sy ii debianutils 3.4 Miscellaneous utilities specific t ii iproute 20100519-3 networking and traffic control too ii ipsec-tools 1:0.7.3-12 IPsec tools for Linux ii libc62.11.2-10 Embedded GNU C Library: Shared lib ii libcap2 1:2.19-3support for getting/setting POSIX. ii libstrongswan4.4.1-5.1 strongSwan utility and crypto libr ii strongswan-starter 4.4.1-5.1 strongSwan daemon starter and conf strongswan-ikev1 recommends no packages. Versions of packages strongswan-ikev1 suggests: pn curl (no description available) -- no debconf information --- End Message --- signature.asc Description: This is a digitally signed message part.
Bug#619117: perl 5.12 transition
On Wed, Apr 06, 2011 at 08:21:07PM +0200, Kurt Roeckx wrote: > On Wed, Mar 30, 2011 at 03:34:17PM +0200, Julien Cristau wrote: > > On Wed, Feb 23, 2011 at 07:40:26PM +, Dominic Hargreaves wrote: > > > I would like to register an interest in carrying out a perl transition > > > soon. This would be to perl 5.10.1 to 5.12.x (x = 3 currently). This > > > transition has already been in preparation for some time, and I think > > > we are in a good position to schedule this now. This is the first major > > > transition I've been involved in (I've recently become a co-maintainer > > > of the perl package), so please bear with me if I miss anything out. > > > You can see the transition tracking bugs at [1]. > > > > One thing that came up is that we need to make sure all sid buildd > > chroots have debconf-english installed and not debconf-i18n before that > > happens (debconf-i18n depends on liblocale-gettext-perl, which depends > > on perlapi-5.10.0). Cc:-ing debian-wb-team so this can be handled > > before the perl transition. > > As far as I know all buildds except alkman now have > debconf-english installed. alkman is done now too. Kurt -- 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/20110406183002.ga24...@roeckx.be
Bug#619117: perl 5.12 transition
On Wed, Mar 30, 2011 at 03:34:17PM +0200, Julien Cristau wrote: > On Wed, Feb 23, 2011 at 07:40:26PM +, Dominic Hargreaves wrote: > > I would like to register an interest in carrying out a perl transition > > soon. This would be to perl 5.10.1 to 5.12.x (x = 3 currently). This > > transition has already been in preparation for some time, and I think > > we are in a good position to schedule this now. This is the first major > > transition I've been involved in (I've recently become a co-maintainer > > of the perl package), so please bear with me if I miss anything out. > > You can see the transition tracking bugs at [1]. > > One thing that came up is that we need to make sure all sid buildd > chroots have debconf-english installed and not debconf-i18n before that > happens (debconf-i18n depends on liblocale-gettext-perl, which depends > on perlapi-5.10.0). Cc:-ing debian-wb-team so this can be handled > before the perl transition. As far as I know all buildds except alkman now have debconf-english installed. Kurt -- 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/20110406182107.ga23...@roeckx.be
Bug#621101: transition: db (db4,6, db4.7, db4.8)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition (sorry for double email, I just found the release.debian.org transition bugtracker) Hi, I would like to coordinate reduction of BDB packages since I took the unhappy job (as I could expect) to maintain BDB in Debian after Clint have orphaned them. The main issue which I have encountered (in cyrus-imapd) is that the change from 4.x to 5.x introduces code changes, because the packages check for 4 + something version number. The fix is easy (I can help with that if needed), but it still some work which needs to be done. My suggestion is (going one at the time starting with db4.6): 1) Fill bugreports against all packages linking to db4.Y to upgrade build depends to libdb-dev (>= 5.1) or at least to libdb5.1-dev (which makes later transitions harded). 1a) Optionally link with just -ldb and not -ldbX.Y (linking to specific BDB versions generate a lot of problems, since f.e. cyrus-imapd will happily include 5.1 headers and link to libdb4.7) 2. After some time rebuild the db4.Y to not generate -dev packages, but to keep db4.Y-util package available and increase severity 3. After some time rebuild the db4.Y to not generate libdb4.Y packages, but keep db4.Y-util package available and increase severity of the bug reports to RC Release next stable with just one libdbX.Y-dev (and libdb-dev) and all dbM.N-util which were included in current stable. For stable+2 reduce the number to just two version - current -dev and dbX.Y-util for stable+1 upgrades. I know this could cause a lot of pain, but I think the keeping of X > 2 versions of BDB is not sustainable from a long term PoV. Also any help would be much appreciated, I am already too overloaded, and I took BDB maintainership just because of cyrus-imapd sake, so if there are any other heavy BDB users, please come and join the packaging team (especially if you use BDB transactional mode). Affected packages: db4.6 (first in row): - bind9 (binNMU with small patch needed) dsniff (binNMU OK) guile-db (no upload since 2008) hpsockd (no upload since 2008) isync (nmued, no upload since 2008) libnss-db (nmued, no upload since 2009) mmorph (removed from testing, no upload since 2008) pkspxy (no upload since 2007) qtstalker (no upload since 2008) db4,7: - batv-milter claws-mail dkim-milter dnshistory drac etpan-ng hotkeys httest jabberd2 kolab-cyrus-imapd libetpan memcachedb nmh nvi perl radiusd-livingston skktools sks squidguard db4,8: - apr-util bmf bogofilter cairo-dock-plugins chise-base citadel clisp cyrus-sasl2 dovecot evolution-exchange exim4 ggz-server gridengine heimdal iproute jigdo kdesvn libapache2-mod-perl2 libapache2-mod-qos libdb-ruby libpam-ccreds librcc log4cxx mailavenger moc netatalk nss-updatedb onak opendkim openldap pam perdition php5 poedit python-bsddb3 python2.5 python2.6 python2.7 python3.1 rapidsvn redland rpm sendmail skksearch spamprobe squid3 subversion tcpstat webalizer webdruid xastir xemacs21 O. -- System Information: Debian Release: squeeze/sid APT prefers maverick-updates APT policy: (500, 'maverick-updates'), (500, 'maverick-security'), (500, 'maverick-proposed'), (500, 'maverick-backports'), (500, 'maverick') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35-28-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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/20110406144301.1382.36343.reportbug@localhost6.localdomain6
Re: [PATCH 0/2] powerpc/kexec build failure fixes
On Wed, Apr 06, 2011 at 06:28:49PM +0530, Kamalesh Babulal wrote: > Hi Greg, > > Can you please pull the powerpc build failure fixes > patch series into 2.6.32-stable. No, I don't "pull" any patches into a stable tree. Especially as you didn't even give me a git tree to pull from :) I'll take the patches you emailed and queue them up for the next round of review though, which is what I think you wanted... thanks, greg k-h -- 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/20110406141443.gb20...@kroah.com
[PATCH 0/2] powerpc/kexec build failure fixes
Hi Greg, Can you please pull the powerpc build failure fixes patch series into 2.6.32-stable. Kumar Gala (1): powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code Paul E. McKenney (1): powerpc: Fix default_machine_crash_shutdown #ifdef botch arch/powerpc/kernel/crash.c |4 1 files changed, 4 insertions(+), 0 deletions(-) -- 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/20110406125849.gj28...@linux.vnet.ibm.com
[PATCH 2/2] powerpc: Fix default_machine_crash_shutdown #ifdef botch
powerpc: Fix default_machine_crash_shutdown #ifdef botch Commit: c2be05481f6125254c45b78f334d4dd09c701c82 upstream crash_kexec_wait_realmode() is defined only if CONFIG_PPC_STD_MMU_64 and CONFIG_SMP, but is called if CONFIG_PPC_STD_MMU_64 even if !CONFIG_SMP. Fix the conditional compilation around the invocation. Reported-by: Ben Hutchings Signed-off-by: Paul E. McKenney Acked-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Kamalesh Babulal cc: Anton Blanchard --- arch/powerpc/kernel/crash.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c index 4de36b8..5009198 100644 --- a/arch/powerpc/kernel/crash.c +++ b/arch/powerpc/kernel/crash.c @@ -447,7 +447,7 @@ void default_machine_crash_shutdown(struct pt_regs *regs) crash_kexec_prepare_cpus(crashing_cpu); cpu_set(crashing_cpu, cpus_in_crash); crash_kexec_stop_spus(); -#ifdef CONFIG_PPC_STD_MMU_64 +#if defined(CONFIG_PPC_STD_MMU_64) && defined(CONFIG_SMP) crash_kexec_wait_realmode(crashing_cpu); #endif if (ppc_md.kexec_cpu_down) -- 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/20110406130448.gl28...@linux.vnet.ibm.com
[PATCH 1/2] powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code
powerpc/kexec: Add ifdef CONFIG_PPC_STD_MMU_64 to PPC64 code
This patch introduces PPC64 specific #ifdef bits from the upstream
commit: b3df895aebe091b1657a42a8c859bd49fc96646b.
Reported-and-tested-by: dann frazier
Signed-off-by: Kumar Gala
Signed-off-by: Kamalesh Babulal
cc: Benjamin Herrenschmidt
cc: Anton Blanchard
---
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index fe02e71..4de36b8 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -163,6 +163,7 @@ static void crash_kexec_prepare_cpus(int cpu)
}
/* wait for all the CPUs to hit real mode but timeout if they don't come in */
+#ifdef CONFIG_PPC_STD_MMU_64
static void crash_kexec_wait_realmode(int cpu)
{
unsigned int msecs;
@@ -187,6 +188,7 @@ static void crash_kexec_wait_realmode(int cpu)
}
mb();
}
+#endif
/*
* This function will be called by secondary cpus or by kexec cpu
@@ -445,7 +447,9 @@ void default_machine_crash_shutdown(struct pt_regs *regs)
crash_kexec_prepare_cpus(crashing_cpu);
cpu_set(crashing_cpu, cpus_in_crash);
crash_kexec_stop_spus();
+#ifdef CONFIG_PPC_STD_MMU_64
crash_kexec_wait_realmode(crashing_cpu);
+#endif
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(1, 0);
}
--
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/20110406130145.gk28...@linux.vnet.ibm.com
Processed: block 617272 with 621045
Processing commands for cont...@bugs.debian.org: > block 617272 with 621045 Bug #617272 [release.debian.org] transition: python3-defaults Was not blocked by any bugs. Added blocking bug(s) of 617272: 621045 > thanks Stopping processing here. Please contact me if you need assistance. -- 617272: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617272 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.130208328430332.transcr...@bugs.debian.org
NEW changes in proposedupdates
Processing changes file: iceape_2.0.11-4_amd64.changes ACCEPT Processing changes file: iceape_2.0.11-4_armel.changes ACCEPT Processing changes file: iceape_2.0.11-4_i386.changes ACCEPT Processing changes file: iceape_2.0.11-4_ia64.changes ACCEPT Processing changes file: iceape_2.0.11-4_kfreebsd-amd64.changes ACCEPT Processing changes file: iceape_2.0.11-4_kfreebsd-i386.changes ACCEPT Processing changes file: iceape_2.0.11-4_mips.changes ACCEPT Processing changes file: iceape_2.0.11-4_mipsel.changes ACCEPT Processing changes file: iceape_2.0.11-4_powerpc.changes ACCEPT Processing changes file: iceape_2.0.11-4_s390.changes ACCEPT Processing changes file: iceape_2.0.11-4_sparc.changes ACCEPT -- 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/e1q7nce-0002m8...@franck.debian.org
Re: Openssl 1.0.0
On Wed, Apr 06, 2011 at 12:45:03AM +0200, Julien Cristau wrote: > On Sun, Feb 13, 2011 at 00:27:51 +0100, Kurt Roeckx wrote: > > > Hi, > > > > I would like to upload version 1.0.0(d) to unstable soon. It > > changes soname, but as far as I know the API is still compatible > > with the old one, and you should be able to rebuild everything > > against the new version. > > > So this is started now. Most packages should be fine because we keep > libssl0.9.8 around for a while. However, the udeb needed for openssh is > going away, which means we'd need to migrate openssl, openssl098 and > openssh together to testing. That might not work out because of > #612607, which Colin says nobody knows how to fix yet. > > I can see two ways out. One is ignoring the bug and getting the new > openssh in testing anyway. The other is to force libcrypto0.9.8-udeb to > stay in testing for now. Please pick one (or an alternative I'm not > thinking of). :) Or re-introduce libcrypto0.9.8-udeb as part of the openssl098 source package. Kurt -- 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/20110406071054.ga20...@roeckx.be
