Re: Xen / EC2 release criteria proposal

[Nico Kadel-Garcia]

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

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

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

As a Fedora user, and a cloud user, this makes complete sense. It gets
very expensive in money and manpower to test *)everything*, especialy
if you're at the bleeding edge of software development. Well defined
test criteria are our friend.

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

[Chris Murphy]

Just in case anyone wants to try to reproduce this particular example:

1. Grab latest stable from here and untar it
https://webkitgtk.org/releases/
2. Run this included script, which is dnf aware, to install dependencies
./Tools/gtk/install-dependencies
3. Additional packages I had to install to get it to build
sudo dnf install ruby-devel openjpeg2-devel woff2-devel
___
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-10 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/08/10/report-389-ds-base-1.4.1.6-20190809git21ba842.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

[Test-Announce] Proposal to CANCEL: 2019-08-12 Fedora QA and blocker review meetings

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA and blocker review meetings
on Monday. We do actually have stuff for both meetings, but Flock ends
Sunday so I'm expecting a lot of people will be busy
traveling/recovering on Monday, so it seems best to wait until next
week.

If you're aware of anything important we have to discuss this week,
please do reply to this mail and we can go ahead and run the meeting.

Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-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

Xen / EC2 release criteria proposal

[Adam Williamson]

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

Re: Does anybody care about gettext?

[Rafal Luzynski]

9.08.2019 22:10 Jerry James  wrote:
> On Fri, Aug 9, 2019 at 2:12 AM Alexander Ploumistos
>  wrote:
> > All the patches we carried were merged back in the latest upstream
> > version (0.20.1), but when I took a stab at it, I got a lot of errors
> > about the variable types and I did not know how to proceed.

I tried this as well and stumbled upon this bug:
https://savannah.gnu.org/bugs/?55356

> Alexander, try the attached spec file.  It leads to a successful build
> for me.  (Sorry for doing this in email, but I'm currently in a place
> where I can't make git pull requests.)  It may need a little tweaking
> still, and feel free to trim my verbose changelog entry if you decide
> to use any part of it. :-)

I am not Alexander but since I've already started working on this
I think I can take a look. Your spec file looks mostly good. I have
some doubts which may be completely wrong (I have never looked at the
internals of gettext before) but just in case here we go:

> %bcond_with jar
> %bcond_with java
> 

Before Jens' commit there was also a line:

%bcond_without check

If you remove it you enable the check phase unconditionally.

> [...]
> License: GPLv3+ and LGPLv2+ and GFDL

GFDL is a new thing here, I guess the public announce of the license
change will be needed.

> Source: https://ftp.gnu.org/pub/gnu/gettext/%{name}-%{version}.tar.xz

Do we need to change ftp to https?

> # ensure 'ARCHIVE_FORMAT=dirxz'
> BuildRequires: xz

"BuildRequires: chrpath" removed here, really no longer needed?

> # for documentation
> BuildRequires: texlive-dvips
> BuildRequires: texinfo-tex

It worked for me without these packages although the results
might have been different due of that.

> BuildRequires: libacl-devel

Same here.

> # for the tests
> BuildRequires: glibc-langpack-de
> BuildRequires: glibc-langpack-en
> BuildRequires: glibc-langpack-fa
> BuildRequires: glibc-langpack-fr
> BuildRequires: glibc-langpack-ja
> BuildRequires: glibc-langpack-tr
> BuildRequires: glibc-langpack-zh

Good point.

> %package devel
> Summary: Development files for %{name}
> # autopoint is GPLv3+
> # libasprintf is LGPLv2+
> # libgettextpo is GPLv3+
> License: LGPLv2+ and GPLv3+ and GFDL

A comment why GFDL has been added here would be helpful.
Maybe it is not needed here?

> %package -n libtextstyle
> Summary: Text styling library
> License: GPLv3+
> [...]

Looks great. Are the licenses correct?

> # Eliminate hardcoded rpaths; workaround libtool reordering
> -Wl,--as-needed
> # after all the libraries.
> sed -e 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' \
> -e 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' \
> -e 's|CC=.g..|& -Wl,--as-needed|' \
> -i $(find . -name libtool)

Is this the reason why chrpath is no longer needed?

> %check
> # this takes quite a lot of time to run

Previously the %check was conditional (with "%if %{with check}").
See also my comment on top.

> %{_bindir}/envsubst
> %{_bindir}/gettext
> %{_bindir}/gettext.sh
> %{_bindir}/msgattrib
> %{_bindir}/msgcat
> %{_bindir}/msgcmp
> %{_bindir}/msgcomm
> %{_bindir}/msgconv
> %{_bindir}/msgen
> %{_bindir}/msgexec
> %{_bindir}/msgfilter
> %{_bindir}/msgfmt
> %{_bindir}/msggrep
> %{_bindir}/msginit
> %{_bindir}/msgmerge
> %{_bindir}/msgunfmt
> %{_bindir}/msguniq
> %{_bindir}/ngettext
> %{_bindir}/recode-sr-latin
> %{_bindir}/xgettext

Is it OK to list all these files explicitly?

> %files -n libtextstyle-devel
> %{_docdir}/libtextstyle/

In other subpackages the documentation (also in HTML format)
is moved to a directory htmldoc (although I am not sure why).

> %changelog
> * Fri Aug  9 2019 Jerry James  - 0.20.1-1
> - update to 0.20.1 release, all patches upstreamed

It would be nice to mention the bug report rhbz#1708013.

Also see this comment which suggests adding an upstream patch:
https://bugzilla.redhat.com/show_bug.cgi?id=1708013#c2

Regards,

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?

[Sundeep Anand]

On Sat, Aug 10, 2019 at 1:42 AM Jerry James  wrote:

> On Fri, Aug 9, 2019 at 2:12 AM Alexander Ploumistos
>  wrote:
> > All the patches we carried were merged back in the latest upstream
> > version (0.20.1), but when I took a stab at it, I got a lot of errors
> > about the variable types and I did not know how to proceed.
>

Not sure, quick (however, may be, improper) work-around could be fixing
formatting as
fprintf (a_fp, "%s", str)  in  libtextstyle/lib/libcroco/cr-statement.c


>
> Alexander, try the attached spec file.  It leads to a successful build
> for me.  (Sorry for doing this in email, but I'm currently in a place
> where I can't make git pull requests.)  It may need a little tweaking
> still, and feel free to trim my verbose changelog entry if you decide
> to use any part of it. :-)
>
>
Thanks Jerry, I tried building it:
https://koji.fedoraproject.org/koji/taskinfo?taskID=36892738
https://koji.fedoraproject.org/koji/taskinfo?taskID=36893268
https://koji.fedoraproject.org/koji/taskinfo?taskID=36893460

