from:"Matej Stuchlik"

Re: python-rpm-macros - splitting out the macros

2016-01-13 Thread Matej Stuchlik

- Original Message -
> From: "Orion Poplawski" 
> To: python-devel@lists.fedoraproject.org, python-ow...@fedoraproject.org, 
> python3-ow...@fedoraproject.org,
> "Development discussions related to Fedora" 
> Sent: Tuesday, January 12, 2016 11:42:13 PM
> Subject: python-rpm-macros - splitting out the macros
> 
> On 01/08/2016 11:27 AM, bugzi...@redhat.com wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1294904
> > 
> > Antonio Trande  changed:
> > 
> >What|Removed |Added
> > 
> >   Flags|fedora-review?  |fedora-review+
> > 
> > 
> > 
> > --- Comment #12 from Antonio Trande  ---
> > Package approved.
> > 
> 
> I still have heard nothing from the main python maintainers, and I'd like to
> get some kind of an ack for the following plan:
> 
> - Dropping the python3-pkgversion-macros package, replaced with
> python-srpm-macros from above and required by redhat-rpm-config (in Fedora)
> and epel-rpm-macros (in EPEL).
> 
> - Dropping the python-macros sub-package from python, replace by Requires:
> python-rpm-macros from above package.  python3 requires this as well.
> 
> - Dropping macros.python2 from python-devel, replaced with Requires:
> python2-rpm-macros from above package.
> 
> - Dropping macros.python3 from python3-devel, replaced with Requires:
> python3-rpm-macros from above package.
> 
> This achieves the goal of decoupling modifying/updating the python macros
> from
> updating the main python package, which has become a serious hindrance to
> developing new python rpm macros.
> 
> The reviewed package contains the Fedora macros.  macros will be changed on
> the EPEL branches.

Sorry for the late response -- extended vacation. :)

We're 100% behind this, it's been something that's been on our todo list for a
while now. :)

Matt

> I've requested a side tag to do the build in here -
> https://fedorahosted.org/rel-eng/ticket/6331
> 
> as I think the timing is tricky and the possibility of breaking the buildroot
> moderate.
> 
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301   http://www.nwra.com
> ___
> python-devel mailing list
> python-devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org
> 
___
python-devel mailing list
python-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: python-rpm-macros - splitting out the macros

2016-01-13 Thread Matej Stuchlik

- Original Message -
> From: "Orion Poplawski" 
> To: python-de...@lists.fedoraproject.org, python-ow...@fedoraproject.org, 
> python3-ow...@fedoraproject.org,
> "Development discussions related to Fedora" 
> Sent: Tuesday, January 12, 2016 11:42:13 PM
> Subject: python-rpm-macros - splitting out the macros
> 
> On 01/08/2016 11:27 AM, bugzi...@redhat.com wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1294904
> > 
> > Antonio Trande  changed:
> > 
> >What|Removed |Added
> > 
> >   Flags|fedora-review?  |fedora-review+
> > 
> > 
> > 
> > --- Comment #12 from Antonio Trande  ---
> > Package approved.
> > 
> 
> I still have heard nothing from the main python maintainers, and I'd like to
> get some kind of an ack for the following plan:
> 
> - Dropping the python3-pkgversion-macros package, replaced with
> python-srpm-macros from above and required by redhat-rpm-config (in Fedora)
> and epel-rpm-macros (in EPEL).
> 
> - Dropping the python-macros sub-package from python, replace by Requires:
> python-rpm-macros from above package.  python3 requires this as well.
> 
> - Dropping macros.python2 from python-devel, replaced with Requires:
> python2-rpm-macros from above package.
> 
> - Dropping macros.python3 from python3-devel, replaced with Requires:
> python3-rpm-macros from above package.
> 
> This achieves the goal of decoupling modifying/updating the python macros
> from
> updating the main python package, which has become a serious hindrance to
> developing new python rpm macros.
> 
> The reviewed package contains the Fedora macros.  macros will be changed on
> the EPEL branches.

Sorry for the late response -- extended vacation. :)

We're 100% behind this, it's been something that's been on our todo list for a
while now. :)

Matt

> I've requested a side tag to do the build in here -
> https://fedorahosted.org/rel-eng/ticket/6331
> 
> as I think the timing is tricky and the possibility of breaking the buildroot
> moderate.
> 
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301   http://www.nwra.com
> ___
> python-devel mailing list
> python-de...@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/python-de...@lists.fedoraproject.org
> 
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel]Re: Boostrapping a new architecture for EPEL

2015-11-27 Thread Matej Stuchlik

