Re: Intent to orphan Python 2
On 4 April 2018 at 22:06, Kevin Fenzi wrote: > On 04/04/2018 01:35 PM, James Hogarth wrote: >> On Wed, 4 Apr 2018, 21:28 Adam Williamson, >> wrote: >> >>> This rather begs the question of whether there are any modules which >>> only work *with python 2*, though... > > The answer is (at least based on what I know from talking with upstream) > that ansible has been pretty well tested with python3 for the controller > host. All upstream PR's are tested against both python2 and python3. All > upstream CI runs against python2 and python3. > > For the target/managed node side: all core modules have been tested > under python3. Community supported modules however they have been fixing > python3 issues as they come up. There's not any full testing thats > happened over all those, nor is there likely to be. > > Heres the list of known python3 bugs in modules: > https://github.com/ansible/ansible/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Apython3+label%3Abug > Yup this is why I'm very nervous about the F29/F30 plans in the face of this ... >> The ansible guys might know... or might not really tbh which is why the >> current documentation upstream still declares it a technology preview. >> >> The test coverage is growing there but not massively comprehensive... and >> tbh I expect the greater problem will be random galaxy stuff or local >> plugins and modules people have written. > > Right. > > However, they do say that most problems are trivial to fix up also. > Trivial ... but still need time and people to review, merge and then release them. Stuff in galaxy can be fixed relatively quickly by owners as it bypasses github stuff of course ... but modules shipped with ansible already will take a while to go from PR to a built and shipped release. >> It's going to be a very disruptive change in F29 as it is... to the extent >> I might start directing people to use the upstream ansible repos directly >> if they don't change there.> >> I'm honestly looking to the py2 drop in F30 as a necessary evil but one I'm >> looking at with intense trepidation. > > Well, if it happens... some people might choose to keep it alive. > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org Well ... even if they do that doesn't help if a bunch of packages (especially pretty core ones to Fedora like firewalld) drop their python2 libraries ... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [DONE] Mass package change (python2- binary package renaming)
On Sun, 2017-08-20 at 20:49 +0100, Sérgio Basto wrote:
> On Sun, 2017-08-20 at 18:49 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Sun, Aug 20, 2017 at 05:09:04PM +0100, Sérgio Basto wrote:
> > > On Sun, 2017-08-20 at 14:46 +, Zbigniew Jędrzejewski-Szmek
> > > wrote:
> > > > On Sun, Aug 20, 2017 at 05:16:54AM +0100, Sérgio Basto wrote:
> > > > > On Sun, 2017-08-20 at 03:26 +, Zbigniew Jędrzejewski-
> > > > > Szmek
> > > > > wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I pushed the changes and rebuilt the packages today.
> > > > >
> > > > > Hi,
> > > > > I got this [1] in log of wammu-0.43-1.fc28, so in [2] line 50
> > > > > you
> > > > > need
> > > > > replace
> > > > > Requires: %{name} = %{version}-%{release}
> > > > > by
> > > > > Requires: python2-%{name} = %{version}-%{release}
> > > > >
> > > > > isn't it ?
> > > >
> > > > Thanks. That's two bugs:
> > > > - the Provides for the old name without %{_isa} is missing
> > > >(Requires: %{name}%{_isa} is resolvable, but not Requires:
> > > > %{name})
> > > > - internal Requires should be updated to use the new name
> > > >(using the old name does not break anything in general, but
> > > > is
> > > > inelegant).
I found a 3rd bug , provides / obsoletes misses epoch
%{version}-%{release} needs be replaced by :
%{?epoch:%{epoch}:}%{version}-%{release}
where packages have epoch , IIRC this happens with python-blivet
--
Sérgio M. B.
___
python-devel mailing list -- python-de...@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Web assets in Fedora
Interesting read thanks, I was looking to package myetherwallet( https://github.com/kvhnuke/etherwallet) as my first package in the official repo. At first I though it will be easy because it's "only html files" no binary, library etc... Oh I was so wrong... To be honest I'm stuck at trying to find a way to package this and the over 800 dependencies and I'm a bit lost with the guideline... I'm a sysadmin with really basic coding skills, if someone reading this have experience with that kind of package I would be more than happy to get some help to start me on the right track! ( Sorry for hijacking your post but I felt it was a bit related!) Thanks! On Wed, Apr 4, 2018 at 3:08 PM, Jakub Kadlcik wrote: > Hello, > I've written a blog post about web assets in Fedora. > > Do you bundle third-party libraries/frameworks like jQuery, Bootstrap or > Patternfly into your project and commit them to the git repository? > > There is a much better solution how to do it. If you are interested, > please read the article http://frostyx.cz/posts/web-assets-in-fedora > > > Jakub > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Web assets in Fedora
On 04/04/2018 03:08 PM, Jakub Kadlcik wrote: > Do you bundle third-party libraries/frameworks like jQuery, Bootstrap or > Patternfly into your project and commit them to the git repository? /me raises his hand > There is a much better solution how to do it. If you are interested, > please read the article http://frostyx.cz/posts/web-assets-in-fedora I've been considering doing exactly this with Bodhi. Thanks for the post! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to orphan Python 2
On 04/04/2018 01:35 PM, James Hogarth wrote: > On Wed, 4 Apr 2018, 21:28 Adam Williamson, > wrote: > >> This rather begs the question of whether there are any modules which >> only work *with python 2*, though... The answer is (at least based on what I know from talking with upstream) that ansible has been pretty well tested with python3 for the controller host. All upstream PR's are tested against both python2 and python3. All upstream CI runs against python2 and python3. For the target/managed node side: all core modules have been tested under python3. Community supported modules however they have been fixing python3 issues as they come up. There's not any full testing thats happened over all those, nor is there likely to be. Heres the list of known python3 bugs in modules: https://github.com/ansible/ansible/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Apython3+label%3Abug > The ansible guys might know... or might not really tbh which is why the > current documentation upstream still declares it a technology preview. > > The test coverage is growing there but not massively comprehensive... and > tbh I expect the greater problem will be random galaxy stuff or local > plugins and modules people have written. Right. However, they do say that most problems are trivial to fix up also. > It's going to be a very disruptive change in F29 as it is... to the extent > I might start directing people to use the upstream ansible repos directly > if they don't change there.> > I'm honestly looking to the py2 drop in F30 as a necessary evil but one I'm > looking at with intense trepidation. Well, if it happens... some people might choose to keep it alive. kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 28-20180404.n.0 compose check report
No missing expected images. Failed openQA tests: 1/137 (x86_64), 3/23 (i386), 1/2 (arm) ID: 217078 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/217078 ID: 217079 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/217079 ID: 217093 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/217093 ID: 217141 Test: x86_64 universal install_blivet_ext3@uefi URL: https://openqa.fedoraproject.org/tests/217141 ID: 217190 Test: i386 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/217190 Soft failed openQA tests: 9/137 (x86_64), 2/23 (i386) (Tests completed, but using a workaround for a known bug) ID: 217045 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/217045 ID: 217056 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/217056 ID: 217057 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/217057 ID: 217097 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user URL: https://openqa.fedoraproject.org/tests/217097 ID: 217098 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/217098 ID: 217099 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/217099 ID: 217124 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/217124 ID: 217128 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/217128 ID: 217146 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/217146 ID: 217156 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/217156 ID: 217172 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/217172 Passed openQA tests: 127/137 (x86_64), 18/23 (i386) Skipped openQA tests: 1 of 162 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to orphan Python 2
Adam Williamson (adamw...@fedoraproject.org) said: > This rather begs the question of whether there are any modules which > only work *with python 2*, though... Given 1500+ modules, all of which can have their own python library dependencies, the safe answer is 'yes'. We're working to solve that, but it's a proces... Bill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On Wed, Apr 4, 2018 at 4:53 PM James Hogarth wrote: > On Wed, 4 Apr 2018, 19:54 Stephen Gallagher, wrote: > >> >> On F28 >> `dnf install php:8/server` (Assuming there's a profile called "server" >> with the packages one would need to use PHP in a server context) >> >> On F29, if you have the php:7 module enabled in F28, an upgrade will not >> switch this on you. If it's a clean install: >> `dnf install php:7/server` >> >> (Note: I don't know if PHP is backwards-compatible between minor >> versions; If it's not, then it would probably be php:7.2 and php:8.0 >> instead) >> > ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > This is intriguing and a big improvement over the previous plans I alluded > to. > > Once we've got the update train going, and F28 is released, could I > please pick your brains a bit on this? > > Absolutely, I'm at your disposal. Also feel free to join #fedora-modularity on Freenode, where I and other folks working on the plumbing hang out. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On Wed, 4 Apr 2018, 19:54 Stephen Gallagher, wrote:
>
>
> On Wed, Apr 4, 2018 at 2:36 PM Przemek Klosowski <
> przemek.klosow...@nist.gov> wrote:
>
>> On 04/04/2018 01:59 PM, Stephen Gallagher wrote:
>> > The short version is that Modules *are* distribution packages. They're
>> > just distribution packages that allow you to pick which major release
>> > stream you want to stay on. We also have a distribution-level defaults
>> > setup that allows you to pick one stream from the module and call that
>> > the "default" for a particular Fedora release. Once that stream is so
>> > marked, it just shows up automatically in DNF identically to the way
>> > that traditional distribution RPMs do today. So let's say that in
>> > Fedora 28 you make PHP into a module with the stream "7.2". We mark
>> > that as the default. People can then `dnf install php` exactly as they
>> > always could; the only thing they might see different would be the
>> > %{release} tag of the RPM.
>> >
>> > Now, let's assume that PHP upstream decided to release 8.0 next month.
>> > Fedora 29 would probably use that as its default module and would
>> > package the same way as the above. *However*, you now also have the
>> > opportunity to mark the module as being available for both F28 and F29
>> > and the Module Build Service would produce it for both. And now users
>> > of Fedora 28 can opt in to 8.0 before F29 is released if they want to.
>> > And the reverse is true as well: when upgrading to Fedora 29, users
>> > can opt to keep their version of PHP on 7.2 to continue supporting
>> > their application.
>> >
>> This is cool---so what command do you use to choose PHP 8.0 in F28? and
>> how do you choose to stay on 7.2 in F29?
>>
>>
> On F28
> `dnf install php:8/server` (Assuming there's a profile called "server"
> with the packages one would need to use PHP in a server context)
>
> On F29, if you have the php:7 module enabled in F28, an upgrade will not
> switch this on you. If it's a clean install:
> `dnf install php:7/server`
>
> (Note: I don't know if PHP is backwards-compatible between minor versions;
> If it's not, then it would probably be php:7.2 and php:8.0 instead)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
This is intriguing and a big improvement over the previous plans I alluded
to.
Once we've got the update train going, and F28 is released, could I please
pick your brains a bit on this?
Combined with my ansible playbooks (which a quick look at the fedora-ci
wiki pages I think I might be able to use there) it really could make life
easier and even allow users to change major version at their own
preference.
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On Wed, 4 Apr 2018, 20:26 Adam Williamson, wrote: > On Wed, 2018-04-04 at 11:15 +0100, James Hogarth wrote: > > On 4 April 2018 at 11:01, David Sommerseth wrote: > > > On 03/04/18 21:00, Christian Glombek wrote: > > > > I should probably add that the actual updater program has not been > shipped in the rpms thus far. Although I'm not sure how this affects major > updates, it is leading to problems elsewhere (i.e. people have to uninstall > some apps on v13 and re-install them on v13.0.1 for them to work again). > > > > > > > > And how many people actually still run NC v10? > > > > > > I have two servers with NC v10 via EPEL 7 ... and getting increasingly > concerned. > > > > > > > EPEL can't be updated > > I think I used to just update it anyway. No-one shot me. :P > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org Haha... you of all people know what steps I took and lengths I went through to safely update our owncloud users in EPEL when I took over maintenance from you ,) The reason I said it can't be updated is that EL7 ships with PHP5.4 which has been dropped from support by both owncloud and nextcloud upstream... and they have no intention of changing that with SCL, RemiRepo and IUS as options for their users on their packages. But of course we can't use any of those for EPEL packages as per our own policies so it literally can't be updated... there's no choice but to retire it. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to orphan Python 2
On Wed, 4 Apr 2018, 21:28 Adam Williamson, wrote: > On Wed, 2018-04-04 at 10:51 -0700, Kevin Fenzi wrote: > > On 04/04/2018 10:46 AM, Kevin Fenzi wrote: > > > On 04/04/2018 09:21 AM, James Hogarth wrote: > > > > > > ...snip... > > > > > > > Can we please get some consistency here? > > > > > > > > I noted today that firewalld has dropped python2-firewall but of > course > > > > ansible isn't switching to py3 for the controller (and therefore > local) > > > > until F29 and not all python modules are py3 compatible yet... and of > > > > course we ship firewalld as our firewall in fedora. > > > > > > > > This means that in F28 you can't just `yum install ansible > > > > python-firewall` and do ansible localhost -m firewalld and have it > work. > > > > > > Yeah, you would need to set ansible_python_interpreter for localhost, > > > which you could add to your command line with -e... > > > -e 'ansible_python_interpreter=/usr/bin/python3' > > > > Or, actually: > > > > yum install ansible-python3 python-firewall > > ansible localhost -m firewalld > > > > (since ansible-python3 defaults to python3 for the control > host/localhost) > > This rather begs the question of whether there are any modules which > only work *with python 2*, though... > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org The ansible guys might know... or might not really tbh which is why the current documentation upstream still declares it a technology preview. The test coverage is growing there but not massively comprehensive... and tbh I expect the greater problem will be random galaxy stuff or local plugins and modules people have written. It's going to be a very disruptive change in F29 as it is... to the extent I might start directing people to use the upstream ansible repos directly if they don't change there. I'm honestly looking to the py2 drop in F30 as a necessary evil but one I'm looking at with intense trepidation. > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On Wed, 4 Apr 2018, 18:39 Kevin Fenzi, wrote: > On 04/04/2018 07:51 AM, James Hogarth wrote: > ...snip... > > Today I've spent time between $realwork getting my ansible plays > > updated to handle F28 (thanks for dropping python2-* early guys!) and > > have been in contact with lorbus (thanks for stepping up). > > Note that if you mean ansible dropping python2 in F28, thats not the > case. If you mean some other package dropping pyhon2 that an ansible > module you use needs you can set ansible to use python3 for that target. > > If you want ansible to use python3 on the control host in f28, you can > just install ansible-python3 (in f29+ it will default to python3). > > For targets, set ansible_python_interpreter to which you want to use. > See > > http://docs.ansible.com/ansible/latest/reference_appendices/python_3_support.html > for more info. > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org Don't worry I'm well abreast of the plans and know the magic things to switch. Had to turn all my python library package installs into variables to override on fedora since this is a massive divergent point with RHEL and python package naming... Had a python-psycopg2 change bite me too (unencrypted password no longer supported in it which breaks my postgres_user task... but not related to py3) ... It's only a minor grumble though as these are changes that had to happen soon anyway... but they slow my iterations down to get the oC/nC stuff tested as I have to deal with them first of course. 10pm and eating dinner... when I'm done with that it'll be Netflix and hacking away on this in bed ;) > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to orphan Python 2
On Wed, 4 Apr 2018, 18:52 Kevin Fenzi, wrote: > On 04/04/2018 10:46 AM, Kevin Fenzi wrote: > > On 04/04/2018 09:21 AM, James Hogarth wrote: > > > > ...snip... > > > >> Can we please get some consistency here? > >> > >> I noted today that firewalld has dropped python2-firewall but of course > >> ansible isn't switching to py3 for the controller (and therefore local) > >> until F29 and not all python modules are py3 compatible yet... and of > >> course we ship firewalld as our firewall in fedora. > >> > >> This means that in F28 you can't just `yum install ansible > >> python-firewall` and do ansible localhost -m firewalld and have it work. > > > > Yeah, you would need to set ansible_python_interpreter for localhost, > > which you could add to your command line with -e... > > -e 'ansible_python_interpreter=/usr/bin/python3' > > Or, actually: > > yum install ansible-python3 python-firewall > ansible localhost -m firewalld > > (since ansible-python3 defaults to python3 for the control host/localhost) > > kevin > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org You're right that solves the issue for the control host, assuming everything else you are doing on there is fine with py3, but doesn't solve F28 target systems. It is also unexpected and not in and changes notes or common issues (yet) ... What happens to systems that currently have the library during an upgrade? It was just dropped from the spec (As many will be) rather than formally retired so it's not added to the "this is dead" super obsoleting package. Even if we don't get a change per library (which I agree would be too much) can we please get something clear for the F28 (and later F29) release ... we should be able to quickly generate it with dnf list > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to orphan Python 2
On Wed, 2018-04-04 at 10:51 -0700, Kevin Fenzi wrote: > On 04/04/2018 10:46 AM, Kevin Fenzi wrote: > > On 04/04/2018 09:21 AM, James Hogarth wrote: > > > > ...snip... > > > > > Can we please get some consistency here? > > > > > > I noted today that firewalld has dropped python2-firewall but of course > > > ansible isn't switching to py3 for the controller (and therefore local) > > > until F29 and not all python modules are py3 compatible yet... and of > > > course we ship firewalld as our firewall in fedora. > > > > > > This means that in F28 you can't just `yum install ansible > > > python-firewall` and do ansible localhost -m firewalld and have it work. > > > > Yeah, you would need to set ansible_python_interpreter for localhost, > > which you could add to your command line with -e... > > -e 'ansible_python_interpreter=/usr/bin/python3' > > Or, actually: > > yum install ansible-python3 python-firewall > ansible localhost -m firewalld > > (since ansible-python3 defaults to python3 for the control host/localhost) This rather begs the question of whether there are any modules which only work *with python 2*, though... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Notifications app is incomprehensible
Chuck Anderson wrote: > Is there a training video to explain how to use Fedora Notifications? > It is utterly incomprehensible and uses "cute" phrases like "Party > Perished" and "tabula rasa" that fail to help the user understand how > to use it. "tabula rasa" (literally "wiped table") is Latin for "restarting from scratch". And that's what the "Party Perished" option does, it deletes ALL customizations and resets everything to the default. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On Wed, 2018-04-04 at 17:55 +0200, Mattia Verga wrote: > Il 04/04/2018 17:26, Randy Barlow ha scritto: > > Another thought on this topic: > > > > It's probably a lot of work to maintain OwnCloud and NextCloud, and it > > sounds like a lot of people have moved to NextCloud or intend to in the > > future. Would it help if we went ahead and retired OwnCloud so we could > > focus on just one of the two to reduce the burden? > > > > I'm in the "I use OwnCloud but intend to switch to NextCloud" camp myself. > > > > If there are OwnCloud users who do not want to switch to NextCloud, > > perhaps they could step in to maintain OwnCloud. > > ___ > > > > I never used OC or NC, so here are my two cents: both are painful to > package in Fedora, so why don't we ask upstream to make some changes > that would simplify our work (if there are any)? They don't want to. They (especially OC) are excessively uninterested in aiding downstream packaging, think it's a waste of time, and advise people to use their upstream deployment methods at every opportunity. This was one major factor in me abandoning efforts to package OC. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On Wed, 2018-04-04 at 11:07 -0400, Randy Barlow wrote: > On 04/03/2018 07:02 PM, Adam Williamson wrote: > > On Tue, 2018-04-03 at 15:25 -0400, Randy Barlow wrote: > > > One question comes to mind though - won't this be a problem in the > > > future too? How can we guarantee that users can keep upgrading to 14, > > > 15, 16, etc. since Fedora doesn't keep in-between updates in the repos? > > When I maintained ownCloud, I just shipped upstream major version bumps > > as downstream stable updates. I wrote a wiki page explaining that the > > upstream ownCloud upgrade policy was the reason for doing this. It's > > still there: > > > > https://fedoraproject.org/wiki/OwnCloud#ownCloud_package_update_policy > > Hey Adam! > > I think that's a reasonable stance to take on the update policy, but it > doesn't quite address the specific problem I was getting at. I wasn't so > much worried about pushing major updates to our users as I was worried > about a user *missing* a major update while it was still in the repos. I > probably didn't express this clearly enough, but to expand my example: I used to keep a side repo with builds of each major version around to cover this scenario. Not sure if James does the same. I stopped using *cloud when I stopped maintaining it. Not worth the hassle. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On Wed, 2018-04-04 at 11:15 +0100, James Hogarth wrote: > On 4 April 2018 at 11:01, David Sommerseth wrote: > > On 03/04/18 21:00, Christian Glombek wrote: > > > I should probably add that the actual updater program has not been > > > shipped in the rpms thus far. Although I'm not sure how this affects > > > major updates, it is leading to problems elsewhere (i.e. people have to > > > uninstall some apps on v13 and re-install them on v13.0.1 for them to > > > work again). > > > > > > And how many people actually still run NC v10? > > > > I have two servers with NC v10 via EPEL 7 ... and getting increasingly > > concerned. > > > > EPEL can't be updated I think I used to just update it anyway. No-one shot me. :P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Web assets in Fedora
Hello, I've written a blog post about web assets in Fedora. Do you bundle third-party libraries/frameworks like jQuery, Bootstrap or Patternfly into your project and commit them to the git repository? There is a much better solution how to do it. If you are interested, please read the article http://frostyx.cz/posts/web-assets-in-fedora Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On Wed, Apr 4, 2018 at 2:36 PM Przemek Klosowski
wrote:
> On 04/04/2018 01:59 PM, Stephen Gallagher wrote:
> > The short version is that Modules *are* distribution packages. They're
> > just distribution packages that allow you to pick which major release
> > stream you want to stay on. We also have a distribution-level defaults
> > setup that allows you to pick one stream from the module and call that
> > the "default" for a particular Fedora release. Once that stream is so
> > marked, it just shows up automatically in DNF identically to the way
> > that traditional distribution RPMs do today. So let's say that in
> > Fedora 28 you make PHP into a module with the stream "7.2". We mark
> > that as the default. People can then `dnf install php` exactly as they
> > always could; the only thing they might see different would be the
> > %{release} tag of the RPM.
> >
> > Now, let's assume that PHP upstream decided to release 8.0 next month.
> > Fedora 29 would probably use that as its default module and would
> > package the same way as the above. *However*, you now also have the
> > opportunity to mark the module as being available for both F28 and F29
> > and the Module Build Service would produce it for both. And now users
> > of Fedora 28 can opt in to 8.0 before F29 is released if they want to.
> > And the reverse is true as well: when upgrading to Fedora 29, users
> > can opt to keep their version of PHP on 7.2 to continue supporting
> > their application.
> >
> This is cool---so what command do you use to choose PHP 8.0 in F28? and
> how do you choose to stay on 7.2 in F29?
>
>
On F28
`dnf install php:8/server` (Assuming there's a profile called "server" with
the packages one would need to use PHP in a server context)
On F29, if you have the php:7 module enabled in F28, an upgrade will not
switch this on you. If it's a clean install:
`dnf install php:7/server`
(Note: I don't know if PHP is backwards-compatible between minor versions;
If it's not, then it would probably be php:7.2 and php:8.0 instead)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On 04/04/2018 01:59 PM, Stephen Gallagher wrote:
The short version is that Modules *are* distribution packages. They're
just distribution packages that allow you to pick which major release
stream you want to stay on. We also have a distribution-level defaults
setup that allows you to pick one stream from the module and call that
the "default" for a particular Fedora release. Once that stream is so
marked, it just shows up automatically in DNF identically to the way
that traditional distribution RPMs do today. So let's say that in
Fedora 28 you make PHP into a module with the stream "7.2". We mark
that as the default. People can then `dnf install php` exactly as they
always could; the only thing they might see different would be the
%{release} tag of the RPM.
Now, let's assume that PHP upstream decided to release 8.0 next month.
Fedora 29 would probably use that as its default module and would
package the same way as the above. *However*, you now also have the
opportunity to mark the module as being available for both F28 and F29
and the Module Build Service would produce it for both. And now users
of Fedora 28 can opt in to 8.0 before F29 is released if they want to.
And the reverse is true as well: when upgrading to Fedora 29, users
can opt to keep their version of PHP on 7.2 to continue supporting
their application.
This is cool---so what command do you use to choose PHP 8.0 in F28? and
how do you choose to stay on 7.2 in F29?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: What to do when test gating in bodhi fails (no test results found)?
On 04/04/2018 10:39 AM, Randy Barlow wrote: Infra is still in a freeze (we will probably lift it sometime today). I can't personally take care of the ticket because I don't have access to create the necessary token. I also suspect the admins will be too busy to do this this week, because they are doing a mass update/reboot cycle, though that's just speculation on my part. Sounds good. I apologize. I think it was a mistake to enable gating in Bodhi when things were this rough. Some of it we didn't know about when the enabling decision was made. Sometimes I consider raising the issue with FESCo to see if we should turn it off until some criteria are met. I'm not sure what the full list of criteria would be, but having this button could be a start. If you feel strongly about it, feel free to submit a FESCo ticket to see what they think. I believe the enablement might have been a Fedora Council objective, but I'm not sure. https://pagure.io/fesco/issue/1872 I would welcome automated tests, but it is a little rough right now. Thanks, Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On Wed, Apr 4, 2018 at 12:59 PM Reindl Harald
wrote:
>
>
> Am 04.04.2018 um 17:36 schrieb Stephen Gallagher:
> > Hopefully this will become easier once we get the PHP maintainers to
> > move over to building Fedora Modules. Then we can decouple the PHP
> > updates from the Fedora release and we can tie the NextCloud streams to
> > a known-working PHP stream
>
> thanks god i biuld the PHP stack for a decade on my own - go away with
> the "modules and atomic only attitude" - or at least don't compromise
> parts of Fedora which i still prefer as distribution packages - that
> won't change and before it changes 40 machines are moved to a different
> distribution
>
> OK, I'm going to try to translate this, because it wasn't altogether
coherent.
I *suspect* you're confusing the version of Modularity that we're shipping
in Fedora 28 Beta with the one we prototyped and abandoned during the
Fedora 26 and 27 cycles.
The short version is that Modules *are* distribution packages. They're just
distribution packages that allow you to pick which major release stream you
want to stay on. We also have a distribution-level defaults setup that
allows you to pick one stream from the module and call that the "default"
for a particular Fedora release. Once that stream is so marked, it just
shows up automatically in DNF identically to the way that traditional
distribution RPMs do today. So let's say that in Fedora 28 you make PHP
into a module with the stream "7.2". We mark that as the default. People
can then `dnf install php` exactly as they always could; the only thing
they might see different would be the %{release} tag of the RPM.
Now, let's assume that PHP upstream decided to release 8.0 next month.
Fedora 29 would probably use that as its default module and would package
the same way as the above. *However*, you now also have the opportunity to
mark the module as being available for both F28 and F29 and the Module
Build Service would produce it for both. And now users of Fedora 28 can opt
in to 8.0 before F29 is released if they want to. And the reverse is true
as well: when upgrading to Fedora 29, users can opt to keep their version
of PHP on 7.2 to continue supporting their application.
So, to recap, packaging as modules means you can avoid people complaining
about
1) "The version in Fedora is too old! I want the latest one!"
2) "I upgraded to the new Fedora release and my application stopped
working!"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to orphan Python 2
On 04/04/2018 10:46 AM, Kevin Fenzi wrote: > On 04/04/2018 09:21 AM, James Hogarth wrote: > > ...snip... > >> Can we please get some consistency here? >> >> I noted today that firewalld has dropped python2-firewall but of course >> ansible isn't switching to py3 for the controller (and therefore local) >> until F29 and not all python modules are py3 compatible yet... and of >> course we ship firewalld as our firewall in fedora. >> >> This means that in F28 you can't just `yum install ansible >> python-firewall` and do ansible localhost -m firewalld and have it work. > > Yeah, you would need to set ansible_python_interpreter for localhost, > which you could add to your command line with -e... > -e 'ansible_python_interpreter=/usr/bin/python3' Or, actually: yum install ansible-python3 python-firewall ansible localhost -m firewalld (since ansible-python3 defaults to python3 for the control host/localhost) kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On Wed, Apr 4, 2018 at 12:05 PM James Hogarth wrote: > On Wed, 4 Apr 2018, 16:37 Stephen Gallagher, wrote: > >> >> >> On Wed, Apr 4, 2018 at 11:34 AM James Hogarth >> wrote: >> >>> >>> >>> On Wed, 4 Apr 2018, 15:59 Reindl Harald, wrote: >>> Am 04.04.2018 um 16:51 schrieb James Hogarth: > Last bit to debug before I can start testing an update of OC and NC is > why my automated setup explodes with: > > PHP Fatal error: Declaration of > OC\\Files\\Storage\\Local::copyFromStorage(OCP\\Files\\Storage > $sourceStorage, $sourceInternalPath, $targetInternalPath) must be > compatible with > OC\\Files\\Storage\\Common::copyFromStorage(OCP\\Files\\Storage > $sourceStorage, $sourceInternalPath, $targetInternalPath, > $preserveMtime = false) in > /usr/share/owncloud/lib/private/Files/Storage/Local.php on line 42" because "$preserveMtime" is missing in one declaration and you must have missed 1.5 years of PHP 7.0/7.1/7.2 "Declaration of ** must be compatible with **" is pretty clear and nothing new, that was even a warning with PHP5 on a proper setup with error_reporting = E_ALL for many years >>> >>> Yes the error is clear... the fixes to get this working are suddenly >>> nontrivial when I need to test a bunch of stuff in spare minutes between >>> $realjob tasks. >>> >>> Keep in mind this is not my code... this is owncloud code that I'll need >>> to write maintainer patches for to ensure it works on F27 and F28 ... at >>> times this means backporting changes ... especially where major php version >>> changes are concerned. >>> >>> This isn't usual - indeed at a Fedora release that has a major PHP >>> update much of my time will be spent on tackling issues like these. >>> >>> I expect to spend 3-4 hours in bed tonight into the wee hours of the >>> morning getting the basics in place so the current version can be safely >>> installed on F28 and still run on F27 for both owncloud and nextcloud ... >>> and then we can look to the major updates. >>> >>> >> Hopefully this will become easier once we get the PHP maintainers to move >> over to building Fedora Modules. Then we can decouple the PHP updates from >> the Fedora release and we can tie the NextCloud streams to a known-working >> PHP stream. >> > ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > Haha poor Remi will get to do even more php testing ;) > > Though to be fair he already does a lot of that with his own repos and > multiple php versions there. > > Well, the idea is that it will be possible to build the same stack for multiple Fedora releases at the same time and then just pick which stream is the "default" for the release, which will just simply appear to end-users much the same way that it does today as a standard package in an RPM repository. > The modular server release was frankly a disaster... and we all know it. > I suspect you're thinking of the original design which was scrapped. I'm referring to the current approach that we just shipped in Fedora 28 that is purely add-on to the traditional deployment. Please don't confuse the two. > > But lessons were learned which is of course important. > > Not just learned, but fixes implemented! > I'm honestly not sure how much that will really simplify maintenance of > this... or what the path from standard fedora rpm to this would be for > someone. > > As far as the path from standard RPM to modules, as long as we are mindful of which module stream is default (or explicitly selected), then from an end-user perspective it'll just look like a standard DNF update. Frankly I fear it'll actually increase my test matrix potentially (standard > plus modular) ... > > Well, given what I've read in this thread, it seems to me that we can actually reduce your matrix significantly. 1) You wouldn't need "standard" as long as you identified a module stream to be the default for the release. That stream will just show up to DNF as if it was "standard". 2) If both this and PHP use modules, NC can declare that it requires PHP e.g. 8.5 for runtime and it will always stick to that, so you can avoid having to move to a newer PHP base until upstream supports it. With this in mind, I think it would be a lot easier to maintain it. Then the upgrade instructions would basically become: ``` dnf module enable owncloud:N+1 ``` ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 28 compose report: 20180404.n.0 changes
OLD: Fedora-28-20180403.n.0 NEW: Fedora-28-20180404.n.0 = SUMMARY = Added images:4 Dropped images: 2 Added packages: 9 Dropped packages:1 Upgraded packages: 42 Downgraded packages: 0 Size of added packages: 841.58 KiB Size of dropped packages:326.34 KiB Size of upgraded packages: 1.76 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 62.77 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: AtomicHost vagrant-libvirt x86_64 Path: AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-28-20180404.n.0.x86_64.vagrant-libvirt.box Image: AtomicHost qcow2 aarch64 Path: AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180404.n.0.aarch64.qcow2 Image: AtomicHost raw-xz aarch64 Path: AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180404.n.0.aarch64.raw.xz Image: AtomicHost vagrant-virtualbox x86_64 Path: AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-28-20180404.n.0.x86_64.vagrant-virtualbox.box = DROPPED IMAGES = Image: Workstation raw-xz aarch64 Path: Workstation/aarch64/images/Fedora-Workstation-28-20180403.n.0.aarch64.raw.xz Image: Container_Minimal_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Minimal-Base-28-20180403.n.0.aarch64.tar.xz = ADDED PACKAGES = Package: container-exception-logger-1.0.2-1.fc28 Summary: Logging from a container to a host RPMs:container-exception-logger Size:176.11 KiB Package: php-mock-integration2-2.0.0-2.fc28 Summary: Integration package for PHP-Mock RPMs:php-mock-integration2 Size:10.36 KiB Package: php-mock-phpunit2-2.1.0-1.fc28 Summary: Mock built-in PHP functions with PHPUnit. RPMs:php-mock-phpunit2 Size:13.66 KiB Package: php-mock2-2.0.0-2.fc28 Summary: PHP-Mock can mock built-in PHP functions RPMs:php-mock2 Size:31.15 KiB Package: php-nikic-php-parser4-4.0.1-1.fc28 Summary: A PHP parser written in PHP - version 4 RPMs:php-nikic-php-parser4 Size:140.39 KiB Package: python-social-auth-app-flask-1.0.0-1.fc28 Summary: The Flask app component of python-social-auth RPMs:python3-social-auth-app-flask Size:18.70 KiB Package: python-social-auth-app-flask-sqlalchemy-1.0.1-1.fc28 Summary: The Flask app component of python-social-auth with SQLAlchemy integration RPMs:python3-social-auth-app-flask-sqlalchemy Size:15.27 KiB Package: python-social-auth-core-1.7.0-1.fc28 Summary: The core component of the python-social-auth ecosystem RPMs:python3-social-auth-core Size:417.47 KiB Package: python-social-auth-storage-sqlalchemy-1.1.0-1.fc28 Summary: The SQLAlchemy storage component of python-social-auth RPMs:python3-social-auth-storage-sqlalchemy Size:18.48 KiB = DROPPED PACKAGES = Package: gnome-tweak-tool-3.27.3-3.fc28 Summary: A tool to customize advanced GNOME 3 options RPMs:gnome-tweak-tool Size:326.34 KiB = UPGRADED PACKAGES = Package: amarok-2.9.0-1.fc28 Old package: amarok-2.8.90-18.fc28 Summary: Media player RPMs: amarok amarok-doc amarok-libs amarok-utils Size: 93.66 MiB Size change: 1.21 MiB Changelog: * Wed Feb 28 2018 Rex Dieter - 2.8.90-19 - use %ldconfig_scriptlets, %_kf5_metainfodir, BR: gcc-c++ * Wed Mar 07 2018 Rex Dieter - 2.9.0-1 - amarok-2.9.0 Package: drupal7-7.58-1.fc28 Old package: drupal7-7.57-1.fc28 Summary: An open-source content-management platform RPMs: drupal7 drupal7-rpmbuild Size: 2.93 MiB Size change: 1.23 KiB Changelog: * Wed Mar 28 2018 Shawn Iwinski - 7.58-1 - Update to 7.58 (RHBZ #1561801 / SA-CORE-2018-002 / CVE-2018-7600) Package: gap-pkg-guava-3.14-1.fc28 Old package: gap-pkg-guava-3.13.1-7.fc28 Summary: Computing with error-correcting codes RPMs: gap-pkg-guava Size: 11.95 MiB Size change: 67.46 KiB Changelog: * Thu Mar 29 2018 Jerry James - 3.14-1 - New upstream version - Drop upstreamed -bibtex patch Package: gnome-shell-extension-no-topleft-hot-corner-17.0-1.fc28 Old package: gnome-shell-extension-no-topleft-hot-corner-16.0-2.fc28 Summary: Disable the "hot corner" in the top-left of GNOME Shell RPMs: gnome-shell-extension-no-topleft-hot-corner Size: 17.52 KiB Size change: 240 B Changelog: * Tue Mar 27 2018 Andrew Toskin - 17.0-1 - Bump to upstream version 17.0, which assures compatibility with the upcoming GNOME 3.28 release. Package: golang-github-davecgh-go-spew-1.1.0-1.fc28 Old package: golang-github-davecgh-go-spew-0-0.15.git6d21280.fc28 Summary: Deep pretty printer for Go data structures to aid in debug RPMs: golang-github-davecgh-go-spew-devel Dropped RPMs: golang-github-davecgh-go-spew-unit-test Size: 41.49 KiB Size change: -152.67 KiB Changelog: * Wed Feb 28 2018 Jan Chaloupka - 0-0.16.20161107git6d21280 - Autogenerate some parts using the new macros * Mon Mar 26 2018 Robert-Andr?? Mauchin - 1.1.0-1 -
Re: Intent to orphan Python 2
On 04/04/2018 09:21 AM, James Hogarth wrote: ...snip... > Can we please get some consistency here? > > I noted today that firewalld has dropped python2-firewall but of course > ansible isn't switching to py3 for the controller (and therefore local) > until F29 and not all python modules are py3 compatible yet... and of > course we ship firewalld as our firewall in fedora. > > This means that in F28 you can't just `yum install ansible > python-firewall` and do ansible localhost -m firewalld and have it work. Yeah, you would need to set ansible_python_interpreter for localhost, which you could add to your command line with -e... -e 'ansible_python_interpreter=/usr/bin/python3' > Worse is if you bump into a module not ported yet and then you have a split > of python versions and playbooks required. Yeah, thats bad, but if there's things that are only python2 as of now, really the ansible module/you should switch them to some python3 alternative. > Naturally there's no technical reason to drop the library in F28 and > there's no Change filed for it. Yeah, I guess the only alternative though would be to try dropping them all at once. :( > We at least need a "common bugs" with all the python2-* libraries being > dropped in F28 and really they shouldn't be going without a Change. > > For a "soft despondency" like firewalld I'd argue that it shouldn't drop > until F29 when ansible goes py3 by default (it has a Change filed to that > effect). Well, yes, but that doesn't really tell the entire story, because thats just the control host. You can continue to use python2 on targets. > To be clear I'm 100% comfortable with python2 being dropped in the proposed > timescale... but let's do it sensibly and not have it surprise people. Yeah, a list/release note would be indeed welcome... kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On 04/04/2018 07:51 AM, James Hogarth wrote: ...snip... > Today I've spent time between $realwork getting my ansible plays > updated to handle F28 (thanks for dropping python2-* early guys!) and > have been in contact with lorbus (thanks for stepping up). Note that if you mean ansible dropping python2 in F28, thats not the case. If you mean some other package dropping pyhon2 that an ansible module you use needs you can set ansible to use python3 for that target. If you want ansible to use python3 on the control host in f28, you can just install ansible-python3 (in f29+ it will default to python3). For targets, set ansible_python_interpreter to which you want to use. See http://docs.ansible.com/ansible/latest/reference_appendices/python_3_support.html for more info. kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Intent to orphan Python 2
On Mon, 26 Mar 2018, 10:59 Petr Viktorin, wrote: > On 03/24/18 15:28, Kevin Kofler wrote: > > Petr Viktorin wrote: > >> As with any orphaning, that leaves two options: > >> - someone else agrees now to take over in 2020 (keeping in mind this is > >> a security-critical package and will be abandoned upstream), or > > > > IMHO, this is clearly the right thing to do. I have been doing security > > backports for qt3 and kdelibs3 for years, and now also qt 4 and kdelibs > 4. > > It is not an unreasonable amount of work, though to be very clear I will > NOT > > be the one to do this for Python 2, somebody experienced with and > interested > > in Python should do it. > > And if you read the original mail to the end, you'll find that our > position is not as black-and-white as it might look from the Subject line. > As Python SIG we maintain old Python versions like 2.6 or 3.3 *today* – > but just for developers who need to test backwards compatibility of > their upstream libraries; we don't want to see them used as a base for > Fedora packages. Why? To make sure Fedora packages work with modern > Python, and to have only one time-sensitive place to concentrate on when > a critical security fix comes. We want to put Python 2.7 in the same > situation. > > Part of the reason to start dropping Python 2 packages now is to figure > out which packages can do it now and which ones will need additional > help or coordination in the next few years. > > As I wrote in the beginning of the e-mail, we'd rather go out and change > the packaging guidelines to say "please drop your unneeded python2 > subpackages, or let us drop them for you". (Note the word *unneeded*.) > That would make a nice a simple message, and in effect it would give you > the same options you have now. > But it turns out we can't say just that (for good reasons [0]), so we're > explicitly mentioning your second option – "if you can manage the > transition better, come and do it instead of us". > I doubt anyone can – Python SIG is, by definition, the people > experienced with and interested in packaging Python in Fedora. And yes, > we'll do our best to manage things, with cooperation with interested > packagers. > > There's of course a third option – if you don't want to take over > *everything* but have ideas about how to do something better – > respecting that if you're asking someone to do more work, they might (or > might not) say no – then come over to Python SIG [1] and talk! > > And let me mention this one explicitly: expecting us to maintain Python > 2 *is* implicitly asking us to do work. It's not necessarily bad per se, > but don't complain if we ask you to do some work in return. > We'll be glad to help anyone who respects that. > > > [0] https://pagure.io/packaging-committee/issue/753 > [1] https://fedoraproject.org/wiki/SIGs/Python > > > > Especially for the first couple years, it will be possible to just borrow > > fixes from other distros, in particular RHEL/CentOS. As was pointed out > > elsewhere in this thread, EL7 ships Python 2.7 and should be supported > until > > 2024. (That said, RHEL typically only fixes the really critical issues. > My > > experience with qt3 and kdelibs3 is that RHEL was not always proactive in > > backporting security fixes and sometimes even ended up picking up my > Fedora > > fix, weeks later. But there are also other distros around.) > > > > Kevin Kofler > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org Can we please get some consistency here? I noted today that firewalld has dropped python2-firewall but of course ansible isn't switching to py3 for the controller (and therefore local) until F29 and not all python modules are py3 compatible yet... and of course we ship firewalld as our firewall in fedora. This means that in F28 you can't just `yum install ansible python-firewall` and do ansible localhost -m firewalld and have it work. Worse is if you bump into a module not ported yet and then you have a split of python versions and playbooks required. Naturally there's no technical reason to drop the library in F28 and there's no Change filed for it. We at least need a "common bugs" with all the python2-* libraries being dropped in F28 and really they shouldn't be going without a Change. For a "soft despondency" like firewalld I'd argue that it shouldn't drop until F29 when ansible goes py3 by default (it has a Change filed to that effect). To be clear I'm 100% comfortable with python2 being dropped in the proposed timescale... but let's do it sensibly and not have it surprise people. > ___ devel mailing list -- devel@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On Wed, 4 Apr 2018, 16:37 Stephen Gallagher, wrote: > > > On Wed, Apr 4, 2018 at 11:34 AM James Hogarth > wrote: > >> >> >> On Wed, 4 Apr 2018, 15:59 Reindl Harald, wrote: >> >>> >>> >>> Am 04.04.2018 um 16:51 schrieb James Hogarth: >>> > Last bit to debug before I can start testing an update of OC and NC is >>> > why my automated setup explodes with: >>> > >>> > PHP Fatal error: Declaration of >>> > OC\\Files\\Storage\\Local::copyFromStorage(OCP\\Files\\Storage >>> > $sourceStorage, $sourceInternalPath, $targetInternalPath) must be >>> > compatible with >>> > OC\\Files\\Storage\\Common::copyFromStorage(OCP\\Files\\Storage >>> > $sourceStorage, $sourceInternalPath, $targetInternalPath, >>> > $preserveMtime = false) in >>> > /usr/share/owncloud/lib/private/Files/Storage/Local.php on line 42" >>> >>> because "$preserveMtime" is missing in one declaration and you must have >>> missed 1.5 years of PHP 7.0/7.1/7.2 >>> >>> "Declaration of ** must be compatible with **" is pretty clear and >>> nothing new, that was even a warning with PHP5 on a proper setup with >>> error_reporting = E_ALL for many years >>> >> >> Yes the error is clear... the fixes to get this working are suddenly >> nontrivial when I need to test a bunch of stuff in spare minutes between >> $realjob tasks. >> >> Keep in mind this is not my code... this is owncloud code that I'll need >> to write maintainer patches for to ensure it works on F27 and F28 ... at >> times this means backporting changes ... especially where major php version >> changes are concerned. >> >> This isn't usual - indeed at a Fedora release that has a major PHP >> update much of my time will be spent on tackling issues like these. >> >> I expect to spend 3-4 hours in bed tonight into the wee hours of the >> morning getting the basics in place so the current version can be safely >> installed on F28 and still run on F27 for both owncloud and nextcloud ... >> and then we can look to the major updates. >> >> > Hopefully this will become easier once we get the PHP maintainers to move > over to building Fedora Modules. Then we can decouple the PHP updates from > the Fedora release and we can tie the NextCloud streams to a known-working > PHP stream. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org Haha poor Remi will get to do even more php testing ;) Though to be fair he already does a lot of that with his own repos and multiple php versions there. The modular server release was frankly a disaster... and we all know it. But lessons were learned which is of course important. I'm honestly not sure how much that will really simplify maintenance of this... or what the path from standard fedora rpm to this would be for someone. Frankly I fear it'll actually increase my test matrix potentially (standard plus modular) ... > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On Wed, 4 Apr 2018, 16:51 William Moreno, wrote: > > > 2018-04-04 9:43 GMT-06:00 Randy Barlow : > >> On 04/04/2018 11:37 AM, William Moreno wrote: >> > A well documented setp can help users to move from OC to NC. >> >> James actually wrote a nice blog post about migration: >> >> https://www.hogarthuk.com/?q=node/17 >> >> > James are you ok with the idea to keep just NC in Fedora? I there is > people than still want OC maybe then can take care or maintain it. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org We'll see Let's get both updated and then we can decide from there. I will provide a migration path though... that is absolutely critical to my commitment to the users to not actively break things or leave anyone stranded. If I get continuing help once we're caught up it'll be much easier to keep both updated. For those that want to leap ahead, there will be COPR repos to do so... and that will simplify the updates needed in fedora itself. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
Il 04/04/2018 17:26, Randy Barlow ha scritto: Another thought on this topic: It's probably a lot of work to maintain OwnCloud and NextCloud, and it sounds like a lot of people have moved to NextCloud or intend to in the future. Would it help if we went ahead and retired OwnCloud so we could focus on just one of the two to reduce the burden? I'm in the "I use OwnCloud but intend to switch to NextCloud" camp myself. If there are OwnCloud users who do not want to switch to NextCloud, perhaps they could step in to maintain OwnCloud. ___ I never used OC or NC, so here are my two cents: both are painful to package in Fedora, so why don't we ask upstream to make some changes that would simplify our work (if there are any)? If one of them can work with us to get their software well supported in Fedora, then we should choose and focus on that software. If both are not willing to help us in our packaging effort, simply choose one of them and drop the other. I can see OC provides their own Fedora repository, so why bother? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[Bug 1560548] perl-Test-PostgreSQL-1.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1560548 --- Comment #8 from Fedora Update System --- perl-Test-PostgreSQL-1.25-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
[Bug 1560768] perl-Authen-SCRAM-0.009 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1560768 --- Comment #4 from Fedora Update System --- perl-Authen-SCRAM-0.009-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
2018-04-04 9:43 GMT-06:00 Randy Barlow : > On 04/04/2018 11:37 AM, William Moreno wrote: > > A well documented setp can help users to move from OC to NC. > > James actually wrote a nice blog post about migration: > > https://www.hogarthuk.com/?q=node/17 > > James are you ok with the idea to keep just NC in Fedora? I there is people than still want OC maybe then can take care or maintain it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Local test VMs (was: Status of OwnCloud/NextCloud)
On Wed, 4 Apr 2018, 16:11 Tim Landscheidt, wrote:
> James Hogarth wrote:
>
> > […]
>
> > FIrst thing when I fired up my test harness was that F28 has changed,
> > and thus broken, kickstart for the user option compared to a standard
> > minimal that worked going back to F22 and EL7 so that had to be
> > debugged and fixed ... done
>
> > Next things is the ansible that I use to test ... well the lovely
> > folks jumping the gun on dropping python2-* packages is making life
> > painful since ansible still uses python2 by default and not everything
> > support python3 yet. There is no python2-firewall anymore for the
> > ansible firewalld module ... yay another silly thing to work around!
>
> > […]
>
> BTW, it would be very nice if there was (maintained) docu-
> mentation on how to generate Fedora VMs and for example use
> Ansible to configure complex interactive test setups.
> James's article
> (https://fedoramagazine.org/day-life-fedora-packager/) is
> mouth-watering, but lacking detail and probably outdated by
> now.
>
> I'm sure that many Fedora packagers have their own ("obvi-
> ous") solutions, but having something general could lower
> the bar for new packagers who do not want to dive deep into
> all the minutiae just to test a release.
>
> Tim
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Would it surprise you to know that it is actually still valid and not
really outdated? ;)
If you'd like me to write something more detailed I'd be happy to do so...
after we have oC/nC updated ;)
There is a bunch of relevant material on my blog you may be interested in
though that goes into more detail on the process of the test environment...
but didn't feel relevant for the magazine...
Start with building of rpms:
https://www.hogarthuk.com/?q=node/11
Then move on to configuring your system for dynamic ansible inventory of
libvirt guests:
https://www.hogarthuk.com/?q=node/12
This one covers my vmcreate (to make a new guest entirely), vmprep (to
prepare a template for cloning) and vmclone (guess what this does? )
scripts to make generating test instances easier...
https://www.hogarthuk.com/?q=node/13
This reminds me I really need to finish and publish my pending stuff...
sudo mktime?
Feel free to contact me about any of this or the scripts I have on github
if you want to build something
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Local test VMs
On 04/04/2018 05:11 PM, Tim Landscheidt wrote:
>
> BTW, it would be very nice if there was (maintained) docu-
> mentation on how to generate Fedora VMs and for example use
> Ansible to configure complex interactive test setups.
> James's article
> (https://fedoramagazine.org/day-life-fedora-packager/) is
> mouth-watering, but lacking detail and probably outdated by
> now.
It turns out there is such a way! It even uses Ansible. :)
There's a fairly recent Fedora Magazine Article about CI:
https://fedoramagazine.org/continuous-integration-fedora/
> I'm sure that many Fedora packagers have their own ("obvi-
> ous") solutions, but having something general could lower
> the bar for new packagers who do not want to dive deep into
> all the minutiae just to test a release.
We started setting up the Standard Test Interface in Fedora to support a
lot of the existing "obvious" solutions and provide best practice
implementations and support for a lot of things that packagers may want
the infrastructure to handle:
https://fedoraproject.org/wiki/CI
Our pipeline to run tests for all packages (non Atomic) should be in
production soon, in a matter of weeks. Until then, it's still fairly
straight forward to test a package locally.
I invite you to take a look at the material and reach out to us on IRC
(contact info on the linked page, #fedora-ci on freenode or via mailing
list) with questions.
Thank you
Dominik
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On 04/04/2018 11:37 AM, William Moreno wrote: > A well documented setp can help users to move from OC to NC. James actually wrote a nice blog post about migration: https://www.hogarthuk.com/?q=node/17 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: What to do when test gating in bodhi fails (no test results found)?
On 04/04/2018 09:15 AM, Michael Cronenworth wrote: > It is now Wednesday. Could this be implemented now? Infra is still in a freeze (we will probably lift it sometime today). I can't personally take care of the ticket because I don't have access to create the necessary token. I also suspect the admins will be too busy to do this this week, because they are doing a mass update/reboot cycle, though that's just speculation on my part. > I've had to submit waivers, again, for a new version of Wine. I > submitted the updates 24 hours ago. Waivers submitted 24 hours ago. Test > gating is still showing up as a failure / can't push. I'm having to > resubmit the updates. I apologize. I think it was a mistake to enable gating in Bodhi when things were this rough. Some of it we didn't know about when the enabling decision was made. Sometimes I consider raising the issue with FESCo to see if we should turn it off until some criteria are met. I'm not sure what the full list of criteria would be, but having this button could be a start. If you feel strongly about it, feel free to submit a FESCo ticket to see what they think. I believe the enablement might have been a Fedora Council objective, but I'm not sure. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
2018-04-04 8:51 GMT-06:00 James Hogarth : > On 4 April 2018 at 14:48, William Moreno > wrote: > > > > > > 2018-04-03 13:11 GMT-06:00 Stephen Gallagher : > >> > >> > >> > >> On Tue, Apr 3, 2018 at 3:01 PM Christian Glombek > > >> wrote: > >>> > >>> I should probably add that the actual updater program has not been > >>> shipped in the rpms thus far. Although I'm not sure how this affects > major > >>> updates, it is leading to problems elsewhere (i.e. people have to > uninstall > >>> some apps on v13 and re-install them on v13.0.1 for them to work > again). > >>> > >>> And how many people actually still run NC v10? > >> > >> > >> > >> Given the current status, I suggest you just ask FESCo to give you > >> permission to release 13.x without supporting upgrades from 10.x and > then > >> submit a Magazine article explaining the situation once 13.x is > landing. As > >> far as the bundling question; that's actually fair game these days as > long > >> as your packages have a virtual `Provides: bundled(packagename) = > ` > >> in the specfile so if we needed to locate packages for security issues, > it > >> can be done. So if you wanted to package the intermediate versions(*) > with > >> bundled libs to get people through the upgrade, that's an option too. > >> > >> > > +1 should be a nice changes for the F29 release. > > > > > To make it absolutely 100% clear this is totally 100% not going to > happen no. > > Today I've spent time between $realwork getting my ansible plays > updated to handle F28 (thanks for dropping python2-* early guys!) and > have been in contact with lorbus (thanks for stepping up). > > Last bit to debug before I can start testing an update of OC and NC is > why my automated setup explodes with: > > PHP Fatal error: Declaration of > OC\\Files\\Storage\\Local::copyFromStorage(OCP\\Files\\Storage > $sourceStorage, $sourceInternalPath, $targetInternalPath) must be > compatible with > OC\\Files\\Storage\\Common::copyFromStorage(OCP\\Files\\Storage > $sourceStorage, $sourceInternalPath, $targetInternalPath, > $preserveMtime = false) in > /usr/share/owncloud/lib/private/Files/Storage/Local.php on line 42", > > The roles I use for testing are here: https://github.com/hogarthj/test_vms > > I'll be pushing updates as I get fixes there > > I'll be adding repos here to start tracking the builds: > https://copr.fedorainfracloud.org/coprs/jhogarth/ > > Again, recognise what you'll be stepping up to, but if you are willing > help is very welcome. > > I do understand that mantain a package like OC and NC it is a lot of work, I know it is just a litle help in the path to get the update working but I did some review of missing depencies because was the only visible step to help to get the updated version of NC at that moment, but I am curios about somethings: 1. There is both OC and NC in repos, two packages, the double of works, It is irrational to keep just with one stream of the software? A well documented setp can help users to move from OC to NC. 2. There is some work done to get NC 13 on Fedora, I apreciate that you want to provide a clean path to current users to update, but it is irratational to thing in ship the last version of NC to users and have a very good docs about it? I see that you have problems with testing the update, is that ansible playbook available in some public repo? I can help to test, a NC/OC test day with a wiki with the test coverage can be a great way to get help in this and get feedback/help for users and I can help to test. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On Wed, Apr 4, 2018 at 11:34 AM James Hogarth wrote: > > > On Wed, 4 Apr 2018, 15:59 Reindl Harald, wrote: > >> >> >> Am 04.04.2018 um 16:51 schrieb James Hogarth: >> > Last bit to debug before I can start testing an update of OC and NC is >> > why my automated setup explodes with: >> > >> > PHP Fatal error: Declaration of >> > OC\\Files\\Storage\\Local::copyFromStorage(OCP\\Files\\Storage >> > $sourceStorage, $sourceInternalPath, $targetInternalPath) must be >> > compatible with >> > OC\\Files\\Storage\\Common::copyFromStorage(OCP\\Files\\Storage >> > $sourceStorage, $sourceInternalPath, $targetInternalPath, >> > $preserveMtime = false) in >> > /usr/share/owncloud/lib/private/Files/Storage/Local.php on line 42" >> >> because "$preserveMtime" is missing in one declaration and you must have >> missed 1.5 years of PHP 7.0/7.1/7.2 >> >> "Declaration of ** must be compatible with **" is pretty clear and >> nothing new, that was even a warning with PHP5 on a proper setup with >> error_reporting = E_ALL for many years >> > > Yes the error is clear... the fixes to get this working are suddenly > nontrivial when I need to test a bunch of stuff in spare minutes between > $realjob tasks. > > Keep in mind this is not my code... this is owncloud code that I'll need > to write maintainer patches for to ensure it works on F27 and F28 ... at > times this means backporting changes ... especially where major php version > changes are concerned. > > This isn't usual - indeed at a Fedora release that has a major PHP update > much of my time will be spent on tackling issues like these. > > I expect to spend 3-4 hours in bed tonight into the wee hours of the > morning getting the basics in place so the current version can be safely > installed on F28 and still run on F27 for both owncloud and nextcloud ... > and then we can look to the major updates. > > Hopefully this will become easier once we get the PHP maintainers to move over to building Fedora Modules. Then we can decouple the PHP updates from the Fedora release and we can tie the NextCloud streams to a known-working PHP stream. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On Wed, 4 Apr 2018, 16:27 Randy Barlow, wrote: > Another thought on this topic: > > It's probably a lot of work to maintain OwnCloud and NextCloud, and it > sounds like a lot of people have moved to NextCloud or intend to in the > future. Would it help if we went ahead and retired OwnCloud so we could > focus on just one of the two to reduce the burden? > > I'm in the "I use OwnCloud but intend to switch to NextCloud" camp myself. > > If there are OwnCloud users who do not want to switch to NextCloud, > perhaps they could step in to maintain OwnCloud. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org To quote you... "I use Owncloud but intend to switch to nextcloud" That intent goes all the way back to my blog post on how to migrate and writing up the tested documentation to do so... But there's nothing I do or need on there that actually requires migration... so it hasn't happened yet. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Notifications app is incomprehensible
On 04/03/2018 07:49 PM, Chuck Anderson wrote: > Is there a training video to explain how to use Fedora Notifications? > It is utterly incomprehensible and uses "cute" phrases like "Party > Perished" and "tabula rasa" that fail to help the user understand how > to use it. Unfortunately I don't know of anything like that. There seems to be some brief documentation about it here: https://apps.fedoraproject.org/notifications/about It also looks like jcline started some docs for it, but he has since moved on to work on a less important project (the kernel ☺ I don't see what we need a kernel for since everything is moving towards serverless [and we might as well also be diskless and networkless too!]) so that effort might be stalled for now: https://fmn.readthedocs.io/en/latest/ This would probably be a good place for contributions if anyone is inclined (or… jcline'd?) to help document it, because I agree that the app is pretty confusing: https://github.com/fedora-infra/fmn/tree/develop/docs ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On Wed, 4 Apr 2018, 15:59 Reindl Harald, wrote: > > > Am 04.04.2018 um 16:51 schrieb James Hogarth: > > Last bit to debug before I can start testing an update of OC and NC is > > why my automated setup explodes with: > > > > PHP Fatal error: Declaration of > > OC\\Files\\Storage\\Local::copyFromStorage(OCP\\Files\\Storage > > $sourceStorage, $sourceInternalPath, $targetInternalPath) must be > > compatible with > > OC\\Files\\Storage\\Common::copyFromStorage(OCP\\Files\\Storage > > $sourceStorage, $sourceInternalPath, $targetInternalPath, > > $preserveMtime = false) in > > /usr/share/owncloud/lib/private/Files/Storage/Local.php on line 42" > > because "$preserveMtime" is missing in one declaration and you must have > missed 1.5 years of PHP 7.0/7.1/7.2 > > "Declaration of ** must be compatible with **" is pretty clear and > nothing new, that was even a warning with PHP5 on a proper setup with > error_reporting = E_ALL for many years > Yes the error is clear... the fixes to get this working are suddenly nontrivial when I need to test a bunch of stuff in spare minutes between $realjob tasks. Keep in mind this is not my code... this is owncloud code that I'll need to write maintainer patches for to ensure it works on F27 and F28 ... at times this means backporting changes ... especially where major php version changes are concerned. This isn't usual - indeed at a Fedora release that has a major PHP update much of my time will be spent on tackling issues like these. I expect to spend 3-4 hours in bed tonight into the wee hours of the morning getting the basics in place so the current version can be safely installed on F28 and still run on F27 for both owncloud and nextcloud ... and then we can look to the major updates. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
Another thought on this topic: It's probably a lot of work to maintain OwnCloud and NextCloud, and it sounds like a lot of people have moved to NextCloud or intend to in the future. Would it help if we went ahead and retired OwnCloud so we could focus on just one of the two to reduce the burden? I'm in the "I use OwnCloud but intend to switch to NextCloud" camp myself. If there are OwnCloud users who do not want to switch to NextCloud, perhaps they could step in to maintain OwnCloud. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Unacceptable size increase to ALL live images in F28: Noto CJK Fonts
Akira TAGOH wrote: > of course if we can go ahead without any workaround on this, that would be > better though. FYI, the plan of the KDE SIG is to simply bump the target size of the image yet again. I do not like that approach, but I am not the one who decides (anymore – I used to de-facto maintain the KDE Live image for a while, but no longer). For a long-term solution: In principle, I think shipping a smaller font (optimized for size, by composing strokes instead of copy&pasting them, see e.g. WQY MicroHei) altogether rather than a subset of Noto would be a better approach (because it would avoid the user confusion and would also be even more compact), but unfortunately I don't know of any such font that is up to date and TC/J/K-friendly (WQY MicroHei is neither of those). (As was pointed out elsewhere in the thread, for the different SC/TC/J/K renderings, it should be technically possible to put them LOCL-tagged into the one font. WQY MicroHei is already a TTC font.) And I also don't think we really need all 3 of Sans, Serif and Mono. There are other scripts where we only ship one variant, too, and Sans is essentially monospaced for CJK anyway. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On 04/04/2018 06:08 AM, James Hogarth wrote: > How about emailing me and asking what you can do to help? > > I've really had no help on this (outside of Shawn and Remi getting > dependencies packaged on occasion) since I took this over from AdamW > way back. > > There's always lots of noise about "oh no OC isn't getting updates" > but never any actual help, or even empty offers for help usually. Hi James! I hope my post didn't sound like complaining to you - that wasn't my intent. My goal was to call attention to the problems in F28 (and F27 has issues to a lesser but still important extent) and to ask if anyone in the Fedora community can help. I really didn't intend to point fingers or place blame - I mean, you can certainly find lots of open tickets assigned to me that I haven't gotten to either. I also wanted to call attention to it before F28 stabilizes, because the current issues are pretty severe and I wanted to make sure Fedora takes some action before our users are affected (even if the action is to remove it from Fedora). My knowledge about PHP is pretty limited, and like you I also have a pretty full schedule and two large applications that I maintain, so I personally can't commit to help with this due to the combination of those two factors. > Honestly I'm tempted to just orphan both owncloud and nextcloud as > it's painful to maintain and it's a truly thankless task. I think this would be OK if you want to do that route, but it does sound like there are some volunteers who would be willing to get involved. I really appreciate the work you did to get us this far, so thank you for your contributions, and also congratulations on the new addition to your family ☺ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Local test VMs (was: Status of OwnCloud/NextCloud)
James Hogarth wrote:
> […]
> FIrst thing when I fired up my test harness was that F28 has changed,
> and thus broken, kickstart for the user option compared to a standard
> minimal that worked going back to F22 and EL7 so that had to be
> debugged and fixed ... done
> Next things is the ansible that I use to test ... well the lovely
> folks jumping the gun on dropping python2-* packages is making life
> painful since ansible still uses python2 by default and not everything
> support python3 yet. There is no python2-firewall anymore for the
> ansible firewalld module ... yay another silly thing to work around!
> […]
BTW, it would be very nice if there was (maintained) docu-
mentation on how to generate Fedora VMs and for example use
Ansible to configure complex interactive test setups.
James's article
(https://fedoramagazine.org/day-life-fedora-packager/) is
mouth-watering, but lacking detail and probably outdated by
now.
I'm sure that many Fedora packagers have their own ("obvi-
ous") solutions, but having something general could lower
the bar for new packagers who do not want to dive deep into
all the minutiae just to test a release.
Tim
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On 04/04/2018 09:48 AM, William Moreno wrote: > +1 should be a nice changes for the F29 release. Since OwnCloud is completely broken on F28 right now (not sure about NextCloud, but it might be as well), it could be nice to do for F28 as well. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On 04/03/2018 07:02 PM, Adam Williamson wrote: > On Tue, 2018-04-03 at 15:25 -0400, Randy Barlow wrote: >> One question comes to mind though - won't this be a problem in the >> future too? How can we guarantee that users can keep upgrading to 14, >> 15, 16, etc. since Fedora doesn't keep in-between updates in the repos? > When I maintained ownCloud, I just shipped upstream major version bumps > as downstream stable updates. I wrote a wiki page explaining that the > upstream ownCloud upgrade policy was the reason for doing this. It's > still there: > > https://fedoraproject.org/wiki/OwnCloud#ownCloud_package_update_policy Hey Adam! I think that's a reasonable stance to take on the update policy, but it doesn't quite address the specific problem I was getting at. I wasn't so much worried about pushing major updates to our users as I was worried about a user *missing* a major update while it was still in the repos. I probably didn't express this clearly enough, but to expand my example: Suppose: 0. Fedora 29 ships with NextCloud 14. 1. A user installs NextCloud 14. 2. Fedora 29 gets an update to NextCloud 15. 3. The user from #2 doesn't install this, for whatever reason. 4. Fedora 29 gets an update to NextCloud 16. NextCloud 15 is now no longer available in any repo. 5. The user from #2 now updates from NextCloud 14 to 16, which it sounds like will be a problem. Perhaps modularity is the answer here. Another suggestion I saw was to put the major version into the package name. So there could be nextcloud14, nextcloud15, and nextcloud16 source packages, but of course this is an extra burden on the maintainer for a package that already seems burdensome to maintain as is. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Practical use of fedabipkgdiff
On Wed, 2018-04-04 at 07:47 -0500, Richard Shaw wrote: > On Tue, Apr 3, 2018 at 2:01 PM, Sinny Kumari > wrote: > > As far as I am aware, right now fedabipkgdiff tool doesn't support > > ABI > > comparison against scratch build. I see this feature as a nice > > addition. > > > > One option is to download scratch build rpms locally and use > > "fedabipkgdiff > > --from fc29 path_to_local_rpm" command. Since this command works > > only on one > > rpm at a time, you can run iteratively on all desired packages. > > Well, I have a local mock build but still not user friendly... > > $ fedabipkgdiff -a --dso-only --from fc29 hamlib-3.2- > 1.fc29.x86_64.rpm > Found more than one debuginfo package in this directory. At the > moment, fedabipkgdiff is not able to deal with this case. > Please create two separate directories and put an RPM and its > ancillary debuginfo and devel RPMs in each directory. > > Thanks, > Richard Do you know the existence of fedabipkgdiff [1] and rfabipkgdiff [2]. The funny part (for me) is that both commands aren't in fedpkg or rfpkg . [1] rpm -qf /usr/bin/fedabipkgdiff libabigail-1.0-1.fc26.x86_64 [2] rpm -qf /usr/bin/rfabipkgdiff rpmfusion-packager-0.6.2-1.fc26.noarch Cheers, -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On 4 April 2018 at 14:48, William Moreno wrote: > > > 2018-04-03 13:11 GMT-06:00 Stephen Gallagher : >> >> >> >> On Tue, Apr 3, 2018 at 3:01 PM Christian Glombek >> wrote: >>> >>> I should probably add that the actual updater program has not been >>> shipped in the rpms thus far. Although I'm not sure how this affects major >>> updates, it is leading to problems elsewhere (i.e. people have to uninstall >>> some apps on v13 and re-install them on v13.0.1 for them to work again). >>> >>> And how many people actually still run NC v10? >> >> >> >> Given the current status, I suggest you just ask FESCo to give you >> permission to release 13.x without supporting upgrades from 10.x and then >> submit a Magazine article explaining the situation once 13.x is landing. As >> far as the bundling question; that's actually fair game these days as long >> as your packages have a virtual `Provides: bundled(packagename) = ` >> in the specfile so if we needed to locate packages for security issues, it >> can be done. So if you wanted to package the intermediate versions(*) with >> bundled libs to get people through the upgrade, that's an option too. >> >> > +1 should be a nice changes for the F29 release. > To make it absolutely 100% clear this is totally 100% not going to happen no. Today I've spent time between $realwork getting my ansible plays updated to handle F28 (thanks for dropping python2-* early guys!) and have been in contact with lorbus (thanks for stepping up). Last bit to debug before I can start testing an update of OC and NC is why my automated setup explodes with: PHP Fatal error: Declaration of OC\\Files\\Storage\\Local::copyFromStorage(OCP\\Files\\Storage $sourceStorage, $sourceInternalPath, $targetInternalPath) must be compatible with OC\\Files\\Storage\\Common::copyFromStorage(OCP\\Files\\Storage $sourceStorage, $sourceInternalPath, $targetInternalPath, $preserveMtime = false) in /usr/share/owncloud/lib/private/Files/Storage/Local.php on line 42", The roles I use for testing are here: https://github.com/hogarthj/test_vms I'll be pushing updates as I get fixes there I'll be adding repos here to start tracking the builds: https://copr.fedorainfracloud.org/coprs/jhogarth/ Again, recognise what you'll be stepping up to, but if you are willing help is very welcome. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
2018-04-03 13:11 GMT-06:00 Stephen Gallagher : > > > On Tue, Apr 3, 2018 at 3:01 PM Christian Glombek > wrote: > >> I should probably add that the actual updater program has not been >> shipped in the rpms thus far. Although I'm not sure how this affects major >> updates, it is leading to problems elsewhere (i.e. people have to uninstall >> some apps on v13 and re-install them on v13.0.1 for them to work again). >> >> And how many people actually still run NC v10? >> > > > Given the current status, I suggest you just ask FESCo to give you > permission to release 13.x without supporting upgrades from 10.x and then > submit a Magazine article explaining the situation once 13.x is landing. As > far as the bundling question; that's actually fair game these days as long > as your packages have a virtual `Provides: bundled(packagename) = > ` in the specfile so if we needed to locate packages for security > issues, it can be done. So if you wanted to package the intermediate > versions(*) with bundled libs to get people through the upgrade, that's an > option too. > > > +1 should be a nice changes for the F29 release. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: What to do when test gating in bodhi fails (no test results found)?
On 04/02/2018 10:25 AM, Randy Barlow wrote: I don't know if there is a way to know this right now, other than waiting up to 6 hours. Bodhi does actually have a UI to submit waivers (to avoid the CLI and the confusing data hunting), but it needs an auth token configured to allow it to talk to waiverdb[1] (Bodhi hides the waiverdb UI when it doesn't have a token to talk to waiverdb). Fedora infrastructure is currently in a freeze, so we cannot add that token at this time. The freeze should lift on Wednesday. It is now Wednesday. Could this be implemented now? I've had to submit waivers, again, for a new version of Wine. I submitted the updates 24 hours ago. Waivers submitted 24 hours ago. Test gating is still showing up as a failure / can't push. I'm having to resubmit the updates. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Practical use of fedabipkgdiff
On Tue, Apr 3, 2018 at 2:01 PM, Sinny Kumari wrote: > As far as I am aware, right now fedabipkgdiff tool doesn't support ABI > comparison against scratch build. I see this feature as a nice addition. > > One option is to download scratch build rpms locally and use "fedabipkgdiff > --from fc29 path_to_local_rpm" command. Since this command works only on > one > rpm at a time, you can run iteratively on all desired packages. > Well, I have a local mock build but still not user friendly... $ fedabipkgdiff -a --dso-only --from fc29 hamlib-3.2-1.fc29.x86_64.rpm Found more than one debuginfo package in this directory. At the moment, fedabipkgdiff is not able to deal with this case. Please create two separate directories and put an RPM and its ancillary debuginfo and devel RPMs in each directory. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Help Needed] Fedora Server's Mission and Goals
I'm going to extend this by a week and cancel tomorrow's Server SIG meeting. People have been very distracted with dealing with Beta blockers and we've extended this request to a wider audience (it got picked up by certain news sources). Let's give it a little more time to percolate. If you have thoughts, I'd really like to hear them. On Mon, Mar 26, 2018 at 8:04 AM Stephen Gallagher wrote: > Quick reminder to please send me your thoughts on this; I'll be collating > them tonight and sending them out for us to discuss tomorrow. > > > On Tue, Mar 20, 2018 at 4:58 PM Stephen Gallagher > wrote: > >> During today's Server SIG IRC meeting[1], we discussed plans for Fedora >> 29 and onwards. In particular, we've decided that we're probably going to >> retire the concept of "server roles" from our overall goals. Adam >> Williamson -- representing Fedora QA -- raised the point that the related >> release criteria and test goals come directly from the Fedora Server >> Product Requirements Document (PRD) [2]. He correctly pointed out that we >> should start by revising the PRD and have that filter down ultimately into >> the release criteria. >> >> Looking at the Fedora Wiki, the Fedora Server PRD is now over four years >> old and thus is ripe for an update. To that end, we're going to start with >> a brainstorming exercise to update our Mission Statement. The current >> statement reads: >> >> Fedora Server is a common base platform with "featured server roles" >> built on top of it. We commit to produce, test, and distribute these server >> roles. >> >> Clearly, this is no longer going to work for us, since we're planning to >> retire the server role concept. So what I'd like is this: If you are >> reading this, I'd like you to send me your view of what the >> purpose/goals/efforts of Fedora Server should be over the next 2-3 years >> (or even longer). I would ask that you send your thoughts directly to me, >> not as a reply on the list. This is so as not to influence anyone else's >> answers or to start a debate before the brainstorming is concluded. I will >> gather the responses and send them back out to the list as a complete set >> on Monday. The floodgates should then open to try to find the common >> elements and start turning them into an actionable strategy (the discussion >> will also continue at the Server SIG meeting on Tuesday). >> >> Once that discussion settles down, I will take the major points we come >> to agreement on and start putting together a draft of a new Products >> Requirement Document. We can then discuss and tweak the PRD up to the >> Fedora 29 System-Wide Change Proposal deadline, at which point the Server >> SIG will submit its F29 Changes to FESCo. >> >> Thank you all in advance for your help with this. >> >> >> [1] >> https://meetbot.fedoraproject.org/fedora-meeting-1/2018-03-20/serversig.2018-03-20-20.00.html >> [2] https://fedoraproject.org/wiki/Server/Product_Requirements_Document >> >> >> ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On 4 April 2018 at 11:01, David Sommerseth wrote: > On 03/04/18 21:00, Christian Glombek wrote: >> I should probably add that the actual updater program has not been shipped >> in the rpms thus far. Although I'm not sure how this affects major updates, >> it is leading to problems elsewhere (i.e. people have to uninstall some apps >> on v13 and re-install them on v13.0.1 for them to work again). >> >> And how many people actually still run NC v10? > > I have two servers with NC v10 via EPEL 7 ... and getting increasingly > concerned. > EPEL can't be updated and both owncloud and nextcloud upstreams are (understandably) hostile to the old PHP version in EL7 ... The EPEL policies forbid us from using SCL to get a newer PHP as well. EPEL will be retired as soon as I've pushed an update with an EOL notice - there is no upgrade path for EPEL packages. If you are running owncloud/nexcloud on CentOS then you either need to use their upstream packages or a container. Once I've got OC/NC back up to date I'll push on with the "official" Fedora container for them again. This article will be critical for you in migrating your install to get a current PHP on that EL7 system: https://www.hogarthuk.com/?q=node/15 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
On 4 April 2018 at 08:38, Benson Muite wrote: > >> >> So, I don't think we can update the package from 10 to 13, thus breaking >> all user installations. >> >> I see 2 possible way >> >> The classical one >> >> - create nextcloud11, nextcloud12 and nextcloud13 packages and also >> future versions, older can be removed when EOLed by upstream (so >> nextcloud + nextcloud10 removed in F29) >> >> The new one (F28+) >> >> - create a nextcloud module with 1 stream per version, following >> upstream life cycle >> >> >> Remi > > > First one seems a little easier, but modules look very promising. Any > experience testing this? If no next cloud apps are installed, mostly a > matter of changing location of data folder. If some Nextcloud apps are > installed, this is more difficult since apps do not always get updated. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org *COUGH* How about emailing me and asking what you can do to help? I've really had no help on this (outside of Shawn and Remi getting dependencies packaged on occasion) since I took this over from AdamW way back. There's always lots of noise about "oh no OC isn't getting updates" but never any actual help, or even empty offers for help usually. Honestly I'm tempted to just orphan both owncloud and nextcloud as it's painful to maintain and it's a truly thankless task. Last time this came up I wrote this on the magazine ... for those who actually have genuine intent to help it's worth reading again: https://fedoramagazine.org/day-life-fedora-packager/ I have no problem with doing major updates in a release, but we do have to manage them carefully to avoid breakage. As for why it's fallen behind in recent times life has a tendency to get in the way. Remember well that most of us (especially me) is not paid for this and try to do our best amongst other things. I had a new daughter born in January, I also have a daughter who recently turned 2. I am a DevOps contractor and work has to come first to pay the bills. My day usually starts at around 6am when I get up, get ready for work, check on the girls and have my ~1.5 hour commute to my office. I usually get in around 08:30 and work till around 17:00 or so. My commute back is also around 1.5 hours. During the commutes I try and catch up on the news and mailing lists. When I get home it's a short time to dinner, a short playtime with my eldest and then putting her to bed. That will normally take me to about 20:00 or thereabouts. Then there's general chores and suddenly it's pushing 22:00 with a 06:00 alarm waiting again ... That is my weekday on a day to day basis ... My ability to do anything Fedora related during working hours will vary with the contract I have at the time ... my last contract was a clearance-required environment that prevented any such activity. My present contract gives me a little more freedom, and this is now at the top of my "spare seconds" radar ... indeed I started testing yesterday (without seeing this thread yet). FIrst thing when I fired up my test harness was that F28 has changed, and thus broken, kickstart for the user option compared to a standard minimal that worked going back to F22 and EL7 so that had to be debugged and fixed ... done Next things is the ansible that I use to test ... well the lovely folks jumping the gun on dropping python2-* packages is making life painful since ansible still uses python2 by default and not everything support python3 yet. There is no python2-firewall anymore for the ansible firewalld module ... yay another silly thing to work around! If there is genuine intent to actually help and not just whine then please do contact me directly - I'm frequently on IRC during the working day (UK time) now as well. My plan is to get the next major versions of both owncloud and nextcloud that are safe to upgrade to built and pushed as soon as I can ... I will bundle libraries if there are versioning issues getting this sorted. This will also involve a change from mod_php to php-fpm for httpd users, nginx of course already has php-fpm. When those have been out a few weeks in stable then I'll do the same with the next major release and so on until we are caught up. At that point I'll look to removing any bundling if some was required. If this looks like too long a path for you feel free to stop using the packages and just use upstream. Again, if you are genuine about wanting to help please contact me directly. If you want to just whine ... well frankly I'm not going to pay any attention to that and we'll get there when we do. If you want to pay me to maintain these so I can make up lost costs when I'm not working that would also be a plan ;) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.
Re: Status of OwnCloud/NextCloud
On 03/04/18 21:00, Christian Glombek wrote: > I should probably add that the actual updater program has not been shipped in > the rpms thus far. Although I'm not sure how this affects major updates, it > is leading to problems elsewhere (i.e. people have to uninstall some apps on > v13 and re-install them on v13.0.1 for them to work again). > > And how many people actually still run NC v10? I have two servers with NC v10 via EPEL 7 ... and getting increasingly concerned. I've even started considering moving those servers over to a stable Debian release, as that environment is closer to EPEL stability than Fedora but with newer dependencies. But I'm not too happy about manually installing NC. NC is great in so many ways, but the poor packaging means I'll have to rethink how much longer I'm willing to accept the current situation. Time is scarce for everyone. I don't mean to shoot any of the NC package maintainers in Fedora, I have the impression they have and are doing what they can, as this is a community project. But I think Nextcloud as a company should take this matter far more serious. It might even be considered a business model for a subscription service. -- kind regards, David Sommerseth signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: DNF dependencies and --allowerasing
On 2018-04-03, Przemek Klosowski wrote: > Recently, upgrading pymol was blocked because of version incompatiblity > with pymol-wxpython: > > https://bugzilla.redhat.com/show_bug.cgi?id=1563269 > > The previous version is 1.8.6 and both packages are closely coupled so > they require each other's version. Pymol update to 1.9.0 is blocked > because there's no corresponding version of pymol-wxpython. DNF aborts > the update, and suggests using --allowerasing, which does update pymol, > obviously by deleting pymol-wxpython. > > I don't think pymol-wxpython is deprecated or obsolete, so when > --allowerase deletes it, You don't think, but pymol-wxpython binary package is not produced by pymol source package anymore. Latest one is pymol-wxpython-0:1.8.6-3.20170314svn4170.fc27.x86_64 while you try to install pymol-1.9.0-1.20180224svn4178.fc27. This is clearly bug in pymol packaging. Either the pymol-wxpython disappearance was an oversight, or the packager removed it intentionally and then either pymol-wxpython files were merged into pymol binary package and then pymol binary package should RPM-provide pymol-wxpython, or pymol-wxpython was removed without a replacement and then such an update should have never gone to stable Fedora 27 release bacause it breaks API. -- Petr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora-Atomic 27-20180404.0 compose check report
No missing expected images. Passed openQA tests: 2/2 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Status of OwnCloud/NextCloud
So, I don't think we can update the package from 10 to 13, thus breaking all user installations. I see 2 possible way The classical one - create nextcloud11, nextcloud12 and nextcloud13 packages and also future versions, older can be removed when EOLed by upstream (so nextcloud + nextcloud10 removed in F29) The new one (F28+) - create a nextcloud module with 1 stream per version, following upstream life cycle Remi First one seems a little easier, but modules look very promising. Any experience testing this? If no next cloud apps are installed, mostly a matter of changing location of data folder. If some Nextcloud apps are installed, this is more difficult since apps do not always get updated. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
