Re: [Dolfin] Please binNMU python-ufc against latest swig
On Wed, Jun 13, 2012 at 10:38 PM, Anders Logg l...@simula.no wrote: Does it work if you remove those checks in dolfin/site-packages/dolfin/compilemodules/compilemodule.py dolfin/site-packages/dolfin/compilemodules/jit.py ? Yes, it works fine, but I also had to remove the check in ufc_utils/build.py in UFC. If so, we might turn those into warnings. Yes, maybe that is a good idea. Johannes -- 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/CALjQY_F2k4HdJ==ckxsfkczqcbu5ptyzau+ogpeaykn-yub...@mail.gmail.com
Bug#672820: transition: libcdio
On Wed, Jun 13, 2012 at 09:08:48PM +0200, Julien Cristau wrote: Thanks for your patience. It should be fine to go ahead now. #676100 will need to be fixed, but that may just mean dropping the libxmmsclient-ruby* packages. Ok, thanks. I just uploaded libcdio 0.83-4 to unstable. Cheers, -- Nicolas -- 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/20120614083207.gb2...@tryphon.debian.net
Bug#676906: marked as done (nmu: atlas_3.8.4-6)
Your message dated Thu, 14 Jun 2012 11:22:25 +0200 with message-id 87txyedz8u@karaba.cepremap.org and subject line Re: Bug#676906: nmu: atlas_3.8.4-6 has caused the Debian Bug report #676906, regarding nmu: atlas_3.8.4-6 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 676906: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676906 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu The package for amd64 has apparently been built with a too recent and specific CPU architecture, leading to Illegal instructions on many recent Intel Core CPUs. A rebuild fixes the problem. nmu atlas_3.8.4-6 . amd64 . -m Rebuild with a more generic x86_64 CPU architecture (Closes: #676885) Thanks, -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (600, 'unstable'), (550, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ---End Message--- ---BeginMessage--- Closing, a new source package has been uploaded. -- Sébastien Villemot Researcher in Economics Debian Maintainer http://www.dynare.org/sebastien Phone: +33-1-40-77-84-04 - GPG Key: 4096R/381A7594 pgpLYFS8xXbTd.pgp Description: PGP signature ---End Message---
Re: Haskell status summary
On 12/06/2012 22:49, Joachim Breitner wrote: A) Upload the fixed haskell-cryptocipher to unstable, let it build on mips, s390, s390x and sparc, remove stuff on powerpc, migrate. B) Remove stuff on mips, powerpc, s390, s390x and sparc, migrate. FTR, a solution smilar to B has been chosen (i.e. temporarily remove affected source packages from testing to let ghc migrate) and ghc migrated. I’m leaning towards A or B to get the migration done and only then consider GHC 7.4.2. I'm afraid we won't have enough time to get GHC 7.4.2 in but we would consider accepting targeted fixes (that do not require rebuilding the Haskell world). Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4fd9bb50.60...@dogguy.org
Bug#677502: unblock: lv2file/0.83-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package lv2file, it does no longer build on non-Linux due to the lack of support for those architectures in lilv. unblock lv2file/0.83-1 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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/20120614110310.21704.65642.reportbug@alessio-laptop
Bug#677502: unblock: lv2file/0.83-1
Hello, Alessio Treglia ales...@debian.org (14/06/2012): Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package lv2file, it does no longer build on non-Linux due to the lack of support for those architectures in lilv. unblock lv2file/0.83-1 1. It is not blocked. 2. You need to get those binary packages removed. 3. For that you file a bug (or reassign this one) against ftp.debian.org http://wiki.debian.org/ftpmaster_Removals Mraw, KiBi. signature.asc Description: Digital signature
Bug#677502: unblock: lv2file/0.83-1
On Thu, Jun 14, 2012 at 1:10 PM, Cyril Brulebois k...@debian.org wrote: 1. It is not blocked. 2. You need to get those binary packages removed. 3. For that you file a bug (or reassign this one) against ftp.debian.org Done, thanks and sorry for the noise. Cheers! -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer | quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- 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/CAMHuwoxur65VCpBV3+E9o5PVdfKW6a+W9wBAV=x9qh3eysq...@mail.gmail.com
Bug#677502: unblock: lv2file/0.83-1
On 14/06/12 12:10, Cyril Brulebois wrote: Alessio Treglia ales...@debian.org (14/06/2012): [...] unblock lv2file/0.83-1 [...] 2. You need to get those binary packages removed. Or it's new dependency, lilv, just needs porting to kFreeBSD, then lv2file will probably build there again? The issue with lilv looks fixable but could be a swig bug so it could take a while. A search for a file called 'lilv' in its include paths results in opening the '../lilv' directory on non-Linux, and junk is read from it. https://buildd.debian.org/status/package.php?p=lilvsuite=sid 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/4fd9cf51.5000...@pyro.eu.org
Re: [Dolfin] Please binNMU python-ufc against latest swig
On 06/14/2012 09:46 AM, Johannes Ring wrote: On Wed, Jun 13, 2012 at 10:38 PM, Anders Loggl...@simula.no wrote: Does it work if you remove those checks in dolfin/site-packages/dolfin/compilemodules/compilemodule.py dolfin/site-packages/dolfin/compilemodules/jit.py ? Yes, it works fine, but I also had to remove the check in ufc_utils/build.py in UFC. If so, we might turn those into warnings. Not sure why we would like to do that? If we are going to ship precompiled binaries we better make sure all packages including JIT compiled stuff are using the same SWIG version. We have not got any reports of this not working (because we have prevented it), but I think it would be gambling to allow this. If an error occur it will most probably be very cryptic and implode the user experience. Can't this be handled by some elaborated debain version logic? Johan Yes, maybe that is a good idea. Johannes ___ Mailing list: https://launchpad.net/~dolfin Post to : dol...@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp -- 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/4fd9cef4.7040...@gmail.com
Re: [Dolfin] Please binNMU python-ufc against latest swig
On Thu, Jun 14, 2012 at 1:45 PM, Johan Hake hake@gmail.com wrote: On 06/14/2012 09:46 AM, Johannes Ring wrote: On Wed, Jun 13, 2012 at 10:38 PM, Anders Loggl...@simula.no wrote: Does it work if you remove those checks in dolfin/site-packages/dolfin/compilemodules/compilemodule.py dolfin/site-packages/dolfin/compilemodules/jit.py ? Yes, it works fine, but I also had to remove the check in ufc_utils/build.py in UFC. If so, we might turn those into warnings. Not sure why we would like to do that? If we are going to ship precompiled binaries we better make sure all packages including JIT compiled stuff are using the same SWIG version. We have not got any reports of this not working (because we have prevented it), but I think it would be gambling to allow this. If an error occur it will most probably be very cryptic and implode the user experience. Good point. Can't this be handled by some elaborated debain version logic? The simplest solution would be to rebuild UFC and DOLFIN whenever a new version of SWIG is added in Debian. That's why i requested a binNMU. Not sure if it would be possible to automate this in some way. Johannes -- 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/caljqy_fu4svhccgznqf+xv3n3p6xkboexcbump0muubtau_...@mail.gmail.com
Bug#666126: transition: poppler 0.18
On Mon, Jun 04, 2012 at 12:21:28AM +0200, Cyril Brulebois wrote: [...] Did that on all archictectures: kibi@grieg:~$ wb nmu apvlv calibre cups-filters epdfview gdcm gimp gle-graphics gnome-commander gpdftext gummi inkscape libextractor pdf-presenter-console pdf2djvu pdf2svg pdfcube pdftoipe python-poppler referencer tracker tumbler webkit2pdf xournal xpdf zathura . ALL . -m 'Rebuild for the poppler transition.' Seems rebuild has triggered http://bugs.debian.org/677345 Should I wait until poppler 0.18 transition ends or should I upload the fix right now? regards, -- Ricardo Mones ~ The three principal virtues of a programmer are Laziness, Impatience, and Hubris.man perl signature.asc Description: Digital signature
Please allow tclvfs to testing
Hi! I've renamed tclvfs binary package to tcl-vfs, and now it cannot pass to testing because of the old tclvfs binary packages there. Could someone hint it to go to testing? -- Sergei Golovan -- 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/caoq2pxhjkjdz8so4gsj2nzzadn9izysrcznfcxpo9wssqka...@mail.gmail.com
Re: Please allow tclvfs to testing
On 2012-06-14 14:58, Sergei Golovan wrote: Hi! I've renamed tclvfs binary package to tcl-vfs, and now it cannot pass to testing because of the old tclvfs binary packages there. Could someone hint it to go to testing? Hi, You need to get the old binaries removed by the ftp-masters in unstable. Usuaully, the old binaries are automatically discovered if there are no reverse (build-)dependencies, but dak reports visual-regexp as being possibly broken by this (I haven't investigated why). ~Niels -- 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/4fd9e45d.3000...@thykier.net
Re: Please allow tclvfs to testing
On Thu, Jun 14, 2012 at 5:17 PM, Niels Thykier ni...@thykier.net wrote: You need to get the old binaries removed by the ftp-masters in unstable. Usuaully, the old binaries are automatically discovered if there are no reverse (build-)dependencies, but dak reports visual-regexp as being possibly broken by this (I haven't investigated why). It depends on tclvfs, but the dependency is not versioned, so it should work with the new tcl-vfs too (tcl-vfs provides tclvfs). Okay, I'll file a bug for ftp.debian.org. Thank you. -- Sergei Golovan -- 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/caoq2pxg6fjhcng5vt2vvky0ckevy_7mzzaj6whyms-020so...@mail.gmail.com
Bug#666126: transition: poppler 0.18
Hi Ricardo! Alle giovedì 14 giugno 2012, Ricardo Mones ha scritto: Seems rebuild has triggered http://bugs.debian.org/677345 Should I wait until poppler 0.18 transition ends or should I upload the fix right now? poppler 0.18 migrated to testing, so you can go ahead in fixing that (and #677521 too, please? ;) ). Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#666126: transition: poppler 0.18
On Thu, Jun 14, 2012 at 04:06:48PM +0200, Pino Toscano wrote: Hi Ricardo! Alle giovedì 14 giugno 2012, Ricardo Mones ha scritto: Seems rebuild has triggered http://bugs.debian.org/677345 Should I wait until poppler 0.18 transition ends or should I upload the fix right now? poppler 0.18 migrated to testing, so you can go ahead in fixing that Alright, tracker was/is at 94%, so I thought it wasn't finished... (and #677521 too, please? ;) ). Yep, saw that too :) thanks, -- Ricardo Mones ~ The three principal virtues of a programmer are Laziness, Impatience, and Hubris.man perl signature.asc Description: Digital signature
Bug#664681: transition: KDE's 4.8 release of platform, applications and workspace
Alle domenica 10 giugno 2012, Adam D. Barratt ha scritto: On Sat, 2012-06-09 at 22:52 +0200, Pino Toscano wrote: A kde-workspace4.8 tracker would be nice, at least for the few workspace libraries that bumped soname: * kde-workspace-dev/kdebase-workspace-dev (src:kde-workspace): libkwineffects1abi2 - libkwineffects1abi3 libkworkspace4 - libkworkspace4abi1 libplasmaclock4abi2 - libplasmaclock4abi3 libtaskmanager4abi2 - libtaskmanager4abi3 Added at URL:http://release.debian.org/transitions/html/kde-workspace4.8.html . Thanks for this. There's quite a few unknowns on there, but the good/bad appear to map to your list of affected packages. It is fine, since kde-workspace provides other libraries and kde(base)-workspace-dev installs all of them, and only few of those had SONAME bumps. The third party sources affected are the following: apper kdenetwork (**) kshutdown (*) ktorrent plasma-widget-adjustableclock plasma-widget-fastuserswitch plasma-widget-smooth-tasks (*) (*) fails to compile with the newer workspace API Is there a plan for getting kshutdown and p-w-smooth-tasks fixed or removed? They are leaf packages so they can be always hinted out of testing until they get fixes. - kshutdown has not been handled yet, we will do so soon - plasma-widget-smooth-tasks is getting an update to a forked version of it (since the original seems to not be developed lately...) the rest of the sources (those without */**) can be binNMUed now, I think (as kde-workspace compiled everywhere in release archs at least). Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: Bug#675207: [Dolfin] Please binNMU python-ufc against latest swig
On Thu, Jun 14, 2012 at 14:19:21 +0200, Johannes Ring wrote: The simplest solution would be to rebuild UFC and DOLFIN whenever a new version of SWIG is added in Debian. That's why i requested a binNMU. Not sure if it would be possible to automate this in some way. If dolfin only works with the version of swig it was built against, that needs to be reflected in the package dependencies. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- 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/20120614144635.gb...@crater1.logilab.fr
qemu-kvm and wheezy
Hello. Since the wheezy freeze is nearby, I wanted to notify the Release Team about possible issue with qemu-kvm package. Currently, wheezy has version 1.0 of qemu-kvm, which contains quite a few bugs fixed in next version, which is 1.1. But the problem is that, due to a few last-minute regressions, qemu-kvm 1.1 hasn't been released yet, even if qemu, which qemu-kvm follows closely, has been released more than 2 weeks ago. I pretty much hope to have qemu-kvm 1.1 in wheezy. This version fixes a few bugs already, which will be difficult to backport into 1.0 version. But the most important issue is to keep maintaining 1.0 version over extended period of time (during whole wheezy support period), when upstream abandomed it already. Currently, qemu-kvm package based on upstream qemu-kvm 1.1 releaase candidate is available in experimental. Experimental because there's still no official release of upstream 1.1, as noted above. So, I hope to have qemu-kvm 1.1 in wheezy, but I'm not quite sure yet when it will be available upstream, and it may happen after the freeze. And it'd be nice to be able to upload new upstream source version when it's ready (since current version in experimental uses non-existing upstream source, an orig.tar.gz made by me out of 1.1-rc4.tar.gz and current git stable). Should I upload whatever we have now to unstable instead of experimental? Should I just wait for the next official release and upload at that time? Or should I just keep 1.0 in wheezy? Is there other alternative? I thought it's not a bad idea to ask, so that the release team is at leaat aware of the possible issue there. But on the other hand, this close to the freeze, release team should be quite busy already... Thanks, /mjt -- 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/4fd9fc84.3050...@msgid.tls.msk.ru
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Fri, Jun 8, 2012 at 6:17 PM, Philipp Kern wrote: On Sat, Jun 09, 2012 at 04:36:40AM +0800, Aron Xu wrote: Does this mean M-A:same packages should be prevented from being binNMUed, but only source upload can be accepted? You cannot deprive the Release Team of this tool. Also multiarch bugs are IMHO at most important, not serious. Possibly we could allow one last sourceful upload when the transitions all settled, but it would again increase the review load on the release team. IMHO it's on the if it works, fine, if not, sorry about that part of the list, given that it was finalized so late, with that critical piece missing. Wouldn't the ideal solution be non-architecture-specific changelogs? So, a normal binnmu changelog looks like this now: package (version) sid; urgency=low * Binary-only non-maintainer upload for amd64; no source changes. -- amd64 Builddd Daemon (barber) buildd_amd64-bar...@buildd.debian.org Tue, 05 Jun 2012 16:33:05 + which could be changed to something like this instead: package (version) sid; urgency=low * Binary-only non-maintainer upload; no source changes. -- Debian Release Team debian-release@lists.debian.org Tue, 05 Jun 2012 16:33:05 + or some other appropriate binnmu mailing address. This would also mean rebuilding all of the other architectures for multi-arch same packages so that they all get the same changelog. Best wishes, Mike -- 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/CANTw=mpzr8wmwtrg4geqe5tscxhavcbiceny1wnp0zutf_c...@mail.gmail.com
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
Michael Gilbert mgilb...@debian.org (14/06/2012): package (version) sid; urgency=low * Binary-only non-maintainer upload; no source changes. -- Debian Release Team debian-release@lists.debian.org Tue, 05 Jun 2012 16:33:05 + or some other appropriate binnmu mailing address. This would also mean rebuilding all of the other architectures for multi-arch same packages so that they all get the same changelog. No, binNMUs numbers can be different, along with timestamps (even with: “wb nmu foo . ALL . -m 'Rebuild for foo.'”, architectures are processed one after each other). Also, reasons can be different. Mraw, KiBi. signature.asc Description: Digital signature
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Thu, Jun 14, 2012 at 12:40 PM, Cyril Brulebois wrote: Michael Gilbert mgilb...@debian.org (14/06/2012): package (version) sid; urgency=low * Binary-only non-maintainer upload; no source changes. -- Debian Release Team debian-release@lists.debian.org Tue, 05 Jun 2012 16:33:05 + or some other appropriate binnmu mailing address. This would also mean rebuilding all of the other architectures for multi-arch same packages so that they all get the same changelog. No, binNMUs numbers can be different, along with timestamps (even with: “wb nmu foo . ALL . -m 'Rebuild for foo.'”, architectures are processed one after each other). Also, reasons can be different. Right, I imagine it will involving reworking of quite a few steps in the process, and again this would be only for 'multi-arch: same'. So, instead of the buildd (or wherever that is done now) creating the changelog/timestamp, instead create one 'multi-arch: same' changelog before passing it off to the buildds, and then after the build is done, replace the automatically architecture-specific changelog with the 'multi-arch: same' one. The reason for rebuilding a 'multi-arch: same' package by definition should be for the same reason on all architectures, right? Non 'multi-arch: same' binnmus would not need to change. Best wishes, Mike -- 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/CANTw=mpnlz6gvczq2scfyzvzu_qvtn_s9ab7+i9kbjozled...@mail.gmail.com
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Thu, Jun 14, 2012 at 12:25:42 -0400, Michael Gilbert wrote: Wouldn't the ideal solution be non-architecture-specific changelogs? No, that would be very much non-ideal. One should be able to schedule binNMUs for a subset of archs, and one shouldn't have to look up whether a package builds m-a:same binaries. This has been said a few times already, please drop this thread if you're just going to repeat old shot-down ideas. Thanks, Julien -- 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/20120614170704.gz12...@radis.cristau.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Thu, Jun 14, 2012 at 1:07 PM, Julien Cristau jcris...@debian.org wrote: On Thu, Jun 14, 2012 at 12:25:42 -0400, Michael Gilbert wrote: Wouldn't the ideal solution be non-architecture-specific changelogs? No, that would be very much non-ideal. One should be able to schedule binNMUs for a subset of archs, I did not suggest that. Anyway, maybe this will be a bit clearer. Let's say an existing package is at version +b1 on amd64, and it needs to get a binnmu, then a +b2 package is built on amd64, its changelog is taken and stuffed it into all of the other 'Multi-Arch: same' +b1 packages, which are now called +b2, and all of them uploaded. Those other architectures didn't undergo a rebuild, but nevertheless, they got new packages. Then lets say a +b3 is needed on i386, then the same is done, and the 'Multi-arch: same' amd64 package (and others) get stuffed with the i386 +b3 changes (which includes the prior amd64 +b2 changelog). and one shouldn't have to look up whether a package builds m-a:same binaries. This is a new special case that will need to be handled somehow, right? Look-ups are not that expensive; although admittedly the time spent writing the infrastructure supporting may not be. Best wishes, Mike -- 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/CANTw=MM=NcxfT-kRLtXoA_7_nX+mJRrxW+4vc7eZYenwSn3=u...@mail.gmail.com
Re: Status of suhosin in Debian
On 06/12/2012 04:22 AM, Alexander Wirt wrote: Therefore the php maintainers decided to drop the patch from the 5.3 packaging a few months ago (there were also some bugs and slowdowns with the patch) [1]. Isn't it possible to disable these slowdowns with environment values, as the suhosin author suggested? This could be the default setup... On 06/12/2012 04:27 AM, Ondřej Surý wrote: +1 from /me on not releasing suhosin in wheezy... Ondřej Surý I'd like to highlight Ondrej's impressive work maintaining PHP mostly alone. If someone wants to oppose to his view, then than someone also needs to stand up and do the work of adding suhosin support AND supporting it for the life of Wheezy. That being said, I'll have a go in trying to influence Ondrej on the other direction! ;) Who care's about Suhosin's author relation with upstream if his work is useful? Let them fight each other if they feel it's needed. Ondrej, is your plan still to leave suhosin as a build option in the source package like you wrote early last February, so that those who want it can just switch that option and rebuild? I can see in the debian/rules that there's still: # Set this flag to 'yes' if you want to compile PHP5 with suhosin patch PHP5_SUHOSIN=no Does this mean that the suhosin patch still works in current php 5.4 package? Or is this still something remaining fro the php 5.3 packaging? Would it be feasible to build twice PHP, once with the suhosin patch, and once without, and build 2 debian binaries? If yes, how much work would this be? Does this mean building 3 more binaries, like: libapache2-mod-php5-suhosin, php5-cli-suhosin, php5-cgi-suhosin? Would it slow down a lot the package building process? Thanks again, Ondrej, for your work of packaging PHP, Thomas -- 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/4fda2f8c.1090...@debian.org
*no* transition of miniupnpc and nusoap
Hi, I am willingly avoiding to ask for transitions of both the miniupnpc library, and PHP nusoap, in order to not break things before the freeze. I don't think there's any major feature or bug fixes that would need such pain. If anyone thinks this is a bad decision, and that we should rush to change things before Wheezy, please let me know (and the release team). Note that both have been sitting in Experimental for quite some time, so anyone willing to test with them are welcome. My plan is to upload them to SID as soon as Wheezy is released (after of course, asking for a transition). Cheers, Thomas -- 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/4fda2fc7.5000...@debian.org
Bug#677554: RM: libvirtuoso5.5-cil old binary package for s390
Package: release.debian.org Severity: normal Hello, at the moment the package libvirtuoso5.5-cil isn't being built for s390 since mono isn't being built for s390 as well, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657781 Therefore could you please remove the binary package libvirtuoso5.5-cil for s390? It's blocking the virtuoso transition to testing. Thank you for your time. signature.asc Description: This is a digitally signed message part.
Stable update for xen
Hi
I'd like to fix an boot error of Xen on several newer machines in
stable.
xen (4.0.1-6) UNRELEASED; urgency=low
[ Ian Campbell ]
* Backport fix to remove lowmem 1:1 mapping that fixes boot on some
classes of machines. (Closes: #649923)
-- Bastian Blank wa...@debian.org Thu, 14 Jun 2012 20:27:03 +0200
Bastian
--
Even historians fail to learn from history -- they repeat the same mistakes.
-- John Gill, Patterns of Force, stardate 2534.7
diff -Nru xen-4.0.1/debian/changelog xen-4.0.1/debian/changelog
--- xen-4.0.1/debian/changelog 2012-06-12 11:37:47.0 +0200
+++ xen-4.0.1/debian/changelog 2012-06-14 20:27:57.0 +0200
@@ -1,3 +1,11 @@
+xen (4.0.1-6) UNRELEASED; urgency=low
+
+ [ Ian Campbell ]
+ * Backport fix to remove lowmem 1:1 mapping that fixes boot on some
+classes of machines. (Closes: #649923)
+
+ -- Bastian Blank wa...@debian.org Thu, 14 Jun 2012 20:27:03 +0200
+
xen (4.0.1-5) stable-security; urgency=low
* Fix privilege escalation and syscall/sysenter DoS while using
diff -Nru xen-4.0.1/debian/control.md5sum xen-4.0.1/debian/control.md5sum
--- xen-4.0.1/debian/control.md5sum 2012-06-12 11:40:53.0 +0200
+++ xen-4.0.1/debian/control.md5sum 2012-06-14 20:31:20.0 +0200
@@ -1,4 +1,4 @@
-e4419cdb21f9d69ca0ba7c65513b4315 debian/changelog
+6a070480a54a79a74d6623a07ff8beb7 debian/changelog
24f2598a23e30264aea4a983d5d19eec debian/bin/gencontrol.py
ee1ccd7bf0932a81ca221cab08347614 debian/templates/control.hypervisor.in
e4335ab10e217a12328cdf123473ed37 debian/templates/control.main.in
diff -Nru xen-4.0.1/debian/patches/series xen-4.0.1/debian/patches/series
--- xen-4.0.1/debian/patches/series 2012-06-12 10:02:17.0 +0200
+++ xen-4.0.1/debian/patches/series 2012-06-14 20:26:44.0 +0200
@@ -71,5 +71,6 @@
upstream-21461:ee088a0b5cb8-CVE-2011-1166
upstream-21482:c2adc059e931-CVE-2011-1583
upstream-21485:b85a9e58ec3a-CVE-2011-1898
+upstream-22375:426f3a265784
CVE-2012-0217+2012-0218
CVE-2012-2934
diff -Nru xen-4.0.1/debian/patches/upstream-22375:426f3a265784
xen-4.0.1/debian/patches/upstream-22375:426f3a265784
--- xen-4.0.1/debian/patches/upstream-22375:426f3a2657841970-01-01
01:00:00.0 +0100
+++ xen-4.0.1/debian/patches/upstream-22375:426f3a2657842012-06-14
20:26:16.0 +0200
@@ -0,0 +1,1094 @@
+# HG changeset patch
+# User Keir Fraser k...@xen.org
+# Date 1289303389 0
+# Node ID 426f3a2657844cec77ce0043b0408b0887fafa41
+# Parent 9997a1418633c92286189b33f701ecbac2a98ccd
+x86: do away with the boot time low-memory 1:1 mapping
+
+By doing so, we're no longer restricted to be able to place all boot
+loader modules into the low 1Gb/4Gb (32-/64-bit) of memory, nor is
+there a dependency anymore on where the boot loader places the
+modules.
+
+We're also no longer restricted to copy the modules into a place below
+4Gb, nor to put them all together into a single piece of memory.
+
+Further it allows even the 32-bit Dom0 kernel to be loaded anywhere in
+physical memory (except if it doesn't support PAE-above-4G).
+
+Signed-off-by: Jan Beulich jbeul...@novell.com
+
+Index: xen-4.0.1/xen/arch/x86/boot/Makefile
+===
+--- xen-4.0.1.orig/xen/arch/x86/boot/Makefile 2010-08-29 17:13:22.0
+0200
xen-4.0.1/xen/arch/x86/boot/Makefile 2011-11-25 16:24:33.0
+0100
+@@ -4,6 +4,6 @@
+
+ BOOT_TRAMPOLINE := $(shell sed -n
's,^\#define[[:space:]]\{1\,\}BOOT_TRAMPOLINE[[:space:]]\{1\,\},,p'
$(BASEDIR)/include/asm-x86/config.h)
+ %.S: %.c
+- RELOC=$(BOOT_TRAMPOLINE) XEN_BITSPERLONG=$(patsubst
x86_%,%,$(TARGET_SUBARCH)) $(MAKE) -f build32.mk $@
++ RELOC=$(BOOT_TRAMPOLINE) $(MAKE) -f build32.mk $@
+
+ reloc.S: $(BASEDIR)/include/asm-x86/config.h
+Index: xen-4.0.1/xen/arch/x86/boot/build32.mk
+===
+--- xen-4.0.1.orig/xen/arch/x86/boot/build32.mk2010-08-29
17:13:22.0 +0200
xen-4.0.1/xen/arch/x86/boot/build32.mk 2011-11-25 16:24:33.0
+0100
+@@ -19,6 +19,6 @@
+ $(LD) $(LDFLAGS_DIRECT) -N -Ttext $(RELOC) -o $@ $
+
+ %.o: %.c
+- $(CC) $(CFLAGS) -DXEN_BITSPERLONG=$(XEN_BITSPERLONG) -c $ -o $@
++ $(CC) $(CFLAGS) -c $ -o $@
+
+ reloc.o: $(BASEDIR)/include/asm-x86/config.h
+Index: xen-4.0.1/xen/arch/x86/boot/head.S
+===
+--- xen-4.0.1.orig/xen/arch/x86/boot/head.S2010-08-29 17:13:22.0
+0200
xen-4.0.1/xen/arch/x86/boot/head.S 2011-11-25 16:24:33.0 +0100
+@@ -110,12 +110,15 @@
+ /* Initialise L2 identity-map and xen page table entries (16MB). */
+ mov $sym_phys(l2_identmap),%edi
+ mov $sym_phys(l2_xenmap),%esi
++mov $sym_phys(l2_bootmap),%edx
+ mov $0x1e3,%eax /* PRESENT+RW+A+D+2MB+GLOBAL */
+ mov $8,%ecx
+
Bug#677554: RM: libvirtuoso5.5-cil old binary package for s390
reassign 677554 ftp.debian.org retitle 677554 RM: libvirtuoso5.5-cil [s390] -- RoM; ANAIS thanks On Thu, 2012-06-14 at 20:45 +0200, José Manuel Santamaría Lema wrote: At the moment the package libvirtuoso5.5-cil isn't being built for s390 since mono isn't being built for s390 as well, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657781 Therefore could you please remove the binary package libvirtuoso5.5-cil for s390? It's blocking the virtuoso transition to testing. We can't, no; you need the package removing from unstable, which is the FTP team's domain. Reassigning. 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/1339699797.19699.3.ca...@jacala.jungle.funky-badger.org
Processed: Re: Bug#677554: RM: libvirtuoso5.5-cil old binary package for s390
Processing commands for cont...@bugs.debian.org: reassign 677554 ftp.debian.org Bug #677554 [release.debian.org] RM: libvirtuoso5.5-cil old binary package for s390 Bug reassigned from package 'release.debian.org' to 'ftp.debian.org'. Ignoring request to alter found versions of bug #677554 to the same values previously set Ignoring request to alter fixed versions of bug #677554 to the same values previously set retitle 677554 RM: libvirtuoso5.5-cil [s390] -- RoM; ANAIS Bug #677554 [ftp.debian.org] RM: libvirtuoso5.5-cil old binary package for s390 Changed Bug title to 'RM: libvirtuoso5.5-cil [s390] -- RoM; ANAIS' from 'RM: libvirtuoso5.5-cil old binary package for s390' thanks Stopping processing here. Please contact me if you need assistance. -- 677554: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677554 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.13396998736524.transcr...@bugs.debian.org
Re: Stable update for xen
On Thu, 2012-06-14 at 20:51 +0200, Bastian Blank wrote: I'd like to fix an boot error of Xen on several newer machines in stable. I'm assuming this is fixed in at least unstable already, given the dates of the commits referenced in the bug report? xen (4.0.1-6) UNRELEASED; urgency=low [ Ian Campbell ] * Backport fix to remove lowmem 1:1 mapping that fixes boot on some classes of machines. (Closes: #649923) Please could we have a full source debdiff for the proposed package, against the package currently in 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/1339700121.19699.6.ca...@jacala.jungle.funky-badger.org
Re: [Pkg-xfce-devel] Bug#668806: Bug#668806: Bits from the Release Team: Freeze approaching!
On sam., 2012-05-26 at 16:41 +0200, Yves-Alexis Perez wrote: On lun., 2012-05-14 at 23:13 +0200, Yves-Alexis Perez wrote: On lun., 2012-05-14 at 20:45 +0200, Cyril Brulebois wrote: So, this is another friendly ping about the main issue. Can I upload a new 4.6 xfce4-panel which adds the Conflicts against xfce4-panel 4.8 in shlibs. Then RT would need to schedule the binNMUs for all the relevant dependencies so, when Wheezy/Wheezy+1 upgrade time comes, a plugin not working with with 4.10+ panel has a chance to be upgraded *before* the new panel is used? Hi RT, I know you're all quite busy, but that won't get better as freeze comes closer. Right now, we won't have an upgrade path for xfce4-panel and plugins between Wheezy and Wheezy+1: for partial upgrades there's a window where panel might already be updated to 4.10+ while plugins are still at 4.8, and it'll break at runtime unless we force (4.8) plugins to be upgraded at the same time as the (4.8) panel. If it's a bit painful to schedule the binNMUs I can do the xfce4-panel upload and then do a sourceful upload of each and every panel plugin but that looks too much like an uncoordinated transition and that doesn't look desirable. Maybe the change is small enough that it could be done post-freeze along with all the binNMUs, but then I wouldn't be against some kind of confirmation of that. So, TL;DR: what can I do to help, and could I have a small bit of update so I have an idea what to do for the upgrade path? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Stable update for xen
On Thu, Jun 14, 2012 at 07:55:21PM +0100, Adam D. Barratt wrote: On Thu, 2012-06-14 at 20:51 +0200, Bastian Blank wrote: I'd like to fix an boot error of Xen on several newer machines in stable. I'm assuming this is fixed in at least unstable already, given the dates of the commits referenced in the bug report? It is included in 4.1.0. Please could we have a full source debdiff for the proposed package, against the package currently in stable? Sure. Bastian -- The idea of male and female are universal constants. -- Kirk, Metamorphosis, stardate 3219.8 diff -Nru xen-4.0.1/debian/changelog xen-4.0.1/debian/changelog --- xen-4.0.1/debian/changelog 2011-06-09 20:35:07.0 +0200 +++ xen-4.0.1/debian/changelog 2012-06-14 20:27:57.0 +0200 @@ -1,3 +1,23 @@ +xen (4.0.1-6) UNRELEASED; urgency=low + + [ Ian Campbell ] + * Backport fix to remove lowmem 1:1 mapping that fixes boot on some +classes of machines. (Closes: #649923) + + -- Bastian Blank wa...@debian.org Thu, 14 Jun 2012 20:27:03 +0200 + +xen (4.0.1-5) stable-security; urgency=low + + * Fix privilege escalation and syscall/sysenter DoS while using +non-canonical addresses by untrusted PV guests. +CVE-2012-0217 +CVE-2012-0218 + * Disable Xen on CPUs affected by AMD Erratum #121. PV guests can +cause a DoS of the host. +CVE-2012-2934 + + -- Bastian Blank wa...@debian.org Mon, 11 Jun 2012 18:12:37 + + xen (4.0.1-4) stable-security; urgency=low * Fix overflows and missing error checks in PV kernel loader. diff -Nru xen-4.0.1/debian/control.md5sum xen-4.0.1/debian/control.md5sum --- xen-4.0.1/debian/control.md5sum 2011-06-09 20:36:05.0 +0200 +++ xen-4.0.1/debian/control.md5sum 2012-06-14 20:31:20.0 +0200 @@ -1,4 +1,4 @@ -3207088ea024aa07513e3c44b7d3e1af debian/changelog +6a070480a54a79a74d6623a07ff8beb7 debian/changelog 24f2598a23e30264aea4a983d5d19eec debian/bin/gencontrol.py ee1ccd7bf0932a81ca221cab08347614 debian/templates/control.hypervisor.in e4335ab10e217a12328cdf123473ed37 debian/templates/control.main.in diff -Nru xen-4.0.1/debian/patches/CVE-2012-0217+2012-0218 xen-4.0.1/debian/patches/CVE-2012-0217+2012-0218 --- xen-4.0.1/debian/patches/CVE-2012-0217+2012-02181970-01-01 01:00:00.0 +0100 +++ xen-4.0.1/debian/patches/CVE-2012-0217+2012-02182012-06-14 20:24:30.0 +0200 @@ -0,0 +1,96 @@ +diff -r d8fd425b60d3 xen/arch/x86/x86_64/asm-offsets.c +--- a/xen/arch/x86/x86_64/asm-offsets.cTue May 01 14:18:46 2012 +0100 b/xen/arch/x86/x86_64/asm-offsets.cThu May 24 11:18:47 2012 +0100 +@@ -89,6 +89,8 @@ void __dummy__(void) +arch.guest_context.trap_ctxt[TRAP_gp_fault].address); + OFFSET(VCPU_gp_fault_sel, struct vcpu, +arch.guest_context.trap_ctxt[TRAP_gp_fault].cs); ++OFFSET(VCPU_gp_fault_flags, struct vcpu, ++ arch.guest_context.trap_ctxt[TRAP_gp_fault].flags); + OFFSET(VCPU_kernel_sp, struct vcpu, arch.guest_context.kernel_sp); + OFFSET(VCPU_kernel_ss, struct vcpu, arch.guest_context.kernel_ss); + OFFSET(VCPU_guest_context_flags, struct vcpu, arch.guest_context.flags); +diff -r d8fd425b60d3 xen/arch/x86/x86_64/compat/entry.S +--- a/xen/arch/x86/x86_64/compat/entry.S Tue May 01 14:18:46 2012 +0100 b/xen/arch/x86/x86_64/compat/entry.S Thu May 24 11:18:47 2012 +0100 +@@ -227,6 +227,7 @@ 1: call compat_create_bounce_frame + ENTRY(compat_post_handle_exception) + testb $TBF_EXCEPTION,TRAPBOUNCE_flags(%rdx) + jzcompat_test_all_events ++.Lcompat_bounce_exception: + call compat_create_bounce_frame + movb $0,TRAPBOUNCE_flags(%rdx) + jmp compat_test_all_events +@@ -243,14 +244,15 @@ ENTRY(compat_syscall) + 1: movq %rax,TRAPBOUNCE_eip(%rdx) + movw %si,TRAPBOUNCE_cs(%rdx) + movb %cl,TRAPBOUNCE_flags(%rdx) +-call compat_create_bounce_frame +-jmp compat_test_all_events ++jmp .Lcompat_bounce_exception + 2: movl $TRAP_gp_fault,UREGS_entry_vector(%rsp) + subl $2,UREGS_rip(%rsp) + movq VCPU_gp_fault_addr(%rbx),%rax + movzwl VCPU_gp_fault_sel(%rbx),%esi +-movb $(TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE|TBF_INTERRUPT),%cl + movl $0,TRAPBOUNCE_error_code(%rdx) ++testb $4,VCPU_gp_fault_flags(%rbx) ++setnz %cl ++leal TBF_EXCEPTION|TBF_EXCEPTION_ERRCODE(,%rcx,TBF_INTERRUPT),%ecx + jmp 1b + + ENTRY(compat_sysenter) +diff -r d8fd425b60d3 xen/arch/x86/x86_64/entry.S +--- a/xen/arch/x86/x86_64/entry.S Tue May 01 14:18:46 2012 +0100 b/xen/arch/x86/x86_64/entry.S Thu May 24 11:18:47 2012 +0100 +@@ -51,6 +51,13 @@ restore_all_guest: + testw $TRAP_syscall,4(%rsp) + jziret_exit_to_guest + ++/* Don't use SYSRET path if the return address is not canonical. */ ++movq 8(%rsp),%rcx ++sarq $47,%rcx ++incl %ecx ++
Re: Status of suhosin in Debian
On Thu, Jun 14, 2012 at 8:38 PM, Thomas Goirand z...@debian.org wrote: Ondrej, is your plan still to leave suhosin as a build option in the source package like you wrote early last February, so that those who want it can just switch that option and rebuild? I can see in the debian/rules that there's still: # Set this flag to 'yes' if you want to compile PHP5 with suhosin patch PHP5_SUHOSIN=no Yes, I do, but see the two last paragraphs. Does this mean that the suhosin patch still works in current php 5.4 package? No, it doesn't (there's even a wishlist bug for that). Or is this still something remaining fro the php 5.3 packaging? Yup. Would it be feasible to build twice PHP, once with the suhosin patch, and once without, and build 2 debian binaries? Nope, you would have to build twice every reverse dependency as well, that's just crazy :). If yes, how much work would this be? Does this mean building 3 more binaries, like: libapache2-mod-php5-suhosin, php5-cli-suhosin, php5-cgi-suhosin? Nope, you would have to have php5-mysql-suhosin, php5-imap-suhosin... But this discussion is pointless. There is no suhosin release for php 5.4.x and even if there was one say tomorrow, there is too little time to include it again and feel comfortable. We might revert the decision for wheezy+1, but given that as far as I know only Ubuntu has kept suhosin (and thus 5.3.x branch) enabled. O. -- Ondřej Surý ond...@sury.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/CALjhHG_dOd+hPW4Ur4gagDRBjqO3YqE920XDWzqpvDzUqjg=y...@mail.gmail.com
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Thu, Jun 14, 2012 at 01:59:25PM -0400, Michael Gilbert wrote: I did not suggest that. Anyway, maybe this will be a bit clearer. Let's say an existing package is at version +b1 on amd64, and it needs to get a binnmu, then a +b2 package is built on amd64, its changelog is taken and stuffed it into all of the other 'Multi-Arch: same' +b1 packages, which are now called +b2, and all of them uploaded. For various reasons you cannot do that without a rebuild. (Hint: Files must not change, new versions have their versions in various fields.) Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#664681: transition: KDE's 4.8 release of platform, applications and workspace
On Thu, 2012-06-14 at 16:45 +0200, Pino Toscano wrote: Alle domenica 10 giugno 2012, Adam D. Barratt ha scritto: On Sat, 2012-06-09 at 22:52 +0200, Pino Toscano wrote: URL:http://release.debian.org/transitions/html/kde-workspace4.8.html [...] kshutdown (*) [...] plasma-widget-smooth-tasks (*) (*) fails to compile with the newer workspace API Is there a plan for getting kshutdown and p-w-smooth-tasks fixed or removed? They are leaf packages so they can be always hinted out of testing until they get fixes. - kshutdown has not been handled yet, we will do so soon - plasma-widget-smooth-tasks is getting an update to a forked version of it (since the original seems to not be developed lately...) Okay; thanks. the rest of the sources (those without */**) can be binNMUed now, I think (as kde-workspace compiled everywhere in release archs at least). Yep. Scheduled, minus apper/sparc which appears to have built more recently than the other arches and already picked up the correct dependency. 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/1339703450.19699.9.ca...@jacala.jungle.funky-badger.org
Futur status of RoarAudio packages
Dear Release Team, Ron Lee recently asked every maintainer with a package depending on one of our libs to remove them. It is not clear to me why he did that. All problem with our packages relevant for the new stable release have been solved (I have only one wishlist ticket left on my QA page). By removing all those dependencies he made the package perfectly useless as it is backend software and is hardly useful without other software using it. In #675610 he writes We'd like to have nothing depending on roar for wheezy, [...]. I'm not sure about the We in this statement. Also I have not got any info from him or the Release Team or any other Team as far as I know. (If I missed something please kindly point me to that). I want to ask if the release team decided anything in this direction. Does the release team want a useful version of the package in wheezy? I'm not interested in any discussion but a plain offical statement from the Release Team. If the Release Team is interested in keeping the package there needs to be a discussion (diffrent thread or on IRC, ...) how to solve the situation. If there is no interested in a useful version I will submit RM bugs against all related packages I'm the maintainer for and suggest Patrick Matthäi (the maintainer of the other half of releated packages) to do the same. I don't see a point in keeping a package made useless and wasting more of our and others time. Thanks you for your help and infos. PS: Please keep Patrick Matthäi in CC as he is no longer subscribed to this list. -- Philipp. (Rah of PH2) signature.asc Description: This is a digitally signed message part
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Thu, Jun 14, 2012 at 3:43 PM, Philipp Kern wrote:
On Thu, Jun 14, 2012 at 01:59:25PM -0400, Michael Gilbert wrote:
I did not suggest that. Anyway, maybe this will be a bit clearer.
Let's say an existing package is at version +b1 on amd64, and it needs
to get a binnmu, then a +b2 package is built on amd64, its changelog
is taken and stuffed it into all of the other 'Multi-Arch: same' +b1
packages, which are now called +b2, and all of them uploaded.
For various reasons you cannot do that without a rebuild. (Hint: Files must
not
change, new versions have their versions in various fields.)
Right, there is that additional complexity, but even so I think it
could be made to work.
dpkg-gencontrol could be used to update the Version and any
${binary:Version} fields in the control file. Also, the package's
md5sums could be regenerated to include the hash for the new
changelog.
Best wishes,
Mike
--
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/CANTw=MNn+1jxCbf_Gj=g2dH=meooxfggxz+iduge5dopzzd...@mail.gmail.com
Bug#677574: transition: libv8
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, i'd like to update libv8 3.8.9.20 to 3.10.8. * packages needing a simple rebuild (i checked them) : + libv8-i18n + osmium + drizzle * packages needing more work : nodejs (i'm maintaining it and it's ready to be uploaded) Please note that SONAME is libv8.so.3.10.8 instead of libv8.so.3.10.8.15, allowing libv8 maintainers to do patch-level updates without the need to setup a transition. This will hopefully improve the current situation. I started some discussion about that here : http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2012-June/003683.html Ben file: title = libv8; is_affected = .depends ~ libv8-3.8.9.20 | .depends ~ libv8-3.10.8; is_good = .depends ~ libv8-3.10.8; is_bad = .depends ~ libv8-3.8.9.20; Regards, Jérémy. -- 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/20120614231010.9525.49513.reportbug@imac.chaumes
Bug#677574: transition: libv8
tag 677574 pending thanks Jérémy Lal kapo...@melix.org (15/06/2012): * packages needing a simple rebuild (i checked them) : + libv8-i18n + osmium + drizzle * packages needing more work : nodejs (i'm maintaining it and it's ready to be uploaded) Please note that SONAME is libv8.so.3.10.8 instead of libv8.so.3.10.8.15, allowing libv8 maintainers to do patch-level updates without the need to setup a transition. This will hopefully improve the current situation. I started some discussion about that here : http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2012-June/003683.html As long as binary compatibility is kept between patch-levels, it looks like a plan. Tracker is at: http://release.debian.org/transitions/html/libv8.html Please go ahead with an upload to unstable. Mraw, KiBi. signature.asc Description: Digital signature
Processed: Re: Bug#677574: transition: libv8
Processing commands for cont...@bugs.debian.org: tag 677574 pending Bug #677574 [release.debian.org] transition: libv8 Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 677574: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677574 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.133971685024789.transcr...@bugs.debian.org
