Re: /usrmove?
On Thu, 2012-02-09 at 04:24 +, Matthew Garrett wrote: > On Thu, Feb 09, 2012 at 02:14:53AM +0100, Kevin Kofler wrote: > > > IMHO, FESCo needs to accept that sometimes they make a mistake (especially > > if the vote was disputed to begin with) and revote. UsrMove should have > > been > > unapproved, not only for F17, but forever. > > So, just to be clear, you're saying that even if usrmove had landed in > an entirely perfect and complete form the day after F16 branched, it > should still have been rejected? You're talking about completely theoretical situation nobody is arguing on. It is theoretical because there is still not _perfect and complete form_ of the UsrMove feature. Yes, most of the objections to it were eventually fixed/workarounded/rebutted but I'm sure not all of them. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gsoap updated in F17 and rawhide
Hi! gsoap was updated to version 2.8.7 in F17 and rawhide. Due to changes to the struct soap the soname of the libraries was bumped from 1 to 2. Dependent packages needs to rebuild: lcgdm lcgdm-dav srm-ifce voms Mattias smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Thu, Feb 09, 2012 at 01:49:13AM +0100, Reindl Harald wrote: > > > Am 09.02.2012 01:44, schrieb Reindl Harald: > >> This is how software development works. > > > > the with every release worser overall-quality shows > > clearly that software development does NOT work this > > way over the long > > > > seeing how dramatically the release quality of many > > opensource software gets lower and lower the last > > years this is the wrong direction > > > > there were times where opensource software was very careful > > with 1.0 releases and "we are done" until it really worked > > because the developers liked to release really good software > > > > these days more and more developers have only the target > > to release with "hopefully good enough" state, if "good enough" > > is the target finally nothing will be really good > > > > the target should ALWAYS be perfect and finally it can be > > considered what is not really needed and were a compromise > > can be made - if you starting with "hopefully good enough" > > you will end in poor quality at all > > to say it in other words: > > the overall release-quality of fedora was MUCH better as long > Redhat controlled it and before everybody could propose hughe > changes in all sorts of subsystems as long he finds some > peopole agree and not enough disagreing loud enough > > hopefully if /usrmove is done and the systemd-transition is > really finished fedora will come back to the quality of > the days where i started to love this distribution Note that both /usrmove and systemd have been initiated and pushed forward by Red Hat people... D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Thu, Feb 09, 2012 at 02:14:53AM +0100, Kevin Kofler wrote: > IMHO, FESCo needs to accept that sometimes they make a mistake (especially > if the vote was disputed to begin with) and revote. UsrMove should have been > unapproved, not only for F17, but forever. So, just to be clear, you're saying that even if usrmove had landed in an entirely perfect and complete form the day after F16 branched, it should still have been rejected? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-17
tdom is picked up by me for Fedora (not EPEL). For EPEL tdom is orphant but not in drop list *still*. > Can I pick up tdom? > > > Takanori > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-17
On Thu, Feb 09, 2012 at 12:19:53 +0900, Takanori MATSUURA wrote: > Can I pick up tdom? Once packages have been blocked the procedure is to require a review similar to getting a new package into Fedora. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gfortran module versioning - f17/rawhide fortran module rebuild needed
It appears that gcc-gfortran-4.7.0-0.11.fc17.x86_64 (in rawhide) and gcc-gfortran-4.7.0-0.12.fc17.x86_64 (in f17 - branching fun!) produces and uses Fortran modules version 9 as I'm getting this trying to rebuild netcdf: use mpi 1 Fatal Error: Wrong module version '8' (expected '9') for file 'mpi.mod' opened at (1) openmpi was built with 4.7.0-0.8.fc17 on Jan 20th, so at some point between the two the module version was bumped. It's somewhat surprising that the version number needed to get bumped during the 4.7.0 pre-release series, though appreciated if it was necessary to fix the fortran regression I came across via plplot. :) Would it be possible for rpm to track this dependency for us somehow so we could get notified of abi breakage automatically? It's hard at the moment to know what packages have Fortran modules and need to be rebuilt (assuming the version number bump was intentional). gcc-gfortran could provide "gfortran(abi) = 8" and rpm could parse .mod files for their header: GFORTRAN module version '6' and put in a requires "gfortran(abi) = 6". Likely rebuild candidates: # repoquery --whatprovides /usr/\*.mod | grep devel | sort getdata-devel-0:0.7.3-1.fc16.i686 hdf5-devel-0:1.8.7-1.fc16.i686 hdf5-devel-0:1.8.7-3.fc16.i686 hdf5-mpich2-devel-0:1.8.7-1.fc16.i686 hdf5-mpich2-devel-0:1.8.7-3.fc16.i686 hdf5-openmpi-devel-0:1.8.7-1.fc16.i686 hdf5-openmpi-devel-0:1.8.7-3.fc16.i686 healpix-devel-0:2.13a-2.fc14.i386 kdelibs3-devel-0:3.5.10-31.fc16.i686 libxc-devel-0:1.1.0-1.fc16.i686 matio-devel-0:1.3.4-2.fc15.i686 mpich2-devel-0:1.4.1p1-1.fc16.i686 mpich2-devel-0:1.4.1p1-4.fc16.i686 netcdf-devel-0:4.1.3-2.fc16.i686 openmpi-devel-0:1.5.4-3.fc16.i686 openmpi-devel-0:1.5-4.fc16.i686 plplot-fortran-devel-0:5.9.8-2.fc16.1.i686 plplot-fortran-devel-0:5.9.9-1.fc16.i686 qd-devel-0:2.3.11-3.fc15.i686 wannier90-devel-0:1.2-3.fc15.i686 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-17
Can I pick up tdom? Takanori 2012/2/2 : Re: [ACTION REQUIRED v4] Retiring packages for F-17 > Orphan tdom > Removing: tdom > mcu8051ide requires tdom = 0.8.2-8.fc17 > tkabber requires tdom = 0.8.2-8.fc17 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-17
Sorry I'm late on this, but is it still possible for me to pick up python-ZSI? Regards, Tim On Wed, 1 Feb 2012 16:49:48 -0500 Bill Nottingham wrote: > (comaintainers bcc'd) > > Each release, before branching, we block currently orphaned packages. > It's that time again for Fedora 17. > > New this go-round is that we are also blocking packages that have > failed to build since before Fedora 15. > > The following packages are currently orphaned, or fail to build. If > you have a need for one of these packages, please pick them up. > > Due to the orphaning of packages due to inactive maintainers, this > list is a little longer than normal. > > If these packages are not claimed, they will be retired shortly before > the mass branch for Fedora 17 on February 7th. > > Orphan adaptx > Orphan ario > Orphan asa > comaintained by: pertusus > Orphan autodafe > Orphan avant-window-navigator > comaintained by: ngompa > Orphan avl > Orphan awn-extras-applets > Orphan bit > Orphan blam > comaintained by: alexlan > Orphan blt > Orphan bwidget > Orphan camstream > Orphan ccsm > Orphan compiz > Orphan compiz-bcop > Orphan compiz-fusion-extras > Orphan compiz-fusion-unsupported > Orphan compiz-manager > Orphan compizconfig-backend-gconf > Orphan compizconfig-backend-kconfig4 > Orphan compizconfig-python > Orphan conexus > Orphan dbus-cxx > Orphan eazykeyboard > Orphan eclipse-setools > Orphan eclipse-slide > Orphan erlang-erlzmq2 > Orphan expatmm > Orphan freehdl > comaintained by: chitlesh > Orphan gestikk > Orphan gget > Orphan gimpfx-foundry > Orphan gkrellm-volume > Orphan gmime22 > Orphan gnome-paint > Orphan gnubversion > Orphan gpx-viewer > Orphan higlayout > Orphan intellij-idea > Orphan intuitively > comaintained by: pertusus > Orphan invulgotracker > Orphan itaka > Orphan itcl > Orphan itk > Orphan itools > Orphan iwak > Orphan iwidgets > Orphan jps > Orphan kcirbshooter > Orphan libcompizconfig > Orphan libdesktop-agnostic > Orphan libmetalink > Orphan libnoise > Orphan libspe2 > Orphan libsx > comaintained by: pertusus > Orphan lifeograph > comaintained by: sundaram > Orphan log4c > Orphan lush > Orphan maradns > Orphan mathmap > Orphan maxr > comaintained by: cassmodiah > Orphan mediawiki-rss > comaintained by: ianweller > Orphan memchan > Orphan metalink > Orphan mingw32-OpenSceneGraph > Orphan mingw32-plib > Orphan mod_perlite > Orphan monsoon > Orphan mtkbabel > Orphan mulk > Orphan nanoxml > Orphan netbeans > Orphan netstiff > Orphan openbios > Orphan papyrus > Orphan pfscalibration > Orphan pfstmo > Orphan pfstools > Orphan phpTodo > Orphan picocontainer > Orphan pinot > Orphan podcatcher > Orphan puritan > Orphan pyactivemq > Orphan pyevent > comaintained by: lmacken > Orphan pymssql > Orphan pypar2 > Orphan python-ZSI > comaintained by: jbowes > Orphan python-assets > Orphan python-elixir > comaintained by: lmacken smilner > Orphan python-text_table > Orphan python-wehjit > Orphan quadkonsole > Orphan quotatool > Orphan rainbow > comaintained by: mstone > Orphan rudecgi > Orphan rudeconfig > Orphan saxon > comaintained by: dbhole > Orphan snacc > comaintained by: chitlesh > Orphan specspo > Orphan spr > Orphan spu-binutils > Orphan stgit > comaintained by: jcwillia > Orphan systemtapguiserver > Orphan tbcload > Orphan tcl-tclxml > Orphan tcl-thread > Orphan tclchecker > Orphan tclcompiler > Orphan tcldebugger > Orphan tclhttpd > Orphan tcllib > Orphan tclparser > Orphan tclpro > Orphan tclsoap > Orphan tdom > Orphan tkcon > Orphan tklib > Orphan tktable > comaintained by: sergiopr > Orphan tomcat5 > comaintained by: devrim dwalluck > Orphan transbot > Orphan ugene > Orphan verilator > comaintained by: chitlesh > Orphan vim-perl-tt2 > Orphan wordtrans > Orphan xcftools > Orphan xmldb-api > comaintained by: dbhole > Orphan xmlrpc-epi > Orphan xmlunit > > List of deps left behind by packages which are orphaned or fail to > build: > > Removing: blt > magic requires blt = 2.4-34.z.fc17 > ngspice requires blt-devel = 2.4-34.z.fc17 > scitools-extras requires blt = 2.4-34.z.fc17 > > Removing: bwidget > amsn requires bwidget = 1.9.0-3.fc17 > mcu8051ide requires bwidget = 1.9.0-3.fc17 > setools-gui requires bwidget = 1.9.0-3.fc17 > tkabber requires bwidget = 1.9.0-3.fc17 > > Removing: ccsm > fusion-icon requires ccsm = 0.9.5.92-2.fc17 > > Removing: compiz > compiz-fusion requires compiz-devel = > 0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17 > compiz-fusion requires compiz = > 0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17 > compiz-fusion-devel requires pkgconfig(compiz) = 0.9.5.92.1 > compiz-fusion-devel requires compiz-devel = > 0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17 > compiz-plugins-main requires libopengl.so compiz-plugins-main > requires compiz-devel = > 0.9.5.92.1-0.1.gite676f1b12eb
Re: Fedora 17 Mass branching
On Wed, 08 Feb 2012 11:24:45 -0600 Mike Chambers wrote: > On Tue, 2012-02-07 at 23:45 -0600, Dennis Gilmore wrote: > > We have completed mass branching for Fedora 17 you now need make > > sure that you build things for Fedora 17 from the f17 branch, > > master is now for Fedora 18. > > So when can we see the actual F17 dir on site/mirrors so we can start > mirroring them locally? Should compose tonight and start syncing out then I think. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17 Mass branching
Dennis Gilmore wrote: > Any feature that is invasive and intended for Fedora 18 should be > landing ASAP now. Just to preempt any possible misunderstandings: Any feature that is invasive should be landing ASAP now IN F18 RAWHIDE ONLY, *NOT* IN THE F17 BRANCH! It is TOO LATE for invasive features in Fedora 17, they need to target Fedora 18 instead! (Dennis, I know this is obvious to you, but it might not be obvious to everyone.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Adam Williamson wrote: > /usr move went through the entire feature process, which is exactly how > features are supposed to get 'broader fedora engagement'. If you're > interested in (or concerned about) new features, the feature process > provides an awful lot of opportunities for you to raise those concerns. The impact had not been appropriately summarized on the feature page, and the mailing list thread was just too long for most people to follow. Any later threads pointing out serious flaws in the feature were just entirely ignored by FESCo, on the grounds that "the feature was already accepted", as Matthew Garrett repeatedly pointed out in the FESCo meeting which would have been the last chance to reconsider. IMHO, FESCo needs to accept that sometimes they make a mistake (especially if the vote was disputed to begin with) and revote. UsrMove should have been unapproved, not only for F17, but forever. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Wed, Feb 8, 2012 at 4:01 PM, Kevin Fenzi wrote: > Personally, I think f16 was a very stable boring release. > There were rough spots, but there always are. I'm still pretty sure we are doing better introducing subsystem transitions now than the pain of the initial udev transition way back in the distance past. But that's just a personal feeling, I don't have a quantitative metric that I can point to to describe a trendline for subsystem transition pain with an eye towards historical perspective. I'm none-to-pleased with the level of unsupported nostalgia in the discussion as rhetorical device however. It's not an effective debate tool especially when this project has a history of rapid development. -jef"which reminds me I need to get some more Just For Men beard gel at the store today"spaleta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Am 09.02.2012 02:01, schrieb Kevin Fenzi: > On Thu, 09 Feb 2012 01:49:13 +0100 > Reindl Harald wrote: > >> to say it in other words: >> >> the overall release-quality of fedora was MUCH better as long >> Redhat controlled it and before everybody could propose hughe >> changes in all sorts of subsystems as long he finds some >> peopole agree and not enough disagreing loud enough > > srpms by release: > > Fedora Core 6: 1154 > Fedora 17: 25927 > > Thats a LOT smaller set of software. ;) > Of course there's a lot more people working on things... this is not right these days there were "Fedora Core" and "Fedora Extras" "Fedora Extras" was the "community repo" "Fedora Core" was controlled by Redhat only and using Fedora since FC3 and since FC6 on all machines i own i notice quality problems in the core-distribution at release times which did not happen in days of "Fedora Core" because changes on the core system were done with much more care than these days signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Thu, 09 Feb 2012 01:49:13 +0100 Reindl Harald wrote: > to say it in other words: > > the overall release-quality of fedora was MUCH better as long > Redhat controlled it and before everybody could propose hughe > changes in all sorts of subsystems as long he finds some > peopole agree and not enough disagreing loud enough srpms by release: Fedora Core 6: 1154 Fedora 17: 25927 Thats a LOT smaller set of software. ;) Of course there's a lot more people working on things... > hopefully if /usrmove is done and the systemd-transition is > really finished fedora will come back to the quality of > the days where i started to love this distribution Help test, file bugs. Personally, I think f16 was a very stable boring release. There were rough spots, but there always are. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: [389 Project] #84: 389 Directory Server Unnecessary Checkpoints
https://fedorahosted.org/389/ticket/84 https://fedorahosted.org/389/attachment/ticket/84/0001-Trac-Ticket-84-389-Directory-Server-Unnecessary-Chec.patch Fix description: txn_checkpoint was always called with DB_FORCE flag. This patch introduces db_force arg to dblayer_txn_checkpoint and DB_FORCE is passed only from dblayer_force_checkpoint. Note: checkpoint_threadmain is one of the BDB housekeeping threads. It calls txn_checkpoint periodically. The interval is specified in the ldbm database config: dn: cn=config,cn=ldbm database,cn=plugins,cn=config nsslapd-db-checkpoint-interval: Even if DB_FORCE is not set and there is no db modify activities, as long as checkpoint thread is functioning, some disk IO is observed due to updating the lock table and mempool to check if there is any data to flush. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: /usrmove?
Am 09.02.2012 01:44, schrieb Reindl Harald: >> This is how software development works. > > the with every release worser overall-quality shows > clearly that software development does NOT work this > way over the long > > seeing how dramatically the release quality of many > opensource software gets lower and lower the last > years this is the wrong direction > > there were times where opensource software was very careful > with 1.0 releases and "we are done" until it really worked > because the developers liked to release really good software > > these days more and more developers have only the target > to release with "hopefully good enough" state, if "good enough" > is the target finally nothing will be really good > > the target should ALWAYS be perfect and finally it can be > considered what is not really needed and were a compromise > can be made - if you starting with "hopefully good enough" > you will end in poor quality at all to say it in other words: the overall release-quality of fedora was MUCH better as long Redhat controlled it and before everybody could propose hughe changes in all sorts of subsystems as long he finds some peopole agree and not enough disagreing loud enough hopefully if /usrmove is done and the systemd-transition is really finished fedora will come back to the quality of the days where i started to love this distribution signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Am 09.02.2012 01:36, schrieb Jesse Keating: > On 2/8/12 4:30 PM, Reindl Harald wrote: >> it is a very good idea because the overall quality of fedora would >> be improved if there would be a larger release-blocking to get >> the big changes fixed BEFORE alpha and in the meantime not involved >> maintainers could proceed fixing the tons of small bugs and polish >> the distribution at all - there are really neough rough corners >> involved in the last releases to work on that there is no need >> to proceed this way of releasing and starting alpha/beta with >> known broken things > > The entire point of having alpha/beta releases is to get wide testing without > having everything "perfect". If it > were perfect, it'd be the release. So you have relaxed requirements for > earlier stages of the release. maybe this should be considered as not optimal > In this case, anaconda upgrades is not a required functionality for the Alpha > release. It is required however for > Beta. We can go ahead with Alpha and get wider testing on everything else, > while anaconda team and others work on > the upgrade issue, and hope to have it fixed by Beta time. > > This is how software development works. the with every release worser overall-quality shows clearly that software development does NOT work this way over the long seeing how dramatically the release quality of many opensource software gets lower and lower the last years this is the wrong direction there were times where opensource software was very careful with 1.0 releases and "we are done" until it really worked because the developers liked to release really good software these days more and more developers have only the target to release with "hopefully good enough" state, if "good enough" is the target finally nothing will be really good the target should ALWAYS be perfect and finally it can be considered what is not really needed and were a compromise can be made - if you starting with "hopefully good enough" you will end in poor quality at all signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 2/8/12 4:30 PM, Reindl Harald wrote: it is a very good idea because the overall quality of fedora would be improved if there would be a larger release-blocking to get the big changes fixed BEFORE alpha and in the meantime not involved maintainers could proceed fixing the tons of small bugs and polish the distribution at all - there are really neough rough corners involved in the last releases to work on that there is no need to proceed this way of releasing and starting alpha/beta with known broken things The entire point of having alpha/beta releases is to get wide testing without having everything "perfect". If it were perfect, it'd be the release. So you have relaxed requirements for earlier stages of the release. In this case, anaconda upgrades is not a required functionality for the Alpha release. It is required however for Beta. We can go ahead with Alpha and get wider testing on everything else, while anaconda team and others work on the upgrade issue, and hope to have it fixed by Beta time. This is how software development works. -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Am 09.02.2012 01:23, schrieb Adam Williamson: > Our experience, though, is that this is entirely the wrong way to do things. > The problem is that life is rarely so neat: you don't get an orderly > succession > of Big Scary Bugs popping up one at a time for you to shoot down. there are enough open bugs for the next ten years > No, it's usually the case that there are ten or a dozen Big Scary Bugs at any > one > time. Given that, it's a very bad idea to find one and then focus all > attention on > it: block all releases until it's fixed and stop looking for or working on > other BSBs. it is a very good idea because the overall quality of fedora would be improved if there would be a larger release-blocking to get the big changes fixed BEFORE alpha and in the meantime not involved maintainers could proceed fixing the tons of small bugs and polish the distribution at all - there are really neough rough corners involved in the last releases to work on that there is no need to proceed this way of releasing and starting alpha/beta with known broken things signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Reindl Harald wrote: > > >Am 08.02.2012 22:56, schrieb Adam Williamson: >> On Wed, 2012-02-08 at 12:49 -0900, Jef Spaleta wrote: >>> On Wed, Feb 8, 2012 at 12:46 PM, Adam Williamson > wrote: "The objectives of the Alpha release are to: Publicly release installable media versions of a feature >complete test release Test accepted features of Fedora 17 Identify as many F17Beta blocker bugs as possible Identify as many F17Blocker blocker bugs as possible" >>> >>> And in this scope. Inability to upgrade would be such a Beta >blocker, methinks. >> >> Sure. But the above doesn't mean that beta and final blockers should >be >> *fixed* in Alpha (obviously not). The point is that the Alpha exists >*in >> order to be used for the discovery of bugs that will block Beta and >> Final*. i.e., we need an Alpha release to test upgrading, find out >that >> it's broken, and file a bug that blocks the Beta release. :) > >why in the world do you need this if you STILL KNOW that something >is exremely broken? this is useless - block ALPHA if you are >aware of horrible broken things instead wasting peoples time >with saying "we have a new alpha lpease test it" > >-- >devel mailing list >devel@lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/devel It's interesting you should say that, because it's a natural instinct: if you find a Big Scary Bug, panic and pull the big red Stop lever until it's fixed, then proceed as normal. Our experience, though, is that this is entirely the wrong way to do things. The problem is that life is rarely so neat: you don't get an orderly succession of Big Scary Bugs popping up one at a time for you to shoot down. No, it's usually the case that there are ten or a dozen Big Scary Bugs at any one time. Given that, it's a very bad idea to find one and then focus all attention on it: block all releases until it's fixed and stop looking for or working on other BSBs. It's a much better idea to work as hard as you can to _prevent_ that happening - obviously you have to make sure the BSB gets fixed, but you definitely DON'T let that stop you looking for and fixing other BSBs. Rather the reverse - I think it's important to work actively on finding ways around big showstoppers when we hit them, so we can find the *other* big showstoppers lurking behind them. Otherwise you get a bad process where you hit a crasher in anaconda and everyone downs tools for two days until it's fixed and a new build is done - whereupon you discover there's another crasher on the next page of anaconda, and if you'd just found a way to work around the earlier crash and carried on testing, the anaconda team couls have been working on BOTH crashes, and probably fixed both in the same two days. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Am 08.02.2012 22:56, schrieb Adam Williamson: > On Wed, 2012-02-08 at 12:49 -0900, Jef Spaleta wrote: >> On Wed, Feb 8, 2012 at 12:46 PM, Adam Williamson wrote: >>> "The objectives of the Alpha release are to: >>> >>>Publicly release installable media versions of a feature complete >>> test release >>>Test accepted features of Fedora 17 >>>Identify as many F17Beta blocker bugs as possible >>>Identify as many F17Blocker blocker bugs as possible" >> >> And in this scope. Inability to upgrade would be such a Beta blocker, >> methinks. > > Sure. But the above doesn't mean that beta and final blockers should be > *fixed* in Alpha (obviously not). The point is that the Alpha exists *in > order to be used for the discovery of bugs that will block Beta and > Final*. i.e., we need an Alpha release to test upgrading, find out that > it's broken, and file a bug that blocks the Beta release. :) why in the world do you need this if you STILL KNOW that something is exremely broken? this is useless - block ALPHA if you are aware of horrible broken things instead wasting peoples time with saying "we have a new alpha lpease test it" signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Thu, 2012-02-09 at 04:51 +0530, Rahul Sundaram wrote: > On 02/09/2012 04:46 AM, Adam Williamson wrote: > > > > > I personally would likely be opposed to such a change, just on the > > grounds (as stated earlier) that we really can't get too strict at Alpha > > stage. Remember, people always want us to stop slipping releases, and > > the slips quite often happen at Alpha stage. ISTR upgrading was broken > > at Alpha stage in F16; if we'd been obliged to have upgrading working by > > Alpha, maybe the F16 release would have been delayed *another* week, and > > QA and anaconda teams would have lost even _more_ sleep. > > I would request that you bring it up in the next QA meeting and discuss > it even if you are opposed to it. As far as Fedora 16 alpha problem is > concerned, I think you are optimizing at the wrong level. Changes that > destabilize the release to that extend has to be handled in a different > branch or split out or postponed. We don't usually discuss criteria proposals at meetings because it takes a long time and not enough people are present (timezone issues). Async discussion via the mailing list has proven to work better. As I said, you can do this; anyone can propose changes to the criteria. Just post a mail to test@ proposing it. There's no 'required form' for such mails but if you want to look at how it's been done in the past, just look through the archives for mails with 'criter' or 'propos' in the subject. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/09/2012 04:46 AM, Adam Williamson wrote: > > I personally would likely be opposed to such a change, just on the > grounds (as stated earlier) that we really can't get too strict at Alpha > stage. Remember, people always want us to stop slipping releases, and > the slips quite often happen at Alpha stage. ISTR upgrading was broken > at Alpha stage in F16; if we'd been obliged to have upgrading working by > Alpha, maybe the F16 release would have been delayed *another* week, and > QA and anaconda teams would have lost even _more_ sleep. I would request that you bring it up in the next QA meeting and discuss it even if you are opposed to it. As far as Fedora 16 alpha problem is concerned, I think you are optimizing at the wrong level. Changes that destabilize the release to that extend has to be handled in a different branch or split out or postponed. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Thu, 2012-02-09 at 03:42 +0530, Rahul Sundaram wrote: > On 02/09/2012 03:16 AM, Adam Williamson wrote: > > > As the release criteria put it - > > https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria: > > > > "The objectives of the Alpha release are to: > > > > Publicly release installable media versions of a feature complete > > test release > > Test accepted features of Fedora 17 > > Identify as many F17Beta blocker bugs as possible > > Identify as many F17Blocker blocker bugs as possible" > > Wouldn't preserving the ability to upgrade increase the chances of > testing the new features and finding bugs? Does QA team have final say > on the release criteria That's more or less how it's worked so far, yes. We don't really have any formal 'escalation process', but if anyone was particularly unhappy with the validation process, I imagine it could be escalated to Board level. > and is there a way I can ask to reconsider this? Certainly: you can propose that the Beta criterion "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria" be turned into an Alpha criterion. You'd do this by posting a message to the test@ list, quite simply, that's all there is to it. We don't have a very formal 'voting process', so far we've simply done things by consensus; it's usually the case that we're able to come up with a resolution that everyone, or perhaps everyone except one person, agrees with. If we ever get a very controversial proposal I imagine we'll have to come up with something better, but for now that's what we've got. I personally would likely be opposed to such a change, just on the grounds (as stated earlier) that we really can't get too strict at Alpha stage. Remember, people always want us to stop slipping releases, and the slips quite often happen at Alpha stage. ISTR upgrading was broken at Alpha stage in F16; if we'd been obliged to have upgrading working by Alpha, maybe the F16 release would have been delayed *another* week, and QA and anaconda teams would have lost even _more_ sleep. As long as we're sticking to six month release cycles, giant feature lists, and short freezes, there has to be a recognition that we can't demand too much in the release criteria; it just won't be practically manageable. (The cynic in me would point out that, when we're just shootin' the breeze on devel@, people are happy to demand 'more quality' out of the validation process...but when the release is delayed by two weeks and we in QA are holding out for a bug to be considered a blocker according to the criteria, suddenly everyone's pressuring us to 'just let it go and get the release done already'...) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Wed, 2012-02-08 at 13:31 -0900, Jef Spaleta wrote: > On Wed, Feb 8, 2012 at 12:56 PM, Adam Williamson wrote: > > On Wed, 2012-02-08 at 12:49 -0900, Jef Spaleta wrote: > >> And in this scope. Inability to upgrade would be such a Beta blocker, > >> methinks. > > > > Sure. But the above doesn't mean that beta and final blockers should be > > *fixed* in Alpha (obviously not). The point is that the Alpha exists *in > > order to be used for the discovery of bugs that will block Beta and > > Final*. i.e., we need an Alpha release to test upgrading, find out that > > it's broken, and file a bug that blocks the Beta release. :) > > That was in fact my point. > I make no argument as to whether identifiable Beta blockers identified > prior to Alpha release should necessarily become Alpha blockers. > The answer to that I fear is stuck in the morass of "case by case > judgement call." Not really, no: they're Beta blockers. The time when they're discovered is not relevant. An issue has to infringe the Alpha criteria to be considered an Alpha blocker. The process allows us to flag up Beta and Final blockers long before we actually hit the Beta or Final cycles, so there's no real problem with this. If we want an issue to block Alpha, then we need to propose and rationally defend an Alpha criterion. > Luckily its not my call. Now if you'll excuse me I need to find my > pitchfork so I won't look out of place as a slip back into the angry > mob. You'll need a flaming torch too! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 2/8/2012 4:37 PM, Rahul Sundaram wrote: > On 02/09/2012 02:30 AM, Adam Williamson wrote: > As far >> as things-that-are-actually-QA are concerned: we mostly go by the >> release validation process, and per the criteria, upgrades have to work >> by Beta, not Alpha. ' > > Any particular reason for this? I think it makes sense to ensure > upgrades work in an alpha release as well. I am the OP of this thread. I normally only lurk here. I do not, myself, feel that I am in any way qualified to 'vote' on this. Or even discuss it. My participation with Fedora is user-to-user help and bug reports. However... I really, really suggest that since this is going happen that it be *painless* for Joe/Jane Average User updates. Or clean installs. As well as for the so called 'power-user' that has sersiouly modified his/his system. That was the reason I posed these questions. Because I can already hear the screaming and flame wars. Messages filled with insults and '!!!" comments. Please make this 'just work' as far back as Fedora 15 and *loudly* warn anyone using a before Fedora 15 release that their system *will* explode. I suggest on the web pages and in the Release Notes. And since *no one reads those first* also in the installer. As in - STOP! This will destroy your install. Do you want to do this? n/Y? Followed with - Are you sure that you want to destroy your system? y/N? Are you *really sure*? y/N? Please. -- David "May your road lead you to warm sands." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Wed, Feb 8, 2012 at 12:56 PM, Adam Williamson wrote: > On Wed, 2012-02-08 at 12:49 -0900, Jef Spaleta wrote: >> And in this scope. Inability to upgrade would be such a Beta blocker, >> methinks. > > Sure. But the above doesn't mean that beta and final blockers should be > *fixed* in Alpha (obviously not). The point is that the Alpha exists *in > order to be used for the discovery of bugs that will block Beta and > Final*. i.e., we need an Alpha release to test upgrading, find out that > it's broken, and file a bug that blocks the Beta release. :) That was in fact my point. I make no argument as to whether identifiable Beta blockers identified prior to Alpha release should necessarily become Alpha blockers. The answer to that I fear is stuck in the morass of "case by case judgement call." I'm just glad I'm not the one who has to make the judgement. Though I'd probably choose to not make beta blockers block alpha in most circumstances. Luckily its not my call. Now if you'll excuse me I need to find my pitchfork so I won't look out of place as a slip back into the angry mob. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/09/2012 03:16 AM, Adam Williamson wrote: > As the release criteria put it - > https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria: > > "The objectives of the Alpha release are to: > > Publicly release installable media versions of a feature complete > test release > Test accepted features of Fedora 17 > Identify as many F17Beta blocker bugs as possible > Identify as many F17Blocker blocker bugs as possible" Wouldn't preserving the ability to upgrade increase the chances of testing the new features and finding bugs? Does QA team have final say on the release criteria and is there a way I can ask to reconsider this? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Wed, 2012-02-08 at 12:49 -0900, Jef Spaleta wrote: > On Wed, Feb 8, 2012 at 12:46 PM, Adam Williamson wrote: > > "The objectives of the Alpha release are to: > > > >Publicly release installable media versions of a feature complete > > test release > >Test accepted features of Fedora 17 > >Identify as many F17Beta blocker bugs as possible > >Identify as many F17Blocker blocker bugs as possible" > > And in this scope. Inability to upgrade would be such a Beta blocker, > methinks. Sure. But the above doesn't mean that beta and final blockers should be *fixed* in Alpha (obviously not). The point is that the Alpha exists *in order to be used for the discovery of bugs that will block Beta and Final*. i.e., we need an Alpha release to test upgrading, find out that it's broken, and file a bug that blocks the Beta release. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Wed, Feb 8, 2012 at 12:46 PM, Adam Williamson wrote: > "The objectives of the Alpha release are to: > > Publicly release installable media versions of a feature complete > test release > Test accepted features of Fedora 17 > Identify as many F17Beta blocker bugs as possible > Identify as many F17Blocker blocker bugs as possible" And in this scope. Inability to upgrade would be such a Beta blocker, methinks. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Wed, 2012-02-08 at 13:44 -0800, Adam Williamson wrote: > On Thu, 2012-02-09 at 03:07 +0530, Rahul Sundaram wrote: > > On 02/09/2012 02:30 AM, Adam Williamson wrote: > > As far > > > as things-that-are-actually-QA are concerned: we mostly go by the > > > release validation process, and per the criteria, upgrades have to work > > > by Beta, not Alpha. ' > > > > Any particular reason for this? I think it makes sense to ensure > > upgrades work in an alpha release as well. > > We don't necessarily think so. I mean, Alpha is *alpha*. We don't want > to set the bar too high. It's mainly meant to boot and run and let you > test the features that have been implemented. If you look at the point > of an Alpha, there isn't a whole lot of point in supporting upgrades to > it. You're not meant to be running Alpha on a machine you actually > *care* about (although I know some of us do, I'm typing this on one :>). > You're meant to be installing Alpha on a disposable throwaway > machine/partition/VM and testing specific things on it. Given that, > upgrade isn't a particularly important thing to have working, because > there's no reason to preserve a previous configuration (which after all > is what an upgrade does). As the release criteria put it - https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria: "The objectives of the Alpha release are to: Publicly release installable media versions of a feature complete test release Test accepted features of Fedora 17 Identify as many F17Beta blocker bugs as possible Identify as many F17Blocker blocker bugs as possible" -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Thu, 2012-02-09 at 03:07 +0530, Rahul Sundaram wrote: > On 02/09/2012 02:30 AM, Adam Williamson wrote: > As far > > as things-that-are-actually-QA are concerned: we mostly go by the > > release validation process, and per the criteria, upgrades have to work > > by Beta, not Alpha. ' > > Any particular reason for this? I think it makes sense to ensure > upgrades work in an alpha release as well. We don't necessarily think so. I mean, Alpha is *alpha*. We don't want to set the bar too high. It's mainly meant to boot and run and let you test the features that have been implemented. If you look at the point of an Alpha, there isn't a whole lot of point in supporting upgrades to it. You're not meant to be running Alpha on a machine you actually *care* about (although I know some of us do, I'm typing this on one :>). You're meant to be installing Alpha on a disposable throwaway machine/partition/VM and testing specific things on it. Given that, upgrade isn't a particularly important thing to have working, because there's no reason to preserve a previous configuration (which after all is what an upgrade does). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/09/2012 02:30 AM, Adam Williamson wrote: As far > as things-that-are-actually-QA are concerned: we mostly go by the > release validation process, and per the criteria, upgrades have to work > by Beta, not Alpha. ' Any particular reason for this? I think it makes sense to ensure upgrades work in an alpha release as well. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Wed, 2012-02-08 at 12:20 -0800, Toshio Kuratomi wrote: > Now it's quite possible that if QA doesn't care whether anaconda upgrades > work until beta that the feature policy could stand to be rewritten here. > Perhaps we could say that Features do not need to be testable in the upgrade > scenario until beta, for instance... I'm not sure that really makes sense, > though If we have a failure to communicate between the feature owners > and the anaconda team (as happened with the feature owners and releng this > time) it might be that the anaconda team isn't told that new code needs to > be integrated or even written until Beta which seems like a bad idea I see your argument, and there's a lot of merit to it. It's entirely up to FESCo to decide how to proceed with this on a feature process basis. As far as the 'feature' side of things goes I don't really have a dog in the fight and am just trying to provide information to this list. As far as things-that-are-actually-QA are concerned: we mostly go by the release validation process, and per the criteria, upgrades have to work by Beta, not Alpha. So as far as QA is concerned the fact that anaconda support for /usr relocation wasn't present until today (it's in now, untested though) is not a huge problem. I personally, and I think QA as a team, certainly don't mind if FESCo decides that, as far the feature process is concerned, it *is* a problem and the feature process should be tightened up to ensure it doesn't happen in future. Hope that clarifies things. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Wed, Feb 08, 2012 at 11:07:48AM -0800, Adam Williamson wrote: > On Wed, 2012-02-08 at 11:03 -0800, Toshio Kuratomi wrote: > > > > > If the anaconda support for UsrMove is not merged (and maybe not even > > > > written?), then why was an untestable and incomplete feature merged? > > > > > > Well, it becomes a semantic argument. You can, after all, install with > > > the /usr move in place, right now. You can upgrade from F16 with /usr > > > move in place, if you follow the yum instructions. You can then test the > > > *feature itself* perfectly well. Arguably, anaconda support for the > > > feature is not part of the feature. You could go either way on this, but > > > it's not an obviously wrong statement. > > > > > I think I would fall firmly on anaconda support being needed for the > > feature. It was one of the things that the FPC was counting on when it > > approved it, for instance. If anaconda support doesn't make it in, we > > won't be able to release with UsrMove activated. > > At this point we're talking about the (first) feature freeze, not the > final release. The question is whether there's a violation of the > feature process if anaconda doesn't have support for usrmove *right > now*, not whether there's a problem if it doesn't have support by > release time. > My argument is that anaconda integration is part of the feature. It just wasn't mentioned on the Feature page (I think because the feature page wasn't fully updated once it became apparent that anaconda integration would be necessary.) How do we know that anaconda integration is part of the feature? If it wasn't we would be able to ship the final release without that integration being done because it would be an optional thing. We wouldn't have an F17 feature, "UsrMove" and an F18 feature "Anaconda that can work with UsrMove". The reason the feature process goes through Fesco (as opposed to be purely about marketing) is because coordination and collaboration is needed to make sure that all the pieces work together. You can't have an "SELinux enabled by default" feature if Xorg doesn't run when it's enabled, for instance. If you want to look at it as two separate features, you'll find that you're fighting with the defintion of Feature Freeze[1]_ from the policy rather than working with it. For instance, "If a feature page specifies that a feature will be enabled by default, it must be so at Feature Freeze." In this case we have a default method of upgrading (anaconda -- yum upgrading isn't even a supported method of upgrading) along with a Feature that is supposed to be enabled on all systems. If the code that integrates them isn't written, then they cant both be satisfied by the policy without contorting their spirit (well, anaconda is only a feature when the anaconda team proposes changes to it... otherwise, it's just a bug in an existing package that it doesn't work with the new changes) .. [1]_ http://fedoraproject.org/wiki/Features/Policy/Milestones#Feature_Freeze Now it's quite possible that if QA doesn't care whether anaconda upgrades work until beta that the feature policy could stand to be rewritten here. Perhaps we could say that Features do not need to be testable in the upgrade scenario until beta, for instance... I'm not sure that really makes sense, though If we have a failure to communicate between the feature owners and the anaconda team (as happened with the feature owners and releng this time) it might be that the anaconda team isn't told that new code needs to be integrated or even written until Beta which seems like a bad idea -Toshio pgpEfg9oAemTg.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Class-Load/f17] Update to 0.14
Summary of changes: 7fba86a... Update to 0.14 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Class-Load] Update to 0.14
commit 7fba86ad86b98fcce0dc5cdfb018b062bb90a2f0
Author: Paul Howarth
Date: Wed Feb 8 19:26:28 2012 +
Update to 0.14
- New upstream release 0.14:
- Use Module::Implementation to handle loading the XS or PP versions of
the
code; using this module fixes a few bugs
- Under taint mode, setting an implementation in the
CLASS_LOAD_IMPLEMENTATION env var caused a taint error
- An invalid value in the CLASS_LOAD_IMPLEMENTATION env var is now
detected
and reported immediately; no attempt is made to load an invalid
implementation
- BR: perl(Module::Implementation)
- BR: perl(base), perl(Carp), perl(strict) and perl(warnings) for
completeness
- Drop version requirement for perl(Package::Stash), no longer present
upstream
- Drop explicit runtime dependencies, no longer needed
- Don't BR: perl(Class::Load::XS) or perl(Pod::Coverage::Moose) if we're
bootstrapping
- Don't run the release tests when bootstrapping as the Pod coverage test
will
fail in the absence of Pod::Coverage::Moose
perl-Class-Load.spec | 46 +-
sources |2 +-
2 files changed, 38 insertions(+), 10 deletions(-)
---
diff --git a/perl-Class-Load.spec b/perl-Class-Load.spec
index bb0416d..ca4623f 100644
--- a/perl-Class-Load.spec
+++ b/perl-Class-Load.spec
@@ -1,6 +1,6 @@
Name: perl-Class-Load
-Version: 0.13
-Release: 2%{?dist}
+Version: 0.14
+Release: 1%{?dist}
Summary: A working (require "Class::Name") and more
Group: Development/Libraries
License: GPL+ or Artistic
@@ -14,13 +14,22 @@ BuildRequires: perl(ExtUtils::MakeMaker)
# ===
# Module requirements
# ===
+BuildRequires: perl(base)
+BuildRequires: perl(Carp)
BuildRequires: perl(Data::OptList)
+BuildRequires: perl(Module::Implementation)
BuildRequires: perl(Module::Runtime) >= 0.011
-BuildRequires: perl(Package::Stash) >= 0.32
+BuildRequires: perl(Package::Stash)
+BuildRequires: perl(strict)
BuildRequires: perl(Try::Tiny)
+BuildRequires: perl(warnings)
# ===
# Regular test suite requirements
# ===
+# Class::Load::XS -> Class::Load
+%if 0%{!?perl_bootstrap:1}
+BuildRequires: perl(Class::Load::XS)
+%endif
BuildRequires: perl(Test::Fatal)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Without::Module)
@@ -28,20 +37,21 @@ BuildRequires: perl(version)
# ===
# Author/Release test requirements
# ===
+# Pod::Coverage::Moose -> Moose -> Class::Load
+%if 0%{!?perl_bootstrap:1}
+BuildRequires: perl(Pod::Coverage::Moose)
+%endif
+BuildRequires: perl(Test::CPAN::Changes)
BuildRequires: perl(Test::EOL)
BuildRequires: perl(Test::NoTabs)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
-BuildRequires: perl(Test::Spelling), aspell-en
BuildRequires: perl(Test::Requires)
-BuildRequires: perl(Pod::Coverage::Moose)
-BuildRequires: perl(Test::CPAN::Changes)
+BuildRequires: perl(Test::Spelling), aspell-en
# ===
# Runtime requirements
# ===
Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
-Requires: perl(Module::Runtime) >= 0.011
-Requires: perl(Package::Stash) >= 0.32
# Also requires core module perl(Exporter) via a "use base" construct
%description
@@ -71,7 +81,7 @@ find %{buildroot} -depth -type d -exec rmdir {} ';'
2>/dev/null
%{_fixperms} %{buildroot}
%check
-make test RELEASE_TESTING=1
+make test %{!?perl_bootstrap:RELEASE_TESTING=1}
%files
%doc Changes LICENSE README
@@ -79,6 +89,24 @@ make test RELEASE_TESTING=1
%{_mandir}/man3/Class::Load.3pm*
%changelog
+* Tue Feb 7 2012 Paul Howarth - 0.14-1
+- Update to 0.14:
+ - Use Module::Implementation to handle loading the XS or PP versions of the
+code; using this module fixes a few bugs
+ - Under taint mode, setting an implementation in the
+CLASS_LOAD_IMPLEMENTATION env var caused a taint error
+ - An invalid value in the CLASS_LOAD_IMPLEMENTATION env var is now detected
+and reported immediately; no attempt is made to load an invalid
+implementation
+- BR: perl(Module::Implementation)
+- BR: perl(base), perl(Carp), perl(strict) and perl(warnings) for completeness
+- Drop version requirement for perl(Package::Stash), no longer present upstream
+- Drop explicit runtime dependencies, no longer needed
+- Don't BR: perl(Class::Load::XS) or perl(Pod::Coverage::Moose) if we're
+ bootstrapping
+- Don't ru
File Class-Load-0.14.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Class-Load: dcae0c8fef65ec193cfafc0f624c4be4 Class-Load-0.14.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: /usrmove?
Once upon a time, Adam Williamson said: > At this point we're talking about the (first) feature freeze, not the > final release. The question is whether there's a violation of the > feature process if anaconda doesn't have support for usrmove *right > now*, not whether there's a problem if it doesn't have support by > release time. As I quoted, features are supposed to be "substantially complete", and something that _requires_ anaconda changes should not be considered anywhere near complete if the required changes haven't been written yet. This isn't a case of a bug in anaconda not holding up the Alpha release; it is a feature that is definately not complete and testable after the feature freeze has passed. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swap
On 02/07/2012 10:16 AM, Jerry James wrote: > Is anyone up for a review swap? I need a review for lrslib: > https://bugzilla.redhat.com/show_bug.cgi?id=723752. > > Thanks, I'll bite. I have two, take your pick: ibutils - https://bugzilla.redhat.com/show_bug.cgi?id=773485 ibsim - https://bugzilla.redhat.com/show_bug.cgi?id=773492 -- Doug Ledford GPG KeyID: 0E572FDD http://people.redhat.com/dledford signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Wed, 2012-02-08 at 11:03 -0800, Toshio Kuratomi wrote: > > > If the anaconda support for UsrMove is not merged (and maybe not even > > > written?), then why was an untestable and incomplete feature merged? > > > > Well, it becomes a semantic argument. You can, after all, install with > > the /usr move in place, right now. You can upgrade from F16 with /usr > > move in place, if you follow the yum instructions. You can then test the > > *feature itself* perfectly well. Arguably, anaconda support for the > > feature is not part of the feature. You could go either way on this, but > > it's not an obviously wrong statement. > > > I think I would fall firmly on anaconda support being needed for the > feature. It was one of the things that the FPC was counting on when it > approved it, for instance. If anaconda support doesn't make it in, we > won't be able to release with UsrMove activated. At this point we're talking about the (first) feature freeze, not the final release. The question is whether there's a violation of the feature process if anaconda doesn't have support for usrmove *right now*, not whether there's a problem if it doesn't have support by release time. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Wed, Feb 08, 2012 at 09:53:20AM -0800, Adam Williamson wrote: > On Wed, 2012-02-08 at 08:11 -0600, Chris Adams wrote: > > Once upon a time, Stijn Hoop said: > > > On Wed, 08 Feb 2012 06:37:33 +0100 > > > Kevin Kofler wrote: > > > > Adam Williamson wrote: > > > > > Note that this has not actually been implemented in anaconda yet, > > > > > so if you do an anaconda upgrade at this time, it will explode > > > > > horribly. The bug requesting this support be added to anaconda is > > > > > http://bugzilla.redhat.com/show_bug.cgi?id=787893 . > > > > > > > > It's totally unacceptable that this "feature" has been merged in this > > > > incomplete state. Working upgrades should have been a prerequisite > > > > for merging it! Anaconda upgrades are even part of our release > > > ^^^ > > > > criteria! This affects both the DVD upgrades and preupgrade, which > > > > are the 2 upgrade methods Fedora claims to support. > > > > > > I did not see a release yet, where did you find it? > > > > He said "release criteria". Included in that is the Feature Freeze > > (which was yesterday for F17), which includes: > > > > Once the Feature Freeze milestone is reached, all new features for the > > release should be: > > - substantially complete and in a testable state > > > > If the anaconda support for UsrMove is not merged (and maybe not even > > written?), then why was an untestable and incomplete feature merged? > > Well, it becomes a semantic argument. You can, after all, install with > the /usr move in place, right now. You can upgrade from F16 with /usr > move in place, if you follow the yum instructions. You can then test the > *feature itself* perfectly well. Arguably, anaconda support for the > feature is not part of the feature. You could go either way on this, but > it's not an obviously wrong statement. > I think I would fall firmly on anaconda support being needed for the feature. It was one of the things that the FPC was counting on when it approved it, for instance. If anaconda support doesn't make it in, we won't be able to release with UsrMove activated. I note that, just like the rel-eng dependency, the anaconda dependency is not noted on the feature page and the completion percentage on the feature page is marked as 100%. It seems that this feature has pointed us at a flaw when it comes to figuring out what points of collaboration are needed, keeping the feature page updated as new points of collaboration are discovered to go with the new plan, and making the completion percentage reliable. I've added these points to the Fixing Features page: https://fedoraproject.org/wiki/Fixing_features#Specific_examples_of_where_the_Feature_Process_failed I'll have to think about what sort of practical solutions exist. -Toshio pgpXWswIMsR15.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Config-Auto-0.42.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Config-Auto: baa0907e5c79c0bf8c91cfe8b56577de Config-Auto-0.42.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[389-devel] Please review (take 2): [389 Project] #27: SASL/PLAIN binds do not work
https://fedorahosted.org/389/ticket/27 https://fedorahosted.org/389/attachment/ticket/27/0001-Trac-Ticket-27-SASL-PLAIN-binds-do-not-work.patch Thanks to Rich for his comment. Fixed the code based upon his suggestions. --noriko -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On 02/07/2012 11:55 PM, Adam Williamson wrote: > On Tue, 2012-02-07 at 13:51 +0530, Rahul Sundaram wrote: >> >> >> On Tue, Feb 7, 2012 at 12:38 PM, Bohuslav Kabrda >> wrote: >> >> >> Again, citing FHS: >> "Distributions may install software in /opt, but must not >> modify or delete software installed by the local system >> administrator without the assent of the local system >> administrator." >> >> >> How can this be interpreted as "non-OS vendor supplied"? >> >> This is one of many places in which FHS is vague but that's the common >> interpretation all distributions rely on > > Um. Really? Wasn't there a distro - I'm thinking SUSE? - that installed > KDE in /opt for a long time? Not anymore apparently Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Wed, Feb 8, 2012 at 6:53 PM, Adam Williamson wrote: > Arguably, anaconda support for the > feature is not part of the feature. ... mostly because the "Scope" section of the feature doesn't contain any information about the scope. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Wed, 2012-02-08 at 07:59 -0500, Genes MailLists wrote: > On 02/08/2012 12:37 AM, Kevin Kofler wrote: > > Adam Williamson wrote: > >> Note that this has not actually been implemented in anaconda yet, so if > >> you do an anaconda upgrade at this time, it will explode horribly. The > >> bug requesting this support be added to anaconda is > >> http://bugzilla.redhat.com/show_bug.cgi?id=787893 . > > > > It's totally unacceptable that this "feature" has been merged in this > > incomplete state. Working upgrades should have been a prerequisite for > > merging it! Anaconda upgrades are even part of our release criteria! This > > affects both the DVD upgrades and preupgrade, which are the 2 upgrade > > methods Fedora claims to support. > There seems to have been a recent pattern (last year or so) of pushing > premature pet projects rapidly without broader fedora engagement. /usr move went through the entire feature process, which is exactly how features are supposed to get 'broader fedora engagement'. If you're interested in (or concerned about) new features, the feature process provides an awful lot of opportunities for you to raise those concerns. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Wed, 2012-02-08 at 08:11 -0600, Chris Adams wrote: > Once upon a time, Stijn Hoop said: > > On Wed, 08 Feb 2012 06:37:33 +0100 > > Kevin Kofler wrote: > > > Adam Williamson wrote: > > > > Note that this has not actually been implemented in anaconda yet, > > > > so if you do an anaconda upgrade at this time, it will explode > > > > horribly. The bug requesting this support be added to anaconda is > > > > http://bugzilla.redhat.com/show_bug.cgi?id=787893 . > > > > > > It's totally unacceptable that this "feature" has been merged in this > > > incomplete state. Working upgrades should have been a prerequisite > > > for merging it! Anaconda upgrades are even part of our release > > ^^^ > > > criteria! This affects both the DVD upgrades and preupgrade, which > > > are the 2 upgrade methods Fedora claims to support. > > > > I did not see a release yet, where did you find it? > > He said "release criteria". Included in that is the Feature Freeze > (which was yesterday for F17), which includes: > > Once the Feature Freeze milestone is reached, all new features for the > release should be: > - substantially complete and in a testable state > > If the anaconda support for UsrMove is not merged (and maybe not even > written?), then why was an untestable and incomplete feature merged? Well, it becomes a semantic argument. You can, after all, install with the /usr move in place, right now. You can upgrade from F16 with /usr move in place, if you follow the yum instructions. You can then test the *feature itself* perfectly well. Arguably, anaconda support for the feature is not part of the feature. You could go either way on this, but it's not an obviously wrong statement. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Wed, 2012-02-08 at 06:37 +0100, Kevin Kofler wrote: > Adam Williamson wrote: > > Note that this has not actually been implemented in anaconda yet, so if > > you do an anaconda upgrade at this time, it will explode horribly. The > > bug requesting this support be added to anaconda is > > http://bugzilla.redhat.com/show_bug.cgi?id=787893 . > > It's totally unacceptable that this "feature" has been merged in this > incomplete state. Working upgrades should have been a prerequisite for > merging it! Anaconda upgrades are even part of our release criteria! This > affects both the DVD upgrades and preupgrade, which are the 2 upgrade > methods Fedora claims to support. Hey, tell it to FESCo. If you asked QA to approve or reject features, nothing would ever get approved. No features makes our life easier. ;) As noted in my other mail, upgrades are indeed in the criteria, but at *beta* stage. They're not required to work at Alpha. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Tue, 2012-02-07 at 20:57 -0700, Chris Murphy wrote: > > On Feb 7, 2012, at 7:46 PM, Adam Williamson wrote: > > Note that this has not actually been implemented in anaconda yet, so if > > you do an anaconda upgrade at this time, it will explode horribly. > > So the instructions here: > http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 > > Are the expected steps to move from F16 to F17 Alpha TC1? And then by > Alpha TC2 the expectation is that these steps will be performed by > anaconda? Not exactly. Upgrading is not a release-blocking issue until Beta; Alpha can go out with upgrades not working. So anaconda team isn't absolutely required to implement it until Beta. I don't know what their actual timeframe for doing it is. I expect it won't be in TC2, since I want to compose that Real Soon Now and the upgrade stuff isn't done yet. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Another Rawhide bug: middle button then trackpad scroll down causes page up
https://bugzilla.redhat.com/show_bug.cgi?id=788632 If you middle click on any scrolling window, then (even some time later) use the track pad two-finger thing to scroll down, the window will "jump up" as if PgUp has been pressed. It's incredibly annoying and makes things like browsing results lists in Google barely usable. Originally I blamed this on Firefox, but it also happens in a terminal window (XFCE Terminal). What to assign this to? X? XFCE? Something else? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does the X server in Rawhide eat Control-Space?
On Wed, Feb 08, 2012 at 06:05:14PM +0100, Nicolas Mailhot wrote: > > Le Mer 8 février 2012 12:17, Richard W.M. Jones a écrit : > > > > After updating everything on my laptop to Rawhide (forced to by > > usrmove) I noticed that emacs was no longer responding to > > Control-Space for setting the mark. > > > > It seems like the X server itself is eating this key combination, > > since emacs works fine in a virtual console, but doesn't work in any > > terminal or directly under X. > > > It seems a bit odd that X would capture this key combination ... > > IIRC it's consumed by input method switching now (whatever the name is this > year) > > I don't think it's a good idea, lots of stuff already grabbed this combo (IIRC > some xkb maps do depend on ctrl+space) For example screen, where you cycle through windows by holding Ctrl and pressing "a" and space alternatively. With ibus grabbing ctrl+space it doesn't work. -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17 Mass branching
On Tue, 2012-02-07 at 23:45 -0600, Dennis Gilmore wrote: > We have completed mass branching for Fedora 17 you now need make sure > that you build things for Fedora 17 from the f17 branch, master is now > for Fedora 18. So when can we see the actual F17 dir on site/mirrors so we can start mirroring them locally? -- Mike Chambers Madisonville, KY "Best little town on Earth!" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does the X server in Rawhide eat Control-Space?
- Original Message - > From: "Nicolas Mailhot" > To: "Development discussions related to Fedora" > > Sent: Wednesday, February 8, 2012 7:05:14 PM > Subject: Re: Does the X server in Rawhide eat Control-Space? > > > Le Mer 8 février 2012 12:17, Richard W.M. Jones a écrit : > > > > After updating everything on my laptop to Rawhide (forced to by > > usrmove) I noticed that emacs was no longer responding to > > Control-Space for setting the mark. > > > > It seems like the X server itself is eating this key combination, > > since emacs works fine in a virtual console, but doesn't work in > > any > > terminal or directly under X. > > > It seems a bit odd that X would capture this key combination ... > > IIRC it's consumed by input method switching now (whatever the name > is this year) > > I don't think it's a good idea, lots of stuff already grabbed this > combo (IIRC > some xkb maps do depend on ctrl+space) I have even opened FESCo ticket https://fedorahosted.org/fesco/ticket/798 to say on that because personally I think it's unacceptable and projects with such bad behaviour should be forced to learn playing with the rest. At least we still can add conflicts in our packages when we have to deal such changes because in my case Eclipse is totally unusable and I consider this as the only possible way to have working Eclipse package if ibus is not changed. Alex > > -- > Nicolas Mailhot > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does the X server in Rawhide eat Control-Space?
Le Mer 8 février 2012 12:17, Richard W.M. Jones a écrit : > > After updating everything on my laptop to Rawhide (forced to by > usrmove) I noticed that emacs was no longer responding to > Control-Space for setting the mark. > > It seems like the X server itself is eating this key combination, > since emacs works fine in a virtual console, but doesn't work in any > terminal or directly under X. > It seems a bit odd that X would capture this key combination ... IIRC it's consumed by input method switching now (whatever the name is this year) I don't think it's a good idea, lots of stuff already grabbed this combo (IIRC some xkb maps do depend on ctrl+space) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 788123] Request for EPEL branches for perl-Module-Runtime
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=788123 --- Comment #4 from Fedora Update System 2012-02-08 10:24:10 EST --- perl-Module-Runtime-0.011-3.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-Module-Runtime-0.011-3.el6 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: /usrmove?
On Wed, Feb 8, 2012 at 12:59 PM, Genes MailLists wrote: > > There seems to have been a recent pattern (last year or so) of pushing > premature pet projects rapidly without broader fedora engagement. > > I know this little issue will get sorted out and its still > rawhide/pre-f17. But its part of the pattern. > > I suspect the pushers feel they are breaking ground and doing good > things. I fervently believe many if not all of them are indeed good > ideas - just often very premature and the process is poorly managed. All > are well intended. > > For many of us its a bad trend to see - and creates an impression that > a few pushy folks are wresting control - rather than things being > accepted based on merit and good work. > > Its a very disappointing thing to see fedora spiraling in this way. I > don't know what changed for this to happen but it is not a net positive. > > Just a personal perspective from a long time fedora user (since about > Redhat 3 or so). I don't know what it means for RHEL but I sincerely > hope it can learn from these missteps when its facing the decision what > to include from fedora .. but I fear its not practical for RHEL to take > anything but all of fedora - so if there's a way to improve this, its at > the fedora level. > > That said, extra kudos to the kernel team who have made things better, > more stable and still managed to keep pace with current kernel > development providing solid, frequent and timely builds all the while > contributing to kernel dev itself. Thank you. Well said! There are some fantastic and excellent developments in Fedora - and some really superb developers and maintainers. The selinux development and support springs immediately to mind and, as Gene said, kernel support is superb. Wireless driver support is top notch, and printing support and development is excellent. Generally the KDE sig do a great job keeping packages flowing reasonably close to upstream developments - with only a relatively small delay for example in releasing 4.8 which will likely be soon. There are others too many to mention that are also superb and vital components of the system that are maintained well and in a timely fashion when it comes to bringing in necessary updates and particularly fixes for security vulnerabilities that are discovered from time to time. So far several major new project developments like pulseaudio, systemd and udev have survived at the point of each stable Fedora release though not without some serious bug squashing required in the pre-release phase for several releases. Some releases have been better than others and in some cases fewer people have opted to move stable platforms to a release and skipped till the next one. However it is really important not to become complacent. I spent 20 years as a private pilot and at times I took the "go" decision on a flight when the weather was difficult and marginal, and I survived. The problem is that it becomes easier the next time to make a similar decision - and if each time you survive on a marginal decision then you feel inside that you are safe when in fact you are carrying a risk of failure - the more times that you tempt fate making such decisions the more likely it will be that one day you won't make it. It is important to not become overconfident that you are all-knowing and immortal. In the case of the private pilot the consequence is that you may not only lose your life but also take the lives of others with you. There have clearly been times when Fedora has "sailed close to the wind" on "go/nogo" decisions on occasion. So far Fedora has made the right decisions at the point of GA release. But just like in the case of the pilots, the one time the decision is the wrong one will have significant consequences. I hope that the latter does not happen in the near future, and the decision making process should take account of the risk of failure as well as the rewards of success. I have been a devoted Fedora user since FC1 - but I am ever more acutely aware that some projects are pushing the boundaries pretty hard - and it is important to listen to the user community when the final button is being pushed. I expect many will say this is already the case - and I hope that they are right. -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Module-Runtime/el6] Reinstate compatibility with old distributions like EL-5
commit 3c757262c8720ade83f50e3b894bb65fc1bea4ea
Author: Paul Howarth
Date: Wed Feb 8 14:14:30 2012 +
Reinstate compatibility with old distributions like EL-5
- Reinstate compatibility with old distributions like EL-5
- Add back buildroot definition and cleaning
- Add back %defattr
- Classify buildreqs by Build/Module/Tests/Runtime
- Make %files list more explicit
- Don't use macros for commands
.gitignore |5 +
perl-Module-Runtime.spec | 36 ++--
2 files changed, 27 insertions(+), 14 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d34773c..c2480be 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1 @@
-/Module-Runtime-0.008.tar.gz
-/Module-Runtime-0.009.tar.gz
-/Module-Runtime-0.010.tar.gz
-/Module-Runtime-0.011.tar.gz
+/Module-Runtime-[0-9.]*.tar.gz
diff --git a/perl-Module-Runtime.spec b/perl-Module-Runtime.spec
index 05ac6e4..5d9823c 100644
--- a/perl-Module-Runtime.spec
+++ b/perl-Module-Runtime.spec
@@ -1,23 +1,26 @@
# This file is licensed under the terms of GNU GPLv2+.
Name: perl-Module-Runtime
Version:0.011
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Runtime module handling
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Module-Runtime/
Source0:
http://www.cpan.org/authors/id/Z/ZE/ZEFRAM/Module-Runtime-%{version}.tar.gz
BuildArch: noarch
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
+# Build:
BuildRequires: perl(Module::Build)
-# Tests:
+# Module:
BuildRequires: perl(Exporter)
BuildRequires: perl(Params::Classify)
BuildRequires: perl(parent)
+# Tests:
BuildRequires: perl(Test::More)
-# Optional tests:
BuildRequires: perl(Test::Pod) >= 1.00
BuildRequires: perl(Test::Pod::Coverage)
-Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+# Runtime:
+Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
Requires: perl(Exporter)
%description
@@ -28,23 +31,36 @@ modules, which are normally handled at compile time.
%setup -q -n Module-Runtime-%{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 \;
-%{_fixperms} $RPM_BUILD_ROOT/*
+rm -rf %{buildroot}
+./Build install destdir=%{buildroot} create_packlist=0
+find %{buildroot} -depth -type d -exec rmdir {} \; 2>/dev/null
+%{_fixperms} %{buildroot}
%check
./Build test
+%clean
+rm -rf %{buildroot}
+
%files
+%defattr(-,root,root,-)
%doc Changes README
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%{perl_vendorlib}/Module/
+%{_mandir}/man3/Module::Runtime.3pm*
%changelog
+* Wed Feb 8 2012 Paul Howarth - 0.011-3
+- Reinstate compatibility with old distributions like EL-5
+ - Add back buildroot definition and cleaning
+ - Add back %%defattr
+- Classify buildreqs by Build/Module/Tests/Runtime
+- Make %%files list more explicit
+- Don't use macros for commands
+
* Fri Jan 13 2012 Fedora Release Engineering
- 0.011-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: /usrmove?
Am 08.02.2012 15:11, schrieb Chris Adams: >>> criteria! This affects both the DVD upgrades and preupgrade, which >>> are the 2 upgrade methods Fedora claims to support. >> >> I did not see a release yet, where did you find it? > > He said "release criteria". Included in that is the Feature Freeze > (which was yesterday for F17), which includes: > > Once the Feature Freeze milestone is reached, all new features for the > release should be: > - substantially complete and in a testable state > > If the anaconda support for UsrMove is not merged (and maybe not even > written?), then why was an untestable and incomplete feature merged? because Fedora decided in the last releases to propose features and include them with the HOPE they MAY BE finished until release, hope is really not enough for a solid development, it could be if releases would happen in they way "it will be released if it is fnished" but NOT "it may be good enough and the release date is near" this is no "straight-forward" this is simply the best way to destroy the distribution if this happens the same way with the next releases because over the long the userbase get lost and contributors will also get lost if pemanently decisions are enforced which means a hughe work for all maintainers proposed by a handful of people Fedora 11-14 was a rock solid distribution and is slightly going down more and more because hughe changes happens only for the "we changed" instead of slow a little bit down and make existing features/packages/infrastructure rock solid i will not understand any developer who thinks he must permanently implement new things and make hughe changes affecting all users and contributors because fixing bugs and optimize existing features is not funny enough! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Sub-Install] Created tag perl-Sub-Install-0.925-1.el5
The lightweight tag 'perl-Sub-Install-0.925-1.el5' was created pointing to: 18019c8... Update to 0.925 (packaging changes) -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Sub-Install] Created tag perl-Sub-Install-0.925-1.el4
The lightweight tag 'perl-Sub-Install-0.925-1.el4' was created pointing to: 6ccdd8c... Update to 0.925 (packaging changes) -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: /usrmove?
On Wed, Feb 08, 2012 at 07:59:39AM -0500, Genes MailLists wrote: > For many of us its a bad trend to see - and creates an impression that > a few pushy folks are wresting control - rather than things being > accepted based on merit and good work. Things happen in Fedora because people work on them. The project is constructed in a way to make it possible for people to do things - we have very little in the way of procedures to *prevent* people from doing what they want. The idea of someone wresting control implies that there was someone else who had control in the first place. The project doesn't have any technical leadership (fesco is there to facilitate things, not to provide any real direction - with hindsight, "steering" was probably not a good word to use there), so unless an alternative is presented with clear technical argument backing it up, anything a group of developers wants to do is going to end up happening. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Once upon a time, Stijn Hoop said: > On Wed, 08 Feb 2012 06:37:33 +0100 > Kevin Kofler wrote: > > Adam Williamson wrote: > > > Note that this has not actually been implemented in anaconda yet, > > > so if you do an anaconda upgrade at this time, it will explode > > > horribly. The bug requesting this support be added to anaconda is > > > http://bugzilla.redhat.com/show_bug.cgi?id=787893 . > > > > It's totally unacceptable that this "feature" has been merged in this > > incomplete state. Working upgrades should have been a prerequisite > > for merging it! Anaconda upgrades are even part of our release > ^^^ > > criteria! This affects both the DVD upgrades and preupgrade, which > > are the 2 upgrade methods Fedora claims to support. > > I did not see a release yet, where did you find it? He said "release criteria". Included in that is the Feature Freeze (which was yesterday for F17), which includes: Once the Feature Freeze milestone is reached, all new features for the release should be: - substantially complete and in a testable state If the anaconda support for UsrMove is not merged (and maybe not even written?), then why was an untestable and incomplete feature merged? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Sub-Install/el4] Update to 0.925 (packaging changes)
commit 6ccdd8cd8c7a3ce0c3502eb75db1ea1ef627617a
Author: Paul Howarth
Date: Wed Feb 8 14:01:22 2012 +
Update to 0.925 (packaging changes)
- Update to 0.925 (packaging changes)
- Fix License
- BR: perl(ExtUtils::MakeMaker)
- BR: perl(Test::Output) for extra test coverage
- BR: perl(Carp), perl(Scalar::Util), perl(strict) and perl(warnings) for
completeness
- Skip buildreq perl(Test::Output) when bootstrapping to avoid circular
build
dependencies
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Make %files list more explicit
- Don't use macros for commands
.gitignore|2 +-
perl-Sub-Install.spec | 53 +++-
sources |2 +-
3 files changed, 36 insertions(+), 21 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4434ed3..8486097 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-Sub-Install-0.924.tar.gz
+/Sub-Install-[0-9.]*.tar.gz
diff --git a/perl-Sub-Install.spec b/perl-Sub-Install.spec
index 37dd36e..6b75df6 100644
--- a/perl-Sub-Install.spec
+++ b/perl-Sub-Install.spec
@@ -1,17 +1,25 @@
Name: perl-Sub-Install
-Version:0.924
-Release:1%{?dist}.1
+Version:0.925
+Release:1%{?dist}
Summary:Install subroutines into packages easily
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Sub-Install/
Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Sub-Install-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
-Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
-
-# testing
-BuildRequires: perl(Test::Pod), perl(Test::Pod::Coverage)
+BuildRequires: perl(Carp)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(strict)
+# Test::Output -> Sub::Exporter -> Sub::Install
+%if 0%{!?perl_bootstrap:1}
+BuildRequires: perl(Test::Output)
+%endif
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(warnings)
+Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
%description
This module makes it easy to install subroutines into packages without the
@@ -22,23 +30,17 @@ can see them.
%setup -q -n Sub-Install-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
-
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
-
+make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
-find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;
-
-%{_fixperms} %{buildroot}/*
+find %{buildroot} -depth -type d -exec rmdir {} \; 2>/dev/null
+%{_fixperms} %{buildroot}
%check
-# you'll note a number of tests are skipped due to Test::Output not being
-# present. However, Test::Output requires Sub::Exporter which requires...
-# Sub::Install. Holy circular loop, Batman! :)
make test
%clean
@@ -47,10 +49,23 @@ rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes README
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%{perl_vendorlib}/Sub/
+%{_mandir}/man3/Sub::Install.3pm*
%changelog
+* Wed Feb 8 2012 Paul Howarth 0.925-1
+- update to 0.925 (packaging changes)
+- fix License
+- BR: perl(ExtUtils::MakeMaker)
+- BR: perl(Test::Output) for extra test coverage
+- BR: perl(Carp), perl(Scalar::Util), perl(strict) and perl(warnings) for
+ completeness
+- Skip buildreq perl(Test::Output) when bootstrapping to avoid circular build
+ dependencies
+- use DESTDIR rather than PERL_INSTALL_ROOT
+- make %%files list more explicit
+- don't use macros for commands
+
* Wed Jan 5 2011 Paul Howarth 0.924-1.1
- drop perl(Test::Perl::Critic) buildreq for EPEL-4 build
diff --git a/sources b/sources
index b41530a..94fcdb6 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-eae66cb5cbd2064ae02b3aeacf6338e4 Sub-Install-0.924.tar.gz
+694aaec771c42280746a9a6279683263 Sub-Install-0.925.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Params-Classify] Created tag perl-Params-Classify-0.013-5.el6
The lightweight tag 'perl-Params-Classify-0.013-5.el6' was created pointing to: cb20467... Reinstate compatibility with old distributions like EL-5 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Sub-Install/el5] Update to 0.925 (packaging changes)
commit 18019c8e5a0ca91255106d52046250bf0be2d84f
Author: Paul Howarth
Date: Wed Feb 8 13:50:16 2012 +
Update to 0.925 (packaging changes)
- Update to 0.925 (packaging changes)
- Fix License
- BR: perl(ExtUtils::MakeMaker)
- BR: perl(Test::Output) for extra test coverage
- BR: perl(Carp), perl(Scalar::Util), perl(strict) and perl(warnings) for
completeness
- Skip buildreqs perl(Test::Output) and perl(Test::Perl::Critic) when
bootstrapping to avoid circular build dependencies
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Make %files list more explicit
- Don't use macros for commands
.gitignore|2 +-
perl-Sub-Install.spec | 57 +++-
sources |2 +-
3 files changed, 39 insertions(+), 22 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 17b7368..8486097 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-Sub-Install-0.922.tar.gz
+/Sub-Install-[0-9.]*.tar.gz
diff --git a/perl-Sub-Install.spec b/perl-Sub-Install.spec
index 2ec5c3e..c289640 100644
--- a/perl-Sub-Install.spec
+++ b/perl-Sub-Install.spec
@@ -1,18 +1,28 @@
Name: perl-Sub-Install
-Version:0.924
+Version:0.925
Release:1%{?dist}
Summary:Install subroutines into packages easily
-License:GPL or Artistic
+License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Sub-Install/
Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Sub-Install-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
-Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
-
-# testing
-BuildRequires: perl(Test::Pod), perl(Test::Pod::Coverage)
+BuildRequires: perl(Carp)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(strict)
+# Test::Output -> Sub::Exporter -> Sub::Install
+# Test::Perl::Critic -> Perl::Critic -> Exception::Class -> Test::EOL ->
+# Pod::Coverage::TrustPod -> Pod::Eventual -> Mixin::Linewise ->
Sub::Exporter -> Sub::Install
+%if 0%{!?perl_bootstrap:1}
+BuildRequires: perl(Test::Output)
BuildRequires: perl(Test::Perl::Critic)
+%endif
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(warnings)
+Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
%description
This module makes it easy to install subroutines into packages without the
@@ -23,24 +33,18 @@ can see them.
%setup -q -n Sub-Install-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
-
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
-
+make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
-find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;
-
-%{_fixperms} %{buildroot}/*
+find %{buildroot} -depth -type d -exec rmdir {} \; 2>/dev/null
+%{_fixperms} %{buildroot}
%check
-# you'll note a number of tests are skipped due to Test::Output not being
-# present. However, Test::Output requires Sub::Exporter which requires...
-# Sub::Install. Holy circular loop, Batman! :)
-make test
+make test %{!?perl_bootstrap:PERL_TEST_CRITIC=1}
%clean
rm -rf %{buildroot}
@@ -48,10 +52,23 @@ rm -rf %{buildroot}
%files
%defattr(-,root,root,-)
%doc Changes README
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%{perl_vendorlib}/Sub/
+%{_mandir}/man3/Sub::Install.3pm*
%changelog
+* Wed Feb 8 2012 Paul Howarth 0.925-1
+- update to 0.925 (packaging changes)
+- fix License
+- BR: perl(ExtUtils::MakeMaker)
+- BR: perl(Test::Output) for extra test coverage
+- BR: perl(Carp), perl(Scalar::Util), perl(strict) and perl(warnings) for
+ completeness
+- Skip buildreqs perl(Test::Output) and perl(Test::Perl::Critic) when
+ bootstrapping to avoid circular build dependencies
+- use DESTDIR rather than PERL_INSTALL_ROOT
+- make %%files list more explicit
+- don't use macros for commands
+
* Wed Nov 22 2006 Chris Weyl 0.924-1
- update to 0.924
- add perl(Test::Perl::Critic) to BR's
diff --git a/sources b/sources
index b41530a..94fcdb6 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-eae66cb5cbd2064ae02b3aeacf6338e4 Sub-Install-0.924.tar.gz
+694aaec771c42280746a9a6279683263 Sub-Install-0.925.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Params-Classify/el5] Reinstate compatibility with old distributions like EL-5
Summary of changes: cb20467... Reinstate compatibility with old distributions like EL-5 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Params-Classify/el6] Reinstate compatibility with old distributions like EL-5
commit cb20467ae8130389edf1fa18b661a8808d5d2a08
Author: Paul Howarth
Date: Wed Feb 8 13:44:49 2012 +
Reinstate compatibility with old distributions like EL-5
- Reinstate compatibility with old distributions like EL-5
- Add back buildroot definition and cleaning
- Make %files list more explicit
- Don't use macros for commands
perl-Params-Classify.spec | 30 --
1 files changed, 20 insertions(+), 10 deletions(-)
---
diff --git a/perl-Params-Classify.spec b/perl-Params-Classify.spec
index 8a68c0a..23186e7 100644
--- a/perl-Params-Classify.spec
+++ b/perl-Params-Classify.spec
@@ -1,21 +1,22 @@
Name: perl-Params-Classify
Version:0.013
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Argument type classification
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Params-Classify/
Source0:
http://www.cpan.org/authors/id/Z/ZE/ZEFRAM/Params-Classify-%{version}.tar.gz
-BuildRequires: perl(ExtUtils::ParseXS) >= 2.2006
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
+BuildRequires: perl(ExtUtils::ParseXS)
BuildRequires: perl(Module::Build)
BuildRequires: perl(parent)
BuildRequires: perl(Scalar::Util) >= 1.01
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
+Requires: perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
Requires: perl(Exporter)
Requires: perl(Scalar::Util) >= 1.01
-Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
%{?perl_default_filter}
@@ -30,27 +31,36 @@ functions in C++).
%setup -q -n Params-Classify-%{version}
%build
-%{__perl} Build.PL installdirs=vendor optimize="%{optflags}"
+perl Build.PL installdirs=vendor optimize="%{optflags}"
./Build
%install
+rm -rf %{buildroot}
./Build install destdir=%{buildroot} create_packlist=0
find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f {} \;
-find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;
-
-%{_fixperms} %{buildroot}/*
+find %{buildroot} -depth -type d -exec rmdir {} \; 2>/dev/null
+%{_fixperms} %{buildroot}
%check
./Build test
+%clean
+rm -rf %{buildroot}
+
%files
%defattr(-,root,root,-)
%doc Changes README
-%{perl_vendorarch}/auto/*
-%{perl_vendorarch}/Params*
-%{_mandir}/man3/*
+%{perl_vendorarch}/auto/Params/
+%{perl_vendorarch}/Params/
+%{_mandir}/man3/Params::Classify.3pm*
%changelog
+* Tue Feb 7 2012 Paul Howarth - 0.013-5
+- Reinstate compatibility with old distributions like EL-5
+ - Add back buildroot definition and cleaning
+- Make %%files list more explicit
+- Don't use macros for commands
+
* Fri Jan 13 2012 Fedora Release Engineering
- 0.013-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Fedora 17 Mass branching
We have completed mass branching for Fedora 17 you now need make sure that you build things for Fedora 17 from the f17 branch, master is now for Fedora 18. http://fedoraproject.org/wiki/Releases/17/Schedule We have the Alpha Change Freeze On Feb 14th this means that we will land f17-candidate builds to land in f17 until then. Bodhi updates will be enabled on February 14. Feature Freeze has passed and all features need to be testable for TC2. Any feature that is invasive and intended for Fedora 18 should be landing ASAP now. Releng ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/08/2012 12:37 AM, Kevin Kofler wrote: > Adam Williamson wrote: >> Note that this has not actually been implemented in anaconda yet, so if >> you do an anaconda upgrade at this time, it will explode horribly. The >> bug requesting this support be added to anaconda is >> http://bugzilla.redhat.com/show_bug.cgi?id=787893 . > > It's totally unacceptable that this "feature" has been merged in this > incomplete state. Working upgrades should have been a prerequisite for > merging it! Anaconda upgrades are even part of our release criteria! This > affects both the DVD upgrades and preupgrade, which are the 2 upgrade > methods Fedora claims to support. > > Kevin Kofler > There seems to have been a recent pattern (last year or so) of pushing premature pet projects rapidly without broader fedora engagement. I know this little issue will get sorted out and its still rawhide/pre-f17. But its part of the pattern. I suspect the pushers feel they are breaking ground and doing good things. I fervently believe many if not all of them are indeed good ideas - just often very premature and the process is poorly managed. All are well intended. For many of us its a bad trend to see - and creates an impression that a few pushy folks are wresting control - rather than things being accepted based on merit and good work. Its a very disappointing thing to see fedora spiraling in this way. I don't know what changed for this to happen but it is not a net positive. Just a personal perspective from a long time fedora user (since about Redhat 3 or so). I don't know what it means for RHEL but I sincerely hope it can learn from these missteps when its facing the decision what to include from fedora .. but I fear its not practical for RHEL to take anything but all of fedora - so if there's a way to improve this, its at the fedora level. That said, extra kudos to the kernel team who have made things better, more stable and still managed to keep pace with current kernel development providing solid, frequent and timely builds all the while contributing to kernel dev itself. Thank you. gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-Sub-Install ownership changed
Package perl-Sub-Install in Fedora EPEL 4 is now owned by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Sub-Install -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-Sub-Install ownership changed
Package perl-Sub-Install in Fedora EPEL 5 is now owned by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Sub-Install -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 788531] perl-Pod-Coverage-0.22 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=788531 Petr Šabata changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Pod-Coverage-0.22-1.fc ||18 Resolution||RAWHIDE Last Closed||2012-02-08 07:53:35 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Pod-Coverage/f17] 0.22 bump
Summary of changes: dd63f33... 0.22 bump (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Pod-Coverage] 0.22 bump
commit dd63f3386b6d371495059860d3c6396a52d12c59
Author: Petr Šabata
Date: Wed Feb 8 13:42:19 2012 +0100
0.22 bump
.gitignore |1 +
perl-Pod-Coverage.spec | 48 ++--
sources|2 +-
3 files changed, 32 insertions(+), 19 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index b21c71a..d16730b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Pod-Coverage-0.20.tar.gz
/Pod-Coverage-0.21.tar.gz
+/Pod-Coverage-0.22.tar.gz
diff --git a/perl-Pod-Coverage.spec b/perl-Pod-Coverage.spec
index 7aa6126..f10d9a8 100644
--- a/perl-Pod-Coverage.spec
+++ b/perl-Pod-Coverage.spec
@@ -1,19 +1,32 @@
Name: perl-Pod-Coverage
-Version:0.21
-Release:5%{?dist}
+Version:0.22
+Release:1%{?dist}
Summary:Checks if the documentation of a module is comprehensive
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Pod-Coverage/
Source0:
http://www.cpan.org/authors/id/R/RC/RCLAMP/Pod-Coverage-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
+BuildRequires: perl(base)
+BuildRequires: perl(constant)
+BuildRequires: perl(lib)
BuildRequires: perl(Devel::Symdump) >= 2.01
-BuildRequires: perl(Module::Build)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Pod::Find) >= 0.21
+BuildRequires: perl(Pod::Parser) >= 1.13
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
+Requires: perl(Devel::Symdump) >= 2.01
+Requires: perl(Pod::Find) >= 0.21
+Requires: perl(Pod::Parser) >= 1.13
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+%{?perl_default_filter}
+%global __requires_exclude
%{?__requires_exclude:__requires_exclude|}^perl\\(Devel::Symdump\\)$
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(Pod::Find\\)$
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(Pod::Parser\\)$
+
%description
Developers hate writing documentation. They'd hate it even more if their
computer tattled on them, but maybe they'll be even more thankful in the
@@ -26,26 +39,20 @@ module is comprehensive.
%setup -q -n Pod-Coverage-%{version}
%build
-%{__perl} Build.PL installdirs=vendor
-./Build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
-
-%{_fixperms} $RPM_BUILD_ROOT/*
+make pure_install PERL_INSTALL_ROOT=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;
+%{_fixperms} %{buildroot}/*
%check
-./Build test
-
-%clean
-rm -rf $RPM_BUILD_ROOT
+make test
%files
-%defattr(-,root,root,-)
-%doc Changes examples/
+%doc Changes examples
%{_bindir}/pod_cover
%{perl_vendorlib}/Pod/
%{_mandir}/man3/Pod::Coverage.3pm*
@@ -54,6 +61,11 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/Pod::Coverage::Overloader.3pm*
%changelog
+* Wed Feb 08 2012 Petr Šabata - 0.22-1
+- 0.22 bump
+- Switch to EE::MM
+- Modernize spec
+
* Fri Jan 13 2012 Fedora Release Engineering
- 0.21-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
diff --git a/sources b/sources
index 4ecafa5..a4f6e81 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-3d8acba0817cc01b03d63bb05e4cef52 Pod-Coverage-0.21.tar.gz
+6cf04053968db85c355a740ab170aaf5 Pod-Coverage-0.22.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Pod-Coverage-0.22.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Pod-Coverage: 6cf04053968db85c355a740ab170aaf5 Pod-Coverage-0.22.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 788123] Request for EPEL branches for perl-Module-Runtime
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=788123 Paul Howarth changed: What|Removed |Added CC||p...@city-fan.org Component|perl-Module-Runtime |perl-Module-Runtime Version|rawhide |el5 Product|Fedora |Fedora EPEL --- Comment #3 from Paul Howarth 2012-02-08 07:36:12 EST --- Thanks; I'm waiting on Params::Classify (Bug #637491) and an EPEL-5 update of ExtUtils::ParseXS (Bug #788243) before I can do these builds. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 788531] perl-Pod-Coverage-0.22 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=788531 Petr Šabata changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com AssignedTo|mmasl...@redhat.com |psab...@redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: nfs-utils requires modutils, but that is obsolete
On Wed, Feb 08, 2012 at 11:56:56AM +, Richard W.M. Jones wrote: > Currently in Rawhide it's impossible to update to the latest udev if > you have nfs-utils installed, because: > > Error: Package: 1:nfs-utils-1.2.5-11.fc17.x86_64 (@rawhide) >Requires: modutils >= 2.4.26-9 >Removing: module-init-tools-3.16-5.fc17.x86_64 (@rawhide) >modutils = 3.16 >Obsoleted By: kmod-5-4.fc17.x86_64 (rawhide) >Not found > > IIUC this suggests either that nfs-utils should be changed to depend > on kmod (but does this provide all of modutils?) or else kmod should > be changed to 'Provides' modutils. > > The modutils explicit dependency was added ages ago: > > * Thu Mar 11 2004 Bill Nottingham > - rpc_pipefs mounting and aliases are now in modutils; require that > > whatever that means .. rpc_pipefs is in nfs-utils, so it could be the > dependency is now bogus. > > Unfortunately removing nfs-utils isn't an option for me because that > would remove libvirt. Also reported in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=788264 Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
nfs-utils requires modutils, but that is obsolete
Currently in Rawhide it's impossible to update to the latest udev if you have nfs-utils installed, because: Error: Package: 1:nfs-utils-1.2.5-11.fc17.x86_64 (@rawhide) Requires: modutils >= 2.4.26-9 Removing: module-init-tools-3.16-5.fc17.x86_64 (@rawhide) modutils = 3.16 Obsoleted By: kmod-5-4.fc17.x86_64 (rawhide) Not found IIUC this suggests either that nfs-utils should be changed to depend on kmod (but does this provide all of modutils?) or else kmod should be changed to 'Provides' modutils. The modutils explicit dependency was added ages ago: * Thu Mar 11 2004 Bill Nottingham - rpc_pipefs mounting and aliases are now in modutils; require that whatever that means .. rpc_pipefs is in nfs-utils, so it could be the dependency is now bogus. Unfortunately removing nfs-utils isn't an option for me because that would remove libvirt. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Glib-Object-Introspection/f17] Add Cairo::GObject BR for tests
Summary of changes: 8d11321... Add Cairo::GObject BR for tests (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Gtk3/f17] Add Cairo::GObject BR
Summary of changes: 98d6e5d... Add Cairo::GObject BR (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 788531] New: perl-Pod-Coverage-0.22 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Pod-Coverage-0.22 is available https://bugzilla.redhat.com/show_bug.cgi?id=788531 Summary: perl-Pod-Coverage-0.22 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Pod-Coverage AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: st...@silug.org, fedora-perl-devel-l...@redhat.com, pertu...@free.fr, mmasl...@redhat.com, ppi...@redhat.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Latest upstream release: 0.22 Current version in Fedora Rawhide: 0.21 URL: http://search.cpan.org/dist/Pod-Coverage/ 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 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 785532] perl-Gtk3-0.003 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=785532 --- Comment #1 from Fedora Update System 2012-02-08 06:26:36 EST --- perl-Gtk3-0.003-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/perl-Gtk3-0.003-2.fc16 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 785363] perl-Glib-Object-Introspection-0.006 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=785363 --- Comment #2 from Fedora Update System 2012-02-08 06:25:50 EST --- perl-Glib-Object-Introspection-0.006-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/perl-Glib-Object-Introspection-0.006-2.fc16 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Does the X server in Rawhide eat Control-Space?
Sorry, I didn't mean to send this email. It turns out to be caused by ibus. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Does the X server in Rawhide eat Control-Space?
After updating everything on my laptop to Rawhide (forced to by usrmove) I noticed that emacs was no longer responding to Control-Space for setting the mark. It seems like the X server itself is eating this key combination, since emacs works fine in a virtual console, but doesn't work in any terminal or directly under X. xorg-x11-server-Xorg-1.11.99.901-3.20120124.fc17.x86_64 xev output from me pressing Control-space is here: http://oirase.annexia.org/tmp/xev.log It seems a bit odd that X would capture this key combination ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Gtk3/f16] (2 commits) ...Add Cairo::GObject BR
Summary of changes: f0f7277... Update to 0.003 release (rhbz #785532) (*) 98d6e5d... Add Cairo::GObject BR (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Audacity - audio editor - test request
Hi, It appears Audacity is getting close to v2 release (it's been in 1.3
beta mode for a few years).
I've built the current svn release as 2.0.0.alpha... , and request
anyone with audio hardware who would like to help to download and
install it to check whichever functions you feel like testing operate as
expected.
build: {rawhide}, also runs on F16 OK.
i686:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3771416
x86_64:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3771415
Any crash/exceptions definitely report in bugzilla.
Cheers, David Timms.
ps. An ffmpeg & mp3 version should be ready @RPM Fusion in a few days.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Glib-Object-Introspection/f16] (5 commits) ...Add Cairo::GObject BR for tests
Summary of changes: 9d32333... - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass (*) 58b3199... Update to 0.006 release (rhbz #785363) (*) 3e52570... Fix typo (*) ca852de... Remove obsolete patch (-EMONDAY) (*) 8d11321... Add Cairo::GObject BR for tests (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Gtk3] Add Cairo::GObject BR
commit 98d6e5d2bb9e923ddc9b3dbf0d08bd6e12a7f0ad
Author: Daniel P. Berrange
Date: Wed Feb 8 10:29:36 2012 +
Add Cairo::GObject BR
perl-Gtk3.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-Gtk3.spec b/perl-Gtk3.spec
index b83d03e..dfe36ff 100644
--- a/perl-Gtk3.spec
+++ b/perl-Gtk3.spec
@@ -2,7 +2,7 @@
Name: perl-Gtk3
Version:0.003
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Perl interface to the 3.x series of the GTK+ toolkit
License:LGPLv2+
Group: Development/Libraries
@@ -19,6 +19,7 @@ BuildRequires: perl(Carp)
BuildRequires: perl(Exporter)
BuildRequires: perl(Test::More)
BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Cairo::GObject)
Requires: perl(Glib) >= 1.240
Requires: perl(Glib::Object::Introspection) >= 0.002
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
@@ -63,6 +64,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2>/dev/null \;
%{_mandir}/man3/*
%changelog
+* Wed Feb 8 2012 Daniel P. Berrange - 0.003-2
+- Add Cairo::GObject BR
+
* Mon Jan 30 2012 Daniel P. Berrange - 0.003-1
- Update to 0.003 release (rhbz #785532)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Glib-Object-Introspection] Add Cairo::GObject BR for tests
commit 8d11321ef4035de702e4cca5a32a08c5b29f6753
Author: Daniel P. Berrange
Date: Wed Feb 8 10:27:01 2012 +
Add Cairo::GObject BR for tests
perl-Glib-Object-Introspection.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-Glib-Object-Introspection.spec
b/perl-Glib-Object-Introspection.spec
index d498625..e50740e 100644
--- a/perl-Glib-Object-Introspection.spec
+++ b/perl-Glib-Object-Introspection.spec
@@ -1,7 +1,7 @@
Name: perl-Glib-Object-Introspection
Version:0.006
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Dynamically create Perl language bindings
License:LGPLv2+
Group: Development/Libraries
@@ -12,6 +12,7 @@ BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(ExtUtils::PkgConfig) >= 1
BuildRequires: perl(Glib) >= 1.24
BuildRequires: perl(Glib::MakeHelper)
+BuildRequires: perl(Cairo::GObject)
BuildRequires: gobject-introspection-devel
BuildRequires: perl(Test::More)
# For the test suite
@@ -58,6 +59,9 @@ LANG=en_US.UTF8 make test
%{_mandir}/man3/*
%changelog
+* Tue Feb 7 2012 Daniel P. Berrange - 0.006-2
+- Add Cairo::GObject BR for tests
+
* Mon Jan 30 2012 Daniel P. Berrange - 0.006-1
- Update to 0.006 release (rhbz #785363)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Parse-CPAN-Meta/f17] update to 1.4402
Summary of changes: e15c52b... update to 1.4402 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Parse-CPAN-Meta] update to 1.4402
commit e15c52bc0a223bea0b753785c76910806751916d
Author: Iain Arnell
Date: Wed Feb 8 10:59:36 2012 +0100
update to 1.4402
.gitignore|1 +
perl-Parse-CPAN-Meta.spec |8 +---
sources |2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 2c16ac9..96d8402 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ Parse-CPAN-Meta-1.40.tar.gz
/Parse-CPAN-Meta-1.4200.tar.gz
/Parse-CPAN-Meta-1.4400.tar.gz
/Parse-CPAN-Meta-1.4401.tar.gz
+/Parse-CPAN-Meta-1.4402.tar.gz
diff --git a/perl-Parse-CPAN-Meta.spec b/perl-Parse-CPAN-Meta.spec
index 7407c08..70b942f 100644
--- a/perl-Parse-CPAN-Meta.spec
+++ b/perl-Parse-CPAN-Meta.spec
@@ -1,8 +1,8 @@
Name: perl-Parse-CPAN-Meta
# dual-lifed module needs to match the epoch in perl.spec
Epoch: 1
-Version:1.4401
-Release:3%{?dist}
+Version:1.4402
+Release:1%{?dist}
Summary:Parse META.yml and META.json CPAN metadata files
License:GPL+ or Artistic
Group: Development/Libraries
@@ -44,12 +44,14 @@ find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null
\;
make test
%files
-%defattr(-,root,root,-)
%doc Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Wed Feb 08 2012 Iain Arnell 1:1.4402-1
+- update to latest upstream version
+
* Fri Jan 13 2012 Fedora Release Engineering
- 1:1.4401-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
diff --git a/sources b/sources
index f820bff..436fc00 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-32c8b2ba97887b526a0948706c546eba Parse-CPAN-Meta-1.4401.tar.gz
+136571ea3aa3b21046346f7d1606a0a6 Parse-CPAN-Meta-1.4402.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Parse-CPAN-Meta-1.4402.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Parse-CPAN-Meta: 136571ea3aa3b21046346f7d1606a0a6 Parse-CPAN-Meta-1.4402.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-Declare/f17] update to 0.006010
Summary of changes: 8fd48e0... update to 0.006010 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Devel-Declare] update to 0.006010
commit 8fd48e001e9e3abbd7dbb2c1f5401d77dfd2c815
Author: Iain Arnell
Date: Wed Feb 8 10:55:25 2012 +0100
update to 0.006010
.gitignore |1 +
perl-Devel-Declare.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a3a7c55..b404ecb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@ Devel-Declare-0.006000.tar.gz
/Devel-Declare-0.006007.tar.gz
/Devel-Declare-0.006008.tar.gz
/Devel-Declare-0.006009.tar.gz
+/Devel-Declare-0.006010.tar.gz
diff --git a/perl-Devel-Declare.spec b/perl-Devel-Declare.spec
index 5754c48..9086489 100644
--- a/perl-Devel-Declare.spec
+++ b/perl-Devel-Declare.spec
@@ -1,5 +1,5 @@
Name: perl-Devel-Declare
-Version:0.006009
+Version:0.006010
Release:1%{?dist}
Summary:Adding keywords to perl, in perl
License:GPL+ or Artistic
@@ -50,6 +50,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Feb 08 2012 Iain Arnell 0.006010-1
+- update to latest upstream version
+
* Fri Feb 03 2012 Iain Arnell 0.006009-1
- update to latest upstream version
- add README to docs
diff --git a/sources b/sources
index 3923488..0844e58 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4914f467b86c62109d1bebc6c04a90fe Devel-Declare-0.006009.tar.gz
+c39c3e4d96315b7e86884864b3ec4394 Devel-Declare-0.006010.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBIx-Class-Schema-Loader/f17] update to 0.07017
Summary of changes: c06fff3... update to 0.07017 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBIx-Class-Schema-Loader] update to 0.07017
commit c06fff31b6ec05d4b2ae677800f617de5f656ae7
Author: Iain Arnell
Date: Wed Feb 8 10:54:27 2012 +0100
update to 0.07017
.gitignore |1 +
perl-DBIx-Class-Schema-Loader.spec |7 +--
sources|2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index f43de15..c4b6511 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ DBIx-Class-Schema-Loader-0.05003.tar.gz
/DBIx-Class-Schema-Loader-0.07002.tar.gz
/DBIx-Class-Schema-Loader-0.07010.tar.gz
/DBIx-Class-Schema-Loader-0.07015.tar.gz
+/DBIx-Class-Schema-Loader-0.07017.tar.gz
diff --git a/perl-DBIx-Class-Schema-Loader.spec
b/perl-DBIx-Class-Schema-Loader.spec
index 0ed2b1c..e36290c 100644
--- a/perl-DBIx-Class-Schema-Loader.spec
+++ b/perl-DBIx-Class-Schema-Loader.spec
@@ -1,6 +1,6 @@
Name: perl-DBIx-Class-Schema-Loader
Summary:Dynamic definition of a DBIx::Class::Schema
-Version:0.07015
+Version:0.07017
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -24,7 +24,7 @@ BuildRequires: perl(DBIx::Class) >= 0.08127
BuildRequires: perl(DBIx::Class::IntrospectableM2M)
BuildRequires: perl(Digest::MD5) >= 2.36
BuildRequires: perl(Exporter) >= 5.63
-BuildRequires: perl(ExtUtils::MakeMaker) >= 6.56
+BuildRequires: perl(ExtUtils::MakeMaker) >= 6.62
BuildRequires: perl(File::Copy)
BuildRequires: perl(File::Path) >= 2.07
BuildRequires: perl(File::Spec)
@@ -111,6 +111,9 @@ make test
%{_bindir}/*
%changelog
+* Wed Feb 08 2012 Iain Arnell 0.07017-1
+- update to latest upstream version
+
* Fri Feb 03 2012 Iain Arnell 0.07015-1
- update to latest upstream version
- silence rpmlint wrong-script-interpreter warning
diff --git a/sources b/sources
index 1c58fcb..1cb855d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-fd492cdd19e9b79f01be9558d764150f DBIx-Class-Schema-Loader-0.07015.tar.gz
+b2bc5056ce57508b7a3a887d5230ac00 DBIx-Class-Schema-Loader-0.07017.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
