Re: [Evergreen-general] SMS Messages Not Being Received

[Lolis, John via Evergreen-general]

Adding to Kathy's point, Evergreen uses an email-to-SMS bridge to send
texts.  This is why the patron's carrier must be known.  For example, if
the carrier is Verizon, one can send a text from an email account
addressing it to xxx...@vztext.com, where the Xs denote the mobile
phone number.  This of course is less expensive than maintaining an actual
mobile number from which to directly send texts.  In that case, the carrier
need not be known.  I would expect the existing email-to-text method to be
less reliable than directly texting from a mobile account for no other
reason than the fact that an additional system--email--comes into play.

John Lolis
Coordinator of Computer Systems

100 Martine Avenue
White Plains, NY  10601
tel: 1.914.422.1497
fax: 1.914.422.1452

https://whiteplainslibrary.org/

*“I would rather have questions that can’t be answered than answers that
can’t be questioned.”*
— Richard Feynman
<https://click.fourhourmail.com/5qure95xkf7hvvo93wh2/7qh7h8h05vr4zrtz/aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUmljaGFyZF9GZXlubWFu>,
theoretical physicist and recipient of the Nobel Prize in Physics in 1965


On Mon, 8 Apr 2024 at 13:07, Lussier, Kathy  wrote:

> Hi,
>
> One thing to keep in mind is that Evergreen's core text messaging
> functionality was created more than 10 years ago when the wireless service
> provider market was much less complex. We now have carriers that use
> multiple networks, each with its own email gateway. Does the typical patron
> know which network their discount carrier may happen to run on? Some
> carriers don't even provide an email gateway, or make it very difficult to
> find. If I were to write up development requirements for this feature in
> 2024, they would be entirely different from what they were in 2011ish.
>
> NOBLE is planning to move to a third-party text messaging service soon.
> Although I can't speak to how this provider works yet, in my previous job,
> I used a service that relied on Twilio, and it was a much better
> experience. Patrons didn't have to worry about getting the precise carrier
> listed. It did not fix the sending / receipt for every single text message,
> but it did handle text messaging in a modern way with sophisticated error
> reporting letting us know the reason for the failed delivery, which helped
> staff better manage these errors.
>
> Kathy
> --
> Kathy Lussier
> she/her
> Executive Director
> NOBLE: North of Boston Library Exchange
> Danvers, MA
> 978-777-8844 x201
> www.noblenet.org
>
>
>
>
> On Mon, Apr 8, 2024 at 12:50 PM Lolis, John via Evergreen-general <
> evergreen-general@list.evergreen-ils.org> wrote:
>
>> I don't know about anyone else's mileage, but in the past few weeks I've
>> had reports of even personal text messages failing delivery.  T'would be a
>> shame if we end up chasing our tails trying to fix something we have no
>> control over.  I'm not saying this is definitely the case, but it bears
>> consideration.
>>
>> John Lolis
>> Coordinator of Computer Systems
>>
>> 100 Martine Avenue
>> White Plains, NY  10601
>> tel: 1.914.422.1497
>> fax: 1.914.422.1452
>>
>> https://whiteplainslibrary.org/
>>
>> *“I would rather have questions that can’t be answered than answers that
>> can’t be questioned.”*
>> — Richard Feynman
>> <https://click.fourhourmail.com/5qure95xkf7hvvo93wh2/7qh7h8h05vr4zrtz/aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUmljaGFyZF9GZXlubWFu>,
>> theoretical physicist and recipient of the Nobel Prize in Physics in 1965
>>
>>
>> On Mon, 8 Apr 2024 at 09:17, Elizabeth Davis via Evergreen-general <
>> evergreen-general@list.evergreen-ils.org> wrote:
>>
>>> Hi Jon,
>>>
>>> We went with Unique’s MessageBee.  We manage is on the consortium level
>>> so there’s no customization for individual libraries, but it’s been working
>>> great.
>>>
>>>
>>>
>>> *Elizabeth Davis* (she/her), *Support & Project Management Specialist*
>>>
>>> *Pennsylvania Integrated Library System **(PaILS) | SPARK*
>>>
>>> (717) 256-1627 | elizabeth.da...@sparkpa.org
>>> 
>>> support.sparkpa.org | supp...@sparkpa.org
>>>
>>>
>>>
>>> *From:* Evergreen-general <
>>> evergreen-general-boun...@list.evergreen-ils.org> *On Behalf Of *JonGeorg
>>> SageLibrary via Evergreen-general
>>> *Sent:* Friday, April 5, 2024 6:13 PM
>>> *To:* Evergreen Discussion Group <
>>> evergreen-general@list.evergreen-ils.org>
>>> *Cc:* JonGeorg SageLibrary 
>>> *Subject:* Re: [Evergreen-general] SMS Messages Not Being Rece

Re: [Evergreen-general] SMS Messages Not Being Received

[Lussier, Kathy via Evergreen-general]

Hi,

One thing to keep in mind is that Evergreen's core text messaging
functionality was created more than 10 years ago when the wireless service
provider market was much less complex. We now have carriers that use
multiple networks, each with its own email gateway. Does the typical patron
know which network their discount carrier may happen to run on? Some
carriers don't even provide an email gateway, or make it very difficult to
find. If I were to write up development requirements for this feature in
2024, they would be entirely different from what they were in 2011ish.

NOBLE is planning to move to a third-party text messaging service soon.
Although I can't speak to how this provider works yet, in my previous job,
I used a service that relied on Twilio, and it was a much better
experience. Patrons didn't have to worry about getting the precise carrier
listed. It did not fix the sending / receipt for every single text message,
but it did handle text messaging in a modern way with sophisticated error
reporting letting us know the reason for the failed delivery, which helped
staff better manage these errors.

Kathy
--
Kathy Lussier
she/her
Executive Director
NOBLE: North of Boston Library Exchange
Danvers, MA
978-777-8844 x201
www.noblenet.org




On Mon, Apr 8, 2024 at 12:50 PM Lolis, John via Evergreen-general <
evergreen-general@list.evergreen-ils.org> wrote:

> I don't know about anyone else's mileage, but in the past few weeks I've
> had reports of even personal text messages failing delivery.  T'would be a
> shame if we end up chasing our tails trying to fix something we have no
> control over.  I'm not saying this is definitely the case, but it bears
> consideration.
>
> John Lolis
> Coordinator of Computer Systems
>
> 100 Martine Avenue
> White Plains, NY  10601
> tel: 1.914.422.1497
> fax: 1.914.422.1452
>
> https://whiteplainslibrary.org/
>
> *“I would rather have questions that can’t be answered than answers that
> can’t be questioned.”*
> — Richard Feynman
> <https://click.fourhourmail.com/5qure95xkf7hvvo93wh2/7qh7h8h05vr4zrtz/aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUmljaGFyZF9GZXlubWFu>,
> theoretical physicist and recipient of the Nobel Prize in Physics in 1965
>
>
> On Mon, 8 Apr 2024 at 09:17, Elizabeth Davis via Evergreen-general <
> evergreen-general@list.evergreen-ils.org> wrote:
>
>> Hi Jon,
>>
>> We went with Unique’s MessageBee.  We manage is on the consortium level
>> so there’s no customization for individual libraries, but it’s been working
>> great.
>>
>>
>>
>> *Elizabeth Davis* (she/her), *Support & Project Management Specialist*
>>
>> *Pennsylvania Integrated Library System **(PaILS) | SPARK*
>>
>> (717) 256-1627 | elizabeth.da...@sparkpa.org
>> 
>> support.sparkpa.org | supp...@sparkpa.org
>>
>>
>>
>> *From:* Evergreen-general <
>> evergreen-general-boun...@list.evergreen-ils.org> *On Behalf Of *JonGeorg
>> SageLibrary via Evergreen-general
>> *Sent:* Friday, April 5, 2024 6:13 PM
>> *To:* Evergreen Discussion Group <
>> evergreen-general@list.evergreen-ils.org>
>> *Cc:* JonGeorg SageLibrary 
>> *Subject:* Re: [Evergreen-general] SMS Messages Not Being Received
>>
>>
>>
>> Elizabeth, what 3rd party service did you end up using and how well has
>> it been working for your libraries?
>>
>> -Jon
>>
>>
>>
>> On Fri, Apr 5, 2024 at 11:29 AM Elizabeth Davis via Evergreen-general <
>> evergreen-general@list.evergreen-ils.org> wrote:
>>
>> Hi Will
>>
>>
>>
>> We’ve had several issues with most of the carriers on SMS issues.
>> Sometimes SMS messages were throttled, and patrons would get them days or
>> weeks later if at all.  Some carriers just stopped sending them totally.
>> Sometimes the messages to a specific carrier would deliver for one library
>> in the consortium but not others.  We tried changing from sending SMS to
>> MMS with no luck.  Also we were getting asked to add new carriers that
>> don’t have gateways and so we were unable to provide SMS service to those
>> patrons.In the end we moved to a third-party option to deliver SMS
>> notifications.
>>
>>
>>
>>
>>
>> *Elizabeth Davis *(she/her), *Support & Project Management Specialist*
>>
>> *Pennsylvania Integrated Library System (PaILS) | SPARK*
>>
>> (717) 256-1627 | elizabeth.da...@sparkpa.org
>> 
>> support.sparkpa.org
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.sparkpa.org_=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=LRHEWfG7tKtoSjGM1XBmJX5tlkBCMt3lnyKxcaVacsw=dwrYBC8O0BMnqZB2_wBS

Re: [Evergreen-general] SMS Messages Not Being Received

[Lolis, John via Evergreen-general]

I don't know about anyone else's mileage, but in the past few weeks I've
had reports of even personal text messages failing delivery.  T'would be a
shame if we end up chasing our tails trying to fix something we have no
control over.  I'm not saying this is definitely the case, but it bears
consideration.

John Lolis
Coordinator of Computer Systems

100 Martine Avenue
White Plains, NY  10601
tel: 1.914.422.1497
fax: 1.914.422.1452

https://whiteplainslibrary.org/

*“I would rather have questions that can’t be answered than answers that
can’t be questioned.”*
— Richard Feynman
<https://click.fourhourmail.com/5qure95xkf7hvvo93wh2/7qh7h8h05vr4zrtz/aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUmljaGFyZF9GZXlubWFu>,
theoretical physicist and recipient of the Nobel Prize in Physics in 1965


On Mon, 8 Apr 2024 at 09:17, Elizabeth Davis via Evergreen-general <
evergreen-general@list.evergreen-ils.org> wrote:

> Hi Jon,
>
> We went with Unique’s MessageBee.  We manage is on the consortium level so
> there’s no customization for individual libraries, but it’s been working
> great.
>
>
>
> *Elizabeth Davis* (she/her), *Support & Project Management Specialist*
>
> *Pennsylvania Integrated Library System **(PaILS) | SPARK*
>
> (717) 256-1627 | elizabeth.da...@sparkpa.org
> 
> support.sparkpa.org | supp...@sparkpa.org
>
>
>
> *From:* Evergreen-general <
> evergreen-general-boun...@list.evergreen-ils.org> *On Behalf Of *JonGeorg
> SageLibrary via Evergreen-general
> *Sent:* Friday, April 5, 2024 6:13 PM
> *To:* Evergreen Discussion Group  >
> *Cc:* JonGeorg SageLibrary 
> *Subject:* Re: [Evergreen-general] SMS Messages Not Being Received
>
>
>
> Elizabeth, what 3rd party service did you end up using and how well has it
> been working for your libraries?
>
> -Jon
>
>
>
> On Fri, Apr 5, 2024 at 11:29 AM Elizabeth Davis via Evergreen-general <
> evergreen-general@list.evergreen-ils.org> wrote:
>
> Hi Will
>
>
>
> We’ve had several issues with most of the carriers on SMS issues.
> Sometimes SMS messages were throttled, and patrons would get them days or
> weeks later if at all.  Some carriers just stopped sending them totally.
> Sometimes the messages to a specific carrier would deliver for one library
> in the consortium but not others.  We tried changing from sending SMS to
> MMS with no luck.  Also we were getting asked to add new carriers that
> don’t have gateways and so we were unable to provide SMS service to those
> patrons.In the end we moved to a third-party option to deliver SMS
> notifications.
>
>
>
>
>
> *Elizabeth Davis *(she/her), *Support & Project Management Specialist*
>
> *Pennsylvania Integrated Library System (PaILS) | SPARK*
>
> (717) 256-1627 | elizabeth.da...@sparkpa.org
> 
> support.sparkpa.org
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__support.sparkpa.org_=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=LRHEWfG7tKtoSjGM1XBmJX5tlkBCMt3lnyKxcaVacsw=dwrYBC8O0BMnqZB2_wBS0yeMRrM7MXdRr1RsCIfpP_FWgATVvcKJ-V7A_fxhtQn4=a-DVfDIJ6SZYJnpG5nLk4H2X6ZNXrw3WxhvfBiNNhIk=>
> | supp...@sparkpa.org
>
>
>
> *From:* Evergreen-general <
> evergreen-general-boun...@list.evergreen-ils.org> *On Behalf Of *Szwagiel,
> Will via Evergreen-general
> *Sent:* Friday, April 5, 2024 2:13 PM
> *To:* Szwagiel, Will via Evergreen-general <
> evergreen-general@list.evergreen-ils.org>
> *Cc:* Szwagiel, Will 
> *Subject:* [Evergreen-general] SMS Messages Not Being Received
>
>
>
> Good afternoon,
>
>
>
> We have recently been receiving a number of reports from different
> libraries that patrons are not receiving SMS notifications, particularly
> those for holds.  Evergreen is sending the messages like it is supposed to,
> so we are thinking that some carriers may be flagging the messages as
> spam.  Based on the reports we have received, it appears to be most common
> with AT
>
>
>
> For anyone else who might have experienced this in the past, did you have
> any direct interactions with the carrier/s, and if so, what were the steps
> that needed to be taken to prevent this from happening in the future?
>
>
>
> Thank you.
>
>
>
> *William C. Szwagiel*
>
> NC Cardinal Project Manager
>
> State Library of North Carolina
>
> william.szwag...@ncdcr.gov | 919.814.6721
>
> https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__statelibrary.ncdcr.gov_services-2Dlibraries_nc-2Dcardinal=DwMFAw=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=LRHEWfG7tKtoSjGM1XBmJX5tlkBCMt3lnyKxcaVacsw=0H4t3hQJflpFt0ea7x85qUiTVDQWbYqh6Dz0QJdoxJOUX_T6PrvwY7VnJnpC2V-2=qM9rGoZZzkmnBg-dhc0vkdPvc6yTj-

Re: [Evergreen-general] SMS Messages Not Being Received

[Elizabeth Davis via Evergreen-general]

Hi Jon,
We went with Unique’s MessageBee.  We manage is on the consortium level so 
there’s no customization for individual libraries, but it’s been working great.

[cid:image004.png@01DA8995.890A58A0]Elizabeth Davis (she/her), Support & 
Project Management Specialist
Pennsylvania Integrated Library System (PaILS) | SPARK
(717) 256-1627 | 
elizabeth.da...@sparkpa.org<mailto:katherine.dann...@sparkpa.org>
support.sparkpa.org<https://support.sparkpa.org/> | 
supp...@sparkpa.org<mailto:supp...@sparkpa.org>

From: Evergreen-general  On 
Behalf Of JonGeorg SageLibrary via Evergreen-general
Sent: Friday, April 5, 2024 6:13 PM
To: Evergreen Discussion Group 
Cc: JonGeorg SageLibrary 
Subject: Re: [Evergreen-general] SMS Messages Not Being Received

Elizabeth, what 3rd party service did you end up using and how well has it been 
working for your libraries?
-Jon

On Fri, Apr 5, 2024 at 11:29 AM Elizabeth Davis via Evergreen-general 
mailto:evergreen-general@list.evergreen-ils.org>>
 wrote:
Hi Will

We’ve had several issues with most of the carriers on SMS issues.  Sometimes 
SMS messages were throttled, and patrons would get them days or weeks later if 
at all.  Some carriers just stopped sending them totally.   Sometimes the 
messages to a specific carrier would deliver for one library in the consortium 
but not others.  We tried changing from sending SMS to MMS with no luck.  Also 
we were getting asked to add new carriers that don’t have gateways and so we 
were unable to provide SMS service to those patrons.In the end we moved to 
a third-party option to deliver SMS notifications.


[cid:image003.png@01DA8995.89059DB0]Elizabeth Davis (she/her), Support & 
Project Management Specialist
Pennsylvania Integrated Library System (PaILS) | SPARK
(717) 256-1627 | 
elizabeth.da...@sparkpa.org<mailto:katherine.dann...@sparkpa.org>
support.sparkpa.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__support.sparkpa.org_=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=LRHEWfG7tKtoSjGM1XBmJX5tlkBCMt3lnyKxcaVacsw=dwrYBC8O0BMnqZB2_wBS0yeMRrM7MXdRr1RsCIfpP_FWgATVvcKJ-V7A_fxhtQn4=a-DVfDIJ6SZYJnpG5nLk4H2X6ZNXrw3WxhvfBiNNhIk=>
 | supp...@sparkpa.org<mailto:supp...@sparkpa.org>

From: Evergreen-general 
mailto:evergreen-general-boun...@list.evergreen-ils.org>>
 On Behalf Of Szwagiel, Will via Evergreen-general
Sent: Friday, April 5, 2024 2:13 PM
To: Szwagiel, Will via Evergreen-general 
mailto:evergreen-general@list.evergreen-ils.org>>
Cc: Szwagiel, Will 
mailto:william.szwag...@dncr.nc.gov>>
Subject: [Evergreen-general] SMS Messages Not Being Received

Good afternoon,

We have recently been receiving a number of reports from different libraries 
that patrons are not receiving SMS notifications, particularly those for holds. 
 Evergreen is sending the messages like it is supposed to, so we are thinking 
that some carriers may be flagging the messages as spam.  Based on the reports 
we have received, it appears to be most common with AT

For anyone else who might have experienced this in the past, did you have any 
direct interactions with the carrier/s, and if so, what were the steps that 
needed to be taken to prevent this from happening in the future?

Thank you.


William C. Szwagiel

NC Cardinal Project Manager

State Library of North Carolina

william.szwag...@ncdcr.gov<mailto:william.szwag...@ncdcr.gov> | 919.814.6721

https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal<https://urldefense.proofpoint.com/v2/url?u=https-3A__statelibrary.ncdcr.gov_services-2Dlibraries_nc-2Dcardinal=DwMFAw=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=LRHEWfG7tKtoSjGM1XBmJX5tlkBCMt3lnyKxcaVacsw=0H4t3hQJflpFt0ea7x85qUiTVDQWbYqh6Dz0QJdoxJOUX_T6PrvwY7VnJnpC2V-2=qM9rGoZZzkmnBg-dhc0vkdPvc6yTj-v0trgYzDKOFOo=>

109 East Jones Street  | 4640 Mail Service Center

Raleigh, North Carolina 27699-4600

The State Library is part of the NC Department of Natural & Cultural Resources.

Email correspondence to and from this address is subject to the North Carolina 
Public Records Law and may be disclosed to third parties.





Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.
_______
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org<mailto:Evergreen-general@list.evergreen-ils.org>
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general<https://urldefense.proofpoint.com/v2/url?u=http-3A__list.evergreen-2Dils.org_cgi-2Dbin_mailman_listinfo_evergreen-2Dgeneral=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=LRHEWfG7tKtoSjGM1XBmJX5tlkBCMt3lnyKxcaVacsw=dwrYBC8O0BMnqZB2_wBS0yeMRrM7MXdRr1RsCIfpP_FWgATVvcKJ-V7A_fxhtQn4=Cc-IgVadVxk5CCePbMOYP1vq2DFgsTyBdSjP30QS0LA=>
___
Evergreen

Re: [Evergreen-general] SMS Messages Not Being Received

[JonGeorg SageLibrary via Evergreen-general]

Elizabeth, what 3rd party service did you end up using and how well has it
been working for your libraries?
-Jon

On Fri, Apr 5, 2024 at 11:29 AM Elizabeth Davis via Evergreen-general <
evergreen-general@list.evergreen-ils.org> wrote:

> Hi Will
>
>
>
> We’ve had several issues with most of the carriers on SMS issues.
> Sometimes SMS messages were throttled, and patrons would get them days or
> weeks later if at all.  Some carriers just stopped sending them totally.
> Sometimes the messages to a specific carrier would deliver for one library
> in the consortium but not others.  We tried changing from sending SMS to
> MMS with no luck.  Also we were getting asked to add new carriers that
> don’t have gateways and so we were unable to provide SMS service to those
> patrons.In the end we moved to a third-party option to deliver SMS
> notifications.
>
>
>
>
>
> *Elizabeth Davis* (she/her), *Support & Project Management Specialist*
>
> *Pennsylvania Integrated Library System **(PaILS) | SPARK*
>
> (717) 256-1627 | elizabeth.da...@sparkpa.org
> 
> support.sparkpa.org | supp...@sparkpa.org
>
>
>
> *From:* Evergreen-general <
> evergreen-general-boun...@list.evergreen-ils.org> *On Behalf Of *Szwagiel,
> Will via Evergreen-general
> *Sent:* Friday, April 5, 2024 2:13 PM
> *To:* Szwagiel, Will via Evergreen-general <
> evergreen-general@list.evergreen-ils.org>
> *Cc:* Szwagiel, Will 
> *Subject:* [Evergreen-general] SMS Messages Not Being Received
>
>
>
> Good afternoon,
>
>
>
> We have recently been receiving a number of reports from different
> libraries that patrons are not receiving SMS notifications, particularly
> those for holds.  Evergreen is sending the messages like it is supposed to,
> so we are thinking that some carriers may be flagging the messages as
> spam.  Based on the reports we have received, it appears to be most common
> with AT
>
>
>
> For anyone else who might have experienced this in the past, did you have
> any direct interactions with the carrier/s, and if so, what were the steps
> that needed to be taken to prevent this from happening in the future?
>
>
>
> Thank you.
>
>
>
> *William C. Szwagiel*
>
> NC Cardinal Project Manager
>
> State Library of North Carolina
>
> william.szwag...@ncdcr.gov | 919.814.6721
>
> https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__statelibrary.ncdcr.gov_services-2Dlibraries_nc-2Dcardinal=DwMFAw=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=LRHEWfG7tKtoSjGM1XBmJX5tlkBCMt3lnyKxcaVacsw=0H4t3hQJflpFt0ea7x85qUiTVDQWbYqh6Dz0QJdoxJOUX_T6PrvwY7VnJnpC2V-2=qM9rGoZZzkmnBg-dhc0vkdPvc6yTj-v0trgYzDKOFOo=>
>
> 109 East Jones Street  | 4640 Mail Service Center
>
> Raleigh, North Carolina 27699-4600
>
> The State Library is part of the NC Department of Natural & Cultural
> Resources.
>
> *Email correspondence to and from this address is subject to the North
> Carolina Public Records Law and may be disclosed to third parties.*
>
>
>
>
> ------
>
>
> Email correspondence to and from this address may be subject to the North
> Carolina Public Records Law and may be disclosed to third parties by an
> authorized state official.
> ___
> Evergreen-general mailing list
> Evergreen-general@list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Evergreen-general] SMS Messages Not Being Received

[Rogan Hamby via Evergreen-general]

This is an ongoing trend I've been seeing with SMS Gateways. A charitable
interpretation would be that they are doing it to prevent spam but
regardless of motive it is certainly driving people to look at SMS services
that don't rely on gateways. This has been a topic of conversation in the
Koha community as well.
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Evergreen-general] SMS Messages Not Being Received

[Elizabeth Davis via Evergreen-general]

Hi Will

We've had several issues with most of the carriers on SMS issues.  Sometimes 
SMS messages were throttled, and patrons would get them days or weeks later if 
at all.  Some carriers just stopped sending them totally.   Sometimes the 
messages to a specific carrier would deliver for one library in the consortium 
but not others.  We tried changing from sending SMS to MMS with no luck.  Also 
we were getting asked to add new carriers that don't have gateways and so we 
were unable to provide SMS service to those patrons.In the end we moved to 
a third-party option to deliver SMS notifications.


[cid:image002.png@01DA8765.AFBEE1A0]Elizabeth Davis (she/her), Support & 
Project Management Specialist
Pennsylvania Integrated Library System (PaILS) | SPARK
(717) 256-1627 | 
elizabeth.da...@sparkpa.org<mailto:katherine.dann...@sparkpa.org>
support.sparkpa.org<https://support.sparkpa.org/> | 
supp...@sparkpa.org<mailto:supp...@sparkpa.org>

From: Evergreen-general  On 
Behalf Of Szwagiel, Will via Evergreen-general
Sent: Friday, April 5, 2024 2:13 PM
To: Szwagiel, Will via Evergreen-general 

Cc: Szwagiel, Will 
Subject: [Evergreen-general] SMS Messages Not Being Received

Good afternoon,

We have recently been receiving a number of reports from different libraries 
that patrons are not receiving SMS notifications, particularly those for holds. 
 Evergreen is sending the messages like it is supposed to, so we are thinking 
that some carriers may be flagging the messages as spam.  Based on the reports 
we have received, it appears to be most common with AT

For anyone else who might have experienced this in the past, did you have any 
direct interactions with the carrier/s, and if so, what were the steps that 
needed to be taken to prevent this from happening in the future?

Thank you.


William C. Szwagiel

NC Cardinal Project Manager

State Library of North Carolina

william.szwag...@ncdcr.gov<mailto:william.szwag...@ncdcr.gov> | 919.814.6721

https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal<https://urldefense.proofpoint.com/v2/url?u=https-3A__statelibrary.ncdcr.gov_services-2Dlibraries_nc-2Dcardinal=DwMFAw=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=LRHEWfG7tKtoSjGM1XBmJX5tlkBCMt3lnyKxcaVacsw=0H4t3hQJflpFt0ea7x85qUiTVDQWbYqh6Dz0QJdoxJOUX_T6PrvwY7VnJnpC2V-2=qM9rGoZZzkmnBg-dhc0vkdPvc6yTj-v0trgYzDKOFOo=>

109 East Jones Street  | 4640 Mail Service Center

Raleigh, North Carolina 27699-4600

The State Library is part of the NC Department of Natural & Cultural Resources.

Email correspondence to and from this address is subject to the North Carolina 
Public Records Law and may be disclosed to third parties.





Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Evergreen-general] SMS Messages Not Being Received

[JonGeorg SageLibrary via Evergreen-general]

We've had a lot of issues with SMS notifications not going out according to
patrons.

Sometimes it's because the carriers were bought out by another carrier like
when StraightTalk was purchased by Verizon out here in Oregon- so I updated
SMS server settings.

Another was when US Cellular apparently stopped supporting email to text
altogether, at least that is what I was told by their support. However,
some users are still receiving notifications while others aren't- leaving
me completely confused and unable to verify the issue.

For now we've been suggesting to staff to recommend email notifications
instead of SMS, and I've set up email forwarders for all branches to avoid
SPF issues for the time being.

Looking forward to seeing more responses on this topic to see what
solutions others are using. It's been mentioned before that the time to use
a 3rd party application for email & text notifications is approaching and
I'd like to hear more about success/issues with that if anyone has gone
that route.

Thanks for bringing this topic up.
-Jon

On Fri, Apr 5, 2024 at 11:13 AM Szwagiel, Will via Evergreen-general <
evergreen-general@list.evergreen-ils.org> wrote:

> Good afternoon,
>
> We have recently been receiving a number of reports from different
> libraries that patrons are not receiving SMS notifications, particularly
> those for holds.  Evergreen is sending the messages like it is supposed to,
> so we are thinking that some carriers may be flagging the messages as
> spam.  Based on the reports we have received, it appears to be most common
> with AT
>
> For anyone else who might have experienced this in the past, did you have
> any direct interactions with the carrier/s, and if so, what were the steps
> that needed to be taken to prevent this from happening in the future?
>
> Thank you.
>
> *William C. Szwagiel*
>
> NC Cardinal Project Manager
>
> State Library of North Carolina
>
> william.szwag...@ncdcr.gov | 919.814.6721
>
> https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal
>
> 109 East Jones Street  | 4640 Mail Service Center
>
> Raleigh, North Carolina 27699-4600
>
> The State Library is part of the NC Department of Natural & Cultural
> Resources.
>
> *Email correspondence to and from this address is subject to the North
> Carolina Public Records Law and may be disclosed to third parties.*
>
>
>
> --
>
> Email correspondence to and from this address may be subject to the North
> Carolina Public Records Law and may be disclosed to third parties by an
> authorized state official.
> ___
> Evergreen-general mailing list
> Evergreen-general@list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>
_______
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

[Evergreen-general] SMS Messages Not Being Received

[Szwagiel, Will via Evergreen-general]

Good afternoon,

We have recently been receiving a number of reports from different libraries 
that patrons are not receiving SMS notifications, particularly those for holds. 
 Evergreen is sending the messages like it is supposed to, so we are thinking 
that some carriers may be flagging the messages as spam.  Based on the reports 
we have received, it appears to be most common with AT

For anyone else who might have experienced this in the past, did you have any 
direct interactions with the carrier/s, and if so, what were the steps that 
needed to be taken to prevent this from happening in the future?

Thank you.


William C. Szwagiel

NC Cardinal Project Manager

State Library of North Carolina

william.szwag...@ncdcr.gov<mailto:william.szwag...@ncdcr.gov> | 919.814.6721

https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal

109 East Jones Street  | 4640 Mail Service Center

Raleigh, North Carolina 27699-4600

The State Library is part of the NC Department of Natural & Cultural Resources.

Email correspondence to and from this address is subject to the North Carolina 
Public Records Law and may be disclosed to third parties.





Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: Arch Linux minimal container userland 100% reproducible - now what?

[David A. Wheeler via rb-general]

> On Apr 2, 2024, at 1:11 PM, John Gilmore  wrote:
> 
> For me, the distinction is that the local storage is under the direct
> control of the person trying to rebuild, while the network and the
> servers elsewhere in the network are not.  If local storage is
> unreliable, you can fix or replace it, and continue with your work.

There are obviously many advantages to local storage.

However, if you locally record cryptographic hashes, and re-download the
bits for (say) a compiler, you could still reproduce the results
*if* the information is still available where you're downloading it from
(or can find an alternative source). The key is that "if" condition.

The risk of not having local copies is the risk of loss of availability.
However, many sites are fairly reliable. I'd hate to tell someone they
can't verify reproducible builds just because they don't (currently)
have a local copy of everything. Indeed, you want multiple verifications
of reproducible builds, and they'll have to get their data from somewhere.

It's sometimes much easier to send the source including build instructions,
information on how to download the rest, and the cryptographic hashes for
what is not bundled.

--- David A. Wheeler

Re: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

MK: I don't understand why YOU wouldn't double at 99%? Can you
explain this?

If the oppenent will still take at 100% then why risk losing 2 points 1% of the 
time?

I thought I answered your question about win rates previously.

A bot that always doubles, I'd expect to lose 0.3 ppg. It's hard to search back 
on my phone app, so maybe that's incorrect.)

A bot that doubles immediately it's ahead, I'd expect to lose about half that.

Those values assume the bot plays as well as gnubg for the remainder of the 
game. If the opponent will make further cube errors, then it should be a little 
bit more.





From: MK 
Sent: Wednesday, April 3, 2024 10:29:11 pm
To: Ian Shaw ; GnuBg Bug 
Subject: Re: Interesting question/experiment about value of cube ownership

On 4/2/2024 7:08 AM, Ian Shaw wrote:

> A cube strategy against a bot that never passes:

Not never but we loosely say that since it takes at GWC > 0,
i.e. even at 0.0001%

> only double when (a) you are 100% to win

I don't understand why you wouldn't double at 99%? Can you
explain this?

> (b) it's the last roll of the game and you have an advantage.

Yes, this is very bad for the mutant and already happens now.

> So the take point is 16.7%. Gammons complicate it, but I'm
> sure you get the idea.

If you can clearly define your strategy, I would be glad to
create a script to run the experiment to see what will happen.

BTW: you are still avoiding the issue of how much the mutant
will win compared to what it would be expected to win based on
its total "cube error rate".

What win rate would you say a mutant that takes at GWC > 0.0001
even on the last roll, (which must be the biggest possible cube
error), will achieve? Any guesses by anyone..?

MK

Re: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

MK: What I PROPOSE is doing the same thing done training TD-Gammon v.1, I.E. 
random self-play, but this time also cubeful and MATCHFUL, i.e. random cube as 
well as checker decisions.

As I remember it (though it's many years since I read the research), the 
self-play wasn't accomplished by picking random moves. It was the initial 
network weights that were random. The move picked was the best-ranked move of 
all the evaluated moves. This is a calculation, not a random selection.

How do you propose to rank double vs no double, and take vs pass?


From: MK 
Sent: Wednesday, April 3, 2024 10:01:17 PM
To: Ian Shaw ; GnuBg Bug 
Subject: Re: Interesting question/experiment about value of cube ownership

On 4/2/2024 5:13 AM, Ian Shaw wrote:

> What would be your proposed structure for training a
> cubeful bot? What gains and obstacles do you foresee.

I don't know what you mean by "structure". What I propose
is doing the same thing done training TD-Gammon v.1, i.e.
random self-play, but this time also cubeful and matchful,
i.e. random cube as well as checker decisions.

Apparently Tseauro still works at IBM with access to huge
CPU powers. Perhaps he can be put to shame for the damage
he caused to BG AI by what he did with TD-Gammon v.2 and
be urged to redeem himself.

In other forums, people talk about doing "XG rollouts on
Amazon's cloud servers", etc. Doing more biased rollouts
is plain stupid/illogical. Any such efforts would be put
to better use in training a new bot instead. The question
is who would volunteer to do it.

People like the Alpha-Zero team, etc. don't seem to want
to touch "gamblegammon" with a ten feet pole, possibly
because of the gambling nature of the game.

In the past, I have suggested in RGB that random rollout
feature can be added to GnuBG and results from trustable
users can be collected over time in a central database
to gradually create a bot that won't rely on concocted,
biased/inaccurate cube formulas and match equity tables.

Unfortunately the faithfuls are happy with their dogmas
and no better bots are likely in the near future... :(

MK

Re: question

[Bug reports for and general discussion about GNU Backgammon.]

Hi Max,

GnuBg can import match files and analyse them.

You can also copy an XG position id and paste it into gnubg.

Like XG, it can identify errors and estimate how lucky the rolls are. The 
results won't be exactly the same as XG because the analysis engine is 
different. But it will be very similar.

Does this answer your question?

Regards,
Ian Shaw





From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org 
 on behalf of Max S 

Sent: Wednesday, April 3, 2024 2:39:07 AM
To: bug-gnubg@gnu.org 
Subject: question

HI
Am I able to import a file of a position, match score etc and you would return 
the XG analysis to me?

Re: [Evergreen-general] Minors and Self Registration

[Diane Disbro via Evergreen-general]

We require a DOB to be entered in the online registration form. We don't
verify that the DOB entered is correct. Our online form is used to create
Internet Only accounts. We don't create these accounts for minors.

In order to check out physical materials, patrons must bring photo ID to
the library. Parents must sign for minors.

Diane Disbro
Pronouns: she/her
Circulation Coordinator
Scenic Regional Library
251 Union Plaza Drive
Union, MO 63084
(636) 583-0652 ext  110
ddis...@scenicregional.or g



On Mon, Apr 1, 2024 at 9:27 AM Gina Monti via Evergreen-general <
evergreen-general@list.evergreen-ils.org> wrote:

> Hi Everyone,
>
> I had a conversation with a library director in regards to the self
> registration page.  I know that there is support in developing a
> customizable page, but in the meantime, I wanted to ask how other
> libraries/consortia handle minors wanting to self-register for cards.
>
> I have mentioned to this director that we can add a DOB, but the main
> problem is having an actual acknowledgement of the library policy to
> protect minors given the current climate in regards to censorship.  This I
> completely understand, and I'm interested in your replies of how
> Evergreen can address this issue if possible.
>
> Thanks!
>
> --
> Gina Monti (she/her)
> Evergreen Systems Manager
> Bibliomation, Inc.
> (203) 577-4070 ext. 109
> English, American Sign Language
> _______
> Evergreen-general mailing list
> Evergreen-general@list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>
_______
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

[Evergreen-general] Evergreen releases 3.11.5 and 3.12.3

[Andrea Buntz Neiman via Evergreen-general]

The Evergreen community is pleased to announce the latest patch releases in
the 3.11 and 3.12 series: 3.11.5 and 3.12.3.

Both releases contain numerous bugfixes and updates. Please see the release
notes for more information:

3.11 Release Notes
<https://evergreen-ils.org/documentation/release/RELEASE_NOTES_3_11.html>

3.12 Release Notes
<https://evergreen-ils.org/documentation/release/RELEASE_NOTES_3_12.html>

Both releases are available for download
<https://evergreen-ils.org/egdownloads/>.

Thank you to all who contributed to this release!




-- 
Andrea Buntz Neiman, MLS
Project Manager for Software Development | Product Specialist
Equinox Open Library Initiative
abnei...@equinoxoli.org 
1-877-OPEN-ILS (673-6457)
Direct: 770-709-5583
*https://www.equinoxOLI.org/ <https://www.equinoxOLI.org/>*
_______
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

Of course I don't assume that gnubg always wins. That would be naive.

A cube strategy against a bot that never passes: only double when (a) you are 
100% to win (b) it's the last roll of the game and you have an advantage. The 
bot can also take a double deeper than normal, since the mutant will always 
take the recube to 4. So the risk is 1 point and the reward is 5 points 
(instead of 3). So the take point is 16.7%. Gammons complicate it, but I'm sure 
you get the idea.




From: MK 
Sent: Tuesday, April 2, 2024 12:08:49 pm
To: Ian Shaw ; GnuBg Bug 
Subject: Re: Interesting question/experiment about value of cube ownership

On 3/31/2024 4:18 AM, Ian Shaw wrote:

> If the mutant strategy is always to take, then gnubg GAINS when > Mutant 
> takes a D/P because that increases the points GnuBg wins.

Yes, of course, but only and only if the GnuBG wins. Obviously you
faithfully assume that GnuBG will always win and keep raking in the
higher cube points but experiment like the ones I did may prove it
otherwise.

And this is only speaking about winning more than 50% of points. To
this day, I have never been able get you guys to talk about mutant
strategies winning more than what would be expected from their cube
error rates, which is even more important in debunking the elaborate
so-called "cube skill theory" a complete mound of cow pies...

> Currently, gnubg is assuming it is playing against a player using
> it's own cube strategy.

And this is why they are as easy to derail as toy trains on tracks
around the xmas tree and to beat even by people like me, who is a
nobody compared to gamblegammon giants.

See my 10-years old experiments against various bots at my site:

https://montanaonline.net/backgammon/

I do however believe that future bots, trained through cubeful and
matchful self-play, will come very close to "perfect" play that no
human may possibly beat but current bots, including GnuBG, are not
even worth a mention by that measure.

> It could be reprogrammed to take advantage of knowing that it's
> opponent would never pass.

Okay, well, I'm daring to tell me how do you propose the bot could
be reprogrammed to do that?

You don't need to post the programming code here. Just explain how
the bot would achieve that in plain language.

I bet you won't be able to do. Empty talk is cheap...

Let me hold your hand to make another baby step: even if you could
reprogram a bot to to that, it would become just another version of
the same toy train on tracks going in circles around the xmas tree,
with the same weakness of exploitability by being totally predictable.
After that, you would have to reprogram you bot by revising your
jackoffski cube formulae again... Do you see your problem..?

MK

> 
> *From:* MK 
> *Sent:* Friday, March 29, 2024 2:28:09 AM
> *To:* Ian Shaw ; GnuBg Bug 
> *Subject:* Re: Interesting question/experiment about value of cube ownership
> On 3/19/2024 3:54 AM, Ian Shaw wrote:
>
>> MK "Those numbers are based on how the bot would play against itself.
>> If you accept the bot's decisions as best/perfect and if you try to
>> play just like bot, assuming that your opponent will also try to play
>> just like the bot, of course you wouldn't/shouldn't double."
>
>> Agreed. Against a worse player, you can take with fewer winning chances.
>> If your opponent will give up enough equity in errors to overcome the
>> error of the bad take (and your own subsequent errors), then you should
>> still come out ahead.
>
> I hope you are realizing that you are agreeing with the bot, not with me.
> What you quoted from me above was in response to your previously saying:
>
>  "I wouldn’t double.  As shown by the rollouts, I'd be giving
>  "up 0.36 points per game, on average. Even if I knew you would
>  "roll 66, I would still take, because the equity of -0.276 * 2
>  "is still better than giving up a whole 1.000 point.
>
> Would you drop if you knew that the mutant would roll 77? You wouldn't.
> (Just exaggerating to make a point, while reminiscing how Jellyfish was
> not only rolling 77's but shamelessly playing them to escape 6-primes:)
>
> Once the mutant conditionally pre-doubles, (i.e. if rules allow it, in
> case it wins the opening roll), you will become hostage to its strategy,
> or in better sounding words, you will be dancing to its tune... ;)
>
> Reaching a D/P later won't help you either because the mutant will not
> drop and will force you to keep playing until the last roll, perhaps
> trading the cube more times back and forth.
>
> Letting the bot play for both side after the "opening double" actually
> defeats the purpose of the experiment but since there is no "separately
> existing, fully functional mutant bot (that would play like me;)" to
> make it play against GnuBG 2-ply, this is the only way we can do it and
> it's better than nothing.
>

Re: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

Yes, I am referring to theoretical continuous model for the 20% value, and 
agree it would apply to any suitable game, not just backgammon.

But backgammon isn't a continuous game. It has jumps in equity betewen one 
opportunity to double and the next.

The concept of cube efficiency is the estimate to allow for this. What other 
approximations are there? If course, at deeper plies than 0, bots look at the 
outcomes of all possible sequences so the effect of the cube efficiency 
approximation diminishes.

What would be your proposed structure for training a cubeful bot? What gains 
and obstacles do you foresee.

If course I think similarly about your other insulting terminology. Speaking 
personally, it reduces the amount of pleasure I get from the discussion and 
therefore the amount of time I'm prepared to put in.


From: MK 
Sent: Tuesday, April 2, 2024 11:43:40 AM
To: Ian Shaw ; GnuBg Bug 
Subject: Re: Interesting question/experiment about value of cube ownership

On 3/31/2024 3:53 AM, Ian Shaw wrote:

> I'm glad we agree on the basic 25% take point. Do you also agree on
> the the theoretical 20% take point for perfect cube efficiency?

If by "theoretical" you mean a purely mathematical proposition, i.e.
not specifically related to cubeful backgammon, cubeful hopscotch,
cubeful snakes and ladders, etc., or (to repeat myself) as applied
in simple games where you can calculate those 25% and 20% accurately
and consistently, then I would say I agree with you.

> As far as I know, the only part of cube theory not calculated
> mathematically is the estimate made for cube efficiency. But it's
> a long time since I read Janowski so I may be wrong on that.

Since no bot was ever trained through cubeful self-play, all cubeful
calculations of all kinds are "mythematically" calculated, by using
repeatedly adjusted constants to produce the results desired by the
humans of faith...

> (I think you are using "gamble gammon" as a pejorative. I suspect
> that every time you do so, you lose credibility with anyone likely
> to read this. You may wish to take this into account, bearing in
> mind that most backgammon with the cube isn't played for money.)

I like writing poems, coining new expressions, country music lyrics,
word plays, puns, etc. and ta times I use them pejoratively but not
so much with "gamblegammon", for which I used worse names.

There was a game called "backgammon" before the "doubling cube" was
introduced to it for gambling purposes, which changed it drastically
enough for it to be considered a "variant" of backgammon, just like
any other such variants.

I have argued for over 20 years that the "cubeful backgammon variant"
needs to be given a new name and I proposed "gamblegammon", which I
thought was quite appropriate. I have been calling it "gamblegammon"
in other forums like RGB ever since and invited others to suggest
other names for it if they didn't like my "gamblegammon". Feel free
to offer your suggestion.

While on the subject, I'm surprised that you didn't catch on to many
other expressions that I have been using pejoratively, such as my
"fartoffski cube skill formula" against the "jackoffski cube skill
formula", etc.

Focus on understanding and refuting my arguments. If you (all) can't,
then I really don't care about my credibility with people who can't
understand my arguments, let alone rise up to defeat my arguments.

MK

> 
> *From:* MK 
> *Sent:* Friday, March 29, 2024 4:34:39 AM
> *To:* Ian Shaw ; GnuBg Bug 
> *Subject:* Re: Interesting question/experiment about value of cube ownership
> On 3/19/2024 7:44 AM, Ian Shaw wrote:
>
>> I don’t "divinely believe" in the current cube theory. I understand
>> the maths behind it. If you have found errors in the maths, then I
>> would be glad to re-evaluate.
>
>> Let's find out where you disagree by starting from the beginning.
>> What is your analysis of the basic 25% takepoint calculation?
>
>
> I'm not questioning whether a simple doubling theory, (assuming it
> can be called a "theory"), can be applied in simple game where you
> can calculate that 25% accurately and consistently.
>
> I'm questioning whether some doubling strategy can be applied in
> gamblegammon, based on a jumble of incomplete/inaccurate empirical
> statistics and mathematical calculation formulas that were several
> times retrofitted to produce some expected results, and call it a
> "cube skill theory".
>
> In RGB, some mathematicians had argued that it could be called a
> "theory" because it was mathematically proven, which can not be
> because the so-called "cube skill" is not a purely mathematical
> proposition.
>
> In a game involving luck like gamblegammon, (more luck than skill
> in my personal opinion), the proposition is necessarily statistical,
> empirical one and thus needs to be empirically proven.
>
> You say "let's start from the 

Re: Arch Linux minimal container userland 100% reproducible - now what?

[James Addison via rb-general]

Hi John,

On Fri, 29 Mar 2024 at 19:29, John Gilmore  wrote:
>
> kpcyrd  wrote:
> > 1) There's currently no way to tell if a package can be built offline
> > (without trying yourself).
>
> Packages that can't be built offline are not reproducible, by
> definition.  They depend on outside events and circumstances
> in order for a third party to reproduce them successfully.
>
> So, fixing that in each package would be a prerequisite to making a
> reproducible Arch distro (in my opinion).

This perspective is valuable because it is certainly true that unreliable
or unexpected responses from a network adapter could cause software builds to
fail, be delayed, or contain errors.

However I fail to see why any of those circumstances would not be
equally possible
in the case of equivalent responses from physically or locally attached I/O
devices.

A storage device could be considered a node on a local network that no other
host is able to communicate with directly; and to my knowledge it's rarely the
case that traffic to-and-from local storage devices is inspected for integrity
by hardware/software outside of the device that it is connected to (which
isn't necessarily the place that it makes sense to run those checks).

My guess is that we could get into near-unsolvable philosophical territory
along this path, but I think it's worth being skeptical of the notions that
local-storage is always trustworthy and that the network should always be
avoided.

Regards,
James

Re: Two questions about build-path reproducibility in Debian

[James Addison via rb-general]

Thanks, Chris,

On Sun, 31 Mar 2024 at 13:01, Chris Lamb  wrote:
>
> Hi James,
>
> > Approximately thirty are still set to other severity levels, and I plan to
> > update those with the following adjusted messaging […]
>
> Looks good to me. :)
>
> Completely out of interest, are any of those 30 bugs tagged both
> "buildpath" and "toolchain"? It's written nowhere in Policy (and I
> can't remember if it's ever been discussed before), but if package X
> is causing package Y to be unreproducible, I feel that has some
> bearing on the severity of the bug for that issue filed against X…
> completely independent of whether package X is reproducible itself or
> not.  :)

None of the remaining thirty-or-so (and in fact, none of the 66 updated so far)
are usertagged both 'buildpath' and 'toolchain'.

I would say that a few of them _are_ 'toolchain packages' -- mono, binutils-dev
and a few others -- but for these bugs the buildpath issues are internal to
each package at build-time and do not affect the construction of other
packages in their ecosystem.

> Just to underscore that this is simply my curiosity before you
> reassign: in the particular case of *buildpath* AND toolchain, these
> should almost certainly be wishlist anyway because, as discussed, we
> "aren't testing buildpath".

Mostly agree.  Of the bugs in Debian that _are_ usertagged both buildpath and
also toolchain, a few of them appear to have possible known/tested fixes, but in
some cases are awaiting maintainer/upstream support.  Using a static buildpath
seems like it should mitigate most concern there, but if that were not the case,
then the severity of those could perhaps be re-argued based on the quantity,
popularity and importance of affected software (packaged or otherwise).

Regards,
James

Re: [Evergreen-general] Minors and Self Registration

[Lussier, Kathy via Evergreen-general]

Hi Gina,

We're using Quipu for self-registration at NOBLE. Even though it isn't the
Evergreen self-registration form, I can speak to how we handled minors at
NOBLE and also at my previous consortium, which was in the process of
implementing Quipu when I left.

In both cases, we looked to how libraries were handling the issuance of
physical library cards to minors to inform our policy on how to handle
registration through our online form. In my previous consortium, we found
that the form parents signed on behalf of their children in most of the
public libraries included an agreement that parents are solely responsible
for their child's use of library materials. Since our eCard allows access
to electronic resources, like Overdrive, it raised the question of how
parents could agree to this term if they didn't know their child had
registered for a card. All of the other terms they agreed to did not apply
to the use of e-resources (e.g. to be financially responsible for the loss
or damage of physical materials). In cases where a minor self registered
and then decided to pick up a physical card, the library's requirement for
the parental signature was applicable, so we only worried about the
e-resource use. In this case, the libraries agreed to a policy where
children under 13 could not self register for a card. If a minor of the age
of 14-15 self registered, Quipu requested a parental email address and sent
an email at registration informing the parent that the child had registered
for a card.

At NOBLE, we went in a different direction. Very few of our libraries ask
that parents agree that they are solely responsible for their child's use
of library materials. Our libraries ultimately decided against setting any
age restrictions. There also is no email sent to parents of minors.

Does Bilbliomation's self-registration allow for access to electronic
resources? If not, I would think the best way to approach this is for
libraries to continue to follow local policies for requiring parental
signatures when the minor picks up the physical card.

I hope this helps!
Kathy
--
Kathy Lussier
she/her
Executive Director
NOBLE: North of Boston Library Exchange
Danvers, MA
978-777-8844 x201
www.noblenet.org




On Mon, Apr 1, 2024 at 10:27 AM Gina Monti via Evergreen-general <
evergreen-general@list.evergreen-ils.org> wrote:

> Hi Everyone,
>
> I had a conversation with a library director in regards to the self
> registration page.  I know that there is support in developing a
> customizable page, but in the meantime, I wanted to ask how other
> libraries/consortia handle minors wanting to self-register for cards.
>
> I have mentioned to this director that we can add a DOB, but the main
> problem is having an actual acknowledgement of the library policy to
> protect minors given the current climate in regards to censorship.  This I
> completely understand, and I'm interested in your replies of how
> Evergreen can address this issue if possible.
>
> Thanks!
>
> --
> Gina Monti (she/her)
> Evergreen Systems Manager
> Bibliomation, Inc.
> (203) 577-4070 ext. 109
> English, American Sign Language
> _______
> Evergreen-general mailing list
> Evergreen-general@list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>
_______
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

[Evergreen-general] Minors and Self Registration

[Gina Monti via Evergreen-general]

Hi Everyone,

I had a conversation with a library director in regards to the self
registration page.  I know that there is support in developing a
customizable page, but in the meantime, I wanted to ask how other
libraries/consortia handle minors wanting to self-register for cards.

I have mentioned to this director that we can add a DOB, but the main
problem is having an actual acknowledgement of the library policy to
protect minors given the current climate in regards to censorship.  This I
completely understand, and I'm interested in your replies of how
Evergreen can address this issue if possible.

Thanks!

-- 
Gina Monti (she/her)
Evergreen Systems Manager
Bibliomation, Inc.
(203) 577-4070 ext. 109
English, American Sign Language
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

[Evergreen-general] Evergreen and TBS

[Frasur, Ruth via Evergreen-general]

Hello all,

I'm curious if any of you or anyone you know is using TBS point of sale 
software with Evergreen.  Feel free to email me off-list if you'd like.

Ruth Frasur Davis (she/they)
Coordinator
Evergreen Indiana Library Consortium
Evergreen Community Development Initiative
Indiana State Library
140 N. Senate Ave.
Indianapolis, IN 46204
(317) 232-3691

___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

OBS/rpm & java-21 success

[Bernhard M. Wiedemann via rb-general]

Hi,

today I want to share with you two successes on our path to total 
reproducibility in openSUSE:


Through the persistence of my colleague Jan Zerebecki and the help of 
mls (SUSE's rpm maintainer) we made nice progress on

https://bugzilla.opensuse.org/show_bug.cgi?id=1148824
to finally normalize mtimes in official openSUSE Tumbleweed rpms.

Together with a workaround for
https://github.com/rpm-software-management/rpm/issues/2965
this allowed me to create bit-identical rpms to the ones pulled from 
build.opensuse.org , processed with rpm --delsign


Now everything that was reproducible in my QA-tests is also 
reproducible+verifiable in practice.



The other success is that I saw 2 bit-identical java-21-openjdk rpm 
builds, but only when both were done on 1-core VMs, so there might only 
be some raciness left. [1]

javadoc output still has an issue from filesystem-readdir-order.
We have a build-tool workaround for that in place [2]


Ciao
Bernhard M.


[1] 
https://rb.zq1.de/compare.factory-20240331/diffs/java-21-openjdk-compare.out
[2] 
https://github.com/bmwiedemann/openSUSE/blob/54e27e1/packages/_/_project/_config#L19-L20


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

If the mutant strategy is always to take, then gnubg GAINS when Mutant takes a 
D/P because that increases the points GnuBg wins.


Currently, gnubg is assuming it is playing against a player using it's own cube 
strategy. It could be reprogrammed to take advantage of knowing that it's 
opponent would never pass.


From: MK 
Sent: Friday, March 29, 2024 2:28:09 AM
To: Ian Shaw ; GnuBg Bug 
Subject: Re: Interesting question/experiment about value of cube ownership

On 3/19/2024 3:54 AM, Ian Shaw wrote:

> MK "Those numbers are based on how the bot would play against itself.
> If you accept the bot's decisions as best/perfect and if you try to
> play just like bot, assuming that your opponent will also try to play
> just like the bot, of course you wouldn't/shouldn't double."

> Agreed. Against a worse player, you can take with fewer winning chances.
> If your opponent will give up enough equity in errors to overcome the
> error of the bad take (and your own subsequent errors), then you should
> still come out ahead.

I hope you are realizing that you are agreeing with the bot, not with me.
What you quoted from me above was in response to your previously saying:

"I wouldn’t double.  As shown by the rollouts, I'd be giving
"up 0.36 points per game, on average. Even if I knew you would
"roll 66, I would still take, because the equity of -0.276 * 2
"is still better than giving up a whole 1.000 point.

Would you drop if you knew that the mutant would roll 77? You wouldn't.
(Just exaggerating to make a point, while reminiscing how Jellyfish was
not only rolling 77's but shamelessly playing them to escape 6-primes:)

Once the mutant conditionally pre-doubles, (i.e. if rules allow it, in
case it wins the opening roll), you will become hostage to its strategy,
or in better sounding words, you will be dancing to its tune... ;)

Reaching a D/P later won't help you either because the mutant will not
drop and will force you to keep playing until the last roll, perhaps
trading the cube more times back and forth.

Letting the bot play for both side after the "opening double" actually
defeats the purpose of the experiment but since there is no "separately
existing, fully functional mutant bot (that would play like me;)" to
make it play against GnuBG 2-ply, this is the only way we can do it and
it's better than nothing.

So, this way the really "semi-mutant" play will lose but it still will
not lose more than what would be expected from the cube error rate that
the mutant incurs from this "opening double". This alone is enough to
prove that the currently dogmatized "cube skill theory" is a jarful of
cow chip cookies...

MK

Re: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

I'm glad we agree on the basic 25% take point. Do you also agree on the the 
theoretical 20% take point for perfect cube efficiency?

As far as I know, the only part of cube theory not calculated mathematically is 
the estimate made for cube efficiency. But it's a long time since I read 
Janowski so I may be wrong on that.

(I think you are using "gamble gammon" as a pejorative. I suspect that every 
time you do so, you lose credibility with anyone likely to read this. You may 
wish to take this into account, bearing in mind that most backgammon with the 
cube isn't played for money.)


Regards,

Ian Shaw


From: MK 
Sent: Friday, March 29, 2024 4:34:39 AM
To: Ian Shaw ; GnuBg Bug 
Subject: Re: Interesting question/experiment about value of cube ownership

On 3/19/2024 7:44 AM, Ian Shaw wrote:

> I don’t "divinely believe" in the current cube theory. I understand
> the maths behind it. If you have found errors in the maths, then I
> would be glad to re-evaluate.

> Let's find out where you disagree by starting from the beginning.
> What is your analysis of the basic 25% takepoint calculation?


I'm not questioning whether a simple doubling theory, (assuming it
can be called a "theory"), can be applied in simple game where you
can calculate that 25% accurately and consistently.

I'm questioning whether some doubling strategy can be applied in
gamblegammon, based on a jumble of incomplete/inaccurate empirical
statistics and mathematical calculation formulas that were several
times retrofitted to produce some expected results, and call it a
"cube skill theory".

In RGB, some mathematicians had argued that it could be called a
"theory" because it was mathematically proven, which can not be
because the so-called "cube skill" is not a purely mathematical
proposition.

In a game involving luck like gamblegammon, (more luck than skill
in my personal opinion), the proposition is necessarily statistical,
empirical one and thus needs to be empirically proven.

You say "let's start from the beginning". Yes, let's do so indeed.

TD-Gammon v.1 was empirically trained through self-play of cubeless
"money games", including gammons but not backgammons, and perhaps
not enough trials. That's it. That's your beginning...

To that, you use all kinds of "maths and mirrors" to add backgammon
rates, cubeful equity formulas, cubeful matchful equity tables, etc.
to "estimate" your winning chances, in order to apply to it what you
a "basic 25% take point". And I'm questioning sanity of all this, in
fact I'm arguing that it's all a pile of cow pies.

Shortcuts was taken in the days of TD-Gammon because of not having
enough CPU power, which is no longer true. Yet, there is no signs
of any willingness out there to create cubefully, matcfully trained
better gamblegammon bots.

It's easier to destroy a falsely claimed "theory" by poking holes in
it than to prove a proposition so that you can call it a theory, and
this is what I'm trying to accomplish with my experiments.

Since I can't single-handedly create a better bot, I'm trying what
I can do to create a need for, thus an incentive for the creation of
such a bot, "from scratch".

My "fartoffski mutant cube strategy", (based on arbitrary stages of
game and double/take points), in my experiments 11 and 12 came within
margin of error of beating GnuBG 2-ply. Folks, it's time for better
gamblegammon bots...

MK

Re: Two questions about build-path reproducibility in Debian

[James Addison via rb-general]

Hi again,

On Mon, 11 Mar 2024 at 18:24, James Addison  wrote:
>
> Hi folks,
>
> On Wed, 6 Mar 2024 at 01:04, James Addison  wrote:
> > [ ... snip ...]
> >
> > The Debian bug severity descriptions[1] provide some more nuance, and that
> > reassures me that wishlist should be appropriate for most of these bugs
> > (although I'll inspect their contents before making any changes).
>
> Please find below a draft of the message I'll send to each affected bugreport.
>
> Note: I confused myself when writing this; in fact Salsa-CI reprotest _does_
> continue to test build-path variance, at least until we decide otherwise.
>
> --- BEGIN DRAFT ---
> Because Debian builds packages from a fixed build path, customized build paths
> are _not_ currently evaluated by the 'reprotest' utility in Salsa-CI, or 
> during
> package builds on the Reproducible Builds team's package test infrastructure
> for Debian[1].
>
> This means that this package will pass current reproducibility tests; however
> we still believe that source code and/or build steps embed the build path into
> binary package output, making it more difficult that necessary for independent
> consumers to confirm whether their local compilations produce identical binary
> artifacts.
>
> As a result, this bugreport will remain open and be assigned the 'wishlist'
> severity[2].
>
> ...
>
> [1] - https://tests.reproducible-builds.org/debian/reproducible.html
>
> [2] - https://www.debian.org/Bugs/Developer#severities
> --- END DRAFT ---

Most of the remaining buildpath bugs have been updated to severity 'wishlist'.

Approximately thirty are still set to other severity levels, and I plan to
update those with the following adjusted messaging:

--- BEGIN DRAFT ---
Control: severity -1 wishlist

Dear Maintainer,

Currently, Debian's buildd and also the Reproducible Builds team's testing
infrastructure[1] both use a fixed build path when building binary packages.

This means that your package will pass current reproducibility tests; however
we believe that varying the build path still produces undesirable changes in
the binary package output, making it more difficult than necessary for
independent consumers to check the integrity of those packages by rebuilding
them themselves.

As a result, this bugreport will remain open and be re-assigned the 'wishlist'
severity[2].

You can use the 'reprotest' package build utility - either locally, or as
provided in Debian's Salsa continuous integration pipelines - to assist
uncovering reproducibility failures due build-path variance.

For more information about build paths and how they can affect reproducibility,
please refer to: https://reproducible-builds.org/docs/build-path/

...

[1] - https://tests.reproducible-builds.org/debian/reproducible.html

[2] - https://www.debian.org/Bugs/Developer#severities
--- END DRAFT ---

Thanks for your feedback and suggestions,
James

Verifying reproducibility of Java builds from Maven Central

[Railean, Alexander via rb-general]

Hi everybody,



I am trying to understand how someone can independently verify the 
reproducibility of Java projects on Maven Central. Having explored the 
repositories on Maven Central, I could not find examples where the "buildinfo" 
file was present.



The archives of this mailing list pointed out examples such as 
https://repo1.maven.org/maven2/com/typesafe/akka/akka-actor_2.13/2.6.4/akka-actor_2.13-2.6.4.buildinfo,
 and yet my understanding is that this is not enough [but why?], hence 
reproducible-central was created to address some sort of gap.



So far, my mental model is that:

*   By including buildinfo in the artifacts on Maven Central, library 
authors empower users to check for themselves if the build is reproducible or 
not.
*   Reproducible-central takes it a step further and attempts to do a build 
and then gives you a "yes/no" result.



Thus, the former makes the problem solvable in principle, whereas the latter 
actually solves it. Is my understanding is correct?





Besides that, I have some additional questions:

1. Can you provide references to documentation that explains how to make sure 
buildinfo ends up on Maven Central?

2. Is there a tutorial that describes how to get featured on Reproducible 
Central?





I had a look at 
https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/doc/BUILDSPEC.md,
 and my understanding is that this is not working for projects built on 
Windows, because it relies on rebuild.sh, which implies one has bash. The 
library I publish on Maven Central is built on a Windows computer - does this 
mean that I won't be able to list it in reproducible-builds?







Looking forward to your feedback,

Alex

[Evergreen-general] REMINDER: Evergreen Reports Interest Group Meets Tomorrow at 2 PM Eastern!

[Jessica Woolford via Evergreen-general]

Just a reminder that the Reports Interest Group will meet tomorrow to take
a sneak peak at the new Angular reports interface! Hope to see you there!

On Fri, Mar 22, 2024 at 12:07 PM Jessica Woolford 
wrote:

> The Reports Interest Group will meet next Wednesday, March 27th at 2 PM
> Eastern via Zoom. Our original plan was to talk about acquisition reports,
> but since the Angular reports interface development has been released for
> community testing, we thought it would be a good time to take a look at it!
> Andrea Buntz Neiman from Equinox Open Library Initiative will be joining us
> to show off the new interface.
>
> You're encouraged to take the new interface for a spin on the demo server
> <https://butternut.evergreencatalog.com/eg/staff> prior to the meeting.
> Login info for the server can be found here
> <https://wiki.evergreen-ils.org/doku.php?id=qa:concerto_logins>.
>
> Connection information and agenda can be found here:
> https://wiki.evergreen-ils.org/doku.php?id=evergreen-reports:meetings:2024-03-27
>
> Hope to see you there!
>
> Jessica
>
> --
>
> Jessica Woolford (she/her)
>
> Director of Member Services
>
> jwoolf...@biblio.org | (203) 577-4070 <203-577-4070>x105
>
> » Help Desk: Open or Check a Ticket <https://helpdesk.biblio.org>
>
> [image: Stylized turquoise book with blue swirl around it, above text
> reading Bibliomation: Libraries Sharing Computerized Services]
> <https://biblio.org/>
>


-- 

Jessica Woolford (she/her)

Director of Member Services

jwoolf...@biblio.org | (203) 577-4070 <203-577-4070>x105

» Help Desk: Open or Check a Ticket <https://helpdesk.biblio.org>

[image: Stylized turquoise book with blue swirl around it, above text
reading Bibliomation: Libraries Sharing Computerized Services]
<https://biblio.org/>
_______
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Evergreen-general] [Evergreen-documentation] Bug Squashing Week - Final Report

[Diane Disbro via Evergreen-general]

Thank you to everyone who worked on this!

Diane Disbro
Pronouns: she/her
Circulation Coordinator
Scenic Regional Library
251 Union Plaza Drive
Union, MO 63084
(636) 583-0652 ext  110
ddis...@scenicregional.or g



On Mon, Mar 25, 2024 at 9:59 AM Terran McCanna via Evergreen-documentation <
evergreen-documentat...@list.evergreen-ils.org> wrote:

> Thanks to everyone who participated in last week's Bug Squashing Week and
> helped to make it another successful effort!
>
> The final report is at:
> https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing:2024-03
>
> As always, if I missed recording your name or spelled your name wrong,
> please let me know so that I can correct it!
>
>
> [image: logo with link to Georgia Public Library Service website]
> <https://georgialibraries.org/>
>
> Terran McCanna, PINES Program Manager
>
> --
>
> Georgia Public Library Service
>
> 2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341
>
> (404) 235-7138 | tmcca...@georgialibraries.org
>
> https://help.georgialibraries.org | h...@georgialibraries.org
>
> [image: logo with link to Georgia Public Library Service Facebook page]
> <https://www.facebook.com/georgialibraries>[image: logo with link to
> Georgia Public Library Service Instagram page]
> <https://www.instagram.com/georgialibraries/>[image: logo with link to
> Georgia Public Library Service LinkedIn page]
> <https://www.linkedin.com/company/georgia-public-library-service/>[image:
> logo with link to Georgia Public Library Service Threads page]
> <https://www.threads.net/@georgialibraries>
>
>
>
>
> ___
> Evergreen-documentation mailing list
> evergreen-documentat...@list.evergreen-ils.org
>
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-documentation
>
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Evergreen-general] [Evergreen-catalogers] Bug Squashing Week - Final Report

