[EPEL-devel] Re: ansible-core-2.11.x in CentOS stream 9

[Toshio Kuratomi]

I believe ansible-core includes a "dependency manager" depending on your
definition.  The ansible-galaxy command in ansible-core can install ansible
collections so that's you can install modules that you may need.

It is similar in scope to pip, rubygem, cargo, or any other of the language
package installers.

It does not resolve based on what modules/plugins are used in your
playbooks but it will resolve dependencies between collection dependencies
if needed (and those deps were properly listed).

I know that Nirik has plans to get newer ansible packages into epel which
provide an all-in-one experience by installing about 75 collections which
give you an experience similar what was included in ansible-2.9 but I'll
let him speak to how he wants to do that.

-Toshio

On Thu, Sep 16, 2021, 7:20 AM Josh Boyer  wrote:

> On Thu, Sep 16, 2021 at 10:10 AM Leon Fauster
>  wrote:
> >
> > On 16.09.21 14:22, Josh Boyer wrote:
> > > On Wed, Sep 15, 2021 at 3:48 PM Kevin Fenzi  wrote:
> > >>
> > >> Just a heads up that ansible-core (the engine part of ansible) is now
> in
> > >> CentOS stream 9:
> > >>
> > >> https://gitlab.com/redhat/centos-stream/rpms/ansible-core
> > >>
> > >> Note that this is the engine, you will likely want to install
> > >> collections for modules and roles, etc.
> > >
> > > For those that might not have followed how Ansible has been
> > > refactored, take a look at
> > > https://www.ansible.com/blog/ansible-3.0.0-qa
> > >
> > > ansible-core is the lowest level of the ansible stack and does not
> > > include many of the modules and plugins that those using ansible
> > > engine (ansible-2.9) might be used to.  As Kevin said, you will almost
> > > certainly need additional modules/plugins not provided by
> > > ansible-core.
> >
> >
> > Out of curiosity
> >
> > Does CS9 provide additional (sub)packages to extend the functionality?
>
> Not generally.  ansible-core has been added to CS9 in support of
> System Roles only.  This is analogous to how ansible is made available
> in RHEL 8.  System Roles will include the modules/plugins it needs to
> manage the various areas of the OS, but they are not general purpose
> ansible packages.
>
> > Right now EPEL8 provide the the full stack based on ansible 2.9.
> >
> > Will EPEL9 provide such packages to provide additional modules/plugins?
> >
> > And more a ansible question: Does ansible3 provide a dependencies
> > manager as consequence now?
>
> I'll leave these for Kevin or someone else to answer in terms of EPEL 9
> plans.
>
> josh
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Draft of New Python Packaging Guidelines

[Toshio Kuratomi]

What do you/the packaging macros do when a pypi name is taken by two
different packages?  (For instance, how setuptools and distribute used the
same name)

-Toshio

On Fri, Jun 11, 2021, 6:24 AM Petr Viktorin  wrote:

> I've proposed the new guidelines as a Fedora change:
> https://fedoraproject.org/wiki/Changes/PythonPackagingGuidelines202x
>
> A discussion thread should pop up on de...@lists.fedoraproject.org soon.
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

[Toshio Kuratomi]

On Tue, Jul 16, 2019, 3:48 PM Miro Hrončok  wrote:

> Hey,
>
> when RHEL 7.7 will be released, the following new components/packages will
> be
> provided (assuming from 7.7 beta):
>
> python3 - the Python 3.6 package
> 
>
> This new RHEL7 component builds several subpackages, all obsoleting the
> subpackages of epel7 python36 package.
> We will simply retire python36 from epel7.
>
> python-rpm-macros
> =
>
> This new RHEL7 component is a drop-in replacement of python-rpm-macros
> from
> epel7, we will simply retire the package. python-epel-rpm-macros already
> provide
> the necessary macros for python34 in epel7.
>
> python3-setuptools
> ==
>
> This new RHEL7 component produces the python3-setuptools package that
> obsoletes
> the python36-setuptools package (built from the python3-setuptools epel7
> component).
>
> We cannot simply retire python3-setuptools from epel7, as it also builds
> python34-setuptools in epel7 and there is no replacement for that in RHEL7.
>
> Easiest thing would be to stop building python36-setuptools and only keep
> python34-setuptools in epel7, however IIRC we cannot have the same
> component
> name as in RHEL. If that is indeed the case, python3-setuptools needs to
> be
> retired and a new python34-setuptools component needs to be created in
> epel7. Is
> my assumption correct?
>
> python-pip
> ==
>
> This new RHEL7 component produces the python3-pip package that obsoletes
> the
> python36-pip package (built from the python-pip epel7 component).
>
> The python-pip epel7 component also produces python34-pip and python2-pip
> (neither available in RHEL 7.7).
>
> If my previous assumption about components with RHEL names is correct, we
> need 1
> or 2 new components for python34-pip and python2-pip - either we have each
> in a
> separate component or we create a new component that builds both (called
> python-pip-epel maybe?).
>
> python-wheel
> 
>
> This new RHEL7 component produces the python3-wheel package.
>
> The python-wheel epel7 component produced python-wheel package (Python 2).
>
> The epel7 package was adapted to produce python2-wheel and python36-wheel,
> however there was no successful build of this in epel7.
>
> If my previous assumption about components with RHEL names is correct,
> we need to add a new python2-wheel component to epel7.
>
> 
>
> Are my assumptions correct?
>
> If we indeed need new packages/components, I can help to create them, but
> I do
> not intent to maintain them. Any takers?
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Re: Issues with egg-info switching between directory and file

[Toshio Kuratomi]

On Mon, Apr 1, 2019 at 7:40 PM Orion Poplawski  wrote:

> I've noticed a few times now where a python package unexpectedly
> produces an egg-info file instead of a directory.  This is particularly
> troubling in light of rpm's inability to replace a directory with a file:
>
> https://fedoraproject.org/wiki/Packaging:Directory_Replacement
>
> This seems to come about in the case of a project using distutils with
> incorrect options:
>
> running install_egg_info
> Writing
>
> /builddir/build/BUILDROOT/python-pkgconfig-1.5.1-1.fc31.x86_64/usr/lib/python3.7/site-packages/pkgconfig-1.5.1-py3.7.egg-info
> /usr/lib64/python3.7/distutils/dist.py:274: UserWarning: Unknown
> distribution option: 'python_requires'
>warnings.warn(msg)
>
> In the case of pkgconfig, this appears to be coming about due to the use
> of "poetry" which seems to incorrectly be using distutils instead of
> setuptools:
>
> https://github.com/sdispater/poetry/issues/866
>
> In any case - please be careful with changing egg-info format - and do
> use egg-info/  in your specs to ensure that the format is a
> directory as expected.
>

An egg-info file is not "incorrect"  but you are right that you have to be
aware of it because of the rpm limitations.

In the past, if upstream had moved from setuptools to distutils, I would
patch the package to use setuptools until the next Python package upgrade
in Fedora.  Since that would need a different site-packages directory to
upgrade (for instance, the egg-info directory in the old package would have
been /usr/lib/python3.6/site-packages/foo*.egg-info/  and in the new
package it would be a file in
/usr/lib/python3.7/site-packages/foo*.egg-info ), it was a good time to
remove my local patch and return to what upstream had decided to use.

-Toshio
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org

Re: flit

[Toshio Kuratomi]

On Thu, Nov 16, 2017 at 8:43 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 17 November 2017 at 11:55, Toshio Kuratomi <a.bad...@gmail.com> wrote:
>>
>> On Thu, Nov 16, 2017 at 5:37 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>> > So the two possible approaches are:
>> >
>> > * traditional sdist: "setup.py build", "setup.py install"
>> > * Current wheel macros: "setup.py bdist_wheel", "pip install "
>> >
>> > If we tweak the %py_build_wheel macro to use `pip wheel` [1] rather than
>> > calling `setup.py bdist_wheel` directly, then even the wheel build macro
>> > would be usable without a setup.py shim (once pip itself fully supports PEP
>> > 517/518)
>> >
>>
>> I'm not sure what you're saying.  I must be further outside of the
>> packaging loop than I thought.
>>
>> The two questions that I need to know the answer to to make sure we're
>> even vaguley on the same page are:
>>
>> * Is the rpm Source: line still going to be an sdist?
>> * Are the files that are in the built rpm going to be the same as now?
>
> Yes, those are both unchanged.
>
> The issue is specifically with the example in
> https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file,
> which only shows the %pyX_build and %pyX_install macros, which assume
> that the right way to install a Python project inside the buildroot is
> to run:
>
> "setup.py build" in the %build step
> "setup.py install" in the %install step
>
> That works as long as the project either uses setup.py natively (i.e.
> distutils/setuptools projects), or provides a backwards compatibility
> shim, but won't work consistently for newer projects that rely on
> pyproject.toml and the static build dependency declarations from PEPs
> 517 & 518.
>
> Switching to a wheel based build doesn't change either the starting
> point (which is still an sdist) or the end point (which is still a
> policy compliant RPM), it changes the internal interface between the
> build step and the install step from being a distutils build directory
> to a wheel archive:
>
> "pip wheel" (or "setup.py bdist_wheel") in the %build step
> "pip install" in the %install step
>
So This seems more like "Building packages via pip"  or "Building
packages that use pyproject.toml".  wheels are actually an
implementation detail here that doesn't really surface to the either
the input side or the output side.  we don't care if the build tool
(pip in this example) takes the sdist with a pyproject.toml file and
builds a wheel, a _build/ directory, or some other intermediate
format.  We just care that it builds the appropriate files in this
step and then installs from that built resource in the second step.
This is why the name and focus seems wrong to me.  the importance to
us when building from source is the metadata format and the tools that
transform the source code with that metadata into a built resource on
our filesystem.

> At a policy management level, I think it makes sense to separate the
> "these are the policy decisions you *must* abide by" guidelines (which
> are the domain of FPC) from the "Here are the helper macros that we
> provide to make it easier to abide by those guidelines". The
> distinction is that you can still pass a package review without using
> the helper macros, but you'll still want to use them in most cases
> simply because they make ongoing package maintenance easier (since the
> helper macros will adjust automatically to rebases and policy changes,
> while handcrafted spec files might not).
>

So, How to write a package that complies with the guidelines is also
the domain of the FPC (at least, right now).  So you need to have
something inside of the guidelines that shows how to use these things.
I leaned towards spelling out the manual steps and then showing that
there were macros that encapsulated some of those steps but that may
no longer be the preferred direction.  The guidelines must have at
least one or the other, though.  This doesn't conflict with your last
statement (whether the package does or does not have to use the
macros) but it does conflict with the implicit idea that the FPC is
limited to the policy decisions that you must abide by and also is a
problem when you talk about not having any in-guidelines information
on how to build the packages that have pyproject.toml.

-Toshio
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: flit

[Toshio Kuratomi]

On Thu, Nov 16, 2017 at 5:37 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 17 November 2017 at 01:51, Toshio Kuratomi <a.bad...@gmail.com> wrote:
>>
>> On Nov 16, 2017 4:59 AM, "Nick Coghlan" <ncogh...@gmail.com> wrote:
>
>
>>
>> Rather than emphasising the absence of setup.py, I'd emphasise the use of
>> wheel files:
>>
>>
>> * "Defining an RPM based on a wheel build process"
>> * "Defining an RPM based on a setup.py file"
>>
>>
>> I would not emphasize the use of wheel files as they are not source and
>> from flit's documentation, it doesn't appear that wheels are even central to
>> it (contrast how much wheel is mentioned in  its documentation compared to
>> pyproject.tom).  Instead I would emphasize flit itself as the build tool
>> which we're using to transform the source into the files on our systems.  If
>> there's ever an alternative to flit which builds with wheels as part of that
>> process we'll need new guidelines based on that so using wheel as the prime
>> keyword that people associate with this build process instead of flit is not
>> future proof either.
>
>
> It's not just flit - it's enscons and other PEP 517/518 backends, whereby
> the only thing we know for sure about the sdist in the long term is that
> "pip wheel" (and other PEP 517 frontends) will be able to convert it into a
> Python wheel in the %build phase, which can then be unpacked by the wheel
> installation macro in the %install phase.
>
> So the two possible approaches are:
>
> * traditional sdist: "setup.py build", "setup.py install"
> * Current wheel macros: "setup.py bdist_wheel", "pip install "
>
> If we tweak the %py_build_wheel macro to use `pip wheel` [1] rather than
> calling `setup.py bdist_wheel` directly, then even the wheel build macro
> would be usable without a setup.py shim (once pip itself fully supports PEP
> 517/518)
>
I'm not sure what you're saying.  I must be further outside of the
packaging loop than I thought.

The two questions that I need to know the answer to to make sure we're
even vaguley on the same page are:

* Is the rpm Source: line still going to be an sdist?
* Are the files that are in the built rpm going to be the same as now?

-Toshio
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: flit

[Toshio Kuratomi]

On Nov 16, 2017 4:59 AM, "Nick Coghlan"  wrote:

On 16 November 2017 at 22:33, Miro Hrončok  wrote:

> Adding the link makes sense to me. Adding all the macros definition to the
> wiki does not make sense to me, but form different reasons. I think that
> having %py3_build_egg and %py3_install_egg there is just not necessary.
> Since there are more files at [0] I'd just add that link.
>
> [0] https://src.fedoraproject.org/rpms/python-rpm-macros/tree/master


Even though it's just a new informational link, I'm guessing we still need
to file an FPC ticket for that?


I think that macros we care about should be on that page, not just at that
link.  However, you should check with tibbs/FPC about whether the
definitions/list of macros are an altogether dated concept.   When I was
there we used those because spec files are just shell scripts.  For a
sysadmin to become a packager, they just needed to understand a few
concepts about the structure of the spec file but otherwise they just put
their steps from the command line into the spec.

Defining the macros on the page allowed those users to see how the macro
replaced some steps of their manual procedure.

However, that may no longer be the audience of the guidelines.  It may be
that they're now targeting programmers or packagers who don't have the same
intimate relationship to the command line as sysadmin and have a greater
comfort learning a domain specific language to do a job.

In that case, perhaps the entire concept of enumerating the macros is
unneeded for that target audience.  Instead, simply introducing the macros
when they're used in the guidelines is enough.  Talk to tibbs/FPC about
what their thoughts are.


>  * if so, should we add a new section of the guidelines? something like
>"Packaging setup.py-less projects"?
>

Rather than emphasising the absence of setup.py, I'd emphasise the use of
wheel files:

* "Defining an RPM based on a wheel build process"
* "Defining an RPM based on a setup.py file"


I would not emphasize the use of wheel files as they are not source and
from flit's documentation, it doesn't appear that wheels are even central
to it (contrast how much wheel is mentioned in  its documentation compared
to pyproject.tom).  Instead I would emphasize flit itself as the build tool
which we're using to transform the source into the files on our systems.
If there's ever an alternative to flit which builds with wheels as part of
that process we'll need new guidelines based on that so using wheel as the
prime keyword that people associate with this build process instead of flit
is not future proof either.

-Toshio
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: ansible retired in epel7

[Toshio Kuratomi]

On Oct 7, 2017 1:18 PM, "Neal Gompa"  wrote:

On Tue, Oct 3, 2017 at 12:49 PM, Kevin Fenzi  wrote:
> Greetings.
>
> Just a note for anyone looking for ansible in epel7.
>
> It's been retired there because with the release of RHEL 7.4 it's now
> int the rhel-extras channel.
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterp
rise_Linux/7/html-single/7.4_Release_Notes/index.html#
technology_previews_red_hat_enterprise_linux_system_roles_powered_by_ansible
>
> Accordingly, you can get ansible now from rhel extras channel, or CentOS
> extras repo.
>
> You can also get ansible rpms now from
> http://releases.ansible.com/ansible/rpm/
>
> Note that ansible continues to be available from epel6.
>

Since Ansible was added as an "unsupported dependency" for the System
Roles feature, it's a bit different from other things in that it's
unlikely to receive updates.

Users of Ansible should probably avoid depending on the Extras version
unless they're okay with no fixes to it... :/

Ansible upstream has added rpm packages for those who might get suck in
that situation.  It won't be exactly like the epel versions and we
[upstream] haven't quite worked out all the things (like having an rpm with
the repo config  files in it) but hopefully it will be useful.

http://releases.ansible.com/ansible/rpm/

(Official releases are packaged in the releases subdir, hopefully the other
subdirs are equally self explanatory)

-toshio
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Should Python 3 macros us UTF-8 locale?

[Toshio Kuratomi]

I think it is better if the build system sets LANG=C.UTF-8, not the
python specific macros.

On Thu, Jun 1, 2017 at 8:56 AM, Miro Hrončok  wrote:
> Hi Pythonistas.
>
> Regarding our Python 3 C.UTF-8 locale coercing [1], aka PEP 538 [2].
>
> As you probably know, we build RPM packages with the C locale. So everytime
> we use python3 in the spec file, the coercing message is shown. This can be
> more problematic than just spamming the build logs, see for example the
> related rpmlint bug [3][4].
>
> Our macros, such as %{python3_sitelib}, %{python3_version} etc. all call
> python3 and generate the warning. Should we "fix" our macros to set the LANG
> to C.UTF-8?
>
> If we change the %{__python3} macro entirely, we might get rid of all of
> those warnings and we will workaround the fact that we build RPM packages
> with the C locale. On the other hand the packager would not be able to set a
> desired locale because it will always be overwritten:
>
> # The crazy test suite needs Czech locale
> LANG=cs_CZ.utf8 %{__python3} -m pytest
>
> Will become:
>
> LANG=cs_CZ.utf8 LANG=C.utf8 /usr/bin/python3 -m pytest
>
> So I would not do that.
>
> But we can change all other macros in /usr/lib/rpm/macros.d/macros.python3
> to set the UTF-8 locale. Would that be wise? Desired?
>
> Any thoughts?
>
>
> [1] https://fedoraproject.org/wiki/Changes/python3_c.utf-8_locale
> [2] https://www.python.org/dev/peps/pep-0538/
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1457786
> [4] https://bugzilla.redhat.com/show_bug.cgi?id=1436345
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Python 3.6, Fedora, and the "C" locale

[Toshio Kuratomi]

jinx ;-)

On Thu, Dec 15, 2016 at 4:38 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 15 December 2016 at 21:17, Toshio Kuratomi <a.bad...@gmail.com> wrote:
>> My one concern is precisely this variety.  For instance, if I get a
>> report that my application is raising a UnicodeError on RHEL7 when run
>> under cron (which uses the C locale) I might then try to replicate the
>> error on Fedora using the same LC_ALL=C locale.  With this change I
>> would fail to reproduce the error.
>
> But with the current patch you *would* get a visible warning on stderr saying:
>
> Python detected LC_CTYPE=C. Setting LC_ALL & LANG to C.UTF-8.
>
warning is not enough IMHO, but
>
> Agreed, and my original idea upstream included an environment variable
> override to account for that case:

I do think this is sufficient.  Debugging already requires setting an
env var (LC_*=C) so setting a second one in addition is not a big
deal.  The internet will have outdated information on debugging for a
few years and then people will figure out the new invocation and
adapt.

>> I think the library is the appropriate place.  Otherwise you end up
>> with a python application failing when run under mod_wsgi[*]_ which
>> you can't debug using the command line interpreter.
>
> There's one pragmatic problem with that, and one that's a question of
> appropriate division of responsibilities in terms of understanding the
> runtime's context of use.
>
> The pragmatic problem is that the main CPython binary calls
> https://docs.python.org/3/c-api/sys.html#c.Py_DecodeLocale to convert
> the command line arguments from char* to wchar_t* before it calls
> Py_Main, which means we have to override the locale *before* we hand
> over control to the dynamically linked library. Otherwise we end up in
> exactly the same situation that click complains about: by the time we
> find out there's a problem with the locale, some work has already been
> done using the wrong setting.
>
I thought about this one and decided it isn't really a problem.  Just
make the check in both places.  The CPython binary is choosing/needs
to preprocess the arguments before calling Py_Main so it needs to
check and set locale to do its job.  libpython needs to make the same
check before it knows it can do its job successfully.  (Actually, this
looks like an API choice on libpython's part.  The arguments are
decoded from raw bytes but they aren't assigned any semantic meaning.
If libpython handled the decoding as well, then this wouldn't be a
concern).

> The architectural problem is that when you embed CPython, it really is
> one of the embedding application's responsibilities to configure the
> locale such that the interpreter plays nice with the rest of the
> application. It's one thing to second guess the shell from directly
> inside a C-level main() function when we know POSIX makes some really
> old ASCII-centric assumptions and that developers are prone to writing
> "LANG=C" rather than "LANG=C.UTF-8" to turn off their locale settings,
> but something else entirely to second guess a GUI application like
> Blender (where arbitrary amounts of code may have already run before
> the CPython runtime gets initialised) or an application platform with
> its own environment management system like Apache httpd.
>
yeah, this one is much tougher, although I disagree on the reason it's
a problem.  I do not think it's necessarily the embedding
application's responsibility to make sure the embedded interpreter.can
run but the nature of the environment variables being process-global
means that the library can't set them without affecting the
application as a whole.  That's a big no-no..