- Original Message -
> From: "Peter Robinson" 
> To: "EPEL Development List" 
> Sent: Wednesday, November 25, 2015 5:33:17 PM
> Subject: [EPEL-devel]Re: Boostrapping a new architecture for EPEL
> 
> >>> So it's been discussed a little about doing a EPEL bootstrap for new
> >>> architectures. We have a number of arches wanting to do this (ppc64le,
> >>> aarch64, i686, s390x). So ppc64le will be our first and this is an
> >>> overview of the process I'll be using to do it. Once it's complete
> >>> I'll do a better write up as I suspect some things will evolve as we
> >>> go on down the path.
> >>>
> >>> So the general overview of the process is:
> >>>
> >>> 1) add new builders to koji (ppc64le complete)
> >>> 2) create separate inherited build target and tag
> >>> (epel7-archbootstrap) with associated architecture
> >>> 3) run scratch builds in that target using the git commit hashes from
> >>> the latest builds in the epel7, epel7-testing and epel7-candidate tags
> >>> 4) For each scratch build completed, run mergeScratch(task_id)
> >>> 5) when all builds are complete enable the arch on the main epel7
> >>> target
> >>> 6) sign all new packages
> >>> 7) update bodhi, pkgdb, mash configs
> >>> 7) mirror out
> >>>
> >>> I have some scripts to do the above which I'll publish for reference
> >>> once I've cleaned them up a little.
> >>>
> >>> This process isn't perfect. The new arch builds may not have the exact
> >>> same build dependency NVRs because, at least in the case of ppc64le,
> >>> the first EL7 release with .el7 distags is 7.2 and obviously most of
> >>> epel7 is built against < 7.2. The mergeScratch koji API call imports
> >>> all the build logs which helps mitigate this from a debug PoV. There's
> >>> not really a good way to deal with this, and obviously once the new
> >>> arch is enabled they'll be the same moving forward. I don't see it as
> >>> an issue really, just making note of it here for reference.
> >>>
> >>> Looking at the current stable epel7 builds, as of a couple of days
> >>> ago, we have around 4763 source packages, of which 2686 are noarch
> >>> (and hence don't need to be rebuilt) and a touch under 2077 (2077 at
> >>> time of check) are arch dependent.
> >>>
> >>> Let me know of any queries, questions, concerns etc
> >>
> >> sounds sane :-) But how will be handled packages that require some
> >> boostrapping procedure - is a new combo of boostrap and final build
> >> required in existing EPEL (dist-git) or or will be the bootstrap build
> >> taken from the original EPEL bootstrap (built eg. against RHEL-7 Beta)
> >> and the current latest NVR will be then the final build?
> >>
> > Note that I have packages already built in my local ppc64le epel7
> > environment and
> > some could be used to help in bootstrap.
> 
> Sorry, that's not going to happen, but if you've got a list of package
> sets that need specific bootstrapping that would be useful.
> 

I'm wondering if [0] could be of any use for you. It's not quite ready for
a release, but it should hopefully make rebuilds (including bootstrapping)
a lot simpler (eventually, anyway :) ).

You tell the tool the names of packages you want to rebuild, where it should get
those packages from and where it should build them, and it builds them
it the right order, using what we call a "recipe" [1] to break a dep cycle
whenever it finds one.

If you think it could be helpful, I'll let the author know he should improve
the README. :)

Matt

[0] https://github.com/mcyprian/sclbuilder (please disregard the name, it's not
SCL specific :) )
[1] 
https://github.com/mcyprian/sclbuilder/blob/master/input_data/recipe1_py35.yml
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Python 3.5 for Fedora 23 in COPR

2015-11-13 Thread Matej Stuchlik

Hey folks,
a while ago I've created a COPR repo [0] with Python 3.5 for f23,
I haven't had any bug reports so far, so it should be OK to use.

You can install it with:

$ dnf copr enable -y mstuchli/Python3.5
$ dnf install -y python35-python3

Then you can use the python3.5 and pip3.5 executables.

Some more information is available at [1].

Enjoy!

[0] https://copr.fedoraproject.org/coprs/mstuchli/Python3.5/
[1] http://synfo.github.io/2015/11/13/Python-3.5-in-Fedora/ 
-- 
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 23 cloud image (and, for that matter, minimal anything) bloat

2015-09-22 Thread Matej Stuchlik

- Original Message -
> From: "Matthew Miller" 
> To: "Fedora Development List" 
> Sent: Monday, September 21, 2015 5:07:40 PM
> Subject: Fedora 23 cloud image (and, for that matter, minimal anything) bloat
> 
> Fedora-Cloud-Base-20141203-21.x86_64.qcow2:   151M
> Fedora-Cloud-Base-23_Beta-20150915.x86_64.qcow2:  275M
> 
> In just one year — 82% more awesome?
> 
> I'd really like this to stay below 200MB as a competitive threshold.
> Or, if we're going to be bigger than that, be bigger for REASONS, not
> just accretion.
> 
> tl;dr: grub2 is a lot to blame, but there seem to be some new
> questionable dep chains from systemd, and general dep growth across the
> board.
> 
> 
> Disk use at first boot:
> 
>   [f21]$ df -h  /
>   Filesystem  Size  Used Avail Use% Mounted on
>   /dev/vda120G  359M   19G   2% /
> 
>   [f23b]$ df -h  /
>   Filesystem  Size  Used Avail Use% Mounted on
>   /dev/vda120G  578M   19G   4% /
> 
> RPMs installed:
> 
>   [f21]$ rpm -qa | wc -l
>   226
> 
>   [f23b]$ rpm -qa | wc -l
>   264
> 
> Top 20 rpms by reported size:
> 
>   $ rpm -qa --qf '%{size} %{name}\n'|sort -nr|head -20
>   120417342 glibc-common
>   42307839 kernel-core
>   25000497 python-libs
>   22438155 systemd
>   14623272 coreutils
>   14000291 glibc
>   11282056 ruby-libs  # hey, at least we lost this
>   10845519 glib2
>   10593004 selinux-policy-targeted
>   9389116 cracklib-dicts  #
>   https://bugzilla.redhat.com/show_bug.cgi?id=865521
>   9078043 python-boto
>   8792531 util-linux
>   7084188 bash
>   6669884 gnupg2
>   5844544 yum
>   4893790 policycoreutils
>   3786564 file-libs
>   3540004 shadow-utils
>   3458312 groff-base  # who doesn't love groff?
>   2997717 tar
> 
> 
>   $ rpm -qa --qf '%{size} %{name}\n'|sort -nr|head -20
>   125195206 glibc-common
>   86298752 linux-firmware   # sadface, but hard
>   53291365 kernel-core
>   36004297 grub2-tools  # this is ridiculous
>   28453336 python3-libs # 13% growth
>   27233273 systemd  # 21% growth
>   16648994 grub2# *sigh*
>   14486819 glibc
>   14287847 coreutils# this package got _smaller!_
>   11143743 glib2
>   11129880 selinux-policy-targeted
>   9389116 cracklib-dicts
>   9261499 python3-boto
>   9237998 util-linux
>   9224255 fedora-logos  # this is also grub's fault.
>   7517574 gnupg2
>   7143418 bash
>   6574678 python3-pip   # :(
>   583 hwdata# this is ALSO grub's fault
>   5423400 xkeyboard-config  # really looks like a systemd dep chain
>   involving plymouth

When it comes to python3, one way to shave off ~9MiB from python3-libs, and
possibly quite a bit more overall, would be to not install both optimized and
unoptimized bytecode, as we do now, but just the unoptimized one (the 
performance
hit should be very small).

I'll look into if that could be done.

We could also move few things from -libs to -devel, possibly.

Matt

> Okay, let's look on disk:
> 
> 
>   [f21]$ sudo du -sh * 2>/dev/null|sort -h
>   [...]
>   36K home
>   40K root
>   228Krun
>   21M boot
>   22M etc
>   34M var
>   276Musr
> 
> 
>   [f23b]$ sudo du -sh * 2>/dev/null|sort -h
>   [...]
>   40K root
>   264Krun
>   16M etc
>   45M boot  # ugh
>   171Mvar   # oww
>   463Musr   # oww oww oww
> 
>   Breakdown:
>  
>- boot is mostly grub, but initramfs is also doubled
>- var: DNF cache is full of stuff! 123M... oh, hey, that wasn't
>  there when we booted. `df -h /` is now up to 702M. Maybe multiple
>  repos would help here, or some other more clever design. Does
>  every cloud image in the world _really_ need to replicate
>  dependency data so I can `dnf install
>  /usr/share/minetest/builtin/mainmenu/init_simple.lua`?
> 
>- usr:
> 
>   * linux-firmware is the biggest thing here
>   * python3 is another good chunk
>   * also kernel modules, but, eh, whatchagonnado
>   * oh, and of course, grub2.
>   
> --
> Matthew Miller
> 
> Fedora Project Leader
> --
> 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: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

2015-09-22 Thread Matej Stuchlik

- Original Message -
> From: "drago01" <drag...@gmail.com>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Sent: Tuesday, September 22, 2015 11:20:27 AM
> Subject: Re: Fedora 23 cloud image (and, for that matter, minimal 
> anything) bloat
> 
> On Tue, Sep 22, 2015 at 11:07 AM, Matej Stuchlik <mstuc...@redhat.com> wrote:
> > [...]
> > When it comes to python3, one way to shave off ~9MiB from python3-libs, and
> > possibly quite a bit more overall, would be to not install both optimized
> > and
> > unoptimized bytecode, as we do now, but just the unoptimized one (the
> > performance
> > hit should be very small).
> 
> How small is "very small" ? Have you measured it?
> I don't think 9MB of disk space is worth taking a performance hit for ...

The only difference between unoptimized and "optimized" bytecode should be that
the latter is missing all docstrings, has disable asserts and sets __debug__ to 
False,
I can't imagine this being significant, performance wise.

That said I do not plan on doing this before I measure the performance 
difference and
discuss it on python-sig and python-linux.

Also note that it's possibly not just 9MB. For instance python3-boto, also on 
this list, would
save 4.7MB, python3-pip 2.9MB. In general most python packages could go down in 
size by ~20-30%.

Matt

> --
> 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: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

2015-09-22 Thread Matej Stuchlik



