Re: well!
On 03/12/2013 08:17 PM, Till Maas wrote: On Tue, Mar 12, 2013 at 12:47:07AM -0400, Digimer wrote: On 03/12/2013 12:41 AM, Charles Zeitler wrote: i don't like giving up control over my machine (partitioning), so i won't be upgrading to Fedora 18. i'll watch the web site for a return to sanity. charles zeitler Setting aside the drama, you can manually partition F18. Unless anaconda crashes (live image) or does not recognise the partitions (DVD image). :-/ Reference: https://bugzilla.redhat.com/show_bug.cgi?id=905669 Btw.: Ideas how to install F18 anyhow are welcome. If I'm honest, I couldn't get F18 Anaconda to install to the partition I wanted either :S I have multiple Linux OS partitions (Fedora 18, Rawhide, Ubuntu), and one big home directory partition, and I wanted Anaconda to replace one of them. Eventually I gave up, installed F18 to a VM, and then used rsync + restorecon + grub2-mkconfig (!) to get it into the partition I wanted. Cheers, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: well!
On 03/13/2013 12:17 PM, Stef Walter wrote: On 03/12/2013 08:17 PM, Till Maas wrote: On Tue, Mar 12, 2013 at 12:47:07AM -0400, Digimer wrote: On 03/12/2013 12:41 AM, Charles Zeitler wrote: i don't like giving up control over my machine (partitioning), so i won't be upgrading to Fedora 18. i'll watch the web site for a return to sanity. charles zeitler Setting aside the drama, you can manually partition F18. Unless anaconda crashes (live image) or does not recognise the partitions (DVD image). :-/ Reference: https://bugzilla.redhat.com/show_bug.cgi?id=905669 Btw.: Ideas how to install F18 anyhow are welcome. If I'm honest, I couldn't get F18 Anaconda to install to the partition I wanted either :S I have multiple Linux OS partitions (Fedora 18, Rawhide, Ubuntu), and one big home directory partition, and I wanted Anaconda to replace one of them. Eventually I gave up, installed F18 to a VM, and then used rsync + restorecon + grub2-mkconfig (!) to get it into the partition I wanted. That was my experience as well. LVMs though instead of partitions. I solved it by deleting the LVM I wanted to replace and letting Anaconda create a new LVM using the space from the old one. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
On Tue, 12 Mar 2013 17:59:50 +0100, Honza Horak hho...@redhat.com wrote: On 03/06/2013 02:44 PM, Miloslav Trmač wrote: On Wed, Mar 6, 2013 at 2:35 PM, Norvald H. Ryeng norvald.ry...@oracle.com wrote: In practice, this means that it will be almost impossible to install MySQL in Fedora. The recipe in the feature page [1] requires the user to 1. edit yum.conf to set excludes=mariadb* and obsoletes=0, 2. run yum shell to replace the packages, and 3. edit yum.conf again to remove obsoletes=0. I think that the above recipe wasn't updated for the package rename; with the new name, a simple yum install MySQL should work. Honza, is that how it was designed? Yes, the feature page has been updated to correspond with the renaming of mysql package. Shortly, users will be able to install MySQL-server in a usual way (yum remove mariadb-server ; yum install MySQL-server). What is a bit different -- MySQL-server requires mysql virtual symbol to have utilities like mysql, mysqldump, etc. These are by default provided by package mariadb, so it means MySQL-server will require mariadb base package (in the same manner as all other packages in Fedora, which need mysql client utilities). I believe the tools should match the server. I.e, MariaDB tools for MariaDB server, MySQL tools for MySQL server. I believe there are already minor protocol differences between MariaDB and MySQL. Having a MySQL server without fully working admin tools is not good. The FESCo decision from the minutes was: feature owners are asked to make it possible to install the MySQL stand-alone server (only) so dependencies on the client libraries are not a concern; Fedora packages are expected to use the MariaDB client libraries. Everything that depends on mysql will then require mariadb to be installed, but having both mariadb and MySQL at the same time is not going to work unless the files in the mariadb packages are renamed. File conflicts within the server packages might still be a concern, I don't know. Per the decision quoted above, FESCo would prefer the maintainers of the two servers to agree on a solution. I believe conflicting server packages are not an issue -- users will be able to use one or another. I disagree. The best example of this not working is the akonadi-mysql package which now depends directly on mariadb-server. This makes it impossible/very much harder to install MySQL on a KDE desktop. Also, there are applications depending on mysql or mysql-server. If the MySQL packages aren't allowed to provide those virtual provides, it will be impossible to use those applications with MySQL. The best would be to make the packages non-conflicting, either completely separate or using alternatives to set a default. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: twinkle: Intent to retire
On 2013-03-12, 23:11 GMT, Peter Robinson wrote: I've never managed to make that work, when ever I configure it all I get is a crash. Using sip.redhat.com (that's eZuce OpenUC) I have just made a call to my cellphone. I have telepathy-rakia-0.7.4-3. Best, Matěj -- 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 Tue, 12 Mar 2013 14:33:21 +0100, Honza Horak hho...@redhat.com wrote: 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. I believe both libraries should be installable and that the upstream projects and/or the maintainer of the package should choose which library to use. There are already API differences, so the libraries aren't fully interchangeable. The libraries are two different implementations of the same protocol. I don't see why they should use the same soname. With a parallel installation, a transition from one library to the other could be done gradually and controlled, one package at a time, with less risk of breakage. 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? Yes, 5.6 will be in as soon as things settle and we find a workable solution for having both MariaDB and MySQL in the same distro. We already have 5.6.10 packaged. We're just waiting for package names, dependencies and everything else to settle. There's no need to mix yet another variable into the equation right now. It's complex enough without it. I'm not sure about the version number. I'll have to check with those responsible for the the client library. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: twinkle: Intent to retire
On 13 Mar 2013 08:02, Matej Cepl mc...@redhat.com wrote: On 2013-03-12, 23:11 GMT, Peter Robinson wrote: I've never managed to make that work, when ever I configure it all I get is a crash. Using sip.redhat.com (that's eZuce OpenUC) I have just made a call to my cellphone. I have telepathy-rakia-0.7.4-3. It might have improved in f18, I got sick of trying and no response from the maintainer to abrt reports -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
Dne 12.3.2013 16:30, Dennis Gilmore napsal(a): -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. Why was it cut off so soon actually? The reason for disabling inheritance was due to Bodhi updates, which might not go stable, if I remember correctly, but Bodhi is not in action yet I suppose, so the cut of was too soon IMO. Could you please reconsider it? Thank you. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Dne 12.3.2013 19:16, Ray Strode napsal(a): Hi, 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. Yea it's not really easier. We start plymouth in the initrd, and we don't have fonts, translations, font rendering libraries or anything in the initrd. we could ship those things in the initrd but it would make the initrd substantially larger. Of course we can do localized text fine on systems that don't have initrds, or at later points in the boot process after we've switched out of the initrd. --Ray May be some nice pictogram wold make it without translation. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On Tue, 12 Mar 2013 18:25:02 +0100, Honza Horak hho...@redhat.com wrote: On 03/12/2013 01:14 PM, Norvald H. Ryeng wrote: 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. I don't think conflict is actually the main problem -- the inability of RPM to un-ambigously choose one of the two packages that provide the same symbol *is* the real problem. If we solved that one, MySQL-server could provide right symbol and KDE system would be happy. I fully agree that enforcing the default is the main problem. It makes the whole ting very difficult. Package conflict is a problem as soon as packages start depending on one particular server or tools implementation (e.g., akonadi-mysql). If both have the same virtual provide and all packages depend on that instead of a specific implementation, they can be conflicting. 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 Interesting idea, we can try that and see if it works, but anyway, I'm not sure if we should rely on it, unless RPM will be consistent and well-defined in that case. So, Jan (or someone from RPM guys), could this be somehow better than simple shorter package name wins or the idea with epoch would still be considered as undefined behavior from RPM POV? Using alternatives could also be considered. In any case, the packages have to be installable in parallel. Sorry for repeating myself -- even if we used alternatives and packages would be installable in parallel -- we still need to say which package is preferred in dependencies. Still the same issue with RPM. I agree. But it could solve the akonadi-mysql problem. I understand their wish to know exactly which server they run, so they could depend on one particular server and start it using the unique server name instead of the alternatives maintained symlink. Packages that only depend on a non-specific server or tools could use the symlinks. Regards, Norvald H. Ryeng -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On Tue, 12 Mar 2013 23:31:46 +0100, Kevin Kofler kevin.kof...@chello.at wrote: Norvald H. Ryeng wrote: This dependency is a problem. It makes it impossible to install MySQL-server on a KDE system since mariadb-server and MySQL-server conflict. That just shows how broken it is to have both in Fedora at the same time. The current solution is broken, but I hope we can find a way to have both. We need to make sure that 1. the live CD composes don't fail due to conflicts and 2. our users get the default database flavor, not a random one, and I don't see any other way to enforce this than to require mariadb-server directly. Are you saying that you would always like to have one particular server implementation, or could you depend on a common provide and let the user choose one or the other (as long as the default situation is solved)? This will influence the possibilities we have wrt. server packaging: - If your answer is that you would like akonadi-mysql to always choose MariaDB or MySQL (no user choice), we have to make MariaDB and MySQL parallel installable. - If you are happy with either implementation (default, or changed manually by the user), we can have conflicting MariaDB and MySQL packages. 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 Wed, Mar 13, 2013 at 12:10 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Mar 12 mars 2013 21:53, Máirín Duffy a écrit : I tried breaking this thread down into its components and summarizing the discussion and points brought up thus far. I hope it helps: http://blog.linuxgrrl.com/2013/03/12/improving-the-fedora-boot-experience/ Máirín, The proposal discussed here is not to keep the hood on the car. The proposal is to remove any indication there is a hood, and show the user a seamless surface with no hint it can be opened (or how). No one there objects to pretty hoods. They object to fixing the hood appearance by removing any indication of a hood. Good car design is not removing the emergency tail lights button because it ruins the panel appearance. Good car design is to keep the emergency tail lights button, and make it pretty. Even if regulations demand it is bright red when the designer wanted a smooth black panel. You are making too much fuzz about emergency and maintenance... we tried this once and the world didn't fall over. The only reason why we don't have it now is the move to grub2. If you know 1) what a kernel is 2) that booting a different kernel might fix your boot issue then you should be able to open the boot menu. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2013-03-13 @ 17:00 UTC - F19 Alpha Blocker Bug Review #1
# F19 Alpha Blocker Review meeting #1 # Date: 2013-03-13 # Time: 17:00 UTC (13:00 EDT, 10:00 PDT) # Location: #fedora-blocker-review on irc.freenode.net A few blockers have been proposed for Alpha and it's time to start the always popular blocker review meetings! We'll be running through the alpha blockers and freeze exception bugs. The current list is available at: http://qa.fedoraproject.org/blockerbugs/current We'll be reviewing the bugs to determine ... 1. Whether they meet the alpha release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria For guidance on Blocker and Nice-to-have (NTH) bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process For the blocker review meeting protocol, see - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Headups: soname bump for librabbitmq
I just build librabbitmq 0.3.0 in f19 and rawhide. Soname change from .0 to .1 Related packages php-pecl-amqp opensips-event_rabbitmq Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Headups: soname bump for librabbitmq
Le 13/03/2013 09:50, Remi Collet a écrit : I just build librabbitmq 0.3.0 in f19 and rawhide. Other change: tools moved to new librabbitmq-tools sub-package so librabbitmq only provides the library. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
On Wed, Mar 13, 2013 at 8:25 AM, Vít Ondruch vondr...@redhat.com wrote: Dne 12.3.2013 16:30, Dennis Gilmore napsal(a): -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. Why was it cut off so soon actually? The reason for disabling inheritance was due to Bodhi updates, which might not go stable, if I remember correctly, but Bodhi is not in action yet I suppose, so the cut of was too soon IMO. Could you please reconsider it? Thank you. No, branching is the correct time to do it. Mandated tagging through koji and inheritance are completely unrelated. At the moment koji tags the packages straight into f19 rather than tagging to f19-updates-candidate and having bodhi deal with the tagging. Inheritance only affect whether something is built in f19 is inherited through to rawhide. There was a discussion some time ago about this so presumably this change was either a decision by release engineering or FESCo. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: tomcat6 unresponsive maintainer deprecation
- Original Message - From: Dan Mashal dan.mas...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, March 12, 2013 9:34:24 PM Subject: Re: tomcat6 unresponsive maintainer deprecation On Tue, Mar 12, 2013 at 10:30 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Quoting Dan Mashal (2013-03-12 18:11:06) On Tue, Mar 12, 2013 at 10:06 AM, yersinia yersinia.spi...@gmail.com wrote: On Tue, Mar 12, 2013 at 6:05 PM, devzero2000 pinto.e...@gmail.com wrote: On Tue, Mar 12, 2013 at 4:28 PM, Stanislav Ochotnicky sochotni...@redhat.com wrote: 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. I have received this today http://www.exploitthis.com/2013/03/rhsa-20130623-1-important-tomcat6-security-update.html. Dunno if useful. Best -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I actually tried to install tomcat6 last night on RHEL6.4 and was having issues. Funny. Don't know if Fedora has the same release (haven't checked), but this is pretty important as I use tomcat at work. Could a proven packager take a look at it as well, (ASAP if it's a security issue?). There's more of them (bugs), but please for the love of all that is holy...don't use tomcat6. Every single supported Fedora release has tomcat-7.x where Ivan Afonichev is doing pretty great work with updates/bugfixing (kudos). Use it. Forget tomcat6. Situation is different on RHEL of course, there the tomcat6 is still being actively maintained (and will be for whole life of the given release). -- 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 Well I was using it on RHEL obviously. Are you saying we have both tomcat6 and tomcat7 in Fedora? Why don't we just hand the package ownership of tomcat6 over to Ivan then (after going through the proper processes)? I see 2 reasons: * Ivan haven't expressed such will - as neither you nor I can speak for himself until he decides whether he wants to do it and apply in pkgdb it's a non option * tomcat6 screws many things in the distro as a whole - even if someone picks it up tomcat6 would need to modified a lot to not provide unversioned servlet/jsp/etc. which is work that noone wants to do (at least noone yet) for old versions. Alexander Kurtakov Red Hat Eclipse team Dan -- 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: Improving the Fedora boot experience
On Wed Mar 13 00:32:09 UTC 2013 Máirín Duffy wrote: Displaying information geared towards power users by default is intimidating / confusing to less-knowledgeable users. Surely if our target audience / user base is those who have a capability / interest in contributing then we shouldn't be looking to dumb the boot experience down - that would probably be a reasonable choice for Mint or Ubuntu but I fail to see why it's a good one for Fedora. Alan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 12 March 2013 22:13, Simo Sorce s...@redhat.com wrote: Why should the default configuration be ugly, slow, and biased toward handling the odd case when things break ? I confess I've only been lightly skimming this entire deeply interesting thread, on which more man hours have almost certainly now been spent than will ever be taken by a boot delay in grub, however I did get the impression that 'ugly' is actually a series of fixable bugs and not the inevitable result of making it apparent to a user that the boot sequence can be interrupted and changed if the machine is in trouble. Further, aside from the 'broken' boot problem (and lots of people on this devel list will have much easier access to multiple computers to look things up in that case than the average user), there is also the case where people are asked to change boot parameters to help try and debug problems that do not directly result in the machine not booting. Now in that case you can tell them how to do it, but why not make it simple rather than requiring hair trigger reflexes to catch the right key at the right moment (and again, that's harder for someone who is not used to messing about with booting and the timings and sequences involved). -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: twinkle: Intent to retire
- Original Message - On 2013-03-12, 22:28 GMT, Kevin Kofler wrote: The main showstopper there is that they almost all directly or indirectly (e.g. through libmediastreamer) depend on FFmpeg. Ekiga seems to be the only one using GStreamer. :-( And telepathy-rakia (I positively hate Empathy as UI, but the telepathy is a great framework as proven on platforms with better UI than we have in Gnome, e.g., N900) Yep, very happy user of N9 telepathy-rakia. And with Telepathy, the integration is amazing. Not sure how current call UIs in out Telepathy clients looks like... Jaroslav Matěj -- 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 QA] #343: Add cgit link to Main Page
#343: Add cgit link to Main Page ---+--- Reporter: tflink| Owner: mkrizek Type: enhancement | Status: new Priority: trivial | Milestone: Fedora 19 Component: Blocker bug tracker page |Version: Resolution:| Keywords: Blocked By:| Blocking: ---+--- Changes (by mkrizek): * cc: qa-devel@… (added) * owner: tflink = mkrizek -- Ticket URL: https://fedorahosted.org/fedora-qa/ticket/343#comment:1 Fedora QA http://fedorahosted.org/fedora-qa Fedora Quality Assurance ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Fedora 18 on Asus U38N-C4010H
Hi Fedora people, I am writing this so somewhere on the Internet there is some info on running Fedora on an U38N. If you use the F18 Live image on a USB stick, reboot the computer from Win8 and keep the esc button pressed you can choose to boot from usb or hard drive. Choosing USB boots up Fedora (seems like there is something regarding secure boot there) Fedora boots up and you can get into gnome. All HW seems to work except for the WLAN. However, if you reboot the laptop from the F18 live image and try to boot F18 again you only get a black screen after the verified by vendor message. If you boot into Win8 and boot into Fedora 18 everything seems to work, but rebooting into F18 from F18 does not work. I do not have access to the laptop anymore so I will not be able to test anything else. But I will see if I can try F19 alpha on it. /Andreas Tunek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Wed, 2013-03-13 at 10:16 +0100, Reindl Harald wrote: Am 13.03.2013 02:54, schrieb Simo Sorce: On Tue, 2013-03-12 at 23:23 +0100, Reindl Harald wrote: Am 12.03.2013 23:13, schrieb Simo Sorce: On Tue, 2013-03-12 at 22:37 +0100, Reindl Harald wrote: Am 12.03.2013 22:34, schrieb Simo Sorce: I reboot VMs a lot for development, 2 seconds do make a difference Bruhahaha 100 reboots = 200 seconds = 3.3 Minutes more for 100 reboots well, i boot probably more VMs you have ever seen BUT if two seconds are really counting you are doing something terrible wrong and should take a deep breat and a coffee Wehn you spin 100 Vms at the same time and do not care when they come up you are not in teh same situationa s someone doing development and waiting doing nothing on the particular VM he is testing who speaks of spin up 100 VMs at the same time? i am doing also development and reboot test-VMs often but if you believe 2 seconds boot-time make and difference you are doing all wrong - some people hammering permanently on their machines and get hurted by two seconds, others are thinking before the are doing technical stuff, you can guess which are having more success at the end of the day Yeah I must be a useless idiot your words SO DISABLE THE GRUB-DELAY ON YOU FUCKING MACHINE BUT LEAVE THE DEFAULTS IN PEACE - IS THIS SO DIFFICULT AND IF IT IS HOW DIFFICULT WOULD IT BE FOR THE BEGINNER TO GET THE OTHER TURN? Dear Reindl, it is evident even to a beginner that it is clearly more difficult for a beginner to change a system setting than for an experienced admin. You know that, so you already know the answer to your question. Shouting and swearing will not improve your message in any way. Your faithful idiot, Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
How to update to Ruby 2.0.0 in Rawhide?
I just got notification of this broken dependency: libguestfs has broken dependencies in the F-19 tree: On x86_64: 1:ruby-libguestfs-1.21.19-1.fc19.x86_64 requires ruby(abi) = 0:1.9.1 [etc] No problem with that. However I tried to install the new Ruby on my Rawhide machine, but it doesn't seem to be available in the repositories. Short of installing it by hand from Koji, is there something I have to do get the new Ruby version? Currently I have: ruby-1.9.3.385-28.fc19.x86_64 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/13/2013 12:26 AM, Ralf Corsepius wrote: - (Nobody explicitly stated this, but) Displaying information geared towards power users by default is intimidating / confusing to less-knowledgeable users. I'd call this to be an urban legend. A boot menu is self-explanatory, even to new-comers. It may baffle them when they see it for the first time, but will very soon get used to it. No, a boot menu is not self-explanatory, and no, this is not an 'urban legend.' How do you even come up with associating the term 'urban legend' to statement saying that a complex screen is confusing to casual computer users? That's like calling Fitts' Law an 'old wives' tale!' I have taught multiple classes of teenage and pre-teen students using Fedora Live USB keys. This necessarily involves having to guide them through using syslinux (which is very similar in appearance to grub) to boot their system, I can say from actual experience that: 1) The boot menu was not self-explanatory, and the students had a lot of questions about what stuff on the screen meant. 2) After the students got used to it, it really annoyed them because it delayed their bootup and they had to hit enter to get through it. 3) Occasionally they would see the screen, panic, forget the correct menu entry to select (the first one) and would have to ask for help even a few weeks into the program. I do hope they were able to continue to use the keys after the classes were over and they were allowed to take them home, but if they got confused I don't even know if asking their parents would have helped. If the general principle of 'specialized technical crap confuses people who don't understand it' is a mystical urban legend to you, you might want to try teaching a class to less-experienced computer users or watching usability test videos. Or maybe try volunteering at a community technical helpdesk. Your opinion will change pretty quickly. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/13/2013 12:47 AM, Stephen John Smoogen wrote: I read the blog and I was NOT talking about your blog post. Rereading what I wrote does show that I did not convey that clearly. What I was trying to refer to was that over the long winding thread others have pointed out that this would be great from an aesthetics view or implying that wanting to see the boot messages was uglifying things. That was where my dander was getting up earlier. Your blog post did not get up my dander and I was agreeing that you were a) listening to us old grognards and b) trying to come up with a solution that encompassed that listening. I don't think it's worth getting upset over the aesthetics point because it clearly appears to be a minor one and not the main impetus. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Wed 13 Mar 2013 08:53:32 AM EDT, Reindl Harald wrote: i wonder how i survived to learn all this stuff which is so confusing - why do linux need to handhold anybody which does get scared from a simple menu where each trained monkey in doubt seletcs the first entry? Clearly you're a genius, Reindl. But I could already tell that from your other posts to this thread. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to update to Ruby 2.0.0 in Rawhide?
Dne 13.3.2013 13:40, Richard W.M. Jones napsal(a): I just got notification of this broken dependency: libguestfs has broken dependencies in the F-19 tree: On x86_64: 1:ruby-libguestfs-1.21.19-1.fc19.x86_64 requires ruby(abi) = 0:1.9.1 [etc] No problem with that. However I tried to install the new Ruby on my Rawhide machine, but it doesn't seem to be available in the repositories. Short of installing it by hand from Koji, is there something I have to do get the new Ruby version? Currently I have: ruby-1.9.3.385-28.fc19.x86_64 Rich. Hi Rich, It was merged yesterday afternoon, so it might take time to propagate through mirrors I guess, but it is definitely available in Koji [1]. Btw I did some update script, I am using personally [2], though for Ruby bindings it might not be very usable. It should be enough to run `update.rb yourpackage.spec` which should do the basic modifications mandated by updated Ruby packaging guidelines [3]. I know it is not overdocumented, sorry about that :/ Vít [1] http://kojipkgs.fedoraproject.org/repos/rawhide/latest/x86_64/ [2] https://github.com/voxik/fermig [3] https://fedoraproject.org/wiki/Packaging:Ruby -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to update to Ruby 2.0.0 in Rawhide?
On Wed, Mar 13, 2013 at 7:40 AM, Richard W.M. Jones rjo...@redhat.comwrote: I just got notification of this broken dependency: libguestfs has broken dependencies in the F-19 tree: On x86_64: 1:ruby-libguestfs-1.21.19-1.fc19.x86_64 requires ruby(abi) = 0:1.9.1 [etc] No problem with that. However I tried to install the new Ruby on my Rawhide machine, but it doesn't seem to be available in the repositories. Short of installing it by hand from Koji, is there something I have to do get the new Ruby version? Currently I have: ruby-1.9.3.385-28.fc19.x86_64 I see the same behaviour in local rawhide mock. I'm wondering if the tagging is correct, it was built in a side tag. -J Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
Dne 13.3.2013 10:09, Peter Robinson napsal(a): On Wed, Mar 13, 2013 at 8:25 AM, Vít Ondruch vondr...@redhat.com wrote: Dne 12.3.2013 16:30, Dennis Gilmore napsal(a): -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. Why was it cut off so soon actually? The reason for disabling inheritance was due to Bodhi updates, which might not go stable, if I remember correctly, but Bodhi is not in action yet I suppose, so the cut of was too soon IMO. Could you please reconsider it? Thank you. No, branching is the correct time to do it. Mandated tagging through koji and inheritance are completely unrelated. At the moment koji tags the packages straight into f19 rather than tagging to f19-updates-candidate and having bodhi deal with the tagging. Inheritance only affect whether something is built in f19 is inherited through to rawhide. There was a discussion some time ago about this so presumably this change was either a decision by release engineering or FESCo. I am afraid that the discussion was more generic, i.e. Rawhide should not inherit from branched Fedora and since I remember the main reason for breaking inheritance was Bodhi and Bodhi is not yet in a game, it should be clarified and adjusted. Vít Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to update to Ruby 2.0.0 in Rawhide?
On Wed, Mar 13, 2013 at 12:40 PM, Richard W.M. Jones rjo...@redhat.com wrote: I just got notification of this broken dependency: libguestfs has broken dependencies in the F-19 tree: On x86_64: 1:ruby-libguestfs-1.21.19-1.fc19.x86_64 requires ruby(abi) = 0:1.9.1 [etc] No problem with that. However I tried to install the new Ruby on my Rawhide machine, but it doesn't seem to be available in the repositories. Short of installing it by hand from Koji, is there something I have to do get the new Ruby version? It was only tagged in yesterday and there's not been a compose and push to mirrors since. Once that's completed it should be the usual yum upgrade process. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to update to Ruby 2.0.0 in Rawhide?
Dne 13.3.2013 14:01, Jon Ciesla napsal(a): On Wed, Mar 13, 2013 at 7:40 AM, Richard W.M. Jones rjo...@redhat.com mailto:rjo...@redhat.com wrote: I just got notification of this broken dependency: libguestfs has broken dependencies in the F-19 tree: On x86_64: 1:ruby-libguestfs-1.21.19-1.fc19.x86_64 requires ruby(abi) = 0:1.9.1 [etc] No problem with that. However I tried to install the new Ruby on my Rawhide machine, but it doesn't seem to be available in the repositories. Short of installing it by hand from Koji, is there something I have to do get the new Ruby version? Currently I have: ruby-1.9.3.385-28.fc19.x86_64 I see the same behaviour in local rawhide mock. I'm wondering if the tagging is correct, it was built in a side tag. -J It works, see my builds from today's morning: http://koji.fedoraproject.org/koji/taskinfo?taskID=5116331 http://koji.fedoraproject.org/koji/taskinfo?taskID=5116329 Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to update to Ruby 2.0.0 in Rawhide?
On Wed, Mar 13, 2013 at 8:06 AM, Vít Ondruch vondr...@redhat.com wrote: Dne 13.3.2013 14:01, Jon Ciesla napsal(a): On Wed, Mar 13, 2013 at 7:40 AM, Richard W.M. Jones rjo...@redhat.comwrote: I just got notification of this broken dependency: libguestfs has broken dependencies in the F-19 tree: On x86_64: 1:ruby-libguestfs-1.21.19-1.fc19.x86_64 requires ruby(abi) = 0:1.9.1 [etc] No problem with that. However I tried to install the new Ruby on my Rawhide machine, but it doesn't seem to be available in the repositories. Short of installing it by hand from Koji, is there something I have to do get the new Ruby version? Currently I have: ruby-1.9.3.385-28.fc19.x86_64 I see the same behaviour in local rawhide mock. I'm wondering if the tagging is correct, it was built in a side tag. -J It works, see my builds from today's morning: http://koji.fedoraproject.org/koji/taskinfo?taskID=5116331 http://koji.fedoraproject.org/koji/taskinfo?taskID=5116329 So it does, thanks! -J Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: twinkle: Intent to retire
On Wed, Mar 13, 2013 at 4:14 AM, Peter Robinson pbrobin...@gmail.com wrote: It might have improved in f18, I got sick of trying and no response from the maintainer to abrt reports I too have had problems getting any sort of response from the maintainer, but I'm always one to give second chances. On a whim, I decided to try out telepathy-rakia again this morning. Created a new SIP account on my Asterisk box, created a SIP account in Empathy, got that both calling to Asterisk and registering to Asterisk. So far so good... But then I tried to make some calls. A call to a simple extension in Asterisk that plays a sound prompt and then hangs up gave me no audio. (I tested the extension with both Twinkle and a hard phone, and neither had any problems.) I then made a call from Twinkle to Empathy. I got the notification that the call was ringing, I answered it, and audio passed in both directions for several seconds. When I hung up the call in Twinkly, Empathy didn't tear down its call -- it acted as if the call were still active for another ten seconds or so, and then crashed. ABRT reported that the issue is already known at https://retrace.fedoraproject.org/faf/reports/44919/, which links to https://bugzilla.redhat.com/show_bug.cgi?id=910079. I've tried several other things this morning, but it doesn't seem nearly stable enough to be my daily driver softphone. Time to go try out Ekiga again, it seems. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
From: Rahul Sundaram methe...@gmail.com On 03/12/2013 08:17 PM, Jasper St. Pierre wrote: What is the point of the RPM changelog then? RPM changelog is for packaging changes. Bodhi update notes are for the user. They are not merely redundant copies of the same information. I see both sides of this argument. When I have my admin hat on, I really don't want to have to consult bodhi, which requires a net connection when I could simply do an 'rpm -q --changelog foo'. However, with my dev hat on, I can see the argument the other way. In my local packaging, my rpm changelogs are a mixture. If V is bumped the changelog describes the diffs between the new V and the old V. If R is bumped, the changelog most likely describes something that changed in the spec only. That's me and what I feel is proper (for local packaging) though. However, I would strongly suggest that if Fedora policy is to have the rpm changelog only cover R changes and not V changes, let's please amend this bit to make it much more explicit and clear to the reader, perhaps even providing the bodhi URL: man rpm(8) PACKAGE QUERY OPTIONS: --changelog Display change information for the package. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 13 March 2013 12:46, Máirín Duffy du...@fedoraproject.org wrote: On 03/13/2013 12:26 AM, Ralf Corsepius wrote: - (Nobody explicitly stated this, but) Displaying information geared towards power users by default is intimidating / confusing to less-knowledgeable users. I'd call this to be an urban legend. A boot menu is self-explanatory, even to new-comers. It may baffle them when they see it for the first time, but will very soon get used to it. No, a boot menu is not self-explanatory, and no, this is not an 'urban legend.' How do you even come up with associating the term 'urban legend' to statement saying that a complex screen is confusing to casual computer users? That's like calling Fitts' Law an 'old wives' tale!' I have taught multiple classes of teenage and pre-teen students using Fedora Live USB keys. This necessarily involves having to guide them through using syslinux (which is very similar in appearance to grub) to boot their system, I can say from actual experience that: 1) The boot menu was not self-explanatory, and the students had a lot of questions about what stuff on the screen meant. Then you have good students. Are teens and pre-teens fedora's main target audience now? I'm really not sure what it is anymore. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: twinkle: Intent to retire
On Wed, Mar 13, 2013 at 9:18 AM, Jared K. Smith jsm...@fedoraproject.org wrote: I've tried several other things this morning, but it doesn't seem nearly stable enough to be my daily driver softphone. Time to go try out Ekiga again, it seems. I know it's usually bad form to reply to yourself on a mailing list -- but I thought some people on this thread would like to know that trying to disabled a SIP account (using telepathy-rakia) also causes it to crash. See https://retrace.fedoraproject.org/faf/reports/57932/ for more info. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
- Original Message - On 03/12/2013 10:18 PM, Michael Catanzaro wrote: Again, I'm disappointed in seeing that placeholder text in stable updates. Clearly that plan failed---it'd be nice if Bodhi could become smart enough to reject updates with the placeholder description. I have filed a request on your behalf https://fedorahosted.org/bodhi/ticket/718 Thanks! And definitely +1. 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: Improving the Fedora boot experience
Le Mer 13 mars 2013 01:32, Máirín Duffy a écrit : On 03/12/2013 07:24 PM, Stephen John Smoogen wrote: I am saying this because I agree. To me the proposal (not the original but some point in the the 500 ms boot time ideal ) seemed very much a welded shut view. And as someone who has to worked on welded shut computers for asthetic reasons.. it brings out the fighting urge in me. Did you guys actually read the blog post? Is aesthetics cited in any of the reasons for hiding the menu? No, it's not. These were the reasons I cited in favor of the proposal to hide the menu: Máirín, That was uncalled for - Changing video modes makes the screen flash unnecessarily. This is an aesthetics argument The video mode changing also screws up how our X setup works and results in unnecessary bugs for users. Nobody here argued for mode changing. - We used to suppress the boot menu by default in earlier releases and its suppression didn’t cause major problems. This suppression was IIRC incomplete which is why people let it pass. - There’s other ways for the user to indicate wanting to enter the menu besides boot-time keypresses – other OSes have methods to enter these menus by rebooting from a running system (systemd is working on this) This is besides the point, if you are in a running system that means that the boot was successful. or automatically loading the menu when an error condition is encountered. And they are not reliable. It is good enough for them because any hardware that fails to boot under a commercial OS gets quickly RMA-ed. That is not the case for Linux. - Not listening for keypresses doesn’t probe USB, meaning not waiting for keypresses will make boot even faster since we won’t have to load/probe USB. Most of the systems Fedora runs on use USB devices in one form or another so this does not matter in real life. You'll need to probe anyway. - (Nobody explicitly stated this, but) Displaying information geared towards power users by default is intimidating / confusing to less-knowledgeable users. It is not a power-user oriented screen unless you think normal other never do updates and never get boot problems. UI is hard. Removing UI elements that were added to solve user problems is not improving UI. It's the ostrich approach to difficult decisions. Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: twinkle: Intent to retire
2013/3/12 Richard W.M. Jones rjo...@redhat.com: On Sun, Mar 10, 2013 at 11:53:00AM -0500, Ian Pilcher wrote: On 03/09/2013 12:08 PM, Kevin Fenzi wrote: So, I am going to retire this package in rawhide soon unless there's folks with a very strong C++ background wishing to fix issues and basically become the new upstream. Does Fedora currently have a functional soft-phone? Has Fedora *ever* had a functional soft-phone? Short answer is no. Fedora never has a fully functional SIP softphone. I personally hope we'll see Jitsi included in Fedora someday. Also one can try Empathy but last time I tried it has awful registration/authorization issues with Avahi, TCP, and IPv6 in different combinations. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 13 Mar 2013 14:03:26 +0100 Vít Ondruch vondr...@redhat.com wrote: Dne 13.3.2013 10:09, Peter Robinson napsal(a): On Wed, Mar 13, 2013 at 8:25 AM, Vít Ondruch vondr...@redhat.com wrote: Dne 12.3.2013 16:30, Dennis Gilmore napsal(a): -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. Why was it cut off so soon actually? The reason for disabling inheritance was due to Bodhi updates, which might not go stable, if I remember correctly, but Bodhi is not in action yet I suppose, so the cut of was too soon IMO. Could you please reconsider it? Thank you. No, branching is the correct time to do it. Mandated tagging through koji and inheritance are completely unrelated. At the moment koji tags the packages straight into f19 rather than tagging to f19-updates-candidate and having bodhi deal with the tagging. Inheritance only affect whether something is built in f19 is inherited through to rawhide. There was a discussion some time ago about this so presumably this change was either a decision by release engineering or FESCo. I am afraid that the discussion was more generic, i.e. Rawhide should not inherit from branched Fedora and since I remember the main reason for breaking inheritance was Bodhi and Bodhi is not yet in a game, it should be clarified and adjusted. Vít Peter https://fedorahosted.org/fesco/ticket/1005 i was asked to cut it at branching time, thats exactly what I did Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlFAfx0ACgkQkSxm47BaWfc8PQCdHIY+RF+TBDXkwHzvX9gHwU3M fbgAnj7Qo8HmJgpECTibV2wOzJkhdDil =14xW -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Tue, 2013-03-12 at 15:47 +0100, Jan Dvořák wrote: 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. IMO that one's actually solvable to an extent (in theory at least and not always to a 100% correct but good enough): The boot loader (GRUB2, gummiboot, ..., I don't care) stores the booted OS (as in e.g. Fedora $version, Windows $version, ...) in a short list (of say 2 ~ 5 items) and the timestamp of booting somewhere it can read it. If being rebooted (as opposed to being shut down), the OS (systemd probably but I don't really care) writes the current HW clock timestamp very late in the reboot process somewhere else the boot loader can read it. A timeout is enabled or extended appropriately if: - the user rebooted into different OSs in the last 2 ~ 5 times because the user seems to want multi-booting, or if - the time of previous boot is not long enough in the past because there might be a problem with the boot attempt (give the user a chance to boot something else, mess with the boot parameters, ...), or if - the time of shutdown before reboot is older than a certain threshold, because this indicates a BIOS with a very long POST (to help users not miss the opportunity to influence what is booted and how) Otherwise, no or a short timeout is used. I'm sure finding the best thresholds, length of the list etc. needs some experimenting, but besides that I don't see a glaring error with this idea. What do you think? Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
From: Chris Murphy li...@colorremedies.com I'm sure there were a bunch of sorry whiners missing verbose text boot scrolling by their screen by default, in favor of graphical boot. Or perhaps those whiners consider themselves responsible employees by being diligent in understanding what normal and correct looks like so that they can recognize when something is going south and maybe doing something to avert a crisis before it occurs. I swear that every time I read about how boot (or other) is so unaesthetic I really have to wonder if people are actually using their system as a tool to do work, or if they're merely playing with them as a novelty. Not that there's anything wrong such play, but please stop trying polish the appearance at the expense of functionality for those who see them only as tool. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
From: Chris Murphy li...@colorremedies.com On Mar 12, 2013, at 12:19 PM, john.flor...@dart.biz wrote: I personally could not care less about the defaults Fedora uses. I've been overriding them for years. I'm just glad I was able to learn these things before everything became hidden. Because, naturally, you don't explore, find, or learn anything hidden. No, I do find it, but at considerable expense sometimes which only decreases the value I find in any such system, Fedora or otherwise. Today's youth have none of the curiosity that I and my friends had at their age and I blame it on this you don't need to know how it works mentality that is infecting everything. Oh that's original. Your parents and grandparents never, ever said anything like this. They never said it to me. They encouraged my exploration despite situations where I maybe I should have been held back, but I learned and yes sometimes the very hard way. I see that way being replaced with fear, apprehension and avoidance; just be a consumer and stop trying to be a producer. From my POV, it's a sad progression, but hey that's just me and my screwed up perspective. If you really want that Apple experience, why don't you just use their goods? I do. Curious, isn't it, how I managed to stumble into linux boot loading, and file systems of all things, never having a single chance of seeing such things? They weren't merely hidden from me. They didn't even exist. Well good for you, but why make it harder than it needs to be? -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Wed, 2013-03-13 at 09:34 -0400, john.flor...@dart.biz wrote: From: Chris Murphy li...@colorremedies.com I'm sure there were a bunch of sorry whiners missing verbose text boot scrolling by their screen by default, in favor of graphical boot. Or perhaps those whiners consider themselves responsible employees by being diligent in understanding what normal and correct looks like so that they can recognize when something is going south and maybe doing something to avert a crisis before it occurs. And maybe they are wrong, we'll never know ... I swear that every time I read about how boot (or other) is so unaesthetic I really have to wonder if people are actually using their system as a tool to do work, or if they're merely playing with them as a novelty. Not that there's anything wrong such play, but please stop trying polish the appearance at the expense of functionality for those who see them only as tool. So let me allow to make a parallel. You go working every day wearing work clothes like these [1] because you see them only as a tool and you need to get work done ? An obviously caring about appearance as well as functionality or as a compromise is wrong, right ? Simo. [1] http://3.bp.blogspot.com/-PWiGSr3ymuw/TpnXBp-z0VI/D34/mMosookklVY/s1600/workclothes-01.jpg -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Anyway, here is a proposal for an alternative way to deal with the boot sequence. 1. the bootloader screen is no longer themed with colour backgrounds but is predominantly black and white. Boot is transitioning from a black shut down screen so any colour or grey background is going to flash. (Microsoft understood this fact years ago. They killed their old win9x colour background boot image) 2. Bootloader entries are prefixed by a small paragraph of text that explains they are safety options that should be used in case of problem. If you can localize it so much the better but from a user POW an English message is better than no message at all and silent failing. This is the last screen the user will see before boot craps itself, so it needs to be helpful not pretty. In case input has not been initialised yet it needs to at least provide a pointer to a web page that explains how to rescue the system (letting users google is not good. The only thing they will find is messages from other users that had boot problems, which will reinforce their feeling Fedora is not reliable). 3. if you want to cheer it up you can add a fire extinguisher icon or something else that conveys safety measure to an i18n audience. 4. that is the only theming that should occur. No colour experiments, no Fedora logo, no video mode switches, nothing to distract from the message 5. the default wait period is at least 5 seconds, maybe as much as 10. 6. any successful boot (where actual non automatic user activity occurs after the boot, and software shutdown completes) temporarily overrides the wait period and shortens it for the next boot to the minimal value that lets the user react (2-3 s IIRC from the discussion). So a hardware reset or battery pull restores the full default wait. As long as everything is fine users get short boots. 7. any detected problem, or dangerous operation such as kernel update resets the wait time till successful boot occurs again (see 6) 8. the wait periods are settable in kickstart so vm farm, embedded people, and Lennart can set it to zero if they feel like it. At zero it will flash too fast for users to notice (esp. if the screen is predominantly black). 9. after a few releases the wait period default values are reevaluated by FESCO, based on the actual in-the-field observed reliability of the error detection heuristics (ie build the new safety net before removing the old one) Sincerely, -- Nicolas Mailhot -- 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:52:40PM +0100, Nicolas Mailhot wrote: rescue system. (that's why safety jackets use flashy unfashionable colors) So we should make the boot loader use flashy unfashionable colors because it makes it more reliable? Ok that's silly, but it's also silly for safety jackets. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
From: Simo Sorce s...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Date: 03/13/2013 09:47 Subject: Re: Improving the Fedora boot experience Sent by: devel-boun...@lists.fedoraproject.org On Wed, 2013-03-13 at 09:34 -0400, john.flor...@dart.biz wrote: From: Chris Murphy li...@colorremedies.com I'm sure there were a bunch of sorry whiners missing verbose text boot scrolling by their screen by default, in favor of graphical boot. Or perhaps those whiners consider themselves responsible employees by being diligent in understanding what normal and correct looks like so that they can recognize when something is going south and maybe doing something to avert a crisis before it occurs. And maybe they are wrong, we'll never know ... They being the employees or the error messages? With either answer, I'd prefer to explain to my boss that I spent time investigating something that was merely a false alarm than to explain why I cannot now salvage something that has gone horribly wrong and I didn't do anything about it because the UX to warn me was unpleasant. I swear that every time I read about how boot (or other) is so unaesthetic I really have to wonder if people are actually using their system as a tool to do work, or if they're merely playing with them as a novelty. Not that there's anything wrong such play, but please stop trying polish the appearance at the expense of functionality for those who see them only as tool. So let me allow to make a parallel. You go working every day wearing work clothes like these [1] because you see them only as a tool and you need to get work done ? An obviously caring about appearance as well as functionality or as a compromise is wrong, right ? I have nothing wrong with wanting to make a good appearance, but I will never put that before function. As an engineer, I see beauty in function and capability, not glitter. If function doesn't have to be compromised, yeah go to town with the appearance. As for those work clothes, it would depend on the job. If I was to do business presentations, no I wouldn't want to be caught dead dressed that way. However, if I was about to jump in a grease pit and do some seriously dirty work, those look mighty appealing to me. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/13/2013 09:28 AM, Nicolas Mailhot wrote: Le Mer 13 mars 2013 01:32, Máirín Duffy a écrit : On 03/12/2013 07:24 PM, Stephen John Smoogen wrote: I am saying this because I agree. To me the proposal (not the original but some point in the the 500 ms boot time ideal ) seemed very much a welded shut view. And as someone who has to worked on welded shut computers for asthetic reasons.. it brings out the fighting urge in me. Did you guys actually read the blog post? Is aesthetics cited in any of the reasons for hiding the menu? No, it's not. These were the reasons I cited in favor of the proposal to hide the menu: Máirín, That was uncalled for Um, what? - Changing video modes makes the screen flash unnecessarily. This is an aesthetics argument You could say that. You could also say that it's an annoyance and causes X issues (which it does), which you decided to separate out as if I listed it as a different issue rather than the *same* issue. The video mode changing also screws up how our X setup works and results in unnecessary bugs for users. Nobody here argued for mode changing. Showing the screen makes that happen, so if you're arguing for showing the screen by default you are arguing for mode changing. - We used to suppress the boot menu by default in earlier releases and its suppression didn’t cause major problems. This suppression was IIRC incomplete which is why people let it pass. How was it incomplete? - There’s other ways for the user to indicate wanting to enter the menu besides boot-time keypresses – other OSes have methods to enter these menus by rebooting from a running system (systemd is working on this) This is besides the point, if you are in a running system that means that the boot was successful. See below quoted snippet split out. The 'or' is pretty key grammatically. or automatically loading the menu when an error condition is encountered. And they are not reliable. It is good enough for them because any hardware that fails to boot under a commercial OS gets quickly RMA-ed. That is not the case for Linux. Peter has already explained that the error detection mechanism here is very extensible. - Not listening for keypresses doesn’t probe USB, meaning not waiting for keypresses will make boot even faster since we won’t have to load/probe USB. Most of the systems Fedora runs on use USB devices in one form or another so this does not matter in real life. You'll need to probe anyway. We probe twice when we don't need to. - (Nobody explicitly stated this, but) Displaying information geared towards power users by default is intimidating / confusing to less-knowledgeable users. It is not a power-user oriented screen unless you think normal other never do updates and never get boot problems. UI is hard. Removing UI elements that were added to solve user problems is not improving UI. It's the ostrich approach to difficult decisions. I would argue that throwing information up in people's faces 100% of the time when it's useless to over 95% of those people is like throwing a text in Japanese at a non-Japanese English speaker in the hopes that somehow they would be able to read it and magically become fluent in Japanese. Yes, if you speak Japanese natively, it's quite easy for you and difficult for you to understand how anybody would struggle with it. You're a native speaker. Most people aren't. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
From: Nicolas Mailhot nicolas.mail...@laposte.net Anyway, here is a proposal for an alternative way to deal with the boot sequence. 1. the bootloader screen is no longer themed with colour backgrounds but is predominantly black and white. Boot is transitioning from a black shut down screen so any colour or grey background is going to flash. (Microsoft understood this fact years ago. They killed their old win9x colour background boot image) 2. Bootloader entries are prefixed by a small paragraph of text that explains they are safety options that should be used in case of problem. If you can localize it so much the better but from a user POW an English message is better than no message at all and silent failing. This is the last screen the user will see before boot craps itself, so it needs to be helpful not pretty. In case input has not been initialised yet it needs to at least provide a pointer to a web page that explains how to rescue the system (letting users google is not good. The only thing they will find is messages from other users that had boot problems, which will reinforce their feeling Fedora is not reliable). 3. if you want to cheer it up you can add a fire extinguisher icon or something else that conveys safety measure to an i18n audience. 4. that is the only theming that should occur. No colour experiments, no Fedora logo, no video mode switches, nothing to distract from the message 5. the default wait period is at least 5 seconds, maybe as much as 10. 6. any successful boot (where actual non automatic user activity occurs after the boot, and software shutdown completes) temporarily overrides the wait period and shortens it for the next boot to the minimal value that lets the user react (2-3 s IIRC from the discussion). So a hardware reset or battery pull restores the full default wait. As long as everything is fine users get short boots. 7. any detected problem, or dangerous operation such as kernel update resets the wait time till successful boot occurs again (see 6) 8. the wait periods are settable in kickstart so vm farm, embedded people, and Lennart can set it to zero if they feel like it. At zero it will flash too fast for users to notice (esp. if the screen is predominantly black). 9. after a few releases the wait period default values are reevaluated by FESCO, based on the actual in-the-field observed reliability of the error detection heuristics (ie build the new safety net before removing the old one) Sincerely, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel If this could be made to work as described, I'd be happy with it. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Hi, On Wed, 13 Mar 2013 14:29:34 +0100 Nils Philippsen n...@redhat.com wrote: Otherwise, no or a short timeout is used. I'm sure finding the best thresholds, length of the list etc. needs some experimenting, but besides that I don't see a glaring error with this idea. What do you think? I like it. Best regards, Jan Dvorak signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
How does it work: What package can open a file?
When you try to open a file for which you have no package installed that handles that file type, there is a GUI that pops up and asks if you want it to search for a package that can handle the file. How exactly does this mechanism work? I'm assuming there is some meta-data in the RPM package that provides this information? I'm trying to help fix a package which does support a particular file type but doesn't come up in the list of potential packages. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Am 13.03.2013 13:46, schrieb Máirín Duffy: If the general principle of 'specialized technical crap confuses people who don't understand it' is a mystical urban legend to you, you might want to try teaching a class to less-experienced computer users or watching usability test videos. Or maybe try volunteering at a community technical helpdesk. Your opinion will change pretty quickly what the hell i installed my first linux a few months after i bought my first PC in the 1990's and in this years there was no mailing-list and no internet at all, there was very few of all the shiny things which makes a linux OS these days nearly idiot proof i wonder how i survived to learn all this stuff which is so confusing - why do linux need to handhold anybody which does get scared from a simple menu where each trained monkey in doubt seletcs the first entry? 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
Le Mer 13 mars 2013 15:26, Máirín Duffy a écrit : Máirín, I would argue that throwing information up in people's faces 100% of the time when it's useless to over 95% of those people is like throwing a text in Japanese at a non-Japanese English speaker in the hopes that somehow they would be able to read it and magically become fluent in Japanese. I'm French. You don't need to preach the evilness of pervasive English intrusion in non-English-speaking countries to me:) Yet I will take some English boot text over no text at all any day. It is definitely evil but in that case it's the lesser one. If you're lamenting the cryptical form of the current strings I totally agree with you but I don't think there is any technical limitation that prevents improving this text instead of dumping the baby with the bath water. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/13/2013 10:43 AM, Nicolas Mailhot wrote: If you're lamenting the cryptical form of the current strings I totally agree with you but I don't think there is any technical limitation that prevents improving this text instead of dumping the baby with the bath water. I'm not. I'm making an analogy. The terminology / jargon on the bootloader page (even the very term, 'bootloader') is about as useful as Japanese to a non-Japanese speaker, so throwing it up in their face 'just in case' isn't really as effective as some are posing it would be. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Tue, Mar 12, 2013 at 11:23 PM, Kevin Kofler kevin.kof...@chello.at wrote: Kevin Fenzi wrote: Why? if we reverted no work would have gone on on the new codebase That's the whole problem. The Anaconda team cannot manage to develop in a branch or trunk which is only put into Rawhide when it's ready. I've been told the new anaconda was actually developed on a branch, but merging it back into mainline/rawhide took about two months because the underlying platform anaconda has started to rely on has changed too much while the branch was being developed. This was actually one of the motivations for this proposal - to allow agreeing on the base design == tier 2 == inter-package interfaces, and enforcing that they are kept working. In the post-revamp model, anaconda has the option of asking to add some of the functionality anaconda relies on in the tier 2 test suite, thus avoiding the breakage or at least detecting it early enough. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Wed, 2013-03-13 at 14:29 +0100, Nils Philippsen wrote: I don't see a glaring error with this idea. What do you think? Well, I talked to a few guys in the office about it and there's one interesting issue with part of my idea: trying to detect multi-boot environments means that the boot loader won't behave in a deterministic fashion, it'll try to adapt to my behavior and always lag behind. So I'd leave this part out and make it like that, i.e. much simpler: - Enable/adapt timeout if an error condition is detected (whether that happens through measuring the time between boots, or something else, or a combination needs to be evaluated). - Measure time for successful reboot as described in my original post to enable/adapt the timeout for long POSTs. Usually the reboot/POST times won't vary that much, so store this time somewhere and use it to make decisions during cold boots. If some hardware is added/removed which influences POST time drastically the first boot will be off w.r.t. timeout -- aw, shucks. People in the know can always configure the boot loader to do nothing fancy but a set, or no timeout, or override booting once through key strokes or whatever. Making this discoverable without cluttering up the boot process is left as an exercise to the reader, but I guess would belong somewhere into System Settings or equivalent, or the Help System should we ever grow one integrated thing instead of a number of competing approaches (man pages, info pages, N different desktop help systems). Oh well. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How does it work: What package can open a file?
On 13/03/13 14:40, Richard Shaw wrote: When you try to open a file for which you have no package installed that handles that file type, there is a GUI that pops up and asks if you want it to search for a package that can handle the file. How exactly does this mechanism work? I'm assuming there is some meta-data in the RPM package that provides this information? I think it happens because the package has a provide of the form: mimehandler(application/csv) Try rpm -q --provides libreoffice-calc for example. In turn rpmbuild creates those automatically from the mime types listed in any desktop files it finds in the package. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Net-Twitter/f19] (2 commits) ...Import 4.00003
Summary of changes: 750fd6a... Updated to Net-Twitter-4.3 (*) aa29c0a... Import 4.3 (*) (*) 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 Wed, 2013-03-13 at 10:48 -0400, Máirín Duffy wrote: On 03/13/2013 10:43 AM, Nicolas Mailhot wrote: If you're lamenting the cryptical form of the current strings I totally agree with you but I don't think there is any technical limitation that prevents improving this text instead of dumping the baby with the bath water. I'm not. I'm making an analogy. The terminology / jargon on the bootloader page (even the very term, 'bootloader') is about as useful as Japanese to a non-Japanese speaker, so throwing it up in their face 'just in case' isn't really as effective as some are posing it would be. I'm with you that users shouldn't see this by default, but rather e.g. upon encountering an error condition (or if configured differently). However, we still could use better wording for such a message, even if we restrict ourselves to English, e.g.: Press keycombo if you want to change how your system starts. That's hardly in the league of Japanese for someone not speaking it. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Le Mer 13 mars 2013 15:48, Máirín Duffy a écrit : On 03/13/2013 10:43 AM, Nicolas Mailhot wrote: If you're lamenting the cryptical form of the current strings I totally agree with you but I don't think there is any technical limitation that prevents improving this text instead of dumping the baby with the bath water. I'm not. I'm making an analogy. The terminology / jargon on the bootloader page (even the very term, 'bootloader') is about as useful as Japanese to a non-Japanese speaker, so throwing it up in their face 'just in case' isn't really as effective as some are posing it would be. I think I'll take that as a yes :) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
On Tue, Mar 12, 2013 at 10:30:01AM -0500, Dennis Gilmore wrote: -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 Having my local mirror wiped when I rsynced todays rawhide tree was unexpected. Having to do a full rsync again is a pain. wtf happened that caused the mirrors to be empty ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/13/2013 10:57 AM, Nils Philippsen wrote: I'm with you that users shouldn't see this by default, but rather e.g. upon encountering an error condition (or if configured differently). However, we still could use better wording for such a message, even if we restrict ourselves to English, e.g.: Press keycombo if you want to change how your system starts. That's hardly in the league of Japanese for someone not speaking it. Why not put it in the control panel on the running system along with other system-level options, though? Doesn't that make more sense rather than separating it out for access only in a completely different context? I mean, I 100% agree if you can't boot, it should pop up automatically. But for cases where you've booted into the machine and just noticed your network doesn't work - we don't automatically notice if the network isn't working and reboot into the boot options screen, and I'm not sure if that would make any sense because there's more reasons the network might not be working besides a new broken kernel update. In that situation my first instinct would be to go into the control panel and poke around and see if there was something I could fix there, and maybe search online for an answer. My first instinct would not be to reboot the system and go into the bootloader menu - it's not intuitive that the problem happened because of a new kernel, and usually when I find myself in that situation it really does take me a while to think it might be a new kernel with a broken driver. I mean, it could be other things too - for example, my network card could be turned off in network manager (has happened before, when i turned off wireless after a plane trip). If I just wanted to explore my options with configuring the computer, I would also go to the control panel first to poke around - again I wouldn't think to reboot the system and poke around with the menus there, I really feel it's not intuitive to configure a particular system before the system is even loaded, if that makes sense? ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Dne 13.3.2013 14:23, Ian Malone napsal(a): Are teens and pre-teens fedora's main target audience now? I'm really not sure what it is anymore. Are you suggesting that we should exclude them? Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/13/2013 09:23 AM, Ian Malone wrote: Then you have good students. Are teens and pre-teens fedora's main target audience now? I'm really not sure what it is anymore. Is there any good reason to exclude them? I started using Linux (Red Hat 5.1) as a 3rd year high school student. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 13 March 2013 15:07, Vít Ondruch vondr...@redhat.com wrote: Dne 13.3.2013 14:23, Ian Malone napsal(a): Are teens and pre-teens fedora's main target audience now? I'm really not sure what it is anymore. Are you suggesting that we should exclude them? Yes okay, that's what I'm suggesting. It's not at all a deliberate misinterpretation. Giving up on this thread altogether now. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] please review: Ticket 600 - Server should return unavailableCriticalExtension when processing a badly formed critical control
https://fedorahosted.org/389/ticket/600 https://fedorahosted.org/389/attachment/ticket/600/0001-Ticket-600-Server-should-return-unavailableCriticalE.patch -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: rawhide report: 20130313 changes
On Wed, Mar 13, 2013 at 08:34:50AM +, Fedora Rawhide Report wrote: Summary: Added Packages: 0 Removed Packages: 13124 Upgraded Packages: 0 Size of added packages: 0 (0 ) Size change of modified packages: 0 (0 ) Size of removed packages: 38512331457 (36 G) Size change: -38512331457 (-36 G) It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away. (Antoine de Saint Exupéry's) -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Tue, 2013-03-12 at 23:52 +0100, Nicolas Mailhot wrote: Le Mar 12 mars 2013 19:04, Peter Jones a écrit : Obviously we need to do a good job of making sure we tolerate failures, and there are multiple ways to do this - if you reboot N times within M seconds or somesuch might be a worthwhile heuristic. By definition an heuristic is unreliable. The current mechanism, while not-pretty, is reliable. Reliability is the major property you want in any rescue system. (that's why safety jackets use flashy unfashionable colors) Just for the record, (non/less) deterministic != (un)reliable. Take the following numbers with a grain of salt because I obviously pulled them out of a hat: If we have error detection that only catches say 95% of error conditions, why shouldn't we use it to make these cases bearable (for power users anyway), additionally to say 80% of normal boots awesome for everyone at the cost of making the remaining 1% a little less easy -- e.g. having to push a keycombo which you have to know at that point. Making this knowledge discoverable is something else and IMO has no place in the boot process (because it just confuses, annoys in 99% of cases). People who want to be power users will find this out, even if we fail to make that information easily discoverable. People who don't have these ambitions won't magically want to turn into power users because we advertise here's where power users turn right during every boot. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130313 changes
On Wed, 13 Mar 2013 16:18:34 +0100 Karel Zak k...@redhat.com wrote: On Wed, Mar 13, 2013 at 08:34:50AM +, Fedora Rawhide Report wrote: Summary: Added Packages: 0 Removed Packages: 13124 Upgraded Packages: 0 Size of added packages: 0 (0 ) Size change of modified packages: 0 (0 ) Size of removed packages: 38512331457 (36 G) Size change: -38512331457 (-36 G) It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away. (Antoine de Saint Exupéry's) On the plus side... the boot improvement thread can reach it's conclusion: Since we have no packages and no files, the boot process can be simply Bootable disk not found In all seriousness, this is being fixed and rawhide compose being re-run. :) 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
From: Máirín Duffy du...@fedoraproject.org Why not put it in the control panel on the running system along with other system-level options, though? Doesn't that make more sense rather than separating it out for access only in a completely different context? Because maybe your computer boots just fine but you're screens are all garbled or just black. Been there, done that. Yes, I could blame Nvidia for not giving me a FOSS driver, but: my work computer came with their hardware, I have a 4-headed display and I've never been able to get any FOSS config to support this as much as I would much prefer that. Personally, I would never think to go into a control panel, but that's just because I've got a gray beard and do things the hard way because that used to be the only way. I'm not suggesting that new ways aren't possible or preferable, but we should preserve traditional methods if there's no or little harm in doing so. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM weekly status meeting 2013-03-13
Good day all, Please join us today (Wednesday, March 13th) at 4PM EDT (8PM UTC) for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode. On the agenda so far.. 0) Status of ACTION items from our previous meeting 1) Problem packages 2) Aarch64 patching 3) Creating test candidate images for F19 4) Release Criteria - changes required for ARM 5) Open Floor If there is something that you would like to discuss that isn't mentioned please feel free to bring it up at the end of the meeting or send an email to the list. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
I know it is a simplification, but to me, the two sides of this argument are: * remove the hood of the car, and keep it off in case something goes wrong, or to entice new drivers to look in there and guess what is going on. * keep the hood of the car on, and if something goes wrong, pop it. If the driver wants to tweak, or have a look around let them pull the lever and pop the hood. --ryanlerch I was pretty much unable to do anything when my hood release froze this winter. The only way to get under the hood and fix a problem with starting the car was to wait for warmer weather. Just a thought. Sebastian Mäki -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/13/2013 02:23 PM, Ian Malone wrote: On 13 March 2013 12:46, Máirín Duffy du...@fedoraproject.org wrote: On 03/13/2013 12:26 AM, Ralf Corsepius wrote: - (Nobody explicitly stated this, but) Displaying information geared towards power users by default is intimidating / confusing to less-knowledgeable users. I'd call this to be an urban legend. A boot menu is self-explanatory, even to new-comers. It may baffle them when they see it for the first time, but will very soon get used to it. No, a boot menu is not self-explanatory, and no, this is not an 'urban legend.' How do you even come up with associating the term 'urban legend' to statement saying that a complex screen is confusing to casual computer users? 20 years+ of experience with Linux and more with other OSes :-) I have taught multiple classes of teenage and pre-teen students using Fedora Live USB keys. This necessarily involves having to guide them through using syslinux (which is very similar in appearance to grub) to boot their system, I can say from actual experience that: 1) The boot menu was not self-explanatory, and the students had a lot of questions about what stuff on the screen meant. And how did it impact their usage experience? I guess, their reaction was a Wazat?, temporary raising the eyebrow, but then they simply went on. Actually, I would expect your students to have more issues with understanding keyboard layout selection, timezones selection, explaining hw-clock, the concepts behind updates/rpm-conflicts and so on and would consider the bootloader prompt to have been one (ignorable) detail amongst many other much huger problem. One experiment I did: I sat some relatives and friends (no computer iliterates) in front of Gnome3 and asked them to work with it. All of threw it away in disgust. Then you have good students. I am having doubts any pre-teen and only some teens are able to run/configure any OS and them to be overwhelmed all over the place without supervison/prior instructions. Once they have been instructed, they likely are able work with it. Are teens and pre-teens fedora's main target audience now? I hope not ... I am not interested in converting Fedora or Linux into a toy. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
Once upon a time, Dave Jones da...@redhat.com said: Having my local mirror wiped when I rsynced todays rawhide tree was unexpected. Having to do a full rsync again is a pain. wtf happened that caused the mirrors to be empty ? Ouch. I see that too. IIRC this happened before (maybe last branch?). There should be some safety check that no more than X% of files get removed in a push (where X is probably small). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
From: Chris Adams cmad...@hiwaay.net To: devel@lists.fedoraproject.org Date: 03/13/2013 11:35 Subject: Re: f19 mass branching Sent by: devel-boun...@lists.fedoraproject.org Once upon a time, Dave Jones da...@redhat.com said: Having my local mirror wiped when I rsynced todays rawhide tree was unexpected. Having to do a full rsync again is a pain. wtf happened that caused the mirrors to be empty ? Ouch. I see that too. Likewise here. There should be some safety check that no more than X% of files get removed in a push (where X is probably small). Long ago I used a perl script (IIRC) called 'mirror' that had just such a safety feature and X was specifiable. I sure wish rsync had this. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Le Mer 13 mars 2013 15:16, Nicolas Mailhot a écrit : Anyway, here is a proposal for an alternative way to deal with the boot sequence. (btw, in case it is not obvious, the solution described here is a form of dead-man switch, which is a proven method to handle operator failures. In the case of a computer, the operator is the system. http://en.wikipedia.org/wiki/Dead_man%27s_switch The basic principle behind a dead-man switch is that you go in safe mode unless you can prove the operator is alive, instead of using error detection to trigger safe mode. The first model is a lot more reliable than the second.) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 13 March 2013 12:46, Máirín Duffy du...@fedoraproject.org wrote: No, a boot menu is not self-explanatory, and no, this is not an 'urban legend.' How do you even come up with associating the term 'urban legend' to statement saying that a complex screen is confusing to casual computer users? On 03/13/2013 11:30 AM, Ralf Corsepius wrote: 20 years+ of experience with Linux and more with other OSes :-) Ah, okay, so you *are* completely ill-equipped to understand a casual user's experience then? And how did it impact their usage experience? I guess, their reaction was a Wazat?, temporary raising the eyebrow, but then they simply went on. Actually, in some students cases, their reaction was to simply plug out their live USB stick, boot into windows, and try to create their project on there. Not exactly the kind of reaction we'd like to see, is it? Actually, I would expect your students to have more issues with understanding keyboard layout selection, timezones selection, explaining hw-clock, the concepts behind updates/rpm-conflicts and so on and would consider the bootloader prompt to have been one (ignorable) detail amongst many other much huger problem. Nope, the live media were pre-configured for their keyboard layouts and timezone, and all of the software they needed was pre-installed. They did have issues getting Flash to work, but that's not really something we can do much about. One experiment I did: I sat some relatives and friends (no computer iliterates) in front of Gnome3 and asked them to work with it. All of threw it away in disgust. Cool! I am having doubts any pre-teen and only some teens are able to run/configure any OS and them to be overwhelmed all over the place without supervison/prior instructions. Once they have been instructed, they likely are able work with it. Yeah, unfortunately this was an Inkscape and Gimp class, not an Operating Systems 101 class. We didn't cover the bootloader, the init system, the terminal, or anything like that. Are teens and pre-teens fedora's main target audience now? I hope not ... I am not interested in converting Fedora or Linux into a toy. How many teens and pre-teens do you know who actually play with toys rather than computers, tablets, and smartphones? Seriously? Do you know any teens or pre-teens? ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Wed, 2013-03-13 at 11:04 -0400, Máirín Duffy wrote: In that situation my first instinct would be to go into the control panel and poke around and see if there was something I could fix there, and maybe search online for an answer. My first instinct would not be to reboot the system and go into the bootloader menu - it's not intuitive that the problem happened because of a new kernel, and usually when I find myself in that situation it really does take me a while to think it might be a new kernel with a broken driver. This brings the question, how do you do your update? I know I'm not he average user but I update via yum and one thing I always watch out for are kernel update, mostly because it means I'll have to reboot my machine sometime after that. So when I reboot and something does not come up, I will likely pretty quickly reboot on an older kernel to see if that's what has changed (I must confess, this is a guess since I don't remember when is the last time something broke on one of my machine with a kernel update). Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
On Wed, 13 Mar 2013 10:35:00 -0500 Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Dave Jones da...@redhat.com said: Having my local mirror wiped when I rsynced todays rawhide tree was unexpected. Having to do a full rsync again is a pain. wtf happened that caused the mirrors to be empty ? Ouch. I see that too. IIRC this happened before (maybe last branch?). There should be some safety check that no more than X% of files get removed in a push (where X is probably small). It's being fixed up now. Sorry for the trouble... http://git.fedorahosted.org/cgit/releng/tree/scripts/buildrawhide is the script that makes rawhide. Patches welcome. 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 2013-03-13 17:29 (GMT+0200) Sebastian Mäki composed: * remove the hood of the car, and keep it off in case something goes wrong, or to entice new drivers to look in there and guess what is going on. * keep the hood of the car on, and if something goes wrong, pop it. If the driver wants to tweak, or have a look around let them pull the lever and pop the hood. I was pretty much unable to do anything when my hood release froze this winter. The only way to get under the hood and fix a problem with starting the car was to wait for warmer weather. No amount of waiting within my expected lifetime would have helped me. The battery died, and the hood cable broke at the latch. No amount of sheet metal disassembly was possible with the hood latched, even after removing the grill. I had to go find a similar car to study its latch mechanism, then squeeze in between the puddle and the bottom of the car and reach up with a big screwdriver to fram on the latch mechanism until I got lucky and hit the right spot to make it release. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
From: Máirín Duffy du...@fedoraproject.org Why not put it in the control panel on the running system along with other system-level options, though? Doesn't that make more sense rather than separating it out for access only in a completely different context? On 03/13/2013 11:26 AM, john.flor...@dart.biz wrote: Because maybe your computer boots just fine but you're screens are all garbled or just black. This is a really good point. In this situation I probably would have just gone to a tty and edited the grub conf file to default to an older kernel if that happened, rather than play whack-a-mole with the grub timeout. Just trying to point out that you can solve this issue without entering grub at boot-time. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Wed, 2013-03-13 at 11:04 -0400, Máirín Duffy wrote: On 03/13/2013 10:57 AM, Nils Philippsen wrote: I'm with you that users shouldn't see this by default, but rather e.g. upon encountering an error condition (or if configured differently). However, we still could use better wording for such a message, even if we restrict ourselves to English, e.g.: Press keycombo if you want to change how your system starts. That's hardly in the league of Japanese for someone not speaking it. Why not put it in the control panel on the running system along with other system-level options, though? Doesn't that make more sense rather than separating it out for access only in a completely different context? I mean, I 100% agree if you can't boot, it should pop up automatically. But for cases where you've booted into the machine and just noticed your network doesn't work - we don't automatically notice if the network isn't working and reboot into the boot options screen, and I'm not sure if that would make any sense because there's more reasons the network might not be working besides a new broken kernel update. Right, sorry I got distracted by the wording thing which is mostly a side-show anyway. In that situation my first instinct would be to go into the control panel and poke around and see if there was something I could fix there, and maybe search online for an answer. My first instinct would not be to reboot the system and go into the bootloader menu - it's not intuitive that the problem happened because of a new kernel, and usually when I find myself in that situation it really does take me a while to think it might be a new kernel with a broken driver. I mean, it could be other things too - for example, my network card could be turned off in network manager (has happened before, when i turned off wireless after a plane trip). If I just wanted to explore my options with configuring the computer, I would also go to the control panel first to poke around - again I wouldn't think to reboot the system and poke around with the menus there, I really feel it's not intuitive to configure a particular system before the system is even loaded, if that makes sense? I'm not 100% sure about the ideal way of booting, considering all the conflicting requirements (easy, pretty, fast, reliable, deterministic, ...). In contrast however, I feel very confident that right now discovering what options are available should you need them is lacking. Using general purpose search engines to find out such information -- before or after disaster strikes -- isn't something I'd like as the only way to find this out. Too often you find pages that deal with something similar, but not quite what you're looking for. Then you find forum threads were a number of people with dangerous half-knowledge discuss about the best way to fix sound/SELinux/... which is switching it (be that pulseaudio, or SELinux, ...) off since that's what worked in 2004. Neither is pointing people to #fedora/freenode I'm afraid. Nor is advertising the boot menu during boot for that matter -- can anyone say Clippy? I imagine that some kind of well discoverable (e.g. advertised during installation, or in the default browser homepage) knowledge-base beyond installation guides, release notes e.a. could get us a far way, which would have vetted information about troubleshooting (So you updated and sound/wireless/suspend broke? Here's what you should check and how: ...) and power-user-ing (So we welded the hood in Fedora a little too shut for your taste? While we're busy munching self-baked cookies by the thankful Aunt Tilly, here's how you gnaw the hood open again: ...). That this needs a little cooperation on the OS components side is obvious, workarounds for power users either need to stay stable, be replaced by something more or less equivalent (with updated documentation), or rendered obsolete. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/13/2013 11:51 AM, Felix Miata wrote: On 2013-03-13 17:29 (GMT+0200) Sebastian Mäki composed: * remove the hood of the car, and keep it off in case something goes wrong, or to entice new drivers to look in there and guess what is going on. * keep the hood of the car on, and if something goes wrong, pop it. If the driver wants to tweak, or have a look around let them pull the lever and pop the hood. I was pretty much unable to do anything when my hood release froze this winter. The only way to get under the hood and fix a problem with starting the car was to wait for warmer weather. No amount of waiting within my expected lifetime would have helped me. The battery died, and the hood cable broke at the latch. No amount of sheet metal disassembly was possible with the hood latched, even after removing the grill. I had to go find a similar car to study its latch mechanism, then squeeze in between the puddle and the bottom of the car and reach up with a big screwdriver to fram on the latch mechanism until I got lucky and hit the right spot to make it release. My kind of engineer!! We fix anything!! -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 03/13/2013 11:46 AM, Pierre-Yves Chibon wrote: This brings the question, how do you do your update? I actually do updates via the package kit nag thing that pops up from the messaging tray, and I rarely pay attention to the list of packages. I just don't have the time to bother, and if that's the default experience (and it is at least for GNOME desktop users) I want to experience it so I understand it, if that makes sense. I know I'm not he average user but I update via yum and one thing I always watch out for are kernel update, mostly because it means I'll have to reboot my machine sometime after that. So when I reboot and something does not come up, I will likely pretty quickly reboot on an older kernel to see if that's what has changed (I must confess, this is a guess since I don't remember when is the last time something broke on one of my machine with a kernel update). I'm not a great troubleshooter, unfortunately! I'm trying to use Fedora to design stuff, not to play around with the OS. :) It's been a really long time since a kernel update broke something on my system as well. I think the last time might have been around F14, there had been a kernel update that broke suspend on my Thinkpad x61. A fix came out shortly after. Anyway, the infrequency of the kernel breaking me (and maybe we are both really lucky for this) is probably another reason why I think 'check network manager' before I think 'try another kernel' for this example situation. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Tue, 12 Mar 2013 23:23:35 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Kevin Fenzi wrote: Why? if we reverted no work would have gone on on the new codebase That's the whole problem. The Anaconda team cannot manage to develop in a branch or trunk which is only put into Rawhide when it's ready. Well, sure they can. But they don't have sufficient resources to do that and _ALSO_ maintain the old code base. Somehow all other upstreams manage, even where they happen to be Red Hat and/or Fedora developers. An installer isn't like those things. So, to recap: 1) You can have old anaconda for f19, at the cost of no one being able to work on the new one. Leading to f20 having the exact same issue. or 2) You can take the longer release time, get the new codebase in and done and then you are in much better shape moving forward. We choose 2. (Anaconda folks, feel free to drop in and correct me if I got anything wrong). I can't see much way to explain it in more detail, so I think I will leave it at that. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
Good day.
By request https://bugzilla.redhat.com/show_bug.cgi?id=849065 I plan
split off ImageMagick-libs sub-package and update ImageMagick to last
6.8.3-9 version.
There many changes including so-name bump and version scheme change from
upstream:
libMagickCore.so.5 became libMagickCore-6.Q16.so
I plan push it in rawhide 14-17 March if no one will argue.
Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5117303
Also changed some directories. Major differences in layout:
%files
- %defattr(-,root,root,-)
- %doc QuickStart.txt ChangeLog Platforms.txt
- %doc README.txt LICENSE NOTICE AUTHORS.txt NEWS.txt
- %{_libdir}/libMagickCore.so.5*
- %{_libdir}/libMagickWand.so.5*
+ %doc README.txt LICENSE NOTICE AUTHORS.txt NEWS.txt ChangeLog
Platforms.txt
%{_bindir}/[a-z]*
- %{_libdir}/%{name}-%{VER}
- %{_datadir}/%{name}-%{VER}
%{_mandir}/man[145]/[a-z]*
%{_mandir}/man1/%{name}.*
+
+ %files libs
+ %defattr(-,root,root,-)
+ %doc LICENSE NOTICE AUTHORS.txt QuickStart.txt
-%{_libdir}/libMagickCore.so.6*
-%{_libdir}/libMagickWand.so.6*
++%{_libdir}/libMagickCore-6.Q16.so.*
++%{_libdir}/libMagickWand-6.Q16.so.*
+ %{_libdir}/%{name}-%{VER}
-%{_datadir}/%{name}-%{VER}
++%{_datadir}/%{name}-6
%exclude %{_libdir}/%{name}-%{VER}/modules-Q16/coders/djvu.*
--%{_sysconfdir}/%{name}
++%{_sysconfdir}/%{name}-6
%files devel
%defattr(-,root,root,-)
@@@ -254,15 -267,15 +269,19 @@@
%{_bindir}/Magick-config
%{_bindir}/MagickWand-config
%{_bindir}/Wand-config
--%{_libdir}/libMagickCore.so
--%{_libdir}/libMagickWand.so
++%{_libdir}/libMagickCore-6.Q16.so
++%{_libdir}/libMagickWand-6.Q16.so
%{_libdir}/pkgconfig/MagickCore.pc
++%{_libdir}/pkgconfig/MagickCore-6.Q16.pc
%{_libdir}/pkgconfig/ImageMagick.pc
++%{_libdir}/pkgconfig/ImageMagick-6.Q16.pc
%{_libdir}/pkgconfig/MagickWand.pc
++%{_libdir}/pkgconfig/MagickWand-6.Q16.pc
%{_libdir}/pkgconfig/Wand.pc
--%dir %{_includedir}/%{name}
--%{_includedir}/%{name}/magick
--%{_includedir}/%{name}/wand
++%{_libdir}/pkgconfig/Wand-6.Q16.pc
++%dir %{_includedir}/%{name}-6
++%{_includedir}/%{name}-6/magick
++%{_includedir}/%{name}-6/wand
%{_mandir}/man1/Magick-config.*
%{_mandir}/man1/MagickCore-config.*
%{_mandir}/man1/Wand-config.*
@@@ -274,6 -287,6 +293,7 @@@
%files doc
%defattr(-,root,root,-)
++%doc %{_datadir}/doc/%{name}-6
%doc %{_datadir}/doc/%{name}-%{VER}
%doc LICENSE
@@@ -281,17 -294,17 +301,19 @@@
%defattr(-,root,root,-)
%doc Magick++/AUTHORS Magick++/ChangeLog Magick++/NEWS Magick++/README
%doc www/Magick++/COPYING
- %{_libdir}/libMagick++.so.5*
-%{_libdir}/libMagick++.so.6*
++%{_libdir}/libMagick++-6.Q16.so.*
%files c++-devel
%defattr(-,root,root,-)
%doc Magick++/examples
%{_bindir}/Magick++-config
--%{_includedir}/%{name}/Magick++
--%{_includedir}/%{name}/Magick++.h
--%{_libdir}/libMagick++.so
++%{_includedir}/%{name}-6/Magick++
++%{_includedir}/%{name}-6/Magick++.h
++%{_libdir}/libMagick++-6.Q16.so
%{_libdir}/pkgconfig/Magick++.pc
++%{_libdir}/pkgconfig/Magick++-6.Q16.pc
%{_libdir}/pkgconfig/ImageMagick++.pc
++%{_libdir}/pkgconfig/ImageMagick++-6.Q16.pc
%{_mandir}/man1/Magick++-config.*
Dependency rebuild required.
List of dependent packages are (maintainers in bcc):
$ repoquery --whatrequires 'libMagickCore.so.*' 'libMagickWand.so.*'
'libMagick++.so.*' --enablerepo=rawhide --source --qf '%{name}' | sed
's!-[^-]\+-[^-]\+\.src\.rpm$!!g' | grep -v ImageMagick | sort -u
ale
autotrace
calibre
converseen
cuneiform
digikam
dmapd
drawtiming
dx
emacs
gdl
imageinfo
inkscape
k3d
kxstitch
libdmtx
nip2
oxine
pfstools
php-magickwand
php-pecl-imagick
psiconv
q
rss-glx
ruby-RMagick
spectrum
techne
transcode
vips
xastir
xine-lib
zbar
--
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me use jabber: hubbi...@jabber.ru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
On Wed, Mar 13, 2013 at 4:03 PM, Pavel Alexeev fo...@hubbitus.com.ru wrote: Good day. By request https://bugzilla.redhat.com/show_bug.cgi?id=849065 I plan split off ImageMagick-libs sub-package and update ImageMagick to last 6.8.3-9 version. There many changes including so-name bump and version scheme change from upstream: libMagickCore.so.5 became libMagickCore-6.Q16.so I plan push it in rawhide 14-17 March if no one will argue. By rawhide you mean F-20 rawhide right? Or do you plan to land this in F-19 too? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Le Mer 13 mars 2013 16:52, Máirín Duffy a écrit : From: Máirín Duffy du...@fedoraproject.org Why not put it in the control panel on the running system along with other system-level options, though? Doesn't that make more sense rather than separating it out for access only in a completely different context? On 03/13/2013 11:26 AM, john.flor...@dart.biz wrote: Because maybe your computer boots just fine but you're screens are all garbled or just black. This is a really good point. In this situation I probably would have just gone to a tty and edited the grub conf file to default to an older kernel if that happened, rather than play whack-a-mole with the grub timeout. Just trying to point out that you can solve this issue without entering grub at boot-time. Máirín, When the gfx driver puts the gpu in such a state, tty is often garbled too. It uses the same hardware. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
Le 13/03/2013 17:03, Pavel Alexeev a écrit : I plan push it in rawhide 14-17 March if no one will argue. Sounds good. Dependency rebuild required. php-magickwand php-pecl-imagick This 2 packages requires some patches to build with latest ImageMagick. I already have them ready. So ping me as soon as available in rawhide, I will take care of updating those ones. Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
Le Mer 13 mars 2013 17:00, Máirín Duffy a écrit : It's been a really long time since a kernel update broke something on my system as well. I think the last time might have been around F14, there had been a kernel update that broke suspend on my Thinkpad x61. A fix came out shortly after. Anyway, the infrequency of the kernel breaking me (and maybe we are both really lucky for this) This is no luck, you are using the exact class of hardware @rh dev use, which is pretty much the safest setup for Fedora (and it's not the least expensive hardware on the market either). -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick update in rawhide to 6.8.3-9 version, so-name change, split libs sub package
Le 13/03/2013 17:16, Remi Collet a écrit : php-pecl-imagick As you're the owner of this one, if you prefer to update it, see http://svn.php.net/viewvc?view=revisionrevision=329769 Remi. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On 03/13/2013 12:02 PM, Kevin Fenzi wrote: snip 2) You can take the longer release time, get the new codebase in and done and then you are in much better shape moving forward. We choose 2. (Anaconda folks, feel free to drop in and correct me if I got anything wrong). I can't see much way to explain it in more detail, so I think I will leave it at that. kevin Finally, a reasonable development approach. Please do get the installer in maintainable shape and consistent from release to release. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Wed 13 Mar 2013 12:19:39 PM EDT, Nicolas Mailhot wrote: This is no luck, you are using the exact class of hardware @rh dev use, which is pretty much the safest setup for Fedora (and it's not the least expensive hardware on the market either). This is my last message to this thread. I am not using the same exact class of hardware that Red Hat developers use. Since 2008 or so I've been using convertible wacom tablet / laptops made by Lenovo - my first was the x61T, now I'm using an x220T. And the x220T, while it works great, spews out a lot of annoying acpi errors whenever I suspend / unsuspend / boot that I'd really not like to see and I'm sure I wouldn't see if more developers were using the same model. The developers I sit with do not all use Thinkpads. Many have Dell or HP laptops or desktop boxes. The hardware isn't as homogeneous as it was back in 2004-2005, the standard issue IBM Thinkpad days. ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Knowledge Base / Help Center Idea
On 03/13/2013 11:53 AM, Nils Philippsen wrote: I imagine that some kind of well discoverable (e.g. advertised during installation, or in the default browser homepage) knowledge-base beyond installation guides, release notes e.a. could get us a far way, which would have vetted information about troubleshooting (So you updated and sound/wireless/suspend broke? Here's what you should check and how: ...) and power-user-ing (So we welded the hood in Fedora a little too shut for your taste? While we're busy munching self-baked cookies by the thankful Aunt Tilly, here's how you gnaw the hood open again: ...). That this needs a little cooperation on the OS components side is obvious, workarounds for power users either need to stay stable, be replaced by something more or less equivalent (with updated documentation), or rendered obsolete. I think this is a fantastic idea. Actually Ryan did a set of conceptual mockups for such a thing. We need some help developing the design omre and also someone to build it, though. We could advertise it during the ransom notes in anaconda if need be. The idea here is that it would be a desktop app that would aggregate information from ask.fedoraproject.org (as a kbase backend) as well as the Fedora docs, so you could search all places at once. If you were in a rough state and couldn't access the network or use the desktop, you could access those same resources directly on line and get the answers. We'd have to populate ask.fedoraproject.org with some good question/answer articles though for this to work well, but it's pretty easy to do given the content. https://fedoraproject.org/wiki/Design/Help_Center_Idea ~m -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
On Wed, Mar 13, 2013 at 09:51:01AM -0600, Kevin Fenzi wrote:
On Wed, 13 Mar 2013 10:35:00 -0500
Chris Adams cmad...@hiwaay.net wrote:
Once upon a time, Dave Jones da...@redhat.com said:
Having my local mirror wiped when I rsynced todays rawhide tree was
unexpected. Having to do a full rsync again is a pain.
wtf happened that caused the mirrors to be empty ?
Ouch. I see that too. IIRC this happened before (maybe last
branch?). There should be some safety check that no more than X% of
files get removed in a push (where X is probably small).
It's being fixed up now.
Sorry for the trouble...
http://git.fedorahosted.org/cgit/releng/tree/scripts/buildrawhide
is the script that makes rawhide. Patches welcome.
Something like this (obv. untested) might at least stop wiping the whole tree
when something gets screwed up.
I guessed at the logging part, I don't know if 'failed' is valid there.
Dave
--- 1/buildrawhide~ 2013-03-13 12:28:34.613042461 -0400
+++ 2/buildrawhide 2013-03-13 12:34:03.488671561 -0400
@@ -111,7 +111,7 @@ mock -r $MOCKCONFIG --uniqueext=$DATE --
rm /mnt/koji/mash/rawhide
ln -s /mnt/koji/mash/rawhide-$DATE/rawhide$EXPANDARCH/ /mnt/koji/mash/rawhide
-echo Compose finisheded at `date --utc`
/mnt/koji/mash/rawhide-$DATE/logs/finish
+echo Compose finished at `date --utc`
/mnt/koji/mash/rawhide-$DATE/logs/finish
echo /mnt/koji/mash/rawhide-$DATE/logs/finish
# Emit a message using bodhi's cert (since we should be running as masher).
@@ -122,6 +122,19 @@ echo {\log\: \start\, \branch\: \
--json-input
cd /tmp
+
+# Check that we actually have RPMs to write out.
+COUNT=$(find . -name *.rpm | wc -l)
+if [ $COUNT-eq 0 ] ; then
+ echo No rpms generated. Something went horribly wrong\n
/mnt/koji/mash/rawhide-$DATE/logs/finish
+ echo {\log\: \failed\, \branch\: \rawhide\, \arch\: \$ARCH\} |
fedmsg-logger \
+--cert-prefix bodhi \
+--modname compose \
+--topic rawhide.rsync.complete \
+--json-input
+ exit
+fi
+
# data
$RSYNCPREFIX /usr/bin/rsync $RSYNC_OPTS --exclude repodata/
/mnt/koji/mash/rawhide-$DATE/rawhide$EXPANDARCH/ $DESTPATH
# repodata cleanup
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Knowledge Base / Help Center Idea
On 03/13/2013 12:31 PM, Máirín Duffy wrote: The idea here is that it would be a desktop app that would aggregate information from ask.fedoraproject.org (as a kbase backend) as well as the Fedora docs, so you could search all places at once. If an API is needed for this functionality, it would be useful to know ahead of time https://ask.fedoraproject.org/question/23872/which-features-do-you-want-in-ask-fedora/ Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On 13 Mar 2013, at 10:16, Nicolas Mailhot wrote: Anyway, here is a proposal for an alternative way to deal with the boot sequence. There have been a number of suggestions that have taken a Windows 8 approach to this problem -- auto-detecting error conditions or enabling one to reboot into a boot menu. I can't say that I'm confident of the error detection, or that I'm happy about having to boot once into the wrong system just so I can reboot into a boot menu that will enable me to boot into the right system. That doesn't seem particularly efficient or user- friendly. Let me make a case for an Apple approach. Although the reaction here was somewhat dismissive of the various start-up keys that Apple enables, the Apple approach does have three great advantages: 1. In the most frequent case, there is no interruption of the boot sequence for the default system. 2. If one wants to invoke one of the Apple start-up options, the normal practice is to hold down the appropriate key, then power on the Mac, and continue holding down the key until one hears the start- up chime and sees that the system is booting. There is no short time interval that one has to hit just right. Like big icons on the edge of the screen, holding down a key from power on provides the fattest target for a user to hit -- sort of Fitts law in a temporal dimension. 3. The key combinations are well-known. Decades of using the same key combinations have ingrained them in Mac culture. A new Mac user might not know the right key combination, but any mailing list or forum will have dozens of Mac users who can quickly recite the key combinations for starting from a CD or DVD, clearing the PRAM (a long- time voodoo practice among some Mac users), starting target disk mode, etc. In the case of Fedora: + If a key were selected -- and I don't think you have to enable all of them -- and advertised in all of the user mailing lists, fora, Quick Start documentation, Installation Guide, User Guide, etc., then within a year or so just about every Fedoran would know and could quickly recite to newbies hold down the F (as in Fedora) key to get to advanced boot options. + If a user could hold the key down from before power on until the boot options menu appeared, then Fedora could still do extremely fast booting without presenting the user with a short time interval to hit. If grub finds the keyboard, and detects no F key hold down, it would continue to boot immediately with no further delay. I recall there was some objection about BIOS buffer clearing, and don't know what problems that would present to this proposal. On the plus side, though, there wouldn't be any need for gnarly auto- detection of error conditions. By the way, in this brave new fast boot world, how is one expected to get to the BIOS or firmware set-up programs? -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On 03/13/2013 09:27 AM, Norvald H. Ryeng wrote: 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. I don't think conflict is actually the main problem -- the inability of RPM to un-ambigously choose one of the two packages that provide the same symbol *is* the real problem. If we solved that one, MySQL-server could provide right symbol and KDE system would be happy. I fully agree that enforcing the default is the main problem. It makes the whole ting very difficult. Package conflict is a problem as soon as packages start depending on one particular server or tools implementation (e.g., akonadi-mysql). If both have the same virtual provide and all packages depend on that instead of a specific implementation, they can be conflicting. Yeah, but on the other hand, as soon as there are still packages that doesn't depend on a specific one (use just mysql or mysql-server) -- we need to keep the API the same -- by API I mean name of the systemd unit file, utilities names, ... Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Wed, 13 Mar 2013 12:52:24 -0400 Mike Pinkerton pseli...@mindspring.com wrote: + If a user could hold the key down from before power on until the boot options menu appeared, then Fedora could still do extremely fast booting without presenting the user with a short time interval to hit. If grub finds the keyboard, and detects no F key hold down, it would continue to boot immediately with no further delay. There are at least two problems with that: * Holding key over remote VNC console can be problematic, especially if the server POSTs slowly. * Holding key on BIOS machines usually results in a long beep sound and keyboard lockup. I never understood why. And again, I would like to add that servers tend to change video mode during POST, sometimes even several times. On some chassis this results to losing video output for several (think 2) seconds. That means that even showing a brief [press F for options] sucks. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On 03/13/2013 09:27 AM, Norvald H. Ryeng wrote: On Tue, 12 Mar 2013 18:25:02 +0100, Honza Horak hho...@redhat.com wrote: On 03/12/2013 01:14 PM, Norvald H. Ryeng wrote: 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. I don't think conflict is actually the main problem -- the inability of RPM to un-ambigously choose one of the two packages that provide the same symbol *is* the real problem. If we solved that one, MySQL-server could provide right symbol and KDE system would be happy. I fully agree that enforcing the default is the main problem. It makes the whole ting very difficult. I've spent some time deep in yum and it seems to be better than I thought now. First, the magic about choosing one provider from more alternatives is not so dark any more (it was worse few years before) -- it's actually documented at [1] now. However, in scenarios I tested with packages similar to mysql/MySQL/mariadb it turned out, that we never reach the point where we have to choose one of more alternate providers. The reason is that yum chooses right package before going down to [1] (I tracked the code and it never came to the part _compare_providers). I've tested that on sample packages in one repo, that basically looked like this: mysql-5.5.30 #last version of the package and also package currently installed mariadb-5.5.29: Provides: mysql = 5.5.29 Obsoletes: mysql 5.6 MySQL-5.6.10: Provides: mysql = 5.6.10 # doesn't obsolete mysql The following table shows what actions (cols) yum chose in different scenarios -- i.e packages installed (rows): installed | # yum install mysql | # yum update | # yum shell (*) | -- --- | mariadb (**)| --- | MySQL | mysql | mariadb | mariadb | MySQL | MySQL | mariadb | MySQL| MySQL | mariadb | --- | mariadb | MySQL | (*) yum shell is needed in order to install MySQL while removing current implementation if any (mysql or mariadb) in one transaction. (**) The reason why mariadb is chosen is most probably this notice printed by yum: Package mysql is obsoleted by mariadb, trying to install mariadb-5.5.29-2.fc18.x86_64 instead This means it works as we'd wish even if we let MySQL packages to provide mysql symbols. I'll test the real packages after weekend, since I'm going to be off until Sunday. So, to sum up the above, I've started to believe that we will be able to add Provides: mysql also to MySQL packages, while mariadb would be correctly preferred by default. [1] http://yum.baseurl.org/wiki/CompareProviders Regards, Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
