Agenda for Env-and-Stacks WG meeting (2015-04-23)
WG meeting will be at 12:00 UTC (9:00 EST, 14:00 Brno, 8:00 Boston, 21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting-2 on Freenode. = Topics = * Follow-ups * Playground result repo (https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-April/000770.html) * Dockerfiles recommended tips (user, logs) * Modular Fedora -- more versions available, not necessarily install-able * Chair for next week (hhorak not available) * Open Floor -- 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: plplot 5.11.0 update in rawhide
On 04/22/2015 02:44 PM, Orion Poplawski wrote: I'm updating plplot to 5.11.0 in rawhide. This changes sonames, breaks APIs, eats babies, etc. I'll be working on rebuilding dependent packages. gdl-0.9.5-5.fc23.src.rpm perl-PDL-Graphics-PLplot-0.67-5.fc22.src.rpm psfex-3.17.1-4.fc22.src.rpm scamp-2.0.4-1.fc22.src.rpm techne-0.2.3-13.fc22.src.rpm There is a problem with the new plplot pkgconfig file that's preventing building. I'm working on a fix, then hopefully I can get these all rebuilt tomorrow. They all require modification to work. I'll be making changes for fedora builds, as well as providing upstreamable patches for maintainers to submit upstream. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
plplot 5.11.0 update in rawhide
I'm updating plplot to 5.11.0 in rawhide. This changes sonames, breaks APIs, eats babies, etc. I'll be working on rebuilding dependent packages. gdl-0.9.5-5.fc23.src.rpm perl-PDL-Graphics-PLplot-0.67-5.fc22.src.rpm psfex-3.17.1-4.fc22.src.rpm scamp-2.0.4-1.fc22.src.rpm techne-0.2.3-13.fc22.src.rpm -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Annonce: qt-virt-manager
On 04/22/2015 12:36 PM, Fl@sh wrote:
> Hi, all!
> I'm developing qt-virt-manager.
> I have to say: this is not a Qt-clone of the virt-manager.
> The application is able to perform a lot, so I suggest you to
> use, and look forward to your wishes.
> (I'm make fedora-build, if somebody build it for other
> distributives, then , pls, say to me for annonce on
> opendesktop.org site.)
>
> https://github.com/F1ash/qt-virt-manager
> https://f1ash.fedorapeople.org/qt-virt-manager/
> http://opendesktop.org/content/show.php/qt-virt-manager?content=169785
>
Looks very nice.
I had to build qtermwidget and then make one tweek [2] to the spec file
to get it to build on RHEL7.
I have uploaded my built packages incase others want to try them on
rhel7. [1]
One feature that I think would be nice, would be to make it easy to
find, setup and connect to localhost connections.
Keep up the good work.
Troy Dawson
[1] - https://tdawson.fedorapeople.org/qt-virt-manager/
[2] - %{make_build} isn't in rhel7 rpm macros.
@@ -74,14 +74,14 @@
mkdir %{cmake_build_dir}-qt4
pushd %{cmake_build_dir}-qt4
%cmake ..
- %{make_build}
+ %{__make} %{?_smp_mflags}
popd
%endif
%if %with qt5
mkdir %{cmake_build_dir}-qt5
pushd %{cmake_build_dir}-qt5
%cmake -DBUILD_QT_VERSION=5 ..
- %{make_build}
+ %{__make} %{?_smp_mflags}
popd
%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: Review needed to resolve bundling issue.
if you have time can you review this one? https://bugzilla.redhat.com/show_bug.cgi?id=1214385 thanks in advance Il 22/04/2015 21:05, Richard Shaw ha scritto: My package, fldigi, has been in Fedora for some time, but in attempting to get other related projects into Fedora from the same upstream, it was discovered that a fork of xmlrpc++ was being bundled in the package. A bundling exception was not granted[1] even though xmlrpc++ is not currently in Fedora so upstream has developed a stand alone library, flxmlrpc, to fix the problem and I have submitted a review request for it: https://bugzilla.redhat.com/show_bug.cgi?id=1214467 It's a very simple library so it should be a very simple review if someone could help me out quickly. Thanks, Richard [1] https://fedorahosted.org/fpc/ticket/515 -- 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: Annonce: qt-virt-manager
On 04/22/2015 11:36 AM, Fl@sh wrote: > Hi, all! > I'm developing qt-virt-manager. > I have to say: this is not a Qt-clone of the virt-manager. > The application is able to perform a lot, so I suggest you to > use, and look forward to your wishes. > (I'm make fedora-build, if somebody build it for other > distributives, then , pls, say to me for annonce on > opendesktop.org site.) > > https://github.com/F1ash/qt-virt-manager > https://f1ash.fedorapeople.org/qt-virt-manager/ > http://opendesktop.org/content/show.php/qt-virt-manager?content=169785 > You might consider making a copr repo. Also, at least the qt5 version doesn't seem to work very well for me. Can see overview most of the time. You might also announce on the fedora-virt list -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review needed to resolve bundling issue.
take .. regards Il 22/04/2015 21:05, Richard Shaw ha scritto: My package, fldigi, has been in Fedora for some time, but in attempting to get other related projects into Fedora from the same upstream, it was discovered that a fork of xmlrpc++ was being bundled in the package. A bundling exception was not granted[1] even though xmlrpc++ is not currently in Fedora so upstream has developed a stand alone library, flxmlrpc, to fix the problem and I have submitted a review request for it: https://bugzilla.redhat.com/show_bug.cgi?id=1214467 It's a very simple library so it should be a very simple review if someone could help me out quickly. Thanks, Richard [1] https://fedorahosted.org/fpc/ticket/515 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Thursday's FPC Meeting (2015-04-23 16:00 UTC) Followups:6 New:1
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2015-04-23 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. rktime):
2015-04-23 09:00 Thu US/Pacific PDT
2015-04-23 12:00 Thu US/Eastern EDT
2015-04-23 16:00 Thu UTC <-
2015-04-23 17:00 Thu Europe/London BST
2015-04-23 18:00 Thu Europe/Paris CEST
2015-04-23 18:00 Thu Europe/Berlin CEST
2015-04-23 21:30 Thu Asia/Calcutta IST
--new day--
2015-04-24 00:00 Fri Asia/Singapore SGT
2015-04-24 00:00 Fri Asia/Hong_Kong HKT
2015-04-24 01:00 Fri Asia/Tokyo JST
2015-04-24 02:00 Fri Australia/Brisbane EST
Links to all tickets below can be found at:
https://fedorahosted.org/fpc/report/13
= Followups =
#topic #281 New Python Macros for Easier Packaging
.fpc 281
https://fedorahosted.org/fpc/ticket/281
#topic #303 Consider reverting decision to ban %{?_isa} in
BuildRequires
.fpc 303
https://fedorahosted.org/fpc/ticket/303
#topic #508 New GID for openstack-neutron
.fpc 508
https://fedorahosted.org/fpc/ticket/508
#topic #513 Use python -Es in shbang
.fpc 513
https://fedorahosted.org/fpc/ticket/513
#topic #520 [Guidelines Draft] Per-Product Configuration Defaults v2
.fpc 520
https://fedorahosted.org/fpc/ticket/520
#topic #524 static UID for ceph
.fpc 524
https://fedorahosted.org/fpc/ticket/524
= New business =
#topic #525 Request for bundling exception: plotnetcfg, contains
parson library
.fpc 525
https://fedorahosted.org/fpc/ticket/525
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at:
https://fedorahosted.org/fpc/report/13
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/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Meetting Minutes for Wednesday's FESCo Meeting (2015-04-22)
=== #fedora-meeting: FESCO (2015-04-22) === Meeting started by jwb at 18:00:14 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-04-22/fesco.2015-04-22-18.00.log.html . Meeting summary --- * init process (jwb, 18:00:22) * rishi paragan nirik jwb dgilmore are here (jwb, 18:20:24) * #1428 cloud vagrant box (jwb, 18:20:43) * LINK: https://fedorahosted.org/fesco/ticket/1428 (jwb, 18:20:45) * AGREED: Vote from last week stands. Change remains pushed back to F23 (jwb, 18:45:05) * #1429 Make explicit spec file License mandatory (jwb, 18:45:59) * LINK: https://fedorahosted.org/fesco/ticket/1429 (jwb, 18:46:00) * AGREED: Explict mandatory spec file licenses are not required (jwb, 18:48:15) * #1430 Fedora 23 schedule proposal (jwb, 18:48:29) * LINK: https://fedorahosted.org/fesco/ticket/1430 (jwb, 18:48:29) * AGREED: add 1 week after alpha ships, before beta freeze, move later milestones out a week and release oct 26th (jwb, 19:07:13) * Open Floor (jwb, 19:07:53) * dgilmore looking into making rawhide composes more like release composes to help with testing (jwb, 19:10:14) * dgilmore to chair next week (jwb, 19:11:53) Meeting ended at 19:12:47 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * jwb (106) * dgilmore (49) * nirik (41) * rishi (29) * jreznik (22) * mattdm (16) * imcleod (11) * zodbot (7) * paragan (6) * jkurik (5) * roshi (4) * stickster (3) * kushal (2) * drago01 (1) * sgallagh (0) * mitr (0) * ajax (0) * thozza (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review needed to resolve bundling issue.
My package, fldigi, has been in Fedora for some time, but in attempting to get other related projects into Fedora from the same upstream, it was discovered that a fork of xmlrpc++ was being bundled in the package. A bundling exception was not granted[1] even though xmlrpc++ is not currently in Fedora so upstream has developed a stand alone library, flxmlrpc, to fix the problem and I have submitted a review request for it: https://bugzilla.redhat.com/show_bug.cgi?id=1214467 It's a very simple library so it should be a very simple review if someone could help me out quickly. Thanks, Richard [1] https://fedorahosted.org/fpc/ticket/515 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Annonce: qt-virt-manager
Hi, all! I'm developing qt-virt-manager. I have to say: this is not a Qt-clone of the virt-manager. The application is able to perform a lot, so I suggest you to use, and look forward to your wishes. (I'm make fedora-build, if somebody build it for other distributives, then , pls, say to me for annonce on opendesktop.org site.) https://github.com/F1ash/qt-virt-manager https://f1ash.fedorapeople.org/qt-virt-manager/ http://opendesktop.org/content/show.php/qt-virt-manager?content=169785 -- Fl@sh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Annonce: qt-virt-manager
Hi, all! I'm developing qt-virt-manager. I have to say: this is not a Qt-clone of the virt-manager. The application is able to perform a lot, so I suggest you to use, and look forward to your wishes. (I'm make fedora-build, if somebody build it for other distributives, then , pls, say to me for annonce on opendesktop.org site.) https://github.com/F1ash/qt-virt-manager https://f1ash.fedorapeople.org/qt-virt-manager/ http://opendesktop.org/content/show.php/qt-virt-manager?content=169785 -- Fl@sh -- 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 1214130] Broken dependency perl-Carp-1.36-1.fc21.noarch requires perl-4:5.18.4-308.fc21.x86_64 on upgrade to F22
https://bugzilla.redhat.com/show_bug.cgi?id=1214130 Ralf Corsepius changed: What|Removed |Added CC||rc040...@freenet.de --- Comment #2 from Ralf Corsepius --- This is not a problem with the perl-Carp package, this is a rel-eng issue. They unleashed a higher version of perl-Carp for fc21 than for fc22. Actually, they released an update for fc21 while the version for fc22 is stuck in the release freeze. That said, I think this BZ should be closed and rel-eng be flamed ;) -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Contact info for FAS user: anishpatil
On Wed, Apr 22, 2015 at 01:38:39PM +0100, Ankur Sinha wrote: > On Tue, 2015-04-21 at 15:05 +0200, Mathieu Bridon wrote: > > On Tue, 2015-04-21 at 15:01 +0200, Robert Mayr wrote: > > > Maybe his RH address? > > > apa...@redhat.com > > > > Anish just left Red Hat. > > > > He is also moving countries, so maybe that's why he hasn't been very > > responsive lately? > > I just spoke to him yesterday. He has indeed moved. I'll ask him to > get in touch with infra. Thanks! If you get in touch with him again, just ask him to check his emails, he should have a bunch of emails from us corresponding to the fact that there is no bugzilla account corresponding to his email in FAS (which is required for all packager). Pierre pgpMWiGPy2dzY.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: yumdownloader vs dnf??????
On 04/22/2015 05:15 PM, Kevin Fenzi wrote: > On Wed, 22 Apr 2015 16:52:54 +0200 > Joachim Backes wrote: > >> As yum has been replaced by dnf, there is a question for me: will >> yumdownloader (installed by yum-utils.rpm) be replaced by something >> like dnfdownloader (installed for example by (a new) dnf-utils.rpm)? > > There's a plugin... > > dnf download > > See: man dnf.plugin.download > > kevin > Thanks to all who replied: dnf.plugin.download is what I need. Kind regards Joachim Backes -- Fedora release 22 (Twenty Two) Kernel-4.0.0-1.fc22.x86_64 Joachim Backes https://www-user.rhrk.uni-kl.de/~backes -- 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: yumdownloader vs dnf??????
HI On Wed, Apr 22, 2015 at 11:19 AM, Richard Shaw wrote: > I'm not volunteering! > > ...but perhaps a yum->dnf transition guide on the Fedora wiki would be > nice which would cover things like this. > https://fedoraproject.org/wiki/Yum_to_DNF_Cheatsheet Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: yumdownloader vs dnf??????
Hi, On Wed, Apr 22, 2015 at 8:49 PM, Richard Shaw wrote: > I'm not volunteering! > > ...but perhaps a yum->dnf transition guide on the Fedora wiki would be nice > which would cover things like this. Since dnf development started, its developers have kept the documentation also updated. You can find all the needed things at http://dnf.readthedocs.org/en/latest. Also check this http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#changes-in-dnf-plugins-compared-to-yum-utilities and http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#changes-in-dnf-plugins-compared-to-yum-plugins pages. Regards, Parag. -- 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: yumdownloader vs dnf??????
I'm not volunteering! ...but perhaps a yum->dnf transition guide on the Fedora wiki would be nice which would cover things like this. Richard -- 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: yumdownloader vs dnf??????
On 04/22/2015 05:15 PM, Kevin Fenzi wrote: > There's a plugin... In package dnf-plugin-core -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- 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: yumdownloader vs dnf??????
On Wed, 22 Apr 2015 16:52:54 +0200 Joachim Backes wrote: > As yum has been replaced by dnf, there is a question for me: will > yumdownloader (installed by yum-utils.rpm) be replaced by something > like dnfdownloader (installed for example by (a new) dnf-utils.rpm)? There's a plugin... dnf download See: man dnf.plugin.download kevin pgpXAzlv0HKvv.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
yumdownloader vs dnf??????
As yum has been replaced by dnf, there is a question for me: will yumdownloader (installed by yum-utils.rpm) be replaced by something like dnfdownloader (installed for example by (a new) dnf-utils.rpm)? Kind regards Joachim Backes -- Fedora release 22 (Twenty Two) Kernel-4.0.0-1.fc22.x86_64 Joachim Backes https://www-user.rhrk.uni-kl.de/~backes -- 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: /usr/share vs /usr/libexec
On Wed, 22 Apr 2015, Miloslav Trmač wrote: now I'm curious. Does it make more sense for these sort of scripts to live in /usr/libexec, or in /usr/share? /usr/libexec. From (info standards): `libexecdir' The directory for installing executable programs to be run by other programs rather than by users. The thing that threw me is that I poked around in /usr/share and found this: $ cat /bin/createrepo #!/bin/sh exec /usr/share/createrepo/genpkgmetadata.py "$@" Given what you're saying, would this be considered a bug in createrepo? Then we get into philosophical discussions about what is “the program” and what is “data used by the program”… In this case, the /usr/share/createrepo/* paths are not a documented stable API (but /usr/bin/createrepo is), and Python programs consisting of multiple files are easier to run and develop if all the files are in the same directory, so this seems a reasonable way to do things. Seems like a good match to put into libexec to me, Paul -- 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: /usr/share vs /usr/libexec
> On Wed, Apr 22, 2015 at 8:06 AM, Miloslav Trmač wrote: > > Hello, > >> I confess I've only seen /usr/libexec used for add-on utilities, but > >> now I'm curious. > >> > >> Does it make more sense for these sort of scripts to live in > >> /usr/libexec, or in /usr/share? > > > > /usr/libexec. From (info standards): > > > >> `libexecdir' > >> The directory for installing executable programs to be run by other > >> programs rather than by users. > > > > The thing that threw me is that I poked around in /usr/share and found this: > > $ cat /bin/createrepo > #!/bin/sh > exec /usr/share/createrepo/genpkgmetadata.py "$@" > > Given what you're saying, would this be considered a bug in createrepo? Then we get into philosophical discussions about what is “the program” and what is “data used by the program”… In this case, the /usr/share/createrepo/* paths are not a documented stable API (but /usr/bin/createrepo is), and Python programs consisting of multiple files are easier to run and develop if all the files are in the same directory, so this seems a reasonable way to do things. 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: /usr/share vs /usr/libexec
On Wed, Apr 22, 2015 at 8:06 AM, Miloslav Trmač wrote: > Hello, >> I confess I've only seen /usr/libexec used for add-on utilities, but >> now I'm curious. >> >> Does it make more sense for these sort of scripts to live in >> /usr/libexec, or in /usr/share? > > /usr/libexec. From (info standards): > >> `libexecdir' >> The directory for installing executable programs to be run by other >> programs rather than by users. > The thing that threw me is that I poked around in /usr/share and found this: $ cat /bin/createrepo #!/bin/sh exec /usr/share/createrepo/genpkgmetadata.py "$@" Given what you're saying, would this be considered a bug in createrepo? There are a lot of Python files in /usr/share, but createrepo was one that's the most obvious to me (simply shelling out to a file in /usr/share). Similarly, there are a lot of executable files: (find /usr/share/ -executable -type f) Are these all bugs? - Ken -- 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: /usr/share vs /usr/libexec
Hello, > I confess I've only seen /usr/libexec used for add-on utilities, but > now I'm curious. > > Does it make more sense for these sort of scripts to live in > /usr/libexec, or in /usr/share? /usr/libexec. From (info standards): > `libexecdir' > The directory for installing executable programs to be run by other > programs rather than by users. vs. > Data files _used by the program during its execution_ (emphasis mine) starting the section that talks about */share 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
/usr/share vs /usr/libexec
Hi folks, The Ceph package ships some utilities that are not intended to be run by users. 1. There's one utility that prepares Ceph's object storage daemon and that is at is in /usr/libexec/ceph/ceph-osd-prestart.sh . The systemd unit file calls that with "ExecStartPre=". 2. There are some other utilities that are only used by udev, and these are currently in /usr/bin. I was going to move these to /usr/libexec , but someone brought up the point that all these files are architecture-independent, so perhaps they should go into /usr/share. [1] I confess I've only seen /usr/libexec used for add-on utilities, but now I'm curious. Does it make more sense for these sort of scripts to live in /usr/libexec, or in /usr/share? - Ken [1] http://tracker.ceph.com/issues/10725#note-8 -- 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: Contact info for FAS user: anishpatil
On Tue, 2015-04-21 at 15:05 +0200, Mathieu Bridon wrote: > On Tue, 2015-04-21 at 15:01 +0200, Robert Mayr wrote: > > Maybe his RH address? > > apa...@redhat.com > > Anish just left Red Hat. > > He is also moving countries, so maybe that's why he hasn't been very > responsive lately? I just spoke to him yesterday. He has indeed moved. I'll ask him to get in touch with infra. -- Thanks, Regards, Ankur Sinha "FranciscoD" http://fedoraproject.org/wiki/User:Ankursinha signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2015-04-22)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2015-04-22 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1428 cloud vagrant box .fesco 1428 https://fedorahosted.org/fesco/ticket/1428 = New business = #topic #1429 Make explicit spec file License mandatory .fesco 1429 https://fedorahosted.org/fesco/ticket/1429 #topic #1430 Fedora 23 schedule proposal .fesco 1430 https://fedorahosted.org/fesco/ticket/1430 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: qt5 as default?
Antti J=?iso-8859-1?B?5A==?=rvinen wrote: > There is also same decision to make regarding libraries that have not been > re-packaged to support both qt4 and qt5. One good example is > https://admin.fedoraproject.org/pkgdb/package/qjson/ > -> there is no separate binary package libqjson-qt5 and libqjson-qt4. The > library from source works all right with both but if the library is > built and linked against qt4, it can also be used to build application > that links against qt5 and everything goes all right. Only downside is > immediate SIGSEGV when you invoke methods from the library :) For libraries that support both, the general best practice is to change library soname for Qt5 builds, to ensure the scenarios you describe doesn't happen accidentally. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20150422 changes
Compose started at Wed Apr 22 05:15:02 UTC 2015 Broken deps for i386 -- [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [aeskulap] aeskulap-0.2.2-0.19beta1.fc22.i686 requires libofstd.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires liboflog.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg8.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg16.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg12.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmnet.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmjpeg.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimgle.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimage.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmdata.so.3.6 [aunit] aunit-2013-7.fc22.i686 requires libgnat-4.9.so [aws] aws-3.1.0-12.fc22.i686 requires libgnat-4.9.so aws-3.1.0-12.fc22.i686 requires libgnarl-4.9.so aws-devel-3.1.0-12.fc22.i686 requires libgnat-4.9.so aws-devel-3.1.0-12.fc22.i686 requires libgnarl-4.9.so [bro] broccoli-2.3.2-1.fc23.i686 requires bro-2.3.2 python-broccoli-2.3.2-1.fc23.i686 requires bro-2.3.2 [crystal] crystal-2.2.1-2.fc22.i686 requires libkdecorations.so.4 [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dsqlite] dsqlite-1.1.1-5.fc22.i686 requires libphobos-ldc.so.64 [elk] elk-mpich-2.3.22-10.fc22.i686 requires libopa.so.1 elk-mpich-2.3.22-10.fc22.i686 requires libmpl.so.1 elk-mpich-2.3.22-10.fc22.i686 requires libmpichf90.so.12 elk-mpich-2.3.22-10.fc22.i686 requires libmpich.so.12 [fawkes] fawkes-plugin-player-0.5.0-19.fc22.i686 requires libboost_thread.so.1.55.0 fawkes-plugin-player-0.5.0-19.fc22.i686 requires libboost_system.so.1.55.0 fawkes-plugin-player-0.5.0-19.fc22.i686 requires libboost_signals.so.1.55.0 [florist] florist-2011-16.fc22.i686 requires libgnat-4.9.so florist-2011-16.fc22.i686 requires libgnarl-4.9.so [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 [gl3n] gl3n-0.20140505-13.fc22.i686 requires libphobos-ldc.so.64 [gnatcoll] gnatcoll-2013-9.fc22.i686 requires libgnat-4.9.so gnatcoll-2013-9.fc22.i686 requires libgnarl-4.9.so [hadoop] hadoop-common-2.4.1-6.fc22.noarch requires mvn(io.netty:netty:3.6.6.Final) hadoop-hdfs-2.4.1-6.fc22.noarch requires mvn(org.jboss.netty:netty:3.6.6.Final) hadoop-hdfs-2.4.1-6.fc22.noarch requires mvn(io.netty:netty:3.6.6.Final) hadoop-mapreduce-2.4.1-6.fc22.noarch requires mvn(io.netty:netty:3.6.6.Final) hadoop-tests-2.4.1-6.fc22.noarch requires mvn(io.netty:netty:3.6.6.Final) [hbase] hbase-0.98.3-2.fc22.noarch requires mvn(io.netty:netty:3.6.6.Final) hbase-tests-0.98.3-2.fc22.noarch requires mvn(io.netty:netty:3.6.6.Final) [julia] julia-0.3.7-2.fc23.i686 requires libLLVM-3.5.so julia-devel-0.3.7-2.fc23.i686 requires libLLVM-3.5.so [kde-style-skulpture] kde-style-skulpture-0.2.4-9.fc22.i686 requires libkdecorations.so.4 [leksah] ghc-leksah-0.12.1.3-16.fc22.i686 requires libHSxhtml-3000.2.1-ghc7.6.3.so ghc-leksah-0.12.1.3-16.fc22.i686 requires libHSutf8-string-0.3.7-ghc7.6.3.so ghc-leksah-0.12.1.3-16.fc22.i686 requires libHSunix-2.6.0.1-ghc7.6.3.so ghc-leksah-0.12.1.3-16.fc22.i686 requires libHStransformers-0.3.0.0-ghc7.6.3.so ghc-leksah-0.12.1.3-16.fc22.i686 requires libHStime-1.4.0.1-ghc7.6.3.so ghc-leksah-0.12.1.3-16.fc22.i686 requires libHStext-0.11.3.1-ghc7.6.3.so ghc-leksah-0.12.1.3-16.fc22.i686 requires libHStemplate-haskell-2.8.0.0-ghc7.6.3.so ghc-leksah-0.12.1.3-16.fc22.i686 requires libHSstrict-0.3.2-ghc7.6.3.so ghc-leksah-0.12.1.3-16.fc22.i686 requires libHSregex-tdfa-1.1.8-ghc7.6.3.so ghc-leksah-0.12.1.3-16.fc22.i686 requires libHSregex-base-0.93.2-ghc7.6.3.so ghc-leksah-0.12.1.3-16.fc22.i686 requires libHSrandom-1.0.1.1-ghc7.6.3.so ghc-leksah-0.12.1.3-16.fc22.i686 requires libHSprocess-1.1.0.2-ghc7.6.3.so ghc-leksah-0.12.1.3-16.fc22.i686 requires libHSpretty-1.1.1.0-ghc7.6.3.so ghc-leksah-0.12.1.3-16.fc22.i686 requires libHSparsec-3.1.3-ghc7.6.3.so ghc-leksah-0.12.1.3-16.fc22.i686 requires libHSpango-0.12.5.0-ghc7.6.3.so ghc-leksah-0.12.1.3-16.fc22.i686 requires libHSold-time-1.1.0.1-ghc7.6.3.so ghc-leksah-0.12.1
Re: qt5 as default?
Kevin Kofler writes: > For applications that support both? In the absence of other criteria (e.g. > features that are not yet ported, or conversely, features that require Qt > 5), the rule of thumb is to build against Qt 5 on Fedora 22 and newer, and > against Qt 4 on Fedora 21 and older. There is also same decision to make regarding libraries that have not been re-packaged to support both qt4 and qt5. One good example is https://admin.fedoraproject.org/pkgdb/package/qjson/ -> there is no separate binary package libqjson-qt5 and libqjson-qt4. The library from source works all right with both but if the library is built and linked against qt4, it can also be used to build application that links against qt5 and everything goes all right. Only downside is immediate SIGSEGV when you invoke methods from the library :) -- Antti -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
