IRC log for #koha, 2020-08-25

← Previous day | Today | Next day → | Search | Index

All times shown according to UTC.

Time Nick Message
00:09 inlibro joined #koha
00:16 tuxayo aleisha: o/ I hope my response via email will help. This first security release sure is confusing.
00:21 aleisha i think it does help, and it confirms some of the assumptions we were making over here. but the trouble is that they are assumptions and the wiki isn't clear enough, if Joubu or mtj or tcohen can confirm what you've written, it would be awesome if you could update the wiki tuxayo because your explanation was much clearer to me.
00:23 tuxayo aleisha: Indeed, needs confirmation. And improving the documentation.
00:26 cait1 joined #koha
00:28 tuxayo aleisha: Related: you might need to do some messy stuff due to the fact that the public 19.11.x branch has release commits like if there was a parallel release. So without the security patches.
00:29 Not sure what git choreography would fit the most.
01:09 inlibro joined #koha
01:24 mtj hey #koha
01:29 hi aleisha, still about?
01:41 ..tuxayo's assumptions in his email are correct :)
01:42 for a security release, rmaints push their stuff to the security.git repo, rather than the koha.git repo
01:49 ...after the co-ordinated release has happened, the rmaints can finally update their branch on the koha.git repo
01:51 so its identical to a regular release, except that rmaints are pushing to a private repo
02:09 inlibro joined #koha
02:14 aleisha thanks mtj and tuxayo - that stuff was super unclear for me
02:26 mtj aleisha: np, ill be about this arvo if you have some Qs
02:27 aleisha i have pushed the translation patches and increment version commit to the maintenance branch
02:27 should i revert those or just leave them?
02:32 mtj hmm, i think revert them
02:36 i wonder how people feel about setting up a private gitweb and jenkins, for the security repo?
02:37 rangi then what happens with the security branch after release, and how does all the stuff get back on to the main branch?
02:38 the tag needs to match the tag on the release
02:38 so you cant tag the security one, unless you plan to merge the security one back into the main one
02:38 or that tag is going to be pointing to a commit no one can reach
02:38 or worse pointing to a commit that isnt actually the one the package was built from
02:40 this is why we never did it this way
02:41 we just put the security patches on last, and pushed
02:41 because this is way way way overcomplicated
02:41 and error prone
02:43 if they are urgent enough to need this level of security they should go out in an actual security release
02:43 not a maintenance release
02:43 </rant>
02:44 hayleymapley__ Error: no opening rant tag
02:44 rangi heh
02:45 mtj hi rangi.. so that would be a no? :)
02:45 rangi i think the plan that people agreed to originally, on the email
02:45 where the main commits are on the main branch, the security ones are on the security one
02:46 (email on the 6th of august)
02:46 is what has been followed, so it can't change now
02:47 the security branches were for doing a security release, not a combined one
02:47 thats where this mess is occuring
02:48 mtj aah right, i hadnt made that distinction
02:54 so lets follow the plan from the email on the 6th of august
02:54 khall joined #koha
02:59 rangi sweet
03:01 aleisha okay mtj, so what ill do is make a new branch in the security repo based off of v19.11.08, apply only the security bugs (because i had done that part wrong anyway), and then cherrypick them over to the 19.11.x maintenance branch
03:09 inlibro joined #koha
03:17 mtj rangi: you mentioned before ..."then what happens with the security branch after release, and how does all the stuff get back on to the main branch"
03:19 rangi (when doing one of these weird combined ones)
03:19 mtj if each rmaint pushes their security branch to the koha.git repo after release... then all the commits and tags are avaiable and correct?
03:19 tuxayo It should be the case indeed
03:19 rangi yeah but you cant do that, if you have been pushing to the main repo already
03:19 tuxayo rangi: «i think the plan that people agreed to originally, on the email »
03:19 «where the main commits are on the main branch, the security ones are on the security one»
03:19 rangi you cant do a -f push
03:19 tuxayo ouch i misunderstood that
03:19 rangi that will mess up everyones git checkouts
03:20 you can either merge from your security branch
03:20 or you can cherry-pick from there
03:20 back to the main one
03:20 alternatively you branch from main one, push everything to security branch, push that over the main one
03:21 which means you have a month of no changes on the branch, then suddenly a whole montsh worth
03:21 this totally breaks the workflow from where 19.11 cherry-picks from 20.05 etc
03:21 so basically only security patches on a security branch
03:22 merge it in for release
03:22 or, if its an actual security release
03:22 ie out of cycle, release from security branch, merge it in after
03:22 because that branch will have the last release + security patches only, which is what a security release should have
03:23 otherwise its a maintenance release, in the normal cycle, that just happens to have some security patches in it (not urgent enough for a full security release)
03:23 does that make sense?
03:23 tuxayo «otherwise its a maintenance release, in the normal cycle, that just happens to have some security patches in it (not urgent enough for a full security release)»
03:23 That seems to be the case here.
03:24 rangi yeah in which case you just truck along pushing to your normal branches, except for the security patches, cos you dont want ppl seeing them until the day of the release
03:25 you dont even really need to use the security branch, it does no ci, has no benefit, except for rolling a security release, without disturbing the workflow on the normal branch
03:25 you just push the security patches as you are about to release
03:27 its hard to explain in text :)
03:34 mtj rangi: thanks, your description makes sense :)
03:34 * tuxayo sent a long message:  < https://matrix.org/_matrix/med[…]VesiC/message.txt >
03:34 tuxayo Oops, draft sent
03:34 rangi heh
03:35 tuxayo Here is the clean version
03:35 My plan if I was able to work enough on Koha as I initially planed was to continue to backport normal patches to the public branch and on release day, rebase the security branch on it.
03:35 And do the release process on the security branch that had all the commits.
03:35 That matched how I understood the «RMaints will have security bugs pushed to their security repos (Regular repos will have everything BUT the security bugs)»
03:35 I'm not sure what everyone had I mind about this phrase but it look very diverse ^^
03:35 «it does no ci, has no benefit, except for rolling a security release, without disturbing the workflow on the normal branch you just push the security patches as you are about to release»
03:35 +1
03:35 Thanks, it's simple to understand in the case of a dedicated out of cycle security release.
03:36 (finished, sorry for the mess)
03:38 «this totally breaks the workflow from where 19.11 cherry-picks from 20.05 etc»
03:38 I still cherry-picked security patches from my upstream. And also normal patches (if could continue to work on them)
03:39 rangi basically you need to have at the point of the release
03:39 everything on the normal branch
03:40 otherwise if i as a user want to look at the logs, i cant
03:40 i dont care how you get it there, but it all needs to be in the normal branch as soon as (or even just before) the release
03:41 thats the end goal, so there are many ways to do it, but none of them should involve either a rebase of the normal branch, or a force push :) as long as they dont do that, people can continue using the branches, safe in the knowledge that it has everything on it
03:42 and if i want to audit the code of the security release i can (this is an average sysadmin/user)
03:42 before applying it to my koha
03:43 khall joined #koha
03:47 mtj yes, agreed
03:54 tuxayo rangi: «all needs to be in the normal branch as soon as (or even just before) the release»
03:54 That wasn't the idea of the security release process:
03:54 https://wiki.koha-community.or[…]security_releases
03:54 «RMaints push the patches from Bugzilla to the protected security repository. They don't push to their normal branches until some time after release. »
03:54 Which doesn't look a good choice for me. As git install can't use it
03:55 rangi it also means that no one can check the security fixes
03:55 but that is for a full on, we have a zero day, need to do a security release now workflow
03:55 not the well we should fix these but its not urgent they can wait until the maintenance release
03:56 tuxayo And if we are that paranoid we should not put in the release note the names of security bugs. Because some are self explanatory and the code of the fix can be found back
03:56 rangi exactly
03:56 aleisha <tuxayo> That wasn't the idea of the security release process:
03:56 tuxayo: that was part of the problem, is every time i asked a question i was referred back to the wiki
03:56 which clearly wasn't applicable for this type of release
03:58 tuxayo aleisha: It wasn't clear for me until now that this process had issues. Because I had interpreted things compatible with it. But likely it wasn't what everyone had in mind during the planing of the release.
03:59 aleisha that's fair enough :) we should rewrite the wiki with clearer instructions so something like this doesnt happen again.
04:01 tuxayo aleisha: Hopefully have one security workflow (maybe just a small variation inside) for both urgent and non-urgent security releases.
04:01 Because two workflow could also cause confusion or inconsistencies in the future.
04:03 aleisha i think two workflows is fine as long as they are both clear - but i dont think that the workflows are that different that we would need two anyway :)
04:03 khall joined #koha
04:09 inlibro joined #koha
04:10 tuxayo rangi: «it also means that no one can check the security fixes»
04:10 That's the expected tradeoff for these kind of release to have the thing less exploitable on the short term to let people a bit of time to upgrade. Not sure that it fits Koha but that not a very though of opinion.
05:10 inlibro joined #koha
05:12 chriss joined #koha
05:15 aleisha i've just sent an email hopefully clarifying everything!
05:21 kohaputti joined #koha
05:31 mtj thanks aleisha, still about?
05:36 fridolin joined #koha
05:51 kohaputti mtj, hey! :) Would you have time to comment on https://bugs.koha-community.or[…].cgi?id=16357#c65 ? It's about debian/control changes and the cpanfile.
05:51 huginn Bug 16357: normal, P3, ---, dcook, Failed QA , Plack error logs are not time stamped
05:51 dcook Thanks kohaputti :) (and pre-emptively mtj)
06:00 mtj kohaputti: i'll add a patch for the control.in file
06:01 lmstrand joined #koha
06:06 kohaputti mtj, thanks. I would like to document the process to wiki also. Are you adding the patch separately from this bug or? And what dependencies go now to cpanfile and are some that need to be added to debian/control.in, and then debian/control file is always updated by you?
06:07 did joined #koha
06:10 inlibro joined #koha
06:13 mtj hi kohaputti, i added the patch to the bug
06:15 the ./debian/update-control script uses cpanfile (and control.in) to update the ./debain/control file
06:16 kohaputti ok, so developer should update cpanfile and control.in, is that right? What running update-control script?
06:17 What about*
06:20 mtj mostly updating the cpanfile is important, and manually updating the control file (usually not control.in)
06:22 kohaputti thanks, I will draft some steps to the wiki page about packaging after finishing reviewing this bug report.
06:23 mtj the package building process uses update-control in a pristine pbuilder instance, to create a new control file
06:24 ... but its really not needed for a developer when sending a patch, you can manually edit cpanfile and control :)
06:26 kohaputti mtj, one more thing, we should remove now the change to control file since it will be overriden with the update-control run in the pbuilder instance? Or can that be left there now that it is already there?
06:32 mtj kohaputti: its ok to leave it there
06:32 kohaputti ok, thanks a lot for the help :)
06:42 reiveune joined #koha
06:42 reiveune hello
06:54 cait joined #koha
06:55 cait joined #koha
06:56 alex_a joined #koha
06:56 alex_a Bonjour
06:57 cait joined #koha
06:59 cait1 joined #koha
06:59 cait1 good morning #koha!
07:03 lds joined #koha
07:06 cait joined #koha
07:06 * magnuse waves
07:10 inlibro joined #koha
07:20 dolf Good morning! Is there a way to add examples or descriptions for librarians in cataloging frameworks? I can modify the field headings (e.g. changing "MAIN ENTRY -- PERSONAL NAME" to "AUTHOR" for very simple frameworks), but for more complex fields, like 773$g, I would like to show an example of the desired format on screen.
07:21 lds hi
07:23 cait1 dolf: you could create your own marc help
07:23 but that's maybe a bit much
07:23 adding tooltips with jquery might be another option
07:24 dolf Thanks for the ideas. Creating marc help: is that in the docs somewhere?
07:28 cait1 check the system preferences for docs
07:29 you can have your own llink structure there
07:29 so you can point it to local fiels that are named with the marc fields or similar
07:29 by default the links go to LOC
07:30 kohaputti++ thx :)
07:32 lukeG joined #koha
07:33 kohaputti cait1, thanks to you for clearing the huge QA backlog, well over 100 bugs you have went through this month! :)
07:47 dolf cait1: Thanks!
07:48 magnuse cait++
08:10 inlibro joined #koha
08:27 kohaputti I didn't find any appropriate existing page other than https://wiki.koha-community.or[…]Coding_Guidelines for the debian packaging instructions but to add it there we need to discuss it in the next development meeting.
08:29 tuxayo kohaputti: debian packaging instructions in the sense of building them?
08:29 https://wiki.koha-community.or[…]es_-_The_Easy_Way
08:29 https://wiki.koha-community.or[…]g_Debian_Packages
08:30 kohaputti tuxayo, no, we were discussing earlier here about what patches a developer should sent, just a patch to cpanfile, control.in, etc.
08:30 or no patch at all
08:31 tuxayo ok, very different ^^
08:33 alex_a joined #koha
08:37 Joubu kohaputti: cpanfile (which replaced C4/Installer/PerlDependencies.pm)
08:38 and debian/control
08:39 no, debian/control is automatically generated by the package manager (see 17084)
08:39 wshealy joined #koha
08:40 tuxayo Some news about the 19.05 release: Re running the test whole test suite. I got failures and though many things were broken.
08:40 Turns out the test env was somehow broken during the previous hours of usage...
08:46 kohaputti Joubu, let's discuss in the next dev meeting and if everybody agrees add a few words about this to the coding guidelines.
08:47 Joubu kohaputti: new dependency => change to cpanfile and eventually to debian/control (must be generated with debian/update-control)
08:47 there is nothing to discuss, it's an established workflow
08:47 but we can add something to the wiki if it's not clear
08:48 kohaputti Joubu, given the recent move from C4/Installer/PerlDependencies.pm I think it was not clear. Some documentation somewhere is definitely useful.
08:48 Joubu well, we can discuss everything! I don't want to be rude :)
09:10 inlibro joined #koha
09:32 kohaputti cait1, hey would you be interested in checking the bug 11175 about component records in biblio view? You mentioned many many years ago you were interested in the feature so I thought to ask xD I fixed some stuff that was requested and I think it is ready for sign-off now.
09:32 huginn Bug http://bugs.koha-community.org[…]_bug.cgi?id=11175 enhancement, P5 - low, ---, joonas.kylmala, Needs Signoff , Show the parent record's component parts in the detailed views
10:10 inlibro joined #koha
10:16 Joubu kohaputti: bug 16357 does not work for me. did you test it in a docker container?
10:16 huginn Bug http://bugs.koha-community.org[…]_bug.cgi?id=16357 normal, P3, ---, dcook, Passed QA , Plack error logs are not time stamped
10:17 kohaputti Joubu, I tested in koha-testing-docker and build debian package and tested it, what's the issue you are having?
10:17 Joubu the log files are not created
10:17 and so I don't see the warn
10:18 I edited .psgi and log4perl.conf accordingly, then added the warn, restart_all
10:18 kohaputti Joubu, have you changed the log4perl configuration / followed the steps in test plan? You need fresh debian package install for them to be set automatically in this new way
10:18 hmm
10:19 Joubu Log4perl: Seems like no initialization happened. Forgot to call init()?
10:19 kohaputti Joubu, did you add a warning message to mainpage.pl manually?
10:19 Joubu hum
10:19 wrong copy paste
10:20 kohaputti Joubu, the files are created only if there are warnings
10:21 ah, you said you added that too
10:21 hmm
10:22 Joubu kohaputti: must be me, I am double checking the changes I made
10:22 did you notice the difference in the format?
10:23 kohaputti yes
10:23 Joubu 30 log4perl.appender.API.layout.ConversionPattern=[%d] [%p] %m %l %n
10:23 63 log4perl.appender.PLACKINTRANET​.layout.ConversionPattern=[%d] [%p] %m
10:23 kohaputti ah, that one I didn't notice
10:23 Joubu the %l and %n are not there for plack
10:23 there were not there for the existing plack log, but wondering what they mean
10:27 kohaputti they are described here https://metacpan.org/pod/Log::[…]4perl#Log-Layouts
10:28 so some extra debugging info, the point of this bug report was to add the date and time which it does now, we could however make a follow-up bug report for adding even more info if wanted
10:29 just have to make sure %l and %n are valid also in this context
10:30 Joubu yes, agreed
10:30 cait joined #koha
10:33 kohaputti Joubu, did you install the new debian package dependency?
10:33 "libplack-middleware-logwarn-perl"
10:35 Joubu yes, actually I was missing the Koha::Logger->get in .psgi..
10:49 kohaputti Joubu, hopefully my latest reply also addresses "Or, maybe we should keep log4perl.logger.plack (ie. stderr) as fallback if the logger does not get initiated properly?"
10:54 Joubu kohaputti: I don't understand why we went that far on this bug report
10:55 we should not have split into 3 files, it should be a separate bug report
10:55 kohaputti adding log4perl?
10:55 or what should be separate
10:57 Joubu, the only real change here is to plack.psgi, and if the koha admin doesn't want to modify the log4perl.conf file things keep working the same as before as far as I can tell.
10:58 oleonard o/
10:59 Joubu no
10:59 kohaputti: I let a comment
10:59 logs are lost
10:59 kohaputti Joubu, thanks I saw it, I understand now
10:59 Joubu hi oleonard!
10:59 wahanui hi oleopard
10:59 kohaputti Joubu, what logs this loses?
11:00 Joubu the warn
11:00 nugged joined #koha
11:00 kohaputti Joubu, if you keep the log4perl.conf files the same as they were before it doesn't lose them, it adds them to plack-error.log as it has before
11:01 Joubu so there is no warn to tell something went wrong, no warn on the about page, and the error is lost
11:01 kohaputti: it's not what I am seeing
11:01 kohaputti hmm, that's how it worked for me
11:02 Joubu, so you copied the plack.psgi from the bug report and didn't modify log4perl.conf?
11:02 Joubu yes
11:02 kohaputti ok, I did that too and for me the warns kept going to plack-error.log
11:03 I will retry
11:04 tuxayo All the tests passed in the 19.05.x, I can move on with the release :D
11:06 cait joined #koha
11:07 cait kohaputti: i try to avoid sign-offs... they get stuck in QA :(
11:08 kidclamp++
11:08 kohaputti Joubu, I think I was able to reproduce the issue now, let me double check still
11:09 GeekRuthie joined #koha
11:10 marcelr joined #koha
11:10 marcelr hi #koha
11:11 inlibro joined #koha
11:12 tuxayo o/
11:14 kohaputti Joubu, ah, I know why it kept working, since the plack.psgi is not updated either during package install
11:15 s/install/upgrade/
11:18 khall_ joined #koha
11:33 eythian hi
11:33 wahanui que tal, eythian
11:40 lukeG1 joined #koha
11:46 marcelr hallo eythian
11:46 eythian hoi marcelr
11:46 marcelr still in a'dam?
11:47 eythian Yep. Rainy Amsterdam right now.
11:47 marcelr Wasnt there quite a bit now
11:48 eythian Yeah, there's been a lot of short storm downpours. This looks more like regular rain.
11:49 marcelr Didnt mean the rain ;)
11:50 fridolin joined #koha
11:51 eythian Oh, that sentence had no onderwerp, hence my confusion :) No, I also haven't gone far except one trip to Scotland a few weeks back.
11:58 khall joined #koha
12:01 Dyrcona joined #koha
12:07 * cait waves
12:08 cait marcelr: eythian nice to see you around :)
12:09 tuxayo o/
12:11 inlibro joined #koha
12:11 cait you too tuxayo ;)
12:19 eythian marcelr: I'm always around :)
12:20 tcohen morning
12:23 khall_ joined #koha
12:30 caroline joined #koha
12:42 marcelr hi tcohen
12:42 tcohen hi marcelr
12:42 marcelr you dont give up on smtp yet
12:42 tcohen should I?
12:42 he
12:43 I rewrote it and am happy with the results
12:43 marcelr no way
12:44 rewriting your own code is a very good process :)
12:44 tcohen I am really happy with the questions ashimema[m] and Joubu made about the code, that yield this re-rewrite
12:46 marcelr the third rewrite is the best
12:46 cait heh
12:46 marcelr: so beware of yoru incoming comments?
12:47 marcelr dont worry
12:51 Joubu cait: can you have a look at the last 2 comments on bug 25534?
12:51 huginn Bug http://bugs.koha-community.org[…]_bug.cgi?id=25534 enhancement, P5 - low, ---, kyle, Passed QA , Add ability to send an email specifying a reason and store the reason when canceling a hold
12:55 Joubu tcohen: hola! plack.psgi is getting modified when koha-common is updated, right?
12:55 tcohen yes, but
12:56 you might be running an instance-specific one I think
12:56 the answer is 'yes, we patch plack.psgi' on update
12:56 Joubu did you follow the discussion on bug 16357?
12:56 huginn Bug http://bugs.koha-community.org[…]_bug.cgi?id=16357 normal, P3, ---, dcook, In Discussion , Plack error logs are not time stamped
12:57 tcohen somehow
12:57 not lately
12:57 Joubu from this "morning" :)
12:58 We have something in postinst to keep log4perl in sync, but I was wondering about plack.psgi then
12:58 I guess it's because log4perl contains paths, plack.psgi can be copied as it
12:58 kohaputti Joubu, I think plack.psgi should be left for the sysadmin
12:59 the instance specific ones I mean
12:59 Joubu the question is: can we assume they are always in sync (ie. the new version from 16357 for both files will be applied), or should we have a fallback in case the "log components" does not exist/is not valid
13:00 /$/?/
13:00 tcohen I prefer it to explode with meaningful error messages
13:00 khall joined #koha
13:00 Joubu me too
13:00 k
13:02 kohaputti Joubu, e.g. a if check in plack.psgi that those configuration lines in log4perl.conf exists, if not die?
13:03 tcohen I prefer that, but we should avoid explosion be the default behaviour for an upgrade thousands will do, he
13:03 Joubu we should not do that manually, ::init should tell us if something is wrong
13:03 kohaputti if there are no issues in this case the postinst script should add those configuratin lines
13:04 Joubu kohaputti: we have some code in about.pl to display potential config issues
13:04 the problem here is that we don't longer have something on the about page
13:05 I am expecting: 1. A geant warning in the log (we have a tiny line from log4perl), and 2. something meaningful on the about page
13:11 inlibro joined #koha
13:16 huginn News from kohagit: Bug 26265: add a plan for tests <http://git.koha-community.org/[…]007d3583a048917f2>
13:16 News from kohagit: Bug 25534: DBIC schema changes <http://git.koha-community.org/[…]718f9cf3b31c5b070>
13:16 News from kohagit: Bug 25534: DBRev 20.06.00.029 <http://git.koha-community.org/[…]eeed46002a02220fc>
13:16 News from kohagit: Bug 25958: DBRev 20.06.00.028 <http://git.koha-community.org/[…]c4f8acd69d17375e9>
13:16 News from kohagit: Bug 25958: (QA follow-up) Implement filter in database query instead of in loop <http://git.koha-community.org/[…]5e8d5546f13f05645>
13:16 News from kohagit: Bug 25534: (QA follow-up) Use modal for cancel links, hide reason unless priority... <http://git.koha-community.org/[…]08ef9e122276c6049>
13:16 News from kohagit: Bug 25534: (QA follow-up) Update Koha::Hold::cancel POD <http://git.koha-community.org/[…]6b400449461e04b41>
13:16 News from kohagit: Bug 25534: Use build_sample_item in tests <http://git.koha-community.org/[…]79bd2f827245e2de2>
13:16 News from kohagit: Bug 25534: (QA follow-up) Add sample notices for translators <http://git.koha-community.org/[…]34bbd9d7b8354c315>
13:16 News from kohagit: Bug 25534: (QA follow-up) Add default values for new AV category <http://git.koha-community.org/[…]01cdad5402872e0ac>
13:16 News from kohagit: Bug 25534: (QA follow-up) Add AV category <http://git.koha-community.org/[…]40ec07f46b5a476c8>
13:16 News from kohagit: Bug 25534: (QA follow-up) Add label to reason pulldown <http://git.koha-community.org/[…]268aa8312f7680e3d>
13:16 News from kohagit: Bug 25534: (QA follow-up) Add sample notice <http://git.koha-community.org/[…]ab5b52c3252b70cdf>
13:16 News from kohagit: Bug 25534: (QA follow-up) Unit tests <http://git.koha-community.org/[…]46472391c0589f82a>
13:16 News from kohagit: Bug 25534: (QA follow-up) Add missing TT filters <http://git.koha-community.org/[…]40d7702fbef17bb60>
13:16 News from kohagit: Bug 25662: (follow-up) Add tests for the wrong patron_id added behaviour <http://git.koha-community.org/[…]dc519f15d41a5b575>
13:16 News from kohagit: Bug 25662: Make the route for holds restpect maxreserves <http://git.koha-community.org/[…]b2bfc472ba24a5054>
13:16 News from kohagit: Bug 25662: Regression tests <http://git.koha-community.org/[…]07fe74f9083167ccc>
13:16 News from kohagit: Bug 25534: Add reason to pendingreserves.pl <http://git.koha-community.org/[…]94e2073ec8d51cdd8>
13:16 News from kohagit: Bug 25534: Use the cancelation reasion for the 'X' hold cancelation links <http://git.koha-community.org/[…]d0d867921617d8339>
13:16 News from kohagit: Bug 25534: Add ability to send an email specifying a reason when canceling a hold <http://git.koha-community.org/[…]1225b0d20c84cd360>
13:16 News from kohagit: Bug 25534: Update database <http://git.koha-community.org/[…]5a85fa55cb660a213>
13:20 Joubu @later tell dcook Is 26231 ready for testing?
13:20 huginn Joubu: The operation succeeded.
13:49 wizzyrea joined #koha
13:55 cait Joubu: i will try to catch up later
13:55 I really want to talk someone into testing my patches for the existing installer files before we move them :(
13:55 marcelr cancelation reasion HORRIBLE
13:55 spelling !
13:55 cait CORONA? :)
13:56 marcelr cancellation reason please
13:56 tcohen WTF
13:56 marcelr excuse me
13:56 wahanui marcelr: Jupiter is aligned with Mars.
13:56 cait marcelr: both are valid... i had looked it up sometime
13:57 iwth ll and l
13:57 marcelr reasion ?
13:57 cait yes, that is wrong
13:58 marcelr cait in Koha cancellation wins by far: git grep them both
13:58 consistency ?
13:58 wahanui consistency is boring...
13:58 cait yea good enough for me
13:58 i love consistency... guess i am boring wahnui
13:59 Joubu cait: the de-DE for 20.05?
14:00 koha-jenkins Yippee, build fixed!
14:00 wahanui Congratulations!
14:00 koha-jenkins Project Koha_Master_D11 build #72: FIXED in 44 min: https://jenkins.koha-community[…]ha_Master_D11/72/
14:09 cait Joubu: yes, the 2 patches still in NSO
14:09 not enough German devs and testers...
14:09 kohaputti cait, should bug 26015 be Need SO given the last huge patch is not reviewed yet?
14:10 huginn Bug http://bugs.koha-community.org[…]_bug.cgi?id=26015 enhancement, P5 - low, ---, katrin.fischer, Signed Off , Terminology: staff interface should be used everywhere
14:10 koha-jenkins Project Koha_Master_D9_My8 build #396: STILL UNSTABLE in 52 min: https://jenkins.koha-community[…]aster_D9_My8/396/
14:11 inlibro joined #koha
14:14 koha-jenkins Yippee, build fixed!
14:14 wahanui Congratulations!
14:14 koha-jenkins Project Koha_Master_U16 build #51: FIXED in 58 min: https://jenkins.koha-community[…]ha_Master_U16/51/
14:14 kohaputti cait, forget the question, I updated the status – I tried to sign-off but it didn't apply anymore
14:21 Joubu cait: I can push if you want me too. I test to install in de-DE, if it works I push?
14:26 @later tell oleonard-away Hi Owen, I want to let you know I did something weird on purpose:
14:26 huginn Joubu: The operation succeeded.
14:26 Joubu lol
14:26 that was a /query!
14:31 cait Joubu: i'd be happy if you did that
14:32 kohaputti:  i signed it i think?
14:32 the last one is from david not from me
14:32 i only rebased
14:33 kohaputti cait, hmm it says your name as the author and there is no sign-off, maybe you are talking about different bug/patch?
14:35 koha-jenkins Project Koha_Master_U20 build #78: FAILURE in 1 hr 16 min: https://jenkins.koha-community[…]ha_Master_U20/78/
14:37 kohaputti cait, in similar bug 25630 the patches are from david
14:37 huginn Bug http://bugs.koha-community.org[…]_bug.cgi?id=25630 enhancement, P5 - low, ---, katrin.fischer, Signed Off , More capitalization and terminology fixes for system preferences
14:39 cait probably, sorry
14:39 checking the history
14:39 the second patch was an rm request
14:39 and only string changes
14:40 usually we don't require another sign-off for follow ups in QA that are not too bad
14:40 this doesn't change any logic, so i left it in signed off
14:41 sorry, too many things... and running out, just now to meet for coffee... hopefully it will help :)
14:41 kohaputti cait, ok
14:45 cait left #koha
14:47 koha-jenkins Yippee, build fixed!
14:47 wahanui Congratulations!
14:47 koha-jenkins Project Koha_Master_D9_MDB_Latest build #372: FIXED in 46 min: https://jenkins.koha-community[…]9_MDB_Latest/372/
14:59 Yippee, build fixed!
14:59 wahanui Congratulations!
14:59 koha-jenkins Project Koha_Master_D9 build #1415: FIXED in 49 min: https://jenkins.koha-community[…]a_Master_D9/1415/
15:07 fridolin left #koha
15:09 reiveune bye
15:09 reiveune left #koha
15:11 inlibro joined #koha
15:13 koha-jenkins Project Koha_Master_U18 build #878: STILL UNSTABLE in 59 min: https://jenkins.koha-community[…]a_Master_U18/878/
15:19 lisettelatah joined #koha
15:31 koha-jenkins Yippee, build fixed!
15:31 wahanui Congratulations!
15:31 koha-jenkins Project Koha_Master_D10_Deps build #59: FIXED in 43 min: https://jenkins.koha-community[…]ster_D10_Deps/59/
15:44 Yippee, build fixed!
15:44 wahanui Congratulations!
15:44 koha-jenkins Project Koha_Master_D10 build #333: FIXED in 44 min: https://jenkins.koha-community[…]a_Master_D10/333/
16:12 inlibro joined #koha
16:28 koha-jenkins Project Koha_Master_D10 build #334: SUCCESS in 44 min: https://jenkins.koha-community[…]a_Master_D10/334/
16:38 Yippee, build fixed!
16:38 wahanui Congratulations!
16:38 koha-jenkins Project Koha_Master_U20 build #79: FIXED in 1 hr 17 min: https://jenkins.koha-community[…]ha_Master_U20/79/
17:12 inlibro joined #koha
17:27 Becky joined #koha
17:29 Becky joined #koha
17:35 Becky left #koha
17:59 did joined #koha
18:12 inlibro joined #koha
18:38 AKhaines joined #koha
18:54 GeekRuthie joined #koha
19:05 khall joined #koha
19:12 inlibro joined #koha
19:21 sf_adam joined #koha
19:23 sf_adam I seem to have the following bug: https://bugs.koha-community.or[…]_bug.cgi?id=26018
19:23 huginn Bug 26018: minor, P5 - low, ---, katrin.fischer, Needs Signoff , Not all subfields for the following tags are in the same tab (or marked 'ignored')
19:23 sf_adam which has a solution as follows: Before you apply the patch: - Check the "MARC bibliographic framework test" page - Ideally you should see the "wrong tab" mistakes - Reset your db (reset_all) or drop your db and run the web installer - Verify the page no longer points out any issues
19:23 can someone please explain mor ehow I do these things: Reset your db (reset_all) or drop your db and run the web installer
19:24 tcohen is it me or Koha isn't caching anything on the browser?
19:32 oleonard tcohen is it because the developer tools pane is open?
19:32 tcohen it is, but I expect to see cache hits
19:36 sf_adam any thought on how I Reset my db (reset_all)
19:36 oleonard Is "Disable HTTP Cache (when toolbox is open)" set tcohen?
19:38 tcohen :-D
19:38 * tcohen didn't know
19:38 tcohen thanks oleonard
19:40 * oleonard-away shouts 'You're welcome!' as he rides off into the sunset
19:41 caroline and of course, there's echo "You're welcome! come! come! come!"
19:45 tcohen hahaha
19:55 kathryn joined #koha
20:12 inlibro joined #koha
20:34 alexbuckley joined #koha
20:55 hayley joined #koha
21:12 hayley joined #koha
21:12 inlibro joined #koha
21:39 aleisha joined #koha
22:04 wshealy joined #koha
22:05 wshealy Hi
22:13 inlibro joined #koha
22:14 did joined #koha
22:23 kathryn joined #koha
22:25 wshealy hey
23:01 dcook @later tell Joubu yep 26231 is ready for testing. Must've forgotten to switch its status. I do it manually as git bz often crashes if I try it there...
23:01 huginn dcook: The operation succeeded.
23:13 inlibro joined #koha
23:31 aleisha_ joined #koha

← Previous day | Today | Next day → | Search | Index

koha1