Re: Please sweep bodhi updates to testing in a timely manner

[Philip Kovacs via devel]

 
> But there's not anything actually wrong anymore?\
>I'm not sure what else you would like me to do here...>kevin

Yeah it's all good now -- f30 and f29 are all in testing now.   Thanks for 
checking.Phil___
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
  ___
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: Please sweep bodhi updates to testing in a timely manner

[Kevin Fenzi]

On 8/10/19 5:34 PM, Philip Kovacs via devel wrote:
>  UTC 00:00:00 has come and gone and nothing was pushed to testing, yet again.

Updates pushes are not instant. You shouldn't expect them all to finish
at 00:00:01. They did indeed fire off as expected at 00:00 and finished
some hours later, as they always do.

>  My reference to "7 days" was the time I have to wait until I can request 
>stable.That timer cannot start until the packages hit testing.

ok

> There really should be more than one guy who happens to be at a 
> conferencetaking care of this.
 But there's not anything actually wrong anymore?

I'm not sure what else you would like me to do here...

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

[389-devel] 389 DS nightly 2019-08-11 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/08/11/report-389-ds-base-1.4.1.6-20190810git21ba842.fc30.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following builds have been pushed to Fedora EPEL 8 updates-testing

aom-1.0.0-8.20190810git9666276.el8
drbdlinks-1.28-7.el8
libmodplug-0.8.9.0-9.el8
pdns-4.1.13-1.el8
python-bsddb3-6.2.6-5.el8
python-pymilter-1.0.4-3.el8
squidGuard-1.4-35.el8
tcpreplay-4.3.2-2.el8
ufw-0.35-14.el8
xorgxrdp-0.2.10-4.el8
xrdp-0.9.10-3.el8
zvbi-0.2.35-9.el8

Details about builds:



 aom-1.0.0-8.20190810git9666276.el8 (FEDORA-EPEL-2019-a27847dadb)
 Royalty-free next-generation video format

Update Information:

Update to commit 9666276accea505cd14cbcb9e3f7ff5033da9172

References:

  [ 1 ] Bug #1558224 - Review Request: aom - Royalty-free next-generation video 
format
https://bugzilla.redhat.com/show_bug.cgi?id=1558224




 drbdlinks-1.28-7.el8 (FEDORA-EPEL-2019-7569d7857c)
 Program for managing links into a DRBD shared partition

Update Information:

The drbdlinks program manages links into a DRBD partition which is shared among
several machines. A simple configuration file, `/etc/drbdlinks.conf`, specifies
the links. This can be used to manage e.g. links for `/etc/httpd`,
`/var/lib/pgsql` and other system directories that need to appear as if they are
local to the system when running applications after the drbd shared partition
has been mounted.  When running drbdlinks with `start` as the mode, drbdlinks
will rename the existing files/directories and then make symbolic links into the
DRBD partition, `stop` does the reverse. By default, rename appends `.drbdlinks`
to the name, but this can be overridden.  An init script is included which runs
`stop` before heartbeat starts, and after heartbeat stops. This is done to try
to ensure that when the shared partition isn't mounted, the links are in their
normal state.

References:

  [ 1 ] Bug #1737964 - drbdlinks depends on Python 2
https://bugzilla.redhat.com/show_bug.cgi?id=1737964




 libmodplug-0.8.9.0-9.el8 (FEDORA-EPEL-2019-ebaf5c08ad)
 Modplug mod music file format library

Update Information:

- New package

References:

  [ 1 ] Bug #1739156 - libmodplug for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1739156




 pdns-4.1.13-1.el8 (FEDORA-EPEL-2019-89a0da3a65)
 A modern, advanced and high performance authoritative-only nameserver

Update Information:

- Update to 4.1.13    The PowerDNS Nameserver is a modern, advanced and high
performance authoritative-only nameserver. It is written from scratch and
conforms to all relevant DNS standards documents. Furthermore, PowerDNS
interfaces with almost any database.




 python-bsddb3-6.2.6-5.el8 (FEDORA-EPEL-2019-b8a583cb1e)
 Python 3 bindings for Berkeley DB

Update Information:

Rebuild for EPEL 8.

References:

  [ 1 ] Bug #1738715 - Please build python-bsddb3 for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1738715




 python-pymilter-1.0.4-3.el8 (FEDORA-EPEL-2019-2b476a55b9)
 Python interface to sendmail milter API

Update Information:

Untested as I haven't figured out how to apply developer subscription to my
rhel8 vm.

References:

  [ 1 ] Bug #1738718 - Please build python-pymilter for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1738718

Re: Why retire Python 2 packages and games that still work to end user ?

[Kevin Kofler]

Nico Kadel-Garcia wrote:
> Maintaining python 2 requires maintaining a *lot* of infrastructure.

What kind of infrastructure do you need to maintain a package that is (will 
be) no longer updated upstream? This takes almost no work. The only thing to 
do is to backport some security fixes from Python 3, and occasionally to fix 
FTBFS bugs.

Now if your concern is maintaining all the python2-* packages, then there 
ought to be some middle ground between maintaining all of them including 
ones that are not used by anything in Fedora anymore, and just dropping all 
of them (with or without the planned exception process, whose usefulness 
depends entirely on how willing FESCo will be to approve the requests). 
Maybe the set of python2-* modules in EL7 or EL8, with or without EPEL, 
minus the ones already retired from Fedora by now, would be a reasonable 
starting point?

I also think that there ought to be more cooperation from the maintainers of 
individual python2-* modules. The approved Fedora 31 Change makes it way too 
easy for maintainers to just drop Python 2 support for no reason. If 
upstream dropped Python 2 support from the current version and so an old 
version has to be packaged specifically for Python 2, that is one good 
reason to require somebody else to pick up maintenance, but as it stands, no 
such reason is required and Fedora maintainers can arbitrarily drop Python 2 
support from their Python modules even if upstream still supports it. This 
is just pointless and unhelpful.

We can try to find people to pick up python2 and a bunch of python2-* 
modules, but expecting the python2 maintainer(s) to sign up for maintaining 
each and every python2-* module is unreasonable and unrealistic. Even if 
several of them will also be dead upstream (at least the version that works 
with Python 2) and thus require very little maintenance effort.

> To support multiple pythons, python26, python28 if it ever happens,
> python36 python38 when it comes out.

The whole reason for this discussion is that Python 2.8 will likely never 
happen. It definitely will not happen from Python upstream. Otherwise, there 
would not be all this talk about dropping Python 2 due to being unsupported 
upstream.

I don't see much point in supporting Python 2.6, which is even more ancient 
than Python 2.7, and 2.7 is backwards-compatible with 2.6.

And supporting multiple versions is not an argument for not having at least 
a python2 symlink and Provides: python2 in python27.

> Simply replacing the "python2" line iwth "python27" is not a difficent
> edit in most source code.

But it is still a completely unnecessary edit.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Orphaning cloud-init, python-boto

[Gwyn Ciesla via devel]

I'll take python-goto. FAS: limb.

Sent from ProtonMail mobile

 Original Message 
On Aug 10, 2019, 8:06 PM, Garrett Holmstrom wrote:

> Hi,
>
> My time to work on Fedora cloud-related things has diminished in
> recent months, so I have not been able to give the cloud-init and
> python-boto packages the care they deserve. They are free to a good
> home.
>
> Thanks,
> --
> Garrett Holmstrom
> ___
> 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___
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

Orphaning cloud-init, python-boto

[Garrett Holmstrom]

Hi,

My time to work on Fedora cloud-related things has diminished in
recent months, so I have not been able to give the cloud-init and
python-boto packages the care they deserve.  They are free to a good
home.

Thanks,
--
Garrett Holmstrom
___
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

[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem

[Stephen John Smoogen]

On Sat, 10 Aug 2019 at 17:12, Miro Hrončok  wrote:

> On 10. 08. 19 21:23, Miro Hrončok wrote:
> > While I really tried to do my best, it seems that I broke CentOS by
> retiring
> > python36. Should it be unretired? Or is it reasonable to say: Please
> wait for
> > CentOS 7.7?
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1739804
>
> If any EPEL expert thinks the package should be unretired for now, please
> do so.
>
>
Miro, please unretire the packages for the 2-3 weeks til CentOS 7.7 is out
in the CR repo. My apologies for not thinking of this when you were
mentioning things yesterday. I do not have the rights to unretire things so
will need to get in touch with Mohan/Kevin/Mizdebsk on what to do.



> > Also after retiring python-rpm-macros, Koji doesn't seem to see the RHEL
> one. Is
> > there any action to take?
> >
> >
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/UKHD6IXORQ6RNNL4JZ67PGQHOMIBVUZZ/
> >
> >
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
>


-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Re: Please sweep bodhi updates to testing in a timely manner

[Philip Kovacs via devel]

 UTC 00:00:00 has come and gone and nothing was pushed to testing, yet again.  
My reference to "7 days" was the time I have to wait until I can request 
stable.That timer cannot start until the packages hit testing.
There really should be more than one guy who happens to be at a 
conferencetaking care of this.

On Saturday, August 10, 2019, 04:40:31 PM EDT, Kevin Fenzi 
 wrote:  
 
 On 8/10/19 11:33 AM, Philip Kovacs via devel wrote:
> Just look at the updates pending pages.  Here are f30 and f29, resp:
> https://bodhi.fedoraproject.org/updates/?releases=F30=pending
> https://bodhi.fedoraproject.org/updates/?releases=F29=pending

Updates are pushed every single day at 00:00UTC.

However, todays failed because there were some unsigned packages.
(This is caused by updates that stay in updates testing for a long time
and their signed copies get grabage collected).

I fixed that and finished the broken push, but I am at flock and didn't
have time to start a full push. One should fire off in about 3 hours...

There should never be an update that waits 7 days to push to testing...

kevin
--
>    On Saturday, August 10, 2019, 02:29:24 PM EDT, Stephen John Smoogen 
> wrote:  
>  
>  
> 
> On Sat, 10 Aug 2019 at 13:22, Philip Kovacs via devel 
>  wrote:
> 
> Why does it take days sometimes just to start the 7 day timer? 
> 
> Can we have some examples to track this down? Because without that.. no idea 
> and no way to fix.
>  
> ___
> 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
> 
> 
> 
> 
> ___
> 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
> 

___
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
  ___
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: Package removal for FTBFS: Add automatic orphaning?

[Christopher]

On Sat, Aug 10, 2019 at 7:33 PM Miro Hrončok  wrote:
>
> On 11. 08. 19 0:34, Kevin Kofler wrote:
> > Miro Hrončok wrote:
> >> Obviously, we can prevent this by only orphaning packages with NEW bugz,
> >> but that doesn't really solve anything, because lot of the retired
> >> packages were actually ASSIGNED/POST/MODIFIED (for months).
> > Of course they were, to prevent you from retiring them even sooner.
>
> If the only reason to set the status to ASSIGNED/POST/MODIFIED is to prevent
> **me** from retiring the package, something is fundamentally broken.
>
> If somebody has a legitimate reason to have a FTBFS package not retired, they
> can ask for some kind of exception from Releng, not provide inaccurate 
> information.
>

I was actually trying to work on some of mine... one of the FTBFS
(thrift) I had was actually because of an optional python2-only
component from upstream I was intending to disable once F31 was
released, if I couldn't recruit a python person to help me fix it
(because I don't know python). But, the entire package was retired
anyway it was *very* much unexpected for me, because I thought I'd
have some more time to patch it once F31 came out (the package in F30
is fine... and I don't care about rawhide... I care about the latest
version of Fedora that people are actually using).

Several other packages I had were Java packages that I was still
trying to figure out the state of their BuildRequires which were in
modules. The last I read on this list was "there may be some news
about that"... and then *bam* RETIRED... at least one I know for sure
was marked ASSIGNED. At least one of these I had fixed the FTBFS once,
but then it broke again, so I left the same issue open until I could
fix that one also... but it also was retired.

This FTBFS policy is *TOO* aggressive, and very unfriendly to casual
packagers, and at a time of significant disruption in Fedora due to
modularity. There should be some extra leniency for a few versions
while the dust from modularity settles, and it *definitely* should be
orphaned first if the maintainer isn't responding to FTBFS bugs.

There's so much disruption going on in Fedora right now... things are
moving too quickly for casual packagers, and it seems like a lot of it
is behind the scenes, motivated by internal interests of RedHat, and
*not* what is in the best interests of the community. It was *not* the
right time to forcibly retire hundreds of packages while these changes
are occurring. Many of these broken packages are probably because
casual maintainers like me are struggling to keep up with the changes.
Instead, now is the time to apply more mentoring, and leadership to
assist those packagers get things in order, to figure out how to get
those packages into appropriate modules, as needed, to assist in
patching for python3, to help them take orphaned BRs, etc.

This sends a very bad message, something along the lines of "only
hard-core, full-time, dedicated packagers allowed; you're on your own
and if you can't get things working in Fedora, you're out".

Also, I have a question about retirement as it pertains to modularity:
let's say a package was retired because its BRs moved into modules
but now the only way to get the BRs (short of packaging all the java
stuff myself) is to put it in a module. Can I do this for a retired
package? Does ursine packages have to be un-retired in order to create
a module?
___
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: Why retire Python 2 packages and games that still work to end user ?

[Nico Kadel-Garcia]

On Sat, Aug 10, 2019 at 7:47 PM Kevin Kofler  wrote:
>
> Sérgio Basto wrote:
> > Why we would retire childsplay or gcompris or gdesklets ? IMHO we still
> > haven't a replacement .
> >
> > From  [1] I strongly disagree with the text,  why all python 2 packages
> > will be removed automatically and why I would have a lot of work if I
> > want keep one package alive . why not the opposite ? .
> > Python 3 it isn't even the default why such hurry to drop python 2 at
> > all , when we still have epel 7 with python 2 ...
> >
> > My opinion at least postpone this decision one or two releases to
> > Fedors 33/34 , many things still just work with python 2 .
>
> I second that wholeheartedly.
>
> This change is just not implementable as it stands. Way too much upstream
> software still depends on Python 2. (In fact, I am not even convinced that
> it can be implemented as stated, ever, without dropping huge parts of Fedora
> and making it useless for a wide number of users. But what is sure is that
> it definitely cannot implemented without huge fallout in time for Fedora
> 32.)

Maintaining python 2 requires maintaining a *lot* of infrastructure.

> I also completely fail to see what value the rename from python2 to python27
> (yet another one, after the already pointless rename from python to python2)
> will bring to our users. But the worst part is the required FESCo exception
> approval for every single remaining Python 2 package, along with loads of
> bureaucracy that many packages will be unable to comply with (starting from
> the plan to move to Python 3, which depends on upstream, if there is even a
> live upstream to begin with).

To support multiple pythons, python26, python28 if it ever happens,
python36 python38 when it comes out.

Simply replacing the "python2" line iwth "python27" is not a difficent
edit in most source code.

>
> This is absolutely not a reasonable and social way to deal with
> compatibility packages in Fedora.
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://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
___
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: Package removal for FTBFS: Add automatic orphaning?

[Kevin Kofler]

Miro Hrončok wrote:
> If the only reason to set the status to ASSIGNED/POST/MODIFIED is to
> prevent **me** from retiring the package, something is fundamentally
> broken.

This is not about you personally, but about the FTBFS process. :-)

> If somebody has a legitimate reason to have a FTBFS package not retired,
> they can ask for some kind of exception from Releng, not provide
> inaccurate information.

Packagers' time is limited, and there are usually much more important issues 
to solve than an FTBFS in Rawhide. (In fact, anything in Rawhide is lowest-
priority for me. If it is an FTBFS without an associated broken dependency, 
even more so.) So if setting the bug from NEW to ASSIGNED buys the 
maintainer a few months extra time to fix the low-priority issue (which is 
the case in the current bizarre rules), why would they NOT do this?

The best way to prevent bugs being falsely set to ASSIGNED is to just drop 
the perverse incentive to do so by dropping point 5 from the FTBFS policy.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Why retire Python 2 packages and games that still work to end user ?

[Sérgio Basto]

On Sun, 2019-08-11 at 01:35 +0200, Miro Hrončok wrote:
> On 11. 08. 19 1:05, Sérgio Basto wrote:
> > Hi,
> > 
> > Why we would retire childsplay or gcompris or gdesklets ? IMHO we
> > still
> > haven't a replacement .
> 
> If the maintainer wants to, they can request an exception for the
> package to be 
> kept.

yes, but just gives more work to package maintainers .

> >  From  [1] I strongly disagree with the text,  why all python 2
> > packages
> > will be removed automatically and why I would have a lot of work if
> > I
> > want keep one package alive . why not the opposite ? .
> 
> Opposite? Retire Python 3? 

The opposite, is just removed the authorized packages . If  maintainer
not respond or aren't against to . 


> > Python 3 it isn't even the default why such hurry to drop python 2
> > at
> > all , when we still have epel 7 with python 2 ...
> 
> Python 3 is the default.

On Fedora 30 still be Python 2 (Python 2.7.16) and Fedora 31 is not yet
released .

Thanks,

> > My opinion at least postpone this decision one or two releases to
> > Fedors 33/34 , many things still just work with python 2 .
> 
> As I ask repeatedly: Who will maintain the Python 2 ecosystem?
> 
> > [1]
> > https://fedoraproject.org/wiki/Changes/RetirePython2
> 
> -- 
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://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
-- 
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://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: Why retire Python 2 packages and games that still work to end user ?

[Kevin Kofler]

Sérgio Basto wrote:
> Why we would retire childsplay or gcompris or gdesklets ? IMHO we still
> haven't a replacement .
> 
> From  [1] I strongly disagree with the text,  why all python 2 packages
> will be removed automatically and why I would have a lot of work if I
> want keep one package alive . why not the opposite ? .
> Python 3 it isn't even the default why such hurry to drop python 2 at
> all , when we still have epel 7 with python 2 ...
> 
> My opinion at least postpone this decision one or two releases to
> Fedors 33/34 , many things still just work with python 2 .

I second that wholeheartedly.

This change is just not implementable as it stands. Way too much upstream 
software still depends on Python 2. (In fact, I am not even convinced that 
it can be implemented as stated, ever, without dropping huge parts of Fedora 
and making it useless for a wide number of users. But what is sure is that 
it definitely cannot implemented without huge fallout in time for Fedora 
32.)

I also completely fail to see what value the rename from python2 to python27 
(yet another one, after the already pointless rename from python to python2) 
will bring to our users. But the worst part is the required FESCo exception 
approval for every single remaining Python 2 package, along with loads of 
bureaucracy that many packages will be unable to comply with (starting from 
the plan to move to Python 3, which depends on upstream, if there is even a 
live upstream to begin with).

This is absolutely not a reasonable and social way to deal with 
compatibility packages in Fedora.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Why retire Python 2 packages and games that still work to end user ?

[Miro Hrončok]

On 11. 08. 19 1:05, Sérgio Basto wrote:

Hi,

Why we would retire childsplay or gcompris or gdesklets ? IMHO we still
haven't a replacement .


If the maintainer wants to, they can request an exception for the package to be 
kept.



 From  [1] I strongly disagree with the text,  why all python 2 packages
will be removed automatically and why I would have a lot of work if I
want keep one package alive . why not the opposite ? .


Opposite? Retire Python 3?


Python 3 it isn't even the default why such hurry to drop python 2 at
all , when we still have epel 7 with python 2 ...


Python 3 is the default.


My opinion at least postpone this decision one or two releases to
Fedors 33/34 , many things still just work with python 2 .


As I ask repeatedly: Who will maintain the Python 2 ecosystem?


[1]
https://fedoraproject.org/wiki/Changes/RetirePython2


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Package removal for FTBFS: Add automatic orphaning?

[Miro Hrončok]

On 11. 08. 19 0:34, Kevin Kofler wrote:

Miro Hrončok wrote:

Obviously, we can prevent this by only orphaning packages with NEW bugz,
but that doesn't really solve anything, because lot of the retired
packages were actually ASSIGNED/POST/MODIFIED (for months).

Of course they were, to prevent you from retiring them even sooner.


If the only reason to set the status to ASSIGNED/POST/MODIFIED is to prevent 
**me** from retiring the package, something is fundamentally broken.


If somebody has a legitimate reason to have a FTBFS package not retired, they 
can ask for some kind of exception from Releng, not provide inaccurate information.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Does anybody care about gettext?

[Dridi Boukelmoune]

On Sat, Aug 10, 2019 at 10:28 PM Kevin Kofler  wrote:
>
> Miro Hrončok wrote:
> > Because if we don't, people just gonna ignore FTBFS forever.
>
> And this would be a problem why exactly?
>
> Packages built for older Fedora releases tend to run on newer Fedora
> releases just fine. If the package:
> * has no broken dependencies, and
> * is not reported as completely broken in Bugzilla,
> it should be assumed to be working by default.
>
> If you encounter a package that does not actually work, it is your job as a
> user to report it. This can happen independently of whether the package
> still compiles or not. It can even still be broken after a successful
> rebuild.
>
> So why are we wasting packagers' time on fixing FTBFS issues (which are
> typically NOT caused by their package, but by changes in dependencies such
> as your python-unversioned-command change, or such as yet another
> incompatible change in GCC for the sake of compliance with some obscure
> subparagraph of a language standard, etc.) when not actually needed? I
> actually NEED to fix the FTBFS if the package has broken dependencies or if
> I need to make some other change to it. Otherwise, the FTBFS fix is just
> churn that Fedora forces me to waste my time on.

Hi,

I understand where you are coming from, but I still disagree. I think
there has been an unfair hostility towards Miro on this topic.

Your package suddenly FTBFS because of dependencies or system-wide
changes but the latest package build is still functional? I agree that
there is no urgency to fix this, but I disagree that status quo is
fine X releases later.

For starters may miss out on system wide changes (and whether someone
agrees with proposed changes is not the question) and in the case you
made about bug reports that mandate action from the maintainer, not
taking care of FTBFS timely means that once shit hits the fan you have
to both solve the FTBFS situation and the user-facing bug report.

So yes, it sucks when someone's package fails because someone else
screwed up by not coordinating an soname bump or whatever, but it
doesn't mean that we can keep the latest successful build around and
let the source repository bit-rot forever because there are no bug
reports.

Now there's certainly room for improvement, but I don't have a
solution to offer and hammering Miro because he's been (very) active
lately retiring FTBFS or orphan packages (as per the normal process)
is helping. Here we had an acknowledgement from a couple maintainers
and someone who stepped in to help, a very positive outcome.

Dridi
___
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: [Bug 1675390] mingw-wine-gecko: FTBFS in Fedora rawhide/f30

[Kevin Kofler]

Miro Hrončok wrote:
> What would you want to do instead? Keep shipping th Fedora 26 package
> forever?

Since this is actually an MSI blob that is a drop-in replacement for the MSI 
blob from WINE upstream (where the version number expected by WINE is 
hardcoded and has not changed for years) and that contains PE binaries that 
are loaded by WINE, there is no reason why the F26 package would not just 
work. The PE binaries are covered by the W32/W64 binary compatibility 
guarantees, and the upstream blob being replaced has not changed for years.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

Why retire Python 2 packages and games that still work to end user ?

[Sérgio Basto]

Hi,

Why we would retire childsplay or gcompris or gdesklets ? IMHO we still
haven't a replacement .

From  [1] I strongly disagree with the text,  why all python 2 packages
will be removed automatically and why I would have a lot of work if I
want keep one package alive . why not the opposite ? .
Python 3 it isn't even the default why such hurry to drop python 2 at
all , when we still have epel 7 with python 2 ...

My opinion at least postpone this decision one or two releases to
Fedors 33/34 , many things still just work with python 2 .

Best regards,

[1]
https://fedoraproject.org/wiki/Changes/RetirePython2
-- 
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://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: Package removal for FTBFS: Add automatic orphaning?

[Kevin Kofler]

Miro Hrončok wrote:
> Obviously, we can prevent this by only orphaning packages with NEW bugz,
> but that doesn't really solve anything, because lot of the retired
> packages were actually ASSIGNED/POST/MODIFIED (for months).

Of course they were, to prevent you from retiring them even sooner.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Does anybody care about gettext?

[Kevin Kofler]

Miro Hrončok wrote:
> Because if we don't, people just gonna ignore FTBFS forever.

And this would be a problem why exactly?

Packages built for older Fedora releases tend to run on newer Fedora 
releases just fine. If the package:
* has no broken dependencies, and
* is not reported as completely broken in Bugzilla,
it should be assumed to be working by default.

If you encounter a package that does not actually work, it is your job as a 
user to report it. This can happen independently of whether the package 
still compiles or not. It can even still be broken after a successful 
rebuild.

So why are we wasting packagers' time on fixing FTBFS issues (which are 
typically NOT caused by their package, but by changes in dependencies such 
as your python-unversioned-command change, or such as yet another 
incompatible change in GCC for the sake of compliance with some obscure 
subparagraph of a language standard, etc.) when not actually needed? I 
actually NEED to fix the FTBFS if the package has broken dependencies or if 
I need to make some other change to it. Otherwise, the FTBFS fix is just 
churn that Fedora forces me to waste my time on.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

Need help to review these packages

[Robert-André Mauchin]

Hello,
 
 I need your help to review these Go packages:
 
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=Package%20Review=zebob.m%40gmail.com=1=substring_id=10401033=Fedora_format=advanced
 
 They are needed to update others or fix FTBFS. I'd love to be able to get to 
