Time |
Nick |
Message |
01:39 |
|
StomproJ joined #evergreen |
01:45 |
|
Guest45619 joined #evergreen |
05:02 |
pinesol_green |
News from qatests: Test Failure <http://testing.evergreen-ils.org/~live> |
06:40 |
|
rlefaive joined #evergreen |
07:11 |
|
rjackson_isl joined #evergreen |
07:16 |
|
agoben joined #evergreen |
07:23 |
|
rlefaive joined #evergreen |
07:39 |
graced |
@coffee |
07:39 |
* pinesol_green |
brews and pours a cup of Ethiopia Yirga Cheffe Koke Espresso, and sends it sliding down the bar to graced |
07:39 |
graced |
mmmmmm |
07:53 |
|
kmlussier joined #evergreen |
07:55 |
kmlussier |
PgTAP live test failure. Must be a release day. |
08:02 |
rhamby |
kmlussier: think of it as getting it out of the way early |
08:06 |
kmlussier |
Beware the Ides of March |
08:13 |
rhamby |
kmlussier: yes but in revenge Octavian took revenge on 300 senators and slew them on an altar dedicated to Ceasar... so slaying bugs is revenge? |
08:14 |
|
rlefaive joined #evergreen |
08:17 |
kmlussier |
rhamby: Do I have to slay 300 bugs? |
08:19 |
rhamby |
kmlussier: I think the actual number should be relative to the crime, so failing a pgtap test isn't quite up there with murder |
08:19 |
kmlussier |
OK, the Concerto users shifted in actor.usr. |
08:20 |
* kmlussier |
is experiencing Déjà vu |
08:22 |
kmlussier |
If I change the id in the test to point to new id 189, we should be good. |
08:23 |
kmlussier |
And add a comment to bug 1672434 that we also need to address the addition of usr records to the sample dataset. |
08:23 |
pinesol_green |
Launchpad bug 1672434 in Evergreen "Improved method for adding new bib records to test dataset" [Undecided,New] https://launchpad.net/bugs/1672434 |
08:40 |
kmlussier |
bug 1673059 for anyone who would like to test and signoff. |
08:40 |
pinesol_green |
Launchpad bug 1673059 in Evergreen "Update passwd storage test" [Undecided,New] https://launchpad.net/bugs/1673059 |
08:44 |
bshum |
kmlussier: I'll test and get that in, since I broke it. |
08:44 |
bshum |
Should only take a moment or two |
08:48 |
|
rlefaive joined #evergreen |
08:51 |
|
mmorgan joined #evergreen |
08:54 |
bshum |
kmlussier++ # test passed for me, pushed to master for you |
08:55 |
kmlussier |
bshum++ Thank you! |
08:58 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1673059: Update passwd storage test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6cd11aa> |
08:59 |
|
Dyrcona joined #evergreen |
09:01 |
|
Callender joined #evergreen |
09:38 |
|
maryj joined #evergreen |
09:44 |
gmcharlt |
I've now branched rel_2_12 in preparation for the RC |
09:44 |
gmcharlt |
and now that that branch exists... I'm declaring a freeze on it :) |
09:45 |
gmcharlt |
specifically, please don't merge anything that is not directly related to the release until I say otherwise |
09:50 |
dbs |
bshum: what the heck? we both ran the live tests and didn't see any issues, right? *sigh* |
09:50 |
JBoyer |
gmcharlt++ |
09:51 |
kmlussier |
gmcharlt++ |
09:51 |
dbs |
gmcharlt++ |
09:51 |
gmcharlt |
kmlussier: do you expect you or DIG to make any additional passes on the release notes today? |
09:52 |
kmlussier |
gmcharlt: No, I don't have the tuits to help. And I didn't hear from anybody else that they would be reviewing them. I think they're good to go. |
09:52 |
gmcharlt |
ok, thanks for confirming |
09:53 |
kmlussier |
Let me rephrase that. I don't have the tuits to look at release notes. Other help might still be available. :) |
09:54 |
kmlussier |
Help will always be given in #evergreen to those who ask for it. |
09:57 |
|
jvwoolf joined #evergreen |
10:00 |
berick |
kmlussier++ |
10:00 |
berick |
help is given at the darkest of times if one only remembers to turn on a light |
10:02 |
abneiman |
kmlussier: gmcharlt: I'm doing a general proofread (for typos etc) on release notes as we speak |
10:10 |
kmlussier |
gmcharlt: And I am just remembering that I didn't take care of Eva's last suggested change in https://bugs.launchpad.net/evergreen/+bug/1667283/comments/5. I'll add a commit for that change, but just say the word if I'm too late. |
10:10 |
pinesol_green |
Launchpad bug 1667283 in Evergreen "Evergreen integration with obalkyknih.cz (Czech added content provider) has not been included to 2.12 beta release notes" [Undecided,New] |
10:11 |
gmcharlt |
kmlussier: have at it! |
10:11 |
gmcharlt |
abneiman++ |
10:11 |
kmlussier |
abneiman++ indeed |
10:35 |
kmlussier |
Are we also doing point release today? I just noticed on the calendar that it's a maintenance release day. |
10:45 |
miker |
kmlussier: were you planning to pull bug 1167541 in? re your question yesterday about my assignment |
10:45 |
pinesol_green |
Launchpad bug 1167541 in Evergreen 2.11 "Pickup library defaults to Home OU of staff, instead of patron when placing holds" [Medium,Confirmed] https://launchpad.net/bugs/1167541 |
10:46 |
kmlussier |
miker: I was just doing general cleanup when looking at RC-targeted bugs. I didn't get a chance to review it. |
10:47 |
miker |
ah, ok |
10:53 |
|
sandbergja joined #evergreen |
10:57 |
kmlussier |
gmcharlt: I've added a commit to the collab branch with abneiman's corrections to the release notes. I think they're really really good to go now. |
10:57 |
gmcharlt |
cool |
10:57 |
kmlussier |
abneiman++ |
11:03 |
remingtron |
kmlussier: quick comment on release notes: This entry is worded strangely: "Add separate make target for translator" |
11:03 |
remingtron |
it says "Add a separate make target during installation..." |
11:04 |
remingtron |
I'd expect it to be something like "A separate make target has been added..." |
11:05 |
remingtron |
kmlussier: also, should security related issues be in a separate section? I'm thinking of "Credit Processor Stripe Settings Permissions" |
11:07 |
gmcharlt |
hey folks - I can accept changes to the release notes up to about 2:30 p.m. EDT today |
11:09 |
kmlussier |
remingtron: Would you be able to push a commit to the tip of the working/collab/kmlussier/2_12RC_release_note_additions with the first change? |
11:09 |
remingtron |
kmlussier: sure |
11:11 |
kmlussier |
As far as the security change, my hope is that sites have already applied the patch to their earlier releases. I could see highlighting it in its own separate section if we were trying to grab their attention to apply the upgrade now. But we did that in the relevant 2.10 and 2.11 point release notes. |
11:11 |
remingtron |
that makes sense |
11:23 |
Bmagic |
dbs: somehow that is not encouraging |
11:56 |
|
Christineb joined #evergreen |
11:59 |
|
khuckins__ joined #evergreen |
12:10 |
|
mmorgan1 joined #evergreen |
12:12 |
|
jihpringle joined #evergreen |
12:27 |
|
pastebot joined #evergreen |
12:29 |
|
jihpringle joined #evergreen |
12:30 |
|
jeff_ joined #evergreen |
12:34 |
|
Jillianne joined #evergreen |
12:47 |
dbs |
Bmagic: yeah, sorry, our experience has not been encouraging :/ |
12:51 |
JBoyer |
dbs, Bmagic, I wonder if our returning 4XX status codes for deleted records might be a problem. If they think our sitemaps are useless because they're full of broken links there's no reason to use them. While returning a 4XX for a "deleted" record may be technically correct, it is still an error status for a result that isn't, strictly speaking, an error. |
12:53 |
kmlussier |
JBoyer: Are deleted records included in the sitemap links? |
12:53 |
dbs |
JBoyer: hmm, your sitemaps are full of links to deleted records? |
12:53 |
JBoyer |
Our sitemaps are updated daily, but records get added and deleted each day. |
12:54 |
JBoyer |
The last 4XX status message in my web console is actually 2/22 and it claims the sitemap was "processed" yesterday, so maybe that's not as big a problem as I'd initially guess.ed |
12:54 |
dbs |
Yeah, I didn't see many of those showing up in our webmaster tools reports from bing / google / yandex |
12:55 |
dbs |
and b) the sitemap generator does avoid deleted records |
12:55 |
JBoyer |
Ah, then that's likely not it. |
12:56 |
dbs |
and c) well behaved search engines will read the sitemaps and note the new/changed records (which we include in chronologically descending order) as well as notice that previously crawled URLs are no longer included on the sitemap |
12:57 |
JBoyer |
These warnings are likely only happening on those rare occasions that a search engine is looking at a map that has had a record deleted that day. (only 12 times since last Feb); I'm not suggesting we're building them incorrectly. |
12:58 |
JBoyer |
I had initially missed the dates on the warnings (there's no way to clear them?) and so I thought we had 31 recent warnings. Oops! |
13:24 |
JBoyer |
exit |
13:24 |
JBoyer |
oops. |
13:35 |
|
tsbere joined #evergreen |
13:36 |
dbs |
hah :) |
13:52 |
|
mmorgan1 left #evergreen |
14:15 |
|
mmorgan joined #evergreen |
14:59 |
gmcharlt |
after I grab a quick late lunch, it's tarball building time. if folks have any final updates to the release notes, nows your chance to slip them in |
15:01 |
|
mmorgan1 joined #evergreen |
15:03 |
|
mmorgan2 joined #evergreen |
15:07 |
JBoyer |
Before I lose any hair over this, has anyone ever seen clark kent symptoms where all reports return "Can't call method "add_worksheet" on an undefined value at /openils/bin/clark-kent.pl line 473." as the error text? |
15:09 |
JBoyer |
never mind, had a bad output_base in opensrf.conf... |
15:09 |
JBoyer |
opensrf.xml, even. |
15:11 |
* miker |
is glad he didn't already start digging into diffs of Spreadsheet::WriteExcel ... |
15:11 |
miker |
s/.../versions... |
15:12 |
JBoyer |
I knew it wouldn't have been that, but I was already at the "copy this clark to that machine" stage myself... :/ If the only other use of $xls to that point hadn't been ->new($file) ' |
15:12 |
* kmlussier |
is glad nobody lost their hair. |
15:12 |
JBoyer |
I'd have likely lost my mind. |
15:12 |
kmlussier |
Or their mind. |
15:27 |
Dyrcona |
Or both. |
15:28 |
kmlussier |
Is there a way we can re-order the column display in the web client grids as we can in the xul client? The middle name, first name, last name order for the patron search gird always throws me off. |
15:29 |
berick |
kmlussier: drag-drop should work |
15:29 |
berick |
it's finicky, but works for me chrome (which I currently have open) |
15:30 |
kmlussier |
berick: hmmmm...I'm having trouble getting it to work for columns that are sortable. |
15:30 |
berick |
kmlussier: grab them by the column name link |
15:30 |
kmlussier |
berick++ |
15:31 |
kmlussier |
berick: You're right, they are a bit finicky. But they'll do. |
15:31 |
berick |
a move left / right clicker in the 'configure columns' section would be a good addition |
15:32 |
|
mmorgan joined #evergreen |
15:36 |
* kmlussier |
agrees |
15:37 |
kmlussier |
In the early web client days, I thought I remember being able to click and drag to resize columns. Now, as far as I can tell, it's only available through the configure menu. It would be nice to be able to click and drag. |
15:37 |
kmlussier |
The cursor turns into a double-headed arrow like it wants to resize that column. |
15:39 |
berick |
kmlussier: yeah, somewhere along the way that bit stopped working |
15:56 |
remingtron |
sandbergja: DIG hackfest tomorrow? |
15:59 |
|
frank_guel joined #evergreen |
16:01 |
frank_guel |
Hi all, regards from México, I'd want to know if the electronic resources could be get the cover image from openlibrary too? I mean, How to make visible an imagen of an electronic resource item into the opac? |
16:01 |
frank_guel |
for example this http://biblioteca.ipicyt.edu.mx/eg/opac/results?query=physics&qtype=keyword&fi%3Aitem_form=&locg=1 |
16:02 |
frank_guel |
it works for a copy but not for electronic resources items |
16:07 |
berick |
frank_guel: hello. added content is accessed by the record's ISBN, UPC, and/or ISSN. (though not all providers support all key types). |
16:08 |
berick |
if no added content is appearing, then the record may not have an ISBN, etc. or the added contentn provider has no content for that particular record. |
16:08 |
Dyrcona |
And ebooks usually have different ISBNs from the print edition. |
16:09 |
Dyrcona |
Though the records sometimes includes the print ISBN. |
16:09 |
frank_guel |
thanks berick por response, for example this one, is an electronic resource in our catalog, http://biblioteca.ipicyt.edu.mx/eg/opac/record/5596?query=physics;qtype=keyword;locg=1;expand=marchtml#marchtml, and the record is available on the open library page, https://openlibrary.org/books/OL25573276M/Studies_of_Credit_and_Equity_Markets_with_Concepts_of_Theoretical_Physics |
16:09 |
pinesol_green |
Showing latest 5 of 11 commits to Evergreen... |
16:09 |
pinesol_green |
[evergreen|Galen Charlton] Docs: more 2.12 release notes updates - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=60b6f06> |
16:09 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: Updates to Czech organizations - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ebff056> |
16:09 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: Grammar tweaks to the 2.12 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=641885d> |
16:09 |
pinesol_green |
[evergreen|Remington Steed] Docs: Slight rewording of release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2988b19> |
16:09 |
pinesol_green |
[evergreen|Remington Steed] Docs: Fix typo, add missing contributing organization - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8f44eff> |
16:12 |
Dyrcona |
frank_guel: Try adding the other ISBN from OpenLibrary to that record. Maybe they're not matching on both? |
16:13 |
berick |
yeah, what Dyrcona said |
16:14 |
Dyrcona |
Evergreen should send them both, but I'm not familiar with OpenLibrary. |
16:14 |
* Dyrcona |
uses ContentCafe. |
16:19 |
frank_guel |
ok, let me try modifying the marc record |
16:21 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1671936: Provide reingest for 1006 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5f612ab> |
16:21 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1671936: Tweak to release notes entry on reingest - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=67b96d2> |
16:21 |
pinesol_green |
[evergreen|Galen Charlton] LP#1671936: add facet reingest to version-upgrade from 2.11.3 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4b25f85> |
16:21 |
pinesol_green |
[evergreen|Galen Charlton] update monolithic schema upgrade script for 2.12-rc - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c377a9e> |
16:35 |
remingtron |
frank_guel: We occasionally have trouble with Open Library cover images caused by bad data in Open Library. |
16:35 |
pinesol_green |
[evergreen|Galen Charlton] Translation updates - newpot - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9a36f33> |
16:35 |
pinesol_green |
[evergreen|Galen Charlton] Translation updates - po files - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=581c918> |
16:37 |
remingtron |
frank_guel: your example looks like one of those cases, since the Open Library "edition" page you shared has a cover image, but the related "works" page does not (https://openlibrary.org/works/OL16998229W/Studies_of_Credit_and_Equity_Markets_with_Concepts_of_Theoretical_Physics) |
16:37 |
pinesol_green |
[evergreen|Galen Charlton] update a couple references of 2.12-beta to 2.12-rc - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0338398> |
16:38 |
remingtron |
frank_guel: one helpful tip: Evergreen uses the Open Library Read API, like this: http://openlibrary.org/api/volumes/brief/json/isbn:0195029216 |
16:39 |
remingtron |
the resulting json data contains a "covers" array if the record has cover images attached |
16:40 |
remingtron |
in your example, there is no "covers" array: http://openlibrary.org/api/volumes/brief/json/isbn:9783834883285 |
16:41 |
remingtron |
so the solution for that example is to login to Open Library and add a cover image to the "works" page |
16:41 |
Dyrcona |
remingtron++ |
16:44 |
frank_guel |
remingtron: I add the cover image to the item, https://openlibrary.org/works/OL16998229W/Studies_of_Credit_and_Equity_Markets_with_Concepts_of_Theoretical_Physics |
16:45 |
pinesol_green |
[evergreen|Mike Rylander] LP#1638377: Allow perl to be installed in non-standard locations - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d95079f> |
16:53 |
remingtron |
frank_guel: After your change, the API still didn't show a "covers" array, so I added the cover image to the "edition" page again, and now the "covers" array is there. |
16:53 |
remingtron |
however, I don't see the image on your catalog page yet |
16:53 |
pinesol_green |
[evergreen|Galen Charlton] LP#1638377: update release notes to mention --with-perlbase - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=782803c> |
16:55 |
remingtron |
frank_guel: you may need to view that record in your Evergreen staff client and use the "Clear AddedContent Cache" link on the right sidebar |
16:57 |
remingtron |
frank_guel: here is the documentation for this feature, in case it helps: http://docs.evergreen-ils.org/2.11/_including_external_content_in_your_public_interface.html#_clear_external_added_content_cache |
16:59 |
frank_guel |
remingtron: at IPICYT we are still on 2.8.4 EG version, so there is no the Clear addedContent cache option, |
17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
17:05 |
remingtron |
frank_guel: Okay. It looks like this feature was added in 2.9: https://bugs.launchpad.net/evergreen/+bug/1435938 |
17:05 |
pinesol_green |
Launchpad bug 1435938 in Evergreen "New Feature: Allow Staff to clear Added Content cache" [Wishlist,Fix released] |
17:06 |
|
Jillianne2 joined #evergreen |
17:07 |
|
mmorgan left #evergreen |
17:08 |
frank_guel |
remingtron: yes, we already looking for upgrade to the last EG version, we actually have a new server where we have 2.11.2 EG version with the same database, and I checked the same item and there the item now shows the cover image |
17:08 |
remingtron |
frank_guel: good! I'm glad you are upgrading, and I'm glad your newer version works! |
17:09 |
frank_guel |
remingtron: so, if we want to show the cover images we need to re-upload the images right? |
17:09 |
|
kmlussier joined #evergreen |
17:12 |
Dyrcona |
frank_guel: Wait about 24 hours for the cache on the current production system to clear. |
17:18 |
kmlussier |
@sortinghat |
17:18 |
pinesol_green |
Hmm... kmlussier... Let me see now... RAVENCLAW! |
17:56 |
gmcharlt |
2.12-rc is now available for download from https://evergreen-ils.org/egdownloads/ |
18:02 |
dbwells |
gmcharlt++ |
18:08 |
gmcharlt |
also, I have created LP milestones for _both_ 2.12.0 and 2.12.1 and divvied up the unfixed bugs that were assigned to 2.12-rc |
18:10 |
gmcharlt |
I was conservative in how I did that: if it wasn't something that visibly affected installation on one or more platforms or caused a lot of JS console spewage, I bumped it to 2.12.1 rather than 2.12.0 |
18:21 |
frank_guel |
remingtron: thanks for your help. It let me understand how it works. |
18:22 |
frank_guel |
As a part of the 2.11.3 EG update testing, I already install EG and it looks working well on opac, but I am getting this message when I want to access to staff client: XML Parsing Error: undefined entity Location: chrome://open_ils_staff_client/content/main/main.xul Line Number 21, Column 1:<window id="main_win" ^ |
18:34 |
dbs |
frank_guel: if you want to remove the cached images right away, you can do something like 'memcrm --servers=localhost ac.jacket.small.0471828726' |
18:34 |
dbs |
(repeating for medium, large in place of small) |
18:35 |
dbs |
memcdump --servers=localhost | grep ac.jacket.large # will show you all of the keys for cached large jackets |
18:35 |
dbs |
not sure what's wrong with your staff client though :( |
18:36 |
frank_guel |
dbs: I reinstalled but it doesn' work :( |
18:49 |
dbs |
frank_guel: sounds like a translation error where the corresponding DTD doesn't contain a definition for an entity in the XML |
18:53 |
|
Jillianne joined #evergreen |
19:09 |
frank_guel |
dbs: yes, I think so, but the problem is how could I change to the US by default |
19:36 |
bshum |
Yeah the packaged 2.11.3 from the website has the problem. Just installed it and encountered the same error. |
19:37 |
bshum |
Only affects es-ES in particular. |
19:37 |
* bshum |
tried with the other ones and found no error immediately |
19:39 |
bshum |
Looks like lang.dtd has no contents in the installed version |
19:39 |
bshum |
From under chrome/locale/es-ES |
19:42 |
bshum |
So my guess is something went wrong in the file during the i18n dance when making the clients for 2.11 |
19:43 |
* bshum |
checks 2.12-rc |
19:43 |
bshum |
Yup, same error. |
19:43 |
bshum |
es-ES is broken for XUL client |
19:46 |
* bshum |
is going to try doing the i18n dance for master and watching specifically for es-ES building to see why lang.dtd is coming up empty |
19:46 |
bshum |
Probably a bad string somewhere in the file that's breaking it |
19:46 |
frank_guel |
bshum: excellent, tks for your help |
19:47 |
bshum |
frank_guel: To get back to US, let's say you could copy the lang.dtd file from any of the other working locales and put it into the es-ES directory for now |
19:47 |
bshum |
And that would work around the problem temporarily and at least let you get your client back to working status |
19:47 |
bshum |
(though of course, not showing the right spanish translations) |
19:48 |
bshum |
So wherever you installed Evergreen on your workstation, like C:\Program Files\Evergreen 2.11.3\ look for chrome\locale\es-ES\lang.dtd file |
19:48 |
bshum |
And replace it with the one from en-US for example |
19:48 |
bshum |
And that should get your client past the error to re-select en-US proper |
19:50 |
frank_guel |
Do I need to restart something? I already change it and the staff client shows the same error |
19:50 |
bshum |
Did you close out of the client completely? |
19:51 |
bshum |
You may have to restart your client session |
19:55 |
frank_guel |
bshum: excellent, I had to restart the laptop, and it works now, Thank you, |
19:56 |
|
jihpringle_ joined #evergreen |
19:56 |
bshum |
frank_guel: Yeah, keep away from es-ES for the XUL client for now. I'll see what we find out about the lang.dtd file once my system finishes compiling it |
19:56 |
bshum |
Well, trying to compile it |
19:57 |
bshum |
Thanks for mentioning the problem :) |
19:57 |
frank_guel |
no problem, tks for your help |
19:57 |
dbs |
bshum++ |
19:57 |
bshum |
Hmmm |
19:57 |
frank_guel |
regards from méxico |
19:58 |
bshum |
So lang.dtd generated in my PO building |
19:58 |
bshum |
Or at least it has content |
20:00 |
bshum |
So strange |
20:01 |
bshum |
frank_guel: http://evergreen-ils.org/~bshum/misc/lang.dtd <-- this is a recent es-ES generated lang.dtd based on master/2.12 |
20:01 |
bshum |
If you copy that down and put it in your es-ES locale, you should get Spanish |
20:01 |
bshum |
For your XUL client |
20:01 |
bshum |
Just a workaround hack for now |
20:01 |
bshum |
I'll keep working through the build process, maybe something is awry with make_release |
20:02 |
bshum |
Or maybe it's something we fixed in master but hasn't been ported properly to the other series |
20:03 |
dbs |
Someone should do a talk about these processes at the conference! |
20:04 |
bshum |
... |
20:04 |
* bshum |
should start writing stuff like this down |
20:04 |
bshum |
For said talk :) |
20:06 |
frank_guel |
thanks , it works, bshum |
20:07 |
bshum |
I'm not sure why the built clients don't have the right content in them. gmcharlt should check his install directory to see what's where. On my test system when I build all the locales, lang.dtd looks fine. And we only just branched rel_2_12 today, so I would have thought the new 2.12-rc client should be fine too. |
20:08 |
bshum |
frank_guel++ Thanks for checking that out for us! |
20:09 |
frank_guel |
:) |
20:09 |
* bshum |
feels like Bmagic encountered this error recently too, but we just weren't sure what we were looking at then; check above for details if you still want Spanish :) |
20:10 |
gmcharlt |
I'll look at it tomorrow |
20:45 |
bshum |
Okay, extra staff client page updated with more recent 2.11 and 2.10 stuff, and the rest (2.10 and 2.9) archived away to the code museum page |