Self-Introduction / Review requests: ocaml dependencies of 0install
Dear all, First of all, a short self-introduction -- I've been a Fedora packager for several years, though with only an intermittent involvement with OCaml packaging (Richard might remember my previous attempt to package Jocaml). One of the packages I maintain, 0install (http://0install.net) has recently been rewritten in a combination of OCaml and Python, and several of its OCaml dependencies are not yet available in Fedora. As such I've taken the trouble to get them packaged, and now need help getting them reviewed: * ocaml-easy-format - High-level and functional interface to the Format module https://bugzilla.redhat.com/show_bug.cgi?id=1055391 * ocaml-biniou - Safe and fast binary data format https://bugzilla.redhat.com/show_bug.cgi?id=1055393 * ocaml-cppo - Equivalent of the C preprocessor for OCaml programs https://bugzilla.redhat.com/show_bug.cgi?id=1055394 * ocaml-xmlm - A streaming XML codec https://bugzilla.redhat.com/show_bug.cgi?id=1055395 * ocaml-yojson - An optimized parsing and printing library for the JSON format https://bugzilla.redhat.com/show_bug.cgi?id=1055396 * 0install - A decentralized cross-distribution software installation system https://bugzilla.redhat.com/show_bug.cgi?id=1055398 (rename/re-review request from zeroinstall-injector) Let me know if I can in turn help review other submissions. Best regards, -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: michel-...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ ocaml-devel mailing list ocaml-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
EPEL Inconsistents names of branches in git
Hello, During my work with my EPEL package I have find out an inconsistent naming of the EPEL branches. For EPEL-6 the branch is named as el6 but for EPEL-7 it's named as epel7. So I would like to ask, is there any reseaons for this naming? Best Regards: Jochen Schmitt ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Inconsistents names of branches in git
Hi, During my work with my EPEL package I have find out an inconsistent naming of the EPEL branches. For EPEL-6 the branch is named as el6 but for EPEL-7 it's named as epel7. So I would like to ask, is there any reseaons for this naming? It seems like it was to avoid confusion with RHEL: https://lists.fedoraproject.org/pipermail/epel-devel/2013-December/008943.html Rich -- Richard Fearn richardfe...@gmail.com ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: sunpinyin
On Jan 15, 2014 10:19 PM, Michael Schwendt mschwe...@gmail.com wrote: Anyone being familiar with sunpinyin please help with this re-review: https://bugzilla.redhat.com/1043504 Well, the assignee is one of the Chinese packagers, still active in chinese list. I will see what I can do. -- 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: directfb, fusionsound packaged, review for submition and sdl2 bridge
On Sun, Jan 19, 2014 at 4:55 AM, Juan Manuel Borges Caño juanmabcm...@gmail.com wrote: The packages built okay without the optional kernel module (to know, linux-fusion is the one), if that turns to be obligatory, again, i'd take alsa packaging as a cool example :) ALSA kernel modules are included in the upstream kernel, AFAIK DirectFB ones are not. In order to be included in Fedora, they need to be upstream or Fedora kernel maintainers convinced to ship them within the kernel package. http://fedoraproject.org/wiki/Packaging:KernelModules -- 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: directfb, fusionsound packaged, review for submition and sdl2 bridge
Hi, On Sun, Jan 19, 2014 at 10:16 AM, Ville Skyttä ville.sky...@iki.fi wrote: On Sun, Jan 19, 2014 at 4:55 AM, Juan Manuel Borges Caño juanmabcm...@gmail.com wrote: The packages built okay without the optional kernel module (to know, linux-fusion is the one), if that turns to be obligatory, again, i'd take alsa packaging as a cool example :) ALSA kernel modules are included in the upstream kernel, AFAIK DirectFB ones are not. In order to be included in Fedora, they need to be upstream or Fedora kernel maintainers convinced to ship them within the kernel package. http://fedoraproject.org/wiki/Packaging:KernelModules It should be possible to build DirectFB-multi without the linux-fusion kernel module, so that's reverting to shmem and UNIX sockets for IPC. I remember I saw fixes for Fusion userspace posted against the -1.7 branch. Ilyes -- 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
Re: SELinux RPM scriplet issue annoucement
On Sat, Jan 18, 2014 at 11:47:37PM -0500, Rahul Sundaram wrote: On Sat, Jan 18, 2014 at 8:20 PM, Andre Robatino wrote: I replaced the typo scriplet - scriptlet in several places in that page, including the anchor link. Don't know if that breaks any existing links. Thanks. I just sent out the announcement. Hopefully it makes sense. The text of the announcement made sense, but the link doesn't point to anything -- https://fedoraproject.org/wiki/Common_F20_bugs exists, but https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriplets_fail_during_updates doesn't point to anything on the page. smime.p7s Description: S/MIME cryptographic signature -- 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: SELinux RPM scriplet issue annoucement
On Sun, 19 Jan 2014 12:23:42 -0500 Scott Schmit i.g...@comcast.net wrote: The text of the announcement made sense, but the link doesn't point to anything -- https://fedoraproject.org/wiki/Common_F20_bugs exists, but https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriplets_fail_during_updates doesn't point to anything on the page. Points to this: RPM scriptlets fail during updates Just clicked on it. ___ Regards, Frank www.frankly3d.com -- 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: SELinux RPM scriplet issue annoucement
On Sun, Jan 19, 2014 at 12:23:42PM -0500, Scott Schmit wrote: On Sat, Jan 18, 2014 at 11:47:37PM -0500, Rahul Sundaram wrote: On Sat, Jan 18, 2014 at 8:20 PM, Andre Robatino wrote: I replaced the typo scriplet - scriptlet in several places in that page, including the anchor link. Don't know if that breaks any existing links. Thanks. I just sent out the announcement. Hopefully it makes sense. The text of the announcement made sense, but the link doesn't point to anything -- https://fedoraproject.org/wiki/Common_F20_bugs exists, but https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriplets_fail_during_updates doesn't point to anything on the page. Weird -- I loaded the page again and now it shows up, but I still have it in another tab the other way, so I know it wasn't just that I had missed it. Maybe there are multiple mirrors at play that aren't all in sync? smime.p7s Description: S/MIME cryptographic signature -- 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: SELinux RPM scriplet issue annoucement
On Sun, 19 Jan 2014 12:23:42 -0500 Scott Schmit i.g...@comcast.net wrote: On Sat, Jan 18, 2014 at 11:47:37PM -0500, Rahul Sundaram wrote: On Sat, Jan 18, 2014 at 8:20 PM, Andre Robatino wrote: I replaced the typo scriplet - scriptlet in several places in that page, including the anchor link. Don't know if that breaks any existing links. Thanks. I just sent out the announcement. Hopefully it makes sense. The text of the announcement made sense, but the link doesn't point to anything -- https://fedoraproject.org/wiki/Common_F20_bugs exists, but https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriplets_fail_during_updates ^ Got it you have the wrong link, that is not the one posted in announce from announce https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriptlets_fail_during_updates ^^ ___ Regards, Frank www.frankly3d.com -- 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: SELinux RPM scriplet issue annoucement
On Sat, Jan 18, 2014 at 9:47 PM, Rahul Sundaram methe...@gmail.com wrote: Hi Since updates don't automatically fix the issue created by https://bugzilla.redhat.com/show_bug.cgi?id=1054350 and users are required to run a set of steps as a workaround, shouldn't this be announced via the fedora announce list and posted in the Fedora website prominently as well? So it happened .. how do we prevent it in the future? How did it pass testing? -- 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: SELinux RPM scriplet issue annoucement
On Sun, 2014-01-19 at 19:15 +0100, drago01 wrote: On Sat, Jan 18, 2014 at 9:47 PM, Rahul Sundaram methe...@gmail.com wrote: Hi Since updates don't automatically fix the issue created by https://bugzilla.redhat.com/show_bug.cgi?id=1054350 and users are required to run a set of steps as a workaround, shouldn't this be announced via the fedora announce list and posted in the Fedora website prominently as well? So it happened .. how do we prevent it in the future? How did it pass testing? Should we modify rpm so scriptlet failures aren't fatal? This is the second time in the last six months or so that I've seen scriptlet failures cause major update problems in Fedora, solely because they are fatal (see https://bugzilla.redhat.com/show_bug.cgi?id=989145). If scriptlet failures weren't fatal, we wouldn't have the problem we have now with duplicate packages. We could have just pushed the selinux update, then bumped the release for all updates in the last few pushes, and then rebuilt them. If some of the scriptlets were vitally important, they would get run with the new updates. Am I missing something? Is there any reason why scriptlet failures should be fatal? Jonathan -- 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: SELinux RPM scriplet issue annoucement
On Sun, 19 Jan 2014 19:15:35 +0100 drago01 drag...@gmail.com wrote: So it happened .. how do we prevent it in the future? How did it pass testing? I don't think it got manually tested. ___ Regards, Frank www.frankly3d.com -- 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: SELinux RPM scriplet issue annoucement
On Sun, 19 Jan 2014 19:15:35 +0100, drago01 wrote: So it happened .. how do we prevent it in the future? How did it pass testing? A first +1 vote 22 hours _before_ it entered the updates-testing repo. A second +1 vote eight hours _before_ it entered the updates-testing repo. A third +1 vote and automatic push to stable two hours after it had entered updates-testing: https://admin.fedoraproject.org/updates/FEDORA-2014-0806/selinux-policy-3.12.1-116.fc20 It has not been offered long enough for more testers to give it a try. For example, here it had not been picked up by the nearby mirror yet when the karma threshold was reached. By the time it had arrived and the first scriptlet errors were noticed and required a closer look to find the culprit, the update had been pushed to stable already. How to prevent it from happening in the future? The update criteria for the so-called critical path packages could be made more strict. A minimum time for updates to stay in the updates-testing repo. A higher karma threshold probably won't be sufficient, if testers aim at speed instead of safety. -- 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: SELinux RPM scriplet issue annoucement
On Sun, Jan 19, 2014 at 7:34 PM, Michael Schwendt mschwe...@gmail.com wrote: On Sun, 19 Jan 2014 19:15:35 +0100, drago01 wrote: So it happened .. how do we prevent it in the future? How did it pass testing? A first +1 vote 22 hours _before_ it entered the updates-testing repo. A second +1 vote eight hours _before_ it entered the updates-testing repo. A third +1 vote and automatic push to stable two hours after it had entered updates-testing: https://admin.fedoraproject.org/updates/FEDORA-2014-0806/selinux-policy-3.12.1-116.fc20 It has not been offered long enough for more testers to give it a try. For example, here it had not been picked up by the nearby mirror yet when the karma threshold was reached. By the time it had arrived and the first scriptlet errors were noticed and required a closer look to find the culprit, the update had been pushed to stable already. OK. How to prevent it from happening in the future? The update criteria for the so-called critical path packages could be made more strict. A minimum time for updates to stay in the updates-testing repo. A higher karma threshold probably won't be sufficient, if testers aim at speed instead of safety. Yeah that makes sense. (Automated tests that do test basic stuff would help as well). -- 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: SELinux RPM scriplet issue annoucement
Hi On Sun, Jan 19, 2014 at 1:34 PM, Michael Schwendt wrote: How to prevent it from happening in the future? The update criteria for the so-called critical path packages could be made more strict. A minimum time for updates to stay in the updates-testing repo. A higher karma threshold probably won't be sufficient, if testers aim at speed instead of safety. Sounds reasonable. Filed a ticket at https://fedorahosted.org/fesco/ticket/1223 Rahul -- 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: SELinux RPM scriplet issue annoucement
On Sun, 19 Jan 2014 19:15:35 +0100 drago01 drag...@gmail.com wrote: So it happened .. how do we prevent it in the future? How did it pass testing? Would a gui yumex\PK have burped at the update? Would the two testers have seen the script errors. ___ Regards, Frank www.frankly3d.com -- 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: SELinux RPM scriplet issue annoucement
On Sun, 19 Jan 2014 20:32:26 +0200, Jonathan Dieter wrote: If scriptlet failures weren't fatal, we wouldn't have the problem we have now with duplicate packages. We could have just pushed the selinux update, After installing the previous bad update that breaks scriptlets, how would you activate the new selinux policy within the fixed package's %post scriptlet? Instead of updating to the package in permissive mode, you would need to run the scriptlet contents manually *and* still reinstall any package were the scriptlets failed. [...] then bumped the release for all updates in the last few pushes, and then rebuilt them. How do you know which packages a user has tried to install/update _after_ updating to the bad policy package? It could be any package within the package collection that would remain installed but broken because of the scriptlets bug. You assume that users have only applied the few updates following the bad selinux policy update. -- 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: SELinux RPM scriplet issue annoucement
On Sun, Jan 19, 2014 at 7:32 PM, Jonathan Dieter jdie...@lesbg.com wrote: On Sun, 2014-01-19 at 19:15 +0100, drago01 wrote: On Sat, Jan 18, 2014 at 9:47 PM, Rahul Sundaram methe...@gmail.com wrote: Hi Since updates don't automatically fix the issue created by https://bugzilla.redhat.com/show_bug.cgi?id=1054350 and users are required to run a set of steps as a workaround, shouldn't this be announced via the fedora announce list and posted in the Fedora website prominently as well? So it happened .. how do we prevent it in the future? How did it pass testing? Should we modify rpm so scriptlet failures aren't fatal? This is the second time in the last six months or so that I've seen scriptlet failures cause major update problems in Fedora, solely because they are fatal (see https://bugzilla.redhat.com/show_bug.cgi?id=989145). Well updates should be atomic so you either have the previous (working) start or the new working state and thing in between. Yes this requires a bit of work but isn't impossible (requires some infra at a lower level though). -- 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: SELinux RPM scriplet issue annoucement
Am 19.01.2014 19:57, schrieb Michael Schwendt: [...] then bumped the release for all updates in the last few pushes, and then rebuilt them. How do you know which packages a user has tried to install/update _after_ updating to the bad policy package? It could be any package within the package collection that would remain installed but broken because of the scriptlets bug. You assume that users have only applied the few updates following the bad selinux policy update this case is *very* special because you also need to realize *what* update before breaks the scriptlets and that it break all scriptlets zero chance to figure that out for 99 out of 100 users you only need to look at the amount of reports that other packages seems to be broken to get the picture that case seems to be unavoidable without force every packager of critical path updates to test them manually before they appear in updates-testing and on bodhi at all and to catch the specific case push the updates to testing after at least on their machine a independent update was applied without problems - unlikely to happen signature.asc Description: OpenPGP digital signature -- 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: SELinux RPM scriplet issue annoucement
Am 19.01.2014 20:00, schrieb drago01: On Sun, Jan 19, 2014 at 7:32 PM, Jonathan Dieter jdie...@lesbg.com wrote: On Sun, 2014-01-19 at 19:15 +0100, drago01 wrote: On Sat, Jan 18, 2014 at 9:47 PM, Rahul Sundaram methe...@gmail.com wrote: Hi Since updates don't automatically fix the issue created by https://bugzilla.redhat.com/show_bug.cgi?id=1054350 and users are required to run a set of steps as a workaround, shouldn't this be announced via the fedora announce list and posted in the Fedora website prominently as well? So it happened .. how do we prevent it in the future? How did it pass testing? Should we modify rpm so scriptlet failures aren't fatal? This is the second time in the last six months or so that I've seen scriptlet failures cause major update problems in Fedora, solely because they are fatal (see https://bugzilla.redhat.com/show_bug.cgi?id=989145). Well updates should be atomic so you either have the previous (working) start or the new working state and thing in between. Yes this requires a bit of work but isn't impossible (requires some infra at a lower level though) which would mean disallow scriptlets at all - but you hardly can do anything scriptlets are doing in a different way one problem is that many scriptlets are not that important or fail only on the second update still containing them after already applied - in that cases have them non-fatal would avoid dupes with no harm IMHO this problem is not solveable signature.asc Description: OpenPGP digital signature -- 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: SELinux RPM scriplet issue annoucement
On Sun, 19 Jan 2014 18:48:57 +, Frank Murphy wrote: Would a gui yumex\PK have burped at the update? Yes, because selinux-policy* is a low-level package not specific to Yum. The policy affects RPM and everything on top of it. Would the two testers have seen the script errors. Only during *subsequent* attempts at updating to or installing *more* packages containing scriptlets - prior to giving +1 in the Fedora Updates System. A simple yum -y update ; reboot ; Oh, everything seems to work has not been enough this time. And it was an update with a screen full of ticket numbers for the included bug-fixes/changes. It could have broken something else, too. Btw, some other packages are in the same boat. Imagine a graphics driver update seems to work for three testers that are required for a +3 vote in the updates system, but fails badly for a hundred other users once it appears in the stable updates repo. -- 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: SELinux RPM scriplet issue annoucement
On Sun, 19 Jan 2014 20:03:14 +0100, Reindl Harald wrote: this case is *very* special because you also need to realize *what* update before breaks the scriptlets and that it break all scriptlets zero chance to figure that out for 99 out of 100 users you only need to look at the amount of reports that other packages seems to be broken to get the picture True. However, it's not the Fedora product's users who do the testing, but brave testers with updates-testing enabled, who evaluate packages _before_ they get pushed into the stable updates repo. All the ordinary users, who thought that the nfs-utils update contained a bad scriptlet, assumed that such a bug has slipped through the Fedora testing process. What does that tell about quality of Fedora testing? ;) Other users have reported the same issue for initscripts and other packages. What these people have in common is that they have noticed the scriptlet errors and have opened a ticket in bugzilla. IMO, testers would have noticed it too, if the test update had been offered in the updates-testing repo for a longer time. It simply won't work well, if testing is a race for the fastest +1 votes. I wonder what a tester would have done when encountering a scriptlet error, if the bad selinux package had not been marked stable yet? Would it have led to a -1 on the wrong package? The nfs-utils update has been pushed to stable with +3 one day after the bad selinux policy. that case seems to be unavoidable without force every packager of critical path updates to test them manually before they appear in updates-testing and on bodhi at all and to catch the specific case push the updates to testing after at least on their machine a independent update was applied without problems - unlikely to happen Why that? Why the manual installation? There is no need to rush when voting in bodhi. Such a selinux policy update with many changes is _scary_. Come on, Fedora 20 has been released already after a long development/testing cycle. Why take the risk of breaking it with large updates that are rushed out? Where the released product is broken already since day zero, a few more days of testing the fixes don't hurt. One of the fundamental actions that critical path package updates must be able to complete is get updates. That means that after a full yum -y update to fetch a latest batch of Test Updates, the tester must attempt at triggering further system updates. A downgrade of some packages may be enough to test a subsequent manual yum update, at least. Alternatively, wait for the next updates/test-updates to appear in the repos, but what about automatic updates and update notifications?. Good, if Yum still works, at least. But that doesn't mean testers should neglect the graphical package tools and system update mechanisms many other users will depend on. -- 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: SELinux RPM scriplet issue annoucement
Am 19.01.2014 20:48, schrieb Michael Schwendt: On Sun, 19 Jan 2014 20:03:14 +0100, Reindl Harald wrote: this case is *very* special because you also need to realize *what* update before breaks the scriptlets and that it break all scriptlets zero chance to figure that out for 99 out of 100 users you only need to look at the amount of reports that other packages seems to be broken to get the picture True. However, it's not the Fedora product's users who do the testing, but brave testers with updates-testing enabled, who evaluate packages _before_ they get pushed into the stable updates repo. All the ordinary users, who thought that the nfs-utils update contained a bad scriptlet, assumed that such a bug has slipped through the Fedora testing process. What does that tell about quality of Fedora testing? ;) i know, in a perfect world it does not happen Other users have reported the same issue for initscripts and other packages. What these people have in common is that they have noticed the scriptlet errors and have opened a ticket in bugzilla. IMO, testers would have noticed it too, if the test update had been offered in the updates-testing repo for a longer time. in that case - no testers also hardly had realized the responsible package said from one running updates-testing and often koji over years on my machines It simply won't work well, if testing is a race for the fastest +1 votes depends on the test matrix and package I wonder what a tester would have done when encountering a scriptlet error, if the bad selinux package had not been marked stable yet? Would it have led to a -1 on the wrong package? most likely The nfs-utils update has been pushed to stable with +3 one day after the bad selinux policy. which says not much most of my servers have selinux completly disabled so the selinux policy can be as broken as possible but that does not mean that i can't qualify a qt, kde, samba or whatever package which works as expected in my workloads that case seems to be unavoidable without force every packager of critical path updates to test them manually before they appear in updates-testing and on bodhi at all and to catch the specific case push the updates to testing after at least on their machine a independent update was applied without problems - unlikely to happen Why that? Why the manual installation? because i faced too much packages in updates-testing at all 3 days after build that hardly broken or not installable at all where i honestly ask has the packager ever instaleld it on one of his systems There is no need to rush when voting in bodhi. Such a selinux policy update with many changes is _scary_. Come on, Fedora 20 has been released already after a long development/testing cycle. Why take the risk of breaking it with large updates that are rushed out? Where the released product is broken already since day zero, a few more days of testing the fixes don't hurt. for that package yes on the other hand there are enough small bugs where it is even hard to realize what package / library is really responsible and library updates with a complete reboot and some hours qualify at least there is not more broken then before and in the best case it fixes issues for others or at least does not more harm then before One of the fundamental actions that critical path package updates must be able to complete is get updates. That means that after a full yum -y update to fetch a latest batch of Test Updates, the tester must attempt at triggering further system updates that is what i am doing always before give karma: * rebuild one of my self maintained packages * they all get MMDD in the %release automatically * run a yum update and verify YUM/RPM works but what about automatic updates and update notifications?. Good, if Yum still works, at least. But that doesn't mean testers should neglect the graphical package tools and system update mechanisms many other users will depend on expect that testers are using only yum for several reasons and many of them even uninstalled all that graphical package stuff if possible by cross-dependencies, that won't change in the future as long nobody takes away the CLI completly which drives away that users completly signature.asc Description: OpenPGP digital signature -- 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: SELinux RPM scriplet issue annoucement
On Jan 19, 2014 8:57 PM, Michael Schwendt mschwe...@gmail.com wrote: On Sun, 19 Jan 2014 20:32:26 +0200, Jonathan Dieter wrote: If scriptlet failures weren't fatal, we wouldn't have the problem we have now with duplicate packages. We could have just pushed the selinux update, After installing the previous bad update that breaks scriptlets, how would you activate the new selinux policy within the fixed package's %post scriptlet? Instead of updating to the package in permissive mode, you would need to run the scriptlet contents manually *and* still reinstall any package were the scriptlets failed. I was focusing on the fact that scriptlet failures lead to duplicates in the rpm database, but, you're right, it's not the main problem. I still think there's a good case for making scriptlet errors non - fatal, but, in this situation, it would have had a minimal benefit. [...] then bumped the release for all updates in the last few pushes, and then rebuilt them. How do you know which packages a user has tried to install/update _after_ updating to the bad policy package? It could be any package within the package collection that would remain installed but broken because of the scriptlets bug. You assume that users have only applied the few updates following the bad selinux policy update. ACK. I didn't think this part through properly. Jonathan -- 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: SELinux RPM scriplet issue annoucement
Anyone not aware of the problem and the fix, who applies the -117.fc20 selinux-policy update in _enforcing_ mode (since it has entered stable updates meanwhile) believing it to be a normal update, will face another failure and a partial update. Package selinux-policy updated to -117.fc20 but -targeted remaining at -116.fc20. Fixing that with the instructions in the Wiki wouldn't work, # yum update selinux-policy Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit No packages marked for update since selinux-policy package is up-to-date. The enhanced fix that adds '\*' works also for this extra problem: setenforce 0 yum clean expire-cache yum update selinux-policy\* setenforce 1 [...] Here's the full reproducer: # yum update Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package selinux-policy.noarch 0:3.12.1-116.fc20 will be updated --- Package selinux-policy.noarch 0:3.12.1-117.fc20 will be an update --- Package selinux-policy-targeted.noarch 0:3.12.1-116.fc20 will be updated --- Package selinux-policy-targeted.noarch 0:3.12.1-117.fc20 will be an update -- Finished Dependency Resolution Dependencies Resolved == == Package Arch Version Repository Size == == Updating: selinux-policy noarch 3.12.1-117.fc20 updates 316 k selinux-policy-targeted noarch 3.12.1-117.fc20 updates 3.6 M Transaction Summary == == Upgrade 2 Packages Total download size: 3.9 M Is this ok [y/d/N]: y Downloading packages: updates/20/x86_64/prestodelta | 1.3 MB 00:02 (1/2): selinux-policy-3.12.1-117.fc20.noarch.rpm | 316 kB 00:04 (2/2): selinux-policy-targeted-3.12.1-117.fc20.noarch.rpm | 3.6 MB 00:04 Total 868 kB/s | 3.9 MB 00:04 Running transaction check Running transaction test Transaction test succeeded Running transaction Warning: RPMDB altered outside of yum. Updating : selinux-policy-3.12.1-117.fc20.noarch 1/4 warning: %post(selinux-policy-3.12.1-117.fc20.noarch) scriptlet failed, exit status 127 Non-fatal POSTIN scriptlet failure in rpm package selinux-policy-3.12.1-117.fc20.noarch warning: %triggerin(selinux-policy-3.12.1-117.fc20.noarch) scriptlet failed, exit status 127 Non-fatal unknown scriptlet failure in rpm package selinux-policy-3.12.1-117.fc20.noarch error: %pre(selinux-policy-targeted-3.12.1-117.fc20.noarch) scriptlet failed, exit status 127 Error in PREIN scriptlet in rpm package selinux-policy-targeted-3.12.1-117.fc20.noarch Cleanup : selinux-policy-3.12.1-116.fc20.noarch 3/4 error: selinux-policy-targeted-3.12.1-117.fc20.noarch: install failed error: selinux-policy-targeted-3.12.1-116.fc20.noarch: erase skipped warning: %postun(selinux-policy-3.12.1-116.fc20.noarch) scriptlet failed, exit status 127 Non-fatal POSTUN scriptlet failure in rpm package selinux-policy-3.12.1-116.fc20.noarch Verifying : selinux-policy-3.12.1-117.fc20.noarch 1/4 selinux-policy-targeted-3.12.1-116.fc20.noarch was supposed to be removed but is not! Verifying : selinux-policy-targeted-3.12.1-116.fc20.noarch 2/4 Verifying : selinux-policy-3.12.1-116.fc20.noarch 3/4 Verifying : selinux-policy-targeted-3.12.1-117.fc20.noarch 4/4 Updated: selinux-policy.noarch 0:3.12.1-117.fc20 Failed: selinux-policy-targeted.noarch 0:3.12.1-116.fc20 selinux-policy-targeted.noarch 0:3.12.1-117.fc20 Complete! # rpm -qa selinux-policy\* selinux-policy-targeted-3.12.1-116.fc20.noarch selinux-policy-3.12.1-117.fc20.noarch # yum update selinux-policy Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit No packages marked for update # yum update selinux-policy\* Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package selinux-policy-targeted.noarch 0:3.12.1-116.fc20 will be updated --- Package selinux-policy-targeted.noarch 0:3.12.1-117.fc20 will be an update -- Finished Dependency Resolution Dependencies Resolved Package Arch Version Repository Size Updating: selinux-policy-targeted noarch 3.12.1-117.fc20 updates 3.6 M Transaction Summary Upgrade 1 Package Total size: 3.6 M Is this ok [y/d/N]: y Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction Updating : selinux-policy-targeted-3.12.1-117.fc20.noarch 1/2 Cleanup:
Re: SELinux RPM scriplet issue annoucement
On Mon, 2014-01-20 at 00:14 +0100, Michael Schwendt wrote: Anyone not aware of the problem and the fix, who applies the -117.fc20 selinux-policy update in _enforcing_ mode (since it has entered stable updates meanwhile) believing it to be a normal update, will face another failure and a partial update. Package selinux-policy updated to -117.fc20 but -targeted remaining at -116.fc20. I don't see this. I just updated today before reading this message (and I haven;t read the whole thread, sorry) and I got selinux-policy and targeted updated without any problem (I always run in enforcing mode). Simo. Fixing that with the instructions in the Wiki wouldn't work, # yum update selinux-policy Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit No packages marked for update since selinux-policy package is up-to-date. The enhanced fix that adds '\*' works also for this extra problem: setenforce 0 yum clean expire-cache yum update selinux-policy\* setenforce 1 [...] [snip] -- Simo Sorce * Red Hat, Inc * New York -- 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: SELinux RPM scriplet issue annoucement
IMO a SOP need to be documented or linked to selinux-policy package update also. BTW not all people run enforcing mode in daily time, so sometimes problems may not be found easily. Thanks. -- -- Yours sincerely, Christopher Meng Noob here. http://cicku.me -- 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: SELinux RPM scriplet issue annoucement
Is it possible to build a one-time build of selinux-policy without scriptlets so that the update will succeed? On Sat, Jan 18, 2014 at 3:47 PM, Rahul Sundaram methe...@gmail.com wrote: Hi Since updates don't automatically fix the issue created by https://bugzilla.redhat.com/show_bug.cgi?id=1054350 and users are required to run a set of steps as a workaround, shouldn't this be announced via the fedora announce list and posted in the Fedora website prominently as well? Rahul -- 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
Re: directfb, fusionsound packaged, review for submition and sdl2 bridge
Yeah, the packages as i built them, as i said, do not build the OPTIONAL KERNEL MODULES, everything works anyway. Thanks, Ville Slytta, for the insight in kernel module packaging in case at some point needs consideration, again, NOT NOW as Ilyes Gouta repeats (and 1.7 is current). If SDL2 IS DROPPING FBCON (their own framebuffer module) IN FAVOUR OF DIRECTFB, Fedora is going to be a little behind if it does not ship it, and would have to be rethinking this again and again. I find a real value in being able to run some kind of quality graphical applications without the OBLIGATORY dependency of an X Server. After all, X is not ALL, OpenGL is not ALL. There are TONS of apps/games/utilities that can/could run on this. I myself enjoy running stuff on the framebuffer, and like the possibility of that option. I'm having a little of a feeling about something i should pronunciate about (NO DIRECT PERSONAL REFERENCE TO ANYONE): If you don't use the framebuffer, you shouldn't be banning it, i would not ban the Xorg Server ;). If you use X Desktop, Y Desktop users shouldn't be banning it (cause it's of no use TO THEM). We are a ton of users, and if you don't like something, just don't install it, if it doesn't work that way, just don't use it. It's not OBLIGATORY to use it. :) Again, not having FB support is gonna come back again and again. For starters, i would be forced to keep my own DirectFB builds and hence SDL2 ones, since i use and plan on being usint it. I wouldn't have thought that DirectFB requires such deep enrollment. I just want to run stuff on the framebuffer. Possible DirectFB FusionSound maintainer(s), take note ;) On Sun, Jan 19, 2014 at 1:43 PM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi, On Sun, Jan 19, 2014 at 10:16 AM, Ville Skyttä ville.sky...@iki.fiwrote: On Sun, Jan 19, 2014 at 4:55 AM, Juan Manuel Borges Caño juanmabcm...@gmail.com wrote: The packages built okay without the optional kernel module (to know, linux-fusion is the one), if that turns to be obligatory, again, i'd take alsa packaging as a cool example :) ALSA kernel modules are included in the upstream kernel, AFAIK DirectFB ones are not. In order to be included in Fedora, they need to be upstream or Fedora kernel maintainers convinced to ship them within the kernel package. http://fedoraproject.org/wiki/Packaging:KernelModules It should be possible to build DirectFB-multi without the linux-fusion kernel module, so that's reverting to shmem and UNIX sockets for IPC. I remember I saw fixes for Fusion userspace posted against the -1.7 branch. Ilyes -- 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 -- 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: SELinux RPM scriplet issue annoucement
On Sun, 19 Jan 2014 23:02:24 -0500, Simo Sorce wrote: Anyone not aware of the problem and the fix, who applies the -117.fc20 selinux-policy update in _enforcing_ mode (since it has entered stable updates meanwhile) believing it to be a normal update, will face another failure and a partial update. Package selinux-policy updated to -117.fc20 but -targeted remaining at -116.fc20. I don't see this. I just updated today before reading this message (and I haven;t read the whole thread, sorry) and I got selinux-policy and targeted updated without any problem (I always run in enforcing mode). Did you update from -116.fc20 or an earlier one? Only if you come from -116.fc20, you would be affected, since -116.fc20 is the bad update. -- 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: SELinux RPM scriplet issue annoucement
On Mon, 20 Jan 2014 12:20:38 +0800, Christopher Meng wrote: IMO a SOP need to be documented or linked to selinux-policy package update also. BTW not all people run enforcing mode in daily time, so sometimes problems may not be found easily. Running SELinux in enforcing mode is mandatory for testers of the selinux-policy-targeted packagers. -- 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-Catalyst-Controller-HTML-FormFu
perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide tree: On x86_64: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On i386: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On armhfp: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) 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-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.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: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) 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-qpid_proton
perl-qpid_proton has broken dependencies in the rawhide tree: On x86_64: perl-qpid_proton-0.6-1.fc21.x86_64 requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.x86_64 requires perl(qpid::proton::ExceptionHandling) On i386: perl-qpid_proton-0.6-1.fc21.i686 requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.i686 requires perl(qpid::proton::ExceptionHandling) On armhfp: perl-qpid_proton-0.6-1.fc21.armv7hl requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.armv7hl requires perl(qpid::proton::ExceptionHandling) 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
[Bug 1055289] New: perl-experimental-0.006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1055289 Bug ID: 1055289 Summary: perl-experimental-0.006 is available Product: Fedora Version: rawhide Component: perl-experimental Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.006 Current version/release in Fedora Rawhide: 0.005-3.fc20 URL: http://search.cpan.org/dist/experimental/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=DzqJaALpOWa=cc_unsubscribe -- 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 1055291] New: perl-JavaScript-Minifier-1.06 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1055291 Bug ID: 1055291 Summary: perl-JavaScript-Minifier-1.06 is available Product: Fedora Version: rawhide Component: perl-JavaScript-Minifier Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 1.06 Current version/release in Fedora Rawhide: 1.05-13.fc20 URL: http://search.cpan.org/dist/JavaScript-Minifier/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=eAMx3ia3DTa=cc_unsubscribe -- 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 1040414] perl-Glib-Object-Introspection-0.019 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1040414 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Glib-Object-Introspect |perl-Glib-Object-Introspect |ion-0.018 is available |ion-0.019 is available --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 0.019 Current version/release in Fedora Rawhide: 0.016-1.fc21 URL: http://search.cpan.org/dist/Glib-Object-Introspection/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=1SSpswYcOEa=cc_unsubscribe -- 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 1055292] New: perl-Module-Load-Conditional-0.60 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1055292 Bug ID: 1055292 Summary: perl-Module-Load-Conditional-0.60 is available Product: Fedora Version: rawhide Component: perl-Module-Load-Conditional Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.60 Current version/release in Fedora Rawhide: 0.58-1.fc21 URL: http://search.cpan.org/dist/Module-Load-Conditional/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=x6Bobcqmg5a=cc_unsubscribe -- 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 1055294] New: perl-Net-DNS-0.74 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1055294 Bug ID: 1055294 Summary: perl-Net-DNS-0.74 is available Product: Fedora Version: rawhide Component: perl-Net-DNS Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 0.74 Current version/release in Fedora Rawhide: 0.73-1.fc21 URL: http://search.cpan.org/dist/Net-DNS/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=02IVfPxF4Da=cc_unsubscribe -- 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 1055295] New: perl-Net-Twitter-4.01002 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1055295 Bug ID: 1055295 Summary: perl-Net-Twitter-4.01002 is available Product: Fedora Version: rawhide Component: perl-Net-Twitter Keywords: FutureFeature, Triaged Assignee: jd...@aquezada.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jd...@aquezada.com, perl-devel@lists.fedoraproject.org Latest upstream release: 4.01002 Current version/release in Fedora Rawhide: 4.01000-1.fc21 URL: http://search.cpan.org/dist/Net-Twitter/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=zs9jIRwjDua=cc_unsubscribe -- 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 1055296] New: perl-Rose-DB-0.775 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1055296 Bug ID: 1055296 Summary: perl-Rose-DB-0.775 is available Product: Fedora Version: rawhide Component: perl-Rose-DB Keywords: FutureFeature, Triaged Assignee: wf...@worldbroken.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, wf...@worldbroken.com Latest upstream release: 0.775 Current version/release in Fedora Rawhide: 0.774-1.fc21 URL: http://search.cpan.org/dist/Rose-DB/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=8LSRUA99Xna=cc_unsubscribe -- 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 1055297] New: perl-Rose-DB-Object-0.810 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1055297 Bug ID: 1055297 Summary: perl-Rose-DB-Object-0.810 is available Product: Fedora Version: rawhide Component: perl-Rose-DB-Object Keywords: FutureFeature, Triaged Assignee: wf...@worldbroken.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, wf...@worldbroken.com Latest upstream release: 0.810 Current version/release in Fedora Rawhide: 0.809-1.fc21 URL: http://search.cpan.org/dist/Rose-DB-Object/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=NxH1JmhWUCa=cc_unsubscribe -- 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 1055298] New: perl-X11-Protocol-Other-29 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1055298 Bug ID: 1055298 Summary: perl-X11-Protocol-Other-29 is available Product: Fedora Version: rawhide Component: perl-X11-Protocol-Other Keywords: FutureFeature, Triaged Assignee: robinlee.s...@gmail.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, robinlee.s...@gmail.com Latest upstream release: 29 Current version/release in Fedora Rawhide: 28-1.fc21 URL: http://search.cpan.org/dist/X11-Protocol-Other/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=iVpqrK9LxMa=cc_unsubscribe -- 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
File Net-Twitter-4.01002.tar.gz uploaded to lookaside cache by jdunn
A file has been added to the lookaside cache for perl-Net-Twitter: 58cb0b4af7c73d74113aa5b5794dfeee Net-Twitter-4.01002.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
[perl-Net-Twitter] Update to 4.01002 (bz#1055295)
commit 2e4e7fa9608b572c35b9774ac334542bbda59c3f
Author: Julian C. Dunn jd...@aquezada.com
Date: Sun Jan 19 22:21:27 2014 -0500
Update to 4.01002 (bz#1055295)
.gitignore|1 +
perl-Net-Twitter.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index f845024..50758d2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,3 +7,4 @@
/Net-Twitter-4.6.tar.gz
/Net-Twitter-4.7.tar.gz
/Net-Twitter-4.01000.tar.gz
+/Net-Twitter-4.01002.tar.gz
diff --git a/perl-Net-Twitter.spec b/perl-Net-Twitter.spec
index af38648..cf3e5cc 100644
--- a/perl-Net-Twitter.spec
+++ b/perl-Net-Twitter.spec
@@ -1,5 +1,5 @@
Name: perl-Net-Twitter
-Version:4.01000
+Version:4.01002
Release:1%{?dist}
Summary:Perl interface to the Twitter API
License:GPL+ or Artistic
@@ -76,6 +76,9 @@ http://dev.twitter.com/doc for a full description of the
Twitter APIs.
%{_mandir}/man3/*
%changelog
+* Sun Jan 19 2014 Julian C. Dunn jd...@aquezada.com - 4.01002-1
+- Upgrade to 4.01002 (bz#1055295)
+
* Thu Nov 21 2013 Julian C. Dunn jd...@aquezada.com - 4.01000-1
- Upgrade to 4.01000 (bz#1032571)
diff --git a/sources b/sources
index 587beec..fb0f793 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4b240f8005f8493dc68ebe6ebf3d7021 Net-Twitter-4.01000.tar.gz
+58cb0b4af7c73d74113aa5b5794dfeee Net-Twitter-4.01002.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
[perl-Net-Twitter/f20] Update to 4.01002 (bz#1055295)
Summary of changes: 2e4e7fa... Update to 4.01002 (bz#1055295) (*) (*) This commit already existed in another branch; no separate mail sent -- 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
[perl-Net-Twitter/f19] Update to 4.01002 (bz#1055295)
Summary of changes: 2e4e7fa... Update to 4.01002 (bz#1055295) (*) (*) This commit already existed in another branch; no separate mail sent -- 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 1055295] perl-Net-Twitter-4.01002 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1055295 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-Net-Twitter-4.01002-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Net-Twitter-4.01002-1.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Z2piGe3aDIa=cc_unsubscribe -- 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 1055295] perl-Net-Twitter-4.01002 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1055295 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-Net-Twitter-4.01002-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-Net-Twitter-4.01002-1.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=EVr9Qkr3d5a=cc_unsubscribe -- 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
