← 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