← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 00:01 | cait left #koha | |
| 00:16 | Bahruz joined #koha | |
| 00:36 | rocio left #koha | |
| 00:39 | tcohen | eythian++ |
| 00:43 | night #koha | |
| 00:55 | eythian | why on earth is the whole OAI library in opac/oai.pl, and not actually in C4 where it's naming claims it should be? |
| 00:57 | * dcook | perks up |
| 00:57 | wizzyrea | http://www.clockworksms.com/?u[…]&utm_campaign=Oct huh. |
| 00:57 | dcook | Yeah! |
| 00:57 | MrAgent075 joined #koha | |
| 00:58 | dcook | eythian: I wondered that quite a bit |
| 01:43 | wizzyrea | ...that moment when you set out to do a thing, then realised you needed 3 other things to do that thing, did those things, then forgot what the original thing was. |
| 01:44 | that's me right now. | |
| 01:55 | bug 10944 | |
| 01:55 | huginn | 04Bug http://bugs.koha-community.org[…]_bug.cgi?id=10944 minor, P5 - low, ---, robin, Passed QA , Mixed content warnings in results and detail with Amazon images on https |
| 01:56 | wizzyrea | gmcharlt - is there a concern about that one/ |
| 01:56 | ? | |
| 01:57 | just curious :) | |
| 03:11 | eythian | OAI-PMH requests are /so very slow/ |
| 03:11 | wahanui | Hmm. No matches for that, eythian. |
| 03:18 | eythian | mtompset: your filter thing should probably also be applied to systems like OAI-PMH too. |
| 04:10 | dcook | eythian: super super slow |
| 04:11 | eythian | yeah, it's like they're going to special effort to do it. |
| 04:11 | I should chuck a profiler at them some time. | |
| 04:11 | * dcook | nods |
| 04:12 | dcook | When I was building the OAI harvester, the slowness was killing me. Admittedly, a big part of that was probably the processing, but the requests definitely added a fair bit of time |
| 04:12 | * dcook | should look at that again someday |
| 04:13 | eythian | I'm getting about 4 bibs per second, running with two threads. There's no reason for it to take ~0.5 secs per request. |
| 04:20 | dcook | How big is your request size? |
| 04:21 | I think my average was about 5 and the best I ever did was about 10 | |
| 04:22 | eythian | what do you mean? |
| 04:24 | dcook | Mmm, I suppose I'm talking about something completely different |
| 04:24 | eythian | I'm just pulling records via OAI-PMH one at a time in order to identify the ones that make it break. |
| 04:25 | dcook | Mmm, and they do make it break.. |
| 04:25 | I think I added some handling for that locally.. | |
| 04:25 | I was talking more about large requests with a maximum cap | |
| 04:25 | eythian | yeah, it is sensitive to badly encoded XML, however those records also need to be fixed anyway, so they want a list of them. |
| 04:25 | ah right | |
| 04:25 | dcook | Mmm, makes sense |
| 04:26 | Although going one by one seems awful | |
| 04:26 | Won't MarcLint pick those up? | |
| 04:26 | eythian | probably, but I thought this'd be faster. |
| 04:26 | No matter, I'm going to leave it to run overnight anyway. | |
| 04:26 | dcook | More reliable, I imagine |
| 04:26 | Your way that is | |
| 04:27 | eythian | probably is, yeah |
| 04:28 | Because of the dumb design of the library, you can't just plug into it and bypass the whole networking thing either. | |
| 04:28 | well, I suppose I could have called the .pl ddirectly | |
| 04:28 | should have done that. | |
| 04:29 | dcook | Hmm, yeah, that probably would've worked better |
| 04:46 | Yaxh joined #koha | |
| 04:56 | mtompset | eythian: Say what?! |
| 04:57 | Don't go making the scope huge. :P | |
| 05:35 | eythian: You there? | |
| 05:36 | cait joined #koha | |
| 05:36 | mtompset | @later tell eythian Check out bug 11592. That's my work so far. |
| 05:36 | huginn | mtompset: The operation succeeded. |
| 05:39 | mtompset | Greetings, cait. And good day (24 hour period). :) |
| 05:39 | Have a great day (24 hour period), #koha. | |
| 05:40 | cait | hi all |
| 05:56 | @wunder konstanz | |
| 05:56 | huginn | cait: The current temperature in Taegerwilen, Taegerwilen, Germany is 1.5°C (6:55 AM CET on January 22, 2014). Conditions: Overcast. Humidity: 97%. Dew Point: 1.0°C. Windchill: 2.0°C. Pressure: 29.86 in 1011 hPa (Steady). |
| 06:01 | * dcook | waves to cait |
| 06:01 | dcook | Switching from Outkast to Iron & Wine is jarring... |
| 06:03 | cait | ? |
| 06:30 | dcook | Sorry, that was unrelated to me waving ;) |
| 06:56 | cait | hm music? |
| 07:16 | laurence joined #koha | |
| 07:21 | dcook | @later tell cait: Yep |
| 07:21 | huginn | dcook: The operation succeeded. |
| 07:23 | dcook | night all |
| 07:23 | wahanui | goodnight dcook. You'll be back. |
| 07:26 | * magnuse | waves |
| 07:26 | magnuse | @wunder boo |
| 07:26 | huginn | magnuse: The current temperature in Bodo, Norway is -4.0°C (8:20 AM CET on January 22, 2014). Conditions: Clear. Humidity: 36%. Dew Point: -17.0°C. Windchill: -12.0°C. Pressure: 30.12 in 1020 hPa (Steady). |
| 07:37 | reiveune joined #koha | |
| 07:37 | reiveune | hello |
| 07:48 | sophie_m joined #koha | |
| 07:50 | magnuse | bonjour reiveune sophie_m |
| 07:50 | eythian++ for quickly packaging libmarc-xml-perl | |
| 07:56 | alex_a joined #koha | |
| 07:56 | alex_a | bonjour |
| 07:56 | wahanui | salut, alex_a |
| 07:57 | cait joined #koha | |
| 07:57 | cait | good morning #koha |
| 07:59 | sophie_m | hello magnuse (you're double ^^) |
| 07:59 | koha joined #koha | |
| 07:59 | sophie_m | hi #koha and cait |
| 07:59 | cait | hi sophie_m |
| 07:59 | :) | |
| 07:59 | koha | hi, my name is Quyen |
| 07:59 | sophie_m | woo, koha himself is there ! |
| 07:59 | koha | From Viet Nam |
| 08:00 | sophie_m | :-) |
| 08:00 | koha | I've just known koha |
| 08:01 | and I like it, but it is quite difficult to do perfect if there is little knowledge about IT. | |
| 08:03 | magnuse | sophie_m: yup, i cloned myself to be able to do twice as much work |
| 08:04 | sophie_m | \o/ |
| 08:06 | magnuse | :-) |
| 08:07 | Joubu joined #koha | |
| 08:07 | Joubu | hi o/ |
| 08:13 | nlegrand | Hey #koha |
| 08:16 | magnuse | hiya Joubu and nlegrand |
| 08:29 | gaetan_B joined #koha | |
| 08:29 | gaetan_B | hello |
| 08:29 | wahanui | kai ora, gaetan_B |
| 08:39 | alex_a joined #koha | |
| 09:00 | cait | good morning Joubu |
| 09:45 | MrAgent075 joined #koha | |
| 10:05 | Brooke joined #koha | |
| 10:05 | Brooke | @later tell druthb *hugs* |
| 10:05 | huginn | Brooke: The operation succeeded. |
| 10:12 | paul_p joined #koha | |
| 10:16 | khall joined #koha | |
| 10:30 | gaetan_B joined #koha | |
| 11:26 | Joubu joined #koha | |
| 11:59 | tcohen joined #koha | |
| 12:13 | tcohen joined #koha | |
| 12:15 | tcohen | morning! |
| 12:15 | wahanui | well, morning is a state of cat |
| 12:17 | liw | shameless self-promotion, but just in case anyone here would find this useful, or knows someone who might find it useful: http://yakking.branchable.com/ |
| 12:19 | magnuse | liw++ - sounds good! |
| 12:20 | tcohen | gmcharlt: do u remember when DOM became the default for authorities? |
| 12:26 | laurence left #koha | |
| 12:27 | tcohen | Joubu: should we default to DOM for authorities? |
| 12:30 | irc meeting? | |
| 12:30 | Joubu | tcohen: I am still using grs1 for auth, but my dev installation is quite old |
| 12:31 | tcohen | I found that rebuild_zebra.pl assumes bib -> grs-1 && auth -> dom if not defined |
| 12:31 | so your patch should need some tweaking I guess | |
| 12:32 | git log daca5edc | |
| 12:34 | vfernandes joined #koha | |
| 12:35 | vfernandes | Hi |
| 12:36 | guys it's possible to generate the serials for one subscription? for example, i have a subscription from 2014-01-01 to 2015-01-01... it's possible to generate all serials/numbers at one time? | |
| 12:48 | mtompset joined #koha | |
| 12:48 | mtompset | Greetings, #koha. |
| 12:52 | tcohen | morning mtompset |
| 12:52 | mtompset | Greetings, tcohen. |
| 12:54 | What fun things are you up to today? | |
| 12:56 | tcohen | mtompset: I'm about to fill a bug related to reporting the user missing entries in koha-conf.xml |
| 12:58 | mtompset | That could potentially save me time from manually comparing a fresh install koha-conf.xml against my upgrade each time. ;) |
| 12:58 | tcohen | exactly :-D |
| 13:01 | JesseM | @wunder 06614 |
| 13:01 | huginn | JesseM: The current temperature in Brewer Stratford Marina, Stratford, Connecticut is -16.6°C (8:01 AM EST on January 22, 2014). Conditions: Overcast. Humidity: 54%. Dew Point: -24.0°C. Windchill: -29.0°C. Pressure: 29.79 in 1009 hPa (Steady). Wind Chill Advisory in effect until 11 am EST this morning... |
| 13:01 | mtompset | Greetings, JesseM. |
| 13:02 | JesseM | its a cold morning. |
| 13:02 | mtompset | @wunder l7e 5y5 |
| 13:02 | huginn | mtompset: The current temperature in Schomberg, Ontario is -29.4°C (8:02 AM EST on January 22, 2014). Conditions: Scattered Clouds. Humidity: 70%. Dew Point: -33.0°C. Windchill: -29.0°C. Pressure: 30.17 in 1022 hPa (Falling). |
| 13:02 | JesseM | Hi mtompset |
| 13:02 | mtompset | -29?! GAH! |
| 13:02 | JesseM | wow |
| 13:02 | tcohen | @wunder cordoba, argentina |
| 13:02 | huginn | tcohen: The current temperature in Bo Alto de San Martin, Cordoba City, Argentina is 31.6°C (10:00 AM ART on January 22, 2014). Conditions: Scattered Clouds. Humidity: 56%. Dew Point: 22.0°C. Pressure: 29.58 in 1002 hPa (Rising). |
| 13:02 | * mtompset | glares at tcohen. |
| 13:03 | meliss joined #koha | |
| 13:03 | mtompset | Did you have to point that out? :P |
| 13:03 | JesseM | :) |
| 13:03 | cait | @wunder Konstanz |
| 13:03 | huginn | cait: The current temperature in Konstanz, Germany is 5.0°C (2:00 PM CET on January 22, 2014). Conditions: Overcast. Humidity: 65%. Dew Point: 1.0°C. Pressure: 29.90 in 1012 hPa (Falling). |
| 13:03 | * cait | suggests meeting in the middle :) |
| 13:03 | mtompset | Greetings, cait. |
| 13:03 | Roadtrip! ;) | |
| 13:03 | JesseM | Hi cait |
| 13:06 | tcohen | its 10 in the morning and is *already* 31.6, we are melting today |
| 13:06 | true story | |
| 13:10 | mtompset | Well, fix the planetary air streams or something, and send some heat this way! :P |
| 13:11 | tcohen | :-P |
| 13:15 | oleonard joined #koha | |
| 13:15 | mtompset | Greetings, oleonard. |
| 13:16 | tcohen | Joubu: i've attached a new patch that does what you wanted to do |
| 13:17 | oleonard | Hi |
| 13:18 | marcelr joined #koha | |
| 13:19 | tcohen | hi oleonard |
| 13:26 | marcelr joined #koha | |
| 13:35 | NateC joined #koha | |
| 13:40 | Joubu | tcohen: ok, I'll test it |
| 13:40 | tcohen: ho yes, my patch was wrong! | |
| 13:42 | nengard joined #koha | |
| 13:47 | magnuse | @wunder boo |
| 13:47 | huginn | magnuse: The current temperature in Bodo, Norway is -4.0°C (2:20 PM CET on January 22, 2014). Conditions: Clear. Humidity: 43%. Dew Point: -15.0°C. Windchill: -12.0°C. Pressure: 30.12 in 1020 hPa (Steady). |
| 13:55 | Dyrcona joined #koha | |
| 13:56 | tcohen | cait: http://snag.gy/z9ewN.jpg |
| 13:58 | talljoy joined #koha | |
| 14:06 | tcohen | #koha: need your feedback on this: http://snag.gy/MtOAB.jpg |
| 14:06 | do u like it like that? | |
| 14:08 | cait | looks good to me |
| 14:08 | tcohen | and the wording? |
| 14:08 | wahanui | the wording is fine. easy to understand. by adding 'temporary' it will be crystal clear. |
| 14:09 | * tcohen | knows he could leave it like that and galen would put it rigt anyway+ |
| 14:11 | edveal joined #koha | |
| 14:20 | tcohen | @seen gmcharlt |
| 14:20 | huginn | tcohen: gmcharlt was last seen in #koha 15 hours, 3 minutes, and 56 seconds ago: <gmcharlt> noted, thanks |
| 14:23 | magnuse | wahanui: forget the wording |
| 14:23 | wahanui | magnuse: I forgot wording |
| 14:23 | druthb | magnuse! |
| 14:23 | wahanui | somebody said magnuse was afraid that we added another 10000 bugs while he was eating pizza. |
| 14:27 | collum joined #koha | |
| 14:28 | magnuse | druthb! |
| 14:28 | wahanui | Well, she finally snapped, like we all knew she would. |
| 14:30 | tgoatley joined #koha | |
| 14:34 | tcohen | mtompset: bug 11596 |
| 14:34 | huginn | 04Bug http://bugs.koha-community.org[…]_bug.cgi?id=11596 enhancement, P5 - low, ---, koha-bugs, Needs Signoff , Missing indexing options in koha-conf.xml should be reported |
| 14:36 | mtompset | tcohen: There's only 2 variables in it. |
| 14:37 | vfernandes | it's possible to generate the serials for one subscription? for example, i have a subscription from 2014-01-01 to 2015-01-01... it's possible to generate all serials/numbers at one time? |
| 14:37 | tcohen | mtompset: what about that? |
| 14:37 | mtompset | I was hoping it was going to be a little more comprehensive. :) |
| 14:38 | tcohen | oh, I think if we agree on that patch, we could fill new bugs for each config entry we find |
| 14:38 | i'm focused on 11096 right now | |
| 14:39 | mtompset | Right. Hence just these two variables. |
| 14:39 | tcohen | true |
| 14:39 | mtompset | I'll sign it off later. I'm in the middle of other things. |
| 15:03 | maximep joined #koha | |
| 15:12 | barton | where do I go to report perl abuse? |
| 15:16 | tcohen | what you mean "perl abuse"? |
| 15:17 | barton | misc/cronjobs/advance_notices.pl line 242: my $digest = $due_digest->{$upcoming->{'borrowernumber'}} ||= {}; |
| 15:19 | tcohen | just fill a bug mentioning the problem |
| 15:19 | barton | This sets $due_digest by auto-vivifying it to a hash reference. |
| 15:19 | Yeah. It's not wrong, per se, just ugly as sin. | |
| 15:24 | tcohen | barton: just report it and comment a possible solution or provide an actual patch for others to review |
| 15:25 | barton | 'k |
| 15:25 | thanks. | |
| 15:28 | tcohen | np |
| 15:32 | rocio joined #koha | |
| 15:33 | tgoatley joined #koha | |
| 15:39 | mtompset | Oh my! That is perl abuse. :P |
| 15:40 | rhcl joined #koha | |
| 15:46 | meliss joined #koha | |
| 15:46 | Dyrcona | Swap the ||= for just || and its not abuse. :) |
| 16:03 | mtompset | Dyrcona: I think it is attempting to do TWO assignments at the same time. |
| 16:05 | Dropping the = would only be ONE assignment, the $due_digest->{$upcoming->{'borrowernumber'}} would still be undef, 0, '', NULL. | |
| 16:18 | barton | Dyrcona -- no, that breaks things, because $due_digest *isnt' set* before that call. I found this because I was inspeting the code, trying to figure out where it was set... I had to run it through the debugger to figure it out. |
| 16:19 | Dyrcona | barton: Depends on what you are trying to do. Just that line by itself, looks like you don't need the = after the ||. |
| 16:27 | reiveune | bye |
| 16:27 | reiveune left #koha | |
| 16:42 | rhcl | @seen bag |
| 16:42 | huginn | rhcl: bag was last seen in #koha 1 week, 5 days, 17 hours, 26 minutes, and 57 seconds ago: * bag makes a loud banging noise |
| 16:42 | rhcl | @wunder 64507 |
| 16:42 | huginn | rhcl: The current temperature in Wyatt Park, St Joseph, Missouri is -5.1°C (10:42 AM CST on January 22, 2014). Conditions: Clear. Humidity: 60%. Dew Point: -12.0°C. Windchill: -5.0°C. Pressure: 30.24 in 1024 hPa (Rising). Wind Chill Advisory in effect from 9 PM this evening to 11 am CST Thursday... |
| 16:43 | rhcl | @seen sekjal |
| 16:43 | huginn | rhcl: sekjal was last seen in #koha 37 weeks, 5 days, 3 hours, 13 minutes, and 52 seconds ago: <sekjal> our camera was put up late this year; the eggs were already there when we installed |
| 16:54 | mtompset | @marc 541 |
| 16:54 | huginn | mtompset: Information on the immediate source of acquisition of the described materials. The field is used primarily for original or historical items or other archival collections. (Repeatable) [a,b,c,d,e,f,h,n,o,3,5,6,8] |
| 16:54 | mtompset | @marc 541$e |
| 16:54 | huginn | mtompset: unknown tag 541$e |
| 16:54 | mtompset | @marc 541 e |
| 16:54 | huginn | mtompset: Accession number The identification code assigned to materials acquired in a single and separate transfer of custody. |
| 16:55 | mtompset | @marc 952 i |
| 16:55 | huginn | mtompset: unknown field/subfield combination (952/i) |
| 16:56 | mtompset | Can someone explain to me what 541$e and 952$i are and how they should be entered in marc_subfield_structure? |
| 17:06 | nengard | http://www.loc.gov/marc/holdings/hd541.html |
| 17:06 | koha doesn't use this ... | |
| 17:06 | marc format for holdings data or MFHD is not something Koha uses - Koha uses the 952 for holdings data | |
| 17:08 | 952 doesn't have an i that i can find ... | |
| 17:08 | cait | 952$i is an accession/inventory number |
| 17:08 | it's saved into stocknumber in items | |
| 17:09 | and there is also an index on it | |
| 17:09 | it#s mostly a european thing | |
| 17:09 | it's required here by law in germany and it seems to be required in France as well | |
| 17:09 | it's an additional number, different from barcode or callnumber | |
| 17:09 | often using a year + number schema | |
| 17:10 | we have plugins to generate those, if you look for stocknumber in the frameworks | |
| 17:10 | normally the number will be written or stamped into the book | |
| 17:11 | and will never change, while a barcode or callnumber can change | |
| 17:11 | it's in the default framworks, but maybenot for old updated installations, i think it got added sometime around.. hm. 3.4 maybe? | |
| 17:13 | hm hope that made sense ) | |
| 17:15 | mtompset | Mostly. |
| 17:15 | Sorry, I was writing an email to the list in the background, before I read this. Oops. :) | |
| 17:15 | cait | 941 is title level... we need it item level |
| 17:15 | mtompset | 541, not 941. |
| 17:15 | cait | ah |
| 17:16 | well koha doesn't use holdings the way marc does | |
| 17:16 | like nicole said | |
| 17:16 | @marc 541 | |
| 17:16 | huginn | cait: Information on the immediate source of acquisition of the described materials. The field is used primarily for original or historical items or other archival collections. (Repeatable) [a,b,c,d,e,f,h,n,o,3,5,6,8] |
| 17:16 | mtompset | So they both should map to stocknumber? |
| 17:17 | And what tab should they be on? | |
| 17:17 | cait | ? |
| 17:17 | i don't think koha does anything with 541 currently | |
| 17:17 | mtompset | See the email, I sent. |
| 17:17 | cait | we CAN only map 1 field |
| 17:18 | and the intend of 952$i stocknumber is item level, so that's how it works now | |
| 17:18 | hm don't have a mail from you yet | |
| 17:18 | ah found it | |
| 17:19 | wow | |
| 17:19 | 541 shouldn't be mapped to items.stocknumber | |
| 17:19 | i did the original patches and it ws not like that when i did it. | |
| 17:19 | are you sure you didn't remap it? | |
| 17:19 | al fields in items.* shoudl only be mapped to 952 fields | |
| 17:20 | or you most certainly will get into trouble | |
| 17:20 | pastebot | "mtompset" at 127.0.0.1 pasted "Here's my SQL results" (24 lines) at http://paste.koha-community.org/95 |
| 17:21 | mtompset | 541$e is the only mess I have. |
| 17:21 | cait | http://git.koha-community.org/[…]1ebbd13e70f266d77 |
| 17:21 | looking at the en default framework - it's only mapped to 952$i there as it should | |
| 17:22 | same goes for the simple frameworks | |
| 17:22 | http://git.koha-community.org/[…]1ebbd13e70f266d77 | |
| 17:22 | and fast add :) | |
| 17:22 | mtompset | So, it's something my librarian colleagues broke? |
| 17:22 | cait | you must have remapped it locally |
| 17:22 | yep | |
| 17:23 | well somoene | |
| 17:23 | buti don't think you can install koha with a mapping on 541 | |
| 17:23 | Joubu | bye #koha |
| 17:23 | Joubu left #koha | |
| 17:24 | cait | really late here - bbl |
| 17:24 | cait left #koha | |
| 17:29 | mtompset | there... blanked kohafield for tag='541' and all is well. :) |
| 17:31 | dani joined #koha | |
| 18:06 | mtompset | Oh shoot. I found out what we did wrong historically to cause that. |
| 18:06 | Now I have 7700+ records to tweak. | |
| 18:07 | cait joined #koha | |
| 18:07 | * cait | waves |
| 18:08 | tcohen | hi cait! |
| 18:08 | cait | :) |
| 18:11 | rhcl | waves |
| 18:18 | mtompset | cait: I just realized we were using 541$e for stocknumber in our imports. |
| 18:18 | oh what a lovely mess from upgrading from a 3.6.3 tarball mess to now. | |
| 18:21 | Dyrcona | Everyone doesn't just upgrade via git? |
| 18:22 | cait | Dyrcona: it's not recommended |
| 18:22 | well to install in dev mode | |
| 18:23 | Dyrcona | :) |
| 18:23 | cait | and i think when you install tarball or standard from git it's not such a big difference hm. |
| 18:24 | i might not make sense, it was a long day | |
| 18:37 | mtompset | No, but we didn't know much about the inner workings of Koha when we first started. |
| 18:37 | And we didn't ask the community. | |
| 18:38 | Then we got these problems as a result. | |
| 18:38 | It's a 2 year old mistake. :) | |
| 18:38 | MrAgent075 joined #koha | |
| 18:41 | mtompset | Why Mr Agent 075? Why not MrAgentMan? |
| 18:42 | (http://youtu.be/6iaR3WO71j4) -- Secret Agent Man. | |
| 18:48 | tcohen | bye #koha |
| 18:50 | mtompset | @marc 01e |
| 18:50 | huginn | mtompset: unknown tag 01e |
| 18:51 | mtompset | Anyone know about 'Coded field error'? |
| 19:02 | blou | !ahok iH |
| 19:03 | cait | hi blou |
| 19:03 | blou | hi cait!! |
| 19:03 | long time no chat | |
| 19:04 | * blou | was assigned to solitary confinement |
| 19:06 | blou | QUestion at large: what is the best way to UPDATE records in Koha, using a Marc (bin or xml) file ? |
| 19:06 | they got a 999c | |
| 19:07 | I don't want to duplicate the notice, so not sure what the plain import will do... | |
| 19:08 | cait | you could match |
| 19:08 | but not sure what you awant to do? | |
| 19:09 | and you don#t want to use sql to change bibliographic data. would be a bad idea | |
| 19:09 | blou | We're modifying some notices. Got the notices, add some fields (using perl script), then need to "put them back" |
| 19:10 | cait | you mean records? :) |
| 19:10 | blou | There's a web service I think |
| 19:10 | yes | |
| 19:10 | cait | you could reimport and match on 999c |
| 19:10 | it won't add duplicate fields, koha can only overlay or not overlay | |
| 19:10 | so itwould overlay the complete record | |
| 19:11 | the items would not be touched by that, if you didn't want to | |
| 19:11 | blou | ha? interesting. Very interesting. So it's like a normal import, but you just specifiy a match field |
| 19:12 | cait | i think there are 2 different ways, the bulkmarcimport can match, but we normally use staged marc import and the matching rules there |
| 19:12 | have never used the first | |
| 19:12 | blou | I'll explore that. Thanks a LOT! |
| 19:14 | Yaxh joined #koha | |
| 19:24 | wizzyrea | oleonard - about? |
| 19:25 | if/when you have a bit of time, I'm curious about less compiling | |
| 19:25 | also good morning | |
| 19:25 | magnuse | kia ora wizzyrea |
| 19:25 | oleonard | Hi |
| 19:25 | * oleonard | was just compiling some less as it happens |
| 19:28 | wizzyrea | so what's the general process, where do you start? I looked over the website but I seemed to get lost |
| 19:28 | it seems like a fantastic idea though | |
| 19:29 | oleonard | wizzyrea: Do you have Node.js installed? |
| 19:30 | wizzyrea | so it claims |
| 19:30 | so yea, my thinking was right, you have to have node, then install less | |
| 19:30 | oleonard | Yes, see "Server-side usage" just past this section: http://www.lesscss.org/#usage |
| 19:30 | wizzyrea | then it should theoretically be as straightforward as they claim. |
| 19:31 | if you can get all that malarkey working | |
| 19:31 | so the idea then | |
| 19:31 | is that when you've gotten it installed, you can just less compile them and output the css to the css directory? | |
| 19:31 | oleonard | Yes |
| 19:32 | wizzyrea | yay i was less lost than I thought ^.^ |
| 19:32 | GETIT ha ha ha. | |
| 19:32 | oleonard | when I was developing the Bootstrap theme I used this: https://github.com/jonycheung/[…]SS-Watch-Compiler |
| 19:32 | wizzyrea | oh. |
| 19:32 | ohhh | |
| 19:32 | oleonard | You run that and it watches for changes in the less directory and automatically compiles |
| 19:32 | wizzyrea | yes I like that idea. |
| 19:32 | oleonard | Unfortunately the latest version also minifies, which we don't currently do with the OPAC css |
| 19:32 | (although we should) | |
| 19:33 | wizzyrea | well it would prevent people from editing it by hand |
| 19:33 | instead of editing the less and compiling it | |
| 19:33 | oleonard | Having minified CSS would be a nice hint that it shouldn't be edited |
| 19:34 | wizzyrea | so, also |
| 19:34 | there are some css files that don't have less counterparts (specifically, print.css) | |
| 19:35 | cait | wizzyrea++ oleonard++ :) |
| 19:35 | wizzyrea | 1. should they have less counterparts? 2. it's still ok to edit them for now, because they don't? |
| 19:36 | oleonard | Perhaps for consistency's sake there should be no directly-edited CSS files in the Bootstrap theme? |
| 19:36 | wizzyrea | well that would be a good guideline I think |
| 19:36 | not good for a patch i have out but good overall ;) | |
| 19:36 | is there a retrocon? | |
| 19:36 | css -> less? | |
| 19:38 | oleonard | You could just slap a .less extension on any of the CSS and it would "compile" (i.e. stay the same because it doesn't have any special directives in it) |
| 19:39 | wizzyrea | hehe yep I just read that |
| 19:39 | is it your opinion that for bootstrap that should be done? | |
| 19:40 | oleonard | Yes |
| 19:41 | wizzyrea | k ty, will file a bug and do some of that. |
| 19:42 | magnuse | wizzyrea++ |
| 19:43 | wizzyrea | unless you'd rather.. |
| 19:43 | * oleonard | is wrapped up in non-Koha stuff at the moment |
| 19:43 | wizzyrea | righty o :) |
| 19:45 | move_ joined #koha | |
| 19:48 | magnuse | poor oleonard |
| 19:49 | have fun #koha! | |
| 19:49 | wizzyrea | later magnuse |
| 19:53 | nengard left #koha | |
| 19:58 | chris_n` joined #koha | |
| 20:51 | meliss joined #koha | |
| 21:10 | chris_n joined #koha | |
| 21:11 | rhcl | chris_n: long time no see |
| 21:13 | nengard joined #koha | |
| 21:34 | enngard left #koha | |
| 21:37 | NateC joined #koha | |
| 21:54 | barton | Hey, I've got a simple question about facets, but they're bending my brain a bit ... |
| 21:56 | I have a partner who is wondering why only five branches show up in the 'Libraries' facet -- they have six -- but there's no 'Show more' button. | |
| 21:59 | cait | hm |
| 21:59 | is the sixth branch appearing in the first x results? | |
| 22:00 | x is set in a pref | |
| 22:00 | it defaults to 20 | |
| 22:00 | search for facets in the prefs, there are a few | |
| 22:00 | wahanui joined #koha | |
| 22:04 | mtompset | Yes, the facets are built from the current page, if I recall. |
| 22:05 | cait | it's according to the sys pref setting |
| 22:05 | you can change it, but take a performance hit | |
| 22:05 | * cait | says barton to make the client ping |
| 22:06 | barton | I see the maxRecordsForFacets sys pref. |
| 22:06 | mtompset | Yes, but I was noting that if the sixth library is mentioned on page 2, it won't show up in the facets unless you are on page 2. |
| 22:06 | cait | yep |
| 22:06 | mtompset | (as far as I recall) |
| 22:06 | cait | hm not sure how it recalculates |
| 22:06 | i didn't try that | |
| 22:07 | wizzyrea | it will do libraries on page 2+ if you set the maxrecordsforfacets higher |
| 22:07 | i think it defaults to 20 | |
| 22:07 | oh cait said that. | |
| 22:07 | mtompset | wizzyread, but then page 2 isn't page 2 anymore. |
| 22:07 | wizzyrea | ok let me rephrase. |
| 22:07 | mtompset | if it is on page 3, and you double the size, page 3 becomes page 2. |
| 22:07 | wizzyrea | no, it's not changing the max results. |
| 22:07 | cait | hm not sure the facets actually change |
| 22:07 | wizzyrea | per page. |
| 22:07 | cait | they don't change on my test installation |
| 22:08 | when i page | |
| 22:08 | wizzyrea | (it definitely used to work.) |
| 22:08 | there are two sysprefs | |
| 22:08 | one for results per page, usually 20 | |
| 22:08 | * cait | nods |
| 22:08 | wizzyrea | one for maxrecordsforfacets, also 20 |
| 22:08 | * mtompset | shrugs. I could be wrong, but I thought the facets were built by Koha, and therefore, only the last block retrieved is used to build the facets. |
| 22:09 | wizzyrea | you can increase maxrecordsforfacets and not increase the results per page |
| 22:09 | mtompset | AH... okay, I was not aware of that, wizzyrea. :) |
| 22:09 | * cait | nods again |
| 22:10 | * mtompset | has begun testing 11596 for tcohen. :) |
| 22:10 | mtompset | I need some successes in my life right now. :) |
| 22:10 | wizzyrea | yea, so, when I say page 2+, I mean "when the results per page is set to 20, and maxrecordsforfacets is set to something higher, like 40, you will get facets from the 2nd page |
| 22:10 | increase it more, and you will get pages 2+ | |
| 22:10 | it's a performance hit, however. | |
| 22:11 | barton ^ | |
| 22:11 | barton | I'm not actually looking for search results though... I'm interested in what shows in the side bar ... |
| 22:12 | wizzyrea | yes, that's what I'm talking about |
| 22:12 | cait | the facets are built from the result list |
| 22:12 | wizzyrea | the facets come from the result list |
| 22:12 | cait | they are based on it |
| 22:12 | wizzyrea | for example |
| 22:12 | wahanui | hmmm... for example is remapping in koha a wise path ? |
| 22:12 | wizzyrea | NEKLS has 48 libraries |
| 22:12 | * barton | starts to get it... |
| 22:12 | wizzyrea | lets say their maxrecordsfor facets is set to 20 |
| 22:12 | cait | forget for example |
| 22:12 | wahanui | cait: I forgot for example |
| 22:12 | wizzyrea | and lets say that in the first 20, only 15 libraries are represented |
| 22:12 | eythian | hi |
| 22:13 | barton | wizzyrea -- riiiight |
| 22:13 | cait | hi eythian |
| 22:13 | wizzyrea | if you double the syspref, you get double the results to calculate from |
| 22:13 | which may increase the number of libraries represented in the results | |
| 22:13 | cait | barton: the only hardcoded facet is availability - that shows up always i think, the others are depending on your result list |
| 22:13 | wizzyrea | in the facets |
| 22:14 | barton | so if there are only 3 libraries shown with the first page of search results, that's what you'll see on the side bar,. |
| 22:14 | wizzyrea | yes, exactly :) |
| 22:14 | cait | our facets are... |
| 22:14 | could be better. | |
| 22:14 | we should let zebra build them. | |
| 22:14 | barton | *chuckle* |
| 22:14 | wizzyrea | or solr. or elasticsearch. |
| 22:14 | barton | nod. |
| 22:15 | cait | not sure how much work solr would need - getting zebra doing it right might be less work |
| 22:15 | but yeah, hoping for elastic search, just not sure when it will be ready :) | |
| 22:16 | barton | ok, I think that answers my question. you can keep on talking about facets if you really *want* to, but I'm good :-) |
| 22:16 | rhcl | :) |
| 22:17 | dcook joined #koha | |
| 22:17 | wizzyrea | \o/ |
| 22:19 | mtompset | i'm waiting for bug 10891 to take off. ;) |
| 22:20 | huginn | 04Bug http://bugs.koha-community.org[…]_bug.cgi?id=10891 enhancement, P3, ---, gmcharlt, NEW , Make facets customisable |
| 22:29 | dcook | I think M. Saby isn't working with Koha anymore? |
| 22:30 | * dcook | thinks someone with more time/money than himself should write a patch to use Zebra's facets :p |
| 22:41 | gmcharlt | dcook lines them up, I knock 'em down ;) |
| 22:42 | dcook | Who wha? |
| 22:42 | * dcook | looks up |
| 22:42 | dcook | Email? |
| 22:42 | wahanui | Email is sent to either the KohaAdminEmailAddress or the branch address - cait is not totally sure |
| 22:43 | gmcharlt | dcook: yeah |
| 22:43 | dcook | \o/ |
| 22:43 | cait | hm? |
| 22:43 | * cait | waves |
| 22:44 | dcook | hey ya cait |
| 22:44 | Thanks for that gmcharlt :) | |
| 22:44 | In retrospect, I suppose I should've asked if that'll be the default for new installs, but I assume so? | |
| 22:44 | Since it's included in Koha's debian repo | |
| 22:45 | gmcharlt | dcook: correct, anybody installing from packages from scratch will get the latest |
| 22:45 | dcook | \o/ |
| 22:45 | I suppose my Debian machines check for updates automatically. I think that's what I had in mind. | |
| 22:45 | I probably have installed the update and not even realized. | |
| 22:46 | One way to check.. | |
| 22:47 | Hmm, perhaps not.. | |
| 22:56 | eythian | they tend to check regularly, but they don't apply updates automatically unless you tell them to. |
| 22:56 | dcook | Yeah, that's usually the case at home |
| 22:56 | eythian | I have a thing installed that emails me of updates needed each morning, in order to stay on top of them. |
| 22:56 | dcook | Not this one at work though. I had to do it manually :/ |
| 22:56 | Mmm, I think I was reading about that. Is that one of those apt* packages? | |
| 22:57 | mtompset | Receiving objects: 100% (258349/258349), 1004.27 MiB | 431 KiB/s, done. |
| 22:57 | Wow! Fresh full git clone is huge! | |
| 22:57 | dcook | eythian: apticron? |
| 22:58 | eythian | dcook: I can't remember what it's called off the top of my head |
| 22:58 | dcook | No worries. Perhaps I'll look into this one at some point. |
| 22:58 | eythian | ah yeah, it is. |
| 22:58 | gmcharlt | apt-listchanges |
| 22:59 | eythian | no, that's different |
| 22:59 | gmcharlt | ah, so it is |
| 22:59 | hmm | |
| 22:59 | eythian | oh, it might have the same effect actually |
| 22:59 | but it was apticron I was thinking of. | |
| 23:00 | dcook | On a related note, I was wondering if I could ask you a question about verifying a GPG trust path, eythian |
| 23:00 | eythian | sure |
| 23:01 | dcook | As far as I can tell so far (having only used GPG for 2 days), a person would either have to have a web in their own keyring connecting themselves to the owner of the key being assessed, or use an online tool to check between the two, yes? |
| 23:01 | Actually, at the moment, I only (vaguely) understand the idea of a keyserver using a tool to do the verification | |
| 23:02 | If doing it from the commandline, one would need to do it semi-manually? | |
| 23:02 | I suppose if there are 5 or fewer steps between themselves and the key being verified? | |
| 23:02 | eythian | yeah |
| 23:02 | so, you do need to have the keys that form the path | |
| 23:03 | http://pgp.cs.uu.nl/paths/F871[…]/to/48BFF157.html <-- things like this will tell you though | |
| 23:04 | dcook | I think that's even the one I looked at last night |
| 23:04 | Are those the only two methods one could use? | |
| 23:04 | I suppose other than knowing the person and just trusting it | |
| 23:05 | But then I guess you wouldn't need to verify a path... | |
| 23:05 | Because you would already have them as a trusted key.. | |
| 23:05 | eythian | well, there's no way for it to know if there's a path without having all the steps in the path |
| 23:06 | dcook | Makes sense. Otherwise, it wouldn't be a web. |
| 23:06 | eythian | yeah. |
| 23:07 | dcook | I suppose the online tool has the advantage of having more keys than one would locally |
| 23:07 | eythian | Over time, your keyring will end up with many many keys in it. |
| 23:07 | yep | |
| 23:07 | dcook | I hope so :) |
| 23:07 | I still need to figure out the best way of managing keys over multiple devices...then I should be ready to start actually using GPG | |
| 23:07 | eythian | especially if you tell your mail client to fetch any that it doesn't know when it sees them. |
| 23:07 | wizzyrea | ^ has been most practical |
| 23:08 | dcook | Interesting...I suppose the more keys you have, the better |
| 23:08 | eythian | also run gpg --refresh every so often to make sure they're up to date |
| 23:08 | dcook | And it doesn't necessarily hurt you if you have your trust specified correctly? |
| 23:08 | eythian | yeah |
| 23:08 | how do you mean? | |
| 23:08 | papa joined #koha | |
| 23:09 | dcook | Well, I haven't thought it through completely, but what if you add a key from a stranger, and you trust it fully and it turns out that this person is somehow malevolent and that you shouldn't be trusting the keys they sign? |
| 23:09 | You might have a trust path to a key that you shouldn't trust? | |
| 23:09 | eythian | yeah, don't trust keys from strangers :) |
| 23:09 | though, the trust path thing is more complex than that. | |
| 23:09 | dcook | But it's ok to have keys from strangers so long as you don't trust them, never trust them, unknown trust them? |
| 23:10 | wizzyrea | I don't even trust keys from people I haven't actually met in person. :P |
| 23:10 | eythian | yep |
| 23:10 | dcook | I added yours, eythian (due to the Koha packages), but I have yet to make up my mind on that one, lol |
| 23:10 | I've met Chris but that's still a degree of separation...:p | |
| 23:10 | eythian | by signing a key, you're saying to everyone "I've checked that this person is who they say they are" |
| 23:11 | by trusting a key, you're saying to yourself "I think this person is likely to do a good job signing keys" | |
| 23:11 | dcook | Right, that's the other thing. It's about trusting the person's ability and not just knowing them. |
| 23:11 | eythian | the keys in the packages are not my key (these days, they used to be.) |
| 23:11 | dcook | For instance, I wouldn't trust me too much, since I'm just starting |
| 23:11 | It definitely had your subkey? | |
| 23:11 | Or maybe it was just that you signed it? | |
| 23:11 | eythian | well, if you just sign, then it doesn't really matter. It'll just require, say, two people vouching for them. |
| 23:12 | But if you trust one person more, then it might just require them. | |
| 23:12 | dcook | When I imported the gpg.asc from the debian site, it had two keys and one was "A99CEB6D" |
| 23:12 | eythian | dcook: I have signed it. |
| 23:12 | My primary key ID these days is F8713BDF | |
| 23:12 | dcook | Ah, hence it being more complex than just trust |
| 23:13 | And A99CEB6D is your subkey signed by your primary? | |
| 23:13 | "a subkey" rather than "your subkey", I guess | |
| 23:13 | eythian | no, that's an old key that I used to use for the packages. |
| 23:13 | Some day soon I'm going to revoke it. | |
| 23:14 | Most people do signing but don't bother with trust too much, and just let it work itself out. | |
| 23:15 | dcook | Hmm |
| 23:15 | eythian | if you run "gpg --update-trustdb", it'll ask you how much you trust the people to be good signers. |
| 23:15 | dcook | So then the path relies more on who has signed whose key up to the key you're checking |
| 23:16 | eythian | yeah |
| 23:16 | the more, the better. | |
| 23:16 | these are all tunable, but no one really bothers. | |
| 23:17 | dcook | So basically I would sign the keys of people I know, and then rely on their signatures |
| 23:19 | eythian | Yep. You can also advertise your trust rating if you want, but you don't have to. You can also locally sign a key if you want to treat them as verified for you, but don't want to say that to other people. |
| 23:19 | Basically it just stops it getting exported beyond your computer. | |
| 23:19 | These are all pretty rarely used though. | |
| 23:20 | dcook | Makes sense. I suppose it's all a bit of added work. |
| 23:20 | Cool. That makes a lot of sense :) | |
| 23:20 | Thanks for that :) | |
| 23:21 | Any tips on managing keys/identities over multiple devices? wizzyrea, feel free to add anything :) | |
| 23:21 | I've thought about trying the method mentioned on https://wiki.debian.org/subkeys but...figure I'd ask some folks I know first | |
| 23:22 | Happy to discuss over PM too if that's preferable | |
| 23:26 | eythian | dcook: I don't really bother. so long as all locations have the right public and private keys, it works itself out in general. |
| 23:26 | dcook | eythian: So you would just export all of your keys and import them onto each different device you use? |
| 23:28 | eythian | yeah. Or copy all of .gnupg over. |
| 23:30 | dcook: beware that the koha@ list silently drops signed emails. | |
| 23:30 | I need to chase up getting that fixed. | |
| 23:30 | dcook | Ah, that's good to know! |
| 23:31 | Hmm, so if a person were copying .gnupg, you would only have to do that each time you generated/revoked your own keys? | |
| 23:31 | eythian | no, just when setting up something the first time. |
| 23:32 | I suppose you could copy the files and the import them, that'd probably work though I've never done it. | |
| 23:33 | dcook | I mean just to keep them in sync in case you add a new key on your home system, send the pubkey to a keyserver, then need the private key on your laptop |
| 23:33 | magnuse joined #koha | |
| 23:36 | wizzyrea | whenever I see that guy's name on an email, it makes me tired and I want to take a nap. |
| 23:36 | eythian | to move the private key, you export it and then import it. |
| 23:36 | This isn't something that happens very often. | |
| 23:36 | public keys I do via the keyserver. | |
| 23:37 | dcook | Mmm, makes sense |
| 23:37 | Send to the keyserver and then retrieve your own public key? | |
| 23:37 | eythian | yeah |
| 23:37 | dcook | So when someone signs your public key, do they send it back to the keyserver, and then you download it again? |
| 23:38 | eythian | generally yeah, though not always. |
| 23:39 | dcook | Ah, I see. "When Blake signs Alice's key he sends the signed key to the key server. The key server adds Blake's signature to its copy of Alice's key." |
| 23:47 | tcohen joined #koha | |
| 23:47 | mtompset | So what if some jerk up the chain gets all their keys revoked... what happens to everyone down the chain? |
| 23:48 | tcohen: Just tested 11596 | |
| 23:48 | Looks good. :) | |
| 23:48 | tcohen | that's great mtompset |
| 23:48 | mtompset | I cloned a fresh 1GB repo for you. ;) |
| 23:50 | BobB joined #koha | |
| 23:52 | dcook | mtompset: --fresh-keys should update your keys and then when you check a key, it'll say whether or not the key is revoked, I believe |
| 23:52 | mtompset | But could a revoke trigger a mass revoke? |
| 23:53 | dcook | You would revoke your key, send it to a keyserver, and then people would download it from there |
| 23:53 | Otherwise, you're emailing everyone you know, I believe | |
| 23:54 | maximep left #koha | |
| 23:55 | tcohen | dcook: how can I get my key signed by you? |
| 23:56 | (or anyone else) | |
| 23:56 | dcook | tcohen: As far as I can tell, you would either need to upload to a keyserver (then I would download by searching your name, email, or a fingerprint that you would give me), or you would email it to me and I would email it back or upload it to the keyserver |
| 23:57 | I think anyone can upload to the keyserver, so you would only want to sign a key if you can confirm the fingerprint with the actual person | |
| 23:57 | Whether that is by email, phone, in-person, etc | |
| 23:57 | With each having its pros and cons, of course | |
| 23:57 | tcohen | got it |
| 23:57 | dcook | Should have keysigning parties at the Kohacon hackfest ;) |
| 23:57 | tcohen | I generated my key when started the rmaint task, but never asked anyone to sign it |
| 23:58 | dcook | I suppose signatures aren't required but they help build the web of trust |
| 23:59 | tcohen | exactly |
← Previous day | Today | Next day → | Search | Index