Armory 0.94 is out

[yslyung]

installed new version all works well now, much faster thx.

[goatpig]

I've confirmed the installation issues I was having with the .deb for 0.94.0 were related to these lines in dpkgfiles/postinst:

Code:

execAndWait('xdg-desktop-menu  install --novendor /usr/share/applications/armory.desktop')
execAndWait('xdg-desktop-menu  install --novendor /usr/share/applications/armorytestnet.desktop')
execAndWait('xdg-desktop-menu  install --novendor /usr/share/applications/armoryoffline.desktop')

not sure if it's the arguments for xdg-desktop-menu or something in the calling function, it's going to take a little wrapping my head around that function (although I think understand it's broad purpose). Documentation for freedesktop/xdg states that error 3 means resource unavailability, and curiously, they have a separate error code for file/dir not found/inaccessible (and in their terminology, "system menu directory" could well not be referring to a filesystem directory).

Will post results if/when I discover the problem. I don't normally work on this sort of thing, someone talented may beat me to it

This code registers the armory shortcuts in the Application drop down menu. Not sure if that's Debian/Ubuntu specific or not. I'm guessing if that path is missing that registration will fail. Quick sanity check: does your GDE have that Application menu?

NOTE:

1. Uninstall C:\Program Files (x86)\Bitcoin\ (32 bit) was required. I couldn't have two versions. This seemed to fix loading database headers however, it still crashed afterwards but passed 0% now.
2. Delete database was required to fix the crash after loading database headers

Since you have 2 versions of Bitcoin installed, Armory auto detected the 32 bit one first. I'm guessing everything else is bound to that.

[Carlton Banks]

Will post results if/when I discover the problem. I don't normally work on this sort of thing, someone talented may beat me to it

This code registers the armory shortcuts in the Application drop down menu. Not sure if that's Debian/Ubuntu specific or not. I'm guessing if that path is missing that registration will fail. Quick sanity check: does your GDE have that Application menu?

Well, /usr/share/applications exists and is suitably populated, likewise /usr/share/menu.

Is anyone else aware of other files/directories relating to the proper functioning of the applications menu? (I'm currently trying to answer my own question also...)

[goatpig]

Well, /usr/share/applications exists and is suitably populated, likewise /usr/share/menu.

Is anyone else aware of other files/directories relating to the proper functioning of the applications menu? (I'm currently trying to answer my own question also...)

Permission issue?

[Carlton Banks]

Well, /usr/share/applications exists and is suitably populated, likewise /usr/share/menu.

Is anyone else aware of other files/directories relating to the proper functioning of the applications menu? (I'm currently trying to answer my own question also...)

Permission issue?

I don't think so, dpkg -i won't run without superuser privileges. Looking at the owner/group/permissions situation for /usr/share/applications and /usr/share/applications, root owns the dir and the files. root has rwx for the dirs and rw for the files contained. Both Group and Others have rx and read-only access for dirs and files respectively.

To put this another way, other .deb files seem to handle the Qubes setup ok, but I'm not sure how/if they're using xdg utils to do the job.

[josephbisch]

Carlton, does /usr/share/desktop-directories/ exist? If not, what happens if you make that directory and try to retrigger the xdg-desktop-menu calls?

[Carlton Banks]

No, only dom0 has that directory. And indeed, mkdir /usr/share/desktop-directories clears up the errors and the installation bug completely. The bug has, of course, been removed from the uninstall process also. Thanks Joseph!

So this is highly likely Qubes specific, but other .deb packagers manage to avoid this somehow, unless the removal of /usr/share/desktop-directories from the OS template is a very recent change in Qubes' codebase. Going to gather some .deb files that install .desktop files for more testing.

Using an argument that ignores the error when executing xdg-desktop-menu would be most ideal. Qubes team removed that directory for a reason, so detecting it's absence and making it seems like a poor choice (they've removed a fair amount of dom0 only stuff from the OS templates)

[goatpig]

No, only dom0 has that directory. And indeed, mkdir /usr/share/desktop-directories clears up the errors and the installation bug completely. The bug has, of course, been removed from the uninstall process also. Thanks Joseph!

So this is highly likely Qubes specific, but other .deb packagers manage to avoid this somehow, unless the removal of /usr/share/desktop-directories from the OS template is a very recent change in Qubes' codebase. Going to gather some .deb files that install .desktop files for more testing.

Using an argument that ignores the error when executing xdg-desktop-menu would be most ideal. Qubes team removed that directory for a reason, so detecting it's absence and making it seems like a poor choice (they've removed a fair amount of dom0 only stuff from the OS templates)

Checking the path exists and creating it if it doesn't, wouldn't that be enough? Or is creating the folder without a prompt overreaching?

[Carlton Banks]

Checking the path exists and creating it if it doesn't, wouldn't that be enough? Or is creating the folder without a prompt overreaching?

 

If you go that way, I would also rm -df the folder after the xdg-desktop-menu lines have executed. I looked in /usr/share/desktop-directories after the successful install, and it was empty. Deleting /usr/share/desktop-directories in the template didn't cause issues when I span up 0.94 in a VM using that template, so it appears to be ok. Not sure of any other possible ramifications, I'll make as much use as I can of 0.94 (in this particular state) to be sure.

[goatpig]

If you go that way, I would also rm -df the folder after the xdg-desktop-menu lines have executed

I could check whether the folder is empty or not before deleting it, but that would probably breach what is expected of the uninstall process. The only way around it would be to keep track of the folder existence before install to restore the system to its original state. That's complicating things too much and I would choose to not remove the folder in this case.

I think the better approach is to look for path existence and skip the shortcut registration if there is no such folder. The .deb is targeted at Debian/Ubuntu. If you are using a distro that deviates from that, I'd rather not forcefully modify it to fit "Debian-ess", and I expect you can spawn Armory from the terminal, or register the shortcuts on your own.

[Carlton Banks]

I'm trying both approaches right now (learning python simultaneously ). Will test and report back.


Edit: your last idea is definitely the best, Qubes has it's own script to check for .desktop files, then talks to the inter-VM RPC to (likely using xdg) re-populate the actual /usr/share/desktop-directories in dom0. So the xdg-desktop-menu commands are probably unneeded with Qubes.

[josephbisch]

Maybe the other packages that don't fail to install the desktop file use an install file (debian/armory.install in Armory's case) to install the desktop files? See http://packaging.ubuntu.com/html/debian-dir-overview.html and search the page for "desktop" to find what I am talking about.

You won't be able to generate the desktop files on demand like the postinst script currently does, but it looks like there are static desktop files in dpkgfiles currently anyway.

[Carlton Banks]

Maybe the other packages that don't fail to install the desktop file use an install file (debian/armory.install in Armory's case) to install the desktop files? See http://packaging.ubuntu.com/html/debian-dir-overview.html and search the page for "desktop" to find what I am talking about.

