[Koha-devel] Memory footprint of Koha processes

2023-10-23 Thread Philippe Blouin via Koha-devel
Howdy! I'm trying to run a server with MANY koha instances (for educational purposes), but although the usage is very small, the resources required just make everything explode. background_jobs_worker.pl for instance uses 170M per instance, and plack uses 200M without anything being loaded.

Re: [Koha-devel] Memory footprint of Koha processes

2023-10-23 Thread Philippe Blouin via Koha-devel
PS this is 22.05.06 Philippe Blouin, Directeur de la technologie Tél.  : (833) 465-4276, poste 230 philippe.blo...@inlibro.com inLibro | pour esprit libre | www.inLibro.com On 2023-10-23 15:57, Philippe Blouin wrote: Howdy! I'm trying to run a server with MANY koha i

Re: [Koha-devel] Memory footprint of Koha processes

2023-10-24 Thread Philippe Blouin via Koha-devel
Blouin, Directeur de la technologie Tél.  : (833) 465-4276, poste 230 philippe.blo...@inlibro.com inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com> On 2023-10-24 03:25, Thomas Klausner via Koha-devel wrote: Hi! On Mon, Oct 23, 2023 at 03:57:16PM -0

Re: [Koha-devel] Elasticsearch sans Zebra

2024-03-25 Thread Philippe Blouin via Koha-devel
Hi! We have a scenario (albeit an exception) where both are used, due to the limitation of ES's z3950. So we fill zebraqueue uselessly in 199 Koha, but really really need it in 1. Logo inLibro Philippe Blouin Directeur de la technologie T 833-INLIBRO (465-4276) ,

Re: [Koha-devel] Elasticsearch sans Zebra

2024-03-27 Thread Philippe Blouin via Koha-devel
Well, not really.  Hammat asked about limitations on Feb 28 on this very list, because attributes are not well handled. Logo inLibro Philippe Blouin Directeur de la technologie T 833-INLIBRO (465-4276) , poste 230 C philippe.blo...@inlibro.com www.inLibro.com

Re: [Koha-devel] XZ Utils backdoor for Linux

2024-04-04 Thread Philippe Blouin via Koha-devel
So to gain trust even faster and then be able to self-QAing backdoors ?  :-P Very interesting article, thanks!  And hats off to the Wiki contributor who wrote that article so quickly. Logo inLibro Philippe Blouin Directeur de la technologie T 833-INLIBRO (465-4276

Re: [Koha-devel] Finding invalid XML characters in Koha data via SQL

2024-04-12 Thread Philippe Blouin via Koha-devel
Something else to add to search_for_data_inconsistencies.pl ? I like perl-based solution, and I appreciate centralized ones, even though I suppose what you're testing is not an "inconsistency". Logo inLibro Philippe Blouin Directeur de la technologie T 833-INLIBRO

Re: [Koha-devel] [Koha] {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Duplicate entry '0' for key 'PRIMARY'

2024-07-10 Thread Philippe Blouin via Koha-devel
updatedatabase.pl line 20736 It's the conversion from issuingrules to circulation_rules. What's the state of your DB right now?  Has it started to convert?  How many circ rules already created?  I suspect it's 0, but it's worth asking. Considering the id is an autoincrement, and it not moved

Re: [Koha-devel] [Koha] {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Duplicate entry '0' for key 'PRIMARY'

2024-07-10 Thread Philippe Blouin via Koha-devel
Ok, let's cheat.  You have very few rules, and most of the info has been moved already.  So just comment the lines 20734 to 20746 and run updatedatabase.pl again. OR modify the version to move ahead. update systempreferences set value = '19.1200018' where variable = 'version'; Then you can

Re: [Koha-devel] [Koha] {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Duplicate entry '0' for key 'PRIMARY'

2024-07-10 Thread Philippe Blouin via Koha-devel
The problem is deeper, then.  issuingrule didn't have unique id, so the problem is not with the starting db.  It seems to be when creating the new entries, autoincrement doesn't seem to do its job ? I don't think there's any integrity problem with your old database, more with the environment,

Re: [Koha-devel] [Koha] {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Duplicate entry '0' for key 'PRIMARY'

2024-07-10 Thread Philippe Blouin via Koha-devel
If you're a bit adventurous (and have some time, which you're probably thinking you've burnt enough already): try to update to 20.05, for example, using 20.05 code. So you reset your installation (you have saved your DB, right?), then instead of installing a 24.05, you install an older version

Re: [Koha-devel] [Koha] {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Duplicate entry '0' for key 'PRIMARY'

2024-07-10 Thread Philippe Blouin via Koha-devel
If you went with an existing 23.11 and tried to overwrite the database with you 19.05 one, it's possible it got conflicts since it drop-and-add in the order in the file and dependencies might break.  Always easier to just drop the old database and load the "new" one in an empty space. Then you

Re: [Koha-devel] Error on make

2025-05-07 Thread Philippe Blouin via Koha-devel
#x27;: Permission denied cp: cannot create regular file 'blib/INTRANET_TMPL_DIR/prog/js/vue/dist/erm.js.map': Permission denied cp: cannot create regular file 'blib/INTRANET_TMPL_DIR/prog/js/vue/dist/erm.js': Permission denied cp: cannot create regular file 'blib/INT

[Koha-devel] Upgrading 17.12.00.016 failed constraint

2025-05-12 Thread Philippe Blouin via Koha-devel
Sunny day all! First time I have this problem: I'm trying to upgrade a 17.05 to 24.11, but it keeps failing on constraints Upgrade to 17.12.00.015 done (Bug 20144 - Adapt DB structure to work with new SQL modes) {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Cannot change column 'type':

[Koha-devel] Error on make

2025-05-06 Thread Philippe Blouin via Koha-devel
Hi! Unexpected issue with our dev installs: when doing "make" (after the perl Makefile.PL, without errors), I now get make: *** No rule to make target 'api/v1/swagger/swagger_bundle.json', needed by 'pm_to_blib'. Stop. on master.  First time I try in 2025. I see two possibilities: I need t

Re: [Koha-devel] Upgrading 17.12.00.016 failed constraint

2025-05-15 Thread Philippe Blouin via Koha-devel
rankly I'm at a loss.  I'd hate to say 'just drop all the foreign keys and re-create them after the update.'  That seems like a lot of work; there should be an easier way to get this to go. On Mon, May 12, 2025 at 8:16 AM Philippe Blouin via Koha-devel wrote: