October 2012 - devel - Fedora Mailing-Lists

Fedora 18 : broken configuration for httpd 2.4

by Remi Collet

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Testing some packages in Fedora 18, I noticed that lot of configuration for httpd have not be fixed for new version 2.4. So I open a tracker bug for this issues https://bugzilla.redhat.com/show_bug.cgi?id=871373 Currently I have filed ~40 bugs, and continue to check all applications providing a httpd configuration file. I you need more explanation on the required changes, feel free to ask. Regards, Remi. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCP4MsACgkQYUppBSnxahiR4QCfX/tow2/DWTLn8jxwSc2D2ifX 4ssAn22FM/hfEnsyXzNfkc5FCujGIvIE =6Wht -----END PGP SIGNATURE-----

11 years, 5 months

6
11
0 / 0

Deploying fedora infrastructure (koji) across clouds

by Mo Morsi

// Deploying fedora infrastructure (koji) across clouds // As promised, steps to deploy kojihub to an openstack instance communicating with builders on ec2 // Any provider supported by deltacloud will work // (lots of em: http://deltacloud.apache.org/drivers.html) // A short video of these steps in action can be seen here: // http://youtu.be/qF2ctg7ItNc // install deltacloud & drivers $ sudo yum install wget deltacloud-core deltacloud-core-openstack deltacloud-core-ec2 // start it $ deltacloudd -i mock // small wrapper script around deltacloud: $ wget https://raw.github.com/movitto/mycloud/master/mycloud.rb $ chmod +x mycloud.rb // template describing kojihub cloud deployment $ wget https://raw.github.com/aeolus-incubator/templates/master/fedora_infra/koj... // template describing kojibuild cloud deployment $ wget https://raw.github.com/aeolus-incubator/templates/master/fedora_infra/koj... // edit kojihub deployment to contain openstack credentials $ vim koji_f17.xml // startup an instance on openstack w/ kojihub setup togo $ ./mycloud.rb koji_f17.xml // grab public address from output, grab kojibuild ssl credentials from new instance $ scp -i ~/os.key ec2-user@kojihub:/etc/pki/koji/kojiadmin.pem . $ scp -i ~/os.key ec2-user@kojihub:/etc/pki/koji/koji_ca_cert.crt . // edit kojibuild deployment to deploy to ec2 w/ correct koji credentials & hub address $ vim koji_builder_f17.xml // startup an instance on ec2 w/ kojibuild communicating w/ the hub $ ./mycloud.rb koji_builder_f17.xml // open up a webbrowser, navigating to http://kojihub/koji to use your Koji instance! -Mo

11 years, 5 months

4
11
0 / 0

still UsrMove problems and wrong PATH in openssh

by Reindl Harald

it is REALLY bad make UsrMove and HRADCODE /bin:/sbin in PATH of openssh, this results in packages built with "rpmbuild" having Requires: /bin/perl as example in my opinion "rpmbuild" should know about the change and fix implicit Requires: /bin and Requires: /sbin https://bugzilla.redhat.com/show_bug.cgi?id=856590 WHY are F18 packages built for testing if a bugreport is for F17 - if someone is working hard to get F17 running as F16 before this is not helpful https://bugzilla.redhat.com/show_bug.cgi?id=871503 https://bugzilla.redhat.com/show_bug.cgi?id=856590 https://bugzilla.redhat.com/show_bug.cgi?id=856584

11 years, 5 months

11
15
0 / 0

rubygem-{bunny,moneta,ohai} package ownership

by Julian C. Dunn

I'm trying to take over the work Jonas Courteau started earlier this year (see below) in regards to getting Opscode Chef into Fedora. To start, I'd like to assume responsibility for the above orphaned packages in Fedora, which are dependencies for Chef. I am already a Fedora Packager but I can't seem to "Take Ownership" of said packages in the package DB. Can anyone assist? - Julian On Mon, May 21, 2012 at 10:36 PM, Jonas Courteau <rpms(a)courteau.org> wrote: > My apologies; the links on that were wrong. Big copy/paste error on my > part; not a good start! > > The main package, rubygem-chef is at > https://bugzilla.redhat.com/show_bug.cgi?id=823352, and the other > packages are linked off of there. > > A little bit about myself: I'm a network administrator who has been > using CentOS extensively for around 5 years, and Chef for about 3 > years. As part of this, I've done a fair amount of packaging of > various software for our internal repository using mock and the EPEL > packaging guidelines. A large part of my early packaging efforts > involved packaging assorted Ruby gems. > > Recently, I've been working with opscode to get Chef packaged up for > Fedora (and EPEL, in the future). There was a previous abortive > attempt to get Chef into Fedora but the volunteer involved at the time > had other requirements on his time. I'm looking to maintain this > package (and its requirements) on a long-term basis, since there is a > fair bit of demand to have Chef be a bit more widely available. > > Please let me know if you have any further questions, or if you have > any suggestions on proceeding from here. > > Thanks! > Jonas Courteau > -- > devel mailing list > devel(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel

11 years, 5 months

2
1
0 / 0

Is RPM now stricter about checking for file conflicts?

by Michel Alexandre Salim

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (originally posted to test@; Adam Williamson suggested it might be more appropriate here) Ever since I started tracking Fedora 18, Google Music Manager is no longer installable, and now Oracle's Virtual Box cannot be installed either (both from upstream Yum repositories). https://bugzilla.redhat.com/show_bug.cgi?id=870655 In both cases, RPM and yum aborts with file conflicts -- /lib/modules for VirtualBox and /usr/bin for google-musicmanager. While, granted, these are upstream packaging bugs and those directories should not be owned by the corresponding packages (they are owned by filesystem), is there any reason why the same RPMs install just fine previously? (and if anyone knows who to contact at Google and Oracle's VBox team respectively, that'd be great -- I tried contacting the Music Manager team but the email listed in the RPM bounces, and the support reps that respond through official channels don't even know what Linux is, they sent me screenshot-grabbing instructions for Windows and Mac...) Apologies if this s a dupe, I could only find one relevant thread regarding file conflicts and that's regarding Samba 3 vs Samba 4 - those apply to files whereas the file conflicts here are really about directories. Best regards, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: salimma(a)fedoraproject.org | GPG key ID: A36A937A Jabber: hircus(a)jabber.ccc.de | IRC: hircus(a)irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQjCvWAAoJEEr1VKujapN6N3cH/3FrXhxeCBrs3CwWpeSaZVbr GBCVZg/vZ06uQqc0/1v8pfsZKXQ24UNxmlqmKnfAsW2GHXq2vwS6cBfd+I/phjZi Z+mmw8wIAMaGm2ihbe8WK6f2tzzq/1jPggri7ofria3/c0EcqaNoLIiQrokAJTKo l5rb46R4isaKzrDO7ijzl8vMhBT4NOo3ASD0P8w0YcTSZISehrHwEw8U/4Bzb6dC 7yPHsodmlGUrPTuzzlXBFfAkfG68T0Ws9QaC4aMpHcYlrK7lOXA4h+BLv/KPN/so ByFKJiN6Hm/a96TjtqJgfrzLuFy/TGV9+RBRYapg0CHSBWehvhpT0sTSkiKLTIY= =x1kZ -----END PGP SIGNATURE-----

11 years, 5 months

7
10
0 / 0

Packaging help needed: Prevent noarch package from requiring 32bit RPMs on a 64bit system

by Miro Hrončok

Hi, I am trying to package slic3r -> it is a perl noarch package, but it requires a lot of arch specific perl modules. The Requires section form spec file: Requires: perl(XML::SAX) Requires: perl(Growl::GNTP) Requires: perl(Net::DBus) Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) https://github.com/hroncok/SPECS/blob/master/slic3r.spec The rest of Requires are automatically added. When I built the package and add it to the repository together with required packages I made, it requires arch mishmash on a 64bit system: Install: slic3r noarch myrepo Install requires: perl-Boost-Geometry-Utils i686 myrepo perl-Class-Accessor noarch perl-Class-Method-Modifiers noarch perl-Crypt-CBC noarch perl-Devel-Symdump noarch perl-Digest-SHA x86_64 perl-Digest-SHA1 x86_64 perl-File-HomeDir noarch perl-File-Which noarch perl-Growl-GNTP noarch myrepo perl-JSON noarch perl-Language-Expr noarch myrepo perl-Math-Clipper i686 myrepo perl-Math-ConvexHull noarch myrepo perl-Math-Expression-Evaluator noarch myrepo perl-Math-Factor-XS i686 myrepo perl-Math-Geometry-Voronoi i686 myrepo perl-Math-Libm x86_64 myrepo perl-Math-NumSeq noarch myrepo perl-Math-PlanePath noarch myrepo perl-Math-Prime-XS i686 myrepo perl-Math-Symbolic noarch perl-Module-Load noarch perl-Module-Util noarch perl-Moo noarch perl-Net-DBus x86_64 perl-Params-Validate x86_64 perl-Parse-RecDescent noarch perl-Pod-Coverage noarch perl-Regexp-Grammars noarch perl-Role-Tiny noarch perl-SVG noarch perl-Test-Pod noarch perl-Test-Pod-Coverage noarch perl-Test-Simple noarch perl-UUID-Tiny noarch myrepo perl-Wx x86_64 perl-XML-Twig noarch perl-boolean noarch perl-constant-defer noarch myrepo perl-libintl x86_64 perl-parent noarch perl-strictures noarch Lines with myrepo are made by me, you can see specs here: https://github.com/hroncok/SPECS/ As you can see, it installs 64bit required packages from officail repositories, but it installs 32bit packages from mine (64bit packages also exists, that's not the problem). It installs slic3r, but it won't work, as it looks up its't arch specific modules in 64bit directories. If I manually run yum install perl-Boost-Geometry-Utils perl-Math-Clipper perl-Math-Factor-XS perl-Math-Geometry-Voronoi perl-Math-Prime-XS slic3r It works as expected (install 64bit packages). What should I as a packager do, to avoid this situation? Thank you very much. Miro Hrončok Jabber: miro(a)hroncok.cz Telefon: +420777974800

