Bug#692291: unblock: mingw-ocaml/3.12.1+debian3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, RC bug #662746 has been fixed on mingw-ocaml. Debdiff is pretty simple: diff -Nru mingw-ocaml-3.12.1+debian2/debian/changelog mingw-ocaml-3.12.1+debian3/debian/changelog --- mingw-ocaml-3.12.1+debian2/debian/changelog 2011-10-09 15:08:17.0 +0200 +++ mingw-ocaml-3.12.1+debian3/debian/changelog 2012-11-03 19:29:54.0 +0100 @@ -1,3 +1,10 @@ +mingw-ocaml (3.12.1+debian3) unstable; urgency=low + + * Added Replaces: mingw32-ocaml to mingw-ocaml + Closes: #662746 + + -- Romain Beauxis to...@rastageeks.org Sat, 03 Nov 2012 16:40:31 +0100 + mingw-ocaml (3.12.1+debian2) unstable; urgency=low * Fixed typo in dummy transitional package.. diff -Nru mingw-ocaml-3.12.1+debian2/debian/control mingw-ocaml-3.12.1+debian3/debian/control --- mingw-ocaml-3.12.1+debian2/debian/control 2011-10-09 15:08:01.0 +0200 +++ mingw-ocaml-3.12.1+debian3/debian/control 2012-11-03 19:28:17.0 +0100 @@ -17,6 +17,8 @@ ocaml-nox, ocaml-findlib, mingw-w64 +Replaces: mingw32-ocaml ( 3.12.1~) +Breaks: mingw32-ocaml ( 3.12.1~) Description: OCaml cross-compiler based on mingw Objective Caml (OCaml) is an implementation of the ML language, based on the Caml Light dialect extended with a complete class-based object system Could it be possible to unblock this package? Thanks! Romain unblock mingw-ocaml/3.12.1+debian3 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-486 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121104181436.17058.1421.reportbug@Obey
Bug#680256: unblock: liquidsoap/1.0.1-1
Hi Adam and thanks for your response, 2012/7/16 Adam D. Barratt a...@adam-barratt.org.uk: On Wed, 2012-07-04 at 18:34 +0200, Romain Beauxis wrote: Our bugfix release of liquidsoap has been caught in the middle of the freeze.. We had already uploaded ocaml-dtools 0.3.0 and ocaml-flac 0.1.1 when the freeze happened. However, liquidsoap 1.0.0 does not build against ocaml-dtools 0.3.0 That's rather unfortunate and implies that the version of liquidsoap currently in wheezy is RC-buggy, as we can't rebuild it if required for security updates or other post-release fixes. How involved would the changes required for 1.0.0 to be buildable against the new ocaml-dtools be? Liquidsoap 1.0.1 is a bugfix release that we have very carefully crafted to make sure that it would be a backward-compatible stable drop-in replacement for 1.0.0 users. The raw diffstat compared to the package that's currently in wheezy is 282 files changed, 3896 insertions(+), 2060 deletions(-) While that's not the largest we've been requested to review, it is quite large for a package that wasn't uploaded until after the freeze. Looking through the upstream changelog, there's quite a lot of things listed under the new heading, which are generally discouraged during a freeze. Some of the descriptions under fixes sound like unblock material, but I don't know the software well enough to know whether the others are. Given that the previous upstream release was eight months ago and the fact that the freeze would be in June has been known for the past year, would it not have been possible to have got the new version released / uploaded earlier? As it is, we're now in a position where we have to review all of the changes and decide whether they're okay. Therefore, we think it would be fine to unblock and migrate to the current testing distribution. I'd be worried if you didn't think so, given that you requested it. :-) However, at first (and third) glance the overall changes don't obviously appear to fulfil the published unblock criteria, so this is more of a request for an exception to those criteria. I understand your concern. It was our initial plan to have a stable release just before the freeze. However, the release itself was delayed in order to make sure that we had properly tested backward compatibility and stability of the new changes, which is why it got stuck in the middle of the actual freeze. As both Debian maintainer of the package and part of the upstream team, I am positively convinced that this release meets the expected stability and functionalities for the next Debian stable release. Finally, since liquidsoap has no packages depending on it, unblocking its migration is of no risk at all for the distribution as a whole. If for any reason, you prefer to go with the current package, then we'll do our best to fix what needs to be fixed directly in the testing distribution. Have a good day, Romain -- 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/CABWZ6OTat8kU6HpuKFfHXVCK5teOjm3s40W2hRB=fu91na0...@mail.gmail.com
Bug#680256: unblock: liquidsoap/1.0.1-1
Hi Adam, 2012/7/4 Romain Beauxis to...@rastageeks.org: 2012/7/4 Adam D. Barratt a...@adam-barratt.org.uk: On 04.07.2012 17:54, Romain Beauxis wrote: Hi, 2012/7/4 Adam D. Barratt a...@adam-barratt.org.uk: On 04.07.2012 17:34, Romain Beauxis wrote: Our bugfix release of liquidsoap has been caught in the middle of the freeze.. We had already uploaded ocaml-dtools 0.3.0 and ocaml-flac 0.1.1 when the freeze happened. However, liquidsoap 1.0.0 does not build against ocaml-dtools 0.3.0 Liquidsoap 1.0.1 is a bugfix release that we have very carefully crafted to make sure that it would be a backward-compatible stable drop-in replacement for 1.0.0 users. Therefore, we think it would be fine to unblock and migrate to the current testing distribution. I'm assuming the diff isn't meant to contain quite so many copies of things? That's a bug in the generated tarball, those .bak files are cleaned at `make clean` invokation. Would you like another, cleaned one? Yes, please. :) Right on! I've just uploaded 1.0.1+repack1 to the archive! Any news on this one? Have a good day, Romain -- 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/cabwz6oqaxevrveb9r7mbhyr3_xdc__ev-2a6alp+j2eqd9g...@mail.gmail.com
Bug#680256: unblock: liquidsoap/1.0.1-1
Hi Cyri, 2012/7/15 Cyril Brulebois k...@debian.org: Romain Beauxis to...@rastageeks.org (15/07/2012): Any news on this one? Please allow him to get back from debconf. Also, you aren't the only one with a pending request, so please be patient. I am patient, don't worry :-) R. -- 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/CABWZ6ORJ9Cb62PhH_buYmih=VM8XjJZ7f=_hummpe7cwsjj...@mail.gmail.com
Bug#680256: unblock: liquidsoap/1.0.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package liquidsoap Hi Release team! Our bugfix release of liquidsoap has been caught in the middle of the freeze.. We had already uploaded ocaml-dtools 0.3.0 and ocaml-flac 0.1.1 when the freeze happened. However, liquidsoap 1.0.0 does not build against ocaml-dtools 0.3.0 Liquidsoap 1.0.1 is a bugfix release that we have very carefully crafted to make sure that it would be a backward-compatible stable drop-in replacement for 1.0.0 users. Therefore, we think it would be fine to unblock and migrate to the current testing distribution. Please let us know what you think and have a good day, Romain unblock liquidsoap/1.0.1-1 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-486 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120704163433.1106.34784.reportbug@Obey
Bug#680256: unblock: liquidsoap/1.0.1-1
Hi, 2012/7/4 Adam D. Barratt a...@adam-barratt.org.uk: On 04.07.2012 17:34, Romain Beauxis wrote: Our bugfix release of liquidsoap has been caught in the middle of the freeze.. We had already uploaded ocaml-dtools 0.3.0 and ocaml-flac 0.1.1 when the freeze happened. However, liquidsoap 1.0.0 does not build against ocaml-dtools 0.3.0 Liquidsoap 1.0.1 is a bugfix release that we have very carefully crafted to make sure that it would be a backward-compatible stable drop-in replacement for 1.0.0 users. Therefore, we think it would be fine to unblock and migrate to the current testing distribution. I'm assuming the diff isn't meant to contain quite so many copies of things? That's a bug in the generated tarball, those .bak files are cleaned at `make clean` invokation. Would you like another, cleaned one? Romain doc/liqi/html.ml | 25 doc/liqi/html.ml.bak | 229 + doc/liqi/html.ml.bak.bak | 229 + doc/liqi/latex.ml | 4 doc/liqi/latex.ml.bak | 108 doc/liqi/latex.ml.bak.bak | 108 doc/liqi/liqi.ml | 4 doc/liqi/liqi.ml.bak | 82 doc/liqi/liqi.ml.bak.bak | 82 doc/liqi/liqi_lexer.ml.bak | 2261 +++ doc/liqi/liqi_lexer.ml.bak.bak | 2261 +++ [etc] src/lang/lang.ml.bak | 801 + src/lang/lang.mli | 2 src/lang/lang.mli.bak | 271 + src/lang/lang_builtins.ml | 228 - src/lang/lang_builtins.ml.bak | 2228 +++ src/lang/lang_encoders.ml | 17 src/lang/lang_encoders.ml.bak | 686 src/lang/lang_lexer.ml.bak | 3418 src/lang/lang_lexer.mll | 3 src/lang/lang_lexer.mll.bak | 207 + src/lang/lang_parser.ml.bak | 2325 src/lang/lang_parser.mli.bak | 69 [etc] 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/CABWZ6ORdP-tFVP=mSxXvqiiY8p1U=dsdwyjgkmr8-mfqwzl...@mail.gmail.com
Bug#680256: unblock: liquidsoap/1.0.1-1
2012/7/4 Adam D. Barratt a...@adam-barratt.org.uk: On 04.07.2012 17:54, Romain Beauxis wrote: Hi, 2012/7/4 Adam D. Barratt a...@adam-barratt.org.uk: On 04.07.2012 17:34, Romain Beauxis wrote: Our bugfix release of liquidsoap has been caught in the middle of the freeze.. We had already uploaded ocaml-dtools 0.3.0 and ocaml-flac 0.1.1 when the freeze happened. However, liquidsoap 1.0.0 does not build against ocaml-dtools 0.3.0 Liquidsoap 1.0.1 is a bugfix release that we have very carefully crafted to make sure that it would be a backward-compatible stable drop-in replacement for 1.0.0 users. Therefore, we think it would be fine to unblock and migrate to the current testing distribution. I'm assuming the diff isn't meant to contain quite so many copies of things? That's a bug in the generated tarball, those .bak files are cleaned at `make clean` invokation. Would you like another, cleaned one? Yes, please. :) Right on! I've just uploaded 1.0.1+repack1 to the archive! Thanks, Romain -- 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/CABWZ6OTCX5HMunR7=ew2pfsw_vzz7ogzrnhpznxede0hvb1...@mail.gmail.com
Bug#644741: nmu: rebuild against ocaml-ogg
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, The following packages need to be rebuilt against the new ocaml-ogg: nmu ocaml-speex_0.2.0-1 . ALL . -m Rebuild against ocaml-ogg 0.4.3-1 dw ocaml-speex_0.2.0-1 . ALL . -m 'libogg-ocaml-dev (= 0.4.3)' nmu ocaml-theora_0.3.0-1 . ALL . -m Rebuild against ocaml-ogg 0.4.3-1 dw ocaml-theora_0.3.0-1 . ALL . -m 'libogg-ocaml-dev (= 0.4.3)' nmu ocaml-flac_0.1.0-1 . ALL . -m Rebuild against ocaml-ogg 0.4.3-1 dw ocaml-flac_0.1.0-1 . ALL . -m 'libogg-ocaml-dev (= 0.4.3)' nmu ocaml-schroedinger_0.1.0-1 . ALL . -m Rebuild against ocaml-ogg 0.4.3-1 dw ocaml-schroedinger_0.1.0-1 . ALL . -m 'libogg-ocaml-dev (= 0.4.3)' Thanks, Romain -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-486 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111008163153.17691.50155.reportbug@Obey
Bug#632766: nmu: ocaml-lastfm_0.3.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi! Ocaml-lastfm needs to be rebuilt against the newest xmlplaylist. nmu ocaml-lastfm_0.3.0-1 . ALL . -m Rebuild against ocaml-xmlplaylist 0.1.3-1 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- 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/20110705200916.17203.3677.reportbug@leonard
Bug#610562: unblock: spip/2.1.1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock I have just uploaded a new package for spip that fixes two recent security issues (#609212 and #610016). The update consists in the addition of a single file named ecran_securite.php (security screen) which is designed with the sole purpose of fixing known security issues in spip. The file is documented there: http://www.spip.net/en_article4201.html I have contacted upstream to ask them whether this was good enough to consider the security issues as fixed and they replied in the affirmative. Thus, I kindly request the unblocking of spip 2.1.1-3 and its migration to testing in the purpose of shipping a fixed spip package in Debian squeeze. Thanks for your work and have a good day, Romain unblock spip/2.1.1-3 -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- 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/20110119222414.31588.67647.reportbug@leonard
Bug#597346: unblock: spip/2.1.1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Hi ! Spip 2.1.2 has been released a couple of day ago. It consists of a one-liner fix for an int overflow on 32 bit machines in the articles' published date. A release-critical bug has been filled at #597026 and I have just uploaded spip 2.1.1-2 which incorporates the following changes: Index: /branches/spip-2.1/ecrire/public/quete.php === --- /branches/spip-2.1/ecrire/public/quete.php (revision 15839) +++ /branches/spip-2.1/ecrire/public/quete.php (revision 16014) @@ -80,5 +80,5 @@ ($GLOBALS['meta']['date_prochain_postdate'] time()) ? $GLOBALS['meta']['date_prochain_postdate'] - : (time()+(3600*24*1))) ; + : (time()+(3600*24*365*2))) ; } Could you please unblock spip 2.1.1-2 in order to ship a fixed package in squeeze ? Romain unblock spip/2.1.1-2 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- 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/20100918202346.30782.54128.report...@leonard
Bug#575344: nmu: wikidiff2_0.0.1+svn55737-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu User: release.debian@packages.debian.org Usertags: binnmu nmu wikidiff2_0.0.1+svn55737-1.1 . amd64 . -m Rebuild against latest php-* ABI -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- 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/20100325012512.9361.12171.report...@leonard
Bug#573903: RM: peercast/0.1218+svn20080104-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Hi ! The peercast package has been unmaintained upstream for months now. I do not wish to maintain it during the next stable and have found no one to take it over. Hence, I would like to request its removal from current testing so that it is not shipped in the next stable. Of course, if any interested maintainer want to take it over and maintain it, I'd be more then happy to hand it to him. Romain -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- 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/20100314213520.20470.34667.report...@leonard
Bug#572918: nmu: liquidsoap_0.9.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu liquidsoap_0.9.2-1 . ALL . -m Rebuild against ocaml-cry 0.1.2 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- 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/20100307171340.10968.15284.report...@leonard
Re: webapps in stable release cyles Was: flashplugin-nonfree in Debian
Hi ! Le Wednesday 22 April 2009 09:07:58 Jan Wagner, vous avez écrit : I've requested a slot at DebConf to discuss this into detail, though feel free to start a discussion already on debian-devel. sorry for coming around with another issue. While reading your comment without giving any details about your ideas, I don't know if our problem maybe related, sorry if not. There are many packages, which are frequently removed from testing right before the release, cause of (potential) security issues and not getting in worries with the security team. Other packages may be obsoleted by upstream and lose their support. This is often the case for web applications. We had something in mind we summarized at http://wiki.debian.org/Proposals/Webapps. I also believe this is an interesting proposal. Additionally, even though webapps upstream can provide a bugfix release with only security-related fixes, due to the nature of the security issues in webapps, this can also mean hudge changes which are not easy at all to review for a security upload. This is was the case for the latest security upload of mediawiki (version 1:1.12.0-2lenny3). However, I wonder if this would need yet another archive, or just an update of a policy, either in backports.org or volatile.. Romain -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Broken testing update check ?
Hi all ! I fail to understand why fglrx-driver just entered testing today. It suffers from a grave bug, namely #476844. The only reason why it could be the case is that this bug has been tagged as pending since the new package, sitting in NEW at the moment, fixes the issue. If this is the case, then I think it's a major bug in the update script, and it would be good to fix it... Romain PS: please CC me, I'm not subscribed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Broken testing update check ?
Le Thursday 29 May 2008 19:54:32 Julien Cristau, vous avez écrit : If this is the case, then I think it's a major bug in the update script, and it would be good to fix it... Thankfully, this isn't the case. Yes, I had the answer quickly after sending the mail (as usual...). Still I don't understand why it took more than a month to move to testing then, while the i386 build was done at least on the 20th of april, based on ftp.debian.org... Yes I know, I could have looked at the status page before, but well Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Broken testing update check ?
Le Thursday 29 May 2008 20:37:56 Romain Beauxis, vous avez écrit : Still I don't understand why it took more than a month to move to testing then, while the i386 build was done at least on the 20th of april, based on ftp.debian.org... Hummm... It seems it's my day for making unecessary noise and getting answers quickly afterwards... The bug was tagged as present in the previous version few days ago. Sorry again for the noise then... Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing mediawiki dependencies on pgsql for etch
Le lundi 19 mars 2007 19:10, Steve Langasek a écrit : If it is ok for you, then I'll upload it.. Yes, this is ok. (FWIW, sending a debdiff to the list is going to get you a quicker review than a link to a source package will...) Thanks Steve, The package is just being uploaded now, I have added the nl po debconf that was submited just on time, though. I'll try to send more relevant information (debdiff) next time. Romain -- 'mama say son, I ain't got no food today tit for tat, butter for fish there's a little porridge in the dish
Re: Removing mediawiki dependencies on pgsql for etch
Le samedi 17 mars 2007 21:09, Steve Langasek a écrit : I'm afraid the time for translation updates is over. So please only remove the dependencies in your upload. Well, if an update is needed anyway, I don't object to the inclusion of l10n changes. I just won't grant exceptions for l10n changes /alone/, because the risk of broken binary packages getting into the release is comparatively high at this point and outweighs the benefits of l10n updates alone. Ok, I have prepared a new release of mediawiki1.7 adding the translations. I have encoutered an issue in our automatic manpage generation system that uses xsltproc, docbook-xml and docbook-xsl. I don't really know which one is the culprit, but it is clearly an issue there. When building the package against current sid versions, I get a lot of: I: mediawiki1.7-math: hyphen-used-as-minus-sign usr/share/man/man1/texvc.1.gz:54 In the lintian check. However building the package against current etch just makes a lintian free package. So, I have written testing-proposed-updates as the target distribution, set urgency to high and built against an etch chroot using cowbuilder. You can find the package at this place: http://www.rastageeks.org/~toots/mediawiki/ If it is ok for you, then I'll upload it.. Romain -- They seh when you have nuff money You got a whole heap o' friend But when your money done dem just don't know you again When your dollars gone dem nah see you again And when your money done dem nah want see you again Money money money money is the root of all evil And you see it
Removing mediawiki dependencies on pgsql for etch
Hi release managers !
Following with bug #414885 and so issue duck had while upgrading from
mediawiki 1.7 with pgsql, we have come to the conclusion that mediawiki1.7
should not be shipped in eth with its current pgsql dependencies since its
support seems not to be complete enough...
Given that I have uploaded some newer releases in experimental for changes
that I don't want to propose for etch, my plan is to raise the severity of
bug 414885 to serious, rename it to pgsql support should be droped for
etch, add the two awaiting po translations and remove pgsql dependecies to
current sid package and upload a mediawiki1.7 1.7.1-9etch0 to unstable and
then ask for its inclusion into testing.
Is that the right way to handle this situation ?
Thanks for your help.
Romain
--
while ( love passion ) {
for( fight = 0 ; rights freedom ; rights++ )
fight = standup( rights );
free( babylon );
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Making mediawiki FHS compliant
Le samedi 24 février 2007 12:46, vous avez écrit : Ok, it was my understanding from previous comments in the bug history that this couldn't be done non-intrusively, because mediawiki would then look up the real directory and use that value for things that it shouldn't? In fact it's easy, it's a one-line patch And it is done in the awaiting mediawiki1.9 that is in the NEW queue. Again I know how to resolve this but I think that the implementation is much more cleaner by doing it in mediawiki1.9.. Again, this is one of the changes that must be done and others are to be very intrusive on the package, I have already listed them: * Let think a moment of what involved solving this issue. It involves: - Changing the patch for installation messages to reflect the /etc location - Adding a patch for defining this MW_INSTALL_PATH - Changing the documentation for reflecting this new path too - Changing the automated update script And, perhaps the most important: - Add an updating code which detects wether the configuration is in /etc or in /var and apply the good changes. Of course, in order not to blow again any file, this script as to be started before the packages files are copied. - Also, you may add an advice to the administrator via debconf so that he is aware of this change in his configuration. All of this is done straith forward and non intrusivly in mediawiki1.9: new configuration files are created with this define, old are patched and since the package uses a different location for its files, nothing more has to be done. Frank, if you think this can be solved cleanly in mediawiki1.7 why don't you just put up a complete patch instead of only one of the things to do ? If then it looks good, I would apply it happily. Romain
Re: Making mediawiki FHS compliant
Le samedi 24 février 2007 17:02, vous avez écrit : Frank, if you think this can be solved cleanly in mediawiki1.7 why don't you just put up a complete patch instead of only one of the things to do ? If then it looks good, I would apply it happily. Hm, I didn't do it mostly because if I send a complete patch, I don't do that without exhaustive testing. And this I didn't want to do on a bug that had an etch-ignore tag. But it seems the tag is based on incomplete information about options to solve the bug, isn't it? You say that while later on you claimed not to understand everything about the package (update script). Don't you have the impression that this judgement is also based on incomplete information on the package ? That's why I propose you to do the work you are asking us. Then you'll understand all the things about the package, and will be able to state such assomption. I say this without any anger, I would be pleased to upload a package that corrects this bug, but I am almost sure that the amount of change needed will never make it into etch. Romain
Re: Upgrade
Le jeudi 8 février 2007 22:17, Steve Langasek a écrit : I think the bug #388616 should be granted this etc-ignore. The configuration file is never shiped with the package nor generated by the software. It is generated in config/ directory, and happen normaly only at first install. My question here is, if the software looks for the config in /var/lib out of necessity, why does the package ship a symlink under /etc/ when that symlink a) will overwrite any attempts by the user to turn this into a real file (for whatever reason), and b) will complicate upgrades in the future when mediawiki's FHS bug is fixed so that the conffile *can* be moved to /etc? Right. I have just uploaded a new package for mediawiki1.7 (-9) that fixes a security issue as published in the current 1.7.3 upstream release. Since -6 I have removed the symlink, added a README and added two deconf translations. You may consider this package as an update candidate for mediawiki1.7 Romain
Re: Upgrade
Le mercredi 21 février 2007 12:54, Frank Küster a écrit : To me that looks a bit more complicated than one would like, but still quite manageable, and acceptable for fixing a RC bug in etch. Not that I don't see any solution, but I would prefer to correct this situation with the forthcoming 1.9 upgrade directly in the upgrade script. I have just uploaded a first mediawiki1.9 to experimental to have a working upgrade script for standard mediawiki1.7 installation located in /var/lib that puts the file in /etc with the correct variable defined in the file. The script may even work in the case where the file is at /etc/mediawiki1.7 since a symlink is expected in /var/lib in this case.. I would prefer to keep the changes as minimal a possible for the package shipped with etch and concentrate the correction for the next package since we could have more time to test it via experimental and then unstable. All of this is based on my personal assumption that the RC bug is not that important since we took care that the configuration file is never overwrited, and added a README to warn the user, and the fact that I beleive it do not worth to add so much change to the actual package. Romain
Re: Upgrade
Le jeudi 8 février 2007 03:03, Filipus Klutiero a écrit : Under the circumstances, I would be willing to grant an etch-ignore exception for the file location. If the location of the file is still causing upgrade errors (which seems possible, since the symlinks under /etc/mediawiki1.7 are not conffiles and therefore may overwrite a user's config), that would be more than just a technicality, and I wouldn't grant an etch-ignore exception for that. OK, so I'm upgrading to serious. Steve, I have no opinion about etch-ignoring this, but you can consider it now. Romain, you may want to unmerge #388616 from #409434 and downgrade #409434 to important. Yes, I'll do it. I think the bug #388616 should be granted this etc-ignore. The configuration file is never shiped with the package nor generated by the software. It is generated in config/ directory, and happen normaly only at first install. Romain
Re: Upgrade
Le jeudi 8 février 2007 15:22, Romain Beauxis a écrit : Le jeudi 8 février 2007 03:03, Filipus Klutiero a écrit : Under the circumstances, I would be willing to grant an etch-ignore exception for the file location. If the location of the file is still causing upgrade errors (which seems possible, since the symlinks under /etc/mediawiki1.7 are not conffiles and therefore may overwrite a user's config), that would be more than just a technicality, and I wouldn't grant an etch-ignore exception for that. OK, so I'm upgrading to serious. Steve, I have no opinion about etch-ignoring this, but you can consider it now. Romain, you may want to unmerge #388616 from #409434 and downgrade #409434 to important. Yes, I'll do it. Ok this is done. If the release team is willing to put the etch-ignore tag, the coresponding bug is now #388616. If not, I would perform the changes discussed. Romain -- mama say son, you've got to stay home today there's a hole in the roof you've got to make it waterproof
Re: Upgrade
Le jeudi 8 février 2007 22:17, Steve Langasek a écrit : I think the bug #388616 should be granted this etc-ignore. The configuration file is never shiped with the package nor generated by the software. It is generated in config/ directory, and happen normaly only at first install. My question here is, if the software looks for the config in /var/lib out of necessity, why does the package ship a symlink under /etc/ when that symlink a) will overwrite any attempts by the user to turn this into a real file (for whatever reason), and b) will complicate upgrades in the future when mediawiki's FHS bug is fixed so that the conffile *can* be moved to /etc? Yes we could just remove the link and add a file like README.mediawiki or any other name in which we just explain where the user can find the confile... Indeed, that would propably be enought to close the two other bug for a small amount of change this time. Romain -- Blessed is the man that walketh not in the counsel of the ungodly, nor standeth in the way of sinners, nor sitteth in the seat of the scornful. - Psalm 1:1
Re: mediawiki1.7 in etch..
Hi ! Le mercredi 10 janvier 2007 11:43, vous avez écrit : However, now a new upstream 1.7.2 has been published today to correct a security issue in 1.7.x branch. Given that the changelog not only includes a security fix, I don't know what should be done for mediawiki1.7 in etch. Either we update to 1.7.2-1 or we update to 1.7.1-6 with only security changes backported (they are not important, I think I have already isolated a single line change..). Please upload -6 with the security fix and mail -release again, so that the package can be unblocked then. Package entered unstable today ! Romain -- Everyday is just a holiday, I don't care what the crowd may say. I live the life I love with you, Having fun while they are feeling blue.
mediawiki1.7 in etch..
Hi release managers ! On a previous mail discussion, you accepted that mediawiki1.7 was to be updated to current package in sid (1.7.1-5), but since then it has not yet been moved to etch. However, now a new upstream 1.7.2 has been published today to correct a security issue in 1.7.x branch. Given that the changelog not only includes a security fix, I don't know what should be done for mediawiki1.7 in etch. Either we update to 1.7.2-1 or we update to 1.7.1-6 with only security changes backported (they are not important, I think I have already isolated a single line change..). Other question in case we update to 1.7.1-6 is do we update to 1.7.1-5 and then we prepare a 1.7.1-6 or do we update directly to 1.7.1-6 ? My guess is that the second option will occur... The latest package that propably will be uploaded to sid is located at: http://www.rastageeks.org/~toots/mediawiki/ Thanks for your answers. Romain -- They tried to fool the black population, By telling them that Jah Jah dead. But II know that Jah no dead! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Some packages that may enter testing.
Hi RMs ! I have two packages that may enter testing before etch is released: geekast: Last updated has removed dependencies on gstreamer0.8 and hence would allow to remove gstreamer0.8 before etch is released linuxdcpp: Upstream has corrected a security issue, according to [1] This package may add two additional issues that I have to tell you about: * The dcpp core has been updated, hence the binary package name should be changed. I want to switch back to linuxdcpp now that the 0.691 is no more needed (was for non backward compatibility means). But I feel this as a minor issue, and such package would have to go through NEW again so mays be too long. * The binary now links against libssl0.9.8 Thanks for your work Romain [1]: http://cvs.berlios.de/cgi-bin/viewcvs.cgi/*checkout*/linuxdcpp/linuxdcpp/Changelog.txt?rev=HEADcontent-type=text/plain -- And the Spirit and the bride say, Come. And let him that heareth say, Come. And let him that is athirst come. And whosoever will, let him take the water of life freely. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some packages that may enter testing.
Le samedi 16 décembre 2006 14:48, Marc 'HE' Brockschmidt a écrit : linuxdcpp: Upstream has corrected a security issue, according to [1] This package may add two additional issues that I have to tell you about: * The dcpp core has been updated, hence the binary package name should be changed. I want to switch back to linuxdcpp now that the 0.691 is no more needed (was for non backward compatibility means). But I feel this as a minor issue, and such package would have to go through NEW again so mays be too long. * The binary now links against libssl0.9.8 I have and will not accept this package in its current state. The number of fixes is too big and the diff is not reviewable in a reasonable time. Please isolate a fix for the security issue (and whatever else you consider to be an important bug) and give us the package for review. Well, the core upgrade IS the bug correction. Also, the core is at first a windows program, adapted for linux, on top of which runs the GTK GUI. In other words, to the windows code is also modified for linux, so that makes a very hard sum of changes to parse for isolating the security fix. Anyway, I will have a look at that, but I'm not sure I'll have a lot of time for it. Romain -- In the beginning, there was but one concept, And that's the concept of I. Then arose Apollyon, the Devil - Satan! Satan! - claiming that it's you and I. And from that day on, There was trouble in the world
update for mediawiki
Hi release managers ! Together with the mediawiki packaging team, we have prepared an update for mediawiki which solves two bugs, namely #401808 and #399886. This update is only a change in the debian/control file, it does not introduce any change, and will help the package to fit better for etch. In particular it would allow one to install the application with postgresql, which is a great improvement for few changes. Could you consider allowing this update to enter testing ? Romain -- Everyday is just a holiday, I don't care what the crowd may say. I live the life I love with you, Having fun while they are feeling blue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