[Kate Coleman via Evergreen-general]

Incredible job everyone! It's always so cool to me to see the work that
comes out of this when everyone comes together!




On Mon, Mar 25, 2024 at 9:59 AM Terran McCanna via Evergreen-catalogers <
evergreen-catalog...@list.evergreen-ils.org> wrote:

> Thanks to everyone who participated in last week's Bug Squashing Week and
> helped to make it another successful effort!
>
> The final report is at:
> https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing:2024-03
>
> As always, if I missed recording your name or spelled your name wrong,
> please let me know so that I can correct it!
>
>
> [image: logo with link to Georgia Public Library Service website]
> <https://georgialibraries.org/>
>
> Terran McCanna, PINES Program Manager
>
> --
>
> Georgia Public Library Service
>
> 2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341
>
> (404) 235-7138 | tmcca...@georgialibraries.org
>
> https://help.georgialibraries.org | h...@georgialibraries.org
>
> [image: logo with link to Georgia Public Library Service Facebook page]
> <https://www.facebook.com/georgialibraries>[image: logo with link to
> Georgia Public Library Service Instagram page]
> <https://www.instagram.com/georgialibraries/>[image: logo with link to
> Georgia Public Library Service LinkedIn page]
> <https://www.linkedin.com/company/georgia-public-library-service/>[image:
> logo with link to Georgia Public Library Service Threads page]
> <https://www.threads.net/@georgialibraries>
>
>
>
>
> ___
> Evergreen-catalogers mailing list
> evergreen-catalog...@list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-catalogers
>
_______
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

[Evergreen-general] Bug Squashing Week - Final Report

[Terran McCanna via Evergreen-general]

Thanks to everyone who participated in last week's Bug Squashing Week and
helped to make it another successful effort!

The final report is at:
https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing:2024-03

As always, if I missed recording your name or spelled your name wrong,
please let me know so that I can correct it!


[image: logo with link to Georgia Public Library Service website]
<https://georgialibraries.org/>

Terran McCanna, PINES Program Manager

--

Georgia Public Library Service

2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341

(404) 235-7138 | tmcca...@georgialibraries.org

https://help.georgialibraries.org | h...@georgialibraries.org

[image: logo with link to Georgia Public Library Service Facebook page]
<https://www.facebook.com/georgialibraries>[image: logo with link to
Georgia Public Library Service Instagram page]
<https://www.instagram.com/georgialibraries/>[image: logo with link to
Georgia Public Library Service LinkedIn page]
<https://www.linkedin.com/company/georgia-public-library-service/>[image:
logo with link to Georgia Public Library Service Threads page]
<https://www.threads.net/@georgialibraries>
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Evergreen-general] The Evergreen Project Board Election - Voter Registration OPEN

[Frasur, Ruth via Evergreen-general]

Hello all,

Here's one last shot to register to vote for the Evergreen Project Board 
elections which will take place next week, beginning on April 1.  If you have 
not done so already, please fill out the voter registration form which is 
available at https://forms.gle/s8CGfVqRfzcdSV368. I will be closing the form at 
4 p.m. Eastern Time today.

Ruth Frasur Davis (she/they)
Coordinator
Evergreen Indiana Library Consortium
Evergreen Community Development Initiative
Indiana State Library
140 N. Senate Ave.
Indianapolis, IN 46204
(317) 232-3691

From: Frasur, Ruth
Sent: Tuesday, March 12, 2024 2:52 PM
To: Evergreen-general@list.evergreen-ils.org
Subject: The Evergreen Project Board Election - Voter Registration OPEN

Hello all,

Thank you to all who submitted nominations to fill open and opening seats on 
the Evergreen Project Board.  The next step in this process is voter 
registration.  Anyone who has contributed to the Evergreen Community or is 
employed by an institution that utilizes the Evergreen open-source ILS is 
eligible to register and ultimately vote.  The voter registration form is 
available at https://forms.gle/s8CGfVqRfzcdSV368 and will remain open until EOB 
on Friday, March 22.

Ruth Frasur Davis (she/they)
President
Evergreen Project Board
Coordinator
Evergreen Indiana Library Consortium
Evergreen Community Development Initiative
Indiana State Library
140 N. Senate Ave.
Indianapolis, IN 46204
(317) 232-3691

___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

[Evergreen-general] PINES is hiring!

[Tiffany Little via Evergreen-general]

Good morning, and apologies in advance for the crossposting.

We're very excited to announce that two of our three vacant positions on
the PINES team are now posted and open for applications!

*PINES Cataloging Specialist*
https://georgialibraries.org/job/georgia-public-library-service-atlanta-295-pines-cataloging-specialist/

*PINES Bibliographic Services Specialist*
https://georgialibraries.org/job/georgia-public-library-service-atlanta-295-pines-bibliographic-services-specialist/

The third posting, the PINES Collection Management Specialist, is in the
final phases of approvals and will be posted as soon as those are complete.

Please make sure to review the notes in the "Regarding this Posting"
section for each position. If anyone has any other questions, you're more
than welcome to email me.

We hope you'll consider joining the team!

Thanks,
Tiffany


[image: logo with link to Georgia Public Library Service website]
<https://georgialibraries.org/>

Tiffany Little

*PINES Bibliographic Projects Manager*

--

Georgia Public Library Service

2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341

(404) 235-7161 | tlit...@georgialibraries.org

[image: logo with link to Georgia Public Library Service Facebook page]
<https://www.facebook.com/georgialibraries>[image: logo with link to
Georgia Public Library Service Instagram page]
<https://www.instagram.com/georgialibraries/>[image: logo with link to
Georgia Public Library Service LinkedIn page]
<https://www.linkedin.com/company/georgia-public-library-service/>[image:
logo with link to Georgia Public Library Service Threads page]
<https://www.threads.net/@georgialibraries>

Join our email list <http://georgialibraries.org/subscription> for stories
of Georgia libraries making an impact in our communities.
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

[Evergreen-general] Permissions Working Group Meeting Tuesday, March 26

[Susan Morrison via Evergreen-general]

Good Morning,

The Permissions Working Group will be meeting tomorrow, Tuesday, March 26, 
at 3 p.m. EST. 

Here is the agenda and connection info:
https://docs.google.com/document/d/1ZSI_LgX5FmFX1qFp3QYIn7hLc-r0HwPmQjm3GQlWR7E/edit?usp=sharing

Notes from previous meetings can be found here:
https://wiki.evergreen-ils.org/doku.php?id=community:permissions_working_group#past_meetings
 
<https://wiki.evergreen-ils.org/doku.php?id=community:permissions_working_group#next_meeting>

Thanks all!
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

[Evergreen-general] Item status translations in Evergreen

[Linda Jansová via Evergreen-general]

Dear all,

It seems that currently default item statuses can only be translated 
within Evergreen, e.g., on Blake’s bugsquash2 server via this interface:


https://bugsquash2.mobiusconsortium.org/eg2/en-US/staff/admin/server/config/copy_status

We are just wondering – as these strings are the same in every Evergreen 
installation, wouldn’t it make sense to have them translated on 
Launchpad or in POEditor?


But maybe there are practical reasons why the current approach makes 
more sense (perhaps like the fact that the original strings can be 
overwritten in the interface so that once they change, the translations 
would no longer be correct)?


In previous versions only the custom item statuses had to be translated 
one by one in the installation.


The default ones are still included in the db.seed file on Launchpad, 
e.g. this translation for Discard/Weed item status:


https://translations.launchpad.net/evergreen/main/+pots/db.seed/cs/+translate?batch=10=all=Discard%2FWeed

Thank you for sharing your thoughts!

And – last but not least – a big thank you goes out to Blake for setting 
up the bugsquash2 test server with Czech!


Linda


___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: Arch Linux minimal container userland 100% reproducible - now what?

[Bernhard M. Wiedemann via rb-general]

On 21/03/2024 21.38, kpcyrd wrote:
- libjpeg-turbo: this package contains a .jar file that is built by 
CMake and contains timestamps of the buildtime, but there's no way in 
CMake to pass --date to the jar executable to normalize this


You could use strip-nondeterminism for post-processing there.
For some reason it is reproducible in my openSUSE tests without us doing 
any extra steps.

https://ismypackagereproducibleyet.org/?pkg=libjpeg-turbo


- librsvg: the 3 rebuilders I've checked produced a .text section that is 6 bytes shorter (0x2dda2c vs 0x2dda26), I didn't investigate further yet, the diff is quite long because a lot of addresses are mismatching as a consequence 


My notes have https://gitlab.gnome.org/GNOME/librsvg/-/issues/1015 which 
turned out to be from pango mis-rendering text when font files were absent.


Ciao
Bernhard M.

[Evergreen-general] Bug Squashing Week Winding Down

[Terran McCanna via Evergreen-general]

Thank you so much to everyone who participated for making this Bug
Squashing Week another productive one! I'll send out the final numbers on
Monday and include any further updates that come in before then.

A few things of note for up and coming features and fixes:

   - The new, Angularized version of the Reports Interface is up and
   running on https://butternut.evergreencatalog.com/eg/staff and is
   looking great! There is some testing feedback entered so far, so please put
   it through its paces and add any issues you find to
   <https://bugs.launchpad.net/evergreen/+bug/1993823>
   https://bugs.launchpad.net/evergreen/+bug/1993823


   - A fix has been signed off on that will prevent staff from submitting
   holds with invalid pickup locations (yay!)
   - A new feature that allows carousel creation from item buckets has been
   tested and signed off on (yay!)
   - The time it takes to batch edit items and call numbers from Item
   Status has been cut down drastically (yay!)

And many more improvements have been made! The full list is at:
https://docs.google.com/spreadsheets/d/1Z_IeLJQ9niiEXnUfftkIAf5YFvNmyfgJ_h4HKq27Kog/edit#gid=1787447764




[image: logo with link to Georgia Public Library Service website]
<https://georgialibraries.org/>

Terran McCanna, PINES Program Manager

--

Georgia Public Library Service

2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341

(404) 235-7138 | tmcca...@georgialibraries.org

https://help.georgialibraries.org | h...@georgialibraries.org

[image: logo with link to Georgia Public Library Service Facebook page]
<https://www.facebook.com/georgialibraries>[image: logo with link to
Georgia Public Library Service Instagram page]
<https://www.instagram.com/georgialibraries/>[image: logo with link to
Georgia Public Library Service LinkedIn page]
<https://www.linkedin.com/company/georgia-public-library-service/>[image:
logo with link to Georgia Public Library Service Threads page]
<https://www.threads.net/@georgialibraries>
_______
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

[Evergreen-general] Evergreen Reports Interest Group Meeting Wednesday at 2 PM Eastern

[Jessica Woolford via Evergreen-general]

The Reports Interest Group will meet next Wednesday, March 27th at 2 PM
Eastern via Zoom. Our original plan was to talk about acquisition reports,
but since the Angular reports interface development has been released for
community testing, we thought it would be a good time to take a look at it!
Andrea Buntz Neiman from Equinox Open Library Initiative will be joining us
to show off the new interface.

You're encouraged to take the new interface for a spin on the demo server
<https://butternut.evergreencatalog.com/eg/staff> prior to the meeting.
Login info for the server can be found here
<https://wiki.evergreen-ils.org/doku.php?id=qa:concerto_logins>.

Connection information and agenda can be found here:
https://wiki.evergreen-ils.org/doku.php?id=evergreen-reports:meetings:2024-03-27

Hope to see you there!

Jessica

-- 

Jessica Woolford (she/her)

Director of Member Services

jwoolf...@biblio.org | (203) 577-4070 <203-577-4070>x105

» Help Desk: Open or Check a Ticket <https://helpdesk.biblio.org>

[image: Stylized turquoise book with blue swirl around it, above text
reading Bibliomation: Libraries Sharing Computerized Services]
<https://biblio.org/>
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

[Evergreen-general] next meeting of the Evergreen Project board

[Katie Greenleaf Martin via Evergreen-general]

Hello all,

 The Evergreen Project Board will be meeting Thursday, March 20 at 11 a.m. PT / 
1 p.m. CT / 2 p.m. ET.
 The agenda and connection details for the meeting are at  
https://wiki.evergreen-ils.org/doku.php?id=governance:minutes:2024-03-21
 This meeting is public and community members are encouraged to attend.
 Thanks!
Katie
TEP Secretary



[cid:image001.png@01DA7AE4.ED999B10]Katie Greenleaf Martin (she/her), Executive 
Director
Pennsylvania Integrated Library System (PaILS) | SPARK
(717) 873-9461 | k...@sparkpa.org<mailto:k...@sparkpa.org>
support.sparkpa.org<https://support.sparkpa.org/> | 
supp...@sparkpa.org<mailto:supp...@sparkpa.org>

___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: Arch Linux minimal container userland 100% reproducible - now what?

[David A. Wheeler via rb-general]

> On Mar 20, 2024, at 8:42 AM, kpcyrd  wrote:
> 
> hello,
> 
> in last week's email to the reproducible-builds email list[1] about 
> reproducible Arch Linux I mentioned there's only one unreproducible package 
> left in docker.io/library/archlinux.
> 
> [1]: 
> https://lists.reproducible-builds.org/pipermail/rb-general/2024-March/003291.html
> 
> Due to amazing work by dvzrv and Foxboron this package is now also 
> reproducible!

That is fantastic, congratulations!!

But you know what I'm going to ask :-). What steps are left, if any, before the 
"normal" Arch Linux packages that people install are reproducible (at least in 
core Arch Linux)? Has that milestone been achieved? Will it be achieved once 
some package updates are released? Or is there something more, and if so, what 
is it?

Sorry, it wasn't clear to me if this was some sort of special set of "test 
packages" or if they were the normal Arch Linux packages.

--- David A. Wheeler

[Evergreen-general] 2023 New Evergreen Members for Annual Report

[Frasur, Ruth via Evergreen-general]

Hello all,

I am helping to compile information for the 2023 Evergreen Community Annual 
Report. One of my tasks is to gather the names of as many new Evergreen 
libraries as possible. Some of you have already received emails from me.  If 
not, it's not because you're not important.  It's because I have gaps in my 
knowledge.

If your library started using the Evergreen ILS in 2023, please let me know.

Ruth Frasur Davis (she/they)
Coordinator
Evergreen Indiana Library Consortium
Evergreen Community Development Initiative
Indiana State Library
140 N. Senate Ave.
Indianapolis, IN 46204
(317) 232-3691

___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Evergreen-general] [External] Paperback vs. Hardcover Records

[Joan Kranich via Evergreen-general]

Hi Eva,

Thank you for the Part suggestion.  That has been suggested by some of our
librarians.  The problem is that C/W MARS uses a lot of Parts.  We use
Parts for our periodical issues which are added as items, travel guides and
things with parts.  We also use Parts for DVD sets that are separated into
multiple items.  This becomes complicated.  All suggestions are welcome tho
so we can determine the best path forward.

Joan

On Wed, Mar 20, 2024 at 1:14 PM Cerninakova Eva via Evergreen-general <
evergreen-general@list.evergreen-ils.org> wrote:

>
> Have you considered using the functionality for parts? I believe this
> would make it possible to keep one record and at the same time allow
> patrons to choose paperback or hardcover when placing hold
>
>
>
>
>
>
>
> Mgr. Eva Cerniňáková, Ph.D.
> vedoucí Knihovny Jabok
>
> Jabok - Vyšší odborná škola sociálně pedagogická a teologická
> +420 211 222 409
> cer...@jabok.cz
> knihovna.jabok.cz
> Salmovská 8, Praha 2, 120 00
>
>
>
>
>
>
>
> Dne st 20. 3. 2024 18:09 uživatel Tiffany Little via Evergreen-general <
> evergreen-general@list.evergreen-ils.org> napsal:
>
>> PINES uses the same record if everything else about the item is the same
>> aside from the binding.
>>
>>
>> https://pines.georgialibraries.org/dokuwiki/doku.php?id=cat:matching_criteria#special_cases
>>
>>
>> [image: logo with link to Georgia Public Library Service website]
>> <https://georgialibraries.org/>
>>
>> Tiffany Little
>>
>> *PINES Bibliographic Projects Manager*
>>
>> --
>>
>> Georgia Public Library Service
>>
>> 2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341
>>
>> (404) 235-7161 | tlit...@georgialibraries.org
>>
>> [image: logo with link to Georgia Public Library Service Facebook page]
>> <https://www.facebook.com/georgialibraries>[image: logo with link to
>> Georgia Public Library Service Instagram page]
>> <https://www.instagram.com/georgialibraries/>[image: logo with link to
>> Georgia Public Library Service LinkedIn page]
>> <https://www.linkedin.com/company/georgia-public-library-service/>[image:
>> logo with link to Georgia Public Library Service Threads page]
>> <https://www.threads.net/@georgialibraries>
>>
>> Join our email list <http://georgialibraries.org/subscription> for
>> stories of Georgia libraries making an impact in our communities.
>>
>>
>> On Wed, Mar 20, 2024 at 1:06 PM Frasur, Ruth via Evergreen-general <
>> evergreen-general@list.evergreen-ils.org> wrote:
>>
>>> Evergreen Indiana uses separate records if the paperback and hardcover
>>> are dramatically different in terms of pagination/additional contents.  We
>>> use the same record is the main difference is just the cover type.
>>>
>>>
>>>
>>> Ruth Frasur Davis (she/they)
>>>
>>> Coordinator
>>>
>>> *Evergreen Indiana Library Consortium*
>>>
>>> *Evergreen Community Development Initiative*
>>>
>>> Indiana State Library
>>>
>>> 140 N. Senate Ave.
>>>
>>> Indianapolis, IN 46204
>>>
>>> (317) 232-3691
>>>
>>>
>>>
>>> *From:* Evergreen-general <
>>> evergreen-general-boun...@list.evergreen-ils.org> *On Behalf Of *Terran
>>> McCanna via Evergreen-general
>>> *Sent:* Wednesday, March 20, 2024 1:01 PM
>>> *To:* Evergreen Discussion Group <
>>> evergreen-general@list.evergreen-ils.org>
>>> *Cc:* Terran McCanna 
>>> *Subject:* Re: [Evergreen-general] [External] Paperback vs. Hardcover
>>> Records
>>>
>>>
>>>
>>>  This is an EXTERNAL email. Exercise caution. DO NOT open
>>> attachments or click links from unknown senders or unexpected email. 
>>> --
>>>
>>> PINES uses separate records.
>>>
>>>
>>>
>>> On Wed, Mar 20, 2024, 12:57 PM Szwagiel, Will via Evergreen-general <
>>> evergreen-general@list.evergreen-ils.org> wrote:
>>>
>>> Good afternoon Joan,
>>>
>>>
>>>
>>> Like you, our bibliographic records can contain both paperback and
>>> hardcover versions of a book.  We actually encourage this, as well, as part
>>> of our cataloging best practices to try and cut down on duplicate records
>>> and to make sure that as many items as possible are available for patrons
>>> on a single re

Re: [Evergreen-general] [External] Paperback vs. Hardcover Records

[Joan Kranich via Evergreen-general]

Hi Tiffany,

Thank you for the link to your documentation.

And thanks everyone for your really helpful responses!  I appreciate it.

Joan


On Wed, Mar 20, 2024 at 1:09 PM Tiffany Little via Evergreen-general <
evergreen-general@list.evergreen-ils.org> wrote:

> PINES uses the same record if everything else about the item is the same
> aside from the binding.
>
>
> https://pines.georgialibraries.org/dokuwiki/doku.php?id=cat:matching_criteria#special_cases
>
>
> [image: logo with link to Georgia Public Library Service website]
> <https://georgialibraries.org/>
>
> Tiffany Little
>
> *PINES Bibliographic Projects Manager*
>
> --
>
> Georgia Public Library Service
>
> 2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341
>
> (404) 235-7161 | tlit...@georgialibraries.org
>
> [image: logo with link to Georgia Public Library Service Facebook page]
> <https://www.facebook.com/georgialibraries>[image: logo with link to
> Georgia Public Library Service Instagram page]
> <https://www.instagram.com/georgialibraries/>[image: logo with link to
> Georgia Public Library Service LinkedIn page]
> <https://www.linkedin.com/company/georgia-public-library-service/>[image:
> logo with link to Georgia Public Library Service Threads page]
> <https://www.threads.net/@georgialibraries>
>
> Join our email list <http://georgialibraries.org/subscription> for
> stories of Georgia libraries making an impact in our communities.
>
>
> On Wed, Mar 20, 2024 at 1:06 PM Frasur, Ruth via Evergreen-general <
> evergreen-general@list.evergreen-ils.org> wrote:
>
>> Evergreen Indiana uses separate records if the paperback and hardcover
>> are dramatically different in terms of pagination/additional contents.  We
>> use the same record is the main difference is just the cover type.
>>
>>
>>
>> Ruth Frasur Davis (she/they)
>>
>> Coordinator
>>
>> *Evergreen Indiana Library Consortium*
>>
>> *Evergreen Community Development Initiative*
>>
>> Indiana State Library
>>
>> 140 N. Senate Ave.
>>
>> Indianapolis, IN 46204
>>
>> (317) 232-3691
>>
>>
>>
>> *From:* Evergreen-general <
>> evergreen-general-boun...@list.evergreen-ils.org> *On Behalf Of *Terran
>> McCanna via Evergreen-general
>> *Sent:* Wednesday, March 20, 2024 1:01 PM
>> *To:* Evergreen Discussion Group <
>> evergreen-general@list.evergreen-ils.org>
>> *Cc:* Terran McCanna 
>> *Subject:* Re: [Evergreen-general] [External] Paperback vs. Hardcover
>> Records
>>
>>
>>
>>  This is an EXTERNAL email. Exercise caution. DO NOT open attachments
>> or click links from unknown senders or unexpected email. 
>> --
>>
>> PINES uses separate records.
>>
>>
>>
>> On Wed, Mar 20, 2024, 12:57 PM Szwagiel, Will via Evergreen-general <
>> evergreen-general@list.evergreen-ils.org> wrote:
>>
>> Good afternoon Joan,
>>
>>
>>
>> Like you, our bibliographic records can contain both paperback and
>> hardcover versions of a book.  We actually encourage this, as well, as part
>> of our cataloging best practices to try and cut down on duplicate records
>> and to make sure that as many items as possible are available for patrons
>> on a single record.  There will be instances, however, where we suggest
>> using a separate record, but that is usually based on the content of the
>> book, not whether it is paperback or hardcover.
>>
>>
>>
>> The majority of our member libraries are fine with this, but we do
>> occasionally receive requests to separate paperbacks and hardcovers,
>> because some libraries have patrons who only want one or the other.  One
>> recommendation we have made is for libraries to use call numbers and/or
>> shelving locations to identify if a specific item is paperback.  For
>> example, one member library puts "Apb" for "Adult Paperback" at the
>> beginning of the call numbers for mass market paperback books.
>>
>>
>>
>> This may not help patrons as much when placing holds, because they cannot
>> place item level holds, but it allows staff to easily identify a paperback
>> version so they can place an item hold for the patron.  Staff would just
>> have to encourage patrons to come to them to place the hold, so the staff
>> can place the item level hold for the patron.
>>
>>
>>
>> It is admittedly not a perfect solution, but because we have combined
>> paper

Re: [Evergreen-general] [External] Paperback vs. Hardcover Records

[Cerninakova Eva via Evergreen-general]

Have you considered using the functionality for parts? I believe this would
make it possible to keep one record and at the same time allow patrons to
choose paperback or hardcover when placing hold







Mgr. Eva Cerniňáková, Ph.D.
vedoucí Knihovny Jabok

Jabok - Vyšší odborná škola sociálně pedagogická a teologická
+420 211 222 409
cer...@jabok.cz
knihovna.jabok.cz
Salmovská 8, Praha 2, 120 00







Dne st 20. 3. 2024 18:09 uživatel Tiffany Little via Evergreen-general <
evergreen-general@list.evergreen-ils.org> napsal:

> PINES uses the same record if everything else about the item is the same
> aside from the binding.
>
>
> https://pines.georgialibraries.org/dokuwiki/doku.php?id=cat:matching_criteria#special_cases
>
>
> [image: logo with link to Georgia Public Library Service website]
> <https://georgialibraries.org/>
>
> Tiffany Little
>
> *PINES Bibliographic Projects Manager*
>
> --
>
> Georgia Public Library Service
>
> 2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341
>
> (404) 235-7161 | tlit...@georgialibraries.org
>
> [image: logo with link to Georgia Public Library Service Facebook page]
> <https://www.facebook.com/georgialibraries>[image: logo with link to
> Georgia Public Library Service Instagram page]
> <https://www.instagram.com/georgialibraries/>[image: logo with link to
> Georgia Public Library Service LinkedIn page]
> <https://www.linkedin.com/company/georgia-public-library-service/>[image:
> logo with link to Georgia Public Library Service Threads page]
> <https://www.threads.net/@georgialibraries>
>
> Join our email list <http://georgialibraries.org/subscription> for
> stories of Georgia libraries making an impact in our communities.
>
>
> On Wed, Mar 20, 2024 at 1:06 PM Frasur, Ruth via Evergreen-general <
> evergreen-general@list.evergreen-ils.org> wrote:
>
>> Evergreen Indiana uses separate records if the paperback and hardcover
>> are dramatically different in terms of pagination/additional contents.  We
>> use the same record is the main difference is just the cover type.
>>
>>
>>
>> Ruth Frasur Davis (she/they)
>>
>> Coordinator
>>
>> *Evergreen Indiana Library Consortium*
>>
>> *Evergreen Community Development Initiative*
>>
>> Indiana State Library
>>
>> 140 N. Senate Ave.
>>
>> Indianapolis, IN 46204
>>
>> (317) 232-3691
>>
>>
>>
>> *From:* Evergreen-general <
>> evergreen-general-boun...@list.evergreen-ils.org> *On Behalf Of *Terran
>> McCanna via Evergreen-general
>> *Sent:* Wednesday, March 20, 2024 1:01 PM
>> *To:* Evergreen Discussion Group <
>> evergreen-general@list.evergreen-ils.org>
>> *Cc:* Terran McCanna 
>> *Subject:* Re: [Evergreen-general] [External] Paperback vs. Hardcover
>> Records
>>
>>
>>
>>  This is an EXTERNAL email. Exercise caution. DO NOT open attachments
>> or click links from unknown senders or unexpected email. 
>> --
>>
>> PINES uses separate records.
>>
>>
>>
>> On Wed, Mar 20, 2024, 12:57 PM Szwagiel, Will via Evergreen-general <
>> evergreen-general@list.evergreen-ils.org> wrote:
>>
>> Good afternoon Joan,
>>
>>
>>
>> Like you, our bibliographic records can contain both paperback and
>> hardcover versions of a book.  We actually encourage this, as well, as part
>> of our cataloging best practices to try and cut down on duplicate records
>> and to make sure that as many items as possible are available for patrons
>> on a single record.  There will be instances, however, where we suggest
>> using a separate record, but that is usually based on the content of the
>> book, not whether it is paperback or hardcover.
>>
>>
>>
>> The majority of our member libraries are fine with this, but we do
>> occasionally receive requests to separate paperbacks and hardcovers,
>> because some libraries have patrons who only want one or the other.  One
>> recommendation we have made is for libraries to use call numbers and/or
>> shelving locations to identify if a specific item is paperback.  For
>> example, one member library puts "Apb" for "Adult Paperback" at the
>> beginning of the call numbers for mass market paperback books.
>>
>>
>>
>> This may not help patrons as much when placing holds, because they cannot
>> place item level holds, but it allows staff to easily identify a paperback
>> version so they can place an item hold for the patron.  Staff wou

