Time |
Nick |
Message |
02:38 |
|
sleary joined #evergreen |
07:50 |
|
collum joined #evergreen |
08:18 |
|
redavis joined #evergreen |
08:22 |
|
Rogan joined #evergreen |
08:32 |
|
mmorgan joined #evergreen |
08:39 |
|
sleary joined #evergreen |
08:42 |
csharp_ |
we have a typo in 002.schema.config.sql in 3.12-rc - looks like sandbergja's editor might have doubled an insertion |
08:42 |
csharp_ |
https://git.evergreen-ils.org/?p=Evergreen.git;a=blobdiff;f=Open-ILS/src/sql/Pg/002.schema.config.sql;h=b5fb5575192eb2edbad0d4543e6c9c86ef15b1b9;hp=1adbb5e5f56e0131f4c969ecf2700e5cd0bbd982;hb=5877f3f8343761e76657eb5f046c8e925981f306;hpb=030416390d8f59e5f664ce9b289761b608d8caed |
08:49 |
|
kmlussier joined #evergreen |
08:54 |
|
smayo joined #evergreen |
09:17 |
|
dguarrac joined #evergreen |
09:20 |
|
adam_reid joined #evergreen |
09:20 |
|
terranm joined #evergreen |
09:38 |
kmlussier |
@coffee |
09:38 |
* pinesol |
brews and pours a cup of Kenya AA Nyeri Fine Cup, and sends it sliding down the bar to kmlussier |
09:38 |
* kmlussier |
is being selfish and keeping the coffee to herself this morning. |
09:41 |
|
sandbergja joined #evergreen |
09:52 |
csharp_ |
didn' |
09:52 |
csharp_ |
didn't realize 3.12.0 was available - ignore my comments above regarding 3.12-rc |
09:56 |
sandbergja |
csharp_++ |
09:56 |
sandbergja |
good catch! |
09:57 |
|
sandbergja joined #evergreen |
10:00 |
|
jvwoolf joined #evergreen |
10:00 |
|
sleary joined #evergreen |
10:12 |
|
sandbergja joined #evergreen |
10:16 |
csharp_ |
Bmagic> Dyrcona: Just testing my tarball, and I got this while building the old concerto set: psql:assets_concerto.sql:58: ERROR: update or delete on table "record_entry" violates foreign key constraint "browse_entry_def_map_source_fkey" on table "browse_entry_def_map" |
10:16 |
csharp_ |
terranm saw that same error yesterday - currently trying to reproduce it |
10:18 |
csharp_ |
and.... no, I can't reproduce it on 3.12.0 |
10:18 |
csharp_ |
(from git, not tarball, if that matters) |
10:21 |
Bmagic |
csharp_++ |
10:22 |
Bmagic |
I don't think the build process messes with the concerto set, but, of course, the base schema build is there in the rel_11 branch. I would think that if there was an issue with the schema, the enhanced concerto would have the problem too |
10:36 |
|
redavis_reboot joined #evergreen |
10:48 |
|
dguarrac joined #evergreen |
10:54 |
|
briank joined #evergreen |
11:11 |
pinesol |
News from commits: Forwad port 3.11.1-3.11.2 database upgrade <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=330533bb06a0a14c56c1749b8c3baba423a95ff2> |
11:42 |
csharp_ |
have OpenSRF libraries been moved? configure: error: *** OpenILS requires libopensrf |
11:43 |
csharp_ |
libopensrf.so is present in /openils/lib, so I don't know why it's complaining |
11:43 |
csharp_ |
and /openils/lib is in the ld path |
11:44 |
|
Christineb joined #evergreen |
11:44 |
csharp_ |
ah - looks like 529af487f81 is the issue? |
11:44 |
* csharp_ |
runs off to read bug 1999823 |
11:44 |
pinesol |
Launchpad bug 1999823 in OpenSRF 3.3 "Name collision causes apache gateway modules to fail when mod_shib is installed" [Medium,Fix released] https://launchpad.net/bugs/1999823 |
11:48 |
JBoyer |
csharp_, sorry, that wasn't the best error message. In short you need to install one of the newer opensrf releases or main from git. |
11:49 |
csharp_ |
JBoyer: doing so now |
11:50 |
csharp_ |
@who 's in the basement mixing up the medicine? |
11:50 |
pinesol |
collum 's in the basement mixing up the medicine. |
11:51 |
collum |
I'm watching my parking meters. |
11:51 |
* JBoyer |
isn't sure if he doesn't get one reference up there or two. |
11:51 |
* berick |
still needs a weatherman |
11:53 |
csharp_ |
collum++ |
11:53 |
csharp_ |
JBoyer: Subterranean Homesick Blues |
11:53 |
csharp_ |
JBoyer: so /usr/lib/apache2/modules is now where OpenSRF libs are? |
11:54 |
* csharp_ |
is so confused |
11:54 |
JBoyer |
csharp_, no, it's still /openils/lib as usual, but you need a libopensrf that exposes the new function names, AND the new apache module that calls them. |
11:55 |
csharp_ |
huh |
11:56 |
csharp_ |
oh, I see - reading further up I see that /openils/lib line |
11:58 |
csharp_ |
still not working :-( |
11:58 |
csharp_ |
On branch osrf_rel_3_3_0 - new enough, right? |
11:58 |
Bmagic |
I get that issue sometimes (so library not found) - and it's solved each time by reinstalling everything again. Something missed somewhere the first time through |
11:58 |
JBoyer |
csharp_, certainly should be, yeah. have you re-run ldconfig since installing it? |
11:59 |
csharp_ |
I fixed it on another server earlier in the week, but reinstalling doesn't appear to help |
11:59 |
csharp_ |
JBoyer: that was it |
11:59 |
csharp_ |
oh wait - wrong directory |
12:00 |
csharp_ |
eyes rolling around in head |
12:00 |
JBoyer |
yay, I didn't think it should be more than that. |
12:00 |
csharp_ |
nope still busted |
12:00 |
csharp_ |
configure: error: *** OpenILS requires libopensrf |
12:00 |
JBoyer |
:( |
12:00 |
csharp_ |
checking for osrf_buffer_free in -lopensrf... no |
12:01 |
JBoyer |
do an ls -l /openils/lib to see where the libopensrf symlink is pointing, if it's the old version of the library that's bad news. |
12:01 |
csharp_ |
lrwxrwxrwx 1 opensrf opensrf 19 Dec 14 11:49 libopensrf.so -> libopensrf.so.2.1.1 |
12:02 |
|
jihpringle joined #evergreen |
12:02 |
JBoyer |
what's the other version in that dir? |
12:02 |
csharp_ |
-rwxr-xr-x 1 opensrf opensrf 995272 Dec 14 11:49 libopensrf.so.2.1.1 |
12:02 |
csharp_ |
yes - the only version |
12:03 |
JBoyer |
I thought the new version should be 2.2.1 or 2.1.2... one sec |
12:04 |
JBoyer |
actually it's 4.0.2, but I'm not sure that's used as-is in the filename. :/ |
12:05 |
csharp_ |
I even moved /openils out of the way so it would all be freshly built |
12:05 |
JBoyer |
I have 2.1.1 and 2.2.0 on my fs, if you've only got the 1 did everything go ok with the 3.3.0 install? |
12:06 |
csharp_ |
trying again |
12:08 |
csharp_ |
-rwxr-xr-x 1 root root 995272 Dec 14 12:07 libopensrf.so.2.1.1 is all I have after installing 3.3.0 from git - I'll try main now |
12:09 |
csharp_ |
maybe I didn't " |
12:09 |
csharp_ |
"make clean" enough |
12:09 |
csharp_ |
building |
12:09 |
JBoyer |
I don't know that make clean works properly, I normally use sudo git clean -fxd |
12:10 |
csharp_ |
ah - now I see the other version |
12:10 |
JBoyer |
(make is supposed to be smart enough to notice the timestamp changes anyway, but *shrug*) |
12:10 |
JBoyer |
That sounds promising |
12:11 |
csharp_ |
never install anything ever, on anything for anyone, for any reason... |
12:11 |
csharp_ |
sometimes I just start a make install process and don't know where I'm going with it |
12:12 |
csharp_ |
AAAYYYY |
12:12 |
csharp_ |
it's working now |
12:12 |
JBoyer |
csharp_++ |
12:12 |
csharp_ |
JBoyer++ # thanks for the handholding :-) |
12:13 |
JBoyer |
Always happy to help make sure I didn't break everything! :D |
12:13 |
berick |
make clean has worked for me so far |
12:13 |
csharp_ |
doesn't work in my kitchen though AAAYYY |
12:14 |
Bmagic |
format fridge/c: |
12:14 |
csharp_ |
open-ils.dinner |
12:15 |
smayo |
cat leg --follow |
12:31 |
csharp_ |
okay, so for the logs and my sanity - this was failing for me because I was not "make clean"-ing as root and some of the files were owned by root and therefore not removed |
12:39 |
JBoyer |
Ah, right. Can't replace build artifacts once sudo make install changes their ownership. |
12:39 |
JBoyer |
csharp_++ |
12:40 |
csharp_ |
right - the alternative approach would be to add a chown -R of the OpenSRF directory as root (again, for the logs) |
12:42 |
|
jvwoolf joined #evergreen |
13:21 |
|
smayo joined #evergreen |
13:34 |
|
smayo joined #evergreen |
14:01 |
|
sleary joined #evergreen |
15:30 |
Bmagic |
JBoyer++ |
15:34 |
|
jihpringle joined #evergreen |
15:35 |
JBoyer |
quick poll for those present, rename the new tarballs like 3.10.4a or just leave the filenames alone? (I noticed only 3.12.0 has officially been announced) |
15:36 |
Bmagic |
I say overwrite |
15:36 |
Bmagic |
less is more IMO |
15:37 |
csharp_ |
+1 |
15:39 |
Bmagic |
in the past, I messed up the tarball, I remember we left it as-is and made a new git branch (a) along with a new tarball. I'm not entirely sure the reasoning |
15:40 |
Bmagic |
IMO if it's broke, why allow it to live? People might end up downloading the broken one |
15:41 |
|
jvwoolf joined #evergreen |
15:42 |
pinesol |
News from commits: Correct Pg10 Syntax Error in Trigger Creation (version upgrade) <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=cd9311af3bcaa8913bebd3c5c948167bcb09f8b5> |
15:42 |
pinesol |
News from commits: Correct Pg10 Syntax Error in Trigger Creation <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2b5f2b0a93a05f368c624c33d172d6f48599e24e> |
15:54 |
JBoyer |
The thought behind renaming isn't to keep the old one around, it's to make it clear to people who would have downloaded the broken one because they can see that the names are different. |
15:58 |
|
adam_reid joined #evergreen |
15:58 |
Bmagic |
roger that |
16:10 |
JBoyer |
But, to answer my own question, I see that all 3 are live on the download page, so I'll be overwriting the existing and also adding symlinks / updating the links for the 'a' versions. And then I'll throw out an email notice. |
16:13 |
terranm |
JBoyer++ |
16:16 |
jeff |
next time around, i'd recommend burning the point release (say, 3.10.4) and releasing 3.10.5. in this case, it's too late to matter, and it's unlikely that we'll actually run into confusion from someone who was on top of things enough that they downloaded 3.10.4 but not on top of things enough to see the followup "nevermind!" and subsequent re-release. |
16:18 |
adam_reid |
Hey all! I've tried recently to add a custom page to our OPAC. While simply adding the .tt2 file to the opac folder of our templates directory works to resolve the page, when visiting the new URL the user is asked to log in. The page is just going to be a place to put all our current staff picks. I read a bit in the docs about permissions for pages |
16:18 |
adam_reid |
being defined in Apache, but I wasn't able to figure out how to make the page visible to anyone. Any thoughts? Is this possible? Are these permissions controlled elsewhere? |
16:19 |
jeff |
is it a static page, or does it use tt2 directives and perl templates/variables? |
16:21 |
sandbergja |
JBoyer++ |
16:21 |
jeff |
if the former, I recommend putting it in a subdir off your main DocumentRoot. almost everything with a URL starting in /eg/ is going to be passed to mod_perl for handling via EGWeb, and while some things work there by happenstance, I'm not sure there are any that do without logging in, and if you don't actually need the perl/tt2 bits, it would probably simplify things a great deal. |
16:21 |
adam_reid |
I'd like it to still have access to all the tt2 directive and template variable. |
16:21 |
jeff |
ah, it's the latter. then the task may be more complicated. :-) |
16:22 |
adam_reid |
ok, thats fair, so does Evergreen need to be aware of the page earlier in the process? |
16:22 |
jeff |
just the tt2 bits, or Evergreen variables/functions also? |
16:23 |
jeff |
do you have the tt2 source somewhere? that would answer some of the questions. it sounds like public data? |
16:23 |
adam_reid |
I'm not 100% the difference, I think just the tt2 bits |
16:24 |
adam_reid |
no source anywhere yet, to test the idea I basically just made a blank test page, I assumed it would resolve but didn't expect to be asked to login by default |
16:24 |
jeff |
which path did you put it at? |
16:25 |
adam_reid |
at the time /openils/var/templates_custom/opac/test.tt2 |
16:26 |
adam_reid |
I figured if the simple test worked I would start to see what was possible, the page was essentially blank, once logged in everything worked fine, pulled in a few carousels and they worked |
16:26 |
adam_reid |
just didn't want users to need to log in |
16:30 |
terranm |
I'm not 100% certain, but you may need to add it into EGCatLoader.pm to route |
16:31 |
terranm |
Example - https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=fc361eeb6759c7af074b14f8faa9b9c4d37bbb77 |
16:34 |
adam_reid |
interesting... right, seems that addition would've required a similar setup, looks like a great place to start looking, THANKS terranm |
16:39 |
jeff |
depending on your needs, you can drop a tt2 file in a place outside of the opac dir, like (using your example above) /openils/var/templates_custom/local/test.tt2 |
16:40 |
jeff |
(without needing to define a route, etc) |
16:41 |
terranm |
jeff++ |
16:44 |
* JBoyer |
Eg tarballs rebuilt, uploaded, and updated. |
16:44 |
adam_reid |
interesting, thanks jeff. I'll play around with that too! |
16:45 |
JBoyer |
huh, I guess I found the "make this an action" keyboard shortcut in my client. |
16:49 |
jeff |
terranm++ |
16:49 |
jeff |
JBoyer++ |
16:52 |
mmorgan |
JBoyer++ |
17:02 |
Bmagic |
JBoyer++ |
17:03 |
jeffdavis |
Bug 2023690 (improvements to enhanced concerto dataset) is targeted at 3.next, does it make sense to target 3.11 and 3.12 point releases? At a glance it seems like bugfixes rather than new features to me. |
17:03 |
pinesol |
Launchpad bug 2023690 in Evergreen "Enhanced Concerto dataset (Cont.)" [Low,Confirmed] https://launchpad.net/bugs/2023690 |
17:04 |
jeffdavis |
... and I see it's already after 5pm Eastern, where does the time go |
17:05 |
Bmagic |
jeffdavis: the enhancement is the date carry piece. Then I've continued to force push some bug fixes regarding the sequence updates |
17:07 |
Bmagic |
but, that said, I vote for backporting it to all the branches that received the original merge |
17:08 |
Bmagic |
which, as you said, started at 3.11 |
17:10 |
jeffdavis |
I'd vote for backporting as well, if it doesn't create headaches for anybody :) |
17:11 |
Bmagic |
+2 means do it right? (hehe) |
17:11 |
|
mmorgan left #evergreen |
17:19 |
Bmagic |
sandbergja++ abneiman++ mmorgan++ terranm++ smayo++ sleary++ collum++ redavis++ # 3.12 rocks! |
18:07 |
|
kmlussier left #evergreen |
18:21 |
|
jihpringle joined #evergreen |