I'd almost say that internalizing the click behviour could be the
correct design here.  Have the library check that it has a locale with
non-ascii capabilities and fail if it doesn't would be helpful.  That
would quickly point to differences in behaviours running under a
mod_wsgi vs /usr/bin/python, for instance, prompting the user to fix
the mod_wsgi deployment in advance.  OTOH, users don't run into the
problem all the time (it depends on the data being processed and how
it is handled) so it seems heavy handed to do it this way (I suppose
by the same argument I'd have to say that click is doing it wrong to
force users to address ascii-only locales...)

The costs here are very steep in both directions... so I don't see any
good ways to address it yet.  The best I can offer so far is for the
library to check and warn if an ascii-only locale is used.  That way
someone who encounters a UnicodeError in code deployed under mod_wsgi
is shown how to debug this when they run it under /usr/bin/python.  So
something like this from the library:

libpython detected LC_CTYPE=C.Some encoding errors may occur..
Us

Re: Python 3.6, Fedora, and the "C" locale

[Toshio Kuratomi]

On Wed, Dec 14, 2016 at 10:40 PM, Nick Coghlan  wrote:

> I opened an issue and attached a patch at
> https://bugzilla.redhat.com/show_bug.cgi?id=1404918
>
> I also cross-linked it with the most recent upstream issue at
> http://bugs.python.org/issue28180
>
Comments on the patch:

* In: http://bugs.python.org/issue28180#msg282964  you mentioned
adding a  "PYTHONKEEPASCIILOCALE environment variable to turn that
behaviour off".  but this patch doesn't implement thta.  I think that
will be necessary to address the cross-platform debuggability concern
I had eearlier in the thread.

* I'm not 100% certain that LC_CTYPE is the best thing to check.
People will set LC_CTYPE in conjunction with LC_COLLATE to C to get a
predictable sort order.(CTYPE is needed because bytes can be
interpreted as different characters and those differences can affect
sort order.).  Changing this will mean that their command line sort
order (ls, sort, etc) could differ from python's sort order.  I
haven't thought this fully through or a better way to check for our
actual meaning, though, and perhaps python already uses LC_CTYPE in
ways that would differ from other unix tools?

* Thinking about whether this belongs in the library or the
interpreter some more I'm seeing some hefty cons in both directions.
already noted that the con for doing it in the interpreter is that we
get out of sync with other things linking to libpython, therefore
making debugging harder.  The con for doing it in the library is that
the environment is global to the process.  So mucking with it in the
library would affect the entire application, not just the portion
that's interpreting python.  Not sure what to do here


-Toshio
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Python 3.6, Fedora, and the "C" locale

[Toshio Kuratomi]

On Mon, Dec 12, 2016 at 1:39 AM, Nick Coghlan  wrote:

> I don't anticipate any major concerns with downstream redistributors
> adding this behaviour, as the main thing that makes us nervous about
> globally changing the default upstream is the sheer variety of Linux
> distros out there, and the fact that folks are inclined to take their
> Linux integration bugs straight to bugs.python.org rather than first
> trying the issue tracker for their particular distro.
>
My one concern is precisely this variety.  For instance, if I get a
report that my application is raising a UnicodeError on RHEL7 when run
under cron (which uses the C locale) I might then try to replicate the
error on Fedora using the same LC_ALL=C locale.  With this change I
would fail to reproduce the error.

This is a variation on arguments about why individual sites should not
change the default encoding via sitecustomize.py.  The changes tend to
make python applications non-portable.  I don't think it is as severe
because we're still able to broadly classify things as "Fedora Python"
vs "Upstream Python" (instead of "Python running at My Business" vs
"Python running on the rest of the world" but it still is problematic.

OTOH, if this is a stepping stone and proving ground for getting it
into upstream Python then we just get this change a little early...
that's IMHO, a good thing.

Perhaps what's needed is a locale on Fedora that allows people to
select an ascii encoding for python which does not coincide with the C
locale.  This should satisfy the case you mention that *most* of the
time the C locale is not a conscious desire to select the ascii
encoding but also, as I'm pointing out, the need to select an
ascii-only encoding for debugging cross-platform scripts and
applications.

[..]
> As far as where we might add that check, I'd suggest the entry point
> for the `python3` binary itself, rather than in the shared library:
> https://hg.python.org/cpython/file/3.6/Programs/python.c#l46
>
I think the library is the appropriate place.  Otherwise you end up
with a python application failing when run under mod_wsgi[*]_ which
you can't debug using the command line interpreter.

.. [*]: or in libreoffice or any other application that links to
libpython for scripting

-Toshio
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: Python 3.6, Fedora, and the "C" locale

[Toshio Kuratomi]

On Sun, Dec 11, 2016 at 3:24 AM, Thomas Spura  wrote:

>
> To change the default encoding for python was proposed a while ago [1], but
> was finally dropped again, as upstream didn't agree to this change. Did
> anything changed here from upstream python?
>
> Best,
>Thomas
>
> [1] https://fedoraproject.org/wiki/Features/PythonEncodingUsesSystemLocale
>
The Feature to change the encoding in Python2 was problematic because
of its implementation.  It lead to some pretty nasty problems such as
breaking dictionaries.  See my blog post about that:
https://anonbadger.wordpress.com/2015/06/16/why-sys-setdefaultencoding-will-break-code/

So the difference here is that the proposal is to change the locale.
That won't mess with the low-level handling of data structures that
messing with sys.setdefaultencoding would.

One of the things that makes changing the locale easier is that Fedora
now supports a C.UTF8 locale.  So Fedora now ships with a UTF8 capable
fallback.  If we'd tried to implement this precise change before the
nearest equivalent of a universal utf8-capable locale would have been
something like en_US.UTF8 which a significant minority would not have
found as universal as we would have liked.

-Toshio
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Virtual packages providing python2-*

[Toshio Kuratomi]

On Tue, Feb 23, 2016 at 2:00 PM, Jason L Tibbitts III  wrote:
> One annoying difference between packaging for Fedora and EPEL7 (and
> probably older) is the fact that Python packages in Fedora are required
> to provide "python2-foo" whereas many EL7 packages don't.  This leads to
> ifdefs and unpleasantness, and kind of complicates our ability to hide
> some details behind macros.
>
The easiest thing to do if you want a single spec file for EPEL7 and
Fedora is to Requires: python-foo rather than python2-foo.  The
packaging guidelines say that the python2 version of the module should
provide both python-foo and python2-foo (one of those being the
package name and the other a virtual provide)

> As I see it, the easiest way to hide this (besides RH maintainers
> updating those packages with the extra Provides:) is to add a bunch of
> empty packages named "python2-foo" which have nothing but a dependency
> on "python-foo".
>
Adding extra packages has the detriment of increasing the metadata
size that has to be downloaded when depsolving.

>
> Even just getting python2-setuptools in would eliminate a lot of cruft.
> There are, I believe, 166 packages which might need this, though we
> don't have to add them all at once if that makes things more palatable.

166 packages might not be so bad... Or as you say, just doing a few
high value ones like python2-setuptools might be the best of both
worlds, providing compatibility for the most common cases but not
adding significantly to the metadata.

-Toshio
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Which python3 versions to package for EPEL7?

[Toshio Kuratomi]

On Tue, Jan 05, 2016 at 08:07:22PM -0700, Orion Poplawski wrote:
> So, I've started packaging up a bunch of python3 only packages for EPEL7 for
> packages that were already in RHEL7.  I've started by packaging the latest
> version of the modules:
> 
> python34-py.noarch   1.4.30-2.el7  epel-testing
> python34-setuptools.noarch   19.2-3.el7epel-testing
> 
> But these are much newer than the python2 versions:
> 
> python-py.noarch 1.4.27-1.el7
> python-setuptools.noarch 0.9.8-4.el7
> 
> I'm afraid I was motivated by the possibilities of supporting newer python3
> code, but Matthias RUnge makes the valid point that this may cause confusion
> and other problems[1].
> 
> What's the consensus here?
> 
> 1 - https://bugzilla.redhat.com/show_bug.cgi?id=1294865#c3
>

Matthias Runge is correct that there will be a confusion factor.  That will
be especially pronounced for libraries which are used specifically for
compatibility between python2 and python3 (python-six, python-backports-*,
python-future if someone packages it eventually).  This confusion is cut
down slightly by having a different naming scheme (34 rather than just 3)
for these packages than the equivalents in Fedora.  However, as the naming
difference is small, the amount that it helps with the confusion is also
small.  We would have been in a lot better place today if we had separate
packaging of python2 and python3 packages in Fedora so that they were never
in sync there but that's not something we can probably change now

Despite the confusion, my feeling is that we want the newer versions.
People who want to run python3 are willing to live more on the bleeding
edge.  What I've observed is that they want newer versions of libraries as
well.  Building packages that nobody wants to use because they are too old
isn't that helpful to those who want to use the system packages for their
development.  For us packagers, getting applications to run on python3
frequently needs newer versions of supporting libraries due to bugfixes for
python3 going into those libraries.  Attempting to pin the python34 versions
to the versions that ship with RHEL or in EPEL as the python2 version will
quickly become a hindrance to us in those efforts as well.

If we deem the confusion factor to be too great we could resort to the
Debian library route and name packages with the library version number as
well: python34-setuptools19, for example.  But that carries its own set of
problems: 1) Although we have a way (via setuptools/pkg_resources) to make
both packaging of alternate modules and usage of the modules work it isn't
as easy as working with modules packaged in the normal way. 2) If it's
standard for us to package python34 modules as compat packages, our support
burden will increase as people create packages for multiple versions of
the upstream library.  We (EPEL) need to figure out some policies on
retiring old packages when they're no longer maintained.  3) If we're
retiring unmaintained older versions of packages during the lifetime of
a RHEL release then we probably need to figure out if our present method for
determining the default python module (what version you get if you just do
"import setuptools") is the best.  The current way is basically, whichever
version entered EPEL first is the default, all others are forward compat
packages.

-Toshio


pgpGexnqv8uJu.pgp
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: [EPEL-devel] Which python3 versions to package for EPEL7?

[Toshio Kuratomi]

On Tue, Jan 05, 2016 at 08:07:22PM -0700, Orion Poplawski wrote:
> So, I've started packaging up a bunch of python3 only packages for EPEL7 for
> packages that were already in RHEL7.  I've started by packaging the latest
> version of the modules:
> 
> python34-py.noarch   1.4.30-2.el7  epel-testing
> python34-setuptools.noarch   19.2-3.el7epel-testing
> 
> But these are much newer than the python2 versions:
> 
> python-py.noarch 1.4.27-1.el7
> python-setuptools.noarch 0.9.8-4.el7
> 
> I'm afraid I was motivated by the possibilities of supporting newer python3
> code, but Matthias RUnge makes the valid point that this may cause confusion
> and other problems[1].
> 
> What's the consensus here?
> 
> 1 - https://bugzilla.redhat.com/show_bug.cgi?id=1294865#c3
>

Matthias Runge is correct that there will be a confusion factor.  That will
be especially pronounced for libraries which are used specifically for
compatibility between python2 and python3 (python-six, python-backports-*,
python-future if someone packages it eventually).  This confusion is cut
down slightly by having a different naming scheme (34 rather than just 3)
for these packages than the equivalents in Fedora.  However, as the naming
difference is small, the amount that it helps with the confusion is also
small.  We would have been in a lot better place today if we had separate
packaging of python2 and python3 packages in Fedora so that they were never
in sync there but that's not something we can probably change now

Despite the confusion, my feeling is that we want the newer versions.
People who want to run python3 are willing to live more on the bleeding
edge.  What I've observed is that they want newer versions of libraries as
well.  Building packages that nobody wants to use because they are too old
isn't that helpful to those who want to use the system packages for their
development.  For us packagers, getting applications to run on python3
frequently needs newer versions of supporting libraries due to bugfixes for
python3 going into those libraries.  Attempting to pin the python34 versions
to the versions that ship with RHEL or in EPEL as the python2 version will
quickly become a hindrance to us in those efforts as well.

If we deem the confusion factor to be too great we could resort to the
Debian library route and name packages with the library version number as
well: python34-setuptools19, for example.  But that carries its own set of
problems: 1) Although we have a way (via setuptools/pkg_resources) to make
both packaging of alternate modules and usage of the modules work it isn't
as easy as working with modules packaged in the normal way. 2) If it's
standard for us to package python34 modules as compat packages, our support
burden will increase as people create packages for multiple versions of
the upstream library.  We (EPEL) need to figure out some policies on
retiring old packages when they're no longer maintained.  3) If we're
retiring unmaintained older versions of packages during the lifetime of
a RHEL release then we probably need to figure out if our present method for
determining the default python module (what version you get if you just do
"import setuptools") is the best.  The current way is basically, whichever
version entered EPEL first is the default, all others are forward compat
packages.

-Toshio


pgpxjpNAbt8Ie.pgp
Description: PGP signature
___
python-devel mailing list
python-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: New (optional) python egg dependency generator for RPM

[Toshio Kuratomi]

On Wed, Nov 18, 2015 at 5:27 AM, Neal Gompa  wrote:
> On Wed, Nov 18, 2015 at 2:48 AM, Nick Coghlan  wrote:
>> I'd been thinking using "pip install" instead of "setup.py install" in
>> the build macros would be sufficient, but I now realise that isn't the
>> case - if a project uses flit (for example) as its build utility, then
>> we're going to need to generate a suitable BuildRequires in pyp2rpm
>> and similar tools (perhaps using the "BuidlRequires:
>> pythonX.Ydist(flit)" format). The build macros themselves could still
>> delegate the task of working out the right build command to invoke to
>> pip, though.
>>
>
> The main issue I see with that is how to make it so that python upgrades
> aren't obnoxiously painful. If BuildRequires use pythonXdist(module) format,
> but all *generated* runtime requirements use pythonX.Ydist(module) format,
> this problem goes away. But as Toshio mentioned, how do we solve that in a
> multi-version environment (like Enterprise Linux, for instance)?
>
Really, for this I think continuing to use package names is the right
thing to do.  Package names uniquely identify the package built for
the default python version for that distribution+release which is what
we want to make rebuilding a package on a newer release with a newer
version of python as the default.  Attempting to build this into the
generated dependencies duplicates the features that relying on the
name gives us.

> Using pythonX.Ydist(module) for BuildRequires effectively locks the module
> to a specific Python version until each and every maintainer upgrades them.
> That is an awful thing to have to do, and no other programming environment
> in any RPM-based distribution requires that. Most of the time, this is an
> unnecessary burden on the package maintainers.
>
Note: we do want this when we're specifically building a package for a
non-default version of python.  If we want to have python2.7 in EPEL6
or python2.6 in Fedora24 or (python3.5 and python3.4 for that matter),
then the package stack built for that non-default python needs to
specify that the packages it requires also need to be those built for
that stack.  So all of those packages can  BuildRequire the X.Y
autogenerated deps.

It's for the default stack that we want to have some notion of
"default" within the dependencies

> My view on pythonXdist(module) vs pythonX.Ydist(module) for
> BuildRequires is that DNF/Zypper may actually solve this issue for us.
> Perhaps presenting it with pythonXdist(module) and a package that provides
> the appropriate "python(ABI) = X.Y" as part of the builddep grab will actually
> pick the right one (after all, each module would Require a specific
> "python(ABI)" anyway). I'm not sure if Yum would do the same, though
> (I hope it does!). I suppose the key is whether or not the depsolver analyzes
> the whole request before creating its proposed transaction, rather than
> iteratively solving and presenting the results.

No depsolver should solve this in its core code.  it's a special case
that relies on information and decisions outside of the package deps'
literal meanings.  Making the special case mandatory would definitely
lead to issues.  For instance, say python-foo ships a utility along
with its library and there is no python3-foo.  python3-bar requires
the utility to build.  If dnf is made to only satisfy the dep if the
package also matches on python(abi) then this will not be buildable
because the depsolver is trying to be too smart instead of doing what
the packager told it to do.

-Toshio
___
python-devel mailing list
python-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: New (optional) python egg dependency generator for RPM

[Toshio Kuratomi]

On Nov 17, 2015 8:18 AM, "Neal Gompa"  wrote:
>
> I see the problem you are describing, but how do you solve it currently?
>
Currently we use manually specified dependencies with package names here.
So when python2.6-foo is built, the packager specifies a dependency on
python2.6-setuptools.

> That said, I *think* I could autogenerate Provides for pythonX.Ydist(M)
> and pythonXdist(M), while only having requires generated
> with pythonX.Ydist(M). Would that solve the problem while allowing
> BuildRequires using pythonXdist(M) to pick up the latest one? I'm not
> entirely sure it would...
>
Nope. In the spec you would need both major and minor to make auto
generated dependencies work correctly in all circumstances.

If your particular distribution only shipped a single version of python2
and a single version of python 3 on that distribution you could use
pythonXdist but the packages would break on other distributions that
shipped multiple runtimes.

Something to consider: if you're worried about how to specify manual deps
in the spec file portably it may be best to continue using package names
there.  That way built packages take advantage of the auto dep generator in
most cases, most packagers can specify buildrequires using the generic
package name that's stable across distro releases (and sometimes across
distros) and truly special cases can pin a specific compatible runtime by
manually specifying pythonX.Ydist(foo).

Also, if doing it this way makes the pythonXdist unnecessary it would be
nice to leave it out.  The size of yum metadata is a big bottleneck.  I
believe someone once enabled erlang auto deps that increased the size so
much that we (fedora) removed that auto dep generator from our packaging
(overriding the maintainer).  It feels like an even worse problem these
days when the packageset is bigger and dnf is downloading the full filelist.

-Toshio
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Python3 as default

[Toshio Kuratomi]

On Apr 15, 2015 2:57 AM, Robert Kuska rku...@redhat.com wrote:

 pip is not a application, even though it is not used via import statement
both python3 and python2
 versions provides different functionality (python-pip installs python2
packages and python3-pip
 installs python3 packages), therefore it is a *module*.

This should probably be phrased differently in the final draft.  Pip is an
application.  But because we need it to provide both a python 2 and python
3 cli tool it follows the same guidelines as dual-python-version modules
rather than applications.  This category might even deserve its own
subsection as there's a couple other specific things to do with these types
of packages.


 *MODULES*

 M1. First of all, all *modules* which aren't using versioned macros must
be fixed to use them.
 This can be done right away as this is already part of packaging
guidelines and all packages
 should comply with guidelines.
 * Note: There is around of 1000 packages using unversioned macros [3]

 M2. We should add provides for python2-foo modules. So python-foo would
provide python2-foo.

I'd make the following its own should bullet as the first part of M2 is
more important. the python-foo package names aren't going away so if we get
into a time crunch for f22, this second portion isn't as critical as the
first.

 Fix all the modules to (Build)Require python2-bar instead of python-bar
(python should
 also provide python2).

 Also if module foo ships bin file `baz` it should have `baz` and
 `baz2` bin file inside `python-foo` and `baz3` file inside `python3-foo`.

I disagree with this but I think it's probably just an omission of some
information.  We need to make clear here that this is only for bin files
where it is necessary to shop a version that runs on py2 and a version that
runs on py3.  Most packages should just ship one version of the bin scripts
for the default python version.  (Note, I don't think we can wrap this
choice into a convenient macro.  It'll probably need a spec file
conditional if packagers want to have a single spec for multiple branches.)


 M3. All modules should be build with option
--executable='/usr/bin/python(2,3)'. This could be
 resolved in [4]


I'm not sure if this is true.  Pure modules don't have a shebang line so I
think the choice of which python interpreter runs them and determines the
path they install into is sufficient.

From a message from ncoghlan a long time ago I think things in bin should
use /usr/bin/python(2,3) in their shebang as long as the setup.py is
invoked with the versioned path.  So --executable is extraneous for these
purposes.  (But if [4] is the -s guideline update, we would want to use
--executable for that purpose for packages providing things in bin).

 *APPLICATIONS*

 A1. All application must use the default python (of course only if
upstream supports it).
 Applications can continue using {__python} macros and it derivatives. We
should add a macro
 for (Build)Requires:

 %global py_default_major 3 # this could be part of f23 buildroot macros
 BuildRequires: python%{?py_default_major}-foo

 This way would maintainer have same specfile for both fedora and epel and
also if the default
 python will change in the future the only thing that would need a change
is the `py_default_major`
 value or we could make the value to be resolved by %{__python} macro.

 A2. Same as M3 (=should be resolved by [4]).

 *{__python} VS /usr/bin/python CONFUSION*
 Why is value of {__python} being changed and /usr/bin/python (along with
python-foo being python2)
 is untached? I see this as two different situations or two different
point of views.

 /usr/bin/python is a *user view*, as a user I would expect when I type
python that it would fire
 up python2 interpreter as this is the default behaviour for
all(-ArchLinux) distros and also
 python.org recommendation. Similarly when I type `sudo dnf install
python-foo` I would expect
 to receive python2 version of foo package. This is why we stay with
/usr/bin/python pointing
 to python2 and python-foo to provide python2 version of package. As a
user I don't care for macros
 and their values, they are hidden from me = I am not confused, I get
what I expect.

 {__python} is a *packager view*, as a packager, I follow the guidelines
