← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
02:36 | dpk joined #koha | |
02:37 | dpk_ joined #koha | |
03:55 | lukeg joined #koha | |
05:38 | eythian joined #koha | |
06:54 | cait joined #koha | |
07:03 | fridolin joined #koha | |
07:03 | fridolin | yellow |
07:06 | marcelr joined #koha | |
07:06 | marcelr | o/ |
07:17 | tcohen joined #koha | |
07:21 | davidnind | FYI - On the dashboard, the 'New features' list is not updating with the latest patches pushed to master |
07:27 | magnuse | \o/ |
07:28 | ashimema | hmm |
07:29 | that’s strange | |
07:30 | morning | |
07:31 | davidnind | good morning Europe! |
07:32 | magnuse | good evening New Zealand! |
07:33 | ashimema | hola |
07:35 | Ah, I wonder.. | |
07:35 | Do you have a bug in particular you think should be showing up in New features davidnind? | |
07:36 | I’m wondering if it’s something to do with ‘Needs documenting’ vs ‘Pushed to master’ | |
07:37 | Joubu | yes I think we search for "pushed to master" |
07:37 | davidnind | For me. it is showing '34955 - One Koha manual' as the top one and '35063 - Convert SelfCheckInMainUserBlock system preference to HTML customization as the last one' = these are all for 23.11 (also used a browser with a cleared cached) |
07:40 | ashimema | Yup.. I see the issue |
07:40 | it's only looking for ‘Pushed to master’ | |
07:40 | We should be looking for both ‘Pushed to master’ OR ‘Needs documenting’ | |
07:40 | I’ll get that fixed this morning once I’m at the right computer. | |
07:41 | Joubu | needs documenting won't show the last pushes |
07:41 | ashimema | Depends how Katrin is marking them |
07:41 | Joubu | well, enh is not supposed to be backported |
07:41 | ok ignore me, it should work | |
07:42 | ashimema | That box shows ‘Enhancements’ ‘Pushed to master’ |
07:42 | indeed | |
07:42 | marcelr | ashimema: care for a final look at 35341 ? |
07:42 | ashimema | What I need is an example of something pushed to 24.05 that’s an enhancement that you think should be appearing and isn’t davidnind |
07:42 | marcelr | the flatpickr thing |
07:43 | ashimema | sure |
07:43 | marcelr | with smart rules |
07:43 | Joubu | not sure cait has started to push enh |
07:43 | marcelr | probably not |
07:43 | ashimema | I think she said she’d pushed one or two.. but I’m struggling to remember what they were |
07:45 | cait | she tends to get stuck on the bugs :) |
07:45 | but I had started to look at some enh | |
07:45 | lukeg joined #koha | |
07:46 | ashimema | Yeah.. there’s a bunch of enh in hte 'Needs documenting’ queue.. |
07:46 | that's certainly it I reckon | |
07:46 | cait | I think I had to fail all of them :( |
07:48 | davidnind | maybe a false alarm - I thought it showed all bugs pushed, not just enhancements (looking through all the recent bugs pushed, none are enhancements) |
07:49 | sorry to get you running around on a Friday morning! | |
07:50 | marcelr | exercise is good :) |
07:51 | ashimema: i am on 35100 | |
07:51 | lmstrand joined #koha | |
08:18 | ashimema | all good |
08:19 | I just pushed a couple of minor changes to the logic there | |
08:19 | we now include 'Needs documenting' bugs exclude the 'Documentation' component | |
08:19 | cait | ashimema++ |
08:19 | ashimema | I think that's the most accurate for 'New features' |
08:20 | davidnind | ashimema++ |
08:21 | ashimema | And now it's time for breakfast 🥞 |
08:32 | Joubu | "Holds allowed (total)" vs "Recalls allowed (total)" |
08:33 | the first one (holds) empty means unlimited, the second one (recalls) means 0 | |
08:33 | is that correct or is it still too early here? | |
08:38 | davidnind | For the recalls part, that is correct - you have to set the number of recalls allowed, otherwise none are allowed. |
08:39 | If I recall rightly from testing (some time ago now...) | |
08:43 | Joubu | not considering a bug that those 2 very similar features behave differently with the same config? |
08:53 | cait joined #koha | |
09:05 | davidnind | I don't think it is a bug, as such. But I can see how it could cause confusion or misunderstanding. |
09:08 | Considering that circulation rules are challenging enough already... 8-) | |
09:09 | ashimema | What's your plan in removing TT helpers Joubu? |
09:09 | as in.. what do you intend to replace them with.. or are you thinking a mix of things? | |
09:11 | Joubu | replace them using Koha::Objects |
09:12 | bug 35782, bug 35783 for examples | |
09:12 | huginn` | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=35782 enhancement, P5 - low, ---, jonathan.druart+koha, Needs Signoff , Remove Koha::Template::Plugin::Biblio::HoldsCount |
09:12 | ashimema | so, making sure we always pass objects from controllers everywhere a plugin might be used |
09:12 | huginn` | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=35783 enhancement, P5 - low, ---, jonathan.druart+koha, Needs Signoff , Remove Koha::Template::Plugin::Biblio::RecallsCount |
09:12 | Joubu | ashimema: yes, what is done in 35782 |
09:12 | we MUST use Koha::Objects (dbic and the rs) | |
09:13 | not this silly mix of passing ids and retrieving the related contents | |
09:15 | ashimema | ok |
09:15 | it'll be interesting to test and qa these things | |
09:15 | Joubu | and we should stop adding more... |
09:16 | ashimema | we'll need to be careful to spot the distance uses.. i.e where an include is used on loads of different pages we'll need to double check every pages controller sends back the full objects |
09:16 | I'm also interested in whether there's a perceived performance implication at all | |
09:16 | Joubu | yes, that's the tricky part, but it's a matter of 10min (at least for 35782) |
09:16 | can only be better :) | |
09:17 | ashimema | I suppose at the moment, if it's a tt plugin then it's already rendering serverside anyway.. I was considering whether we should be doing more async for some things.. i.e. api requests to replace a few instead of serverside rendering still |
09:18 | ok.. well.. I'm onboard anyway.. sounds like you've thought those things through already.. or are at least aware fo rthem | |
09:19 | Joubu | maybe some can be replaced with async fetch, so far I didn't find any |
09:21 | ashimema | coolios |
09:35 | Joubu | fredericdem: you should setup the RMaint pre-push hook... |
09:35 | fredericdem: https://jenkins.koha-community[…]0/276/consoleText | |
09:35 | fredericdem: koha_1 | # Failed test at xt/find-misplaced-executables.t line 54. | |
09:35 | fredericdem: koha_1 | # $VAR1 = './installer/data/mysql/db_revs/221112000.pl'; | |
09:35 | this is not supposed to happen | |
09:36 | fredericdem: https://wiki.koha-community.or[…]d_tricks#pre-push | |
09:43 | marcelr | ashimema: 35100 back to you |
09:43 | minor fix needed | |
09:56 | cait joined #koha | |
10:05 | ashimema | ta |
10:07 | marcelr | ja' |
10:08 | ashimema | thanks for the review.. yeah, I intend to squash but hoped leaving unsquashed for initial QA helped with the thought process understanding |
10:08 | your right.. I intended to write up a much clearer test plan for that last patch, just feel short on time yesterday with meetings | |
10:08 | you've really helped by spotting some other things though.. I'll revisit asap, really appreciate the review. | |
10:09 | transfers is SOOOOO confusing | |
10:09 | marcelr | sure |
10:09 | we should ask chris what word is confusing in Maori ? | |
10:10 | i hear it too often :) | |
10:10 | ashimema | I must admit.. I am starting to reconsider SR entirely.. it should outright drop it's reliance on transfers and just keep track of it's own shiz instead |
10:10 | it was nice to try and not duplicate data.. but transfers is just too active to reliably use that data they way SR does | |
10:11 | right.. I gotta review a few company policy documents before a management review I'm leading later today.. be back in a bit.. I hope | |
10:13 | NikolayGospodinov[m] | Hello. If I may, I have a question. When searching in catalog, Z39.50 returns no results, regardless of what I'm searching with: title, bibliographic number, ISBN, keyword |
10:13 | marcelr | ok ashimema (and try to have a look at 35341 please) |
10:14 | ashimema | got the tab open waiting for me 🙂 |
10:17 | Joubu | cait: do you agree with the "Holds allowed (total)" vs "Recalls allowed (total)" behaviour? I think we discussed that already somewhere.. |
10:29 | ashimema | on that bug now marcelr 🙂 |
10:29 | Joubu | "Holds allowed (total)" vs "Recalls allowed (total)" see bug 19532 comment 930 |
10:29 | huginn` | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=19532 new feature, P1 - high, ---, aleisha, Needs documenting , Recalls for Koha |
10:33 | cait | Joubu: sorry, not aware of the question/discussion |
10:33 | what is the issue? | |
10:34 | Joubu | cait: see bug 19532 comment 930 |
10:34 | huginn` | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=19532 new feature, P1 - high, ---, aleisha, Needs documenting , Recalls for Koha |
10:43 | tcohen joined #koha | |
10:59 | marcelr | thx ashimema |
11:00 | bye #koha | |
11:06 | matts_ joined #koha | |
11:12 | cait | Joubu: I commented |
11:15 | Joubu | thanks, cait |
11:32 | khall joined #koha | |
11:38 | cait | I also updated the wiki installation page a bit... I wonder if we should totally remove the 3.x installation guides? |
11:39 | https://wiki.koha-community.or[…]ion_Documentation | |
12:03 | ashimema | hell yes |
12:04 | cait | so... kill the whole section? |
12:05 | ashimema | I would say so |
12:05 | cait | I agree |
12:06 | i did it | |
12:06 | I'll also add an outdated note to the pages ith the instructions if I can manage | |
12:12 | khall joined #koha | |
13:09 | oleonard | I can't seem to reproduce Bug 35676 |
13:09 | huginn` | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=35676 normal, P5 - low, ---, jonathan.druart+koha, Needs Signoff , OPAC search results - link for "Check for suggestions" generates a blank page |
13:12 | Joubu | do you see the "Check for suggestions" text? |
13:22 | oleonard | No |
13:22 | Joubu | oleonard: disable didyoumean |
13:22 | admin > did you mean, and uncheck all checkboxes | |
13:23 | khall joined #koha | |
13:23 | oleonard | Yeah, I have done that. |
13:24 | Joubu | select value from systempreference where variable="OPACdidyoumean"; |
13:25 | you should not have "enabled" | |
13:25 | if you have, try again the admin config :D | |
13:25 | if you don't, restart_all, and try again | |
13:28 | oleonard | It's not ES only is it? |
13:29 | Joubu | yes, zebra only |
13:29 | oleonard | Oh sorry it is working, I don't know what I was doing before. |
13:30 | Is that "search for suggestions" link ever used? | |
13:32 | lds joined #koha | |
13:34 | oleonard | Thanks Joubu, and sorry for being the cause of the bug |
13:34 | khall joined #koha | |
13:37 | Joubu | oleonard: no this link is never used, when everything is working correctly it is replaced. We should never see it... |
13:46 | cait | No-JS-Fallback maybe? |
13:46 | an old one | |
13:55 | Dyrcona joined #koha | |
14:03 | huberto joined #koha | |
14:18 | khall_ joined #koha | |
14:27 | huberto | Hello everyone. We are seeing bug #34755 (https://bugs.koha-community.or[…]bug.cgi?id=34755) affecting our only client using OAuth. The bug is supposed to have been resolved by #34163 (https://bugs.koha-community.or[…]bug.cgi?id=34163), part of 23.05.04. Should I open a new bug referencing both of these? I found part of the cause of the bug, but I'm unsure of where to dig next. |
14:27 | huginn` | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=34755 critical, P5 - low, ---, tomascohen, RESOLVED DUPLICATE, Error authenticating to external OpenID Connect (OIDC) identity provider : wrong_csrf_token |
14:27 | 04Bug 34755: critical, P5 - low, ---, tomascohen, RESOLVED DUPLICATE, Error authenticating to external OpenID Connect (OIDC) identity provider : wrong_csrf_token | |
14:27 | 04Bug 34163: critical, P5 - low, ---, dcook, RESOLVED FIXED, CSRF error if try OAuth2/OIDC after logout | |
14:32 | Joubu | huberto: does it work if you click again on login? |
14:32 | from 34755 "If the user clicks once again on the login button he is logged in his opac account." | |
14:32 | huberto | Yes, that is exactly what happens. |
14:32 | fridolin joined #koha | |
14:33 | fridolin left #koha | |
14:33 | Joubu | huberto: reopen the bug and provide details |
14:33 | huberto | Alright, thank you! |
14:33 | Joubu | tell that you are using 23.05.04 and the bug is not fixed |
14:33 | do you see an error or warning in the koha log? | |
14:39 | huberto | No, but I've traced the source of the bug to the id used in the CSRF token generation. Sometimes the id of any recently logged in user is used instead of anonymous, sometimes anonymous is used. This means that upon returning from logging in to the SSO, the CSRF doesn't match, as the id doesn't match. |
14:39 | I'll try and setup koha-testing-docker in order to test using https://wiki.koha-community.org/wiki/Testing_SSO | |
14:41 | Joubu | if you can provide reproduction steps that would be great |
14:42 | huberto | I'll try and get as far as I can. |
14:48 | cait | maybe we should open a new bug - we will need this fixed in stable versions |
14:48 | but link to the existing one | |
14:50 | Joubu | the bug has been marked as duplicate |
14:51 | but it's not resolved | |
14:51 | it makes sense to reopen it | |
14:59 | magnuse | hm, i switched from zebra to elasticsearch and search is working, but background_jobs where queue = 'elastic_index' as stuck at status = new. i did "sudo koha-es-indexer --start kobarnbok" and "sudo koha-worker --start --queue elastic_index kobarnbok" but they are still stuck. anything else that needs to be started? |
15:00 | koha-indexer is running | |
15:01 | nothing interesting in worker-*.log | |
15:01 | Joubu | cait: ^ |
15:02 | magnuse | nor indexer-*.log |
15:02 | Joubu | magnuse: that's a "known" bug, but it needs to be investigated |
15:02 | magnuse | tried turning off rabbitmq too |
15:04 | cait | Joubu: all good then thx |
15:04 | Joubu | magnuse: it's koha-es-indexer |
15:05 | cait | magnuse: we have seen a lot of thos, but not all stuck too |
15:05 | Joubu | "new" jobs should be started without using rabbitmq if it's off |
15:05 | cait | curious for a solution |
15:05 | magnuse | koha-es-indexer is running too |
15:05 | Joubu | magnuse: stop the rabbit and restart koha-es-indexer |
15:06 | magnuse | yeah, that seems to have done the trick |
15:07 | and new jobs do get processed | |
15:07 | Joubu | yes, but it does not fix the problem :-/ |
15:07 | magnuse | nope |
15:08 | well, it does for me right now ;-) | |
15:10 | also, it looks liekwe could document the need to start koha-es-indexer and "koha-worker --queue elastic_index" when switching from zebra to elastic better too | |
15:39 | Joubu | lauraesca[m]: around? |
15:40 | lauraesca[m]: re bug 35714 - did you run the `yarn js:build` command? | |
15:40 | huginn` | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=35714 normal, P5 - low, ---, jonathan.druart+koha, Failed QA , Clicking Print slips when no letter template selected causes error |
16:00 | bag joined #koha | |
16:12 | khall joined #koha | |
16:21 | huberto | What's a common mistake that could cause the "No configuration found for your provider" error, while trying to use SSO with KTD? |
16:21 | I have followed https://wiki.koha-community.org/wiki/Testing_SSO but I must have skipped over something. | |
16:25 | bag | ashimema++ |
16:35 | huberto | Ok, so I had to manually specify the authorize_url, token_url and userinfo_url from keycloak's openid configuration page. Now I'm getting the following error when logging in through the SSO: Cannot assign requested address. |
17:54 | khall joined #koha | |
19:04 | khall joined #koha | |
19:06 | michael_hafen joined #koha | |
19:08 | michael_hafen | Hello |
19:11 | huberto | Hi |
19:18 | michael_hafen | I could use some help, I think my problem is Ubuntu. Any Ubuntu experts here? |
19:19 | Or maybe I should say I need to report a problem with Ubuntu? | |
19:19 | huberto | What is the issue, exactly? |
19:21 | michael_hafen | I'm trying to upgrade Koha on my workstation (before touching my production servers), and I can't get 'yarnpkg build:prod' to work. It reports a missing module. I tried 'yarnpkg install' too, and there cypress complained that nodejs was to old. |
19:21 | I can wait until next July-ish when Ubuntu 24.04.01 is released, but that would put me a fair bit behind on Koha releases. | |
19:22 | huberto | Yes, you need to install a version of nodejs that's in the sweet spot of supported versions. Are you using Node 14 at the moment? |
19:23 | michael_hafen | Ubuntu 22.04 comes with nodejs 12. I'm not sure how to get 14. |
19:24 | huberto | I think 14 is also too old. I believe version 16-18 work though. For installing a different node version, you could always use Node Version Manager, NVM. |
19:25 | To install nvm, you need to have curl on your machine, though. | |
19:26 | michael_hafen | I tried updating nodejs from nodesource to version 18, but I lost yarnpkg doing that. Some dependency wanted nodejs v12. I'll try nvm and nodejs v16 though. Do you have the address for it at hand? |
19:27 | huberto | `curl https://raw.githubusercontent.[…]master/install.sh | bash` should do it. |
19:47 | For the record, my "Cannot assign requested address" SSO problem was linked to a bad hostname in my KTD's host file. I have enough information to reopen the bug now. | |
19:59 | caroline | Is it normal that a staff with view_borrower_infos_from_any_libraries permission cannot see who an item is checked out to? |
19:59 | tuxayo | michael_hafen: hi :) «cypress complained that nodejs was to old» if you want to prepare a production upgrade, cypress is not relevant for that. Cypress is a testing tool. In what context does it complains? |
20:01 | michael_hafen | tuxayo: I have updated koha from git (dev-mode) and am trying to run yarnpkg install --frozen-lockfile, during the fetch cypress12.17.4 complains about node. |
20:01 | caroline | HidePatronName is set to show too. I can't figure out why the name would be hidden |
20:02 | michael_hafen | caroline: IndependentBranches ? |
20:02 | caroline | no it's off |
20:05 | it's something that's changed between 22.05 and now. | |
20:05 | I'm wondering if it's a bug or a new parameter that's not on by default | |
20:06 | tuxayo | michael_hafen: our CI job that runs cypress test is using Debian 11, I wonder why it has not issues. https://jenkins.koha-community[…]/2770/consoleText |
20:07 | michael_hafen | I have Ubuntu LTS (22.04) which comes with nodejs v12 |
20:07 | tuxayo | The equivalent of yarnpkg build:prod might be done when building the image. But still the env would be Debian 11. With not a more recent node than Ubuntu 22.04 |
20:07 | caroline: hi :) maybe what you have is related to bug 30230 | |
20:08 | huginn` | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=30230 normal, P5 - low, ---, thibaud.guillot, Failed QA , Search for patrons in checkout should not require edit_borrowers permission |
20:08 | tuxayo | Hm, the change that requires the above is Bug 15812 and it's from 21.11.00 |
20:08 | huginn` | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=15812 normal, P3, ---, nick, CLOSED FIXED, Checkout search with too many results (single character search) causes poor performance or timeout |
20:09 | michael_hafen | tuxayo: yarnpkg build:prod failes with cannot find module 'stream/promises' for me during the opac build, which is why I was trying yarn install. |
20:10 | tuxayo | michael_hafen: ok, the build of the images of the CI and koha testing docker (the dev env most people use) installs a recent nodejs |
20:10 | So if you want to have your dev env setup from scratch you indeed need to have a recent enough nodeJS | |
20:13 | michael_hafen | I tried nvm to use a newer nodejs, but that ran into cannot find module '@babel/runtime/helpers/interopRequireDefault'. |
20:13 | caroline | My patron has all the borrower permissions though, including edit_borrowers |
20:15 | tuxayo | michael_hafen: weird. If that can help, the images used either node 16 or 18, depending on the base OS (18 for UB 22.04) |
20:15 | caroline: ok, it's not that then. | |
20:16 | caroline: «it's something that's changed between 22.05 and now. » If you can reproduce that on your local environment, `git bisect` can help find the exact commit where that changed :) | |
20:17 | caroline | oh I've never use git bisect yet! I usually try git log <file> or git blame <file> |
20:18 | tuxayo | usage: git bisect start. Then git bisect bad upstream/master (it tells that the issue can be seen on master (assuming your remote is called upstream)) |
20:18 | Then git bisect good v22.05.00 to tell that it was ok on v22.05.00 | |
20:19 | Then git will checkout to a commit between main/master and v22.05.00 | |
20:19 | caroline | I think mine is called origin/master, because when I want to reset, I do git reset --hard origin/master |
20:19 | tuxayo | ok |
20:19 | Then you will do reset_all | |
20:19 | And test if the issue is there | |
20:19 | If it's there do git bisect bad, if it's not, do git bisect good | |
20:20 | Then depending on your answer, git will move to a commit closed to main/master or 22.05 | |
20:20 | And you do reset_all | |
20:20 | retest | |
20:20 | caroline | interesting! |
20:20 | tuxayo | and tell git bisect if it wall good or bad |
20:22 | The problem if that v22.05.00 is old and even the middle between main/master and v22.05.00 can be too old and the dependencies of koha changed enough that koha won't start. Because you still have all the perl libs from today... ^^ | |
20:22 | cait | i love git bisect |
20:22 | tuxayo | :D |
20:22 | cait | it's a great tool, but I also love to mumble: bad! good! when I do it |
20:22 | tuxayo | You can circumvent the above issue by using an older KTD image |
20:23 | * caroline | is mumbling right now |
20:23 | tuxayo | he he |
20:23 | KOHA_IMAGE=22.05-jammy ktd up | |
20:23 | KOHA_IMAGE=22.11-jammy bin/ktd up | |
20:23 | So turns out it should even work far in the past! | |
20:24 | After all that you might want to clean old docker images because over time it can take tons of GB | |
20:24 | docker image ls | |
20:25 | And then docker image delete 3e87f8bfed4e #← image ID of the one you want to delete | |
20:25 | caroline | oh yes, I had to do that this week... I had 6-8 images (I didn't know it kept it each pull) and my disk was full... |
20:26 | tuxayo | caroline: there is also `docker system prune --volumes && docker volume prune --all # prune aggressively` |
20:26 | Be careful, if you use docker for something else than Koha | |
20:27 | you have to know docker and what you are doing because it might delete volume where you hypotetically have data for something else that koha | |
20:27 | caroline | I had tried `docker container prune -a` but it didn't do much... I went with docker image delete X |
20:29 | Sorry, I'm still new to KTD. The git bisect thing do I do that in my koha git or in the ktd --shell? | |
20:33 | tuxayo | docker container prune -a doesn't do much in our usage of docker IIRC |
20:35 | caroline: git bisect is to be done in the same place you usual do git stuff, like change branches | |
20:35 | caroline | perfect thanks! |
20:46 | tuxayo | yw, I hope that lead somewhere ^^ There are 6556 between main/master and 22.05 so are worse you will do 13 hops at most ^^ |
20:46 | *6556 commit | |
20:46 | davidnind | docker system prune -a and docker system prune --volumes (separate commands) works for me) |
20:48 | tuxayo | does it still manage to delete something more with docker system prune --volumes or docker volume prune --all ? |
20:49 | davidnind: lol `docker system prune -a` as I should have expected deleted all containers, I have to redownload to start koha ^^" | |
20:51 | > docker system prune -a | |
20:51 | It just says prune, so maybe not that obvious it was that agressive | |
20:51 | davidnind | yes, yes they do delete everything ☠️ |
20:51 | tuxayo | lol |
20:54 | caroline | so does the bisect take the exact middle commit? |
20:54 | or a random one in between | |
20:54 | tuxayo | middle |
20:56 | davidnind: You might be happy with `docker system prune --volumes && docker volume prune --all` | |
20:56 | It still keeps latest version of images. Then you can use `docker image ls` and `docker image delete IMAGE_ID` to remove stuff you don't want like and old koha branch | |
20:57 | caroline it takes the middle that why even with a lot of commits, it's not that long. 32 hops to search in 4 000 000 commits! | |
20:58 | caroline | Yes I was suprised, at first it said 3000+ revision (roughly 12 steps), I though it wasnt that much (althoug it is because my test plan is a bit long, esp. with the db reset in between |
21:00 | tuxayo | caroline: also: «After a bisect session, to clean up the bisection state and return to the original HEAD, issue the following command: `git bisect reset`» |
21:00 | caroline | +1 thanks! will do |
21:01 | tuxayo | you might have you test disturbed if bisect puts you on a commit where koha was totally broken. Then you need to manually checkout to another commit. Don't do git bisect bad since it's not the problem you are searching |
21:01 | davidnind | thanks tuxayo! I'll try that next time and update my KTD snippet |
21:01 | tuxayo | *your test |
21:02 | git bisect doesn't care to jump in the middle of commits of a given bug. It's possible to have a inconsistent code. | |
21:28 | caroline_catlady joined #koha | |
21:59 | caroline | git bisect pointed me to a commit, but I don't know how it's related... I wrote a bug report and mentioned it in case it helps |
21:59 | bug 35800 | |
21:59 | huginn` | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=35800 enhancement, P5 - low, ---, koha-bugs, NEW , edit_any_item permission required to see patron name in detail page |
22:00 | caroline | the bug that git bisect pointed me to is bug 33167 |
22:00 | huginn` | 04Bug https://bugs.koha-community.or[…]_bug.cgi?id=33167 normal, P5 - low, ---, nick, RESOLVED FIXED, Cleanup staff interface catalog details page |
23:01 | tuxayo | caroline: you can double check the result of git bisect by manually going to the previous commit and confirming that it works there. |
23:03 | Just in case of a mistake when telling bad or good in a previous step |
← Previous day | Today | Next day → | Search | Index