On Sun, 13 Jan 2019 at 19:36, Miro Hrončok wrote:
> On 13. 01. 19 7:57, Nick Coghlan wrote:
> > Anyway, Zbigniew has resubmitted the change to make the package policy
> > compliant as a new PR:
> > https://src.fedoraproject.org/rpms/catfish/pull-request/2
>
> This is a
o make the package policy
compliant as a new PR:
https://src.fedoraproject.org/rpms/catfish/pull-request/2
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproje
rg/mm3/archives/list/distutils-...@python.org/message/TYENF32X7E6U3M2WJWMTH5DTJEXZBVMS/
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe se
; now being converted to RuntimeError rather than being an
alias for "return" in generator implementations, and the changes to the way
deprecation warnings get handled (by default and in unittest), so those
breakages are unfortunately intentional :(
Cheers,
Nick.
--
Nick Coghlan |
sal was that if a significant
regression *was* found in a point release, then the resolution would be to
spin a new point release with a fix ASAP. It's just that in such cases, the
version numbers involved would be X.Y.Z and X.Y.Z+1 rather than X.Y.Zrc1
and X.Y.Z.
Cheers
mended way to make `python` invoke Python 3.
Cool, thanks for moving this forward!
Did you want to update
https://fedora-python.readthedocs.io/en/latest/plans/default-python-module/
accordingly, or should that entire site just be scrubbed as an
experimental idea that didn't work out in
setting, Python will ignore source
file changes entirely, and trust that RPM will keep the source and pyc
files consistent.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@li
y just submitted the PR to fix that:
https://github.com/python/cpython/pull/4565
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe se
On 18 November 2017 at 06:54, Toshio Kuratomi wrote:
> On Thu, Nov 16, 2017 at 8:43 PM, Nick Coghlan wrote:
>> 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 comp
On 17 November 2017 at 11:55, Toshio Kuratomi wrote:
>
> On Thu, Nov 16, 2017 at 5:37 PM, Nick Coghlan wrote:
> > So the two possible approaches are:
> >
> > * traditional sdist: "setup.py build", "setup.py install"
> > * Current wheel macros: &q
is mainly in GitHub because I couldn't figure out how
to get Pagure's RTD integration to work, but I also see some benefits in
lowering barriers to contribution for Python folks that already have GitHub
accounts, but don't have Fedora accounts yet.
--
On 17 November 2017 at 01:51, Toshio Kuratomi wrote:
> On Nov 16, 2017 4:59 AM, "Nick Coghlan" 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&
named
https://fedoraproject.org/wiki/Packaging:Python#Example_common_spec_file -
that is the setup.py based build process, but it isn't currently obvious
that `pyX_build` and `pyX_install` assume the use of a setup.py file.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
On 16 November 2017 at 16:51, Elliott Sales de Andrade <
quantum.anal...@gmail.com> wrote:
> On 16 November 2017 at 01:31, Nick Coghlan wrote:
>>
>> However, if flit is now adding its own shim implcitly, then the answer
>> would just be "Yes".
>>
>
If that's still the case, then the answer would be "Yes, but only if you
make sure the sdist still contains a suitable setup.py shim".
However, if flit is now adding its own shim implcitly, then the answer
would just be "Yes".
Cheers,
Nick.
--
Nick Coghlan | ncogh...
On 29 August 2017 at 19:33, Petr Viktorin wrote:
> On 08/25/2017 10:23 AM, Nick Coghlan wrote:
>> Traditionally, that would have meant that we wouldn't get a Fedora
>> based Python 3.7 container out the door until the release of Fedora 29
>> in October, and we'd nev
On 24 August 2017 at 21:28, Petr Viktorin wrote:
> On 08/24/2017 12:22 PM, Nick Coghlan wrote:
>>> Stream names match the Platform module. We follow its policy here, even
>>> when
>>> it changes.
>>
>> Oh, interesting, I had that backwards (I thought
On 24 August 2017 at 19:02, Petr Viktorin wrote:
> On 08/24/2017 10:13 AM, Nick Coghlan wrote:
>> My current thinking based on that discussion is that we're actually
>> going to need a module set that looks like this for F28+:
>>
>> * Platform Python (already plan
On 21 August 2017 at 19:46, Petr Viktorin wrote:
> On 08/18/2017 01:38 PM, Nick Coghlan wrote:
>> Does that approach sound sufficiently plausible to folks that I can
>> use it to provide feedback to the folks working on the modularity
>> tooling as to the capabilitie
On 21 August 2017 at 19:53, Petr Viktorin wrote:
> On 08/18/2017 12:06 PM, Nick Coghlan wrote:
>> I couldn't get Pagure's webhooks to work properly (see
>> https://pagure.io/pagure/issue/2522), so revising the revised plan:
>> could someone with the appropriate a
igured as
the default when defining your container would *prevent* you from
including any regular userspace Python components - you'd only be able
to include the ones built specifically for that stream.
Does that approach sound sufficiently plausible to folks that I can
use it to provide feedba
On 15 August 2017 at 19:44, Nick Coghlan wrote:
> So I decided to set up a build on ReadTheDocs instead, and that looks
> to have just worked, including the logo rendering:
> https://fedora-python.readthedocs.io/en/latest/
I couldn't get Pagure's webhooks to work properly (se
vel dependency *isn't* shared,
and is instead specific to that application.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
On 11 August 2017 at 17:34, Nick Coghlan wrote:
> The relocated "default Python module" proposal is at
> https://docs.pagure.org/fedora-python.fedora-python/default-python-module.html
>
> I'm not super fond of that auto-generated URL, nor do I like the
> client-dri
On 2 August 2017 at 21:34, Nick Coghlan wrote:
> While working on
> https://fedoraproject.org/wiki/User:Ncoghlan/Default_python_module, I
> started getting annoyed at the lack of decent review and commenting
> features in MediaWiki, so prompted by
> https://docs.pagure.org/mod
vs binary
extension modules?
3. Would we allow daisy chaining of these private venvs via *.pth
files? (see https://github.com/berdario/pew#add)
4. How would we make this manageable across Fedora/EPEL/SCLo spec files?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
tchtoPython3
could potentially move over to the new repo as well, allowing folks to
submit suggested amendments as PRs
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
T
age maintainers and increases the opportunity
> for errors.
Aye, I agree we should be actively seeking to make single-spec
feasible across Fedora/RHEL/CentOS, at least in combination with EPEL
(without the EPEL dependency, it's hard to consistently make new
Fedora level macro definitions avai
alified
description and files sections
A script like that may even do a tolerable job for packages that *do*
offer Python 3 subpackages (since those will already have qualifiers,
and will necessarily appear after any unqualified runtime and build
requirements for
h the upcoming pkgdb -> Pagure--in-front-of-dist-git migration and
subsequently adding a new integration test to replace "--findleaks".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-d
On 20 July 2017 at 16:12, Bohuslav Kabrda wrote:
> On Thu, Jul 20, 2017 at 7:51 AM, Nick Coghlan wrote:
>> * checking for refleaks means we can't run parallel tests across
>> multiple processes. If we were to move refleak testing out to an
>> integration test in Tasko
test execution process, and provides an indicator of
where to focus efforts if the goal is to make the tests more
efficient.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-de
_prefix), and either
leave the latter undefined for systems with no native Py3 stack, or
else set it to rely on EPEL, IUS, or a suitable software collection.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
On 2 June 2017 at 18:46, Nick Coghlan wrote:
> On Fri, Jun 2, 2017 at 1:15 PM, Zbigniew Jędrzejewski-Szmek
> wrote:
>> It seems that right solution, that would work while the builders are
>> still not F26, would be to configure their locale to C.UTF-8. It'd
>> just
TYPE to the more
sensible setting.
The accepted version of the PEP upstream *only* sets LC_CTYPE, so the
chance of unintended side effects from the coercion is much lower that
it was with the approach that made the F26 Beta cut-off (which also
sets LANG).
Cheers,
Nick.
--
Nick Coghlan
Red
ructure specifically for LeApp, but I wanted to
raise the notion here early so I didn't go down any paths that would
later prove to be an absolute deal-breaker for updating the distro
level recommendations.
Cheers,
Nick.
[1] https://github.com/leapp-to/prototype/issues/126
--
Nick Coghlan
ctory to /usr/local in a way that "pipsi" detects)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
On 1 May 2017 at 22:47, Nico Kadel-Garcia wrote:
> On Sun, Apr 30, 2017 at 10:30 PM, Nick Coghlan wrote:
>> If the intended benefit of this change remains unclear, it may help to
>> focus on a specific concrete case, which would be that the following
>> operations
ocal/ split helps
there as well, by making the installed-via-pip versions easier to
identify even without checking the PEP 376 installation metadata)
Cheers,
Nick.
[1]
https://www.slideshare.net/ncoghlan_dev/developing-in-python-on-red-hat-platforms-devnation-2016
--
Nick Coghlan | ncogh...@gmai
On 29 April 2017 at 01:51, Barry Warsaw wrote:
> On Apr 28, 2017, at 11:50 AM, Nick Coghlan wrote:
>
>>My recollection from the last time I looked at this was that where
>>rewheel assumes that the Python level PEP 376 package metadata will be
>>available, dirtbike inste
or omitting the PEP 376 metadata.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
On 27 April 2017 at 23:04, Daniel P. Berrange wrote:
> On Thu, Apr 27, 2017 at 04:32:09PM +1000, Nick Coghlan wrote:
>> Their approach means that any harm caused by "sudo pip install X" can
>> subsequently be fully reversed by doing "sudo pip uninstall X".
>
uot; from the main Python development branch will mess with
the default symlinks if you didn't set a suitable `/opt/` prefix).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing
al system pip modules. It *does not belong* in
> /usr/lib. Because the components are modular and bundled in a non-RPM
> compatible fashion, it behooves developers to use a tool to segregate
> the tools as much as feasible from the Fedora underlying
> infrastructure. i.e., use pyvenv
dated delegation today:
https://mail.python.org/pipermail/python-dev/2017-April/147796.html
So with any luck, we should be able to get this change explicitly
approved by upstream within the next couple of weeks.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Aust
nded or suggested:
> * pillow
> * scikit-image
> * scikit-learn
> * scipy
> * statsmodels
> * sympy
> * pandas
I'd move `pandas` into the "recommends", but `suggests` seems
reasonable to me for the others.
Definite +1 from me for the general idea though.
Cheer
packaging collaboration across the RPM-based distros are
always going to get a big thumbs up from me :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
//fedoraproject.org/wiki/Category:ChangeAnnounced
that it's already been announced on fedora-devel.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubs
they
> should be doing (`pip install --user` is usually more appropriate).
>
> What do you think?
I guess when you're building an RPM you're not typically running as
root either, so standard RPM builds would still be fine. So +1 from
me.
Cheers,
Nick.
--
Nick Coghlan |
newer
> version of the same package with '--upgrade' option.
This, on the other hand, is why having the system site-packages
visible is discouraged in general - it really is more complicated than
using an environment that only shares that standard library and
On 8 February 2017 at 13:44, Tadej Janež wrote:
> Nick,
>
> thanks for your thorough answer.
>
> On Mon, 2017-02-06 at 20:07 +0100, Nick Coghlan wrote:
>>
>> It's not specific to Fedora's Python 3 packaging as such, but it *is*
>> specific to:
>>
ackage (to pass --ignore-installed when installing components into
the venv), and it may even make sense to file it as a bug against
CPython upstream as well, since it will happen any time you have the
three way combination of:
- system wide installation of pip
- using native stdlib venv cr
ases: run a recent Fedora container image atop a RHEL or
CentOS container host rather than running directly on the host.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
NOSYS handling needed to cope with
newer binaries running on older kernels
http://bugs.python.org/issue29157 has a patch to change the logic so
that getrandom is preferred over getentropy when both are available,
and also to add the ENOSYS handling that getrandom already has to
getentropy.
Ch
evice
path.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
On 24 December 2016 at 02:38, John Dulaney
wrote:
> On Fri, Dec 23, 2016 at 05:37:51PM +1000, Nick Coghlan wrote:
>
> > I filed that idea on the pip issue tracker at
> > https://github.com/pypa/pip/issues/4197 but figured I should raise it
> here
> > as well, as if so
es/4197 but figured I should raise it here
as well, as if something like this was added, then Fedora could be updated
to use a standard symlink map when building RPMs, and the developer portal
could be updated with suggest `pip.conf` settings to use the system cert
bundle by default.
Cheers,
Nic
ting "Some libraries,
applications and operating system interfaces may not work correctly."
as that's literally the answer to "Why isn't the C locale allowed by
default anymore?".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane,
to address ascii-only locales...)
click is younger than Python 3, so Armin did make some initial
attempts to get it working in the C locale on both 2 & 3. However, he
eventually gave the latter up as unsupportable and the error makes it
clear that &q
On 15 December 2016 at 21:17, Toshio Kuratomi wrote:
> 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 changi
On 12 December 2016 at 20:37, Petr Viktorin wrote:
> On 12/10/2016 02:56 PM, Nick Coghlan wrote:
>> I also have an upstream motive for suggesting this, though: if we do
>> this in the more constrained environment of "Fedora users" and it
>> doesn't break th
ng everything
in --user can easily break previously working setups.
So if we wanted to offer this, it would likely need to be as a
standalone (pip installable?) script that was equivalent to the above
bash snippet.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.co
On 12 December 2016 at 19:59, Tomas Orsava wrote:
> On 12/12/2016 05:39 AM, Nick Coghlan wrote:
>> On 11 December 2016 at 01:33, Donald Stufft wrote:
>> The benefit of that approach is that it would not only solve the
>> conflict between dnf and pip at the Fedora lev
}
(Plus error checking and the warning on stderr that this was being done)
I guess the next step would be for me to try this in a local clone,
and see what happens when running "LANG=C ./python -m regrtest" as
well as when running click.
Cheers,
Nick.
--
Nick Coghlan | ncogh.
On 11 December 2016 at 08:41, Neal Gompa wrote:
> On Sat, Dec 10, 2016 at 3:40 PM, Zbigniew Jędrzejewski-Szmek
> wrote:
>> On Sat, Dec 10, 2016 at 11:56:44PM +1000, Nick Coghlan wrote:
>>> Along similar lines, what do folks think of the idea of patching
>>> Python
On 11 December 2016 at 01:33, Donald Stufft wrote:
>
> On Dec 10, 2016, at 8:10 AM, Nick Coghlan wrote:
>
>> P.S. For folks wondering what the problem with "--user" is on
>> Debian/Ubuntu, as far as I know it's mainly the fact that
>> "~/.local/bin&
hat will help build a case for making
it the default upstream behaviour in Python 3.7.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
usr/bin/python3" end-user
configurable (so sysadmins can choose their own "default Python")
without risking any harm to core system utilities written in Python.
Cheers,
Nick.
P.S. For folks wondering what the problem with "--user" is on
Debian/Ubuntu, as far as I kno
h references to:
* https://packaging.python.org/specifications/#recording-installed-distributions
* http://setuptools.readthedocs.io/en/latest/setuptools.html
* https://packaging.python.org/multi_version_install/
* https://packaging.python.org/wheel_egg/
* https://packaging.python.
ersion identifier" feature
in PEP 440 to expose RPM release numbers to Python level tooling:
https://www.python.org/dev/peps/pep-0440/#local-version-identifiers
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
deployment rather than redistribution, and hence can (and
usually should) pin the exact combination of dependencies that was
tested.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list
enchmarking utility ("perf") and a new benchmark suite
for Python interpreters ("performance":
https://pypi.python.org/pypi/performance ). (He doesn't have 3.5 vs
3.6 performance data yet, but hopefully that will be available on
speed.python.org by the time of the actual 3.
On 4 November 2016 at 02:16, Charalampos Stratakis wrote:
> And FESCo ticket about that[0]
>
> [0] https://pagure.io/fesco/issue/1642
Awesome, thanks for tackling this.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane,
On 18 October 2016 at 00:49, Charalampos Stratakis wrote:
> The current URL should be https://beaker.qa.fedoraproject.org/ if that is the
> one you have in mind.
Indeed it is, thank you!
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Aus
at on the Red Hat internal instance instead)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
'sys.executable' can be used the same way it can upstream and then
hope that nobody does "pip install --upgrade" on a patched downstream
component :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
finding them
while there's time to submit fixes for them back upstream.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
lease
candidate in early December.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
On 5 October 2016 at 21:45, Tomas Orsava wrote:
> On 10/04/2016 03:10 PM, Nick Coghlan wrote:
>> I bring that up, as one of the other challenges with the way SCLs
>> currently work is that the upstream convention of copying
>> "sys.executable" into the shebang to
On 3 October 2016 at 23:36, Tomas Orsava wrote:
> On 09/27/2016 08:43 AM, Nick Coghlan wrote:
>>>
>>> P.P.S. I realize rh-python34 is available on RHSCL, but it didn't seem to
>>> support "python3" in scripts...
>>
>> Script sheban
a
wrapper script that implicitly enables the SCL, rather than just being
a symlink to the SCL's Python executable. I don't recall the exact
incantation myself, but hopefully someone else will be able to chime
in with that.
Cheers,
Nick.
--
Nick Coghlan | n
On 7 September 2016 at 19:30, Tomas Orsava wrote:
> On 09/06/2016 08:25 PM, Nick Coghlan wrote:
>> Very interesting, although I see a pragmatic problem with trying to
>> check for explicitly missing packages only after checking for the
>> standard library ones: the default
git.
+1 that sounds like an excellent idea :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
ry on
sys.path, and then defining a custom path_hook to process it:
https://docs.python.org/3/reference/import.html#path-entry-finders
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
mux.
If we pitched something like that, then rather than distros having to
agree on which level of configurability was appropriate, we'd just
have to agree on "if we implement that tier, we're happy to abide by
those guidelines", and then it would be up to individual distros
On 1 September 2016 at 22:04, Avram Lubkin wrote:
>
> On Thu, Sep 1, 2016 at 7:44 AM, Nick Coghlan wrote:
>>
>>
>> The ideal point we'd like to get to is one where all distro provided
>> scripts actually have the appropriate major version in their shebang
>&
t to the distro recommendations in
PEP 394.
The nice thing about the design of pythonmux is that, if Python 2 is
installed, it will use it automatically in non-interactive mode for
maximum compatibility with existing scripts, but if only Python 3 is
available, it will implicitly try that, rath
curate the spec file by hand",
but they should also have to opt in to that, rather than having it as
the default (just as all deployed servers should be under
configuration management by default, and people have to turn that off
if they want their local modifications t
sk spec file
to me - Python 3.x cache files shouldn't be showing up in the Python
2.7 site-packages directory.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
software-management/rpm/pull/80
Is that the PR you intended to link? It doesn't seem to be related to
the problem of .egg-link files appearing in the RPM contents.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 18 August 2016 at 17:04, Miro Hrončok wrote:
> On 17.8.2016 19:04, Nick Coghlan wrote:
>> Nice! Would it make sense for us to have a "tox" section in the
>> sidebar at
>> https://developer.fedoraproject.org/tech/languages/python/python-installation.html
>>
copr.fedorainfracloud.org/coprs/g/python/python34/
>
> There is one remaining issue, but it should not block you form using the
> package.
>
> https://github.com/fedora-python/python34/issues/1
>
> Let me know how it works for you.
Nice! Would it make sense for us to have
file, it's just generating a new one based on the new
upstream metadata and the old supplemental metadata, and seeing if the
result still passes CI.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-dev
On 11 Aug 2016 23:48, "Petr Viktorin" wrote:
>
> Hello,
> As of now, http://fedora.portingdb.xyz shows that we are 50% done porting
Fedora packages to Python 3. This is a big magic milestone; if you're
looking for a reason to celebrate, this is it! :)
Very cool!
> Now, what's next?
> I can't spe
On 8 August 2016 at 20:04, Petr Viktorin wrote:
> On 08/08/2016 06:09 AM, Nick Coghlan wrote:
>
>> Elaborating a bit further on the nature of the proposed Rawhide
>> experiment, the cases we're trying to distinguish are:
>>
>> - it doesn't really matter, b
On 8 August 2016 at 13:10, Nick Coghlan wrote:
> Accordingly, what I propose we do is as follows:
>
> 1. Raise the concern in the F26 system-wide change proposal for migrating
> to Python 3.6
> 2. Apply the patch when the 3.6 beta releases are added to Fedora Rawhide
> 3. Dec
m() will fail noisily in those cases, so
you can either switch to the random module, or fix your entropy pool
seeding".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
ance
> team, and I'm generally interested Python in Fedora. Please let me in? :)
And here I'd been assuming you were already a member - welcome! :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
would tip the answer towards "Yes" :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
python-devel mailing list
python-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
On 23 February 2016 at 13:13, Toshio Kuratomi wrote:
> On Feb 22, 2016 6:15 PM, "Nick Coghlan" wrote:
> > Fedora 24 will be shipping with a C.UTF-8 locale:
> https://bugzilla.redhat.com/show_bug.cgi?id=902094
> >
> > Perhaps we should file an RFE with rpm and
1 - 100 of 195 matches
Mail list logo
