Tuesday, October 31, 2017

Issues with the Dojo package on Debian

On main thing that is currently (and has been) delaying the update of the LedgerSMB package in Debian is that it depends on the Dojo package and that has not been updated to a more current version.  The version even in Debian Unstable ('Sid') is only at v1.11.0 while IIRC, the version the LedgeSMB 1.5.x series has been built against is at v1.12.2.
And issues related to Dojo also prevented any version of LedgerSMB from being released with Debian v9 ('Stretch'), because the dojo package was removed from there due to a Failure To Build From Source (FTBFS) bug, #852923. And so LedgerSMB was also removed from Stretch prior to the release of Debian v9 because it depends on the Dojo packages.  (And is still not present in the current Debian Testing, 'Buster', for the same reason.)
That bug is tagged as being "fixed-upstream".  That often means that it was fixed in a newer version of upstream.  What is generally used in Debian to track upstream sources is the debian/watch file. And what is commonly used as a referernce for the results and status of that are in the Package QA and PackageTracker pages for the packages in question, because part of what they display are the results of checks regarding the upstream sources.
However, in the case of Dojo; all that has been getting displayed is an error about not being able to access the upstream archive:
The package has a debian/watch file, but the last attempt to use it for checking for newer upstream versions failed with an error:In watchfile debian/watch, reading webpage failed: 404 Not Found
Which showed that the process was able to find what seemed to be a newer version but was not able to access it. The same thing happens if one goes to the downloads page directly and attempts to download the achive that way (It was listed under 'Other Projects' in the 2nd column of the page.  The link itself shows as the

$ wget
--2017-10-22 09:40:06--
Resolving (
Connecting to (||:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2017-10-22 09:40:06 ERROR 404: Not Found.

That has been the status for quite awhile and I had not seen any updated information, or even any comment, about it in the bug or anywhere else. So I thought I'd do some more research of my own, and one thing I did was to post the following to the dojo IRC channel on freenode:
There seems to be a problem with the 'shrinksafe' link on the downloads page;  attempting to access it in order to download the archive just results in a  'ERROR 404: Not Found" error.
After some discussion clarifying what I was referring to, a response to that was as follows:
it was bundled separately in the dojo 1.1 - 1.3 days
so likely just a left over...
Apropos to that, the original packaging for Dojo when it was brought into Debian was back in 2010 with Dojo v1.3.2, so that matches up.

One thing that was also mentioned by that same someone in the dojo IRC channel, when I mentioned that this was related to the dojo Debian package:
"any serious user will either use a custom build or a CDN reference"
Well perhaps that just shows his (and others who hold similar opinons)  lack of knowledge regarding Debian and Debian packages more than anything else, because after all a Debian package is a "custom build";  one that in this case installs the javascript libraries to a specific and standard directory on a Debian system so that it can be available to whatever would like to use them.

I also sent an email to server-ops at the dojotoolkit site about the issue, advising of the error resulting from attempting to access the archive at the link provided on the downloads page, wondering if that link is even still relevent and closing with the following:
So I'm wondering if the dojo-release-1.13.0-src.tar.gz archive, for instance, has entirely replaced an archive like dojo-release-1.13.0-shrinksafe.tar.gz which is not available any longer because it's no longer needed.
The response I received back regarding that included the following:
Usage of ShrinkSafe is declining and while not formally deprecated, it really hasn't been updated in quite a while other than to make sure it's not broken. Most people today would use either Closure Compiler, Uglify, or webpack.
And yes, the dojo-release tarball would be a suitable replacement.

That all certainly explains why that 'shrinksafe' archive is no longer available (although perhaps not why it's still  being referenced on the Dojo downloads page.

However, I next decided to clone the Debian Dojo packaging Git reposotory to take a direct look at the packaging and its history.  When I checked the most recent version of the debian/watch file there, I found that it is already pointing to the 'src' archive rather than the 'shrinksafe' archive.  Downloaded the most current version in Debian Unstable and checked the debian/watch file there, and found that there it is also pointing to the 'src' file.  So the question becomes;  why are the sites like the still referencing the wrongURL?
What seems to be happening is that the uscan process is not looking in the release subdirectories, even though that seems to be intent of "/release-(\d.*)/" part of the URL being looked at. What I found is that, apparrantly with the 1.11.0~rc3+dfsg-1 verison of the package, the debian/watch file stops working correctly, while in the previous version 1.10.4+dfsg-2 it does works correctly.  The difference appearing to be changing "/release-([\d\.]*)/"   to  "/release-(\d.*)/" in the URL template part the command, apparently instended to "Support development versions" according to the 1.11.0~rc3+dfsg-1  debian/changelog.  Adding those square brackets back in allows it to correctly find and repack the correct version of the archive, which is currently for 1.13.0 (dojo 2 having not yet been released and in any case it's not yet clear that they will be releasing that on the same page).
Sent an update to the debian bug about the issue.

Sunday, October 1, 2017

Debian pkg-perl related package updates

Worked on the following Debian packages today, all of which are under the auspices of the Debian pkg-perl team but which I added to Debian because they are dependencies of the packaging for LedgerSMB.

libmoosex-param-perl - This one has not had a new upstream release since 2007, but has had changes commited by pkg-perl team members which have not yet been released.  This might better have been done last year but taking care of this today with the release and upload to Debian Unstable (Sid) of version 0.02-3 of the Debian package.

libpgobject-perl -  Package updated for a new upstream release and uploaded  Debian Unstable as version 2.000002-1.

libpgobject-type-datetime-perl -  Package updated for a new upstream release and uploaded  to Debian Unstable as version 2.000001-1,

libtemplate-plugin-latex-perl - This one was updated for a new upstream version, 3.12-1, but has since been pending followups about which Debian package for it to Build-Depend on for testing before being released.  Sent another followup email about it.

Monday, July 10, 2017

Debian Perl package updates

Now that Stretch has been released, the Perl modules that I am an uploader for and for which there have been version updates waiting to be packaged can now be worked on, either by me or by others of the Debian pkg-perl team.  This included the following 9 packages:


 Checked the debian-policy package again on 20 June & found that 4.0.0-1 is now in unstable, so will be updating that in the packages I do.

Noted during a pkg-perl LHF (Low-hanging fruits) session in IRC debian-perl that both the Standards version up to 4.0.0  as well as debhelper to version 10, were getting updated.  Checked the debhelper package in Debian and Ubuntu;  10.x is in stretch as well as jessie-backports (but not jessie itself as it only has 9.2x), as well as yakkety (16.10) and xenial-backports (but not xenial itself as that only has 9.2x).  All in all; it looks like it's better to also move them to debhelper 10, and if there are any issues with building for older distributions it just won't be able to do a no-change backport to them.

Friday, July 7, 2017

Update libpgobject-type-bigfloat-perl package in Debian

Besides that there is a new upstream and so the package needs updating in any case, there's also that it is showing up with a "fail" in the CI (Continous Integration) reference at my Packages overview where the package is listed: "This package is failing and has previously passed." Several of the other modules have had similar problems although they also had FTBFS (Failed To Build From Source) issues. Found that it was failing tests, possibly because of things like the upgrade to use Perl 5.24 where the tests are running?  Will see if the issue is still present after the update to the new upstream.

In order to use the command 'dpt orig-import'  (one of the pkg-perl tools) well, it likes to have the upstream git repository URL, looking for entries for it in debian/copyright or an 'upstream-repo' remote setting in the git config, or the information being in a debian/upstream/metadata file. The one other time I tried it I added the 'upstream-repo' remote setting manually. That worked but also ended up adding  upstream tags because it also set up an upstream-repo branch where it brought the tags from upstream in order to check for what is the most recent.  Will have to use something like the 'git push --follow-tags' command (which also only require the one command) instead of the using 'git push -tags' command after pushing the commits like I've in the habit of doing.

This package hasn't had the metadata file yet because the necessary information hasn't been in the distribution archive where it could be referenced.  It is in the new upstream, so downloaded the new upstream archive manually in order to verify the information, then added a metadata file as the file debian/upstream/metadata. Imported the new upstream version, using the 'dpt import-orig' command.  Updated the packaging. Then pushed the commits for the release. And the new package version has been uploaded to Debian.

Sunday, June 25, 2017

LedgerSMB 1.5.8 released

Version 1.5.8 of LedgerSMB has been released:

Changelog for 1.5.8
  • Fix printing of AR/AP transactions results in JavaScript error (Erik H)
  • Fix ODS output appearing on 'Title page' instead of 'Search results' (Erik H)
  • Fix Edit Vendor address misses 'Save' button (Erik H, #2709)
  • Fix Recurring Transactions screen fails on second access (Erik H, #2888)
  • Fix 'On Hand' goods search filter not being applied (Erik H, #2584)
  • Clean up issues found by Debian's 'lintian' (Erik H, Robert C)
  • Fix layout regression of 1.5 in single payment screen (Erik H, #1917)
  • Fix 'Update' on Assembly page resetting BOM count to 1 (Erik H, #2835)
  • Fix 'Update' on Assembly page requiring all BOM lines filled (Erik H, #2835)
  • New 'Welcome' screen after login, helping people find help (Erik H)
  • Updated Indonesian translation (LedgerSMB Transifex Indonesian group)

Erik H is Erik Huelsmann
Robert C is Robert James Clay
Note also that the project is no longer hosted at SourceForge but rather has entirely moved to GitHub and separate hosting for the mailing lists and other resources.

Saturday, June 17, 2017

Monday, June 12, 2017

Packaging Plack::Builder::Conditionals for Debian

  I had been working on updating the dependencies  for the LedgerSMB package in Debian which I am in the process of transitioning to the 1.5.x series and also the ledgersmb-1.5 package and it seems I missed that there is still a Perl module required for it that is not yet packaged for Debian:  Plack::Builder::Conditionals.  (At least, I hadn't yet been able to find it in Debian.)

  Working on taking care of that, I created the ITP (Intend To Package) Debian bug to track it: #863454

I was able to get the initial package completed but some issues were found with it. I corrected all of those and it was then uploaded to the Debian New queue.  It was then accepted into unstable as the package libplack-builder-conditionals-perl.  It was also then made available at the LedgerSMB Ubuntu PPA as well as will be made available at the package repository as necessary.