By this time *BuildRequires* looks like:
...
BuildRequires: teckit
BuildRequires: texlive-dvips
BuildRequires: texlive-dvipdfmx
BuildRequires: texinfo-tex
BuildRequires: texlive-xetex
...
Is teckit required? (perhaps teckit could not build from source:
https://src.fedoraproject.org/rpms/teckit/tree/master) Or am I missing
something?

thanks,
sundeep


> Regards,
> --
> Jerry James
> http://www.jamezone.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: Does anybody care about gettext?

[Alexander Ploumistos]

On Fri, Aug 9, 2019 at 11:13 PM Jerry James  wrote:
>
> On Fri, Aug 9, 2019 at 2:12 AM Alexander Ploumistos
>  wrote:
> > All the patches we carried were merged back in the latest upstream
> > version (0.20.1), but when I took a stab at it, I got a lot of errors
> > about the variable types and I did not know how to proceed.
>
> Alexander, try the attached spec file.  It leads to a successful build
> for me.  (Sorry for doing this in email, but I'm currently in a place
> where I can't make git pull requests.)  It may need a little tweaking
> still, and feel free to trim my verbose changelog entry if you decide
> to use any part of it. :-)

Wow, thank you so much Jerry!
This should be really helpful for the gettext maintainers as well.

Best regards,
Alex
___
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

[Omair Majid]

Hi,

Chris Murphy  writes:

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

It sounds like the same issue that has been in the news recently:

- https://www.phoronix.com/scan.php?page=news_item=Linux-Does-Bad-Low-RAM
- https://news.ycombinator.com/item?id=20620545

Older sources with more information:

- https://lwn.net/Articles/759658/
- 
https://superuser.com/questions/1115983/prevent-system-freeze-unresponsiveness-due-to-swapping-run-away-memory-usage

(I learned about this bug the hard way; my machine experienced this bug
in the middle of a public presentation a few years ago.)

Regards,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
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: Disappearing mouse pointer

[Chris Murphy]

On Fri, Aug 9, 2019 at 2:07 PM Jerry James  wrote:
>
> On Thu, Aug 8, 2019 at 2:08 PM Antonio M  wrote:
> > confirmed that running on 5.1.20-300 this issue is not present
>
> Same here.  It does seem to be the 5.2 kernel that triggered this
> behavior.  I also managed to reproduce it once today without
> virt-manager running, so maybe VMs have nothing to do with it.
> Interacting with them seems to be the easiest way to trigger the
> behavior, though.

I also experienced it today, no VM's running, no virt-manager running.
Just gnome-shell. I briefly had it consistently disappearing upon
pressing the super key (show activities), and then it would reappear
upon pressing super again (hide activities). And then I went to a
different computer with ssh into the one experiencing the problem, to
look at logs, but there were no messages at all in the journal for
this time frame (no kernel or shell message or anything at all). And
then just as inexplicably, the problem stopped, mouse pointer was
visible with activities showing and hidden.

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

Better interactivity in low-memory situations

[Chris Murphy]

This subject matches a Fedora Workstation Working Group issue of the
same name [1], and this post is intended to be an independent summary
of the findings so far, and call for additional testing and
discussion, in particular subject matter experts.

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.

$ cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja
$ ninja

Case 1: 8GiB swap on SSD plain partition (not encrypted, not on LVM)
Case 2: 8GiB swap on /dev/zram0

In each case, that swap is exclusive, there are no other swap devices.
Within ~30 minutes in the first case, and ~10 minutes in the second
case, the GUI is completely unresponsive, mouse pointer has frozen and
doesn't recover after more than 30 minutes of waiting. By remote ssh,
the first case is semi-responsive, updates should be every 5 seconds
but are instead received every 2-5 minutes but it wasn't possible to
compel recovery by cancelling the build process after another 30
minutes. By remote ssh, the second case is totally unresponsive, no
updates for 30 minutes.

The system was manually forced power off at that point, in both cases.
oom killer never triggered.

NOTE: ninja, by default on this system, sets N concurrent jobs to
nrcpus + 2, which is 10 on this system. If I reboot with nr_cpus=4,
ninja sets N jobs to 6.

Case 3: 2GiB swap on /dev/zram0
In one test this resulted in system hang (no pointer movement) within
5 minutes of executing ninja, and within another 6 minutes oom killer
is invoked on a cc1plus process, which is fatal to the build process,
remaining build related processes quit on their own, and the system
eventually recovers.

But in two subsequent tests in this same configuration, oom killer
wasn't invoked, and the system meandered between responsive for ~1
minute, totally frozen for 5-6 minutes, in a cycle lasting beyond 1
hour without ever triggering oom killer.

Screenshot taken during one of the moments the remote ssh session updated
https://drive.google.com/open?id=1IDboR1fzP4onu_tzyZxsx7M5cT_RJ7Iz

The state had not changed after 45 minutes following the above
screenshot so I forced power off on that system. But the point here is
this slightly different configuration has some non-determinism to it,
even though in the end it's a bad UX. The default, unprivileged build
command is effectively taking down the system all the same.

Case 4: 8GiB swap on SSD plain partition, `ninja -j 4`
This is the same setup as Case 1, except I manually set N jobs to 4.
Build succeeds, and except for a few mouse pointer stutters, the
system remains responsive, even Firefox with multiple tabs open, and
youtube video playing. Exactly the experience we'd like to see, albeit
not all CPU resources are used for the build, but clearly the limiting
factor is this particular package requires more than ~14GiB to build
successfully, and the system + shell + Firefox, just doesn't have
that.

Starter questions:
To what degree, and why, is this problem instigated by the build
application (ninja in this example) or its supporting configuration
files, including cmake? Or the kernel? Or the system configuration? Is
it a straightforward problem, or is this actually somewhat nuanced
with multiple components in suboptimal configuration coming together
as the cause? Is it expected that an unprivileged user can run a
command whose defaults eventually lead to a totally unrecoverable
system? From a security risk standpoint, the blame can't be entirely
on the user or the application configuration, but how should
application containment be enforced? Other than containerizing the
build programs, is there a practical way right now of enforcing CPU
and memory limits on unprivileged applications? Other alternatives? At
the very least it seems like getting to an oom killer sooner would
result in a better experience, fail the process before the GUI becomes
unresponsive and hangs out for 30+minutes (possibly many hours).

[1]
https://pagure.io/fedora-workstation/issue/98
[2]
https://pagure.io/fedora-workstation/issue/98#comment-588713

Thanks,

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

[Jerry James]

On Fri, Aug 9, 2019 at 2:12 AM Alexander Ploumistos
 wrote:
> All the patches we carried were merged back in the latest upstream
> version (0.20.1), but when I took a stab at it, I got a lot of errors
> about the variable types and I did not know how to proceed.

Alexander, try the attached spec file.  It leads to a successful build
for me.  (Sorry for doing this in email, but I'm currently in a place
where I can't make git pull requests.)  It may need a little tweaking
still, and feel free to trim my verbose changelog entry if you decide
to use any part of it. :-)

Regards,
-- 
Jerry James
http://www.jamezone.org/
%bcond_with jar
%bcond_with java

%global tarversion 0.20.1
%global archiveversion 0.20

Summary: GNU libraries and utilities for producing multi-lingual messages
Name: gettext
Version: %{tarversion}
Release: 1%{?dist}
# The following are licensed under LGPLv2+:
# - libintl and its headers
# - libasprintf and its headers
# - libintl.jar
# - GNU.Gettext.dll
# - gettext.sh
# The following are licensed under GFDL:
# - gettext-tools/doc/FAQ.html
# - gettext-tools/doc/tutorial.html
# - gettext info files
# - libasprintf info files
# - libtextstyle info files
# Everything else is GPLv3+
License: GPLv3+ and LGPLv2+ and GFDL
URL: http://www.gnu.org/software/gettext/
Source: https://ftp.gnu.org/pub/gnu/gettext/%{name}-%{version}.tar.xz
Source2: msghack.py
Source3: msghack.1

# for bootstrapping
# BuildRequires: autoconf >= 2.62
# BuildRequires: automake
# BuildRequires: libtool
# BuildRequires: bison

BuildRequires: gcc-c++
%if %{with java}
# libintl.jar requires gcj >= 4.3 to build
BuildRequires: gcc-java, libgcj
# For javadoc
BuildRequires: java-1.6.0-openjdk-devel
%if %{with jar}
BuildRequires: %{_bindir}/fastjar
# require zip and unzip for brp-java-repack-jars
BuildRequires: zip, unzip
%endif
%endif
# for po-mode.el
BuildRequires: emacs
# for autosetup
BuildRequires: git
# ensure 'ARCHIVE_FORMAT=dirxz'
BuildRequires: xz
# for documentation
BuildRequires: texlive-dvips
BuildRequires: texinfo-tex
# following suggested by DEPENDENCIES:
BuildRequires: ncurses-devel
BuildRequires: libxml2-devel
BuildRequires: glib2-devel
BuildRequires: libacl-devel
BuildRequires: libcroco-devel
BuildRequires: libunistring-devel
# for the tests
BuildRequires: glibc-langpack-de
BuildRequires: glibc-langpack-en
BuildRequires: glibc-langpack-fa
BuildRequires: glibc-langpack-fr
BuildRequires: glibc-langpack-ja
BuildRequires: glibc-langpack-tr
BuildRequires: glibc-langpack-zh
# Depend on the exact version of the library sub package
Requires: %{name}-libs%{_isa} = %{version}-%{release}
# exception for bundled gnulib copylib
Provides: bundled(gnulib)

%description
The GNU gettext package provides a set of tools and documentation for
producing multi-lingual messages in programs. Tools include a set of
conventions about how programs should be written to support message
catalogs, a directory and file naming organization for the message
catalogs, a runtime library which supports the retrieval of translated
messages, and stand-alone programs for handling the translatable and
the already translated strings. Gettext provides an easy to use
library and tools for creating, using, and modifying natural language
catalogs and is a powerful and simple method for internationalizing
programs.


%package common-devel
Summary: Common development files for %{name}
# autopoint archive
License: GPLv3+
BuildArch: noarch

%description common-devel
This package contains common architecture independent gettext development files.


%package devel
Summary: Development files for %{name}
# autopoint is GPLv3+
# libasprintf is LGPLv2+
# libgettextpo is GPLv3+
License: LGPLv2+ and GPLv3+ and GFDL
Requires: %{name} = %{version}-%{release}
Requires: %{name}-libs = %{version}-%{release}
Requires: %{name}-common-devel = %{version}-%{release}
Requires: xz
Obsoletes: gettext-autopoint < 0.18.1.1-3
Provides: gettext-autopoint = %{version}-%{release}

%description devel
This package contains all development related files necessary for
developing or compiling applications/libraries that needs
internationalization capability. You also need this package if you
want to add gettext support for your project.


%package libs
Summary: Libraries for %{name}
# libasprintf is LGPLv2+
# libgettextpo is GPLv3+
License: LGPLv2+ and GPLv3+

%description libs
This package contains libraries used internationalization support.


%package -n libtextstyle
Summary: Text styling library
License: GPLv3+

%description -n libtextstyle
Library for producing styled text to be displayed in a terminal
emulator.


%package -n libtextstyle-devel
Summary: Development files for libtextstyle
License: GPLv3+ and GFDL
Requires: libtextstyle%{?_isa} = %{version}-%{release}

%description -n libtextstyle-devel
This package contains all development related files necessary for
developing or compiling applications/libraries that needs text
styling.


%package -n emacs-%{name}
Summary: Support for editing po 

Re: Disappearing mouse pointer

[Jerry James]

On Thu, Aug 8, 2019 at 2:08 PM Antonio M  wrote:
> confirmed that running on 5.1.20-300 this issue is not present

Same here.  It does seem to be the 5.2 kernel that triggered this
behavior.  I also managed to reproduce it once today without
virt-manager running, so maybe VMs have nothing to do with it.
Interacting with them seems to be the easiest way to trigger the
behavior, though.
-- 
Jerry James
http://www.jamezone.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: [Bug 1675390] mingw-wine-gecko: FTBFS in Fedora rawhide/f30

[Miro Hrončok]

On 09. 08. 19 21:10, Michael Cronenworth wrote:

On 8/9/19 11:02 AM, Miro Hrončok wrote:

The FTBFS bug was set to ASSIGNED yet your script retired it.


Correct. It was still failing to build.


I misinterpreted the "retire if still failing to build". This is new and 
unexpected.


It is not that new, it just didn't happen for several years because nobody did 
it.

It is not reasonable to place a hard timeline on a single person for 
a huge package such as wine gecko.


What would you want to do instead? Keep shipping th Fedora 26 package forever?
Is there nobody who is interested in winde and could help?

Wine users need this package to prevent Wine from downloading Gecko from the 
Internet.


The reasons for the FTBFS have been stated in the bug.

While I would love to fix every FTBFS issue overnight sometimes it just 
doesn't work that way.


Overnight? The latest build is from 2016-11-24. 


Here's the latest update on it, which I will also append to the bug report.

https://www.winehq.org/pipermail/wine-devel/2019-August/149411.html


Thanks.

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

[Michael Cronenworth]

On 8/9/19 11:02 AM, Miro Hrončok wrote:

The FTBFS bug was set to ASSIGNED yet your script retired it.


Correct. It was still failing to build.


I misinterpreted the "retire if still failing to build". This is new and unexpected. 
It is not reasonable to place a hard timeline on a single person for a huge package 
such as wine gecko.




Wine users need this package to prevent Wine from downloading Gecko from the 
Internet.


The reasons for the FTBFS have been stated in the bug.

While I would love to fix every FTBFS issue overnight sometimes it just doesn't 
work that way.


Overnight? The latest build is from 2016-11-24. 


Here's the latest update on it, which I will also append to the bug report.

https://www.winehq.org/pipermail/wine-devel/2019-August/149411.html
___
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?

[Stephen John Smoogen]

On Fri, 9 Aug 2019 at 14:08, Michael Cronenworth  wrote:

> On 8/9/19 8:50 AM, Miro Hrončok wrote:
> > Because if we don't, people just gonna ignore FTBFS forever.
> >
> > Could we have known that gettext will be unretired right away anyway?
> Probably
> > yes, but nobody got time / energy / resources to do any kind of analysis
> of the
> > FTBFS packages.
> >
> > Next time, I hope that FTBFS bugs for critical component are actually
> actively
> > solved sooner than the retirement happens. We can try to be more
> aggressive with
> > the reminders, but I don't know if that helps, because even currently,
> packages
> > just switch the Bugzilla to ASSIGNED to stop them.
>
> Instead of spending your time on better nag e-mails why don't you look at
> contributing patches?
>

Miro does contribute a lot of patches. There are still a lot of packages
which need more than just a patch but someone to take ownership. If you
have a problem with these actions please bring them up with FESCO or the
Council as this was brought up previously in both places as things that
needed to be fixed. They can then work out how this is to be dealt with in
the future.




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

[Adam Williamson]

On Fri, 2019-08-09 at 13:07 -0500, Michael Cronenworth wrote:
> On 8/9/19 8:50 AM, Miro Hrončok wrote:
> > Because if we don't, people just gonna ignore FTBFS forever.
> > 
> > Could we have known that gettext will be unretired right away anyway? 
> > Probably 
> > yes, but nobody got time / energy / resources to do any kind of analysis of 
> > the 
> > FTBFS packages.
> > 
> > Next time, I hope that FTBFS bugs for critical component are actually 
> > actively 
> > solved sooner than the retirement happens. We can try to be more aggressive 
> > with 
> > the reminders, but I don't know if that helps, because even currently, 
> > packages 
> > just switch the Bugzilla to ASSIGNED to stop them.
> 
> Instead of spending your time on better nag e-mails why don't you look at 
> contributing patches?

Do you know he doesn't? But regardless, one person can run an FTBFS
notification system. One person cannot fix all the FTBFS bugs.

It's similar to the blocker bug process: a couple of us in QA can
handle discovering, reporting and tracking blocker bugs. We can't *fix*
them all (though I try to fix as many as I have time and ability to).
-- 
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

Re: Does anybody care about gettext?

[Michael Cronenworth]

On 8/9/19 8:50 AM, Miro Hrončok wrote:

Because if we don't, people just gonna ignore FTBFS forever.

Could we have known that gettext will be unretired right away anyway? Probably 
yes, but nobody got time / energy / resources to do any kind of analysis of the 
FTBFS packages.


Next time, I hope that FTBFS bugs for critical component are actually actively 
solved sooner than the retirement happens. We can try to be more aggressive with 
the reminders, but I don't know if that helps, because even currently, packages 
just switch the Bugzilla to ASSIGNED to stop them.


Instead of spending your time on better nag e-mails why don't you look at 
contributing patches?

___
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: Dropping python2-rpm subpackage?

[Miro Hrončok]

On 07. 08. 19 12:55, Panu Matilainen wrote:
Oh, based on the quoting, I thought the "FTBFS, should have been retired 
yesterday" remarks in your initial reply covered all these too. Since 
that's not the case...


Sorry for the confusion:

$ repoquery --repo=koji{,-source} --whatrequires python2-rpm
ailurus-0:10.10.3-19.fc31.noarch
dmlite-shell-0:1.13.1-2.fc31.x86_64
mach-0:1.0.4-10.fc31.x86_64
python2-kobo-rpmlib-0:0.10.0-2.fc31.noarch

The last listed (kobo) is going to be removed next week.


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

[Miro Hrončok]

On 09. 08. 19 17:45, Michael Cronenworth wrote:

On 8/8/19 7:45 PM, Miro Hrončok wrote:


What's the bug? Why should have it not been retired exactly? It didn't build 
since Fedora 26. 


The retirement message states:

Please fix mingw-wine-gecko at your earliest convenience and set the bug's 
status to

ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks,
mingw-wine-gecko will be orphaned. Before branching of Fedora 32,
mingw-wine-gecko will be retired, if it still fails to build.


It actually stated:

"Before branching of Fedora 31, mingw-wine-gecko will be retired, if it still 
fails to build."


https://bugzilla.redhat.com/show_bug.cgi?id=1675390#c0

Branching of Fedora 31 will happen next week.



The FTBFS bug was set to ASSIGNED yet your script retired it.


Correct. It was still failing to build.

Wine users need this package to prevent Wine from downloading Gecko from the 
Internet.


The reasons for the FTBFS have been stated in the bug.

While I would love to fix every FTBFS issue overnight sometimes it just doesn't 
work that way.


Overnight? The latest build is from 2016-11-24.

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

[Michael Cronenworth]

On 8/8/19 7:45 PM, Miro Hrončok wrote:


What's the bug? Why should have it not been retired exactly? It didn't build since 
Fedora 26. 


The retirement message states:

Please fix mingw-wine-gecko at your earliest convenience and set the bug's 
status to
ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks,
mingw-wine-gecko will be orphaned. Before branching of Fedora 32,
mingw-wine-gecko will be retired, if it still fails to build.

The FTBFS bug was set to ASSIGNED yet your script retired it.

Wine users need this package to prevent Wine from downloading Gecko from the 
Internet.

The reasons for the FTBFS have been stated in the bug.

While I would love to fix every FTBFS issue overnight sometimes it just doesn't 
work that way.
___
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

[HEADS-UP] dav1d and aom SONAME bump

[Robert-André Mauchin]

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.

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 packages to be removed form EPEL 7 (provided by RHEL 7)

[Miro Hrončok]

On 09. 08. 19 17:38, Stephen John Smoogen wrote:



I tested all three and gave karma.


Thanks. I'll wait for the push and retire the old packages.

I hope everything will work as expected.

--
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 packages to be removed form EPEL 7 (provided by RHEL 7)

[Stephen John Smoogen]

I tested all three and gave karma.

On Fri, 9 Aug 2019 at 11:32, Miro Hrončok  wrote:

> On 09. 08. 19 16:49, Stephen John Smoogen wrote:
> >
> > I have tested python2-wheel and it worked. Looking to see what needs to
> be done
> > for th eohters.
>
> Thanks. The update is for all 3 of them.
>
> --
> 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

[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

[Miro Hrončok]

On 09. 08. 19 16:49, Stephen John Smoogen wrote:


I have tested python2-wheel and it worked. Looking to see what needs to be done 
for th eohters.


Thanks. The update is for all 3 of them.

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

Package removal for FTBFS: Add automatic orphaning?

[Miro Hrončok]

The current policy says:

https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

7. A week before the mass branching, any packages which still have open FTBFS 
bugs from the previous release will be retired.


I propose we add a point just before that that says:

7. 7 weeks before the mass branching, any packages which still have open FTBFS 
bugs from the previous release will be orphaned.
8. A week before the mass branching, any packages which still have open FTBFS 
bugs from the previous release will be retired.


In theory, the 8. doesn't need to be there, but in practice, it prevents 
packagers from claiming the package but not fixing it.


This should raise awareness and prevent surprises.

But, there is one communication failure:

Imagine a maintainer says: "Yes, I'm working on this, fix will be ready next 
week." And the response is "Your package has been orphaned."


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


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

[Brian (bex) Exelbierd]

On Fri, Aug 9, 2019 at 5:06 PM Miro Hrončok  wrote:
>
> On 09. 08. 19 16:29, Simo Sorce wrote:
> > On Fri, 2019-08-09 at 15:50 +0200, Miro Hrončok wrote:
> >> Next time, I hope that FTBFS bugs for critical component are actually 
> >> actively
> >> solved sooner than the retirement happens. We can try to be more 
> >> aggressive with
> >> the reminders, but I don't know if that helps, because even currently, 
> >> packages
> >> just switch the Bugzilla to ASSIGNED to stop them.
> >
> > If you send direct emails to package owner specifying what package is
> > broken maybe yes.
> >
> > If you send multikilobyte emails generically stating FTBFS and parse
> > yourself this list of 1000 packages to see if one is yours, then no,
> > they go to trash directly.
>
> Patches welcome :D Even now, the reminders are semiautomatical and painful.
> Sending direct e-mail is impossible without proper automation. And it seems 
> all
> our automation from years ago is now nonfunctional.

FWIW, python3-mailmerge might be useful here as the email would be
direct, personalized, and not subject to filters around BZ mail.

regards,

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

[Miro Hrončok]

On 09. 08. 19 16:58, Paul Wouters wrote:

On Fri, 9 Aug 2019, Daniel P. Berrangé wrote:


We can't carry on postponing things indefinitely though - at some point we
have to say enough, and expect a maintainer to actually do some maintaining.


That is an argument to orphan, not an argument to remove the package.
Had gettext been orphaned, people would have noticed without the entire
OS breakage.


The breakage took ~3 several hours to notice and a 5 minute fix.

I think it was not that catastrophic.

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

[Adam Williamson]

On Fri, 2019-08-09 at 10:29 -0400, Simo Sorce wrote:
> On Fri, 2019-08-09 at 15:50 +0200, Miro Hrončok wrote:
> > Next time, I hope that FTBFS bugs for critical component are actually 
> > actively 
> > solved sooner than the retirement happens. We can try to be more aggressive 
> > with 
> > the reminders, but I don't know if that helps, because even currently, 
> > packages 
> > just switch the Bugzilla to ASSIGNED to stop them.
> 
> If you send direct emails to package owner specifying what package is
> broken maybe yes.

The bug reports do that.
-- 
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

Re: Does anybody care about gettext?

[Paul Wouters]

On Fri, 9 Aug 2019, Daniel P. Berrangé wrote:


We can't carry on postponing things indefinitely though - at some point we
have to say enough, and expect a maintainer to actually do some maintaining.


That is an argument to orphan, not an argument to remove the package.
Had gettext been orphaned, people would have noticed without the entire
OS breakage.

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

[Miro Hrončok]

On 09. 08. 19 16:22, Martin Kolman wrote:

On Fri, 2019-08-09 at 15:14 +0100, Daniel P. Berrangé wrote:

On Fri, Aug 09, 2019 at 03:13:07PM +0200, Martin Kolman wrote:

On Fri, 2019-08-09 at 14:00 +0100, Daniel P. Berrangé wrote:

On Fri, Aug 09, 2019 at 02:28:55PM +0200, Jens-Ulrik Petersen wrote:

On Fri, Aug 9, 2019 at 9:27 AM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:


Well, it was retired because it did not built since F30 mass rebuild…



I went ahead and built it with the testsuite disabled for now: I suppose
any Proven Packager could also have done, but yeah normally it should be
done by the maintainers.
I admit the ball was dropped on this by various people (myself included),
and sorry about that. [1]
The new major upstream release was also a long time coming...

But to me the deeper question is still "why are we proactively breaking the
distro" in this way with package retirements by non-maintainers?

Sure FTBFS is bad but there is no need to proactively remove core packages
which are still working okay.
I really really wish could stop this... causing more busy work and stress.


When a FTBFS hits, we don't know whether the package is still working
ok or not as there are many possible reasons for the failure.

Maybe this is something gating tests could help with ? If a package is FTBFS
and has reasonable gating test coverage, you will know it is working.


The gating CI is a pretty low bar right now. As CI is made stronger,
it could well actually make FTBFS *more* common, as CI is introducing
more scope for things to be classed as a failure. So be careful what
you wish for :-)


  Filing
the FTBFS BZs informs the maintainer(s) & allows them to investigate,
figure what has gone wrong & decide what changes are needed. Missing
on 2 mass rebuilds means the package is still build with F29 toolchain,
and thus lacking desired improvements Fedora is introducing, so this
has a cost for the rest of the distro. Somewhere there's a balance
between cost for the maintainer in work & cost for the distro in the
package being outdated.

There was no acknowlegement on the BZ that anyone was actively working
on fixing it in 6 months. This is true for so many of the FTBFS BZs that
get filed. If the packages don't get orphaned after 6+ months of being
ignored, when would they ever be fixed ?

Having said that, I think in the case of packages which are deps of
so much of the distro, it could have been useful to have a warning of
imminent orphaning on fedora-devel. There was a warning that orphaning
was starting, but no list of affected packages included.

Maybe another job for automated tests/CI ?

Before dropping a batch of packages, do a test compose without them and postpone
the drop if the compose run crashes and burns.

Sounds really like something doable which could save a lot of everyones time 
once in place.


We can't carry on postponing things indefinitely though - at some point we
have to say enough, and expect a maintainer to actually do some maintaining.

Sure & I totally agree with that.

I'm just trying to find ways that can sound the alarm bells &
prevent everyone impacting Rawhide breakage before it's too late
and things need to be fixed post-mortem. An this case really looks
like something that an automated check should be able to catch soon
enough. :)


