Koschei on stable branch and testing repository (QA)

[Remi Collet]

Hi,

Please see discussion about using testing package for Koschei to detect
possible breakage "before" the update is pushed to stable.

https://github.com/msimacek/koschei/issues/194

This may have some infrastructure impact


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

Re: Pagure roles at Fedora

[Christopher]

On Thu, Oct 12, 2017 at 12:04 AM Kevin Fenzi  wrote:

> On 10/11/2017 07:23 PM, Christopher wrote:
> > Hi,
> >
> > Pagure seems to play several roles in the Fedora community, but it's a
> bit
> > confusing. Perhaps somebody can respond (or write a Wiki article on the
> > topic) to clear up some confusion.
>
> I can try...
>
> > For example, I hear/read the term "dist-git" a lot, but most of the
> > conversation about that seems to focus on Pagure being used to host
> Fedora
> > source repos. I don't really understand how these terms relate to each
> > other.
>
> dist-git is https://github.com/release-engineering/dist-git
> Basically a setup of git and scripts for hosting a collection of repos +
> lookaside cache. pkgs.fedoraproject.org was/is a example of this.
>
> > Another example: all the documentation for the transition away from Pkgdb
> > seems to reference pagure.io. However, that doesn't appear to be where
> the
> > things have moved to. Rather, things have moved to a different instance
> of
> > Pagure hosted at src.fedoraproject.org. How are these two separate
> > instances of Pagure related to one another, why are they separate, and
> what
> > separate roles do they each serve for Fedora packagers and contributors?
>
> pagure.io is for "upstream" projects and general trackers. This is a
> replacement for fedorahosted.org and similar to github or gitlab.
>
> src.fedoraproject.org is a pagure instance + a pagure dist git extension
> ( https://pagure.io/pagure-dist-git ). It is only for distribution
> packages. It's setup differently to work with the special cases distro
> packages have vs general source code. Things like no issue trackers (we
> use bugzilla), groups synced from fas, ssh keys synced from fas, etc.
>
> > Are there any other instances of Pagure that are relevant to Fedora
> > packagers?
>
> There is a staging instance we use to test new pagure releases:
> https://stg.pagure.io
>
> > Are there any other roles that an existing instance of Pagure should be
> > serving, but currently isn't? For example, I've noticed that
> > src.fedoraproject.org has disabled issues on repos. However, I
> personally
> > would love to use it as an issue tracker instead of Bugzilla. I
> understand
> > that Bugzilla is more integrated with other services, but having issues
> > enabled would be a nice option in the future, as moving issue trackers
> > closer to the source is one of the best things that has come out of the
> > various git hosting services.
>
> We could of course do this, but yeah, there's a bunch of things we use
> bugzilla for right now. Someone would have to look at all those and
> propose something to fesco and get the community to buy in.
>
> > So far, I like Pagure. I also like similar git hosting services, such as
> > GitLab and GitHub, but I don't think we're making the best use of it, if
> > we're customizing separate deployments of it instead of providing a
> generic
> > service and customizing the integrations to it. Perhaps somebody can help
> > explain, with a summary of the choices which have been made and the
> reasons
> > behind those choices, why (for better or worse) this is the direction
> > Fedora is headed?
>
> I did my best above. Feel free to ask more, or wait for better answers
> from Pingou. ;)
>
> kevin
>

Thanks, that definitely helps.

I think the hardest part of being a contributor to Fedora is trying to get
an understanding of how all the backend stuff fits together, so that you
understand where you fit as a contributor. Some tools like `fedpkg` and
`fedrepo_req` can help make certain repetitive tasks easier, but they have
the unfortunate side-effect of obscuring the infrastructure so that it can
be hard to grok.

Can you explain how the branches in Pagure (specifically,
src.fedoraproject.org) map to the new SLAs (after F27), and what backend
pieces are changing to compose a Fedora distribution from these branches
after F27? What infrastructure metadata is stored about branches, so the
right branch is used for composing a particular distribution? And how do
packagers view/track this metadata, as it pertains to the branches in their
repos in Pagure? Does src.fedoraproject.org fit in to this picture at all,
or is all that done outside of that particular Pagure instance (aside from
the git branches themselves, which obviously would exist in those repos)?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pagure roles at Fedora

[Kevin Fenzi]

On 10/11/2017 07:23 PM, Christopher wrote:
> Hi,
> 
> Pagure seems to play several roles in the Fedora community, but it's a bit
> confusing. Perhaps somebody can respond (or write a Wiki article on the
> topic) to clear up some confusion.

I can try...

> For example, I hear/read the term "dist-git" a lot, but most of the
> conversation about that seems to focus on Pagure being used to host Fedora
> source repos. I don't really understand how these terms relate to each
> other.

dist-git is https://github.com/release-engineering/dist-git
Basically a setup of git and scripts for hosting a collection of repos +
lookaside cache. pkgs.fedoraproject.org was/is a example of this.

> Another example: all the documentation for the transition away from Pkgdb
> seems to reference pagure.io. However, that doesn't appear to be where the
> things have moved to. Rather, things have moved to a different instance of
> Pagure hosted at src.fedoraproject.org. How are these two separate
> instances of Pagure related to one another, why are they separate, and what
> separate roles do they each serve for Fedora packagers and contributors?

pagure.io is for "upstream" projects and general trackers. This is a
replacement for fedorahosted.org and similar to github or gitlab.

src.fedoraproject.org is a pagure instance + a pagure dist git extension
( https://pagure.io/pagure-dist-git ). It is only for distribution
packages. It's setup differently to work with the special cases distro
packages have vs general source code. Things like no issue trackers (we
use bugzilla), groups synced from fas, ssh keys synced from fas, etc.

> Are there any other instances of Pagure that are relevant to Fedora
> packagers?

There is a staging instance we use to test new pagure releases:
https://stg.pagure.io

> Are there any other roles that an existing instance of Pagure should be
> serving, but currently isn't? For example, I've noticed that
> src.fedoraproject.org has disabled issues on repos. However, I personally
> would love to use it as an issue tracker instead of Bugzilla. I understand
> that Bugzilla is more integrated with other services, but having issues
> enabled would be a nice option in the future, as moving issue trackers
> closer to the source is one of the best things that has come out of the
> various git hosting services.

We could of course do this, but yeah, there's a bunch of things we use
bugzilla for right now. Someone would have to look at all those and
propose something to fesco and get the community to buy in.

> So far, I like Pagure. I also like similar git hosting services, such as
> GitLab and GitHub, but I don't think we're making the best use of it, if
> we're customizing separate deployments of it instead of providing a generic
> service and customizing the integrations to it. Perhaps somebody can help
> explain, with a summary of the choices which have been made and the reasons
> behind those choices, why (for better or worse) this is the direction
> Fedora is headed?

I did my best above. Feel free to ask more, or wait for better answers
from Pingou. ;)

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: A less "bloated" KDE spin

[Radka Janekova]

> Also, it might be trash for you but for someone else it might be a very
useful tool or even his or her favourite programme for a given task. So
please, be respectful to others' preferences or needs.

Could you guys please stop catching words? Obviously nobody meant any
insult by the choice of words[1] bloat or trash towards the software or
it's creators or maintainers. Should you wish to discuss the topic then
stay on the topic please. It is a whole lot of useless software (in other
words also trash, bloat and unwanted software) to just about every user,
with but a few tools they may like, except people trying to review KDE as a
family of tools. Every regular user will choose their own tools for
calendar, email, etc. Simple picture viewer/kpaint etc, should be included
because they are essential part of a desktop system, however, calendar,
address book, email client, are not.

Now that said, it was discussed that the spin is meant to be as a showoff
of the KDE family. Is it? Or is it meant for the *actual user* who has
preferences.


[1] Choice of words - In our very diverse, multinational community, not
many people are actually native English speakers. For me, trash is totally
acceptable word, and I would have never imagined that someone would make
*so much fuss* around it. The US contributors love to say that we non-US
people have to be "mindful of other cultures." Here I ask you, to be
mindful of my mixed culture, and stop insulting me or treating me like if I
did something horrible by something as silly as not the best choice of
words. Thank you.


Regards,
Radka

--
*Radka Janeková*
.NET & OpenShift Engineer, Red Hat
*radka.ja...@redhat.com *
IRC: radka | Freenode: Rhea


On Mon, Oct 9, 2017 at 12:33 PM, Silvia Sánchez  wrote:

>
> Also, it might be trash for you but for someone else it might be a very
> useful tool or even his or her favourite programme for a given task. So
> please, be respectful to others' preferences or needs.
>
> Cheers,
> Silvia
>
>
>
>
> 2017-09-11 2:00 GMT+01:00 Globe Trotter :
>
>> Very good point. I think that the original poster meant "not needed" by
>> him but it is good to be precise.
>>
>> I do not use KDE because of the bload that I consider to be KDE, and so
>> have been amused by this thread. I guess the OP and his friends could
>> create a KDE-Lite spin or try LXQT (which I also do not use but is based on
>> the same toolkit and Plasma from what I understand).
>>
>> THanks!
>>
>>
>>
>>
>> --
>>  *From:* Matthew Miller 
>> *To:* Development discussions related to Fedora <
>> devel@lists.fedoraproject.org>
>> *Sent:* Sunday, September 10, 2017 5:35 PM
>> *Subject:* Re: A less "bloated" KDE spin
>>
>> On Sun, Sep 10, 2017 at 11:34:10PM +0200, Radka Janekova wrote:
>> > Yes, I've installed it and removed about a *gigabyte* of trash. I
>> believe
>> > that most people will use maybe one or two tools out of that list.
>>
>> Hey, let's please not call software in Fedora "trash", regardless of
>> personal opinion of it. The stuff you don't use may be written by one
>> of your collaborators here — and even if not, it was written by one of
>> your collaborators in the wider open source / free software world.
>>
>>
>>
>> ___
>> 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
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 948  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 710  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 292  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 190  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 187  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7ecb12e378   
python-XStatic-jquery-ui-1.12.0.1-1.el7
  22  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  19  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-52b8147c68   
openvpn-auth-ldap-2.0.3-15.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-afdcf119f4   
freexl-1.0.4-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4826761f5d   
openvpn-2.4.4-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-abe6f98ebf   
tor-0.2.9.12-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0f92580f68   
yadifa-2.2.6-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-17b77b3268   
botan-1.10.17-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-3c06a7eecf   
nagios-4.3.4-3.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-9e6a789af9   
check-mk-1.2.8p26-1.el7


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

manifest-tool-0.7.0-1.el7
mate-themes-3.22.14-2.el7
php-justinrainbow-json-schema5-5.2.5-1.el7
php-phpmyadmin-sql-parser-4.2.3-1.el7
python-productmd-1.8-1.el7
rakudo-zef-0.1.30-1.el7

Details about builds:



 manifest-tool-0.7.0-1.el7 (FEDORA-EPEL-2017-bf4d97c599)
 A command line tool used for creating manifest list objects

Update Information:

Update to latest upstream release




 mate-themes-3.22.14-2.el7 (FEDORA-EPEL-2017-037c7fcbf4)
 MATE Desktop themes

Update Information:

- add some upstream patches




 php-justinrainbow-json-schema5-5.2.5-1.el7 (FEDORA-EPEL-2017-ef2da69c6d)
 A library to validate a json schema

Update Information:

**Version 5.2.5**  * Backports for 5.2.5  * 452 (Don't add a file:// prefix
to URI that already have a scheme)  **Version 5.2.4**  * Fresh tag to
rectify 5.2.3 mistag.  -  **Version 5.2.3**  * 453 Backports for 5.2.3 *
452 (bugfix for id double-resolution introduced in 5.2.2)   **Version
5.2.2**  * 431 Backports for 5.2.2 (Part 1) * 425 (bugfix for #424 - make
uri splitting reversable) * 429 (adjust hhvm platform for Travis, remove
phpdocumentor dependency) * 432 Added property name in draft-3 required error *
433 Backports for 5.2.2 (Part 2) * 432 (fix missing property in boolean
required error) * 450 Backports for 5.2.2 (Part 3) * 449 (Update config for
php-cs-fixer & travis) * 448 (add proper recursive handling for $ref - fixes
#447)




 php-phpmyadmin-sql-parser-4.2.3-1.el7 (FEDORA-EPEL-2017-688cea)
 A validating SQL lexer and parser with a focus on MySQL dialect

Update Information:

**Version 4.2.3** - 2017-10-10  * Fixed build CREATE TABLE query with PARTITIONS
having ENGINE but not VALUES.     **Version 4.2.2** - 2017-09-28  * Added
support for binding parameters.




 python-productmd-1.8-1.el7 (FEDORA-EPEL-2017-50d867e003)
 Library providing parsers for metadata related to OS installation

Update Information:

Improved error reporting when encountering invalid metadata files.




 rakudo-zef-0.1.30-1.el7 (FEDORA-EPEL-2017-d9944b4e64)
 Perl6 Module Management

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 826  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 820  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 710  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 682  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 292  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
  22  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-ad63a060a6   
freexl-1.0.4-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-a437fba22e   
openvpn-2.4.4-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e4d447e97c   
tor-0.2.9.12-1.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1f4bfd5d1d   
botan-1.8.15-2.el6
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-164cc614ff   
nagios-4.3.4-4.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8abafd9ad0   
check-mk-1.2.6p16-5.el6


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

python-productmd-1.8-1.el6

Details about builds:



 python-productmd-1.8-1.el6 (FEDORA-EPEL-2017-a46a0dbc20)
 Library providing parsers for metadata related to OS installation

Update Information:

Improved error reporting when encountering invalid metadata files.

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

Fedora Rawhide-20171011.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Server dvd i386
Workstation live i386
Server boot i386
Kde live i386

Failed openQA tests: 85/128 (x86_64), 1/2 (arm)

New failures (same test did not fail in Rawhide-20171010.n.1):

ID: 155954  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/155954
ID: 155955  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/155955
ID: 155966  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/155966

Old failures (same test failed in Rawhide-20171010.n.1):

ID: 155912  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/155912
ID: 155913  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/155913
ID: 155915  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/155915
ID: 155916  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/155916
ID: 155918  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/155918
ID: 155922  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/155922
ID: 155923  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/155923
ID: 155934  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/155934
ID: 155935  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/155935
ID: 155937  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/155937
ID: 155941  Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/155941
ID: 155943  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/155943
ID: 155947  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/155947
ID: 155949  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/155949
ID: 155950  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/155950
ID: 155951  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/155951
ID: 155952  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/155952
ID: 155957  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/155957
ID: 155958  Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/155958
ID: 155964  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/155964
ID: 155968  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/155968
ID: 155969  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/155969
ID: 155970  Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/155970
ID: 155971  Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/155971
ID: 155973  Test: x86_64 universal install_blivet_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/155973
ID: 155974  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/155974
ID: 155975  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/155975
ID: 155976  Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/155976
ID: 155977  Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/155977
ID: 155978  Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/155978
ID: 155979  Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/155979
ID: 155980  Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/155980
ID: 155981  Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/155981
ID: 155982  Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/155982
ID: 155983  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/155983
ID: 155984  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/155984
ID: 155985  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/155985
ID: 155986  Test: x86_64 universal upgrade_desktop_64bit
URL: 

Pagure roles at Fedora

[Christopher]

Hi,

Pagure seems to play several roles in the Fedora community, but it's a bit
confusing. Perhaps somebody can respond (or write a Wiki article on the
topic) to clear up some confusion.

For example, I hear/read the term "dist-git" a lot, but most of the
conversation about that seems to focus on Pagure being used to host Fedora
source repos. I don't really understand how these terms relate to each
other.

Another example: all the documentation for the transition away from Pkgdb
seems to reference pagure.io. However, that doesn't appear to be where the
things have moved to. Rather, things have moved to a different instance of
Pagure hosted at src.fedoraproject.org. How are these two separate
instances of Pagure related to one another, why are they separate, and what
separate roles do they each serve for Fedora packagers and contributors?

Are there any other instances of Pagure that are relevant to Fedora
packagers?

Are there any other roles that an existing instance of Pagure should be
serving, but currently isn't? For example, I've noticed that
src.fedoraproject.org has disabled issues on repos. However, I personally
would love to use it as an issue tracker instead of Bugzilla. I understand
that Bugzilla is more integrated with other services, but having issues
enabled would be a nice option in the future, as moving issue trackers
closer to the source is one of the best things that has come out of the
various git hosting services.

So far, I like Pagure. I also like similar git hosting services, such as
GitLab and GitHub, but I don't think we're making the best use of it, if
we're customizing separate deployments of it instead of providing a generic
service and customizing the integrations to it. Perhaps somebody can help
explain, with a summary of the choices which have been made and the reasons
behind those choices, why (for better or worse) this is the direction
Fedora is headed?

Thanks,

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

[Fedocal] Reminder meeting : Fedora Modular Server Beta Release Go/No-Go

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Fedora Modular Server Beta Release Go/No-Go on 2017-10-12 from 13:00:00 to 
15:00:00 US/Eastern
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Before each public release Development, QA and Release Engineering meet to 
determine if the release criteria are met for a particular release. This 
meeting is called the Go/No-Go Meeting. Verifying that the Release criteria are 
met is the responsibility of the QA Team. Release Candidate (RC) availability 
and good QA coverage are prerequisites for the Go/No-Go meeting. If you have 
any bug on the list, please help us with Beta release. If we won't be ready by 
Thursday, we will use this meeting to review blockers and decide what to do.


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

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

[Bug 1500794] perl-Term-Table-0.011 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Term-Table-0.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-2017-2b491ac3f3

-- 
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 1500439] perl-CPANPLUS-0.9172 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-CPANPLUS-0.917.200-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-2017-fddaee64b9

-- 
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: Why is Fx 57 in Updates Testing?

[Gerald B. Cox]

On Wed, Oct 11, 2017 at 5:36 PM, Adam Williamson  wrote:

> On Wed, 2017-10-11 at 17:13 -0700, Gerald B. Cox wrote:
> > On Wed, Oct 11, 2017 at 12:08 PM, Martin Stransky 
> > wrote:
> >
> > >
> > >
> > > I'm surprised that people use updates-testing for stable/production
> > > machines, have problem with handling the update and act like newbies.
> If
> > > you can't handle that, don't use that. Fedora is really a bleeding
> edge so
> > > don't complain you get new software with new features - even as testing
> > > only :)
> > >
> > > Where is Matthew Miller when you need him?  No one said anything about
> >
> > using updates-testing for stable/productioin machines.  And the fact that
> > you're implying that Fedora itself is bleeding edge and not really suited
> > for production raises a huge red flag.
> >
> > i have no doubt when this whole situation is reviewed logical minds will
> > prevail, but in the meantime you've taken advantage of a loophole.
> > Congratulations.
>
> I think you're getting a bit needlessly confrontational at this point.
> The issue's been sufficiently well raised now. Let's try to move
> forward productively from here...
>

Exactly what is confrontational?  I quoted his statement.  Yes, the issue
has been raised.
Martin is apparently going to keep it in updates-testing because that's
what he wants to do.
It may or may not be reviewed - and he took advantage of a loophole.  Since
when is in confrontational to summarize
facts?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: tnef has unfixed CVEs with patches available for some time

[Kevin Fenzi]

On 10/01/2017 01:41 PM, Christian Stadelmann wrote:
> The package tnef [1][2] has unfixed CVEs [3][4]. A fix has been commited and 
> an update has been released upstream. The fedora version has not seen this 
> update yet. Can someone please step in?

I've built and pushed the update for
CVE-2017-8911 to all supported branches. Please test.

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: 'No More Alphas': wiki revision drafts

[Adam Williamson]

On Wed, 2017-08-02 at 17:16 -0700, Adam Williamson wrote:
> Hi, folks! So I've (finally) got ready an initial round of draft
> changes to various wiki pages for the purpose of implementing the 'No
> More Alphas' Change. You can find all the drafts in the NoMoreAlphas
> category:
> 
> https://fedoraproject.org/wiki/Category:NoMoreAlpha
> 
> For each page I cloned the original text and saved it as the first
> edit, so you can use the 'History' tab's diff feature to see the actual
> changes to each page (just compare the current state to the first
> edit).
> 
> To summarize the changes, at least as I remember them, and call out
> some significant choices:
> 
> * Obviously, all Alpha-related points on the schedule template on the
> Fedora Release Life Cycle page were removed. For schedule points that
> were previously derived from Alpha points that got removed, I adjusted
> them to derive from some other still-remaining point.
> 
> * My proposal for 'what do we do about release criteria / validation'
> is basically: the 'Fedora 27 Alpha Release Criteria' page gets renamed
> 'Basic Release Criteria' (note: not versioned, I don't think it should
> be), and we document that *all* composes - not just Beta and Final
> candidate composes, but also Rawhide and Branched nightlies - will be
> automatically tested for (and release of them gated on) compliance with
> them. Which is more or less what's proposed in the Change. All external
> references to the 'Alpha' criteria get changed to 'Basic' (e.g. this is
> what changed on the other criteria pages, and on the test matrix
> template pages). Practically speaking, we currently have automated
> testing for *most* of the existing Alpha criteria, but a few items
> aren't covered. We can choose to move these to the Beta criteria, or
> leave them on Basic and just accept that *actual* coverage doesn't
> quite meet what we aspire to. I do *NOT* propose to have any kind of
> blocker tracking bug for the Basic release criteria; it doesn't seem to
> fit in the process, there is no Alpha release to block, and we can't
> realistically block nightly composes on manual test results. So a
> tracker bug wouldn't really have any reason to exist. In the case where
> a violation of the Basic criteria makes it into composes despite the
> automated testing, it should be marked as a Beta blocker.
> 
> * There is a problem with what to do about the Change schedule: our two
> sources for it don't actually agree on what the schedule *is*. The
> Changes Policy page - https://fedoraproject.org/wiki/Changes/Policy -
> claims that the 'Completion deadline' "falls on the same day as the
> Alpha milestone freeze", but the Fedora Release Life Cycle page -
> https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle - claims it
> falls on the same day as the branch point, which is two weeks *before*
> the Alpha freeze. Given this inconsistency I didn't really feel
> confident proposing a draft for the Changes/Policy page yet; probably
> it'd be good for FESCo(?) as owners of the Change process to decide
> when they actually want the key dates of the Change process to be, In A
> World Without Alphas. If FESCo wants to figure that out and let me
> know, I can draft the changes.
> 
> Please do look these over and provide any kind of feedback! Thanks.

As there was no opposition to these changes, I have gone ahead and
implemented them all, save for the changes to the Release Life Cycle
page, as those conflict with some changes planned by jkurik to some
extent. I'll review the status of that tomorrow and make any changes to
that page that I still think should be made, without unilaterally
deciding the question of how to change the release cycle.

Thanks everyone!

Quick notes-more-or-less-to-self: I need to do a new wikitcms release
to add the Basic milestone, and the blocker bug creation script needs
updating to not create Alpha blocker bugs any more.
-- 
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

Re: Why is Fx 57 in Updates Testing?

[Adam Williamson]

On Wed, 2017-10-11 at 17:13 -0700, Gerald B. Cox wrote:
> On Wed, Oct 11, 2017 at 12:08 PM, Martin Stransky 
> wrote:
> 
> > 
> > 
> > I'm surprised that people use updates-testing for stable/production
> > machines, have problem with handling the update and act like newbies. If
> > you can't handle that, don't use that. Fedora is really a bleeding edge so
> > don't complain you get new software with new features - even as testing
> > only :)
> > 
> > Where is Matthew Miller when you need him?  No one said anything about
> 
> using updates-testing for stable/productioin machines.  And the fact that
> you're implying that Fedora itself is bleeding edge and not really suited
> for production raises a huge red flag.
> 
> i have no doubt when this whole situation is reviewed logical minds will
> prevail, but in the meantime you've taken advantage of a loophole.
> Congratulations.

I think you're getting a bit needlessly confrontational at this point.
The issue's been sufficiently well raised now. Let's try to move
forward productively from here...
-- 
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

Re: Why is Fx 57 in Updates Testing?

[Gerald B. Cox]

On Wed, Oct 11, 2017 at 12:08 PM, Martin Stransky 
wrote:

>
>
> I'm surprised that people use updates-testing for stable/production
> machines, have problem with handling the update and act like newbies. If
> you can't handle that, don't use that. Fedora is really a bleeding edge so
> don't complain you get new software with new features - even as testing
> only :)
>
> Where is Matthew Miller when you need him?  No one said anything about
using updates-testing for stable/productioin machines.  And the fact that
you're implying that Fedora itself is bleeding edge and not really suited
for production raises a huge red flag.

i have no doubt when this whole situation is reviewed logical minds will
prevail, but in the meantime you've taken advantage of a loophole.
Congratulations.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Deleting a fork in src.fedoraproject.org?

[Kevin Fenzi]

On 09/08/2017 03:35 PM, Christopher wrote:
> I was playing around in the new Pagure https://src.fedoraproject.org/ and I
> created a fork of a repo to test. However, I don't need or want this fork.
> How do I delete it? There doesn't appear to be an option.

Go to the fork page, click on 'settings', to to the bottom and click on
the big red "delete the ... project" button.

Also, finally you should be able to now make a fork then delete it, then
make it again if you like.

kevin



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

Fedora Rawhide-20171010.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Server dvd i386
Workstation live i386
Server boot i386
Kde live i386

Failed openQA tests: 88/128 (x86_64), 1/2 (arm)

New failures (same test did not fail in Rawhide-20171008.n.0):

ID: 155169  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/155169
ID: 155200  Test: x86_64 Atomic-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/155200
ID: 155201  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/155201
ID: 155214  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/155214
ID: 155286  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/155286
ID: 155313  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/155313
ID: 155453  Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/155453
ID: 155458  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/155458
ID: 155462  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/155462
ID: 155464  Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/155464
ID: 155465  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/155465
ID: 155470  Test: arm Minimal-raw_xz-raw.xz base_services_start_arm
URL: https://openqa.fedoraproject.org/tests/155470

Old failures (same test failed in Rawhide-20171008.n.0):

ID: 155147  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/155147
ID: 155167  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/155167
ID: 155182  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/155182
ID: 155183  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/155183
ID: 155202  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/155202
ID: 155203  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/155203
ID: 155204  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/155204
ID: 155205  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/155205
ID: 155206  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/155206
ID: 155207  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/155207
ID: 155208  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/155208
ID: 155209  Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/155209
ID: 155213  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/155213
ID: 155215  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/155215
ID: 155216  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/155216
ID: 155217  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/155217
ID: 155218  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/155218
ID: 155219  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/155219
ID: 155220  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/155220
ID: 155221  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/155221
ID: 155222  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/155222
ID: 155223  Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/155223
ID: 155224  Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/155224
ID: 155225  Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/155225
ID: 155226  Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/155226
ID: 155227  Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/155227
ID: 155228  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/155228
ID: 155229  Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/155229
ID: 155230  Test: x86_64 universal install_simple_free_space@uefi
URL: 

Fedora 27-20171011.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Server dvd i386
Workstation live i386
Server boot i386
Kde live i386

Failed openQA tests: 17/128 (x86_64), 1/2 (arm)

ID: 155668  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/155668
ID: 155684  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/155684
ID: 155688  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/155688
ID: 155690  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/155690
ID: 155693  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/155693
ID: 155698  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/155698
ID: 155705  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/155705
ID: 155707  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/155707
ID: 155727  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/155727
ID: 155729  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/155729
ID: 155732  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/155732
ID: 155737  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/155737
ID: 155742  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/155742
ID: 155743  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/155743
ID: 155749  Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/155749
ID: 155764  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/155764
ID: 155772  Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/155772
ID: 155781  Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/155781

Soft failed openQA tests: 3/128 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 155726  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/155726
ID: 155728  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/155728
ID: 155734  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/155734

Passed openQA tests: 107/128 (x86_64)

Skipped openQA tests: 1 of 130
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Pierre-Yves Chibon]

On Wed, Oct 11, 2017 at 10:07:44PM +0100, James Hogarth wrote:
>Yes I saw the commit but that is my very point. 
>I was pretty sure that only scratch builds could be carried out from non
>release branches but you get something into a compose you needed to merge
>to master or a release branch. 

I am also pretty sure this didn't change, since koji does not have the ability
to know in which branch a commit is, it takes a url to a git repo and that's
about it.


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

Re: Why is Fx 57 in Updates Testing?

[Adam Williamson]

On Wed, 2017-10-11 at 20:58 +, Zbigniew Jędrzejewski-Szmek wrote:
> 
> OTOH, let's consider two points: one, FF57 is disruptive, and two,
> FF57 will be released as an update in Fedora when Mozilla make the
> release, as specified by our policy for FF updates.

Uh, what policy is that? AFAICS Firefox does not have a specific update
policy. It's also not listed as having any exceptions at:
https://fedoraproject.org/wiki/Updates_Policy#Exceptions .

AIUI we usually send updates to newer Firefox versions out for stable
releases under the 'needed to get security fixes out' clause. But that
doesn't mean we *must* ship every new version as an update immediately.

>  In the light of
> this, it seems reasonable to push FF57 to updates-testing right now,
> the sooner the better.
> 
> I don't get the whole kerfuffle about FF57 being beta: F27 is in beta
> now too, and it's the time to test what will be in the relased version,
> and using a pre-release of a package seems to be a better way to do
> this than using some old version that will be soon replaced.
> If we had a different updates policy for Firefox in Fedora, things
> would be different, but we don't.

I don't care about it being in beta. I *do* care about this being an
unusual approach to shipping a major Firefox change which wasn't really
discussed or even notified about in advance, and which involves sending
a package to updates-testing which is clearly not destined for stable.
If the package of the beta Firefox was actually intended to go to
stable Fedora, and that was in line with the update policy, that would
be a different case.
-- 
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

Re: Why is Fx 57 in Updates Testing?

[Matěj Cepl]

On 2017-10-11, 14:38 GMT, Martin Stransky wrote:
> And no, I'm not going to create COPR builds for that - it does 
> not contain required NSS/NSPR packages and building from git 
> is broken.

I don’t think I want to get immersed into merit of this 
discussion, but let me just note that:

a) there is no problem to build NSS/NSPR packages in COPR as 
   well,

b) it is possible to build package in COPR from ANY URL of 
   SRPM, which means it could be as well SRPM in koji.

Just my €0.02.

Matěj
-- 
http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Besides, the determined Real Programmer can write Fortran
programs in any language.
  -- Ed Post, Real Programmers Don't Use Pascal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[James Hogarth]

On 11 Oct 2017 4:48 pm, "Pierre-Yves Chibon"  wrote:

On Wed, Oct 11, 2017 at 04:34:52PM +0100, James Hogarth wrote:
>On 11 October 2017 at 16:23, Gerald B. Cox  wrote:
>
>  On Wed, Oct 11, 2017 at 7:23 AM, Till Hofmann
>   wrote:
>
>The very first sentence of the page you linked above:
>
>  The updates-testing repository, also referred to as Test Updates,
>  contains updates scheduled to be released for Branched
pre-releases
>  (after the Bodhi enabling point) and stable releases of Fedora
>
>The point is that your update is not intended to ever make it to
the
>stable update, i.e., it is not "scheduled to be released" for
>anything. If I understood correctly, you want people to test the
beta
>version and then eventually submit the final release (i.e., not
this
>update) to stable. I don't think that's how the updates-testing
>repository is supposed to be used. Instead, it should only contain
>updates that will eventually make it into stable.
>
>Regards,
>Till
>
>  +1 - Exactly...
>
>Thought I'd quickly test this being built in a COPR ... but where
exactly
>are you building from?
>https://src.fedoraproject.org/rpms/firefox/blob/f27/f/firefox.spec
>That shows vesion 56, not 57, and same with rawhide.
>I didn't think we could build from a non-fedora-branch git branch for a
>bodhi update ... that feels ... wrong ...Â
>Is this an intended effect of the "arbitrary branches" for
modularity?Â
>This really feels like it breaks the history/audit trail fro what ends
up
>in our repos.
>This doesn't even show the branch it came
>from:Â https://koji.fedoraproject.org/koji/buildinfo?buildID=981886

But it gives the commit which is:
https://src.fedoraproject.org/rpms/firefox/c/fd700ad0ae450c4705017e05db7af7
09f7ea90f0?branch=stransky-firefox-57
itself part of the stransky-firefox-57 branch:
https://src.fedoraproject.org/rpms/firefox/commits/stransky-firefox-57

This behavior is nothing new and is the reason why releng does not allow to
delete branches in dist-git.


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


Yes I saw the commit but that is my very point.

I was pretty sure that only scratch builds could be carried out from non
release branches but you get something into a compose you needed to merge
to master or a release branch.

Otherwise things like releng or proven packagers doing rebuilds for library
bumps or similar issues start to go very wrong.

They'd go to do a patch or release bump in the branch and boom...
versioning screwed.

As I said I suspect this is a side affect of the modularity arbitrary
branching stuff, similar to how as an accident it was possible to do docker
container builds from the rpms namespace at first.

It'd be good to get confirmation from releng or FESCo on the intended
behaviour as this feels wrong...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Zbigniew Jędrzejewski-Szmek]

On Wed, Oct 11, 2017 at 12:52:11PM -0700, Adam Williamson wrote:
> On Wed, 2017-10-11 at 15:42 -0400, Stephen John Smoogen wrote:
> > On 11 October 2017 at 15:08, Martin Stransky  wrote:
> > > On 10/11/2017 07:26 PM, Gerald B. Cox wrote:
> > > > 
> > > > On Wed, Oct 11, 2017 at 10:04 AM, Heiko Adams  
> > > > wrote:
> > > > 
> > > > > Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:
> > > > > 
> > > > > By definition BETA software is never intended to be pushed to stable. 
> > > > >  Fx
> > > > > 57 is BETA.  When the STABLE version is released, then it can go into
> > > > > updates-testing.  Not before.  Again, that is the purpose of RAWHIDE.
> > > > > 
> > > > > Does this mean it's also not allowed to push packaged git-snapshots 
> > > > > of a
> > > > > software to updates-testing because they are unreleased and 
> > > > > potentially
> > > > > unstable?
> > > > > 
> > > > 
> > > > As Adam mentioned apparently this isn't the "Official Policy".
> > > > 
> > > > My opinion however is common sense dictates that you don't put anything 
> > > > in
> > > > updates-testing unless you intend to push that software to stable.  If 
> > > > you
> > > > want people to test out experimental software, put it in RAWHIDE.  If 
> > > > it's
> > > > a git-snapshot and your INTENT is to push it to stable (for example,
> > > > you're
> > > > fixing a bug) then that is OK for updates-testing.
> > > > 
> > > > In this instance, there is no intent to push Fx 57 BETA to stable.  
> > > > That's
> > > > why it does't belong in update-testing.
> > > 
> > > 
> > > I think there's a bit misunderstanding here. Some parts of the FF57 update
> > > are going to be in stable as is (if the testing goes well). That includes
> > > the CSD patch [1].
> > > 
> > 
> > There are several misunderstandings here but they all stem from a core
> > problem which an old Mozilla quote covers:
> > 
> > Surprise is the opposite of engagement. [1]
> > 
> > It is something we forget a lot.. but is a reason why older
> > maintainers of XYZ software (Mozilla, X11, gcc, kernel, etc) would
> > make sure that a heads up email about a major version change goes out.
> > 
> > If you put out a heads up that "tomorrow I will be pushing Firefox
> > 57BETA into updates-testing" you could have given people heads up and
> > would have also learned from someone that updates-testing is on for
> > everyone in the post-branch world. While in this case it probably
> > would not have affected your decision, in other cases it might have
> > made it clearer that you needed to do so after a different time. It
> > would have also queued in people to either skip updates or know why
> > their workflow died.
> > 
> > In either case, people would be better informed.
> 
> Agreed. It is true that in general people using updates-testing should
> more or less know what they're doing, but they're not necessarily
> expecting surprises like this. And as smooge says, updates-testing is
> enabled by default in Branched releases (so, F27 at present); anyone
> running F27 Beta will get this package as soon as it reaches the
> mirrors.

OTOH, let's consider two points: one, FF57 is disruptive, and two,
FF57 will be released as an update in Fedora when Mozilla make the
release, as specified by our policy for FF updates. In the light of
this, it seems reasonable to push FF57 to updates-testing right now,
the sooner the better.

I don't get the whole kerfuffle about FF57 being beta: F27 is in beta
now too, and it's the time to test what will be in the relased version,
and using a pre-release of a package seems to be a better way to do
this than using some old version that will be soon replaced.
If we had a different updates policy for Firefox in Fedora, things
would be different, but we don't.

Zbyszek

> I think Harald really has a point that the potentially disruptive
> nature of the changes in 57 should mean that, if anything, we go
> *slower* in pushing it out to our users, not *faster*. Unless it
> includes vital security fixes we can't backport, I don't think there's
> necessarily a reason we need to jump all over this and try to get it
> out on release day; why not wait a bit while providing a way for early
> adopters to try it out if they'd like to?
> 
> Note that there is an alternative to both u-t and COPR; you can do
> scratch builds in Koji, or do real builds but don't actually submit
> them to updates-testing , and either provide a repo with those builds
> yourself, or just write a blog post or something explaining which
> packages people should pull from Koji if they want to test...
> -- 
> 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

Re: Why is Fx 57 in Updates Testing?

[Adam Williamson]

On Wed, 2017-10-11 at 15:42 -0400, Stephen John Smoogen wrote:
> On 11 October 2017 at 15:08, Martin Stransky  wrote:
> > On 10/11/2017 07:26 PM, Gerald B. Cox wrote:
> > > 
> > > On Wed, Oct 11, 2017 at 10:04 AM, Heiko Adams  wrote:
> > > 
> > > > Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:
> > > > 
> > > > By definition BETA software is never intended to be pushed to stable.  
> > > > Fx
> > > > 57 is BETA.  When the STABLE version is released, then it can go into
> > > > updates-testing.  Not before.  Again, that is the purpose of RAWHIDE.
> > > > 
> > > > Does this mean it's also not allowed to push packaged git-snapshots of a
> > > > software to updates-testing because they are unreleased and potentially
> > > > unstable?
> > > > 
> > > 
> > > As Adam mentioned apparently this isn't the "Official Policy".
> > > 
> > > My opinion however is common sense dictates that you don't put anything in
> > > updates-testing unless you intend to push that software to stable.  If you
> > > want people to test out experimental software, put it in RAWHIDE.  If it's
> > > a git-snapshot and your INTENT is to push it to stable (for example,
> > > you're
> > > fixing a bug) then that is OK for updates-testing.
> > > 
> > > In this instance, there is no intent to push Fx 57 BETA to stable.  That's
> > > why it does't belong in update-testing.
> > 
> > 
> > I think there's a bit misunderstanding here. Some parts of the FF57 update
> > are going to be in stable as is (if the testing goes well). That includes
> > the CSD patch [1].
> > 
> 
> There are several misunderstandings here but they all stem from a core
> problem which an old Mozilla quote covers:
> 
> Surprise is the opposite of engagement. [1]
> 
> It is something we forget a lot.. but is a reason why older
> maintainers of XYZ software (Mozilla, X11, gcc, kernel, etc) would
> make sure that a heads up email about a major version change goes out.
> 
> If you put out a heads up that "tomorrow I will be pushing Firefox
> 57BETA into updates-testing" you could have given people heads up and
> would have also learned from someone that updates-testing is on for
> everyone in the post-branch world. While in this case it probably
> would not have affected your decision, in other cases it might have
> made it clearer that you needed to do so after a different time. It
> would have also queued in people to either skip updates or know why
> their workflow died.
> 
> In either case, people would be better informed.

Agreed. It is true that in general people using updates-testing should
more or less know what they're doing, but they're not necessarily
expecting surprises like this. And as smooge says, updates-testing is
enabled by default in Branched releases (so, F27 at present); anyone
running F27 Beta will get this package as soon as it reaches the
mirrors.

I think Harald really has a point that the potentially disruptive
nature of the changes in 57 should mean that, if anything, we go
*slower* in pushing it out to our users, not *faster*. Unless it
includes vital security fixes we can't backport, I don't think there's
necessarily a reason we need to jump all over this and try to get it
out on release day; why not wait a bit while providing a way for early
adopters to try it out if they'd like to?

Note that there is an alternative to both u-t and COPR; you can do
scratch builds in Koji, or do real builds but don't actually submit
them to updates-testing , and either provide a repo with those builds
yourself, or just write a blog post or something explaining which
packages people should pull from Koji if they want to test...
-- 
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

Re: Why is Fx 57 in Updates Testing?

[Stephen John Smoogen]

On 11 October 2017 at 15:08, Martin Stransky  wrote:
> On 10/11/2017 07:26 PM, Gerald B. Cox wrote:
>>
>> On Wed, Oct 11, 2017 at 10:04 AM, Heiko Adams  wrote:
>>
>>> Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:
>>>
>>> By definition BETA software is never intended to be pushed to stable.  Fx
>>> 57 is BETA.  When the STABLE version is released, then it can go into
>>> updates-testing.  Not before.  Again, that is the purpose of RAWHIDE.
>>>
>>> Does this mean it's also not allowed to push packaged git-snapshots of a
>>> software to updates-testing because they are unreleased and potentially
>>> unstable?
>>>
>>
>> As Adam mentioned apparently this isn't the "Official Policy".
>>
>> My opinion however is common sense dictates that you don't put anything in
>> updates-testing unless you intend to push that software to stable.  If you
>> want people to test out experimental software, put it in RAWHIDE.  If it's
>> a git-snapshot and your INTENT is to push it to stable (for example,
>> you're
>> fixing a bug) then that is OK for updates-testing.
>>
>> In this instance, there is no intent to push Fx 57 BETA to stable.  That's
>> why it does't belong in update-testing.
>
>
> I think there's a bit misunderstanding here. Some parts of the FF57 update
> are going to be in stable as is (if the testing goes well). That includes
> the CSD patch [1].
>

There are several misunderstandings here but they all stem from a core
problem which an old Mozilla quote covers:

Surprise is the opposite of engagement. [1]

It is something we forget a lot.. but is a reason why older
maintainers of XYZ software (Mozilla, X11, gcc, kernel, etc) would
make sure that a heads up email about a major version change goes out.

If you put out a heads up that "tomorrow I will be pushing Firefox
57BETA into updates-testing" you could have given people heads up and
would have also learned from someone that updates-testing is on for
everyone in the post-branch world. While in this case it probably
would not have affected your decision, in other cases it might have
made it clearer that you needed to do so after a different time. It
would have also queued in people to either skip updates or know why
their workflow died.

In either case, people would be better informed.

[1] 
https://opensource.com/business/10/3/five-questions-about-building-community-chris-blizzard-mozilla


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

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[nicolas . mailhot]

De: "Mark Wielaard" 

>On Wed, 2017-10-11 at 20:36 +0200, nicolas.mail...@laposte.net wrote:
>> De: "Frank Ch. Eigler" 
> 
>> > nicolas.mailhot wrote:
>> > 
>> > > [...]
>> > > extracting debug info from
>> > > /builddir/build/BUILDROOT/golang-github-performancecopilot-speed-
>> > > 2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
>> > > *** ERROR: No build ID note found in
>> > > /builddir/build/BUILDROOT/golang-github-performancecopilot-speed-
>> > > 2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
>> > 
>> > See https://fedoraproject.org/wiki/PackagingDrafts/Go#Build_ID
>> 
>> Thanks, I somewhat missed it in all the not-really current EL6-
>> oriented stuff in this document

>I CCed Jakub, who maintains the go package. He might have some update
>to this. We did recently discuss adding the support directly to the go
>linker, but I believe that isn't yet there.

>The problem indeed is that the golang linker doesn't insert a build-id
>note in the executable. In theory this can also be worked around by
>using %undefine _missing_build_ids_terminate_build in your spec file.
>But the workaround in the wiki is better. 

>Please let me know if there are any other issues with debuginfo
>packages for go programs that you cannot work around with the hints in
>the wiki page.

Thanks for the proposal, I will indeed try to report issues rather than 
workarounding them silently and forgetting about long-term fixing. Even if the 
best intentions tend to erode around the 20th Go spec ;)

Regards,

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

Re: Why is Fx 57 in Updates Testing?

[Martin Stransky]

On 10/11/2017 07:26 PM, Gerald B. Cox wrote:

On Wed, Oct 11, 2017 at 10:04 AM, Heiko Adams  wrote:


Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:

By definition BETA software is never intended to be pushed to stable.  Fx
57 is BETA.  When the STABLE version is released, then it can go into
updates-testing.  Not before.  Again, that is the purpose of RAWHIDE.

Does this mean it's also not allowed to push packaged git-snapshots of a
software to updates-testing because they are unreleased and potentially
unstable?



As Adam mentioned apparently this isn't the "Official Policy".

My opinion however is common sense dictates that you don't put anything in
updates-testing unless you intend to push that software to stable.  If you
want people to test out experimental software, put it in RAWHIDE.  If it's
a git-snapshot and your INTENT is to push it to stable (for example, you're
fixing a bug) then that is OK for updates-testing.

In this instance, there is no intent to push Fx 57 BETA to stable.  That's
why it does't belong in update-testing.


I think there's a bit misunderstanding here. Some parts of the FF57 
update are going to be in stable as is (if the testing goes well). That 
includes the CSD patch [1].


The package may not be finished yet but the FF57 is almost done
and 99% of the code is going to be shipped to stable. This is not a 
completely different version, it may got some bugfixes but what you see 
is what you will almost get as stable update at Nov 14.


I'm sure the package is almost done so I don't take your argument about 
"completely different" package.


Due to the radical change in extension handlings and also needs to test 
the CSD patch [1] which I'd like to include in stable package I decided 
to put the FF57 to testing as early as possible. This is really a 
special case.


I believed that the update-testing repository is intended for testing 
and it's used by power users who can handle that, exclude the package 
from testing if needed, downgrade broken package and so on.


I'm surprised that people use updates-testing for stable/production 
machines, have problem with handling the update and act like newbies. If 
you can't handle that, don't use that. Fedora is really a bleeding edge 
so don't complain you get new software with new features - even as 
testing only :)


Also, I think your expectation about dramatic change of new extension 
availability for FF57 last month before the final release is false.


ma.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1283299
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[Mark Wielaard]

On Wed, 2017-10-11 at 20:36 +0200, nicolas.mail...@laposte.net wrote:
> De: "Frank Ch. Eigler" 
> 
> > nicolas.mailhot wrote:
> > 
> > > [...]
> > > extracting debug info from
> > > /builddir/build/BUILDROOT/golang-github-performancecopilot-speed-
> > > 2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
> > > *** ERROR: No build ID note found in
> > > /builddir/build/BUILDROOT/golang-github-performancecopilot-speed-
> > > 2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
> > 
> > See https://fedoraproject.org/wiki/PackagingDrafts/Go#Build_ID
> 
> Thanks, I somewhat missed it in all the not-really current EL6-
> oriented stuff in this document

I CCed Jakub, who maintains the go package. He might have some update
to this. We did recently discuss adding the support directly to the go
linker, but I believe that isn't yet there.

The problem indeed is that the golang linker doesn't insert a build-id
note in the executable. In theory this can also be worked around by
using %undefine _missing_build_ids_terminate_build in your spec file.
But the workaround in the wiki is better. Once there is a build-id note
 rpm debugedit can update it (making it unique, but stable).
Unfortunately rpm debugedit cannot insert it itself. The ELF note needs
to be in an allocated section, meaning that to add it the runtime
program headers also need to be update. And rpm debugedit cannot do
that easily. Only a real linker can.

Please let me know if there are any other issues with debuginfo
packages for go programs that you cannot work around with the hints in
the wiki page.

Thanks,

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

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[nicolas . mailhot]

De: "Frank Ch. Eigler" 

|nicolas.mailhot wrote:
|
|> [...]
|> extracting debug info from
|> 
/builddir/build/BUILDROOT/golang-github-performancecopilot-speed-2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
|> *** ERROR: No build ID note found in
|> 
/builddir/build/BUILDROOT/golang-github-performancecopilot-speed-2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
|
|See https://fedoraproject.org/wiki/PackagingDrafts/Go#Build_ID

Thanks, I somewhat missed it in all the not-really current EL6-oriented stuff 
in this document

Regards,

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

Re: Why is Fx 57 in Updates Testing?

[Stephen Gallagher]

On Wed, Oct 11, 2017 at 1:37 PM Gerald B. Cox  wrote:

> You need to read my entire statement in context.  That is not what I
> meant.  As I replied to Heiko:
>
> "My opinion however is common sense dictates that you don't put anything
> in updates-testing unless you intend to push that software to stable.  If
> you want people to test out experimental software, put it in RAWHIDE.  If
> it's a git-snapshot and your INTENT is to push it to stable (for example,
> you're fixing a bug) then that is OK for updates-testing.
>
> In this instance, there is no intent to push Fx 57 BETA to stable.  That's
> why it does't belong in update-testing."
>
> In this instance, I believe that RAWHIDE would be appropriate - since it
> not so much a prototype as a BETA release of a single package which is
> being released within a month.  Something like a test release of KDE/GNOME
> which is comprised of multiple packages would be ideal for COPR - but a Fx
> BETA COPR would be an excellent idea also.
>
>
Actually, I'm not sure if it belongs in Rawhide either, but it's closer.
The purpose of Rawhide is actually *integration*, not prototyping.
Prereleases are permissible in Rawhide when it is known that this package
may require coordinating other updates (such as updating to a new release
of a language interpreter or a desktop environment), but in general the
goal should be that Rawhide be kept reasonably stable and not treated as a
free-for-all playground. In this particular case, I can see an argument
here in that we probably want to have a place to work out any
incompatibilities with extensions that are packaged in Fedora, but I'm not
sure how many of those there are.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How should we handle gnupg v1.4.X as gpg1?

[Till Maas]

Hi,

On Tue, Oct 10, 2017 at 09:55:29AM -0700, Brian C. Lane wrote:

> The time for change is finally, almost here :) Upstream is talking about
> installing the v1.4 series as gpg1. They have already switched the
> default install of 2.2 to /usr/bin/gpg, but we currently override this
> with the --enable-gpg-is-gpg2 switch in gnupg2.

Awesome! It would be great if we continue to ship a gpg2 -> gpg symlink
to make it easier possible for tools to use gpg2.

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

Re: Why is Fx 57 in Updates Testing?

[Gerald B. Cox]

On Wed, Oct 11, 2017 at 10:24 AM, Stephen Gallagher 
wrote:

>
>
> On Wed, Oct 11, 2017 at 1:05 PM Heiko Adams  wrote:
>
>> Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:
>>
>> By definition BETA software is never intended to be pushed to stable.  Fx
>> 57 is BETA.  When the STABLE version is released, then it can go into
>> updates-testing.  Not before.  Again, that is the purpose of RAWHIDE.
>>
>> Does this mean it's also not allowed to push packaged git-snapshots of a
>> software to updates-testing because they are unreleased and potentially
>> unstable?
>>
>
> I think Gerald's position is overstating it. Upstream's definition of what
> is "beta" or "stable" is informative but not definitive.
>
> However, in this particular case, the maintainer has stated that this
> version of the package is *not* intended to actually go to the stable
> Fedora repository, which says to me that it should not be in the
> updates-testing stream at all. The point of u-t is to be a last-chance
> check on the quality before it goes out to all users. It's not intended to
> be a prototyping location; that's one of COPR's jobs.
>
>
You need to read my entire statement in context.  That is not what I
meant.  As I replied to Heiko:

"My opinion however is common sense dictates that you don't put anything in
updates-testing unless you intend to push that software to stable.  If you
want people to test out experimental software, put it in RAWHIDE.  If it's
a git-snapshot and your INTENT is to push it to stable (for example, you're
fixing a bug) then that is OK for updates-testing.

In this instance, there is no intent to push Fx 57 BETA to stable.  That's
why it does't belong in update-testing."

In this instance, I believe that RAWHIDE would be appropriate - since it
not so much a prototype as a BETA release of a single package which is
being released within a month.  Something like a test release of KDE/GNOME
which is comprised of multiple packages would be ideal for COPR - but a Fx
BETA COPR would be an excellent idea also.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Gerald B. Cox]

On Wed, Oct 11, 2017 at 10:04 AM, Heiko Adams  wrote:

> Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:
>
> By definition BETA software is never intended to be pushed to stable.  Fx
> 57 is BETA.  When the STABLE version is released, then it can go into
> updates-testing.  Not before.  Again, that is the purpose of RAWHIDE.
>
> Does this mean it's also not allowed to push packaged git-snapshots of a
> software to updates-testing because they are unreleased and potentially
> unstable?
>

As Adam mentioned apparently this isn't the "Official Policy".

My opinion however is common sense dictates that you don't put anything in
updates-testing unless you intend to push that software to stable.  If you
want people to test out experimental software, put it in RAWHIDE.  If it's
a git-snapshot and your INTENT is to push it to stable (for example, you're
fixing a bug) then that is OK for updates-testing.

In this instance, there is no intent to push Fx 57 BETA to stable.  That's
why it does't belong in update-testing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Stephen Gallagher]

On Wed, Oct 11, 2017 at 1:05 PM Heiko Adams  wrote:

> Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:
>
> By definition BETA software is never intended to be pushed to stable.  Fx
> 57 is BETA.  When the STABLE version is released, then it can go into
> updates-testing.  Not before.  Again, that is the purpose of RAWHIDE.
>
> Does this mean it's also not allowed to push packaged git-snapshots of a
> software to updates-testing because they are unreleased and potentially
> unstable?
>

I think Gerald's position is overstating it. Upstream's definition of what
is "beta" or "stable" is informative but not definitive.

However, in this particular case, the maintainer has stated that this
version of the package is *not* intended to actually go to the stable
Fedora repository, which says to me that it should not be in the
updates-testing stream at all. The point of u-t is to be a last-chance
check on the quality before it goes out to all users. It's not intended to
be a prototyping location; that's one of COPR's jobs.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Gerald B. Cox]

On Wed, Oct 11, 2017 at 9:58 AM, Adam Williamson  wrote:

> On Wed, 2017-10-11 at 07:53 -0700, Gerald B. Cox wrote:
> 
> > Martin, this is what is stated at the very top of the doc you referenced:
> > "The *updates-testing* repository
> 
>
> It's worth noting that page isn't really a policy page, it's just an
> 'informational' page. It's not officially maintained by anyone in
> control of the update process, or anything. The text was probably just
> written by a single person, describing the process as they understand
> it (it may well have been me). I wouldn't rely excessively strongly on
> a literal reading of the text as if it were the word of law.
>

That's fine, but Martin referenced it and I just pointed out the plain
reading -
which is updates there are intended to be pushed to stable.


>
> The main official policy page regarding updates is:
>
> https://fedoraproject.org/wiki/Updates_Policy
>
> that page *is* locked to drive-by edits and *is* controlled by (IIRC)
> FESCo in their role as maintainers of the update process. It doesn't
> really have any rules, right now, about how updates-testing is to be
> used, but this seems like an omission.
>

I agree, if that page is the policy, it is an omission and needs to be
corrected.


>
> FWIW, my own belief is similar to yours and sgallagh's: updates-testing
> is really only intended for packages you believe there is at least a
> decent chance will be ready to be pushed stable. It's not really
> intended for sending out packages you have no intention of pushing
> stable. But this does seem to be a slightly unusual case, at least
> reading between the lines. Perhaps if Firefox 57 is a sufficiently
> significant update that it needs special handling, exactly how this is
> to be done (for all supported releases) should be discussed and
> arranged with FPC and/or FESCo?
>


Well, the problem is that in Fx 57 many extensions will stop working.  A
few extensions which I
use have been modified in the last few days, and many others probably won't
be released until
the last minute.  Many people have updates-testing enabled automatically to
tests and report on
software.  They aren't expected BETA software to be there.  That is the
point.  Software
that is not intended to be pushed to STABLE belongs in RAWHIDE.  While
apparently it isn't written officially
anywhere doesn't mean that people should start using updates-testing in
that manner.  As I mentioned
above, if that is the case, why do we need RAWHIDE.

As far as Fx 57 being a special case, it isn't.  In fact, if anything due
to the extension breakage it should be
handled with an abundance of caution - which means don't do anything which
would case someone to
accidentally install it.

It's extremely easy to install Fx from RAWHIDE by using koji.  There is no
reason to put it in updates-testing.

This is just sending the wrong message and inviting people to start
populating updates-testing with RAWHIDE software -
and I can't imagine why anyone would want that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Emmanuel Seyman]

* Gerald B. Cox [11/10/2017 07:53] :
>
> By definition BETA software is never intended to be pushed to stable.

We've sometimes pushed beta versions of software, usually when that version is
more stable than the previous stable release.

I'm all for enforcing rules on what goes to the updates and updates-testing
repos but I'ld be happier if they went through the proper channels (FESCo/FPC)
rather than made up on the fly.

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

Re: Why is Fx 57 in Updates Testing?

[Heiko Adams]

Am Mittwoch, den 11.10.2017, 07:53 -0700 schrieb Gerald B. Cox:
> By definition BETA software is never intended to be pushed to
> stable.  Fx 57 is BETA.  When the STABLE version is released, then it
> can go into updates-testing.  Not before.  Again, that is the purpose
> of RAWHIDE.
>  
> 
> 
> 
Does this mean it's also not allowed to push packaged git-snapshots of
a software to updates-testing because they are unreleased and
potentially unstable?
-- 
Regards,

Heiko Adams


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: How should we handle gnupg v1.4.X as gpg1?

[Christopher]

On Wed, Oct 11, 2017 at 4:09 AM Tomas Mraz  wrote:

> On Wed, 2017-10-11 at 05:33 +, Christopher wrote:
> > On Tue, Oct 10, 2017 at 5:44 PM Dominik 'Rathann' Mierzejewski <
> > domi...@greysector.net> wrote:
> >
> > > On Tuesday, 10 October 2017 at 20:57, Christopher wrote:
> > > > On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lane 
> > > > wrote:
> > > >
> > > > > The time for change is finally, almost here :) Upstream is
> > > > > talking
> > >
> > > about
> > > > > installing the v1.4 series as gpg1. They have already switched
> > > > > the
> > > > > default install of 2.2 to /usr/bin/gpg, but we currently
> > > > > override this
> > > > > with the --enable-gpg-is-gpg2 switch in gnupg2.
> > > > >
> > > > > Tracker bug here - https://dev.gnupg.org/T3443
> > > > > Discussion -
> > > > > https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/0331
> > > > > 51.html
> > > > >
> > > > > When this happens I plan on tracking upstream's change and
> > > > > installing
> > >
> > > as
> > > > > gpg1, but I'm pretty sure we need a plan so that things don't
> > > > > end up
> > >
> > > all
> > > > > broken.
> > > > >
> > > >
> > > > Have you considered using alternatives as part of that plan, with
> > > > gpg2
> > >
> > > set
> > > > to higher priority than gpg1? Since upstream calls both binaries
> > > > "gpg",
> > >
> > > it
> > > > kind of already makes sense to deconflict them with the
> > > > alternatives
> > >
> > > system
> > > > in this way.
> > >
> > > Alternatives are for things that are drop-in replacements. As far
> > > as I
> > > know, gpg2 is not a drop-in replacement for gpg1.
> > >
> >
> > I suppose it depends on which characteristics you're considering when
> > you
> > compare the two. I can't be the only one who has noticed their
> > command-line
> > usage similarities, which is the characteristic I would expect to
> > matter
> > when considering using the alternatives system.
>
> I think that the incompatibility of the key storage warrants for not
> using the alternatives system in this case.
>
>
The alternatives system is there to provide choice between different
implementations. The fact that they have different implementations of their
backend storage is not a reason to avoid alternatives... it's a reason to
use it to provide users a choice. Not using alternatives is just going to
make it harder for users to switch back to gpg1 when gpg2 is made the
default gpg, if a user needs to continue using the old storage format. It
won't affect me, though. I'll be using gpg2, regardless. I was just
thinking of trying to support those other users who need/want to stay on
the old implementation.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Adam Williamson]

On Wed, 2017-10-11 at 07:53 -0700, Gerald B. Cox wrote:
> On Wed, Oct 11, 2017 at 7:00 AM, Martin Stransky 
> wrote:
> 
> > 
> >It's *updates*-testing repo and software in it should not be 'planned',
> > > but basically 'ready' for Fedora.
> > >If you want testing repo for experienced users, use COPR.
> > > 
> > 
> > I don't see it that way. Is that your personal statement or is that
> > written in any Fedora rules? I don't see that at Fedora page [1].
> > 
> > Also, the COPR suffers from some drawbacks - can't easily build from
> > Fedora or other git repo [2].
> > 
> > ma.
> > 
> > [1] https://fedoraproject.org/wiki/QA:Updates_Testing
> > [2] I know it's supposed to work but the work flow is somehow complicated
> > and uneasy and it's broken from time to time (actually right now).
> > 
> 
> Martin, this is what is stated at the very top of the doc you referenced:
> "The *updates-testing* repository
> , also
> referred to as *Test Updates*, contains updates scheduled to be released
> for Branched 
> pre-releases (after the Bodhi enabling point
> ) and stable
> releases of Fedora. User testing and feedback provided via Bodhi
> , on the test
>  mailing list and
> the relevant Bugzilla  is vital to ensure that
> good updates are released quickly and bad ones kept away from release."

It's worth noting that page isn't really a policy page, it's just an
'informational' page. It's not officially maintained by anyone in
control of the update process, or anything. The text was probably just
written by a single person, describing the process as they understand
it (it may well have been me). I wouldn't rely excessively strongly on
a literal reading of the text as if it were the word of law.

The main official policy page regarding updates is:

https://fedoraproject.org/wiki/Updates_Policy

that page *is* locked to drive-by edits and *is* controlled by (IIRC)
FESCo in their role as maintainers of the update process. It doesn't
really have any rules, right now, about how updates-testing is to be
used, but this seems like an omission.

FWIW, my own belief is similar to yours and sgallagh's: updates-testing 
is really only intended for packages you believe there is at least a
decent chance will be ready to be pushed stable. It's not really
intended for sending out packages you have no intention of pushing
stable. But this does seem to be a slightly unusual case, at least
reading between the lines. Perhaps if Firefox 57 is a sufficiently
significant update that it needs special handling, exactly how this is
to be done (for all supported releases) should be discussed and
arranged with FPC and/or FESCo?
-- 
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

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[Frank Ch. Eigler]

nicolas.mailhot wrote:

> [...]
> extracting debug info from
> /builddir/build/BUILDROOT/golang-github-performancecopilot-speed-2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
> *** ERROR: No build ID note found in
> /builddir/build/BUILDROOT/golang-github-performancecopilot-speed-2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump

See https://fedoraproject.org/wiki/PackagingDrafts/Go#Build_ID

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

Re: Why is Fx 57 in Updates Testing?

[Pierre-Yves Chibon]

On Wed, Oct 11, 2017 at 04:34:52PM +0100, James Hogarth wrote:
>On 11 October 2017 at 16:23, Gerald B. Cox  wrote:
> 
>  On Wed, Oct 11, 2017 at 7:23 AM, Till Hofmann
>   wrote:
> 
>The very first sentence of the page you linked above:
> 
>  The updates-testing repository, also referred to as Test Updates,
>  contains updates scheduled to be released for Branched pre-releases
>  (after the Bodhi enabling point) and stable releases of Fedora
> 
>The point is that your update is not intended to ever make it to the
>stable update, i.e., it is not "scheduled to be released" for
>anything. If I understood correctly, you want people to test the beta
>version and then eventually submit the final release (i.e., not this
>update) to stable. I don't think that's how the updates-testing
>repository is supposed to be used. Instead, it should only contain
>updates that will eventually make it into stable.
> 
>Regards,
>Till
> 
>  +1 - Exactly...
> 
>Thought I'd quickly test this being built in a COPR ... but where exactly
>are you building from?
>https://src.fedoraproject.org/rpms/firefox/blob/f27/f/firefox.spec
>That shows vesion 56, not 57, and same with rawhide.
>I didn't think we could build from a non-fedora-branch git branch for a
>bodhi update ... that feels ... wrong ... 
>Is this an intended effect of the "arbitrary branches" for modularity? 
>This really feels like it breaks the history/audit trail fro what ends up
>in our repos.
>This doesn't even show the branch it came
>from: https://koji.fedoraproject.org/koji/buildinfo?buildID=981886

But it gives the commit which is:
https://src.fedoraproject.org/rpms/firefox/c/fd700ad0ae450c4705017e05db7af709f7ea90f0?branch=stransky-firefox-57
itself part of the stransky-firefox-57 branch:
https://src.fedoraproject.org/rpms/firefox/commits/stransky-firefox-57

This behavior is nothing new and is the reason why releng does not allow to
delete branches in dist-git.


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

Re: Why is Fx 57 in Updates Testing?

[James Hogarth]

On 11 October 2017 at 16:23, Gerald B. Cox  wrote:

>
>
> On Wed, Oct 11, 2017 at 7:23 AM, Till Hofmann 
> wrote:
>
>>
>>
>> The very first sentence of the page you linked above:
>>
>>> The updates-testing repository, also referred to as Test Updates,
>>> contains updates scheduled to be released for Branched pre-releases (after
>>> the Bodhi enabling point) and stable releases of Fedora
>>>
>>
>> The point is that your update is not intended to ever make it to the
>> stable update, i.e., it is not "scheduled to be released" for anything. If
>> I understood correctly, you want people to test the beta version and then
>> eventually submit the final release (i.e., not this update) to stable. I
>> don't think that's how the updates-testing repository is supposed to be
>> used. Instead, it should only contain updates that will eventually make it
>> into stable.
>>
>> Regards,
>> Till
>>
>
> +1 - Exactly...
>
>
>
>
Thought I'd quickly test this being built in a COPR ... but where exactly
are you building from?

https://src.fedoraproject.org/rpms/firefox/blob/f27/f/firefox.spec

That shows vesion 56, not 57, and same with rawhide.

I didn't think we could build from a non-fedora-branch git branch for a
bodhi update ... that feels ... wrong ...

Is this an intended effect of the "arbitrary branches" for modularity?

This really feels like it breaks the history/audit trail fro what ends up
in our repos.

This doesn't even show the branch it came from:
https://koji.fedoraproject.org/koji/buildinfo?buildID=981886

Surely stuff that is non-scratch in koji and intended for a Fedora compose
should come from a release branch - at least outside of modularity stuff?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Please review: Merge lib389 to source tree

[William Brown]

https://pagure.io/389-ds-base/issue/49363

https://pagure.io/389-ds-base/issue/raw/files/85897f15e4523511c5a01cf20f10dcf05882beaed804ffe666e4e16e28c7d8b3-0001-Ticket-49363-Merge-lib389.patch



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



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

Re: Why is Fx 57 in Updates Testing?

[Gerald B. Cox]

On Wed, Oct 11, 2017 at 7:23 AM, Till Hofmann 
wrote:

>
>
> The very first sentence of the page you linked above:
>
>> The updates-testing repository, also referred to as Test Updates,
>> contains updates scheduled to be released for Branched pre-releases (after
>> the Bodhi enabling point) and stable releases of Fedora
>>
>
> The point is that your update is not intended to ever make it to the
> stable update, i.e., it is not "scheduled to be released" for anything. If
> I understood correctly, you want people to test the beta version and then
> eventually submit the final release (i.e., not this update) to stable. I
> don't think that's how the updates-testing repository is supposed to be
> used. Instead, it should only contain updates that will eventually make it
> into stable.
>
> Regards,
> Till
>

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

Re: Why is Fx 57 in Updates Testing?

[Gerald B. Cox]

On Wed, Oct 11, 2017 at 7:00 AM, Martin Stransky 
wrote:

>
>It's *updates*-testing repo and software in it should not be 'planned',
>> but basically 'ready' for Fedora.
>>If you want testing repo for experienced users, use COPR.
>>
>
> I don't see it that way. Is that your personal statement or is that
> written in any Fedora rules? I don't see that at Fedora page [1].
>
> Also, the COPR suffers from some drawbacks - can't easily build from
> Fedora or other git repo [2].
>
> ma.
>
> [1] https://fedoraproject.org/wiki/QA:Updates_Testing
> [2] I know it's supposed to work but the work flow is somehow complicated
> and uneasy and it's broken from time to time (actually right now).
>

Martin, this is what is stated at the very top of the doc you referenced:
"The *updates-testing* repository
, also
referred to as *Test Updates*, contains updates scheduled to be released
for Branched 
pre-releases (after the Bodhi enabling point
) and stable
releases of Fedora. User testing and feedback provided via Bodhi
, on the test
 mailing list and
the relevant Bugzilla  is vital to ensure that
good updates are released quickly and bad ones kept away from release."

By definition BETA software is never intended to be pushed to stable.  Fx
57 is BETA.  When the STABLE version is released, then it can go into
updates-testing.  Not before.  Again, that is the purpose of RAWHIDE.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Gerald B. Cox]

On Wed, Oct 11, 2017 at 6:32 AM, Martin Stransky 
wrote:

> On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
>
>> Was this on purpose?  Fx 57 is BETA, and  I was under the impression that
>> BETA software was for RAWHIDE.
>>
>
> It's going to be stable in one month. Fx 57 release date is 2017-11-14.
>

And?  My point was that Fx 57 isn't stable now, it's BETA.


>
> Yes, I understand there is an annotation NOT to push Fx 57 to stable - but
>> I thought that was the purpose of updates testing... software there is
>> intended to be tested and pushed to stable.
>>
>
> I expect the testing repo is used by experienced users who wish to test
> software planned for Fedora thus I don't see any problem here.
>

It is my understanding that is the purpose of RAWHIDE.  updates-testing is
for software that is intended to be pushed to stable.  It isn't for BETA
software.


> There are many extensions which aren't yet available for Fx 57 - and we're
>> effectively moving up the timetable by putting it in updates testing.
>>
>
> Do you think it's better when it suddenly appears on stable at 2017-11-14?
> I do not.
>

Well, if people want to test, they can use Nightly or RAWHIDE.  If people
start placing BETA software in updates-testing, why do we need
RAWHIDE.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Martin Stransky]

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:

Was this on purpose?  Fx 57 is BETA, and  I was under the impression that
BETA software was for RAWHIDE.

Yes, I understand there is an annotation NOT to push Fx 57 to stable - but
I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.

There are many extensions which aren't yet available for Fx 57 - and we're
effectively moving up the timetable by putting it in updates testing.


To be clear here, my intention was to enable early testing of new 
Firefox 57 release which also includes the CSD patch [1].


If there's no interest for such package I'll pull that out and you can 
expect regular FF57 update when the time comes. Please speak out at #BZ [2].


And no, I'm not going to create COPR builds for that - it does not 
contain required NSS/NSPR packages and building from git is broken.


ma.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1399611
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1500806
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora rawhide compose report: 20171011.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20171010.n.1
NEW: Fedora-Rawhide-20171011.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  0
Dropped packages:1
Upgraded packages:   24
Downgraded packages: 0

Size of added packages:  0.00 B
Size of dropped packages:1.09 MiB
Size of upgraded packages:   5.42 GiB
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   -107.61 MiB
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Atomic dvd-ostree aarch64
Path: Atomic/aarch64/iso/Fedora-Atomic-ostree-aarch64-Rawhide-20171010.n.1.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: pth-2.0.7-31.fc28
Summary: The GNU Portable Threads library
RPMs:pth pth-devel
Size:1138624 bytes


= UPGRADED PACKAGES =
Package:  audit-2.8-1.fc28
Old package:  audit-2.7.8-1.fc28
Summary:  User space tools for 2.6 kernel auditing
RPMs: audispd-plugins audispd-plugins-zos audit audit-libs 
audit-libs-devel audit-libs-python audit-libs-python3 audit-libs-static
Size: 5696328 bytes
Size change:  58296 bytes
Changelog:
  * Tue Oct 10 2017 Steve Grubb <sgr...@redhat.com> 2.8-1
  - New upstream feature release


Package:  avahi-0.7-5.fc28
Old package:  avahi-0.7-4.fc28
Summary:  Local network service discovery
RPMs: avahi avahi-autoipd avahi-compat-howl avahi-compat-howl-devel 
avahi-compat-libdns_sd avahi-compat-libdns_sd-devel avahi-devel avahi-dnsconfd 
avahi-glib avahi-glib-devel avahi-gobject avahi-gobject-devel avahi-libs 
avahi-qt3 avahi-qt3-devel avahi-qt4 avahi-qt4-devel avahi-sharp avahi-tools 
avahi-ui avahi-ui-devel avahi-ui-gtk3 avahi-ui-sharp avahi-ui-sharp-devel 
avahi-ui-tools python2-avahi python3-avahi
Size: 5952816 bytes
Size change:  16160 bytes
Changelog:
  * Sat Oct 07 2017 Rex Dieter <rdie...@fedoraproject.org> - 0.7-5
  - consistently use %{_unitdir} macro


Package:  bodhi-2.12.0-1.fc28
Old package:  bodhi-2.11.0-3.fc28
Summary:  A modular framework that facilitates publishing software updates
RPMs: bodhi-client bodhi-docs bodhi-server python2-bodhi
Size: 5982436 bytes
Size change:  736 bytes
Changelog:
  * Tue Oct 10 2017 Randy Barlow <bowlofe...@fedoraproject.org> - 2.12.0-1
  - Update to 2.12.0 (#1500515).
  - https://github.com/fedora-infra/bodhi/releases/tag/2.12.0


Package:  entangle-1.0-1.fc28
Old package:  entangle-0.7.2-1.fc28
Summary:  Tethered shooting & control of digital cameras
RPMs: entangle
Size: 3558760 bytes
Size change:  81632 bytes
Changelog:
  * Tue Oct 10 2017 Daniel P. Berrange <berra...@redhat.com> - 1.0-1
  - Update to 1.0 release


Package:  ffcall-2.0-1.fc28
Old package:  ffcall-1.13-5.fc27
Summary:  Libraries for foreign function call interfaces
RPMs: ffcall ffcall-devel ffcall-static
Added RPMs:   ffcall-devel ffcall-static
Size: 695224 bytes
Size change:  242706 bytes
Changelog:
  * Tue Sep 12 2017 Jerry James <loganje...@gmail.com> - 2.0-1
  - New upstream release
  - Make -devel and -static subpackages


Package:  findbugs-contrib-7.0.5-1.fc28
Old package:  findbugs-contrib-7.0.3-2.fc28
Summary:  Extra findbugs detectors
RPMs: eclipse-findbugs-contrib findbugs-contrib 
findbugs-contrib-javadoc findbugs-contrib-samples
Size: 1481688 bytes
Size change:  9748 bytes
Changelog:
  * Tue Oct 10 2017 Richard Fearn <richardfe...@gmail.com> - 7.0.4-1
  - Update to 7.0.4

  * Tue Oct 10 2017 Richard Fearn <richardfe...@gmail.com> - 7.0.5-1
  - Update to 7.0.5 (bug #1488265)


Package:  gpm-1.20.7-13.fc28
Old package:  gpm-1.20.7-10.fc26
Summary:  A mouse server for the Linux console
RPMs: gpm gpm-devel gpm-libs gpm-static
Size: 2011992 bytes
Size change:  26164 bytes
Changelog:
  * Wed Jul 26 2017 Fedora Release Engineering <rel...@fedoraproject.org> - 
1.20.7-11
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild

  * Wed Aug 02 2017 Fedora Release Engineering <rel...@fedoraproject.org> - 
1.20.7-12
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild

  * Tue Oct 10 2017 Merlin Mathesius <mmath...@redhat.com> - 1.20.7-13
  - Include upstream pull request patches to fix FTBFS (BZ#1500092)


Package:  java-9-openjdk-1:9.0.0.181-8.fc28
Old package:  java-9-openjdk-1:9.0.0.181-5.fc28
Summary:  OpenJDK Runtime Environment
RPMs: java-9-openjdk java-9-openjdk-accessibility 
java-9-openjdk-accessibility-debug java-9-openjdk-debug java-9-openjdk-demo 
java-9-openjdk-demo-debug java-9-openjdk-devel java-9-openjdk-devel-debug 
java-9-openjdk-headless java-9-openjdk-headless-debug java-9-openjdk-javadoc 
java-9-openjdk-javadoc-debug java-9-openjdk-javadoc-zip 
java-9-openjdk-javadoc-zip-debug java-9-openjdk-jmods 
java-9-openjdk-jmods-debug java-9-openjdk-src java-9-openjdk-src-d

Re: Why is Fx 57 in Updates Testing?

[Stephen Gallagher]

On Wed, Oct 11, 2017 at 10:26 AM Till Hofmann 
wrote:

>
> The very first sentence of the page you linked above:
> > The updates-testing repository, also referred to as Test Updates,
> contains updates scheduled to be released for Branched pre-releases (after
> the Bodhi enabling point) and stable releases of Fedora
>
> The point is that your update is not intended to ever make it to the
> stable update, i.e., it is not "scheduled to be released" for anything.
> If I understood correctly, you want people to test the beta version and
> then eventually submit the final release (i.e., not this update) to
> stable. I don't think that's how the updates-testing repository is
> supposed to be used. Instead, it should only contain updates that will
> eventually make it into stable.
>
>
Yeah, testing for a package that isn't expected to arrive in the stable
stream really belongs in a COPR these days. The updates-testing repo should
really be used exclusively as a stopover towards a stable release (with the
option to revoke it if it reveals problems).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why is Fx 57 in Updates Testing?

[Till Hofmann]

On 10/11/2017 04:00 PM, Martin Stransky wrote:

On 10/11/2017 03:52 PM, Tomasz Torcz wrote:

On Wed, Oct 11, 2017 at 03:32:07PM +0200, Martin Stransky wrote:

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
Was this on purpose?  Fx 57 is BETA, and  I was under the impression 
that

BETA software was for RAWHIDE.


It's going to be stable in one month. Fx 57 release date is 2017-11-14.

Yes, I understand there is an annotation NOT to push Fx 57 to stable 
- but

I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.


I expect the testing repo is used by experienced users who wish to test
software planned for Fedora thus I don't see any problem here.


   It's *updates*-testing repo and software in it should not be 
'planned',

but basically 'ready' for Fedora.
   If you want testing repo for experienced users, use COPR.


I don't see it that way. Is that your personal statement or is that 
written in any Fedora rules? I don't see that at Fedora page [1].



The very first sentence of the page you linked above:

The updates-testing repository, also referred to as Test Updates, contains 
updates scheduled to be released for Branched pre-releases (after the Bodhi 
enabling point) and stable releases of Fedora


The point is that your update is not intended to ever make it to the 
stable update, i.e., it is not "scheduled to be released" for anything. 
If I understood correctly, you want people to test the beta version and 
then eventually submit the final release (i.e., not this update) to 
stable. I don't think that's how the updates-testing repository is 
supposed to be used. Instead, it should only contain updates that will 
eventually make it into stable.


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

Re: Why is Fx 57 in Updates Testing?

[M A Young]

On Wed, 11 Oct 2017, Martin Stransky wrote:

> On 10/11/2017 03:46 PM, Mátyás Selmeci wrote:
> > On 10/11/17 08:32, Martin Stransky wrote:
> > > On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
> > > > Was this on purpose?  Fx 57 is BETA, and I was under the impression that
> > > > BETA software was for RAWHIDE.
> > > 
> > > It's going to be stable in one month. Fx 57 release date is 2017-11-14.
> > > 
> > > > Yes, I understand there is an annotation NOT to push Fx 57 to stable -
> > > > but
> > > > I thought that was the purpose of updates testing... software there is
> > > > intended to be tested and pushed to stable.
> > > 
> > > I expect the testing repo is used by experienced users who wish to test
> > > software planned for Fedora thus I don't see any problem here.
> > > 
> > > > There are many extensions which aren't yet available for Fx 57 - and
> > > > we're
> > > > effectively moving up the timetable by putting it in updates testing.
> > > 
> > > Do you think it's better when it suddenly appears on stable at 2017-11-14?
> > > I do not.
> > > 
> > > ma.
> > 
> > Will an older version (either 56 or the ESR version, 52) also be included in
> > Fedora 27 as a separate package?
> 
> No, we (Red Hat Desktop team) will ship Firefox 57 only as well as Mozilla
> does. Of course anyone can create/maintain additional Firefox packages (ESR,
> Developer edition...) for Fedora as I mentioned many times before.
> 
> This is also reason why I created this update for testing so early.

The problem is that Fedora 27 is still getting updates from 
updates-testing at the moment (until the final freeze scheduled for 
2017-10-17) so anyone running dnf update on F27 will get Firefox 57 at the 
moment.

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

[Bug 1500805] New: perl-MP3-Info-1.26 is available

[bugzilla]

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

Bug ID: 1500805
   Summary: perl-MP3-Info-1.26 is available
   Product: Fedora
   Version: rawhide
 Component: perl-MP3-Info
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 1.26
Current version/release in rawhide: 1.25-1.fc28
URL: http://search.cpan.org/dist/MP3-Info/

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

-- 
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 1500804] New: perl-Net-IPv6Addr-0.91 is available

[bugzilla]

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

Bug ID: 1500804
   Summary: perl-Net-IPv6Addr-0.91 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Net-IPv6Addr
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 0.91
Current version/release in rawhide: 0.9-1.fc28
URL: http://search.cpan.org/dist/Net-IPv6Addr/

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

-- 
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: Why is Fx 57 in Updates Testing?

[Martin Stransky]

On 10/11/2017 03:52 PM, Tomasz Torcz wrote:

On Wed, Oct 11, 2017 at 03:32:07PM +0200, Martin Stransky wrote:

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:

Was this on purpose?  Fx 57 is BETA, and  I was under the impression that
BETA software was for RAWHIDE.


It's going to be stable in one month. Fx 57 release date is 2017-11-14.


Yes, I understand there is an annotation NOT to push Fx 57 to stable - but
I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.


I expect the testing repo is used by experienced users who wish to test
software planned for Fedora thus I don't see any problem here.


   It's *updates*-testing repo and software in it should not be 'planned',
but basically 'ready' for Fedora.
   If you want testing repo for experienced users, use COPR.


I don't see it that way. Is that your personal statement or is that 
written in any Fedora rules? I don't see that at Fedora page [1].


Also, the COPR suffers from some drawbacks - can't easily build from 
Fedora or other git repo [2].


ma.

[1] https://fedoraproject.org/wiki/QA:Updates_Testing
[2] I know it's supposed to work but the work flow is somehow 
complicated and uneasy and it's broken from time to time (actually right 
now).

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

Re: Why is Fx 57 in Updates Testing?

[Martin Stransky]

On 10/11/2017 03:46 PM, Mátyás Selmeci wrote:

On 10/11/17 08:32, Martin Stransky wrote:

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:

Was this on purpose?  Fx 57 is BETA, and I was under the impression that
BETA software was for RAWHIDE.


It's going to be stable in one month. Fx 57 release date is 2017-11-14.

Yes, I understand there is an annotation NOT to push Fx 57 to stable 
- but

I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.


I expect the testing repo is used by experienced users who wish to 
test software planned for Fedora thus I don't see any problem here.


There are many extensions which aren't yet available for Fx 57 - and 
we're

effectively moving up the timetable by putting it in updates testing.


Do you think it's better when it suddenly appears on stable at 
2017-11-14? I do not.


ma.


Will an older version (either 56 or the ESR version, 52) also be 
included in Fedora 27 as a separate package?


Note: There's also IceCat browser available at Fedora:

https://apps.fedoraproject.org/packages/icecat

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

Re: Why is Fx 57 in Updates Testing?

[Martin Stransky]

On 10/11/2017 03:46 PM, Mátyás Selmeci wrote:

On 10/11/17 08:32, Martin Stransky wrote:

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:

Was this on purpose?  Fx 57 is BETA, and I was under the impression that
BETA software was for RAWHIDE.


It's going to be stable in one month. Fx 57 release date is 2017-11-14.

Yes, I understand there is an annotation NOT to push Fx 57 to stable 
- but

I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.


I expect the testing repo is used by experienced users who wish to 
test software planned for Fedora thus I don't see any problem here.


There are many extensions which aren't yet available for Fx 57 - and 
we're

effectively moving up the timetable by putting it in updates testing.


Do you think it's better when it suddenly appears on stable at 
2017-11-14? I do not.


ma.


Will an older version (either 56 or the ESR version, 52) also be 
included in Fedora 27 as a separate package?


No, we (Red Hat Desktop team) will ship Firefox 57 only as well as 
Mozilla does. Of course anyone can create/maintain additional Firefox 
packages (ESR, Developer edition...) for Fedora as I mentioned many 
times before.


This is also reason why I created this update for testing so early.

ma.


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

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

Re: Why is Fx 57 in Updates Testing?

[Tomasz Torcz]

On Wed, Oct 11, 2017 at 03:32:07PM +0200, Martin Stransky wrote:
> On 10/11/2017 03:17 PM, Gerald B. Cox wrote:
> > Was this on purpose?  Fx 57 is BETA, and  I was under the impression that
> > BETA software was for RAWHIDE.
> 
> It's going to be stable in one month. Fx 57 release date is 2017-11-14.
> 
> > Yes, I understand there is an annotation NOT to push Fx 57 to stable - but
> > I thought that was the purpose of updates testing... software there is
> > intended to be tested and pushed to stable.
> 
> I expect the testing repo is used by experienced users who wish to test
> software planned for Fedora thus I don't see any problem here.

  It's *updates*-testing repo and software in it should not be 'planned',
but basically 'ready' for Fedora.
  If you want testing repo for experienced users, use COPR.

-- 
Tomasz Torcz   "Never underestimate the bandwidth of a station
xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1500794] perl-Term-Table-0.011 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-Term-Table-0.011-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-2b491ac3f3

-- 
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 1500794] perl-Term-Table-0.011 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Fixed In Version||perl-Term-Table-0.011-1.fc2
   ||8
   Assignee|ppi...@redhat.com   |jples...@redhat.com



-- 
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: Why is Fx 57 in Updates Testing?

[Mátyás Selmeci]

On 10/11/17 08:32, Martin Stransky wrote:

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:

Was this on purpose?  Fx 57 is BETA, and I was under the impression that
BETA software was for RAWHIDE.


It's going to be stable in one month. Fx 57 release date is 2017-11-14.

Yes, I understand there is an annotation NOT to push Fx 57 to stable 
- but

I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.


I expect the testing repo is used by experienced users who wish to 
test software planned for Fedora thus I don't see any problem here.


There are many extensions which aren't yet available for Fx 57 - and 
we're

effectively moving up the timetable by putting it in updates testing.


Do you think it's better when it suddenly appears on stable at 
2017-11-14? I do not.


ma.


Will an older version (either 56 or the ESR version, 52) also be 
included in Fedora 27 as a separate package?


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

Re: Why is Fx 57 in Updates Testing?

[Martin Stransky]

On 10/11/2017 03:17 PM, Gerald B. Cox wrote:

Was this on purpose?  Fx 57 is BETA, and  I was under the impression that
BETA software was for RAWHIDE.


It's going to be stable in one month. Fx 57 release date is 2017-11-14.


Yes, I understand there is an annotation NOT to push Fx 57 to stable - but
I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.


I expect the testing repo is used by experienced users who wish to test 
software planned for Fedora thus I don't see any problem here.



There are many extensions which aren't yet available for Fx 57 - and we're
effectively moving up the timetable by putting it in updates testing.


Do you think it's better when it suddenly appears on stable at 
2017-11-14? I do not.


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

[Bug 1500794] New: perl-Term-Table-0.011 is available

[bugzilla]

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

Bug ID: 1500794
   Summary: perl-Term-Table-0.011 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Term-Table
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.011
Current version/release in rawhide: 0.008-3.fc27
URL: http://search.cpan.org/dist/Term-Table/

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

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

Why is Fx 57 in Updates Testing?

[Gerald B. Cox]

Was this on purpose?  Fx 57 is BETA, and  I was under the impression that
BETA software was for RAWHIDE.

Yes, I understand there is an annotation NOT to push Fx 57 to stable - but
I thought that was the purpose of updates testing... software there is
intended to be tested and pushed to stable.

There are many extensions which aren't yet available for Fx 57 - and we're
effectively moving up the timetable by putting it in updates testing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Re: csiphash on Sparc

[Lukas Slebodnik]

On (11/10/17 12:42), Carsten Grzemba wrote:
>
>
>On 11.10.17 10:54, William Brown   wrote: 
>> 
>> On Tue, 2017-10-10 at 16:28 +0200, Carsten Grzemba wrote:
>> > 
>> > On 10.10.17 16:10, William Brown  wrote: 
>> > > 
>> > > On Fri, 2017-10-06 at 10:21 +0200, Carsten Grzemba wrote:
>> > > > Currently the code src/libsds/external/csiphash/csiphash.c do not work 
>> > > > on Sparc. 
>> > > > The casting void* or char* to unit64_t* throws Bus-Error.
>> > > > 
>> > > > The solution would be to copy the content of the void and char pointer 
>> > > > so that the variabeles are suitably aligned.
>> > > > To prevent have to use malloc: do we know the max of src_sz?
>> > > > 
>> > > 
>> > > 
>> > > What line is this? I assume you are refering to:
>> > > 
>> > > https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82
>> > > 
>> > yes!
>> > 
>> > > 
>> > > (https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82)
>> > > 
>> > > No, we can't know the max of src_sz, in theory it could be uint64_t max.
>> > > So this may not be an option.
>> > > 
>> > So is malloc for uint64 alignment of the src variable the only option?
>> > 
>> > > 
>> > > 
>> > > 
>> > > Are you trying this on a 32bit platform perhaps? What's the arch of the
>> > > machine with the issue?
>> > > 
>> > 64bit, Fujitsu M4000
>> > $ isainfo -v
>> > 64-bit sparcv9 applications
>> > fmaf vis2 vis popc 
>> 
>> I feel like there is something I'm missing here in the problem. What is
>> sizeof(void *) on this platform? I'm assuming 4 or 16 rather than 8
>> bytes? Is this correct? 
>> 
>no it is 8.
>
>The following programm works on x86 but dumps on Sparc:
>
>
>
>#include 
>#include 
>
>int func(const void *str, size_t sz, const char key[16]){
> uint64_t *ip = (uint64_t*) str;
> printf ("str: %lx:%lx\n", ip, *ip);
>}
>
>int main()
>{
> char str[25] = "ABCDEFGH12345678";
> char key[16];
>
But following code should work. Please correct me if I am wrong. I didn't test.
  char *str = strdup("ABCDEFGH12345678");
  char *key = malloc(16);

yes, function sds_siphash13 is not ideal because it rely on properly alligned
input data.

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

[Bug 1500439] perl-CPANPLUS-0.9172 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-CPANPLUS-0.917.200-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-fddaee64b9

-- 
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: tools and systemtap containers are available in Fedora

[Mark Wielaard]

Hi Tomas,

On Fri, 2017-10-06 at 20:09 +0200, Tomas Tomecek wrote:
> Mark, thanks for feedback!
> 
> I'll be honest that I left gcc and gdb in there by accident. As Dan
> said, we are trying to reduce size of that container so it's easier
> to use. Who decides what's in it?

> This was an internal collaboration with multiple
> people -- in the end, everyone can express themselves and provide
> feedback or suggestions.
> 
> Would you be able to come up with a complete list of packages you
> have in mind? Creating a new issue in Atomic WG issue tracker would
> be really helpful to us: https://pagure.io/atomic-wg/issues
> 
> I agree with Dan that this could be a good candidate for a debugging
> container -- tools container could contain sysadmin tools and the
> debugging container could be used for debugging applications and
> maybe even C-development.

Aha. Interesting. I think the name "tools" is a little misleading.
Seeing some of the "tools" in there I assumed it was actually the
development tools container. The name tools might be a bit overloaded
:)

I am not sure debugging container on itself is that useful, it probably
should be a developer tools container, containing everything you would
use for your normal edit-compile-debug cycle. Or maybe a group of
"stacked" containers might be nice, one for the core native toolchain,
one for development debug tools and one for production monitoring,
tracing and profiling?

Maybe the packages from the Developer Toolset software collection (for
CentOS, but then for current Fedora) might be a good starting point:
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-6/
Those come with a toolchain and perftools collection, also available as
docker image. But designed to be parallel installable, something which
you might not care for for the atomic containers. But the package lists
might be a good starting point.
http://mirror.centos.org/centos/7/sclo/x86_64/rh/devtoolset-7/

Cheers,

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

[Bug 1500439] perl-CPANPLUS-0.9172 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Fixed In Version||perl-CPANPLUS-0.917.200-1.f
   ||c28
   Assignee|ppi...@redhat.com   |jples...@redhat.com



-- 
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 1500438] perl-Code-TidyAll-0.69 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Depends On||1500691




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1500691
[Bug 1500691] Review Request: perl-lib-relative - Add paths relative to the
current file to @INC
-- 
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

[389-devel] Re: csiphash on Sparc

[Carsten Grzemba]

On 11.10.17 10:54, William Brown   wrote: 
> 
> On Tue, 2017-10-10 at 16:28 +0200, Carsten Grzemba wrote:
> > 
> > On 10.10.17 16:10, William Brown  wrote: 
> > > 
> > > On Fri, 2017-10-06 at 10:21 +0200, Carsten Grzemba wrote:
> > > > Currently the code src/libsds/external/csiphash/csiphash.c do not work 
> > > > on Sparc. 
> > > > The casting void* or char* to unit64_t* throws Bus-Error.
> > > > 
> > > > The solution would be to copy the content of the void and char pointer 
> > > > so that the variabeles are suitably aligned.
> > > > To prevent have to use malloc: do we know the max of src_sz?
> > > > 
> > > 
> > > 
> > > What line is this? I assume you are refering to:
> > > 
> > > https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82
> > > 
> > yes!
> > 
> > > 
> > > (https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82)
> > > 
> > > No, we can't know the max of src_sz, in theory it could be uint64_t max.
> > > So this may not be an option.
> > > 
> > So is malloc for uint64 alignment of the src variable the only option?
> > 
> > > 
> > > 
> > > 
> > > Are you trying this on a 32bit platform perhaps? What's the arch of the
> > > machine with the issue?
> > > 
> > 64bit, Fujitsu M4000
> > $ isainfo -v
> > 64-bit sparcv9 applications
> > fmaf vis2 vis popc 
> 
> I feel like there is something I'm missing here in the problem. What is
> sizeof(void *) on this platform? I'm assuming 4 or 16 rather than 8
> bytes? Is this correct? 
> 
no it is 8.

The following programm works on x86 but dumps on Sparc:



#include 
#include 

int func(const void *str, size_t sz, const char key[16]){
 uint64_t *ip = (uint64_t*) str;
 printf ("str: %lx:%lx\n", ip, *ip);
}

int main()
{
 char str[25] = "ABCDEFGH12345678";
 char key[16];

 printf ("sizeof void* %d\n", sizeof(void*));
 printf ("sizeof char* %d\n", sizeof(char*));
 printf ("sizeof uint64_t* %d\n", sizeof(uint64_t*));

 func(str, 12, key);
 func([1], 11, key);
}

On x86:

grzemba@unstable11x:~/Tests$ gcc -g -m64 -O3 -fPIC -DPIC -MD -MP size_test.c -o 
st_x86

grzemba@unstable11x:~/Tests$ ./st_x86 
sizeof void* 8
sizeof char* 8
sizeof uint64_t* 8
str: 80ffbb20:4847464544434241
str: 80ffbb21:3148474645444342

On Sparc: 

grzemba@unstable11s:~/Tests$ gcc -g -m64 -O3 -fPIC -DPIC -MD -MP size_test.c -o 
st_sparc

grzemba@unstable11s:~/Tests$ ./st_sparc 
sizeof void* 8
sizeof char* 8
sizeof uint64_t* 8
str: 77d0:4142434445464748
Bus Error (core dumped)

grzemba@unstable11s:~/Tests$ gdb st_sparc core
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.11".
For bug reporting instructions, please see:
...
Reading symbols from /home/grzemba/Tests/st_sparc...done.
[New LWP 1]
[New LWP 1]
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
Core was generated by `./st_sparc'.
Program terminated with signal 10, Bus error.
#0 0x00010de8 in func (str=0x77d1, sz=, 
 key=0x77c0 "") at size_test.c:6
6 printf ("str: %lx:%lx\n", ip, *ip);
(gdb) 





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

Re: [HEADS UP] libselinux golang bindings will be dropped from Rawhide

[Petr Lautrbach]

On Tue, Oct 10, 2017 at 05:06:02PM +0200, Zygmunt Krynicki wrote:
> 
> As it's too early to tell which way we'll go with SELinux and golang I
> think it's okay to drop this. Once we start to make some progress into
> making any policy work in snapd we'll either revive this or use a
> maintained package.
> 


According to selinux.go [1] the initial motivation for this
implementation was to add selinux support to docker but this is
maintained by opencontainers now.

Because there are python and ruby bindings in libselinux already, it
would make sense to have also golang bindings if there's any demand.
However, the current implementation needs to be updated and reviewed
before it can be proposed upstream. But I'm not familiar with GO.

So for now, I moved golang bindings to golang-bindings branch [2]
and I will drop it from master branch. It will not be part of the next
libselinux-devel build in Rawhide.


[1] 
https://github.com/fedora-selinux/selinux/blob/golang-bindings/libselinux/golang/selinux.go
[2] https://github.com/fedora-selinux/selinux/tree/golang-bindings

Petr

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

Re: [atomic-devel] tools and systemtap containers are available in Fedora

[nicolas . mailhot]

Hi,

BTW since we are talking about debug and future tech, what is the correct way 
(as of rawhide and EPEL 7) to handle 

extracting debug info from 
/builddir/build/BUILDROOT/golang-github-performancecopilot-speed-2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump
*** ERROR: No build ID note found in 
/builddir/build/BUILDROOT/golang-github-performancecopilot-speed-2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump

(I have those in all Go packages that build something)

I can sprinkle %global debug_package   %{nil} everywhere, but that's not overly 
satisfying.

Regards,

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

[389-devel] Re: csiphash on Sparc

[William Brown]

On Tue, 2017-10-10 at 16:28 +0200, Carsten Grzemba wrote:
> 
> On 10.10.17 16:10, William Brown   wrote: 
> > 
> > On Fri, 2017-10-06 at 10:21 +0200, Carsten Grzemba wrote:
> > > Currently the code src/libsds/external/csiphash/csiphash.c do not work on 
> > > Sparc. 
> > > The casting void* or char* to unit64_t* throws Bus-Error.
> > > 
> > > The solution would be to copy the content of the void and char pointer so 
> > > that the variabeles are suitably aligned.
> > > To prevent have to use malloc: do we know the max of src_sz?
> > > 
> > 
> > 
> > What line is this? I assume you are refering to:
> > 
> > https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82
> > 
> yes!
>  
> > 
> > (https://pagure.io/389-ds-base/blob/master/f/src/libsds/external/csiphash/csiphash.c#_82)
> > 
> > No, we can't know the max of src_sz, in theory it could be uint64_t max.
> > So this may not be an option.
> > 
> So is malloc for uint64 alignment of the src variable the only option?
>  
> > 
> > 
> > 
> > Are you trying this on a 32bit platform perhaps? What's the arch of the
> > machine with the issue?
> > 
> 64bit, Fujitsu M4000
> $ isainfo -v
> 64-bit sparcv9 applications
>  fmaf vis2 vis popc 

I feel like there is something I'm missing here in the problem. What is
sizeof(void *) on this platform? I'm assuming 4 or 16 rather than 8
bytes? Is this correct? 



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



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

Re: How should we handle gnupg v1.4.X as gpg1?

[Tomas Mraz]

On Wed, 2017-10-11 at 05:33 +, Christopher wrote:
> On Tue, Oct 10, 2017 at 5:44 PM Dominik 'Rathann' Mierzejewski <
> domi...@greysector.net> wrote:
> 
> > On Tuesday, 10 October 2017 at 20:57, Christopher wrote:
> > > On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lane 
> > > wrote:
> > > 
> > > > The time for change is finally, almost here :) Upstream is
> > > > talking
> > 
> > about
> > > > installing the v1.4 series as gpg1. They have already switched
> > > > the
> > > > default install of 2.2 to /usr/bin/gpg, but we currently
> > > > override this
> > > > with the --enable-gpg-is-gpg2 switch in gnupg2.
> > > > 
> > > > Tracker bug here - https://dev.gnupg.org/T3443
> > > > Discussion -
> > > > https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/0331
> > > > 51.html
> > > > 
> > > > When this happens I plan on tracking upstream's change and
> > > > installing
> > 
> > as
> > > > gpg1, but I'm pretty sure we need a plan so that things don't
> > > > end up
> > 
> > all
> > > > broken.
> > > > 
> > > 
> > > Have you considered using alternatives as part of that plan, with
> > > gpg2
> > 
> > set
> > > to higher priority than gpg1? Since upstream calls both binaries
> > > "gpg",
> > 
> > it
> > > kind of already makes sense to deconflict them with the
> > > alternatives
> > 
> > system
> > > in this way.
> > 
> > Alternatives are for things that are drop-in replacements. As far
> > as I
> > know, gpg2 is not a drop-in replacement for gpg1.
> > 
> 
> I suppose it depends on which characteristics you're considering when
> you
> compare the two. I can't be the only one who has noticed their
> command-line
> usage similarities, which is the characteristic I would expect to
> matter
> when considering using the alternatives system.

I think that the incompatibility of the key storage warrants for not
using the alternatives system in this case.

-- 
Tomáš Mráz
Red Hat

No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

 * Google and NSA associates, this message is none of your business.
 * Please leave it alone, and consider whether your actions are
 * authorized by the contract with Red Hat, or by the US constitution.
 * If you feel you're being encouraged to disregard the limits built
 * into them, remember Edward Snowden and Wikileaks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 947  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 709  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 291  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 189  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 187  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5f9a6163b4   
tnef-1.4.14-1.el7
 186  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7ecb12e378   
python-XStatic-jquery-ui-1.12.0.1-1.el7
  21  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  19  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-52b8147c68   
openvpn-auth-ldap-2.0.3-15.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-3dcce634cb   
MySQL-zrm-3.0-17.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-afdcf119f4   
freexl-1.0.4-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4826761f5d   
openvpn-2.4.4-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-abe6f98ebf   
tor-0.2.9.12-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0f92580f68   
yadifa-2.2.6-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-17b77b3268   
botan-1.10.17-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-3c06a7eecf   
nagios-4.3.4-3.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-9e6a789af9   
check-mk-1.2.8p26-1.el7


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

golang-github-mgutz-logxi-1-1.el7
gsmartcontrol-1.1.1-1.el7
gtk-gnutella-1.1.12-1.el7
liblxi-1.0-2.el7
lxi-tools-1.1-1.el7
mimedefang-2.82-1.el7
php-horde-Horde-Share-2.2.0-1.el7
python-texttable-0.9.1-1.el7

Details about builds:



 golang-github-mgutz-logxi-1-1.el7 (FEDORA-EPEL-2017-6fa4e1361a)
 A 12-factor app logger built for performance and happy development

Update Information:

First package for Fedora

References:

  [ 1 ] Bug #1430147 - Review Request: golang-github-mgutz-logxi - A 12-factor 
app logger built for performance and happy development
https://bugzilla.redhat.com/show_bug.cgi?id=1430147




 gsmartcontrol-1.1.1-1.el7 (FEDORA-EPEL-2017-b72f3a4b21)
 Graphical user interface for smartctl

Update Information:

Update to 1.1.1.




 gtk-gnutella-1.1.12-1.el7 (FEDORA-EPEL-2017-91f2b07a44)
 GUI based Gnutella Client

Update Information:

Update to 1.1.12




 liblxi-1.0-2.el7 (FEDORA-EPEL-2017-532fc5b9f3)
 Library with simple API for communication with LXI devices

Update Information:

The LXI library (liblxi) is an open source software library for GNU/Linux
systems which offers a simple API for communicating with LXI enabled
instruments. The API allows applications to easily discover instruments on
networks and communicate SCPI commands.

References:

  [ 1 ] Bug #1499559 - Review Request: liblxi - Library with simple API for 
communication with LXI devices
https://bugzilla.redhat.com/show_bug.cgi?id=1499559




 lxi-tools-1.1-1.el7 (FEDORA-EPEL-2017-d9783562ce)
 Tools collection to control LXI enabled instruments

Update Information:

LXI tools are a collection of open source software tools for GNU/Linux systems
that enable control of LXI enabled instruments such as modern oscilloscopes,
power supplies, spectrum analyzers etc.  The main tool is the 'lxi' application
which provides commandline control of LXI instruments.  Also available is a
small tool for grabbing screenshots 

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 825  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 819  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 709  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 681  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 291  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 187  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c0d33ae70f   
tnef-1.4.14-1.el6
  21  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-be95216c3a   
MySQL-zrm-3.0-6.el6.2
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-ad63a060a6   
freexl-1.0.4-1.el6
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-a437fba22e   
openvpn-2.4.4-1.el6
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e4d447e97c   
tor-0.2.9.12-1.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-1f4bfd5d1d   
botan-1.8.15-2.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-164cc614ff   
nagios-4.3.4-4.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8abafd9ad0   
check-mk-1.2.6p16-5.el6


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

gtk-gnutella-1.1.12-1.el6
kmodtool-1-27.el6
liblxi-1.0-2.el6
lxi-tools-1.1-1.el6
mimedefang-2.82-1.el6
php-horde-Horde-Share-2.2.0-1.el6

Details about builds:



 gtk-gnutella-1.1.12-1.el6 (FEDORA-EPEL-2017-1db82c4717)
 GUI based Gnutella Client

Update Information:

Update to 1.1.12




 kmodtool-1-27.el6 (FEDORA-EPEL-2017-1840d9a2d4)
 Tool for building kmod packages

Update Information:

Revert my (incomplete) previous conditional fix for (/usr)/sbin/depmod in the
spec file and apply the kmodtool patch by Nicolas Vieville instead to also cover
(/usr)/lib/modules issue properly (#1484293)

References:

  [ 1 ] Bug #1484293 - None
https://bugzilla.redhat.com/show_bug.cgi?id=1484293




 liblxi-1.0-2.el6 (FEDORA-EPEL-2017-54a1830083)
 Library with simple API for communication with LXI devices

Update Information:

The LXI library (liblxi) is an open source software library for GNU/Linux
systems which offers a simple API for communicating with LXI enabled
instruments. The API allows applications to easily discover instruments on
networks and communicate SCPI commands.

References:

  [ 1 ] Bug #1499559 - Review Request: liblxi - Library with simple API for 
communication with LXI devices
https://bugzilla.redhat.com/show_bug.cgi?id=1499559




 lxi-tools-1.1-1.el6 (FEDORA-EPEL-2017-4b329cd743)
 Tools collection to control LXI enabled instruments

Update Information:

LXI tools are a collection of open source software tools for GNU/Linux systems
that enable control of LXI enabled instruments such as modern oscilloscopes,
power supplies, spectrum analyzers etc.  The main tool is the 'lxi' application
which provides commandline control of LXI instruments.  Also available is a
small tool for grabbing screenshots from Rigol 1000Z series oscilloscopes.

References:

  [ 1 ] Bug #1499560 - Review Request: lxi-tools - Tools collection to control 
LXI enabled instruments
https://bugzilla.redhat.com/show_bug.cgi?id=1499560




 mimedefang-2.82-1.el6 (FEDORA-EPEL-2017-ff3d139608)
 E-Mail filtering framework using Sendmail's Milter interface

Update 

[Bug 1494881] perl-PDF-Create-1.43 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-PDF-Create-1.43-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-2017-a17b6cf901

-- 
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 1488159] Upgrade perl-HTTP-OAI to 4.06

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-HTTP-OAI-4.06-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-2017-06e80182be

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