Re: Mass Rebuild for Fedora 28

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2018-02-13 at 20:14 +, Samuel Rakitničan wrote:
> Strange error with camotics:
> 
> Error: 
>  Problem: package cairo-devel-1.15.10-2.fc28.x86_64 requires
> pkgconfig(gobject-2.0), but none of the providers can be installed
>   - conflicting requests
>   - nothing provides /usr/bin//usr/bin/python3 needed by glib2-devel-2.55.2-
> 1.fc28.x86_64

Just rebuild, this bug has been fixed for quite some time already.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqD3dsACgkQaVcUvRu8
X0wwdQ//Y5n/HlFZoItCLQcvOBEECrQSjYyS6WDzQ9PuaKJKh33bF1k7KYEWjtPf
+5lJKs3oJiXL7kSmx0cSBzhODVM3b99dX0oCikAXx96EGHu1JzM7u2IzBAAa1vW3
Mkx3lx+z7Sj8m9B2+taX2kBpsQy9VGGpGgaGIbWyb3lo16rItkG2bM+HdKqjHRLF
wYuQjkd/4TA5IGII1KkB/oZkg7TMyz+YqflcDc4CyefGZ28/cuEco0bFPFmtIHdj
HH8/nKiEq5/ftIFP35ZdSs3Vni2ZH/y3E8Pw+94K637ZkUtgBj69JZxV5XLFL2FQ
nbUqAjjzVNu2kcuDYNBS9qOPOrURhnwPVF7QRyN5PZxtPkc7YjzqE4Dwarp8uzRE
rQdzBB7UAlsMwDSkbCOC7RnudzIJIOAXzY+cV2tJwasqHsGXbynDgHW4YwZfKARG
R4Djc1mNrBmaomD2RRflDBlL2uO+f1GvqDscLerKor6ybcUV1K5cIZKoHjYHL98i
p+7ySNEXeZ749xDWkVnwvVUshRUXbtcTF6qW5/nTdEcHh9wDNdV+nzEI9j0ctVM8
J83rrzTXDNyQ/P8r83CTUYjLztCU+0sR+MskUh1rVr30E8WfiX39PDWCSfbxKCcJ
/zCpXA8zXSE1MwJ4FGhy3PxwW/VNgkKQAwqd0bHI3BJIZV+HSDc=
=20Xz
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: clang -mcet -fcf-protection (was: Re: Mass Rebuild for Fedora 28)

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2018-02-13 at 10:36 +, Daniel P. Berrangé wrote:
> On Tue, Feb 13, 2018 at 10:18:05AM +, Richard W.M. Jones wrote:
> > 
> > My build of american-fuzzy-lop fails because clang doesn't
> > understand the ‘-mcet -fcf-protection’ flags which seem to be
> > added by RPM.
> > 
> >   clang -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-
> > gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> > -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection 
> > -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign
> > -DAFL_PATH=\"/usr/lib64/afl\" -DBIN_PATH=\"/usr/bin\"
> > -DVERSION=\"2.52b\"  afl-clang-fast.c -o ../afl-clang-fast 
> >   clang-6.0: error: unknown argument: '-mcet'
> >   clang-6.0: error: unknown argument: '-fcf-protection'
> > 
> > (https://koji.fedoraproject.org/koji/taskinfo?taskID=25000571)
> > 
> > This suggests a bug in our RPM configuration.
> 
> Not much more info about what these flags do, but the change was recorded
> here with an opaque "Intel says we need this" rationale:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1538725
> 
> redhat-rpm-config flags have usually been compatible with both gcc and
> clang, so if there's no newer clang that supports this, it feels like
> we've a few options
> 
>  1. Have the RPM spec for apps using clang filter these flags out of
> the RPM cflags. 
>  2. Revert the change in redhat-rpm-config so we're compatible with
> clang
>  3. Provide a second macro in redhat-rpm-config that is the cut down
> set of cflags which still work with clang, that apps can opt for.

As long as it doesn't break builds, I don't think we need this separation. If
clang is simply ignoring flags, let it do that 
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqD3YYACgkQaVcUvRu8
X0xrhw/+IXyGgcnNd3vJoQJJr25sg23FKP/Y4iPDEFf1Le96/GM1FiFyD5vFgHsS
Y5n8MQwzMpW/1QX/T8x2+EomQdnkXZG0EDG6smuOGKeEENiuAjuujULyrTQWEpr1
UychOFEdn6ZJJTUsqKn4LOlCwAvuUdvrgT/B3JyF5iFaKV6VTU76vDjoa4HjkyQY
lohRWFGNamb5fTpfP2it6CcDCOBV3ABN7TVAUd/v1sXP+FjrXBVk2DBZIeoDs52W
BP+ftXQaEsgdb6RN5IStvQ4d4TOcmEjun3bPzUU8w2ldPGJfJ6QPyrj0Tvye18XC
gDrVbjKvFQdZAFNYWWO5SEakb3ZWgzKzUHAi2MOZNcA4D+hgny0E+uPPdq5O6qnc
KlFM7QZTpQO9oZAqvn/2EDI10XJdzXPVVtp992Vbgm01nDuVhr6XeaKbyEnBErk5
pE1/voR5Vw8Cx5nu+yFBrn6VPSQVJFjs+iY5DOH0jS2WAF9J9npIsTl0FdpsaaWC
Uzu6Q3KwQs4TEoF5Xn/Z98gt/tUb5QK2meQfUz55Arm1x4Zp5KigaHUv99lpBP5n
sixBJS54rorf0LlK+Fi6jglrJAIdXMCvlJ4NIUms5gN6OCaoshO5baKu7vCv26uc
44yvhaVupmYJDwyB/UG6KuxsCPLyzQ7HEMRUhNfXJ++QYkCVPAM=
=frLg
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1544065] perl-Net-DNS-1.15 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Net-DNS-1.15-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-2697615f0c

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

[Bug 1544065] perl-Net-DNS-1.15 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-Net-DNS-1.15-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-344ecfd015

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

[Bug 1315525] perl-Net-DNS-1.06 is available

[bugzilla]

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

Paul Wouters  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |EOL
Last Closed||2018-02-13 21:12:31



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

Orphaning scram

[Olzhas Rakhimov]

Hi,

I orphaned scram.

My hard drive w/ Fedora died a while ago.
Lost all my packaging setup and never caught up w/ the new packaging changes :(

There's an open "upgrade-request" [bug 1544524] that I cannot fix:
https://bugzilla.redhat.com/show_bug.cgi?id=1544524

I'm an upstream developer
and willing to help out anyone wishing to adopt this package.

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

Re: Escaping macros in %changelog

[David Malcolm]

On Tue, 2018-02-13 at 12:07 -0800, Adam Williamson wrote:
> On Mon, 2018-02-12 at 11:59 -0500, David Cantrell wrote:
> > The dist-git changelogs are mostly noise and I would prefer better
> > organized information about impacts to users and developers.  Like
> > tell
> > me what things changed in the new glibc package, not that the glibc
> > RPM
> > has been upgraded to the new release.  I can figure out that part
> > myself.
> 
> As an alternative perspective on this, I am *constantly* frustrated
> by
> the lack of detail in SCM commit messages, and would much prefer far
> more of it. I frequently find myself wanting to know exactly why
> someone did something seven years ago, and find it entirely
> impossible
> to answer the question from the information available.

As well as %changelog, there's this wonderful other syntactical
construct in rpm spec files called a "comment" ;-)

Joking aside, and I haven't done much packaging in some time, but back
in the day I was always struck my how terse most specfiles seemed to
be, and I made a point of trying to properly comment mine.  I think
some of this may be the result of dealing with frustrating build
issues: "yes! it finally worked, commit it and move on!"

Specfiles are code, and IMHO ought to be commented, following the usual
best-practices for code comments.  If nothing else, a bug ID is way
better than nothing - or a URL to a discussion - but ideally summarize
the rationale for anything surprising in a comment.

It's not an obfuscated code competition.

Hope this is constructive
Dave
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Removal of BuildRoot

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Just a small heads up, BuildRoot tag is not needed since RHEL6 (which is oldest
supported one nowadays, it's been year or so after EL5 retirement). And we
don't support EL5 anymore, so...

I wanted to send this heads up before I actually did that, but I hit "enter"
button too early.

Anyway, this is straitghtforward change, so no one should notice anything
(apart from one commit with, hopefully, useful description in their
repositories) 
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqDYSgACgkQaVcUvRu8
X0yzGw//R1CxLUKv24mETURYToIg3QTPWGOU1X6nOg0zBmT17AVCYOWr559+FYN3
WSgNwaVgO5iOkr2PufX7Zx8n7N0LitAKFr9zF/eV2kaSd2+NyHgKLL8uKDQtXVvQ
GWLISIP+BC/W0u+kuGXvBFF4Olp3wrUnB6+Jxb4EI70UbQsyJN+mI7wnbnnW+AWJ
OIV4gtsx1nXxD5XxjqHJEIkzXaFpnZxQ5EE0FNT1lwE5SJo9eSArqM/1M2i/dK0W
/85jAteSg8PEVMRMhGq/nLWIE8FCFk9r872SEbMFQZrlCw25Ykax5ef/I26T00ev
l+rcCMOHobGabxSf1QJV2YvUUnirDuTBHhyUPIfGPlSykc3AcyJY0C/XThnhUmwf
cnr66gOsZEAqGs4fpoUJ3akXcdrC3G3+04GmShdP/7fYnxmmCNxtQ1u/ZPxqz605
/rDI0SH9fywZuP0DX2Xk6YgCLrschIZ5W8+jajmJ9DbU3TdKkueLTKrfZgXiPz+d
dUsjUzp/+bVdeM0MvWRibxYjijBzSPGfi5lv0HPN9gg8884MRAEHFcMqHPkcEnC8
SPkhgT8YmFu6sVtmY0/Wb+SGYm/etlj/g5QhqTy0HyoGZEpD8+eJw91aW/rWsLIh
5d738JfsLUoOpl/iFGxc1MdyNSPNayRi5vaTbkn5vBd7nLR22IA=
=EhRC
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass Rebuild for Fedora 28

[Adam Williamson]

On Tue, 2018-02-13 at 09:37 +, Peter Robinson wrote:
> > > 
> About 5K packages is very high for the average mass rebuild failures
> (around 25% of the total source packages), there was a dist-git outage
> during the mass rebuild and I wonder if a bunch of these were affected
> by that issue, any chance rel-eng could check the logs to see if there
> were timeouts/503 errors against a bunch of the failures?

Possibly related, I had a bunch of failures trying to build os-autoinst 
on Friday which were not the package's fault; seemed like the s390x
build kept failing or hanging. It built fine this morning.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Usefulness of `copr mock-config ` feature?

[Michal Novotny]

On Tue, Feb 13, 2018 at 9:51 PM, Michal Novotny  wrote:

> Hello,
>
> On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček 
> wrote:
>
>> On 2018-02-13 11:47, Pavel Raiskup wrote:
>>
>>> Sorry, I wanted to CC fedora devel before, forwarding.
>>>
>>> Pavel
>>>
>>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
>>>
 Because we are unable to find a consensus on implementation details,
 it's
 likely we'll drop this feature from copr API and it will be probably a
 bit
 more complicated to setup mock chroot for local tests in future (you'll
 need to have builder machine with copr-rpmbuild installed, which brings
 a
 lot more runtime dependencies at least).

  From user perspective, do you mind if we dropped `copr mock-config`
 command?


>> I didn't know this command existed, but there were multiple times in the
>> past where I wished something like this had been available (It didn't exist
>> back then). It was usually situation like this: "Hi, I'm trying to build
>> $package in $copr and it fails because of $build_tool that you maintain,
>> can you help me?". And since I had no idea how his copr was set up, it took
>> me a lot of time before I was able to reproduce the problem. So, I would
>> find the feature useful, especially in instances outside Fedora, which
>> usually have more complex configurations.
>> If it had to be dropped, I'd appreciate if copr could display the
>> configuration of given project for non-owners. That way it would be easier
>> to construct my own config, without trying to guess stuff based on the logs.
>>
>
> First, thanks for your input. This is very useful information for us.
> Next, I would like to ask if it was ok to put all the functionality about
> build-testing and building itself into just a single package:
> copr-rpmbuild. I think having things on just one place can help us focus on
> doing them really well and as the copr-rpmbuild tool is already responsible
> for building, I think it would be a perfect place to add additional
> build-debugging functionality like printing-out/dumping mock configs,
> enablement to run just a part of the build process, possibility to enter
> the build environment interactively etc. Would this be alright?
>

I need to add that with this tool you really need to know _what_ you are
building to be on the safe side. It is similar to running rpmbuild locally
(unless you are really just dumping mock configs).


>
> Thank you again for your feedback
> Michal
>
>
>>
>> Michael
>> ___
>> copr-devel mailing list -- copr-de...@lists.fedorahosted.org
>> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
>>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass Rebuild for Fedora 28

[Dennis Gilmore]

El mar, 13-02-2018 a las 20:14 +, Samuel Rakitničan escribió:
> Strange error with camotics:
> 
> Error: 
>  Problem: package cairo-devel-1.15.10-2.fc28.x86_64 requires
> pkgconfig(gobject-2.0), but none of the providers can be installed
>   - conflicting requests
>   - nothing provides /usr/bin//usr/bin/python3 needed by glib2-devel-
> 2.55.2-1.fc28.x86_64

that looks like a packaging bug in glib2

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Usefulness of `copr mock-config ` feature?

[Michal Novotny]

Hello,

On Tue, Feb 13, 2018 at 12:54 PM, Michael Šimáček 
wrote:

> On 2018-02-13 11:47, Pavel Raiskup wrote:
>
>> Sorry, I wanted to CC fedora devel before, forwarding.
>>
>> Pavel
>>
>> On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
>>
>>> Because we are unable to find a consensus on implementation details, it's
>>> likely we'll drop this feature from copr API and it will be probably a
>>> bit
>>> more complicated to setup mock chroot for local tests in future (you'll
>>> need to have builder machine with copr-rpmbuild installed, which brings a
>>> lot more runtime dependencies at least).
>>>
>>>  From user perspective, do you mind if we dropped `copr mock-config`
>>> command?
>>>
>>>
> I didn't know this command existed, but there were multiple times in the
> past where I wished something like this had been available (It didn't exist
> back then). It was usually situation like this: "Hi, I'm trying to build
> $package in $copr and it fails because of $build_tool that you maintain,
> can you help me?". And since I had no idea how his copr was set up, it took
> me a lot of time before I was able to reproduce the problem. So, I would
> find the feature useful, especially in instances outside Fedora, which
> usually have more complex configurations.
> If it had to be dropped, I'd appreciate if copr could display the
> configuration of given project for non-owners. That way it would be easier
> to construct my own config, without trying to guess stuff based on the logs.
>

First, thanks for your input. This is very useful information for us. Next,
I would like to ask if it was ok to put all the functionality about
build-testing and building itself into just a single package:
copr-rpmbuild. I think having things on just one place can help us focus on
doing them really well and as the copr-rpmbuild tool is already responsible
for building, I think it would be a perfect place to add additional
build-debugging functionality like printing-out/dumping mock configs,
enablement to run just a part of the build process, possibility to enter
the build environment interactively etc. Would this be alright?

Thank you again for your feedback
Michal


>
> Michael
> ___
> copr-devel mailing list -- copr-de...@lists.fedorahosted.org
> To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Josh Boyer]

On Tue, Feb 13, 2018 at 3:24 PM, Matthew Miller
 wrote:
> On Tue, Feb 13, 2018 at 12:07:27PM -0800, Adam Williamson wrote:
>> > The dist-git changelogs are mostly noise and I would prefer better
>> > organized information about impacts to users and developers.  Like tell
>> > me what things changed in the new glibc package, not that the glibc RPM
>> > has been upgraded to the new release.  I can figure out that part myself.
>> As an alternative perspective on this, I am *constantly* frustrated by
>> the lack of detail in SCM commit messages, and would much prefer far
>> more of it. I frequently find myself wanting to know exactly why
>> someone did something seven years ago, and find it entirely impossible
>> to answer the question from the information available.
>
> I think this is made worse by having three different changelogs in
> three different places (spec file, git, bodhi).

Or 4 if you include bugzilla, where a lot of discussion actually takes place.

Or 5 if you include upstream.

Or 6 if you include devel list posts talking about a general change
that is then done across packages but doesn't reference the original
thread anywhere in git, bugzilla, changelog, or bodhi.

The point is, we have LOTS of places where change information or
discussion occurs.  We should try and have a canonical location for
the *descriptive summary* of these changes/discussions.  I don't think
%changelog lends itself to that.  The git commit log is likely the
best place, but we have nothing to enforce good usage of it.

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

Re: Escaping macros in %changelog

[Matthew Miller]

On Tue, Feb 13, 2018 at 12:07:27PM -0800, Adam Williamson wrote:
> > The dist-git changelogs are mostly noise and I would prefer better
> > organized information about impacts to users and developers.  Like tell
> > me what things changed in the new glibc package, not that the glibc RPM
> > has been upgraded to the new release.  I can figure out that part myself.
> As an alternative perspective on this, I am *constantly* frustrated by
> the lack of detail in SCM commit messages, and would much prefer far
> more of it. I frequently find myself wanting to know exactly why
> someone did something seven years ago, and find it entirely impossible
> to answer the question from the information available.

I think this is made worse by having three different changelogs in
three different places (spec file, git, bodhi).



-- 
Matthew Miller

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

Re: Mass Rebuild for Fedora 28

[Samuel Rakitničan]

Strange error with camotics:

Error: 
 Problem: package cairo-devel-1.15.10-2.fc28.x86_64 requires 
pkgconfig(gobject-2.0), but none of the providers can be installed
  - conflicting requests
  - nothing provides /usr/bin//usr/bin/python3 needed by 
glib2-devel-2.55.2-1.fc28.x86_64
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Escaping macros in %changelog

[Adam Williamson]

On Mon, 2018-02-12 at 11:59 -0500, David Cantrell wrote:
> The dist-git changelogs are mostly noise and I would prefer better
> organized information about impacts to users and developers.  Like tell
> me what things changed in the new glibc package, not that the glibc RPM
> has been upgraded to the new release.  I can figure out that part myself.

As an alternative perspective on this, I am *constantly* frustrated by
the lack of detail in SCM commit messages, and would much prefer far
more of it. I frequently find myself wanting to know exactly why
someone did something seven years ago, and find it entirely impossible
to answer the question from the information available.
-- 
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

Gating test in bodhi failing on dependency check, can't tell why

[David Shea]

https://bodhi.fedoraproject.org/updates/FEDORA-2018-55ac90e798 is the update 
I'm trying to push. The dist.rpmdeplint test is failing, for example with 
https://taskotron.fedoraproject.org/artifacts/all/7207b7c8-10ed-11e8-9d8f-525400fc9f92/task_output/ghc-listsafe-0.1.0.1-1.fc27.x86_64.log

The thing is, it shouldn't be failing. The message is "nothing provides 
libHSarray-0.5.1.1-ghc8.0.2.so needed by ghc-listsafe-0.1.0.1-1.fc27.i686". 
This dependency is definitely available in F27.

$ dnf repoquery --whatprovides 'libHSarray-0.5.1.1-ghc8.0.2.so'
Last metadata expiration check: 0:01:00 ago on Tue 13 Feb 2018 02:21:40 PM EST.
ghc-array-0:0.5.1.1-59.fc27.i686
ghc-array-0:0.5.1.1-60.fc27.i686

There are no issues with installing the package from updates-testing on 32-bit 
or 64-bit F27.

Is this because the package depends on a .so that isn't installed to/usr/lib? 
Did something get mixed up as far 32-bit vs 64-bit? It does seem kind of weird 
that the arch is reported as x86_64 but the error is for the .i686 package. 
Does anyone have any advice?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Python2 stub packages now in EPEL stable

[nicolas . mailhot]

De: "Jason L Tibbitts III" 

> The initial set of stub python2-* packages I created have now made their
> way to EPEL6 and EPEL7 stable, so packages can now depend on
> python2-setuptools, python2-six, python2-pytest and python2-sphinx
> in all releases without having to add conditionals for EPEL.

Awesome progress thank you very much!

I hope that someday EL will stop trying to perpetuate old quirks by default, 
and starts being more forward-looking. I've lost count of the amount of efforts 
poured in SCLs or modules just to avoid touching the EL basesystem.

Regards,

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

Re: Python2 stub packages now in EPEL stable

[Michal Novotny]

On Tue, Feb 13, 2018 at 5:32 PM, Jason L Tibbitts III 
wrote:

> [For those who don't read epel-devel, this is a duplicate of a message
> also posted there.]
>
> The initial set of stub python2-* packages I created have now made their
> way to EPEL6 and EPEL7 stable, so packages can now depend on
> python2-setuptools, python2-six, python2-pytest and python2-sphinx
> in all releases without having to add conditionals for EPEL.
>

Thank you!


>
> Feel free to suggest additional packages; I will be happy to create
> them.
>
> See https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages for
> more information.
>
>  - J<
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1542731] Please provide a package for EPEL7

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Sys-Statistics-Linux-0.66-14.el7 has been pushed to the Fedora EPEL 7
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-d861e58814

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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2018-02-14 from 18:00:00 to 19:00:00 GMT
   At fedora-meet...@irc.freenode.net

The meeting will be about:
The EPEL Steering Committee will have a weekly meeting to cover current tasks 
and problems needed to keep EPEL going.


Source: https://apps.fedoraproject.org/calendar/meeting/8724/

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

[Bug 1541674] perl-Email-Address-XS-1.02 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Email-Address-XS-1.02-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

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

Qt 5.10.1 coming to rawhide

[Rex Dieter]

Sorry for the late notice...

kde sig is working to import Qt 5.10.1 into rawhide starting today, so there 
will be some related rawhide buildroot broken dependencies until this task 
is complete

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

Re: Mass Rebuild for Fedora 28

[Kevin Fenzi]

On 02/12/2018 11:16 PM, Vascom wrote:
> I am see that my package libzen in need rebuild list. but I can't find
> failed koji build for it to see logs.
> Where I can find failed build? Or I must run it manually?

There were some packages missed because pkgs01 had a short outage.
I suspect yours is one of those, so just bump the release and do a new
build and it should disappear from the list.

kevin
--
> 
> вт, 13 февр. 2018 г. в 3:37, Mamoru TASAKA :
> 
>> Dennis Gilmore wrote on 02/13/2018 08:06 AM:
>>> Hi All,
>>>
>>> We have now completed the automated part of the Fedora 28 mass rebuild,
>>> The details for the scheduled mass rebuild for Fedora 28 can be found
>>> here[1]. The failure page for the rebuilds can be found here[3] and the
>>> full list of packages that are needing rebuilding can be found here[4].
>>>   The needs rebuild list includes packages that failed to get submitted
>>> to koji for various reasons, things like the spec bumping failing due
>>> to incomplete or incorrect retirement
>>>
>>>
>>> [1] https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
>>> [2] https://kojipkgs.fedoraproject.org/mass-rebuild/f28-failures.html
>>> [3] https://kojipkgs.fedoraproject.org/mass-rebuild/f28-need-rebuild.ht
>>> ml
>>> [4] https://fedoraproject.org/wiki/Releases/28/Schedule
>>>
>>
>> f28-need-rebuild.html [4] shows that most of "need-rebuild" packages are
>> assigned to rel-eng, and does not seem to show the "real" owner of packages
>> correctly.
>>
>> Regards,
>> Mamoru
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1544753] perl-RDF-NS-20180213 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System <upda...@fedoraproject.org> ---
perl-RDF-NS-20180213-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-6254482e1a

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

Re: "Bodhi is unable to request this update for stabilization: invalid syntax (ssl.py, line 7)"

[Kevin Fenzi]

On 02/13/2018 01:02 AM, Petr Pisar wrote:
> On 2018-02-13, Richard W.M. Jones  wrote:
>> What does it mean?
>>
> I opened .

A config change was pushed that was missing a , in it so the config was
invalid.

This was fixed last night.

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora27: NFS v4 terrible write performance, is async working

[Stephen John Smoogen]

On 13 February 2018 at 02:01, Terry Barnaby  wrote:

>> Yes: http://nfs.sourceforge.net/#faq_a8
>>
>> --b.
>
>
> Quite right, it was network limited (disk vs network speed is about the
> same). Using a slower USB stick disk shows that fsync() is not working with
> a NFSv4 "async" export.
>
> But why is this ? It just doesn't make sense to me that fsync() should work
> this way even with an NFS "async" export ? Why shouldn't it do the right
> thing "synchronize a file's in-core state with storage device" (I don't
> consider an NFS server a storage device only the non volatile devices it
> uses). It seems it would be easy to flush the clients write buffer to the
> NFS server (as it does now) and then perform the fsync() on the server for
> the file in question. What am I missing ?
>

You seem to be missing the part where several people have told you
that the async option in the server is misnamed. NFS server async()
was named that ~20 years ago (?) to match requirements from sites that
wanted NFSv2 'look and feel' with NFSv3 and has been constantly called
that since because changing it would break people's setups.

What you are wanting may be useful as a renamed and different feature,
but it really needs to be done on the NFS kernel mailing list versus
here. While you have 2 NFS oriented kernel developers here, they are
only a subset of the people who would need to look at it and see if it
could be done.

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

Python2 stub packages now in EPEL stable

[Jason L Tibbitts III]

[For those who don't read epel-devel, this is a duplicate of a message
also posted there.]

The initial set of stub python2-* packages I created have now made their
way to EPEL6 and EPEL7 stable, so packages can now depend on
python2-setuptools, python2-six, python2-pytest and python2-sphinx
in all releases without having to add conditionals for EPEL.

Feel free to suggest additional packages; I will be happy to create
them.

See https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages for
more information.

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

Python2 stub packages now in EPEL stable

[Jason L Tibbitts III]

[For those who don't read epel-devel, this is a duplicate of a message
also posted there.]

The initial set of stub python2-* packages I created have now made their
way to EPEL6 and EPEL7 stable, so packages can now depend on
python2-setuptools, python2-six, python2-pytest and python2-sphinx
in all releases without having to add conditionals for EPEL.

Feel free to suggest additional packages; I will be happy to create
them.

See https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages for
more information.

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

Re: Mass Rebuild for Fedora 28

[dennis]

On February 13, 2018 8:24:12 AM CST, "Tomasz Torcz ️"  
wrote:
>On Tue, Feb 13, 2018 at 07:16:01AM +, Vascom wrote:
>> I am see that my package libzen in need rebuild list. but I can't
>find
>> failed koji build for it to see logs.
>> Where I can find failed build? Or I must run it manually?
>
>  I see the same with my "maradns". GIT shows version bump in spec,
>but there is no build in Koji.

Please submit the build in this case. If the srpm for instance failed to create 
there is no task in koji. I do not know why it was not submitted.

Dennis
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Python2 stub packages now in EPEL stable

[Jason L Tibbitts III]

The initial set of stub python2-* packages I created have now made their
way to EPEL6 and EPEL7 stable, so packages can now depend on
python2-setuptools, python2-six, python2-pytest and python2-sphinx
in all releases without having to add conditionals for EPEL.

Feel free to suggest additional packages; I will be happy to create
them.

See https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages for
more information.

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

[Bug 1544753] perl-RDF-NS-20180213 is available

[bugzilla]

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

Fedora Update System <upda...@fedoraproject.org> changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System <upda...@fedoraproject.org> ---
perl-RDF-NS-20180213-1.fc26 has been pushed to the Fedora 26 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-cf99034a15

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

[Bug 1389064] EPEL7 branch missing (required for psad)

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-IPTables-ChainMgr-1.6-
   ||5.el7
 Resolution|--- |ERRATA
Last Closed||2018-02-13 10:58:07



--- Comment #6 from Fedora Update System  ---
perl-IPTables-ChainMgr-1.6-5.el7 has been pushed to the Fedora EPEL 7 stable
repository. If problems still persist, please make note of it in this bug
report.

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

Re: HEADS UP: upcoming giflib-5.1.4 update in rawhide

[Sandro Mani]

The giflib-5.1.4 update is mostly done now, three packages failed to 
build hitting unrelated issues:


* java-9-openjdk 
(https://koji.fedoraproject.org/koji/taskinfo?taskID=25000111)

error: cannot access module-info
  bad class file: 
/builddir/build/BUILD/java-9-openjdk-9.0.4.11-6.fc28.x86_64/openjdk/build-debug/jdk/modules/java.transaction/module-info.class
    module name java.management does not match expected name 
java.transaction
    Please remove or make sure it appears in the correct subdirectory 
of the classpath.


* mathgl (https://koji.fedoraproject.org/koji/taskinfo?taskID=25000348)
assertion falure running 
BUILD/mathgl-2.4.1/x86_64-redhat-linux-gnu_serial/examples/mgl_example 
-kind=light:

#0  0x74ac6f4b in raise () from /lib64/libc.so.6
#1  0x74ab1591 in abort () from /lib64/libc.so.6
#2  0x55701882 in std::__replacement_assert 
(__condition=0x55807820 "__builtin_expect(__n < this->size(), true)",
    __function=, __line=950, __file=0x55807850 
"/usr/include/c++/8/bits/stl_vector.h")

    at /usr/include/c++/8/x86_64-redhat-linux/bits/c++config.h:2389
#3  std::vector::operator[] (__n=5, 
this=0x55b28da0) at /usr/include/c++/8/bits/stl_vector.h:950
#4  mglCanvas::col2int (this=this@entry=0x55b28af0, p=..., 
r=r@entry=0x7221fac4 "", obj_id=obj_id@entry=-9)

    at /home/sandro/rpmbuild/BUILD/mathgl-2.4.1/src/pixel.cpp:279
#5  0x557041ef in mglCanvas::trig_draw (this=0x55b28af0, 
p1=..., p2=..., p3=..., anorm=false, d=)

    at /home/sandro/rpmbuild/BUILD/mathgl-2.4.1/src/pixel.cpp:493
#6  0x55711fbf in mglCanvas::glyph_fill (this=0x55b28af0, 
phi=, pp=..., f=, g=..., d=0x7221fdc0)

    at /home/sandro/rpmbuild/BUILD/mathgl-2.4.1/src/pixel.cpp:1118
#7  0x5570c542 in mglCanvas::glyph_draw 
(this=this@entry=0x55b28af0, P=..., d=d@entry=0x7221fdc0)

    at /home/sandro/rpmbuild/BUILD/mathgl-2.4.1/src/pixel.cpp:1073
#8  0x5570d043 in mglCanvas::pxl_primdr(long, long, void const*) 
[clone ._omp_fn.7] () at 
/home/sandro/rpmbuild/BUILD/mathgl-2.4.1/src/pixel.cpp:132

#9  0x7529cd8e in gomp_thread_start () from /lib64/libgomp.so.1
#10 0x74e56574 in start_thread () from /lib64/libpthread.so.0
#11 0x74b8a31f in clone () from /lib64/libc.so.6

* emacs (https://koji.fedoraproject.org/koji/buildinfo?buildID=1043555)
aarch64 specific failure:
    /bin/sh: line 4:  7602 Segmentation fault  (core dumped) 
EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file 
--no-site-lisp -l autoload --eval '(setq autoload-ensure-writable t)' 
--eval '(setq autoload-builtin-package-versions t)' --eval '(setq 
generated-autoload-file (expand-file-name (unmsys--file-name 
"../../lisp/loaddefs.el")))' -f batch-update-autoloads ../../lisp 
../../lisp/calc ../../lisp/calendar ../../lisp/cedet 
../../lisp/cedet/ede ../../lisp/cedet/semantic 
../../lisp/cedet/semantic/analyze ../../lisp/cedet/semantic/bovine 
../../lisp/cedet/semantic/decorate ../../lisp/cedet/semantic/symref 
../../lisp/cedet/semantic/wisent ../../lisp/cedet/srecode 
../../lisp/emacs-lisp ../../lisp/emulation ../../lisp/erc 
../../lisp/eshell ../../lisp/gnus ../../lisp/international 
../../lisp/language ../../lisp/leim ../../lisp/leim/ja-dic 
../../lisp/leim/quail ../../lisp/mail ../../lisp/mh-e ../../lisp/net 
../../lisp/nxml ../../lisp/org ../../lisp/play ../../lisp/progmodes 
../../lisp/textmodes ../../lisp/url ../../lisp/vc

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

Re: Mass Rebuild for Fedora 28

[Tomasz Torcz ️]

On Tue, Feb 13, 2018 at 07:16:01AM +, Vascom wrote:
> I am see that my package libzen in need rebuild list. but I can't find
> failed koji build for it to see logs.
> Where I can find failed build? Or I must run it manually?

  I see the same with my "maradns". GIT shows version bump in spec,
but there is no build in Koji.

-- 
Tomasz TorczTo co nierealne -- tutaj jest normalne.
xmpp: zdzich...@chrome.pl  Ziomale na życie mają tu patenty specjalne.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: clang -mcet -fcf-protection

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 13 February 2018 at 14:27, Florian Weimer wrote:
> On 02/13/2018 11:36 AM, Daniel P. Berrangé wrote:
> > redhat-rpm-config flags have usually been compatible with both gcc and
> > clang, so if there's no newer clang that supports this, it feels like
> > we've a few options
> > 
> >   1. Have the RPM spec for apps using clang filter these flags out of
> >  the RPM cflags.
> >   2. Revert the change in redhat-rpm-config so we're compatible with
> >  clang
> >   3. Provide a second macro in redhat-rpm-config that is the cut down
> >  set of cflags which still work with clang, that apps can opt for.
> 
> You forgot:
> 
> 4. Compile the package with GCC (porting it if necessary).
> 
> GCC is the Fedora system compiler, after all.

The Packaging Guidelines say this, too:
https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler

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

Re: clang -mcet -fcf-protection

[Florian Weimer]

On 02/13/2018 11:36 AM, Daniel P. Berrangé wrote:

redhat-rpm-config flags have usually been compatible with both gcc and
clang, so if there's no newer clang that supports this, it feels like
we've a few options

  1. Have the RPM spec for apps using clang filter these flags out of
 the RPM cflags.
  2. Revert the change in redhat-rpm-config so we're compatible with
 clang
  3. Provide a second macro in redhat-rpm-config that is the cut down
 set of cflags which still work with clang, that apps can opt for.


You forgot:

4. Compile the package with GCC (porting it if necessary).

GCC is the Fedora system compiler, after all.

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

Re: clang -mcet -fcf-protection

[Florian Weimer]

On 02/13/2018 11:46 AM, Tom Hughes wrote:

Given that -mcet seems to turn on extra instructions is this not an
issue for compatibility with older processors? or are they sequences
which decode as no-ops on older processors?


They are NOPs on all current CPUs.  They trap on some older CPUs, but we 
coordinated this change with the x86 SIG to make sure that it matches 
their requirements.


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

Re: Escaping macros in %changelog

[Daniel P . Berrangé]

On Tue, Feb 13, 2018 at 08:18:20AM -0500, Neal Gompa wrote:
> On Tue, Feb 13, 2018 at 8:08 AM, Randy Barlow
>  wrote:
> > On 02/12/2018 08:00 PM, Michal Schorm wrote:
> >> The changelogs are long ass hell.
> >> What about keeping just 2 latest releases in it and deleting the rest?
> >> (It will be still kept in GIT history)
> >> 2 releases could be 2-
> >
> > I usually trim my changelogs to the last year of entries. It's kinda
> > arbitrary, but it does keep it from getting too insane and it's easy.
> >
> >
> 
> What I don't get is why we don't just set RPM to trim the changelog
> automatically for the binary RPMs.
> 
> Mageia does this to keep the payload sizes sane:
> http://gitweb.mageia.org/software/rpm/rpm-setup/tree/macros.in#n22

That's good, but it is still worth trimming the actual changelogs too.
It is pointless accumulating 10 years worth of %changelog in the .spec
file in dist-git. Every time we branch rawhide, we should have something
that culls all changelogs from the specs in 'master' that are older
than 1 year.

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

Re: Escaping macros in %changelog

[Neal Gompa]

On Tue, Feb 13, 2018 at 8:08 AM, Randy Barlow
 wrote:
> On 02/12/2018 08:00 PM, Michal Schorm wrote:
>> The changelogs are long ass hell.
>> What about keeping just 2 latest releases in it and deleting the rest?
>> (It will be still kept in GIT history)
>> 2 releases could be 2-
>
> I usually trim my changelogs to the last year of entries. It's kinda
> arbitrary, but it does keep it from getting too insane and it's easy.
>
>

What I don't get is why we don't just set RPM to trim the changelog
automatically for the binary RPMs.

Mageia does this to keep the payload sizes sane:
http://gitweb.mageia.org/software/rpm/rpm-setup/tree/macros.in#n22

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

Re: Escaping macros in %changelog

[Randy Barlow]

On 02/12/2018 08:00 PM, Michal Schorm wrote:
> The changelogs are long ass hell.
> What about keeping just 2 latest releases in it and deleting the rest?
> (It will be still kept in GIT history)
> 2 releases could be 2-

I usually trim my changelogs to the last year of entries. It's kinda
arbitrary, but it does keep it from getting too insane and it's easy.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1544753] perl-RDF-NS-20180213 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System <upda...@fedoraproject.org> ---
perl-RDF-NS-20180213-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-cf99034a15

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

[Bug 1544753] perl-RDF-NS-20180213 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System <upda...@fedoraproject.org> ---
perl-RDF-NS-20180213-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-6254482e1a

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

[Bug 1544753] perl-RDF-NS-20180213 is available

[bugzilla]

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

Petr Pisar <ppi...@redhat.com> changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-RDF-NS-20180213-1.fc28



--- Comment #1 from Petr Pisar <ppi...@redhat.com> ---
An enhancement release suitable for all Fedoras.

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

[Bug 1542721] Please provide a package for EPEL7

[bugzilla]

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



--- Comment #10 from Ralf Corsepius  ---
(In reply to Matthew Miller from comment #9)
> I agree -- Ralf, this is by no means an acceptable way to act towards new
> people in Fedora, and your comments about "noobs" are way off base.
Matthew, please note that I did not accuse Robert-André in person.

I was talking about a general tendency in Fedora, I consider not to be helpful.

To me, Robert-André is a complete unknown, I've never heard of before who
popped out of blue sky, despite I am monitoring almost everything esp. related
to perl-packaging in Fedora, ever since Fedora exists.

That said, Robert-André, please take my appologies, I did not mean to offend
you by any means.

> Robert-André is a member of the packaging group in good standing. Please add
> him as a committer so that he can work on the EPEL packages.
No idea, how to do this.

https://src.fedoraproject.org/rpms/perl-Locale-Maketext-Lexicon/
leaves me completely clueless.

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

[Bug 1544753] New: perl-RDF-NS-20180213 is available

[bugzilla]

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

Bug ID: 1544753
   Summary: perl-RDF-NS-20180213 is available
   Product: Fedora
   Version: rawhide
 Component: perl-RDF-NS
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 20180213
Current version/release in rawhide: 20170111-5.fc28
URL: http://search.cpan.org/dist/RDF-NS/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/10759/

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

[Bug 1542721] Please provide a package for EPEL7

[bugzilla]

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



--- Comment #13 from Ralf Corsepius  ---
(In reply to Matthew Miller from comment #12)
> This probably is not the proper forum for hashing out whatever "general
> tendency" you're talking about,
Agreed, this is not the appropriate forum.

> but no matter what that is, it's important
> for all Fedora contributors to be welcoming to new users — and people in
> leadership positions in Fedora packaging need to hold themselves to the
> highest standard in that regard.
That's a point, I do not agree with and have never agreed with. Fedora should
be selective about the technical skills of its contributors and accept not
"everybody".

> The problem with "My actual point is I do not want Fedora to be furtherly
> run down by noobs." is not that someone might be offended, but that it is
> discouraging to new people in  Fedora. Especially in conjunction with
> refusing a request, that gives the distinct impression that Fedora does not
> welcome new contributors.
> 
> Fedora is a big project and it's incredibly likely that there will be people
> we don't recognize. It's best to assume good intentions.
Put yourself into my position: A person, which has been completely unknown to
me dropped out of the blue and requested an EPEL7 branch. Something many people
have done before. Many of them "hit the wall", when they realized that this is
not a easy task. Actually, this is the reason why EPEL - esp. wrt. perl modules
- is far behind Fedora (with all consequences: insecure, broken, outdated)

Another problem related to this: Unlike pkgdb, pagure lacks the concept of
per-branch maintainers. This means to grant the person full access of the
package.

> On the technical side:
> 
> https://fedoraproject.org/wiki/Infrastructure/
> WhatHappenedToPkgdb#How_do_I_give_a_user_commit_access_to_a_dist-git_repo.3F
Sigh. This is a parent page of what left me clueless above. You actually only
understand it when you already know it.

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

Re: Usefulness of `copr mock-config ` feature?

[Michael Šimáček]

On 2018-02-13 11:47, Pavel Raiskup wrote:

Sorry, I wanted to CC fedora devel before, forwarding.

Pavel

On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:

Because we are unable to find a consensus on implementation details, it's
likely we'll drop this feature from copr API and it will be probably a bit
more complicated to setup mock chroot for local tests in future (you'll
need to have builder machine with copr-rpmbuild installed, which brings a
lot more runtime dependencies at least).

 From user perspective, do you mind if we dropped `copr mock-config` command?



I didn't know this command existed, but there were multiple times in the 
past where I wished something like this had been available (It didn't 
exist back then). It was usually situation like this: "Hi, I'm trying to 
build $package in $copr and it fails because of $build_tool that you 
maintain, can you help me?". And since I had no idea how his copr was 
set up, it took me a lot of time before I was able to reproduce the 
problem. So, I would find the feature useful, especially in instances 
outside Fedora, which usually have more complex configurations.
If it had to be dropped, I'd appreciate if copr could display the 
configuration of given project for non-owners. That way it would be 
easier to construct my own config, without trying to guess stuff based 
on the logs.


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

[Bug 1544588] perl-SVG-2.83 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-SVG-2.83-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-02-13 06:35:23



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

Re: Escaping macros in %changelog

[Till Maas]

On Sat, Feb 10, 2018 at 10:25:48PM +0100, David Sommerseth wrote:

> I personally find it abusing shared resources throwing builds at it which has
> not been tested first.  So I prefer to do local mockbuilds first, simply to
> lessen the load on shared resources.  I'm not saying I haven't tossed failing
> builds at koji, that has happened too.  But I generally try to avoid that as
> much as I can.

koji has enough ressources to allow for test builds. You can actually to
test-only builds (so-called stretch builds). IMHO the scarcer resource
is maintainer time, therefore I am all for using as much shared
resources as possible if it frees time for maintainers. See also:
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

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

Re: clang -mcet -fcf-protection

[Jakub Jelinek]

On Tue, Feb 13, 2018 at 10:46:37AM +, Tom Hughes wrote:
> Given that -mcet seems to turn on extra instructions is this not an
> issue for compatibility with older processors? or are they sequences
> which decode as no-ops on older processors?

https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
The instructions are NOPs on older CPUs.

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

Re: Usefulness of `copr mock-config ` feature?

[Pavel Raiskup]

Sorry, I wanted to CC fedora devel before, forwarding.

Pavel

On Tuesday, February 13, 2018 10:54:55 AM CET Pavel Raiskup wrote:
> Because we are unable to find a consensus on implementation details, it's
> likely we'll drop this feature from copr API and it will be probably a bit
> more complicated to setup mock chroot for local tests in future (you'll
> need to have builder machine with copr-rpmbuild installed, which brings a
> lot more runtime dependencies at least).
> 
> From user perspective, do you mind if we dropped `copr mock-config` command?
> 
> Pavel


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

Re: clang -mcet -fcf-protection

[Tom Hughes]

On 13/02/18 10:36, Daniel P. Berrangé wrote:

On Tue, Feb 13, 2018 at 10:18:05AM +, Richard W.M. Jones wrote:


My build of american-fuzzy-lop fails because clang doesn't
understand the ‘-mcet -fcf-protection’ flags which seem to be
added by RPM.

   clang -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables 
-fstack-clash-protection -mcet -fcf-protection -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign 
-DAFL_PATH=\"/usr/lib64/afl\" -DBIN_PATH=\"/usr/bin\" -DVERSION=\"2.52b\"  
afl-clang-fast.c -o ../afl-clang-fast
   clang-6.0: error: unknown argument: '-mcet'
   clang-6.0: error: unknown argument: '-fcf-protection'

(https://koji.fedoraproject.org/koji/taskinfo?taskID=25000571)

This suggests a bug in our RPM configuration.


Not much more info about what these flags do, but the change was recorded
here with an opaque "Intel says we need this" rationale:

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


Here's how the gcc 8 documentation describes -mcet:

 The '-mcet' option turns on the '-mibt' and '-mshstk' options.  The
 '-mibt' option enables indirect branch tracking support and the
 '-mshstk' option enables shadow stack support from Intel
 Control-flow Enforcement Technology (CET). The compiler also
 provides a number of built-in functions for fine-grained control in
 a CET-based application.  See *Note x86 Built-in Functions::, for
 more information.

and -fcf-protection:

'-fcf-protection=[full|branch|return|none]'
 Enable code instrumentation of control-flow transfers to increase
 program security by checking that target addresses of control-flow
 transfer instructions (such as indirect function call, function
 return, indirect jump) are valid.  This prevents diverting the flow
 of control to an unexpected target.  This is intended to protect
 against such threats as Return-oriented Programming (ROP), and
 similarly call/jmp-oriented programming (COP/JOP).

 The value 'branch' tells the compiler to implement checking of
 validity of control-flow transfer at the point of indirect branch
 instructions, i.e.  call/jmp instructions.  The value 'return'
 implements checking of validity at the point of returning from a
 function.  The value 'full' is an alias for specifying both
 'branch' and 'return'.  The value 'none' turns off instrumentation.

 You can also use the 'nocf_check' attribute to identify which
 functions and calls should be skipped from instrumentation (*note
 Function Attributes::).

 Currently the x86 GNU/Linux target provides an implementation based
 on Intel Control-flow Enforcement Technology (CET). Instrumentation
 for x86 is controlled by target-specific options '-mcet', '-mibt'
 and '-mshstk' (*note x86 Options::).

Given that -mcet seems to turn on extra instructions is this not an
issue for compatibility with older processors? or are they sequences
which decode as no-ops on older processors?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: clang -mcet -fcf-protection (was: Re: Mass Rebuild for Fedora 28)

[Daniel P . Berrangé]

On Tue, Feb 13, 2018 at 10:18:05AM +, Richard W.M. Jones wrote:
> 
> My build of american-fuzzy-lop fails because clang doesn't
> understand the ‘-mcet -fcf-protection’ flags which seem to be
> added by RPM.
> 
>   clang -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong 
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection 
> -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/lib64/afl\" 
> -DBIN_PATH=\"/usr/bin\" -DVERSION=\"2.52b\"  afl-clang-fast.c -o 
> ../afl-clang-fast 
>   clang-6.0: error: unknown argument: '-mcet'
>   clang-6.0: error: unknown argument: '-fcf-protection'
> 
> (https://koji.fedoraproject.org/koji/taskinfo?taskID=25000571)
> 
> This suggests a bug in our RPM configuration.

Not much more info about what these flags do, but the change was recorded
here with an opaque "Intel says we need this" rationale:

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

redhat-rpm-config flags have usually been compatible with both gcc and
clang, so if there's no newer clang that supports this, it feels like
we've a few options

 1. Have the RPM spec for apps using clang filter these flags out of
the RPM cflags. 
 2. Revert the change in redhat-rpm-config so we're compatible with
clang
 3. Provide a second macro in redhat-rpm-config that is the cut down
set of cflags which still work with clang, that apps can opt for.

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

clang -mcet -fcf-protection (was: Re: Mass Rebuild for Fedora 28)

[Richard W.M. Jones]

My build of american-fuzzy-lop fails because clang doesn't
understand the ‘-mcet -fcf-protection’ flags which seem to be
added by RPM.

  clang -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong 
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection 
-Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/lib64/afl\" 
-DBIN_PATH=\"/usr/bin\" -DVERSION=\"2.52b\"  afl-clang-fast.c -o 
../afl-clang-fast 
  clang-6.0: error: unknown argument: '-mcet'
  clang-6.0: error: unknown argument: '-fcf-protection'

(https://koji.fedoraproject.org/koji/taskinfo?taskID=25000571)

This suggests a bug in our RPM configuration.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1542731] Please provide a package for EPEL7

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Sys-Statistics-Linux-0.66-14.el7 has been submitted as an update to Fedora
EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-d861e58814

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

[Bug 1544581] perl-DBD-Pg-3.7.4 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-DBD-Pg-3.7.4-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2018-02-13 04:55:43



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

[Bug 1544581] perl-DBD-Pg-3.7.4 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-DBD-Pg-3.7.3 is|perl-DBD-Pg-3.7.4 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 3.7.4
Current version/release in rawhide: 3.7.1-1.fc28
URL: http://search.cpan.org/dist/DBD-Pg/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/2809/

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

Re: Mass Rebuild for Fedora 28

[Peter Robinson]

>> We have now completed the automated part of the Fedora 28 mass rebuild,
>> The details for the scheduled mass rebuild for Fedora 28 can be found
>> here[1]. The failure page for the rebuilds can be found here[3] and the
>> full list of packages that are needing rebuilding can be found here[4].
>>   The needs rebuild list includes packages that failed to get submitted
>> to koji for various reasons, things like the spec bumping failing due
>> to incomplete or incorrect retirement
>>
>>
>> [1] https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
>> [2] https://kojipkgs.fedoraproject.org/mass-rebuild/f28-failures.html
>> [3] https://kojipkgs.fedoraproject.org/mass-rebuild/f28-need-rebuild.ht
>> ml
>> [4] https://fedoraproject.org/wiki/Releases/28/Schedule
>>
>
> f28-need-rebuild.html [4] shows that most of "need-rebuild" packages are
> assigned to rel-eng, and does not seem to show the "real" owner of packages
> correctly.

About 5K packages is very high for the average mass rebuild failures
(around 25% of the total source packages), there was a dist-git outage
during the mass rebuild and I wonder if a bunch of these were affected
by that issue, any chance rel-eng could check the logs to see if there
were timeouts/503 errors against a bunch of the failures?

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

Re: "Bodhi is unable to request this update for stabilization: invalid syntax (ssl.py, line 7)"

[Petr Pisar]

On 2018-02-13, Richard W.M. Jones  wrote:
> What does it mean?
>
I opened .

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

Re: Escaping macros in %changelog

[Pavel Raiskup]

On Monday, February 12, 2018 5:59:57 PM CET David Cantrell wrote:
> On 02/09/2018 08:34 AM, Josh Boyer wrote:
> > On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller  
> > wrote:
> >> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
> >>> It seems that a lot of people have %file, %check, %build, %whatsoever
> >>> in their changelog section.
> >>> Is there any reason I should not go and automatically escape them?
> >>
> >> This seems like a lot of churn. If we're going to do this, let's go big
> >> and get rid of RPM changelogs.
> >>
> >> When we have a package update, there are basically two different kinds
> >> of changelog information. Well, three.
> >>
> >> First, there's the upstream changelog. We don't generally do much with
> >> these except maybe package as %doc.
> >>
> >> Second, there's package maintainer changelogs. These are really
> >> redundant with the dist-git log. We don't really need this anymore.
> >> It's just a chore.
> >>
> >> Third, though, there's end-user information. Why should a user care
> >> *This* is redundant with bodhi update info, at least if packagers fill
> >> that out, and it often also duplicates upstream changelogs, *and* it
> >> often also covers things like "fixes CVE-' also carried the
> >> specfile changelog.
> >>
> >> This is neither most helpful for user *nor* ideal for packages. Why
> >> don't we drop changelogs entirely in favor of 1) using the dist-git
> >> logs for specfile maintainers and 2) providing the end-user information
> >> in a different way. This could be through specially formatted log lines
> >> going with the commit, or it could be simply in a standard separate
> >> file (`fedora.user-visible-changes`). Optionally, it could include both
> >> a high level end-user summary, and a detailed description for sysadmins
> >> and the curious.
> >>
> >> Wherever it lives, this would be read by Bodhi, so there's
> >> would be need to enter it more than once. And, perhaps a DNF plugin
> >> could be made to read and display this information for systems
> >> administrators.
> > 
> > I fully support the removal of RPM changelogs.  However, you've missed
> > two cases:
> 
> I will also add that I fully support removal of RPM changelogs.  To me
> it ends up being a very common merge conflict if you are trying to
> backport patches to previous branches and we could fix that by
> eliminating the changelogs entirely.

I don't support full removal.  If any automation goes into pipeline
regarding %changelogs, please let users the freedom to write the
%changelogs manually if they want.  Even if I'm not probably good at it,
I'm fine to write the %changelog entry, and resolve the merge conflicts
(in case of changelog it is matter of less then several seconds with meld,
similar to merge conflicts in Release tag).

As an example, see at GNU upstream repos (e.g. tar, automake, ..) how they
generate ChangeLog from git changelog (gitlog-to-changelog through `make
V=1 ChangeLog` command).  That really requires *a lot* of concentration
during writing git commit messages, and reviews.  Any mistake in commit
message requires another commit with "patch" for gitlog-to-changelog
output.

Yes, if we'll have good protection against mistakes (push-reject policy
for mis-formated git messages, so e.g. provenpackagers won't create patch
work for maintainers), it would be nice _option_ which I would love to
pick in many cases.

Pavel

> > 1) Rawhide, which doesn't go through bodhi
> > 2) Fedora release upgrades, which don't go through bodhi
> > 
> > Now, I would actually LOVE for Rawhide to go through bodhi but
> > whatever.  The release -> release upgrade isn't really solvable that
> > way though.
> > 
> > Someone else suggested changelogs could be inserted during koji build
> > time.  That would be interesting to look into.
> 
> The dist-git changelogs are mostly noise and I would prefer better
> organized information about impacts to users and developers.  Like tell
> me what things changed in the new glibc package, not that the glibc RPM
> has been upgraded to the new release.  I can figure out that part myself.
> 
> Many projects include a NEWS file which summarizes the major changes and
> fixes in a new release.  This is usually nicer to consume than
> changelogs.  Sometimes the summarized changes are in another file.
> Sometimes there's nothing like that.
> 
> Maybe we could mark the relevant changes for that release in the %files
> section.  Like:
> 
> %changes NEWS
> 
> Like a doc macro.  An 'rpm -q --changelog' would just pipe that file
> through the pager.  Or display the path or whatever.  If a package lacks
> a file like that, rpm -q --changelog could just return nothing.
> 
> This also leaves open the option for package maintainers to create their
> own summary files and package readmes, which could be expanded to
> explain specifics about that software on Fedora.
> 
> -- 
> David Cantrell 
> Red Hat, Inc. | 

"Bodhi is unable to request this update for stabilization: invalid syntax (ssl.py, line 7)"

[Richard W.M. Jones]

What does it mean?

Rich.

- Forwarded message from upda...@fedoraproject.org -

The following comment has been added to the libguestfs-1.36.13-1.fc26 update:

bodhi - 2018-02-13 03:01:37.555909 (karma: 0)
Bodhi is unable to request this update for stabilization: invalid syntax 
(ssl.py, line 7)

To reply to this comment, please visit the URL at the bottom of this mail


 libguestfs-1.36.13-1.fc26

  Update ID: FEDORA-2018-49cd53ff36
Release: Fedora 26
 Status: testing
   Type: bugfix
  Karma: 0
   Critpath: True
Request: batched
  Notes: New upstream version 1.36.13. Drop libguestfs-gobject-doc because
   : gtk-doc is no longer provided upstream. Add new man
   : page guestfs-gobject(3) to libguestfs-gobject-devel.
  Submitter: rjones
  Submitted: 2018-01-26 10:55:45.451633
   Comments: bodhi - 2018-01-26 10:55:45.460315 (karma 0)
 This update has been submitted for testing by rjones.
 bodhi - 2018-01-26 19:12:36.703507 (karma 0)
 This update has been pushed to testing.
 bodhi - 2018-02-10 00:00:23.804844 (karma 0)
 This update has reached 14 days in testing and can be
 pushed to stable now if the maintainer wishes
 bodhi - 2018-02-10 07:32:25.932908 (karma 0)
 This update has been submitted for batched by rjones.
 bodhi - 2018-02-13 03:01:37.555909 (karma 0)
 Bodhi is unable to request this update for
 stabilization: invalid syntax (ssl.py, line 7)

  https://bodhi.fedoraproject.org/updates/FEDORA-2018-49cd53ff36

- End forwarded message -

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: "Bodhi is unable to request this update for stabilization: invalid syntax (ssl.py, line 7)"

[Miro Hrončok]

On 13.2.2018 09:00, Richard W.M. Jones wrote:

What does it mean?

Rich.

- Forwarded message from upda...@fedoraproject.org -

The following comment has been added to the libguestfs-1.36.13-1.fc26 update:

bodhi - 2018-02-13 03:01:37.555909 (karma: 0)
Bodhi is unable to request this update for stabilization: invalid syntax 
(ssl.py, line 7)

To reply to this comment, please visit the URL at the bottom of this mail


  libguestfs-1.36.13-1.fc26

   Update ID: FEDORA-2018-49cd53ff36
 Release: Fedora 26
  Status: testing
Type: bugfix
   Karma: 0
Critpath: True
 Request: batched
   Notes: New upstream version 1.36.13. Drop libguestfs-gobject-doc because
: gtk-doc is no longer provided upstream. Add new man
: page guestfs-gobject(3) to libguestfs-gobject-devel.
   Submitter: rjones
   Submitted: 2018-01-26 10:55:45.451633
Comments: bodhi - 2018-01-26 10:55:45.460315 (karma 0)
  This update has been submitted for testing by rjones.
  bodhi - 2018-01-26 19:12:36.703507 (karma 0)
  This update has been pushed to testing.
  bodhi - 2018-02-10 00:00:23.804844 (karma 0)
  This update has reached 14 days in testing and can be
  pushed to stable now if the maintainer wishes
  bodhi - 2018-02-10 07:32:25.932908 (karma 0)
  This update has been submitted for batched by rjones.
  bodhi - 2018-02-13 03:01:37.555909 (karma 0)
  Bodhi is unable to request this update for
  stabilization: invalid syntax (ssl.py, line 7)

   https://bodhi.fedoraproject.org/updates/FEDORA-2018-49cd53ff36

- End forwarded message -



Also here https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbd2b092df

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

[Bug 1544277] perl-Dist-Zilla-6.011 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-Dist-Zilla-6.011-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-98972967f7

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

[Bug 1544287] perl-System-Info-0.057 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|CLOSED  |ON_QA
 Resolution|RAWHIDE |---
   Keywords||Reopened



--- Comment #2 from Fedora Update System  ---
perl-System-Info-0.057-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-23a6c5c28e

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

[Bug 1544162] perl-Dancer-Session-Cookie-0.28 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-Dancer-Session-Cookie-0.28-1.fc27 has been pushed to the Fedora 27 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-9b72549411

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