| Time |
Nick |
Message |
| 07:01 |
|
collum joined #evergreen |
| 07:41 |
|
redavis joined #evergreen |
| 08:09 |
|
redavis joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 09:05 |
|
dguarrac joined #evergreen |
| 09:25 |
|
Dyrcona joined #evergreen |
| 09:32 |
|
mantis joined #evergreen |
| 09:36 |
|
mantis left #evergreen |
| 09:47 |
redavis |
abneiman++ # thanks for that addition. I did a very ADHD thing (for me) where I don't actually always write left to right but rather top to bottom and left to right. But then I read it left to right...so it said "hold off on angular lint cleanup 3.15 pushes accept for critical fix and documentation." It didn't jive with my memory, but the written word is law (in my head). So, yeah. I excluded it because of the conflict |
| 09:47 |
redavis |
between memory and written word. There is some chaos up in here. |
| 09:58 |
sleary |
my brain has been full of coked-up squirrels this week. Like, more so than usual. |
| 09:59 |
redavis |
yes. |
| 10:05 |
redavis |
Can someone summarize the difference between the EDI message body and the JEDI message body? I can SEE the difference, but I'm curious to know more |
| 10:07 |
abneiman |
redavis++ |
| 10:16 |
berick |
release-team++ coked-up-squirrels++ |
| 10:18 |
redavis |
lol!! |
| 10:19 |
Dyrcona |
Whatever the opposite of coked up squirrels is, that's what I've got in my head today. |
| 10:20 |
abneiman |
barbiturate sloth? ;-) |
| 10:21 |
abneiman |
(that's what MY brain feels like, anyway) |
| 10:22 |
abneiman |
just wanna nap in a tree all day and eat some plants |
| 10:22 |
redavis |
coked-up-squirrels and barbiturate-sloths are siblings. possibly twins. possibly identical twins. |
| 10:23 |
Dyrcona |
Anyway, I think I've had success in splitting up our daily courtesy/autorenewal process. I was able to test the filters Monday and they work! |
| 10:23 |
redavis |
Dyrcona++ |
| 10:24 |
Dyrcona |
redavis: I think the JEDI is just a JSON representation of the EDI. |
| 10:24 |
Dyrcona |
Same data in a different format. |
| 10:25 |
redavis |
That makes sense. There does seem to be more information in the EDI message for INVOIC type than in the JEDI, but I have a theory about that, lol. |
| 10:26 |
Dyrcona |
The JEDI was (is?) used internally by Evergreen and not sent to vendors. |
| 10:26 |
Dyrcona |
I don't remember if the new EDI process uses it or not. |
| 10:27 |
redavis |
++ |
| 10:27 |
Dyrcona |
Ha! We're supposed to do this Phishing security training/test for insurance purposes, and the invitation email ended up in my spam. Yay, Google! |
| 10:27 |
redavis |
berick, do you know? |
| 10:28 |
Dyrcona |
berick should know for sure. |
| 10:29 |
berick |
yeah JEDI is the internal representation of the EDI. it's mainly just a snapshot for debugging |
| 10:29 |
berick |
... these days |
| 10:30 |
redavis |
Okay. Perfect. Thank you. |
| 10:30 |
redavis |
So the actual EDI message is the thing going back and forth and the JEDI is something generated internally. ? |
| 10:31 |
berick |
redavis: yes |
| 10:31 |
redavis |
That stays internal to Evergreen. |
| 10:31 |
berick |
yep |
| 10:31 |
redavis |
Delightful. Thank you :D |
| 10:31 |
redavis |
Dyrcona++ berick++ |
| 10:37 |
|
mantis joined #evergreen |
| 10:38 |
mantis |
trying to install opensrf on a testbox with a make command off of Makefile.install; I can't seem to enter the correct OS for Ubuntu 24.04 LTS |
| 10:38 |
mantis |
I tried [sudo make -f src/extras/Makefile.install noble-numbat] but didn't get any luck |
| 10:39 |
Dyrcona |
mantis: it's ubuntu-noble |
| 10:40 |
Dyrcona |
sudo make -f src/extras/Makefile.install ubuntu-noble |
| 10:40 |
mantis |
[No rule to make target 'ubuntu-noble'] |
| 10:40 |
Dyrcona |
You have main checked out and fully updated? |
| 10:41 |
berick |
reminds me of my strong dislike of ubuntu release code names. why do I have to know 2 things? |
| 10:42 |
mantis |
-face palm- I downloaded the wrong Opensrf version |
| 10:42 |
mantis |
the makefile command works, thank you! |
| 10:42 |
mantis |
Dyrcona++ |
| 10:42 |
mantis |
berick: is there a way to look up those release code names? |
| 10:42 |
Dyrcona |
berick: We could use the version numbers instead. |
| 10:43 |
mantis |
maybe I should have grepped the Makefile |
| 10:43 |
mantis |
version-numbers++ |
| 10:43 |
Dyrcona |
mantis: https://wiki.ubuntu.com/Releases |
| 10:44 |
Dyrcona |
Unrelated, the minutes for yesterday's dev meeting give me a 404. |
| 10:44 |
mantis |
Dyrcona++ |
| 10:46 |
Dyrcona |
I'll note that we use the codenames for the Debian releases, too. |
| 10:49 |
berick |
Dyrcona: i don't want to start a thing, just griping |
| 10:51 |
|
Christineb joined #evergreen |
| 10:51 |
Dyrcona |
OK |
| 10:55 |
Dyrcona |
We need the Nattering Nabob release of .... something. |
| 10:56 |
jeffdavis |
I suppose in theory we could detect the system's distro and release codename and pick the correct Makefile automatically... |
| 10:57 |
redavis |
jeffdavis++ # that sounds pretty intriguing. |
| 11:01 |
Dyrcona |
Yes. We could easily do it in an install script. |
| 11:03 |
Dyrcona |
Well, I say "easily" but it depends. On some really bare bones configurations it gets harder. lsb_release is not always there nor fully functional. |
| 11:10 |
berick |
cat /etc/issue maybe |
| 11:11 |
berick |
(but maybe those are linked, dunno) |
| 11:12 |
collum |
Is /etc/os-release in Debian? |
| 11:28 |
mantis |
let's say there's an item that was placed into transit in 2019 and I'm looking this up in the auditor table. auditor.asset_copy_history has an audit time of 2023 for an item with the item status changed in 2019. Where does the audit_time actually come from in this table? |
| 11:28 |
Bmagic |
yall are reminding me of this bug 2086803 |
| 11:28 |
pinesol |
Launchpad bug 2086803 in Evergreen "Evergreen should be eaiser to install from scratch" [Undecided,Confirmed] https://launchpad.net/bugs/2086803 |
| 11:29 |
Bmagic |
mantis: the PG trigger makes that |
| 11:31 |
Bmagic |
mantis: take a look at the helper function auditor.create_auditor(sch text, tbl text) |
| 11:31 |
jeffdavis |
An audit_time of 2023 means that that the row was changed in 2023. The auditor table shows what the row looked like *before* the change ("here's what the row looked like until it was changed in 2023") |
| 11:31 |
mantis |
Bmagic: ok; the issue is this item has been with an In Transit status for that long but for some reason it's not showing up on a monthly report that has these as filters: circ lib, receive date NULL, and cancel date NULL |
| 11:32 |
|
jihpringle joined #evergreen |
| 11:33 |
mantis |
jeffdavis: ok so something must had happened between the old in transit status to the new one I guess |
| 11:33 |
mantis |
it's still in transit according to Item Status |
| 11:33 |
Bmagic |
sounds like the report isn't designed to look at the right pieces of the puzzle |
| 11:34 |
mantis |
Bmagic++ |
| 11:34 |
mantis |
jeffdavis++ |
| 11:34 |
Bmagic |
the status of an item being "in transit" doesn't always mean there's a row in action.transit_copy |
| 11:35 |
mantis |
I guess I should say this report is for items in transit that haven't been received yet |
| 11:35 |
mantis |
sorry |
| 11:35 |
mantis |
would it be better if it was something like: owning lib, in transit status, receive date NULL? |
| 11:36 |
Bmagic |
you might find several examples of items that are "in transit" that don't have an accompanying action.transit_copy line |
| 11:37 |
mantis |
I'll give it a shot in the db first |
| 11:43 |
Bmagic |
here's a query that might find items that have a status of in transit but don't have a row for the transit in action.transit_copy |
| 11:44 |
Bmagic |
select ac.barcode,ccs.name from asset.copy ac join config.copy_status ccs on(ccs.id=ac.status and not ac.deleted) left join action.transit_copy atc on(atc.target_copy=ac.id and (cancel_time is null or dest_recv_time is null)) where ccs.name~*'transit' andatc.id is null |
| 11:44 |
Bmagic |
looks like there's a space needed there |
| 11:45 |
Bmagic |
let's try that again |
| 11:45 |
Bmagic |
select ac.barcode,ccs.name from asset.copy ac join config.copy_status ccs on(ccs.id=ac.status and not ac.deleted) left join action.transit_copy atc on(atc.target_copy=ac.id and (cancel_time is null or dest_recv_time is null)) where ccs.name~*'transit' and atc.id is null |
| 11:46 |
mantis |
I do receive some results but it appears that the item in question isn't in the results |
| 11:46 |
Bmagic |
I'd take a close look at your report template |
| 11:46 |
mantis |
Bmagic++ |
| 12:01 |
|
dguarrac joined #evergreen |
| 12:34 |
|
jihpringle joined #evergreen |
| 13:09 |
phasefx |
--load-concerto-enhanced in main (and 3.15-rc) gave me a duplicate key error on permission.grp_tree |
| 13:10 |
Bmagic |
ah! I got that too, the other day, probably needs regenerated now |
| 13:12 |
Bmagic |
for feedback fest, I got enhanced concerto loaded on the test machine, but encountered that issue and figured it was due to all of the patches I'd loaded onto the source code. But now that they've been merged, it's time to regenerate the enhanced concerto to bring it up to current |
| 13:13 |
phasefx |
@Bmagic++ |
| 13:13 |
pinesol |
phasefx: uh huh.. please tell me more about that |
| 13:13 |
phasefx |
urg, my IRC habits are fading away |
| 13:14 |
Bmagic |
https://docs.evergreen-ils.org/docs/latest/development/support_scripts.html#make_concerto_from_evergreen_db |
| 13:14 |
Bmagic |
"Upgrade a previously-created dataset" |
| 13:22 |
Bmagic |
I'll put a commit out there in a bit |
| 13:35 |
abneiman |
phasefx++ Bmagic++ |
| 14:04 |
csharp_ |
re: grabbing release from the OS, you can make sure lsb-release is installed and do lsb_release -c (or whatever we're going by) |
| 14:05 |
csharp_ |
it's universal in Linux as far as I'm aware - I have used it in many scripts I want to use across distros/releases |
| 14:06 |
csharp_ |
DISTRONAME="$(lsb_release -si | tr [:upper:] [:lower:])-$(lsb_release -sc | tr [:upper:] [:lower:])" |
| 14:06 |
csharp_ |
that would produce "ubuntu-jammy" or whatever |
| 14:11 |
csharp_ |
hmm - Fedora stopped populating the "codename" field |
| 14:13 |
csharp_ |
so yeah, if we did go the lsb release route and want to support more than just Debian-world, we would probably want to use release numbers |
| 14:14 |
csharp_ |
(I'll also throw in that after the three seconds of chuckling about the toy story character, I hate Debian's codename scheme too) |
| 14:15 |
csharp_ |
buster/bullseye/wheezy etc. - if you don't use Debian all the time they all sound the same |
| 14:15 |
csharp_ |
@monologue |
| 14:15 |
pinesol |
csharp_: Your current monologue is at least 9 lines long. |
| 14:16 |
jeffdavis |
I think the fedora makefile is just called "fedora" anyway, i.e. we don't use a codename for that one? |
| 14:16 |
csharp_ |
jeffdavis: yeah.... that should be removed completely imho |
| 14:16 |
csharp_ |
and if we are going to support RHEL-ish things it would be RHEL/Rocky probably |
| 14:17 |
csharp_ |
the fedora support originated from denials when he was running EG on his Fedora laptop afaik |
| 14:18 |
csharp_ |
bug 1880703 for reference4 |
| 14:18 |
pinesol |
Launchpad bug 1880703 in OpenSRF "Wishlist: RHEL/Rocky Support" [Wishlist,New] https://launchpad.net/bugs/1880703 - Assigned to Chris Sharp (chrissharp123) |
| 14:18 |
csharp_ |
s/4// |
| 14:19 |
csharp_ |
my long-running low-intensity effort to branch out beyond Debian :-) |
| 15:01 |
Bmagic |
I agree that we should remove support for fedora. It doesn't work and we shouldn't mislead people |
| 15:04 |
Bmagic |
I never got it to work. I put hours into it at one point |
| 15:05 |
Bmagic |
it all comes down to the perl modules IIRC |
| 15:08 |
csharp_ |
Bmagic: just filed bug 2106667 |
| 15:08 |
pinesol |
Launchpad bug 2106667 in OpenSRF "Remove Fedora Makefile Target" [Low,New] https://launchpad.net/bugs/2106667 - Assigned to Chris Sharp (chrissharp123) |
| 15:08 |
Bmagic |
csharp_++ |
| 15:17 |
mmorgan |
Back to mantis's In transit question - not sure this is relevant, but before there was a 'Canceled transit' status, in transit items that had their transit canceled retained the 'In transit' status. So that could potentially provide an explaination for items with the status, but no active transit. |
| 15:25 |
Bmagic |
phasefx: for db upgrade 1468, I'm finding that the upgrade script introduces new rows into permission.grp_tree differently than it would if Evergreen were installed from 950 seed. In the case of the 950 seed, the ID's are explicit, whereas the upgrade script allows the DB to assign ID's from the sequence. The enhanced concerto logic assumes that the upgrade version and the seed version would match |
| 15:26 |
Bmagic |
it's not a huge deal, but something I thought I'd note |
| 15:33 |
Dyrcona |
Bmagic: I think the pgt id thing is unavoidable since we likely have sites with custom groups that have ids that would overlap with fixed ids in an upgrade script. |
| 15:33 |
Bmagic |
yep, I understand |
| 15:33 |
Dyrcona |
I don't think we ever carved out a reserved range for pgt.id. |
| 15:35 |
csharp_ |
we can do that retroactively, but we'd have to be super careful |
| 15:44 |
Dyrcona |
It's probably better if the enhanced concerto data didn't depend on fixed ids for pgt. |
| 15:48 |
Bmagic |
I've almost got it, you can see the commit on main shortly, if you're curious |
| 15:50 |
Bmagic |
the new generation of the dataset pooped out a difference in config.org_unit_setting_type because there were rows in previous EG versions that are removed in new seed data, but the EG upgrade script doesn't delete the rows from the database. |
| 15:51 |
Bmagic |
instead, the upgrade script (for similar reasons as pgt) renames the label to "Deprecated:" - I think I'll manually interviene on that one and not allow that to propigate into the enhanced set |
| 15:52 |
Bmagic |
propigate/propagate |
| 15:52 |
Bmagic |
it looked weird after typing it and yep, spelled wrong. |
| 16:02 |
Dyrcona |
Bmagic++ |
| 16:03 |
Bmagic |
pushed to main |
| 16:06 |
Bmagic |
main and 3.15 are the same as far as the database pieces go, I'll backport |
| 16:07 |
Bmagic |
phasefx: you should be able to install the dataset now like normal from current rel_3_15 |
| 16:12 |
|
frank_g joined #evergreen |
| 16:16 |
frank_g |
Hi all, I am trying to implement a new EG development server but with the same database server (production), Is it posible? because running the perl /home/opensrf/Evergreen-ILS-3.12.0/Open-ILS/src/support-scripts/eg_db_config --update-config --service all --user evergreen_dev --password dTW --hostname 192.168.6.XXX --port 5432 --database |
| 16:16 |
frank_g |
evergreendatos_dev --admin-user administrator --admin-pass XXXX command I got this DBD::Pg::st execute failed: ERROR: permission denied for schema evergreen |
| 16:16 |
frank_g |
LINE 4: COALESCE(evergreen.unaccent_and_squash(NEW.first_giv.. |
| 16:17 |
Bmagic |
frank_g: permission denied means you've passed a username/password into the script that doesn't have proper access to your database (most likely) - and the IP address that you've provided, is that exactly what you used? |
| 16:21 |
Bmagic |
frank_g: what's the name of the database in postgres that you use for production? Is it called "evergreen"? if so, you're very much going to want to change that command to talk to a different* database other than evergreen. Because that script will delete* the database and create a new database with the same name. |
| 16:21 |
Bmagic |
maybe it's IRC cutting off your paste |
| 16:23 |
frank_g |
This is the comand I run for production: perl /home/opensrf/Evergreen-ILS-3.12.0/Open-ILS/src/support-scripts/eg_db_config --update-config --service all --user evergreen --password 1=1234 --hostname 192.168.6.123 --port 5432 --database evergreendatos --admin-user administrator --admin-pass 1234 |
| 16:24 |
Bmagic |
Another thought: if you want to make a copy of the production database, then you're probably not going to want to run that script in the first place. You'll want to perform a dump/restore. https://www.postgresql.org/docs/current/backup-dump.html |
| 16:24 |
pinesol |
News from commits: Regenerate and update the enhanced concerto dataset <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=55698546cda7cdef7bbce5408e4f964eb2302cf4> |
| 16:24 |
pinesol |
News from commits: Fixing enhanced concerto <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=9e7b636109aa5d199e951baad8950e47887e797a> |
| 16:24 |
frank_g |
and this is the command I run for development: perl /home/opensrf/Evergreen-ILS-3.12.0/Open-ILS/src/support-scripts/eg_db_config --update-config --service all --user evergreen_dev --password 1=1234 --hostname 192.168.6.123 --port 5432 --database evergreendatos_dev --admin-user administrator --admin-pass 1234 |
| 16:25 |
Bmagic |
frank_g: ok that makes sense. Thanks. The direct issue with your error has to do with database permissions. You will need to run a couple of commands on your database in order to give permissions to the database user "evergreen_dev" to "evergreendatos_dev" |
| 16:26 |
Bmagic |
just know that the results of this procedure won't be a copy of production. It will be an empty Evergreen database |
| 16:27 |
Bmagic |
here are three postgres commands that should help you get through the permission error: |
| 16:27 |
Bmagic |
CREATE ROLE evergreen_dev PASSWORD '1=1234' LOGIN INHERIT CREATEDB CREATEROLE; |
| 16:28 |
Bmagic |
CREATE DATABASE evergreendatos_dev; |
| 16:28 |
Bmagic |
GRANT ALL PRIVILEGES ON DATABASE "evergreendatos_dev" to evergreen_dev; |
| 16:28 |
Bmagic |
GRANT ALL ON DATABASE "evergreendatos_dev" to evergreen_dev; |
| 16:28 |
Bmagic |
well, ok, four commands |
| 16:30 |
Bmagic |
I have to step away for a bit |
| 16:31 |
frank_g |
Ok, I will try, thank you so much |
| 16:31 |
berick |
@dunno CREATEDB CASSEROLE |
| 16:31 |
pinesol |
berick: What we have here is a failure to communicate. |
| 16:31 |
berick |
@dunno add CREATEDB CASSEROLE |
| 16:31 |
pinesol |
berick: The operation succeeded. Dunno #95 added. |
| 17:18 |
|
mmorgan left #evergreen |
| 18:54 |
|
jihpringle joined #evergreen |
| 19:22 |
|
pinesol joined #evergreen |
| 19:26 |
|
jihpringle joined #evergreen |
| 20:57 |
csharp_ |
berick++ # love me a good ol' CREATEDB CASSEROLE |
