1. Release:        1

https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Using_the_.25.7B.3Fdist.7D_Tag

2. BuildRequires:  python-devel
BuildRequires:  python3-devel

Why python2 still being used?

3. LDFLAGS need to set as well: %?__global_ldflags

4. Try make -C for subdir building.

(In reply to Christopher Meng from comment #1)
> 1. Release:        1
> 
> https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Using_the_.25.7B.
> 3Fdist.7D_Tag

Fixed
8
> 2. BuildRequires:  python-devel
> BuildRequires:  python3-devel
> 
> Why python2 still being used?

Required during the build process:
python ../py/makeqstrdata.py build/genhdr/qstrdefs.preprocessed.h qstrdefsport.h > build/genhdr/qstrdefs.generated.h

> 3. LDFLAGS need to set as well: %?__global_ldflags

Fixed, but I'm now the build fails during linking.
http://koji.fedoraproject.org/koji/taskinfo?taskID=7095407
I'll look into it, but does it seem familiar to you?

> 4. Try make -C for subdir building

Fixed

New SRPM URL: http://mstuchli.fedorapeople.org/micropython-1.1.1-1.fc20.src.rpm

(In reply to Matej Stuchlik from comment #2)
> Fixed, but I'm now the build fails during linking.
> http://koji.fedoraproject.org/koji/taskinfo?taskID=7095407
> I'll look into it, but does it seem familiar to you?

Yes, because you are overriding the ldflags.

Also no hidden build:

mkdir -p build/genhdr
CPP ../py/qstrdefs.h
makeqstrdata ../py/qstrdefs.h qstrdefsport.h
../py/py-version.sh: line 4: git: command not found
Generating build/genhdr/py-version.h
mkdir -p build/py/
CC ../py/nlrx86.S
CC ../py/nlrx64.S
CC ../py/nlrthumb.S
CC ../py/nlrsetjmp.c
CC ../py/malloc.c
CC ../py/gc.c
CC ../py/qstr.c
CC ../py/vstr.c
CC ../py/unicode.c
CC ../py/mpz.c
CC ../py/lexer.c
CC ../py/lexerstr.c
CC ../py/lexerunix.c
CC ../py/parse.c
CC ../py/parsehelper.c
CC ../py/scope.c
CC ../py/compile.c
CC ../py/emitcommon.c
CC ../py/emitpass1.c
CC ../py/emitcpy.c
CC ../py/emitbc.c
CC ../py/asmx64.c
CC ../py/emitnative.c
CC ../py/asmthumb.c
CC ../py/emitnative.c
CC ../py/emitinlinethumb.c
CC ../py/formatfloat.c
CC ../py/parsenumbase.c
CC ../py/parsenum.c
CC ../py/emitglue.c
CC ../py/runtime.c
CC ../py/argcheck.c
CC ../py/map.c
CC ../py/obj.c
CC ../py/objarray.c
CC ../py/objbool.c
CC ../py/objboundmeth.c
CC ../py/objcell.c
CC ../py/objclosure.c
CC ../py/objcomplex.c
CC ../py/objdict.c
CC ../py/objenumerate.c
CC ../py/objexcept.c
CC ../py/objfilter.c
CC ../py/objfloat.c
CC ../py/objfun.c
CC ../py/objgenerator.c
CC ../py/objgetitemiter.c
CC ../py/objint.c
CC ../py/objint_longlong.c
CC ../py/objint_mpz.c
CC ../py/objlist.c
CC ../py/objmap.c
CC ../py/objmodule.c
CC ../py/objobject.c
CC ../py/objproperty.c
CC ../py/objnone.c
CC ../py/objnamedtuple.c
CC ../py/objrange.c
CC ../py/objset.c
CC ../py/objslice.c
CC ../py/objstr.c
CC ../py/objstringio.c
CC ../py/objtuple.c
CC ../py/objtype.c
CC ../py/objzip.c
CC ../py/opmethods.c
CC ../py/sequence.c
CC ../py/stream.c
CC ../py/binary.c
CC ../py/builtin.c
CC ../py/builtinimport.c
CC ../py/builtinevex.c
CC ../py/builtintables.c
CC ../py/modarray.c
CC ../py/modcollections.c
CC ../py/modgc.c
CC ../py/modio.c
CC ../py/modmath.c
CC ../py/modcmath.c
CC ../py/modmicropython.c
CC ../py/modstruct.c
CC ../py/modsys.c
CC ../py/vm.c
CC ../py/showbc.c
CC ../py/repl.c
CC ../py/smallint.c
CC ../py/pfenv.c
CC main.c
CC gccollect.c
CC input.c
CC file.c
CC modsocket.c
CC modos.c
CC modtime.c
CC modffi.c
LINK micropython
build/modffi.o: In function `ffifunc_call':
/builddir/build/BUILD/micropython-1.1.1/unix/modffi.c:331: undefined reference to `ffi_call'
build/modffi.o: In function `ffimod_close':
/builddir/build/BUILD/micropython-1.1.1/unix/modffi.c:163: undefined reference to `dlclose'
build/modffi.o: In function `ffimod_var':
/builddir/build/BUILD/micropython-1.1.1/unix/modffi.c:247: undefined reference to `dlsym'
build/modffi.o: In function `ffimod_make_new':
/builddir/build/BUILD/micropython-1.1.1/unix/modffi.c:262: undefined reference to `dlopen'
build/modffi.o: In function `mod_ffi_callback':
/builddir/build/BUILD/micropython-1.1.1/unix/modffi.c:217: undefined reference to `ffi_closure_alloc'
/builddir/build/BUILD/micropython-1.1.1/unix/modffi.c:228: undefined reference to `ffi_prep_cif'
/builddir/build/BUILD/micropython-1.1.1/unix/modffi.c:233: undefined reference to `ffi_prep_closure_loc'
build/modffi.o: In function `ffimod_func':
/builddir/build/BUILD/micropython-1.1.1/unix/modffi.c:173: undefined reference to `dlsym'
/builddir/build/BUILD/micropython-1.1.1/unix/modffi.c:191: undefined reference to `ffi_prep_cif'
build/modffi.o:(.rodata+0x0): undefined reference to `ffi_type_uint8'
build/modffi.o:(.rodata+0x1c): undefined reference to `ffi_type_uint32'
build/modffi.o:(.rodata+0x28): undefined reference to `ffi_type_uint32'
build/modffi.o:(.rodata+0x38): undefined reference to `ffi_type_pointer'
build/modffi.o:(.rodata+0x80): undefined reference to `ffi_type_sint8'
build/modffi.o:(.rodata+0x88): undefined reference to `ffi_type_double'
build/modffi.o:(.rodata+0x90): undefined reference to `ffi_type_float'
build/modffi.o:(.rodata+0x9c): undefined reference to `ffi_type_sint32'
build/modffi.o:(.rodata+0xa8): undefined reference to `ffi_type_sint32'
build/modffi.o:(.rodata+0xb8): undefined reference to `ffi_type_pointer'
build/modffi.o:(.rodata+0xc4): undefined reference to `ffi_type_pointer'
build/modffi.o:(.rodata+0xd0): undefined reference to `ffi_type_void'
collect2: error: ld returned 1 exit status
../py/mkrules.mk:75: recipe for target 'micropython' failed
make: Leaving directory '/builddir/build/BUILD/micropython-1.1.1/unix'
RPM build errors:
make: *** [micropython] Error 1

(In reply to Christopher Meng from comment #3)
> (In reply to Matej Stuchlik from comment #2)
> > Fixed, but I'm now the build fails during linking.
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=7095407
> > I'll look into it, but does it seem familiar to you?
> 
> Yes, because you are overriding the ldflags.

I don't think I follow, looking at the build log, LDFLAGS seem to be "-Wl,-z,relro  -lm -Wl,-Map=micropython.map,--cref", i.e. %?__global_ldflags followed by whatever is added in the Makefile, which seem alright to me. Maybe you missed that I'm using LDFLAGS_MOD="%?__global_ldflags"?
                                  ^^^

(In reply to Matej Stuchlik from comment #4)
> (In reply to Christopher Meng from comment #3)
> > (In reply to Matej Stuchlik from comment #2)
> > > Fixed, but I'm now the build fails during linking.
> > > http://koji.fedoraproject.org/koji/taskinfo?taskID=7095407
> > > I'll look into it, but does it seem familiar to you?
> > 
> > Yes, because you are overriding the ldflags.
> 
> I don't think I follow, looking at the build log, LDFLAGS seem to be
> "-Wl,-z,relro  -lm -Wl,-Map=micropython.map,--cref", i.e. %?__global_ldflags
> followed by whatever is added in the Makefile, which seem alright to me.
> Maybe you missed that I'm using LDFLAGS_MOD="%?__global_ldflags"?
>                                   ^^^

I don't know.

If revision 1 was built successfully, then rev 2 failed, it should be caused by ldflags.

But now you provide the rev 2 RPM with no %release tag bumped, I can't tell.

Anyway, fix it and then I will go ahead.

I've rebased the package to micropython 1.2, fixed an issue with cflags, added the ldflags and added a patch that stops git from being invoked during build.

new SRPM URL: http://mstuchli.fedorapeople.org/micropython-1.2-1.fc20.src.rpm

I will finish this in today or tomorrow.

1. I don't think it's a good idea to remove O2 from the cflags, you should contact upstream. (Use V=1 and report the issues)

2. The summary of this package should be: "Python for microcontrollers"

Upstream is up to version 1.4.4. Would be great to finish this. Matej, any plans for an update? Christopher, any plans to finish the review?

Also, what about the stdlib? It has separate sources, so should be built separately...

%license is now mandatory (https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text).

Is this still a thing?  If I get no response in a week, I'm going to submit my own review.

jdulaney's scratch build of micropython-1.2-1.fc23.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=11807116

jdulaney's scratch build of micropython-1.5-0.fc23.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=11807259

jdulaney's scratch build of micropython-1.5-0.fc23.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=11807362

jdulaney's scratch build of micropython-1.5-0.fc23.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=11807404

(In reply to John Dulaney from comment #10)
> Is this still a thing?  If I get no response in a week, I'm going to submit
> my own review.

I think you can go ahead. Nothing much has happened here in a long time.

What's the status here? John's last comment suggests a new review request would be incoming, but that doesn't appear to be the case as yet.

Context for my question is this Marketing Team ticket about creating updated Python talking points for Fedora Ambassadors: https://fedorahosted.org/marketing-team/ticket/219

Packaged MicroPython and the BBC micro:bit support in https://fedoraproject.org/wiki/Changes/Micro_Bit would potentially make good additions to that, but the first part of that depends on MicroPython actually being packaged (the second part doesn't, as that can work with building MicroPython directly from source)

So, I had some things to work through with upstream, and then got distracted.  Let me poke at that a bit.

*** This bug has been marked as a duplicate of bug 1323966 ***