Re: [Evergreen-general] [External] Paperback vs. Hardcover Records

[Joan Kranich via Evergreen-general]

Hi Elizabeth,

When we place a meta record hold all of print that is not large print has
the format book so we would need to add formats.  This is a
good consideration that I've been thinking about.

Thank you for your help.

Joan

On Wed, Mar 20, 2024 at 1:06 PM Elizabeth Davis via Evergreen-general <
evergreen-general@list.evergreen-ils.org> wrote:

> Hello
>
>
>
> PaILS uses the same record for hardcover and trade paper editions.  We
> encourage a separate record for mass market paperback.  I’d have to test it
> but would the multi-format hold work for instances where you have records
> for the hardcover and one for the paperback?
>
>
>
>
>
>
>
> *Elizabeth Davis* (she/her), *Support & Project Management Specialist*
>
> *Pennsylvania Integrated Library System **(PaILS) | SPARK*
>
> (717) 256-1627 | elizabeth.da...@sparkpa.org
> 
> support.sparkpa.org | supp...@sparkpa.org
>
>
>
> *From:* Evergreen-general <
> evergreen-general-boun...@list.evergreen-ils.org> *On Behalf Of *Terran
> McCanna via Evergreen-general
> *Sent:* Wednesday, March 20, 2024 1:01 PM
> *To:* Evergreen Discussion Group  >
> *Cc:* Terran McCanna 
> *Subject:* Re: [Evergreen-general] [External] Paperback vs. Hardcover
> Records
>
>
>
> PINES uses separate records.
>
>
>
> On Wed, Mar 20, 2024, 12:57 PM Szwagiel, Will via Evergreen-general <
> evergreen-general@list.evergreen-ils.org> wrote:
>
> Good afternoon Joan,
>
>
>
> Like you, our bibliographic records can contain both paperback and
> hardcover versions of a book.  We actually encourage this, as well, as part
> of our cataloging best practices to try and cut down on duplicate records
> and to make sure that as many items as possible are available for patrons
> on a single record.  There will be instances, however, where we suggest
> using a separate record, but that is usually based on the content of the
> book, not whether it is paperback or hardcover.
>
>
>
> The majority of our member libraries are fine with this, but we do
> occasionally receive requests to separate paperbacks and hardcovers,
> because some libraries have patrons who only want one or the other.  One
> recommendation we have made is for libraries to use call numbers and/or
> shelving locations to identify if a specific item is paperback.  For
> example, one member library puts "Apb" for "Adult Paperback" at the
> beginning of the call numbers for mass market paperback books.
>
>
>
> This may not help patrons as much when placing holds, because they cannot
> place item level holds, but it allows staff to easily identify a paperback
> version so they can place an item hold for the patron.  Staff would just
> have to encourage patrons to come to them to place the hold, so the staff
> can place the item level hold for the patron.
>
>
>
> It is admittedly not a perfect solution, but because we have combined
> paperbacks and hardcovers on single records for so long, trying to split
> them up now would simply be unfeasible.  And even if we began instructing
> catalogers to use separate records moving forward, that would still leave
> countless existing records in the catalog with both paperbacks and
> hardcovers on them.
>
>
>
> *William C. Szwagiel*
>
> NC Cardinal Project Manager
>
> State Library of North Carolina
>
> william.szwag...@ncdcr.gov | 919.814.6721
>
> https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__statelibrary.ncdcr.gov_services-2Dlibraries_nc-2Dcardinal=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=LRHEWfG7tKtoSjGM1XBmJX5tlkBCMt3lnyKxcaVacsw=kjPccD-EhhqnmskWzrp3GLzuWBZxnfCLqsKtt5gujNc5U-uEWr8LMFuzty892oD5=qaTgbSaMM5WJ5Tpq9J4HiytjSLhXS36iM3CB0mUn3Bk=>
>
> 109 East Jones Street  | 4640 Mail Service Center
>
> Raleigh, North Carolina 27699-4600
>
> The State Library is part of the NC Department of Natural & Cultural
> Resources.
>
> *Email correspondence to and from this address is subject to the North
> Carolina Public Records Law and may be disclosed to third parties.*
>
>
> --
>
> *From:* Evergreen-general <
> evergreen-general-boun...@list.evergreen-ils.org> on behalf of Joan
> Kranich via Evergreen-general 
> *Sent:* Wednesday, March 20, 2024 12:43 PM
> *To:* Evergreen Discussion Group  >
> *Cc:* Joan Kranich 
> *Subject:* [External] [Evergreen-general] Paperback vs. Hardcover Records
>
>
>
> *CAUTION:* External email. Do not click links or open attachments unless
> verified. Report suspicious emails with the Report Message button located
> on your Outlook menu bar on the Ho

Re: [Evergreen-general] [External] Paperback vs. Hardcover Records

[Terran McCanna via Evergreen-general]

My apologies, we do *sometimes* - lol - see Tiffany's response for detail :D


On Wed, Mar 20, 2024 at 1:08 PM Joan Kranich  wrote:

> Hi Terran,
>
> Thank you!
>
> We're thinking separate records will need more work to make the record
> specifically for paperback.  We are considering this.
>
> Joan
>
> On Wed, Mar 20, 2024 at 1:01 PM Terran McCanna via Evergreen-general <
> evergreen-general@list.evergreen-ils.org> wrote:
>
>> PINES uses separate records.
>>
>> On Wed, Mar 20, 2024, 12:57 PM Szwagiel, Will via Evergreen-general <
>> evergreen-general@list.evergreen-ils.org> wrote:
>>
>>> Good afternoon Joan,
>>>
>>> Like you, our bibliographic records can contain both paperback and
>>> hardcover versions of a book.  We actually encourage this, as well, as part
>>> of our cataloging best practices to try and cut down on duplicate records
>>> and to make sure that as many items as possible are available for patrons
>>> on a single record.  There will be instances, however, where we suggest
>>> using a separate record, but that is usually based on the content of the
>>> book, not whether it is paperback or hardcover.
>>>
>>> The majority of our member libraries are fine with this, but we do
>>> occasionally receive requests to separate paperbacks and hardcovers,
>>> because some libraries have patrons who only want one or the other.  One
>>> recommendation we have made is for libraries to use call numbers and/or
>>> shelving locations to identify if a specific item is paperback.  For
>>> example, one member library puts "Apb" for "Adult Paperback" at the
>>> beginning of the call numbers for mass market paperback books.
>>>
>>> This may not help patrons as much when placing holds, because they
>>> cannot place item level holds, but it allows staff to easily identify a
>>> paperback version so they can place an item hold for the patron.  Staff
>>> would just have to encourage patrons to come to them to place the hold, so
>>> the staff can place the item level hold for the patron.
>>>
>>> It is admittedly not a perfect solution, but because we have combined
>>> paperbacks and hardcovers on single records for so long, trying to split
>>> them up now would simply be unfeasible.  And even if we began instructing
>>> catalogers to use separate records moving forward, that would still leave
>>> countless existing records in the catalog with both paperbacks and
>>> hardcovers on them.
>>>
>>> *William C. Szwagiel*
>>>
>>> NC Cardinal Project Manager
>>>
>>> State Library of North Carolina
>>>
>>> william.szwag...@ncdcr.gov | 919.814.6721
>>>
>>> https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal
>>>
>>> 109 East Jones Street  | 4640 Mail Service Center
>>>
>>> Raleigh, North Carolina 27699-4600
>>>
>>> The State Library is part of the NC Department of Natural & Cultural
>>> Resources.
>>>
>>> *Email correspondence to and from this address is subject to the North
>>> Carolina Public Records Law and may be disclosed to third parties.*
>>>
>>>
>>> --
>>> *From:* Evergreen-general <
>>> evergreen-general-boun...@list.evergreen-ils.org> on behalf of Joan
>>> Kranich via Evergreen-general 
>>> *Sent:* Wednesday, March 20, 2024 12:43 PM
>>> *To:* Evergreen Discussion Group <
>>> evergreen-general@list.evergreen-ils.org>
>>> *Cc:* Joan Kranich 
>>> *Subject:* [External] [Evergreen-general] Paperback vs. Hardcover
>>> Records
>>>
>>> CAUTION: External email. Do not click links or open attachments unless
>>> verified. Report suspicious emails with the Report Message button located
>>> on your Outlook menu bar on the Home tab.
>>>
>>> Hi,
>>>
>>> In C/W MARS a bibliographic record may contain items for paperback and
>>> for hardcover.  We have had some recommendations to separate paperback
>>> items from hardcover items.
>>>
>>> This is a change on the cataloging side but also with how holds would be
>>> filled.
>>>
>>> Do any of you use separate bibliographic records for paperback vs.
>>> hardcover or do you have another workflow to make it easy for staff and
>>> patrons to place holds to be filled by one format vs. the other?
>>>
>>> Thank you.
>>&g

Re: [Evergreen-general] [External] Paperback vs. Hardcover Records

[Tiffany Little via Evergreen-general]

PINES uses the same record if everything else about the item is the same
aside from the binding.

https://pines.georgialibraries.org/dokuwiki/doku.php?id=cat:matching_criteria#special_cases


[image: logo with link to Georgia Public Library Service website]
<https://georgialibraries.org/>

Tiffany Little

*PINES Bibliographic Projects Manager*

--

Georgia Public Library Service

2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341

(404) 235-7161 | tlit...@georgialibraries.org

[image: logo with link to Georgia Public Library Service Facebook page]
<https://www.facebook.com/georgialibraries>[image: logo with link to
Georgia Public Library Service Instagram page]
<https://www.instagram.com/georgialibraries/>[image: logo with link to
Georgia Public Library Service LinkedIn page]
<https://www.linkedin.com/company/georgia-public-library-service/>[image:
logo with link to Georgia Public Library Service Threads page]
<https://www.threads.net/@georgialibraries>

Join our email list <http://georgialibraries.org/subscription> for stories
of Georgia libraries making an impact in our communities.


On Wed, Mar 20, 2024 at 1:06 PM Frasur, Ruth via Evergreen-general <
evergreen-general@list.evergreen-ils.org> wrote:

> Evergreen Indiana uses separate records if the paperback and hardcover are
> dramatically different in terms of pagination/additional contents.  We use
> the same record is the main difference is just the cover type.
>
>
>
> Ruth Frasur Davis (she/they)
>
> Coordinator
>
> *Evergreen Indiana Library Consortium*
>
> *Evergreen Community Development Initiative*
>
> Indiana State Library
>
> 140 N. Senate Ave.
>
> Indianapolis, IN 46204
>
> (317) 232-3691
>
>
>
> *From:* Evergreen-general <
> evergreen-general-boun...@list.evergreen-ils.org> *On Behalf Of *Terran
> McCanna via Evergreen-general
> *Sent:* Wednesday, March 20, 2024 1:01 PM
> *To:* Evergreen Discussion Group  >
> *Cc:* Terran McCanna 
> *Subject:* Re: [Evergreen-general] [External] Paperback vs. Hardcover
> Records
>
>
>
>  This is an EXTERNAL email. Exercise caution. DO NOT open attachments
> or click links from unknown senders or unexpected email. 
> --
>
> PINES uses separate records.
>
>
>
> On Wed, Mar 20, 2024, 12:57 PM Szwagiel, Will via Evergreen-general <
> evergreen-general@list.evergreen-ils.org> wrote:
>
> Good afternoon Joan,
>
>
>
> Like you, our bibliographic records can contain both paperback and
> hardcover versions of a book.  We actually encourage this, as well, as part
> of our cataloging best practices to try and cut down on duplicate records
> and to make sure that as many items as possible are available for patrons
> on a single record.  There will be instances, however, where we suggest
> using a separate record, but that is usually based on the content of the
> book, not whether it is paperback or hardcover.
>
>
>
> The majority of our member libraries are fine with this, but we do
> occasionally receive requests to separate paperbacks and hardcovers,
> because some libraries have patrons who only want one or the other.  One
> recommendation we have made is for libraries to use call numbers and/or
> shelving locations to identify if a specific item is paperback.  For
> example, one member library puts "Apb" for "Adult Paperback" at the
> beginning of the call numbers for mass market paperback books.
>
>
>
> This may not help patrons as much when placing holds, because they cannot
> place item level holds, but it allows staff to easily identify a paperback
> version so they can place an item hold for the patron.  Staff would just
> have to encourage patrons to come to them to place the hold, so the staff
> can place the item level hold for the patron.
>
>
>
> It is admittedly not a perfect solution, but because we have combined
> paperbacks and hardcovers on single records for so long, trying to split
> them up now would simply be unfeasible.  And even if we began instructing
> catalogers to use separate records moving forward, that would still leave
> countless existing records in the catalog with both paperbacks and
> hardcovers on them.
>
>
>
> *William C. Szwagiel*
>
> NC Cardinal Project Manager
>
> State Library of North Carolina
>
> william.szwag...@ncdcr.gov | 919.814.6721
>
> https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal
> <https://protect2.fireeye.com/v1/url?k=31323334-50bba2bf-31367a34-4544474f5631-520c1bf1f7f8cf41=1=5881d0dc-6a85-4edc-924a-94fcf42fb0c0=https%3A%2F%2Fstatelibrary.ncdcr.gov%2Fservices-libraries%2Fnc-cardinal>
>
> 109 East Jones Street  | 464

Re: [Evergreen-general] Paperback vs. Hardcover Records

[Lindsay Stratton via Evergreen-general]

We also combine different editions and formats like paperback and hardcover
on bib records, to reduce "duplicate" records and to make title holds
simpler, and also get regular requests to separate paperbacks.

However, we are also now using Aspen discovery which groups formats by
default, and the different formats/editions are much easier to
differentiate than in other public catalogs.

I'm beginning to wonder if separating formats/editions is a better approach
now that we have better tools for display.

Lindsay

*Lindsay Stratton*
*Systems Librarian*
Westchester Library System
570 Taxter Rd., 4th Floor
Elmsford, NY 10523
lstrat...@wlsmail.org


On Wed, Mar 20, 2024 at 12:43 PM Joan Kranich via Evergreen-general <
evergreen-general@list.evergreen-ils.org> wrote:

> Hi,
>
> In C/W MARS a bibliographic record may contain items for paperback and for
> hardcover.  We have had some recommendations to separate paperback items
> from hardcover items.
>
> This is a change on the cataloging side but also with how holds would be
> filled.
>
> Do any of you use separate bibliographic records for paperback vs.
> hardcover or do you have another workflow to make it easy for staff and
> patrons to place holds to be filled by one format vs. the other?
>
> Thank you.
>
> Joan
>
> --
>
> Joan Kranich (she/her/hers)
> Library Applications Manager, C/W MARS, Inc.
>
> --
>
> [image: icon] jkran...@cwmars.org | [image: icon]www.cwmars.org
>
> [image: icon] 508-755-3323 x 1
> ___
> Evergreen-general mailing list
> Evergreen-general@list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Evergreen-general] [External] Paperback vs. Hardcover Records

[Joan Kranich via Evergreen-general]

Hi Terran,

Thank you!

We're thinking separate records will need more work to make the record
specifically for paperback.  We are considering this.

Joan

On Wed, Mar 20, 2024 at 1:01 PM Terran McCanna via Evergreen-general <
evergreen-general@list.evergreen-ils.org> wrote:

> PINES uses separate records.
>
> On Wed, Mar 20, 2024, 12:57 PM Szwagiel, Will via Evergreen-general <
> evergreen-general@list.evergreen-ils.org> wrote:
>
>> Good afternoon Joan,
>>
>> Like you, our bibliographic records can contain both paperback and
>> hardcover versions of a book.  We actually encourage this, as well, as part
>> of our cataloging best practices to try and cut down on duplicate records
>> and to make sure that as many items as possible are available for patrons
>> on a single record.  There will be instances, however, where we suggest
>> using a separate record, but that is usually based on the content of the
>> book, not whether it is paperback or hardcover.
>>
>> The majority of our member libraries are fine with this, but we do
>> occasionally receive requests to separate paperbacks and hardcovers,
>> because some libraries have patrons who only want one or the other.  One
>> recommendation we have made is for libraries to use call numbers and/or
>> shelving locations to identify if a specific item is paperback.  For
>> example, one member library puts "Apb" for "Adult Paperback" at the
>> beginning of the call numbers for mass market paperback books.
>>
>> This may not help patrons as much when placing holds, because they cannot
>> place item level holds, but it allows staff to easily identify a paperback
>> version so they can place an item hold for the patron.  Staff would just
>> have to encourage patrons to come to them to place the hold, so the staff
>> can place the item level hold for the patron.
>>
>> It is admittedly not a perfect solution, but because we have combined
>> paperbacks and hardcovers on single records for so long, trying to split
>> them up now would simply be unfeasible.  And even if we began instructing
>> catalogers to use separate records moving forward, that would still leave
>> countless existing records in the catalog with both paperbacks and
>> hardcovers on them.
>>
>> *William C. Szwagiel*
>>
>> NC Cardinal Project Manager
>>
>> State Library of North Carolina
>>
>> william.szwag...@ncdcr.gov | 919.814.6721
>>
>> https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal
>>
>> 109 East Jones Street  | 4640 Mail Service Center
>>
>> Raleigh, North Carolina 27699-4600
>>
>> The State Library is part of the NC Department of Natural & Cultural
>> Resources.
>>
>> *Email correspondence to and from this address is subject to the North
>> Carolina Public Records Law and may be disclosed to third parties.*
>>
>>
>> --
>> *From:* Evergreen-general <
>> evergreen-general-boun...@list.evergreen-ils.org> on behalf of Joan
>> Kranich via Evergreen-general 
>> *Sent:* Wednesday, March 20, 2024 12:43 PM
>> *To:* Evergreen Discussion Group <
>> evergreen-general@list.evergreen-ils.org>
>> *Cc:* Joan Kranich 
>> *Subject:* [External] [Evergreen-general] Paperback vs. Hardcover Records
>>
>> CAUTION: External email. Do not click links or open attachments unless
>> verified. Report suspicious emails with the Report Message button located
>> on your Outlook menu bar on the Home tab.
>>
>> Hi,
>>
>> In C/W MARS a bibliographic record may contain items for paperback and
>> for hardcover.  We have had some recommendations to separate paperback
>> items from hardcover items.
>>
>> This is a change on the cataloging side but also with how holds would be
>> filled.
>>
>> Do any of you use separate bibliographic records for paperback vs.
>> hardcover or do you have another workflow to make it easy for staff and
>> patrons to place holds to be filled by one format vs. the other?
>>
>> Thank you.
>>
>> Joan
>>
>> --
>>
>> Joan Kranich (she/her/hers)
>> Library Applications Manager, C/W MARS, Inc.
>>
>> --
>>
>> [image: icon] jkran...@cwmars.org | [image: icon]www.cwmars.org
>>
>> [image: icon] 508-755-3323 x 1
>>
>> --
>>
>> Email correspondence to and from this address may be subject to the North
>> Carolina Public Records Law and may be disclosed to third parties by a

Re: [Evergreen-general] [External] Paperback vs. Hardcover Records

[Kate Coleman via Evergreen-general]

Missouri Evergreen made a change from separate records to allowing both on
one record about 5 years ago. We had many of the same reasonings that Will
outlined, especially duplicate records (or what seem to be duplicated to
the patrons) in the catalog. We did have libraries that felt that it was
still worth separating them, but when it came down to the amount of patrons
to whom it was important versus how much work and clutter it caused, it was
simply not justified anymore.

Our rule is if the *content* is the same, it can be placed together. We
have  +/- 10 page and +/- 3 cm. rulesw. Mass markets are never put on the
same record as hardovers, and of course if there is a different
illustrator, narrator, foreword, etc., they get their own records.




On Wed, Mar 20, 2024 at 12:01 PM Terran McCanna via Evergreen-general <
evergreen-general@list.evergreen-ils.org> wrote:

> PINES uses separate records.
>
> On Wed, Mar 20, 2024, 12:57 PM Szwagiel, Will via Evergreen-general <
> evergreen-general@list.evergreen-ils.org> wrote:
>
>> Good afternoon Joan,
>>
>> Like you, our bibliographic records can contain both paperback and
>> hardcover versions of a book.  We actually encourage this, as well, as part
>> of our cataloging best practices to try and cut down on duplicate records
>> and to make sure that as many items as possible are available for patrons
>> on a single record.  There will be instances, however, where we suggest
>> using a separate record, but that is usually based on the content of the
>> book, not whether it is paperback or hardcover.
>>
>> The majority of our member libraries are fine with this, but we do
>> occasionally receive requests to separate paperbacks and hardcovers,
>> because some libraries have patrons who only want one or the other.  One
>> recommendation we have made is for libraries to use call numbers and/or
>> shelving locations to identify if a specific item is paperback.  For
>> example, one member library puts "Apb" for "Adult Paperback" at the
>> beginning of the call numbers for mass market paperback books.
>>
>> This may not help patrons as much when placing holds, because they cannot
>> place item level holds, but it allows staff to easily identify a paperback
>> version so they can place an item hold for the patron.  Staff would just
>> have to encourage patrons to come to them to place the hold, so the staff
>> can place the item level hold for the patron.
>>
>> It is admittedly not a perfect solution, but because we have combined
>> paperbacks and hardcovers on single records for so long, trying to split
>> them up now would simply be unfeasible.  And even if we began instructing
>> catalogers to use separate records moving forward, that would still leave
>> countless existing records in the catalog with both paperbacks and
>> hardcovers on them.
>>
>> *William C. Szwagiel*
>>
>> NC Cardinal Project Manager
>>
>> State Library of North Carolina
>>
>> william.szwag...@ncdcr.gov | 919.814.6721
>>
>> https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal
>>
>> 109 East Jones Street  | 4640 Mail Service Center
>>
>> Raleigh, North Carolina 27699-4600
>>
>> The State Library is part of the NC Department of Natural & Cultural
>> Resources.
>>
>> *Email correspondence to and from this address is subject to the North
>> Carolina Public Records Law and may be disclosed to third parties.*
>>
>>
>> --
>> *From:* Evergreen-general <
>> evergreen-general-boun...@list.evergreen-ils.org> on behalf of Joan
>> Kranich via Evergreen-general 
>> *Sent:* Wednesday, March 20, 2024 12:43 PM
>> *To:* Evergreen Discussion Group <
>> evergreen-general@list.evergreen-ils.org>
>> *Cc:* Joan Kranich 
>> *Subject:* [External] [Evergreen-general] Paperback vs. Hardcover Records
>>
>> CAUTION: External email. Do not click links or open attachments unless
>> verified. Report suspicious emails with the Report Message button located
>> on your Outlook menu bar on the Home tab.
>>
>> Hi,
>>
>> In C/W MARS a bibliographic record may contain items for paperback and
>> for hardcover.  We have had some recommendations to separate paperback
>> items from hardcover items.
>>
>> This is a change on the cataloging side but also with how holds would be
>> filled.
>>
>> Do any of you use separate bibliographic records for paperback vs.
>> hardcover or do you have another workflow to make it easy for staff and
>> patrons to place 

Re: [Evergreen-general] Paperback vs. Hardcover Records

[Millissa Macomber via Evergreen-general]

We have a mix of separate records and single records. We use Aspen though
and if they are in separate records in Evergreen (and they group
correctly), Aspen shows the different editions to patrons who then can
place a hold for a specific copy.

-
Millissa


On Wed, Mar 20, 2024 at 9:43 AM Joan Kranich via Evergreen-general <
evergreen-general@list.evergreen-ils.org> wrote:

> Hi,
>
> In C/W MARS a bibliographic record may contain items for paperback and for
> hardcover.  We have had some recommendations to separate paperback items
> from hardcover items.
>
> This is a change on the cataloging side but also with how holds would be
> filled.
>
> Do any of you use separate bibliographic records for paperback vs.
> hardcover or do you have another workflow to make it easy for staff and
> patrons to place holds to be filled by one format vs. the other?
>
> Thank you.
>
> Joan
>
> --
>
> Joan Kranich (she/her/hers)
> Library Applications Manager, C/W MARS, Inc.
>
> --
>
> [image: icon] jkran...@cwmars.org | [image: icon]www.cwmars.org
>
> [image: icon] 508-755-3323 x 1
> _______
> Evergreen-general mailing list
> Evergreen-general@list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Evergreen-general] [External] Paperback vs. Hardcover Records

[Frasur, Ruth via Evergreen-general]

Evergreen Indiana uses separate records if the paperback and hardcover are 
dramatically different in terms of pagination/additional contents.  We use the 
same record is the main difference is just the cover type.

Ruth Frasur Davis (she/they)
Coordinator
Evergreen Indiana Library Consortium
Evergreen Community Development Initiative
Indiana State Library
140 N. Senate Ave.
Indianapolis, IN 46204
(317) 232-3691

From: Evergreen-general  On 
Behalf Of Terran McCanna via Evergreen-general
Sent: Wednesday, March 20, 2024 1:01 PM
To: Evergreen Discussion Group 
Cc: Terran McCanna 
Subject: Re: [Evergreen-general] [External] Paperback vs. Hardcover Records

 This is an EXTERNAL email. Exercise caution. DO NOT open attachments or 
click links from unknown senders or unexpected email. 

PINES uses separate records.

On Wed, Mar 20, 2024, 12:57 PM Szwagiel, Will via Evergreen-general 
mailto:evergreen-general@list.evergreen-ils.org>>
 wrote:
Good afternoon Joan,

Like you, our bibliographic records can contain both paperback and hardcover 
versions of a book.  We actually encourage this, as well, as part of our 
cataloging best practices to try and cut down on duplicate records and to make 
sure that as many items as possible are available for patrons on a single 
record.  There will be instances, however, where we suggest using a separate 
record, but that is usually based on the content of the book, not whether it is 
paperback or hardcover.

The majority of our member libraries are fine with this, but we do occasionally 
receive requests to separate paperbacks and hardcovers, because some libraries 
have patrons who only want one or the other.  One recommendation we have made 
is for libraries to use call numbers and/or shelving locations to identify if a 
specific item is paperback.  For example, one member library puts "Apb" for 
"Adult Paperback" at the beginning of the call numbers for mass market 
paperback books.

This may not help patrons as much when placing holds, because they cannot place 
item level holds, but it allows staff to easily identify a paperback version so 
they can place an item hold for the patron.  Staff would just have to encourage 
patrons to come to them to place the hold, so the staff can place the item 
level hold for the patron.

It is admittedly not a perfect solution, but because we have combined 
paperbacks and hardcovers on single records for so long, trying to split them 
up now would simply be unfeasible.  And even if we began instructing catalogers 
to use separate records moving forward, that would still leave countless 
existing records in the catalog with both paperbacks and hardcovers on them.


William C. Szwagiel

NC Cardinal Project Manager

State Library of North Carolina

william.szwag...@ncdcr.gov<mailto:william.szwag...@ncdcr.gov> | 919.814.6721

https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal<https://protect2.fireeye.com/v1/url?k=31323334-50bba2bf-31367a34-4544474f5631-520c1bf1f7f8cf41=1=5881d0dc-6a85-4edc-924a-94fcf42fb0c0=https%3A%2F%2Fstatelibrary.ncdcr.gov%2Fservices-libraries%2Fnc-cardinal>

109 East Jones Street  | 4640 Mail Service Center

Raleigh, North Carolina 27699-4600

The State Library is part of the NC Department of Natural & Cultural Resources.

Email correspondence to and from this address is subject to the North Carolina 
Public Records Law and may be disclosed to third parties.



________
From: Evergreen-general 
mailto:evergreen-general-boun...@list.evergreen-ils.org>>
 on behalf of Joan Kranich via Evergreen-general 
mailto:evergreen-general@list.evergreen-ils.org>>
Sent: Wednesday, March 20, 2024 12:43 PM
To: Evergreen Discussion Group 
mailto:evergreen-general@list.evergreen-ils.org>>
Cc: Joan Kranich mailto:jkran...@cwmars.org>>
Subject: [External] [Evergreen-general] Paperback vs. Hardcover Records

CAUTION: External email. Do not click links or open attachments unless 
verified. Report suspicious emails with the Report Message button located on 
your Outlook menu bar on the Home tab.

Hi,

In C/W MARS a bibliographic record may contain items for paperback and for 
hardcover.  We have had some recommendations to separate paperback items from 
hardcover items.

This is a change on the cataloging side but also with how holds would be filled.

Do any of you use separate bibliographic records for paperback vs. hardcover or 
do you have another workflow to make it easy for staff and patrons to place 
holds to be filled by one format vs. the other?

Thank you.

Joan

--

