Re: Non-responsive maintainer check for hguemar

[Haïkel]

Hi,

send me your FAS account and I'll transfer ownership to you of pyperclip.
You're welcome to contact me directly through email (I'm currently in
sick leave but I'll browse email from time to time).

Regards,
H.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fwd: Orphaning some packages (C++/Gtkmm)

[Haïkel]

Le mer. 10 févr. 2021 à 18:10, Zbigniew Jędrzejewski-Szmek
 a écrit :
>
> Hi,
>
> In case you didn't see bcotton's mail about pp status, please do.
>
> Zbyszek

I did, it helped deciding to actively reduce the scope.

Regards,
H.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fwd: Orphaning some packages (C++/Gtkmm)

[Haïkel]

Hello,

due to long-standing health issues, I'd like to focus on a smaller set
of packages and continue mentoring new packagers which helped me to
stay afloat during grim times.
Here's a list of packages that have no co-maintainers and are required
for other projects.
- cairomm
- gconfmm26
- libglademm24
-  gtkmm24
- gstreamermm
- glom
- goocanvasmm2 (only used by glom)

should not be picked up:
- libnotifymm
- plotmm

I might update this list, as I'll focus my attention into getting better.
Most other packages are co-maintained by either SIGs or
co-maintainers, but if you need access to a package that I maintain,
you can directly mail me.

Regards,
H.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: 15 nonresponsive maintainers

[Haïkel]

I'm still around, I had a kidney failure recently hence not able to answer.

Regards.
H.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[rdo-dev] [Reminder] No RDO meeting until January, 9 2019

[Haïkel]

Hi,

As a reminder, there will be no RDO meetings for the next two weeks as
we cancelled those.
Dec, 26: cancelled
Jan, 2: cancelled

So next meeting is January, 9 in 2019!
Have fun during the end of year celebrations!

Regards,
H.
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

[rdo-users] [Meeting] RDO meeting (2018-12-19) minutes

[Haïkel]

==
#rdo: RDO meeting - 2018-12-19
==


Meeting started by number80 at 15:04:15 UTC.  The full logs are
available at
http://eavesdrop.openstack.org/meetings/rdo_meeting___2018_12_19/2018/rdo_meeting___2018_12_19.2018-12-19-15.04.log.html
.



Meeting summary
---

* roll call  (number80, 15:04:28)

* Revisit haproxy situation  (number80, 15:08:47)
  * AGREED: use F28 and/or PaaS SIG build of haproxy 1.8  (number80,
15:22:28)
  * bandini submitted patches for tripleo to support haproxy 1.8 without
breaking compat with 1.5  (number80, 15:23:15)

* ML migration  (number80, 15:32:04)
  * ping leanderthal about ML migration  (number80, 15:35:27)

* open floor  (number80, 15:35:39)
  * baha requested reviewers for ppc64le container build job  (number80,
15:37:47)
  * LINK: https://review.rdoproject.org/r/#/c/17741/  (number80,
15:37:55)
  * ACTION: number80 review it  (number80, 15:38:06)
  * amoralej will chair Jan, 9 meeting  (number80, 15:39:04)



Meeting ended at 15:40:35 UTC.



Action items, by person
---

* number80
  * number80 review it



People present (lines said)
---

* number80 (47)
* dciabrin_ (23)
* amoralej (22)
* Duck (15)
* ykarel (10)
* openstack (6)
* jpena (5)
* baha (3)
* bandini (2)
* PagliaccisCloud (1)
* rdogerrit (1)



Generated by `MeetBot`_ 0.1.4
___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

[rdo-dev] [Meeting] RDO meeting (2018-12-19) minutes

[Haïkel]

==
#rdo: RDO meeting - 2018-12-19
==


Meeting started by number80 at 15:04:15 UTC.  The full logs are
available at
http://eavesdrop.openstack.org/meetings/rdo_meeting___2018_12_19/2018/rdo_meeting___2018_12_19.2018-12-19-15.04.log.html
.



Meeting summary
---

* roll call  (number80, 15:04:28)

* Revisit haproxy situation  (number80, 15:08:47)
  * AGREED: use F28 and/or PaaS SIG build of haproxy 1.8  (number80,
15:22:28)
  * bandini submitted patches for tripleo to support haproxy 1.8 without
breaking compat with 1.5  (number80, 15:23:15)

* ML migration  (number80, 15:32:04)
  * ping leanderthal about ML migration  (number80, 15:35:27)

* open floor  (number80, 15:35:39)
  * baha requested reviewers for ppc64le container build job  (number80,
15:37:47)
  * LINK: https://review.rdoproject.org/r/#/c/17741/  (number80,
15:37:55)
  * ACTION: number80 review it  (number80, 15:38:06)
  * amoralej will chair Jan, 9 meeting  (number80, 15:39:04)



Meeting ended at 15:40:35 UTC.



Action items, by person
---

* number80
  * number80 review it



People present (lines said)
---

* number80 (47)
* dciabrin_ (23)
* amoralej (22)
* Duck (15)
* ykarel (10)
* openstack (6)
* jpena (5)
* baha (3)
* bandini (2)
* PagliaccisCloud (1)
* rdogerrit (1)



Generated by `MeetBot`_ 0.1.4
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

[rdo-users] [Meeting] RDO meeting (2018-12-12) minutes

[Haïkel]

==
#rdo: RDO meeting - 2018-12-12
==


Meeting started by number80 at 15:02:11 UTC.  The full logs are
available at
http://eavesdrop.openstack.org/meetings/rdo_meeting___2018_12_12/2018/rdo_meeting___2018_12_12.2018-12-12-15.02.log.html
.



Meeting summary
---

* roll call  (number80, 15:02:43)

* haproxy 1.8 packaging  (number80, 15:04:55)
  * LINK: https://github.com/mwhahaha/kolla/tree/fedora  (mwhahaha,
15:18:19)
  * AGREED: revisit haproxy 1.8 situation next week  (number80,
15:26:48)

* What to do with upcoming meetings  (number80, 15:28:02)
  * AGREED: Cancelling december, 26 and January, 2 RDO meeting
(number80, 15:29:57)
  * AGREED: Cancelling december, 26 and January, 2 RDO meetings
(number80, 15:30:05)
  * ACTION: number80 Notify the list about meetings cancelled
(number80, 15:32:11)

* FOSDEM and DevConf.CZ booths and swag  (number80, 15:32:17)
  * we need volunteers for openstack and RDO booths at FOSDEM/devconf.cz
(number80, 15:34:23)
  * submit ideas for RDO goodies to leanderthal  (number80, 15:34:32)

* next meeting chair  (number80, 15:35:14)
  * ACTION: number80 to chair next week  (number80, 15:36:52)

* open floor  (number80, 15:36:59)



Meeting ended at 16:00:16 UTC.



Action items, by person
---

* number80
  * number80 Notify the list about meetings cancelled
  * number80 to chair next week



People present (lines said)
---

* number80 (62)
* amoralej (56)
* mwhahaha (29)
* ykarel (23)
* dciabrin (17)
* rdogerrit (8)
* Vorrtex (8)
* openstack (7)
* Duck (6)
* bandini (5)
* quiquell (4)
* jpena (2)
* moguimar (1)



Generated by `MeetBot`_ 0.1.4
___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

[rdo-dev] [Meeting] RDO meeting (2018-12-12) minutes

[Haïkel]

==
#rdo: RDO meeting - 2018-12-12
==


Meeting started by number80 at 15:02:11 UTC.  The full logs are
available at
http://eavesdrop.openstack.org/meetings/rdo_meeting___2018_12_12/2018/rdo_meeting___2018_12_12.2018-12-12-15.02.log.html
.



Meeting summary
---

* roll call  (number80, 15:02:43)

* haproxy 1.8 packaging  (number80, 15:04:55)
  * LINK: https://github.com/mwhahaha/kolla/tree/fedora  (mwhahaha,
15:18:19)
  * AGREED: revisit haproxy 1.8 situation next week  (number80,
15:26:48)

* What to do with upcoming meetings  (number80, 15:28:02)
  * AGREED: Cancelling december, 26 and January, 2 RDO meeting
(number80, 15:29:57)
  * AGREED: Cancelling december, 26 and January, 2 RDO meetings
(number80, 15:30:05)
  * ACTION: number80 Notify the list about meetings cancelled
(number80, 15:32:11)

* FOSDEM and DevConf.CZ booths and swag  (number80, 15:32:17)
  * we need volunteers for openstack and RDO booths at FOSDEM/devconf.cz
(number80, 15:34:23)
  * submit ideas for RDO goodies to leanderthal  (number80, 15:34:32)

* next meeting chair  (number80, 15:35:14)
  * ACTION: number80 to chair next week  (number80, 15:36:52)

* open floor  (number80, 15:36:59)



Meeting ended at 16:00:16 UTC.



Action items, by person
---

* number80
  * number80 Notify the list about meetings cancelled
  * number80 to chair next week



People present (lines said)
---

* number80 (62)
* amoralej (56)
* mwhahaha (29)
* ykarel (23)
* dciabrin (17)
* rdogerrit (8)
* Vorrtex (8)
* openstack (7)
* Duck (6)
* bandini (5)
* quiquell (4)
* jpena (2)
* moguimar (1)



Generated by `MeetBot`_ 0.1.4
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Re: [Softwarefactory-dev] dependencies issues when installing sf on rhel for python-ecdsa

[Haïkel Guémar]

On 07/12/2018 16:03, Nicolas Hicher wrote:

Hello,

Here the dependencies for mock, python-ecdsa and python-lockfile don't 
have dependencies.


Installing:
  mocknoarch   1.4.13-1.el7 
   epel163 k
Installing for dependencies:
  createrepo_cx86_64   0.10.0-18.el7
   rhel-7-server-extras-rpms65 k
  createrepo_c-libs   x86_64   0.10.0-18.el7
   rhel-7-server-extras-rpms89 k
  distribution-gpg-keys   noarch   1.26-1.el7   
   epel185 k
  mock-core-configs   noarch   29.4-1.el7   
   epel 31 k
  pigzx86_64   2.3.4-1.el7  
   epel 81 k
  python2-distro  noarch   1.2.0-1.el7  
   epel 29 k
  python2-pyroute2noarch   0.4.13-1.el7 
   epel345 k

Nico



I'm in favor of tagging both of them in RDO repo, they already exists in 
CBS. Otherwise, we can't support RHEL users of RDO.

Mock is a different story, though.

Regards,
H.



On 2018-12-07 4:05 a.m., Javier Pena wrote:

- Original Message -

Hello,

On 2018-12-06 5:40 p.m., Haïkel Guémar wrote:

On 06/12/2018 23:22, Nicolas Hicher wrote:

Hello,

I'm testing sf on rhel installation using rdo openstack-queens
repository.

I found an issue with python-ecdsa package. On centos, this package
is present on extra repo, but on rhel I found it on
rhel-7-server-openstack-13-rpms.

There are some issues to enable both rhel-7-server-openstack-13-rpms
and openstack-queens repositories:

- users need rhel-7-server-openstack subscription

- we have a mix of python libs from both repos (50% from
rhel-7-openstack, 50% from openstack-queens)

- there were errors on dependencies with erlang:
https://softwarefactory-project.io/paste/show/1347/  , I disabled
rhel-7-server-openstack-13-rpms to fix

What should be the best solution, add python-ecdsa to
openstack-queens or add in in sf packages ? I prefer the first
solution if it's possible, because we manually bump distgit version
on sf.

Thanks.

Nico



My 2 cts

Since we should also support RHEL without requiring any layered
product repo, we should just cross-tag it into RDO.
In the past, we used to ship it (bstinson has built a newer one but
it's same build with NVR bump)
http://cbs.centos.org/koji/buildinfo?buildID=405

For CentOS users, it won't change much, it will be more or less the
same package either from extras or RDO repo.

Regards.
H.

I found 2 others dependencies issues, so we needs to have these packages
available:

- python-ecdsa is for managesf

- mock for drln


This is a tricky one. When installing on RHEL, we only get the package from 
EPEL, so if it doesn't have any additional dependencies we should probably 
cross-tag it.

Javier


- python-lockfile for gerritbot

Only mock have a lot of dependencies, we have to check if we need more
package for its.

The packages used in sf from openstack-queens repos are
https://softwarefactory-project.io/paste/show/1348/

Alan proposed on irc to add centos extra on our sf deployment, but I
think we will have the same issue when using openstack-queens and
rhel-7-server-openstack-13-rpms by having 30% of packages from centos-extra.

Thanks.

Nico




___
Softwarefactory-dev mailing list
Softwarefactory-dev@redhat.com
https://www.redhat.com/mailman/listinfo/softwarefactory-dev

Re: [rdo-users] Zun rpmpackages

[Haïkel Guémar]

On 15/11/2018 08:38, Ignazio Cassano wrote:

Hello everybody,
please, I'd like to know if zun rpm will be released.
Thanks and Regards
Ignazio

___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org



I have two answers for that:
1. Not that I know of
2. Contributions are welcome, so you can make it happen and we will 
gladly help you :)


Regards,
H.

PS: I know it's a cheeky answer but again this what makes RDO awesome, 
you get the power to change things :)

___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

[rdo-users] [meeting] RDO meeting (2018-11-14) minutes

[Haïkel]

==
#rdo: RDO meeting - 2018-11-14
==


Meeting started by number80 at 15:03:29 UTC.  The full logs are
available at
http://eavesdrop.openstack.org/meetings/rdo_meeting___2018_11_14/2018/rdo_meeting___2018_11_14.2018-11-14-15.03.log.html
.



Meeting summary
---

* roll call  (number80, 15:03:40)

* heads up on pcmk2 rpms for OOOCI consumption?  (number80, 15:07:27)
  * ACTION: number80 look at bandini's patch for pcs  (number80,
15:17:19)
  * TripleO considering to have all CI running against podman
(number80, 15:17:49)

* mariadb specfile PR to fix mariadb 10.3.10 rpms  (number80, 15:23:41)
  * ACTION: number80 build newer mariadb in CBS  (number80, 15:24:29)

* Automate podman/virt SIG updates testing  (number80, 15:24:59)
  * ACTION: number80 move discussion to the list  (number80, 15:37:26)

* open floor  (number80, 15:37:34)
  * jpena to chair next week  (number80, 15:39:07)



Meeting ended at 15:41:17 UTC.



Action items, by person
---

* bandini
  * number80 look at bandini's patch for pcs
* number80
  * number80 look at bandini's patch for pcs
  * number80 build newer mariadb in CBS
  * number80 move discussion to the list



People present (lines said)
---

* number80 (57)
* dciabrin (22)
* EmilienM (20)
* openstack (6)
* bandini (5)
* Tengu (4)
* jpena (4)
* panda|rover (1)
* openstackgerrit (1)



Generated by `MeetBot`_ 0.1.4
___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

[rdo-users] [meeting] RDO meeting (2018-10-24) minutes

[Haïkel]

==
#rdo: RDO meeting - 2018-10-24
==


Meeting started by number80 at 15:01:23 UTC.  The full logs are
available at
http://eavesdrop.openstack.org/meetings/rdo_meeting___2018_10_24/2018/rdo_meeting___2018_10_24.2018-10-24-15.01.log.html
.



Meeting summary
---

* roll call  (number80, 15:01:31)

* reserve rdo-* namespaces on gitlab  (number80, 15:12:03)
  * considering to move gerrit replication from github to gitlab
(number80, 15:15:33)
  * AGREED: Allow reserving rdo-* namespaces on both gitlab and
bitbucket  (number80, 15:21:55)
  * ACTION: apevec reserve rdo-* namespaces on gitlab and bitbucket
(number80, 15:23:50)
  * ACTION: number80 mail apevec and Duck about gitlab namespaces
(number80, 15:24:48)

* Booth volunteers for OpenStack Summit Berlin  (number80, 15:25:19)
  * LINK: https://etherpad.openstack.org/p/berlin-summit-community-pod
(number80, 15:27:14)

* open floor  (number80, 15:30:32)

* python3 enabled status  (number80, 15:31:18)
  * LINK:
https://lists.rdoproject.org/pipermail/dev/2018-October/008952.html
-> call for help on tempest plugins  (chandankumar, 15:32:47)
  * new promotion pipeline running for puppet (fedora)  (number80,
15:36:03)

* easyfix project  (number80, 15:42:13)
  * ACTION: PagliaccisCloud will start emails with Rain & Rich on
possible 1st time contributor workshop at upcoming Red Hat Summit
(PagliaccisCloud, 15:56:52)
  * ACTION: chandankumar to kick discusssion on merging efforts taken by
tripleo rdo and openstack community to attract contributors
(chandankumar, 15:56:55)
  * number80 again chairing next week  (number80, 15:58:20)



Meeting ended at 15:58:52 UTC.



Action items, by person
---

* chandankumar
  * chandankumar to kick discusssion on merging efforts taken by tripleo
rdo and openstack community to attract contributors
* number80
  * number80 mail apevec and Duck about gitlab namespaces
* openstack
  * chandankumar to kick discusssion on merging efforts taken by tripleo
rdo and openstack community to attract contributors
* PagliaccisCloud
  * PagliaccisCloud will start emails with Rain & Rich on possible 1st
time contributor workshop at upcoming Red Hat Summit



People present (lines said)
---

* number80 (70)
* chandankumar (63)
* amoralej (53)
* PagliaccisCloud (23)
* ykarel (9)
* hitchover (7)
* jpena (6)
* tosky (5)
* openstack (5)
* rdogerrit (3)
* vkmc (2)



Generated by `MeetBot`_ 0.1.4
___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

[rdo-dev] [meeting] RDO meeting (2018-10-24) minutes

[Haïkel]

==
#rdo: RDO meeting - 2018-10-24
==


Meeting started by number80 at 15:01:23 UTC.  The full logs are
available at
http://eavesdrop.openstack.org/meetings/rdo_meeting___2018_10_24/2018/rdo_meeting___2018_10_24.2018-10-24-15.01.log.html
.



Meeting summary
---

* roll call  (number80, 15:01:31)

* reserve rdo-* namespaces on gitlab  (number80, 15:12:03)
  * considering to move gerrit replication from github to gitlab
(number80, 15:15:33)
  * AGREED: Allow reserving rdo-* namespaces on both gitlab and
bitbucket  (number80, 15:21:55)
  * ACTION: apevec reserve rdo-* namespaces on gitlab and bitbucket
(number80, 15:23:50)
  * ACTION: number80 mail apevec and Duck about gitlab namespaces
(number80, 15:24:48)

* Booth volunteers for OpenStack Summit Berlin  (number80, 15:25:19)
  * LINK: https://etherpad.openstack.org/p/berlin-summit-community-pod
(number80, 15:27:14)

* open floor  (number80, 15:30:32)

* python3 enabled status  (number80, 15:31:18)
  * LINK:
https://lists.rdoproject.org/pipermail/dev/2018-October/008952.html
-> call for help on tempest plugins  (chandankumar, 15:32:47)
  * new promotion pipeline running for puppet (fedora)  (number80,
15:36:03)

* easyfix project  (number80, 15:42:13)
  * ACTION: PagliaccisCloud will start emails with Rain & Rich on
possible 1st time contributor workshop at upcoming Red Hat Summit
(PagliaccisCloud, 15:56:52)
  * ACTION: chandankumar to kick discusssion on merging efforts taken by
tripleo rdo and openstack community to attract contributors
(chandankumar, 15:56:55)
  * number80 again chairing next week  (number80, 15:58:20)



Meeting ended at 15:58:52 UTC.



Action items, by person
---

* chandankumar
  * chandankumar to kick discusssion on merging efforts taken by tripleo
rdo and openstack community to attract contributors
* number80
  * number80 mail apevec and Duck about gitlab namespaces
* openstack
  * chandankumar to kick discusssion on merging efforts taken by tripleo