- Original Message -
> From: "Ville Skyttä" <ville.sky...@iki.fi>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Sent: Tuesday, September 22, 2015 1:36:09 PM
> Subject: Re: Fedora 23 cloud image (and, for that matter, minimal 
> anything) bloat
> 
> On Tue, Sep 22, 2015 at 2:25 PM, Neal Gompa <ngomp...@gmail.com> wrote:
> > On Tue, Sep 22, 2015 at 5:36 AM, Matej Stuchlik <mstuc...@redhat.com>
> > wrote:
> >>
> >> Also note that it's possibly not just 9MB. For instance python3-boto, also
> >> on this list, would
> >> save 4.7MB, python3-pip 2.9MB. In general most python packages could go
> >> down in size by ~20-30%.
> >
> > However, this approach would break with Python 3.5 (where pyo data is
> > merged
> > into *.pyc data)
> 
> To be more precise, AFAIU there's no "merging", *.pyo goes away but in
> exchange there are actually two new optimized bytecode files,
> *.opt-1.pyc and *.opt-2.pyc: https://www.python.org/dev/peps/pep-0488/
> If you want to exclude them from packages, they should be there listed
> as %ghost so they're removed in case they get generated by something
> run with -O or -OO. Ditto *.pyo if you intend to exclude them from
> python < 3.5 packages.
> 
> Also, be careful with measuring space savings when working with *.pyo.
> It is a common case that *.pyc and *.pyo are identical, and when they
> are rpmbuild already hardlinks them.

That's really interesting, I've had no idea:

% find /usr/ -name "*.pyc" | wc -l
# All .pyc files
18376

% find /usr/ -name "*.pyc" -links +1 | wc -l
# .pyc files that are hard linked
15761

find /usr/ -name '*.pyc' -links 1 -print0 | du --files0-from=- -ch | tail -n1
# Total size of non-hardlinked .pyc files
65M total

If I'm correct here it looks like it wouldn't really be worth it.

> --
> 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: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

2015-09-22 Thread Matej Stuchlik

- Original Message -
> From: "Ville Skyttä" <ville.sky...@iki.fi>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Sent: Tuesday, September 22, 2015 2:43:33 PM
> Subject: Re: Fedora 23 cloud image (and, for that matter, minimal 
> anything) bloat
> 
> On Tue, Sep 22, 2015 at 3:32 PM, Matej Stuchlik <mstuc...@redhat.com> wrote:
> > - Original Message -
> >> From: "Ville Skyttä" <ville.sky...@iki.fi>
> >>
> >> Also, be careful with measuring space savings when working with *.pyo.
> >> It is a common case that *.pyc and *.pyo are identical, and when they
> >> are rpmbuild already hardlinks them.
> >
> > That's really interesting, I've had no idea:
> 
> BTW I just had a peek into some Arch Linux Python 3.5 packages, and it
> seems they contain *no* identical *.pyc and corresponding *.opt-1.pyc
> files. This is bad news wrt the hardlinking. I haven't found any
> *.opt-2.pyc files to play with, so I don't know what's the situation
> with them.

And sure enough:

 % rpm2cpio python3-libs-3.4.3-5.fc24.x86_64.rpm | cpio -idmv 2> /dev/null && 
du -ch usr/ | tail -n1
31M total

% rpm2cpio python3-libs-3.5.0-1.fc24.x86_64.rpm | cpio -idmv 2> /dev/null && du 
-ch usr/ | tail -n1
43M total

That's definitely not great.

> --
> 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: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

2015-09-22 Thread Matej Stuchlik

- Original Message -
> From: "Ville Skyttä" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, September 22, 2015 3:03:24 PM
> Subject: Re: Fedora 23 cloud image (and, for that matter, minimal 
> anything) bloat
> 
> On Tue, Sep 22, 2015 at 3:43 PM, Ville Skyttä  wrote:
> >
> > BTW I just had a peek into some Arch Linux Python 3.5 packages, and it
> > seems they contain *no* identical *.pyc and corresponding *.opt-1.pyc
> > files. This is bad news wrt the hardlinking. I haven't found any
> > *.opt-2.pyc files to play with, so I don't know what's the situation
> > with them.
> 
> Managed to fiddle around some more and looks like the above is a false
> concern, many *.pyc, *.opt-1.pyc and *.opt-2.pyc are identical.
> So, https://github.com/rpm-software-management/rpm/pull/16

Is it? See my next email, Python 3.5.0 RPM seems ~50% bigger right now, unless
I'm making some silly mistake, and from what I see *.opt-2.pyc is nearly always
different from the other ones.

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

Fedora Badge for Python 3 Efforts

2015-08-04 Thread Matej Stuchlik

Hey folks,
in connection with the Python 3 as the Default Implementation change [0],
we're giving out badges [1] for helping making Fedora speak Python 3.
Therefore, if you have added Python 3 support to 3 or more packages since
f20, or if you have made significant contributions towards the Change, please
let rkuska, bkabrda or me know, and you'll get your badge. :)

Matt

[0] https://fedoraproject.org/wiki/Changes/Python_3_as_Default
[1] https://badges.fedoraproject.org/badge/parselmouth
-- 
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: Mass bug filing proposal - switching to Python3

2015-07-02 Thread Matej Stuchlik

- Original Message -
 From: Miroslav Suchý msu...@redhat.com
 To: devel@lists.fedoraproject.org
 Sent: Thursday, July 2, 2015 11:30:22 AM
 Subject: Re: Mass bug filing proposal - switching to Python3

 Dne 1.7.2015 v 15:33 Robert Kuska napsal(a):
  I would like to start with Mass bug filing process and as stated
  at wiki, the first step is to gain consensus for what I want to make.

 I maintain several python applications, but not all python libraries are
 available for python3 yet.
 Just few weeks ago I filed BZ please provide python3 subpackage for several
 libraries as the python3 subpackage
 neither exist yet nor it was reported yet.

 Can you rather file BZs for all python libraries which does not provide
 python3 library yet? And start filing
 application BZs only where all (or at least most) libraries will support
 python3.

I believe Robert's point is that once a bug is filled on an application,
it is the application's maintainer's obligation to file any additional bugs
that may be needes (Please let me know, if I understand it incorrectly, Robert).

That said, I tend to agree that filing against both all applications and modules
may be preferable, since we want as many packages as possible to support Python 
3.

Matt

 For example absence of python3 support in ansible modules and
 python-openstackclient is real blocker for me.

 --
 Miroslav Suchy, RHCA
 Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
 --
 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: [EPEL-devel] EpSCO Meeting Agenda: 06-Mar-2015 17:00 UTC

2015-03-20 Thread Matej Stuchlik

Hey,
I've unfortunately had other things on my plate, but this is now on the top,
so I'll get things moving. :)

Cheers,
Matt

- Original Message -
 From: Bohuslav Kabrda bkab...@redhat.com
 To: Stephen John Smoogen smo...@gmail.com
 Cc: epel-devel@lists.fedoraproject.org, epel-us...@lists.fedoraproject.org, 
 Matej Stuchlik mstuc...@redhat.com
 Sent: Friday, March 6, 2015 10:39:38 AM
 Subject: Re: EpSCO Meeting Agenda: 06-Mar-2015 17:00 UTC

 - Original Message -

  Sorry for the delay in getting this out. We will be continuing the EPEL
  Python discussion

  We will be in #epel on Freenode for our weekly EPEL Steering
  Committee meeting Friday 06-Mar-2015 at 17:00 UTC.

  Proposed Agenda items:

  1.) Python 3.X Discussion
  - Dual stack support?
  - Macros?
  - How can people help?

 Hi, I'm sorry but I won't be able to attend today's meeting for some personal
 reasons that appeared suddenly. I believe the proposal is in a good shape
 and most pressing concerns have been discussed on the ML. If any more are
 concerns are voiced on the meeting, I'll try to handle them during next
 Monday.
 Also, since I've been in a huge time press lately, I'd like to pass ownership
 of this proposal to someone else during next week or week after that. One of
 my colleagues, Matej Stuchlik (CCed), has expressed an interest and would be
 willing to take this - that's unless someone else who's participated up
 until now wants to take it.
 I'll still be around doing suggestions and trying to help, I just don't have
 the time to really drive this effort and do all the hard work. I'll try to
 ask Matej to come to the meeting, assuming he has the time today.

 Thanks for understanding,
 Slavek

  2) Keep the meeting at the same UTC time? [I would like to do so.]

  3) Open Floor / Other Items

  --
  Stephen J Smoogen.

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

Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22

2015-02-11 Thread Matej Stuchlik

 python3-3.4.2-3.fc22.src.rpm
   build started failing with http://gcc.gnu.org/PR60517
   The code has an undefined behavior (returning address of a local 
 variable);
   it
   tried to perform a stack overflow, but the compiler turned the code via 
 tail
   recursion
   optimization into an endless loop.

Would you have a buildlog of the failure available somewhere? I've tried to 
rebuild it [1]
and it seems to pass just fine.

Thanks,
Matt

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=8893808
-- 
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: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22

2015-02-11 Thread Matej Stuchlik

- Original Message -
 From: Jakub Jelinek ja...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Cc: Marek Polacek mpola...@redhat.com
 Sent: Wednesday, February 11, 2015 12:53:18 PM
 Subject: Re: Results of a test mass rebuild of rawhide/x86_64 with
 gcc-5.0.0-0.5.fc22

 On Wed, Feb 11, 2015 at 06:25:10AM -0500, Matej Stuchlik wrote:
   python3-3.4.2-3.fc22.src.rpm
 build started failing with http://gcc.gnu.org/PR60517
 The code has an undefined behavior (returning address of a local
 variable);
 it
 tried to perform a stack overflow, but the compiler turned the code via
 tail
 recursion
 optimization into an endless loop.

  Would you have a buildlog of the failure available somewhere? I've tried to
  rebuild it [1]
  and it seems to pass just fine.

 You've verified it rebuilt on i686.  You've also got it stuck forever in
 endless loop on x86_64 [1].

Ow, my bad, I assumed it would pass on x86_64 as well. Thanks for pointing that 
out.

  [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=8893808

   Jakub
 --
 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: [python] Add python2_version_nodots macro

2014-11-18 Thread Matej Stuchlik

I think this is more of a problem with unclear macro names. As we currently
use them (e.g. [0]) and as they were intended [1], both python2_version and
python2_version_nodots are supposed to contain major and minor version numbers
only, which they do and as far as I can see will continue to do so even if 
micro  9.

It's true that they would stop working if the minor version ever got to  9 
however,
so I'll change the definition as you advise, using version_info, just without 
the leading
zero. :)

