Re: [Koha-devel] remote training on Koha & covid-19

2020-03-15 Thread dcook
Sometimes we have to do remote training for geographical/financial reasons.

On our end, we just need to use software that allows us to share our screen and 
audio/audiovisual, so that we can demonstrate / lecture. 

Then on their end, they can use a computer lab, a meeting room w/ BYOD (bring 
your own device), or some combination like that so that they can follow along, 
participate, talk to each other, pose questions, etc. 

One thing to note is that participants seem to have less energy for remote 
training than in-person training, so we tend to only book half-day remote 
training sessions and just do more of them.

Obviously, it's also harder to monitor their progress, since you can't look 
over their shoulders and do as much one-on-one work. There might be software 
solutions to help with that. (Like muting the group but being able to share 
screens with only an individual, so you can see what they're seeing and comment 
on their particular situation.) But I don't have experience with that.

I think in-person training tends to be more effective (like in-person 
university classes really), but I think remote training is a useful substitute. 

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  On Behalf Of 
Paul Poulain
Sent: Saturday, 14 March 2020 4:33 AM
To: koha-devel@lists.koha-community.org
Subject: [Koha-devel] remote training on Koha & covid-19

Hello all,

In France, we always move to the library for training. With the covid-19 we may 
have to do some remote training. Have you experimented remote training ? How 
does it go ? How do you organise the training ? Any hints ?

Thanks for anything shared, that will be helpful for us !

--
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@lists.koha-community.org
https://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/



signature.asc
Description: PGP signature
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://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/


Re: [Koha-devel] Koha packaging problems (Deb10/Buster)

2020-03-15 Thread dcook
Hmm that is tricky. 

I've run through a few different scenarios in my head but they all have pros 
and cons. No obvious winner. 

I think maybe your idea of a main Koha repo and separate Debian specific repos 
is the best compromise. That way all supported Linux distros can gets access to 
all supported Koha versions. Right?

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: Mason James  
Sent: Friday, 13 March 2020 6:44 PM
To: dc...@prosentient.com.au; 'Koha Devel' 
Subject: Re: [Koha-devel] Koha packaging problems (Deb10/Buster)

we need to pin on buster because the current combination of 
libmojolicious-plugin-openapi-perl (1.15~koha) and libmojolicious-perl (8.12) 
packages that buster pulls are incompatible with each other - even with bz 
22522 applied, this problem still exists on buster

we can fix buster by uploading a new version of 
libmojolicious-plugin-openapi-perl (2.20) to the koha repo, but this breaks 
jessie - so we cant do that until 30th june

...or do we decide to upload a new version of 
libmojolicious-plugin-openapi-perl to the koha repo now, and break jessie to 
fix buster?


any other ideas?


On 13/03/20 11:36 am, dc...@prosentient.com.au wrote:
> Wait a minute... why do we need to pin libmojolicious-perl? 
>
> Thanks to Ere's work on 
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22522, Koha should 
> be able to work with Mojolicious 8 now (and Mojolicious::Plugin::OpenAPI 2.21 
> and JSON::Validator 3.18). Admittedly it's only in master right now, but I'm 
> using his patches on 18.11 and 19.11 already with Mojolicious 8, and they're 
> working well so far. So hopefully people start pushing that code to stable 
> branches ASAP. 
>
> 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  On 
> Behalf Of Mason James
> Sent: Thursday, 12 March 2020 8:20 PM
> To: Koha Devel 
> Subject: Re: [Koha-devel] Koha packaging problems (Deb10/Buster)
>
> On 12/03/20 12:43 am, Mason James wrote:
>> On 10/03/20 8:08 pm, Mason James wrote:
>>> Hi Koha devs
>>>
>>> We have a dependency problem with the release of debian-10 and the 
>>> following packages. (debian-11 is ok)
>>>
>>>  libmojolicious-perl
>>>  libmojolicious-plugin-openapi-perl
>>>  libyaml-libyaml-perl
>>> Two other options...
>>>  1/ use kc.org debian packages, with cpanminus (or similar) 
>>> providing the distro specific packages (extra installation steps and
>>> complexity)
>>>  2/ ignore the problem for now, and accept that older koha/distro 
>>> combinations will be forced to break
>> some other points i didnt mention...
>>
>> koha on buster has a security bug. the solution requires some 
>> packages to be updated
>>
>> i can push the packages to the koha repo to fix this problem, but... 
>> (there's always a but) the new packages will break jessie :/ when 
>> jessie-lts support officially finishes on 30th june 2020, i can 
>> happily push these packages - but between now and 30th june we need 
>> to decide on a fix for the security bug on buster  
>> https://wiki.debian.org/LTS
>>
>> some other options...
>>  3/ do nothing and tell people to not use buster, until june  4/ 
>> provide buster packages in an separate repo, until june  5/ provide 
>> instructions to add buster packages using cpanm, until june  6/ 
>> update koha repo to fix buster, and provide jessie packages in an 
>> separate repo  7/ update koha repo to fix buster, and provide 
>> instructions to add jessie packages using cpanm  8/ submit required 
>> buster packages to debian buster-backports repo (not sure how 
>> difficult this is)
>>
>> i prefer option 4/, as its the least disruptive for users, and only 
>> requires an extra sources.list line to implement
>>
>> also... i think we should hold off on redesigning the koha apt 
>> repository until *after* this buster security issue is fixed
>>
>> cheers, Mason
> hmm, i had forgotten another...
> its possible to tell apt to prefer koha's older mojo v7 package, 
> rather than the newer debian/buster mojo v8 package
>
> running the following command before 'apt install koha-common' makes 
> it possible to run the various koha releases on debian 10
>
> $ sudo cat << EOF > /etc/apt/preferences.d/koha-1001
> Package: libjson-validator-perl
> Pin-Priority: 1001
> Pin: release o=Koha
>
> Package: libmojolicious-perl
> Pin-Priority: 1001
> Pin: release o=Koha
> EOF
>
>
> for me, this option is probably the easiest workaround for koha on 
> debian 10
>
> if nobody objects? - i am happy to update the koha wiki with this 
> workaround
>
> cheers, Mason
>
> ___
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website