Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)
On Thu, 06 Aug 2015 13:15:02 +, Igor Gnatenko wrote: We discussed with Jan Silhan yesterday. It looks like something broken in createrepo/createrepo_c in F22. So it's not dnf/yum/hawkey/libsolv issue. LOG: https://ignatenkobrain.fedorapeople.org/epoch_bug.log Also CCing Jan. Wow. createrepo is also affected. createrepo_c uses strtol() to accept only numbers as Epoch. Anything else strol() cannot parse is ignored and defaults to epoch=0 in the repo metadata. This means it can break for typos as well as, not just an undefined macro used as Epoch in a versioned dep. It couldn't find a comment in the source that would tell whether this is by design. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 23 Alpha Go/No-Go Meeting - the second round, Friday, August 07 @ 17:00 UTC
As on the Go/No-Go meeting organized today (2015-Aug-06) we agreed to postpone the final decision for one day [1], I would like to ask you to join us once more on irc.freenode.net in #fedora-meeting-2 wherein we shall finally determine the readiness of the Fedora 23 Alpha. Friday, August 07, 2015 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST) For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 23 Alpha Blocker list: http://qa.fedoraproject.org/blockerbugs/milestone/23/alpha/buglist Regards, Jan [FedoCal] https://apps.fedoraproject.org/calendar/meeting/2862/ [1] http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-06/f23_alpha_gono-go_meeting.2015-08-06-17.00.html/ -- Jan Kuřík ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 266 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3989/cross-binutils-2.23.88.0.1-2.el7.1 150 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1087/dokuwiki-0-0.24.20140929c.el7 71 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-6262/cabal-install-1.16.1.0-1.el7,haskell-platform-2013.2.0.0-39.el7 57 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1545/strongswan-5.3.2-1.el7 46 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-6813/chicken-4.9.0.1-4.el7 24 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7143/nx-libs-3.5.0.32-1.el7 14 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7297/uwsgi-2.0.11.1-1.el7 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7334/lighttpd-1.4.36-1.el7 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7493/lxc-1.0.7-2.el7 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7512/nbd-3.11-1.el7 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7366/wordpress-4.2.4-1.el7 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7549/nagios-plugins-2.0.3-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing canl-java-2.1.1-4.el7 globus-ftp-client-8.23-1.el7 globus-ftp-control-6.7-1.el7 globus-gridftp-server-8.1-1.el7 globus-gss-assist-10.15-1.el7 globus-net-manager-0.12-1.el7 globus-xio-gridftp-driver-2.11-1.el7 globus-xio-gridftp-multicast-1.6-1.el7 globus-xio-udt-driver-1.18-2.el7 gsi-openssh-6.6.1p1-2.el7 hitch-1.0.0-0.4.3.beta4.el7 keybinder-0.3.0-6.el7 mingw-crt-4.0.4-1.el7 mingw-headers-4.0.4-1.el7 mingw-winpthreads-4.0.4-1.el7 mosh-1.2.5-1.el7 mozilla-noscript-2.6.9.34-1.el7 nagios-plugins-2.0.3-1.el7 php-aws-sdk-2.8.17-1.el7 python-defusedxml-0.4.1-4.el7 zarafa-7.1.13-1.el7 Details about builds: canl-java-2.1.1-4.el7 (FEDORA-EPEL-2015-7529) EMI Common Authentication library - bindings for Java Update Information: Javadoc fixes. ChangeLog: * Wed Aug 5 2015 Mattias Ellert mattias.ell...@fysast.uu.se - 2.1.1-4 - Drop bouncycastle 1.52 modifications (Fedora 23+ now uses canl-java 2.2.0) - Minor javadoc fixes globus-ftp-client-8.23-1.el7 (FEDORA-EPEL-2015-7380) Globus Toolkit - GridFTP Client Library Update Information: Globus Toolkit updates from upstream developers: * globus-ftp-client 8.23 * globus-ftp-control 6.7 * globus-gridftp-server 8.1 * globus-gss-assist 10.15 * globus-net-manager 0.12 * globus-xio-gridftp-driver 2.11 * globus-xio-gridftp-multicast 1.6 * globus-xio-udt-driver 1.18 ChangeLog: * Mon Jul 27 2015 Mattias Ellert mattias.ell...@fysast.uu.se - 8.23-1 - GT6 update (Fix crash in error handling) * Wed Jun 17 2015 Fedora Release Engineering rel-...@lists.fedoraproject.org - 8.22-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild globus-ftp-control-6.7-1.el7 (FEDORA-EPEL-2015-7380) Globus Toolkit - GridFTP Control Library Update Information: Globus Toolkit updates from upstream developers: * globus-ftp-client 8.23 * globus-ftp-control 6.7 * globus-gridftp-server 8.1 * globus-gss-assist 10.15 * globus-net-manager 0.12 * globus-xio-gridftp-driver 2.11 * globus-xio-gridftp-multicast 1.6 * globus-xio-udt-driver 1.18 ChangeLog: * Mon Jul 27 2015 Mattias Ellert mattias.ell...@fysast.uu.se - 6.7-1 - GT6 update (Fix old-style function definitions, Fix variable scope) * Wed Jun 17 2015 Fedora Release Engineering rel-...@lists.fedoraproject.org - 6.6-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild globus-gridftp-server-8.1-1.el7 (FEDORA-EPEL-2015-7380) Globus Toolkit - Globus GridFTP Server Update Information: Globus Toolkit updates from upstream developers: *
[Test-Announce] Fedora 23 Alpha Go/No-Go Meeting - the second round, Friday, August 07 @ 17:00 UTC
As on the Go/No-Go meeting organized today (2015-Aug-06) we agreed to postpone the final decision for one day [1], I would like to ask you to join us once more on irc.freenode.net in #fedora-meeting-2 wherein we shall finally determine the readiness of the Fedora 23 Alpha. Friday, August 07, 2015 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST) For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 23 Alpha Blocker list: http://qa.fedoraproject.org/blockerbugs/milestone/23/alpha/buglist Regards, Jan [FedoCal] https://apps.fedoraproject.org/calendar/meeting/2862/ [1] http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-06/f23_alpha_gono-go_meeting.2015-08-06-17.00.html/ -- Jan Kuřík ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)
On Thu, 2015-08-06 at 18:37 +0200, Michael Schwendt wrote:
On Thu, 06 Aug 2015 13:15:02 +, Igor Gnatenko wrote:
We discussed with Jan Silhan yesterday. It looks like something broken in
createrepo/createrepo_c in F22. So it's not dnf/yum/hawkey/libsolv issue.
LOG: https://ignatenkobrain.fedorapeople.org/epoch_bug.log
Also CCing Jan.
Wow. createrepo is also affected.
createrepo_c uses strtol() to accept only numbers as Epoch. Anything
else strol() cannot parse is ignored and defaults to epoch=0 in the
repo metadata. This means it can break for typos as well as, not just
an undefined macro used as Epoch in a versioned dep.
It couldn't find a comment in the source that would tell whether this
is by design.
I'd guess it is. I'd say the root bug here is in rpmbuild, this is what
it does for Epoch itself:
case RPMTAG_EPOCH: {
SINGLE_TOKEN_ONLY;
uint32_t epoch;
if (parseUnsignedNum(field, epoch)) {
rpmlog(RPMLOG_ERR,
_(line %d: Epoch field must be an unsigned number: %
s\n),
spec-lineNum, spec-line);
goto exit;
}
...it should do the same kind of thing for epoch's within E:V-R data
too.
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Self Introduction: Seth Jennings
On Thu, Aug 6, 2015 at 2:12 PM, Seth Jennings spartacu...@gmail.com wrote: Greetings! In acordance with the procedure for a first-time packager, I'm annoucing on devel list :) I opened my first review request bug for yubioath-desktop, and GUI and CLI for extracting OTP tokens from a Yubikey. https://bugzilla.redhat.com/show_bug.cgi?id=1251238 I work at Red Hat on one of the kernel development teams. In my spare time though, I like to learn everything I can about open source technologies and Fedora is my platform of choice! I have a Youtube channel where I demonstrate various tasks on Fedora: https://www.youtube.com/channel/UCUMY5vAIUPlKzZm_LEtFUJA My Blog: https://www.variantweb.net/blog/ GPG Fingerprint: 6786 EF89 9CFF 4913 F200 2FE2 9622 D5C8 C1AC F915 I look forward to contributing! Welcome to Fedora! Happy to have you here :) -AdamM Seth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 266 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-4008/cross-binutils-2.23.51.0.3-1.el6.1 57 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1501/strongswan-5.3.2-1.el6 46 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-6828/chicken-4.9.0.1-4.el6 29 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7031/python-virtualenv-12.0.7-1.el6 24 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7116/nx-libs-3.5.0.32-1.el6 23 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7168/rubygem-crack-0.3.2-2.el6 14 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7304/uwsgi-2.0.11.1-1.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7362/drupal6-cck-2.10-1.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7347/lighttpd-1.4.36-1.el6 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7497/lxc-1.0.7-2.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7353/wordpress-4.2.4-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7535/nagios-plugins-2.0.3-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing globus-ftp-client-8.23-1.el6 globus-ftp-control-6.7-1.el6 globus-gridftp-server-8.1-1.el6 globus-gss-assist-10.15-1.el6 globus-net-manager-0.12-1.el6 globus-xio-gridftp-driver-2.11-1.el6 globus-xio-gridftp-multicast-1.6-1.el6 globus-xio-udt-driver-1.18-2.el6 golang-github-hashicorp-consul-migrate-0-0.2.git4977886.el6 golang-github-hashicorp-go-checkpoint-0-0.2.git88326f6.el6 golang-github-hashicorp-go-multierror-0-0.2.gitfcdddc3.el6 golang-github-hashicorp-go-syslog-0-0.2.git42a2b57.el6 golang-github-hashicorp-golang-lru-0-0.2.gitd85392d.el6 golang-github-hashicorp-hcl-0-0.2.git513e04c.el6 golang-github-hashicorp-logutils-0-0.2.git367a65d.el6 golang-github-hashicorp-mdns-0-0.2.git2b439d3.el6 golang-github-hashicorp-net-rpc-msgpackrpc-0-0.2.gitd377902.el6 golang-github-hashicorp-raft-boltdb-0-0.2.gitd1e82c1.el6 golang-github-hashicorp-raft-mdb-0-0.2.git4ec3694.el6 golang-github-hashicorp-scada-client-0-0.2.gitc26580c.el6 golang-github-howeyc-gopass-0-0.2.git2c70fa7.el6 golang-github-imdario-mergo-0-0.3.git6ce7536.el6 golang-github-inconshreveable-muxado-0-0.2.gitf693c7e.el6 golang-github-influxdb-hyperleveldb-go-0-0.3.gite24de94.el6 golang-github-influxdb-rocksdb-0-0.3.git7adff3e.el6 golang-github-jessevdk-go-flags-0-0.2.git5e11878.el6 golang-github-jonboulle-clockwork-0-0.3.git3f831b6.el6 hitch-1.0.0-0.4.3.beta4.el6 nagios-plugins-2.0.3-1.el6 php-aws-sdk-2.8.17-1.el6 rubygem-thor-0.18.1-3.el6 sks-1.1.5-9.el6 zarafa-7.1.13-1.el6 Details about builds: globus-ftp-client-8.23-1.el6 (FEDORA-EPEL-2015-7339) Globus Toolkit - GridFTP Client Library Update Information: Globus Toolkit updates from upstream developers: * globus-ftp-client 8.23 * globus-ftp-control 6.7 * globus-gridftp-server 8.1 * globus-gss-assist 10.15 * globus-net-manager 0.12 * globus-xio-gridftp-driver 2.11 * globus-xio-gridftp-multicast 1.6 * globus-xio-udt-driver 1.18 ChangeLog: * Mon Jul 27 2015 Mattias Ellert mattias.ell...@fysast.uu.se - 8.23-1 - GT6 update (Fix crash in error handling) * Wed Jun 17 2015 Fedora Release Engineering rel-...@lists.fedoraproject.org - 8.22-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild globus-ftp-control-6.7-1.el6 (FEDORA-EPEL-2015-7339) Globus Toolkit - GridFTP Control Library Update Information: Globus Toolkit updates from upstream developers: * globus-ftp-client 8.23 * globus-ftp-control 6.7 * globus-gridftp-server 8.1 * globus-gss-assist 10.15 * globus-net-manager 0.12 * globus-xio-gridftp-driver 2.11 * globus-xio-gridftp-multicast 1.6 * globus-xio-udt-driver 1.18 ChangeLog: * Mon Jul 27 2015 Mattias Ellert mattias.ell...@fysast.uu.se - 6.7-1 - GT6 update (Fix old-style function definitions, Fix variable scope) * Wed Jun 17 2015 Fedora Release Engineering rel-...@lists.fedoraproject.org - 6.6-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
[389-devel] Review Request for test cases
Hi All, I have automated few test cases for https://fedorahosted.org/389/attachment/ticket/47910/ . Here is my patch :: https://fedorahosted.org/389/attachment/ticket/47910/0001-Ticket-47910-allow-logconv.pl-S-E-switches-to-work-e.2.patch I request for your valuable feedback. Thanks Regards, Amita -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: gpg keys of older/newer fedora versions
On Wed, 5 Aug 2015, Neal Gompa wrote: I disagree that including the keys for EOL'd releases counts as encouraging people to use old stuff. If someone has a reason to be building RPMs for something way-old, I think it'd be nice for us to keep those GPG keys available for them. Agreed. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[389-devel] 48239 lib389 Please review fix for un-allocated prefix in
https://fedorahosted.org/389/ticket/48239 https://fedorahosted.org/389/attachment/ticket/48239/0001-Fix-for-prefix-allocat ion-of-un-initialised-dirsrv-o.patch -- William Brown will...@blackhats.net.au -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Agenda for Env-and-Stacks WG meeting (2015-08-06)
On 08/06/2015 11:59 AM, Honza Horak wrote: WG meeting will be at 17:00 UTC (13:00 EST, 19:00 Brno, 13:00 Boston, 2:00+1d Tokyo, 3:00+1d Brisbane) in #fedora-meeting-2 on Freenode. = Topics = * RHEL.next and how communicate between containers / stacks Of course it should be Fedora.next, sorry for copypaste error of former typing error. Honza * Rings in Fedora 24 - documentation would be awesome * Taiga.io - could it be used to track features/projects and it's progress? * Open Floor ___ env-and-stacks mailing list env-and-sta...@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Agenda for Env-and-Stacks WG meeting (2015-08-06)
WG meeting will be at 17:00 UTC (13:00 EST, 19:00 Brno, 13:00 Boston, 2:00+1d Tokyo, 3:00+1d Brisbane) in #fedora-meeting-2 on Freenode. = Topics = * RHEL.next and how communicate between containers / stacks * Rings in Fedora 24 - documentation would be awesome * Taiga.io - could it be used to track features/projects and it's progress? * Open Floor -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [389-devel] Instance discovery tools in lib389
Hi William, On 08/06/2015 12:54 AM, William Brown wrote: Hi, I have been working on lib389 recently to bring in a number of the tools I have developed professionally into the project so that others can benefit from this. As you may have seen I've already submitted a few patches related to this. I've done some of the api changes needed, but now I would like to make it a bit easier to add command line tools that can utilise lib389. This is right inline with what we would like to do as well. I would like to add a tools directory to lib389 with a number of the cli tools and helpers that I have written [1]. Is this the best location for these tools? If there are really simple, maybe they could just be added to the tools.py/utils.py files? More on this below... Some of them could arguably go into the main line 389ds codebase, but I want to use lib389 to back them. This really depends on the tool, but see below... Second, with these tools I don't want them to be complex. +1 For lib389 inclusion they should be very simple, so that other tools can utilize them. For example, I would like a tool that can show what attribute can be held by what objectClass. I would want the calling syntax to be as easy as: attribute_query.py -i instance name attribute name In order to achieve this there are a few changes I want to make. First, is that there is already a DirSrv.list() function. This works well to list instances on the system, but it's missing the instance name, so I want to add this to the dictionary that is returned. Second, I want to make it possible to initialise the DirSrv object from an instance directory returned by the list() function. Normally this is done through the allocate() function to establish the details of the connection, at the moment the instance function doesn't return enough data to support this. Either, I can add in functionality to the list() function to return more data about each instance, possibly enough to just take the result from list() and put it in as allocate(args) and have a working connection. Alternately I write a new allocate_from_instance() (or some other name ...?) function that is able to do the discovery of the needed data, and then call allocate. Which would be the preferred method. Both. Expand the instance dictionary(your proposal could be useful for many other tasks/tools), and create the new allocate_from_instance function. Comments and advice is appreciated. [1] The tools I want to add are: * List all known system instances * schema query tools (list of object classes, attributes, query which objectclasses can take which attribute) This should really be added to schema.py, or at least the core functionality added to schema.py, then build your tool off of that? * aci testing and manipulation tools. For example, does aci X do what I suspect. * aci inversion tool. convert != aci's into == aci's to help conversion to white lists. Maybe these aci tools could be partially integrated into a new acl.py file? Kind of like what I suggested with the schema tools. * Probably many more that I haven't thought of yet to help make administration of a 389ds instance simpler. Ultimately, I would like to see some of your new functionally go into the existing core module, and then write your tools based off of those. This way it can be leveraged outside of your specific task tools - for use in other new/future tools. Of course I am specualting a bit, because I have not seen what you are working on yet. Perhaps others on this list might have some opinions thoughts as well? In the meantime I would like to see what you are working on, and we can discuss this together and work towards an ideal approach. Thanks again for your interest and contribution to the lib389 project! Mark -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[Bug 1251348] New: Revive dead package perl-Module-Pluggable
https://bugzilla.redhat.com/show_bug.cgi?id=1251348 Bug ID: 1251348 Summary: Revive dead package perl-Module-Pluggable Product: Fedora EPEL Version: el6 Component: perl-Module-Pluggable Severity: medium Assignee: p...@city-fan.org Reporter: ticot...@gmail.com QA Contact: extras...@fedoraproject.org CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org, psab...@redhat.com, st...@silug.org Description of problem: perl-Module-Pluggable is required for perl-Alien-Packages (#12742723) Version-Release number of selected component (if applicable): 5.10-6 How reproducible: fedpkg build Steps to Reproduce: 1. git clone git://pkgs.fedoraproject.org/perl-Module-Pluggable.git 2. fedpkg switch-branch el6 3. fedpkg build Actual results: Package has been retired Expected results: Package builds Additional info: Latest version builds on koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=10629863 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [389-devel] please review: Ticket 47703 - Remove search limit for ACI group evaluation
On Thu, 2015-08-06 at 16:13 -0400, Mark Reynolds wrote: https://fedorahosted.org/389/ticket/47703 https://fedorahosted.org/389/attachment/ticket/47703/0001-Ticket-47703-remove- search-limit-for-aci-group-evalu.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel I'm having a read through of this to try and understand more about this, and hopefully to help with your review. Why was the search limit added initially into the aci plugin? By deleting this code, is there some other edge case that it may cause? Would it be possible to make a unit test case for this. If you set the sizelimit in cn=config to be low, say 5, you could easily make a group that has more members, and then evaluate aci behaviour in a unit test? If you are busy perhaps that's something I could knock up and test if you were happy for me to do so. Sincerely, -- William Brown will...@blackhats.net.au -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[EPEL-devel] Package zbar blocks ImageMagick update for CentOS 6.7
zbar requires libMagickWand.so.2 and libMagickCore.so.2 from ImageMagick-6.5.4.7-7.el6_5 The ImageMagick-6.7.2.7-2.el6 update provides libMagickWand.so.5 and libMagickCore.so.5 Error: Package: zbar-0.10-7.el6.x86_64 (@epel) Requires: libMagickCore.so.2()(64bit) Removing: ImageMagick-6.5.4.7-7.el6_5.x86_64 (@anaconda-CentOS-201410241409.x86_64/6.6) libMagickCore.so.2()(64bit) Updated By: ImageMagick-6.7.2.7-2.el6.x86_64 (base) Not found Error: Package: zbar-0.10-7.el6.x86_64 (@epel) Requires: libMagickWand.so.2()(64bit) Removing: ImageMagick-6.5.4.7-7.el6_5.x86_64 (@anaconda-CentOS-201410241409.x86_64/6.6) libMagickWand.so.2()(64bit) Updated By: ImageMagick-6.7.2.7-2.el6.x86_64 (base) Not found -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[Bug 1216112] CVE-2015-3451 perl-XML-LibXML: expand_entities option was not preserved under some circumstances
https://bugzilla.redhat.com/show_bug.cgi?id=1216112 Kurt Seifried kseifr...@redhat.com changed: What|Removed |Added Whiteboard|impact=low,public=20150423, |impact=low,public=20150423, |reported=20150423,source=re |reported=20150423,source=re |searcher,cvss2=2.6/AV:N/AC: |searcher,cvss2=2.6/AV:N/AC: |H/Au:N/C:P/I:N/A:N,fedora-a |H/Au:N/C:P/I:N/A:N,fedora-a |ll/perl-XML-LibXML=affected |ll/perl-XML-LibXML=affected |,rhel-5/perl-XML-LibXML=new |,rhel-5/perl-XML-LibXML=won |,rhel-6/perl-XML-LibXML=aff |tfix,rhel-6/perl-XML-LibXML |ected,rhel-7/perl-XML-LibXM |=wontfix,rhel-7/perl-XML-Li |L=affected |bXML=wontfix --- Comment #3 from Kurt Seifried kseifr...@redhat.com --- Mitigations: This issue only affects programs using this program in forms such as: $parser = XML::LibXML-new or $XML_DOC = $parser-load_xml if you use the form: $XML_DOC = XML::LibXML-load_xml this vulnerability will not be exposed. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [389-devel] Instance discovery tools in lib389
I've done some of the api changes needed, but now I would like to make it a bit easier to add command line tools that can utilise lib389. This is right inline with what we would like to do as well. Glad to hear it. I would like to add a tools directory to lib389 with a number of the cli tools and helpers that I have written [1]. Is this the best location for these tools? If there are really simple, maybe they could just be added to the tools.py/utils.py files? More on this below... Yes and no. See below, as I think I explain a bit better what I'm working towards. Some of them could arguably go into the main line 389ds codebase, but I want to use lib389 to back them. This really depends on the tool, but see below... Second, with these tools I don't want them to be complex. +1 For lib389 inclusion they should be very simple, so that other tools can utilize them. Glad that we agree on this. Either, I can add in functionality to the list() function to return more data about each instance, possibly enough to just take the result from list() and put it in as allocate(args) and have a working connection. Alternately I write a new allocate_from_instance() (or some other name ...?) function that is able to do the discovery of the needed data, and then call allocate. Which would be the preferred method. Both. Expand the instance dictionary(your proposal could be useful for many other tasks/tools), and create the new allocate_from_instance function. Well, there is no point doing both. I was either going to expand the instance dict to include all the SER_* attributes, so that you could literally pass it straight to allocate(). Or, you have just the instance name added to the instance dict, then you have allocate_from_instance (Which also, I don't like that name even though I came up with it. It's confusing :S ) which will then discover all the SER_* values, then pass them all to allocate() anyway. This is why I think we should choose on way or the other. My preference is actually the former, as we avoid a confusing function name, and it makes the value of the list() function greater. You could do: insts = ds.list(all=True) someinst = insts[0] ds.allocate(someinst) Or even allocate a new DirSrv, etc. Comments and advice is appreciated. [1] The tools I want to add are: * List all known system instances * schema query tools (list of object classes, attributes, query which objectclasses can take which attribute) This should really be added to schema.py, or at least the core functionality added to schema.py, then build your tool off of that? * aci testing and manipulation tools. For example, does aci X do what I suspect. * aci inversion tool. convert != aci's into == aci's to help conversion to white lists. Maybe these aci tools could be partially integrated into a new acl.py file? Kind of like what I suggested with the schema tools. * Probably many more that I haven't thought of yet to help make administration of a 389ds instance simpler. Ultimately, I would like to see some of your new functionally go into the existing core module, and then write your tools based off of those. This way it can be leveraged outside of your specific task tools - for use in other new/future tools. Of course I am specualting a bit, because I have not seen what you are working on yet. You have already seen my work, and acked most of the functionality into the core modules. Additionally the aci.py module is waiting in your inbox for informal review. For example: https://fedorahosted.org/389/ticket/48236 - Will be used in conjunction with aci.py to evaluate and test aci functionality is working as expected, both in the aci evaluation engine in 389ds, but also from a semantic point of view of user acis https://fedorahosted.org/389/ticket/48238 - Is all the functionality needed to make the schema query tool I was discussing before. My goal was to always add functionality into the library, then make the most minimal command line tool possible to just stich it all together. This way both unit tests and possible cli tools can benefit from the work. So I think we already have the same approach, I just maybe didn't communicate that very well. Perhaps others on this list might have some opinions thoughts as well? In the meantime I would like to see what you are working on, and we can discuss this together and work towards an ideal approach. Sounds like a plan! Thanks again for your interest and contribution to the lib389 project! You're welcome. Thanks for your time reviewing my work and ideas. -- William Brown will...@blackhats.net.au -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: gpg keys of older/newer fedora versions
On Thu, Aug 06, 2015 at 11:43:19AM -0700, Samuel Sieb wrote: On 08/05/2015 09:58 PM, Christopher Meng wrote: On 7/18/15, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: I thought I'd ask here first: is there a strong reason *not* to include those keys? It's not recommended to encourage end users installing EOL releases. I don't see how this affects people installing old releases either way. It's easy to install any release. Just point to the right repo, the keys are included. Is there some other aspect to this that I'm missing? How would you know that those keys are the right keys? Once it is installed, it will use it's own keys, but during the initial installation you have to provide the keys (or take the leap of faith with --nogpg). Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Guidelines change] Changes to the packaging guidelines
VS == Ville Skyttä ville.sky...@iki.fi writes: VS I have a bug report about the macros. Where should I file it, FPC VS ticket or Bugzilla against the python* packages that ship the VS affected macro files? Oops, I didn't see your mailing list post until well after I saw the ticket. Unfortunately this kind of thing is in the hands of the python folks. We'll all coordinate to try to get something worked out but in the end they have to update and push and support these things while the guidelines are just documentation. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1216112] CVE-2015-3451 perl-XML-LibXML: expand_entities option was not preserved under some circumstances
https://bugzilla.redhat.com/show_bug.cgi?id=1216112 Kurt Seifried kseifr...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |WONTFIX Last Closed||2015-08-06 20:01:21 --- Comment #4 from Kurt Seifried kseifr...@redhat.com --- Statement: This issue affects the versions of perl-XML-LibXML as shipped with Red Hat Enterprise Linux 5, 6 and 7. Red Hat Product Security has rated this issue as having Low security impact. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: polymake
polymake has broken dependencies in the F-23 tree: On x86_64: polymake-2.13-22.git20141013.fc23.x86_64 requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.x86_64 requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.x86_64 requires libperl.so.5.20()(64bit) On i386: polymake-2.13-22.git20141013.fc23.i686 requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.i686 requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.i686 requires libperl.so.5.20 On armhfp: polymake-2.13-22.git20141013.fc23.armv7hl requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.armv7hl requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-CGI-Application-Structured-Tools
perl-CGI-Application-Structured-Tools has broken dependencies in the F-23 tree: On x86_64: perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Devel-FindRef
perl-Devel-FindRef has broken dependencies in the F-23 tree: On x86_64: perl-Devel-FindRef-1.44-3.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-FindRef-1.44-3.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Devel-FindRef-1.44-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-FindRef-1.44-3.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Devel-FindRef-1.44-3.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-FindRef-1.44-3.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-CatalystX-REPL
perl-CatalystX-REPL has broken dependencies in the F-23 tree: On x86_64: perl-CatalystX-REPL-0.04-10.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-CatalystX-REPL-0.04-10.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-CatalystX-REPL-0.04-10.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Carp-REPL
perl-Carp-REPL has broken dependencies in the F-23 tree: On x86_64: perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2) On i386: perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2) On armhfp: perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Test-AutoBuild
perl-Test-AutoBuild has broken dependencies in the F-23 tree: On x86_64: perl-Test-AutoBuild-1.2.4-15.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Test-AutoBuild-1.2.4-15.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Test-AutoBuild-1.2.4-15.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-POE-API-Peek
perl-POE-API-Peek has broken dependencies in the F-23 tree: On x86_64: 1:perl-POE-API-Peek-2.20-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: 1:perl-POE-API-Peek-2.20-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: 1:perl-POE-API-Peek-2.20-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Task-Catalyst
perl-Task-Catalyst has broken dependencies in the F-23 tree: On x86_64: perl-Task-Catalyst-4.02-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Task-Catalyst-4.02-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Task-Catalyst-4.02-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Devel-BeginLift
perl-Devel-BeginLift has broken dependencies in the F-23 tree: On x86_64: perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Devel-BeginLift-0.001003-9.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-BeginLift-0.001003-9.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [389-devel] Review Request for test cases
On 08/06/2015 06:24 AM, Amita Sharma wrote: Hi All, I have automated few test cases for https://fedorahosted.org/389/attachment/ticket/47910/ . Here is my patch :: https://fedorahosted.org/389/attachment/ticket/47910/0001-Ticket-47910-allow-logconv.pl-S-E-switches-to-work-e.2.patch I request for your valuable feedback. Hi Amita, Thanks for writing a lib389 test! I do have some comments, see below... In function log_dir: First, you are using the DATA directory for temporary storage, you should be using the TMP dir - this way the contents are removed for you before the next test runs. ldif_file = topology.standalone.getDir(__file__, TMP_DIR) + ticket47910.ldif - Note, for future tests, if you need to store files permanently, they should be in subdirectories of DATA: getDir(__file__, DATA_DIR) + /ticket47910/ticket47910.ldif - Next in log_dir You are generating an ldif file, and then importing it for each test function. This seems excessive for trying to generate logging. The only thing that is logged is the adding of the task entry. So like 6 lines of logging. It would be easier/faster to just do a single search. You can also disable access log buffering so you don't have to wait for the logging to be written to disk. There is a shortcut function for setting access log buffering: topology.standalone.setAccessLogBuffering (False) You still need to sleep for 1 second, but it's a lot better than 50 seconds. The rest looks good. Thanks, Mark Thanks Regards, Amita -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
F-23 Branched report: 20150806 changes
Compose started at Thu Aug 6 07:15:03 UTC 2015 Broken deps for armhfp -- [apache-scout] apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws) apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:juddi-client) [aws] aws-tools-2015-2.fc23.armv7hl requires libaws_ssl.so [deltaspike] deltaspike-test-utils-1.2.1-3.fc23.noarch requires mvn(org.jboss.arquillian.container:arquillian-container-test-spi) [dpm-contrib-admintools] dpm-contrib-admintools-0.2.1-6.fc23.armv7hl requires MySQL-python(armv7hl-32) [gammaray] gammaray-qt5-2.2.1-10.fc23.armv7hl requires qt5-qtbase(armv7hl-32) = 0:5.4.2 [ghc-hjsmin] ghc-hjsmin-0.1.4.7-7.fc23.armv7hl requires ghc(language-javascript-0.5.13-09e4f74578c09254f3515579177112ae) ghc-hjsmin-devel-0.1.4.7-7.fc23.armv7hl requires ghc-devel(language-javascript-0.5.13-09e4f74578c09254f3515579177112ae) [gnome-python2] gnome-python2-bonobo-2.28.1-16.fc23.armv7hl requires pyorbit(armv7hl-32) = 0:2.0.1 [gnome-shell-extension-pomodoro] gnome-shell-extension-pomodoro-0.11.0-0.3.gitc7ad79d3.fc23.armv7hl requires libgnome-desktop-3.so.10 [gtksourceview-sharp] gtksourceview-sharp-2.0.12-24.fc23.armv7hl requires gtksourceview [hadoop] hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-servlet) hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-mapreduce-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-mapreduce-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-servlet) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-client) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-client) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) [hawaii-shell] hawaii-shell-0.3.0-3.fc22.armv7hl requires libqtaccountsservice-qt5.so.0.1.2 [hbase] hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core) [klavaro] klavaro-3.01-0.pre1.1.fc23.1.armv7hl requires libgtkdataboks.so.0 [mariadb-galera] 1:mariadb-galera-server-10.0.17-5.fc23.armv7hl requires galera = 0:25.3.3 [mesos] mesos-0.22.0-SNAPSHOT.1.c513126.fc22.1.armv7hl requires libprotobuf.so.8 python-mesos-0.22.0-SNAPSHOT.1.c513126.fc22.1.armv7hl requires libprotobuf.so.8 [moon-buggy] moon-buggy-1.0.51-14.fc23.armv7hl requires libesd.so.0 [ncbi-blast+] ncbi-blast+-2.2.31-1.fc23.armv7hl requires libxformat.so ncbi-blast+-2.2.31-1.fc23.armv7hl requires libxcleanup.so ncbi-blast+-2.2.31-1.fc23.armv7hl requires libvalid.so ncbi-blast+-2.2.31-1.fc23.armv7hl requires libpubmed.so ncbi-blast+-2.2.31-1.fc23.armv7hl requires libmlacli.so ncbi-blast+-2.2.31-1.fc23.armv7hl requires libmla.so ncbi-blast+-2.2.31-1.fc23.armv7hl requires libmedlars.so ncbi-blast+-2.2.31-1.fc23.armv7hl requires libgbseq.so [netbeans-platform] 1:netbeans-platform-harness-7.0.1-11.fc22.armv7hl requires cobertura = 0:1.9.3 [nodejs-grunt-contrib-copy] nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(file-sync-cmp) 0:0.2 nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(file-sync-cmp) = 0:0.1.0 nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(chalk) = 0:0.5.1 [nodejs-grunt-saucelabs]
Re: [HEADS-UP] Please test kdbus in Rawhide!
On 07/31/2015 08:49 PM, Lennart Poettering wrote: On Thu, 30.07.15 19:57, Lennart Poettering (mzerq...@0pointer.de) wrote: Heya! I'd like to ask everybody to test kdbus on Rawhide. Josh thankfully added it to the Rawhide kernel packages, and our systemd RPMs come with built-in support, too now. If you are running an up-to-date Rawhide system adding kdbus=1 to your kernel command line is hence everything you need to run kdbus instead of dbus-daemon. (No additional RPMs need to be installed.) If you do, things should just work the same way as before, if we did everything right. By adding or dropping kdbus=1 to/from the command line you can enable kdbus or revert back to dbus1 on each individual boot. Quick update: We have released a new version of systemd now with all bugs reported here fixed. It's also in Rawhide already, but it might not have hit all mirrors yet. To download it directly, please use: http://koji.fedoraproject.org/koji/buildinfo?buildID=674692 And please remember to turn selinux at least into permissive mode when using this, or even turn it off entirely while testing (kdbus=1 selinux=0 on the kernel command line). As you probably know this is not only about a policy fix. We added a support for /sys/fs/kdbus in the latest rawhide policy builds to avoid unlabeled_t issues and we can better track all issues related to kdbusfs_t. But there is no a good policy fix in this state. It requires LSM/SELinux support and without this support it is a completely uncontrolled IPC mechanism. Also some mails about the kdbus development plans and timing would be helpful. Thanks. Mirek Thanks a lot to everybody who already tested this! Please test the new version, any feedback much appreciated! Lennart -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Metadata signing for rawhide
On Thu, Aug 6, 2015 at 8:46 AM, Dennis Gilmore den...@ausil.us wrote: On Thursday, August 06, 2015 08:27:44 AM Neal Gompa wrote: In the rpm-ecosystem mailing list, Michael Schroeder from SUSE brought up that we don't sign the metadata for the rawhide repository http://lists.rpm.org/pipermail/rpm-ecosystem/Week-of-Mon-20150803/000193.ht ml and it would be nice if it was signed so that he could be sure that the mirrors didn't do funny things. Is there a reason we don't sign the rawhide repodata? Forgive me for my ignorance, but do we sign repository metadata at all, and if so, how do we do it I'd like to do that for my own repos too. we do not sign any repodata because it is a a manual step at the end of long running manual processes or at the end of long running fully automated processes. The way that mirrormanager handles metalinks mitigates the need to sign the metadata. you get the md5, sha1, sha256 and sha512 sums and timestamps of the repomd.xml from mirrormanager that is verifiable through https, assuming you trust fedora infrastructure. repomd.xml is the file that tells you the checksums and data for the other files in the repodata. you can then use the repomd.xml file to verify that none of the other metadata has been tampered with. yum and dnf will ignore any mirrors that return invalid data. Dennis What makes you think a site that is poisoning or abusing the metadata would not simply run createrepo and generate entirely new metadata? I've certainly done it, to build tuned repositories with certain core components locked down or replaced from internal repositories and to avoid undesired upgrades from the upstream primary Fedora mirrors. I particularly went through this with different variants of MySQL, samba, ecj, and other Java components whose Requires settings were resolved with the wrong packages for my internal use. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)
On Wed, 5 Aug 2015 10:26:38 -0600, Kevin Fenzi wrote: There is a dnf repoclosure plugin, but not sure how well it works off hand. It seems to be completely broken. :-( It reports lots of available shared libs as unresolved deps. - https://mschwendt.fedorapeople.org/tmp/f22-dnf-repoclosure.txt yum-utils' repoclosure - https://bugzilla.redhat.com/1251037 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: perl-B-Hooks-OP-Check-EntersubForCV
perl-B-Hooks-OP-Check-EntersubForCV has broken dependencies in the F-23 tree: On x86_64: perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires libperl.so.5.20 On armhfp: perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Test-Vars
perl-Test-Vars has broken dependencies in the F-23 tree: On x86_64: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Data-Dump-Streamer
perl-Data-Dump-Streamer has broken dependencies in the F-23 tree: On x86_64: perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Data-Alias
perl-Data-Alias has broken dependencies in the F-23 tree: On x86_64: perl-Data-Alias-1.18-4.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Alias-1.18-4.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Data-Alias-1.18-4.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Alias-1.18-4.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Data-Alias-1.18-4.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Alias-1.18-4.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Method-Signatures
perl-Method-Signatures has broken dependencies in the F-23 tree: On x86_64: perl-Method-Signatures-20141021-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On i386: perl-Method-Signatures-20141021-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On armhfp: perl-Method-Signatures-20141021-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [HEADS-UP] Please test kdbus in Rawhide!
On 08/06/2015 01:47 PM, Miroslav Grepl wrote: On 07/31/2015 08:49 PM, Lennart Poettering wrote: On Thu, 30.07.15 19:57, Lennart Poettering (mzerq...@0pointer.de) wrote: Heya! I'd like to ask everybody to test kdbus on Rawhide. Josh thankfully added it to the Rawhide kernel packages, and our systemd RPMs come with built-in support, too now. If you are running an up-to-date Rawhide system adding kdbus=1 to your kernel command line is hence everything you need to run kdbus instead of dbus-daemon. (No additional RPMs need to be installed.) If you do, things should just work the same way as before, if we did everything right. By adding or dropping kdbus=1 to/from the command line you can enable kdbus or revert back to dbus1 on each individual boot. Quick update: We have released a new version of systemd now with all bugs reported here fixed. It's also in Rawhide already, but it might not have hit all mirrors yet. To download it directly, please use: http://koji.fedoraproject.org/koji/buildinfo?buildID=674692 And please remember to turn selinux at least into permissive mode when using this, or even turn it off entirely while testing (kdbus=1 selinux=0 on the kernel command line). As you probably know this is not only about a policy fix. We added a support for /sys/fs/kdbus in the latest rawhide policy builds to avoid unlabeled_t issues and we can better track all issues related to kdbusfs_t. But there is no a good policy fix in this state. It requires LSM/SELinux support in kernel and without this support it is a completely uncontrolled IPC mechanism. Also some mails about the kdbus development plans and timing would be helpful. Thanks. Mirek Thanks a lot to everybody who already tested this! Please test the new version, any feedback much appreciated! Lennart -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Metadata signing for rawhide
In the rpm-ecosystem mailing list, Michael Schroeder from SUSE brought up that we don't sign the metadata for the rawhide repository http://lists.rpm.org/pipermail/rpm-ecosystem/Week-of-Mon-20150803/000193.html and it would be nice if it was signed so that he could be sure that the mirrors didn't do funny things. Is there a reason we don't sign the rawhide repodata? Forgive me for my ignorance, but do we sign repository metadata at all, and if so, how do we do it I'd like to do that for my own repos too. -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: perl-CatalystX-REPL
perl-CatalystX-REPL has broken dependencies in the rawhide tree: On x86_64: perl-CatalystX-REPL-0.04-10.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-CatalystX-REPL-0.04-10.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-CatalystX-REPL-0.04-10.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Data-Alias
perl-Data-Alias has broken dependencies in the rawhide tree: On x86_64: perl-Data-Alias-1.18-4.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Alias-1.18-4.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Data-Alias-1.18-4.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Alias-1.18-4.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Data-Alias-1.18-4.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Alias-1.18-4.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Data-Dump-Streamer
perl-Data-Dump-Streamer has broken dependencies in the rawhide tree: On x86_64: perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Devel-FindRef
perl-Devel-FindRef has broken dependencies in the rawhide tree: On x86_64: perl-Devel-FindRef-1.44-3.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-FindRef-1.44-3.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Devel-FindRef-1.44-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-FindRef-1.44-3.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Devel-FindRef-1.44-3.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-FindRef-1.44-3.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Test-Vars
perl-Test-Vars has broken dependencies in the rawhide tree: On x86_64: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Test-Vars-0.005-6.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-CGI-Application-Structured-Tools
perl-CGI-Application-Structured-Tools has broken dependencies in the rawhide tree: On x86_64: perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-CGI-Application-Structured-Tools-0.015-7.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Task-Catalyst
perl-Task-Catalyst has broken dependencies in the rawhide tree: On x86_64: perl-Task-Catalyst-4.02-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Task-Catalyst-4.02-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Task-Catalyst-4.02-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Method-Signatures
perl-Method-Signatures has broken dependencies in the rawhide tree: On x86_64: perl-Method-Signatures-20141021-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On i386: perl-Method-Signatures-20141021-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) On armhfp: perl-Method-Signatures-20141021-1.fc22.noarch requires perl(:MODULE_COMPAT_5.20.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-B-Hooks-OP-Check-EntersubForCV
perl-B-Hooks-OP-Check-EntersubForCV has broken dependencies in the rawhide tree: On x86_64: perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires libperl.so.5.20 On armhfp: perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-POE-API-Peek
perl-POE-API-Peek has broken dependencies in the rawhide tree: On x86_64: 1:perl-POE-API-Peek-2.20-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On i386: 1:perl-POE-API-Peek-2.20-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) On armhfp: 1:perl-POE-API-Peek-2.20-8.fc22.noarch requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Carp-REPL
perl-Carp-REPL has broken dependencies in the rawhide tree: On x86_64: perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2) On i386: perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2) On armhfp: perl-Carp-REPL-0.18-1.fc23.noarch requires perl(:MODULE_COMPAT_5.20.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Devel-BeginLift
perl-Devel-BeginLift has broken dependencies in the rawhide tree: On x86_64: perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires libperl.so.5.20()(64bit) On i386: perl-Devel-BeginLift-0.001003-9.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-BeginLift-0.001003-9.fc22.i686 requires libperl.so.5.20 On armhfp: perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: polymake
polymake has broken dependencies in the rawhide tree: On x86_64: polymake-2.13-22.git20141013.fc23.x86_64 requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.x86_64 requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.x86_64 requires libperl.so.5.20()(64bit) On i386: polymake-2.13-22.git20141013.fc23.i686 requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.i686 requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.i686 requires libperl.so.5.20 On armhfp: polymake-2.13-22.git20141013.fc23.armv7hl requires perl(:MODULE_COMPAT_5.20.2) polymake-2.13-22.git20141013.fc23.armv7hl requires perl = 4:5.20.2 polymake-2.13-22.git20141013.fc23.armv7hl requires libperl.so.5.20 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Test-AutoBuild
perl-Test-AutoBuild has broken dependencies in the rawhide tree: On x86_64: perl-Test-AutoBuild-1.2.4-15.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0) On i386: perl-Test-AutoBuild-1.2.4-15.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0) On armhfp: perl-Test-AutoBuild-1.2.4-15.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Metadata signing for rawhide
On Thursday, August 06, 2015 08:27:44 AM Neal Gompa wrote: In the rpm-ecosystem mailing list, Michael Schroeder from SUSE brought up that we don't sign the metadata for the rawhide repository http://lists.rpm.org/pipermail/rpm-ecosystem/Week-of-Mon-20150803/000193.ht ml and it would be nice if it was signed so that he could be sure that the mirrors didn't do funny things. Is there a reason we don't sign the rawhide repodata? Forgive me for my ignorance, but do we sign repository metadata at all, and if so, how do we do it I'd like to do that for my own repos too. we do not sign any repodata because it is a a manual step at the end of long running manual processes or at the end of long running fully automated processes. The way that mirrormanager handles metalinks mitigates the need to sign the metadata. you get the md5, sha1, sha256 and sha512 sums and timestamps of the repomd.xml from mirrormanager that is verifiable through https, assuming you trust fedora infrastructure. repomd.xml is the file that tells you the checksums and data for the other files in the repodata. you can then use the repomd.xml file to verify that none of the other metadata has been tampered with. yum and dnf will ignore any mirrors that return invalid data. Dennis signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1197694] perl-Dancer2-0.158000-1.fc23 FTBFS: t/route-pod-coverage/route-pod-coverage.t test fails
https://bugzilla.redhat.com/show_bug.cgi?id=1197694 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Dancer2-0.16-2.fc2 ||3 Resolution|--- |NEXTRELEASE Last Closed||2015-08-06 08:40:11 -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1249716] rt-4.2.11-1.fc24 FTBFS: Installed (but unpackaged) file(s) found with rpm-4.13
https://bugzilla.redhat.com/show_bug.cgi?id=1249716
Ralf Corsepius rc040...@freenet.de changed:
What|Removed |Added
Status|NEW |ASSIGNED
Component|rt |rpm
Assignee|rc040...@freenet.de |packaging-team-maint@redhat
||.com
--- Comment #3 from Ralf Corsepius rc040...@freenet.de ---
(In reply to Ľuboš Kardoš from comment #2)
The problem is that in a previous version of rpm was bug causing that all
files in %{_pkgdocdir} became part of a package despite the fact that they
wasn't explicitly listed in file list (#728959). We fixed that bug and
changed that behaviour intentionally. I understand that this change of
behaviour is unpleasant for you
Please understand that I do not agree with you. IMO, you FUBARed rpm's %doc
handling.
because it causes FTBS but former behaviour
was broken and we don't plan to revert back to that behaviour.
There was nothing wrong with this package.
It was installing some files into %_pkgdocdir directly and was adding others
using %doc.
This was one way, recommended by the former rpm-maintainer - You broke that!
BTW %doc followed by relative paths of files copies these files from BUILD
to BUILDROOT/%{_pkgdocdir}. And you don't need to do that because this is
already done by your install script (by make install).
You are wrong again.
rt's make install installs a lot of files into %_pkgdocdir. %doc was used to
add some files.
You don't need to use %doc for absolute paths in %{_pkgdocdir} either
because all files in %{_pkgdocdir} are automatically marked as doc files.
For now, I resorted to manually install those files, which used to be %doc and
to use
%files
%{_pkgdocdir}
Also, let me emphasize that I furthon will not step in to fix FTBS in future
mass rebuild because I consider these FTBSes your responsibility, which is why
I am expecting you to fix each and every package yourselves.
Alos, IMO, your change does not fix anything in rpms. To the contrary. You
broke rpm.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)
We discussed with Jan Silhan yesterday. It looks like something broken in createrepo/createrepo_c in F22. So it's not dnf/yum/hawkey/libsolv issue. LOG: https://ignatenkobrain.fedorapeople.org/epoch_bug.log Also CCing Jan. On Thu, Aug 6, 2015 at 4:03 PM Michael Schwendt mschwe...@gmail.com wrote: On Wed, 5 Aug 2015 10:26:38 -0600, Kevin Fenzi wrote: There is a dnf repoclosure plugin, but not sure how well it works off hand. It seems to be completely broken. :-( It reports lots of available shared libs as unresolved deps. - https://mschwendt.fedorapeople.org/tmp/f22-dnf-repoclosure.txt yum-utils' repoclosure - https://bugzilla.redhat.com/1251037 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Igor Gnatenko -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction: Seth Jennings
Greetings! In acordance with the procedure for a first-time packager, I'm annoucing on devel list :) I opened my first review request bug for yubioath-desktop, and GUI and CLI for extracting OTP tokens from a Yubikey. https://bugzilla.redhat.com/show_bug.cgi?id=1251238 I work at Red Hat on one of the kernel development teams. In my spare time though, I like to learn everything I can about open source technologies and Fedora is my platform of choice! I have a Youtube channel where I demonstrate various tasks on Fedora: https://www.youtube.com/channel/UCUMY5vAIUPlKzZm_LEtFUJA My Blog: https://www.variantweb.net/blog/ GPG Fingerprint: 6786 EF89 9CFF 4913 F200 2FE2 9622 D5C8 C1AC F915 I look forward to contributing! Seth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Agenda for Env-and-Stacks WG meeting (2015-08-06)
Meeting started at #fedora-meeting-1, we had collision at #fedora-meeting-2.. Honza On 08/06/2015 11:59 AM, Honza Horak wrote: WG meeting will be at 17:00 UTC (13:00 EST, 19:00 Brno, 13:00 Boston, 2:00+1d Tokyo, 3:00+1d Brisbane) in #fedora-meeting-2 on Freenode. = Topics = * Fedora.next and how communicate between containers / stacks * Rings in Fedora 24 - documentation would be awesome * Taiga.io - could it be used to track features/projects and it's progress? * Open Floor ___ env-and-stacks mailing list env-and-sta...@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gpg keys of older/newer fedora versions
On 08/05/2015 09:58 PM, Christopher Meng wrote: On 7/18/15, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: I thought I'd ask here first: is there a strong reason *not* to include those keys? It's not recommended to encourage end users installing EOL releases. I don't see how this affects people installing old releases either way. It's easy to install any release. Just point to the right repo, the keys are included. Is there some other aspect to this that I'm missing? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)
On Thu, 6 Aug 2015 18:00:23 +, Zbigniew Jędrzejewski-Szmek wrote:
It couldn't find a comment in the source that would tell whether this
is by design.
Does this really matter? If it's by design, then the design is wrong.
If not, than the implementation is wrong.
It doesn't matter much, except that I fear dilettantism related to
handling corner-cases and lack of error handling. :-/ Not verifying
input data is the reason for many security vulnerabilities even.
I thought that in the XML repodata, epoch=-1 instead of epoch=0 would
have been possible, too, and would not resolve. (whereas no Epoch and Epoch
0
are treated as equal by definition)
However, rpmbuild doesn't care much about the EVR in versioned deps.
It accepts weird EVR specifiers, such as
Requires: badepoch = 1a:2b:3c-4-0-1-2-3
and successfully builds the package, only printing this:
# warning: line 13: Invalid version (double separator ':'):
1a:2b:3c-4-0-1-2-3: Requires: badepoch = 1a:2b:3c-4-0-1-2-3
It even happily builds a spec file that contains
Requires: badepoch = -1
and
Requires: badepoch = -1:1
and createrepo_c turns that into epoch=-1 ver=1. *sigh* ;-)
On the contrary, rpmbuild rejects spec files with a non-positive Epoch.
So, errors (even if they may be only corner-cases), propagate through the
various tools causing unpredictable symptoms.
Even after a real undefined %epoch in released packages, one can only
hope that some of this is purely theoretical:
Requires: %{depname} = %{depepoch}x:%{depminver}
It's possible today. An accidentally inserted 'x' at the wrong place,
rpmbuild would happily build it, and repoclosure would not detect it
as unresolvable, because in the metadata it becomes epoch=0.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)
On Thu, Aug 06, 2015 at 06:37:29PM +0200, Michael Schwendt wrote: On Thu, 06 Aug 2015 13:15:02 +, Igor Gnatenko wrote: We discussed with Jan Silhan yesterday. It looks like something broken in createrepo/createrepo_c in F22. So it's not dnf/yum/hawkey/libsolv issue. LOG: https://ignatenkobrain.fedorapeople.org/epoch_bug.log Also CCing Jan. Wow. createrepo is also affected. createrepo_c uses strtol() to accept only numbers as Epoch. Anything else strol() cannot parse is ignored and defaults to epoch=0 in the repo metadata. This means it can break for typos as well as, not just an undefined macro used as Epoch in a versioned dep. It couldn't find a comment in the source that would tell whether this is by design. Does this really matter? If it's by design, then the design is wrong. If not, than the implementation is wrong. (Nevertheless, I think it's not by design, but because strtol() is so hard to use correctly. I think it's fair to say to it is designed to be used incorrectly. Systemd has a bunch of wrappers for strto*() that try to answer the question was the conversion successful? [1], and it's sad that they are needed and that they are so complex.) [1] https://github.com/systemd/systemd/blob/73974f6768e#L406 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gpg keys of older/newer fedora versions
On Thu, Aug 06, 2015 at 12:58:36PM +0800, Christopher Meng wrote: On 7/18/15, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: I thought I'd ask here first: is there a strong reason *not* to include those keys? It's not recommended to encourage end users installing EOL releases. However a seperate package for gpg keys from EOL releases is OK. But is it worthwhile to move these keys out from mock? I think it is, for two reasons: 1. keys in mock are in a mock specific directory, so dnf doesn't know about them. I'd like things to work out-of-the-box, without the need to manually adjusts paths or copy keys around. 2. mock is at a higher level in the stack. It has different purpose, gives privileges to some users, has additional functionality, etc. Mock also pulls in some packaging tools, including both dnf and yum. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Guidelines change] Changes to the packaging guidelines
On Thu, Aug 06, 2015 at 10:03:00AM -0400, Robert Kuska wrote: - Original Message - From: Jason L Tibbitts III ti...@math.uh.edu To: devel-annou...@lists.fedoraproject.org Sent: Tuesday, August 4, 2015 11:34:06 PM Subject: [Guidelines change] Changes to the packaging guidelines Here are the recent changes to the packaging guidelines. - The big change is that the Python guidelines have been extensively reorganized and partially rewritten, and new macros are available which simplify packaging by removing some of the boilerplate which was previously required. The main guideline page has been slimmed down to show the more basic info and a clean and simple spec using the new macros which is free of multiline conditionals. boilerplate previously associated with python packages. Some of the more esoteric information has been moved to an appendix page to keep the main page of reasonable size. The new guidelines are currently only functional on Fedora 22 and newer releases, but are currently in updates-testing for Fedora 21 and EPEL7. The older guidelines are preserved in a separate page and we'll try to keep them updated with new requirements. The new guidelines page: * https://fedoraproject.org/wiki/Packaging:Python Sorry for late reply. From the Python packaging: # Must do the python2 install first because the scripts in /usr/bin are # overwritten with every setup.py install, and in general we want the # python3 version to be the default. %py2_install %py3_install I don't think that binaries of python module should be already switched to the state that non versioned binary is python3 binary. This problem is covered extensively in the guidelines: If the executables provide the same functionality independent of whether they are run on top of Python 2 or Python 3, then only one version of the executable should be packaged. On releases up to and including F21, this was the python 2 implementation. Python3 should be used in F22 and later if supported by upstream. [...] Transitioning from python2 to python3 is left to individual package maintainers[...] The switch as default was accepted as https://fedoraproject.org/wiki/Changes/Python_3_as_Default. While /usr/bin/python points to /usr/bin/python2 and python-foo provides python2 version of the foo package I would expect binary foo to run on python2. Fedora is finally switching to Python 3. E.g. /usr/bin/dnf now uses Python 3, and a lot of other things also. This applies for modules binaries such as pytest (nosetests, pip, ...) where is difference between running python2 and python3 version of the binary. For those cases guidelines say that both versions should be packaged. Currently we should have non versioned binaries to run on python3 only for python applications (devassistant) where both python2 and python3 version of the application provide same functionality. Yes. Therefore I suggest to switch order of pyX_install macros. Eeee, no. Let's use Python 3 by default. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Agenda for Env-and-Stacks WG meeting (2015-08-06)
Canceled, only phracek and me showed up.. Honza On 08/06/2015 07:07 PM, Honza Horak wrote: Meeting started at #fedora-meeting-1, we had collision at #fedora-meeting-2.. Honza On 08/06/2015 11:59 AM, Honza Horak wrote: WG meeting will be at 17:00 UTC (13:00 EST, 19:00 Brno, 13:00 Boston, 2:00+1d Tokyo, 3:00+1d Brisbane) in #fedora-meeting-2 on Freenode. = Topics = * Fedora.next and how communicate between containers / stacks * Rings in Fedora 24 - documentation would be awesome * Taiga.io - could it be used to track features/projects and it's progress? * Open Floor ___ env-and-stacks mailing list env-and-sta...@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks ___ env-and-stacks mailing list env-and-sta...@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Metadata signing for rawhide
Nico Kadel-Garcia wrote: What makes you think a site that is poisoning or abusing the metadata would not simply run createrepo and generate entirely new metadat But then it wouldn't match the metalink timestamps or checksums, that Dennis mentioned either. Or am I missing something? -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Guidelines change] Changes to the packaging guidelines
- Original Message - From: Jason L Tibbitts III ti...@math.uh.edu To: devel-annou...@lists.fedoraproject.org Sent: Tuesday, August 4, 2015 11:34:06 PM Subject: [Guidelines change] Changes to the packaging guidelines Here are the recent changes to the packaging guidelines. - The big change is that the Python guidelines have been extensively reorganized and partially rewritten, and new macros are available which simplify packaging by removing some of the boilerplate which was previously required. The main guideline page has been slimmed down to show the more basic info and a clean and simple spec using the new macros which is free of multiline conditionals. boilerplate previously associated with python packages. Some of the more esoteric information has been moved to an appendix page to keep the main page of reasonable size. The new guidelines are currently only functional on Fedora 22 and newer releases, but are currently in updates-testing for Fedora 21 and EPEL7. The older guidelines are preserved in a separate page and we'll try to keep them updated with new requirements. The new guidelines page: * https://fedoraproject.org/wiki/Packaging:Python Sorry for late reply. From the Python packaging: # Must do the python2 install first because the scripts in /usr/bin are # overwritten with every setup.py install, and in general we want the # python3 version to be the default. %py2_install %py3_install I don't think that binaries of python module should be already switched to the state that non versioned binary is python3 binary. While /usr/bin/python points to /usr/bin/python2 and python-foo provides python2 version of the foo package I would expect binary foo to run on python2. This applies for modules binaries such as pytest (nosetests, pip, ...) where is difference between running python2 and python3 version of the binary. Currently we should have non versioned binaries to run on python3 only for python applications (devassistant) where both python2 and python3 version of the application provide same functionality. Therefore I suggest to switch order of pyX_install macros. The appendix: * https://fedoraproject.org/wiki/Packaging:Python_Appendix The old guidelines: * https://fedoraproject.org/wiki/Packaging:Python_Old Note that these cleaned up pages (and the old copy) include some new guidelines as well: There is new section indicating that -OO must not be used for python versions less than 3.5. * https://fedoraproject.org/wiki/Packaging:Python#Optimization There are requirements for what python module packages must provide (via Provides:): * https://fedoraproject.org/wiki/Packaging:Python#Provides Related FPC tickets: * https://fedorahosted.org/fpc/ticket/281 * https://fedorahosted.org/fpc/ticket/534 * https://fedorahosted.org/fpc/ticket/542 * https://fedorahosted.org/fpc/ticket/545 * https://fedorahosted.org/fpc/ticket/552 - Guidelines have been added covering services which need to perform setup when they are first started (including self-signed certificate generation). *https://fedoraproject.org/wiki/Packaging:Initial_Service_Setup *https://fedorahosted.org/fpc/ticket/506 - The guideline on spec file naming was moved into the main guidelines and now requires that its name be constructed by taking the name of the source package and appending .spec. * https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_File_Naming * https://fedorahosted.org/fpc/ticket/553 - FPC can now grant exceptions to the regular package review procedures. * https://fedoraproject.org/wiki/Packaging_Committee#Review_Process_Exemption_Procedure * https://fedorahosted.org/fpc/ticket/539 * https://fedorahosted.org/fesco/ticket/1435 ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1221832] perl-Dancer2-0.161000 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1221832 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppi...@redhat.com Assignee|dd...@cpan.org |ppi...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1221832] perl-Dancer2-0.161000 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1221832 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Depends On||1230227 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1230227 [Bug 1230227] Review Request: perl-HTTP-Headers-Fast - Faster implementation of HTTP::Headers -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
ppisar uploaded Dancer2-0.161000.tar.gz for perl-Dancer2
8ff7455ec32635e261e8d0b9e3102b52 Dancer2-0.161000.tar.gz http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Dancer2/Dancer2-0.161000.tar.gz/md5/8ff7455ec32635e261e8d0b9e3102b52/Dancer2-0.161000.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1221832] perl-Dancer2-0.161000 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1221832 --- Comment #12 from Petr Pisar ppi...@redhat.com --- This requires not yet packaged HTTP::Headers::Fast. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Reminder: Fedora 23 Alpha Release Readiness Meeting, Thursday, August 06 @ 19:00 UTC
Just a reminder: Today we will meet to make sure we are coordinated and ready for the Alpha release of Fedora 23. Please join us at 19:00 UTC (3 PM EDT, 12 AM PDT, 21:00 CEST) on fedora-meetin...@irc.freenode.net channel. [FedoCal] https://apps.fedoraproject.org/calendar/meeting/2630/ Thanks for joining, Jan - Original Message - From: Jan Kurik jku...@redhat.com To: Fedora Logistics List logist...@lists.fedoraproject.org, ambassadors ambassad...@lists.fedoraproject.org, Fedora Design Team design-t...@lists.fedoraproject.org, docs d...@lists.fedoraproject.org, Fedora Marketing team market...@lists.fedoraproject.org, For testing and quality assurance of Fedora releases t...@lists.fedoraproject.org, Paul W. Frields pfrie...@redhat.com, Matthew Miller mat...@fedoraproject.org, dennis den...@ausil.us, Fedora Websites Team websi...@lists.fedoraproject.org, Fedora Translation Project List tr...@lists.fedoraproject.org, devel-annou...@lists.fedoraproject.org Sent: Monday, August 3, 2015 6:08:51 PM Subject: Re: Fedora 23 Alpha Release Readiness Meeting, Thursday, August 06 @ 19:00 UTC - Original Message - From: Jan Kurik jku...@redhat.com To: Fedora Logistics List logist...@lists.fedoraproject.org, ambassadors ambassad...@lists.fedoraproject.org, Fedora Design Team design-t...@lists.fedoraproject.org, docs d...@lists.fedoraproject.org, Fedora Marketing team market...@lists.fedoraproject.org, For testing and quality assurance of Fedora releases t...@lists.fedoraproject.org, Paul W. Frields pfrie...@redhat.com, Matthew Miller mat...@fedoraproject.org, dennis den...@ausil.us, Fedora Websites Team websi...@lists.fedoraproject.org, Fedora Translation Project List tr...@lists.fedoraproject.org, devel-annou...@lists.fedoraproject.org Sent: Monday, August 3, 2015 4:36:24 PM Subject: Fedora 23 Alpha Release Readiness Meeting, Thursday, August 06 @ 19:00 UTC Fedora 23 Alpha Release Readiness Meeting. date: 2015-08-06 place: irc.freenode.net in #fedora-meeting-2 time: 19:00 UTC (2 PM EST, 11 AM PST, 20:00 CET) I am sorry. I failed to correctly convert timezones. The correct time is: time: 19:00 UTC (3 PM EDT, 12 AM PDT, 21:00 CEST) Regards, Jan This Thursday, August 06, we will meet to make sure we are coordinated and ready for the Alpha release of Fedora 23 on Tuesday, August 11, 2015. Please note that this meeting will occur on August 06 even if the release is delayed at the Go/No-Go meeting on the same day two hours earlier. You may received this message several times, but I was asked to open this meeting to the teams and I'll also hope this will raise awareness and more team representatives will come to this meeting. This meeting works best when we have representatives from all of the teams. Regards, Jan [FedoCal] https://apps.fedoraproject.org/calendar/Fedora%20release/#m2630 -- Jan Kuřík -- Jan Kuřík ___ logistics mailing list logist...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/logistics -- Jan Kuřík -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Reminder: Fedora 23 Alpha Go/No-Go Meeting, Thursday, August 06 @ 17:00 UTC
Just a reminder: Today we will meet to determine the readiness of the Fedora 23 Alpha. Please join us at 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST) on fedora-meetin...@irc.freenode.net channel. [FedoCal] https://apps.fedoraproject.org/calendar/meeting/2629/ Thanks for joining, Jan - Original Message - From: Jan Kurik jku...@redhat.com To: test-annou...@lists.fedoraproject.org Sent: Monday, August 3, 2015 6:31:44 PM Subject: Fedora 23 Alpha Go/No-Go Meeting, Thursday, August 06 @ 17:00 UTC Join us on irc.freenode.net in #fedora-meeting-2 for this important meeting, wherein we shall determine the readiness of the Fedora 23 Alpha. Thursday, August 06, 2015 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST) 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. We don't have RC yet as the list of accepted blockers is still pretty long. If you have any bug on the list, please help us with Alpha release. If we won't be ready by Thursday, we will use this meeting to review blockers and decide what to do. For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 23 Alpha Blocker list: http://qa.fedoraproject.org/blockerbugs/milestone/23/alpha/buglist Regards, Jan [FedoCal] https://apps.fedoraproject.org/calendar/meeting/2629/ -- Jan Kuřík -- Jan Kuřík -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Validity of i686 as a release blocker
On 6 August 2015 at 10:04, Pete Travis li...@petetravis.com wrote: \ Perhaps the best approach, from a community perspective, would be to promote a spin to Edition status and recommend *that* for i686 or low resource desktop use cases. --Pete That would require people volunteering to dedicate time to working on it. Are you volunteering to start this? -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] Fedora 23 Alpha Release Candidate 2 (RC2) Available Now!
Somewhat later than scheduled [1], Fedora 23 Alpha Release Candidate 2 (RC2) is now available for testing. Please help us complete as much of the validation testing as we can! Unfortunately there looks to already be a known blocker - https://bugzilla.redhat.com/show_bug.cgi?id=1250874 - but it would still be valuable to cover all Alpha tests. No-one needs to kill themselves working on it, though! Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/6213#comment:8 . Please see the following pages for download links and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download- ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Workstation and Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Server: https://fedoraproject.org/wiki/Test_Results:Current_Server_Test Cloud: https://fedoraproject.org/wiki/Test_Results:Current_Cloud_Test Summary: https://fedoraproject.org/wiki/Test_Results:Current_Summary All Alpha priority test cases for each of these test pages [2] must pass in order to meet the Alpha Release Criteria [3]. We are also trying to run the Beta and Final tests at this time, to try and identify later release blocker bugs as early as possible. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Create Fedora 23 Alpha test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/6213 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-23/f-23-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_23_Alpha_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://admin.fedoraproject.org/mailman/listinfo/test -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Metadata signing for rawhide
On Thursday, August 06, 2015 08:29:50 AM Rex Dieter wrote: Nico Kadel-Garcia wrote: What makes you think a site that is poisoning or abusing the metadata would not simply run createrepo and generate entirely new metadat But then it wouldn't match the metalink timestamps or checksums, that Dennis mentioned either. Or am I missing something? Exactly. it would only bite a user that had switched from the metalink urls shipped by default to something else. Dennis signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Validity of i686 as a release blocker
On Tue, Aug 04, 2015 at 10:40:28 -0400, Paul W. Frields sticks...@gmail.com wrote: Ambivalent is probably understated here. It's hard to imagine people securing i686 hardware these days to run a Workstation experience, after all. I still use i686 for my primary server, primary desktop and primary laptop. I just don't hit install issues as I rarely due fresh install on those machines. I do try to help debug kernel issues. I am unlikely to buy i686 hardware, but I might scrounge some if I could get it for free. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1250373] perl-Spreadsheet-WriteExcel and Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250373 Tom spot Callaway tcall...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Blocks|182235 (FE-Legal) | Resolution|--- |NOTABUG Last Closed||2015-08-06 11:56:37 --- Comment #2 from Tom spot Callaway tcall...@redhat.com --- The use of the trademark excel is nominative here, since we are using it in a minimal way to describe this applications support and manipulation of the excel file format. Thus, the use is considered fair use and appropriate. Lifting FE-Legal and closing this bug. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=182235 [Bug 182235] Fedora Legal Tracker -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250372] perl-Spreadsheet-ParseExcel-Simple and Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250372 Tom spot Callaway tcall...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED CC||tcall...@redhat.com Blocks|182235 (FE-Legal) | Resolution|--- |NOTABUG Last Closed||2015-08-06 11:57:07 --- Comment #2 from Tom spot Callaway tcall...@redhat.com --- The use of the trademark excel is nominative here, since we are using it in a minimal way to describe this applications support and manipulation of the excel file format. Thus, the use is considered fair use and appropriate. Lifting FE-Legal and closing this bug. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=182235 [Bug 182235] Fedora Legal Tracker -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250375] perl-Spreadsheet-WriteExcel-Simple and Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250375 Tom spot Callaway tcall...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED CC||tcall...@redhat.com Blocks|182235 (FE-Legal) | Resolution|--- |NOTABUG Last Closed||2015-08-06 11:56:02 --- Comment #2 from Tom spot Callaway tcall...@redhat.com --- The use of the trademark excel is nominative here, since we are using it in a minimal way to describe this applications support and manipulation of the excel file format. Thus, the use is considered fair use and appropriate. Lifting FE-Legal and closing this ticket. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=182235 [Bug 182235] Fedora Legal Tracker -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250365] perl-Spreadsheet-ParseExcel and Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250365 Tom spot Callaway tcall...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED CC||tcall...@redhat.com Blocks|182235 (FE-Legal) | Resolution|--- |NOTABUG Last Closed||2015-08-06 11:59:43 --- Comment #2 from Tom spot Callaway tcall...@redhat.com --- The use of the trademark excel is nominative here, since we are using it in a minimal way to describe this applications support and manipulation of the excel file format. Thus, the use is considered fair use and appropriate. Lifting FE-Legal and closing this bug. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=182235 [Bug 182235] Fedora Legal Tracker -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1250360] perl-DateTime-Format-Excel and Trademark problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1250360 Tom spot Callaway tcall...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED CC||tcall...@redhat.com Blocks|182235 (FE-Legal) | Resolution|--- |NOTABUG Last Closed||2015-08-06 12:01:16 --- Comment #2 from Tom spot Callaway tcall...@redhat.com --- The use of the trademark excel is nominative here, since we are using it in a minimal way to describe this applications support and manipulation of the excel file format. Thus, the use is considered fair use and appropriate. Lifting FE-Legal and closing this bug. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=182235 [Bug 182235] Fedora Legal Tracker -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Validity of i686 as a release blocker
On Aug 4, 2015 9:40 AM, Paul W. Frields sticks...@gmail.com wrote: On Tue, Aug 04, 2015 at 09:47:27AM -0400, Josh Boyer wrote: [...snip...] Perhaps it is time that we evaluate where i686 stands in Fedora more closely. For a starting suggestion, I would recommend that we do not treat it as a release blocking architecture. This is not the same as demotion to secondary architecture status. That has broader implications in both buildsys and ecosystem. My suggestion is narrowly focused so that builds still proceed as today, but if there is something broken for i686 it does not block the release of whatever milestone we are pursuing. (To be clear, I would support a move to secondary arch status for i686, but I am not suggesting it at this time.) So to put a finer point on this, our shipping i686 images depends on a broader community effort beyond the kernel maintainers in the Fedora Engineering team. That needs to precisely not mean more heroics on the part of e.g. QE, rel-eng, etc. I have no idea what the pushback on this issue is, but I'm sure this thread will tell us. But given that Fedora is supposed to encourage such community effort, it would be good to see what people are willing to do to build it. Making i686 non-release blocking would actually match reality. None of the Fedora Editions appear at all concerned with i686. Cloud is demoting[3] i686 from its offering. Workstation has been fairly ambivalent about it and recommends x86_64. Server does the same. Given the lack of focus on it, and the fact that the broader community is not testing the development releases for i686, I believe this would be a good first step. Ambivalent is probably understated here. It's hard to imagine people securing i686 hardware these days to run a Workstation experience, after all. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1247382 [2] https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html [3] https://fedorahosted.org/cloud/ticket/106 -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- Perhaps the best approach, from a community perspective, would be to promote a spin to Edition status and recommend *that* for i686 or low resource desktop use cases. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