Thanks for noticing this!
Matt

[0] from python-click.spec:
PYTHONPATH=$(pwd) py.test-%{python2_version} tests --tb=long --verbose

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


- Original Message -
 From: Nick Coghlan ncogh...@redhat.com
 To: Fedora Python SIG python-devel@lists.fedoraproject.org
 Sent: Monday, November 17, 2014 5:17:48 AM
 Subject: Re: [python] Add python2_version_nodots macro
 
 On 11/14/2014 12:05 AM, Matej Stuchlik wrote:
  commit 6875a63831616c6c8e722632e24faaa1a09cc831
  Author: Matej Stuchlik mstuc...@redhat.com
  Date:   Thu Nov 13 15:04:28 2014 +0100
  
  Add python2_version_nodots macro
  
   macros.python2 |1 +
   python.spec|5 -
   2 files changed, 5 insertions(+), 1 deletions(-)
  ---
  diff --git a/macros.python2 b/macros.python2
  index 982b51f..d090296 100644
  --- a/macros.python2
  +++ b/macros.python2
  @@ -2,3 +2,4 @@
   %python2_sitelib %(%{__python2} -c from distutils.sysconfig import
   get_python_lib; print(get_python_lib()))
   %python2_sitearch %(%{__python2} -c from distutils.sysconfig import
   get_python_lib; print(get_python_lib(1)))
   %python2_version %(%{__python2} -c import sys;
   sys.stdout.write(sys.version[:3]))
  +%python2_version_nodots %(%{__python2} -c import sys;
  sys.stdout.write(sys.version[:3].replace('.','')))
 
 I just saw this commit go by on python-owners.
 
 These macros are going to fail when Python 2.7.10 is released next year.
 Anything currently depending on the new no dots version in particular
 may also fail when it moves from 3 digits to 4 (since 2710 sorts
 lexically lower than 279).
 
 The version with dots can be fixed by using
 '.'.join(sys.version_info[:3]) instead of ignoring the explicit Do
 not extract version information out of it guidance for sys.version.
 
 The version without dots can be addressed by including the leading zero:
 {0.major}{0.minor}{0.micro:02d}.format(sys.version_info)
 
 Cheers,
 Nick.
 
 --
 Nick Coghlan
 Red Hat Hosted  Shared Services
 Software Engineering  Development, Brisbane
 
 HSS Provisioning Architect
 ___
 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: Python 3.4 to rawhide

2014-05-12 Thread Matej Stuchlik

Thanks for the tip, did just that.

- Original Message -
 From: Miro Hrončok mhron...@redhat.com
 To: Fedora Python SIG python-de...@lists.fedoraproject.org, Development 
 discussions related to Fedora
 devel@lists.fedoraproject.org
 Sent: Friday, May 9, 2014 1:10:40 PM
 Subject: Re: Python 3.4 to rawhide

 I'd say ask releng for help and mass rebuild everything unless satisfied.

 Dne 9.5.2014 11:45, Matej Stuchlik napsal(a):
  What are you trying to rebuild? I think what you are getting is expected,
  since python-six is not yet rebuild against Python 3.4 in the tag.

  Sorry if this is not going as fast as it could, I've never done this
  sort of a mass rebuild before, still learning the ropes.

  Matt

  - Original Message -
  From: Orion Poplawski or...@cora.nwra.com
  To: Development discussions related to Fedora
  devel@lists.fedoraproject.org, Fedora Python SIG
  python-de...@lists.fedoraproject.org
  Sent: Thursday, May 8, 2014 11:28:16 PM
  Subject: Re: Python 3.4 to rawhide

  On 04/30/2014 04:22 AM, Matej Stuchlik wrote:
  Good day folks,
  Python 3.4 is now [ready and tagged] in f21-python, so I'd like to ask
  you
  to make whatever modifications that may be necessary and [rebuild] your
  Python packages into the tag. Once we have sufficient fraction up and
  running,
  we'll merge with rawhide.

  Note that your spec file may require slight tweaks due to some file
  suffixes
  changing:
  * bytecode files from .cpython-33.py[co] to .cpython-34.py[co]
  * extension modules from .cpython-33m.so to .cpython-34m.so and
 .cpython-33dm.so to .cpython-34dm.so

  There's also an upstream guide to [porting to Python 3.4] you may find
  helpful.

  Finally, should you need help with your package, feel free to contact me
  and
  I'll do my best to help... :)

  Matt

  [ready and tagged]
  http://koji.fedoraproject.org/koji/taskinfo?taskID=6794120
  [rebuild] with fedpkg build --target f21-python
  [porting to Python 3.4]
  https://docs.python.org/dev/whatsnew/3.4.html#porting-to-python-3-4

  Looks like the f21-python buildroot is hosed.  I can't build anything.
  SRPM
  builds are failing with:

  DEBUG util.py:281:  Error: Package: python3-six-1.6.1-1.fc21.noarch
  (build)
  DEBUG util.py:281: Requires: python(abi) = 3.3
  DEBUG util.py:281: Installing: python-2.7.6-6.fc21.armv7hl
  (build)
  DEBUG util.py:281: python(abi) = 2.7
  DEBUG util.py:281: python(abi) = 2.7
  DEBUG util.py:281: Available: python3-3.4.0-3.fc21.armv7hl
  (build)
  DEBUG util.py:281: python(abi) = 3.4
  DEBUG util.py:281: python(abi) = 3.4

  --
  Orion Poplawski
  Technical Manager 303-415-9701 x222
  NWRA, Boulder/CoRA Office FAX: 303-415-9702
  3380 Mitchell Lane   or...@nwra.com
  Boulder, CO 80301   http://www.nwra.com
  --
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel
  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
  ___
  python-devel mailing list
  python-de...@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/python-devel

 --
 Miro Hrončok
 --
 Phone: +420777974800
 IRC: mhroncok
 ___
 python-devel mailing list
 python-de...@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/python-devel
