Re: Summary/Minutes from today's FESCo Meeting (2013-10-23)
- Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/24/2013 02:45 AM, Bohuslav Kabrda wrote: * ticket #1182 F21/F22 System Wide Change: Python 3 as the Default Implementation - https://fedoraproject.org/wiki/Changes/Python_3_as_Default (nirik, 18:10:29) * AGREED: Feature is approved, provided that the contingency plan is updated with permitting a mixed environment of py2/py3 (+6,-1,0) (nirik, 18:30:22) This is not very clear to me. Does that mean that we shouldn't use side tag at all, but rather just switch as many system tools as possible to Python 3 (in F22 rawhide) and leave the rest running on Python 2? Just making sure before I update the Change page. Yes, we determined that a reasonable contingency plan is to move forward with the parts that did get converted properly and finish up the work in the next release. Thanks for the clarification, I'll update the Change page. The major caveat was that we would like to request that you focus efforts heavily on getting all the pieces that are required for the stripped-down cloud image in first, since they're the ones with the most to lose if we get stuck carrying two stacks at once. Ok, I'll try to send some patches in this direction. Thanks, Slavek. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: svn build issue
On Mon, 21 Oct, 2013 at 02:12:04 GMT, Kevin Kofler wrote:
Upstream's CMakeLists.txt does this:
FIND_PACKAGE(Subversion)
IF(Subversion_FOUND)
Subversion_WC_INFO(${PROJECT_SOURCE_DIR} GUAYADEQUE)
MESSAGE(Current revision is ${GUAYADEQUE_WC_REVISION})
SET( _GUREVISION_ ${GUAYADEQUE_WC_REVISION})
ELSE(Subversion_FOUND)
SET( _GUREVISION_ )
ENDIF(Subversion_FOUND)
In particular, this line:
Subversion_WC_INFO(${PROJECT_SOURCE_DIR} GUAYADEQUE)
runs svn info on the current directory to obtain the revision and store it
in the CMake variable GUAYADEQUE_WC_REVISION, which is then copies to the
CMake variable _GUREVISION_, presumably to show it in some about dialog or
something. And the tarball they ship is a working copy in an outdated format
(outdated SVN version). (IMHO, shipping SVN working copies rather than
exports as tarballs is broken in the first place.)
IMHO, just removing the .svn directories (i.e. converting the working copies
to a clean export) is the best fix, but you could also run svn upgrade in
the specfile (with BuildRequires: subversion) if you think it's important to
have the revision show up (but you could also manually specify
-D_GUREVISION_:STRING=1885 on the cmake command line to get that).
FWIW, the way that this *should* be done is:
1) Wish you had git's export-subst support[1]
2) If no .svn directory exists, assume it's not computable (no
revision number)
3) If subversion is found, then add_custom_command() to generate a
header file with configure_file() from output of execute_process()
to get the current revision (and preferably also whether the source
tree has modifications)
The main problem with the approach here is that the revision isn't
guaranteed to be right (not really a problem for tarballs, but upstream
might care):
% cmake ../src
% make # Uses current revision
% cd ../src
% vim # Hack, hack, hack
% svn add .
% svn commit
% cd ../build
% make # Uses previous revision
--Ben
[1].gitattributes and set export-subst on the CMake file with this code:
if ($Format:$ STREQUAL )
option(TREE_IS_PATCHED Maintainers: Please set to ON if patched OFF)
set(git_full_hash $Format:%H)
set(git_short_hash $Format:%h)
set(git_tree_dirty ${TREE_IS_PATCHED})
configure_file(...)
else ()
# Logic from above.
endif ()
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Graphics driver support in F21+
that you can do successfully complete a graphical DVD default package install with 512MB of RAM, or a text network default package install. I believe a text install may even work in 384MB, though I don't absolutely remember, and you may have to pass the parameter that disable's anaconda's RAM check to try it. Graphical network installs require more than 512MB - network installs need extra RAM before swap space comes online, as they go out and get package lists. Actually you could probably do an ugly hack around that by passing an intentionally invalid repo=, going through the storage spoke, and *then* setting the correct repo interactively, but that'd be hideous. I tried doing an F20 live install on a 512 MB machine and wasn't able to get it to work. There was no swap drive available though. The install configuration was extremely slow and seemed to have some of the subparts terminate. I never got to the part where I could start the install transaction. At some point I might try using an install image on the machine and see if that works better. The above was written with the assumption some swap space would be available, yeah. Once anaconda gets into package installation, memory consumption increases notably, but at that point, swap space is available if any has been configured during partitioning, so effective available memory is also greater. Last time I ran the numbers - which are on my blog somewhere - overall peak memory consumption (RAM plus swap) during a typical DVD install was, IIRC, somewhere around 750MB. From memory the peak was when the selinux policies were being applied/installed and those numbers are about right from my memory of the peak but I believe there's been work to reduce the high water mark although, like you, I have no idea what the current figures are. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New maintainer for lirc/Jarod Wilson's packages
On 2013-10-25 01:13, Adam Williamson wrote: On Sat, 2013-10-12 at 11:51 +0200, Alec Leamas wrote: On 10/12/2013 09:55 AM, Till Maas wrote: On Tue, Oct 01, 2013 at 07:50:45PM +0200, Till Maas wrote: cx18-firmware -- Firmware for Conexant cx23418-based video capture devices libcrystalhd -- Broadcom Crystal HD device interface library lirc -- The Linux Infrared Remote Control package rinputd -- A server for receiving input events over the network wacomexpresskeys -- Wacom ExpressKeys and Touch Strips configuration utility The packages are now orphaned, so please pick them up. Regards Till I have built a new release 15 which is available shortly in updates-testing for f19 (not rawhide ATM). This is *huge* update, and This is against guidelines. You should not build for an older release without building for all newer releases; it breaks the upgradepath. You should have sent this to Rawhide and F20 before sending it to F19. Yup, I nowadays know (and even understand why), got several messages about this. Sorry for the mess, --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Anyone else using and interested in co-maintaining sogo?
On 25.10.2013 03:00, Haïkel Guémar wrote: Le 25/10/2013 01:53, Adam Williamson a écrit : On Tue, 2013-10-15 at 17:35 +0200, Sandro Mani wrote: Hi, Needing a calendar server for the company, I've ended up packaging the groupware server SOGo [1], which is a neat MS Exchange alternative. SRPM of sogo plus deps are here: FWIW, OwnCloud works great as a CalDAV server (doesn't emulate Exchange, though, I don't think) and is already packaged. It's the thing that's finally given me a viable personal calendar/contacts server after years of failed attempts with other groupware things. There's also radicale [1] in Packages Collection, which should a more entreprisey (and lightweight solution) than both of them. Upstream maintainers may be insane but they did a great job :o) Thanks both. I didn't find radicale during my internet search, looks like a neat solution. However from what I can see it does not offer mail integration. I must say that I've got to really like SOGo, so once I've finished the -selinux subpackage, I'll post it for review. Sandro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [389-devel] Please review lib389 ticket 47568: Rename DSAdmin class (2nd)
My comments (a github like platform for comment could be really useful) https://fedorahosted.org/389/attachment/ticket/47568/0002-Ticket-47568-Renam e-DSAdmin-class.patch line: comment lib389/__init__.py:1: the module is lib389, not dirsrv lib389/brooker.py:795: python variable naming convention: I would get stick with the _ instead of camelCase and change whenever possible. tests/dsadmin_test.py: I renamed it lib389_test.py, you can merge my changes tests/dsadmin_test.py:39: why remove the addbackend_harn? tests/replica_test.py:119: you're using Backend.delete in a class that should test just Replica. I would use harness and the standard python-ldap methods in setup/teardown, so that we can change the Backend and Replica class without at least breaking the tests. Let me know + Peace, R. -- Roberto Polli Community Manager Babel S.r.l. - http://www.babel.it T: +39.06.9826.9651 M: +39.340.652.2736 F: +39.06.9826.9680 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere confidenziale per i destinatari in indirizzo. E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati nel messaggio originale. Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di comunicarlo al mittente e cancellarlo immediatamente. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Differences between Fakeroot and Mock Suggested method
On Fri, Oct 25, 2013 at 2:07 AM, Adam Williamson awill...@redhat.com wrote: The koji builders are usually faster than your system anyway Maybe, if building only a specific arch (e.g. koji build --arch-override=x86_64). The arm builders tend to be quite slow in the first place, and I don't think it helps that for some reason they end up doing most if not all noarch builds entirely as well as a lot of buildSRPMFromSCM and tagBuild tasks for arch specific builds. I suppose the reason has something to do with alphabetic ordering of arches or builder names, at least that's IIRC what the explanation was when ppc builders were in the mix, the slowest ones in the first place, and they ended up doing the extra tasks that arm ones do now... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Could someone help me with writing polkit rule?
Hello All!
I 'm trying to write a polkit rule which allows every member of a
particular group (ejabberd) to run a specific script
(/sbin/ejabberdctl or /usr/sbin/ejabberdctl). Other users should
not be even able to run it. This sounds simple, so I quickly wrote
this:
http://peter.fedorapeople.org/stuff/ejabberdctl.polkit.rules
I installed it to %{_datadir}/polkit-1/rules.d/51-ejabberdctl.rules,
and added /usr/bin/ejabberdctl which contains just the following:
===
#!/bin/sh
/usr/bin/pkexec /usr/sbin/ejabberdctl $@
===
So when user types ejabberdctl it actually runs /usr/sbin/ejabberdctl
under the polkit supervision. Unfortunately people started reporting
about the issues with the other apps:
* https://bugzilla.redhat.com/show_bug.cgi?id=1009408
I can't find what's wrong with the rule above so I'm calling you for
help. Could please someone help me fixing this mess?
--
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Sunday 13th of October: SSD cache test day
On 10/15/2013 09:13 PM, Rolf Fokkens wrote: On 10/14/2013 10:08 AM, Florian Weimer wrote: Is there a write-up somewhere documenting what strategies are implemented by bcache to keep the SSD and the hard disk contents in sync even in the event of a sudden power loss? This is good place to start: http://bcache.evilpiepirate.org/ It doesn't actually address this as far as I can see. It only describes how the data structure integrity is maintained on the SSD side. Even that doesn't seem to address torn writes (which are problem for cheap-to-medium-grade SSDs). The code contains propagate barriers as a to-do item (see the beginning of drivers/md/bcache/btree.c). I couldn't find anything that discusses write ordering issues which can occur in write-through mode. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [389-devel] Please review lib389 ticket 47568: Rename DSAdmin class (2nd)
On 10/25/2013 11:38 AM, Roberto Polli wrote: On Friday 25 October 2013 11:18:53 thierry bordaz wrote: lib389/brooker.py:795: python variable naming convention: I would get stick with the _ instead of camelCase and change whenever possible. If you prefer to use '_' also for local variable, I am fine. Using camel just for classes is more explicative, and I find that _ are easier to read and replace with sed ;) tests/dsadmin_test.py: I renamed it lib389_test.py, you can merge my changes tests/dsadmin_test.py:39: why remove the addbackend_harn? Humm, to be honest... I do not know how to rename files :-) git mv dsadmin_test.py lib389_test.py ;) :-[ !! so easy :-D tests/replica_test.py:119: you're using Backend.delete in a class that should test just Replica. I would use harness and the standard python-ldap methods in setup/teardown, so that we can change the Backend and Replica class without at least breaking the tests. I miss your point. It is calling in teardown conn.backend.delete, is that the call that is not correct ? That's just an IMHO: see those cases: 1- I change the Backend class and break the replica test: I'll look for errors in Replica while the issue is in Backend 2- somebody works on the Backend class, I work on the Replica one: he can break my tests. Splitting the test stuff in an harness module will reduce the impact of all that. As an example, I could even agree the setup process be done populating entries via an LDIF. If I test Replica, Backend or Suffix I shouldn't have other dependencies distracting me. Is that related to Mock. For example in Replica, we need a suffix and a replica but do not want to rely on them. If instead of creating a real suffix/backend, we have mock of them we could develop the replica tests without any concerns regarding further changes in suffix/backend. Is that your concern ? regards thierry Let me know + Peace, R. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Ocaml rpath issue
On Thu, Oct 24, 2013 at 09:28:53AM -0600, Orion Poplawski wrote: plplot has an OCaml interface, but I see: plplot-ocaml.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/ocaml/stublibs/dllplplot_stubs.so ['/usr/lib64/ocaml', '/builddir/build/BUILD/plplot-5.9.9/fedora/src'] plplot-ocaml.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/ocaml/stublibs/dllplcairo_stubs.so ['/usr/lib64', '/builddir/build/BUILD/plplot-5.9.9/fedora/src'] These files are created with: /usr/bin/ocamlmklib -o plplot_stubs -L/usr/lib64/ocaml -lcamlidl -L/export/home/orion/fedora/plplot/plplot-5.9.10/fedora/src -lplplotd /export/home/orion/fedora/plplot/plplot-5.9.10/fedora/bindings/ocaml/plplot_core_stubs.o /export/home/orion/fedora/plplot/plplot-5.9.10/fedora/bindings/ocaml/plplot_impl.o Should we be doing something different? This could be a bug in one of the OCaml tools. If you have a simple way to reproduce it, then file a bug and I can take a look. If you just want to work around it, run chrpath --delete on the offending files during %install. 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 KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Canonical copy of config.guess/config.sub
W dniu 22.10.2013 17:26, Ralf Corsepius pisze:
Also, automake-based projects receive the versions bundled with
automake, when running automake rsp. autoreconf.
*IF* they run autoreconf. I am working on getting software built for
AArch64 for over a year now. Main issue is all those projects which ship
old, long-time-deprecated copies of config.{guess,sub} files. Sure, they
are new enough for most of architectures and operating systems now in
use but not for new ones.
And %configure macro updates them from /usr/lib/rpm/redhat/ anyway which
covers most of situations but for some we need to copy those files by
hand because authors think that they are smart and do lot of crazy
tricks like:
1. ln -sf ../configure . (so %configure tries . instead of ..)
2. shipping multiple copies of gnu-config files in any random versions
3. shipping both config.{guess,sub} and configure.{guess,sub} with use
of the second ones
And such list can go on and on...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Working Groups: Call for Self-Nominations
On Thu, Oct 24, 2013 at 6:52 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2013-10-24 at 19:56 -0400, Josh Boyer wrote: It is up to each WG to determine their product requirements. That includes which architectures and target users they are trying to produce a product for. We've done a lot of work over the last few cycles to really bump ARM up to 'first class citizen' status, and a lot of that is coming together - I think reasonably successfully - in F19 and F20. It would be rather odd to go with a change for F21 or F22 which goes in the opposite direction. ARM is important long term, yes. I don't necessarily think that ARM is equally important across all of the existing products. I find it more likely that ARM is important enough to have it's own WG and it's own product, which may or may not have commonality with the other products. I'm not entirely sure that makes sense; it seems to be a conceptual error. ARM is an architecture. In practice, at present, the ARM-architecture based hardware we support mostly falls into a certain category that kind of naturally lends itself to a particular kind of product, but that seems a transient scenario, not a permanent one. And if we think the WGs are unable to adapt to transient scenarios, then we've failed. Computing is an ever-changing world. We work with the situation we have today and for the short-term future, and adapt as changes pop up. Looked at conceptually, it doesn't make any more sense for there to be an 'ARM working group' and an 'ARM product' than it does for there to be an 'x86_64 working group' and an 'x86_64 product', but those are, I think, prima facie absurd. The concepts of 'working group' and 'product' Yes, x86_64 as a WG is absurd. It's already widely adopted, commonly availalbe, and used in all 3 of the mainly defined products. ARM is not _yet_. have been drawn up along broadly _functional_ lines, and a 'working group' or 'product' for a specific system architecture doesn't really line up with that design. I think the approach I implied in my email - making sure the functional WGs and products we are inventing do not neglect any of our primary architectures and use cases - is the correct way to go. I think pretending the current class of readily available ARM hardware can fully support the products a WG wants to define is somewhat disingenuous. I'm not saying ARM won't soon, but it's simply not the case today. I fully agree that ARM should be kept in mind during the product creation and included if capable, but I do not think it should necessarily be something that _has_ to be targeted. To get to specifics, I do not foresee the Workstation WG focusing on producing a product that will work equally on ARM. The dearth of workstation style ARM hardware and open graphics drivers would make it even harder to produce that product. This will not always be the case, but it is now and we need products NOW, not whenever ARM catches up. (Please note this is my opinion and does not necessarily reflect that of the WG.) Believe me, I would love to see ARM laptops that were just as functional as x86_64 laptops with full open source software support. Bring them on! We'll adapt as we go. Until then we need to focus on the best target for the products, as defined by the WG. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Could someone help me with writing polkit rule?
It is some time ago it was fighting with polkit, but as far is I remember
you have to
make a .policy file to get pkexec to work right
Like this one I use in yumex.
https://github.com/timlau/yumex/blob/master/misc/dk.yumex.backend.policy.in
It should be installed in /usr/share/polkit-1/actions/
When you can make a rule to bypass the polkit password prompt
Tim
PS.
You can use *cat /var/log/secure | grep polkit * to look for errors
On Fri, Oct 25, 2013 at 11:22 AM, Peter Lemenkov lemen...@gmail.com wrote:
Hello All!
I 'm trying to write a polkit rule which allows every member of a
particular group (ejabberd) to run a specific script
(/sbin/ejabberdctl or /usr/sbin/ejabberdctl). Other users should
not be even able to run it. This sounds simple, so I quickly wrote
this:
http://peter.fedorapeople.org/stuff/ejabberdctl.polkit.rules
I installed it to %{_datadir}/polkit-1/rules.d/51-ejabberdctl.rules,
and added /usr/bin/ejabberdctl which contains just the following:
===
#!/bin/sh
/usr/bin/pkexec /usr/sbin/ejabberdctl $@
===
So when user types ejabberdctl it actually runs /usr/sbin/ejabberdctl
under the polkit supervision. Unfortunately people started reporting
about the issues with the other apps:
* https://bugzilla.redhat.com/show_bug.cgi?id=1009408
I can't find what's wrong with the rule above so I'm calling you for
help. Could please someone help me fixing this mess?
--
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Canonical copy of config.guess/config.sub
On 10/25/2013 12:07 PM, Marcin Juszkiewicz wrote:
W dniu 22.10.2013 17:26, Ralf Corsepius pisze:
Also, automake-based projects receive the versions bundled with
automake, when running automake rsp. autoreconf.
*IF* they run autoreconf. I am working on getting software built for
AArch64 for over a year now. Main issue is all those projects which ship
old, long-time-deprecated copies of config.{guess,sub} files. Sure, they
are new enough for most of architectures and operating systems now in
use but not for new ones.
And %configure macro updates them from /usr/lib/rpm/redhat/ anyway which
covers most of situations but for some we need to copy those files by
hand because authors think that they are smart and do lot of crazy
tricks like:
1. ln -sf ../configure . (so %configure tries . instead of ..)
2. shipping multiple copies of gnu-config files in any random versions
3. shipping both config.{guess,sub} and configure.{guess,sub} with use
of the second ones
And such list can go on and on...
Brent Baude from IBM has proposed a bit of a different approach a few
days ago on the secondary mailing list for their work and bring up of
Power 64bit Little endian:
https://lists.fedoraproject.org/pipermail/secondary/2013-October/002628.html
A very brief summary of what they did was that, instead of tackling the
problem on the autoFOO and libtool side they modified the linker itself
to always claim to be able to generate shared libraries, even if the
arch was actually wrong. In a confined and controlled environment where
you control the linker and the linker actually really KNOWS it can
generate correct shared libraries for that arch this works just as well.
The huge benefit here is that you only need to modify the linker,
everything else afterwards simply falls into place and just works(tm).
They have already tried this with a large number of packages and haven't
seen a single issue with that approach.
Obviously you'd want this as a temporary solution until either Florian's
approach would get adopted and shared by upstream libtool or the
majority of packages have gotten an upstream update that picked up the
latest config.sub and config.guess to work properly on your new
architecture.
Just some food for thought.
Thanks regards, Phil
--
Philipp Knirsch | Tel.: +49-711-96437-470
Manager Core Services| Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com
Wankelstrasse 5 | Web: http://www.redhat.com/
D-70563 Stuttgart, Germany
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Could someone help me with writing polkit rule?
2013/10/25 tim.laurid...@gmail.com tim.laurid...@gmail.com: It is some time ago it was fighting with polkit, but as far is I remember you have to make a .policy file to get pkexec to work right Like this one I use in yumex. https://github.com/timlau/yumex/blob/master/misc/dk.yumex.backend.policy.in It should be installed in /usr/share/polkit-1/actions/ When you can make a rule to bypass the polkit password prompt Do I need both - /usr/share/polkit-1/actions/*.policy and /usr/share/polkit-1/rules.d/*.rules ? -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Announcing the Fedora Server Working Group
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tl;dr The Server Working Group has been formed and will be meeting on Wednesday. See the == Logistical Information == section below for details. == General Announcement == As most of you are aware, the Fedora Project is embarking upon a new venture. Traditionally, the Fedora Project has been a bag of bits collection of packages that attempted to serve everyone's needs simulataneously. As time has passed, we've discovered that when you try to please everyone at once, you usually fail to please anyone at all. Starting at Flock, a new proposal was born: Instead of One Fedora Project to Rule Them All, why don't we try building three Fedora Operating Systems from the packages in the Fedora Project. These three operating systems (dubbed Fedora Server, Fedora Workstation and Fedora Cloud, initially) were discussed at length, then ultimately proposed to the Fedora Project Advisory Board, who gave the go-ahead to start implementation. We spent about a month eliciting calls for volunteers to serve on five Working Groups. There is one group built around the planning and execution of each of these new Fedora Products and then the Base Design group, which will be responsible for ensuring that the products share a common core and an Environments and Stacks group that will investigate how best to deploy software from the larger Fedora Project ecosystem atop these new Fedora Products. Part of the planning process for these new working groups was for us to set up an initial voting membership who has two initial responsibilities[1]: 1) Establish a governance charter - determine how to run the Working Group and elect voting members. This charter is due on November 15, 2013 and must be ratified by FESCo. 2) Produce a Product Requirements Document (PRD) - This is a statement of target audience and the role of the project (what problems it will solve and what niche it will fill). This is a high-level view of the Product. This document is due in January, 2014 and must be ratified by the Fedora Advisory Board. To talk a little bit about the voting membership. It should be noted that these are NOT the only members of the Server WG that can participate. We strongly encourage the participation of all of the larger Server SIG in this effort. Ultimately, the voting membership will be the ones to make (and vote on) final decisions, particularly in the case of controversy or disagreement. This should never be done without careful consideration of all the facts. The initial voting membership was selected by the FESCo coordinator (me, Stephen Gallagher). * Jim Perrin: He will bring to the table an idea of what the CentOS project would want to see in CentOS 8 for its constituency (which is notably different from Red Hat's consumers, despite sharing a common code ancestry) * David Strauss: He maintains a large existing deployment of Fedora servers in production and will be able to help us identify its strengths and weaknesses when used in such a manner. * Truong Anh. Tuan: Representing the Fedora Ambassadors, he will be aiding us in producing information that will be useful when talking about this new product in public. * Máirín Duffy: As the representative from the Fedora Design Team, she will be invaluable in all conversations planning for the user experience and product announcements. * Kevin Fenzi: Representing Fedora Infrastructure, he will hopefully keep us grounded in what we can or cannot accomplish in a particular period of time (as well as having a wealth of knowledge around real-world deployment scenarios). He is also a member of FESCo, though not acting as coordinator. * Miloslav Trmač: Red Hat security engineer who no doubt work tirelessly to ensure that we ship a product that is tightly controlled and properly maintained, as well as representing other low-level security decisions. He is also a member of FESCo, though not acting as coordinator. * Simo Sorce: Red Hat engineer representing the identity and policy management space. His experience with both FreeIPA and Active Directory will be invaluable as we work out how to coordinate Fedora Server in heterogenous environments. * Jóhann B. Guðmundsson: Representing the Fedora QA team, I expect Jóhann to focus primarily on working to make sure that we do not make life any more difficult for testers than we strictly must. == Logistical Information == This logistical information is a proposal. We may decide to change some or all of it as a result of the first meeting of the voting membership. This meeting will take place in #fedora-meeting-1 on Wednesday, November 30 at 17:00 UTC (13:00 EDT, 19:00 CZ). This is immediately prior to the FESCo meeting at 18:00 UTC, so we will have a strict one-hour limit on this meeting. Mailing List: ser...@lists.fedoraproject.org IRC Channel: #fedora-server on Freenode [1]
Re: systemd no longer creating /var/log/journal?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/24/2013 08:15 PM, Adam Williamson wrote:
On Thu, 2013-10-17 at 08:55 -0500, Rex Dieter wrote:
Matthew Miller wrote:
Back in May, the systemd package was changed to enable journal
persistancy by default, by creating /var/log/journal.
that dir should be owned by systemd:
repoquery --whatprovides /var/log/journal systemd-0:208-2.fc20.x86_64
it is on my f20 box, systemd.spec in master/ branch has proper
creation/ownership too:
%dir %{_localstatedir}/log/journal
Is that folder getting deleted for you somehow?
I've seen some interesting AVCs in images I've built / installs I've done
recently:
[3.494655] type=1400 audit(1382659969.717:4): avc: denied { setattr }
for pid=419 comm=systemd-tmpfile name=journal dev=dm-1 ino=391755
scontext=system_u:system_r:systemd_tmpfiles_t:s0
tcontext=system_u:object_r:var_log_t:s0 tclass=dir [3.513159] type=1400
audit(1382659969.737:5): avc: denied { setattr } for pid=419
comm=systemd-tmpfile name=1a57b8c4d8764583b84c8a8faec7f995 dev=dm-1
ino=392555 scontext=system_u:system_r:systemd_tmpfiles_t:s0
tcontext=system_u:object_r:var_log_t:s0 tclass=dir
/var/log/journal does still exist on that install, but still, it's
interesting, and may be more of a problem on cloud images than it is on a
'regular' install somehow.
Just checked a fix in for this, should be in the next policy build.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJqYDgACgkQrlYvE4MpobP7cgCgk931Wz4cHEzQ/ZL8AIJnYCFT
G0IAnRCnZ1uLug/IaUFBqW6L+wwtGSPZ
=X8Zb
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-20 Branched report: 20131025 changes
Compose started at Fri Oct 25 09:15:03 UTC 2013 Broken deps for armhfp -- [blueman] blueman-1.23-7.fc20.armv7hl requires obex-data-server = 0:0.4.3 blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp [bwm-ng] bwm-ng-0.6-11.1.fc20.armv7hl requires libstatgrab.so.9 [cloud-init] cloud-init-0.7.2-7.fc20.noarch requires dmidecode [cobbler] cobbler-2.4.0-2.fc20.noarch requires syslinux [condor-wallaby] condor-wallaby-client-5.0.3-4.fc20.noarch requires python-qmf = 0:0.9.1073306 [fts] fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14 [glpi] glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Version glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Stdlib glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-ServiceManager glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Loader glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-I18n glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache-apc glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache [gnome-do-plugins] gnome-do-plugins-thunderbird-0.8.4-14.fc20.armv7hl requires thunderbird [gofer] ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) = 0:0.16.0 [gradle] gradle-1.0-18.fc20.noarch requires plexus-container-default [grass] grass-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so grass-libs-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so [gtkd] gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 0:2.0.0-29.20120815git9ae9181.fc18 [gxine] gxine-0.5.907-10.fc20.armv7hl requires libxine.so.1 [kawa] 1:kawa-1.11-5.fc19.armv7hl requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0 [monotone] monotone-1.0-11.fc19.armv7hl requires libbotan-1.8.2.so perl-Monotone-1.0-11.fc19.armv7hl requires perl(:MODULE_COMPAT_5.16.2) [mozilla-firetray] mozilla-firetray-thunderbird-0.3.6-0.5.143svn.fc18.1.armv7hl requires thunderbird = 0:11 [msp430-libc] msp430-libc-20120224-2.fc19.noarch requires msp430-gcc = 0:4.6.3 [nifti2dicom] nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10 [nocpulse-common] nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI) [openbox] gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel [openpts] openpts-0.2.6-7.fc20.armv7hl requires tboot [osm2pgsql] osm2pgsql-0.82.0-1.fc20.armv7hl requires libgeos-3.3.8.so [oyranos] oyranos-libs-0.4.0-7.fc19.armv7hl requires libraw.so.5 [perl-BerkeleyDB] perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21 [perl-Language-Expr] perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [perl-MIME-Lite-HTML] perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [perl-Padre] perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [pure] pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20 [python-tag] python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0 [rootplot] rootplot-2.2.1-7.fc19.noarch requires root-python [ruby-spqr] ruby-spqr-0.3.6-7.fc20.noarch requires ruby-qpid-qmf [rubygem-audited-activerecord] rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires rubygem(activerecord) 0:4 [rubygem-fog] rubygem-fog-1.11.1-1.fc20.noarch
Re: Could someone help me with writing polkit rule?
On 25 October 2013 11:22, Peter Lemenkov lemen...@gmail.com wrote:
Hello All!
I 'm trying to write a polkit rule which allows every member of a
particular group (ejabberd) to run a specific script
(/sbin/ejabberdctl or /usr/sbin/ejabberdctl). Other users should
not be even able to run it. This sounds simple, so I quickly wrote
this:
http://peter.fedorapeople.org/stuff/ejabberdctl.polkit.rules
I am not an expert on javascript or polkit, but IINM the second if
rule has wrong syntax, it should be:
if( subject.isInGroup(ejabberd) ) {
return polkit.Result.YES;
}
also, it doesn't need an else bit.
I think you can merge the second if with the first one:
polkit.addRule(function(action, subject) {
var CommandLine = action.lookup(command_line).split( );
if ( action.id == org.freedesktop.policykit.exec (CommandLine[0]
== /sbin/ejabberdctl || CommandLine[0] == /usr/sbin/ejabberdctl)
subject.isInGroup(ejabberd) ) {
return polkit.Result.YES;
}
});
(I could be very wrong though).
I installed it to %{_datadir}/polkit-1/rules.d/51-ejabberdctl.rules,
and added /usr/bin/ejabberdctl which contains just the following:
===
#!/bin/sh
/usr/bin/pkexec /usr/sbin/ejabberdctl $@
===
So when user types ejabberdctl it actually runs /usr/sbin/ejabberdctl
under the polkit supervision. Unfortunately people started reporting
about the issues with the other apps:
* https://bugzilla.redhat.com/show_bug.cgi?id=1009408
I can't find what's wrong with the rule above so I'm calling you for
help. Could please someone help me fixing this mess?
--
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Ahmad Samir
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Could someone help me with writing polkit rule?
Yes, I think so The policy is to config pkexec to run something as root The rule is to make the group get permission without having to enter a root/admin password Tim On Fri, Oct 25, 2013 at 2:08 PM, Peter Lemenkov lemen...@gmail.com wrote: 2013/10/25 tim.laurid...@gmail.com tim.laurid...@gmail.com: It is some time ago it was fighting with polkit, but as far is I remember you have to make a .policy file to get pkexec to work right Like this one I use in yumex. https://github.com/timlau/yumex/blob/master/misc/dk.yumex.backend.policy.in It should be installed in /usr/share/polkit-1/actions/ When you can make a rule to bypass the polkit password prompt Do I need both - /usr/share/polkit-1/actions/*.policy and /usr/share/polkit-1/rules.d/*.rules ? -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Graphics driver support in F21+
On Thu, Oct 24, 2013 at 04:41:09PM -0400, Adam Jackson wrote: One other detail: the intel driver currently has both UMS support for the i810 chipset, and KMS support for everything newer. To be consistent with the above changes I'll be dropping the i810 support, which will then fall back to vesa. This is done, too. Given that the i810/815 chipsets max out at 512MB RAM (and even then only under specific module combinations) there's no real loss there.. - Solomon -- Solomon Peachy pizza at shaftnet dot org Delray Beach, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum viditur. pgpjc4SkS2vy3.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Archive-Tar] 1.96 bump
commit 5e20537859185e91df105615066366f610656aaf
Author: Jitka Plesnikova jples...@redhat.com
Date: Fri Oct 25 15:15:58 2013 +0200
1.96 bump
.gitignore|1 +
perl-Archive-Tar.spec | 10 ++
sources |2 +-
3 files changed, 8 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index f5d55d7..5abafcc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@ Archive-Tar-1.64.tar.gz
/Archive-Tar-1.88.tar.gz
/Archive-Tar-1.90.tar.gz
/Archive-Tar-1.92.tar.gz
+/Archive-Tar-1.96.tar.gz
diff --git a/perl-Archive-Tar.spec b/perl-Archive-Tar.spec
index d611b9b..7cd83b6 100644
--- a/perl-Archive-Tar.spec
+++ b/perl-Archive-Tar.spec
@@ -1,6 +1,6 @@
Name: perl-Archive-Tar
-Version:1.92
-Release:4%{?dist}
+Version:1.96
+Release:1%{?dist}
Summary:A module for Perl manipulation of .tar files
Group: Development/Libraries
License:GPL+ or Artistic
@@ -31,7 +31,6 @@ BuildRequires: perl(IO::File)
BuildRequires: perl(IO::String)
BuildRequires: perl(IO::Zlib) = 1.01
BuildRequires: perl(lib)
-BuildRequires: perl(Package::Constants)
BuildRequires: perl(strict)
BuildRequires: perl(Test::Harness) = 2.26
BuildRequires: perl(Test::More)
@@ -74,6 +73,9 @@ make test
%changelog
+* Fri Oct 25 2013 Jitka Plesnikova jples...@redhat.com - 1.96-1
+- 1.96 bump
+
* Wed Aug 14 2013 Jitka Plesnikova jples...@redhat.com - 1.92-4
- Perl 5.18 re-rebuild of bootstrapped packages
@@ -179,7 +181,7 @@ make test
* Wed Mar 08 2006 Jason Vas Dias jvd...@redhat.com - 1.29-1
- Upgrade to upstream version 1.29
-* Fri Feb 02 2006 Jason Vas Dias jvd...@redhat.com - 1.28-1
+* Fri Feb 03 2006 Jason Vas Dias jvd...@redhat.com - 1.28-1
- Upgrade to upstream version 1.28
- Rebuild for perl-5.8.8
diff --git a/sources b/sources
index 94040a5..e1add90 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8d24ebfc08dbe908d5b0192e4f6459dc Archive-Tar-1.92.tar.gz
+e480708fa215fb3778523d73682c4af8 Archive-Tar-1.96.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
EPEL Update Netdisco RPMs
Hello, I would like to use a recent version of Netdisco on CentOS 5 but I see that EPEL still has: netdisco-1.1-1.el5.noarch.rpm which is quite old. In the past I had upgraded from Netdisco 1.0 to 1.1 using the above package, but I had serious problems with it (I would conclude that the package is OK with new installs but it does not handle upgrades correctly). You may see: http://sourceforge.net/mailarchive/forum.php?thread_name=4EE1FD3B.4080603%40admin.noa.grforum_name=netdisco-users ...for more details. I could try to build an RPM using netdisco 1.3.2 (latest stable release: http://sourceforge.net/projects/netdisco/files/netdisco/1.3.2/) source code and: netdisco-1.1-1.el5.src.rpm but I am afraid that, even if the build is successful, I'll probably have the same problem again when upgrading. I've noticed that the above packages were built by goul...@fedoraproject.org. So, not being an expert myself to check and possibly modify the SRC RPM file (spec file and any required patches), I would appreciate it if the original author or someone else is in a position to help in preparing a current Netdisco RPM. Please let me know what should I do to assist this process. Best regards and thanks in advance, Nick ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: communications and community [was Re: Lack of response about sponsorship]
On Thu, 24 Oct 2013 18:23:49 -0700, Adam Williamson wrote: On Mon, 2013-10-21 at 18:08 +0200, Michael Schwendt wrote: The intended usage of test list has always been a problem. Once in a while, somebody points that out, but there's nobody (no leadership) to work on a change actively. Is it only for Test releases or also for Rawhide? Its description is vague. Is there not any testing and quality assurance for non-Test releases? Huh. I don't remember this ever coming up as a problem before, but I could've drunk away the memory. As far as I know it's the QA list; it covers testing of Fedora, so yes, it covers Rawhide use, in fact discussion of Rawhide use is quite a common topic area for test@. Do you have any references for its purpose being considered unclear? The split and intended usage has been questioned by several community members for many years, even already when the lists where still on Red Hat's servers. Locating such comments with a search engine isn't easy. The people who've pointed out the confusion about which list to choose when haven't drunk away their memory and could join here, but that will be fruitless if an instance such as FESCo decides otherwise. -maintainers list has been closed by FESCo for the same reasons, despite disagreement by community members: https://lists.fedoraproject.org/pipermail/devel/2007-September/109577.html In that thread, there's a comment about closing fedora-test-list *and* fedora-packaging-list in favour of fedora-devel-list: https://lists.fedoraproject.org/pipermail/devel/2007-September/109591.html To which I agreed, because in 2007 and earlier we've had problems with these two competing lists: https://lists.fedoraproject.org/pipermail/devel/2007-September/109624.html Here's a reference that confirms past attempts at improving the list descriptions and intended usage: https://lists.fedoraproject.org/pipermail/devel/2007-September/109625.html https://fedoraproject.org/wiki/Releases/Rawhide#Mailing_Lists | Rawhide discussion is on topic and welcome in both the test and devel lists. D'oh! ;-) The Rawhide report being posted to both lists is the same problem. https://www.redhat.com/archives/fedora-test-list/2003-November/msg01148.html | Hmmm, shouldn't this be discussed on fedora-devel-list though? ;-) There are more. I just cannot spend more time on locating them. Similarly, users of fedora list, who enable updates-testing, get asked whether they should have posted to test list instead. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: EPEL Update Netdisco RPMs
On 10/25/2013 03:19 PM, Nikolaos Milas wrote: Hello, I would like to use a recent version of Netdisco on CentOS 5 but I see that EPEL still has: netdisco-1.1-1.el5.noarch.rpm which is quite old. In the past I had upgraded from Netdisco 1.0 to 1.1 using the above package, but I had serious problems with it (I would conclude that the package is OK with new installs but it does not handle upgrades correctly). You may see: http://sourceforge.net/mailarchive/forum.php?thread_name=4EE1FD3B.4080603%40admin.noa.grforum_name=netdisco-users ...for more details. I could try to build an RPM using netdisco 1.3.2 (latest stable release: http://sourceforge.net/projects/netdisco/files/netdisco/1.3.2/) source code and: netdisco-1.1-1.el5.src.rpm but I am afraid that, even if the build is successful, I'll probably have the same problem again when upgrading. I've noticed that the above packages were built by goul...@fedoraproject.org. So, not being an expert myself to check and possibly modify the SRC RPM file (spec file and any required patches), I would appreciate it if the original author or someone else is in a position to help in preparing a current Netdisco RPM. Please let me know what should I do to assist this process. Best regards and thanks in advance, Nick ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel Please file a bugzilla ticket for upgrading to the new version in Fedora as well, while you're at it. My advice would have been to rebuild that, but unfortunately it's not up to date either. Volker Fröhlich ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Review swap
On Thu, Oct 24, 2013 at 07:40:59AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Oct 23, 2013 at 11:34:23AM -0400, Darryl L. Pierce wrote: I have a package review (BZ#1022584:Review Request: qpid-qmf - The QPID Management Framework). I pulled the subpackages from qpid-cpp relating to QMF so they can built completely separate from Qpid. I'll take this one. I'm looking for reviewers for Bug 1016677 - Review Request: mathjax - JavaScript library to render math in the browser Bug 1021164 - Review Request: general-purpose-preprocessor - Customizable language-agnostic preprocessor Danga, you and Brandon beat me to the punch for swapping reviews! Anybody have a review I can take on to review it forward? :) -- Darryl L. Pierce mcpie...@gmail.com http://mcpierce.fedorapeople.org/ What do you care what people think, Mr. Feynman? pgp7iWSsN7hKT.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: communications and community [was Re: Lack of response about sponsorship]
On Fri, Oct 25, 2013 at 04:02:23PM +0200, Michael Schwendt wrote: The people who've pointed out the confusion about which list to choose when haven't drunk away their memory and could join here, but that will be fruitless if an instance such as FESCo decides otherwise. So, here's what I'd like to see. Collapse all lists to just four: * Fedora Users * Fedora Development - includes testing * Fedora Announcments - low traffic, big official announcements only * Auto-generated Reports - and probably tickets which go to a list; these things are useful to the people who want them but overall lower signal-to-noise ratio Which sounds a little dramatic, but we would start making heavy use of the mailman topics/keywords features to sort into meaningful sub-categories. I understand that hyperkitty will make this nice and easy, but it's also not really very hard just as email. Note that you can subscribe to just certain topics, if you are not interested in certain areas. We can still host other lists are focused around one clear goal (like development of a hosted project), but encourage most discussion to be on one of the main lists. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review swap
I also have plenty of packages: Re-review request of mlmmj: https://bugzilla.redhat.com/show_bug.cgi?id=995933 herbstluftwm - A manual tiling window manager: https://bugzilla.redhat.com/show_bug.cgi?id=1001407 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Text-Autoformat] Update to 1.669004
commit c189a753f8924b43f912fcde2525c768e4164e96
Author: Paul Howarth p...@city-fan.org
Date: Fri Oct 25 16:01:59 2013 +0100
Update to 1.669004
- New upstream release 1.669004
- Tweaked widow handling to avoid a nasty edge case
- Specify all dependencies
- Replace provides filter with a patch that works right back to EL-5
- Don't need to remove empty directories from the buildroot
- Drop %defattr, redundant since rpm 4.4
- Make %files list more explicit
- Don't use macros for commands
.gitignore |3 +-
Text-Autoformat-1.669004-provides.patch | 26 +
Text-Autoformat-filter-provides.sh |4 --
perl-Text-Autoformat.spec | 63 +++
sources |2 +-
5 files changed, 67 insertions(+), 31 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4965030..0a32bb0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1 @@
-Text-Autoformat-v1.14.0.tar.gz
-/Text-Autoformat-1.669002.tar.gz
+/Text-Autoformat-[0-9.]*.tar.gz
diff --git a/Text-Autoformat-1.669004-provides.patch
b/Text-Autoformat-1.669004-provides.patch
new file mode 100644
index 000..39e269b
--- /dev/null
+++ b/Text-Autoformat-1.669004-provides.patch
@@ -0,0 +1,26 @@
+Separating package and package names by a newline results in
+rpm provides not being generated for the package, which is
+exactly what we want in these cases, as they're private modules.
+
+--- lib/Text/Autoformat.pm
lib/Text/Autoformat.pm
+@@ -649,7 +649,8 @@
+ return 1;
+ }
+
+-package Hang;
++package # hide from rpm
++Hang;
+ use strict;
+
+ # ROMAN NUMERALS
+@@ -851,7 +852,8 @@
+
+ sub empty { 0 }
+
+-package NullHang;
++package # hide from rpm
++NullHang;
+ use strict;
+
+ sub new { bless {}, $_[0] }
diff --git a/perl-Text-Autoformat.spec b/perl-Text-Autoformat.spec
index 608c1bd..909ccb5 100644
--- a/perl-Text-Autoformat.spec
+++ b/perl-Text-Autoformat.spec
@@ -1,23 +1,31 @@
Name: perl-Text-Autoformat
-Version:1.669002
-Release:9%{?dist}
+Version:1.669004
+Release:1%{?dist}
Summary:Automatic text wrapping and reformatting
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Text-Autoformat/
Source0:
http://www.cpan.org/authors/id/D/DC/DCONWAY/Text-Autoformat-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Patch0: Text-Autoformat-1.669004-provides.patch
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
+# Module Build
BuildRequires: perl(Module::Build)
-BuildRequires: perl(Test::More)
+BuildRequires: perl(warnings)
+# Module Runtime
+BuildRequires: perl(Carp)
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(overload)
+BuildRequires: perl(strict)
BuildRequires: perl(Text::Reform) = 1.11
-BuildRequires: perl(version)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-
-# Filter out perl(Hang) and perl(NullHang) auto-provides.
-Source99: Text-Autoformat-filter-provides.sh
-%global real_perl_provides %{__perl_provides}
-%define __perl_provides %{_tmppath}/%{name}-%{version}-%{release}-%(%{__id_u}
-n)-filter-provides
+BuildRequires: perl(Text::Tabs)
+BuildRequires: perl(utf8)
+BuildRequires: perl(vars)
+# Test Suite
+BuildRequires: perl(Test::More)
+# Runtime
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
Text::Autoformat provides intelligent formatting of plaintext without the
@@ -32,37 +40,44 @@ the built-in Perl format() mechanism.
%prep
%setup -q -n Text-Autoformat-%{version}
-chmod a-x lib/Text/Autoformat.pm Changes README
-sed -e 's,@@PERL_PROV@@,%{real_perl_provides},' %{SOURCE99}
%{__perl_provides}
-chmod +x %{__perl_provides}
+# Drop bogus exec bits
+chmod -c -x config.*
+
+# Hide private modules from rpm
+%patch0
%build
-%{__perl} Build.PL installdirs=vendor
+perl Build.PL installdirs=vendor
./Build
%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/*
+%{_fixperms} $RPM_BUILD_ROOT
%check
./Build test
%clean
-rm -rf $RPM_BUILD_ROOT %{__perl_provides}
+rm -rf $RPM_BUILD_ROOT
%files
-%defattr(-,root,root,-)
%doc Changes README config.emacs config.vim
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%{perl_vendorlib}/Text/
+%{_mandir}/man3/Text::Autoformat.3pm*
%changelog
+* Fri Oct 25 2013 Paul Howarth p...@city-fan.org - 1.669004-1
+- Update to 1.669004
+ - Tweaked widow handling to avoid a nasty edge case
+- Specify all dependencies
+- Replace provides filter with a patch that works right back to EL-5
+- Don't need to remove empty directories
Re: Review swap
On Fri, Oct 25, 2013 at 10:58:02PM +0800, Christopher Meng wrote: I also have plenty of packages: Re-review request of mlmmj: https://bugzilla.redhat.com/show_bug.cgi?id=995933 Nabbed! :) -- Darryl L. Pierce mcpie...@gmail.com http://mcpierce.fedorapeople.org/ What do you care what people think, Mr. Feynman? pgpqXE9FOqX9C.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Announcing the Environment and Stacks Working Group
I'd like to introduce to you Environment and Stack group. From our first round of emails it looks like we will work on interpreted languages, databases, software collections... We'd like to setup good environment for developers and admins and give other groups good environment for their work. Our group didn't speak about any regular meetings and if we have some, it will be hard to plan time, because we are spread in many time-zones. I asked for new mailing list called env-and-stacks. I hope it's fine with all members of this group, I felt there was wish to have dedicated mailing list for the group. As soon as mailing list is created, we will start working on our product requirement document. Currently, some members are working on: * SCL in Fedora * Python3 as default And I guess everyone has an idea what can be improved in his/her area of expertise or how can be improved or changed tooling, which we are using. Let's meet on new mailing lists with your ideas. The initial voting membership was selected by the FESCo coordinator (me, Marcela Mašláňová). There are more members of the group and it would be good if even more people join the discussion. * Toshio Kuratomi as member of FPC and infrastructure he can help with guidelines and changes in infrastructure. * Petr Kovar Technical writer at Red Hat, working on RPM and Software Collections documentation. Long-time contributor to Fedora and GNOME documentation, i18n l10n and related fields. He'd like to focus on providing good packaging documentation for Fedora contributors and users. * Tadej Janež Pythonista who would like to help in making Fedora the most attractive platform for upstream Python projects and developers. * Sam Kottler As a member of the Rubygems + Bundler core teams, he'd like to help make the Ruby stack on Fedora more robust and have a particular interest in integrating the runtime more tightly with SCL. * Slavek Kabrda Python maintainer, packager, developer of pyp2rpm and spec2scl. His interest is integrating Software Collections into Fedora and make them useful for wide community. Most experience packager of SCLs. * John Dulaney Representing the Fedora QA. * Honza Horak Databases team lead in Red Hat, package (co-)maintainer of several databases. He will try to find a way to offer both stability and new features within databases area. * Jens Petersen Haskell SIG, i18n Project, Proven Packager and Tester. He would like to help strengthen the support for Functional Programming Languages and the general Fedora software developer experience, and in particular to make it easier to package for modern programming languages for Fedora. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: communications and community [was Re: Lack of response about sponsorship]
On Tue, 22 Oct 2013 16:17:14 -0400, Bill Nottingham wrote: I would think that if we are in a situation where people who do development don't subscribe to the devel list because of 'energy' reasons (disillusionment, feelings of either a) pointlessness b) fait-accompli, etc.), then just moving things to -announce is not actually solving the problem. Isn't it similar with bugzilla.redhat.com and package maintainers not responding to the hundreds of problem reports they receive there? There even is a separate Fedora list for glibc these days, with seldomly many more than half a dozen messages per month: https://admin.fedoraproject.org/mailman/listinfo/glibc An own list for Zarafa, with not even a single post per month: https://lists.fedoraproject.org/pipermail/zarafa/ A brand-new one for gnome, created on Sep 17th, with no more than the custom Welcome message: https://lists.fedoraproject.org/pipermail/gnome/ Not even sure how that one relates to desktop list, which has had its peak activity with 223 messages in March 2013, but doesn't have a description: https://lists.fedoraproject.org/pipermail/desktop/ There are more examples at: https://lists.fedoraproject.org/mailman/listinfo Lists, which have been created because of too much noise and too much traffic on devel list. Devel list is the dumping ground. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Text-Diff-HTML] Created tag perl-Text-Diff-HTML-0.07-1.fc20
The lightweight tag 'perl-Text-Diff-HTML-0.07-1.fc20' was created pointing to: cc10542... Update to 0.07 -- 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-Text-Diff-HTML] Created tag perl-Text-Diff-HTML-0.07-1.fc21
The lightweight tag 'perl-Text-Diff-HTML-0.07-1.fc21' was created pointing to: cc10542... Update to 0.07 -- 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: Review swap
On 10/25/2013 04:12 PM, Darryl L. Pierce wrote: On Thu, Oct 24, 2013 at 07:40:59AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Oct 23, 2013 at 11:34:23AM -0400, Darryl L. Pierce wrote: I have a package review (BZ#1022584:Review Request: qpid-qmf - The QPID Management Framework). I pulled the subpackages from qpid-cpp relating to QMF so they can built completely separate from Qpid. I'll take this one. I'm looking for reviewers for Bug 1016677 - Review Request: mathjax - JavaScript library to render math in the browser Bug 1021164 - Review Request: general-purpose-preprocessor - Customizable language-agnostic preprocessor Danga, you and Brandon beat me to the punch for swapping reviews! Sorry, Darryl. Didn't mean to hijack your request! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Differences between Fakeroot and Mock Suggested method
On Fri, 2013-10-25 at 11:24 +0300, Ville Skyttä wrote: On Fri, Oct 25, 2013 at 2:07 AM, Adam Williamson awill...@redhat.com wrote: The koji builders are usually faster than your system anyway Maybe, if building only a specific arch (e.g. koji build --arch-override=x86_64). The arm builders tend to be quite slow in the first place, You can download the RPMs from any arch as soon as it completes; you don't have to wait for ARM to finish. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: communications and community [was Re: Lack of response about sponsorship]
On Fri, 2013-10-25 at 16:02 +0200, Michael Schwendt wrote: The split and intended usage has been questioned by several community members for many years, even already when the lists where still on Red Hat's servers. Locating such comments with a search engine isn't easy. https://lists.fedoraproject.org/pipermail/devel/2007-September/109577.html https://lists.fedoraproject.org/pipermail/devel/2007-September/109591.html https://lists.fedoraproject.org/pipermail/devel/2007-September/109624.html https://lists.fedoraproject.org/pipermail/devel/2007-September/109625.html https://fedoraproject.org/wiki/Releases/Rawhide#Mailing_Lists | Rawhide discussion is on topic and welcome in both the test and devel lists. https://www.redhat.com/archives/fedora-test-list/2003-November/msg01148.html | Hmmm, shouldn't this be discussed on fedora-devel-list though? ;-) There are more. I just cannot spend more time on locating them. Similarly, users of fedora list, who enable updates-testing, get asked whether they should have posted to test list instead. I can't help noticing that all your references are from a minimum of six years ago, which is, well, quite a long time. Ever since I've joined, which is ohgod nearly five years ago now, the split has seemed reasonably clear and non-controversial, and I really can't recall anyone being particularly confused about it, so perhaps this is a problem which is still current in your mind but obsolete in cold unfeeling reality? :) I think we wind up with more posts that we think would be appropriate for users@ than devel@. To me, at least, test@ has a very clear and specific purpose which is quite different from devel@, and I'd fight with tooth and claw any proposal to 'merge' them. Merging them would be a flat-out disaster for QA work: we have a different atmosphere and much lower traffic on test@, if all our useful and productive QA mails got drowned in the devel@ noise it would have a significant negative impact on our ability to do useful stuff. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: communications and community [was Re: Lack of response about sponsorship]
On Fri, 2013-10-25 at 10:48 -0400, Matthew Miller wrote: On Fri, Oct 25, 2013 at 04:02:23PM +0200, Michael Schwendt wrote: The people who've pointed out the confusion about which list to choose when haven't drunk away their memory and could join here, but that will be fruitless if an instance such as FESCo decides otherwise. So, here's what I'd like to see. Collapse all lists to just four: * Fedora Users * Fedora Development - includes testing * Fedora Announcments - low traffic, big official announcements only * Auto-generated Reports - and probably tickets which go to a list; these things are useful to the people who want them but overall lower signal-to-noise ratio Which sounds a little dramatic, but we would start making heavy use of the mailman topics/keywords features to sort into meaningful sub-categories. I understand that hyperkitty will make this nice and easy, but it's also not really very hard just as email. Note that you can subscribe to just certain topics, if you are not interested in certain areas. So, have fewer lists, but then have what are effectively sub-lists within the lists. Where exactly is the win? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 551 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 65 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11274/ssmtp-2.61-21.el6 26 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11703/chicken-4.8.0.4-4.el6 14 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11785/phpMyAdmin-3.5.8.2-1.el6 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11865/quassel-0.9.1-1.el6 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11817/ReviewBoard-1.7.16-2.el6.1,python-djblets-0.7.21-1.el6 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11880/GraphicsMagick-1.3.18-2.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11883/salt-0.17.1-1.el6 5 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11891/libuv-0.10.18-1.el6,nodejs-0.10.21-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing ProDy-1.4.6-2.el6 erlang-erlsyslog-0.6.2-4.el6 ghc-rpm-macros-0.15.16-1.el6 graphite-web-0.9.12-5.el6 jansson-2.4-3.el6 php-zmq-1.0.8-2.el6 python-carbon-0.9.12-3.el6 python-django-helpdesk-0.1.11-1.el6 transifex-client-0.9-7.el6 wordpress-3.7-1.el6 Details about builds: ProDy-1.4.6-2.el6 (FEDORA-EPEL-2013-11957) Application for protein structure, dynamics and sequence analysis Update Information: New packages. References: [ 1 ] Bug #996222 - Review Request: ProDy - Application for protein structure, dynamics and sequence analysis https://bugzilla.redhat.com/show_bug.cgi?id=996222 erlang-erlsyslog-0.6.2-4.el6 (FEDORA-EPEL-2013-11950) Syslog facility for Erlang Update Information: * Explicitly set up CFLAGS to avoid bogus debuginfo generation - Fix for dynamic verbosity change - Fix for dynamic verbosity change ChangeLog: * Thu Oct 24 2013 Peter Lemenkov lemen...@gmail.com - 0.6.2-4 - Actually allow building proper debuginfo * Thu Oct 24 2013 Peter Lemenkov lemen...@gmail.com - 0.6.2-3 - Rebuild with new erlang_drv_version number - Explicitly set up CFLAGS to avoid bogus debuginfo generation (rhbz #958965) * Sat Aug 3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.6.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild References: [ 1 ] Bug #958965 - erlsyslog 0.6.2-1 not built with $RPM_*_FLAGS, *.so not stripped https://bugzilla.redhat.com/show_bug.cgi?id=958965 ghc-rpm-macros-0.15.16-1.el6 (FEDORA-EPEL-2013-11951) RPM macros for building packages for GHC Update Information: Add %ghcpkgdocdir macro ChangeLog: * Fri Oct 25 2013 Jens Petersen peter...@redhat.com - 0.15.16-1 - add ghcpkgdocdir graphite-web-0.9.12-5.el6 (FEDORA-EPEL-2013-11952) A Django webapp for enterprise scalable realtime graphing Update Information: Patch for fix loading dashboards by name (RHBZ#1014349) Patch for log name of metric that throws exception for CarbonLink (RHBZ#1014349) Add deque to the PICKLE_SAFE filter (RHBZ#1014356) Merge in EL5 conditionals for single spec Remove logrotate configuration as it conflicts with internal log rotation (RHBZ#1008616) ChangeLog: * Tue Oct 1 2013 Jonathan Steffan jstef...@fedoraproject.org - 0.9.12-5 - Patch for fix loading dashboards by name (RHBZ#1014349) - Patch for log name of metric that throws exception for CarbonLink (RHBZ#1014349) - Add deque to the PICKLE_SAFE filter (RHBZ#1014356) - Merge in EL5 conditionals for single spec * Mon Sep 30 2013 Jonathan Steffan jstef...@fedoraproject.org - 0.9.12-4 - Remove logrotate configuration as it conflicts with internal log rotation
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 551 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 65 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11276/ssmtp-2.61-21.el5 41 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11879/scipy-0.6.0-7.el5 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11887/salt-0.17.1-1.el5 5 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing erlang-erlsyslog-0.6.2-4.el5 graphite-web-0.9.12-5.el5 wordpress-3.7-1.el5 Details about builds: erlang-erlsyslog-0.6.2-4.el5 (FEDORA-EPEL-2013-11953) Syslog facility for Erlang Update Information: * Explicitly set up CFLAGS to avoid bogus debuginfo generation - Fix for dynamic verbosity change - Fix for dynamic verbosity change ChangeLog: * Thu Oct 24 2013 Peter Lemenkov lemen...@gmail.com - 0.6.2-4 - Actually allow building proper debuginfo * Thu Oct 24 2013 Peter Lemenkov lemen...@gmail.com - 0.6.2-3 - Rebuild with new erlang_drv_version number - Explicitly set up CFLAGS to avoid bogus debuginfo generation (rhbz #958965) * Sat Aug 3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.6.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild References: [ 1 ] Bug #958965 - erlsyslog 0.6.2-1 not built with $RPM_*_FLAGS, *.so not stripped https://bugzilla.redhat.com/show_bug.cgi?id=958965 graphite-web-0.9.12-5.el5 (FEDORA-EPEL-2013-11958) A Django webapp for enterprise scalable realtime graphing Update Information: Patch for fix loading dashboards by name (RHBZ#1014349) Patch for log name of metric that throws exception for CarbonLink (RHBZ#1014349) Add deque to the PICKLE_SAFE filter (RHBZ#1014356) Merge in EL5 conditionals for single spec Remove logrotate configuration as it conflicts with internal log rotation (RHBZ#1008616) References: [ 1 ] Bug #1008616 - graphite-web cannot use logrotate; conflicts with internal log rotation https://bugzilla.redhat.com/show_bug.cgi?id=1008616 [ 2 ] Bug #1014349 - Backport fixes to graphite-web 0.9.12 https://bugzilla.redhat.com/show_bug.cgi?id=1014349 [ 3 ] Bug #1014356 - graphite-web CarbonLink error: UnpicklingError: Attempting to unpickle unsafe module collections https://bugzilla.redhat.com/show_bug.cgi?id=1014356 wordpress-3.7-1.el5 (FEDORA-EPEL-2013-11956) Blog tool and publishing platform Update Information: * Upstream annoucement: http://wordpress.org/news/2013/10/basie/ * Changes: http://codex.wordpress.org/Version_3.7 ChangeLog: * Fri Oct 25 2013 Remi Collet rcol...@redhat.com - 3.7-1 - update to 3.7 - requires ca-certificates for ca-bundle.crt - drop pre-compiled Flash and Silverlight binaries - #1000267 ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Package EVR problems in Fedora 2013-10-25
Broken upgrade path report for tags f20-updates-testing - f21: PackageKit: f20-updates-testing f21 (PackageKit-0.8.12-1.fc20 PackageKit-0.8.11-3.fc21) ReviewBoard: f20-updates-testing f21 (ReviewBoard-1.7.16-2.fc20 ReviewBoard-1.7.16-1.fc21) aisleriot: f20-updates-testing f21 (1:aisleriot-3.10.1-1.fc20 1:aisleriot-3.10.0-1.fc21) apache-commons-daemon: f20-updates-testing f21 (apache-commons-daemon-1.0.15-4.fc20 apache-commons-daemon-1.0.15-3.fc20) at-spi2-core: f20-updates-testing f21 (at-spi2-core-2.10.1-1.fc20 at-spi2-core-2.10.0-1.fc21) baobab: f20-updates-testing f21 (baobab-3.10.1-1.fc20 baobab-3.10-1.fc21) cheese: f20-updates-testing f21 (2:cheese-3.10.1-1.fc20 2:cheese-3.10.0-1.fc21) cloud-init: f20-updates-testing f21 (cloud-init-0.7.2-7.fc20 cloud-init-0.7.2-4.fc20) control-center: f20-updates-testing f21 (1:control-center-3.10.1-1.fc20 1:control-center-3.10.0-1.fc21) crtools: f20-updates-testing f21 (crtools-0.8-1.fc20 crtools-0.7-1.fc21) diffpdf: f20-updates-testing f21 (diffpdf-2.1.3-2.fc20 diffpdf-2.1.3-1.fc21) drupal7-l10n_client: f20-updates-testing f21 (drupal7-l10n_client-1.3-1.fc20 drupal7-l10n_client-1.2-3.fc20) eclipse-linuxtools: f20-updates-testing f21 (eclipse-linuxtools-2.1.0-3.fc20 eclipse-linuxtools-2.1.0-2.fc21) eclipse-wtp-sourceediting: f20-updates-testing f21 (eclipse-wtp-sourceediting-3.5.1-2.fc20 eclipse-wtp-sourceediting-3.5.1-1.fc21) eog: f20-updates-testing f21 (eog-3.10.1-1.fc20 eog-3.10.0-1.fc21) eog-plugins: f20-updates-testing f21 (eog-plugins-3.10.1-1.fc20 eog-plugins-3.10.0-1.fc21) epiphany: f20-updates-testing f21 (1:epiphany-3.10.1-1.fc20 1:epiphany-3.10.0-1.fc21) fedora-release-notes: f20-updates-testing f21 (fedora-release-notes-20-0.2 fedora-release-notes-20-0.0) fence-agents: f20-updates-testing f21 (fence-agents-4.0.4-3.fc20 fence-agents-4.0.3-1.fc21) file-roller: f20-updates-testing f21 (file-roller-3.10.1-1.fc20 file-roller-3.10.0-1.fc21) firmware-tools: f20-updates-testing f21 (firmware-tools-2.1.15-1.fc20.6 firmware-tools-2.1.15-1.fc20.5) five-or-more: f20-updates-testing f21 (five-or-more-3.10.1-1.fc20 five-or-more-3.10.0-1.fc21) freeipa: f20-updates-testing f21 (freeipa-3.3.2-1.fc20 freeipa-3.3.1-2.fc21) gedit: f20-updates-testing f21 (2:gedit-3.10.1-1.fc20 2:gedit-3.9.92-1.fc21) gedit-plugins: f20-updates-testing f21 (gedit-plugins-3.10.0-1.fc20 gedit-plugins-3.8.3-2.fc20) glib-networking: f20-updates-testing f21 (glib-networking-2.38.1-1.fc20 glib-networking-2.38.0-1.fc21) glib2: f20-updates-testing f21 (glib2-2.38.1-1.fc20 glib2-2.38.0-1.fc21) glibmm24: f20-updates-testing f21 (glibmm24-2.38.0-1.fc20 glibmm24-2.37.93-1.fc21) gnome-backgrounds: f20-updates-testing f21 (gnome-backgrounds-3.10.1-1.fc20 gnome-backgrounds-3.10.0-1.fc21) gnome-chess: f20-updates-testing f21 (gnome-chess-3.10.1.1-1.fc20 gnome-chess-3.10.0-1.fc21) gnome-color-manager: f20-updates-testing f21 (gnome-color-manager-3.10.1-1.fc20 gnome-color-manager-3.10.0-1.fc21) gnome-contacts: f20-updates-testing f21 (gnome-contacts-3.10.1-1.fc20 gnome-contacts-3.10-1.fc21) gnome-desktop3: f20-updates-testing f21 (gnome-desktop3-3.10.1-1.fc20 gnome-desktop3-3.10.0-1.fc21) gnome-devel-docs: f20-updates-testing f21 (gnome-devel-docs-3.10.1-1.fc20 gnome-devel-docs-3.10.0-1.fc21) gnome-dictionary: f20-updates-testing f21 (gnome-dictionary-3.10.0-1.fc20 gnome-dictionary-3.9.0-1.fc21) gnome-icon-theme-symbolic: f20-updates-testing f21 (gnome-icon-theme-symbolic-3.10.1-1.fc20 gnome-icon-theme-symbolic-3.10.0-1.fc21) gnome-initial-setup: f20-updates-testing f21 (gnome-initial-setup-3.10.1.1-1.fc20 gnome-initial-setup-3.10.0.1-1.fc21) gnome-mahjongg: f20-updates-testing f21 (gnome-mahjongg-3.10.1-1.fc20 gnome-mahjongg-3.10.0-1.fc21) gnome-menus: f20-updates-testing f21 (gnome-menus-3.10.1-1.fc20 gnome-menus-3.8.0-3.fc20) gnome-music: f20-updates-testing f21 (gnome-music-3.10.1-1.fc20 gnome-music-3.10.0-1.fc21) gnome-nibbles: f20-updates-testing f21 (gnome-nibbles-3.10.1-1.fc20 gnome-nibbles-3.10.0-1.fc21) gnome-packagekit: f20-updates-testing f21 (gnome-packagekit-3.10.1-1.fc20 gnome-packagekit-3.10.0-2.fc21) gnome-photos: f20-updates-testing f21 (gnome-photos-3.10.1-1.fc20 gnome-photos-3.10.0-1.fc21) gnome-power-manager: f20-updates-testing f21 (gnome-power-manager-3.10.1-1.fc20 gnome-power-manager-3.10.0-1.fc21) gnome-session: f20-updates-testing f21 (gnome-session-3.10.1-1.fc20 gnome-session-3.10.0-1.fc21) gnome-settings-daemon: f20-updates-testing f21 (gnome-settings-daemon-3.10.1-2.fc20 gnome-settings-daemon-3.10.0-3.fc21) gnome-software: f20-updates-testing f21 (gnome-software-3.10.2-1.fc20 gnome-software-3.10.0-1.fc21) gnome-system-monitor: f20-updates-testing f21
Re: communications and community [was Re: Lack of response about sponsorship]
On Fri, 25 Oct 2013 10:40:28 -0700, Adam Williamson wrote: Ever since I've joined, which is ohgod nearly five years ago now, the split has seemed reasonably clear and non-controversial, and I really can't recall anyone being particularly confused about it, so perhaps this is a problem which is still current in your mind but obsolete in cold unfeeling reality? :) This is no real basis for trying to improve anything. I'm not here to fight for anything. If you put it as if I'm the only one, who thinks that the many lists and their purpose is confusing, well, then let's stop. To have two lists about Rawhide (even for the build reports) is the most fundamental mistake already. I think we wind up with more posts that we think would be appropriate for users@ than devel@. To me, at least, test@ has a very clear and specific purpose which is quite different from devel@, So very clear that qa-devel has been split off early this year, after the Fedora QA trac notifications had caused a flood of posts to test list. and I'd fight with tooth and claw any proposal to 'merge' them. Merging them would be a flat-out disaster for QA work: we have a different atmosphere and much lower traffic on test@, if all our useful and productive QA mails got drowned in the devel@ noise it would have a significant negative impact on our ability to do useful stuff. Moving all Rawhide topics, build failures, build report, package version upgrade annoucements, ABI breakage announcements, Branched report, Rawhide report, from devel to test list would be the way to go. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: communications and community [was Re: Lack of response about sponsorship]
On Fri, 2013-10-25 at 21:43 +0200, Michael Schwendt wrote: On Fri, 25 Oct 2013 10:40:28 -0700, Adam Williamson wrote: Ever since I've joined, which is ohgod nearly five years ago now, the split has seemed reasonably clear and non-controversial, and I really can't recall anyone being particularly confused about it, so perhaps this is a problem which is still current in your mind but obsolete in cold unfeeling reality? :) This is no real basis for trying to improve anything. I'm not here to fight for anything. If you put it as if I'm the only one, who thinks that the many lists and their purpose is confusing, well, then let's stop. Well, I don't know which perspective is true for sure, just offering the possibility. To have two lists about Rawhide (even for the build reports) is the most fundamental mistake already. Neither list is really 'about' Rawhide. test is about testing, devel is about development. Obviously, both are going to *involve* Rawhide at some point. But our lists are not per-product lists; we don't have a Rawhide list and an F20 list and an F19 list. They're about topic areas. I'm sure the docs team talks about stuff in Rawhide occasionally too; that doesn't mean their topics should be on the same list as development topics that involve Rawhide and QA topics that involve Rawhide and artwork topics that involve Rawhide... I think we wind up with more posts that we think would be appropriate for users@ than devel@. To me, at least, test@ has a very clear and specific purpose which is quite different from devel@, So very clear that qa-devel has been split off early this year, after the Fedora QA trac notifications had caused a flood of posts to test list. Well, yes? The purpose of the test@ list clearly didn't include those mails, so they were moved. They are clearly also not appropriate for devel@, because they're about QA tooling development. and I'd fight with tooth and claw any proposal to 'merge' them. Merging them would be a flat-out disaster for QA work: we have a different atmosphere and much lower traffic on test@, if all our useful and productive QA mails got drowned in the devel@ noise it would have a significant negative impact on our ability to do useful stuff. Moving all Rawhide topics, build failures, build report, package version upgrade annoucements, ABI breakage announcements, Branched report, Rawhide report, from devel to test list would be the way to go. Well, no it wouldn't, because most of those mails are relevant to *developers* (or rather, packagers), not testers. Which is why they're sent to devel@. Build failures are fixed by packagers. ABI bumps are fixed by packagers. The errors identified on the Branched and Rawhide reports are fixed by packagers. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [389-devel] Proof of concept: mocking DS in lib389
On 10/25/2013 01:36 PM, Jan Rusnacko wrote: Hello Roberto and Thierry, as I promised, I am sending you a proof-of-concept code that demonstrates, how we can mock DS in unit tests for library function (see attachment). You can run tests just by executing py.test in tests directory. Only 3 files are of interest here: lib389/dsmodules/repl.py - this is a Python module with functions - they expect DS instance as the first argument. Since they are functions, not methods, I can just mock DS and pass that fake one as the first argument to them in unit tests. tests/test_dsmodules/conftest.py - this file contains definition of mock DS class along with py.test fixture, that returns it. tests/test_dsmodules/test_repl.py - this contains unit tests for functions from repl.py. What I do is quite simple - I override ldapadd, ldapdelete .. methods of mock DS class, so that instead of sending command to real DS instance, they just store the data in 'dit' dictionary (which represents content stored in DS). This way, I can check that when I call e.g. function enable_changelog(..), in the end DS will have correct changelog entry. To put it very bluntly - enable_changelog(..) function just adds correct changelog entry to whatever is passed to it as the first argument. In unit tests, it is mock DS, otherwise it would be real DS class that sends real ldap commands to real DS instance behind. def test_add_repl_manager(fake_ds_inst_with_repl): ds_inst = fake_ds_inst_with_repl ds_inst.repl.add_repl_manager(cn=replication manager, cn=config, Secret123) assert ds_inst.dit[cn=replication manager, cn=config][userPassword] == Secret123 assert ds_inst.dit[cn=replication manager, cn=config][nsIdleTimeout] == 0 assert ds_inst.dit[cn=replication manager, cn=config][cn] == replication manager If you are using a real directory server instance, doing add_repl_manager() is going to make a real LDAP ADD request, right? Will it still update the ds_inst.dit dict? Wouldn't you have to do a real LDAP Search request to get the actual values? Now I can successfully test that enable_changelog really works, without going into trouble defining DSInstance or ldap calls at all. Also, I believe this approach would work for 95% of all functions in lib389. Another benefit is that unit tests are much faster, than on real DS instance. Sidenote: even though everything is defined in separate namespace of 'repl' module as function, in runtime they can be used as normal methods of class DSInstance. That is handled by DSModuleProxy. We already went through this, but not with Roberto. Hopefully, now with some code in our hands, we will be able to understand each other on this 'mocking' issue and come to conclusions more quickly. Let me know what you think. Thank you, Jan -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: communications and community [was Re: Lack of response about sponsorship]
On Fri, 25 Oct 2013 13:54:27 -0700, Adam Williamson wrote: I'm sure the docs team talks about stuff in Rawhide occasionally too; Unlike devel, the docs list is related to Documentation only, isn't it? Could you imagine turning devel into a less general list? Is devel the catch-all for anything related to arbitrary development issues in the Fedora Project? doc-fol [no description available] docsFor participants of the Documentation Project docs-commitsFor tracking commits to Docs Project owned modules docs-qa Fedora Docs QA list To me, at least, test@ has a very clear and specific purpose which is quite different from devel@, So very clear that qa-devel has been split off early this year, after the Fedora QA trac notifications had caused a flood of posts to test list. Well, yes? The purpose of the test@ list clearly didn't include those mails, so they were moved. They are clearly also not appropriate for devel@, because they're about QA tooling development. Are downtime announcements for AutoQA posted only to that list? Moving all Rawhide topics, build failures, build report, package version upgrade annoucements, ABI breakage announcements, Branched report, Rawhide report, from devel to test list would be the way to go. Well, no it wouldn't, because most of those mails are relevant to *developers* (or rather, packagers), not testers. Which is why they're sent to devel@. Build failures are fixed by packagers. ABI bumps are fixed by packagers. The errors identified on the Branched and Rawhide reports are fixed by packagers. Why are rawhide report and F-20 Branched reported also sent to test list? Why the duplication? Why are the F-19 and F-18 updates-testing reports not sent to users list to raise awareness of what updates may be releases as stable updates in after a few days already? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Announcing the Cloud Working Group
I sent a message about this yesterday to the Cloud SIG mailing list, but neglected to send to the wider community. Also, I just listed people without introductions, and although I think all of these names should be familiar to many of us, that seems like a nice thing. So: I'm pleased to annouce that the following people have agreed to be voting members of the initial working group: * James Antill -- FPC member, yum maintainer. Will help with the tools we'll need to build a brave new containerized world. * Robyn Bergeron -- Former Fedora Cloud SIG wrangler, now the FPL. Driver of Fedora for those who value mean time to recover over mean time between failure. Talks regularly with smart people in awesome innovative open software communities outside of our traditional comfort zone. * Joe Brockmeier -- Fedora Marketing contributor, and also member of the Apache CloudStack PMC. Will help with market research, marketing, communications, and as much as we can trick him into taking on. * Haïkel Guémar -- Longtime Fedora contributor (packager, ambassador, writer), and works on cloud computing for $DAYJOB, and so will provide a voice for real-world users. * Sam Kottler -- Works with Puppet and is a member of Bundler and RubyGems core teams. Has opinions, not afraid to use them. Does not sleep. * Sandro Mathys -- Another longtime contributor, active in OpenStack and RDO, also works on cloud computing for actual money; will provide real-world experience and contribute to QA. * Matthew Miller -- Me. FESCo coordinator, cheerleading, that sort of thing. * Frankie Onuonga -- Member of the Fedora Infrastructure team, interested in release engineering. Works for a public cloud startup hopefully going live next week with Fedora images. * Mattias Runge -- Fedora contributor and OpenStack developer. Has presented a somewhat different idea of where we should go with this than what I suggested, which is good in case I'm entirely wrong. As Josh noted in the Workstation WG announcement, I also want to strongly stress that while the above people are the initial voting members, we're looking for participation from anyone interested in helping Fedora succeed as a cloud operating system. We will be using using the existing Cloud SIG mailing list (cl...@lists.fedoraproject.org) and #fedora-cloud IRC channel for group communication. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21/F22 System Wide Change: Python 3 as the Default Implementation
On Wed, Oct 9, 2013 at 5:07 AM, Jaroslav Reznik jrez...@redhat.com wrote: Work in Fedora 21 Timeframe * Proposal owners: ** Discussing changes in Python packaging guidelines with Fedora community and FPC ** Helping upstreams with porting to Python 3 Note, there's an upstream mailing list that people who are doing porting work would be well-served to join: https://mail.python.org/mailman/listinfo/python-porting This isn't just a place where people can discuss gerneal porting best practices but also a place where we can coordinate with other distros on porting software that is important to all of us (crypto and http client libraries, web frameworks, etc). -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: communications and community [was Re: Lack of response about sponsorship]
On Fri, 2013-10-25 at 23:08 +0200, Michael Schwendt wrote: On Fri, 25 Oct 2013 13:54:27 -0700, Adam Williamson wrote: I'm sure the docs team talks about stuff in Rawhide occasionally too; Unlike devel, the docs list is related to Documentation only, isn't it? Could you imagine turning devel into a less general list? Is devel the catch-all for anything related to arbitrary development issues in the Fedora Project? I tend to think of it as 'the list for people packaging stuff for Fedora', myself. I can't tell you how others think of it, but that seems to map quite well for me. Well, yes? The purpose of the test@ list clearly didn't include those mails, so they were moved. They are clearly also not appropriate for devel@, because they're about QA tooling development. Are downtime announcements for AutoQA posted only to that list? I'm not sure. As AutoQA is meant to be a tool for the benefit of packagers, it would make sense to send them to devel@ too; if we're not doing that we probably should. Moving all Rawhide topics, build failures, build report, package version upgrade annoucements, ABI breakage announcements, Branched report, Rawhide report, from devel to test list would be the way to go. Well, no it wouldn't, because most of those mails are relevant to *developers* (or rather, packagers), not testers. Which is why they're sent to devel@. Build failures are fixed by packagers. ABI bumps are fixed by packagers. The errors identified on the Branched and Rawhide reports are fixed by packagers. Why are rawhide report and F-20 Branched reported also sent to test list? Why the duplication? I could live without 'em being duplicated, really. I think the idea is that testers may want to know what packages have been changed in the previous day. Why are the F-19 and F-18 updates-testing reports not sent to users list to raise awareness of what updates may be releases as stable updates in after a few days already? I don't know; possibly just volume (they're long emails and there's three of 'em a day, I used to find time to try and read them all, these days I just tend to mark 'em as read and move on). But it seems like a reasonable idea. Perhaps someone's worried such long automated mails might scare the users@ audience? I don't read users@, so I don't really know. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: communications and community [was Re: Lack of response about sponsorship]
On Fri, Oct 25, 2013 at 10:41:12AM -0700, Adam Williamson wrote: mailman topics/keywords features to sort into meaningful sub-categories. I understand that hyperkitty will make this nice and easy, but it's also not really very hard just as email. Note that you can subscribe to just certain topics, if you are not interested in certain areas. So, have fewer lists, but then have what are effectively sub-lists within the lists. Where exactly is the win? Opting in / out of topics is more lightweight than subscribing and unsubscribing. And the web interface will present it all together with easy ways to filter on the fly. (I notice that hyperkitty lets me change categories for a post after the fact; this is cool and I think desirable but I'm not sure how it interacts if at all with mailman keywords.) I'd love to hear better suggestions the main problem seems to be it's so busy no one goes there anymore. How can we keep the discussion cohesive but prevent it from becoming overwhelming? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: communications and community [was Re: Lack of response about sponsorship]
On Fri, 2013-10-25 at 17:41 -0400, Matthew Miller wrote: I'd love to hear better suggestions the main problem seems to be it's so busy no one goes there anymore. There is a rather obvious gaping logical flaw in that one ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: communications and community [was Re: Lack of response about sponsorship]
On Oct 25, 2013 3:09 PM, Michael Schwendt mschwe...@gmail.com wrote: On Fri, 25 Oct 2013 13:54:27 -0700, Adam Williamson wrote: I'm sure the docs team talks about stuff in Rawhide occasionally too; Unlike devel, the docs list is related to Documentation only, isn't it? Could you imagine turning devel into a less general list? Is devel the catch-all for anything related to arbitrary development issues in the Fedora Project? doc-fol [no description available] docsFor participants of the Documentation Project docs-commitsFor tracking commits to Docs Project owned modules docs-qa Fedora Docs QA list *snip* This really isn't a fair comparison. Fedora Documentation is a distinct product; in some contexts it is an upstream project using Fedora/fedorahosted resources. For this discussion, citing, oh, the cobbler mailing list would be just as effective. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: communications and community [was Re: Lack of response about sponsorship]
On Fri, Oct 25, 2013 at 11:41 PM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Oct 25, 2013 at 10:41:12AM -0700, Adam Williamson wrote: mailman topics/keywords features to sort into meaningful sub-categories. I understand that hyperkitty will make this nice and easy, but it's also not really very hard just as email. Note that you can subscribe to just certain topics, if you are not interested in certain areas. So, have fewer lists, but then have what are effectively sub-lists within the lists. Where exactly is the win? Opting in / out of topics is more lightweight than subscribing and unsubscribing. Subscribing to a mailing list is an one-time, 5-minute operation (BTDT just today). OTOH dealing with topics is a constant cost: mail programs have good autocompletion for the To: field, but not for arbitrary syntax in Subject:. It's mental overhead and there will be an unending stream of mistakes. I'd love to hear better suggestions the main problem seems to be it's so busy no one goes there anymore. How can we keep the discussion cohesive but prevent it from becoming overwhelming? In general, avoid badly targeted email. Doing this for human communication is fairly difficult - we'll see whether/how much the new working groups will help minimizing the communication that is irrelevant to most. (Corollary: if you care about any of the WGs, subscribe now :) ) It would be probably simpler for the automated emails: unless everyone on the list wants to, or should want to, read them, just stop sending them; _and_, send them to a better targeted group, which would make them more useful. E.g. the rawhide/F20 report and EVR problem e-mails should, I think be sent to rel-eng (if they read it, that is) and the packagers that need to take action. (Currently I never read them, so I wouldn't even notice if they mentioned my package - for me they are pure overhead.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: communications and community [was Re: Lack of response about sponsorship]
On Fri, 25 Oct 2013 16:02:44 -0600, Pete Travis wrote: On Fri, 25 Oct 2013 13:54:27 -0700, Adam Williamson wrote: I'm sure the docs team talks about stuff in Rawhide occasionally too; Unlike devel, the docs list is related to Documentation only, isn't it? Could you imagine turning devel into a less general list? Is devel the catch-all for anything related to arbitrary development issues in the Fedora Project? doc-fol [no description available] docsFor participants of the Documentation Project docs-commitsFor tracking commits to Docs Project owned modules docs-qa Fedora Docs QA list *snip* This really isn't a fair comparison. Fedora Documentation is a distinct product; in some contexts it is an upstream project using Fedora/fedorahosted resources. For this discussion, citing, oh, the cobbler mailing list would be just as effective. I guess we will hardly ever read about Fedora Documentation on devel list and only occasionally see related announcements that affect packagers. I've mentioned other lists before. Those that overlap are troublesome. Cross-posting is troublesome, if it results in replies only on one list. Separate lists that move traffic from somewhere else can be a problem, too. Suddenly, subscribers of a list, such as devel, no longer learn about the topics that have moved elsewhere. Unless they subscribe to the separate list. Adam says that devel is relevant to *developers* (or rather, packagers). Yet there is the packaging list, too. Quote from Oct 16th: I don't know whether this belongs to the packaging or devel list, Not even devel-announce is used consistently. Some people post version bump announcements there. If that were done for the entire package collection, forget about the LOW TRAFFIC mentioned in the list description. ;) I guess the problem is not fixable with old-school mailing-lists. The thread Lack of response about sponsorship could have posted on fedora-join list. Who has been aware of that list anyway? https://lists.fedoraproject.org/pipermail/fedora-join/ It's linked in some places, but has it been announced on announce or devel-announce? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: communications and community [was Re: Lack of response about sponsorship]
On Sat, 2013-10-26 at 02:11 +0200, Michael Schwendt wrote: Adam says that devel is relevant to *developers* (or rather, packagers). Yet there is the packaging list, too. Quote from Oct 16th: I don't know whether this belongs to the packaging or devel list, Now to me, THAT seems like a redundancy :) devel@ is the list for, well, developing Fedora. Is there a history behind the packaging list? I'm not familiar with it. Is it actually used much? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: communications and community [was Re: Lack of response about sponsorship]
On 10/25/2013 04:48 PM, Matthew Miller wrote: On Fri, Oct 25, 2013 at 04:02:23PM +0200, Michael Schwendt wrote: The people who've pointed out the confusion about which list to choose when haven't drunk away their memory and could join here, but that will be fruitless if an instance such as FESCo decides otherwise. So, here's what I'd like to see. Collapse all lists to just four: * Fedora Users * Fedora Development - includes testing * Fedora Announcments - low traffic, big official announcements only * Auto-generated Reports - and probably tickets which go to a list; these things are useful to the people who want them but overall lower signal-to-noise ratio History repeats - This is approximately what Fedora had in its early days. Then, people were complaining about traffic and low S/N. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: communications and community [was Re: Lack of response about sponsorship]
On 10/26/2013 02:14 AM, Adam Williamson wrote: On Sat, 2013-10-26 at 02:11 +0200, Michael Schwendt wrote: Adam says that devel is relevant to *developers* (or rather, packagers). Yet there is the packaging list, too. Quote from Oct 16th: I don't know whether this belongs to the packaging or devel list, Now to me, THAT seems like a redundancy :) devel@ is the list for, well, developing Fedora. Is there a history behind the packaging list? Yes. It's about discussing packaging issues and packaging standards. The reason it exists is the same as with most other lists: People having complained about packaging discussions being non-interesting to them and thus contributing to what they consider to be noise. I'm not familiar with it. Is it actually used much? Yes, it is. It's not a high traffic list, but it's in active use. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: communications and community [was Re: Lack of response about sponsorship]
On 10/25/2013 11:55 PM, Adam Williamson wrote:
On Fri, 2013-10-25 at 17:41 -0400, Matthew Miller wrote:
I'd love to hear better suggestions the main problem seems to be it's
so busy no one goes there anymore.
There is a rather obvious gaping logical flaw in that one ;)
Not quite. Complaints like these were common in the early Fedora days:
I am unsubscribing, because though I am a {kernel|java|..}-dev, most
postings are not of interest to me.
Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1023397] New: perl-Archive-Tar-1.96 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1023397 Bug ID: 1023397 Summary: perl-Archive-Tar-1.96 is available Product: Fedora Version: rawhide Component: perl-Archive-Tar Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 1.96 Current version/release in Fedora Rawhide: 1.92-4.fc20 URL: http://search.cpan.org/dist/Archive-Tar/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=5azKKCJhVNa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1023400] New: perl-lib-abs-0.93 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1023400 Bug ID: 1023400 Summary: perl-lib-abs-0.93 is available Product: Fedora Version: rawhide Component: perl-lib-abs Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.93 Current version/release in Fedora Rawhide: 0.92-3.fc20 URL: http://search.cpan.org/dist/lib-abs/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=VbL2UJuwWUa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1021855] perl-Shipwright-2.4.35 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1021855 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Shipwright-2.4.34 is |perl-Shipwright-2.4.35 is |available |available --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 2.4.35 Current version/release in Fedora Rawhide: 2.4.33-4.fc20 URL: http://search.cpan.org/dist/Shipwright/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fdYcq1JxMoa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the F-20 tree: On x86_64: perl-PDL-2.4.10-6.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit) On i386: perl-PDL-2.4.10-6.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the F-20 tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-MIME-Lite-HTML
perl-MIME-Lite-HTML has broken dependencies in the F-20 tree: On x86_64: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: slic3r
slic3r has broken dependencies in the F-20 tree: On x86_64: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On i386: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On armhfp: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-BerkeleyDB
perl-BerkeleyDB has broken dependencies in the F-20 tree: On x86_64: perl-BerkeleyDB-0.53-1.fc20.x86_64 requires libdb = 0:5.3.21 On i386: perl-BerkeleyDB-0.53-1.fc20.i686 requires libdb = 0:5.3.21 On armhfp: perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Padre
perl-Padre has broken dependencies in the F-20 tree: On x86_64: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Archive-Tar-1.96.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Archive-Tar: e480708fa215fb3778523d73682c4af8 Archive-Tar-1.96.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1023397] perl-Archive-Tar-1.96 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1023397 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Archive-Tar-1.96-1.fc2 ||1 Resolution|--- |RAWHIDE Last Closed||2013-10-25 09:24:31 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=iqFEHcSTJoa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Text-Autoformat-1.669004.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Text-Autoformat: 7a7881ca625fa71e551c1f43910f2865 Text-Autoformat-1.669004.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-Autoformat/f20] Update to 1.669004
Summary of changes: c189a75... Update to 1.669004 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-Autoformat] Created tag perl-Text-Autoformat-1.669004-1.fc21
The lightweight tag 'perl-Text-Autoformat-1.669004-1.fc21' was created pointing to: c189a75... Update to 1.669004 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-Autoformat] Created tag perl-Text-Autoformat-1.669004-1.fc20
The lightweight tag 'perl-Text-Autoformat-1.669004-1.fc20' was created pointing to: c189a75... Update to 1.669004 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Text-Diff-HTML-0.07.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Text-Diff-HTML: bea80ec02d4f6d7e8eb8cfbcb35f3b2c Text-Diff-HTML-0.07.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-Diff-HTML] Update to 0.07
commit cc10542785f4f0271d832c08e683c98bd4d46a5f
Author: Paul Howarth p...@city-fan.org
Date: Fri Oct 25 17:13:46 2013 +0100
Update to 0.07
- New upstream release 0.07
- Moved to http://github.com/theory/text-diff-html/
- Switched to a static README.md, rather than a generated README
- Specify all dependencies
- Drop %defattr, redundant since rpm 4.4
- Make %files list more explicit
- Don't need to remove empty directories from the buildroot
- Don't use macros for commands
.gitignore |3 +--
perl-Text-Diff-HTML.spec | 45 +
sources |2 +-
3 files changed, 31 insertions(+), 19 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index c427697..9502d99 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1 @@
-Text-Diff-HTML-0.05.tar.gz
-/Text-Diff-HTML-0.06.tar.gz
+/Text-Diff-HTML-[0-9.]*.tar.gz
diff --git a/perl-Text-Diff-HTML.spec b/perl-Text-Diff-HTML.spec
index aab332b..04c74dd 100644
--- a/perl-Text-Diff-HTML.spec
+++ b/perl-Text-Diff-HTML.spec
@@ -1,19 +1,26 @@
Name: perl-Text-Diff-HTML
-Version:0.06
-Release:9%{?dist}
+Version:0.07
+Release:1%{?dist}
Summary:XHTML format for Text::Diff::Unified
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Text-Diff-HTML/
Source0:
http://www.cpan.org/authors/id/D/DW/DWHEELER/Text-Diff-HTML-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
-BuildRequires: perl(HTML::Entities)
+# Module Build
BuildRequires: perl(Module::Build)
-BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Pod) = 1.20
+# Module Runtime
+BuildRequires: perl(constant)
+BuildRequires: perl(HTML::Entities)
+BuildRequires: perl(strict)
BuildRequires: perl(Text::Diff) = 0.11
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+BuildRequires: perl(vars)
+# Test Suite
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+# Runtime
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
This class subclasses Text::Diff::Unified, a formatting class provided by
@@ -25,16 +32,13 @@ documentation.
%setup -q -n Text-Diff-HTML-%{version}
%build
-%{__perl} Build.PL installdirs=vendor
+perl Build.PL installdirs=vendor
./Build
%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/*
+%{_fixperms} $RPM_BUILD_ROOT
%check
./Build test
@@ -43,12 +47,21 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
rm -rf $RPM_BUILD_ROOT
%files
-%defattr(-,root,root,-)
-%doc Changes README
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%doc Changes README.md
+%{perl_vendorlib}/Text/
+%{_mandir}/man3/Text::Diff::HTML.3pm*
%changelog
+* Fri Oct 25 2013 Paul Howarth p...@city-fan.org - 0.07-1
+- Update to 0.07
+ - Moved to http://github.com/theory/text-diff-html/
+ - Switched to a static README.md, rather than a generated README
+- Specify all dependencies
+- Drop %%defattr, redundant since rpm 4.4
+- Make %%files list more explicit
+- Don't need to remove empty directories from the buildroot
+- Don't use macros for commands
+
* Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.06-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index efb4862..58d441f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-27d6447eebebcfb620977aba8a9b9300 Text-Diff-HTML-0.06.tar.gz
+bea80ec02d4f6d7e8eb8cfbcb35f3b2c Text-Diff-HTML-0.07.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-Diff-HTML/f20] Update to 0.07
Summary of changes: cc10542... Update to 0.07 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken upgrade path(s) detected for: perl-XML-TreeBuilder
f20-updates-testing f21 (perl-XML-TreeBuilder-4.2-0.fc20 perl-XML-TreeBuilder-4.0-11.fc20) Please fix the(se) issue(s) as soon as possible. --- This report generated by Fedora Release Engineering, using http://git.fedorahosted.org/cgit/releng/tree/scripts/check-upgrade-paths.py -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [389-devel] Please review lib389 ticket 47568: Rename DSAdmin class (2nd)
On Friday 25 October 2013 11:18:53 thierry bordaz wrote: lib389/brooker.py:795: python variable naming convention: I would get stick with the _ instead of camelCase and change whenever possible. If you prefer to use '_' also for local variable, I am fine. Using camel just for classes is more explicative, and I find that _ are easier to read and replace with sed ;) tests/dsadmin_test.py: I renamed it lib389_test.py, you can merge my changes tests/dsadmin_test.py:39: why remove the addbackend_harn? Humm, to be honest... I do not know how to rename files :-) git mv dsadmin_test.py lib389_test.py ;) tests/replica_test.py:119: you're using Backend.delete in a class that should test just Replica. I would use harness and the standard python-ldap methods in setup/teardown, so that we can change the Backend and Replica class without at least breaking the tests. I miss your point. It is calling in teardown conn.backend.delete, is that the call that is not correct ? That's just an IMHO: see those cases: 1- I change the Backend class and break the replica test: I'll look for errors in Replica while the issue is in Backend 2- somebody works on the Backend class, I work on the Replica one: he can break my tests. Splitting the test stuff in an harness module will reduce the impact of all that. As an example, I could even agree the setup process be done populating entries via an LDIF. If I test Replica, Backend or Suffix I shouldn't have other dependencies distracting me. Let me know + Peace, R. -- Roberto Polli Community Manager Babel S.r.l. - http://www.babel.it T: +39.06.9826.9651 M: +39.340.652.2736 F: +39.06.9826.9680 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere confidenziale per i destinatari in indirizzo. E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati nel messaggio originale. Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di comunicarlo al mittente e cancellarlo immediatamente. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] resent: please review: Ticket 47368 - IPA server dirsrv RUV entry data excluded from fractional replication
Performance numbers look good with this patch (no significant impact). Resending this out for review... https://fedorahosted.org/389/ticket/47368 https://fedorahosted.org/389/attachment/ticket/47368/0001-Ticket-47368-IPA-server-dirsrv-RUV-entry-data-exclud.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Proof of concept: mocking DS in lib389
Hello Roberto and Thierry, as I promised, I am sending you a proof-of-concept code that demonstrates, how we can mock DS in unit tests for library function (see attachment). You can run tests just by executing py.test in tests directory. Only 3 files are of interest here: lib389/dsmodules/repl.py - this is a Python module with functions - they expect DS instance as the first argument. Since they are functions, not methods, I can just mock DS and pass that fake one as the first argument to them in unit tests. tests/test_dsmodules/conftest.py - this file contains definition of mock DS class along with py.test fixture, that returns it. tests/test_dsmodules/test_repl.py - this contains unit tests for functions from repl.py. What I do is quite simple - I override ldapadd, ldapdelete .. methods of mock DS class, so that instead of sending command to real DS instance, they just store the data in 'dit' dictionary (which represents content stored in DS). This way, I can check that when I call e.g. function enable_changelog(..), in the end DS will have correct changelog entry. To put it very bluntly - enable_changelog(..) function just adds correct changelog entry to whatever is passed to it as the first argument. In unit tests, it is mock DS, otherwise it would be real DS class that sends real ldap commands to real DS instance behind. Now I can successfully test that enable_changelog really works, without going into trouble defining DSInstance or ldap calls at all. Also, I believe this approach would work for 95% of all functions in lib389. Another benefit is that unit tests are much faster, than on real DS instance. Sidenote: even though everything is defined in separate namespace of 'repl' module as function, in runtime they can be used as normal methods of class DSInstance. That is handled by DSModuleProxy. We already went through this, but not with Roberto. Hopefully, now with some code in our hands, we will be able to understand each other on this 'mocking' issue and come to conclusions more quickly. Let me know what you think. Thank you, Jan proof_of_concept_mocking.tar.gz Description: GNU Zip compressed data -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review: [389 Project] #47555: db2bak.pl issue when specifying non-default directory
https://fedorahosted.org/389/attachment/ticket/47555/0001-Ticket-47555-db2bak.pl-issue-when-specifying-non-def.patch
Bug description: db2bak.pl takes an option -a backupdir, which is
supposed to be generated by the server and used as a backup directory.
But since the created directory inherits the parent's selinux context,
it may fail to store the backup files in the directory.
Fix description: As the reporter agaviola suggested, it should be a
good idea to add one more level to the archive directory.
$archivedir = ${archivedir}/ID-${yr}_${mn}_${dy}_${h}_${m}_${s};
But to keep the backward compatibility, introducing a new option -A
backupdir and when -A is given, storing the backup files in the
nested backup directory. If the option is -a backupdir, the backup
files are stored in the backupdir.
Also, this patch sets the right ownership and selinux context to the
generated directory. Note: if the parent directories of the created
backupdir do not have the correct selinux context, even if the last
directory's setting is correct, storing the backup files fails. It
is the user's responsibility to set them correctly.
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
