Re: Non-responsive maintainer check for hguemar

[Haïkel]

Hi,

send me your FAS account and I'll transfer ownership to you of pyperclip.
You're welcome to contact me directly through email (I'm currently in
sick leave but I'll browse email from time to time).

Regards,
H.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fwd: Orphaning some packages (C++/Gtkmm)

[Haïkel]

Le mer. 10 févr. 2021 à 18:10, Zbigniew Jędrzejewski-Szmek
 a écrit :
>
> Hi,
>
> In case you didn't see bcotton's mail about pp status, please do.
>
> Zbyszek

I did, it helped deciding to actively reduce the scope.

Regards,
H.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fwd: Orphaning some packages (C++/Gtkmm)

[Haïkel]

Hello,

due to long-standing health issues, I'd like to focus on a smaller set
of packages and continue mentoring new packagers which helped me to
stay afloat during grim times.
Here's a list of packages that have no co-maintainers and are required
for other projects.
- cairomm
- gconfmm26
- libglademm24
-  gtkmm24
- gstreamermm
- glom
- goocanvasmm2 (only used by glom)

should not be picked up:
- libnotifymm
- plotmm

I might update this list, as I'll focus my attention into getting better.
Most other packages are co-maintained by either SIGs or
co-maintainers, but if you need access to a package that I maintain,
you can directly mail me.

Regards,
H.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: 15 nonresponsive maintainers

[Haïkel]

I'm still around, I had a kidney failure recently hence not able to answer.

Regards.
H.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Possibly non-responsive maintainer: hguemar

[Haïkel]

Le lun. 17 sept. 2018 à 08:12, Mattia Verga  a écrit :
>
> > Le dim. 16 sept. 2018 à 11:27, Fabio Valentini  > a écrit :
> >
> >
> > The policy mention that you have to try contacting the maintainer
> > *first*, you never sent me an email or pinged me on irc.
> > I don't like this kind of passive-aggressive approach, had you
> > contacted me, we would have sorted this out quickly, co-maintainers
> > are welcome.
> >
> > One more thing, when you want to contact someone in the project =>
> >  >
> > Regards,
> > H.
> >
>
> Trying to contact the maintainer directly before opening the unresponsive 
> maintainer policy and reply to bugs via email is right, BUT I would expect 
> bugzilla to be the first contact point and so maintainers should respond in 
> bugzilla first, not via email.
>
> Sometimes a "bug aknowledge, but it's in low priority list" message can keep 
> users calm...
>
> Mattia

(On the policy)

Yes, first attempt should be through bugzilla, but we are human
beings, so it happens that a direct ping is necessary.
The policy may be subject to interpretation, but it hints that this
process should be used when you *cannot* reach the maintainer.
If you have time to mail the list, you have time to mail the person first.

"and asks if anyone knows how to contact the maintainer." => It's
crystal clear (to me at least) that it assumes that you could not
reach the
maintainer through the email registered in FAS (we used to have
regular pings from the system to verify that users are still
monitoring these).

If you want access to a package that I happen to be a "Point of
Contact" (which is semantically different that owner and it's on
purpose), just ask.
Nobody owns anything in Fedora.

Regards,
H.


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

Re: Possibly non-responsive maintainer: hguemar

[Haïkel]

Le dim. 16 sept. 2018 à 11:27, Fabio Valentini  a écrit :
>
> Hi everybody,
>
> There are many open bugs assigned to hguemar, which he is not
> responding to at all. According to a quick bugzilla query, he doesn't
> seem to have responded to any of the bugs assigned to him since
> October 2017 (!).
>

Erm, I have been quite active in august on bugzilla, for instance, I
helped fixing many python3 FTBFS.


> Particularly important to me are the FTBFS reports for libgda, which
> has last been successfully built on f24 (!):
> https://koji.fedoraproject.org/koji/packageinfo?packageID=2321
>
> Since then, the package is essentially broken, and there are several FTBFS 
> bugs.
>
> for f26: https://bugzilla.redhat.com/show_bug.cgi?id=1423852
> for f28: https://bugzilla.redhat.com/show_bug.cgi?id=1556039
> for f29: https://bugzilla.redhat.com/show_bug.cgi?id=1604587
>
> The maintainer has not responded to any of these bugs despite multiple
> comments and needinfo requests. He also has not touched the libgda
> dist-git repository in 5 years according to the commit log.
>

Surprising for a project that had its last stable in 2015 and was
mostly dead since.
I hadn't touched it for a while, as it got updated regularly by the
desktop team.

> There are also other bugzilla bugs where other people have tried to
> reach him, without success, for example:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1560212
>

Incorrect, I did answer and yes I forgot about this.
Did you ask for access? No

> Additionally, several of his packages failed the f29 mass rebuild, and
> the bug reports have been sitting there unacknowledged:
>
> python-yolk: https://bugzilla.redhat.com/show_bug.cgi?id=1606007
> python-sexy: https://bugzilla.redhat.com/show_bug.cgi?id=1605903

These needs co-maintainers, sexy should have been retired long ago,
I kept them around as other packages depends on it.
Again, if you want perms, just ask!


> python-setproctitle: https://bugzilla.redhat.com/show_bug.cgi?id=1605902
> python-ldappool: https://bugzilla.redhat.com/show_bug.cgi?id=1605745
> python-daiquiri: https://bugzilla.redhat.com/show_bug.cgi?id=1605649

I missed these as they were not in the python37 FTBFS tracker.
I'll get them fixed today.

> plotmm: https://bugzilla.redhat.com/show_bug.cgi?id=1605479

Needs a co-maintainer

> gtksourceviewmm3: https://bugzilla.redhat.com/show_bug.cgi?id=1604292

This one has co-maintainers and was actively attended by the desktop team.

> glom: https://bugzilla.redhat.com/show_bug.cgi?id=1604130
>

Co-maintainers are welcome, otherwise, I'll deprecate that.

> Does anybody know how to contact Haïkel Guémar (hguemar), or has heard
> from him recently? According to fedora-active-user, he is - somewhat -
> active? If not, I will continue the non-responsive maintainer process
> according to the Policy.
>
> Fabio

The policy mention that you have to try contacting the maintainer
*first*, you never sent me an email or pinged me on irc.
I don't like this kind of passive-aggressive approach, had you
contacted me, we would have sorted this out quickly, co-maintainers
are welcome.

One more thing, when you want to contact someone in the project =>
@fedoraproject.org should always work.

Regards,
H.

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

Re: broken package needs attention: libgda

[Haïkel]

2018-06-10 22:46 GMT+02:00 Sérgio Basto :
> On Sun, 2018-06-10 at 18:27 +0200, Fabio Valentini wrote:
>> Hi,
>>
>> The "libgda" package is quite broken in fedora, which is impacting
>> dependent programs.
>>
>> - The last successful build of libgda was for the fedora 24 (!) mass
>> rebuild. No more recent builds succeeded, and the packages was
>> reported as FTBFS.
>> - Not even the latest version is packaged (5.2.2 instead of 5.2.4).
>>
>> This is leading to problems in all current releases of fedora. For
>> example, the mysql database provider can't be installed anymore,
>> because libgda wasn't rebuilt for soname bumps in mariadb/mysql.
>>
>> Packages depending on libgda include:
>>
>> - anjuta
>> - glom
>> - gnumeric-plugins-extras
>> - gtranslator
>> - noise
>> - sequeler
>>
>> Is there any procedure for dealing with a package that's obviously
>> outdated and broken (and has been for 3 fedora releases), but is
>> still depended on by other packages?
>>
>> There has been an open bug report [0] about the FTBFS issues, but no
>> actions have been taken so far by the package maintainer(s).
>>
>> Fabio
>>
>> [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1423852
>
>
> I see 3 patches there and we got another bug report  [1]
>
> The best would be add one pull request in src.f.o [2] , i.e do a fork
> apply the patch and submit one pull request .
>
>
> [1]
> https://bugzilla.redhat.com/show_bug.cgi?id=1556039
>
>
> [2]
>  https://src.fedoraproject.org/rpms/libgda/pull-requests
>
> --
> Sérgio M. B.
> ___
> 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/KGBVPAILSYUXYYWPOGECPPSCDYMICFIX/


Sending an email to libgda-owner would have raised the attention on
your patches.
I got a notification late night about and I planned to go through it
later today (currently, I am teaching a class and I still have my
$dayjob duty)

libgda is co-maintained with the desktop team but it seems that the
project is not anymore
maintained in GNOME upstream hence its sore state.

So first task is to apply those patches and possibly, send them
upstream. Second task is to determine if we should drop the packages
(and it includes all the bindings to libgda),
but I need more time for that.

Alternative is you want comaintainership, just ask, you're welcome :)

Regards,
H.
___
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/BV6IP6FF6VRJDJM4PILHC3LCK74WRYSF/

New SIG: OpenStack

[Haïkel]

Hi,

I'd like to announce the beginning of a new SIG: OpenStack.

During these last years, I've been more or less maintaining OpenStack
clients, and I'd like to pass over
that (burden) to a SIG.
OpenStack clients/libraries are quite tied to each other, so it is
difficult to maintain them without provenpackager
permissions, and it is also a lot of work to sync requirements, do the
testing. So we will be working with RDO project
to provide latest and validated OpenStack clients packaging.

We already have ten packagers who signed up [1], and we welcome anyone
who wants to help [2].

So what are our immediate plans:
1. create @openstack SIG group
2. transfer packages ownership to @openstack SIG
3. set up CI jobs to regularly test and validate Fedora OpenStack
clients packages.
4. automate packages syncing with RDO (still require human validation,
no bot!) [3]
5. Enjoy latest and validated OpenStack clients on Fedora.

For now, the focus will be solely on clients.

Regards,
H.


[1] Most of them are either upstream developers and/or active in RDO
and Fedora projects
[2] If you're new in packaging, feel free to join, I'd be happy to
mentor/sponsor you!
[3] RDO has already automated most packaging tasks, and has proper CI
to test against real OpenStack deployments
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Complicated problem: kiwi and kiwi-gtk conflict

[Haïkel]

2017-08-23 14:44 GMT+02:00 Miroslav Suchý :
> Dne 23.8.2017 v 11:40 Neal Gompa napsal(a):
>>
>> However, there's a problem. It seems python-kiwi already exists in
>> Fedora[4], and it's the kiwi-gtk framework[5].
>>
>> I'm not sure what to do in this scenario. I've requested from upstream
>> to rename the module[6], but I don't think they'll go for that,
>> especially since they actually do have the kiwi name in PyPI.
>>
>> So what can I do?
>
>
> Ask hguemar (owner of python-kiwi in fedora) to rename python-kiwi to
> python-kiwi-gtk.
>
> Mirek

Since it got renamed in pypi, ok, but Neal will have to review the
renamed package.

H.

> ___
> 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: Nonresponsive maintainer: attempting to contact kanarip

[Haïkel]

2017-06-23 12:39 GMT+02:00 James Hogarth :
> Hi,
>
> Has anyone heard from kanarip or able to contact him?
>
> I've been attempting to contact for this bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1223593
>
> If there's no response in one week an issue will be filed with FESCo
> following the nonrepsonsive maintainer policy to review the ownership
> status of the packages.
>
> For ruby maintainers please note that this has a significant impact on
> you, if you want to keep track of this, as he owns puppet, rubygems
> and ruby ...
>
> https://admin.fedoraproject.org/pkgdb/packager/kanarip/
>

You're making it sound like Puppet is unmaintained which is not accurate.
There are many comaintainers and provenpackagers working on it.

Regards,
H.

> Regards,
>
> James
> ___
> 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: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Haïkel]

2017-06-13 0:38 GMT+02:00  :
> In preparation for the Final Freeze on 2017-06-27 Release
> Engineering will retire all packages in Branched with broken dependencies and
> all packages depending on these. If you get this e-mail directly this affects
> at least one of your packages. Please fix the broken dependency as soon as
> possible.  If you know for sure that the package should be retired, please do
> so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
>   Package(co)maintainers  Status Change
> ===
> AcetoneISO spot   160 weeks ago
> OmegaT olea, mtasaka  160 weeks ago
> RackTables coec   160 weeks ago
> Raysebhtml, jussilehtola  160 weeks ago
> YafaRayluya, slaanesh 15 weeks ago
> asterisk   jsmith, gtjoseph, itamarjp,83 weeks ago
>lbazan, russellb
> atomicapp  vpavlin, golang-sig,   103 weeks ago
>jchaloup, lalatendu
> ayttm  mintojoseph160 weeks ago
> banshee-community-extensions   chkr, elsupergomez 160 weeks ago
> beacon satyak 160 weeks ago
> compat-gcc-34  jakub  160 weeks ago
> consul fpokorny, golang-sig,  74 weeks ago
>jchaloup, sspreitz
> eclipse-avrvladimirk, akurtakov   160 weeks ago
> eflspot, dchen, sereinit  114 weeks ago
> elemental  rhl27 weeks ago
> erlang-riak_pipe   peter, erlang-sig  160 weeks ago
> etcd   jchaloup, avesh, cypret,   110 weeks ago
>eparis, golang-sig,
>gscrivano, jcajka, lsm5,
>peter, walters
> fedora-dockerfiles adimania, lsm5, scollier   130 weeks ago
> floppy-support bruno  160 weeks ago
> fusionforgebeuc, nerville 136 weeks ago
> gcc-python-plugin  dmalcolm, jakub160 weeks ago
> gearmand   ktdreyer, blakegardner 160 weeks ago
> getdp  ignatenkobrain, group  80 weeks ago
>::neuro-sig, smani
> gif2pngsundaram   160 weeks ago
> git-annex  mathstuf, haskell-sig  160 weeks ago
> gofed  jchaloup, fale, golang-sig 115 weeks ago
> golang-github-docker-go-   jchaloup   65 weeks ago
> connections
> golang-github-docker-  fpokorny, eparis, jchaloup,95 weeks ago
> libcontainer   lsm5, vbatts
> golang-github-fsouza-go-   fpokorny, eparis, golang-  95 weeks ago
> dockerclient   sig, jchaloup, lsm5,
>maxamillion
> golang-github-gonum-matrix fpokorny, jchaloup 86 weeks ago
> golang-github-kubernetes-  fpokorny, jchaloup 86 weeks ago
> heapster
> golang-github-mistifyio-go-jchaloup   57 weeks ago
> zfs
> golang-github-samalba- fpokorny, golang-sig,  97 weeks ago
> dockerclient   jchaloup
> golang-googlecode-go-exp   fpokorny, golang-sig,  97 weeks ago
>jchaloup, lsm5, vbatts
> grass  devrim, neteler, oliver,   160 weeks ago
>pertusus, rezso, volter
> gyachi sundaram, ghosler  160 weeks ago
> homerunjmarrero   160 weeks ago
> iwhd   meyering, clalance, zaitcev160 weeks ago
> java-gnome abo160 weeks ago
> kf5-libkface   rdieter70 weeks ago
> ledger radford, jamielinux160 weeks ago
> libsmbios  mebrown, gunnersrini,  33 weeks ago
>praveenp
> lldb   airlied, daveisfera,   71 weeks ago
>jankratochvil, jvcelak,
>siddharths, tstellar
> meshlabbrouhaha   160 weeks ago
> mesos  

Re: Self Introduction: Stephen Kitt

[Haïkel]

2017-02-23 18:48 GMT+01:00 Stephen Kitt :
> Hi everyone,
>
> As part of the "join the package collection maintainers" process, I'd like to
> introduce myself — I've just submitted my first review request
> (https://bugzilla.redhat.com/show_bug.cgi?id=1426333).
>
> I'm a long-standing free software user and packager, in the Debian world
> (https://qa.debian.org/developer.php?login=skitt). My packaging interests
> cover a wide spectrum, from games and emulators to toolchains and random
> interesting pieces of software. Some of you might have seen me at Devconf
> where I gave a presentation contrasting the processes for joining Debian and
> Fedora as a packaging contributor
> (https://www.youtube.com/watch?v=pGQFZPA6r8w). I work for Red Hat but
> packaging isn't a big part of my day job (although the request above is
> submitted using my @redhat.com account — it's for OpenDaylight, which is what
> I work on).
>
> I'm looking forward to adding some interesting software to Fedora!
>
> Regards,
>
> Stephen


Hi Stephen,

Welcome to see you here :)
Knowing Stephen afk, I trust him as a FOSS hacker and keen expert in (Debian)
packaging so I'm willing to sponsor him.

Regards,
H.

> ___
> 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: MongoDB in EPEL7

[Haïkel]

2016-10-31 14:25 GMT+01:00 Marek Skalický :
> Hi,
> current situation:
> EPEL6 - MongoDB 2.4.x
> EPEL7 - MongoDB 2.6.x
>
> Upstream supports only upgrade to next major version. So from 2.4 it is
> supported only to 2.6.
> Therefore I kept MongoDB 2.6 in EPEL7 (even two next major versions are
> released).
>
> But MongoDB 2.6 is going to EOL (probably this week), so MongoDB in
> EPEL7 will be unsupported.
>
> How to solve this - what EPEL/Fedora guidelines says about upgrades?
> Upgrade EPEL6 to EPEL7? Or keep unsupported version in EPEL7?
>

If it's unsupported upstream, you need to send a heads-up on EPEL m-l,
and wait for comments.
Then, just push the update.

I'm working on upgrading MongoDB to 3.2 in the CentOS SIGs space, it
will require a //-installable boost package (I have a working boost159
package) but I'd be glad to share the work.

Regards,
H.

> Thanks,
> Marek
> ___
> 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: Update python-django EPEL7

[Haïkel]

2016-08-16 19:11 GMT+02:00 Igor Gnatenko :
> It's against policies. Currently python-django has version 1.6. And
> 1.8 is major release.
>

Wrong.
Django 1.8 is an Long-Term Support version (supported until April,
2018) while 1.6 support ended in April, 2015 (so one year without
security updates ...).
https://www.djangoproject.com/download/#supported-versions
For EPEL, it would be smarter to stick to LTS releases, rather than
sticking to unmaintained releases.

Moreover, updates policies are guidelines to prevent mistakes not
absolute rules.

> On Tue, Aug 16, 2016 at 6:17 PM, Germano Massullo
>  wrote:
>> Hello, I would like to ask if it is possible to update python-django
>> for EPEL7 to, for example, 1.8 version.
>> I am actually going to fill a Review Request for
>> python-django-netjsongraph[1], and among its requirements, there is
>> python-django-rest-framework that cannot actually be packaged for
>> EPEL7 due python-django actual version
>>
>> Thank you
>>
>> [1]: https://github.com/interop-dev/django-netjsongraph
>> ___
>> 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
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/python-devel@lists.fedoraproject.org

Re: FESCo - July 2016 Elections - Result announcement

[Haïkel]

2016-07-26 4:58 GMT+02:00 Jan Kurik :
> Greetings, all!
>
> The elections for FESCo - July 2016 have concluded, and the results
> are shown below.
>
> FESCo is electing 4 seats this time.
> A total of 196 ballots were cast, meaning a candidate
> could accumulate up to 980 votes (196 * 5).
>
> The results for the elections are as follows:
>
>   # votes |  name
> - +--
>  655  | Stephen Gallagher (sgallagh)
>  619  | Josh Boyer (jwb/jwboyer)
>  557  | Dennis Gilmore (dgilmore/ausil)
>  474  | Dominik Mierzejewski (rathann)
> - +--
>  454  | Haikel Guemar (number80/hguemar)
>
>
> Congratulations to the winning candidates, and thank you all
> candidates for running this elections!
>
> --
> Jan Kuřík
> Platform & Fedora Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic



Congratulations to the elected members!

Regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Self introduction: Zygmunt Krynicki

[Haïkel]

2016-07-23 10:03 GMT+02:00 Zygmunt Krynicki :
> Hello
>
> My name is Zygmunt (zyga) Krynicki. I’ve been using various distributions of 
> Linux for the past 15 years. I helped create the Linaro’s LAVA test system, 
> Ubuntu’s Checkbox hardware testing toolkit. Most recently I’m involved with 
> Snappy where I am responsible for the interface system.
>
> My main focus will be to maintain the Snappy stack in Fedora. This involves 
> the packaging (snapd, snap-confine and a few golang dependencies), upstream 
> snappy support for SElinux and overall architecture support so that snaps 
> work on every computing environment.
>
> I’m excited to join this community and to work on making snaps at home in 
> Fedora
>
> Best regards
> ZK

Welcome to the Fedora community!

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

Re: Snaps and Fedora

[Haïkel]

http://www.ubuntu.com/legal/contributors

2016-07-23 2:46 GMT+02:00 Neal Gompa :
> Hello all,
>
> Over the course of this week, I've been involved in the first Snap
> sprint focused on making the Snap system broadly useful and workable
> across a wide variety of Linux distributions. While I obviously did
> not represent Fedora in any official capacity (and I'm not even really
> sure it's possible for a person to represent such a diverse community
> such as ours), I ensured that Fedora was part of the conversation when
> it came to evolving the Snap system.
>

Thanks Neal for sharing your notes.
It's interesting to have accurate status of snappy on Fedora.


> There are some interesting highlights from the event that I think are
> quite relevant to Fedora:
>
> * Snaps are intended to evolve beyond Ubuntu. While snaps have their
> origins in Click for Ubuntu Touch user apps, the Snap system is
> clearly designed to support a broader array of capabilities and
> systems. Snaps can be used to handle OS components, services, CLI
> tools, desktop applications, build environments, web services, and so
> on.
>

Well, I know first hand, that non-Ubuntu system support is still alpha at best.
It's welcome that Canonical is working to expand support to other
distributions, windowing system, and kernel security modules, though.

> * Runtimes are supported in snaps. While technically there's no
> specific "type" of snap, it's possible to build a snap that contains
> common libraries and services that can be connected to other snaps.
> This is done through the "plugs" and "slots" that can be used to
> create interfaces among them. This is a true superset of the
> capability provided by Flatpak through Portals, since it can be used
> to export non-DBus oriented communications mechanisms. This is
> described on the Snapcraft documentation[0].
>

I wouldn't be so affirmative on that, it slightly inaccurante but I'll
let people with more knowledge of flatpak internals answering that.

> * SELinux-based confinement is a _very_ high priority. As most know,
> snapd currently only works on systems using AppArmor and seccomp, and
> only those using AppArmor patches developed by Ubuntu that are in the
> process of being upstreamed. For SELinux support, we aren't exactly
> sure how this will be pulled off. I proposed something along the lines
> of how confinement works for Docker containers and virtual machines
> (sVirt), but I'm not sure if that's the right approach for enabling
> proper confinement while allowing the sandboxes to support the
> interconnection capabilities of snaps. The way that the Snap system
> enforces confinement using AppArmor and seccomp is by generating a
> profile for the snap on the fly that defines what it can and cannot do
> and access for the mounted snap filesystem (from the squashfs image).
> This policy is applied, locking down the snap's environment. I'm
> curious to hear from others on how the approach should be for
> providing confinement using SELinux.
>

To be more precise, until recently, snappy website recommended to
setenforce 0 as it didn't interact well with SELinux.
That statement was removed though it's still not fixed.

> * Detection and auto-configuration of confinement is coming.
> Snap-confine currently relies on build time configuration to figure
> out whether it should support confinement. However, this will change.
> Snap-confine will be merged into snapd and snapd will be set up to
> query and set up whatever confinement is possible, given the
> information returned from the kernel and systemd about what
> confinement mechanisms are supported.
>
> * The snap format is simple and lends itself to being able to be
> generated by many kinds of tools. While the current main tool used to
> make snaps is Snapcraft, there's no reason someone couldn't build a
> "snapbuild" (like rpmbuild, debbuild[1], and pkgbuild[2]) that could
> theoretically use RPM spec format (or a derivative of it) to build
> snaps.
>
> * Snapcraft is currently Ubuntu specific, but will be reworked to
> remove that. Snapcraft and the snapcraft.yaml format will change to
> enable easily and reproducibly building snaps using Debian and RPM
> based distro bases in addition to Ubuntu[3]. The goal is to make it
> possible for a distribution like Fedora to be able to easily add
> support for building snaps and snap parts from Fedora infrastructure
> using Fedora packages/software, along the lines of what we do now for
> Docker images, so that people can use them in their own snaps or
> solutions.
>
> * The VideoLAN project now officially offers a VLC snap[4], and the
> Elementary OS folks are working on snaps for their Pantheon Desktop
> applications and tying it to an Elementary GTK runtime snap.
> Similarly, the KDE Neon folks are developing a KDE Frameworks 5
> runtime snap and building application snaps to use them.
>
> * Using snapd with alternative stores is possible. In fact, the tests
> done on 

Re: LBNL BSD licence

[Haïkel]

2016-07-05 11:45 GMT+02:00 Dave Love :
> I've realized that the licence for a package I've recently had reviewed
> is actually "LBNL BSD"
> , not BSD3 with a DoE
> disclaimer, as I thought.  (Mea culpa, but licensecheck didn't spot it.)
>
> Anyway, I've fixed that, but I can't find any discussion about the
> licence.  Does anyone know of any past discussion, specifically any
> recommendation for dealing with the clause that seems problematic to me
> as a potential booby-trap for contributors:
>
>   You are under no obligation whatsoever to provide any bug fixes, patches, or
>   upgrades to the features, functionality or performance of the source code
>   ("Enhancements") to anyone; however, if you choose to make your Enhancements
>   available either publicly, or directly to Lawrence Berkeley National
>   Laboratory, without imposing a separate written license agreement for such
>   Enhancements, then you hereby grant the following license: a  non-exclusive,
>   royalty-free perpetual license to install, use, modify, prepare derivative
>   works, incorporate into other computer software, distribute, and sublicense
>   such enhancements or derivative works thereof, in binary and source code 
> form.
>
> People sending copyright-significant changes probably don't expect to
> grant an all-permissive licence (which presumably involves the
> possibility of removing copyright notices, for instance), so I wondered
> what to do for the "separate written license" to keep contributions
> under the basic BSD3 terms.  I'm thinking of modifying the COPYING file
> to say simply that changes are distributed only under BSD3 terms.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Do not change shipped license file from upstream.
First, contact the following list: legal AT lists.fedoraproject.org in
order to clarify the obscure points.
Then, coordinate with upstream to fix licensing upstream if you're requested to.


Regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Anyone know how to contact maintainer Salimma?

[Haïkel]

2016-06-30 4:59 GMT+02:00 Avram Lubkin :
>
> I've been trying to contact Salimma, Michel Alexandre Salim, for the last
> month. I've been trying to update python-sphinx which hasn't had an update
> since last fall. Worked through all of the issues, but maintainer hasn't
> responded to commit request, email, or bug reports.
>
> Bug report for newest version of Sphinx with needinfo flag.
> https://bugzilla.redhat.com/show_bug.cgi?id=1323202
>
> Anyone have any info?
>

I see builds from him june, 8 in Koji so he shouldn't be far away.
Meanwhile, you can send me your patch or add it in the bugzilla and
I'll apply it in rawhide as provenpackager.


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

Re: Packages seeking new Point Of Contact

[Haïkel]

2016-06-28 18:49 GMT+02:00 Kevin Fenzi :
> Greetings.
>
> Per: https://fedorahosted.org/fesco/ticket/1589
>
> I have orphaned bjohnson's packages.
>
> Please do take point of contact for any of these you wish to help
> maintain for the Fedora Project.
>
> rpms/conduit -- A synchronization solution for GNOME ( master f24 f23 f22 
> )
> rpms/dbmail -- A database backed mail storage system ( master f24 f23 f22 
> epel7 el6 el5 )
> rpms/dwatch -- A program that watches over other programs ( master f24 
> f23 f22 epel7 el6 el5 )
> rpms/gmime -- Library for creating and parsing MIME messages ( epel7 el6 
> el5 )
> rpms/goocanvas -- A new canvas widget for GTK+ that uses cairo for 
> drawing ( master f24 f23 f22 )
> rpms/gscan2pdf -- GUI for producing a multipage PDF from a scan ( master 
> f24 f23 f22 )
> rpms/libmkv -- An alternative to the official libmatroska library ( 
> master f24 f23 f22 epel7 )
> rpms/libsieve -- A library for parsing, sorting and filtering your mail ( 
> master f24 f23 f22 epel7 el6 el5 )
> rpms/libzdb -- Small, easy to use Database Connection Pool Library ( 
> master f24 f23 f22 epel7 el6 el5 )
> rpms/mailgraph -- A RRDtool frontend for Mail statistics ( master f24 f23 
> f22 epel7 el6 el5 )
> rpms/perl-Gtk2-Ex-PodViewer -- A Gtk2 widget for displaying Plain old 
> Documentation (POD) ( master f24 f23 f22 )
> rpms/perl-Net-FTP-AutoReconnect -- FTP client class with automatic 
> reconnect on failure ( master f24 f23 f22 epel7 el6 el5 )
> rpms/perl-Net-FTP-RetrHandle -- Provides a file reading interface for 
> reading files on a remote FTP server ( master f24 f23 f22 epel7 el6 el5 )
> rpms/perl-PDF-API2 -- Perl module for creation and modification of PDF 
> files ( master f24 f23 f22 epel7 el6 )
> rpms/perl-Sane -- Perl extension for the SANE (Scanner Access Now Easy) 
> Project ( master f24 f23 f22 )
> rpms/perl-forks -- A drop-in replacement for Perl threads using fork() ( 
> master f24 f23 f22 )
> rpms/polipo -- Lightweight caching web proxy ( master f24 f23 f22 epel7 
> el6 )
> rpms/pygoocanvas -- GooCanvas python bindings ( master f24 f23 f22 )
> rpms/queuegraph -- A RRDtool frontend for Mail statistics ( master f24 
> f23 f22 epel7 el6 el5 )
> rpms/tmda -- Tagged Message Delivery Agent ( master f24 f23 f22 epel7 el6 
> el5 )
> rpms/unpaper -- Post-processing of scanned and photocopied book
> pages ( master f24 f23 f22 epel7 el6 el5 )
>
> kevin
>

I see that goocanvas is retired, so pygoocanvas should be too.


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

"Summary/Minutes for today's FESCo meeting (2016-06-24)"

[Haïkel]

===
#fedora-meeting: FESCO (2016-06-24)
===


Meeting started by number80 at 16:00:02 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2016-06-24/fesco.2016-06-24-16.00.log.html
.



Meeting summary
---
* #1587 Policy regarding packaging when upstream has chosen  (number80,
  16:02:09)
  * LINK: https://fedorahosted.org/fpc/ticket/633   (number80, 16:03:20)
  * AGREED: close ticket #1587 (+1: 7, 0: 0, -1: 0)  (number80,
16:12:33)
  * if there are conflict about inappropriate package naming or
conflict, you should raise it to FPC (guidelines) or ultimately to
FESCo  (number80, 16:13:48)

* #1576  Evaluate Workstation graphical upgrade Change status
  (number80, 16:14:42)
  * ACTION: number80 close ticket 1576  (number80, 16:17:26)

* #1589 BackupPC's packager Bernard Johnson is nonresponsive  (number80,
  16:17:56)
  * LINK: https://admin.fedoraproject.org/pkgdb/packager/bjohnson/
(nirik, 16:21:10)
  * AGREED: orphan all of bjohnson's packages. nirik will sponsor and
mentor lef to take ownership of BackupPC (+1: 7, 0: 0, -1: 0)
(number80, 16:33:23)

* #1588 F25 System Wide Change: PHP 7.0  (number80, 16:33:44)
  * AGREED: PHP 7.0 system wide feature is accepted (+1: 7, 0: 0, -1; 0)
(number80, 16:36:23)

* Open Floor  (number80, 16:36:55)
  * paragan will chair the next meeting (2016-07-01)  (number80,
16:41:26)

Meeting ended at 16:41:56 UTC.




Action Items

* number80 close ticket 1576




Action Items, by person
---
* number80
  * number80 close ticket 1576
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* number80 (82)
* sgallagh (32)
* nirik (28)
* maxamillion (18)
* zodbot (15)
* jwb (15)
* paragan (14)
* mulhern (8)
* jsmith (8)
* tibbs|w (5)
* RemiFedora (2)
* handsome_pirate (1)
* gholms (1)
* kalev (0)
* dgilmore (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

"Schedule for Friday's FESCo Meeting (2016-06-24)"

[Haïkel]

Following is the list of topics that will be discussed in the FESCo
meeting Friday at 16:00UTC in #fedora-meeting on irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2016-06-24 16:00 UTC'


Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1587 Policy regarding packaging when upstream has chosen
inappropriate name for package
.fesco 1587
https://fedorahosted.org/fesco/ticket/1587

#topic #1576  Evaluate Workstation graphical upgrade Change status
.fesco 1576
https://fedorahosted.org/fesco/ticket/1576

= New business =

#topic #1589 BackupPC's packager Bernard Johnson is nonresponsive
.fesco 1589
https://fedorahosted.org/fesco/ticket/1589

#topic #1588 F25 System Wide Change: PHP 7.0
.fesco 1588
https://fedorahosted.org/fesco/ticket/1588


= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or 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
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Self Introduction: Oliver Haessler

[Haïkel]

2016-06-14 16:45 GMT+02:00 Oliver Haessler :
> Hi everyone,
>
> my name is Oliver and I am working for Red Hat in the internal IT department.
> I am responsible for the internal RHEL desktop build we use for our employees.
> I maintain extra config packages that we add to the existing Red Hat 
> Enterprise Linux,
> so our employees are getting productive faster.
>
> A while ago I decided to give something back to the Open Source community by
> contributing to the Fedora project. I am co-maintaining several packages I am 
> using
> myself, or that employees asked for to be included in our internal 
> repositories.
>
> One of my goals is to extend the contribution to also include package/release 
> testing and
> reporting of bugs via bugzilla.
>
> I am looking very much forward to work with a lot of interesting people in 
> the community,
> and learn a lot new things.
>
> Cheers
> Oliver

Welcome Oliver, nice to see you on this side of the firewall :)
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Unresponsive maintainer: asaf

[Haïkel]

2016-05-30 12:55 GMT+02:00 gil <punto...@libero.it>:
>
>
> Il 30/05/2016 12:09, Haïkel ha scritto:
>>
>> 2016-05-30 10:18 GMT+02:00 Mikolaj Izdebski <mizde...@redhat.com>:
>>>
>>> On 05/30/2016 10:01 AM, gil wrote:
>>>>
>>>> But until now I have not had any response from the maintainer, asaf
>>>> (Asaf Shakarchi a...@redhat.com ) .
>>>
>>> This email address seems to be inactive.
>>>
>> Asaf left Red Hat now six years ago, and he last logged in FAS in 2013.
>> It's likely we'll orphan all his packages when it'll reach FESCo.
>>
>> H.
>>
> Thanks,
> i need to upgrade slf4j-jboss-logmanager
> https://bugzilla.redhat.com/show_bug.cgi?id=1340406
> regards
> .g

Since the process may take at least a week, I'll do the update in your
stead as provenpackager.
Please open a ticket in the FESCO trac.


>>>
>>> --
>>> Mikolaj Izdebski
>>> Software Engineer, Red Hat
>>> IRC: mizdebsk
>>> --
>>> 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
>
> --
> 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

Re: Unresponsive maintainer: asaf

[Haïkel]

2016-05-30 10:18 GMT+02:00 Mikolaj Izdebski :
> On 05/30/2016 10:01 AM, gil wrote:
>> But until now I have not had any response from the maintainer, asaf
>> (Asaf Shakarchi a...@redhat.com ) .
>
> This email address seems to be inactive.
>

Asaf left Red Hat now six years ago, and he last logged in FAS in 2013.
It's likely we'll orphan all his packages when it'll reach FESCo.

H.


> --
> Mikolaj Izdebski
> Software Engineer, Red Hat
> IRC: mizdebsk
> --
> 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

Re: Reserved GID for MongoDB

[Haïkel]

2016-05-18 21:39 GMT+02:00 Reindl Harald :
>
>
> it's simple: apache (httpd) has gid/uid 48 likely before you did knew about
> Fedora nad you can rely on that on every Fdora/RHEL/CentOS system out there
>
> *that* is consistent UID/GID
>

That is irrelevant to the current discussion, and you're belittling
yourself with these kind of personal attacks.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Reserved GID for MongoDB

[Haïkel]

2016-05-18 20:28 GMT+02:00 Florian Weimer <fwei...@redhat.com>:
> On 05/18/2016 08:08 PM, Haïkel wrote:
>>
>> If you need to reserve statically id/gid, you're likely solving the
>> wrong problem.
>
>
> Static UIDs and GIDs are required for reproducible installations which give
> the same results independent of the execution order of RPM scriptlets.
>
> Florian
>

Relying on RPM scriptlets to ensure reproducibility is inherently
broken by design.
You can't prevent UID/GID conflict that way, and if you want to ensure
that all your cluster
use consistent UID/GID then you have better ways to preallocate them.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Reserved GID for MongoDB

[Haïkel]

If you need to reserve statically id/gid, you're likely solving the
wrong problem.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Attempting to contact unresponsive maintainer - ndipanov

[Haïkel]

2016-04-25 18:00 GMT+02:00 Kevin Fenzi :
> Greetings, we've been told that the email addresses
> for this package maintainer is no longer valid.  I'm starting the
> unresponsive maintainer policy to find out if they are still interested
> in maintaining their packages (and if so, have them update their email
> addresses in FAS).  If they're not interested in maintaining or we
> can't locate them I'll have FESCo orphan the packages so that others
> can take them over.
>
> If you have a way to contact this maintainer, please let them
> know that we'd appreciate knowing what to do with their packages.
> Thanks!
>
> * ndipanov - former email ndipa...@redhat.com
>
> Point of contact:
>
> rpms/python-autopep8 -- The package autopep8 formats Python code based on 
> the output of the pep8 utility ( master f24 f23 f22 )
>
> Co-maintainer:
>
> rpms/novnc -- VNC client using HTML5 (Web Sockets, Canvas) with 
> encryption support ( master f24 f23 f22 epel7 )
> rpms/openstack-glance -- OpenStack Image Service ( f23 f22 )
> rpms/openstack-nova -- OpenStack Compute (nova) ( f23 f22 )
> rpms/python-oslo-config -- OpenStack common configuration library ( 
> master f24 f23 f22 )
> rpms/python-oslo-messaging -- OpenStack common messaging library ( master 
> f24 f23 f22 )
> rpms/python-websockify -- WSGI based adapter for the Websockets protocol 
> ( master f24 f23 f22 epel7 el6 )
>
> kevin
>

Nikola recently left Red Hat, just reassign whatever packages he had to me.

Regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Call for help contacting contributors

[Haïkel]

2016-03-31 0:51 GMT+02:00 Kevin Fenzi :
> On Thu, 24 Mar 2016 19:55:54 +0100
> Pierre-Yves Chibon  wrote:
>
>> Dear all,
>>
>> Packagers, members of the fedorabugs group and people having a
>> 'watchbugzilla' ACL in pkgdb must have a bugzilla account attached to
>> the email they set in the Fedora Account System (FAS).
>> This is mandatory to allow ACLs to be propagated from pkgdb to
>> bugzilla, allowing the right person to be made assignee or to be
>> cc'ed on bug reports of packages.
>>
>> There are currently a few users who are not following this rule and
>> have not been for quite a while, despite our attempts to contact them:
>>
>> * jackprice,  FAS email: jackprice -- outlook.com
>> watches 1 package
>> * vjancik,FAS email: viktor.vix.jancik  --  gmail.com
>> co-maintains¹ 68 packages
>> watches   1 package
>> * mstuchli,   FAS email: matej.stuchlik -- gmail.com
>> POC of 14 packages
>> co-maintains 18 packages
>> * ferbncode,  FAS email: suyashgargsfam  --  gmail.com
>> watches 2 packages
>> * jangernert, FAS email: janlukasgernert  -- freenet.de
>> watches 1 package
>>
>> If anyone knows how to reach to them and could either send them to
>> us, the Fedora infrastructure team, or directly ask them to create a
>> bugzilla account associated to the email they set in FAS, it would be
>> highly appreciated.
>>
>> If nothing changes in the coming days, we will drop their ACLs in
>> pkgdb.
>
> I've now done this.
>
> Those folks who only had watch on some packages have been removed from
> those, but mstuchli was maintaining 14 packages.
>
> I have orphaned those packages and they need a new point of contact:
>
> rpms/RunSnakeRun -- GUI Viewer for Python profiling runs ( master f24 f23 
> f22 )
> rpms/fig -- Punctual, lightweight development environments using Docker ( 
> f22 )

This one should be retired, it has been renamed as docker-compose.

> rpms/pipsi -- Wraps pip and virtualenv to install scripts ( master f24 
> f23 f22 )
> rpms/python-flask-admin -- Simple and extensible admin interface 
> framework for Flask ( master f24 f23 f22 epel7 el6 )
> rpms/python-flask-mongoengine -- Flask extension that provides 
> integration with MongoEngine ( master f24 f23 f22 el6 )
> rpms/python-peewee -- A small, expressive orm ( master f24 f23 f22 el6 )
> rpms/python-pytest-capturelog -- py.test plugin to capture log messages ( 
> master f24 f23 f22 )
> rpms/python-rply -- Pure Python parser generator ( master f24 f23 f22 )
> rpms/python-scripttest -- Helper to test command-line scripts ( master 
> f24 f23 f22 epel7 el6 )
> rpms/python-wtf-peewee -- WTForms integration for peewee models ( master 
> f24 f23 f22 el6 )
> rpms/python3-pkgversion-macros -- Convenience macros for Fedora/EPEL 
> Python 3 packages building ( master f24 f23 f22 epel7 el6 )
> rpms/rpm-compare-req -- Tool for comparing RPM dependencies against a set 
> of repositories ( master f24 f23 f22 )
> rpms/sasquatch -- Modified unsquashfs utility supporting many SquashFS 
> implementations ( master f24 f23 f22 )
> rpms/unp -- A command line tool that can unpack archives easily
> ( master f24 f23 f22 )
>
> kevin
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: HEADS UP: systemd package split

[Haïkel]

2016-03-04 23:36 GMT+01:00 Zbigniew Jędrzejewski-Szmek :
> Hi,
>
> I finally pushed the split of the systemd package to Rawhide and F24 today
> [https://fedoraproject.org/w/index.php?title=Changes/systemd_package_split].
> If you upgrade with dnf you should see something like this:
> Installing:
>  systemd-container  x86_64 229-5.fc23@commandline 353 
> k
>  replacing  systemd.x86_64 222-13.fc23
>  systemd-udev   x86_64 229-5.fc23@commandline 1.2 
> M
>  replacing  systemd.x86_64 222-13.fc23
> Upgrading:
>  systemdx86_64 229-5.fc23@commandline 5.1 
> M
>  systemd-libs   x86_64 229-5.fc23@commandline 452 
> k
>  ...
>
> (systemd-udev provides udevd and hardware support, systemd-container provides
> machinectl and other tools to manager containers and VMs.)
>
> Comps 'core' group includes systemd-udev as mandatory and systemd-container
> as optional, so they should be present in new installs.
> Please check that you have systemd-udev package installed after an upgrade.
> If you are building containers, things should be functional without either
> of those new packages.
> Otherwise, please holler on the bugzilla or here.
>
> Zbyszek


Great news!
Thank you for keeping us up to date;)


> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Summary/Minutes for today's FESCo meeting (2016-03-04)

[Haïkel]

===
#fedora-meeting: FESCO (2016-03-04)
===


Meeting started by number80 at 17:00:11 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2016-03-04/fesco.2016-03-04-17.00.log.html
.



Meeting summary
---
* #1518 Software packaged in Fedora should not be allowed to implement
  DRM schemes that cannot be disabled  (number80, 17:03:15)
  * there's progress in our discussion w/ Mozilla about signed add-ons
(number80, 17:06:04)

* #1552 Review of delayed Changes for F24  (number80, 17:09:06)
  * delayed changes for F24 will be reviewed during the next FESCO
meeting  (number80, 17:11:31)

* #1551 Linking GPRbuild statically  (number80, 17:11:58)
  * AGREED: gprbuild is allowed to link statically (+1: 6, 0:0, -1:0)
(number80, 17:22:37)

* #1554 python-llfuse package takeover  (number80, 17:23:00)
  * AGREED: orphan all maci packages (+1:7, 0:0, -1:0)  (number80,
17:30:40)

* #1557 Update Squid 3.4.13 to 3.5.10 in F22  (number80, 17:32:23)
  * AGREED: allow squid update to 3.5.x in F22 (+1:7, 0:0, -1:0)
(number80, 17:33:30)

* #1555 Please clarify updates policy for security issues  (number80,
  17:33:42)
  * ACTION: jsmith will try to clarify updates policy for security
issues  (number80, 17:43:53)

* Next week's chair  (number80, 17:44:58)
  * maxamillion will chair fesco meeting next week  (number80, 17:46:29)

* Open Floor  (jwb, 17:47:33)

Meeting ended at 17:51:11 UTC.




Action Items

* jsmith will try to clarify updates policy for security issues




Action Items, by person
---
* jsmith
  * jsmith will try to clarify updates policy for security issues
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* number80 (80)
* dgilmore (28)
* maxamillion (26)
* sgallagh (24)
* nirik (18)
* jwb (18)
* zodbot (17)
* kalev (12)
* jsmith (9)
* Rombobeorn (3)
* Southern_Gentlem (1)
* paragan (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Schedule for Friday's FESCo Meeting (2016-03-04)

[Haïkel]

Following is the list of topics that will be discussed in the FESCo
meeting Friday at 17:00UTC in #fedora-meeting on irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2016-03-04 17:00 UTC'


Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic 1518 Software packaged in Fedora should not be allowed to
implement DRM schemes that cannot be disabled
.fesco 1518
https://fedorahosted.org/fesco/ticket/1518

#topic 1552 Review of delayed Changes for F24
.fesco 1552
https://fedorahosted.org/fesco/ticket/1552

= New business =

#topic #1551 Linking GPRbuild statically
.fesco 1551
https://fedorahosted.org/fesco/ticket/1551

#topic #1554 python-llfuse package takeover
.fesco 1554
https://fedorahosted.org/fesco/ticket/1554

#topic #1557 Update Squid 3.4.13 to 3.5.10 in F22
.fesco 1557
https://fedorahosted.org/fesco/ticket/1557

#topic #1555 Please clarify updates policy for security issues
.fesco 1555
https://fedorahosted.org/fesco/ticket/1555

= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or 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
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Large number of packages to be orphaned on Feb 26

[Haïkel]

I took zsh-lovers.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: update mercurial to 3.7.1 in rawhide and F24

[Haïkel]

2016-02-25 16:58 GMT+01:00 Neal Becker :
> I'd like to update to latest mercurial.  I built 3.7.1 in rawhide, and
> AFAICT there's no problem using it with tortoisehg-3.7.1-fc24.
>
> I'd like to update mercurial in F24 - AFAIK there should not be any
> compatibility issues.
>
> Any objections?

I'd suggest that you ping packages maintainers for packages that
relies on mercurial before, in order to collaborate on that update.
dnf --releasever=24 repoquery --alldeps --whatrequires mercurial shows
much more than just tortoisehg

It's better that a provenpackager or someone with commit access try to
do a bundle update.

Regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: CVE-2015-7547 fix for Fedora 21

[Haïkel]

2016-02-19 3:35 GMT+01:00 Kevin Kofler :
> Hi,
>
> I have built an updated glibc package for Fedora 21, with (alleged) fixes
> for the following security issues:
> * CVE-2015-7547 (CRITICAL)
> * CVE-2015-1781
> * CVE-2015-8777
> * glibc PR17269
> * glibc PR18032
> backported from Fedora 22 or forward-ported from CentOS 7. (To the best of
> my knowledge, the patches I backported do indeed address the above issues,
> but I cannot provide any kind of guarantees for that.)
>
> You can find it in the following repository:
> https://repos.fedorapeople.org/kkofler/f21-security/
> (I had to use the old repos.fedorapeople.org infrastructure because the Copr
> maintainers "helpfully" deleted the Fedora 21 buildroots, making Copr
> entirely useless for the purpose of building security updates for
> distributions Fedora no longer provides them for. I consider this a very bad
> idea and an absolutely counterproductive practice.)
>
> As specified in the .repo file, the packages are signed with my CalcForge
> GPG key, available over HTTPS (with a valid certificate from Let's Encrypt):
> https://www.calcforge.org/RPM-GPG-KEY-calcforge
>
> This repository is provided "AS IS", in the hope that it will be useful, but
> WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> or FITNESS FOR A PARTICULAR PURPOSE.  In particular, NO warrants of any kind
> are made for completeness of security fix coverage.
>
> Currently, glibc is the ONLY package that has an update available in the
> above repository.
>
> Kevin Kofler

/me wearing his FESCO member hat.

Please remember that F21 has reached End of Life and is *not*
supported by fedoraproject.org
Though these packages may fix a very critical CVE, we cannot guarantee
that CVEs in other packages are also fixed.

So no warranties from fp.o if you keep using F21 with or without these packages.


/me removing his FESCO member hat

Thank you Kevin for your effort to provided a very critical bugfix to
people who may use F21, though they shouldn't.
At least, I appreciate that you shared your efforts with a larger set of people.

Regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora AMI build process

[Haïkel]

2016-02-16 15:02 GMT+01:00 Jon Kent :
> Hi,
>
> I've been trying to see how we build Fedora AMIs but am starting having not
> luck with finding documents on the buiild process. If someone could throw me
> a link it would be much appreciated.
>
> Thanks,
> Jon
>

I suggest that you contact the Fedora Cloud SIG through their own mailing list.

In short, AMI are composed by Koji using ImageFactory, fedimg is used
to upload images.
http://imgfac.org/
https://github.com/fedora-infra/fedimg

Regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: Redis update to 3.0.x branch

[Haïkel]

2016-02-08 16:56 GMT+01:00 Peter Robinson :
>
> Is there client side soname bumps which will need associated rebuilds
> for anything that depends on it?

redis does not provide any library or public API, clients use the wire
protocol which remains compatible.
No rebuilds required.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Redis update to 3.0.x branch

[Haïkel]

Hi,

EPEL7 currently ship Redis 2.8.x branch, but it will be EOLed soon
after the 3.2.x branch will be released.
I plan to update EPEL7 branch to 3.0.x, there's no specific action
required from users for the migration.

Regards,
H.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: Python packages not compliant to Fedora guidelines

[Haïkel]

2016-02-06 9:44 GMT+01:00 Germano Massullo :
> In past days I filled many review requests for various python libraries, in
> order to submit python-netdiff [1] and python-django-netjsongraph [2].
> During this process, I noticed that a lot of python packages are not
> compliant to Fedora Guidelines for packaging Python stuff [3]. So you have
> to deal with many packages that have the old naming (python-*) and are not
> using the new python2-* and python3-*
> Moreover there are packages that have newer branches that are compliant to
> guidelines and older that are not, so the result is that you have a *your*
> package that builds for example on >= F23 but does not on F22, and maybe on
> EPEL7 too.
>

Problem is that these guidelines are not compliant with EL7 guidelines.
I have the reverse problem that packages from EPEL7 don't build
anymore on CentOS.
It's putting an additional barrier for people from CentOS community,
and third party repositories.

I honestly think that these guidelines were a mistake, we should just
have left python- prefix die with python2 and enforce versioned
pythonX prefix everywhere (Qt packaging experience proved that was the
only sane option).
These have brought more issues that it solved (if it solved any issues at all).

Regards,
H.

> I think it would be nice if we put some effort to have all those problems
> fixed for F24 release
>
> [1]: https://pypi.python.org/pypi/netdiff
> [2]: https://pypi.python.org/pypi/django-netjsongraph
> [3]: https://fedoraproject.org/wiki/Packaging:Python
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

[Haïkel]

2016-02-03 17:04 GMT+01:00 Jonathan Wakely :
> On 03/02/16 08:44 -0700, Jerry James wrote:
>
>> 1. Demotivating packagers
>>
>> I know a number of companies have experimented with "ownership-free"
>> models of code development, but they are able to offer incentives that
>> Fedora cannot offer, such as money and kudos offered in front of
>> coworkers.  What motivates volunteer packagers to do what they do?
>> I'd like to hear from a few packagers on this topic.
>
>
> I want Fedora to be better.
>
>> If I send these two provenpackagers a somewhat hostile email, are you
>> going to blame me?  I have no problem with most provenpackager
>> changes.  In general, they have an obvious purpose and save me the
>> work of making the same change myself.  But changes like the ones
>> above make more work for me, work that could have been avoided if the
>> provenpackager in question had just bothered to make some attempt, any
>> attempt, to contact me first.
>
>
> I don't think that's always realistic to expect.
>
> When a provenpackager is rebuilding *hundreds* of packages at once,
> and trying to deal with maybe dozens of build failures, sending emails
> to all the package owners and waiting to see if they respond promptly
> is not an efficient way to get things fixed. Waiting for a reply adds
> a lot of latency, and then you have to context-switch back to a
> package you were dealing with a day or two ago. That's impractical
> when you have a patch ready to go now and loads more packages to look
> at.
>

I disagree with you on that point.
I agree with the premises that we can't expect provenpackagers to
contact every single maintainers for fixing a large number of packages
at once, but that's the role of fedora devel list.
If you can't contact everyone, a message on fedora-devel is good enough.

For instance, the desktop team maintains a spreadsheet before GNOME
rebuilds so that package maintainers can give their input before a
provenpackager do the builds.
That allows maintainer to provide valuable feedback like avoiding
borken versions upstream, or how to update patchset if they're
maintained in a specific way.

> Sometimes a provenpackager will make a bad change, and that's
> unfortunate, but it happens. Sometimes package owners make bad changes
> too! :-)
>

Yes, but provided that they sent a heads-up on usual communication
channels, there's no problem with it.

> If I make a bad change to a package please do let me know. If I appear
> to change things and walk away it's probably because I've moved on to
> look at other packages that also need attention, not just a careless
> hit & run. I would expect it's similar for others.
>

As a provenpackager, I always ping maintainers, and try to minimize
impact (e.g not fixing spec to my personal liking w/o agreement)
As a packager, I usually go through the changes, unless it broke
something or is non-trivial, I'm fine with letting it go.

If you add epoch to packages I co-maintain without telling me,
I'll hate you until the ends of time ;-)


> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to fix a package name with wrong capitalization?

[Haïkel]

2016-01-16 16:10 GMT+01:00 Kevin Kofler :
> Hi,
>
> in the following review:
> https://bugzilla.redhat.com/show_bug.cgi?id=1285042
> a package was reviewed and approved under the name "kpmcore", which matches
> how upstream calls its tarballs. However, the subject line incorrectly
> spelled the name as "KPMcore" in camel-case, which was not caught during
> review, and so when the package was created in pkgdb, the submitter
> accidentally requested the module as "KPMcore". Unfortunately, the automated
> checks apparently do not notice mismatches between the specfile name and the
> subject line, and neither did the reviewer.
>
> In addition, since nobody reviewed that rename, it also does not handle
> Provides correctly, there isn't even a Provides for the correct name.
>
> So I would like to ask:
> * How can this particular package get fixed? I sure hope the answer is not
>   to stick to the incorrect camel-case name forever! Can the administrators
>   please look into this?


Since this package only hit rawhide, I guess we can accept that releng
fixes the repo and
avoid the rename process.
http://koji.fedoraproject.org/koji/packageinfo?packageID=21440

If it were a stable or branched release, I would insist to follow the
rename process.

> * Can we add some additional sanity checks to prevent this from happening
>   again in the future? I guess the issue there is that specfile links do not
>   necessarily contain the file name in the link or even contain it, they can
>   be fpaste links, links into some SCM viewer, etc. We would also need to
>   check the latest specfile link, not the first, because sometimes, package
>   names are fixed as part of the review process. But if we can find a
>   solution that does not break current use cases, I think it would be very
>   helpful.
>
> Kevin Kofler

That is an excellent idea, I encourage you to open a ticket in pkgdb2.

I guess we could add sanity check to the bugzilla sync script
https://github.com/fedora-infra/pkgdb2/blob/0b40ed5e7543a587b0acc8118f0f99ca14c256a8/utility/pkgdb-sync-bugzilla

It could be either a flash message warning packager or plainly refuses
to create the request if you don't fix the ticket.

Regards,
H.


> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel] Re: LibRaw is in EPEL testing and also in Base

[Haïkel]

2016-01-12 16:28 GMT+01:00 Johnny Hughes :
> 'LibRaw-0.17.1-3.el7.x86_64 (epel-testing)' and
> 'LibRaw-0.14.8-5.el7.20120830git98d925.x86_64 (@base/$releasever)' are
> conflicting
>

Maybe it needs to be synced but it's not on the list of packages that
should be shipped by EPEL.
https://infrastructure.fedoraproject.org/repo/json/pkg_el7.json

H.

>
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
>
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Unresponsive maintainer procedure for nsjae

[Haïkel]

Hi,

I'd like to start the unresponsive maintainer procedure for nsaje.
https://admin.fedoraproject.org/pkgdb/packager/nsaje/

Nec is a former Red Hat intern and Alan tried to contact him more than
one month ago.
He also requested package ACLs for python-kazoo without any answer.

https://admin.fedoraproject.org/pkgdb/package/rpms/python-kazoo/

If anyone can contact him I would be grateful.

Regards.
H.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Suds Jurko Fork

[Haïkel]

2016-01-04 15:15 GMT+01:00 Josh Boyer :
> On Mon, Jan 4, 2016 at 9:01 AM, Jan Kurik  wrote:
>> = Proposed System Wide Change: Suds Jurko Fork =
>> https://fedoraproject.org/wiki/Changes/Suds_Jurko_Fork
>>
>> Change owner(s):
>> * Scott Talbert 
>>
>> Change the python-suds package to use the fork maintained by Jurko 
>> Gospodnetić.
>>
>> == Detailed Description ==
>> Suds is a SOAP-based web service client for Python which is currently
>> packaged in Fedora as python-suds. This change proposal aims to update
>> the python-suds package to use the fork maintained by Jurko
>> Gospodnetić. Currently Fedora has the original version of Suds which
>> has not been maintained or updated since 2011. The original version
>> does not support Python 3.
>>
>> == Scope ==
>> Proposal owners:
>> * Update existing python-suds package to suds-jurko and ensure it
>> builds/works in Rawhide. (NOTE: proposal owner is not currently the
>> maintainer of python-suds, but would intend to assume maintainership
>> as part of this change.) The plan is to use the latest hg snapshot of
>> suds-jurko.
>
> Has the current python-suds maintainer been contacted about this
> change directly?  If so, did they have an opinion on it?
>

Chandan did contact him a while ago and I confirm that he did not
receive any answer.
Since maintainer is inactive for a while, I was thinking about doing
the update as provenpackager after a reasonable delay.

>> * In conjunction with the python-suds dependent package maintainers,
>> help test dependent packages to ensure they work correctly with the
>> new package.
>>
>> Other developers:
>> * For maintainers of packages that depend on python-suds: test the
>> dependent packages to ensure they work correctly with the updated
>> python-suds package. No changes should be needed as the Jurko fork is
>> believed to maintain compatibility with the original Suds.
>
> Can someone actually check this for compatibility instead of just believing?
>
> josh

Compatibility has been tested extensively by OpenStack, suds-jurko is
the current recommend fork of suds as upstream is unmaintained.
It is mostly bugfixes + more tests (and I hope that new package will run them)

suds-jurko upstream maintainer did a good job documenting the changes
and his fork is based upon latest revision from suds which is already
4 years old.

Regards,
H.

> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: no systemd in containers: Requires -> Recommends

[Haïkel]

2015-12-18 0:58 GMT+01:00 Jason L Tibbitts III :
>> "RWMJ" == Richard W M Jones  writes:
>
> RWMJ> Couldn't it use inotify (or whatever we're using these days to
> RWMJ> detect filesystem changes)?  So when you drop in the unit file,
> RWMJ> systemd notices and reloads.
>
> Well, the point is that systemd isn't running or even installed when the
> daemons are installed.  The question is what happens when systemd comes
> up later.  (And yes, systemd could use rpm file triggers so that we can
> drop the scriptlets entirely.  That would be great, but it's an entirely
> separate discussion.)
>
> I know this thread has gone in a completely different direction, but the
> original message was about modifying or removing the dependencies.  Can
> we drop dependencies on systemd and still have a system that works as
> expected if systemd gets installed later?  If so, then dropping the
> dependency doesn't actually hurt anything since the kernel will still
> pull it in, and thus the other arguments about this become kind of
> pointless.
>
>  - J<

We could waste time bickering but Jason made a point.
kernel-core requires systemd, so all running instances of Fedora
(except for containers) have systemd installed,
and since our systemd scriptlets are non failing, we could safely drop
the requirements in other packages.

I'm in favor of updating systemd guidelines to drop that requirements.

Regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

[EPEL-devel]Re: diskimage-builder in epel7

[Haïkel]

2015-12-08 16:04 GMT-05:00 Kevin Fenzi :
>
> They were included there by mistake when I was trying to fix another
> issue. ;(
>
> Should be cleared up now... can you check again?
>
> kevin
>

No worries, and I just verified that the list contains no foreign
repositories thanks to this quick'n' dirty one-liner:
jq '.["packages"][]|values["channel"]' pkg_el7.json | sort | uniq
[
]
  "rhel-7-server-extras-rpms"
  "rhel-7-server-extras-rpms",
  "rhel-7-server-optional-rpms"
  "rhel-7-server-optional-rpms",
  "rhel-7-server-rpms"
  "rhel-7-server-rpms",
  "rhel-ha-for-rhel-7-server-rpms"

Regards,
H.
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: Schedule for Wednesday's FESCo Meeting (2015-12-02)

[Haïkel]

Due to a business travel, I'll be missing this week meeting.
I'll make sure to review all the tickets though.

Regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Dealing with the "my packages" problem

[Haïkel]

2015-11-18 1:08 GMT+01:00 Jason L Tibbitts III :
> tl; dr: I have submitted the following RFE for pkgdb:
>   https://github.com/fedora-infra/pkgdb2/issues/274
> Please add comments there if you have any.
>
> I know I'm not the only provenpackager to have applied a bugfix to
> someone's package only to be yelled at it for it.  Some maintainers are
> more prickly about having others touch the packages they maintain for
> the community than others, and unfortunately there's currently just no
> way to know whether you'll be thanked or flamed for helping out with a
> package.
>
> After some IRC discussion I've come to the following proposal: that
> maintainers have some way to easily indicate how open they are to
> external contributions.  Basically this would take the form of a few
> options in pkgdb where maintainers can indicate their willingness to
> have provenpackagers carry out a few actions.  Please read the github
> ticket for details:
>   https://github.com/fedora-infra/pkgdb2/issues/274
>
> This would be purely advisory, with hopefully reasonable defaults.  I
> believe it has the potential to eliminate quite a bit of friction that
> provenpackagers must handle, as well as eliminate the hesitation some of
> us feel for fear of being flamed.
>
>  - J<

As a provenpackager, I prefer to send an heads up and briefly explain
(for non-trivial change) the reason. This lessen the friction a lot.

As a comaintainer, I've had issues with non-trivial changes and some
buggy updates (e.g. provenpackager pushing latest release though it's
known upstream to be broken).
Issues that could be avoided with minimal communications, I wish we
had an actual reviewing system that creates this communication and
lower the threshold to contributing at the same time.

Though I prefer review boards like gerrit or ReviewBoard, even a
simple Pull Requests based reviewing system as in Pague would be
welcome.

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Guidelines unclear for unretire of a branch

[Haïkel]

2015-11-17 15:02 GMT+01:00 Richard Shaw :
> I would like to unretire the epel7 branch of LibRaw, per the guidelines[1]
> this woudl require a re-review, but that would only make sense if the whole
> package was retired, not an epel branch.
>
> Why would we re-review something that still have active branches
> (specifically rawhide)?
>
> Thanks,
> Richard
>
> [1] https://fedoraproject.org/wiki/PackageDB_admin_requests#Other_requests
>


It has been retired because it's in RHEL7, hence it can't be shipped
in EPEL (cf. pkgdb)

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Quick proposal for making packager sponsorship slightly easier

[Haïkel]

2015-11-17 2:42 GMT+01:00 Jason L Tibbitts III :
> I recently filed https://fedorahosted.org/fesco/ticket/1499 with the
> goal of making the process just a bit simpler for new packagers.  The text of
> my proposal follows.  Please make sure that substantial comments are
> made on the ticket to ensure that FESCo sees them.
>
> -
> tl;dr: Relax the requirement that sponsors be directly involved in the
> package review process.
>
> Sponsors are responsible (but not solely responsible) for shepherding
> people through the packaging process. They should know how to do
> reviews, but there is nothing so special about a packager's first review
> that it cannot be handled by the regular packager community. We trust
> packagers to do every other package review, after all. We also allow new
> packagers to be sponsored without actually going through the package
> review process at all via the comaintainer process so what we appear to
> be emphasizing is that someone is there to assist and monitor the new
> contributor and not that the contributor make it through the arduous
> process of a package review with a highly restricted pool of reviewers.
>
> Proposal: Decouple sponsorship from the review process.
>
> Allow the community to do reviews as normal. Remove the requirement that
> the first review be done by a sponsor.
>

agreed

> Emphasize that sponsors can sponsor anyone separate from the review
> process. They can sponsor them before the review has been done, after it
> has been done, in the middle of the process, whatever. (This is all
> currently true in any case, but the process documents link most
> everything to the completion of a review.)
>
> Notes: Obviously sponsorship should still be tied to package maintenance
> in some way; sponsoring someone without any intention of having them
> work on a package in some way is pointless.
>
> Note that I do not intend to imply that sponsors need not know how to do
> proper package reviews. The guidelines for becoming a sponsor currently
> and should continue to specify that having done some package reviews is
> important to the process. The same goes for actually maintaining
> packages. Sponsors should know both the mechanics of maintaining
> packages and the standards for package quality.
>
> Hopefully this will open up the actual reviewing to the community as a
> whole, eliminating one bottleneck.
>
> We could potentially end up with people who have completed package
> reviews but who cannot yet actually import their packages. This would be
> worse than having people waiting in the sponsorship queue, because they
> actually did more work and someone from the community actually did some
> work as well. This could be mitigated through vigilance coupled with
> some scripting, or additional process in the packager-sponsor trac for
> requests that happen to fall through the cracks.
>

It's all the more important then to formalize requirements from new
packagers like having done two quality reviews and link them back to
their first package tickets.

Though the main bottleneck is time to properly mentor new packagers.

Regards,
H.

> Searching bugzilla for NEEDSPONSOR tickets still open with
> fedora-review+ set should be a reasonable first-pass report for those
> waiting. Mailing a filtered version of that to the sponsors would
> probably be effective but annoying.
>
>  - J<
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: What's the current status of mp3-licensing issues?

[Haïkel]

Hi,

You should have contacted fedora-legal list on that topic.
Besides, determining when a patent expires is not that easy and Fedora
Legal is backed by skilled lawyers that said the contrary. Unless Fedora
Legal confirms your theory (which I doubt), it's useless to discuss this on
this list.

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi should strip subjects

[Haïkel]

Again, what you're saying makes sense but if you don't file tickets,
it won't get fixed.

Here's bodhi bug tracker.
https://github.com/fedora-infra/bodhi/issues

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd package bloat

[Haïkel]

2015-11-06 16:35 GMT+01:00 Reindl Harald :
> it's one thing that there is a common tarball containing everything, but 26
> MB, 821 files including /usr/bin/machinectl and
> /usr/lib/systemd/systemd-machined useless on tiny virtual machines is too
> much and the beast is growing slightly
>
> F21: 22 MB
> F22: 24 MB
> F23: 26 MB
>
> there should be *really* subpackages instead a monoloithic one
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Excellent idea, please file a ticket and it'd be appreciated if you
could send patches.

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Elections - November 2015

[Haïkel]

2015-11-05 11:29 GMT+01:00 Jan Kurik :
> Hi,
>
> as Fedora 23 has been successfully released, we are starting with
> preparations for Elections. You can find schedule for these Elections
> at [1].
>
> Currently I am aware of the following teams we are going to organize
> Elections for:
>
> * FAmSCo (7 seats) - There were no Elections for more then a year, so
> all mandates are already expired. We need to re-elect the whole
> Ambassador team.
> * Council (1 seat)
> * FESCo (5 seats)
> * Env & Stacks WG (4 seats)
>
> I would like to ask whether there is any other team (working group)
> which needs to have its members elected and wants to join this
> Elections. If so, please let me know.
>

thanks!
None for the Cloud WG.

Regards.
H.
> [1] https://fedorapeople.org/groups/schedule/f-23/f-23-elections.html
>
> Thanks and Best Regards,
> Jan
> --
> Jan Kuřík
> Platform & Fedora Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2015-10-28)

[Haïkel]

Sorry for missing the meeting but as I said during the previous
meeting, I'll be in Japan until 11/3 due to the OpenStack summit.
It was quite late for me.
I'll also miss next week meeting as I'll be flying back home.

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [EPEL-devel] EPEL package rebased upon RHEL update?

[Haïkel]

2015-10-20 9:35 GMT+02:00 Christopher Meng <i...@cicku.me>:
> On 10/18/15, Haïkel <hgue...@fedoraproject.org> wrote:
>> Considering EPEL update policy, there's no argument not to skip 2.8
>> and upgrade to 3.0.
>> 2.8 will be dropped when 3.2 will be released (WiP), and migrating
>> from 2.4 to 2.8 is not easier than 2.4 to 3.0
>
> Migration from users can't be avoided I think, and I doubt if there
> are users using 2.4 since it's not supported and (may) full of
> security holes.
>

Yes, that's *exactly* what I was telling you. Skip 2.8 and update EPEL
branch straight to 3.0.x

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

Re: Unresponsive maintainer: patches <tchollingswo...@gmail.com>

[Haïkel]

2015-10-19 13:00 GMT+02:00 Viktor Jancik :
> Hi,
>
> As per the Policy for nonresponsive package maintainers:
> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
>
> I am writing here to ask you, if any of you know how to get in contact with 
> T.C. Hollingsworth?
>
> It appears he has been inactive for +6 months and I to contact him about some 
> of his packages.
>
> Thank you,
> Viktor
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Please re-read the policy, you're one week too early.
And if you want to update npm, you could also request ACLs.

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [EPEL-devel] EPEL package rebased upon RHEL update?

[Haïkel]

Considering EPEL update policy, there's no argument not to skip 2.8
and upgrade to 3.0.
2.8 will be dropped when 3.2 will be released (WiP), and migrating
from 2.4 to 2.8 is not easier than 2.4 to 3.0

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

Re: Looking for co-maintainers: zookeeper, bookkeeper, curator

[Haïkel]

2015-10-14 17:53 GMT+02:00 Christopher :
> I'm currently a co-maintainer on ZooKeeper. I know there's some bugs that
> I've overlooked these last few months. I intend to try to address some of
> them this week, but having another, esp. an upstream maintainer involved,
> would be nice.
>

Awesome, please get in touch and coordinate your work together.

@Raul: send me a private mail with your FAS account.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Looking for co-maintainers: zookeeper, bookkeeper, curator

[Haïkel]

2015-10-14 16:21 GMT+02:00 Raúl Gutiérrez Segalés :
>
> On Oct 14, 2015 7:14 AM, "Tim St. Clair"  wrote:
>>
>> I intend to orphan, and I simply don't have the bandwidth to maintain
>> these packages.
>>
>
> I am a ZooKeeper committer so I'd be happy to take over these (haven't
> officially maintained any packages though).
>
> -rgs
>

If you're an upstream maintainer, I can sponsor you through the
comaintainership process and help you
with topics related to RPM packaging and Fedora guidelines.

H.

>>
>> --
>> Cheers,
>> Timothy St. Clair
>> tstcl...@redhat.com
>>
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Ansible 2.0 in Fedora: review request for python-shade (and a copr)

[Haïkel]

Under review, thanks for preparing ansible 2.0 landing :)

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [EPEL-devel] Version bump for erlang

[Haïkel]

You need to open a ticket and request that version bump.

Note that this may conflict with EPEL updates policy, then the
alternatives would be providing a parallel installable version of
Erlang packages.
https://fedoraproject.org/wiki/EPEL_Updates_Policy

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

Re: Self Introduction: Nuno Dias

[Haïkel]

2015-10-10 21:38 GMT+02:00 Nuno Dias :
>  Hi,
>
>  Following the procedure from "Join the package collection
> maintainers", let me introduce myself,
>
>  I usually create rpms to my use, and after some years doing that, I
> realised that maybe I should contribute, I use Linux every day, I
> started with RedHat some year ago, and now Fedora is my Desktop.
>
>  The package I requested to review can be see in this link
>  https://bugzilla.redhat.com/show_bug.cgi?id=1270531
>
>  This is a Twitter, Facebook & Tumblr client.
>
>  Because it's my first package in Fedora, I need a sponsor.
>
> Thanks,
> Nuno
> --
> Nuno Dias 
>

Welcome into Fedora!
My sponsoring queue is already full, but I'll leave some comments in
your review.

Some recommendations to get sponsored faster:
* help decreasing the reviewing queue by providing *informal* reviews
for new packages
http://fedoraproject.org/PackageReviewStatus/NEW.html
* providing patches to fix existing packages may encourage a sponsor
to sponsor you.

Don't forget to link back your reviews and patches to your initial review

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Query: %cmake not doing out-of-tree builds?

[Haïkel]

2015-10-10 22:25 GMT+02:00 Neal Gompa :
> Hello all,
>
> Over the last few weeks, I've been working on a number of packages that use
> CMake for the build system for various distros, and I've noticed something
> rather peculiar. Of all the distros I've built packages for (Fedora/CentOS,
> openSUSE, Mageia, Debian, and Ubuntu), only Fedora/CentOS does not
> automatically do CMake building in a subdirectory such that the build
> artifacts don't mix in with the source tree. Essentially, the %cmake macro
> doesn't enforce builds are out-of-tree.
>
> Is there a particular reason for this?
>

According Rex who implemented the %cmake macro
https://www.redhat.com/archives/fedora-packaging/2007-March/msg00044.html

I must admit that I agree that out-of-tree builds is not  very useful
in RPM packaging case, as you always scratch the build directory.
Implementing out-of-tree builds who result in having to move between
directories during package building which could error-prone.

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ipset unmaintained

[Haïkel]

Done, fails to build in rawhide due to an unrelated ARM builder failure.

> DEBUG util.py:393:  Config error: releasever not given and can not be 
> detected from the installroot.
https://kojipkgs.fedoraproject.org//work/tasks/3255/11403255/root.log

F23 update submitted.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Query: %cmake not doing out-of-tree builds?

[Haïkel]

2015-10-11 2:14 GMT+02:00 Neal Gompa :
>
> I pretty much wound up doing that, but I wanted to know if there was a
> reason for not having it built into the macro like Mageia and SUSE do.
>
>

Fedora's %cmake macros came first many years ago before Suse's version.

Again:
1. it has little value for packaging, we don't reuse the sources
between two package builds.
If your CMake script is broken (no install rules), you should fix it.
I may be mistaken but it seems that you're trying to fix a package by
trial and errors: detecting generated files and then install them by
hand rather than patching your CMake script. Install rules are fairly
easy to write with CMake, and these patches could be upstreamed. [1]

Yes, out-of-tree builds is a nice feature of CMake but it's
interesting as a developer, not as a packager. We have very different
workflows, explaining why this is less important for packaging.

2. it is error-prone to implicitly move to a different directory.
Put yourself in a new packager's shoes: you want to copy a file from
sources (very common example: license file) and is not aware that the
%cmake macros moves you to a different directory, then, you get to
waste time trying to "debug" this.

3. As Orion stated, you can do an out-of-tree build explicitly, which is fine.

This is the typical example where simple design is better than
"smart". As a sponsor, I appreciate that the Fedora macro just do what
it's expected to do, nothing more (least-surprise principle). Mentees
have to learn a lot of concepts, read a lot of guidelines, do not add
them the burden of "smart" macros with unexpected behaviours. It will
save you *one* line in a spec, it could save many hours for many
newbies.
If you want my opinion, implementing a cmake template in rpmdev-tools
with out-of-tree build support would be a better alternative.

Regards,
H.

[1] this discussion reminded me of a very nice introduction to RPM
packaging from Matthias Saou about RPM packaging (The Fight), the
first step being "Know your enemy : The source!".
http://freshrpms.net/docs/fight/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ipset unmaintained

[Haïkel]

2015-10-10 22:37 GMT+02:00 Xose Vazquez Perez :
> Hi,
>
> Can anyone update it ?
> https://bugzilla.redhat.com/1145913
>
> -thanks-
>

Please start the unresponsive maintainer process.
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

Meanwhile, I'll update it in rawhide.

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: "Unbundling SIG" was [Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)]

[Haïkel]

2015-10-10 1:31 GMT+02:00 Kevin Kofler :
> Matthew Miller wrote:
>> When the packager has reasoned belief that debundling is actively bad
>> in some way for this package, I think we should trust the packager. I
>> know not everyone on this thread agrees, but in general, Fedora
>> *always* places a high level of trust in our packagers to make the
>> right call in all sorts of situations. Here, perhaps some of the
>> current (former?) pages on the rationale for unbundling could be moved
>> into the Unbundling SIG's space and used as guidance.
>
> I am worried that a lot of packagers will just refuse to do anything that
> upstream does not support, either:
> * because they ARE upstream, or
> * because they are too worried about offending upstream, or
> * because they are too lazy and/or too busy to rebase patches.
> And the often-cited fact that there are more and more upstreams not
> supporting unbundling only makes this WORSE and is actually a reason for
> MORE strictness in downstream policies, not less!
>
> The new policy does not require any kind of rationale for refusing, just
> saying "no" is enough to block everything.
>

In short: packagers are not to be trusted, that's the bottom line of
your argumentation.

Being putting down stricter guidelines without any means of enforcing
them, you're not solving anything.
FESCo choose to trust contributors to do the right thing and being honest.

>> Obviously we're not Debian, but I think this part from their Getting
>> Started guide applies to volunteer software projects in general:
>>
>> * We all are volunteers.
>>  * You cannot impose on others what to do.
>>  * You should be motivated to do things by yourself.
>>
>> 
>
> I find it funny that you are citing Debian in an attempt to support your
> point, because Debian actually has a "no bundled libraries" policy at least
> as strict as our old one.
>
> Kevin Kofler
>

Wrong, it's even more "laxist" than our current one.
https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
https://fedoraproject.org/wiki/User:Tibbs/BundlingDraft2

You know the difference? Debian trusts maintainers to do the right
thing by default.
If we can't trust Fedora maintainers, then we have another problem to solve.

Besides, you're not answering the question, Matthew changed the topic
to focus the discussion on the Unbundling SIG proposal.
I think it's a better idea to have a focused group leading that effort
and I hope closely with FPC.

I envision their mission being:
* work on detecting bundled libraries in the current packages collection
* work with package maintainers and upstream developers to reduce bundling.
* document
* cooperate with FPC to apply best practices
* cooperate with security team when CVE is discovered in a bundled lib
(filing tickets or apply fix as provenpackagers)
* provides metrics to follow the progress of that effort.

If you care about reducing bundling, this is a far more effective
solution than stricter guidelines.

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Haïkel]

2015-10-10 1:12 GMT+02:00 Kevin Kofler :
> Ian Malone wrote:
>> I'm actually all for unbundling, but going it alone is not guaranteed
>> to be simple. "Oh, hey, that deprecated function has been removed."
>
> Then you try to port the application to the new APIs, and if it's not
> possible, you revert the library commit that removed the old API.
>
> Kevin Kofler
>

And what happens if the library is consumed by other packages
requiring the new API?

Let's keep Ian example:
You keep the deprecated function in the new library despite upstream's
decision. Since we keep shipping it, developers will keep using it in
their new software, making it incompatible with other distro.
We only had one problem, now we have more problems.

Engineering is not science, as previously stated, it's about compromises.

H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Haïkel]

2015-10-10 12:17 GMT+02:00 Reindl Harald <h.rei...@thelounge.net>:
>
>
> Am 10.10.2015 um 11:27 schrieb Haïkel:
>>
>> Engineering is not science
>
>
> really?
>
>> as previously stated, it's about compromises
>
>
> well, that can end in something like "the cleverer give in until he becomes
> the dumber itself" in german "Der Klügere gibt solange nach bis er selbst
> der Dümmere ist"
>
>

Compromising is not the same thing as giving in.
If you can't tell the difference, then that explains a lot.

H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

[Haïkel]

2015-10-09 1:17 GMT+02:00 Kevin Kofler <kevin.kof...@chello.at>:
> Haïkel wrote:
>> Not that I'm 100% happy with the way it happened but this has been a
>> very long-lived topic. To some, it'll be a hasty decision, to others,
>> it's already a late one.
>
> There's a REASON it had always been shot down so far!
>
>> Please keep in mind, that Fesco is aware this is not a perfect
>> solution, and we''ll gladly review any proposals to improve this
>> policy.
>
> It is not possible to "improve" a policy that is fundamentally broken. The
> only possible improvement is to repeal/revert it.
>
>> But we can keep discussing this for years, or try to solve this issue
>> incrementally.
>
> Or we can just keep saying no, in compliance with our principles.
>
>> We chose the latter.
>
> What is "incremental" about this policy change? It is a radical U-turn.
>
>> No we didn't chose quantity over quality, it will only have a marginal
>> impact on the former.
>
> Then it will even have failed its stated purpose.
>
>> It doesn't prevent you to do unbundling
>
> It does. The maintainer can now say "no" to any non-upstream unbundling.
>
>> Pretending that the now-previous guidelines that many packages
>> (including recent ones) did not respect were preventing issues was
>> giving a false impression of security, that was *harmful*.
>
> If existing packages were not compliant to the policy, that's the problem
> you need to fix, by:
> 1. fixing the packages (not just threatening their removal from Fedora, but
>actually having a provenpackager go in and do the downstream unbundling),
>and

Sounds like you're volunteering for an Unbundling SIG, go ahead, you
have blessing.
I can even provide you a list of offending packages or ones that are
not updated because of the unbundling efforts (ie: hadoop)

> 2. for blatant or repeat offenses, unsponsoring both the submitters and the
>reviewers of the offending packages.
>

Good luck with that, we can't even ban repeated offenders on this very
list, let alone packagers that let bundled libs sneak in.

>> You're free to rant or work with us to improve the now-current policy.
>
> See above, the policy cannot be "improved" because it is fundamentally
> flawed and the exact opposite of what the policy should be.
>
> Kevin Kofler
>

I read all above and I still believe that you're turning something
that has always been a best-effort goal into some kind of dogma.
New policy needs better wording and guidelines changes but it's not
that different from the previous one.

Unbundling will still be required when possible and necessary (e.g
dead upstream), but we have now a better footing to track bundled
libs, and stop misguided behaviours.

Regards,
H.

> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

[Haïkel]

2015-10-09 16:20 GMT+02:00 Neal Gompa :
>
> A SIG dedicated to going through our packages and "systemizing" them (e.g.
> unbundling them) would probably be a really good idea, especially with the
> new rules. A group of packagers experienced in this could be solicited to
> help with trickier packages. As it is, it's pretty hard to solicit for help
> on packages. Last night, I was in #fedora-devel, where someone was working
> on a package to unbundle, and he was having a lot of trouble doing it on his
> own. He didn't have to, but was trying to anyway.
>
> I think our packagers generally want our packages to be system-friendly, but
> sometimes it can be very hard. We have SIGs to solicit experience for
> Python, Ruby, PHP, etc., why not have one for this too?
>
> Kevin, given that you're so passionate about this, why don't you create the
> SIG and gather folks to help support such efforts? It would be greatly
> appreciated.
>
>

+1
And I was serious about it, rather sticking to guidelines as if they
were dogma, I prefer positive actions to fight poor practices.

H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

[Haïkel]

2015-10-08 10:55 GMT+02:00 Tomas Mraz :
> On Čt, 2015-10-08 at 00:06 +0200, Kevin Kofler wrote:
>> Stephen Gallagher wrote:
>> > * #1483 Decision on bundling policy in the Fedora Package Collection
>> >   (sgallagh, 18:11:40)
>> >   * LINK: http://paste.fedoraproject.org/276064/44243383/ is sgallaghs
>> > proposal without the critpath distinction  (nirik, 18:43:49)
>> >   * AGREED: Adjust the packaging policy as described in
>> > http://paste.fedoraproject.org/276064/44243383/ (+5, 3, -1)
>> > (sgallagh, 18:57:44)
>> >   * ACTION: tibbs|w to inform FPC and work on removing the anti-bundling
>> > stuff from the guidelines  (sgallagh, 18:59:17)
>>
>> Ewww! :-(
>>
>> This opens the door to all kinds of duplication, waste of disk space, waste
>> of RAM, symbol conflicts and unfixed security issues!
>>
>> "Thanks" for making Fedora worse!
>
> Yes, it seems the quantity over quality view won. :(
> Also the haste with which it was pushed is seriously disappointing.
>
> --
> 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.)
>

Not that I'm 100% happy with the way it happened but this has been a
very long-lived topic. To some, it'll be a hasty decision, to others,
it's already a late one.

Please keep in mind, that Fesco is aware this is not a perfect
solution, and we''ll gladly review any proposals to improve this
policy. But we can keep discussing this for years, or try to solve
this issue incrementally. We chose the latter.
No we didn't chose quantity over quality, it will only have a marginal
impact on the former. It doesn't prevent you to do unbundling, track
bundled libraries, request FPC or peers feedback if you want.
Pretending that the now-previous guidelines that many packages
(including recent ones) did not respect were preventing issues was
giving a false impression of security, that was *harmful*.

You're free to rant or work with us to improve the now-current policy.

Regards,
H.

PS: I won't reply to private answers on that topic. It's either on the
list or it'll go to /dev/null
PPS: I encourage people complaining to participate more actively in
the reviewing pipeline, best way to prevent bundled libraries to be
sneaked in. Sloppy reviews and the lack of regular reviewing process
for current packages are a far more serious issue.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)

[Haïkel]

2015-10-09 0:08 GMT+02:00 Dominik 'Rathann' Mierzejewski
:
> On Wednesday, 07 October 2015 at 21:17, Stephen Gallagher wrote:
>> Meeting summary
>> ---
> [...]
>> * #1483 Decision on bundling policy in the Fedora Package Collection
>>   (sgallagh, 18:11:40)
>>   * LINK: http://paste.fedoraproject.org/276064/44243383/ is sgallaghs
>> proposal without the critpath distinction  (nirik, 18:43:49)
>>   * AGREED: Adjust the packaging policy as described in
>> http://paste.fedoraproject.org/276064/44243383/ (+5, 3, -1)
>> (sgallagh, 18:57:44)
>>   * ACTION: tibbs|w to inform FPC and work on removing the anti-bundling
>> stuff from the guidelines  (sgallagh, 18:59:17)
>
> This was handled far too quickly and without considering the full
> consequences of the change that was passed. Also, the way you handled
> this caused a lot of resentment among the FPC members (or at least
> that's the impression I have). Now, personal feelings aside, I do have
> some technical points to make, with my FPC hat on.
>

Thanks for doing that.


> The new wording completely drops the requirement for package maintainers
> to at least attempt unbundling on their own if upstream doesn't want to
> support it. In many cases, it's quite trivial and should be required,
> especially if upstream has a testsuite and it passes with downstream
> unbundling.
>

Ack, makes sense.

> You completely ignored the case when upstream is dead and cannot be
> contacted (and, for example the upstream of the bundled code is not).
>

This was discussed, I remember that this very point being raised by rishi.
We agreed (but not voted) that packages with dead upstream should unbundle.

I personally even consider that such packages should just be dropped
in the long-term.

=> I don't think anyone is against strict unbundling for dead upstream package.
Problem is how we detect that a package has a dead upstream :/

> Additionally, there's no requirement to maintain sanity in the bundled
> Provides: naming. You should have at least mandated that the maintainer
> checks existing packaged and/or bundled package names and uses the same
> name if the code is bundled in a new package. FPC or at least the
> packaging list should be consulted in case of any doubts here. We have
> considerable experience in this area and we (used to) maintain a canonical
> list of bundled(foo) provides. I believe it makes sense that we keep
> doing it.
>

*nods*
If FPC is willing to do that, that's fine with me.

> Finally, the wording speaks about libraries, completely ignoring the
> fact that very often, only single files or even code snippets are
> bundled and these need to be tracked as well. You haven't defined
> what a "library" is.
>

Yeah, many packages bundle crypto and checksum code, and these needs
to be tracked.

Any wording clarifications should be welcome, but I guess we'll have
to review this topic during fesco meeting again.

Regards,
H.


> Regards,
> Dominik
> --
> Fedora http://fedoraproject.org/wiki/User:Rathann
> RPMFusion http://rpmfusion.org
> "Faith manages."
> -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Haïkel]

2015-10-09 0:42 GMT+02:00 Kevin Kofler :
> Neal Gompa wrote:
>> Not that I don't agree that we should pursue unbundling whenever
>> possible, but I don't remember any contract or terms that explicitly said
>> *packagers* do the work of *developers* to re-architect
>> applications/services/etc to do stuff like that. In fact, I thought *the
>> whole point* of RPM packaging (and indeed packaging in general) was to
>> make it so that you could reliably build and install software. Spiting
>> upstream is just asking for trouble, too.
>
> The whole point of a distribution is to ship a well-integrated set of
> packages, not a bunch of isolated sandboxes that don't talk to each other.
> If we ship the latter, we become entirely redundant and provide no service
> whatsoever to our users.
>
> I consider unbundling to be about integration, not development. In most
> cases, you will be making little to no changes to the application's actual
> code, just fix its broken build system.
>

Erm, it may be a wording problem, but the new policy should require
you to unbundle in that case.


>> Personally, I would consider "upstream does not support it" a very valid
>> reason to not unbundle. It gets very hard to pin down where the problems
>> are caused when the rug is pulled out from under you. Some applications do
>> all kinds of things with their libraries or code chunks to make it safe or
>> useful for their needs.
>
> As I said, either fix the application to work with the library or fix the
> library to work with the application (and we need to force our library
> maintainers to be more flexible when it comes to the latter – there too,
> shipping an integrated set of packages is more important than blindly
> following upstream's wishes).
>
>> We should, of course, default to unbundling. But if it's not feasible, we
>> need a firm policy on how to include the software and continually engage
>> on developing solutions that are appealing to everyone on improving the
>> modularity of software and usefulness of reusing system copies of
>> libraries.
>
> It is almost always feasible. The new policy just encourages packagers to
> not even try!
>

No, the new policy encourages packagers to be *honest*, and not hide
issues under the carpet for stupid reasons.
As long as guidelines are not enforced, relaxing them won't do much more harm.

I prefer knowing the problem rather than pretending it does not exist.


H.

> Kevin Kofler
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [EPEL-devel] [Proposal] Converge EPEL and CBS

[Haïkel]

2015-09-24 18:58 GMT+02:00 Stephen John Smoogen <smo...@gmail.com>:
> On 24 September 2015 at 10:40, Haïkel <hgue...@fedoraproject.org> wrote:
>> Looks like we do have some progress on that topic :)
>>
>> So plan B would be:
>> 1. automate EPEL rebuilds in CBS
>> 2. have CI run automated test suite over EPEL rebuilds
>>
>> Correct me if I'm wrong but we would be ok to enable CentOS folks to
>> fix EPEL packaging.
>
> That is the 10,000 km view of the items. There is a LOT of detail that
> is lost at that height. There have to be CentOS people wanting to fix
> things in EPEL and they would need to get accounts in the Fedora
> system. There are always people saying they want this, but not a lot
> who do anything with it. [The reason for them to get a Fedora account
> is that any sort of federalization built into FAS is a ways out (1-2
> years at the rate FAS gets worked on?)]
>

Still an huge improvement compared to the previous dead-end.
What matters is that we agree on a common goal and start working toward that.

I implicitly volunteered myself to work on the build automation, as
I'm already currently doing a lot of *manual* rebuilds and syncing.


> There will also need to be done on what a proven packager is in EPEL
> land, and if it is even possible to have an epel-provenpackager which
> doesn't break fedora-provenpackager and vice versa. That is a lot of
> work which at the rate things work in CentOS and/or EPEL land is years
> off.
>

I separated this from the list as it doesn't prevent us to automate
EPEL rebuilds + CI, it's more something *nice to have* if we want to
make EPEL less foreign to CentOS folks.
From Kevin's answer, it should be possible. I cannot exactly estimate
the task but it's rather a question of months than years.


>
>> It would be easier if we do create an epel-provenpackager group
>> limited to EL branches distinct from fedora's provenpackager as in the
>> first proposal.
>>
>> If that's ok for everyone, let's wait Karsten speak to KB (and
>> hopefully, start working on this asap)
>>
>> H.
>> ___
>> epel-devel mailing list
>> epel-devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/epel-devel
>
>
>
> --
> Stephen J Smoogen.
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/epel-devel
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] [Proposal] Converge EPEL and CBS

[Haïkel]

Looks like we do have some progress on that topic :)

So plan B would be:
1. automate EPEL rebuilds in CBS
2. have CI run automated test suite over EPEL rebuilds

Correct me if I'm wrong but we would be ok to enable CentOS folks to
fix EPEL packaging.
It would be easier if we do create an epel-provenpackager group
limited to EL branches distinct from fedora's provenpackager as in the
first proposal.

If that's ok for everyone, let's wait Karsten speak to KB (and
hopefully, start working on this asap)

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

Re: [EPEL-devel] [Proposal] Converge EPEL and CBS

[Haïkel]

2015-09-22 21:18 GMT+02:00 Dennis Gilmore <den...@ausil.us>:
> On Monday, September 21, 2015 08:58:21 PM Haïkel wrote:
>> 2015-09-21 19:46 GMT+02:00 Kevin Fenzi <ke...@scrye.com>:
>> > On Mon, 21 Sep 2015 16:12:07 +0200
>> >
>> > Haïkel <hgue...@fedoraproject.org> wrote:
>> >> Hi,
>> >>
>> >> Since the CentOS acquihire, there was a lot of discussion about
>> >> EPEL's future. Since the FOSDEM meetup between Fedora/CentOS folks,
>> >> there was little progress on that topic
>> >>
>> >> After a discussion with a Smooge, I decided to come with a proposal,
>> >> knowing that
>> >> 1. Fedora wants to keep EPEL within it umbrella
>> >> 2. That CentOS SIGs are in practice rebuilding a lot of EPEL packages
>> >> (or retag them for other SIGs)
>> >> leading to poor maintenance as they don't follow EPEL tickets for all
>> >> their dependencies.
>
> Why is this? would it be enough that the CBS had epel as an external repo that
> can be added to SIG's projects? that way epel and updates can be available to
> build against.
>

Well, that was my first idea, but it ended up in dead-end, both EPEL
and CentOS have their arguments.
This situation is no good for both projects,  I tried to revive the
discussion through a proposal.

The point itself is not the proposal but to solve the problem that
there is no integrated vision between EPEL/CentOS.



>> > Which tickets do you mean here? They are only rebuilding some packages,
>> > but not others or?
>>
>> Any tickets filed against EPEL, for instance, if a bug or CVE is fixed
>> against EPEL package,  CBS rebuilds won't be impacted as there's no
>> way to automate that.
>> Some examples from CentOS Cloud SIG:
>> * RabbitMQ: it's a runtime requirement for OpenStack, we could just
>> reuse EPEL packages but that would mean that Cloud SIG repository
>> wouldn't be self-contained
>> => Nick Coghlan's RepoFunnel would be a solution to mash repositories here.
>> * A hell lot of python build requirements, that have to be rebuilt in
>> CBS, as CBS don't have access to EPEL packages.
> if we build and track in epel and use epel in CBS to build against we should
> be covered.
>
>> For instance, if the EPEL package gets fixed for a CVE, the CBS
>> package may not get fixed (and vice-versa).
>> Moreover, it makes mixing EPEL and CentOS SIGs repositories harder.
>>
>> >> 3. EPEL is not part CentOS plans, and as soon as SIGs will progress,
>> >> *may* turn the former irrelevant
>> >
>> > I suppose, but lots of people use/look to epel for packages, I don't
>> > think that will change to using packages from CentOS sigs overnight.
>>
>> I agree.
>>
>> >> 4. Some EPEL packages are poorly maintained especially on older EL
>> >> releases and/or orphaned
>> >
>> > Sure, just like any large collection of packages.
>>
>> Yes, but all the more a reason to make it easier for CentOS community
>> to participate to this efforts
>
> I am all for making it easier to contribute to EPEL, one thing to consider is
> that to contribute to EPEL you must agree to the FPCA, afaik CentOS does not
> have an equivalent and at the least Legal requires it for Fedora and EPEL
>
>> >> We've reached the point where both EPEL/CBS would greatly benefit to
>> >> join hands.
>> >>
>> >> So I suggest that we consider the following:
>> >> * EPEL will still use Fedora dist-git
>> >> * EPEL builds should be done in CBS to make it easier for SIGs to
>> >> consume it.
>> >
>> > How do EPEL maintainers launch builds in CBS?
>>
>> Through bstrinson centpkg tool as for the tooling aspect
>> (infra-related issues are covered in a later point)
> why would it need to if we are using fedora's dist-git? It seems very very
> messy here.
>
>> > How do builds get signed?
>>
>> That would be left to CentOS core SIG team
> Okay, I would like to know what exactly that means and entails, for one we
> have no way to export the private keys for epel from Fedora's sigul server.
> changing keys would be a pain and require a lot of careful work.
>
>> > How do updates get pushed out to EPEL users? Does CentOS have a bodhi
>>
>> Good question, from my current experience, I get little feedback on my
>> EPEL updates and never got one pushed to stable just through karma.
>
> So what can we do to add extra QA and testing? as that is what is needed to
> get builds pushed via karma. 

[EPEL-devel] [Proposal] Converge EPEL and CBS

[Haïkel]

Hi,

Since the CentOS acquihire, there was a lot of discussion about EPEL's future.
Since the FOSDEM meetup between Fedora/CentOS folks, there was little
progress on that topic

After a discussion with a Smooge, I decided to come with a proposal,
knowing that
1. Fedora wants to keep EPEL within it umbrella
2. That CentOS SIGs are in practice rebuilding a lot of EPEL packages
(or retag them for other SIGs)
leading to poor maintenance as they don't follow EPEL tickets for all
their dependencies.
3. EPEL is not part CentOS plans, and as soon as SIGs will progress,
*may* turn the former irrelevant
4. Some EPEL packages are poorly maintained especially on older EL
releases and/or orphaned


We've reached the point where both EPEL/CBS would greatly benefit to join hands.

So I suggest that we consider the following:
* EPEL will still use Fedora dist-git
* EPEL builds should be done in CBS to make it easier for SIGs to consume it.
* EPEL will use CentOS repositories instead of mirroring RHEL repositories
* Bridging Fedora/CentOS accounting system (CentOS is migrating to
FAS)  <== we need to see the feasibility of this but that would be
optimal, that would increase the permeability between our two
contributors pools which is something, we all want to encourage.
* Create a EPEL provenpackager group under CentOS core SIG
supervision, allowing them to appoint people to maintain EPEL
packages.

I suggest that we keep the EPEL name to acknowledge EPEL historical
effort to provide quality additional packages for EL distros.
Fedora contributors would still be able to contribute to EPEL, and
CentOS contributors to make it up their standards.

Would that work for you?

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

Re: [EPEL-devel] [CentOS-devel] [Proposal] Converge EPEL and CBS

[Haïkel]

2015-09-21 16:38 GMT+02:00 Dave Johansen :
>
>
> I'm a maintainer of several EPEL packages and a CentOS user. After reading
> through this, I don't understand the value in this shift. Also, what are the
> potential negatives of the change?
> Thanks,
> Dave
>

I don't see any negative except that it will require some efforts to
do the transition (and I'm already volunteering to work on that).
Bridging two FAS instances may not be possible currently.
The value is that, what CentOS SIGs are trying to build will leverage
EPEL without having them duplicate in a poorly fashion, work done in
EPEL.
https://wiki.centos.org/SpecialInterestGroup
Enhancing collaboration between EPEL and CentOS will allow us to ship
a much better curated EPEL repository, you're more likely to find
people able to provide proper maintenance of EPEL packages within the
CentOS community.

And if CentOS ended up rebuilding an EPEL-like repositories (which
will happen sooner or later), what will happen to EPEL? Moreover,
rebuilding EPEL from scratch will be painful and long process.

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

Re: [EPEL-devel] [Proposal] Converge EPEL and CBS

[Haïkel]

2015-09-21 19:46 GMT+02:00 Kevin Fenzi <ke...@scrye.com>:
> On Mon, 21 Sep 2015 16:12:07 +0200
> Haïkel <hgue...@fedoraproject.org> wrote:
>
>> Hi,
>>
>> Since the CentOS acquihire, there was a lot of discussion about
>> EPEL's future. Since the FOSDEM meetup between Fedora/CentOS folks,
>> there was little progress on that topic
>>
>> After a discussion with a Smooge, I decided to come with a proposal,
>> knowing that
>> 1. Fedora wants to keep EPEL within it umbrella
>> 2. That CentOS SIGs are in practice rebuilding a lot of EPEL packages
>> (or retag them for other SIGs)
>> leading to poor maintenance as they don't follow EPEL tickets for all
>> their dependencies.
>
> Which tickets do you mean here? They are only rebuilding some packages,
> but not others or?
>

Any tickets filed against EPEL, for instance, if a bug or CVE is fixed
against EPEL package,  CBS rebuilds won't be impacted as there's no
way to automate that.
Some examples from CentOS Cloud SIG:
* RabbitMQ: it's a runtime requirement for OpenStack, we could just
reuse EPEL packages but that would mean that Cloud SIG repository
wouldn't be self-contained
=> Nick Coghlan's RepoFunnel would be a solution to mash repositories here.
* A hell lot of python build requirements, that have to be rebuilt in
CBS, as CBS don't have access to EPEL packages.

For instance, if the EPEL package gets fixed for a CVE, the CBS
package may not get fixed (and vice-versa).
Moreover, it makes mixing EPEL and CentOS SIGs repositories harder.


>> 3. EPEL is not part CentOS plans, and as soon as SIGs will progress,
>> *may* turn the former irrelevant
>
> I suppose, but lots of people use/look to epel for packages, I don't
> think that will change to using packages from CentOS sigs overnight.
>

I agree.

>> 4. Some EPEL packages are poorly maintained especially on older EL
>> releases and/or orphaned
>
> Sure, just like any large collection of packages.
>

Yes, but all the more a reason to make it easier for CentOS community
to participate to this efforts

>> We've reached the point where both EPEL/CBS would greatly benefit to
>> join hands.
>>
>> So I suggest that we consider the following:
>> * EPEL will still use Fedora dist-git
>> * EPEL builds should be done in CBS to make it easier for SIGs to
>> consume it.
>
> How do EPEL maintainers launch builds in CBS?

Through bstrinson centpkg tool as for the tooling aspect
(infra-related issues are covered in a later point)

> How do builds get signed?

That would be left to CentOS core SIG team

> How do updates get pushed out to EPEL users? Does CentOS have a bodhi

Good question, from my current experience, I get little feedback on my
EPEL updates and never got one pushed to stable just through karma.

> instance?
>
>> * EPEL will use CentOS repositories instead of mirroring RHEL
>> repositories
>
> CBS seems to not have ppc64... so no more ppc64 EPEL packages?
>

True, if we could get some stats over ppc64 (and any arch unsupported
by CentOS), that would help weighting on the decision as for any
trade-off.

> Also, this would probibly be some kind of big deal to some people who
> like that EPEL is built against rhel. Personally, I don't think it
> matters, but it would have to be communicated clearly.
>

(I also saw Karsten reply about it)
It needs to be communicated, but considering CentOS good history on
that matter, I personally don't think it's big deal, too.


>> * Bridging Fedora/CentOS accounting system (CentOS is migrating to
>> FAS)  <== we need to see the feasibility of this but that would be
>> optimal, that would increase the permeability between our two
>> contributors pools which is something, we all want to encourage.
>
> Bridging in which way? what information would be good to communicate
> back and forth?
>

I'm not familiar enough with the FAS/pkgdb architecture, so I will
just list some requirements.
* ensure that EPEL packagers could rebuild their packages in CBS
* ensure that CentOS core SIG could administrate epel-provenpackager group

Off course, it could be minimal and may not require syncing FAS
instances, in the end.

>> * Create a EPEL provenpackager group under CentOS core SIG
>> supervision, allowing them to appoint people to maintain EPEL
>> packages.
>
> Overriding the existing EPEL maintainers?
>

Yes, as provenpackager could do with most Fedora packages but limited
to EPEL branches.
I know this may be difficult to give some control to another
organization over part of our project. But we need to consider that
Fedora/CentOS are part of a larger ecosystem.


>> I suggest that we keep the EPEL name to acknowledge EPEL historical
>> effort to provide

Re: Proposal to reduce anti-bundling requirements

[Haïkel]

2015-09-15 13:02 GMT+02:00 Ralf Corsepius :
>
> a) We don't have any such tracking system.

If maintainers followed FPC recommendations on that matter, it will be
very easy to have one.
I have in my TODO to implement one for CentOS Cloud SIG to track
security issues for some horrible packages


> b) So far, this has not been a problem.
>

Not being aware of the problem is different from not having a problem.
Famous example being requests bundling other common libraries and
itself being bundled by the rest of the world. All those funny REST
clients with buggy code and nobody cares upstream.

> In the past, this these issues were commonly worked around by Fedora
> maintainers forking in private and them feeding them into Fedora as set of
> patches.
>

Yes, and I'm working on a proposal on guidelines + tooling to make it
easier to work on that.
And preferably self-hosted in Fedora thanks to pagure.

>> Our role is mitigate bad habits and educate upstream, not ignoring them.
>
> Right, but you're underestimating the stubbornness and non-cooperativeness
> of some upstream and fedora maintainer.

Sadly, no.

> They usually believe to have an "ultra-clever design" and the FPC to be dumb
> idiots who are unable to comprehend their cleverness.
>
> Ralf
>

Well, I'm personally thankful that FPC "dumb idiots" and alike taught
me proper engineering when I was young graduate a decade ago.
I think that every developer should once in a while, put his hands
into packaging/integration or system administration to understand what
they're doing.

(forgot to send this one, but well, we don't praise enough FPC for
their awesome work)

>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Haïkel]

2015-09-14 13:17 GMT+02:00 Andrew Haley <a...@redhat.com>:
> On 09/13/2015 09:23 PM, Haïkel wrote:
>> I'm not speaking about PHP, most of the upstream I deal with
>> are python developers. Bad habits are rather spreading than
>> regressing.
>
> We're not going to solve that problem by adopting bad habits
> ourselves.
>
> Andrew.
>

Did I request somewhere to *drop* unbundling?
I'm more concerned by the current habit to let bundled libraries sneak
in the repositories without being properly tracked rather than a
non-existing one.
I suggested that we allow to a certain extent bundling under conditions:
* enforcing bundled libraries tracking
* requiring approval from trusted packagers (I suggested that
Fesco/FPC allow selected SIGs to grant bundling requests on *limited*
set of packages => ie: python SIG for python modules that are not
critpath)
* distinguishing case where unbundling is unnecessary (ie: upstream
maintains both lib and application, and lib is not meant to be used
standalone)

That still leaves out a lot of packages not acceptable in Fedora and
I'm more in favor of tighter integration of copr for these (ie: having
blessed copr repo)
Nick made a very appealing proposal about software pipeline in that area.

Our role is mitigate bad habits and educate upstream, not ignoring them.

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Haïkel]

2015-09-14 12:45 GMT+02:00 Reindl Harald :
>
>
>
> and much more important:
>
> if Fedora changes to more and more recommend "pip", "gem" and "cpan" like
> installs instead RPM packages it is no longer a distribution over the long
> because that would mean finally you have a core OS and handle anything else
> like Microsoft or Apple - does anybody really want to go that road?
>

Stop oversimplifying the debate, just integrating programming
languages package managers into the distro one, doesn't mean there
won't be any integration.

We could:
1. integrate install by pip/gem/cpan into RPM database as previously said
2. integrate them with dnf
3. mirror upstream repositories and trim them for Fedora users
4. spend more time fixing integration issues upstream rather focusing
on packaging.
5. focus on continuous integration of packages too

I'm not saying that's the way we should go, but don't kill the
discussion before it even started. It's important to leverage our past
experience but we shouldn't let it tie us to the point we can't evolve
anymore.

What's important is not to ship code in little packages, but to ship a
consistent and rock-solid experience to our users.
And there's more than one way to do it.

H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Haïkel]

2015-09-14 14:38 GMT+02:00 Dominik 'Rathann' Mierzejewski
:
>
> This case doesn't automatically mean that we should allow bundling.
> Especially, if there are multiple consumers of the library in question.
> A recent example is kwsys, which is bundled in every project released
> by kitware. See bugs [1][2][3]. Another example is rawspeed, bundled
> in three independent applications [4][5][6].
>

Yes, and that's what we should be discussing!

> New bundling exception could be granted automatically in cases where:
> * the bundled code is not packaged in Fedora yet
> * no other Fedora package bundles it already
>

Interesting idea, unbundling on demand.

I may ask what happens for heavily modified bundled libraries


> However, the above puts the burden of unbundling on the second packager
> who attempts to package something that bundles the same code.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1251198
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1251281
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1251289
> [4] https://bugzilla.redhat.com/show_bug.cgi?id=1248730
> [5] https://bugzilla.redhat.com/show_bug.cgi?id=1248756
> [6] https://bugzilla.redhat.com/show_bug.cgi?id=972604
>
> Regards,
> Dominik

In that aspect, that's the reason I want to encourage packages to work
within SIGs to lessen the burden.

H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Rpmbuild SPEC file - variable declaration

[Haïkel]

I might add that fedora-review could be run on local spec + srpm
and will warn you about these kinds of things.

H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Haïkel]

2015-09-13 10:16 GMT+02:00 Andrew Haley :
>
> The development model followed by much of the upstream world is
> immature: it may not even be repeatable, let alone well-defined.
> Shoehorning upstream's mess of bundled requirements is a very useful
> service that we can provide to our users.  By behaving in a mature way
> we can show that free software can be more reliable (predictable,
> trustworthy) than proprietary software.
>

That's quite the idyllic picture and it might have been true a decade ago.

But, distros have lost the influence they used to have then, we're in the
cloud/container era where people bundle everything ...

Before, upstream used to welcome patches to unbundle libraries or
we just ignored niche projects with difficult upstream.
Now, it's very common that large upstream projects just tell us to get
lost.

Results:
1. Packages maintainers burning out in following fast-paced projects
as some bundled libs have older API than latest releases, others are
heavily modified, and others are added.
2. Decrease in quality as these changes rejected by upstream are not
tested in their CI or by their community. Let's recognise that our QA for
packages is quite weak.
3. We can't ship a lot of "critical" packages for our users that ends up
relying on third party repo with far *lower* standards, or switch to other
distros.
4. Bundled libs are sneaked in thanks to sloppy incoming reviews and
that we usually don't review existing packages.

1 => it's important that we do not task our fellow contributors with
unreasonable efforts.

2 & 3 => that's something that makes us less relevant for end users

4. => ruins completely the effort. Moreover, security team can't track
CVE for these bundled libraries as they're not announced.


The difficulty is here to keep the incentive of pursuing the effort, while
relaxing the rules to discourage bad practices from our folks, and keep
Fedora relevant to users.

Long-term solution would probably be rings or alike, so we could focus
on properly curated core, and have groups focusing on a small set of
packages without affecting the rest of us.



> I remember the time before free software distros like Fedora: it was
> chaotic, with messes of bundles and contradictory dependencies from
> all over the place, with no reliable tools for finding things.
> Relying on the upstream ecosystem's way of sorting this out, with a
> different mechanism provided depending on programming language, isn't
> going to do it.
>
> Andrew.
>

The world has changed, and containers have made this problem less
relevant so it's gonna stay like this for a while.
Ignoring that fact would just lead to our downfall, and leave the space
to alternatives with lesser quality.

H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Haïkel]

2015-09-13 20:40 GMT+02:00 Matěj Cepl <mc...@cepl.eu>:
> On 2015-09-13, 13:13 GMT, Haïkel wrote:
>> But, distros have lost the influence they used to have then, we're in the
>> cloud/container era where people bundle everything ...
>
> And they won't retake it by giving up. Then they will just give
> ammunition to the idiots persuading them they are right.
>

Nope, they end up telling their users just not to use Fedora
packages or not using Fedora at all.


That's common sense that if nobody uses Fedora, no upstream
will care about our "peculiar" requests. Influence is necessary.


>
> My experience is very different. Sensible languages and their
> universe usually welcome sensible patches. Even some less
> sensible universes are moving towards more sensible state ...
> certainly even such monster as Java is (hopefully, slowly)
> moving in the right direction, I see some (some!) movement in
> the right direction even in the JavaScript world (ES6, some
> efforts in the NodeJS world).

The Java world is definitively not moving in the right direction.


> Yes, there is PHP, but I believe that their brightest moment has
> passed and they will either start to do sensical engineering
> (and that means way more than just unbundling) or they will
> slowly vanish. Certainly, I don't think PHP is the reason why
> Fedora should change their direction.
>

I'm not speaking about PHP, most of the upstream I deal with
are python developers. Bad habits are rather spreading than
regressing.

Recently, the new trend among python developers is to follow
Kenneth Reitz stupid habit to bundle all dependencies in
his modules though we have pip and ability to pin versions!

> And if somebody thinks docker & co. is the answer, then we
> should wait just a little bit before they discover that the
> content of their containters needs maintenance as well, and
> before their customers discover that they have infrastructure
> full of old unmaintatenable junk.
>
> Certainly, an engineer who prostitutes himself and in order to
> be popular accepts stupid decisions of his clients is not
> something I would like to follow.
>
> Matěj
>

Thanks for calling me a whore.

If you care about purity, I care about all those hidden bundled
libs carrying CVE shipped in Fedora that are not properly referenced
and tracked security team.

Good engineering is not just about technical prowess but being able to
prevent customers/users to shoot themselves in the foot.


I think I do not want to debate anymore if people purposefully
mix a proposal to relax a guideline with dropping it.
That's a cheap trick.

H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No autocomplete for new package in bodhi 2.0?

[Haïkel]

There's autocompletion on package name, but looks like bodhi
autocompletion database was not refreshed.


H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Haïkel]

2015-09-10 15:53 GMT+02:00 Stephen Gallagher :
> I assume that subject line got your attention.
>
> I know this is a long-standing debate and that this thread is likely
> to turn into an incomprehensible flamewar filled with the same tired
> arguments, but I'm going to make a proposal and then attempt to
> respond to many of those known arguments up-front (in the hopes that
> we can try to keep the conversation on-track). Please keep the
> conversation on devel@lists.fedoraproject.org . I CCed packaging@ to
> make them aware of this discussion.
>
>
>
> Right now, we have a policy that essentially forbids source code from
> being bundled into a package. In technical terms, this means
> essentially that the packaging policies mandate that any code that
> appears more than once in the repository must be turned into a shared
> library and dynamically linked into any package that requires it. Any
> package that wants an exception to this must petition the Fedora
> Packaging Committee and get an explicit exemption from this policy.
> This process is heavyweight and sometimes inconsistent in how the
> decision is made.
>
> I would like to propose that the no-bundled-libraries policy be
> amended  as follows: "Any package that has an existing mechanism to
> link against a shared system library and functions correctly when
> doing so must link against that library and not bundle it internally.
> Any package whose upstream releases cannot link against a shared
> system library (or are incompatible with the version in Fedora) may
> bundle that library (without requiring a special exemption) but MUST
> add Provides: bundled() =  in the spec file for each
> known bundled library.(This will allow us to track down the bundling
> when we need to). Package maintainers should continue attempt to
> engage upstream to support linking against shared system libraries
> wherever possible, due to the advantages it provides the package
> maintainer."
>

Well, I won't discuss about benefits of unbundling vs bundling, this
is a sterile conversation.

I'll just point out that a non-negligible part of Fedora packages already
bundle libraries. Unless we want to mass-review and ban all those packages,
I consider that Stephen's proposal to be an *improvement* to the current
situation.

I would prefer that we also empower SIGs or provenpackagers to grant or not
those bundling exceptions and enforce the provides thing.

If you disagree, please come up with a counter-proposal even if it
means dropping half of Fedora packages.
Keeping status quo is at best diverting our eyes from bad practices,
at worst, hypocrite.

>
>
> The reason for this proposal is relatively simple: we know the
> advantages to unbundling, particularly with security and resource-
> usage. However, the world's developer community largely *does not
> care*. We fought the good fight, we tried to bring people around to
> seeing our reasoning and we failed.
>
>
> The point of software is to provide a service to an end-user. Users
> don't run software because it has good packaging policies, they run
> software because it meets a need that they have. If they can't get
> that software from Fedora, they *will* get it from another source (or
> use a different OS that doesn't get in their way). I'll take a moment
> to remind people that two of Fedora's Four Foundations are "Features"
> and "First". We want Fedora to be the most feature-complete
> distribution available and we want to get there before anyone else
> does. I would say that holding to our no-bundling policy actively
> defeats our efforts on that score.
>
>
>
> Let me describe some of the advantages to bundling and to unbundling
> (as noted so we can hopefully skip some of the hotter parts of the
> flamewar). As I noted above, anything that is capable of unbundling
> should remain unbundled for its advantages. But things that are not
> currently capable (or can't be due to forwards/backwards compatibility
> issues, etc.) really shouldn't be forced to attempt it.
>
>
> == Advantages to using shared libraries ==
>  * Security/Bugs - When a bug or security vulnerability is located in
> a library, it needs to be patched in only a single package in order to
> fix all applications using that library.
>  * Resources - A shared library only needs to be loaded into memory
> once, reducing the memory requirements of the system.
>
> == Advantages to bundling ==
>  * Guarantees that the application is running with the same set of
> code that upstream tested. (Fewer Fedora-specific bugs means less
> burden on the maintainer)
>  * Simplifies packaging of updates. (Fedora maintainer does not need
> to keep tabs on unbundling patches to keep in sync for new versions)
>  * Increases the available pool of software that can be packaged
> substantially (many modern languages such as Ruby and Go are
> realistically only functional with allowable bundling)
>  * Did I mention the reduction in maintainer burden yet?
>
>

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Haïkel]

2015-09-11 21:09 GMT+02:00 Josh Stone :
> On 09/11/2015 10:35 AM, Stephen Gallagher wrote:
>> Actually, the opposite is true. RHEL has fewer limitations in this
>> space. Red Hat's layered projects ship a fair amount of bundled stuff.
>> This problem is entirely Fedora's. Fedora has far stricter rules than
>> RHEL in this regard.
>
> It helps that we have paid maintainers for RHEL.  Bundling is not as bad
> when there's some assurance that it won't stagnate.  But in general with
> unpaid community members, it's harder to be sure things will be actively
> maintained.

Keyword is *some*, there are packages in RHEL that are less maintained than
they are in Fedora.
I'd rather insist that RHEL has a smaller set of packages that makes
it easier that
most of them are better curated.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Haïkel]

2015-09-11 21:26 GMT+02:00 Jóhann B. Guðmundsson :
>
>
> Right as well as most issues already have been found and fixed in Fedora
> long before those components enter RHEL.
>
> JBG
>

Fair point, Fedora brings value to Red Hat and it is acknowledged.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Haïkel]

2015-09-11 20:24 GMT+02:00 Jóhann B. Guðmundsson :
>
>
> The inclusion of what now 15k components in the distribution is a testimony
> of success of un-bundling against your testimony of ( few ) failures of
> bundling.
>
> JBG
>

Say that *after* you properly reviewed the current set of packages.
You'd discover that sloppy reviews and upstream changes has resulted
in plenty of bundled libraries in the distro.

And if we were to strictly forbid unbundling, you'd have no single
web app or javascript packages in Fedora.

I for one would be in favor of delegating SIGs the right to lift *some*
packaging guidelines.
FPC has enough workload than reviewing every bundled library
requests, that does not scale.
I'd rather ensure that we know about packaging guidelines violations
and have them reviewed by trusted packagers than letting everyone sn
eaking them in.

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Haïkel]

2015-09-11 23:37 GMT+02:00 Dominik 'Rathann' Mierzejewski
:
>
> It's not an improvement as such. We already require the Provides:
> bundled(foo) thing, though we rely on the good will of maintainers
> (both in Fedora and upstream) because we have practical means of
> enforcement.
>

It's currently not enforced and as some maintainers bypass the current policy,
it's not gonna change.

>
> Which SIGs? FPC is the the right general SIG for this. I guess you
> meant something along the lines of: Perl SIG would grant/deny exceptions
> for perl-* packages, Python SIG would do the same for python* packages,
> and so on. That... isn't entirely a bad idea IMHO, but I think it'd
> have to be tracked anyway.
>

+1 for FPC
But analyzing pros and cons of unbundling takes a lot of time, so if
we could allow some
SIGs. ie: python, perl, big data to do overrides FPC on a limited and defined
set of packages, it'd scale better.

Off course, SIGs would need blessing from fesco or FPC, or it
would be to easy.


> What if one provenpackager grants an exception and another disagrees?
>

 Good point, if we ended going that way, it would be formal rules.


>> If you disagree, please come up with a counter-proposal even if it
>> means dropping half of Fedora packages.
>
> Please don't speak in unsubtantiated hyperboles. If you have specific
> numbers detailing the extent of bundling in existing packages then
> please present them.
>

I have no specific numbers, but I regularly find bundled code in existing
packages. Latest was CFEngine bundling code from RPM ...
Some modules of interpreted languages fork base libs and ship them too.

Some critical packages like Puppet regularly requires shipping bundled
libs. Some packages like Hadoop are stuck to very old releases, as unbundling
libs is a neverending task. Upstream even advise users not to use
Fedora packages.

We could ignore them but we'll be less and less relevant and our influence
on upstream projects to bring good practice will fade.
A vibrant Fedora that can influence upstream to improve is better than
ignored Fedora


>> Keeping status quo is at best diverting our eyes from bad practices,
>> at worst, hypocrite.
>
> Not at all, IMHO. The FPC is dealing with cases of bundling as they're
> brought to our attention. I believe there are enough cases that are not
> straightforward to decide to warrant analyzing them closely and voting.
> As you've probably noticed, not everyone on the FPC has exactly the same
> stance on bundling, though we all agree that it's bad in the general
> case.
>
> Regards,
> Dominik

I'm not criticizing FPC here, you're doing a great job while having a
lot pressure
on your shoulders.
It's rather about people who refuse to discuss that topic.

In a decade, the world has changed, in a good or bad way, not up to me
to decide.
I agree that bundling is a terrible practice, but we need to weight
pros and cons
and accept that we may change our policies.


> --
> Fedora http://fedoraproject.org/wiki/User:Rathann
> RPMFusion http://rpmfusion.org
> "Faith manages."
> -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

macros.python2 requires update in F21+

[Haïkel]

Hi,

Recently, we had a lot of issues with openstack packages due to python
newer guidelines.
To fix upgrade path for python2 modules, you had to obsolete previous
python-xxx module.
Orion committed a fix in rawhide in the macro %python_provides that
fixes that issue.

http://pkgs.fedoraproject.org/cgit/python.git/commit/?id=7fdb9bedcda48894b7ba85e34ca5722b28b69076
http://pkgs.fedoraproject.org/cgit/python.git/commit/?id=cb9dd734593c52b84f0b9b6f19f352001c1d50d3

Could we backport these in F21/22/23 ?
It's rather critical, as we have less experienced packagers pushing
updates without checking
the upgrade path or provides/obsoletes. Having a reliable
%python_macros as in rawhide makes it more
robust and will avoid breaking users dependencies

I prefer that python maintainers do the update as it's a critical
package, but I don't mind doing it in their stead
if you approve this (if necessary)


Regards,
H.
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Sane ownCloud alternatives (was: Re: Looking for new maintainer: ownCloud (Fedora / EPEL))

[Haïkel]

There's also cozy cloud , though it's JavaScript much less insane than
owncloud.
https://cozy.io/

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi 2 now live

[Haïkel]

2015-08-22 4:46 GMT+02:00 Christopher Meng i...@cicku.me:

 Occupying the moral high ground doesn't help as well.
 --

 Yours sincerely,
 Christopher Meng


If you want your bugs to be fixed, posting them on a list and
ignoring the bug tracker doesn't work.

And for people who don't want to go through github, the old trac
is still open and reviewed by infra team:
https://fedorahosted.org/bodhi/newticket

For the rest, read the code of conduct.

Regards,
H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: bodhi 2 now live

[Haïkel]

2015-08-22 12:07 GMT+02:00 Reindl Harald h.rei...@thelounge.net:

 come on the bugtracker also don't work
 https://bugzilla.redhat.com/show_bug.cgi?id=1226509#c5


Thanks for definitively killing this thread by posting something unrelated.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Sponsors - who does (not) work on FE-NEEDSPONSOR tickets

[Haïkel]

2015-08-21 0:58 GMT+02:00 Orion Poplawski or...@cora.nwra.com:
 On 08/20/2015 02:50 AM, Miroslav Suchý wrote:

 I was just watching the ongoing reports of want-to-be-contributors how hard 
 is to get sponsored; reports how Fedora
 Repository stalled [1]; discussion that we actually do not know how many 
 active sponsors we have.
 ...

 [1] 
 https://eischmann.wordpress.com/2015/07/27/growth-of-fedora-repository-has-almost-stalled/

 My gut reaction to this is, my god, we don't need *more* packages in Fedora,
 we need more people maintaining the pile we already have.  So I'd like to see
 more packagers added as co-maintainers of packages.



I agree on the part that we should encourage comaintainership.

But I'm still skeptical on the comaintainership process which is much
less transparent than the classic one.
I prefer limiting this to upstream maintainers (which I assume care
about tending to their packages) or someone
that will be closely supervised by an experienced packager.

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