Re: [EPEL-devel] [EPEL] #7: Policy and technical means for removing orphaned packages in EPEL
#7: Policy and technical means for removing orphaned packages in EPEL -+ Reporter: smooge | Owner: epel-wranglers Type: task| Status: new Priority: major | Milestone: Component: Policy problem |Version: Resolution: | Keywords: -+ Comment (by smooge): Jim. I would say that if the package is not shipped in RHEL but used just for 'building' stuff then it is something we can look at for shipping with EPEL. Till, fair plan. I guess we need to break the date down into two Dec 17th remove Orphans. Dec 19th remove children. I will try and do a trial run later this month to get an idea of how much is going. -- Ticket URL: https://fedorahosted.org/epel/ticket/7#comment:5 EPEL https://fedoraproject.org/wiki/EPEL Extra Packages for Enterprise Linux ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] Mongodb plans for EPEL
On Tue, Nov 4, 2014 at 4:51 PM, Troy Dawson tdaw...@redhat.com wrote: Hi, mongodb 2.6 brought alot of changes to it's libraries and packaging. I believe the 2.6 databases are backward compatible with the 2.4 databases, but the libraries and structures have gone through some changes. If you look at the mongodb 2.6 in rawhide (f22) you will notice that there is no libmongodb. All of that has been split off into a separate package called mongo-cxx-driver. What am I proposing for EPEL6 and EPEL7? I propose we keep mongodb on EPEL6 at 2.4 for as long as possible. I have just updated it to 2.4.12 (from 2.4.6). https://admin.fedoraproject.org/updates/mongodb-2.4.12-1.el6 I am also proposing that we move EPEL7 to mongodb 2.6.x now, instead of later. That will give people a clean way to migrate from mongodb 2.4 to 2.6. They will just need to migrate from RHEL6 to RHEL7. https://admin.fedoraproject.org/updates/mongodb-2.6.5-2.el7 Any thoughts, complaints, problems? If there aren't any, I'll let these take their normal 2 weeks in bohdi and then move them into EPEL. +1 - I think sticking with 2.4.x for as long as possible is likely the best course of action given that users tend to expect a certain level of stability from EPEL (for various definitions/contexts of the term). -AdamM Thanks Troy Dawson ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[EPEL-devel] Fedora EPEL 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 927 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 381 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 146 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1626/puppet-2.7.26-1.el5 41 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2669/check-mk-1.2.4p5-1.el5 41 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2853/mediawiki119-1.19.18-1.el5 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3549/rubygem-actionpack-2.3.18-1.el5,rubygem-activerecord-2.3.18-1.el5,rubygem-activesupport-2.3.18-1.el5 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3554/rubygem-rails-2.3.18-1.el5,rubygem-actionmailer-2.3.18-1.el5,rubygem-activeresource-2.3.18-1.el5 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3570/tor-0.2.4.25-1.el5 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3651/phpMyAdmin4-4.0.10.5-1.el5 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3675/Pound-2.6-2.el5.2 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3784/mantis-1.2.17-3.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing R-3.1.2-1.el5 classads-1.0.10-1.el5 dar-2.4.15-2.el5 mantis-1.2.17-3.el5 Details about builds: R-3.1.2-1.el5 (FEDORA-EPEL-2014-3810) A language for data analysis and graphics Update Information: Update to R 3.1.2 Change /usr/lib[64]/R/etc/Makeconf from %config(noreplace) to %config to force it to be updated when upgrading. Without this change, the TCL_LIBS variable can be set incorrectly. The old Makeconf file will be preserved as Makeconf.rpmold ChangeLog: * Fri Oct 31 2014 Tom Callaway s...@fedoraproject.org - 3.1.2-1 - update to 3.1.2 * Wed Oct 29 2014 Tom Callaway s...@fedoraproject.org - 3.1.1-8 - rebuild for new tcl/tk - mark Makeconf as config (not config(noreplace) so that we get proper updated tcl/tk libs) References: [ 1 ] Bug #1158425 - package install fails with infinite loop https://bugzilla.redhat.com/show_bug.cgi?id=1158425 classads-1.0.10-1.el5 (FEDORA-EPEL-2014-3798) Condor's classified advertisement language Update Information: Unretire package and update to bugfix release 1.0.10. ChangeLog: * Tue Nov 4 2014 František Dvořák val...@civ.zcu.cz - 1.0.10-1 - Upgraded to 1.0.10 release - Removed static subpackage - Spec cleanups * Sat Aug 3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.0.8-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild * Wed Feb 13 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.0.8-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild * Wed Jul 18 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.0.8-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild * Fri Feb 10 2012 Petr Pisar ppi...@redhat.com - 1.0.8-4 - Rebuild against PCRE 8.30 * Thu Jan 12 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.0.8-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild * Tue Feb 8 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.0.8-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild References: [ 1 ] Bug #1148415 - Review Request: classads - Condor's classified advertisement language https://bugzilla.redhat.com/show_bug.cgi?id=1148415 dar-2.4.15-2.el5 (FEDORA-EPEL-2014-3789) Software for making/restoring incremental CD/DVD backups Update Information: libdar-devel: include pkg-config file ChangeLog: * Mon Nov 3 2014 Luis Bazan lba...@fedoraproject.org - 2.4.15-2 - add pkgconfig References: [ 1 ] Bug #1077403 - libdar-devel: include pkg-config
Re: Koji timeout
On Tue, 4 Nov 2014 08:52:25 +0100 Andrea Musuruane musur...@gmail.com wrote: Hi, I'm trying to build pinta but it fails due to timeout on F20 and F22: http://koji.fedoraproject.org/koji/taskinfo?taskID=8009403 http://koji.fedoraproject.org/koji/taskinfo?taskID=8009471 It built fine for F19 and F21 though. And it builds fine using mock. I resubmitted the two failed builds but it seems nothing changed. I don't know what to do next. Help appreciated. hm, it's not the first case where Mono enters a deadlock or endless loop ... What is your host system and what is the kernel version? Dan -- 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: Koji timeout
On Tue, Nov 4, 2014 at 3:52 PM, Andrea Musuruane musur...@gmail.com wrote:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8009403
Hi,
Please try again with make directly instead of make %{?_smp_mflags}.
Yours sincerely,
Christopher Meng
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: Proposal for integration tests infrastructure
Tim, thanks for your comments, I think we're on the same page in basically all aspects you mention. It seems like the issue was more wording and I still fail to find some better term for the tests that I was referring to -- so, how to ideally call the tests that are not unit tests any more, but still verify only one or more particular component(s)? What about Functional tests, would it be more precise? Honza On 11/03/2014 07:10 PM, Tim Flink wrote: On Mon, 03 Nov 2014 17:08:40 +0100 Honza Horak hho...@redhat.com wrote: On 10/28/2014 08:08 AM, Nick Coghlan wrote: On 10/22/2014 09:43 PM, Honza Horak wrote: Fedora lacks integration testing (unit testing done during build is not enough). Taskotron will be able to fill some gaps in the future, so maintainers will be able to set-up various tasks after their component is built. But even before this works we can benefit from having the tests already available (and run them manually if needed). Hereby, I'd like to get ideas and figure out answers for how and where to keep the tests. A similar discussion already took place before, which I'd like to continue in: https://lists.fedoraproject.org/pipermail/devel/2014-January/193498.html And some short discussion already took place here as well: https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-October/000570.html It's worth clarifying your scope here, as integration tests means different things to different people, and the complexity varies wildly depending on *what* you're trying to test. If you're just looking at tests of individual packages beyond what folks have specified in their RPM %check macro, then this is exactly the case that Taskotron is designed to cover. If you're looking at more complex cases like multihost testing, bare metal testing across multiple architectures, or installer integration testing, then that's what Beaker was built to handle (and has already been handling for RHEL for several years). That level is where you start to cross the line into true system level acceptance tests and you often *want* those maintained independently of the individual components in order to catch regressions in behaviour other services are relying on. Good point about defining the scope, thanks.. From my POV, we should rather start with some less complicated scenarios, so we can have something ready to use in reasonable time. Let's say the common use case would be defining tests that verify components' basic functionality that cannot be run during build. This should cover simple installation scenarios, running test-suites that need to be run outside of build process, or tests that need to be run for multiple components at the same time (e.g. testing basic functionality of LAMP stack). This should also cover issues with SELinux, systemd units, etc. that cannot be tested during build and IMHO are often cause of issues. I have no problem to state clearly for now that the tests cannot define any hardware requirements, even non-localhost networking. In other words the tests will be run on one machine with any hardware and any (or none) network. However, I'd rather see tests not tight to a particular component, since even simple test might cover two or three of them and it wouldn't be correct tight it to all nor to only one of them. Yeah, I think that package-specific checks are a similar but slightly different kettle of fish than we're discussing here. We'd have to figure out how the integration tests would be scheduled (nightly, on change in a set of packages corresponding to each check, etc.) but that can wait until we've refined what we're looking to do a bit more. snip How to deliver tests? a/ just use them directly from git (we need to keep some metadata for dependencies anyway) b/ package them as RPMs (we can keep metadata there; e.g. Taskotron will run only tests that have Provides: ci-tests(mariadb) after mariadb is built; we also might automate packaging tests to RPMs) Our experience with Beaker suggests that you want to support both - running directly from Git tends to be better for test development, while using RPMs tends to be better for dependency management and sharing test infrastructure code. Which framework to use? People have no time to learn new things, so we should let them to write the tests in any language and just define some conventions how to run them. Taskotron already covers this pretty well (even if invoking Beaker tests, it would make more sense to do that via Taskotron rather than directly). Right, Taskotron involvement seems like the best bet now, but it should not be tight to it -- in case Taskotron is replaced by some other tool for executing tasks in the future, we cannot loose the tests themselves. While I don't see Taskotron going away anytime soon, I agree that we should avoid tight coupling where it makes sense to avoid it. With my captain obvious hat on, the trick is figuring out where the point of diminishing returns is - too
Re: Koji timeout
On Tue, Nov 4, 2014 at 9:02 AM, Dan Horák d...@danny.cz wrote: hm, it's not the first case where Mono enters a deadlock or endless loop ... What is your host system and what is the kernel version? $ cat /etc/redhat-release Fedora release 20 (Heisenbug) $ uname -r 3.16.6-200.fc20.x86_64 Bye, Andrea -- 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: Koji timeout
On Tue, 4 Nov 2014 09:40:07 +0100 Andrea Musuruane musur...@gmail.com wrote: On Tue, Nov 4, 2014 at 9:02 AM, Dan Horák d...@danny.cz wrote: hm, it's not the first case where Mono enters a deadlock or endless loop ... What is your host system and what is the kernel version? $ cat /etc/redhat-release Fedora release 20 (Heisenbug) $ uname -r 3.16.6-200.fc20.x86_64 the builders have 3.16.3-200.fc20.x86_64, could you retry the local mock rebuild with this kernel installed? I know it won't solve the problem, but might lead to having a reproducer. Eventually also with the same mock config as used for the koji build which you can get from koji mock-config --task 8009477 Dan -- 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: Proposal for integration tests infrastructure
This looks related to: https://wiki.gnome.org/GnomeGoals/InstalledTests (Note that the Issues with make check is equivalent to issues with rpm %check) It's implemented by gnome-continuous, and there's been a bit of effort to make -tests subpackages for some pieces in Fedora, but AFAIK no runner yet. The thing that makes the gnome-continuous model a more radical departure here is it does *not* run the equivalent of rpm %check - it only supports InstalledTests. After a component gets a new git commit, it's built (but not tested), shipped, and then *all tests* are rerun inside a VM from the resulting shipped tree. The beauty of this is that all tests are running all of the time. Continuously. This has caught real bugs much faster in several cases, because the tests for all dependencies get run when a given shared library changes. This idea is *not* GNOME specific as the Related Art section shows; also worth a compare and contrast with Debian autopkgtest: http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst Extending this to support headless tests that ran as Linux containers (e.g. via Docker) would likely be very worthwhile, and cover a lot of components like gcc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20141104 changes
Compose started at Tue Nov 4 05:15:02 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [alienarena] alienarena-7.66-4.fc22.i686 requires libode-double.so.3 [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [collectd] collectd-onewire-5.4.1-10.fc22.i686 requires libowcapi-2.9.so.7 [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so [couchdb] couchdb-1.6.1-1.fc22.i686 requires erlang(erl_nif_version) = 0:2.6 couchdb-1.6.1-1.fc22.i686 requires erlang(erl_drv_version) = 0:3.0 [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires libLLVM-3.4.so dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [ejabberd] ejabberd-14.07-2.fc22.i686 requires erlang(erl_nif_version) = 0:2.6 ejabberd-14.07-2.fc22.i686 requires erlang(erl_drv_version) = 0:3.0 [erlang-basho_metrics] erlang-basho_metrics-1.0.0-12.fc22.i686 requires erlang(erl_nif_version) = 0:2.6 [erlang-bitcask] erlang-bitcask-1.6.3-5.fc22.i686 requires erlang(erl_nif_version) = 0:2.6 [erlang-cl] erlang-cl-1.2.1-5.fc22.i686 requires erlang(erl_nif_version) = 0:2.6 [erlang-ebloom] erlang-ebloom-1.1.2-6.fc22.i686 requires erlang(erl_nif_version) = 0:2.6 [erlang-eleveldb] erlang-eleveldb-1.3.2-6.fc22.i686 requires erlang(erl_nif_version) = 0:2.6 [erlang-emmap] erlang-emmap-0-0.10.git05ae1bb.fc22.i686 requires erlang(erl_nif_version) = 0:2.6 [erlang-erlsyslog] erlang-erlsyslog-0.6.2-7.fc22.i686 requires erlang(erl_drv_version) = 0:3.0 [erlang-esasl] erlang-esasl-0.1-16.20120116git665cc80.fc22.i686 requires erlang(erl_drv_version) = 0:3.0 [erlang-esdl] erlang-esdl-1.3.1-6.fc22.i686 requires erlang(erl_drv_version) = 0:3.0 [erlang-js] erlang-js-1.2.2-7.fc22.i686 requires erlang(erl_drv_version) = 0:3.0 [erlang-sd_notify] erlang-sd_notify-0.1-4.fc22.i686 requires erlang(erl_nif_version) = 0:2.6 [erlang-skerl] erlang-skerl-1.1.0-9.fc22.i686 requires erlang(erl_nif_version) = 0:2.6 [erlang-snappy] erlang-snappy-1.0.3-0.9.git80db168.fc22.i686 requires erlang(erl_nif_version) = 0:2.6 [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [gdesklet-SlideShow] gdesklet-SlideShow-0.9-16.fc21.noarch requires gdesklets [gdesklets-citation] gdesklets-citation-2.0-3.20120702git355e2ee.fc19.noarch requires gdesklets [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [ghc-hjsmin] ghc-hjsmin-0.1.4.7-3.fc22.i686 requires libHSoptparse-applicative-0.9.0-ghc7.6.3.so [glances] glances-2.1.2-2.fc22.noarch requires python-psutil = 0:2.0.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [iwhd] iwhd-1.6-11.fc22.i686 requires libmongoclient.so [kmid2] kmid2-2.4.0-7.fc22.i686 requires libdrumstick-file.so.0 kmid2-2.4.0-7.fc22.i686 requires libdrumstick-alsa.so.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3 libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.i686 requires fuse-unionfs ltsp-server-5.4.5-8.fc21.i686 requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.i686 requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.i686 requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.i686 requires vala 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [nodejs-muffin]
Re: Firefox Gtk3 test package
The Gtk3 Firefox is enabled for master (Fedora 22) now. If you'd like to have gtk3 build for other distros, just change the toolkit_gtk3 variable and rebuild (locally, in copr). I'd be glad for any feedback/bugreport and please mind - it's still rawhide :) ma. On 01/13/2014 04:15 PM, Martin Stransky wrote: Hi guys, first $SUBJ is available at: http://stransky.fedorapeople.org/FirefoxGtk3/ It's just a src.spm and plugin support it not finished (don't browse youtube ;-)) but may work as a preview. I'll provide Fedora builds and repo later. ma. -- 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: Firefox Gtk3 test package
IMO It would be great if anyone can step in, rebuild the gtk3 package for other Fedora's and maintain the copr repo. I can help with any issues with that so feel free to ask. ma. On 11/04/2014 12:37 PM, Martin Stransky wrote: The Gtk3 Firefox is enabled for master (Fedora 22) now. If you'd like to have gtk3 build for other distros, just change the toolkit_gtk3 variable and rebuild (locally, in copr). I'd be glad for any feedback/bugreport and please mind - it's still rawhide :) ma. On 01/13/2014 04:15 PM, Martin Stransky wrote: Hi guys, first $SUBJ is available at: http://stransky.fedorapeople.org/FirefoxGtk3/ It's just a src.spm and plugin support it not finished (don't browse youtube ;-)) but may work as a preview. I'll provide Fedora builds and repo later. ma. -- 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: Requiring all files in /usr to be world-readable?
On Mon, 03.11.14 09:13, Miloslav Trmač (m...@redhat.com) wrote: Hello, - Original Message - On Fri, 31.10.14 10:04, Andrew Lutomirski (l...@mit.edu) wrote: I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467 Thoughts? I very much agree with this, but I'd really prefer if we'd list what is allowed rather than just declare what is forbidden. What is the use case for such a blanket requirement? fpc/467 lists the virt thing I so far disagree with, and other uses cases in there actually need much less than all of /usr. We are working on allowing stateless system boot up with /usr. For that I really want the ability that any user can copy /usr to some other place without having privileges, and then boot that up. Replicating a system shouldn't require privileges. Moreover, the stateless systems stuff actually enables sharing /usr over the network. In some setups network sharing servers tend to refuse access to networked clients if the files are marked inaccessible, under the assumption that root on the networked client might not be the same as root on the server. Also, things like auditd making its tools for no reason non-root accessible (so that I cannot even type auditctl --help as non-root!) is really annoying to the admin. A system should be transparent, and we should encourage to do as much work as possible unprivileged on it. In particular exploring it, reading the built in help texts (as accessible via --help on binaries for example) should be entirely unrestricted. Then, we really shouldn't propagate a style of security through obscurity that the access rights on the binaries does. It's misleading, it indicates to our users that the binary code of executables was secret in any way, even though it really isn't. In general, cleaning this up is basic hygiene, it makes things much simpler, if you just allow 5 kinds of files, and that's it. A short list like this should be everything we should allow in /usr: a) symlinks b) directories with access mode 0555 c) files with access mode 0444 (optionally 0644 if owned by root user) d) files with access mode 0555 (optionally 0755 if owned by root user) e) files with access mode 2555 (optionally 2755 if owned by root user) f) files with access mode 4555 Primarily: oh no, please don’t perpetuate the security-by-nonworking-rube-goldberg-machine that is denying write permissions to the file’s owner. If SELinux constraints apply this doesn’t do anything more, and if they don’t the owner doesn’t need any privileges or capabilities to change the permissions and regain the denied access. Well, if you only want to allow 0644 instead of 0444, then I am fine with that too. Secondarily: The rationale that the executables of suid files are public and thus it is useless to make them non-readable is false for 1) any non-distribution packages 2) local rebuilds Fedora has no control about those and should not make any restrictions on the stuff we don't control, don't package. If the admin fucks with /usr, then that's his right. I wouldn't recommend it, but it's an open system, and he's in control. Hence: restricting the stuff we put in /usr should be a requirement for the RPMs we ship, and be a recommendation for other stuff, but not more. 3) in-distribution packages for which the worm doesn’t carry pre-generated exploit parameters. This would be security by obscurity, nothing more. Also, it's wrong. Either you have a worm that carries a fixed set of pre-generated exploit parameters. It will exploit what it can exploit, and won't what it doesn't have any pre-generates exploit parameters around. Or you have a smart worm, where a human attacker is behind. In that case the attacker can easily look at the binary versions of whatever he finds on the target systems that prohibits access: he can just download it again from Fedora. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-21 Branched report: 20141104 changes
Compose started at Tue Nov 4 07:15:02 UTC 2014 Broken deps for armhfp -- [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [blender] 1:blender-2.72b-1.fc21.armv7hl requires libOpenCOLLADAStreamWriter.so.0.1 1:blender-2.72b-1.fc21.armv7hl requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blender-2.72b-1.fc21.armv7hl requires libOpenCOLLADAFramework.so.0.1 1:blender-2.72b-1.fc21.armv7hl requires libOpenCOLLADABaseUtils.so.0.1 1:blender-2.72b-1.fc21.armv7hl requires libMathMLSolver.so.0.1 1:blender-2.72b-1.fc21.armv7hl requires libGeneratedSaxParser.so.0.1 1:blenderplayer-2.72b-1.fc21.armv7hl requires libOpenCOLLADAStreamWriter.so.0.1 1:blenderplayer-2.72b-1.fc21.armv7hl requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blenderplayer-2.72b-1.fc21.armv7hl requires libOpenCOLLADAFramework.so.0.1 1:blenderplayer-2.72b-1.fc21.armv7hl requires libOpenCOLLADABaseUtils.so.0.1 1:blenderplayer-2.72b-1.fc21.armv7hl requires libMathMLSolver.so.0.1 1:blenderplayer-2.72b-1.fc21.armv7hl requires libGeneratedSaxParser.so.0.1 [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [gdesklet-SlideShow] gdesklet-SlideShow-0.9-16.fc21.noarch requires gdesklets [gdesklets-citation] gdesklets-citation-2.0-3.20120702git355e2ee.fc19.noarch requires gdesklets [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [golang-github-influxdb-influxdb] golang-github-influxdb-influxdb-datastore-0.8.0-0.3.rc4.git67f9869.fc21.noarch requires golang(github.com/jmhodges/levigo) golang-github-influxdb-influxdb-datastore-0.8.0-0.3.rc4.git67f9869.fc21.noarch requires golang(code.google.com/p/log4go) golang-github-influxdb-influxdb-devel-0.8.0-0.3.rc4.git67f9869.fc21.noarch requires golang(github.com/jmhodges/levigo) golang-github-influxdb-influxdb-devel-0.8.0-0.3.rc4.git67f9869.fc21.noarch requires golang(github.com/influxdb/go-cache) golang-github-influxdb-influxdb-devel-0.8.0-0.3.rc4.git67f9869.fc21.noarch requires golang(github.com/bmizerany/pat) golang-github-influxdb-influxdb-devel-0.8.0-0.3.rc4.git67f9869.fc21.noarch requires golang(code.google.com/p/log4go) [gorm] gorm-1.2.18-5.fc20.armv7hl requires libgnustep-gui.so.0.23 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django 0:1.5 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [openvas-client] openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6
Re: Koji timeout
On Tue, Nov 4, 2014 at 9:52 AM, Dan Horák d...@danny.cz wrote: the builders have 3.16.3-200.fc20.x86_64, could you retry the local mock rebuild with this kernel installed? I know it won't solve the problem, but might lead to having a reproducer. Eventually also with the same mock config as used for the koji build which you can get from koji mock-config --task 8009477 $ cd ~/rpmbuild/SPECS/ [andrea@panoramix SPECS]$ uname -r 3.16.3-200.fc20.x86_64 [andrea@panoramix SPECS]$ rpmbuild -bs pinta.spec Scritto: /home/andrea/rpmbuild/SRPMS/pinta-1.5-1.fc20.src.rpm [andrea@panoramix SPECS]$ mock /home/andrea/rpmbuild/SRPMS/pinta-1.5-1.fc20.src.rpm [...] Start: build setup for pinta-1.5-1.fc20.src.rpm Finish: build setup for pinta-1.5-1.fc20.src.rpm Start: rpmbuild -bb pinta-1.5-1.fc20.src.rpm Finish: rpmbuild -bb pinta-1.5-1.fc20.src.rpm Finish: build phase for pinta-1.5-1.fc20.src.rpm INFO: Done(/home/andrea/rpmbuild/SRPMS/pinta-1.5-1.fc20.src.rpm) Config(default) 7 minutes 15 seconds INFO: Results and/or logs in: /var/lib/mock/fedora-20-x86_64/result Finish: run [andrea@panoramix SPECS]$ mock -r fedora-rawhide-x86_64 /home/andrea/rpmbuild/SRPMS/pinta-1.5-1.fc20.src.rpm [...] Start: build phase for pinta-1.5-1.fc20.src.rpm Start: device setup Finish: device setup Start: build setup for pinta-1.5-1.fc20.src.rpm Finish: build setup for pinta-1.5-1.fc20.src.rpm Start: rpmbuild -bb pinta-1.5-1.fc20.src.rpm Finish: rpmbuild -bb pinta-1.5-1.fc20.src.rpm Finish: build phase for pinta-1.5-1.fc20.src.rpm INFO: Done(/home/andrea/rpmbuild/SRPMS/pinta-1.5-1.fc20.src.rpm) Config(fedora-rawhide-x86_64) 8 minutes 16 seconds INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result Finish: run [andrea@panoramix SPECS]$ su Password: [root@panoramix SPECS]# koji mock-config --task 8009477 koji-debug.cfg [root@panoramix SPECS]# mv koji-debug.cfg /etc/mock/ [root@panoramix SPECS]# exit exit [andrea@panoramix SPECS]$ mock -r koji-debug /home/andrea/rpmbuild/SRPMS/pinta-1.5-1.fc20.src.rpm [...] Start: build phase for pinta-1.5-1.fc20.src.rpm Start: device setup Finish: device setup Start: build setup for pinta-1.5-1.fc20.src.rpm Finish: build setup for pinta-1.5-1.fc20.src.rpm Start: rpmbuild -bb pinta-1.5-1.fc20.src.rpm Finish: rpmbuild -bb pinta-1.5-1.fc20.src.rpm Finish: build phase for pinta-1.5-1.fc20.src.rpm INFO: Done(/home/andrea/rpmbuild/SRPMS/pinta-1.5-1.fc20.src.rpm) Config(koji-debug) 10 minutes 3 seconds INFO: Results and/or logs in: /var/lib/mock/f20-build-repo_430101/result Finish: run [andrea@panoramix SPECS]$ Everything seems fine. Bye, Andrea -- 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: Koji timeout
On Tue, Nov 4, 2014 at 9:03 AM, Christopher Meng cicku...@gmail.com wrote:
On Tue, Nov 4, 2014 at 3:52 PM, Andrea Musuruane musur...@gmail.com wrote:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8009403
Hi,
Please try again with make directly instead of make %{?_smp_mflags}.
I tried but it stalled again:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8024559
BR,
Andrea
--
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: Koji timeout
On Tue, 4 Nov 2014 14:45:43 +0100
Andrea Musuruane musur...@gmail.com wrote:
On Tue, Nov 4, 2014 at 9:03 AM, Christopher Meng cicku...@gmail.com
wrote:
On Tue, Nov 4, 2014 at 3:52 PM, Andrea Musuruane
musur...@gmail.com wrote:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8009403
Hi,
Please try again with make directly instead of make %{?
_smp_mflags}.
I tried but it stalled again:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8024559
seems it's the mono compiler process that gets stuck, now to find out
why ...
Dan
--
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: Suggested Freeze Policy change for Fedora 22+
On Tue, Nov 04, 2014 at 03:26:50AM +0100, Kevin Kofler wrote: I talked to several people over the last couple days about what we can do to try to avoid the hero testing treadmill that we've been on during every Freeze in recent memory (specifically that we're usually fixing Blocker bugs until the day before the Go/No-Go meeting and that means that our QA team is pulling all-night test runs basically every week). Your proposed changes will only cause us to slip more often. Those hero runs have been done for a reason: to prevent a slip that would otherwise have been inevitable! Your proposed changes effectively ban such hero actions, actively preventing volunteers from helping releasing Fedora on time. I see no benefit whatsoever coming from those changes. Kevin, I'm missing something here. You're right that the QA hero runs are done to prevent slips, but I'm not seeing the logical connection between what Stephen suggests and _banning_ them. The idea is to make them less likely to be necessary with the cooparation of packagers as we go up to the release. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: Does Fedora have a technical expertise oriented SIG?
On Sun, 2 Nov 2014 10:13:10 -0500, Matthew Miller wrote: Is there any authoritative group at Fedora who wants the product to not suck like that? Authoritative? Probably FESCo. https://fedorahosted.org/fesco/ticket/1365 Basically, we need to tell every Fedora User that Firefox and Claws Mail don't play well together because of what Fedora's /usr/bin/firefox does whereas RHEL doesn't. Bad publicity already. And if those users follow /usr/share/doc/claws-mail/README.Fedora or are accustomed to setting various environment variables already, even that doesn't work everywhere with Fedora, e.g. gnome-terminal where NOTABUG has been today's response after nine months. -- 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] Announcing the release of Fedora 21 Beta!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Fedora 21 beta release is here, and - as usual - is packed with amazing improvements to Fedora, as well as fantastic free and open source software, gently harvested for your enjoyment. No bits were harmed in the making of this beta. What is the Beta Release? = The beta release is the last important milestone before the release of Fedora 21. A Beta release is code-complete and bears a very strong resemblance to the third and final release. Only critical bug fixes will be pushed as updates up to the general release of Fedora 21. The final release of Fedora 21 is [https://fedoraproject.org/wiki/Releases/21/Schedule] expected in early December. Meanwhile, download the beta of Fedora 21 and help us make it even better: http://fedoraproject.org/get-prerelease We need your help to make Fedora 21 the best release yet, so please take some time to download and try out the beta and make sure the things that are important to you are working. If you find a bug, please report it: https://fedoraproject.org/wiki/How_to_file_a_bug_report Every bug you uncover is a chance to improve the experience for millions of Fedora users worldwide. Together, we can make Fedora 21 a rock-solid distribution. We have a culture of coordinating new features and pushing fixes upstream as much as feasible and your feedback will help improve not only Fedora but Linux and free software on the whole. https://fedoraproject.org/wiki/Staying_close_to_upstream_projects (See the end of this announcement for more information on how to help.) Since it's a beta release, some problems may still be lurking. A list of problems that we already know about can be found at the Common F21 bugs page: http://fedoraproject.org/wiki/Common_F21_bugs Fedora.Next and Fedora 21 Products == As part of the Fedora.next initiative, Fedora 21 will boast three products, Cloud, Server, and Workstation: * Cloud: https://fedoraproject.org/wiki/Cloud * Server: https://fedoraproject.org/wiki/Server * Workstation: https://fedoraproject.org/wiki/Workstation We encourage you to visit the wiki pages providing the details of these individual products for more information. Spins - - In addition to the new Fedora products, Fedora users also have the choice of Fedora Spins that highlight user favorites like KDE Plasma Workspaces, Xfce, LXDE, and Sugar on a Stick (SoaS). If you're interested in trying out one of the spins, head over to the prelease page for Fedora Spins and grab the spins you're interested in: http://fedoraproject.org/get-spin-prerelease Fedora 21 Base - -- Each of the products will build on the base set of packages for Fedora. For instance, each product will use the same packages for the kernel, RPM, Yum, systemd, Anaconda, and so forth. The Base Working Group develops the standard platform for all Fedora products, which includes the installer, compose tools, and basic platform for the other products. The Base set of packages is not a full product intended for use on its own, but to be kept as a small, stable platform for other products to build on. Highlights in the Beta Release == In this section, we'll look at some of the things that are new or interesting in the Beta release. A Note on Shellshocked - -- You've probably read all about the Shellshocked vulnerability in GNU Bash, which affected Fedora 19, 20, and 21 Alpha. Rest assured that Fedora 21 beta has been patched to close this vulnerability. Fedora 21 Cloud === The Fedora Cloud Working Group and Special Interest Group (SIG) has been busy leading up to Fedora 21. Cloud is now a top-level product for Fedora 21, and will include images for use in private cloud environments like OpenStack, as well as AMIs for use on Amazon, and a new image streamlined for running Docker containers. Modular Kernel Packaging for Cloud - -- Space is precious, and there's little reason to include drivers for hardware that doesn't exist in the cloud. As part of the work for Fedora 21, the cloud SIG and kernel team split the kernel into two packages. One package contains the minimum modules for running in a virtualized environment, the other contains the larger set of modules for a more general installation. As a result, the F21 beta cloud image is 10% smaller than F20, making for faster deployment. Fedora Atomic Host - -- Red Hat announced Project Atomic (http://projectatomic.io/), in early April of this year as an effort to provide the tools and patterns for a streamlined operating system to run Docker containers. The Fedora 21 release will be the first to offer an Atomic host for Fedora, which includes a minimal set of packages and an image composed with rpm-ostree. While using the same RPMs as other Fedora offerings, the Atomic host will allow users to roll
Note on 'systemd-216-9'
An update has been submitted for systemd today: https://admin.fedoraproject.org/updates/kmod-18-4.fc21,systemd-216-9.fc21 with a fairly short description. I wanted to flag up that, in fact, systemd-216-9 is a major change from systemd-216-8 and is not really systemd 216 at all. systemd-216-8 (and 216-1 through 216-5) and earlier) was more or less identical to upstream systemd-stable 216: http://cgit.freedesktop.org/systemd/systemd-stable/log/?h=v216-stable . systemd 216-9 is not built from 216 at all, it is in fact systemd-217 with some particular changes (presumably intended to be the most disruptive ones) reverted. When I dropped build-related files and directories and documentation from the trees, did a context-free recursive diff, and filtered out the metadata from the diff, it still worked out at 7,000 lines worth of additions and removals between the underlying code of 'systemd-216-8' and 'systemd-216-9'. This is a lot of change to land between Beta and Final. Testers, please take care to test the update thoroughly, despite the small bump and small description it is a major change to the package. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Note on 'systemd-216-9'
On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote: systemd 216-9 is not built from 216 at all, it is in fact systemd-217 Why the misleading version number? -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Note on 'systemd-216-9'
Hi On Tue, Nov 4, 2014 at 11:37 AM, Tomasz Torcz wrote: On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote: systemd 216-9 is not built from 216 at all, it is in fact systemd-217 Why the misleading version number? More importantly, why is this pushed so late in the release cycle? 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: Requiring all files in /usr to be world-readable?
Hello, - Original Message - On Mon, 03.11.14 09:13, Miloslav Trmač (m...@redhat.com) wrote: Hello, - Original Message - On Fri, 31.10.14 10:04, Andrew Lutomirski (l...@mit.edu) wrote: I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467 Thoughts? I very much agree with this, but I'd really prefer if we'd list what is allowed rather than just declare what is forbidden. What is the use case for such a blanket requirement? fpc/467 lists the virt thing I so far disagree with, and other uses cases in there actually need much less than all of /usr. We are working on allowing stateless system boot up with /usr. For that I really want the ability that any user can copy /usr to some other place without having privileges, and then boot that up. Replicating a system shouldn't require privileges. Could you expand on the flow of thought from “stateless system“ to “distribution by replication” and (separately?) “administration/replication by any user”? I don’t see how that follows. Moreover, the stateless systems stuff actually enables sharing /usr over the network. In some setups network sharing servers tend to refuse access to networked clients if the files are marked inaccessible, under the assumption that root on the networked client might not be the same as root on the server. Is this limited to treating root specifically, or generally anything non-world-readable? I am only aware of the former (in NFS). In general, cleaning this up is basic hygiene, it makes things much simpler, if you just allow 5 kinds of files, and that's it. It would make things more uniform, not simpler. Addition of the rule/assumption makes the design more complex. A short list like this should be everything we should allow in /usr: a) symlinks b) directories with access mode 0555 c) files with access mode 0444 (optionally 0644 if owned by root user) d) files with access mode 0555 (optionally 0755 if owned by root user) e) files with access mode 2555 (optionally 2755 if owned by root user) f) files with access mode 4555 snip Secondarily: The rationale that the executables of suid files are public and thus it is useless to make them non-readable is false for 1) any non-distribution packages 2) local rebuilds Fedora has no control about those and should not make any restrictions on the stuff we don't control, don't package. But then we go back to “we don’t control it, so we can’t make that assumption on /usr contents, so we can’t design applications to require such /usr contents”; what Fedora packages is not all that relevant for designs that assume an _universal_ property over /usr. Or perhaps we should require it for a specific subset of /usr where we know that the benefits/uses enabled by such a requirement outweight the costs. 3) in-distribution packages for which the worm doesn’t carry pre-generated exploit parameters. This would be security by obscurity, nothing more. Also, it's wrong. Either you have a worm that carries a fixed set of pre-generated exploit parameters. It will exploit what it can exploit, and won't what it doesn't have any pre-generates exploit parameters around. There is one more set: where the exploit parameters can be derived by automated analysis of the on-system binary (perhaps just using nm). Mirek -- 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 21 Final Test Compose 1 (TC1) Available Now!
As per the Fedora 21 schedule [1], Fedora 21 Final Test Compose 1 (TC1) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/6031 . Please see the following pages for download links (including delta ISOs) 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 Ideally, all Alpha, Beta, and Final priority test cases for each of these test pages [2] should pass in order to meet the Final Release Criteria [3]. Help is available on #fedora-qa on irc.freenode.net [4], or on the test list [5]. Create Fedora 21 Final test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/6031 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-21/f-21-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan [3] https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria [4] irc://irc.freenode.net/fedora-qa [5] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ 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: Note on 'systemd-216-9'
On Tue, 2014-11-04 at 17:37 +0100, Tomasz Torcz wrote: On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote: systemd 216-9 is not built from 216 at all, it is in fact systemd-217 Why the misleading version number? There is a comment in the spec: # This is really closer to 217 than to 216, and it is easier to revert a few # patches then to carry all the other patches after 216. and a changelog note: - Pull more changes from upstream, including post-217 bugfixes. This is now a bastard mix of systemd-216 and systemd-217, with some of the important changes in systemd 217 still reverted: readahead removal, timedatectl change, fq_codel as default, job timeouts for init and poweroff, multi-seat-x removal, coredumps from watchdog timeouts. For the record, systemd-216-8 had ~588 patches. I think the intent is that 216-8 and 216-9 be more or less the same codebase but arrived at in different ways, but in practice there seems to be a noticeable difference. The diff I came up with is: https://www.happyassassin.net/temp/systemd-2168-2169.diff if anyone wants to check it (that version has context left in). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Requiring all files in /usr to be world-readable?
On Tue, Nov 4, 2014 at 8:42 AM, Miloslav Trmač m...@redhat.com wrote: Hello, - Original Message - On Mon, 03.11.14 09:13, Miloslav Trmač (m...@redhat.com) wrote: Hello, - Original Message - On Fri, 31.10.14 10:04, Andrew Lutomirski (l...@mit.edu) wrote: I filed an FPC ticket: https://fedorahosted.org/fpc/ticket/467 Thoughts? I very much agree with this, but I'd really prefer if we'd list what is allowed rather than just declare what is forbidden. What is the use case for such a blanket requirement? fpc/467 lists the virt thing I so far disagree with, and other uses cases in there actually need much less than all of /usr. We are working on allowing stateless system boot up with /usr. For that I really want the ability that any user can copy /usr to some other place without having privileges, and then boot that up. Replicating a system shouldn't require privileges. Could you expand on the flow of thought from “stateless system“ to “distribution by replication” and (separately?) “administration/replication by any user”? I don’t see how that follows. I can only speak for my own perspective on this, which may not match Lennart's at all: A major part of the stateless system idea is that /usr should contain all of the files needed to boot what is effectively a fresh install. IOW, systemd should be able to boot a fully-functional system that starts with an empty /etc and /var, OS code in /usr, and a handful of kernel-provided mounts and symlinks filling out the root directory. If /usr is world-readable, then an unprivileged user can use /usr to boot a fully-functional Fedora system in a number of ways. They can pipe it into QEMU/KVM using virtfs (what virtme does, although it's not currently targeting this usecase), they can bind-mount it into an unprivileged container (I have no idea whether LXC can do this easily right now, but it's straightforward. I imagine that someone will add support to nspawn to do exactly this at some point. As of the last time I looked at the nspawn code, it wasn't set up for this yet, though.) They can serve it over whatever protocol they like (NFS using Ganesha, for example) to another physical machine and run it there. I'm sure that other people might think of other uses for this. virtme will give you a fully function Fedora shell right now (no systemd) in a couple of seconds. You can try it: $ sudo dnf install virtme qemu-system-x86 [or whatever the appropriate QEMU is] $ virtme-run --installed-kernel If you try to run any of the audit tools inside virtme, you can't, because virtme can't read them from /usr. If I wrote the small amount of code needed, then you could run: $ virtme-run --installed-kernel --stateless-usr=/usr --graphics This is likely to have all kinds of problems as a result of the polkit rules being unreadable, though. See: http://0pointer.net/blog/projects/stateless.html --Andy -- 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: Note on 'systemd-216-9'
On Tue, Nov 04, 2014 at 08:30:32 -0800, Adam Williamson adamw...@fedoraproject.org wrote: systemd-216-8 (and 216-1 through 216-5) and earlier) was more or less identical to upstream systemd-stable 216: http://cgit.freedesktop.org/systemd/systemd-stable/log/?h=v216-stable . systemd 216-9 is not built from 216 at all, it is in fact systemd-217 with some particular changes (presumably intended to be the most There is a definite problem with 217 I have been seeing in rawhide. I am seeing an intermittent (very roughly 50% of boots) problem where copying logs to persistent storage hangs for a long time. This is described in: https://bugzilla.redhat.com/show_bug.cgi?id=1159641 Though I actually filed that bug because the debug-shell was shutting the system down. -- 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: Multiple problems with multiple monitors
On 2014-10-13 10:23 AM, Basil Mohamed Gohar wrote: I've searched for bugs related to the specific problems I've been having, and I've not been able to find anything that describes what I'm seeing. I have an HP EliteBook 840 that also comes with an UltraDock, to which I've plugged-in two external monitors and I use in conjunction with the built-in laptop display. Issue #1: I use LUKS to encrypt my disk, and when I first start up the computer, after choosing the kernel to boot into in GRUB, the GUI prompt for the LUKS passphrase shows-up on the middle monitor, not the laptop's built-in display. I don't mind this when I have multiple monitors plugged-in, but when I boot-up without the external monitors, such as when I'm unplugged from the UltraDock, I now get NO GUI prompt for the LUKS passphrase. I can enter it, and I can see a text prompt if I hit ESC. I suspect its attempting to display on the now phantom, unplugged monitor. Note, it was never plugged-in during this cycle. The problem is, I don't even know what's instructing LUKS or the GUI prompt to display on any monitor, so I don't know where to go to debug this. Issue #2: When I undock my laptop while logged-in, Gnome Shell just crashes. When I redock after the laptop has been started when unconnected, one of the two external monitors start-up (the one connected by VGA), but not the one connected by a DisplayPort connection. And, recently (but not when I first started using this laptop with the dock, which was about a month ago), now when I start-up with the laptop docked and both external monitors connected, both external monitors will be active, but the built-in display will show nothing. Gnome Shell reports the built-in display is active, but will not display anything unless I deactivate it and reactivate it via the settings Displays utility. Issue #3: The monitor connected via DisplayPort display significant tearing and delay on the upper-right half of the screen in the form of a triangle taking-up half of the screen. Reading about displayport and tearing issues, I guess the idea that these were resolved in the past. I don't know if this is the same or something different. I don't mean to use devel as a bug reporting venue, but I think these issues are either related or I just don't know how to address them to make significant progress to fixing them. Any guidance is more than welcome. Thanks! -- Libre Video http://librevideo.org So, a recent update which included a kernel update fixed issue #2, and I was really happy. Then, another update this week, which included multiple systemd updates, restored/rebroke issue #2 above (the docking/undocking) issue. -- Libre Video http://librevideo.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[IMPORTANT] Fedora 21 Schedule Change
== tl;dr Version == We are accelerating the Fedora 21 schedule so that we will enter Final Freeze one week earlier than previously described on the schedule page[1]. This means that all fixes intended for inclusion in the Fedora 21 release must be submitted for the stable repository no later than November 17th (so that we have time to do the updates push and build the Release Candidate on November 18th). The Final Release date will remain at December 9th. This essentially means that we are implementing a planned two-week Final Freeze instead of the traditional one-week freeze. == Why are we doing this? == The Fedora 21 cycle has run considerably beyond its original deadline, primarily due to the massive number of changes that we have been implementing this time around (in particular, the shift to producing three top-tier Products has had a significant impact). Because of the schedule adjustments that took place during the Alpha and Beta phases, we are now looking at an early December release for Fedora 21. With the Final Release being so close to the December holidays, any delay that occurs at this point puts Fedora at real danger of slipping out of 2014 entirely. To minimize this risk, FESCo has decided (with QA and rel-eng input), that we are going to make a one-time modification to our schedule. The historic cause of slips has been that the time between the start of Freeze and the completion of the release validation has never left enough room in the schedule to fix any blocker issues that come up. By moving up the Freeze, we hope to be able to identify these blockers faster and maintain our curernt planned release date. We are aware that shortening a schedule puts added strain on our developers, which is why we generally do not do so except at great reluctance. However, the Fedora Updates Policy[2] describes the period between Beta and Final releases thusly: The branched tree should now be stabilized and prepared for release. Major changes should be avoided during this period. So the shorter time-frame should already be dedicated only to addressing bug-fixes. Most of these can be handled with a release-day update if needed; those that are truly release- blocking will remain so (and will be allowed to be built into the release candidates during the freeze). [1] https://fedoraproject.org/wiki/Releases/21/Schedule [2] http://fedoraproject.org/wiki/Updates_Policy#Beta_to_Pre_Release 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: Proposal for integration tests infrastructure
On Tue, 2014-11-04 at 04:56 -0500, Colin Walters wrote: This looks related to: https://wiki.gnome.org/GnomeGoals/InstalledTests (Note that the Issues with make check is equivalent to issues with rpm %check) It's implemented by gnome-continuous, and there's been a bit of effort to make -tests subpackages for some pieces in Fedora, but AFAIK no runner yet. The upstream continuous test runner is in the gnome-desktop-testing package. And the following tests packages are available to make use of it: gjs-tests gtk3-tests glib2-tests pango-tests clutter-tests gdk-pixbuf2-tests gnome-weather-tests gtksourceview3-tests glib-networking-tests I would love to bring the other upstream tests to Fedora as well - altogether, we have 500 tests running continuously in gnome-continuous. -- 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: Note on 'systemd-216-9'
On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote: An update has been submitted for systemd today: https://admin.fedoraproject.org/updates/kmod-18-4.fc21,systemd-216-9.fc21 with a fairly short description. I wanted to flag up that, in fact, systemd-216-9 is a major change from systemd-216-8 and is not really systemd 216 at all. Hi Adam, this annoucement misrepresents the situation quite a bit. Since you are speaking from your position as QA chief, your word carries a lot of weight. We *were* in contact on IRC yesterday, I'm in #fedora-devel semi-permanently, and it should not be a problem to show it to me before you sent it out, since you are talking about updates I made. If you disagreed with what I have to say and *then* sent the mail, that would be fine, but not like this, out of the blue. Anyway, returning to the matter at hand, systemd-216-9 is fairly close to systemd-216-8, has patches over it to fix *known bugs*, the ones listed in the update, a few listed on the freedesktop systemd bug tracker, and a few small ones I found while testing the update. The delta is not as small as I would like, but fits imho in the rules. If systemd upstream was doing point releases, this would certainly qualify as one. Actually it was 216-2 which contained the biggest change. I built it on Oct 7, before the alpha freeze. It was called 216 because 217 wasn't tagged yet, and I didn't want F21 to miss the bugfixes and features which have accumulated in the upstream git. So 216-2 has most of the post-216 commits, and 216-9 is fairly close to that. It *is* built from 217 by reverting the major changes done after 216-2, but that is a matter of convenience... It was simply simpler and more explicit this way (reverts not ommitted patches). systemd-216-8 (and 216-1 through 216-5) and earlier) was more or less identical to upstream systemd-stable 216: http://cgit.freedesktop.org/systemd/systemd-stable/log/?h=v216-stable . systemd 216-9 is not built from 216 at all, it is in fact systemd-217 with some particular changes (presumably intended to be the most disruptive ones) reverted. When I dropped build-related files and directories and documentation from the trees, did a context-free recursive diff, and filtered out the metadata from the diff, it still worked out at 7,000 lines worth of additions and removals between the underlying code of 'systemd-216-8' and 'systemd-216-9'. This is a lot of change to land between Beta and Final. Like I said on IRC yesterday, a large part of this is code which is not compiled for Fedora, or unsupported [*], or tests. Testers, please take care to test the update thoroughly, despite the small bump and small description it is a major change to the package. That I can agree with. I'd much prefer a concrete list of things to test in this update though, which would be *useful* and lead to a better release. Right now you suggest that anything might be broken. Zbyszek [*] systemd-resolved, systemd-networkd -- 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: Note on 'systemd-216-9'
On Tue, Nov 04, 2014 at 08:56:40AM -0800, Adam Williamson wrote: On Tue, 2014-11-04 at 17:37 +0100, Tomasz Torcz wrote: On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote: systemd 216-9 is not built from 216 at all, it is in fact systemd-217 Why the misleading version number? There is a comment in the spec: # This is really closer to 217 than to 216, and it is easier to revert a few # patches then to carry all the other patches after 216. and a changelog note: - Pull more changes from upstream, including post-217 bugfixes. This is now a bastard mix of systemd-216 and systemd-217, with some of the important changes in systemd 217 still reverted: readahead removal, timedatectl change, fq_codel as default, job timeouts for init and poweroff, multi-seat-x removal, coredumps from watchdog timeouts. For the record, systemd-216-8 had ~588 patches. I think the intent is that 216-8 and 216-9 be more or less the same codebase but arrived at in different ways, but in practice there seems to be a noticeable difference. The diff I came up with is: https://www.happyassassin.net/temp/systemd-2168-2169.diff This diffs autogenerated content. It also contains a rename of functions to add mac_ prefixes to selinux functions. And a rename to hashmap functions in preparation of for implementation changes which were done post 217 (and are not part of this update). It is also done without -M, so catches some renames as significant changes. I'm frankly puzzled about the point of this exercise. 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: Does Fedora have a technical expertise oriented SIG?
On Sun, Nov 02, 2014 at 09:13:07AM -0800, Adam Williamson wrote: On Sun, 2014-11-02 at 10:13 -0500, Matthew Miller wrote: On Sun, Nov 02, 2014 at 04:08:36PM +0100, Michael Schwendt wrote: Is there any authoritative group at Fedora who wants the product to not suck like that? Authoritative? Probably FESCo. Well, this sounds like a packaging issue, doesn't it? Er, no? I see where you're coming from, and the distinction can be somewhat muddled at times. It is in a package, granted, but so is everything else, but Software should honor TMPDIR and everything across the distro should have the same defaults isn't really about packaging the software at all. Wouldn't the expected outcome be a packaging guideline for how to deal with temporary directory locations? So, the packaging committee... Maybe, but maybe not? Look at it this way: the last times we changed the rules here are effectively these two features: http://fedoraproject.org/wiki/Features/ServicesPrivateTmp http://fedoraproject.org/wiki/Features/tmp-on-tmpfs Both of them specify that things should use /tmp - the first for a select batch of programs, the second for the whole distro. In neither case is there an FPC ruling on the matter, and in neither case is the actual packaging /necessarily/ affected. If there's no need to have a specific rule about where a packager should be installing files, what kind of config file should be used to manage something, or other things of that nature, this sort of thing usually doesn't go through FPC. -- Peter -- 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: Note on 'systemd-216-9'
On Tue, 2014-11-04 at 21:13 +0100, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote: An update has been submitted for systemd today: https://admin.fedoraproject.org/updates/kmod-18-4.fc21,systemd-216-9.fc21 with a fairly short description. I wanted to flag up that, in fact, systemd-216-9 is a major change from systemd-216-8 and is not really systemd 216 at all. Hi Adam, this annoucement misrepresents the situation quite a bit. Since you are speaking from your position as QA chief I don't hold that position, and there isn't such a position. , your word carries a lot of weight. We *were* in contact on IRC yesterday, I'm in #fedora-devel semi-permanently, and it should not be a problem to show it to me before you sent it out, since you are talking about updates I made. If you disagreed with what I have to say and *then* sent the mail, that would be fine, but not like this, out of the blue. Sorry for not running it by you first, but I'm just trying to stay on top of a whole bunch of stuff for F21 right now. I wasn't *complaining* about anything. I just wanted to make sure people didn't rubber-stamp 216-9 on the impression that it contained a single bugfix vs -8 or something. Anyway, returning to the matter at hand, systemd-216-9 is fairly close to systemd-216-8, has patches over it to fix *known bugs*, the ones listed in the update, a few listed on the freedesktop systemd bug tracker, and a few small ones I found while testing the update. The delta is not as small as I would like, but fits imho in the rules. I didn't say otherwise, but I wouldn't characterize the diff posted earlier as 'fairly close', it really isn't. Anything past a dozen LOC is not 'fairly close', IMHO. If systemd upstream was doing point releases, this would certainly qualify as one. Well, I didn't want to bring it up, but that would rather clarify things, wouldn't it? Right now we have a sort of messy situation where what the Fedora package is is basically 'whatever's on the systemd-stable 216 branch upstream', and what that is is 'whatever you find most convenient right at present' - like the Fedora package, up until a couple of days ago that branch was a few hundred commits added to the 216 tarball, whereas now it's been completely changed to be 217 minus a few reversions. This I guess makes sense to you as you have this kind of mental vision of what you want '216 stable' to be, so it makes sense to at some point say 'oh hey, my mental 216 stable is just 217 minus X, Y and Z, so let's make the branch be that' but it's rather difficult for anyone else to follow, there isn't much continuity. Things like point releases and changelogs and consistent maintenance procedures and more differentiation between upstream and downstream changes would make the picture clearer. While I was researching the mail I kind of pieced together all this history from the package changelog, the package SCM commit log, the upstream SCM log, and the Bodhi update comments, but you *do* have to go through all of that to actually figure out what the hell's going on, because it's all just '216-x', there's no 216 point releases, no release documentation, not a lot to differentiate package changes and upstream changes. Actually it was 216-2 which contained the biggest change. I built it on Oct 7, before the alpha freeze. It was called 216 because 217 wasn't tagged yet, and I didn't want F21 to miss the bugfixes and features which have accumulated in the upstream git. So 216-2 has most of the post-216 commits, and 216-9 is fairly close to that. Again, well, I posted the diff, and I disagree that it's 'fairly close'. 216-2 was certainly hugely different to 216-1, but 216-1 never went to updates-testing, so it doesn't really signify. systemd-216-8 (and 216-1 through 216-5) and earlier) was more or less identical to upstream systemd-stable 216: http://cgit.freedesktop.org/systemd/systemd-stable/log/?h=v216-stable . systemd 216-9 is not built from 216 at all, it is in fact systemd-217 with some particular changes (presumably intended to be the most disruptive ones) reverted. When I dropped build-related files and directories and documentation from the trees, did a context-free recursive diff, and filtered out the metadata from the diff, it still worked out at 7,000 lines worth of additions and removals between the underlying code of 'systemd-216-8' and 'systemd-216-9'. This is a lot of change to land between Beta and Final. Like I said on IRC yesterday, a large part of this is code which is not compiled for Fedora, or unsupported [*], or tests. Testers, please take care to test the update thoroughly, despite the small bump and small description it is a major change to the package. That I can agree with. I'd much prefer a concrete list of things to test in this update though, which would be *useful* and lead to a better release. Right now
Re: Note on 'systemd-216-9'
On Tue, Nov 04, 2014 at 12:27:58PM -0800, Adam Williamson wrote: Testers, please take care to test the update thoroughly, despite the small bump and small description it is a major change to the package. That I can agree with. I'd much prefer a concrete list of things to test in this update though, which would be *useful* and lead to a better release. Right now you suggest that anything might be broken. Well, I just said it's a big change and the update description doesn't accurately encapsulate it. I would of course be very happy with a concrete list of things to test in the update. The update description would be a good place for it. Well, then ping me on IRC to update the description (or even mail it to test@ or whatever) and with luck 30 minutes later we would have a much better picture than by looking at a squashed diff. Another good place for concrete lists of changes would be in the changelogs for the upstream point releases which we don't have...:) Sure, that would be nice. 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: Note on 'systemd-216-9'
On Tue, 2014-11-04 at 21:20 +0100, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Nov 04, 2014 at 08:56:40AM -0800, Adam Williamson wrote: On Tue, 2014-11-04 at 17:37 +0100, Tomasz Torcz wrote: On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote: systemd 216-9 is not built from 216 at all, it is in fact systemd-217 Why the misleading version number? There is a comment in the spec: # This is really closer to 217 than to 216, and it is easier to revert a few # patches then to carry all the other patches after 216. and a changelog note: - Pull more changes from upstream, including post-217 bugfixes. This is now a bastard mix of systemd-216 and systemd-217, with some of the important changes in systemd 217 still reverted: readahead removal, timedatectl change, fq_codel as default, job timeouts for init and poweroff, multi-seat-x removal, coredumps from watchdog timeouts. For the record, systemd-216-8 had ~588 patches. I think the intent is that 216-8 and 216-9 be more or less the same codebase but arrived at in different ways, but in practice there seems to be a noticeable difference. The diff I came up with is: https://www.happyassassin.net/temp/systemd-2168-2169.diff This diffs autogenerated content. There's a bit of stuff at the top that could have been trimmed out, sure, but I didn't want to spend *too* much time on it. It's not that much. It also contains a rename of functions to add mac_ prefixes to selinux functions. And a rename to hashmap functions in preparation of for implementation changes which were done post 217 (and are not part of this update). None of which was communicated in the package changelog, or the update description. And remember, what you just wrote is gobbledegook to most of the people testing updates, they are not necessarily coders and do not necessarily know anything about systemd internals. They are folks volunteering to provide feedback on pre-release updates; even those who are also Fedora packagers are not necessarily coders, and those who are coders don't necessarily know systemd's design. It is also done without -M, so catches some renames as significant changes. I'm frankly puzzled about the point of this exercise. Well, remember, I'm not a specialist. I'm just the QA monkey. I don't know the detailed ins and outs of every codebase in the distro, QA doesn't in general, we just try to test the bits. The more information is available about what those changes actually *are*, communicated in a style appropriate to the knowledge level of the folks doing the testing, the better that job is going to get done. I didn't inspect the diff in a huge degree of detail, I just was interested in how much difference there actually is between '216 stable plus 500+ patches' (216-5 / 216-8) and '217 minus some reversions (216-6 / 216-9), so I bashed at the trees for fifteen minutes trying to figure it out, and it looked like rather more difference than the update description and package changelog suggested, so I thought it would be a good idea to communicate that. Again, one thing that could prevent us having to have this kind of discussion would be for systemd to have more sophisticated/heavier/whatever stable release management. The systemd-stable repo is a definite improvement on the previous approach, but it's still missing actual *release management*, when you say 'OK, we're going to release an actual thing that will be called systemd 216.1 and we're going to put all these bits in it and we're going to write down what those are'. Right now if someone asks what systemd is in Fedora 21, what do we say? Well, we can say 'systemd-216 stable' and point to http://cgit.freedesktop.org/systemd/systemd-stable/log/?h=v216-stable , but then they ask 'what's that?', and what do we say? Where is its existence described? It's not systemd-216. It's not systemd-217. It doesn't have a version, it doesn't have a tarball, it doesn't have a readme, it doesn't have a changelog. The NEWS file says CHANGES WITH 217:, so it seems dangerous to assume that it accurately describes all the changes on the 216-stable branch and *only* those changes. You only really have a hope of understanding what it *is* by reading the commit log, somehow grokking that it used to be produced by backporting a ton of changes onto 216 but is now produced by reverting/excluding a bunch of stuff from 217, and understanding what the things that were reverted actually *are* and what the implications of their reversion/exclusion are. And then to answer the original question, you have to figure out somehow whether there are any downstream-specific changes in the Fedora package vs. the 216-stable tree and what they are, when the current maintenance approach means that when we update to a new checkout of the 216-stable tree we bump the package release but when we add a downstream specific change we...bump the package release.
Re: Note on 'systemd-216-9'
On Tue, 2014-11-04 at 21:37 +0100, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Nov 04, 2014 at 12:27:58PM -0800, Adam Williamson wrote: Testers, please take care to test the update thoroughly, despite the small bump and small description it is a major change to the package. That I can agree with. I'd much prefer a concrete list of things to test in this update though, which would be *useful* and lead to a better release. Right now you suggest that anything might be broken. Well, I just said it's a big change and the update description doesn't accurately encapsulate it. I would of course be very happy with a concrete list of things to test in the update. The update description would be a good place for it. Well, then ping me on IRC to update the description (or even mail it to test@ or whatever) and with luck 30 minutes later we would have a much better picture than by looking at a squashed diff. Well, that's more or less what my initial mail was meant to be. I didn't post the diff initially, only in response to a follow-up mail asking what the difference between the builds was. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Note on 'systemd-216-9'
On Tue, Nov 04, 2014 at 12:48:36PM -0800, Adam Williamson wrote: On Tue, 2014-11-04 at 21:20 +0100, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Nov 04, 2014 at 08:56:40AM -0800, Adam Williamson wrote: On Tue, 2014-11-04 at 17:37 +0100, Tomasz Torcz wrote: On Tue, Nov 04, 2014 at 08:30:32AM -0800, Adam Williamson wrote: systemd 216-9 is not built from 216 at all, it is in fact systemd-217 Why the misleading version number? There is a comment in the spec: # This is really closer to 217 than to 216, and it is easier to revert a few # patches then to carry all the other patches after 216. and a changelog note: - Pull more changes from upstream, including post-217 bugfixes. This is now a bastard mix of systemd-216 and systemd-217, with some of the important changes in systemd 217 still reverted: readahead removal, timedatectl change, fq_codel as default, job timeouts for init and poweroff, multi-seat-x removal, coredumps from watchdog timeouts. For the record, systemd-216-8 had ~588 patches. I think the intent is that 216-8 and 216-9 be more or less the same codebase but arrived at in different ways, but in practice there seems to be a noticeable difference. The diff I came up with is: https://www.happyassassin.net/temp/systemd-2168-2169.diff This diffs autogenerated content. There's a bit of stuff at the top that could have been trimmed out, sure, but I didn't want to spend *too* much time on it. It's not that much. It also contains a rename of functions to add mac_ prefixes to selinux functions. And a rename to hashmap functions in preparation of for implementation changes which were done post 217 (and are not part of this update). None of which was communicated in the package changelog, or the update description. And remember, what you just wrote is gobbledegook to most of the people testing updates Well, it is gobbledegook to everyone, it is a completely meaningless internal change. It was done with a sed script, and if the tree still compiles afterwards, then its OK. It blows up the diff. It also makes it annoying to backport later patches because of trivial conflicts, which is why I include it in the update. , they are not necessarily coders and do not necessarily know anything about systemd internals. They are folks volunteering to provide feedback on pre-release updates; even those who are also Fedora packagers are not necessarily coders, and those who are coders don't necessarily know systemd's design. It is also done without -M, so catches some renames as significant changes. I'm frankly puzzled about the point of this exercise. Well, remember, I'm not a specialist. I'm just the QA monkey. I don't know the detailed ins and outs of every codebase in the distro, QA doesn't in general, we just try to test the bits. The more information is available about what those changes actually *are*, communicated in a style appropriate to the knowledge level of the folks doing the testing, the better that job is going to get done. I didn't inspect the diff in a huge degree of detail, I just was interested in how much difference there actually is between '216 stable plus 500+ patches' (216-5 / 216-8) and '217 minus some reversions (216-6 / 216-9), so I bashed at the trees for fifteen minutes trying to figure it out, and it looked like rather more difference than the update description and package changelog suggested, so I thought it would be a good idea to communicate that. OK, let's not dwell on this. I don't think this is a useful measure in any way. Again, one thing that could prevent us having to have this kind of discussion would be for systemd to have more sophisticated/heavier/whatever stable release management. If you want me (or someone else) to provide better changelogs or whatever, than I'm happy to discuss it, but a thread about a specific update on test@ is hardly the place. The systemd-stable repo is a definite improvement on the previous approach, but it's still missing actual *release management*, when you say 'OK, we're going to release an actual thing that will be called systemd 216.1 and we're going to put all these bits in it and we're going to write down what those are'. If you look the diff you made, it NEWS file is accurate and lists user-visible changes. I guess it should not say '217'. This *is* a good suggestion, in the future I'll make sure that the NEWS file says that it pertains to the release. Right now if someone asks what systemd is in Fedora 21, what do we say? Well, we can say 'systemd-216 stable' and point to http://cgit.freedesktop.org/systemd/systemd-stable/log/?h=v216-stable , but then they ask 'what's that?', and what do we say? Where is its existence described? It's not systemd-216. It's not systemd-217. It doesn't have a version, it doesn't have a tarball, it doesn't have a
Re: Note on 'systemd-216-9'
On Tue, Nov 04, 2014 at 12:49:27PM -0800, Adam Williamson wrote: On Tue, 2014-11-04 at 21:37 +0100, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Nov 04, 2014 at 12:27:58PM -0800, Adam Williamson wrote: Testers, please take care to test the update thoroughly, despite the small bump and small description it is a major change to the package. That I can agree with. I'd much prefer a concrete list of things to test in this update though, which would be *useful* and lead to a better release. Right now you suggest that anything might be broken. Well, I just said it's a big change and the update description doesn't accurately encapsulate it. I would of course be very happy with a concrete list of things to test in the update. The update description would be a good place for it. Well, then ping me on IRC to update the description (or even mail it to test@ or whatever) and with luck 30 minutes later we would have a much better picture than by looking at a squashed diff. Well, that's more or less what my initial mail was meant to be. I didn't post the diff initially, only in response to a follow-up mail asking what the difference between the builds was. The first mail I saw was this: I wanted to flag up that, in fact, systemd-216-9 is a major change from systemd-216-8 and is not really systemd 216 at all. ... worked out at 7,000 lines worth of additions and removals between the underlying code of 'systemd-216-8' and 'systemd-216-9'. 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: Note on 'systemd-216-9'
On Tue, 2014-11-04 at 22:41 +0100, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Nov 04, 2014 at 12:49:27PM -0800, Adam Williamson wrote: On Tue, 2014-11-04 at 21:37 +0100, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Nov 04, 2014 at 12:27:58PM -0800, Adam Williamson wrote: Testers, please take care to test the update thoroughly, despite the small bump and small description it is a major change to the package. That I can agree with. I'd much prefer a concrete list of things to test in this update though, which would be *useful* and lead to a better release. Right now you suggest that anything might be broken. Well, I just said it's a big change and the update description doesn't accurately encapsulate it. I would of course be very happy with a concrete list of things to test in the update. The update description would be a good place for it. Well, then ping me on IRC to update the description (or even mail it to test@ or whatever) and with luck 30 minutes later we would have a much better picture than by looking at a squashed diff. Well, that's more or less what my initial mail was meant to be. I didn't post the diff initially, only in response to a follow-up mail asking what the difference between the builds was. The first mail I saw was this: I wanted to flag up that, in fact, systemd-216-9 is a major change from systemd-216-8 and is not really systemd 216 at all. ... worked out at 7,000 lines worth of additions and removals between the underlying code of 'systemd-216-8' and 'systemd-216-9'. Oh, sorry. I thought I'd cut that bit before sending the mail. It went through a few revisions. Sorry :/ I was context-switching between a few different things. I wrote the mail a few different ways and to a few different recipients but in the end I only wanted to send out a more or less factual 'hey, heads up this update needs full testing' mail. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Note on 'systemd-216-9'
On Tue, 2014-11-04 at 22:39 +0100, Zbigniew Jędrzejewski-Szmek wrote: I understand that systemd git is not easy to follow, but I don't think this differes that much from other fast-changing projects. If you take a random kernel release, it's not like there's a nice lwn-style description somewhere. But there are actual releases. There's a kernel 3.17.1, and a kernel 3.17.2. They are artifacts with some sort of concrete presence, an announcement mail and a changelog (even though yes, it's just a git commit log). People can discuss the artifact called '3.17.1', say 'oh hey that's broken in 3.17.1', whatever. There's no 'systemd 216.1' to discuss, there's just a git branch which keeps changing. Sure, any specific checkout of a git branch has superior capabilities to any tarball and you can make one from the other, but the point of there being a tarball called '3.17.1' is that *that's the thing that's 3.17.1*. A git branch that keeps changing is a very slippery thing to try and do testing or communication or whatever in relation to. The Fedora kernel maintainers maintain a clear distinction between upstream and downstream 'hats'; we don't just have kernel 3.17-1, kernel 3.17-2, kernel 3.17-3, kernel 3.17-4 with changes from an upstream git branch rolling in continuously, the upstream kernel releases are the downstream package versions and the package releases are downstream changes. The kernel package usually respects Fedora milestone freezes very well, it's maintained in such a way that blocker/FE-fixing changes can be isolated properly from other changes. The kernel maintainers also decide a long time in advance what kernel we're going to have in a Fedora release and stick to that. For F21 we decided quite late to pull in 3.17 instead of 3.16, but the kernel maintainers actively went out and talked to other groups (including QA) about that, and made sure that everyone was on the same page about it getting pulled in. (3.17 landed in stable on 10-12). [snip] checkout of the 216-stable tree we bump the package release but when we add a downstream specific change we...bump the package release. Well, there's really very little difference between upstream and downstream here. stable/v216-stable is updated when I add patches to the Fedora package. If they were both versioned, the version numbers would be pretty much the same anyway. But stable/v216-stable is *also* updated when you backport a whole bunch of changes from upstream master, or whatever. Again, to you this all feels like part of one process, but I'm not sure it really should be, especially for a very significant project like systemd. For me, upstream stable branches of something like systemd shouldn't really be intimately associated with the Fedora package of that same branch. The upstream stable branch should be maintained as a thing *in itself*, an object with a clear raison d'etre and maintenance policy and so on, and the Fedora package of that branch should be a separate thing. It shouldn't 'naturally' be the case that all these changes get sort of rolled together into the same big blob of code which exists as both an upstream git branch and a Fedora package which is a very direct reflection of that git branch, with all the same stuff landing in both at the same time. There are usually different constraints on upstream and downstream at different times; systemd isn't in a release freeze when Fedora is, for instance. Maybe it makes sense for change (X) to land on the upstream stable branch right now, but Fedora just wants blocker fix (Y). The current process doesn't really seem to handle that kind of thing very well, and it's exactly the kind of thing we have this distinction between upstream and downstream maintenance for. One simple change that might help a bit right now is to follow the Fedora package versioning convention for when your package is built from SCM snapshots: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages So the systemd package should not just be 'systemd-216-8', or whatever, but something like: systemd-216-8.20141104gitaf59039bc Yes, this makes sense when building from upstream git, where the date and the number correspond to something tangible. Here the list of patches is somewhat arbitrary: patches are backported if they are easy, or when they fix know problems. They often end up not in the same order as upstream, for example where a cleanup patch is much later cherry-picked to avoid diff conflicts in an actual patch that fixes something. So the upstream git hash (or date) would be very misleading. What I can do, and what should be useful, is to add tags to the stable branches where fedora releases are built from. I'm not sure if you're suggesting having tags on the *upstream* git repo that reflect *downstream* package builds, but that seems like more confusion between two separate processes to me - I'm suggesting more separation between the
Re: Announcing the release of Fedora 21 Beta!
. On Tuesday, November 4, 2014, 10:01:02 AM, Dennis Gilmore wrote: The Fedora 21 beta release is here, and - as usual - is packed with amazing improvements to Fedora, as well as fantastic free and open source software, gently harvested for your enjoyment. No bits were harmed in the making of this beta. * * * Spins - - In addition to the new Fedora products, Fedora users also have the choice of Fedora Spins that highlight user favorites like KDE Plasma Workspaces, Xfce, LXDE, and Sugar on a Stick (SoaS). If you're interested in trying out one of the spins, head over to the prelease page for Fedora Spins and grab the spins you're interested in: http://fedoraproject.org/get-spin-prerelease The Mate_Compiz spin is on the mirrors. Is there a reason it was omitted from the spins shown on this web page? -- 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: Announcing the release of Fedora 21 Beta!
2014-11-04 23:55 GMT+01:00 Al Dunsmuir al.dunsm...@sympatico.ca: . On Tuesday, November 4, 2014, 10:01:02 AM, Dennis Gilmore wrote: The Fedora 21 beta release is here, and - as usual - is packed with amazing improvements to Fedora, as well as fantastic free and open source software, gently harvested for your enjoyment. No bits were harmed in the making of this beta. * * * Spins - - In addition to the new Fedora products, Fedora users also have the choice of Fedora Spins that highlight user favorites like KDE Plasma Workspaces, Xfce, LXDE, and Sugar on a Stick (SoaS). If you're interested in trying out one of the spins, head over to the prelease page for Fedora Spins and grab the spins you're interested in: http://fedoraproject.org/get-spin-prerelease The Mate_Compiz spin is on the mirrors. Is there a reason it was omitted from the spins shown on this web page? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct I've re-added it right now, thank you for reporting that. It should be on the spins page in about 30 minutes or so. Kind regards. -- Robert Mayr (robyduck) -- 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: Announcing the release of Fedora 21 Beta!
On Tuesday, November 4, 2014, 6:01:35 PM, Robert Mayz wrote: 2014-11-04 23:55 GMT+01:00 Al Dunsmuir al.dunsm...@sympatico.ca: On Tuesday, November 4, 2014, 10:01:02 AM, Dennis Gilmore wrote: The Fedora 21 beta release is here, and - as usual - is packed with amazing improvements to Fedora, as well as fantastic free and open source software, gently harvested for your enjoyment. No bits were harmed in the making of this beta. * * * Spins - - In addition to the new Fedora products, Fedora users also have the choice of Fedora Spins that highlight user favorites like KDE Plasma Workspaces, Xfce, LXDE, and Sugar on a Stick (SoaS). If you're interested in trying out one of the spins, head over to the prelease page for Fedora Spins and grab the spins you're interested in: http://fedoraproject.org/get-spin-prerelease The Mate_Compiz spin is on the mirrors. Is there a reason it was omitted from the spins shown on this web page? I've re-added it right now, thank you for reporting that. It should be on the spins page in about 30 minutes or so. Excellent - thanks for the timely response! -- 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: Note on 'systemd-216-9'
On Tue, Nov 04, 2014 at 02:06:21PM -0800, Adam Williamson wrote: On Tue, 2014-11-04 at 22:39 +0100, Zbigniew Jędrzejewski-Szmek wrote: I understand that systemd git is not easy to follow, but I don't think this differes that much from other fast-changing projects. If you take a random kernel release, it's not like there's a nice lwn-style description somewhere. But there are actual releases. There's a kernel 3.17.1, and a kernel 3.17.2. They are artifacts with some sort of concrete presence, an announcement mail and a changelog (even though yes, it's just a git commit log). Lots of things you say I agree with. Yesterday after you complained that there the releases are not tagged in dist-git, I actually went ahead and added tags for all post-F20 releases (haven't pushed them yet). The subject of point releases hasn't come up before. Actually I haven't had *any* communication about the stable branches since they were created apart from a few patches backported by other systemd maintainers. If there are difficiencies, I need to hear about them. I love working on Fedora, and I'm happy to fix whatever I can. Systemd has 213 open bugs in Fedora, + another 49 marked as RFC. I pushed aggressively for an update in F21 to diminish this backlog a little. Some of those bugs have fixes upstream, but because of the large code reorganization that was done after systemd-208, lots of patches can't be really backported and would have to be rewritten to apply to the version of systemd that is in F20. This situation is something that I want to avoid as long as possible in F21, and that is why pre-release F21 updates were following upstream closely. I'm sorry about the timeout bug #1154768, it was my fault that it landed in an update. We (upstream) knew about the issue, but I don't think that anyone saw it as more than an annoyance, and that is why it slipped through. Like I wrote before, that update *was* supposed to go stable before the alpha freeze, and was supposed to go through all the testing sufficiently early. Yes, this makes sense when building from upstream git, where the date and the number correspond to something tangible. Here the list of patches is somewhat arbitrary: patches are backported if they are easy, or when they fix know problems. They often end up not in the same order as upstream, for example where a cleanup patch is much later cherry-picked to avoid diff conflicts in an actual patch that fixes something. So the upstream git hash (or date) would be very misleading. What I can do, and what should be useful, is to add tags to the stable branches where fedora releases are built from. I'm not sure if you're suggesting having tags on the *upstream* git repo that reflect *downstream* package builds, but that seems like more confusion between two separate processes to me - I'm suggesting more separation between the two, not more conflation. I update the stable branches when I work on a Fedora update. So I'll just tag the stable branch at the time when it is pulled into a Fedora update. The process will not change in any way from what happens currently, but there'll be a visible tag. 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
[Test-Announce] 2014-11-05 @ 1600 UTC ** F21 Blocker Review
# F21 Blocker Review meeting # Date: 2014-11-05 # Time: 16:00 UTC (11:00 EST, 08:00 PST) # Location: #fedora-blocker-review on irc.freenode.net The first TC of Final is upon us! Along with that, we've changed up the release schedule a bit so we need to get to finding and knocking out these blocker bugs for Final. Currently we have 15 proposed blockers and 3 proposed FEs to get through. If you want to take a look at the accepted blockers, the full list can be found here: https://qa.fedoraproject.org/blockerbugs/milestone/21/final/buglist We'll be evaluating these bugs to see if they violate the Final Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F21 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting See you Wednesday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org ___ 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
Schedule for Wednesday's FESCo Meeting (2014-11-05)
== Meeting time change == Note, this week the meeting time is changed from 1700UTC to 1800UTC now that both Europe and the US have changed DST. Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-11-05 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = New business = #topic #1362 Clarify feature process as it relates to FPC .fesco 1362 https://fedorahosted.org/fesco/ticket/1362 #topic #1365 A unique system-wide TMP directory for all programs and sane ways to retrieve the default .fesco 1365 https://fedorahosted.org/fesco/ticket/1365 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Porting initramfs-tools to dracut
Hi there, So I've been working on a project that requires me to have my own custom initrd. The doc I'm following is specialized for ubuntu, so it makes use of mkinitramfs to create initrd, and uses initramfs-tools/scripts and initramfs-tools/hooks for serving its purpose. I tried using dracut to create a ramdisk, but I cannot figure out how should I incorporate additional scripts and hooks into the same. I tried extending a dracut module (00bash) by adding *inst_hook cmdline 20 path to the script * but that doesn't seem to help. I'd really appreciate if someone could help me figure out a way. Either using dracut or somehow if its possible to use initramfs-tools on fedora.. :) Thanks, -- Saurabh R Kulkarni Graduate Student, ECE Carnegie Mellon University -- 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: Porting initramfs-tools to dracut
On Tue, Nov 4, 2014 at 5:35 PM, Saurabh Kulkarni srk...@gmail.com wrote: Hi there, So I've been working on a project that requires me to have my own custom initrd. The doc I'm following is specialized for ubuntu, so it makes use of mkinitramfs to create initrd, and uses initramfs-tools/scripts and initramfs-tools/hooks for serving its purpose. I tried using dracut to create a ramdisk, but I cannot figure out how should I incorporate additional scripts and hooks into the same. I tried extending a dracut module (00bash) by adding *inst_hook cmdline 20 path to the script * but that doesn't seem to help. How custom? What are you trying to do? Are you trying to boot in an environment that needs hardware-dependent drivers loaded or is the environment controlled enough that you don't need all that fanciness. I'm asking because this thing, while not currently intended for external use, can generate working initramfses very very quickly and with so little code that you can see what's going on in a minute or two: https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/tree/virtme/mkinitramfs.py --Andy -- 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: Note on 'systemd-216-9'
On Wed, 2014-11-05 at 01:06 +0100, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Nov 04, 2014 at 02:06:21PM -0800, Adam Williamson wrote: On Tue, 2014-11-04 at 22:39 +0100, Zbigniew Jędrzejewski-Szmek wrote: I understand that systemd git is not easy to follow, but I don't think this differes that much from other fast-changing projects. If you take a random kernel release, it's not like there's a nice lwn-style description somewhere. But there are actual releases. There's a kernel 3.17.1, and a kernel 3.17.2. They are artifacts with some sort of concrete presence, an announcement mail and a changelog (even though yes, it's just a git commit log). Lots of things you say I agree with. Yesterday after you complained that there the releases are not tagged in dist-git, I actually went ahead and added tags for all post-F20 releases (haven't pushed them yet). The subject of point releases hasn't come up before. Actually I haven't had *any* communication about the stable branches since they were created apart from a few patches backported by other systemd maintainers. If there are difficiencies, I need to hear about them. I love working on Fedora, and I'm happy to fix whatever I can. In the nature of things it tends to become most obvious around release times, because that's when it gets really painful when things break :) Systemd has 213 open bugs in Fedora, + another 49 marked as RFC. I pushed aggressively for an update in F21 to diminish this backlog a little. Some of those bugs have fixes upstream, but because of the large code reorganization that was done after systemd-208, lots of patches can't be really backported and would have to be rewritten to apply to the version of systemd that is in F20. This situation is something that I want to avoid as long as possible in F21, and that is why pre-release F21 updates were following upstream closely. I can see what you're trying to do there, and there's merit to it, but it's best if it's carefully handled. Obviously there's a limit to how much you can do as one person, I understand that. I'm sorry about the timeout bug #1154768, it was my fault that it landed in an update. We (upstream) knew about the issue, but I don't think that anyone saw it as more than an annoyance, and that is why it slipped through. Like I wrote before, that update *was* supposed to go stable before the alpha freeze, and was supposed to go through all the testing sufficiently early. 10-14 was the date of the *Beta* freeze, not the Alpha freeze. Alpha freeze was weeks ago, on 08-26; this change landed long after Alpha shipped. So what I'd suggest here is, at least in the conventional conception of a 'stable' branch, this is a change that should never have come close to one. It is clearly a feature addition, it's a substantial behaviour change, and it was not in response to any specific bug report (no, Lennart going 'hey, it's sure easy to push the power button on this laptop' doesn't really count as a bug report :) A stable branch is supposed to be, well, stable. It shouldn't suddenly start introducing significant behaviour changes. The typical mindset for maintaining a stable branch isn't 'let's pull everything that isn't obviously dangerous' but 'let's not pull anything unless we have a really good reason to believe it's a) needed and b) safe'. I certainly see the argument for pulling more changes downstream than would be pulled by following a traditional 'stable branch', but I'm not sure the system of having a branch that's called a stable branch but really isn't one which you suck straight into the downstream package without any kind of 'filtering' step is the best way to go about that. It might really be a good idea to talk to the kernel maintainers about their approach here, as over the years they've got to a point where they strike a very decent balance between getting too far behind upstream development and introducing de-stabilizing changes downstream at bad times. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Note on 'systemd-216-9'
On Tue, Nov 04, 2014 at 06:09:35PM -0800, Adam Williamson wrote: On Wed, 2014-11-05 at 01:06 +0100, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Nov 04, 2014 at 02:06:21PM -0800, Adam Williamson wrote: On Tue, 2014-11-04 at 22:39 +0100, Zbigniew Jędrzejewski-Szmek wrote: I understand that systemd git is not easy to follow, but I don't think this differes that much from other fast-changing projects. If you take a random kernel release, it's not like there's a nice lwn-style description somewhere. But there are actual releases. There's a kernel 3.17.1, and a kernel 3.17.2. They are artifacts with some sort of concrete presence, an announcement mail and a changelog (even though yes, it's just a git commit log). Lots of things you say I agree with. Yesterday after you complained that there the releases are not tagged in dist-git, I actually went ahead and added tags for all post-F20 releases (haven't pushed them yet). The subject of point releases hasn't come up before. Actually I haven't had *any* communication about the stable branches since they were created apart from a few patches backported by other systemd maintainers. If there are difficiencies, I need to hear about them. I love working on Fedora, and I'm happy to fix whatever I can. In the nature of things it tends to become most obvious around release times, because that's when it gets really painful when things break :) Systemd has 213 open bugs in Fedora, + another 49 marked as RFC. I pushed aggressively for an update in F21 to diminish this backlog a little. Some of those bugs have fixes upstream, but because of the large code reorganization that was done after systemd-208, lots of patches can't be really backported and would have to be rewritten to apply to the version of systemd that is in F20. This situation is something that I want to avoid as long as possible in F21, and that is why pre-release F21 updates were following upstream closely. I can see what you're trying to do there, and there's merit to it, but it's best if it's carefully handled. Obviously there's a limit to how much you can do as one person, I understand that. I'm sorry about the timeout bug #1154768, it was my fault that it landed in an update. We (upstream) knew about the issue, but I don't think that anyone saw it as more than an annoyance, and that is why it slipped through. Like I wrote before, that update *was* supposed to go stable before the alpha freeze, and was supposed to go through all the testing sufficiently early. 10-14 was the date of the *Beta* freeze, not the Alpha freeze. Alpha freeze was weeks ago, on 08-26; this change landed long after Alpha shipped. You're right, I was thinking about the beta freeze. The policy for updates says Pre Beta. This is the time between the Bodhi enabling point and the Beta release. During this time we are attempting to stabilize the major versions of software that will be shipped with the final release of the OS. Major updates can be tolerated, but breaking things for early testers should be avoided if possible. Additionally, as we get close to Alpha or Beta releases any change that breaks composes of Live media, install media or testing should be avoided. Packages for Changes should be landing and getting major testing. Avoid ABI/API changes where possible. Once again, I apologize for the timeout bug, had I know that it will interact badly with fedup, I certainly wouldn't have included it. Otherwise, I still feel the update was withing the confines of the policy. The patches that I pushed introduced some new features, but nothing which would count as an (intentional) major feature or significant change in the codebase, or ABI/API break. I used the versions in question on a few different machines, and I wasn't aware of any significant problems with them. Of course I didn't upgrade them using fedup, so I didn't hit the one bug that caused problem. If you look at the Fedora bugzilla, the F21 version has *less* bugs than either the F20 and F19 versions. So what I'd suggest here is, at least in the conventional conception of a 'stable' branch, this is a change that should never have come close to one. It is clearly a feature addition, it's a substantial behaviour change, and it was not in response to any specific bug report (no, Lennart going 'hey, it's sure easy to push the power button on this laptop' doesn't really count as a bug report :) It's not about Lennart. Afaik he usually sticks to git HEAD and/or rawhide. There are multiple reports about systemd entering an infinite loop and I *thought* that this is a step in the right direction. Systemd 217 was released with similar functionality, and while it is now clear that this approach doesn't really solve anything, the issues with it weren't clear at the time. The way I understood the impact was if your system hangs, it'll sync and poweroff at some point.
Re: LLVM 3.5 rebase
llvm-3.5 seems to break Haskell programs compiled with ghc on ARM badly. Perhaps I should just barge ahead with a compat-llvm34? Adam: this would be very welcome for ghc (ghc only needs llvm - not any clang bits). Otherwise currently we can't build any Haskell packages in Rawhide because compiled programs all fail to run on armv7hl with a runtime error: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? See for example http://koji.fedoraproject.org/koji/getfile?taskID=8036158name=build.logoffset=-4000 and http://koji.fedoraproject.org/koji/getfile?taskID=8037090name=build.logoffset=-4000 I just ran into this today and someone else reported the same to ghc upstream last week. Jens -- 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: Note on 'systemd-216-9'
On Wed, 2014-11-05 at 04:52 +0100, Zbigniew Jędrzejewski-Szmek wrote: I'm very appreciative of the kernel promise of stability. But systemd isn't at this stage yet, the codebase is much more in flux. Well, it's in flux, but it *is* the init system. It's kind of important. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Note on 'systemd-216-9'
On Wed, 2014-11-05 at 04:52 +0100, Zbigniew Jędrzejewski-Szmek wrote: It's not about Lennart. Afaik he usually sticks to git HEAD and/or rawhide. There are multiple reports about systemd entering an infinite loop and I *thought* that this is a step in the right direction. Well, looking at it practically as a user - if my system sticks in an infinite loop on boot, and the message is 'well, this new release doesn't make it boot properly, but it *will* time out and hard power off after 15 minutes' - that doesn't really make me jump for joy. Has it practically improved my situation? Not really. To give a really personal example, I'm one of the people suffering from https://bugzilla.redhat.com/show_bug.cgi?id=1123170 , I never have time to investigate it properly and provide details - sorry about that. But I guess the same way of thinking would say the timer is a 'step in the right direction' for me because my system will eventually give up and hard power off after 30 minutes - but does that really practically make me feel like I'm getting a better experience? Honestly, not really. If I'm actually sitting in front of the system I've usually lost patience and hard rebooted after, like, five minutes. If I'm not, all the 30 minute timeout did was save me five cents of electricity. The only case I could see where someone would really think 'hey, that made my life better' is Lennart's case of a laptop sitting in a case or a bag - but the thing is, the change only helps in that case *if you happen to be using encrypted storage*! If you aren't, the boot will complete without any user interaction needed, and the timeout will never kick in. So it really seems like a change which doesn't provide an awful lot of practical benefit. If boot or shutdown is failing so badly that a 15/30 minute timer would kick in, just adding a 15/30 minute timer doesn't honestly make things seem a whole lot 'better'. Fixing whatever bug is preventing the startup/shutdown from actually working is what would make the experience feel better. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: shutdown failure/delay (was: Note on 'systemd-216-9')
Adam Williamson composed on 2014-11-04 23:22 (UTC-0800): https://bugzilla.redhat.com/show_bug.cgi?id=1123170 , I never have time to investigate it properly and provide details - sorry about that. But I guess the same way of thinking would say the timer is a 'step in the right direction' for me because my system will eventually give up and hard power off after 30 minutes - but does that really practically make me feel like I'm getting a better experience? I've seen shutdown delays on various installations going back to when systemd was very young. Often they seem to stem from start processes that reported failure at init time, so at shutdown time, instead of stop jobs, I see *start* jobs stalling. One of the easier ways to cause a shutdown delay is to try to CAD right after making a boot menu selection and realizing I chose the wrong one. That typically will hang with message failed to store sound card state, and continually repeat for as long as CAD is held down. It doesn't happen on every installation, but it is common. Rather than trying to troubleshoot any of these hangs I invariably have more urgent things to do and reach for the reset button or power switch. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.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
[Bug 1068706] Password prompt matching requires colon, which may be missing
https://bugzilla.redhat.com/show_bug.cgi?id=1068706 Salvador Fandiño sfand...@yahoo.com changed: What|Removed |Added CC||sfand...@yahoo.com --- Comment #2 from Salvador Fandiño sfand...@yahoo.com --- Checking just for /[:?]/ is not something that ocurred to me alone, but the result of lots of feedback from users. Checking for /password|passphrase/ on the other hand is quite a bad idea as that would break authentication against systems where the locale is not English based. I don't think it is possible to come to some regular expression that would catch all the possibilities. That is the reason the door is open for unhandled cases as the one you are facing through the password_prompt option. In any case, at this point it is too late to change the regular expressions used for password prompt detection as that would break lots of existant scripts and that is unaceptable to me (I am upstream, btw :-) -- 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=0OMJeuUDdka=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 1147434] perl-Module-ScanDeps-1.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1147434 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppi...@redhat.com Assignee|st...@silug.org |ppi...@redhat.com -- 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=b5UOix9JdGa=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 1147434] perl-Module-ScanDeps-1.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1147434 --- Comment #2 from Petr Pisar ppi...@redhat.com --- This release breaks backward compatibility. -- 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=jP7K7JBljOa=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
[perl-Module-ScanDeps] 0.17 bump
commit c27d8573607bfdcbd4f1602ad189015e34e79348
Author: Petr Písař ppi...@redhat.com
Date: Tue Nov 4 13:05:02 2014 +0100
0.17 bump
perl-Module-ScanDeps.spec |7 +--
sources |2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/perl-Module-ScanDeps.spec b/perl-Module-ScanDeps.spec
index 49a1b13..33019b0 100644
--- a/perl-Module-ScanDeps.spec
+++ b/perl-Module-ScanDeps.spec
@@ -1,7 +1,7 @@
Name: perl-Module-ScanDeps
Summary:Recursively scan Perl code for dependencies
-Version:1.15
-Release:3%{?dist}
+Version:1.17
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/R/RS/RSCHUPP/Module-ScanDeps-%{version}.tar.gz
@@ -85,6 +85,9 @@ make test
%{_mandir}/man3/Module::ScanDeps.3pm*
%changelog
+* Tue Nov 04 2014 Petr Pisar ppi...@redhat.com - 1.17-1
+- 0.17 bump
+
* Mon Sep 08 2014 Jitka Plesnikova jples...@redhat.com - 1.15-3
- Perl 5.20 re-rebuild of bootstrapped packages
diff --git a/sources b/sources
index c7a0101..c889810 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6a397df339fa13bf844dd2bacc37db5b Module-ScanDeps-1.15.tar.gz
+d8c87c2ca6c94d699b856e999fa0d247 Module-ScanDeps-1.17.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
File Module-ScanDeps-1.17.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Module-ScanDeps: d8c87c2ca6c94d699b856e999fa0d247 Module-ScanDeps-1.17.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
File Test-Pod-Spelling-CommonMistakes-1.001.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Test-Pod-Spelling-CommonMistakes: 09705594778e5de6a84868208889e06e Test-Pod-Spelling-CommonMistakes-1.001.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-Test-Pod-Spelling-CommonMistakes] 1.001 bump
commit b71fceab4a9fda38185e048cf37406ed60f2e2a0
Author: Petr Písař ppi...@redhat.com
Date: Tue Nov 4 13:14:03 2014 +0100
1.001 bump
.gitignore |1 +
perl-Test-Pod-Spelling-CommonMistakes.spec | 26 --
sources|2 +-
3 files changed, 18 insertions(+), 11 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 2a230f5..a32af71 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Test-Pod-Spelling-CommonMistakes-1.000.tar.gz
+/Test-Pod-Spelling-CommonMistakes-1.001.tar.gz
diff --git a/perl-Test-Pod-Spelling-CommonMistakes.spec
b/perl-Test-Pod-Spelling-CommonMistakes.spec
index 39e8b34..e401ba0 100644
--- a/perl-Test-Pod-Spelling-CommonMistakes.spec
+++ b/perl-Test-Pod-Spelling-CommonMistakes.spec
@@ -1,25 +1,29 @@
Name: perl-Test-Pod-Spelling-CommonMistakes
-Version:1.000
-Release:8%{?dist}
+Version:1.001
+Release:1%{?dist}
Summary:Checks POD for common spelling mistakes
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Test-Pod-Spelling-CommonMistakes/
Source0:
http://www.cpan.org/authors/id/A/AP/APOCAL/Test-Pod-Spelling-CommonMistakes-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(Module::Build)
+BuildRequires: perl
+BuildRequires: perl(Module::Build::Tiny) = 0.039
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
# Run-time:
-BuildRequires: perl(base)
BuildRequires: perl(Exporter)
+BuildRequires: perl(parent)
BuildRequires: perl(Pod::Spell::CommonMistakes) = 0.01
BuildRequires: perl(Test::Builder) = 0.94
BuildRequires: perl(Test::Pod) = 1.40
# Tests:
+BuildRequires: perl(File::Spec)
BuildRequires: perl(File::Temp)
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(IPC::Open3)
BuildRequires: perl(Test::More) = 0.88
-# Optional tests:
-BuildRequires: perl(Test::Script) = 1.05
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
This module checks your POD for common spelling errors. This differs from
@@ -31,12 +35,11 @@ as any standard Test::* module, as seen here.
%setup -q -n Test-Pod-Spelling-CommonMistakes-%{version}
%build
-%{__perl} Build.PL installdirs=vendor
+perl Build.PL --installdirs=vendor
./Build
%install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+./Build install --destdir=$RPM_BUILD_ROOT --create_packlist=0
%{_fixperms} $RPM_BUILD_ROOT/*
%check
@@ -48,6 +51,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Tue Nov 04 2014 Petr Pisar ppi...@redhat.com - 1.001-1
+- 1.001 bump
+
* Mon Sep 01 2014 Jitka Plesnikova jples...@redhat.com - 1.000-8
- Perl 5.20 rebuild
diff --git a/sources b/sources
index a582590..782b38d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-aeda7256624c232958cae991488e4617 Test-Pod-Spelling-CommonMistakes-1.000.tar.gz
+09705594778e5de6a84868208889e06e Test-Pod-Spelling-CommonMistakes-1.001.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 1147434] perl-Module-ScanDeps-1.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1147434 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Module-ScanDeps-1.17-1 ||.fc22 Resolution|--- |RAWHIDE Last Closed||2014-11-04 07:18:16 -- 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=jSVf7LqUbIa=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 1159521] perl-Test-Pod-Spelling-CommonMistakes-1.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1159521 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Test-Pod-Spelling-Comm ||onMistakes-1.001-1.fc22 Resolution|--- |RAWHIDE Last Closed||2014-11-04 07:26:45 -- 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=q7WZf3RsaFa=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
Re: FESCo to orphan iarnell's packages
* Emmanuel Seyman [31/10/2014 18:02] : I'll be glad to give a hand, especially for all HTML/HTTP-related modules. Finally, I'll be requesting: - perl-App* - perl-Catalyst* - perl-CGI* - perl-Config* - perl-CSS* - perl-Email* - perl-FCGI* - perl-HTML* - perl-HTTP* - perl-JSON* - perl-Moo* - perl-Mouse* - perl-Plack* - perl-PSGI* - perl-Role* - perl-URI* - perl-WWW* - perl-XML* Emmanuel -- 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-POE-Component-Client-DNS] Disable live network tests by default
commit abb95cfc6d3a64ded4e9d8ce4c5364056a1e4d07
Author: Petr Šabata con...@redhat.com
Date: Tue Nov 4 13:35:54 2014 +0100
Disable live network tests by default
perl-POE-Component-Client-DNS.spec |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
---
diff --git a/perl-POE-Component-Client-DNS.spec
b/perl-POE-Component-Client-DNS.spec
index 03ac55c..601747d 100644
--- a/perl-POE-Component-Client-DNS.spec
+++ b/perl-POE-Component-Client-DNS.spec
@@ -12,7 +12,9 @@ BuildRequires: perl(Carp)
BuildRequires: perl(constant)
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(ExtUtils::MakeMaker)
+%{?_with_network_tests:
BuildRequires: perl(lib)
+}
BuildRequires: perl(Net::DNS) = 0.65
BuildRequires: perl(POE) = 1.294
BuildRequires: perl(Scalar::Util)
@@ -47,6 +49,7 @@ find %{buildroot} -type f -name .packlist -exec rm -f {} +
cp t/01_resolve.t example_resolve
%check
+%{?!_with_network_tests: rm t/01_resolve.t }
make test
%files
--
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 Test-Pod-LinkCheck-0.008.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Test-Pod-LinkCheck: 38c01d0f7c7b88a452a3a98f4f72857f Test-Pod-LinkCheck-0.008.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-Test-Pod-LinkCheck] 0.008 bump
commit 2d80556da66871660c574eae998b1b75272dff1b
Author: Petr Písař ppi...@redhat.com
Date: Tue Nov 4 13:40:57 2014 +0100
0.008 bump
.gitignore |1 +
perl-Test-Pod-LinkCheck.spec | 25 +
sources |2 +-
3 files changed, 15 insertions(+), 13 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8c13cc7..86949de 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Test-Pod-LinkCheck-0.007.tar.gz
+/Test-Pod-LinkCheck-0.008.tar.gz
diff --git a/perl-Test-Pod-LinkCheck.spec b/perl-Test-Pod-LinkCheck.spec
index 9c43a28..cdd1db6 100644
--- a/perl-Test-Pod-LinkCheck.spec
+++ b/perl-Test-Pod-LinkCheck.spec
@@ -1,6 +1,6 @@
Name: perl-Test-Pod-LinkCheck
-Version:0.007
-Release:11%{?dist}
+Version:0.008
+Release:1%{?dist}
Summary:Tests POD for invalid links
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,7 +8,8 @@ URL:http://search.cpan.org/dist/Test-Pod-LinkCheck/
Source0:
http://www.cpan.org/authors/id/A/AP/APOCAL/Test-Pod-LinkCheck-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl
-BuildRequires: perl(Module::Build)
+# ExtUtils::MakeMaker not used
+BuildRequires: perl(Module::Build::Tiny) = 0.039
BuildRequires: perl(strict)
BuildRequires: perl(warnings)
# Run-time:
@@ -25,19 +26,17 @@ BuildRequires: perl(Pod::Find)
BuildRequires: perl(Test::Builder) = 0.94
BuildRequires: perl(Test::Pod) = 1.44
# Tests:
-BuildRequires: perl(File::Find)
BuildRequires: perl(File::Temp)
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(IPC::Open3)
BuildRequires: perl(Test::More) = 0.88
BuildRequires: perl(Test::Tester)
# Optional tests:
%if %{undefined perl_bootstrap}
# Break build-time cycle with perl-Test-Apocalypse
BuildRequires: perl(Test::Apocalypse) = 1.000
-BuildRequires: perl(Test::NoWarnings)
-BuildRequires: perl(Test::Pod::Coverage)
%endif
-BuildRequires: perl(Test::Script) = 1.05
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(App::PodLinkCheck::ParseSections)
Requires: perl(Capture::Tiny)
Requires: perl(Config)
@@ -55,23 +54,25 @@ example. Also, manual pages are resolved and checked.
%setup -q -n Test-Pod-LinkCheck-%{version}
%build
-%{__perl} Build.PL installdirs=vendor
+perl Build.PL --installdirs=vendor
./Build
%install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+./Build install --destdir=$RPM_BUILD_ROOT --create_packlist=0
%{_fixperms} $RPM_BUILD_ROOT/*
%check
./Build test
%files
-%doc Changes CommitLog examples LICENSE README
+%doc AUTHOR_PLEDGE Changes CommitLog examples LICENSE README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Tue Nov 04 2014 Petr Pisar ppi...@redhat.com - 0.008-1
+- 0.008 bump
+
* Sun Sep 07 2014 Jitka Plesnikova jples...@redhat.com - 0.007-11
- Perl 5.20 re-rebuild of bootstrapped packages
diff --git a/sources b/sources
index b903b57..4b3466c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-27944d9dbaa3ad3e8f62a6344ac03f44 Test-Pod-LinkCheck-0.007.tar.gz
+38c01d0f7c7b88a452a3a98f4f72857f Test-Pod-LinkCheck-0.008.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 1159634] perl-Test-Pod-LinkCheck-0.008 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1159634 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Test-Pod-LinkCheck-0.0 ||08-1.fc22 Resolution|--- |RAWHIDE Last Closed||2014-11-04 07:59:08 -- 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=seTZU6SsHOa=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 Test-Pod-No404s-0.02.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Test-Pod-No404s: 3d62652f4a9310856d286b181be8153e Test-Pod-No404s-0.02.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 1160263] New: $Test::Pod::No404s::VERSION = '0.02' provides version 404
https://bugzilla.redhat.com/show_bug.cgi?id=1160263 Bug ID: 1160263 Summary: $Test::Pod::No404s::VERSION = '0.02' provides version 404 Product: Fedora Version: rawhide Component: perl-generators Assignee: jples...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com perl-Test-Pod-No404s-0.02-1.fc22 delivers No404s.pm starting with: package Test::Pod::No404s; $Test::Pod::No404s::VERSION = '0.02'; This code is translated into this Provides: perl(Test::Pod::No404s) = 404 Probably the first non-numeric substring in the variable name becomes the provided version. Expected value is 0.02. Broken in perl-generators-1.00-2.fc22. -- 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=aEqcviLMNRa=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
[perl-Test-Pod-No404s] 0.02 bump
commit e079e7c20e413b6333293fdb933adcda51a39be1
Author: Petr Písař ppi...@redhat.com
Date: Tue Nov 4 14:32:42 2014 +0100
0.02 bump
.gitignore|1 +
perl-Test-Pod-No404s.spec | 60 +++-
sources |2 +-
3 files changed, 33 insertions(+), 30 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8493a05..0345ebf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Test-Pod-No404s-0.01.tar.gz
+/Test-Pod-No404s-0.02.tar.gz
diff --git a/perl-Test-Pod-No404s.spec b/perl-Test-Pod-No404s.spec
index 9975617..9153565 100644
--- a/perl-Test-Pod-No404s.spec
+++ b/perl-Test-Pod-No404s.spec
@@ -1,42 +1,42 @@
-# Remove once apocalypse gets into build root. But keep the BuildRequires
-# conditional blocks to utlize apocalypse during futher package life.
-%define perl_bootstrap 1
-
Name: perl-Test-Pod-No404s
-Version:0.01
-Release:11%{?dist}
+Version:0.02
+Release:1%{?dist}
Summary:Checks POD for HTTP 404 links
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Test-Pod-No404s/
Source0:
http://www.cpan.org/authors/id/A/AP/APOCAL/Test-Pod-No404s-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(Module::Build)
+BuildRequires: perl
+# ExtUtils::MakeMaker not needed
+BuildRequires: perl(Module::Build::Tiny) = 0.039
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
# Run-Time:
-BuildRequires: perl(LWP::UserAgent) = 5.834
-BuildRequires: perl(Pod::Simple::Text) = 3.13
-BuildRequires: perl(Test::Builder) = 0.94
-BuildRequires: perl(Test::Pod) = 1.40
-BuildRequires: perl(URI::Find) = 20090319
+BuildRequires: perl(Exporter)
+BuildRequires: perl(LWP::UserAgent)
+BuildRequires: perl(parent)
+BuildRequires: perl(Pod::Simple::Text)
+BuildRequires: perl(Test::Builder)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(URI::Find)
# Tests:
-BuildRequires: perl(Test::More)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(IPC::Open3)
+BuildRequires: perl(Test::More) = 0.88
# Optional tests:
-BuildRequires: perl(Test::NoWarnings)
# Break build-time cycle with perl-Test-Apocalypse
%if %{undefined perl_bootstrap}
-BuildRequires: perl(Test::Apocalypse)
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(Test::Apocalypse) = 1.000
%endif
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-Requires: perl(LWP::UserAgent) = 5.834
-Requires: perl(Pod::Simple::Text) = 3.13
-Requires: perl(Test::Builder) = 0.94
-Requires: perl(Test::Pod) = 1.40
-Requires: perl(URI::Find) = 20090319
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+# Inject correct provide, bug #1160263
+Provides: perl(Test::Pod::No404s) = %{version}
-# Remove under-specified dependencies
-%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\((LWP::UserAgent|Pod::Simple::Text|Test::Builder|Test::Pod|URI::Find)\\)$
+# Filter bogus provide, bug #1160263
+%global __provides_exclude
%{?__provides_exclude:%__provides_exclude|}^perl\\(Test::Pod::No404s\\) = 404$
%description
This module looks for any HTTP(S) links in your POD and verifies that they
@@ -48,23 +48,25 @@ it uses $response-is_error as the test.
%setup -q -n Test-Pod-No404s-%{version}
%build
-%{__perl} Build.PL installdirs=vendor
+perl Build.PL --installdirs=vendor
./Build
%install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+./Build install --destdir=$RPM_BUILD_ROOT --create_packlist=0
%{_fixperms} $RPM_BUILD_ROOT/*
%check
./Build test
%files
-%doc Changes examples LICENSE README
+%doc AUTHOR_PLEDGE Changes CommitLog examples LICENSE README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Tue Nov 04 2014 Petr Pisar ppi...@redhat.com - 0.02-1
+- 0.02 bump
+
* Sun Sep 07 2014 Jitka Plesnikova jples...@redhat.com - 0.01-11
- Perl 5.20 re-rebuild of bootstrapped packages
diff --git a/sources b/sources
index 49d4a1b..c77d957 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-828d11730b2a133d3150d0eb83674424 Test-Pod-No404s-0.01.tar.gz
+3d62652f4a9310856d286b181be8153e Test-Pod-No404s-0.02.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 1160275] New: perl-Capture-Tiny-0.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1160275 Bug ID: 1160275 Summary: perl-Capture-Tiny-0.26 is available Product: Fedora Version: rawhide Component: perl-Capture-Tiny 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.26 Current version/release in Fedora Rawhide: 0.25-3.fc22 URL: http://search.cpan.org/dist/Capture-Tiny/ 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 Soon this service will be implemented by a new system: https://github.com/fedora-infra/anitya/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=n1hCNNVulVa=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 1160282] New: perl-PAR-Packer-1.023 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1160282 Bug ID: 1160282 Summary: perl-PAR-Packer-1.023 is available Product: Fedora Version: rawhide Component: perl-PAR-Packer 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: 1.023 Current version/release in Fedora Rawhide: 1.022-1.fc22 URL: http://search.cpan.org/dist/PAR-Packer/ 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 Soon this service will be implemented by a new system: https://github.com/fedora-infra/anitya/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=CA6Wz8rktha=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 1160283] New: perl-POE-1.366 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1160283 Bug ID: 1160283 Summary: perl-POE-1.366 is available Product: Fedora Version: rawhide Component: perl-POE Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 1.366 Current version/release in Fedora Rawhide: 1.365-1.fc22 URL: http://search.cpan.org/dist/POE/ 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 Soon this service will be implemented by a new system: https://github.com/fedora-infra/anitya/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=8QE0ns7K9sa=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 1160284] New: perl-POE-Test-Loops-1.360 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1160284 Bug ID: 1160284 Summary: perl-POE-Test-Loops-1.360 is available Product: Fedora Version: rawhide Component: perl-POE-Test-Loops Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 1.360 Current version/release in Fedora Rawhide: 1.359-1.fc22 URL: http://search.cpan.org/dist/POE-Test-Loops/ 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 Soon this service will be implemented by a new system: https://github.com/fedora-infra/anitya/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=pbycB6yxEHa=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 1159635] perl-Test-Pod-No404s-0.02 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1159635 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Test-Pod-No404s-0.02-1 ||.fc22 Resolution|--- |RAWHIDE Last Closed||2014-11-04 09:01:29 -- 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=zuzf10cRPpa=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 Capture-Tiny-0.26.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Capture-Tiny: bff4602137a8c59dae2808dbcda5135b Capture-Tiny-0.26.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-Capture-Tiny] 0.26 bump
commit e8ec77f09f4b29fb466be5596007bfb5c57795a9
Author: Petr Šabata con...@redhat.com
Date: Tue Nov 4 15:09:18 2014 +0100
0.26 bump
- Test suite enhancements only
.gitignore |1 +
perl-Capture-Tiny.spec |8 ++--
sources|2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7e26c35..9f72be4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,4 @@ Capture-Tiny-0.08.tar.gz
/Capture-Tiny-0.23.tar.gz
/Capture-Tiny-0.24.tar.gz
/Capture-Tiny-0.25.tar.gz
+/Capture-Tiny-0.26.tar.gz
diff --git a/perl-Capture-Tiny.spec b/perl-Capture-Tiny.spec
index c1b3320..3fd9f95 100644
--- a/perl-Capture-Tiny.spec
+++ b/perl-Capture-Tiny.spec
@@ -1,6 +1,6 @@
Name: perl-Capture-Tiny
-Version:0.25
-Release:3%{?dist}
+Version:0.26
+Release:1%{?dist}
Summary:Capture STDOUT and STDERR from Perl, XS or external programs
License:ASL 2.0
Group: Development/Libraries
@@ -65,6 +65,10 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Nov 04 2014 Petr Šabata con...@redhat.com - 0.26-1
+- 0.26 bump
+- Test suite enhancements only
+
* Sun Sep 07 2014 Jitka Plesnikova jples...@redhat.com - 0.25-3
- Perl 5.20 re-rebuild of bootstrapped packages
diff --git a/sources b/sources
index ddf97b2..ae73fc7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8cbf69b1ceb10899308ac1f57a28c8a8 Capture-Tiny-0.25.tar.gz
+bff4602137a8c59dae2808dbcda5135b Capture-Tiny-0.26.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 1160275] perl-Capture-Tiny-0.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1160275 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Capture-Tiny-0.26-1.fc ||22 Resolution|--- |RAWHIDE Last Closed||2014-11-04 09:11:21 -- 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=Os4wXzGdb2a=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 PAR-Packer-1.023.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-PAR-Packer: 68bd295aa2454c32817d8d7d3588fbf4 PAR-Packer-1.023.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-PAR-Packer] 1.023 bump
commit 6d0973a15c2cc488d3b5d2705e7a958c0c4a7a75
Author: Petr Šabata con...@redhat.com
Date: Tue Nov 4 15:34:14 2014 +0100
1.023 bump
.gitignore |1 +
perl-PAR-Packer.spec | 11 +++
sources |2 +-
3 files changed, 9 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 71e8f0b..ba7a88a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,3 +13,4 @@ PAR-Packer-1.005.tar.gz
/PAR-Packer-1.018.tar.gz
/PAR-Packer-1.019.tar.gz
/PAR-Packer-1.022.tar.gz
+/PAR-Packer-1.023.tar.gz
diff --git a/perl-PAR-Packer.spec b/perl-PAR-Packer.spec
index fd13977..b948dc1 100644
--- a/perl-PAR-Packer.spec
+++ b/perl-PAR-Packer.spec
@@ -1,5 +1,5 @@
Name: perl-PAR-Packer
-Version:1.022
+Version:1.023
Release:1%{?dist}
Summary:PAR Packager
License:GPL+ or Artistic
@@ -35,7 +35,7 @@ BuildRequires: perl(File::Find)
BuildRequires: perl(File::Spec)
BuildRequires: perl(File::Temp) = 0.05
BuildRequires: perl(Getopt::ArgvFile) = 1.07
-BuildRequires: perl(Module::ScanDeps) = 1.15
+BuildRequires: perl(Module::ScanDeps) = 1.17
BuildRequires: perl(PAR) = 1.005
BuildRequires: perl(PAR::Dist) = 0.22
BuildRequires: perl(vars)
@@ -50,7 +50,7 @@ Requires: perl(Compress::Zlib) = 1.3
Requires: perl(File::Temp) = 0.05
Requires: perl(Getopt::ArgvFile) = 1.07
Requires: perl(IO::Compress::Gzip)
-Requires: perl(Module::ScanDeps) = 1.15
+Requires: perl(Module::ScanDeps) = 1.17
Requires: perl(PAR) = 1.005
Requires: perl(PAR::Dist) = 0.22
@@ -119,7 +119,7 @@ fi
/usr/bin/gtk-update-icon-cache %{_datadir}/icons/hicolor /dev/null || :
%files
-%doc AUTHORS ChangeLog README TODO
+%doc AUTHORS Changes README TODO
%{perl_vendorlib}/*
%{_bindir}/par.pl
%{_bindir}/parl
@@ -136,6 +136,9 @@ fi
%{_datadir}/icons/hicolor/32x32/apps/tkpp.gif
%changelog
+* Tue Nov 04 2014 Petr Šabata con...@redhat.com - 1.023-1
+- 1.023 bump
+
* Mon Sep 29 2014 Petr Šabata con...@redhat.com - 1.022-1
- 1.022 bump
diff --git a/sources b/sources
index 3f0151b..2d9a6e6 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-69155f6ea29e3d4a60dd377b14537947 PAR-Packer-1.022.tar.gz
+68bd295aa2454c32817d8d7d3588fbf4 PAR-Packer-1.023.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
File Sereal-Encoder-3.003.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Sereal-Encoder: 544c4f7222a22aa1c42fcf366eacb382 Sereal-Encoder-3.003.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 1160282] perl-PAR-Packer-1.023 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1160282 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-PAR-Packer-1.023-1.fc2 ||2 Resolution|--- |RAWHIDE Last Closed||2014-11-04 09:53:37 -- 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=clFeXQlzXFa=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
[perl-Sereal-Encoder] 3.003 bump
commit ed42db25b930bc4aa29ab637d3a7d27d88d7c0d9
Author: Petr Písař ppi...@redhat.com
Date: Tue Nov 4 15:51:27 2014 +0100
3.003 bump
.gitignore |1 +
...xternal-csnappy-library-in-Sereal-Encoder.patch | 93
...-external-miniz-library-in-Sereal-Encoder.patch | 81 -
perl-Sereal-Encoder.spec | 11 +--
sources|2 +-
5 files changed, 6 insertions(+), 182 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index b678aa8..3a9c025 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Sereal-Encoder-3.002.tar.gz
+/Sereal-Encoder-3.003.tar.gz
diff --git a/perl-Sereal-Encoder.spec b/perl-Sereal-Encoder.spec
index fd6a014..aa92d81 100644
--- a/perl-Sereal-Encoder.spec
+++ b/perl-Sereal-Encoder.spec
@@ -2,7 +2,7 @@
%global perl_bootstrap 1
Name: perl-Sereal-Encoder
-Version:3.002
+Version:3.003
Release:1%{?dist}
Summary:Perl serialization into Serial format
# lib/Sereal/Encoder.pm:GPL+ or Artistic
@@ -13,10 +13,6 @@ License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Sereal-Encoder/
Source0:
http://www.cpan.org/authors/id/Y/YV/YVES/Sereal-Encoder-%{version}.tar.gz
-# Use external csnappy library, https://github.com/Sereal/Sereal/issues/72
-Patch0:
Sereal-3.002_001-Prefer-external-csnappy-library-in-Sereal-Encoder.patch
-# Use external miniz library, https://github.com/Sereal/Sereal/issues/72
-Patch1:
Sereal-3.002_001-Prefer-external-miniz-library-in-Sereal-Encoder.patch
BuildRequires: csnappy-devel
BuildRequires: miniz-devel
BuildRequires: perl
@@ -66,8 +62,6 @@ serializer using a binary protocol called Sereal.
%prep
%setup -q -n Sereal-Encoder-%{version}
-%patch0 -p3
-%patch1 -p3
# Remove bundled Perl modules
rm -r ./inc/Devel
sed -i -s '/^inc\/Devel/d' MANIFEST
@@ -98,5 +92,8 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Nov 04 2014 Petr Pisar ppi...@redhat.com - 3.003-1
+- 3.003 bump
+
* Fri Oct 10 2014 Petr Pisar ppi...@redhat.com 3.002-1
- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index bcfdad0..1bbb120 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-18e88a20ae5842f98e2874557d8d525c Sereal-Encoder-3.002.tar.gz
+544c4f7222a22aa1c42fcf366eacb382 Sereal-Encoder-3.003.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-Sereal-Encoder] Teach rpmlint
commit ab9a5adfe3524651f658e81ae0df2d0536dd5581 Author: Petr Písař ppi...@redhat.com Date: Tue Nov 4 15:53:43 2014 +0100 Teach rpmlint .rpmlint |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) --- diff --git a/.rpmlint b/.rpmlint new file mode 100644 index 000..8d02e3e --- /dev/null +++ b/.rpmlint @@ -0,0 +1,2 @@ +from Config import * +addFilter(spelling-error .* serializer); -- 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 1159519] perl-Sereal-Encoder-3.003 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1159519 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Sereal-Encoder-3.003-1 ||.fc22 Resolution|--- |RAWHIDE Last Closed||2014-11-04 10:05:07 -- 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=3CzEhxr7Oza=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 POE-Test-Loops-1.360.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-POE-Test-Loops: 7ee1aca3b18189d709cf89a7883d8f95 POE-Test-Loops-1.360.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-POE-Test-Loops] 1.360 bump
commit b0a4bab529e5d8bb0f73ef8678949cd348122caa
Author: Petr Šabata con...@redhat.com
Date: Tue Nov 4 16:09:03 2014 +0100
1.360 bump
.gitignore |1 +
perl-POE-Test-Loops.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index b8900bb..66b7995 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,3 +7,4 @@ POE-Test-Loops-1.035.tar.gz
/POE-Test-Loops-1.354.tar.gz
/POE-Test-Loops-1.358.tar.gz
/POE-Test-Loops-1.359.tar.gz
+/POE-Test-Loops-1.360.tar.gz
diff --git a/perl-POE-Test-Loops.spec b/perl-POE-Test-Loops.spec
index cf93cb0..598ea5e 100644
--- a/perl-POE-Test-Loops.spec
+++ b/perl-POE-Test-Loops.spec
@@ -1,6 +1,6 @@
Name: perl-POE-Test-Loops
Summary:Reusable tests for POE::Loop authors
-Version:1.359
+Version:1.360
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -100,6 +100,9 @@ make test
%{_mandir}/man1/poe-gen-tests.1.gz
%changelog
+* Tue Nov 04 2014 Petr Šabata con...@redhat.com - 1.360-1
+- 1.360 bump
+
* Wed Oct 08 2014 Petr Šabata con...@redhat.com - 1.359-1
- 1.359 bump
diff --git a/sources b/sources
index e978085..befcd75 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d320dbd7d9b424f9a5150cb14cfa5783 POE-Test-Loops-1.359.tar.gz
+7ee1aca3b18189d709cf89a7883d8f95 POE-Test-Loops-1.360.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 1160284] perl-POE-Test-Loops-1.360 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1160284 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-POE-Test-Loops-1.360-1 ||.fc22 Resolution|--- |RAWHIDE Last Closed||2014-11-04 10:18:02 -- 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=ljy7Tl9xHoa=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 1160284] perl-POE-Test-Loops-1.360 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1160284 Petr Šabata psab...@redhat.com changed: What|Removed |Added Blocks||1160283 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1160283 [Bug 1160283] perl-POE-1.366 is available -- 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=jz0YaLKvbsa=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 1160283] perl-POE-1.366 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1160283 Petr Šabata psab...@redhat.com changed: What|Removed |Added Depends On||1160284 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1160284 [Bug 1160284] perl-POE-Test-Loops-1.360 is available -- 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=m0KObrN6HWa=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 POE-1.366.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-POE: 0cbbc3fadf5787cd91a5005128fd39f0 POE-1.366.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-POE] 1.366 bump
commit d85e6f40721361546fd03ffc33b49f2035525205
Author: Petr Šabata con...@redhat.com
Date: Tue Nov 4 17:06:48 2014 +0100
1.366 bump
.gitignore|1 +
perl-POE.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 62bdf39..9b50654 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@ POE-1.289.tar.gz
/POE-1.358.tar.gz
/POE-1.364.tar.gz
/POE-1.365.tar.gz
+/POE-1.366.tar.gz
diff --git a/perl-POE.spec b/perl-POE.spec
index 9986623..9f5f585 100644
--- a/perl-POE.spec
+++ b/perl-POE.spec
@@ -1,5 +1,5 @@
Name: perl-POE
-Version: 1.365
+Version: 1.366
Release: 1%{?dist}
Summary: POE - portable multitasking and networking framework for Perl
@@ -65,7 +65,7 @@ BuildRequires: perl(Time::HiRes) = 1.59
# POE::Test::Loops unsurprisingly requires POE
# ...and it's not in EPEL at the moment
%if 0%{!?perl_bootstrap:1} ! ( 0%{?rhel} )
-BuildRequires: perl(POE::Test::Loops) = 1.359
+BuildRequires: perl(POE::Test::Loops) = 1.360
%endif
Requires: perl(Compress::Zlib) = 1.33
@@ -143,6 +143,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Tue Nov 04 2014 Petr Šabata con...@redhat.com - 1.366-1
+- 1.366 bump
+
* Tue Oct 14 2014 Petr Šabata con...@redhat.com - 1.365-1
- 1.365 bump
diff --git a/sources b/sources
index 800abc3..04b2d70 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e5e56e2b458322ac89d3d96b777ea497 POE-1.365.tar.gz
+0cbbc3fadf5787cd91a5005128fd39f0 POE-1.366.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 1160283] perl-POE-1.366 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1160283 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-POE-1.366-1.fc22 Resolution|--- |RAWHIDE Last Closed||2014-11-04 11:12:21 -- 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=qv05QeBBFIa=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 namespace-autoclean-0.22.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-namespace-autoclean: df5230afe646dcdb83261d1d6f6fb4f7 namespace-autoclean-0.22.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-namespace-autoclean] Update to 0.22
commit 035c2dea58143a1a5d0db72d6a1c61e2cfea9075
Author: Paul Howarth p...@city-fan.org
Date: Tue Nov 4 18:33:11 2014 +
Update to 0.22
- New upstream release 0.22
- Drop testing of MooseX::MarkAsMethods, now that Moose 2.1400 has better
overload handling
perl-namespace-autoclean.spec | 11 +++
sources |2 +-
2 files changed, 8 insertions(+), 5 deletions(-)
---
diff --git a/perl-namespace-autoclean.spec b/perl-namespace-autoclean.spec
index 9d48d9d..415b5a4 100644
--- a/perl-namespace-autoclean.spec
+++ b/perl-namespace-autoclean.spec
@@ -1,5 +1,5 @@
Name: perl-namespace-autoclean
-Version:0.20
+Version:0.22
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -38,12 +38,10 @@ BuildRequires: perl(Moo) = 1.07
BuildRequires: perl(Moose) = 0.56
BuildRequires: perl(Moose::Role)
%if ! %{defined perl_bootstrap}
-%if 0%{?fedora} || 0%{?rhel} 7
-BuildRequires: perl(MooseX::MarkAsMethods)
-%endif
BuildRequires: perl(MooseX::Role::WithOverloading) = 0.09
%endif
BuildRequires: perl(Mouse)
+BuildRequires: perl(Sub::Install)
BuildRequires: perl(Sub::Name)
# Runtime
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
@@ -81,6 +79,11 @@ perl Build.PL --installdirs=vendor
%{_mandir}/man3/namespace::autoclean.3pm*
%changelog
+* Tue Nov 4 2014 Paul Howarth p...@city-fan.org - 0.22-1
+- Update to 0.22
+ - Drop testing of MooseX::MarkAsMethods, now that Moose 2.1400 has better
+overload handling
+
* Tue Sep 23 2014 Paul Howarth p...@city-fan.org - 0.20-1
- Update to 0.20
- Moose earlier than 2.0300 had a broken -does method, which called methods
diff --git a/sources b/sources
index 8306ca6..5d33c52 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d135cec631465e25316537828fcf0fba namespace-autoclean-0.20.tar.gz
+df5230afe646dcdb83261d1d6f6fb4f7 namespace-autoclean-0.22.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-namespace-autoclean] Created tag perl-namespace-autoclean-0.22-1.fc22
The lightweight tag 'perl-namespace-autoclean-0.22-1.fc22' was created pointing to: 035c2de... Update to 0.22 -- 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 Test-Simple-1.001009.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-Simple: 45b8942055352fc20543d24b6f5b9a59 Test-Simple-1.001009.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