rdo and openstack community to attract contributors
* PagliaccisCloud
  * PagliaccisCloud will start emails with Rain & Rich on possible 1st
time contributor workshop at upcoming Red Hat Summit



People present (lines said)
---

* number80 (70)
* chandankumar (63)
* amoralej (53)
* PagliaccisCloud (23)
* ykarel (9)
* hitchover (7)
* jpena (6)
* tosky (5)
* openstack (5)
* rdogerrit (3)
* vkmc (2)



Generated by `MeetBot`_ 0.1.4
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Re: [rdo-users] Which repos for RDO

[Haïkel Guémar]

On 23/10/2018 14:07, Andreas Kasenides wrote:

Hi all. Fairly new to RDO/Openstack.

I have been reading around and the abundance of distributions/REPOS for 
Openstack is overwhelming and rather confusing to me. I would like to do 
a production install with undercloud/overcloud methods and following the 
RDO stable releases.


Which REPOS do I need to enable in order to get started?

I would appreciate a helping hand since my first install was not 
successful and reading the TripleO docs 
(http://tripleo.org/install/installation/installation.html#installing-the-undercloud) 
does not match the RDO releases. Or does it?


Thank you

--
Andreas Kasenides
Senior IT Officer
Dept. of Computer Science,
University of Cyprus




Well, we provide packages that will setup everything for you:
* RHEL: https://www.rdoproject.org/repos/rdo-release.rpm (alias to 
latest release package)

* CentOS: yum install centos-release-openstack-rocky from CentOS extras

Do not enable EPEL as this repository conflicts with ours, and there's 
no simple way to fix these.


Regards,
H.



___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org



___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

Re: [rdo-users] requests requires chardet >= 3.0.2, < 3.1.0

[Haïkel Guémar]

Ignore that, flaky network issue made me think previous mail was not 
sent /o\

___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

Re: [rdo-users] requests requires chardet >= 3.0.2, < 3.1.0

[Haïkel Guémar]

On 03/10/2018 11:02, Tobias Urdin wrote:

Hello,

This is an issue we've seen in the CentOS CI for Puppet OpenStack for a 
while as well.
After talking to Alfredo on IRC he reported the following bug a while 
ago [1].


Best regards

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1620221



No update for 6 weeks, it might be worth pinging jcline about it.
I mean I technically can fix it directly in Fedora but since it was 
removed by another maintainer, it would be removed again.

Meanwhile, workaround has been built, and we can keep going.
https://review.rdoproject.org/r/16730


Regards,
H.


On 10/03/2018 09:51 AM, Haïkel Guémar wrote:

On 02/10/2018 21:22, iain MacDonnell wrote:

Not sure if this should go to -users or -dev (or somewhere else)...

RDO (Rocky) ships with python2-requests-2.19.1-3.el7.noarch.rpm and
python2-chardet-3.0.4-7.el7.noarch.rpm.

The requests code has a hard-coded check for:

  # Check chardet for compatibility.
  major, minor, patch = chardet_version.split('.')[:3]
  major, minor, patch = int(major), int(minor), int(patch)
  # chardet >= 3.0.2, < 3.1.0
  assert major == 3
  assert minor < 1
  assert patch >= 2

Unfortunately this requirement is not reflected in the
python2-requests RPM, which just "requires" "python-chardet" (without
any specific version). If the EL7-bundled version of python-chardet is
already installed, and one installs python2-requests from the RDO
repo, either directly or via dependency, python2-chardet does NOT get
updated, which results in warnings like:

# python -c 'import requests'
/usr/lib/python2.7/site-packages/requests/__init__.py:91:
RequestsDependencyWarning: urllib3 (1.21.1) or chardet (2.2.1) doesn't
match a supported version!
    RequestsDependencyWarning)
#

I think that the python2-requests PRM needs an explicit "requires" for
the specific version of python[2]-chardet. Anyone disagree? What's the
right way to file a bug on this?

TIA,

  ~iain
___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org


FYI, I acknowledge this issue so I should deliver a fix today.
About it, we're rebasing requests packages from Fedora but it seems that
they just dropped that lower version requirements for the same reason
[1] so reintroducing it there would not be constructive.
Nonetheless, we will fix it in RDO packages as it impacts EL7 users.

Regards,
H.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1589306

___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org





___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

Re: [rdo-users] requests requires chardet >= 3.0.2, < 3.1.0

[Haïkel Guémar]

On 03/10/2018 11:02, Tobias Urdin wrote:

Hello,

This is an issue we've seen in the CentOS CI for Puppet OpenStack for a 
while as well.
After talking to Alfredo on IRC he reported the following bug a while 
ago [1].


Best regards

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1620221



No update since August, 22, it's worth pinging jcline about it. 
Meanwhile, I have built a fixed package in CBS.

https://review.rdoproject.org/r/16730



On 10/03/2018 09:51 AM, Haïkel Guémar wrote:

On 02/10/2018 21:22, iain MacDonnell wrote:

Not sure if this should go to -users or -dev (or somewhere else)...

RDO (Rocky) ships with python2-requests-2.19.1-3.el7.noarch.rpm and
python2-chardet-3.0.4-7.el7.noarch.rpm.

The requests code has a hard-coded check for:

  # Check chardet for compatibility.
  major, minor, patch = chardet_version.split('.')[:3]
  major, minor, patch = int(major), int(minor), int(patch)
  # chardet >= 3.0.2, < 3.1.0
  assert major == 3
  assert minor < 1
  assert patch >= 2

Unfortunately this requirement is not reflected in the
python2-requests RPM, which just "requires" "python-chardet" (without
any specific version). If the EL7-bundled version of python-chardet is
already installed, and one installs python2-requests from the RDO
repo, either directly or via dependency, python2-chardet does NOT get
updated, which results in warnings like:

# python -c 'import requests'
/usr/lib/python2.7/site-packages/requests/__init__.py:91:
RequestsDependencyWarning: urllib3 (1.21.1) or chardet (2.2.1) doesn't
match a supported version!
    RequestsDependencyWarning)
#

I think that the python2-requests PRM needs an explicit "requires" for
the specific version of python[2]-chardet. Anyone disagree? What's the
right way to file a bug on this?

TIA,

  ~iain
___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org


FYI, I acknowledge this issue so I should deliver a fix today.
About it, we're rebasing requests packages from Fedora but it seems that
they just dropped that lower version requirements for the same reason
[1] so reintroducing it there would not be constructive.
Nonetheless, we will fix it in RDO packages as it impacts EL7 users.

Regards,
H.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1589306

___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org





___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

Re: Possibly non-responsive maintainer: hguemar

[Haïkel]

Le lun. 17 sept. 2018 à 08:12, Mattia Verga  a écrit :
>
> > Le dim. 16 sept. 2018 à 11:27, Fabio Valentini  > a écrit :
> >
> >
> > The policy mention that you have to try contacting the maintainer
> > *first*, you never sent me an email or pinged me on irc.
> > I don't like this kind of passive-aggressive approach, had you
> > contacted me, we would have sorted this out quickly, co-maintainers
> > are welcome.
> >
> > One more thing, when you want to contact someone in the project =>
> >  >
> > Regards,
> > H.
> >
>
> Trying to contact the maintainer directly before opening the unresponsive 
> maintainer policy and reply to bugs via email is right, BUT I would expect 
> bugzilla to be the first contact point and so maintainers should respond in 
> bugzilla first, not via email.
>
> Sometimes a "bug aknowledge, but it's in low priority list" message can keep 
> users calm...
>
> Mattia

(On the policy)

Yes, first attempt should be through bugzilla, but we are human
beings, so it happens that a direct ping is necessary.
The policy may be subject to interpretation, but it hints that this
process should be used when you *cannot* reach the maintainer.
If you have time to mail the list, you have time to mail the person first.

"and asks if anyone knows how to contact the maintainer." => It's
crystal clear (to me at least) that it assumes that you could not
reach the
maintainer through the email registered in FAS (we used to have
regular pings from the system to verify that users are still
monitoring these).

If you want access to a package that I happen to be a "Point of
Contact" (which is semantically different that owner and it's on
purpose), just ask.
Nobody owns anything in Fedora.

Regards,
H.


> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Possibly non-responsive maintainer: hguemar

[Haïkel]

Le dim. 16 sept. 2018 à 11:27, Fabio Valentini  a écrit :
>
> Hi everybody,
>
> There are many open bugs assigned to hguemar, which he is not
> responding to at all. According to a quick bugzilla query, he doesn't
> seem to have responded to any of the bugs assigned to him since
> October 2017 (!).
>

Erm, I have been quite active in august on bugzilla, for instance, I
helped fixing many python3 FTBFS.


> Particularly important to me are the FTBFS reports for libgda, which
> has last been successfully built on f24 (!):
> https://koji.fedoraproject.org/koji/packageinfo?packageID=2321
>
> Since then, the package is essentially broken, and there are several FTBFS 
> bugs.
>
> for f26: https://bugzilla.redhat.com/show_bug.cgi?id=1423852
> for f28: https://bugzilla.redhat.com/show_bug.cgi?id=1556039
> for f29: https://bugzilla.redhat.com/show_bug.cgi?id=1604587
>
> The maintainer has not responded to any of these bugs despite multiple
> comments and needinfo requests. He also has not touched the libgda
> dist-git repository in 5 years according to the commit log.
>

Surprising for a project that had its last stable in 2015 and was
mostly dead since.
I hadn't touched it for a while, as it got updated regularly by the
desktop team.

> There are also other bugzilla bugs where other people have tried to
> reach him, without success, for example:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1560212
>

Incorrect, I did answer and yes I forgot about this.
Did you ask for access? No

> Additionally, several of his packages failed the f29 mass rebuild, and
> the bug reports have been sitting there unacknowledged:
>
> python-yolk: https://bugzilla.redhat.com/show_bug.cgi?id=1606007
> python-sexy: https://bugzilla.redhat.com/show_bug.cgi?id=1605903

These needs co-maintainers, sexy should have been retired long ago,
I kept them around as other packages depends on it.
Again, if you want perms, just ask!


> python-setproctitle: https://bugzilla.redhat.com/show_bug.cgi?id=1605902
> python-ldappool: https://bugzilla.redhat.com/show_bug.cgi?id=1605745
> python-daiquiri: https://bugzilla.redhat.com/show_bug.cgi?id=1605649

I missed these as they were not in the python37 FTBFS tracker.
I'll get them fixed today.

> plotmm: https://bugzilla.redhat.com/show_bug.cgi?id=1605479

Needs a co-maintainer

> gtksourceviewmm3: https://bugzilla.redhat.com/show_bug.cgi?id=1604292

This one has co-maintainers and was actively attended by the desktop team.

> glom: https://bugzilla.redhat.com/show_bug.cgi?id=1604130
>

Co-maintainers are welcome, otherwise, I'll deprecate that.

> Does anybody know how to contact Haïkel Guémar (hguemar), or has heard
> from him recently? According to fedora-active-user, he is - somewhat -
> active? If not, I will continue the non-responsive maintainer process
> according to the Policy.
>
> Fabio

The policy mention that you have to try contacting the maintainer
*first*, you never sent me an email or pinged me on irc.
I don't like this kind of passive-aggressive approach, had you
contacted me, we would have sorted this out quickly, co-maintainers
are welcome.

One more thing, when you want to contact someone in the project =>
@fedoraproject.org should always work.

Regards,
H.

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[openstack-dev] Redis licensing terms changes

[Haïkel]

Hi,

I haven't seen this but I'd like to point that Redis moved to an open
core licensing model.
https://redislabs.com/community/commons-clause/

In short:
* base engine remains under BSD license
* modules move to ASL 2.0 + commons clause which is non-free
(prohibits sales of derived products)

IMHO, projects that rely on Redis as default driver, should consider
alternatives (off course, it's up to them).

Regards,
H.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [rdo-dev] Fwd: ansible 2.6 support in RDO

[Haïkel Guémar]

On 20/07/18 17:36, Ken Dreyer wrote:

Hi RDO developers,

In ceph-ansible we are planning to switch our CI system to use Ansible
2.6 on the master branch.
https://github.com/ceph/ceph-ansible/pull/2908


When do you plan to support Ansible 2.6 on the openstack node that
would run ceph-ansible ?

- Ken
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org



Currently Rocky has Ansible 2.5.2.
TripleO will be testing against Ansible 2.6.x, but at this stage, I am 
not very optimistic it will get into Rocky (release in mid-september).


Regards,
H.
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Re: [rdo-dev] Regenerate secrets required by zuul jobs

[Haïkel Guémar]

On 18/07/18 22:24, Paul Belanger wrote:

Greetings,

With recent Jenkins security advisory today, I realized we just imported the
current secrets from jenkins into zuulv3.  I'd like to propose, just to be extra
safe, we preform a re-key of everything that uses secrets.

I'm not sure if this has every been done with jenkins, but we should also
consider some policy to re-key everything ever x months too.

Thoughts?
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org



The current CBS credentials for RDO have never been into Jenkins.

Regards,
H.
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Re: broken package needs attention: libgda

[Haïkel]

2018-06-10 22:46 GMT+02:00 Sérgio Basto :
> On Sun, 2018-06-10 at 18:27 +0200, Fabio Valentini wrote:
>> Hi,
>>
>> The "libgda" package is quite broken in fedora, which is impacting
>> dependent programs.
>>
>> - The last successful build of libgda was for the fedora 24 (!) mass
>> rebuild. No more recent builds succeeded, and the packages was
>> reported as FTBFS.
>> - Not even the latest version is packaged (5.2.2 instead of 5.2.4).
>>
>> This is leading to problems in all current releases of fedora. For
>> example, the mysql database provider can't be installed anymore,
>> because libgda wasn't rebuilt for soname bumps in mariadb/mysql.
>>
>> Packages depending on libgda include:
>>
>> - anjuta
>> - glom
>> - gnumeric-plugins-extras
>> - gtranslator
>> - noise
>> - sequeler
>>
>> Is there any procedure for dealing with a package that's obviously
>> outdated and broken (and has been for 3 fedora releases), but is
>> still depended on by other packages?
>>
>> There has been an open bug report [0] about the FTBFS issues, but no
>> actions have been taken so far by the package maintainer(s).
>>
>> Fabio
>>
>> [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1423852
>
>
> I see 3 patches there and we got another bug report  [1]
>
> The best would be add one pull request in src.f.o [2] , i.e do a fork
> apply the patch and submit one pull request .
>
>
> [1]
> https://bugzilla.redhat.com/show_bug.cgi?id=1556039
>
>
> [2]
>  https://src.fedoraproject.org/rpms/libgda/pull-requests
>
> --
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KGBVPAILSYUXYYWPOGECPPSCDYMICFIX/


Sending an email to libgda-owner would have raised the attention on
your patches.
I got a notification late night about and I planned to go through it
later today (currently, I am teaching a class and I still have my
$dayjob duty)

libgda is co-maintained with the desktop team but it seems that the
project is not anymore
maintained in GNOME upstream hence its sore state.

So first task is to apply those patches and possibly, send them
upstream. Second task is to determine if we should drop the packages
(and it includes all the bindings to libgda),
but I need more time for that.

Alternative is you want comaintainership, just ask, you're welcome :)

Regards,
H.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BV6IP6FF6VRJDJM4PILHC3LCK74WRYSF/

Re: [rdo-dev] qemu-kvm vs qemu-kvm-rhev requirement

[Haïkel Guémar]

On 06/05/2018 11:28 AM, Roman Kagan wrote:

On Tue, Jun 05, 2018 at 10:26:54AM +0200, Kashyap Chamarthy wrote:

On Mon, Jun 04, 2018 at 09:41:07PM +0300, Roman Kagan wrote:

Not so long ago openstack-nova started to require qemu-kvm-rhev instead
of qemu-kvm.

This made it impossible to install on Virtuozzo, which used to work well
before the change.


I think Virtuozzo is based on CentOS.


Right, to a large extent.  However, our QEMU package is much closer to
qemu-kvm-rhev than to CentOS' qemu-kvm.  It's still different from
qemu-kvm-rhev in some respects so we don't feel comfortable providing
"qemu-kvm-rhev" in our package.



The thing is EL7 is stuck at RPM 4.11.x. If we had RPM 4.13.x, we could 
have used boolean dependencies to do that:


Requires: qemu-kvm-rhev >= 2.9.0 or qemu-kvm-virtuozzo >= x.y.z

Meanwhile, we don't have much alternatives than the one already 
suggested to provide qemu-kvm-rhev



I skimmed through the related tickets

https://bugzilla.redhat.com/show_bug.cgi?id=1367696
https://review.rdoproject.org/r/1900
https://bugzilla.redhat.com/show_bug.cgi?id=1392820
https://review.rdoproject.org/r/9858

but failed to understand the motivation behind this change.  What are
those particular features that are only present in qemu-kvm-rhev and
make the vendor-neutral requirement insufficient?  So far we didn't
notice any issues running recent enough QEMU with Nova, but I guess this
must have changed.


Dan has already responded.  In short, 'qemu-kvm-rhev' is the recommended
RPM for Red Hat OSP.


This is clear :)  I'm interested in a longer reply to "why", in order to
figure out how to correctly run Nova on top of Virtuozzo.

Thanks,
Roman.


In short, it's a trimmed version of qemu-kvm for enterprise users:
* unsupported devices/features are disabled
* features backported from the next branch (including support for newer CPU)
Most patches are linked to an upstream pull request, or a ticket for bugs.

In our case, I think we're mostly interested in live migration features 
backports, but that might not be accurate or up-to-date as I'm not 
focusing on compute.


Regards,
H.



___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org



___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Re: [rdo-dev] qemu-kvm vs qemu-kvm-rhev requirement

[Haïkel Guémar]

On 06/05/2018 10:26 AM, Kashyap Chamarthy wrote:

On Mon, Jun 04, 2018 at 09:41:07PM +0300, Roman Kagan wrote:

Not so long ago openstack-nova started to require qemu-kvm-rhev instead
of qemu-kvm.

This made it impossible to install on Virtuozzo, which used to work well
before the change.


I think Virtuozzo is based on CentOS.


I skimmed through the related tickets

https://bugzilla.redhat.com/show_bug.cgi?id=1367696
https://review.rdoproject.org/r/1900
https://bugzilla.redhat.com/show_bug.cgi?id=1392820
https://review.rdoproject.org/r/9858

but failed to understand the motivation behind this change.  What are
those particular features that are only present in qemu-kvm-rhev and
make the vendor-neutral requirement insufficient?  So far we didn't
notice any issues running recent enough QEMU with Nova, but I guess this
must have changed.


Dan has already responded.  In short, 'qemu-kvm-rhev' is the recommended
RPM for Red Hat OSP.

 - - -

FYI, a related change that will get shortly pushed to RDO Nova spec (and
to "Queens" branch too):

 https://review.rdoproject.org/r/#/c/13277/ -- Bump the minimum
 version of 'qemu-kvm-rhev' & libvirt


I'm now trying to figure out what is needed to make our QEMU package
work with Nova; any help will be appreciated.

Thanks,
Roman.




Maybe the missing information is that qemu-kvm-ev is provided by the 
CentOS Virt SIG => https://cbs.centos.org/koji/packageinfo?packageID=539


If you use the release packages provided by RDO or CentOS extras, 
repositories are correctly setup to retrieve it.


Regards,
H.
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

[rdo-users] [Meeting] RDO meeting (2018-04-19) minutes

[Haïkel]

My apologies for the late sending of the minutes

---

==
#rdo: RDO meeting - 2018-04-18
==


Meeting started by number80 at 15:01:41 UTC.  The full logs are
available at
http://eavesdrop.openstack.org/meetings/rdo_meeting___2018_04_18/2018/rdo_meeting___2018_04_18.2018-04-18-15.01.log.html
.



Meeting summary
---

* roll call  (number80, 15:01:49)

* OpenStack Summit booth duty signup  (number80, 15:04:53)
  * we're looking for volunteers to staff the RDO booth at OpenStack
Summit Vancouver  (number80, 15:05:38)
  * LINK: https://etherpad.openstack.org/p/rdo-vancouver-summit-booth
(number80, 15:05:58)

* Red Hat Summit booth duty signup  (number80, 15:08:51)
  * mollyk will be the RDO ambassador for Red Hat Summit  (number80,
15:09:07)
  * LINK:
https://etherpad.openstack.org/p/rdo-manageIQ-ceph-rhSummit2018
(number80, 15:09:43)

* Test days on April, 26 and 27  (number80, 15:12:02)
  * LINK: http://rdoproject.org/testday/  (rbowen, 15:12:09)
  * LINK: https://dashboards.rdoproject.org/rdo-dev  (rbowen, 15:15:43)
  * All green considering promotion for RDO Rocky M-1 test days
(number80, 15:19:38)

* next week chair  (number80, 15:19:59)
  * chandankumar chairing next week  (number80, 15:20:31)

* open floor  (number80, 15:20:39)
  * devconf.in will happen in Aug, 4/5 and CfP is open  (number80,
15:21:48)
  * LINK: https://devconf.info/in  (number80, 15:22:02)



Meeting ended at 15:29:05 UTC.



People present (lines said)
---

* number80 (61)
* rbowen (37)
* chandankumar (17)
* openstack (12)
* PagliaccisCloud (4)
* rdogerrit (3)
* mollyk (2)
* amoralej (2)
* jpena (1)
* sfbender (1)
* baha (1)
* jruzicka (1)
* mjturek (1)



Generated by `MeetBot`_ 0.1.4
___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

Re: [rdo-dev] proposal to alert #rdo w/ issues from launchpad

[Haïkel Guémar]

On 03/03/2018 01:27 PM, Wesley Hayutin wrote:

Greetings,

As we rely on RDO infrastructure more and more for TripleO 3rd party 
jobs and periodic jobs I propose we use the same alerting method we use 
in the #tripleo channel.


So in this case I think we could add a tag to launch pad bugs named
tag = "rdo-infra-alert"
or
tag = "rdo-infra"

etc.. you get the point.

The irc alerts have worked well in other channels and it would probably 
help establish the cross-team dependencies we have atm.


Thanks for your comments



I'm not found of that bot, special mention to using all caps.
We need a better way or at least NOT IN ALL CAPS :)

Regards,
H.



___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org



___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Re: [rdo-dev] [ptg] Dublin PTG lunch?

[Haïkel]

Hi,

if you don't recognize the people, I'll wear my RDO cap (which is beige) today.

Regards,
H.

2018-02-23 2:28 GMT+00:00 Tony Breeds :
> On Thu, Feb 22, 2018 at 02:27:09PM -0500, Michael Turek wrote:
>
>> Great!
>>
>> I sent a confirmation out but it looks like I only sent it to Tony...
>> Whoops!
>>
>> Anyway, let's plan to meet outside the lunch room on Tuesday at the start of
>> lunch! See you all there.
>
> Great!.
>
> Yours Tony.
>
> ___
> dev mailing list
> dev@lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
>
> To unsubscribe: dev-unsubscr...@lists.rdoproject.org
>
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

[Fedora-legal-list] Re: BSD 2-Clause license

[Haïkel]

2018-02-21 16:07 GMT+01:00 Fernando Nasser :
> On 2018-02-19 11:25 AM, Neal Gompa wrote:
>
> On Mon, Feb 19, 2018 at 11:24 AM, Fernando Nasser 
> wrote:
>
> Hi,
>
>
> Would it be possible to add:
>
> BSD 2-clause
>
> to our table of valid licenses?
>
>
> This is already accepted under the "BSD" moniker for Fedora license tags.
>
>
> Oh, I see it now:
>
> BSD License (two clause)BSD   (...)
> https://fedoraproject.org/wiki/Licensing/BSD#2ClauseBSD
>
>
>
> Aren't we using this plain "BSD" abbreviation too liberally?
>
> If you look at SPDX you'll see that there are BSD licenses and then BSD
> licenses, some are ok for FSF, some for OSI, some for both, and some for
> none (which is scary) (ref.: https://spdx.org/licenses/ ).
>
>
> We want to get closer to the SPDX maybe it is time to use the more specific
> abbreviations for these BSD licenses we have.
>
>
> P.S.: Any interest in adding a SPDX abbrev column to our table?  I can try
> and help populating it.
>
>
> --Fernando
>

This discussion was raised few years ago and stalled. I don't think
it's useful to have a SPDX
abbrev column. It'd be more interesting to switch to SPDX (or refine
our own abbreviations).

Regards,
H.

>
>
> ___
> legal mailing list -- legal@lists.fedoraproject.org
> To unsubscribe send an email to legal-le...@lists.fedoraproject.org
>
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org

Re: [openstack-dev] Debian OpenStack packages switching to Py3 for Queens

[Haïkel]

2018-02-15 11:25 GMT+01:00 Bob Ball :
> Hi Thomas,
>
> As noted on the patch, XenServer only has python 2 (and some versions of 
> XenServer even has Python 2.4) in domain0.  This is code that will not run in 
> Debian (only in XenServer's dom0) and therefore can be ignored or removed 
> from the Debian package.
> It's not practical to convert these to support python 3.
>
> Bob
>

We're not there yet but we also plan to work on migrating RDO to Python 3.
And I have to disagree, this code is called by other projects and their tests,
so it will likely be an impediment in migrating OpenStack to Python 3, not just
a "packaging" issue.

If this code is meant to run on Dom0, fine, then we won't package it,
but we also
have to decouple that dependency from Nova, Neutron, Ceilometer etc... to either
communicate directly through an API endpoint or a light wrapper around it.

Regards,
H.

> -Original Message-
> From: Thomas Goirand [mailto:z...@debian.org]
> Sent: 15 February 2018 08:31
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] Debian OpenStack packages switching to Py3 for Queens
>
> Hi,
>
> Since I'm getting some pressure from other DDs to actively remove Py2 support 
> from my packages, I'm very much considering switching all of the Debian 
> packages for Queens to using exclusively Py3. I would have like to read some 
> opinions about this. Is it a good time for such move? I hope it is, because 
> I'd like to maintain as few Python package with Py2 support at the time of 
> Debian Buster freeze.
>
> Also, doing Queens, I've noticed that os-xenapi is still full of py2 only 
> stuff in os_xenapi/dom0. Can we get those fixes? Here's my patch:
>
> https://review.openstack.org/544809
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo][python3] python3 readiness?

[Haïkel]

2018-02-14 22:53 GMT+01:00 Tom Barron :
> On 13/02/18 16:53 -0600, Ben Nemec wrote:
>>
>>
>>
>> On 02/13/2018 01:57 PM, Tom Barron wrote:
>>>
>>> Since python 2.7 will not be maintained past 2020 [1] it is a reasonable
>>> conjecture that downstream distributions
>>> will drop support for python 2 between now and then, perhaps as early as
>>> next year.
>>
>>
>> I'm not sure I agree.  I suspect python 2 support will not go quietly into
>> that good night.  Personally I anticipate a lot of kicking and screaming
>> right up to the end, especially from change averse enterprise users.
>>
>> But that's neither here nor there.  I think we're all in agreement that
>> python 3 support is needed. :-)
>
>
> Yeah, but you raise a good issue.  How likely is it that EL8 will choose --
> perhaps under duress -- to support both python 2 and python 3 in the next
> big downstream release.  If this is done long enough that we can support
> TripleO deployments on CentOS 8 using python2 while at the same time testing
> TripleO deployments on CentOS using python3 then TripleO support for Fedora
> wouldn't be necessary.
>
> Perhaps this question is settled, perhaps it is open.  Let's try to nail
> down which for the record.
>

All I can say is that question is definitely settled. As far as
OpenStack is concerned,
there will be no Python2 on EL8.

>
>>
>>> In Pike, OpenStack projects, including TripleO, added python 3 unit
>>> tests.  That effort was a good start, but likely we can agree that it is
>>> *only* a start to gaining confidence that real life TripleO deployments will
>>> "just work" running python 3.  As agreed in the TripleO community meeting,
>>> this email is intended to kick off a discussion in advance of PTG on what
>>> else needs to be done.
>>>
>>> In this regard it is worth observing that TripleO currently only supports
>>> CentOS deployments and CentOS won't have python 3 support until RHEL does,
>>> which may be too late to test deploying with python3 before support for
>>> python2 is dropped.  Fedora does have support for python 3 and for this
>>> reason RDO has decided [2] to begin work to run with *stabilized* Fedora
>>> repositories in the Rocky cycle, aiming to be ready on time to migrate to
>>> Python 3 and support its use in downstream and upstream CI pipelines.
>>
>>
>> So that means we'll never have Python 3 on CentOS 7 and we need to start
>> supporting Fedora again in order to do functional testing on py3? That's
>> potentially messy.  My recollection of running TripleO CI on Fedora is that
>> it was, to put it nicely, a maintenance headache.  Even with the
>> "stabilized" repos from RDO, TripleO has a knack for hitting edge case bugs
>> in a fast-moving distro like Fedora.  I guess it's not entirely clear to me
>> what the exact plan is since there's some discussion of frozen snapshots and
>> such, which might address the fast-moving part.
>>
>> It also means more CI jobs, unless we're okay with dropping CentOS support
>> for some scenarios and switching them to Fedora.  Given the amount of
>> changes between CentOS 7 and current Fedora that's a pretty big gap in our
>> testing.
>>
>> I guess if RDO has chosen this path then we don't have much choice.  As
>> far as next steps, the first thing that would need to be done is to get
>> TripleO running on Fedora again.  I suggest starting with
>> https://github.com/openstack/instack-undercloud/blob/3e702f3bdfea21c69dc8184e690f26e142a13bff/instack_undercloud/undercloud.py#L1377
>> :-)
>>
>> -Ben
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo][python3] python3 readiness?

[Haïkel]

2018-02-14 17:05 GMT+01:00 Ben Nemec :
>
>
> On 02/13/2018 05:30 PM, David Moreau Simard wrote:
>>
>> On Tue, Feb 13, 2018 at 5:53 PM, Ben Nemec  wrote:
>>>
>>>
>>> I guess if RDO has chosen this path then we don't have much choice.
>>
>>
>> This makes it sound like we had a choice to begin with.
>> We've already had a lot of discussions around the topic but we're
>> ultimately stuck between a rock and a hard place.
>>
>> We're in this together and it's important that everyone understands
>> what's going on.
>>
>> It's not a secret to anyone that Fedora is more or less the upstream to
>> RHEL.
>> There's no py3 available in RHEL 7.
>> The alternative to making things work in Fedora is to use Software
>> Collections [1].
>>
>> If you're not familiar with Software Collections for python, it's more
>> or less the installation of RPM packages in a virtualenv.
>> Installing the "rh-python35" SCL would:
>> - Set up a chroot in /opt/rh/rh-python35/root
>> - Set up a py35 interpreter at /opt/rh/rh-python35/root/usr/bin/python3
>>
>> And then, when you would install packages *against* that SCL, they
>> would end up being installed
>> in /opt/rh/rh-python35/root/usr/lib/python3.5/site-packages/.
>>
>> That means that you need *all* of your python packages to be built
>> against the software collections and installed in the right path.
>>
>> Python script with a #!/usr/bin/python shebang ? Probably not going to
>> work.
>> Need python-requests ? Nope, sclo-python35-python-requests.
>> Need one of the 1000+ python packages maintained by RDO ?
>> Those need to be re-built and maintained against the SCL too.
>>
>> If you want to see what it looks like in practice, here's a Zuul spec
>> file [2] or the official docs for SCL [3].
>
>
> Ick, I didn't realize SCLs were that bad.
>

And that's only the tip of the iceberg :)

> /me dons his fireproof suit
>
> I know this is a dirty word around these parts, but I note that EPEL appears
> to have python 3 packages...
>

All I can say is that option was put on the table.

> Ultimately, though, I'm not in a position to be making any definitive
> statements about how to handle this.  RDO has more consumers than just
> TripleO.  The purpose of my email was mostly to provide some historical
> perspective from back when we were doing TripleO CI on Fedora, why we're not
> doing that anymore, and in fact went so far as to explicitly disable Fedora
> in the undercloud installer.  If Fedora is still our best option then so be
> it, but I don't want anyone to think it's going to be as simple as
> s/CentOS/Fedora/ (I assume no one does, but you know what they say about
> ass-u-me :-).
>

I agree it won't be simple, we will have to provide those
repositories, determine how
we will gate updates, fix puppet modules, POI, etc.. and that's only a
beginning.

That's why we won't be providing raw Fedora but rather a curated
version and at some
point, we'll likely freeze it. That's kinda similar to how EL8 is
made, but it won't be EL8. :o)

Let's say that the time is ticking, if we want to ship a productized
OpenStack distro on
Python3, and possibly on EL8 (Hint: I don't know when it will be
released, and moreover,
I'm not the one who gets to decide when RHOSP will support EL8), we're
about to reach
the point of no-return.

H.

>
>>
>> Making stuff work on Fedora is not going to be easy for anyone but it
>> sure beats messing with 1500+ packages that we'd need to untangle
>> later.
>> Most of the hard work for Fedora is already done as far as packaging
>> is concerned, we never really stopped building packages for Fedora
>> [4].
>>
>> It means we should be prepared once RHEL 8 comes out.
>>
>> [1]: https://www.softwarecollections.org/en/
>> [2]:
>> https://softwarefactory-project.io/r/gitweb?p=scl/zuul-distgit.git;a=blob;f=zuul.spec;h=6bba6a79c1f8ff844a9ea3715ab2cef1b12d323f;hb=refs/heads/master
>> [3]:
>> https://www.softwarecollections.org/en/docs/guide/#chap-Packaging_Software_Collections
>> [4]: https://trunk.rdoproject.org/fedora-rawhide/report.html
>>
>> David Moreau Simard
>> Senior Software Engineer | OpenStack RDO
>>
>> dmsimard = [irc, github, twitter]
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[rdo-dev] [Meeting] RDO meeting (2018-02-14) minutes

[Haïkel]

==
#rdo: RDO meeting - 2018-02-14
==


Meeting started by number80 at 15:00:16 UTC.  The full logs are
available at
http://eavesdrop.openstack.org/meetings/rdo_meeting___2018_02_14/2018/rdo_meeting___2018_02_14.2018-02-14-15.00.log.html
.



Meeting summary
---

* roll call  (number80, 15:00:23)

* virtual meetup, April, 12th CFP  (number80, 15:03:00)
  * LINK: https://goo.gl/e5EWAt  (rbowen, 15:03:53)
  * if you want to present a project, feature, Return on Experience
about OpenStack, please submit to CfP  (number80, 15:04:15)
  * LINK: https://etherpad.openstack.org/p/rdo-queens-release  (rbowen,
15:07:17)

* Queens Release checklist  (number80, 15:08:11)
  * help required to write RDO Queens release notes!  (number80,
15:08:34)
  * ACTION: jpena to extract contributor list and numbers from
repoxplorer  (jpena, 15:11:25)

* Test day preparedness  (number80, 15:11:57)
  * ACTION: rbowen will update testday web site, send announce to lists
(rbowen, 15:15:07)
  * AGREED: move test day to March 15, 16 as final release test days
(number80, 15:15:14)

* Follow-up: CentOS Cloud SIG meetings?  (number80, 15:18:05)
  * ACTION: look at the poll result and send results on centos-devel
list  (number80, 15:18:43)
  * LINK: http://whenisgood.net/bpqn4fn  (rbowen, 15:19:32)

* Follow-up: stabilized repositories proposal  (number80, 15:22:17)
  * LINK:

https://etherpad.openstack.org/p/stabilized-fedora-repositories-for-openstack
(number80, 15:22:43)

* next week chair  (number80, 15:27:27)
  * jpena chairing next week meeting  (number80, 15:28:39)

* open floor (and celebration for leanderthal come back)  (number80,
  15:28:56)
  * leanderthal is back :)  (number80, 15:29:02)



Meeting ended at 15:32:50 UTC.



Action items, by person
---

* jpena
  * jpena to extract contributor list and numbers from repoxplorer
* rbowen
  * rbowen will update testday web site, send announce to lists



People present (lines said)
---

* number80 (68)
* rbowen (50)
* dmsimard (12)
* openstack (10)
* leanderthal (8)
* amoralej (8)
* jpena (5)
* rdogerrit (3)
* ykarel (3)
* dtantsur (2)
* jruzicka (2)
* weshay (1)
* apevec (1)
* jschlueter (1)
* mjturek (1)
* mary_grace (1)



Generated by `MeetBot`_ 0.1.4
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Re: [rdo-dev] [rdo-users] Python3 proposal: stabilized Fedora repositories for OpenStack

[Haïkel Guémar]

On 02/14/2018 09:42 AM, Tristan Cacqueray wrote:

Hello Haïkel,

thanks for putting this summary. Please find some comments inlined bellow.

On February 7, 2018 4:21 pm, Haïkel wrote:

Hi,

Following our discussions during today's RDO meeting about a draft to
start working on
python3 support in RDO, I expand the discussion to the wider group.
Please keep the discussion on the dev list, users list is only there
to raise awareness.


Since it's a huge topic, I started an etherpad to collect our
thoughts. It is on upstream etherpad
in order to collaborate with upstream as we hope this would be useful
for upstream gating.
Please read the etherpad for details and provide your feedback.

https://etherpad.openstack.org/p/stabilized-fedora-repositories-for-openstack 



The main idea is to use stabilized Fedora repositories, it is a lot of
work and we intend to start
working that during the Rocky cycle.

Please forgive my ignorance, but what are "stabilized Fedora
repositories" ?



Since Fedora has proven to be an unstable platform for OpenStack, we 
plan to provide "stabilized" repositories.
The concept is quite simple: we provide a snapshot of Fedora 
repositories and then gate updates through CI.
Any updates that fails CI will be blacklisted or overridden, we will 
also provides packages overrides for the ones we can't update in Fedora.


Hence stabilized :)



This will allow us to work on
migrating our packaging on python3
and support modularity which will ship with EL8 (currently a Fedora
only feature).

IIRC modularity correctly, are we going to create distgit branch for
openstack requirements version from the upper-constraints file?
Then each openstack package would be a module built using those branches?
Perhaps we would be able to use those branched fedora spec in rdo 
repository

using automatic conversion?



In short, there's no 1:1 mapping between modules and packages.
As of today, there will be a python36 module (and later python37 one etc 
...). On top of that, we will have base OpenStack Rocky, OpenStack S 
etc.. modules containing dependencies (and likely oslo libs). Our 
packages will require a specific module.


That's more or less the plan, we might have finer-grained modules (e.g 
for gnocchi or swift) but this would be considered at a later stage 
after we finish the transition to Python3 and modules. First, baby steps.



I hope this answers your questions, otherwise feel free to nag me again :)

Regards,
H.


There's a lot of work but we aim to be ready on time to migrate to
Python3 when EL8 will be released.

This is not about supporting python3 for end-users, until EL8 gets
released, this is only intended
for our downstream and upstream CI pipelines.

Regards,
H.
___
users mailing list
us...@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org




___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org



___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Re: [openstack-dev] [tripleo][python3] python3 readiness?

[Haïkel]

2018-02-13 23:53 GMT+01:00 Ben Nemec :
>
>
> On 02/13/2018 01:57 PM, Tom Barron wrote:
>>
>> Since python 2.7 will not be maintained past 2020 [1] it is a reasonable
>> conjecture that downstream distributions
>> will drop support for python 2 between now and then, perhaps as early as
>> next year.
>
>
> I'm not sure I agree.  I suspect python 2 support will not go quietly into
> that good night.  Personally I anticipate a lot of kicking and screaming
> right up to the end, especially from change averse enterprise users.
>
> But that's neither here nor there.  I think we're all in agreement that
> python 3 support is needed. :-)
>
>> In Pike, OpenStack projects, including TripleO, added python 3 unit tests.
>> That effort was a good start, but likely we can agree that it is *only* a
>> start to gaining confidence that real life TripleO deployments will "just
>> work" running python 3.  As agreed in the TripleO community meeting, this
>> email is intended to kick off a discussion in advance of PTG on what else
>> needs to be done.
>>
>> In this regard it is worth observing that TripleO currently only supports
>> CentOS deployments and CentOS won't have python 3 support until RHEL does,
>> which may be too late to test deploying with python3 before support for
>> python2 is dropped.  Fedora does have support for python 3 and for this
>> reason RDO has decided [2] to begin work to run with *stabilized* Fedora
>> repositories in the Rocky cycle, aiming to be ready on time to migrate to
>> Python 3 and support its use in downstream and upstream CI pipelines.
>
>
> So that means we'll never have Python 3 on CentOS 7 and we need to start
> supporting Fedora again in order to do functional testing on py3? That's
> potentially messy.  My recollection of running TripleO CI on Fedora is that
> it was, to put it nicely, a maintenance headache.  Even with the
> "stabilized" repos from RDO, TripleO has a knack for hitting edge case bugs
> in a fast-moving distro like Fedora.  I guess it's not entirely clear to me
> what the exact plan is since there's some discussion of frozen snapshots and
> such, which might address the fast-moving part.
>
> It also means more CI jobs, unless we're okay with dropping CentOS support
> for some scenarios and switching them to Fedora.  Given the amount of
> changes between CentOS 7 and current Fedora that's a pretty big gap in our
> testing.
>
> I guess if RDO has chosen this path then we don't have much choice.  As far
> as next steps, the first thing that would need to be done is to get TripleO
> running on Fedora again.  I suggest starting with
> https://github.com/openstack/instack-undercloud/blob/3e702f3bdfea21c69dc8184e690f26e142a13bff/instack_undercloud/undercloud.py#L1377
> :-)
>
> -Ben
>

RDO has *yet* to choose a plan, and people were invited to work on the
"stabilized" repository draft [0]. If anyone has a better plan that fits all the
constraints, please share it asap.
Whatever the plan, we're launching it with the Rocky cycle.

Among the constraints (but not limited to):
* EL8 is not available
* No Python3 on EL7 *and* no allocated resources to maintain it (that includes
rebuilding/maintaining *all* python modules + libraries)
* Bridge the gap between EL7 and EL8, Fedora 27/28 are the closest thing we
have to EL8 [1][2]
* SCL have a cost (and I cannot yet expose why but not jumping onto the SCL
bandwagon has proven to be the right bet)
* Have something stable enough so that upstream gate can use it.
That's why plan stress that updates will be gated (definition of how
is still open)
* Manage to align planets so that we can ship version X of OpenStack [3] on EL8
without additional delay

Well, I cannot say that I can't relate to what you're saying, though. [4]

Regards,
H.

[0] 
https://etherpad.openstack.org/p/stabilized-fedora-repositories-for-openstack
[1] Do not assume anything on EL8 (name included) it's more
complicated than that.
[2] Take a breath, but we might have to ship RDO as modules, not just RPMs or
Containers. I already have headaches about it.
[3] Do not ask which one, I do not know :)
[4] Good thing that next PTG will be in Dublin, I'll need a lot of
irish whiskey :)

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [rdo-dev] [ppc64le] Some greenlet packages seem to be wrong arch

[Haïkel Guémar]

On 02/13/2018 05:00 PM, Michael Turek wrote:

Hey RDO,

Continued to play with the build of RDO in rdotrunk [0] and noticed 
another problem with the deps [1]. If you ctrl+f for x86_64, you'll see 
that the following packages are listed as (and I'm assuming actually 
are) x86_64 builds:


python-greenlet-debuginfo-0.4.12-1.el7.x86_64.rpm
python2-greenlet-0.4.12-1.el7.x86_64.rpm
python2-greenlet-devel-0.4.12-1.el7.x86_64.rpm



Where do you see these?

The link [0] are continuous builds from DLRN instance (not CBS) which is 
x86_64 only which is fine as most stuff built there are noarch though.


Good news is, I checked out the koji build for the package and it looks 
like it's already built [2]. I'm not sure how to fix such a problem so 
if anyone could point me in the right direction, I'd really appreciate it.


Also, if I should be opening bugs somewhere rather than pointing them 
out here please let me know!


Thanks,
Mike Turek 


[0] https://trunk.rdoproject.org/centos7-queens/current/
[1] https://trunk.rdoproject.org/centos7-queens/deps/latest/ppc64le/
[2] https://cbs.centos.org/koji/buildinfo?buildID=21455

___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org


___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Re: [rdo-dev] Long queue in RDO SF

[Haïkel Guémar]

On 02/11/2018 05:57 PM, David Manchado Cuesta wrote:

FWIW no alerts during the weekend and I have been able to spawn 10+
instances without issue.

Cheers
David Manchado
Senior Software Engineer - SysOps Team
Red Hat
dmanc...@redhat.com



Thanks David!
Just wanted to check :)

Regards,
H.



On 11 February 2018 at 16:39, Paul Belanger <pabelan...@redhat.com> wrote:

On Sun, Feb 11, 2018 at 12:44:52PM +0100, Haïkel Guémar wrote:

On 02/11/2018 12:17 AM, Sagi Shnaidman wrote:

Hi,

I see openstack-check has 53 hours queue when 1 job only is queued:
https://review.rdoproject.org/zuul/

Seems like problem with nodepool?

Thanks

--
Best regards
Sagi Shnaidman


___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org



Ok, it looks bad enough that a simple nodepool list fails with that error:
os_client_config.exceptions.OpenStackConfigException: Cloud rdo-cloud was
not found.

Despite RDO Cloud looks up, there might be an outage or incident hence
copying David Manchado.

Regards,
H.


Okay, I have to run, but this looks like a configuration issue. It is hard to
tell without debug logs for nodepool or zuul, but please double check your node
is setup properly.

I have to run now.



___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Re: [rdo-dev] Long queue in RDO SF

[Haïkel Guémar]

On 02/11/2018 12:17 AM, Sagi Shnaidman wrote:

Hi,

I see openstack-check has 53 hours queue when 1 job only is queued:
https://review.rdoproject.org/zuul/

Seems like problem with nodepool?

Thanks

--
Best regards
Sagi Shnaidman


___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org



Ok, it looks bad enough that a simple nodepool list fails with that error:
os_client_config.exceptions.OpenStackConfigException: Cloud rdo-cloud 
was not found.


Despite RDO Cloud looks up, there might be an outage or incident hence 
copying David Manchado.


Regards,
H.

___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Re: [rdo-dev] Missing packages for ppc64le builds of RDO

[Haïkel Guémar]

On 02/08/2018 08:47 AM, Tony Breeds wrote:

On Thu, Feb 08, 2018 at 08:37:39AM +0100, Haïkel Guémar wrote:


Just make sure it is available in the buildroot (root.log shows missing
packages). In this case, liberasurecode was tagged in
cloud7-openstack-queens-testing, not cloud7-openstack-queens-candidate which
is the tag from where packages are pulled for the buildroot, so I had to
manually tag it.


So something like:
 koji -p cbs add-pkg cloud7-openstack-queens-candidate liberasurecode
?



To apply a tag on a specific build:
koji -p cbs tag-build cloud7-openstack-queens-candidate 

the add-pkg command will register the package to the 
cloud7-openstack-queens-candidate tag. It could be a pre-requisite, if 
it wasn't the case as you can't apply a tag on a build if the package is 
not registered to the tag.




If so I'm kicking myself 'cause I nearly did that yesterday.

Yours Tony.



___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Re: [rdo-users] firewall_driver in nova-dist.conf

[Haïkel Guémar]

On 02/05/2018 07:34 PM, iain MacDonnell wrote:

Hi,

Is there a reason for this to be in /usr/share/nova/nova-dist.conf ?

firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver

From
https://docs.openstack.org/nova/pike/configuration/config.html#DEFAULT.firewall_driver



:


"firewall_driver Type:string 
Default:nova.virt.firewall.NoopFirewallDriver


Firewall driver to use with nova-network service. This option only 
applies when using the nova-network service. When using another 
networking services, such as Neutron, this should be to set to the 
nova.virt.firewall.NoopFirewallDriver. Possible values: * 
nova.virt.firewall.IptablesFirewallDriver * 
nova.virt.firewall.NoopFirewallDriver * 
nova.virt.libvirt.firewall.IptablesFirewallDriver * […] Related 
options: * use_neutron: This must be set to False to enable 
nova-network networking


Warning This option is deprecated for removal since 16.0.0. Its value
may be silently ignored in the future. Reason: nova-network is
deprecated, as are any related configuration options."


Since "use_neutron" is default, it appears to be inappropriate to
set firewall_driver at all, and especially to set it to the Iptables
one.

For my Ocata deployments, I had explicitly set firewall_driver to
the Noop one (in nova.conf), but when I went to Pike, I decided to
clean up some of the deprecated options in my config, and, according
to the docs (above), it seemed like firewall_driver should be
removed completely then I ran into an obscure issue (sometimes
when an instance got terminated, all other instances on the same
compute node became unreachable), which turned out to be nova and
neutron fighting over the content of the iptables "FORWARD" chain. I
was unaware of the setting in nova-dist.conf (which led to a "fun"
diagnostic process)

If there's not a good reason for the option to be there, I suppose I 
can submit a bug report?




Good point, you can submit bug report or fix it directly :)

Here's the file in the packaging repository:
https://github.com/rdo-packages/nova-distgit/blob/rpm-master/nova-dist.conf

Fix it, commit it and then submit it through gerrit.


As *-dist.conf are rarely touched, feel free to review it and submit
other changes you feel worthy to be discussed.


Regards,
H.


~iain ___ users mailing
list users@lists.rdoproject.org 
http://lists.rdoproject.org/mailman/listinfo/users


To unsubscribe: users-unsubscr...@lists.rdoproject.org


___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

[rdo-users] [Meeting] RDO meeting (2018-01-10) minutes

[Haïkel]

==
#rdo: RDO meeting - 2018-01-10
==


Meeting started by number80 at 15:03:07 UTC.  The full logs are
available at
http://eavesdrop.openstack.org/meetings/rdo_meeting___2018_01_10/2018/rdo_meeting___2018_01_10.2018-01-10-15.03.log.html
.



Meeting summary
---

* roll call  (number80, 15:03:13)

* DLRN Fedora Rawhide builder issues  (number80, 15:04:59)
  * jpena will be working on a new DLRN fedora builder  (number80,
15:16:59)

* Move Q3 test day to Feb 8, 9 (conflict with FOSDEM)  (number80,
  15:20:44)
  * AGREED: Move M3 test days to Feb 8, 9  (number80, 15:24:34)
  * ACTION: rbowen will announce the M3 test days change to Feb 8, 9
(number80, 15:27:15)

* [Octavia] Providing service VM images in RDO  (number80, 15:27:49)
  * LINK:
https://lists.rdoproject.org/pipermail/dev/2018-January/008482.html
(number80, 15:28:59)

* rdopkg is now available for testing in F25+ and EPEL7  (number80,
  15:39:19)
  * LINK:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b2c3f7fabb
(number80, 15:39:47)
  * how to install rdopkg? just dnf/yum it!  (number80, 15:41:08)
  * EPEL 7 rdopkg build in testing:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b2c3f7fabb
(jruzicka, 15:42:15)
  * for cleanup, nuke jruzicka/rdopkg copr repo  (jruzicka, 15:43:07)

* FOSDEM openstack booth volunteers  (number80, 15:44:16)
  * LINK: https://etherpad.openstack.org/p/fosdem-2018  (number80,
15:44:32)

* PTG interviews with Rich  (number80, 15:47:04)

* next week meeting chair  (number80, 15:49:51)
  * chandankumar is chairing next week meeting  (number80, 15:50:36)

* open floor  (number80, 15:50:47)
  * LINK:

https://rdo.fsn.ponee.io/thread.html/1e8105a4c9bc869d1d2754f1cf307c7b342abf5b7a89ffcde8f2832c@%3Cdev.lists.rdoproject.org%3E
(chandankumar, 15:51:33)



Meeting ended at 15:54:33 UTC.



Action items, by person
---

* rbowen
  * rbowen will announce the M3 test days change to Feb 8, 9



People present (lines said)
---

* number80 (77)
* amoralej (26)
* jruzicka (21)
* rbowen (19)
* jpena (17)
* bcafarel (12)
* chandankumar (9)
* openstack (8)
* jschlueter (4)
* tbarron (3)
* mary_grace (2)
* rdogerrit (1)
* dmsimard (1)
* mfedosin (1)
* chem (1)



Generated by `MeetBot`_ 0.1.4
___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

Re: [rdo-dev] Possibly moving Q3 test day date (Feb 1, 2 -> Feb 8, 9)

[Haïkel Guémar]

On 08/01/2018 17:06, Rich Bowen wrote:
The last couple of years, the Milestone 3 test date has fallen on the 
Thursday, Friday before FOSDEM, which has resulted in certain key 
players being absent, and test day essentially not happening.


I'd like to move the Q3 test day to February 8, 9, so that we can have a 
better turnout. It also gives us an opportunity to promote the test day 
at three in-person events - DevConf.cz, the CentOS Dojo, and FOSDEM - 
and possibly have some more "outsiders" join us for this one.


Thoughts?

--Rich




Since I'll be at CentOS dojo too, I'm +1'ing this but let's discuss this 
and vote during our wednesday meeting


H.
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

[rdo-users] [Meeting] RDO meeting (2017-12-06) minutes

[Haïkel]

==
#rdo: RDO meeting - 2017-12-06
==


Meeting started by number80 at 15:00:26 UTC.  The full logs are
available at
http://eavesdrop.openstack.org/meetings/rdo_meeting___2017_12_06/2017/rdo_meeting___2017_12_06.2017-12-06-15.00.log.html
.



Meeting summary
---

* roll call  (number80, 15:00:38)

* building py3 services  (number80, 15:05:55)

* test days  (number80, 15:17:47)
  * LINK: https://etherpad.openstack.org/p/RDO-Meeting  (number80,
15:20:59)
  * LINK: https://etherpad.openstack.org/p/rdo-queens-m2-cloud
(dmsimard, 15:21:01)
  * LINK:
https://dmsimard.com/2017/11/29/come-try-a-real-openstack-queens-deployment/
(dmsimard, 15:21:11)
  * trystack setup for test days is ongoing  (number80, 15:24:47)
  * ACTION: all spread the word about test days  (number80, 15:24:59)
  * ACTION: number80 add new items in "does it work"  (number80,
15:28:38)

* Last chance to submit a talk for the CentOS Dojo at FOSDEM:
  https://goo.gl/forms/FVOEtVOukuCGEnsG2  (number80, 15:30:17)
  * LINK: https://goo.gl/forms/FVOEtVOukuCGEnsG2  (number80, 15:30:35)

* Both OpenStack and CentOS will have stands at FOSDEM this year
  (number80, 15:34:19)
  * we're looking for volunteers to man the OpenStack and CentOS booth
at FOSDEM  (number80, 15:37:14)

* open floor  (number80, 15:37:48)
  * easyfix is looking for new projects ideas  (number80, 15:38:26)
  * LINK: https://github.com/redhat-openstack/easyfix/issues  (number80,
15:38:44)
  * ACTION: chandankumar to chair next week meeting  (number80,
15:40:35)



Meeting ended at 15:41:59 UTC.



Action items, by person
---

* chandankumar
  * chandankumar to chair next week meeting
* number80
  * number80 add new items in "does it work"



People present (lines said)
---

* number80 (72)
* rbowen (27)
* dmsimard (13)
* tosky (8)
* chandankumar (8)
* jruzicka (7)
* openstack (6)
* ykarel (4)
* rdogerrit (2)
* mary_grace (2)
* myoung|ruck (1)
* Duck (1)



Generated by `MeetBot`_ 0.1.4
___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

Re: [rdo-users] [rdo-dev] [all] Revisiting RDO Technical Definition of Done

[Haïkel Guémar]

On 29/11/2017 15:46, Alfredo Moralejo Alonso wrote:



On Wed, Nov 29, 2017 at 3:32 PM, Haïkel <hgue...@fedoraproject.org 
<mailto:hgue...@fedoraproject.org>> wrote:


2017-11-29 13:16 GMT+01:00 Alan Pevec <ape...@redhat.com
<mailto:ape...@redhat.com>>:
> Hi all,
>
> we as a community last discussed RDO definition of done more than a
> year ago and it was documented[1]
>
> In  the meantime we have multiple changes in the RDO promotion
> process, most significant is that we do not run all the CI promotion
> jobs in the single Jenkins pipeline, instead there is now an
> increasing number of periodic Zuul jobs in review.rdoproject.org 
<http://review.rdoproject.org>
> reporting to DLRN API database.
> Promotion is performed asynchronously when all the required jobs report 
success.
>
> At the same time, TripleO as the deployment project with the most
> coverage in the promotion CI, has moved to be completely containerized
>  in Queens.
> While RDO does provide container registry which is used with RDO
> Trunk, there aren't currently plans to provide containers built from
> the stable RPM builds as discussed on this list [2] around Pike GA.
> Even if we do all the work listed in [2] problem stays that containers
> are currently installer specific and we cannot realistically provide
> separate set of containers for each of TripleO, Kolla, OSA...
>

It makes sense as RDO is installer-agnostic. It's an opportunity to
reconsider how
we collaborate with those projects.

> Proposal would be to redefine DoD as follows:
> - RDO GA release delivers RPM packages via CentOS Cloud SIG repos,
> built from pristine upstream source tarballs

ack

> - CI promotion GA criteria is changed from Jenkins pipeline to the
> list of jobs running with RPM packages directly, initial set would be
> all weirdo jobs running in [3]

I'd like to ensure that TripleO CI is still monitored closely during
the development cycle.
So it can be a non-blocking criteria for GA.

As Javier noticed it means that our jobs will be based upon POI and
packstack. It should encourage
us to work with other installers supporting "raw" packages to make
sure that we will be able to test our
artefacts long-term.

> - TripleO jobs would not be part of RDO GA criteria since TripelO now
> requires containers which RDO will not ship.TripleO promotion CI will
> continue running with containers built with RDO Trunk packages.
>

Question is to know if upstream is okay with shipping containers
images using
our trunk packages. Otherwise ack.


Would it make sense to include a job to build containers using RPMs 
cloudsig repos as release criteria?, I'm not talking about publish those 
containers, just make sure that they can be built using kolla with 
tripleo overrides.




Partially yes, we still need to run the full suite of tests during 
development cycle so that we don't discover very late packaging issues.
But in a sense, it shouldn't be a blocker, as David pointed out, nearing 
GA, our packaging should be in a good shape, so installers bugs should 
not block us.
But it's only true if we pay attention to keep containers building and 
running using our packages during the whole cycle.


H.

Regards,
H.

 > I'm adding this topic on the agenda for the RDO meeting today, I
won't
 > be able to join but we need to get that discussion going so we have
 > updated DoD ready for Queens GA.
 >
 > Cheers,
 > Alan
 >
 > [1]
https://www.rdoproject.org/blog/2016/05/technical-definition-of-done/ 
<https://www.rdoproject.org/blog/2016/05/technical-definition-of-done/>
 > [2]
https://www.redhat.com/archives/rdo-list/2017-August/msg00069.html
<https://www.redhat.com/archives/rdo-list/2017-August/msg00069.html>
 > [3]

https://ci.centos.org/view/rdo/view/promotion-pipeline/job/rdo_trunk-promote-master-current-tripleo/

<https://ci.centos.org/view/rdo/view/promotion-pipeline/job/rdo_trunk-promote-master-current-tripleo/>
 > ___
 > dev mailing list
 > d...@lists.rdoproject.org <mailto:d...@lists.rdoproject.org>
 > http://lists.rdoproject.org/mailman/listinfo/dev
<http://lists.rdoproject.org/mailman/listinfo/dev>
 >
 > To unsubscribe: dev-unsubscr...@lists.rdoproject.org
<mailto:dev-unsubscr...@lists.rdoproject.org>
___
dev mailing list
d...@lists.rdoproject.org <mailto:d...@lists.rdoproject.org>
http://lists.rdoproject.org/mailman/listinfo/dev
<

Re: [rdo-users] [rdo-dev] [all] Revisiting RDO Technical Definition of Done

[Haïkel]

2017-11-29 13:16 GMT+01:00 Alan Pevec :
> Hi all,
>
> we as a community last discussed RDO definition of done more than a
> year ago and it was documented[1]
>
> In  the meantime we have multiple changes in the RDO promotion
> process, most significant is that we do not run all the CI promotion
> jobs in the single Jenkins pipeline, instead there is now an
> increasing number of periodic Zuul jobs in review.rdoproject.org
> reporting to DLRN API database.
> Promotion is performed asynchronously when all the required jobs report 
> success.
>
> At the same time, TripleO as the deployment project with the most
> coverage in the promotion CI, has moved to be completely containerized
>  in Queens.
> While RDO does provide container registry which is used with RDO
> Trunk, there aren't currently plans to provide containers built from
> the stable RPM builds as discussed on this list [2] around Pike GA.
> Even if we do all the work listed in [2] problem stays that containers
> are currently installer specific and we cannot realistically provide
> separate set of containers for each of TripleO, Kolla, OSA...
>

It makes sense as RDO is installer-agnostic. It's an opportunity to
reconsider how
we collaborate with those projects.

> Proposal would be to redefine DoD as follows:
> - RDO GA release delivers RPM packages via CentOS Cloud SIG repos,
> built from pristine upstream source tarballs

ack

> - CI promotion GA criteria is changed from Jenkins pipeline to the
> list of jobs running with RPM packages directly, initial set would be
> all weirdo jobs running in [3]

I'd like to ensure that TripleO CI is still monitored closely during
the development cycle.
So it can be a non-blocking criteria for GA.

As Javier noticed it means that our jobs will be based upon POI and
packstack. It should encourage
us to work with other installers supporting "raw" packages to make
sure that we will be able to test our
artefacts long-term.

> - TripleO jobs would not be part of RDO GA criteria since TripelO now
> requires containers which RDO will not ship.TripleO promotion CI will
> continue running with containers built with RDO Trunk packages.
>

Question is to know if upstream is okay with shipping containers images using
our trunk packages. Otherwise ack.

Regards,
H.

> I'm adding this topic on the agenda for the RDO meeting today, I won't
> be able to join but we need to get that discussion going so we have
> updated DoD ready for Queens GA.
>
> Cheers,
> Alan
>
> [1] https://www.rdoproject.org/blog/2016/05/technical-definition-of-done/
> [2] https://www.redhat.com/archives/rdo-list/2017-August/msg00069.html
> [3] 
> https://ci.centos.org/view/rdo/view/promotion-pipeline/job/rdo_trunk-promote-master-current-tripleo/
> ___
> dev mailing list
> d...@lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
>
> To unsubscribe: dev-unsubscr...@lists.rdoproject.org
___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

Re: [rdo-dev] [all] Revisiting RDO Technical Definition of Done

[Haïkel]

2017-11-29 13:16 GMT+01:00 Alan Pevec :
> Hi all,
>
> we as a community last discussed RDO definition of done more than a
> year ago and it was documented[1]
>
> In  the meantime we have multiple changes in the RDO promotion
> process, most significant is that we do not run all the CI promotion
> jobs in the single Jenkins pipeline, instead there is now an
> increasing number of periodic Zuul jobs in review.rdoproject.org
> reporting to DLRN API database.
> Promotion is performed asynchronously when all the required jobs report 
> success.
>
> At the same time, TripleO as the deployment project with the most
> coverage in the promotion CI, has moved to be completely containerized
>  in Queens.
> While RDO does provide container registry which is used with RDO
> Trunk, there aren't currently plans to provide containers built from
> the stable RPM builds as discussed on this list [2] around Pike GA.
> Even if we do all the work listed in [2] problem stays that containers
> are currently installer specific and we cannot realistically provide
> separate set of containers for each of TripleO, Kolla, OSA...
>

It makes sense as RDO is installer-agnostic. It's an opportunity to
reconsider how
we collaborate with those projects.

> Proposal would be to redefine DoD as follows:
> - RDO GA release delivers RPM packages via CentOS Cloud SIG repos,
> built from pristine upstream source tarballs

ack

> - CI promotion GA criteria is changed from Jenkins pipeline to the
> list of jobs running with RPM packages directly, initial set would be
> all weirdo jobs running in [3]

I'd like to ensure that TripleO CI is still monitored closely during
the development cycle.
So it can be a non-blocking criteria for GA.

As Javier noticed it means that our jobs will be based upon POI and
packstack. It should encourage
us to work with other installers supporting "raw" packages to make
sure that we will be able to test our
artefacts long-term.

> - TripleO jobs would not be part of RDO GA criteria since TripelO now
> requires containers which RDO will not ship.TripleO promotion CI will
> continue running with containers built with RDO Trunk packages.
>

Question is to know if upstream is okay with shipping containers images using
our trunk packages. Otherwise ack.

Regards,
H.

> I'm adding this topic on the agenda for the RDO meeting today, I won't
> be able to join but we need to get that discussion going so we have
> updated DoD ready for Queens GA.
>
> Cheers,
> Alan
>
> [1] https://www.rdoproject.org/blog/2016/05/technical-definition-of-done/
> [2] https://www.redhat.com/archives/rdo-list/2017-August/msg00069.html
> [3] 
> https://ci.centos.org/view/rdo/view/promotion-pipeline/job/rdo_trunk-promote-master-current-tripleo/
> ___
> dev mailing list
> dev@lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
>
> To unsubscribe: dev-unsubscr...@lists.rdoproject.org
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

[rdo-users] [Fedora] Please reassign your packages to the OpenStack SIG

[Haïkel]

Hi,

We've now created the Fedora OpenStack SIG [1] to allow shared
maintenance of clients
and easier sync from RDO.
In order to do so, we need you to reassign OpenStack-related packages
and core dependencies to
the SIG. If it's in rdoinfo [2], then it should be owned by the SIG.

If you want to join the SIG, please contact us or join the weekly irc
meeting [3].
We want to semi-automate sync for OpenStack clients, and allow more
people helping to fix core deps
in Fedora.
This way, we can provide better user experience for Fedora users, and
limit forking dependencies from
Fedora [4]


=== How to reassign Fedora Packages to openstack-sig ===

Now, that pkgdb is deprecated, you must go through Fedora's instance
of Pagure and
add the "openstack-sig" group as admin of your package.

Fastest way is to visit the following page:
https://src.fedoraproject.org/rpms//addgroup

Autocompletion should help you to find the group "openstack-sig" and
then set it as an admin.
And that's all folks!

Regards,
H.


[1] https://fedoraproject.org/wiki/SIGs/OpenStack
[2] https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml
[3] https://etherpad.openstack.org/p/RDO-Meeting
[4] when it makes sense, we want to behave as good citizens within Fedora!
___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

[rdo-users] [Meeting] RDO meeting (2017-11-15) minutes

[Haïkel]

==
#rdo: RDO meeting - 2017-11-15
==


Meeting started by dmsimard at 15:02:51 UTC.  The full logs are
available at
http://eavesdrop.openstack.org/meetings/rdo_meeting___2017_11_15/2017/rdo_meeting___2017_11_15.2017-11-15-15.02.log.html
.



Meeting summary
---

* rollcall  (dmsimard, 15:03:37)

* Queens Test day  (hguemar, 15:04:54)
  * LINK: https://www.rdoproject.org/testday/queens/milestone1/
(hguemar, 15:06:43)
  * ACTION: hguemar sends reminder about test day on user/devel lists
(hguemar, 15:09:17)

* rdopkg: what to do with `rdopkg update-patches`?  (hguemar, 15:09:46)
  * `rdopkg patch -l --bump-only` is smarter and more robust alternative
to old `rdopkg update-patches` (which is in turn a rewrite on
ancient `update-patches.sh` script that started this whole patches
branch thing)  (jruzicka, 15:10:14)
  * users tell me it's convenient to have a `rdopkg patch`-like action
that is guaranteed to work on local patches branch and not overwrite
it (implicit -l/--local-patches)  (jruzicka, 15:10:30)
  * ACTION: jruzicka discuss rdopkg update-patches with jschlueter
(hguemar, 15:17:58)

* rdopkg .spec Release bumping  (hguemar, 15:18:21)
  * under review with some relevant comments:
https://softwarefactory-project.io/r/#/c/10200/  (jruzicka,
15:19:13)
  * ACTION: everyone with mad .spec Release bumping skillz please review
this patch: https://softwarefactory-project.io/r/#/c/10200/
(jruzicka, 15:24:44)

* Looking for new project ideas which can done as a part of easyfix in
  order to foster new contributors  (hguemar, 15:25:37)
  * ACTION: everyone help finding new ideas for easyfix  (hguemar,
15:27:48)
  * LINK:

https://www.rdoproject.org/use/bookmarks/01-tripleo-cheatsheet-deploying-tripleo.pdf
(rbowen, 15:30:43)

* DLRN on TripleO CI usage of GitHub repos  (hguemar, 15:35:04)
  * ACTION: dmsimard to talk to Technical Committee about external
sources in TripleO (follow-up from Denver discussion)  (dmsimard,
15:46:53)

* Upstream LTS releases discussion  (hguemar, 15:50:21)
  * LINK: https://etherpad.openstack.org/p/LTS-proposal  (EmilienM,
15:50:32)
  * LINK:
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124308.html
(EmilienM, 15:53:50)
  * jpena chairing next week  (hguemar, 16:05:07)



Meeting ended at 16:05:34 UTC.



Action items, by person
---

* dmsimard
  * dmsimard to talk to Technical Committee about external sources in
TripleO (follow-up from Denver discussion)
* hguemar
  * hguemar sends reminder about test day on user/devel lists
* jruzicka
  * jruzicka discuss rdopkg update-patches with jschlueter
* **UNASSIGNED**
  * everyone with mad .spec Release bumping skillz please review this
patch: https://softwarefactory-project.io/r/#/c/10200/
  * everyone help finding new ideas for easyfix



People present (lines said)
---

* hguemar (95)
* dmsimard (58)
* EmilienM (38)
* jruzicka (30)
* jpena (26)
* amoralej (19)
* chandankumar (17)
* openstack (12)
* PagliaccisCloud (9)
* rbowen (8)
* adarazs|ruck (4)
* jjoyce (3)
* ykarel (2)
* Duck (2)
* weshay (1)
* myoung (0)



Generated by `MeetBot`_ 0.1.4
___
users mailing list
users@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/users

To unsubscribe: users-unsubscr...@lists.rdoproject.org

New SIG: OpenStack

[Haïkel]

Hi,

I'd like to announce the beginning of a new SIG: OpenStack.

During these last years, I've been more or less maintaining OpenStack
clients, and I'd like to pass over
that (burden) to a SIG.
OpenStack clients/libraries are quite tied to each other, so it is
difficult to maintain them without provenpackager
permissions, and it is also a lot of work to sync requirements, do the
testing. So we will be working with RDO project
to provide latest and validated OpenStack clients packaging.

We already have ten packagers who signed up [1], and we welcome anyone
who wants to help [2].

So what are our immediate plans:
1. create @openstack SIG group
2. transfer packages ownership to @openstack SIG
3. set up CI jobs to regularly test and validate Fedora OpenStack
clients packages.
4. automate packages syncing with RDO (still require human validation,
no bot!) [3]
5. Enjoy latest and validated OpenStack clients on Fedora.

For now, the focus will be solely on clients.

Regards,
H.


[1] Most of them are either upstream developers and/or active in RDO
and Fedora projects
[2] If you're new in packaging, feel free to join, I'd be happy to
mentor/sponsor you!
[3] RDO has already automated most packaging tasks, and has proper CI
to test against real OpenStack deployments
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Complicated problem: kiwi and kiwi-gtk conflict

[Haïkel]

2017-08-23 14:44 GMT+02:00 Miroslav Suchý :
> Dne 23.8.2017 v 11:40 Neal Gompa napsal(a):
>>
>> However, there's a problem. It seems python-kiwi already exists in
>> Fedora[4], and it's the kiwi-gtk framework[5].
>>
>> I'm not sure what to do in this scenario. I've requested from upstream
>> to rename the module[6], but I don't think they'll go for that,
>> especially since they actually do have the kiwi name in PyPI.
>>
>> So what can I do?
>
>
> Ask hguemar (owner of python-kiwi in fedora) to rename python-kiwi to
> python-kiwi-gtk.
>
> Mirek

Since it got renamed in pypi, ok, but Neal will have to review the
renamed package.

H.

> ___
> 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: [Openstack] [openstack-dev] package gluster-swift with Openstack swift repository

[Haïkel]

2017-08-10 9:52 GMT+02:00 Venkata R Edara :
> Hello All,
>
> we are from Red Hat and we have product called Gluster which is distributed
> file system. we have integrated Gluster with openstack-swift , the product
> is called
>
> gluster-swift . gluster-swift allows users to have SWIFT/S3 APIs with
> Gluster filesystem as back-end. we did re-base of gluster-swift with
> openstack-swift Newton release.
>
> As gluster-swift is dependent on openstack-swift we would like to have it
> packaged in openstack-swift newton repository.
>
> Is it possible to package gluster-swift project in openstack repository?.
>
> we would like to know the process of packaging with openstack repo if
> openstack community agrees for that.
>
> -Thanks
>
> Venkata R Edara.
>
>

Hi,

AFAIK, shipping binary packages is the responsibility of downstream
distributions of OpenStack, though
there are efforts to collaborate on packaging within OpenStack.
I'm one of the RDO Release Engineer, RDO community would be happy to
help you packaging gluster-swift.
Please contact the RDO mailing list or join RDO weekly irc meetings.

Regards,
H.


> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] package gluster-swift with Openstack swift repository

[Haïkel]

2017-08-10 9:52 GMT+02:00 Venkata R Edara :
> Hello All,
>
> we are from Red Hat and we have product called Gluster which is distributed
> file system. we have integrated Gluster with openstack-swift , the product
> is called
>
> gluster-swift . gluster-swift allows users to have SWIFT/S3 APIs with
> Gluster filesystem as back-end. we did re-base of gluster-swift with
> openstack-swift Newton release.
>
> As gluster-swift is dependent on openstack-swift we would like to have it
> packaged in openstack-swift newton repository.
>
> Is it possible to package gluster-swift project in openstack repository?.
>
> we would like to know the process of packaging with openstack repo if
> openstack community agrees for that.
>
> -Thanks
>
> Venkata R Edara.
>
>

Hi,

AFAIK, shipping binary packages is the responsibility of downstream
distributions of OpenStack, though
there are efforts to collaborate on packaging within OpenStack.
I'm one of the RDO Release Engineer, RDO community would be happy to
help you packaging gluster-swift.
Please contact the RDO mailing list or join RDO weekly irc meetings.

Regards,
H.


> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: Nonresponsive maintainer: attempting to contact kanarip

[Haïkel]

2017-06-23 12:39 GMT+02:00 James Hogarth :
> Hi,
>
> Has anyone heard from kanarip or able to contact him?
>
> I've been attempting to contact for this bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1223593
>
> If there's no response in one week an issue will be filed with FESCo
> following the nonrepsonsive maintainer policy to review the ownership
> status of the packages.
>
> For ruby maintainers please note that this has a significant impact on
> you, if you want to keep track of this, as he owns puppet, rubygems
> and ruby ...
>
> https://admin.fedoraproject.org/pkgdb/packager/kanarip/
>

You're making it sound like Puppet is unmaintained which is not accurate.
There are many comaintainers and provenpackagers working on it.

Regards,
H.

> Regards,
>
> James
> ___
> 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: Assemblée Générale ordinaire GNOME-FR

[Haïkel]

Le 13 juin 2017 à 10:55, Bastien Nocera  a écrit :
> Salut,
>
> On Fri, 2017-05-19 at 17:04 +0200, liberfo...@freeside.fr wrote:
>> Oyez, oyez, braves GNOMistes,
>>
>> cela fait moultes et moultes lunes que nous ne nous sommes pas
>> retrouvés
>> pour festoyer et évoquer le devenir de l'association GNOME-FR.
>
> Ça fait presque un mois que la discussion a été lancée. On la fait
> quand cette AG alors? :)
>
> A+
>

Question con: online ou offline? Si c'est online, pourquoi pas demain?


> ___
> gnome-fr-list mailing list
> gnome-fr-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-fr-list

___
gnome-fr-list mailing list
gnome-fr-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-fr-list

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Haïkel]

2017-06-13 0:38 GMT+02:00  :
> In preparation for the Final Freeze on 2017-06-27 Release
> Engineering will retire all packages in Branched with broken dependencies and
> all packages depending on these. If you get this e-mail directly this affects
> at least one of your packages. Please fix the broken dependency as soon as
> possible.  If you know for sure that the package should be retired, please do
> so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
>   Package(co)maintainers  Status Change
> ===
> AcetoneISO spot   160 weeks ago
> OmegaT olea, mtasaka  160 weeks ago
> RackTables coec   160 weeks ago
> Raysebhtml, jussilehtola  160 weeks ago
> YafaRayluya, slaanesh 15 weeks ago
> asterisk   jsmith, gtjoseph, itamarjp,83 weeks ago
>lbazan, russellb
> atomicapp  vpavlin, golang-sig,   103 weeks ago
>jchaloup, lalatendu
> ayttm  mintojoseph160 weeks ago
> banshee-community-extensions   chkr, elsupergomez 160 weeks ago
> beacon satyak 160 weeks ago
> compat-gcc-34  jakub  160 weeks ago
> consul fpokorny, golang-sig,  74 weeks ago
>jchaloup, sspreitz
> eclipse-avrvladimirk, akurtakov   160 weeks ago
> eflspot, dchen, sereinit  114 weeks ago
> elemental  rhl27 weeks ago
> erlang-riak_pipe   peter, erlang-sig  160 weeks ago
> etcd   jchaloup, avesh, cypret,   110 weeks ago
>eparis, golang-sig,
>gscrivano, jcajka, lsm5,
>peter, walters
> fedora-dockerfiles adimania, lsm5, scollier   130 weeks ago
> floppy-support bruno  160 weeks ago
> fusionforgebeuc, nerville 136 weeks ago
> gcc-python-plugin  dmalcolm, jakub160 weeks ago
> gearmand   ktdreyer, blakegardner 160 weeks ago
> getdp  ignatenkobrain, group  80 weeks ago
>::neuro-sig, smani
> gif2pngsundaram   160 weeks ago
> git-annex  mathstuf, haskell-sig  160 weeks ago
> gofed  jchaloup, fale, golang-sig 115 weeks ago
> golang-github-docker-go-   jchaloup   65 weeks ago
> connections
> golang-github-docker-  fpokorny, eparis, jchaloup,95 weeks ago
> libcontainer   lsm5, vbatts
> golang-github-fsouza-go-   fpokorny, eparis, golang-  95 weeks ago
> dockerclient   sig, jchaloup, lsm5,
>maxamillion
> golang-github-gonum-matrix fpokorny, jchaloup 86 weeks ago
> golang-github-kubernetes-  fpokorny, jchaloup 86 weeks ago
> heapster
> golang-github-mistifyio-go-jchaloup   57 weeks ago
> zfs
> golang-github-samalba- fpokorny, golang-sig,  97 weeks ago
> dockerclient   jchaloup
> golang-googlecode-go-exp   fpokorny, golang-sig,  97 weeks ago
>jchaloup, lsm5, vbatts
> grass  devrim, neteler, oliver,   160 weeks ago
>pertusus, rezso, volter
> gyachi sundaram, ghosler  160 weeks ago
> homerunjmarrero   160 weeks ago
> iwhd   meyering, clalance, zaitcev160 weeks ago
> java-gnome abo160 weeks ago
> kf5-libkface   rdieter70 weeks ago
> ledger radford, jamielinux160 weeks ago
> libsmbios  mebrown, gunnersrini,  33 weeks ago
>praveenp
> lldb   airlied, daveisfera,   71 weeks ago
>jankratochvil, jvcelak,
>siddharths, tstellar
> meshlabbrouhaha   160 weeks ago
> mesos  

