| Time |
Nick |
Message |
| 07:11 |
|
collum joined #evergreen |
| 07:12 |
|
collum joined #evergreen |
| 07:58 |
|
BDorsey joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 09:13 |
|
dguarrac joined #evergreen |
| 10:13 |
|
Dyrcona joined #evergreen |
| 10:17 |
* Dyrcona |
has to switch Internet. |
| 10:20 |
|
Dyrcona joined #evergreen |
| 10:33 |
|
sandbergja joined #evergreen |
| 10:36 |
sandbergja |
Bmagic Dyrcona: okay if I backport abneiman's release notes to rel_3_12, rel_3_13, and rel_3_14? |
| 10:36 |
Dyrcona |
sandbergja: I did 3.14 already. Feel free to do the other two. |
| 10:39 |
Dyrcona |
I have some things to add to the 3.14 release notes, then I was going to start building it. |
| 10:40 |
Dyrcona |
I'm working in the Salem, Mass. public library's reference room with a lovely view of Maxwell(?) St. Part of me thinks I should tell them that the Evergreen 3.14.0 release is being made in the library. They use Evergreen. They're members of NOBLE. |
| 10:41 |
berick |
Dyrcona++ |
| 10:41 |
berick |
love it |
| 10:43 |
Dyrcona |
sandbergja: I wasn't going to port the 3.12.8 or 3.13.5 release notes to 3.14, but I guess that's OK. |
| 10:43 |
sandbergja |
oh, whooops. |
| 10:44 |
sandbergja |
Dyrcona: should I skip the 3.13 ones then? |
| 10:44 |
Dyrcona |
sandbergja: Might as well do them, too, just to be consistent. :) |
| 10:46 |
sandbergja |
Okay, pushed, now I'm out of your branch :-) |
| 10:46 |
Dyrcona |
sandbergja++ |
| 10:46 |
* Dyrcona |
looks up how to use the release notes from commit messages script again. |
| 10:47 |
sandbergja |
I'll start building 3.12.8. |
| 10:51 |
Dyrcona |
Of course the script is in docs/tools and not build/tools. I always look for it first in the wrong place. Maybe I'll remember after this time? |
| 11:09 |
Dyrcona |
Huh..... `echo : > file` doesn't do on Linux what it does on FreeBSD. |
| 11:17 |
Dyrcona |
OK. Looks like Bmagic did some of that stuff already. |
| 11:18 |
|
collum joined #evergreen |
| 11:27 |
pinesol |
News from commits: docs: Addit 3.14 to site.yml <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=9ebe8b3529c9502526ba0cb18a7ccd6d523eef67> |
| 11:27 |
pinesol |
News from commits: docs: Empty out docs/RELEASE_NOTES_NEXT/miscellaneous.adoc <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=3574e2b3a8d71583850374423339bd00f41340cc> |
| 11:27 |
pinesol |
News from commits: docs: Update release notes for 3.14.0 <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=4126eb52988a926d7d8742c03db2363756fc1786> |
| 11:37 |
|
jihpringle joined #evergreen |
| 11:46 |
Dyrcona |
There's an error in the server_upgrade.adoc that should be fixed after the releases are made. It says Debian Bullseye is 11.0. It should be 12.0. |
| 11:49 |
Dyrcona |
Grr. Debian Bookworm it says is 11 and it should be 12. Bullseye is 11. |
| 11:50 |
|
cbrown joined #evergreen |
| 12:20 |
Dyrcona |
Our message about missing full text search configuration could use an update. It says the latest PostgreSQL version is "(96)". |
| 12:25 |
|
jihpringle joined #evergreen |
| 12:27 |
jeffdavis |
Only 79 more releases until that statement is valid, maybe we should just leave it in. |
| 12:27 |
Dyrcona |
Heh. |
| 12:28 |
* Dyrcona |
tests the 3.14.0 db upgrade script because it needed to be modified. |
| 12:29 |
Dyrcona |
Works for me! |
| 12:35 |
Bmagic |
are the branches ready for build (I'm mostly asking about "my" branch rel_3_13) ? |
| 12:35 |
Dyrcona |
Bmagic: I believe so. |
| 12:35 |
Dyrcona |
I'm almost done with 3.14. |
| 12:35 |
Bmagic |
ok! I'll get crackin |
| 12:36 |
Dyrcona |
I guess if the xtb file has no changes since the -rc, then there's nothing to commit, eh? |
| 12:37 |
Bmagic |
theoretically, the phase between beta and final, there would be new translations for us to include in the build |
| 12:38 |
Dyrcona |
Well, there were apparently changes on Lp, but the file from POEditor was the same as last time. |
| 12:38 |
Bmagic |
if the translation community were hip to the new strings published on POEditor and LP |
| 12:38 |
|
collum joined #evergreen |
| 12:39 |
Bmagic |
no change, then no change. Though, POEditor can emit a different xtb file depending on the "tags" that you choose in their web export UI |
| 12:39 |
Dyrcona |
Well, if anything is missing, it will get picked up with .1, but I'm pretty sure that I used the correct tags. |
| 12:40 |
Bmagic |
When dealing with the new* release (basically main) - then I'd probably elect to export the "all" xtb |
| 12:40 |
Dyrcona |
We need to simplify this, like last year. :) |
| 12:40 |
Bmagic |
when dealing with older branches, then the strings for that version should be all you want. So in my case, I'm going to download the xtb for 3_13, and see if that's different than what we have in the repo |
| 12:41 |
|
collum joined #evergreen |
| 12:41 |
Dyrcona |
The RC was also just last week, so maybe nothing changed? |
| 12:41 |
Bmagic |
I'll confirm, just a sec |
| 12:42 |
Dyrcona |
I did "ALL" with tags rel_3_14 and rel_3_14_0, which I think is correct. |
| 12:56 |
Bmagic |
ok, when I export "All" plus the two tags rel_3_14 and rel_3_14_0, the result is identical to what we have. But if you don't add those tags, and download the full file, we have a lot of new things. So, I guess those are translated strings that 3.14 doesn't have and doesn't need? |
| 12:57 |
|
sandbergja joined #evergreen |
| 12:57 |
Dyrcona |
IDK. |
| 12:57 |
pinesol |
News from commits: Forward-port 3.12.7-3.12.8 upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=6bc0f2ade724e4e1e083465efc33526edc3d2e59> |
| 12:58 |
Dyrcona |
It should be the same as main at this point. |
| 12:58 |
sandbergja |
Bmagic (and anybody else who might wish to test it): 3.12.8 is done building, tarball and other build artifacts are available at https://drive.google.com/drive/folders/19pGPywtrTbohBre-EBpQcoQptHXb6Bgu?usp=sharing |
| 12:58 |
Dyrcona |
I don't really understand our translation process. I think it all needs to be simplified. |
| 12:58 |
Dyrcona |
sandbergja++ |
| 12:59 |
Dyrcona |
3.41.0 is also done. I just copied the files to lupin. |
| 13:00 |
Bmagic |
I think we're doing it right. Comparing the full download xtb file against main, the mystery is solving |
| 13:01 |
Dyrcona |
sandbergja: I'm downloading the 3.12.8 files. |
| 13:01 |
sandbergja |
Dyrcona++ |
| 13:01 |
Bmagic |
There is a step where we export the Evergreen file and import it into POEditor (this step is done for us automatically by LP for the older translation components, but it's still done manualy for POE (for now)). And when we import our file into POE, we specify the branch of evergreen from which it was exported |
| 13:02 |
Dyrcona |
I'd like to move it all to POEditor and have the git integration set up. |
| 13:03 |
Dyrcona |
C'mon Google, you can zip 100MB of files.... |
| 13:03 |
Bmagic |
This informs POE of any new* strings that may or may not have been introduced on that branch of Evergreen, and those strings are tagged as such. So when we come back to download the translations after the translators have translated stuff, we will only want the strings for the same version of Evergreen that we're compiling |
| 13:03 |
Dyrcona |
Bmagic: I get all that. I don't get why it is all still so complicated. :) |
| 13:04 |
Dyrcona |
Maybe Google can't zip those files.... :/ |
| 13:04 |
Bmagic |
What's complicated, I think, is the concept of tags. We're using POE's tagging system for "branches" to mirror our git branch naming convention. Once I wrap my head around that, it starts making sense |
| 13:05 |
Dyrcona |
The git integration should eliminate the need to import into POEditor, but what do I know? I just know that some other projects don't jump through all these hoops for translations. |
| 13:05 |
Bmagic |
LP is "easier" because the Evergreen->LP is automatic. And the LP->Evergreen is "kind of" automatic, we have to bzr pull and run some custom code to reconcile the lp bzr directory against the Evergreen repo |
| 13:06 |
Dyrcona |
OK. So, I do mostly understand it. I just don't like it. :P |
| 13:06 |
Bmagic |
No, I think you're exactly right. The git integration will make the Evergreen->POE step auto |
| 13:06 |
Dyrcona |
I make mistakes sometimes. This multistep process invites error. |
| 13:07 |
Bmagic |
I think we all agree with you |
| 13:07 |
|
sandbergja joined #evergreen |
| 13:08 |
Dyrcona |
I tested this all yesterday, minus the tarball part, so I think I'm just going to get the files in place once you're ready. I'll put sandbergja's files on the server and put them in place at the same time. |
| 13:09 |
|
collum joined #evergreen |
| 13:12 |
Dyrcona |
That's going to take a couple of minutes over the cell network. |
| 13:17 |
Dyrcona |
Wonder if I've hit a cap on my unlimited plan. Seems like they're slowing me down. |
| 13:28 |
pinesol |
News from commits: Foward port 3.13.14-3.14.0 upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=b0afb880ec5fe763e10719f7ac020e9ba12f5c2a> |
| 13:29 |
Dyrcona |
remote: postdrop: warning: uid=1006: File too large |
| 13:29 |
Dyrcona |
remote: sendmail: warning: mail_stream_cleanup: close error |
| 13:29 |
Dyrcona |
Never seen that from git push before. |
| 13:31 |
Dyrcona |
It showed up when I pushed to rel_3_14 and rtags/rel_3_14_0 |
| 13:32 |
Dyrcona |
Postfix says the email to notify about the push is too large, I guess. |
| 13:33 |
Dyrcona |
Bet it's the po files update. 649 files changed. |
| 13:35 |
Dyrcona |
I'm going to grab a bite to eat. I'll be back. |
| 14:11 |
|
jihpringle joined #evergreen |
| 14:34 |
|
jihpringle joined #evergreen |
| 14:59 |
|
Dyrcona joined #evergreen |
| 15:05 |
|
jihpringle joined #evergreen |
| 15:07 |
Dyrcona |
Well, I'm back. |
| 15:10 |
Dyrcona |
Oh man... typos in commit messages. I hate when I do that. I just noticed it from earlier. |
| 15:15 |
Dyrcona |
Bmagic: Where do we stand 3.13.5? |
| 15:27 |
Bmagic |
nothing to report yet |
| 15:28 |
Dyrcona |
ok |
| 15:29 |
|
cbrown_ joined #evergreen |
| 15:32 |
Bmagic |
my job is getting in the way of my work |
| 15:39 |
Dyrcona |
Heh. |
| 15:39 |
|
cbrown joined #evergreen |
| 15:43 |
* Dyrcona |
woudn't know anything about that. |
| 16:14 |
Bmagic |
OMG dojo.tgz bites me again |
| 16:14 |
Bmagic |
92% ALL DAY |
| 16:18 |
Dyrcona |
Bmagic: I keep a set of files around that I copy to my VMs, especially for building. I keep a ~/release directory in it with a copy of dojo.tgz. |
| 16:18 |
Bmagic |
yep, I'm about to (finally) record this in my personal steps so I don't have to start over when this happens |
| 16:18 |
Dyrcona |
Do you want me to put it somewhere you can download it? |
| 16:18 |
Bmagic |
I have it |
| 16:19 |
Dyrcona |
OK. |
| 16:19 |
Bmagic |
It's just something about the make release process that invokes wget, that fails at 92% (when the file doesn't already exist in ../dojo.tgz) |
| 16:19 |
Bmagic |
so dumb |
| 16:19 |
Dyrcona |
It won't invoke wget if dojo.tgz is already there. |
| 16:19 |
Bmagic |
that's what I mean |
| 16:20 |
Dyrcona |
OK. |
| 16:20 |
Bmagic |
"(when the file doesn't already exist in ../dojo.tgz)" |
| 16:20 |
Dyrcona |
Oh. right. :) |
| 16:21 |
Bmagic |
something about the Agent string that wget uses maybe? Our community web server barfs when downloading that file with wget, but has no problem when using FF or Chrome |
| 16:21 |
Dyrcona |
Could be. It's behind a State of Georgia firewall. |
| 16:22 |
Bmagic |
might be IDS/IDP |
| 16:22 |
Bmagic |
I bet it's that, Agent string is getting inspected and the file stream get's a TCP RST packet sent to both hosts to kill the connection and it takes the IDP the amount of time to inject those packets at around the 92% mark |
| 16:25 |
Dyrcona |
Could be. We could try switching to curl to see what happens. |
| 16:25 |
Bmagic |
I'm playing with it |
| 16:25 |
Bmagic |
wget --user-agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0" http://evergreen-ils.org/downloads/dojo.tgz -O dojo.tgz |
| 16:25 |
Bmagic |
still dies at 92% |
| 16:25 |
Dyrcona |
I gotta move. It's too hot where I'm sitting. |
| 16:25 |
Bmagic |
sounds good |
| 16:27 |
Bmagic |
curl worked |
| 16:30 |
Dyrcona |
There are ways other than the user-agent to detect a "browser." |
| 16:32 |
Dyrcona |
Also, if you're going to spoof the user agent, you should use one that's more up to date. :) |
| 16:32 |
Bmagic |
I think I'm going to make a bug report for it |
| 16:32 |
Dyrcona |
Sounds good. We can just push it with minimal fuss since it only affects devs. |
| 16:33 |
Bmagic |
annoying when it strikes |
| 16:33 |
Bmagic |
ok, we have tarball |
| 16:33 |
Dyrcona |
Cool. |
| 16:33 |
Bmagic |
https://evergreen-ils.org/downloads/Evergreen-ILS-3.13.5.tar.gz |
| 16:34 |
Dyrcona |
Can you upload it to Lupin, or do you ... |
| 16:34 |
Bmagic |
you have one for me to test? |
| 16:35 |
Dyrcona |
https://evergreen-ils.org/downloads/Evergreen-ILS-3.14.0.tar.gz |
| 16:36 |
Bmagic |
sweet, testing |
| 16:39 |
Dyrcona |
Hmm... I should see if I have a clean vm on my laptop. If not, I should probably start a new one. The one I was going to use is "contaminated" with the 3.14 prerequisites. |
| 16:40 |
Bmagic |
we do have the handy dandy docker tarball builder |
| 16:40 |
Dyrcona |
I'd have to install docker and learn it just enough. I've got a got a clean Debian 12 vm. |
| 16:40 |
Bmagic |
groovy/tubular/radical |
| 16:41 |
Dyrcona |
Looks like I haven't even installed OpenSRF, yet. |
| 16:49 |
Bmagic |
far out |
| 16:59 |
Dyrcona |
Heh. forgot about that max_client_sessions variable in ejabberd.yml again. |
| 17:01 |
Dyrcona |
Now, the vm appears to be stuck in some limbo state. |
| 17:01 |
|
mmorgan left #evergreen |
| 17:02 |
Dyrcona |
Had to force it off. |
| 17:07 |
|
sandbergja joined #evergreen |
| 17:08 |
sandbergja |
Bmagic: fyi, I wrote down the steps that I use to test a tarball using your docker magic on the wiki: https://wiki.evergreen-ils.org/doku.php?id=qa:testing_a_tarball&s[]=testing&s[]=tarball |
| 17:08 |
Bmagic |
sandbergja++ |
| 17:09 |
sandbergja |
I'm going to try it for the 3.13.5 tarball to see if I wrote them down correctly hahaha |
| 17:10 |
Bmagic |
heck yeah |
| 17:12 |
sandbergja |
found some of my typos already whooo! |
| 17:25 |
Dyrcona |
typos-- |
| 17:26 |
Dyrcona |
Dang. forgot autogen.sh before running the tests and the usual suspects are failing... |
| 17:31 |
Dyrcona |
Bmagic: The 3.13.5 tarball gets a thumbs up from me. |
| 17:31 |
Dyrcona |
I have to pick my daughter up and won't be home for a couple of hours, so I an update the downloads page then. |
| 17:31 |
Bmagic |
same for 3.14.0 from me, though, for fun, I'm running some of the automated test |
| 17:32 |
Dyrcona |
I always run the tests. |
| 17:32 |
Bmagic |
all of em? nightwatch, headless firefox, etc? |
| 17:32 |
Dyrcona |
Not always ALL of them. I often skip nightwatch. |
| 17:33 |
Dyrcona |
Anyway, I got to go. |
| 17:33 |
Bmagic |
lata |
| 17:33 |
Dyrcona |
the cover uploader is still failing for me. That one is picky. |
| 17:33 |
Dyrcona |
I'll catch y'all tomorrow probably. |
| 17:33 |
sandbergja |
Dyrcona++ |
| 17:33 |
Bmagic |
holla |
| 17:34 |
Bmagic |
sandbergja: Mine is failing live_t/0824.item_import_defaults.pg "Should have a row with a NULL barcode and call number, auto-circ mod of BOOK" |
| 17:35 |
sandbergja |
hmmmm, I'll take a look |
| 17:43 |
sandbergja |
Bmagic: it is passing for me in the 3.13.5 tarball docker with classic concerto data set. What version of the code do you have up, and what failure are you seeing? |
| 17:48 |
Bmagic |
it's probably due to the enhanced |
| 17:49 |
sandbergja |
awwww we really should make them more flexible w/r/t what data is in the system. |
| 17:50 |
sandbergja |
the fewer assumptions they make, the better |
| 17:50 |
Bmagic |
yeah, it's bubbling higher and higher on my priority list. I'm going to take it on |
| 17:50 |
sandbergja |
Bmagic++ |
| 17:51 |
Bmagic |
that is to say: I want to make an LP report for our tests in general, with the notion of going over each one, one by one and making them work with any dataset, and maybe eliminating some test that don't make sense. With an end goal of clean and working test sets for each of the languages that we're testing |
| 17:52 |
sandbergja |
that would be sweet, Bmagic! |
| 17:53 |
Bmagic |
It's too soon for me to make report though. I don't know what I don't know |
| 17:54 |
sandbergja |
I opened bug 2053095 earlier -- I guess I should also add the pgtap live tests to this list |
| 17:54 |
pinesol |
Launchpad bug 2053095 in Evergreen "Make tests compatible with the enhanced concerto data set" [Undecided,New] https://launchpad.net/bugs/2053095 |
| 17:54 |
Bmagic |
maybe we use that one |
| 17:55 |
Bmagic |
I will say that the standard concerto set takes much less time to reload/install |
| 17:55 |
Bmagic |
so, resetting the database each time we run your ansible run_test.yml script, becomes a larger endevour |
| 17:55 |
sandbergja |
it still takes forever compared to my patience hahaha |
| 17:56 |
sandbergja |
I think it would be nice to speed up loading both the classic and enhanced |
| 17:57 |
Bmagic |
I'm liking the dev container work I've got going where, instead of deleting the database and making a new one, it makes a new database (evergreen2, 3, 4, etc), which can be done asynchronously, while the original "evergreen" database is hooked up to OpenSRF |
| 17:57 |
sandbergja |
ah! I keep meaning to check that out. |
| 17:58 |
sandbergja |
I will say, I LOVED building the tarball today with the dev container. Having the repo mounted as a volume worked really nicely. |
| 17:59 |
Bmagic |
excellent |
| 17:59 |
sandbergja |
3.13.5 tarball looks good to me too! |
| 18:00 |
sandbergja |
Bmagic: in case you run the nightwatch tests, there is one failure I get that points to this regression: bug 2067160. |
| 18:00 |
pinesol |
Launchpad bug 2067160 in Evergreen "Holdings editor regression: Can no longer remove a default item alert type" [Medium,Confirmed] https://launchpad.net/bugs/2067160 - Assigned to Jane Sandberg (sandbergja) |
| 18:00 |
sandbergja |
I keep meaning to submit a patch for it -- Dan even left a comment saying exactly what needs to be done -- but I haven't gotten around to it yet. |
| 18:04 |
sandbergja |
heading out -- have a good night, Evergreen! |
