[manjaro-dev] accessibility package updates

[Bernhard Landauer]

Lets try the current git version then. And hope that the new pkg installs for everyone now.
We don't normally get any reports about gpg issues with my signature theses days anymore.
Maybe some people haven't updated their systems for a while... should be taken care of by the manjaro-system-pkg upgrades anyway.

On 05/12/15 12:49, kendell clark wrote:

> hi
> To be honest, I'm not really sure what the differences are, other than
> some better sound icons. I'm sure there's lots of other stuff that an
> avid emacs user would know about but since I don't use it I'm not sure.
> I can try the aur, only I've been having so many issues just logging in
> that it might be faster to use the git version, which I don't believe
> has this error. At least when I built and installed it last, which was
> about a week ago it didn't.
> Thanks
> Kendell clark
> I'm also getting a lot of reports on our sonar support list about the
> espeak package failing to upgrade from the package we originally had to
> the package you built and uploaded. The error seems to be a corrupted
> pgp signature, even though I've told them to run pacman-key --init
> followed by pacman-key --populate manjaro and finally pacman-key
> --refresh-keys before trying to upgrade again. They say it doesn't help
> and I'm not sure what else to try. I've told them to add espeak to the
> ignorepkg line in pacman.conf temporarily , which some do happily and
> some ... well, lets just say they complain a lot and compare us to a
> certain microsoft product ... I didn't get the error so I have no idea
> what's going on.
> Thanks
> Kendell clark
>
>
> On 12/05/2015 05:33 AM, Bernhard Landauer wrote:
>> Hi Kendell!
>>
>> When using the current PKGBUILD for emacspeak the reason for the error
>> seems to be the prepare() function.
>> For me buildpkg throws this error:
>> install -d /usr/share/emacs/site-lisp
>> install -d /usr/share/emacs/site-lisp/emacspeak
>> install: cannot change permissions of
>> '/usr/share/emacs/site-lisp/emacspeak': No such file or directory
>> Makefile:242: recipe for target 'install' failed
>>
>> When you look at the PKGBUILD for emacspeak-git there are some little
>> differences. It would take some more investigation to figure out what
>> exactly needs to be changed in the PKGBUILD...
>> How helpful or important do you think the update to v43.0 is? We could
>> either wait for the maintainer (who is also the maintainer of the git
>> version) to update the pkg - maybe send him a comment on the pkg in the
>> AUR to remind him?)
>> Or we could use the git version instead.
>>
>> I'm not exactly sure about your question regarding brltty and the other
>> pkgs. Should we simply add them as build-dependencies?
>>
>> I will rebuild tintin-alteraeon.
>> We just need to know when there have been commits that you would like to
>> have integrated or when a repo has a new release.
>> Another reasonable occasion would be that a dependency or related pkg
>> would be updated. Like for example in this case when there would be a
>> new release of tintin itself.
>>
>> kind regards
>> Bernhard
>>
>> On 05/12/15 10:24, kendell clark wrote:
>>
>>> hi all
>>>    I'm writing in to let everyone know of new updates to some of the
>>> packages bernhard has built for sonar. Emacspeak has been updated from
>>> 42.0 to 43.0. I attempted to fix this in the pkgbuild and push, but I
>>> refuse to push a change that won't build cleanly, and I get an error
>>> when building. The exact error is as follows. Install:
>>> /usr/share/emacs/site-lisp/emacspeak/readme: permission denied. i've
>>> never gotten this before and I'm stumped. I thought the packages were
>>> built in chroots and then installed? THis is during the build process,
>>> which means it's getting a permission denied error when trying to
>>> install into the chroot. I have a request to make of whoever is managing
>>> the brltty package for manjaro. Would you be willing to install
>>> speech-dispatcher and espeak? You don't need to use them, but brltty
>>> builds drivers for these into itself and is able to act as a console
>>> screen reader if these are detected. There has been an update to the
>>> tintin alteraeon pack. This brings up a question. How should we manage
>>> git packages? The tintin pack is a git repository, and it would be way
>>> too burdensome to expect a new version every push. How often should the
>>> maintainer check for and update the package?
>>> Thanks
>>> Kendell clark
>>> _______________________________________________
>>> manjaro-dev mailing list
>>> manjaro-dev at manjaro.org
>>> http://lists.manjaro.org/mailman/listinfo/manjaro-dev
>>>
>> _______________________________________________
>> manjaro-dev mailing list
>> manjaro-dev at manjaro.org
>> http://lists.manjaro.org/mailman/listinfo/manjaro-dev
>>