Tough question: Would the package get any attention if it was not retired?

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

[Miro Hrončok]

On 09. 08. 19 16:29, Simo Sorce wrote:

On Fri, 2019-08-09 at 15:50 +0200, Miro Hrončok wrote:

Next time, I hope that FTBFS bugs for critical component are actually actively
solved sooner than the retirement happens. We can try to be more aggressive with
the reminders, but I don't know if that helps, because even currently, packages
just switch the Bugzilla to ASSIGNED to stop them.


If you send direct emails to package owner specifying what package is
broken maybe yes.

If you send multikilobyte emails generically stating FTBFS and parse
yourself this list of 1000 packages to see if one is yours, then no,
they go to trash directly.


Patches welcome :D Even now, the reminders are semiautomatical and painful. 
Sending direct e-mail is impossible without proper automation. And it seems all 
our automation from years ago is now nonfunctional.


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

[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)

[Stephen John Smoogen]

I have tested python2-wheel and it worked. Looking to see what needs to be
done for th eohters.

On Fri, 9 Aug 2019 at 10:27, Miro Hrončok  wrote:

> On 17. 07. 19 0:00, Miro Hrončok wrote:
> > Hey,
> >
> > when RHEL 7.7 will be released, the following new components/packages
> will be
> > provided (assuming from 7.7 beta):
>
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-31bd12e515
>
> Please somebody do a sanity check, so I can retire python-pip,
> python3-setuptools and python-wheel.
>
> --
> 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: Does anybody care about gettext?

