Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 02/05/2013 08:09 AM, Jef Spaleta wrote: On Mon, Feb 4, 2013 at 9:55 PM, Ralf Corsepius rc040...@freenet.de wrote: I disagree. Fedora's lack of popularity is largely thanks to these issues. In this context, I feel the Cinnamon request rsp. the give users a choice on DEs attempts are part of an attempt to escape the at least one of the dead-end roads Fedora currently is stuck in (The Gnome3 dead-end). I disagree. I do not think the existence of Cinnamon as yet another environment does anything to address any of the things you previously listed: Freaks'/nerds' distro, Ubuntu is much easier, Fedora lacks s much, Way too unstable, Way too short life-cycles. I view your inclusion of your list as a general angst filled pile-on, and not constructive for the feature proposal discussion. Absolutely no. My points are: * The Gnome3-suite will never fit everybody, i.e. trying to push/force it onto all users will never work and is not helpful to the Fedora community. * Gnome3 is (ab-) using Fedora as Gnome3 test-bed. This already has caused a considerable damage to Fedora (and RH). -jefthe real solution to all these problems is openCDE, which I look forward to proposing as default in the F20 cyclespaleta Yes, though you might have ment this as joke. I am sure there are people, who would support such and endeavor ;) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 02/05/2013 08:45 AM, drago01 wrote: On Tue, Feb 5, 2013 at 7:55 AM, Ralf Corsepius rc040...@freenet.de wrote: On 02/05/2013 07:42 AM, Adam Williamson wrote: On Tue, 2013-02-05 at 07:19 +0100, Ralf Corsepius wrote: On 02/05/2013 05:51 AM, Adam Williamson wrote: On Tue, 2013-02-05 at 02:59 +0100, Kevin Kofler wrote: , but since you started it: OpenSUSE is doing just fine doing exactly what I suggest (making people actually pick their download). Their download button actually points to a selector, not directly to an ISO. That would be the SUSE that along with Mandriva got completely panned when Ubuntu showed up, then? Is the situation Fedora is in essentially better? I feel no. Reality is, when mentioning Fedora to Linux users, I am having difficulties to not get laughed at. Freaks'/nerds' distro, Ubuntu is much easier, Fedora lacks s much, Way too unstable, Way too short life-cycles are the usual answers. Let's not go down that path. It's far off topic. I disagree. Fedora's lack of popularity is largely thanks to these issues. No the desktop choice isn't the issue (it wasn't any more popular in the GNOME2 days). In the Gnome2 days you had choices between functionally similar DEs. Times have changed ... Gnome has been forked multiply (Gnome3, MATE, Cinammon), xfce/enlightenment are back. Why? IMO, due to user dissatisfaction with what primarily Fedora and Ubuntu ship as default DEs, rsp. because Gnome has dropped their former userbase. For the advanced users the desktop choice matters even less because they know how to chose a desktop. To advanced users anaconda enforcing GNOME is defect ;) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/02/13 11:45, drago01 wrote: For the new users: There is no easy way to install applications (regular user don't want to mess up with packages). We do not ship stuff that some user want to use (by design or for legal reasons). For the advanced users the desktop choice matters even less because they know how to chose a desktop. That is very true. In my opinion there's no reason to change default or omit this concept. Fedora is _not_ distro for linux newcomers. If one wants to make fedora more friendly to newbie users, one should make it way more stable(It not fedora way), start to ship non-free media codecs(same here) and so on. That's why I think that all cinnamon is friendly to newcomers reasons are not true for fedora, because fedora itself not friendly to newcomers. And advanced user(as drago01 says) usually knows what he wants, and he able to click on more download options link. - -- Grigory excuse my poor english -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJREMCuAAoJEB2Utztg3NGsFRwP/jiz2pD6eC6HntWylaaN3ZEB x9sfujHsNSGJfmY89DK7VF2Y/PpFxbkEURYjdiKyvwIaSDhxUhIiNwXrZCUntQYF V6XfQzjnpX7KWAk1uvgxNKvBOlx2NizuV2Fng3y15Zq5ps0qQ4Dx8fluV4XqSAz6 7qSGfK6BIdG+Rq9iI8p12fJDaMbZKduitJIqUV/heAdYMJV5kAFQkuF4eMlJF2Sb 2xwL8BHNvtH0xsvqjM9mes9qqLtVNTaaxWrwsZt4Kp9TGgNN3oineNa3g0drEeJb XHpk0q6yXCqr7s6C+KyLIeB0fUKaE9o0xwYLDVGKXnU2BV7AtuzYxnzb9jeY30PZ oAHVRANaX+bPKw4UApFhLDiIsmULo7vBUlooRCdR1NM3VRrj7XAMzgfvt/7ss/ma rPYldejcHav7/ohAAusKcS2+0ESsoeQqCDTZpSZH4au2trAqFUkzeRfL9nmgO2LM WbNrNgFgCr0Gjr96Q0oVBm+nv5HODYdvqwkoQ1Qqs17VGFwStmkiPal5tuXXn5vH EWqfljO20pu0AgO4zwD5UDkWYBBjXF9N17M2rZabZBU6mDUgl7hl13DgUKTo86XQ jvfBX1hscAB9qeZcAmy9aM4kdmo+yIaYC3ltcg95l1Kh0aMq/BKYY+B0O1ZuQgUx cst88y+pfva8uzoTPhvY =zvJZ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Mon, Feb 4, 2013 at 11:02 PM, Ralf Corsepius rc040...@freenet.de wrote: Absolutely no. My points are: * The Gnome3-suite will never fit everybody, i.e. trying to push/force it onto all users will never work and is not helpful to the Fedora community. * Gnome3 is (ab-) using Fedora as Gnome3 test-bed. This already has caused a considerable damage to Fedora (and RH). These are different points than the you previously listed. I fear you are severely conflating issues. You feel gnome3 doesn't fit everybody... i doubt anyone is going to argue against that point. But that has nothing to do with instability or fast release cycles or not having enough stuff in the distro. -jefthe real solution to all these problems is openCDE, which I look forward to proposing as default in the F20 cyclespaleta Yes, though you might have ment this as joke. I am sure there are people, who would support such and endeavor ;) My proposal is as funny as turning to Cinnamon as the default environment. I leave it up to the reader to decide if either was intended in a joking manner. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Actually, the feedback I got at FOSDEM was to focus on packaging trunk for the time being. But indeed, the biggest effort is on packaging in a way that it is satisfactory for everybody, and for this first step it doesn't really make a technical difference whether we use 3.4.1, a recent 4.0 milestone or 4.0, since the major infrastructural changes were already done in OpenOffice 3.4.0 and newer versions do not introduce new dependencies (although trunk uses an updated product name, that could help in solving some conflicts). In Fedora, even installing OpenOffice manually (i.e., by downloading RPMs from the OpenOffice website) is problematic since: 1) it won't install cleanly due to the conflicting soffice alias 2) even if you force installation, yum update can wipe out OpenOffice since one of the LibreOffice RPMs obsoletes the OpenOffice RPMs. It is surely possible to do better, and to do so in a way that leaves the user experience for LibreOffice end-users unchanged. This is what I see as a first step. Note that I haven't had time to check with F18 yet, so I welcome feedback on this if someone can test before I do. Let's take a look at a similar (although of course not identical) situation with respect to a package that is very similar to another - indeed will conflict on certain files even - and the process/time that took to get packaged... https://bugzilla.redhat.com/show_bug.cgi?id=875150 This the the MariaDB packaging review request. The RPMs already existed upstream so it theoretically should have been a pretty simple cleanup in line with Fedora Pacakaging Guidelines. It took from 9/11/12 to 10/1/13 to get that from the initial big to approved... The only existing codebase form which to discuss this and test a *working* office suite packaged by RPM is 3.4.1 ... Right now there's no roadmap for 4.0 - no milestone dates, alpha dates or beta dates... The best that exists for this is a nightly snapshot from trunk covered in caveats about how unstable it's likely to be. The openoffice.org wiki doesn't even mention 3.4 much less future plans for 4.0 on it's features page! http://wiki.openoffice.org/wiki/Features Could you have a chat with Rob Weir to clarify IBM's timeline for the 4.0 package and provide some hard milestone dates rather than the current vague April 2013 ? Annoyingly the AOO thread has split in my email client by I agree the discussion about the IBM Symphony dump ( licensing concerns as out of scope given that won't be packaged and all code will be review for license whilst being merged to AOO however this inject of proprietary code as opposed to the open tested code of 3.4.1 on a tight timeline is I would submit a concern as to the likelihood of bugs and slippage from the current vague date. Out of curiosity I just downloaded the tarball (of x86_64 RPMs) on the oo.org website to see how they would behave whilst installing to my F18 system... Yum reported no conflicts on install - which surprised me (although I didn't install the desktop integration stuff) - and then I noticed it installed to /opt which is an immediate violation of the packaging guidelines so there's not actually a reasonably clean (like the mariaDB ones were) to start from in the first place... There's substantial risk here to the reputation of Fedora trying to squeeze this untested application into a F19 timeline when it's rushed into the distribution rather than taking a step back and working through the conflict issues (and others involved) and certainly with the 3.4.1 code no gain to Fedora users at all over the existing LibreOffice suite. Realistically this packaging discussion should have been started back last year on the 3.4.1 release or shortly thereafter - perhaps with an apache supported but unofficial yum repository until such time as the RPMs fell inline with Fedora guidelines and then the discussion could have been had well ahead of the feature deadline for a release and definitely more than 3 weeks from branch... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Am Montag, den 04.02.2013, 13:34 +0100 schrieb Michael Stahl: how exactly does LibreOffice depend on OpenOffice, and what do you mean by OpenOffice in this context? As I understood the discussion at Linux Day last year the LibreOffice rebase is not only about changing Licence headers but substantial code of the Apache OpenOffice project as well. So it is Apache Open Office LibreOffice seems to depend on (whereas depend may be bit strong given the combersome and delicate relation between the projects and I would like to withdraw this part of my post). Therefore, if the projects share a substantial code base, I'm wondering about the different direction of development and different feature set, Martin wrote about. And I would like to learn about those in greater detail. in the hope that they will stop wasting everybody's time with the current duplication of efforts and stupid politics. Yes, I would like to see all participants leaving the former conflicts invoked by Oracle politics (and to some extend by Sun as well) behind and build a constructive cooperation as hard as it may be for those who are highly engaged in the projects for years. for more info see: https://wiki.documentfoundation.org/Development/Re-Basing thanks for the link, very informative for me. Thanks Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 2013-02-05, 06:19 GMT, Ralf Corsepius wrote: Reality is, when mentioning Fedora to Linux users, I am having difficulties to not get laughed at. Freaks'/nerds' distro, Ubuntu is much easier, Fedora lacks s much, Way too unstable, Way too short life-cycles are the usual answers. Good people walk balanced step towards the goal. Others, without knowing, dance around them contemporary dances. (Franz Kafka) I wouldn't be worried that Fedora is not cool. Actually, thinking about it, that's the best part of Fedora. Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
On 2013-02-04, 19:52 GMT, Andrea Pescetti wrote: It's an outdated article and not much relevant to the current discussion (you see, it says the Symphony repository...). [...] The Symphony code is like everything else in this respect: all Symphony code that OpenOffice will choose to use will sooner or later go to trunk and into a release, receiving the same paranoid attention as the rest and a crystal clear license notice (the Apache 2 License in this case) allowing anybody to use it. And then (and only then) there will be something released from IBM to the public. Until then my comment https://lwn.net/Articles/533402/ stands and the discussion on that webpage is still pretty relevant. Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/02/13 10:19, Ralf Corsepius wrote: On 02/05/2013 05:51 AM, Adam Williamson wrote: On Tue, 2013-02-05 at 02:59 +0100, Kevin Kofler wrote: , but since you started it: OpenSUSE is doing just fine doing exactly what I suggest (making people actually pick their download). Their download button actually points to a selector, not directly to an ISO. That would be the SUSE that along with Mandriva got completely panned when Ubuntu showed up, then? Is the situation Fedora is in essentially better? I feel no. Reality is, when mentioning Fedora to Linux users, I am having difficulties to not get laughed at. Freaks'/nerds' distro, Ubuntu is much easier, Fedora lacks s much, Way too unstable, Way too short life-cycles are the usual answers. Try to look from different point of view: This is true for newcomers. Ubuntu is really easier for new users. Fedora is really unstable and lacks some software for new users. Cinnamon(or selector instead of direct link) won't fix it. To the point where they've since been sold two times and have never really recovered. Yes, primarily because they did not make enough money to satisfy their shareholders. Nevertheless, at least in Germany (SUSE had never played a major role outside of Germany), openSUSE seem to have a pretty stable and solid user base. Ralf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRENJBAAoJEB2Utztg3NGsP8AP/iqgZzDYYa9k5McLp1D03ZRT 3gLQnCtYTA6BSKu14tf/7Sgi0G7F88uYnwOATQ9xQVNwy1ha7jdylsX2cq8+9xZT eyLUgM6LIU24SLNmuhOg/UjiRLJL6Jrfic86SIsgbJpzkisqZhdIvejhh7tswFi2 7B0Xox8HZDnpy+bQDktWnpjjy65h0xxMa2PdRG5taP+JCEio39ZLn3sUgx/Njw8I R8ATXTkNxUkY4qzSoH/HbpEwIa1QZjuU9HdaMiTUQMvt5kT8w4mckdS0jK3GSbh2 fCqLeVg19BrYUDKo0mI3jKXGG42rpbiTn/d5gNMUA8JINDSq/j9tbrh/7mfNP3mA czTLr1jXQF7QKFpb2nArq+Eqc3CYQJWF4d6uVgG+A2KvmeWAHmpzGw0PEmBmX5uZ kj1TzR1HvEp4PYQTtJdJ4XouGzvoGU5Epk+meKq7x0AOsF4Ju8O6/Ce0Viexx5LW L7TVSs35TPA4TmvideMtN5PvqOgrLAcbgSCiTb8rqz3B46pJA2klSiLR8LgqExzk SmWuOou2olEWPa8n3MB5k/3LjXjRhNhIOqzGcDDXazLLdLlGa5m05np+19VaZK1Y N46UyiKdzetrXen4rEL5gihyYxMdBiHU7e4+M71lJA3TGJ03ylq1wIPr77IEM73d pdDwcFNB837DfZNPwb8p =ZfUd -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 02/05/2013 07:40 AM, Michael Scherer wrote: Le mardi 05 février 2013 à 06:43 +0100, Ralf Corsepius a écrit : I think you are putting too much emphasize on first-timers and seem to be forgetting the Linux distro switcher-users. For them, easily finding the DE they know from their so-far used distro and easily switching between alternative DEs would be an important feature. Last time I checked, people were fully able to switch DE after installation. For advanced users it's possible to switch the DE - For beginners, I feel it's close to impossible. Did this point change, It did change insofar, as it has become increasingly difficult. or is it too hard to do for a regular linux user, cause maybe that would be the point to improve ? Keep in mind that to get to the point of installing an alternative-only DE, in current Fedora, you normally first have a full blown Gnome3 installed, which is close to impossible to get rid of. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 02/05/2013 09:24 AM, Jef Spaleta wrote: On Mon, Feb 4, 2013 at 11:02 PM, Ralf Corsepius rc040...@freenet.de wrote: Absolutely no. My points are: * The Gnome3-suite will never fit everybody, i.e. trying to push/force it onto all users will never work and is not helpful to the Fedora community. * Gnome3 is (ab-) using Fedora as Gnome3 test-bed. This already has caused a considerable damage to Fedora (and RH). These are different points than the you previously listed. I fear you are severely conflating issues. Not quite. You never heard sentences like: * What you can cope with Fedora? Is the GUI still this unusable beta crap? I did (Usually from Ubuntu users), and am not happy having to hear this. * Thanks CentOS6 came out, Gnome3 and the stuff underneath are too much of a hazzle to continue with Fedora (Often heared from IT-professionals, who switched to Fedora from RHL). You feel gnome3 doesn't fit everybody... i doubt anyone is going to argue against that point. But that has nothing to do with instability or fast release cycles or not having enough stuff in the distro. Sigh, let me try again: The Fedora project is pushing away Fedora users from Fedora, because Fedora/RH have missed that it's new DE (Gnome3) is addressing a different audience than Gnome2 did. The Gnome3 audience is not the classical Fedora user base (Linux devs), it's the Android/iOS adicted wipe/tile kidz. I.e. if Fedora wants to keep their old user-base you need to offer them alternatives, and not to be stubborn on Gnome 3 for whatever reasons. -jefthe real solution to all these problems is openCDE, which I look forward to proposing as default in the F20 cyclespaleta Yes, though you might have ment this as joke. I am sure there are people, who would support such and endeavor ;) My proposal is as funny as turning to Cinnamon as the default environment. I leave it up to the reader to decide if either was intended in a joking manner. Agreed, as I wrote earlier on in this thread, to me, Cinnamon is not sufficiently away from Gnome3 to justify switching. OK with me, if other people want to use it, but do NOT FORCE me to use either! Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Mon, Feb 04, 2013 at 08:51:47PM -0800, Adam Williamson wrote:
That would be the SUSE that along with Mandriva got completely panned
when Ubuntu showed up, then?
The last numbers I had showed that the openSUSE user base is about the
same size as the Fedora user base. (That was about two years ago,
though, I don't know if Fedora made a giant leap in the meantime.)
To the point where they've since been sold
two times and have never really recovered.
Please don't claim things you don't know anything about.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 02/05/2013 10:06 AM, Matej Cepl wrote: On 2013-02-05, 06:19 GMT, Ralf Corsepius wrote: Reality is, when mentioning Fedora to Linux users, I am having difficulties to not get laughed at. Freaks'/nerds' distro, Ubuntu is much easier, Fedora lacks s much, Way too unstable, Way too short life-cycles are the usual answers. Good people walk balanced step towards the goal. Others, without knowing, dance around them contemporary dances. (Franz Kafka) I wouldn't be worried that Fedora is not cool. Actually, thinking about it, that's the best part of Fedora. Absolutely d'accord ... But why have this kool default DE and not leave the choice to what its users actually use? Or differently: One of Fedora's higher goal is freedom - Why not demonstrate this attitude by example and decouple Fedora from Gnome? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Tue, 2013-02-05 at 11:12 +0100, Ralf Corsepius wrote: You never heard sentences like: * What you can cope with Fedora? Is the GUI still this unusable beta crap? I did (Usually from Ubuntu users), and am not happy having to hear this. You never heard Ubuntu users pondering a switch to Fedora 18 because GNOME 3 on Ubuntu is a mix and match of GNOME components in different versions, not working very well together? I did. Sigh, let me try again: The Fedora project is pushing away Fedora users from Fedora, because Fedora/RH have missed that it's new DE (Gnome3) is addressing a different audience than Gnome2 did. The Gnome3 audience is not the classical Fedora user base (Linux devs), it's the Android/iOS adicted wipe/tile kidz. I.e. if Fedora wants to keep their old user-base you need to offer them alternatives, and not to be stubborn on Gnome 3 for whatever reasons. This is a gross generalization. I was a GNOME 2 user, and am still a GNOME 3 user. I loved GNOME 2 for their focus on simplicity and not getting in my way, and I love GNOME 3 even more as they went even further in that direction. My $dayjob is to make a RHEL/Fedora derivative distro, does that fall in what you characterize the classical Fedora user base (Linux devs)? I have never owned any Android/iOS device, am I a 'Android/iOS adicted wipe/tile kidz'? Can you please stop pigeonholing people this way? Agreed, as I wrote earlier on in this thread, to me, Cinnamon is not sufficiently away from Gnome3 to justify switching. OK with me, if other people want to use it, but do NOT FORCE me to use either! Nobody is forcing you to do anything... I find it surprising that you keep saying that new users should be able to read a few paragraphs before choosing the desktop they want to download, and yet you (a seasoned Fedora contributor) didn't manage to read the following: More download options... Or even: Other Options Formats: DVD ISOs, Physical Media Desktops: KDE, Xfce, GNOME, and others Spins: Games, Design, Security, and others Cloud: EC2 Cloud Images Secondary Arches: ARM, s390, PPC View more Fedora options... That's all prominently listed on the main download page: http://fedoraproject.org/get-fedora -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Good people walk balanced step towards the goal. Others, without knowing, dance around them contemporary dances. (Franz Kafka) I wouldn't be worried that Fedora is not cool. Actually, thinking about it, that's the best part of Fedora. Absolutely d'accord ... But why have this kool default DE and not leave the choice to what its users actually use? Or differently: One of Fedora's higher goal is freedom - Why not demonstrate this attitude by example and decouple Fedora from Gnome? Hey, it's GNOME and not Gnome ;) If we start shipping DE choice on the ISO, it will make them heavier. And we will always have to pre-select the available DE. We simply can't include them all. Some won't have enough test. Some won't be as integrated as others. Some won't be available or updated for the next release. It is a really difficult choice. But we can think about the most used DE (GNOME, KDE, Xfce, LXDE..?) We already have a multidesktop DVD including an initial menu that let people decide which DE to install by default. We could probably advertise this one, or work on this to get it on the blockers? I am not from QA, I don't have so much inputs from the release process for this specific ISO, but I am sure that people like them. Ok, we would still have GNOME by default on the DVD and the default live download.. We can spread this topic in three parts: - People install from the DVD We could probably advertize better the DE choice during Anaconda. - People install from the default download ISO We can't include all DE on the media here, therefore we could be able to propose them an app or a start menu or something faster than PackageKit to let them easily change there DE. - People are lost looking for the ISO that they want Then they should just install the default one and keep rocking. Or we need to improve our websites. Or we should graph a dowload workflow where everyone would be represented (simple users, experienced users, sysadmins...) Hey folks, we have spins.fedoraproject.org for all that does not want the default GNOME DE. Can you please take one minute to check this website, and report me which spin as an up to date content? Most of this website is outdated (not the dowload links of course). The content was created once. The screeshots was taken onces. The package listed on the yum groups is probably outdated. Do the websites team has to handle this? My reply is no. If you think so, join us. I have sent to the spin mailing list a request for new screenshot and fresh content for several releases now (not for F18). Only got one or two answers. What is important is not to propose something incredible once. We want to provide quality. Everytime. We should maintain our softwares. Same for our communication. Same for our websites. Same for our Fedora. We are not seeking GNU/Linux users. We are seeking for contributors. If they don't take the time to change their DE and just leave Fedora because we have GNOME by default, do we really care? (Yeah, I do. A bit.) But I agree, I don't like configuring things every time, I would not like to have to install KDE and remove GNOME every time if I were a KDE lover. But we have kickstart install. We already have spins. We should probably just change the way we advertise them. -- Kévin Raymond (Shaiton) pgptwwCzZaHhS.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
On Tue, Feb 5, 2013 at 3:24 AM, Matej Cepl mc...@redhat.com wrote: On 2013-02-04, 19:52 GMT, Andrea Pescetti wrote: It's an outdated article and not much relevant to the current discussion (you see, it says the Symphony repository...). [...] The Symphony code is like everything else in this respect: all Symphony code that OpenOffice will choose to use will sooner or later go to trunk and into a release, receiving the same paranoid attention as the rest and a crystal clear license notice (the Apache 2 License in this case) allowing anybody to use it. And then (and only then) there will be something released from IBM to the public. Until then my comment https://lwn.net/Articles/533402/ stands and the discussion on that webpage is still pretty relevant. Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel At the same time, it's still totally irrelevant for the purpose of this discussion. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Static Analysis: some UI ideas
On Monday 04 February 2013 22:37:45 David Malcolm wrote: Content-addressed storage: they're named by SHA-1 sum of their contents, similar to how git does it, so if the bulk of the files don't change, they have the same SHA-1 sum and are only stored once. See e.g.: http://fedorapeople.org/~dmalcolm/static-analysis/2013-01-30/python-ethtool -0.7-4.fc19.src.rpm/static-analysis/sources/ I probably should gzip them as well. This can indeed save some space. I really like the idea. Maybe using a true git store would give you additional reduction of space requirements thanks to using the delta compression. Currently it's capturing all C files that have GCC invoked on them, or are mentioned in a warning (e.g. a .h file with an inline function with a bug). I could tweak things so it only captures files that are mentioned in a warning. But then you would be no longer able to provide the context. If the error trace goes through a function foo() defined in another module of the same package, the user needs to look at its definition to confirm/waive the defect. I guess the issue is: where do you store the knowledge about good vs bad warnings? My plan was to store it server-side. But we could generate summaries and have them available client-side. For example, if, say cppcheck's useClosedFile test has generated 100 issues of which 5 have received human attention: 1 has been marked as a true positive, and 4 has been marked as false positives. We could then say (cppcheck, useClosedFile) has a signal:noise ratio of 1:4. We could then generate a summary of these (tool, testID) ratios for use by clients, which could then a user-configurable signal:noise threshold, so you can say: only show me results from tests that achieve 1:2 or better. I did not realize you mean auto-filtering based on statistics form user's input. Then maintaining the statistics at the server sounds as a good idea. Being able to export a text file with scores per checker should be just fine for the command-line tools. We will see if the statistics from user's input could be used as a reliable criterion. The problem is that some defects tend to be classified incorrectly without a deeper analysis of the report (and code). The limitation of javascript-based UIs is that they are read-only. Some developers prefer to go through the defects using their own environment (eclipse, vim, emacs, ...) rather than a web browser so that they can fix them immediately. We should support both approaches I guess. Both approaches. What we could do is provide a tool (fedpkg get-errors ?) that captures the errors in the same output format as gcc. That way if you run it from say gcc, the *compilation* buffer has everything in the right format, and emacs' goto-next-error stuff works. 'fedpkg foo' is probably overkill at this point. My concern was rather that we should not so much rely on the web server/browser approach in the first place. I would like to have most of the equipment working just from terminal without any server or browser. Any server solution can be then easily built on top of it. Currently it's matching on 4 things: * by name of test tool (e.g. clang-analyzer) + the class of defect? e.g. useClosedFile in your example above... * by filename of C file within the tarball (so e.g. '/builddir/build/BUILD/python-ethtool-0.7/python-ethtool/etherinfo.c' becomes 'python-ethtool/etherinfo.c', allowing different versions to be compared) With some part of the path or just base name? * function name (or None) You want to work with full signatures if you are going to support overloaded functions/methods in C++. * text of message The messages cannot be checked for exact match in certain cases. Have a look at the rules we use in csdiff for the text messages: http://git.fedorahosted.org/cgit/codescan-diff.git/plain/csfilter.cc See make-comparative-report.py:ComparativeIssues in https://github.com/fedora-static-analysis/mock-with-analysis/blob/master/re ports/make-comparative-report.py Actually my comment was not about the matching algorithm, but about the way you present the comparative results. The UI is based on comparing a pair of source files. In many cases you will fail to find a proper pairing of source files between two versions of a package. Kamil -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Tue, Feb 5, 2013 at 11:27 AM, Ralf Corsepius rc040...@freenet.de wrote: On 02/05/2013 10:06 AM, Matej Cepl wrote: On 2013-02-05, 06:19 GMT, Ralf Corsepius wrote: Reality is, when mentioning Fedora to Linux users, I am having difficulties to not get laughed at. Freaks'/nerds' distro, Ubuntu is much easier, Fedora lacks s much, Way too unstable, Way too short life-cycles are the usual answers. Good people walk balanced step towards the goal. Others, without knowing, dance around them contemporary dances. (Franz Kafka) I wouldn't be worried that Fedora is not cool. Actually, thinking about it, that's the best part of Fedora. Absolutely d'accord ... But why have this kool default DE and not leave the choice to what its users actually use? Or differently: One of Fedora's higher goal is freedom - Why not demonstrate this attitude by example and decouple Fedora from Gnome? Freedom != Choice dialogs for everything. Our users have the freedom to install whatever desktop they like. And where do you draw the line? Select browser? Select texteditor? Select calculator? Select ? Most users don't give a shit about this they just want to install and be done with it. Those who want to select something different have the freedom to do so. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
- Original Message - From: Ralf Corsepius rc040...@freenet.de To: devel@lists.fedoraproject.org Sent: Tuesday, February 5, 2013 12:27:35 PM Subject: Re: Proposed F19 Feature: Cinnamon as Default Desktop On 02/05/2013 10:06 AM, Matej Cepl wrote: On 2013-02-05, 06:19 GMT, Ralf Corsepius wrote: Reality is, when mentioning Fedora to Linux users, I am having difficulties to not get laughed at. Freaks'/nerds' distro, Ubuntu is much easier, Fedora lacks s much, Way too unstable, Way too short life-cycles are the usual answers. Good people walk balanced step towards the goal. Others, without knowing, dance around them contemporary dances. (Franz Kafka) I wouldn't be worried that Fedora is not cool. Actually, thinking about it, that's the best part of Fedora. Absolutely d'accord ... But why have this kool default DE and not leave the choice to what its users actually use? Or differently: One of Fedora's higher goal is freedom - Why not demonstrate this attitude by example and decouple Fedora from Gnome? Is this a technical coupling you speak about or just because of the download button? I mean Fedora being coupled to Gnome for me means that if I install from the KDE spin I'll get a full blown Gnome installation too. Alexander Kurtakov Red Hat Eclipse team Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changing 500 packages BR:maven to BR:maven-local - TOMORROW(ish)
Quoting Stephen Gallagher (2013-02-04 16:26:40) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon 04 Feb 2013 04:56:23 AM EST, Stanislav Ochotnicky wrote: Now that I have your attention... Fedora Maven package is currently a mix of upstream release and our changes that we need for building RPMs. We can clean it up, but we need to move packages from BR: maven to BR:maven-local. That will enable users to install Maven package without installing a lot of other stuff they don't necessarily need. This change will not affect buildroots because maven-local pulls in maven package. The only issue is: there's mass rebuild scheduled for 8.2. I would like to rebuild Maven packages before that. We have a modified mass-rebuild script that can do the change of maven - maven-local automatically. Strictly speaking this change is also breaking current Java guidelines, but I believe for the better (change proposal should be up today/tomorrow, with SIG meeting following). I am looking for a blessing from a community to do this change tomorrow/Wednesday so that F19 is even more awesome :-) Is there anyone who feels strongly against this change? I realize this is very short-notice, but I believe disruption this change will cause is nil. If this change is in violation of policy, PLEASE refrain from performing it until such time as the FPC reviews the proposed changes. Also, if this is going to impact a large number of packages, it should either be coordinated with the existing mass-rebuild plan or else performed in a private branch and then merged in. If something goes wrong with your mass-rebuild, it will be difficult to address in Rawhide with some packages updated and some not. I've filed an FPC ticket[1]. The reason I was planning to do it shortly before mass rebuild is exactly because mass rebuild checks last build that was done on package and if it was done recently - doesn't perform the mass rebuild. I hope we'll manage an agreement on Wednesday so I'll be able to do a nice rebuild in coordination with rel-engs and not pollute repos too much. Thanks for speaking up, [1] https://fedorahosted.org/fpc/ticket/251 -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Hi, On Tue, 05 Feb 2013 19:01:49 +0800 Mathieu Bridon boche...@fedoraproject.org wrote: On Tue, 2013-02-05 at 11:12 +0100, Ralf Corsepius wrote: Sigh, let me try again: The Fedora project is pushing away Fedora users from Fedora, because Fedora/RH have missed that it's new DE (Gnome3) is addressing a different audience than Gnome2 did. The Gnome3 audience is not the classical Fedora user base (Linux devs), it's the Android/iOS adicted wipe/tile kidz. I.e. if Fedora wants to keep their old user-base you need to offer them alternatives, and not to be stubborn on Gnome 3 for whatever reasons. This is a gross generalization. I was a GNOME 2 user, and am still a GNOME 3 user. I loved GNOME 2 for their focus on simplicity and not getting in my way, and I love GNOME 3 even more as they went even further in that direction. My $dayjob is to make a RHEL/Fedora derivative distro, does that fall in what you characterize the classical Fedora user base (Linux devs)? I have never owned any Android/iOS device, am I a 'Android/iOS adicted wipe/tile kidz'? Can you please stop pigeonholing people this way? Normally I try not to do this, but: what he said. I would like to add a voice to the people having successfully switched from GNOME 2 to GNOME 3. In fact, I started out with FVWM and have run IRIX and SunOS desktops as well, before I got onto GNOME 1. If that does not make me an old fart, I do not know what will. Compared to GNOME 2 I really like GNOME 3, even with the remaining warts that I still encounter (multiscreen support is not yet *there* for me mostly). And no, I do not even run many extensions, just the ALT-TAB one. I know lots of people are unhappy with being forced to run GNOME 3, but as has been pointed out in this thread that is a stretch if anything. Even before installation it is possible to choose a distro, after installation as well. Valid points in my eyes are that it should maybe be even easier to switch DE's, either before or after install, but there is nothing in there that makes it necessary to switch the *default*. --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-OpenOffice-UNO
perl-OpenOffice-UNO has broken dependencies in the rawhide tree: On i386: perl-OpenOffice-UNO-0.07-6.fc19.i686 requires libstlport_gcc.so Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Proposed F19 Feature: High Availability Container Resources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2013 03:55 PM, David Vossel wrote: - Original Message - From: Daniel J Walsh dwa...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Friday, February 1, 2013 10:09:27 AM Subject: Re: Proposed F19 Feature: High Availability Container Resources -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/29/2013 03:17 PM, Glauber Costa wrote: = Features/ High Availability Container Resources = https://fedoraproject.org/wiki/Features/High_Availability_Container_Resources Feature owner(s): David Vossel dvos...@redhat.com The Container Resources feature allows the HA stack (Pacemaker + Corosync) residing on a host machine to extend management of resources into virtual guest instances (KVM/LXC). Is this about LXC or libvirt-lxc? These two are entirely different projects, sharing no code, which makes me wonder which project is meant here? Yep, I left that vague and should have used the term linux containers instead of LXC. I'm going to update the page to reflect this. This feature architecturally doesn't care which project manages/initiates the container. All we care about is that the container has it's own isolated network namespace that is reachable from the host (or whatever node is remotely managing the resources within the container) I intentionally chose to use tcp/tls as the first transport we will support to avoid locking this feature into use with any specific virt technology. With that said, I'm likely going to be focusing my test cases on libvirt-lxc just because it seems like it has better fedora support. The LXC project appears to be moving all over the place. Part of the project is really to identify good use-cases for linux containers in an HA environment. The kvm use-case is fairly straight forward and well understood though. I'll update the page to list the linux container use-case as a possible risk. Please also keep in mind that LXC usually refers to a specific project, either the original lxc code or libvirt-lxc. We have either Container Solutions in Fedora, like OpenVZ. You may be able to reach a broader base by making your solution work on that too (and of course, I'd be more than happy to help to trim any issues you may find) -- E Mare, Libertas I would like to also understand how we can work together with virt-sandbox. (Secure Linux Containers) Really interesting idea. Integrating with virt-sandbox would allow the cluster to dynamically launch resources in a contained environment. My understand is that this contained environment would give users the ability to automatically set cpu and memory usage limits for a resource as well as isolate that resource's access to the rest of system. Everywhere that resource gets launched in the cluster, it gets the exact same environment. For the HA config we could do this in a really slick way. We could just allow people to start defining environment details (number cpus, memory usage, network settings) in the resource definition. Then when it's time to launch the resource, if we have certain environment details associated with the resource, we'll just launch the resource in a dynamically created guest sandbox environment instead of directly within the host. This is really brilliant... Conceptually this is like we are creating a virtual machine image on the fly for a resource to start in that follows the resource wherever it goes in the cluster. This would be fun to talk through sometime. The remote LRMD daemon I'm working on would be the piece of the puzzle that allows the HA stack to reach into contained environment to start/stop/monitor the resource living in the container. -- Vossel I think you would also want to talk to Dan Berrange and Vivek Goyal who are designing some higher level concepts for resource controls. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEREu0ACgkQrlYvE4MpobNxjACeNcMMrr50+i5BHDbQv2KvOyiR rwsAoI0flZpto2F6M7LiJdu/gr9MF8+X =flPL -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Tue, Feb 5, 2013 at 1:09 AM, Jef Spaleta jspal...@gmail.com wrote: On Mon, Feb 4, 2013 at 9:55 PM, Ralf Corsepius rc040...@freenet.de wrote: I disagree. Fedora's lack of popularity is largely thanks to these issues. In this context, I feel the Cinnamon request rsp. the give users a choice on DEs attempts are part of an attempt to escape the at least one of the dead-end roads Fedora currently is stuck in (The Gnome3 dead-end). I disagree. I do not think the existence of Cinnamon as yet another environment does anything to address any of the things you previously listed: Freaks'/nerds' distro, Ubuntu is much easier, Fedora lacks s much, Way too unstable, Way too short life-cycles. I view your inclusion of your list as a general angst filled pile-on, and not constructive for the feature proposal discussion. -jefthe real solution to all these problems is openCDE, which I look forward to proposing as default in the F20 cyclespaleta spittake -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ 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: how reload udev rules and systemd on F18
On Tue, Jan 29, 2013 at 1:42 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 29.01.2013 00:50, schrieb Kay Sievers: It is completely wrong to ever do that and to restart udev or other essential sevices from packages. No package besides udev itself is allowed to do restart these services and not only in the context of udev it is GENERALLY wrong it is wrong to restart httpd it is wrong to restart mysqld it is GENERALLY wrong to cripple this in any fedora package instead AT LEAST have this controlled by a global setting what do packagers imagine to happen by restart mysqld on machines where a lot of services depend on mysqld.service and randomly failing while the admin is EXACTLY knowing what he is doing and which services in which order he has to restart to get a new mysqld, httpd whatever version actibe? File a bug (or better patch) to port the services you care about to use socket activation. That way a restart wont have any consequences like those. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 18 for ARM Available Now!
The Fedora ARM team is pleased to announce that Fedora 18 for ARM is now available for download from: http://dl.fedoraproject.org/pub/fedora-secondary/releases/18/Images/ The Fedora 18 for ARM release includes pre-built images for Versatile Express (QEMU), Trimslice (Tegra), Pandaboard (OMAP4), GuruPlug (Kirkwood), and Beagleboard (OMAP3) hardware platforms. Fedora 18 for ARM also includes an installation tree in the yum repository which may be used to PXE-boot a kickstart-based installation on systems that support this option, such as the Calxeda EnergyCore (HighBank). Please visit the announcement page for additional information and links to specific images: http://fedoraproject.org/wiki/Architectures/ARM/F18_Release_Announcement Join us on the IRC in #fedora-arm on Freenode or send feedback and comments to the ARM mailing list. On behalf of the Fedora ARM team, Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Am 04.02.2013 18:35, schrieb Miroslav Suchý: On 01/25/2013 12:12 AM, Lennart Poettering wrote: So, you can ignore all of that, but then you have to think about what you actually accomplished by your upgrade? You updated a couple of libraries, and maybe managed to restart a few processes using them, but for the rest of them the vulnerable openssl version is still in memory, still actively used, even though your update script exited successfully leaving the user under the impression that all was good now and that after he made this upgrade his machine was not vulnerable anymore. And how this differ from yum upgrade which I'm doing every day/week? Lets pretend I'm still running Fedora 16 and every day I do yum-upgrade and not rebooted from day zero. I have exactly the same problem as during yum upgrade to next Fedora release. So we are ignoring this behaviour in middle of release, but it is very serious problem between releases? oh even if people like i did some hundret dist-upgrades over the years it was us told that linux has to go the windows way: http://fedoraproject.org/wiki/Features/OfflineSystemUpdates a few years ago you could make a dist-upgrade and even httpd and fileservers like netatalk were running in the old version until reboot, did it, was there then fedora introduced the restart-service-snippets in every SPEC file, after that came Packagekit and after systemd now all the things worked over decades are suddenly not possible in a clean way - i do not buy that the development goes in the right direction at all signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
the need of Offline Updates
the whole discussion abiut offline updates and why yum is not so good for dist-upgrades is from the wrong point of view, most of the problems are only existing because with each release working things are mangeled actual example: https://bugzilla.redhat.com/show_bug.cgi?id=907749 https://bugzilla.redhat.com/show_bug.cgi?id=887763#c20 bothing bad would happen if the package would not touch /etc/mtab the same for updates of services: nothing would happen on a webserver with httpd if it would not be restarted at package-update which goes wrong if you are using PHP and packages of the dep-tree are not yet all updated which fails PHP to load, without the hardcoded restart httpd would happily continue to run with the old php-package from memory so all the problems which are statet against yum-upgrades are introdouced about the last 5-6 years and were not existing before what currently happens is that more and more HARD-WIRED cross-dependencies are introduced, more and more magic ist introduced and at the end of the road we will be on the windows way you touched anything on the system and so please reboot now signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-OpenOffice-UNO] Try to avoid having tests running in parallel
commit 02160656b8e794e2124eb9ce4e0e354ad3683d8b
Author: Paul Howarth p...@city-fan.org
Date: Tue Feb 5 15:06:01 2013 +
Try to avoid having tests running in parallel
perl-OpenOffice-UNO.spec |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
---
diff --git a/perl-OpenOffice-UNO.spec b/perl-OpenOffice-UNO.spec
index 13e905d..352d134 100644
--- a/perl-OpenOffice-UNO.spec
+++ b/perl-OpenOffice-UNO.spec
@@ -63,7 +63,8 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%check
setsid ooffice --headless
--accept='socket,host=localhost,port=8100;urp;StarOffice.ServiceManager'
trap kill -- -$! ||: EXIT
-sleep 10 # In fact, OpenOffice is known to start almost instantaneously
+# Try to avoid having tests running in parallel
+sleep $(expr \( %__isa_bits - 30 \) \* 4)
make test
@@ -82,6 +83,7 @@ rm -rf $RPM_BUILD_ROOT
%changelog
* Sun Feb 3 2013 Paul Howarth p...@city-fan.org - 0.07-7
- Drop requirement for libreoffice-sdk 4; builds OK with LibreOffice 4
+- Try to avoid having tests running in parallel
* Fri Nov 9 2012 Paul Howarth p...@city-fan.org - 0.07-6
- Tweak Makefile.PL so we don't end up finding libsal_textenc when we're
--
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
File Pod-Parser-1.60.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Pod-Parser: 5f8432f03c121b403e97107bb673885a Pod-Parser-1.60.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
libtasn1 soname bump in rawhide
I'm rebasing libtasn1 in rawhide to libtasn1-3.2. As there is some obsolete API dropped it is accompanied with SONAME bump from libtasn1.so.3 to libtasn1.so.6. I will try to rebuild the dependencies. Regards, -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: the need of Offline Updates
On Tue, 2013-02-05 at 13:21 +0100, Reindl Harald wrote: and at the end of the road we will be on the windows way you touched anything on the system and so please reboot now That's not true - no engineer involved in operating systems development wants that. However: 1) Modern Windows requires reboots for fewer things than the common internet meme would imply 2) Modern Windows updates are safer than RPM, speaking broadly The key is to address both of these things at the same time. Starting from a basis of correctness and safety, then optimizing on top of that is much easier than the other way around. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: #5467: 2 Packages missing from mirrors
#5467: 2 Packages missing from mirrors --+--- Reporter: limb | Owner: rel-eng@… Type: task | Status: closed Milestone: Fedora 19 Alpha | Component: koji Resolution: fixed| Keywords: Blocked By: | Blocking: --+--- Changes (by kevin): * resolution: = fixed * status: new = closed Comment: You can --force tag things into f18-updates and they should go out with the next updates push. I'd done so with the rt3 package. -- Ticket URL: https://fedorahosted.org/rel-eng/ticket/5467#comment:4 Fedora Release Engineering http://fedorahosted.org/rel-eng Release Engineering for the Fedora Project -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 907797] perl-Pod-Parser-1.60 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=907797 Bug 907797 depends on bug 907550, which changed state. Bug 907550 Summary: Review Request: perl-Pod-Usage - Print a usage message from embedded pod documentation https://bugzilla.redhat.com/show_bug.cgi?id=907550 What|Removed |Added Status|ASSIGNED|CLOSED Resolution|--- |RAWHIDE -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=xlPPLKnH0ga=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Install-AutoManifest] Use shipped Module::Install to avoid build dependency cycles (#906007)
commit 90c4cb80d8449be441e79cba3b4e167603fad58e
Author: Paul Howarth p...@city-fan.org
Date: Tue Feb 5 15:40:00 2013 +
Use shipped Module::Install to avoid build dependency cycles (#906007)
perl-Module-Install-AutoManifest.spec | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
---
diff --git a/perl-Module-Install-AutoManifest.spec
b/perl-Module-Install-AutoManifest.spec
index dc70020..25b6f09 100644
--- a/perl-Module-Install-AutoManifest.spec
+++ b/perl-Module-Install-AutoManifest.spec
@@ -1,15 +1,15 @@
Name: perl-Module-Install-AutoManifest
Version:0.003
-Release:3%{?dist}
+Release:4%{?dist}
Summary:The module generates MANIFEST automatically
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Module-Install-AutoManifest/
Source0:
http://www.cpan.org/authors/id/H/HD/HDP/Module-Install-AutoManifest-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(inc::Module::Install)
-BuildRequires: perl(Module::Install::Base)
-BuildRequires: perl(Module::Install::ExtraTests)
+BuildRequires: perl(Cwd)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Path)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -19,8 +19,6 @@ automatically generating MANIFEST.
%prep
%setup -q -n Module-Install-AutoManifest-%{version}
-rm -r inc
-sed -i -e '/^inc\// d' MANIFEST
find -type f -exec chmod -x {} +
%build
@@ -42,6 +40,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Feb 5 2013 Paul Howarth p...@city-fan.org - 0.003-4
+- Use shipped Module::Install to avoid build dependency cycles (#906007)
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.003-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
--
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: the need of Offline Updates
On Tue, Feb 05, 2013 at 10:30:50AM -0500, Colin Walters wrote: 2) Modern Windows updates are safer than RPM, speaking broadly That is more a QA related topic. On Fedora 17 I have several times the expirience, that an update didn't worked well due the existence of broken dependencies. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: the need of Offline Updates
On Tue, Feb 05, 2013 at 01:21:23PM +0100, Reindl Harald wrote: the whole discussion abiut offline updates and why yum is not so good for dist-upgrades is from the wrong point of view, most of the problems are only existing because with each release working things are mangeled Odd question, AFAIK I have understood the wiki page for this feature offline updates woriking only, if you are have running a GUI on your system. For a servere without a GuI offline update is not realize. the same for updates of services: nothing would happen on a webserver with httpd if it would not be restarted at package-update which goes wrong if you are using PHP and packages of the dep-tree are not yet all updated which fails PHP to load, without the hardcoded restart httpd would happily continue to run with the old php-package from memory Question: Does it makes sense to collect all services which should be restarted during the update process and restart the services after all packages was updated? Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Module-Install-ExtraTests] Use included Module::Install to avoid build dependency cycles (#906007)
commit 24ee883300a32a9208284c5e7bbb1ba8bfe6e3eb
Author: Paul Howarth p...@city-fan.org
Date: Tue Feb 5 15:58:36 2013 +
Use included Module::Install to avoid build dependency cycles (#906007)
perl-Module-Install-ExtraTests.spec | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
---
diff --git a/perl-Module-Install-ExtraTests.spec
b/perl-Module-Install-ExtraTests.spec
index 1a8753d..7d055ec 100644
--- a/perl-Module-Install-ExtraTests.spec
+++ b/perl-Module-Install-ExtraTests.spec
@@ -1,19 +1,18 @@
Name: perl-Module-Install-ExtraTests
Version:0.008
-Release:1%{?dist}
+Release:2%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Summary:Ignorable, contextual test support for Module::Install
Url:http://search.cpan.org/dist/Module-Install-ExtraTests
Source:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/Module-Install-ExtraTests-%{version}.tar.gz
BuildArch: noarch
-BuildRequires: perl(Module::Install)
# Run-time
BuildRequires: perl(Cwd)
BuildRequires: perl(ExtUtils::Command)
+BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Find)
BuildRequires: perl(File::Spec)
-BuildRequires: perl(Module::Install::Base)
# Tests
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -32,8 +31,6 @@ instances:
%prep
%setup -q -n Module-Install-ExtraTests-%{version}
-# Update bundled Module::Install from system
-touch inc/.author
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -54,6 +51,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Tue Feb 5 2013 Paul Howarth p...@city-fan.org - 0.008-2
+- Use included Module::Install to avoid build dependency cycles (#906007)
+
* Wed Jan 1 2013 Jitka Plesnikova jples...@redhat.com - 0.008-1
- 0.008 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Install-AutoManifest] Created tag perl-Module-Install-AutoManifest-0.003-4.fc19
The lightweight tag 'perl-Module-Install-AutoManifest-0.003-4.fc19' was created pointing to: 90c4cb8... Use shipped Module::Install to avoid build dependency cycle -- 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: the need of Offline Updates
Am 05.02.2013 16:49, schrieb Jochen Schmitt: On Tue, Feb 05, 2013 at 10:30:50AM -0500, Colin Walters wrote: 2) Modern Windows updates are safer than RPM, speaking broadly jokingly? show me a upgrade of production machines from F9 to F17 without end in a inconsistent system on windows - you can't, i have been there windows is missing anything like transaction-checks tp prevent one package is overwriting files of a different one, has no package-deps over the complete system tune2fs 1.42.3 (14-May-2012) Filesystem volume name: / Last mounted on: / Filesystem UUID: 918f24a7-bc8e-4da5-8a23-8800d510442 Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file uninit_bg dir_nlink Filesystem created: Mon Aug 18 06:48:05 2008 3.7.3-101.fc17.x86_64 #1 SMP Fri Jan 18 17:40:57 UTC 2013 and as you can see above this was installed with F9 in 2008 on ext3 and is now F17 with ext4 and 100% as clean as any fresh install (one of more than 20 machines from the same golden master) and yes, i even survived dist-upgrades with power-loss in the middle at home, no problem to cleanup the dupes and finish the upgrade simply not possible with windows That is more a QA related topic. On Fedora 17 I have several times the expirience, that an update didn't worked well due the existence of broken dependencies. which makes the update SAFER because the deps have to be fixed and a update is installed clean or not at all signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: the need of Offline Updates
Am 05.02.2013 16:58, schrieb Jochen Schmitt: the same for updates of services: nothing would happen on a webserver with httpd if it would not be restarted at package-update which goes wrong if you are using PHP and packages of the dep-tree are not yet all updated which fails PHP to load, without the hardcoded restart httpd would happily continue to run with the old php-package from memory Question: Does it makes sense to collect all services which should be restarted during the update process and restart the services after all packages was updated? it would make MUCH more sense and if you are there and have removed the condrestart-crap from all of the SPEC-files you are in a position to make a global setting not restart any service which is what i want in case of a dist-upgrade * httpd is running * if it crashes - Restart=always, RestartSec=1 * at all the better option as offline-upgrade * without restart services mostg things are running perfect * the upgrade takes 5 minutes * before restart i want manually verify grub-config and do cleanups * this cleanups take two minutes * after that i reboot the machine in the new system i am doing this since many years on many setups and rebuild all for me critical packages to prevent the restarts - BUT i still do not get this poor decision in a naive way mangle all SPEC-files signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Virtio RNG
Matthew Garrett (mj...@srcf.ucam.org) said: This patchset means that there's a /dev/hwrng available in the guest, so you still need to run something like rngd to mix that into the kernel's entropy pool. Speaking of, why is it a thing that we need a separate userspace daemon to dump data from kernel bucket A (/dev/hwrng) into kernel bucket B (the entropy pool)? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Mon, Feb 04, 2013 at 11:27:10PM +0100, Martin Sourada wrote: On Mon, 4 Feb 2013 16:34:18 +0100 Jan Kratochvil wrote: Still I believe it is probably true as I doubt Fedora QA tests compatibility with old hosts. Fedora QA AFAIK tests on their own hardware only + virtual machines. I don't know about kernel upstream QA/devs though. I'm running F18 on a 32bit machine as well. Actually, I am installing a 32bit F18 on my laptop today. Though to be honest, I haven't run 32bit outsideo of a guest since before FC1 GA. I have noticed a large number of kernel bugs that seem to trigger on 32bit only. I am guessing this is partly due to PAE being used much more than it used to be, combined with the fact that very few kernel developers actually run 32bit hardware. That said, I plan to investigate kernel issues with it, and will not be doing full QA checks accross software I do not use in day to day desktop use. Justin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Tue, 2013-02-05 at 11:18 +0100, Michael Schroeder wrote: On Mon, Feb 04, 2013 at 08:51:47PM -0800, Adam Williamson wrote: That would be the SUSE that along with Mandriva got completely panned when Ubuntu showed up, then? The last numbers I had showed that the openSUSE user base is about the same size as the Fedora user base. (That was about two years ago, though, I don't know if Fedora made a giant leap in the meantime.) To the point where they've since been sold two times and have never really recovered. Please don't claim things you don't know anything about. Sorry, that came off as excessively harsh, I didn't intend it that way - just that SUSE hasn't achieved some extraordinary level of success or anything, to make it a model. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-XML-SAX-Writer] Always use included Module::Install to avoid circular build deps (#906007)
commit b220aa08f8f4d564f70d052ec9adb2d06c48bce3
Author: Paul Howarth p...@city-fan.org
Date: Tue Feb 5 16:19:19 2013 +
Always use included Module::Install to avoid circular build deps (#906007)
perl-XML-SAX-Writer.spec | 20 +++-
1 files changed, 7 insertions(+), 13 deletions(-)
---
diff --git a/perl-XML-SAX-Writer.spec b/perl-XML-SAX-Writer.spec
index abbf6b2..8a29600 100644
--- a/perl-XML-SAX-Writer.spec
+++ b/perl-XML-SAX-Writer.spec
@@ -1,6 +1,6 @@
Name: perl-XML-SAX-Writer
Version:0.53
-Release:2%{?dist}
+Release:3%{?dist}
Summary:SAX2 Writer
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,12 +8,10 @@ URL:http://search.cpan.org/dist/XML-SAX-Writer/
Source0:
http://www.cpan.org/modules/by-module/XML/XML-SAX-Writer-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
-BuildRequires: perl(inc::Module::Install)
+BuildRequires: perl(Cwd)
BuildRequires: perl(Encode) = 2.12
-%if ! ( 0%{?rhel} )
-BuildRequires: perl(Module::Install::AutoManifest)
-BuildRequires: perl(Module::Install::Repository)
-%endif
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Path)
BuildRequires: perl(Test::More) = 0.40
BuildRequires: perl(XML::Filter::BufferText) = 1.00
BuildRequires: perl(XML::NamespaceSupport) = 1.00
@@ -25,15 +23,8 @@ A new XML Writer to match the SAX2 effort.
%prep
%setup -q -n XML-SAX-Writer-%{version}
-rm -r inc
-sed -i -e '/^inc\// d' MANIFEST
find -type f -exec chmod -x {} +
-%if ( 0%{?rhel} )
-sed -i -e '/^auto_set_repository/ d' Makefile.PL
-sed -i -e '/^auto_manifest/ d' Makefile.PL
-%endif
-
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
@@ -61,6 +52,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Tue Feb 5 2013 Paul Howarth p...@city-fan.org - 0.53-3
+- Always use included Module::Install to avoid circular build deps (#906007)
+
* Fri Nov 23 2012 Jitka Plesnikova jples...@redhat.com - 0.53-2
- Drop BR perl(Module::Install::*) for RHEL
--
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: Proposed F19 Feature: Fedora Upgrade - using yum
On Tue, 2013-02-05 at 08:54 +0100, Miroslav Suchý wrote: On 02/04/2013 10:29 PM, Adam Williamson wrote: https://ohjeezlinux.wordpress.com/2012/11/13/fedup-a-little-background/ ... kinda. That's the best that I know of. It lacks in details how I can put hook in upgrade.pre and upgrade.post. What is the best practise here? It would be nice if you can enhance: http://fedoraproject.org/wiki/Packaging:Guidelines with example snippets and general guidance how packager can create such hook. I agree that would be nice, but I am not actually the author of the feature or a user of it, so I don't have the expertise on tap. :) Will is the one currently best-placed to do so. So far as I'm aware these are simply dracut hooks so dracut docs would apply, but I'm not sure. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Module-Install-Repository] Created tag perl-Module-Install-Repository-0.06-4.fc19
The lightweight tag 'perl-Module-Install-Repository-0.06-4.fc19' was created pointing to: ce31946... Use included Module::Install to avoid build dependency cycl -- 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-XML-SAX-Writer] Created tag perl-XML-SAX-Writer-0.53-3.fc19
The lightweight tag 'perl-XML-SAX-Writer-0.53-3.fc19' was created pointing to: b220aa0... Always use included Module::Install to avoid circular build -- 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
udisks in rawhide
FYI, the old-generation udisks package has been made orphan in rawhide, nothing should be really using it nowadays. There's udisks2 (with incompatible API) as a supported method for handling storage. Is anybody still using udisks, the first generation? I see a few from quick repoquery check. Maintainers please check if it's possible to use/port to udisks2 instead. # repoquery --whatrequires udisks bashmount-0:1.6.2-4.fc18.noarch emelfm2-0:0.8.2-1.fc19.x86_64 exaile-0:3.3.1-1.fc19.noarch liveusb-creator-0:3.11.7-2.fc18.noarch wmudmount-0:1.13-4.fc19.x86_64 yumex-0:3.0.10-1.fc19.noarch (please keep me on Cc: when replying) Thanks, -- Tomas Bzatek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [perl-XML-SAX-Writer] Always use included Module::Install to avoid circular build deps (#906007)
On 05/02/13 16:38, Petr Pisar wrote: On Tue, Feb 05, 2013 at 04:19:56PM +, Paul Howarth wrote: commit b220aa08f8f4d564f70d052ec9adb2d06c48bc Author: Paul Howarth p...@city-fan.org Date: Tue Feb 5 16:19:19 2013 + Always use included Module::Install to avoid circular build deps (#906007) perl-XML-SAX-Writer.spec | 20 +++- 1 files changed, 7 insertions(+), 13 deletions(-) Can you show me the cycle? I cannot find why Module::Install::* stuff would need XML::SAX::Writer. There's a lot of them. Remember, these are build dependency cycles, not regular dependency cycles, so things pulled in by test suites take effect. Some samples: perl-XML-Twig-perl-XML-SAX-Writer-perl-Module-Install-Repository-perl-Path-Class-perl-Test-Perl-Critic-perl-Perl-Critic-perl-List-MoreUtils-perl-Test-LeakTrace-perl-Test-Valgrind-perl-XML-Twig perl-prefork-perl-Perl-MinimumVersion-perl-Perl-Critic-perl-List-MoreUtils-perl-Test-LeakTrace-perl-Test-Valgrind-perl-XML-Twig-perl-XML-SAX-Writer-perl-Module-Install-perl-Module-ScanDeps-perl-prefork perl-XML-Twig-perl-XML-SAX-Writer-perl-Module-Install-perl-Test-MinimumVersion-perl-Perl-MinimumVersion-perl-Perl-Critic-perl-List-MoreUtils-perl-Test-LeakTrace-perl-Test-Valgrind-perl-XML-Twig There's probably more than one place to have broken these cycles, but this way fits in with upstream's build process and doesn't require any bootstrapping conditionals or extra builds at the end of bootstrapping. Paul. -- 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: Static Analysis: some UI ideas
On Tue, 2013-02-05 at 13:02 +0100, Kamil Dudka wrote: On Monday 04 February 2013 22:37:45 David Malcolm wrote: Content-addressed storage: they're named by SHA-1 sum of their contents, similar to how git does it, so if the bulk of the files don't change, they have the same SHA-1 sum and are only stored once. See e.g.: http://fedorapeople.org/~dmalcolm/static-analysis/2013-01-30/python-ethtool -0.7-4.fc19.src.rpm/static-analysis/sources/ I probably should gzip them as well. This can indeed save some space. I really like the idea. Maybe using a true git store would give you additional reduction of space requirements thanks to using the delta compression. Interesting. I had thought that git purely stored compressed files and eschewed the idea of deltas, but it does indeed store deltas sometimes: http://git-scm.com/book/ch9-4.html My plan had been to store the files either in a big lookaside directory structure, or directly as (compressed) blobs in a database, named/indexed by SHA-1 sum. But that approach might yield significant savings, provided it can do name-matching. Then again, premature optimization is the root of all bugs :) Currently it's capturing all C files that have GCC invoked on them, or are mentioned in a warning (e.g. a .h file with an inline function with a bug). I could tweak things so it only captures files that are mentioned in a warning. But then you would be no longer able to provide the context. If the error trace goes through a function foo() defined in another module of the same package, the user needs to look at its definition to confirm/waive the defect. I was a little sloppy in my wording when I said mentioned in a warning, sorry. This *does* include the traces, so for the case you describe it *would* capture the source file containing the definition of foo(), so that we would be able to render that information in a presentation of the data. (though all of my current trace visualizations only handle one function at a time; see e.g.: http://gcc-python-plugin.readthedocs.org/en/latest/_images/sample-html-error-report.png (screenshot of html) and: http://fedorapeople.org/~dmalcolm/gcc-python-plugin/2012-03-19/example/example.html http://fedorapeople.org/~dmalcolm/gcc-python-plugin/2012-03-26/pylibmc/example.html so we'd need some kind of new visualization for interprocedural paths. [specifically, the source extraction is implemented by https://github.com/fedora-static-analysis/mock-with-analysis/blob/master/mock-with-analysis#L172 in extract_results_from_chroot() where I pass a SourceExtractor visitor over the analysis file; it visits all files mentioned in the analysis file] I guess the issue is: where do you store the knowledge about good vs bad warnings? My plan was to store it server-side. But we could generate summaries and have them available client-side. For example, if, say cppcheck's useClosedFile test has generated 100 issues of which 5 have received human attention: 1 has been marked as a true positive, and 4 has been marked as false positives. We could then say (cppcheck, useClosedFile) has a signal:noise ratio of 1:4. We could then generate a summary of these (tool, testID) ratios for use by clients, which could then a user-configurable signal:noise threshold, so you can say: only show me results from tests that achieve 1:2 or better. I did not realize you mean auto-filtering based on statistics form user's input. Then maintaining the statistics at the server sounds as a good idea. Being able to export a text file with scores per checker should be just fine for the command-line tools. We will see if the statistics from user's input could be used as a reliable criterion. The problem is that some defects tend to be classified incorrectly without a deeper analysis of the report (and code). (nods) For some depressing but useful thoughts on this, see: http://www.dwheeler.com/flawfinder/#fool-with-tool The limitation of javascript-based UIs is that they are read-only. Some developers prefer to go through the defects using their own environment (eclipse, vim, emacs, ...) rather than a web browser so that they can fix them immediately. We should support both approaches I guess. Both approaches. What we could do is provide a tool (fedpkg get-errors ?) that captures the errors in the same output format as gcc. That way if you run it from say gcc, the *compilation* buffer has everything in the right format, and emacs' goto-next-error stuff works. 'fedpkg foo' is probably overkill at this point. My concern was rather that we should not so much rely on the web server/browser approach in the first place. I would like to have most of the equipment working just from terminal without any server or browser. Any server solution can be then easily built on top of it. Right, and that's what I've been doing. Currently it's matching on 4 things: *
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 02/04/2013 09:49 PM, Orcan Ogetbil wrote: The user should also be informed that the choice is not final, and the DE can be switched after the installation via package manager. Does the current webpage indicate this somewhere? I could not see it. What's worse is that it's harder than it used to be to change the desktop---desktop style is no longer a login-time selection. In fact, I am not sure what is the recommended method nowadays--- groupinstall KDE + groupremove Gnome? but this can't be right for XFCE which I think shares stuff with Gnome.. I agree with Adam that the solution isn't to force a choice early on, but the flip side of it is that it should be easier to choose on an installed system. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Hi On Tue, Feb 5, 2013 at 11:58 AM, Przemek Klosowski wrote: What's worse is that it's harder than it used to be to change the desktop---desktop style is no longer a login-time selection. It certainly is. Every login manager offers that option Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: the need of Offline Updates
Hi On Tue, Feb 5, 2013 at 11:04 AM, Reindl Harald wrote: it would make MUCH more sense and if you are there and have removed the condrestart-crap from all of the SPEC-files you are in a position to make a global setting not restart any service which is what i want in case of a dist-upgrade Currently, the recommendation is to use systemd macros which essentially makes this a global setting. I am not sure why you are not in favor of that Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 907775] overload arg '+0' is invalid at /usr/share/perl5/vendor_perl/Mail/Message/Field.pm line 29.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=907775 --- Comment #1 from Tom spot Callaway tcall...@redhat.com --- Pretty sure this is fixed in the update I just pushed a few days ago: https://admin.fedoraproject.org/updates/FEDORA-2013-1833/perl-Mail-Box-2.107-1.fc18 Please test and let me know if it is not (and give +1 karma if it is). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=qCr15nX9dia=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Proposed F19 Feature: Dracut HostOnly
On Fri, 01 Feb 2013 11:34:40 +0100 Harald Hoyer harald.ho...@gmail.com wrote: The rescue initramfs carries just more kernel drivers to cope with different HW and will also have more debug tools, if you really really screwed up your real root. Nothing security fancy here, besides that you might want to passwort protect this entry, either via grub or via including /etc/passwd with a rescue root password in the initramfs. So, is this 'rescue' mode the same as the current rescue mode on dvd/netinstall via anaconda? Or just similar? Is it intended to replace those? Can you easily setup network and find your installs (if any)? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 05/02/13 16:58, Przemek Klosowski wrote: What's worse is that it's harder than it used to be to change the desktop---desktop style is no longer a login-time selection. In fact, I am not sure what is the recommended method nowadays--- groupinstall KDE + groupremove Gnome? but this can't be right for XFCE which I think shares stuff with Gnome.. If you want to change what display manager is used then just change what /etc/systemd/system/display-manager.service points to. What desktop a display manager starts will be a display manager specific configuration option. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: MATE Desktop 1.6
One additional question on the feature... from the feature page: Fedora 16/17/18 are already running MATE Desktop 1.5.5 which is the development release of 1.6 Is there a reason for a development release being pushed to stable releases? http://fedoraproject.org/wiki/Updates_Policy#Stable_Releases I don't know much about the MATE release cycle, how much change is there in a development release? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: QXL/Spice KMS Driver
On Thursday 31 of January 2013 09:19:56 Kevin Fenzi wrote: On Thu, 31 Jan 2013 08:12:28 -0800 Adam Williamson awill...@redhat.com wrote: I thought the feature deadline was yesterday; are we on late features now? The deadline was yesterday to have your feature submitted. Yep, the deadline to have features submitted to wrangler for review. I wish people would not submit most of the features in the last few days but it's how tech people work :-) It takes some time to process everything... I think the wrangler has been spreading them out a bit to avoid dumping them all at once into the list. And yes, also spreading it over more days. A few still to come - submitted on time but I have questions/asked owners to provide more details etc. but I've been travelling to FOSDEM (so sorry for late reply)... Jaroslav This is a good change but I'd very much like it to be in and reliable enough for basic use by Alpha: we do a lot of validation testing in qxl KVMs so it wouldn't be ideal for this to be bouncing around during Alpha/Beta time. Is that likely to be the case? Thanks! +1 kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Simplify Java/Maven Packaging using XMvn
On Monday 28 of January 2013 09:51:42 Jaroslav Reznik wrote: = Features/XMvn = https://fedoraproject.org/wiki/Features/XMvn Feature has been moved by maintainer to https://fedoraproject.org/wiki/Features/Simplified_Maven_Packaging to have more descriptive URL. Jaroslav Feature owner(s): Stanislav Ochotnicky sochotni...@redhat.com Introduce new Maven packaging tooling with new macros, automated install section and more. == Detailed description == Current Maven packaging can be time-consuming and full of repetition even for simple packages. To simplify Maven packaging new XMvn tools and macros have been developed. Main features of XMvn include: No need for patched Maven (simpler maintenance) Automated %install section with possible per-artifact installation configuration Automatic requires generation for Maven artifacts Goal of this feature is to migrate all packages to use XMvn instead of mvn- rpmbuild script. Several packages have already been converted as part of initial testing: http://pkgs.fedoraproject.org/cgit/maven-surefire.git/tree/maven- surefire.spec http://pkgs.fedoraproject.org/cgit/maven-doxia.git/tree/maven-doxia.spec http://pkgs.fedoraproject.org/cgit/slf4j.git/tree/slf4j.spec http://pkgs.fedoraproject.org/cgit/apache-commons- compress.git/tree/apache-commons-compress.spec ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: PreUpgrade Assistant
Additionally, what about adding 'postupgrade' hooks or assistance? Ie, after a fedup upgrade you could run and note to users packages which are orphaned and could be removed, etc kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Static Analysis: firehose-devel mailing list
There's been some interest in using the proposed static analysis results format (Firehose) from the Debian side of the house so I've gone ahead and created: https://admin.fedoraproject.org/mailman/listinfo/firehose-devel as a mailing list for discussion of the format, importers, etc. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: the need of Offline Updates
Am 05.02.2013 18:02, schrieb Rahul Sundaram: Hi On Tue, Feb 5, 2013 at 11:04 AM, Reindl Harald wrote: it would make MUCH more sense and if you are there and have removed the condrestart-crap from all of the SPEC-files you are in a position to make a global setting not restart any service which is what i want in case of a dist-upgrade Currently, the recommendation is to use systemd macros which essentially makes this a global setting. I am not sure why you are not in favor of that because %posttrans test -f /etc/sysconfig/httpd-disable-posttrans || \ /bin/systemctl try-restart httpd.service htcacheclean.service /dev/null 21 || : is all but not a global setting? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how reload udev rules and systemd on F18
On Ter, 2013-02-05 at 06:42 +, Sérgio Basto wrote: On Ter, 2013-01-29 at 17:59 +, Sérgio Basto wrote: On Ter, 2013-01-29 at 01:52 +0100, Lennart Poettering wrote: Yes, even then. udev will notice rules dropped there. OK I will test that I just test it and doesn't assign USB devices. But seeing what udev.service , udev-trigger.service and udev-settle.service do on : systemctl restart udev.service systemctl restart udev-trigger.service systemctl restart udev-settle.service I back to old scripts # Assign USB devices if /sbin/udevadm control --reload-rules /dev/null 21 then /sbin/udevadm trigger --subsystem-match=usb /dev/null 21 || : /sbin/udevadm settle /dev/null 21 || : fi After some tests I'm going pack with : if /sbin/udevadm control --reload-rules /dev/null 21 then /sbin/udevadm trigger --subsystem-match=usb --action=add /dev/null 21 || : /sbin/udevadm settle /dev/null 21 || : fi Any advises or opinions ? Many thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: the need of Offline Updates
HI On Tue, Feb 5, 2013 at 12:38 PM, Reindl Harald h.rei...@thelounge.netwrote: Currently, the recommendation is to use systemd macros which essentially makes this a global setting. I am not sure why you are not in favor of that because %posttrans test -f /etc/sysconfig/httpd-disable-posttrans || \ /bin/systemctl try-restart httpd.service htcacheclean.service /dev/null 21 || : is all but not a global setting? Read properly what I have written above and read the current guidelines. Thanks Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Tue, 2013-02-05 at 17:17 +, Tom Hughes wrote: On 05/02/13 16:58, Przemek Klosowski wrote: What's worse is that it's harder than it used to be to change the desktop---desktop style is no longer a login-time selection. In fact, I am not sure what is the recommended method nowadays--- groupinstall KDE + groupremove Gnome? but this can't be right for XFCE which I think shares stuff with Gnome.. If you want to change what display manager is used then just change what /etc/systemd/system/display-manager.service points to. What desktop a display manager starts will be a display manager specific configuration option. ...but as Rahul said, they all allow you to log in to any desktop. There seems to be a meme in this thread that GDM does not, but that's not correct, it does. The choice is not visible unless you actually have multiple desktops installed, but when you do, it gives you the option. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
There is a current poll at fedora forum. http://forums.fedoraforum.org/showthread.php?t=284463 The winner is... Wolfgang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Am 05.02.2013 19:49, schrieb Rave it: There is a current poll at fedora forum. http://forums.fedoraforum.org/showthread.php?t=284463 pff look at the total count 56 users said they use GNOME3 so what.. and even if the count would be larger, it says nothing about how satisfied they are, nor do most users even know about the voting and last but not least most users are not visible here or at fedoraforum.org and nonody can count the wtf did they with my desktop users after GNOME3 hit their life the same for KDE4.0 some years ago - if there would have been the option KDE3 or KDE4 the first two years you can imagine how much users would have choosen KDE3.x what makes me rellay angry (as one who never used and will use GNOME and i knew GNOME 1.0 and KDE 1.0 as well where most users of today not heard about linux at all) is that the GNOME developers did NOT learn ANYTHING by the KDE4.0 disaster and that distributions are not straight enough to show ignorant upstream if you think you can abuse all your users by present a completly different desktop with thse same name we stop supporting you - no lala i follow blindly signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Virtio RNG
On Tue, 2013-02-05 at 11:11 -0500, Bill Nottingham wrote: Matthew Garrett (mj...@srcf.ucam.org) said: This patchset means that there's a /dev/hwrng available in the guest, so you still need to run something like rngd to mix that into the kernel's entropy pool. Speaking of, why is it a thing that we need a separate userspace daemon to dump data from kernel bucket A (/dev/hwrng) into kernel bucket B (the entropy pool)? I completely agree with Bill here. I think this mechanism should be just built into kernel and for the paranoid it should definitely be controllable by sysctl (even maybe off by default although in initial seeding of the kernel entropy pool it would be very nice to have it on). -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 2013-02-05 20:06, Reindl Harald wrote: [cut] what makes me rellay angry (as one who never used and will use GNOME and i knew GNOME 1.0 and KDE 1.0 as well where most users of today not heard about linux at all) is that the GNOME developers did NOT learn ANYTHING by the KDE4.0 disaster and that distributions are not straight enough to show ignorant upstream if you think you can abuse all your users by present a completly different desktop with thse same name we stop supporting you - no lala i follow blindly As one with memories of OpenLook, CDE, Gnome 1.0 and others...I think we have two things in this thread: whether to have a default alternative for new users (attracting most of the QA resources we have available), and what a default alternative should be. I leave the no default desktop discussion aside, we shouldnt it have unless some on this list are feeling so strong about the GNOME3 evilness. So remaining question is IMHO what default alternative we should use. I wouldn't say Fedora follows blindly but rather chooses an upstream from some alternatives (their ability to handle feedback from us beeing one ot the criterias). I think the discussion in this thread has shown that GNOME3 is really the best option, the developer resources maybe being the best argument. That said, one question is in the air for those of us with so long memories: are we able to adapt to a changing (desktop) environment? Personally, I really like GNOME3. But if Fedora for reasons unknown decided to choose another desktop I think I would just stick to GNOME3, installing it and then use it as long as it was a viable alternative. Can't see this as a big issue. Just my 5 öre --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 5 February 2013 20:10, Alec Leamas leamas.a...@gmail.com wrote: I wouldn't say Fedora follows blindly but rather chooses an upstream from some alternatives (their ability to handle feedback from us beeing one ot the criterias). Gnome has been the default, unless I'm misremebering since *before* Fedora (RH8/9 or earlier). That's not incompatible with 'chooses an upstream from some alternatives' but does suggest some inertia. Maybe if Gnome really thinks distros might drop them they'd think harder about introducing unwanted workflow changes every other release. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 02/05/2013 09:31 PM, Ian Malone wrote: On 5 February 2013 20:10, Alec Leamas leamas.a...@gmail.com wrote: I wouldn't say Fedora follows blindly but rather chooses an upstream from some alternatives (their ability to handle feedback from us beeing one ot the criterias). Gnome has been the default, unless I'm misremebering since *before* Fedora (RH8/9 or earlier). That's not incompatible with 'chooses an upstream from some alternatives' but does suggest some inertia. Maybe if Gnome really thinks distros might drop them they'd think harder about introducing unwanted workflow changes every other release. The actual problem is the current Gnome 3 being an entirely different product than Gnome 2, which usability-wise has *nothing* in common with Gnome2 and addresses a completely different target audience. You ordered Gnome and have been served Pizza for a long time - now you're being served Burgers :-) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Tue, Feb 5, 2013 at 2:46 PM, Ralf Corsepius rc040...@freenet.de wrote: On 02/05/2013 09:31 PM, Ian Malone wrote: On 5 February 2013 20:10, Alec Leamas leamas.a...@gmail.com wrote: I wouldn't say Fedora follows blindly but rather chooses an upstream from some alternatives (their ability to handle feedback from us beeing one ot the criterias). Gnome has been the default, unless I'm misremebering since *before* Fedora (RH8/9 or earlier). That's not incompatible with 'chooses an upstream from some alternatives' but does suggest some inertia. Maybe if Gnome really thinks distros might drop them they'd think harder about introducing unwanted workflow changes every other release. The actual problem is the current Gnome 3 being an entirely different product than Gnome 2, which usability-wise has *nothing* in common with Gnome2 and addresses a completely different target audience. You ordered Gnome and have been served Pizza for a long time - now you're being served Burgers :-) M. . . .cheeseburger pizza. . . -J Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ 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
Schedule for Wednesday's FESCo Meeting (2013-02-06)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC (1:00pm EST, 19:00 CET) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #896 Refine Feature process .fesco 896 https://fedorahosted.org/fesco/ticket/896 #topic #966 Fedora 19 Schedule proposal (DRAFT!) .fesco 966 https://fedorahosted.org/fesco/ticket/966 #topic #1008 F19 Feature: First-Class Cloud Images - https://fedoraproject.org/wiki/Features/FirstClassCloudImages .fesco 1008 https://fedorahosted.org/fesco/ticket/1008 = New business = #topic #1028 tor package concerns .fesco 1028 https://fedorahosted.org/fesco/ticket/1028 #topic #1076 2013-02-06 meeting feature voting .fesco 1076 https://fedorahosted.org/fesco/ticket/1076 FESCo members please add your list of features to discuss in ticket or have it ready for the meeting at this time. #topic #1030 F19 Feature: AnacondaNewUI Followup - https://fedoraproject.org/wiki/Features/AnacondaNewUI_Followup .fesco 1030 https://fedorahosted.org/fesco/ticket/1030 #topic #1031 F19 Feature: Anaconda Realm Integration - https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration .fesco 1031 https://fedorahosted.org/fesco/ticket/1031 #topic #1032 F19 Feature: Better NetworkManager IPSec Integration - https://fedoraproject.org/wiki/Features/BetterNetworkManagerIPSecIntegration .fesco 1032 https://fedorahosted.org/fesco/ticket/1032 #topic #1033 F19 Feature: CUPS 1.6 - https://fedoraproject.org/wiki/Features/CUPS1.6 .fesco 1033 https://fedorahosted.org/fesco/ticket/1033 #topic #1034 F19 Feature: Developers Assistant - https://fedoraproject.org/wiki/Features/DevelopersAssistant .fesco 1034 https://fedorahosted.org/fesco/ticket/1034 #topic #1035 F19 Feature: Dracut HostOnly - https://fedoraproject.org/wiki/Features/DracutHostOnly .fesco 1035 https://fedorahosted.org/fesco/ticket/1035 #topic #1036 F19 Feature: Enterprise / distributed two-factor authentication - https://fedoraproject.org/wiki/Features/EnterpriseTwoFactorAuthentication .fesco 1036 https://fedorahosted.org/fesco/ticket/1036 #topic #1037 F19 Feature: Erlang/OTP R16 - https://fedoraproject.org/wiki/Features/Erlang_R16 .fesco 1037 https://fedorahosted.org/fesco/ticket/1037 #topic #1038 F19 Feature: Apache OpenOffice - https://fedoraproject.org/wiki/Features/ApacheOpenOffice .fesco 1038 https://fedorahosted.org/fesco/ticket/1038 #topic #1039 F19 Feature: Federated VoIP - https://fedoraproject.org/wiki/Features/FederatedVoIP .fesco 1039 https://fedorahosted.org/fesco/ticket/1039 #topic #1040 F19 Feature: firewalld Lockdown - https://fedoraproject.org/wiki/Features/FirewalldLockdown .fesco 1040 https://fedorahosted.org/fesco/ticket/1040 #topic #1041 F19 Feature: GLIBC 2.17 - https://fedoraproject.org/wiki/Features/GLIBC217 .fesco 1041 https://fedorahosted.org/fesco/ticket/1041 #topic #1042 F19 Feature: GNOME 3.8 - https://fedoraproject.org/wiki/Features/Gnome3.8 .fesco 1042 https://fedorahosted.org/fesco/ticket/1042 #topic #1043 F19 Feature: GSS Proxy - https://fedoraproject.org/wiki/Features/gss-proxy .fesco 1043 https://fedorahosted.org/fesco/ticket/1043 #topic #1044 F19 Feature: High Availability Container Resources - https://fedoraproject.org/wiki/Features/High_Availability_Container_Resources .fesco 1044 https://fedorahosted.org/fesco/ticket/1044 #topic #1045 F19 Feature: Cinnamon as Default Desktop - https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop .fesco 1045 https://fedorahosted.org/fesco/ticket/1045 #topic #1046 F19 Feature: firewalld Rich Language - https://fedoraproject.org/wiki/Features/FirewalldRichLanguage .fesco 1046 https://fedorahosted.org/fesco/ticket/1046 #topic #1047 F19 Feature: KDE Plasma Workspaces 4.10 - https://fedoraproject.org/wiki/Features/KDE410 .fesco 1047 https://fedorahosted.org/fesco/ticket/1047 #topic #1048 F19 Feature: libkkc - https://fedoraproject.org/wiki/Features/libkkc .fesco 1048 https://fedorahosted.org/fesco/ticket/1048 #topic #1049 F19 Feature: MATE Desktop 1.6 - https://fedoraproject.org/wiki/Features/MATE-Desktop-1.6 .fesco 1049 https://fedorahosted.org/fesco/ticket/1049 #topic #1050 F19 Feature: MinGW GCC 4.8 - https://fedoraproject.org/wiki/Features/MinGW_GCC_4.8 .fesco 1050 https://fedorahosted.org/fesco/ticket/1050 #topic #1051 F19 Feature: More Mobile Broadband - https://fedoraproject.org/wiki/Features/MoreMobileBroadband .fesco 1051 https://fedorahosted.org/fesco/ticket/1051 #topic #1052 F19 Feature: Multiqueue virtio-net - https://fedoraproject.org/wiki/Features/MQ_virtio_net .fesco 1052 https://fedorahosted.org/fesco/ticket/1052 #topic #1053 F19 Feature: NetworkManager Bonding Support - https://fedoraproject.org/wiki/Features/NetworkManagerBonding .fesco 1053 https://fedorahosted.org/fesco/ticket/1053 #topic #1054 F19 Feature: NetworkManager Bridging Support -
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 05/02/13 12:09 AM, Ralf Corsepius wrote: In the Gnome2 days you had choices between functionally similar DEs. Times have changed ... Gnome has been forked multiply (Gnome3, MATE, Cinammon), xfce/enlightenment are back. Gnome 3 is still Gnome. Both MATE and Cinnamon which came years after Gnome 3 via Gnome-Shell, are reactionary for self-interest because these DE can easily reproduced through Gnome-Shell extensions meaning they will become irrelevant in a future. Luya -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 2013-02-05 21:46, Ralf Corsepius wrote: On 02/05/2013 09:31 PM, Ian Malone wrote: On 5 February 2013 20:10, Alec Leamas leamas.a...@gmail.com wrote: I wouldn't say Fedora follows blindly but rather chooses an upstream from some alternatives (their ability to handle feedback from us beeing one ot the criterias). Gnome has been the default, unless I'm misremebering since *before* Fedora (RH8/9 or earlier). That's not incompatible with 'chooses an upstream from some alternatives' but does suggest some inertia. Maybe if Gnome really thinks distros might drop them they'd think harder about introducing unwanted workflow changes every other release. The actual problem is the current Gnome 3 being an entirely different product than Gnome 2, which usability-wise has *nothing* in common with Gnome2 and addresses a completely different target audience. You ordered Gnome and have been served Pizza for a long time - now you're being served Burgers :-) Ralf Well, from a nutrition perspective that's actually a big step forward. Perhaps time to trust the chef? ;) --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Tue, Feb 5, 2013 at 4:21 PM, Luya Tshimbalanga l...@fedoraproject.orgwrote: On 05/02/13 12:09 AM, Ralf Corsepius wrote: In the Gnome2 days you had choices between functionally similar DEs. Times have changed ... Gnome has been forked multiply (Gnome3, MATE, Cinammon), xfce/enlightenment are back. Gnome 3 is still Gnome. Both MATE and Cinnamon which came years after Gnome 3 via Gnome-Shell, are reactionary for self-interest because these DE can easily reproduced through Gnome-Shell extensions meaning they will become irrelevant in a future. Luya While I agree that Gnome 3 is still Gnome... it is still Gnome in the sense that Windows 8 is still just the new version of Windows. Also, years after? I first read about MATE on the Arch forums back in 2011, a few months after the final release of Gnome 3 (which was in April 2011): https://bbs.archlinux.org/viewtopic.php?id=121162 Likewise, the first post about Cinnamon on the Linux Mint website I can find was in December 2011. Unless you were referring to the Gnome 3 development cycle, I suppose. For the record, I'm pretty sure replacing Gnome 3 with Cinnamon isn't the best idea. (I think if we change the default at all it should probably be to KDE instead, but that's just me). However, let's not pretend Gnome 3 (or Gnome 3 with Gnome Shell) isn't a very different desktop environment from its predecessor, even though it is still Gnome. Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: firewalld Lockdown
On Wed, Jan 30, 2013 at 12:51:49PM +, Jaroslav Reznik wrote: This feature adds a simple configuration setting for firewalld to be able to lock down configuration changes from local applications. == Detailed description == Local applications are able to change the firewall configuration. With this feature the administator can lock the firewall configuration and these applications are not able to modify the firewall anymore. The lockdown feature is the first part of user and application policies for firewalld and will be disabled by default. Without this feature, the available changes users can make are not limited in any way, right? That is, with current firewalld, any local user can change the firewall without additional authentication? Wouldn't we want this actually enabled by default? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: the need of Offline Updates
Jochen Schmitt writes: On Tue, Feb 05, 2013 at 01:21:23PM +0100, Reindl Harald wrote: nothing would happen on a webserver with httpd if it would not be restarted at package-update which goes wrong if you are using PHP and packages of the dep-tree are not yet all updated which fails PHP to load, without the hardcoded restart httpd would happily continue to run with the old php-package from memory Question: Does it makes sense to collect all services which should be restarted during the update process and restart the services after all packages was updated? I've been doing updates via yum update forever. I never had any problems. This looks like a solution in search of a problem, to me. But if this indeed an issue, the package should take care of by itself, using its own scripts. There is even a documented way for a package to stop its services, before it gets updated, and restart it, after the update, see /var/lib/rpm-state pgpvOzZv2RZzM.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Message: 10 Date: Tue, 05 Feb 2013 13:21:03 -0800 From: Luya Tshimbalanga l...@fedoraproject.org To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Re: Proposed F19 Feature: Cinnamon as Default Desktop Message-ID: 511177bf.1020...@fedoraproject.org Content-Type: text/plain; charset=UTF-8; format=flowed On 05/02/13 12:09 AM, Ralf Corsepius wrote: In the Gnome2 days you had choices between functionally similar DEs. Times have changed ... Gnome has been forked multiply (Gnome3, MATE, Cinammon), xfce/enlightenment are back. Gnome 3 is still Gnome. Both MATE and Cinnamon which came years after Gnome 3 via Gnome-Shell, are reactionary for self-interest because these DE can easily reproduced through Gnome-Shell extensions meaning they will become irrelevant in a future. Luya Your look in a crystal ball is far away from reality like the topic himself. Pls, give more to laugh. and stay close to facts instead of posting your personal perspective. This doesn't help us really. As a former mate maintainer for fedora and very closed to mate upstream, i prefer a change to KDE now, because it is more stable than gnome-shell and has a great and stable developer base. my 10 cent, Wolfgang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: firewalld Lockdown
On Tue, 2013-02-05 at 17:20 -0500, Matthew Miller wrote: On Wed, Jan 30, 2013 at 12:51:49PM +, Jaroslav Reznik wrote: This feature adds a simple configuration setting for firewalld to be able to lock down configuration changes from local applications. == Detailed description == Local applications are able to change the firewall configuration. With this feature the administator can lock the firewall configuration and these applications are not able to modify the firewall anymore. The lockdown feature is the first part of user and application policies for firewalld and will be disabled by default. Without this feature, the available changes users can make are not limited in any way, right? That is, with current firewalld, any local user can change the firewall without additional authentication? I'm not sure that's correct, no. When I launch firewall-config I'm asked for auth. It's as my local user, but I think that's because my local user is set as an admin account. I don't believe regular (non-admin) users can modify the config. I'm willing to be wrong, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: libkkc - a new Japanese Kana Kanji input library
Daiki Ueno u...@fedoraproject.org writes: Thanks for testing. Well, when I drafted the feature page, I didn't plan to change the default without hearing the opinions from actual users of sentence-based Japanese input. But it might be good to start with a wider scope and fallback to ibus-anthy if needed. So I'll update the wiki to cover the default change. I did some performance measure of libkkc and Anthy and libkkc was significantly better[1]. So I updated the feature page to suggest the default change. Regards, Footnotes: [1] http://blog.du-a.org/?p=1004 -- Daiki Ueno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]
On Tue, Jan 29, 2013 at 9:47 PM, Miloslav Trmač m...@volny.cz wrote: Hello, just a minor point, not getting into the wider should getaddrinfo() be the primary interface debate... On Tue, Jan 29, 2013 at 4:58 AM, Nick Jones nick.fa.jo...@gmail.com wrote: As a quick summary: I would suggest, in addition to addressing the outstanding bugs and issues covered by the Fedora feature, a flag be added to the set of getaddrinfo parameters that instructs it NOT to do DNS lookups, only perform alternative resource lookups supported by nss. This flag would be something like: AI_NODNS This will allow application developers to make use of getaddrinfo for resolving names using non dns sources (hosts file is DNS, so this means ldap and others), then perform internet domain lookups using an alternative DNS library that is standardised in Fedora. That's unnecessarily difficult for the application developers. Application should have a single API to call; if they have to call two separate APIs, some of them won't. Mirek Admittedly there is a problem with adding the AI_NODNS flag, in addition to what you mentioned. That is, what happens when an application compiled to use AI_NODNS is run against an older libc. The binary interface is the same but not the behavioural interface, therefore the application will run but will perform two dns lookups. One way to get around this is by adding a versioned symbol for getaddrinfo, which is no different from the current non versioned symbol. It will be present for enforcement of runtime and rpm build time compatability. Another way is to add a new functional interface like: getnondnsaddrinfo, except with a better name, which performs non dns lookups only. Adding new interfaces to glibc is only done when necessary so a lot of justification for either would be needed, rightly so. I agree that splitting name resolution into two parts is an added complication for application developers, but I feel getaddrinfo itself is split into two of parts: - name resolution using databases such as ldap via nss - name resolution using a dns A or record lookup Making getaddrinfo and nss fully asynchronous will not happen soon, but my suggestion is to split the behaviour to allow an application to be able to resolve names from non-dns sources (which is an important function) then make use of a more modern dns resolver. The behaviour of existing binaries run against the a libc will not be changed in any way. They will continue to use getaddrinfo as they have always done. New applications will have the freedom to lookup a name using getaddrinfo first, then perform the specifically A or record lookup using a dedicated dns library that is fully asynchronous, and also supports richer dns functionality, thus can be re-used for other purposes. Nick -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
On Wed, Feb 06, 2013 at 02:36:36AM +0100, Andrea Pescetti wrote: Miloslav Trmač wrote: On Mon, Feb 4, 2013 at 7:31 AM, David Tardon wrote: On Sun, Feb 03, 2013 at 11:26:35PM -0600, Chris Adams wrote: $ rpm -ql libreoffice-core | grep bin/ | xargs ls -ld -rwxr-xr-x. 1 root root 362 Dec 6 18:37 /usr/bin/libreoffice -rwxr-xr-x. 1 root root 32 Dec 6 18:37 /usr/bin/ooffice -rwxr-xr-x. 1 root root 39 Dec 6 18:37 /usr/bin/ooviewdoc lrwxrwxrwx. 1 root root 11 Jan 9 12:46 /usr/bin/openoffice.org - libreoffice lrwxrwxrwx. 1 root root 38 Jan 9 12:46 /usr/bin/soffice - /usr/lib64/libreoffice/program/soffice -rwxr-xr-x. 1 root root 360 Dec 6 18:37 /usr/bin/unopkg There is also /usr/bin/oowriter, oocalc, ooimpress, oodraw and oobase that belong to other libreoffice-* subpackages. The feature page only discusses the soffice link; what does the feature propose to do about the other conflicting files in /usr/bin? As Stephan wrote, soffice is the main problem (and I wonder if unopkg is in the same situation or is not problematic). unopkg is in the same situation, of course. I would find it just reasonable that openoffice.org and the oo* launchers are kept free for Apache OpenOffice. Using the aoo* convention for OpenOffice is not common: executables from other Apache projects are not prefixed with an a (i.e., Fedora doesn't have ahttpd, asvn and so on). That is not a technical argument, either. Apache OpenOffice is the newcomer to the distribution, so IMHO it is your responsibility to resolve any clashes with already present components (in this case by renaming the executables or not installing them). It would not be the first case of that in Fedora. LibreOffice modules could reasonably adopt the lo* convention to reflect the current naming. Anyway, this is common sense rather than a source of package conflict, so if there are technical arguments against this we can surely discuss further. Sorry, but I do not want having to explain to users (and bug reporters) why running ooffice (oowriter,...) on command line suddenly fails because the executable does not exist. D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Feb 04, 2013 at 03:03:08PM +0100, Kay Sievers wrote: On Thu, Jan 31, 2013 at 2:45 PM, Scott Schmit wrote: Current: em1 - enp2s0 That is expected, and actually the right thing to do. Udev cannot apply such it looks like it is embedded heuristics for very practical technical reasons. There is no reliable information about that on the system, so this logic will break sooner or later. There is also no sane way to share the namespace with the embedded interface indices defined by the firmware. It should never have been done by biosdevname that way. em2 - eno1 em3 - eno2 Ouch, is that really the case? If that's what you see on your box, then biosdevname would have invented its own numbers for the *fixed* SMBIOS provided index numbers, and rebased them to something different. That would be really weird. This isn't a real life example, this was just an example of something I could imagine happening that would screw people up, based on what I thought I understood from the list (even your response to the first part implies that some machines could have real embedded devices mixed with pseudo-embedded devices, but your response to the second implies otherwise, so I don't know what to make of that...). Is there a program/script we can run that would tell us what the interface names would be without biosdevname (without running the new version of systemd on the box)? Not that that would tell me what to expect for other people, but I suppose if a bunch of people looked at what it did to their box(es) and somebody saw something surprising, they could speak up. (Assuming they knew what surprising looked like...) :-) -- Scott Schmit smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 907464] cpanm bundle lots of library and is not listed on fesco page
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=907464 --- Comment #3 from Marcela Mašláňová mmasl...@redhat.com --- Filed as: https://fedorahosted.org/fpc/ticket/250 I wonder if the wiki is checked by security team for possible CVEs. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=iGrdhouJrJa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 907775] New: overload arg '+0' is invalid at /usr/share/perl5/vendor_perl/Mail/Message/Field.pm line 29.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=907775 Bug ID: 907775 Summary: overload arg '+0' is invalid at /usr/share/perl5/vendor_perl/Mail/Message/Field.pm line 29. Product: Fedora Version: 18 Component: perl-Mail-Box Severity: low Priority: low Reporter: rbink...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=WF3tUUYCKza=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 907775] overload arg '+0' is invalid at /usr/share/perl5/vendor_perl/Mail/Message/Field.pm line 29.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=907775 Robert Binkhorst rbink...@redhat.com changed: What|Removed |Added Comment #0 is|1 |0 private|| -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=XmOJQ6dSA7a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File GStreamer-0.18.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-GStreamer: 7ac748677f00d1fd966b09e10448cff6 GStreamer-0.18.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-GStreamer] 0.18 bump
commit 063537c073c6308544d6260b324aa75ccd6fefb3
Author: Petr Písař ppi...@redhat.com
Date: Tue Feb 5 11:04:41 2013 +0100
0.18 bump
.gitignore |1 +
perl-GStreamer.spec | 24
sources |2 +-
3 files changed, 18 insertions(+), 9 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 3190c99..dffdb0e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
GStreamer-0.15.tar.gz
/GStreamer-0.16.tar.gz
/GStreamer-0.17.tar.gz
+/GStreamer-0.18.tar.gz
diff --git a/perl-GStreamer.spec b/perl-GStreamer.spec
index 2387be7..e304fa5 100644
--- a/perl-GStreamer.spec
+++ b/perl-GStreamer.spec
@@ -1,26 +1,32 @@
Name: perl-GStreamer
-Version:0.17
-Release:3%{?dist}
+Version:0.18
+Release:1%{?dist}
Summary:Perl bindings to the GStreamer framework
License:LGPLv2+
Group: Development/Libraries
URL:http://search.cpan.org/dist/GStreamer/
Source0:
http://www.cpan.org/authors/id/X/XA/XAOC/GStreamer-%{version}.tar.gz
-BuildRequires: gstreamer-devel
+BuildRequires: gstreamer-devel = 0.10.0
+BuildRequires: perl
+BuildRequires: perl(Cwd)
BuildRequires: perl(ExtUtils::Depends) = 0.205
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(ExtUtils::PkgConfig) = 1.07
+BuildRequires: perl(Glib) = 1.180
+BuildRequires: perl(Glib::CodeGen)
BuildRequires: perl(Glib::MakeHelper)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
# Run-time
BuildRequires: perl(constant)
BuildRequires: perl(DynaLoader)
BuildRequires: perl(Exporter)
-BuildRequires: perl(Glib) = 1.180
+BuildRequires: perl(overload)
# Tests
BuildRequires: gstreamer-plugins-base
BuildRequires: perl(File::Spec)
BuildRequires: perl(Test::More)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%{?perl_default_filter}
@@ -35,14 +41,13 @@ the programmer from any memory management and object
casting hassles.
%setup -q -n GStreamer-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags}
+perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags}
make %{?_smp_mflags}
%install
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
+make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f {} \;
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} %{buildroot}/*
%check
@@ -58,6 +63,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Feb 05 2013 Petr Pisar ppi...@redhat.com - 0.18-1
+- 0.18 bump
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.17-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
diff --git a/sources b/sources
index f0f14ab..563f682 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8fe097daf0e2534452a3f69af05ec9fd GStreamer-0.17.tar.gz
+7ac748677f00d1fd966b09e10448cff6 GStreamer-0.18.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 907382] perl-GStreamer-0.18 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=907382 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-GStreamer-0.18-1.fc19 Resolution|--- |RAWHIDE Last Closed||2013-02-05 05:24:24 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=X8M4yadxYPa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 907704] Use the plain `perl` command instead of the `%{_perl}` macro in generated specfiles
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=907704
Petr Pisar ppi...@redhat.com changed:
What|Removed |Added
CC||ppi...@redhat.com
--- Comment #2 from Petr Pisar ppi...@redhat.com ---
Main packaging guidelines discourage using macros for plain commands
https://fedoraproject.org/wiki/Packaging:Guidelines#Macros:
Macro forms of system executables SHOULD NOT be used except when there is a
need to allow the location of those executables to be configurable. For
example, rm should be used in preference to %{__rm}, but %{__python} is
acceptable.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=788T2UeKFMa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 907797] perl-Pod-Parser-1.60 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=907797 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Blocks||907546 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=hcy0n1D6BUa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 907797] perl-Pod-Parser-1.60 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=907797 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Depends On||907550 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=9DU1riedOoa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 907704] Use the plain `perl` command instead of the `%{_perl}` macro in generated specfiles
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=907704
Ralf Corsepius rc040...@freenet.de changed:
What|Removed |Added
CC||rc040...@freenet.de
--- Comment #3 from Ralf Corsepius rc040...@freenet.de ---
(In reply to comment #2)
Main packaging guidelines discourage using macros for plain commands
https://fedoraproject.org/wiki/Packaging:Guidelines#Macros:
Macro forms of system executables SHOULD NOT be used except when there is a
need to allow the location of those executables to be configurable. For
example, rm should be used in preference to %{__rm}, but %{__python} is
acceptable.
a) %__perl is in a similar position as %__python.
b) The wording SHOULD NOT means %__perl or other macros are _allowed_
= It's up to a packager's discretion to use it or not. I encourage people to
use it and consider people enforcing plain perl to commit a mistake.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=a7BSOVxyBSa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Pod-Usage-1.60.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Pod-Usage: 71b2e69a2334d6fbedc835eea0d9b1e1 Pod-Usage-1.60.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Pod-Usage] Import
commit fb1fd3cb4e12bcc423a4c3505cada625a391c258
Author: Petr Písař ppi...@redhat.com
Date: Tue Feb 5 15:40:47 2013 +0100
Import
.gitignore |1 +
perl-Pod-Usage.spec | 73 +++
sources |1 +
3 files changed, 75 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..adbaa38 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Pod-Usage-1.60.tar.gz
diff --git a/perl-Pod-Usage.spec b/perl-Pod-Usage.spec
new file mode 100644
index 000..b32df1d
--- /dev/null
+++ b/perl-Pod-Usage.spec
@@ -0,0 +1,73 @@
+Name: perl-Pod-Usage
+Version:1.60
+Release:1%{?dist}
+Summary:Print a usage message from embedded pod documentation
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Pod-Usage/
+Source0:
http://www.cpan.org/authors/id/M/MA/MAREKR/Pod-Usage-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Spec)
+# Run-time:
+BuildRequires: perl(Carp)
+BuildRequires: perl(Config)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(Pod::Select)
+# Pod::Usage executes perldoc from perl-Pod-Perldoc by default
+BuildRequires: perl-Pod-Perldoc
+BuildRequires: perl(Pod::Text)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+# Tests:
+BuildRequires: perl(Cwd)
+BuildRequires: perl(File::Basename)
+BuildRequires: perl(FileHandle)
+BuildRequires: perl(Test::More)
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+# Pod::Usage executes perldoc from perl-Pod-Perldoc by default
+Requires: perl-Pod-Perldoc
+Requires: perl(Pod::Text)
+
+%description
+pod2usage will print a usage message for the invoking script (using its
+embedded POD documentation) and then exit the script with the desired exit
+status. The usage message printed may have any one of three levels of
+verboseness: If the verbose level is 0, then only a synopsis is printed.
+If the verbose level is 1, then the synopsis is printed along with a
+description (if present) of the command line options and arguments. If the
+verbose level is 2, then the entire manual page is printed.
+
+%prep
+%setup -q -n Pod-Usage-%{version}
+find -type f -exec chmod a-x {} +
+for F in CHANGES README; do
+sed -i -e 's/\r//' $F
+done
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+# pod2usage.t fails currently, CPAN RT #83111
+rm -f t/pod/pod2usage.t
+make test
+
+%files
+%doc CHANGES README
+%{_bindir}/*
+%{perl_vendorlib}/*
+%{_mandir}/man1/*
+%{_mandir}/man3/*
+
+%changelog
+* Mon Feb 04 2013 Petr Pisar ppi...@redhat.com 1.60-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..30b564d 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+71b2e69a2334d6fbedc835eea0d9b1e1 Pod-Usage-1.60.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Pod-Usage] Clean-up requested by review
commit c1e3bda7d28ae04023494f30814a7fd4672f0c1b
Author: Petr Písař ppi...@redhat.com
Date: Tue Feb 5 15:41:23 2013 +0100
Clean-up requested by review
perl-Pod-Usage.spec |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
---
diff --git a/perl-Pod-Usage.spec b/perl-Pod-Usage.spec
index b32df1d..66a5c65 100644
--- a/perl-Pod-Usage.spec
+++ b/perl-Pod-Usage.spec
@@ -53,7 +53,6 @@ make %{?_smp_mflags}
%install
make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Pod-Parser] 1.60 bump
commit c832df027bfc9a63e7c79a29cc5803d8d5a93cda
Author: Petr Písař ppi...@redhat.com
Date: Tue Feb 5 16:15:40 2013 +0100
1.60 bump
.gitignore |1 +
perl-Pod-Parser.spec | 87 -
sources |2 +-
3 files changed, 24 insertions(+), 66 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index f30a03c..25f9cb2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Pod-Parser-1.51.tar.gz
+/Pod-Parser-1.60.tar.gz
diff --git a/perl-Pod-Parser.spec b/perl-Pod-Parser.spec
index e182aba..727e124 100644
--- a/perl-Pod-Parser.spec
+++ b/perl-Pod-Parser.spec
@@ -1,6 +1,6 @@
Name: perl-Pod-Parser
-Version:1.51
-Release:248%{?dist}
+Version:1.60
+Release:1%{?dist}
Summary:Basic perl modules for handling Plain Old Documentation (POD)
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,55 +8,26 @@ URL:http://search.cpan.org/dist/Pod-Parser/
Source0:
http://www.cpan.org/authors/id/M/MA/MAREKR/Pod-Parser-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
-# Run-time
+# Run-time:
BuildRequires: perl(Carp)
BuildRequires: perl(Cwd)
BuildRequires: perl(Exporter)
BuildRequires: perl(File::Spec)
# Tests:
BuildRequires: perl(Test::More) = 0.6
+%if !%{defined perl_bootstrap}
+# Break circular dependency Pod::Checker - Pod::Parser
+BuildRequires: perl(Pod::Checker) = 1.40
+# Break circular dependency Pod::Usage - Pod::Select
+BuildRequires: perl(Pod::Usage)
+%endif
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-# Filter under-specified depenedencies
-%global __requires_exclude
%{?__requires_exclude|%__requires_exclude|}^perl\\(Pod::Parser\\)$
-
%description
This software distribution contains the packages for using Perl5 POD (Plain
Old Documentation). See the perlpod and perlsyn manual pages from your
Perl5 distribution for more information about POD.
-%package -n perl-Pod-Checker
-Summary:Check POD documents for syntax errors
-License:GPL+ or Artistic
-Group: Development/Libraries
-Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-Conflicts: perl-Pod-Parser 1.51-248
-
-%description -n perl-Pod-Checker
-Module and tools to verify POD documentation contents for compliance with the
-Plain Old Documentation format specifications.
-
-%package -n perl-Pod-Usage
-Summary:Print a usage message from embedded pod documentation
-License:GPL+ or Artistic
-Group: Development/Libraries
-# Pod::Usage execute perldoc from perl-Pod-Perldoc by default
-BuildRequires: perl-Pod-Perldoc
-Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-# Pod::Usage executes perldoc from perl-Pod-Perldoc by default
-Requires: perl-Pod-Perldoc
-Requires: perl(Pod::Text)
-Conflicts: perl-Pod-Parser 1.51-248
-
-%description -n perl-Pod-Usage
-pod2usage will print a usage message for the invoking script (using its
-embedded POD documentation) and then exit the script with the desired exit
-status. The usage message printed may have any one of three levels of
-verboseness: If the verbose level is 0, then only a synopsis is printed.
-If the verbose level is 1, then the synopsis is printed along with a
-description (if present) of the command line options and arguments. If the
-verbose level is 2, then the entire manual page is printed.
-
%prep
%setup -q -n Pod-Parser-%{version}
find -type f -exec chmod -x {} +
@@ -77,42 +48,28 @@ find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {}
\;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
+%if %{defined perl_bootstrap}
+# Break circular dependency Pod::Usage - Pod::Select
+rm -f t/pod/headings.t
+%endif
make test
%files
%doc ANNOUNCE CHANGES README TODO
-%{_bindir}/*
+%if %{defined perl_bootstrap}
+# Break circular dependency Pod::Usage - Pod::Select
+%exclude %{_bindir}/podselect
+%else
+%{_bindir}/podselect
+%endif
%{perl_vendorlib}/*
%{_mandir}/man1/*
%{_mandir}/man3/*
-# Pod-Checker
-%exclude %{_bindir}/podchecker
-%exclude %{perl_vendorlib}/Pod/Checker.pm
-%exclude %{_mandir}/man1/podchecker.*
-%exclude %{_mandir}/man3/Pod::Checker.*
-
-# Pod-Usage
-%exclude %{_bindir}/pod2usage
-%exclude %{perl_vendorlib}/Pod/Usage.pm
-%exclude %{_mandir}/man1/pod2usage.*
-%exclude %{_mandir}/man3/Pod::Usage.*
-
-%files -n perl-Pod-Checker
-%doc ANNOUNCE CHANGES README TODO
-%{_bindir}/podchecker
-%{perl_vendorlib}/Pod/Checker.pm
-%{_mandir}/man1/podchecker.*
-%{_mandir}/man3/Pod::Checker.*
-
-%files -n perl-Pod-Usage
-%doc ANNOUNCE CHANGES README TODO
-%{_bindir}/pod2usage
-%{perl_vendorlib}/Pod/Usage.pm
-%{_mandir}/man1/pod2usage.*
-%{_mandir}/man3/Pod::Usage.*
-
%changelog
+* Tue Feb 05 2013 Petr Pisar ppi...@redhat.com - 1.60-1
+- 1.60 bump
+
* Mon Feb 04 2013 Petr Pisar ppi...@redhat.com - 1.51-248
- Sub-package
[perl-Module-ScanDeps] Revert to using bundled Module::Install
commit a7172818a77bf77a3c14be93022ac0bcc4d37380
Author: Paul Howarth p...@city-fan.org
Date: Tue Feb 5 15:15:32 2013 +
Revert to using bundled Module::Install
- Revert to using bundled Module::Install to avoid build dependency cycles
(#906007
perl-Module-ScanDeps.spec | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
---
diff --git a/perl-Module-ScanDeps.spec b/perl-Module-ScanDeps.spec
index 2743f2a..daa0482 100644
--- a/perl-Module-ScanDeps.spec
+++ b/perl-Module-ScanDeps.spec
@@ -1,14 +1,13 @@
Name: perl-Module-ScanDeps
Summary:Recursively scan Perl code for dependencies
Version:1.10
-Release:1%{?dist}
+Release:2%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/R/RS/RSCHUPP/Module-ScanDeps-%{version}.tar.gz
URL:http://search.cpan.org/dist/Module-ScanDeps/
BuildArch: noarch
-BuildRequires: perl(inc::Module::Install) = 1.00
# Run-time:
BuildRequires: perl(B)
BuildRequires: perl(Config)
@@ -38,7 +37,6 @@ Requires: perl(:MODULE_COMPAT_%(eval `%{__perl}
-V:version`; echo $versi
Requires: perl(Encode)
Requires: perl(File::Find)
-
%{?perl_default_filter}
%description
@@ -48,9 +46,6 @@ Test/More.pm). The values are hash references.
%prep
%setup -q -n Module-ScanDeps-%{version}
-# Remove bundled modules
-rm -rf inc/*
-sed -i '/^inc\//d' MANIFEST
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -72,6 +67,10 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Feb 5 2013 Paul Howarth p...@city-fan.org - 1.10-2
+- Revert to using bundled Module::Install to avoid build dependency cycles
+ (#906007)
+
* Tue Oct 23 2012 Petr Pisar ppi...@redhat.com - 1.10-1
- 1.10 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
