Bug#788615: jessie-pu: package libgee-0.8/0.16.1-2
Am 19.06.2015 um 23:36 schrieb Michael Biebl: Lintian complained about the -2~deb8u1 version, so I uploaded -1+deb8u1 (which happens to be identical to -2 aside from the first line in the changelog) Thanks, Adam. Emilio rightfully points out, that I'm not actually Adam :-) So let me try again: Thanks Adam for handling this bug report (and all your other amazing work). Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#788615: jessie-pu: package libgee-0.8/0.16.1-2
Am 14.06.2015 um 23:18 schrieb Adam D. Barratt: On Sun, 2015-06-14 at 18:47 +0200, Michael Biebl wrote: Am 14.06.2015 um 17:29 schrieb Adam D. Barratt: [...] Assuming that the intention is to simply rebuild -2 on Jessie, then -2~deb8u1 would be more self-explanatory (as an additional changelog stanza on top of -2). Well, I wasn't planning on adding an additional changelog entry on top of -2, but rather do this: diff --git a/debian/changelog b/debian/changelog index bb1e475..59fef1b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,4 +1,4 @@ -libgee-0.8 (0.16.1-2) unstable; urgency=medium +libgee-0.8 (0.16.1-1+deb8u1) jessie; urgency=medium I just wasn't sure, what the preferred versioning is, in case the changes in stable and unstable were identical. Either way round works. -1+deb8u1 as above, as jessie plus some other changes (which happen to be equivalent to -2), or -2~deb8u1 as backport -2 to jessie. In the latter case I'd expect the changelog to have -2~deb8u1 as a simple rebuild for jessie entry, followed by the -2 to unstable, in the same way as one would for a backports upload. Lintian complained about the -2~deb8u1 version, so I uploaded -1+deb8u1 (which happens to be identical to -2 aside from the first line in the changelog) Thanks, Adam. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
avast_premier_antivirus_ZeNiX_setup.exe - 2015.10.0.2022
CÓPIA EXECUTÁVEL DO AVAST 2015 QUE PERMITE A ATIVAÇÃO COM ZeNiX. http://www.4shared.com/file/r1M33Yhzce/avast_premier_antivirus_ZeNiX_.html Acesse http://conv.ly/tonyallbr e aproveite de excelentes programas com serial de ativação.
Re: Request for permission to upload MariaDB 10.0.19 with debian/* bugfixes and security fixes together
Hello Otto, Julien and Adam, On Fri, Jun 19, 2015 at 08:49:25AM +0300, Otto Kekäläinen wrote: Hello! Ok, thanks for the review. If I revert the two bug fixes commented by Julien below from the jessie branch, and nobody comments in X days, then it is OK to upload 10.0.19 to Jessie? Thanks! I'm fine with going ahead with the mariadb-10.0 DSA given a final ack of Julien and Adam on the debian/* related changes. Could you please attach the final resulting debdiff with all above changes? p.s.: in the git version: + * Removed /var/log/mysql.log from logrotate. No mysql related log should be + not directly under /var/log. The correct place is in /var/log/mysql a small typo/error (double negation about mysql log location files). Regards, Salvatore signature.asc Description: Digital signature
Bug#789133: transition: ocaml 4.02.2
On 18/06/15 09:50, Stéphane Glondu wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Managers and OCaml Maintainers, I would like to start the transition to OCaml 4.02.2 (released yesterday) as soon as possible. This version has been preceded by a release candidate, which I used to test-rebuild all the packages. It breaks some packages; most of them have been fixed in experimental and/or in git. As usual, it involves a lot of binNMUs; I will take care of those. The bug number in the tracker: https://release.debian.org/transitions/html/ocaml.html should be updated now. Attached is the list of packages appearing in the tracker, with an annotation: - unstable if the package can be binNMUed - experimental if the package has to be uploaded from experimental - UNRELEASED if the package has to be uploaded from git (though I am not sure I've pushed everything I should have) - MISSING if the package has not been built for some reason (FTBFS, missing dependency, resource exhaustion) Out of 256 packages, 41 are MISSING. LLVM packages are probably OK but take too much disk space for my sandbox. Other notable MISSING packages include dose3, camlimages and js-of-ocaml but I am confident they are fixed upstream and just need an update. They also include packages that are not in testing such as ocamlduce, jocaml or janest-core. Once the transition has started, and all not-MISSING packages have been compiled, it should be possible for everyone to fix MISSING ones but for now, it's delicate because all dependencies have to be recompiled in order... I see some of the failing packages have in the log: - Finished parsing the build-deps Wrong version of OCaml! That does that mean the package couldn't be built because of the dependency problems you mention? My only concern here is that with 41 failing packages, the transition may take quite a while to finish, blocking other stuff. That'd be different if most of those packages will just build fine after the binNMUs, but I have no idea if that's the case... I do wonder how many of those are actual failures, of those, how many are maintained by the ocaml team and how many are not... BTW if you have filed bugs for the failing packages, please make them block this tracking bug. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5583f555.10...@debian.org
Bug#756867: transition: gdal
On 17/06/15 01:22, Sebastiaan Couwenberg wrote: On 06/16/2015 01:21 AM, Emilio Pozuelo Monfort wrote: On 14/06/15 13:28, Sebastiaan Couwenberg wrote: On 06/14/2015 04:29 AM, Julien Cristau wrote: On Fri, Jun 12, 2015 at 17:39:14 +0200, Sebastiaan Couwenberg wrote: This hasn't been an issue before, so I'm tempted to ignore it. Unless the Release Team wants this addressed, then we'll need to update gdal in jessie first. It needs to be addressed, with no changes in jessie. That probably means changing the libgdal binary package name, AIUI. OK, since changing the package name is now required for each patch release of GDAL, Why? It is only required now because your rdeps don't have strict dependencies for the C++ symbols, and you're breaking that. Once they have strict dependencies, you don't need to rename the package, just change the Provides: gdal-abi-1-11-0, and rebuild the rdeps that depend on that (i.e. the C++ rdeps). Not changing the package name at every patch release is good to avoid lengthy delays through the NEW queue. But I don't see much practical difference between having the upstream version in the package name and have the alternative dependency template on the C++ symbols. Most gdal rdeps depend on some C++ symbols, there are only a few that don't need a rebuild at every new patch release. OK. It seemed easier to append the version to the package name, combining the SONAME derived package name for the C library and the -version for the C++ library like for do for geos for instance. I don't mind either way. You can try to educate your upstream to not break the ABI at every release (especially at minor / point releases). Though unfortunately some upstreams don't care much about ABI stability... having the alternative dependency for the C++ symbols doesn't have much benefit anymore. It still does. The package rename is a one time thing to ensure that all your C++ rdeps get proper strict dependencies and they don't break whenever you break your ABI (because they would depend on gdal-abi-1-11-0 and for say 1.11.1, you change the provides to gdal-1-11-1, and so the libgdal package can't be upgraded unless the rdeps are upgraded too). See e.g. what qtbase-opensource-src (libqt5core5a binary) does with its Provides: qtbase-abi-*. It may be better to just include the upstream version in the package name (e.g. libgdal1-1.11.2 libgdal20-2.0.0) and drop the alternative dependency for the C++ symbols. That's possible, but it's not better. OK, I'll keep the alternative dependency template for the C++ symbols and change the package name. libgdal1i seems an obvious choice to succeed libgdal1h. ACK. I have updated the transition tracker for that. I'll stick to the libgdal.so.1-1.11.2 virtual package that was initially suggest in this transition bug to not break the gdal 1.11.2 as included in Ubuntu. Switching to the more common naming convention of gdal-abi-2-0-0 for GDAL 2.0 seems like a good idea. OK. The name doesn't matter much. And I don't mind all that much if you go through Provides or through renaming the binary package. Your call. GDAL upstream started a vote to bless GDAL 2.0.0 RC1 as final, so the final release is expected soon. I've started packaging the pre-releases but I expect we'll need to resolve quite a number of issues in the reverse dependencies to work with GDAL 2.0.0 before we can consider it for unstable. With that in mind I still prefer to first move GDAL 1.11.2 from experimental to unstable so we can use experimental for GDAL 2.0.0. It does mean another gdal transition in the near future for 1.11 - 2.0. There would be another transition for the 1.11 - 2.0 update, but only involving the C++ rdeps (assuming the C ABI stays stable). But either way that's not a problem. If 1.11 is ready now, let's do that first. 1.11 has been ready for quite some time now, I'd like to get it into unstable as soon as possible. This conflicts with the (uncoordinated) mapnik transition, which is currently stalled due to #788533. I see that is maintained by the same team as gdal, so maybe you can take a look or ping the right people? gdal can probably go after that, if no other issues arise. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5583fb2f.7020...@debian.org
Bug#756867: transition: gdal
On 06/19/2015 01:21 PM, Emilio Pozuelo Monfort wrote: On 17/06/15 01:22, Sebastiaan Couwenberg wrote: On 06/16/2015 01:21 AM, Emilio Pozuelo Monfort wrote: On 14/06/15 13:28, Sebastiaan Couwenberg wrote: On 06/14/2015 04:29 AM, Julien Cristau wrote: On Fri, Jun 12, 2015 at 17:39:14 +0200, Sebastiaan Couwenberg wrote: This hasn't been an issue before, so I'm tempted to ignore it. Unless the Release Team wants this addressed, then we'll need to update gdal in jessie first. It needs to be addressed, with no changes in jessie. That probably means changing the libgdal binary package name, AIUI. OK, since changing the package name is now required for each patch release of GDAL, Why? It is only required now because your rdeps don't have strict dependencies for the C++ symbols, and you're breaking that. Once they have strict dependencies, you don't need to rename the package, just change the Provides: gdal-abi-1-11-0, and rebuild the rdeps that depend on that (i.e. the C++ rdeps). Not changing the package name at every patch release is good to avoid lengthy delays through the NEW queue. But I don't see much practical difference between having the upstream version in the package name and have the alternative dependency template on the C++ symbols. Most gdal rdeps depend on some C++ symbols, there are only a few that don't need a rebuild at every new patch release. OK. It seemed easier to append the version to the package name, combining the SONAME derived package name for the C library and the -version for the C++ library like for do for geos for instance. I don't mind either way. You can try to educate your upstream to not break the ABI at every release (especially at minor / point releases). Though unfortunately some upstreams don't care much about ABI stability... The C API is pretty stable, the combination of the both the C C++ API in the same library makes it more difficult to deal with for gdal. Other GIS projects like GEOS and libLAS a separate C C++ libraries, that may be a good idea for GDAL too. It's unfortunate that one of the facts documented in the README.Debian for gdal is not true anymore: - the only official API that should be used by all programs is the C one. At the moment this is generally respected, so forcing a library migration should be considered pointless in general. The alternative dependency template for the C++ symbols shows that most reverse dependencies don't limit themselves to the C API only. I'm not well versed enough in the subject matter to educate upstream about it. I therefor very much appreciate the help I've received in this and earlier gdal transitions to improve the situation for the gdal package in Debian. having the alternative dependency for the C++ symbols doesn't have much benefit anymore. It still does. The package rename is a one time thing to ensure that all your C++ rdeps get proper strict dependencies and they don't break whenever you break your ABI (because they would depend on gdal-abi-1-11-0 and for say 1.11.1, you change the provides to gdal-1-11-1, and so the libgdal package can't be upgraded unless the rdeps are upgraded too). See e.g. what qtbase-opensource-src (libqt5core5a binary) does with its Provides: qtbase-abi-*. It may be better to just include the upstream version in the package name (e.g. libgdal1-1.11.2 libgdal20-2.0.0) and drop the alternative dependency for the C++ symbols. That's possible, but it's not better. OK, I'll keep the alternative dependency template for the C++ symbols and change the package name. libgdal1i seems an obvious choice to succeed libgdal1h. ACK. I have updated the transition tracker for that. Thanks for the tracker update. The updated gdal package was uploaded yesterday and is currently in NEW because of the library package rename: https://ftp-master.debian.org/new/gdal_1.11.2+dfsg-1~exp4.html I'll stick to the libgdal.so.1-1.11.2 virtual package that was initially suggest in this transition bug to not break the gdal 1.11.2 as included in Ubuntu. Switching to the more common naming convention of gdal-abi-2-0-0 for GDAL 2.0 seems like a good idea. OK. The name doesn't matter much. And I don't mind all that much if you go through Provides or through renaming the binary package. Your call. I'm tempted to reconsider the approach again, but I won't. I'll stick to the chosen path now that I'm finally convinced the best approach is taken with the package rename + alternative dependency template. GDAL upstream started a vote to bless GDAL 2.0.0 RC1 as final, so the final release is expected soon. I've started packaging the pre-releases but I expect we'll need to resolve quite a number of issues in the reverse dependencies to work with GDAL 2.0.0 before we can consider it for unstable. With that in mind I still prefer to first move GDAL 1.11.2 from experimental to unstable so we can use experimental for GDAL
Bug#789214: jessie-pu: package cloud-init/0.7.6~bzr976-2 - -3
On 06/19/2015 07:14 AM, Julien Cristau wrote: On Fri, Jun 19, 2015 at 00:26:07 +0200, Thomas Goirand wrote: In Sid, I added missing systemd .service files to the cloud-init package, because without them, the ordering when starting cloud-init is completely wrong. With the default OpenStack image at cdimage.debian.org, you may not find out about it, until you add some new daemons in the startup process. I wish to also update cloud-init in Jessie, to fix this issue, and add the missing .service files. I have attached the debdiff between Debian release -2 and -3. 1/ Would you agree with such a change? FWIW, I wouldn't. If the init scripts are broken, fix the init scripts, don't work around them being broken with a more intrusive change. Thanks, Julien How do you propose to fix the change when running with systemd then? (the issue doesn't appear if using sysv-rc...) Thomas -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5583c8d3.4080...@debian.org
Bug#789214: jessie-pu: package cloud-init/0.7.6~bzr976-2 - -3
On 06/19/2015 07:14 AM, Julien Cristau wrote: On Fri, Jun 19, 2015 at 00:26:07 +0200, Thomas Goirand wrote: In Sid, I added missing systemd .service files to the cloud-init package, because without them, the ordering when starting cloud-init is completely wrong. With the default OpenStack image at cdimage.debian.org, you may not find out about it, until you add some new daemons in the startup process. I wish to also update cloud-init in Jessie, to fix this issue, and add the missing .service files. I have attached the debdiff between Debian release -2 and -3. 1/ Would you agree with such a change? FWIW, I wouldn't. If the init scripts are broken, fix the init scripts, don't work around them being broken with a more intrusive change. Thanks, Julien Also, I wanted to highlight that the issue isn't about the init scripts, but about the compat mode of systemd which doesn't work. So there's nothing that can be fixed in the init scripts, unfortunately. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5583cb63.2060...@debian.org
Re: Request for permission to upload MariaDB 10.0.19 with debian/* bugfixes and security fixes together
Hello! Ok, thanks for the review. If I revert the two bug fixes commented by Julien below from the jessie branch, and nobody comments in X days, then it is OK to upload 10.0.19 to Jessie? 2015-06-19 8:12 GMT+03:00 Julien Cristau jcris...@debian.org: On Fri, Jun 19, 2015 at 00:12:52 +0300, Otto Kekäläinen wrote: + * Security: improved hardening flags (hardening=+all,-pie) I'd prefer to defer to the Security Team on this one, as to whether they'd generally accept it in packages they were releasing. Lintian complained that hardening-wrapper is deprecated so it had to be replaced with this. That's irrelevant for stable. We keep changes in stable to a minimum. You can go have fun and break stuff in unstable, not in stable. We have a master branch where we have fun. This jessie branch keeps changes to a minimum and does not break anything. When these changes where done in early 2015 they were well reviewed and tested with the target of getting into Jessie, which it unfortunately missed. This change has been also in the master branch and thus in unstable and testing for many months already without breaking anything. [...] + * Adding mysqld_multi.server_lsb-header.patch, provides LSB headers for +example initscript (Closes: #778762) + * Adding mysqld_multi_confd.patch, makes mysqld_multi reading conf.d +(Closes: #778761) This seems a little featureish. The only packages shipping files in the conf.d folder appear to be MySQL variants, so I guess this isn't too bad. Very few people run multiple different mysqld daemons on the same system, and this thing must have been broken for a long time. Here somebody scratched their own itch and fixed the buggy scripts inherited from older packaging. These have been well reviewed and deemed safe changes. It would be a shame not to release these fixes. There are very few contributors in the MySQL packaging team and we should value the work of new people who show up and provide ready-made patches. Same as above. Cheers, Julien -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAHj_TLCO8T1ee0=Zy6U+e2j=vbjxaonuecvytmnts1vwbti...@mail.gmail.com
Bug#782381: pu: package motif/2.3.4-8
Hi Julien On 19/06/2015 07:08, Julien Cristau wrote: This description of that change is terrible. The symbol is actually removed by 22-disable-1565.patch, this is removing it from the debian packaging metadata, not the library... Also, the way this is handled makes it pretty hard from the diff to figure out what undefining FIX_1565 actually does. Please see revised debdiff attached. Regards Graham diff -Nru motif-2.3.4/debian/changelog motif-2.3.4/debian/changelog --- motif-2.3.4/debian/changelog2014-10-13 09:27:43.0 +0200 +++ motif-2.3.4/debian/changelog2015-06-19 11:17:06.0 +0200 @@ -1,3 +1,13 @@ +motif (2.3.4-6+deb8u1) jessie-proposed-updates; urgency=medium + + * Disable fix for upstream bug #1565 which caused segfaults in +ddd and xpdf (Closes: #781995). + * Remove XmForceGrabKeyboard@Base from d/libxm4.symbols +which was introduced by upstream's updated fix applied in +motif 2.3.4-5 (Closes: #782678). + + -- Graham Inggs gra...@nerve.org.za Fri, 19 Jun 2015 10:55:55 +0200 + motif (2.3.4-6) unstable; urgency=medium * Bump standards-version to 3.9.6 (no changes). diff -Nru motif-2.3.4/debian/libxm4.symbols motif-2.3.4/debian/libxm4.symbols --- motif-2.3.4/debian/libxm4.symbols 2014-10-07 15:57:54.0 +0200 +++ motif-2.3.4/debian/libxm4.symbols 2015-06-19 10:55:45.0 +0200 @@ -257,7 +257,6 @@ XmFontListInitFontContext@Base 2.3.4 XmFontListNextEntry@Base 2.3.4 XmFontListRemoveEntry@Base 2.3.4 - XmForceGrabKeyboard@Base 2.3.4-5~ XmGetAtomName@Base 2.3.4 XmGetColorCalculation@Base 2.3.4 XmGetColors@Base 2.3.4 diff -Nru motif-2.3.4/debian/patches/22-disable-fix-1565.patch motif-2.3.4/debian/patches/22-disable-fix-1565.patch --- motif-2.3.4/debian/patches/22-disable-fix-1565.patch1970-01-01 02:00:00.0 +0200 +++ motif-2.3.4/debian/patches/22-disable-fix-1565.patch2015-06-19 11:10:05.0 +0200 @@ -0,0 +1,22 @@ +Description: Disable fix for upstream bug #1565 + This patch reverts the changes introduced by upstream's fix for + upstream bug #1565 and causes pop menus and keyboard navigation in + menus to revert to their Motif 2.3.3 behaviour. + . + Upstream's original fix broke keyboard navigation in menus (#730026) + and upstream's updated fix (applied in motif 2.3.4-5) caused segfaults + in ddd and xpdf (#781995). +Author: Graham Inggs gra...@nerve.org.za +Bug: http://bugs.motifzone.net/show_bug.cgi?id=1565 +Bug-Debian: https://bugs.debian.org/781995 +Last-Update: 2015-06-19 +--- a/lib/Xm/XmI.h b/lib/Xm/XmI.h +@@ -299,7 +299,6 @@ extern Pixel _XmAssignInsensitiveColor(W + #define FIX_1501 + #define FIX_1521 + #define FIX_1505 +-#define FIX_1565 + + #endif /* _XmI_h */ + /* DON'T ADD ANYTHING AFTER THIS #endif */ diff -Nru motif-2.3.4/debian/patches/series motif-2.3.4/debian/patches/series --- motif-2.3.4/debian/patches/series 2014-10-13 09:27:43.0 +0200 +++ motif-2.3.4/debian/patches/series 2015-06-19 10:58:12.0 +0200 @@ -19,3 +19,4 @@ 19-fix-type-inconsistencies.patch 20-fix-1612.patch 21-fix-1636.patch +22-disable-fix-1565.patch
Bug#789133: transition: ocaml 4.02.2
Le 18/06/2015 17:06, Eric Cooper a écrit : Attached is the list of packages appearing in the tracker, with an annotation: - unstable if the package can be binNMUed - experimental if the package has to be uploaded from experimental - UNRELEASED if the package has to be uploaded from git (though I am not sure I've pushed everything I should have) - MISSING if the package has not been built for some reason (FTBFS, missing dependency, resource exhaustion) Is any further information (build logs etc.) available about the MISSING packages? Build logs and binary packages are available at: http://ocaml.debian.net/debian/ocaml-4.02.2%2Brc1/pool/ Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5583ed33.1090...@debian.org
Bug#756867: transition: gdal
(Moving the discussion to #788533; #756867 bcc'ed) On 19/06/15 14:40, Sebastiaan Couwenberg wrote: The mips* FTBFS are a recurring problem for the mapnik package, previous builds were no different. I'll try to get it to build on a porterbox, but I expect intervention from the buildd admins will be required like last time to make sure only the buildds with the most resources try to build mapnik. See: https://bugs.debian.org/742149 https://bugs.debian.org/729121 I'm not sure there are buildds with more RAM. Note that the package failed in the exact same way on kfreebsd-i386, which has 3GB of RAM + 4GB of swap. Since all these arches are 32bits, more memory is probably not going to help. Instead, perhaps you can make the build take less memory, e.g. by reducing the optimizations (-O1?) or using some flags such as the linker's --no-keep-memory. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558441d2.1050...@debian.org
