Wednesday, December 6, 2017

Issue with LedgerSMB 1.5 dependencies at PPA

An issue with the versions of some of the dependencies for the ledgersmb-1.5 package (and which the ledgersmb package would have if it had been updated to LedgerSMB v-1.5 and also uploaded to the PPA) was pointed out by someone attempting to install the ledgersmb-1.5 package on an Ubuntu Xenial (v16.04) installation using the LedgerSMB PPA as the source for the packages. The attempt resulted in errors about the versions of some of the required packages. I was able to duplicate the errors, wherein even after manually installing some dependencies using a command line like this:
apt install libpgobject-perl libpgobject-simple-perl liblatex-driver-perl \
  libmath-bigint-gmp-perl libtemplate-plugin-latex-perl libtex-encode-perl \
Attempting to install the ledgersmb-1.5 package still resulted in errors like this:

The following packages have unmet dependencies:
    ledgersmb-1.5 :
Depends: libpgobject-perl (>= 1.403.2-1) but 1.403.2-1~ubuntu16.04.1 is to be installed
Depends: libpgobject-simple-perl (>= 3.000002-1) but 3.000002-1~ubuntu16.04.1ppa1 is to be installed
Recommends: libtemplate-plugin-latex-perl (>= 3.09-1) but 3.09-1~ubuntu16.04.1 is to be installed
E: Unable to correct problems, you have held broken packages.

I think it is because those are the package versions that are required but the backportpackage process adds the "~ubuntu16.04.1" suffix, which with the "~" suffix makes that version of the package to be "less than" so it doesn't. meet the requirements. Not always an issue but with two of packages in question here, it is curently the most recent version of the module that is required.

I decided that I should do them manually instead of using backportpackage, using '+ubuntu16.04.1' as the full suffix, except for libpgobject-perl which I just manually created and uploaded this version of the package: libpgobject-perl_1.403.2-2~ubuntu16.04.1. There were still the issues with the libpgobject-simple-perl and libtemplate-plugin-latex-perl pacakges and those are the latest required LedgerSMB versions so will need to create packages using the '+ubuntu16.04.1' suffix so as to not interfere with possible later package versions.  Manually created and uploaded  to the PPA: libpgobject-simple-perl_3.000002-1+ubuntu16.04.1 and libtemplate-plugin-latex-perl_3.09-1+ubuntu16.04.1.

Was then able to install the then current ledgersmb-1.5 version as well as the ledgersmb-1.5-apache package, configure it for use, and then log into to create a company database and a user, then use the page to log into the application itself.

Wednesday, November 29, 2017

Dojo packages & LedgerSMB in Debian

At least one of the reasons I had not yet tried updating the ledgersmb package to the 1.5.x series is that the dojo package currently in Debian Unstable is only 1.11.0 and I had thought that the 1.5.x series needed 1.12.2 like the master branch did. However, the dojo requirements for the LedgerSMB application were recently updated and while the master branch went from 1.12.2 to 1.13.0, the 1.5 branch only went from 1.10.8 to 1.10.9, according to the commit comment.

I'd kinda been making assumptions about the dojo being used in in the1.4.x series as well, it seems; althought that has worked, at least in-so-far as being able to log in. Now that I actually have an idea where the dojo information is kept in a dojo install (dojo/_base/kernal.js), I checked and found that it seems that it is only dojo 1.9.1 that it has been being used with the LedgerSMB 1.4.x series.  On the other hand, it's also true that the 1.4.x series doesn't use dojo as much as the 1.5.x series do.

What will help with all this will be actually getting autopkgtest implemented for ledgersmb as much as possible, as in the case of the ledgersmb package it will allow running application testing using package as it is actually installed.  And since I now know how to get a proper origin archive for a specific dojo version, I'll be able to test against those also instead of just those versions that are in the main Debian package repositories.  And, better yet, be able to compare how it tests with both the version it was release against as well as the version actually in Debian.

If there's nothing else barring it, perhaps I should get the ledgersmb package updated to the 1.5.x series while the dojo in sid is still only 1.11.0? But should I wait until I have it working with autopkgtest?  That I haven't decided yet.

Tuesday, November 28, 2017

Use 'Dapper' to maintain web sites?

Looking through the listings of static web site generators for ones implemented in Perl I found one that has been available has been Dapper, a "publishing tool for static websites".  I thought about using it and as usual I checked to see if it something that is already in Debian. I found that there had been an WNPP (Work-Needing and Prospective Package) bug open about it, # 783868, which had been closed for the following reason:
"dapper is not suitable for Debian. It is not maintained and one of its
dependency recommending a module that doesn't work with modern versions
of perl"
That was back in June of 2015 and is still true today; the most recent version (v0.18) was released in May of 2014 and there have been no updates since.  And given that issue regarding the dependence, it would have to be updated even to use privately. So, at least for now, I think I'll look elsewhere.

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.

Thursday, July 6, 2017

Bash scipt snippets ...

An interesting set of bash script snippets showed up as referenced in my twitter feed:

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.