[https://lh7-us.googleusercontent.com/ZQr4WGP3h4koRDsog_XgO4yyjl3zMIYNeK4G5qYIsR56oBs3WwQ2MiQI0sbmeVm6MF-WHyxuibj-CSWnvm4LjbvvnVUEWXurZq8GzoSabV-J1RHScmgeZ6QPw2dC3IIpCswbXFg2XxwuYaSvXwvnzWw]

Joan Kranich (she/her/hers)
Library Applications Manager, C/W MARS, Inc.



[icon]jkran...@cwmars.org<

Re: [Evergreen-general] [External] Paperback vs. Hardcover Records

[Elizabeth Davis via Evergreen-general]

Hello

PaILS uses the same record for hardcover and trade paper editions.  We 
encourage a separate record for mass market paperback.  I’d have to test it but 
would the multi-format hold work for instances where you have records for the 
hardcover and one for the paperback?



[cid:image003.png@01DA7AC7.5A0FDAC0]Elizabeth Davis (she/her), Support & 
Project Management Specialist
Pennsylvania Integrated Library System (PaILS) | SPARK
(717) 256-1627 | 
elizabeth.da...@sparkpa.org<mailto:katherine.dann...@sparkpa.org>
support.sparkpa.org<https://support.sparkpa.org/> | 
supp...@sparkpa.org<mailto:supp...@sparkpa.org>

From: Evergreen-general  On 
Behalf Of Terran McCanna via Evergreen-general
Sent: Wednesday, March 20, 2024 1:01 PM
To: Evergreen Discussion Group 
Cc: Terran McCanna 
Subject: Re: [Evergreen-general] [External] Paperback vs. Hardcover Records

PINES uses separate records.

On Wed, Mar 20, 2024, 12:57 PM Szwagiel, Will via Evergreen-general 
mailto:evergreen-general@list.evergreen-ils.org>>
 wrote:
Good afternoon Joan,

Like you, our bibliographic records can contain both paperback and hardcover 
versions of a book.  We actually encourage this, as well, as part of our 
cataloging best practices to try and cut down on duplicate records and to make 
sure that as many items as possible are available for patrons on a single 
record.  There will be instances, however, where we suggest using a separate 
record, but that is usually based on the content of the book, not whether it is 
paperback or hardcover.

The majority of our member libraries are fine with this, but we do occasionally 
receive requests to separate paperbacks and hardcovers, because some libraries 
have patrons who only want one or the other.  One recommendation we have made 
is for libraries to use call numbers and/or shelving locations to identify if a 
specific item is paperback.  For example, one member library puts "Apb" for 
"Adult Paperback" at the beginning of the call numbers for mass market 
paperback books.

This may not help patrons as much when placing holds, because they cannot place 
item level holds, but it allows staff to easily identify a paperback version so 
they can place an item hold for the patron.  Staff would just have to encourage 
patrons to come to them to place the hold, so the staff can place the item 
level hold for the patron.

It is admittedly not a perfect solution, but because we have combined 
paperbacks and hardcovers on single records for so long, trying to split them 
up now would simply be unfeasible.  And even if we began instructing catalogers 
to use separate records moving forward, that would still leave countless 
existing records in the catalog with both paperbacks and hardcovers on them.


William C. Szwagiel

NC Cardinal Project Manager

State Library of North Carolina

william.szwag...@ncdcr.gov<mailto:william.szwag...@ncdcr.gov> | 919.814.6721

https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal<https://urldefense.proofpoint.com/v2/url?u=https-3A__statelibrary.ncdcr.gov_services-2Dlibraries_nc-2Dcardinal=DwMFaQ=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=LRHEWfG7tKtoSjGM1XBmJX5tlkBCMt3lnyKxcaVacsw=kjPccD-EhhqnmskWzrp3GLzuWBZxnfCLqsKtt5gujNc5U-uEWr8LMFuzty892oD5=qaTgbSaMM5WJ5Tpq9J4HiytjSLhXS36iM3CB0mUn3Bk=>

109 East Jones Street  | 4640 Mail Service Center

Raleigh, North Carolina 27699-4600

The State Library is part of the NC Department of Natural & Cultural Resources.

Email correspondence to and from this address is subject to the North Carolina 
Public Records Law and may be disclosed to third parties.



________
From: Evergreen-general 
mailto:evergreen-general-boun...@list.evergreen-ils.org>>
 on behalf of Joan Kranich via Evergreen-general 
mailto:evergreen-general@list.evergreen-ils.org>>
Sent: Wednesday, March 20, 2024 12:43 PM
To: Evergreen Discussion Group 
mailto:evergreen-general@list.evergreen-ils.org>>
Cc: Joan Kranich mailto:jkran...@cwmars.org>>
Subject: [External] [Evergreen-general] Paperback vs. Hardcover Records

CAUTION: External email. Do not click links or open attachments unless 
verified. Report suspicious emails with the Report Message button located on 
your Outlook menu bar on the Home tab.

Hi,

In C/W MARS a bibliographic record may contain items for paperback and for 
hardcover.  We have had some recommendations to separate paperback items from 
hardcover items.

This is a change on the cataloging side but also with how holds would be filled.

Do any of you use separate bibliographic records for paperback vs. hardcover or 
do you have another workflow to make it easy for staff and patrons to place 
holds to be filled by one format vs. the other?

Thank you.

Joan

--

[https://lh7-us.googleusercontent.com/ZQr4WGP3h4koRDsog_XgO4yyjl3zMIYNeK4G5qYIsR56oBs3WwQ2MiQI0sbmeVm6MF-WHyxuibj-CSWnvm4LjbvvnVUEWXurZq8GzoSabV-J1RHScmgeZ6QPw2dC3II

Re: [Evergreen-general] [External] Paperback vs. Hardcover Records

[Joan Kranich via Evergreen-general]

Hi Will,

Thank you for your suggestions and very helpful details!

Some of our libraries indicate paperback in the call number.  The shelving
location is an interesting thought because we can filter by the location.

Joan

On Wed, Mar 20, 2024 at 12:57 PM Szwagiel, Will <
william.szwag...@dncr.nc.gov> wrote:

> Good afternoon Joan,
>
> Like you, our bibliographic records can contain both paperback and
> hardcover versions of a book.  We actually encourage this, as well, as part
> of our cataloging best practices to try and cut down on duplicate records
> and to make sure that as many items as possible are available for patrons
> on a single record.  There will be instances, however, where we suggest
> using a separate record, but that is usually based on the content of the
> book, not whether it is paperback or hardcover.
>
> The majority of our member libraries are fine with this, but we do
> occasionally receive requests to separate paperbacks and hardcovers,
> because some libraries have patrons who only want one or the other.  One
> recommendation we have made is for libraries to use call numbers and/or
> shelving locations to identify if a specific item is paperback.  For
> example, one member library puts "Apb" for "Adult Paperback" at the
> beginning of the call numbers for mass market paperback books.
>
> This may not help patrons as much when placing holds, because they cannot
> place item level holds, but it allows staff to easily identify a paperback
> version so they can place an item hold for the patron.  Staff would just
> have to encourage patrons to come to them to place the hold, so the staff
> can place the item level hold for the patron.
>
> It is admittedly not a perfect solution, but because we have combined
> paperbacks and hardcovers on single records for so long, trying to split
> them up now would simply be unfeasible.  And even if we began instructing
> catalogers to use separate records moving forward, that would still leave
> countless existing records in the catalog with both paperbacks and
> hardcovers on them.
>
> *William C. Szwagiel*
>
> NC Cardinal Project Manager
>
> State Library of North Carolina
>
> william.szwag...@ncdcr.gov | 919.814.6721
>
> https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal
>
> 109 East Jones Street  | 4640 Mail Service Center
>
> Raleigh, North Carolina 27699-4600
>
> The State Library is part of the NC Department of Natural & Cultural
> Resources.
>
> *Email correspondence to and from this address is subject to the North
> Carolina Public Records Law and may be disclosed to third parties.*
>
>
> --
> *From:* Evergreen-general <
> evergreen-general-boun...@list.evergreen-ils.org> on behalf of Joan
> Kranich via Evergreen-general 
> *Sent:* Wednesday, March 20, 2024 12:43 PM
> *To:* Evergreen Discussion Group  >
> *Cc:* Joan Kranich 
> *Subject:* [External] [Evergreen-general] Paperback vs. Hardcover Records
>
> CAUTION: External email. Do not click links or open attachments unless
> verified. Report suspicious emails with the Report Message button located
> on your Outlook menu bar on the Home tab.
>
> Hi,
>
> In C/W MARS a bibliographic record may contain items for paperback and for
> hardcover.  We have had some recommendations to separate paperback items
> from hardcover items.
>
> This is a change on the cataloging side but also with how holds would be
> filled.
>
> Do any of you use separate bibliographic records for paperback vs.
> hardcover or do you have another workflow to make it easy for staff and
> patrons to place holds to be filled by one format vs. the other?
>
> Thank you.
>
> Joan
>
> --
>
> Joan Kranich (she/her/hers)
> Library Applications Manager, C/W MARS, Inc.
>
> --
>
> [image: icon] jkran...@cwmars.org | [image: icon]www.cwmars.org
>
> [image: icon] 508-755-3323 x 1
>
> --
>
> Email correspondence to and from this address may be subject to the North
> Carolina Public Records Law and may be disclosed to third parties by an
> authorized state official.
>


-- 

Joan Kranich (she/her/hers)
Library Applications Manager, C/W MARS, Inc.

--

[image: icon] jkran...@cwmars.org | [image: icon]www.cwmars.org

[image: icon] 508-755-3323 x 1
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Evergreen-general] [External] Paperback vs. Hardcover Records

[Terran McCanna via Evergreen-general]

PINES uses separate records.

On Wed, Mar 20, 2024, 12:57 PM Szwagiel, Will via Evergreen-general <
evergreen-general@list.evergreen-ils.org> wrote:

> Good afternoon Joan,
>
> Like you, our bibliographic records can contain both paperback and
> hardcover versions of a book.  We actually encourage this, as well, as part
> of our cataloging best practices to try and cut down on duplicate records
> and to make sure that as many items as possible are available for patrons
> on a single record.  There will be instances, however, where we suggest
> using a separate record, but that is usually based on the content of the
> book, not whether it is paperback or hardcover.
>
> The majority of our member libraries are fine with this, but we do
> occasionally receive requests to separate paperbacks and hardcovers,
> because some libraries have patrons who only want one or the other.  One
> recommendation we have made is for libraries to use call numbers and/or
> shelving locations to identify if a specific item is paperback.  For
> example, one member library puts "Apb" for "Adult Paperback" at the
> beginning of the call numbers for mass market paperback books.
>
> This may not help patrons as much when placing holds, because they cannot
> place item level holds, but it allows staff to easily identify a paperback
> version so they can place an item hold for the patron.  Staff would just
> have to encourage patrons to come to them to place the hold, so the staff
> can place the item level hold for the patron.
>
> It is admittedly not a perfect solution, but because we have combined
> paperbacks and hardcovers on single records for so long, trying to split
> them up now would simply be unfeasible.  And even if we began instructing
> catalogers to use separate records moving forward, that would still leave
> countless existing records in the catalog with both paperbacks and
> hardcovers on them.
>
> *William C. Szwagiel*
>
> NC Cardinal Project Manager
>
> State Library of North Carolina
>
> william.szwag...@ncdcr.gov | 919.814.6721
>
> https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal
>
> 109 East Jones Street  | 4640 Mail Service Center
>
> Raleigh, North Carolina 27699-4600
>
> The State Library is part of the NC Department of Natural & Cultural
> Resources.
>
> *Email correspondence to and from this address is subject to the North
> Carolina Public Records Law and may be disclosed to third parties.*
>
>
> --
> *From:* Evergreen-general <
> evergreen-general-boun...@list.evergreen-ils.org> on behalf of Joan
> Kranich via Evergreen-general 
> *Sent:* Wednesday, March 20, 2024 12:43 PM
> *To:* Evergreen Discussion Group  >
> *Cc:* Joan Kranich 
> *Subject:* [External] [Evergreen-general] Paperback vs. Hardcover Records
>
> CAUTION: External email. Do not click links or open attachments unless
> verified. Report suspicious emails with the Report Message button located
> on your Outlook menu bar on the Home tab.
>
> Hi,
>
> In C/W MARS a bibliographic record may contain items for paperback and for
> hardcover.  We have had some recommendations to separate paperback items
> from hardcover items.
>
> This is a change on the cataloging side but also with how holds would be
> filled.
>
> Do any of you use separate bibliographic records for paperback vs.
> hardcover or do you have another workflow to make it easy for staff and
> patrons to place holds to be filled by one format vs. the other?
>
> Thank you.
>
> Joan
>
> --
>
> Joan Kranich (she/her/hers)
> Library Applications Manager, C/W MARS, Inc.
>
> --
>
> [image: icon] jkran...@cwmars.org | [image: icon]www.cwmars.org
>
> [image: icon] 508-755-3323 x 1
>
> --
>
> Email correspondence to and from this address may be subject to the North
> Carolina Public Records Law and may be disclosed to third parties by an
> authorized state official.
> ___
> Evergreen-general mailing list
> Evergreen-general@list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Evergreen-general] [External] Paperback vs. Hardcover Records

[Szwagiel, Will via Evergreen-general]

Good afternoon Joan,

Like you, our bibliographic records can contain both paperback and hardcover 
versions of a book.  We actually encourage this, as well, as part of our 
cataloging best practices to try and cut down on duplicate records and to make 
sure that as many items as possible are available for patrons on a single 
record.  There will be instances, however, where we suggest using a separate 
record, but that is usually based on the content of the book, not whether it is 
paperback or hardcover.

The majority of our member libraries are fine with this, but we do occasionally 
receive requests to separate paperbacks and hardcovers, because some libraries 
have patrons who only want one or the other.  One recommendation we have made 
is for libraries to use call numbers and/or shelving locations to identify if a 
specific item is paperback.  For example, one member library puts "Apb" for 
"Adult Paperback" at the beginning of the call numbers for mass market 
paperback books.

This may not help patrons as much when placing holds, because they cannot place 
item level holds, but it allows staff to easily identify a paperback version so 
they can place an item hold for the patron.  Staff would just have to encourage 
patrons to come to them to place the hold, so the staff can place the item 
level hold for the patron.

It is admittedly not a perfect solution, but because we have combined 
paperbacks and hardcovers on single records for so long, trying to split them 
up now would simply be unfeasible.  And even if we began instructing catalogers 
to use separate records moving forward, that would still leave countless 
existing records in the catalog with both paperbacks and hardcovers on them.


William C. Szwagiel

NC Cardinal Project Manager

State Library of North Carolina

william.szwag...@ncdcr.gov<mailto:william.szwag...@ncdcr.gov> | 919.814.6721

https://statelibrary.ncdcr.gov/services-libraries/nc-cardinal

109 East Jones Street  | 4640 Mail Service Center

Raleigh, North Carolina 27699-4600

The State Library is part of the NC Department of Natural & Cultural Resources.

Email correspondence to and from this address is subject to the North Carolina 
Public Records Law and may be disclosed to third parties.



________
From: Evergreen-general  on 
behalf of Joan Kranich via Evergreen-general 

Sent: Wednesday, March 20, 2024 12:43 PM
To: Evergreen Discussion Group 
Cc: Joan Kranich 
Subject: [External] [Evergreen-general] Paperback vs. Hardcover Records

CAUTION: External email. Do not click links or open attachments unless 
verified. Report suspicious emails with the Report Message button located on 
your Outlook menu bar on the Home tab.

Hi,

In C/W MARS a bibliographic record may contain items for paperback and for 
hardcover.  We have had some recommendations to separate paperback items from 
hardcover items.

This is a change on the cataloging side but also with how holds would be filled.

Do any of you use separate bibliographic records for paperback vs. hardcover or 
do you have another workflow to make it easy for staff and patrons to place 
holds to be filled by one format vs. the other?

Thank you.

Joan

--

[https://lh7-us.googleusercontent.com/ZQr4WGP3h4koRDsog_XgO4yyjl3zMIYNeK4G5qYIsR56oBs3WwQ2MiQI0sbmeVm6MF-WHyxuibj-CSWnvm4LjbvvnVUEWXurZq8GzoSabV-J1RHScmgeZ6QPw2dC3IIpCswbXFg2XxwuYaSvXwvnzWw]

Joan Kranich (she/her/hers)
Library Applications Manager, C/W MARS, Inc.



[icon] jkran...@cwmars.org<mailto:jkran...@cwmars.org> | [icon] 
www.cwmars.org<https://www.cwmars.org/>

[icon] 508-755-3323 x 1



Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

[Evergreen-general] Paperback vs. Hardcover Records

[Joan Kranich via Evergreen-general]

Hi,

In C/W MARS a bibliographic record may contain items for paperback and for
hardcover.  We have had some recommendations to separate paperback items
from hardcover items.

This is a change on the cataloging side but also with how holds would be
filled.

Do any of you use separate bibliographic records for paperback vs.
hardcover or do you have another workflow to make it easy for staff and
patrons to place holds to be filled by one format vs. the other?

Thank you.

Joan

-- 

Joan Kranich (she/her/hers)
Library Applications Manager, C/W MARS, Inc.

--

[image: icon] jkran...@cwmars.org | [image: icon]www.cwmars.org

[image: icon] 508-755-3323 x 1
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Evergreen-general] Bug Squashing Week Starts Now!

[Linda Jansová via Evergreen-general]

Thank you very much, Blake!

Linda

On 3/20/24 15:50, Blake Graham-Henderson via Evergreen-general wrote:

Linda,

The Czech language is now available in the OPAC. Sorry I missed that!
-Blake-
Conducting Magic
Will consume any data format
MOBIUS

On 3/19/2024 12:15 PM, Linda Jansová via Evergreen-general wrote:

Hi Blake,

Thank you very much!

I have just found out that you have switched on some other languages 
(including Czech) in the staff client which is great :-)!


I was just wondering - do you think you could also add those other 
languages to the OPAC?


It is always useful to be able to check on things in both places :-)...

Linda

On 3/19/24 17:43, Blake Graham-Henderson via Evergreen-general wrote:

All,

I just finished a second server for testing. Those of you that may 
have looked at the spreadsheet before now may not realize there's a 
new set of bugs to test on bugsquash2!


Many of the included bugs require some server-side config changes. 
For SIP/auth proxy. I'm happy to make changes to the config as 
needed. Please contact me separately to work out the details. 
(bugsquash1 also has several bugs installed that still need testing)


A nod to Bill Erickson for his work on Redis. I've included that 
infrastructure on both bugsquash.mobiusconsortium.org and 
bugsquash2.mobiusconsortium.org. As a little extra credit, they are 
also running PostgreSQL 15.


These are included on bugsquash2:

Typo in Library Setting Description for "How to set default owning 
library for auto-created line item items" 
<https://bugs.launchpad.net/evergreen/+bug/2028095>https://bugs.launchpad.net/evergreen/+bug/2028095 
<https://bugs.launchpad.net/evergreen/+bug/2028095>
Default Phone Number and SMS Number example and regex 
<https://bugs.launchpad.net/evergreen/+bug/2035396>https://bugs.launchpad.net/evergreen/+bug/2035396 
<https://bugs.launchpad.net/evergreen/+bug/2035396>
Stripe Payment Intents and Duplicate Charges 
<https://bugs.launchpad.net/evergreen/+bug/2057948>https://bugs.launchpad.net/evergreen/+bug/2057948 
<https://bugs.launchpad.net/evergreen/+bug/2057948>
Some field labels in angularized Acquisition interface are not shown 
translated 
<https://bugs.launchpad.net/evergreen/+bug/1968087>https://bugs.launchpad.net/evergreen/+bug/1968087 
<https://bugs.launchpad.net/evergreen/+bug/1968087>
Dynamic staff portal doesn't work well in non-English languages 
<https://bugs.launchpad.net/evergreen/+bug/2037426>https://bugs.launchpad.net/evergreen/+bug/2037426 
<https://bugs.launchpad.net/evergreen/+bug/2037426>
add STRING_AGG transform to reporter 
<https://bugs.launchpad.net/evergreen/+bug/2020914>https://bugs.launchpad.net/evergreen/+bug/2020914 
<https://bugs.launchpad.net/evergreen/+bug/2020914>
Possible to bypass holds placement limits via direct API calls 
<https://bugs.launchpad.net/evergreen/+bug/1017990>https://bugs.launchpad.net/evergreen/+bug/1017990 
<https://bugs.launchpad.net/evergreen/+bug/1017990>
SIP patron part level holds respond blank 
<https://bugs.launchpad.net/evergreen/+bug/1525394>https://bugs.launchpad.net/evergreen/+bug/1525394 
<https://bugs.launchpad.net/evergreen/+bug/1525394>
SIP Return Screen Message OK 
<https://bugs.launchpad.net/evergreen/+bug/1613335>https://bugs.launchpad.net/evergreen/+bug/1613335 
<https://bugs.launchpad.net/evergreen/+bug/1613335>
Install directory hardcoded in web client build and tests 
<https://bugs.launchpad.net/evergreen/+bug/1662297>https://bugs.launchpad.net/evergreen/+bug/1662297 
<https://bugs.launchpad.net/evergreen/+bug/1662297>
Long browse entries cause index row size error 
<https://bugs.launchpad.net/evergreen/+bug/1695911>https://bugs.launchpad.net/evergreen/+bug/1695911 
<https://bugs.launchpad.net/evergreen/+bug/1695911>
Remaining chunk/bundle work 
<https://bugs.launchpad.net/evergreen/+bug/1710293>https://bugs.launchpad.net/evergreen/+bug/1710293 
<https://bugs.launchpad.net/evergreen/+bug/1710293>
auth_proxy, native login fails when LDAP unavailable 
<https://bugs.launchpad.net/evergreen/+bug/1715396>https://bugs.launchpad.net/evergreen/+bug/1715396 
<https://bugs.launchpad.net/evergreen/+bug/1715396>
Long-frozen holds skew hold queue position calculation 
<https://bugs.launchpad.net/evergreen/+bug/1744341>https://bugs.launchpad.net/evergreen/+bug/1744341 
<https://bugs.launchpad.net/evergreen/+bug/1744341>
webstaff: EXPAND_WEB_IMPORTS = 0 no longer works 
<https://bugs.launchpad.net/evergreen/+bug/1770212>https://bugs.launchpad.net/evergreen/+bug/1770212 
<https://bugs.launchpad.net/evergreen/+bug/1770212>
Add a support script for importing patrons 
<https://bugs.launchpad.net/evergreen/+bug/1786524>https://bugs.launchpad.net/evergreen/+bug/1786524 
<https://bugs.launchpad.net/evergreen/+bug/1786524>
AuthProxy native login 

Re: [Evergreen-general] Bug Squashing Week Starts Now!

[Blake Graham-Henderson via Evergreen-general]

Linda,

The Czech language is now available in the OPAC. Sorry I missed that!

-Blake-
Conducting Magic
Will consume any data format
MOBIUS

On 3/19/2024 12:15 PM, Linda Jansová via Evergreen-general wrote:

Hi Blake,

Thank you very much!

I have just found out that you have switched on some other languages 
(including Czech) in the staff client which is great :-)!


I was just wondering - do you think you could also add those other 
languages to the OPAC?


It is always useful to be able to check on things in both places :-)...

Linda

On 3/19/24 17:43, Blake Graham-Henderson via Evergreen-general wrote:

All,

I just finished a second server for testing. Those of you that may 
have looked at the spreadsheet before now may not realize there's a 
new set of bugs to test on bugsquash2!


Many of the included bugs require some server-side config changes. 
For SIP/auth proxy. I'm happy to make changes to the config as 
needed. Please contact me separately to work out the details. 
(bugsquash1 also has several bugs installed that still need testing)


A nod to Bill Erickson for his work on Redis. I've included that 
infrastructure on both bugsquash.mobiusconsortium.org and 
bugsquash2.mobiusconsortium.org. As a little extra credit, they are 
also running PostgreSQL 15.


These are included on bugsquash2:

Typo in Library Setting Description for "How to set default owning 
library for auto-created line item items" 
<https://bugs.launchpad.net/evergreen/+bug/2028095>https://bugs.launchpad.net/evergreen/+bug/2028095 
<https://bugs.launchpad.net/evergreen/+bug/2028095>
Default Phone Number and SMS Number example and regex 
<https://bugs.launchpad.net/evergreen/+bug/2035396>https://bugs.launchpad.net/evergreen/+bug/2035396 
<https://bugs.launchpad.net/evergreen/+bug/2035396>
Stripe Payment Intents and Duplicate Charges 
<https://bugs.launchpad.net/evergreen/+bug/2057948>https://bugs.launchpad.net/evergreen/+bug/2057948 
<https://bugs.launchpad.net/evergreen/+bug/2057948>
Some field labels in angularized Acquisition interface are not shown 
translated 
<https://bugs.launchpad.net/evergreen/+bug/1968087>https://bugs.launchpad.net/evergreen/+bug/1968087 
<https://bugs.launchpad.net/evergreen/+bug/1968087>
Dynamic staff portal doesn't work well in non-English languages 
<https://bugs.launchpad.net/evergreen/+bug/2037426>https://bugs.launchpad.net/evergreen/+bug/2037426 
<https://bugs.launchpad.net/evergreen/+bug/2037426>
add STRING_AGG transform to reporter 
<https://bugs.launchpad.net/evergreen/+bug/2020914>https://bugs.launchpad.net/evergreen/+bug/2020914 
<https://bugs.launchpad.net/evergreen/+bug/2020914>
Possible to bypass holds placement limits via direct API calls 
<https://bugs.launchpad.net/evergreen/+bug/1017990>https://bugs.launchpad.net/evergreen/+bug/1017990 
<https://bugs.launchpad.net/evergreen/+bug/1017990>
SIP patron part level holds respond blank 
<https://bugs.launchpad.net/evergreen/+bug/1525394>https://bugs.launchpad.net/evergreen/+bug/1525394 
<https://bugs.launchpad.net/evergreen/+bug/1525394>
SIP Return Screen Message OK 
<https://bugs.launchpad.net/evergreen/+bug/1613335>https://bugs.launchpad.net/evergreen/+bug/1613335 
<https://bugs.launchpad.net/evergreen/+bug/1613335>
Install directory hardcoded in web client build and tests 
<https://bugs.launchpad.net/evergreen/+bug/1662297>https://bugs.launchpad.net/evergreen/+bug/1662297 
<https://bugs.launchpad.net/evergreen/+bug/1662297>
Long browse entries cause index row size error 
<https://bugs.launchpad.net/evergreen/+bug/1695911>https://bugs.launchpad.net/evergreen/+bug/1695911 
<https://bugs.launchpad.net/evergreen/+bug/1695911>
Remaining chunk/bundle work 
<https://bugs.launchpad.net/evergreen/+bug/1710293>https://bugs.launchpad.net/evergreen/+bug/1710293 
<https://bugs.launchpad.net/evergreen/+bug/1710293>
auth_proxy, native login fails when LDAP unavailable 
<https://bugs.launchpad.net/evergreen/+bug/1715396>https://bugs.launchpad.net/evergreen/+bug/1715396 
<https://bugs.launchpad.net/evergreen/+bug/1715396>
Long-frozen holds skew hold queue position calculation 
<https://bugs.launchpad.net/evergreen/+bug/1744341>https://bugs.launchpad.net/evergreen/+bug/1744341 
<https://bugs.launchpad.net/evergreen/+bug/1744341>
webstaff: EXPAND_WEB_IMPORTS = 0 no longer works 
<https://bugs.launchpad.net/evergreen/+bug/1770212>https://bugs.launchpad.net/evergreen/+bug/1770212 
<https://bugs.launchpad.net/evergreen/+bug/1770212>
Add a support script for importing patrons 
<https://bugs.launchpad.net/evergreen/+bug/1786524>https://bugs.launchpad.net/evergreen/+bug/1786524 
<https://bugs.launchpad.net/evergreen/+bug/1786524>
AuthProxy native login fails if username begins with a number 
<https://bugs.launchpad.net/evergreen/+bug/1828456>http

[Evergreen-general] Bug Squashing Week: Mid-Week Update

[Terran McCanna via Evergreen-general]

Hi everyone!

Bug Squashing Week is going strong, thanks to all of you who have already
participated in testing, reporting, tagging, building, and committing!

So far there have been:

   - 15 bug fixes fully tested and signed off
   - 15 committed to core Evergreen.
   - 19 new or updated proposed fixes
   - 5 new bugs reported
   - and 80 testing comments / tags / bug updates added

There are still 37 proposed fixes / features loaded onto test servers that
need to be fully tested out, so if you have a little time this week, please
pick one and put it through its paces!

As always, if you're not sure how to test or provide feedback, feel free to
contact me off list.

Happy Squashing!
Terran


[image: logo with link to Georgia Public Library Service website]
<https://georgialibraries.org/>

Terran McCanna, PINES Program Manager

--

Georgia Public Library Service

2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341

(404) 235-7138 | tmcca...@georgialibraries.org

https://help.georgialibraries.org | h...@georgialibraries.org

[image: logo with link to Georgia Public Library Service Facebook page]
<https://www.facebook.com/georgialibraries>[image: logo with link to
Georgia Public Library Service Instagram page]
<https://www.instagram.com/georgialibraries/>[image: logo with link to
Georgia Public Library Service LinkedIn page]
<https://www.linkedin.com/company/georgia-public-library-service/>[image:
logo with link to Georgia Public Library Service Threads page]
<https://www.threads.net/@georgialibraries>
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: RFE: enable buffering on null-terminated data

[Carl Edquist via GNU coreutils General Discussion]

On Tue, 19 Mar 2024, Zachary Santer wrote:


On Tue, Mar 19, 2024 at 1:24 AM Kaz Kylheku  wrote:


But what tee does is set up _IONBF on its output streams,
including stdout.


So it doesn't buffer at all. Awesome. Nevermind.


Yay!  :D

And since tee uses fwrite to copy whatever input is available, that will 
mean 'records' are output on the same boundaries as the input (whether 
that be newlines, nuls, or just block boundaries).  So putting tee in the 
middle of a pipeline shouldn't itself interfere with whatever else you're 
up to.  (AND it's still relatively efficient, compared to some tools like 
cut that putchar a byte at a time.)


My note about pipelines like this though:

$ ./build.sh | sed s/what/ever/ | tee build.log

is that with the default stdio buffering, while all the commands in 
build.sh will be implicitly self-flushing, the sed in the middle will end 
up batching its output into blocks, so tee will also repeat them in 
blocks.


However, if stdbuf's magic env vars are exported in your shell (either by 
doing a trick like 'export $(env -i stdbuf -oL env)', or else more simply 
by first starting a new shell with 'stdbuf -oL bash'), then every command 
in your pipelines will start with the new default line-buffered stdout. 
That way your line-items from build.sh should get passed all the way 
through the pipeline as they are produced.



(But, proof's in the pudding, so whatever works for you :D )


Happy putting all the way!

Carl

Re: [Evergreen-general] Bug Squashing Week Starts Now!

[Terran McCanna via Evergreen-general]

Thanks, Blake!

On Tue, Mar 19, 2024 at 12:43 PM Blake Graham-Henderson via
Evergreen-general  wrote:

> All,
>
> I just finished a second server for testing. Those of you that may have
> looked at the spreadsheet before now may not realize there's a new set of
> bugs to test on bugsquash2!
>
> Many of the included bugs require some server-side config changes. For
> SIP/auth proxy. I'm happy to make changes to the config as needed. Please
> contact me separately to work out the details. (bugsquash1 also has several
> bugs installed that still need testing)
>
> A nod to Bill Erickson for his work on Redis. I've included that
> infrastructure on both bugsquash.mobiusconsortium.org and
> bugsquash2.mobiusconsortium.org. As a little extra credit, they are also
> running PostgreSQL 15.
>
> These are included on bugsquash2:
>
> Typo in Library Setting Description for "How to set default owning library
> for auto-created line item items"
> <https://bugs.launchpad.net/evergreen/+bug/2028095>
> https://bugs.launchpad.net/evergreen/+bug/2028095
> Default Phone Number and SMS Number example and regex
> <https://bugs.launchpad.net/evergreen/+bug/2035396>
> https://bugs.launchpad.net/evergreen/+bug/2035396
> Stripe Payment Intents and Duplicate Charges
> <https://bugs.launchpad.net/evergreen/+bug/2057948>
> https://bugs.launchpad.net/evergreen/+bug/2057948
> Some field labels in angularized Acquisition interface are not shown
> translated <https://bugs.launchpad.net/evergreen/+bug/1968087>
> https://bugs.launchpad.net/evergreen/+bug/1968087
> Dynamic staff portal doesn't work well in non-English languages
> <https://bugs.launchpad.net/evergreen/+bug/2037426>
> https://bugs.launchpad.net/evergreen/+bug/2037426
> add STRING_AGG transform to reporter
> <https://bugs.launchpad.net/evergreen/+bug/2020914>
> https://bugs.launchpad.net/evergreen/+bug/2020914
> Possible to bypass holds placement limits via direct API calls
> <https://bugs.launchpad.net/evergreen/+bug/1017990>
> https://bugs.launchpad.net/evergreen/+bug/1017990
> SIP patron part level holds respond blank
> <https://bugs.launchpad.net/evergreen/+bug/1525394>
> https://bugs.launchpad.net/evergreen/+bug/1525394
> SIP Return Screen Message OK
> <https://bugs.launchpad.net/evergreen/+bug/1613335>
> https://bugs.launchpad.net/evergreen/+bug/1613335
> Install directory hardcoded in web client build and tests
> <https://bugs.launchpad.net/evergreen/+bug/1662297>
> https://bugs.launchpad.net/evergreen/+bug/1662297
> Long browse entries cause index row size error
> <https://bugs.launchpad.net/evergreen/+bug/1695911>
> https://bugs.launchpad.net/evergreen/+bug/1695911
> Remaining chunk/bundle work
> <https://bugs.launchpad.net/evergreen/+bug/1710293>
> https://bugs.launchpad.net/evergreen/+bug/1710293
> auth_proxy, native login fails when LDAP unavailable
> <https://bugs.launchpad.net/evergreen/+bug/1715396>
> https://bugs.launchpad.net/evergreen/+bug/1715396
> Long-frozen holds skew hold queue position calculation
> <https://bugs.launchpad.net/evergreen/+bug/1744341>
> https://bugs.launchpad.net/evergreen/+bug/1744341
> webstaff: EXPAND_WEB_IMPORTS = 0 no longer works
> <https://bugs.launchpad.net/evergreen/+bug/1770212>
> https://bugs.launchpad.net/evergreen/+bug/1770212
> Add a support script for importing patrons
> <https://bugs.launchpad.net/evergreen/+bug/1786524>
> https://bugs.launchpad.net/evergreen/+bug/1786524
> AuthProxy native login fails if username begins with a number
> <https://bugs.launchpad.net/evergreen/+bug/1828456>
> https://bugs.launchpad.net/evergreen
> <https://bugs.launchpad.net/evergreen/+bug/1828456>
> /+bug/1828456 <https://bugs.launchpad.net/evergreen/+bug/1828456>
> teach SIP driver how to use open-ils.auth_proxy
> <https://bugs.launchpad.net/evergreen/+bug/1526558>
> https://bugs.launchpad.net/evergreen/+bug/1526558
>
> -Blake-
> Conducting Magic
> Will consume any data format
> MOBIUS
> 573-234-4513
> 877-312-3517
>
> On 3/18/2024 8:12 AM, Terran McCanna via Eg-newdevs wrote:
>
> The test servers are freshly loaded with proposed bug fixes and features
> that are ready to test!
>
> List of servers and loaded patches:
>
> https://docs.google.com/spreadsheets/d/1Z_IeLJQ9niiEXnUfftkIAf5YFvNmyfgJ_h4HKq27Kog/edit?usp=sharing
>
> When you test something, please add your testing feedback at the
> associated Launchpad link. More specific instructions, and other things you
> can work on during Bug Squashing Week (like verifying reported bugs) are
> available at: https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing
&g

Re: [Evergreen-general] Bug Squashing Week Starts Now!

[Linda Jansová via Evergreen-general]

Hi Blake,

Thank you very much!

I have just found out that you have switched on some other languages 
(including Czech) in the staff client which is great :-)!


