Bug 1327994 - Re-Review Request: python-jupyter-core - Jupyter core package. A base package on which Jupyter projects rely
Summary: Re-Review Request: python-jupyter-core - Jupyter core package. A base package...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jonathan Underwood
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 1242709 (view as bug list)
Depends On:
Blocks: 1243249 1327989
TreeView+ depends on / blocked
 
Reported: 2016-04-18 08:24 UTC by Thomas Spura
Modified: 2016-08-14 15:38 UTC (History)
7 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2016-08-14 15:38:13 UTC
jonathan.underwood: fedora-review+


Attachments (Terms of Use)
tweaks to the spec file (4.04 KB, patch)
2016-04-18 17:21 UTC, Zbigniew Jędrzejewski-Szmek
no flags Details | Diff

Description Thomas Spura 2016-04-18 08:24:37 UTC
Spec URL: https://tomspur.fedorapeople.org/review/python-jupyter-core/python-jupyter-core.spec
SRPM URL: https://tomspur.fedorapeople.org/review/python-jupyter-core/python-jupyter-core-4.1.0-1.fc23.src.rpm
Description:

This package provides basic functionality for Jupyter projects.
There is no reason to install this package on its own.

Fedora Account System Username: tomspur

Comment 1 Jonathan Underwood 2016-04-18 10:41:02 UTC
Currently building under mock fails during sphinx run to build docs:

running build
running build_py
running build_scripts
creating build/scripts-3.5
copying and adjusting scripts/jupyter-migrate -> build/scripts-3.5
copying and adjusting scripts/jupyter -> build/scripts-3.5
changing mode of build/scripts-3.5/jupyter-migrate from 644 to 755
changing mode of build/scripts-3.5/jupyter from 644 to 755
+ sphinx-build docs html
Running Sphinx v1.3.1
making output directory...
Exception occurred:
  File "conf.py", line 57, in <module>
ImportError: No module named jupyter_core.version
The full traceback has been saved in /tmp/sphinx-err-WWBsUl.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
error: Bad exit status from /var/tmp/rpm-tmp.F8mFeT (%build)
    Bad exit status from /var/tmp/rpm-tmp.F8mFeT (%build)
RPM build errors:

Comment 2 Mairi Dulaney 2016-04-18 13:56:52 UTC
Setting to assigned and ccing

Comment 3 Zbigniew Jędrzejewski-Szmek 2016-04-18 17:21 UTC
Created attachment 1148257 [details]
tweaks to the spec file

I wanted to try the review of python-jupyter-client, so I needed this to build :)

The fix for the missing module is simple enough (add PYTHONPATH).

I also modified the installation procedure to link jupyter → jupyter-2 → jupyter-2.7, jupyter-3 → jupyter-3.5 (with cp one of those symlinks would be real files instead)

Also %license.

Some more things I'd change:

I think the package should be renamed to python-jupyter-core. "use dashes in preference to underscores." [https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming].

Summary should not repeat the package name, and should not be a sentence. And the %description could be extended to say what this package actually does.

Comment 4 Thomas Spura 2016-04-18 18:04:16 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> Created attachment 1148257 [details]
> tweaks to the spec file
> 
> I wanted to try the review of python-jupyter-client, so I needed this to
> build :)
> 
> The fix for the missing module is simple enough (add PYTHONPATH).
> 
> I also modified the installation procedure to link jupyter → jupyter-2 →
> jupyter-2.7, jupyter-3 → jupyter-3.5 (with cp one of those symlinks would be
> real files instead)
> 
> Also %license.

Thanks for the fixes!

> Some more things I'd change:
> 
> I think the package should be renamed to python-jupyter-core. "use dashes in
> preference to underscores."
> [https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming].

Fixed. Only did it in %name so far... Thanks for pointing it out!


> Summary should not repeat the package name, and should not be a sentence.
> And the %description could be extended to say what this package actually
> does.

New urls:
Spec URL: https://tomspur.fedorapeople.org/review/python-jupyter-core/python-jupyter-core.spec
SRPM URL: https://tomspur.fedorapeople.org/review/python-jupyter-core/python-jupyter-core-4.1.0-2.fc23.src.rpm

Comment 5 Mairi Dulaney 2016-04-18 18:22:31 UTC
You might want to remove the commented out lines.

Comment 6 Zbigniew Jędrzejewski-Szmek 2016-04-18 19:58:15 UTC
Summary?

Comment 7 Thomas Spura 2016-04-18 21:00:12 UTC
(In reply to John Dulaney from comment #5)
> You might want to remove the commented out lines.

I wanted to keep it in case jupyter-troubleshoot really exists as entry-point. But it can also be added later. -> removed

(In reply to Zbigniew Jędrzejewski-Szmek from comment #6)
> Summary?

Is "The base package for Jupyter projects" a better wording?

%changelog
- Remove references to jupyter-troubleshoot
- Improve summary
- Remove shebang from troubleshoot.py

Spec URL: https://tomspur.fedorapeople.org/review/python-jupyter-core/python-jupyter-core.spec
SRPM URL: https://tomspur.fedorapeople.org/review/python-jupyter-core/python-jupyter-core-4.1.0-3.fc23.src.rpm

Comment 8 Zbigniew Jędrzejewski-Szmek 2016-04-19 00:06:44 UTC
(In reply to Thomas Spura from comment #7)
> Is "The base package for Jupyter projects" a better wording?

Yes.

Comment 9 Jonathan Underwood 2016-04-19 12:38:01 UTC
OK, great, seems the flurry of activity has died down, so I'll continue to review.

Quick question: are there consumers of the python2 subpackage within the jupyter stack? If not, why don't we simply remove the python2 subpackage.

Comment 10 Thomas Spura 2016-04-19 13:00:42 UTC
You can use jupyter with either python2 or python3, so I think it makes sense to ship both until python2 will become no longer relevant. I _guess_ this will still take a few years (given that /usr/bin/python is still python2 ...).

Comment 11 Jonathan Underwood 2016-04-19 13:35:21 UTC
OK... what's actually going on here? We already have a package python-jupyter_core in Fedora which seems to be exactly this (although it's a point release behind).

Comment 12 Jonathan Underwood 2016-04-19 13:36:10 UTC
cc'ing Orion

Comment 13 Jonathan Underwood 2016-04-19 13:42:15 UTC
I'm pasting the review anyway, as hopefully it'll be of some use once this situation is resolved. In particular the rpmlint errors need investigation.


Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed



===== MUST items =====

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "BSD (3 clause)", "Unknown or generated". 39 files have unknown
     license. Detailed output of licensecheck in /home/jgu/Fedora/1327994
     -python-jupyter-core/licensecheck.txt
[x]: License file installed when any subpackage combination is installed.
[x]: Package requires other packages for directories it uses.
     Note: No known owner of /usr/lib/python3.5/site-packages,
     /usr/lib/python3.5
[x]: Package must own all directories that it creates.
     Note: Directories without known owners: /usr/lib/python3.5/site-
     packages, /usr/lib/python3.5
[!]: Package does not own files or directories owned by other packages.
     Note: Dirs in package are owned also by: /usr/lib/python2.7/site-
     packages/jupyter_core/tests(python-jupyter_core), /usr/lib/python2.7
     /site-packages/jupyter_core/utils(python-jupyter_core),
     /usr/lib/python2.7/site-packages/jupyter_core(python-jupyter_core)

Seems this package is already in Fedora!!!!

[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[!]: Package does not generate any conflict.

See above

[x]: Package obeys FHS, except libexecdir and /usr/target.
[!]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.

If this is actually intended by a package rename review, then this
needs addessing

[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 20480 bytes in 2 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %license.
[x]: All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

Python:
[x]: Python eggs must not download any dependencies during the build
     process.
[x]: A package which is used by another package via an egg interface should
     provide egg info.
[ ]: Package meets the Packaging Guidelines::Python
[x]: Package contains BR: python2-devel or python3-devel
[x]: Binary eggs must be removed in %prep

===== SHOULD items =====

Generic:
[x]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[x]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in python2
     -jupyter-core , python3-jupyter-core , python-jupyter-core-doc
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[!]: Spec file according to URL is the same as in SRPM.
     Note: Spec file as given by url is not the same as in SRPM (see
     attached diff).
     See: (this test has no URL)

Needs fixing!


[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).


Rpmlint
-------
Checking: python2-jupyter-core-4.1.0-3.fc25.noarch.rpm
          python3-jupyter-core-4.1.0-3.fc25.noarch.rpm
          python-jupyter-core-doc-4.1.0-3.fc25.noarch.rpm
          python-jupyter-core-4.1.0-3.fc25.src.rpm
python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-2
python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-2.7
python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter
python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-2.7
python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate
python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-2
python3-jupyter-core.noarch: E: python-bytecode-wrong-magic-value /usr/lib/python3.5/site-packages/jupyter_core/paths.pyc expected 3350 (3.5), found 62211 (2.7)
python3-jupyter-core.noarch: E: python-bytecode-wrong-magic-value /usr/lib/python3.5/site-packages/jupyter_core/__init__.pyc expected 3350 (3.5), found 62211 (2.7)
python3-jupyter-core.noarch: E: python-bytecode-wrong-magic-value /usr/lib/python3.5/site-packages/jupyter_core/version.pyc expected 3350 (3.5), found 62211 (2.7)


These look very worrying, suggests the wrong pyton interpreter has
been used for their generation?


python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-3.5
python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-3
python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-3.5
python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-3
4 packages and 0 specfiles checked; 3 errors, 10 warnings.




Rpmlint (installed packages)
----------------------------
python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-2
python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate
python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-2
python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-2.7
python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-2.7
python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter
python3-jupyter-core.noarch: E: python-bytecode-wrong-magic-value /usr/lib/python3.5/site-packages/jupyter_core/version.pyc expected 3350 (3.5), found 62211 (2.7)
python3-jupyter-core.noarch: E: python-bytecode-wrong-magic-value /usr/lib/python3.5/site-packages/jupyter_core/paths.pyc expected 3350 (3.5), found 62211 (2.7)
python3-jupyter-core.noarch: E: python-bytecode-wrong-magic-value /usr/lib/python3.5/site-packages/jupyter_core/__init__.pyc expected 3350 (3.5), found 62211 (2.7)


These look very worrying, suggests the wrong pyton interpreter has
been used for their generation?



python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-3
python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-3
python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-3.5
python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-3.5
3 packages and 0 specfiles checked; 3 errors, 10 warnings.



Diff spec file in url and in SRPM
---------------------------------
--- /home/jgu/Fedora/1327994-python-jupyter-core/srpm/python-jupyter-core.spec	2016-04-19 13:46:32.284247836 +0100
+++ /home/jgu/Fedora/1327994-python-jupyter-core/srpm-unpacked/python-jupyter-core.spec	2016-04-18 21:57:13.000000000 +0100
@@ -90,4 +90,5 @@
 # Remove shebang from troubleshoot.py
 for lib in %{buildroot}{%{python2_sitelib},%{python3_sitelib}}/jupyter_core/troubleshoot.py; do
+    ls $lib
     sed '1{\@^#!/usr/bin/env@d}' $lib > $lib.new &&
     touch -r $lib $lib.new &&


Requires
--------
python-jupyter-core-doc (rpmlib, GLIBC filtered):

python2-jupyter-core (rpmlib, GLIBC filtered):
    /usr/bin/python2
    python(abi)
    python-setuptools
    python-traitlets

python3-jupyter-core (rpmlib, GLIBC filtered):
    /usr/bin/python3
    python(abi)
    python3-setuptools
    python3-traitlets



Provides
--------
python-jupyter-core-doc:
    python-jupyter-core-doc

python2-jupyter-core:
    python-jupyter-core
    python2-jupyter-core

python3-jupyter-core:
    python3-jupyter-core



Source checksums
----------------
https://pypi.python.org/packages/source/j/jupyter_core/jupyter_core-4.1.0.tar.gz :
  CHECKSUM(SHA256) this package     : 146af0679c33c56db4b85b785f3dacd933ffaca97e7d2d56ff577a5485c2bd13
  CHECKSUM(SHA256) upstream package : 146af0679c33c56db4b85b785f3dacd933ffaca97e7d2d56ff577a5485c2bd13


Generated by fedora-review 0.6.0 (3c5c9d7) last change: 2015-05-20
Command line :/usr/bin/fedora-review -m fedora-rawhide-x86_64 -b 1327994
Buildroot used: fedora-rawhide-x86_64
Active plugins: Python, Generic, Shell-api
Disabled plugins: Java, C/C++, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP, Ruby
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6

Comment 14 Jonathan Underwood 2016-04-19 13:50:26 UTC
The optimal outcome here would be for Thomas to co-maintain the existing package and merge the changes back in (including updating to the most recent release).

It might also be a good idea to treat this as a package rename review, and remove the underscore from the package name. But this is not critical.

Comment 15 Orion Poplawski 2016-04-19 15:28:09 UTC
 I don't read the "prefer - to _" as a reason to change upstream's name, as I feel "follow upstream" trumps that.  So I would suggest keeping the existing python-jupyter_core package.  I've been completely neglectful of that though so I'd be happy to have anyone take it over.

Comment 16 Orion Poplawski 2016-04-19 15:39:45 UTC
Meh, it seems that moving to '-'s seems to be the way to go.  So yeah, let's treat this as a rename, so you'll need the appropriate obsoletes/provides if you don't already.

Comment 17 Jonathan Underwood 2016-04-22 10:56:27 UTC
Hi Thomas - any progress here?

Comment 18 Thomas Spura 2016-04-23 16:27:33 UTC
Thanks for the review!

Sorry, Orion, for missing your jupyter_core package...

Upstream is unfortunately not consistently using either jupyter_core or jupyter-core:
https://jupyter-core.readthedocs.org/en/latest/changelog.html

(In reply to Jonathan Underwood from comment #13)
> [!]: Package does not own files or directories owned by other packages.
>      Note: Dirs in package are owned also by: /usr/lib/python2.7/site-
>      packages/jupyter_core/tests(python-jupyter_core), /usr/lib/python2.7
>      /site-packages/jupyter_core/utils(python-jupyter_core),
>      /usr/lib/python2.7/site-packages/jupyter_core(python-jupyter_core)
> 
> Seems this package is already in Fedora!!!!
> [!]: Package does not generate any conflict.
> 
> See above
> 
> [!]: If the package is a rename of another package, proper Obsoletes and
>      Provides are present.
> 
> If this is actually intended by a package rename review, then this
> needs addessing

The obsoletes/provides of the existing package are added.

> ===== EXTRA items =====
> 
> Generic:
> [!]: Spec file according to URL is the same as in SRPM.
>      Note: Spec file as given by url is not the same as in SRPM (see
>      attached diff).
>      See: (this test has no URL)
> 
> Needs fixing!

Sorry, for the debug print in the spec. Removed and fixed.

> [x]: Rpmlint is run on all installed packages.
>      Note: There are rpmlint messages (see attachment).
> 
> 
> Rpmlint
> -------
> Checking: python2-jupyter-core-4.1.0-3.fc25.noarch.rpm
>           python3-jupyter-core-4.1.0-3.fc25.noarch.rpm
>           python-jupyter-core-doc-4.1.0-3.fc25.noarch.rpm
>           python-jupyter-core-4.1.0-3.fc25.src.rpm
> python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-2
> python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-2.7
> python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter
> python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-2.7
> python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate
> python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-2
> python3-jupyter-core.noarch: E: python-bytecode-wrong-magic-value
> /usr/lib/python3.5/site-packages/jupyter_core/paths.pyc expected 3350 (3.5),
> found 62211 (2.7)
> python3-jupyter-core.noarch: E: python-bytecode-wrong-magic-value
> /usr/lib/python3.5/site-packages/jupyter_core/__init__.pyc expected 3350
> (3.5), found 62211 (2.7)
> python3-jupyter-core.noarch: E: python-bytecode-wrong-magic-value
> /usr/lib/python3.5/site-packages/jupyter_core/version.pyc expected 3350
> (3.5), found 62211 (2.7)
> 
> 
> These look very worrying, suggests the wrong pyton interpreter has
> been used for their generation?

It seems %py2_build and %py3_build builds (and compiles) in ./build/ and python3 installs the pyc files, generated from python2.
Workaround at the beginning of %install:
find | grep pyc$ | xargs rm -v

This needs proper fixing in distutils...

> python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-3.5
> python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-3
> python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-3.5
> python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-3
> 4 packages and 0 specfiles checked; 3 errors, 10 warnings.
> 
> 
> 
> 
> Rpmlint (installed packages)
> ----------------------------
> python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-2
> python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate
> python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-2
> python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-2.7
> python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-2.7
> python2-jupyter-core.noarch: W: no-manual-page-for-binary jupyter
> python3-jupyter-core.noarch: E: python-bytecode-wrong-magic-value
> /usr/lib/python3.5/site-packages/jupyter_core/version.pyc expected 3350
> (3.5), found 62211 (2.7)
> python3-jupyter-core.noarch: E: python-bytecode-wrong-magic-value
> /usr/lib/python3.5/site-packages/jupyter_core/paths.pyc expected 3350 (3.5),
> found 62211 (2.7)
> python3-jupyter-core.noarch: E: python-bytecode-wrong-magic-value
> /usr/lib/python3.5/site-packages/jupyter_core/__init__.pyc expected 3350
> (3.5), found 62211 (2.7)
> 
> 
> These look very worrying, suggests the wrong pyton interpreter has
> been used for their generation?

Fixed above.

> python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-3
> python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-3
> python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-3.5
> python3-jupyter-core.noarch: W: no-manual-page-for-binary jupyter-migrate-3.5
> 3 packages and 0 specfiles checked; 3 errors, 10 warnings.
> 
> 
> 
> Diff spec file in url and in SRPM
> ---------------------------------
> ---
> /home/jgu/Fedora/1327994-python-jupyter-core/srpm/python-jupyter-core.spec
> 2016-04-19 13:46:32.284247836 +0100
> +++
> /home/jgu/Fedora/1327994-python-jupyter-core/srpm-unpacked/python-jupyter-
> core.spec	2016-04-18 21:57:13.000000000 +0100
> @@ -90,4 +90,5 @@
>  # Remove shebang from troubleshoot.py
>  for lib in
> %{buildroot}{%{python2_sitelib},%{python3_sitelib}}/jupyter_core/
> troubleshoot.py; do
> +    ls $lib
>      sed '1{\@^#!/usr/bin/env@d}' $lib > $lib.new &&
>      touch -r $lib $lib.new &&

Debug print removed.

%changelog
- Add obsoletes/provides for jupyter_core
- Fix python2 files installed with python3

Spec URL: https://tomspur.fedorapeople.org/review/python-jupyter-core/python-jupyter-core.spec
SRPM URL: https://tomspur.fedorapeople.org/review/python-jupyter-core/python-jupyter-core-4.1.0-4.fc23.src.rpm

Comment 19 Thomas Spura 2016-04-23 16:30:52 UTC
*** Bug 1242709 has been marked as a duplicate of this bug. ***

Comment 20 Jonathan Underwood 2016-04-24 18:02:15 UTC
OK, great. Obsoletes and Provides are sane and correct. All other problems fixed, so this is ready to go. Thanks for working on this. APPROVED.

Regarding this:

(In reply to Thomas Spura from comment #18)
> > python3-jupyter-core.noarch: E: python-bytecode-wrong-magic-value
> > /usr/lib/python3.5/site-packages/jupyter_core/paths.pyc expected 3350 (3.5),
> > found 62211 (2.7)
> > python3-jupyter-core.noarch: E: python-bytecode-wrong-magic-value
> > /usr/lib/python3.5/site-packages/jupyter_core/__init__.pyc expected 3350
> > (3.5), found 62211 (2.7)
> > python3-jupyter-core.noarch: E: python-bytecode-wrong-magic-value
> > /usr/lib/python3.5/site-packages/jupyter_core/version.pyc expected 3350
> > (3.5), found 62211 (2.7)
> > 
> > 
> > These look very worrying, suggests the wrong pyton interpreter has
> > been used for their generation?
> 
> It seems %py2_build and %py3_build builds (and compiles) in ./build/ and
> python3 installs the pyc files, generated from python2.
> Workaround at the beginning of %install:
> find | grep pyc$ | xargs rm -v
> 
> This needs proper fixing in distutils...

Have you filed a bug for that somewhere? It seems like this could be affecting a lot of packages in Fedora.

In the meantime, wouldn't it be a good idea for %py2_install and %py3_install to remove all pyc as their first action - after all bython byte compilation is done on the installed files automatically anyway. I'll file a bug against the pthon macros package, unless you beat me to it :)

Comment 21 Gwyn Ciesla 2016-04-25 13:20:00 UTC
Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/rpms/python-jupyter-core


Note You need to log in before you can comment on or make changes to this bug.