Re: [Openstack] Deployment for production

[Haïkel]

2017-05-03 10:41 GMT+02:00 Fawaz Mohammed :
> Hi Satish,
>
> I believe RDO is not meant to be for production. I prefer to use the
> original upstream project "TripleO" as they have better documentation.
>

It is meant for production, but it is community-support.
I won't comment further but many people are working on RDO to make it
usable either as full-time RH employees (such as myself) or community
contributor (as I did previously).

Regards,
H.

> Other production grade deployment tools are:
> Fuel:
> https://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide.html
> Support CentOS and Ubuntu as hosts.
>
> Charm:
> https://docs.openstack.org/developer/charm-guide/
> Support Ubuntu only.
>
>
> On May 3, 2017 11:00 AM, "Satish Patel"  wrote:
>>
>> We did POC on RDO and we are happy with product but now question is,
>> should we use RDO for production deployment or other open source flavor
>> available to deploy on prod. Not sure what is the best method of production
>> deployment?
>>
>> Sent from my iPhone
>> ___
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Fedora-legal-list] Re: SPDX license tags and Rust packaging

[Haïkel]

2017-02-23 15:31 GMT+01:00 Neal Gompa :
> Hello all,
>
> I know that it's been discussed from time to time about using SPDX
> identifiers for our license tags[1][2]. In the Rust SIG, we're
> beginning the work to figure out the packaging of Rust things. Cargo,
> the Rust equivalent of Python's pip, enforces the usage of SPDX
> identifiers for license tags in the Cargo.toml (the file indicating
> the metadata of a "crate").
>
> If we're considering using SPDX identifiers for license tags (as it
> appeared to be the case in Tom's FOSDEM talk[3]), would it be possible
> to grant us the ability to just use that data instead of having to
> attempt to maintain a mapping of SPDX to Fedora short tags? Since our
> ecosystem in Fedora is basically zero right now, we could avoid the
> ugliness right from the get-go.
>

This is just my opinion.
1. I do not see any justification to grant a specific exception *only*
to the Rust SIG
2. The mapping is quite straightforward for most cases (Cf. the
discussion on fedora-legal),
so technically it's not uglier than what other languages packaging utilities do.

For example, this is how pyp2rpm converts pypi classifiers into Fedora
short tags, this is quite simple code.
https://github.com/fedora-python/pyp2rpm/blob/87f25610ef957a0738f31b217b8017cd2b1325d3/pyp2rpm/utils.py#L90
https://github.com/fedora-python/pyp2rpm/blob/87f25610ef957a0738f31b217b8017cd2b1325d3/pyp2rpm/settings.py#L23
For SPDX, it can't be more complex, I would even say it should be even simpler.

I still think that we should move to SPDX but maintaining consistency
within the distro is also important.

Regards,
H.


> Thanks and best regards,
> Neal
>
> [1]: 
> https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/2BU5JTWLCQWRSPMORNPJLOPLDYHINGMV/
> [2]: 
> https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/YT7A6MROI3CZNNEKO6RKLD3GG7NNL2LU/
> [3]: https://fosdem.org/2017/schedule/event/fedoras_legal_state/
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
___
legal mailing list -- legal@lists.fedoraproject.org
To unsubscribe send an email to legal-le...@lists.fedoraproject.org

Re: Self Introduction: Stephen Kitt

[Haïkel]

2017-02-23 18:48 GMT+01:00 Stephen Kitt :
> Hi everyone,
>
> As part of the "join the package collection maintainers" process, I'd like to
> introduce myself — I've just submitted my first review request
> (https://bugzilla.redhat.com/show_bug.cgi?id=1426333).
>
> I'm a long-standing free software user and packager, in the Debian world
> (https://qa.debian.org/developer.php?login=skitt). My packaging interests
> cover a wide spectrum, from games and emulators to toolchains and random
> interesting pieces of software. Some of you might have seen me at Devconf
> where I gave a presentation contrasting the processes for joining Debian and
> Fedora as a packaging contributor
> (https://www.youtube.com/watch?v=pGQFZPA6r8w). I work for Red Hat but
> packaging isn't a big part of my day job (although the request above is
> submitted using my @redhat.com account — it's for OpenDaylight, which is what
> I work on).
>
> I'm looking forward to adding some interesting software to Fedora!
>
> Regards,
>
> Stephen


Hi Stephen,

Welcome to see you here :)
Knowing Stephen afk, I trust him as a FOSS hacker and keen expert in (Debian)
packaging so I'm willing to sponsor him.

Regards,
H.

> ___
> 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: [openstack-dev] [Packaging-RPM] Nominating Alberto Planas Dominguez for Packaging-RPM core

[Haïkel]

2017-02-16 15:43 GMT+01:00 Igor Yozhikov :
> Hello team.
> I want to announce the following changes to Packaging-RPM core team:
> I’d like to nominate Alberto Planas Dominguez known as aplanas on irc for
> Packaging-RPM core.
> Alberto done a lot of reviews for as for project modules [1],[2] as for rest
> of OpenStack components [3]. His experience within OpenStack components and
> packaging are very appreciated.
>

+1
Alberto was nominated for the next cycle and I was and am still supporting this.

Regards,
H.

>
> [1]
> http://stackalytics.com/?metric=marks_type=all=packaging-rpm-group_id=aplanas
> [2]
> http://stackalytics.com/?metric=marks_type=all=packaging-rpm-group
> [3] http://stackalytics.com/?user_id=aplanas=marks
>
> Packaging-RPM team please respond with +1/-1 to the proposed changes.
>
> Thanks,
> Igor Yozhikov
> Senior Deployment Engineer
> at Mirantis
> skype: igor.yozhikov
> cellular: +7 901 5331200
> slack: iyozhikov
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Haïkel]

2017-02-15 13:42 GMT+01:00 Thomas Goirand :
> Hi there,
>
> It's been a while since I planed on writing this message. I couldn't
> write it because the situation makes me really sad. At this point, it
> starts to be urgent to post it.
>
> As for many other folks, Mirantis decided to end its contract with me.
> This happened when I was the most successful doing the job, with all of
> the packaging CI moved to OpenStack infra at the end of the OpenStack
> Newton cycle, after we were able to release Newton this way. I was
> hoping to start packaging on every commit for Ocata. That's yet another
> reason for me to be very frustrated about all of this. Such is life...
>
> Over the last few months, I hoped for having enough strengths to
> continue my packaging work anyway, and get Ocata packages done. But
> that's not what happened. The biggest reason for this is that I know
> that this needs to be a full time job. And at this point, I still don't
> know what my professional future will be. A company, in Barcelona, told
> me I'd get hired to continue my past work of packaging OpenStack in
> Debian, but so far, I'm still waiting for a definitive answer, so I'm
> looking into some other opportunities.
>
> All this to say that, unless someone wants to hire me for it (which
> would be the best outcome, but I fear this wont happen), or if someone
> steps in (this seems unlikely at this point), both the packaging-deb and
> the faith of OpenStack packages in Debian are currently compromised.
>
> I will continue to maintain OpenStack Newton during the lifetime of
> Debian Stretch though, but I don't plan on doing anything more. This
> means that maybe, Newton will be the last release of OpenStack in
> Debian. If things continue this way, I probably will ask for the removal
> of all OpenStack packages from Debian Sid after Stretch gets released
> (unless I know that someone will do the work).
>
> As a consequence, the following projects wont get packages even in
> Ubuntu (as they were "community maintained", which means done by me and
> later sync into Ubuntu...):
>
> - congress
> - gnocchi
> - magnum
> - mistral
> - murano
> - sahara
> - senlin
> - watcher
> - zaqar
>
> Hopefully, Canonical will continue to maintain the other 15 (more
> core...) projects in UCA.
>
> Thanks for the fish,
>
> Thomas Goirand (zigo)
>
> P,S: To the infra folks: please keep the packaging CI as it is, as it
> will be useful for the lifetime of Stretch.
>

I'm sad to hear that as a fellow packager.
You've been a driving force for Debian packaging and improving
OpenStack since its early days.
Your work has helped many people to use OpenStack on Debian and
derived effectively. I hope
that you'll find asap a sponsorship or a dayjob to keep going.

Regards,
H.

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] The end of OpenStack packages in Debian?

[Haïkel]

2017-02-15 13:42 GMT+01:00 Thomas Goirand :
> Hi there,
>
> It's been a while since I planed on writing this message. I couldn't
> write it because the situation makes me really sad. At this point, it
> starts to be urgent to post it.
>
> As for many other folks, Mirantis decided to end its contract with me.
> This happened when I was the most successful doing the job, with all of
> the packaging CI moved to OpenStack infra at the end of the OpenStack
> Newton cycle, after we were able to release Newton this way. I was
> hoping to start packaging on every commit for Ocata. That's yet another
> reason for me to be very frustrated about all of this. Such is life...
>
> Over the last few months, I hoped for having enough strengths to
> continue my packaging work anyway, and get Ocata packages done. But
> that's not what happened. The biggest reason for this is that I know
> that this needs to be a full time job. And at this point, I still don't
> know what my professional future will be. A company, in Barcelona, told
> me I'd get hired to continue my past work of packaging OpenStack in
> Debian, but so far, I'm still waiting for a definitive answer, so I'm
> looking into some other opportunities.
>
> All this to say that, unless someone wants to hire me for it (which
> would be the best outcome, but I fear this wont happen), or if someone
> steps in (this seems unlikely at this point), both the packaging-deb and
> the faith of OpenStack packages in Debian are currently compromised.
>
> I will continue to maintain OpenStack Newton during the lifetime of
> Debian Stretch though, but I don't plan on doing anything more. This
> means that maybe, Newton will be the last release of OpenStack in
> Debian. If things continue this way, I probably will ask for the removal
> of all OpenStack packages from Debian Sid after Stretch gets released
> (unless I know that someone will do the work).
>
> As a consequence, the following projects wont get packages even in
> Ubuntu (as they were "community maintained", which means done by me and
> later sync into Ubuntu...):
>
> - congress
> - gnocchi
> - magnum
> - mistral
> - murano
> - sahara
> - senlin
> - watcher
> - zaqar
>
> Hopefully, Canonical will continue to maintain the other 15 (more
> core...) projects in UCA.
>
> Thanks for the fish,
>
> Thomas Goirand (zigo)
>
> P,S: To the infra folks: please keep the packaging CI as it is, as it
> will be useful for the lifetime of Stretch.
>

I'm sad to hear that as a fellow packager.
You've been a driving force for Debian packaging and improving
OpenStack since its early days.
Your work has helped many people to use OpenStack on Debian and
derived effectively. I hope
that you'll find asap a sponsorship or a dayjob to keep going.

Regards,
H.

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: MongoDB in EPEL7

[Haïkel]

2016-10-31 14:25 GMT+01:00 Marek Skalický :
> Hi,
> current situation:
> EPEL6 - MongoDB 2.4.x
> EPEL7 - MongoDB 2.6.x
>
> Upstream supports only upgrade to next major version. So from 2.4 it is
> supported only to 2.6.
> Therefore I kept MongoDB 2.6 in EPEL7 (even two next major versions are
> released).
>
> But MongoDB 2.6 is going to EOL (probably this week), so MongoDB in
> EPEL7 will be unsupported.
>
> How to solve this - what EPEL/Fedora guidelines says about upgrades?
> Upgrade EPEL6 to EPEL7? Or keep unsupported version in EPEL7?
>

If it's unsupported upstream, you need to send a heads-up on EPEL m-l,
and wait for comments.
Then, just push the update.

I'm working on upgrading MongoDB to 3.2 in the CentOS SIGs space, it
will require a //-installable boost package (I have a working boost159
package) but I'd be glad to share the work.

Regards,
H.

> Thanks,
> Marek
> ___
> 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: [openstack-dev] [daisycloud-core] Kolla Mitaka requirements supported by CentOS

[Haïkel]

Le 12 oct. 2016 6:01 AM, "Steven Dake (stdake)" <std...@cisco.com> a écrit :
>
> Haikel,
>
>
>
> We attempted removing EPEL from our repo lists.  We got build errors on
cinder-volume.  We have iscsi integration because vendors require it to
work with their third party plugins.  The package iscsi-target-utils is not
in the newton repos for RDO.
>
>
>
> The package that fails can be seen here:
>
>
http://logs.openstack.org/04/385104/1/check/gate-kolla-dsvm-build-centos-source-centos-7-nv/f6cc1d8/console.html#_2016-10-11_19_34_40_662928
>
>
>
> If you could fix that up, it would be grand J
>
>

Sorry for the delay, it got in the wrong folder, I'll look into adding this
package.

H.
>
> Thanks
>
> -steve
>
>
>
>
>>
>> From: Haïkel <hgue...@fedoraproject.org>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
>> Date: Saturday, July 2, 2016 at 2:14 PM
>>
>> To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [daisycloud-core] Kolla Mitaka requirements
supported by CentOS
>>
>>
>>
>> 2016-07-02 20:42 GMT+02:00 jason <huzhiji...@gmail.com>:
>>>
>>> Pip Package Name Supported By Centos CentOS
Name  Repo Name
>>>
>>>
==
>>>
>>> ansible   yes
>>>
>>> ansible1.9.noarchepel
>>>
>>> docker-py  yes
>>>
>>> python-docker-py.noarchextras
>>>
>>> gitdb  yes
>>>
>>> python-gitdb.x86_64epel
>>>
>>> GitPython  yes
>>>
>>> GitPython.noarchepel
>>>
>>> oslo.config yes
>>>
>>> python2-oslo-config.noarch centos-openstack-mitaka
>>>
>>> pbryes
>>>
>>> python-pbr.noarch   epel
>>>
>>> setuptools yes
>>>
>>> python-setuptools.noarchbase
>>>
>>> six yes
>>>
>>> python-six.noarch base
>>>
>>> pycryptoyes
>>>
>>> python2-crypto  epel
>>>
>>> graphvizno
>>>
>>> Jinja2no (Note: Jinja2 2.7.2 will be installed as
>>>
>>> dependency by ansible)
>>>
>>>
>>
>>
>>
>> As one of RDO maintainer, I strongly invite kolla, not to use EPEL.
>>
>> It's proven very hard to prevent EPEL pushing broken updates, or push
>>
>> updates to fit OpenStack requirements.
>>
>>
>>
>> Actually, all the dependency above but ansible, docker and git python
>>
>> modules are in CentOS Cloud SIG repositories.
>>
>> If you are interested to work w/ CentOS Cloud SIG, we can add missing
>>
>> dependencies in our repositories.
>>
>>
>>
>>
>>>
>>>
>>>
>>> As above table shows, only two (graphviz and Jinja2) are not supported
>>>
>>> by centos currently. As those not supported packages are definitly not
>>>
>>> used by OpenStack as well as Daisy. So basicaly we can use pip to
>>>
>>> install them after installing other packages by yum. But note that
>>>
>>> Jinja2 2.7.2 will be installed as dependency while yum install
>>>
>>> ansible, so we need to using pip to install jinja2 2.8 after that to
>>>
>>> overide the old one. Also note that we must make sure pip is ONLY used
>>>
>>> for installing those two not supported packages.
>>>
>>>
>>>
>>> But before you trying to use pip, please consider these:
>>>
>>>
>>>
>>> 1) graphviz is just for saving image depend graph text file and is not
>>>
>>> used by default and only used in build process if it is configured to
>>>
>>> be used.
>>>
>>>
>>>
>>> 2) Jinja2 rpm can be found at
>>>
>>> http://koji.fedoraproject.org/koji/packageinfo?packageID=6506, which I
>>>
>>> think is suitable for CentOS. I have tested it.
>>>
>>>
>>>
>>> So, as far as Kolla

Re: [openstack-dev] [openstack-announce] OpenStack Newton is officially released!

[Haïkel]

RDO Newton GA was ready for more than an hour ago, builds are currently running.
Formal publication should happen soon.

Good job to all projects and release mgmt team!

Regards,
H.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging][rpm] 3rd-party gates promotion to voting gates

[Haïkel]

2016-09-26 16:05 GMT+02:00 Anita Kuno <ante...@anteaya.info>:
> On 16-09-26 07:48 AM, Haïkel wrote:
>>
>> Hi,
>>
>> following our discussions about 3rd party gates in RPM packaging project,
>> I suggest that we vote in order to promote the following gates as voting:
>> - MOS CI
>> - SUSE CI
>>
>> After promotion, all patchsets submitted will have to validate these gates
>> in order to get merged. And gates maintainers should ensure that the gates
>> are running properly.
>>
>> Please vote before (and/or during) our thursday meeting.
>>
>>
>> +1 to promote both MOS and SUSE CI as voting gates.
>>
>> Regards,
>> H.
>
>
> I'm not sure what you mean by voting gates. Gates don't vote, an individual
> job can leave a verified +1 in the check queue or/and a verified +2 in the
> gate queue.
>
> Third party CI systems do not vote verified +2 in gerrit. They may if the
> project chooses vote verified +1 on a project.
>

Yeah, that was pretty much what was assumed.
Gates that do not leave verified +1 are called non-voting, so
logically gates that leaves verified +1 are called voting gates.

> If you need clarification in what third party ci systems may do in gerrit,
> you are welcome to reply to this email, join the #openstack-infra channel or
> participate in a third party meeting:
> http://eavesdrop.openstack.org/#Third_Party_Meeting
>
> Thank you,
> Anita.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [packaging][rpm] 3rd-party gates promotion to voting gates

[Haïkel]

Hi,

following our discussions about 3rd party gates in RPM packaging project,
I suggest that we vote in order to promote the following gates as voting:
- MOS CI
- SUSE CI

After promotion, all patchsets submitted will have to validate these gates
in order to get merged. And gates maintainers should ensure that the gates
are running properly.

Please vote before (and/or during) our thursday meeting.


+1 to promote both MOS and SUSE CI as voting gates.

Regards,
H.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [vote][kolla] deprecation for fedora distro support

[Haïkel]

2016-09-21 16:34 GMT+02:00 Steven Dake (stdake) <std...@cisco.com>:
>
>
>
> On 9/20/16, 11:18 AM, "Haïkel" <hgue...@fedoraproject.org> wrote:
>
> 2016-09-19 19:40 GMT+02:00 Jeffrey Zhang <zhang.lei@gmail.com>:
> > Kolla core reviewer team,
> >
> > Kolla supports multiple Linux distros now, including
> >
> > * Ubuntu
> > * CentOS
> > * RHEL
> > * Fedora
> > * Debian
> > * OracleLinux
> >
> > But only Ubuntu, CentOS, and OracleLinux are widely used and we have
> > robust gate to ensure the quality.
> >
> > For fedora, Kolla hasn't any test for it and nobody reports any bug
> > about it( i.e. nobody use fedora as base distro image). We (kolla
> > team) also do not have enough resources to support so many Linux
> > distros. I prefer to deprecate fedora support now.  This is talked in
> > past but inconclusive[0].
> >
> > Please vote:
> >
> > 1. Kolla needs support fedora( if so, we need some guys to set up the
> > gate and fix all the issues ASAP in O cycle)
> > 2. Kolla should deprecate fedora support
> >
> > [0] 
> http://lists.openstack.org/pipermail/openstack-dev/2016-June/098526.html
> >
>
>
> /me has no voting rights
>
> As RDO maintainer and Fedora developer, I support option 2. as it'd be
> very time-consuming to maintain Fedora support..
>
>
> >
> > --
> > Regards,
> > Jeffrey Zhang
> > Blog: http://xcodest.me
> >
>
> Haikel,
>
> Quck Q – are you saying maintaining fedora in kolla is time consuming or that 
> maintaining rdo for fedora is time consuming (and something that is being 
> dropped)?
>

