Re: how reload udev rules and systemd on F18
On 02/05/2013 07:43 PM, Sérgio Basto wrote: Any advises or opinions ? I think you haven't yet described the original problem you're trying to solve. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps for Node.js stuff
On 07/02/13 21:33, Stephen Gallagher wrote: On Thu 07 Feb 2013 02:26:48 PM EST, Jamie Nguyen wrote: On 07/02/13 19:24, Jamie Nguyen wrote: Now that I'm a bit more familiar with node.js packaging (ie, never even looked at node.js before this week...), I'll take it. I don't currently have any packages for you to review, so you get off scot-free. Well, for now at least ;) Oops, looks like Stephen beat me to it by 30 minutes :) I took care of the high-priority one, but by all means, please dig into the nodejs-tap dependency chain. As T.C. says, that will make it easier to test and validate future reviews. Will do. I'm currently packaging a tonne of deps for buddycloud, so many review swaps may be imminent! -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Fri, 08 Feb 2013 07:47:48 +0100 Ralf Corsepius rc040...@freenet.de wrote: On 02/06/2013 08:42 AM, Stijn Hoop wrote: On Tue, 05 Feb 2013 21:46:32 +0100 Ralf Corsepius rc040...@freenet.de wrote: 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. Ralf, could you please stop this generalization. You have been conveniently ignoring posts to the contrary, including mine. Sorry, I don't see what I am generalizing. Gnome3 and Gnome2's GUI working principles are entirely different and therefore are catering the demands of different target audiences. They are similarly different as WinXP and Android are different in their GUIs' working principles. I can not help you if do not understand what I am talking about. Ralf I am providing a datapoint that directly contradicts your original statement, namely that there is a completely different target audience for GNOME 2 vs GNOME 3. I am that datapoint. I know that it is my anecdata, but I am pretty sure that I have not yet read any actual facts supporting your side of the argument as well. Furthermore I am pretty sure that I am not the only one enjoying GNOME 3, while having enjoyed GNOME 2, having read the other posts in this thread. Hopefully that is clearer, regards, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.53 in Rawhide
On 02/08/2013 03:56 AM, Kevin Fenzi wrote: On Fri, 08 Feb 2013 02:57:19 +0100 Petr Machata pmach...@redhat.com wrote: I have just built boost 1.53. I didn't go through the side tag as originally envisioned, as tomorrow's mass rebuild should take care of it all in one fell swoop. I'll still be available for help if your package mysteriously fails or if there's just too many 's and 's in your package for a sane person to wrap their head around. Dennis is traveling right now, so it looks like the mass rebuild may be pushed off to the 12th. Do we want to untag this until then? Or is it going to cause broken deps? The mass rebuild doesn't do rebuilds in the dep order, it just goes through all the packages alphabetically. With packages using boost, there are often long dep chains that need rebuilding in the dep order. I would say that it still needs some provenpackager action to get the rebuilds done. Petr, are you a provenpackager now? In my opinion, it would be perfect to have the gist of the boost rebuilds completed by the time of the mass rebuild. Boost has not only shared libraries, but also a lot of header-only template code. When provenpackagers do rebuilds, they usually take care of the broken library deps, but nobody rebuilds packages that only use the template code. If we manage to complete the library rebuilds by the time of the 12th, then the mass rebuilds would also take care of doing the rest of the rebuilds, to ensure that all packages are really using new boost 1.53 template code. -- Hope this helps, Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Mass Rebuild for Fedora 19
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 it was requested in https://fedorahosted.org/fesco/ticket/1004 that we do a mass rebuild for Fedora 19 for http://fedoraproject.org/wiki/Features/GCC48 Additionally we will be mass patching config.guess and config.sub to support aarch64 in preperation for 64 bit arm support we will start the mass rebuild on 2013-02-12 This is a heads up that it will be done in a side tag and moved over when completed. We will be running scripts to output failure stats. please be sure to let releng know if you see any bugs in the reporting. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlEUx/4ACgkQkSxm47BaWffzcQCggHykVzb0MlCY+sXoHsbjbQxm aVgAnjTb32kw6gmXTwlrIxhnU+N2YHkD =fj3Q -END PGP SIGNATURE- ___ 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: boost 1.53 in Rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Fri, 08 Feb 2013 10:41:29 +0100 Kalev Lember kalevlem...@gmail.com escribió: On 02/08/2013 03:56 AM, Kevin Fenzi wrote: On Fri, 08 Feb 2013 02:57:19 +0100 Petr Machata pmach...@redhat.com wrote: I have just built boost 1.53. I didn't go through the side tag as originally envisioned, as tomorrow's mass rebuild should take care of it all in one fell swoop. I'll still be available for help if your package mysteriously fails or if there's just too many 's and 's in your package for a sane person to wrap their head around. Dennis is traveling right now, so it looks like the mass rebuild may be pushed off to the 12th. Do we want to untag this until then? Or is it going to cause broken deps? The mass rebuild doesn't do rebuilds in the dep order, it just goes through all the packages alphabetically. With packages using boost, there are often long dep chains that need rebuilding in the dep order. I would say that it still needs some provenpackager action to get the rebuilds done. Petr, are you a provenpackager now? In my opinion, it would be perfect to have the gist of the boost rebuilds completed by the time of the mass rebuild. Boost has not only shared libraries, but also a lot of header-only template code. When provenpackagers do rebuilds, they usually take care of the broken library deps, but nobody rebuilds packages that only use the template code. If we manage to complete the library rebuilds by the time of the 12th, then the mass rebuilds would also take care of doing the rest of the rebuilds, to ensure that all packages are really using new boost 1.53 template code. As Kalev said the mass rebuild happens alphabetically, additionally the results of the mass rebuild are not tagged into the buildroot. The process is not designed to deal with soname bumps. If you can get it done before the 12th then please do so. if not you will need to wait until after the mass rebuild and use a side tag. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlEUzdIACgkQkSxm47BaWfdrVgCgjtHE5RCYkd72Zgya0DniotJT jiMAmwcztwaWMJ1XyNT1Eo9XCTy/Q+OU =UMO5 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps for Node.js stuff
Quoting Jamie Nguyen (2013-02-08 10:12:12) On 07/02/13 21:33, Stephen Gallagher wrote: On Thu 07 Feb 2013 02:26:48 PM EST, Jamie Nguyen wrote: On 07/02/13 19:24, Jamie Nguyen wrote: Now that I'm a bit more familiar with node.js packaging (ie, never even looked at node.js before this week...), I'll take it. I don't currently have any packages for you to review, so you get off scot-free. Well, for now at least ;) Oops, looks like Stephen beat me to it by 30 minutes :) I took care of the high-priority one, but by all means, please dig into the nodejs-tap dependency chain. As T.C. says, that will make it easier to test and validate future reviews. Will do. I'm currently packaging a tonne of deps for buddycloud, so many review swaps may be imminent! Ah, buddycloud in Fedora? Cool. I'll have to try it out one day :-) -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps for Node.js stuff
On 08/02/13 10:52, Stanislav Ochotnicky wrote: Will do. I'm currently packaging a tonne of deps for buddycloud, so many review swaps may be imminent! Ah, buddycloud in Fedora? Cool. I'll have to try it out one day :-) Hopefully one day is going to be reasonably soon :) There are quite a few nodejs new package reviews that still need to be done (which I'll be working on trying to review), and I'll be opening something like 30+ new package reviews myself. I've now discovered the hell that is nodejs packaging, which is almost as painful as rubygems packaging, complete with vast arrays of specific versioned dependencies... -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boost 1.53 in Rawhide
Kevin Fenzi ke...@scrye.com writes: On Fri, 08 Feb 2013 02:57:19 +0100 Petr Machata pmach...@redhat.com wrote: Hi there, I have just built boost 1.53. I didn't go through the side tag as originally envisioned, as tomorrow's mass rebuild should take care of it all in one fell swoop. I'll still be available for help if your package mysteriously fails or if there's just too many 's and 's in your package for a sane person to wrap their head around. Dennis is traveling right now, so it looks like the mass rebuild may be pushed off to the 12th. Do we want to untag this until then? Or is it going to cause broken deps? FYI (Y as in wider community), Kevin went ahead and did that, which is fine by me. You can still find the relevant RPMs in koji if you are interested in trying out 1.53 before the real thing lands. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Package shipping their own CA and security
Hi, a few days ago, the topic of package shipping their own ssl CA bundle was discussed on irc with kiilerix, and the discussion prompted me to add some code to rpmlint to warn people about it. In short, shipping a private key, or a .pem is highly suspicious. For a private key to be used as default configuration, the reason is obvious, ie it is no longer private if you can find several copy everywhere, and provides a false sense of security. For a certificate, that's slightly more subtle. A certificate alone in a package cannot do much. If there is no private key, then it cannot be used out of the box, except for client side validation ( afaik ). So all .pam certificates we can find would be used to validate another ssl certificates. That's where it start to be funny and security related, because the whole certificate authority idea requires update to be kept secure ( for exemple, when a CA was compromised, like DigiNotar, Trustwave ). And that's something we may not really watch. So this bring the question of : should we do something about it ? There is more than 1 approach : - ban all certificates if used to validate something. That mean patching and could be not practical. We try to not deviate from upstream too much, so that's a while wide scale project. That also mean some code audit, and while it is not a hard tasks, this still requires to read code in various languages. And Fedora may not be the right place for that. - list all problematic packages on a wiki. This way, if a certificate is to be removed, someone can check and open the bug. I imagine that the command to check the certificate should be documented on the wiki, as well as the last audit time. - do nothing. Security is sometime about balance between convenience and the risk. Certificate once revoked by mozilla/google/apple/etc are likely to be unused, so we can guess as a side effect that no one will use the compromised certificate anymore. I would propose to have prop 2 for the short term, and start thinking about prop 1. Prop 1 would need a rpmlint check ( done, but to be completed with other extensions ), and a FPC/Fesco approval. Then once approved as a general idea, decide on the detail, ie what to do, listing ( where ), fixing ( how ), etc, etc. We cannot automate that test, since private key and certificates are often used in tests suite. And as long as this is just used for testing purpose, the certificate should be ok. If people want to look at affected packages, there is # yum whatprovides '*pem' You can see gajim, some python/ruby modules, etc. Another good way is: # yum whatprovides '*cacert* But one side issue is that upstreams can be quite creative in the way they store and name the CA bundle. What triggered to write this mail is review 902503, where I was not able to find a way to inspect the cacert.p7s. I am not able to decipher openssl man pages to do anything with that file ( as a side note, if someone can tell me how to list certificate there, I would love to know ). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package shipping their own CA and security
On 02/08/2013 12:41 PM, Michael Scherer wrote: For a certificate, that's slightly more subtle. A certificate alone in a package cannot do much. If there is no private key, then it cannot be used out of the box, except for client side validation ( afaik ). So all .pam certificates we can find would be used to validate another ssl certificates. Embedding a certificate in a RPM is fine because we can handle revocation/key rollover through an RPM update—especially if it's not a configuration file. We might eventually get a better mechanism, but until that happens, it's not so bad. (This assumes that we own the certificate in question. Obviously, it won't do to download the certificate from the Internet, bake it in, and hope that it won't change until it expires. That's just not going to work.) -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package shipping their own CA and security
On 02/08/2013 12:58 PM, Reindl Harald wrote: Am 08.02.2013 12:54, schrieb Florian Weimer: On 02/08/2013 12:41 PM, Michael Scherer wrote: For a certificate, that's slightly more subtle. A certificate alone in a package cannot do much. If there is no private key, then it cannot be used out of the box, except for client side validation ( afaik ). So all .pam certificates we can find would be used to validate another ssl certificates. Embedding a certificate in a RPM is fine because we can handle revocation/key rollover through an RPM update—especially if it's not a configuration file. We might eventually get a better mechanism, but until that happens, it's not so bad. (This assumes that we own the certificate in question. Obviously, it won't do to download the certificate from the Internet, bake it in, and hope that it won't change until it expires. That's just not going to work.) it is NOT fine, it is just stupid the certificate is broken after that any random guy out there can missuse it and your users which trust the certificate are Please mind your language. Evidently, we are not talking about the same thing. I was referring to server certificates baked in to clients, in case this wasn't clear. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package shipping their own CA and security
Le 08/02/2013 12:41, Michael Scherer a écrit : Hi, a few days ago, the topic of package shipping their own ssl CA bundle was discussed on irc with kiilerix, and the discussion prompted me to add some code to rpmlint to warn people about it. In short, shipping a private key, or a .pem is highly suspicious. For a private key to be used as default configuration, the reason is obvious, ie it is no longer private if you can find several copy everywhere, and provides a false sense of security. For a certificate, that's slightly more subtle. A certificate alone in a package cannot do much. If there is no private key, then it cannot be used out of the box, except for client side validation ( afaik ). So all .pam certificates we can find would be used to validate another ssl certificates. That's where it start to be funny and security related, because the whole certificate authority idea requires update to be kept secure ( for exemple, when a CA was compromised, like DigiNotar, Trustwave ). And that's something we may not really watch. So this bring the question of : should we do something about it ? Good concern, we should take care of that issue. There is more than 1 approach : - ban all certificates if used to validate something. That mean patching and could be not practical. We try to not deviate from upstream too much, so that's a while wide scale project. That also mean some code audit, and while it is not a hard tasks, this still requires to read code in various languages. And Fedora may not be the right place for that. At the very least, it should require an exception from fesco and be documented in the spec file. - list all problematic packages on a wiki. This way, if a certificate is to be removed, someone can check and open the bug. I imagine that the command to check the certificate should be documented on the wiki, as well as the last audit time. +1 - do nothing. Security is sometime about balance between convenience and the risk. Certificate once revoked by mozilla/google/apple/etc are likely to be unused, so we can guess as a side effect that no one will use the compromised certificate anymore. everyone should agree that it's not even an option I would propose to have prop 2 for the short term, and start thinking about prop 1. Prop 1 would need a rpmlint check ( done, but to be completed with other extensions ), and a FPC/Fesco approval. Then once approved as a general idea, decide on the detail, ie what to do, listing ( where ), fixing ( how ), etc, etc. We cannot automate that test, since private key and certificates are often used in tests suite. And as long as this is just used for testing purpose, the certificate should be ok. If people want to look at affected packages, there is # yum whatprovides '*pem' You can see gajim, some python/ruby modules, etc. Another good way is: # yum whatprovides '*cacert* But one side issue is that upstreams can be quite creative in the way they store and name the CA bundle. Maybe we could add this item to the package review checklist (yes, reviewers are already supposed to go through every files during the review for licensing and library bundling issues at least) What triggered to write this mail is review 902503, where I was not able to find a way to inspect the cacert.p7s. I am not able to decipher openssl man pages to do anything with that file ( as a side note, if someone can tell me how to list certificate there, I would love to know ). best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Fri, Feb 08, 2013 at 10:34:58AM +0100, Stijn Hoop wrote: I am providing a datapoint that directly contradicts your original statement, namely that there is a completely different target audience for GNOME 2 vs GNOME 3. I am that datapoint. As are various others during FOSDEM (Vincent Untz asked people to raise their hands). No idea how representative that it. Also people who didn't like it, etc. As said during that presentation, figuring out if something is felt by either a small focal minority or that it is generic (representative) is pretty difficult and anyone is of course feel free to assist. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Fri, Feb 8, 2013 at 7:47 AM, Ralf Corsepius rc040...@freenet.de wrote: On 02/06/2013 08:42 AM, Stijn Hoop wrote: On Tue, 05 Feb 2013 21:46:32 +0100 Ralf Corsepius rc040...@freenet.de wrote: 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. Ralf, could you please stop this generalization. You have been conveniently ignoring posts to the contrary, including mine. Sorry, I don't see what I am generalizing. Gnome3 and Gnome2's GUI working principles are entirely different and therefore are catering the demands of different target audiences. Citation needed for implication is different - catering the demands of different target audiences . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package shipping their own CA and security
On Fri, 2013-02-08 at 12:41 +0100, Michael Scherer wrote: Hi, a few days ago, the topic of package shipping their own ssl CA bundle was discussed on irc with kiilerix, and the discussion prompted me to add some code to rpmlint to warn people about it. In short, shipping a private key, or a .pem is highly suspicious. For a private key to be used as default configuration, the reason is obvious, ie it is no longer private if you can find several copy everywhere, and provides a false sense of security. For a certificate, that's slightly more subtle. A certificate alone in a package cannot do much. If there is no private key, then it cannot be used out of the box, except for client side validation ( afaik ). So all .pam certificates we can find would be used to validate another ssl certificates. That's where it start to be funny and security related, because the whole certificate authority idea requires update to be kept secure ( for exemple, when a CA was compromised, like DigiNotar, Trustwave ). And that's something we may not really watch. So this bring the question of : should we do something about it ? There is more than 1 approach : - ban all certificates if used to validate something. That mean patching and could be not practical. We try to not deviate from upstream too much, so that's a while wide scale project. That also mean some code audit, and while it is not a hard tasks, this still requires to read code in various languages. And Fedora may not be the right place for that. - list all problematic packages on a wiki. This way, if a certificate is to be removed, someone can check and open the bug. I imagine that the command to check the certificate should be documented on the wiki, as well as the last audit time. - do nothing. Security is sometime about balance between convenience and the risk. Certificate once revoked by mozilla/google/apple/etc are likely to be unused, so we can guess as a side effect that no one will use the compromised certificate anymore. I would propose to have prop 2 for the short term, and start thinking about prop 1. Prop 1 would need a rpmlint check ( done, but to be completed with other extensions ), and a FPC/Fesco approval. Then once approved as a general idea, decide on the detail, ie what to do, listing ( where ), fixing ( how ), etc, etc. We cannot automate that test, since private key and certificates are often used in tests suite. And as long as this is just used for testing purpose, the certificate should be ok. If people want to look at affected packages, there is # yum whatprovides '*pem' You can see gajim, some python/ruby modules, etc. Another good way is: # yum whatprovides '*cacert* But one side issue is that upstreams can be quite creative in the way they store and name the CA bundle. What triggered to write this mail is review 902503, where I was not able to find a way to inspect the cacert.p7s. I am not able to decipher openssl man pages to do anything with that file ( as a side note, if someone can tell me how to list certificate there, I would love to know ). The cacert.p7s is just S/MIME signed bundle of X.509 CA certificates in the PEM format - you can manually separate them out of the file and I suppose the bundle should be directly usable instead of the /etc/pki/tls/certs/ca-bundle.crt. I did not inspect what individual CA certificates it contains but I am almost 100% sure that this should not be shipped and the package patched so the default system CA certificate bundle is used instead. Shipping extra CA bundle would make sense only in case it was for some kind of special purpose application where the servers do not use the regularly trusted CAs but some special ones. -- 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
Non-responsive Maintainer: mediawiki
The mediawiki package is severely outdated. I have attempted to contact the maintainer and received only one reply in a couple of weeks. He has ignored my requests for co-maintainership. I commented on the NRM bug[1] two weeks ago with no response. The bug itself is months old, but he pops in to keep from having the package taken. At this point it is time for someone to update the package as it is currently a security hazard. I have already built the latest mediawiki package and have it ready to rock-and-or-roll once the NRM procedure is finished. Michael [1] https://bugzilla.redhat.com/show_bug.cgi?id=850937 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedpkg: Change in git push method?
I just got this output when updating a package: $ fedpkg push warning: push.default is unset; its implicit value is changing in Git 2.0 from 'matching' to 'simple'. To squelch this message and maintain the current behavior after the default changes, use: git config --global push.default matching To squelch this message and adopt the new behavior now, use: git config --global push.default simple See 'git help config' and search for 'push.default' for further information. Does it matter which method is used for packaging purposes? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
config.guess/config.sub for aarch64 (was Re: Mass Rebuild for Fedora 19)
Dennis Gilmore den...@ausil.us writes: Additionally we will be mass patching config.guess and config.sub to support aarch64 in preperation for 64 bit arm support Hm, it would be much better in the long run to pester upstreams to update to an appropriate version of these files. Are the required changes in upstream autoconf yet, and if so what version? If not, why not? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg: Change in git push method?
On Fri, Feb 8, 2013 at 10:06 AM, Richard Shaw hobbes1...@gmail.com wrote: I just got this output when updating a package: $ fedpkg push warning: push.default is unset; its implicit value is changing in Git 2.0 from 'matching' to 'simple'. To squelch this message and maintain the current behavior after the default changes, use: git config --global push.default matching To squelch this message and adopt the new behavior now, use: git config --global push.default simple See 'git help config' and search for 'push.default' for further information. That's actually from the git package that fedpkg calls underneath. Does it matter which method is used for packaging purposes? I believe fedpkg might want to start setting push.default to matching when it does a clone. Probably a small change. Want to file a bug? josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg: Change in git push method?
On Fri, Feb 8, 2013 at 9:16 AM, Josh Boyer jwbo...@gmail.com wrote: On Fri, Feb 8, 2013 at 10:06 AM, Richard Shaw hobbes1...@gmail.com wrote: Does it matter which method is used for packaging purposes? I believe fedpkg might want to start setting push.default to matching when it does a clone. Probably a small change. Want to file a bug? I don't mind filling one out, but I'm not sure what I would put in it. Are you saying that fedpkg should not rely on the default and explicit set the push method? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[abi-compliance-checker/f18] Update to latest upstream release.
Summary of changes: 91c503e... Update to latest upstream release. (*) (*) This commit already existed in another branch; no separate mail sent -- 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
[abi-compliance-checker/f17] Update to latest upstream release.
Summary of changes: 91c503e... Update to latest upstream release. (*) (*) This commit already existed in another branch; no separate mail sent -- 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
[abi-compliance-checker/f16] Update to latest upstream release.
Summary of changes: 91c503e... Update to latest upstream release. (*) (*) This commit already existed in another branch; no separate mail sent -- 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: Package shipping their own CA and security
Hello, On Fri, Feb 8, 2013 at 12:41 PM, Michael Scherer m...@zarb.org wrote: That's where it start to be funny and security related, because the whole certificate authority idea requires update to be kept secure ( for exemple, when a CA was compromised, like DigiNotar, Trustwave ). And that's something we may not really watch. There's also the system administration impact - an application that ships its own CA bundle will not be affected by admin's changes to https://fedoraproject.org/wiki/Features/SharedSystemCertificates . - ban all certificates if used to validate something. I think this is too strict; there may be legitimate cases of service-specific CAs; there even are projects that use the X.509 certificate format for something completely unrelated to the global CA universe. Requiring an exception or an independent review may be fine. - list all problematic packages on a wiki. Well, not necessarily a wiki, but a list of all potentially problematic packages, and eventually an analysis of them, would make a potential policy decision much easier (and would make it more likely that the chosen policy will be the right one). We cannot automate that test, since private key and certificates are often used in tests suite. And as long as this is just used for testing purpose, the certificate should be ok. Wouldn't this be handled by only checking the binary packages, and allowing private keys/certificates in SRPMs? Shipping test suites is usually not that valuable (... speaking as an owner of a package that does ship a test suite :) It will be dropped soon). If people want to look at affected packages, there is # yum whatprovides '*pem' That's quite a few :( Don't forget about other formats - .der, .p12 at least; possibly also the native NSS and Java formats. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 904756] perl-Filesys-Notify-Simple-0.10 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=904756 Robin Lee robinlee.s...@gmail.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Filesys-Notify-Simple- ||0.10-1.fc19 Resolution|--- |RAWHIDE Last Closed||2013-02-08 10:42:04 -- 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=LzAqWDEpRZa=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: Package shipping their own CA and security
On Fri, Feb 08, 2013 at 12:41:29PM +0100, Michael Scherer wrote: What triggered to write this mail is review 902503, where I was not able to find a way to inspect the cacert.p7s. I am not able to decipher openssl man pages to do anything with that file ( as a side note, if someone can tell me how to list certificate there, I would love to know ). This worked for me: openssl cms -verify -noverify -in cacert.p7s HTH, Nalin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: config.guess/config.sub for aarch64 (was Re: Mass Rebuild for Fedora 19)
On 02/08/2013 07:12 AM, Tom Lane wrote: Dennis Gilmore den...@ausil.us writes: Additionally we will be mass patching config.guess and config.sub to support aarch64 in preperation for 64 bit arm support Hm, it would be much better in the long run to pester upstreams to update to an appropriate version of these files. Are the required changes in upstream autoconf yet, and if so what version? If not, why not? Support for aarch64 landed in autoconf 2.69 which was released on March 25th and first built in Fedora on May 15th. Packages that use autoconf 2.69 are already good to go. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
/etc/mtab symlink PERMANENTLY mangeled
would deveopers of core-packages take a look at this? https://bugzilla.redhat.com/show_bug.cgi?id=887763#c37 god knows what happens here with the /etc/mtab symlink BUT this all did never happen before the problems with /etc/mtab where solved by replace it with a symlink may i suggest to make nails with heads and fix packages that any usage of /etc/mtab is REPLACED with directly look at /proc/mounts? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package shipping their own CA and security
Am 08.02.2013 13:05, schrieb Florian Weimer: On 02/08/2013 12:58 PM, Reindl Harald wrote: Am 08.02.2013 12:54, schrieb Florian Weimer: On 02/08/2013 12:41 PM, Michael Scherer wrote: For a certificate, that's slightly more subtle. A certificate alone in a package cannot do much. If there is no private key, then it cannot be used out of the box, except for client side validation ( afaik ). So all .pam certificates we can find would be used to validate another ssl certificates. Embedding a certificate in a RPM is fine because we can handle revocation/key rollover through an RPM update—especially if it's not a configuration file. We might eventually get a better mechanism, but until that happens, it's not so bad. (This assumes that we own the certificate in question. Obviously, it won't do to download the certificate from the Internet, bake it in, and hope that it won't change until it expires. That's just not going to work.) it is NOT fine, it is just stupid the certificate is broken after that any random guy out there can missuse it and your users which trust the certificate are Please mind your language. my language was moderate Evidently, we are not talking about the same thing. I was referring to server certificates baked in to clients, in case this wasn't clear. Package shipping their own CA and security is clearly server side so maybe you should not switch to another topic without state that signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request for a firewalld secondary DHCP + PXEBOOT HOWTO
On 02/07/2013 04:23 PM, Aaron Gray wrote: Can someone who knows firewalld please do a HOWTO to on setting up a secondary DHCP with DNS and HTTPS access for PXEBOOTing of Fedora18 please to go with the PXEBOOT HOWTO :- http://linux-sxs.org/internet_serving/pxeboot.html Hope someone can help, I put I message on the User List but got no response. Well what seems to be standards sysadmin practice with firewalld on servers is to disable it and enable iptables. Firewalld is aimed at desktop users and roaming hardware which makes zones useless concept for static server within an corporate infrastructure. So the missing steps for your guide simply are... systemctl stop firewalld* systemctl disable firewalld* systemctl enable iptables.service systemctl start iptables.service JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[abi-compliance-checker/el6] (2 commits) ...Merge remote-tracking branch 'origin/master' into el6 Update to 1.98.8
Summary of changes: 91c503e... Update to latest upstream release. (*) 44c263d... Merge remote-tracking branch 'origin/master' into el6 Updat (*) This commit already existed in another branch; no separate mail sent -- 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
[abi-compliance-checker/el6: 2/2] Merge remote-tracking branch 'origin/master' into el6 Update to 1.98.8
commit 44c263dcf884abb0ed928a38096242ba3d3f5a1a Merge: 9dfbc9a 91c503e Author: Orion Poplawski or...@nwra.com Date: Fri Feb 8 09:44:54 2013 -0700 Merge remote-tracking branch 'origin/master' into el6 Update to 1.98.8 .gitignore |1 + abi-compliance-checker.spec |5 - sources |2 +- 3 files changed, 6 insertions(+), 2 deletions(-) --- -- 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: fedpkg: Change in git push method?
On Fri, Feb 08, 2013 at 09:20:23AM -0600, Richard Shaw wrote: I don't mind filling one out, but I'm not sure what I would put in it. Are you saying that fedpkg should not rely on the default and explicit set the push method? Fedpkg doesn't set any setting. It only call git push. The issue seems to be caused by a change of git. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Comiz Tester for xfce and lxde
Dear xfce/lxde user/maintainer, perhaps you know i re-retired compiz-0.88 for f18. I also added a start-script for lxde and xfce, subpackage compiz-xfce and compiz-lxde. Unfortunately i do not use xfce or lxde directly so i have no feedback if compiz is running well in those desktop. I did a short test if i had created the packages, and it was OK. It wold be nice if some could test it more and give me a feedback. Thank you Wolfgang PS: compiz is running well in gnome-fallback -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Comiz Tester for xfce and lxde
Hi Wolfgang, I have heard it is working in LXDE but I have not tried it myself. Thanks for your hard work on this. Dan On Fri, Feb 8, 2013 at 9:27 AM, Rave it chat-to...@raveit.de wrote: Dear xfce/lxde user/maintainer, perhaps you know i re-retired compiz-0.88 for f18. I also added a start-script for lxde and xfce, subpackage compiz-xfce and compiz-lxde. Unfortunately i do not use xfce or lxde directly so i have no feedback if compiz is running well in those desktop. I did a short test if i had created the packages, and it was OK. It wold be nice if some could test it more and give me a feedback. Thank you Wolfgang PS: compiz is running well in gnome-fallback -- 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: Package shipping their own CA and security
Le vendredi 08 février 2013 à 11:08 -0500, Nalin Dahyabhai a écrit : On Fri, Feb 08, 2013 at 12:41:29PM +0100, Michael Scherer wrote: What triggered to write this mail is review 902503, where I was not able to find a way to inspect the cacert.p7s. I am not able to decipher openssl man pages to do anything with that file ( as a side note, if someone can tell me how to list certificate there, I would love to know ). This worked for me: openssl cms -verify -noverify -in cacert.p7s Sorry to not have been clearer, what i want is the clear text version of the certificate. IE, there is 79 certs in the file. Who do thy belong is diginotar in it, etc, etc. ( but this command is still useful to know, as it was non obvious at all ) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package shipping their own CA and security
Le vendredi 08 février 2013 à 16:54 +0100, Miloslav Trmač a écrit : Hello, On Fri, Feb 8, 2013 at 12:41 PM, Michael Scherer m...@zarb.org wrote: - ban all certificates if used to validate something. I think this is too strict; there may be legitimate cases of service-specific CAs; there even are projects that use the X.509 certificate format for something completely unrelated to the global CA universe. Requiring an exception or an independent review may be fine. Of course, when i mean ban all, I mean unless exceptions. And finding those potential exceptions is also one reason to have this thread :) We cannot automate that test, since private key and certificates are often used in tests suite. And as long as this is just used for testing purpose, the certificate should be ok. Wouldn't this be handled by only checking the binary packages, and allowing private keys/certificates in SRPMs? Shipping test suites is usually not that valuable (... speaking as an owner of a package that does ship a test suite :) It will be dropped soon). Usually, the test end in %doc, so maybe that's something that can be used. Sometimes, that's also used as example ( see the various perl modules shipping a cert ). Even if I can imagine people using the example to setup a service and end with a non private key. Not sure if we whould prevent that or just let darwin do his job... If people want to look at affected packages, there is # yum whatprovides '*pem' That's quite a few :( Don't forget about other formats - .der, .p12 at least; possibly also the native NSS and Java formats. I will add .dev and .p12. For the native formats, I am not a certificate specialist, so I will have to look and see what can be done. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg: Change in git push method?
On Fri, Feb 8, 2013 at 12:26 PM, Jochen Schmitt joc...@herr-schmitt.de wrote: On Fri, Feb 08, 2013 at 09:20:23AM -0600, Richard Shaw wrote: I don't mind filling one out, but I'm not sure what I would put in it. Are you saying that fedpkg should not rely on the default and explicit set the push method? Yes. Fedpkg doesn't set any setting. It only call git push. Right, that's what I said in my initial reply. The issue seems to be caused by a change of git. Yes, but fedpkg is currently relying on the existing git default, which is matching. That is changing upstream in git, so fedpkg needs to set a default when it clones. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[HEADS-UP] Updating MongoDB in F17 and EPEL6
Hello, A couple of months back I asked about updating MongoDB from 2.0.7 to 2.2.0 in EPEL6 and Fedora 17. Although it is backwards compatible, there were several bugs brought up that people wanted fixed in Mongodb 2.2.x before we moved to this version. With MongoDB 2.2.3, the last of these bugs has been fixed. MongoDB 2.2.3 is now built and in testing, and I propose the following schedule. February 20 Push MongoDB 2.2.3 to stable for Fedora 17 and EPEL6 If anyone has any concerns, please let me know. If anyone knows where else I should announce this other than epel-devel-list, please let me know. Thanks Troy Dawson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg: Change in git push method?
2013/2/8 Josh Boyer jwbo...@gmail.com: Yes, but fedpkg is currently relying on the existing git default, which is matching. That is changing upstream in git, so fedpkg needs to set a default when it clones. And this default should probably be push.default=upstream. -- Thomas Moschny thomas.mosc...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg: Change in git push method?
On Fri, Feb 8, 2013 at 12:54 PM, Thomas Moschny thomas.mosc...@gmail.com wrote: 2013/2/8 Josh Boyer jwbo...@gmail.com: Yes, but fedpkg is currently relying on the existing git default, which is matching. That is changing upstream in git, so fedpkg needs to set a default when it clones. And this default should probably be push.default=upstream. Sure, that's certainly possible. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self introduction
Hello, My name is Frederik Holden, and I'm trying to becoming a package collection maintainer. I am sending this email to introduce myself, as recommended by the wiki. I submitted my first review request earlier today, which can be found at https://bugzilla.redhat.com/show_bug.cgi?id=909387. I also might add that I am looking for a sponsor. My Fedora Account System username is airwave, and I can found on Freenode under the name Airwave. I am currently enrolled in a 3-year bachelor course at Sør-Trøndelag University College in Norway to become a sysadmin. My bachelor's degree will be completed this summer. Regards, Frederik Holden -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package shipping their own CA and security
On Fri, Feb 08, 2013 at 06:40:05PM +0100, Michael Scherer wrote: Le vendredi 08 février 2013 à 11:08 -0500, Nalin Dahyabhai a écrit : This worked for me: openssl cms -verify -noverify -in cacert.p7s Sorry to not have been clearer, what i want is the clear text version of the certificate. IE, there is 79 certs in the file. Who do thy belong is diginotar in it, etc, etc. ( but this command is still useful to know, as it was non obvious at all) Each of those can be piped, individually, through a command like openssl x509 -noout -text or openssl x509 -noout -subject to get something more human readable. So, maybe something like this, though YMMV: #!/bin/sh tmpfile=`mktemp` if test -z $tmpfile ; then echo Error creating temporary file. fi trap 'rm -f $tmpfile' EXIT incert=false openssl cms -verify -noverify -in cacert.p7s | while read line ; do case $line in *-BEGIN*) echo $line $tmpfile incert=true ;; *-END*) if $incert ; then echo $line $tmpfile openssl x509 -noout -text -in $tmpfile cat $tmpfile incert=false fi ;; *) if $incert ; then echo $line $tmpfile fi ;; esac done Cheers, Nalin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
Hi On Fri, Feb 8, 2013 at 9:46 AM, Michael Cronenworth wrote: At this point it is time for someone to update the package as it is currently a security hazard. I have already built the latest mediawiki package and have it ready to rock-and-or-roll once the NRM procedure is finished. There is no need to wait on the NRM process for fixing security bugs. I recommend you just go ahead and push out a build asap Rahul -- 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: --+--- Comment (by limb): rt3 is there now, I'll do a new update for jcifs. -- Ticket URL: https://fedorahosted.org/rel-eng/ticket/5467#comment:5 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
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Le Ven 8 février 2013 13:22, Olav Vitters a écrit : On Fri, Feb 08, 2013 at 10:34:58AM +0100, Stijn Hoop wrote: I am providing a datapoint that directly contradicts your original statement, namely that there is a completely different target audience for GNOME 2 vs GNOME 3. I am that datapoint. As are various others during FOSDEM (Vincent Untz asked people to raise their hands). No idea how representative that it. The FOSDEM poll was stacked — no one really wanted to hurt Vincent Untz too much given his obvious efforts to be nice, there was this knot of GNOME people bunched together that were a tad intimidating, and people do not go to FOSDEM to fight. What is telling however is the complete refusal of the audience to put systemd and Gnome 3 in the same bucket. Lennart's efforts to explain his project, understand sysadmin needs, provide a smooth transition and keep current usages working clearly paid off there. So don't overplay the GNOME 3 FOSDEM session, it was an awkward moment for everyone involved (and certainly not representative of the positive energy that permeated other presentations). -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 909136] abi-compliance-checker-1.98.8 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=909136 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- abi-compliance-checker-1.98.8-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/abi-compliance-checker-1.98.8-1.fc17 -- 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=FGuFbakXXva=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 909136] abi-compliance-checker-1.98.8 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=909136 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- abi-compliance-checker-1.98.8-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/abi-compliance-checker-1.98.8-1.fc16 -- 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=ZYqgwpTvPMa=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: Cinnamon as Default Desktop
On Fri, 8 Feb 2013 20:35:56 +0100 Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Ven 8 février 2013 13:22, Olav Vitters a écrit : On Fri, Feb 08, 2013 at 10:34:58AM +0100, Stijn Hoop wrote: I am providing a datapoint that directly contradicts your original statement, namely that there is a completely different target audience for GNOME 2 vs GNOME 3. I am that datapoint. As are various others during FOSDEM (Vincent Untz asked people to raise their hands). No idea how representative that it. The FOSDEM poll was stacked — no one really wanted to hurt Vincent Untz too much given his obvious efforts to be nice, there was this knot of GNOME people bunched together that were a tad intimidating, and people do not go to FOSDEM to fight. What is telling however is the complete refusal of the audience to put systemd and Gnome 3 in the same bucket. Lennart's efforts to explain his project, understand sysadmin needs, provide a smooth transition and keep current usages working clearly paid off there. So don't overplay the GNOME 3 FOSDEM session, it was an awkward moment for everyone involved (and certainly not representative of the positive energy that permeated other presentations). To be honest, I don't think any poll will ever suffice for this topic. Nor do I think a poll is what's needed. It should simply be easier to switch to a desktop that Works For You, especially after installation, and even before if possible. That way we can keep the anti-GNOME-3 people happy as well. In the end I guess we can't get rid of the fanatical GNOME 3 is for tablets only meme (and others like it that I personally don't agree with), but hey, I don't mind as long as I can ignore those. But I will keep objecting to the single-sided argument that there is no GNOME 2 user that likes GNOME 3. I fully support those who have tried and rejected the new stuff -- as long as they don't impose their opinion on me :-) --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
I'm not sure there's any place in our community where it is acceptable for people to go to fight. Nor do I think that would be healthy. I would prefer to think that noone in our community really wants to hurt anyone else. I think if anyone showed up at any face-to-face meeting specifically with the intent to fight or to hurt someone they would feel intimidated and would modify their behavior accordingly. So I really don't understand why FOSDEM as a collection of individuals at a face-to-face meeting. would be any different than another face-to-face meeting. But I will say that I would prefer it if our written communication channels were similarly less tolerant of individuals who show up primarily to fight or are intent on hurting someone. Text communication channels, are inherently prone to a loss of civility, and by collectively condoning behavior we'd otherwise find uncomfortable in a face to face setting we hasten the debasement of the level of discourse therein. -jef On Fri, Feb 8, 2013 at 10:35 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Ven 8 février 2013 13:22, Olav Vitters a écrit : On Fri, Feb 08, 2013 at 10:34:58AM +0100, Stijn Hoop wrote: I am providing a datapoint that directly contradicts your original statement, namely that there is a completely different target audience for GNOME 2 vs GNOME 3. I am that datapoint. As are various others during FOSDEM (Vincent Untz asked people to raise their hands). No idea how representative that it. The FOSDEM poll was stacked — no one really wanted to hurt Vincent Untz too much given his obvious efforts to be nice, there was this knot of GNOME people bunched together that were a tad intimidating, and people do not go to FOSDEM to fight. What is telling however is the complete refusal of the audience to put systemd and Gnome 3 in the same bucket. Lennart's efforts to explain his project, understand sysadmin needs, provide a smooth transition and keep current usages working clearly paid off there. So don't overplay the GNOME 3 FOSDEM session, it was an awkward moment for everyone involved (and certainly not representative of the positive energy that permeated other presentations). -- Nicolas Mailhot -- 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
[Bug 909136] abi-compliance-checker-1.98.8 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=909136 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- abi-compliance-checker-1.98.8-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/abi-compliance-checker-1.98.8-1.fc18 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=BeDmh4h2Apa=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: Non-responsive Maintainer: mediawiki
On 8 February 2013 12:15, Rahul Sundaram methe...@gmail.com wrote: Hi On Fri, Feb 8, 2013 at 9:46 AM, Michael Cronenworth wrote: At this point it is time for someone to update the package as it is currently a security hazard. I have already built the latest mediawiki package and have it ready to rock-and-or-roll once the NRM procedure is finished. There is no need to wait on the NRM process for fixing security bugs. I recommend you just go ahead and push out a build asap This package is a bit difficult to fix. One it has custom patches that upstream doesn't accept. Two the fix is to upgrade to a very new version which will break everyone who upgrades until they (or the first person who gets to the website :) ) runs the upgrade mode.. which might not work due to either custom changes or the fact that it is a large upgrade change. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Fri, 08.02.13 20:35, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote: Le Ven 8 février 2013 13:22, Olav Vitters a écrit : On Fri, Feb 08, 2013 at 10:34:58AM +0100, Stijn Hoop wrote: I am providing a datapoint that directly contradicts your original statement, namely that there is a completely different target audience for GNOME 2 vs GNOME 3. I am that datapoint. As are various others during FOSDEM (Vincent Untz asked people to raise their hands). No idea how representative that it. The FOSDEM poll was stacked — no one really wanted to hurt Vincent Untz too much given his obvious efforts to be nice, there was this knot of GNOME people bunched together that were a tad intimidating, and people do not go to FOSDEM to fight. What is telling however is the complete refusal of the audience to put systemd and Gnome 3 in the same bucket. Lennart's efforts to explain his project, understand sysadmin needs, provide a smooth transition and keep current usages working clearly paid off there. Actually, don't try to separate us systemd folks too much from the GNOME3 folks. I as one of the systemd guys, am a GNOME3 guy too. I fully support GNOME3's goals, much of my work I see as groundwork to achieve GNOME3's goals, and I believe GNOME3 is the best thing that ever happened to the Linux desktop. When I see a GNOME2 desktop it appears like a trip down memory lane to me, and even though it was only a few years ago that GNOME2 was the state of the art of a Linux desktop it now appears to be as old as Windows 3.1 to me. And I am really thankful I don't have to use Windows 3.1 anymore. So yeah, I'll jump in defending GNOME 3 any time, thank you very much, even though I know that these discussions will never stop any haters from hating, and never stop them from doing this publicly, and repetitively and loudly on mailing lists such as this one. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
Stephen John Smoogen wrote: This package is a bit difficult to fix. One it has custom patches that upstream doesn't accept. Two the fix is to upgrade to a very new version which will break everyone who upgrades until they (or the first person who gets to the website :) ) runs the upgrade mode.. which might not work due to either custom changes or the fact that it is a large upgrade change. Stephen, 1. The two patches are for hard-coding defaults. We shouldn't be in the business of doing this. I've dropped the two patches in my 1.19 build. 2. The upgrade mode is executed for the user when they upgrade by a post-install scriptlet. In any case the upgrade procedure is no different from an upgrade in PostgreSQL or any other app that requires user-interaction on upgrades. This is no reason to keep mediawiki at 1.16. I don't see any reason to keep mediawiki at 1.16 other than a NRM. If any FESCo member wants to orphan the package I'll push the update ASAP. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: [389 Project] #576: DNA: use event queue for config update only at the start up.
https://fedorahosted.org/389/ticket/576 https://fedorahosted.org/389/attachment/ticket/576/0001-Ticket-576-DNA-use-event-queue-for-config-update-onl.patch Bug description: DNA config updates were always put into the event queue and executed in 30 seconds, which increased a chance to conflict with the ordinary modify operations and cause db deadlocks. Fix description: The 30 seconds delay is necessary at the start- up time when MMR is configured to guarantee the shared config is logged in the changelog. This patch leaves the behaviour of the config update at the start-up as it is; the rest won't be queued but updated immediately. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
The FOSDEM poll was stacked ??? no one really wanted to hurt Vincent Untz too much given his obvious efforts to be nice, there was this knot of GNOME people bunched together that were a tad intimidating, and people do [...] So don't overplay the GNOME 3 FOSDEM session, it was an awkward moment for everyone involved (and certainly not representative of the positive energy that permeated other presentations). Sounds like bitterness to me. First we had the rabid hordes of hatred mongers running surveys, polls and what not to support their claims of how GNOME 3 sucks and no one uses it anymore and so on and so forth. Now that the other side of the argument is coming to light, you are trying to cling on to your vociferous claims at all costs. For what it is worth, I have been using GNOME since 2004 and absolutely loved the move to GNOME3. Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgpw1I3aTrmeb.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
I'm an Ambassador and this proposal is confusing me. We have LibreOffice in our repositories; I think that bring back Apache OpenOffice generates only confusion between users, not freedom of choice. The confusion is already there in Windows world, linux user should be more capable of treating it as freedom of choice instead of confusion. Only if you think free software is meant only for those who spend all their time crawling the Internet to keep track of every little drama going on in the technology world. If you consider that free software is meant for everybody, irrespective of their technical abilities, then, yes, it creates too much confusion. Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgpyXoNXblZQX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Hi On Fri, Feb 8, 2013 at 3:36 PM, Debarshi Ray wrote: If you consider that free software is meant for everybody, irrespective of their technical abilities, then, yes, it creates too much confusion. There are multiple alternative office suites already in Linux. Adding one more isn't really going to aggravate the problem too much for users especially since there is a default installed already. The real weakness in Fedora is that our package manager GUI has no way for users to figure out which one is more popular or recommended. So if I am trying to checkout which games are available in the repo, I have no way to really differentiate between say nethack, openarena and xonotic without installing and going through all of them one by one or reading the dull often not very insightful descriptions and hoping to make some sense of it. No screenshots, no votes, no reviews, no top lists - nothing a regular user would expect. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Email-Address-1.898.tar.gz uploaded to lookaside cache by spot
A file has been added to the lookaside cache for perl-Email-Address: 0ea27eae4888ec25733af68b51f20245 Email-Address-1.898.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Email-Address] 1.898
commit 3d0142676e5a3a7b77f350d468484dd3cbd40f54
Author: Tom Callaway s...@fedoraproject.org
Date: Fri Feb 8 15:52:27 2013 -0500
1.898
.gitignore |1 +
perl-Email-Address.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 1c0c584..efa5543 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
Email-Address-1.889.tar.gz
/Email-Address-1.896.tar.gz
/Email-Address-1.897.tar.gz
+/Email-Address-1.898.tar.gz
diff --git a/perl-Email-Address.spec b/perl-Email-Address.spec
index 0cc8518..810f465 100644
--- a/perl-Email-Address.spec
+++ b/perl-Email-Address.spec
@@ -1,5 +1,5 @@
Name: perl-Email-Address
-Version:1.897
+Version:1.898
Release:1%{?dist}
Summary:RFC 2822 Address Parsing and Creation
@@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Fri Feb 8 2013 Tom Callaway s...@fedoraproject.org - 1.898-1
+- update to 1.898
+
* Wed Dec 19 2012 Tom Callaway s...@fedoraproject.org - 1.897-1
- update to 1.897
diff --git a/sources b/sources
index 18b56ef..66e0180 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d915df36b15c53f94e77b260c440be62 Email-Address-1.897.tar.gz
+0ea27eae4888ec25733af68b51f20245 Email-Address-1.898.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Proposed F19 Feature: Apache OpenOffice
Unlike pulseaudio (in the above linked thread), AOO is end-user GUI application, not a library/daemon/sound-server/whatever used to get the wanted sound to your headphones (that by design interferes with anything else trying to do the same) ;-) By adding AOO we're not breaking some third app, we might break LO and that's exactly what I consider critical not to do. Is it doable? Are there people willing and able to do that? If yes, sure, let them. It is irrelevant whether it is a daemon or a GUI application. The main point is that you are confusing users and also developers. Why the hell should a random user have to choose from half a dozen seemingly similar programs when the information for making an educated choice is so hard to obtain, if at all it can be obtained? Whether it is editing a document or listening to audio, it is all about using some piece of software to get something done. It is not about spending loads of time to make the choice. As for developers, why would they have to deal with bug reports filed against the wrong component (AOO vs LO)? Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgp2aqAa3l5ic.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On 8 February 2013 13:15, Michael Cronenworth m...@cchtml.com wrote: Stephen John Smoogen wrote: This package is a bit difficult to fix. One it has custom patches that upstream doesn't accept. Two the fix is to upgrade to a very new version which will break everyone who upgrades until they (or the first person who gets to the website :) ) runs the upgrade mode.. which might not work due to either custom changes or the fact that it is a large upgrade change. Stephen, 1. The two patches are for hard-coding defaults. We shouldn't be in the business of doing this. I've dropped the two patches in my 1.19 build. I thought it was more in the past. I dropped them from the various ones that were in the old 1.14 tree that tried to allow for multihosting-mutliwiki easily. There were also TeX parts in the past which were finicky. 2. The upgrade mode is executed for the user when they upgrade by a post-install scriptlet. In any case the upgrade procedure is no different from an upgrade in PostgreSQL or any other app that requires user-interaction on upgrades. This is no reason to keep mediawiki at 1.16. I don't think that it does either. However, having gotten the emails for it not always working etc etc.. I get a little gunshy of just pushing it out without some strong testing. My email was more of a this isn't a simple security fix. It is a major upgrade of the software. I don't see any reason to keep mediawiki at 1.16 other than a NRM. If any FESCo member wants to orphan the package I'll push the update ASAP. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
There are multiple alternative office suites already in Linux. Adding one more isn't really going to aggravate the problem too much for users We suck. So lets suck a little bit more. Is that what you are saying? :-) especially since there is a default installed already. The first time I ran an installer 10 years ago, I remember staring at a screen which gave me 2 options: GNOME and KDE, and the description for both of them were exactly the same except those 2 words. I don't want an user staring at yum or gnome-packagekit or whatever and seeing 2 office suites which appear to be identical except for their names, and wondering what the hell is going on. The real weakness in Fedora is that our package manager GUI has no way for users to figure out which one is more popular or recommended. And how exactly are you going to explain all the nuances of how OpenOffice and LibreOffice are different? Don't forget the little bit about Go-oo. :-) Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgpN6rhz25Mi3.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 Fri, Feb 8, 2013 at 9:50 PM, Debarshi Ray rishi...@lostca.se wrote: It is irrelevant whether it is a daemon or a GUI application. The main point is that you are confusing users and also developers. Why the hell should a random user have to choose from half a dozen seemingly similar programs when the information for making an educated choice is so hard to obtain, if at all it can be obtained? 1) If were so hard to make an educated choice, the users couldn't do to badly by choosing either one, could they? 2) Just install LibreOffice by default (or make it the only one visible during installation) and be done with it. Whether it is editing a document or listening to audio, it is all about using some piece of software to get something done. It is not about spending loads of time to make the choice. This is one of the cases where the expression it is about used to reference an association in human brain only obscures the argument, so I'm left to guessing what you meant, anyway... If you don't want to spend the time to make a choice, don't. If you don't want uninformed users to need to make a choice, see above. If somebody else wants to spend time packaging, testing and bug fixing Apache OpenOffice, that doesn't hurt you, or most others, in any way I can see. As for developers, why would they have to deal with bug reports filed against the wrong component (AOO vs LO)? If the users can find the bug tracker, they can also probably find the Help/About menu. If anything, this will put more work on the AOO package maintainers. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
I know this applies, but installing gnome-shell pulls in gdm. I.e. removing gdm without removing gnone-shell is not possible. Because gnome-shell (running in a special mode) is nowadays the greeter used by GDM. That does not mean GDM won't let you log into KDE if you have it installed. As for GDM requiring gnome-shell, I don't think it should come across as surprising because GDM is GNOME's display manager. If you dislike GNOME so much then get yourself a different display manager. Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgpeO6FmBx7O0.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Hi On Fri, Feb 8, 2013 at 3:56 PM, Debarshi Ray wrote: There are multiple alternative office suites already in Linux. Adding one more isn't really going to aggravate the problem too much for users We suck. So lets suck a little bit more. Is that what you are saying? :-) If you want to build a distribution with a single default for everything and nothing else, Fedora is simply not that distribution. That is a lost cause and fighting against Apache Openoffice is not going to win you anything. Given what we have, I think addressing the potential confusion by improving the GUI is the only realistic answer. And how exactly are you going to explain all the nuances of how OpenOffice and LibreOffice are different? Don't forget the little bit about Go-oo. :-) Go-oo is entirely irrelevant to Fedora. I don't see any reason to drag it in. Since Libreoffice will be installed by default, regular users will just use it. No need to explain any nuances. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
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. [citation needed] Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgpCXShvAfgaH.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
There are multiple alternative office suites already in Linux. Adding one more isn't really going to aggravate the problem too much for users We suck. So lets suck a little bit more. Is that what you are saying? :-) If you want to build a distribution with a single default for everything and nothing else, Fedora is simply not that distribution. That is a lost cause and fighting against Apache Openoffice is not going to win you anything. Given what we have, I think addressing the potential confusion by improving the GUI is the only realistic answer. Ok. sarcasm So what is the next step? Offering another kernel? Or allowing us to choose a different package manager or packing format? Oh, wait, using multiple different depsolvers has already been frowned upon. Now why did *that* happen? It is Fedora, isn't it? /sarcasm Go-oo is entirely irrelevant to Fedora. No, it is not. It is an important part of where LO came from. I don't see any reason to drag it in. Since Libreoffice will be installed by default, regular users will just use it. No need to explain any nuances. I see. So how will you empower users to make an informed decision to choose LO over AOO or the other way around? And it will be the default until someone gets the bright idea of creating an AOO spin, and that idea has already started floating around. Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgp5agW1apeJJ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Hi On Fri, Feb 8, 2013 at 4:21 PM, Debarshi Ray rishi...@lostca.se wrote: Ok. sarcasm So what is the next step? Offering another kernel? Or allowing us to choose a different package manager or packing format? Oh, wait, using multiple different depsolvers has already been frowned upon. Now why did *that* happen? It is Fedora, isn't it? /sarcasm Sarcasm isn't going to resolve the problems. If you have a proposal, let's hear it. Removing all the alternatives isn't an option. Is it? Go-oo is entirely irrelevant to Fedora. No, it is not. It is an important part of where LO came from. Users don't care where LO comes from at all. I see. So how will you empower users to make an informed decision to choose LO over AOO or the other way around? Refer to my first post. And it will be the default until someone gets the bright idea of creating an AOO spin, and that idea has already started floating around. I don't expect this to happen, realistically speaking but regardless of that, spins don't change the default. What we have as default is the single ISO in the fedoraproject.org page Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
On Fri, Feb 8, 2013 at 12:21 PM, Debarshi Ray rishi...@lostca.se wrote: sarcasm So what is the next step? Offering another kernel? Or allowing us to choose a different package manager or packing format? Oh, wait, using multiple different depsolvers has already been frowned upon. deadpan On an F18 system yum info smart yum info dpkg /deadpan Please don't confuse the discussion concerning default choices with a discussion as to what is allowable to include for end-users to choose from. Please don't confuse the discussion concerning what we mandate with regard to our internal project workflow concerning the tools we require contributors to use with discussion concerning what we allow to exist for end-users to choose from. Because we do include alternative depsolvers for rpm packages. And we do include alternative package management tools for end-user use. And as much as I really personally have no intention of using AOO, I can't think of a sound policy reason or precedent to exclude its inclusion. The historical symlinks muddy the water to some degree, as does the unfortunate history with the project forking. But there's nothing fundamental here that screams policy red flag. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
On Feb 8, 2013 12:54 PM, Stephen John Smoogen smo...@gmail.com wrote: . Two the fix is to upgrade to a very new version which will break everyone who upgrades until they (or the first person who gets to the website :) ) runs the upgrade mode.. which might not work due to either custom changes or the fact that it is a large upgrade change. -- Stephen J Smoogen. I haven't poked at mediawiki in a while, so please correct me if I'm wrong, but isn't it fairly self contained? I recall copying the content from /usr/share/ to /var/www/ then localizing. Having a new version shouldn't break existing deployments unless they are served out of /usr/share/, and that doesn't seem sane. The update would then be available, not imposed. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
sarcasm So what is the next step? Offering another kernel? Or allowing us to choose a different package manager or packing format? Oh, wait, using multiple different depsolvers has already been frowned upon. Now why did *that* happen? It is Fedora, isn't it? /sarcasm Sarcasm isn't going to resolve the problems. But it might highlight the problem with this lets have some more choices madness. If you have a proposal, let's hear it. Removing all the alternatives isn't an option. Is it? You already heard it: don't make it worse than it already is. Users don't care where LO comes from at all. Then how will you empower them to make a choice between LO and AOO? How will you ensure that bugs don't get misfiled? Every now and then I get bugs arising out of forks and downstream patches that get misfiled by confused users. Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgpUeu24n3QCZ.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 Fri, Feb 8, 2013 at 10:38 PM, Debarshi Ray rishi...@lostca.se wrote: Users don't care where LO comes from at all. Then how will you empower them to make a choice between LO and AOO? We don't. We don't need to, and we don't care to. We empower interested programmers to work on AOO within the Fedora ecosystem. That's all. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
sarcasm So what is the next step? Offering another kernel? Or allowing us to choose a different package manager or packing format? Oh, wait, using multiple different depsolvers has already been frowned upon. deadpan On an F18 system yum info smart yum info dpkg /deadpan You do know the difference between frowned upon and banned, right? For starters: https://fedorahosted.org/fesco/ticket/669 If you dig you will atleast one more. Please don't confuse the discussion concerning default choices with a discussion as to what is allowable to include for end-users to choose from. The point was to refute the this is Fedora, so we want more choices argument. Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgpy3ByJRPSYR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
We empower interested programmers to work on AOO within the Fedora ecosystem. That's all. How is packaging AOO a requirement for that? They can compile AOO and work on it just fine. Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgphhOGQaudSg.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Hi On Fri, Feb 8, 2013 at 4:38 PM, Debarshi Ray wrote: Sarcasm isn't going to resolve the problems. But it might highlight the problem with this lets have some more choices madness. There are better ways to highlight that not to mention the examples you used already exist in Fedora. I never advocated for more choices but you are trying to draw a arbitrary line. I don't find that acceptable. I let's hear it. Removing all the alternatives isn't an option. Is it? You already heard it: don't make it worse than it already is. That doesn't solve the existing problem at all. There is no reason why we should have say Epiphany but exclude Apache Openoffice. Every now and then I get bugs arising out of forks and downstream patches that get misfiled by confused users. Better tooling and metadata will mitigate the problem. Nothing will eliminate it entirely. That's just impossible -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
On Fri, Feb 8, 2013 at 12:44 PM, Debarshi Ray rishi...@lostca.se wrote: For starters: https://fedorahosted.org/fesco/ticket/669 Uhm that ticket is specifically about a feature proposal to include something as a default installed tech. We are not talking about AOO as a default installed package. You are conflating issues. Which is exactly what I politely asked that you avoid. Maybe if I say pretty please. Pretty please, don't mix up discussion about defaults with mere existence. zif and smart and dpkg as installable software are well within line for the repository collection. The mere existence of these as packaged technologies in our software repository is not a problem as user installable payloads. If this were a proposal to make AOO a default installed package for any official spin or install target for any pre-composed media image we provide as a project...I'll be right there with you shaking my fist and pressing the case for LO as the one and true default for situation which requires an office suite to be installed. But we aren't talking about that, so my i'm keeping my ire holstered. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
There are better ways to highlight that not to mention the examples you used already exist in Fedora. So do we have multiple kernels in Fedora? We offer .deb variants of Fedora? That doesn't solve the existing problem at all. There is no reason why we should have say Epiphany but exclude Apache Openoffice. Because we moved away from OpenOffice.org towards LibreOffice, and then AOO appeared on the horizon. Epiphany or Firefox do not share such a history. For what it is worth, I would very much like to streamline things there too, which is why I said initially: lets not make it any worse than it already is. (Once upon a time Epiphany had multiple backends, before it adopted WebKit as the only one [1]. So we atleast gave up on some choice there.) Cheers, Debarshi [1] https://mail.gnome.org/archives/epiphany-list/2008-April/msg0.html -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgpiNYHQ9ABiP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Le vendredi 08 février 2013 à 20:56 +, Debarshi Ray a écrit : especially since there is a default installed already. The first time I ran an installer 10 years ago, I remember staring at a screen which gave me 2 options: GNOME and KDE, and the description for both of them were exactly the same except those 2 words. I don't want an user staring at yum or gnome-packagekit or whatever and seeing 2 office suites which appear to be identical except for their names, and wondering what the hell is going on. So what can be done to show their difference? Make sure there is a different enough description, different icons, something else ? -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Hi On Fri, Feb 8, 2013 at 5:07 PM, Debarshi Ray wrote: So do we have multiple kernels in Fedora? We offer .deb variants of Fedora? Reductio ad absurdum. We will discuss serious considerations based on actual proposals on a case by case basis. Alternative office suites already exist in Fedora and adding one more is nowhere the same as adding an alternative kernel. That doesn't solve the existing problem at all. There is no reason why we should have say Epiphany but exclude Apache Openoffice. Because we moved away from OpenOffice.org towards LibreOffice, and then AOO appeared on the horizon. Right. When we moved from Openoffice.org to Libreoffice by default, AOO wasn't a choice at that point and when it did become available, we didn't rush to package it but now that an upstream developer has volunteered to maintain it, we let him do that. We are not switching defaults. We are not promoting it or advocating for it. Just making it available. Same as say Cinnamon. Nothing in our policy excludes it. and FESCo has accepted the proposal. End of story. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Le Ven 8 février 2013 21:30, Debarshi Ray a écrit : The FOSDEM poll was stacked ??? no one really wanted to hurt Vincent Untz too much given his obvious efforts to be nice, there was this knot of GNOME people bunched together that were a tad intimidating, and people do [...] So don't overplay the GNOME 3 FOSDEM session, it was an awkward moment for everyone involved (and certainly not representative of the positive energy that permeated other presentations). Sounds like bitterness to me. […] Now that the other side of the argument is coming to light, you are trying to cling on to your vociferous claims at all costs. Do you realise my vociferous claims didn't even include an opinion on which side of the argument the audience was leaning towards most? Can you please stop the stupid bunker mentality? I stand by my statement that this was a very awkward moment, with Vincent and the GNOME team radiating unhappiness and pretty much everyone else being perplexed and wondering whether they should take offence at being accused of being mad or if it was some weird form of apology. Certainly not the kind of celebration being portrayed here. As for the vocifering, I'll leave that to others. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
This thread is over. I'd like to ask everyone to take a few minutes to re-read: http://fedoraproject.org/code-of-conduct and get some away time from the discussion and think about things and how to approach discussions more constructively. Thanks, Stephen -- Stephen J Smoogen. Don't derail a useful feature for the 99% because you're not in it. Linus Torvalds Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Lennart, For better or worse Vincent Untz had people express themselves on systemd at FOSDEM, and pretty much everyone thought you were doing great. I can understand your regrets that it was less the case for your GNOME 3 friends, but that should not overshadow this great achievement of the systemd team. Given the scope of your work, I don't think anyone would have predicted a week ago systemd could attain such a complete adhesion. That is something to remember and rejoice on. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
On Fri, 8 Feb 2013 22:07:02 + Debarshi Ray wrote: So do we have multiple kernels in Fedora? We offer .deb variants of Fedora? Let me say one thing: if you're going by examples, go with proper ones. There is vast difference of work needed to support two kernels and work needed to support two office suites. You know kernel is the base upon everything runs, right? Please, don't make the most basic component that cannot be even switched without a whole lot of work as an example for choices. You just cannot support two kernels in one distribution. It's unsustainable amount of work, many tools/libs would have to have two versions shipped depending on the used kernel... This is totally different from having two *end-user apps*. (Once upon a time Epiphany had multiple backends, before it adopted WebKit as the only one [1]. So we atleast gave up on some choice there.) Yes, because there's a really lot more work need to have two backends (epiphany-webkit/epiphany-gecko) than two frontends (e.g. epiphany, midori) working. Needless to say that the backends usually conflict in runtime, unlike the frontends. And yes, I'm strongly against having AOO in repos *if* it'll conflict in runtime with LO. I'm starting to feel you are advocating the single app approach for everything... That's just nuts, unless you're building a proprietary device you do not want your users to tackle with. It's not just about choice. The choice is already here. You can install AOO from upstream (they even provide RPMs). But that's a road to hell. We package things to make it easier for our users to install software, not to offer them the choice. Everyone capable can ./configure make make install... Is there anyone willing to do the packaging work for AOO? Yes? Than why the hell should we stop him? AOO is *not* LO, will likely be even more different in the future; and it's not some base component like package manager, kernel, pulseaudio... Should we just limit ourselves to having only some default apps for each task and leaving the rest to 3rd party sources (e.g. upstream)? I don't think so. Having to choice might be hard sometimes (yes, I had the very same reaction as you, when I stared at IIRC RH7 anaconda explaining the difference between KDE and GNOME by one having KDE and the other GNOME in the description...), but the choice is already here, we're just making sure that the user can use whatever he chose easily -- within some reasonable limits. Also, people coming to linux from windows are (still?) more likely to know about AOO than LO, but many of them already know about both of them and already made their choice in Win. We want to make it hard to them to keep their SW of choice on linux even if the SW in question is FLOSS? Martin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Reductio ad absurdum. To me this is as absurd as the others. Right. When we moved from Openoffice.org to Libreoffice by default, AOO We could have kept the openoffice.org packages instead of replacing them with LO, but we did not. (I guess, at this point, it is quite clear that I am losing faith in the way Fedora functions.) Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgpkXvC7ApCrL.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Hi On Fri, Feb 8, 2013 at 5:54 PM, Debarshi Ray wrote: Right. When we moved from Openoffice.org to Libreoffice by default, AOO We could have kept the openoffice.org packages instead of replacing them with LO, but we did not. Yes because we had some problems with how openoffice.org was being developed which Libreoffice solved and this is the reason Libreoffice remains the default. That has not changed. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Let me say one thing: if you're going by examples, go with proper ones. There is vast difference of work needed to support two kernels and work needed to support two office suites. You know kernel is the base upon everything runs, right? Please, don't make the most basic component that cannot be even switched without a whole lot of work as an example for choices. Why not? We have ConnMan and upstart in the repos already. The way things are going I won't be surprised if someone sincerely proposed it. In fact a feature page was written which turned out to be a hoax. You just cannot support two kernels in one distribution. Such distros do exist. I don't think that the guiding principle should be: here is some FOSS code, lets package it. Cheers, Debarshi -- If computers are going to revolutionize education, then steam engines and cars and electricity would have done it too. -- Arjun Shankar pgpN__9QeYnD8.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
Hi On Fri, Feb 8, 2013 at 6:21 PM, Debarshi Ray wrote: I don't think that the guiding principle should be: here is some FOSS code, lets package it. Claiming what it shouldn't be is the easy part. Writing up a proposal on what the guiding principles should be and building consensus on it is the harder part. Are you willing to do that? If so, look up https://fedoraproject.org/wiki/Overview and prior discussions on Fedora advisory board list and elsewhere and build on it. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Apache OpenOffice
On Fri, 8 Feb 2013 20:50:11 + Debarshi Ray wrote: It is irrelevant whether it is a daemon or a GUI application. No, it is not. To stay with pulseaudio -- when you're playing a song, it's not exactly easy to tell if it goes to your headphones through alsa, oss, openal, pulseaudio, or a combination of these. When you encounter a bug in Office suite, it's really easy to tell if you're running Open Office or Libre Office, FWIW every sane DE shows the app name in their app launchers and the names follow LibreOffice Writer template. Whether it is editing a document or listening to audio, it is all about using some piece of software to get something done. It is not about spending loads of time to make the choice. So you're basically telling me that it's better to only have one office suite in repos? How about the lots of time finding where to download the better alternative (better fitting for my needs) I want to use, then spending hours figuring out, how to install it, only to end up with memory exhausted message doing linking? No thanks. I certainly prefer having to choice once and than yum install/update whenever new version of the software or fedora is released, than either being stuck with something I don't like or compiling a whole office suite every other month... Also, I don't *just* want to get something done, I want to do it quickly, effectively and well. That's not the same! There are things for which I use TeX, there are things for which I use LibreOffice Writer, and there are things for which Abiword is all I need. I don't think we should force on our diverse user base LibreOffice only. Some can do their work better in Calligra, some do prefer Apache Open Office. For those who know next to nothing, just want to write a document, there is default. As for developers, why would they have to deal with bug reports filed against the wrong component (AOO vs LO)? Are the people who don't know what app they're using really the target audience of Fedora? It might seem so from our desktop spin, with apps disguised as Files, Internet, ..., but I don't think that's the case. Cheers, Martin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /etc/mtab symlink PERMANENTLY mangeled
On 02/08/2013 12:57 AM, Reindl Harald wrote: would deveopers of core-packages take a look at this? https://bugzilla.redhat.com/show_bug.cgi?id=887763#c37 god knows what happens here with the /etc/mtab symlink BUT this all did never happen before the problems with /etc/mtab where solved by replace it with a symlink may i suggest to make nails with heads and fix packages that any usage of /etc/mtab is REPLACED with directly look at /proc/mounts? I believe this was a problem with upgrading util-linux with rpm-4.10.2-2 installed. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Fri, 8 Feb 2013 20:45:30 +0100 Stijn Hoop wrote: But I will keep objecting to the single-sided argument that there is no GNOME 2 user that likes GNOME 3. I fully support those who have tried and rejected the new stuff -- as long as they don't impose their opinion on me :-) I don't think anyone ever claimed such thing. What we (the Gnome 2 fans, but Gnome 3 haters) are saying is basically this: * Gnome 3 is a radical change from Gnome 2, in many ways, and for many people this was an unacceptable direction. These were numerous enough to get Cinnamon, Mate and Unity up and working. Some of those (including me) expanded XFCE (or other classical desktops) user base. These combined are a real lot of people. These users aren't going to return. * Gnome devs didn't learn from KDE's mistake (the release of beta stuff as 4.0) and went even further. Users affected by only this might return (like Linus did). * Gnome 3's target audience does not enclose majority of Gnome 2's target audience, though it *does* have some intersection. Many of those are seeing this as arrogance. * Some trivial stuff is taking months to years to re-implement (shut down). * Gnome 3 is going the I-know-better-then-you-what's-good-for-you way. That's one of the reasons why many of us are using linux than windows -- because it traditionally *does not* do so. Randomly breaking things with messages like (oops, something went wrong, please try again) or things behaving unpredictably is *not* the linux way. * We think Gnome 3 is doing similar type of mistake as Windows 8. * We believe that due to the differences between Gnome 2 and Gnome 3, many users left Fedora during the switch. * We think that if we changed default desktop now, it would be less disruptive than when we switched from G2 to G3, because we wouldn't be switching to beta project, however I think that neither Cinnamon and Mate are good candidates. They're too recent both in the world and in Fedora repos. I'd rather have G3 as default than another semi-beta or monolithic-DE-maintained-by-two-or-three people stuff. * gnome devs are systematically removing features many former gnome users thought were useful, and sometimes adding them back again after a year or so of complains. We perceive that as devs doing whatever they wont and ignoring the real users in favour of some imaginary ones. * huge overuse of symbolic icons (this includes the new anaconda) * maybe I forgot something Not every former gnome user agrees with these, but they're probably the ones that are most prominent. Martin 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 Sat, Feb 9, 2013 at 1:23 AM, Martin Sourada martin.sour...@gmail.com wrote: * Gnome devs didn't learn from KDE's mistake (the release of beta stuff as 4.0) and went even further. Users affected by only this might return (like Linus did). I can't recall that many stability bugs getting reported against GNOME 3.0 ... so [citation needed]. * Gnome 3's target audience does not enclose majority of Gnome 2's target audience, though it *does* have some intersection. Many of those are seeing this as arrogance. Being different does not imply different target audience ... same thing and discussion happened when GNOME 2.0 got released. Now the haters from back then want GNOME 2.0 back ;) * Some trivial stuff is taking months to years to re-implement (shut down). Nonsense. Shutdown has always been implemented. It just got presented differently. * Gnome 3 is going the I-know-better-then-you-what's-good-for-you way. Sure by giving you an extension system that allows you to do whatever you want with the desktop That's one of the reasons why many of us are using linux than windows -- because it traditionally *does not* do so. Randomly breaking things with messages like (oops, something went wrong, please try again) or things behaving unpredictably is *not* the linux way. Strawman. * We think Gnome 3 is doing similar type of mistake as Windows 8. GNOME3 has nothing to do with windows 8 other than both work better on touch devices then previous releases supporting new hardware isn't really a bad thing imo. * We believe that due to the differences between Gnome 2 and Gnome 3, many users left Fedora during the switch. [citation needed]. Anecdotes do not count (there are user that switched to Fedora because they wanted a good GNOME 3 experience). * gnome devs are systematically removing features many former gnome users thought were useful, and sometimes adding them back again after a year or so of complains. We perceive that as devs doing whatever they wont and ignoring the real users in favour of some imaginary ones. * huge overuse of symbolic icons (this includes the new anaconda) That's a problem why exactly? Actually it is the opposite ... stuff looks way better and polished if you compare it to the GNOME2. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Fri, Feb 8, 2013 at 3:37 PM, drago01 drag...@gmail.com wrote: Being different does not imply different target audience ... same thing and discussion happened when GNOME 2.0 got released. Now the haters from back then want GNOME 2.0 back ;) Can we start a new thread about bringing sawfish back as the default window manager. Because really, it had a lot of features that I have been missing through the entire g2 experience. -jefsort of not jokingspaleta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Sat, 9 Feb 2013 01:37:03 +0100 drago01 wrote: I can't recall that many stability bugs getting reported against GNOME 3.0 ... so [citation needed]. Well the fallback mode being a poor man's excuse was partly the case why the people couldn't stay with gnome. Loads of features weren't implemented in 3.0. If anything Gnome 3.0 was more of a technology preview than fully usable desktop. Nonsense. Shutdown has always been implemented. It just got presented differently. That's even more the reason -- the code was present, so it was not a problem of not having the human resources to make it work as expected by users. It was just the devs being stuck on the mundane idea that it's bad to have it shown by default. * Gnome 3 is going the I-know-better-then-you-what's-good-for-you way. Sure by giving you an extension system that allows you to do whatever you want with the desktop 1st Gnome 3 isn't just a gnome shell, gnome apps are getting worse as well (but there are also some positive trends) 2nd Yes, three major releases after 3.0 we finally get something that can be used by majority of gnome 2 user base. I'm sorry, but that's too late for most of them to think of going back. GNOME3 has nothing to do with windows 8 other than both work better M on touch devices then previous releases supporting new hardware isn't really a bad thing imo. I think they've done the same mistake, that does not implicate that they have anything else to do with each other (besides gnome shell is older than Win 8). Being neither cat nor dog isn't a good thing, IMHO. Either you optimize for touch devices or for traditional input, not for both. * We believe that due to the differences between Gnome 2 and Gnome 3, many users left Fedora during the switch. Notice the wording I used. I'm not presenting it as fact, but as a belief based on experience. There aren't any acceptable statistics to either prove or disprove the claim. Anecdotes do not count (there are user that switched to Fedora because they wanted a good GNOME 3 experience). That users left does not imply new didn't come ;-) * huge overuse of symbolic icons (this includes the new anaconda) That's a problem why exactly? Actually it is the opposite ... stuff looks way better and polished if you compare it to the GNOME2. Better? Polished? Those huge lumps of blurry grey stuff you have no idea what they represent? Oh yes, on my BW e-book reader they look awesome, but on desktop? Are we back in the days when displays didn't display colour? I tried directly comparing Nautilus with Thunar, side-by-side, in F18. It's actually Nautilus that looks like from last millennium, not Thunar. Despite having otherwise very similar interface. I'm not against symbolic icons ideologically. They have their place in modern desktop. But when they are used too much, and in bigger sizes, they tend to be bland. Plus, as they are actually composed of no more than 2 or 3 shades/colours, they're very limited in how they can look, so having too much of them is severely damaging your ability to tell them apart. And while talking about polish -- why in the world is the Adwaitha scrollbar a grey rounded rectangle while almost everything else in the theme is shaded with gradients, shadows and distinct borders? No, I definitely cannot talk about polish when speaking about Gnome 3. In some places yes, but it's hugely inconsistent. Looks like half-done work (some areas polished [almost] professionally, while others are bland and non-fitting with the rest). IMHO Martin 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
Could we move this to a gnome/desktop list? The subject of the thread has been decided... I don't think it's providing much value to the Fedora devel community anymore. 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 Fri, 8 Feb 2013 18:21:00 -0700 Kevin Fenzi wrote: Could we move this to a gnome/desktop list? The subject of the thread has been decided... I don't think it's providing much value to the Fedora devel community anymore. Ah, yes, my apologies. I would rather end this off topic sub-thread altogether. I don't want another flame, and I've already said pretty much everything what I wanted to say, anything else would be just rephrasing that... Martin 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 Fri, Feb 8, 2013 at 8:21 PM, Kevin Fenzi wrote: Could we move this to a gnome/desktop list? The subject of the thread has been decided... I don't think it's providing much value to the Fedora devel community anymore. +1. Gnome 2 was counterintuitive enough. I can't imagine how Gnome 3 is like after all these comments (I never dared to try). Please continue the discussion in some Gnome mailing list. Thanks, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Can a admin pls close this topic? boring since some days, people who don't want use gnome anymore are branded as 'haters' and 'reactionary'. .i don't and want follow your logic. regards, Wolfgang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive Maintainer: mediawiki
I've handed up with this question when I first request for an upgrade of mediawiki. I remember someone told me that upgrading may cause errors of custom css or custom theme,is it true? 在 2013-2-9 AM5:37，Pete Travis li...@petetravis.com写道： On Feb 8, 2013 12:54 PM, Stephen John Smoogen smo...@gmail.com wrote: . Two the fix is to upgrade to a very new version which will break everyone who upgrades until they (or the first person who gets to the website :) ) runs the upgrade mode.. which might not work due to either custom changes or the fact that it is a large upgrade change. -- Stephen J Smoogen. I haven't poked at mediawiki in a while, so please correct me if I'm wrong, but isn't it fairly self contained? I recall copying the content from /usr/share/ to /var/www/ then localizing. Having a new version shouldn't break existing deployments unless they are served out of /usr/share/, and that doesn't seem sane. The update would then be available, not imposed. --Pete -- 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
