Quantcast

[ITA] units

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[ITA] units

Brian Inglis
Hi folks,

As a long time user of Cygwin and units, both professionally and
personally, I noticed a new release of units 2.14 was available
but the package is orphaned.

I built and installed the new release for myself, and thought I'd
like to make it available to the community, so would like to adopt
the package units.
I've had no problems downloading the prvious source, bumping the
cygport version, building, testing, installing, and using the new
release.

You should be able to see what was built at:

https://drive.google.com/drive/folders/0B_phQl0EKs8jdXc4bXl2dGFqN3c?usp=sharing

where the following components are available:

units.cygport
units-2.14-1.hint
units-2.14-1.tar.xz
units-2.14-1-src.tar.xz
units-debuginfo-2.14-1.hint
units-debuginfo-2.14-1.tar.xz

I've read the contributor/maintainer guides but as this would be my
first package contribution, I may need some help using calm, etc.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ITA] units

Yaakov Selkowitz
On 2017-04-25 17:42, Brian Inglis wrote:
> As a long time user of Cygwin and units, both professionally and
> personally, I noticed a new release of units 2.14 was available
> but the package is orphaned.

I have been nominally maintaining it anyway, but you're welcome to take it.

> I built and installed the new release for myself, and thought I'd
> like to make it available to the community, so would like to adopt
> the package units.
> I've had no problems downloading the prvious source, bumping the
> cygport version, building, testing, installing, and using the new
> release.

That is a good start, but:

> units.cygport
> units-2.14-1.hint
> units-2.14-1.tar.xz
> units-2.14-1-src.tar.xz
> units-debuginfo-2.14-1.hint
> units-debuginfo-2.14-1.tar.xz

This is the build from only one architecture.  Each archful package
needs to be built for each of x86 (32-bit) and x86_64 (64-bit).  Are you
set up to build both?

> I've read the contributor/maintainer guides but as this would be my
> first package contribution, I may need some help using calm, etc.

"cygport upload" takes care of this for you.

--
Yaakov
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ITA] units

Brian Inglis
On 2017-04-25 20:25, Yaakov Selkowitz wrote:
> On 2017-04-25 17:42, Brian Inglis wrote:
>> As a long time user of Cygwin and units, both professionally and
>> personally, I noticed a new release of units 2.14 was available
>> but the package is orphaned.
>
> I have been nominally maintaining it anyway, but you're welcome to
> take it.

One less thing on your plate - but your call.

>> I built and installed the new release for myself, and thought I'd
>> like to make it available to the community, so would like to adopt
>> the package units.
>> I've had no problems downloading the prvious source, bumping the
>> cygport version, building, testing, installing, and using the new
>> release.
>
> That is a good start, but:
>
>> units.cygport
>> units-2.14-1.hint
>> units-2.14-1.tar.xz
>> units-2.14-1-src.tar.xz
>> units-debuginfo-2.14-1.hint
>> units-debuginfo-2.14-1.tar.xz
>
> This is the build from only one architecture. Each archful package
> needs to be built for each of x86 (32-bit) and x86_64 (64-bit). Are
> you set up to build both?

Yes - I still upgrade x86 infrequently.

>> I've read the contributor/maintainer guides but as this would be my
>> first package contribution, I may need some help using calm, etc.
>
> "cygport upload" takes care of this for you.

Thanks - was vaguely aware there were other commands, but obviously
never had use for them.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ITA] units

Jon TURNEY
On 26/04/2017 03:59, Brian Inglis wrote:
> On 2017-04-25 20:25, Yaakov Selkowitz wrote:
>> On 2017-04-25 17:42, Brian Inglis wrote:>
>>> I've read the contributor/maintainer guides but as this would be my
>>> first package contribution, I may need some help using calm, etc.
>>
>> "cygport upload" takes care of this for you.
>
> Thanks - was vaguely aware there were other commands, but obviously
> never had use for them.

See [1], and please provide a ssh key as per that page.

[1] https://cygwin.com/package-upload.html




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ITA] units

Brian Inglis
In reply to this post by Brian Inglis
On 2017-04-25 20:59, Brian Inglis wrote:

> On 2017-04-25 20:25, Yaakov Selkowitz wrote:
>> On 2017-04-25 17:42, Brian Inglis wrote:
>>> As a long time user of Cygwin and units, both professionally and
>>> personally, I noticed a new release of units 2.14 was available
>>> but the package is orphaned.
>> I have been nominally maintaining it anyway, but you're welcome to
>> take it.
> One less thing on your plate - but your call.
>>> I built and installed the new release for myself, and thought
>>> I'd like to make it available to the community, so would like to
>>> adopt the package units.
>>> I've had no problems downloading the previous source, bumping
>>> the cygport version, building, testing, installing, and using the
>>> new release.
>> That is a good start, but:
>>> units.cygport
>>> units-2.14-1.hint
>>> units-2.14-1.tar.xz
>>> units-2.14-1-src.tar.xz
>>> units-debuginfo-2.14-1.hint
>>> units-debuginfo-2.14-1.tar.xz
>> This is the build from only one architecture. Each archful package
>> needs to be built for each of x86 (32-bit) and x86_64 (64-bit).
>> Are you set up to build both?
> Yes - I still upgrade x86 infrequently.

Added below

>>> I've read the contributor/maintainer guides but as this would be
>>> my first package contribution, I may need some help using calm,
>>> etc.
>> "cygport upload" takes care of this for you.
> Thanks - was vaguely aware there were other commands, but obviously
> never had use for them.

Gdrive:

https://drive.google.com/drive/folders/0B_phQl0EKs8jdXc4bXl2dGFqN3c?usp=sharing
units/
units.cygport

https://drive.google.com/drive/folders/0B_phQl0EKs8jaTdMNDFybVFqZm8?usp=sharing
units/x86/
units-2.14-1.hint
units-2.14-1.tar.xz
units-2.14-1-src.tar.xz
units-debuginfo-2.14-1.hint
units-debuginfo-2.14-1.tar.xz

- x86 does not have the libreadline7 direct dependency in .hint

https://drive.google.com/drive/folders/0B_phQl0EKs8jQmx3YjlwS28yaTA?usp=sharing
units/x86_64/
units-2.14-1.hint
units-2.14-1.tar.xz
units-2.14-1-src.tar.xz
units-debuginfo-2.14-1.hint
units-debuginfo-2.14-1.tar.xz

- x86_64 has a libreadline7 direct dependency in .hint
- src has different timestamps so x86_64 is 4 bytes longer but
  identical content sizes to x86
- debuginfo hints are identical

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ITA] units

Yaakov Selkowitz
On 2017-04-26 10:50, Brian Inglis wrote:
> - x86 does not have the libreadline7 direct dependency in .hint

That means you were missing libreadline-devel; you will need to install
that for x86 and rebuild.

--
Yaakov
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ITA] units

Brian Inglis
On 2017-04-26 12:30, Yaakov Selkowitz wrote:
> On 2017-04-26 10:50, Brian Inglis wrote:
>> - x86 does not have the libreadline7 direct dependency in .hint
> That means you were missing libreadline-devel; you will need to
> install that for x86 and rebuild.

Thanks Yaakov - installed lib{readline,ncurses}-devel, first
rebuild make said "nothing to do", so blew away build/ contents,
rebuilt, tested, checked --version, and using cygcheck, both
indicate built with readline (and ncursesw10), hints and source
packages now all match, so moved common sources under units/, only
binaries under x86{,_64}/:

Gdrive

https://drive.google.com/drive/folders/0B_phQl0EKs8jdXc4bXl2dGFqN3c?usp=sharing
units/
units.cygport
units-2.14-1.hint
units-2.14-1-src.tar.xz
units-debuginfo-2.14-1.hint

https://drive.google.com/drive/folders/0B_phQl0EKs8jaTdMNDFybVFqZm8?usp=sharing
units/x86/
units-2.14-1.tar.xz
units-debuginfo-2.14-1.tar.xz

- x86 does not have the libreadline7 direct dependency in .hint

https://drive.google.com/drive/folders/0B_phQl0EKs8jQmx3YjlwS28yaTA?usp=sharing
units/x86_64/
units-2.14-1.tar.xz
units-debuginfo-2.14-1.tar.xz

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ITA] units

Brian Inglis
On 2017-04-26 17:16, Brian Inglis wrote:
> On 2017-04-26 12:30, Yaakov Selkowitz wrote:
>> On 2017-04-26 10:50, Brian Inglis wrote:
>>> - x86 does not have the libreadline7 direct dependency in .hint
>> That means you were missing libreadline-devel; you will need to
>> install that for x86 and rebuild.

Should I add libreadline-devel to .cygport DEPEND=?
 

> Thanks Yaakov - installed lib{readline,ncurses}-devel, first
> rebuild make said "nothing to do", so blew away build/ contents,
> rebuilt, tested, checked --version, and using cygcheck, both
> indicate built with readline (and ncursesw10), hints and source
> packages now all match, so moved common sources under units/, only
> binaries under x86{,_64}/:
>
> Gdrive
>
> https://drive.google.com/drive/folders/0B_phQl0EKs8jdXc4bXl2dGFqN3c?usp=sharing
> units/
> units.cygport
> units-2.14-1.hint
> units-2.14-1-src.tar.xz
> units-debuginfo-2.14-1.hint
>
> https://drive.google.com/drive/folders/0B_phQl0EKs8jaTdMNDFybVFqZm8?usp=sharing
> units/x86/
> units-2.14-1.tar.xz
> units-debuginfo-2.14-1.tar.xz
>
> - x86 does not have the libreadline7 direct dependency in .hint
>
> https://drive.google.com/drive/folders/0B_phQl0EKs8jQmx3YjlwS28yaTA?usp=sharing
> units/x86_64/
> units-2.14-1.tar.xz
> units-debuginfo-2.14-1.tar.xz

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ITA] units

Jon TURNEY
On 27/04/2017 00:20, Brian Inglis wrote:
> On 2017-04-26 17:16, Brian Inglis wrote:
>> On 2017-04-26 12:30, Yaakov Selkowitz wrote:
>>> On 2017-04-26 10:50, Brian Inglis wrote:
>>>> - x86 does not have the libreadline7 direct dependency in .hint
>>> That means you were missing libreadline-devel; you will need to
>>> install that for x86 and rebuild.
>
> Should I add libreadline-devel to .cygport DEPEND=?

Yes.

It would be better (works when cross-compiled) to write that as a
pkg-config dependency, but unfortunately libreadline doesn't seem to
have a .pc file.

You might also want to explicitly add --enable-readline (or whatever the
right thing is) to the configure line.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ITA] units

Andrew Schulman
In reply to this post by Yaakov Selkowitz
> On 2017-04-25 17:42, Brian Inglis wrote:
> > As a long time user of Cygwin and units, both professionally and
> > personally, I noticed a new release of units 2.14 was available
> > but the package is orphaned.
>
> I have been nominally maintaining it anyway, but you're welcome to take it.

Gold star awarded! https://cygwin.com/goldstars/#BI

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ITA] units

Brian Inglis
In reply to this post by Jon TURNEY
On 2017-04-27 05:51, Jon Turney wrote:

> On 27/04/2017 00:20, Brian Inglis wrote:
>> On 2017-04-26 17:16, Brian Inglis wrote:
>>> On 2017-04-26 12:30, Yaakov Selkowitz wrote:
>>>> On 2017-04-26 10:50, Brian Inglis wrote:
>>>>> - x86 does not have the libreadline7 direct dependency in .hint
>>>> That means you were missing libreadline-devel; you will need to
>>>> install that for x86 and rebuild.
>>
>> Should I add libreadline-devel to .cygport DEPEND=?
>
> Yes.
>
> It would be better (works when cross-compiled) to write that as a
> pkg-config dependency, but unfortunately libreadline doesn't seem to
> have a .pc file.
>
> You might also want to explicitly add --enable-readline (or whatever
> the right thing is) to the configure line.

configure does not seem to support --{with,enable}-readline but does
dynamic checks to see if readline can be used with -lreadline and if
it also needs -l{termcap,ncurses,curses} to build, so I just added
to DEPEND, rebuilt both archs, and uploaded both.

Please let me know if there are any issues, or what I should read
now to know what to check?

I've sftp-ed !mail and x86{,_64}/release/!ready, received two calm
emails indicating release, apt update shows units upgradable to 2.14-1
for x86{,_64}, ran setup-x86{,_64} to install, tested, so should be
okay to announce?

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ITA] units

Brian Inglis
On 2017-04-27 12:37, Brian Inglis wrote:

> On 2017-04-27 05:51, Jon Turney wrote:
>> On 27/04/2017 00:20, Brian Inglis wrote:
>>> On 2017-04-26 17:16, Brian Inglis wrote:
>>>> On 2017-04-26 12:30, Yaakov Selkowitz wrote:
>>>>> On 2017-04-26 10:50, Brian Inglis wrote:
>>>>>> - x86 does not have the libreadline7 direct dependency in .hint
>>>>> That means you were missing libreadline-devel; you will need
>>>>> to install that for x86 and rebuild.
>>> Should I add libreadline-devel to .cygport DEPEND=?
>> Yes.
>> It would be better (works when cross-compiled) to write that as a
>> pkg-config dependency, but unfortunately libreadline doesn't seem
>> to have a .pc file.
>> You might also want to explicitly add --enable-readline (or
>> whatever the right thing is) to the configure line.
> configure does not seem to support --{with,enable}-readline but does
> dynamic checks to see if readline can be used with -lreadline and if
> it also needs -l{termcap,ncurses,curses} to build, so I just added to
> DEPEND, rebuilt both archs, and uploaded both.
> Please let me know if there are any issues, or what I should read now
> to know what to check?
> I've sftp-ed !mail and x86{,_64}/release/!ready, received two calm
> emails indicating release, apt update shows units upgradable to
> 2.14-1 for x86{,_64}, ran setup-x86{,_64} to install, tested, so
> should be okay to announce?

Sorry about the garbled premature announcement.
I was trying out cygport announce, and thought there were problems with
it connecting to my ISP mailserver, so messed around with that getting
nowhere, then tried Thunderbird, and it too went nowhere.
Finally noticed I had a network problem with my cable internet: bounced
system, router, cable modem, with no luck; checking via my cell provider,
turned out to be a national outage, including VoIP, for my ISP.
Unfortunately, it looks like Tbird kept the failed sent message around,
then sent it when the network came back up.
Haven't experienced an unscheduled outage for a few years, so not used
to checking for stuff in my Outbox, and Murphy knows how to teach us
humility, and educate us about our tools! ;^>

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: units issues

Brian Inglis
In reply to this post by Brian Inglis
On the cygwin list, Achim Gratz asked:
> Can you please make that configurable by some file in /var/lib/units
> that will prevent the perpetual postinstall script from even forking
> if the user decides that this should not be updated?

Configuration of units is currently supported only in
/usr/share/units/*.units files which are defaulted by the utility,
specified on the command line, included from one of those, or specified
in ~/.units, and conditions may be specified depending only on either
locale or an environment variable.

The easiest approaches to this would be:
- rename or delete postinstall script which might upset cygcheck or
setup remove
- null /usr/share/units/currency.units, as it is required and produces
an error message if not available, but if it is empty, everything works.

It is not very useful if not up to date (I run the update daily), and if
not up to date, might as well be empty, but some opinions may differ.

In the postinstall script find which ensures updates happen at most daily:
/usr/bin/find /usr/share/units/currency.units -mtime +0 -exec
/usr/bin/units_cur \;
I could add a -size +0 qualifier, which would skip the update if the
file is empty, and avoid creating a config flag file in directory
/var/lib/units/, which is not currently created or used by the package.

I will ask upstream about disabling currency updates by the python
script, as that would be a preferred configurable approach.

In any case, I will raise handling an expired cert in the python update
script upstream, and suggest a configurable override.

Please respond with any advice on how disabling pi updates and expired
certs are or should be dealt with in postinstall scripts or python (I
posted a temporary replacement workaround script and change to the
original on the cygwin list, so the technical workaround is known and
handled).

and Ian Lambert reported:
> In /var/log/setup.log.full I see:
> Error connecting to currency server. <urlopen error [Errno 8] Name or service not known>
> Running /usr/bin/units_cur or /etc/postinstall/zp_units_cur.sh I get
> Error connecting to currency server. HTTP Error 407: Proxy Authentication Required
> I'm behind a proxy requiring username, password, and restrictions on user-agents...

I will raise handling proxies upstream, but once again, any advice is
welcome, including technical approaches that work with Windows proxies
under Cygwin in python3 (I am not a "python guy", and resort to google
and SO, although some of those "suggestions" just don't work, as I found
looking for ways to handle the expired cert).

I posted responses that I'd take the issues upstream, follow up here,
and report back, or provide a package update.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: units issues

Achim Gratz
Brian Inglis writes:
> The easiest approaches to this would be:
> - rename or delete postinstall script which might upset cygcheck or
> setup remove
> - null /usr/share/units/currency.units, as it is required and produces
> an error message if not available, but if it is empty, everything works.

Nope.  The user should not have to muck with packaged files at all.

> It is not very useful if not up to date (I run the update daily), and if
> not up to date, might as well be empty, but some opinions may differ.

The issue is that you cannot assume that postinstall scripts are able to
access the network at all.  Where this isn't possible the administrator
will have to find a different way of keeping those files up-to-date
(which should also not be packaged), but that's something to maybe just
document.  But you will have to provide some way of letting the user
specify if that updating is OK.  If you want this to be possible during
the initial install you might even need to provide another sub-package
whose only purpose is to confer this decision (it could be empty and
just doing a simple postinstall action).

> In the postinstall script find which ensures updates happen at most daily:

I've asked specifically to structure any perpetual postinstall script in
a way that it doesn't do any non-necessary work, be it forking or
otherwise unless it is going to actually do something useful.  A simple
file test that exits the postinstall script when the file is or isn't
there satisfies that constraint, running commands and scripts doesn't.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: units issues

Brian Inglis
On 2017-05-23 11:28, Achim Gratz wrote:

> Brian Inglis writes:
>> The easiest approaches to this would be:
>> - rename or delete postinstall script which might upset cygcheck or
>> setup remove
>> - null /usr/share/units/currency.units, as it is required and produces
>> an error message if not available, but if it is empty, everything works.
>
> Nope.  The user should not have to muck with packaged files at all.
>
>> It is not very useful if not up to date (I run the update daily), and if
>> not up to date, might as well be empty, but some opinions may differ.
>
> The issue is that you cannot assume that postinstall scripts are able to
> access the network at all.  Where this isn't possible the administrator
> will have to find a different way of keeping those files up-to-date
> (which should also not be packaged), but that's something to maybe just
> document.  But you will have to provide some way of letting the user
> specify if that updating is OK.  If you want this to be possible during
> the initial install you might even need to provide another sub-package
> whose only purpose is to confer this decision (it could be empty and
> just doing a simple postinstall action).
>
>> In the postinstall script find which ensures updates happen at most daily:
>
> I've asked specifically to structure any perpetual postinstall script in
> a way that it doesn't do any non-necessary work, be it forking or
> otherwise unless it is going to actually do something useful.  A simple
> file test that exits the postinstall script when the file is or isn't
> there satisfies that constraint, running commands and scripts doesn't.

Updating the currencies only when setup is run seems to me to be
insufficient if users want to use current currency conversions.

Would the best approach be to punt on running the update script at all,
install a null /usr/share/units/currency.units file, announce and
document that if currency conversions are desirable, the user should
arrange to run the update script, either from the command line, profile,
cron job, or Task Scheduler?

If we kept the postinstall script, we could change it to run only if the
currency.units file is non-null and drop the time check:
[ -s /usr/share/units/currency.units ] && /usr/bin/units_cur
or keep the time check, using find -mtime +0, or date and stat.

I have followed up with the upstream maintainer AdrianM at GNU dot org
about the Python currency update script issues with no response yet.
Does anyone have contact or know a better address to try? PM if so.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: units issues

Doug Henderson
On 23 May 2017 at 15:49, Brian Inglis wrote:

> Updating the currencies only when setup is run seems to me to be
> insufficient if users want to use current currency conversions.

Currencies needs to be split to a different package from non-currency
units. Non-currency units is very static, whereas most currencies
changes daily. In the absence of updates, non-currency units are still
useful; but currencies are incorrect in most cases, and increasingly
so as time pass.

It is difficult to predict user requirements based on current package
dependencies as non-currency units and currencies are likely used by
almost disjoint sets of packages. Users of non-currency units should
not be burdened by the complexities of currencies. But if they do need
currencies, they should be up to date.

A possible solution is to check the currency of the currency data on
library initialization or each use by comparing the current date with
the data's date of update. When the data is stale, automatically
update it if possible, or notify the user of the problem.

Doug

--
Doug Henderson, Calgary, Alberta, Canada - from gmail.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: units issues

Brian Inglis
On 2017-05-23 17:55, Doug Henderson wrote:

> On 23 May 2017 at 15:49, Brian Inglis wrote:
>
>> Updating the currencies only when setup is run seems to me to be
>> insufficient if users want to use current currency conversions.
>
> Currencies needs to be split to a different package from non-currency
> units. Non-currency units is very static, whereas most currencies
> changes daily. In the absence of updates, non-currency units are still
> useful; but currencies are incorrect in most cases, and increasingly
> so as time pass.
>
> It is difficult to predict user requirements based on current package
> dependencies as non-currency units and currencies are likely used by
> almost disjoint sets of packages. Users of non-currency units should
> not be burdened by the complexities of currencies. But if they do need
> currencies, they should be up to date.
>
> A possible solution is to check the currency of the currency data on
> library initialization or each use by comparing the current date with
> the data's date of update. When the data is stale, automatically
> update it if possible, or notify the user of the problem.

It's a command line utility from GNU with currency conversion factors in
a separate definition file included from the main file, updated by a
Python script, which downloads an RSS XML file of current (Euro) rates
from a free source with a permissive licence, and converts it to
definitions acceptable to the utility, overwriting the existing file.

The main issues are that, as currently implemented, currency rates are
updated automatically by a postinstall script only when setup is run;
setup may be running in an environment without external access, so the
postinstall script will generate an error; users may not want or care
about currency updates; and the postinstall script uses find to avoid
updating if there is no currency file, or it has been updated recently.

One option to deal with this is update the package to install a zero
length currency definitions file, so currency conversions are not
defined, but the program has no issues, and drop the permanent
postinstall script to perform updates.
Then announce and document that users who want updated currency
conversion rates need to run the update script from the command line, a
profile script, cron job, or Windows Scheduled Task, as is desirable if
they use currency conversions.

There are also issues with the Python update script, as the currency
source site cert expired recently, causing the update and postinstall
scripts to fail, with no workaround other than a replacement or patch;
and a poster has problems using the update script with Windows proxies,
which I have addressed to the upstream maintainer for discussion about
approaches.
If there is no response, I will create a Cygwin update patch and submit
it upstream, but there has been no visible response to issues raised on
the GNU site.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: units issues

Buchbinder, Barry (NIH/NIAID) [E]
Brian Inglis sent the following at Tuesday, May 23, 2017 10:37 PM

>
>On 2017-05-23 17:55, Doug Henderson wrote:
>
>> On 23 May 2017 at 15:49, Brian Inglis wrote:
>>
>>> Updating the currencies only when setup is run seems to me to be
>>> insufficient if users want to use current currency conversions.
>>
>> Currencies needs to be split to a different package from non-currency
>> units. Non-currency units is very static, whereas most currencies
>> changes daily. In the absence of updates, non-currency units are still
>> useful; but currencies are incorrect in most cases, and increasingly
>> so as time pass.
>>
>> It is difficult to predict user requirements based on current package
>> dependencies as non-currency units and currencies are likely used by
>> almost disjoint sets of packages. Users of non-currency units should
>> not be burdened by the complexities of currencies. But if they do need
>> currencies, they should be up to date.
>>
>> A possible solution is to check the currency of the currency data on
>> library initialization or each use by comparing the current date with
>> the data's date of update. When the data is stale, automatically
>> update it if possible, or notify the user of the problem.
>
>It's a command line utility from GNU with currency conversion factors
>in a separate definition file included from the main file, updated by
>a Python script, which downloads an RSS XML file of current (Euro)
>rates from a free source with a permissive licence, and converts it to
>definitions acceptable to the utility, overwriting the existing file.
>
>The main issues are that, as currently implemented, currency rates are
>updated automatically by a postinstall script only when setup is run;
>setup may be running in an environment without external access, so the
>postinstall script will generate an error; users may not want or care
>about currency updates; and the postinstall script uses find to avoid
>updating if there is no currency file, or it has been updated recently.
>
>One option to deal with this is update the package to install a
>zero length currency definitions file, so currency conversions are
>not defined, but the program has no issues, and drop the permanent
>postinstall script to perform updates. Then announce and document that
>users who want updated currency conversion rates need to run the update
>script from the command line, a profile script, cron job, or Windows
>Scheduled Task, as is desirable if they use currency conversions.
>
>There are also issues with the Python update script, as the currency
>source site cert expired recently, causing the update and postinstall
>scripts to fail, with no workaround other than a replacement or patch;
>and a poster has problems using the update script with Windows proxies,
>which I have addressed to the upstream maintainer for discussion about
>approaches. If there is no response, I will create a Cygwin update patch
>and submit it upstream, but there has been no visible response to issues
>raised on the GNU site.

I would prefer that by default updates happen automatically and those
who do not want automatic updates do something to stop them from
happening.  For instance, someone who does not want updates makes the
definitions file read-only and have the script check for write
permission and exit or skip updating if the file cannot be written.  A
zero length read-only file works if one is worried about someone using
stale conversion factors.  An environmental variable whose existence
marks no-update might be another possibility.

Best wishes,

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: units issues

Brian Inglis
On 2017-05-24 10:26, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> Brian Inglis sent the following at Tuesday, May 23, 2017 10:37 PM
>> On 2017-05-23 17:55, Doug Henderson wrote:
>>> On 23 May 2017 at 15:49, Brian Inglis wrote:
>>>> Updating the currencies only when setup is run seems to me to be
>>>> insufficient if users want to use current currency conversions.

>> It's a command line utility from GNU with currency conversion factors
>> in a separate definition file included from the main file, updated by
>> a Python script, which downloads an RSS XML file of current (Euro)
>> rates from a free source with a permissive licence, and converts it to
>> definitions acceptable to the utility, overwriting the existing file.
>>
>> The main issues are that, as currently implemented, currency rates are
>> updated automatically by a postinstall script only when setup is run;
>> setup may be running in an environment without external access, so the
>> postinstall script will generate an error; users may not want or care
>> about currency updates; and the postinstall script uses find to avoid
>> updating if there is no currency file, or it has been updated recently.
>>
>> One option to deal with this is update the package to install a
>> zero length currency definitions file, so currency conversions are
>> not defined, but the program has no issues, and drop the permanent
>> postinstall script to perform updates. Then announce and document that
>> users who want updated currency conversion rates need to run the update
>> script from the command line, a profile script, cron job, or Windows
>> Scheduled Task, as is desirable if they use currency conversions.

> I would prefer that by default updates happen automatically and those
> who do not want automatic updates do something to stop them from
> happening.  For instance, someone who does not want updates makes the
> definitions file read-only and have the script check for write
> permission and exit or skip updating if the file cannot be written.  A
> zero length read-only file works if one is worried about someone using
> stale conversion factors.  An environmental variable whose existence
> marks no-update might be another possibility.

I agree with Achim that currency updates should not be done at
postinstall, as the user could be doing an automated install with no
external access, and we don't know that.

With no guaranteed automatic execution facility, we don't even have a
mechanism, how should updates should be done automatically and how can
we provide this?

Alternative suggestions for automated updates are welcome and why I am
asking here.

For other services, we leave it to users to figure out how to start them
up and shut them down before setup is run.

We could install an /etc/profile.d script which asks the user first time
thru if they want daily currency updates during login over the network,
and then either null or update currencies, and after do or do not update
currencies.

We could document how updates could be run: run the command from the
shell, or add the necessary code to: some profile or profile.d script;
command alias or function wrapper in some profile script; script which
uses units currencies, cron job, or Windows Scheduled Task.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: units issues

Achim Gratz
In reply to this post by Buchbinder, Barry (NIH/NIAID) [E]
Buchbinder, Barry (NIH/NIAID) [E] writes:
> I would prefer that by default updates happen automatically and those
> who do not want automatic updates do something to stop them from
> happening.

That there should be updates was never debated, only the machanism of
doing so is discussed here.

> For instance, someone who does not want updates makes the
> definitions file read-only and have the script check for write
> permission and exit or skip updating if the file cannot be written.  A
> zero length read-only file works if one is worried about someone using
> stale conversion factors.  An environmental variable whose existence
> marks no-update might be another possibility.

No again.  In general, it is a no-no to alter or remove files that came
with the package (besides, the user might not even be able to, depending
on how Cygwin gets installed).  Cygwin isn't very fussy about such
errors at the moment, but that shouldn't be an excuse to become sloppy.


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada
12
Loading...