From kohanews at gmail.com Wed Jan 3 03:00:14 2018 From: kohanews at gmail.com (kohanews) Date: Tue, 2 Jan 2018 18:00:14 -0800 Subject: [Koha-devel] Koha Community Newsletter: December 2017 Message-ID: <65848084-ee45-f42a-ae3d-abfa21a0b3c5@gmail.com> Fellow Koha users: The Koha Community Newsletter for December 2017 is here: https://koha-community.org/koha-community-newsletter-december-2017/ Many thanks to the folks who submitted articles and news to this month's newsletter. Please feel free to email me with any corrections or suggestions. Thanks! -- Chad Roseburg Editor, Koha Community Newsletter -------------- next part -------------- An HTML attachment was scrubbed... URL: From fridolin.somers at biblibre.com Thu Jan 4 10:06:48 2018 From: fridolin.somers at biblibre.com (Fridolin SOMERS) Date: Thu, 4 Jan 2018 10:06:48 +0100 Subject: [Koha-devel] Koha 17.05.07 release Message-ID: The Koha community is proud to announce the release of Koha 17.05.07. This is a maintenance release. It was a bit late because of vacations. The full release notes are available at https://koha-community.org/koha-17-05-07-release/ Regards, -- Fridolin SOMERS BibLibre - software and system maintainer From jonathan.druart at bugs.koha-community.org Tue Jan 9 16:27:37 2018 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Tue, 09 Jan 2018 15:27:37 +0000 Subject: [Koha-devel] Move C4::Members to Koha::Patrons - another big step Message-ID: Hi all, I have moved out of C4::Members the following subroutines: - GetMemberAccountRecords - GetMemberAccountBalance - Check_userid - Generate_Userid - GetPendingIssues - GetOverduesForPatron - patronflags See the remote branch https://github.com/joubu/Koha/tree/clean_c4_members There is a bunch of ~35 commits but do not be scared, they are all small and I wrote them to make them easy to read/review (well, at least it is what I think). Most of these subroutines were ugly and impacted performances (too many useless fetches from the DB). This whole stack will be hard to rebase and maintain, so it would be great to get it in soon. Several things can appear ugly or not perfect, but keep in mind that we are moving, improving and refactoring our code. The test coverage is better and this is just a step before the next one. I really want to start to take care of the very ugly code, but for now we need keep moving. C4::Members is almost dead and we are going to manipulate Koha::Patrons everywhere, which will ease the readability, maintenance and write of new improvements. Let me know if you have any questions. Note that patronflags is not completely removed as I need help to remove it from C4::SIP Cheers, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at bywatersolutions.com Tue Jan 9 16:01:42 2018 From: nick at bywatersolutions.com (Nick Clemens) Date: Tue, 09 Jan 2018 15:01:42 +0000 Subject: [Koha-devel] Meeting Reminder: General and Dev Meeting - 10 January 2018, 14:00 UTC Message-ID: Hi All, Tomorrow we have both meetings scheduled for the same time, so we will run General followed by Dev. The agendas are short so we should be able to cover both. As always, please add anything you wish to discuss to the agendas: https://wiki.koha-community.org/wiki/General_IRC_meeting_10_January_2018 https://wiki.koha-community.org/wiki/Development_IRC_meeting_10_January_2018 Hope to see you all there :-) Nick (kidclamp) -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.poulain at biblibre.com Wed Jan 10 13:52:16 2018 From: paul.poulain at biblibre.com (Paul Poulain) Date: Wed, 10 Jan 2018 13:52:16 +0100 Subject: [Koha-devel] Hackfest in Marseille, registrations open ! Message-ID: <084bc359-a1a6-3b9b-4031-55af95ba7116@biblibre.com> Hello everyone, As already announced, the next Koha hackfest in Marseille will be in March, 12th-16th. Registrations are open !!! Should I explain what is the hackfest ? OK, for newbies, I explain. That's a week for anyone interested in being involved into Koha. About 50 persons, librarians and developers, from France and other countries, meet to: * meet * test * document * translate * patch * talk * share * show * try * miss ... and ... retry * discuss how to conquer the world (at least libraries...) * eat and drink (OK, drink, it's after day-work. And it's not mandatory) The FAQ: *Q= what are the conditions to come ?* A= none, except wanting to contribute to Koha *Q= What is the cost ?* A= it's free (but BibLibre does not pay for traveling fees, hotel, or food) *Q= where does it take place ?* A= Marseille, 108 rue Breteuil, in BibLibre office. We provide coffee, desk, chairs, internet, video-projectors and cookies (many people come with their local candies) *Q= can I come only for a few days ?* A= yes, but at least 2 days, in just one day, no time do contribute anything. *Q= I need an official letter* A= Just drop me an email, I'll send one *Q= I have no laptop* A= mmmm.... tricky... we don't have any spare laptop, and it's hard to contribute without laptop... *Q= how to register ?* A= easy : drop me an email *Q= What about hotel, transportation,...* A= You'll be added to a Google doc when you register. *Q= I've heard about a cheese lunch, can you explain ?* A= lunches are organized by BibLibre, in our office (there's no restaurant large enough in the area), and each lunch has it's own theme. The legendary "cheese lunch" includes 30+ different french cheese, in a huge buffet (with some salads...). So you'll discover a part of French gastronomy. This year, it will be tuesday 13th (I've been asked a few times: "when is the cheese lunch, I can't be here the whole week, so I want to be here for the cheese") *Q= I'm veggie, can you take care of me ?* A= yes, for sure. Just tell me when you register *Q= I'm vegan, can you take care of me ?* A= sorry, but no, too complex. You'll be on your own. But you can eat with us, welcome. -- Paul Poulain, Associ?-g?rant / co-owner BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Open Source software and services for libraries -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: From nicolas.legrand at bulac.fr Wed Jan 10 17:29:45 2018 From: nicolas.legrand at bulac.fr (Nicolas Legrand) Date: Wed, 10 Jan 2018 17:29:45 +0100 Subject: [Koha-devel] Hackfest in Marseille, registrations open ! In-Reply-To: <084bc359-a1a6-3b9b-4031-55af95ba7116@biblibre.com> References: <084bc359-a1a6-3b9b-4031-55af95ba7116@biblibre.com> Message-ID: 2018-01-10 13:52 GMT+01:00 Paul Poulain : [...] > *Q= I'm vegan, can you take care of me ?* > A= sorry, but no, too complex. You'll be on your own. But you can eat with > us, welcome. > If you happen to be vegan and ask yourself where to eat, here are a list of vegan friendly restaurants in Marseilles : https://vegoresto.fr/?s=13000 There is also a very good falafel restaurant near the old port : https://www.yelp.com/biz/au-falafel-marseille It is also easier and easier to find vegan food in supermarket in France, but if you're coming from Berlin, New-York or Tel-Aviv, you'll think we're still dwelling in the dark ages ;). Note that it's not possible to cook at Biblibre, there is just one or two microwave. As a french vegan attending the hackfest, I'll be happy to help any other vegan looking for good food ! Yours, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.legrand at bulac.fr Thu Jan 11 10:57:27 2018 From: nicolas.legrand at bulac.fr (Nicolas Legrand) Date: Thu, 11 Jan 2018 10:57:27 +0100 Subject: [Koha-devel] Koha and Elastic Search used in production ? In-Reply-To: References: <4737400f-0476-7c76-eca9-b79344abe3f8@biblibre.com> Message-ID: At the BULAC we plan to install ES in production this year. ES improves greatly our searches with some languages, in particular Chinese, Urdu and Farsi and also searches with transliteration. We plan to test, sign and chat about ES at the next hackfest. 2017-12-14 22:52 GMT+01:00 Brendan Gallagher : > Our plan is that Nick is working on getting ES as stable as possible. He > has invested many days in the past months and will continue to have > different days to work on ES in the coming months. There are a number of > ES bugs out there that needs testing and sign off. > > Our goal is that by 18.05 this will be a viable option for use in > production. If you have further questions please don't hesitate to ask > Nick. > > -Brendan > > > > On Wed, Dec 13, 2017 at 5:56 AM, Paul Poulain > wrote: > >> Hello all, >> >> Is there someone using Koha with ES in production ? >> >> bywater, PTFS-E, Catalyst-NZ, Theke, or any other support company, what's >> your plan ? >> >> BibLibre is planning to invest some effort to work on Koha-ES with >> UNIMARC in the next months, if there are things to share, we would be more >> than happy ! >> >> -- >> Paul Poulain, Associ?-g?rant / co-owner >> BibLibre, Services en logiciels libres pour les biblioth?ques >> BibLibre, Open Source software and services for libraries >> >> _______________________________________________ >> Koha-devel mailing list >> Koha-devel at lists.koha-community.org >> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >> website : http://www.koha-community.org/ >> git : http://git.koha-community.org/ >> bugs : http://bugs.koha-community.org/ > > > > > -- > ------------------------------------------------------------ > --------------------------------------------------- > Brendan A. Gallagher > ByWater Solutions > CEO > > Support and Consulting for Open Source Software > Installation, Data Migration, Training, Customization, Hosting > and Complete Support Packages > Office: Portland, OR - Office: Redding, CT > Phone # (888) 900-8944 > http://bywatersolutions.com > info at bywatersolutions.com > > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- *Nicolas Legrand* Administration technique et d?veloppements du syst?me de gestion de la biblioth?que [image: Logo BULAC] Biblioth?que universitaire des langues et civilisations 65 rue des Grands Moulins F-75013 PARIS T +33 1 81 69 *18 22* www.bulac.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From kohanews at gmail.com Wed Jan 17 02:24:33 2018 From: kohanews at gmail.com (kohanews) Date: Tue, 16 Jan 2018 17:24:33 -0800 Subject: [Koha-devel] Call for News: January 2017 Newsletter Message-ID: <2734f429-61ad-6982-99a5-6c774cffd034@gmail.com> I'm collecting news for the January newsletter. Send anything noteworthy to: k o h a news AT gmail dot com News criteria: --------------------------- ** For events **: ?? - Please include dates for past events. If I can't find dates I may not add it. ?? - Announcements for future events with dates T.B.A. are fine ...Eg., Kohacon ?? - For past events , **** one month back is the cut-off? ****. * News items can be of any length. * Images are fine * Anything and everything Koha. * Submit by the 26th of the month. If you are working on an interesting project or development related to Koha, please let me know and I'll include it in the development section. Thank you! -- Chad Roseburg Editor, Koha Community Newsletter From julian.maurice at biblibre.com Wed Jan 17 11:14:15 2018 From: julian.maurice at biblibre.com (Julian Maurice) Date: Wed, 17 Jan 2018 11:14:15 +0100 Subject: [Koha-devel] git-bz: avoid storing unencrypted passwords in gitconfig Message-ID: <3f60e9b8-473e-1a8c-3c20-ef538aa8696e@biblibre.com> Hi all, I recently shared an LXD container containing my Koha dev environment, and of course I forgot to remove my Bugzilla credentials from the git config... I immediately changed it, but for that not to happen again I searched for a way to not have to store unencrypted passwords for git-bz. The result is here https://github.com/jajm/git-bz/tree/git-credential It uses git-credential, so you can theoretically use any password manager you want, as long as you can write a git-credential helper for it (I use the builtin 'cache' helper, which stores passwords in memory) I thought it might interest some people here. For more information, see the commit message at https://github.com/jajm/git-bz/commit/efb06d8fe3033a83772d0294ab5f67c7f51eaf57 -- Julian Maurice BibLibre From tomascohen at gmail.com Wed Jan 17 11:40:28 2018 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Wed, 17 Jan 2018 10:40:28 +0000 Subject: [Koha-devel] git-bz: avoid storing unencrypted passwords in gitconfig In-Reply-To: <3f60e9b8-473e-1a8c-3c20-ef538aa8696e@biblibre.com> References: <3f60e9b8-473e-1a8c-3c20-ef538aa8696e@biblibre.com> Message-ID: Awesome! El mi?., 17 de ene. de 2018 7:14 a. m., Julian Maurice < julian.maurice at biblibre.com> escribi?: > Hi all, > > I recently shared an LXD container containing my Koha dev environment, > and of course I forgot to remove my Bugzilla credentials from the git > config... > I immediately changed it, but for that not to happen again I searched > for a way to not have to store unencrypted passwords for git-bz. > > The result is here https://github.com/jajm/git-bz/tree/git-credential > > It uses git-credential, so you can theoretically use any password > manager you want, as long as you can write a git-credential helper for > it (I use the builtin 'cache' helper, which stores passwords in memory) > > I thought it might interest some people here. > > For more information, see the commit message at > > https://github.com/jajm/git-bz/commit/efb06d8fe3033a83772d0294ab5f67c7f51eaf57 > > -- > Julian Maurice > BibLibre > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Tom?s Cohen Arazi Theke Solutions (https://theke.io ) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From barton at bywatersolutions.com Wed Jan 17 19:46:29 2018 From: barton at bywatersolutions.com (Barton Chittenden) Date: Wed, 17 Jan 2018 13:46:29 -0500 Subject: [Koha-devel] Clarification on build_browser_and_cloud.pl Message-ID: The documentation for misc/cronjobs/build_browser_and_cloud.pl States > *Important* > This preference and cron job should only be used on French systems. (see https://koha-community.org/manual/18.05/en/html/16_cron_jobs.html?highlight=cronjobs#authorities-browser ) The associated OpacBrowser syspref says: Important > > This preference only applies to installations using UNIMARC at this time. ... but the script itself seems to use MARC::File::USMARC exclusively: 13 use C4::Koha; 14 use C4::Context; 15 use C4::Biblio; 16 use Date::Calc; 17 use Time::HiRes qw(gettimeofday); 18 use ZOOM; 19 *use MARC::File::USMARC;* 20 use Getopt::Long; 21 use C4::Log; (see http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=misc/cronjobs/build_browser_and_cloud.pl;h=d5e0d1a8f5ab96ec10a38ffe2070de8132cac5f1;hb=HEAD ) The subroutine dewey_french obviously isn't translatable (I've filed bug Bug 20007 - build_browser_and_cloud.pl contains hard-coded text in French for thatt 173 sub dewey_french { 174 return { 175 "0" => "G?n?ralit?s (Ouvrages g?n?raux (encyclop?dies, bibliographies, etc.) et informatique)", 176 "00" => "Savoir et communication", 177 "001.42" => "Collecte, agencement, analyse des donn?es", 178 "003" => "Syst?mique, syst?mes", 179 "003.1" => "Identification de syst?me", 180 "003.2" => "Pr?visions. Futurologie", ... The French text seems to be at cross purposes with MARC::File::USMARC, because French catalogers would probably use UNIMARC; at the same time the use of USMARC contradicts the documentation. Ideally, I'd to get the I18N *and* the marc flavor fixed so that everyone can use this, and I'd like to file bug reports that accurately show what needs to be fixed. Any clarification is welcome. Thanks, --Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From liz at catalyst.net.nz Wed Jan 17 21:30:05 2018 From: liz at catalyst.net.nz (Liz Rea) Date: Thu, 18 Jan 2018 09:30:05 +1300 Subject: [Koha-devel] git-bz: avoid storing unencrypted passwords in gitconfig In-Reply-To: <3f60e9b8-473e-1a8c-3c20-ef538aa8696e@biblibre.com> References: <3f60e9b8-473e-1a8c-3c20-ef538aa8696e@biblibre.com> Message-ID: <80d42bb4-4ca7-1346-e0c5-6c62c77a9ec9@catalyst.net.nz> Deep approval, nice! Liz On 17/01/18 23:14, Julian Maurice wrote: > Hi all, > > I recently shared an LXD container containing my Koha dev environment, > and of course I forgot to remove my Bugzilla credentials from the git > config... > I immediately changed it, but for that not to happen again I searched > for a way to not have to store unencrypted passwords for git-bz. > > The result is here https://github.com/jajm/git-bz/tree/git-credential > > It uses git-credential, so you can theoretically use any password > manager you want, as long as you can write a git-credential helper for > it (I use the builtin 'cache' helper, which stores passwords in memory) > > I thought it might interest some people here. > > For more information, see the commit message at > https://github.com/jajm/git-bz/commit/efb06d8fe3033a83772d0294ab5f67c7f51eaf57 > -- -- Liz Rea Catalyst.Net Limited Level 6, Catalyst House, 150 Willis Street, Wellington. P.O Box 11053, Manners Street, Wellington 6142 04 803 2265 GPG: B149 A443 6B01 7386 C2C7 F481 B6c2 A49D 3726 38B7 From dcook at prosentient.com.au Thu Jan 18 02:14:44 2018 From: dcook at prosentient.com.au (David Cook) Date: Thu, 18 Jan 2018 12:14:44 +1100 Subject: [Koha-devel] git-bz: avoid storing unencrypted passwords in gitconfig In-Reply-To: <3f60e9b8-473e-1a8c-3c20-ef538aa8696e@biblibre.com> References: <3f60e9b8-473e-1a8c-3c20-ef538aa8696e@biblibre.com> Message-ID: <02e501d38ff9$b97975d0$2c6c6170$@prosentient.com.au> This issue has annoyed me for years, so this sounds pretty cool! I don't love the "cache" and "store" options... but it looks like there might be an alternative using libsecret or the gnome keyring. These alternatives can be found in separate packages or built from source it seems. On OpenSUSE, I just installed " git-credential-gnome-keyring". On Arch, they use libsecret: https://wiki.archlinux.org/index.php/GNOME/Keyring#Git_integration. It looks like the gnome keyring one is deprecated (https://stackoverflow.com/questions/36585496/error-when-using-git-credentia l-helper-with-gnome-keyring-as-sudo), so libsecret is probably the way to go. I've tried using /usr/lib/git/git-credential-gnome-keyring, but it doesn't seem to be working. Admittedly I'm just using a SSH session rather than a GUI session. I launched DBUS so I don't get errors but it's not saving credentials using "git credential approve". The "cache" option worked well though. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: koha-devel-bounces at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Julian Maurice Sent: Wednesday, 17 January 2018 9:14 PM To: koha-devel at lists.koha-community.org Subject: [Koha-devel] git-bz: avoid storing unencrypted passwords in gitconfig Hi all, I recently shared an LXD container containing my Koha dev environment, and of course I forgot to remove my Bugzilla credentials from the git config... I immediately changed it, but for that not to happen again I searched for a way to not have to store unencrypted passwords for git-bz. The result is here https://github.com/jajm/git-bz/tree/git-credential It uses git-credential, so you can theoretically use any password manager you want, as long as you can write a git-credential helper for it (I use the builtin 'cache' helper, which stores passwords in memory) I thought it might interest some people here. For more information, see the commit message at https://github.com/jajm/git-bz/commit/efb06d8fe3033a83772d0294ab5f67c7f51eaf 57 -- Julian Maurice BibLibre _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ From chris at bigballofwax.co.nz Thu Jan 18 04:45:18 2018 From: chris at bigballofwax.co.nz (Chris Cormack) Date: Thu, 18 Jan 2018 16:45:18 +1300 Subject: [Koha-devel] Outage for bugs.koha-community.org : Fwd: Linode Support Ticket 9818790 - Critical Maintenance for CPU Vulnerabilities (Meltdown) Message-ID: It looks like my linode which hosts bugs.koha-community.org and the dashboard and few other sites will be down for maintenance at 2018-01-19 9:00:00 AM UTC Chris ---------- Forwarded message ---------- From: Date: 18 January 2018 at 16:39 Subject: Linode Support Ticket 9818790 - Critical Maintenance for CPU Vulnerabilities (Meltdown) To: chris at bigballofwax.co.nz Hello, A number of serious security vulnerabilities affecting multiple CPU architectures were recently disclosed by Google's Project Zero team as outlined in our blog post[1]. In order to address the disclosed vulnerabilities, the physical hardware on which your Linode resides will need to undergo maintenance. This is the first of several separate maintenances that will be necessary to fully mitigate these vulnerabilities. This maintenance specifically patches the Meltdown vulnerability; the Spectre vulnerability will be addressed in a future maintenance cycle. We will inform you of these maintenance cycles via additional tickets. Scheduled maintenance windows are listed within the Linode Manager[2] in the time zone that was configured in your user's My Profile[3]. The maintenance window of new Linodes and upgraded, migrated, or resized Linodes will be reflected in the Linode Manager[2], but you may not receive maintenance ticket updates for these changes. The following Linode(s) have now been assigned a maintenance window in which a reboot will occur. Please note that these times can change as a result of the actions mentioned above. At this time your reboot schedule in UTC is as follows: * 2018-01-19 9:00:00 AM UTC - bugs You can prepare your Linode for this maintenance by following our Reboot Survival Guide. By following this guide before your maintenance, you will be able to ensure that services running on your Linode are resumed properly. The Reboot Survival Guide is available here: https://www.linode.com/docs/uptime/reboot-survival-guide These updates affect the underlying infrastructure that your Linode resides on and will not affect the data stored within your Linode. To further protect your Linode, we strongly recommend that you verify it is configured to boot using our latest kernel, which includes patches to help address these vulnerabilities. If your Linode's Configuration Profile is set to utilize our latest kernel, your kernel will automatically be updated upon rebooting. During the maintenance window, your Linode will be cleanly shut down and will be unavailable while we perform the updates. A two-hour window is allocated, however the actual downtime should be much less. After the maintenance has concluded, each Linode will be returned to its last state (running or powered off). We regret the short notice and the downtime required for this maintenance. However, due to the severity of these vulnerabilities, we have no choice but to take swift and immediate action to ensure the safety and security of our customers. For these reasons, we must adhere to a strict timetable, and will not be able to reschedule or defer this maintenance. If you experience any issues following the maintenance, please feel free to reach out to us and we will be happy to assist. --Linode [1] [2] [3] --- https://manager.linode.com/support/ticket/9818790 From julian.maurice at biblibre.com Thu Jan 18 09:42:27 2018 From: julian.maurice at biblibre.com (Julian Maurice) Date: Thu, 18 Jan 2018 09:42:27 +0100 Subject: [Koha-devel] git-bz: avoid storing unencrypted passwords in gitconfig In-Reply-To: <02e501d38ff9$b97975d0$2c6c6170$@prosentient.com.au> References: <3f60e9b8-473e-1a8c-3c20-ef538aa8696e@biblibre.com> <02e501d38ff9$b97975d0$2c6c6170$@prosentient.com.au> Message-ID: <94bf0545-133e-115d-6716-6078c6785868@biblibre.com> I tried libsecret with gnome-keyring, it worked the first time, but not the other ones infortunately... I get this error message: https://stackoverflow.com/questions/36585496/error-when-using-git-credential-helper-with-gnome-keyring-as-sudo#comment70025417_40312117 If you know how to fix it, please share! :) Le 18/01/2018 ? 02:14, David Cook a ?crit?: > This issue has annoyed me for years, so this sounds pretty cool! > > I don't love the "cache" and "store" options... but it looks like there > might be an alternative using libsecret or the gnome keyring. These > alternatives can be found in separate packages or built from source it > seems. > > On OpenSUSE, I just installed " git-credential-gnome-keyring". On Arch, they > use libsecret: > https://wiki.archlinux.org/index.php/GNOME/Keyring#Git_integration. > > It looks like the gnome keyring one is deprecated > (https://stackoverflow.com/questions/36585496/error-when-using-git-credentia > l-helper-with-gnome-keyring-as-sudo), so libsecret is probably the way to > go. > > I've tried using /usr/lib/git/git-credential-gnome-keyring, but it doesn't > seem to be working. Admittedly I'm just using a SSH session rather than a > GUI session. I launched DBUS so I don't get errors but it's not saving > credentials using "git credential approve". The "cache" option worked well > though. > > > David Cook > Systems Librarian > Prosentient Systems > 72/330 Wattle St > Ultimo, NSW 2007 > Australia > > Office: 02 9212 0899 > Direct: 02 8005 0595 > > > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org > [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of Julian > Maurice > Sent: Wednesday, 17 January 2018 9:14 PM > To: koha-devel at lists.koha-community.org > Subject: [Koha-devel] git-bz: avoid storing unencrypted passwords in > gitconfig > > Hi all, > > I recently shared an LXD container containing my Koha dev environment, and > of course I forgot to remove my Bugzilla credentials from the git config... > I immediately changed it, but for that not to happen again I searched for a > way to not have to store unencrypted passwords for git-bz. > > The result is here https://github.com/jajm/git-bz/tree/git-credential > > It uses git-credential, so you can theoretically use any password manager > you want, as long as you can write a git-credential helper for it (I use the > builtin 'cache' helper, which stores passwords in memory) > > I thought it might interest some people here. > > For more information, see the commit message at > https://github.com/jajm/git-bz/commit/efb06d8fe3033a83772d0294ab5f67c7f51eaf > 57 > > -- > Julian Maurice BibLibre > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : > http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ > > -- Julian Maurice BibLibre From claire.hernandez at biblibre.com Thu Jan 18 16:00:19 2018 From: claire.hernandez at biblibre.com (Claire Hernandez) Date: Thu, 18 Jan 2018 16:00:19 +0100 Subject: [Koha-devel] Exploration of Koha ElasticSearch implementation Message-ID: <95055bce-6d05-b585-1d36-1de43fdb5cc1@biblibre.com> Hi, I want to share a work with you. I knew we can now switch SearchEngine syspref to ElasticSearch in Koha community version, but I didn't know a lot more. I explored with some BibLibre guys what we can really do, if we can propose this feature to our users. It seems there is some work to do but it would be great to have a more solid version for 18.05 if we test and fix more things, a version for early adopters who want to try it in production. I began a document where I list the gap to this version, it is a work in progress. I integrated the items identified by Nick (kidclamp) in the wiki page (Elastisearch_status). Thanks. I could have put everything in bugzilla or wiki but it wasn't ideal to me at this time. Depending your feedback I can make it better. https://docs.google.com/spreadsheets/d/10VUKvIYZjlbJhE-oCLmInLe601su6vIRBRC_g6oNekE/edit#gid=0 Notes about tabs: - Way to 18.05 : I wanted it "macro functionnal", but currently it lists features or issues that may be too small. I tried to evaluate the work in "complexity point", "1" can be one developper day or maybe more or less; - Questions : can be used as a faq, I dropped my questions, sometimes I answered myself and other time someone else answeredme; - Queries and behaviours : we did a lot of work to implement Solr in Koha (at BibLibre, it begun in 2011) and an advanced search version is always maintained. I think it can be asked, so I pasted a list of queries we work with, it is expected to be different, it is just examples; - Pros : quick list of advantages for ElasticSearch in Koha Please, feel free to read, add lines, add questions or whatever. I am often available on #koha (@clrh). Claire. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Thu Jan 18 16:07:22 2018 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Thu, 18 Jan 2018 15:07:22 +0000 Subject: [Koha-devel] Exploration of Koha ElasticSearch implementation In-Reply-To: <95055bce-6d05-b585-1d36-1de43fdb5cc1@biblibre.com> References: <95055bce-6d05-b585-1d36-1de43fdb5cc1@biblibre.com> Message-ID: Excellent work, Claire and Biblibre friends! El jue., 18 ene. 2018 a las 12:00, Claire Hernandez (< claire.hernandez at biblibre.com>) escribi?: > Hi, > > I want to share a work with you. I knew we can now switch SearchEngine > syspref to ElasticSearch in Koha community version, but I didn't know a lot > more. I explored with some BibLibre guys what we can really do, if we can > propose this feature to our users. It seems there is some work to do but it > would be great to have a more solid version for 18.05 if we test and fix > more things, a version for early adopters who want to try it in production. > > I began a document where I list the gap to this version, it is a work in > progress. I integrated the items identified by Nick (kidclamp) in the wiki > page (Elastisearch_status). Thanks. I could have put everything in bugzilla > or wiki but it wasn't ideal to me at this time. Depending your feedback I > can make it better. > https://docs.google.com/spreadsheets/d/10VUKvIYZjlbJhE-oCLmInLe601su6vIRBRC_g6oNekE/edit#gid=0 > > Notes about tabs: > - Way to 18.05 : I wanted it "macro functionnal", but currently it lists > features or issues that may be too small. I tried to evaluate the work in > "complexity point", "1" can be one developper day or maybe more or less; > - Questions : can be used as a faq, I dropped my questions, sometimes I > answered myself and other time someone else answered me; > - Queries and behaviours : we did a lot of work to implement Solr in Koha > (at BibLibre, it begun in 2011) and an advanced search version is always > maintained. I think it can be asked, so I pasted a list of queries we work > with, it is expected to be different, it is just examples; > - Pros : quick list of advantages for ElasticSearch in Koha > > Please, feel free to read, add lines, add questions or whatever. I am > often available on #koha (@clrh). > > Claire. > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -- Tom?s Cohen Arazi Theke Solutions (https://theke.io ) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.druart at bugs.koha-community.org Thu Jan 18 19:38:59 2018 From: jonathan.druart at bugs.koha-community.org (Jonathan Druart) Date: Thu, 18 Jan 2018 18:38:59 +0000 Subject: [Koha-devel] git-bz: avoid storing unencrypted passwords in gitconfig In-Reply-To: <3f60e9b8-473e-1a8c-3c20-ef538aa8696e@biblibre.com> References: <3f60e9b8-473e-1a8c-3c20-ef538aa8696e@biblibre.com> Message-ID: Very long standing issues, good to see it fixed :) I have picked the commit for the apply_on_cascade branch of my github repo. Maybe we should make it (apply on cascade + use-git-credential) the default and push it to the community/master(or fishsoup) branch. By the way the fishsoup repo is 37 commits ahead from us :-/ http://git.fishsoup.net/cgit/git-bz/ On Wed, 17 Jan 2018 at 07:14 Julian Maurice wrote: > Hi all, > > I recently shared an LXD container containing my Koha dev environment, > and of course I forgot to remove my Bugzilla credentials from the git > config... > I immediately changed it, but for that not to happen again I searched > for a way to not have to store unencrypted passwords for git-bz. > > The result is here https://github.com/jajm/git-bz/tree/git-credential > > It uses git-credential, so you can theoretically use any password > manager you want, as long as you can write a git-credential helper for > it (I use the builtin 'cache' helper, which stores passwords in memory) > > I thought it might interest some people here. > > For more information, see the commit message at > > https://github.com/jajm/git-bz/commit/efb06d8fe3033a83772d0294ab5f67c7f51eaf57 > > -- > Julian Maurice > BibLibre > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcook at prosentient.com.au Thu Jan 18 23:26:54 2018 From: dcook at prosentient.com.au (David Cook) Date: Fri, 19 Jan 2018 09:26:54 +1100 Subject: [Koha-devel] git-bz: avoid storing unencrypted passwords in gitconfig In-Reply-To: <94bf0545-133e-115d-6716-6078c6785868@biblibre.com> References: <3f60e9b8-473e-1a8c-3c20-ef538aa8696e@biblibre.com> <02e501d38ff9$b97975d0$2c6c6170$@prosentient.com.au> <94bf0545-133e-115d-6716-6078c6785868@biblibre.com> Message-ID: <035501d390ab$71c1f3e0$5545dba0$@prosentient.com.au> That's cool, Julian! What version of Git are you using? The comments seem to suggest that might make a difference. I'm kind of curious to try git-credential-gnome-keyring, but... just not a priority at the moment. Overall, I'm super pleased about this though! David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 -----Original Message----- From: Julian Maurice [mailto:julian.maurice at biblibre.com] Sent: Thursday, 18 January 2018 7:42 PM To: David Cook ; koha-devel at lists.koha-community.org Subject: Re: [Koha-devel] git-bz: avoid storing unencrypted passwords in gitconfig I tried libsecret with gnome-keyring, it worked the first time, but not the other ones infortunately... I get this error message: https://stackoverflow.com/questions/36585496/error-when-using-git-credential-helper-with-gnome-keyring-as-sudo#comment70025417_40312117 If you know how to fix it, please share! :) Le 18/01/2018 ? 02:14, David Cook a ?crit : > This issue has annoyed me for years, so this sounds pretty cool! > > I don't love the "cache" and "store" options... but it looks like > there might be an alternative using libsecret or the gnome keyring. > These alternatives can be found in separate packages or built from > source it seems. > > On OpenSUSE, I just installed " git-credential-gnome-keyring". On > Arch, they use libsecret: > https://wiki.archlinux.org/index.php/GNOME/Keyring#Git_integration. > > It looks like the gnome keyring one is deprecated > (https://stackoverflow.com/questions/36585496/error-when-using-git-cre > dentia l-helper-with-gnome-keyring-as-sudo), so libsecret is probably > the way to go. > > I've tried using /usr/lib/git/git-credential-gnome-keyring, but it > doesn't seem to be working. Admittedly I'm just using a SSH session > rather than a GUI session. I launched DBUS so I don't get errors but > it's not saving credentials using "git credential approve". The > "cache" option worked well though. > > > David Cook > Systems Librarian > Prosentient Systems > 72/330 Wattle St > Ultimo, NSW 2007 > Australia > > Office: 02 9212 0899 > Direct: 02 8005 0595 > > > -----Original Message----- > From: koha-devel-bounces at lists.koha-community.org > [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of > Julian Maurice > Sent: Wednesday, 17 January 2018 9:14 PM > To: koha-devel at lists.koha-community.org > Subject: [Koha-devel] git-bz: avoid storing unencrypted passwords in > gitconfig > > Hi all, > > I recently shared an LXD container containing my Koha dev environment, > and of course I forgot to remove my Bugzilla credentials from the git config... > I immediately changed it, but for that not to happen again I searched > for a way to not have to store unencrypted passwords for git-bz. > > The result is here https://github.com/jajm/git-bz/tree/git-credential > > It uses git-credential, so you can theoretically use any password > manager you want, as long as you can write a git-credential helper for > it (I use the builtin 'cache' helper, which stores passwords in > memory) > > I thought it might interest some people here. > > For more information, see the commit message at > https://github.com/jajm/git-bz/commit/efb06d8fe3033a83772d0294ab5f67c7 > f51eaf > 57 > > -- > Julian Maurice BibLibre > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : > http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ > > -- Julian Maurice BibLibre From paul.poulain at biblibre.com Fri Jan 19 09:59:18 2018 From: paul.poulain at biblibre.com (Paul Poulain) Date: Fri, 19 Jan 2018 09:59:18 +0100 Subject: [Koha-devel] Hackfest, waiting for registrations ! Message-ID: <970748a3-525a-1eaa-7992-fa3de0550d80@biblibre.com> Hello everyone, I've only a few registrations so far. So reminder : join us in Marseille, March 12-16, for the Koha Hackfest !!! -- Paul Poulain, Associ?-g?rant / co-owner BibLibre, Services en logiciels libres pour les biblioth?ques BibLibre, Open Source software and services for libraries From julian.maurice at biblibre.com Fri Jan 19 10:13:59 2018 From: julian.maurice at biblibre.com (Julian Maurice) Date: Fri, 19 Jan 2018 10:13:59 +0100 Subject: [Koha-devel] git-bz: avoid storing unencrypted passwords in gitconfig In-Reply-To: References: <3f60e9b8-473e-1a8c-3c20-ef538aa8696e@biblibre.com> Message-ID: +1 for using master branch instead of fishsoup (or at least make fishsoup the default branch so we don't have to specify branch when cloning) I see that you did retrieve the "git-credential" commit on fishsoup branch (did you check that it continues to work for those that have password in their gitconfig ? I did, but another check would be good), but not the apply_on_cascade branch, why ? Also, I have a suggestion for git-bz for which I would like to hear other people opinion: I think we should use Github/Gitlab/... (whatever platform that makes easy for people to fork and create pull requests) and give push permission to anyone interested in reviewing pull requests. That suggestion also applies to our QA tools. I think that would ease and encourage improvements. Any thoughts ? Le 18/01/2018 ? 19:38, Jonathan Druart a ?crit?: > Very long standing issues, good to see it fixed :) > I have picked the commit for the apply_on_cascade branch of my github repo. > Maybe we should make it (apply on cascade + use-git-credential) the > default and push it to the community/master(or fishsoup) branch. > > By the way the fishsoup repo is 37 commits ahead from us :-/ > http://git.fishsoup.net/cgit/git-bz/ > > On Wed, 17 Jan 2018 at 07:14 Julian Maurice > wrote: > > Hi all, > > I recently shared an LXD container containing my Koha dev environment, > and of course I forgot to remove my Bugzilla credentials from the git > config... > I immediately changed it, but for that not to happen again I searched > for a way to not have to store unencrypted passwords for git-bz. > > The result is here https://github.com/jajm/git-bz/tree/git-credential > > It uses git-credential, so you can theoretically use any password > manager you want, as long as you can write a git-credential helper for > it (I use the builtin 'cache' helper, which stores passwords in memory) > > I thought it might interest some people here. > > For more information, see the commit message at > https://github.com/jajm/git-bz/commit/efb06d8fe3033a83772d0294ab5f67c7f51eaf57 > > -- > Julian Maurice > > BibLibre > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ > -- Julian Maurice BibLibre From mtompset at hotmail.com Fri Jan 19 17:47:05 2018 From: mtompset at hotmail.com (Mark Tompsett) Date: Fri, 19 Jan 2018 16:47:05 +0000 Subject: [Koha-devel] Outage for bugs.koha-community.org : Fwd: Linode Support Ticket 9818790 - Critical Maintenance for CPU Vulnerabilities (Meltdown) In-Reply-To: References: Message-ID: Greetings, I believe the outage is over (it suggests 2 hours max), but something gateway-wise is still buggy for dashboard. Bugzilla is back up. It is the weekend there, so no rush, but it would be nice to have back up. GPML, Mark Tompsett -----Original Message----- From: Chris Cormack Sent: Wednesday, January 17, 2018 10:45 PM To: koha-user ; koha-devel at lists.koha-community.org Subject: [Koha-devel] Outage for bugs.koha-community.org : Fwd: Linode Support Ticket 9818790 - Critical Maintenance for CPU Vulnerabilities (Meltdown) It looks like my linode which hosts bugs.koha-community.org and the dashboard and few other sites will be down for maintenance at 2018-01-19 9:00:00 AM UTC Chris ---------- Forwarded message ---------- From: Date: 18 January 2018 at 16:39 Subject: Linode Support Ticket 9818790 - Critical Maintenance for CPU Vulnerabilities (Meltdown) To: chris at bigballofwax.co.nz Hello, A number of serious security vulnerabilities affecting multiple CPU architectures were recently disclosed by Google's Project Zero team as outlined in our blog post[1]. In order to address the disclosed vulnerabilities, the physical hardware on which your Linode resides will need to undergo maintenance. This is the first of several separate maintenances that will be necessary to fully mitigate these vulnerabilities. This maintenance specifically patches the Meltdown vulnerability; the Spectre vulnerability will be addressed in a future maintenance cycle. We will inform you of these maintenance cycles via additional tickets. Scheduled maintenance windows are listed within the Linode Manager[2] in the time zone that was configured in your user's My Profile[3]. The maintenance window of new Linodes and upgraded, migrated, or resized Linodes will be reflected in the Linode Manager[2], but you may not receive maintenance ticket updates for these changes. The following Linode(s) have now been assigned a maintenance window in which a reboot will occur. Please note that these times can change as a result of the actions mentioned above. At this time your reboot schedule in UTC is as follows: * 2018-01-19 9:00:00 AM UTC - bugs You can prepare your Linode for this maintenance by following our Reboot Survival Guide. By following this guide before your maintenance, you will be able to ensure that services running on your Linode are resumed properly. The Reboot Survival Guide is available here: https://www.linode.com/docs/uptime/reboot-survival-guide These updates affect the underlying infrastructure that your Linode resides on and will not affect the data stored within your Linode. To further protect your Linode, we strongly recommend that you verify it is configured to boot using our latest kernel, which includes patches to help address these vulnerabilities. If your Linode's Configuration Profile is set to utilize our latest kernel, your kernel will automatically be updated upon rebooting. During the maintenance window, your Linode will be cleanly shut down and will be unavailable while we perform the updates. A two-hour window is allocated, however the actual downtime should be much less. After the maintenance has concluded, each Linode will be returned to its last state (running or powered off). We regret the short notice and the downtime required for this maintenance. However, due to the severity of these vulnerabilities, we have no choice but to take swift and immediate action to ensure the safety and security of our customers. For these reasons, we must adhere to a strict timetable, and will not be able to reschedule or defer this maintenance. If you experience any issues following the maintenance, please feel free to reach out to us and we will be happy to assist. --Linode [1] [2] [3] --- https://manager.linode.com/support/ticket/9818790 _______________________________________________ Koha-devel mailing list Koha-devel at lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ From chrisc at catalyst.net.nz Sat Jan 20 05:14:24 2018 From: chrisc at catalyst.net.nz (Chris Cormack) Date: Sat, 20 Jan 2018 17:14:24 +1300 Subject: [Koha-devel] Outage for bugs.koha-community.org : Fwd: Linode Support Ticket 9818790 - Critical Maintenance for CPU Vulnerabilities (Meltdown) In-Reply-To: References: Message-ID: <20180120041424.GE14111@rorohiko.wgtn.cat-it.co.nz> * Mark Tompsett (mtompset at hotmail.com) wrote: >Greetings, > >I believe the outage is over (it suggests 2 hours max), but something >gateway-wise is still buggy for dashboard. >Bugzilla is back up. It is the weekend there, so no rush, but it would be >nice to have back up. Should be all back now Chris > >GPML, >Mark Tompsett > >-----Original Message----- >From: Chris Cormack >Sent: Wednesday, January 17, 2018 10:45 PM >To: koha-user ; koha-devel at lists.koha-community.org >Subject: [Koha-devel] Outage for bugs.koha-community.org : Fwd: Linode >Support Ticket 9818790 - Critical Maintenance for CPU Vulnerabilities >(Meltdown) > >It looks like my linode which hosts bugs.koha-community.org and the >dashboard and few other sites will be down for maintenance >at 2018-01-19 9:00:00 AM UTC > >Chris > > > >---------- Forwarded message ---------- >From: >Date: 18 January 2018 at 16:39 >Subject: Linode Support Ticket 9818790 - Critical Maintenance for CPU >Vulnerabilities (Meltdown) >To: chris at bigballofwax.co.nz > > > >Hello, > >A number of serious security vulnerabilities affecting multiple CPU >architectures were recently disclosed by Google's Project Zero team as >outlined in our blog post[1]. In order to address the disclosed >vulnerabilities, the physical hardware on which your Linode resides >will need to undergo maintenance. This is the first of several >separate maintenances that will be necessary to fully mitigate these >vulnerabilities. This maintenance specifically patches the Meltdown >vulnerability; the Spectre vulnerability will be addressed in a future >maintenance cycle. We will inform you of these maintenance cycles via >additional tickets. > >Scheduled maintenance windows are listed within the Linode Manager[2] >in the time zone that was configured in your user's My Profile[3]. The >maintenance window of new Linodes and upgraded, migrated, or resized >Linodes will be reflected in the Linode Manager[2], but you may not >receive maintenance ticket updates for these changes. > >The following Linode(s) have now been assigned a maintenance window in >which a reboot will occur. Please note that these times can change as >a result of the actions mentioned above. At this time your reboot >schedule in UTC is as follows: > >* 2018-01-19 9:00:00 AM UTC - bugs > >You can prepare your Linode for this maintenance by following our >Reboot Survival Guide. By following this guide before your >maintenance, you will be able to ensure that services running on your >Linode are resumed properly. The Reboot Survival Guide is available >here: > >https://www.linode.com/docs/uptime/reboot-survival-guide > >These updates affect the underlying infrastructure that your Linode >resides on and will not affect the data stored within your Linode. To >further protect your Linode, we strongly recommend that you verify it >is configured to boot using our latest kernel, which includes patches >to help address these vulnerabilities. If your Linode's Configuration >Profile is set to utilize our latest kernel, your kernel will >automatically be updated upon rebooting. > >During the maintenance window, your Linode will be cleanly shut down >and will be unavailable while we perform the updates. A two-hour >window is allocated, however the actual downtime should be much less. >After the maintenance has concluded, each Linode will be returned to >its last state (running or powered off). > >We regret the short notice and the downtime required for this >maintenance. However, due to the severity of these vulnerabilities, we >have no choice but to take swift and immediate action to ensure the >safety and security of our customers. For these reasons, we must >adhere to a strict timetable, and will not be able to reschedule or >defer this maintenance. > >If you experience any issues following the maintenance, please feel >free to reach out to us and we will be happy to assist. > >--Linode > >[1] > >[2] >[3] > > >--- >https://manager.linode.com/support/ticket/9818790 >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ > >_______________________________________________ >Koha-devel mailing list >Koha-devel at lists.koha-community.org >http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel >website : http://www.koha-community.org/ >git : http://git.koha-community.org/ >bugs : http://bugs.koha-community.org/ -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From indradg at gmail.com Sun Jan 21 17:46:05 2018 From: indradg at gmail.com (Indranil Das Gupta) Date: Sun, 21 Jan 2018 22:16:05 +0530 Subject: [Koha-devel] What is the current kohadocs patch submission workflow Message-ID: Hi, Back in the day, when Nicole was managing the Docs, the workflow I knew was thus : clone kohadocs -> add your part -> generate patch -> send it to Nicole Nicole used to merge it and up it went. I was trying to find out what is the present workflow for docs. Any pointers I can read up? thanks indranil -- Indranil Das Gupta L2C2 Technologies Phone : +91-98300-20971 WWW : http://www.l2c2.co.in Blog : http://blog.l2c2.co.in IRC : indradg on irc://irc.freenode.net Twitter : indradg -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomascohen at gmail.com Sun Jan 21 19:54:18 2018 From: tomascohen at gmail.com (Tomas Cohen Arazi) Date: Sun, 21 Jan 2018 18:54:18 +0000 Subject: [Koha-devel] What is the current kohadocs patch submission workflow In-Reply-To: References: Message-ID: Yes, there's a complete wiki page about it! https://wiki.koha-community.org/wiki/Editing_the_Koha_Manual Enjoy! El dom., 21 de ene. de 2018 1:46 p. m., Indranil Das Gupta < indradg at gmail.com> escribi?: > Hi, > > Back in the day, when Nicole was managing the Docs, the workflow I knew > was thus : > > clone kohadocs -> add your part -> generate patch -> send it to Nicole > > Nicole used to merge it and up it went. I was trying to find out what is > the present workflow for docs. > > Any pointers I can read up? > > thanks > indranil > > > -- > Indranil Das Gupta > L2C2 Technologies > > Phone : +91-98300-20971 > WWW : http://www.l2c2.co.in > Blog : http://blog.l2c2.co.in > IRC : indradg on irc://irc.freenode.net > Twitter : indradg > _______________________________________________ > Koha-devel mailing list > Koha-devel at lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -- Tom?s Cohen Arazi Theke Solutions (https://theke.io ) ? +54 9351 3513384 GPG: B2F3C15F -------------- next part -------------- An HTML attachment was scrubbed... URL: From indradg at gmail.com Sun Jan 21 22:18:12 2018 From: indradg at gmail.com (Indranil Das Gupta) Date: Mon, 22 Jan 2018 02:48:12 +0530 Subject: [Koha-devel] W3C Validator now generates several warnings on OPAC pages Message-ID: Hi, I generally use the W3C Validator to make sure that editable OPAC blocks do not contain any non-conforming / invalid HTML5. Earlier, the validator used to complain only about the unapi-server as the only error, which is unavoidable. However, from around Dec 2017, I started noticing that Koha's OPAC pages were triggering several warnings when checked with W3C Validator - about 10 - 14 (or more) warnings that comes up. The warnings are about the type attribute set to "text/javascript" in the