← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 02:12 | C4R7 joined #koha | |
| 02:13 | C4R7 | Hello |
| 03:11 | C4R7 joined #koha | |
| 06:35 | cait joined #koha | |
| 07:14 | cait joined #koha | |
| 07:17 | cait joined #koha | |
| 07:28 | magnuse | ashimema: "ancient perls" - are those the perls shipped with debian and ubuntu? |
| 07:34 | ashimema | Yup, we lock ourselves to the lowest common denominator.. i.e lts debian |
| 07:35 | 5.14 perl | |
| 07:36 | magnuse | that is pretty low... |
| 07:36 | ashimema | 5.24 would give us a fair bit from memory.. and the thinks that people are getting excited about in the perl world are brand new.. objects, signatures, etc |
| 07:36 | magnuse | there are versions of debian/ubuntu we say we support that has perl as old as that? |
| 07:37 | ashimema | 5.38 is current perl |
| 07:37 | Yup | |
| 07:37 | magnuse | how hard would it be to install a newer perl? |
| 07:39 | ashimema | Looks like 5.28 is in buster.. the older non-lts debian |
| 07:39 | Whilst we stick to system perl, fairly hard | |
| 07:40 | If we opted to try and go local lib it would mean some infrastructure change but then not so hard | |
| 07:40 | I don't know the answer to be honest | |
| 07:40 | Right, swim time for me.. be back in an hour | |
| 08:04 | lds joined #koha | |
| 08:13 | cait joined #koha | |
| 08:44 | fridolin joined #koha | |
| 08:45 | fridolin | salutations |
| 08:48 | t/db_dependent/api/v1/erm_counter_registries.t failing on master 23.11 | |
| 08:48 | and t/db_dependent/api/v1/erm_sushi_services.t | |
| 08:49 | maybe a change in the WS itself | |
| 08:49 | any idea ? | |
| 09:00 | Joubu | PedroAmorim[m]: ? |
| 09:01 | t/db_dependent/api/v1/erm_sushi_services.t is failing because it compares an expected output with https://registry.projectcounte[…]a5f-6c113f7ffa0b/ | |
| 09:01 | and there is "migrations" there | |
| 09:01 | which may have been added recently | |
| 09:01 | this test is really bad (ie. depending on an external resource) | |
| 09:02 | unless it's what we want, but it's not clear what the test is actually testing | |
| 09:06 | * cait | waves |
| 09:07 | cait | can anyone help with a password reset on the wiki? It looks like emails are not being sent out |
| 09:07 | Joubu | fridolin: added a comment on bug 35218 |
| 09:07 | huginn` | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=35218 blocker, P5 - low, ---, martin.renvoize, RESOLVED FIXED, No tests for /erm/sushi_service |
| 09:08 | fridolin | Joubu: tanks a lot |
| 09:18 | PedroAmorim[m] | I was not aware of this |
| 09:18 | can take a look | |
| 10:20 | dolf joined #koha | |
| 10:24 | dolf | Hi there. I'm trying to upgrade an old Koha (21.05) step by step, starting with 21.05 -> 21.11. It's on debian, using apt. I updates the codename to 21.11 in /etc/apt/sources.list.d/koha/list and ran `apt update` followed by `apt upgrade`. The database schema upgrades started at 21.06.00.000 and went swimmingly until 21.06.00.041, when I got this error: ERROR - {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Row size too large. The maximum row size for the |
| 10:24 | used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs at /usr/share/koha/lib/C4/Installer.pm line 743 . I'm not sure what to do with this... | |
| 10:24 | cait | you don't need to do a step by step update |
| 10:25 | but the error you ahve needs to be resolved, give me a moment | |
| 10:25 | Bug 28267 - Older databases fail to upgrade due to having a row format other than "DYNAMIC" | |
| 10:25 | dolf | I realize that, but I tried to upgrade directly to the latest version before, and got the same error, so I reverted the state of the VM and tried again with a smaller increment. Also, our staff members like to test things thoroughly in between upgrades. Anyway, thanks for your time and attention! |
| 10:26 | cait | yes, but testing every versin in between might be a bit of wasted energy |
| 10:26 | dolf | Ah, it's the row format again. I think I ran into this on another instance a while ago! |
| 10:26 | cait | have a look at the bug I posted, the link is https://bugs.koha-community.or[…]_bug.cgi?id=28267 |
| 10:26 | huginn` | 04Bug 28267: critical, P1 - high, ---, jonathan.druart+koha, RESOLVED FIXED, Older databases fail to upgrade due to having a row format other than "DYNAMIC" |
| 10:28 | cait | comments 20/21 especially |
| 10:30 | dolf | Thanks. I also found https://irc.koha-community.org[…]a;date=2023-08-16 where I discussed the same problem. I'll just pick up from there! Thanks again. |
| 10:48 | paulderscheid[m] | morning #koha |
| 10:50 | I think we should make some efforts to get to 5.036 at least as one of perl's flagships (even if not this cycle). And I want these type checks as soon as they're in core :D | |
| 10:53 | dolf | Has the wiki account creation / email sending been sorted out yet? Back in August, davidnind tried to help me get my wiki account activated, but none of the e-mails are reaching me, so I can't (re)set my password. I would like to improve this page: https://wiki.koha-community.or[…]tabase_row_format |
| 10:54 | cait | dolf: we just found it not workign today/yesterday for another user |
| 10:55 | maybe you could comment here too: Bug 34637 - Wiki - email notifications aren't being sent (account registrations, password resets, etc.) - I left a comment earlier, but strangely I am receiving page update notifications to my email | |
| 11:01 | Joubu | paulderscheid[m]: we can already improve some of our old code. Waiting for a future version of Perl is just an excuse to procrastinate :D |
| 11:02 | paulderscheid[m] | You are right |
| 11:02 | ˆˆ | |
| 11:03 | Joubu | there are several places where prototype of subs is bad and can be improved/cleaned already |
| 11:11 | oleonard | Hi #koha |
| 11:50 | cait | hi oleonard |
| 12:18 | dolf | cait: I commented on both issues. On Bug 28267 (the one about the DYNAMIC rows) I posted a link to the script that I used to convert everything to DYNAMIC row format. After that, the database upgrades worked, and this Koha instance is now on 21.11 at last. However, now I'm seeing another issue that I also had in August, and never got resolved (I ended up rolling back the VM). The discussion started here https://irc.koha-community.org[…]3-08-17#i_2503120 |
| 12:18 | . In summary, the search results and normal view on the biblio page are both omitting lots of data, even though the MARC data is all there and in good condition. | |
| 12:18 | huginn` | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=28267 critical, P1 - high, ---, jonathan.druart+koha, RESOLVED FIXED, Older databases fail to upgrade due to having a row format other than "DYNAMIC" |
| 12:21 | dolf | Unfortunately I did not check in between the row format conversion and the "apt upgrade" step, so I don't know which one is the problem. |
| 12:25 | It's looking fine on the intranet, but on the OPAC in "Normal view" on the opac-detail.pl page, no record details are shown | |
| 12:26 | On the OPAC search page, only the covers are shown: https://library.refstudycentre[…]sort_by=relevance | |
| 12:34 | lds joined #koha | |
| 12:37 | dolf | brb |
| 12:39 | cait | @later tell dolf sorry, I was afk. That sounds like you should check your frameworks - especially the visilbility settings. It didn't work in the past and then we fixed it. So field need to be set to be visible in the OPAC |
| 12:39 | huginn` | cait: The operation succeeded. |
| 12:40 | cait | and you will always want to have "default" in the XSLT prefs (non-XSLT views have been removed in newer versions anyway) |
| 12:48 | @later tell dolf: also check the logs for errors, XSLT errors can make themselves visible like this. In the frameworks you want to check for biblionumber 999 to be set to visible in the OPAC for a start. | |
| 12:48 | huginn` | cait: The operation succeeded. |
| 12:58 | lds joined #koha | |
| 13:52 | dolf joined #koha | |
| 13:53 | Dyrcona joined #koha | |
| 13:58 | dolf | cait: Thanks, I'll look into that. Although I don't recall ever changing the frameworks or XLST stuff since installing Koha for the first time back in 2011. |
| 13:59 | By the way, I reverted my VM to after converting the rows to DYNAMIC, and before upgrading to 21.11 (so it's still on 21.05) and now everything is working. So it's not the row format that is causing trouble. It must be one of the updates not playing nicely with my settings? | |
| 14:03 | cait | dolf: there can be different reasons |
| 14:03 | is it only in the opac or the staff interface as well? | |
| 14:04 | meaning: does the result list and detail page in staff interface display normally? | |
| 14:05 | dolf | Staff displays normally, yes. The problem is only on the OPAC (both in search results and on the detail page) |
| 14:06 | cait | ok, did you check the logs yet? |
| 14:06 | or first: go to your frameworks | |
| 14:07 | check that all your frameworks have 999$c set to visible in the OPAC | |
| 14:07 | dolf | Will do!, as soon as I get the problem replicated on another VM. I need to keep it in a stable position for the following week until my next maintenance window. So I'm keeping it on 21.05 for now so that the staff can do their work. |
| 14:08 | cait | ah ok, a separate system for testing might be useful :) |
| 14:09 | tail -f /var/log/koha/instance/*.log when you go to result list and look for anything error'y | |
| 14:23 | dolf | cait: Under /cgi-bin/koha/admin/marc_subfields_structure.pl?op=add_form&tagfield=999&frameworkcode=#subcfield the OPAC check box is ticked next to "Visibility" under "Advanced constraints". Is this the right place? I noticed that it's not possible to modify that check box. |
| 14:23 | cait | that's odd |
| 14:23 | dolf | (Still on 21.05, just poking around) |
| 14:23 | cait | but yes, visibility |
| 14:23 | is it checked? | |
| 14:24 | dolf | Yes, Checked are OPAC, Intranet and Collapsed. Unchecked are Editor and Flagged. |
| 14:28 | On the "Tag 999 Subfield structure" page, it says "subfield ignored" in the "Constraints" column of subfield "c". What does that mean? | |
| 14:35 | marie-luce joined #koha | |
| 14:52 | cait | i think that's ok |
| 14:53 | I think checking for an error would be the next step when you try to update again, in the logs, when you do a search | |
| 14:56 | dolf | Will do. In the mean time. I see that "OPACXSLTDetailsDisplay" and "OPACXSLTListsDisplay" and "OPACXSLTResultsDisplay" are empty instead of "default". Maybe that is the problem? |
| 14:56 | What did you mean when you said "non-XSLT views have been removed in newer versions anyway" ? | |
| 14:58 | oleonard-away | dolf: There used to be two ways to show those pages, XSLT or non-XSLT. |
| 14:59 | caroline joined #koha | |
| 15:05 | dolf | Without upgrading (i.e. still on 21.05) I changed all OPACXSLT*Display settings from empty to "default", and now I see the same problem as when I upgraded: Only the book cover picture is shown. The rest is missing, both on the book detail page and on the search results page. |
| 15:06 | Changing back to empty fixed the problem. I don't understand this setting. Maybe the default xslt is missing or corrupted? Is it part of the deb package installed via APT? | |
| 15:07 | oleonard | dolf: I'm sorry if you've answered this already, but have you customized the default XSLT somehow? |
| 15:07 | dolf | I have not. I would not know how. How can I check if it's still at "factory settings"? |
| 15:08 | cait | the package update would also overwrite any local changes I think |
| 15:08 | we really need the error from the logs | |
| 15:08 | if you see the problem now too, maybe check the logs now? | |
| 15:08 | I thin it's something in the configuration | |
| 15:09 | dolf | Good thinking, I should have thought of that. Doing that ASAP |
| 15:12 | There are some errors, but nothing new appears in the log when visiting opac-detail.pl , even though I see the issue (no details being displayed other than the book cover and the holdings table) | |
| 15:13 | cait | hm an XSLT bug should be logged soemwhere |
| 15:13 | are you checking all logs or only a specific one? | |
| 15:14 | dolf | I'm using tail -f /var/log/koha/instance/*.log as you suggested |
| 15:14 | with instance being "rsc" | |
| 15:15 | cait | ok |
| 15:15 | hm | |
| 15:15 | dolf | I can paste some of the errors I see, but their timing don't coincide with my page reload |
| 15:15 | cait | and when you go to results, there is nothing new? |
| 15:15 | dolf | I don't understand what you mean |
| 15:15 | cait | tail -f let's you watch the logs when you do the thing |
| 15:15 | so you can add empty lines and then reproduce the error, see if something turns up | |
| 15:16 | dolf | Yes, that's what I did. Nothing new pops up when I reload opac-detail.pl |
| 15:16 | cait | and same for opac-results? |
| 15:16 | dolf | Yes, same. |
| 15:16 | cait | i mean the result list |
| 15:16 | dolf | Got it |
| 15:17 | cait | yep hm |
| 15:17 | there was a short ime when we didn't log XSLT errors right, but that would be a very unlucky coincidence | |
| 15:17 | dolf | I see some other errors popping up, but they seem unrelated. This is a production site, and people are searching, browsing, etc. |
| 15:17 | cait | but you set XSLT to default now? |
| 15:17 | can you share a link? | |
| 15:18 | I just want to check something real quick | |
| 15:18 | dolf | Yes, three OPACXSLT*Display settings all set to "default", which makes my stuff hidden. |
| 15:18 | cait | in the browser |
| 15:18 | dolf | https://library.refstudycentre[…]s&weight_search=1 |
| 15:18 | https://library.refstudycentre[…]iblionumber=38779 | |
| 15:19 | cait | the bit where the output of the XSLt woudl be is completely missing from the page source |
| 15:20 | dolf | Strange... Where do these default XSLT files live? Can I check them manually? |
| 15:20 | cait | trying to remember the path for a package installation |
| 15:20 | they live in .... opac/bootstrap/xslt i think | |
| 15:21 | the opac template directory | |
| 15:22 | dolf | I have /usr/share/koha/opac/htdocs/opac-tmpl/bootstrap/en/xslt . Is that right? |
| 15:22 | Other one is /usr/share/koha/lib/Koha/XSLT | |
| 15:22 | cait | yes, that looks right |
| 15:22 | no the bootstrap one | |
| 15:22 | the ohter is the perl module, that shoudl be alright | |
| 15:23 | dolf | I see 12 .xsl files here |
| 15:24 | compact.xsl MARC21slim2OPACDetail.xsl MARC21slimUtils.xsl NORMARCslim2OPACResults.xsl plainMARC.xsl UNIMARCslim2OPACResults.xsl MARC21Languages.xsl MARC21slim2OPACResults.xsl NORMARCslim2OPACDetail.xsl NORMARCslimUtils.xsl UNIMARCslim2OPACDetail.xsl UNIMARCslimUtils.xsl | |
| 15:25 | oleonard | dolf: MARC21slim2OPACDetail.xsl & MARC21slim2OPACResults.xsl are for the OPAC details page and the OPAC search results page |
| 15:26 | dolf: What's your full Koha version number? | |
| 15:26 | dolf | `apt show koha-common` gives me `21.11.26-1` |
| 15:27 | oh wait, I thought I was still on 21.05. | |
| 15:28 | Ah, `apt show` does not give the installed version, but the latest available one in the apt repos | |
| 15:28 | oleonard | dolf: The Koha "About" page will show you |
| 15:28 | dolf | It |
| 15:29 | It's 21.05.00.000 | |
| 15:29 | oleonard | https://gitlab.com/koha-commun[…]lt?ref_type=heads |
| 15:36 | dolf | I downloaded from git and did a diff. The MARC21slim2OPACResults.xsl files are identical. The MARC21slim2OPACDetail.xsl files have a diff: https://pastebin.com/qh6Atnbx |
| 15:37 | It looks like mine is just slightly older. Should I update to the latest 21.05.* ? | |
| 15:39 | oleonard | dolf: It couldn't hurt to try |
| 15:41 | cait | I still think itmight be something int he data cuasing an error |
| 15:41 | but we need the error to be able to tell more | |
| 15:41 | maybe if you try to update again, repeat checking the logs | |
| 15:51 | dolf | Something in the data: You mean in my MARC records? We have tens of thousands, and I did a spot check – all have the same problem. |
| 15:51 | I updated to 21.05.21.000 now. Checking again ... | |
| 15:54 | Still no new lines in any log files when loading opac-detail or opac-search. When I change the OPACXSLT*Display settings back to empty, I can see the book details again. | |
| 15:55 | cait | can you still paste what you have in the logs? |
| 15:55 | dolf | Yes, I'll do that. But I have to go soon. Thanks for all the help!!! |
| 15:56 | cait | have to go soon too, but maybe someone will also read later |
| 15:57 | dolf | opac-error.log https://pastebin.com/LD3JHkmg |
| 15:57 | Any other files? There are many, but I assumed opac-error.log is the only relevant one. | |
| 15:57 | Bye now :) | |
| 15:57 | cait | i was thinking of anything that appears when you load the opac-rsult or opac-detail page |
| 15:58 | but ther eis nothing obvious there | |
| 15:58 | dolf | Nothing appeared when doing tail -f *.log during a reload. |
| 15:58 | cait | hm |
| 15:59 | sorry, I am out of ideas :( | |
| 15:59 | have a nice evening/rest of day #koha | |
| 16:00 | bag joined #koha | |
| 16:36 | paulderscheid[m] | Is metacpan.org broken for anyone else (Search specifically)? |
| 16:55 | ashimema | All works for me |
| 17:00 | cait joined #koha | |
| 17:04 | paulderscheid[m] | thanks ashimema |
| 17:04 | now it works for me too | |
| 17:05 | Have you played w/ Mojo::JWT already ashimema? | |
| 17:07 | ashimema | Yeah, a few times over the years |
| 17:11 | paulderscheid[m] | Would you recommend it for JWTs for Koha via OpenAPI or rather one of the other packages? |
| 17:11 | I think there's also JSON::WebToken | |
| 17:11 | And many more | |
| 17:51 | tuxayo | paulderscheid: https://github.com/orgs/Perl-A[…]lo/discussions/49 => is that about optional typing? |
| 17:51 | hi all :) | |
| 17:56 | alexted[m] joined #koha | |
| 17:59 | alexted[m] | hello, I have jsut installed Koha on Debian (following the official Wiki: https://wiki.koha-community.or[…]i/Koha_on_Debian). My question is: which is the default password assigned to the system user "library-koha" created by the "koha-create"? Thanks! |
| 18:11 | tuxayo | alexted: hi :) |
| 18:11 | https://wiki.koha-community.or[…]the_web_interface | |
| 18:11 | > When you see the login for the Koha installer, the username and password are in the koha-conf.xml file for the instance. | |
| 18:12 | > You can view the password with: | |
| 18:12 | > sudo koha-passwd libraryname | |
| 18:12 | I think it's that | |
| 18:17 | alexted[m] | tuxayo: hi! thanks for you reply :) |
| 18:19 | the password you are referring to is that of the MySQL user (koha_library), I was referring to that of the Debian system user (koha-library) | |
| 18:39 | lukeg joined #koha | |
| 18:40 | lukeg | hi |
| 18:41 | cait | alexted[m]: what are you trying to do? |
| 18:41 | you can use sudo koha-shell instance to switch to this user | |
| 19:06 | alexted[m] | cait: hi cait, thanks for your answer |
| 19:07 | i'm tring to rebuild Zebra with "sudo koha-rebuild-zebra -f -v instancename" and i don't know how to find the password for the koha system user | |
| 19:57 | cait | you don't need it |
| 19:58 | that's your normal root user, not the koha one | |
| 19:58 | all the sudo koha-... commands are just run with your own password | |
| 19:59 | and if you need to run other scripts you switch to the koha user using the command I gave earlier | |
| 20:20 | paulderscheid[m] | Hi tuxayo => yes |
| 20:20 | Also: global big squashing days came up during the last dev meeting, just fyi if you want to organise | |
| 20:30 | alexted[m] | caitok, so so the "koha-rebuild"-zebracommand must be run as root user? thanks! |
| 20:32 | cait | it will take care of using the right user internally I believe |
| 20:32 | you have the instance as parameter | |
| 20:41 | alexted[m] | ok, but the Koha Installation Guide on Debian https://wiki.koha-community.or[…]ki/Koha_on_Debian says that "A system user is created, called library-koha. All things to do with this instance will be run as this user." |
| 20:41 | This is why I was wondering if the "koha-rebuild-zebra" command should be run as the library-koha user |
← Previous day | Today | Next day → | Search | Index