Both, in my experience in maintaining RDO on Fedora, I encountered
similar issues than Kolla. It's doable but a lot of work.
One of the biggest problem are updates, you may have disruptive
updates on python modules packages quite frequently, or even rarer,
get some updates reverted.
So keeping Fedora in a good shape would require a decent amount of efforts.

Regards,
H.



> Thanks for improving clarity on this situation.
>
> Regards
> -steve
>
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [vote][kolla] deprecation for fedora distro support

[Haïkel]

2016-09-19 19:40 GMT+02:00 Jeffrey Zhang :
> Kolla core reviewer team,
>
> Kolla supports multiple Linux distros now, including
>
> * Ubuntu
> * CentOS
> * RHEL
> * Fedora
> * Debian
> * OracleLinux
>
> But only Ubuntu, CentOS, and OracleLinux are widely used and we have
> robust gate to ensure the quality.
>
> For fedora, Kolla hasn't any test for it and nobody reports any bug
> about it( i.e. nobody use fedora as base distro image). We (kolla
> team) also do not have enough resources to support so many Linux
> distros. I prefer to deprecate fedora support now.  This is talked in
> past but inconclusive[0].
>
> Please vote:
>
> 1. Kolla needs support fedora( if so, we need some guys to set up the
> gate and fix all the issues ASAP in O cycle)
> 2. Kolla should deprecate fedora support
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-June/098526.html
>


/me has no voting rights

As RDO maintainer and Fedora developer, I support option 2. as it'd be
very time-consuming to maintain Fedora support..


>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Packaging Rpm] PTL candidacy

[Haïkel]

Fellow RPM packagers,

I announce my candidacy for PTL of the Packaging Rpm project.
During the Newton cycle, we reached the point where we provide enough
artefacts to build OpenStack clients usable on all supported platforms.

As a PTL, my primary focus would be on:
* 3rd party CI: increase coverage and stability so that we can promote
  existing CI to voting gates.  Next step would be allowing other
  projects to consume our packaging for their own CI (mostly installer
  ones)
* better tooling to generate more native packages, and reduce
  churn. Also adding python3 support.
* allowing people to deploy a minimal OpenStack from our
  packages. Rather than focusing on shoving as much services as
  possible, I'd like us to focus on curating a minimal but high
  quality set of packages to build upon it. After such milestone,
  adding more services will be much easier later.

Why? The goal is to produce a production-ready and curated set of
OpenStack packages for all supported RPM-based platforms (SUSE, RHEL,
etc.). Such deliverables could be used to seed downstream
distributions and encourage collaboration between them around
packaging. It would also help OpenStack installers CI to test against
fresh OpenStack packages.


Off course, I plan to continue supporting these ongoing efforts:
* extending our packages set
* extending our contributors pool (including core)
* last but not least, foster collaboration between downstream vendors.

Best regards,
H.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging-deb][PTL] candidacy

[Haïkel]

2016-09-12 21:10 GMT+02:00 Thomas Goirand :
> I am writing to submit my candidacy for re-election as the PTL for the
> packaging-deb project.
>
> The idea sparked in Vancouver (spring 2015). The project joined the
> big-tent about a year ago (in August 2015, it was approved by the TC)
> But it then took about a year to have it bootstraped. This was long and
> painful bootstrap, but today, I can proudly announce that it was finally
> well launched. Right now, all of Oslo and python-*client are built, and
> it is a mater of days until all services of Newton is completely built
> in OpenStack infra (Keystone is already there in Newton b2 version).
>
> I'll do my best to continue to drive the project, and hope to gather
> more contribution every day. Every contributor counts.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> P.S: It maybe will be a bit hard to find out who can vote, because only
> the debian/newton branch should count, and currently Stackalytics is
> counting the master which contains upstream commits. Hopefully, we can
> solve the issue before the elections.
>

Thomas has been very helpful in collaborating with other packaging
groups like RPM ones.
So I welcome his candidacy!

Regards,
H.

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] [telemetry] [requirements] [FFE] Oslo.db 4.13.3

[Haïkel]

2016-09-08 19:33 GMT+02:00 Mehdi Abaakouk :
>
>
> Le 2016-09-08 16:21, Matthew Thode a écrit :
>>>
>>> Once it’s in, we’ll trigger another oslo.db release.
>
>
> The release change is ready: https://review.openstack.org/#/c/367482/
>
> I have tested it against Gnocchi we don't have any issue anymore.
>
> Thanks all!
>

Good news, thanks for fixing it!

> --
> Mehdi Abaakouk
> mail: sil...@sileht.net
> irc: sileht
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [packaging-rpm] Javier Peña as additonal core reviewer for packaging-rpm core group

[Haïkel]

2016-09-02 12:45 GMT+02:00 Dirk Müller :
> Hi,
>
> I would like to suggest Javier Peña as an additional core reviewer for
> the packaging-rpm core group. He's been an extremely valueable

+1

Javier has done a good job as a reviewer, and is key contributor to
add RDO 3rd CI.
Good job!

H.




> contributing more to the packaging effort overall.
>
> See http://stackalytics.com/?user_id=jpena-c=rpm-packaging
>
>
> Please reply with +1/-1
>
> Thanks a lot in advance,
> Dirk
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: Update python-django EPEL7

[Haïkel]

2016-08-16 19:11 GMT+02:00 Igor Gnatenko :
> It's against policies. Currently python-django has version 1.6. And
> 1.8 is major release.
>

Wrong.
Django 1.8 is an Long-Term Support version (supported until April,
2018) while 1.6 support ended in April, 2015 (so one year without
security updates ...).
https://www.djangoproject.com/download/#supported-versions
For EPEL, it would be smarter to stick to LTS releases, rather than
sticking to unmaintained releases.

Moreover, updates policies are guidelines to prevent mistakes not
absolute rules.

> On Tue, Aug 16, 2016 at 6:17 PM, Germano Massullo
>  wrote:
>> Hello, I would like to ask if it is possible to update python-django
>> for EPEL7 to, for example, 1.8 version.
>> I am actually going to fill a Review Request for
>> python-django-netjsongraph[1], and among its requirements, there is
>> python-django-rest-framework that cannot actually be packaged for
>> EPEL7 due python-django actual version
>>
>> Thank you
>>
>> [1]: https://github.com/interop-dev/django-netjsongraph
>> ___
>> python-devel mailing list
>> python-devel@lists.fedoraproject.org
>> https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
>
>
>
> --
> -Igor Gnatenko
> ___
> python-devel mailing list
> python-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: FESCo - July 2016 Elections - Result announcement

[Haïkel]

2016-07-26 4:58 GMT+02:00 Jan Kurik :
> Greetings, all!
>
> The elections for FESCo - July 2016 have concluded, and the results
> are shown below.
>
> FESCo is electing 4 seats this time.
> A total of 196 ballots were cast, meaning a candidate
> could accumulate up to 980 votes (196 * 5).
>
> The results for the elections are as follows:
>
>   # votes |  name
> - +--
>  655  | Stephen Gallagher (sgallagh)
>  619  | Josh Boyer (jwb/jwboyer)
>  557  | Dennis Gilmore (dgilmore/ausil)
>  474  | Dominik Mierzejewski (rathann)
> - +--
>  454  | Haikel Guemar (number80/hguemar)
>
>
> Congratulations to the winning candidates, and thank you all
> candidates for running this elections!
>
> --
> Jan Kuřík
> Platform & Fedora Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic



Congratulations to the elected members!

Regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[Fedora-legal-list] Re: Switching to SPDX in license tags redux

[Haïkel]

2016-07-26 3:54 GMT+02:00 Richard Fontana :
> On Mon, Jul 25, 2016 at 01:31:58PM -0400, Tom Callaway wrote:
>> I've been working on and off with SPDX to ensure that there is as
>> minimal as possible deviation between our two lists.
>>
>> If we did want to move forward with this, we'd need to figure out how to
>> resolve the inconsistencies with BSD/MIT between Fedora and SPDX.
>> Additionally, since pretty much every single package would need to be
>> touched for this change (as well as every package awaiting review), this
>> would not be a small effort, and I am _not_ volunteering to undertake it
>> alone, as I do not have the time.
>>
>> I tend be of the opinion that the work involved vastly outweighs the
>> benefit, but if others disagree (and are willing to volunteer their time
>> to work on this), I could be convinced.
>
> The main problem is exemplified by the BSD/MIT case, but it's not
> limited to that. We have a number of instances where a Fedora license
> tag refers to a set of things that are (usefully, I increasingly
> believe) treated as multiple licenses in the SPDX universe. BSD and
> MIT are just the extremes. I.e. it's not just a case of conceptually
> equivalent standards that just happen to use different tokens for
> things.
>
> Would it be possible to gradually evolve towards the SPDX system, say
> on a voluntary basis (by package maintainer), making use of the
> existing RPM license field? For example, say some Fedora package foo
> today has "License: LGPLv2+" and let's further say that the code is
> clearly licensed under LGPL version 2.1 or later. Could we move to a
> voluntary system where the foo package maintainer can opt to change
> that to "License: LGPLv2+ (SPDX: LGPL-2.1+)"? Or does that not even
> make sense?
>
> Richard

We can add custom tags, but we should probably do it progressively
with automated warnings as Vit suggested.
As for problematic conversions like BSD/MIT, we should just retrieve
the list of the packages and have them fixed manually by volunteers
after review.
___
legal mailing list
legal@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/legal@lists.fedoraproject.org

Re: [Openstack] RDO manager

[Haïkel]

Can you point me the documentation you're using?
And explain me what you're looking for: installing RDO Manager? which
version? (master, Mitaka, etc.)

Regards,
H.

PS: I'm one of the RDO maintainers.

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Fedora-legal-list] Re: Switching to SPDX in license tags redux

[Haïkel]

2016-07-24 1:53 GMT+02:00 Jason Tibbitts <ti...@math.uh.edu>:
> Haïkel <hgue...@fedoraproject.org> writes:
>
>> 3. execute the change (packagers + provenpackagers),
>
> Honestly I feel this should instead be:
>
> 3. execute the change (people who want this)
>

That's likely a misunderstanding (I'm not a native speaker), packagers
will be encouraged to do it, but not *forced* to do it themselves.
Ultimately it will be left to the change owners to do it and it's not
feasible without a set of volunteering provenpackagers as it's a
distro-wide change.

I also volunteered to do it in the initial mail.

> Figuring out the proper tag could potentially involve a re-review of the
> licensing of a large number of packages, to account for the situations
> where there isn't simply a 1-to-1 mapping between our current tags and
> this new setup.
>

Considering version 2.0, this is likely to be a short list and
wouldn't be better to fix it in that standardization body. And we're
already using SPDX in gnome software.

> There just isn't enough obvious benefit (to me, anyway, though I really
> doubt I'm alone) to push this change through without a set of people
> already lined up to do the work.
>

*nods*


>> As we have already standardized our licensing nomenclature, it would
>> easily automatable (update git but not necessarily with rebuild).
>
> If it's that easy, the script to convert everything should also be
> provided by those who want this change.  Or at least a really simple set
> of instructions between what we now have and what you would want us to
> have.  I'd expect to see that document pretty much up front, before
> anyone else sinks time into this.
>

This discussion lost some context, but I offered to write that tooling
last year (which was to me a prerequisite for submitting a change)
At this stage, without Fedora Legal green light, it's useless to
request FPC input and submitting a Fedora system-wide change with
proper documentation and tooling.

> Also, this gets us away from the current process of "ask fedora-legal if
> you see some new license" to... something else, since we no longer
> control the tags.  Someone needs to document the "something else", and
> preferably set up some Fedora contact who will handle whatever
> interaction is needed with whatever standards group is involved.
>
>  - J<

that only changes the nomenclature, not that process.
I don't know all the details, but Spot is listed among the
contributors, we're maybe already involved even indirectly to that
effort.

But yes, we need a representative from Fedora Legal but that's likely
part of the decision.

H.
___
legal mailing list
legal@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/legal@lists.fedoraproject.org

[Fedora-legal-list] About Facebook updated open source patent grant

[Haïkel]

Hi,

It appears that since April, 2015, Facebook updated their open source
patent grant.
https://code.facebook.com/posts/1639473982937255/updating-our-open-source-patent-grant/

Some companies like Google decided to ban Facebook software from their
toolbox since.
https://news.ycombinator.com/item?id=9271331

The actual conditions added to all Facebook projects:
https://github.com/facebook/osquery/blob/master/PATENTS

Potentially, it could mean that no Facebook open source projects can
be shipped in Fedora including high-profile projects like
React.Native.

The worse being that such javascript library are often bundled without
notice ...

Regards;
H;
___
legal mailing list
legal@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/legal@lists.fedoraproject.org

[Fedora-legal-list] Re: Switching to SPDX in license tags redux

[Haïkel]

Well, I'm glad that you're reconsidering it.

With my FESCo hat, I consider this a question that belongs to Legal
Team and technical committees aka FESCo and FPC. Council could
coordinate it as it involves multiple bodies.
My personal opinion about standardizing licensing nomemclature accross
FOSS actors (e.g SUSE [1]) is something we should encourage.
Especially regarding efforts with cross-platform desktop apps packages
(flatpak), and standardizing app metadata (FreeDesktop AppData
specification uses SPDX [2]), both being projects where Fedora Desktop
Team is involved.
Benefits may be low, but cost of doing it is quite low itself.

If we were to decide switching to SPDX, actions plan would be:
1. update licensing guidelines (FPC + Fedora Legal)
2. schedule the change + announcement (FESCo)
3. execute the change (packagers + provenpackagers),

As we have already standardized our licensing nomenclature, it would
easily automatable (update git but not necessarily with rebuild).
Ideally, it should happen in rawhide before a mass rebuild.
It would also help to detect in the next cycle packages, that did not
get a rebuild and are potentially unmaintained. Yes, it would be a
side effect but a positive one, I guess.

Regards,
H.

[1] https://en.opensuse.org/openSUSE:Packaging_guidelines
[2] https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html
___
legal mailing list
legal@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/legal@lists.fedoraproject.org

Re: Self introduction: Zygmunt Krynicki

[Haïkel]

2016-07-23 10:03 GMT+02:00 Zygmunt Krynicki :
> Hello
>
> My name is Zygmunt (zyga) Krynicki. I’ve been using various distributions of 
> Linux for the past 15 years. I helped create the Linaro’s LAVA test system, 
> Ubuntu’s Checkbox hardware testing toolkit. Most recently I’m involved with 
> Snappy where I am responsible for the interface system.
>
> My main focus will be to maintain the Snappy stack in Fedora. This involves 
> the packaging (snapd, snap-confine and a few golang dependencies), upstream 
> snappy support for SElinux and overall architecture support so that snaps 
> work on every computing environment.
>
> I’m excited to join this community and to work on making snaps at home in 
> Fedora
>
> Best regards
> ZK

Welcome to the Fedora community!

> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Snaps and Fedora

[Haïkel]

http://www.ubuntu.com/legal/contributors

2016-07-23 2:46 GMT+02:00 Neal Gompa :
> Hello all,
>
> Over the course of this week, I've been involved in the first Snap
> sprint focused on making the Snap system broadly useful and workable
> across a wide variety of Linux distributions. While I obviously did
> not represent Fedora in any official capacity (and I'm not even really
> sure it's possible for a person to represent such a diverse community
> such as ours), I ensured that Fedora was part of the conversation when
> it came to evolving the Snap system.
>

Thanks Neal for sharing your notes.
It's interesting to have accurate status of snappy on Fedora.


> There are some interesting highlights from the event that I think are
> quite relevant to Fedora:
>
> * Snaps are intended to evolve beyond Ubuntu. While snaps have their
> origins in Click for Ubuntu Touch user apps, the Snap system is
> clearly designed to support a broader array of capabilities and
> systems. Snaps can be used to handle OS components, services, CLI
> tools, desktop applications, build environments, web services, and so
> on.
>

Well, I know first hand, that non-Ubuntu system support is still alpha at best.
It's welcome that Canonical is working to expand support to other
distributions, windowing system, and kernel security modules, though.

> * Runtimes are supported in snaps. While technically there's no
> specific "type" of snap, it's possible to build a snap that contains
> common libraries and services that can be connected to other snaps.
> This is done through the "plugs" and "slots" that can be used to
> create interfaces among them. This is a true superset of the
> capability provided by Flatpak through Portals, since it can be used
> to export non-DBus oriented communications mechanisms. This is
> described on the Snapcraft documentation[0].
>

I wouldn't be so affirmative on that, it slightly inaccurante but I'll
let people with more knowledge of flatpak internals answering that.

> * SELinux-based confinement is a _very_ high priority. As most know,
> snapd currently only works on systems using AppArmor and seccomp, and
> only those using AppArmor patches developed by Ubuntu that are in the
> process of being upstreamed. For SELinux support, we aren't exactly
> sure how this will be pulled off. I proposed something along the lines
> of how confinement works for Docker containers and virtual machines
> (sVirt), but I'm not sure if that's the right approach for enabling
> proper confinement while allowing the sandboxes to support the
> interconnection capabilities of snaps. The way that the Snap system
> enforces confinement using AppArmor and seccomp is by generating a
> profile for the snap on the fly that defines what it can and cannot do
> and access for the mounted snap filesystem (from the squashfs image).
> This policy is applied, locking down the snap's environment. I'm
> curious to hear from others on how the approach should be for
> providing confinement using SELinux.
>

To be more precise, until recently, snappy website recommended to
setenforce 0 as it didn't interact well with SELinux.
That statement was removed though it's still not fixed.

> * Detection and auto-configuration of confinement is coming.
> Snap-confine currently relies on build time configuration to figure
> out whether it should support confinement. However, this will change.
> Snap-confine will be merged into snapd and snapd will be set up to
> query and set up whatever confinement is possible, given the
> information returned from the kernel and systemd about what
> confinement mechanisms are supported.
>
> * The snap format is simple and lends itself to being able to be
> generated by many kinds of tools. While the current main tool used to
> make snaps is Snapcraft, there's no reason someone couldn't build a
> "snapbuild" (like rpmbuild, debbuild[1], and pkgbuild[2]) that could
> theoretically use RPM spec format (or a derivative of it) to build
> snaps.
>
> * Snapcraft is currently Ubuntu specific, but will be reworked to
> remove that. Snapcraft and the snapcraft.yaml format will change to
> enable easily and reproducibly building snaps using Debian and RPM
> based distro bases in addition to Ubuntu[3]. The goal is to make it
> possible for a distribution like Fedora to be able to easily add
> support for building snaps and snap parts from Fedora infrastructure
> using Fedora packages/software, along the lines of what we do now for
> Docker images, so that people can use them in their own snaps or
> solutions.
>
> * The VideoLAN project now officially offers a VLC snap[4], and the
> Elementary OS folks are working on snaps for their Pantheon Desktop
> applications and tying it to an Elementary GTK runtime snap.
> Similarly, the KDE Neon folks are developing a KDE Frameworks 5
> runtime snap and building application snaps to use them.
>
> * Using snapd with alternative stores is possible. In fact, the tests
> done on 

Re: LBNL BSD licence

[Haïkel]

