| Time |
Nick |
Message |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:12 |
|
calvinm joined #evergreen |
| 07:21 |
|
rjackson_isl_hom joined #evergreen |
| 08:06 |
|
alynn26 joined #evergreen |
| 08:25 |
|
Dyrcona joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 09:17 |
|
rfrasur joined #evergreen |
| 09:22 |
|
dbwells joined #evergreen |
| 09:56 |
|
dbwells joined #evergreen |
| 10:19 |
|
dbwells joined #evergreen |
| 10:21 |
|
alynn26_away joined #evergreen |
| 10:38 |
Bmagic |
I'm fooling with the docs site this morning, yall, don't be alarmed if it acts weird. Troubleshooting the lunr search box |
| 10:41 |
* csharp |
disables site-fooling alarms accordingly |
| 10:42 |
csharp |
so I may have dreamed this, but I remember seeing a bug report where JBoyer (?) had created views for Dewey, etc. to make Classic Item List and Classic Circulation View obsolete... |
| 10:42 |
csharp |
trying to find the bug in LP but I'm either overlooking it or it's not findable with my search terms/tags |
| 10:45 |
mmorgan |
csharp: bug 1813191 ? |
| 10:45 |
pinesol |
Launchpad bug 1813191 in Evergreen "Move calculated dewey ranges/blocks to their own reporting view" [Wishlist,New] https://launchpad.net/bugs/1813191 |
| 10:54 |
csharp |
mmorgan: yes! thank you |
| 10:55 |
mmorgan |
YW! |
| 10:58 |
JBoyer |
mmorgan++ |
| 10:59 |
JBoyer |
csharp, I'd be delighted if you could throw that on a test server with PINES data to see what's what with a real dataset. Obviously works pretty well with concerto. ;) |
| 10:59 |
csharp |
JBoyer: will do |
| 11:00 |
JBoyer |
(If that's what you're thinking) |
| 11:00 |
JBoyer |
csharp++ |
| 11:00 |
csharp |
we're having fits with Classic Circulation View, which would also be rendered unnecessary with that improvement |
| 11:00 |
JBoyer |
Nice. |
| 11:02 |
JBoyer |
My aim was to make it easier / possible to do a git rm :q |
| 11:02 |
csharp |
yes |
| 11:02 |
JBoyer |
Not a command line, bad typist. |
| 11:12 |
Bmagic |
JBoyer: I hate to say it, but it seems that removing the ui supplement stuff from Evergreen is bugging the search. Though, I can't figure out why. I agree, that you've migrated the overrides over to eg-antora. Still diffing |
| 11:13 |
Bmagic |
right now, I can say for sure that building antora with the ui-bits in Evergreen overlayed over eg-antora makes it work |
| 11:33 |
Bmagic |
JBoyer: we may need to put the supplement stuff back. The issue was our nightly Evergreen builds were bombing on the absence of header-content.hba? Can we just make that file exist (with the updates from eg-antora) and call it a day? |
| 11:34 |
Bmagic |
I'm starting to think that the lunr stuff needs* itself to be in the repo with the docs during build time. Alternatively, the build script could cp eg-antora -> Evergreen/docs/ui, commit a test branch, build that branch, then revert it all |
| 11:47 |
gmcharlt |
the former, if there's no other way, is preferable to the latter: creating and throwing away git commits wouldn't be great for anybody with uncommitted changes in the clone who simply wants to try a doc build |
| 11:57 |
|
jihpringle joined #evergreen |
| 12:03 |
|
Christineb joined #evergreen |
| 12:06 |
Bmagic |
gmcharlt: I agree for sure, though the commits would only exist locally and thrown away locally. They wouldn't ever need pushed during the build process |
| 12:08 |
Bmagic |
But programming generate_docs.pl to do that, would be pretty antora server specific, which makes it less adoptable by the community. Though, I could see a way for it to allow for that sort of behavior with switches or something along those lines. Not my favorite idea |
| 12:13 |
Bmagic |
One thing that bufuttled me when I was first getting familiar with Antora is: all of your changes need to be commited to branch. Antora will not build/include any files/changes that are not commited to the main build branch. Including antora.yml |
| 12:17 |
JBoyer |
Bmagic, yeah, if that file is missing we should be able to just put it in place with the edits it needs. It's possible I accidentally left it out when moving things over. |
| 12:18 |
Bmagic |
JBoyer: header-contents.hba exists in the eg-antora repo. No problem. The issue, it seems, is that lunr doesn't like zero files being in the Evergreen branch |
| 12:19 |
Bmagic |
I haven't tried building it with an empty folder structure and a call out to it in the yaml file though.... I wonder |
| 12:19 |
JBoyer |
I thought the issue was something with the CSS? I was under the impression it was fine aside from that. |
| 12:22 |
Bmagic |
the resulting site has a broken search box right now |
| 12:22 |
Bmagic |
I've been rebuilding it with different ideas, and it's currently working with the ui-bits back in the Evergreen repo |
| 12:22 |
|
eady joined #evergreen |
| 12:23 |
Bmagic |
so, right this second, it's working fine |
| 12:53 |
|
collum joined #evergreen |
| 12:55 |
|
sandbergja joined #evergreen |
| 13:34 |
JBoyer |
Bmagic, it looks like the issue with the built-in lunr changes is that the path for search.css is wrong. I'm getting 404s for it and seeing the weird search problem you're talking about. |
| 13:34 |
Bmagic |
ah! There we go |
| 13:34 |
Bmagic |
nice catch |
| 13:35 |
JBoyer |
so it's not a matter of using the supplemental thing again, but making that happy. |
| 13:35 |
Bmagic |
sweet, we update search.css in eg-antora then? It sounds like you already know which lines? |
| 13:36 |
JBoyer |
search.css itself is fine, I don't think it's being included in the ui-bundle. |
| 13:38 |
Bmagic |
I see, search.css (part of lunr's overrides) is not compiled into ui-bundle with gulp pack |
| 13:38 |
* Dyrcona |
shakes his head.... |
| 13:38 |
JBoyer |
yeah, because it wasn't a changed file in the original antora-ui, it's as if we just dropped a new file into a project and wondered why make didn't pick it up. |
| 13:39 |
Bmagic |
You're thinking of making gulp do that? or perhaps putting search.css in the Evergreen repo? |
| 13:39 |
JBoyer |
gulp just needs to be told that it's part of the build target. |
| 13:39 |
JBoyer |
wherever that's done... |
| 13:39 |
* Bmagic |
nods at Dyrcona. The agony |
| 13:50 |
Bmagic |
JBoyer: it sure seems like it should* be including search.css: css: `${srcDir}/css/**/*.css`, |
| 13:51 |
Bmagic |
oh right, it compiles* them into site.css |
| 13:51 |
Bmagic |
minifies them |
| 13:52 |
Bmagic |
I'll bet search.css won't lint |
| 13:52 |
JBoyer |
:q |
| 13:52 |
JBoyer |
bah |
| 13:53 |
Bmagic |
lol |
| 13:54 |
JBoyer |
the only thing that shouldn't lint is lunr.js. It's such a mess according to their rules I just disabled linting that file altogether. |
| 13:54 |
Bmagic |
I saw that |
| 13:54 |
JBoyer |
search.css only needed a couple minor edits. |
| 13:55 |
Bmagic |
grepping the resulting site.css, I'm not seeing any of the definitions from search.css included. Though, it seems it should be with the ** syntax from gulpfile.js |
| 13:56 |
Bmagic |
in fact, the word "search" doesn't apear in ui-bundle.zip:css/site.css |
| 13:56 |
Bmagic |
appear |
| 13:56 |
JBoyer |
something needs to be changed in gulp.d/build.js |
| 13:57 |
JBoyer |
OR, we just throw the contents of search.js at the bottom of site.js and call it good. |
| 13:57 |
JBoyer |
I don't know enough about the layout and build process to know which would be the better way to deal with it |
| 13:58 |
* Bmagic |
reads the files referenced |
| 13:59 |
Bmagic |
sheesh, only 114 lines in search.css |
| 14:00 |
JBoyer |
well, my latter suggestion is no good, when I said that I assumed there was only a single site.css file in there; it can obviously handle multiples somehow, it just doesn't want to add search. |
| 14:01 |
Bmagic |
adding the stuff back to Evergreen would be cleaner anyway IMO |
| 14:01 |
Dyrcona |
@decide lunr.js or luny.js |
| 14:01 |
pinesol |
Dyrcona: go with lunr.js |
| 14:02 |
Dyrcona |
@decide bottle in front of me or frontal lobotomy |
| 14:02 |
pinesol |
Dyrcona: go with bottle in front of me |
| 14:02 |
Bmagic |
lol |
| 14:04 |
JBoyer |
If we have a custom eg-antora what would be "clean" is keeping all of the custom stuff in one place. Otherwise we have some custom antora stuff in eg-antora, more custom antora stuff in Evergreen/docs/ui-lunr, etc. |
| 14:16 |
|
nfBurton joined #evergreen |
| 14:16 |
JBoyer |
paying just a little more attention to the grep I ran earlier shows that all that *should* need to be done is drop another @import into site.css. |
| 14:16 |
* JBoyer |
feels silly now |
| 14:16 |
JBoyer |
provided it works, anyway |
| 14:17 |
JBoyer |
And yes, that's all it needs. (and removing the line about search.css from head-meta.hbs) I can push a fix to eg-antora. |
| 14:18 |
JBoyer |
done |
| 14:32 |
Dyrcona |
:) |
| 14:33 |
* Dyrcona |
deals with a mess caused by squashed commits and wishes he still had the original commit chain somewhere..... |
| 14:34 |
Dyrcona |
Maybe ediff or emerge modes in Emacs can repair this? |
| 14:38 |
Dyrcona |
Oh, joy of joys..... This is NOT gonna be fun..... |
| 14:39 |
Dyrcona |
I'm gonna have to split differences, etc. Deleting blank lines in the file was a bad idea...... Maybe I have another way to deal with this? |
| 14:41 |
Dyrcona |
Hm.... If I compare the file to the previous commit rather than the tip of master, that *might* make things easier. |
| 14:44 |
Dyrcona |
It may also be time to stop using rebase and go with merge on the CW MARS custom branch.... |
| 14:45 |
Dyrcona |
Because of the rebase, I can't really find the "previous" commit..... |
| 14:47 |
Dyrcona |
git log -- Open-ILS/examples/opensrf.xml.example # Does the trick? :) |
| 14:48 |
Dyrcona |
And the merge/diff is just as hairy as going with origin/master.... |
| 14:54 |
Dyrcona |
Merge gets the same conflict markers......... |
| 15:26 |
|
jihpringle joined #evergreen |
| 15:28 |
|
jvwoolf joined #evergreen |
| 15:38 |
Dyrcona |
So, I think I'll tackle that again tomorrow morning in the opposite direction. I'm going to start with master and move our changes over, and I'll update the opensrf.xml.example manually after the fact. |
| 15:46 |
|
collum joined #evergreen |
| 15:46 |
Dyrcona |
Hmmm... I just got a "PIN recovery" email from my library's ILS, except I didn't ask for one, and the link is not to my home library, but another one. |
| 15:48 |
* Dyrcona |
emails tsbere to see if they're doing anything system-wide. |
| 16:27 |
|
troy___ joined #evergreen |
| 16:27 |
|
jeffdavis_ joined #evergreen |
| 16:27 |
|
troy__ joined #evergreen |
| 16:27 |
|
jeffdavis joined #evergreen |
| 16:27 |
|
jeffdavis joined #evergreen |
| 16:27 |
|
jeffdavis joined #evergreen |
| 16:40 |
|
khuckins joined #evergreen |
| 16:53 |
|
sandbergja joined #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 17:29 |
|
Dyrcona joined #evergreen |
| 17:54 |
pinesol |
[evergreen|Lisa Carlucci] docs: corrections to the 3.6 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b2c3f81> |
| 17:56 |
pinesol |
[evergreen|Galen Charlton] docs: release notes: adding EOLI to the list of commissioning entities - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f900fbd> |
| 18:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:44 |
|
sandbergja joined #evergreen |
| 18:46 |
sandbergja |
For anybody still around: can I make a URL that opens the patron self-registration form with a specific library selected? |
| 18:46 |
sandbergja |
(apart from setting up another OPAC with that library as physical_loc)? |
| 21:03 |
jtm-lis |
I am looking for a marc21 catalog, that I can query publicly. |
| 21:31 |
|
mrisher joined #evergreen |
| 23:12 |
|
sandbergja joined #evergreen |
