Time |
Nick |
Message |
05:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
06:25 |
|
neet joined #evergreen |
06:40 |
|
neet joined #evergreen |
07:40 |
|
jboyer-isl joined #evergreen |
07:42 |
|
collum joined #evergreen |
07:45 |
|
jboyer-isl joined #evergreen |
07:57 |
|
eeevil joined #evergreen |
07:57 |
|
mtate joined #evergreen |
07:58 |
|
phasefx joined #evergreen |
07:58 |
|
Callender joined #evergreen |
07:59 |
|
graced joined #evergreen |
08:11 |
|
akilsdonk joined #evergreen |
08:32 |
|
mmorgan joined #evergreen |
08:34 |
|
mrpeters joined #evergreen |
08:40 |
|
Stompro joined #evergreen |
08:47 |
|
Shae joined #evergreen |
08:53 |
|
Dyrcona joined #evergreen |
09:01 |
|
kmlussier joined #evergreen |
09:07 |
|
ericar joined #evergreen |
09:15 |
csharp |
quote in zoia's database: |
09:15 |
csharp |
09:04 < zoia_> yo_bj: Quote #2: "the evergreen software development staff is currently playing Quake III, please try again later" (added by edsu at 09:45 PM, September 06, 2005) |
09:15 |
kmlussier |
Heh |
09:24 |
|
jwoodard joined #evergreen |
09:28 |
|
_bott_ joined #evergreen |
09:44 |
|
yboston joined #evergreen |
09:52 |
* csharp |
hates the name "Boopsie" |
09:53 |
csharp |
no opinion of the actual product, though we had to fend off the super aggressive hard sell a few years ago ;-) |
09:59 |
|
neet joined #evergreen |
10:08 |
jcamins |
csharp: they came up with the name at Hernando's Hideaway. |
10:09 |
Bmagic |
Quake III!! Now that's a game I can get into |
10:23 |
jeff |
@who knocked three times and wispered low? |
10:23 |
pinesol_green |
jboyer-isl knocked three times and wispered low. |
10:45 |
jeff |
for those using CollectionHQ, have you ever had interest in including "in-library use" counts for purposes of CollectionHQ extracts? |
10:46 |
jeff |
we're considering adding that ability as an option here, and i'm just wondering if others would have input. |
10:46 |
jeff |
(my intent would be to do it in an optional, generalized fashion and contribute it back to the esi-contrib repo, but if others had input or different needs i'm interested in that also) |
11:13 |
|
vlewis joined #evergreen |
11:14 |
|
snigdha26 joined #evergreen |
11:53 |
|
nhilton joined #evergreen |
11:56 |
|
dreuther joined #evergreen |
12:14 |
* bshum |
doesn't trust "trusty" anymore :( |
12:14 |
jcamins |
bshum: what did trusty do? |
12:15 |
bshum |
jcamins: Made my life hell mostly |
12:15 |
gmcharlt |
question for the room -- is anybody attached to the default eg_vhost.conf creating deflate_log? |
12:15 |
gmcharlt |
if not, I have an itching to remove it |
12:15 |
jcamins |
bshum: oh no! |
12:16 |
bshum |
jcamins: I'm just not sure what we're doing wrong but our fancy "new" database hardware performs terribly right now. |
12:17 |
bshum |
jcamins: And other weird installation quirks that we're still looking into |
12:19 |
jeff |
gmcharlt: i've no attachment. |
12:20 |
berick |
gmcharlt: no attachment to deflate_log |
12:24 |
|
nhilton_ joined #evergreen |
12:47 |
snigdha26 |
Hi I have been trying to commit my local repository to the remote for quite sometime now. I tried following the instructions given on http://evergreen-ils.org/dokuwiki/doku.php?id=dev:git but have been facing several issues |
12:47 |
snigdha26 |
I was able to add the remote branch and create a new repository 'snigdha' in my local machine |
12:48 |
snigdha26 |
but when I tried to push the same to the server I got ssh bad file error |
12:48 |
snigdha26 |
I assumed this might be because my college has blocked access to ssh ports outside the campus, so I decided to remove the current 'working' remote and reset it with the HTTPS connection |
12:49 |
kmlussier |
snigdha26: Did you send along your SSH key to the git admins? |
12:49 |
snigdha26 |
kmlussier: yes I sent the SSH key to the admins and got a reply saying that the key has been added |
12:50 |
snigdha26 |
I think the issue is that since SSH isn't allowed in my college, I will have to work with a HTTPS connection for git. |
12:51 |
snigdha26 |
Do I need to generate a different HTTPS key for this? I mean I tried the following command : git remote add working https://github.com/evergreen-library-system/Evergreen.git |
12:53 |
snigdha26 |
that is replace the ssh format with the https one, but when I tried to push to remote I got a permission denied error. Any idea what to do now? |
12:54 |
Dyrcona |
snigdha26: You can push via HTTPS, that is read only. To push you need the ssh URL. |
12:55 |
Dyrcona |
snigdha26: It sounds like you need to have your keys added to the server. There is an address where you should send them. It should be on the dev:git page from the wiki that you linked to earlier. |
12:55 |
snigdha26 |
Dyrcona: I already did that. |
12:56 |
Dyrcona |
I missed the part where you said ssh is blocked for you. |
12:56 |
Dyrcona |
I've been in a meeting most of the morning and didn't read all of the scrollback. |
12:56 |
snigdha26 |
Dyrcona: Can you please give me an example of how to use this command? "git push working working_branch:user/<username>/working_branch" => It might be I have messed up here, will try that once |
12:57 |
Dyrcona |
Say you have a branch named "fix_buzz" |
12:58 |
Dyrcona |
Do you know your username on the git server? |
12:58 |
Dyrcona |
A generic one for a user with username "username" would look like this: |
12:59 |
Dyrcona |
git push working fix_buzz:user/username/fix_buzz |
12:59 |
snigdha26 |
For the working repository my username is snighda. My github.com name is SnigdhaD though. |
12:59 |
Dyrcona |
What happens when you try to push to the working repository? |
13:00 |
Dyrcona |
It would help if you could try it and copy and paste the exact message that you get. |
13:00 |
|
alisha joined #evergreen |
13:00 |
Dyrcona |
Another thing to check is to run "git remote -v" to see what remotes you have defined and what the URLs are. |
13:01 |
Dyrcona |
I have to go. I'll be back later. |
13:01 |
snigdha26 |
Dyrcona: Give me 2 minutes. I will run the command and paste the error message |
13:01 |
snigdha26 |
okay! Thank you :) |
13:02 |
kmlussier |
snigdha26: Go ahead and paste the message anyway. Somebody else might be able to help out with it while Dyrcona is gone |
13:03 |
|
jihpringle joined #evergreen |
13:05 |
|
nhilton joined #evergreen |
13:05 |
|
dMiller joined #evergreen |
13:05 |
snigdha26 |
C:\Users\Snigdha\Documents\GitHub\ever\Evergreen [snigdha]> git push working snigdha:user/snigdha/snigdha |
13:05 |
snigdha26 |
ssh: connect to host git.evergreen-ils.org port 22: Bad file number fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. |
13:05 |
snigdha26 |
The first one was the command I ran and this is the error I am getting |
13:07 |
snigdha26 |
kmlussier: Since I am unable to push my changes to the remote right now, can I make changes and create pull requests from the github website (like I did the last time)? |
13:12 |
kmlussier |
snigdha26: Sorry. I was pulled away. |
13:12 |
snigdha26 |
kmlussier: no problem :) |
13:15 |
kmlussier |
snigdha26: Sure, you can certainly make the changes through github, but at some point I think it would be good if we could work out the git issues. |
13:16 |
kmlussier |
snigdha26: I'm not the best person to help you troubleshoot git, and I'm guessing the people who can usually help out with these questions are busy at the moment. So you might want to come back (or stay around for a while longer) to see if you can get yourself set up to push to the working repository. |
13:17 |
snigdha26 |
kmlussier: Yeah, it's all because my college authorities have blocked the SSH port :/ . Hopefully someone can guide me on how to circumvent it. I will try and talk to the authorities too once and see if something can be done. |
13:18 |
kmlussier |
snigdha26: If it turns out that you won't be able to do so because of constraints at your university, then we'll have to figure something. But I first would like to hear from some of the git folks here to verify that's the problem. |
13:18 |
snigdha26 |
kmlussier: okay, sure. :) |
13:18 |
jcamins |
kmlussier: if git.evergreen-ils.org isn't configured to allow pushing on HTTPS, there's not really any solution that is going to allow someone with a firewall blocking SSH to push directly to a repo there. |
13:19 |
jcamins |
(but I can't confirm that that is the problem) |
13:19 |
kmlussier |
jcamins: Ok, thanks! That's helpful to know. |
13:19 |
* csharp |
summons gmcharlt for answers^^ |
13:19 |
csharp |
or tsbere |
13:20 |
tsbere |
wait, answers? Why would people want answers? :P |
13:20 |
gmcharlt |
heh |
13:20 |
jcamins |
snigdha26: If the firewall *is* the problem, an option might be to clone the Evergreen repo on GitHub, and push your branches to there and ask your signers-off to push the branches to the working branch when they sign off. |
13:20 |
gmcharlt |
yes |
13:20 |
jcamins |
(supposedly GH allows pushing via https) |
13:21 |
snigdha26 |
jcamins: That's what I did the last time |
13:21 |
jcamins |
snigdha26: ah, okay. |
13:21 |
tsbere |
https is a bit of a tricky thing to deal with. Just getting http *pulling* working can be annoying. |
13:21 |
tsbere |
Given that we identify people on the main git server via their SSH keys I can't see how we could use https right now. >_> |
13:22 |
jcamins |
tsbere: right, that's why I suggested GH, though apparently that's what was already being done. |
13:24 |
* tsbere |
wonders how hard it would be to set up a https-style proxy that people could use to get to the SSH port through annoying firewalls... |
13:24 |
jeff |
tsbere: all depends on how advanced said annoying firewalls are. |
13:24 |
jcamins |
tsbere: I keep on meaning to set up an SSH proxy on port 80. |
13:25 |
kmlussier |
Yes, we had her starting off with the intermediate instructions from here http://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:how-to-contribute-documentation#quick_start_for_new_contributors and editing the file directly in github. |
13:25 |
jcamins |
Not that it would help you, because I'm not planning on sharing passwords to my server. |
13:25 |
jeff |
tsbere: having ssh listen on port 443 is pretty low effort (assuming something isn't listening on that port), but won't help if the network is rejecting ssh traffic on all ports, or is rejecting non-SSL/TLS traffic on port 443. |
13:26 |
tsbere |
jeff: "pretend to be https unless we are talked to like a proxy" can be fun though. ;) |
13:27 |
|
phasefx joined #evergreen |
13:27 |
|
Callender joined #evergreen |
13:27 |
|
pinesol_green joined #evergreen |
13:27 |
jeff |
tsbere: ah, talk SSL/TLS and support HTTP CONNECT style proxying to a specific hostname/port? |
13:30 |
tsbere |
jeff: I don't know 100% how it was done when I saw it before. Point a web browser at it and you get a web page. Point anything that knew what a SOCKS proxy was at it and it proxied. Though I imagine a HTTP proxy would be far easier to configure. |
13:32 |
snigdha26 |
jeff: I think my college hasn't blocked 443 and 80. Thus, routing SSH through these ports *might* work. |
13:33 |
|
pastebot joined #evergreen |
13:53 |
|
sseng joined #evergreen |
14:12 |
jboyer-isl |
bshum: I'm certainly no expert, but what kind of issues are you seeing with your new db server? |
14:27 |
csharp |
our performance on somewhat similar hardware and trusty has not been problematic, but bshum has had his hardware longer |
14:27 |
* csharp |
keeps waiting for the other shoe to drop :-/ |
14:28 |
csharp |
bshum: we can compare configs, etc at the hackaway |
14:44 |
|
akilsdonk joined #evergreen |
14:56 |
bshum |
csharp: I'm not sure I'd say you're not problematic. Your speed isn't that great either. |
14:56 |
|
ericar joined #evergreen |
14:56 |
bshum |
jboyer-isl: I can't quite place it, but basically all our actions are taking longer than I would expect given the equipment we have. |
14:57 |
bshum |
jboyer-isl: Queries seem to run slower, and thus OPAC response is slow, and actions in the staff client too. |
14:57 |
bshum |
I've been going through all our tuning and everything to try and figure out what I might have done wrong with our configuration. |
14:57 |
jboyer-isl |
What do your raids look like? |
14:57 |
bshum |
And I've read a lot of things people have tried with their systems to deal with performance issues. |
14:57 |
bshum |
That's part of the problem too. |
14:57 |
bshum |
We were using RAID10 with four SSD disks |
14:58 |
bshum |
But we're working on trying to get around the embedded RAID controller and going with software RAID. |
14:58 |
bshum |
The one we have doesn't handle SSD TRIM and we know that eventually that could become an issue. |
14:59 |
jboyer-isl |
Ick. They're selling a controller/disk combo that eventually self-destructs? That seems customer-hostile. |
14:59 |
bshum |
Yeah pretty much what I was thinking in the car on the way to the data center. |
15:00 |
jboyer-isl |
I'm spec'ing out another db machine with spinning rust, but I am at least moving up to 15K drives. (current drives are 7.2 I think. :( ) |
15:03 |
bshum |
Yeah |
15:03 |
|
nhilton joined #evergreen |
15:03 |
bshum |
So far, I'm not entirely sold that the 3.13 kernel in Ubuntu 14.04 isn't messing with me somehow. |
15:04 |
bshum |
We're going to try an older kernel and older Ubuntu on our next try. |
15:04 |
bshum |
But the SSD issue bothers me. |
15:05 |
Stompro |
Is there an Evergreen hardware sizing guide anywhere out there? |
15:07 |
bshum |
Stompro: for the server? No there isn't exactly a guide on that. It's more guestimates by experiences presently. |
15:08 |
bshum |
jboyer-isl: Even with our quirks the read speed on the SSDs has been SUPER fun for getting things quickly into cache. |
15:08 |
bradl |
bshum: that SSD issue is really odd. Mind if I ask what RAID card you're running? |
15:09 |
Stompro |
bshum: yes for server sizing. |
15:09 |
jboyer-isl |
bshum: I'll bet. Few would appreciate the dumping and restoring of a huge db quite like new server owners. ;D |
15:12 |
bshum |
bradl: it's starting to drive me a bit mad, but it's a Dell PERC H710p |
15:13 |
bshum |
"In order to use the drives directly, as a so-called JBOD (just a bunch of Drives) instead of a RAID, you need to use a workaround because the built-in controller does not support JBOD directly. You can circumvent this limitation by configuring each drive as an individual RAID 0." |
15:13 |
bshum |
So basically we're screwed :) |
15:13 |
* bshum |
shakes fist at Dell |
15:14 |
bradl |
we don't use Dell hardware for DB, but we do for about everything else |
15:15 |
bshum |
I didn't used to be unhappy with them |
15:15 |
bshum |
But I'm quickly getting there :( |
15:16 |
bradl |
there was one particular PERC card that made the debian install hang recently for me, but I can't recall the exact model |
15:17 |
bradl |
bshum: what filesystem are you using? (sorry about being nosy) |
15:18 |
bshum |
bradl: I don't mind, I could probably use all the extra thoughts we can get right now :( |
15:18 |
bshum |
bradl: We're using ext4, since that's the default that goes with Ubuntu installs. |
15:18 |
bradl |
well, I'm not the resident database guru, but I've been around a lot of them :) |
15:19 |
bradl |
bshum: I'm sure you have the usual "performance" options on there, like not updating atime |
15:20 |
bshum |
bradl: Yeah gmcharlt mentioned that to me a couple weeks ago and we applied that to try helping things out. |
15:20 |
bradl |
I'm usually a step or two behind gmcharlt ;) |
15:21 |
bshum |
Today we tried turning off Intel hyperthreading, since there was an email thread about mixed reactions to performance with that |
15:21 |
bshum |
No noticeable improvements |
15:21 |
bshum |
And we've done a few tweaks to disable some features in the newer kernels that postgresql folk also worry about performance wise |
15:22 |
bshum |
http://www.postgresql.org/message-id/50E4AAB1.9040902@optionshouse.com was one of the threads I was reading on that. In case it matters someday :) |
15:22 |
bshum |
I've been thinking about digging up some postgresql folk to consult on our system implementation. At this point I feel like I'm just bashing my head on a wall. |
15:22 |
bradl |
I think your idea to try to go to a test software raid setup is reasonable. |
15:23 |
|
Shae joined #evergreen |
15:23 |
bshum |
bradl: I just don't know if having the SSDs as RAID0 by the controller and then using software RAID on that will negate TRIM anyways. Due to incompatibilities of TRIM and the RAID controller itself. |
15:23 |
bshum |
Still reading to see what'll do :) |
15:26 |
bradl |
bshum: have you tried wiping the PERC BIOS completely, reverting to default settings, and starting from scratch? |
15:26 |
bshum |
bradl: Yeah I wiped the PERC settings completely. And the installer still can't detect the disks |
15:27 |
bshum |
Basically it's locked them behind the controller |
15:27 |
bshum |
It's holding my drives hostage, damn them! |
15:27 |
bradl |
bshum: by "installer" you mean ubuntu's installer, right? just want to make sure I'm following. |
15:28 |
bshum |
bradl: Correct. |
15:28 |
bradl |
on the PERC I had here that was acting nuts, I had to go into Debian's "expert" installer to get the controller/drives to act right. |
15:30 |
bradl |
of course, I don't recall doing anything heroic, but it seemed the PERC just fell in line when I claimed to be an expert. /me shrugs |
15:30 |
Bmagic |
snigdha26: you could run the TOR proxy on your workstation locally. It will connect to machines all over the globe which will use connections that your University firewall will allow. Then setup your ssh connection to use the local SOCKS5 proxy 127.0.0.1 and viola! you have SSH access |
15:31 |
|
Vanya joined #evergreen |
15:31 |
bradl |
but that was on a Dell R320.. and just just spinning disks |
15:33 |
Bmagic |
@later tell snigdha26 you could run the TOR proxy on your workstation locally. It will connect to machines all over the globe which will use connections that your University firewall will allow. Then setup your ssh connection to use the local SOCKS5 proxy 127.0.0.1 and viola! you have SSH access |
15:33 |
pinesol_green |
Bmagic: The operation succeeded. |
15:33 |
kmlussier |
Bmagic++ |
15:34 |
jeff |
might want to keep in mind that none of these technical workarounds will help if they create a conflict/violation of applicable (university or other) policies. |
15:36 |
jboyer-isl |
bshum: Just to check, what have you done in postgesql.conf? i.e. run pgtune or more? |
15:37 |
Vanya |
Hello everyone, I am Vanya. I am interested in contributing to Evergreen for the OPW Round-9. I am very fascinated by the "Awesome Box Project" and was wondering if someone could tell me more about it and how to proceed. |
15:39 |
Bmagic |
bshum: can you run bonnie++ utility on your disks and get some sort of measuring stats for me? In addition run dd if=/dev/zero of=/folder/raid10ssd bs=1M count=10000 and see what you get. bonnie++ is the most informative |
15:40 |
kmlussier |
Vanya: You might want to start with some of the steps of the Learning About Evergreen section of http://wiki.evergreen-ils.org/doku.php?id=opw |
15:41 |
kmlussier |
Vanya: Maybe getting started with downloading the client from one of our community demo servers to get familiar with it. |
15:41 |
|
myra joined #evergreen |
15:42 |
* kmlussier |
needs to duck out for a while. |
15:42 |
|
myra left #evergreen |
15:43 |
Vanya |
kmlussier: Thank you. |
15:43 |
Bmagic |
bshum: I might have missed something but did this exact hardware have another OS that performed btter? |
15:44 |
|
myra joined #evergreen |
15:48 |
bshum |
Bmagic: No we haven't determined that either. I was just going with the "but the CPUs and RAM are so much better" mindset on this equipment. |
15:48 |
bshum |
So it must be something in the way we're configured. |
15:49 |
bshum |
Either that or i just have super unrealistic expectations :D |
15:49 |
bshum |
But basically, our older HP database servers have 0.5 less GHz, and run slower memory too. |
15:49 |
bshum |
But things were "faster" then |
15:49 |
bshum |
It's super strange. |
15:49 |
Bmagic |
bshum: can you provide I/O numbers to back up your theory? |
15:50 |
bshum |
Bmagic: Nothing specific. And we don't have the old HPs available to test with anymore. |
15:50 |
bshum |
Those became the Hyper-V servers :) |
15:50 |
bshum |
It's more of a general "Evergreen isn't supposed to be THIS slow" feeling right now. |
15:51 |
* bshum |
is being unscientific in the face of imminent system disaster :) |
15:51 |
Bmagic |
bshum: have you configured SSD's on RAID10 before? |
15:51 |
bshum |
Bmagic: We've never had SSDs before. |
15:51 |
bshum |
So, no. :) |
15:53 |
bshum |
We're going back to the hardware RAID10 setup using the controller for now. We'll fight the TRIM battle another day, but I want to get some tests done with an older Ubuntu just to see if that makes any differences at all. |
15:53 |
bshum |
The last DB we had was actually a 10.04 server even |
15:53 |
bshum |
So who knows |
15:54 |
Bmagic |
bshum: I have worked on this subject matter quite a bit and I have read that SSD's in RAID doesn't always make it faster depending on the controller. Here is an article on the R720 with RAID10 SSD's. He claims that the more SSD's you add, the slower they go! http://www.brentozar.com/archive/2013/08/load-testing-solid-state-drives-raid/ |
15:54 |
bshum |
Bmagic: Yeah I believe that. |
15:54 |
Bmagic |
"when dealing with small random operations, more drives may not be faster. In fact, the more drives you add, the slower writes get, because the controller has to manage a whole lot of writes across a whole bunch of drives." |
15:55 |
bshum |
Bmagic: that somehow doesn't surprise me |
15:55 |
|
ningalls joined #evergreen |
15:55 |
bshum |
Now I wish I had gotten PCI-E SSD storage |
15:55 |
bshum |
:D |
15:55 |
bshum |
Just 'cause |
15:55 |
bshum |
Since we apparently gain nothing with this controller. |
15:56 |
bradl |
bshum: I have some stories to share about PCI-E SSDs. They aren't pretty. |
15:56 |
bshum |
bradl: Ugh, nevermind then :) |
15:57 |
bradl |
we moved to RAID because, well, the RAID card handles failure gracefully. Or is supposed to. If a PCI-E card blows up, well, you're all blowed up. (excuse the Georgia talk there) |
15:57 |
bradl |
...and we had some blow ups |
15:58 |
bshum |
Yuck |
15:58 |
bshum |
And boo, hiss |
15:59 |
* bshum |
wants magic hardware that just works™ |
16:01 |
|
_bott_ joined #evergreen |
16:01 |
jcamins |
bshum: I'll take two orders of magic hardware that just works™, please. I can resell anything I don't need for a sizable profit. |
16:02 |
bshum |
jcamins++ |
16:08 |
|
ningalls joined #evergreen |
16:10 |
|
_bott_ joined #evergreen |
16:11 |
bshum |
dbs: Heh, just tried the fresh install of a standalone PG server. |
16:11 |
bshum |
And the one thing I didn't remember |
16:11 |
bshum |
We need to install "make" first |
16:11 |
bshum |
Before we can use the make -f ;) |
16:12 |
bshum |
So a literal reader of the install steps for a standalone DB would fail on that first move. |
16:12 |
|
kmlussier joined #evergreen |
16:13 |
bshum |
Oh and apparently it installed PG 9.1 of course... cause it's a precise system now, not a trusty one :( |
16:13 |
* bshum |
uninstalls and reinstalls |
16:15 |
|
dbs joined #evergreen |
16:19 |
csharp |
we didn't have good times with PCIe SSDs either |
16:21 |
gmcharlt |
annoying, crashy, data-losing things |
16:22 |
jeff |
those are bad things. |
16:24 |
|
dMiller joined #evergreen |
16:26 |
* bshum |
taps his fingers waiting for pg_restore to run on the newly reformatted test server |
16:34 |
|
tspindler left #evergreen |
16:36 |
|
nhilton joined #evergreen |
16:59 |
|
buzzy joined #evergreen |
17:18 |
|
mmorgan left #evergreen |
17:20 |
pinesol_green |
[evergreen|Kathy Lussier] Release notes repair to fix PDF build - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=27e4401> |
17:30 |
|
berick joined #evergreen |
17:46 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
18:58 |
|
mrpeters joined #evergreen |
19:02 |
|
mrpeters joined #evergreen |
19:05 |
|
sarabee joined #evergreen |
19:28 |
|
sarabee joined #evergreen |
19:32 |
|
bmills joined #evergreen |
20:34 |
|
dMiller joined #evergreen |
21:34 |
|
buzzy joined #evergreen |
21:53 |
|
_bott_ joined #evergreen |
21:53 |
|
Callender joined #evergreen |
21:53 |
|
phasefx joined #evergreen |
21:53 |
|
mtate joined #evergreen |
21:53 |
|
eeevil joined #evergreen |
21:54 |
|
berick joined #evergreen |
21:54 |
|
tsbere joined #evergreen |
21:54 |
|
dbwells joined #evergreen |
21:54 |
|
bradl joined #evergreen |
21:54 |
|
rangi joined #evergreen |
21:54 |
|
ldw joined #evergreen |
21:54 |
|
chatley_ joined #evergreen |
21:54 |
|
mnsri- joined #evergreen |
21:54 |
|
ktomita joined #evergreen |
21:54 |
|
b_bonner joined #evergreen |
21:54 |
|
shadowspar joined #evergreen |
22:03 |
|
newGuy joined #evergreen |
22:06 |
|
newGuy joined #evergreen |
22:06 |
newGuy |
hi I have a nontechnical question |
22:06 |
newGuy |
really looking for advice on operation/method |
22:07 |
newGuy |
is this the right place to ask? |
22:19 |
|
kmlussier joined #evergreen |
22:39 |
kmlussier |
When I look at https://translations.launchpad.net/evergreen/master, it appears as if Evergreen is largely translated in Armenian. But when I look here - http://docs.evergreen-ils.org/2.6/_setting_a_default_language_and_adding_optional_languages.html - Armenian isn't listed. |
22:39 |
kmlussier |
Is that because the docs are outdated or is it because I'm misunderstanding the information in Launchpad? |