them before branching.

I can review anything else in exchange.

Best regards,

Robert-André



___
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

[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem

[Bryan J Smith]

Robert-André Mauchin  wrote:

> How long would that wait be?
>

RHEL7.7 is only 4 days old.  Everyone running CentOS should be planning
their patching cycles around the lull between a brand new RHEL Update and
the CentOS build/catch-up.

- bjs
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem

[Robert-André Mauchin]

On Saturday, 10 August 2019 21:23:55 CEST Miro Hrončok wrote:
> While I really tried to do my best, it seems that I broke CentOS by retiring
>  python36. Should it be unretired? Or is it reasonable to say: Please wait
> for CentOS 7.7?
> 
How long would that wait be?

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem

[Miro Hrončok]

On 10. 08. 19 21:23, Miro Hrončok wrote:
While I really tried to do my best, it seems that I broke CentOS by retiring 
python36. Should it be unretired? Or is it reasonable to say: Please wait for 
CentOS 7.7?


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


If any EPEL expert thinks the package should be unretired for now, please do so.

Also after retiring python-rpm-macros, Koji doesn't seem to see the RHEL one. Is 
there any action to take?


https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/UKHD6IXORQ6RNNL4JZ67PGQHOMIBVUZZ/ 





--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem

[Bryan J Smith]

Stephen John Smoogen  wrote:

> This was the purpose of the various branching proposals. The main issue
> there are
>
not enough time/manpower resources to make any of the proposals work as it
> needs
>
build system changes, a full time release manager and packagers who want to
> deal with it.
>
In the end though this is a volunteer project done on the side by various
> people in the
>
Fedora community. If we were to move this elsewhere, it would still be a
> volunteer activity.
>
I wish I had a better answer but after seeing us break the world every
> RHEL-X.Y release.. I don't.
>

Indeed, it's a thankless job.
Sincerely, keep up the good work, and that goes for all maintainers too.

I've always advised those running 'downstream' versions wait to update
until they are on the same, new 'Update' after any new RHEL release.  It's
a good rule to follow -- e.g., RHEL 7.7 just came out.

- "Still lurking" bjs


P.S.  For those that don't know, starting a good 7 years ago I brought up
the increasing 'breakage' with RHEL as Fedora EPEL build various packages
for CentOS because CentOS rebuilding various RHEL add-ons.  Simply put, at
a half-dozen major Red Hat accounts, I had to warn EPEL would now conflict
in various ways outside of the very RHEL core, so RHEL systems couldn't be
subscribed to it, and each EPEL package needed to be vetted into an
internal channel/repo (e.g., Satellite) before even considering deployment.

I also worked with both Red Hat GLS as well as Partners over the next 18
months to tell them to yank all sections regarding EPEL from Training,
Enablement and other documentation, as only core RHEL compatibility was the
goal, not all of RHEL.

So at that time I suggested the idea of forking into Emerging Technologies
for Enterprise Linux (ETEL) from EPEL.  That way, people who wanted newer
Fedora stuff or, in the case of CentOS not rebuilding various Enterprise
add-ons available for RHEL, or even newer versions of packages in RHEL
add-ons, would have a separate repo from EPEL that was never supposed to
conflict.

As Stephen, Kevin and others others pointed out for that to happen,
increases of resources and volunteer hours would have to happen.  And
that's just the reality.  Not everyone is going to be made happy, given the
constraints.  So we should all appreciate what we have.  I'm just glad EPEL
still focuses on at least core RHEL.

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem

[Stephen John Smoogen]

On Sat, 10 Aug 2019 at 16:18, Andrew C Aitchison 
wrote:

> On Sat, 10 Aug 2019, Richard Grainger wrote:
>
> >> On 10 Aug 2019, at 20:23, Miro HronÄ ok  wrote:
> >>
> >> While I really tried to do my best, it seems that I broke CentOS by
> >> retiring python36. Should it be unretired? Or is it reasonable to
> >> say: Please wait for CentOS 7.7?
> >
> > This is why I believe we need a “CentOS-EPEL† repo that mirrors EPEL
> > generally, but that is frozen in the period between a RHEL and
> > CentOS release.
>
> The same could be said for a Scientific-Linux-EPEL.
> Would it be clearer to have an EPEL7.6 and an EPEL7.7 ?
>

This was the purpose of the various branching proposals. The main issue
there are not enough time/manpower resources to make any of the proposals
work as it needs build system changes, a full time release manager and
packagers who want to deal with it. In the end though this is a volunteer
project done on the side by various people in the Fedora community. If we
were to move this elsewhere, it would still be a volunteer activity.

I wish I had a better answer but after seeing us break the world every
RHEL-X.Y release.. I don't.


-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Re: Does anybody care about gettext?

[Kevin Fenzi]

On 8/10/19 12:48 PM, Björn Persson wrote:
> Kevin Fenzi wrote:
>> On 8/10/19 4:12 AM, Björn Persson wrote:
>>> Rafal Luzynski wrote:  
 9.08.2019 22:10 Jerry James  wrote:  
> Source: https://ftp.gnu.org/pub/gnu/gettext/%{name}-%{version}.tar.xz

 Do we need to change ftp to https?  
>>>
>>> That's the wrong question to ask. The right question is: What reason is
>>> there to choose an insecure protocol when HTTPS is available?  
>>
>> I'm confused by this... https is already being used, it is just the
>> hostname that is 'ftp'.
> 
> When I posted, gettext.spec in the master branch still said:
> 
> Source: ftp://ftp.gnu.org/gnu/gettext/%{name}-%{tarversion}.tar.xz

Alright, I was going from the quoted text.

> The spec that Jerry James posted changed the URI scheme to https, which
> is the right thing to do. That change is now also in Git.

Sure, 100% agree.

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Please sweep bodhi updates to testing in a timely manner

[Kevin Fenzi]

On 8/10/19 11:33 AM, Philip Kovacs via devel wrote:
> Just look at the updates pending pages.  Here are f30 and f29, resp:
> https://bodhi.fedoraproject.org/updates/?releases=F30=pending
> https://bodhi.fedoraproject.org/updates/?releases=F29=pending

Updates are pushed every single day at 00:00UTC.

However, todays failed because there were some unsigned packages.
(This is caused by updates that stay in updates testing for a long time
and their signed copies get grabage collected).

I fixed that and finished the broken push, but I am at flock and didn't
have time to start a full push. One should fire off in about 3 hours...

There should never be an update that waits 7 days to push to testing...

kevin
--
>On Saturday, August 10, 2019, 02:29:24 PM EDT, Stephen John Smoogen 
>  wrote:  
>  
>  
> 
> On Sat, 10 Aug 2019 at 13:22, Philip Kovacs via devel 
>  wrote:
> 
> Why does it take days sometimes just to start the 7 day timer? 
> 
> Can we have some examples to track this down? Because without that.. no idea 
> and no way to fix.
>  
> ___
> 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
> 
> 
> 
> 
> ___
> 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
> 




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

Self Introduction: Ege Gunes

[Ege Gunes]

Hi,

I'm a software developer from Istanbul, Turkey. I want to include some of my 
open source projects to Fedora and I submitted my first package review[1].

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

--
Ege Gunes
https://ege.dev/publickey.txt
___
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

RFE: automatically enable rpmlint gating test for packages with a foo.rpmlintrc

[Hans de Goede]

Hi All,

So what I've been reading from the rawhide gating mailthread,
creating the gating rules unfortunately is somewhat convoluted /
involved.

As such I was wondering if maybe it is an idea to automatically
enabled the rpmlint gating test for packages which have a
.rpmlint rc. ?

Alternatively a wiki page with gating confif snippets, mirroring
how have a wiki page for specfile scriptlet snippets, might be a
good idea. I would like to opt in to test-gating where possible,
esp. with the rpmlint tests, but I do not have a lot of time to
spend on this. More in general I believe that the easier this
is made to use, the better chances are that people will actually
use this.

Regards,

Hans
___
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: Does anybody care about gettext?

[Björn Persson]

Kevin Fenzi wrote:
> On 8/10/19 4:12 AM, Björn Persson wrote:
> > Rafal Luzynski wrote:  
> >> 9.08.2019 22:10 Jerry James  wrote:  
> >>> Source: https://ftp.gnu.org/pub/gnu/gettext/%{name}-%{version}.tar.xz
> >>
> >> Do we need to change ftp to https?  
> > 
> > That's the wrong question to ask. The right question is: What reason is
> > there to choose an insecure protocol when HTTPS is available?  
> 
> I'm confused by this... https is already being used, it is just the
> hostname that is 'ftp'.

When I posted, gettext.spec in the master branch still said:

Source: ftp://ftp.gnu.org/gnu/gettext/%{name}-%{tarversion}.tar.xz

The spec that Jerry James posted changed the URI scheme to https, which
is the right thing to do. That change is now also in Git.

The URL field should also be changed by the way. www.gnu.org redirects
HTTP requests to HTTPS, but there is no reason to give an attacker the
chance to intercept the HTTP request and redirect you to a malicious
server instead.

Björn Persson


pgp0irXcPb2Xm.pgp
Description: OpenPGP digital signatur
___
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

[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem

[Richard Grainger]

> On 10 Aug 2019, at 20:23, Miro Hrončok  wrote:
> 
> While I really tried to do my best, it seems that I broke CentOS by retiring 
> python36. Should it be unretired? Or is it reasonable to say: Please wait for 
> CentOS 7.7?

This is why I believe we need a “CentOS-EPEL” repo that mirrors EPEL generally, 
but that is frozen in the period between a RHEL and CentOS release.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

[EPEL-devel] Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem

[Miro Hrončok]

While I really tried to do my best, it seems that I broke CentOS by retiring 
python36. Should it be unretired? Or is it reasonable to say: Please wait for 
CentOS 7.7?


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

Also after retiring python-rpm-macros, Koji doesn't seem to see the RHEL one. Is 
there any action to take?


https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/UKHD6IXORQ6RNNL4JZ67PGQHOMIBVUZZ/

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Re: Please sweep bodhi updates to testing in a timely manner

[Philip Kovacs via devel]

Just look at the updates pending pages.  Here are f30 and f29, resp:
https://bodhi.fedoraproject.org/updates/?releases=F30=pending
https://bodhi.fedoraproject.org/updates/?releases=F29=pending
   On Saturday, August 10, 2019, 02:29:24 PM EDT, Stephen John Smoogen 
 wrote:  
 
 

On Sat, 10 Aug 2019 at 13:22, Philip Kovacs via devel 
 wrote:

Why does it take days sometimes just to start the 7 day timer? 

Can we have some examples to track this down? Because without that.. no idea 
and no way to fix.
 
___
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



-- 
Stephen J Smoogen.

___
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
  ___
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: Please sweep bodhi updates to testing in a timely manner

[Stephen John Smoogen]

On Sat, 10 Aug 2019 at 13:22, Philip Kovacs via devel <
devel@lists.fedoraproject.org> wrote:

> Why does it take days sometimes just to start the 7 day timer?
>

Can we have some examples to track this down? Because without that.. no
idea and no way to fix.



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


-- 
Stephen J Smoogen.
___
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: [Xen-devel] Xen / EC2 release criteria proposal

[Dridi Boukelmoune]

Sorry for the top posting, "smart" phone...

What about Qubes OS? Isn't their dom0 using xen, based on Fedora?

Do they use Xen as packaged by Fedora? If not, couldn't they contribute
whatever they do that Fedora doesn't here?

It might be worth getting in touch with them. They look like a significant
Xen user, on Fedora.

Dridi

On Sat, Aug 10, 2019, 17:33 Adam Williamson 
wrote:

> On Sat, 2019-08-10 at 17:01 +0300, Matt Wilson wrote:
> > On Fri, Aug 09, 2019 at 05:56:11PM -0700, Adam Williamson wrote:
> > [...]
> > > So it seems like this would also be a good opportunity to revisit and
> > > nail down more specifically exactly what our cloud requirements are.
> > > bcotton suggested  that we require two sample instance types to be
> > > tested, c5.large (KVM) and t3.large (Xen). (I've also mailed Thomas
> > > Cameron, ex-of Red Hat, now of Amazon, for his opinion, as it seemed
> > > like it might be worthwhile - he's promised to get back to me).
> > >
> > > So, for now, let me propose this as a trial balloon: we rewrite the
> > > above criterion to say:
> > >
> > > "Release-blocking cloud disk images must be published to Amazon EC2 as
> > > AMIs, and these must boot successfully and meet other relevant release
> > > criteria on c5.large and t3.large instance types."
> >
> > Hi Adam,
> >
> > Thanks for bringing this up. It's good to revisit things from time to
> > time as the world changes.
>
> Thanks for the feedback, Matt!
>
> > Of the two instances that you propose, neither runs on Xen. The T2
> > instances run on Xen, but T3 uses the KVM-based Nitro hypervisor.
>
> That'll teach me to trust Ben...;)
>
> > To ensure that a Linux based AMI functions across all of the devices
> > and operating modes of EC2, you need to cover:
> >
> > x86 platforms
> > -
> > * Xen domU with only PV interfaces (e.g., M3 instances)
> > * Xen domU with Intel 82599 virtual functions for Enhanced Networking
> >   (e.g., C3 instances running in a VPC)
> > * Xen domU with Enhanced Networking Adapter (e.g., R4 instances)
> > * Xen domU with NVMe local instance storage (e.g., virtualized I3
> >   instances)
> > * Xen domU with more than 32 vCPUs (e.g., c4.8xlarge)
> > * Xen domU with four NUMA nodes (e.g., x1.32xlarge)
> > * Xen domU with maximum RAM available in EC2 (x1e.32xlarge)
> > * KVM guest with consistent performance (e.g., c5.large)
> > * KVM guest with burstable performance (e.g., t3.large)
> > * KVM guest with local NVMe storage (e.g., c5d.large)
> > * KVM guest with 100 Gbps networking and Elastic Fabric Adapter
> >   (c5n.18xlarge)
> > * KVM guest on AMD processors (e.g., m5a.large)
> > * KVM guest on AMD processors with maximum NUMA nodes (e.g.,
> >   m5a.24xlarge)
> > * Bare metal Broadwell (i3.metal)
> > * Bare metal Skylake (m5.metal)
> > * Bare metal Cascade Lake (c5.metal)
> >
> > Arm platforms
> > -
> > * KVM guest on Arm with 1 CPU cluster (a1.xlarge)
> > * KVM guest on Arm with 2 CPU clusters (a1.2xlarge)
> > * KVM guest on Arm with 4 CPU clusters (a1.4xlarge)
> >
> > Not all of these are going to cause an image to fail to boot up to the
> > point where a customer can SSH in. But a good number of these have
> > caused early boot problems in the past (e.g., >32 vCPUs on PVHVM Xen).
>
> Thanks a lot for the list, it's very helpful. It's also very long,
> though. :P Still, we can certainly use it as a base.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://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
>
___
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

Please sweep bodhi updates to testing in a timely manner

[Philip Kovacs via devel]

Why does it take days sometimes just to start the 7 day timer? ___
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: Better interactivity in low-memory situations

[Georg Sauthoff]

On Fri, Aug 09, 2019 at 03:50:43PM -0600, Chris Murphy wrote:
[..]
> Problem and thesis statement:
> Certain workloads, such as building webkitGTK from source, results in
> heavy swap usage eventually leading to the system becoming totally
> unresponsive. Look into switching from disk based swap, to swap on a
> ZRAM device.
> 
> Summary of findings (restated, but basically the same as found at [2]):
> Test system, Macbook Pro, Intel Core i7-2820QM (4/8 cores), 8GiB RAM,
> Samsung SSD 840 EVO, Fedora Rawhide Workstation.
> Test case, build WebKitGTK from source.
[..]

To avoid such issues I disable swap on my machines. I really don't see
the point of having a swap partition if you have 16 or 32 GiB RAM. Even
with 8 GiB I disable swap.

With - say - 8 GiB the build of a large project might fail (e.g. llvm,
e.g. during linking) but it then fails fast and I can just restart it
with `ninja -j2` or something like that.

Another source of IO related unresponsiveness is buffer bloat - I thus
apply this configuration on my machines:

$ cat /etc/sysctl.d/01-disk-bufferbloat.conf
vm.dirty_background_bytes=107374182
vm.dirty_bytes=214748364

Best regards
Georg
-- 
'Time your programs before making claims about efficiency'
  (Bjarne Stroustrup, The C++ Programming Language, 4th ed., p. 132, 2013)
___
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: Does anybody care about gettext?

[Nico Kadel-Garcia]

On Sat, Aug 10, 2019 at 12:48 PM Kevin Fenzi  wrote:
>
> On 8/10/19 4:12 AM, Björn Persson wrote:
> > Rafal Luzynski wrote:
> >> 9.08.2019 22:10 Jerry James  wrote:
> >>> Source: https://ftp.gnu.org/pub/gnu/gettext/%{name}-%{version}.tar.xz
> >>
> >> Do we need to change ftp to https?
> >
> > That's the wrong question to ask. The right question is: What reason is
> > there to choose an insecure protocol when HTTPS is available?
>
> I'm confused by this... https is already being used, it is just the
> hostname that is 'ftp'. So, I would see no reason to change this, but I
> suppose you could ask upstream to rename the host to avoid confusion...
>
> kevin

The site still supports FTP, which I suspect is why they use the same
name for both services. Check out ftp://ftp.gnu.org/pub/gnu/
___
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: Does anybody care about gettext?

[Kevin Fenzi]

On 8/10/19 4:12 AM, Björn Persson wrote:
> Rafal Luzynski wrote:
>> 9.08.2019 22:10 Jerry James  wrote:
>>> Source: https://ftp.gnu.org/pub/gnu/gettext/%{name}-%{version}.tar.xz  
>>
>> Do we need to change ftp to https?
> 
> That's the wrong question to ask. The right question is: What reason is
> there to choose an insecure protocol when HTTPS is available?

I'm confused by this... https is already being used, it is just the
hostname that is 'ftp'. So, I would see no reason to change this, but I
suppose you could ask upstream to rename the host to avoid confusion...

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Signing problem again in Rawhide?

[Kevin Fenzi]

On 8/10/19 2:20 AM, Richard W.M. Jones wrote:
> On Sat, Aug 10, 2019 at 10:09:50AM +0100, Richard W.M. Jones wrote:
>>
>> This package was built over 24 hours ago:
>>
>>   https://koji.fedoraproject.org/koji/buildinfo?buildID=1349103
>>
>> but it hasn't appeared in Rawhide yet.
> 
> It seems the problem may only apply to this package, as I've just
> built another package in Rawhide and that one was signed and available
> to build against in only a few minutes.
> 

Not sure what happened, but I have re-tagged it and it processed
correctly now.

kevin





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: [Xen-devel] Xen / EC2 release criteria proposal

[Adam Williamson]

On Sat, 2019-08-10 at 17:01 +0300, Matt Wilson wrote:
> On Fri, Aug 09, 2019 at 05:56:11PM -0700, Adam Williamson wrote:
> [...]
> > So it seems like this would also be a good opportunity to revisit and
> > nail down more specifically exactly what our cloud requirements are.
> > bcotton suggested  that we require two sample instance types to be
> > tested, c5.large (KVM) and t3.large (Xen). (I've also mailed Thomas
> > Cameron, ex-of Red Hat, now of Amazon, for his opinion, as it seemed
> > like it might be worthwhile - he's promised to get back to me).
> > 
> > So, for now, let me propose this as a trial balloon: we rewrite the
> > above criterion to say:
> > 
> > "Release-blocking cloud disk images must be published to Amazon EC2 as
> > AMIs, and these must boot successfully and meet other relevant release
> > criteria on c5.large and t3.large instance types."
> 
> Hi Adam,
> 
> Thanks for bringing this up. It's good to revisit things from time to
> time as the world changes.

Thanks for the feedback, Matt!

> Of the two instances that you propose, neither runs on Xen. The T2
> instances run on Xen, but T3 uses the KVM-based Nitro hypervisor.

That'll teach me to trust Ben...;)

> To ensure that a Linux based AMI functions across all of the devices
> and operating modes of EC2, you need to cover:
> 
> x86 platforms
> -
> * Xen domU with only PV interfaces (e.g., M3 instances)
> * Xen domU with Intel 82599 virtual functions for Enhanced Networking
>   (e.g., C3 instances running in a VPC)
> * Xen domU with Enhanced Networking Adapter (e.g., R4 instances)
> * Xen domU with NVMe local instance storage (e.g., virtualized I3
>   instances)
> * Xen domU with more than 32 vCPUs (e.g., c4.8xlarge)
> * Xen domU with four NUMA nodes (e.g., x1.32xlarge)
> * Xen domU with maximum RAM available in EC2 (x1e.32xlarge)
> * KVM guest with consistent performance (e.g., c5.large)
> * KVM guest with burstable performance (e.g., t3.large)
> * KVM guest with local NVMe storage (e.g., c5d.large)
> * KVM guest with 100 Gbps networking and Elastic Fabric Adapter
>   (c5n.18xlarge)
> * KVM guest on AMD processors (e.g., m5a.large)
> * KVM guest on AMD processors with maximum NUMA nodes (e.g.,
>   m5a.24xlarge)
> * Bare metal Broadwell (i3.metal)
> * Bare metal Skylake (m5.metal)
> * Bare metal Cascade Lake (c5.metal)
> 
> Arm platforms
> -
> * KVM guest on Arm with 1 CPU cluster (a1.xlarge)
> * KVM guest on Arm with 2 CPU clusters (a1.2xlarge)
> * KVM guest on Arm with 4 CPU clusters (a1.4xlarge)
> 
> Not all of these are going to cause an image to fail to boot up to the
> point where a customer can SSH in. But a good number of these have
> caused early boot problems in the past (e.g., >32 vCPUs on PVHVM Xen).

Thanks a lot for the list, it's very helpful. It's also very long,
though. :P Still, we can certainly use it as a base.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

[EPEL-devel] Re: Missing python-rpm-macros>3.30 on EPEL7 ppc64le

[Robert-André Mauchin]

The package are correctly retired, but the ones from RHEL are not available, 
which breaks building for EPEL7: 

https://kojipkgs.fedoraproject.org//work/tasks/9826/36909826/mock_output.log

Error: Package: epel-rpm-macros-7-20.noarch (build)
   Requires: python-srpm-macros
Error: Package: epel-rpm-macros-7-20.noarch (build)
   Requires: python2-rpm-macros
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
Error: Package: epel-rpm-macros-7-20.noarch (build)
   Requires: python-rpm-macros


Does something need to be one Koji side?

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Re: Xen / EC2 release criteria proposal

[W. Michael Petullo]

> "The release must boot successfully as Xen DomU with releases providing
> a functional, supported Xen Dom0 and widely used cloud providers
> utilizing Xen."

I am a long time Xen/Fedora user. In fact, I rely on Fedora as my Dom0. I
acknowledge that there are not too many of us, and I further acknowledge
that mandatory testing often goes unperformed. The Fedora Xen mailing
list is exceedingly low-volume.

Michael Young has in the past done a lot of the heavy lifting surrounding
Xen support, and I am very grateful for his work.

Xen Dom0 is particularly tenuous. Dropping (for a good reason) GRUB's
multiboot2 module left Xen unable to boot under EFI [e.g., 1].

All of that said, there are good reasons to choose Xen over KVM. Xen's
architecture and full support for libvmi come to mind. (Of course,
there are good reasons to choose KVM too.)

Perhaps we could go one more release with the status quo to give the
Xen/Fedora community a last chance to rally and demonstrate a willingness
to perform the necessary testing and maintenance. I suspect we are
all quite busy, so we might find ourselves admitting that broader Xen
support will be relegated to the standard means of maintenance rather
than rising to the status of blockers.

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

-- 
Mike

:wq
___
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: Modules in rawhide (that shouldn't be there)

[Igor Gnatenko]

You meant more like "rebuilding" modules rather than branching, right?

On Sat, Aug 10, 2019 at 3:09 PM Mohan Boddu  wrote:
>
> Hi all,
>
> There is a Mass Branching scheduled for next Tuesday, that is on Aug 13th 
> 2019. There were some modules that are stuck in rawhide that shouldn't be 
> there, please create a ticket in https://pagure.io/releng with the list of 
> module builds that shouldn't be there and we will remove them from rawhide 
> and will not be branched.
>
> Thanks,
> Mohan Boddu.
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://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-annou...@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://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: [HEADS-UP] dav1d and aom SONAME bump

[Dominik 'Rathann' Mierzejewski]

On Friday, 09 August 2019 at 17:40, Robert-André Mauchin wrote:
> Hello,
> 
> Next week I will update dav1d to version 0.4.0 which includes a SONAME bump, 
> and will do a GIT snapshot of aom, whose library is unstable.
> 
> I will push these updates both on F31 and F30, so consumers of these 
> libraries 
> (ffmpeg, xine-lib, vlc) will need to rebuild their packages on both release.

Why F30? Please don't push unstable stuff to released branches.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

Modules in rawhide (that shouldn't be there)

[Mohan Boddu]

Hi all,

There is a Mass Branching scheduled for next Tuesday, that is on Aug 13th
2019. There were some modules that are stuck in rawhide that shouldn't be
there, please create a ticket in https://pagure.io/releng with the list of
module builds that shouldn't be there and we will remove them from rawhide
and will not be branched.

Thanks,
Mohan Boddu.
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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-annou...@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://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

Modules in rawhide (that shouldn't be there)

[Mohan Boddu]

Hi all,

There is a Mass Branching scheduled for next Tuesday, that is on Aug 13th
2019. There were some modules that are stuck in rawhide that shouldn't be
there, please create a ticket in https://pagure.io/releng with the list of
module builds that shouldn't be there and we will remove them from rawhide
and will not be branched.

Thanks,
Mohan Boddu.
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org

Re: bootctl: no entry could be determined as default (Was: Upgrade to F30 gone wrong)

[Dridi Boukelmoune]

Hi,

> That only works properly on distros that implement the boot loader
> spec and the boot loader interface properly:
>
> https://systemd.io/BOOT_LOADER_SPECIFICATION
> https://systemd.io/BOOT_LOADER_INTERFACE

Thanks for the links, I looked briefly when you replied but figured
I'd need a quiet setup since this is unfamiliar territory. I have
finally read both documents, and they are very accessible even to
someone without prior knowledge.

> Unfortunately, Fedora/grub do not support either.
>
> (Which is a pity of course, since it also means there's no working
> "systemctl --boot-loader-entry=" support in Fedora, nor "sytemctl
> kexec" support).

I see. Do I understand from reading the specification that it was put
together during the Fedora 18 days? Do I understand from reading the
boot loader interface documented that systemd supported all this in
the f18 days too?

Thanks,
Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Does anybody care about gettext?

[Rafal Luzynski]

10.08.2019 13:12 Björn Persson  wrote:
> [...]
> Anyway, the answer is yes:
> 
> 220 GNU FTP server ready.
> USER anonymous
> 230-NOTICE (Updated October 13 2017):
> 230-
> 230-Because of security concerns with plaintext protocols, we still
> 230-intend to disable the FTP protocol for downloads on this server
> [...]

This answers the question, thanks.

Rafal
___
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: Does anybody care about gettext?

[Björn Persson]

Rafal Luzynski wrote:
> 9.08.2019 22:10 Jerry James  wrote:
> > Source: https://ftp.gnu.org/pub/gnu/gettext/%{name}-%{version}.tar.xz  
> 
> Do we need to change ftp to https?

That's the wrong question to ask. The right question is: What reason is
there to choose an insecure protocol when HTTPS is available?

Anyway, the answer is yes:

220 GNU FTP server ready.
USER anonymous
230-NOTICE (Updated October 13 2017):
230-
230-Because of security concerns with plaintext protocols, we still
230-intend to disable the FTP protocol for downloads on this server
230-(downloads would still be available over HTTP and HTTPS), but we
230-will not be doing it on November 1, 2017, as previously announced
230-here. We will be sharing our reasons and offering a chance to
230-comment on this issue soon; watch this space for details.
230-
230-If you maintain scripts used to access ftp.gnu.org over FTP,
230-we strongly encourage you to change them to use HTTPS instead.

Björn Persson


pgpwAji6ITSLs.pgp
Description: OpenPGP digital signatur
___
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

[EPEL-devel] Re: Missing python-rpm-macros>3.30 on EPEL7 ppc64le

[Miro Hrončok]

On 10. 08. 19 11:53, Antonio Trande wrote:

When will it happen?


I did that right after that e-mail:

https://src.fedoraproject.org/rpms/python-rpm-macros/c/b6f2fa0c7616565c964e5c72ecfddb6e712c2266?branch=epel7

If ti doesn't work, maybe some Koji admins need to do stuff?

Or it just takes a while?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Missing python-rpm-macros>3.30 on EPEL7 ppc64le

[Antonio Trande]

When will it happen?

On 09/08/19 15:39, Miro Hrončok wrote:
> 
> Will do. I was waiting for the release to happen.
> 

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



signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org

Re: Signing problem again in Rawhide?

[Richard W.M. Jones]

On Sat, Aug 10, 2019 at 10:09:50AM +0100, Richard W.M. Jones wrote:
> 
> This package was built over 24 hours ago:
> 
>   https://koji.fedoraproject.org/koji/buildinfo?buildID=1349103
> 
> but it hasn't appeared in Rawhide yet.

It seems the problem may only apply to this package, as I've just
built another package in Rawhide and that one was signed and available
to build against in only a few minutes.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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: Discussion around app retirements and categorizations by the CPE team

[Dridi Boukelmoune]

On Wed, Jul 31, 2019 at 7:17 AM Pierre-Yves Chibon  wrote:
>
> On Tue, Jul 30, 2019 at 01:13:50PM -0400, Tim Zabel wrote:
> >Hello,
> >I'm a little late to this conversation, but is fpaste in Category 4 due 
> > to
> >the high legal costs, or because of a lack of a maintainer?
> >It would be sad to see fpaste go away because of legal reasons. Is there 
> > a
> >better way to handle this?
>
> Basically both, it has a very high legal cost and the software we use is not
> maintained and hasn't been for a while. Finding a new pastebin that works, 
> means
> investigating the ecosystem, figuring out which one fits best our needs, 
> getting
> it deployed, monitoring the project for security issues and alike.
> All this considered, CPE feels that spending time on fpaste isn't the best use
> of its time, especially considering the number of nicer pastebins out there.

Hi,

For a pastebin replacement I can point you to my colleague's filebin
[1] project that is our $DAYJOB dogfood. It's written in Go and might
need work to be included in Fedora. I can only promise to help as an
ambassador to make sure any request or contribution from Fedora gets
attention.

Dridi

[1] https://github.com/espebra/filebin/
___
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

Signing problem again in Rawhide?

[Richard W.M. Jones]

This package was built over 24 hours ago:

  https://koji.fedoraproject.org/koji/buildinfo?buildID=1349103

but it hasn't appeared in Rawhide yet.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
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: Better interactivity in low-memory situations

[Jan Kratochvil]

On Fri, 09 Aug 2019 23:50:43 +0200, Chris Murphy wrote:
> $ cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja

RelWithDebInfo is -O2 -g build.  That is not suitable for debugging, for
debugging you should use -DCMAKE_BUILD_TYPE=Debug (that is -g).
RelWithDebInfo is useful for final rpm packages but those are build in Koji.

Debug build will have smaller debug info so the problem may go away.

If it does not go away then tune the parallelism. Low -j makes the build
needlessly slow during compilation phase while high -j (up to about #cpus
+ 2 or so) will make the final linking phase with debug info to run out of
memory. This is why LLVM has separate "-j" for the linking phase but that is
implemented only in LLVM CMakeLists.txt files:
https://llvm.org/docs/CMake.html
LLVM_PARALLEL_LINK_JOBS
So that you leave the default -j high but set LLVM_PARALLEL_LINK_JOBS to 1 or 2.

Other options for faster build times are also LLVM specific:
-DLLVM_USE_LINKER=gold (maybe also lld now?)
 - as ld.gold or ld.lld are faster than ld.bfd
-DLLVM_USE_SPLIT_DWARF=ON
 - Linking phase no longer deals with the huge debug info

Which should be applicable for other projects by something like (untested!):
-DCMAKE_C_FLAGS="-gsplit-dwarf"
-DCMAKE_CXX_FLAGS="-gsplit-dwarf"
-DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=gold -Wl,--gdb-index"
-DCMAKE_SHARED_LINKER_FLAGS="-fuse-ld=gold -Wl,--gdb-index"

(That gdb-index is useful if you are really going to debug it using GDB as
I expect you are going to do when you want RelWithDebInfo and not Release; but
then I would recommend Debug in such case anyway as debugging optimized code
is very difficult.)


> is there a practical way right now of enforcing CPU
> and memory limits on unprivileged applications?

$ help ulimit
  -mthe maximum resident set size
  -uthe maximum number of user processes
  -vthe size of virtual memory

One can also run it with 'nice -n19', 'ionice -c3'
and/or "cgclassify -g '*':hammock" (config attached).

But after all I recommend just more memory, it is cheap nowadays and I find
64GB just about the right size.


Jan
mount {
cpu = /cgroup/cpu;
memory  = /cgroup/memory;
blkio   = /cgroup/blkio;
}

group hammock {
perm {
task {
uid = jkratoch;
gid = jkratoch;
}
admin {
uid = jkratoch;
gid = jkratoch;
}
}
cpu {
cpu.shares = 2;
}
memory {
memory.limit_in_bytes = 2G;
}
blkio {
blkio.weight = 100;
}
}
___
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: Orphaning some packages

[Elliott Sales de Andrade]

Hi Pierre,

On Sat, 3 Aug 2019 at 14:35, Pierre-Yves Chibon  wrote:
>
> Good Morning Everyone,
>
> I think it's time I make amends and recognize that I've been a terrible
> maintainer for a number of my packages.
> So I'd like to orphan the following packages hoping they can find a better 
> home.
>
> I no longer use R, so all of my R libraries:
> rpms/R-affy
> rpms/R-affydata
> rpms/R-affyio
> rpms/R-ALL
> rpms/R-AnnotationDbi
> rpms/R-Biobase
> rpms/R-BiocGenerics
> rpms/R-Biostrings
> rpms/R-BSgenome
> rpms/R-BSgenome.Celegans.UCSC.ce2
> rpms/R-BufferedMatrix
> rpms/R-BufferedMatrixMethods
> rpms/R-caTools
> rpms/R-DynDoc
> rpms/R-fibroEset
> rpms/R-GenomicFeatures
> rpms/R-GenomicRanges
> rpms/R-hgu133acdf
> rpms/R-hgu95av2cdf
> rpms/R-hgu95av2probe
> rpms/R-IRanges
> rpms/rkward
> rpms/R-maanova
> rpms/R-multtest
> rpms/R-pls
> rpms/R-preprocessCore
> rpms/R-qvalue
> rpms/R-rlecuyer
> rpms/R-ROC
> rpms/R-RUnit
> rpms/R-sandwich
> rpms/R-statmod
> rpms/R-timeDate
> rpms/R-tkWidgets
> rpms/R-widgetTools
> rpms/R-XML
> rpms/R-xtable
>

I can take R-caTools, R-RUnit, R-timeDate, R-XML, and R-xtable.

And while I have your attention, I'd like to ask about maintaining
R2spec, which has several open PRs but has not been touched for ages.

> rpms/trac-mastertickets-plugin
>No longer used in infra
>
> rpms/libdivecomputer
> rpms/subsurface
>   Upstream (of the later) does a lot of bundling and I've had a hard time
>   keeping up with it. I think this one may be more suitable for a flatpack 
> tbh.
>   libdivecomputer is a dependency of subsurface.
>
> rpms/igraph
> rpms/python-igraph
>   I picked these two when I was looking at graph libraries but I've never done
>   anything with them
>
> rpms/python-rdfextras
>   I took over this one but I'm not using it anywhere and not keeping up with
>   upstream
>
>
> Let me know if you are interested in any of them and I'll give them to you.
> Otherwise I'll likely orphan them when I can back from flock.
>
>
>
> Best,
> Pierre

-- 
Elliott
___
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: Xen / EC2 release criteria proposal

[Laura Abbott]

On 8/10/19 2:56 AM, Adam Williamson wrote:

Hey folks! I'm starting a new thread for this to trim the recipient
list a bit and include devel@ and coreos@.

The Story So Far: there is a Fedora release criterion which requires
Fedora to boot on Xen:

"The release must boot successfully as Xen DomU with releases providing
a functional, supported Xen Dom0 and widely used cloud providers
utilizing Xen."

We (QA group) had a discussion about removing this criterion entirely.
That has now morphed into the idea that we should tweak it to be
focused exclusively on the "widely used cloud providers utilizing
Xen"...by which we mean EC2. At the time this criterion was invented,
all EC2 instance types used Xen; now, some still use Xen, and some use
KVM.

So it seems like this would also be a good opportunity to revisit and
nail down more specifically exactly what our cloud requirements are.
bcotton suggested  that we require two sample instance types to be
tested, c5.large (KVM) and t3.large (Xen). (I've also mailed Thomas
Cameron, ex-of Red Hat, now of Amazon, for his opinion, as it seemed
like it might be worthwhile - he's promised to get back to me).

So, for now, let me propose this as a trial balloon: we rewrite the
above criterion to say:

"Release-blocking cloud disk images must be published to Amazon EC2 as
AMIs, and these must boot successfully and meet other relevant release
criteria on c5.large and t3.large instance types."

Notes:

1. The test matrix template has an Openstack column, but we never
actually covered Openstack in the release criteria. I think we should
continue to leave it out of the criteria and also remove the column
from the matrix. In the past we tested Openstack boot in the infra
Openstack, but that has gone away or is going away...that means a) we
can't test on Openstack so easily any more and b) a lot of the reason
to bother testing on Openstack is gone. This is up for debate, but if
we believe it's important to test on Openstack and block on working in
that environment we need to have a reliable way to *do* that.

2. The test matrix template also has a 'Local' column which is for
testing locally with testcloud, but I don't think we need to
specifically require that to work in the criteria. It's more of a
testing convenience thing, so even if no-one tests on EC2 we at least
test that the image boots in testcloud; testcloud isn't an environment
you'd actually use to do anything practical in.

3. I believe this wording is generic enough to cover us if we, e.g.,
want to start blocking on CoreOS images. All we have to do is declare
that some CoreOS image is 'release-blocking', and it's instantly
covered by this requirement.


I'm in favor of this. We've had problems getting engagement and bug
fixing for Xen in the Fedora kernel. Narrowing the scope to particular
Xen instances will make this easier to debug and probably less likely
to break.

Thanks,
Laura

P.S. For those who might be interested in keeping this working in
the kernel, testing is good but bisecting and identifying fixes
to bring in is much more valuable simply because it's what's missing
at the moment.
___
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: Xen / EC2 release criteria proposal

[Adam Williamson]

On Sat, 2019-08-10 at 00:53 -0400, Nico Kadel-Garcia wrote:
> On Fri, Aug 9, 2019 at 8:57 PM Adam Williamson
>  wrote:
> > Hey folks! I'm starting a new thread for this to trim the recipient
> > list a bit and include devel@ and coreos@.
> > 
> > The Story So Far: there is a Fedora release criterion which requires
> > Fedora to boot on Xen:
> > 
> > "The release must boot successfully as Xen DomU with releases providing
> > a functional, supported Xen Dom0 and widely used cloud providers
> > utilizing Xen."
> 
> How difficult is this to accomodate?

So there's two factors behind the idea of dropping support for
straight-up Xen domU support:

1. It just doesn't get tested. It's been in the criteria for years and
we've had various promises from various folks to test it, but...it just
doesn't happen. Each cycle we end up scrambling to have someone test it
in a hurry a week before release. Once again after we sent out this
proposal people have promised to test it, but...honestly, after the
last two go-rounds I'm finding it harder to believe in that.

2. What's the justification for it? Xen isn't our supported virt stack,
that's KVM. It is also just not that popularly used by Fedora users in
my experience. People ask about running Fedora on VMware, VirtualBox
and Parallels a lot, and we don't block on those. Xen doesn't often
come up, yet we block on it.

> Amaxon Dom0... well, they've got
> their own developers tweaking their own kernel, both for their
> hypervisors and for Amazon Linux, and they do seem to absorb leding
> edge kernel technologies. It's the rest of us, using the other
> technologies such as Xen, from the CentOS community, KVM from the Red
> Hat commercial community, Virtualbox and VMWAre guests, that I think
> are more likely to run into difficulties.

KVM we already block on, as it's Fedora's supported virt stack. And
yeah, we've never blocked on VirtualBox or VMWare even though they're
widely used. So just blocking on Xen seems a little arbitrary.

> > We (QA group) had a discussion about removing this criterion entirely.
> > That has now morphed into the idea that we should tweak it to be
> > focused exclusively on the "widely used cloud providers utilizing
> > Xen"...by which we mean EC2. At the time this criterion was invented,
> > all EC2 instance types used Xen; now, some still use Xen, and some use
> > KVM.
> 
> Commercially, and for developers, they're all still in use. As a
> DevOps person, I can appreciate that testing resources are limited.
> 
> > So it seems like this would also be a good opportunity to revisit and
> > nail down more specifically exactly what our cloud requirements are.
> > bcotton suggested  that we require two sample instance types to be
> > tested, c5.large (KVM) and t3.large (Xen). (I've also mailed Thomas
> > Cameron, ex-of Red Hat, now of Amazon, for his opinion, as it seemed
> > like it might be worthwhile - he's promised to get back to me).
> 
> The *tiny* instances are still often used for test environments.

Sure, but we can't practically commit to testing every instance type
(there's a ton). The aim is, pick a reasonable sample that will give us
pretty good confidence that the others will work too. If 'large' works,
is 'tiny' likely to not work? And vice versa? This is definitely
something we still need to nail down, the types suggested so far are
just bcotton's proposal. Perhaps it would make sense to go for smaller
types rather than larger ones, as you can envisage a scenario where the
larger types are fine but smaller ones have issues due to resource
problems or something...of course, we shouldn't pick a type with fewer
hardware resources than we actually intend to support...

Thanks for the feedback!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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