and I follow the changes.
 I understand that there are two major versions of interpreter and we are
switching to the python3
 to be the default one.
 For me, python-foo is just a name of the package. I operate with
python(2/3)-foo as build(requires)
 and versioned macros within my specfile if the package is the module. I
understand why python-foo
 provides python2 version of package, yet I operate only with versioned
packages/macros = I
 am not confused, its just *python2* or *python3* for me.
 If my package is an application, I use only default python macros because
I ship only one version
 of an application for one version of an interpreter = I am not confused
its just *python* for me and
 *python* 

Re: Apps using default Python in Fedora vs. EPEL

[Toshio Kuratomi]

On Feb 25, 2015 3:14 PM, Nick Coghlan ncogh...@gmail.com wrote:

 For those not following along with the FPC ticket, Toshio and Tomspur
 have a nice write-up of the options at
 https://etherpad.mozilla.org/2Uqk0ikCll

 I came back to this question myself due to a couple of different
 ideas, discussed in https://fedorahosted.org/fpc/ticket/498#comment:19

 * How does the situation in Fedora change if the upstream PEP 494
 recommendation to downstream Linux distros was to change in
 conjunction with the Python 3.5 release currently scheduled for
 September? That release (https://www.python.org/dev/peps/pep-0478/)
 amongst other things, automatically handles EINTR errors for syscalls,
 restores binary interpolation support and adds matrix multiplication
 support and os.scandir().


I would be against making the switch to /usr/bin/python at this time but
would do most of that fighting upstream.  If the pep were updated then I'd
at least want to see that the other major distros are committed to changing
their /usr/bin/python at the same time.

Changing the behavior of a well known program like this is a bad idea.  As
it breaks compatibility: with people's home grown scripts, with their self
installed programs, and between os's and os releases. The pep is palatable
because the arguments in favor of someday changing the value revolve around
someday there not being a /usr/bin/python on most systems. At that point it
becomes reasonable to reallocate /usr/bin/python and let the systems where
/usr/bin/python be declared legacy and the behavior of /usr/bin/python on
those legacy systems is the quirk, not ours.

We could cut over sooner than this argument actually makes the case for but
now is definitely not that day.  Fedora, rhel, ubuntu, aren't yet at the
point where /usr/bin/python isn't present on most of their installed
systems in their latest version, let alone all of their versions.people are
still pulling /usr/bin/python onto their systems through dependencies for
common applications even if their os is advanced enough not to need it by
default.  We have quite a ways to go before /usr/bin/python can be switched.

 * With the default interpreter change postponed to Fedora 23, would it
 make sense to patch the system Python in Fedora 22 to emit Python 3
 warnings by default when it was run using the unqualified python
 reference rather than being run as the qualified python2? And then
 switch the symlink along with the RPM macros in Fedora 23?


No to switching the value of /usr/bin/python and stated above.  The test
makes some sense. If your warning is restricted to warning not to use
/usr/bin/python (use /usr/bin/python 2 instead) that sounds really good to
me.  (Your wording sounded like we should turn on warnings like python2 -3
does which I don't think is such a good idea for fedora 22 but might be
good in the future... our perhaps, like the kernel does with extra kernel
debugging, we should turn it on in rawhide and fedora.n+1 but turn it off
before release.)

 It's also worth noting that the change I am considering to the
 upstream recommendation would place a qualifier on the distro
 providing a C.UTF-8 locale, so the C.UTF-8 in upstream glibc RFE
 (https://sourceware.org/bugzilla/show_bug.cgi?id=17318) would become a
 key enabler for making the symlink switch in Fedora (associated Fedora
 RFE: https://bugzilla.redhat.com/show_bug.cgi?id=902094)

Like tomspur I'm not sure I see the specific relevance of this to what
/usr/bin/python invokes although I would welcome the change :-)

-Toshio
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Apps using default Python in Fedora vs. EPEL

[Toshio Kuratomi]

On Wed, Jan 28, 2015 at 11:59:01AM -0500, Bohuslav Kabrda wrote:
 - Original Message -
  On Tue, Jan 27, 2015 at 06:26:26AM -0500, Bohuslav Kabrda wrote:
   
   Current state:
   - Up until F21, maintainers were encouraged to build applications with
   Python 2, but weren't discouraged from building with Python 3.
  
  Note -- this isn't quite right.  If an application could run with either
  python2 or python3 maintainers in F21 and below were supposed to have the
  app run with python2.  F22 is supposed to flip this so that maintainers are
  supposed make these packages run with python3 instead of python2.
 
 I guess that I interpreted it my way since I didn't see any must in 
 there... But ok, thanks for the clarification :)
 
Yeah -- a product of Fedora Guidelines being written by different people at
different times.  We don't have strict RFC-like usage of should and may in
most places. (must is usually unambiguous as to being a directive and
a bolded should, must, or may has precise meaning.  Other uses (or
simple lack of any of those terms) leaves the question of how strict
a question that would have to go back to the FPC to figure out what they
meant in the past or what they want it to mean in the present day.)

   - This means that packagers will be able to use the unversioned macros
   throughout their specfile. Requires and BuildRequires will look like this:
   
   Requires: %{default_python}-flask
   BuildRequires %{default_python}-setuptools
   
   Note: since BuildRequires need to be expanded in the minimal buildroot,
   it's necessary to define the %default_python macro in the specfile. Other
   way would be to define it in a macro file that would be added to the
   minimal buildroot, but that's neither very likely nor very nice :)
   
  Have you talked to dennis?  We've added packages to the minimal BuildRoot
  many times before in order to enable macro files.  Not so problematic if
  it's only one macro, though.
 
 I will. Do you have any idea who I should talk to regarding EPEL? Is it also 
 Dennis?

Also dennis.  Rel-eng is growing as a group so you could also put in
a ticket/go to one of their weekly meetings but Dennis is probably still the
one that knows the most about koji and buildroots.

 
   
   I think this solution makes sense for *applications* that need to be built
   both in Fedora and in EPEL. Note that it'd also align with my EPEL-python3
   proposal [1], in case such an app was to be moved to python3X in EPEL
   (%default_python would just be redefined to python3X). I also think that
   this approach should never be allowed for packaging libraries, e.g.
   packages that have python-foo and python3-foo subpackages.
   
   Thoughts?
  
  If we were to use different macro names instead of overwriting currently
  well known ones I think this has merit.
 
 For me, introducing yet another set of macros is unnecessary. I think that 
 it'd introduce a long(-ish) new part of guidelines that'll make them even 
 more complicated than they are right now (compared to one new macro function 
 and rules on how/when to use it).

Nick's breakdown of the three desired states seems like a non-complex way to
organize things.  And explicit being a good thing is also a winner for me.
In addition to my original arguments that bashing existing macro names in
some spec files but not in all of them is a bad thing to force packagers to
have to deal with.

tangentially, when speaking about long-ish, though, could we use something
shorter than default_python?  Maybe syspython to follow Nick's usage of
System Python?

-Toshio


pgpW94ONm2CJU.pgp
Description: PGP signature
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Apps using default Python in Fedora vs. EPEL

[Toshio Kuratomi]

On Tue, Jan 27, 2015 at 06:26:26AM -0500, Bohuslav Kabrda wrote:
 
 Current state:
 - Up until F21, maintainers were encouraged to build applications with Python 
 2, but weren't discouraged from building with Python 3.

Note -- this isn't quite right.  If an application could run with either
python2 or python3 maintainers in F21 and below were supposed to have the
app run with python2.  F22 is supposed to flip this so that maintainers are
supposed make these packages run with python3 instead of python2.

 - From F22 on, packagers will be encouraged to build with Python 3 rather 
 than Python 2.
 - Lots of packagers want to keep the same specfile for EPEL and Fedora.
 - Fedora guidelines mandate explicit usage of %__python2 and %__python3 (and 
 all the sitelib/sitearch macros).
 
 The Problem:
 If packagers want to build against Python 3 in Fedora and Python in EPEL 
 *and* keep the same specfile, they have to invent some ugly hacks, since 
 Fedora's guidelines require explicit usage of versioned Python macros. This 
 affects Requires and BuildRequires and %prep, %build, %install, %check 
 sections. People who want to do this either redefine %__python in Fedora to 
 point to Python 3 or something like that - I'm afraid that we could end up 
 with a huge pile of crazy macro redefinitions in tons of packages and I want 
 to avoid that.
 
 Proposed Solution:
 After thinking a few days about this, here's what I propose:
 - Every specfile will have a minimal header with macro definitions that will 
 look like this:
 
 %if 0%{?fedora}
 %global default_python python3
 %else
 %global default_python python
 %endif
 
 %make_default_python %default_python
 
 - The %make_default_python macro function will point all the unversioned 
 macros to proper values for given %default_python:
 
 ### In Fedora
 %{__python}- /usr/bin/python3
 %{python_sitelib}  - /usr/lib/python3.X/site-packages
 # and other macros...
 
 ### In EPEL
 %{__python}- /usr/bin/python2
 %{python_sitelib}  - /usr/lib/python2.X/site-packages
 # and other macros...
 
I'm not really a fan of redefining existing macros like this.  The problem
is the same as the python2 from __future__ import unicode_literals
statement.  It causes your existing knowledge of how things work to betray
you.  And recognizing that the change is present requires you to look
somewhere far away from the code that you are actually interested in.

 - This means that packagers will be able to use the unversioned macros 
 throughout their specfile. Requires and BuildRequires will look like this:
 
 Requires: %{default_python}-flask
 BuildRequires %{default_python}-setuptools
 
 Note: since BuildRequires need to be expanded in the minimal buildroot, it's 
 necessary to define the %default_python macro in the specfile. Other way 
 would be to define it in a macro file that would be added to the minimal 
 buildroot, but that's neither very likely nor very nice :)
 
Have you talked to dennis?  We've added packages to the minimal BuildRoot
many times before in order to enable macro files.  Not so problematic if
it's only one macro, though.

 
 I think this solution makes sense for *applications* that need to be built 
 both in Fedora and in EPEL. Note that it'd also align with my EPEL-python3 
 proposal [1], in case such an app was to be moved to python3X in EPEL 
 (%default_python would just be redefined to python3X). I also think that 
 this approach should never be allowed for packaging libraries, e.g. 
 packages that have python-foo and python3-foo subpackages.
 
 Thoughts?

If we were to use different macro names instead of overwriting currently
well known ones I think this has merit.

-Toshio


pgpaq3Gb4ghbI.pgp
Description: PGP signature
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Apps using default Python in Fedora vs. EPEL

[Toshio Kuratomi]

On Tue, Jan 27, 2015 at 10:50:07PM +1000, Nick Coghlan wrote:
 
  %if 0%{?fedora}
  %global default_python python3
  %else
  %global default_python python
  %endif
 
 I'm wary of this proposed solution mostly due to the fact that in the
 middle of last year, the Beaker team had to go through and completely
 redesign the way the automatic kickstart generation worked, because
 the templates were full of checks that assumed RHEL 6 as the default
 basis for derived distros. Once RHEL 7 and CentOS 7 were generally
 available, that assumption became problematically wrong (e.g. systemd
 wasn't a Fedora only feature any more), so the templates were all
 rewritten to be based on operating system feature flags instead (which
 had the added bonus of also making them more tolerant of Fedora
 derivatives).
 
 I see the seeds of a similar problem being planted with the above
 proposal: what happens when, at some point in the future, Python 3 as
 default is no longer a Fedora-only feature? Do we have to go edit all
 the spec files again?
 
Note that this ship has sailed long ago.  Fedora packaging spec style is
that someone (usually FPC) has to collect information about which
Fedora/RHEL version a feature became relevant and then construct
a conditional that accurately portrays that knowledge.  So in the example
above, at least a version check for fedora would be added.  When we are able
to build default python3 on rhel people would need to update spec files to
reflect that (but that's an EPEL branching event anyway so people are going to
have to do some manual work on to make the packages build on for the new
EPEL anyway.)

It would be good if we could do better, though

 What if, instead, we were able to add a new macro that let folks
 *explicitly* opt in to running in the system Python, but then define
 the recommended spec file usage such that it falls back to Python 2 if
 the system Python macro isn't defined?
 
Slavek raises the issue of how we get this into the buildroot.  An idea
could be to talk to rel-eng and the other packagers about adding these sorts
of system-feature macros to a package in the buildroot.  We could create
a new package or add onto an existing one (is epel-release and
fedora-release in the buildroot?)  the package would contain a small set of
macros that specified certain features about the OS that packagers need to know 
Then we really could write the conditionals as a feature test instead of
a distro version test.

One drawback is that we would have to push the macros out to every release
that we build for (epel and fedora) otherwise we'd still have to use
distro+version  conditionals.

-Toshio


pgpgBUYuy6UCF.pgp
Description: PGP signature
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: [Fedora-packaging] Changes in Guidelines Connected to Python 3 as Default Change

[Toshio Kuratomi]

On Thu, Dec 04, 2014 at 08:10:39AM -0500, Bohuslav Kabrda wrote:
  
  * sphinx-build-v0.9
  * sphinx-build-2-v0.9
  * sphinx-build-2.7-v0.9
  * sphinx-build-3-v0.9
  * sphinx-build-3.7-v0.9
 
 I'd rather see sphinx-build-v0.9-3.4. IMO keeping the Python version at
 the very end in every case is better. In other words, the binary would
 normally be sphinx-build-0.9 and we just append -3.4 to it.

I'm not really attached to whether the v0.9 goes before or after the -3.4
however, the argument was made earlier that upstream naming and documentation,
and tab completion were important factors.  To remain consistent with that
it seems more appropriate to put any Fedora-added suffixes for
backwards/forwards compat packages at the very end.

 Also, this makes me realize more arguments to append Python version with 
 dash, not without it:
 1) sphinx-build-v0.93.4 would be very confusing (I do understand that this
is a downstream problem, but see the following point)
 2) Similarly, if there is an upstream whose entry_point/script ends with
a number (pep8 for example), it'd be highly confusing to use the notation
without dash, it would yield pep83.4 assuming the upstream community would
accept this scheme. This feels just wrong.

I'm wholehearterdly in favor of dashes when we're creating these script
names too.

I also note that this line of reasoning also lends itself to putting any
backwards compat versions at the very end.  sphinx-build-v3.1-2 is more
ambiguous (especially to a sysadmin who is used to reading rpm NEVR's) than
sphinx-build-2-v3.1.  The v provides additional guidance to someone
looking at it that the number following it serves a separate purpose from
the number before it.

Anyhow, not really attached so I've stated the reasons I think the
fedora-local version suffix makes more sense at the very end and now I'll
shut about it ;-)

  Also an addition: It would be great for us to always have a major version
  number
  only script name.  Currently there's a few packages (python3-nose, I'm
  looking at you) that only provide the MAJOR.MINOR form ie: nosetests-3.4.
  That means scripts (user scripts as well as spec files) have to change
  whenever we update python3 to a new major release.  Having the major only
  form for all of these binaries will alleviate that.  Packagers can just
  create a symlink if upstrean doesn't provide the -MAJOR version.
 
 I do agree that we should have that, although you can now use 
 nosetests-%{python3_version}.
 
nod -- yeah, that's what I use in spec files now.  Unfortunately, spec
macros aren't as helpful for the scripts that I have for building and
testing my own projects.

Even in spec files, it's also an annoyingly long way to write 3.4 ;-)

-Toshio


pgpunmyEhLu9t.pgp
Description: PGP signature
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: [Fedora-packaging] Changes in Guidelines Connected to Python 3 as Default Change

[Toshio Kuratomi]

On Thu, Dec 04, 2014 at 11:18:58PM +1000, Nick Coghlan wrote:
 
 I think these are good reasons to default to using the dash if its
 Fedora adding it. The guideline could be something like For Python
 executables, also provide symlinks with a '-X' and '-X.Y' suffix,
 unless upstream already provides appropriately versioned executables
 without the dash. For compatibility packages, the Python version is
 appended *after* the specific package version.
 
Couple notes -- if we do go with putting the Python version after the Fedora
compat version, we'll want to phrase this so people know whether to do that
for all packages or only for those where upstream is not already putting the
version in the name.

Always putting the python version at the end means that users have to
remember that change when they switch to using a compat package:
nosetests-3.4 vs nosetests-v1.1-3.4

Only putting the Fedora version first when upstream doesn't provide the
names means that users have to remember the change on a package by package
basis:
sphinx-build-3.4-v1.1 vs nosetests-v1.1-3.4


We also want to mention the v addition to the version specified in the
compat version.  The v helps the user differentiate between the pyhton
version and the package version.  Most Fedora compat packages don't have
this matrix of $language_version + $package_version so they mark the compat
files with just a bare $package_version.  Since we have both, we need to let
packagers know that compat packages need to do a little bit more to
distinguish the two sets of numbers.

-Toshio


pgptkK18I6vNF.pgp
Description: PGP signature
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Changes in Guidelines Connected to Python 3 as Default Change

[Toshio Kuratomi]

On Thu, Dec 04, 2014 at 12:51:40AM +1000, Nick Coghlan wrote:
 
 On 4 Dec 2014 00:38, Bohuslav Kabrda bkab...@redhat.com wrote:
 
  So here are my proposals for changes in current guidelines [2]:
  - In [3], it says If the executables provide the same functionality
 independent of whether they are run on top of Python 2 or Python 3, then only
 one version of the executable should be packaged. Currently it will be the
 python 2 implementation, but once the Python 3 implementation is proven to
 work, the executable can be retired from the python 2 build and enabled in the
 python 3 package. - this should be changed to prefer Python 3
 
 Agreed.
 
Definitely +1 as well.

  - (This is not really related to the switch, but more of a general remark) 
  In
 [4], it says that python 3 version of the executable gains a python3- 
 prefix.
 This is IMO bad, since upstream projects tend to name the versioned binaries
 foo-3.4, foo-3 or foo3.4, foo3. We should accept one of these - I'm not
 really certain which one of them. I tried to discuss this several times on
 distutils-sig mailing list, but without reaching a consensus. Either way,
 prefixing with python3- doesn't make sense to me, because it's not similar to
 any upstream way and you don't find the binaries under their names using tab
 completion (e.g. footab doesn't tell you about python3-foo).
 
 Agreed.
 
 CPython  pip use the foo3.4, foo3 convention, so that seems enough of a
 reason to use that convention by default. We may want a unless upstream does
 it differently caveat though.
 
Second caveat here is that currently we use version suffixes to denote
a command coming from a compat package.  If we make this change we need to
address that as well.  So, you might have sphinx-build, sphinx-build-2,
sphinx-build-2.7, sphinx-build-3, and sphinx-build-3.4 for the python
interpreter.  If you need a forwards or backwards compat package you might
also have an 0.9 and 1.1 that you need to tack on.  Possible solution here:
use a v prefix for the compat package's version.  So if the default
package is 1.1, you would have the python-sphinx0.9 and python3-sphinx0.9
packages provide:

* sphinx-build-v0.9
* sphinx-build-2-v0.9
* sphinx-build-2.7-v0.9
* sphinx-build-3-v0.9
* sphinx-build-3.7-v0.9

Also an addition: It would be great for us to always have a major version 
number
only script name.  Currently there's a few packages (python3-nose, I'm
looking at you) that only provide the MAJOR.MINOR form ie: nosetests-3.4.
That means scripts (user scripts as well as spec files) have to change
whenever we update python3 to a new major release.  Having the major only
form for all of these binaries will alleviate that.  Packagers can just
create a symlink if upstrean doesn't provide the -MAJOR version.

  - As for binaries/scripts in /usr/bin (assuming there are both python2 and
 python3 versions), the unversioned files should point to python2 version. This
 aligns with /usr/bin/python still pointing to python2.
 
 This also aligns with CPython  pip conventions. Between them, only pyvenv
 runs under Python 3 by default, and that's only because it doesn't exist in
 Python 2.
 
One exception to this, I think, should be 2to3.  Or perhaps python-tools
should stop shipping 2to3 and the other /bin/ scripts which python3-tools
ships and are not needed in two versions (Not sure if any of those scripts
actually need to be carried in two versions.. pygettext.py might need to be
tested to be sure the python3 version can handle all sorts of python2
strings correctly).

-Toshio


pgpT3aeQuBQLI.pgp
Description: PGP signature
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: python-sig in pkgdb2?

[Toshio Kuratomi]

I've stepped back from packaging for the most part but I think this is a
great idea.  When I was active I'd often find something to cleanup in
python packaging for each release (pil = pillow; removing
python-setuptools-devel).  A python-sig group would definitely help with
future cleanups like those.

-Toshio
On Oct 6, 2014 2:49 PM, Haïkel hgue...@fedoraproject.org wrote:


 Le 6 oct. 2014 21:56, Thomas Spura toms...@fedoraproject.org a écrit :
 
  Hi all,
 
  there just was a request to test groups for pkgdb2 [1] and I thought
  it might be a good opportunity to maybe start sharing at least some
  core python packages among a few people.
 
  For instance, I maintain ipython and the dependency chain when other
  maintainers chose to orphan something I need for it (or ipython
  introduces a new dependency). Such packages are good candidates to be
  maintained by a group of people, so updates can be managed better and
  several people have an eye on them.
 
  What do others think about that? Who else would be interested in
  starting a common python-sig group in pkgdb2?
 

 I am.

  Greetings,
  Tom
 
  [1]
 https://lists.fedoraproject.org/pipermail/devel-announce/2014-October/001445.html
  ___
  python-devel mailing list
  python-devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/python-devel

 ___
 python-devel mailing list
 python-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/python-devel

