A new request with request id 7109 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is :
Title : Koha-devel Digest, Vol 202, Issue 23
Category :
Description : Send Koha-devel mailing list submissions to
koha-devel@lists.koha-community.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
or, via email, send a message with subject or body 'help' to
koha-devel-request@lists.koha-community.org
You can reach the person managing the list at
koha-devel-owner@lists.koha-community.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Koha-devel digest..."
Today's Topics:
1. Bug 31654 - Hide non-public libraries from
MastheadLibraryPulldown (Thomas Klausner)
2. Merging authority records can corrupt data (Thomas Klausner)
3. Re: koha-create with remote mariadb server (David Schmidt)
4. Re: Merging authority records can corrupt data (Pedro Amorim)
5. Re: Critical error on Koha website (Liz Rea)
----------------------------------------------------------------------
Message: 1
Date: Fri, 30 Sep 2022 13:50:27 +0200
From: Thomas Klausner <domm@plix.at>
To: Koha-devel@lists.koha-community.org
Subject: [Koha-devel] Bug 31654 - Hide non-public libraries from
MastheadLibraryPulldown
Message-ID: <20220930115027.GB1853016@plix.at>
Content-Type: text/plain; charset=utf-8
Hi!
I've just submitted a patch implementing Bug 31654 - Hide non-public libraries from MastheadLibraryPulldown
It's quite simple (two lines in two files), and the sponsor
(Steiermärkische Landesbibliothek) would be happy if the fix makes it
into 22.11. So if there is anything I can do to make that happen, please
advise :-)
Greetings,
domm
--
#!/usr/bin/perl https://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
------------------------------
Message: 2
Date: Fri, 30 Sep 2022 14:19:13 +0200
From: Thomas Klausner <domm@plix.at>
To: Koha-devel@lists.koha-community.org
Subject: [Koha-devel] Merging authority records can corrupt data
Message-ID: <20220930121913.GC1853016@plix.at>
Content-Type: text/plain; charset=utf-8
Hi!
It seems that merging authorities with lots of linked biblios can lead
to data corruption (at least in 21.05):
The merging of the auth record itself seems to work, but the linking of
the biblios from old to new auth record happens inside a normal
synchrone web request. If this requests times out (because there might
be a lot of biblio records to relink), some of the biblios still point
to the old auth, which is already deleted. (At least this seems to be
happening, based on the complaints we got from librarians)
I guess the only fix is to handle authority merging via background jobs
/ job queue.
Is this a known bug? I couldn't find anything about that in bugzilla?
If yes, is there a timeframe when it will be fixed?
If no, I will create a bug (though reproducing it will need some weird
fixtures in the DB..).
In any case, the Steiermärkische Landesbibliothek is keen to get this
working, so I could give fixing it a try. But this will need some
discussion, I assume? As I suppose this will be a bit more work than a
single-line fix in a template, I'd like to have some backing by other
Koha-devs, that this behaviour is indeed a bug, and that using
background jobs is the correct way to fix it.
Greetings,
domm
--
#!/usr/bin/perl https://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
------------------------------
Message: 3
Date: Fri, 30 Sep 2022 15:46:09 +0200
From: "David Schmidt" <mail@davidschmidt.at>
To: koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] koha-create with remote mariadb server
Message-ID: <a989a3bf-7e99-4c94-a4ea-31acbda91067@app.fastmail.com>
Content-Type: text/plain; charset="utf-8"
with the help from koha irc and lots of try&error&code-reading I figured some things out
### on your database server:
apt update && apt install -y mariadb-server
sed -i -e 's/^bind-address\s*=\s*127\.0\.0\.1$/bind-address = */' /etc/mysql/mariadb.conf.d/50-server.cnf
/etc/init.d/mariadb restart
mysql -e "CREATE DATABASE koha_demo;"
mysql -e "CREATE USER 'koha_demo'@'%' IDENTIFIED BY 'kohadbpw';"
mysql -e "GRANT ALL PRIVILEGES on koha_demo.* TO koha_demo;"
mysql -e "FLUSH PRIVILEGES;"
### on your koha server
apt update && apt install -y wget gnupg
wget -q -O- https://debian.koha-community.org/koha/gpg.asc | apt-key add -
echo 'deb http://debian.koha-community.org/koha 22.05 main' | tee /etc/apt/sources.list.d/koha.list
apt update
apt install koha-common -y
a2enmod rewrite
a2enmod cgi
service apache2 restart
mv /etc/mysql/koha-common.cnf /etc/mysql/koha-common.cnf.bak
echo "[client]
host = mariadb
user = koha_demo
password = kohadbpw" > /etc/mysql/koha-common.cnf
sed -i -e 's/^DOMAIN="\.myDNSname\.org"$/DOMAIN=".koha-support.eu"/' /etc/koha/koha-sites.conf
sed -i -e 's/^OPACSUFFIX=""$/OPACSUFFIX="-opac"/' /etc/koha/koha-sites.conf
#instance:username:password:dbname:dbhost
echo "koha-demo:koha_demo:kohadbpw:koha_demo:mariadb" > koha_db_passwdfile.txt
koha-create --passwdfile=koha_db_passwdfile.txt --use-db koha-demo
On Thu, 29 Sep 2022, at 6:47 PM, David Schmidt wrote:
> im trying to create a koha instance configured for a remote mariadb server
>
> https://wiki.koha-community.org/wiki/Debian#Create_a_Koha_instance
>
> > remove /etc/mysql/koha-common.cnf
> > create a new file in its place containing the connection
> information for the server, in the form of a my.cnf file.
>
> what does that mean? the only my.cnf file that I can find on the system is /etc/mysql/my.cnf and that doesnt look right
>
>
> $ koha-create --dbhost 172.23.0.3 --database kohadb --request-db koha-demo
> $ vim koha-demo-db-request.txt
> $ koha-create --dbhost 172.23.0.3 --database kohadb --populate-db koha-demo
> Koha instance is empty, no staff user created.
>
> after that I still see the autogenerated password in /etc/koha/sites/koha-demo/koha-conf.xml and the mariadb database is empty
>
> after reading the koha-create source i have a feeling this --request-db/--populate-db stuff cant possibly work. --populate-db is trying to get the db passwort using getinstancemysqluser() but that function is a wrapper around xmlstarlet and i was just told by `koha-create --request-db` to write the new db password into this txt file.
>
> I will update the wiki after I figured this out
>
> cheers
> david
> _______________________________________________
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : https://www.koha-community.org/
> git : https://git.koha-community.org/
> bugs : https://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220930/79473b20/attachment-0001.htm>
------------------------------
Message: 4
Date: Fri, 30 Sep 2022 14:11:13 +0000
From: Pedro Amorim <pjamorim91@gmail.com>
To: Koha-devel@lists.koha-community.org
Subject: Re: [Koha-devel] Merging authority records can corrupt data
Message-ID:
<CALWP7TLQjE9p2rbc05FqAxnW5afe2-dqEf4xa9nzq6HSM0QHVg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Thomas,
Not sure if this will help but what is the value of the
*AuthorityMergeLimit* sys pref?
I think the default value is 50 and any authority being merged with more
than 50 linked biblios will be processed by the
*misc/migration_tools/merge_authority.pl
<http://merge_authority.pl>* cronjob (which runs daily by default if I'm
not mistaken).
If the problem you're experiencing is indeed related to having lots of
linked biblios, maybe lowering this value (or setting it if empty) might
help?
In the past I reported an issue with subsequent authority merging (that get
queued to be processed by the cronjob):
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22437
But I believe this has been fixed.
On Fri, 30 Sept 2022 at 12:19, Thomas Klausner <domm@plix.at> wrote:
> Hi!
>
> It seems that merging authorities with lots of linked biblios can lead
> to data corruption (at least in 21.05):
>
> The merging of the auth record itself seems to work, but the linking of
> the biblios from old to new auth record happens inside a normal
> synchrone web request. If this requests times out (because there might
> be a lot of biblio records to relink), some of the biblios still point
> to the old auth, which is already deleted. (At least this seems to be
> happening, based on the complaints we got from librarians)
>
> I guess the only fix is to handle authority merging via background jobs
> / job queue.
>
> Is this a known bug? I couldn't find anything about that in bugzilla?
> If yes, is there a timeframe when it will be fixed?
> If no, I will create a bug (though reproducing it will need some weird
> fixtures in the DB..).
>
> In any case, the Steiermärkische Landesbibliothek is keen to get this
> working, so I could give fixing it a try. But this will need some
> discussion, I assume? As I suppose this will be a bit more work than a
> single-line fix in a template, I'd like to have some backing by other
> Koha-devs, that this behaviour is indeed a bug, and that using
> background jobs is the correct way to fix it.
>
> Greetings,
> domm
>
> --
> #!/usr/bin/perl https://domm.plix.at
> for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
> _______________________________________________
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : https://www.koha-community.org/
> git : https://git.koha-community.org/
> bugs : https://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220930/994950ee/attachment-0001.htm>
------------------------------
Message: 5
Date: Fri, 30 Sep 2022 09:32:33 -0500
From: Liz Rea <wizzyrea@gmail.com>
To: Michael Kuhn <mik@adminkuhn.ch>
Cc: Koha <koha@lists.katipo.co.nz>, Koha-devel
<koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] Critical error on Koha website
Message-ID:
<CAD+xdkR5WqqsF6szspT81J935_G8L_-sVw+d8deSRHD4ATQ8bw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi friends,
This was related to an update to Wordpress and the theme we use. Have
sorted out those issues and things are seeming better now, if you'd please
test!
Cheers,
Liz
On Thu, Sep 29, 2022 at 2:51 PM Michael Kuhn <mik@adminkuhn.ch> wrote:
> Hi
>
> When I'm trying to preview or release the current Koha newsletter I'm
> getting the following message:
>
> There has been a critical error on this website.
>
> I'm also getting this message when I try to access older newsletters,
> for example
>
> * https://koha-community.org/koha-community-newsletter-april-2022/
> * https://koha-community.org/koha-community-newsletter-august-2022/
>
> Can someone with the necessary rights and knowledge please remove this
> problem?
>
> Best wishes: Michael
> --
> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
> T 0041 (0)61 261 55 61 · E mik@adminkuhn.ch · W www.adminkuhn.ch
> _______________________________________________
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : https://www.koha-community.org/
> git : https://git.koha-community.org/
> bugs : https://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220930/0450c17f/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/
------------------------------
End of Koha-devel Digest, Vol 202, Issue 23
*******************************************
NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.