Re: Reviews Weekly
by Randy Barlow
On Mon, 2017-01-23 at 10:09 +0000, nobody(a)fedoraproject.org wrote:
> Remi Collet : 14
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1414843 php
> -react-http-client
> https://bugzilla.redhat.com/show_bug.cgi?id=1414826 php
> -react-event-loop
> https://bugzilla.redhat.com/show_bug.cgi?id=1414828 php
> -react-stream
> https://bugzilla.redhat.com/show_bug.cgi?id=1414827 php
> -react-promise-timer
> https://bugzilla.redhat.com/show_bug.cgi?id=1414840 php
> -react-http
> https://bugzilla.redhat.com/show_bug.cgi?id=1414839 php
> -react-dns
> https://bugzilla.redhat.com/show_bug.cgi?id=1414838 php
> -react-socket
> https://bugzilla.redhat.com/show_bug.cgi?id=1414842 php
> -react-socket-client
> https://bugzilla.redhat.com/show_bug.cgi?id=1414833 php
> -react-child-process
> https://bugzilla.redhat.com/show_bug.cgi?id=1414831 php
> -clue-block-react
> https://bugzilla.redhat.com/show_bug.cgi?id=1413339 php
> -evenement
> https://bugzilla.redhat.com/show_bug.cgi?id=1414824 php
> -clue-stream-filter
> https://bugzilla.redhat.com/show_bug.cgi?id=1414825 php
> -react-cache
> https://bugzilla.redhat.com/show_bug.cgi?id=1411188 php
> -echonest-api
Haha, nice work Remi!
7 years, 3 months
Re: Want to help me package Ampache?
by Randy Barlow
Thanks for the reply Remi! I'm switching the thread to php-devel (from
devel). Responses inline below.
On Mon, 2017-01-16 at 08:44 +0100, Remi Collet wrote:
> Le 16/01/2017 à 07:06, Randy Barlow a écrit :
> > Hello Fedora devs!
> >
> > I recently started working on getting Ampache packaged for Fedora,
> and
> > it turns out it is no small feat. There are two problems:
> >
> > 0) 5 of the packages have been abandoned upstream, and have been
> > replaced with different packages that are now recommended. Ampache
> is
> > aware of this and does intend to switch, but at this time they
> still
> > depend on these 5 packages. Would this be a blocker to getting
> Ampache
> > in, or can we just plan to retire these packages once upstream is
> able
> > to use their new replacements?
>
> I don't think this is a blocker.
>
> Of course you can retire them when no more used by Ampache.
>
> BTW, perhaps another way is to use bundled versions for these, to not
> expose them as something "stable and maintained".
Bundling them is an interesting idea. It'll save some time, and it'll
make it easier to do the packaging initially. Perhaps I'll go this
route.
> > 1) There are 34 PHP and JavaScript packages that need to be
> packaged
> > Fedora!
>
> Perhaps php-devel(a)lists.fedoraproject.org worth to be used.
>
> I also recommend you read the SIG pages (especially the packaging
> tips
> for autoloaders, and how we get rid of the composer autoloader)
>
> => https://fedoraproject.org/wiki/SIGs/PHP
>
> Shawn Iwinski can probably help you on the guzzle stuff.
I actually just discovered the PHP packaging tips page last night that
mentions a bit about the autoloaders. It might be helpeful to include
the information from https://fedoraproject.org/wiki/SIGs/PHP/PackagingT
ips in https://fedoraproject.org/wiki/Packaging:PHP, or possibly link
to the former from the latter. I had only discovered the latter link
when making my first few packages, so knowing about the tips would have
been nice.
If anyone would like to help me, this page tracks the packages that are
needed:
https://fedoraproject.org/wiki/Ampache
7 years, 3 months
dropping php-oauth from Fedora
by François Kooman
Hi,
It seems like a good idea to drop "php-oauth" [1] from Fedora, as it is
old and no longer maintained upstream and there are no packages
depending on it:
[fkooman@fralen ~]$ sudo dnf repoquery --whatrequires php-oauth
Last metadata expiration check: 1:15:18 ago on Mon Jan 9 11:18:04 2017.
[fkooman@fralen ~]$
Thoughts?
Cheers,
François
[1] https://admin.fedoraproject.org/pkgdb/package/rpms/php-oauth/
7 years, 3 months
Library multi-version and dependencies
by Remi Collet
Hi,
Working again on multi-versions of the same library.
We start to have more and more libraries available in multiple versions.
In a consumer package:
If composer.json states foo: "~1 | ~2"
As v1 and v2 are different major version, we are going to have 2
different packages installed in different tree.
php-foo1, with autoloader in /usr/share/php/foo1/autoload.php
php-foo2, with autoloader in /usr/share/php/foo2/autoload.php
So you MUST allow both version ONLY if your autoloader is aware of each
autoloader patch
Examples
BuildRequires: php-composer(foo) < 3
BuildRequires: php-composer(foo) >= 1
Requires: php-composer(foo) < 3
Requires: php-composer(foo) >= 1
And in autoloader
\Fedora\Autoloader\Dependencies::required(array(
array(
'/usr/share/php/foo2/autoload.php',
'/usr/share/php/foo1/autoload.php',
)));
Do not allow multi major versions if your composer if not aware.
Do not add Conflicts on composer virtual name.
Conflicts: php-composer(foo) >= 3
This is bad, as if php-foo3 exists, it will be installed in another
tree, so won't be used, and no conflicts needed.
Comment (before I try to add something in the packaging tips page) ?
Remi.
Ex:
https://raw.githubusercontent.com/remicollet/remirepo/160ef9c7e1fba041810...
(in my repo)
- twig 1 and 2 are allowed, as autoloader is aware of both versions
- symfony 3 is not allowed (despite supported by upstream) as the
autoloader is only aware of v2
7 years, 3 months