You won't be able to generate the desktop files on demand like the postinst script currently does, but it looks like there are static desktop files in dpkgfiles currently anyway.

Seems highly convincing, not least because the on-the-fly desktop file generation doesn't depend on dynamic input anyway. Possibly too involving for a bugfix release, we'll see what can be done before goatpig decides to do the release.

[RoadStress]

0.94 DB format is different from 0.93, you can't have them both running in the same folder. I'd recommend you use a different DB folder (add --dbdir="some/new/folder" to your shortcut target) and make sure 0.94 is stable before completely replacing 0.93's DB.

From 0.94 onward the "--datadir=" argument is now "--dbdir=" or are they different?

Thank you for this release!

[goatpig]

0.94 DB format is different from 0.93, you can't have them both running in the same folder. I'd recommend you use a different DB folder (add --dbdir="some/new/folder" to your shortcut target) and make sure 0.94 is stable before completely replacing 0.93's DB.

From 0.94 onward the "--datadir=" argument is now "--dbdir=" or are they different?

Thank you for this release!

--datadir sets the datadir, which is your wallets, log files, settings file and database folder

--dbdir sets the database folder independently

--datadir="folder1" along with --dbdir="folder2" will result in wallets, logs and settings to go into folder1 and db into folder2.

[Carlton Banks]