___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: reproducible builds and python

[Toshio Kuratomi]

On Mon, Aug 11, 2014 at 08:01:23PM +0200, bmorbach wrote:
 Hi everyone!
 
 I've been doing some work towards reproducible builds in Fedora (mostly
 with various upstreams so far) and one of the elephants in the Room are
 obviously Pythons .pyc and .pyo files.
 
 As those contain the mtime of the original .py file, they might be
 different for each rebuild of an srpm.
 For many rpms this isn't a problem, because the files are not modified
 and thus retain their timestamp from the archive. Quite a few rpms do
 modify to .py files though and because of that, every build has a
 different result.
 
 I would like to propose to set the mtime of all .py files to a fixed
 (for this specific srpm) time. This could be done
 in /usr/lib/rpm/brp-python-bytecompile before doing the actual
 byte-compilation. This would result in the same .py{c,o} files being
 created for each rebuild.
 
 The timestamp could be e.g. the mtime of the oldest file in the
 buildroot (which would assume that not _all_ of the files are modified)
 But if you are interested in the idea, I'd certainly be open to
 suggestions.
 
 To address the obvious question:
 Why not special-case those files when comparing rpms?
 
 It will certainly be impossible to achieve this for all packages in
 Fedora, so for some files this might indeed be needed, but I think we
 should avoid this where possible. The idea of reproducible builds
 becomes meaningless if the amount of differences that you just ignore
 gets to big.
 
 
 What do you think of this proposal?
 
I'm not in love with this as it's throwing out information.  OTOH, the
information that's being thrown out may not be all that useful.  It would
help if we knew what the goal was here (besides simply being 100%
reproducible for the sake of being reproducible) as we could then think
about what we stand to gain for losing the real timestamp information.

One idea I just had -- only modify the timestamp of files whose mtime is
more recent than when the tarballs were unpacked.  This would leave files
that were simply untarred with the real upstream timestamps and any files
which would have had their timestamps modified anyway will get the new
timestamp.

One actual (though small) problem I see with lying about timestamps is that
your going to need to select a fixed time in the past that this timestamp
would be.  Looking at a directory of files and seeing that one file is from
about the time the package was built while the others are all older can be
an indication that the distro has changed the file from what is upstream
which can then lead to comparing against vanilla upstream to determine if
we're applying a patch that causes a bug.  If we have to apply a timestamp
in the past, that indication goes away.  (Small help because I only remember
doing this once in all my years of looking at files from packages :-)

-Toshio


pgp5FNwlVovUM.pgp
Description: PGP signature
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Some orphaned packages

[Toshio Kuratomi]

As some of you may know from flock or following the FPC meeting minutes, I'm
taking a break from Fedora.  As part of that, I've reassigned most of my
packages to others that can  care for them.  A few packages don't have
obvious owners (mostly in specific branches) So I've orphaned them.  If
you'd like to pick them up, please go to the pkgdb and do so:

qbzr, bzr-explorer = orphan
gprof2dot = orphan
python-paver = orphan
python-elixir = (orphan Fedora devel, Fedora 21, Fedora 20, Fedora 19,
Fedora EPEL 5)
python-cpio = toshio (Doesn't update much so I could keep it but I'm not
using it so I'd be happy to give it to someone ele)
bzr-gtk = orphan (epel5)
bzr, bzrtools = orphan on epel5
python-cjson (el5) = orphan
python-migrate = orphan(el5)

-Toshio


pgpomFY24fCwY.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Brokenness in newly created dist-git repositories

[Toshio Kuratomi]

On Tue, Jul 22, 2014 at 08:11:30PM +0100, Richard W.M. Jones wrote:
 
 Two new packages/repositories have been created for me recently.
 Both appear to be broken in a subtle, non-fatal way:
 
   $ fedpkg clone ocaml-camlp4
   $ cd ocaml-camlp4/
   $ fedpkg verrel
   Exception AttributeError: '_read_only' in bound method write.__del__ of 
 git.config.write object at 0x1872d70 ignored
 
 [ the command hangs for a few minutes before printing ... ]
 
   ocaml-camlp4-4.02.0-0.3.git87c6a6b0.fc22
 
 The other repository which is broken in the same way is `ocaml-labltk'.
 
 This doesn't happen for me on any other dist-git repository, so I
 don't believe it has anything to do with my copy of fedpkg or my
 environment.
 
 I opened a bug about this but it didn't get any traction:
 
   https://bugzilla.redhat.com/show_bug.cgi?id=1121333
 
 I'm slightly worried that all new repos are being built incorrectly
 somehow.
 
Looks to me like it's an aspect of this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=843292



pgpx3awVxpKu3.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Brokenness in newly created dist-git repositories

[Toshio Kuratomi]

On Tue, Jul 22, 2014 at 08:31:50PM +0100, Richard W.M. Jones wrote:
 
 OK I see in the final comment there is a hang reported.  I would still
 be interested in whether anyone else can reproduce the bug on the
 specific two repos: ocaml-camlp4  ocaml-labltk.
 
Yep, I can reproduce on those two.  I notice that one of the comments on the
bug seems to indicate that this is happening on git repos that only have the
master branch so that might be a clue as to why these two new repositories
are the only ones you're seeing with the issue.

-Toshio


pgp5duj71FFrC.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: EPEL Orphan or retire the TurboGears (v1) stack in 7

[Toshio Kuratomi]

On Fri, Jul 11, 2014 at 05:41:04PM +1000, Dan Callaghan wrote:
 
 I'm a little confused now though... I would have also expected these 
 other TG1 pieces to be on the list:
 
 * python-TurboMail

This doesn't have a dep on TurboGears in them so my repoquery didn't pick
it up.  Possibly a packaging bug.  I'm pretty sure that lmacken won't want
to maintain this on EPEL7 either so you'll probably want to pick it up if
you need to send email from the web app.

 * python-tgmochikit

This was my mistake... I remember asking lmacken about it but I just didn't
retire it when I retired the others.

 * TurboGears

This was also my mistake.  TurboGears isn't a dep of itself nor does it
require itself... so when I went down the list of deps, I forgot to orphan
it either.  Oops.

Dan, would you like me to reassign the epel7 branch of all three of these
packages to you?

-Toshio


pgp_phXCiX5Pj.pgp
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Orphan or retire the TurboGears (v1) stack in 7

[Toshio Kuratomi]

On Thu, Jul 10, 2014 at 05:39:40AM +, Zhiwei Zhu wrote:
 Hi Toshio,
 
 I have just noticed this message after I failed to install TurboGears (v1) on 
 CentOS 7.
 
 We really need the TurboGears (v1) support via epel for el7.  Migrating away 
 from TurboGears V1 to V2 or to other framework seems impossible for us at the 
 moment, though we know that we will have to migrate in future.
 
 Could you help to suggest what we could do to revive these packages and have 
 epel7 will still support TurboGears( v1 )?
 
Sure!  Become a package maintainer and maintain the packages that have
become orphaned in EPEL7.

Note that you won't need to revive all of the packages -- some of those were
retired because they depend on TurboGears1 (for instance, bodhi).  You'll
only need to revive the ones that TurboGears1 depends on (and those that
your applications need).

-Toshio

 
 --
 Best Regards
 Jacky
 
 -Original Message-
 From: epel-devel-boun...@lists.fedoraproject.org 
 [mailto:epel-devel-boun...@lists.fedoraproject.org] On Behalf Of Toshio 
 Kuratomi
 Sent: Saturday, 21 June 2014 3:02 AM
 To: epel-devel@lists.fedoraproject.org
 Subject: Re: EPEL Orphan or retire the TurboGears (v1) stack in 7
 
 On Mon, Jun 16, 2014 at 12:01:26PM -0700, Toshio Kuratomi wrote:
 
  If someone steps up to say they'll take ownership of TurboGears1 (one
  of the comaintainers or someone new), then I'll reassign these packages to 
  them.
  If no one does, then I'll retire them in epel7 and ask that the
  packages be removed from the download repos before epel7 leaves beta.
  Someone can revive them later if they're interested.
 
 
  == Packages to be orphaned retired ==
  * python-cherrypy2
  * python-elixir
  * python-peak-rules
  * python-turbocheetah
  * bodhi
  * python-tgcaptcha2
  * python-turboflot
  * python-turbokid (need to remove a spurious dep on this from
  TurboGears2)
  * python-turbojson (need to remove a spurious dep on this from
  TurboGears2)
  * python-paste-script (this one has other dependents in Fedora but none in
EPEL7.  Please speak up or revive this later if you're interested)
 
 
 These have now been retired.  If someone is interested in them, feel free to 
 revive.
 
 -Toshio
 [wargaming.net]
 EgzO3mXGcK
 This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or 
 PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient 
 and, therefore, may not be retransmitted to any party outside of the 
 recipient's organization without the prior written consent of the sender. If 
 you have received this e-mail in error please notify the sender immediately 
 by telephone or reply e-mail and destroy the original message without making 
 a copy. Wargaming.net accepts no liability for any losses or damages 
 resulting from infected e-mail transmissions and viruses in e-mail 
 attachment. kgzO3mXGcg
 ___
 epel-devel mailing list
 epel-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/epel-devel


pgpe7ewpeSsvv.pgp
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: Schedule for Thursday's FPC Meeting (2014-07-10 16:00 UTC)

[Toshio Kuratomi]

On Wed, Jul 9, 2014 at 12:31 PM, James Antill ja...@fedoraproject.org wrote:
  Following is the list of topics that will be discussed in the FPC
 meeting Thursday at 2014-07-10 16:00 UTC in #fedora-meeting-1 on
 irc.freenode.net.


  For more complete details, please visit each individual ticket.  The
 report of the agenda items can be found at:

 https://fedorahosted.org/fpc/report/12


  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/fpc,
 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.

There were a couple other tickets that are needed for Fedora Changes
so we'll discuss those first thing:

Per-product Config:
https://fedorahosted.org/fpc/ticket/446

New java Packaging Guidelines (AFAIK, just making javadocs optional):
https://fedorahosted.org/fpc/ticket/445


There were some updated to the mimeinfo scriptlets that we passed last
week as well.  So we could take a look at that while it's still fresh
in our minds:
https://fedorahosted.org/fpc/ticket/440

-Toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: EPEL Orphan or retire the TurboGears (v1) stack in 7

[Toshio Kuratomi]

On Mon, Jun 16, 2014 at 12:01:26PM -0700, Toshio Kuratomi wrote:
 
 If someone steps up to say they'll take ownership of TurboGears1 (one of the
 comaintainers or someone new), then I'll reassign these packages to them.
 If no one does, then I'll retire them in epel7 and ask that the packages be
 removed from the download repos before epel7 leaves beta.  Someone can
 revive them later if they're interested.
 
 
 == Packages to be orphaned retired ==
 * python-cherrypy2
 * python-elixir
 * python-peak-rules
 * python-turbocheetah
 * bodhi
 * python-tgcaptcha2
 * python-turboflot
 * python-turbokid (need to remove a spurious dep on this from TurboGears2)
 * python-turbojson (need to remove a spurious dep on this from TurboGears2)
 * python-paste-script (this one has other dependents in Fedora but none in
   EPEL7.  Please speak up or revive this later if you're interested)


These have now been retired.  If someone is interested in them, feel free to
revive.

-Toshio


pgpfjE71f6utj.pgp
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [Env and Stack WG] cancelled meeting

[Toshio Kuratomi]

On Fri, Jun 20, 2014 at 03:38:32PM +0200, Marcela Mašláňová wrote:
 On 06/16/2014 06:40 PM, Toshio Kuratomi wrote:
 On Mon, Jun 16, 2014 at 05:52:18PM +0200, Marcela Mašláňová wrote:
 Meetings will be cancelled until we have some topics to discuss. If
 you have something, please let us know on mailing list:
 env-and-sta...@lists.fedoraproject.org
 
 On item for a meeting agenda would be finding replacement members for the
 two open seats.
 
 -Toshio
 
 
 
 That's great for agenda, but I don't see any want to be members. I
 guess docker people should also join Env and Stack WG. Any takers?
 
 Let's meet next week, see progress of features and discuss open seats.
 
Probably should publish that there's two open seats to the devel list and ask
for candidates to step forward.

-Toshio


pgpuoV9ijOLRj.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

EPEL Orphan or retire the TurboGears (v1) stack in 7

[Toshio Kuratomi]

Since RHEL7 has been released, EPEL7 won't be far behind.  Before we get
there, I'm planning to retire the TurboGears (v1, not Turbogears2) stack in
epel7.  In Fedora Infrastructure we are planning to migrate away from
TurboGears1 rather than continue maintaining it throughout EPEL7's lifetime.

If someone steps up to say they'll take ownership of TurboGears1 (one of the
comaintainers or someone new), then I'll reassign these packages to them.
If no one does, then I'll retire them in epel7 and ask that the packages be
removed from the download repos before epel7 leaves beta.  Someone can
revive them later if they're interested.

Let me know soon -- I'm planning to retire the packages no one says they're
interested in maintaining at the end of this week so that they don't
accidentally sneak into EPEL7 with no active maintainance.

== Packages to be orphaned retired ==
* python-cherrypy2
* python-elixir
* python-peak-rules
* python-turbocheetah
* bodhi
* python-tgcaptcha2
* python-turboflot
* python-turbokid (need to remove a spurious dep on this from TurboGears2)
* python-turbojson (need to remove a spurious dep on this from TurboGears2)
* python-paste-script (this one has other dependents in Fedora but none in
  EPEL7.  Please speak up or revive this later if you're interested)

Full lists of deps found (you don't need to read this unless you want to
see what other packages are in the dep tree that won't be touched by this):

== Found TurboGears Deps ==

=== Requires: TG ===
Retire these

bodhi-server-0:0.9.8-2.el7.noarch
python-tgcaptcha2-0:0.2.0-5.el7.noarch
python-turboflot-0:0.7.0-4.el7.noarch

=== BR: TurboGears ===
Retire these (same set as Requires: TG)

bodhi-0:0.9.8-2.el7.src
python-tgcaptcha2-0:0.2.0-5.el7.src
python-turboflot-0:0.7.0-4.el7.src

=== TG Requires ===

 Not needed by anything else 

python-cherrypy2
python-elixir = 0.6.1
python-peak-rules
python-tgmochikit
python-turbocheetah = 1.0
python-turbojson = 1.3

 Maybe not needed by anything else 

# TurboGears2?  :: python-turbokid = 1.0.5
Is this a spurious dep?

# ? :: python-paste-script = 1.7
Nothing requires or BuildRequires this but maybe it's a needed thing for the
paste stack?

 Do not retire these 
# TurboGears2 :: python-tw-forms = 0.9.6
# RHEL :: python-configobj = 4.3.2
# RHEL :: python-dateutil
# RHEL :: python-webtest
# RHEL :: python-nose = 0.9.3 ::
# RHEL :: python-setuptools = 0.6c11
# python-sqlobject, python-tw-forms :: python-formencode = 1.2.1
# TurboGears2 :: python-genshi = 0.4.4
# Needed by repoview, python-turbokid :: python-kid
# Probably an optional dep of SQLAlchemy python-psycopg2
# fedmsg, python-fedora, many others :: python-simplejson = 1.9.1
# mirrorbrain-tools, python-mb :: python-sqlobject = 0.10.1
# TurboGears2, python-tw-forms :: python-toscawidgets = 0.9.6


=== TG BR ===

 Not needed by anything else 
python-cherrypy2
python-elixir
python-peak-rules
python-tgmochikit
python-turbocheetah
python-turbokid = 1.0.5

 Maybe not needed by anything else 
# ? :: python-paste-script
Nothing requires or BR's this but maybe it's a primary portion of hte paste 
stack?

# TurboGears2? :: python-turbojson
Is this a spurious dep?

 Do not retire 
dos2unix
python-configobj
python-dateutil
python-formencode
python-genshi
python-kid
python-nose
python-setuptools
python-simplejson
python-sqlalchemy
python-sqlobject
python-tw-forms
python-webtest
python2-devel
python-toscawidgets

-Toshio


pgpOpiH7HxRaE.pgp
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [Env and Stack WG] cancelled meeting

[Toshio Kuratomi]

On Mon, Jun 16, 2014 at 05:52:18PM +0200, Marcela Mašláňová wrote:
 Meetings will be cancelled until we have some topics to discuss. If
 you have something, please let us know on mailing list:
 env-and-sta...@lists.fedoraproject.org
 
On item for a meeting agenda would be finding replacement members for the
two open seats.

-Toshio


pgp2o8CjQLpBU.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Cross-distro fossology instance?

[Toshio Kuratomi]

On Mon, Jun 16, 2014 at 10:01:09AM +0200, Stanislav Ochotnicky wrote:
 
 I was wondering if anyone was considering cross-distribution fossology[1]
 instance where we could share burden of license review with other
 distros. I know at least Debian does comprehensive license reviews and
 we could possibly deduplicate a lot of review time this way.
 
 Note that I am not talking about doing whole package reviews in
 fossology, just hooking up the license checking part there.
 
 It's likely we'd need to clean up fossology a bit to be universally
 usable for this use case, but it should be doable. Opinions,
 suggestions...all welcome.
 
 [1] http://fossology.org/

Probably should get Fedora Legal's opinion here too.

I'm not sure I'd like the idea of having the work of license review done by
third parties.  I think it might be better to do reporting to fossology.
ie: we do license review and Debian also does license review and we
coordinate by posting our results to fossology.

The reason is that I've seen a lot of missed license problems both in Fedora
packages and in Debian packages.  Coordinating more eyes on the problem
seems like a way to fix this while deduplicating just means we'll all be
sharing the same erroneous assumptions.

-Toshio


pgpTg3DSbxKZ0.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Schedule for Wednesday's FESCo Meeting (2014-06-11)

[Toshio Kuratomi]

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 17: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 '2014-06-11 17:00 UTC'


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

= Followups =

#topic #1221 Product working group activity reports
.fesco 1221
https://fedorahosted.org/fesco/ticket/1221

= New business =

#topic #1311 Disable syscall auditing by default
.fesco 1311
https://fedorahosted.org/fesco/ticket/1311

#topic #1310 Reconsidering rpcbind's exception allowing it to start by default
.fesco 1310
https://fedorahosted.org/fesco/ticket/1310

= 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. 

-Toshio


pgpap7_js4ZBd.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo Meeting (2014-06-11)

[Toshio Kuratomi]

On Wed, Jun 11, 2014 at 11:35:16AM -0400, Josh Boyer wrote:
 On Wed, Jun 11, 2014 at 9:36 AM, Toshio Kuratomi a.bad...@gmail.com wrote:
  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.
 
 Should probably discuss Bill's departure and how you want to handle
 the open seat.
 
I'll make sure this comes up in the meeting and I'll open a ticket if
we don't just select a runner-up from the previous election as per
http://fedoraproject.org/wiki/FESCo_election_policy#Filling_Vacant_Seats

-Toshio


pgp3BRN4CtGOU.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

This Weeks FESCo Meeting: Cancelled

[Toshio Kuratomi]

Sorry for the late notification.  I took a look at making an agenda for this
week and saw that we only have a few tickets to look at and all of them
are pending input from various other people so I'm cancelling the meeting.

That's two week's in a row so plan on having a meeting next week.  We should
hopefully have information back from maintainers on a few tickets and WG
activity reports among others.

-Toshio


pgpxdI3ls89NN.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fwd: Ophaning lcms(1)

[Toshio Kuratomi]

https://apps.fedoraproject.org/packages/lcms/bugs/all lists a CVE.  If
lcms-11 is no longer going to be maintained in Fedora that (and any
other) security flaws won't be addressed.  It's therefore advisable
for them to update to the new version of lcms if feasible.  The
affected packager would likely want to take ownership of lcms-1 and
patch the security issues.

-Toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fwd: Ophaning lcms(1)

[Toshio Kuratomi]

On Mon, Jun 02, 2014 at 10:39:56PM +0200, Nicolas Chauvet wrote:
 python-pillow-2.2.1-4.fc20.src.rpm

This one can be fixed by upgrading to 2.3.0 (or greater.  2.4.0 is current).
2.4.0 is what's in rawhide.  Not sure if that's safe to push back to f20 and
earlier.  (Although I see that there's an insecure use of tempfile CVE that
was ficed in 2.3.1 so maybe it makes sense to update even if there is API
breakage.)

@smani: Do you have more information here?

-Toshio


pgpVtProWXg4E.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging: bin subfolder

[Toshio Kuratomi]

On Thu, May 29, 2014 at 11:56:02PM +0200, Sandro Mani wrote:
 
 binaries and python scripts to the /usr/bin/salome folder. Is this
 acceptable?
I believe a symbolic link should be acceptable. Actually creating a subdir
 would probably have a lot of opposition, but it should be possible to
 reconfigure salome to use %_libexecdir/salome or %_libdir/salome
 Yeah reconfiguring is not an issue, and if the symlink solution is
 accepted I'd be happy. I'd just prefer not to break the install
 hierarchy too much so that various documentation and stuff on the net
 also applies to Fedora as far as possible.
 
nod  Probably %{_libdir}/salome/REAL_FILES  and
%{_bindir}/SYMLINKS_TO_REAL_FILES.  If there is a concern that salome's
files will conflict with other things in %{_bindir} the symlinks probably
need to have a prefix like salome-SYMLINK.

-Toshio


pgpjAguzoXqEg.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Schedule for Wednesday's FESCo Meeting (2014-05-28)

[Toshio Kuratomi]

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 17: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 '2014-05-28 17:00 UTC'


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

= Followups =

#topic #1291 F21 System Wide Change: BerkeleyDB 6 - 
https://fedoraproject.org/wiki/Changes/BerkeleyDB_6
.fesco 1291
https://fedorahosted.org/fesco/ticket/1291

= New business =

= 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. 


-Toshio


pgpNG3h5Bl9FT.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo Meeting (2014-05-28)

[Toshio Kuratomi]

On Wed, May 28, 2014 at 11:06:03AM -0400, Matthew Miller wrote:
 On Wed, May 28, 2014 at 11:05:10AM -0400, Stephen Gallagher wrote:
  This ticket appears to be resolved on Trac. Shall we just cancel the
  meeting this week?
 
 I was trying to think of something inflammatory, but I don't think I have it
 in me today. :) I'm good with canceling.

I don't see any new tickets or any requests to add something to the agenda
so consider this meeting cancelled.  See you all next week.

-Toshio


pgpWSC3tFsKBY.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Schedule for Thursday's FPC Meeting (2014-05-29 16:00 UTC)

[Toshio Kuratomi]

On Wed, May 28, 2014 at 05:30:12PM -0400, James Antill wrote:
  Following is the list of topics that will be discussed in the FPC
 meeting Thursday at 2014-05-29 16:00 UTC in #fedora-meeting-1 on
 irc.freenode.net.
 
  Local time information (via. rktime):
 
 2014-05-29 09:00 Thu US/Pacific PDT
 2014-05-29 12:00 Thu US/Eastern EDT
 2014-05-29 16:00 Thu UTC -
 2014-05-29 17:00 Thu Europe/London  BST
 2014-05-29 18:00 Thu Europe/Paris  CEST
 2014-05-29 18:00 Thu Europe/Berlin CEST
 2014-05-29 21:30 Thu Asia/Calcutta  IST
 --new day--
 2014-05-30 00:00 Fri Asia/Singapore SGT
 2014-05-30 00:00 Fri Asia/Hong_Kong HKT
 2014-05-30 01:00 Fri Asia/Tokyo JST
 2014-05-30 02:00 Fri Australia/Brisbane EST
 
I'm afraid I won't be able to make the meeting tomorrow.  My stepchildren's
father's flight was delayed and I'll have to pick him up at the airport
tomorrow morning.

spot or geppetto, would either of you be able to run the meeting tomorrow?

I can vote in ticket after I get back from the airport.

-Toshio


pgpS9aDTiHfhQ.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Attempting to contact three unresponsive maintainers

[Toshio Kuratomi]

On Thu, May 15, 2014 at 03:57:24PM +0530, Kashyap Chamarthy wrote:
 On Fri, Mar 28, 2014 at 10:11:47AM -0700, Toshio Kuratomi wrote:
  Greetings, we've been told that the email addresses for three package
  maintainers are no longer valid.  I'm starting the unresponsive maintainer
  policy to find out if they are still interested in maintaining their
  packages (and if so, have them update their email addresses in FAS).  If
  they're not interested in maintaining or we can't locate them I'll have
  FESCo orphan the packages so that others can take them over.
  
  If you have a way to contact any of these maintainers, please let them know
  that we'd appreciate knowing what to do with their packages.  Thanks!
  
  Maintainers:
  * awnuk -- former email address aw...@redhat.com
 
 He doesn't work for Red Hat anymore. I CC'ed Ade Lee who leads upstream
 Dogtag work, he might suggest someone who is willing to take up the
 maintenance.
 
Thanks.  do note that the dogtag stuff has a maintainer.  awnuk was just
a comaintainer.

Sometimes when people leave red hat they still want to maintain their Fedora
packages (or a subset thereof).  Other times they want to give them up
because they only maintained them as part of their job.  If we definitely
know that one of these cases apply we can do something appropriate with
package ownership and account info (in the former case, the person needs to
update their email address in the Fedora Account System.  In the latter case
we can remove their acls in the Fedora PackageDB).  In many cases, like this
one, we just know that the packager has left red hat and don't know what
they wish to do.  That leaves us with packages where we suspect that the bug
reports, commit messages, etc are going to someone who isn't actually
working on the packages.  We'd like to know what's happening so that we can
update the acls to reflect who's actually actively working on the packages.

-Toshio


pgpgGMIiT5XCx.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fwd: git commit Undelivered Mail Returned to Sender

[Toshio Kuratomi]

On Thu, May 15, 2014 at 08:35:27PM -0400, Al Dunsmuir wrote:
 On Thursday, May 15, 2014, 12:42:25 AM, Orion Poplawski wrote:
  More fallout from pkgdb2?
 
Yeah.  The script that updates the package email aliases was still pointing
at the staging instance (for testing).  So it wasn't picking up new
packages.  I've changed the script, run it once manually, and it seems to
have created the octave-io-owner email alias as expected.

 I  just  send  an  email to this list about weird problems I have been
 experiencing  with  the  ppc  mailing  list. When I tried to log on to
 check  my  options, I got a 502 proxy error about a DNS lookup failure
 for collab03.fedoraproject.org.
 
I think that's unrelated.

-Toshio


pgpIZMte1XxCP.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Building a non functional package just to remove dependency mess

[Toshio Kuratomi]

On Wed, May 14, 2014 at 01:08:51PM +0200, Miro Hrončok wrote:
 Hi,
 
 perl-Language-Expr FTBFS in rawhide and F20 (since F20 was rawhide).
 There is some crazy stuff in Perl itself that prevents
 perl-Regexp-Grammars to work properly and perl-Language-Expr cannot work
 without proper perl-Regexp-Grammars.
 
 This leads to perl-Language-Expr in F20 being from F19 and having
 unresolved dependencies on perl(:MODULE_COMPAT_5.16.2).
 
  * It makes mess when updating F19 to F20
  * It emails me on daily basic
  * I cannot fix it
 
 However, new version of upstream Language::Expr is out, that disables
 tests, while still not being functional. I would like to update
 perl-Language-Expr in F20 and rawhide. That would lead to:
 
  * No more mess
  * No more email for me
  * Nonfunctional package in Fedora
 
 While I believe that nonfunctional package is a bad think, I believe
 that anything is better than the situation now.
 
 Any thoughts?
 
It sounds like this would just hide the issues from you.  If it's
nonfunctional, why not retire perl-Language-Expr instead?

-Toshio

 Links:
 
 https://bugzilla.redhat.com/show_bug.cgi?id=992666
 perl-Language-Expr: FTBFS in rawhide
 
 https://bugzilla.redhat.com/show_bug.cgi?id=997835
 perl-Language-Expr-0.23 is available
 
 https://bugzilla.redhat.com/show_bug.cgi?id=1009919
 perl-5.18: Regexp::Grammars does not work due to bug in perl
 


pgpFVTXLSBxMo.pgp
Description: PGP signature
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: [Fedora-packaging] Building a non functional package just to remove dependency mess

[Toshio Kuratomi]

On Wed, May 14, 2014 at 05:43:14PM +0200, Miro Hrončok wrote:
 Dne 14.5.2014 16:38, Toshio Kuratomi napsal(a):
  It sounds like this would just hide the issues from you.  If it's
  nonfunctional, why not retire perl-Language-Expr instead?
 
 1) Retiring the package would not solve the F19 to F20 update issue
 2) The bug in Perl is supposed to be fixed in near future, however I'm
 not quite sure when
 
But you say it's been non-functional in Fedora 20 since before release?
If you think it'll be fixed soon, maybe a half measure would be to have the
perl package Obsolete perl-Language-Expr to get it off the user's systems
but don't retire it yet.  If you don't think that it will be fixed soon (for
instance, there's no commitment by anyone that they are working on the
issue) then it's likely you do want to retire the package on rawhide in
addition to throwing in the Obsoletes.  The package is just a re-review away
from being brought back when the problems are fixed.

We really don't want to be shipping packages that are irretrievably broken
to users.  And shipping another package that has no purpose to hide the fact
that the first package is broken to the package maintainer just doesn't seem
right.  Really the system is emailing you because as package maintainer
you're supposed to fix the software.  If you can't then we likely don't want
the software in Fedora until the issue can be resolved.  :-(

-Toshio


pgpbfC9QyEynU.pgp
Description: PGP signature
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Incorrect order of /usr/bin and /usr/sbin in path

[Toshio Kuratomi]

On Mon, May 05, 2014 at 10:38:10PM +0200, Kalev Lember wrote:
 On 05/05/2014 10:28 PM, Matthew Miller wrote:
  On Mon, May 05, 2014 at 04:24:03PM -0400, Matthias Clasen wrote:
  It causes pointless configure and Makefile complications in every single
  upstream project that wants to install something into that location and
  has to differentiate between Fedora (/usr/libexec) and the rest of the
  world (/usr/lib/$pkg). It has ripple-on effects throughout the project -
  e.g. having to patch the right prefix into desktop files, into service
  files, etc etc.
  
Note that when I first read this, I assumed you meant %{_libexecdir} and
%{_libdir}/$pkg which would be untrue.  After reading kalev's message, I'm
guessing that you mean %{_libexecdir} and %{_prefix}/lib/$pkg.  This could
also be stated as %{_libdir}/$pkg vs %{_prefix}/lib/$pkg... %{_libexecdir}
and %{_libdir}/$pkg are both valid in the packaging guidelines.

  Now that's a practical reason that I can get behind. But given that we're
  already here and have done all that, is it valuable to undo? Again, I shrug
  -- plenty of other stuff to fix, but I think a case could certainly be made.
 
 I don't think it's valuable to undo it at this point, but rather let
 applications install into /usr/lib/$pkg/ if they want to. Right now, the
 Fedora guidelines downright forbid that.
 
 I'll emphasize that I really mean /usr/lib/$pkg/, as opposed to
 /usr/$multilib_directory/$pkg/ -- this ensures that the same directory
 is available in all distros the same way, and avoids multilib issues
 with helper binaries.
 
 Right now, various upstreams have to ship checks like:
 
 if (fedora_based_distro)
   helper_dir = /usr/libexec
 else
   helper_dir = /usr/lib
 

If upstream is using the autotools you should just use @pkglibexecdir@ or
@libexecdir@.  Linux distributions, BSDs and etc all set --libexecdir to
the proper location for their tastes.

If upstream does not use autotools then they may end up having to do
a platform check for helper_dir.  But they could also end up having to do
a platform check for shared libraries or arch-specific data files. The
difference between Fedora and other distros is really multilib, not libexec.

 Relaxing the guidelines would allow those upstreams to write saner code,
 and be more compatible across various distributions.

If we get rid of multilib then that would be fine otherwise it'll be more
error prone to add %{_prefix}/lib into the mix with  %{_libexecdir} and
%{_libdir}.  Most upstreams do not know about or care about multilib.  This
means that they mix stuff appropriate for %{_prefix}/lib/$pkg in with things
that must go in %{_libdir}/$pkg.  As long as we have multilib we need to
check the usage of these directories and patch in the separation between the
directories when needed.  The usage of %{_libdir}/$pkg and %{_libexecdir}
just makes this more apparent.

We've already gotten rid of multilib distinctions for specific ecosystems
within Fedora so they don't have to make checks like this.  We could either
expand that to encompass additional specific ecosystems or we could get rid
of multilib altogether.

-Toshio


pgpJ1pDGlvtN4.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

EPEL RFC: Strategy for python3 versions

[Toshio Kuratomi]

Hi guys,

Orion has submitted a python34 package for EPEL and I'm going to review them
soon if no one beats me to it.  In parallel with getting that approved I'd
like to ask about the general strategy we'd like to take with maintaining
python3 in EPEL.

Python3 is an evolving language.  New 3.N releases bring new features,
bugfixes, and both backwards compatibility breaking and backwards
compatibility enhancing changes (For instance, 3.3 brought the ability to
mark regular text strings with the u prefix to match with python2.x.  3.5
will bring back formatting methods for byte strings.)

Currently, there are a good many python libraries that work with both
python2 and python3 but few libraries and few applications that are
python3-only.

Upstream, python3 releases generally see 18 months of bugfix updates and
5 years of security fixes[1]_.

As Orion has pointed out, it would be hard for us to maintain a python3
release past upstream's EOL date as there's a lot of code in a python3
package (Not to mention the stack of packages that we'll build on top of
it.)

In addition, I am a little worried about the amount of time we may end up
having to devote to keeping multiple python3.N packages (and stacks of
packages for them) alive if we only retire old python3 releases when
upstream ceases to provide support for them (back of the envelope
calculations are that if we don't skip any python3.N releases, we'd be
attempting to maintain 4-5 python3 releases before the first of those EOL's
upstream).

I'd like to propose that we attempt to maintain 2 python3 releases at any
one time.  We'll create python3.4 now.  When python3.5 comes out in 18
months (less since python3.4 has been out for several months), we'll
package that in addition.  When python3.6 comes out (3 years), we'll package
that and retire python3.4.

Pluses:
* This gives users some time to verify that their homegrown applications
  continue to work with the newer python3 package that we produce before the
  old one goes EOL.
* This means that we're only working on 3 versions of python3 at a time (the
  two we expect users to use and the next version that we're tracking as
  upstream works on finishing it).
* This gives us a chance to update frameworks, libraries, and other stacks
  of software built on top of python3 at the same time as we create the new
  interpreter package.  So you could get python3.4 with Django-1.6.x  and
  you could get python3.5 with Django-1.8.x

Negatives:
* Users will have to reverify and port apps written against python3 to the
  new interpreter version sometime in the 3 year lifespan of the python3
  package they originally wrote it against.
* Package maintainers who are creating packages that run on python3 will
  need to submit new packages for python3.4, python3.5, etc.
* Users may have to port to both new versions of python3 and to new versions
  of some libraries they depend on (because we took the opportunity to
  update those libraries for the new python3 interpreter stack).

Precedents:
* With mediawiki, we now ship versioned packages and retire the old versions
  when upstream stops shipping updates.  The stacks of packages built on top
  of mediawiki have to be produced for each mediawiki version.

Alternatives:
* Never retire the python3 packages.  This leaves us trying to support the
  release once upstream stops support.  Since new python3 releases are in
  demand, we'd probably end up trying to maintain all of the python3
  releases that came out between when RHEL-N was released and when
  RHEL-N+1 releases (because maintainer focus usually shifts to building
  packages for RHEL-N+1 then).
* Retire the python3 packages when upstream stops support.  This defers the
  pain for users (They can use a python3.N version for about 5 years instead
  of about 3 years).  However, it means that we're maintaining 4-5 versions
  of python3 at a time instead of 2-3 

What do people think?  Is this something we can do within the policies of
EPEL?  Does it make sense to go forward with this?  Is it better to go with
one of the alternatives?

.. [1]_: Previous versions of python3 have a lifespan defined in their PEP.  For
  instance, this one for python3.3:
  http://legacy.python.org/dev/peps/pep-0398/#lifespan

  The lifespan for the previous versions are the same:
  * bugfix updates for python3.N approximately every 4-6 months for
approximately 18 months.
  * After the release of python3.N+1, a final bugfix of python3.N is released.
  * After that, security updates (source only) will be released until 5 years
after the initial release of 3.N.

  3.4 doesn't have this lifespan section but that's probably an oversight (I
  can ask Larry Hastings to clarify that if need be).

-Toshio


pgpD0KdHyh6Gn.pgp
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3.4 for 7

[Toshio Kuratomi]

On Mon, Apr 28, 2014 at 01:45:52PM -0400, Aaron Knister wrote:
 I think it's a little unrealistic to expect the vendor to namespace their
 packages although it would be nice and probably the right thing to do.

If you buy from Red Hat, you should complain to them.  That might have more
effect than I have had.

 Could
 EPEL, as the 3rd-party layered product,  namespace theirs? (e.g.
 epel-python34). It's more consistent with how other packages store version
 numbers in the name

Unfortunately, this wouldn't be very consistent with the packages as
a whole.  If you have a bug in the python3 package that's in
/usr/bin/python3.4, for instance, you're going to go to bugzilla looking to
file against the python34 package, not epel-python34.  And we'd be doing
this for packages that we don't even build against or assume that people
have.  We also have no control over what packages Red Hat will choose to
scl-ize.  In the future, they could create mediawiki119 scls or Turbogears2
scls.  So we really need Red Hat to stick to convention and not pollute the
toplevel package 


 (although as an aside, the smushing together of version
 numbers without dots drives me a little crazy so part of me likes the dot in
 python3.4).


I also like the dot in the version number in the name.  However, although
that solves the problem of conflicting package names for a computer, it
doesn't solve the problem for humans.  (Why do I have both python3.4 and
python34 packages installed?  I should be able to get rid of one of those.)
It's also not a requirement of scls that they do not contain any dots in the
scl name.  Future Red Hat supplied scls may put a dot into the name and thus
we'll still have conflicts.

-Toshio


pgpcMQ4X13EdP.pgp
Description: PGP signature
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3.4 for 7

[Toshio Kuratomi]

On Sat, Apr 26, 2014 at 09:13:12PM -0600, Orion Poplawski wrote:
 On 04/26/2014 06:55 PM, Toshio Kuratomi wrote:
  
  On Apr 26, 2014 11:37 AM, Orion Poplawski or...@cora.nwra.com
  mailto:or...@cora.nwra.com wrote:
  
  One interesting change from RHEL7 beta-rc is the dropping of libdb4
  which python3 currently BRs, although I cannot see any evidence in
 
  http://kojipkgs.fedoraproject.org//packages/python3/3.4.0/2.fc21/data/logs/x86_64/build.log
  of python3 actually using it (it seems to be using gdbm instead).
 
  Python 3 does use libdb although I think it can use libdb5.  Python has
  a standard library that includes both libdb bindings and gdbm bindings.
 
 Hmm, I see no evidence that it makes use of both as currently built.  It
 seems that gdbm is preferred and there are no dependencies on libdb*.
 
On further investigation, I see that you are absolutely right.  The bsddb
module was removed from python3.0 so we can remove the BuildRequires on db
for any python3 packages.

See the disclaimer at the top of the python2 docs:
https://docs.python.org/2/library/bsddb.html

and the PEP:
http://legacy.python.org/dev/peps/pep-3108/#maintenance-burden

-Toshio


pgpILUvRXfVH6.pgp
Description: PGP signature
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Toshio Kuratomi]

On Apr 28, 2014 5:01 PM, Daniel J Walsh dwa...@redhat.com wrote:

 The problem  is lots of services require systemd because they ship a
 unit file and want systemctl reload to happen.

Would removing the requires on systemd and doing:

/usr/bin/systemctl reload ||:

Work for these cases?

-Toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: EPEL Python 3.4 for 7

[Toshio Kuratomi]

On Apr 27, 2014 9:37 AM, Aaron Knister aaron.knis...@gmail.com wrote:


 On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi a.bad...@gmail.com wrote:


 On Apr 26, 2014 8:27 PM, Aaron Knister aaron.knis...@gmail.com wrote:
 
  We use both EPEL and SCL in my org. I didn't see this addressed in the
email chain but I'm concerned about what'll happen if/when SCL includes
python34. There are technical means to work around this but it
fundamentally makes EPEL and SCL incompatible. I don't believe SCL is
considered a layered product but maybe I'm wrong :)

 If red hat does the right thing and namespaces their scl packages then
there shouldn't be any conflicts.  Scls are intended to be isolated from
system packages while epel packages are intended to integrate into the
system.

 -Toshio

 The contents are namespaced but the package names are not. We'll end up
with a package called python34 in each repo that are incompatible.

Exactly.  That's why red hat has to do the right thing.

-Toshio
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: F21 System Wide Change: SCL

[Toshio Kuratomi]

On Thu, Apr 17, 2014 at 04:35:25PM +0200, Miloslav Trmač wrote:
 2014-04-14 14:13 GMT+02:00 Jaroslav Reznik jrez...@redhat.com:
 
 2. Upload packages into git - specific branch based on Fedora version and
 name
 of collection. For stable repo we must be able to replicate builds from 
 git
 repo, which Fedora own.
 
 
 I'm confused; what precisely is the layout you are proposing for pkgs git?  I
 read this as ruby.git/{f20,f21,f21-$sclname}; is that really the proposal?

I'm not sure what the proposal is but the FPC wants to have all scls live in
a separate package than the mainstream package.  Like this:

ruby.git/{f20,f21}
fdr-ruby1.9.3-ruby.git/{f20,f21}

This matches with what mingw does and after working on creating an SCL, it
seems to be a better plan to keep the two sources separate as scl spec files
are much different than mainstream specs.

-Toshio


pgp1QXELqWbXO.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Thursday's FPC Meeting (2014-04-17 16:00 UTC)

[Toshio Kuratomi]

I won't be present again this week (or next) but I did vote on a few
tickets.  Hopefully that will help with meeting, discussing, and voting.

-Toshio


pgpKd0BmNZ4y9.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Python 3 and mod_wsgi

[Toshio Kuratomi]

On Mon, Apr 14, 2014 at 04:54:33PM -0400, Bohuslav Kabrda wrote:
 ━━━
 
 I naively ported my Django app to Python 3 and didn't realize WSGI was
 going to be an issue.  I saw python3-django was available for Fedora 20 
 and
 thought I was all set until I saw in my httpd logs that python2.7 seems to
 be the assumed default for mod_wsgi.  After reading the README and more, I
 see the writing on the wall:
 
 
 If you have multiple versions of Python installed and you are not using
 that which is the default, you may have to organise that the PATH 
 inherited
 by the Apache application when run will result in Apache finding the
 alternate version. Alternatively, the WSGIPythonHome directive should
 be used to specify the exact location of the Python installation
 corresponding to the version of Python compiled against. If this is not
 done, the version of Python running within Apache may attempt to use the
 Python modules from the wrong version of Python.
 
 
 I take this to mean that merely fiddling with WSGIPythonHome alone will be
 insufficient and that I would need to recompile the package.  Is that
 correct, or did I miss a Python3-specific mod_wsgi package or some other
 neater solution?  If I am truly forced to recompile -- as reversing the
 Python 3 is really undesirable at this point -- is there any reason Fedora
 couldn't have two mod_wsgi packages (one for Python2 and another for
 Python3)?
 
 AFAIK you can't have 2 mod_wsgi's, each one compiled against a different 
 Python
 major.minor, loaded by Apache at the same time for various reasons. So the 
 best
 solution would IMO be to create python3-mod_wsgi (subpackage of mod_wsgi), 
 that
 would conflict with mod_wsgi. It should be perfectly doable and it shouldn't
 break anything.
 CCing Matthias, the owner of mod_wsgi in Fedora - Matthias, what do you think?
 

It's available in rawhide already and uses the conflicts that you outline:
http://koji.fedoraproject.org/koji/buildinfo?buildID=493296
https://bugzilla.redhat.com/show_bug.cgi?id=1007002

However, conflicts aren't the correct strategy here.

Instead, take a look at how the python26-mod_wsgi package is implemented for
epel5.  The two mod_wsgi packages should be parallel installable.  But the
apache config files should prevent both from being loaded into a single
apache process.  Here's the config file for the python26-mod_wsgi package
as a example of this:

  # NOTE: By default python26-mod_python with not load if mod_wsgi is
  # installed and enabled.  Only load if mod_python and mod_wsgi are not
  # already loaded.

  IfModule !wsgi_module
LoadModule wsgi_module modules/python26-mod_wsgi.so
  /IfModule

We should probably have a similar guard in the mod_wsgi config file as well.
Then be sure that we consciously name the conf files so that we are
promoting one of these as the default (because sort order will load one of
them before the other) if both packages are installed.

Having both packages be parallel installable makes it easier for people
who are willing to configure apache to start two separate instances of
apache.  The two instances could each run a different version of mod_wsgi by
adding the correct mod_wsgi config for each.

Bug filed:
https://bugzilla.redhat.com/show_bug.cgi?id=1087943

-Toshio


pgp04t4ERgkAq.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Agenda for Env-and-Stacks WG meeting (2014-04-08)

[Toshio Kuratomi]

On Apr 7, 2014 10:28 AM, Marcela Mašláňová mmasl...@redhat.com wrote:

 WG meeting will be at 16:00 UTC, 17:00 Central Europe, 12:00 (noon)
Boston, 9:00 San Francisco, 1:00 Tokyo in #fedora-meeting on Freenode.

 == Topic ==
 I sent three Change proposals. If you have any comments, please share
them.
 * https://fedoraproject.org/wiki/Changes/SCL
 * https://fedoraproject.org/wiki/Changes/Playground_repository
 * https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL

not sure that the ruby scl should have its own change.  It needs to have
the equivalent filed for the fpc to evaluate, though.
https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Approval_Process

Since the guidelines aren't final, probably open an fpc ticket so the fpc
sees the request and more that it's needed for the fedora scl change.
Although the scl package guidelines aren't final, the guidelines/criteria
for approving the scl itself were approved so fpc should be able to
evaluate it in parallel to finishing the packaging guidelines.

If we remove the ruby scl change we should add more to the main scl change,
though, about expectations around the scl approval.  For instance, we
probably want to touch base with docs/marketing to see if they want to
publicize scls in the exact same way as fedora changes or have a slightly
different procedure.

Also note, in case no one saw it in either fpc or fesco meeting notes, I'm
traveling to a week and a half conference now followed by a week and a half
of vacation.so I likely won't be around for any fedora meetings until april
27th (and playing catch up with my email for that first week.)

-Toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Agenda for Env-and-Stacks WG meeting (2014-04-08)

[Toshio Kuratomi]

On Tue, Apr 08, 2014 at 04:16:58PM +0200, Marcela Mašláňová wrote:
 On 04/08/2014 03:02 PM, Toshio Kuratomi wrote:
 
 not sure that the ruby scl should have its own change.  It needs to have
 the equivalent filed for the fpc to evaluate, though.
 https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Approval_Process
 
 Since the guidelines aren't final, probably open an fpc ticket so the
 fpc sees the request and more that it's needed for the fedora scl
 change.  Although the scl package guidelines aren't final, the
 guidelines/criteria for approving the scl itself were approved so fpc
 should be able to evaluate it in parallel to finishing the packaging
 guidelines.
 
 If we remove the ruby scl change we should add more to the main scl
 change, though, about expectations around the scl approval.  For
 instance, we probably want to touch base with docs/marketing to see if
 they want to publicize scls in the exact same way as fedora changes or
 have a slightly different procedure.
 
 Also note, in case no one saw it in either fpc or fesco meeting notes,
 I'm traveling to a week and a half conference now followed by a week and
 a half of vacation.so I likely won't be around for any fedora meetings
 until april 27th (and playing catch up with my email for that first week.)
 
 -Toshio
 
 
 
 I'm trying to provide feature needed by Cloud WG, that's all. I can
 file a new ticket on FPC, but wouldn't it just duplicate
 communication about General SCL guidelines?
 Ruby193 could test workflow around SCL in Fedora, that's another good
 reason to try how far can I get it and what won't work :)
 
 I would prefer to keep my changes as is and let FESCo decide.
 
I sense a miscommunication here -- the Draft Guidelines for approving an SCL
say that you need to get the FPC to approve new SCLs:

https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29#SCL_Approval_Process

I felt that a new FPC ticket would be good because this is the first SCL to
be approved and the FPC likely won't become aware of it unless it's called
out in a ticket.

-Toshio


pgpgC8BnX1shb.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Agenda for Env-and-Stacks WG meeting (2014-04-08)

[Toshio Kuratomi]

On Tue, Apr 08, 2014 at 01:26:23PM -0400, Matthew Miller wrote:
 On Tue, Apr 08, 2014 at 06:02:02AM -0700, Toshio Kuratomi wrote:
  not sure that the ruby scl should have its own change.  It needs to have
 
 FWIW, I'm happy to have a distinct change because I want to call this out in
 the marketing.
 
Note -- I called out the need to talk to the docs and marketing team in my
email because I think that we'll probably want to publicize all SCLs so the
SCL approval process should probably also get something into the docs and
marketing queue.  A separate Fedora Change might be extraneous in this
regard -- I'm thinking that fesco probably doesn't need to re-approve
an SCL  that FPC has already approved.

OTOH, how does the Cloud SIG want to use the SCL?  If they want to create
things that are outside of the SCL that make use of it, that would seem to
be a point of coordination and thus would be Fedora Change worthy... On yet
another hand, though, having something not in an SCL depend on something
that's in an scl was something that I was told we (FPC) shouldn't put into
the first draft of the guidelines.  Instead things that require SCLs must be
placed inside of an SCL.

I guess -- there needs to be a bit more information about what is desired
here to know whether that would require a rethink of some of the
foundational goals that were given to me.

-Toshio


pgpk0MH6aPNBK.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Schedule for Thursday's FPC Meeting (2014-04-03 16:00 UTC) (post DST change UTC time)

[Toshio Kuratomi]

On Wed, Apr 02, 2014 at 04:20:16PM -0400, James Antill wrote:
 
 (too big to fail vote?)
 #topic #391 Exception for bundled libraries in icecat
 .fpc 391
 https://fedorahosted.org/fpc/ticket/391
 

Yep, there's four separate new exception criteria posted on:
https://fedoraproject.org/wiki/User:Toshio/Bundling_relaxation

that we can cote for.

 
 #topic #411   proposal: migrate license files to %license instead of %doc
 .fpc 411
 https://fedorahosted.org/fpc/ticket/411
 
 #topic #412   Please change the packaging guidelines to include
 packaging policy regarding systemd timer units
 .fpc 412
 https://fedorahosted.org/fpc/ticket/412
 
These two are part of Fedora Changes/fedora.next so we'll probably move them
up in the schedule.

-Toshio


pgpRd1Tmx7Ltd.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Meeting minutes from Env-and-Stacks WG meeting (2014-04-01)

[Toshio Kuratomi]

On Tue, Apr 1, 2014 at 6:39 AM, Marcela Mašláňová mmasl...@redhat.com wrote:

 * Open Questions - Playground: Signing  (mmaslano, 12:04:12)

I saw that this got voted on in the meeting even though it didn't get
recorded as such for the meeting minutes.  The proposal seemed to be:
use obs-sign to sign packages.  That's not actually a proposal that we
can approve here.  The proposal here should probably be: is signing
of packages a blocker for making the playground repo, nice to have, or
optional?

In terms of how to get the packages signed, that's something that the
infrastructure team has to decide.  IIRC past conversations correctly,
adding another signing server (meaning a different code base) to
infrastructure is at the bottom of their list of ways to sign packages
in copr (and by extension in the playground repo).

When I saw the vote in the meeting logs I mentioned it to nirik.  In
turn he told me that he hadn't heard anything about this and had only
glanced briefly at obs-sign (mentioning that it wasn't even packaged
for Fedora yet).  As I related to tjanez on IRC today, I think lack of
packaging probably slows down infra's ability to deploy it but is only
a foottnote to the real problems.  Compromising signing servers and
gaining access to the private keys on them is a very high value target
for an attacker.  The more signing servers we have the greater the
attack surface infrastructure has to protect.  probably in the ideal
scenario infra would run a single signing server and everything
needing signing would be sent to that.  (Jesse Kating had that use in
mind when he designed sigul but I don't know if that design goal
actually became part of the software that we are currently running).
A step down from there might be running multiple instances of the same
signing software to handle the various needs as infra would then have
to protect the keys on these multiple hosts.  At the bottom of the
list is running separate signing software as that places the
additional burden of auditing and protecting the software stack of the
multiple signing servers.

For whoever is going to approach infra about signing the packages in
copr it probably makes more sense to either talk about enhancing sigul
to work with copr or getting obs-sign to be able to sign packages from
koji.  We'd probably also want to ask bressers or someone else from
the security team to do some sort of evaluation of the code bases that
we're looking at.

-Toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: lbzip2 as default bzip2 implementation

[Toshio Kuratomi]

On Wed, Apr 02, 2014 at 08:47:11PM -0500, Chris Adams wrote:
 
 I think the right way to move forward is to make a library that is at
 least API-compatible with the current libbz2.so.1, make all the tools
 use it, and just replace bzip2 with lbzip2.

Although I'm still on the fence about whether I'd vote for the Change as is,
I tend to agree with this sentiment.

Having two sets of code with different characteristics seems like
isomething of a disservice to users (I started bzip'ing my logs and backups
because the performance was suitable for my task when I tested with
/usr/bin/bzip2 but then when I operated on those logs with a custom python
script it was 3x slower!)

From past precedent I agree that getting the new package to the point where
we think it's a suitable replacement and then just making the switch for the
next release makes the most sense.

-Toshio


pgp1_BNd0eyBq.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: lbzip2 as default bzip2 implementation

[Toshio Kuratomi]

On Thu, Apr 03, 2014 at 04:48:03AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
 On Wed, Apr 02, 2014 at 07:26:59PM -0700, Toshio Kuratomi wrote:
  On Wed, Apr 02, 2014 at 08:47:11PM -0500, Chris Adams wrote:
   
   I think the right way to move forward is to make a library that is at
   least API-compatible with the current libbz2.so.1, make all the tools
   use it, and just replace bzip2 with lbzip2.
  
  Although I'm still on the fence about whether I'd vote for the Change as is,
  I tend to agree with this sentiment.
  
  Having two sets of code with different characteristics seems like
  isomething of a disservice to users (I started bzip'ing my logs and backups
  because the performance was suitable for my task when I tested with
  /usr/bin/bzip2 but then when I operated on those logs with a custom python
  script it was 3x slower!)
  
  From past precedent I agree that getting the new package to the point where
  we think it's a suitable replacement and then just making the switch for the
  next release makes the most sense.
 I agree that this is desirable. OTOH, lbzip2.rpm is 90k, so I guess we can
 suffer the extra disk usage :)
 
If it was about disk usage :-)

But it's not.  It's about having two codebases that do the same thing in
different ways.

-Toshio


pgp5MTiU5Fmrw.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Attempting to contact three unresponsive maintainers

[Toshio Kuratomi]

Greetings, we've been told that the email addresses for three package
maintainers are no longer valid.  I'm starting the unresponsive maintainer
policy to find out if they are still interested in maintaining their
packages (and if so, have them update their email addresses in FAS).  If
they're not interested in maintaining or we can't locate them I'll have
FESCo orphan the packages so that others can take them over.

If you have a way to contact any of these maintainers, please let them know
that we'd appreciate knowing what to do with their packages.  Thanks!

Maintainers:
* awnuk -- former email address aw...@redhat.com
  - comaintainer of dogtag-pki, dogtag-pki-theme, pki-console, pki-core,
pki-ra, and pki-tps
* llim -- Lawrence Lim -- former email address l...@redhat.com
  - Bugzilla owner of redhat-lsb
* osier -- Osier Yang -- former email address jy...@redhat.com
  - comaintainer of libvirt

If we get to the point of removing acls for these people, only redhat-lsb
will need a new owner.  The other packages just have these package
maintainers as comaintianers.

-Toshio


pgpMjXb1h8e6a.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Thursday's FPC Meeting (2014-03-27 17:00 UTC) (next week back to 16:00 UTC)

[Toshio Kuratomi]

On Wed, Mar 26, 2014 at 09:45:14PM +0100, Miloslav Trmač wrote:
 2014-03-26 20:51 GMT+01:00 James Antill ja...@fedoraproject.org:
  (approval and retirement sections already passed, /opt exception passed)
  #topic #339 software collections in Fedora
  .fpc 339
  https://fedorahosted.org/fpc/ticket/339
 
 I can't help seeing this on the agenda for a long time (the ticket has
 been opened 7 months ago), including 3 months with no activity in the
 ticket, and now 2 months since last activity in the ticket.  Mailing
 list discussions also vary between vigorous in some months and
 essentially zero in other months.
 
 Is there some work going on elsewhere that I'm missing?  If not, what
 are the constraints that prevent quicker decision making?
 Mirek

There have been many problems in the past which I think I've gone into
elsewhere.

Current things that are being worked on:

I have one set of scls built:
http://copr-fe.cloud.fedoraproject.org/coprs/toshio/SCL-Test-Python2.4/

Have to push the lessons from that into the guideline draft and also have to
update it with some more discussion that happened between Jan and myself
(after testing that those proposals will work).

Current build of scl-utils with patches I've found necessary applied:
http://copr-fe.cloud.fedoraproject.org/coprs/toshio/SCL-Test-scl-utils/

The filesystem paths patch from that is a blocker but seems to be stalled:
https://bugzilla.redhat.com/show_bug.cgi?id=105

The byte compile patch I have to work on incorporating some feedback from
Jan before trying to push it upstream.

I also need to build something that makes use of statefiles and conf files.
to test this out.  mariadb or a postgresql package are good candidates.
hhorak had mentioned testing this simply by changing the paths in a package
(rather than changing scl-utils) and the general strategy works.

That's pretty much where we're at.

-Toshio


pgpIZXS70xlFa.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Let's close the remaining merge reviews

[Toshio Kuratomi]

On Mon, Mar 24, 2014 at 04:41:29PM -0400, Cole Robinson wrote:
 
 An alternative would be to reassign every open merge review to the component
 in question, and let maintainers handle it as they like.
 
 Thoughts?
 
Alternative idea -- maybe identify all packages which are not ciritcal and
have an open merge review.  Take those packages out of the repository.

Then revisit the list and formulate a plan on what to do with thoes (even if
the plan is then, these were critical enough to leave in so we'll give them
a pass on going through a formal review).

-Toshio


pgpwZkb5_xTPH.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: python packages versus pydoc -k

[Toshio Kuratomi]

On Thu, Mar 13, 2014 at 09:11:12AM -0700, Josh Stone wrote:
 On 03/12/2014 06:12 PM, Toshio Kuratomi wrote:
  On Wed, Mar 12, 2014 at 12:18:17PM -0700, Josh Stone wrote:

  Of course, these are just the first exceptions I hit.  Experience shows
  that fixing these will likely find more behind them.
 
  Yeah, I think there's a never ending treadmill here.
 
 Alright, I'll try not to let it bother me then.

Yeah... which is not to stop you from filing bugs and working on fixes if
you want... but I don't think we'll be able to maintain a working pydoc
-k... there's jsut too many ways it can go wrong whenever a python package
updates or is added.

-Toshio


pgpWmeCX6s4Sm.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: python packages versus pydoc -k

[Toshio Kuratomi]

On Wed, Mar 12, 2014 at 12:18:17PM -0700, Josh Stone wrote:
 Do we have any packaging requirements or guidelines for python modules
 to behave nicely with pydoc?  I've seen this break a number of times,
 and sometimes the bugs I've filed have been fixed, sometimes ignored.
 Before I go through another round, I'd like to know if we have (or
 should have) some official policy on this.
 
We don't currently have any official guidelines on this.

I know that pydoc can be broken.  Because of how it works I'm not certain
that we can fix it and keep it fixed.

 AIUI, pydoc works by importing the named module, then displaying its
 docstrings.  Then pydoc -k does this for all modules in sys.path,
 looking for the specified keyword.  A problem then arises if something
 in the path does protect itself with 'if __name__ == __main__:' to
 know when it's acting as a module or a script.  (And if some module
 really doesn't want to support normal importing, it should not be
 installed in the path!)
 
There's also packages that need a non-default version of a dependency in
order to work.  We've worked out ways to do this so that the module can be
imported when we use them in an application but it will probably break with
the way pydoc -k works.

setuptools entrypoints can break unrelated code.  It's probably another way
that pydoc -k could be broken.

[..]
 
 Of course, these are just the first exceptions I hit.  Experience shows
 that fixing these will likely find more behind them.

Yeah, I think there's a never ending treadmill here.


pgprsxW9r6Dwn.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Per-Product Config file divergence

[Toshio Kuratomi]

At last week's FESCo meeting, the fact that Products desired to have
divergent configuration was briefly touched on.  On Thursday, a few FPC
members had a brainstorming session about it and on Friday, sgallagh and
that brainstorming continued with sgallagh, adamw, tflink, notting, and
myself.  We came up with a tentative idea here:

https://fedoraproject.org/wiki/User:Toshio/Product_Divergence_(config)

The idea is to allow config file divergence via the alternatives system as
that already provides us with a commandline tool and some structure to build
on.  We'd still have to write a few pieces to complete the picture but it
seemed to be a better starting point than using rpm Conflicts between
config-packages.

Anyone have thoughts on this potential path?

-Toshio


pgpp2bECF9uaP.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Per-Product Config file divergence

[Toshio Kuratomi]

On Mon, Mar 10, 2014 at 10:40:29AM -0600, Chris Murphy wrote:
 
 On Mar 10, 2014, at 10:10 AM, Toshio Kuratomi a.bad...@gmail.com wrote:
 
  At last week's FESCo meeting, the fact that Products desired to have
  divergent configuration was briefly touched on.  On Thursday, a few FPC
  members had a brainstorming session about it and on Friday, sgallagh and
  that brainstorming continued with sgallagh, adamw, tflink, notting, and
  myself.  We came up with a tentative idea here:
  
  https://fedoraproject.org/wiki/User:Toshio/Product_Divergence_(config)
  
  The idea is to allow config file divergence via the alternatives system as
  that already provides us with a commandline tool and some structure to build
  on.  We'd still have to write a few pieces to complete the picture but it
  seemed to be a better starting point than using rpm Conflicts between
  config-packages.
  
  Anyone have thoughts on this potential path?
 
 What will fedup updates of Fedora 20 look like? Would there be a flag, e.g. 
 --product cloud/workstation/server? If not specified do we fail, or is there 
 a default?
 
 Or is this getting too far ahead of things?
 
The default should be whatever product was installed onto the system
originally.  Going from Fedora 20 to a Product in F21 is probably a one-off
but I'm not sure what that should look like.  I could be totally wrong but
I believe that each of the Products will have their own install image.  With
that in mind, fedup might need a one-off bit of UI to ask which Product
image you want to use.  That image would then set the Product on the disk
accordingly.

-Toshio


pgp0meK5sbc8S.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Per-Product Config file divergence

[Toshio Kuratomi]

On Mar 10, 2014 10:22 AM, Kevin Fenzi ke...@scrye.com wrote:

 On Mon, 10 Mar 2014 10:09:43 -0700
 Toshio Kuratomi a.bad...@gmail.com wrote:

   What will fedup updates of Fedora 20 look like? Would there be a
   flag, e.g. --product cloud/workstation/server? If not specified do
   we fail, or is there a default?
  
   Or is this getting too far ahead of things?
  
  The default should be whatever product was installed onto the system
  originally.  Going from Fedora 20 to a Product in F21 is probably a
  one-off but I'm not sure what that should look like.  I could be
  totally wrong but I believe that each of the Products will have their
  own install image.  With that in mind, fedup might need a one-off bit
  of UI to ask which Product image you want to use.  That image would
  then set the Product on the disk accordingly.

 Or we could simply say that fedup doesn't upgrade from a non product to
 a product. You have to re-install or use a manual method to do that
 (some yum/dnf commands, etc).

 We need to consider this case also for someone who installs Fedora, but
 not one of the products (a spin, or a custom kickstart or whatever) who
 then wants to install a product.

Perhaps spins should also specify a product identifier.  Maybe they could
have the ability to specify an existing products' identifier if they are
merely a variant set of packages top an existing product as well.

-Toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Per-Product Config file divergence

[Toshio Kuratomi]

On Mon, Mar 10, 2014 at 12:08:40PM -0600, Kevin Fenzi wrote:
 On Mon, 10 Mar 2014 11:00:25 -0700
 Toshio Kuratomi a.bad...@gmail.com wrote:
 
  Perhaps spins should also specify a product identifier.  Maybe they
  could have the ability to specify an existing products' identifier if
  they are merely a variant set of packages top an existing product as
  well.
 
 But they aren't products... so that would be pretty confusing. 
 
We don't necessarily have to limit the identifier to Official Products.  It's
purpose is to allow software to differentiate
this-thing-that-we-ship-that's-different-than-these-other-things.  So it
might be that spins fall into this category jsut as much as the Official
Products do.

 Yeah, if there was some spin built on top of workstation I assume they
 would just have the workstation product setup by pulling in the
 fedora-workstation-release and such. 

-Toshio


pgplUcG5cNk2I.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Per-Product Config file divergence

[Toshio Kuratomi]

On Mar 10, 2014 11:09 AM, Matthew Miller mat...@fedoraproject.org wrote:

 On Mon, Mar 10, 2014 at 10:09:43AM -0700, Toshio Kuratomi wrote:
   What will fedup updates of Fedora 20 look like? Would there be a flag,
   e.g. --product cloud/workstation/server? If not specified do we fail,
or
   is there a default?
  The default should be whatever product was installed onto the system
  originally.  Going from Fedora 20 to a Product in F21 is probably a
one-off
  but I'm not sure what that should look like.  I could be totally wrong
but
  I believe that each of the Products will have their own install image.
 With
  that in mind, fedup might need a one-off bit of UI to ask which Product
  image you want to use.  That image would then set the Product on the
disk
  accordingly.

 I assume that we'll do something that makes it easy to read the existing
 product from the system -- I like fedora-release +
 fedora-release-{workstation,server,cloud} subpackages.

 And I think those subpackages probably _should_ conflict, don't you?


Depends.  Sgallagh had a desire to mark that a particular system
implemented multiple products (ie server that also had workstation
installed).  I'm not sure that's a good idea but if we did go that route
then we'd have to be able to support that with our identifiers.
Subpackages that conflict wouldn't be flexible enough to handle that.

-Toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Per-Product Config file divergence

[Toshio Kuratomi]

On Mon, Mar 10, 2014 at 03:16:31PM -0400, Martin Langhoff wrote:
 On Mon, Mar 10, 2014 at 12:10 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
  The idea is to allow config file divergence via the alternatives system as
 
 Will this handle user customization? IME alternatives is not geared to
 handle config files, customizable shell scripts, etc.
 
That's an issue that I was trying to think through over the weekend.
I think you're right that alternatives by itself wouldn't handle this well.
I was trying to figure out if we could use alternatives to copy in a config
file instead of symlinking or check the hash of the file just like rpm would
do with any other config file but didn't get through my thought experiments.

It may be that vanilla alternatives is unsuitable but we want something
alternatives-like (an external tool that updates the config file) rather
than something based on rpm metadata (Conflicts which causes you to have
either one or the other package installed).

-Toshio


pgpZ8XQJw1fNS.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Toshio Kuratomi]

On Mar 9, 2014 7:49 AM, Kevin Kofler kevin.kof...@chello.at wrote:

 Toshio Kuratomi wrote:
  Directory and file interaction is a hard problem. There's no right thing
  to do in this case.  The many possible things we could do all have one
  drawback or another in certain cases.

 The right thing is clear: If all the files inside the directory are owned
by
 packages about to be removed in the transaction, just rm -rf the directory
 (or rather the equivalent in C code),

Yes, the simple case is simple.

 otherwise rename it with a suffix
 (.rpmsave, if necessary .rpmsave0, .rpmsave1, … , .rpmsave10, …) and only
 delete the files owned by packages about to be removed in the transaction.

But this is where the answers start to have drawbacks.  As just one
example, renaming the directory will break other packages which installed
files into that directory.

-Toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Toshio Kuratomi]

On Mar 8, 2014 11:57 AM, Kevin Kofler kevin.kof...@chello.at wrote:

 Tom Callaway wrote:

  Changes to python-setuptools in F20 cause easy_install to install egg
  files instead of egg directories by default. This sometimes causes
  problems for rpms of multi-version python modules as the egg filenames
  are the same if the version of the package hasn't been increased and rpm
  is unable to replace the directory with a file. To fix this, the ​
  https://fedoraproject.org/wiki/Packaging:Python_Eggs#Multiple_Versions
  guideline has been updated to pass the -Z switch to easy_install which
  restores the former behaviour of installing eggs as a directory.
 
  If you package a backwards or forwards compat python module that makes
  use of the Multiple_Versions guideline (or easy_install in some other
  way), please update your spec file to include the -Z switch.

 Couldn't we %pretrans-hack that?


In terms of possible, the answer is yes.  In terms of desirable, the answer
is no.  First, the hack you refer to is not guaranteed safe and should be
avoided when alternative meth odds exist.  This guideline change is such an
alternative that simply adds a single upstream cli flag to workaround the
problem.

Secondly, the current standard is to install most scripting language files
in human readable form.  The new easy_install default violates that. using
the flag restores that.

 And with all the issues this and the related symlink problem have caused,
 IMHO, it's really time to fix RPM to support these cases without hacks!

Directory and file interaction is a hard problem. There's no right thing to
do in this case.  The many possible things we could do all have one
drawback or another in certain cases.

-Toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Meeting minutes for Env-and-Stacks WG meeting (2014-03-03)

[Toshio Kuratomi]

On Tue, Mar 04, 2014 at 03:23:28PM +0100, Marcela Mašláňová wrote:
 
 * additional repository - Playground requirements  (mmaslano, 13:03:05)
   * how do updates work (rolling? bodhi? Will we constantly be
 regenerating the repodata [like the rawhide build repo?])
 (mmaslano, 13:07:16)
   * rolling + constantly regenerating repodata  (mmaslano, 13:10:26)
   * one repo per Fedora release + arch  (tjanez, 13:11:14)
   * daily push  (mmaslano, 13:12:25)
   * no bodhi yet  (mmaslano, 13:14:02)
   * Do we trust this person to keep the repo up to date and address
 serious bugs/security issues.  (mmaslano, 13:20:50)
   * we could always have the fedora-playground-release package
 Obsoletes: badapp-$version  (mmaslano, 13:29:09)
   * is there a testing repo?  (mmaslano, 13:42:12)
   * testing repo - not needed, testing are coprs  (mmaslano, 13:43:07)
   * The repo will attempt to do automatic package review, falling back
 to human intervention on known trouble cases such as Obsoletes.
 (tjanez, 14:02:13)
   * ACTION: tjanez will add comments from our today's meeting to Open
 Questions  (mmaslano, 14:09:55)
 
Did anyone forward the playground repo proposal on to FESCo?  FESCo needs to
know about things we are hooping to do in time for tomorrow's meeting
(officially, Monday, Mar 3... but discussion will start at the meeting
tomorrow).

-Toshio


pgp39Mqzgzb5W.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: System-wide crypto policy

[Toshio Kuratomi]

On Feb 27, 2014 8:25 AM, Jaroslav Reznik jrez...@redhat.com wrote:

 = Proposed System Wide Change: System-wide crypto policy =
 https://fedoraproject.org/wiki/Changes/CryptoPolicy

 == Detailed Description ==
 The idea is to have some predefined security levels such as LEVEL-80,
 LEVEL-128, LEVEL-256,
 or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the
 security levels
 that the administrator of the system will be able to configure by
modifying
 /usr/lib/crypto-profiles/config
 /etc/crypto-profiles/config

 and being applied after executing update-crypto-profiles.
 (Note: it would be better to have a daemon that watches those files and
 runs update-crypto-profiles automatically)

 After that the administrator should be assured that any application
 that uses the system settings will follow a policy that adheres to
 the configured profile.

 Ideally setting a profile should be setting:
 * the acceptable TLS/SSL (and DTLS) versions
 * the acceptable ciphersuites and the preferred order
 * acceptable parameters in certificates and key exchange, i.e.:
 ** the minimum acceptable size of parameters (DH,ECDH,RSA,DSA,ECDSA)
 ** the acceptable elliptic curves (ECDH,ECDSA)
 ** the acceptable signature hash functions
 * other TLS options such as:
 ** safe renegotiation


Does this configuration limit the algorithms that are available or only the
options that can be given to those algorithms or only the default values of
those algorithms?

-Toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packages with missing %check

[Toshio Kuratomi]

On Feb 26, 2014 5:16 AM, Colin Walters walt...@verbum.org wrote:

 On Wed, Feb 26, 2014 at 8:09 AM, Stanislav Ochotnicky 
sochotni...@redhat.com wrote:

 I didn't name them. I used standard names for different testing levels
as defined by software engineering bodies. Quoting from SWEBOK:


 Yes, I think they're wrong.   Well, suboptimal is a better word.

 During making glib changes you should run glib unit tests to have some
basic level of assurance you didn't introduce regressions or unwanted
changes.


 The *very first* test I run is does the OS still boot?  That's called
smoketest for me, and it only takes a few minutes.

 Yes, after every change, even just an updated translation, I boot the OS,
run through systemd, gdm, gnome-shelll, and everything and ensure it still
logs in.

 This is *before* I run the GTK+ tests or the glib tests or any other
test.  Why?  Because if that fails, there's *no point* to running the other
tests.  The system is broken.  The originating change is investigated and
is up for reverting.   Whether or not the GKeyFile test pass or not is
irrelevant.

 (Also, there is the fact that InstalledTests are guaranteed to be run in
a logged in desktop, not a mock chroot, so the above needs to work anyways)

 It's great that your change helped with discovering issues but perhaps
your original testsuite was mixing different levels of testing in the same
code. Unit tests are supposed to be quick, dirty solutions using mock
objects and other hacks to allow of testing with small granularity.


 Ah, but if one makes integration tests very fast and easy to run as I
have, then there's less need for quick and dirty.

Integration tests and unittests really have different purposes.
Integration tests test that things that you want to do aren't broken by a
change.  Unittests test that individual functional units aren't broken by a
change.

For a developer who can run their tests right after each commit there's
likely not a lot of difference.  For someone who's getting a code drop with
hundreds of commits in it, however, it's often easier to debug what's
causing a failing unittest than what's causing a failing integration test.
The reason is that ideally unittests isolate a small piece of code for
testing.  when it fails, the Unittest itself provides the clues to the
person debugging as to where the failure lies.

-Toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packages with missing %check

[Toshio Kuratomi]

On Tue, Feb 25, 2014 at 12:45:11PM +0200, Alexander Todorov wrote:
 Hi guys,
 I have identified 551 packages on the Fedora 20 source DVD which are
 missing a %check section in their spec files but are very likely to
 have a test suite. See
 https://github.com/atodorov/fedora-scripts/blob/master/sample-data/fedora-20/srpms-with-tests-WITHOUT-check-in-fedora-20-dvd
 
 For a few of them I already had bug open previously (will filter the
 list later when I run my scripts against latest Rawhide).
 
 I have the following questions:
 
 1) Do we consider this a bug and if yes what priority do you give it?
 From last week discussions it looks like most people prefer to have
 tests executed in %check.
 
https://fedoraproject.org/wiki/Packaging:Guidelines#Test_Suites

So in some set of cases this would be a bug.  I don't have an estimate of
how many test suites would be practical to execute the test suite though.

-Toshio


pgpuCMVJ_QYR9.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2014-02-19)

[Toshio Kuratomi]

On Feb 24, 2014 1:46 AM, Marcela Mašláňová mmasl...@redhat.com wrote:

 On 02/19/2014 08:57 PM, Tomas Mraz wrote:

 * Open floor  (t8m, 19:45:44)
* AGREED: FESCo expects the Tech specs/docs from working groups by
  March 3rd at the latest (+7, -0, 0:0)  (t8m, 19:50:38)
* ACTION: t8m will update the weekly reports ticket with this request
  (t8m, 19:53:08)


 Env and Stacks WG are dependent on requirements from 3 products, so we
probably can't deliver on 3rd March.

We can start though.  For instance, we've decided that we're forging ahead
with the idea of a repo for less than perfect packages.  So we'll need the
support infrastructure for that.

- Disk space?
- hooked up to the mirror network?
- copr out of beta?
- what scripts and manpower does the new repo need?
- are we using bodhi, signing packages, etc?
- do we need a set of people who check what goes into the new repo?

-toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: python-django update to Django-1.6

[Toshio Kuratomi]

}/django/contrib/localflavor/locale/*/LC_MESSAGES/
-%dir %{python_sitelib}/django/contrib/markup/
-%dir %{python_sitelib}/django/contrib/messages/
-%dir %{python_sitelib}/django/contrib/messages/locale
-%dir %{python_sitelib}/django/contrib/messages/locale/??/
-%dir %{python_sitelib}/django/contrib/messages/locale/??_*/
-%dir %{python_sitelib}/django/contrib/messages/locale/*/LC_MESSAGES
-%dir %{python_sitelib}/django/contrib/redirects
-%dir %{python_sitelib}/django/contrib/redirects/locale
-%dir %{python_sitelib}/django/contrib/redirects/locale/??/
-%dir %{python_sitelib}/django/contrib/redirects/locale/??_*/
-%dir %{python_sitelib}/django/contrib/redirects/locale/*/LC_MESSAGES
-%dir %{python_sitelib}/django/contrib/sessions/
-%dir %{python_sitelib}/django/contrib/sessions/locale/
-%dir %{python_sitelib}/django/contrib/sessions/locale/??/
-%dir %{python_sitelib}/django/contrib/sessions/locale/??_*/
-%dir %{python_sitelib}/django/contrib/sessions/locale/*/LC_MESSAGES
-%dir %{python_sitelib}/django/contrib/sitemaps/
-%dir %{python_sitelib}/django/contrib/sites/
-%dir %{python_sitelib}/django/contrib/sites/locale/
-%dir %{python_sitelib}/django/contrib/sites/locale/??/
-%dir %{python_sitelib}/django/contrib/sites/locale/??_*/
-%dir %{python_sitelib}/django/contrib/sites/locale/*/LC_MESSAGES
-%dir %{python_sitelib}/django/contrib/staticfiles/
-%dir %{python_sitelib}/django/contrib/syndication/
-%dir %{python_sitelib}/django/contrib/webdesign/
-%{python_sitelib}/django/contrib/*/*.py*
-%{python_sitelib}/django/contrib/*/fixtures/
-%{python_sitelib}/django/contrib/*/handlers/
-%{python_sitelib}/django/contrib/*/management/
-%{python_sitelib}/django/contrib/*/plugins/
-%{python_sitelib}/django/contrib/*/templates/
-%{python_sitelib}/django/contrib/*/templatetags/
-%{python_sitelib}/django/contrib/*/tests/
-%{python_sitelib}/django/contrib/*/views/
-%{python_sitelib}/django/contrib/gis/admin/
-%{python_sitelib}/django/contrib/gis/db/
-%{python_sitelib}/django/contrib/gis/forms/
-%{python_sitelib}/django/contrib/gis/gdal/
-%{python_sitelib}/django/contrib/gis/geometry/
-%{python_sitelib}/django/contrib/gis/geos/
-%{python_sitelib}/django/contrib/gis/maps/
-%{python_sitelib}/django/contrib/gis/sitemaps/
-%{python_sitelib}/django/contrib/gis/utils/
-%{python_sitelib}/django/contrib/localflavor/generic/
-%{python_sitelib}/django/contrib/localflavor/in_/
-%{python_sitelib}/django/contrib/localflavor/is_/
-%{python_sitelib}/django/contrib/messages/storage/
-%{python_sitelib}/django/contrib/sessions/backends/
-%{python_sitelib}/django/forms/
-%{python_sitelib}/django/templatetags/ 
-%{python_sitelib}/django/core/
-%{python_sitelib}/django/http/
-%{python_sitelib}/django/middleware/
-%{python_sitelib}/django/test/
-%{python_sitelib}/django/conf/*.py*
-%{python_sitelib}/django/conf/project_template/
-%{python_sitelib}/django/conf/app_template/
-%{python_sitelib}/django/conf/urls/
-%{python_sitelib}/django/conf/locale/*/*.py*
-%{python_sitelib}/django/conf/locale/*.py*
-
-%{python_sitelib}/*.egg-info
-
- 
+
+%{python_sitelib}/*.egg
 
 %files doc
 %defattr(-,root,root,-)
@@ -301,6 +165,9 @@ cd tests
 
 
 %changelog
+* Fri Feb 21 2014 Toshio Kuratomi tos...@fedoraproject.org - 1.4.8-1.1
+- Initial test of parallel installable version
+
 * Mon Sep 16 2013 Matthias Runge mru...@redhat.com - 1.4.8-1
 - update to 1.4.8, fix CVE-2013-1443 (DoS via large passwords)
 - fixes rhbz#1008282
Index: Django-1.4.8/setup.py
===
--- Django-1.4.8.orig/setup.py
+++ Django-1.4.8/setup.py
@@ -1,4 +1,4 @@
-from distutils.core import setup
+from setuptools import setup
 from distutils.command.install_data import install_data
 from distutils.command.install import INSTALL_SCHEMES
 import os


pgpwMy5O4o9w2.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rpm bug 1065563 affecting httpd / php packages

[Toshio Kuratomi]

On Mon, Feb 17, 2014 at 10:56:14AM +, Joe Orton wrote:
 On Mon, Feb 17, 2014 at 12:37:53PM +0200, Ville Skyttä wrote:
  I don't think this calls for a mass rebuild or any kind of a rebuild
  actually, nor should it be rawhide only. AFAIU this doesn't affect
  runtime at all, only build time, and affected packages can be just
  fixed at the same time if they need an update in affected releases in
  the first place.
 
 The new rpmbuild cannot build an httpd which will satisfy dependencies 
 of current Fedora packages.  The new rpmbuild will force us to break the 
 existing ABI dependency for httpd, breaking compatibility with existing 
 and third-party packages.  And all that breakage is for zero gain, with 
 a bunch of engineering time wasted.
 
 This change is inappropriate for a F19/20 update IMO.  Yes, we know the 
 deps are wrong, but that was not hurting any Fedora users, and we've 
 fixed it properly for F21.
 
I think this depends on what rpm and yum are currently doing with the
dependencies.  As Panu says here:
https://bugzilla.redhat.com/show_bug.cgi?id=1065563#c1 if - is used in
version or release then rpm and yum have to guess about what portion of hte
string is the version and which is the release.

If rpm/yum are doing the wrong thing in a large number of cases (there's
several ways it could be wrong -- one portion of the stack is parsing it
as Version: 20140215-x86 Release: 64 and another is parsing it as Version:
20140215 Release: x86-64;  there's a manual version comparison somewhere
that's looking for something like httpd-mmn = 20140215 which always
evaluates false because the Provides is evaluating to Version: 20140215-x86;
etc) then it can be effectively argued that the provides themselves need to
be fixed in the stable Fedora release.  rpmbuild's refusal to build is
simply a helpful tool for showing where these broken Provides are present.

However, it could also be that over the course of time rpm and the software
built on top of it has evolved to make the same guess about where to separate
version-release in the ambiguous case.  If that's the case then sure, rpm
could continue to allow the broken behaviour in stable releases and only
make the change in rawhide.

I'd leave it to Panu and the rpm team to let us know which of those
scenarios are true for the current code.

-Toshio


pgpjADYu0Jmk_.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Heads-up: updating python-sphinx to 1.2.1 in Rawhide

[Toshio Kuratomi]

On Wed, Feb 12, 2014 at 10:54:14AM -0500, Stephen Gallagher wrote:
  Quite a lot of packages rely on Sphinx, so I
 think we may even want to deal with this in a side-tag.


My understanding from Dennis is that creating and then merging side tags in
koji is not a trivial thing (I can't remember is it's labor intensive when
merging back or whether having a lot of side-tags is bad for koji's
performance.)

Since sphinx is used very little at runtime and since there's not a deep
circular dep chain (sphinx requires docutils.  docutils does not require
sphinx [although, looking at the source, it could be changed to rebuild its
docs using sphinx at buildtime]) this seems like it might be better to deal
with fallout in rawhide than go through the creation of a side tag.

Pre-view packages in copr (or a scratch build link) does sound like a nice
thing, though (although my reading of the incompatibilities is that most
packages won't hit those issues.)

-Toshio


pgpumInDazGJA.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Summary/Minutes for today's FESCo Meeting (2014-02-12)

[Toshio Kuratomi]

===
#fedora-meeting: FESCO (2014-02-12)
===


Meeting started by abadger1999 at 18:01:58 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting/2014-02-12/fesco.2014-02-12-18.01.log.html
.



Meeting summary
---
* init process  (abadger1999, 18:02:02)

* New FESCo  (abadger1999, 18:04:01)
  * LINK:

https://lists.fedoraproject.org/pipermail/devel-announce/2014-February/001300.html
(abadger1999, 18:04:06)
  * Thanks to mmaslano for her service and welcome to dgilmore
(sgallagh, 18:06:06)
  * LINK:
https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee
https://fedoraproject.org/wiki/Extras/SteeringCommitteeHistory
(abadger1999, 18:06:06)
  * ACTION: nirik to take care of the mailing list switch  (abadger1999,
18:06:20)
  * ACTION: abadger1999 to take care of updating trac and the 2 fesco
wiki pages  (abadger1999, 18:07:54)

* #1221 (Product working group activity reports) – FESCo  (abadger1999,
  18:08:19)
  * very little WG activity as a lot of people were running around to
conferences  (mattdm, 18:09:25)
  * fesco acks the notes on WG progress  (abadger1999, 18:13:29)

* #1178 (Fedora 21 scheduling strategy) – FESCo  (abadger1999, 18:13:40)
  * FESCo needs the list of necessary changes from existing Fedora
procedures needed to release the products.  (abadger1999, 18:14:25)
  * ACTION: mattdm to help coordinate the engagement of talking with
other teams once we get the list of changes.  (abadger1999,
18:15:09)
  * ACTION: sgallagh to send message to devel-announe that talks about
where to discuss the initial list of changes to existing Fedora
procedures  (abadger1999, 18:20:01)
  * ACTION: sgallagh to send what we need next from WGs message to
liasons to bring to the next WG meeting  (abadger1999, 18:21:51)

* #1198 (Possible changes to Fedora EOL bug procedure) – FESCo
  (abadger1999, 18:26:27)
  * ACTION: mattdm to check if it's possible to do the
anyone-can-repoen-closed-eol  (mattdm, 18:42:08)

* #1197 (Procedure for suggesting/approving different Products and/or
  WGs?) – FESCo  (abadger1999, 18:44:44)
  * Continue to discuss how to make new products on mailing list
(abadger1999, 19:09:15)

* #1231 (Provenpackager request: averi) – FESCo  (abadger1999, 19:09:24)
  * averi approved as a provenpackager (+1:7, 0:1, -1:0)  (abadger1999,
19:13:31)

* #1229 (RFC: add WG liasons to FESCo mailing list?) – FESCo
  (abadger1999, 19:13:41)
  * Adding liasons to fesco list passed (+1:7, 0:1, -1:0)  (abadger1999,
19:19:30)

* #1230 (Requesting FESCo address Cherokee logo issue) – FESCo
  (abadger1999, 19:19:50)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1060984   (nirik,
19:30:08)
  * LINK: https://fedorahosted.org/fesco/ticket/1230#comment:10
(abadger1999, 19:31:18)
  * LINK:

https://github.com/cherokee/webserver/commit/965311bf0ff0f00556abfbc425fe2dc9c52f5533
(nirik, 19:33:30)
  * package maintainer to remove or replace the offensive logo(s). If
maintainer refuses or 2 weeks pass, package to be retired from
fedora and no longer shipped PASSED (+1:8, 0:0, -1:0)  (abadger1999,
19:38:54)
  * fesco notes that the upstream censored logo is also deemed to fall
into the offensive category.  (abadger1999, 19:39:46)

* #1233 (Nonresponsive maintainer: steve) – FESCo  (abadger1999,
  19:39:57)
  * decide whether to orphan other packages owned by steve next week
since it's not clear if the week since direct email was sent has
expired.  (abadger1999, 19:46:25)
  * defered to next week  (abadger1999, 19:52:37)

* #1179 (Interactions of the various Products) – FESCo  (abadger1999,
  19:52:59)

* Next week's chair  (abadger1999, 19:54:51)
  * t8m to chair next week's meeting  (abadger1999, 19:55:27)

* Open Floor  (abadger1999, 19:55:31)
  * we'll continue with current time for now (dgilmore is the one most
inconvenienced, may have to adapt later)  (abadger1999, 19:57:43)

Meeting ended at 20:01:17 UTC.




Action Items

* nirik to take care of the mailing list switch
* abadger1999 to take care of updating trac and the 2 fesco wiki pages
* mattdm to help coordinate the engagement of talking with other teams
  once we get the list of changes.
* sgallagh to send message to devel-announe that talks about where to
  discuss the initial list of changes to existing Fedora procedures
* sgallagh to send what we need next from WGs message to liasons to
  bring to the next WG meeting
* mattdm to check if it's possible to do the
  anyone-can-repoen-closed-eol




Action Items, by person
---
* abadger1999
  * abadger1999 to take care of updating trac and the 2 fesco wiki pages
* mattdm
  * mattdm to help coordinate the engagement of talking with other teams
once we get the list of changes.
  * mattdm to check if it's possible to do the

Schedule for Wednesday's FESCo Meeting (2014-02-12)

[Toshio Kuratomi]

Long agenda this week due to not having a meeting last week.  I've tried to
put the easiest things first (other than #1197 which is a followup item) to
try to clear out as many as possible.


Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18: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 '2014-02-12 18:00 UTC'


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

= Followups =

#topic New FESCo
https://lists.fedoraproject.org/pipermail/devel-announce/2014-February/001300.html

#topic #1221 (Product working group activity reports) – FESCo
.fesco 1221
https://fedorahosted.org/fesco/ticket/1221

#topic #1198 (Possible changes to Fedora EOL bug procedure) – FESCo
.fesco 1198
https://fedorahosted.org/fesco/ticket/1198#comment:58

#topic #1197 (Procedure for suggesting/approving different Products and/or 
WGs?) – FESCo
.fesco 1197
https://fedorahosted.org/fesco/ticket/1197


= New business =

#topic #1231 (Provenpackager request: averi) – FESCo
.fesco 1231
https://fedorahosted.org/fesco/ticket/1231

#topic #1229 (RFC: add WG liasons to FESCo mailing list?) – FESCo
.fesco 1229
https://fedorahosted.org/fesco/ticket/1229

#topic #1230 (Requesting FESCo address Cherokee logo issue) – FESCo 
.fesco 1230
https://fedorahosted.org/fesco/ticket/1230

#topic #1233 (Nonresponsive maintainer: steve) – FESCo
.fesco 1233
https://fedorahosted.org/fesco/ticket/1233

#topic #1178 (Fedora 21 scheduling strategy) – FESCo
.fesco 1178
https://fedorahosted.org/fesco/ticket/1178

#topic #1179 (Interactions of the various Products) – FESCo
.fesco 1179
https://fedorahosted.org/fesco/ticket/1179

= 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. 


pgpYyFrEcWNYn.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: What is bundling?

[Toshio Kuratomi]

On Mon, Feb 10, 2014 at 11:54:47AM +0100, Florian Weimer wrote:
 What is bundling in the sense of
 https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries?
 
 In my opinion, the page deals with source package contents.
 
 But there are other things a package can do bundle things in the
 binary packages, by copying code and data from installed packages in
 the build root.  These have comparable negative effects to bundling
 at the source package level.  Examples are static linking (already
 covered elsewhere), Java static linking (jarjar, Maven bundling,
 perhaps others), things like minify/lstrip/fatpack, copying programs
 and .so files out of the build root, etc.
 
 Are these post-SRPM copying mechanism in scope for the no bundled
 libraries page, or should they be covered in other places?

These strategies usually come to the FPC in the context of bundled libraries
but they're actually static linking examples.  In general, the FPC considers
bundled libraries to be very problematic, static linking (and their analogs,
like packaging a library's source and then having a dependent package
compile against that) to be somewhat problematic, and shared libraries to be
preferred.

When there is no reason (the FPC is often called upon to evaluate whether
a valid reason exists) not to take the preferred strategy, packages need to
be modified to take that route.  If the FPC finds a valid reason for that
not to work, then the static linking alternatives are looked at and finally
the bundling alternatives.

-Toshio


pgph7r8lF37VO.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Orphaned packages

[Toshio Kuratomi]

We no longer have valid contact information for the following packagers due
to changes in their work duties:

* npajkovs
* fkocina
* zpavlas

For packages that they own we have orphaned the packages and made them
comaintainers.  In the future, if their current fas email addresses start to
bounce, we will need to remove the accounts from the pkgdb altogether.  If
anyone knows of a way to contact them to ask if they would still like to
maintain any of their packages we would appreciate it.  They'd need to
update their email address in fas and retake ownership of packages that were
orphaned as part of this.

The following packages have been orphaned.  Feel free to take them over if
you care about them:

npajkovs:
* inn (f19-devel and epel7)
* iptraf-ng (f19-devel epel5-6)
* irssi-xmpp (f19-devel)

fkocina:
* librtas (f19-devel)
* libservicelog (f19-devel)
* netatalk (f19-devel epel5-6)
* powerpc-utils-python (f19-devel)
* servicelog (f19-devel)

-Toshio


pgpWuMr1K_5Wr.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: EPEL Python 3 for 7?

[Toshio Kuratomi]

On Fri, Jan 17, 2014 at 10:55:09AM -0500, Matthew Miller wrote:
 On Fri, Jan 17, 2014 at 08:05:23AM -0700, Dave Johansen wrote:
   system.so we've mostly decided that things in the system shouldn't use 
   SCLs
   to work.  So we still need to solve the problem of newer python 
   interpreter
   and newer django framework for use with apps that EPEL ships.
  What about having a separate EPEL repo for SCLs and/or these newest version
  of things? Like you mentioned before, this takes more work, but if then
  those that want the stable base can have it and those that want the newest
  can have it as well.
 
The problem I'm raising is that SCLs don't solve the problem that sgallagh
is wanting to address by current policy.  He has applications (ReviewBoard)
that need newer versions of a framework (django) in order to run.  For us to
ship reviewboard in EPEL, we'd need to figure out if we want to allow that
and how.  Possible options are:

* ReviewBoard is in its own SCL.  The SCL deps on the appropriate django SCL.
* ReviewBoard is not in an SCL and we allow mainstream packages to dep on
  SCLs.  We need to figure out guidance on how a package can enable an scl
  for its own use as well.

Either of these may exacerbate the problem of an enabled scl polluting other
applications (especially hard if we get into invoking other processes from
that application... env variables like LD_LIBRRY_PATH will probably get
passed onto the invoked process).

 Or possibly an additional sub-project separate from EPEL. The idea has been
 kicked around a little bit -- Robyn Bergeron calls it EPIC (for Extra
 Packages for Infrastructure and Clouds, I think). I was thinking about this
 more recently in the context of things we need for Fedora.next in the
 coming year or so. The new repo might target both EL and Fedora and provide
 alternative versions maintained on, say, a 3-year lifecycle.
 
Yeah -- I think that something like this could be good.  A repo with
a 3 year lifecycle may make sense for RHEL more than Fedora as the
basesystem we're building on is still active at the end of that period.



pgpRdL8QZ1AjJ.pgp
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3 for 7?

[Toshio Kuratomi]

On Fri, Jan 17, 2014 at 01:57:18PM -0500, Matthew Miller wrote:
 On Fri, Jan 17, 2014 at 09:48:18AM -0800, Toshio Kuratomi wrote:
   Packages for Infrastructure and Clouds, I think). I was thinking about 
   this
   more recently in the context of things we need for Fedora.next in the
   coming year or so. The new repo might target both EL and Fedora and 
   provide
   alternative versions maintained on, say, a 3-year lifecycle.
  Yeah -- I think that something like this could be good.  A repo with
  a 3 year lifecycle may make sense for RHEL more than Fedora as the
  basesystem we're building on is still active at the end of that period.
 
 I'm thinking here about SCLs (or possibly other stack/env tech) that might
 target current supported Fedora but have a longer lifecyle of its own (with
 best-effort compatibility for three years).
 
 I keep coming back to this idea because it's what people ask me for. :)
 
Ah I see.  I think present thinking around SCLs has revolved around lifetime
for indivudal SCLs but having a repository wide lifetime could be either
better or a useful additional guarantee.

-Toshio


pgpC7ZOTAYkVO.pgp
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: GIT development branches for packagers?

[Toshio Kuratomi]

On Jan 16, 2014 10:19 AM, Andrew Lutomirski l...@mit.edu wrote:

 On Thu, Jan 16, 2014 at 10:15 AM, Adam Williamson awill...@redhat.com
wrote:
  On Wed, 2014-01-15 at 11:29 +0100, Tomas Mraz wrote:
  On Út, 2014-01-14 at 13:13 -0800, Andrew Lutomirski wrote:
   On Tue, Jan 14, 2014 at 12:59 PM, Adam Williamson 
awill...@redhat.com wrote:
On Tue, 2014-01-14 at 12:41 -0800, Andrew Lutomirski wrote:
I have some trivial cleanups I want to make to a package a
maintain.
These cleanups are trivial enough that I don't think they're
worth a
new build.  Should I commit them to the master branch?  If so, I
can
imagine a couple of issues:
   
 - A provenpackager could kick off a rebuild for whatever reason
(e.g.
dependency soname bump).  That will (I think) inadvertently
include my
changes.
   
Yes, this will happen. Why do you think it's a problem, though? If
your
changes are correct but you just don't think it's worth doing a new
build simply for them, why is it a problem if they get pulled in
when
someone does another build for some *other* (presumably
appropriate)
reason? It would seem like that's just what you'd want to happen.
  
   Depends how well I've tested.  I'd like to imagine that I never
commit
   anything broken anywhere, but this is empirically incorrect -- I
break
   development branches on a semi-regular basis.  I guess I'll just have
   to be more cautious w/ Fedora :)
  
   
 - I need to think about whether to add a changelog entry or not.
 If
not, those changes might be included silently.  If yes, then I
need to
think about what to do about the revision number.
   
One thing I've seen done is to add the line that actually
describes the
change, above the last date/builder/NEVR line, *without* adding a
new
line identifying the new build, date and builder. That way when
someone
comes along and does a new build, they ought to see what should
happen -
they should roll your partial entry into the entry they add for the
build.
  
   That would work.
 
  I'd recommend rather the approach suggested by Kevin. Bump the release
  and include a regular changelog entry. Just do not build. There is no
  rule that all changeloged entries must be really built.
 
  I have found this kind of phantom release a bit annoying in some really
  esoteric situations - when the changelog indicates that there was, say,
  a 1.2-6 build, but there never was, only 1.2-5 and 1.2-7 - but most of
  the time it's not going to be a problem, yeah.

 I can imagine this annoying anyone who does a mass rebuilt or a
 similar set of rebuilds that aren't intended (by the one doing the
 rebuilds) to change anything other than dependencies and, say, the
 compiler version.  Sure, this *shouldn't* cause a problem if everyone
 is appropriately careful, but I'm hesitant to trust things that
 transparently deploy code when no has has explicitly asked for a
 change to be deployed.


Yeah, I wouldn't trust my un built changes either :-).  But I think I'd go
with another of Kevin's options - go ahead and build in rawhide.  There's
really no downside to getting your this type of change out there sooner
rather than later.

-Toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf versus yum

[Toshio Kuratomi]

On Jan 7, 2014 4:53 AM, Frank Murphy frankl...@gmail.com wrote:

 On Thu, 02 Jan 2014 16:28:59 +0100
 Reindl Harald h.rei...@thelounge.net wrote:

  look like it starts to happen again: a replacement which is not ready
 
 https://bugzilla.redhat.com/show_bug.cgi?id=1049310

 It seems the majority want the current dnf default [1] to be kept
 Those who want to keep running kernel may need to speak up [2]

 [1]

http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel

 [2]
 https://bugzilla.redhat.com/show_bug.cgi?id=1049310

After asking on the bugzilla it seems that ales would like people who want
this change to cc themselves on the bug report.  If the cc reaches 40 he'll
reconsider.  Kinda a strange way of deciding but whatever works for the
maintainer I guess.

-Toshio
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf versus yum

[Toshio Kuratomi]

On Jan 9, 2014 6:26 AM, Chris Adams li...@cmadams.net wrote:

 Once upon a time, Toshio Kuratomi a.bad...@gmail.com said:
  nod  Just have yum drop a config file in there that protects the
kernel
  rather than protecting the kernel if some other package chooses to
protect
  something else.

 The magic don't delete the running kernel can't be done with just a
 config file.  Something has to detect which kernel version is running
 and match it to an RPM, and then protect just that version of multiple
 installed kernel RPMs.


Can't the meaning of a package name in the config file simply mean: make
sure one of these packages is always installed?

That won't protect the running kernel but it will protect a kernel
(probably the latest installed).  That would seem to address hreindl's use
case of wanting to test on multiple systems and when satisfied that things
are working cleanup all older packages.

That would still be a difference from the current yum code but less than
not having any protection at all and would be more generic.

-Toshio

 I supposed you could do it external to yum/dnf with a boot-time script
 that rewrites a config file to protect kernel-$(uname -r), but that may
 not always work (it would have to handle things like kernel-PAE and
 such).

 --
 Chris Adams li...@cmadams.net
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: dnf versus yum

[Toshio Kuratomi]

On Wed, Jan 08, 2014 at 02:56:14PM -0500, Bill Nottingham wrote:
 Matthew Miller (mat...@fedoraproject.org) said: 
  I'm a little lost in the thread, but do you mean that yum's protected
  packages functionality is undocumented? If that is what you mean, check the
  man page. It says:
  
protected_packages  This  is  a list of packages that yum should
never completely remove. They are  protected  via  Obsoletes  as
well as user/plugin removals.
  
The  default  is:  yum  glob:/etc/yum/protected.d/*.conf  So any
packages which should be protected can do so by including a file
in /etc/yum/protected.d with their package name in it.
  
Also  if  this  configuration  is set to anything, then yum will
protect the package corresponding to the running version of  the
kernel.
 
 While documented, I do find this last bit of behavior extremely odd and
 non-intuitive. (And hardcoded, no less.)
 
nod  Just have yum drop a config file in there that protects the kernel
rather than protecting the kernel if some other package chooses to protect
something else.

-Toshio


pgpS06jtjRQjT.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Source file audit - 2014-01-05

[Toshio Kuratomi]

On Tue, Jan 07, 2014 at 09:25:36AM +0100, Simone Caronni wrote:
 On 6 January 2014 20:53, Kevin Fenzi ke...@scrye.com wrote:
 
 slaanesh:BADSOURCE:dkms-2.2.0.3.tar.gz:dkms
 
 
 Downloading the file again gives a different md5sum, but the release tarball 
 is
 the same, so probably the archive has been regenerated.
 
 What's the procedure to update the source files in the lookaside cache when 
 the
 file name has not changed? fedpkg new-sources does not allow me to do it:
 
This should work.

 $ fedpkg new-sources dkms-2.2.0.3.tar.gz
 Uploading: 11a8aaade2ebec2803653837c7593030  dkms-2.2.0.3.tar.gz
 File already uploaded: dkms-2.2.0.3.tar.gz
 Uploaded and added to .gitignore:
 Source upload succeeded. Don't forget to commit the sources file
 
Looking at the lookaside cache directly, it looks like that file has been
uploaded previously (in lookaside, there's currently two tarballs for
dkms-2.2.0.3.tar.gz with two separate md5sums).  Has the upstream perhaps
released a tarball, released a new tarball, and then reverted to the
original one?

One option is to change the sources file to reflect the new md5sum.

You may also want to check that the new tarball and the tarball in the
lookaside cache *really* are the same.  A hash collision is unlikely but if
that were the case we'd want to be extra certain about what's going on
before blindly accepting the changed tarball.

You can retrieve the tarballs in lookaside directly from here:
http://pkgs.fedoraproject.org/lookaside/pkgs/dkms/dkms-2.2.0.3.tar.gz/

-Toshio


pgpb90KzIetT_.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct