Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages

[Zbigniew Jędrzejewski-Szmek]

On Wed, Aug 22, 2018 at 04:13:50PM -0500, Jason L Tibbitts III wrote:
> > "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:
> 
> ZJ> Can we patch rpm not to show this useless line?
> 
> In the context of what I wrote, there's no "useless line".  I assume
> you're talking about rpm -qi output, but I was being more general than
> that.  Certainly we wouldn't patch out the GROUP querytag, for example,
> or change the RPM header format.  The group field in the header will
> always contain some data, and if the specfile didn't specify a group
> then 'Unspecified' will be stored there.
> 
> Now, the 'rpm -qi' output is actually something you can change.  It's
> defined in /usr/lib/rpm/rpmpopt-(version).  I have no idea if the Fedora
> RPM maintainers, or upstream RPM, would be willing to patch that file,
> since it can show valid info and Fedora isn't the only place where
> people might acquire packages.  Plus I figure that if anyone really
> cared about what was shown there, we would have patched out the
> 'Relocations:' line about a decade ago.  Really, 'dnf info' output is
> probably more relevant at this point.
> 
> However, if you really don't want to see it, you can just put an 'rpm
> alias --info' line in /etc/popt or ~/.popt.  I don't believe that RPM
> query expressions are sufficiently powerful to suppress the Group: line
> if the group is 'Unspecified', but I'd be happy if I were wrong.

Yeah, I meant the output of 'rpm -qi'. It would be great to make
it simply skip the line instead of showing "Group   : Unspecified",
but only when %GROUP is really "Unspecified". AFAICS, rpm does not have
a syntax for this, but of course the syntax is helpfully completely
undocumented, so it's hard to say for sure.

Patching ~/.popt is an option, but I would prefer to see Group if it
is given.

I filed https://github.com/rpm-software-management/rpm/pull/532 for the 
Relocations: line.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SLBIXSSIBTW2YR62MWKKLTHGYV4XPEXN/

Re: libgsf build help - MinGW edition

[Daniel P . Berrangé]

On Wed, Aug 22, 2018 at 10:06:17PM -0500, Greg Hellings wrote:
> Recent versions of libgsf (since 1.14.43) have begun to fail to build in
> MinGW environments. The error is straightforward enough - a function
> signature definition differs between its forward declaration and its
> implementation. But I don't see any clear way that it differs. The same
> code compiles cleanly in the native libgsf with nary a hiccup. The specific
> error is as follows:
> 
> ../../gsf/gsf-input.c:632:1: error: conflicting types for
> 'gsf_input_set_modtime_from_stat'
>  gsf_input_set_modtime_from_stat (GsfInput *input,
>  ^~~
> In file included from ../../gsf/gsf.h:54,
>  from ../../gsf/gsf-input.c:24:
> ../../gsf/gsf-input-impl.h:67:10: note: previous declaration of
> 'gsf_input_set_modtime_from_stat' was here
>  gboolean gsf_input_set_modtime_from_stat (GsfInput *input,
>   ^~~
> make[2]: *** [Makefile:706: gsf-input.lo] Error 1
> 
> Anyone know what could be different here vs in native builds? I've pushed a
> copy of my development branch to my own fork of the mingw-libgsf repo (
> https://src.fedoraproject.org/fork/greghellings/rpms/mingw-libgsf). It
> lives in the branch named 1_14_44. There is nothing about it that should
> differ in compilation between f28 and current Rawhide.
> 
> I'm definitely stumped at this. The two declarations look the same to me,
> but obviously there's something hidden in the bowels of these headers that
> changes the definitions between those two places. Any help would be
> appreciated.

Given that the two declarations are identical, the difference must be in
the way they are being interpreted. The likely candidate for the cause
is the "struct stat" parameter.

Looking at the code in gsf-input.c, it pulls in gsf.h which pulls in
gsf-input-impl.h with one definition of the struct.

At this point, however, 'sys/stat.h' has not been included yet, so the
'struct stat' is likely an undefined type.

Later gsf-input.c includes  'sys/stat.h' and then after that the second
declaration of the function is done, which now sees the 'struct stat'
type.

IOW, moving the sys/stat.h include to the top of gsf-input.c should
fix this problem, or adding it to the top of gsf.h is probably even
better.

The reason for the difference is probably  the glib.h header file.
I expect that on native builds, it ends up pulling in a definition
of 'struct stat' from somewhere, while this does not happen on
Mingw platforms.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TYHH5GBK5ORS74V2Y5XW2ABSB33FB3FT/

Re: Non-responsive maintainer for python-pytz

[Manas Mangaonkar]

To work on this does one need to be sponsored ? If no & if the maintainer
doesn't repsond i can start work immediately tomorrow.

Recently began packaging would love to work on this.

On Thu, 23 Aug 2018, 12:23 Joseph D. Wagner,  wrote:

> It hasn't been updated in almost a year, and it's updates are sorely
> needed.
>
> Trying to get updated before the beta freeze.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1508227
>
> Joseph D. Wagner
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2GSZ5VJIDMGTVF7D7ABDROPX7KJWBPLU/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NFIJE6Y7CQKJF5SFUIIJLSUUABPVIS53/

Self Introduction

[Manas Mangaonkar]

Hello,

My name is Manas,i am a Computer Engineering student at the University of
Mumbai.

i recently began packaging with my first package being this
,and
would love to work on even more packages. I am wish to join the packager
group,thus seeking sponsorship.

You may find the bugzilla review request for my first package here
.

Learned about the fedora community effort during Google summer of
code,joined the mailing list saw a issue open and began working on it. Have
been using various tux distro's since a teen always wanted to
contribute,have been self taught.  Learned the ropes of packaging using the
irc fedora chat room.

I am mostly interested in packaging and maintaining python packages as i
use python a lot and would love to give back to the community.

My Github 

- Manas Mangaonkar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GSZFIHQTY6AEENZ3YEHXYEDSVMW7SAQI/

Dropping python2 Biopython on fedora 30+

[Antonio Trande]

Hello everyone.

Python2 Biopython is required by 'python-MDAnalysis' on fedora 30+
(other than 'openms', already modified).

Ask to the maintainer of 'python-MDAnalysis' (Dominik Mierzejewski -
rathann) if we are ready for switching to Python3 definitively.

Best regards.
-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2X2WCT3HS6PX5X65LJEC7ECQGK346D4A/

Re: Orphaning procedure for python-assimulo

[Antonio Trande]

What's your FAS account?

On 23/08/2018 03:16, Manas Mangaonkar wrote:
> Hey,
> 
> Kindly assign it to me.
> 
> On Wed, 22 Aug 2018, 23:32 Antonio Trande,  > wrote:
> 
> Hello everyone.
> 
> I'm leaving the maintenance of 'python-assimulo' package; if someone
> wishes take care of it, please reply here.
> 
> Regards.
> -- 
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x5E212EE1D35568BE
> GPG key server: https://keys.fedoraproject.org/
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VZLRSGRZEVHTDR6J3RIZT6ISZRCYYYVS/
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6SBICXFDIEZKGOZLZW3MM6V7AYD6PKUV/
> 

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x5E212EE1D35568BE
GPG key server: https://keys.fedoraproject.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AO53QG5B6ME3DVSEORLRRMYXTL5LVRVE/

Re: Non-responsive maintainer for python-simplejson

[Miro Hrončok]

On 23.8.2018 07:32, Joseph D. Wagner wrote:

It hasn't been updated in over a year, and it's updates are sorely needed.

Trying to get updated before the beta freeze.

https://bugzilla.redhat.com/show_bug.cgi?id=1462583


See also https://bugzilla.redhat.com/show_bug.cgi?id=1610474

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HZIKYEG5QRNHKUUMDCK6UOLWHUGXFFMT/

Re: kcov: code coverage for programs and python/shell scripts

[Dridi Boukelmoune]

> I just submitted a review request [1] for kcov [2] that I recently
> discovered. It has no relation to Linux's kcov and is more akin to
> lcov, except that all it needs is a binary with DWARF debuginfo
> instead of requiring compile-time instrumentation.
>
> I came across kcov when I was looking for a way to measure code
> coverage in a Rust project and I'm impressed. It supposedly has a low
> overhead, but so far I've been monitoring small single-threaded
> programs so I can't really tell. I haven't tested python and shell
> support, although I have cases where it would be relevant, but I don't
> have time yet.

Greetings,

I have been using it for a year now, and the only problem I had was to
upstream aarch64 support! (or technically write the patch)

Since it's currently not easy to run the test suite at packaging time,
and since the test suite is not really arch-aware anyway, it would be
great if someone with hardware could give it a try on architectures
other than x86_64:

https://bodhi.fedoraproject.org/updates/FEDORA-2018-b19a317636

Thanks,
Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XLA3Z7GYGALGGQXCAOOKPJ2OSQZHAC2J/

Re: Summary/Minutes from yesterday's FESCo meeting (2018-08-20)

[Kevin Kofler]

Zbigniew Jędrzejewski-Szmek wrote:
> #1957 F29 Change: Liberation Fonts 2
> https://pagure.io/fesco/issue/1957
> DECISION (+6, 0, 0)

Sigh!

Really nothing has changed since the decision in Fedora 19 to stick with 
Liberation 1, only 4 years have passed without any changes whatsoever to the 
"Liberation 2" fonts.

Liberation 1 is no longer developed upstream, but as far as I can tell, 
neither is Liberation 2.

"Liberation 2" fonts are essentially rebranded Google Croscore fonts. And 
those Google Croscore fonts are, in fact, already packaged in Fedora 
(https://src.fedoraproject.org/rpms/google-croscore-fonts). Why can't we 
just let Liberation be Liberation and Croscore be Croscore?

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DHMCBGMDZNW755ZWTKPMIE74EVLCNOG2/

Intent to retire python modules

[Miro Hrončok]

I'm going to retire (in a ~week):

https://src.fedoraproject.org/modules/python
https://src.fedoraproject.org/modules/python2
https://src.fedoraproject.org/modules/python2-bootstrap
https://src.fedoraproject.org/modules/python2-ecosystem
https://src.fedoraproject.org/modules/python3
https://src.fedoraproject.org/modules/python3-bootstrap
https://src.fedoraproject.org/modules/python3-ecosystem


This is f28 cruft from the "older modularity". Not used, not needed. 
Correct me if I'm wrong.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AP26AEJB5MO4MULOCAAOK3V2FPHDQANO/

Intend to bump soname of minizip (and provide minizip-compat)

[Patrik Novotny]

Hi all,

I intend to remove minizip from the zlib package and replace it with a more
maintained fork [1][2]. To preserve backwards compatibility and ease the
transition on maintainers of dependent packages, the idea is to provide
minizip-compat and minizip-compat-devel packages in the zlib minizip
package first.

Therefore, I would like to ask all maintainers of the packages depending on
minizip and/or minizip-devel to update their dependencies to minizip-compat
and minizip-compat-devel respectively.

For now this is just a "cosmetic" change without any breakages. However,
when all related packages will require minizip-compat I will build the new
minizip package with a soname bump.

Please keep in mind that the minizip-compat package is just a temporary
solution to give us some time and should be considered deprecated as soon
as I build the new minizip package.

Finally, here's a list of related packages:
chromium
libsbml
mingw-zfstream
mingw-zlib
qt5-qtwebengine
assimp
zfstream
R-Rcompression
gpsbabel
vxl
COPASI
psi
GLC_lib
qmc2
mingw-libkml
libdigidocpp
zipper
libCombine
xu4
blender
libsedml
collada-dom
quazip
psi-plus
vacuum-im
godot
sigil
libnuml
zlib
libkml
fritzing

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1615381
[2] https://github.com/nmoinvaz/minizip

-- 

Patrik Novotný

Associate Software Engineer

Red Hat 

panov...@redhat.com

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YSPZUBTKN6T5TTUZW5NOWUW7VBIRCOZY/

Re: Orphaning procedure for python-assimulo

[Manas Mangaonkar]

pac23


On Thu, Aug 23, 2018 at 2:17 PM, Antonio Trande 
wrote:

> What's your FAS account?
>
> On 23/08/2018 03:16, Manas Mangaonkar wrote:
> > Hey,
> >
> > Kindly assign it to me.
> >
> > On Wed, 22 Aug 2018, 23:32 Antonio Trande,  > > wrote:
> >
> > Hello everyone.
> >
> > I'm leaving the maintenance of 'python-assimulo' package; if someone
> > wishes take care of it, please reply here.
> >
> > Regards.
> > --
> > ---
> > Antonio Trande
> > Fedora Project
> > mailto 'sagitter at fedoraproject dot org'
> > GPG key: 0x5E212EE1D35568BE
> > GPG key server: https://keys.fedoraproject.org/
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > 
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/
> wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.
> fedoraproject.org/message/VZLRSGRZEVHTDR6J3RIZT6ISZRCYYYVS/
> >
> >
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.
> org/archives/list/devel@lists.fedoraproject.org/message/
> 6SBICXFDIEZKGOZLZW3MM6V7AYD6PKUV/
> >
>
> --
> ---
> Antonio Trande
> Fedora Project
> mailto 'sagitter at fedoraproject dot org'
> GPG key: 0x5E212EE1D35568BE
> GPG key server: https://keys.fedoraproject.org/
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
> fedoraproject.org/message/AO53QG5B6ME3DVSEORLRRMYXTL5LVRVE/
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y7MQGLX3S5KVS6QRNHOYKVSO3WUTMQ2T/

HEADS UP: Update to gmsh-4.0

[Sandro Mani]

Hi

I'm preparing an update to gmsh-4.0.0. They not only bumped the soname, 
but also renamed the library from libGmsh to libgmsh (case change). 
Also, they declared large portions of the API as private, and introduced 
new gmsh.h / gmshc.h / gmsh.h_cwrap headers instead. The private API is 
still installable, but officially unsupported. I'll be providing a 
gmsh-devel-private package for that. Similarly for python, there is now 
a gmsh.py API file, with the previous gmshpy wrapper declared private 
API, which I'll provide in a python3-gmsh-private package.


The only package depending on gmsh according to repoquery is getdp. I'll 
look at adapting that package as necessary.


If all goes to plan, I'll land gmsh-4.0.0 this weekend.

Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GY7TBTTJO2WURYTGAT2B33XML3SLJQYE/

Schedule for Thursday's FPC Meeting (2018-08-23 16:00 UTC)

[James Antill]

  Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2018-08-23 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.


  Local time information (via. uitime):

= Day: Thursday ==
2018-08-23 09:00 PDT  US/Pacific
2018-08-23 12:00 EDT  --> US/Eastern <--
2018-08-23 16:00 UTC  UTC   
2018-08-23 17:00 BST  Europe/London 
2018-08-23 18:00 CEST Europe/Berlin 
2018-08-23 18:00 CEST Europe/Paris  
2018-08-23 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2018-08-24 00:00 HKT  Asia/Hong_Kong
2018-08-24 00:00 +08  Asia/Singapore
2018-08-24 01:00 JST  Asia/Tokyo
2018-08-24 02:00 AEST Australia/Brisbane

  Links to all tickets below can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting


= Followups =

#topic #665 SSLCertificateHandling policy update
.fpc 665
https://pagure.io/packaging-committee/issue/665

#topic #667 Recommend use of systemd sandboxing directives
.fpc 667
https://pagure.io/packaging-committee/issue/667

#topic #693 Wiki:Packaging:RPMMacros
.fpc 693
https://pagure.io/packaging-committee/issue/693

#topic #703 Inconsistency between "General Naming" and "Case Sensitivity"
.fpc 703
https://pagure.io/packaging-committee/issue/703

#topic #714 let's kill file deps!
.fpc 714
https://pagure.io/packaging-committee/issue/714

#topic #719 Simplify packaging of forge-hosted projects
.fpc 719
https://pagure.io/packaging-committee/issue/719

#topic #726 Review for SELinux Independent Policy packaging Draft
.fpc 726
https://pagure.io/packaging-committee/issue/726

#topic #740 Add "%python_enable_dependency_generator" onto Python
.fpc 740
https://pagure.io/packaging-committee/issue/740

#topic #743 Add link to C/C++ build flag docs. in redhat-rpm-config
.fpc 743
https://pagure.io/packaging-committee/issue/743

#topic #775 Allow to have %{?suse_version} condition in spec file
.fpc 775
https://pagure.io/packaging-committee/issue/775

#topic #782 Forbid %{pythonX_site(lib|arch)}/* in %files 
.fpc 782
https://pagure.io/packaging-committee/issue/782

#topic #784 forbid globs for shared libraries as it conceals sonames
.fpc 784
https://pagure.io/packaging-committee/issue/784

= New business =

#topic #785 Crypto policies packaging guideline update
.fpc 785
https://pagure.io/packaging-committee/issue/785

#topic #788 Bootstrap Exception for rebar3
fpc 788
https://pagure.io/packaging-committee/issue/788

#topic #789 Use bconds everywhere
.fpc 789
https://pagure.io/packaging-committee/issue/789

= Open Floor =

  For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

  If you would like to add something to this agenda, you can:
   * Reply to this e-mail
   * File a new ticket at: https://pagure.io/packaging-committee
   * E-mail me directly
   * Bring it up at the end of the meeting, during the open floor topic.
 Note that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KYBCQZDT57OJEJAR4BTB6VX3X3AHN6YD/

Re: intel microcode license change?

[Michael Cronenworth]

On 08/20/2018 01:38 PM, Chris Murphy wrote:

I also don't like this "will not allow any
third party" b.s. as if Fedora has any responsibility or power to
prevent me (or any Fedora user) to do trivial things like benchmarking
the performance effects of these microcode updates. And so on...


So this news is hitting more outlets. Intel's new clause of no more benchmarking is 
pretty ridiculous. Am I wrong?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MMZ5JALD3XN2AUW3RZF62T7D5NDEGGXC/

Re: libgsf build help - MinGW edition

[Greg Hellings]

> --
>
> Date: Thu, 23 Aug 2018 08:04:15 +0100
> From: Daniel P. Berrangé 
> Subject: Re: libgsf build help - MinGW edition
> To: Development discussions related to Fedora
> 
> Message-ID: <20180823070415.ga23...@redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> On Wed, Aug 22, 2018 at 10:06:17PM -0500, Greg Hellings wrote:
> > Recent versions of libgsf (since 1.14.43) have begun to fail to build in
> > MinGW environments. The error is straightforward enough - a function
> > signature definition differs between its forward declaration and its
> > implementation. But I don't see any clear way that it differs. The same
> > code compiles cleanly in the native libgsf with nary a hiccup. The specific
> > error is as follows:
> >
> > ../../gsf/gsf-input.c:632:1: error: conflicting types for
> > 'gsf_input_set_modtime_from_stat'
> >  gsf_input_set_modtime_from_stat (GsfInput *input,
> >  ^~~
> > In file included from ../../gsf/gsf.h:54,
> >  from ../../gsf/gsf-input.c:24:
> > ../../gsf/gsf-input-impl.h:67:10: note: previous declaration of
> > 'gsf_input_set_modtime_from_stat' was here
> >  gboolean gsf_input_set_modtime_from_stat (GsfInput *input,
> >   ^~~
> > make[2]: *** [Makefile:706: gsf-input.lo] Error 1
> >
> > Anyone know what could be different here vs in native builds? I've pushed a
> > copy of my development branch to my own fork of the mingw-libgsf repo (
> > https://src.fedoraproject.org/fork/greghellings/rpms/mingw-libgsf). It
> > lives in the branch named 1_14_44. There is nothing about it that should
> > differ in compilation between f28 and current Rawhide.
> >
> > I'm definitely stumped at this. The two declarations look the same to me,
> > but obviously there's something hidden in the bowels of these headers that
> > changes the definitions between those two places. Any help would be
> > appreciated.
>
> Given that the two declarations are identical, the difference must be in
> the way they are being interpreted. The likely candidate for the cause
> is the "struct stat" parameter.
>
> Looking at the code in gsf-input.c, it pulls in gsf.h which pulls in
> gsf-input-impl.h with one definition of the struct.
>
> At this point, however, 'sys/stat.h' has not been included yet, so the
> 'struct stat' is likely an undefined type.
>
> Later gsf-input.c includes  'sys/stat.h' and then after that the second
> declaration of the function is done, which now sees the 'struct stat'
> type.
>
> IOW, moving the sys/stat.h include to the top of gsf-input.c should
> fix this problem, or adding it to the top of gsf.h is probably even
> better.
>
> The reason for the difference is probably  the glib.h header file.
> I expect that on native builds, it ends up pulling in a definition
> of 'struct stat' from somewhere, while this does not happen on
> Mingw platforms.
>
>
> Regards,
> Daniel
> --
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Your advice was perfect. When I then went to report the bug to libgsf
along with my hack-a-patch I found a pending MR for the change that
was better. Thanks!

--Greg
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HPTOJ5ZTZOQGJARQOJF42I4W4MPVYBPQ/

Re: Consistent CI Messages

[Petr Šplíchal]

On Tue, 21 Aug 2018 at 15:22, Jeremy Cline  wrote:
>
> Hi Petr,
>
> On 08/21/2018 11:50 AM, Petr Šplíchal wrote:
> > Hi,
> >
> > as part of bringing upstream and downstream workflows related to
> > testing one more step closer together and allow easier automation
> > tools development and sharing between Fedora, Red Hat Enterprise
> > Linux and other products, the CI team is proposing to use a
> > consistent format for the CI related messages:
> >
> > https://pagure.io/fedora-ci/messages
> >
> > The specification (currently describing koji-build and brew-build
> > messages) is written in self-documented YAML files defining a
> > JSON SCHEMA which can be used to validate the message format.
> > Included is also a set of example messages to get a quick start.
> >
> > Please, review the proposed format and share your feedback.
> > Thanks!
>
> I've only skimmed the format and I don't work on anything that consumes
> these messages, so I can't provide great feedback on that. A couple of
> quick notes on the schema itself, though:

Thanks for the review, Jeremy.

> * "generated_at" is in a human-readable format, but doesn't include the
>   timezone (UTC). It would be nice to include that, or use a machine-
>   readable format and keep it documented as being UTC. You should also
>   be able to enforce this with JSON schema's "date-time" type if you
>   opt to go the human-readable route.

Yes, this is expected to be UTC as defined by the spec here:
https://pagure.io/fedora-ci/messages/blob/master/f/schemas/common.yaml#_20
Also the description suggests using the ISO format so I guess we
should be set here.

> * URLs can be of type "uri" and JSON schema will enforce that.

That for the hint. I've updated schemas to specify format as well
(simply using uri as type did not work):
https://pagure.io/fedora-ci/messages/c/c0cdee9
Unfortunately it seems "python-jsonschema" does not enforce this.

> I'm curious, are you aware of https://fedora-messaging.readthedocs.io/
> and generally the plan for Fedora infrastructure to move to AMQP?
> fedora-messaging uses JSON schema as well and enforces the schema when
> sending or receiving.

Didn't know that. Thanks for the pointer! Will have a look. Do you
know what's the time frame when the migration should happen?

psss...

>
>
> --
> Jeremy Cline
> XMPP: jer...@jcline.org
> IRC:  jcline
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/APFPP6LKQSQGVA2TMGXWMM2CQSYFVTE7/

Re: Orphaning procedure for python-assimulo

[Iñaki Ucar]

El jue., 23 ago. 2018 a las 16:10, Manas Mangaonkar
() escribió:
>
> pac23
>

Manas, you need to be sponsored first to get access to the packager
group. Please, follow the guidelines:

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

>
> On Thu, Aug 23, 2018 at 2:17 PM, Antonio Trande  wrote:
>>
>> What's your FAS account?
>>
>> On 23/08/2018 03:16, Manas Mangaonkar wrote:
>> > Hey,
>> >
>> > Kindly assign it to me.
>> >
>> > On Wed, 22 Aug 2018, 23:32 Antonio Trande, > > > wrote:
>> >
>> > Hello everyone.
>> >
>> > I'm leaving the maintenance of 'python-assimulo' package; if someone
>> > wishes take care of it, please reply here.
>> >
>> > Regards.
>> > --
>> > ---
>> > Antonio Trande
>> > Fedora Project
>> > mailto 'sagitter at fedoraproject dot org'
>> > GPG key: 0x5E212EE1D35568BE
>> > GPG key server: https://keys.fedoraproject.org/
>> >

-- 
Iñaki Ucar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SPDNIZ55O3LVOQL6SICGMLIZIT5MR2ZN/

Re: Consistent CI Messages

[Jeremy Cline]

On 08/23/2018 10:57 AM, Petr Šplíchal wrote:
> On Tue, 21 Aug 2018 at 15:22, Jeremy Cline  wrote:
> 
>> * URLs can be of type "uri" and JSON schema will enforce that.
> 
> That for the hint. I've updated schemas to specify format as well
> (simply using uri as type did not work):
> https://pagure.io/fedora-ci/messages/c/c0cdee9
> Unfortunately it seems "python-jsonschema" does not enforce this.
> 

Ah, that's good to know.

>> I'm curious, are you aware of https://fedora-messaging.readthedocs.io/
>> and generally the plan for Fedora infrastructure to move to AMQP?
>> fedora-messaging uses JSON schema as well and enforces the schema when
>> sending or receiving.
> 
> Didn't know that. Thanks for the pointer! Will have a look. Do you
> know what's the time frame when the migration should happen?

There's a broker cluster in stg now, and bridges for the ZMQ publishers
and subscribers will be set up in the next week or two. Once all the
issues discovered there are fixed up we'll set up a production cluster
and applications can start to migrate. Optimistically, I'd say
mid-September?


-- 
Jeremy Cline
XMPP: jer...@jcline.org
IRC:  jcline
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5PIOGGC5OW6ZREF4RECKUD4KW4GHNDKN/

Re: Orphaning procedure for python-assimulo

[Robert-André Mauchin]

On jeudi 23 août 2018 15:14:13 CEST Manas Mangaonkar wrote:
> pac23
> 
> 
> On Thu, Aug 23, 2018 at 2:17 PM, Antonio Trande 
> 
> wrote:
> > What's your FAS account?
> > 
> > On 23/08/2018 03:16, Manas Mangaonkar wrote:
> > > Hey,
> > > 
> > > Kindly assign it to me.
> > > 
> > > On Wed, 22 Aug 2018, 23:32 Antonio Trande,  > > 
> > > > wrote:
> > > Hello everyone.
> > > 
> > > I'm leaving the maintenance of 'python-assimulo' package; if someone
> > > wishes take care of it, please reply here.
> > > 
> > > Regards.
> > > --
> > > ---
> > > Antonio Trande
> > > Fedora Project
> > > mailto 'sagitter at fedoraproject dot org'
> > > GPG key: 0x5E212EE1D35568BE
> > > GPG key server: https://keys.fedoraproject.org/
> > > 

You need to be sponsored first.



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UH47TYEU47P2CKC6BUPKSDSJQK6TVTTR/

Re: Consistent CI Messages

[Adam Williamson]

On Thu, 2018-08-23 at 15:45 +, Jeremy Cline wrote:
> On 08/23/2018 10:57 AM, Petr Šplíchal wrote:
> > On Tue, 21 Aug 2018 at 15:22, Jeremy Cline  wrote:
> > 
> > > * URLs can be of type "uri" and JSON schema will enforce that.
> > 
> > That for the hint. I've updated schemas to specify format as well
> > (simply using uri as type did not work):
> > https://pagure.io/fedora-ci/messages/c/c0cdee9
> > Unfortunately it seems "python-jsonschema" does not enforce this.
> > 
> 
> Ah, that's good to know.
> 
> > > I'm curious, are you aware of https://fedora-messaging.readthedocs.io/
> > > and generally the plan for Fedora infrastructure to move to AMQP?
> > > fedora-messaging uses JSON schema as well and enforces the schema when
> > > sending or receiving.
> > 
> > Didn't know that. Thanks for the pointer! Will have a look. Do you
> > know what's the time frame when the migration should happen?
> 
> There's a broker cluster in stg now, and bridges for the ZMQ publishers
> and subscribers will be set up in the next week or two. Once all the
> issues discovered there are fixed up we'll set up a production cluster
> and applications can start to migrate. Optimistically, I'd say
> mid-September?

 QA TIME ESTIMATE CONVERSION START>

INPUT: "mid-September"

"late October"

"early November"

"late November"

OUTPUT: "late December"

 QA TIME ESTIMATE CONVERSION END>

:P
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4KPTLKSSTVZS4LHL66XF2YBZOA76JT22/

copr-frontend: fix for webhook secrets leakage

[Michal Novotny]

Hello,

there have been security problem fixed in copr-frontend today. Basically by
forking, you could get to webhook secrets of an original project being
forked. Also the integration page where you can insert pagure api token was
actually available under certain URL if you knew how this URL should be
structured. Both of these problems are now fixed. See full details here:
https://lists.fedoraproject.org/archives/list/copr-de...@lists.fedorahosted.org/thread/VOOOVQ4VOZIB4GKXZWSX7REWCX3WVTLN/

We will do full security audits now to prevent any future problems like
this.
Sorry for this trouble
Copr team
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/JJ3T74WRH63AMZB6TS3S72KUME2IUT7H/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JJ3T74WRH63AMZB6TS3S72KUME2IUT7H/

Intent to retire: mingw-libdb

[Greg Hellings]

I intend to retire the mingw-libdb package. It failed to rebuild in
the latest Rawhide. I have no use for it, anymore, and maintaining
what is, essentially, abandonware by a company with no financial
reason to invest in the software is beyond my desire.

If you're interested in grabbing the package, let me know and I'll be
happy to transfer it. But it's run its course for me and I'm happy
enough to let it wither.

--Greg
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AJ3K4ZHSNPIGKDKXTYQX5Q76AD2H2PLR/

Re: intel microcode license change?

[Chris Murphy]

On Thu, Aug 23, 2018 at 8:27 AM, Michael Cronenworth  wrote:
> On 08/20/2018 01:38 PM, Chris Murphy wrote:
>>
>> I also don't like this "will not allow any
>> third party" b.s. as if Fedora has any responsibility or power to
>> prevent me (or any Fedora user) to do trivial things like benchmarking
>> the performance effects of these microcode updates. And so on...
>
>
> So this news is hitting more outlets. Intel's new clause of no more
> benchmarking is pretty ridiculous. Am I wrong?

I'm putting it in the category of general purpose transient
incompetency, because it is so worthy of ridicule it could never have
achieved the nefarious end goal an imaginative mind would imagine.

Also in that category, is I'm only finding the updated license
reported on Tom's Hardware and not Intel's blog or press release
pages. So, I'm chocking it up to Intel just stepping on their own dick
again. *shrug*

https://www.tomshardware.com/news/intel-cpu-microcode-benchmark-mitigation,37684.html



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/A26UUWQL5GT43FAPJNKUUT75ZNN7PJN3/

Re: Consistent CI Messages

[Richard W.M. Jones]

On Tue, Aug 21, 2018 at 12:50:57PM +0200, Petr Šplíchal wrote:
> Hi,
> 
> as part of bringing upstream and downstream workflows related to
> testing one more step closer together and allow easier automation
> tools development and sharing between Fedora, Red Hat Enterprise
> Linux and other products, the CI team is proposing to use a
> consistent format for the CI related messages:
> 
> https://pagure.io/fedora-ci/messages
> 
> The specification (currently describing koji-build and brew-build
> messages) is written in self-documented YAML files defining a
> JSON SCHEMA which can be used to validate the message format.
> Included is also a set of example messages to get a quick start.
> 
> Please, review the proposed format and share your feedback.

It was really clear if this refers to emails or some other kind of
message.  In any case I'd be more than happy if you just fixed the
subject lines of emails.  Attached is my previous rant on this topic
for reference :-)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--- Begin Message ---

Here are a small collection of subject lines of emails sent
automatically to me by various Fedora systems in the past few days:

Subject: upgradepath PASSED for FEDORA-2015-850e89be8b
Subject: [Fedora Update] [comment] auto-buildrequires-1.2-1.fc23
Subject: rjones's libguestfs-1.33.1-2.fc24 completed
Subject: rpmlint PASSED for libguestfs-1.33.1-2.fc24
Subject: Broken dependencies: libguestfs
Subject: ABRT report for package gnome-boxes has reached 10 occurrences
Subject: [Bug 1269975] svirt very occasionally prevents parallel libvirt [..]
Subject: Fedora 'packager' sponsor needed for suanand
Subject: sailer's mingw-sqlite-3.10.1.0-1.fc24 failed to build
Subject: libguestfs's builds are back to normal in f24
Subject: dchen pushed to ocaml-lwt (el6).  "New upstream version 2.2.0."

The only consistent thing is there's nothing consistent about them :-/

I'd like to propose a very lightweight "standard" for subject lines of
emails.

(1) The first word should be the package name which the email
concerns.  If the email is not about a package, but about a person,
then the first word should be the FAS username of that person.

(2) The second word should be the status, reflecting what the reader
needs to know or do, for example "succeeded", "failed", "submitted".

That's it!

The above subject lines might become (chopped to 72 characters to
simulate what you might see in a text-based email reader):

Subject: auto-buildrequires passed: upgradepath FEDORA-2015-850e89be8b
Subject: auto-buildrequires submitted: auto-buildrequires-1.2-1.fc23
Subject: libguestfs completed: rjones's libguestfs-1.33.1-2.fc24 build c
Subject: libguestfs passed: rpmlint libguestfs-1.33.1-2.fc24
Subject: libguestfs failed: Broken dependencies found in package libgues
Subject: gnome-boxes failed: ABRT report for package gnome-boxes has rea
Subject: selinux-policy comment: [Bug 1269975] svirt very occasionally p
Subject: suanand requested: Fedora 'packager' sponsor needed for suanand
Subject: mingw-sqlite failed: sailer's mingw-sqlite-3.10.1.0-1.fc24 fail
Subject: libguestfs passed: libguestfs's builds are back to normal in f2
Subject: ocaml-lwt pushed: dchen pushed to ocaml-lwt (el6).  "New upstre

Maybe you have some better ideas?

A related topic is headers, which could be used for filtering.
Various systems add headers -- see examples below -- but again there's
not much consistency and the headers aren't particularly useful for
filtering.

Rich.

X-Fedmsg-Topic: org.fedoraproject.prod.taskotron.result.new
X-Fedmsg-Category: taskotron
X-Fedmsg-Package: libguestfs

X-Bodhi-Update-Builds: auto-buildrequires-1.2-1.fc23
X-Bodhi-Update-Pushed: True
X-Bodhi-Update-Type: enhancement
X-Bodhi-Update-Release: F23
X-Bodhi-Update-Status: testing
X-Bodhi-Update-Request: stable
X-Bodhi-Update-Submitter: rjones
X-Bodhi-Update-Title: auto-buildrequires-1.2-1.fc23
X-Bodhi: fedoraproject.org

-- 
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
--- End Message ---
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RKMAEHQ5PZNDK2PLUHIEYHT6E3XEILPF/

Re: Consistent CI Messages

[Randy Barlow]

On 08/23/2018 01:34 PM, Adam Williamson wrote:
> 
> OUTPUT: "late December"

What about


OUTPUT: "late January"

OUTPUT: "late February"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZKKGUIV46NCZM2JBL6YBFMQW5TB4EBWC/

[HEADS UP] There will be no virtualenv-2 and virtualenv-3, just virtualenv

[Miro Hrončok]

We used to have /usr/bin/virtualenv-2 and /usr/bin/virtualenv in 
python2-virtualenv. /usr/bin/virtualenv-3 in python3-virtualenv.


As of https://bugzilla.redhat.com/show_bug.cgi?id=1599422 this will 
change on F29+. There will be just one /usr/bin/virtualenv.



If you need to specify python version of the created virtual 
environment, use --python/-p:


  $ virtualenv -p /usr/bin/python2.7 
  $ virtualenv -p python3.7 
  $ virtualenv -p pypy2 
  $ virtualenv -p /opt/tauthon/bin/tauthon2.8 

If you omit -p, the Python version will be 3.7 on F29+, 2.7 before that. 
I recommend always using the -p option explicitly to avoid surprises.



If you have Python 3.4+ (including PyPy), you can use the standard 
library venv module instead (I recommend that):


  $ python3.7 -m venv 
  $ pypy3 -m venv 

Unlike virtualenv, here the interpreter that runs the venv module is the 
same that will be used in the virtual environment.



If you really need to **run** virtualenv using python2, you can use -m:

  $ python2 -m virtualenv --python=python3.7 


If you need to BuildRequire virtualenv from your packages, you can use:

  BuildRequires: virtualenv

(once the change is done on F29+), or:

  BuildRequires: /usr/bin/virtualenv

(already now on any Fedora version)


PS virtualenv-2 and  virtualenv-3 were Fedora specific hacks.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CG3AOYHZTELQ5OUFRMLLQI3X2LSLUS7O/

Re: Consistent CI Messages

[Neal Gompa]

On Thu, Aug 23, 2018 at 4:18 PM Randy Barlow
 wrote:
>
> On 08/23/2018 01:34 PM, Adam Williamson wrote:
> > 
> > OUTPUT: "late December"
>
> What about
>
> 
> OUTPUT: "late January"
> 
> OUTPUT: "late February"

Also don't forget


OUTPUT: "late March"



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NAIRN65FH4IMAGZUC3VPMYKK6PBBUIWO/

Idea: let's use Pagure to track Changes

[Ben Cotton]

Hi community,

We've traditionally used the wiki for Change proposals because it's
the tool we had. But, it's not necessarily well-suited to the purpose.
But now we have Pagure, which can help address some of the
shortcomings of using the wiki: poor scriptability, no reporting, and
a lot of copy/paste.

So I've come up with a plan that would use Pagure instead:
https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges

You can read the full details on the wiki page above, but the general
idea is that we won't change the policy for Changes, just how we store
and manipulate them. My intent is to make it nearly seamless for the
community while giving us a platform for building on the process in
the future. Note that this would run parallel to Bugzilla for a
release or two and then replace Bugzilla for Changes tracking.

Because we're already moving with changes for Fedora 30 and because a
few Pagure features would make it smoother (primarily allowing issue
submitters to edit metadata), I'd like to implement this for Fedora
31. Before that, I'd like the community's feedback.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UXKUPP4WYMKZKAWZO66GZIKH5ALTSH77/

Re: Consistent CI Messages

[Adam Williamson]

On Thu, 2018-08-23 at 20:32 +0100, Richard W.M. Jones wrote:
> On Tue, Aug 21, 2018 at 12:50:57PM +0200, Petr Šplíchal wrote:
> > Hi,
> > 
> > as part of bringing upstream and downstream workflows related to
> > testing one more step closer together and allow easier automation
> > tools development and sharing between Fedora, Red Hat Enterprise
> > Linux and other products, the CI team is proposing to use a
> > consistent format for the CI related messages:
> > 
> > https://pagure.io/fedora-ci/messages
> > 
> > The specification (currently describing koji-build and brew-build
> > messages) is written in self-documented YAML files defining a
> > JSON SCHEMA which can be used to validate the message format.
> > Included is also a set of example messages to get a quick start.
> > 
> > Please, review the proposed format and share your feedback.
> 
> It was really clear if this refers to emails or some other kind of
> message.  In any case I'd be more than happy if you just fixed the
> subject lines of emails.  Attached is my previous rant on this topic
> for reference :-)

It's about message bus messages. For Fedora, fedmsg messages.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/U3NQDTYNEG5X6FENZMZGCRKFFB4QHVQE/

Re: Idea: let's use Pagure to track Changes

[Miro Hrončok]

On 23.8.2018 22:43, Ben Cotton wrote:

Hi community,

We've traditionally used the wiki for Change proposals because it's
the tool we had. But, it's not necessarily well-suited to the purpose.
But now we have Pagure, which can help address some of the
shortcomings of using the wiki: poor scriptability, no reporting, and
a lot of copy/paste.


Good idea!


So I've come up with a plan that would use Pagure instead:
https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges


> 6. FESCo votes on change.

On the Pagure ticket with the change or in a separate FESCo Pagure ticket?



You can read the full details on the wiki page above, but the general
idea is that we won't change the policy for Changes, just how we store
and manipulate them. My intent is to make it nearly seamless for the
community while giving us a platform for building on the process in
the future. Note that this would run parallel to Bugzilla for a
release or two and then replace Bugzilla for Changes tracking.


The good thing about Bugzilla trackers is that they can be used as... 
Bugzilla trackers. I mean you can block/depend other bugs on it.


See for example http://bugzilla.redhat.com/show_bug.cgi?id=PYTHON37 and 
the dependent bugs. Of course, this might be relevant to some kind of 
Changes only, so the Bugzilla tracker can be optional, but I'd rather 
keep it as part of the process.




Because we're already moving with changes for Fedora 30 and because a
few Pagure features would make it smoother (primarily allowing issue
submitters to edit metadata), I'd like to implement this for Fedora
31. Before that, I'd like the community's feedback.



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FQWOCTT4SOFQHWEXUL2G2HEZFTVY4ILA/

Fedora Rawhide-20180822.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 33/132 (x86_64), 6/24 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20180820.n.3):

ID: 268568  Test: x86_64 Server-dvd-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/268568
ID: 268605  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/268605
ID: 268649  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/268649

Old failures (same test failed in Rawhide-20180820.n.3):

ID: 268562  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/268562
ID: 268563  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/268563
ID: 268574  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/268574
ID: 268578  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/268578
ID: 268587  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/268587
ID: 268588  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/268588
ID: 268589  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/268589
ID: 268599  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/268599
ID: 268602  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/268602
ID: 268603  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/268603
ID: 268606  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/268606
ID: 268607  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/268607
ID: 268611  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/268611
ID: 268619  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/268619
ID: 268620  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/268620
ID: 268622  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/268622
ID: 268623  Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/268623
ID: 268635  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/268635
ID: 268636  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/268636
ID: 268639  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/268639
ID: 268640  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/268640
ID: 268641  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/268641
ID: 268645  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/268645
ID: 268659  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/268659
ID: 268660  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/268660
ID: 268661  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/268661
ID: 268669  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/268669
ID: 268681  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/268681
ID: 268682  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/268682
ID: 268685  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/268685
ID: 268687  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/268687
ID: 268692  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/268692
ID: 268693  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/268693
ID: 268694  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/268694
ID: 268702  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/268702
ID: 268703  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/268703
ID: 268709  Test: i386 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/268709

Soft failed openQA tests: 58/132 (x86_64), 16/24 (i386)
(Tests completed, but using a workaround for a known bug)

New 

Re: Idea: let's use Pagure to track Changes

[Vít Ondruch]

Could you please show us example of such change proposal? I somehow
cannot imagine the real benefit.

V.



Dne 23.8.2018 v 22:43 Ben Cotton napsal(a):
> Hi community,
>
> We've traditionally used the wiki for Change proposals because it's
> the tool we had. But, it's not necessarily well-suited to the purpose.
> But now we have Pagure, which can help address some of the
> shortcomings of using the wiki: poor scriptability, no reporting, and
> a lot of copy/paste.
>
> So I've come up with a plan that would use Pagure instead:
> https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges
>
> You can read the full details on the wiki page above, but the general
> idea is that we won't change the policy for Changes, just how we store
> and manipulate them. My intent is to make it nearly seamless for the
> community while giving us a platform for building on the process in
> the future. Note that this would run parallel to Bugzilla for a
> release or two and then replace Bugzilla for Changes tracking.
>
> Because we're already moving with changes for Fedora 30 and because a
> few Pagure features would make it smoother (primarily allowing issue
> submitters to edit metadata), I'd like to implement this for Fedora
> 31. Before that, I'd like the community's feedback.
>

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IVURLPA523CQJSONM5MOW2U7KCSWAKNY/

Re: Idea: let's use Pagure to track Changes

[Kevin Fenzi]

Sounds like a great idea to me. I'm in favor...

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YXHL2P7F6WWHA6RZAROSUH5PFYLOVKLD/

Re: Dropping python2 Biopython on fedora 30+

[Dominik 'Rathann' Mierzejewski]

Hello, Antonio.

On Thursday, 23 August 2018 at 11:05, Antonio Trande wrote:
> Hello everyone.
> 
> Python2 Biopython is required by 'python-MDAnalysis' on fedora 30+
> (other than 'openms', already modified).
> 
> Ask to the maintainer of 'python-MDAnalysis' (Dominik Mierzejewski -
> rathann) if we are ready for switching to Python3 definitively.

MDAnalysis claims to support python 3.4+ since 0.17.0, but I haven't
tried to build and run it with python3 yet. Please open a bugzilla
ticket to track this. PRs are of course welcome. Thank you for being
proactive on this.

Regards,
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JWQMQXD7MARX6BGRIWZJ6EBJ53DH5NLY/