Evergreen ILS Website

IRC log for #evergreen, 2020-08-04

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:19 abowling joined #evergreen
01:29 abowling1 joined #evergreen
01:30 abowling1 left #evergreen
01:31 abowling1 joined #evergreen
01:32 abowling1 left #evergreen
03:01 mrisher_ joined #evergreen
04:49 mrisher joined #evergreen
06:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:00 agoben joined #evergreen
07:13 rjackson_isl_hom joined #evergreen
07:40 angelo joined #evergreen
07:48 angelo does anyone have experience migrating data from one evergreen server to another? i have a new install of an evergreen server that i need to import data into in the form of TSV files
07:48 angelo but when i try to import them i get a bunch of DB constraint violation errors
08:02 Dyrcona joined #evergreen
08:08 mantis1 joined #evergreen
08:15 angelo left #evergreen
08:15 angelo joined #evergreen
08:16 angelo left #evergreen
08:16 angelo joined #evergreen
08:17 angelo left #evergreen
08:17 rfrasur joined #evergreen
08:18 angelo joined #evergreen
08:19 angelo can anyone see this?
08:22 agoben Yes, but I can't offer you any answers on your earlier questions.
08:22 angelo oh perfect, i wasnt sure if i was registered or not
08:23 agoben You might try posting again in an hour or so.  More support staff will be watching the chat by then.  Good luck with your migration!
08:23 angelo thanks, will do
08:38 mmorgan joined #evergreen
08:45 Dyrcona angelo: Are you trying to move everything from one Evergreen instance to another, or is it just selected data from the source database?
08:50 tlittle joined #evergreen
08:57 angelo joined #evergreen
08:57 angelo Dyrcona its an export of certain data
08:58 angelo the old host is not giving us any assitance because we are moving away from them so they just dumped the tables
08:58 Dyrcona angelo: You'll have to disable the constraints in the target database and re-enable them after the load is finished, and hope you didn't miss any crucial data.
08:59 angelo ok, ill give that a try
08:59 angelo thanks
09:00 Dyrcona Also, pay attention to the constraint messages because loading the data in a certain order may help.
09:01 Dyrcona For instace, the actor.org_unit table should be the very first data loaded. Without those entries, nothing else works.
09:05 collum joined #evergreen
09:18 Stompro joined #evergreen
09:32 rhamby so you have a bunch of delimited files but not a dump, I take it this is a subset of the data and that's why you don't have an actual postgres dump file?
09:37 Dyrcona rhamby: That's what it sounds like, and I wonder how complete the data really is.
09:37 rhamby Dyrcona: yeah, depends and what from, for example if they're from the migration-tools export script it's fairly complete data wise but not really meant to rebuild an evergreen instance from
09:38 rhamby I would assume dragons would live in those waters actually.
09:38 Dyrcona Yeah. If it's done by hand, then who knows what they've got.
09:39 rhamby yeppers
09:39 Dyrcona I was also just about to suggest that angelo have a look at the migration tools: https://github.com/EquinoxOpenLi​braryInitiative/migration-tools
09:41 rhamby and that reminds me I need to put on my todo when when I have time (hah) to audit the actor schema for tables that should be added to the export script
09:42 angelo thanks @dy
09:42 angelo @dy
09:42 pinesol angelo: http://cat.evergreen-ils.org.meowbify.com/
09:42 angelo Dyrcona omg, clicking too soon, thank you
09:43 angelo pinesol that link goes nowhere
09:43 pinesol angelo: It reads like a Nigerian 419 scam, but I think it is a sincere question sent to the wrong list.
09:45 Dyrcona Looks like meobify.com doesn't work any more.
09:45 * Dyrcona had trouble typing the URL to visit the home page, too.
09:47 Dyrcona pineol: Be nice.
09:47 Dyrcona pinesol, even.... :)
09:47 pinesol Dyrcona: We're going to need a bigger boat.
09:47 Dyrcona My fingers don't seem to want to cooperate this morning.
09:48 csharp angelo: pinesol is our channel bot and @ is the prefix for bot commands - when addressing someone individually, just use their nick with no @
09:48 csharp @blame pinesol
09:48 pinesol csharp: itself is probably integrated with systemd
09:49 angelo csharp thanks
09:51 csharp +
09:51 gmcharlt yikes, the bot is feeling stroppy today!
09:52 csharp @insult pinesbot
09:52 pinesol pinesbot: You are nothing but a weasel-smelling pile of off-color snake.
09:52 csharp heh - "pinesbot" is the name of our XMPP channel bot on another platform so muscle memory did that
09:52 angelo **skynet activated**
09:53 csharp angelo++
09:53 Dyrcona angelo++ and welcome to the club!
09:53 angelo thanks!
09:54 csharp angelo: if you can pastebin the format of your data files somewhere (pastebin.com, paste.evergreen-ils.org, etc.) people might be able to advise more helpfully
09:54 angelo i inherited this evergreen project, im just a lowly developer but now a library system admin!
09:54 angelo csharp i was just looking how to paste in a screen shot of the files to see if anyone recognized the format
09:54 csharp (cleansed of any sensitive data, of course, just the column structure)
09:55 stompro_ joined #evergreen
09:55 Dyrcona Yeah, the header lines should be enough.
09:55 angelo https://pasteboard.co/JkOvo5j.png
09:55 angelo thats what was in the zip
09:58 rhamby angelo: that is a dead ringer for the export script output from migration-tools
09:59 rhamby those files have complete data but the export wasn't designed to be a quick rebuild for an evergreen instance
09:59 csharp angelo: and most people here inherited their sys admin roles, so you're in good company :-)
10:00 angelo csharp i need a new rack for all my hats
10:09 rhamby angelo: I don't know if this is enough detail to be helpful but the way I'd aprpoach that kind of migration/data loading is to create a bunch of child tables with the old IDs as legacy values and use those to map to new fresh IDs on a fresh Evergreen install
10:09 rhamby angelo : it's time consuming but could be largely scripted for an easy repeatable process
10:12 csharp create a table that matches the columns/data types, then "copy <table name> from '<file>' csv header;" would at least get it into postgres where you can work with it more easily
10:13 csharp wouldn
10:13 csharp 't need to do that with the MARC files though - they could be imported directly
10:14 csharp I'm not a migration expert at all, though - our instance has been super static for years
10:14 * csharp would defer to rhamby and people like Bmagic
10:14 * Bmagic scrolls up
10:15 gmcharlt e.g., create table actor.org_unit_stage (like actor.org_unit);
10:15 stompro__ joined #evergreen
10:16 Dyrcona I'd recommend creating the tables in a staging schema, like the migration tools do in the other import scripts.
10:16 rhamby a quick not about using psql \copy with tsv files if you use \coopy with tabs you'll need to use the \E flag when you define the '\t' delimiter
10:17 rhamby i.e. ELIMITER E'\t'
10:17 rhamby erg, DELIMITER E'\t'
10:17 rhamby which just says the delimiter is extended and not single character
10:18 rhamby and my fingers need a lot more caffeine /sigh
10:18 Dyrcona @coffee rhamby
10:18 * pinesol brews and pours a cup of Sumatra Lake Tawar, and sends it sliding down the bar to rhamby
10:18 rhamby mmmmm
10:18 Bmagic I wrote a script to migrate Evergreen -> Evergreen... linking it here if it might be helpful
10:19 Bmagic it does exactly that: makes a schema, and tons of inherited tables... automates all of those columns and maps old ID -> new ID
10:20 Bmagic https://github.com/mcoia/mobius_evergreen​/blob/master/Random/migrate_evergreen.pl
10:20 Bmagic angelo: It won't work for you "out of the box" - but maybe* you could use some of the ideas. It shows some of the things that rhamby and gmcharlt have mentioned about staging tables
10:21 rhamby yeah, if you're comfortable with postgres it's not hard but there will be an evergreen data learning curve
10:21 Bmagic that script will at least give you a full list of important tables. Something to start with hopefully
10:28 angelo i dont suppose there is an import script as part of migration tools lol
10:28 Bmagic looking deeper - that script is just one part of the equation. You will also need this one: https://github.com/mcoia/mobius_evergreen​/blob/master/Random/migrate_evergreen.sql
10:29 Bmagic It's not strictly a sql file - it's more of a crib sheet :)
10:30 rhamby angelo : it wouldn't be impossible to write such as script but there isn't at this point, if you write one feel to do a push request though :)
10:55 dbwells joined #evergreen
10:58 angelo would this accomplsh the import?
10:58 angelo http://docs.evergreen-ils.org/2.1/html/mig​rating_records_using_migration_tools.html
10:59 dbwells_ joined #evergreen
11:00 Bmagic angelo: you have several challenges. Those import instructions will get you close to importing the marc. You need to get all the rest of those files into the database. Into a staging table, where you can operate on the data and get them into their final destination production tables
11:02 rhamby angelo : it's going to be a substantial project
11:03 Bmagic angelo: what rhamby said. Sorry :) -  I wish there was a script to do this for you but there isn't (right now)
11:04 rhamby I can pretty easily see how to write a script to fire and forget how to do it with the output from migration-tools but it would be enough work that I wouldn't just hack it together on the side
11:06 angelo yeah im just not familiar enough with the data structure to write anything
11:08 Bmagic Too bad you don't have the original database or at least access to it. Those scripts I linked above would have worked pretty much out of the box. With a little shim though, they could still work. Just need to import the data from files instead of from a database
11:18 csharp angelo: how are your postgresql skills?
11:19 angelo never used it until now, but im familiar with MSSQL and MySQL if that matteres
11:19 csharp it does matter - just some differences in dialect
11:20 csharp angelo: is the Evergreen database up and running yet?
11:20 angelo yeah
11:21 csharp ok, then I would just focus on getting each file imported into staging tables, then you can get more familiar with Evergreen's data structures so you can map everything
11:21 Bmagic the way I see it: 1. Setup empty PG DB. 2. Create default EG schema from repo. 3. Shim migrate_evergreen.pl to read in files, including mrc (hopefully 901c is there). 4. Follow the steps in migrate_evergreen.sql. 5. Success!
11:21 csharp everyone who's speaking up about this is very familiar with the DB structure and can help you
11:22 Bmagic angelo: yep! We got you!
11:22 angelo thanks guys
11:22 angelo i got an empty staging table setup in postgre
11:22 angelo i copied the existing EGDB
11:23 Bmagic wha??! You have the DB?
11:23 angelo i was going to copy the tsv files into the staging db
11:23 angelo the one that came with the default install
11:24 Bmagic oh ok - the default EG db can be re-created at will from the EG repo
11:25 angelo ok
11:25 angelo can i copy the schema without the data into the staging table?
11:25 Bmagic not sure I am following - which schema?
11:26 angelo i suppose all of them, so i can import the data into a staging table to work with it and get it into prod
11:26 Bmagic This section of the Evergreen install instructions will create the EG database (and schemas and functions, etc)
11:26 Bmagic https://evergreen-ils.org/documentation/install/​README_3_3.html#_creating_the_evergreen_database
11:27 Bmagic that perl script up there will create a staging schema for you - and populate it with the data (from another EG DB, but we want to change that to "from files")
11:30 Bmagic Once you get those files (that you showed in your screen shot) - into the staging schema tables - you are half way there!
11:31 Bmagic FYI - Unlike MYSQL - Postgres has another path layer: schema. In PG there is a "database", and below that are "schemas" and then finally "tables" - MYSQL is: Database -> tables. So keep that in mind. There will always be a schema designation for your queries
11:32 angelo yeah i got that, where are you seeing the "from files" optioon?
11:32 angelo i dont see that in the help for eg_db_config
11:32 Bmagic The "from files" option is not coded :)
11:33 Bmagic that is the piece that you are missing
11:34 Bmagic I was thinking that the work I did with the migrate_evergreen.pl perl script could save you some time, and just edit that script to read your files instead of another database. It's not "simple" but with an hour or two I bet a perl programmer could get it functioning
11:35 angelo ok so i dumped the schemas into an empty db for staging, would the next step be to import the TSV data into that DB?
11:36 Bmagic alternatively, you could manually create the schema, and file by file, import them into pre-created staging tables, column by column
11:38 Bmagic angelo: yes, that's the next step - either make them by hand or make that script do it for you. How many files are we talking about?
11:38 nfBurton joined #evergreen
11:38 angelo looks like under 100
11:40 Bmagic I wouldn't want to make 100 tables by hand but more power to you! Does each TSV file contain a header row? With column names?
11:40 angelo i got the tables created already
11:40 angelo by using the dump
11:41 Bmagic tables that will accept each of these ~100 files?
11:41 sandbergja joined #evergreen
11:43 angelo yeah, its the same schema and tables as the default EG db
11:43 Bmagic the issue is: you don't want to import these files directly into the EG database production tables
11:43 angelo yeah im using a staging DB
11:43 Bmagic CREATE SCHEMA m_staging
11:44 Bmagic CREATE TABLE m_staging.file_name (l_col1 TEXT, l_col2 TEXT, l_col3 TEXT, l_col4 TEXT, ......);
11:45 Bmagic \copy m_staging.file_name (l_col1 TEXT, l_col2 TEXT, l_col3 TEXT, l_col4 TEXT, ......) from /filename
11:47 Bmagic back on that CREATE TABLE statement, I would make it "inherit" from the related production table so that you get all the related production columns in your child table - and then you get a nice ID->ID map created for you
11:47 sandbergja joined #evergreen
11:57 alynn26 joined #evergreen
12:00 angelo is there a way to disable constrains without removing them completely?
12:00 jihpringle joined #evergreen
12:00 Bmagic it sounds like you are wanting to import these files directly into the production tables? If you use the staging schema, you won't have that problem. One of the main reasons we import files like this into staging schemas
12:01 angelo i created a dump from the prod db to import the schemas without data into a staging db
12:01 angelo im trying to import the files into that staging db
12:01 Bmagic but yes - you can disable constraints without removing them. It will be table specific and IMO much more work than you need to do
12:01 angelo but it brought the contraints over with the dump
12:02 Bmagic I am confused - you have a pg_dump file that contains the default EG database? No data?
12:02 angelo yes
12:02 angelo just schemas and tables
12:03 Bmagic You don't need that. Let the Evergreen repository make the database for you
12:03 angelo wouldnt that still put the constraints in place?
12:04 Bmagic yes, and that's OK
12:04 angelo but when i try and import the TSV i get the constraint error
12:05 Bmagic sure, because you are importing the data directly into the production table right?
12:05 angelo no, into the table in the staging db i created
12:05 Bmagic please share your command that produces the error
12:06 dbwells joined #evergreen
12:06 angelo staging=# COPY actor.org_unit FROM '/home/evergreen/client/clien​t/items/actor.org_unit.tsv';
12:06 Bmagic actor.org_unit   <-- production table
12:06 angelo ERROR:  insert or update on table "org_unit" violates foreign key constraint "actor_org_unit_billing_address_fkey"
12:07 Bmagic you want m_staging.actor_org_unit
12:07 angelo ok when you said production i thought you meant the actual eg db
12:07 Bmagic sorry, that's what I mean by production table. Any table that is "For Evergreen production functionality"
12:08 angelo where did you get m_staging.actor_ord_unit
12:08 Bmagic you have to create it
12:08 angelo with the columns and everything
12:08 Bmagic I wrote the an example command for you above
12:08 Bmagic yep!
12:08 Bmagic a real pain
12:08 angelo ahh
12:08 Bmagic that's why I was recommending that script
12:08 angelo could i just remove the constraints in my staging DB?
12:09 Bmagic you could but if you knew the amount of constraints/triggers/business logic that you would be dealing with, you would choose to do what I am suggesting instead :)
12:11 Bmagic Admittedly it's lots of work either way. But the staging schema -> into production tables is the "Safer" and "sure" way to ensure data integrity while at the same time letting the Evergreen DB do what it's deisgned to do when things are INSERTED and UPDATED
12:13 angelo ok thanks bmagic, i need to sign off for a little, ill see what i come up with and report back
12:13 angelo thanks for everyone's help
12:13 Bmagic no problem! Good luck. We are usually here during business hours
12:13 angelo sounds good, im sure ill be back
12:14 Bmagic :)
12:14 angelo idk where you guys are located, but i need to go prep for the hurricane coming up the east coast of the US
12:14 Bmagic Oh man! That is arguably more important than Evergreen migration
12:15 angelo if only upper management thought so
12:15 angelo lol
12:15 angelo ttyl
12:24 mrisher joined #evergreen
12:25 mrisher joined #evergreen
12:27 rjackson_isl_hom joined #evergreen
12:31 Bmagic I have a question of my own. I just noticed that I have 973 entries in acq.edi_message for the exact same file with the exact same edi message
12:32 Bmagic should edi_import ignore already-processed files from the ftp server?
12:32 Bmagic edi_fetcher.pl rather
12:37 jvwoolf joined #evergreen
12:41 Bmagic it seems (from looking at Application::Acq::EDI::retrieve_core it does "dedupe"
12:49 Bmagic I found in my logs where it open-ils.cstore.direct.acq.​edi_message.id_list.atomic looks up a matching row in the database, and the return is "1 result(s)"
12:52 Bmagic therefore, I would expect to see another log message for "already retrieved" but I don't. Instead I see " 1 of 187 targets: ftp://server/filename"
12:55 Bmagic well, if I am reading these logs correctly (debug is not turne don) - I don't see the message "already retrieved.  Skipping" but that's because debug is not on
12:56 Bmagic so the question is: Will the edi_fetcher software create a new row in acq.edi_message for files that it doesn't process? Trying to find an explaination why I have 973 rows for the same file with the exact same edi message. Each with "processed" status
13:21 mantis1 joined #evergreen
13:22 csharp Bmagic: we had that happen early on - I can't remember offhand why though :-/
13:22 Bmagic hmmmm, still analyzing the logs
13:22 Bmagic it runs every half hour and every hour, it looks to see if the file exists. Finds that it DOESN'T and processes it again....
13:26 csharp is there an error listed for each edi_message?
13:26 stompro__ joined #evergreen
13:26 Bmagic no error
13:26 Bmagic all of them process just fine
13:29 csharp what's in the status column for those?
13:29 Bmagic processed
13:34 csharp https://git.evergreen-ils.org/?p=Evergreen.git​;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Ap​plication/Acq/EDI.pm;h=49feb960986c8ad870684cc​1bd16c2dd6b6d46d7;hb=refs/heads/master#l122 - that's the (master) query that finds already-processed/errored-out files
13:42 Bmagic yep!
13:42 Bmagic was just looking at that bit
13:42 Bmagic I see the related log messages for the atomic lookup
13:43 Bmagic and it responds with "0 results"
13:43 Bmagic open-ils.cstore open-ils.cstore.direct.acq.​edi_message.id_list.atomic {"+acqedi":{"host":"ftp://ftp.ingramcontent.co​m","in_dir":"outgoing","username":"XXXXXX","pa​ssword":"XXXXXX"},"remote_file":{"=":{"value":​["evergreen.lowercase","outgoing/XXXXXXXXXXXXX​X.EPR"],"transform":"evergreen.lowercase"}},"s​tatus":{"in":["processed","proc_error","trans_​error"]}},{"join":{"acqedi":{}},"limit":1}
13:44 Bmagic sanitized log entry there
13:44 Bmagic funny thing is that sometimes it responds with "1 result(s)"
13:44 Bmagic and then, of course, it doesn't process the file
13:45 Bmagic I wonder if the edi_fetcher.pl script is overlapping runtimes
13:45 Bmagic the CRONSCRIPT lockfile should keep that at bay though
13:50 Dyrcona We've had the fetcher and puller overlap and some vendors will not let one log in while the other is connected. Also, it does some stupid stuff when you have multiple accounts for the same vendor. It logs in once for each account even though the credentials and directory are the same.
13:51 Dyrcona We've also had 1 vendor out right block us for a few hours because that looks like an attack.
13:53 Bmagic yeah those sound sticky but the fetcher is running and logging into the FTP server and getting directory listings without issue in this case
13:54 Bmagic the fetcher is running right now... I don't see a LOCK file in /tmp - should it be there?
13:56 Bmagic the cron passes these switches: ./edi_fetcher.pl -v -d
13:56 Bmagic I couldn't find those switches in the code....
14:02 Dyrcona Bmagic: Are you talking about the fetcher or the pusher, and if the pusher, which one?
14:04 Dyrcona The fetcher and the old pusher use Cronscript.pm, so they'll recognize -v as "verbose" and -d as "debug." Doesn't mean that they do anything with those options, though.
14:14 Bmagic fetcher
14:33 * JBoyer announces a Developer Meeting beginning in approximately 30 minutes
14:35 jeffdavis JBoyer++
14:56 nfBurton joined #evergreen
14:57 terran joined #evergreen
14:59 JBoyer left #evergreen
15:00 JBoyer joined #evergreen
15:00 JBoyer Ah, love the keyboard shortcut that auto-closes the channel...
15:00 JBoyer Anyway.
15:01 * JBoyer bangs drum, shouts DEV MEETING
15:01 JBoyer #startmeeting 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/do​ku.php?id=dev:meetings:2020-08-04
15:01 pinesol Meeting started Tue Aug  4 15:01:10 2020 US/Eastern.  The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01 pinesol Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01 Topic for #evergreen is now  (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/dok​u.php?id=dev:meetings:2020-08-04)
15:01 pinesol The meeting name has been set to '2020_08_04___developer_meeting__agenda_​available_at_https___wiki_evergreen_ils_​org_doku_php_id_dev_meetings_2020_08_04'
15:01 JBoyer #topic Introductions
15:01 Topic for #evergreen is now Introductions (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/dok​u.php?id=dev:meetings:2020-08-04)
15:01 berick drums, drums in the deep
15:01 berick #info berick Bill Erickson, KCLS
15:01 JBoyer #info JBoyer = Jason Boyer, EOLI
15:01 Dyrcona #info Dyrcona = Jason Stephenson, CWMARS
15:01 gmcharlt #info gmcharlt = Galen Charlton, EOLI, part of the 3.6 release team
15:01 Bmagic #info Bmagic = Blake GH, MOBIUS
15:02 jeffdavis #info jeffdavis = Jeff Davis, BC Libraries Cooperative (Sitka)
15:02 mmorgan #info mmorgan = Michele Morgan, NOBLE
15:02 nfBurton #info cburton = Chris Burton, Niagara Falls Public Library
15:02 terran #info terran = Terran McCanna, PINES
15:03 JBoyer Folks can feel free to introduce themselves as they continue to come in
15:03 JBoyer #topic Action Items from Last Meeting
15:03 Topic for #evergreen is now Action Items from Last Meeting (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/dok​u.php?id=dev:meetings:2020-08-04)
15:03 JBoyer First up, now that I notice he may not be here, csharp was going to ask around PINES if lp 1821094 is ready or needs more testing, terran, do you know how that went?
15:04 pinesol Launchpad bug 1821094 in Evergreen 3.4 "Item status refresh after editing can get confusingly slow" [Medium,Confirmed] https://launchpad.net/bugs/1821094
15:04 terran I'm not sure
15:04 miker #info mike = Mike Rylander, EOLI
15:05 terran Elaine was fine with it
15:06 alynn26 info alynn26 = Lynn Floyd Evergreen Indiana
15:06 alynn26 #info alynn26 = Lynn Floyd Evergreen Indiana
15:07 JBoyer Ok, given the pullrequest tag and the comments we can assume it does the thing re: performance and it just needs a signoff and commiting.
15:07 JBoyer That's positive.
15:07 JBoyer Action item 2, berick, have you had an opportunity to consider EDI availability codes?
15:07 csharp #info csharp = Chris Sharp, GPLS
15:08 berick I have not, but I will
15:08 JBoyer Before I just add that back on berick, is anyone else working with EDI enough that they would like to take that on or assist?
15:08 _sandbergja joined #evergreen
15:09 csharp I can assist
15:09 JBoyer csharp++
15:09 _sandbergja #info _sandbergja is Jane Sandberg, Linn-Benton Community College
15:09 _sandbergja csharp++
15:09 csharp I'll need to refresh my knowledge of them, but yeah
15:09 _sandbergja berick++
15:09 JBoyer #action berick and csharp to consider approaches to lp 1627373
15:09 pinesol Launchpad bug 1627373 in Evergreen "Acq: We need to fully implement EDI availability codes" [Wishlist,New] https://launchpad.net/bugs/1627373
15:10 csharp I'll follow up with bug 1821094 too - that got dropped (like so many things)
15:10 pinesol Launchpad bug 1821094 in Evergreen 3.4 "Item status refresh after editing can get confusingly slow" [Medium,Confirmed] https://launchpad.net/bugs/1821094
15:11 JBoyer The last carried over action item, Dyrcona, did you have a chance to enter the LP bug about using jQuery in the OPAC? I didn't find it in a cursory search, but LP gonna LP.
15:11 Dyrcona Nope. I didn't get to it.
15:11 csharp "2020: I Didn't Get to It"
15:12 JBoyer Was the intent more than "we should just use it and throw everything else away?"
15:12 * csharp likes that better than "we're all in this together" and "in these unprecedented times"
15:12 JBoyer Because I imagine many of us can get behind that.
15:12 Dyrcona :)
15:12 berick csharp: :)
15:13 nfBurton The OPAC I'm targeting for 3.6 has jQuery always enabled
15:13 Dyrcona The intent was pretty much just replace Dojo with jQuery, and add jQueryUI for datepickers and things.
15:13 nfBurton34 joined #evergreen
15:13 Dyrcona And, yeah, with nfBurton's work, it may be obsolete anyway.
15:14 miker ISTM, since we added a fake $() eons ago, we might as well just make that the real thing
15:14 nfBurton34 Ugh IRC, but yeah there are a bunch of additions there
15:14 JBoyer That's what I was thinking. I wouldn't mind replacing all JS use with it, or at least requiring that it doesn't break when jQ is enabled.
15:14 JBoyer and nfBurton34 , Is the goal of the new OPAC that it's THE OPAC, or one of 2 options?
15:15 JBoyer miker +1 to that.
15:15 nfBurton34 THE OPAC, but giving people time to OPT in
15:15 nfBurton34 Or opt out?
15:15 nfBurton34 IDK it was suggested it is an 'option' for a version
15:15 nfBurton34 Kinda Beta-ing it out
15:16 csharp @band add THE OPAC
15:16 pinesol csharp: Band 'THE OPAC' added to list
15:16 JBoyer Ok, so at least optional for 3.6.
15:16 nfBurton34 Yes
15:16 csharp nfBurton34++
15:16 gmcharlt yeah, agreed - optional for 3.6, maybe default for 3.7
15:16 csharp +1
15:16 JBoyer In that case I'd say it's still worth pursuing jQ in the meantime since it does cause problems in the existing OPAC.
15:16 gmcharlt I think question is when do we want to deprecate the old OPAC - I'm inclined to say 3.7
15:17 nfBurton34 Yeah I had to change the load order of the jQuery
15:17 JBoyer gmcharlt, with the intent that it's then gone in ~3.8?
15:17 gmcharlt (which I realize is begging the question of whether to deprecate at all, but I think we should, in part so that we avoid a long-term committment that I don't believe we can colellectively make)
15:17 gmcharlt JBoyer: yeah, gone in 3.8
15:18 Bmagic +1 deprecation 3.7, gone 3.8
15:19 csharp gmcharlt++ # proper use of "begging the question"
15:19 csharp I'm good with the plan
15:19 jeffdavis Not necessarily opposed but that is an aggressive timeline for the main public-facing component of EG, esp considering many of us have probably done some degree of OPAC customization.
15:20 JBoyer Sounds like a plan then. We don't need to firm up the schedule today, but we should definitely look into making jQ work as expected.
15:20 nfBurton34 It does make navigation FAR easier
15:20 Bmagic jeffdavis: I have the same thoughts, though, I think that the OPAC that nfBurton34 has worked out is mostly what the customizations are trying to get to....
15:20 terran Should deprecation wait for 4.x?  (In PINES we will consider moving to it sooner though)
15:21 _sandbergja I would be interested in a longer timeline
15:21 _sandbergja We only upgrade once a year, so it would go from optional to gone in one upgrade cycle
15:21 _sandbergja And I don't think we're the only ones who upgrade annually...
15:21 csharp deprecation doesn't necessary mean removal - like the XUL client stuck around in a "deprecated" state over a few releases
15:21 csharp we also upgrade annually
15:22 jeffdavis I don't think we need to decide now, main thing is to get the new OPAC in the next release, right?
15:22 csharp maybe just delay removal?
15:22 JBoyer The timing plans can probably be hashed out once the new OPAC is even an option, my primary point was "do we still pursue replacing dojo with jQuery?" and it sounds like yes.
15:23 miker JBoyer: +1 to s/dojo/jquery/ in the opac
15:23 _sandbergja JBoyer: yes to dojo -> jquery
15:23 jeffdavis +1 to that (Overdrive API stuff will need to be de-Dojofied but that was always expected)
15:23 nfBurton34 jQuery > dojo
15:23 JBoyer So, does anyone feel strongly about taking that action item or will I do it after this meeting (lest I forget)
15:24 Dyrcona JBoyer: You can have it if you like. I couldn't get to it in 3 months, so....
15:25 JBoyer #action JBoyer to file LP bug about replacing Dojo with jQuery
15:26 JBoyer The three months in question does make it a bit more understandable though.
15:26 JBoyer Moving on!
15:26 JBoyer #topic OpenSRF Release Info
15:26 Topic for #evergreen is now OpenSRF Release Info (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/dok​u.php?id=dev:meetings:2020-08-04)
15:26 JBoyer Is there any OpenSRF release info to discuss?
15:26 gmcharlt short term, we have two patches that are enough to warrant cutting 3.2.1 IMO
15:27 miker ooo, I know what they are! :)
15:27 gmcharlt well, three, one's an easy merge
15:27 gmcharlt so I propose to take an action item to release 3.2.1 this month the same time as the Evergreen maint releases
15:28 JBoyer gmcharlt++
15:28 gmcharlt #action gmcharlt will cut OpenSRF 3.2.1
15:28 JBoyer #action gmcharlt to build an OpenSRF 3.2.1 release during the same timeframe as the Evergreen maintenance releases
15:28 JBoyer Oops, too wordy I suppose.
15:29 JBoyer left #evergreen
15:29 Bmagic words bad. " " good.
15:29 JBoyer joined #evergreen
15:29 gmcharlt come back, JBoyer! a double #action is not the end of the world!  ;)
15:29 JBoyer Sigh. I may need a new IRC client. :/
15:30 csharp gmcharlt++
15:30 JBoyer On to Evergreen!
15:30 JBoyer #topic Evergreen Release Info
15:30 Topic for #evergreen is now Evergreen Release Info (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/dok​u.php?id=dev:meetings:2020-08-04)
15:30 JBoyer Are we still on schedule for August 19th for the monthly point releases?
15:31 gmcharlt in ##eg-release I had proposed instead doing them on August 12 to avoid running into Feedback Fest
15:31 csharp I'm good with either
15:31 gmcharlt and I'm happy to continue with that plan, but want to confirm that other build team members are available
15:31 Bmagic I'm available for either date
15:31 Dyrcona What calendar is Feedback Fest on? I don't see it in Google.
15:32 JBoyer Dyrcona, currently it's been mentioned in a couple of emails and the dev meeting agenda. I need to see if I have / can get community calendar editing powers.
15:33 terran I can add it to the calendar - the schedule is here for now: https://wiki.evergreen-ils.org/do​ku.php?id=faqs:evergreen_roadmap
15:33 JBoyer terran++
15:33 Dyrcona I could add it to the development calendar. I don't think I can edit the others.
15:33 JBoyer I'm also +1 to moving it away from Feedback Fest
15:33 gmcharlt I've added it to the community calendar - is it showing up for folks now?
15:34 terran Now it's on there twice :)
15:34 gmcharlt I'll remove the one I added :)
15:34 Dyrcona I wonder if doing the releases after feedback fest is better than before?
15:34 terran I'll add bug squashing week if it's not on there yet too
15:34 gmcharlt terran++
15:34 JBoyer I'd feel that way more about bugsquashing week, given their difference in focus.
15:35 gmcharlt Dyrcona: feedback fest is more focused on enhancements rather than bugfixes; i.e., I agree with JBoyer
15:36 Dyrcona OK. Fine with me. I was just wondering.
15:37 _sandbergja I'd prefer August 12th for point releases, so I can actually participate in feedback fest. :-)
15:37 _sandbergja And I am available then
15:37 JBoyer I don't think that's a voting matter, but are enough build team members available to shift it?
15:37 csharp sounds like it
15:38 gmcharlt agreed
15:38 JBoyer Huzaah.
15:38 JBoyer #info the next Evergreen Maintenance Release date is August 12th
15:38 JBoyer left #evergreen
15:38 JBoyer joined #evergreen
15:39 JBoyer So, Any other Evergreen release news?
15:40 JBoyer Well, since I can't check my scrollback these may as well go in the minutes
15:40 mantis1 left #evergreen
15:40 JBoyer #info Feedback Fest is August 17 - August 21
15:41 JBoyer #info Bug Squashing Week is September 21 - September 25
15:41 csharp also remember http://irc.evergreen-ils.org/evergreen/2020-08-04
15:41 gmcharlt only other update is that mmorgan and I (and the other members of the RM team) will be sending out a summary on Monday
15:41 JBoyer csharp++
15:41 JBoyer gmcharlt++ mmorgan++
15:42 JBoyer #topic Hatch Release info
15:42 Topic for #evergreen is now Hatch Release info (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/dok​u.php?id=dev:meetings:2020-08-04)
15:42 berick no recent Hatch changes
15:43 JBoyer It'll be nice when OpenJDK has all of the necessary parts to make it a single file install, but until then I don't suppose a lot needs to change.
15:43 JBoyer That said, Is 3.6 maybe a good time to pull the band-aid on Hatch Local Storage, or should that go on as is for a while longer?
15:44 JBoyer (In general, not trying to make more work for berick. ;) )
15:44 berick yeah we should remove that option from the config UI in the webstaff -- the bandaid has in essence been pulled already
15:44 terran +1
15:44 csharp +1000
15:44 mmorgan +1
15:44 terran We still have staff that we find out are using it
15:45 mmorgan Endless cause of confusion there.
15:45 csharp yeah, it's a pain to troubleshoot
15:45 berick i'll open a LP
15:45 JBoyer berick++
15:45 csharp berick++
15:45 JBoyer #action berick to open LP bug re: the removal of Hatch Local Storage in web staff client
15:46 JBoyer Onward!
15:46 JBoyer #topic New Business
15:46 Topic for #evergreen is now New Business (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/dok​u.php?id=dev:meetings:2020-08-04)
15:46 csharp I have something tangentially dev-related
15:47 JBoyer csharp, go for it
15:47 csharp GPLS is decommissioning our email list server, and we have five Evergreen-related lists that need to be migrated to the Evergreen community list server (open-ils-general, open-ils-dev, open-ils-docs & the commits lists)
15:48 csharp so look for communications from me about when that will happen over the next couple of weeks
15:48 gmcharlt csharp++
15:48 _sandbergja csharp++
15:48 JBoyer csharp++
15:48 rhamby csharp++
15:49 csharp we've been talking about that for nearly 10 years, so good to finally see it happen :-)
15:50 JBoyer The new business entry on the agenda was mine; I wanted to remind people about LP 1703411 . Some good code that we needed came from it, but not SASL authentication, which we still need.
15:50 pinesol Launchpad bug 1703411 in OpenSRF "OpenSRF: XMPP Non-SASL auth is being phased out" [Medium,Confirmed] https://launchpad.net/bugs/1703411
15:51 JBoyer I have the most bare-bones bit of the perl half of this working, so perl services can login via the PLAIN mechanism, but I may need some help with the C portions, and we should really aim for SCRAM support so we can remove "Turn off all of the security features" from our install instructions.
15:52 JBoyer I don't have a working branch out there yet (just banging on it on a local VM) but does this sound like the sort of thing anyone is interested in poking at?
15:52 gmcharlt I would be
15:53 JBoyer gmcharlt++
15:53 JBoyer Obviously I'll have to get what I have to date in a collab wip branch, which I'll try to do asap.
15:53 berick i'm definitely following along.
15:53 JBoyer berick++
15:53 miker me too
15:54 Bmagic seems like it's time
15:54 JBoyer I'll try to remember to mention it in here once it's up, and FYI, at present it's really not commit-worthy. ;)
15:55 JBoyer So, we move on to
15:55 JBoyer #topic Feedback for new features
15:55 Topic for #evergreen is now Feedback for new features (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/dok​u.php?id=dev:meetings:2020-08-04)
15:55 JBoyer berick, you've got the first one.
15:55 berick hi..
15:55 berick heads up we have a new tag angularcatblocker
15:55 berick any angular staff cat issues that prevent its use in production should get this tag
15:56 berick or new regressions, etc.
15:56 berick i'm tracking them closely
15:56 berick also just curious if anyone has any strong feeling either way for making it the defult in 3.6 as it's one of the earlier-is-better things
15:57 berick if we want to merge it
15:57 Bmagic I like the launchpad tag. +1 3.6
15:57 gmcharlt I'm inclined to merge it sooner rather than later, in particular, before feedback fest
15:58 berick i saw the comment re: removing the org setting, gmcharlt
15:58 berick i'll look at that
15:58 gmcharlt and specifically before feedback fest so that /all/ test systems set up for FF are implicitly testing it as well
15:59 JBoyer That does make sense, should help with the slightly shorter release cycle also.
15:59 _sandbergja +1 merging it soon for 3.6
16:00 JBoyer berick, do you want an action item for that or would you like someone else to give it another look first?
16:00 _sandbergja As a side note, it will be really nice to have those broadcast messages in the Angular client
16:01 berick JBoyer: i have one thing to fix (removing org setting), but other than that I thing someone else would need to volunteer for testing the branch
16:01 _sandbergja I can volunteer
16:01 berick thanks _sandbergja++
16:01 JBoyer _sandbergja++
16:02 JBoyer #action _sandbergja to do some testing on the Angular staff catalog branch with the aim of merging pre-feedback fest
16:03 JBoyer And I suppose berick's second point on the agenda is fairly closely related, given the timing?
16:03 berick right, Ang 9 (or 10) bug 1864371
16:03 pinesol Launchpad bug 1864371 in Evergreen "Upgrade to Angular 9" [Undecided,Confirmed] https://launchpad.net/bugs/1864371
16:03 gmcharlt yeah
16:03 JBoyer #topic Angular 9 /10 update
16:03 Topic for #evergreen is now Angular 9 /10 update (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/dok​u.php?id=dev:meetings:2020-08-04)
16:03 gmcharlt I've looked over the branch and am in favor of going all the way to Angular 10, and doing so ASAP
16:04 JBoyer I just realized these minutes are going to be a bit sparse on what it is we;re actually talking about.
16:04 Dyrcona The minutes usually are sparse, but there's a link for the full log.
16:04 gmcharlt in part, selfishly, because I'd prefer to rebase the angular acq search branch at a predictable time to convert it from using ngbTabset to ngbNav
16:05 berick gmcharlt: *nod*
16:05 berick well, I can rebase the working branch and give it another once over this week
16:05 gmcharlt and I'd happily take on putting the 1864371 branch through its paces
16:05 berick even better! :)
16:05 _sandbergja berick: gmcharlt: from glancing over that branch, it looks like it's not as impactful as Angular 8 adding static to all those ViewChilds
16:05 berick _sandbergja: definitely not
16:05 _sandbergja Yes!
16:06 gmcharlt I also glanced over the ng-bootstrap and bootstrap release notes, and bumping up up to 7.0.0 and 4.5.1 respectively doesn't look like it will be too painful
16:06 berick and the tab/nav changes are encouraged but not strictly required yet
16:06 berick hold my last thought, i haven't tested latest bootstrap
16:06 berick pretty sure it's still just deprecated, though
16:06 _sandbergja I can take a look after you, gmcharlt
16:06 gmcharlt _sandbergja++
16:07 berick gmcharlt++ _sandbergja++
16:07 JBoyer gmcharlt++ _sandbergja++ berick++
16:07 _sandbergja it would be nice to be able to rebase the course materials work on Angular 10 too
16:07 _sandbergja :-)
16:07 JBoyer Would the aim for that also be pre-FF week?
16:07 _sandbergja That would be ideal, I think
16:07 berick +1 to pre-FF
16:08 _sandbergja So, when reviewing old PRs, we can easily check Angular 10 compatibility
16:08 gmcharlt yeah
16:09 JBoyer #action gmcharlt , _sandbergja , and berick will work to test and merge lp 1864371 to use Angular 10 in the staff client before Feedback Fest week.
16:09 pinesol Launchpad bug 1864371 in Evergreen "Upgrade to Angular 9" [Undecided,Confirmed] https://launchpad.net/bugs/1864371
16:09 JBoyer That sounds great.
16:09 JBoyer Given it's standing as a, uh, standing item, we can skip over discussionneeded for now.
16:10 JBoyer #topic Curbside pickup discussion
16:10 Topic for #evergreen is now Curbside pickup discussion (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/dok​u.php?id=dev:meetings:2020-08-04)
16:10 gmcharlt so, this one is mostly just a plea for reviewer and committer attention, especially now that we have some libraries using it in production
16:11 gmcharlt not much to say otherwise unless there are questions
16:11 JBoyer lp 1879983 for those reading the logs later
16:11 pinesol Launchpad bug 1879983 in Evergreen "Curbside Pickup" [Wishlist,Confirmed] https://launchpad.net/bugs/1879983
16:12 mmorgan Is the test server with that code still available?
16:13 gmcharlt mmorgan: as it happens, yeah, curbside.evergreencatalog.com is still up
16:13 jeffdavis we're testing curbside here, will share any feedback via LP
16:13 gmcharlt only thing it would need is refreshing it to the latest-and-greatest
16:13 gmcharlt jeffdavis++
16:14 JBoyer Any other questions or curbside discussion?
16:14 * mmorgan will try and devote some time to looking at curbside.
16:15 gmcharlt mmorgan++
16:15 JBoyer mmorgan++
16:15 JBoyer #topic Angular Acquisitions Search (LP 1850547 )
16:15 Topic for #evergreen is now Angular Acquisitions Search (LP 1850547 ) (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/dok​u.php?id=dev:meetings:2020-08-04)
16:15 pinesol Launchpad bug 1850547 in Evergreen "Angular Acquisitions Sprint 3: Acquisitions Search" [Wishlist,Confirmed] https://launchpad.net/bugs/1850547
16:15 JBoyer I assume this is a similar request for eyes.
16:16 gmcharlt so, same deal as the curbside branch, but with a specific request that some of the angular core component changes be looked at (and could be merged independently)
16:16 berick i plan to review, but I'll wait until after Ang 10 rebase
16:16 gmcharlt there are a bunch of them, including new eg-file-reader and eg-interval-input components and changes to org-select, date-select, eg-grid, and eg-combobox
16:16 gmcharlt and even just eyeballing would be useful
16:17 gmcharlt I will plan on rebasing that branch ASAP once the angular 10 branch is in
16:17 * berick nods
16:18 gmcharlt but otherwise, I've nothing else specific to sa
16:18 gmcharlt y
16:19 JBoyer I'll also try to poke around at those two.
16:19 JBoyer #topic Patron API (LP 1887196)
16:19 Topic for #evergreen is now Patron API (LP 1887196) (Meeting topic: 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/dok​u.php?id=dev:meetings:2020-08-04)
16:19 pinesol Launchpad bug 1887196 in Evergreen "Support PatronAPI-compatible auth via RemoteAuth" [Wishlist,New] https://launchpad.net/bugs/1887196
16:19 JBoyer jeffdavis, take it away
16:20 jeffdavis I'm hoping to add support for PatronAPI, which is a patron authentication method used by III that a lot of vendors support.
16:20 jeffdavis But I know some countries have strange/confusing laws around copyrightability of APIs so I'm not sure if there are issues adding a PatronAPI-compatible API to EG?
16:21 gmcharlt IIRC, there's at least one shim running around that adds PatronAPI support to Evergreen, that TMK nobody's challenged
16:21 stompro_ joined #evergreen
16:22 JBoyer I don't recall if the Google / Oracle fight is over, but given that we've so little money to take I'd assume that's not an issue.
16:22 JBoyer Unless Oracle buys III, in which case all bets are off. ;)
16:24 jeffdavis It seems like a bit of a grey area and it would be adding the API to EG itself (rather than an external shim), so I just wanted to flag it before anything gets committed. If we don't think there's an issue then that's good with me.
16:24 JBoyer Of note to potential testers, it requires LP 1850992 also, which would also be a great addition.
16:24 pinesol Launchpad bug 1850992 in Evergreen "Use RemoteAuth for EZProxy authentication" [Wishlist,New] https://launchpad.net/bugs/1850992 - Assigned to Jane Sandberg (sandbej)
16:25 Stompro joined #evergreen
16:26 JBoyer Any more discussion for jeffdavis about PatronAPI? I've let things run a bit longer than expected today.
16:26 gmcharlt there is also this: http://bricestacey.com/2009/06/03/Configu​re-EZProxy-to-Authenticate-Against-Voyage​r-ILS-for-WorldCat-Local-Navigator.html
16:27 gmcharlt so, not adding PatronAPI support to Voyager, but code that provides its as an endpoint
16:28 Stompro joined #evergreen
16:29 gmcharlt but I've nothing more to say
16:29 jeffdavis that's a handy link, thanks
16:29 JBoyer That's the first I've seen of the output of PatronAPI, I'm a little bummed that's becoming a defacto standard.
16:30 JBoyer Everyone is encouraged to check out LP bugs that have have pullrequests but need signoffs, and I don't believe we have any qa failing bugs at present.
16:30 JBoyer Have a great day eveyone.
16:30 JBoyer #endmeeting
16:30 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration
16:30 pinesol Meeting ended Tue Aug  4 16:30:55 2020 US/Eastern.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:30 pinesol Minutes:        http://evergreen-ils.org/meetings/evergr​een/2020/evergreen.2020-08-04-15.01.html
16:30 pinesol Minutes (text): http://evergreen-ils.org/meetings/evergr​een/2020/evergreen.2020-08-04-15.01.txt
16:30 pinesol Log:            http://evergreen-ils.org/meetings/evergree​n/2020/evergreen.2020-08-04-15.01.log.html
16:31 gmcharlt JBoyer++
16:31 jeffdavis JBoyer++
16:31 berick JBoyer++
16:31 mmorgan JBoyer++
16:31 terran JBoyer++
16:32 phasefx_ JBoyer++
16:32 Dyrcona JBoyer++
16:32 JBoyer Hopefully if I don't leave the channel every randomly next meeting it won't take 90 minutes...
16:32 Bmagic JBoyer++
16:33 Dyrcona Well, it has been 3 months since the previous meeting, so 30 minutes/month ain't that bad.
16:33 JBoyer I can deal with ain't that bad.
16:35 csharp JBoyer++
16:39 Bmagic reminds me of this https://www.youtube.com/watch?v=VakU20APPdw
16:40 JBoyer Bmagic++
16:40 Bmagic "That ain't bad" always brings Jack Nicholson to mind.
16:44 Dyrcona "Ain't That Pretty At All"
17:36 mmorgan left #evergreen
17:38 sandbergja_ joined #evergreen
18:01 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
18:11 dbwells_ joined #evergreen
18:20 sandbergja_ joined #evergreen
18:57 RBecker joined #evergreen
18:57 csharp joined #evergreen
19:29 sandbergja_ joined #evergreen
20:15 Stompro joined #evergreen
23:24 sandbergja_ joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat