Re: The question of rolling release?
On 26/01/12 01:19, Kevin Fenzi wrote: I would personally advise against this way forward. I'd like to suggest an alternative: * Gather folks interested in this (you should be able to see some from this thread). Perhaps announce that you are forming a group to look into this. * Get together and write up a wiki page / detailed proposal, answering: +100 -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 proposal - prerelease version name changes
Michał Piotrowski wrote: Microsoft has changed the way of prerelease version naming Alpha - Developer Preview Beta - Consumer Preview Release Candidate - Enterprise (or Business) Preview Ugh, no thanks! I'd suggest going with the naming KDE, a leading Free Software project uses: Alpha → Beta Beta → RC Alpha/Beta/Release Candidate → Beta/RC/Release try (The last rename is needed because otherwise you'd have 2 kinds of RCs. :-) The try term is what KDE uses on the kde-packager mailing list for what is essentially the equivalent of our candidates. It's also shorter than candidate and makes it clearer that the last try will be released as is, RC has lost that meaning (which it did originally have) for years in the Free Software world, so people are really surprised when we tell them we don't respin the ISOs between the last RC and Gold.) Incidentally, this is also very close to what we used to use until Fedora 11, which was Beta / Preview rather than Alpha / Beta. I think the current naming misleads developers into thinking their work can be much less ready than it should be for the milestones, and I blame the Fedora 12 slippages, and to a lesser extent the slippages of more recent releases, on it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
Reindl Harald wrote: i made several HUNDRET of dist-upgrades with yum since FC3 and upgrade via DVD/Preupgrade is simply UNACEPPTABLE +1 IMHO this is a showstopper and approval for UsrMove should be withdrawn and the feature reverted. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
Greg wrote: i don't have any problems downloading a DvD, or a LiveCD Live CDs cannot be used to upgrade existing systems. As for the DVD, it does not include the updates repository when doing upgrades (you can only add additional repositories for fresh installations), which means the process is completely broken due to the inevitable upgrade path issues. (You have to run yum update after the DVD upgrade to fix these, and that's if yum isn't affected by the upgrade path issues, which it sometimes is, e.g. it was for Fedora 11.) As I've already stated multiple times, the DVD MUST be fixed to include the updates repository for upgrades (and yes, that means offline upgrades are not possible, they're just not supportable; and yes, if Anaconda still doesn't support any networking other than basic wired Ethernet, that needs to be fixed, too); as is, DVD upgrades are totally unsupportable. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
I wrote: IMHO this is a showstopper and approval for UsrMove should be withdrawn and the feature reverted. PS: Oh, and I don't see why this cannot be fixed by a %pretrans scriptlet in filesystem rather than a script we have to run by hand. That's what %pretrans is for. (We successfully used %pretrans to convert directories to symlinks or the opposite in a couple cases in KDE packaging in the past. None were directories as important as the ones being touched by UsrMove though!) And the scriptlet having been written BEFORE starting to convert packages should have been a requirement for approving this feature. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On 01/26/2012 02:19 AM, Kevin Fenzi wrote: On Wed, 25 Jan 2012 21:37:36 -0200 Henrique Juniorhenrique...@gmail.com wrote: I would like to see Fedora following the path of rolling release. openSUSE is doing a great job with the Tumbleweed, still keeping the same old system of releases and letting users choose whether or not using roling release. Particularly I wouldn't like to see this thread dying as happened in other occasions, after all, we know that discussions may not lead to anything, and sometimes small actions can be more productive than long threads [1]. I wonder if we could create a poll (for active members with FAS accounts) to determine what the community thinks about it. After the poll, if the idea of rolling release receives most votes then would be the time to discuss how and when doing the implementation. I would personally advise against this way forward. I'd like to suggest an alternative: * Gather folks interested in this (you should be able to see some from this thread). Perhaps announce that you are forming a group to look into this. * Get together and write up a wiki page / detailed proposal, answering: - How would this work? - What resources would you need? - What impact does it have on maintainers? users? release engineering? - Would this work alongside the current setup? Or would it be one or the other? - Try and answer questions raised by folks in this thread. - Try and list advantages. Why would we want to do this? what does it get us? * Post again once you have details and ask for more feedback. * Repeat cycle until you find it's ready and then ask fesco to take a look. Just a suggestion... kevin +1 Create suggestion I would like to join such a SIG. regards Markus -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
While I take issue with how Reindl is presenting his case, I'd just like to add a concurring voice to the original point: this will negatively affect a particular swath of users, of which I am one. Media-driven upgrades aren't a reasonable option for my (admittedly small) collection of machines, all of which are managed remotely and with a number of other constraints that I won't bore the list with (as they're mainly self-imposed). I suspect we're not the only ones for whom this will be a difficult release. Not impossible by any stretch, but it will be, to be blunt, a rather large pain in the ass for a particular class of user. It's interesting to me to consider this change in the context of the rolling release thread. (This is me trying to be constructive and get people thinking, rather than the more argumentative approach I've seen some folks taking so far. Let's see if it works. :)) Without revealing my own preference about rolling releases: how would a change like this, whose deployment is *significantly* eased with install-time magic, be deployed in a rolling-release world? (ie. add the constraint that, once a machine is installed, ongoing updates are performed without media; not that they are performed with yum upgrade, just that they are performed without physical media, and with an eye toward minimal offline time.) How would the approach change? Could you (with effort) handle the relocation of /bin and friends at runtime, or is this just one of those times where you naturally need to boot to an upgrade process to implement? If we decide a boot to perform our magic is required (I concede that the runtime case has a few chicken-and-egg problems to solve, and backporting the RPM changes would probably be a requirement), could the necessary initramfs and upgrade tooling be provided/generated as part of a helper package for yum upgraders, and documented on the wiki (require a single reboot to do the minimal heavy lifting of the relocation, then back to a running system for the actual upgrade)? Or perhaps a more elegant solution that you could envision? (If you hadn't guessed, I agree with the rationale for UsrMove; I think it's a win. It just seems that more thought could be put into how deployment has been implemented to make a few use cases more reasonable. systemd-as-default was made to wait a release to make sure the details were right; punting for a single release cycle isn't the end of the world, for any feature.) Anyway, food for thought. (And a potential real-world case for the rolling-release proponents to consider.) On Wed, Jan 25, 2012 at 11:37 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 26.01.2012 08:06, schrieb Aleksandar Kurtakov: - Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Thursday, January 26, 2012 7:15:51 AM Subject: Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17? Am 26.01.2012 05:02, schrieb Rahul Sundaram: On 01/26/2012 09:23 AM, Reindl Harald wrote: i see really nothing wrong in demanding not break things randomly without VERY good reasons and in this context it does relly not matter if opensource /paid / whatever Nobody breaks things randomly. Sometimes changes have unintentional side effects. since this happens much too often it should be considered what is wrong in the way making big changes and if it is really needed / useful to make them so big this transition could be done with less drastic effects by start change the locations of updated packages, targeting empty top-level dirs in the next release and file bugreports for every single file existing after that finally you have the directories empty and they can be removed the first step could be even install the new binaries to /usr/bin/ and create symlinks in /bin/ which will be removed in the next release Let me start that I'll miss yum upgrade badly! the package manager and clean update transitions are so much imprtant that breaking them is no option as long anybody works on changes wants to say he does things right Looking at the feature page though is making me think that this is really incremental approach. Move everything in usr this release and benefit from it in consequent releases(F-18) (snapshoting and etc.). If a more conservative approach is taken we will have e.g. everything moved to /usr in F-17, symlinks from bin removed in F-18, bin|sbin|lib made symlinks in F-19 and etc. If we move that slow by the time we have a feature it will so badly outdated that it might be irrelevant or already a commodity so noone is considering Fedora as a contender. Note that I speak overall not just in the Linux/Unix world. in other words: better making things fast to be first and early instead make them right yes, this is exactly what happens the last years and makes me so angry because it results in NEVER have software working right because
Re: Unity For Fedora (As in OpenSUSE or Arch)
Dne 26.1.2012 02:05, Manuel Escudero napsal(a): I don't know if you're aware of this or not, but a user managed to port Ubuntu's Unity to OpenSUSE 12.1 as you can see here: http://en.opensuse.org/openSUSE:GNOME_Ayatana And also I've been told this desktop is available for ArchLinux now as well... As for this facts I was wondering how feasible is to port Unity to Fedora as well (Now that we have OpenSUSE RPM packages of the Unity sources and deps available to play with) and if someone is interested in trying to bring the Unity Desktop to Fedora If no one is, I was wondering where is a good place to start trying to do it so I can try it myself and then maybe I gather some other interested ones... -- Manuel Escudero Linux User #509052 Twitter: @Jmlevick http://twitter.com/Jmlevick Blogger: Blog Xenode http://xenodesystems.blogspot.com/ PGP/GnuPG: E2F5 12FA E1C3 FA58 CF15 8481 B77B 00CA C1E1 0FA7 Xenode Systems - xenodesystems.com http://www.xenodesystems.com/ - Conéctate a Tu Mundo I like gnome3, however I really love the HUD idea recently announced by Mark Shuttleworth. Vit [1] http://www.markshuttleworth.com/archives/939 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: Korean default font change (un-core-*-fonts - nanum-*-fonts)
Hi all, Forwarding this to get more attention from Korean users and developers. If no one objects, I'll start working on the transtion so that it can be tested with F17 Alpha. Regards, Start of forwarded message Message-ID: m37h0s8207.fsf-u...@fedoraproject.org From: Daiki Ueno u...@fedoraproject.org To: fo...@lists.fedoraproject.org Subject: Korean default font change (un-core-*-fonts - nanum-*-fonts) Date: Mon, 16 Jan 2012 17:01:39 +0900 Hi, I heard that Ubuntu is going to change the default Korean font from un-core to nanum within their P release cycle: http://permalink.gmane.org/gmane.linux.ubuntu.devel.discuss/13090 https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/836430 Since I maintain both font packages in Fedora, I would like to ask Korean users whether it is a good thing to do as well in F17. AFAIK, the only concern discussed there was that they dropped nanum-coding font (a monospace variant of nanum-gothic, distributed as a separate upstream tarball) from the default install, due to size limitation. I guess we could also simply mark it as optional in comps (like un-extra-*-fonts). Regards, -- Daiki Ueno ___ fonts mailing list fo...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fonts http://fonts.fedoraproject.org/ End of forwarded message -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 1:34 AM, Toshio Kuratomi a.bad...@gmail.com wrote: On Wed, Jan 25, 2012 at 10:48:27PM +, Peter Robinson wrote: Hi All, So I saw a rpm update and a number of other builds today when dealing with various packaging bits. Checking the update [1] and reading the attached bug [2] I was a little shocked to find that yum upgrade between releases would be explicitly broken due to this feature. Yes, I know that it's not officially recommended as a means of upgrading and never been QAed it has been generally supported and expected to work [4] for as long as I can remember. The thing that is annoying me is that this change has not been explicitly mentioned in the Feature [3], it does no appear in the FAQ on the feature and I don't remember it ever being bought up in the discussions about the feature although I admit I probably have missed some of the discussion. Has this side effect of the feature been discussed at all? Can someone point me to a thread? https://fedorahosted.org/fesco/ticket/690#comment:8 https://fedorahosted.org/fpc/ticket/118 IIRC from the discussion in FPC meetings, there should be a way to make yum upgrades work but you'd first have to boot up specially and run an initial upgrade script: http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 How does that work on headless devices? It doesn't seem to be well tested. In fact there doesn't seem to be a way to be able to test it. If the Feature Owners have progressed to the implementing stae, I would greatly appreciate them updating that page with the actual step-by-step to perform the upgrade (which will also allow people to test that things work). They haven't yet. They were building packages yesterday under the f17-usrmove tag but there has been no heads up to any of the lists, no documentation or links to the documentation from the feature page and we're only 12 days out from feature freeze and it still hasn't landed. This should have been in rawhide months ago. This is just asking for slippage of the schedule. IMO this is too late and there's too many widely impacting things that haven't been widely announced. Personally I think, similar to what happened in F-14 with systemd, this feature should be pushed back to F-18 to give the feature developers more time to properly develop and test things like those scripts or decent procedures in order to be able to progress this properly rather than throwing it over the fence a week or so before feature freeze/branch and ensuring a just about guaranteed slip of the schedule. This just makes a whole mockery of the Feature process and basically gives the idea that a number of people thing they can just do as they please, when they please and ride rough shod over the process. I also agree with your point that this discussion should be reflected on the Feature page (Since the Feature page is where marketing material is taken from). Could that be updated as well? It's also where a lot of people go to figure out the impact and how they can test various features. There's not a single mention of yum upgrade breakage or change of process. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bumblebee on fedora
Hi to all developers on Fedora, In this week, on Italian Fedora Community a user ask help about a problem with his external monitor [1]. He has an Nvidia card with Optimus tecnology. We see the Bumblebee project [2] that is not packaged for Fedora. What do you think about bumblebee? And what do you think to package it in Fedora? [1] http://forum.fedoraonline.it/viewtopic.php?id=17336 [2] https://github.com/Bumblebee-Project/Bumblebee -- Mario Santagiuliana www.marionline.it signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 8:24 AM, Kevin Kofler kevin.kof...@chello.at wrote: Reindl Harald wrote: i made several HUNDRET of dist-upgrades with yum since FC3 and upgrade via DVD/Preupgrade is simply UNACEPPTABLE +1 IMHO this is a showstopper and approval for UsrMove should be withdrawn and the feature reverted. Fortunately (and IMO the major part of the problem) the core parts of the feature haven't landed yet and hence not even widely tested. This is the reason for my mail to the list so we don't have a massive blow out just before freeze ensuring a slip. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On 01/26/2012 02:34 AM, Toshio Kuratomi wrote: On Wed, Jan 25, 2012 at 10:48:27PM +, Peter Robinson wrote: Hi All, So I saw a rpm update and a number of other builds today when dealing with various packaging bits. Checking the update [1] and reading the attached bug [2] I was a little shocked to find that yum upgrade between releases would be explicitly broken due to this feature. Yes, I know that it's not officially recommended as a means of upgrading and never been QAed it has been generally supported and expected to work [4] for as long as I can remember. The thing that is annoying me is that this change has not been explicitly mentioned in the Feature [3], it does no appear in the FAQ on the feature and I don't remember it ever being bought up in the discussions about the feature although I admit I probably have missed some of the discussion. Has this side effect of the feature been discussed at all? Can someone point me to a thread? https://fedorahosted.org/fesco/ticket/690#comment:8 https://fedorahosted.org/fpc/ticket/118 IIRC from the discussion in FPC meetings, there should be a way to make yum upgrades work but you'd first have to boot up specially and run an initial upgrade script: http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 If the Feature Owners have progressed to the implementing stae, I would greatly appreciate them updating that page with the actual step-by-step to perform the upgrade (which will also allow people to test that things work). I also agree with your point that this discussion should be reflected on the Feature page (Since the Feature page is where marketing material is taken from). Could that be updated as well? -Toshio I wonder where is mentioned the change of guidelines. I didn't find at [1]. Should we stop using /bin in our new packages now or when? I really feel that this change is not well communicated and well planned. I hope someone from FPC will give us an update on changes in packaging. [1] fedoraproject.org/wiki/PackagingGuidelines Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bumblebee on fedora
On 26/01/12 09:35, Mario Santagiuliana wrote: What do you think about bumblebee? And what do you think to package it in Fedora? If you are able to package it, go ahead. https://fedoraproject.org/wiki/Category:Package_Maintainers If not put in on a wishlist. https://fedoraproject.org/wiki/Package_maintainers_wishlist -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Bumblebee on fedora
In data giovedì 26 gennaio 2012 09:33:22, Frank Murphy ha scritto: On 26/01/12 09:35, Mario Santagiuliana wrote: What do you think about bumblebee? And what do you think to package it in Fedora? If you are able to package it, go ahead. https://fedoraproject.org/wiki/Category:Package_Maintainers If not put in on a wishlist. https://fedoraproject.org/wiki/Package_maintainers_wishlist Thank you Frank, I am just a Fedora packager :) I would a feedback from you. I understand that bumblebee is just a temporary project. All the features should be integrate in kernel...but I am not a really expert of Linux kernel... -- Mario Santagiuliana www.marionline.it signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On 26/01/2012 7:31 PM, Kevin Kofler wrote: Live CDs cannot be used to upgrade existing systems. As for the DVD, it does not include the updates repository when doing upgrades (you can only add additional repositories for fresh installations), which means the process is completely broken due to the inevitable upgrade path issues. (You have to run yum update after the DVD upgrade to fix these, and that's if yum isn't affected by the upgrade path issues, which it sometimes is, e.g. it was for Fedora 11.) As I've already stated multiple times, the DVD MUST be fixed to include the updates repository for upgrades (and yes, that means offline upgrades are not possible, they're just not supportable; and yes, if Anaconda still doesn't support any networking other than basic wired Ethernet, that needs to be fixed, too); as is, DVD upgrades are totally unsupportable. Kevin Kofler as i will say again i have no problems downloading a LiveCD or a DvD. if i have had 1 DE installed i'll download a LiveCD only rather than a DvD, some people havent got the bandwidth to download a DvD. i have used a LiveCD in the past without a problem. im suspecting a lot download a LiveCD just to install KDE or Gnome, once that's installed they then yum the rest. i dont see anything wrong with this Feature Fedora/Redhat want by moving all the binaries to /usr . if one doesnt like it then all i can suggest is move to a different Distro. just because it's gonna interupt people from using yum upgrade dist or whatever. this is the 21st century yanno. technology does improve or get better. however if you wanna complain to kevin i can buy you a box of tissues. whether this feature gets pushed in F17 or a later release its gonna be something you cant stop. whinging about it isnt helping anyone. a quote from Rahul i totally agree with. perhapos you should make better approaches to Kev. Nobody breaks things randomly. Sometimes changes have unintentional side effects. You could send patches or make a convincing argument as to why the problem needs to be fixed. Demanding doesn't help accomplish your goals at all. It just annoys people and puts people off any valid points you might make. So think carefully about this and I would recommend that you consider better approaches. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bumblebee on fedora
cc list. On 26/01/12 09:46, Mario Santagiuliana wrote: Thank you Frank, I am just a Fedora packager :) I would a feedback from you. I understand that bumblebee is just a temporary project. All the features should be integrate in kernel...but I am not a really expert of Linux kernel... Maybe check upstream, to see what plans they have for it, or ask on fedora kernel list. They may have some advice to give. -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Locale-SubCountry-1.47.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Locale-SubCountry: e40c500ef7d5ae45b3ab1bb9a05f9a5b Locale-SubCountry-1.47.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Locale-SubCountry] 1.47 bump
commit 8b5fe33268b7e90565d244a780f8e4e0b58e0ea6
Author: Petr Písař ppi...@redhat.com
Date: Thu Jan 26 10:49:25 2012 +0100
1.47 bump
.gitignore |1 +
perl-Locale-SubCountry.spec | 56 ---
sources |2 +-
3 files changed, 28 insertions(+), 31 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index c665bac..7ceeea2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Locale-SubCountry-1.41.tar.gz
+/Locale-SubCountry-1.47.tar.gz
diff --git a/perl-Locale-SubCountry.spec b/perl-Locale-SubCountry.spec
index 5dedd1e..40f57f4 100644
--- a/perl-Locale-SubCountry.spec
+++ b/perl-Locale-SubCountry.spec
@@ -1,69 +1,65 @@
Name: perl-Locale-SubCountry
-Version:1.41
-Release:10%{?dist}
+Version:1.47
+Release:1%{?dist}
Summary:ISO 3166-2 two letter subcountry codes
-
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Locale-SubCountry
-Source0:
http://search.cpan.org/CPAN/authors/id/K/KI/KIMRYAN/Locale-SubCountry-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
+Source0:
http://search.cpan.org/CPAN/authors/id/K/KI/KIMRYAN/Locale-SubCountry-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(Test::Pod), perl(Test::Pod::Coverage)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+BuildRequires: perl(ExtUtils::MakeMaker)
+# Run-time
+BuildRequires: perl(Exporter)
+BuildRequires: perl(locale)
+# Tests
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Simple)
+# Optional test
+BuildRequires: perl(Test::Pod) = 1.14
+BuildRequires: perl(Test::Pod::Coverage) = 1.04
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
This module allows you to convert the full name for a countries administrative
-region to the code commonly used for postal addressing. The reverse lookup can
-also be done. Sub country codes are defined in ISO 3166-2:1998, Codes for the
-representation of names of countries and their subdivisions.
+region to the code commonly used for postal addressing. The reverse look-up
+can also be done. Sub country codes are defined in ISO 3166-2:1998, Codes for
+the representation of names of countries and their subdivisions.
Sub countries are termed as states in the US and Australia, provinces in
Canada and counties in the UK and Ireland.
%prep
%setup -q -n Locale-SubCountry-%{version}
-
-find . -type f -exec chmod -c -x {} +
+find examples -type f -exec chmod -c -x {} +
+for i in Changes lib/Locale/SubCountry.pm; do
+iconv --from=ISO-8859-1 --to=UTF-8 $i new
+mv new $i
+done
+sed -i -e $'1 i =encoding utf8\\\n' lib/Locale/SubCountry.pm
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
-# make sure the man page is UTF-8...
-#cd blib/man3
-for i in Changes blib/man3/Locale::SubCountry.3pm ; do
-iconv --from=ISO-8859-1 --to=UTF-8 $i new
-mv new $i
-done
-
%install
-rm -rf %{buildroot}
-
make pure_install PERL_INSTALL_ROOT=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -type d -depth -exec rmdir {} 2/dev/null ';'
-
%{_fixperms} %{buildroot}/*
-
%check
make test
-
-%clean
-rm -rf %{buildroot}
-
-
%files
-%defattr(-,root,root,-)
%doc Changes README examples/
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
+* Thu Jan 26 2012 Petr Pisar ppi...@redhat.com - 1.47-1
+- 1.47 bump
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.41-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
diff --git a/sources b/sources
index 226e0bc..920e9a3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-44f6b0cc4b1ad5db591e45d1395d2d7f Locale-SubCountry-1.41.tar.gz
+e40c500ef7d5ae45b3ab1bb9a05f9a5b Locale-SubCountry-1.47.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
Am 26.01.2012 10:42, schrieb Greg: if one doesnt like it then all i can suggest is move to a different Distro. just because it's gonna interupt people from using yum upgrade dist or whatever. this is the 21st century yanno. technology does improve or get better. where is the improvement or does anything get better if things worked for years got damaged? you definition of improvement must have a bug! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bumblebee on fedora
On 26/01/12 09:46, Mario Santagiuliana wrote: Thank you Frank, I am just a Fedora packager :) I would a feedback from you. I understand that bumblebee is just a temporary project. All the features should be integrate in kernel...but I am not a really expert of Linux kernel... I've had a quick read ot the release notes. This may be beerter served ,with the people who look after the nVidia packages on rpmfusion. As it seem to have to be an unloadable module. Open to corrction. -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bumblebee on fedora
I looked into packaging it for Fedora a while back, but there are a couple of issues, iirc. First of all, you'll also need to package VirtualGL, which isn't part of Fedora at the moment either. Aside from that, Bumblebee(d) needs one of the vga_switcheroo, acpi_call or similar kernel modules to do power management, right? Those kernel modules are out-of-tree and Fedora does not ship out-of-tree kernel modules. So indeed, RPMFusion is probably a better place, since they can distribute kmod RPM's. Apart from that that, I installed bumblebee(d) on Fedora (I'm using it right now) and it wasn't a real big issue. Maxim Burgerhout ma...@wzzrd.com EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A On Thu, Jan 26, 2012 at 10:33, Frank Murphy frankl...@gmail.com wrote: On 26/01/12 09:35, Mario Santagiuliana wrote: What do you think about bumblebee? And what do you think to package it in Fedora? If you are able to package it, go ahead. https://fedoraproject.org/**wiki/Category:Package_**Maintainershttps://fedoraproject.org/wiki/Category:Package_Maintainers If not put in on a wishlist. https://fedoraproject.org/**wiki/Package_maintainers_**wishlisthttps://fedoraproject.org/wiki/Package_maintainers_wishlist -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Statistics-Basic-1.6607.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Statistics-Basic: 6d0857688035c62a6979af9b15dcb030 Statistics-Basic-1.6607.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: gcc 4.7 changes binary behaviors ?
On Thu, 26 Jan 2012 08:12:43 +0100, Sérgio Basto wrote: /usr/bin/kmk_sed: file /builddir/build/BUILD/VirtualBox-4.1.8_OSE/src/VBox/Runtime/common/err/errmsg.sed line 31: Unmatched [ or [^ kmk: *** [/builddir/build/BUILD/VirtualBox-4.1.8_OSE/obj/obj/Runtime/errmsgdata.h] Error 1 kmk: *** Deleting file `/builddir/build/BUILD/VirtualBox-4.1.8_OSE/obj/obj/Runtime/errmsgdata.h' kmk: *** Waiting for unfinished jobs build virtualbox with same kBuild but that was build with gcc 4.6 I don't have this problem using kBuild-0.1.98-1.r1.fc17 works, using kBuild-0.1.98-2.r1.fc17 I got this error, with kmk_sed. Any clue is appreciated kmk_sed is most probably using some undefined C behavior which only fortunately worked with gcc-4.6. You should try compiling kmk_sed first with -O0 and then checking whether the specific function having this problem there is really valid ISO C. As an illustration gcore also broke with gcc-4.7 but it was a bug of gcore: http://sourceware.org/ml/binutils/2011-12/msg00298.html Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On 26/01/2012 8:58 PM, Reindl Harald wrote: where is the improvement or does anything get better if things worked for years got damaged? you definition of improvement must have a bug! first thing. i agree that the Linux Filesystem needs to be cleaned up. by doing what redhat/Fedora is progressing to do with the filesystem makes it easier. its been Noted in OsNews about it. im sure elsewhere to. Google is your friend, use it. if you dont know where the improvement is, use Google. im not google. or lookup the feature page which im sure has some kinda Documentation about it. Fedora is to Test Up-coming Technology Distro that may make its way into RHEL. take for instance Grub2. may not even see its way into RHEL7 till its stable and at 2.0 . not 1.99. if your not happy with what Fedora/Redhat are doing there's is a list of Linux Distributions you can use at your own leisure. but by Demanding Fedora/Redhat not do this is a bit silly. im sure you were or have been told many times Fedora is a Testing Release for RHEL but this Demanding approach of yours isnt really getting anywhere . your one of these people that hate Change but there's no need to start Demanding things you want yourself. just because its gonna ruin you from using yum to upgrade when all one has to do is download a DvD. i know you have said it before that a DvD upgrade could or can go wrong. but here's my point. lets say your downloading a upgrade and the upgrade gets to 87% and your power goes out for some time. what are you gonna do then? you'll come to the mailing list and say my yum upgrade doesnt work. when all you had to do was download a DvD. only time i have seen a DvD install go wrong and that's when some chooses the wrong repo's during install. but yes lets go back to the dark Ages and forget about Technology. im all for redhat/Fedora doing this if it simplifies the filesystem -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
2012/1/26 Markus Mayer lotharl...@gmx.de: On 01/26/2012 02:19 AM, Kevin Fenzi wrote: On Wed, 25 Jan 2012 21:37:36 -0200 Henrique Juniorhenrique...@gmail.com wrote: I would like to see Fedora following the path of rolling release. openSUSE is doing a great job with the Tumbleweed, still keeping the same old system of releases and letting users choose whether or not using roling release. Particularly I wouldn't like to see this thread dying as happened in other occasions, after all, we know that discussions may not lead to anything, and sometimes small actions can be more productive than long threads [1]. I wonder if we could create a poll (for active members with FAS accounts) to determine what the community thinks about it. After the poll, if the idea of rolling release receives most votes then would be the time to discuss how and when doing the implementation. I would personally advise against this way forward. I'd like to suggest an alternative: * Gather folks interested in this (you should be able to see some from this thread). Perhaps announce that you are forming a group to look into this. * Get together and write up a wiki page / detailed proposal, answering: - How would this work? - What resources would you need? - What impact does it have on maintainers? users? release engineering? - Would this work alongside the current setup? Or would it be one or the other? - Try and answer questions raised by folks in this thread. - Try and list advantages. Why would we want to do this? what does it get us? * Post again once you have details and ask for more feedback. * Repeat cycle until you find it's ready and then ask fesco to take a look. Just a suggestion... kevin +1 Create suggestion I would like to join such a SIG. regards Markus -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Did we have someone to lead this process? -- Henrique LonelySpooky Junior -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
Am 26.01.2012 12:29, schrieb Greg: On 26/01/2012 8:58 PM, Reindl Harald wrote: where is the improvement or does anything get better if things worked for years got damaged? you definition of improvement must have a bug! first thing. i agree that the Linux Filesystem needs to be cleaned up. have i said something against this? no, i speak about the HOW! but here's my point. lets say your downloading a upgrade and the upgrade gets to 87% and your power goes out for some time. what are you gonna do then? reboot and start again - yes i had this case in the past yum-complete-transaction and package-cleanup is your friend a small UPS does not cost too much an prevents from such cases but to be honesty - have a power outage while dist-upgrade is like win in the lottery you'll come to the mailing list and say my yum upgrade doesnt work. WTF - who will do this in the case of a power outage and what the hell does a upgrade with DVD if your power goes down? there is no difference to a yum upgrade - you have a undefined state so please stop with such senseless arguments! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On Wed, Jan 25, 2012 at 11:19 PM, Kevin Fenzi ke...@scrye.com wrote: I would personally advise against this way forward. I'd like to suggest an alternative: * Gather folks interested in this (you should be able to see some from this thread). Perhaps announce that you are forming a group to look into this. * Get together and write up a wiki page / detailed proposal, answering: - How would this work? - What resources would you need? - What impact does it have on maintainers? users? release engineering? - Would this work alongside the current setup? Or would it be one or the other? - Try and answer questions raised by folks in this thread. - Try and list advantages. Why would we want to do this? what does it get us? * Post again once you have details and ask for more feedback. * Repeat cycle until you find it's ready and then ask fesco to take a look. Just a suggestion... +1 Good idea! -- Elder Marco GNU/Linux User: #471180 Contra o positivismo, que pára perante os fenômenos e diz: 'Há apenas fatos', eu digo: 'Ao contrário, fatos é o que não há; há apenas interpretações'. (Nietzsche) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On 26/01/12 11:37, Henrique Junior wrote: Did we have someone to lead this process? possibly the op -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 08:42:15PM +1100, Greg wrote: On 26/01/2012 7:31 PM, Kevin Kofler wrote: Live CDs cannot be used to upgrade existing systems. As for the DVD, it does not include the updates repository when doing upgrades (you can only add additional repositories for fresh installations), which means the process is completely broken due to the inevitable upgrade path issues. (You have to run yum update after the DVD upgrade to fix these, and that's if yum isn't affected by the upgrade path issues, which it sometimes is, e.g. it was for Fedora 11.) As I've already stated multiple times, the DVD MUST be fixed to include the updates repository for upgrades (and yes, that means offline upgrades are not possible, they're just not supportable; and yes, if Anaconda still doesn't support any networking other than basic wired Ethernet, that needs to be fixed, too); as is, DVD upgrades are totally unsupportable. Kevin Kofler as i will say again i have no problems downloading a LiveCD or a DvD. if i have had 1 DE installed i'll download a LiveCD only rather than a DvD, some people havent got the bandwidth to download a DvD. And yet others do not have to download either of them, because there already is (was) a perfectly reasonable way to perform an upgrade without it. i have used a LiveCD in the past without a problem. im suspecting a lot download a LiveCD just to install KDE or Gnome, once that's installed they then yum the rest. i dont see anything wrong with this Feature Fedora/Redhat want by moving all the binaries to /usr . Fedora is not some abstract entity with dictatorial powers. Fedora are the people who contribute to it. And they have the right to speak up when they do not like something, whether _you_ like it or not. if one doesnt like it then all i can suggest is move to a different Distro. This thread is not questioning the feature itself but the way it is being done. just because it's gonna interupt people from using yum upgrade dist or whatever. this is the 21st century yanno. Exactly. CDs/DVDs are thing of the past, online update is the way to go. So it is questionable why we need to return to the past... technology does improve or get better. however if you wanna complain to kevin i can buy you a box of tissues. whether this feature gets pushed in F17 or a later release its gonna be something you cant stop. Again, this is not about stopping it but doing it in the least disruptive way. Btw, if you are not able to talk in reasonably polite manner, it would be better if you did not talk at all. D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Bumblebee on fedora
In data giovedì 26 gennaio 2012 11:19:39, Maxim Burgerhout ha scritto: I looked into packaging it for Fedora a while back, but there are a couple of issues, iirc. First of all, you'll also need to package VirtualGL, which isn't part of Fedora at the moment either. Aside from that, Bumblebee(d) needs one of the vga_switcheroo, acpi_call or similar kernel modules to do power management, right? Those kernel modules are out-of-tree and Fedora does not ship out-of-tree kernel modules. So indeed, RPMFusion is probably a better place, since they can distribute kmod RPM's. Apart from that that, I installed bumblebee(d) on Fedora (I'm using it right now) and it wasn't a real big issue. Thanks to all for the precious info! -- Mario Santagiuliana www.marionline.it signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
For the sake of completeness: On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote: after a yum upgrade you can verify that the most important things are fine BEFORE reboot (bootloader-config, package-cleanup --problems, ), optimize/correct things you know are not fine after the upgrade (active services after transition to systemd as example) and then you reboot ONCE in a clean starting system instead a boot in the blue ... as can be done on VC2 after updating with anaconda. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
Am 26.01.2012 14:08, schrieb Nils Philippsen: For the sake of completeness: On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote: after a yum upgrade you can verify that the most important things are fine BEFORE reboot (bootloader-config, package-cleanup --problems, ), optimize/correct things you know are not fine after the upgrade (active services after transition to systemd as example) and then you reboot ONCE in a clean starting system instead a boot in the blue ... as can be done on VC2 after updating with anaconda while the system and services are running? show me how you will do this! you are missing the point that yum distro-sync is running while the system is up and can be distributed after testing AUTOMATICALLY to 10,20,30,100 machines followed by a 30 seconds reboot shutdown the VM, insert the ISO and boot anaconda takes much longer as the whole upgrade via yum - our machines needed between 4 and 6 minutes each server for the whole F14-F15 upgrade, so in an hour you have all machines updated with nearly zero downtime a change which damages this capabilities has to be fixed signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On Thu, 2012-01-26 at 14:19 +0100, Reindl Harald wrote: Am 26.01.2012 14:08, schrieb Nils Philippsen: For the sake of completeness: On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote: after a yum upgrade you can verify that the most important things are fine BEFORE reboot (bootloader-config, package-cleanup --problems, ), optimize/correct things you know are not fine after the upgrade (active services after transition to systemd as example) and then you reboot ONCE in a clean starting system instead a boot in the blue ... as can be done on VC2 after updating with anaconda while the system and services are running? show me how you will do this! This not what I wrote. you are missing the point that yum distro-sync is running while the system is up and can be distributed after testing AUTOMATICALLY to 10,20,30,100 machines followed by a 30 seconds reboot I am well aware of the differences between doing an upgrade with anaconda and doing it with yum in a live system. I've done enough of the latter to at least shut down critical processes (e.g. MTA, database server software) before doing a yum upgrade, because stuff tends to hick-up if you pull the rug from underneath it (e.g. if files get moved around, renamed, dynamically loaded modules are replaced by newer versions with new API, data formats change, ...). What you described sounds too non-deterministic for my taste. Granted, you reduce the amount of planned downtime with this scheme, but you trade that in for a heightened risk of unplanned downtime should stuff break in the process. And testing only buys you a limited sense of security here. shutdown the VM, insert the ISO and boot anaconda takes much longer as the whole upgrade via yum - our machines needed between 4 and 6 minutes each server for the whole F14-F15 upgrade, so in an hour you have all machines updated with nearly zero downtime If all goes well. The move of pretty much every basic user space building block from / to /usr has enough potentially disruptive qualities that I'd rather have the patient not be the surgeon in this round of open heart surgery. In less colorful words, anaconda is self-sufficient, it brings everything it needs with it, i.e. its libc, loader and so forth won't magically move to a different place so the installer won't suddenly break because stuff it uses is removed, or in a different place or format than expected. So if something breaks badly during the upgrade I have a working shell and a small set of essential tools that continue to work regardless, with which I can fix things. This gives me enough warm fuzzy feelings that I'll happily spend the little more planned downtime on it this time. a change which damages this capabilities has to be fixed For the situation we're discussing, I'll take safety over speed any time. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
Am 25.01.2012 23:48, schrieb Peter Robinson: Hi All, So I saw a rpm update and a number of other builds today when dealing with various packaging bits. Checking the update [1] and reading the attached bug [2] I was a little shocked to find that yum upgrade between releases would be explicitly broken due to this feature. Not really true. yum upgrade will be supported, but it needs a little help with a special initramfs and an additional kernel command line parameter, so that dracut can convert your filesystem. After this filesystem conversion, yum upgrade will work without problems. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
Am 26.01.2012 15:07, schrieb Nils Philippsen: On Thu, 2012-01-26 at 14:19 +0100, Reindl Harald wrote: Am 26.01.2012 14:08, schrieb Nils Philippsen: For the sake of completeness: On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote: after a yum upgrade you can verify that the most important things are fine BEFORE reboot (bootloader-config, package-cleanup --problems, ), optimize/correct things you know are not fine after the upgrade (active services after transition to systemd as example) and then you reboot ONCE in a clean starting system instead a boot in the blue ... as can be done on VC2 after updating with anaconda while the system and services are running? show me how you will do this! This not what I wrote. you did - you wrote as can be done I am well aware of the differences between doing an upgrade with anaconda and doing it with yum in a live system. I've done enough of the latter to at least shut down critical processes (e.g. MTA, database server software) before doing a yum upgrade, because stuff tends to hick-up if you pull the rug from underneath it (e.g. if files get moved around, renamed, dynamically loaded modules are replaced by newer versions with new API, data formats change, ...). What you described sounds too non-deterministic for my taste. Granted, you reduce the amount of planned downtime with this scheme, but you trade that in for a heightened risk of unplanned downtime should stuff break in the process. And testing only buys you a limited sense of security here. we build critical server packages usually on our own infrastructure and do version changes sepearted from the dist-upgrade as also the automatic restart on update is removed from all packages as example we had MySQL 5.5 on F13 there is no limited sense of security each machine has a clone for backup-reasons this clones are updated first so after that i know the exactly behavior and these capabilities are exactly what anaconda can NOT provide shutdown the VM, insert the ISO and boot anaconda takes much longer as the whole upgrade via yum - our machines needed between 4 and 6 minutes each server for the whole F14-F15 upgrade, so in an hour you have all machines updated with nearly zero downtime If all goes well it does as explained above The move of pretty much every basic user space building block from / to /usr has enough potentially disruptive qualities that I'd rather have the patient not be the surgeon in this round of open heart surgery if you have a identical clone of a whole machine you can play around with the upgrade as often as needed (snapshots) and can prepare the whole transition, no matter preparing configurations or rebuild packages as needed the production machines are done after this tests / prepares usually it takes 1-2 days to prepare a fedora dist-upgrade for our production servers and the real update takes 5 minutes for each machine with a 100% clear step-for-step-list a change which damages this capabilities has to be fixed For the situation we're discussing, I'll take safety over speed any time read my explanation above the way i rollout is much more safe as any anaconda update because i can prepare every single package if it is needed and our production servers NEVER access the feodra repos directly there is ALWAYS the internal build/repo-cache server between and that is why anaconda is unuseable and it would be a shame damage this capabilities while my upgrade-szenario worked from F7 to F15 on 20 machines without any single problem and from 3 upgrades with anaconda on my workstation 2 failed to boot after that and the second failed one was my last anaconda update (the one try with preupgrade did also fail) while on the other side i made around 180 yum-dist-upgrades without troubles on production environment and around 100 on test/development-VM's also without problems signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-XML-Stream] 1.23 bump and some cleanup
commit 1adb6bfaff3b08303a834b9c51d9146a6e7a9ce9
Author: Petr Šabata con...@redhat.com
Date: Thu Jan 26 15:46:43 2012 +0100
1.23 bump and some cleanup
.gitignore |1 +
perl-XML-Stream.spec | 57 ++
sources |2 +-
3 files changed, 27 insertions(+), 33 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 63c2c82..40b6691 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
XML-Stream-1.22.tar.gz
+/XML-Stream-1.23.tar.gz
diff --git a/perl-XML-Stream.spec b/perl-XML-Stream.spec
index 99629a6..5cdbcd4 100644
--- a/perl-XML-Stream.spec
+++ b/perl-XML-Stream.spec
@@ -1,6 +1,6 @@
Name: perl-XML-Stream
-Version:1.22
-Release:17%{?dist}
+Version:1.23
+Release:1%{?dist}
Summary:XML::Stream - streaming XML library
Group: Development/Libraries
@@ -8,21 +8,26 @@ License:(GPL+ or Artistic) or LGPLv2+
URL:http://search.cpan.org/dist/XML-Stream/
Source0:
http://search.cpan.org/CPAN/authors/id/R/RE/REATMON/XML-Stream-%{version}.tar.gz
Source1:LICENSING.correspondance
-Patch0: tests.patch
-BuildArch: noarch
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-
+BuildArch: noarch
+BuildRequires: perl(base)
+BuildRequires: perl(threads)
+BuildRequires: perl(threads::shared)
+BuildRequires: perl(Authen::SASL)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(HTTP::ProxyAutoConfig)
+BuildRequires: perl(IO::Select)
+BuildRequires: perl(IO::Socket)
BuildRequires: perl(IO::Socket::SSL)
-BuildRequires: perl(Net::DNS)
-BuildRequires: perl(Authen::SASL)
BuildRequires: perl(MIME::Base64)
-
+BuildRequires: perl(Net::DNS)
+BuildRequires: perl(Test::Builder)
+BuildRequires: perl(Test::More)
Requires: perl(IO::Socket::SSL)
Requires: perl(Net::DNS)
-# also pulled in via a 'requires' construct; but not yet in Fedora
-#Requires: perl(HTTP::ProxyAutoConfig)
+Requires: perl(HTTP::ProxyAutoConfig)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
This module provides the user with methods to connect to a remote server,
@@ -43,46 +48,34 @@ look at the detailed description at the end of the file.
%prep
%setup -q -n XML-Stream-%{version}
-%patch0
-
cp %{SOURCE1} .
-# generate our other two licenses...
-perldoc perlgpl LICENSE.GPL
-perldoc perlartistic LICENSE.Artistic
-
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags}
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
-
%install
-rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
-
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -type d -depth -exec rmdir {} 2/dev/null ';'
-
%{_fixperms} %{buildroot}/*
-
%check
%{?_with_network_tests: make test}
-
rm -rf t/lib
-%clean
-rm -rf %{buildroot}
-
-
%files
-%defattr(-,root,root,-)
-%doc CHANGES README INFO LICENSE.* LICENSING* t/
+%doc CHANGES README INFO LICENSING* t/
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
-
%changelog
+* Mon Jan 23 2012 Petr Šabata con...@redhat.com - 1.23-1
+- 1.23 bump
+- Spec cleanup
+- Removing the unneeded tests patch
+- We are noarch, removing optflags
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.22-17
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
diff --git a/sources b/sources
index 29b3445..878f2e2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ae09400fac17eaea4c9b12283db06881 XML-Stream-1.22.tar.gz
+1c0908384fe57a1c3c529071a8b882af XML-Stream-1.23.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On 26/01/12 14:43, Harald Hoyer wrote: Not really true. yum upgrade will be supported, but it needs a little help with a special initramfs and an additional kernel command line parameter, so that dracut can convert your filesystem. After this filesystem conversion, yum upgrade will work without problems. Will a howto be ready for those going from F17-Rawhide\F16+ to F17-Branched. If /usr is ready by then. -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 2:43 PM, Harald Hoyer har...@redhat.com wrote: Am 25.01.2012 23:48, schrieb Peter Robinson: Hi All, So I saw a rpm update and a number of other builds today when dealing with various packaging bits. Checking the update [1] and reading the attached bug [2] I was a little shocked to find that yum upgrade between releases would be explicitly broken due to this feature. Not really true. yum upgrade will be supported, but it needs a little help with a special initramfs and an additiona So why isn't it documented as such? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-Gtk2-Ex-Simple-List ownership changed
Package perl-Gtk2-Ex-Simple-List in Fedora 16 is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Gtk2-Ex-Simple-List -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-Gtk2-Ex-Simple-List ownership changed
Package perl-Gtk2-Ex-Simple-List in Fedora devel is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Gtk2-Ex-Simple-List -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-Gtk2-Ex-Simple-List ownership changed
Package perl-Gtk2-Ex-Simple-List in Fedora 15 is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Gtk2-Ex-Simple-List -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
Am 26.01.2012 15:51, schrieb Frank Murphy: On 26/01/12 14:43, Harald Hoyer wrote: Not really true. yum upgrade will be supported, but it needs a little help with a special initramfs and an additional kernel command line parameter, so that dracut can convert your filesystem. After this filesystem conversion, yum upgrade will work without problems. Will a howto be ready for those going from F17-Rawhide\F16+ to F17-Branched. If /usr is ready by then. HOWTO is in the making -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-IO-TieCombine ownership changed
Package perl-IO-TieCombine in Fedora 16 is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-IO-TieCombine -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-IO-TieCombine ownership changed
Package perl-IO-TieCombine in Fedora devel is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-IO-TieCombine -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-IO-TieCombine ownership changed
Package perl-IO-TieCombine in Fedora 15 is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-IO-TieCombine -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 09:25:31AM +, Peter Robinson wrote: On Thu, Jan 26, 2012 at 1:34 AM, Toshio Kuratomi a.bad...@gmail.com wrote: IIRC from the discussion in FPC meetings, there should be a way to make yum upgrades work but you'd first have to boot up specially and run an initial upgrade script: http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 How does that work on headless devices? It doesn't seem to be well tested. In fact there doesn't seem to be a way to be able to test it. To test -- 1) install F16. 2) Run through procedure outlined on wiki (once the Feature Owners fill in the blanks) 3) Se if you then have a working F17 system For headless devices I do not know -- you'll need the Feature Owners to answer that one. This should have been in rawhide months ago. This is just asking for slippage of the schedule. Yeah, I agree that rawhide is for breakage and things should land as early as possible... but lots of people don't agree. I'm guessing that the Feature process is going to need to change to accomodate them rather than the other way around. IMO this is too late and there's too many widely impacting things that haven't been widely announced. Personally I think, similar to what happened in F-14 with systemd, this feature should be pushed back to F-18 to give the feature developers more time to properly develop and test things like those scripts or decent procedures in order to be able to progress this properly rather than throwing it over the fence a week or so before feature freeze/branch and ensuring a just about guaranteed slip of the schedule. This just makes a whole mockery of the Feature process and basically gives the idea that a number of people thing they can just do as they please, when they please and ride rough shod over the process. Please file a fesco meeting ticket. I also agree with your point that this discussion should be reflected on the Feature page (Since the Feature page is where marketing material is taken from). Could that be updated as well? It's also where a lot of people go to figure out the impact and how they can test various features. There's not a single mention of yum upgrade breakage or change of process. +1 -Toshio pgp0H2BCZ3P72.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 09:40:33AM +0100, Kevin Kofler wrote: I wrote: IMHO this is a showstopper and approval for UsrMove should be withdrawn and the feature reverted. PS: Oh, and I don't see why this cannot be fixed by a %pretrans scriptlet in filesystem rather than a script we have to run by hand. That's what %pretrans is for. (We successfully used %pretrans to convert directories to symlinks or the opposite in a couple cases in KDE packaging in the past. None were directories as important as the ones being touched by UsrMove though!) And the scriptlet having been written BEFORE starting to convert packages should have been a requirement for approving this feature. https://fedorahosted.org/fpc/ticket/118#comment:7 -Toshio pgpaqAOcEIpC1.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 3:22 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Thu, Jan 26, 2012 at 09:25:31AM +, Peter Robinson wrote: On Thu, Jan 26, 2012 at 1:34 AM, Toshio Kuratomi a.bad...@gmail.com wrote: IIRC from the discussion in FPC meetings, there should be a way to make yum upgrades work but you'd first have to boot up specially and run an initial upgrade script: http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 How does that work on headless devices? It doesn't seem to be well tested. In fact there doesn't seem to be a way to be able to test it. To test -- 1) install F16. 2) Run through procedure outlined on wiki (once the Feature Owners fill in the blanks) 3) Se if you then have a working F17 system The packages aren't in F-17 yet. See the contents of the f17-usrmove tag in koji. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 03:26:01PM +, Peter Robinson wrote: On Thu, Jan 26, 2012 at 3:22 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Thu, Jan 26, 2012 at 09:25:31AM +, Peter Robinson wrote: On Thu, Jan 26, 2012 at 1:34 AM, Toshio Kuratomi a.bad...@gmail.com wrote: IIRC from the discussion in FPC meetings, there should be a way to make yum upgrades work but you'd first have to boot up specially and run an initial upgrade script: http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 How does that work on headless devices? It doesn't seem to be well tested. In fact there doesn't seem to be a way to be able to test it. To test -- 1) install F16. 2) Run through procedure outlined on wiki (once the Feature Owners fill in the blanks) 3) Se if you then have a working F17 system The packages aren't in F-17 yet. See the contents of the f17-usrmove tag in koji. Ah -- I didn't understand that you wanted a method to test it *now*. Yep, if the work hasn't landed in rawhide, there is no way to test. That's pretty self explanatory. When the feature owner has to land their changes so that they're testable is laid out in the policy: * New features must be feature complete or close enough to completion by Feature Freeze so that a majority of its functionality can be tested during the Alpha and Beta releases. http://fedoraproject.org/wiki/Features/Policy/Milestones As you've been pointing out, this is a recipe for alpha slippage (and since recently we've been slipping all later milestones, a slip in alpha means a slip to the release) but I don't think the feature owners are technically doing anything wrong under the current policy :-( -Toshio pgpZAk5PCnDED.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up: possible libOSMesa soname bump in rawhide
We're going to update Mesa to a pre-8.0 snapshot in anticipation of shipping 8.0 in F17. Typically the libOSMesa version number is bumped when this happens. However there's no real ABI change, so the rebuild should be trivial. Sorry for the late announcement, but this should be pretty low impact. Currently the only user in F17 appears to be paraview (which is odd, I thought there were more). I'll rebuild that once and if needed. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-GD-Barcode ownership changed
Package perl-GD-Barcode in Fedora 16 is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-GD-Barcode -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-GD-Barcode ownership changed
Package perl-GD-Barcode in Fedora devel is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-GD-Barcode -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-GD-Barcode ownership changed
Package perl-GD-Barcode in Fedora 15 is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-GD-Barcode -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-PDF-Reuse ownership changed
Package perl-PDF-Reuse in Fedora 16 is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-PDF-Reuse -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-PDF-Reuse ownership changed
Package perl-PDF-Reuse in Fedora 15 is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-PDF-Reuse -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-rpm-build-perl ownership changed
Package perl-rpm-build-perl in Fedora 16 is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-rpm-build-perl -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-rpm-build-perl ownership changed
Package perl-rpm-build-perl in Fedora devel is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-rpm-build-perl -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-rpm-build-perl ownership changed
Package perl-rpm-build-perl in Fedora 15 is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-rpm-build-perl -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
On Thu, Jan 26, 2012 at 6:43 AM, Harald Hoyer har...@redhat.com wrote: Not really true. yum upgrade will be supported, but it needs a little help with a special initramfs and an additional kernel command line parameter, so that dracut can convert your filesystem. After this filesystem conversion, yum upgrade will work without problems. This satisfies my needs; a reboot for conversion is not ideal, but not the end of the world (and understandable, in this case). There seems to be a great deal of resistance to the RPM changes that are required, though, both for RHEL and Fedora (at least in their respective BZ entries); will updated versions of rpm be generally available in F16 and RHEL6 at the time of F17's release? -- Ed Marshall e...@logic.net Felix qui potuit rerum cognoscere causas. http://esm.logic.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
Am 26.01.2012 17:19, schrieb Ed Marshall: On Thu, Jan 26, 2012 at 6:43 AM, Harald Hoyer har...@redhat.com wrote: Not really true. yum upgrade will be supported, but it needs a little help with a special initramfs and an additional kernel command line parameter, so that dracut can convert your filesystem. After this filesystem conversion, yum upgrade will work without problems. This satisfies my needs; a reboot for conversion is not ideal, but not the end of the world (and understandable, in this case). There seems to be a great deal of resistance to the RPM changes that are required, though, both for RHEL and Fedora (at least in their respective BZ entries); will updated versions of rpm be generally available in F16 and RHEL6 at the time of F17's release? RHEL6 has all ACKs F17 is already in F15 and F16 are in updates-testing, AFAIK -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On Thu, Jan 26, 2012 at 00:22:28 -0500, Scott Schmit i.g...@comcast.net wrote: Except that this doesn't burn people often because Linus is also *very* strict about interface changes between the kernel userspace. Hardware specific regressions aren't that rare. I have run into them several times. I have had problems with disk controllers, USB flash drives and video cards. Sometimes there are work arounds (e.g. using nomodeset or disabling AGP), other times I just stayed on old kernels for a while. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
I just had a conversation which I believe sheds some light on the problem which a rolling release is trying to solve. The example is Ubuntu bu you could apply the same to Fedora/RHEL. My coworker wants to use Ubuntu LTS for development on Heroku. He wants the stability of an LTS, but he needs a later version of Ruby to run the Heroku tools. He has found that there is not supported way to upgrade Ruby short of recompiling Ruby or upgrading his entire system. Because of this he has returned to developing on OS X which handles the Ruby upgrade. I understand the cry of what about dependencies? However, if Linux is to succeed we need to be able to be able to work with cases like this one which OS X are fine with i.e. where only one or two packages out of an entire system need to be upgraded leaving the rest of the system alone. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Wednesday 25 January 2012 19:05:37 Manuel Escudero wrote: And also I've been told this desktop is available for ArchLinux now as well... As for this facts I was wondering how feasible is to port Unity to Fedora as well The last I heard from the Arch packaging efforts was that Unity won't be an officially supported package until it no longer depends on non-upstream patches to GTK+ and friends. The same seems to be true for OpenSuse: Since we're replacing some of the core components of openSUSE (ex: GTK+, gnome-session) the priority is important. (pasted from your link) I don't think I'm going out on a limb if I say that this doesn't look like Unity will hit Fedora repos anytime soon. You may look at repos.fedorapeople.org, though. As far as I remember Adam Williamson once looked at the feasibility of packaging Unity for Fedora. Don't know what was the result, though. Maybe he can elaborate on that. Lars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On 01/26/2012 02:05 AM, Manuel Escudero wrote: I don't know if you're aware of this or not, but a user managed to port Ubuntu's Unity to OpenSUSE 12.1 as you can see here: http://en.opensuse.org/openSUSE:GNOME_Ayatana And also I've been told this desktop is available for ArchLinux now as well... As for this facts I was wondering how feasible is to port Unity to Fedora as well (Now that we have OpenSUSE RPM packages of the Unity sources and deps available to play with) and if someone is interested in trying to bring the Unity Desktop to Fedora If no one is, I was wondering where is a good place to start trying to do it so I can try it myself and then maybe I gather some other interested ones... -- Manuel Escudero Linux User #509052 Twitter: @Jmlevick http://twitter.com/Jmlevick Blogger: Blog Xenode http://xenodesystems.blogspot.com/ PGP/GnuPG: E2F5 12FA E1C3 FA58 CF15 8481 B77B 00CA C1E1 0FA7 Xenode Systems - xenodesystems.com http://www.xenodesystems.com/ - Conéctate a Tu Mundo I remember Adam W took a look at this a while ago. Not sure where he ended up with it. [1] [1] http://www.happyassassin.net/2010/12/03/unity-on-fedora-possibly/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On 26/01/12 17:15, Mark Bidewell wrote: My coworker wants to use Ubuntu LTS for development on Heroku. He wants the stability of an LTS, but he needs a later version of Ruby to run the Heroku tools. He has found that there is not supported way to upgrade Ruby short of recompiling Ruby or upgrading his entire system. Because of this he has returned to developing on OS X which handles the Ruby upgrade. Supported by Fedora or Ruby? -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On Thu, Jan 26, 2012 at 8:09 AM, Bruno Wolff III br...@wolff.to wrote: Hardware specific regressions aren't that rare. I have run into them several times. I have had problems with disk controllers, USB flash drives and video cards. Sometimes there are work arounds (e.g. using nomodeset or disabling AGP), other times I just stayed on old kernels for a while. And it should be pointed out, the kernel is handled as a very special case in our packaging. We understand and expect people to have multiple parallel installed kernel packages on system. So if and when you do hit a hardware regression you usually have the ability to fallback to an older kernel that was working for you because it was not removed from the system when the new kernel was installed. The point being, we don't make it easy to do that for other packaged components. A fear a full rolling release would involve some deep re-engineering of everything we package to make it possible to parallel install multiple versions of everything. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On 01/26/2012 10:45 PM, Mark Bidewell wrote: I just had a conversation which I believe sheds some light on the problem which a rolling release is trying to solve. The example is Ubuntu bu you could apply the same to Fedora/RHEL. My coworker wants to use Ubuntu LTS for development on Heroku. He wants the stability of an LTS, but he needs a later version of Ruby to run the Heroku tools. Rolling releases won't solve this problem because your coworker wants the stability of long releases. He wants the base to be stable and edges to be fluid. He has found that there is not supported way to upgrade Ruby short of recompiling Ruby or upgrading his entire system. Because of this he has returned to developing on OS X which handles the Ruby upgrade. I understand the cry of what about dependencies? However, if Linux is to succeed we need to be able to be able to work with cases like this one which OS X are fine with i.e. where only one or two packages out of an entire system need to be upgraded leaving the rest of the system alone. The solution that Mac OS X has come up with is bundling however the problem is that Linux is not a monolithic platform like Mac OS X and the amount of bundling you have to do is much higher. Nothing other than kernel or maybe glibc can be guaranteed to exist. There are some tools in this area. glick for instance: http://people.gnome.org/~alexl/glick2/ Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On Thu, Jan 26, 2012 at 12:37 PM, Frank Murphy frankl...@gmail.com wrote: On 26/01/12 17:15, Mark Bidewell wrote: My coworker wants to use Ubuntu LTS for development on Heroku. He wants the stability of an LTS, but he needs a later version of Ruby to run the Heroku tools. He has found that there is not supported way to upgrade Ruby short of recompiling Ruby or upgrading his entire system. Because of this he has returned to developing on OS X which handles the Ruby upgrade. Supported by Fedora or Ruby? -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Since he was using Ubuntu I will say distro-supported, but if he was using Fedora it would be Fedora supported. Ruby does not maintain distro specific packages. Ubuntu has PPAs but these are somewhat spotty for some software. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On 26/01/12 17:43, Mark Bidewell wrote: Since he was using Ubuntu I will say distro-supported, but if he was using Fedora it would be Fedora supported. Ruby does not maintain distro specific packages. Ubuntu has PPAs but these are somewhat spotty for some software. Sorry, I meant if he wasn't worried about Fedora supporting his Ruby. He could have used rvm to keep updated. ditto Ubuntu. -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On Thu, 26 Jan 2012 12:15:01 -0500 Mark Bidewell mbide...@gmail.com wrote: I just had a conversation which I believe sheds some light on the problem which a rolling release is trying to solve. The example is Ubuntu bu you could apply the same to Fedora/RHEL. My coworker wants to use Ubuntu LTS for development on Heroku. He wants the stability of an LTS, but he needs a later version of Ruby to run the Heroku tools. He has found that there is not supported way to upgrade Ruby short of recompiling Ruby or upgrading his entire system. Because of this he has returned to developing on OS X which handles the Ruby upgrade. ...snip... This is the age old LTS 'use case'. I want: * A super stable platform. * Backporting security fixes only and tons of testing and care. * Minimal updates, only the backported security fixes after massive testing. oh, and: * The very latest git head of php, python, ruby, or some other very very specific component. The problem here is that these are opposite goals. And they are also exclusive... ie, I might want the very latest php and nothing else, but $otheruser may want stable php but the latest ruby. It's hard to win here. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On Thu, Jan 26, 2012 at 12:49 PM, Frank Murphy frankl...@gmail.com wrote: On 26/01/12 17:43, Mark Bidewell wrote: Since he was using Ubuntu I will say distro-supported, but if he was using Fedora it would be Fedora supported. Ruby does not maintain distro specific packages. Ubuntu has PPAs but these are somewhat spotty for some software. Sorry, I meant if he wasn't worried about Fedora supporting his Ruby. He could have used rvm to keep updated. ditto Ubuntu. -- Regards, Frank Murphy, friend of fedoraproject UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I will look at rvm. thanks -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On Thu, Jan 26, 2012 at 12:51 PM, Kevin Fenzi ke...@scrye.com wrote: On Thu, 26 Jan 2012 12:15:01 -0500 Mark Bidewell mbide...@gmail.com wrote: I just had a conversation which I believe sheds some light on the problem which a rolling release is trying to solve. The example is Ubuntu bu you could apply the same to Fedora/RHEL. My coworker wants to use Ubuntu LTS for development on Heroku. He wants the stability of an LTS, but he needs a later version of Ruby to run the Heroku tools. He has found that there is not supported way to upgrade Ruby short of recompiling Ruby or upgrading his entire system. Because of this he has returned to developing on OS X which handles the Ruby upgrade. ...snip... This is the age old LTS 'use case'. I want: * A super stable platform. * Backporting security fixes only and tons of testing and care. * Minimal updates, only the backported security fixes after massive testing. oh, and: * The very latest git head of php, python, ruby, or some other very very specific component. The problem here is that these are opposite goals. And they are also exclusive... ie, I might want the very latest php and nothing else, but $otheruser may want stable php but the latest ruby. It's hard to win here. ;) kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I understand the difficulty, but facilitating some degree of flexibility would be a big usability improvement. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On Thu, Jan 26, 2012 at 6:15 PM, Mark Bidewell mbide...@gmail.com wrote: I just had a conversation which I believe sheds some light on the problem which a rolling release is trying to solve. You didn't state how a rolling release would solve that (it wouldn't). This is really a package management issue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On Thu, Jan 26, 2012 at 1:12 PM, drago01 drag...@gmail.com wrote: On Thu, Jan 26, 2012 at 6:15 PM, Mark Bidewell mbide...@gmail.com wrote: I just had a conversation which I believe sheds some light on the problem which a rolling release is trying to solve. You didn't state how a rolling release would solve that (it wouldn't). This is really a package management issue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel A rolling or semi-rolling release would make the most recent packages available in some way. With careful updating a minimum Ruby upgrade could be accomplished. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On 01/26/2012 11:47 PM, Mark Bidewell wrote: A rolling or semi-rolling release would make the most recent packages available in some way. With careful updating a minimum Ruby upgrade could be accomplished. A rolling release addresses the dependencies problem by updating everything including the base. This isn't what you want. When you have interdependencies, you can untangle it by copying code, bundling libraries or parallelize everything so that you can install multiple versions together. There aren't any easy answers here. This is why it remains unsolved for the most part. A rolling release doesn't solve your problem at all. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, Jan 26, 2012 at 8:21 AM, Lars Seipel lars.sei...@googlemail.com wrote: The last I heard from the Arch packaging efforts was that Unity won't be an officially supported package until it no longer depends on non-upstream patches to GTK+ and friends. The same seems to be true for OpenSuse: Since we're replacing some of the core components of openSUSE (ex: GTK+, gnome-session) the priority is important. (pasted from your link) I don't think I'm going out on a limb if I say that this doesn't look like Unity will hit Fedora repos anytime soon. You may look at repos.fedorapeople.org, though. required patches to gtk and core gnome components that are not acceptable to upstream are basically a non-starter. It maybe possible to get some variant of Unity packaged and operational without those patches. But such a version might suffer some operational loss compare to the one offered by Ubuntu. I'm not sure its in anyone's best interest for us to offer a version we know is crippled just to say we were offering it at all. I don't think that's fair to users nor to the developers. And I'm not particularly thrilled when I see other distributors making the choice to ship crippled variants of competitor's offerings, so I wouldn't want Fedora to do it. The reality is, Unity and its Canonical developed dependency stack is not designed our constructed as a distribution neutral offering. Canonical has made some choices in how these bits of code are developed that assume tight integration with the Ubuntu distribution specifically, making it difficult for any other traditional distributor to include it as an offering without make some sort of special exception in some regard. It's not even in Debian yet in any capacity and that should speak volumes right there. If Unity was constructed as a neutral upstream project, it should be very easy for Debian to scoop it up and make small changes to the existing packaging and rebuild it..as a reversal of the more common approach on how Ubuntu merges from Debian. But it hasn't happened, and its not clear when it will happen. I would find it deeply amusing and highly ironic if Fedora or OpenSuse got officially maintained packages up and running in official repos ahead of Debian. That being said, I'll cheerfully review any new packages needed to get Unity packages into Fedora. Just ping me. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Unable to delete pkg 'blktool'?
I am trying to retire package blktool. This is what dead.package says locally: Tool never really caught on with users, or kept up with the times. It is retired in the package database, but when trying to fedpkg push following fedpkg retire, I get the following error: [jgarzik@bd blktool]$ fedpkg push Counting objects: 4, done. Delta compression using up to 8 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 358 bytes, done. Total 3 (delta 0), reused 0 (delta 0) remote: W refs/heads/master blktool jgarzik DENIED by fallthru remote: error: hook declined to update refs/heads/master To ssh://jgar...@pkgs.fedoraproject.org/blktool ! [remote rejected] master - master (hook declined) error: failed to push some refs to 'ssh://jgar...@pkgs.fedoraproject.org/blktool' Could not execute push: Command '['git', 'push']' returned non-zero exit status 1 Not sure what DENIED by fallthru means. Anybody able to shed some light? Thanks, Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2012-01-27 @ 17:00 UTC - F17 Alpha Blocker Bug Review #1
# F17 Alpha Blocker Review meeting #1 # Date: 2012-01-27 # Time: 17:00 UTC [1] (13:00 EDT, 09:00 PDT) # Location: #fedora-bugzappers on irc.freenode.net We're approaching the F17 alpha release and it's time for the first F17 blocker review meeting! I'm sure everyone's excited to get these meetings started up again; I know that I am. The first F17 alpha blocker bug review meeting will be this Friday at 17:00 UTC in #fedora-bugzappers. We'll be running through the final blockers and nice-to-haves. An updated list of blocker bugs is available at https://fedoraproject.org/wiki/Current_Release_Blockers. We'll be reviewing the bugs to determine ... 1. Whether they meet the final release criteria [2] and should stay on the list 2. Whether they are getting the attention they need For guidance on Blocker and Nice-to-have (NTH) bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_process For the blocker review meeting protocol, see https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting . Tim signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unable to delete pkg 'blktool'?
On Thu, Jan 26, 2012 at 11:30 AM, Jeff Garzik jgar...@pobox.com wrote: I am trying to retire package blktool. This is what dead.package says locally: Tool never really caught on with users, or kept up with the times. It is retired in the package database, but when trying to fedpkg push following fedpkg retire, I get the following error: [jgarzik@bd blktool]$ fedpkg push Counting objects: 4, done. Delta compression using up to 8 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 358 bytes, done. Total 3 (delta 0), reused 0 (delta 0) remote: W refs/heads/master blktool jgarzik DENIED by fallthru remote: error: hook declined to update refs/heads/master To ssh://jgar...@pkgs.fedoraproject.org/blktool ! [remote rejected] master - master (hook declined) error: failed to push some refs to 'ssh://jgar...@pkgs.fedoraproject.org/blktool' Could not execute push: Command '['git', 'push']' returned non-zero exit status 1 Not sure what DENIED by fallthru means. Anybody able to shed some light? I don't know, but devel shows retired in pkgdb. -J Thanks, Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The question of rolling release?
On 01/26/2012 06:51 PM, Kevin Fenzi wrote: On Thu, 26 Jan 2012 12:15:01 -0500 Mark Bidewellmbide...@gmail.com wrote: I just had a conversation which I believe sheds some light on the problem which a rolling release is trying to solve. The example is Ubuntu bu you could apply the same to Fedora/RHEL. My coworker wants to use Ubuntu LTS for development on Heroku. He wants the stability of an LTS, but he needs a later version of Ruby to run the Heroku tools. He has found that there is not supported way to upgrade Ruby short of recompiling Ruby or upgrading his entire system. Because of this he has returned to developing on OS X which handles the Ruby upgrade. ...snip... This is the age old LTS 'use case'. I want: * A super stable platform. * Backporting security fixes only and tons of testing and care. * Minimal updates, only the backported security fixes after massive testing. oh, and: * The very latest git head of php, python, ruby, or some other very very specific component. The problem here is that these are opposite goals. And they are also exclusive... ie, I might want the very latest php and nothing else, but $otheruser may want stable php but the latest ruby. It's hard to win here. ;) This solution to such use-cases actually is quite simple: Use one of these stable/LTS/stagnating distros as basis and build those packages you have special needs for yourself. If you want to do this cleanly, start packaging these packages as rpms (rsp. debs in Ubuntu). In some cases you may as well find some 3rd party repos, which already does this. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[ACTION REQUIRED v3] Retiring packages for F-17
Each release, before branching, we block currently orphaned packages. It's that time again for Fedora 17. New this go-round is that we are also blocking packages that have failed to build since before Fedora 15. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. Due to the orphaning of packages due to inactive maintainers, this list is a little longer than normal. If these packages are not claimed, they will be retired shortly before the mass branch for Fedora 17 on February 7th. Orphan adaptx Orphan ario Orphan asa comaintained by: pertusus Orphan autodafe Orphan avant-window-navigator comaintained by: ngompa Orphan avl Orphan awn-extras-applets Orphan bit Orphan blam comaintained by: alexlan Orphan blt Orphan bmake Orphan bwidget Orphan byaccj comaintained by: dbhole Orphan camstream Orphan castor Orphan ccsm Orphan compiz Orphan compiz-bcop Orphan compiz-fusion-extras Orphan compiz-fusion-unsupported Orphan compiz-manager Orphan compizconfig-backend-gconf Orphan compizconfig-backend-kconfig4 Orphan compizconfig-python Orphan concurrent Orphan conexus Orphan dbus-cxx Orphan eazykeyboard Orphan eclipse-setools Orphan eclipse-slide Orphan eclipse-systemtapgui Orphan eg Orphan erlang-erlzmq2 Orphan expatmm Orphan freehdl comaintained by: chitlesh Orphan gestikk Orphan gget Orphan gimpfx-foundry Orphan gkrellm-volume Orphan gmime22 Orphan gnome-paint Orphan gnubversion Orphan gpx-viewer Orphan higlayout Orphan intellij-idea Orphan intuitively comaintained by: pertusus Orphan invulgotracker Orphan itaka Orphan itcl Orphan itk Orphan itools Orphan iwak Orphan iwidgets Orphan jps Orphan kcirbshooter Orphan libcompizconfig Orphan libdesktop-agnostic Orphan libmetalink Orphan libmodelfile Orphan libnoise Orphan libspe2 Orphan libsx comaintained by: pertusus Orphan libyahoo2 comaintained by: siddhesh Orphan lifeograph comaintained by: sundaram Orphan log4c Orphan lush Orphan maradns Orphan mathmap Orphan maxr comaintained by: cassmodiah Orphan mediawiki-rss comaintained by: ianweller Orphan memchan Orphan metalink Orphan mingw32-OpenSceneGraph Orphan mingw32-SDL_image Orphan mingw32-SDL_mixer Orphan mingw32-plib Orphan mod_perlite Orphan monsoon Orphan mtkbabel Orphan mulk Orphan nanoxml Orphan netbeans Orphan netstiff Orphan openbios Orphan papyrus Orphan perl-Archive-RPM comaintained by: ppisar psabata mmaslano Orphan perl-B-Hooks-OP-Check-StashChange comaintained by: ppisar psabata mmaslano Orphan perl-CPAN-Mini comaintained by: ppisar psabata mmaslano Orphan perl-CPANPLUS-Shell-Default-Plugins-Changes comaintained by: ppisar psabata mmaslano Orphan perl-CPANPLUS-Shell-Default-Plugins-Diff comaintained by: ppisar psabata mmaslano Orphan perl-CPANPLUS-Shell-Default-Plugins-RT comaintained by: ppisar psabata mmaslano Orphan perl-Check-ISA comaintained by: ppisar psabata mmaslano Orphan perl-Class-Can Orphan perl-Class-Data-Accessor comaintained by: ppisar psabata mmaslano Orphan perl-Class-Exporter Orphan perl-Convert-NLS_DATE_FORMAT comaintained by: ppisar psabata mmaslano Orphan perl-DBD-Multi comaintained by: ppisar psabata mmaslano Orphan perl-DBI-Dumper comaintained by: ppisar psabata mmaslano Orphan perl-DBIx-POS comaintained by: ppisar psabata mmaslano Orphan perl-Data-TreeDumper comaintained by: psabata ppisar mmaslano Orphan perl-Data-TreeDumper-Renderer-GTK comaintained by: psabata ppisar mmaslano Orphan perl-DateTime-Format-DB2 comaintained by: ppisar psabata mmaslano Orphan perl-DateTime-Format-DBI comaintained by: ppisar psabata mmaslano Orphan perl-DateTime-Format-Excel comaintained by: ppisar psabata mmaslano Orphan perl-DateTime-Format-Oracle comaintained by: ppisar psabata mmaslano Orphan perl-Directory-Scratch-Structured comaintained by: psabata ppisar mmaslano Orphan perl-Eval-Context comaintained by: ppisar psabata mmaslano Orphan perl-File-ExtAttr comaintained by: ppisar psabata mmaslano Orphan perl-Gnome2 comaintained by: ppisar psabata mmaslano Orphan perl-Gnome2-GConf comaintained by: ppisar psabata mmaslano Orphan perl-Gnome2-VFS comaintained by: ppisar psabata mmaslano Orphan perl-Gtk2-Ex-CalendarButton comaintained by: ppisar psabata mmaslano Orphan perl-Gtk2-Ex-Carp comaintained by: ppisar psabata mmaslano Orphan perl-Gtk2-Ex-Dialogs comaintained by: ppisar psabata mmaslano Orphan perl-Gtk2-Ex-Utils comaintained by: ppisar psabata mmaslano Orphan perl-Gtk2-Spell comaintained by: ppisar psabata mmaslano Orphan perl-KinoSearch Orphan perl-LWP-Authen-Wsse comaintained by: ppisar psabata mmaslano Orphan perl-Module-Depends Orphan perl-Module-Install-ExtraTests comaintained
Re: [ACTION REQUIRED v3] Retiring packages for F-17
Took libmodelfile and sage. -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] 2012-01-27 @ 17:00 UTC - F17 Alpha Blocker Bug Review #1
On Thu, 26 Jan 2012 12:22:58 -0700 Tim Flink tfl...@redhat.com wrote: # F17 Alpha Blocker Review meeting #1 # Date: 2012-01-27 # Time: 17:00 UTC [1] (13:00 EDT, 09:00 PDT) # Location: #fedora-bugzappers on irc.freenode.net Correction on the time: 17:00 UTC, 12:00 EST, 09:00 PST Sorry for the extra mail, Tim signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc 4.7 changes binary behaviors ?
On Thu, Jan 26, 2012 at 07:12:43AM +, Sérgio Basto wrote: Hi, hope that also could help Has package builder we also build kBuid http://koji.fedoraproject.org/koji/packageinfo?packageID=7356 , after use kBuid compile with gcc 4.7 I got this error on building virtuaBox /usr/bin/kmk_sed: file /builddir/build/BUILD/VirtualBox-4.1.8_OSE/src/VBox/Runtime/common/err/errmsg.sed line 31: Unmatched [ or [^ kmk: *** [/builddir/build/BUILD/VirtualBox-4.1.8_OSE/obj/obj/Runtime/errmsgdata.h] Error 1 kmk: *** Deleting file `/builddir/build/BUILD/VirtualBox-4.1.8_OSE/obj/obj/Runtime/errmsgdata.h' kmk: *** Waiting for unfinished jobs build virtualbox with same kBuild but that was build with gcc 4.6 I don't have this problem using kBuild-0.1.98-1.r1.fc17 works, using kBuild-0.1.98-2.r1.fc17 I got this error, with kmk_sed. Any clue is appreciated That just clearly shows how bundling libraries (violation of Fedora packaging guidelines) is harmful. Apparently, kBuild/src/sed/lib contains a copy of sed? regex code which is a copy of the glibc code (but I hope sed is configured to use the system regex), so it hits the same problem as has been already fixed in glibc: http://sources.redhat.com/ml/libc-alpha/2011-12/msg00091.html Please file bugs against kBuild and possibly against sed too. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[kde, lxde, xfce] Removing ModemManager dep from NM, adding to comps instead
Hi, It was recently brought to my attention that NM has an RPM dep on ModemManager. I believe we added it long ago to ensure that users did not lose 3G modem support when updating from NM 0.7.x (where NM had internal 3G support) to 0.8.x (where that support was split out into MM). These days there no hard dependency between NM - MM, only a D-Bus API, and NetworkManager runs fine when MM is not installed (thought it looses 3G support of course). People who don't have 3G modems and know they wont in the future have no need of installing or running MM. Thus I'd like to remove the RPM dep from NetworkManager, and instead add ModemManager to the default comps installs of all the major desktop environments instead. Thus base system installs won't include ModemManager, but desktop installs would. Most 3G users are likely desktop users as well. Thoughts? If there aren't any objections from the KDE, LXDE, or XFCE folks I'll update comps as I describe here. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v3] Retiring packages for F-17
On Thu, Jan 26, 2012 at 14:58:59 -0500, Bill Nottingham nott...@redhat.com wrote: If these packages are not claimed, they will be retired shortly before the mass branch for Fedora 17 on February 7th. Orphan xmms-pulse Since I actually use xmms, I'm taking xmms-pulse. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Odd build failures in Koji
On Thu, Jan 26, 2012 at 2:59 PM, Jon Ciesla limburg...@gmail.com wrote: I've been updating ettercap, and I got a build working on my local f16. Then I built it in local rawhide mock, and it was fine. So I committed and built for rawhide, f16, and f15. Sometimes it worked, and sometimes it didn't, failing with an error I'd not seen before. This f15 build.log is typical: http://koji.fedoraproject.org/koji/getfile?taskID=3738127name=build.log Could there be a problem on some builders and not others? If a build fails, and I retry after changing nothing, it should still fail. And now it worked. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Odd build failures in Koji
On Thu, Jan 26, 2012 at 2:59 PM, Jon Ciesla limburg...@gmail.com wrote:
I've been updating ettercap, and I got a build working on my local
f16. Then I built it in local rawhide mock, and it was fine. So I
committed and built for rawhide, f16, and f15. Sometimes it worked,
and sometimes it didn't, failing with an error I'd not seen before.
This f15 build.log is typical:
http://koji.fedoraproject.org/koji/getfile?taskID=3738127name=build.log
Could there be a problem on some builders and not others? If a build
fails, and I retry after changing nothing, it should still fail.
Looking at the first error I could find:
make[2]: *** No rule to make target `ef_grammar.h', needed by `all-am'. Stop.
make[2]: *** Waiting for unfinished jobs
Perhaps it's a parallel make issue? Although unless ef_grammer.h is
generated I would think it would always find it.
See if you can repeatably get it to build (probably using scratch
builds?) after removing %{?_smp_mflags} from %build.
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Odd build failures in Koji
On Thu, Jan 26, 2012 at 3:07 PM, Richard Shaw hobbes1...@gmail.com wrote:
On Thu, Jan 26, 2012 at 2:59 PM, Jon Ciesla limburg...@gmail.com wrote:
I've been updating ettercap, and I got a build working on my local
f16. Then I built it in local rawhide mock, and it was fine. So I
committed and built for rawhide, f16, and f15. Sometimes it worked,
and sometimes it didn't, failing with an error I'd not seen before.
This f15 build.log is typical:
http://koji.fedoraproject.org/koji/getfile?taskID=3738127name=build.log
Could there be a problem on some builders and not others? If a build
fails, and I retry after changing nothing, it should still fail.
Looking at the first error I could find:
make[2]: *** No rule to make target `ef_grammar.h', needed by `all-am'. Stop.
make[2]: *** Waiting for unfinished jobs
Perhaps it's a parallel make issue? Although unless ef_grammer.h is
generated I would think it would always find it.
See if you can repeatably get it to build (probably using scratch
builds?) after removing %{?_smp_mflags} from %build.
It could be. I removed it in one part, but not another. I'll see.
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: Rebuild for Ruby 1.9.3
On 01/25/2012 02:10 PM, Vít Ondruch wrote: 1) Always use Bundler provided by Fedora which will works as it should. 2) Force Ruby and RubyGems upstream to properly support FHS. I already provided patches [1] but I need your support. 3) Revert the customized behavior of RubyGems and break FHS. 4) Treat root as regular user and install gem also into root's home directory, but it obviously doesn't make sense. FHS is broken by upstream. Fedora ideally should be doing 2) and work with upstream instead of patching the changes downstream which tends to cause problems like the current situation. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unity For Fedora (As in OpenSUSE or Arch)
On Thu, 2012-01-26 at 10:15 -0900, Jef Spaleta wrote: required patches to gtk and core gnome components that are not acceptable to upstream are basically a non-starter. It maybe possible to get some variant of Unity packaged and operational without those patches. But such a version might suffer some operational loss compare to the one offered by Ubuntu. I'm not sure its in anyone's best interest for us to offer a version we know is crippled just to say we were offering it at all. I don't think that's fair to users nor to the developers. And I'm not particularly thrilled when I see other distributors making the choice to ship crippled variants of competitor's offerings, so I wouldn't want Fedora to do it. The app menu work that has recently landed in GTK+ is partially an effort to get some of these patches upstream. Hopefully, unity will be ported to use the upstreamed API at some point. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unable to delete pkg 'blktool'?
On Thu, Jan 26, 2012 at 01:26:10PM -0600, Jon Ciesla wrote: On Thu, Jan 26, 2012 at 11:30 AM, Jeff Garzik jgar...@pobox.com wrote: I am trying to retire package blktool. This is what dead.package says locally: Tool never really caught on with users, or kept up with the times. It is retired in the package database, but when trying to fedpkg push following fedpkg retire, I get the following error: [jgarzik@bd blktool]$ fedpkg push Counting objects: 4, done. Delta compression using up to 8 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 358 bytes, done. Total 3 (delta 0), reused 0 (delta 0) remote: W refs/heads/master blktool jgarzik DENIED by fallthru remote: error: hook declined to update refs/heads/master To ssh://jgar...@pkgs.fedoraproject.org/blktool ! [remote rejected] master - master (hook declined) error: failed to push some refs to 'ssh://jgar...@pkgs.fedoraproject.org/blktool' Could not execute push: Command '['git', 'push']' returned non-zero exit status 1 Not sure what DENIED by fallthru means. Anybody able to shed some light? I don't know, but devel shows retired in pkgdb. I can't be sure but what might be happening is that the deprecation in the pkgdb was mirrored out to the acls in the git server before you were able to push your dead.package there. Since you're not in provenpackager and the deprecation sets orphan as the owner, you don't have permission to push to that branch anymore. For now, I've committed and push a similar change for you so the package is properly retired in git. dgilmore has expressed interest in getting the whole retired package process into a fedpkg command. At FUDCon we worked out the steps that fedpkg would need to do and it seems like there's nothing stopping it, there just needs to be some time to make it happen. -Toshio pgpHFeCNb8BSG.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: Ticket #161 - Review and address latest Coverity issues
https://fedorahosted.org/389/ticket/161 ds patches - https://fedorahosted.org/389/attachment/ticket/161/0001-Ticket-161-Review-and-address-latest-Coverity-issues.patch admin server - https://fedorahosted.org/389/attachment/ticket/161/0001-Ticket-161-Review-and-address-latest-Coverity-issues.2.patch adminutil - https://fedorahosted.org/389/attachment/ticket/161/0001-Ticket-161-Review-and-address-latest-Coverity-issues.3.patch -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: gcc 4.7 changes binary behaviors ?
On Thu, 2012-01-26 at 21:15 +0100, Jakub Jelinek wrote: On Thu, Jan 26, 2012 at 07:12:43AM +, Sérgio Basto wrote: Hi, hope that also could help Has package builder we also build kBuid http://koji.fedoraproject.org/koji/packageinfo?packageID=7356 , after use kBuid compile with gcc 4.7 I got this error on building virtuaBox /usr/bin/kmk_sed: file /builddir/build/BUILD/VirtualBox-4.1.8_OSE/src/VBox/Runtime/common/err/errmsg.sed line 31: Unmatched [ or [^ kmk: *** [/builddir/build/BUILD/VirtualBox-4.1.8_OSE/obj/obj/Runtime/errmsgdata.h] Error 1 kmk: *** Deleting file `/builddir/build/BUILD/VirtualBox-4.1.8_OSE/obj/obj/Runtime/errmsgdata.h' kmk: *** Waiting for unfinished jobs build virtualbox with same kBuild but that was build with gcc 4.6 I don't have this problem using kBuild-0.1.98-1.r1.fc17 works, using kBuild-0.1.98-2.r1.fc17 I got this error, with kmk_sed. Any clue is appreciated That just clearly shows how bundling libraries (violation of Fedora packaging guidelines) is harmful. I'd rather build virtualbox with binaries of kmk_sed provide by virtualbox, than put this kBuild package on fedora and build it from sources. Is just a waste of time. but yeah, not my fault, but diff /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/kBuild-0.1.9998/src/sed and ~/rpmbuild/SOURCES/sed-4.2.1 have 147 identical files NEWS says that is Sed 4.1.5 Thanks for the tip , I will see what I can do about not bundle sed . Apparently, kBuild/src/sed/lib contains a copy of sed? regex code which is a copy of the glibc code (but I hope sed is configured to use the system regex), so it hits the same problem as has been already fixed in glibc: http://sources.redhat.com/ml/libc-alpha/2011-12/msg00091.html Please file bugs against kBuild and possibly against sed too. Jakub -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MATE desktop environment (GNOME 2 fork)
On Fri, Dec 09, 2011 at 01:24:08PM +0100, Dennis Jacobfeuerborn wrote: On 12/09/2011 12:50 PM, Jóhann B. Guðmundsson wrote: On 12/09/2011 03:50 AM, Eric Smith wrote: I've submitted review requests for the first two packages for the MATE desktop environment, mate-doc-utils and mate-corba. MATE is a fork of GNOME 2. I expect that it will take me a few months to package the remaining MATE packages. Would anyone like to see the MATE desktop environment as an official feature of Fedora 17 or Fedora 18? https://bugzilla.redhat.com/show_bug.cgi?id=765666 https://bugzilla.redhat.com/show_bug.cgi?id=765667 Is it not better to just create extension and an theme on spin with gnome3 that bring back the functionality you seek? That's pretty much was Mint seems to be doing and I agree that this is probably a much more viable approach: http://desktoplinuxreviews.com/2011/11/30/linux-mint-12/ [Reviving an old thread ...] Indeed this seems to be not just vapourware: http://cinnamon.linuxmint.com/?p=119 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v3] Retiring packages for F-17
On Thu, Jan 26, 2012 at 02:58:59PM -0500, Bill Nottingham wrote: Orphan techtalk-pse I have taken this. Currently it FTBFS because a critical dependency was dropped from Fedora, however I have patches upstream (not applied to git yet) which fix this. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [kde, lxde, xfce] Removing ModemManager dep from NM, adding to comps instead
Dan Williams wrote: People who don't have 3G modems and know they wont in the future have no need of installing or running MM. Thus I'd like to remove the RPM dep from NetworkManager, and instead add ModemManager to the default comps installs of all the major desktop environments instead. Thus base system installs won't include ModemManager, but desktop installs would. Most 3G users are likely desktop users as well. Why not add this to some desktop-independent comps group instead, e.g. base, dial-up or hardware-support? I think the desktop groups are not the right place to put this, it has nothing to do with desktops. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [kde, lxde, xfce] Removing ModemManager dep from NM, adding to comps instead
Am Donnerstag, den 26.01.2012, 14:54 -0600 schrieb Dan Williams: People who don't have 3G modems and know they wont in the future have no need of installing or running MM. Thus I'd like to remove the RPM dep from NetworkManager, and instead add ModemManager to the default comps installs of all the major desktop environments instead. Thus base system installs won't include ModemManager, but desktop installs would. Most 3G users are likely desktop users as well. Thoughts? If there aren't any objections from the KDE, LXDE, or XFCE folks I'll update comps as I describe here. Is it - it least in theory - possible to configure 3G with NetworkManager but without a UI? In this case it should be moved to base, dial-up or hardware-support. If not, adding it to the *-desktop groups is fine with me. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking yum upgrade upgrades from older releases to F17?
Toshio Kuratomi wrote: As you've been pointing out, this is a recipe for alpha slippage (and since recently we've been slipping all later milestones, a slip in alpha means a slip to the release) but I don't think the feature owners are technically doing anything wrong under the current policy :-( This is not the first time a feature which impacts the entire distribution in a way which can break a lot of things gets rushed in so late. I remember the ld DSO feature which changed decades-old ELF semantics, breaking the build of dozens of packages, and which got rushed into F13 the day of the feature freeze (!), with neither the feature owners nor FESCo wanting to postpone it to F14 even though there was no reason at all why that change couldn't have waited for a release (especially considering that the F14 Rawhide was about to open, which would have been the perfect point in the schedule to land such a change). I don't understand the rush for UsrMove either. We really need to require such deep-impacting changes to land much earlier in the cycle (if we allow them at all), while being more flexible for features in leaf packages. Having a single feature freeze day for everything just doesn't work. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