I was just wondering - do you think you could also add those other 
languages to the OPAC?


It is always useful to be able to check on things in both places :-)...

Linda

On 3/19/24 17:43, Blake Graham-Henderson via Evergreen-general wrote:

All,

I just finished a second server for testing. Those of you that may 
have looked at the spreadsheet before now may not realize there's a 
new set of bugs to test on bugsquash2!


Many of the included bugs require some server-side config changes. For 
SIP/auth proxy. I'm happy to make changes to the config as needed. 
Please contact me separately to work out the details. (bugsquash1 also 
has several bugs installed that still need testing)


A nod to Bill Erickson for his work on Redis. I've included that 
infrastructure on both bugsquash.mobiusconsortium.org and 
bugsquash2.mobiusconsortium.org. As a little extra credit, they are 
also running PostgreSQL 15.


These are included on bugsquash2:

Typo in Library Setting Description for "How to set default owning 
library for auto-created line item items" 
<https://bugs.launchpad.net/evergreen/+bug/2028095>https://bugs.launchpad.net/evergreen/+bug/2028095 
<https://bugs.launchpad.net/evergreen/+bug/2028095>
Default Phone Number and SMS Number example and regex 
<https://bugs.launchpad.net/evergreen/+bug/2035396>https://bugs.launchpad.net/evergreen/+bug/2035396 
<https://bugs.launchpad.net/evergreen/+bug/2035396>
Stripe Payment Intents and Duplicate Charges 
<https://bugs.launchpad.net/evergreen/+bug/2057948>https://bugs.launchpad.net/evergreen/+bug/2057948 
<https://bugs.launchpad.net/evergreen/+bug/2057948>
Some field labels in angularized Acquisition interface are not shown 
translated 
<https://bugs.launchpad.net/evergreen/+bug/1968087>https://bugs.launchpad.net/evergreen/+bug/1968087 
<https://bugs.launchpad.net/evergreen/+bug/1968087>
Dynamic staff portal doesn't work well in non-English languages 
<https://bugs.launchpad.net/evergreen/+bug/2037426>https://bugs.launchpad.net/evergreen/+bug/2037426 
<https://bugs.launchpad.net/evergreen/+bug/2037426>
add STRING_AGG transform to reporter 
<https://bugs.launchpad.net/evergreen/+bug/2020914>https://bugs.launchpad.net/evergreen/+bug/2020914 
<https://bugs.launchpad.net/evergreen/+bug/2020914>
Possible to bypass holds placement limits via direct API calls 
<https://bugs.launchpad.net/evergreen/+bug/1017990>https://bugs.launchpad.net/evergreen/+bug/1017990 
<https://bugs.launchpad.net/evergreen/+bug/1017990>
SIP patron part level holds respond blank 
<https://bugs.launchpad.net/evergreen/+bug/1525394>https://bugs.launchpad.net/evergreen/+bug/1525394 
<https://bugs.launchpad.net/evergreen/+bug/1525394>
SIP Return Screen Message OK 
<https://bugs.launchpad.net/evergreen/+bug/1613335>https://bugs.launchpad.net/evergreen/+bug/1613335 
<https://bugs.launchpad.net/evergreen/+bug/1613335>
Install directory hardcoded in web client build and tests 
<https://bugs.launchpad.net/evergreen/+bug/1662297>https://bugs.launchpad.net/evergreen/+bug/1662297 
<https://bugs.launchpad.net/evergreen/+bug/1662297>
Long browse entries cause index row size error 
<https://bugs.launchpad.net/evergreen/+bug/1695911>https://bugs.launchpad.net/evergreen/+bug/1695911 
<https://bugs.launchpad.net/evergreen/+bug/1695911>
Remaining chunk/bundle work 
<https://bugs.launchpad.net/evergreen/+bug/1710293>https://bugs.launchpad.net/evergreen/+bug/1710293 
<https://bugs.launchpad.net/evergreen/+bug/1710293>
auth_proxy, native login fails when LDAP unavailable 
<https://bugs.launchpad.net/evergreen/+bug/1715396>https://bugs.launchpad.net/evergreen/+bug/1715396 
<https://bugs.launchpad.net/evergreen/+bug/1715396>
Long-frozen holds skew hold queue position calculation 
<https://bugs.launchpad.net/evergreen/+bug/1744341>https://bugs.launchpad.net/evergreen/+bug/1744341 
<https://bugs.launchpad.net/evergreen/+bug/1744341>
webstaff: EXPAND_WEB_IMPORTS = 0 no longer works 
<https://bugs.launchpad.net/evergreen/+bug/1770212>https://bugs.launchpad.net/evergreen/+bug/1770212 
<https://bugs.launchpad.net/evergreen/+bug/1770212>
Add a support script for importing patrons 
<https://bugs.launchpad.net/evergreen/+bug/1786524>https://bugs.launchpad.net/evergreen/+bug/1786524 
<https://bugs.launchpad.net/evergreen/+bug/1786524>
AuthProxy native login fails if username begins with a number 
<https://bugs.launchpad.net/evergreen/+bug/1828456>https://bugs.launchpad.net/evergreen 
<https://bugs.launchpad.net/evergreen/+bug/1828456>

/+bug/1828456 <https://bugs.launchpad.net/evergreen/+bug/1828456>
teach SIP driver how to use open-ils.auth_proxy 

Re: [Evergreen-general] Bug Squashing Week Starts Now!

[Blake Graham-Henderson via Evergreen-general]

test!


List of servers and loaded patches:
https://docs.google.com/spreadsheets/d/1Z_IeLJQ9niiEXnUfftkIAf5YFvNmyfgJ_h4HKq27Kog/edit?usp=sharing

When you test something, please add your testing feedback at the 
associated Launchpad link. More specific instructions, and other 
things you can work on during Bug Squashing Week (like verifying 
reported bugs) are available at: 
https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing


Please feel free to email me off-list if you have any questions.

Happy Squashing!


logo with link to Georgia Public Library Service website 
<https://georgialibraries.org/>




Terran McCanna, PINES Program Manager



Georgia Public Library Service

2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341

(404) 235-7138 | tmcca...@georgialibraries.org

https://help.georgialibraries.org | h...@georgialibraries.org




logo with link to Georgia Public Library Service Facebook page 
<https://www.facebook.com/georgialibraries>logo with link to Georgia 
Public Library Service Instagram page 
<https://www.instagram.com/georgialibraries/>logo with link to Georgia 
Public Library Service LinkedIn page 
<https://www.linkedin.com/company/georgia-public-library-service/>logo 
with link to Georgia Public Library Service Threads page 
<https://www.threads.net/@georgialibraries>








___
Eg-newdevs mailing list
eg-newd...@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-newdevs
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

[Evergreen-general] Reminder: Evergreen Cataloging Interest Group - Today

[Jennifer Weston via Evergreen-general]

*Reminder:*

*The Cataloging Interest Group meets today at 2pm (Eastern)*



Meeting agenda: https://bit.ly/3vswD21


*Featured Program: **Bug Squashing Week and Recent Release Updates*



See meeting login details below.



Hope to see you there!



Jennifer



On Tue, Mar 12, 2024 at 9:03 AM Jennifer Weston <
jennifer.wes...@equinoxoli.org> wrote:

> *Cataloging Interest Group RESCHEDULED to next week*
>
> The Evergreen Cataloging Interest Group will *not* meet today. Instead,
> we will meet next week -- *Tuesday, March 19, 2024, at 2pm (ET)*.
>
>
>
> We will have the added benefit of meeting during Bug Squashing Week
> <https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing> next week
> so we can participate in the process together.
>
>
>
> Everyone is welcome – please join us! The meeting will be recorded for any
> interested parties who cannot attend.
>
>
>
> *Evergreen Cataloging Interest Group*
>
> *Tuesday, March 19, 2024*
>
> *2:00pm ET*
>
>
>
> Zoom Meeting Link:
>
> https://us06web.zoom.us/j/89440379465?pwd=TVY4anVHZmN6ZlZQRXVTM3o5eUUyZz09
>
>
>
> Meeting ID: 894 4037 9465
>
> Passcode: 086021
>
> Want to dial into the call using your phone? Find your local number:
> https://us06web.zoom.us/u/kcsI1s3S9P
>
>
>
> *Topic:** Bug Squashing Week and Recent Release Updates*
>
> We’ll look at the list of bugs to be reviewed during bug squashing week
> and pick one or two to test together. We will also look at recent updates
> to 3.11 and 3.12 related to cataloging.
>
>
>
> We hope to see you there!
>
> Jennifer Weston,
>
> on behalf of the Cataloging IG Organizing Committee
>
>
>
> -
>
> The Cataloging Interest Group usually meets on the second Tuesday of each
> month. Everyone is welcome. Meetings are recorded and made available to the
> community. For more information, please visit the Cat IG wiki at:
> https://wiki.evergreen-ils.org/doku.php?id=cataloging:cwg
> -
>
>
> ---
>
> Jennifer Weston, MLIS
>
> Product and Education Manager | Assistant Operations Manager
>
> Equinox Open Library Initiative
>
> *jennifer.wes...@equinoxoli.org *
>
> 1-877-OPEN-ILS (673-6457)
>
> direct: 770-709-5574
>
> *www.equinoxOLI.org <http://www.equinoxOLI.org>*
>
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

RE: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

MK: Even though I think most of you won't absorb what I wrote above, because 
you all "divinely believe" in the current "cube skill theory", I won't consider 
it a total waste of my time even if it sows a seed of doubt in just one mind.

I don’t "divinely believe" in the current cube theory. I understand the maths 
behind it. If you have found errors in the maths, then I would be glad to 
re-evaluate.

Let's find out where you disagree by starting from the beginning. What is your 
analysis of the basic 25% takepoint calculation?

-- Ian 

RE: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

MK: This is why I am doing my various experiments. One of which that I had 
previously mentioned in this very thread involves a "mutant cube strategy" of 
doubling at GWC > 50% and taking at GWC > 0%. In that experiment of 20,000 
money games, the mutant won 40.80% of total points against GnuBG 2-ply. Since 
winning the opening roll gives the player GWC > 50%, I ran a variant of the 
above experiment making the mutant also double if it wins the opening roll. 
This time, after 20,000 money games the mutant won 45.77% of total points.

These sound similar enough that I'll combine them.  Overall, the mutant 
strategy if doubling as soon as you had an advantage lost 0.1343 points per 
game. Always doubling immediately lost 0.36 ppg. So, not doubling until you are 
winning appears to be a better strategy than always doubling. But, as you 
expected, the mutant strategy isn't as good as the current cube algorithm, 
which loses 0 ppg.

However, I don’t think 4 trials is enough. Your strategy has huge variance. 
Have you calculated the statistical significance as suggested by one of the 
earlier responders? I recall that he suggested a similar experiment with lower 
variance to reduce the required number of trials, but you didn't want to try 
it.  I can't find that post at the moment, so I don’t know how many trials he 
calculated, but since your cube can get very high you would inevitably need 
more trials. 

RE: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

MK "Those numbers are based on how the bot would play against itself. If you 
accept the bot's decisions as best/perfect and if you try to play just like 
bot, assuming that your opponent will also try to play just like the bot, of 
course you wouldn't/shouldn't double."

Agreed. Against a worse player, you can take with fewer winning chances. If 
your opponent will give up enough equity in errors to overcome the error of the 
bad take (and your own subsequent errors), then you should still come out ahead.

[Evergreen-general] Bug Squashing Week Starts Now!

[Terran McCanna via Evergreen-general]

The test servers are freshly loaded with proposed bug fixes and features
that are ready to test!

List of servers and loaded patches:
https://docs.google.com/spreadsheets/d/1Z_IeLJQ9niiEXnUfftkIAf5YFvNmyfgJ_h4HKq27Kog/edit?usp=sharing

When you test something, please add your testing feedback at the associated
Launchpad link. More specific instructions, and other things you can work
on during Bug Squashing Week (like verifying reported bugs) are available
at: https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing

Please feel free to email me off-list if you have any questions.

Happy Squashing!


[image: logo with link to Georgia Public Library Service website]
<https://georgialibraries.org/>

Terran McCanna, PINES Program Manager

--

Georgia Public Library Service

2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341

(404) 235-7138 | tmcca...@georgialibraries.org

https://help.georgialibraries.org | h...@georgialibraries.org

[image: logo with link to Georgia Public Library Service Facebook page]
<https://www.facebook.com/georgialibraries>[image: logo with link to
Georgia Public Library Service Instagram page]
<https://www.instagram.com/georgialibraries/>[image: logo with link to
Georgia Public Library Service LinkedIn page]
<https://www.linkedin.com/company/georgia-public-library-service/>[image:
logo with link to Georgia Public Library Service Threads page]
<https://www.threads.net/@georgialibraries>
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Fwd: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

MK,

You wrote "Not the "equity" but the "equity difference" between the "from" 
position and the "to" position."

I can't see any difference in outcome between selecting the play that maximises 
the equity of the move made, and maximising the equity gain between the current 
position and the new position. The latter option just adds an unnecessary 
subtraction step, so I doubt that's how it's programmed.

I agree that the Temp Map you posted is showing the equity with doubles 
allowed. I've put then into a spreadsheet so you can see the calculations. 
https://docs.google.com/spreadsheets/d/17XFvQPvWNqGMRgZScl2qcTW2ovNeCISq/edit?usp=sharing=117015456330598325471=true=true

The equity of 31 after returning to the opening position is +0.219. The equity 
after an opening 31 is also +0.219.  I conclude that there is no problem with 
the equity calculation that would affect how gnubg plays.

The temp map was a later addition to gnubg, so I don't think it's used in the 
luck calculation. Even if the luck calculation is down as per the temperature 
map, and there is an error in the luck calculation of the opening roll, it 
won't permeate through to other rolls. The luck calculation is based on the 
actual roll compared to the other 21 (14 in the opening) possible rolls.

The luck of 31 after returning to the opening position is +0.112. It's a good 
roll but not as good as any double. It's just above the average of +0.107. The 
worst roll is 14 at -0.113.
The luck of an opening 31 is +0.219. It's a great roll, compared to the average 
of 0.000. The worst roll is 14 at -0.219.

You want to make a distinction between the game not started being on roll 
before the move. For example, if you tossed a coin to see who started and then 
the winner rolls any non-double and plays it.
Then winning the opening roll would show a luck of +0.052.
The luck of an opening 31 is +0.167.
This adds to +0.219, the same as above.

This all seems consistent to me.

Your argument about a fallacy appears to be a semantic one. When I say, "the 
equity before the opening roll is zero", I'm aware that the opening roll also 
defines who rolls first, and I'm using it in that context.

If the opening roll were a coin toss, I wouldn’t speak in the same terms. I 
would say, "the equity before the toss is zero" because that's the average 
equity of all 30 possible outcomes (player 1 wind the toss & rolls, player 2 
wins the toss and rolls). I would also say, "the equity having won the toss is 
+0.052 before rolling" because that's the average equity of the remaining 15 
possible outcomes.

Do you agree with the preceding paragraph?

Knowing the absolute equity is only useful for cube actions, and since the 
rules prohibit doubling on the opening roll, it's not very useful to me  to 
make a distinction.

"In fact, I'd argue that with the cube centered, you should be allowed to 
double if you want before you open your eyes but this is a whole different 
subject and for one of the experiments that I have done and will share soon."

I wouldn’t double.  As shown by the rollouts, I'd be giving up 0.36 points per 
game, on average. Even if I knew you would roll 66, I would still take, because 
the equity of -0.276 * 2 is still better than giving up a whole 1.000 point.

A couple of final points.

I'm sure the match equity tables are calculated correctly. The starting player 
of any subsequent game is equally likely, so the equity of each game starts at 
zero.

I did read some of the old rgb threads.  They descended into rudeness and I 
lost interest.

For some reason, your last 2 messages got caught in my spam filter, hence the 
late reply.


Regards,
Ian

-Original Message-
From: MK 
Sent: Wednesday, March 6, 2024 9:35 PM
To: Ian Shaw ; bug-gnubg@gnu.org
Cc: Philippe Michel 
Subject: Re: Interesting question/experiment about value of cube ownership

On 3/4/2024 5:26 AM, Ian Shaw wrote:

Since at least you care to continue this discussion, I will invest more of my 
time and effort mainly for the sake of improving GnuBG.

> Sorry, MK, I didn't read back over the old threads,

It was in my a previous post in this current thread here but it's no big deal. 
However, if you are serious about discussing this issue, which one of many 
related ones, you really need to read at least this thread in RGB (which I had 
mentioned in my last post):

https://groups.google.com/g/rec.games.backgammon/c/QU1jM9aatO0/m/peIBhLJNAgAJ

There is a lot in there, including a bug that I had pointed out in "analysis.c" 
that had been there since 2014, which is still there. See lines 243-246 in 2022 
and 272-275 in current version:

https://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/analysis.c?revision=1.241=markup

https://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/analysis.c?revision=1.263=markup

Too bad that the development/maintenance team isn't hearing me.

> You asked earlier about the GNUBG ID I used. It was:
> 4HPwATDgc/ABMA:cAkA This is the ID obtained after the 

Re: [Evergreen-general] Hack-A-Hosting Proposals for 2024 Now Open

[Rogan Hamby via Evergreen-general]

Good afternoon,

As we head into the weekend, I'm reminding folks of this opportunity to
host the 2024 Hack-A-Way.  We've had a few questions but not proposals yet
so if you're shy please step forward. This is not a large event that
requires a consortia level host, in fact we've been hosted by individual
libraries several times in the past.

What we need:


   - A clean meeting space for 15 - 30 people.
   - Working space for laptops.
   - A TV, projector or other display.
   - Adequate bandwidth for the users.
   - A few snacks and forms of hydration and caffeine to keep blood sugar
   and productivity up.
   - Facilitate reasonable hotel accommodations (cheaper is better but no
   bed bugs).
   - Although not required it's become tradition for the host to supply
   lunches.


On Mon, Feb 19, 2024 at 6:32 PM Rogan Hamby 
wrote:

> We are looking for a host for the annual Hack-A-Way this year in 2024.
> Traditionally we have opened proposals after the conference but we are
> doing it a little early this year.  For those unfamiliar with it, the
> Hack-A-Way is a much smaller event than the conference and a great way for
> an organization to host a community event. The Hack-A-Way focuses on
> providing a means for coders and documentation writers to collaborate in
> person and plan major projects for the upcoming year.
>
> What we need:
>
>
>- A clean meeting space for 15 - 30 people.
>- Working space for laptops.
>- A TV, projector or other display.
>- Adequate bandwidth for the users.
>- A few snacks and forms of hydration and caffeine to keep blood sugar
>and productivity up.
>- Facilitate reasonable hotel accommodations (cheaper is better but no
>bed bugs).
>- Although not required it's become tradition for the host to supply
>lunches.
>
> If your organization is interested please contact me with details of your
> proposal.
>
>
> Rogan Hamby (he/him/his), MLIS
>
> Data and Project Manager
>
> Equinox Open Library Initiative
>
> rogan.ha...@equinoxoli.org
>
> 1-770-709-5570 x5570
>
> www.equinoxOLI.org
>
>
>
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

[Evergreen-general] Reminder: Bug Squashing Week next week!

[Terran McCanna via Evergreen-general]

Hi everyone!

A reminder that the first Bug Squashing Week of next week will start on
Monday and everyone is welcome to participate! Test servers are currently
being built that will have proposed bug fixes and features loaded onto them
and ready for testing. The tracking sheet is in progress but available
here:

https://docs.google.com/spreadsheets/d/1Z_IeLJQ9niiEXnUfftkIAf5YFvNmyfgJ_h4HKq27Kog/edit?usp=sharing

For an overview of different ways you can participate in BSW, even if
you're not a developer, take a look at
https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing

Any time you can contribute to BSW efforts is welcome and much appreciated!

Feel free to email me directly if you have any questions,
Terran


[image: logo with link to Georgia Public Library Service website]
<https://georgialibraries.org/>

Terran McCanna, PINES Program Manager

--

Georgia Public Library Service

2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341

(404) 235-7138 | tmcca...@georgialibraries.org

https://help.georgialibraries.org | h...@georgialibraries.org

[image: logo with link to Georgia Public Library Service Facebook page]
<https://www.facebook.com/georgialibraries>[image: logo with link to
Georgia Public Library Service Instagram page]
<https://www.instagram.com/georgialibraries/>[image: logo with link to
Georgia Public Library Service LinkedIn page]
<https://www.linkedin.com/company/georgia-public-library-service/>[image:
logo with link to Georgia Public Library Service Threads page]
<https://www.threads.net/@georgialibraries>
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Evergreen-general] Stripe Duplicate Charges

[Morgan, Michele via Evergreen-general]

Hi Terran,

I've only read about this recently, but I would imagine that the
combination of data elements you describe would at least take care of
double clicks and connection errors. It would be nice if we could use
something truly unique, like the billable_xact ids, but because users can
select and pay against multiple xacts at the same time, I'm not sure how
that would work.

I will go ahead and open a Launchpad bug to continue the discussion there.

Thanks,
Michele

--
Michele M. Morgan, Systems Support Specialist
North of Boston Library Exchange, Danvers Massachusetts
mmor...@noblenet.org



On Wed, Mar 13, 2024 at 3:37 PM Terran McCanna <
tmcca...@georgialibraries.org> wrote:

> I read about that a while back, but I was under the impression that it
> would only solve double-click types of problems, not problems where the
> patron is actually filling out the form again. Is it just that we'd need to
> design the idempotency key in a way that it generated the same key if the
> scenario was the same? Like a combination of the patron ID and the amount
> and the date or something like that?
>
> On Wed, Mar 13, 2024 at 3:16 PM Morgan, Michele 
> wrote:
>
>> I wanted to share some information from Stripe's support about the
>> duplicate credit card charges issue we have seen since our upgrade to 3.10.
>>
>> Stripe support indicated that making the requests from Evergreen
>> idempotent will prevent retried requests from creating duplicate charges.
>> This would entail including an idempotency key as an element in the payment
>> request sent to Stripe. Here is some documentation from Stripe:
>>
>> https://docs.stripe.com/api/idempotent_requests
>>
>> I will likely open a Launchpad bug about this, but have not heard that
>> others have seen this issue. I would still be interested in hearing if,
>> besides PINES, there are other systems running Evergreen 3.8 or later and
>> using Stripe, and whether or not you have seen any issues.
>>
>> Thanks for any feedback,
>> Michele
>>
>> --
>> Michele M. Morgan, Systems Support Specialist
>> North of Boston Library Exchange, Danvers Massachusetts
>> mmor...@noblenet.org
>>
>>
>>
>> On Wed, Feb 28, 2024 at 9:42 AM Morgan, Michele 
>> wrote:
>>
>>> Thanks Terran!
>>>
>>> We've seen that negative bill issue once since our upgrade, and we're
>>> double checking that our tt2 files have the correct code.
>>>
>>> We have also seen issues where the payment looks fine on the Evergreen
>>> side, but on the Stripe side we see that more than one successful charge
>>> was made for the same Evergreen bill. These patrons have *not* had any
>>> negative bills.
>>>
>>> Has anyone else seen similar behavior?
>>>
>>> Thanks,
>>> Michele
>>>
>>> --
>>> Michele M. Morgan, Systems Support Specialist
>>> North of Boston Library Exchange, Danvers Massachusetts
>>> mmor...@noblenet.org
>>>
>>>
>>>
>>> On Tue, Feb 27, 2024 at 5:09 PM Terran McCanna <
>>> tmcca...@georgialibraries.org> wrote:
>>>
>>>> We still see it sometimes when a patron has a negative bill on their
>>>> account (even when the overall balance isn't negative).
>>>> The current code shouldn't even be showing the payment option if there
>>>> are any negative bills, but somehow some patrons are still getting the
>>>> option. We have been on the new code for a long time (more than 2 years?)
>>>> so the only thing we can think of is that those patrons must be using an
>>>> old device that is stubbornly hanging onto a locally cached version of the
>>>> page. But we haven't been able to recreate the problem, so it's really
>>>> frustrating to troubleshoot.
>>>>
>>>> As far as I can tell, what is happening is that the patron somehow
>>>> loads the old version of the page that didn't do the negative bill check,
>>>> pays, Stripe accepts the payment but it's the wrong amount, so when Stripe
>>>> sends it to Evergreen it fails. Then the patron sees that Evergreen didn't
>>>> accept it and they pay again (still the wrong amount), causing their credit
>>>> card to be charged again.
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Feb 27, 2024 at 4:59 PM Morgan, Michele via Evergreen-general <
>>>> evergreen-general@list.evergreen-ils.org> wrote:
>>>>
>>>>> Hi Everyone,
>>>>>
>>>>> Since moving to Stri

Re: RFE: enable buffering on null-terminated data

[Carl Edquist via GNU coreutils General Discussion]

lessings here. I don't know what's going 
on in the background that would explain glibc not supporting any of 
that, or stdbuf(1) implementing features that aren't supported on the 
vast majority of systems where it will be installed.


Hey try it right?

Works for me (on glibc-2.23)

$ for s in 8k 16k 32k 1M; do
echo ::: $s :::
{ stdbuf -o$s strace -ewrite tr 1 2
} < /dev/zero 2>&1 > /dev/null | head -3
echo
  done

::: 8k :::
write(1, "\0\0\0\0\0\0\0\0"..., 8192) = 8192
write(1, "\0\0\0\0\0\0\0\0"..., 8192) = 8192
write(1, "\0\0\0\0\0\0\0\0"..., 8192) = 8192

::: 16k :::
write(1, "\0\0\0\0\0\0\0\0"..., 16384) = 16384
write(1, "\0\0\0\0\0\0\0\0"..., 16384) = 16384
write(1, "\0\0\0\0\0\0\0\0"..., 16384) = 16384

::: 32k :::
write(1, "\0\0\0\0\0\0\0\0"..., 32768) = 32768
write(1, "\0\0\0\0\0\0\0\0"..., 32768) = 32768
write(1, "\0\0\0\0\0\0\0\0"..., 32768) = 32768

::: 1M :::
write(1, "\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
write(1, "\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
write(1, "\0\0\0\0\0\0\0\0"..., 1048576) = 1048576



It may just be that nobody has actually had a real need for it. 
(Yet?)


I imagine if anybody has, they just set --output=0 and moved on. Bash 
scripts aren't the fastest thing in the world, anyway.


Ouch.  Ouch.  Och.  :)

While that's true if you're talking about bash itself doing the actual 
computation and data processing, the main work of the shell is making it 
easy to set up pipelines for other (very fast) programs to pass their data 
around.


The stdbuf tool is not meant for the shell!  It's meant for those very 
fast programs that the shell stands up.


Using stdbuf to tweak a very fast program, causing it to output more often 
at newlines over pipes rather than at block boundaries, does slow down 
those programs somewhat.  But as we've discussed, this is necessary for 
certain pipelines that have two-way communication (including coprocesses), 
or in general any time you want the output immediately.


What may not be obvious is that the shell does not need to get involved 
with writing input for a coprocess or reading its output - the shell can 
start other (very fast) programs with input/output redirected to/from the 
coprocess pipes to do that processing.


My point though earlier was that a null-terminated record buffering mode, 
as useful as it sounds on the surface (for null-terminated paths), may 
actually be something _nobody_ has ever actually needed for an actual (not 
contrived) workflow.


But then again I say "Yet?" - because, never say never.


Happy line-buffering  :)

Carl

Re: [Evergreen-general] Stripe Duplicate Charges

[Terran McCanna via Evergreen-general]

I read about that a while back, but I was under the impression that it
would only solve double-click types of problems, not problems where the
patron is actually filling out the form again. Is it just that we'd need to
design the idempotency key in a way that it generated the same key if the
scenario was the same? Like a combination of the patron ID and the amount
and the date or something like that?

On Wed, Mar 13, 2024 at 3:16 PM Morgan, Michele 
wrote:

> I wanted to share some information from Stripe's support about the
> duplicate credit card charges issue we have seen since our upgrade to 3.10.
>
> Stripe support indicated that making the requests from Evergreen
> idempotent will prevent retried requests from creating duplicate charges.
> This would entail including an idempotency key as an element in the payment
> request sent to Stripe. Here is some documentation from Stripe:
>
> https://docs.stripe.com/api/idempotent_requests
>
> I will likely open a Launchpad bug about this, but have not heard that
> others have seen this issue. I would still be interested in hearing if,
> besides PINES, there are other systems running Evergreen 3.8 or later and
> using Stripe, and whether or not you have seen any issues.
>
> Thanks for any feedback,
> Michele
>
> --
> Michele M. Morgan, Systems Support Specialist
> North of Boston Library Exchange, Danvers Massachusetts
> mmor...@noblenet.org
>
>
>
> On Wed, Feb 28, 2024 at 9:42 AM Morgan, Michele 
> wrote:
>
>> Thanks Terran!
>>
>> We've seen that negative bill issue once since our upgrade, and we're
>> double checking that our tt2 files have the correct code.
>>
>> We have also seen issues where the payment looks fine on the Evergreen
>> side, but on the Stripe side we see that more than one successful charge
>> was made for the same Evergreen bill. These patrons have *not* had any
>> negative bills.
>>
>> Has anyone else seen similar behavior?
>>
>> Thanks,
>> Michele
>>
>> --
>> Michele M. Morgan, Systems Support Specialist
>> North of Boston Library Exchange, Danvers Massachusetts
>> mmor...@noblenet.org
>>
>>
>>
>> On Tue, Feb 27, 2024 at 5:09 PM Terran McCanna <
>> tmcca...@georgialibraries.org> wrote:
>>
>>> We still see it sometimes when a patron has a negative bill on their
>>> account (even when the overall balance isn't negative).
>>> The current code shouldn't even be showing the payment option if there
>>> are any negative bills, but somehow some patrons are still getting the
>>> option. We have been on the new code for a long time (more than 2 years?)
>>> so the only thing we can think of is that those patrons must be using an
>>> old device that is stubbornly hanging onto a locally cached version of the
>>> page. But we haven't been able to recreate the problem, so it's really
>>> frustrating to troubleshoot.
>>>
>>> As far as I can tell, what is happening is that the patron somehow loads
>>> the old version of the page that didn't do the negative bill check, pays,
>>> Stripe accepts the payment but it's the wrong amount, so when Stripe sends
>>> it to Evergreen it fails. Then the patron sees that Evergreen didn't accept
>>> it and they pay again (still the wrong amount), causing their credit card
>>> to be charged again.
>>>
>>>
>>>
>>>
>>> On Tue, Feb 27, 2024 at 4:59 PM Morgan, Michele via Evergreen-general <
>>> evergreen-general@list.evergreen-ils.org> wrote:
>>>
>>>> Hi Everyone,
>>>>
>>>> Since moving to Stripe Payment Intents with our upgrade in early
>>>> January, we've seen issues with duplicate charges to the patron for the
>>>> same billing in Evergreen.
>>>>
>>>> I've searched Launchpad, but haven't found a relevant bug.
>>>>
>>>> Have others experienced similar issues since moving to Payment Intents?
>>>>
>>>> For reference, bug 1894005
>>>> <https://bugs.launchpad.net/evergreen/+bug/1894005> *Wishlist: Add
>>>> support for Stripe Payment Intents* was released in Evergreen 3.8.
>>>>
>>>> Also, for reference, these two followup bugfixes:
>>>>
>>>> bug 1965579 <https://bugs.launchpad.net/evergreen/+bug/1965579> - Stripe
>>>> Payment Intents and Negative Bills
>>>> bug 1981628 <https://bugs.launchpad.net/evergreen/+bug/1981628> - Follow
>>>> up to Stripe payment intents bug
>>>>
>>>> Thanks for any insight!
>>>>
>>>> Michele
>>>>
>>>> --
>>>> Michele M. Morgan, Systems Support Specialist
>>>> North of Boston Library Exchange, Danvers Massachusetts
>>>> mmor...@noblenet.org
>>>>
>>>> ___
>>>> Evergreen-general mailing list
>>>> Evergreen-general@list.evergreen-ils.org
>>>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>>>>
>>>
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Evergreen-general] Stripe Duplicate Charges

[Morgan, Michele via Evergreen-general]

I wanted to share some information from Stripe's support about the
duplicate credit card charges issue we have seen since our upgrade to 3.10.

Stripe support indicated that making the requests from Evergreen idempotent
will prevent retried requests from creating duplicate charges. This would
entail including an idempotency key as an element in the payment request
sent to Stripe. Here is some documentation from Stripe:

https://docs.stripe.com/api/idempotent_requests

I will likely open a Launchpad bug about this, but have not heard that
others have seen this issue. I would still be interested in hearing if,
besides PINES, there are other systems running Evergreen 3.8 or later and
using Stripe, and whether or not you have seen any issues.

Thanks for any feedback,
Michele

--
Michele M. Morgan, Systems Support Specialist
North of Boston Library Exchange, Danvers Massachusetts
mmor...@noblenet.org



On Wed, Feb 28, 2024 at 9:42 AM Morgan, Michele 
wrote:

> Thanks Terran!
>
> We've seen that negative bill issue once since our upgrade, and we're
> double checking that our tt2 files have the correct code.
>
> We have also seen issues where the payment looks fine on the Evergreen
> side, but on the Stripe side we see that more than one successful charge
> was made for the same Evergreen bill. These patrons have *not* had any
> negative bills.
>
> Has anyone else seen similar behavior?
>
> Thanks,
> Michele
>
> --
> Michele M. Morgan, Systems Support Specialist
> North of Boston Library Exchange, Danvers Massachusetts
> mmor...@noblenet.org
>
>
>
> On Tue, Feb 27, 2024 at 5:09 PM Terran McCanna <
> tmcca...@georgialibraries.org> wrote:
>
>> We still see it sometimes when a patron has a negative bill on their
>> account (even when the overall balance isn't negative).
>> The current code shouldn't even be showing the payment option if there
>> are any negative bills, but somehow some patrons are still getting the
>> option. We have been on the new code for a long time (more than 2 years?)
>> so the only thing we can think of is that those patrons must be using an
>> old device that is stubbornly hanging onto a locally cached version of the
>> page. But we haven't been able to recreate the problem, so it's really
>> frustrating to troubleshoot.
>>
>> As far as I can tell, what is happening is that the patron somehow loads
>> the old version of the page that didn't do the negative bill check, pays,
>> Stripe accepts the payment but it's the wrong amount, so when Stripe sends
>> it to Evergreen it fails. Then the patron sees that Evergreen didn't accept
>> it and they pay again (still the wrong amount), causing their credit card
>> to be charged again.
>>
>>
>>
>>
>> On Tue, Feb 27, 2024 at 4:59 PM Morgan, Michele via Evergreen-general <
>> evergreen-general@list.evergreen-ils.org> wrote:
>>
>>> Hi Everyone,
>>>
>>> Since moving to Stripe Payment Intents with our upgrade in early
>>> January, we've seen issues with duplicate charges to the patron for the
>>> same billing in Evergreen.
>>>
>>> I've searched Launchpad, but haven't found a relevant bug.
>>>
>>> Have others experienced similar issues since moving to Payment Intents?
>>>
>>> For reference, bug 1894005
>>> <https://bugs.launchpad.net/evergreen/+bug/1894005> *Wishlist: Add
>>> support for Stripe Payment Intents* was released in Evergreen 3.8.
>>>
>>> Also, for reference, these two followup bugfixes:
>>>
>>> bug 1965579 <https://bugs.launchpad.net/evergreen/+bug/1965579> - Stripe
>>> Payment Intents and Negative Bills
>>> bug 1981628 <https://bugs.launchpad.net/evergreen/+bug/1981628> - Follow
>>> up to Stripe payment intents bug
>>>
>>> Thanks for any insight!
>>>
>>> Michele
>>>
>>> --
>>> Michele M. Morgan, Systems Support Specialist
>>> North of Boston Library Exchange, Danvers Massachusetts
>>> mmor...@noblenet.org
>>>
>>> ___
>>> Evergreen-general mailing list
>>> Evergreen-general@list.evergreen-ils.org
>>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>>>
>>
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: Two questions about build-path reproducibility in Debian

[David A. Wheeler via rb-general]

> On Mar 12, 2024, at 11:45 AM, Vagrant Cascadian 
>  wrote:
> 
> On 2024-03-12, Holger Levsen wrote:
>> On Mon, Mar 11, 2024 at 06:24:22PM +, James Addison via rb-general wrote:
>>> Please find below a draft of the message I'll send to each affected 
>>> bugreport.
>> 
>> looks good to me, thank you for doing this!
>> 
>>> Note: I confused myself when writing this; in fact Salsa-CI reprotest _does_
>>> continue to test build-path variance, at least until we decide otherwise.
>> 
>> this is in fact a bug and should be fixed with the next reprotest release.
> 
> That is not a reprotest bug, but an infrastructure issue for the
> debian-specific salsa-ci configuration. Reprotest is not a
> debian-specific tool.
> 
> Reprotest should continue to vary build paths by default; reprotest
> historically and currently defaults to enabling all variations and
> making an exception does not seem worth the opinionated change of
> behavior. By design, reprotest is easy to configure which variations to
> enable and disable as needed.

This makes sense. If programs can build reproducibly while varying the 
build-path,
reproducible builds are easier to create, and that's a good thing even if not
strictly required.

--- David A. Wheeler

[Evergreen-general] The Evergreen Project Board Election - Voter Registration OPEN

[Frasur, Ruth via Evergreen-general]

Hello all,

Thank you to all who submitted nominations to fill open and opening seats on 
the Evergreen Project Board.  The next step in this process is voter 
registration.  Anyone who has contributed to the Evergreen Community or is 
employed by an institution that utilizes the Evergreen open-source ILS is 
eligible to register and ultimately vote.  The voter registration form is 
available at https://forms.gle/s8CGfVqRfzcdSV368 and will remain open until EOB 
on Friday, March 22.

Ruth Frasur Davis (she/they)
President
Evergreen Project Board
Coordinator
Evergreen Indiana Library Consortium
Evergreen Community Development Initiative
Indiana State Library
140 N. Senate Ave.
Indianapolis, IN 46204
(317) 232-3691

___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

[Evergreen-general] Evergreen Cataloging Interest Group – rescheduled to Tues, Mar 19

[Jennifer Weston via Evergreen-general]

*Cataloging Interest Group RESCHEDULED to next week*

The Evergreen Cataloging Interest Group will *not* meet today. Instead, we
will meet next week -- *Tuesday, March 19, 2024, at 2pm (ET)*.



We will have the added benefit of meeting during Bug Squashing Week
<https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing> next week so
we can participate in the process together.



Everyone is welcome – please join us! The meeting will be recorded for any
interested parties who cannot attend.



*Evergreen Cataloging Interest Group*

*Tuesday, March 19, 2024*

*2:00pm ET*



Zoom Meeting Link:

https://us06web.zoom.us/j/89440379465?pwd=TVY4anVHZmN6ZlZQRXVTM3o5eUUyZz09



Meeting ID: 894 4037 9465

Passcode: 086021

Want to dial into the call using your phone? Find your local number:
https://us06web.zoom.us/u/kcsI1s3S9P



*Topic:** Bug Squashing Week and Recent Release Updates*

We’ll look at the list of bugs to be reviewed during bug squashing week and
pick one or two to test together. We will also look at recent updates to
3.11 and 3.12 related to cataloging.



We hope to see you there!

Jennifer Weston,

on behalf of the Cataloging IG Organizing Committee



-

The Cataloging Interest Group usually meets on the second Tuesday of each
month. Everyone is welcome. Meetings are recorded and made available to the
community. For more information, please visit the Cat IG wiki at:
https://wiki.evergreen-ils.org/doku.php?id=cataloging:cwg
-


---

Jennifer Weston, MLIS

Product and Education Manager | Assistant Operations Manager

Equinox Open Library Initiative

*jennifer.wes...@equinoxoli.org *

1-877-OPEN-ILS (673-6457)

direct: 770-709-5574

*www.equinoxOLI.org <http://www.equinoxOLI.org>*
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: Two questions about build-path reproducibility in Debian

[James Addison via rb-general]

Hi folks,

On Wed, 6 Mar 2024 at 01:04, James Addison  wrote:
> [ ... snip ...]
>
> The Debian bug severity descriptions[1] provide some more nuance, and that
> reassures me that wishlist should be appropriate for most of these bugs
> (although I'll inspect their contents before making any changes).

Please find below a draft of the message I'll send to each affected bugreport.

Note: I confused myself when writing this; in fact Salsa-CI reprotest _does_
continue to test build-path variance, at least until we decide otherwise.

--- BEGIN DRAFT ---
Because Debian builds packages from a fixed build path, customized build paths
are _not_ currently evaluated by the 'reprotest' utility in Salsa-CI, or during
package builds on the Reproducible Builds team's package test infrastructure
for Debian[1].

This means that this package will pass current reproducibility tests; however
we still believe that source code and/or build steps embed the build path into
binary package output, making it more difficult that necessary for independent
consumers to confirm whether their local compilations produce identical binary
artifacts.

As a result, this bugreport will remain open and be assigned the 'wishlist'
severity[2].

...

[1] - https://tests.reproducible-builds.org/debian/reproducible.html

[2] - https://www.debian.org/Bugs/Developer#severities
--- END DRAFT ---

[Evergreen-general] Developer meeting reminder: Tomorrow March 12th at 3pm Eastern, 12 Pacific

[Blake Graham-Henderson via Evergreen-general]

All,

A friendly reminder that we'll have our Evergreen dev meeting in IRC 
tomorrow, March 12th at 3pm Eastern, 12 Pacific.


Agenda: https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2024-03-12

--
-Blake-
Conducting Magic
Will consume any data format
MOBIUS

___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: RFE: enable buffering on null-terminated data

[Carl Edquist via GNU coreutils General Discussion]

On Sun, 10 Mar 2024, Zachary Santer wrote:


On Sun, Mar 10, 2024 at 4:36 PM Carl Edquist  wrote:


Out of curiosity, do you have an example command line for your use case?


My use for 'stdbuf --output=L' is to be able to run a command within a
bash coprocess.


Oh, cool, now you're talking!  ;)


(Really, a background process communicating with the parent process 
through FIFOs, since Bash prints a warning message if you try to run 
more than one coprocess at a time. Shouldn't make a difference here.)


(Kind of a side-note ... bash's limited coprocess handling was a long 
standing annoyance for me in the past, to the point that I wrote a bash 
coprocess management library to handle multiple active coprocess and give 
convenient methods for interaction.  Perhaps the trickiest bit about 
multiple coprocesses open at once (which I suspect is the reason support 
was never added to bash) is that you don't want the second and subsequent 
coprocesses to inherit the pipe fds of prior open coprocesses.  This can 
result in deadlock if, for instance, you close your write end to coproc1, 
but coproc1 continues to wait for input because coproc2 also has a copy of 
a write end of the pipe to coproc1's input.  So you need to be smart about 
subsequent coprocesses first closing all fds associated with other 
coprocesses.


Word to the wise: you might encounter this issue (coproc2 prevents coproc1 
from seeing its end-of-input) even though you are rigging this up yourself 
with FIFOs rather than bash's coproc builtin.)




See coproc-buffering, attached.


Thanks!

Without making the command's output either line-buffered or unbuffered, 
what I'm doing there would deadlock. I feed one line in and then expect 
to be able to read a transformed line immediately. If that transformed 
line is stuck in a buffer that's still waiting to be filled, then 
nothing happens.


I swear doing this actually makes sense in my application.


Yeah makes sense!  I am familiar with the problem you're describing.

(In my coprocess management library, I effectively run every coproc with 
--output=L by default, by eval'ing the output of 'env -i stdbuf -oL env', 
because most of the time for a coprocess, that's whats wanted/necessary.)



... Although, for your example coprocess use, where the shell both 
produces the input for the coproc and consumes its output, you might be 
able to simplify things by making the producer and consumer separate 
processes.  Then you could do a simpler 'producer | filter | consumer' 
without having to worry about buffering at all.  But if the producer and 
consumer need to be in the same process (eg they share state and are 
logically interdependent), then yeah that's where you need a coprocess for 
the filter.


... On the other hand, if the issue is that someone is producing one line 
at a time _interactively_ (that is, inputting text or commands from a 
terminal), then you might argue that the performance hit for unbuffered 
output will be insignificant compared to time spent waiting for terminal 
input.




$ ./coproc-buffering 10
Line-buffered:
real0m17.795s
user0m6.234s
sys 0m11.469s
Unbuffered:
real0m21.656s
user0m6.609s
sys 0m14.906s


Yeah, this makes sense in your particular example.

It looks like expand(1) uses putchar(3), so in unbuffered mode this 
translates to one write(2) call for every byte.  sed(1) is not quite as 
bad - in unbuffered it appears to output the line and the newline 
terminator separately, so two write(2) calls for every line.


So in both cases (but especially for expand), line buffering reduces the 
number of write(2) calls.


(Although given your time output, you might say the performance hit for 
unbuffered is not that huge.)



When I initially implemented this thing, I felt lucky that the data I 
was passing in were lines ending in newlines, and not null-terminated, 
since my script gets to benefit from 'stdbuf --output=L'.


:thumbsup:



Truth be told, I don't currently have a need for --output=N.


Mmm-hmm  :)


Of course, sed and all sorts of other Linux command-line tools can 
produce or handle null-terminated data.


Definitely.  So in the general case, theoretically it seems as useful to 
buffer output on nul bytes.


Note that for gnu sed in particular, there is a -u/--unbuffered option, 
which will effectively give you line buffered output, including buffering 
on nul bytes with -z/--null-data .


... I'll be honest though, I am having trouble imagining a realistic 
pipeline that filters filenames with embedded newlines using expand(1) 
;)


...

But, I want to be a good sport here and contrive an actual use case.

So for fun, say I want to use cut(1) (which performs poorly when 
unbuffered) in a coprocess that takes null-terminated file paths on input 
and outputs the first directory component (which possibly contains 
embedded newlines).


The basic command in the coprocess would be:

cut -d/ -f1 -z

but with the default

[Slony1-general] Future of slony.info

[Steve Singer via Slony1-general]

A while back I was talking to Jan about what our plans should be for 
slony.info.


The user base and use-cases for slony been replaced with options built 
around the built in replication/decoding features and these are present in 
all non EOL versions of PG.


The only updates to slony in the past 4-6 years have been minimal/trivial.

Should we declare the project finished and work towards shutting down the 
mailing lists and website?


The source code is already hosted at 
http://git.postgresql.org/git/slony1-engine.git with mirrors on github


I would guess that slony is mostly used to help migrate off out of support 
versions of PG.


Unless someone objects we are thinking of shutting down the mailing lists 
and bugzilla, update the website to say this and that the project is moving to 
an archive phase.


Thoughts?

Steve

___
Slony1-general mailing list
Slony1-general@lists.slony.info
https://lists.slony.info/cgi-bin/mailman/listinfo/slony1-general

Re: RFE: enable buffering on null-terminated data

[Carl Edquist via GNU coreutils General Discussion]

Hi Zack,

This sounds like a potentially useful feature (it'd probably belong with a 
corresponding new buffer mode in setbuf(3)) ...


Filenames should be passed between utilities in a null-terminated 
fashion, because the null byte is the only byte that can't appear within 
one.


Out of curiosity, do you have an example command line for your use case?

If I want to buffer output data on null bytes, the closest I can get is 
'stdbuf --output=0', which doesn't buffer at all. This is pretty 
inefficient.


I'm just thinking that find(1), for instance, will end up calling write(2) 
exactly once per filename (-print or -print0) if run under stdbuf 
unbuffered, which is the same as you'd get with a corresponding stdbuf 
line-buffered mode (newline or null-terminated).


It seems that where line buffering improves performance over unbuffered is 
when there are several calls to (for example) printf(3) in constructing a 
single line.  find(1), and some filters like grep(1), will write a line at 
a time in unbuffered mode, and thus don't seem to benefit at all from line 
buffering.  On the other hand, cut(1) appears to putchar(3) a byte at a 
time, which in unbuffered mode will (like you say) be pretty inefficient.


So, depending on your use case, a new null-terminated line buffered option 
may or may not actually improve efficiency over unbuffered mode.



You can run your commands under strace like

stdbuf --output=X  strace -c -ewrite  command ... | ...

to count the number of actual writes for each buffering mode.


Carl


PS, "find -printf" recognizes a '\c' escape to flush the output, in case 
that helps.  So "find -printf '%p\0\c'" would, for instance, already 
behave the same as "stdbuf --output=N  find -print0" with the new stdbuf 
output mode you're suggesting.


(Though again, this doesn't actually seem to be any more efficient than 
running "stdbuf --output=0  find -print0")


On Sun, 10 Mar 2024, Zachary Santer wrote:


Was "stdbuf feature request - line buffering but for null-terminated data"

See below.

On Sun, Mar 10, 2024 at 5:38 AM Pádraig Brady  wrote:


On 09/03/2024 16:30, Zachary Santer wrote:

'stdbuf --output=L' will line-buffer the command's output stream.
Pretty useful, but that's looking for newlines. Filenames should be
passed between utilities in a null-terminated fashion, because the
null byte is the only byte that can't appear within one.

If I want to buffer output data on null bytes, the closest I can get
is 'stdbuf --output=0', which doesn't buffer at all. This is pretty
inefficient.

0 means unbuffered, and Z is already taken for, I guess, zebibytes.
--output=N, then?

Would this require a change to libc implementations, or is it possible now?


This does seem like useful functionality,
but it would require support for libc implementations first.

cheers,
Pádraig

Re: Three bytes in a zip file

[Larry Doolittle via rb-general]

Friends -

On Fri, Mar 08, 2024 at 05:21:43PM +0100, Fay Stegerman wrote:
> * Chris Lamb  [2024-03-08 12:16]:
> > Oh this is great work! So, using your tool, did you manage to solve the
> > underlying non-determinism? :)
> The original reproducibility issue this thread started with was traced back to
> the atime back then, my tool just hopefully makes doing that a bit easier :)
> I don't know how the original issue was fixed, but I can, eh, reproduce (and 
> get
> rid of) such an atime difference easily [with zip -X]:

For completeness, here is the production (working, well-tested) stanza of
shell scripting the emerged from that discussion.

# Create the final zip file
rm -f "$zipfile"
if test -n "$SOURCE_DATE_EPOCH"; then
  echo "Forcing timestamp $SOURCE_DATE_EPOCH"
  touch --date="@$SOURCE_DATE_EPOCH" fab/*
  TZ=UTC zip -X --latest-time "$zipfile" fab/*
  # Note the -X flag; to be pedantic about timestamps,
  # that means you should unpack with TZ=UTC unzip "$zipfile".  See
  # 
https://lists.reproducible-builds.org/pipermail/rb-general/2023-April/002927.html
else
  zip "$zipfile" fab/*
fi

As found on https://github.com/BerkeleyLab/Marble
in design/scripts/manufacturing.sh .

  - Larry

[Evergreen-general] Wanted! Conference Moderators

[Gina Monti via Evergreen-general]

Hi All,

This is another call for anyone interested in becoming a moderator for the
2024 Evergreen Conference, held remotely this year.  Your
responsibilities as a moderator are to keep audience counts, introduce the
speakers of the sessions you're assigned to, and field questions from the
chat.

If you're interested please send a reply off list and/or attend our
upcoming meeting to go over moderating next Friday, March 15 at 2PM Est.

Join Zoom Meeting
https://us02web.zoom.us/j/9142087021?omn=84334629513

-- 
Gina Monti (she/her)
Evergreen Systems Manager
Bibliomation, Inc.
(203) 577-4070 ext. 109
English, American Sign Language
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: pam_oath with user_unknown=ignore

[Simon Josefsson via OATH Toolkit general discussions]

Dirk van Deun  writes:

> On Wed, Mar 06, 2024 at 09:11:54PM +0100, Simon Josefsson wrote:
>> Dirk van Deun  writes:
>> 
>> > Hi,
>> >
>> > I really like the fact that you can use user_unknown=ignore to
>> > introduce pam_oath gradually, and it works fine if you use one users
>> > file to store all the secrets; but when you use a file per user 
>> > (like with usersfile=/oath/${USER}), users that do not have a secret
>> > yet do need an empty file for PAM_USER_UNKNOWN to be returned;
>> > without, you get a file-not-found kind of error instead.
>> >
>> > It is debatable whether this is a bug or just unexpected behaviour,
>> > but to me it would make more sense if in such a configuration, a
>> > missing file would also lead to PAM_USER_UNKNOWN.  
>> 
>> Yes this makes somewhat sense.  The patch to get your behaviour would
>> probably be something like this:
>> 
>> diff --git a/pam_oath/pam_oath.c b/pam_oath/pam_oath.c
>> index 25eb83e..f5ae490 100644
>> --- a/pam_oath/pam_oath.c
>> +++ b/pam_oath/pam_oath.c
>> @@ -303,7 +303,7 @@ pam_sm_authenticate (pam_handle_t *pamh,
>>  DBG (("authenticate first pass rc %d (%s: %s) last otp %s", rc,
>>oath_strerror_name (rc) ? oath_strerror_name (rc) : "UNKNOWN",
>>oath_strerror (rc), ctime (_otp)));
>> -if (rc == OATH_UNKNOWN_USER)
>> +if (rc == OATH_NO_SUCH_FILE || rc == OATH_UNKNOWN_USER)
>>{
>>  retval = PAM_USER_UNKNOWN;
>>  goto done;
>> 
>> Although since (IIRC) 'user_unknown=ignore' is handled by the PAM layer
>> and not the pam_oath module, I worry that if we start to return
>> PAM_USER_UNKNOWN on file-not-found errors, we will cause unwanted
>> behaviour in other situations.
>> 
>> One ugly way to resolve this is to introduce a new keyword that cause
>> this particular behaviour to happen, for example
>> 'missing_usersfile_leads_to_user_unknown' causes OATH_NO_SUCH_FILE
>> errors to be translated into PAM_USER_UNKNOWN.  What do you think?
>> Would you like to make an attempt to make a patch?
>> 
>> /Simon
>
> We can try to do the right thing based on the usersfile parameter:
>
> - if usersfile does not contain a variable, then OATH_NO_SUCH_FILE
> is still an error;
>
> - if usersfile starts with ${HOME}, OATH_NO_SUCH_FILE gives rise to
> PAM_USER_UNKNOWN, except if the home directory in question does
> not exist, as then it is safer to assume that something went wrong
> (like homes not being mounted) and keep calling it an error;
>
> - if usersfile starts with a literal path that ends with a slash,
> followed by a variable (presumably ${USER}), followed by whatever,
> OATH_NO_SUCH_FILE gives rise to PAM_USER_UNKNOWN, except if the
> literal path part does not exist OR is an empty directory -- the
> is-empty test can be added because we can reasonably assume that at
> least one user on the system has configured oath; 
>
> - other cases are just weird, so the error may stay an error.
>
> Agree ?

This sounds complicated to me since it assumes even further semantic
understanding of the usersfile path value.  Understanding the difference
between a missing and unreadable home directory can be difficult for
network file systems.  Right now the error is returned on all fopen()
failures, which includes a number of different error conditions.  It
isn't clear to me that there aren't reasonable scenarios where a missing
usersfile should NOT lead PAM_USER_UNKNOWN errors, but a hard error:
maybe someone is using the current semantics and has a hierarchy of
usersfile for users, and expect the current behaviour.

It still seems simpler to introduce a new keyword that triggers
PAM_USER_UNKNOWN for OATH_NO_SUCH_FILE usersfile error.  Then this can
be documented as a new supported feature.

/Simon


signature.asc
Description: PGP signature

[Evergreen-general] Reminder part deux - Nominations for open/ing seats on the Evergreen Project Board

[Frasur, Ruth via Evergreen-general]

Hello all,

Thank you to those of you who have submitted nominations for this year’s 
election.  There are still spots open, and I would encourage you to think, even 
if this is not something you are prepared to do, who in your organization MIGHT 
be able to meet once a month to discuss and make decisions related to the 
sustainability of the Evergreen Project as an organization and how it supports 
the Evergreen open-source ILS community.

The nomination form is located here - 
https://forms.gle/pH684HFtnyCRh2FVA<https://protect2.fireeye.com/v1/url?k=31323334-50bba2bf-31367a34-4544474f5631-75c0b21ce91f6e85=1=c7e2b05a-f7b5-46f1-a343-c412c6dea999=https%3A%2F%2Fforms.gle%2FpH684HFtnyCRh2FVA>.
  I’d love to give lots of reasons why you should do this, but I think you all 
know.  If not, please contact me or any of the other current or past board 
members for more information.  Please do not let imposter syndrome stop you 
from self-nominating.  This board was one of my first and best teachers about 
how the Evergreen community works, and where I could fit in the grand scheme of 
it all.  You can find out more about the Evergreen Project Board including 
those current and past members at this page - 
https://evergreen-ils.org/governance/<https://protect2.fireeye.com/v1/url?k=31323334-50bba2bf-31367a34-4544474f5631-ff71789228bde254=1=c7e2b05a-f7b5-46f1-a343-c412c6dea999=https%3A%2F%2Fevergreen-ils.org%2Fgovernance%2F>.

Ruth Frasur Davis (she/they)
President
Evergreen Project Board
Coordinator
Evergreen Indiana Library Consortium
Evergreen Community Development Initiative
Indiana State Library
140 N. Senate Ave.
Indianapolis, IN 46204
(317) 232-3691






___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Qgis-user] Atlas printing to PDF

[Nigel Berjak - General via QGIS-User]

Hi Spring

I think that, if I am understanding Emma's workflow correctly, you do 
not need to recreate the entire project, only the layout part. If I have 
misunderstood, I would first try loading the same project, then creating 
a new layout from the template, then reincorporating all the various 
settings. If this works, it would save a lot of time.


---
Regards,

Nigel Berjak
Please consider the environment before printing this email.

On 2024-03-07 11:20, Springfield Harrison wrote:


Hello Emma,

Thanks very much for your suggestions.

Pondering your workflow suggestions, are you suggesting that I create a 
new project in a new version of QGIS by dragging the old project into a 
empty project in the new version?  Do I have that right?  The .qpt file 
is a print template?


It sounds workable but time-consuming.  As it is, I'm up half the night 
just trying to get some of this work done.  I may give it a try but am 
leery of investing more time in "run the Atlas and see if it works."


I do appreciate your help and will probably give it a try, all fingers 
crossed.


Thanks again...


Cheers, Spring

On 2024-03-06 15:36, Emma Hain wrote:

Hi Spring
I am sorry you are experiencing this. I would strongly advise you to 
move up to the latest LTR of QGIS 3.36 when you can.


It sounds like there are some buggy things happening in the background, 
so maybe you need a clean version.


If this was me, I would follow this workflow.

* Open up in the original version and create a .qpt from the print 
layout

* Create a new product in the latest LTR

* Locate the old project in the Browser window

* Expand that project and drag the files into the new product.

* In the print layout:

* load the qpt
* Copy over the Atlas parameters from your old product (you can have 
both versions open at the same time)

* Run the atlas and see if it works.

Good luck!
Cheers
Em

On Sat, 2 Mar 2024 at 21:10, Springfield Harrison via QGIS-User 
 wrote: Hi Nigel,


Okay, note that.

However, I cannot get QGIS 3.32.3 to load copies of a couple of my
projects.  It seemed to hang up while dealing with certain files which 
I

then went back to the original 3.16.4 and removed.  Then it would hang
up on a different file.

In a new project, 3.32.3 will load those files but not from the 
original

project.  Is 3.32.3 known to have problems?  It seemed to install all
right from the Windows .MSI installer.

Update: the program will actually load those files, it just takes up 10
min. to do so.  And then there are huge delays during the work session.
The files loaded individually into a new project with no problem.

Once I finally got it working, I was able to try printing the Atlas.  
No

change, it just prints one blank page.  No error messages, just a fail.

Not sure what the answer is, I don't have the time to keep trying new
versions when they are mostly a disappointment.

Nevertheless, thanks very much for your thoughts...


Cheers, Spring

On 2024-03-01 00:22, Nigel Berjak wrote:

Hi Spring

The rasters should not be a problem. If they are not referenced, QGIS
will simply revert to querying you and asking you find their correct
locations. The file sizes should be fairly irrelevant, especially if
they have the pyramids built.

Cheers.

---
Regards,

Nigel Berjak
Please consider the environment before printing this email.

On 2024-03-01 09:57, Springfield Harrison wrote:

Hello Nigel,

Okay, thanks very much, just on the verge of updating now.

Your tip about using a copy of the project file is a good one. Will
certainly do that.

I hope the update will fix the Atlas printing problem but I'm not
holding my breath.  It contains several large map raster files which
may be the problem.

Thanks again...


Cheers, Spring



On 2024-02-29 22:26, Nigel Berjak wrote:

Hi Spring

It may be worthwhile trying this. Even 3.26 final release, as an
interim version. Also, ensure you do not open the original project
file, but rather a copy, in case you save it and cannot return
(possibly) to using it with the older version.

---
Regards,

Nigel Berjak
Please consider the environment before printing this email.

On 2024-03-01 05:16, Springfield Harrison wrote:
OK, thank you.  I'm using 3.16.4, perhaps I should move up to 
3.32.3?



Cheers, Spring



On 2024-02-29 05:15, Nigel Berjak wrote:

Hi

I have had to revert to using an older version (3.32.3) for one of
my projects, where the Atlas sheets bombs the application
(3.34.3). Is this the issue you are having?

---
Regards,

Nigel Berjak
Please consider the environment before printing this email.

On 2024-02-29 13:28, Springfield Harrison via QGIS-User wrote:

Hello,

Printing a PDF Atlas is a total fail - 1 page if I'm lucky,
mostly 1 blank page.  Is there a work around?

Thanks very much.  I'm sorry if this has been already covered,
there seems to be no searchable forum.


Cheers, Spring Harrison


___
QGIS-User 

Re: pam_oath with user_unknown=ignore

[Simon Josefsson via OATH Toolkit general discussions]

Dirk van Deun  writes:

> Hi,
>
> I really like the fact that you can use user_unknown=ignore to
> introduce pam_oath gradually, and it works fine if you use one users
> file to store all the secrets; but when you use a file per user 
> (like with usersfile=/oath/${USER}), users that do not have a secret
> yet do need an empty file for PAM_USER_UNKNOWN to be returned;
> without, you get a file-not-found kind of error instead.
>
> It is debatable whether this is a bug or just unexpected behaviour,
> but to me it would make more sense if in such a configuration, a
> missing file would also lead to PAM_USER_UNKNOWN.  

Yes this makes somewhat sense.  The patch to get your behaviour would
probably be something like this:

diff --git a/pam_oath/pam_oath.c b/pam_oath/pam_oath.c
index 25eb83e..f5ae490 100644
--- a/pam_oath/pam_oath.c
+++ b/pam_oath/pam_oath.c
@@ -303,7 +303,7 @@ pam_sm_authenticate (pam_handle_t *pamh,
 DBG (("authenticate first pass rc %d (%s: %s) last otp %s", rc,
  oath_strerror_name (rc) ? oath_strerror_name (rc) : "UNKNOWN",
  oath_strerror (rc), ctime (_otp)));
-if (rc == OATH_UNKNOWN_USER)
+if (rc == OATH_NO_SUCH_FILE || rc == OATH_UNKNOWN_USER)
   {
retval = PAM_USER_UNKNOWN;
goto done;

Although since (IIRC) 'user_unknown=ignore' is handled by the PAM layer
and not the pam_oath module, I worry that if we start to return
PAM_USER_UNKNOWN on file-not-found errors, we will cause unwanted
behaviour in other situations.

One ugly way to resolve this is to introduce a new keyword that cause
this particular behaviour to happen, for example
'missing_usersfile_leads_to_user_unknown' causes OATH_NO_SUCH_FILE
errors to be translated into PAM_USER_UNKNOWN.  What do you think?
Would you like to make an attempt to make a patch?

/Simon


signature.asc
Description: PGP signature

Re: [Evergreen-general] Reminder - Nominations for open/ing seats on the Evergreen Project Board

[Frasur, Ruth via Evergreen-general]

My apologies all.  I didn’t realize this was going out to the EVGILS general 
list.

Ruth Frasur Davis (she/they)
Coordinator
Evergreen Indiana Library Consortium
Evergreen Community Development Initiative
Indiana State Library
140 N. Senate Ave.
Indianapolis, IN 46204
(317) 232-3691

From: Evergreen-general  On 
Behalf Of Frasur, Ruth via Evergreen-general
Sent: Wednesday, March 6, 2024 8:08 AM
To: Evergreen Discussion Group 
Cc: Frasur, Ruth 
Subject: Re: [Evergreen-general] Reminder - Nominations for open/ing seats on 
the Evergreen Project Board

 This is an EXTERNAL email. Exercise caution. DO NOT open attachments or 
click links from unknown senders or unexpected email. 

Misty,

The skill set needed is honestly a willingness to participate at a higher level 
in the consortium, to represent both your library and other EG libraries in the 
same class (A,B,C), and the ability to attend virtual and/or in-person 
meetings.  The executive committee meets every other month in person at various 
libraries near the center of the state (mostly) and has a virtual option.  
Members must attend in-person at least twice a year.  The other committees meet 
virtually via Zoom.

In terms of what a board member needs to do, most of it is conceptual and 
involves gaining an understanding of general library workflows and needs as 
well as the willingness to work collaboratively and help make consensus based 
decisions.

Ruth Frasur Davis (she/they)
Coordinator
Evergreen Indiana Library Consortium
Evergreen Community Development Initiative
Indiana State Library
140 N. Senate Ave.
Indianapolis, IN 46204
(317) 232-3691

From: Evergreen-general 
mailto:evergreen-general-boun...@list.evergreen-ils.org>>
 On Behalf Of Misty via Evergreen-general
Sent: Tuesday, March 5, 2024 1:19 PM
To: Evergreen Discussion Group 
mailto:evergreen-general@list.evergreen-ils.org>>
Cc: mi...@clintonpl.lib.in.us<mailto:mi...@clintonpl.lib.in.us>
Subject: Re: [Evergreen-general] Reminder - Nominations for open/ing seats on 
the Evergreen Project Board

 This is an EXTERNAL email. Exercise caution. DO NOT open attachments or 
click links from unknown senders or unexpected email. 

If on the board what would someone have to do ? Is there a certain skill set 
needed ?
Misty Morse [She/Her]
Head of Adult Services
Clinton Public Library
https://clintonpl.lib.in.us/<https://protect2.fireeye.com/v1/url?k=31323334-50bba2bf-31367a34-4544474f5631-56f575b4dc74ecb9=1=c7e2b05a-f7b5-46f1-a343-c412c6dea999=https%3A%2F%2Fclintonpl.lib.in.us%2F>
765-832-8349
313 S. 4th St. Clinton, In.,47842

The only thing that you absolutely have to know,
is the location of the library.
—Albert Einstein




On Mon, Mar 4, 2024 at 10:51 AM, "Frasur, Ruth via Evergreen-general" 
mailto:evergreen-general@list.evergreen-ils.org>>
 wrote:
Hello all,





This is a reminder that there are FOUR open or opening seats on the Evergreen 
Project Board.  I’m extending the deadline for nominations (self-nominations 
are HIGHLY encouraged) through Friday, March 8.  The initial deadline was March 
1, and there have been NO nominations yet.  The nomination form is located here 
- 
https://forms.gle/pH684HFtnyCRh2FVA<https://protect2.fireeye.com/v1/url?k=31323334-50bba2bf-31367a34-4544474f5631-75c0b21ce91f6e85=1=c7e2b05a-f7b5-46f1-a343-c412c6dea999=https%3A%2F%2Fforms.gle%2FpH684HFtnyCRh2FVA>.
  I’d love to give lots of reasons why you should do this, but I think you all 
know.  If not, please contact me or any of the other current or past board 
members for more information.  Please do not let imposter syndrome stop you 
from self-nominating.  This board was one of my first and best teachers about 
how the Evergreen community works, and where I could fit in the grand scheme of 
it all.  You can find out more about the Evergreen Project Board including 
those current and past members at this page - 
https://evergreen-ils.org/governance/<https://protect2.fireeye.com/v1/url?k=31323334-50bba2bf-31367a34-4544474f5631-ff71789228bde254=1=c7e2b05a-f7b5-46f1-a343-c412c6dea999=https%3A%2F%2Fevergreen-ils.org%2Fgovernance%2F>.




Ruth Frasur Davis (she/they)


President


Evergreen Project Board


Coordinator


Evergreen Indiana Library Consortium


Evergreen Community Development Initiative


Indiana State Library


140 N. Senate Ave.


Indianapolis, IN 46204


(317) 232-3691


___________
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: [Evergreen-general] Reminder - Nominations for open/ing seats on the Evergreen Project Board

[Frasur, Ruth via Evergreen-general]

Misty,

The skill set needed is honestly a willingness to participate at a higher level 
in the consortium, to represent both your library and other EG libraries in the 
same class (A,B,C), and the ability to attend virtual and/or in-person 
meetings.  The executive committee meets every other month in person at various 
libraries near the center of the state (mostly) and has a virtual option.  
Members must attend in-person at least twice a year.  The other committees meet 
virtually via Zoom.

In terms of what a board member needs to do, most of it is conceptual and 
involves gaining an understanding of general library workflows and needs as 
well as the willingness to work collaboratively and help make consensus based 
decisions.

Ruth Frasur Davis (she/they)
Coordinator
Evergreen Indiana Library Consortium
Evergreen Community Development Initiative
Indiana State Library
140 N. Senate Ave.
Indianapolis, IN 46204
(317) 232-3691

From: Evergreen-general  On 
Behalf Of Misty via Evergreen-general
Sent: Tuesday, March 5, 2024 1:19 PM
To: Evergreen Discussion Group 
Cc: mi...@clintonpl.lib.in.us
Subject: Re: [Evergreen-general] Reminder - Nominations for open/ing seats on 
the Evergreen Project Board

 This is an EXTERNAL email. Exercise caution. DO NOT open attachments or 
click links from unknown senders or unexpected email. 

If on the board what would someone have to do ? Is there a certain skill set 
needed ?
Misty Morse [She/Her]
Head of Adult Services
Clinton Public Library
https://clintonpl.lib.in.us/<https://protect2.fireeye.com/v1/url?k=31323334-50bba2bf-31367a34-4544474f5631-56f575b4dc74ecb9=1=c7e2b05a-f7b5-46f1-a343-c412c6dea999=https%3A%2F%2Fclintonpl.lib.in.us%2F>
765-832-8349
313 S. 4th St. Clinton, In.,47842

The only thing that you absolutely have to know,
is the location of the library.
—Albert Einstein




On Mon, Mar 4, 2024 at 10:51 AM, "Frasur, Ruth via Evergreen-general" 
mailto:evergreen-general@list.evergreen-ils.org>>
 wrote:
Hello all,





This is a reminder that there are FOUR open or opening seats on the Evergreen 
Project Board.  I’m extending the deadline for nominations (self-nominations 
are HIGHLY encouraged) through Friday, March 8.  The initial deadline was March 
1, and there have been NO nominations yet.  The nomination form is located here 
- 
https://forms.gle/pH684HFtnyCRh2FVA<https://protect2.fireeye.com/v1/url?k=31323334-50bba2bf-31367a34-4544474f5631-75c0b21ce91f6e85=1=c7e2b05a-f7b5-46f1-a343-c412c6dea999=https%3A%2F%2Fforms.gle%2FpH684HFtnyCRh2FVA>.
  I’d love to give lots of reasons why you should do this, but I think you all 
know.  If not, please contact me or any of the other current or past board 
members for more information.  Please do not let imposter syndrome stop you 
from self-nominating.  This board was one of my first and best teachers about 
how the Evergreen community works, and where I could fit in the grand scheme of 
it all.  You can find out more about the Evergreen Project Board including 
those current and past members at this page - 
https://evergreen-ils.org/governance/<https://protect2.fireeye.com/v1/url?k=31323334-50bba2bf-31367a34-4544474f5631-ff71789228bde254=1=c7e2b05a-f7b5-46f1-a343-c412c6dea999=https%3A%2F%2Fevergreen-ils.org%2Fgovernance%2F>.




Ruth Frasur Davis (she/they)


President


Evergreen Project Board


Coordinator


Evergreen Indiana Library Consortium


Evergreen Community Development Initiative


Indiana State Library


140 N. Senate Ave.


Indianapolis, IN 46204


(317) 232-3691



___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: Two questions about build-path reproducibility in Debian

[James Addison via rb-general]

Hi Vagrant,

Narrowing in on (or perhaps nitpicking) a detail:

On Mon, 4 Mar 2024 at 20:41, Vagrant Cascadian
 wrote:
>
> On 2024-03-04, John Gilmore wrote:
> > Vagrant Cascadian wrote:
> >> > > to make it easier to debug other issues, although deprioritizing them
> >> > > makes sense, given buildd.debian.org now normalizes them.
> >
> > James Addison via rb-general  
> > wrote:
> >> Ok, thank you both.  A number of these bugs are currently recorded at 
> >> severity
> >> level 'normal'; unless told not to, I'll spend some time to double-check 
> >> their
> >> details and - assuming all looks OK - will bulk downgrade them to 
> >> 'wishlist'
> >> severity a week or so from now.
>
> Well, I think we should change it to "minor" rather than "wishlist"
> severity, but that may be splitting hairs; I do not find a huge amount
> of difference between debian bug severities... they are pretty much
> either critical/serious/grave and thus must be fixed, or
> normal/minor/wishlist and fixed when someone feels like it.

The Debian bug severity descriptions[1] provide some more nuance, and that
reassures me that wishlist should be appropriate for most of these bugs
(although I'll inspect their contents before making any changes).

Regards,
James

[1] - https://www.debian.org/Bugs/Developer#severities

Re: [Evergreen-general] Reminder - Nominations for open/ing seats on the Evergreen Project Board

[Misty via Evergreen-general]

If on the board what would someone have to do ? Is there a certain skill set 
needed ?
Misty Morse [She/Her]
Head of Adult Services
Clinton Public Library
https://clintonpl.lib.in.us/ (https://clintonpl.lib.in.us/)
765-832-8349
313 S. 4th St. Clinton, In.,47842
The only thing that you absolutely have to know,
is the location of the library.
—Albert Einstein
On Mon, Mar 4, 2024 at 10:51 AM, "Frasur, Ruth via Evergreen-general"  wrote: 
 Hello all,
 This is a reminder that there are FOUR open or opening seats on the Evergreen 
Project Board.  I’m extending the deadline for nominations (self-nominations 
are HIGHLY encouraged) through Friday, March 8.  The initial deadline was March 
1, and there have been NO nominations yet.  The nomination form is located here 
-  https://forms.gle/pH684HFtnyCRh2FVA (https://forms.gle/pH684HFtnyCRh2FVA).  
I’d love to give lots of reasons why you should do this, but I think you all 
know.  If not, please contact me or any of the other current or past board 
members for more information.  Please do not let imposter syndrome stop you 
from self-nominating.  This board was one of my first and best teachers about 
how the Evergreen community works, and where I could fit in the grand scheme of 
it all.  You can find out more about the Evergreen Project Board including 
those current and past members at this page -  
https://evergreen-ils.org/governance/ (https://evergreen-ils.org/governance/). 
 Ruth Frasur Davis (she/they)
 President
 Evergreen Project Board
 Coordinator
 Evergreen Indiana Library Consortium
 Evergreen Community Development Initiative
 Indiana State Library
 140 N. Senate Ave. 
 Indianapolis, IN 46204
 (317) 232-3691
___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: Two questions about build-path reproducibility in Debian

[David A. Wheeler via rb-general]

> On Mar 4, 2024, at 3:37 PM, Holger Levsen  wrote:
> 
> On Mon, Mar 04, 2024 at 11:52:07AM -0800, John Gilmore wrote:
>> Why would these become "wishlist" bugs as opposed to actual reproducibility 
>> bugs
>> that deserve fixing, just because one server at Debian no longer invokes this
>> bug because it always uses the same build directory?
> 
> because it's "not one server at Debian" but what many ecosystems do: build in 
> an
> deterministic path (eg /$pkg/$version or whatever) or record the path as part
> of the build environment, to have it deterministic as well.
> 
> in the distant past, before namespacing become popular, using a random path
> was a solution to allow parallel builds of the same software & version.
> 
> and yes, this is a shortcut and a tradeoff, similar to demanding to build 
> in a certain locale. also it makes reproducibilty from around 80-85% of all 
> packages to >95%, IOW with this shortcut we can have meaningful 
> reproducibility
> *many years* sooner, than without.
> 
> and I'd really rather like to see Debian 100% reproducible in 2030, than in 
> 2038.
> and some subsets today, or much sooner.

I agree with Holger (and Vagrant).

It'd be *nice* if a build was reproducible regardless of the directory used to 
build it.
But today, if you're building an executable for others, it's common to build 
using a
container/chroot or similar that makes it easy to implement "must compile with 
these paths",
while *fixing* this is often a lot of work.

I suggest focusing on ensuring everyone knows what the executable files 
contain, first.
if people can add more flexibility to their build process, all the better, but 
that added flexibility
comes at a cost of time and effort that is NOT as important.

--- David A. Wheeler

[Evergreen-general] Reminder - Nominations for open/ing seats on the Evergreen Project Board

[Frasur, Ruth via Evergreen-general]

Hello all,

This is a reminder that there are FOUR open or opening seats on the Evergreen 
Project Board.  I'm extending the deadline for nominations (self-nominations 
are HIGHLY encouraged) through Friday, March 8.  The initial deadline was March 
1, and there have been NO nominations yet.  The nomination form is located here 
- https://forms.gle/pH684HFtnyCRh2FVA.  I'd love to give lots of reasons why 
you should do this, but I think you all know.  If not, please contact me or any 
of the other current or past board members for more information.  Please do not 
let imposter syndrome stop you from self-nominating.  This board was one of my 
first and best teachers about how the Evergreen community works, and where I 
could fit in the grand scheme of it all.  You can find out more about the 
Evergreen Project Board including those current and past members at this page - 
https://evergreen-ils.org/governance/.

Ruth Frasur Davis (she/they)
President
Evergreen Project Board
Coordinator
Evergreen Indiana Library Consortium
Evergreen Community Development Initiative
Indiana State Library
140 N. Senate Ave.
Indianapolis, IN 46204
(317) 232-3691

___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

Re: Two questions about build-path reproducibility in Debian

[James Addison via rb-general]

On Wed, 28 Feb 2024 at 12:06, Chris Lamb  wrote:
>
> Vagrant Cascadian wrote:
>
> > There are real-world build path issues, and while it is possible to work
> > around them in various ways, I think they are still issues worth fixing
> > to make it easier to debug other issues, although deprioritizing them
> > makes sense, given buildd.debian.org now normalizes them.
>
> +1.
>
> And for this reason, I think we should keep the buildpath-related
> bugs as well. They should all be 'wishlist' priority anyway, and I
> wouldn't like to bet my hat that the usertag metadata is accurate and
> comprehensive enough to blindly close them in the first place. (We
> only really used the usertags to do some rough-and-ready statistics
> on broad issue categories.)

Ok, thank you both.  A number of these bugs are currently recorded at severity
level 'normal'; unless told not to, I'll spend some time to double-check their
details and - assuming all looks OK - will bulk downgrade them to 'wishlist'
severity a week or so from now.

Re: reprotest: inadvertent misconfiguration in salsa-ci config

[James Addison via rb-general]

Hi Chris, Vagrant,

On Tue, 27 Feb 2024 at 17:44, Vagrant Cascadian
 wrote:
>
> On 2024-02-27, Chris Lamb wrote:
> >> * Update reprotest to handle a single-disabled-varations-value as a
> >>   special case - treating it as vary and/or emitting a warning.
>
> Well, I would broaden this to include an arbitrary number of negating
> options:
>
>   --variations=-time,-build_path
>
> That seems just as invalid.
>
> The one special case I could see is "--variations=-all" where you might
> want to be normalizing as much as possible.

Hmm, yep.  So when there are only subtractions, we _could_ imply that
there is an
implicit '+all' at the beginning of the 'variations' argument.

And along that line of thinking, we could emit a warning to stderr:

  $ reprotest auto --dry-run --variations=-timezone
  Implicitly expanding variations '-timezone' to '+all,-timezone'
  ...

> > On whether to magically/transparently fix this, needless to say, it's
> > considered bad practice to change the behaviour of software that has
> > already been released — I would, as a rule, subscribe to that idea.
> > However, we should bear in mind that this idea revolves around what
> > users are *expecting*, not necessarily what the software actually
> > does.
> >
> > I say that because I hazard that all 400 usages are indeed expecting
> > that `--variations=-foo` functions the same as `--variations=all,-foo`
> > (or `--vary=-foo`), and so this proposed change would merely be
> > modifying reprotest to reflect their existing expectations. It would
> > not therefore be a violation of the "don't break existing
> > functionality" dictum.
> >
> > (Saying that, the addition of a warning that we are doing so would
> > definitely not go amiss.)
>
> Hrm. Less inclined toward this approach; expectations can shift with
> time and context and culture and whatnot. That said, I agree the current
> behavior is confusing, and we should change something explicitly, rather
> than implicitly...

Changing-existing-behaviours could arguably be even more problematic for
cases like this where we're talking about continuous integration checks.

Breaking/unbreaking unrelated CI pipelines seems like something we should be
careful to avoid.

> >> * Treat removal of a variance factor from an already-empty-context
> >> as an error.
> >
> > I'm also tempted by this as well. :)  How would this be experienced by
> > most DDs? Would their new pushes to Salsa now suddenly fail in the
> > reprotest job of the pipeline? If so, that's not too awful, given that
> > the prominent error message would presumably let them know precisely
> > how to fix it.
>
> I would much prefer an error message if we can correctly identify this.

That'd be nice - perhaps something like:

  Failed to parse variations: '-timezone'; did you mean '+all,-timezone'?

I've opened a merge request[1] to explore this error-treatment approach; it
lacks useful error messaging so far, but I'll attempt to add that soon.

> Some possible expected behaviors to consider treating as invalid, and
> issue an error:
>
>   --variations=-build_path
>
>   --variations=-time,-build_path
>
> This almost makes me want to entirely deprecate --variations, and switch
> to recommending "--vary=-all,+whatever" or "--vary=-all
> --vary=+whatever" instead of ever using --variations.
>
> I'm not sure the variations syntax enables much that cannot be more
> unambiguously expressed with --vary.

I do think that supporting two command-line argument names that provide
similar operations (and use similar names!) is confusing.

However I'm inclined to limit the effect of any behaviour changes here to the
specific cases that we know are problematic (ref previous thoughts about CI
infrastructure).

> That said, the reprotest code is a bit hairy, and I am not sure what
> sort of refactoring will be needed to make this possible. In particular,
> how --auto-build is implemented, where it systematically tests each
> variation one at a time. That said, Refactoring might be needed
> regardless. :)

That's a neat bit of functionality in auto-build.  As far as I can tell, it
seems agnostic of whether the build specifications are provided by 'vary' or
'variations' -- but test coverage would be better at confirming that.

Regards,
James

RE: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

Sorry, MK, I didn't read back over the old threads, to see what links you had 
referenced, before I replied. It was late at night, and I was using my phone 
rather than a PC.



In that case, I must have misunderstood what you meant by, "Is making the bot 
auto-play the same as doing rollouts?" It seemed to me that, since only you 
know what’s in your scripts, it was most likely that you were asking about 
rollouts are, although that also seemed unlikely.



You asked earlier about the GNUBG ID I used. It was:   
4HPwATDgc/ABMA:cAkA

This is the ID obtained after the sequence I suggested:   
4HPwATDgc/ABMA:cAkA

(Thanks for the link to the BKGM post. I’d forgotten about it, but fortunately 
it had recently been discussed on Daily Gammon, where someone else also found 
your 4-roll solution!)



They are identical, so there is no indication in the ID to indicate whether it 
is the opening roll. Therefore, the evaluation is the same. The Contact Net 
does not have an input for Opening Roll, which makes sense. The bot plays by 
maximizing the equity of the next position. The opening layout – with doubles 
prohibited - is never the next position.


Comparing evaluation, Rollout as Normal Position, Rollout as Initial Position, 
we can see that the evaluation is close to the value of the rollout. The 
rollout as the initial position is lower since it doesn’t include those useful 
doubles.
Ply

Cube

Pwin

Pwin2

Pwin3

Plose

Plose2

Plose3

E cubeless

E No Double

E Double/Take

Action

2 eval

n/a

0.5248

0.1495

0.0069

0.4752

0.1248

0.0053

+0.0759

+0.0982

‑0.1712

NB (23.0%)

2

1Cen

0.5256

0.1532

0.0082

0.4744

0.1287

0.0053

+0.0785

+0.1187





Normal

2Opp

0.5274

0.1521

0.0074

0.4726

0.1295

0.0056

+0.1586



-0.2127

NB (27.3%)

2

1Cen

0.5130

0.1461

0.0069

0.4870

0.1336

0.0058

+0.0395

+0.0580





Initial

2Opp

0.5147

0.1468

0.0068

0.4853

0.1332

0.0059

+0.0881



-0.3002

NB (27.6%)




I don’t think the value of 0.36 ppg for cube ownership that we both obtained is 
a "coincidence". I think it's evidence that your script is a good emulation of 
a rollout. If you think 0.36 is inaccurate, I’m open to persuasion. Do you have 
a theory as to why it’s wrong, or what you think the correct value is?



Regarding the equity at the beginning of the game, I’m not aware of any 
“age-old fallacy”. It's well established that winning the opening roll confers 
an advantage. I don’t think there's any theory that says the equity (between 
equal opponents) is non-zero before the opening roll. Indeed, the construction 
of most match equity tables is based on the equity at the start of the game 
being zero (unless they are assuming unequal players).



Finally, please lay off the disparagement. “What will it take for you guys to 
give some credit/benefit of the doubt to others than just yourselves?” is 
unnecessary. I’m not sure which group of ‘guys’ you lump me into; I’m just a 
gnubg user and a moderate player. I give lots of credit to loads of people who 
have contributed far more to backgammon than I ever will.



Ian



--Original Message-

From: MK mailto:playbg-...@yahoo.com>>

Sent: Monday, March 4, 2024 3:17 AM

To: Ian Shaw mailto:ian.s...@riverauto.co.uk>>; 
bug-gnubg@gnu.org

Cc: Philippe Michel mailto:philippe.mich...@free.fr>>

Subject: Re: Interesting question/experiment about value of cube ownership



On 3/1/2024 6:02 PM, Ian Shaw wrote:



> "Is making the bot auto-play the

> same as doing rollouts?"

>

> It sounds like you are asking what a rollout is?



I wasn't.



> https://www.gnu.org/software/gnubg/manual/html_node/Introduction-to-ro

> llouts.html



I had read it many a times before.



> https://www.bkgm.com/openings/rollouts.html



This is funny. You are referring me back to the same link that I had given in 
my reply to you on February 10, here in this very same thread... :) What will 
it take for you guys to give some credit/benefit of the doubt to others than 
just yourselves?



> Your auto-play script sounds very similar but I don't know exactly

> what it does.



Fair enough. My explaining in my previous post about what it does in this 
specific experiment was probably too brief and not very clear.



> The main difference would be that you can make your scripts double

> using your own algorithm.



Yes, in some experiment I did that but not in this one.



> Or indeed, veer from the bot's best chequer play.



I haven't done any checker experiments yet but I may.



> Minor differences might be the play settings for search depth and

> pruning.



Okay. You now made me realize that even unchecking all of the optional settings 
in roll-outs, it will not be the same as bot auto-playing. We both must have 
come up with the same 0.36 ppg by coincidence. Regardless, I believe that it's 
inaccurate in either case anyway.



> Try this manual sequence, and evaluate the next move.

> This gets you back to 

Re: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

"Is making the bot auto-play the
same as doing rollouts?"

It sounds like you are asking what a rollout is?  There are plenty of resources 
on the net.
https://www.gnu.org/software/gnubg/manual/html_node/Introduction-to-rollouts.html

https://www.bkgm.com/openings/rollouts.html

Your auto-play script sounds very similar but I don't know exactly what it does.

The main difference would be that you can make your scripts double using your 
own algorithm. Or indeed, veer from the bot's best chequer play.

Minor differences might be the play settings for search depth and pruning.

Try this manual sequence, and evaluate the next move. This gets you back to the 
start position. But doubles would be allowed, so the bot evaluation should not 
be the same as that of the opening roll.

64: 13/7 24/20

33: 24/18* 13/7

21: bar/24 20/18*

51: bar/24 18/13

32: 18/13




From: MK 
Sent: Friday, March 1, 2024 10:46:29 PM
To: Ian Shaw ; bug-gnubg@gnu.org 
Cc: Philippe Michel 
Subject: Re: Interesting question/experiment about value of cube ownership

On 3/1/2024 6:22 AM, Ian Shaw wrote:

> 27000 trials at 0-ply and 1-ply. 135000 trials at 2-ply.
> There’s almost no difference in value between the rollout
> that took 8 minutes and the one that tool 23 hours, which
> speaks to the strength of the initial evaluation.

This is good to know. Can you post the position ID so that
there is no misassumptions.

> The rollout suggests that the value of cube ownership in
> the initial position is worth about 0.36 points.

This is very interesting. Is making the bot auto-play the
same as doing rollouts? During the past weeks, I have done
12 different experiments with 20,000 games in each. I'm now
putting it all on a neatly organized web page which I will
share here soon.

Six of my experiments were about the value of winning the
opening roll and/or owning the cube from the start (i.e.
before the first move for the mutant but before the second
move for the bot since it always auto-plays and there is no
way to intercept before its first move).

Very interestingly I also came up with 0.36 ppg and 0.28 ppc
("points per cube" decision).

I collected and tabulated quite a lot of various stats which
will be on my web page, along with the actual scripts I ran,
saved games, log files, etc. so that you all can derive your
own conclusions with or without replicating my experiments,
with the important ones being about "mutant cube strategies".

> One thing to notice is that the rollout has the on-roll
> player winning about 1% less than the evaluations posted
> by MK. I think this is due to the evaluation assuming that
> initial doubles may be played, whereas I set the rollout
> to play as the initial position.

I'm not sure what you are referring to here. What I had posted
was the GnuBG's 2-ply evaluation of the opening position (i.e.
without initial doubles). So, that 1% must be the difference
between that and your rollouts?? (as well as my experiments?)

> I haven’t found a way toa ask gnubg for an evaluation for the
> initial roll. Is there one?
> You could get a 1-ply evaluation by combining all 15 0-ply
> evaluations of the first roll, and so forth.

I don't understand these. Hopefully others will pitch in their
comments in response...

MK


> *From:*bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org
>  *On Behalf Of *Ian Shaw 
> via Bug reports for and
> general discussion about GNU Backgammon.
> *Sent:* Thursday, February 8, 2024 11:39 AM
> *To:* playbg-...@yahoo.com; bug-gnubg@gnu.org
> *Cc:* Philippe Michel 
> *Subject:* RE: Interesting question/experiment about value of cube ownership
>
> It just so happens that I rolled out the opening position a few days ago for 
> another reason. This
> was at 7-away 7-away rather than $ play, because I was interested in match 
> play. I doubt that makes
> a huge difference.
>
> This was using gnubg-1_08_dev-20240103-setup.exe not the newest 
> gnubg-1_08_001-20240204-setup.exe
> that Philippe released recently.
>
> Philippe, am I correct in thinking that the cube handling on these two 
> versions is the same? Your
> announcement emails both include the same comment.
>
> “Improvement to cube decisions at 0- and 1-ply and weaker levels. Cube error 
> rates are approximately
> halved and the repartition of errors (premature doubles vs. missed doubles 
> vs. take or pass errors)
> is now similar to higher plies instead of being mostly premature doubles.”
>
> The rollout results indicate about 1% fewer wins for the roller than the 
> evaluations.
>
> 4HPwATDgc/ABMA:cAngAAAE
>
> Cube analysis
>
> Rollout cubeless equity +0.0408 (Money: +0.0396)
>
> Cubeful equities:
>
> 1. No double   +0.0655
>
> 2. Double, pass+1.  (+0.9345)
>
> 3. Dou