Re: aoetools package updates from upstream
在 2013-8-21 PM1:28，Tomasz Torcz to...@pipebreaker.pl写道： Also on related note: vblade package (the AoE server) was on recent orphans list. If it's not taken, the other half of aoe stack will disappear from Fedora. Damn... it's deprecated now. Can Dennis unretire it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
headup : libzip 0.11 in rawhide (and PHP change)
Hi. I have updated libzip to 0.11.1 in rawhide. Despite there is no soname change, see: http://upstream-tracker.org/versions/libzip.html So I think it is preferable to rebuild dependent packages to ensure all is ok. As PHP only work with libzip 0.10 (use lot of private stuff), the zip extension is become unmaintainable, so have been dropped from php. So we are going to receive tons of broken deps for pakages requiring php-zip. I just submit php-pecl-zip to review [1] This extension (from the same sources, but updated for libzip 0.11) is of course absolutely compatible. It will be really simpler to sync the life cyle of this extension with the library. Remi [1] https://bugzilla.redhat.com/show_bug.cgi?id=999313 -- 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: Self Introduction
Dne 20.8.2013 20:28, Frankie Onuonga napsal(a): On Tue, 2013-08-20 at 13:01 -0400, Matthew Miller wrote: On Tue, Aug 20, 2013 at 07:35:54PM +0300, Frankie Onuonga wrote: I am hoping to assist in packaging if required. what are you interested in? Anything specific? Languages? I would like something that is cloud related but, I do not think I can be too picky when it comes to this. Awesome. Come join the Fedora Cloud SIG http://fedoraproject.org/wiki/Cloud_SIG by signing up for our mailing list. Cloud is, of course, a big topic -- any particular area of interest there? well I saw there was some work, on one the pages that required someone to do something. I can not recall that well but let me search through. all i recall was seeing openshift there. It looked interesting. I am not too sure if this is a place to start. I will therefore ask that I be given something to get my fingers dirty. I honestly do not think I can be picky on this. I am here to learn with an open mind, heart and hands. thank you. Not sure how much it is cloud related, but there is list of bugs which should be easy to fix [1], so you might want to choose one of them. Vít [1] http://fedoraproject.org/easyfix/ -- 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: RFC: Spins process changes proposal
On 20 August 2013 19:29, Kevin Fenzi ke...@scrye.com wrote: Each approved spin MUST have at least 1 person fill in a basic spin test matrix for at least 1 TC or RC in order to be shipped with Alpha. If the image fails or there are no test results maintainers can try again at the next milestone, but the image is NOT shipped with Alpha. My only question is what happens when something higher up is causing all composes to fail, IIRC that was the case for a while for F18. Do all the spins have to follow this process to try and maintain approval in that case? -- imalone http://ibmalone.blogspot.co.uk -- 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: slowing down the development schedule for a release.
On Wed, Aug 21, 2013 at 9:12 AM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 20 Aug 2013 23:37:44 -0400 Matthew Miller mat...@fedoraproject.org wrote: On Tue, Aug 20, 2013 at 09:09:03PM -0400, Josh Boyer wrote: Without spinning the wheel of blame -- at Flock, we talked about slowing down the crazy train a little bit, probably not for F20 at this point but for F21, specifically so we all have a chance to work on those kind of things. Why not F20? FESCo perpetuated the we don't have a schedule yet so Um, I asked Dennis and he said it was too late for that to be useful. So there's that. :) we have already started so many of the release processes that it is really hard to stop and postpone things. not impossible, just makes things very difficult. We started on the tasks for fedora 20 about a week after f19 was done due to the schedule that was setup. The whole discussion does not make much sense unless we know what you exactly want to do, how much time you need for it and why it can't be done during a release cycle and deployed for the next release. Currently this reads like I need more time to do something. -- 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: slowing down the development schedule for a release.
On 21 Aug 2013 08:13, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 20 Aug 2013 23:37:44 -0400 Matthew Miller mat...@fedoraproject.org wrote: On Tue, Aug 20, 2013 at 09:09:03PM -0400, Josh Boyer wrote: Without spinning the wheel of blame -- at Flock, we talked about slowing down the crazy train a little bit, probably not for F20 at this point but for F21, specifically so we all have a chance to work on those kind of things. Why not F20? FESCo perpetuated the we don't have a schedule yet so Um, I asked Dennis and he said it was too late for that to be useful. So there's that. :) we have already started so many of the release processes that it is really hard to stop and postpone things. not impossible, just makes things very difficult. We started on the tasks for fedora 20 about a week after f19 was done due to the schedule that was setup. With the branch for F-20 just complete it makes it the perfect time to begin the change of process for F-21 then so let's keep the discussion going of what we should be doing now as F-21 is officially open for business... Otherwise we'll get to this stage in F-21 and be having the same conversation. OMG its like we're growing up or something! Peter Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIUaHAACgkQkSxm47BaWfeSRwCdGg4PAZ2S7/YVTC7XJd76cgXd f7EAoI2gKte1K0u+bM76vV/s0N8L4G5m =EcWo -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 -- 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: slowing down the development schedule for a release.
On Aug 21, 2013, at 1:54 AM, Peter Robinson pbrobin...@gmail.com wrote: With the branch for F-20 just complete it makes it the perfect time to begin the change of process for F-21 then so let's keep the discussion going of what we should be doing now as F-21 is officially open for business... Otherwise we'll get to this stage in F-21 and be having the same conversation. OMG its like we're growing up or something! What are the options? Push 21 back 3 months, and then 8 month instead of 6 month intervals? Chris Murphy -- 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: slowing down the development schedule for a release.
On Wed, Aug 21, 2013 at 1:36 PM, Chris Murphy li...@colorremedies.com wrote: What are the options? Push 21 back 3 months, and then 8 month instead of 6 month intervals? May be pushing 21 for whole 6 months, which will give enough time to concentrate to the existing issues. Another option can be with keeping same 6months time frame but saying instead of adding 20 new features, we will fix existing issues to have a solid release. Kushal -- http://fedoraproject.org http://kushaldas.in -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
fipscheck openssl / Re: Obsoletes, Obsoletes, Obsoletes
On Wed, 21 Aug 2013 08:57:38 +0200, Tomas Mraz wrote: I have openssl and fipscheck obsoletes on the list. They were added because the base openssl (and fipscheck) package was split into openssl-libs and openssl subpackages where only the openssl-libs is needed unless something requires the openssl command to work. I've added the obsoletes into the openssl-libs on the old (non-split) openssl package according to the https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages But once you install the new split openssl package it should not be obsoleted by openssl-libs so I think the obsoletes are correct. Yes, they have been correct, but they are aging. For fipscheck, the Obsoletes don't work anymore for packages in Fedora 16 and onwards, starting with a build from Fedora 15: fipscheck-0:1.3.0-2.fc15.i686 isn't obsoleted fipscheck 0:1.2.0-1 obsoleted by fipscheck-lib-0:1.3.1-4.fc20.i686 Hence the 2nd list I've created is called dubious. For openssl, it's Fedora 18 and onwards, so the Obsoletes still cover something in F17 and F16. No worries. -- 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: headup : libzip 0.11 in rawhide + F20 (and PHP change)
Le 21/08/2013 09:38, Remi Collet a écrit : Hi. I have updated libzip to 0.11.1 in rawhide. And in F20 branched too. -- 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 (2013-08-21)
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 '-MM-DD HH:MM UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1077 Drop usage of --vendor from .desktop files .fesco 1077 https://fedorahosted.org/fesco/ticket/1077 #topic #1148 F20 System Wide Change: Application Installer - https://fedoraproject.org/wiki/Changes/AppInstaller .fesco 1148 https://fedorahosted.org/fesco/ticket/1148 #topic BlueZ System Wide Change - https://fedoraproject.org/wiki/Changes/Bluez5 (No fesco ticket yet) = New business = #topic #1157 change the way Initial Hosting Requests are processed .fesco 1157 https://fedorahosted.org/fesco/ticket/1157 #toic 1158 post-Flock Fedora rings + target products draft proposal for Fedora board .fesco 1158 https://fedorahosted.org/fesco/ticket/1158 = 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. -Toshio pgpJP1NaIefNw.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
php-gettext
What's the full story here? php-gettext php-gettext-0:1.0.11-5.fc20.noarch isn't obsoleted php-gettext-0:1.0.11-4.fc19.noarch isn't obsoleted php-gettext-0:1.0.11-3.fc18.noarch isn't obsoleted php-gettext-0:1.0.9-3.fc15.noarch is oldest php-gettext 0:1.0.11-3 obsoleted by php-php-gettext-0:1.0.11-8.fc20.noarch Searching a bit, there has been a rename to php-php-gettext and plans to retire php-gettext because it conflicts with the core module, but the package has been kept in the dist and mass-rebuilt several times: http://koji.fedoraproject.org/koji/packageinfo?packageID=9618 So, meanwhile, the Obsoletes tag is insufficient, and the package is available again. Is this intentional? Else, please retire it: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life # repoquery --whatprovides php-gettext php-common-0:5.5.2-1.fc19.x86_64 php-common-0:5.5.2-1.fc19.i686 php-common-0:5.5.0-0.10.RC3.fc19.i686 php-common-0:5.5.1-1.fc19.x86_64 php-gettext-0:1.0.11-4.fc19.noarch php-common-0:5.5.0-0.10.RC3.fc19.x86_64 php-common-0:5.5.1-1.fc19.i686 -- 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: slowing down the development schedule for a release.
- Original Message - On Tue, Aug 20, 2013 at 8:57 PM, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Aug 20, 2013 at 06:47:31PM -0500, Dennis Gilmore wrote: I need to update the documentation. But we need to get to the point where the releng side is transparent and just happens. The crazy schedules we have had since f18 have allowed zero time for Release Engineering and QA to do much in the line of development. this is entirely a failure of FESCo Without spinning the wheel of blame -- at Flock, we talked about slowing down the crazy train a little bit, probably not for F20 at this point but for F21, specifically so we all have a chance to work on those kind of things. Why not F20? FESCo perpetuated the we don't have a schedule yet so we'll do the Not-Before-XXX-Date thing long enough that it's certainly able to do so to extend the schedule. I fail to see the point in forcing an F20 schedule that various parties think is crazy just for the sake of sticking to some nebulous dates. If you're wary of the holiday break (which you should be), then push it out well past that. It's too late for F20 I'd say. And yeah, I told people who wanted to do bigger stuff for F20, to propose it and for example for QA automation, I'd say there would be support for moving it for a few months... So everyone had a chance to talk in the right time, restarting it now once we're branched it's not fair to people, who really submitted theirs Changes and already planned the development. And yeah, at Flock, we talked about making more space for F21 - we can't do releases and new next Fedoras together. One option was skipping F21 and doing a bigger update instead of release (use bundled updates if available that time?). But Fedora.next still depends on resources - if we would even have enough power to do things (mostly everything can be done immediately, just nobody is working on it/ interested in this time). So I don't expect we would be able to start that movement now and release F20 later. Jaroslav Continuing to think that we're going to fix the release schedule problems with the Next release is clearly not working. 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 -- 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: slowing down the development schedule for a release.
On Wed, Aug 21, 2013 at 10:13 AM, Kushal Das kushal...@gmail.com wrote: On Wed, Aug 21, 2013 at 1:36 PM, Chris Murphy li...@colorremedies.com wrote: What are the options? Push 21 back 3 months, and then 8 month instead of 6 month intervals? May be pushing 21 for whole 6 months, which will give enough time to concentrate to the existing issues. Another option can be with keeping same 6months time frame but saying instead of adding 20 new features, we will fix existing issues to have a solid release. What exactly do you want to fix? And how do features block you from fixing it? This is all to hand wavy. And you cannot force volunteers to just work on bugfixes for 6 months instead of working on new stuff if that's what you mean. (that would be pretty pointless anyway). The only conclusion I get out of this thread is that releng is apparently unable to cope with there tasks while making progress on improving stuff (whatever this improvements are). So we need more resources (people) working on releng stuff not force everyone to just fix bugs for 6 months. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
python-django insufficient Obsoletes
The Obsoletes tag for these python-django-foo renames is not high enough. A systematical error due to not considering the dist tag. django-extra-form-fields django-extra-form-fields-0:0.0.1-2.fc17.noarch isn't obsoleted django-extra-form-fields-0:0.0.1-1.fc16.noarch is oldest django-extra-form-fields 0:0.0.1-2 obsoleted by python-django-extra-form-fields-0:0.0.1-7.fc20.noarch django-followit django-followit-0:0.0.3-2.fc17.noarch isn't obsoleted django-followit-0:0.0.2-2.fc16.noarch is oldest django-followit 0:0.0.3-2 obsoleted by python-django-followit-0:0.0.3-6.fc20.noarch django-recaptcha-works django-recaptcha-works-0:0.3.4-3.fc18.noarch isn't obsoleted django-recaptcha-works-0:0.3.4-1.fc16.noarch is oldest django-recaptcha-works 0:0.3.4-3 obsoleted by python-django-recaptcha-works-0:0.3.4-5.fc20.noarch django-registration django-registration-0:0.7-4.fc18.noarch isn't obsoleted django-registration-0:0.7-2.fc16.noarch is oldest django-registration 0:0.7-4 obsoleted by python-django-registration-0:0.8-4.fc20.noarch -- 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: slowing down the development schedule for a release.
- Original Message - On Wed, Aug 21, 2013 at 10:13 AM, Kushal Das kushal...@gmail.com wrote: On Wed, Aug 21, 2013 at 1:36 PM, Chris Murphy li...@colorremedies.com wrote: What are the options? Push 21 back 3 months, and then 8 month instead of 6 month intervals? May be pushing 21 for whole 6 months, which will give enough time to concentrate to the existing issues. Another option can be with keeping same 6months time frame but saying instead of adding 20 new features, we will fix existing issues to have a solid release. What exactly do you want to fix? And how do features block you from fixing it? This is all to hand wavy. And you cannot force volunteers to just work on bugfixes for 6 months instead of working on new stuff if that's what you mean. (that would be pretty pointless anyway). The only conclusion I get out of this thread is that releng is apparently unable to cope with there tasks while making progress on improving stuff (whatever this improvements are). So we need more resources (people) working on releng stuff not force everyone to just fix bugs for 6 months. It's not only about releng but QA and other teams - time between F19 and F20 was pretty short. And yes, we're still trying to get into the pace again after F18 that cost us a lot... But if we really want to do bigger changes how we produce things, we really need time for it. For bugfixing - as I said, there's a chance of bigger bundled update accompanied with QA effort that could serve as a replacement for regular release (so it could contain a limited set of new stuff too). Jaroslav -- 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
Problem with sed in spec file
Hello, I'm adding a SELinux module to the gogoc package, as seen in this
draft [1], and I've received a error about the dependecies. In my spec
file I use this to extract the selinux-policy version and use it as a
dependency:
%global selinux_policyver %(%{__sed} -e
's,.*selinux-policy-\\([^/]*\\)/.*,\\1,'
/usr/share/selinux/devel/policyhelp || echo 0.0.0)
BuildRequires: openssl-devel
BuildRequires: systemd
BuildRequires: checkpolicy
BuildRequires: selinux-policy-devel
BuildRequires: /usr/share/selinux/devel/policyhelp
BuildRequires: hardlink
%if %{selinux_policyver} !=
Requires: selinux-policy = %{selinux_policyver}
%endif
I use mock to compile it for f19 and f20:
$ mock -r fedora-rawhide-x86_64 gogoc-1.2-30.fc20.src.rpm
$ mock -r fedora-19-x86_64 gogoc-1.2-30.fc20.src.rpm
And when I check the dependecies, I see it has been a problem with the
sed command in f20. What can be the cause? a problem with f20 rpm and
double back-slashes?
# everything ok in f19
$ rpm -qpR
/var/lib/mock/fedora-19-x86_64/result/gogoc-1.2-30.fc19.x86_64.rpm
/bin/sh
/bin/sh
/bin/sh
/sbin/fixfiles
/usr/sbin/semodule
/usr/sbin/semodule
config(gogoc) = 1.2-30.fc19
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.15)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libcrypto.so.10()(64bit)
libcrypto.so.10(libcrypto.so.10)(64bit)
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit)
libstdc++.so.6(GLIBCXX_3.4.11)(64bit)
libstdc++.so.6(GLIBCXX_3.4.15)(64bit)
libstdc++.so.6(GLIBCXX_3.4.9)(64bit)
policycoreutils-python
radvd
rpmlib(CompressedFileNames) = 3.0.4-1
rpmlib(FileDigests) = 4.6.0-1
rpmlib(PayloadFilesHavePrefix) = 4.0-1
rtld(GNU_HASH)
selinux-policy = 3.12.1
systemd
systemd
systemd
rpmlib(PayloadIsXz) = 5.2-1
# PROBLEM! the sed hasn't worked I have two bogus dependencies:
# file:///usr/share/doc/selinux-policy/html/index.htm
# selinux-policy = xdg-open
$ rpm -qpR
/var/lib/mock/fedora-rawhide-x86_64/result/gogoc-1.2-30.fc20.x86_64.rpm
/bin/sh
/bin/sh
/bin/sh
/sbin/fixfiles
/usr/sbin/semodule
/usr/sbin/semodule
config(gogoc) = 1.2-30.fc20
file:///usr/share/doc/selinux-policy/html/index.html
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.15)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libcrypto.so.10()(64bit)
libcrypto.so.10(libcrypto.so.10)(64bit)
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit)
libstdc++.so.6(GLIBCXX_3.4.11)(64bit)
libstdc++.so.6(GLIBCXX_3.4.15)(64bit)
libstdc++.so.6(GLIBCXX_3.4.9)(64bit)
policycoreutils-python
radvd
rpmlib(CompressedFileNames) = 3.0.4-1
rpmlib(FileDigests) = 4.6.0-1
rpmlib(PayloadFilesHavePrefix) = 4.0-1
rtld(GNU_HASH)
selinux-policy = xdg-open
systemd
systemd
systemd
rpmlib(PayloadIsXz) = 5.2-1
[1]
https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft
--
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: slowing down the development schedule for a release.
On Wed, Aug 21, 2013 at 12:36 PM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On Wed, Aug 21, 2013 at 10:13 AM, Kushal Das kushal...@gmail.com wrote: On Wed, Aug 21, 2013 at 1:36 PM, Chris Murphy li...@colorremedies.com wrote: What are the options? Push 21 back 3 months, and then 8 month instead of 6 month intervals? May be pushing 21 for whole 6 months, which will give enough time to concentrate to the existing issues. Another option can be with keeping same 6months time frame but saying instead of adding 20 new features, we will fix existing issues to have a solid release. What exactly do you want to fix? And how do features block you from fixing it? This is all to hand wavy. And you cannot force volunteers to just work on bugfixes for 6 months instead of working on new stuff if that's what you mean. (that would be pretty pointless anyway). The only conclusion I get out of this thread is that releng is apparently unable to cope with there tasks while making progress on improving stuff (whatever this improvements are). So we need more resources (people) working on releng stuff not force everyone to just fix bugs for 6 months. It's not only about releng but QA and other teams - time between F19 and F20 was pretty short. And still no word on *what* you exactly want to do and why it needs to skip a release. And yes, we're still trying to get into the pace again after F18 that cost us a lot... But if we really want to do bigger changes how we produce things, we really need time for it. We should do that once ready and not stop the release train for it. We did that once (F18) and we all know how this ended up. For bugfixing - as I said, there's a chance of bigger bundled update accompanied with QA effort We already can and do fix bugs in releases. that could serve as a replacement for regular release (so it could contain a limited set of new stuff too). This is rather pointless ... if we are going to such changes we could as well do a proper release. -- 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: slowing down the development schedule for a release.
On Wed, Aug 21, 2013 at 3:12 AM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 20 Aug 2013 23:37:44 -0400 Matthew Miller mat...@fedoraproject.org wrote: On Tue, Aug 20, 2013 at 09:09:03PM -0400, Josh Boyer wrote: Without spinning the wheel of blame -- at Flock, we talked about slowing down the crazy train a little bit, probably not for F20 at this point but for F21, specifically so we all have a chance to work on those kind of things. Why not F20? FESCo perpetuated the we don't have a schedule yet so Um, I asked Dennis and he said it was too late for that to be useful. So there's that. :) we have already started so many of the release processes that it is really hard to stop and postpone things. not impossible, just makes things very difficult. We started on the tasks for fedora 20 about a week after f19 was done due to the schedule that was setup. As far as I know, we've done a mass rebuild and we've branched. FESCo has closed the Changes. Beyond that, I don't know what else has actually started. Can you elaborate? Also, while there might be many tasks started, I don't really remember them having strict time windows. Pushing out all the dates starting today seems feasible to me. Clearly it can be done, because we keep slipping every release and we still have releases. 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: [AutoQA] #443: Update repoinfo.conf - Add branch
#443: Update repoinfo.conf - Add branch +- Reporter: ausil | Owner: Type: task| Status: closed Priority: critical| Milestone: 0.9.0 Component: production | Resolution: fixed Keywords: | Blocked By: Blocking: | +- Changes (by kparal): * milestone: Hot issues = 0.9.0 * resolution: = fixed * status: new = closed Comment: Thanks. I pushed the change as ecb4bbb and hot-fixed on autoqa-stg and autoqa-prd. -- Ticket URL: https://fedorahosted.org/autoqa/ticket/443#comment:1 AutoQA http://autoqa.fedorahosted.org Automated QA project ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Rawhide grub messed up
Hi, I just updated my rawhide machine and it stopped booting. I end up in grub rescue prompt, stating that there is no '/grub2/i386-pc/normal.mod'. grub rescue ls /grub2 ./ ../ themes/ grub.cfg grub rescue set prefix=(hd0,msdos1)/grub2 root=hd0,msdos1 Partition seems to be right, why msdos escapes me, though. How do I fix this mess? Cheers, -- Jan Synacek Software Engineer, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Problem with sed in spec file
On 21/08/13 12:21, Juan Orti Alcaine wrote:
Hello, I'm adding a SELinux module to the gogoc package, as seen in this
draft [1], and I've received a error about the dependecies. In my spec
file I use this to extract the selinux-policy version and use it as a
dependency:
%global selinux_policyver %(%{__sed} -e
's,.*selinux-policy-\\([^/]*\\)/.*,\\1,'
/usr/share/selinux/devel/policyhelp || echo 0.0.0)
This was an attempt to grok the selinux-policy version number without
querying the rpm database (which you can't reliably do during a package
build). Unfortunately there is no upstream version number for the policy
so the one used in Fedora is just made up. More unfortunately, the one
place I was reliably able to find it (in the policyhelp file) no longer
has it. In fact I can't find it anywhere in any of the
selinux-policy-{devel,doc} files in F-20. So there's no way I can see of
expressing the necessary dependency version in any sort of automated way.
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: Problem with sed in spec file
El 2013-08-21 11:49, Paul Howarth escribió:
On 21/08/13 12:21, Juan Orti Alcaine wrote:
Hello, I'm adding a SELinux module to the gogoc package, as seen in
this
draft [1], and I've received a error about the dependecies. In my spec
file I use this to extract the selinux-policy version and use it as a
dependency:
%global selinux_policyver %(%{__sed} -e
's,.*selinux-policy-\\([^/]*\\)/.*,\\1,'
/usr/share/selinux/devel/policyhelp || echo 0.0.0)
This was an attempt to grok the selinux-policy version number without
querying the rpm database (which you can't reliably do during a
package build). Unfortunately there is no upstream version number for
the policy so the one used in Fedora is just made up. More
unfortunately, the one place I was reliably able to find it (in the
policyhelp file) no longer has it. In fact I can't find it anywhere in
any of the selinux-policy-{devel,doc} files in F-20. So there's no way
I can see of expressing the necessary dependency version in any sort
of automated way.
Paul.
I see, this is because of the unversioned doc dirs in f20.
Now I'm testing this in mock and works ok:
%global selinux_policyver %(rpm -q selinux-policy | %{__sed} -e
's,selinux-policy-\\(.*\\)-.*,\\1,' || echo 0.0.0)
What's wrong about querying the version number to rpm? Can I do it?
--
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: headup : libzip 0.11 in rawhide (and PHP change)
Le 21/08/2013 09:38, Remi Collet a écrit : Hi. I have updated libzip to 0.11.1 in rawhide. Despite there is no soname change, see: http://upstream-tracker.org/versions/libzip.html So I think it is preferable to rebuild dependent packages to ensure all is ok. Build done, f20 and rawhide: libzip-0.11.1-1 php-5.5.3-1 (drop zip extension, so no more libzip dep) amftools-0.0-4.20121220svn32 ebook-tools-0.2.1-5 focuswriter-1.3.5.1-6 fuse-zip-0.2.12-9 libsigrok-0.2.1-2 nodejs-zipfile-0.4.0-2 openlierox-0.59-0.17.beta10 repsnapper-0:2.2.0-0.5.a4 Still TODO (but seems already FTBFS) subsurface-0:3.1 Remi. -- 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: Problem with sed in spec file
On 08/21/2013 02:00 PM, Juan Orti Alcaine wrote:
El 2013-08-21 11:49, Paul Howarth escribió:
On 21/08/13 12:21, Juan Orti Alcaine wrote:
Hello, I'm adding a SELinux module to the gogoc package, as seen in this
draft [1], and I've received a error about the dependecies. In my spec
file I use this to extract the selinux-policy version and use it as a
dependency:
%global selinux_policyver %(%{__sed} -e
's,.*selinux-policy-\\([^/]*\\)/.*,\\1,'
/usr/share/selinux/devel/policyhelp || echo 0.0.0)
This was an attempt to grok the selinux-policy version number without
querying the rpm database (which you can't reliably do during a
package build). Unfortunately there is no upstream version number for
the policy so the one used in Fedora is just made up. More
unfortunately, the one place I was reliably able to find it (in the
policyhelp file) no longer has it. In fact I can't find it anywhere in
any of the selinux-policy-{devel,doc} files in F-20. So there's no way
I can see of expressing the necessary dependency version in any sort
of automated way.
Paul.
I see, this is because of the unversioned doc dirs in f20.
Now I'm testing this in mock and works ok:
%global selinux_policyver %(rpm -q selinux-policy | %{__sed} -e
's,selinux-policy-\\(.*\\)-.*,\\1,' || echo 0.0.0)
What's wrong about querying the version number to rpm?
rpm doesn't work reliably inside of chroots.
Can I do it?
No.
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: slowing down the development schedule for a release.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Aug 2013 07:37:10 -0400 Josh Boyer jwbo...@fedoraproject.org wrote: On Wed, Aug 21, 2013 at 3:12 AM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 20 Aug 2013 23:37:44 -0400 Matthew Miller mat...@fedoraproject.org wrote: On Tue, Aug 20, 2013 at 09:09:03PM -0400, Josh Boyer wrote: Without spinning the wheel of blame -- at Flock, we talked about slowing down the crazy train a little bit, probably not for F20 at this point but for F21, specifically so we all have a chance to work on those kind of things. Why not F20? FESCo perpetuated the we don't have a schedule yet so Um, I asked Dennis and he said it was too late for that to be useful. So there's that. :) we have already started so many of the release processes that it is really hard to stop and postpone things. not impossible, just makes things very difficult. We started on the tasks for fedora 20 about a week after f19 was done due to the schedule that was setup. As far as I know, we've done a mass rebuild and we've branched. FESCo has closed the Changes. Beyond that, I don't know what else has actually started. Can you elaborate? Physically it can be done, now that we have branched it means we would have two development strains for awhile or we have a pain point somewhere. biggest issue is that FESCo set an expectation that a release will happen this year. all the hand waviness around dates doesn't relate to reality. Again my thoughts may be wrong but I don't think so. Also, while there might be many tasks started, I don't really remember them having strict time windows. Pushing out all the dates starting today seems feasible to me. Clearly it can be done, because we keep slipping every release and we still have releases. not having strict time windows is a new thing. Setting a date sets an expectation. There is big pain for all with slipping. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIUu14ACgkQkSxm47BaWfeP4wCgkMgaLHPLyvAzb6kbuKO/M92A MJMAnjg37ZqII7ZBHd55yxxeAJrDQH5A =e2gP -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
Re: Rawhide grub messed up
On 08/21/2013 01:41 PM, Jan Synacek wrote: Hi, I just updated my rawhide machine and it stopped booting. I end up in grub rescue prompt, stating that there is no '/grub2/i386-pc/normal.mod'. grub rescue ls /grub2 ./ ../ themes/ grub.cfg grub rescue set prefix=(hd0,msdos1)/grub2 root=hd0,msdos1 Partition seems to be right, why msdos escapes me, though. How do I fix this mess? In case somebody runs into the same problem, I managed to fix it. Mount and chroot to the root filesystem from a live cd and reinstall grub2 with 'grub2-install my-disk'. Simple yum reinstallation did nothing (there still was almost empty /boot/grub2 as shown in the original message). I'm not sure why there was nothing but themes and a config file in /boot/grub2 after the installation/reinstallation. I tried grub2-2.00-21.fc20.x86_64.rpm, grub2-2.00-23.fc20.x86_64.rpm and grub2-2.00-24.fc20.x86_64.rpm, all resulted in the same broken /boot/grub2. Anybody have any clue? Am I the only one that ran into this? Or is it broken? -- Jan Synacek Software Engineer, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-AnyEvent] Created tag perl-AnyEvent-7.05-1.fc21
The lightweight tag 'perl-AnyEvent-7.05-1.fc21' was created pointing to: c3b9734... Update to 7.05 -- 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-AnyEvent] Created tag perl-AnyEvent-7.05-1.fc20
The lightweight tag 'perl-AnyEvent-7.05-1.fc20' was created pointing to: c3b9734... Update to 7.05 -- 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: slowing down the development schedule for a release.
On 08/21/2013 03:06 PM, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Aug 2013 07:37:10 -0400 Josh Boyer jwbo...@fedoraproject.org wrote: As far as I know, we've done a mass rebuild and we've branched. FESCo has closed the Changes. Beyond that, I don't know what else has actually started. Can you elaborate? Physically it can be done, now that we have branched it means we would have two development strains for awhile or we have a pain point somewhere. biggest issue is that FESCo set an expectation that a release will happen this year. all the hand waviness around dates doesn't relate to reality. My thoughts are converse. IMO, FESCO's decision to branching now was prematiure and causes further non-helpful delays and hick-ups in preparing f20. Just one minor item: How do you expect people to test f20 fixes at the moment? There is no f20 repo on dl.fedoraproject.org, there are no f20 mock configurations on released Fedora releases in place, mirrormanager also so doesn't know about f20 yet, etc. ... Admitted, these issues are minor, but ... these are causing some amount churn on packager side and thus causes delays. 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: F20 Self Contained Change: Apache OpenOffice
On 25 July 2013 12:44, Jaroslav Reznik jrez...@redhat.com wrote: Change is accepted under the condition that the conflicts with libreoffice must be worked out. openoffice and libreoffice packagers get to work them out. There is no Fesco mandate that libreoffice must change to accomodate openoffice at this time. alternatives is not the way to resolve the conflicts but environment-modules may be looked at as a similar means to achieve that. mattdm wants this to be perfectly clear: FESCo does not grant automatic exceptions to our processes on any basis. Once again branch has been reached without so much as a package review request with a sample spec file... Can this farce please be ended and this 'self contained change' which is only there as a 'change' for PR by AOO be dropped and the proper channels for a new package be followed? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Data-Peek-0.39.tgz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Data-Peek: 2db6a9296df3f778282ca3dcd9d79e9a Data-Peek-0.39.tgz -- 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-Data-Peek] 0.39 bump
commit 751218150ad38797f1e953e8770dfe361c410569 Author: Jitka Plesnikova jples...@redhat.com Date: Wed Aug 21 15:56:42 2013 +0200 0.39 bump -- 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: slowing down the development schedule for a release.
On 08/21/2013 03:35 PM, Ralf Corsepius wrote: there are no f20 mock configurations on released Fedora releases in place Is fedpkg mock-config problematic? Either vanilla or after editing from baseurl=http://kojipkgs.fedoraproject.org//repos/f20-build/315000/x86_64 to baseurl=http://kojipkgs.fedoraproject.org//repos/f20-build/latest/x86_64 ? Thank you very much. Frantisek Kluknavsky -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
NOTE: Serf library 1.3.1 will land in f20 and rawhide soon
Hi, As serf upstream has released 1.3 and 1.3.1 bugfix for a long time, I'm going to push an update in the next week. Upstream had changed to scon so there needs some work. Serf is the default client library of Subversion and Apache OpenOffice. Subversion has been built with serf support for a while after serf got approved. Not sure about AOO now. Please check your package to see if there are any issues affected by the update. Thanks. -- 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: Self Introduction
On Wed, 2013-08-21 at 09:39 +0200, Vít Ondruch wrote: Dne 20.8.2013 20:28, Frankie Onuonga napsal(a): On Tue, 2013-08-20 at 13:01 -0400, Matthew Miller wrote: On Tue, Aug 20, 2013 at 07:35:54PM +0300, Frankie Onuonga wrote: I am hoping to assist in packaging if required. what are you interested in? Anything specific? Languages? I would like something that is cloud related but, I do not think I can be too picky when it comes to this. Awesome. Come join the Fedora Cloud SIG http://fedoraproject.org/wiki/Cloud_SIG by signing up for our mailing list. Cloud is, of course, a big topic -- any particular area of interest there? well I saw there was some work, on one the pages that required someone to do something. I can not recall that well but let me search through. all i recall was seeing openshift there. It looked interesting. I am not too sure if this is a place to start. I will therefore ask that I be given something to get my fingers dirty. I honestly do not think I can be picky on this. I am here to learn with an open mind, heart and hands. thank you. Not sure how much it is cloud related, but there is list of bugs which should be easy to fix [1], so you might want to choose one of them. I might be wrong here. Infact I am most likely wrong. but will def take a look. still trying to get my hands into things. Not sure who someone should ask to take this up. Vít [1] http://fedoraproject.org/easyfix/ 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
[perl-Data-Peek] 0.39 bump
commit 80dd9c87d3a7acedef34f951fb5b999d42d1 Author: Jitka Plesnikova jples...@redhat.com Date: Wed Aug 21 15:58:03 2013 +0200 0.39 bump .gitignore |1 + sources|2 +- 2 files changed, 2 insertions(+), 1 deletions(-) --- diff --git a/.gitignore b/.gitignore index 6d2d51b..10b0412 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,3 @@ /Data-Peek-0.33.tgz /Data-Peek-0.38.tgz +/Data-Peek-0.39.tgz diff --git a/sources b/sources index c117079..39f207f 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -e91d1fedeff01f4775b3eec668bb52ab Data-Peek-0.38.tgz +2db6a9296df3f778282ca3dcd9d79e9a Data-Peek-0.39.tgz -- 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: slowing down the development schedule for a release.
On 08/21/2013 04:01 PM, Frantisek Kluknavsky wrote: On 08/21/2013 03:35 PM, Ralf Corsepius wrote: there are no f20 mock configurations on released Fedora releases in place Is fedpkg mock-config problematic? No. fedpkg mockbuild for f20 and mock -r fedora-20-XXX are the problem. 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: slowing down the development schedule for a release.
On 08/21/2013 04:16 PM, Ralf Corsepius wrote: On 08/21/2013 04:01 PM, Frantisek Kluknavsky wrote: On 08/21/2013 03:35 PM, Ralf Corsepius wrote: there are no f20 mock configurations on released Fedora releases in place Is fedpkg mock-config problematic? No. fedpkg mockbuild for f20 and mock -r fedora-20-XXX are the problem. Ralf Maybe I misunderstand the purpose of fedpkg mock-config. I mean workflow like: 1. fedpkg switch-branch f20 2. fedpkg mock-config fedora-20-x86_64.cfg 3. (maybe edit fedora-20-x86_64.cfg ?) 4. sudo mv fedora-20-x86_64.cfg /etc/mock 5. fedpkg mockbuild where steps 2-4 are needed only once after branching. Is fedpkg mockbuild for f20 still problematic after that? I did it today, so now I am sincerely concerned about the trouble I am in (did not notice any). Fero -- 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: F20 System Wide Change: Web Assets
Le Dim 4 août 2013 10:44, Till Maas a écrit : On Tue, Jul 23, 2013 at 07:54:38PM +0200, Nicolas Mailhot wrote: Le Mar 23 juillet 2013 19:26, T.C. Hollingsworth a écrit : AFAICS it shouldn't be too hard to script up something so this would as easy as `fixfontmd --copyright $(head -n3 LICENSE) --licensedesc $(cat LICENSE) --licenseurl http://example.com/LICENSE` for packagers. I'd be happy to add a guideline for this and fix up existing packages if this seems amenable. If you can write a tool that makes it easy to fix opentype licensing fields at build time, I'll be delighted to support any guideline change that mandated its use. However if you go in this direction please check on the fonts and openfontlibrary list knowledgeable people agree there are no wrong side-effect (this will reach debian font packagers at least BTW) The guideline should be to ask upstream to fix the meta data. In case of missing license text (e.g. source code with a GPL header but no copy of the GPL itself), it is also upstream's task to fix it and the packager's to ask for it. And if upstream fixes it, the debian font packagers do not need to replicate Fedora's effort. This is already the guideline, the problem is what do you do when upstream postpones fixing to indefinitely later because licensing stuff is low-prio for them -- Nicolas Mailhot -- 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: F20 System Wide Change: Web Assets
Le Mar 6 août 2013 23:48, T.C. Hollingsworth a écrit : There's already some example instructions on how to use ttname here, which accurately reflects the CLI interface as it is now implemented: https://fedoraproject.org/wiki/User:Patches/ttname also please keep the fonts list in CC when discussing changes to fonts packaging in Fedora Thank's for working on this! -- Nicolas Mailhot -- 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: Problem with sed in spec file
On Wed, Aug 21, 2013 at 12:49:04PM +0100, Paul Howarth wrote:
On 21/08/13 12:21, Juan Orti Alcaine wrote:
Hello, I'm adding a SELinux module to the gogoc package, as seen in this
draft [1], and I've received a error about the dependecies. In my spec
file I use this to extract the selinux-policy version and use it as a
dependency:
%global selinux_policyver %(%{__sed} -e
's,.*selinux-policy-\\([^/]*\\)/.*,\\1,'
/usr/share/selinux/devel/policyhelp || echo 0.0.0)
This was an attempt to grok the selinux-policy version number
without querying the rpm database (which you can't reliably do
during a package build). Unfortunately there is no upstream version
number for the policy so the one used in Fedora is just made up.
More unfortunately, the one place I was reliably able to find it (in
the policyhelp file) no longer has it. In fact I can't find it
anywhere in any of the selinux-policy-{devel,doc} files in F-20. So
there's no way I can see of expressing the necessary dependency
version in any sort of automated way.
Just open a bug against selinux-policy and ask the maintainer
to drop a file somewhere which contains the version number, eg:
%install
echo '%{version}' $RPM_BUILD_ROOT%{_datadir}/selinux/version
We do something similar in the OCaml compiler base package.
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: slowing down the development schedule for a release.
On Wed, 21 Aug 2013 15:35:57 +0200 Ralf Corsepius rc040...@freenet.de wrote: Just one minor item: How do you expect people to test f20 fixes at the moment? There is no f20 repo on dl.fedoraproject.org, there are no f20 mock configurations on released Fedora releases in place, mirrormanager also so doesn't know about f20 yet, etc. ... We branched yesterday afternoon. The first branched compose is... composing right now. mock is being updated today. You can surely make a new f20 cfg file if you have some urgent need, or use a scratch build? mirrormanager picks up releases from the master mirror trees. See point one about a compose happening right now. Admitted, these issues are minor, but ... these are causing some amount churn on packager side and thus causes delays. This is a completely normal one day state. How can we compose a tree before we have branched? kevin signature.asc 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: slowing down the development schedule for a release.
IMHO, I'd prefer to do f20 as we have planned with the tight schedule, then after the holidays look at the proposals for fedora.next and base Fedora 21 on that. If we do much of the fedora.next setup it's going to require a lot of retooling and setup (just how much we can ask each team after we have more concrete proposals). kevin signature.asc 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: slowing down the development schedule for a release.
On 08/21/2013 05:18 PM, Kevin Fenzi wrote: On Wed, 21 Aug 2013 15:35:57 +0200 Ralf Corsepius rc040...@freenet.de wrote: Just one minor item: How do you expect people to test f20 fixes at the moment? There is no f20 repo on dl.fedoraproject.org, there are no f20 mock configurations on released Fedora releases in place, mirrormanager also so doesn't know about f20 yet, etc. ... We branched yesterday afternoon. The first branched compose is... composing right now. mock is being updated today. You can surely make a new f20 cfg file if you have some urgent need, or use a scratch build? The latter is what I am doing (Thanks to the arm, this has become part of all updates and reviews, in any case). mirrormanager picks up releases from the master mirror trees. See point one about a compose happening right now. Admitted, these issues are minor, but ... these are causing some amount churn on packager side and thus causes delays. This is a completely normal one day state. We will see. In the past, such branches had taken several days from branching until fully migrated over the big pond to Europe. How can we compose a tree before we have branched? I don't know what a compose is. To me it seems illogical to have a presumably functional repository accessible through fedpkg/koji, while none is available on dl.fedoraproject.org rsp. the mirrors. That said, to me a compose would be flipping a switch such that this internal repo is mirrored to the outside and then propagated to the mirror - Seems as if I am wrong. 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: slowing down the development schedule for a release.
On 08/21/2013 04:39 PM, Frantisek Kluknavsky wrote: On 08/21/2013 04:16 PM, Ralf Corsepius wrote: On 08/21/2013 04:01 PM, Frantisek Kluknavsky wrote: On 08/21/2013 03:35 PM, Ralf Corsepius wrote: there are no f20 mock configurations on released Fedora releases in place Is fedpkg mock-config problematic? No. fedpkg mockbuild for f20 and mock -r fedora-20-XXX are the problem. Ralf Maybe I misunderstand the purpose of fedpkg mock-config. I mean workflow like: 1. fedpkg switch-branch f20 2. fedpkg mock-config fedora-20-x86_64.cfg 3. (maybe edit fedora-20-x86_64.cfg ?) 4. sudo mv fedora-20-x86_64.cfg /etc/mock 5. fedpkg mockbuild where steps 2-4 are needed only once after branching. Ahh! I wasn't aware about this possibility. Is fedpkg mockbuild for f20 still problematic after that? Slightly, because you'd have to install such a *.cfg globally, which then will conflict with mock, once it will be updated. 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: slowing down the development schedule for a release.
Please see bottom-postSent from my BlackBerry 10 smartphone on the TELUS network From: Matthew MillerSent: Tuesday, August 20, 2013 17:57To: Development discussions related to FedoraReply To: Development discussions related to FedoraSubject: slowing down the development schedule for a release.On Tue, Aug 20, 2013 at 06:47:31PM -0500, Dennis Gilmore wrote: I need to update the documentation. But we need to get to the point where the releng side is transparent and just happens. The crazy schedules we have had since f18 have allowed zero time for Release Engineering and QA to do much in the line of development. this is entirely a failure of FESCoWithout spinning the wheel of blame -- at Flock, we talked about slowingdown the crazy train a little bit, probably not for F20 at this point butfor F21, specifically so we all have a chance to work on those kind ofthings. resources and or bother to keep spins standing on their own to feets so to speak. I think we can implement what is needed in F20. Releng stopped propping up spins quite a few releases ago. we have not shipped things that failed to compose. but things that failed to work have shipped. the burden on releng really is minimal.So, off-topic for this thread, but let's collect things which we can changewhich _are_ burdensome for releng or otherwise cause bottlenecks, and putthem on the plan for fixing during a theoretical longer release.-- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org-- Way off topic, so much so that I considered emailing Matthew off list: how do you get the cloud-graphics in your signature?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: slowing down the development schedule for a release.
On Tue, Aug 20, 2013 at 06:21:11PM -0700, richard.vicker...@gmail.com wrote: Way off topic, so much so that I considered emailing Matthew off list: how do you get the cloud-graphics in your signature? The magic power of Unicode. -- 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: headup : libzip 0.11 in rawhide (and PHP change)
Am 21.08.2013 14:10, schrieb Remi Collet: Le 21/08/2013 09:38, Remi Collet a écrit : Hi. I have updated libzip to 0.11.1 in rawhide. Despite there is no soname change, see: http://upstream-tracker.org/versions/libzip.html So I think it is preferable to rebuild dependent packages to ensure all is ok. Build done, f20 and rawhide: php-5.5.3-1 (drop zip extension, so no more libzip dep) drop zip extension? why? signature.asc 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
[perl-Encode/f20] 2.52 bump
commit fc54ae30401a91a7dc75b3a8657d8dc54e883171
Author: Jitka Plesnikova jples...@redhat.com
Date: Wed Aug 21 17:50:31 2013 +0200
2.52 bump
.gitignore |1 +
perl-Encode.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 934d104..ec71ad4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@
/Encode-2.49.tar.gz
/Encode-2.50.tar.gz
/Encode-2.51.tar.gz
+/Encode-2.52.tar.gz
diff --git a/perl-Encode.spec b/perl-Encode.spec
index 77f67e2..7e5e5fb 100644
--- a/perl-Encode.spec
+++ b/perl-Encode.spec
@@ -1,7 +1,7 @@
Name: perl-Encode
Epoch: 1
-Version:2.51
-Release:7%{?dist}
+Version:2.52
+Release:1%{?dist}
Summary:Character encodings in Perl
License:GPL+ or Artistic
Group: Development/Libraries
@@ -106,6 +106,9 @@ make test
%{perl_vendorarch}/Encode/encode.h
%changelog
+* Wed Aug 21 2013 Jitka Plesnikova jples...@redhat.com - 1:2.52-1
+- 2.52 bump
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1:2.51-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 2344e34..17f3010 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-bb8e631a0b5c8f40059a5a7f8c818600 Encode-2.51.tar.gz
+bf26ef62725b1938181d71d1127f22d8 Encode-2.52.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 997833] perl-Encode-2.52 is available
https://bugzilla.redhat.com/show_bug.cgi?id=997833 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|NEW |MODIFIED CC||jples...@redhat.com Fixed In Version||perl-Encode-2.52-1.fc21 Assignee|ppi...@redhat.com |jples...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=aGWhgsVdWPa=cc_unsubscribe -- 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: headup : libzip 0.11 in rawhide (and PHP change)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 21/08/2013 14:44, Reindl Harald a écrit : drop zip extension? why? - From my initial message: As PHP only work with libzip 0.10 (use lot of private stuff), the zip extension is become unmaintainable, so have been dropped from php. So we are going to receive tons of broken deps for pakages requiring php-zip. I just submit php-pecl-zip to review [1] This extension (from the same sources, but updated for libzip 0.11) is of course absolutely compatible. It will be really simpler to sync the life cyle of this extension with the library. Remi [1] https://bugzilla.redhat.com/show_bug.cgi?id=999313 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIU4zsACgkQYUppBSnxahiNpwCeJ/jcbBlEMXBbz8BnGPtApBlp 21gAnjByhcwkRFl9TEVwVK0Zexv5ItfZ =LG4K -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
Re: Problem with sed in spec file
El Miércoles, 21 de agosto de 2013 16:03:23 Richard W.M. Jones escribió:
Just open a bug against selinux-policy and ask the maintainer
to drop a file somewhere which contains the version number, eg:
%install
echo '%{version}' $RPM_BUILD_ROOT%{_datadir}/selinux/version
We do something similar in the OCaml compiler base package.
Rich.
Done.
https://bugzilla.redhat.com/show_bug.cgi?id=999584
--
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-Encode/f19] 2.52 bump
commit 59e130e48fa1f6f6cb21f7c6f221799d2622ea2c
Author: Jitka Plesnikova jples...@redhat.com
Date: Wed Aug 21 18:02:21 2013 +0200
2.52 bump
.gitignore |1 +
perl-Encode.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 934d104..ec71ad4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@
/Encode-2.49.tar.gz
/Encode-2.50.tar.gz
/Encode-2.51.tar.gz
+/Encode-2.52.tar.gz
diff --git a/perl-Encode.spec b/perl-Encode.spec
index 2419760..43cbe2a 100644
--- a/perl-Encode.spec
+++ b/perl-Encode.spec
@@ -1,5 +1,5 @@
Name: perl-Encode
-Version:2.51
+Version:2.52
Release:1%{?dist}
Summary:Character encodings in Perl
License:GPL+ or Artistic
@@ -89,6 +89,9 @@ make test
%{perl_vendorarch}/Encode/encode.h
%changelog
+* Wed Aug 21 2013 Jitka Plesnikova jples...@redhat.com - 2.52-1
+- 2.52 bump
+
* Thu May 02 2013 Petr Pisar ppi...@redhat.com - 2.51-1
- 2.51 bump
diff --git a/sources b/sources
index 2344e34..17f3010 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-bb8e631a0b5c8f40059a5a7f8c818600 Encode-2.51.tar.gz
+bf26ef62725b1938181d71d1127f22d8 Encode-2.52.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
Changes to make MySQL vs. MariaDB less confusing
Hi guys, there has been some demand for some time to make more strict line between mariadb and mysql in Fedora. I've tried to summarize some steps we'd like to apply for F20 in order to decrease that confusing -- see bug #999589 and feel free to comment here or there (it seemed to me that bug will better store what was the resolution eventually). I won't be able to respond until the end of the weekend, so sorry for that in advance. Cheers, Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: perl-Alien-ROOT
perl-Alien-ROOT has broken dependencies in the F-20 tree: On armhfp: perl-Alien-ROOT-5.34.3.1-3.fc20.noarch requires root-core Please resolve this as soon as possible. -- 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
Broken dependencies: perl-ParseUtil-Domain
perl-ParseUtil-Domain has broken dependencies in the F-20 tree: On x86_64: perl-ParseUtil-Domain-2.22-3.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-ParseUtil-Domain-2.22-3.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-ParseUtil-Domain-2.22-3.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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Encode-JP-Mobile
perl-Encode-JP-Mobile has broken dependencies in the F-20 tree: On x86_64: perl-Encode-JP-Mobile-0.30-2.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Encode-JP-Mobile-0.30-2.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Encode-JP-Mobile-0.30-2.fc19.armv7hl 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-IPTables-libiptc
perl-IPTables-libiptc has broken dependencies in the F-20 tree: On x86_64: perl-IPTables-libiptc-0.52-5.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-IPTables-libiptc-0.52-5.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-IPTables-libiptc-0.52-5.fc19.armv7hl 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-de...@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-de...@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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Jemplate
perl-Jemplate has broken dependencies in the F-20 tree: On x86_64: perl-Jemplate-0.262-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Jemplate-0.262-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Jemplate-0.262-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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-MooseX-TrackDirty-Attributes
perl-MooseX-TrackDirty-Attributes has broken dependencies in the F-20 tree: On x86_64: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-MooseX-TrackDirty-Attributes-2.002-2.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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Unix-Statgrab
perl-Unix-Statgrab has broken dependencies in the F-20 tree: On x86_64: perl-Unix-Statgrab-0.04-20.fc20.x86_64 requires libstatgrab.so.6()(64bit) On i386: perl-Unix-Statgrab-0.04-20.fc20.i686 requires libstatgrab.so.6 On armhfp: perl-Unix-Statgrab-0.04-20.fc20.armv7hl requires libstatgrab.so.6 Please resolve this as soon as possible. -- 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
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-de...@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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Qt
perl-Qt has broken dependencies in the F-20 tree: On x86_64: perl-Qt-0.96.0-6.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2) perl-Qt-0.96.0-6.fc19.x86_64 requires libperl.so()(64bit) On i386: perl-Qt-0.96.0-6.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2) perl-Qt-0.96.0-6.fc19.i686 requires libperl.so On armhfp: perl-Qt-0.96.0-6.fc19.armv7hl requires perl(:MODULE_COMPAT_5.16.2) perl-Qt-0.96.0-6.fc19.armv7hl requires libperl.so Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the F-20 tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-19.fc20.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-19.fc20.noarch requires perl(Bio::Index::AbstractSeq) On armhfp: perl-Bio-ASN1-EntrezGene-1.091-19.fc20.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Template-Alloy
perl-Template-Alloy has broken dependencies in the F-20 tree: On x86_64: perl-Template-Alloy-1.016-6.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Template-Alloy-1.016-6.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Template-Alloy-1.016-6.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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-CGI-Ex
perl-CGI-Ex has broken dependencies in the F-20 tree: On x86_64: perl-CGI-Ex-2.38-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-CGI-Ex-2.38-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-CGI-Ex-2.38-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-de...@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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: RFC: Spins process changes proposal
On Wed, 21 Aug 2013 08:45:59 +0100 Ian Malone ibmal...@gmail.com wrote: On 20 August 2013 19:29, Kevin Fenzi ke...@scrye.com wrote: Each approved spin MUST have at least 1 person fill in a basic spin test matrix for at least 1 TC or RC in order to be shipped with Alpha. If the image fails or there are no test results maintainers can try again at the next milestone, but the image is NOT shipped with Alpha. My only question is what happens when something higher up is causing all composes to fail, IIRC that was the case for a while for F18. Do all the spins have to follow this process to try and maintain approval in that case? Well, if it's causing gnome/kde/dvd/netiso to also fail, the release would be blocked until thats fixed. Once it is, it should be possible to test and get out in that release, or the next milestone if that one is missed. In practice when all the images don't compose things get fixed pretty quickly. kevin signature.asc 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: Schedule for Wednesday's FESCo Meeting (2013-08-21)
On Wed, Aug 21, 2013 at 2:09 AM, Toshio Kuratomi a.bad...@gmail.com wrote: = New business = Jaroslav notice that there's one more Fedora 20 Change that hasn't been approved: https://fedoraproject.org/wiki/Changes/GLIBC218 This one didn't get ticketed because it should be a system-wide change but the Change Owner hasn't made the necessary changes to the Change page to reflect that. I'm putting it on the agenda as the first thing in New business as we need to make sure we get all the Fedora Changes approved. -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: Changes to make MySQL vs. MariaDB less confusing
On 21 August 2013 17:11, Honza Horak hho...@redhat.com wrote: Hi guys, there has been some demand for some time to make more strict line between mariadb and mysql in Fedora. I've tried to summarize some steps we'd like to apply for F20 in order to decrease that confusing -- see bug #999589 and feel free to comment here or there (it seemed to me that bug will better store what was the resolution eventually). Would there be huge loss to just orphaning and dropping community-mysql entirely to resolve the issue once and for all - and thus making this very clear? When the switch was first proposed it was Oracle who was most vocal against it to the point of them stating they'd take over package ownership and filing #958131 to update to 5.6 and change the name from community-mysql to mysql-community etc etc ... The last comment from Bjorn was just over two months ago with the 'NEEDINFO' flag raised over 6 weeks ago... -- 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: F20 System Wide Change: Web Assets
On Wed, Aug 21, 2013 at 04:52:53PM +0200, Nicolas Mailhot wrote: Le Dim 4 août 2013 10:44, Till Maas a écrit : The guideline should be to ask upstream to fix the meta data. In case of missing license text (e.g. source code with a GPL header but no copy of the GPL itself), it is also upstream's task to fix it and the packager's to ask for it. And if upstream fixes it, the debian font packagers do not need to replicate Fedora's effort. This is already the guideline, the problem is what do you do when upstream postpones fixing to indefinitely later because licensing stuff is low-prio for them If upstream does not see an urgent problem in it, why should we? We do the same with license copies in packages. Also it would be upstream that might have a problem with the license information, since they provided the fonts like they are and allow distribution, I cannot see a problem. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora ARM Weekly Status Meeting 2013-08-21 - CANCELLED
Good day all, This week's status meeting has been cancelled, please join us next week during our regular time. In the interim send any issues you would like to discuss to the list. 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: aoetools package updates from upstream
On Wed, Aug 21, 2013 at 03:26:38PM +0800, Christopher Meng wrote: 在 2013-8-21 PM1:28，Tomasz Torcz to...@pipebreaker.pl写道： Also on related note: vblade package (the AoE server) was on recent orphans list. If it's not taken, the other half of aoe stack will disappear from Fedora. Damn... it's deprecated now. Can Dennis unretire it? It is unblocked in koji now, but you need to file a SCM admin request: https://fedoraproject.org/wiki/Package_SCM_admin_requests Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Wider feedback requested on two changes to our base/core defaults
Greetings all After sitting Dan's Walsh Secure Linux Containers talk at flock where he mentioned him and Dan B. had successfully scaled application containers to what 8000 instances or so and I noticing that his slide where a bit dated due to the changes in croup I decided to have a look at the current state in systemd to see what we needed to fix and properly integrate those changes into Fedora and deliver good out of the box container experience for our administrators and users as well as document those changes ( early readers can jump here [1] just note this page is a work in progress ). Now I've been poking and prodding, fixing and preparing us for those upcoming cgroup changes in systemd in relation to Linux OS Containers known as machine slices ( Essentially this feature [2] which btw does not work as advertised due to several bugs in various places ). Now aiming at achieving some simple practical steps something like this for administrators to use # btrfs subvolume create /containers/container01.example.com Install minimal package set into the OS container being created # yum -y --releasever=rawhide --nogpg --installroot=/containers/container01.example.com --disablerepo='*' --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal procps-ng Spawn the container and set the machine hostname # systemd-nspawn -jbD /containers/example.com/ -M container01.example.com ( perfect admin steps for setup would stop here but due to several bugs additional steps and workarounds are needed at this point ) And I have come across a bit of scalability issue due to us defaulting to using short hostnames in login and command prompt when creating OS containers in any real numbers. Now for those that are not familiar with our default using the short fqdn it cuts the fqdn at the highest level domain as in the first dot so in the sample case the login and command line promt is shown as container01. That scalability problem comes immediately apparent when you would create the next container01 for the next second level domain like container01.ackme.com you as an ISP would be hosting, it would be also showing container01 at the login and command line prompt just begging for administrative mistake and headaches. I would like us to change our default to use long hostname instead as in the fqdn or container01.ackme.com and would love any kind of feed back in that regard ( why we should not default to that ). The downside of doing that ofcourse if you have like 6 level domain name in your infrastructure like i'm.a.really.long.domain.name.com it might become a bit of a nuance but administrators could always revert those change to use short hostname instead if that was the case. The other issue I would like to get some comments on is that we default to setting an empty root password which will allow administrators to log into containers as root and set the root password as well as removing few line from spin kickstarts as well being beneficial to the arm community. Now the only reason I see for not doing this is because on the releng dvd installs we enable ssh by default ( which we arguably should not be doing ) but the argument can be made in that regard that we leave the users anyway open to bruteforce attacks out of the box without them even knowing that it's happening so it comes as bit of security through obscurity not allowing this in the first place. JBG 1. https://fedoraproject.org/wiki/User:Johannbg/Systemd/cgroup-changes 2. https://fedoraproject.org/wiki/Features/SystemdLightweightContainers -- 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-Module-Metadata] Created tag perl-Module-Metadata-1.000015-1.fc20
The lightweight tag 'perl-Module-Metadata-1.15-1.fc20' was created pointing to: d21df9c... Update to 1.15 -- 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-Module-Metadata] Created tag perl-Module-Metadata-1.000015-1.fc21
The lightweight tag 'perl-Module-Metadata-1.15-1.fc21' was created pointing to: d21df9c... Update to 1.15 -- 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-Module-Metadata] Created tag perl-Module-Metadata-1.000015-1.fc18
The lightweight tag 'perl-Module-Metadata-1.15-1.fc18' was created pointing to: d21df9c... Update to 1.15 -- 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-Module-Metadata] Created tag perl-Module-Metadata-1.000015-1.fc19
The lightweight tag 'perl-Module-Metadata-1.15-1.fc19' was created pointing to: d21df9c... Update to 1.15 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 999631] CVE-2013-1437 perl-Module-Metadata: incorrectly documents that it does not execute unsafe code [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=999631 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-Module-Metadata-1.15-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-Module-Metadata-1.15-1.fc18 -- 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=6EQrfob0n8a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 999631] CVE-2013-1437 perl-Module-Metadata: incorrectly documents that it does not execute unsafe code [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=999631 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-Module-Metadata-1.15-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-Module-Metadata-1.15-1.fc19 -- 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=IQOoMU9X4Ya=cc_unsubscribe -- 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
Schedule for Thursday's FPC Meeting (2013-08-22 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2013-08-22 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2013-08-22 09:00 Thu US/Pacific PDT 2013-08-22 12:00 Thu US/Eastern EDT 2013-08-22 16:00 Thu UTC - 2013-08-22 17:00 Thu Europe/London BST 2013-08-22 18:00 Thu Europe/Paris CEST 2013-08-22 18:00 Thu Europe/Berlin CEST 2013-08-22 21:30 Thu Asia/Calcutta IST --new day-- 2013-08-23 00:00 Fri Asia/Singapore SGT 2013-08-23 00:00 Fri Asia/Hong_Kong HKT 2013-08-23 01:00 Fri Asia/Tokyo JST 2013-08-23 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = New business = #topic #327 Python shebangs should not point to /usr/bin/python .fpc 327 https://fedorahosted.org/fpc/ticket/327 #topic #328 Soft-static uid/gid allocation for Performance Co-Pilot daemons .fpc 328 https://fedorahosted.org/fpc/ticket/328 #topic #329 Packaging Guideline: libtool should be regenerated in SPEC .fpc 329 https://fedorahosted.org/fpc/ticket/329 #topic #331 ruby guidelines requiring ruby(release) causes depsolving headache .fpc 331 https://fedorahosted.org/fpc/ticket/331 #topic #332 Bundling exception for IQmol .fpc 332 https://fedorahosted.org/fpc/ticket/332 = 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/12 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
Re: Wider feedback requested on two changes to our base/core defaults
On Wed, Aug 21, 2013 at 8:45 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Now for those that are not familiar with our default using the short fqdn it cuts the fqdn at the highest level domain as in the first dot so in the sample case the login and command line promt is shown as container01. That scalability problem comes immediately apparent when you would create the next container01 for the next second level domain like container01.ackme.com you as an ISP would be hosting, it would be also showing container01 at the login and command line prompt just begging for administrative mistake and headaches. It's not obvious to me that optimizing the default setup for ISPs (who have server management as their core business, and will likely do much more customization to get a competitive edge) is a good idea, but I'll defer to people who actually do such things with containers. The other issue I would like to get some comments on is that we default to setting an empty root password which will allow administrators to log into containers as root and set the root password as well as removing few line from spin kickstarts as well being beneficial to the arm community. * If the container is supposed to resemble an ordinary operating system, with user accounts and ability to use it from the outside (whether using the console or over the network), then it should also not allow just anyone who knows the IP address to connect. (per systemd-nspawn(1), --private-network is not default.) * If the container only sandboxes a separate service, there shouldn't be a login process (or, an user session, really) running inside in the first place; the tools should just launch a shell (or other tool) running within the container, with the authentication happening outside the container. So, no. we leave the users anyway open to bruteforce attacks out of the box without them even knowing that it's happening so it comes as bit of security through obscurity not allowing this in the first place. That's equivalent to saying that all passwords are security through obscurity, and equally incorrect. 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: bug filed against distribution
On Mon, 19 Aug 2013 16:39:40 +0200 Reindl Harald h.rei...@thelounge.net wrote: Am 19.08.2013 16:37, schrieb Kevin Fenzi: On Sat, 17 Aug 2013 20:20:33 +0200 Reindl Harald h.rei...@thelounge.net wrote: because it happens *regulary* and not from time to time and not depending on package/maintainer and that is a wrong behavior which should be made clear insinde the distribution So, you are proposing a addition to the package maintainer responsibilities page? (I am not sure this will solve the issue, but would give you somewhere to point people). Perhaps: Try and solve bugs or issues for the release against which they were reported, or if that is impractical note to bug reporters why their bug cannot be fixed in that release Thoughts? sounds good! This was approved at today's fesco meeting and I have added it to the wiki: https://fedoraproject.org/w/index.php?title=Package_maintainer_responsibilitiesdiff=350231oldid=342466 kevin signature.asc 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: Wider feedback requested on two changes to our base/core defaults
On 08/21/2013 08:22 PM, Miloslav Trmač wrote: On Wed, Aug 21, 2013 at 8:45 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Now for those that are not familiar with our default using the short fqdn it cuts the fqdn at the highest level domain as in the first dot so in the sample case the login and command line promt is shown as container01. That scalability problem comes immediately apparent when you would create the next container01 for the next second level domain like container01.ackme.com you as an ISP would be hosting, it would be also showing container01 at the login and command line prompt just begging for administrative mistake and headaches. It's not obvious to me that optimizing the default setup for ISPs (who have server management as their core business, and will likely do much more customization to get a competitive edge) is a good idea, but I'll defer to people who actually do such things with containers. If people do not want our login and command promt default to fqdn of the host we should move forward and default it to pretty hostname instead of using the short hostname anyway. The other issue I would like to get some comments on is that we default to setting an empty root password which will allow administrators to log into containers as root and set the root password as well as removing few line from spin kickstarts as well being beneficial to the arm community. * If the container is supposed to resemble an ordinary operating system, with user accounts and ability to use it from the outside (whether using the console or over the network), then it should also not allow just anyone who knows the IP address to connect. (per systemd-nspawn(1), --private-network is not default.) You create an OS container and run other containers within it ( users, system etc ). * If the container only sandboxes a separate service, there shouldn't be a login process (or, an user session, really) running inside in the first place; the tools should just launch a shell (or other tool) running within the container, with the authentication happening outside the container. So, no. No what? And I think you are confusing here OS container with application container these are two different container solutions. we leave the users anyway open to bruteforce attacks out of the box without them even knowing that it's happening so it comes as bit of security through obscurity not allowing this in the first place. That's equivalent to saying that all passwords are security through obscurity, and equally incorrect. If I was not obvious enough the difference is only in time and if you are trying to claim that users dont get cracked after installing fedora of the dvd I can tell you here and now that it already has happened and that user did not have the faintest idea that a) sshd was running and b) someone was trying to login to his system he just choice to install Gnome of relengs dvd because that instalment gave him more complete desktop experience. Lesson he learned from that experience never to use Fedora again. Lesson we should have learned was for us deliver identical install and usage experience of dvd as the live images give users. JBG -- 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: Changes to make MySQL vs. MariaDB less confusing
On Wed, Aug 21, 2013 at 10:54 AM, James Hogarth james.hoga...@gmail.com wrote: When the switch was first proposed it was Oracle who was most vocal against it to the point of them stating they'd take over package ownership and filing #958131 to update to 5.6 and change the name from community-mysql to mysql-community etc etc ... I fear a similar fate is going to befall mysql-workbench before too long, since it's been orphaned for a while. Are the Oracle employees still around? - 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: Changes to make MySQL vs. MariaDB less confusing
Once upon a time, Ken Dreyer ktdre...@ktdreyer.com said: I fear a similar fate is going to befall mysql-workbench before too long, since it's been orphaned for a while. Are the Oracle employees still around? I looked a while back, and it is marked deprecated in the Fedora package database. I'm not sure why it wasn't just orphaned, since AFAIK it still works, still maintained, and there's no direct replacement. -- Chris Adams li...@cmadams.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: Wider feedback requested on two changes to our base/core defaults
On Wed, 2013-08-21 at 18:45 +, Jóhann B. Guðmundsson wrote: Greetings all After sitting Dan's Walsh Secure Linux Containers talk at flock where he mentioned him and Dan B. had successfully scaled application containers to what 8000 instances or so and I noticing that his slide where a bit dated due to the changes in croup I decided to have a look at the current state in systemd to see what we needed to fix and properly integrate those changes into Fedora and deliver good out of the box container experience for our administrators and users as well as document those changes ( early readers can jump here [1] just note this page is a work in progress ). Now I've been poking and prodding, fixing and preparing us for those upcoming cgroup changes in systemd in relation to Linux OS Containers known as machine slices ( Essentially this feature [2] which btw does not work as advertised due to several bugs in various places ). Now aiming at achieving some simple practical steps something like this for administrators to use # btrfs subvolume create /containers/container01.example.com Install minimal package set into the OS container being created # yum -y --releasever=rawhide --nogpg --installroot=/containers/container01.example.com --disablerepo='*' --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal procps-ng Spawn the container and set the machine hostname # systemd-nspawn -jbD /containers/example.com/ -M container01.example.com ( perfect admin steps for setup would stop here but due to several bugs additional steps and workarounds are needed at this point ) And I have come across a bit of scalability issue due to us defaulting to using short hostnames in login and command prompt when creating OS containers in any real numbers. Now for those that are not familiar with our default using the short fqdn it cuts the fqdn at the highest level domain as in the first dot so in the sample case the login and command line promt is shown as container01. That scalability problem comes immediately apparent when you would create the next container01 for the next second level domain like container01.ackme.com you as an ISP would be hosting, it would be also showing container01 at the login and command line prompt just begging for administrative mistake and headaches. I would like us to change our default to use long hostname instead as in the fqdn or container01.ackme.com and would love any kind of feed back in that regard ( why we should not default to that ). +1 always good to show the full name IMO, at least at the ssh/shell level, let the pretty graphical UIs be more lax and try to prettify things. The downside of doing that ofcourse if you have like 6 level domain name in your infrastructure like i'm.a.really.long.domain.name.com it might become a bit of a nuance but administrators could always revert those change to use short hostname instead if that was the case. One way to make it less painful could be to preint the fqdn on one line and then just login on the next. Ie instead of haiving container01 login: you would have container01.my.really.deep.sub.domain.name.hierarchy login: I think people will object less to something like this, after all we already print the full fedora name and kernel version on console logins in previous lines. The other issue I would like to get some comments on is that we default to setting an empty root password which will allow administrators to log into containers as root and set the root password as well as removing few line from spin kickstarts as well being beneficial to the arm community. Now the only reason I see for not doing this is because on the releng dvd installs we enable ssh by default ( which we arguably should not be doing ) but the argument can be made in that regard that we leave the users anyway open to bruteforce attacks out of the box without them even knowing that it's happening so it comes as bit of security through obscurity not allowing this in the first place. Sounds like a bad idea. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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 991767] perl-App-cpanminus-1.6941 is available
https://bugzilla.redhat.com/show_bug.cgi?id=991767 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-App-cpanminus-1.6940 |perl-App-cpanminus-1.6941 |is available|is available --- Comment #7 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 1.6941 Current version/release in Fedora Rawhide: 1.6927-2.fc20 URL: http://search.cpan.org/dist/App-cpanminus/ 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=5P2x1jWjjea=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 999359] New: perl-Data-Peek-0.39 is available
https://bugzilla.redhat.com/show_bug.cgi?id=999359 Bug ID: 999359 Summary: perl-Data-Peek-0.39 is available Product: Fedora Version: rawhide Component: perl-Data-Peek Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.39 Current version/release in Fedora Rawhide: 0.38-4.fc20 URL: http://search.cpan.org/dist/Data-Peek/ 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=3xzrAIB3QVa=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 999370] New: perl-POE-Test-Loops-1.352 is available
https://bugzilla.redhat.com/show_bug.cgi?id=999370 Bug ID: 999370 Summary: perl-POE-Test-Loops-1.352 is available Product: Fedora Version: rawhide Component: perl-POE-Test-Loops Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 1.352 Current version/release in Fedora Rawhide: 1.351-6.fc20 URL: http://search.cpan.org/dist/POE-Test-Loops/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=hlYqqPgjcea=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 999367] New: perl-POE-1.356 is available
https://bugzilla.redhat.com/show_bug.cgi?id=999367 Bug ID: 999367 Summary: perl-POE-1.356 is available Product: Fedora Version: rawhide Component: perl-POE Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 1.356 Current version/release in Fedora Rawhide: 1.354-9.fc20 URL: http://search.cpan.org/dist/POE/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=eCF1HLELXja=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 999372] New: perl-YAML-Tiny-1.53 is available
https://bugzilla.redhat.com/show_bug.cgi?id=999372 Bug ID: 999372 Summary: perl-YAML-Tiny-1.53 is available Product: Fedora Version: rawhide Component: perl-YAML-Tiny Keywords: FutureFeature, Triaged Assignee: st...@silug.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, st...@silug.org Latest upstream release: 1.53 Current version/release in Fedora Rawhide: 1.51-8.fc20 URL: http://search.cpan.org/dist/YAML-Tiny/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=ewusOiibmga=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 999370] perl-POE-Test-Loops-1.352 is available
https://bugzilla.redhat.com/show_bug.cgi?id=999370 Petr Šabata psab...@redhat.com changed: What|Removed |Added Blocks||999367 -- 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=TKCSURnHG6a=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 999367] perl-POE-1.356 is available
https://bugzilla.redhat.com/show_bug.cgi?id=999367 Petr Šabata psab...@redhat.com changed: What|Removed |Added Depends On||999370 -- 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=VmgllGZk6Ba=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 YAML-Tiny-1.53.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-YAML-Tiny: 8eaa665b54b94770c438407dd99b3ee2 YAML-Tiny-1.53.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-YAML-Tiny] Update to 1.53
commit 8eb9caf80ea2572883d59b30c34ec6d2c2825532
Author: Paul Howarth p...@city-fan.org
Date: Wed Aug 21 10:51:38 2013 +0100
Update to 1.53
- New upstream release 1.53
- Updated repository metadata to reflect move to github
- This release by ETHER - update source URL
- Upstream no longer shipping README
- Don't need to remove empty directories from the buildroot
- Make %files list more explicit
.gitignore |6 +-
perl-YAML-Tiny.spec | 21 ++---
sources |2 +-
3 files changed, 16 insertions(+), 13 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 15ecf01..adffd8c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1 @@
-YAML-Tiny-1.40.tar.gz
-/YAML-Tiny-1.44.tar.gz
-/YAML-Tiny-1.46.tar.gz
-/YAML-Tiny-1.50.tar.gz
-/YAML-Tiny-1.51.tar.gz
+/YAML-Tiny-[0-9.]*.tar.gz
diff --git a/perl-YAML-Tiny.spec b/perl-YAML-Tiny.spec
index f134e25..f3d5a2d 100644
--- a/perl-YAML-Tiny.spec
+++ b/perl-YAML-Tiny.spec
@@ -1,11 +1,11 @@
Name: perl-YAML-Tiny
-Version:1.51
-Release:8%{?dist}
+Version:1.53
+Release:1%{?dist}
Summary:Read/Write YAML files with as little code as possible
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/YAML-Tiny/
-Source0:
http://search.cpan.org/CPAN/authors/id/A/AD/ADAMK/YAML-Tiny-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/E/ET/ETHER/YAML-Tiny-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl(Carp)
BuildRequires: perl(Exporter)
@@ -38,18 +38,25 @@ make %{?_smp_mflags}
%install
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} %{buildroot}/*
%check
make test AUTOMATED_TESTING=1
%files
-%doc Changes LICENSE README
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%doc Changes LICENSE
+%{perl_vendorlib}/YAML/
+%{_mandir}/man3/YAML::Tiny.3pm*
%changelog
+* Wed Aug 21 2013 Paul Howarth p...@city-fan.org 1.53-1
+- Update to 1.53
+ - Updated repository metadata to reflect move to github
+- This release by ETHER - update source URL
+- Upstream no longer shipping README
+- Don't need to remove empty directories from the buildroot
+- Make %%files list more explicit
+
* Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.51-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index a04dae9..5a55ab2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8e67d89a4905e797216384a89011efa9 YAML-Tiny-1.51.tar.gz
+8eaa665b54b94770c438407dd99b3ee2 YAML-Tiny-1.53.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