2016-07-05 11:45 GMT+02:00 Dave Love :
> I've realized that the licence for a package I've recently had reviewed
> is actually "LBNL BSD"
> , not BSD3 with a DoE
> disclaimer, as I thought.  (Mea culpa, but licensecheck didn't spot it.)
>
> Anyway, I've fixed that, but I can't find any discussion about the
> licence.  Does anyone know of any past discussion, specifically any
> recommendation for dealing with the clause that seems problematic to me
> as a potential booby-trap for contributors:
>
>   You are under no obligation whatsoever to provide any bug fixes, patches, or
>   upgrades to the features, functionality or performance of the source code
>   ("Enhancements") to anyone; however, if you choose to make your Enhancements
>   available either publicly, or directly to Lawrence Berkeley National
>   Laboratory, without imposing a separate written license agreement for such
>   Enhancements, then you hereby grant the following license: a  non-exclusive,
>   royalty-free perpetual license to install, use, modify, prepare derivative
>   works, incorporate into other computer software, distribute, and sublicense
>   such enhancements or derivative works thereof, in binary and source code 
> form.
>
> People sending copyright-significant changes probably don't expect to
> grant an all-permissive licence (which presumably involves the
> possibility of removing copyright notices, for instance), so I wondered
> what to do for the "separate written license" to keep contributions
> under the basic BSD3 terms.  I'm thinking of modifying the COPYING file
> to say simply that changes are distributed only under BSD3 terms.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Do not change shipped license file from upstream.
First, contact the following list: legal AT lists.fedoraproject.org in
order to clarify the obscure points.
Then, coordinate with upstream to fix licensing upstream if you're requested to.


Regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [openstack-dev] [daisycloud-core] Kolla Mitaka requirements supported by CentOS

[Haïkel]

2016-07-02 20:42 GMT+02:00 jason :
> Pip Package Name Supported By Centos CentOS Name  Repo 
> Name
> ==
> ansible   yes
> ansible1.9.noarchepel
> docker-py  yes
> python-docker-py.noarchextras
> gitdb  yes
> python-gitdb.x86_64epel
> GitPython  yes
> GitPython.noarchepel
> oslo.config yes
> python2-oslo-config.noarch centos-openstack-mitaka
> pbryes
> python-pbr.noarch   epel
> setuptools yes
> python-setuptools.noarchbase
> six yes
> python-six.noarch base
> pycryptoyes
> python2-crypto  epel
> graphvizno
> Jinja2no (Note: Jinja2 2.7.2 will be installed as
> dependency by ansible)
>

As one of RDO maintainer, I strongly invite kolla, not to use EPEL.
It's proven very hard to prevent EPEL pushing broken updates, or push
updates to fit OpenStack requirements.

Actually, all the dependency above but ansible, docker and git python
modules are in CentOS Cloud SIG repositories.
If you are interested to work w/ CentOS Cloud SIG, we can add missing
dependencies in our repositories.


>
> As above table shows, only two (graphviz and Jinja2) are not supported
> by centos currently. As those not supported packages are definitly not
> used by OpenStack as well as Daisy. So basicaly we can use pip to
> install them after installing other packages by yum. But note that
> Jinja2 2.7.2 will be installed as dependency while yum install
> ansible, so we need to using pip to install jinja2 2.8 after that to
> overide the old one. Also note that we must make sure pip is ONLY used
> for installing those two not supported packages.
>
> But before you trying to use pip, please consider these:
>
> 1) graphviz is just for saving image depend graph text file and is not
> used by default and only used in build process if it is configured to
> be used.
>
> 2) Jinja2 rpm can be found at
> http://koji.fedoraproject.org/koji/packageinfo?packageID=6506, which I
> think is suitable for CentOS. I have tested it.
>
> So, as far as Kolla deploy process concerned, there is no need to use
> pip to install graphviz and Jinja2. Further more, if we do not install
> Kolla either then we can get ride of pip totally!
>
> I encourage all of you to think about not using pip any more for
> Daisy+Kolla, because pip hase a lot of overlaps between yum/rpm, files
> may be overide back and force if not using them carefully. So not
> using pip will make things easier and make jump server more cleaner.
> Any ideas?
>
>
> Thanks,
> Zhijiang
>
> --
> Yours,
> Jason
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Continued support of Fedora as a base platform

[Haïkel]

2016-06-30 14:07 GMT+02:00 Steven Dake (stdake) :
> What really cratered our implementation of fedora was the introduction of
> DNF.  Prior to that, we led with Fedora.  I switched my focus to something
> slower moving (CentOS) so I could focus on a properly working RDO rather
> then working around the latest and greatest changes.
>
> That said, if someone wants to fix Kolla to run against dnf, that would be
> fantastic, as it will need to be done for CentOS8 an RHEL8.
>
> Regards
> -steve
>

That's something that we fixed for Fedora Cloud image. I'll give it a shot.

Regards,
H.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Continued support of Fedora as a base platform

[Haïkel]

My opinion as one of RDO release wranglers is not to support Fedora
for anything else that isn't trunk.
It's proven really hard to maintain all dependencies in a good state,
and when we managed to do that,
an update could break things at any time (like python-pymongo update
who was removed because of Pulp developers).

RDO actually ensure that spec files are buildable on Fedora but you'd
have to maintain dependencies separately and rely on
tools like yum priorities plugin to override base packages.

Fedora lifecycle is also not sync-ed with OpenStack, OpenStack being
released around 2 months before the next Fedora Stable.
So in practice, if you use stable N-1, you have 9 months of support
from Fedora, and updating to stable N requires some amount of work.

Regards,
H.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: Anyone know how to contact maintainer Salimma?

[Haïkel]

2016-06-30 4:59 GMT+02:00 Avram Lubkin :
>
> I've been trying to contact Salimma, Michel Alexandre Salim, for the last
> month. I've been trying to update python-sphinx which hasn't had an update
> since last fall. Worked through all of the issues, but maintainer hasn't
> responded to commit request, email, or bug reports.
>
> Bug report for newest version of Sphinx with needinfo flag.
> https://bugzilla.redhat.com/show_bug.cgi?id=1323202
>
> Anyone have any info?
>

I see builds from him june, 8 in Koji so he shouldn't be far away.
Meanwhile, you can send me your patch or add it in the bugzilla and
I'll apply it in rawhide as provenpackager.


>
> Thanks
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [openstack-dev] [kolla] version of python2-oslo-config

[Haïkel]

2016-06-28 17:53 GMT+02:00 Steven Dake (stdake) :
> The mitaka branch of Kolla requires 3.7 or later.
>
> Git checkout stable/mitaka
>
> Master may require 3.10, but that happens via the global requirements update
> process, of which RDO will surely address in the future.
>
> Regards
> -steve
>

Yes, we haven't branched Newton in stable repositories, but you can
get it in trunk repositories.
Feel free to CC rdo-list or me directly for anything related to packaging.

H.


> From: "hu.zhiji...@zte.com.cn" 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Tuesday, June 28, 2016 at 4:30 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [kolla] version of python2-oslo-config
>
> Hi Kolla team,
>
> Base upon requirement.txt, Kolla needs oslo-config version 3.10. But CentOS
> Mitaka uses 3.9 ,which is python2-oslo-config-3.9.0-1.el7.noarch.rpm.
>
> I want to know if Kolla can also work on oslo-config-3.9.0. If it can, then
> will be a benefit because pip is conflict with rpm on python2-oslo-config
> package. For example, the rpm version has the ability to find config file in
> /usr/share/keystone/keystone-dist.conf but the pip version not.
>
>
> Thanks
> Zhijiang,
>
> 
> ZTE Information Security Notice: The information contained in this mail (and
> any attachment transmitted herewith) is privileged and confidential and is
> intended for the exclusive use of the addressee(s).  If you are not an
> intended recipient, any disclosure, reproduction, distribution or other
> dissemination or use of the information contained is strictly prohibited.
> If you have received this mail in error, please delete it and notify us
> immediately.
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: Packages seeking new Point Of Contact

[Haïkel]

2016-06-28 18:49 GMT+02:00 Kevin Fenzi :
> Greetings.
>
> Per: https://fedorahosted.org/fesco/ticket/1589
>
> I have orphaned bjohnson's packages.
>
> Please do take point of contact for any of these you wish to help
> maintain for the Fedora Project.
>
> rpms/conduit -- A synchronization solution for GNOME ( master f24 f23 f22 
> )
> rpms/dbmail -- A database backed mail storage system ( master f24 f23 f22 
> epel7 el6 el5 )
> rpms/dwatch -- A program that watches over other programs ( master f24 
> f23 f22 epel7 el6 el5 )
> rpms/gmime -- Library for creating and parsing MIME messages ( epel7 el6 
> el5 )
> rpms/goocanvas -- A new canvas widget for GTK+ that uses cairo for 
> drawing ( master f24 f23 f22 )
> rpms/gscan2pdf -- GUI for producing a multipage PDF from a scan ( master 
> f24 f23 f22 )
> rpms/libmkv -- An alternative to the official libmatroska library ( 
> master f24 f23 f22 epel7 )
> rpms/libsieve -- A library for parsing, sorting and filtering your mail ( 
> master f24 f23 f22 epel7 el6 el5 )
> rpms/libzdb -- Small, easy to use Database Connection Pool Library ( 
> master f24 f23 f22 epel7 el6 el5 )
> rpms/mailgraph -- A RRDtool frontend for Mail statistics ( master f24 f23 
> f22 epel7 el6 el5 )
> rpms/perl-Gtk2-Ex-PodViewer -- A Gtk2 widget for displaying Plain old 
> Documentation (POD) ( master f24 f23 f22 )
> rpms/perl-Net-FTP-AutoReconnect -- FTP client class with automatic 
> reconnect on failure ( master f24 f23 f22 epel7 el6 el5 )
> rpms/perl-Net-FTP-RetrHandle -- Provides a file reading interface for 
> reading files on a remote FTP server ( master f24 f23 f22 epel7 el6 el5 )
> rpms/perl-PDF-API2 -- Perl module for creation and modification of PDF 
> files ( master f24 f23 f22 epel7 el6 )
> rpms/perl-Sane -- Perl extension for the SANE (Scanner Access Now Easy) 
> Project ( master f24 f23 f22 )
> rpms/perl-forks -- A drop-in replacement for Perl threads using fork() ( 
> master f24 f23 f22 )
> rpms/polipo -- Lightweight caching web proxy ( master f24 f23 f22 epel7 
> el6 )
> rpms/pygoocanvas -- GooCanvas python bindings ( master f24 f23 f22 )
> rpms/queuegraph -- A RRDtool frontend for Mail statistics ( master f24 
> f23 f22 epel7 el6 el5 )
> rpms/tmda -- Tagged Message Delivery Agent ( master f24 f23 f22 epel7 el6 
> el5 )
> rpms/unpaper -- Post-processing of scanned and photocopied book
> pages ( master f24 f23 f22 epel7 el6 el5 )
>
> kevin
>

I see that goocanvas is retired, so pygoocanvas should be too.


> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

"Summary/Minutes for today's FESCo meeting (2016-06-24)"

[Haïkel]

===
#fedora-meeting: FESCO (2016-06-24)
===


Meeting started by number80 at 16:00:02 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2016-06-24/fesco.2016-06-24-16.00.log.html
.



Meeting summary
---
* #1587 Policy regarding packaging when upstream has chosen  (number80,
  16:02:09)
  * LINK: https://fedorahosted.org/fpc/ticket/633   (number80, 16:03:20)
  * AGREED: close ticket #1587 (+1: 7, 0: 0, -1: 0)  (number80,
16:12:33)
  * if there are conflict about inappropriate package naming or
conflict, you should raise it to FPC (guidelines) or ultimately to
FESCo  (number80, 16:13:48)

* #1576  Evaluate Workstation graphical upgrade Change status
  (number80, 16:14:42)
  * ACTION: number80 close ticket 1576  (number80, 16:17:26)

* #1589 BackupPC's packager Bernard Johnson is nonresponsive  (number80,
  16:17:56)
  * LINK: https://admin.fedoraproject.org/pkgdb/packager/bjohnson/
(nirik, 16:21:10)
  * AGREED: orphan all of bjohnson's packages. nirik will sponsor and
mentor lef to take ownership of BackupPC (+1: 7, 0: 0, -1: 0)
(number80, 16:33:23)

* #1588 F25 System Wide Change: PHP 7.0  (number80, 16:33:44)
  * AGREED: PHP 7.0 system wide feature is accepted (+1: 7, 0: 0, -1; 0)
(number80, 16:36:23)

* Open Floor  (number80, 16:36:55)
  * paragan will chair the next meeting (2016-07-01)  (number80,
16:41:26)

Meeting ended at 16:41:56 UTC.




Action Items

* number80 close ticket 1576




Action Items, by person
---
* number80
  * number80 close ticket 1576
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* number80 (82)
* sgallagh (32)
* nirik (28)
* maxamillion (18)
* zodbot (15)
* jwb (15)
* paragan (14)
* mulhern (8)
* jsmith (8)
* tibbs|w (5)
* RemiFedora (2)
* handsome_pirate (1)
* gholms (1)
* kalev (0)
* dgilmore (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

"Schedule for Friday's FESCo Meeting (2016-06-24)"

[Haïkel]

Following is the list of topics that will be discussed in the FESCo
meeting Friday at 16:00UTC in #fedora-meeting on irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2016-06-24 16:00 UTC'


Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1587 Policy regarding packaging when upstream has chosen
inappropriate name for package
.fesco 1587
https://fedorahosted.org/fesco/ticket/1587

#topic #1576  Evaluate Workstation graphical upgrade Change status
.fesco 1576
https://fedorahosted.org/fesco/ticket/1576

= New business =

#topic #1589 BackupPC's packager Bernard Johnson is nonresponsive
.fesco 1589
https://fedorahosted.org/fesco/ticket/1589

#topic #1588 F25 System Wide Change: PHP 7.0
.fesco 1588
https://fedorahosted.org/fesco/ticket/1588


= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [openstack-dev] [requirements][packaging] Normalizing requirements file

[Haïkel]

2016-06-24 4:02 GMT+02:00 Tony Breeds :
>
> I think we need to pause on these 'normalizing' changes in g-r.  They're
> genertaing whitspace only reviews in many, (possibly all) projects that have
> managed requirements.
>
> We need to do more testing and possibly make the bot smarter befoer we look at
> this again.
>
>
> Yours Tony.
>

Roger.
Maybe we can put it at the agenda to the next (or later) meeting to
work on specifications
and define the next steps before moving on.

Regards,
H.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[CentOS-virt] [Virt SIG] status of virt7-docker repository?

[Haïkel]

Hi,

I'm considering to add virt7-docker repository as a dependency for the
openstack repo from Cloud SIG.
It seems that it's not consumable yet and some packages like
Kubernetes are outdated.

Could you update me with the current status and if there is anything
we can do to help?

Regards,
H.
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [openstack-dev] [neutron][general] Multiple implementation of /usr/bin/foo stored at the same location, leading to conflicts

[Haïkel]

Yes, RDO faced the very same issue:
https://github.com/rdo-packages/neutron-fwaas-distgit/blob/rpm-master/openstack-neutron-fwaas.spec#L115

My understanding was that neutron folks were looking for a solution,
but we ship this workaround for now a month.

Regards,
H

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][packaging] Normalizing requirements file

[Haïkel]

2016-06-22 7:23 GMT+02:00 Tony Breeds :
>
> I'm fine with doign something like this.  I wrote [1] some time ago but didn't
> push on it as I needed to verify that this wouldn't create a "storm" of
> pointless updates that just reorder things in every projects 
> *requirements.txt.
>
> I think the first step is to get the 'tool' added to the requirements repo to
> make it easy to run again when things get out of wack.
>
> perhaps openstack_requirements/cmds/normalize ?
>

Thanks Swapnil and Tony for your positive comments.

I didn't submit the script as I wanted to see in real conditions, how
well it fare and
get feedback from my peers, first. I'll submit the script in a separate review.

> we can bikeshed on the output format / incrementally improve things if we have
> a common base.
>

makes sense, I tried to stay as close to the main current style

Regards,
H.

> So I think that's a -1 on your review as it stands until we have the tool 
> merged.
>
> Yours Tony.
>
> [1] https://gist.github.com/tbreeds/f250b964383922bdea4645740ae4b195
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [requirements][packaging] Normalizing requirements file

[Haïkel]

Hi,

as a packager, I spend a lot of time to scrutinize the requirements
repo, and I find it easier to read if specifiers are ordered.
So in a quick glance, you can check which is the min version required
and max one without trying to search them among other specifiers.
I scripted a basic linter to do that (which also normalize comments to
PEP8 standards)

Initial review is here:
https://review.openstack.org/#/c/332623/

script is available here;
https://gist.github.com/hguemar/7a17bf93f6c8bd8ae5ec34bf9ab311a1

Your thoughts?

Regards,
H.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: Self Introduction: Oliver Haessler

[Haïkel]

2016-06-14 16:45 GMT+02:00 Oliver Haessler :
> Hi everyone,
>
> my name is Oliver and I am working for Red Hat in the internal IT department.
> I am responsible for the internal RHEL desktop build we use for our employees.
> I maintain extra config packages that we add to the existing Red Hat 
> Enterprise Linux,
> so our employees are getting productive faster.
>
> A while ago I decided to give something back to the Open Source community by
> contributing to the Fedora project. I am co-maintaining several packages I am 
> using
> myself, or that employees asked for to be included in our internal 
> repositories.
>
> One of my goals is to extend the contribution to also include package/release 
> testing and
> reporting of bugs via bugzilla.
>
> I am looking very much forward to work with a lot of interesting people in 
> the community,
> and learn a lot new things.
>
> Cheers
> Oliver

Welcome Oliver, nice to see you on this side of the firewall :)
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unresponsive maintainer: asaf

[Haïkel]

2016-05-30 12:55 GMT+02:00 gil <punto...@libero.it>:
>
>
> Il 30/05/2016 12:09, Haïkel ha scritto:
>>
>> 2016-05-30 10:18 GMT+02:00 Mikolaj Izdebski <mizde...@redhat.com>:
>>>
>>> On 05/30/2016 10:01 AM, gil wrote:
>>>>
>>>> But until now I have not had any response from the maintainer, asaf
>>>> (Asaf Shakarchi a...@redhat.com ) .
>>>
>>> This email address seems to be inactive.
>>>
>> Asaf left Red Hat now six years ago, and he last logged in FAS in 2013.
>> It's likely we'll orphan all his packages when it'll reach FESCo.
>>
>> H.
>>
> Thanks,
> i need to upgrade slf4j-jboss-logmanager
> https://bugzilla.redhat.com/show_bug.cgi?id=1340406
> regards
> .g

Since the process may take at least a week, I'll do the update in your
stead as provenpackager.
Please open a ticket in the FESCO trac.


>>>
>>> --
>>> Mikolaj Izdebski
>>> Software Engineer, Red Hat
>>> IRC: mizdebsk
>>> --
>>> devel mailing list
>>> devel@lists.fedoraproject.org
>>> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>>
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unresponsive maintainer: asaf

[Haïkel]

2016-05-30 10:18 GMT+02:00 Mikolaj Izdebski :
> On 05/30/2016 10:01 AM, gil wrote:
>> But until now I have not had any response from the maintainer, asaf
>> (Asaf Shakarchi a...@redhat.com ) .
>
> This email address seems to be inactive.
>

Asaf left Red Hat now six years ago, and he last logged in FAS in 2013.
It's likely we'll orphan all his packages when it'll reach FESCo.

H.


> --
> Mikolaj Izdebski
> Software Engineer, Red Hat
> IRC: mizdebsk
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Reserved GID for MongoDB

[Haïkel]

2016-05-18 21:39 GMT+02:00 Reindl Harald :
>
>
> it's simple: apache (httpd) has gid/uid 48 likely before you did knew about
> Fedora nad you can rely on that on every Fdora/RHEL/CentOS system out there
>
> *that* is consistent UID/GID
>

That is irrelevant to the current discussion, and you're belittling
yourself with these kind of personal attacks.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org