I'm trying to test a basic fix (adding a test for the path before the xdg-desktop-menu lines, also indenting the xdg-desktop-menu lines and the the blank line after those to make those lines execute contingent on the if statement). It's almost like make_deb_package.py is using the old postinst script, despite copying the correct file to the temporary directory used to build the package. So my coding syntax has got to be wrong.

Here's the line I'm adding:

Code:

if os.path.exists('/usr/share/desktop-directories'):

Other than the correct indentation to delineate the codeblock, what could be the issue? Could it actually be using the old script? Am I not allowed to supply literal string values?

[josephbisch]

I'm trying to test a basic fix (adding a test for the path before the xdg-desktop-menu lines, also indenting the xdg-desktop-menu lines and the the blank line after those to make those lines execute contingent on the if statement). It's almost like make_deb_package.py is using the old postinst script, despite copying the correct file to the temporary directory used to build the package. So my coding syntax has got to be wrong.

Here's the line I'm adding:

Code:

if os.path.exists('/usr/share/desktop-directories'):

Other than the correct indentation to delineate the codeblock, what could be the issue? Could it actually be using the old script? Am I not allowed to supply literal string values?

The Python code you added looks correct to me. The problem is that the temporary directory gets recreated from dpkgfiles each time you run make_deb_package.py. So if you are copying to or modifying the file in the temporary directory instead of dpkgfiles, it will get overwritten when you run make_deb_package.py. So if you aren't doing it already, you should modify the postinst in dpkgfiles and then try running make_deb_package.py.

[Carlton Banks]

Right, so there was nothing wrong with the one line of python code.

I'm thinking now there must be some uninstall script or another part of the code where the xdg-utils commands are called.

I have:

• built the .deb as 93.99.2, including the extra line in postint script
• installed that into a fresh Debian 8 VM
• built another .deb as 0.93.99.3, also including the extra line
• installing 93.99.3 over 93.99.2 generates the same errors that installing 0.94 over 0.93.3 does

I can tell the initial modified .deb is working, I stuck 1 print line inside the if statement and then also another print line immediately after the if. Only the latter appeared in stdout, seems convincing to me. The behaviour when installing over 93.99.2 looks so much like it's getting those lines from a different copy of the same script, could that be right? Can't see anything like that in the file structure though

edit: how about the postrm binary? can't see any source for that in the codebase

[josephbisch]

Right, so there was nothing wrong with the one line of python code.

I'm thinking now there must be some uninstall script or another part of the code where the xdg-utils commands are called.

I have:

• built the .deb as 93.99.2, including the extra line in postint script
• installed that into a fresh Debian 8 VM
• built another .deb as 0.93.99.3, also including the extra line
• installing 93.99.3 over 93.99.2 generates the same errors that installing 0.94 over 0.93.3 does

I can tell the initial modified .deb is working, I stuck 1 print line inside the if statement and then also another print line immediately after the if. Only the latter appeared in stdout, seems convincing to me. The behaviour when installing over 93.99.2 looks so much like it's getting those lines from a different copy of the same script, could that be right? Can't see anything like that in the file structure though

edit: how about the postrm binary? can't see any source for that in the codebase

The postrm is located in dpkgfiles (https://github.com/goatpig/BitcoinArmory/blob/master/dpkgfiles/postrm in the master branch for example). And it does look like there are xdg-utils uninstall commands in that script. So that seems like it is the source of the error when installing a new version over the old version of Armory.

[Carlton Banks]

ugh, I assumed postrm was a compiled binary, that will teach me to take the nautilus icon as any kind of information at all, other than a picture! Thanks again Joseph, really appreciated.