-- 
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.4 to rawhide

2014-05-12 Thread Matej Stuchlik

Neat! Thanks a lot Orion. :)
We've started working on getting all the necessary dependencies of 
Sphinx/Pillow in.

- Original Message -
 From: Orion Poplawski or...@cora.nwra.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org, Fedora Python SIG
 python-de...@lists.fedoraproject.org, 
 python-docutils-ow...@fedoraproject.org
 Sent: Sunday, May 11, 2014 6:40:54 AM
 Subject: Re: Python 3.4 to rawhide

 On 05/09/2014 09:57 PM, Orion Poplawski wrote:
  On 04/30/2014 04:22 AM, Matej Stuchlik wrote:
  Good day folks,
  Python 3.4 is now [ready and tagged] in f21-python, so I'd like to ask you
  to make whatever modifications that may be necessary and [rebuild] your
  Python packages into the tag. Once we have sufficient fraction up and
  running,
  we'll merge with rawhide.

  Note that your spec file may require slight tweaks due to some file
  suffixes
  changing:
  * bytecode files from .cpython-33.py[co] to .cpython-34.py[co]
  * extension modules from .cpython-33m.so to .cpython-34m.so and
.cpython-33dm.so to .cpython-34dm.so

  There's also an upstream guide to [porting to Python 3.4] you may find
  helpful.

  Finally, should you need help with your package, feel free to contact me
  and
  I'll do my best to help... :)

  Matt

  [ready and tagged]
  http://koji.fedoraproject.org/koji/taskinfo?taskID=6794120
  [rebuild] with fedpkg build --target f21-python
  [porting to Python 3.4]
  https://docs.python.org/dev/whatsnew/3.4.html#porting-to-python-3-4

  I've been rebuilding some things today.  I'm ending today with docutils
  failing.  Haven't looked at the porting guide yet.  Maybe someone else
  will have time to take a look.

 Updating to current svn trunk allows the test to complete so
 python-docutils has now be rebuilt with 3.4.

 --
 Orion Poplawski
 Technical Manager 303-415-9701 x222
 NWRA/CoRA DivisionFAX: 303-415-9702
 3380 Mitchell Lane  or...@cora.nwra.com
 Boulder, CO 80301  http://www.cora.nwra.com
 ___
 python-devel mailing list
 python-de...@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/python-devel
-- 
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.4 to rawhide

2014-05-09 Thread Matej Stuchlik

What are you trying to rebuild? I think what you are getting is expected,
since python-six is not yet rebuild against Python 3.4 in the tag.

Sorry if this is not going as fast as it could, I've never done this
sort of a mass rebuild before, still learning the ropes.

Matt

- Original Message -
 From: Orion Poplawski or...@cora.nwra.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org, Fedora Python SIG
 python-de...@lists.fedoraproject.org
 Sent: Thursday, May 8, 2014 11:28:16 PM
 Subject: Re: Python 3.4 to rawhide
 
 On 04/30/2014 04:22 AM, Matej Stuchlik wrote:
  Good day folks,
  Python 3.4 is now [ready and tagged] in f21-python, so I'd like to ask you
  to make whatever modifications that may be necessary and [rebuild] your
  Python packages into the tag. Once we have sufficient fraction up and
  running,
  we'll merge with rawhide.
 
  Note that your spec file may require slight tweaks due to some file
  suffixes
  changing:
  * bytecode files from .cpython-33.py[co] to .cpython-34.py[co]
  * extension modules from .cpython-33m.so to .cpython-34m.so and
 .cpython-33dm.so to .cpython-34dm.so
 
  There's also an upstream guide to [porting to Python 3.4] you may find
  helpful.
 
  Finally, should you need help with your package, feel free to contact me
  and
  I'll do my best to help... :)
 
  Matt
 
  [ready and tagged]
  http://koji.fedoraproject.org/koji/taskinfo?taskID=6794120
  [rebuild] with fedpkg build --target f21-python
  [porting to Python 3.4]
  https://docs.python.org/dev/whatsnew/3.4.html#porting-to-python-3-4
 
 
 
 Looks like the f21-python buildroot is hosed.  I can't build anything.  SRPM
 builds are failing with:
 
 DEBUG util.py:281:  Error: Package: python3-six-1.6.1-1.fc21.noarch (build)
 DEBUG util.py:281: Requires: python(abi) = 3.3
 DEBUG util.py:281: Installing: python-2.7.6-6.fc21.armv7hl
 (build)
 DEBUG util.py:281: python(abi) = 2.7
 DEBUG util.py:281: python(abi) = 2.7
 DEBUG util.py:281: Available: python3-3.4.0-3.fc21.armv7hl
 (build)
 DEBUG util.py:281: python(abi) = 3.4
 DEBUG util.py:281: python(abi) = 3.4
 
 
 --
 Orion Poplawski
 Technical Manager 303-415-9701 x222
 NWRA, Boulder/CoRA Office FAX: 303-415-9702
 3380 Mitchell Lane   or...@nwra.com
 Boulder, CO 80301   http://www.nwra.com
 --
 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