[Simo Sorce]

On Fri, 2019-08-09 at 15:50 +0200, Miro Hrončok wrote:
> Next time, I hope that FTBFS bugs for critical component are actually 
> actively 
> solved sooner than the retirement happens. We can try to be more aggressive 
> with 
> the reminders, but I don't know if that helps, because even currently, 
> packages 
> just switch the Bugzilla to ASSIGNED to stop them.

If you send direct emails to package owner specifying what package is
broken maybe yes.

If you send multikilobyte emails generically stating FTBFS and parse
yourself this list of 1000 packages to see if one is yours, then no,
they go to trash directly.

Simo.
___
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 packages to be removed form EPEL 7 (provided by RHEL 7)

[Miro Hrončok]

On 17. 07. 19 0:00, Miro Hrončok wrote:

Hey,

when RHEL 7.7 will be released, the following new components/packages will be 
provided (assuming from 7.7 beta):


https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-31bd12e515

Please somebody do a sanity check, so I can retire python-pip, 
python3-setuptools and python-wheel.


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

[Martin Kolman]

On Fri, 2019-08-09 at 15:14 +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 09, 2019 at 03:13:07PM +0200, Martin Kolman wrote:
> > On Fri, 2019-08-09 at 14:00 +0100, Daniel P. Berrangé wrote:
> > > On Fri, Aug 09, 2019 at 02:28:55PM +0200, Jens-Ulrik Petersen wrote:
> > > > On Fri, Aug 9, 2019 at 9:27 AM Igor Gnatenko <
> > > > ignatenkobr...@fedoraproject.org> wrote:
> > > > 
> > > > > Well, it was retired because it did not built since F30 mass rebuild…
> > > > > 
> > > > 
> > > > I went ahead and built it with the testsuite disabled for now: I suppose
> > > > any Proven Packager could also have done, but yeah normally it should be
> > > > done by the maintainers.
> > > > I admit the ball was dropped on this by various people (myself 
> > > > included),
> > > > and sorry about that. [1]
> > > > The new major upstream release was also a long time coming...
> > > > 
> > > > But to me the deeper question is still "why are we proactively breaking 
> > > > the
> > > > distro" in this way with package retirements by non-maintainers?
> > > > 
> > > > Sure FTBFS is bad but there is no need to proactively remove core 
> > > > packages
> > > > which are still working okay.
> > > > I really really wish could stop this... causing more busy work and 
> > > > stress.
> > > 
> > > When a FTBFS hits, we don't know whether the package is still working
> > > ok or not as there are many possible reasons for the failure.
> > Maybe this is something gating tests could help with ? If a package is FTBFS
> > and has reasonable gating test coverage, you will know it is working.
> 
> The gating CI is a pretty low bar right now. As CI is made stronger,
> it could well actually make FTBFS *more* common, as CI is introducing
> more scope for things to be classed as a failure. So be careful what
> you wish for :-)
> 
> > >  Filing
> > > the FTBFS BZs informs the maintainer(s) & allows them to investigate,
> > > figure what has gone wrong & decide what changes are needed. Missing
> > > on 2 mass rebuilds means the package is still build with F29 toolchain,
> > > and thus lacking desired improvements Fedora is introducing, so this
> > > has a cost for the rest of the distro. Somewhere there's a balance
> > > between cost for the maintainer in work & cost for the distro in the
> > > package being outdated.
> > > 
> > > There was no acknowlegement on the BZ that anyone was actively working
> > > on fixing it in 6 months. This is true for so many of the FTBFS BZs that
> > > get filed. If the packages don't get orphaned after 6+ months of being
> > > ignored, when would they ever be fixed ?
> > > 
> > > Having said that, I think in the case of packages which are deps of
> > > so much of the distro, it could have been useful to have a warning of
> > > imminent orphaning on fedora-devel. There was a warning that orphaning
> > > was starting, but no list of affected packages included.
> > Maybe another job for automated tests/CI ?
> > 
> > Before dropping a batch of packages, do a test compose without them and 
> > postpone
> > the drop if the compose run crashes and burns.
> > 
> > Sounds really like something doable which could save a lot of everyones 
> > time once in place.
> 
> We can't carry on postponing things indefinitely though - at some point we
> have to say enough, and expect a maintainer to actually do some maintaining.
Sure & I totally agree with that. 

