Re: Unhelpful update descriptions
On Mon, Mar 11, 2013 at 10:37 PM, Rahul Sundaram methe...@gmail.com wrote: On 03/12/2013 01:30 AM, Dan Mashal wrote: Semantics. Providing a link is helpful to users isn't semantics. You as a package maintainer would be aware of where to look for reviewing the changes before pushing an update. Users don't since it is different for different projects and is not necessarily obvious or even easily searchable. Just take that few seconds of additional effort and provide the link. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Right because you do that for every single update you push? Honestly, I'm done arguing my point. Other people in this thread have made arguments for it, other people including yourself have made arguments against it. This is turning into a what should the default desktop be discussion. So I'm dropping off. This is a SHOULD not a MUST. If you have packaged for a while, you'd get that. From your previous emails it doesn't seem you are. Hopefully, this one makes my point more clearly. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On 03/12/2013 02:39 AM, Dan Mashal wrote: Right because you do that for every single update you push? For new upstream releases, I certainly try to. Honestly, I'm done arguing my point. Other people in this thread have made arguments for it, other people including yourself have made arguments against it. This is turning into a what should the default desktop be discussion. So I'm dropping off. This is a SHOULD not a MUST. If you have packaged for a while, you'd get that. From your previous emails it doesn't seem you are. Hopefully, this one makes my point more clearly. Dan I have been packaging long before Fedora even existed and maintain/co-maintain over a hundred RPM packages for Fedora but that's besides the point. Providing links in the changelog is just good practice. Telling that users can just google isn't. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, Mar 11, 2013 at 10:30:13PM +0100, Björn Persson wrote: After a few iterations I'd also be cursing the idiots who designed such an unfriendly user interface just because they didn't want any text on the screen. After a few iterations you should just enable bootloader menu with timeout appropriate for you. -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Mon, Mar 11, 2013 at 11:49 PM, Rahul Sundaram methe...@gmail.com wrote: On 03/12/2013 02:39 AM, Dan Mashal wrote: Right because you do that for every single update you push? For new upstream releases, I certainly try to. Honestly, I'm done arguing my point. Other people in this thread have made arguments for it, other people including yourself have made arguments against it. This is turning into a what should the default desktop be discussion. So I'm dropping off. This is a SHOULD not a MUST. If you have packaged for a while, you'd get that. From your previous emails it doesn't seem you are. Hopefully, this one makes my point more clearly. Dan I have been packaging long before Fedora even existed and maintain/co-maintain over a hundred RPM packages for Fedora but that's besides the point. That's great. I looked at your bodhi pushes. Good for you. Providing links in the changelog is just good practice. Telling that users can just google isn't. Rahul But it's not a requirement. And again, sometimes upstream does not provide a changelog. Is this is in the Fedora packaging/updating guidelines? I'm not doubting your technical skills. I'm making a few points. a) sometimes upstream doesn't provide a changelog b) sometimes you have a LOT of packages to push out. c) sometimes even you yourself don't know what to put in the notes. d) sometimes there's really not much else to put at all. e) different packagers have different upstreams to work with, which goes back to point A. The updates sit in updates-testing for 7+ days before being moved to stable. At any which point anyone can leave negative karma if there is an issue. Looking at your updates you got negative karma and pushed to stable anyway. Like I said, I'd rather not get in semantics. I'm just making a point. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Mon, Mar 11, 2013 at 11:57:00PM -0700, Dan Mashal wrote: I'm not doubting your technical skills. I'm making a few points. b) sometimes you have a LOT of packages to push out. c) sometimes even you yourself don't know what to put in the notes. d) sometimes there's really not much else to put at all. This sounds like updates that SHOULDN'T be pushed. If update has no changes worth mentioning, it is trivial - trivial updates should not be pushed. -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
在 2013-3-12 PM3:03，Tomasz Torcz to...@pipebreaker.pl写道： This sounds like updates that SHOULDN'T be pushed. If update has no changes worth mentioning, it is trivial - trivial updates should not be pushed. If upstream release a minor bug fix version, what should we do? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Tue, 2013-03-12 at 15:14 +0800, Christopher Meng wrote: 在 2013-3-12 PM3:03，Tomasz Torcz to...@pipebreaker.pl写道： This sounds like updates that SHOULDN'T be pushed. If update has no changes worth mentioning, it is trivial - trivial updates should not be pushed. If upstream release a minor bug fix version, what should we do? 在 2013-3-12 PM3:03，Tomasz Torcz to...@pipebreaker.pl写道： This sounds like updates that SHOULDN'T be pushed. If update has no changes worth mentioning, it is trivial - trivial updates should not be pushed. If upstream release a minor bug fix version, what should we do? Then the update is not trivial, and you know what to put in the update notes: just talk about this bug fix. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On 03/12/2013 03:14 AM, Christopher Meng wrote: 在 2013-3-12 PM3:03，Tomasz Torcz 写道： This sounds like updates that SHOULDN'T be pushed. If update has no changes worth mentioning, it is trivial - trivial updates should not be pushed. If upstream release a minor bug fix version, what should we do? How do you know it is minor without a changelog? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Tue, Mar 12, 2013 at 12:28 AM, Mathieu Bridon boche...@fedoraproject.org wrote: On Tue, 2013-03-12 at 15:14 +0800, Christopher Meng wrote: 在 2013-3-12 PM3:03，Tomasz Torcz to...@pipebreaker.pl写道： This sounds like updates that SHOULDN'T be pushed. If update has no changes worth mentioning, it is trivial - trivial updates should not be pushed. If upstream release a minor bug fix version, what should we do? 在 2013-3-12 PM3:03，Tomasz Torcz to...@pipebreaker.pl写道： This sounds like updates that SHOULDN'T be pushed. If update has no changes worth mentioning, it is trivial - trivial updates should not be pushed. If upstream release a minor bug fix version, what should we do? Then the update is not trivial, and you know what to put in the update notes: just talk about this bug fix. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Forget it. There is such a double standard here and exceptions to many rules. This is a worthless conversation. Good on ya if you put in the extra effort. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: twinkle: Intent to retire
On Tue, 12 Mar 2013 02:03:16 +0100, Jared K. Smith wrote: On Mon, Mar 11, 2013 at 7:02 PM, Richard W.M. Jones rjo...@redhat.com wrote: Has Fedora *ever* had a functional soft-phone? I ask this because I have tried many, and none of them *ever* worked [...] I've successfully used Twinkle for the last three or four years, Using SIP since 2005 as mostly the only phone and Twinkle was always the only one that worked, despite I tried many. I never wanted to use Twinkle due to its ugly GUI but Twinkle just always worked. I *once* had Ekiga working, but it gave me so many problems a few years ago that I had given up on it. Exactly. I even bugreported multiple SIP incompatibilities and got them fixed in opal but it still was not enough for practical use. Maybe it has changed. Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: twinkle: Intent to retire
On Tue, Mar 12, 2013 at 7:36 AM, Jan Kratochvil jan.kratoch...@redhat.com wrote: On Tue, 12 Mar 2013 02:03:16 +0100, Jared K. Smith wrote: On Mon, Mar 11, 2013 at 7:02 PM, Richard W.M. Jones rjo...@redhat.com wrote: Has Fedora *ever* had a functional soft-phone? I ask this because I have tried many, and none of them *ever* worked [...] I've successfully used Twinkle for the last three or four years, Using SIP since 2005 as mostly the only phone and Twinkle was always the only one that worked, despite I tried many. I never wanted to use Twinkle due to its ugly GUI but Twinkle just always worked. I *once* had Ekiga working, but it gave me so many problems a few years ago that I had given up on it. Exactly. I even bugreported multiple SIP incompatibilities and got them fixed in opal but it still was not enough for practical use. Maybe it has changed. Ekiga v4 seems to have improved a number of the problems and as the Fedora maintainer I've been working closely with upstream since it's release to close out any remaining issues, 4.0.1 appears to be a reasonable bugfix release but if you do have issues please report a bug and we'll work with upstream to get them fixed. Upstream seems to have been reinvigorated of late. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New groups in comps for F19
Hi guys, as per [1], I'd like to propose some patches for F19 comps. These patches are splitting group called Development Tools into several smaller groups. The purpose of this email is to find out if there is something fundamentally wrong with the change (except for the fact that it is change). These are key points about the patch set: 1. There should be only small visible impact to users. Currently the only tool that is commonly using comps is anaconda and that uses the Developer workstation environment. This group will contain all groups that were created by the split to ensure maximal similarity to the old state of things. 2. All in all, the Development Tools group needed a huge cleanup, as it contained a lot of different tools and/or devel packages but many times these were only fractions of development environments necessary for the particular purpose. These tools are mostly still avaiable in other groups, like C development, Electronic Lab, ... 3. The current idea for Developer Tools group is to contain just tools that are common/usable for development of most programming languages 4. This should bring only the big picture change. No need to discuss what particular packages should be in which group. That can be tuned any time later. 5. More groups targeted at specific areas should be created and/or reviewed soon-ish. Among them: Perl Development Python Development Ruby Development feel free to suggest more development-related areas that you would like to improve. The goal of this effort is to start a process which would lead to more usable comps, so users will be able (and more importantly encouraged) to simply use for example yum to install these environments. By that time, these environments should be cleaned up, in case user wants to install just specific type of devel env, not the entire Developer Workstation [1] https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups Thanks Jan patches.tar.gz Description: application/compressed-tar -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, Mar 11, 2013 at 10:22 PM, seth vidal skvi...@fedoraproject.org wrote: On Mon, 11 Mar 2013 16:18:33 -0500 Michael Cronenworth m...@cchtml.com wrote: On 03/11/2013 04:13 PM, seth vidal wrote: I want to encourage kids, teenagers, etc to explore the OS. We need them to be involved in CREATING and LEARNING. So I don't want to scare any of them off. My OLPC does not present any boot menu or prompt. That's not an argument for why we should not present one. It is an argument for why they should be. Sorry but that's nonsense. Pretty much all other operating systems do not display the boot loader by default and you see this as a reason for showing it? What kind of weird logic is that? Or do you really think we can have we do show a screen that you won't care about most of the time on every boot as a selling point for fedora? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 916154] Bad summary
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=916154 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- perl-Data-Validate-IP-0.18-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. -- 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=n4xYTfUA7Na=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: Unhelpful update descriptions
- Original Message - Adam Williamson awill...@redhat.com writes: On 11/03/13 06:28 PM, Toshio Kuratomi wrote: That's not readily apparent in the Updates Policy ... Ah, you're right, I really should have checked it before posting (yet again). I was thinking that it discouraged *all* version updates, not just major ones. I personally would still be hesitant to update a package to a new upstream version if I didn't know what the heck was in it, but that is indeed apparently just a personal preference and not a policy :) I think there's no substitute for knowing your upstream --- and therefore, not a whole lot of scope for a one-size-fits-all distro-wide policy. Yep, it was my main concern when these rules were set-up - every upstream is different. And you have to know your upstream and understand their release policies. So sometimes it ends up I just update to a new version even without Changelog (sometimes it's just forgotten) if I trust the upstream and I know even this update will be valuable. Even I feel a bit bad in such case ;-) Jaroslav In my case, I work mostly with upstreams that are pretty conservative about what they fix in minor releases, and I would think it irresponsible *not* to push out their minor updates into released Fedora branches. Other upstreams are a lot different though. I'm for leaving this to the package maintainer's discretion. Now, there's no harm in having the guidelines try to explain how to exercise that discretion. Maybe the existing text could use refinement. It doesn't seem that bad as it stands, though. regards, tom lane -- 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: Unhelpful update descriptions
- Original Message - On 03/12/2013 01:30 AM, Dan Mashal wrote: Semantics. Providing a link is helpful to users isn't semantics. You as a package maintainer would be aware of where to look for reviewing the changes before pushing an update. Users don't since it is different for different projects and is not necessarily obvious or even easily searchable. Just take that few seconds of additional effort and provide the link. Yep, I think the link, when available, is very useful. What I try is to pick up a few most important changes directly affecting Fedora and then I link full Changelog. So maybe idea - what about a dedicated field in Bodhi for upstream's Changelog and then present it for users in PackageKit in a some nicer way - real, clickable link... Not sure it will be possible in our Packaging GUIs and also we try to hide updates as much as possible from our users... Jaroslav Rahul -- 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: Review Request 16: Initial Packaging Work
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/16/#review16 --- This looks good to me. - Martin Krizek On March 7, 2013, 11:38 p.m., Tim Flink wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/16/ --- (Updated March 7, 2013, 11:38 p.m.) Review request for blockerbugs. Bugs: 337 https://fedorahosted.org/fedora-qa/ticket/337 Repository: blockerbugs Description --- Initial packaging work and reworking all the various cli scripts into a single module to make it more packaging friendly Diffs - update_blockers.sh d5229ea9b54119608e73cabcabbaaf4d99248876 sync_db.py 3489434c9cd6dc4f67ad82f61b171f94c4d65793 setup.py b4a51dc9c4bb9dadbd5ada286b8ddd5448811886 run_cli.py PRE-CREATION initialize.py eb3c3e160e66f5f044e20f53ff79994820fd4a7e init_db.sh 540dcb1f4baff9d7d0cad0dc75d67a4d6f3c3a98 docs/source/installation.rst PRE-CREATION docs/source/index.rst PRE-CREATION docs/source/development.rst PRE-CREATION docs/source/conf.py PRE-CREATION docs/Makefile PRE-CREATION doc/source/installation.rst 41319a6c345987bf50663ae4ff88068aed81334c doc/source/index.rst f07f013268aaa01cec780efec6e320c6cb267339 doc/source/development.rst 35b1b34a6b81d8d35e91fb11d32b35dc5d8269a9 doc/source/conf.py fc14e55effbd22e0c2b4fef5c7a395d16f0a5f70 doc/Makefile 8c16a97606680359188461c22ef48777b5ee9ee0 blockerbugs/cli.py PRE-CREATION blockerbugs/__init__.py 9030c04ee244ce21439075be9c446a83c05ed9ae blockerbugs.spec PRE-CREATION alembic.ini 848a3873008f231b03c12c4bcfe6d7367527f8fc Diff: http://reviewboard-tflink.rhcloud.com/r/16/diff/ Testing --- I've done a bunch of local testing and have a staging instance set up in the cloud: https://209.132.184.164/blockerbugs/ Thanks, Tim Flink ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Unhelpful update descriptions
- Original Message - On Mon, Mar 11, 2013 at 11:57:00PM -0700, Dan Mashal wrote: I'm not doubting your technical skills. I'm making a few points. b) sometimes you have a LOT of packages to push out. c) sometimes even you yourself don't know what to put in the notes. d) sometimes there's really not much else to put at all. This sounds like updates that SHOULDN'T be pushed. If update has no changes worth mentioning, it is trivial - trivial updates should not be pushed. I understand the trivial update more as trivial change in a SPEC file, not a new minor upstream release. Maybe it needs more clarification. For example a typo fix in description field in a SPEC file, it's definitely not worth to issue an update and disturb user with an update. And yes, sometimes even typo could be a reason for update if it misleads users in a bad manner (not likely). The second part is clear - if the release fixes only Windows build issue, no reason to update and I expect our maintainers are clever enough not to update it ;-) Jaroslav -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen -- 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: Fedora 18 and new version of Gnome (3.7.x)
Il giorno mer, 06/03/2013 alle 12.51 +, Richard W.M. Jones ha scritto: Upgrading to Fedora 19 is not good for end users. That's rather negative. We want to encourage testers. I would suggest to the original poster: Thank Richard! your instructions is what I'm looking for. Thanks! -- Dario Lesca - sip:da...@solinos.it (Inviato dal mio Linux Fedora18+Gnome3) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Tue, Mar 12, 2013 at 11:37 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 12.03.2013 09:55, schrieb drago01: On Mon, Mar 11, 2013 at 10:22 PM, seth vidal skvi...@fedoraproject.org wrote: On Mon, 11 Mar 2013 16:18:33 -0500 Michael Cronenworth m...@cchtml.com wrote: On 03/11/2013 04:13 PM, seth vidal wrote: I want to encourage kids, teenagers, etc to explore the OS. We need them to be involved in CREATING and LEARNING. So I don't want to scare any of them off. My OLPC does not present any boot menu or prompt. That's not an argument for why we should not present one. It is an argument for why they should be. Sorry but that's nonsense. Pretty much all other operating systems do not display the boot loader by default and you see this as a reason for showing it? What kind of weird logic is that? Or do you really think we can have we do show a screen that you won't care about most of the time on every boot as a selling point for fedora? who cares about OTHER operating systems? You can't develop an operating system while living under a rock you have to look at what the competition does. if i would want their behavior i would install them Strawman. are you guys booting the whole day your machines that save 2 seconds is woth any discussion? Yes 2 seconds is a LONG time when your system is using an SSD. Booting should be instant there is no reason why we should have to wait before being able to use the system. (killing grub delay gets us closer to that goal). I'd say booting is a more common task then messing with bootloader options so lets optimize for the former rather then the later. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/11/2013 09:16 PM, Lennart Poettering wrote: On Mon, 11.03.13 13:08, Chris Murphy (li...@colorremedies.com) wrote: On Mar 11, 2013, at 11:31 AM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: Or nothing at all displayed unless the user happens to know to press some key at the right moment? A multiboot system needs at least a message to inform the user how to get to the boot manager (the GRUB menu). A Fedora only system probably should entirely suppress the menu or notice how to get to it. Somebody who is capable of installing multiple operating systems on one machine should easily be savvy enough to remember that pressing shift/esc/space/f2/whatever gets him the boot menu. In a multiboot scenario you normally once switch off all bootscreen suppression and will not look into again until something breaks it. If you installed multiple OSes and noticed that the boot menu is gone, wouldn't pressing these keys be your natural reaction anyway? No. Because switching off bootmenu suppression is a one-time job, you will have forgotten what to do if something switches of bootmenus. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Hi all, On the question of how kernel versions should be accessed, I am very much in favour of the position that Chris Murphy expressed earlier: choosing a kernel version is opaque to most users and requires fairly advanced technical knowledge to understand. Invitations to access boot options (such as a string reading Press Esc to access boot options) run the risk of enticing people into a part of the UI that isn't useful and that they don't understand. Having a key (or keys) that you need to know about to access these options makes a lot of sense: the people who know about booting kernel versions will go looking for a way to access the menu [1], if they don't know the menu already. Those who don't know what the menu is for can happily ignore it. It's also worth remembering that even those users who do understand what it means to boot into a different kernel will do so infrequently. With regards to the question of which key or keys should be used for accessing the menu, it seems like a good idea to avoid keys that are already used for accessing BIOS options: if we are going to be telling people to turn their machine on and hold down a key, we don't want them ending up in their BIOS configuration by accident. Common keys for that include F1, F2, F10, Del or Esc. Perhaps Ctrl would make a good choice for us. In terms of the the look and feel of the grub menu and boot progress, I think it's important that we ensure consistency with the login screen and try to have as little visual noise as possible (meaning that we need to keep the number of visual transitions to a minimum), since this will communicate quality and robustness to users. In that respect, a minimal boot screen with a plain black background followed by a boot progress screen that uses the same background as GNOME login would be a big step forward. Allan [1] The main requirement here is that a Google search gives you the answer when you go looking for it. :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting assistance with packaging a web app: wikindx
Hi folks, On Mon, 2013-03-11 at 17:58 -0700, Adam Williamson wrote: No-one's answered the simplest part of the question yet :) You can make httpd 'use the files in /usr/share' simply by including a config snippet in /etc/httpd/conf.d/ . As Kevin suggests, Wordpress is a decent example, but roundcubemail's happens to be even simpler. Just to do the directory thing, all it really needs is something like this: Alias /roundcubemail /usr/share/roundcubemail i.e. /roundcubemail under the web server root is /usr/share/roundcubemail on the local file system. The mediawiki approach isn't really appropriate for a simple webapp. Thank you for the detailed response Adam. I'm going to start with roundcubemail and try to package wikindx4 in a similar manner. Maybe I'll write up a wiki page after words that folks can refer to in the future. -- Thanks, Warm regards, Ankur: FranciscoD Please only print if necessary. Looking to contribute to Fedora? Look here: https://fedoraproject.org/wiki/Fedora_Join_SIG http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
On 08/03 12.56, Michael Scherer wrote: Le mardi 05 mars 2013 à 11:34 +0100, Bjorn Munch a écrit : The package we have ready as an upgrade of the existing one removes some no longer needed patches, adds a few new patches, updates the spec file of course, and also adds an rpmlintrc file. It has of course been tested on a Rawhide installation. What do you mean by adding a rpmlintrc file ? Sorry for late reply, I was away. We have run rpmlint on the package and it reported a number of problems. Many have been fixed, but this file lists a couple of problems to be ignored. Either they're not actually errors (e.g. a few zero length files) or they should be fixed upstream. - Bjorn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, Mar 11, 2013 at 5:58 PM, Matthias Clasen mcla...@redhat.com wrote: I would love to see F19 make a good first impression. The first time you see something Fedora-related on the screen currently is the graphical grub screen, followed by the filling-in-Fedora of Plymouth, followed by the gdm login screen. snip Can we postpone this tinkering with colors, logos, pixel positioning, and bootloader defaults that matter only for users that actively watch for them, until basic functionality in the ordinary use case that users _have to_ interact with is solid? Like having a prompt for the hard disk passphrase that tells the user in text what is necessary, and actually looks like a text input field? (Have you seen how confused a newbie is when turning on a Linux computer owned by somebody else and encountering the prompt?) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 2013-03-12 12:45, Miloslav Trmač wrote: On Mon, Mar 11, 2013 at 5:58 PM, Matthias Clasen mcla...@redhat.com wrote: I would love to see F19 make a good first impression. The first time you see something Fedora-related on the screen currently is the graphical grub screen, followed by the filling-in-Fedora of Plymouth, followed by the gdm login screen. snip Can we postpone this tinkering with colors, logos, pixel positioning, and bootloader defaults that matter only for users that actively watch for them, until basic functionality in the ordinary use case that users _have to_ interact with is solid? Like having a prompt for the hard disk passphrase that tells the user in text what is necessary, and actually looks like a text input field? (Have you seen how confused a newbie is when turning on a Linux computer owned by somebody else and encountering the prompt?) Mirek This is a bootloader aspect. As for the continued boot, there is the case when a boot which normally goes fast suddenly stalls without any user feedback when doing a disk check. This is actually a source of FUD. The easy fix here would be something like Press F1 to see what's going on. Many (admittedly not all) users would then find fsck counting blocks and find some comfort in that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, Mar 11, 2013 at 3:49 PM, Michael Cronenworth m...@cchtml.com wrote: Does any other computing device you own prompt you for a boot menu? Your mobile phone? Your TV (which likely has embedded Linux)? Your car? Windows? OS X? Why is that? Could it be because a boot menu is not necessary for normal operation? A normal user doesn't need to wonder Hey what kernel do I need to boot today? every time their system boots. And a napking is not necessary for normal eating. Nevetheless, most of us spill enough crumbs or get enough smears on our faces from messy food that it's often useful. And enough of us do kernel selection for configuration testing, or dual-boot systems with Linux on one disk and Windows on another partition or disk, that it's quite useful. Virtualization has eased the need for this, but I've needed to get at grub 3 times this month in development environments. There is a time when developers need to distance themselves from user-interfaces and realize they are not the only user of the user-interface. This is one of those times. And the main lesson her is don't clutter the user interface with useless graphical eye candy. It makes the boot process require unnecessary system resources. The new Fedora installation setup is currently a *nightmare*. It works very poorly through low bandwidth remote connections, the graphics are poorly labeled and very confusing, and the spoke and hub model is a bit of big vision coneptual weirdness that is actively preventing people from wanting to touch Fedora. It's an *installer*, keeping it as lightweight and simple as possible with minimal graphics means that it will display better on small virtual system or remote KVM displays. But this has been discarded in favor or an overly bulky and complex system that is showing off what are quite fragile graphical features rather than simply doing the *job*. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Allan Day píše v Út 12. 03. 2013 v 11:15 +: Hi all, On the question of how kernel versions should be accessed, I am very much in favour of the position that Chris Murphy expressed earlier: choosing a kernel version is opaque to most users and requires fairly advanced technical knowledge to understand. I agree, but unfortunately, it's not the case of Fedora. By having a rolling release policy for the kernel, we're forcing users to deal with kernel versions. I follow user forums quite a lot and I read it every day: I updated and my wireless card stopped working, my computer doesn't wake up from suspend, the system is now much slower. New kernels bring a lot of regressions and we don't have enough test coverage to avoid them. The general solution to those problems is to go back to the last working kernel version. But by making it less obvious we make these frequent problems more difficult to solve. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, Mar 11, 2013 at 4:16 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 11.03.13 13:08, Chris Murphy (li...@colorremedies.com) wrote: On Mar 11, 2013, at 11:31 AM, Björn Persson bj...@xn--rombobjrn-67a.se wrote: Or nothing at all displayed unless the user happens to know to press some key at the right moment? A multiboot system needs at least a message to inform the user how to get to the boot manager (the GRUB menu). A Fedora only system probably should entirely suppress the menu or notice how to get to it. Somebody who is capable of installing multiple operating systems on one machine should easily be savvy enough to remember that pressing shift/esc/space/f2/whatever gets him the boot menu. If you installed multiple OSes and noticed that the boot menu is gone, wouldn't pressing these keys be your natural reaction anyway? Lennart I've been a hardware evaluator. Absolutely not, because different hardware components have different, and fundamentally unpredictable, configuration keys. Hiding the particular configuration key for the bootloader, that may be only work for a few seconds in a lengthy boot process on, say, an HP high end controller with several disk controller cards, is wasting the system engineer's time with repeated reboots where *she can't tell when to push the escape button without triggering the wrong configuration tool*. I would reject out of hand tools that did this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Hi, On 03/12/2013 01:02 PM, Jiří Eischmann wrote: Allan Day píše v Út 12. 03. 2013 v 11:15 +: Hi all, On the question of how kernel versions should be accessed, I am very much in favour of the position that Chris Murphy expressed earlier: choosing a kernel version is opaque to most users and requires fairly advanced technical knowledge to understand. I agree, but unfortunately, it's not the case of Fedora. By having a rolling release policy for the kernel, we're forcing users to deal with kernel versions. I follow user forums quite a lot and I read it every day: I updated and my wireless card stopped working, my computer doesn't wake up from suspend, the system is now much slower. New kernels bring a lot of regressions and we don't have enough test coverage to avoid them. The general solution to those problems is to go back to the last working kernel version. But by making it less obvious we make these frequent problems more difficult to solve. Keep in mind that the not show the menu by default plan depends on the bootspec changes, and that will include a gui tool which will allow users to select things like show the menu (and then it won't have a timeout so be easier to get to), or even to directly select the kernel to boot next time. I do agree that having such a tool in place is a requirement for disabling the menu, we must get the ordering right, iow first the bootspec tool, then disable the menu by default. This could be as easy as a dialog / ncurses tool for starts, but we must have a tool to do this *first*. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On Mon, 11 Mar 2013 19:58:03 +0100, Kevin Kofler kevin.kof...@chello.at wrote: Honza Horak wrote: This doesn't solve all the issues -- if package like akonadi-mysql says Requires: mysql-server, then Oracle MySQL either wouldn't satisfy that requirement or (in case it includes Provides: mysql-server) RPM choosing behavior would be ambiguous. And it should not satisfy it. We now changed the Requires in akonadi-mysql to mariadb-server to be sure of what we get. This dependency is a problem. It makes it impossible to install MySQL-server on a KDE system since mariadb-server and MySQL-server conflict. This would all be solvable if the packages were installable in parallel, which is also the recommended solution [1]. This would require some renaming, but it has several benefits: - Users can choose to install either MySQL or MariaDB, or both. - Package maintainers can choose to depend on one or the other. - Package maintenance becomes easier since the packages don't mess around with the same filenames. A common virtual provide should solve dependencies for applications that don't care which server they get. With that virtual provide comes the upgrade issues around choosing a default. Could this be solved by bumping the epoch of mariadb-server? Wouldn't that make yum choose the highest versioned package, which would always be mariadb-server? Epoch bumping may not be the prettiest solution, but if it works, we could do: If existing MySQL users are to be forced over to MariaDB: mysql*: virtual provides mariadb*: provides mysql*, epoch 1 mysql-community*: provides mysql*, epoch 0 (*) If existing MySQL users are to remain on MySQL: real-mysql*: virtual provides mariadb*: provides real-mysql*, epoch 1 mysql*provides real-mysql*, epoch 0 Using alternatives could also be considered. In any case, the packages have to be installable in parallel. Regards, Norvald H. Ryeng (*) The name MySQL crashes with the standalone packages at dev.mysql.com, and I think I read something about a problem with case sensitive names in one of the mailing list threads. The software is called MySQL Community Server, so we suggest the mysql-community prefix. The same prefix is already used by OpenSuSE. [1] https://fedoraproject.org/wiki/Packaging:Conflicts#Common_Conflicting_Files_Cases_and_Solutions -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Von: Máirín Duffy On 03/11/2013 05:13 PM, seth vidal wrote: Is one line of text really that significant of a problem to present? I'm pretty sure it is because of where we are in the process at that point. For example, translations - can we render Indic or CJK glyphs to the screen at this point in the boot process? I'm not quite sure that's possible? Another thing with translations is they take up additional disk space and I think (don't quote me on this, maybe Peter or one of the other grub experts could speak up) grub2 is a bit chubby compared to grub, but its space usage is a concern so to not have to have all the translation files for the languages we support would definitely be good. (grub2's girth is one of the reasons - on upstream's recommendation - that we don't allow installing the bootloader to a partition now.) What about pulling the message stuff into plymouth and using dracut to trigger a reboot which shows the grub menu? Something along the lines: Press ESC to see deatils or 'b' to enter the bootloader This way we would avoid showing the grub menu, but still give the users to trigger a reboot into the grub menu . The main reason against such an approach is - obvioulsy - the need for a reboot. And on the other side I dunno if dracut is capable to modify grub2's config (to display the menu upon the next boot) - fabian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Le Mar 12 mars 2013 09:55, drago01 a écrit : On Mon, Mar 11, 2013 at 10:22 PM, seth vidal skvi...@fedoraproject.org wrote: On Mon, 11 Mar 2013 16:18:33 -0500 Michael Cronenworth m...@cchtml.com wrote: On 03/11/2013 04:13 PM, seth vidal wrote: I want to encourage kids, teenagers, etc to explore the OS. We need them to be involved in CREATING and LEARNING. So I don't want to scare any of them off. My OLPC does not present any boot menu or prompt. That's not an argument for why we should not present one. It is an argument for why they should be. Sorry but that's nonsense. Pretty much all other operating systems do not display the boot loader by default and you see this as a reason for showing it? Pretty much all other operating systems come preloaded on hardware certified to run under this specific OS version, and pretty much all other operating systems do not experiment with the boot software stack every year. Before hiding safety measures for æsthetics' sake you need to be stable and safe long enough for users to trust you. (hint: long enough is not measured in months) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Le Mar 12 mars 2013 13:17, Hans de Goede a écrit : Hi, On 03/12/2013 01:02 PM, Jiří Eischmann wrote: Allan Day píše v Út 12. 03. 2013 v 11:15 +: Hi all, On the question of how kernel versions should be accessed, I am very much in favour of the position that Chris Murphy expressed earlier: choosing a kernel version is opaque to most users and requires fairly advanced technical knowledge to understand. I agree, but unfortunately, it's not the case of Fedora. By having a rolling release policy for the kernel, we're forcing users to deal with kernel versions. I follow user forums quite a lot and I read it every day: I updated and my wireless card stopped working, my computer doesn't wake up from suspend, the system is now much slower. New kernels bring a lot of regressions and we don't have enough test coverage to avoid them. The general solution to those problems is to go back to the last working kernel version. But by making it less obvious we make these frequent problems more difficult to solve. Keep in mind that the not show the menu by default plan depends on the bootspec changes, and that will include a gui tool which will allow users to select things like show the menu (and then it won't have a timeout so be easier to get to), or even to directly select the kernel to boot next time. Any gui tool requires a successful boot Successful means kernel ok, systemd ok, selinux ok, x/wayland ok, gdm ok, gnome-shell ok (replace with other de equivalents) There are so many parts there where we *fail* the user regularly I don't see how can anyone reasonably propose to build any safety net over them. For example, how are you going to deal with gfx drivers that break after a kernel update? The system thinks all is fine, even though the display necessary for any gui is garbage. Or has anyone found the resources and consensus necessary to implement the draconian QA checks that would be necessary to make this safe? -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
tomcat6 unresponsive maintainer deprecation
Tomcat6 package in Fedora is old, has several problematic bugs (including 4 security) and most importantly there's a replacement: tomcat-7.x I believe it is in our (developers as well as users) best interest to get rid of it. I have sent similar email to java-devel on February 26th[1], created another tomcat6 bugreport a week ago[2] but I wasn't successful in reaching David Knox (primary maintainer). Note that we already had a bugreport to migrate packages to tomcat-7[3] and we almost succeeded, but then new packages started creeping in with dependency on tomcat6. We need to get rid of it ASAP or we'll be fighting neverending battle. Even as comaintainer/provenpackager I cannot deprecate package that I do not own. I consider this point 4 of unresponsive maintainer process[4]. However due to security issues, and package being effectively dead I wouldn't mind speeding up the process. I might try to bring this up with FESCO, but process doesn't seem to include any wiggle room there. [1] http://lists.fedoraproject.org/pipermail/java-devel/2013-February/004698.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=918010 [3] https://bugzilla.redhat.com/show_bug.cgi?id=819505 [4] http://fedoraproject.org/wiki/Package_maintainer_policy#What_to_do_if_a_maintainer_is_absent -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://www.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Le Mar 12 mars 2013 13:30, Fabian Deutsch a écrit : Von: Máirín Duffy On 03/11/2013 05:13 PM, seth vidal wrote: Is one line of text really that significant of a problem to present? I'm pretty sure it is because of where we are in the process at that point. For example, translations - can we render Indic or CJK glyphs to the screen at this point in the boot process? I'm not quite sure that's possible? Another thing with translations is they take up additional disk space and I think (don't quote me on this, maybe Peter or one of the other grub experts could speak up) grub2 is a bit chubby compared to grub, but its space usage is a concern so to not have to have all the translation files for the languages we support would definitely be good. (grub2's girth is one of the reasons - on upstream's recommendation - that we don't allow installing the bootloader to a partition now.) What about pulling the message stuff into plymouth and using dracut to trigger a reboot which shows the grub menu? Something along the lines: Press ESC to see deatils or 'b' to enter the bootloader Plymouth is not a mandatory boot process element right now, precisely because people who cared about fast boot found it unnecessary, and people who cared about maintainability also found it got in the way. Please do not advocate hardwiring it again. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Tue, 12 Mar 2013 13:52:30 +0100 Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Mar 12 mars 2013 13:30, Fabian Deutsch a écrit : What about pulling the message stuff into plymouth and using dracut to trigger a reboot which shows the grub menu? Something along the lines: Press ESC to see deatils or 'b' to enter the bootloader Plymouth is not a mandatory boot process element right now, precisely because people who cared about fast boot found it unnecessary, and people who cared about maintainability also found it got in the way. Please do not advocate hardwiring it again. +1 -- Regards, Frank http//www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building broken in rawhide for packages requiring mysql? Re: MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64
On Mon, 11 Mar 2013 19:00:29 +0100, Honza Horak hho...@redhat.com wrote: On 03/11/2013 06:55 PM, Sérgio Basto wrote: Hi , On Qua, 2013-03-06 at 09:25 -0600, Richard Shaw wrote: Looks like mariadb has hit rawhide now and I can't build mythtv. I've added conditionals for the direct mysql Requires and BR's but until some of the dependent packages are fixed, MySQL-python, qt4-mysql, etc. How (and when) we fix rawhide ? Thanks, Hi, if I understand it correctly that the problem is caused by conflicting library names, then it should be solved today (the enhanced package is already building). Why not have non-conflicting library names? The APIs are different, so it makes sense to have both libmysqlclient.so and libmariadbclient.so. These can co-exist and applications can choose which library to build against. The solution that's currently implemented (bumping the version of the original libmysqlclient.so from 18 to 1018) is a hack and not a long-term solution. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/12/2013 07:04 AM, drago01 wrote: On Tue, Mar 12, 2013 at 11:37 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 12.03.2013 09:55, schrieb drago01: On Mon, Mar 11, 2013 at 10:22 PM, seth vidal skvi...@fedoraproject.org wrote: On Mon, 11 Mar 2013 16:18:33 -0500 Michael Cronenworth m...@cchtml.com wrote: On 03/11/2013 04:13 PM, seth vidal wrote: I want to encourage kids, teenagers, etc to explore the OS. We need them to be involved in CREATING and LEARNING. So I don't want to scare any of them off. My OLPC does not present any boot menu or prompt. That's not an argument for why we should not present one. It is an argument for why they should be. Sorry but that's nonsense. Pretty much all other operating systems do not display the boot loader by default and you see this as a reason for showing it? What kind of weird logic is that? Or do you really think we can have we do show a screen that you won't care about most of the time on every boot as a selling point for fedora? who cares about OTHER operating systems? You can't develop an operating system while living under a rock you have to look at what the competition does. if i would want their behavior i would install them Strawman. are you guys booting the whole day your machines that save 2 seconds is woth any discussion? Yes 2 seconds is a LONG time when your system is using an SSD. Booting should be instant there is no reason why we should have to wait before being able to use the system. (killing grub delay gets us closer to that goal). I'd say booting is a more common task then messing with bootloader options so lets optimize for the former rather then the later. How many times do you boot your system each day? 10? Okay thats a whole 20 additional seconds. -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Tue, Mar 12, 2013 at 2:13 PM, Steve Clark scl...@netwolves.com wrote: On 03/12/2013 07:04 AM, drago01 wrote: On Tue, Mar 12, 2013 at 11:37 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 12.03.2013 09:55, schrieb drago01: On Mon, Mar 11, 2013 at 10:22 PM, seth vidal skvi...@fedoraproject.org wrote: On Mon, 11 Mar 2013 16:18:33 -0500 Michael Cronenworth m...@cchtml.com wrote: On 03/11/2013 04:13 PM, seth vidal wrote: I want to encourage kids, teenagers, etc to explore the OS. We need them to be involved in CREATING and LEARNING. So I don't want to scare any of them off. My OLPC does not present any boot menu or prompt. That's not an argument for why we should not present one. It is an argument for why they should be. Sorry but that's nonsense. Pretty much all other operating systems do not display the boot loader by default and you see this as a reason for showing it? What kind of weird logic is that? Or do you really think we can have we do show a screen that you won't care about most of the time on every boot as a selling point for fedora? who cares about OTHER operating systems? You can't develop an operating system while living under a rock you have to look at what the competition does. if i would want their behavior i would install them Strawman. are you guys booting the whole day your machines that save 2 seconds is woth any discussion? Yes 2 seconds is a LONG time when your system is using an SSD. Booting should be instant there is no reason why we should have to wait before being able to use the system. (killing grub delay gets us closer to that goal). I'd say booting is a more common task then messing with bootloader options so lets optimize for the former rather then the later. How many times do you boot your system each day? 10? Okay thats a whole 20 additional seconds. Depends on the day ... but the point is I (and 99.99%) of computer uses want to turn the device on and work with it. Not mess with random options every time for the sake of messing with random options. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Ruby 2.0 in F19/Rawhide
Hi everybody, Ruby 2.0 just landed in F19/Rawhide [1]. Since the rebuild was not as fast as one would wish, there will be probably plenty of broken dependencies. I kindly ask you for patience or better for help with fixing any remaining issues. Just rebuild is unfortunately not enough. Please come to Ruby-SIG ML to discuss any issues or ping me on freenode (vondruch). Thank you Vít [1] https://fedorahosted.org/rel-eng/ticket/5463#comment:4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 914316] perl-Net-Twitter-4.00004 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=914316 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Net-Twitter-4.3 is |perl-Net-Twitter-4.4 is |available |available --- Comment #3 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 4.4 Current version in Fedora Rawhide: 4.2 URL: http://search.cpan.org/dist/Net-Twitter/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ea2ov4aIu8a=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: Requesting assistance with packaging a web app: wikindx
On Tue, 2013-03-12 at 22:21 +1100, Ankur Sinha wrote: I'm going to start with roundcubemail and try to package wikindx4 in a similar manner I've looked at a few web apps and made quite a few changes to the spec. However, there are still a few issues that would require heavy patching. I've filed an RFE with upstream here[1]. I thank everyone for their help getting me stared. If upstream helps out, it should be fairly simple to proceed from here. [1] https://sourceforge.net/p/wikindx/v4-feature-requests/42/ -- Thanks, Warm regards, Ankur: FranciscoD Please only print if necessary. Looking to contribute to Fedora? Look here: https://fedoraproject.org/wiki/Fedora_Join_SIG http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Von: Nicolas Mailhot Gesendet: 12.03.13 13:52 Uhr Le Mar 12 mars 2013 13:30, Fabian Deutsch a écrit : Von: Máirín Duffy On 03/11/2013 05:13 PM, seth vidal wrote: Is one line of text really that significant of a problem to present? I'm pretty sure it is because of where we are in the process at that point. For example, translations - can we render Indic or CJK glyphs to the screen at this point in the boot process? I'm not quite sure that's possible? Another thing with translations is they take up additional disk space and I think (don't quote me on this, maybe Peter or one of the other grub experts could speak up) grub2 is a bit chubby compared to grub, but its space usage is a concern so to not have to have all the translation files for the languages we support would definitely be good. (grub2's girth is one of the reasons - on upstream's recommendation - that we don't allow installing the bootloader to a partition now.) What about pulling the message stuff into plymouth and using dracut to trigger a reboot which shows the grub menu? Something along the lines: Press ESC to see deatils or 'b' to enter the bootloader Plymouth is not a mandatory boot process element right now, precisely because people who cared about fast boot found it unnecessary, and people who cared about maintainability also found it got in the way. Please do not advocate hardwiring it again. It's actually less about plymouth itself, it's more about the idea of avoiding to use the grub2 menu and telling the user during (early) boot how the bootloader can be accessed. For a non-plymouth boot I'd just display one or none grub message (non-localized) for a short time - which will be as un-fancy as the boot itself. - fabian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Le Mar 12 mars 2013 14:16, drago01 a écrit : On Tue, Mar 12, 2013 at 2:13 PM, Steve Clark scl...@netwolves.com wrote: I'd say booting is a more common task then messing with bootloader options so lets optimize for the former rather then the later. How many times do you boot your system each day? 10? Okay thats a whole 20 additional seconds. Depends on the day ... but the point is I (and 99.99%) of computer uses want to turn the device on and work with it. Not mess with random options every time for the sake of messing with random options. Messing with random options is not the result of bootloader visibility, messing with random options is the product of our lack of stability. Removing the interface won't make the system suddenly stable and not in need of maintenance. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Tue, 12.03.13 09:13, Steve Clark (scl...@netwolves.com) wrote: How many times do you boot your system each day? 10? Okay thats a whole 20 additional seconds. This is way up on my list of most non-sensical arguments about building OSes, right next to Linux is about choice. This bullshit about boot times don't matter is just entirely bogus, and it doesn't get better by constant repitition. Fast boot times matter on desktops, they matter on embedded, they matter on mobile, they matter or servers, they matter everywhere. Fast boot times matter to dual-boot users, they matter to everybdoy who doesn't run his system 24/7, they matter in container setups, they matter in HA setups, they matter in the cloud, they matter for people who update their system, they matter to people with discontiniuous power supplies, they matter to provide users with a sane user experience. Fast boot times save you time and energy. They increase reliability, and applicability. Fast boot times improve the first impression our OS makes on people. And yes, I know that some BIOSes suck, and are slower than the OS to boot. But that's -- for once -- something that *does* not matter, and is no excuse for having everything else to be slow, too. The Windows 8 certification *requires* fast POST from all machines, and so, it's only getting better, and we should do our bit about it. You know: *you* might not need fast boot. *Your* systems you might not reboot only every other week. *Your* server system might have a very slow BIOS POST. But we don't do this OS for *you* alone. Fedora has a certain claim of universality. And that's why fast boot matters to Fedora. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building broken in rawhide for packages requiring mysql? Re: MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64
On 03/12/2013 02:03 PM, Norvald H. Ryeng wrote: On Mon, 11 Mar 2013 19:00:29 +0100, Honza Horak hho...@redhat.com wrote: if I understand it correctly that the problem is caused by conflicting library names, then it should be solved today (the enhanced package is already building). Why not have non-conflicting library names? The APIs are different, so it makes sense to have both libmysqlclient.so and libmariadbclient.so. These can co-exist and applications can choose which library to build against. That would mean to persuade many depended projects to enhance their building configuration. Unless these projects start using some in-compatible features regularly, I don't think it would be worth changing the library name -- such projects currently don't care if it is build against mysql or mariadb. The solution that's currently implemented (bumping the version of the original libmysqlclient.so from 18 to 1018) is a hack and not a long-term solution. True, I'm expecting MySQL will be rebased to 5.6 and mariadb to 10.0 sooner or later and I don't believe that library versions will remain the same at that point. What does MySQL upstream actually plan with library version in 5.6? Is it going to be bumped? Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[AutoQA] #437: Update repoinfo.conf - Add branch
#437: Update repoinfo.conf - Add branch -+ Reporter: ausil | Owner: Type: task| Status: new Priority: critical| Milestone: Hot issues Component: production | Keywords: Blocked By: | Blocking: -+ we have just branched for f19 -- Ticket URL: https://fedorahosted.org/autoqa/ticket/437 AutoQA http://autoqa.fedorahosted.org Automated QA project ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Self introduction
Hi all, This is a personal introduction, as I'm hoping to join the package team. The following is a short story of my first encounter with Fedora. I started using Linux as a part of my studies, almost five years ago, and at that time the terminal seemed an odd way of controlling things. Naturally that has changed over time, and I often miss the functionality when using other systems. I started using Arch Linux for roughly 4 years, though there are many positive things about the distribution, we come to that in a while, I just got tired of things breaking after an update, and the endless compilation time of openAFS after each kernel update. All I ever needed is a simple desktop with decent default settings. I don't really need to choose my own desktop manager and desktop during installation, not to mention the right wireless drivers for my PC, that's why I started looking for something else. After reading a article reviewing the top 10 distros at the time, I tried Fedora 16 as the first and only one. Previously I had always used KDE, so it was something new with both Fedora, running systemd which I had never seen before, and Gnome. Except for the Alt + Mouse for shutdown, I had nothing to complain about, so I stuck with Fedora. There are just that one thing I keep missing, and that is the Arch User Repository (AUR), as I never found an open source project which I couldn't find there and install within a short time. I know a repository like that relies on me as the user, to read and validate that the build is in order, which I'm guessing doesn't go well with the Fedora philosophy. That is why I want to join the package team, as I see it, a distribution is more usable the wider the range of packages in the package system. I currently have two packages up for review, where I need a sponsor. I'm planning to make more packages of those requested by the Fedora Design Team and the sqlite browserhttp://sqlitebrowser.sourceforge.net/, when hopefully I get a sponsor. Regards Palle Ravn aka. paller -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/12/2013 09:33 AM, Lennart Poettering wrote: On Tue, 12.03.13 09:13, Steve Clark (scl...@netwolves.com) wrote: How many times do you boot your system each day? 10? Okay thats a whole 20 additional seconds. This is way up on my list of most non-sensical arguments about building OSes, right next to Linux is about choice. This bullshit about boot times don't matter is just entirely bogus, and it doesn't get better by constant repitition. Fast boot times matter on desktops, they matter on embedded, they matter on mobile, they matter or servers, they matter everywhere. Fast boot times matter to dual-boot users, they matter to everybdoy who doesn't run his system 24/7, they matter in container setups, they matter in HA setups, they matter in the cloud, they matter for people who update their system, they matter to people with discontiniuous power supplies, they matter to provide users with a sane user experience. Fast boot times save you time and energy. They increase reliability, and applicability. Fast boot times improve the first impression our OS makes on people. And yes, I know that some BIOSes suck, and are slower than the OS to boot. But that's -- for once -- something that *does* not matter, and is no excuse for having everything else to be slow, too. The Windows 8 certification *requires* fast POST from all machines, and so, it's only getting better, and we should do our bit about it. You know: *you* might not need fast boot. *Your* systems you might not reboot only every other week. *Your* server system might have a very slow BIOS POST. But we don't do this OS for *you* alone. Fedora has a certain claim of universality. And that's why fast boot matters to Fedora. Lennart How in the hell does 2 more seconds when booting a Desktop make any difference in an 8 to 10 hour day that the computer is going to be up. Go get a cup a coffee! You keep touting window 8 - maybe you should just use it an leave Linux alone! -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-libwww-perl/f18] 6.05 bump
commit 47dd784b3eae12b57a950e2252dc430f2ce3b1a0
Author: Petr Písař ppi...@redhat.com
Date: Tue Mar 12 14:56:29 2013 +0100
6.05 bump
.gitignore |1 +
...TP-6.04-we-don-t-need-our-own-can_read-an.patch | 75
perl-libwww-perl.spec | 10 ++--
sources|2 +-
4 files changed, 7 insertions(+), 81 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a868007..d4a6ab6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ libwww-perl-5.834.tar.gz
/libwww-perl-6.02.tar.gz
/libwww-perl-6.03.tar.gz
/libwww-perl-6.04.tar.gz
+/libwww-perl-6.05.tar.gz
diff --git a/perl-libwww-perl.spec b/perl-libwww-perl.spec
index 06308fa..164d393 100644
--- a/perl-libwww-perl.spec
+++ b/perl-libwww-perl.spec
@@ -1,13 +1,11 @@
Name: perl-libwww-perl
-Version:6.04
-Release:4%{?dist}
+Version:6.05
+Release:1%{?dist}
Summary:A Perl interface to the World-Wide Web
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/libwww-perl/
Source0:
http://www.cpan.org/authors/id/G/GA/GAAS/libwww-perl-%{version}.tar.gz
-# Fix time-out, bug #919448, CPAN RT#81799, in upstream after 6.04
-Patch0:
libwww-perl-6.04-With-Net-HTTP-6.04-we-don-t-need-our-own-can_read-an.patch
BuildArch: noarch
BuildRequires: perl(Digest::MD5)
BuildRequires: perl(Encode) = 2.12
@@ -84,7 +82,6 @@ use and even classes that help you implement simple HTTP
servers.
%prep
%setup -q -n libwww-perl-%{version}
-%patch0 -p1
%build
# Install the aliases by default
@@ -110,6 +107,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Tue Mar 12 2013 Petr Pisar ppi...@redhat.com - 6.05-1
+- 6.05 bump
+
* Fri Mar 08 2013 Petr Pisar ppi...@redhat.com - 6.04-3
- Honor time-out (bug #919448)
diff --git a/sources b/sources
index 9a32659..4b96ad3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-24acf2fe33b2295f048f8859e9665ee3 libwww-perl-6.04.tar.gz
+637d5f1eb61336ca2caa6e026b382f87 libwww-perl-6.05.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
File IO-Socket-IP-0.19.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-IO-Socket-IP: 7cc2dcaecbc3cbc36c212883ea4239e0 IO-Socket-IP-0.19.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: Improving the Fedora boot experience
Am 11.03.2013 18:49, schrieb Lennart Poettering: - Turn off the graphical grub screen Even if we are not able to suppress the boot menu entirely, or having a clean boot menu like this: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/bootmenu.png, avoiding the graphical screen will be a win in terms of reduced visual noise. We should not only turn off the graphical screen, but the entire thing should get turned off unless the user presses some key NO NO NO why do developers these days tend to hdie all from the users? and later you wonder why nobody has any idea about basics? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
Am 11.03.2013 19:12, schrieb Honza Horak: On 03/09/2013 07:20 PM, Reindl Harald wrote: and why in the world is this not solved more pragmatically? my conslusion is * MariaDB will replace mysql as default * any package will be linked against mariadb * Oracle MySQL should only provide the server and not the client-tools This doesn't solve all the issues -- if package like akonadi-mysql says Requires: mysql-server, then Oracle MySQL either wouldn't satisfy that requirement or (in case it includes Provides: mysql-server) RPM choosing behavior would be ambiguous. so you can not have both in Fedora so why is MariaDB not obsoleting mysql without all this versioning tricks and mysql-oracle installs the server under /usr/local/mysql-oracle/ and provides a mysql-oracle.service? This is simply not possible in Fedora: http://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fopt.2C_or_.2Fusr.2Flocal so you can not have both in Fedora do the switch to mariadb or leave things as they where instead create problems afters problems or leave mysql untouched at all signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Am 12.03.2013 09:55, schrieb drago01: On Mon, Mar 11, 2013 at 10:22 PM, seth vidal skvi...@fedoraproject.org wrote: On Mon, 11 Mar 2013 16:18:33 -0500 Michael Cronenworth m...@cchtml.com wrote: On 03/11/2013 04:13 PM, seth vidal wrote: I want to encourage kids, teenagers, etc to explore the OS. We need them to be involved in CREATING and LEARNING. So I don't want to scare any of them off. My OLPC does not present any boot menu or prompt. That's not an argument for why we should not present one. It is an argument for why they should be. Sorry but that's nonsense. Pretty much all other operating systems do not display the boot loader by default and you see this as a reason for showing it? What kind of weird logic is that? Or do you really think we can have we do show a screen that you won't care about most of the time on every boot as a selling point for fedora? who cares about OTHER operating systems? if i would want their behavior i would install them are you guys booting the whole day your machines that save 2 seconds is woth any discussion? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Am 12.03.2013 12:04, schrieb drago01: Sorry but that's nonsense. Pretty much all other operating systems do not display the boot loader by default and you see this as a reason for showing it? What kind of weird logic is that? Or do you really think we can have we do show a screen that you won't care about most of the time on every boot as a selling point for fedora? who cares about OTHER operating systems? You can't develop an operating system while living under a rock you have to look at what the competition does surely you CAN and you SHOULD does the other operating systems let you select older kernels for whatever reason? no they don't! with the attitude of the last few years from the begin i would still not know that i can boot older kernels if after aupdate the machine refuses to start and if you are in that situation you have no google signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [AutoQA] #437: Update repoinfo.conf - Add branch
#437: Update repoinfo.conf - Add branch +- Reporter: ausil | Owner: Type: task| Status: new Priority: critical| Milestone: Hot issues Component: production | Resolution: Keywords: | Blocked By: Blocking: | +- Comment (by kparal): Thanks. Fixed in commit eaf8a7c and hot-fixed at staging and production. -- Ticket URL: https://fedorahosted.org/autoqa/ticket/437#comment:1 AutoQA http://autoqa.fedorahosted.org Automated QA project ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: [AutoQA] #437: Update repoinfo.conf - Add branch
#437: Update repoinfo.conf - Add branch +- Reporter: ausil | Owner: Type: task| Status: closed Priority: critical| Milestone: 0.9.0 Component: production | Resolution: fixed Keywords: | Blocked By: Blocking: | +- Changes (by kparal): * status: new = closed * milestone: Hot issues = 0.9.0 * resolution: = fixed -- Ticket URL: https://fedorahosted.org/autoqa/ticket/437#comment:2 AutoQA http://autoqa.fedorahosted.org Automated QA project ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Unhelpful update descriptions
On Tue, Mar 12, 2013 at 2:39 AM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On 03/12/2013 01:30 AM, Dan Mashal wrote: Semantics. Providing a link is helpful to users isn't semantics. You as a package maintainer would be aware of where to look for reviewing the changes before pushing an update. Users don't since it is different for different projects and is not necessarily obvious or even easily searchable. Just take that few seconds of additional effort and provide the link. Yep, I think the link, when available, is very useful. What I try is to pick up a few most important changes directly affecting Fedora and then I link full Changelog. So maybe idea - what about a dedicated field in Bodhi for upstream's Changelog and then present it for users in PackageKit in a some nicer way - real, clickable link... Not sure it will be possible in our Packaging GUIs and also we try to hide updates as much as possible from our users... Jaroslav Rahul -- 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 Have bodhi grab it from the RPM change log spec file. Don't make packager do more work than they already have to. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-libwww-perl ownership changed
Package perl-libwww-perl in Fedora 18 is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-libwww-perl -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-libwww-perl ownership changed
Package perl-libwww-perl in Fedora 17 is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-libwww-perl -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: MySQL-libs conflicts with mariadb-libs-5.5.29-7.fc19.x86_64
Rex Dieter wrote: Honza Horak wrote: So to solve the live image composes issue for now I adjusted the major soname number to libmysqlclient.so.1018. I know it doesn't solve all the issues, though. Thanks, that should mitigate immediate issues mentioned in this thread. Still a problem with last night's image compose. I suspect similar problems are occuring from amarok's use of mysql-embedded. Please change the soname in -embedded subpkg too -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 19 Feature Freeze is tomorrow!
Hi Jaroslav, I had updated our page to say that we were 95% complete, and I thought we were. But our first tests found a major cgroups bug, that has been fixed in our latest release, that just was finished yesterday. In short, yes, we are complete, but there is going to be a major update of packages today. That doesn't mean we are adding features, just fixing a major bug. Troy On 03/11/2013 12:02 PM, Jaroslav Reznik wrote: REMINDER: Tuesday, March 12 is the Feature Freeze for Fedora 19, the Planning Development phase ends - that means tomorrow! At this point, all accepted features should be substantially complete, and testable. Additionally, if a feature is to be enabled by default, it must be so enabled at Feature Freeze. See [1] and [2]. For more detail, check my previous announcement: http://lists.fedoraproject.org/pipermail/devel-announce/2013-March/001125.html There are still quite a lot of Features not updated recently, you will make my life much more easier by filling the current status (I don't have to ask everyone individually then;-). And of course, thanks to everyone who already updates theirs Features! Thanks Jaroslav [1] https://fedoraproject.org/wiki/Feature_Freeze_Policy [2] https://fedoraproject.org/wiki/Features/Policy/Milestones#Feature_Freeze ___ 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: [darktable] Upgrade to 1.1.4
Please be careful, rewriting history (and changelog entries).
-- rex
madko wrote:
commit 7cbe3221ef9411bb258c6d65b7f00f0de557c380
Author: Edouard Bourguignon ma...@linuxed.net
Date: Sat Mar 9 13:57:43 2013 +0100
Upgrade to 1.1.4
...
@@ -114,11 +115,11 @@ gtk-update-icon-cache %{_datadir}/icons/hicolor
/dev/null || :
%changelog
-* Sun Mar 10 2013 Rex Dieter rdie...@fedoraproject.org 1.1.4-1
-- Upgrade to 1.1.4 (#913847, #919811)
+* Sun Mar 10 2013 Edouard Bourguignon ma...@linuxed.net - 1.1.4-1
+- Upgrade to 1.1.4
-* Sun Mar 10 2013 Rex Dieter rdie...@fedoraproject.org - 1.1.3-2
-- rebuild (OpenEXR)
+* Fri Feb 22 2013 Edouard Bourguignon ma...@linuxed.net - 1.1.3-2
+- Add some missing dependancies
* Mon Feb 11 2013 Edouard Bourguignon ma...@linuxed.net - 1.1.3-1
- Upgrade to 1.1.3
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Tue, Mar 12, 2013 at 7:15 AM, Dan Mashal dan.mas...@gmail.com wrote: On Tue, Mar 12, 2013 at 2:39 AM, Jaroslav Reznik jrez...@redhat.com wrote: - Original Message - On 03/12/2013 01:30 AM, Dan Mashal wrote: Semantics. Providing a link is helpful to users isn't semantics. You as a package maintainer would be aware of where to look for reviewing the changes before pushing an update. Users don't since it is different for different projects and is not necessarily obvious or even easily searchable. Just take that few seconds of additional effort and provide the link. Yep, I think the link, when available, is very useful. What I try is to pick up a few most important changes directly affecting Fedora and then I link full Changelog. So maybe idea - what about a dedicated field in Bodhi for upstream's Changelog and then present it for users in PackageKit in a some nicer way - real, clickable link... Not sure it will be possible in our Packaging GUIs and also we try to hide updates as much as possible from our users... Jaroslav Rahul -- 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 Have bodhi grab it from the RPM change log spec file. Don't make packager do more work than they already have to. Dan In fact Koji does this and is a place where I go to get more info and does this already. You can even get compilation logs! ;) Bodhi never seemed like a tool to be informative. Just push out updates. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience - no plymouth!
Am 12.03.2013 13:52, schrieb Nicolas Mailhot: Le Mar 12 mars 2013 13:30, Fabian Deutsch a écrit : Von: Máirín Duffy On 03/11/2013 05:13 PM, seth vidal wrote: Is one line of text really that significant of a problem to present? I'm pretty sure it is because of where we are in the process at that point. For example, translations - can we render Indic or CJK glyphs to the screen at this point in the boot process? I'm not quite sure that's possible? Another thing with translations is they take up additional disk space and I think (don't quote me on this, maybe Peter or one of the other grub experts could speak up) grub2 is a bit chubby compared to grub, but its space usage is a concern so to not have to have all the translation files for the languages we support would definitely be good. (grub2's girth is one of the reasons - on upstream's recommendation - that we don't allow installing the bootloader to a partition now.) What about pulling the message stuff into plymouth and using dracut to trigger a reboot which shows the grub menu? Something along the lines: Press ESC to see deatils or 'b' to enter the bootloader Plymouth is not a mandatory boot process element right now, precisely because people who cared about fast boot found it unnecessary, and people who cared about maintainability also found it got in the way. Please do not advocate hardwiring it again plymouth is a no-go as requirement rd.plymouth=0 plymouth.enable=0 are my first kernel params on a lot of machines [root@srv-rhsoft:~]$ cat /etc/dracut.conf.d/90-plymouth.conf omit_dracutmodules+=plymouth is present on ANY machine i maintain the only thing i want on a machine is: * no graphical stuff at boot time, not any of it * no submenus in the boot-menu * the kernel list dispalyed for 1 second * no rhgb * no quiet why? because i want to see what me system does if i look how it boots up within 15 seconds and i want to face ANY possible warning nobody cares especially after a upgrade signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Tue, Mar 12, 2013 at 08:01:54AM -0400, Nico Kadel-Garcia wrote: And the main lesson her is don't clutter the user interface with useless graphical eye candy. It makes the boot process require unnecessary system resources. The new Fedora installation setup is currently a *nightmare*. It works very poorly through low bandwidth remote connections, the graphics are poorly labeled and very confusing, and the spoke and hub model is a bit of big vision coneptual weirdness that is actively preventing people from wanting to touch Fedora. It's an *installer*, keeping it as lightweight and simple as possible with minimal graphics means that it will display better on small virtual system or remote KVM displays. But this has been discarded in favor or an overly bulky and complex system that is showing off what are quite fragile graphical features rather than simply doing the *job*. Citation needed. Anaconda has been graphical for ages, and has probably gotten lighter after the rewrite if anything. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-IO-Socket-IP/f19] 0.19 bump
Summary of changes: e52d45e... 0.19 bump (*) (*) 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: Improving the Fedora boot experience
On Tue, Mar 12, 2013 at 09:56:57AM -0400, Steve Clark wrote: On 03/12/2013 09:33 AM, Lennart Poettering wrote: On Tue, 12.03.13 09:13, Steve Clark (scl...@netwolves.com) wrote: You know: *you* might not need fast boot. *Your* systems you might not reboot only every other week. *Your* server system might have a very slow BIOS POST. But we don't do this OS for *you* alone. Fedora has a certain claim of universality. And that's why fast boot matters to Fedora. [..] How in the hell does 2 more seconds when booting a Desktop make any difference in an 8 to 10 hour day that the computer is going to be up. Go get a cup a coffee! As you're making a suggestion towards Lennart, can I also make the suggestion that you read his email? This as he already addressed your it does not matter for me. You keep touting window 8 - maybe you should just use it an leave Linux alone! Why not reconfigure Grub on your own to have a 30 second delay? -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience - no plymouth!
On Tue, Mar 12, 2013 at 6:06 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 12.03.2013 13:52, schrieb Nicolas Mailhot: Le Mar 12 mars 2013 13:30, Fabian Deutsch a écrit : Von: Máirín Duffy On 03/11/2013 05:13 PM, seth vidal wrote: Is one line of text really that significant of a problem to present? I'm pretty sure it is because of where we are in the process at that point. For example, translations - can we render Indic or CJK glyphs to the screen at this point in the boot process? I'm not quite sure that's possible? Another thing with translations is they take up additional disk space and I think (don't quote me on this, maybe Peter or one of the other grub experts could speak up) grub2 is a bit chubby compared to grub, but its space usage is a concern so to not have to have all the translation files for the languages we support would definitely be good. (grub2's girth is one of the reasons - on upstream's recommendation - that we don't allow installing the bootloader to a partition now.) What about pulling the message stuff into plymouth and using dracut to trigger a reboot which shows the grub menu? Something along the lines: Press ESC to see deatils or 'b' to enter the bootloader Plymouth is not a mandatory boot process element right now, precisely because people who cared about fast boot found it unnecessary, and people who cared about maintainability also found it got in the way. Please do not advocate hardwiring it again plymouth is a no-go as requirement rd.plymouth=0 plymouth.enable=0 are my first kernel params on a lot of machines [root@srv-rhsoft:~]$ cat /etc/dracut.conf.d/90-plymouth.conf omit_dracutmodules+=plymouth is present on ANY machine i maintain the only thing i want on a machine is: * no graphical stuff at boot time, not any of it * no submenus in the boot-menu * the kernel list dispalyed for 1 second * no rhgb * no quiet why? because i want to see what me system does if i look how it boots up within 15 seconds and i want to face ANY possible warning nobody cares especially after a upgrade -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora boot process MUST look pretty! Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 920632] perl-IO-Socket-IP-0.19 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=920632 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-IO-Socket-IP-0.19-1.fc ||19 Resolution|--- |RAWHIDE Last Closed||2013-03-12 10:31:39 -- 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=wWdji91sVda=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 920683] CVE-2013-1841 perl-Net-Server: Improper reverse DNS matching for the given hostname
Product: Security Response https://bugzilla.redhat.com/show_bug.cgi?id=920683 Jan Lieskovsky jlies...@redhat.com changed: What|Removed |Added CC||ke...@scrye.com, ||perl-devel@lists.fedoraproj ||ect.org -- 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=bdmni445IZa=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 920683] CVE-2013-1841 perl-Net-Server: Improper reverse DNS matching for the given hostname
Product: Security Response https://bugzilla.redhat.com/show_bug.cgi?id=920683 --- Comment #1 from Jan Lieskovsky jlies...@redhat.com --- I am not sure there is an upstream patch for this issue yet. But once there is, please schedule updates for Fedora / Fedora-EPEL versions. -- 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=sqv24eLutPa=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 920685] CVE-2013-1841 perl-Net-Server: Improper reverse DNS matching for the given hostname [epel-all]
Product: Fedora EPEL https://bugzilla.redhat.com/show_bug.cgi?id=920685 --- Comment #1 from Jan Lieskovsky jlies...@redhat.com --- Please use the following update submission link to create the Bodhi request for this issue as it contains the top-level parent bug(s) as well as this tracking bug. This will ensure that all associated bugs get updated when new packages are pushed to stable. Please also ensure that the Close bugs when update is stable option remains checked. Bodhi update submission link: https://admin.fedoraproject.org/updates/new/?type_=securitybugs=920683,920685 -- 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=B7hYCEfaUTa=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 920684] New: CVE-2013-1841 perl-Net-Server: Improper reverse DNS matching for the given hostname [fedora-all]
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=920684 Bug ID: 920684 Summary: CVE-2013-1841 perl-Net-Server: Improper reverse DNS matching for the given hostname [fedora-all] Product: Fedora Version: 18 Component: perl-Net-Server Keywords: Security, SecurityTracking Severity: low Priority: low Reporter: jlies...@redhat.com Blocks: 920683 (CVE-2013-1841) This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of Fedora. For comments that are specific to the vulnerability please use bugs filed against the Security Response product referenced in the Blocks field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When creating a Bodhi update request, please use the bodhi submission link noted in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the Bodhi notes field when available. Please note: this issue affects multiple supported versions of Fedora. Only one tracking bug has been filed; please ensure that it is only closed when all affected versions are fixed. [bug automatically created by: add-tracking-bugs] -- 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=UR1dgRQIgwa=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 920683] CVE-2013-1841 perl-Net-Server: Improper reverse DNS matching for the given hostname
Product: Security Response https://bugzilla.redhat.com/show_bug.cgi?id=920683 Jan Lieskovsky jlies...@redhat.com changed: What|Removed |Added Depends On||920684 Depends On||920685 --- Comment #2 from Jan Lieskovsky jlies...@redhat.com --- Created perl-Net-Server tracking bugs for this issue Affects: fedora-all [bug 920684] Affects: epel-all [bug 920685] -- 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=oYEuFWnP9Xa=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 920685] New: CVE-2013-1841 perl-Net-Server: Improper reverse DNS matching for the given hostname [epel-all]
Product: Fedora EPEL https://bugzilla.redhat.com/show_bug.cgi?id=920685 Bug ID: 920685 Summary: CVE-2013-1841 perl-Net-Server: Improper reverse DNS matching for the given hostname [epel-all] Product: Fedora EPEL Version: el6 Component: perl-Net-Server Keywords: Security, SecurityTracking Severity: low Priority: low Reporter: jlies...@redhat.com Blocks: 920683 (CVE-2013-1841) This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of Fedora EPEL. For comments that are specific to the vulnerability please use bugs filed against the Security Response product referenced in the Blocks field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When creating a Bodhi update request, please use the bodhi submission link noted in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the Bodhi notes field when available. Please note: this issue affects multiple supported versions of Fedora EPEL. Only one tracking bug has been filed; please ensure that it is only closed when all affected versions are fixed. [bug automatically created by: add-tracking-bugs] -- 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=HTpHkG2Fdua=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 920684] CVE-2013-1841 perl-Net-Server: Improper reverse DNS matching for the given hostname [fedora-all]
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=920684 --- Comment #1 from Jan Lieskovsky jlies...@redhat.com --- Please use the following update submission link to create the Bodhi request for this issue as it contains the top-level parent bug(s) as well as this tracking bug. This will ensure that all associated bugs get updated when new packages are pushed to stable. Please also ensure that the Close bugs when update is stable option remains checked. Bodhi update submission link: https://admin.fedoraproject.org/updates/new/?type_=securitybugs=920683,920684 -- 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=ksSYa49Fuma=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: Improving the Fedora boot experience
Repeating that fast boot times matter is just as bogus as saying they don't. The 2 or 3 seconds that's being talked about here has no meaningful impact on anything other than embedded users and they're probably not using grub anyway. Fedora 18 screwed my laptop pretty thoroughly since the ATI drivers would hang the machine on resume. Having the menu there so I could chose an alternate kernel was a godsend, especially since the newer kernel wasn't always better than the previous. 2 seconds isn't hurting anyone and its more than likely going to make it easier on someone to have that menu there. Many non-server systems hibernate or suspend anyway, so they're only going to see the menu on a hard reboot. Additionally, having the ability to hit escape and see what is going on when the progress bar has hung has also saved me on occasion. On 03/12/2013 09:33 AM, Lennart Poettering wrote: On Tue, 12.03.13 09:13, Steve Clark (scl...@netwolves.com) wrote: How many times do you boot your system each day? 10? Okay thats a whole 20 additional seconds. This is way up on my list of most non-sensical arguments about building OSes, right next to Linux is about choice. This bullshit about boot times don't matter is just entirely bogus, and it doesn't get better by constant repitition. Fast boot times matter on desktops, they matter on embedded, they matter on mobile, they matter or servers, they matter everywhere. Fast boot times matter to dual-boot users, they matter to everybdoy who doesn't run his system 24/7, they matter in container setups, they matter in HA setups, they matter in the cloud, they matter for people who update their system, they matter to people with discontiniuous power supplies, they matter to provide users with a sane user experience. Fast boot times save you time and energy. They increase reliability, and applicability. Fast boot times improve the first impression our OS makes on people. And yes, I know that some BIOSes suck, and are slower than the OS to boot. But that's -- for once -- something that *does* not matter, and is no excuse for having everything else to be slow, too. The Windows 8 certification *requires* fast POST from all machines, and so, it's only getting better, and we should do our bit about it. You know: *you* might not need fast boot. *Your* systems you might not reboot only every other week. *Your* server system might have a very slow BIOS POST. But we don't do this OS for *you* alone. Fedora has a certain claim of universality. And that's why fast boot matters to Fedora. Lennart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience - no plymouth!
On 2013-03-13 00:06, Reindl Harald wrote: Am 12.03.2013 13:52, schrieb Nicolas Mailhot: Le Mar 12 mars 2013 13:30, Fabian Deutsch a écrit : Von: Máirín Duffy On 03/11/2013 05:13 PM, seth vidal wrote: Is one line of text really that significant of a problem to present? I'm pretty sure it is because of where we are in the process at that point. For example, translations - can we render Indic or CJK glyphs to the screen at this point in the boot process? I'm not quite sure that's possible? Another thing with translations is they take up additional disk space and I think (don't quote me on this, maybe Peter or one of the other grub experts could speak up) grub2 is a bit chubby compared to grub, but its space usage is a concern so to not have to have all the translation files for the languages we support would definitely be good. (grub2's girth is one of the reasons - on upstream's recommendation - that we don't allow installing the bootloader to a partition now.) What about pulling the message stuff into plymouth and using dracut to trigger a reboot which shows the grub menu? Something along the lines: Press ESC to see deatils or 'b' to enter the bootloader Plymouth is not a mandatory boot process element right now, precisely because people who cared about fast boot found it unnecessary, and people who cared about maintainability also found it got in the way. Please do not advocate hardwiring it again plymouth is a no-go as requirement rd.plymouth=0 plymouth.enable=0 are my first kernel params on a lot of machines [root@srv-rhsoft:~]$ cat /etc/dracut.conf.d/90-plymouth.conf omit_dracutmodules+=plymouth is present on ANY machine i maintain the only thing i want on a machine is: * no graphical stuff at boot time, not any of it * no submenus in the boot-menu * the kernel list dispalyed for 1 second * no rhgb * no quiet why? because i want to see what me system does if i look how it boots up within 15 seconds and i want to face ANY possible warning nobody cares especially after a upgrade +1 -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: p...@pricom.com.au -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 920683] CVE-2013-1841 perl-Net-Server: Improper reverse DNS matching check for the given hostname
Product: Security Response https://bugzilla.redhat.com/show_bug.cgi?id=920683 Jan Lieskovsky jlies...@redhat.com changed: What|Removed |Added Summary|CVE-2013-1841 |CVE-2013-1841 |perl-Net-Server: Improper |perl-Net-Server: Improper |reverse DNS matching for|reverse DNS matching check |the given hostname |for the given hostname -- 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=32LayZ9vRva=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: Self introduction
Hi, On 03/12/2013 02:37 PM, Palle Ravn wrote: Hi all, This is a personal introduction, as I'm hoping to join the package team. The following is a short story of my first encounter with Fedora. Welcome! I started using Linux as a part of my studies, almost five years ago, and at that time the terminal seemed an odd way of controlling things. Naturally that has changed over time, and I often miss the functionality when using other systems. I started using Arch Linux for roughly 4 years, though there are many positive things about the distribution, we come to that in a while, I just got tired of things breaking after an update, and the endless compilation time of openAFS after each kernel update. All I ever needed is a simple desktop with decent default settings. I don't really need to choose my own desktop manager and desktop during installation, not to mention the right wireless drivers for my PC, that's why I started looking for something else. After reading a article reviewing the top 10 distros at the time, I tried Fedora 16 as the first and only one. Previously I had always used KDE, so it was something new with both Fedora, running systemd which I had never seen before, and Gnome. Except for the Alt + Mouse for shutdown, I had nothing to complain about, so I stuck with Fedora. There are just that one thing I keep missing, and that is the Arch User Repository (AUR), as I never found an open source project which I couldn't find there and install within a short time. I know a repository like that relies on me as the user, to read and validate that the build is in order, which I'm guessing doesn't go well with the Fedora philosophy. That is why I want to join the package team, as I see it, a distribution is more usable the wider the range of packages in the package system. I currently have two packages up for review, where I need a sponsor. I'm planning to make more packages of those requested by the Fedora Design Team and the sqlite browser http://sqlitebrowser.sourceforge.net/, when hopefully I get a sponsor. It would be helpful if you could provide bugzilla links to the 2 packages you've up for review. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Hi, first of all, I respect your work very much and am actually very grateful for avahi, pulseaudio and systemd as I was for ifplugd back in the old days when Gentoo was cool. Fast boot times matter to dual-boot users, they matter to everybdoy who doesn't run his system 24/7, That is indeed very true and the experience of rebooting to Windows to play a few games with friends sucks because of long shutdown and bootup times. On the other hand, from my experience the situation frequently requires making tee, rearanging furniture and preparing waterpipe charcoal which means lot of confusion and running around. I have witness, several times, people booting back to their default system and having to go through the reboot once again just because they have missed the OS selection dialog. You might have noticed that Microsoft goes with 20 second timeout on Windows/Windows dual-boot systems. I am sure there is a reason for that. Fast boot times matter on desktops, they matter on embedded, they matter on mobile, they matter or servers, they matter everywhere. As have already been mentioned before, POSTing server takes so long that GRUB delay is hardly noticeable. But what is worse, if you miss the kernel selection dialog on a server, you look at UP TO FIVE MORE MINUTES of waiting for the damn thing before you get another attempt. I have worked with IBM, Dell and HP remote management consoles and one thing can be guaranteed -- if you give user less than 2s time window after display mode switch, she *will* frequently miss the keystroke. So, what would be the solution that will actually help on laptops while keeping benefits of the current system where people need them? I am thinking of a Reboot To dialog in GNOME, which will help with dual-booting. Next, add anaconda option to toggle GRUB prompt and autodetect it's default state, which will speed up boot on laptops while keeping sysadmins sane. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience - no plymouth!
On Tue, Mar 12, 2013 at 7:45 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 12.03.2013 15:37, schrieb Dan Mashal: On Tue, Mar 12, 2013 at 6:06 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 12.03.2013 13:52, schrieb Nicolas Mailhot: Le Mar 12 mars 2013 13:30, Fabian Deutsch a écrit : Von: Máirín Duffy On 03/11/2013 05:13 PM, seth vidal wrote: Is one line of text really that significant of a problem to present? I'm pretty sure it is because of where we are in the process at that point. For example, translations - can we render Indic or CJK glyphs to the screen at this point in the boot process? I'm not quite sure that's possible? Another thing with translations is they take up additional disk space and I think (don't quote me on this, maybe Peter or one of the other grub experts could speak up) grub2 is a bit chubby compared to grub, but its space usage is a concern so to not have to have all the translation files for the languages we support would definitely be good. (grub2's girth is one of the reasons - on upstream's recommendation - that we don't allow installing the bootloader to a partition now.) What about pulling the message stuff into plymouth and using dracut to trigger a reboot which shows the grub menu? Something along the lines: Press ESC to see deatils or 'b' to enter the bootloader Plymouth is not a mandatory boot process element right now, precisely because people who cared about fast boot found it unnecessary, and people who cared about maintainability also found it got in the way. Please do not advocate hardwiring it again plymouth is a no-go as requirement rd.plymouth=0 plymouth.enable=0 are my first kernel params on a lot of machines [root@srv-rhsoft:~]$ cat /etc/dracut.conf.d/90-plymouth.conf omit_dracutmodules+=plymouth is present on ANY machine i maintain the only thing i want on a machine is: * no graphical stuff at boot time, not any of it * no submenus in the boot-menu * the kernel list dispalyed for 1 second * no rhgb * no quiet why? because i want to see what me system does if i look how it boots up within 15 seconds and i want to face ANY possible warning nobody cares especially after a upgrade Fedora boot process MUST look pretty! says who? AND WHAT IS UGLY IN A KERNEL-MENU? the only thing to which this new shiny attitude hide anything from the users will lead is that the next generation of users stay dumb beginners who will answer the questions here in 10 years? I was joking. :) You can always yum remove plymouth. In fact we were even *gasp* looking at replacing plymouth with our own theme for laughs. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience - no plymouth!
Am 12.03.2013 15:37, schrieb Dan Mashal: On Tue, Mar 12, 2013 at 6:06 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 12.03.2013 13:52, schrieb Nicolas Mailhot: Le Mar 12 mars 2013 13:30, Fabian Deutsch a écrit : Von: Máirín Duffy On 03/11/2013 05:13 PM, seth vidal wrote: Is one line of text really that significant of a problem to present? I'm pretty sure it is because of where we are in the process at that point. For example, translations - can we render Indic or CJK glyphs to the screen at this point in the boot process? I'm not quite sure that's possible? Another thing with translations is they take up additional disk space and I think (don't quote me on this, maybe Peter or one of the other grub experts could speak up) grub2 is a bit chubby compared to grub, but its space usage is a concern so to not have to have all the translation files for the languages we support would definitely be good. (grub2's girth is one of the reasons - on upstream's recommendation - that we don't allow installing the bootloader to a partition now.) What about pulling the message stuff into plymouth and using dracut to trigger a reboot which shows the grub menu? Something along the lines: Press ESC to see deatils or 'b' to enter the bootloader Plymouth is not a mandatory boot process element right now, precisely because people who cared about fast boot found it unnecessary, and people who cared about maintainability also found it got in the way. Please do not advocate hardwiring it again plymouth is a no-go as requirement rd.plymouth=0 plymouth.enable=0 are my first kernel params on a lot of machines [root@srv-rhsoft:~]$ cat /etc/dracut.conf.d/90-plymouth.conf omit_dracutmodules+=plymouth is present on ANY machine i maintain the only thing i want on a machine is: * no graphical stuff at boot time, not any of it * no submenus in the boot-menu * the kernel list dispalyed for 1 second * no rhgb * no quiet why? because i want to see what me system does if i look how it boots up within 15 seconds and i want to face ANY possible warning nobody cares especially after a upgrade Fedora boot process MUST look pretty! says who? AND WHAT IS UGLY IN A KERNEL-MENU? the only thing to which this new shiny attitude hide anything from the users will lead is that the next generation of users stay dumb beginners who will answer the questions here in 10 years? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tomcat6 unresponsive maintainer deprecation
On Tue, 12 Mar 2013 13:49:22 +0100 Stanislav Ochotnicky sochotni...@redhat.com wrote: Tomcat6 package in Fedora is old, has several problematic bugs (including 4 security) and most importantly there's a replacement: tomcat-7.x I believe it is in our (developers as well as users) best interest to get rid of it. I have sent similar email to java-devel on February 26th[1], created another tomcat6 bugreport a week ago[2] but I wasn't successful in reaching David Knox (primary maintainer). Note that we already had a bugreport to migrate packages to tomcat-7[3] and we almost succeeded, but then new packages started creeping in with dependency on tomcat6. We need to get rid of it ASAP or we'll be fighting neverending battle. Even as comaintainer/provenpackager I cannot deprecate package that I do not own. I consider this point 4 of unresponsive maintainer process[4]. However due to security issues, and package being effectively dead I wouldn't mind speeding up the process. I might try to bring this up with FESCO, but process doesn't seem to include any wiggle room there. Feel free to file a fesco ticket and explain whats going on. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Tue, 12 Mar 2013 07:29:03 -0700 Dan Mashal dan.mas...@gmail.com wrote: On Tue, Mar 12, 2013 at 7:15 AM, Dan Mashal dan.mas...@gmail.com wrote: On Tue, Mar 12, 2013 at 2:39 AM, Jaroslav Reznik jrez...@redhat.com wrote: ...snip... Yep, I think the link, when available, is very useful. What I try is to pick up a few most important changes directly affecting Fedora and then I link full Changelog. So maybe idea - what about a dedicated field in Bodhi for upstream's Changelog and then present it for users in PackageKit in a some nicer way - real, clickable link... Not sure it will be possible in our Packaging GUIs and also we try to hide updates as much as possible from our users... ...snip... I'm not sure either, but it could be nice to see. I'd guess it would have to be a per update optional field, since some upstreams do a different url per release. I don't know how or if PackageKit could display it. Perhaps file some RFEs? Have bodhi grab it from the RPM change log spec file. Don't make packager do more work than they already have to. Grab what? It doesn't know what part of things is the upstream changelog link (if any). In fact Koji does this and is a place where I go to get more info and does this already. You can even get compilation logs! ;) I suspect many consumers of our updates don't care about compile logs. They would rather see what many projects put in their NEWS file. (ie, changes they might notice or care about). Bodhi never seemed like a tool to be informative. Just push out updates. I'm not sure I agree. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/12/2013 08:30 AM, Fabian Deutsch wrote: What about pulling the message stuff into plymouth and using dracut to trigger a reboot which shows the grub menu? Something along the lines: Press ESC to see deatils or 'b' to enter the bootloader This is an interesting idea, but I don't think plymouth makes it any easier to display CJK Indic glyphs. (Please someone more technical tell me if I'm wrong here, I vaguely remember this being an issue when we wanted to add a messagse to fedup) ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Tue, Mar 12, 2013 at 7:58 AM, Kevin Fenzi ke...@scrye.com wrote: On Tue, 12 Mar 2013 07:29:03 -0700 Dan Mashal dan.mas...@gmail.com wrote: On Tue, Mar 12, 2013 at 7:15 AM, Dan Mashal dan.mas...@gmail.com wrote: On Tue, Mar 12, 2013 at 2:39 AM, Jaroslav Reznik jrez...@redhat.com wrote: ...snip... Yep, I think the link, when available, is very useful. What I try is to pick up a few most important changes directly affecting Fedora and then I link full Changelog. So maybe idea - what about a dedicated field in Bodhi for upstream's Changelog and then present it for users in PackageKit in a some nicer way - real, clickable link... Not sure it will be possible in our Packaging GUIs and also we try to hide updates as much as possible from our users... ...snip... I'm not sure either, but it could be nice to see. I'd guess it would have to be a per update optional field, since some upstreams do a different url per release. I don't know how or if PackageKit could display it. Perhaps file some RFEs? Have bodhi grab it from the RPM change log spec file. Don't make packager do more work than they already have to. Grab what? It doesn't know what part of things is the upstream changelog link (if any). In fact Koji does this and is a place where I go to get more info and does this already. You can even get compilation logs! ;) I suspect many consumers of our updates don't care about compile logs. They would rather see what many projects put in their NEWS file. (ie, changes they might notice or care about). Bodhi never seemed like a tool to be informative. Just push out updates. I'm not sure I agree. ;) kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Agree to disagree. I care about compilation logs! :P I will try and include NEWS (if any) from now on. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
On Tue, 12 Mar 2013 08:04:47 -0700 Dan Mashal dan.mas...@gmail.com wrote: Agree to disagree. I care about compilation logs! :P Sure, and they are there for you. I doubt many people will say: Hey, foobar-1.0 is updating to foobar-1.0.1, I should read the compile logs to see whats changed. I will try and include NEWS (if any) from now on. Well, if your project has a link to it thats better than including the content. Depending on the project the NEWS entry for a release can be long. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Hi, Keep in mind that the not show the menu by default plan depends on the bootspec changes, and that will include a gui tool which will allow users to select things like show the menu (and then it won't have a timeout so be easier to get to), or even to directly select the kernel to boot next time. Any gui tool requires a successful boot Successful means kernel ok, systemd ok, selinux ok, x/wayland ok, gdm ok, gnome-shell ok (replace with other de equivalents) There are so many parts there where we *fail* the user regularly I don't see how can anyone reasonably propose to build any safety net over them. For example, how are you going to deal with gfx drivers that break after a kernel update? The system thinks all is fine, even though the display necessary for any gui is garbage. Well. lilo (anyone remembers?) had a cool feature to address that, and for grub1 patches where floating around to implement something simliar. You could do lilo -R $kernel $args. Then lilo boots the specified kernel (with args if specified) *once*. So you can boot a new kernel *without* changing the default kernel. Or boot the kernel with additional args without changing the default args. Pretty neat for kernel hacking. When your kernel fails to boot -- just hit reset (or power-cycle the machine remotely) and the system comes up with the known-good default kernel. Likewise useful for kernel updates. Install new kernel, *not* make it the default (yet), ask lilo to boot it once, reboot, and when the system came up fine you can make the new kernel the default. cheers, Gerd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, Mar 11, 2013 at 12:58:05PM -0400, Matthias Clasen wrote: Hi, I would love to see F19 make a good first impression. The first time you see something Fedora-related on the screen currently is the graphical grub screen, followed by the filling-in-Fedora of Plymouth, followed by the gdm login screen. Grub in particular is problematic, with a starfield background that looks like a Fedora background from a few releases ago and a progress bar that indicates the progress in 'booting the bootloader'. There are also some issues on the login screen, with Fedora logo being at small-print size right now. I think a few simple changes we can make a big improvement to the visual experience for F19: - Turn off the graphical grub screen Even if we are not able to suppress the boot menu entirely, or having a clean boot menu like this: https://raw.github.com/gnome-design-team/gnome-mockups/master/system-lock-login-boot/bootmenu.png, avoiding the graphical screen will be a win in terms of reduced visual noise. Honestly, I'd like to do this anyway - the grub2 gfxterm code seems to cause nothing but bugs in later graphics setup. That said, I'd rather go back to not having it at all, but with a different plan than last time. The idea would be to have a positive indication from systemd that we've gotten to some pre-defined point on the previous boot (say, starting your login manager), and not to show you any menu unless the previous boot didn't get that far. So when you install a new kernel, the process would look like: 1) install kernel 2) set it to boot once with grub2-set-default 3) upon reboot, set it as default if and only if we get to the success point 4) if we see a second boot happen without the success flag set, don't set it default, and wait the normal 5 seconds for input This has a number of advantages when booting on some systems. On UEFI systems, which is most new desktops: 1) we don't need any grub UI whatsoever 2) we don't need the 5 second timeout 3) we don't need to indicate to the firmware that we need USB probed unless it's the device we're booting from. Together, these currently represent the majority of time from poweron to login. On new desktop hardware, this would be a dramatically faster boot experience. Note that getting to the system firmware menus or switching kernels would have to be selected before reboot, except in the case where the previous boot failed - in that case, we'd display the menus, probe the keyboard, and wait the 5 seconds. On BIOS machines I think we can still accomplish #1 and #2 as well, but there's no guarantee of a way to disable firmware timeouts or press f2 for setup screens and loading the usb stack. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Von: Máirín Duffy On 03/12/2013 08:30 AM, Fabian Deutsch wrote: What about pulling the message stuff into plymouth and using dracut to trigger a reboot which shows the grub menu? Something along the lines: Press ESC to see deatils or 'b' to enter the bootloader This is an interesting idea, but I don't think plymouth makes it any easier to display CJK Indic glyphs. (Please someone more technical tell me if I'm wrong here, I vaguely remember this being an issue when we wanted to add a messagse to fedup) I hoped that it would be easier to localize plymouth compared to grub2. In addition to that we'd also get rid of problems resulting of the interaction between grub2 s gfx stack and the kernel/plymouth, and last but not least we wouldn't need to maintain a theme for grub. - fabian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, Mar 11, 2013 at 01:43:28PM -0400, Ryan Lerch wrote: IIRC, in f17, the GRUB screen was not visible. (you could still press f11 to bring it up if you needed it to). Does anyone know why this behaviour changed? I think you're thinking of F15. It was a patch we were carrying to grub1, and it wasn't particularly well liked, so we didn't see it as worth investing the time in when we switched to grub2. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self introduction
On 03/12/2013 09:47 AM, Hans de Goede wrote: It would be helpful if you could provide bugzilla links to the 2 packages you've up for review. I believe these are the reviews. He may have missed your e-mail due to the massive fire-hose of paint being thrown on the nearby bike shed. https://bugzilla.redhat.com/show_bug.cgi?id=915337 https://bugzilla.redhat.com/show_bug.cgi?id=919429 Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tomcat6 unresponsive maintainer deprecation
Quoting Kevin Fenzi (2013-03-12 15:53:56) On Tue, 12 Mar 2013 13:49:22 +0100 Stanislav Ochotnicky sochotni...@redhat.com wrote: Tomcat6 package in Fedora is old, has several problematic bugs (including 4 security) and most importantly there's a replacement: tomcat-7.x I believe it is in our (developers as well as users) best interest to get rid of it. I have sent similar email to java-devel on February 26th[1], created another tomcat6 bugreport a week ago[2] but I wasn't successful in reaching David Knox (primary maintainer). Note that we already had a bugreport to migrate packages to tomcat-7[3] and we almost succeeded, but then new packages started creeping in with dependency on tomcat6. We need to get rid of it ASAP or we'll be fighting neverending battle. Even as comaintainer/provenpackager I cannot deprecate package that I do not own. I consider this point 4 of unresponsive maintainer process[4]. However due to security issues, and package being effectively dead I wouldn't mind speeding up the process. I might try to bring this up with FESCO, but process doesn't seem to include any wiggle room there. Feel free to file a fesco ticket and explain whats going on. Thanks, filed https://fedorahosted.org/fesco/ticket/1094 I believe the emails/bugzilla provides enough context but I'll also try to attend the FESCO meeting to answer any questions. -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Tue, 12 Mar 2013 11:10:27 -0400 Peter Jones pjo...@redhat.com wrote: Honestly, I'd like to do this anyway - the grub2 gfxterm code seems to cause nothing but bugs in later graphics setup. That said, I'd rather go back to not having it at all, but with a different plan than last time. The idea would be to have a positive indication from systemd that we've gotten to some pre-defined point on the previous boot (say, starting your login manager), and not to show you any menu unless the previous boot didn't get that far. So when you install a new kernel, the process would look like: ...snip reasonable plan... One downside: systemd can see that it started your display manager fine, but it can't tell that it's actually displayed correctly. I guess we can try this and see how often a case like that happens. On BIOS machines I think we can still accomplish #1 and #2 as well, but there's no guarantee of a way to disable firmware timeouts or press f2 for setup screens and loading the usb stack. If it's at all possible, I personally would vastly prefer hold down any key to get to the menu. rationale: a) It's very easy to document b) it avoids keymap / keyboard / locale issues. I don't have function keys, etc. c) if avoids people who have slow reaction time Hit F1 in 5 seconds d) It means you can hold down the key and boot and don't need to send your full attention to it until it's at the grub menu. (for some servers that take minutes to get to grub, it's very easy to get distracted, miss the window and have to reboot again). kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Mon, Mar 11, 2013 at 05:51:06PM -0400, Máirín Duffy wrote: On 03/11/2013 05:01 PM, Lennart Poettering wrote: By hooking this up to keys people would natrually try, such as shift, space, enter, escape, or whatever windows does for their boot menu stuff. FWIW Windows uses F8 Windows 8 on new hardware does not do this. At all. There is no key hooked up until the OS is running. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
f19 mass branching
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, F19 has been branched, please be sure to do a git pull --rebase to pick up the new branch, additionally rawhide/f20 has had inheritance cut off from previous releases, so this means that anything you do for f19 you also have to do in the master branch and do a build there. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlE/SfkACgkQkSxm47BaWfcN1wCguWnZhlA7wwIRD5rUm/s8gnk1 DFQAniCIITZodm/r3xkw+aOz227+AFYH =da30 -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: Self introduction
On Tue, Mar 12, 2013 at 4:23 PM, Michael Cronenworth m...@cchtml.com wrote: I believe these are the reviews. He may have missed your e-mail due to the massive fire-hose of paint being thrown on the nearby bike shed. I accidentally made a wrong reply, as my gmail doesn't reply to the mailing list by default. I hope this mail ends up where it should. https://bugzilla.redhat.com/show_bug.cgi?id=915337 https://bugzilla.redhat.com/show_bug.cgi?id=919429 Those are the correct ones. Regards Palle Ravn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