Python 3.4 to rawhide

2014-04-30 Thread Matej Stuchlik

Good day folks,
Python 3.4 is now [ready and tagged] in f21-python, so I'd like to ask you
to make whatever modifications that may be necessary and [rebuild] your
Python packages into the tag. Once we have sufficient fraction up and running,
we'll merge with rawhide.

Note that your spec file may require slight tweaks due to some file suffixes
changing:
* bytecode files from .cpython-33.py[co] to .cpython-34.py[co]
* extension modules from .cpython-33m.so to .cpython-34m.so and
  .cpython-33dm.so to .cpython-34dm.so

There's also an upstream guide to [porting to Python 3.4] you may find helpful.

Finally, should you need help with your package, feel free to contact me and
I'll do my best to help... :)

Matt

[ready and tagged] http://koji.fedoraproject.org/koji/taskinfo?taskID=6794120
[rebuild] with fedpkg build --target f21-python
[porting to Python 3.4] 
https://docs.python.org/dev/whatsnew/3.4.html#porting-to-python-3-4
-- 
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: How to escape question mark / equality sign in spec's source URI to get proper source name

2013-11-14 Thread Matej Stuchlik

- Original Message -
From: Mathieu Bridon boche...@fedoraproject.org
To: Development discussions related to Fedora devel@lists.fedoraproject.org
Sent: Thursday, November 14, 2013 11:12:21 AM
Subject: Re: How to escape question mark / equality sign in spec's source   
URI to get proper source name

On Thu, 2013-11-14 at 05:01 -0500, Jan Lieskovsky wrote:
 Hello guys,

  I have one source which has the form of (in the last part of it's URI):
   checklist-cce-feed?id=295 (the source doesn't seem to be available 
 otherwise
 than via aforementioned query string - or at least I wasn't able to obtain
 it's final location past the query = if you known there's a way how to find
 out the final file location past the query string would be expanded, let me 
 know).

 For now I present that source URI in the particular spec in it's original 
 form
 (including the query string to avoid rpmlint to complain about non-existing
 source, and later in the %install moving that source to some more meaningful
 name). This works on RHEL5 (maybe question mark / equality sign not having
 special meaning there yet?), but not for example at Fedora-19.

  At Fedora 19 rpmbuild strips off the part till equality sign, iow
 checklist-cce-feed?id= from the source and searches only for '295' =
 rpmbuild fails with a complain not being able to find rpmbuild/SOURCES/295
 file.

Maybe use only the name of the source file, and add a comment above
explaining that it comes from that URL?

You can use checklist-cce-feed?id=295#nameofthesource.tar.bz2, but I'd say ^ 
is
the best idea.

Matt

-- 
Mathieu

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

Self Introduction

2013-03-29 Thread Matej Stuchlik

Hi there!
Similarly to my colleague, Mr Kruska, I, too, study Masaryk University in Brno, 
currently pursuing a bachelor's degree in computer science, and I, too, have 
recently joined Red Hat as an Associate Software Engineer in the Base OS team 
and as such I'll try my best to help you guys with some of the python packages. 
:)

Best regards,
Matej Stuchlik
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: python-rpm-macros - splitting out the macros

Re: python-rpm-macros - splitting out the macros

[EPEL-devel]Re: Boostrapping a new architecture for EPEL

Python 3.5 for Fedora 23 in COPR

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

Re: Fedora 23 cloud image (and, for that matter, minimal anything) bloat

Fedora Badge for Python 3 Efforts

Re: Mass bug filing proposal - switching to Python3

Re: [EPEL-devel] EpSCO Meeting Agenda: 06-Mar-2015 17:00 UTC

Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22

Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22

Re: [python] Add python2_version_nodots macro

Re: Python 3.4 to rawhide

Re: Python 3.4 to rawhide

Re: Python 3.4 to rawhide

Python 3.4 to rawhide

Re: How to escape question mark / equality sign in spec's source URI to get proper source name

Self Introduction

21 matches

Site Navigation

Mail list logo

Footer information