I'm just trying to find ways that can sound the alarm bells & 
prevent everyone impacting Rawhide breakage before it's too late
and things need to be fixed post-mortem. An this case really looks
like something that an automated check should be able to catch soon 
enough. :)

> 
> Regards,
> Daniel
___
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?

[Daniel P . Berrangé]

On Fri, Aug 09, 2019 at 03:13:07PM +0200, Martin Kolman wrote:
> On Fri, 2019-08-09 at 14:00 +0100, Daniel P. Berrangé wrote:
> > On Fri, Aug 09, 2019 at 02:28:55PM +0200, Jens-Ulrik Petersen wrote:
> > > On Fri, Aug 9, 2019 at 9:27 AM Igor Gnatenko <
> > > ignatenkobr...@fedoraproject.org> wrote:
> > > 
> > > > Well, it was retired because it did not built since F30 mass rebuild…
> > > > 
> > > 
> > > I went ahead and built it with the testsuite disabled for now: I suppose
> > > any Proven Packager could also have done, but yeah normally it should be
> > > done by the maintainers.
> > > I admit the ball was dropped on this by various people (myself included),
> > > and sorry about that. [1]
> > > The new major upstream release was also a long time coming...
> > > 
> > > But to me the deeper question is still "why are we proactively breaking 
> > > the
> > > distro" in this way with package retirements by non-maintainers?
> > > 
> > > Sure FTBFS is bad but there is no need to proactively remove core packages
> > > which are still working okay.
> > > I really really wish could stop this... causing more busy work and stress.
> > 
> > When a FTBFS hits, we don't know whether the package is still working
> > ok or not as there are many possible reasons for the failure.
> Maybe this is something gating tests could help with ? If a package is FTBFS
> and has reasonable gating test coverage, you will know it is working.

The gating CI is a pretty low bar right now. As CI is made stronger,
it could well actually make FTBFS *more* common, as CI is introducing
more scope for things to be classed as a failure. So be careful what
you wish for :-)

> >  Filing
> > the FTBFS BZs informs the maintainer(s) & allows them to investigate,
> > figure what has gone wrong & decide what changes are needed. Missing
> > on 2 mass rebuilds means the package is still build with F29 toolchain,
> > and thus lacking desired improvements Fedora is introducing, so this
> > has a cost for the rest of the distro. Somewhere there's a balance
> > between cost for the maintainer in work & cost for the distro in the
> > package being outdated.
> > 
> > There was no acknowlegement on the BZ that anyone was actively working
> > on fixing it in 6 months. This is true for so many of the FTBFS BZs that
> > get filed. If the packages don't get orphaned after 6+ months of being
> > ignored, when would they ever be fixed ?
> > 
> > Having said that, I think in the case of packages which are deps of
> > so much of the distro, it could have been useful to have a warning of
> > imminent orphaning on fedora-devel. There was a warning that orphaning
> > was starting, but no list of affected packages included.
> Maybe another job for automated tests/CI ?
> 
> Before dropping a batch of packages, do a test compose without them and 
> postpone
> the drop if the compose run crashes and burns.
> 
> Sounds really like something doable which could save a lot of everyones time 
> once in place.

We can't carry on postponing things indefinitely though - at some point we
have to say enough, and expect a maintainer to actually do some maintaining.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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?

[Miro Hrončok]

On 09. 08. 19 14:28, Jens-Ulrik Petersen wrote:
On Fri, Aug 9, 2019 at 9:27 AM Igor Gnatenko > wrote:


Well, it was retired because it did not built since F30 mass rebuild…


I went ahead and built it with the testsuite disabled for now: I suppose any 
Proven Packager could also have done, but yeah normally it should be done by the 
maintainers.
I admit the ball was dropped on this by various people (myself included), and 
sorry about that. [1]

The new major upstream release was also a long time coming...

But to me the deeper question is still "why are we proactively breaking the 
distro" in this way with package retirements by non-maintainers?


Because if we don't, people just gonna ignore FTBFS forever.

Could we have known that gettext will be unretired right away anyway? Probably 
yes, but nobody got time / energy / resources to do any kind of analysis of the 
FTBFS packages.


Next time, I hope that FTBFS bugs for critical component are actually actively 
solved sooner than the retirement happens. We can try to be more aggressive with 
the reminders, but I don't know if that helps, because even currently, packages 
just switch the Bugzilla to ASSIGNED to stop them.


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

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

[Miro Hrončok]

On 09. 08. 19 12:17, Pablo Sebastián Greco wrote:


El 9/8/19 a las 07:08, Miro Hrončok escribió:

On 09. 08. 19 11:13, Antonio Trande wrote:

Hi all.

'python-devel-2.7.5-86.el7' requires 'python(2)-rpm-macros > 3-30' on
EPEL7 ppc64le only?

https://koji.fedoraproject.org/koji/getfile?taskID=36879492=DEFAULT=root.log=-4000 



It does it on all architectures. This looks like the RHEL 7.7 version of the 
package. python(2)-rpm-macros 3-32 should be there as well.


Is it possible that you have caught the builders mid updating? Such as the 
ppc64le packages were updated to 7.7 but the noarch packages were not yet?



I think that what is happening is that koji is ignoring the RHEL version.

The last python-rpm-macros built in koji for epel, is 3.25, and this one has 
priority over 3.32 imported from RHEL 7.7 (locally built is more important than 
external, no matter the version).


This package needs to be retired from EPEL so it can pick up the RHEL version, 
which is also mandatory due to EPEL guidelines.


Will do. I was waiting for the release to happen.

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

[HEADS-UP] gradle will go away

[Fabio Valentini]

Hi everybody!

After some discussions, we (the Stewardship SIG) have decided that we
cannot continue to maintain gradle in fedora.

- the current version packaged in fedora is outdated (4.4.1, from Dec.
2017, vs. 5.5.1 from July 2019)
- it currently doesn't build itself (not even in bootstrap mode), and
needs an older version tagged into rawhide as a buildroot override to
even build (this doesn't work anymore, due to rawhide gating)
- the current version has open CVE issues associated with it on fedora 30+
- it pulls in a lot of dependencies (and newer versions pull in even
more), which we don't have the manpower to maintain (including scala,
sbt, zinc)
- other distros seem to have basically given up on building gradle as
well, since they mostly ship the same version as fedora (except Arch,
where they just package up the binaries upstream publishes)

The current plan is to drop support for building packages with gradle,
first by orphaning / retiring gradle, and then removing the gradle
support code from javapackages-tools (which produces the gradle-local
package).

Since there is a very limited number of actively maintained Java
packages that are built with gradle (less than 10), we expect the
breakage not to be too bad.

Also, there is a possibility to "port" projects that currently use
gradle to be built with maven instead, which has already been done for
some fedora packages (testng, junit5, aqute-bnd, etc.). This might be
the way forward for packagers who don't want their packages to be
broken but also don't want to / cannot maintain gradle and its
dependencies either.

The exact time of the retirement will depend on the fedora schedule
and our available time, but it will probably happen just before the
F31 branch point, to make sure there's enough time before the F31 beta
freeze to fix any breakage.

---

I've talked about this at flock, you can look at my slides here (the
gradle issue is towards the end):
https://decathorpe.fedorapeople.org/flock2019/stewardship.pdf

The talks are also all being recorded, but I don't know when the
videos will be available.

Fabio, for the Stewardship SIG
___
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

[HEADS-UP] gradle will go away

[Fabio Valentini]

Hi everybody!

After some discussions, we (the Stewardship SIG) have decided that we
cannot continue to maintain gradle in fedora.

- the current version packaged in fedora is outdated (4.4.1, from Dec.
2017, vs. 5.5.1 from July 2019)
- it currently doesn't build itself (not even in bootstrap mode), and
needs an older version tagged into rawhide as a buildroot override to
even build (this doesn't work anymore, due to rawhide gating)
- the current version has open CVE issues associated with it on fedora 30+
- it pulls in a lot of dependencies (and newer versions pull in even
more), which we don't have the manpower to maintain (including scala,
sbt, zinc)
- other distros seem to have basically given up on building gradle as
well, since they mostly ship the same version as fedora (except Arch,
where they just package up the binaries upstream publishes)

The current plan is to drop support for building packages with gradle,
first by orphaning / retiring gradle, and then removing the gradle
support code from javapackages-tools (which produces the gradle-local
package).

Since there is a very limited number of actively maintained Java
packages that are built with gradle (less than 10), we expect the
breakage not to be too bad.

Also, there is a possibility to "port" projects that currently use
gradle to be built with maven instead, which has already been done for
some fedora packages (testng, junit5, aqute-bnd, etc.). This might be
the way forward for packagers who don't want their packages to be
broken but also don't want to / cannot maintain gradle and its
dependencies either.

The exact time of the retirement will depend on the fedora schedule
and our available time, but it will probably happen just before the
F31 branch point, to make sure there's enough time before the F31 beta
freeze to fix any breakage.

---

I've talked about this at flock, you can look at my slides here (the
gradle issue is towards the end):
https://decathorpe.fedorapeople.org/flock2019/stewardship.pdf

The talks are also all being recorded, but I don't know when the
videos will be available.

Fabio, for the Stewardship SIG
___
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?

[Martin Kolman]

On Fri, 2019-08-09 at 14:00 +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 09, 2019 at 02:28:55PM +0200, Jens-Ulrik Petersen wrote:
> > On Fri, Aug 9, 2019 at 9:27 AM Igor Gnatenko <
> > ignatenkobr...@fedoraproject.org> wrote:
> > 
> > > Well, it was retired because it did not built since F30 mass rebuild…
> > > 
> > 
> > I went ahead and built it with the testsuite disabled for now: I suppose
> > any Proven Packager could also have done, but yeah normally it should be
> > done by the maintainers.
> > I admit the ball was dropped on this by various people (myself included),
> > and sorry about that. [1]
> > The new major upstream release was also a long time coming...
> > 
> > But to me the deeper question is still "why are we proactively breaking the
> > distro" in this way with package retirements by non-maintainers?
> > 
> > Sure FTBFS is bad but there is no need to proactively remove core packages
> > which are still working okay.
> > I really really wish could stop this... causing more busy work and stress.
> 
> When a FTBFS hits, we don't know whether the package is still working
> ok or not as there are many possible reasons for the failure.
Maybe this is something gating tests could help with ? If a package is FTBFS
and has reasonable gating test coverage, you will know it is working.

>  Filing
> the FTBFS BZs informs the maintainer(s) & allows them to investigate,
> figure what has gone wrong & decide what changes are needed. Missing
> on 2 mass rebuilds means the package is still build with F29 toolchain,
> and thus lacking desired improvements Fedora is introducing, so this
> has a cost for the rest of the distro. Somewhere there's a balance
> between cost for the maintainer in work & cost for the distro in the
> package being outdated.
> 
> There was no acknowlegement on the BZ that anyone was actively working
> on fixing it in 6 months. This is true for so many of the FTBFS BZs that
> get filed. If the packages don't get orphaned after 6+ months of being
> ignored, when would they ever be fixed ?
> 
> Having said that, I think in the case of packages which are deps of
> so much of the distro, it could have been useful to have a warning of
> imminent orphaning on fedora-devel. There was a warning that orphaning
> was starting, but no list of affected packages included.
Maybe another job for automated tests/CI ?

Before dropping a batch of packages, do a test compose without them and postpone
the drop if the compose run crashes and burns.

Sounds really like something doable which could save a lot of everyones time 
once in place.

> 
> If a package list was included, *non-maintainers* might have noticed that
> gettext was at risk & would massively impact the distro & could have
> stepped up to help solve it, where the original maintainer drops the ball.
> 
> Overall though, despite the disruption, orphaning has had the intended
> effect of getting the long standing FTBFS problem resolved.
> 
> Regards,
> Daniel
> -- 
> > : https://berrange.com  -o-https://www.flickr.com/photos/dberrange 
> > :|
> > : https://libvirt.org -o-https://fstop138.berrange.com 
> > :|
> > : https://entangle-photo.org-o-https://www.instagram.com/dberrange 
> > :|
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://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: HEADS UP: Source File Verification

[Simo Sorce]

On Thu, 2019-08-08 at 16:24 +0200, Björn Persson wrote:
> Joe Orton wrote:
> > If you don't enforce GPG verification at or before "fedpkg upload" there 
> > is no assurance that what hits the lookaside cache is trusted, so I 
> > agree - doing this at build time is a good example of not caring about 
> > security until it's too late.
> 
> I hope most people reading this can see the flaws in that reasoning.
> 
> > But I assume the FPC is off doing its own thing and will totally ignore 
> > community feedback as normal,
> 
> It took a long time and some prodding, but the fact that the source
> file verification policy was eventually accepted is proof that this
> accusation is false.

Hi Björn,
I have not commented on this till now and both Joe's email is
needlessly provocative as well as your dismissal is a bit content-less.

The question is simply, how can you trust build time verification if
you do not have INPUT time verification ?
What prevents me from putting *into* Fedora a completely bogus source
*AND* public key that always verifies correctly ?

Simo.
___
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?

[Daniel P . Berrangé]

On Fri, Aug 09, 2019 at 02:28:55PM +0200, Jens-Ulrik Petersen wrote:
> On Fri, Aug 9, 2019 at 9:27 AM Igor Gnatenko <
> ignatenkobr...@fedoraproject.org> wrote:
> 
> > Well, it was retired because it did not built since F30 mass rebuild…
> >
> 
> I went ahead and built it with the testsuite disabled for now: I suppose
> any Proven Packager could also have done, but yeah normally it should be
> done by the maintainers.
> I admit the ball was dropped on this by various people (myself included),
> and sorry about that. [1]
> The new major upstream release was also a long time coming...
> 
> But to me the deeper question is still "why are we proactively breaking the
> distro" in this way with package retirements by non-maintainers?
> 
> Sure FTBFS is bad but there is no need to proactively remove core packages
> which are still working okay.
> I really really wish could stop this... causing more busy work and stress.

When a FTBFS hits, we don't know whether the package is still working
ok or not as there are many possible reasons for the failure. Filing
the FTBFS BZs informs the maintainer(s) & allows them to investigate,
figure what has gone wrong & decide what changes are needed. Missing
on 2 mass rebuilds means the package is still build with F29 toolchain,
and thus lacking desired improvements Fedora is introducing, so this
has a cost for the rest of the distro. Somewhere there's a balance
between cost for the maintainer in work & cost for the distro in the
package being outdated.

There was no acknowlegement on the BZ that anyone was actively working
on fixing it in 6 months. This is true for so many of the FTBFS BZs that
get filed. If the packages don't get orphaned after 6+ months of being
ignored, when would they ever be fixed ?

Having said that, I think in the case of packages which are deps of
so much of the distro, it could have been useful to have a warning of
imminent orphaning on fedora-devel. There was a warning that orphaning
was starting, but no list of affected packages included.

If a package list was included, *non-maintainers* might have noticed that
gettext was at risk & would massively impact the distro & could have
stepped up to help solve it, where the original maintainer drops the ball.

Overall though, despite the disruption, orphaning has had the intended
effect of getting the long standing FTBFS problem resolved.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: gettext retired, rawhide broken

[Jens-Ulrik Petersen]

On Fri, Aug 9, 2019 at 7:38 AM Fabio Valentini  wrote:

> Can somebody please unretire and fix gettext? It was just automatically
> retired because it didn't build successfully since fedora 29. And now the
> world is broken.
>

Thanks - I think it has been taken care of for now.
Jens
___
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?

[Jens-Ulrik Petersen]

On Fri, Aug 9, 2019 at 9:27 AM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

> Well, it was retired because it did not built since F30 mass rebuild…
>

I went ahead and built it with the testsuite disabled for now: I suppose
any Proven Packager could also have done, but yeah normally it should be
done by the maintainers.
I admit the ball was dropped on this by various people (myself included),
and sorry about that. [1]
The new major upstream release was also a long time coming...

But to me the deeper question is still "why are we proactively breaking the
distro" in this way with package retirements by non-maintainers?

Sure FTBFS is bad but there is no need to proactively remove core packages
which are still working okay.
I really really wish could stop this... causing more busy work and stress.

Jens

[1] short version is: there was a partial package owner handover which was
not properly completed unfortunately.
___
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

[Bug 1739463] New: perldoc -f '<>' complains about pod errors

[bugzilla]

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

Bug ID: 1739463
   Summary: perldoc -f '<>' complains about pod errors
   Product: Fedora
   Version: 30
Status: NEW
 Component: perl
  Assignee: jples...@redhat.com
  Reporter: iamde...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com, iarn...@gmail.com,
jples...@redhat.com, ka...@ucw.cz,
mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com, rhug...@redhat.com,
sandm...@redhat.com, tcall...@redhat.com
  Target Milestone: ---
Classification: Fedora



Description of problem: the output of `perldoc -f '<>'` is garbled with pod
errors at the end [1]. Also, there's more text than probably should be [2].

Version-Release number of selected component (if applicable):
perl-interpreter-5.28.2-438.fc30.x86_64 (also see [2])

How reproducible: always


Steps to Reproduce:
1. perldoc -f '<>'
2. scroll to the end

Actual results: see below

[1]
POD ERRORS
Hey! The above document had some coding errors, which are explained
below:

Around line 259:
You forgot a '=back' before '=head2'

Around line 482:
=back without =over

[2]
Besides pod errors, there's some extra text beginning with "Constant Folding"
and ending with

Here is a short, but incomplete summary:

  Math::String   treat string sequences like numbers
  Math::FixedPrecision   calculate with a fixed precision
  Math::Currency for currency calculations
  Bit::Vectormanipulate bit vectors fast (uses C)
  Math::BigIntFast   Bit::Vector wrapper for big numbers
  Math::Pari provides access to the Pari C library
  Math::Cephes   uses the external Cephes C library (no
 big numbers)
  Math::Cephes::Fraction fractions via the Cephes library
  Math::GMP  another one using an external C library
  Math::GMPz an alternative interface to libgmp's big ints
  Math::GMPq an interface to libgmp's fraction numbers
  Math::GMPf an interface to libgmp's floating point numbers

Choose wisely.

after the actual contents of the requested perldoc section. Also there's no
section header at the beginning. The similar issue exists on Windows with
Strawberry Perl 5.30.0.1 (hence it's highly likely an upstream bug). On CentOS
7 with perl-5.16.3-292.el7.x86_64 `perldoc -f '<>'` displays what it should
without any errors.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

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

[Pablo Sebastián Greco]

El 9/8/19 a las 07:08, Miro Hrončok escribió:

On 09. 08. 19 11:13, Antonio Trande wrote:

Hi all.

'python-devel-2.7.5-86.el7' requires 'python(2)-rpm-macros > 3-30' on
EPEL7 ppc64le only?

https://koji.fedoraproject.org/koji/getfile?taskID=36879492=DEFAULT=root.log=-4000 



It does it on all architectures. This looks like the RHEL 7.7 version 
of the package. python(2)-rpm-macros 3-32 should be there as well.


Is it possible that you have caught the builders mid updating? Such as 
the ppc64le packages were updated to 7.7 but the noarch packages were 
not yet?



I think that what is happening is that koji is ignoring the RHEL version.

The last python-rpm-macros built in koji for epel, is 3.25, and this one 
has priority over 3.32 imported from RHEL 7.7 (locally built is more 
important than external, no matter the version).


This package needs to be retired from EPEL so it can pick up the RHEL 
version, which is also mandatory due to EPEL guidelines.


Pablo.

___
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

[Miro Hrončok]

On 09. 08. 19 11:13, Antonio Trande wrote:

Hi all.

'python-devel-2.7.5-86.el7' requires 'python(2)-rpm-macros > 3-30' on
EPEL7 ppc64le only?

https://koji.fedoraproject.org/koji/getfile?taskID=36879492=DEFAULT=root.log=-4000


It does it on all architectures. This looks like the RHEL 7.7 version of the 
package. python(2)-rpm-macros 3-32 should be there as well.


Is it possible that you have caught the builders mid updating? Such as the 
ppc64le packages were updated to 7.7 but the noarch packages were not yet?


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

[Miro Hrončok]

On 09. 08. 19 10:09, Alexander Ploumistos wrote:

P.S.: Can anyone explain how the builds of other packages went back to
normal, even though there was no successful gettext build?


I've requested the package to be unretired and when that happened, I've retagged 
the latest build to f31-pending. That eventually moved it back to f31.


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

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

[Antonio Trande]

Hi all.

'python-devel-2.7.5-86.el7' requires 'python(2)-rpm-macros > 3-30' on
EPEL7 ppc64le only?

https://koji.fedoraproject.org/koji/getfile?taskID=36879492=DEFAULT=root.log=-4000

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

Missing python-rpm-macros>3.30 on EPEL7 ppc64le

[Antonio Trande]

Hi all.

'python-devel-2.7.5-86.el7' requires 'python(2)-rpm-macros > 3-30' on
EPEL7 ppc64le only?

https://koji.fedoraproject.org/koji/getfile?taskID=36879492=DEFAULT=root.log=-4000

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

[Leigh Scott]

Maybe package the newer version 0.20.1 http://www.gnu.org/software/gettext/
___
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?

[Sundeep Anand]

On Fri, Aug 9, 2019 at 1:40 PM Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> Hello,
>
> On Fri, Aug 9, 2019 at 11:03 AM Sundeep Anand  wrote:
> > most probably I’ll fix that by next week.
>
> All the patches we carried were merged back in the latest upstream
> version (0.20.1), but when I took a stab at it, I got a lot of errors
>

I noticed that, thanks :)


> about the variable types and I did not know how to proceed.
>
> Best of luck
>
> P.S.: Can anyone explain how the builds of other packages went back to
> normal, even though there was no successful gettext build?
> ___
> 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: Does anybody care about gettext?

[Alexander Ploumistos]

Hello,

On Fri, Aug 9, 2019 at 11:03 AM Sundeep Anand  wrote:
> most probably I’ll fix that by next week.

All the patches we carried were merged back in the latest upstream
version (0.20.1), but when I took a stab at it, I got a lot of errors
about the variable types and I did not know how to proceed.

Best of luck

P.S.: Can anyone explain how the builds of other packages went back to
normal, even though there was no successful gettext build?
___
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

[Bug 1627117] perl-Gtk3-0.034-3.fc30 FTBFS: Undefined subroutine ::Gdk::PIXDATA_HEADER_LENGTH called at /builddir/build/BUILD/Gtk3-0.034/blib/lib/Gtk3.pm line 2119

[bugzilla]

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



--- Comment #5 from Petr Pisar  ---
(In reply to Mohan Boddu from comment #4)
> The following builds were made: perl-Gtk3-0.034-5.fc30
> perl-Gtk3-0.034-6.fc30 perl-Gtk3-0.035-1.fc31 perl-Gtk3-0.035-2.fc31
> perl-Gtk3-0.035-3.fc31

(In reply to Petr Pisar from comment #3)
> This is still broken in Fedora 29 (perl-Gtk3-0.034-3.fc29).
 ^^^

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: Does anybody care about gettext?

[Sundeep Anand]

Hi,

most probably I’ll fix that by next week.

thanks,
sundeep 

> On 09-Aug-2019, at 9:26 AM, Igor Gnatenko  
> wrote:
> 
> Well, it was retired because it did not built since F30 mass rebuild…
> 
> * petersen (Jens Petersen)
> * ueno (Daiki Ueno)
> * praiskup (Pavel Raiskup)
> * suanand (Sundeep Anand)
> * nphilipp (Nils Philippsen)
> * jjanco (Jakub Janco)
> 
> 6 maintainers could not fix FTBFS for half a year? Anybody is
> interested to maintain gettext?
> ___
> 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: Does anybody care about gettext?

[Miro Hrončok]

> Well, it was retired because it did not built since F30 mass rebuild…
> 
> 6 maintainers could not fix FTBFS for half a year? Anybody is
> interested to maintain gettext?

BTW I've just orphaned it, so hopefully somebody will take it and actually make 
it build. 
___
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

Does anybody care about gettext?

[Igor Gnatenko]

Well, it was retired because it did not built since F30 mass rebuild…

* petersen (Jens Petersen)
* ueno (Daiki Ueno)
* praiskup (Pavel Raiskup)
* suanand (Sundeep Anand)
* nphilipp (Nils Philippsen)
* jjanco (Jakub Janco)

6 maintainers could not fix FTBFS for half a year? Anybody is
interested to maintain gettext?
___
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] Fedora EPEL 8 updates-testing report

[updates]

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

adplug-2.2.1-10.el8
clamav-0.101.3-1.el8
future-0.17.1-0.3.20190506git23989c4.el8
libbinio-1.4-31.el8
libcue-2.2.1-2.el8
minisign-0.8-2.el8
msoffcrypto-tool-4.10.0-2.el8
python-easygui-0.96-25.el8

Details about builds:



 adplug-2.2.1-10.el8 (FEDORA-EPEL-2019-8c0c9b89c4)
 A software library for AdLib (OPL2) emulation

Update Information:

AdPlug is a free software, cross-platform, hardware independent AdLib sound
player library, mainly written in C++ and released under the LGPL. AdPlug plays
sound data, originally created for the AdLib (OPL2) audio board, directly from
its original format on top of an OPL2 emulator or by using the real hardware. No
OPL chip is required for playback. It supports various audio formats from MS-DOS
AdLib trackers.




 clamav-0.101.3-1.el8 (FEDORA-EPEL-2019-6d871ae48f)
 End-user tools for the Clam Antivirus scanner

Update Information:

- Update to 0.101.3    Clam AntiVirus is an anti-virus toolkit for UNIX. The
main purpose of this software is the integration with mail servers (attachment
scanning). The package provides a flexible and scalable multi-threaded daemon, a
command line scanner, and a tool for automatic updating via Internet. The
programs are based on a shared library distributed with the Clam AntiVirus
package, which you can use with your own software. The virus database is based
on the virus database from OpenAntiVirus, but contains additional signatures
(including signatures for popular polymorphic viruses, too) and is KEPT UP TO
DATE.




 future-0.17.1-0.3.20190506git23989c4.el8 (FEDORA-EPEL-2019-39e398815a)
 Easy, clean, reliable Python 2/3 compatibility

Update Information:

- New package




 libbinio-1.4-31.el8 (FEDORA-EPEL-2019-fbf16ce287)
 A software library for binary I/O classes in C++

Update Information:

This binary I/O stream class library presents a platform-independent way to
access binary data streams in C++. The library is hardware independent in the
form that it transparently converts between the different forms of machine-
internal binary data representation. It further employs no special I/O protocol
and can be used on arbitrary binary data sources.




 libcue-2.2.1-2.el8 (FEDORA-EPEL-2019-e93b4d9691)
 Cue sheet parser library

Update Information:

Libcue is intended for parsing a so-called cue sheet from a char string or a
file pointer. For handling of the parsed data a convenient API is available.




 minisign-0.8-2.el8 (FEDORA-EPEL-2019-b080204bb5)
 A dead simple tool to sign files and verify digital signatures

Update Information:

use macros for Source0




 msoffcrypto-tool-4.10.0-2.el8 (FEDORA-EPEL-2019-b660a4f97c)
 Python tool for decrypting MS Office files with passwords or other keys

Update Information:

The msoffcrypto-tool (formerly ms-offcrypto-tool) is a Python tool and library
for decrypting encrypted Microsoft Office files with password, intermediate key,
or private key which generated its escrow key.




 python-easygui-0.96-25.el8 (FEDORA-EPEL-2019-b0cbd60db0)
 Very simple, very easy GUI programming in Python

[Bug 1739331] rebuilding src.rpm failed due to missing website

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Link ID||CPAN 102916



--- Comment #1 from Emmanuel Seyman  ---
This is bug #102916 on CPAN. Disabling the test seems the way to go since we
don't run it anyway.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org