Bumped Calibre to 1.16.0

[TomOne]

I have an idea: Since I’m particularly interested that this package and the CDBurnerXP package are up-to-date, what if you would make me a co-maintainer of these? I update my automatic packages almost every day, and without wanting to brag, I think I’m currently a quite reliable package maintainer.

It’s just a suggestion. :smiley: My Chocolatey.org username: purity

[gep13]

The more I think about this, the more I would like to see these packages moved into the Chocolatey Core Packages Repository. One of the requirements for putting packages in there is that they are automatically updatable packages. I have just downloaded and installed keratin, and I am reading through the documentation for setting it up. So that I can jump start this process, can you send me details of the keratin configuration that you have used for Calibre and CDBurnerXP? Once I have that set up, I will move the files for these packages into the CoreTeam Packages repository, and then add both you, and the Chocolatey User as maintainers of the package. How does that sound?

[Redsandro]

@gep13 now that you've done this once, do you think the process is actually rather easy and summarizable in a few points in stead of the verbose article in the wiki?

[gep13]

@Redsandro I think it can be summarised, yes, but I think there are still some things that are not clear, and need to be expanded on. For instance:

• Do you just hardcode the 64URL? Or can that be derived from somewhere?
• Is it possible to export the keratin configuration for each application and store that in the repo?
• Is it actually necessary to download the exe/msi into the _work folder? These are potentially large files, so doing this each update could be long and expensive (depending on bandwidth and connection)
• There is no mention of how the /disablepush works? Does this simply use an already stored API Key, or does this have to be stored elsewhere?
• I think some more explanation around what keratin is, and what features the choco updater tool is using of it, is necessary.

There are probably a couple other things as well, but for now I forget what they are. I will have a think again, when I come back around to this, and let you know.

[gep13]

@TomOne did you see my request above? Regarding what keratin settings you are using for Calibre and CDBurnerXP

[TomOne]

Do you just hardcode the 64URL? Or can that be derived from somewhere?

url64 is a Ketarin variable. Look at the last screenshot of this page to see how a variable is handled by Ketarin: http://wiki.ketarin.org/index.php?title=Basics Variables can contain contents from web pages, regular expressions or textual content. In most of my automatic packages I use the textual content for url64, e.g. something like this: http://example.com/foo/bar/somesoftware-{version}.exe In the specific case of Calibre: url64 = http://download.calibre-ebook.com/{version}/calibre-64bit-{version}.msi {version} gets then replaced with the actual content of the version variable (1.16.0 at the moment.)

Is it possible to export the keratin configuration for each application and store that in the repo?

Yes, just highlight an application entry in Ketarin and then File > Export selected… Ketarin also has a command line switch to export all your application configurations as one combined XML file. With the scripting language of your desire you could split this XML into one XML for each application and save it in the application folder where the corresponding *.nuspec resides.

Is it actually necessary to download the exe/msi into the _work folder? These are potentially large files, so doing this each update could be long and expensive (depending on bandwidth and connection)

It is necessary to download the files into the _work folder. Ketarin has an option “Do not download, check for updates only”, but by activating this option the automatic packages will no longer work, because chocopkgup only gets executed after a successful download start with HTTP status code 200. Of course the process of downloading the entire application exe/msi/zip/… files on every update is bandwidth intensive, but note that Ketarin is not especially made for our specific purpose. The original purpose of Ketarin is to maintain a compilation of all desired application setup files. But nothing prevents any C# developer form optimizing it more for the specific purpose of automatic Chocolatey packages, since it’s FOSS.

There is no mention of how the /disablepush works? Does this simply use an already stored API Key, or does this have to be stored elsewhere?

I think you confuse things here. /disablepush means that pushing to the Chocolatey Gallery is disabled, so the API key is irrelevant in this case. If you leave /disablepush away, chocopkgup pushes the updated *.nupkg using your existing API key, the same like with cpush.

I think some more explanation around what keratin is, and what features the choco updater tool is using of it, is necessary.

I suggest to read through the official Ketarin Wiki. It helped me a lot when I created my first automatic packages. Unfortunately the documentation of chocopkgup is a bit short at the moment. Type chocopkgup --help in a terminal to see it.

[gep13]

@TomOne thanks for all the info! Do you already have applications configured for Calibre and CDBirnerXP based on the PR for automatic packages that you sent me? If so, can I ask you to export them so I can compare with what I have come up with? As a sanity check? Cheers!

[TomOne]

@gep13 After reading your question I think you overlooked the jobs.db file. This file is the SQLite database for Ketarin I created for you with all preconfigured settings and and Ketarin jobs for calibre, cdburnerxp, feeddemon, fiddler4 and poweriso. You only have to put this file into %appdata%\Ketarin and after you launch Ketarin, you will see all applications I from my PR preconfigured, including Calibre and CDBurnerXP. That’s the reason why I always said that you will only need a few minutes to set up the automatic packages I migrated for you. :smiley:

I also wrote about the jobs.db file in the original PR.

[TomOne]

Important info: Always name the package folders, nuspecs, Ketarin jobs the same as the package IDs. They are case sensitive. I did this already in https://github.com/gep13/ChocolateyAutomaticPackages, but I’ve seen you didn’t do it entirely in https://github.com/gep13/ChocolateyPackages.

If you mess up with upper and lower case it could lead to package update and dependency issues. For new packages, there are package naming guidelines. But only use them for new packages and don’t change the upper case to lower case of already existing packages, or it will lead to the issues mentioned above.

[Redsandro]

This seems like a perfect way to do maintenance automation for software that supports this method. It's just not easy experimenting when it has this verbose process using Windows apps. For 'normal' packages, you can just write everything in the cloud on your Chromebook, and when you get on a Windows machine do a cpack, cinst test, and cpush. Go back to business.

But you (@TomOne) mentioned something interesting:

Ketarin also has a command line switch to export all your application configurations as one combined XML file.

Maybe this means someone can just borrow an XML file without needing to use Ketarin.

I also heard some people where experimenting with package checking and verification in a VM after push. As a Linux user who cannot have automatic packages batch generated, having a VM do automatic updating instead of package maintainers on their own machine sounds like music. Especially chained with verification.

Just a little future fantasy.

[gep13]

@TomOne you are right, I completely overlooked this. Thanks for the tip, and for pointing this out.