Time  Nick            Message
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: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 tuxayo          Not sure what git choreography would fit the most.
01:24 mtj             hey #koha
01:29 mtj             hi aleisha, still about?
01:41 mtj             ..tuxayo's assumptions in his email are correct :)
01:42 mtj             for a security release, rmaints push their stuff to the security.git repo, rather than the koha.git repo
01:49 mtj             ...after the co-ordinated release has happened, the rmaints can finally update their branch on the koha.git repo
01:51 mtj             so its identical to a regular release, except that rmaints are pushing to a private repo
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 aleisha         should i revert those or just leave them?
02:32 mtj             hmm, i think revert them
02:36 mtj             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 rangi           the tag needs to match the tag on the release
02:38 rangi           so you cant tag the security one, unless you plan to merge the security one back into the main one
02:38 rangi           or that tag is going to be pointing to a commit no one can reach
02:38 rangi           or worse pointing to a commit that isnt actually the one the package was built from
02:40 rangi           this is why we never did it this way
02:41 rangi           we just put the security patches on last, and pushed
02:41 rangi           because this is way way way overcomplicated
02:41 rangi           and error prone
02:43 rangi           if they are urgent enough to need this level of security they should go out in an actual security release
02:43 rangi           not a maintenance release
02:43 rangi           </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 rangi           where the main commits are on the main branch, the security ones are on the security one
02:46 rangi           (email on the 6th of august)
02:46 rangi           is what has been followed, so it can't change now
02:47 rangi           the security branches were for doing a security release, not a combined one
02:47 rangi           thats where this mess is occuring
02:48 mtj             aah right, i hadnt made that distinction
02:54 mtj             so lets follow the plan from the email on the 6th of august
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: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 tuxayo          «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 rangi           you can either merge from your security branch
03:20 rangi           or you can cherry-pick from there
03:20 rangi           back to the main one
03:20 rangi           alternatively you branch from main one, push everything to security branch, push that over the main one
03:21 rangi           which means you have a month of no changes on the branch, then suddenly a whole montsh worth
03:21 rangi           this totally breaks the workflow from where 19.11 cherry-picks from 20.05 etc
03:21 rangi           so basically only security patches on a security branch
03:22 rangi           merge it in for release
03:22 rangi           or, if its an actual security release
03:22 rangi           ie out of cycle, release from security branch, merge it in after
03:22 rangi           because that branch will have the last release + security patches only, which is what a security release should have
03:23 rangi           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 rangi           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 tuxayo          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 rangi           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 rangi           you just push the security patches as you are about to release
03:27 rangi           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/media/r0/download/matrix.org/PpPyecFLgbEbPZBwoJAVesiC/message.txt >
03:34 tuxayo          Oops, draft sent
03:34 rangi           heh
03:35 tuxayo          Here is the clean version
03:35 tuxayo          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 tuxayo          And do the release process on the security branch that had all the commits.
03:35 tuxayo          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 tuxayo          I'm not sure what everyone had I mind about this phrase but it look very diverse ^^
03:35 tuxayo          «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 tuxayo          +1
03:35 tuxayo          Thanks, it's simple to understand in the case of a dedicated out of cycle security release.
03:36 tuxayo          (finished, sorry for the mess)
03:38 tuxayo          «this totally breaks the workflow from where 19.11 cherry-picks from 20.05 etc»
03:38 tuxayo          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 rangi           everything on the normal branch
03:40 rangi           otherwise if i as a user want to look at the logs, i cant
03:40 rangi           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 rangi           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 rangi           and if i want to audit the code of the security release i can (this is an average sysadmin/user)
03:42 rangi           before applying it to my 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 tuxayo          That wasn't the idea of the security release process:
03:54 tuxayo          https://wiki.koha-community.org/wiki/Release_maintenance#Coordinated_security_releases
03:54 tuxayo          «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 tuxayo          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 rangi           but that is for a full on, we have a zero day, need to do a security release now workflow
03:55 rangi           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 aleisha         tuxayo: that was part of the problem, is every time i asked a question i was referred back to the wiki
03:56 aleisha         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 tuxayo          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:10 tuxayo          rangi: «it also means that no one can check the security fixes»
04:10 tuxayo          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:15 aleisha         i've just sent an email hopefully clarifying everything!
05:31 mtj             thanks aleisha, still about?
05:51 kohaputti       mtj, hey! :) Would you have time to comment on https://bugs.koha-community.org/bugzilla3/show_bug.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: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:13 mtj             hi kohaputti, i added the patch to the bug
06:15 mtj             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 kohaputti       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 mtj             ... 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        hello
06:56 alex_a          Bonjour
06:59 cait1           good morning #koha!
07:06 * magnuse       waves
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 cait1           but that's maybe a bit much
07:23 cait1           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 cait1           you can have your own llink structure there
07:29 cait1           so you can point it to local fiels that are named with the marc fields or similar
07:29 cait1           by default the links go to LOC
07:30 cait1           kohaputti++ thx :)
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:27 kohaputti       I didn't find any appropriate existing page other than https://wiki.koha-community.org/wiki/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 tuxayo          https://wiki.koha-community.org/wiki/Building_Debian_Packages_-_The_Easy_Way
08:29 tuxayo          https://wiki.koha-community.org/wiki/Building_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 kohaputti       or no patch at all
08:31 tuxayo          ok, very different ^^
08:37 Joubu           kohaputti: cpanfile (which replaced C4/Installer/PerlDependencies.pm)
08:38 Joubu           and debian/control
08:39 Joubu           no, debian/control is automatically generated by the package manager (see 17084)
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 tuxayo          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 Joubu           there is nothing to discuss, it's an established workflow
08:47 Joubu           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: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/bugzilla3/show_bug.cgi?id=11175 enhancement, P5 - low, ---, joonas.kylmala, Needs Signoff , Show the parent record's component parts in the detailed views
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/bugzilla3/show_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 Joubu           and so I don't see the warn
10:18 Joubu           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 kohaputti       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 Joubu           wrong copy paste
10:20 kohaputti       Joubu, the files are created only if there are warnings
10:21 kohaputti       ah, you said you added that too
10:21 kohaputti       hmm
10:22 Joubu           kohaputti: must be me, I am double checking the changes I made
10:22 Joubu           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 Joubu           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 Joubu           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::Log4perl#Log-Layouts
10:28 kohaputti       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 kohaputti       just have to make sure %l and %n are valid also in this context
10:30 Joubu           yes, agreed
10:33 kohaputti       Joubu, did you install the new debian package dependency?
10:33 kohaputti       "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 Joubu           we should not have split into 3 files, it should be a separate bug report
10:55 kohaputti       adding log4perl?
10:55 kohaputti       or what should be separate
10:57 kohaputti       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 Joubu           kohaputti: I let a comment
10:59 Joubu           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 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 Joubu           kohaputti: it's not what I am seeing
11:01 kohaputti       hmm, that's how it worked for me
11:02 kohaputti       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 kohaputti       I will retry
11:04 tuxayo          All the tests passed in the 19.05.x, I can move on with the release :D
11:07 cait            kohaputti: i try to avoid sign-offs... they get stuck in QA :(
11:08 cait            kidclamp++
11:08 kohaputti       Joubu, I think I was able to reproduce the issue now, let me double check still
11:10 marcelr         hi #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 kohaputti       s/install/upgrade/
11:33 eythian         hi
11:33 wahanui         que tal, eythian
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: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.
12:07 * cait          waves
12:08 cait            marcelr: eythian nice to see you around :)
12:09 tuxayo          o/
12:11 cait            you too tuxayo ;)
12:19 eythian         marcelr: I'm always around :)
12:20 tcohen          morning
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 tcohen          he
12:43 tcohen          I rewrote it and am happy with the results
12:43 marcelr         no way
12:44 marcelr         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 cait            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/bugzilla3/show_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 tcohen          you might be running an instance-specific one I think
12:56 tcohen          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/bugzilla3/show_bug.cgi?id=16357 normal, P3, ---, dcook, In Discussion , Plack error logs are not time stamped
12:57 tcohen          somehow
12:57 tcohen          not lately
12:57 Joubu           from this "morning" :)
12:58 Joubu           We have something in postinst to keep log4perl in sync, but I was wondering about plack.psgi then
12:58 Joubu           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 kohaputti       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 Joubu           /$/?/
13:00 tcohen          I prefer it to explode with meaningful error messages
13:00 Joubu           me too
13:00 Joubu           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 Joubu           the problem here is that we don't longer have something on the about page
13:05 Joubu           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:16 huginn          News from kohagit: Bug 26265: add a plan for tests <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=88f64019536887c094b0178007d3583a048917f2>
13:16 huginn          News from kohagit: Bug 25534: DBIC schema changes <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=352bc794d4bda2d39bdc0c9718f9cf3b31c5b070>
13:16 huginn          News from kohagit: Bug 25534: DBRev 20.06.00.029 <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=0d64db87d7764855dcb1227eeed46002a02220fc>
13:16 huginn          News from kohagit: Bug 25958: DBRev 20.06.00.028 <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=385a4cba44c5ac56d334d5ac4f8acd69d17375e9>
13:16 huginn          News from kohagit: Bug 25958: (QA follow-up) Implement filter in database query instead of in loop <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=66382458dc46356818473935e8d5546f13f05645>
13:16 huginn          News from kohagit: Bug 25534: (QA follow-up) Use modal for cancel links, hide reason unless priority... <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=1d19dccbb22b64690a7212708ef9e122276c6049>
13:16 huginn          News from kohagit: Bug 25534: (QA follow-up) Update Koha::Hold::cancel POD <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=94df210c415dfac39cb778b6b400449461e04b41>
13:16 huginn          News from kohagit: Bug 25534: Use build_sample_item in tests <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=d574597473180006cf7e71679bd2f827245e2de2>
13:16 huginn          News from kohagit: Bug 25534: (QA follow-up) Add sample notices for translators <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=0a7e3a264e0b3d73cbec51e34bbd9d7b8354c315>
13:16 huginn          News from kohagit: Bug 25534: (QA follow-up) Add default values for new AV category <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=ab1d71c53daafb7bd35f84101cdad5402872e0ac>
13:16 huginn          News from kohagit: Bug 25534: (QA follow-up) Add AV category <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=57bbb2861f0c0e2c8eca67d40ec07f46b5a476c8>
13:16 huginn          News from kohagit: Bug 25534: (QA follow-up) Add label to reason pulldown <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=563328d3cc37eb64d0eae9c268aa8312f7680e3d>
13:16 huginn          News from kohagit: Bug 25534: (QA follow-up) Add sample notice <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=a6042768ac87794b58b858dab5b52c3252b70cdf>
13:16 huginn          News from kohagit: Bug 25534: (QA follow-up) Unit tests <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=8afa136aee4a07a99d5ef0b46472391c0589f82a>
13:16 huginn          News from kohagit: Bug 25534: (QA follow-up) Add missing TT filters <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=61e00246803821dc2680ff740d7702fbef17bb60>
13:16 huginn          News from kohagit: Bug 25662: (follow-up) Add tests for the wrong patron_id added behaviour <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=deee485a24df0734cace673dc519f15d41a5b575>
13:16 huginn          News from kohagit: Bug 25662: Make the route for holds restpect maxreserves <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=69bdc94cd4f420094c5706fb2bfc472ba24a5054>
13:16 huginn          News from kohagit: Bug 25662: Regression tests <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=9a63cf6dec55c67491e5a2807fe74f9083167ccc>
13:16 huginn          News from kohagit: Bug 25534: Add reason to pendingreserves.pl <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=0b3f22710a45ccfcde8668494e2073ec8d51cdd8>
13:16 huginn          News from kohagit: Bug 25534: Use the cancelation reasion for the 'X' hold cancelation links <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=27c80187ba55e801787a591d0d867921617d8339>
13:16 huginn          News from kohagit: Bug 25534: Add ability to send an email specifying a reason when canceling a hold <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=af0d71b7479432aeaf65dd61225b0d20c84cd360>
13:16 huginn          News from kohagit: Bug 25534: Update database <http://git.koha-community.org/gitweb/?p=koha.git;a=commitdiff;h=f840342c0a5eb39dfe7aa045a85fa55cb660a213>
13:20 Joubu           @later tell dcook Is 26231 ready for testing?
13:20 huginn          Joubu: The operation succeeded.
13:55 cait            Joubu: i will try to catch up later
13:55 cait            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 marcelr         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 cait            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 marcelr         consistency ?
13:58 wahanui         consistency is boring...
13:58 cait            yea good enough for me
13:58 cait            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.org/job/Koha_Master_D11/72/
14:09 cait            Joubu: yes, the 2 patches still in NSO
14:09 cait            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/bugzilla3/show_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.org/job/Koha_Master_D9_My8/396/
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.org/job/Koha_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 Joubu           @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 Joubu           that was a /query!
14:31 cait            Joubu: i'd be happy if you did that
14:32 cait            kohaputti:  i signed it i think?
14:32 cait            the last one is from david not from me
14:32 cait            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.org/job/Koha_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/bugzilla3/show_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 cait            checking the history
14:39 cait            the second patch was an rm request
14:39 cait            and only string changes
14:40 cait            usually we don't require another sign-off for follow ups in QA that are not too bad
14:40 cait            this doesn't change any logic, so i left it in signed off
14:41 cait            sorry, too many things... and running out, just now to meet for coffee... hopefully it will help :)
14:41 kohaputti       cait, ok
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.org/job/Koha_Master_D9_MDB_Latest/372/
14:59 koha-jenkins    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.org/job/Koha_Master_D9/1415/
15:09 reiveune        bye
15:13 koha-jenkins    Project Koha_Master_U18 build #878: STILL UNSTABLE in 59 min: https://jenkins.koha-community.org/job/Koha_Master_U18/878/
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.org/job/Koha_Master_D10_Deps/59/
15:44 koha-jenkins    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.org/job/Koha_Master_D10/333/
16:28 koha-jenkins    Project Koha_Master_D10 build #334: SUCCESS in 44 min: https://jenkins.koha-community.org/job/Koha_Master_D10/334/
16:38 koha-jenkins    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.org/job/Koha_Master_U20/79/
19:23 sf_adam         I seem to have the following bug: https://bugs.koha-community.org/bugzilla3/show_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 sf_adam         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
22:05 wshealy         Hi
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.