11 years, 5 months

3
4
0 / 0

Fedora ARM weekly staus meeting minutes 2012-10-31

by Paul Whalen

Good day all, Thanks to those who were able to join us for the weekly status meeting today. For those that were unable, the minutes are posted below: Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-10-31/fedora-meeti... Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2012-10-31/fedora-meeti... Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-10-31/fedora-meeti... Have a safe and happy Halloween, Paul

11 years, 5 months

1
0
0 / 0

Schedule for Wednesday's FESCo Meeting (2012-11-01)

by Kevin Fenzi

Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #932 F18 Features - progress at Feature Freeze .fesco 932 https://fedorahosted.org/fesco/ticket/932 #topic #960 F18 schedule + the holidays .fesco 960 https://fedorahosted.org/fesco/ticket/960 = New business = #topic #961 Clarification request- Is Java (including the JVM) exempt from Multilib .fesco 961 https://fedorahosted.org/fesco/ticket/961 #topic #963 change of names of configuration files .fesco 963 https://fedorahosted.org/fesco/ticket/963 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

11 years, 5 months

1
1
0 / 0

[Guidelines Change] Changes to the Packaging Guidelines

by Tom Callaway

Some changes to the Fedora Packaging Guidelines have been made: --- In the specific case where multiple software components generate identically named (but incompatible) binaries, Fedora Packagers should make every effort to convince the upstreams to rename the binaries to resolve the conflict (see: Packaging:Conflicts#Binary_Name_Conflicts). However, if neither upstream is willing to rename the binaries to resolve the conflict, AND the binaries are not viable candidates for alternatives or environment modules (incompatible runtimes), as long as there are no clear cases for both packages to be installed simultaneously, explicit Conflicts are permitted at the packager's discretion. Both packages must carry Conflicts in this case. Be aware, adding explicit Conflicts means that if any other packages depend on your package, you may be creating a chain-of-conflicts that could cause user pain. Please consider this as a last resort. https://fedoraproject.org/wiki/Packaging:Conflicts#Incompatible_Binary_Fi... --- The PEAR section of the PHP Guidelines has been updated to reflect the existence of a new macro, %{pear_metadir}, along with an example of how it is to be used, and a new EPEL specific section relating to the fact that %{pear_metadir} does not exist in RHEL php builds. https://fedoraproject.org/wiki/Packaging:PHP#PEAR_Modules --- The MPI Guidelines have been updated to install the module files under a "mpi" sub-directory and adds "conflict mpi" to the module files to avoid being able to load multiple mpi modules at one time. https://fedoraproject.org/wiki/Packaging:MPI --- These guideline changes were approved by the Fedora Packaging Committee (FPC). Many thanks to Remi Collet, Orion Poplawski, Michal Sekletar, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines. As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here: https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure Thanks, ~tom _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

11 years, 5 months

1
0
0 / 0

Fedora ARM weekly status meeting 2012-10-31

by Paul Whalen

Good day all, This weeks Fedora ARM status meeting will take place today (Wednesday Oct 31st) in #fedora-meeting-1 on Freenode. Times in various time zones (please let us know if these do not work): PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Current items on the agenda: 1) Fedora 18 ARM Alpha release 2) F18/19 build status - problem packages? 3) Koji Hub - speed issues, moving to Phoenix prior to PA push? 4) Kirkwood images - is anyone interested in assisting with their creation/testing? 4) Your topic here If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting. Paul

11 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel October 2012