Re: Packages FTBFS with Python 3.6

[Igor Gnatenko]

On Wed, Dec 21, 2016 at 12:18 AM, Miro Hrončok <mhron...@redhat.com> wrote:
> Hi all,
> We've recently tried to rebuild all Python packages with Python 3.6.
> However, we currently have bunch of packages that simply fail to build.
>
> As the list contains >200 packages, it would be very helpful, if you
> (package maintainers) could help us solve the issues, as we cannot go one by
> one to investigate the issue.
>
> I've attached the list of failed packages (failed.txt). You can search Koji
> to find out, what went wrong. Sometimes, it's just  missing dependency. That
> dependency should be on this list as well. If it is not,  maybe we lost it,
> please tell us if that's the case. Maybe the dependency is circular and
> something needs to be bootstrapped. If you need provenpackager powers, let
> me know.
I've fixed python-smartcols and python-behave..

Attaching current rawhide/koji packages which depend on python 3.5
instead of 3.6 still.
-- 
-Igor Gnatenko
dnsyo
elastic-curator
gerrymander
google-api-python-client
graphite-api
hgsvn
lcgdm
libcec
libproxy
libuser
netstat-monitor
openwsman
pcs
pdc-client
python3-bsddb3
python3-cherrypy
python-acme
python-adal
python-beanbag
python-blosc
python-cassandra-driver
python-castellan
python-ceilometerclient
python-cerberus
python-characteristic
python-congressclient
python-cursive
python-deap
python-dill
python-django-admin-honeypot
python-django-avatar
python-django-countries
python-django-filter
python-django-formtools
python-django-jsonfield
python-django-model-utils
python-django-notifications-hq
python-django-openstack-auth
python-django-pyscss
python-fastimport
python-flask-migrate
python-flask-script
python-flower
python-gensim
python-gerritlib
python-hglib
python-k8sclient
python-kdcproxy
python-keystonemiddleware
python-lazr-smtptest
python-magnumclient
python-manilaclient
python-marrow-mailer
python-mdp
python-microversion-parse
python-more-itertools
python-moss
python-netdiff
python-nipy
python-openstacksdk
python-os-brick
python-osc-lib
python-os-client-config
python-oslo-cache
python-oslo-context
python-oslo-db
python-oslo-log
python-oslo-messaging
python-oslo-middleware
python-oslo-policy
python-oslo-reports
python-oslo-service
python-oslo-versionedobjects
python-oslo-vmware
python-photutils
python-profilehooks
python-prov
python-pyopencl
python-recommonmark
python-repoze-who-plugins-sa
python-rows
python-sphinxcontrib-programoutput
python-sphinxcontrib-spelling
python-statsd
python-structlog
python-swiftclient
python-tackerclient
python-tosca-parser
python-troveclient
rb_libtorrent
root
rpy
shogun
sympy

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

Re: LibRaw soname bump

[Igor Gnatenko]

On Wed, Dec 28, 2016 at 12:12 AM, Jon Ciesla <limburg...@gmail.com> wrote:
> 0.18.0 is coming.  I'm taking care of:
>
> efl
> entangle
> freeimage
> gegl03
> gthumb
> kf5-libkdcraw
> libkdcraw
> nomacs
> OpenImageIO
> oyranos
> shotwell
You missed some of packages:
* evas-generic-loaders
* fotoxx
* indi-gphoto
* krita
* kstars
* luminance-hdr
* photoqt
* siril
>
> If I missed something, let me know.
>
> --
> http://cecinestpasunefromage.wordpress.com/
> 
> in your fear, seek only peace
> in your fear, seek only love
>
> -d. bowie
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



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

scanmem lincese changes from GPLv2+ to GPLv3+ and LGPLv3+

[Igor Gnatenko]

Since 0.16 libscanmem is LGPLv3+ and the rest is GPLv3+.
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: cross-compiler support?

[Igor Gnatenko]

On Tue, Dec 20, 2016 at 12:59 AM, Laura Abbott <labb...@redhat.com> wrote:
> On 12/19/2016 02:59 PM, Igor Gnatenko wrote:
>> Hi,
>>
>> I found only one cross-compiler in repos -- arm-none-eabi-gcc-cs
>>
>> But it doesn't work:
>> This package is compiled in bootstrap mode and used only to solve circular
>> build dependency. You don't want to use this package. It's not expected to
>> work.
>>
>> In normal circumstances, you should not see bootstrap package in any
>> released Fedora.
>>
>> Do I miss something?
>>
>
> Well there is gcc-arm-linux-gnu for example but that's for kernels per
> description
Didn't see it before... But looks like it doesn't work either:
/usr/bin/arm-linux-gnu-ld: cannot find crt1.o: No such file or directory
/usr/bin/arm-linux-gnu-ld: cannot find crti.o: No such file or directory
/usr/bin/arm-linux-gnu-ld: cannot find -lc
/usr/bin/arm-linux-gnu-ld: cannot find crtn.o: No such file or directory
>
> $ dnf info gcc-arm-linux-gnu
> Installed Packages
> Name: gcc-arm-linux-gnu
> Arch: x86_64
> Epoch   : 0
> Version : 6.1.1
> Release : 2.fc24
> Size: 59 M
> Repo: @System
> From repo   : updates
> Summary : Cross-build binary utilities for arm-linux-gnu
> URL : http://gcc.gnu.org
> License : GPLv3+ and GPLv3+ with exceptions and GPLv2+ with exceptions and
> : LGPLv2+ and BSD
> Description : Cross-build GNU C compiler.
> :
> : Only building kernels is currently supported.  Support for
> : cross-building user space programs is not currently provided as
> : that would massively multiply the number of packages
> _______
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

cross-compiler support?

[Igor Gnatenko]

Hi,

I found only one cross-compiler in repos -- arm-none-eabi-gcc-cs

But it doesn't work:
This package is compiled in bootstrap mode and used only to solve circular
build dependency. You don't want to use this package. It's not expected to
work.

In normal circumstances, you should not see bootstrap package in any
released Fedora.

Do I miss something?
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Updated xmlrpc-c (1.47.1) is on the way

[Igor Gnatenko]

On Sun, Dec 18, 2016 at 3:27 PM, Alexander Bokovoy <aboko...@redhat.com> wrote:
> On su, 18 joulu 2016, Igor Gnatenko wrote:
>>
>> Unfortunately we stuck with very old (1.32.5, somewhere from 2012)
>> version of xmlrpc-c. I've rebased it to newer version (1.47.1, from
>> this month). It doesn't anymore use cmake (it was port from one of our
>> contributors, official buildsys is autoconf+gnumake) for building, now
>> it uses meson (you can see why in my blog[0]).
>>
>> * abrt
>> No problem for rebuild
>> * certmonger
>> FTBFS due to openssl1.1[1], though probably it should be retired
>> because looks like it's part of FreeIPA now
>
> Certmonger is a separate project and is a separate package. The fact
> that it is used by FreeIPA does not change the state of it.
>
>> * freeipa
>> No problem for rebuild
>
> Did you actually try to install/enroll IPA client with new xmlrpc-c?
> Last time the change happened due to CVE, GSSAPI authentication broke in
> xmlrpc-c and none of IPA clients were able to enroll. This was a major
> breakage.
Hmm.. I have not checked it, but before doing update/rebuilds will try
to spawn IPA server/client in VM and see whether it works. You can try
yourself as well from this repo:
https://copr.fedorainfracloud.org/coprs/ignatenkobrain/xmlrpc-c-rebase/
>
>
>> I will build new xmlrpc-c and rebuild dependent libraries this or next
>> week.
>>
>>
>> [0] https://blogs.gnome.org/ignatenko/2016/12/17/meson-%E2%99%A5-xmlrpc-c/
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1405790
>> [2] https://github.com/FreightAgent/freight-tools/issues/5
>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1385596
>
>
> --
> / Alexander Bokovoy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

[HEADS UP] Updated xmlrpc-c (1.47.1) is on the way

[Igor Gnatenko]

Unfortunately we stuck with very old (1.32.5, somewhere from 2012)
version of xmlrpc-c. I've rebased it to newer version (1.47.1, from
this month). It doesn't anymore use cmake (it was port from one of our
contributors, official buildsys is autoconf+gnumake) for building, now
it uses meson (you can see why in my blog[0]).

* abrt
No problem for rebuild
* certmonger
FTBFS due to openssl1.1[1], though probably it should be retired
because looks like it's part of FreeIPA now
* freeipa
No problem for rebuild
* freight-tools
Doesn't build with new xmlrpc-c, but seems easy to fix[2]
* libreport
No problem for rebuild
* opensips
FTBFS due to openssl1.1[3]
* rtorrent
No problem for rebuild
* fawkes
Was not able to build due to nothing provides libvtkftgl.so.1 needed
by pcl-1.8.0-2.fc26.x86_64

I will build new xmlrpc-c and rebuild dependent libraries this or next week.


[0] https://blogs.gnome.org/ignatenko/2016/12/17/meson-%E2%99%A5-xmlrpc-c/
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1405790
[2] https://github.com/FreightAgent/freight-tools/issues/5
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1385596
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rawhide: Illegal char '-' (0x2d) in: Release: 3.fc26-pending

[Igor Gnatenko]

On Wed, Dec 14, 2016 at 12:00 PM, Nikos Mavrogiannopoulos
<n...@redhat.com> wrote:
> Any idea on why this happens when attempting to build in rawhide? Is
> the buildroot broken?
You need to update fedpkg/pyrpkg.
>
> $ fedpkg build
> error: line 6: Illegal char '-' (0x2d) in: Release: 3.fc26-pending
> error: query of specfile /home/.../fedora/gnutls/gnutls.spec failed,
> can't parse
>
> The line in question has:
> Release: 3%{?dist}
>
>
> Builds in other branches work fine.
>
> regards,
> Nikos
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: Announcement: Fedora Docker Layered Image Build Service is GO!

[Igor Gnatenko]

On Tue, Dec 13, 2016 at 8:36 PM, Adam Miller
<maxamill...@fedoraproject.org> wrote:
> It is with great pleasure that the Fedora Project Announces the availability
> of the Fedora Docker Layered Image Build Service[0] to the Fedora Contributor
> Community!
>
> With this announcement we are opening availability of the Docker Layered
> Image Build Service for the Docker Layered Images[1] that the Fedora Cloud
> SIG[2] has been the primary maintainers[3] of on GitHub into DistGit as
> official components of Fedora. From there we will be extending an invitation
> to all Fedora Contributors to maintain Docker Layered Image Containers for
> official release by the Fedora Project. Currently this effort is to enable
> the Fedora Cloud/Atomic WG[2] goals which target Fedora Atomic Host[4] as a
> primary deliverable to power the future of Cloud. This is also to enable the
> Fedora Modularity[5] work be delivered as Containers in the future as Fedora
> becomes fundamentally more modular in nature.
>
> How do I get started?
>
> Contributors will go through a simliar process as what they currently do
> with RPM Review Requests. There will be Container Reviews as well as
> Container Guidelines:
>
> https://fedoraproject.org/wiki/Container:Review_Process
> https://fedoraproject.org/wiki/Container:Guidelines
Nice job!

I have couple of questions:
* why "FROM fedora:25", how do I choose version on which I want to
base container?
* is there containers in registry for rawhide?
>
> At this time the Cloud/Atomic WG[2] will maintain the Guidelines as well as
> the Review Process along with input from all Fedora Contributors. This may
> change later with the formation of a Fedora Container Committee (similar to
> the Fedora Packaging Committee[6]).
>
> Please note that both the Guidelines and the Review Process are likely to
> evolve along with the Container technologies as we move into the future so
> we encourage community members to check the documentation for updates.
>
> For more information, please see the following Fedora Community Blog:
>
> 
> https://communityblog.fedoraproject.org/fedora-docker-layered-image-build-service-now-available/
>
> [0] - 
> https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
> [1] - https://fedoraproject.org/wiki/Cloud
> [2] - 
> https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/
> [3] - https://github.com/fedora-cloud/Fedora-Dockerfiles
> [4] - https://getfedora.org/en/atomic/download/
> [5] - https://fedoraproject.org/wiki/Modularity
> [6] - https://fedoraproject.org/wiki/Packaging_Committee
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: Packagers - Flag day 2016 Important changes

[Igor Gnatenko]

On Mon, Dec 12, 2016 at 2:33 AM, Michael Catanzaro <mcatanz...@gnome.org> wrote:
> On Sun, 2016-12-11 at 18:34 -0600, Dennis Gilmore wrote:
>> * koji and the source lookaside were changed to use kerberos
>> authentication
>> instead of ssl certificates. All maintainers will need to:
>>
>> kinit your-fas-accountn...@fedoraaproject.org
>>
>> to get a valid kerberos TGT and be able to authenticate to koji and
>> the lookaside upload cgi.
>>
>> See the general kerberos information at:
>> https://fedoraproject.org/wiki/Infrastructure_kerberos_authentication
>> for more details.
>
> I had some fun with this! Turns out both username and domain are case-
> sensitive. I almost gave up when none of the following worked:
>
> $ kinit catanz...@fedoraproject.org
> $ kinit catanz...@fedoraproject.org
> $ kinit catanz...@fedoraproject.org
>
> This worked:
>
> $ kinit catanz...@fedoraproject.org
>
> OK great, but now it wants me to type a password, but I still don't
> want to switch my FAS account to use a memorable password, so let's try
> to use the gnome-online-accounts option instead! Unfortunately the
> instructions on how to use gnome-online-accounts in the wiki do not
> work. It shows a little error icon in the Domain box, as if to indicate
> that FEDORAPROJECT.ORG is an invalid domain (but unhelpfully without
> any actual tooltip or error message). Is there a known problem here?
yes, and even patch available:
https://bugzilla.redhat.com/show_bug.cgi?id=1401605
>
> Michael
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: HEADS UP: shapelib soname bump

[Igor Gnatenko]

On Sun, Dec 11, 2016 at 7:04 PM, Ralf Corsepius <rc040...@freenet.de> wrote:
> On 12/11/2016 01:44 PM, Igor Gnatenko wrote:
>
>>>>> gpsbabel-0:1.5.3-4.fc24
>>
>> + perl xmldoc/makedoc
>> /var/tmp/rpm-tmp.rKbJFb: line 62: perl: command not found
>> Can you file FTBFS bug?
>
> Why didn't you try a scratch-build in advance to a introducing broken builds
> into git?
1. What means "broken build into git"?
2. Why should I try scratch-build in case I know that if build will
not fail due my change?
>
> Anyway, I (gpsbabel maintainer) will take care of this, tomorrow.
>
> Ralf
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: Start packaging/maintaining in Fedora

[Igor Gnatenko]

On Dec 11, 2016 3:46 PM, "Ms Sanchez"  wrote:


Hello everyone!

I want to start packaging and maintaining packages in Fedora, but I'm a bit
lost. What should I do first? How can I start maintaining a package?  Is
there anyone who can guide me a bit, please?

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

I know Python and C languages.

Thanks in advance!  Sylvia






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

Re: out of space on some builders

[Igor Gnatenko]

On Dec 11, 2016 2:53 PM, "Patrick マルタインアンドレアス Uiterwijk" <
puiterw...@redhat.com> wrote:

> Looks like there are problems on some builders:

Then reporting koji errors, it would be great if you could attach the task
link
so that we can check.

http://koji.fedoraproject.org/koji/taskinfo?taskID=16837961
For example this one.


>
> BuildrootError: could not init mock buildroot, mock exited with status
> 1; see build.log for more information
>
> And there is no build.log.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

out of space on some builders

[Igor Gnatenko]

Looks like there are problems on some builders:

BuildrootError: could not init mock buildroot, mock exited with status
1; see build.log for more information

And there is no build.log.
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] gpgme-1.8.0 comes in Rawhide

[Igor Gnatenko]

On Sat, Dec 10, 2016 at 7:30 PM, Neal Gompa <ngomp...@gmail.com> wrote:
> On Sat, Dec 10, 2016 at 1:28 PM, Igor Gnatenko <ignate...@redhat.com> wrote:
>> There is also C++ bindings, but I didn't package it. Do you want me to do it?
>
>
> If you could, I think it'd be appreciated if the C++ bindings were included.
Done.

New pacakges:
* gpgmepp
* gpgmepp-devel
* qgpgme
* qgpgme-devel

Python packages are named:
* python2-gpg
* python3-gpg
since they provide "gpg" egg and to not confuse people with pygpgme project.

It's building right now.
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: HEADS UP: shapelib soname bump

[Igor Gnatenko]

On Sun, Dec 11, 2016 at 1:20 PM, Sandro Mani <manisan...@gmail.com> wrote:
>
>
> On 11.12.2016 12:54, Igor Gnatenko wrote:
>>
>> On Sun, Dec 11, 2016 at 11:54 AM, Sandro Mani <manisan...@gmail.com>
>> wrote:
>>>
>>> Hi
>>>
>>> I'm preparing the shapelib-1.4.0 update, which bumped the soname. There
>>> are
>>> no API changes, it was just to synchronize with the debian soname.
>>> Dependent
>>> packages are:
>>>
>>> gpsbabel-0:1.5.3-4.fc24
+ perl xmldoc/makedoc
/var/tmp/rpm-tmp.rKbJFb: line 62: perl: command not found
Can you file FTBFS bug?
>>> grads-0:2.0.2-18.fc26
done
>>> librecad-0:2.1.0-1.fc25
http://koji.fedoraproject.org/koji/taskinfo?taskID=16837961
/usr/bin/tar: LibreCAD-dbf1cc7c9597740d34a068f6f09c36841054e903/librecad/res:
Cannot mkdir: No space left on device
anyway, after next try -- done
>>> marble-widget-qt5-1:16.08.3-1.fc26
done
>>> plplot-libs-0:5.11.1-5.fc25
can't be built due to swig/octave incompatibility
>>>
>>> I'll need help rebuilding the above packages.
>>
>> I can help, ping me when package is in koji and I should rebuild these
>> packages.
>
> Thanks, the package is now in koji.
>
>
> Sandro
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: HEADS UP: shapelib soname bump

[Igor Gnatenko]

On Sun, Dec 11, 2016 at 11:54 AM, Sandro Mani <manisan...@gmail.com> wrote:
> Hi
>
> I'm preparing the shapelib-1.4.0 update, which bumped the soname. There are
> no API changes, it was just to synchronize with the debian soname. Dependent
> packages are:
>
> gpsbabel-0:1.5.3-4.fc24
> grads-0:2.0.2-18.fc26
> librecad-0:2.1.0-1.fc25
> marble-widget-qt5-1:16.08.3-1.fc26
> plplot-libs-0:5.11.1-5.fc25
>
> I'll need help rebuilding the above packages.
I can help, ping me when package is in koji and I should rebuild these packages.
>
> Thanks
> Sandro
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Missing heads up for gmsh SONAME bump

[Igor Gnatenko]

Looks like there was no announcement nor rebuild of dependent packages.

getdp has broken dependencies in the rawhide tree:
On x86_64:
getdp-2.10.0-2.fc26.x86_64 requires libGmsh.so.2.14()(64bit)
On armhfp:
getdp-2.10.0-2.fc26.armv7hl requires libGmsh.so.2.14
On ppc64le:
getdp-2.10.0-2.fc26.ppc64le requires libGmsh.so.2.14()(64bit)
On aarch64:
getdp-2.10.0-2.fc26.aarch64 requires libGmsh.so.2.14()(64bit)
On ppc64:
getdp-2.10.0-2.fc26.ppc64 requires libGmsh.so.2.14()(64bit)
On i386:
getdp-2.10.0-2.fc26.i686 requires libGmsh.so.2.14
Please resolve this as soon as possible.

Would be nice in future if someone will send headsup and/or rebuild
dependent packages.
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] gpgme-1.8.0 comes in Rawhide

[Igor Gnatenko]

On Sat, Dec 10, 2016 at 7:28 PM, Igor Gnatenko <ignate...@redhat.com> wrote:
> Currently we stuck for very old version and I am preparing update,
> notable changes are:
> * Python bindings (both py2 and py3), upstream recommend projects to
> switch to official bindings
> * libgpgme-pthread.so is removed, GPGME is thread-safe (should not
> affect packages using gpgme-config)
>
> There is also C++ bindings, but I didn't package it. Do you want me to do it?
>
> Packages to rebuild:
I realized that ABI was not broken, so most of the packages do not need rebuild.
* balsa
* kdepim4
* kdepimlibs
* kde-runtime
* kget
* kf5-gpgmepp
* kf5-libkleo
* kleopatra
* ostree
Rebuilt

* kdepim
Needs rebuild of kf5-mailcommon

* kf5-mailcommon
Needs rebuild of kf5-messagelib

* kdepim-addons
* kdepim-apps-libs
DEBUG util.py:426:  No matching package to install:
'kf5-pimcommon-devel >= 16.08.3'

* kf5-messagelib
DEBUG util.py:426:  No matching package to install:
'kdepim-apps-libs-devel >= 16.08.3'
DEBUG util.py:426:  No matching package to install:
'kf5-libgravatar-devel >= 16.08.3'
DEBUG util.py:426:  No matching package to install:
'kf5-pimcommon-devel >= 16.08.3'

* trojita
FTBFS by other reasons
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[HEADS UP] gpgme-1.8.0 comes in Rawhide

[Igor Gnatenko]

Currently we stuck for very old version and I am preparing update,
notable changes are:
* Python bindings (both py2 and py3), upstream recommend projects to
switch to official bindings
* libgpgme-pthread.so is removed, GPGME is thread-safe (should not
affect packages using gpgme-config)

There is also C++ bindings, but I didn't package it. Do you want me to do it?

Packages to rebuild:
* almanah
* alot
* balsa
* centerim
* claws-mail
* docker
* docker-latest
* fwknop
* fwknop-gui
* fwupd
* geany-plugins
* kdepim
* kdepim4
* kdepim
* kdepim-apps-libs
* kdepimlibs
* kde-runtime
* kf5-gpgmepp
* kf5-kwallet
* kf5-libkleo
* kf5-mailcommon
* kf5-messagelib
* kget
* kleopatra
* libcryptui
* libisds
* librepo
* mcabber
* mutt
* openvas-libraries
* openvas-manager
* ostree
* pacman
* python-pygpgme
* reprepro
* seahorse
* seahorse-nautilus
* seahorse-sharing
* skopeo
* sylpheed
* trojita
* volume_key

I will rebuild all this packages.
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: a diversion into EPEL [was Re: Two more concrete ideas for what a once-yearly+update schedule would look like]

[Igor Gnatenko]

On Dec 9, 2016 5:18 PM, "Matthew Miller"  wrote:

On Fri, Dec 09, 2016 at 11:07:32AM -0500, Colin Walters wrote:
> > Anyways, in the big picture, while I don't speak for everyone on
> > the Project Atomic side, I personally point users at CentOS first,
> > unless I have some reason to think they want Fedora. Something like
> > 80% of Fedora usage hitting the mirrors was desktop systems, right?
> > I don't expect that to change personally.
> Although..except for EPEL.  And how EPEL works should obviously be
> part of this. Things would feel clearer if EPEL lived in CentOS now
> perhaps.

Right; in mirror traffic, EPEL is to Fedora Workstation as Workstation
is to Server. :)

EPEL packages *are* Fedora packages, though — moving the project to
CentOS isn't completely crazy, but would require a lot more integration
and cooperation between the projects.

That's something I'd like to see anyway. I think there are a lot of
opportunities for this with containers and modularity — if you can just
run Fedora containers on CentOS or RHEL *directly*, why bother
rebuilding them? For a lot of the software that's in EPEL, that's
completely sufficient. For other software, where users would like the
version to match more closely the long lifecycle, maybe there could be
a hand-off from Fedora version to CentOS version.

Don't know how modularity is related here. It's just about building distro.
Containers, yeah, but please don't kill Fedora. I don't want to run
container for each software I use. RHEL and CentOS people can struggle, but
don't do this with Fedora users.




--
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Python 2/3 package naming

[Igor Gnatenko]

On Wed, Dec 7, 2016 at 2:07 PM, Jakub Jedelsky <jakub.jedel...@gmail.com> wrote:
> On Wed, Dec 07, 2016 at 11:48:55AM +0100, Igor Gnatenko wrote:
>> On Wed, Dec 7, 2016 at 10:48 AM, James Hogarth <james.hoga...@gmail.com> 
>> wrote:
>> > On 7 December 2016 at 09:39, Jakub Jedelsky <jakub.jedel...@gmail.com> 
>> > wrote:
>> >> Hi there,
>> >>
>> >> I'm maintainer of vertica-python package and want to add support for
>> >> python3, but I'm a little bit lost in naming.
>> >>
>> >> I named package as a upstream 'vertica-python', because (if I remember
>> >> correctly) naming guidelines told, that if upstream has 'python' in
>> >> the name it should stay there (can't found the source now). But how
>> >> should I name python3 package? Should it be 'python3-vertica-python'
>> >> od 'vertica-python3'?
>> >>
>> >> Or should I rename package to python{3,2}-vertica and obsolete
>> >> vertica-python?
>> >>
>> >>
>> >
>> > Well the name in setup.py is vertica-python and it installs as
>> > vertica_python and the pip install is that as well.
>> >
>> > So according to the guidelines I'd expect it to by
>> > python2-vertica-python and python3-vertica-python even if it sounds a
>> > little awkward, best way to handle anything that might end up
>> > depending on it etc
>> IMO this is worst thing. I think having pythonX-vertica is better.
>
> I just sniffed around repos and found just one package with a weird
> name - it's python3-python-etcd. On the other hand I found a few, which
> are in style -python3, e.g. abrt-python3, libvirt-python3. So it
> looks, that this naming should be quite good.
etcd bug should be already fixed or there is bug opened (I opened it
long time ago).
>
> - jj
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: Python 2/3 package naming

[Igor Gnatenko]

On Wed, Dec 7, 2016 at 10:48 AM, James Hogarth <james.hoga...@gmail.com> wrote:
> On 7 December 2016 at 09:39, Jakub Jedelsky <jakub.jedel...@gmail.com> wrote:
>> Hi there,
>>
>> I'm maintainer of vertica-python package and want to add support for
>> python3, but I'm a little bit lost in naming.
>>
>> I named package as a upstream 'vertica-python', because (if I remember
>> correctly) naming guidelines told, that if upstream has 'python' in
>> the name it should stay there (can't found the source now). But how
>> should I name python3 package? Should it be 'python3-vertica-python'
>> od 'vertica-python3'?
>>
>> Or should I rename package to python{3,2}-vertica and obsolete
>> vertica-python?
>>
>>
>
> Well the name in setup.py is vertica-python and it installs as
> vertica_python and the pip install is that as well.
>
> So according to the guidelines I'd expect it to by
> python2-vertica-python and python3-vertica-python even if it sounds a
> little awkward, best way to handle anything that might end up
> depending on it etc
IMO this is worst thing. I think having pythonX-vertica is better.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates - warning

[Igor Gnatenko]

On Tue, Dec 6, 2016 at 9:01 AM, Florian Weimer <fwei...@redhat.com> wrote:
> On 12/06/2016 08:27 AM, Ralf Corsepius wrote:
>>
>> On 12/06/2016 04:44 AM, Orion Poplawski wrote:
>>
>>> I've run into a reasonable number of failures of (custom) configure
>>> checks due to this.  Mainly calling exit() without including stdlib.h.
>>> So keep alert everyone.  Unfortunately this can lead to unpredictable
>>> and perhaps hard to detect changes.
>>
>>
>> It's worse. This change contradicts autoconf's working principles.
>
>
> I doubt that it's deliberate that autoconf attempts to compile invalid C
> code.
>
>> It
>> causes configure-checks to produce bogus results and to produce
>> mal-built packages.
>
>
> These packages are unportable and will fail with other C compilers.
>
>> That said, I am vehemently opposed to this step and ask the persons in
>> charge to revert it.
>
>
> We could probably help with identifying packages affected by this change,
> but after seventeen years, it's time to clean up these broken autoconf
> checks.
Totally agree here.

Florian, why only %__global_cflags were changed and not %optflags?
Many of packages which don't do %configure, use %optflags.
>
> Thanks,
> Florian
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: dnf skipping updates in koji

[Igor Gnatenko]

On Tue, Dec 6, 2016 at 10:34 AM, Igor Gnatenko <ignate...@redhat.com> wrote:
> On Sun, Nov 20, 2016 at 5:58 AM, Dennis Gilmore <den...@ausil.us> wrote:
>> On Saturday, November 19, 2016 8:13:41 PM CST Igor Gnatenko wrote:
>>> On Nov 19, 2016 7:26 PM, "Dan Horák" <d...@danny.cz> wrote:
>>> > On Sat, 19 Nov 2016 11:16:17 -0700
>>> >
>>> > Orion Poplawski <or...@cora.nwra.com> wrote:
>>> > > I just noticed this in a root.log for a koji rawhide build that
>>> >
>>> > > didn't error out doing the install:
>>> > afaik these are weak dependencies, that are not installed (by policy),
>>> > dnf 2.0 reports them without the confusing "conflicts"
>>>
>>> Not the dnf-conf.
>> What do you mean by that statement?
> I mean dnf-conf is not a weak dep, it's hard dep.
>>
>>> I would recommend add to mock those 2 options.
>> What two options? We have intentionally turned off all weak deps in the
>> buildroots.  AFAIK the confusing output from dnf is it saying its skipping 
>> the
>> packages because of our turning off all weak deps
> Actually if there are some broken deps within latest packages, solver
> tries to install any package which will be solvable (lower version).
`--best` disallows that and forces newest version to be installed. I
think we should really enable this in mock.

Mirek, Dennis, opinions?
>>
>>
>> Dennis
>>> > Dan
>>> > >
>>> > > DEBUG util.py:421:  Skipping packages with conflicts:
>>> > > DEBUG util.py:421:  (add '--best --allowerasing' to command line to
>>> > > force their upgrade):
>>> > > DEBUG util.py:421:   acl  x86_64
>>> > > 2.2.52-11.fc24 build   75 k
>>> > > DEBUG util.py:421:   bash-completion  noarch
>>> > > 1:2.4-1.fc26 build  268 k
>>> > > DEBUG util.py:421:   compat-openssl10 x86_64
>>> > > 1:1.0.2j-5.fc26  build  1.1 M
>>> > > DEBUG util.py:421:   cracklib-dicts   x86_64
>>> > > 2.9.6-3.fc25 build  3.9 M
>>> > > DEBUG util.py:421:   dbus x86_64
>>> > > 1:1.11.6-1.fc26  build  245 k
>>> > > DEBUG util.py:421:   dbus-libsx86_64
>>> > > 1:1.11.6-1.fc26  build  172 k
>>> > > DEBUG util.py:421:   deltarpm x86_64  3.6-17.fc25
>>> > >
>>> > >build   88 k
>>> > >
>>> > > DEBUG util.py:421:   dnf-conf noarch
>>> > > 2.0.0-0.rc1.4.fc26   build   41 k
>>> > > DEBUG util.py:421:   dnf-plugins-core noarch
>>> > > 1.0.0-0.rc1.1.fc26   build   38 k
>>> > > 
>>> > >
>>> > >
>>> > > This doesn't seem right to me.
>>> > >
>>> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=16531079
>>> > >
>>> > > --
>>> > > 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
>>> > > ___
>>> > > devel mailing list -- devel@lists.fedoraproject.org
>>> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> >
>>> > ___
>>> > devel mailing list -- devel@lists.fedoraproject.org
>>> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>
>
>
> --
> -Igor Gnatenko



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

Re: dnf skipping updates in koji

[Igor Gnatenko]

On Sun, Nov 20, 2016 at 5:58 AM, Dennis Gilmore <den...@ausil.us> wrote:
> On Saturday, November 19, 2016 8:13:41 PM CST Igor Gnatenko wrote:
>> On Nov 19, 2016 7:26 PM, "Dan Horák" <d...@danny.cz> wrote:
>> > On Sat, 19 Nov 2016 11:16:17 -0700
>> >
>> > Orion Poplawski <or...@cora.nwra.com> wrote:
>> > > I just noticed this in a root.log for a koji rawhide build that
>> >
>> > > didn't error out doing the install:
>> > afaik these are weak dependencies, that are not installed (by policy),
>> > dnf 2.0 reports them without the confusing "conflicts"
>>
>> Not the dnf-conf.
> What do you mean by that statement?
I mean dnf-conf is not a weak dep, it's hard dep.
>
>> I would recommend add to mock those 2 options.
> What two options? We have intentionally turned off all weak deps in the
> buildroots.  AFAIK the confusing output from dnf is it saying its skipping the
> packages because of our turning off all weak deps
Actually if there are some broken deps within latest packages, solver
tries to install any package which will be solvable (lower version).
>
>
> Dennis
>> > Dan
>> > >
>> > > DEBUG util.py:421:  Skipping packages with conflicts:
>> > > DEBUG util.py:421:  (add '--best --allowerasing' to command line to
>> > > force their upgrade):
>> > > DEBUG util.py:421:   acl  x86_64
>> > > 2.2.52-11.fc24 build   75 k
>> > > DEBUG util.py:421:   bash-completion  noarch
>> > > 1:2.4-1.fc26 build  268 k
>> > > DEBUG util.py:421:   compat-openssl10 x86_64
>> > > 1:1.0.2j-5.fc26  build  1.1 M
>> > > DEBUG util.py:421:   cracklib-dicts   x86_64
>> > > 2.9.6-3.fc25 build  3.9 M
>> > > DEBUG util.py:421:   dbus x86_64
>> > > 1:1.11.6-1.fc26  build  245 k
>> > > DEBUG util.py:421:   dbus-libsx86_64
>> > > 1:1.11.6-1.fc26  build  172 k
>> > > DEBUG util.py:421:   deltarpm x86_64  3.6-17.fc25
>> > >
>> > >build   88 k
>> > >
>> > > DEBUG util.py:421:   dnf-conf noarch
>> > > 2.0.0-0.rc1.4.fc26   build   41 k
>> > > DEBUG util.py:421:   dnf-plugins-core noarch
>> > > 1.0.0-0.rc1.1.fc26   build   38 k
>> > > 
>> > >
>> > >
>> > > This doesn't seem right to me.
>> > >
>> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=16531079
>> > >
>> > > --
>> > > 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
>> > > ___
>> > > devel mailing list -- devel@lists.fedoraproject.org
>> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> >
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



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

Re: My package has stopped building on rawhide

[Igor Gnatenko]

On Tue, Dec 6, 2016 at 12:19 AM, Jared L Wallace
<jared-wall...@us.ibm.com> wrote:
>
> The configure script errors out when checking:
>
> AC_TRY_LINK([#include ],
> [gsl_complex a; GSL_SET_COMPLEX(, 1.0, 1.0);
> gsl_complex_logabs(a);],
> HAS_GSL_LIB=yes, HAS_GSL_LIB=no)
>
> This works fine on F25.
>
> I checked gsl, and the package not only hasn't changed recently, it hasn't
> even been built in rawhide (still f25 version). gcc has also not changed.
>
> The package was building fine Friday, and in fact, still builds successfully
> on my rawhide box (and another developers box).
>
> The failing build is here:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=16762827
Would be nice if you can add `|| :` after %configure and cat the
verbose log (config.log IIRC).
>
> successful f25 build:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=16763334
>
> Any ideas?
> JARED L. WALLACE
> Software Engineer, Sametime Extended Support
> Phone: 1-512-973-5281
> E-mail: jared-wall...@us.ibm.com
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



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

Re: Base Runtime prototype build and numerous FTBFS issues

[Igor Gnatenko]

On Wed, Nov 30, 2016 at 4:36 PM, Petr Šabata <con...@redhat.com> wrote:
> Hi!
>
> during the Tuesday's Modularity WG meeting I was talking about the status
> of the Base Runtime prototype build and the package build failures we
> encountered during our latest attempt.  The meeting log is here:
>
> https://meetbot.fedoraproject.org/teams/modularity_wg/modularity_wg.2016-11-29-15.00.log.html
>
> In short: To bootstrap the Modularity infra (yeah, it's still not done)
> we took a (fairly large) set of packages directly from Fedora 25 RC3
> and put them all in one, self-hosting module, currently misleadingly
> labeled as base-runtime.  The next step was to rebuild this set using
> only the packages in it, preferrably twice, to prove it works, produces
> the same, reproducible builds (or as close as we can get) and to save us
> from sudden, unexpected breakage later when we need to touch components
> deep in the [build] dependency chain.
>
> (Since this is a common question: No, the final Base Runtime module,
> or the Generational Core stack it is part of, won't be self-hosting and
> we won't be shipping the entire set we're currently working with under
> that name.)
>
> We attempted to rebuild 2943 SRPMs and encountered 152 failures.
> The reasons vary and include undiscovered conditional build dependencies,
> undeclared build or runtime dependencies in combination with recent
> buildroot and other package dependency chains changes, packages no
> longer being compatible with their updated dependencies, random hangs
> or non-deterministic, randomly failing test suites, to name a few.
>
> Some but not all of those affect, and can be reproduced in, the traditional
> Fedora release, too, and fixing these issues is not only crucial for the
> upcoming modular Fedora 26 Server but will benefit the standard Fedora
> release as well.
>
> We'll be working on resolving these failures during the upcoming few weeks
> -- via FTBFS bug reports or immediate fixes in the most trivial cases.
> We'll use the following tracker bug for this purpose:
> https://bugzilla.redhat.com/show_bug.cgi?id=1400162
>
> For the curious, the logs are here:
> https://psabata.fedorapeople.org/f25rc3-failures/
Would be nice to get name of packages + their (co-)maintainer list.
>
> And the modulemd input for this build is here:
> http://pkgs.stg.fedoraproject.org/cgit/modules/base-runtime.git/tree/base-runtime.yaml?id=d2485512c7916304e73fabc5db422798eb2be1d5
Wondering why rubygem*, jboss*, nodejs* and gstreamer* are there...
>
> If you maintain some of these FTBFS'd packages, feel free to fix them
> even before we get to you! :) Just, please, let us know if you do.
>
> Finally, some quick test instructions: Make sure your package builds
> in F25 and Rawhide.  If it does, check whether it also builds in mock
> using this configuration file: https://paste.fedoraproject.org/494173/
> If it works there as well, chances are it's fine.
>
> Thank you in advance,
> P
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



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

[RFC] RPM's Python dependency generator

[Igor Gnatenko]

Hi,

in short, it reads egg metadata and can generate Provides (which we
already do now), Requires (which I want to talk about) and Recommends
(which I don't care atm).

Let's take simple package -- aiohttp.
https://bugzilla.redhat.com/show_bug.cgi?id=1381750

As you can see, since some version multidict requirement was bumped to
>= 2.0 and async_timeout requirement was added. Currently we specify
all requirements during initial package and usually without versions
which is breaking after some time.

So, let's try it (I will skip unrelated parts).
Before:
python(abi) = 3.5
python3-chardet
python3-multidict
After:
python(abi) = 3.5
python3.5dist(async-timeout)
python3.5dist(chardet)
python3.5dist(multidict) >= 2.0

Without more complicated packages (MNE, nipy, nilearn, moss) it's
getting much more harder since I have there 10+ deps.

We can't really track all changes in upstream code, so if we will
enable dependency generator, it will do this work for us. Note that we
can't just enable it in RPM, because it will break a lot of packages
due to:
* missing requires in egg metadata
* extra requires in egg metadata (e.g. windows-modules)

I would propose plan:
1. Create macro which will enable/disable depgen (e.g %python_enable_depgen)
2. Start enabling depgen and porting things (somehow reuse
portingdb.xyz probably?) and submitting patches upstream
3. In 1-2 releases I hope we can use it for major amount of packages
4. Enable depgen by default in RPM, add disabling depgen for remaining packages

Neal, you can share how Mageia did that as well and feel free to comment this ;)

Thoughts?
-- 
-Igor Gnatenko
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: line 1: udevadm: command not found

[Igor Gnatenko]

On Fri, Nov 25, 2016 at 1:17 PM, Michael Schwendt <mschwe...@gmail.com> wrote:
> The root.log of F25 build jobs prints this late:
>
> DEBUG util.py:421:  Running transaction
> DEBUG util.py:421:  /var/tmp/rpm-tmp.W2zvnF: line 1: udevadm: command not 
> found
> DEBUG util.py:421:  /var/tmp/rpm-tmp.W2zvnF: line 2: udevadm: command not 
> found
> DEBUG util.py:421:  Running in chroot, ignoring request.
>
> Haven't done anything to examine it, but mention it in case somebody 
> recognises
> which scriptlet it comes from.
it's standard thing which we did in %post for %udev_rules_update (or
its plain version).

We discussed this some time ago.. Nowadays systemd picks changes
automatically, so no scriptlets are needed.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: Add new application to repository

[Igor Gnatenko]

On Thu, Nov 24, 2016 at 10:10 AM, Gregorio . <de...@outlook.it> wrote:
> Hi all,
Hello,
>
>
> I'm a newbie, so I don't know what are the steps to add a new application to
> the official repository. I'm asking this question because I ported
> Slingscold (fork of Slingshot, the Elementary OS application launcher) from
> GTK2 to GTK3 (project link: https://github.com/echo-devim/slingswarm). I'd
> like to add it to the Fedora official repository, but I don't know how to do
> that and if there are some requirements.
>
>
> Can someone help me, please?
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
>
>
> Kind regards,
>
> Gregorio
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



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

Re: upcoming build and release developer flag day December 12 2016

[Igor Gnatenko]

On Nov 22, 2016 10:42 AM, "Vít Ondruch"  wrote:
>
>
>
> Dne 21.11.2016 v 21:52 Patrick マルタインアンドレアス Uiterwijk napsal(a):
> >> Dne 21.11.2016 v 16:07 Alexander Bokovoy napsal(a):
> >>
> >>
> >> $ KRB5_TRACE=/dev/stderr kinit vondruch(a)FEDORAPROJECT.ORG
> >> [8655] 1479746886.252240: Resolving unique ccache of type KEYRING
> >> [8655] 1479746886.252281: Getting initial credentials for
> >> vondruch(a)FEDORAPROJECT.ORG
> >> [8655] 1479746886.252439: Sending request (205 bytes) to
FEDORAPROJECT.ORG
> >> [8655] 1479746886.252542: Resolving hostname id.fedoraproject.org
> >> [8655] 1479746886.380979: Terminating TCP connection to https
> >> 2604:1580:fe00:0:dead:beef:cafe:fed1:443
> >> [8655] 1479746886.383242: Terminating TCP connection to https
> >> 2610:28:3090:3001:dead:beef:cafe:fed3:443
> >> [8655] 1479746886.754122: TLS certificate name matched
> >> "id.fedoraproject.org"
> >> [8655] 1479746886.926836: Sending HTTPS request to https
140.211.169.206:443
> >> [8655] 1479746887.331375: HTTPS error receiving from https
> >> 140.211.169.206:443
> >> [8655] 1479746887.333212: Terminating TCP connection to https
> >> 140.211.169.206:443
> >> [8655] 1479746887.594719: TLS certificate name matched
> >> "id.fedoraproject.org"
> >> [8655] 1479746887.710694: Sending HTTPS request to https
67.219.144.68:443
> >> [8655] 1479746888.330867: HTTPS error receiving from https
67.219.144.68:443
> >> [8655] 1479746888.331797: Terminating TCP connection to https
> >> 67.219.144.68:443
> >> [8655] 1479746888.694098: TLS certificate name matched
> >> "id.fedoraproject.org"
> >> [8655] 1479746888.862462: Sending HTTPS request to https
67.203.2.67:443
> >> [8655] 1479746889.122858: HTTPS error receiving from https
67.203.2.67:443
> >> [8655] 1479746889.123787: Terminating TCP connection to https
> >> 67.203.2.67:443
> >> [8655] 1479746889.527941: TLS certificate name matched
> >> "id.fedoraproject.org"
> >> [8655] 1479746889.722994: Sending HTTPS request to https
209.132.181.16:443
> >> [8655] 1479746889.964857: HTTPS error receiving from https
> >> 209.132.181.16:443
> >> [8655] 1479746889.965718: Terminating TCP connection to https
> >> 209.132.181.16:443
> >> [8655] 1479746890.363509: TLS certificate name matched
> >> "id.fedoraproject.org"
> >> [8655] 1479746890.552022: Sending HTTPS request to https
209.132.181.15:443
> >> [8655] 1479746890.787479: HTTPS error receiving from https
> >> 209.132.181.15:443
> >> [8655] 1479746890.788339: Terminating TCP connection to https
> >> 209.132.181.15:443
> >> [8655] 1479746891.68629: TLS certificate name matched "
id.fedoraproject.org"
> >> [8655] 1479746891.201442: Sending HTTPS request to https
152.19.134.198:443
> >> [8655] 1479746891.711140: HTTPS error receiving from https
> >> 152.19.134.198:443
> >> [8655] 1479746891.711960: Terminating TCP connection to https
> >> 152.19.134.198:443
> >> [8655] 1479746892.55922: TLS certificate name matched "
id.fedoraproject.org"
> >> [8655] 1479746892.214348: Sending HTTPS request to https
66.35.62.162:443
> >> [8655] 1479746892.563662: HTTPS error receiving from https
66.35.62.162:443
> >> [8655] 1479746892.564576: Terminating TCP connection to https
> >> 66.35.62.162:443
> >> [8655] 1479746892.945989: TLS certificate name matched
> >> "id.fedoraproject.org"
> >> [8655] 1479746893.119732: Sending HTTPS request to https
140.211.169.196:443
> >> [8655] 1479746893.512855: HTTPS error receiving from https
> >> 140.211.169.196:443
> >> [8655] 1479746893.513684: Terminating TCP connection to https
> >> 140.211.169.196:443
> >> [8655] 1479746893.812319: TLS certificate name matched
> >> "id.fedoraproject.org"
> >> [8655] 1479746893.944132: Sending HTTPS request to https
152.19.134.142:443
> >> [8655] 1479746894.412080: HTTPS error receiving from https
> >> 152.19.134.142:443
> >> [8655] 1479746894.412908: Terminating TCP connection to https
> >> 152.19.134.142:443
> >> kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while
> >> getting initial credentials
> > Downgrade to openssl-1.1.0b:
https://github.com/openssl/openssl/issues/1919
>
> Hm, I would need to downgrade more packages apparently  I'll wait
> and hopefully it'll get fixed soon 
Not really, you hit that bug in dnf about installing local packages.
Workaround is to create local repo and downgrade from there.
>
>
> Vít
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: upcoming build and release developer flag day December 12 2016

[Igor Gnatenko]

On Mon, Nov 21, 2016 at 5:48 PM, Vít Ondruch <vondr...@redhat.com> wrote:
>
>
> Dne 21.11.2016 v 16:07 Alexander Bokovoy napsal(a):
>>
>>>
>>>>>  }
>>>>> [domain_realm]
>>>>>  .fedoraproject.org = FEDORAPROJECT.ORG
>>>>>  fedoraproject.org = FEDORAPROJECT.ORG
>>>>> ```
>>>>>
>>>> But apparently, with this snippet, I can't kinit anymore :/
>>>>
>>>> ```
>>>> $ kinit vondr...@fedoraproject.org
>>>> kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while
>>>> getting initial credentials
>> works for me on Fedora 25. You can provide output from
>> 'KRB5_TRACE=/dev/stderr kinit vondr...@fedoraproject.org' to get
>> further.
>>
>
>
> $ KRB5_TRACE=/dev/stderr kinit vondr...@fedoraproject.org
> [8655] 1479746886.252240: Resolving unique ccache of type KEYRING
> [8655] 1479746886.252281: Getting initial credentials for
> vondr...@fedoraproject.org
> [8655] 1479746886.252439: Sending request (205 bytes) to FEDORAPROJECT.ORG
> [8655] 1479746886.252542: Resolving hostname id.fedoraproject.org
> [8655] 1479746886.380979: Terminating TCP connection to https
> 2604:1580:fe00:0:dead:beef:cafe:fed1:443
> [8655] 1479746886.383242: Terminating TCP connection to https
> 2610:28:3090:3001:dead:beef:cafe:fed3:443
> [8655] 1479746886.754122: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746886.926836: Sending HTTPS request to https 140.211.169.206:443
> [8655] 1479746887.331375: HTTPS error receiving from https
> 140.211.169.206:443
> [8655] 1479746887.333212: Terminating TCP connection to https
> 140.211.169.206:443
> [8655] 1479746887.594719: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746887.710694: Sending HTTPS request to https 67.219.144.68:443
> [8655] 1479746888.330867: HTTPS error receiving from https 67.219.144.68:443
> [8655] 1479746888.331797: Terminating TCP connection to https
> 67.219.144.68:443
> [8655] 1479746888.694098: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746888.862462: Sending HTTPS request to https 67.203.2.67:443
> [8655] 1479746889.122858: HTTPS error receiving from https 67.203.2.67:443
> [8655] 1479746889.123787: Terminating TCP connection to https
> 67.203.2.67:443
> [8655] 1479746889.527941: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746889.722994: Sending HTTPS request to https 209.132.181.16:443
> [8655] 1479746889.964857: HTTPS error receiving from https
> 209.132.181.16:443
> [8655] 1479746889.965718: Terminating TCP connection to https
> 209.132.181.16:443
> [8655] 1479746890.363509: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746890.552022: Sending HTTPS request to https 209.132.181.15:443
> [8655] 1479746890.787479: HTTPS error receiving from https
> 209.132.181.15:443
> [8655] 1479746890.788339: Terminating TCP connection to https
> 209.132.181.15:443
> [8655] 1479746891.68629: TLS certificate name matched "id.fedoraproject.org"
> [8655] 1479746891.201442: Sending HTTPS request to https 152.19.134.198:443
> [8655] 1479746891.711140: HTTPS error receiving from https
> 152.19.134.198:443
> [8655] 1479746891.711960: Terminating TCP connection to https
> 152.19.134.198:443
> [8655] 1479746892.55922: TLS certificate name matched "id.fedoraproject.org"
> [8655] 1479746892.214348: Sending HTTPS request to https 66.35.62.162:443
> [8655] 1479746892.563662: HTTPS error receiving from https 66.35.62.162:443
> [8655] 1479746892.564576: Terminating TCP connection to https
> 66.35.62.162:443
> [8655] 1479746892.945989: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746893.119732: Sending HTTPS request to https 140.211.169.196:443
> [8655] 1479746893.512855: HTTPS error receiving from https
> 140.211.169.196:443
> [8655] 1479746893.513684: Terminating TCP connection to https
> 140.211.169.196:443
> [8655] 1479746893.812319: TLS certificate name matched
> "id.fedoraproject.org"
> [8655] 1479746893.944132: Sending HTTPS request to https 152.19.134.142:443
> [8655] 1479746894.412080: HTTPS error receiving from https
> 152.19.134.142:443
> [8655] 1479746894.412908: Terminating TCP connection to https
> 152.19.134.142:443
> kinit: Cannot contact any KDC for realm 'FEDORAPROJECT.ORG' while
> getting initial credentials
https://github.com/openssl/openssl/issues/1919

Solution is to downgrade to openssl-1.1.0b
>
>
>
> Vít
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: repoquery to get the complete set of dependant packages

[Igor Gnatenko]

On Nov 21, 2016 11:47 AM, "Jaroslav Mracek"  wrote:
>
> DNF will have soon (Pull-Request
https://github.com/rpm-software-management/dnf/pull/621) --deplist option
that should provide requested information. The new option will be available
first for rawhide in DNF-2.0 and later for Fc26. This output is similar to
```yum deplist``` command.
This is completely different thing.
> Jaroslav
>
> On Wed, Nov 2, 2016 at 6:14 PM, Pavel Raiskup  wrote:
>>
>> Sorry for the typo in $Subject, s/dependencies/dependant packages/
probably, or
>> "requiring" packages, according to "--whatrequires" syntax.
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] broken/fixed gnupg2-2.1.13 and pygpgme renamed to python-pygpgme

[Igor Gnatenko]

On Sun, Nov 20, 2016 at 10:37 AM, Igor Gnatenko <ignate...@redhat.com> wrote:
> On Sun, Nov 20, 2016 at 10:18 AM, Till Maas <opensou...@till.name> wrote:
>> Hi,
>>
>> On Mon, Jul 25, 2016 at 07:02:44PM +0200, Igor Gnatenko wrote:
>>
>>> Alogn with this I realized that pygpgme spec needs some love (like
>>> cleaning stuff, adding %check section to run tests, backporting
>>> patches) and renaming, so I sent new one for review[5] and created
>>> repo with our (Fedora) fixes on top of dead upstream package[6].
>>
>> This is awesome. Did you by any chance get in touch with other
>> distributions to get them switch to the new fork as well?
> No, I didn't. Unfortunately I don't know what's the usual way of doing
> this. Help is very welcomed!
>
> Actually since gpgme-1.7.0 it should include py2/py3 bindings and all
> people who are using pygpgme are encouraged to use official bindings.
> Unfortunately it's still not available in fedora as we stuck with
> 1.6.0, because there are some problems with libgcrypt-x.y.z.
I'm a bit wrong here, we can get 1.7.0 and I'm working on it:
https://bugzilla.redhat.com/show_bug.cgi?id=1378056.
>>
>> Kind regards
>> Till
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
> --
> -Igor Gnatenko



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

Re: Orphaned Packages in rawhide (2016-11-14)

[Igor Gnatenko]

On Sun, Nov 20, 2016 at 11:00 AM, Till Maas <opensou...@till.name> wrote:
> On Mon, Nov 14, 2016 at 10:34:39AM +, opensou...@till.name wrote:
>
>> Depending on: gnome-web-photo (1), status change: 2016-09-15 (8 weeks ago)
>>   shutter (maintained by: liangsuilong, ivanromanov)
>>   shutter-0.93.1-3.fc25.noarch requires gnome-web-photo = 
>> 0.10.5-9.fc24
>
> gnome-web-photo is still orphaned and shutter still depends on it. If
> you do not want it to be removed from Fedora, please change this.
I think it's better to remove that hard requirement on
gnome-web-photo. Or at least convert it to weak.
>
> Kind regards
> Till
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: [HEADS UP] broken/fixed gnupg2-2.1.13 and pygpgme renamed to python-pygpgme

[Igor Gnatenko]

On Sun, Nov 20, 2016 at 10:18 AM, Till Maas <opensou...@till.name> wrote:
> Hi,
>
> On Mon, Jul 25, 2016 at 07:02:44PM +0200, Igor Gnatenko wrote:
>
>> Alogn with this I realized that pygpgme spec needs some love (like
>> cleaning stuff, adding %check section to run tests, backporting
>> patches) and renaming, so I sent new one for review[5] and created
>> repo with our (Fedora) fixes on top of dead upstream package[6].
>
> This is awesome. Did you by any chance get in touch with other
> distributions to get them switch to the new fork as well?
No, I didn't. Unfortunately I don't know what's the usual way of doing
this. Help is very welcomed!

Actually since gpgme-1.7.0 it should include py2/py3 bindings and all
people who are using pygpgme are encouraged to use official bindings.
Unfortunately it's still not available in fedora as we stuck with
1.6.0, because there are some problems with libgcrypt-x.y.z.
>
> Kind regards
> Till
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: dnf skipping updates in koji

[Igor Gnatenko]

On Nov 19, 2016 7:26 PM, "Dan Horák"  wrote:
>
> On Sat, 19 Nov 2016 11:16:17 -0700
> Orion Poplawski  wrote:
>
> > I just noticed this in a root.log for a koji rawhide build that
> > didn't error out doing the install:
>
> afaik these are weak dependencies, that are not installed (by policy),
> dnf 2.0 reports them without the confusing "conflicts"
Not the dnf-conf.

I would recommend add to mock those 2 options.
>
>
> Dan
>
> > DEBUG util.py:421:  Skipping packages with conflicts:
> > DEBUG util.py:421:  (add '--best --allowerasing' to command line to
> > force their upgrade):
> > DEBUG util.py:421:   acl  x86_64
> > 2.2.52-11.fc24 build   75 k
> > DEBUG util.py:421:   bash-completion  noarch
> > 1:2.4-1.fc26 build  268 k
> > DEBUG util.py:421:   compat-openssl10 x86_64
> > 1:1.0.2j-5.fc26  build  1.1 M
> > DEBUG util.py:421:   cracklib-dicts   x86_64
> > 2.9.6-3.fc25 build  3.9 M
> > DEBUG util.py:421:   dbus x86_64
> > 1:1.11.6-1.fc26  build  245 k
> > DEBUG util.py:421:   dbus-libsx86_64
> > 1:1.11.6-1.fc26  build  172 k
> > DEBUG util.py:421:   deltarpm x86_64  3.6-17.fc25
> >build   88 k
> > DEBUG util.py:421:   dnf-conf noarch
> > 2.0.0-0.rc1.4.fc26   build   41 k
> > DEBUG util.py:421:   dnf-plugins-core noarch
> > 1.0.0-0.rc1.1.fc26   build   38 k
> > 
> >
> >
> > This doesn't seem right to me.
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=16531079
> >
> > --
> > 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
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packaging udev rules

[Igor Gnatenko]

On Fri, Nov 18, 2016 at 2:46 PM, Igor Gnatenko <ignate...@redhat.com> wrote:
> Hello @all,
>
> unfortunately I was not able to find updated information how to do that.
>
> %{_udevrulesdir}/foo.rules is fine in %files and BuildRequires:
> systemd, but there are more questions:
>
> * Should %udev_rules_update be put into %post?
> * Should %{?systemd_requires} be presented in spec? probably something else?

Looks like non of above:
(03:31:38 PM) dreisner: ignatenkobrain: no, it isn't
(03:32:12 PM) dreisner: assuming it does something silly like 'udevadm
control --reload'
(03:33:38 PM) ignatenkobrain: dreisner: yes, it does udevadm control
--reload ...
(03:33:47 PM) dreisner: not needed.
(03:34:01 PM) grawity: does udev pick up changes automatically now?
(03:37:38 PM) dreisner: it has for years
(03:38:08 PM) dreisner: used to do it by inotify. more recently it
just looks at timestamps prior to event processing, with some amount
of rate limiting.
> --
> -Igor Gnatenko



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

Packaging udev rules

[Igor Gnatenko]

Hello @all,

unfortunately I was not able to find updated information how to do that.

%{_udevrulesdir}/foo.rules is fine in %files and BuildRequires:
systemd, but there are more questions:

* Should %udev_rules_update be put into %post?
* Should %{?systemd_requires} be presented in spec? probably something else?
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: List of packages owning %{python3_sitelib}/__pycache__

[Igor Gnatenko]

On Tue, Nov 15, 2016 at 2:49 AM, Athos Ribeiro <athoscribe...@gmail.com> wrote:
> Hello,
Hi,
>
> Guidelines say that %{python3_sitelib}/__pycache__ should not be owned
> by python packages because python3-libs already owns it [1]. That
> directory is actually owned by system-python-libs.
>
> While going through a package review, I realized that 50+ packages own
> %{python3_sitelib}/__pycache__. To avoid generating noise to packagers,
> I am just listing those packages here [2].
Usually, people are just putting %{python3_sitelib/* which is wrong.
>
> [1] https://fedoraproject.org/wiki/Packaging:Python#Byte_compiling
>
> [2] - List of packages (rawhide) owning %{python3_sitelib}/__pycache__:
> cairo-dock-plug-ins
> netstat-monitor
> pydot
> pyparsing
> python-apipkg
> python-args
> python-autopep8
> python-bottle
> python-cma
> python-cmdln
> python-configobj
> python-configparser
> python-cookies
> python-cram
> python-cycler
> python-debian
> python-demjson
> python-dialog
> python-docopt
> python-empy
> python-entrypoints
> python-feedparser
> python-flask-assets
> python-flask-login
> python-flask-principal
> python-flask-whooshee
> python-flexmock
> python-fuse
> python-hwdata
> python-ipgetter
> python-jupyter-core
> python-markdown2
> python-mimeparse
> python-MultipartPostHandler2
> python-novaclient-os-networks
> python-novaclient-os-virtual-interfaces
> python-optcomplete
> python-pandocfilters
> python-path
> python-pefile
> python-pickleshare
> python-pika_pool
> python-plaintable
> python-polib
> python-pylcdsysinfo
> python-pyphen
> python-pytest-flakes
> python-pytest-pep8
> python-q
Fixed.
> python-random2
> python-responses
> python-scp
> python-setuptools_hg
> python-simplemediawiki
> root
> uwsgi
>
> --
> Athos Ribeiro
>
> http://www.ime.usp.br/~athoscr
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org



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

[HEADS UP] Retiring mozjs31

[Igor Gnatenko]

Hi,

At this point, nothing uses mozjs31, so I'm going to retire it in
Rawhide and orphan for F24 / F25. It was used by 0 A.D. (the reason
why we packaged it), but nowadays upstream migrated to mozjs38.
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

libpeas-gtk is in separate subpackage for Rawhide

[Igor Gnatenko]

I pushed commit[0] which separates libpeas-gtk.so.* out of the main
package. Reason is that in future libdnf will be dependent on
libpeas[1] and we don't want to have minimal system with GTK+ stuff ;)

If you will find any regressions / bugs (in libpeas-1.20.0-2.fc26),
let me know. Thanks!

[0] 
http://pkgs.fedoraproject.org/cgit/rpms/libpeas.git/commit/?id=dd1b72dd88584e339686a2c1c985a04a883ea212
[1] https://github.com/rpm-software-management/libhif/pull/202
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: python-setuptools explicit build dependency

[Igor Gnatenko]

if setuptools is used, then you add BR: pythonX-setuptools.

On Sat, Oct 29, 2016 at 10:31 AM, Germano Massullo
<germano.massu...@gmail.com> wrote:
> In spec files of Python based software, python-setuptools is a build
> requirement that is mandatory for EPEL7, on Fedora instead it is not
> required because it should already be a runtime dependency for python-devel.
> By the way I remember I have heard that in next future it should be
> added explicitly for various reasons.
> Since I am actually doing some edits on the spec files of all Python
> packages I mantain, I would like to know if what I have heard is true,
> so that I can add it such dependency now.
>
> Thank you
>
>
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
>



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

[RFC] Standardizing RPM macro for out-of-tree builds

[Igor Gnatenko]

Hi,

during last FPC meeting we agreed[0] that we need some standardization
of macro related to builds where builddir != srcdir (and with
possibility to make it builddir = srcdir).

I was working to make guidelines for ninja and meson. For ninja it
doesn't matter from where you build (it's like make), but meson itself
accepts ONLY out-of-tree builds. Would be nice to get system-wide
(rpm-wide?) macro which stands for:
1) source directory where CMakeLists.txt/meson.build/configure are
2) build directory (I think _target_platform is a good candidate)

to make out-of-tree conversion to in-tree, you do the RPM variable override.

For example, in openSUSE it's defined in cmake[1] as __builddir and __srcdir.

Ideas, suggestions are appreciated!


[0] 
https://meetbot.fedoraproject.org/fedora-meeting-1/2016-10-13/fpc.2016-10-13-16.00.log.html
[1] https://build.opensuse.org/package/view_file/openSUSE:Factory/cmake
/cmake.macros?expand=1
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: where is /1 coming from?

[Igor Gnatenko]

It was bug in binutils packaging. It's fixed.

-Igor Gnatenko

On Oct 12, 2016 3:04 PM, "Matthew Miller" <mat...@fedoraproject.org> wrote:

> Someone on Reddit noted that there's a zero-length file named `1` in /
> on their F25 system. I just looked on mine, and I have one too. It's
> not owned by any RPM. And I checked on an F24 box, and it's got that
> too. Anyone know where this is coming from?
>
> --
> Matthew Miller
> <mat...@fedoraproject.org>
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: OpenSSL 1.1.0 in Rawhide very soon

[Igor Gnatenko]

On Tue, Oct 11, 2016 at 6:08 PM, Tomas Mraz <tm...@redhat.com> wrote:
> On Út, 2016-10-11 at 15:27 +0200, Igor Gnatenko wrote:
>> On Tue, Oct 11, 2016 at 3:21 PM, Vít Ondruch <vondr...@redhat.com>
>> wrote:
>> >
>> > Just FTR, I opened Ruby upstream ticket asking about the OpenSSL
>> > 1.1.0
>> > support:
>> >
>> > https://bugs.ruby-lang.org/issues/12830
>> >
>> > Not sure if you'll have also some Fedora specific tracker 
>> Would be nice to get tracking bug created on RHBZ, so we can track
>> all
>> the packages.
>
> Created:
> https://bugzilla.redhat.com/show_bug.cgi?id=1383740
Thanks!

I opened couple of bugreports against my packages so I will try to fix
myself and notify upstream. Just wanted bug to track things to do.
>
> --
> Tomas Mraz
> No matter how far down the wrong road you've gone, turn back.
>   Turkish proverb
> (You'll never know whether the road is wrong though.)
>
>
> _______
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: OpenSSL 1.1.0 in Rawhide very soon

[Igor Gnatenko]

On Tue, Oct 11, 2016 at 3:21 PM, Vít Ondruch <vondr...@redhat.com> wrote:
> Just FTR, I opened Ruby upstream ticket asking about the OpenSSL 1.1.0
> support:
>
> https://bugs.ruby-lang.org/issues/12830
>
> Not sure if you'll have also some Fedora specific tracker 
Would be nice to get tracking bug created on RHBZ, so we can track all
the packages.
>
>
> Vít
>
>
>
>
> Dne 10.10.2016 v 16:29 Tomas Mraz napsal(a):
>> On So, 2016-10-08 at 13:37 +0200, Kevin Kofler wrote:
>>> Tomas Mraz wrote:
>>>> At worst if the patching of a package is highly non-trivial and the
>>>> upstream is not responsive we might have to drop the package from
>>>> Fedora.
>>>>
>>>> We do not want to keep 1.0.2 devel around as that could make it to
>>>> look
>>>> like the 1.0.2 is still fully "supported" in Fedora and there would
>>>> be
>>>> no incentive to switch to 1.1.0. Also to get any new features from
>>>> upstream OpenSSL we have to move to newer versions as they are
>>>> released
>>>> as the old versions get only bug fixes.
>>> IMHO, this is not acceptable. If the API of a library changes enough
>>> to
>>> warrant a compat package, you have to provide the -devel for the
>>> compat
>>> package as well. Dropping all the packages that don't build against
>>> the new
>>> incompatible version from Fedora is not a reasonable plan.
>> We will work on porting the dependent packages to the new API. If by
>> some reasonable deadline there are still some packages that are not
>> dead by other reasons and we are unable to port them we can add -devel
>> to the compat package. Note though that small changes in such packages
>> will be needed anyway as the include files of the compat package will
>> have to be in non-default include directory. (If the package doesn't
>> use pkgconfig to find the needed CFLAGS automatically.)
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: including EOL and vulnerable software in Fedora

[Igor Gnatenko]

On Mon, Oct 10, 2016 at 10:29 AM, Vít Ondruch <vondr...@redhat.com> wrote:
>
>
> Dne 9.10.2016 v 05:42 Nick Coghlan napsal(a):
>> On 8 October 2016 at 23:13, Kevin Kofler <kevin.kof...@chello.at> wrote:
>>> These python[23][1-9] packages are entirely unnecessary and should go away
>>> ASAP.
>> They're not unnecessary for Python developers, as if you want to make
>> sure you're not accidentally using any features from later versions of
>> Python, the only way to reliably check that is to actually test your
>> code on those older versions.
>
> While I understand you want to test against older pythons, I don't
> understand how you would do that, since I don't believe that "just"
> older python is enough. You typically need also some additional
> libraries. Therefore I'm afraid this won't stop just with older python,
> but will continue with another set of packages.
I think pip should be used for that along with/without virtalenv.
>
>
> Vít
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: F26 Self Contained Change: Jekyll

[Igor Gnatenko]

On Mon, Oct 10, 2016 at 10:39 AM, Vít Ondruch <vondr...@redhat.com> wrote:
> Is it F26 or F25 change?
I think F25 changes deadline is over, so it has been created for F26.
>
>
> Vít
>
>
>
> Dne 10.10.2016 v 10:30 Jan Kurik napsal(a):
>> = Proposed Self Contained Change: Jekyll =
>> https://fedoraproject.org/wiki/Changes/Jekyll
>>
>> Change owner(s):
>> * Björn Esser < besser82 AT fedoraproject DOT org >
>>
>>
>> Transform your plain text into static websites and blogs.
>>
>>
>> == Detailed Description ==
>> Jekyll is a simple, blog-aware, static site generator perfect for
>> personal, project, or organization sites. Think of it like a
>> file-based CMS, without all the complexity. Jekyll takes your content,
>> renders Markdown and Liquid templates, and spits out a complete,
>> static website ready to be served by Apache, Nginx or another web
>> server. Jekyll is the engine behind GitHub Pages, which you can use to
>> host sites right from your GitHub repositories.
>>
>> Jekyll does what you tell it to do — no more, no less. It doesn't try
>> to outsmart users by making bold assumptions, nor does it burden them
>> with needless complexity and configuration. Put simply, Jekyll gets
>> out of your way and allows you to concentrate on what truly matters:
>> your content.
>>
>>
>> == Scope ==
>> * Proposal owners: doing the packaging
>>
>> * Other developers: doing the reviews
>>
>> * Release engineering: N/A (not a System Wide Change)
>>
>> * Policies and guidelines: N/A (not a System Wide Change)
>>
>> * Trademark approval: N/A (not needed for this Change)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: F26 Self Contained Change: Jekyll

[Igor Gnatenko]

On Mon, Oct 10, 2016 at 10:50 AM, Marcin Juszkiewicz
<mjuszkiew...@redhat.com> wrote:
> W dniu 10.10.2016 o 10:30, Jan Kurik pisze:
>> = Proposed Self Contained Change: Jekyll =
>> https://fedoraproject.org/wiki/Changes/Jekyll
>
> Since when adding new package requires Change proposal?
I'ts done to get more eyes and to promote Fedora.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Orphaning libgit2 for EPEL*

[Igor Gnatenko]

Hello,

When I picked libgit2 after orphaning somehow I picked up EPEL
branches as well. But Unfortunately I don't have power nor wilingness
to maintain it for EPEL, so I orphaned it right now.

Feel free to pick it up!
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Orphaning libgit2 for EPEL*

[Igor Gnatenko]

Hello,

When I picked libgit2 after orphaning somehow I picked up EPEL
branches as well. But Unfortunately I don't have power nor wilingness
to maintain it for EPEL, so I orphaned it right now.

Feel free to pick it up!
-- 
-Igor Gnatenko
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: duplicate package on fresh install

[Igor Gnatenko]

On Sun, Oct 9, 2016 at 2:11 PM, Jaroslav Mracek <jmra...@redhat.com> wrote:
> There is another option: ``dnf remove --duplicated``
Basically it's an alias to command mentioned before, but anyhow it
doesn't exist in F25.
>
> Jaroslav
>
> On Mon, Sep 26, 2016 at 8:44 PM, stan <stanl-fedorau...@vfemail.net> wrote:
>>
>> On Mon, 26 Sep 2016 11:23:53 -0700
>> stan <stanl-fedorau...@vfemail.net> wrote:
>>
>>
>> > dnf remove $(dnf repoquery --installonly --latest-limit -3 -q)
>>
>> This is wrong! I copied the wrong line.  The actual command should be
>>
>> dnf remove $(dnf repoquery --duplicated --latest-limit -1 -q)
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



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

Re: [SO-NAME BUMP] jsoncpp 1.7.7 comes to rawhide (and maybe to fc25)

[Igor Gnatenko]

On Tue, Oct 4, 2016 at 10:18 AM, Björn Esser <fed...@besser82.io> wrote:
> Am 03.10.2016 um 06:10 schrieb Björn Esser:
>>
>> Chain-build is running:
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=15917326
>>
>>
>> Am 03.10.2016 um 05:38 schrieb Björn Esser:
>>>
>>> I'm upgrading jsoncpp to v1.7.7 in Rawhide.  This will bump the so-name
>>> to libjsoncpp.so.11.
>>>
>>> Affected packages:
>>> cmake
>>> engrid
>>> mrpt
>>> orthanc
>>> paraview
>>> pcl
>>> vfrnav
>>> vrpn
>>> vtk
>>>
>>> I'll chain-rebuild all affected packages when pushing the new version of
>>> jsoncpp.  If there isn't any trouble, I'll consider and prepare an update
>>> for fc25 as well.
>>>
>>> Cheers
>>>   Björn
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
> All packages have been rebuilt, except for 'paraview', which FTBFS [1] [2].
> It seems it needs a little patching for some small change in jsoncpp.  I
> will do that during the next few days.
I'm getting report that minetest has broken dependency on libjsoncpp.
Can you rebuild it as well?
>
> Cheers,
>   Björn
>
>
> [1]  https://koji.fedoraproject.org/koji/buildinfo?buildID=806450
> [2]  https://koji.fedoraproject.org/koji/buildinfo?buildID=806372
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: [HEADS UP] libtimidity-0.2.0 comes to rawhide

[Igor Gnatenko]

On Tue, Oct 4, 2016 at 10:42 AM, Igor Gnatenko <ignate...@redhat.com> wrote:
> Hi,
>
> I'm preparing update for new version. According to release notes[0],
> there is only API additions and couple of changes. I will rebuild all
> dependent packages:
> * gstreamer-plugins-bad-free
Rebuilt and patch sent upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=772503
> * moc
RPM Fusion package, no actions done.
> * openttd
Rebuilt without any problems.
>
> Before I build it in rawhide, I will try to build it in COPR.
>
> Thanks for attention!
>
>
> [0] 
> https://sourceforge.net/p/libtimidity/news/2016/09/libtimidity-new-stable-version-020/
> --
> -Igor Gnatenko



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

[HEADS UP] libtimidity-0.2.0 comes to rawhide

[Igor Gnatenko]

Hi,

I'm preparing update for new version. According to release notes[0],
there is only API additions and couple of changes. I will rebuild all
dependent packages:
* gstreamer-plugins-bad-free
* moc
* openttd

Before I build it in rawhide, I will try to build it in COPR.

Thanks for attention!


[0] 
https://sourceforge.net/p/libtimidity/news/2016/09/libtimidity-new-stable-version-020/
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Rawhide-20160930.n.2 compose check report

[Igor Gnatenko]

Pull Request sent: https://pagure.io/fedora-comps/pull-request/51

On Sat, Oct 1, 2016 at 11:17 AM, Igor Gnatenko <ignate...@redhat.com> wrote:
>   File 
> "/usr/lib64/python3.5/site-packages/pyanaconda/packaging/dnfpayload.py",
> line 537, in _select_group
> self._base.group_install(grp.id, types, exclude=exclude)
>
>   File "/usr/lib/python3.5/site-packages/dnf/base.py", line 1359, in
> group_install
> return self._add_comps_trans(trans)
>
>   File "/usr/lib/python3.5/site-packages/dnf/base.py", line 1281, in
> _add_comps_trans
> raise dnf.exceptions.MarkingError(it)
>
> dnf.exceptions.MarkingError: dnf-langpacks
>
>
> is that bug somewhere in DNF or it's just error of trying to install
> non-existing group?
>
>
> On Sat, Oct 1, 2016 at 11:12 AM, Fedora compose checker
> <rawh...@fedoraproject.org> wrote:
>> Missing expected images:
>>
>> Kde live i386
>> Workstation live i386
>> Kde live x86_64
>> Cloud_base raw-xz i386
>> Workstation live x86_64
>>
>> Failed openQA tests: 49/80 (x86_64), 14/15 (i386)
>>
>> New failures (same test did not fail in Rawhide-20160929.n.1):
>>
>> ID: 37588   Test: x86_64 Everything-boot-iso install_default
>> URL: https://openqa.fedoraproject.org/tests/37588
>> ID: 37589   Test: x86_64 Everything-boot-iso install_default@uefi
>> URL: https://openqa.fedoraproject.org/tests/37589
>> ID: 37590   Test: i386 Everything-boot-iso install_default
>> URL: https://openqa.fedoraproject.org/tests/37590
>> ID: 37591   Test: x86_64 Workstation-boot-iso install_default
>> URL: https://openqa.fedoraproject.org/tests/37591
>> ID: 37592   Test: x86_64 Workstation-boot-iso install_default@uefi
>> URL: https://openqa.fedoraproject.org/tests/37592
>> ID: 37593   Test: i386 Workstation-boot-iso install_default
>> URL: https://openqa.fedoraproject.org/tests/37593
>> ID: 37594   Test: x86_64 Atomic-boot-iso install_default
>> URL: https://openqa.fedoraproject.org/tests/37594
>> ID: 37597   Test: x86_64 Server-boot-iso install_default
>> URL: https://openqa.fedoraproject.org/tests/37597
>> ID: 37598   Test: x86_64 Server-boot-iso install_default@uefi
>> URL: https://openqa.fedoraproject.org/tests/37598
>> ID: 37618   Test: i386 Server-boot-iso install_default
>> URL: https://openqa.fedoraproject.org/tests/37618
>>
>> Old failures (same test failed in Rawhide-20160929.n.1):
>>
>> ID: 37599   Test: x86_64 Server-dvd-iso install_default_upload
>> URL: https://openqa.fedoraproject.org/tests/37599
>> ID: 37600   Test: x86_64 Server-dvd-iso install_default@uefi
>> URL: https://openqa.fedoraproject.org/tests/37600
>> ID: 37607   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
>> URL: https://openqa.fedoraproject.org/tests/37607
>> ID: 37608   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
>> URL: https://openqa.fedoraproject.org/tests/37608
>> ID: 37617   Test: x86_64 Server-dvd-iso install_updates_nfs
>> URL: https://openqa.fedoraproject.org/tests/37617
>> ID: 37619   Test: i386 Server-dvd-iso install_default
>> URL: https://openqa.fedoraproject.org/tests/37619
>> ID: 37620   Test: x86_64 universal install_btrfs@uefi
>> URL: https://openqa.fedoraproject.org/tests/37620
>> ID: 37621   Test: x86_64 universal install_ext3@uefi
>> URL: https://openqa.fedoraproject.org/tests/37621
>> ID: 37622   Test: x86_64 universal install_xfs@uefi
>> URL: https://openqa.fedoraproject.org/tests/37622
>> ID: 37623   Test: x86_64 universal install_lvmthin@uefi
>> URL: https://openqa.fedoraproject.org/tests/37623
>> ID: 37624   Test: x86_64 universal install_no_swap@uefi
>> URL: https://openqa.fedoraproject.org/tests/37624
>> ID: 37636   Test: x86_64 universal install_updates_img_local
>> URL: https://openqa.fedoraproject.org/tests/37636
>> ID: 37637   Test: x86_64 universal install_shrink_ext4
>> URL: https://openqa.fedoraproject.org/tests/37637
>> ID: 37638   Test: x86_64 universal install_shrink_ntfs
>> URL: https://openqa.fedoraproject.org/tests/37638
>> ID: 37639   Test: x86_64 universal install_european_language
>> URL: https://openqa.fedoraproject.org/tests/37639
>> ID: 37640   Test: x86_64 universal install_cyrillic_language
>> URL: https://openqa.fedoraproject.org/tests/37640
>> ID: 37643   Test: x86_64 universal install_package_set_minimal
>> URL: https://openqa.fedoraproject.org/tests/37643
>> ID: 37644   Test: x86_64 universal inst

Re: Fedora Rawhide-20160930.n.2 compose check report

[Igor Gnatenko]

/openqa.fedoraproject.org/tests/37649
> ID: 37650   Test: x86_64 universal install_delete_pata@uefi
> URL: https://openqa.fedoraproject.org/tests/37650
> ID: 37652   Test: x86_64 universal install_scsi_updates_img
> URL: https://openqa.fedoraproject.org/tests/37652
> ID: 37653   Test: x86_64 universal install_multi
> URL: https://openqa.fedoraproject.org/tests/37653
> ID: 37654   Test: x86_64 universal install_multi@uefi
> URL: https://openqa.fedoraproject.org/tests/37654
> ID: 37655   Test: x86_64 universal install_simple_encrypted
> URL: https://openqa.fedoraproject.org/tests/37655
> ID: 37656   Test: x86_64 universal install_simple_free_space
> URL: https://openqa.fedoraproject.org/tests/37656
> ID: 37657   Test: x86_64 universal install_multi_empty
> URL: https://openqa.fedoraproject.org/tests/37657
> ID: 37658   Test: x86_64 universal install_software_raid
> URL: https://openqa.fedoraproject.org/tests/37658
> ID: 37659   Test: x86_64 universal install_delete_partial
> URL: https://openqa.fedoraproject.org/tests/37659
> ID: 37660   Test: x86_64 universal install_btrfs
> URL: https://openqa.fedoraproject.org/tests/37660
> ID: 37661   Test: x86_64 universal install_ext3
> URL: https://openqa.fedoraproject.org/tests/37661
> ID: 37662   Test: x86_64 universal install_xfs
> URL: https://openqa.fedoraproject.org/tests/37662
> ID: 37663   Test: x86_64 universal install_lvmthin
> URL: https://openqa.fedoraproject.org/tests/37663
> ID: 37664   Test: x86_64 universal install_no_swap
> URL: https://openqa.fedoraproject.org/tests/37664
> ID: 37665   Test: x86_64 universal install_iscsi
> URL: https://openqa.fedoraproject.org/tests/37665
> ID: 37666   Test: x86_64 universal install_package_set_kde
> URL: https://openqa.fedoraproject.org/tests/37666
> ID: 37667   Test: x86_64 universal install_simple_encrypted@uefi
> URL: https://openqa.fedoraproject.org/tests/37667
> ID: 37668   Test: x86_64 universal install_simple_free_space@uefi
> URL: https://openqa.fedoraproject.org/tests/37668
> ID: 37669   Test: x86_64 universal install_multi_empty@uefi
> URL: https://openqa.fedoraproject.org/tests/37669
> ID: 37670   Test: x86_64 universal install_software_raid@uefi
> URL: https://openqa.fedoraproject.org/tests/37670
> ID: 37671   Test: x86_64 universal install_delete_partial@uefi
> URL: https://openqa.fedoraproject.org/tests/37671
> ID: 37674   Test: i386 universal install_package_set_minimal
> URL: https://openqa.fedoraproject.org/tests/37674
> ID: 37675   Test: i386 universal install_repository_http_graphical
> URL: https://openqa.fedoraproject.org/tests/37675
> ID: 37676   Test: i386 universal install_scsi_updates_img
> URL: https://openqa.fedoraproject.org/tests/37676
> ID: 37677   Test: i386 universal install_simple_encrypted
> URL: https://openqa.fedoraproject.org/tests/37677
> ID: 37678   Test: i386 universal install_software_raid
> URL: https://openqa.fedoraproject.org/tests/37678
> ID: 37679   Test: i386 universal install_btrfs
> URL: https://openqa.fedoraproject.org/tests/37679
> ID: 37680   Test: i386 universal install_ext3
> URL: https://openqa.fedoraproject.org/tests/37680
> ID: 37681   Test: i386 universal install_lvmthin
> URL: https://openqa.fedoraproject.org/tests/37681
> ID: 37683   Test: i386 universal upgrade_2_desktop_32bit
> URL: https://openqa.fedoraproject.org/tests/37683
> ID: 37684   Test: i386 universal install_package_set_kde
> URL: https://openqa.fedoraproject.org/tests/37684
>
> Passed openQA tests: 17/80 (x86_64), 1/15 (i386), 2/2 (arm)
>
> New passes (same test did not pass in Rawhide-20160929.n.1):
>
> ID: 37595   Test: arm Minimal-raw_xz-raw.xz 
> install_arm_image_deployment_upload
> URL: https://openqa.fedoraproject.org/tests/37595
> ID: 37596   Test: arm Minimal-raw_xz-raw.xz base_services_start_arm
> URL: https://openqa.fedoraproject.org/tests/37596
> ID: 37625   Test: x86_64 universal install_kickstart_hdd
> URL: https://openqa.fedoraproject.org/tests/37625
> ID: 37629   Test: x86_64 universal upgrade_kde_64bit
> URL: https://openqa.fedoraproject.org/tests/37629
> ID: 37630   Test: x86_64 universal upgrade_desktop_encrypted_64bit
> URL: https://openqa.fedoraproject.org/tests/37630
> ID: 37641   Test: x86_64 universal install_kickstart_firewall_disabled
> URL: https://openqa.fedoraproject.org/tests/37641
> ID: 37642   Test: x86_64 universal install_kickstart_firewall_configured
> URL: https://openqa.fedoraproject.org/tests/37642
> ID: 37651   Test: x86_64 universal install_kickstart_user_creation
> URL: https://openqa.fedoraproject.org/tests/37651
> ID: 37672   Test: x8

Re: Was perl removed from buildsys-build?

[Igor Gnatenko]

I remember that perl-generators were removed from deps of rpm-build.

On Sat, Oct 1, 2016 at 10:01 AM, Richard W.M. Jones <rjo...@redhat.com> wrote:
> In the RISC-V mass rebuild, some packages fail because Perl is
> missing.  However they don't have 'BuildRequires: perl'.
>
> One example is 'telnet':
>
> https://fedorapeople.org/groups/risc-v/logs/telnet/0.17-65.fc24/build.log
>
>   /var/tmp/rpm-tmp.ksu80z: line 36: perl: command not found
>   error: Bad exit status from /var/tmp/rpm-tmp.ksu80z (%build)
>
> http://pkgs.fedoraproject.org/cgit/rpms/telnet.git/tree/telnet.spec
>
>   No BuildRequires: perl
>
> [WARNING: The next URL may crash your browser]
> https://pagure.io/fedora-comps/blob/master/f/comps-f25.xml.in#_446
>
>   No perl in buildsys-build
>
> I have a vague recollection that this change was deliberate, and perl
> was removed from the "implicit" (buildsys-build) dependencies.
> However I cannot find anything about that.
>
> Is this right - are the packages themselves broken?
>
> If so I will add a BR: perl to the packages whenever I come across
> this problem.
>
> If not, what is the correct fix?  I believe our buildsys-build
> packages are complete and equivalent to x86 ones.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: Bind update (CVE-2016-2776)?

[Igor Gnatenko]

On Thu, Sep 29, 2016 at 10:08 AM, Tomas Hozza <tho...@redhat.com> wrote:
> On 09/29/2016 06:19 AM, Bojan Smojver wrote:
>> Could someone with sufficient access please spin up an update of bind
>> for F-24 and other flavours of Fedora. That CVE looks like a pretty
>> serious DoS. This has already been fixed in RHEL.
>>
>> Thanks,
>>
>
> Hi.
>
> I'll be pushing the updates shortly. The problem with Fedora is that we can 
> not prepare the update in advance as for RHEL, because everything (git repos, 
> update system, etc.) is public.
You mean before CVE has been published? Or what's the problem with being public?
>
> Regards,
> Tomas
> --
> Tomas Hozza
> Associate Manager, Software Engineering - EMEA ENG Mainstream RHEL
>
> PGP: 1D9F3C2D
> UTC+2 (CEST)
> Red Hat Inc. http://cz.redhat.com
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: Non-numeric lz4 package version

[Igor Gnatenko]

You do rsplit() by the '-'. Right part is R.A. you remove arch and get
release.

What exactly you want to do? RPM and DNF have proper --queryformat.

-Igor Gnatenko

On Sep 28, 2016 8:52 PM, "Richard W.M. Jones" <rjo...@redhat.com> wrote:

>
> Is it permitted to have a non-numeric Version field?
> The guidelines are at best unclear on this topic:
> https://fedoraproject.org/wiki/Packaging:Versioning#Version_Tag
>
> The lz4 package has version "r131":
> http://pkgs.fedoraproject.org/cgit/rpms/lz4.git/tree/lz4.spec#n5
>
> Corollary question: If I'm given an NVR string, how can I split it
> into name, version and release?  I was using the regexp
>
>   ^(.*?)-(\d.*)-([^-]+)$
>
> but that breaks on the lz4 package.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~
> rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://people.redhat.com/~rjones/virt-top
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] DNF 2.0 coming to Rawhide

[Igor Gnatenko]

Forgot to add, you can try to rebuild your components against our
nightly repos: 
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf-nightly/

On Tue, Sep 27, 2016 at 3:36 PM, Igor Gnatenko <ignate...@redhat.com> wrote:
> Hello,
>
> our team is on the way to release new version in upstream and push it
> to Rawhide as per accepted Change[0].
>
> We don't expect that it will break mashing repos, but we expect that
> it will break Anaconda (as it uses private functions from DNF
> (non-API)), there is PR for it[1] so I hope Anaconda maintainers will
> merge it in upstream and backport patch for Fedora.
>
> It will definitely break yumex-dnf (patch in upstream) and probably
> some other tools, but we tried to check as much of them as possible
> and provide patch.
>
>
> If no one has big objections, we are going to build updated packages
> on this Thursday (29 Sep 2016) and after that you can apply your
> patches and build updated packages (or you can push patches into
> dist-git, let me know package names and I will rebuild it once we will
> do release).
>
> If you see some bug - don't hesitate to approach me via mail/irc or file a 
> bug.
>
>
> [0] https://fedoraproject.org/wiki/Changes/DNF-2.0
> [1] https://github.com/rhinstaller/anaconda/pull/763
> --
> -Igor Gnatenko



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

[HEADS UP] DNF 2.0 coming to Rawhide

[Igor Gnatenko]

Hello,

our team is on the way to release new version in upstream and push it
to Rawhide as per accepted Change[0].

We don't expect that it will break mashing repos, but we expect that
it will break Anaconda (as it uses private functions from DNF
(non-API)), there is PR for it[1] so I hope Anaconda maintainers will
merge it in upstream and backport patch for Fedora.

It will definitely break yumex-dnf (patch in upstream) and probably
some other tools, but we tried to check as much of them as possible
and provide patch.


If no one has big objections, we are going to build updated packages
on this Thursday (29 Sep 2016) and after that you can apply your
patches and build updated packages (or you can push patches into
dist-git, let me know package names and I will rebuild it once we will
do release).

If you see some bug - don't hesitate to approach me via mail/irc or file a bug.


[0] https://fedoraproject.org/wiki/Changes/DNF-2.0
[1] https://github.com/rhinstaller/anaconda/pull/763
-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Upstream Release Monitoring builds for EL7 instead of Rawhide

[Igor Gnatenko]

I definitely fixed this issue:
https://github.com/fedora-infra/the-new-hotness/commit/2eed58c4ea09729f17e8c672196318d7028b0dba

On Thu, Sep 22, 2016 at 7:31 PM, Kevin Fenzi <ke...@scrye.com> wrote:
> On Wed, 21 Sep 2016 15:34:07 -0400
> Avram Lubkin <av...@rockhopper.net> wrote:
>
>> Seems like this issue is almost a year old.
>
> Sadly so. ;(
>
> If anyone would like to work on it they would be most welcome.
>
> Folks in #fedora-apps would be happy to answer any questions you have
> about the setup.
>
> kevin
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



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

Re: Get list of latest builds from Koji

[Igor Gnatenko]

$ koji list-tagged --inherit --latest f$FVER-updates-testing-pending $PKG

On Tue, Sep 20, 2016 at 3:50 PM, Richard W.M. Jones <rjo...@redhat.com> wrote:
>
> Is there a way to get a list of the latest builds out of Koji?
> Especially builds from a particular tag/target (f25).
>
> I tried a few things, but none of them are ideal:
>
> (1) There is an RSS feed (http://koji.fedoraproject.org/koji/recentbuilds)
> but it only contains a handful of builds.
>
> (2) `koji latest-pkg --all f25` shows the highest NVR of all packages
> in f25.  Unfortunately when I diffed the output over about an hour, it
> never changed.
>
> (3) `koji list-tasks` seems like another candidate, but it only goes
> back a few dozen builds.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: How to obsolete a subpackage?

[Igor Gnatenko]

On Wed, Sep 14, 2016 at 4:28 PM, David Howells <dhowe...@redhat.com> wrote:
> I need to obsolete one of the arch subpackages in the cross-binutils rpm (and
> also in the cross-gcc rpm) because binutils no longer supports that arch
> (sh64).
>
> Just marking the appropriate subpackage as obsoleted in the specfile for the
> cross-binutils-common subpackage causes dnf to complain:
>
> warthog>sudo dnf upgrade 
> ./noarch/cross-binutils-common-2.27-1.fc26.noarch.rpm ./x86_64/binutils-*
> Last metadata expiration check: 0:20:38 ago on Wed Sep 14 15:06:27 2016.
> Error: package binutils-sh64-linux-gnu-2.26.1-1.fc24.x86_64 requires 
> cross-binutils-common = 2.26.1-1.fc24, but none of the providers can be 
> installed
> (try to add '--allowerasing' to command line to replace conflicting packages)
>
> Is this the right way to do things?
Can you show diff what you did?
>
> David
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Handling bugs which are fixed in upstream, but not released yet

[Igor Gnatenko]

On Wed, Sep 14, 2016 at 2:45 PM, Josh Boyer <jwbo...@fedoraproject.org> wrote:
> On Wed, Sep 14, 2016 at 8:41 AM, Igor Gnatenko <ignate...@redhat.com> wrote:
>> Hi,
>>
>> I have question, how you handle bugs where fix already available in
>> upstream, but you don't want to backport that fix yet. What you do
>> with bug in our trash-box (bugzilla.redhat.com)?
>
> Why don't you want to backport it?
Sometimes it's too much work to backport if there are merge conflicts.
>
>> Probably you use whiteboard to indicate where it was fixed, close bug
>> and write into comment that it will be fixed in next upstream release
>> or ...?
>
> CLOSED->UPSTREAM or CLOSED->NEXTRELEASE both exist, but honestly I
> would probably put the bug in DEFERRED if you plan to fix it but can't
> yet for some reason.  A comment describing the timeline for when the
> fix will hit Fedora is probably sufficient.  The key for any of these
> states is to remember to actually do the fix.
>
> josh
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Handling bugs which are fixed in upstream, but not released yet

[Igor Gnatenko]

Hi,

I have question, how you handle bugs where fix already available in
upstream, but you don't want to backport that fix yet. What you do
with bug in our trash-box (bugzilla.redhat.com)?

Probably you use whiteboard to indicate where it was fixed, close bug
and write into comment that it will be fixed in next upstream release
or ...?
-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unversioned and >/=/>= obsoletes

[Igor Gnatenko]

I'm going to do mass bug filling for those packages which are still
not fixed. Are there some scripts to do that or I have to write my
own?

Unfixed packages:
https://ignatenkobrain.fedorapeople.org/broken-obsoletes/latest/broken-obsoletes.txt

On Fri, Sep 2, 2016 at 1:14 PM, Igor Gnatenko <ignate...@redhat.com> wrote:
> All guidelines mandate the use of  have some number of packages (179 source rpms -> 292 binary rpms) with
> unversioned Obsoletes or with >/=/>= Obsoletes.
>
> It is causing problems with upgrade (if package is getting re-added)
> or with 3rd-party repositories. Older package is obsoleting new
> package.
>
> Problem categories (in following text by "never" I mean latest N-2 releases):
>
> * Package/SubPackage was never built in Fedora
> Package "python" has "Obsoletes: python2" which was never built ->
> drop Obsoletes
> SubPackage "qpid-proton-c" of "qpid-proton" has "Obsoletes:
> qpid-proton" which was not the package for long time -> drop Obsoletes
>
> * Package replacement
> Package "storaged" has "Obsoletes: udisks2" -> take latest version
> from koji (2.1.7-1) and make Obsoletes versioned: udisks2 < 2.1.7-2
> storaged is not simple use-case as it replaces udisks2, but latter is
> still not retired.
>
> * "=" Obsoletes
> "rubygem-vte" has "Obsoletes: ruby-vte = 3.0.9-1.fc26" (probably it's
> macro in spec) which seems really weird as it will not obsolete
> F24/F25 with such version
>
> * Obsoletes by Provides
> It doesn't work to prevent undefined behavior. Imagine you have
> installed "A" and "B", both providing "C". Package "D" has "Obsoletes:
> C", it should not remove "A" and "B".
> ** %{?_isa}
> "glibc-headers" has "Obsoletes: glibc-headers(i686)". %{?_isa} is just
> text, it's not part of architecture or something else.
> ** Other provides
> "rubygem-http_connection" has "Obsoletes:
> rubygem(right_http_connection)". Latter is virtual provides.
>
> * Weird obsoletes (broken)
> "krb5-server" has "Obsoletes: krb5-server-1.14.3-8.fc26.i686".
> Basically it will not obsolete anything because it's threated as
> package name (and we definitely don't have such package name).
>
> * >/>= Obsoletes
> "vdsm" has "Obsoletes: vdsm-infra >= 4.16.0". It's almost same as
> unversioned Obsoletes. So it must not be used.
>
> Table of affected packages/maintainers:
> https://ignatenkobrain.fedorapeople.org/broken-obsoletes/2016-09-02/broken-obsoletes.txt
> --
> -Igor Gnatenko



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Question about Python applications / web applications

[Igor Gnatenko]

On Mon, Sep 12, 2016 at 4:32 PM, Germano Massullo
<germano.massu...@gmail.com> wrote:
> 2016-09-12 15:37 GMT+02:00 Igor Gnatenko <ignate...@redhat.com>:
>> It depends on application/we-application.
>> If it's not supposed to "import foo", then it's fine to build only one 
>> version.
>
> Does the following review request fall into that case?
> python-django-netjsongraph - Reusable django app for collecting and
> visualizing network topology
> https://bugzilla.redhat.com/show_bug.cgi?id=1369213
Well, you package it -> you tell us if it fall into that case ;)

If you don't know what you package probably it's better to not package it?
> ___
> python-devel mailing list
> python-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: Reviews Weekly

[Igor Gnatenko]

On Mon, Sep 12, 2016 at 12:09 PM,  <nob...@fedoraproject.org> wrote:
> Start Date: 2016-09-05 10:08:02.140226
> End Date: 2016-09-12 10:08:02.140226
>
> Lokesh Mandvekar : 4
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1373623 glide
> https://bugzilla.redhat.com/show_bug.cgi?id=1373913 golint
> https://bugzilla.redhat.com/show_bug.cgi?id=1373612 
> golang-github-Masterminds-vcs
> https://bugzilla.redhat.com/show_bug.cgi?id=1373551 
> golang-github-Masterminds-semver
>
>
> Raphael Groner : 2
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1344294 warsow-data
> https://bugzilla.redhat.com/show_bug.cgi?id=1202064 knock
>
>
> gil cattaneo : 2
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1374642 
> perl-Number-Range
> https://bugzilla.redhat.com/show_bug.cgi?id=1373244 
> perl-Path-Iterator-Rule
>
>
> Igor Gnatenko : 1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1349380 libzmf
>
>
> Javier Peña : 1
Please fix unicode issues ;)
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1370291 
> python-tenacity
>
>
> Jitka Plesnikova : 1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1373155 
> perl-Test-Toolbox
>
>
> Lumír Balhar : 1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1373450 esptool
>
>
> Martin Bříza : 1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1370611 python-serpy
>
>
> Matthias Runge : 1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1373003 
> rubygem-string-scrub
>
>
> Michael Simacek : 1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1366843 
> openhft-chronicle-queue
>
>
> Michal Karm Babacek : 1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1372825 
> picketlink-bindings
>
>
> Miro HronÄ ok : 1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1372064 
> lulzbot-marlin-firmware
>
>
> Mukundan Ragavan : 1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1364777 fifechan
>
>
> Orion Poplawski : 1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=879740  python-evdev
>
>
> Parag AN(पराग) : 1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1368790 perl-App-PFT
>
>
> Petr Pisar : 1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1373243 
> perl-Test-Filename
>
>
> Rex Dieter : 1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1360258 
> qt5-qtserialbus
>
>
> Sandro Mani : 1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1357064 lumina-desktop
>
>
> Zbigniew Jędrzejewski-Szmek : 1
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1367699 
> python-sphinx-theme-py3doc-enhanced
>
>
>
> Completed Review Requests: 24
> This report was generated by bz-review-report.py.
> The original source is available at: 
> https://git.fedorahosted.org/cgit/triage.git/tree/scripts/bzReviewReport.py
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GDB: Recommends vs. Suggests and abrt->gdb->gcc dependency

[Igor Gnatenko]

 (gdb) compile print HUGE_VAL
> $1 = inf
>
> Without gcc-gdb-plugin GDB would print only:
> (gdb) compile print HUGE_VAL
> Could not load libcc1.so: libcc1.so: cannot open shared object file: 
> No such file or directory
>
> Additionally it is expected that future GDB will use
> (gdb) compile print EXPRESSION
> for any use of:
> (gdb) compile EXPRESSION
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: comiing to koji aarch64

[Igor Gnatenko]

On Sat, Sep 10, 2016 at 4:19 PM, Dennis Gilmore <den...@ausil.us> wrote:
> Hi All,
>
> We are in the process of importing aarch64 to the primary koji instance as
> part of https://fedoraproject.org/wiki/Architectures/
> RedefiningSecondaryArchitectures  The import and enablement of aarch64 is for
> rawhide only,  we expect to add power big and little endiian sometime before
> the mass rebuild.
>
> We will be making changes to the compose process early next week to enable
> aarch64 in the rawhide compose,  at the same time i386 we be moving from /pub/
> fedora/ to /pub/fedora-secondary/
>
> A further announcement will come when building of aarch64 is enabled
Nice! /me enabled aarch64 arch for LuaJIT few weeks ago.
>
>
> Thanks
>
> Peter and Dennis
> ___
> devel-announce mailing list
> devel-annou...@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please clean up unneeded files from fedorapeople.org groups and repos

[Igor Gnatenko]

On Fri, Sep 9, 2016 at 9:40 PM, Kevin Fenzi <ke...@scrye.com> wrote:
> On Fri, 9 Sep 2016 08:37:19 +0200
> Igor Gnatenko <ignate...@redhat.com> wrote:
>
>> Kevin, help me please with cleanup:
>>
>> [ignatenkobrain@people02 ~][PROD]$ rm -rf
>> /home/fedora/ignatenkobrain/public_git/*
>> rm: cannot remove
>> ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/20/3a73563e678017862cc45354588d40a967a57d’:
>> Permission denied
>> rm: cannot remove
>> ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/8b/cff8eb33b25bef2d995ce4bc420153f2c1aade’:
>> Permission denied
>> rm: cannot remove
>> ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/a8/3159425e2105565b79d0daeef7e16073d0d32a’:
>> Permission denied
>> rm: cannot remove
>> ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/e5/2ea1c393718f48e74abf0c2062b753cb542f4c’:
>> Permission denied
>> rm: cannot remove
>> ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/ef/56842f0422bf92e453ec47c8f1556bdeb04b77’:
>> Permission denied
>> rm: cannot remove
>> ‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/f0/5c6e5deddbcc835948588534b0c2f34248d6f6’:
>> Permission denied
>
> Removed.
Thanks!
>
> Those were files pushed by someone else into your repo. I would have
> thought acls would allow you to remove them, but the acls seem to have
> gotten lost somewhere.
I used recipe from our wiki with setfacl to give someone else access to repo.
>
> Anyhow, they are removed and thanks for cleaning up your space.
>
> kevin
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F26 System Wide Change: DNF 2.0

[Igor Gnatenko]

If it requires actions from releng, then it's system-wide change. But
it's not about changing existing process of building distro, it's just
bugfixing releng tools.

So I'm not sure.

On Fri, Sep 9, 2016 at 10:38 PM, Mathieu Bridon <boche...@daitauha.fr> wrote:
> Hi,
>
> On Fri, 2016-09-09 at 16:49 +0200, Jan Kurik wrote:
>> = Proposed System Wide Change: DNF 2.0 =
>
> This email says it is a system-wide change.
>
>> https://fedoraproject.org/wiki/Changes/DNF-2.0
>
> But this page keeps saying « not a System Wide Change ».
>
> Which is? :)
>
>
> --
> Mathieu
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to package a Git repository

[Igor Gnatenko]

Problem with tito as it doesn't really do proper archive for
build/release and doesn't work properly in many cases:
1. Version is specified in spec -> all builds will be unordered.
Example: Version: 2.0.0 -> 2.0.0-1.git.tree-ish
2. Replaces archive. Source: https://.../%{name}-%{version}.tar.gz is
404 as tito creates releases in %{name}-%{version}-X where X is
release. If we are talking about Github, then even you change URL to
proper it still doesn't work because %(auto)setup fails, as github
generates archive in %{name}-%{name}-%{version}-X format.
X. Requires some files in upstream repo

I would not recommend using tito. I would recommend to have spec in
upstream ONLY for reference, but have proper Fedora ones in our
dist-git.

On Fri, Sep 9, 2016 at 4:47 PM, John Florian <john.flor...@dart.biz> wrote:
> On Fri, 2016-09-09 at 11:25 +0200, Florian Weimer wrote:
>
> I would like to build (S)RPMs directly from a Git repository (which
> contains the .spec file in the top-level directory).  This is for a
> CI-style project, with a quick release cycle.
>
> I have a Lua script fragment which generates a proper SRPM with the
> mock-scm target in COPR, and which is also compatible with “fedpkg
> srpm”.  But rpmbuild strips leading path components from Source: and
> Patch: references, so this only works if all files are in a single
> directory.
>
> Are there any alternatives that work in COPR, EPEL and Fedora proper?
>
> I think it's strange that I have to put a tarball somewhere just for
> RPM's sake if there is no separate upstream, and there are no upstream
> releases as a result.  It's just an annoyance and yet another step that
> can go wrong in various ways.
>
>
> This is my situation with everything I package (privately for my employer).
> I went in circles for a while simply believing I had to be doing something
> wrong until I considered the fact that most people doing packaging are not
> the authors.  This all settled in completely when I began recalling the days
> of yore when one would download a tgz, extract, config, make, etc..  Still I
> think it's a shame that this isn't handled better.  With very large projects
> it's quite a waste of time to archive just to meet the expected input format
> only to have the process reversed immediately.
>
> That said, I do much as Igor has already mentioned.  My build process starts
> with tito but lands in our Koji.  I use the following Makefile without any
> changes for each of my projects to facilitate tito's
> tito.release.KojiGitReleaser:
>
> $ cat Makefile
> # Extract NVR from the spec while stripping any macros, specifically the
> # disttag macro.
> name := $(shell awk '/^Name:/{print $$2}' *.spec)
> version := $(shell \
>awk '/^Version:/{print gensub(/%{.*?}/, "", "g", $$2)}' *.spec \
>)
> release := $(shell \
>awk '/^Release:/{print gensub(/%{.*?}/, "", "g", $$2)}' *.spec \
>)
> # The treeish we'll archive is effectively the Git tag that tito created.
> treeish := ${name}-${version}-${release}
>
> # Koji's buildSRPMFromSCM method expects a target named "sources" which
> # ultimately must ensure that a tarball of the package's sources and its
> spec
> # file are present.  Our practice is to always keep a spec file in the Git
> # repository, but we must build the tarball on the fly to resemble an
> upstream
> # published work.
> sources:
>git archive \
>--output=${name}-${version}.tar.gz \
>--prefix=${name}-${version}/ \
>    ${treeish}
>
>
> Hope this helps!
> --
> John Florian <john.flor...@dart.biz>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to package a Git repository

[Igor Gnatenko]

In DNF CI we use rpm-gitoverlay[0], but due to RPM we have to prepare
archive from git, replace path for %(auto)setup, and some other magic,
so you can't use it as is in Fedora. But you can easily use it with
COPR as you don't have to follow all guidelines.

When I deal with one project I just do: $ rpm-gitoverlay build-package
-n libdnf rpm copr --owner ignatenkobrain --project libdnf
which does everything for me.


[0] https://github.com/ignatenkobrain/rpm-gitoverlay

On Fri, Sep 9, 2016 at 11:25 AM, Florian Weimer <fwei...@redhat.com> wrote:
> I would like to build (S)RPMs directly from a Git repository (which contains
> the .spec file in the top-level directory).  This is for a CI-style project,
> with a quick release cycle.
>
> I have a Lua script fragment which generates a proper SRPM with the mock-scm
> target in COPR, and which is also compatible with “fedpkg srpm”.  But
> rpmbuild strips leading path components from Source: and Patch: references,
> so this only works if all files are in a single directory.
>
> Are there any alternatives that work in COPR, EPEL and Fedora proper?
>
> I think it's strange that I have to put a tarball somewhere just for RPM's
> sake if there is no separate upstream, and there are no upstream releases as
> a result.  It's just an annoyance and yet another step that can go wrong in
> various ways.
>
> Thanks,
> Florian
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please clean up unneeded files from fedorapeople.org groups and repos

[Igor Gnatenko]

Kevin, help me please with cleanup:

[ignatenkobrain@people02 ~][PROD]$ rm -rf
/home/fedora/ignatenkobrain/public_git/*
rm: cannot remove
‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/20/3a73563e678017862cc45354588d40a967a57d’:
Permission denied
rm: cannot remove
‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/8b/cff8eb33b25bef2d995ce4bc420153f2c1aade’:
Permission denied
rm: cannot remove
‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/a8/3159425e2105565b79d0daeef7e16073d0d32a’:
Permission denied
rm: cannot remove
‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/e5/2ea1c393718f48e74abf0c2062b753cb542f4c’:
Permission denied
rm: cannot remove
‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/ef/56842f0422bf92e453ec47c8f1556bdeb04b77’:
Permission denied
rm: cannot remove
‘/home/fedora/ignatenkobrain/public_git/shiny.git/objects/f0/5c6e5deddbcc835948588534b0c2f34248d6f6’:
Permission denied


On Thu, Sep 8, 2016 at 9:20 PM, Kevin Fenzi <ke...@scrye.com> wrote:
> Greetings.
>
> There's a large amount of space used on fedorapeople.org for group
> projects:
>
> Filesystem   Size  Used Avail Use% Mounted on
> /dev/mapper/GuestVolGroup00-project  342G  328G   15G  96% /project
>
> This includes /project/repos/ (which is https://repos.fedorapeople.org)
>
> Please take a few minutes to look at any files you or your group may
> have there and delete anything you no longer need.
>
> You may also want to look at your /home directories on fedorapeople.org
> and clean up any unneeded files there as well.
>
> Thanks.
>
> kevin
>
> ___
> devel-announce mailing list
> devel-annou...@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Orphaned: elementry, evas-generic-loaders

[Igor Gnatenko]

Kevin, yeah, you are right. It will work as there is no -Release.

Didn't see this before.

On Thu, Sep 8, 2016 at 12:59 AM, Kevin Kofler <kevin.kof...@chello.at> wrote:
> Igor Gnatenko wrote:
>> +Obsoletes: evas-generic-loaders <= 1.17.0
>>
>> This is basically wrong because current version is 1.17.0-5%{?dist}.
>
> <= 1.17.0 should still match that, I think (because there's no -Release in
> there), but still, <= Obsoletes are usually a bad idea (< is safer).
>
> Kevin Kofler
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Orphaned: elementry, evas-generic-loaders

[Igor Gnatenko]

On Thu, Sep 8, 2016 at 5:34 AM, Christopher Meng <i...@cicku.me> wrote:
>
>
> On Thursday, September 8, 2016, Kevin Kofler <kevin.kof...@chello.at> wrote:
>>
>> I wrote:
>> > <= 1.17.0 should still match that, I think (because there's no -Release
>> > in
>> > there), but still, <= Obsoletes are usually a bad idea (< is safer).
>>
>> PS: To be clear, I would use either:
>> Obsoletes: evas-generic-loaders < 1.17.1
>> if I am sure that the version will never go back to 1.17.0, or:
>> Obsoletes: evas-generic-loaders < 1.17.0-100
>> to be safe. (It should catch all current and future EVRs on the branches
>> that still ship the old version (in the worst case, use Release: 99.1,
>> 99.2,
>> etc.), but still allow you to bring back evas-generic-loaders-1.17.0 if
>> needed.)
>
>
> 100 is not enough at all, even . Since efl has higher version, just use
> proper macros.
>
> Obsoletes: evas-generic-loaders <=  %{version}-%{release}
This is bad idea though.
>
>
> Obsoletes: evas-generic-loaders%{?_isa} <=  %{version}-%{release}
As I wrote week ago to ML, %{?_isa} is virtual provides and it will
never work for Obsoletes.
>
>
>
> --
>
> Yours sincerely,
> Christopher Meng
>
> http://cicku.me
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Orphaned: elementry, evas-generic-loaders

[Igor Gnatenko]

+Obsoletes: evas-generic-loaders <= 1.17.0

This is basically wrong because current version is 1.17.0-5%{?dist}.

On Wed, Sep 7, 2016 at 4:09 PM, Tom Callaway <tcall...@redhat.com> wrote:
> On 09/06/2016 03:48 AM, Peter Robinson wrote:
>> On Tue, Sep 6, 2016 at 2:32 AM, Ding Yi Chen <dc...@redhat.com> wrote:
>>> As elementry and evas-generic-loaders are merged to efl after 1.8.0.
>>>
>>> The elementry and evas-generic-loaders will be orphanded.
>>
>> Please actually actively retire them, rather than just orphaning then,
>> making sure you add the appropriate obsoletes to EFL to ensure a clean
>> upgrade for users.
>
> EFL should have the proper Provides/Obsoletes now. Lemme know if I
> screwed it up. :)
>
> ~tom
>
> ==
> Red Hat
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unversioned and >/=/>= obsoletes

[Igor Gnatenko]

On Fri, Sep 2, 2016 at 10:34 PM, Matthew Miller
<mat...@fedoraproject.org> wrote:
> On Fri, Sep 02, 2016 at 09:24:10PM +0200, Igor Gnatenko wrote:
>> DNF has nothing to do with Obsoletes. It's up to RPM how to handle it.
>
> DNF might not, but Yum did. Hence
> https://bugzilla.redhat.com/show_bug.cgi?id=1261034
It's different problem than what we are discussing here.

From all those use-cases only one doesn't work and we are working on
fixing that.
>
>
> --
> Matthew Miller
> <mat...@fedoraproject.org>
> Fedora Project Leader
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unversioned and >/=/>= obsoletes

[Igor Gnatenko]

On Fri, Sep 2, 2016 at 7:28 PM, Kalev Lember <kalevlem...@gmail.com> wrote:
> On 09/02/2016 06:57 PM, Stephen Gallagher wrote:
>> On 09/02/2016 12:54 PM, Robbie Harwood wrote:
>>> Stephen Gallagher <sgall...@redhat.com> writes:
>>>
>>>> On 09/02/2016 07:14 AM, Igor Gnatenko wrote:
>>>>>
>>>>> * Weird obsoletes (broken)
>>>>> "krb5-server" has "Obsoletes: krb5-server-1.14.3-8.fc26.i686".
>>>>> Basically it will not obsolete anything because it's threated as
>>>>> package name (and we definitely don't have such package name).
>>>>
>>>> This definitely looks odd... Robbie?
>>>
>>> This is part of something I was requested to add (from the RHEL
>>> packaging where we have lines like `Obsoletes:
>>> krb5-server-1.11.3-49.el7.i686`, added by a previous maintainer) wherein
>>> the 64-bit versions of packages need to obsolete the 32-bit versions
>>> because we run into problems if both are installed.
>>>
>>> If what's in the spec file is not the correct way to accomplish that,
>>> what is?  I am unable to find documentation for any of this.
>>>
>>
>> Is that because some machines at one point did have both installed? That's 
>> kind
>> of a mess. I'd recommend taking that discussion to
>> packag...@lists.fedoraproject.org and see what they recommend.
>
> I think the issue here is just that the syntax is wrong.
>
> Instead of what's right now,
>
> Obsoletes: krb5-server-1.11.3-49.el7.i686
>
> it should be:
>
> Obsoletes: krb5-server <= 1.11.3-49.el7.i686
>
> ... or something along those lines. Right now the problem is that dnf
> considers the whole string "krb5-server-1.11.3-49.el7.i686" to be a
> package name while the package name is really "krb5-server". This makes
> the obsoletes just plain not do anything right now since they don't
> match any package name.
DNF has nothing to do with Obsoletes. It's up to RPM how to handle it.

tl;dr You can't replace i686 with x86_64 package.
>
> --
> Kalev
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Intel Vulkan driver status

[Igor Gnatenko]

We need Vulkan loader which is now on review. I will take care of it ASAP.

On Fri, Sep 2, 2016 at 3:56 PM, Michael Cronenworth <m...@cchtml.com> wrote:
> Why is the Vulkan driver being left out right now?
>
> Here's the RFE[1] from July asking for it to be enabled.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1356229
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unversioned and >/=/>= obsoletes

[Igor Gnatenko]

On Fri, Sep 2, 2016 at 3:34 PM, Michael Schwendt <mschwe...@gmail.com> wrote:
> On Fri, 2 Sep 2016 13:14:13 +0200, Igor Gnatenko wrote:
>
>> All guidelines mandate the use of > have some number of packages (179 source rpms -> 292 binary rpms) with
>> unversioned Obsoletes or with >/=/>= Obsoletes.
>>
>> It is causing problems with upgrade (if package is getting re-added)
>> or with 3rd-party repositories. Older package is obsoleting new
>> package.
>
> Good luck with trying to get some packagers to fix such issues!
> I appreciate the effort as I've reported similar things many times before,
> but some packagers just don't respond in bugzilla or overwrite changes
> applied to git after waiting months for a reply.
Isn't this is a guidelines, so if packager ignores them - he should be punished?
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Unversioned and >/=/>= obsoletes

[Igor Gnatenko]

All guidelines mandate the use of  292 binary rpms) with
unversioned Obsoletes or with >/=/>= Obsoletes.

It is causing problems with upgrade (if package is getting re-added)
or with 3rd-party repositories. Older package is obsoleting new
package.

Problem categories (in following text by "never" I mean latest N-2 releases):

* Package/SubPackage was never built in Fedora
Package "python" has "Obsoletes: python2" which was never built ->
drop Obsoletes
SubPackage "qpid-proton-c" of "qpid-proton" has "Obsoletes:
qpid-proton" which was not the package for long time -> drop Obsoletes

* Package replacement
Package "storaged" has "Obsoletes: udisks2" -> take latest version
from koji (2.1.7-1) and make Obsoletes versioned: udisks2 < 2.1.7-2
storaged is not simple use-case as it replaces udisks2, but latter is
still not retired.

* "=" Obsoletes
"rubygem-vte" has "Obsoletes: ruby-vte = 3.0.9-1.fc26" (probably it's
macro in spec) which seems really weird as it will not obsolete
F24/F25 with such version

* Obsoletes by Provides
It doesn't work to prevent undefined behavior. Imagine you have
installed "A" and "B", both providing "C". Package "D" has "Obsoletes:
C", it should not remove "A" and "B".
** %{?_isa}
"glibc-headers" has "Obsoletes: glibc-headers(i686)". %{?_isa} is just
text, it's not part of architecture or something else.
** Other provides
"rubygem-http_connection" has "Obsoletes:
rubygem(right_http_connection)". Latter is virtual provides.

* Weird obsoletes (broken)
"krb5-server" has "Obsoletes: krb5-server-1.14.3-8.fc26.i686".
Basically it will not obsolete anything because it's threated as
package name (and we definitely don't have such package name).

* >/>= Obsoletes
"vdsm" has "Obsoletes: vdsm-infra >= 4.16.0". It's almost same as
unversioned Obsoletes. So it must not be used.

Table of affected packages/maintainers:
https://ignatenkobrain.fedorapeople.org/broken-obsoletes/2016-09-02/broken-obsoletes.txt
-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Orphaning packages

[Igor Gnatenko]

On Wed, Aug 31, 2016 at 11:37 AM, Mario Ceresa <mrcer...@gmail.com> wrote:
> Hi Antonio,
> I think Igor took ownership yesterday after I orphaned them
Yes, I took them and added all ACLs for Mario. In week or two I will
go through all bugs and will comment them and update packages.
>
> Best,
> Mario
>
> On Tue, 30 Aug 2016 at 15:09 Antonio Trande <anto.tra...@gmail.com> wrote:
>>
>> On 08/30/2016 11:26 AM, Mario Ceresa wrote:
>> > Dear all,
>> > I'm orphaning the following packages due to not enough time to be a
>> > proper mantainer:
>> >
>> > * dcmtk (https://admin.fedoraproject.org/pkgdb/package/rpms/dcmtk/)
>> > * gdcm (https://admin.fedoraproject.org/pkgdb/package/rpms/gdcm/)
>> >
>> > I'll still be around to help if needed, just can't be the main point of
>> > contact.
>> >
>> > Best,
>> >
>> > Mario
>> >
>>
>> These packages are maintained by other packagers; are they still active?
>>
>> --
>> ---
>> Antonio Trande
>> mailto: sagitter 'at' fedoraproject 'dot' org
>> http://fedoraos.wordpress.com/
>> https://fedoraproject.org/wiki/User:Sagitter
>> GPG Key: 0x6CE6D08A
>> Check on https://keys.fedoraproject.org/
>>
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [HEADS UP] LuaJIT 2.1.0-beta2 comes to Rawhide

[Igor Gnatenko]

On Mon, Aug 29, 2016 at 8:38 PM, Peter Robinson <pbrobin...@gmail.com> wrote:
> On Mon, Aug 29, 2016 at 6:21 PM, Igor Gnatenko <ignate...@redhat.com> wrote:
>> On Mon, Aug 29, 2016 at 2:10 PM, Igor Gnatenko <ignate...@redhat.com> wrote:
>>> I'm working on getting new luajit version for Rawhide. Affected packages:
>>>
>>> $ sudo dnf -q repoquery --alldeps --whatrequires luajit --srpm
>>> --queryformat="%{name}"
>>> cantor
>> Definitely bug in FindLuaJIT.cmake
>> -- Could NOT find LuaJIT (missing:  LUAJIT_INCLUDE_DIR)
>> https://bugzilla.redhat.com/show_bug.cgi?id=1371250
>>> csound
>> Same as above.
>> https://bugzilla.redhat.com/show_bug.cgi?id=1371257
>>> dnsdist
>>> efl
>>> hexchat
>>> knot-resolver
>>> love
>>> lua-fun
>> -> Failed due to:
>> /var/tmp/rpm-tmp.vqvKQr: line 33: lua: command not found
>> https://bugzilla.redhat.com/show_bug.cgi?id=1371238
>>> luajit
>>> minetest
>> Same about CMake. I will take care about this as it's my package.
>>> pdns-recursor
>>>
>>> I will try to rebuild this packages. Looks like there were no serious
>>> API changes (if there were any except adding new functions).
>>
>> I should definitely think about writing proper file and include it
>> into luajit, but unless this is done - just fix PATH_SUFFIXES in
>> FindLuaJIT.cmake.
>
> Great so you actively go and break a bunch of packages and throw it
> over the wall for others to fix. Why the sudden need to move to a beta
> that's been sitting there with no real movement upstream for nearly 6
> months?
There are ongoing development in git repo. It's same if you would say
why do we have 4.13-rc1 RPM in Fedora as it has been released 1 year
ago (or even more). There are aarch64 support, couple of improvements
in FFI and in JIT compiler.

If you will read more carefully you will find that only 3 packages
needs to be fixed. and fix is easy.
/PATH_SUFFIXES/s/luajit-2.0/luajit-2.1/ FindLuaJIT.cmake.
I'm not going to fix those packages myself as it's need to be sent to
upstream as well.

After all:
* 1 of packages I will fix myself
* 2 packages which are FTBFS, but easily fixable.
* 1 package which has nothing to do with this update as it was broken
even before
>
> Maybe you should have tested them _BEFORE_ you went and pushed it.
I tested efl, pdns-recursor, dnsdist and hexchat as most important
from this list and they worked. I don't see point why you complain.
>
> Peter



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [HEADS UP] LuaJIT 2.1.0-beta2 comes to Rawhide

[Igor Gnatenko]

On Mon, Aug 29, 2016 at 2:10 PM, Igor Gnatenko <ignate...@redhat.com> wrote:
> I'm working on getting new luajit version for Rawhide. Affected packages:
>
> $ sudo dnf -q repoquery --alldeps --whatrequires luajit --srpm
> --queryformat="%{name}"
> cantor
Definitely bug in FindLuaJIT.cmake
-- Could NOT find LuaJIT (missing:  LUAJIT_INCLUDE_DIR)
https://bugzilla.redhat.com/show_bug.cgi?id=1371250
> csound
Same as above.
https://bugzilla.redhat.com/show_bug.cgi?id=1371257
> dnsdist
> efl
> hexchat
> knot-resolver
> love
> lua-fun
-> Failed due to:
/var/tmp/rpm-tmp.vqvKQr: line 33: lua: command not found
https://bugzilla.redhat.com/show_bug.cgi?id=1371238
> luajit
> minetest
Same about CMake. I will take care about this as it's my package.
> pdns-recursor
>
> I will try to rebuild this packages. Looks like there were no serious
> API changes (if there were any except adding new functions).

I should definitely think about writing proper file and include it
into luajit, but unless this is done - just fix PATH_SUFFIXES in
FindLuaJIT.cmake.
> --
> -Igor Gnatenko



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unresponsive maintainer: mrceresa

[Igor Gnatenko]

On Mon, Aug 29, 2016 at 4:34 PM, Mario Ceresa <mrcer...@gmail.com> wrote:
> Dear Igor,
> Thanks for the prodding. I have all fedora related email in a separate box
> and I've not been reading them lately. I'm sorry for not replying earlier to
> you and even more so if that affected your productivity.
>
> Also August is traditionally summer time in Spain which usually means even
> less responsitivity ;).
Bug is open since past December ;)
>
> I also have to confess that I have almost no idea on how to fix the error on
> the ARM arch. If you are able to investigate the problem further, or to
> create a patch I'll be happy to apply it myself or to give you access to the
> repo.
Just report bug to upstream.
>
> Of course you are more than welcome to maintain/co-mantain all of my
> packages. It would be a great help and relief for me, as I'm only doing that
> in order not to lose them.
I will request ACLs.
>
> With best regards,
>
>
> Mario
>
> On Sat, 20 Aug 2016 at 21:20 Igor Gnatenko <ignate...@redhat.com> wrote:
>>
>> We have bug in InsightToolKit[0] for > half year that it doesn't work
>> properly on ARM, but maintainer doesn't respond neither to bugzilla
>> nor to email. It's blocking me from importing 4 packages as all of
>> them failing on ARM due to ITK bug.
>>
>> Probably it just needs update, probably some investigation. Would be
>> nice if we can reassign his packages to someone else.
>>
>> He is maintainer of:
>> * CableSwig
>> * CharLS
>> * InsightToolkit
>> * dcmtk
>> * expatpp
>> * gdcm
>> * libigtl
>> * octave-dicom
>> * rply
>> * vxl
>>
>> He is co-maintainer of:
>> * orthanc
>> * tinyxml2
>> * vtk
>>
>> I would be interested in taking care of: InsightToolkit, dcmtk, gdcm,
>> vxl, tinyxml2, vtk. As I have some number of packages depending on
>> those.
>>
>> [0] https://bugzilla.redhat.com/show_bug.cgi?id=1291010
>> --
>> -Igor Gnatenko
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[HEADS UP] LuaJIT 2.1.0-beta2 comes to Rawhide

[Igor Gnatenko]

I'm working on getting new luajit version for Rawhide. Affected packages:

$ sudo dnf -q repoquery --alldeps --whatrequires luajit --srpm
--queryformat="%{name}"
cantor
csound
dnsdist
efl
hexchat
knot-resolver
love
lua-fun
luajit
minetest
pdns-recursor

I will try to rebuild this packages. Looks like there were no serious
API changes (if there were any except adding new functions).
-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: OCB blockcipher mode - is it allowed?

[Igor Gnatenko]

On Sun, Aug 28, 2016 at 2:56 AM, Christopher <ctubb...@fedoraproject.org> wrote:
> On Sat, Aug 27, 2016 at 6:16 PM Igor Gnatenko <ignate...@redhat.com> wrote:
>>
>> Hi,
>>
>> I have some questions about OCB[0] and it's usage in Fedora.
>>
>> I wanted to package pycryptodome[1] and found that they implement OCB
>> in their code. From my POV (completely without any legal knowledge) it
>> seems that it's not completely free[2] as it's not allowed for
>> military use. It seems to be allowed without any restrictions only for
>> OpenSSL.
>>
>> What do you think? Looks like now we have mosh[3] packaged and it
>> includes OCB (so if it's not acceptable, it most probably should be
>> removed).
>>
>>
>> [0] http://web.cs.ucdavis.edu/~rogaway/ocb/
>> [1] https://pycryptodome.readthedocs.io/en/latest/
>> [2] http://web.cs.ucdavis.edu/~rogaway/ocb/license.htm
>> [3] https://mosh.org
>> --
>> -Igor Gnatenko
>>
>
> I'm not a lawyer, but it seems to me that OCB is available to be implemented
> under 4 different license options:
> 1. Any open source software licensed under an approved license by OSI or
> public domain.
> 2. General license for non-military use.
> 3. OpenSSL-specific use.
> 4. Special license from the patent owner.
>
> Only option 2 has the non-military restriction, and anything in Fedora would
> almost certainly fall under 1 or 3. So, I can't imagine there'd be a problem
> using the OCB patent in Fedora software. I'm actually not even sure why
> option 3 even exists, since it seems to be a subset of option 1. Regardless,
> it doesn't look like the non-military restriction of option 2 would apply if
> option 1 is used.
Unfortunately I don't know how licenses applies, so if program is
licensed under OSI-approved license then 2nd license doesn't apply
anymore?
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

OCB blockcipher mode - is it allowed?

[Igor Gnatenko]

Hi,

I have some questions about OCB[0] and it's usage in Fedora.

I wanted to package pycryptodome[1] and found that they implement OCB
in their code. From my POV (completely without any legal knowledge) it
seems that it's not completely free[2] as it's not allowed for
military use. It seems to be allowed without any restrictions only for
OpenSSL.

What do you think? Looks like now we have mosh[3] packaged and it
includes OCB (so if it's not acceptable, it most probably should be
removed).


[0] http://web.cs.ucdavis.edu/~rogaway/ocb/
[1] https://pycryptodome.readthedocs.io/en/latest/
[2] http://web.cs.ucdavis.edu/~rogaway/ocb/license.htm
[3] https://mosh.org
-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: __pycache__ in python2 directory? O_o

[Igor Gnatenko]

Looks like this is bug in brp-python-compile, but I fixed python-Flask
so it's not reproducible anymore ;)

On Sun, Aug 21, 2016 at 8:31 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 21 August 2016 at 08:24, Zbigniew Jędrzejewski-Szmek
> <zbys...@in.waw.pl> wrote:
>> On Sat, Aug 20, 2016 at 05:17:59PM +0200, Igor Gnatenko wrote:
>>> RPM build errors:
>>> Installed (but unpackaged) file(s) found:
>>>/usr/lib/python2.7/site-packages/__pycache__/site.cpython-35.pyc
>>>
>>>
>>> This is from build of Flask. Looks really weird.
>>>
>>> Also it has some weird file inside:
>>> /usr/lib/python3.5/site-packages/flask/testsuite/test_apps/lib/python2.5/site-packages/SiteEgg.egg
>>>
>>> Should we skip such things from RPM generator or we should remove that
>>> or what? Thoughts?
>>
>> Looks like a in the build system or packaging script.
>> Any automatic tools (like the RPM generator) should probably just ignore 
>> those,
>> just like Python itself does.
>
> This looks like RPM is flagging a potential bug in the Flask 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



-- 
-Igor Gnatenko
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: Unresponsive maintainer: golfu

[Igor Gnatenko]

On Sun, Aug 21, 2016 at 11:42 AM, Golo Fuchert <packa...@golotop.de> wrote:
> Hi Igor,
Hey,
>
> If you tried to contact me by email that email got lost. I'm investigating
> what went wrong there, I guess I pushed the last round of updates just
> around the time when F24 was finalized and so somehow it didn't get in. I
> can fix that later.
I definitely tried to contact you by mail some time ago.

Actually I fixed that bug for you today. Unfortunately I excluded
env_parallel thing as it is causing some problems.

Thanks for reply!
>
>
> On 08/21/2016 11:34 AM, Igor Gnatenko wrote:
>
> Looks like Golo is not responding neither to the bug[0] nor to email.
>
> [0] https://bugzilla.redhat.com/show_bug.cgi?id=1352647
> --
> -Igor Gnatenko
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Unresponsive maintainer: golfu

[Igor Gnatenko]

Looks like Golo is not responding neither to the bug[0] nor to email.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1352647
-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Unresponsive maintainer: mrceresa

[Igor Gnatenko]

We have bug in InsightToolKit[0] for > half year that it doesn't work
properly on ARM, but maintainer doesn't respond neither to bugzilla
nor to email. It's blocking me from importing 4 packages as all of
them failing on ARM due to ITK bug.

Probably it just needs update, probably some investigation. Would be
nice if we can reassign his packages to someone else.

He is maintainer of:
* CableSwig
* CharLS
* InsightToolkit
* dcmtk
* expatpp
* gdcm
* libigtl
* octave-dicom
* rply
* vxl

He is co-maintainer of:
* orthanc
* tinyxml2
* vtk

I would be interested in taking care of: InsightToolkit, dcmtk, gdcm,
vxl, tinyxml2, vtk. As I have some number of packages depending on
those.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1291010
-- 
-Igor Gnatenko
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Python 3.4 for Fedora 24+

[Igor Gnatenko]

On Thu, Aug 18, 2016 at 9:04 AM, Miro Hrončok <mhron...@redhat.com> wrote:
> On 17.8.2016 19:04, Nick Coghlan wrote:
>>
>> On 16 August 2016 at 20:36, Miro Hrončok <mhron...@redhat.com> wrote:
>>>
>>> On 11.8.2016 11:26, Miro Hrončok wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> As a follow up of our Flock discussion, I will build several Python
>>>> versions in Copr, for development purposes (such as testing your code
>>>> with tox on multiple Python versions).
>>>>
>>>> Those builds will be installable alongside regular python3/python
>>>> packages and will be normal packages, no software collections etc. One
>>>> flat package (i.e. no -libs, -devel...) with bundled setuptools and pip.
>>>>
>>>> First I've built Python 3.5 for Fedora 23, you can grab it here [1].
>>>>
>>>> If you try to use tox with it, you'll have to use Python 3 version
>>>> (python3-tox is the package and unfortunately also the command), due to
>>>> a bug in virtualenv [2].
>>>>
>>>> I would appreciate any feedback on the build, so I can build python34
>>>> package for Fedora 24+ in similar manner soon.
>>>>
>>>> Also python33 and python26 are planned.
>>>>
>>>> If those builds prove themselves useful I'll try to put them in Fedora
>>>> (with a strict guideline that forbids any other package to depend on
>>>> them).
>>>>
>>>> [1] https://copr.fedorainfracloud.org/coprs/g/python/python35/
>>>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1365941
>>>
>>>
>>>
>>> You can now also test Python 3.4 for Fedora 24 and 25.
>>>
>>> https://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 a "tox" section in the
>> sidebar at
>> https://developer.fedoraproject.org/tech/languages/python/python-installation.html
>> that covers using these COPR builds with tox for cross-version
>> testing?
>
>
> It would. My long term plan here actually is to put this in Fedora proper
> and make tox Recommend all the Pythons, so you could just dnf install tox
> and it would bring all the runtimes (and you could prevent it if you didn't
> want (actually I have no idea if we ahve some --without-recommends flag for
> dnf, but anyway...)).
dnf --setopt=install_weak_deps=false install tox
>
>>
>> Cheers,
>> Nick.
>>
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> python-devel mailing list
> python-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: Automatic Provides: Discussion summary and plan

[Igor Gnatenko]

It can't track/change BR/R's as RPM is Turing complete and impossible to parse.
Imagine, we have pythonXdist(foo) extracted from PyPI metadata, but in
Fedora we still need to add some more BR for that, so we add it. When
new release comes (still without added BR in upstream) rebase-helper
will not be helpful. It can change only version of spec.

On Mon, Aug 15, 2016 at 11:25 AM, Tomas Orsava <tors...@redhat.com> wrote:
> On 08/12/2016 05:40 PM, Petr Viktorin wrote:
>>
>> The idea with pyp2rpm is to work with the Python Packaging Authority so
>> that the upstream metadata *can* be converted automatically. Ideally Fedora
>> packagers would fix packaging problems upstream, rather than maintaining
>> spec files.
>> Ideas for a tool for *updating* spec files are also floating around.
>>
> There's already rebase-helper (it's an interactive tool as well as an
> automatic one) that specializes in updating spec files.
>
> ___
> python-devel mailing list
> python-devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org



-- 
-Igor Gnatenko
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org