Bug#887563: corosync prerm will stop pacemaker and not start it again
Hi Ferenc! On Fri, Apr 20, 2018 at 7:59 AM, Ferenc Wágner wrote: > Control: fixed -1 2.4.4-1 > > Nishanth Aravamudan writes: > >> I believe this is because the prerm of corosync.service [...] >> unconditionally stops corosync for all Debian and Ubuntu releases >> (as the init script is installed even if unused by systemd). When >> corosync stops, pacemaker fails to connect to corosync (and the >> pacemaker systemd unit file specifies that pacemaker Requires corosync) >> and also stops. >> >> When the postinst for corosync runs [...] corosync will start, but >> there is no connection between corosync starting (systemd or SysV) and >> pacemaker. > > Right. > >> I think there are two necessary changes to the packaging/upstream to fix >> this: >> >> 1) The systemd unit file should indicate pacemaker is PartOf corosync, >> which will propogate restarts of corosync to pacemaker. This will also >> propogate stops, but as mentioned above, pacemaker already stops when >> corosync stops, so I think it's harmless. > > How would this help? Currently pacemaker.service Requires > corosync.service, which is a stronger (stricter) constraint than PartOf > would be if I read systemd.unit(5) correctly. You are right, and I'm sorry for not updating the Debian bug sooner -- we ended up moving to "BindsTo" not "PartOf" to resolve this in Ubuntu. I spent some time reading the manpage myself and this is how I interpret the relevant section(s): Requires= Configures requirement dependencies on other units. If this unit gets activated, the units listed here will be activated as well. ... This means, since pacemaker.service Requires=corosync.service, that when pacemaker is started, corosync is started (and, iirc, since pacemaker.service also has an After=corosync.service, systemd will start corosync.service first). This does not imply anything further, though, and in the default package configuration, pacemaker has a *hard* dependency on corosync (afaict). Thus, the first line of the next paragraph in the manpage is relevant: Note that this dependency type does not imply that the other unit always has to be in active state when this unit is running This section also mentions the use of BindsTo=, however that only affects the stopping of units, per the manpage. Finally, from PartOf: PartOf= Configures dependencies similar to Requires=, but limited to stopping and restarting of units. When systemd stops or restarts the units listed here, the action is propagated to this unit. So, actually, PartOf is *different* than Requires, and in the case of pacemaker and corosync's dependency relationship, helps reflect the other half of the requirements, but not the existing ones :) What we want to express (I believe) is: 1) Corosync can be started/stopped on its own 2) If pacemaker is started, corosync must be started 3) If corosync is restarted, pacemaker should be restarted pacemaker.service Requires=corosync.service says "When pacemaker is started, corosync should be started. When corosync is stopped, pacemaker is stopped." pacemaker.service PartOf=corosync.service says "When corosync is restarted, pacemaker is restarted. When corosync is stopped, pacemaker is stopped." pacemaker.service BindsTo=corosync.service says "Every state transition corosync goes through, pacemaker will also go through." >> Additionally, the SysV init file should be updated to check if the >> pacemaker SysV status was running before stopping corosync in the >> restart path and start pacemaker as well after starting corosync. > > I don't intend to go there. If you stop Corosync under Pacemaker, > Pacemaker will fail and the node will be fenced. Systemd helps with > this by cleanly stopping Pacemaker (and any other service declaring a > Requires relation to Corosync) beforehand; SysV init has no comparable > mechanisms. And you can't expect the Corosync init script take care of > all possible dependent services (Pacemaker, DLM, cLVM, corosync-notifyd, > whatever). This is part of the reason why I don't really support SysV > init in the HA stack. Yeah, I'm fine with this; I only mentioned it for completeness wrt. the ordering. >> 2) d/rules should call dh_installinit with --restart-after-upgrade. This >> is the default in compat >= 10 (2.4.2-3 is still at 9). That will change >> the prerm and postinst to not stop/start the service on upgrade, but >> simply restart it in the postinst (removals will still stop the >> service). > > Corosync 2.4.4-1 has switched to compat 11, so this is done. Great! >> Now, neither of these actually fix the existing packages unfortunately, >> which will stop pacemaker on the upgrade to a fixed package and thus >> stop pacemaker. I have no idea if there actually is any way to fix this >> for existing packages, since the 'old' prerm will be invoked by dpkg on >> the upgrade path. > > I don't find this a too serious problem. Inconv
Bug#888127: Fix available in 0.7.1
Specifically, https://github.com/ruby-grape/grape-entity/commit/03d3b928ee7d1c48fdfa9bf55b150eee46d5e572 which I believe is in 0.7.0 and 0.7.1. uscan/uupdate finds it, but patches need refreshing, and there is a new build-dependency on ruby-simplecov. -- Nishanth Aravamudan Ubuntu Server Canonical Ltd
Bug#889811: gosa-encrypt-password is broken since PHP7.2's php-mcrypt removal
On Thu, 15 Feb 2018 09:33:27 + Mike Gabriel wrote: > Hi, > > On Mi 07 Feb 2018 14:01:53 CET, Holger Levsen wrote: > > > control: affects -1 src:debian-edu > > # thanks for this bug report, Wolfgang! > > I just notified GONICUS about this issue and Benjamin Zapiec said, > that they will work on a patch. FYI, upstream is resolving this in https://github.com/gosa-project/gosa-core/issues/12 -Nish
Bug#883640: symfony dependency changes
FYI, this seems like it might be resolved in 4.7.25 upstream. https://lab.civicrm.org/dev/core/issues/3#note_2974
Bug#889181: closed by Paul Gevers (Bug#889181: fixed in cacti 1.1.34+ds1-1)
On Tue, Feb 13, 2018 at 3:26 PM, Nish Aravamudan wrote: > While this update did fix the bug in question, it still doesn't pass > DEP8, whereas my backport did :/ Any ideas? My fault, I see 1.1.35+ds1-1 was uploaded with the fix. I'll sync that down. Sorry for the noise! -Nish > On Tue, Feb 6, 2018 at 1:54 PM, Debian Bug Tracking System > wrote: >> This is an automatic notification regarding your Bug report >> which was filed against the cacti package: >> >> #889181: cacti changes for PHP7.2 and dep8 tests >> >> It has been closed by Paul Gevers . >> >> Their explanation is attached below along with your original report. >> If this explanation is unsatisfactory and you have not received a >> better one in a separate message then please contact Paul Gevers >> by >> replying to this email. >> >> >> -- >> 889181: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889181 >> Debian Bug Tracking System >> Contact ow...@bugs.debian.org with problems >> >> >> -- Forwarded message -- >> From: Paul Gevers >> To: 889181-cl...@bugs.debian.org >> Cc: >> Bcc: >> Date: Tue, 06 Feb 2018 21:50:45 + >> Subject: Bug#889181: fixed in cacti 1.1.34+ds1-1 >> Source: cacti >> Source-Version: 1.1.34+ds1-1 >> >> We believe that the bug you reported is fixed in the latest version of >> cacti, which is due to be installed in the Debian FTP archive. >> >> A summary of the changes between this version and the previous one is >> attached. >> >> Thank you for reporting the bug, which will now be closed. If you >> have further comments please address them to 889...@bugs.debian.org, >> and the maintainer will reopen the bug report if appropriate. >> >> Debian distribution maintenance software >> pp. >> Paul Gevers (supplier of updated cacti package) >> >> (This message was generated automatically at their request; if you >> believe that there is a problem with it please contact the archive >> administrators by mailing ftpmas...@ftp-master.debian.org) >> >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Format: 1.8 >> Date: Tue, 06 Feb 2018 22:31:34 +0100 >> Source: cacti >> Binary: cacti >> Architecture: source >> Version: 1.1.34+ds1-1 >> Distribution: unstable >> Urgency: medium >> Maintainer: Cacti Maintainer >> Changed-By: Paul Gevers >> Description: >> cacti - web interface for graphing of monitoring systems >> Closes: 889181 >> Changes: >> cacti (1.1.34+ds1-1) unstable; urgency=medium >> . >>* New upstream version 1.1.34 >> - Includes updates for php7.2 (Closes: #889181) >> Checksums-Sha1: >> 69a571f90eb6bd8e11890db947876b3acaa9fefe 2144 cacti_1.1.34+ds1-1.dsc >> a6b13c3611423cc2e706b60d5bb7cfdb026d00b1 66580 >> cacti_1.1.34+ds1.orig-docs-source.tar.xz >> df446350a1e7c53db2b94bc7c0d35fa2163ca66d 3824107 >> cacti_1.1.34+ds1.orig.tar.gz >> 44eff5fedf4dd898942b1956b9566a79f44e7a03 51712 >> cacti_1.1.34+ds1-1.debian.tar.xz >> Checksums-Sha256: >> faf9ed2bf37a916c527b3e1a80a4091f26ef48e72b3b86435407b76339e68d4c 2144 >> cacti_1.1.34+ds1-1.dsc >> 4e93415bb3e4d4cb126a8ea027378827214bf93e80e73f8718906a94acc7a318 66580 >> cacti_1.1.34+ds1.orig-docs-source.tar.xz >> 1ff8fc4273b6ff6f167bbb1214dd92a71ecfa3dea8a5085c08ca3bb4ddd3e1a0 3824107 >> cacti_1.1.34+ds1.orig.tar.gz >> 56f7f11a4f2a54479b53dc39553a17b2e94ad44b1226890068b4daed4339cf62 51712 >> cacti_1.1.34+ds1-1.debian.tar.xz >> Files: >> 64d7b2736e67c98da799984bf3b4f820 2144 web optional cacti_1.1.34+ds1-1.dsc >> 9f41c097f6beab7281874a473bbf3a86 66580 web optional >> cacti_1.1.34+ds1.orig-docs-source.tar.xz >> 56d2d16363ad5f7771edafebc0a49a62 3824107 web optional >> cacti_1.1.34+ds1.orig.tar.gz >> 4a92b0ec3ce56c015797d8db08e474b5 51712 web optional >> cacti_1.1.34+ds1-1.debian.tar.xz >> >> -BEGIN PGP SIGNATURE- >> >> iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlp6Hz0ACgkQnFyZ6wW9 >> dQrp4gf7BNa9muSi3z2zOmzHiwXFnN4lMUybML5PZe6R7kJhVcOwcQOuIJEs06Zf >> wKI9MyB0Lo+n3HvrrRqyIv7woZPHsAkDC1xHmgjfFuqYqWFXAbuxR2NNFG7HLMLz >> T/Xq5mpiG+oVBiHYDBIbbeQPyK0QOr9zZ/bzK8xxQXMlVg7P/FLhCVRExyTLRjBr >> TipNCpDpheD8I87euvdE+ExJ6AtJey1vEtWtm2ka6dav/nm3lxJBGzumOcxn+151 >> ZS/7HTOdb5AViU4Bi4IZsCOc0ivFJg7me4VVEinmPkOyt+BylGRm2IjGnXY7ZejN >> 9EsR/qhEVCA4vDIflWFCS1CxpmXd6g== >> =rn75 >> -END PGP SIGNATURE- >> >> -- Forwarded message -- >
Bug#889181: closed by Paul Gevers (Bug#889181: fixed in cacti 1.1.34+ds1-1)
While this update did fix the bug in question, it still doesn't pass DEP8, whereas my backport did :/ Any ideas? On Tue, Feb 6, 2018 at 1:54 PM, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the cacti package: > > #889181: cacti changes for PHP7.2 and dep8 tests > > It has been closed by Paul Gevers . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Paul Gevers > by > replying to this email. > > > -- > 889181: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889181 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > -- Forwarded message -- > From: Paul Gevers > To: 889181-cl...@bugs.debian.org > Cc: > Bcc: > Date: Tue, 06 Feb 2018 21:50:45 + > Subject: Bug#889181: fixed in cacti 1.1.34+ds1-1 > Source: cacti > Source-Version: 1.1.34+ds1-1 > > We believe that the bug you reported is fixed in the latest version of > cacti, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 889...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Paul Gevers (supplier of updated cacti package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Tue, 06 Feb 2018 22:31:34 +0100 > Source: cacti > Binary: cacti > Architecture: source > Version: 1.1.34+ds1-1 > Distribution: unstable > Urgency: medium > Maintainer: Cacti Maintainer > Changed-By: Paul Gevers > Description: > cacti - web interface for graphing of monitoring systems > Closes: 889181 > Changes: > cacti (1.1.34+ds1-1) unstable; urgency=medium > . >* New upstream version 1.1.34 > - Includes updates for php7.2 (Closes: #889181) > Checksums-Sha1: > 69a571f90eb6bd8e11890db947876b3acaa9fefe 2144 cacti_1.1.34+ds1-1.dsc > a6b13c3611423cc2e706b60d5bb7cfdb026d00b1 66580 > cacti_1.1.34+ds1.orig-docs-source.tar.xz > df446350a1e7c53db2b94bc7c0d35fa2163ca66d 3824107 cacti_1.1.34+ds1.orig.tar.gz > 44eff5fedf4dd898942b1956b9566a79f44e7a03 51712 > cacti_1.1.34+ds1-1.debian.tar.xz > Checksums-Sha256: > faf9ed2bf37a916c527b3e1a80a4091f26ef48e72b3b86435407b76339e68d4c 2144 > cacti_1.1.34+ds1-1.dsc > 4e93415bb3e4d4cb126a8ea027378827214bf93e80e73f8718906a94acc7a318 66580 > cacti_1.1.34+ds1.orig-docs-source.tar.xz > 1ff8fc4273b6ff6f167bbb1214dd92a71ecfa3dea8a5085c08ca3bb4ddd3e1a0 3824107 > cacti_1.1.34+ds1.orig.tar.gz > 56f7f11a4f2a54479b53dc39553a17b2e94ad44b1226890068b4daed4339cf62 51712 > cacti_1.1.34+ds1-1.debian.tar.xz > Files: > 64d7b2736e67c98da799984bf3b4f820 2144 web optional cacti_1.1.34+ds1-1.dsc > 9f41c097f6beab7281874a473bbf3a86 66580 web optional > cacti_1.1.34+ds1.orig-docs-source.tar.xz > 56d2d16363ad5f7771edafebc0a49a62 3824107 web optional > cacti_1.1.34+ds1.orig.tar.gz > 4a92b0ec3ce56c015797d8db08e474b5 51712 web optional > cacti_1.1.34+ds1-1.debian.tar.xz > > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlp6Hz0ACgkQnFyZ6wW9 > dQrp4gf7BNa9muSi3z2zOmzHiwXFnN4lMUybML5PZe6R7kJhVcOwcQOuIJEs06Zf > wKI9MyB0Lo+n3HvrrRqyIv7woZPHsAkDC1xHmgjfFuqYqWFXAbuxR2NNFG7HLMLz > T/Xq5mpiG+oVBiHYDBIbbeQPyK0QOr9zZ/bzK8xxQXMlVg7P/FLhCVRExyTLRjBr > TipNCpDpheD8I87euvdE+ExJ6AtJey1vEtWtm2ka6dav/nm3lxJBGzumOcxn+151 > ZS/7HTOdb5AViU4Bi4IZsCOc0ivFJg7me4VVEinmPkOyt+BylGRm2IjGnXY7ZejN > 9EsR/qhEVCA4vDIflWFCS1CxpmXd6g== > =rn75 > -END PGP SIGNATURE- > > -- Forwarded message -- > From: Nishanth Aravamudan > To: Debian Bug Tracking System > Cc: > Bcc: > Date: Fri, 2 Feb 2018 22:25:24 -0800 > Subject: cacti changes for PHP7.2 and dep8 tests > Package: cacti > Version: 1.1.31+ds1-1 > Severity: normal > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu bionic ubuntu-patch > > Dear Maintainer, > > > In Ubuntu, the attached patch was applied to achieve the following: > > * debian/patches/php72_count_bc_changes.patch: PHP7.2 has deprecated > count() of non-Countable objects. > * debian/patches/update-cactisql.patch: Update cacti.sql for > readstring to community change. > > Note that even with this change, the DEP8 tests fail on Ubuntu 18.04, > with: > > Unexpected output in /var/log/cacti/cacti.log: > 02/02/2018 16:40:07 - AUTOM8 ERROR: The Network ID: 1 is disabled. You must > use the 'force' option to force it's execution. > > Which I think might be because we need to pass force to some URL
Bug#883352: php-doctrine-cache-bundle FTBFS: test failures
This is related to Symfony internal changes. https://github.com/doctrine/DoctrineCacheBundle/issues/101 -- Nishanth Aravamudan Ubuntu Server Canonical Ltd
Bug#889181: cacti changes for PHP7.2 and dep8 tests
Hi Paul, On Feb 4, 2018 04:38, "Paul Gevers" wrote: Hi Nishanth, Thanks for the report and the work with upstream to get this fixed. On 03-02-18 07:25, Nishanth Aravamudan wrote: > In Ubuntu, the attached patch was applied to achieve the following: > > * debian/patches/php72_count_bc_changes.patch: PHP7.2 has deprecated > count() of non-Countable objects. > * debian/patches/update-cactisql.patch: Update cacti.sql for > readstring to community change. I'll most likely just wait for the next upstream release, which I expect to come soon (they release about every other week). Sure, I was not aware of cacti's release schedule and we are moving to 7.2 for 18.04, so just wanted you to be aware. I will sync the update once I see it from Debian. > Note that even with this change, the DEP8 tests fail on Ubuntu 18.04, > with: > > Unexpected output in /var/log/cacti/cacti.log: > 02/02/2018 16:40:07 - AUTOM8 ERROR: The Network ID: 1 is disabled. You must use the 'force' option to force it's execution. > > Which I think might be because we need to pass force to some URL or > check a network enabled box in the script? If I understood upstream correctly about this issue, we should just add the line to the accepted output. Yeah, that is what I will do in our delta, and then it should be part of the sync if you make the same change. -Nish Paul
Bug#887563: correction in source package
Note that my suggestion 1) is actually partially in src:pacemaker (the systemd change).
Bug#865573: git-buildpackage: gbp import-orig git_2.13.1.orig.tar.xz fails
On 22.06.2017 [23:13:27 +0200], Guido Günther wrote: > control: reassign -1 pristine-tar > > On Thu, Jun 22, 2017 at 01:01:09PM -0700, Nishanth Aravamudan wrote: > > Package: git-buildpackage > > Version: 0.8.12.2 > > Severity: normal > > > > Dear Maintainer, > > > > The Ubuntu git importer is unable to import the orig tarballs for the > > latest uploads to Debian for src:git, as pristine-tar is unable to > > recreate the provided orig tarball. > > > > Verbose log is: > > > > # gbp import-orig ../git_2.13.1.orig.tar.xz --pristine-tar --verbose > > gbp:debug: ['git', 'rev-parse', '--show-cdup'] > > gbp:debug: ['git', 'rev-parse', '--is-bare-repository'] > > gbp:debug: ['git', 'rev-parse', '--git-dir'] > > gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', > > 'refs/heads/'] > > gbp:debug: ['git', 'show-ref', 'refs/heads/upstream'] > > gbp:debug: ['git', 'status', '--porcelain'] > > gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', > > 'master:debian/changelog'] > > What will be the source package name? [git] > > What is the upstream version? [2.13.1] > > gbp:debug: ['git', 'tag', '-l', 'upstream/2.13.1'] > > gbp:debug: tar ['-C', '../tmphDjmdz', '-a', '-xf', > > '../git_2.13.1.orig.tar.xz'] [] > > gbp:debug: Unpacked '../git_2.13.1.orig.tar.xz' to '../tmphDjmdz/git-2.13.1' > > gbp:info: Importing '../git_2.13.1.orig.tar.xz' to branch 'upstream'... > > gbp:info: Source package is git > > gbp:info: Upstream version is 2.13.1 > > gbp:debug: ['git', 'show-ref', 'refs/heads/upstream'] > > gbp:debug: ['git', 'add', '-f', '.'] > > gbp:debug: ['git', 'write-tree'] > > gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream'] > > gbp:debug: Will create missing branch 'upstream'... > > gbp:debug: ['git', 'commit-tree', > > '517e235ade1f8ffecdaf048f7f7adb494383bbca'] > > gbp:debug: ['git', 'update-ref', '-m', 'gbp: New upstream version 2.13.1', > > 'refs/heads/upstream', '0ae0e594ef4d5a2756ca561e56c68c0ddee8e6ba'] > > gbp:debug: ['git', 'show-ref', 'refs/heads/pristine-tar'] > > gbp:debug: ['git', 'ls-tree', '-z', 'upstream', '--'] > > gbp:debug: ['git', 'mktree', '-z'] > > gbp:debug: /usr/bin/pristine-tar [] ['commit', '../git_2.13.1.orig.tar.xz', > > '517e235ade1f8ffecdaf048f7f7adb494383bbca'] > > gbp:error: Couldn't commit to 'pristine-tar' with upstream > > '517e235ade1f8ffecdaf048f7f7adb494383bbca': pristine-xz failed to reproduce > > build of ../git_2.13.1.orig.tar.xz > > (Please file a bug report.) > > pristine-tar: command failed: pristine-xz --no-verbose --no-debug --no-keep > > gendelta ../git_2.13.1.orig.tar.xz /tmp/pristine-tar.DKOKI61g5N/wrapper > > pristine-tar: failed to generate delta > > gbp:error: Import of ../git_2.13.1.orig.tar.xz failed: Couldn't commit to > > 'pristine-tar' with upstream '517e235ade1f8ffecdaf048f7f7adb494383bbca': > > pristine-xz failed to reproduce build of ../git_2.13.1.orig.tar.xz > > (Please file a bug report.) > > pristine-tar: command failed: pristine-xz --no-verbose --no-debug --no-keep > > gendelta ../git_2.13.1.orig.tar.xz /tmp/pristine-tar.DKOKI61g5N/wrapper > > pristine-tar: failed to generate delta > > gbp:error: Error detected, Will roll back changes. > > gbp:info: Rolling back branch upstream by deleting it > > gbp:debug: ['git', 'show-ref', 'refs/heads/upstream'] > > gbp:debug: ['git', 'symbolic-ref', 'HEAD'] > > gbp:debug: ['git', 'show-ref', 'refs/heads/master'] > > gbp:debug: ['git', 'branch', '-D', 'upstream'] > > gbp:info: Rolling back branch pristine-tar by deleting it > > gbp:debug: ['git', 'show-ref', 'refs/heads/pristine-tar'] > > gbp:error: Rolled back changes after import error. > > gbp:debug: rm ['-rf', '../tmphDjmdz'] [] > > > > > > And I'm reporting the bug as requested :) > > That's an issue in pristine-tar. Reassigning. D'oh! Sorry about that! > Can you add the pristine-tar version you used? I reproduced the issue (the above is from the same env) in a Debian Sid LXD. # apt policy pristine-tar pristine-tar: Installed: 1.38 Candidate: 1.38 Version table: *** 1.38 500 500 http://httpredir.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status
Bug#846219: Why wasn't the same change made to fusionforge-plugin-extsubproj?
While they are still broken, shouldn't the same changes be made to
$subject binary package:
diff -Nru fusionforge-6.0.4+20160504/debian/control
fusionforge-6.0.4+20160504/debian/control
--- fusionforge-6.0.4+20160504/debian/control 2017-01-01 07:59:40.0
-0800
+++ fusionforge-6.0.4+20160504/debian/control 2017-05-30 15:28:05.0
-0700
@@ -449,7 +449,7 @@
with content-negotiation (application/rdf+xml).
Package: fusionforge-plugin-extsubproj
-Depends: fusionforge-web (=${source:Version}), libarc-php,
fusionforge-plugin-compactpreview, ${misc:Depends}
+Depends: fusionforge-web (=${source:Version}),
fusionforge-plugin-compactpreview, ${misc:Depends}
Architecture: all
Description: FusionForge plugin - External SubProjects
FusionForge provides many tools to aid collaboration in a
diff -Nru fusionforge-6.0.4+20160504/debian/plugins
fusionforge-6.0.4+20160504/debian/plugins
--- fusionforge-6.0.4+20160504/debian/plugins 2017-01-01 07:59:40.0
-0800
+++ fusionforge-6.0.4+20160504/debian/plugins 2017-05-30 15:27:59.0
-0700
@@ -46,7 +46,7 @@
Depends:
Package: fusionforge-plugin-extsubproj
-Depends: libarc-php, fusionforge-plugin-compactpreview
+Depends: fusionforge-plugin-compactpreview
Package: fusionforge-plugin-foafprofiles
Depends:
--
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd
Bug#861637: sassphp: src:sassphp explicitly creates a php7.0 binary package
On 04.05.2017 [10:40:50 +0200], Ondřej Surý wrote: > Source: sassphp > Followup-For: Bug #861637 > > Rhonda, > > like in the attached patch. > > Sorry for not having a better documentation, but I am extremely bad at > documenting my own work. (Would be happy to accept any patches that > makes the documentation of dh-php better though.) I think there is one mistake in the patch, unrelated to my other comment: diff --git a/debian/php7.0-sassphp.php b/debian/php-sassphp.php similarity index 50% rename from debian/php7.0-sassphp.php rename to debian/php-sassphp.php index b102494..228bf89 100644 --- a/debian/php7.0-sassphp.php +++ b/debian/php-sassphp.php @@ -1,2 +1 @@ -mod modules/sass.so mod debian/sass.ini I believe the file should be debian/php-sass.php ? To match what is in d/control. Without this, it appear that php-sass only contains the .so file, but there is no /etc/php/7.1/mods-available/sass.ini created. Thanks, Nish
Bug#861637: sassphp: src:sassphp explicitly creates a php7.0 binary package
On Thu, May 4, 2017 at 11:40 AM, Ondřej Surý wrote: > That's: > > PECL_SOURCE=$(filter-out debian $(DIR_TARGETS),$(wildcard *)) +$(foreach > ver,$(DH_PHP_VERSIONS),$(eval PECL_SOURCE_$(ver) := $(PECL_SOURCE))) > > So something else must be going on there. I have successfully built sass for > coinstallable php 5.6, 7.0 and 7.1. PEBKAC, sorry! Was manually copying the patch in and missed a hunk.
Bug#861637: sassphp: src:sassphp explicitly creates a php7.0 binary package
Hi Ondřej, It appears that this patch assumes a normal PECL extension and I'm not sure sass is one? The build eventually fails with: cp -a undefined build-7.1 cp: cannot stat 'undefined': No such file or directory /usr/share/dh-php/pkg-pecl.mk:60: recipe for target 'configure-7.1-stamp' failed make[1]: *** [configure-7.1-stamp] Error 1 from dh-php.mk: configure-%-stamp: cp -a $(PECL_SOURCE_$(*)) $(SOURCE_DIR) $(foreach ver,$(DH_PHP_VERSIONS),$(eval PECL_SOURCE_$(ver) := $(if $(PACKAGE_XML_$(ver)),$(shell xml2 < $(PACKAGE_XML_$(ver)) | sed -ne "s,^/package/name=,,p")-$(shell xml2 < $(PACKAGE_XML_$(ver)) | sed -ne "s,^/package/version/release=,,p"),undefined))) Since there is no package.xml, this results in undefined? In a quick look through pkg-pecl.mk, I'm not seeing an obvious override for this case? Also, should the above resulting in undefined be a fatal error since the build is going to eventually fail (and maybe with a better message: "unable to determine PECL source version from package.xml"?)
Bug#861364: dgit: empty directories are not representable
On Wed, May 3, 2017 at 8:47 AM, Ian Jackson
wrote:
> Nishanth Aravamudan writes ("Bug#861364: dgit: empty directories are not
> representable"):
>> At least src:software-properties has at one time had empty directories
>> in the source package, e.g. in 0.96.20.5 in xenial on Ubuntu, and git
>> (and thus dgit (via import-dsc) and the Ubuntu git importer) fail to
>> properly represent the srcpkg's contents in the import.
>>
>> Specifically, tests/aptroot/etc/apt/apt.conf.d/ is missing from either
>> import.
>
> Presumably the package breaks without this ?
Yeah, in this case, a developer built a new srcpkg using our imported
tree and it failed to pass the autopkgtests, which depended on this
directory existing.
>> Given that git does not represent empty directories, I'm not sure what
>> we should do here?
>
> Call it a bug in git ? :-) I know that doesn't really help.
Yeah -- Robie is working on fixing git.
> My initial plan was to simply ignore empty directories and hope that
> it didn't matter. If they do matter then we probably don't have a
> good answer.
Agreed -- I think it is generically not possible to know if a given
empty directory matters or not. But it does mean if a goal is to
represent the exact contents of a given source package in the
corresponding git commit -- that's not achievable in the presence of
empty directories, at least by default.
I wanted to file this mostly so our importer and dgit did the same
thing for cases like this :)
Bug#861364: Acknowledgement (dgit: empty directories are not representable)
Note we are tracking the affected source packages which are hitting this at: https://bugs.launchpad.net/usd-importer/+bug/1687057.
Bug#858305: [Python-modules-team] Bug#858305: celeryd: celerdy should depend on python-celery-common?
On Sat, Mar 25, 2017 at 4:52 PM, Brian May wrote: > Nish Aravamudan writes: > >>> I have pushed a change through to git that will fix this on the next >>> release. > > I just uploaded this to unstable. Are you able to test this? I was able to verify the updated package in unstable has the correct dependencies and when 'celeryd' is installed, the appropriate binaries `celery` and `celeryd` are avaiable. Thanks! -Nish
Bug#858305: [Python-modules-team] Bug#858305: celeryd: celerdy should depend on python-celery-common?
On 21.03.2017 [21:26:23 +1100], Brian May wrote: > Nishanth Aravamudan writes: > > > It seems like celeryd incorrectly only depends on python-celery (which > > appears to just the python2 library code), but the init scripts in > > celeryd invoke celery and celeryd, which are (now?) in > > python-celery-common. > > I have pushed a change through to git that will fix this on the next > release. Thank you! > However note that I am not entirely happy with celeryd. The problem > being that the init.d depends on some project directory that is outside > the scope of Debian. As a result choices like python2 or python3 are > arbitrary (unless override in the defaults file) and may be wrong for > the given project. Or may change unexpectedly. e.g. installing > python3-celery will make it default to python3. > > Would be better I think if the project supplied its own init.d script. Agreed, this is the first package I've come across that uses the upstream's initscripts directly (rather than, say, a copy). -- Nishanth Aravamudan Ubuntu Server Canonical Ltd
Bug#858287: Potential fix
--
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd
diff --git a/scripts/dep3changelog.pl b/scripts/dep3changelog.pl
index b7000cc..cebf6cb 100755
--- a/scripts/dep3changelog.pl
+++ b/scripts/dep3changelog.pl
@@ -129,7 +129,7 @@ for my $patch (@patches) {
next;
}
}
- last if (/^---/ || /^\s*$/);
+ last if (/^---/);
chomp;
# only if there was a shebang do we strip comment chars
s/^# // if ($dpatch);
Bug#854821: Reverting 29be63fd restores the old behavior
On 14.02.2017 [20:30:52 +0100], Aurelien Jarno wrote:
> On 2017-02-10 11:50, Nish Aravamudan wrote:
> > Just ran a quick test using a PPA build of glibc with 29be63fd
> > ("debian/patches/localedata/locale-C.diff: switch back transliterations
> > to combining. Closes: #840199" [0] reverted and the test passes in a
> > 17.04 (Zesty) container again.
>
> This change is intentional, and was done to revert an unintentional
> change (see #840199). Now the behaviour is consistent between jessie
> and stretch/sid.
I understand that, the above revert was mostly informational. Reading
the other bug, I see the reasoning behind not changing behavior. But it
seems like this also changes behavior, even if only within Unstable, and
needs some follow-up as phpmyadmin in Unstable will fail to rebuild
(verified just now in the chroot).
Given that this appears in an upstream test that is making an assumption
about \\TRANSLIT support from iconv (meaning that the behavior they are
testing for might be consistent across distributions), I'm not sure what
the best next step would be. Note that the phpmyadmin tests were only
relatively recently enabled at build-time, so that may be why this
wasn't noticed.
Any advice would be greatly appreciated!
Thanks,
Nish
--
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd
Bug#854821: Reverting 29be63fd restores the old behavior
Just ran a quick test using a PPA build of glibc with 29be63fd
("debian/patches/localedata/locale-C.diff: switch back transliterations
to combining. Closes: #840199" [0] reverted and the test passes in a
17.04 (Zesty) container again.
Thanks,
Nish
[0]
https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?id=29be63fde23ee497bb83fc9fee77171d26a7d447
--
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd
Bug#591419: librmagick-ruby should not be installable with imagemagick
On 03.12.2016 [10:24:19 -0200], Antonio Terceiro wrote:
> On Fri, Dec 02, 2016 at 11:12:21AM -0800, Nishanth Aravamudan wrote:
> > Package: ruby-rmagick
> > Version: 2.15.4+dfsg-2
> > Followup-For: Bug #591419
> > User: ubuntu-de...@lists.ubuntu.com
> > Usertags: origin-ubuntu zesty ubuntu-patch
> >
> > I think this should do what is expected. Basically, AIUI, there is a
> > more-than-ABI-specifiable (due to issues upstream and possibly in the
> > Debian package itself (cf.:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846385) dependency
> > between ruby-rmagick and the version of imagemagick compiled against. To
> > that end, add an overriding dependency at build-time.
> >
> > I think what's actually needed currently in ruby-rmagick's case in
> > Debian is a rebuild against the bumped version of imagemagick; if that's
> > done, the autopkgtests would pass. But expressing this dependency
> > explicilty would have caught that and prevented imagemagick from
> > changing in Debian until ruby-rmagick had been rebuilt?
> >
> > Comments more than welcome and appreciated.
> >
> > Thanks!
> > -Nish
> >
> > ## REPLACE THIS WITH ACTUAL INFORMATION
> > -
> > ## Please add all necessary information about why the change needed to go in
> > ## Ubuntu, quote policy, spec or any other background material and why it
> > can
> > ## and should be used in Debian too. If the patch is composed of multiple
> > ## independent pieces, please send them as separate bug reports.
> > ## REPLACE THIS WITH ACTUAL INFORMATION
> > -
> >
> >
> > * d/{control,rules}: use a new substitution variable to specify the
> > hard-dependency on the version of ImageMagick built against
> > (Closes: #591419). Thanks to Adam Conrad for the shell code.
> >
> > Thanks for considering the patch.
> >
> > *** /tmp/tmp6FrTwc/ruby-rmagick_2.15.4+dfsg-2ubuntu1.debdiff
> > diff -Nru ruby-rmagick-2.15.4+dfsg/debian/control
> > ruby-rmagick-2.15.4+dfsg/debian/control
> > --- ruby-rmagick-2.15.4+dfsg/debian/control 2016-08-16 07:29:37.0
> > -0700
> > +++ ruby-rmagick-2.15.4+dfsg/debian/control 2016-12-01 15:36:05.0
> > -0800
> > @@ -28,7 +28,8 @@
> > XB-Ruby-Versions: ${ruby:Versions}
> > Depends: ruby | ruby-interpreter,
> > ${misc:Depends},
> > - ${shlibs:Depends}
> > + ${shlibs:Depends},
> > + ${imagemagick:Depends}
> > Description: ImageMagick API for Ruby
> > RMagick is an interface between the Ruby programming language and the
> > ImageMagick image processing library.
> > diff -Nru ruby-rmagick-2.15.4+dfsg/debian/rules
> > ruby-rmagick-2.15.4+dfsg/debian/rules
> > --- ruby-rmagick-2.15.4+dfsg/debian/rules 2016-08-16 07:29:37.0
> > -0700
> > +++ ruby-rmagick-2.15.4+dfsg/debian/rules 2016-12-01 15:36:05.0
> > -0800
> > @@ -12,3 +12,11 @@
> > find debian/*/usr/share/doc/ruby-rmagick-doc/ \
> > -type f -executable -exec \
> > chmod -x '{}' ';'
> > +
> > +override_dh_gencontrol:
> > + $(eval IMAGEMAGICK_DEP := \
> > + $(shell find debian/ruby-rmagick/ -name RMagick2.so -exec ldd
> > '{}' ';' | \
> > + awk '/\/libMagickCore/ {print $$3}' | xargs dpkg -S | \
> > + awk '{print $$1}' | sed 's/:$$//' | xargs dpkg-query -W \
> > + -f='$${Package} (>= $${Version})'))
> > + dh_gencontrol -- -Vimagemagick:Depends='$(IMAGEMAGICK_DEP)'
>
> Hi, thanks for the patch.
>
> However, I fail to see how this would fix the issue, since it won't help
> with the very problem that a new version of ImageMagick that has no
> SONAME bump breaks ruby-rmagick.
So you're right that it does not "fix" the issue of ImageMagick itself
-- given that is something (as you've responded in the other bug) that
src:imagemagick needs to fix.
> There is a new version of ruby-rmagick which claims support for
> ImageMagick 6.9, and apparently shifts the dependency from libmagickcore
> to libmagickwand ... this might be the correct fix.
However, what the above patch does is, at least for libMagickCore itself
(and that could be adjusted for libMagickWand as well) is ignore the ABI
values from the symbols file -- that's not entirely 'correct', but what
it means is that if the ABI is not correctly describing minimum version,
we will insert a dependency on the version of imagemagick actually used
to build the package at build-time. That does mean the dependency may be
strictly higher than it needs to be, but it also helps accurately
reflect that ruby-rmagick should be rebuilt (so it forces an imagemagick
transition of sorts on every version bump?). Although perhaps the shell
snippet should make the dependency strictly = (rather than >=).
Thanks for the feedback!
-Nish
--
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd
Bug#591419: Same librmagick problem again
> * the second one is that librmagick-ruby is very easily broken by > newer versions of imagemagick, which is actually very hard to track. > This will need some thinking; possibly a solution would be a strict > versioned dependency along if only binNMUs for each imagemagick > release ? What happened to this idea? I think this is the (a?) reason ruby-rmagick is currently failing its autopkgtests, using an imagemagick at runtime that it is not built against? We have seen this on Ubuntu as well, and I wonder if it would be appropriate to just extract the libmagickcore version used at build-time and override the shlib-depends for that package with specifically the built-using version? Thanks to Adam Conrad for this suggestion. I can work on a patch, if it would be acceptable. -Nish -- Nishanth Aravamudan Ubuntu Server Canonical Ltd
Bug#816701: Imagemagick bug: could you retest
On 26.10.2016 [11:59:09 +0200], Bastien ROUCARIES wrote: > control: tags -1 + moreinfo > > Hi, > > I have put the patch could you retest and check if it work ? It does appear that 0083-Fix-a-off-by-one-error-leading-to-segfault.patch in 8:6.8.9.9-5+deb8u5 should have the correct fix now. -Nish -- Nishanth Aravamudan Ubuntu Server Canonical Ltd
Bug#710895: [Pkg-freeradius-maintainers] Bug#710895: freeradius: Added autopkgtests
On 17.11.2016 [22:35:26 +0100], Michael Stapelberg wrote: > Thanks for the patch! Applied and uploaded. > > Tiny request: next time, please send patches formatted using git > format-patch against the git repository. That makes it easier for me to > accept your contributions. Thanks! Absolutely, will keep that in mind! Note that the format of the patch I sent originally is from 'submittodebian', which is the tool I tend to use for submitting delta from Ubuntu to Debian. I wonder if we should update that tool in cases like this, if it's determinable that git patch would be preffered? Thanks, Nish -- Nishanth Aravamudan Ubuntu Server Canonical Ltd
Bug#830178: Possible fix
On Wed, Nov 2, 2016 at 3:00 PM, Sandro Tosi wrote: > On Mon, 26 Sep 2016 17:34:47 -0700 Nish Aravamudan > wrote: >> So I am tracking the same issue seen on Ubuntu 16.10 and I found: >> >> https://github.com/sphinx-doc/sphinx/pull/2396 >> >> I tested the following patch to the sourc3, and it does seem to build, >> although I'm not sure I fully understand why yet (I'm completely new to >> sphinx, just trying to help fix these bugs :) But I think it's because >> upstream sphinx has changed an underlying data structure (index)? >> >> -Nish >> >> --- a/doc/build/templates/genindex.mako >> +++ b/doc/build/templates/genindex.mako >> @@ -21,7 +21,7 @@ >> numcols = 1 >> numitems = 0 >> %> >> -% for entryname, (links, subitems) in entries: >> +% for entryname, (links, subitems, dummy) in entries: >> >> >> % if links: >> > > hey Piotr, did you have a chance to look at this patch? do you think > it's ok to apply to the debian package or would you rather forward it > upstream and ask what they thnk about it? Sorry, I should have updated this bug: upstream mako has picked this up already: https://github.com/zzzeek/mako/pull/20 -Nish
Bug#835582: Possible fix
This gets the build going, but then it eventually seems to fail with:
Failing Tests (2):
LLVM-Unit :: ADT/Release/ADTTests/APIntTest.LargeAPIntConstruction
LLVM-Unit :: ADT/Release/ADTTests/APIntTest.nearestLogBase2
Details on the fails I see (with both 16.10 and sid):
FAIL: LLVM-Unit :: ADT/Release/ADTTests/APIntTest.LargeAPIntConstruction (11248
of 12318)
TEST 'LLVM-Unit ::
ADT/Release/ADTTests/APIntTest.LargeAPIntConstruction' FAILED
Note: Google Test filter = APIntTest.LargeAPIntConstruction
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from APIntTest
[ RUN ] APIntTest.LargeAPIntConstruction
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
0 libLLVM-3.6.so.1 0x7f65fa969b22 llvm::sys::PrintStackTrace(_IO_FILE*) +
50
1 libLLVM-3.6.so.1 0x7f65fa968251
2 libpthread.so.0 0x7f65f9b09670
3 libc.so.60x7f65f91c77ef gsignal + 159
4 libc.so.60x7f65f91c93ea abort + 362
5 libstdc++.so.6 0x7f65f980158d __gnu_cxx::__verbose_terminate_handler()
+ 365
6 libstdc++.so.6 0x7f65f97ff336
7 libstdc++.so.6 0x7f65f97ff381
8 libstdc++.so.6 0x7f65f97ff599
9 libstdc++.so.6 0x7f65f97ffb5c
10 libLLVM-3.6.so.1 0x7f65fa92e9b8 llvm::APInt::initSlowCase(unsigned int,
unsigned long, bool) + 40
11 ADTTests 0x563e2728033a
12 ADTTests 0x563e2741ba3a testing::Test::Run() + 186
13 ADTTests 0x563e2741bb80 testing::TestInfo::Run() + 272
14 ADTTests 0x563e2741bc45 testing::TestCase::Run() + 165
15 ADTTests 0x563e2741f897
testing::internal::UnitTestImpl::RunAllTests() + 583
16 ADTTests 0x563e2741fb82 testing::UnitTest::Run() + 34
17 ADTTests 0x563e27243c56 main + 70
18 libc.so.60x7f65f91b23f1 __libc_start_main + 241
19 ADTTests 0x563e27243cba _start + 42
FAIL: LLVM-Unit :: ADT/Release/ADTTests/APIntTest.nearestLogBase2 (11269 of
12318)
TEST 'LLVM-Unit ::
ADT/Release/ADTTests/APIntTest.nearestLogBase2' FAILED
Note: Google Test filter = APIntTest.nearestLogBase2
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from APIntTest
[ RUN ] APIntTest.nearestLogBase2
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
0 libLLVM-3.6.so.1 0x7f71055cab22 llvm::sys::PrintStackTrace(_IO_FILE*) +
50
1 libLLVM-3.6.so.1 0x7f71055c9251
2 libpthread.so.0 0x7f710476a670
3 libc.so.60x7f7103e287ef gsignal + 159
4 libc.so.60x7f7103e2a3ea abort + 362
5 libstdc++.so.6 0x7f710446258d __gnu_cxx::__verbose_terminate_handler()
+ 365
6 libstdc++.so.6 0x7f7104460336
7 libstdc++.so.6 0x7f7104460381
8 libstdc++.so.6 0x7f7104460599
9 libstdc++.so.6 0x7f7104460b5c
10 libLLVM-3.6.so.1 0x7f710558f9b8 llvm::APInt::initSlowCase(unsigned int,
unsigned long, bool) + 40
11 ADTTests 0x56207be123f8
12 ADTTests 0x56207bfa7a3a testing::Test::Run() + 186
13 ADTTests 0x56207bfa7b80 testing::TestInfo::Run() + 272
14 ADTTests 0x56207bfa7c45 testing::TestCase::Run() + 165
15 ADTTests 0x56207bfab897
testing::internal::UnitTestImpl::RunAllTests() + 583
16 ADTTests 0x56207bfabb82 testing::UnitTest::Run() + 34
17 ADTTests 0x56207bdcfc56 main + 70
18 libc.so.60x7f7103e133f1 __libc_start_main + 241
19 ADTTests 0x56207bdcfcba _start + 42
The patch I applied is:
diff -Nru llvm-toolchain-3.6-3.6.2/debian/rules
llvm-toolchain-3.6-3.6.2/debian/rules
--- llvm-toolchain-3.6-3.6.2/debian/rules 2015-10-20 09:40:08.0
-0700
+++ llvm-toolchain-3.6-3.6.2/debian/rules 2016-09-26 16:38:48.0
-0700
@@ -3,9 +3,10 @@
TARGET_BUILD := build-llvm
DEB_INST := $(CURDIR)/debian/tmp/
#GCC_VERSION := 4.8
-# The 5| in the regexp is a crappy workaround. g++ 5.2 in Debian is not
providing a g++-5.2 binary (only g++-5)
-# accomodate that by hardcoding the 5 detection
-GCC_VERSION := $(shell dpkg-query -W -f '$${Version}' g++ | sed -rne
's,^([0-9]+:)?(5|[0-9]+\.[0-9]+|[0-9]+).*$$,\2,p')
+# The 5|6 in the regexp is a crappy workaround. g++ 5.2 in Debian is not
+# providing a g++-5.2 binary (only g++-5). Similar for g++ 6.x
+# accomodate that by hardcoding the 5/6 detection
+GCC_VERSION := $(shell dpkg-query -W -f '$${Version}' g++ | sed -rne
's,^([0-9]+:)?(5|6|[0-9]+\.[0-9]+|[0-9]+).*$$,\2,p')
LLVM_VERSION := 3.6
LLVM_VERSION_FULL := $(LLVM_VERSION).2
SONAME_EXT := 1
Thanks,
Nish
Bug#830178: Possible fix
So I am tracking the same issue seen on Ubuntu 16.10 and I found: https://github.com/sphinx-doc/sphinx/pull/2396 I tested the following patch to the sourc3, and it does seem to build, although I'm not sure I fully understand why yet (I'm completely new to sphinx, just trying to help fix these bugs :) But I think it's because upstream sphinx has changed an underlying data structure (index)? -Nish --- a/doc/build/templates/genindex.mako +++ b/doc/build/templates/genindex.mako @@ -21,7 +21,7 @@ numcols = 1 numitems = 0 %> -% for entryname, (links, subitems) in entries: +% for entryname, (links, subitems, dummy) in entries: % if links: -- Nishanth Aravamudan Ubuntu Server Canonical Ltd
Bug#697225: Typo in backport patch
Sorry, there was a bug in my backport, where _END_ was used in the patch rather than __END__. This leads to perl parse errors. Fixing the patch to use __END__ corrects the backport fully. -Nish -- Nishanth Aravamudan Ubuntu Server Canonical Ltd
Bug#830999: [pkg-bacula-devel] Bug#830999: bacula-director-mysql db-config installation fails with reference to ${db_name}
On 15.07.2016 [17:48:08 +0200], Carsten Leonhardt wrote:
> tags 830999 + confirmed patch
> thanks
>
> Dear Nish,
>
> > That seems very right to me, I will try and test it here too.
> >
> > update_mysql_tables.in
> > update_mysql_tables_10_to_11.in
> > update_mysql_tables_11_to_12.in
> >
> > may need similar changes (they did in 7.4.1+dfsg-1, and I haven't
> > rebased yet to check if they still apply).
>
> I've committed a different fix to git now which doesn't need to touch
> all these files.
Great, thanks!
> > Also, depending on the source, you may want to ensure that
> > update_mysql_tables.in's db_name assignemnt properly uses the
> > ${db_name:-@db_name@} so that environment variables can be used with it.
>
> You mean for people not using dbconfig-common?
Yeah, iirc, the scripts end up living in /usr/share/bacula-director/ and
are sometimes referenced online as a way to manually do migrations, etc.
I believe upstream has made the referenced changed already, in a bugfix:
http://www.bacula.org/git/cgit.cgi/bacula/commit/?h=Branch-7.4&id=074419ac0c9dbbde2e4d2f5ccb6d4ca85c6ec8a9
Bug#830999: [pkg-bacula-devel] Bug#830999: bacula-director-mysql db-config installation fails with reference to ${db_name}
On 14.07.2016 [01:17:54 +0200], Carsten Leonhardt wrote:
> tags 830999 + confirmed patch
> thanks
>
> Dear Nish,
>
> > Ubuntu 16.10 is currently in-sync with Debian unstable's packaging and
> > I am seeing an installation failure with bacula-director-mysql.
>
> thank you for your bug report. I can confirm the error and I have
> commited a - so far untested - fix to our git repository¹. I'll make an
> upload once I have done some tests, probably tomorrow.
That seems very right to me, I will try and test it here too.
update_mysql_tables.in
update_mysql_tables_10_to_11.in
update_mysql_tables_11_to_12.in
may need similar changes (they did in 7.4.1+dfsg-1, and I haven't
rebased yet to check if they still apply).
Also, depending on the source, you may want to ensure that
update_mysql_tables.in's db_name assignemnt properly uses the
${db_name:-@db_name@} so that environment variables can be used with it.
Thanks,
Nish
--
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd
Bug#813549: cobbler: New version available upstream
Note that uscan/uupdate seems to pick up this new version fine. Also, updating would fix Bug # 830302 without needing to patch. -- Nishanth Aravamudan Ubuntu Server Canonical Ltd
Bug#829764: [pkg-php-pear] Bug#829764: php-monolog: add stage1 and nocheck build profiles
On 05.07.2016 [16:51:48 -0400], David Prévot wrote: > Hi Nishanth, > > Le 05/07/2016 à 16:19, Nishanth Aravamudan a écrit : > > Package: php-monolog > […] > > * Add nocheck and stage1 build profiles. > > Thanks for your patch. Please, do commit it directly: I have no way to > test it nor any setup to maintain it anyway, besides being able to > revert it in case it breaks (broken) expectations in Debian infrastructure. Done, looking at master's history, I believe you'll take care of the corresponding changelog entry? Thanks, Nish
Bug#829005: [Pkg-monitoring-maintainers] Bug#829005: ganglia-webfrontend: runtime dependency on php-xml
On 29.06.2016 [19:50:44 +0200], Daniel Pocock wrote: > > > On 29/06/16 19:33, Nishanth Aravamudan wrote: > > Package: ganglia-web > > Version: 3.6.1-2 > > Severity: normal > > Tags: patch > > User: ubuntu-de...@lists.ubuntu.com > > Usertags: origin-ubuntu yakkety ubuntu-patch > > > > Dear Maintainer, > > > > In Ubuntu, the attached patch was applied to achieve the following: > > > > * ganglia-webfrontend: Add run-time dependency on php-xml as the code > > calls xml_parser_create(), etc (LP: #1577916). > > > > Thanks for considering the patch. > > Hi Nishanth, > > Thanks for this contribution. > > Is the patch only needed for Ubuntu or also for Debian stretch now? Also for stretch (PHP7.0 only) afaict. Ubuntu 16.04 and Debian stretch have basically the same dependency requirements. > Would you like to help maintain the package in alioth, do you already > have an account there? We use Git to track all the packaging files. I do, I can commit it there, if that would be preferred; I've been hesitant to do so, just in case I break something :)
Bug#827483: [pkg-horde] Bug#827483: php-horde-mapi: fix autopkgtest errors
On 19.06.2016 [21:30:48 +0200], Mathieu Parent wrote: > )Control: clone -1 -2 > Control: reassign -1 php-horde-mapi 1.0.8-2 > Control: tag -1 + patch > Control: tag -2 + patch wontfix > > 2016-06-19 9:46 GMT+02:00 Nish Aravamudan : > > On 18.06.2016 [16:50:23 -0400], David Prévot wrote: > [...] > >> I disagree, and stand to what I’ve written in the last changelog entry: > >> > >> Actually fixing the constructors requires to also fix all their calls, > >> both internally and externally. This backward-incompatible change has > >> been achieved in version 2 of phpseclib, packaged in Debian as > >> php-phpseclib to ensure co-installability. (Closes: #819420) > > Okay. I agree with you David. > > > Right, my original patch in this e-mail was just to quieten the > > deprecated call from this testcase, as it's not really a failure (any > > output on stderr is treated as a failure). > > > >> From http://phpseclib.sourceforge.net/: > >> > >> The 2.0 branch has pretty much the exact same API as the 1.0 branch, > >> save for that it is namespaced, uses PHP5-style constructors (thereby > >> avoiding E_DEPRECATED errors) and requires the use of an autoloader. > [...] > > Agreed, and perhaps something like the attached (which passes > > autopkgtests for me) can be applied to Debian's package (and we can sync > > in Ubuntu) and massaged to be sent upstream? I apologize if this is way > > off-base, I'm not all a PHP developer :) > > Thanks Nish. You patch looks good. > > Some notes: > - In d/control, use php-phpseclib (>= 2~) as < and > operators are > obsolete (see man:dpkg(1)) > - "use phpseclib\Math;" is probably not needed as you use fully > qualified names after (see > http://php.net/manual/en/language.namespaces.importing.php) > - Can you send this upstream (using github.com/horde/horde or bugs.horde.org)? I'm working on this latter part today. Also, I just got a ping in a different upstream bug that maybe is relevant here, about this idea: http://cweiske.de/tagebuch/php4-constructors-php7.htm. Not sure why I didn't think of that myself, but it would avoid the issue that led to the regression in phpseclib, afaict, as the externally visible API would stay the same.
Bug#827483: [pkg-horde] Bug#827483: php-horde-mapi: fix autopkgtest errors
On 19.06.2016 [21:30:48 +0200], Mathieu Parent wrote: > )Control: clone -1 -2 > Control: reassign -1 php-horde-mapi 1.0.8-2 > Control: tag -1 + patch > Control: tag -2 + patch wontfix > > 2016-06-19 9:46 GMT+02:00 Nish Aravamudan : > > On 18.06.2016 [16:50:23 -0400], David Prévot wrote: > [...] > >> I disagree, and stand to what I’ve written in the last changelog entry: > >> > >> Actually fixing the constructors requires to also fix all their calls, > >> both internally and externally. This backward-incompatible change has > >> been achieved in version 2 of phpseclib, packaged in Debian as > >> php-phpseclib to ensure co-installability. (Closes: #819420) > > Okay. I agree with you David. > > > Right, my original patch in this e-mail was just to quieten the > > deprecated call from this testcase, as it's not really a failure (any > > output on stderr is treated as a failure). > > > >> From http://phpseclib.sourceforge.net/: > >> > >> The 2.0 branch has pretty much the exact same API as the 1.0 branch, > >> save for that it is namespaced, uses PHP5-style constructors (thereby > >> avoiding E_DEPRECATED errors) and requires the use of an autoloader. > [...] > > Agreed, and perhaps something like the attached (which passes > > autopkgtests for me) can be applied to Debian's package (and we can sync > > in Ubuntu) and massaged to be sent upstream? I apologize if this is way > > off-base, I'm not all a PHP developer :) > > Thanks Nish. You patch looks good. > > Some notes: > - In d/control, use php-phpseclib (>= 2~) as < and > operators are > obsolete (see man:dpkg(1)) > - "use phpseclib\Math;" is probably not needed as you use fully > qualified names after (see > http://php.net/manual/en/language.namespaces.importing.php) > - Can you send this upstream (using github.com/horde/horde or bugs.horde.org)? > > I'll apply your patch once I have some time to test. Another question I had about this, since I was thinking about it. The current pkg-php-tools-overrides file for php-horde-mapi has: pear.php.net Math_BigInteger none Would it make sense to have php-seclib/php-phpseclib (appropriately versioned) provide this in the overrides file? Then the control file wouldn't need a manual modification, AIUI. Just trying to understand if that is the more maintainable approach. Thanks, Nish
Bug#827698: Fixed in 780414, but then reverted?
I'm quite confused by the current state of this package -- the zendframework dependency was removed in 1.1.1-1 (and 780414 correspondingly marked closed), but then it was introduced again in 1.1.1-2 (hence this bug). There isn't much explanation in the changelog as to why this churn occurred or if there is an intent to fix it?
Bug#827695: [pkg-php-pear] Bug#827695: zendframework: Rename zend-framework in Ubuntu to allow for a package sync
On 19.06.2016 [16:06:04 -0400], David Prévot wrote: > Hi, > > Le 19/06/2016 à 15:35, Nishanth Aravamudan a écrit : > > Package: zendframework > > Version: 1.12.18+dfsg-1 > […] > > I am hoping to get rid of the Ubuntu zend-framework package and simply > > sync the zendframework package from Debian. > > I’m not clear about why Debian should carry Ubuntu-specific hacks for > Ubuntu-specific transitions. Why not simply make those changes directly > in the zend-framework Ubuntu-specific package? Yes, we can do that (and would), but I was asked to see if I could push it to Debian so that we can sync instead of merge for this delta. Thanks for the feedback. > zendframework is targeted for removal ASAP anyway. Any help into fixing > the current reverse dependencies would be welcome, some bugs already > filed are affecting zendframework, maybe more need to be filed. > > https://bugs.debian.org/zendframework Ah, interesting! I'm a bit concerned by the fact the upstream icinga2 author responded in February to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814143 and no response was made in return. They seem to depend on ZF1 directly, and can't/won't move to ZF2/ZF3. Would Stretch drop icinga2 then?
Bug#827483: [pkg-horde] Bug#827483: php-horde-mapi: fix autopkgtest errors
On 19.06.2016 [21:30:48 +0200], Mathieu Parent wrote: > )Control: clone -1 -2 > Control: reassign -1 php-horde-mapi 1.0.8-2 > Control: tag -1 + patch > Control: tag -2 + patch wontfix > > 2016-06-19 9:46 GMT+02:00 Nish Aravamudan : > > On 18.06.2016 [16:50:23 -0400], David Prévot wrote: > [...] > >> I disagree, and stand to what I’ve written in the last changelog entry: > >> > >> Actually fixing the constructors requires to also fix all their calls, > >> both internally and externally. This backward-incompatible change has > >> been achieved in version 2 of phpseclib, packaged in Debian as > >> php-phpseclib to ensure co-installability. (Closes: #819420) > > Okay. I agree with you David. > > > Right, my original patch in this e-mail was just to quieten the > > deprecated call from this testcase, as it's not really a failure (any > > output on stderr is treated as a failure). > > > >> From http://phpseclib.sourceforge.net/: > >> > >> The 2.0 branch has pretty much the exact same API as the 1.0 branch, > >> save for that it is namespaced, uses PHP5-style constructors (thereby > >> avoiding E_DEPRECATED errors) and requires the use of an autoloader. > [...] > > Agreed, and perhaps something like the attached (which passes > > autopkgtests for me) can be applied to Debian's package (and we can sync > > in Ubuntu) and massaged to be sent upstream? I apologize if this is way > > off-base, I'm not all a PHP developer :) > > Thanks Nish. You patch looks good. > > Some notes: > - In d/control, use php-phpseclib (>= 2~) as < and > operators are > obsolete (see man:dpkg(1)) Got it, thanks! > - "use phpseclib\Math;" is probably not needed as you use fully > qualified names after (see > http://php.net/manual/en/language.namespaces.importing.php) Good point, I'll test and fix this up. > - Can you send this upstream (using github.com/horde/horde or bugs.horde.org)? Yep, I'll do this first thing Monday! Thanks again for your help! -Nish -- Nishanth Aravamudan Ubuntu Server Canonical Ltd
Bug#827483: [pkg-horde] Bug#827483: php-horde-mapi: fix autopkgtest errors
On 18.06.2016 [16:50:23 -0400], David Prévot wrote:
> Hi,
>
> Le 18/06/2016 à 16:32, Mathieu Parent a écrit :
>
> > Some other things may break, but I'll vote still vote for this patch,
> > as only 6 packages depends on it.
> >
> > David, what do you think?
>
> I disagree, and stand to what I’ve written in the last changelog entry:
>
> Actually fixing the constructors requires to also fix all their calls,
> both internally and externally. This backward-incompatible change has
> been achieved in version 2 of phpseclib, packaged in Debian as
> php-phpseclib to ensure co-installability. (Closes: #819420)
Right, my original patch in this e-mail was just to quieten the
deprecated call from this testcase, as it's not really a failure (any
output on stderr is treated as a failure).
> From http://phpseclib.sourceforge.net/:
>
> The 2.0 branch has pretty much the exact same API as the 1.0 branch,
> save for that it is namespaced, uses PHP5-style constructors (thereby
> avoiding E_DEPRECATED errors) and requires the use of an autoloader.
>
> A proper fix to the deprecated constructor syntax is maintained
> upstream, provided in Debian via php-phpseclib (version 2). If you want
> to use it, you should depend on php-phpseclib instead of php-seclib
> (helping various upstreams to move away from version 1 to version 2 will
> probably be a better use of our collective time than patching the
> version 1 ourselves).
Agreed, and perhaps something like the attached (which passes
autopkgtests for me) can be applied to Debian's package (and we can sync
in Ubuntu) and massaged to be sent upstream? I apologize if this is way
off-base, I'm not all a PHP developer :)
-Nish
diff -Nru php-horde-mapi-1.0.8/debian/changelog
php-horde-mapi-1.0.8/debian/changelog
--- php-horde-mapi-1.0.8/debian/changelog 2016-06-08 00:09:58.0
-0700
+++ php-horde-mapi-1.0.8/debian/changelog 2016-06-19 00:42:35.0
-0700
@@ -1,3 +1,9 @@
+php-horde-mapi (1.0.8-3) unstable; urgency=medium
+
+ * debian/patches/use_phpseclibv2.patch: Move to php-phpseclib v2 API.
+
+ -- Nishanth Aravamudan Sun, 19 Jun 2016
00:42:07 -0700
+
php-horde-mapi (1.0.8-2) unstable; urgency=medium
* Update Standards-Version to 3.9.8, no change
diff -Nru php-horde-mapi-1.0.8/debian/control
php-horde-mapi-1.0.8/debian/control
--- php-horde-mapi-1.0.8/debian/control 2016-06-08 00:09:58.0 -0700
+++ php-horde-mapi-1.0.8/debian/control 2016-06-19 00:41:58.0 -0700
@@ -11,7 +11,7 @@
Package: php-horde-mapi
Architecture: all
-Depends: ${misc:Depends}, ${phppear:Debian-Depends}, php-seclib (<< 2~)
+Depends: ${misc:Depends}, ${phppear:Debian-Depends}, php-phpseclib (> 2~)
Recommends: ${phppear:Debian-Recommends}
Breaks: ${phppear:Debian-Breaks}
Description: ${phppear:summary}
diff -Nru php-horde-mapi-1.0.8/debian/patches/series
php-horde-mapi-1.0.8/debian/patches/series
--- php-horde-mapi-1.0.8/debian/patches/series 1969-12-31 16:00:00.0
-0800
+++ php-horde-mapi-1.0.8/debian/patches/series 2016-06-19 00:41:51.0
-0700
@@ -0,0 +1 @@
+use_phpseclibv2.patch
diff -Nru php-horde-mapi-1.0.8/debian/patches/use_phpseclibv2.patch
php-horde-mapi-1.0.8/debian/patches/use_phpseclibv2.patch
--- php-horde-mapi-1.0.8/debian/patches/use_phpseclibv2.patch 1969-12-31
16:00:00.0 -0800
+++ php-horde-mapi-1.0.8/debian/patches/use_phpseclibv2.patch 2016-06-19
00:43:13.0 -0700
@@ -0,0 +1,88 @@
+Description: Move to php-phpseclib v2 API
+ Use the v2 php-phpseclib library.
+Author: Nishanth Aravamudan
+
+--- a/Horde_Mapi-1.0.8/lib/Horde/Mapi.php
b/Horde_Mapi-1.0.8/lib/Horde/Mapi.php
+@@ -20,6 +20,9 @@
+ * @authorMichael J Rubinsky
+ * @package Mapi_Utils
+ */
++
++use phpseclib\Math;
++
+ class Horde_Mapi
+ {
+ /**
+@@ -169,13 +172,13 @@
+ 'A'=>'10', 'B'=>'11', 'C'=>'12', 'D'=>'13', 'E'=>'14',
'F'=>'15'
+ );
+
+-$bci = new Math_BigInteger('0');
++$bci = new phpseclib\Math\BigInteger('0');
+ $len = strlen($str);
+ for ($i = 0; $i < $len; ++$i) {
+-$bci = $bci->multiply(new Math_BigInteger('16'));
++$bci = $bci->multiply(new phpseclib\Math\BigInteger('16'));
+ $ch = $str[$i];
+ if (isset($hex[$ch])) {
+-$bci = $bci->add(new Math_BigInteger($hex[$ch]));
++$bci = $bci->add(new phpseclib\Math\BigInteger($hex[$ch]));
+ }
+ }
+
+@@ -184,14 +187,14 @@
+
+ /**
+ *
+- * @param Math_BigInteger $bci
++ * @param phpseclib\Math\BigInteger $bci
+ * @return string
+ */
+ protected static function _win64ToUnix($bci)
+ {
+ // Unix epoch as a Windows file date-time value
+-$t = $bci->subtract(new Math_BigInteger('116444735995904000'));//
Cast to Unix epoch
+-list($quotient, $remainder) = $t->divide(new
Math_BigInteger('1000'));
++$t = $bci->subtract(new
Bug#827492: [pkg-horde] Bug#827492: php-horde-http: use fully-qualified non-existent domain
On 17.06.2016 [14:21:20 +0200], Mathieu Parent wrote: > 2016-06-17 1:31 GMT+02:00 Nishanth Aravamudan : > > Package: php-horde-http > > Version: 2.1.6-3 > > Severity: wishlist > > Tags: patch > > User: ubuntu-de...@lists.ubuntu.com > > Usertags: origin-ubuntu yakkety ubuntu-patch > > > > Dear Maintainer, > > > > We found a failure in the php-horde-http autopkgtest without the > > following. > > > > In Ubuntu, the attached patch was applied to achieve the following: > > > > - fix_test_domain.patch: use a fully-qualified inexistent domain for > > test suite to prevent test failure in autopkgtest environment. > > > > Thanks for considering the patch. > > Thanks for your patch. > > The test pass on debci. Can you tell me what is specific to Ubuntu here? I'm not sure, I wonder if it's something lower level that is saying the domain was non-existent. > Also were is Ubuntu ci? http://autopkgtest.ubuntu.com/packages/p/php-horde-http/yakkety/amd64/ e.g. Let me debug this some more, feel free to hold off on taking this patch. -Nish
Bug#827483: [pkg-horde] Bug#827483: php-horde-mapi: fix autopkgtest errors
On 17.06.2016 [14:17:49 +0200], Mathieu Parent wrote:
> Control: tag -1 + confirmed + upstream - patch
> Control: reassign -1 + php-seclib 1.0.2-1
> Control: affects -1 + php-horde-mapi
>
>
> 2016-06-16 23:09 GMT+02:00 Nishanth Aravamudan
> :
> > Package: php-horde-mapi
> > Version: 1.0.8-2
> > Severity: wishlist
> > Tags: patch
> > User: ubuntu-de...@lists.ubuntu.com
> > Usertags: origin-ubuntu yakkety ubuntu-patch
> >
> > Dear Maintainer,
> >
> > autopkgtests in Debian and Ubuntu are failing, due to a deprecation
> > warning being emitted on stderr during the test.
> >
> > In Ubuntu, the attached patch was applied to achieve the following:
> >
> > * d/tests/control: allow stderr output, as deprecated warnings from
> > BigInteger are reported with PHP7.0 (LP: #1593003).
> >
> > Thanks for considering the patch.
>
> Hello Nishanth,
>
> Thanks for the patch. I won't merge it, can you fix php-seclib instead
> (while not re-introducing #819420)?
I am happy to try! It seems like the attached patch should do it at
least for all the php-seclib code. I'm not sure there's a way to audit
all source files in Debian that might include a PHP file from php-seclib
and then define a class and not use the non-deprecated constructor
syntax?
Description: Fix "Methods with the same name as their class" deprecation
PHP7 emits a deprecation warning for any class using a same-named
function as a constructor (it should be __construct). Fix phpseclib to
be internally consistent with this requirement.
Author: Nishanth Aravamudan
Bug-Debian: https://bugs.debian.org/827483
--- phpseclib-1.0.2.orig/phpseclib/Crypt/Base.php
+++ phpseclib-1.0.2/phpseclib/Crypt/Base.php
@@ -97,7 +97,7 @@ define('CRYPT_MODE_STREAM', 5);
/**#@+
* @access private
- * @see self::Crypt_Base()
+ * @see self::__construct()
* @internal These constants are for internal use only
*/
/**
@@ -127,7 +127,7 @@ class Crypt_Base
/**
* The Encryption Mode
*
- * @see self::Crypt_Base()
+ * @see self::__construct()
* @var int
* @access private
*/
@@ -316,7 +316,7 @@ class Crypt_Base
/**
* Is the mode one that is paddable?
*
- * @see self::Crypt_Base()
+ * @see self::__construct()
* @var bool
* @access private
*/
@@ -411,7 +411,7 @@ class Crypt_Base
* $aes = new Crypt_AES(CRYPT_AES_MODE_CFB); // $aes will operate in cfb mode
* $aes = new Crypt_AES(CRYPT_MODE_CFB); // identical
*
- * @see self::Crypt_Base()
+ * @see self::__construct()
* @var string
* @access private
*/
@@ -503,7 +503,7 @@ class Crypt_Base
* @param int $mode
* @access public
*/
-function Crypt_Base($mode = CRYPT_MODE_CBC)
+function __construct($mode = CRYPT_MODE_CBC)
{
// $mode dependent settings
switch ($mode) {
@@ -1587,7 +1587,7 @@ class Crypt_Base
/**
* Test for engine validity
*
- * @see self::Crypt_Base()
+ * @see self::__construct()
* @param int $engine
* @access public
* @return bool
@@ -1654,7 +1654,7 @@ class Crypt_Base
*
* If the preferred crypt engine is not available the fastest available one will be used
*
- * @see self::Crypt_Base()
+ * @see self::__construct()
* @param int $engine
* @access public
*/
@@ -1687,7 +1687,7 @@ class Crypt_Base
/**
* Sets the engine as appropriate
*
- * @see self::Crypt_Base()
+ * @see self::__construct()
* @access private
*/
function _setEngine()
--- phpseclib-1.0.2.orig/phpseclib/Crypt/Hash.php
+++ phpseclib-1.0.2/phpseclib/Crypt/Hash.php
@@ -56,7 +56,7 @@
/**#@+
* @access private
- * @see self::Crypt_Hash()
+ * @see self::__construct()
*/
/**
* Toggles the internal implementation
@@ -151,7 +151,7 @@ class Crypt_Hash
* @return Crypt_Hash
* @access public
*/
-function Crypt_Hash($hash = 'sha1')
+function __construct($hash = 'sha1')
{
if (!defined('CRYPT_HASH_MODE')) {
switch (true) {
--- phpseclib-1.0.2.orig/phpseclib/Crypt/RC2.php
+++ phpseclib-1.0.2/phpseclib/Crypt/RC2.php
@@ -351,13 +351,13 @@ class Crypt_RC2 extends Crypt_Base
*
* If not explicitly set, CRYPT_RC2_MODE_CBC will be used.
*
- * @see Crypt_Base::Crypt_Base()
+ * @see Crypt_Base::__construct()
* @param int $mode
* @access public
*/
-function Crypt_RC2($mode = CRYPT_RC2_MODE_CBC)
+function __construct($mode = CRYPT_RC2_MODE_CBC)
{
-parent::Crypt_Base($mode);
+parent::__construct($mode);
}
/**
@@ -365,7 +365,7 @@ class Crypt_RC2 extends Crypt_Base
*
* This is mainly just a wrapper to set things up for Crypt_Base::isValidEngine()
*
- * @see Crypt_Base::Crypt_Base()
+ * @see Crypt_Base::__construct()
* @param int $engine
* @access public
* @return bool
--- phpseclib-1.0.2.orig/phps
Bug#827485: Acknowledgement (phing: properly handle Ubuntu versions in changelog)
I apologize, a stale patch was submitted earlier, here is the correct one: diff --git a/debian/rules b/debian/rules index 32255a7..cb1f09a 100755 --- a/debian/rules +++ b/debian/rules @@ -1,6 +1,6 @@ #!/usr/bin/make -f -UPSTREAM := $(shell head -1 debian/changelog | sed 's/.*(//;s/-.?*).*//') +UPSTREAM := $(shell head -1 debian/changelog | sed 's/.*(//;s/-[^-]*).*//') %: dh $@ --buildsystem=phppear --with phppear
Bug#817751: google-api-php-client: diff for NMU version 1.1.7-0.1
Control: tags 817751 + patch
Control: tags 821577 + patch
Dear maintainer,
I've prepared an NMU for google-api-php-client (versioned as 1.1.7-0.1) and
attached it as a debdiff. Since this is a version bump and the resulting
diff to the source is quite large, I have only attached the diff for the
debian/ directory. Please use uscan/uupdate to pull down the new orig
tarball using the updated watch file.
diff -Nru google-api-php-client-0.6.7/debian/changelog
google-api-php-client-1.1.7/debian/changelog
--- google-api-php-client-0.6.7/debian/changelog2014-05-10
17:31:08.0 -0700
+++ google-api-php-client-1.1.7/debian/changelog2016-05-24
08:33:51.0 -0700
@@ -1,3 +1,13 @@
+google-api-php-client (1.1.7-1) unstable; urgency=medium
+
+ * New upstream release
+ * Update d/watch file to point to github.
+ * Update d/rules references to removed examples.
+ * Update to PHP7.0 dependencies (LP: #1544352, Closes: #821577,
+Closes: #817751).
+
+ -- Nishanth Aravamudan Wed, 23 Mar 2016
16:42:33 -0700
+
google-api-php-client (0.6.7-2) unstable; urgency=medium
* Add ownCloud for Debian to uploaders
diff -Nru google-api-php-client-0.6.7/debian/control
google-api-php-client-1.1.7/debian/control
--- google-api-php-client-0.6.7/debian/control 2014-05-10 17:21:50.0
-0700
+++ google-api-php-client-1.1.7/debian/control 2016-05-23 17:33:29.0
-0700
@@ -12,8 +12,8 @@
Package: php-google-api-php-client
Architecture: all
-Depends: ca-certificates, php5 | php5-cli, php5-curl, ${misc:Depends}
-Recommends: php5-json
+Depends: ca-certificates, php | php-cli, php-curl, ${misc:Depends}
+Recommends: php-json
Description: Google APIs client library for PHP
The Google API client library allows one to work with Google APIs such
as Analytics, Adsense, Google+, Calendar, Drive or Games. It includes
diff -Nru google-api-php-client-0.6.7/debian/rules
google-api-php-client-1.1.7/debian/rules
--- google-api-php-client-0.6.7/debian/rules2014-05-10 17:16:12.0
-0700
+++ google-api-php-client-1.1.7/debian/rules2016-05-24 08:12:06.0
-0700
@@ -2,13 +2,6 @@
%:
dh $@
-override_dh_fixperms:
- dh_fixperms
- chmod -x \
-
$(CURDIR)/debian/php-google-api-php-client/usr/share/doc/php-google-api-php-client/examples/adsensehost/AdSenseHostAuth.php
\
-
$(CURDIR)/debian/php-google-api-php-client/usr/share/doc/php-google-api-php-client/examples/adsensehost/examples/*.php
\
-
$(CURDIR)/debian/php-google-api-php-client/usr/share/doc/php-google-api-php-client/examples/youtube/*.php
-
override_dh_compress:
dh_compress -X.php
diff -Nru google-api-php-client-0.6.7/debian/watch
google-api-php-client-1.1.7/debian/watch
--- google-api-php-client-0.6.7/debian/watch2014-05-10 17:16:12.0
-0700
+++ google-api-php-client-1.1.7/debian/watch2016-05-23 17:26:57.0
-0700
@@ -1,3 +1,3 @@
-version=3
-http://code.google.com/p/google-api-php-client/downloads/list?can=1 \
-//google-api-php-client.googlecode.com/files/google-api-php-client-(.+)\.tar\.gz
+version=4
+opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%google-api-php-client-$1.tar.gz%"
\
+https://github.com/google/google-api-php-client/releases
(?:.*?/)?v?(\d[\d.]*)\.tar\.gz
signature.asc
Description: PGP signature
Bug#821475: auth2db upstream abandoned?
Hi Ondřej, In a simple googling and such, and given `uscan` output, it seems like upstream auth2db has been abandoned. Do we still want to package it? If so, I can send the patch we used in Ubuntu 16.04, but maybe it's better to simply remove it as crufty. -Nish
Bug#814952: numactl: Fix FTBS when all file timestamps are updated
On 13.03.2016 [12:50:29 +1100], Ian Wienand wrote:
> On Tue, Feb 16, 2016 at 03:11:04PM -0800, Nishanth Aravamudan wrote:
> > # find . -exec touch {} \;
> > # debian/rules build
>
> > /root/numactl-2.0.11/build-aux/missing: line 81: aclocal-1.14: command not
> > found
> > WARNING: 'aclocal-1.14' is missing on your system.
>
> I'm not sure this is unexpected; if you go and touch all the generated
> files and configure thinks they have been modified, it will try to
> regenerate them.
I think I wasn't quite clear in my original report.
> I don't understand why you would want to do this and why it would make
> it a FTBFS bug?
The above quote is a way to reproduce the issue, in my experience, but I
saw it specifically after:
$ git clone https://git.dgit.debian.org/numactl
$ cd numactl && fakeroot ./debian/rules binary
...
DPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash
/home/nacc/debian/numactl/build-aux/missing aclocal-1.14 -I m4
/home/nacc/debian/numactl/build-aux/missing: line 81: aclocal-1.14:
command not found
WARNING: 'aclocal-1.14' is missing on your system.
You should only need it if you modified 'acinclude.m4' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'aclocal' program is part of the GNU Automake package:
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
Bug#816724: php-imagick: update d/tests/control
On 04.03.2016 [09:11:01 -0800], Nishanth Aravamudan wrote: > Source: php-imagick > Version: 3.4.0~rc6-2 > Severity: important > Tags: patch > > Dear Maintainer, > > php-imagick's autopkgtests currently fail, due to some missing steps to > properly run phpunit and missing test dependencies. > > P.S. Additionally, two imagemagick bugs need fixing in order to fully pass > the tests (#811308 which is marked fixed but the included backport is > missing key fixes from upstream; and a bug I just filed to backport a > fix for a segfault [will update this bug with that # once I've received > it]. Second imagemagick bug is #816701.
Bug#811308: imagemagick: Missing upstream fix for 'PixelColor off by one on i386'
On 25.02.2016 [10:54:51 -0800], Nish Aravamudan wrote: > On 25.02.2016 [09:29:44 -0800], Nishanth Aravamudan wrote: > > Package: imagemagick > > Version: 8:6.8.9.9-7 > > Followup-For: Bug #811308 > > > > Dear Maintainer, > > > > While working on Ubuntu 16.04, I noticed that the currently sync'd > > version of imagemagick, 8:6.8.9.9-7 has backported the fixes for > > https://github.com/ImageMagick/ImageMagick/issues/54, but missed one > > change: > > https://github.com/ImageMagick/ImageMagick/commit/95c8394eaacc8c2f272177269416daf0b2ba004f. > > > > The patches git commit in question is: > > http://anonscm.debian.org/cgit/collab-maint/imagemagick.git/commit/?h=debian-patches/6.8.9.9-7&id=f40ae7899afa53437ea99f7be105e549e85b0c47 > > > > Note also that since the bugfix in question came from a version greater > > than 0x689 but the Debian package's version number has not been > > modified, I think that other packages (e.g., php-imagick) can't use the > > version number any longer to determine if/when a test has been fixed. > > Ah, actually I was slightly wrong about this, as there is another > upstream commit that seems to have been missed that is really the reason > for the testcase failure I'm seeing: > > https://github.com/ImageMagick/ImageMagick/commit/d60548249a3370e481ef43f206b6af95c9dd7364#diff-b48c4feab32724d54e6e77845f23f7cc Sorry for the noise, but there are (eventually) three upstream commits that are needed on top of the current backport in Debian: https://github.com/ImageMagick/ImageMagick/commit/d6054824 https://github.com/ImageMagick/ImageMagick/commit/95c8394e https://github.com/ImageMagick/ImageMagick/commit/68c6a7d -Nish
Bug#811308: imagemagick: Missing upstream fix for 'PixelColor off by one on i386'
On 25.02.2016 [09:29:44 -0800], Nishanth Aravamudan wrote: > Package: imagemagick > Version: 8:6.8.9.9-7 > Followup-For: Bug #811308 > > Dear Maintainer, > > While working on Ubuntu 16.04, I noticed that the currently sync'd > version of imagemagick, 8:6.8.9.9-7 has backported the fixes for > https://github.com/ImageMagick/ImageMagick/issues/54, but missed one > change: > https://github.com/ImageMagick/ImageMagick/commit/95c8394eaacc8c2f272177269416daf0b2ba004f. > > The patches git commit in question is: > http://anonscm.debian.org/cgit/collab-maint/imagemagick.git/commit/?h=debian-patches/6.8.9.9-7&id=f40ae7899afa53437ea99f7be105e549e85b0c47 > > Note also that since the bugfix in question came from a version greater > than 0x689 but the Debian package's version number has not been > modified, I think that other packages (e.g., php-imagick) can't use the > version number any longer to determine if/when a test has been fixed. Ah, actually I was slightly wrong about this, as there is another upstream commit that seems to have been missed that is really the reason for the testcase failure I'm seeing: https://github.com/ImageMagick/ImageMagick/commit/d60548249a3370e481ef43f206b6af95c9dd7364#diff-b48c4feab32724d54e6e77845f23f7cc -- Nishanth Aravamudan Ubuntu Server Canonical Ltd
Bug#814858: Additional test fix for pkg-php-tools 1.32 (when using PHP7.0)
Since php-json has been merged into php7.0 (as opposed to from
src:php-json with PHP5), I noticed that the error message in one of the
tests is incorrect.
* tests/PhpcomposerSourceTest.php: update php-json error message
Not-signed-off-by: Nishanth Aravamudan
---
Note that I know this isn't quite right, because now the test will fail
with PHP5 versions of php-json. I'm not quite sure how the test should
be fixed in this case, though -- should it have two functions with
different @requires? It seems like the phpunit @requires syntax implies
>= which doesn't work for specifying exact versions (or in this case
families, e.g. '@requires PHP 5'). I'm hoping someone with more
experience can provide the right syntax.
diff --git a/tests/PhpcomposerSourceTest.php b/tests/PhpcomposerSourceTest.php
index 0c65bad..23ef3a3 100644
--- a/tests/PhpcomposerSourceTest.php
+++ b/tests/PhpcomposerSourceTest.php
@@ -44,7 +44,7 @@ class PhpcomposerSourceTest extends
PHPUnit_Framework_TestCase {
/**
* @expectedException InvalidArgumentException
- * @expectedExceptionMessage Error parsing composer.json: Syntax error,
malformed JSON (quoted object property name expected)
+ * @expectedExceptionMessage Error parsing composer.json: Syntax error,
malformed JSON (Syntax error)
*/
public function testBrokenOpen() {
// Open a directory with a broken composer.json
--
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd
Bug#813125: phpcs upstream issue [was: php-proxy-manager 2.0.0* has a dependency on a new PHP API PackageVersions]
On 09.02.2016 [15:17:17 -0400], David Prévot wrote: > Hi Nish, > > Le 09/02/2016 15:05, Nish Aravamudan a écrit : > > > I was finally able to get to this, and I see build failures using that > > base (due to phpcs issues): > > > > phpcs --standard=PSR2 ./src/ > […] > > I can fix this up on my end by putting in a staged build, but it seems > > like something needs to be fixed still? > > That’s probably caused by a new issue in php-codesniffer 2.5.1, e.g., > > https://github.com/squizlabs/PHP_CodeSniffer/issues/876 Did you mean an issue with 2.5.0? > FWIW, the build runs fine with php-codesniffer 2.5.1 (not in the > archive, but I can push my update to the VCS if you wish), but > php-codesniffer 2.5.1 does break other packages build, so I’d prefer to > see an upstream php-codesniffer (and php-proxy-manager) fix before > uploading it (unless I push both to experimental for the time being, > would that be useful?). Well, for the purposes of syncing with Debian, it's probably only worth pushing something to experimental once upstream has the fixes in, I agree. I'll just wait on those and I'll request a sync once Debian updates. -Nish -- Nishanth Aravamudan Ubuntu Server Canonical Ltd
Bug#813125: [pkg-php-pear] Bug#813125: Bug#813125: php-proxy-manager 2.0.0* has a dependency on a new PHP API PackageVersions
On 30.01.2016 [09:10:58 -0400], David Prévot wrote: > Le 29/01/2016 18:45, Nish Aravamudan a écrit : > > On 29.01.2016 [18:31:11 -0400], David Prévot wrote: > >> Le 29/01/2016 12:39, Nishanth Aravamudan a écrit : > >>> […] it has a dependency that prevents it > >>> from successfully packaging currently. The upstream code has introduced > >>> a new dependency on https://github.com/Ocramius/PackageVersions, which I > >>> am guessing would need to be packaged as a new package, i.e., > >>> php-package-versions. > >> > >> I instead patched the package to not use this new dependency. > > > > Ok, I'll look at your version when it's in the VCS tomorrow. > > > http://anonscm.debian.org/cgit/pkg-php/php-proxy-manager.git/commit/?id=599baa2548cfc9be768f7436c9457796acad2094 > I was finally able to get to this, and I see build failures using that base (due to phpcs issues): phpcs --standard=PSR2 ./src/ FILE: 0.0/src/ProxyManager/Exception/InvalidProxiedClassException.php -- FOUND 2 ERRORS AFFECTING 2 LINES -- 54 | ERROR | [x] Multi-line function call not indented correctly; | | expected 20 spaces but found 24 59 | ERROR | [x] Multi-line function call not indented correctly; | | expected 24 spaces but found 28 -- PHPCBF CAN FIX THE 2 MARKED SNIFF VIOLATIONS AUTOMATICALLY -- FILE: 0/src/ProxyManager/ProxyGenerator/LazyLoadingGhostGenerator.php -- FOUND 1 ERROR AFFECTING 1 LINE -- 150 | ERROR | [x] Multi-line function call not indented correctly; | | expected 12 spaces but found 16 -- PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY -- FILE: ...-2.0.0/src/ProxyManager/ProxyGenerator/RemoteObjectGenerator.php -- FOUND 1 ERROR AFFECTING 1 LINE -- 75 | ERROR | [x] Multi-line function call not indented correctly; | | expected 20 spaces but found 24 -- PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY -- FILE: .../src/ProxyManager/ProxyGenerator/Assertion/CanProxyAssertion.php -- FOUND 1 ERROR AFFECTING 1 LINE -- 90 | ERROR | [x] Multi-line function call not indented correctly; | | expected 12 spaces but found 16 -- PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY -- FILE: 0/src/ProxyManager/ProxyGenerator/Util/ProxiedMethodsFilter.php -- FOUND 1 ERROR AFFECTING 1 LINE -- 83 | ERROR | [x] Multi-line function call not indented correctly; | | expected 12 spaces but found 16 -- PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY -- FILE: ...anager-2.0.0/src/ProxyManager/ProxyGenerator/Util/Properties.php -- FOUND 1 ERROR AFFECTING 1 LINE -- 59 | ERROR | [x] Multi-line function call not indented correctly; | | expected 20 spaces but found 24 -- PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY -- FILE: ...rc/ProxyManager/ProxyGenerator/Util/UnsetPropertiesGenerator.php -- FOUND 1 ERROR AFFECTING 1 LINE -- 104 | ERROR | [x] Multi-line function call not indented correctly; | | expected 20 spaces but found 24
Bug#813125: [pkg-php-pear] Bug#813125: php-proxy-manager 2.0.0* has a dependency on a new PHP API PackageVersions
On 29.01.2016 [18:31:11 -0400], David Prévot wrote: > Hi, > > Le 29/01/2016 12:39, Nishanth Aravamudan a écrit : > > Package: php-proxy-manager > > Version: 2.0.0-* > > Not in Debian. Yes, I understand that. I apologize for not being clear. It seems like the upstream maintainer is stating that phpunit failures with PHP7 + 1.2.0 are expected -- so we'd need to update the tests in the Debian & Ubuntu packages. > > While updating the packages in an Ubuntu Xenial PPA to use PHP7.0 by > > default, I ran into phpunit failures with the php-proxy-manager package. > > From #811431: > > Again (#810526#10), you may wish to not file such bugs currently [0]: > the (soon to be) ongoing transition of php will require a lot of rebuild > (and NEW processing). We already know that, but all the tools are not > yet in place. > > 0: https://lists.debian.org/debian-devel-announce/2016/01/msg2.html Yep, I'm aware of this and am in contact with Ondřej on the progress in Ubuntu for the same transitions (I've got phpunit bootstrapped at this point but am hitting another build-depends cycle). > > The same issues should be seen with Debian unstable. > > FWIW, with what is currently in Debian, I don’t get such issue. Right, because, I'm expecting that the php-proxy-manager package is still depending on PHP5, rather than PHP7. > > I see that per https://packages.qa.debian.org/p/php-proxy-manager.html, > > there is a 2.0.0~beta1 available to package. > > Even 2.0.0~beta2, I already prepared the package for experimental, will > push my changes to the VCS tomorrow. Ok, thanks, I'll take a look! > > […] it has a dependency that prevents it > > from successfully packaging currently. The upstream code has introduced > > a new dependency on https://github.com/Ocramius/PackageVersions, which I > > am guessing would need to be packaged as a new package, i.e., > > php-package-versions. > > I instead patched the package to not use this new dependency. Ok, I'll look at your version when it's in the VCS tomorrow. -- Nishanth Aravamudan Ubuntu Server Canonical Ltd
Bug#603894: yaboot: mkofboot needs updating to correctly recognize PowerStation CPUs
Package: yaboot Version: 1.3.13a-1squeeze1 Severity: normal mkofboot currently contains the following lines: if (cat /proc/cpuinfo 2> /dev/null | grep ^machine | grep -q 'CHRP IBM'); then fstype=raw else fstype=hfs I believe the conditional check needs to be extended to also recognize the PPC970MP processors in the PowerStation. With the code as-is, the installer consistently fails to successfully reboot after installation. By commenting out the conditional altogether and forcing fstype=raw, I was able to succesfully reboot the machine after installation. -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: powerpc (ppc64) Kernel: Linux 2.6.32-5-powerpc64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages yaboot depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib Versions of packages yaboot recommends: pn hfsutils (no description available) ii powerpc-utils 1.1.3-24 Various utilities for Linux/PowerP yaboot suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
