Re: Abotu setting 'PermitRootLogin=no' in sshd_config
On Sun, Nov 23, 2014 at 7:44 PM, Dennis Gilmore wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Fri, 21 Nov 2014 07:11:27 + (UTC) > P J P wrote: > >> Hello, >> >> Sshd(8) daemon by default allows remote users to login as root. >> >> 1. Is that really necessary? >> 2. Lot of users use their systems as root, without even creating a >> non-root user. Such practices need to be discouraged, not allowing >> remote root login could be useful in that. >> >> Does it make sense to disable remote root login by default? If so, do >> we need to just report it to the maintainer or it would be treated as >> a feature? > > I think its a bad idea, but I say so as a user that when installing a > new system, especially a remove vm will log in as root via ssh and > join the machine post install to my ipa domain. > > Dennis This is an old, old, subject and debate in the SSH community. Every time people try to change defaults, it can and *wll* break existing practices, even if the defaults are a security problem and should have been changed a decade ago. Personally? I'd *love* to see the default allow root direct login directly only from ""localhost". That means a 'Match Host' change to re-enable PermitRootLogin only if the connection is from localhost, which is a bit more sophisticated than just turning PermitRootlLogin on or off. Plus, I don't know if you've looked lately, but some people *really* screw up "localhost" settings in /etc/hosts as they try to get clever with shoving the FQDN into the loopback IP addresses, and hilarity ensues. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] 2014-11-24 @16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2014-11-24 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again tomorrow! We haven't met for a while, so let's sync up on Fedora 21 status and anything else we need to discuss. Remember, we're at 1600 UTC now (everywhere that does daylight savings should be on winter time already). As always, please reply to this mail if you'd like to propose any additional topics! == Proposed Agenda Topics == 1. Fedora 21 Final status * TC3 quality? * Blocker verification? * TC4/RC1 planning? * Criteria status and test case criteria coverage? 2. Test Days * Any more? 3. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Abotu setting 'PermitRootLogin=no' in sshd_config
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 21 Nov 2014 07:11:27 + (UTC) P J P wrote: > Hello, > > Sshd(8) daemon by default allows remote users to login as root. > > 1. Is that really necessary? > 2. Lot of users use their systems as root, without even creating a > non-root user. Such practices need to be discouraged, not allowing > remote root login could be useful in that. > > Does it make sense to disable remote root login by default? If so, do > we need to just report it to the maintainer or it would be treated as > a feature? I think its a bad idea, but I say so as a user that when installing a new system, especially a remove vm will log in as root via ssh and join the machine post install to my ipa domain. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUcn9WAAoJEH7ltONmPFDRAwQP/36BhjlPb8AbNKzpZvuIcIX4 Sn+zTceuaaAwBYLIiHzqB7pQ7992Y3ka2V7ViWVcgmEbfgcVbm2roXQwHKN2IRGY e6xy+Tji0nt3vpbI+nvVVH3zWBMsIn+iy6YmddpzTCDNQVFtJBe/NRwNjKlqEg5A mXsPY/H0g20tv5SgWMzsTnbPOYRTEouLpCR7fUsEB5vifBjAmwHolPJ5IfiMIXg8 ese7JVE1UMfB6e2+CrkproC5lxVgmNASx/+6wgKKXJKVM8kD338Iy8zS3rWZpPOF zBModm0lgIF3kBDV9rpJARAo7Loj1EF9c/Dgv4OwzAcwsLWc8AxhHTK5Mle5T16Q 2WXteZBi9cJxdOK+n9lYWJDYN+NvjFViHFBY65ZKFcj95bu2UQy0dQtygtUJuv5C SC7MizpH1p/6BEwDnUmydk3PZ8m1zW1VExTRrkk/8uyjuxvBhMkQhrTB8dXQEwAO ReISOpEA7lyRlXH0v6SkKgQ2XST1nceR1Qt+lgyBksdXGVZ6Qgk1De2jV0230i44 lY0JfqgTwlg9dyRq3XQ4c9LteA53m2XICWrctcxeoJ3RxcO01UGbhwJ/bSNUVe+p c55FlsJm9oQqj28+0BD5kMeQAVoCtsW2iuk8htoLl3wbkn5KaRZPpCuTe4L5Z6Vy N5ZPvFiY2KbI5eZKz2fm =DRcf -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Enable tapping by default
On Sun, Nov 23, 2014 at 09:42:39AM +0100, Kevin Kofler wrote: > Nikos Roussos wrote: > > It's a UX thing, so the Workstation WG seems like the best place to > > decide this (at least for Gnome). > > But the Workstation WG has no decision power over other desktop > environments, such as KDE, which, incidentally, is what the original poster > happens to use. > > And I insist, IMHO, desktop environments should not be overriding the > systemwide default here. FTR, I disagree with this bit here. I think it's perfectly fine for a DE to change the defaults to what it thinks is best for the out-of-the-box experience. Some things like tapping simply have no correct solution that works for everyone and we have to pick one default. That doesn't mean that everyone has to follow that default now. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Enable tapping by default
On Sun, Nov 23, 2014 at 10:30:21AM +0100, Till Maas wrote: > On Mon, Nov 17, 2014 at 02:27:53PM +0300, Mustafa Muhammad wrote: > > Hi, I am testing Fedora 21 beta and -like all previous versions- click > > by tapping is off by default. > > Several bug reports concerning this were closed as NOTABUG, but > > tapping is useful for us (people who use it), I don't think it bothers > > the others that much, and is on by default in most operating systems > > and Linux distributions. > > How about just asking the user once if several tap-to-click events are > detected whether this should be enabled (and showing where to > enable/disable it). Then if someone is trying to use it while it does > not work, it can be easily enabled. And if someone does not want it but > would accidently click, the message just needs to be ignored once. not really possible in the current driver stack. Other than the synaptics driver itself, there is no knowledge that an event was caused by a tap vs. a physical button press. even the X server itself doesn't have that information. that is if tapping is enabled. if it is disabled, you don't get _any_ event at all from tapping, the movement of the finger isn't sufficient to trigger pointer movement and we don't expose the actual touch events to the clients. Short of adding a custom protocol that desktop environments can talk to the driver directly we're pretty much powerless here. And the idea of that doesn't fill me with excitement, as I hope you can understand :) Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora scientific packaging
- Original Message - > From: "Sandro Mani" > To: "Development discussions related to Fedora" > , scit...@lists.fedoraproject.org > Sent: Saturday, November 22, 2014 5:32:43 AM > Subject: Fedora scientific packaging > > Hello, > > Some time ago I started working on packaging Salome, the platform for > numerical simulation. As always, time is a limited resource, and things > kinda stalled after hitting a few issues here and there, despite most of > the work being done. Now, with Jiri Kastner joining the effort, we > decided that it would be nice to attempt to make the effort of packaging > scientific packages for Fedora in general more public, in particular > considering the scientific-spin effort [1]. > Many of the larger scientific packages tend to be very complex and their > build systems occasionally somewhat fragile... So getting more > interested people involved would likely increase the chances of the > efforts succeeding. > > That said, there is now a github repo which contains the > work-in-progress stuff for packaging Salome (and some initial OpenFOAM > work) here [2]. People interested in joining these efforts or sharing > initial work on other scientific packages are very welcome to join the > github project. This is great. I created the Fedora Scientific organization on GitHub some time back [1]. Do you think you would want to get your repo moved here? I can of course make you an admin, member, etc. [1] https://github.com/FedoraScientific Thanks, Amit. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mozilla enabled ads in Firefox and they're active in Fedora
On 11/23/2014 06:56 PM, Benjamin Kreuter wrote: > On Sun, 2014-11-23 at 02:59 -0800, Benjamin Kerensa wrote: > >> Personally I prefer data over knee jerk reactions because honestly this is >> what I see going on. I don't see a demand from users that want a different >> default I see developers who want to choose a different default based on >> their own beliefs. > > There is plenty of demand from users of Fedora for proprietary software > to be included. "Beliefs" are what keep that proprietary software out. > > -- Ben > > > +1 Just because folks may like Firefox, it does not mean that everyone would accept a Firefox that imposes Ads on you without at least asking you first. There is only a fine line between being the super-hero and the super-villain. -- Regards, Rejy M Cyriac (rmc) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 21 Final blocker bug status report #1
On 11/22/2014 12:15 AM, Adam Williamson wrote: Hi folks! We're now into the Fedora 21 Final freeze period, and we really need to address blocker bugs promptly to try and make the scheduled release date. On the current schedule Go/No-Go will happen on 2014-12-04, which means we really need the final release candidate built by 2014-12-02, so even if December feels like a long time away, it really isn't that much time to get everything fixed! Blockers needing testing / karma This should be testable by updating a FreeIPA server to openldap-2.4.40-2.fc21 and then...???...trying to enrol a client with ipa-client-install? https://bugzilla.redhat.com/show_bug.cgi?id=1146232 "f21 workstation ships 'default' network, so loses connectivity when run in a VM" - libvirt / gnome-boxes The 'fix' for this is a gnome-boxes build which drops the requirement for libvirt-daemon-config-network . That build has been included in TC3; I believe the expectation is that TC3 Workstation should not include libvirt and so should not be subject to this bug, we can check that. The update is marked as fixing the dependent bug https://bugzilla.redhat.com/show_bug.cgi?id=1164492 . One clarification: the livecd will still have a bunch of libvirt packages installed. What will be missing is only libvirt-driver-config-network - Cole -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Re: Mozilla enabled ads in Firefox and they're active in Fedora
If you want it in some cases (ie chrome i do ) learn to use it and accept that Fedora is FOSS minded so support for your endeavours may vary as will functionality and use/lack of funding projects for said FOSS projects deal or find another "tool" Corey W Sheldon Freelance IT Consultant, Multi-Discipline Tutor 310.909.7672 www.facebook.com/1stclassmobileshine On Sun, Nov 23, 2014 at 8:26 AM, Benjamin Kreuter wrote: > On Sun, 2014-11-23 at 02:59 -0800, Benjamin Kerensa wrote: > > > Personally I prefer data over knee jerk reactions because honestly this > is > > what I see going on. I don't see a demand from users that want a > different > > default I see developers who want to choose a different default based on > > their own beliefs. > > There is plenty of demand from users of Fedora for proprietary software > to be included. "Beliefs" are what keep that proprietary software out. > > -- Ben > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Re: Mozilla enabled ads in Firefox and they're active in Fedora
On Sun, 2014-11-23 at 02:59 -0800, Benjamin Kerensa wrote: > Personally I prefer data over knee jerk reactions because honestly this is > what I see going on. I don't see a demand from users that want a different > default I see developers who want to choose a different default based on > their own beliefs. There is plenty of demand from users of Fedora for proprietary software to be included. "Beliefs" are what keep that proprietary software out. -- Ben signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
xcf-pixbuf-loader unmaintained
A package with Fedora packaging bugs that are unhandled for years, e.g. https://bugzilla.redhat.com/668159 Upstream development has stopped, too. As one can see in the %changelog, it's still the same software since 2009/2010. In Fedora bugzilla, there is no response. The upstream developer has replied to me about two recent bug reports and might accept patches, too, but without contributing anything to the code base anymore, that basically means somebody else would need to take over development. For example, one can avoid some crashes easily, but it would not make the code more complete with regard to the XCF specs. https://apps.fedoraproject.org/packages/xcf-pixbuf-loader/bugs/all * Mon Aug 18 2014 Fedora Release Engineering - 0.0.1-13.8af913d1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild * Sun Jun 08 2014 Fedora Release Engineering - 0.0.1-12.8af913d1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild * Sun Aug 04 2013 Fedora Release Engineering - 0.0.1-11.8af913d1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild * Fri Feb 15 2013 Fedora Release Engineering - 0.0.1-10.8af913d1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild * Sun Jul 22 2012 Fedora Release Engineering - 0.0.1-9.8af913d1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild * Sat Jan 14 2012 Fedora Release Engineering - 0.0.1-8.8af913d1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild [...] * Wed Feb 17 2010 Bastien Nocera 0.0.1-2.8af913d1 - Update to 8af913d1 commit - Update with review comments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20141123 changes
Compose started at Sun Nov 23 05:15:02 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [codeblocks] codeblocks-13.12-10.fc22.i686 requires libastyle-2.04.so [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [glite-lb-common] glite-lb-common-9.1.1-2.fc22.i686 requires libclassad.so.6 [glite-lb-server] glite-lb-server-3.0.18-4.fc22.i686 requires libclassad.so.6 [nwchem] nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1 [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [seqan] seqan-1.4.2-2.fc22.i686 requires libseqan_flexlib.so seqan-1.4.2-2.fc22.i686 requires libmason_sim.so [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.i686 requires libmongoclient.so uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.i686 requires libmongoclient.so [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-utils-20140510-2.fc22.i686 requires libpolyclipping.so.16 Broken deps for x86_64 -- [3Depict] 3Depict-0.0.16-3.fc22.x86_64 requires libmgl.so.7.2.0()(64bit) [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [cab] cab-0.1.9-12.fc22.x86_64 requires cabal-dev [codeblocks] codeblocks-13.12-10.fc22.x86_64 requires libastyle-2.04.so()(64bit) [dnssec-check] dnssec-check-1.14.0.1-4.fc20.x86_64 requires libval-threads.so.14()(64bit) dnssec-check-1.14.0.1-4.fc20.x86_64 requires libsres.so.14()(64bit) [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [glite-lb-common] glite-lb-common-9.1.1-2.fc22.i686 requires libclassad.so.6 glite-lb-common-9.1.1-2.fc22.x86_64 requires libclassad.so.6()(64bit) [glite-lb-server] glite-lb-server-3.0.18-4.fc22.x86_64 requires libclassad.so.6()(64bit) [nwchem] nwchem-openmpi-6.3.2-11.fc21.x86_64 requires libmpi_usempi.so.1()(64bit) [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [seqan] seqan-1.4.2-2.fc22.x86_64 requires libseqan_flexlib.so()(64bit) seqan-1.4.2-2.fc22.x86_64 requires libmason_sim.so()(64bit) [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) vfrnav-utils-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) Broken deps for armhfp -- [3Depict] 3Depict-0.0.16-3.fc22.armv7hl requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [avro] avro-mapred-1.7.5-9.fc22.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc22.noarch requires hadoop-client [cab] cab-0.1.9-12.fc22.armv7hl requires cabal-dev [calamares] calamares-0-0.16.20141119git01c3244396f35.fc22.armv7hl requires grub2 [codeblocks] codeblocks-13.12-10.fc22.armv7hl requires libastyle-2.04.so [dnssec-check] dnssec-check-1.14.0.1-4.fc20.armv7hl requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.armv7hl requires libsres.so.14 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [glite-lb-common] glite-lb-common-9.1.1-2.fc22.armv7hl requires libclassad.so.6 [glite-lb-server] glite-lb-server-3.0.18-4.fc22.armv7hl requires libclassad.so.6 [ostree] ostree-grub2-2014.11-1.fc22.armv7hl requires grub2 [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [scirenderer] scirenderer-1.1.0-4.fc22.noarch requires jogl2 [seqan] seqan-1.4.2-2.fc22.armv7hl requires libseqan_flexlib.so seqan-1.4.2-2.fc22.armv7hl requires libmason_sim.so [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [spring-maps-default] spring-maps-default-0.1-12.fc21.noarch requires spring [syntastic] syntastic-d-3.5.0-1.fc22.noarch requires
F-21 Branched report: 20141123 changes
Compose started at Sun Nov 23 07:15:03 UTC 2014 Broken deps for armhfp -- [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [gearbox] gearbox-10.11-8.fc21.armv7hl requires libIceUtil.so.35 gearbox-10.11-8.fc21.armv7hl requires ice gearbox-devel-10.11-8.fc21.armv7hl requires ice-devel [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [ostree] ostree-grub2-2014.11-1.fc21.armv7hl requires grub2 [spring-maps-default] spring-maps-default-0.1-12.fc21.noarch requires spring [syntastic] syntastic-d-3.5.0-1.fc21.noarch requires ldc Broken deps for i386 -- [gearbox] gearbox-10.11-8.fc21.i686 requires libIceUtil.so.35 gearbox-10.11-8.fc21.i686 requires ice gearbox-devel-10.11-8.fc21.i686 requires ice-devel [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 Broken deps for x86_64 -- [gearbox] gearbox-10.11-8.fc21.i686 requires libIceUtil.so.35 gearbox-10.11-8.fc21.i686 requires ice gearbox-10.11-8.fc21.x86_64 requires libIceUtil.so.35()(64bit) gearbox-10.11-8.fc21.x86_64 requires ice gearbox-devel-10.11-8.fc21.i686 requires ice-devel gearbox-devel-10.11-8.fc21.x86_64 requires ice-devel [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0 Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Size of added packages: 0 (0 ) Size change of modified packages: 0 (0 ) Size of removed packages: 0 (0 ) Size change: 0 (0 ) Compose finished at Sun Nov 23 11:39:22 UTC 2014 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Re: Mozilla enabled ads in Firefox and they're active in Fedora
Well I'll go on the record as niether a firefox user OR gnome (chrome/ium & xfce), and to be honest, what tv station or other sporting event for that matter doesn't do the same ? So its okay there ? because I pay for a ticket to watch a show/game, besides defaults are there for functionality OOB NOT the gospel lordy... Corey W Sheldon Freelance IT Consultant, Multi-Discipline Tutor 310.909.7672 www.facebook.com/1stclassmobileshine On Sun, Nov 23, 2014 at 5:59 AM, Benjamin Kerensa wrote: > On Nov 22, 2014 11:48 PM, "Kevin Kofler" wrote: > > > > Benjamin Kerensa <…@mozillausa.org> wrote: > > [snip] > > > > Well, we can stop reading right at "mozillausa.org"… Of course the rest > of > > the mail is a totally biased plug. > > > Biased why because I work on Firefox? I work on a lot of Open Source > projects. > > > One thing though just forces me to reply: > > > > > but the fact is Fedora users come to expect Firefox to be the default > much > > > like they expect Gnome to be the default. > > > > Says who? The fact is that I'm one of those people who also want that > > default changed, because I think that it is clearly not the best desktop > > environment we can offer to our users (due to its design decisions). > > Thinking and knowing what the best experience for your users is two > different things. I would bet money if you surveyed fedora users they would > pick Firefox and Gnome. > > Personally I prefer data over knee jerk reactions because honestly this is > what I see going on. I don't see a demand from users that want a different > default I see developers who want to choose a different default based on > their own beliefs. > > If your users want something other than Firefox then give it to them but I > don't see that argument being made. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Re: Mozilla enabled ads in Firefox and they're active in Fedora
On Nov 22, 2014 11:48 PM, "Kevin Kofler" wrote: > > Benjamin Kerensa <…@mozillausa.org> wrote: > [snip] > > Well, we can stop reading right at "mozillausa.org"… Of course the rest of > the mail is a totally biased plug. > Biased why because I work on Firefox? I work on a lot of Open Source projects. > One thing though just forces me to reply: > > > but the fact is Fedora users come to expect Firefox to be the default much > > like they expect Gnome to be the default. > > Says who? The fact is that I'm one of those people who also want that > default changed, because I think that it is clearly not the best desktop > environment we can offer to our users (due to its design decisions). Thinking and knowing what the best experience for your users is two different things. I would bet money if you surveyed fedora users they would pick Firefox and Gnome. Personally I prefer data over knee jerk reactions because honestly this is what I see going on. I don't see a demand from users that want a different default I see developers who want to choose a different default based on their own beliefs. If your users want something other than Firefox then give it to them but I don't see that argument being made. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Enable tapping by default
On Mon, Nov 17, 2014 at 02:27:53PM +0300, Mustafa Muhammad wrote: > Hi, I am testing Fedora 21 beta and -like all previous versions- click > by tapping is off by default. > Several bug reports concerning this were closed as NOTABUG, but > tapping is useful for us (people who use it), I don't think it bothers > the others that much, and is on by default in most operating systems > and Linux distributions. How about just asking the user once if several tap-to-click events are detected whether this should be enabled (and showing where to enable/disable it). Then if someone is trying to use it while it does not work, it can be easily enabled. And if someone does not want it but would accidently click, the message just needs to be ignored once. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Suggested Freeze Policy change for Fedora 22+
Stephen Gallagher wrote: > These new rules don't ban "preventing a slip", they attempt to eliminate > the unreasonable demands we're putting on our volunteer QA team *every > week during Freeze*. It's gotten out of hand and it's burning people > out. > > The primary problem is that when we slip, there has never been a clear > statement made about when exactly when the deadline is for devs to get > their fixes in. Historically, devs have been operating under the > assumption that as long as a package lands before the next Go/No-Go > meeting, but that has failed to account for the time needed to create a > new Test Compose (which takes approx. 8 hours right now) as well as time > to have the QA team re-run the Release Validation tests (which takes an > absolute minimum of 20 hours fueled by caffeine and adrenaline). This > constant pause-then-panic situation is untenable and needs to be > addressed. > > By instituting the above plan, we will be much more transparent about > what the deadlines are for all participants (dev/maintainers, rel-eng > and QA) and we relieve the latter two of some of their panicked efforts > if we get to the Monday Blocker Review and it's clear that there is no > realistic chance that the Thursday Go/No-Go will rule in favor. I think our fundamental disagreement is that you believe that the rules will make developers come up with fixes faster, whereas I believe that we developers are already fixing things as fast as we can and the rules will only make Fedora releases slip more often. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Enable tapping by default
Peter Hutterer wrote: > that sounds like bug, please file it here: > https://bugs.freedesktop.org/enter_bug.cgi?product=xorg, component > Input/synaptics with one or more evemu recordings attached that triggered > an accidental tap. > > while tapping has its drawbacks, it's not supposed to be that bad. Well, I haven't had tapping enabled on my Fedora machines for ages, so I really don't know how bad it is nowadays. When I curse at tapping these days, it is only when I'm doing something on somebody else's machine, which is typically running anything from Ubuntu to Window$. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Enable tapping by default
Lukas Zapletal wrote: > I am not interested in tapping at all (I actually hate random clicks and > I always disable this), but if you really want to see this, why don't > you start a new screen in Gnome to present a selection during the first > boot. Maybe Gnome folks will like the idea, maybe not. You are assuming (incorrectly, as I know from IRC discussions) that the original poster is using GNOME. And are you seriously suggesting to add a *configuration screen* to *GNOME*?! ;-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Enable tapping by default
Nikos Roussos wrote: > It's a UX thing, so the Workstation WG seems like the best place to > decide this (at least for Gnome). But the Workstation WG has no decision power over other desktop environments, such as KDE, which, incidentally, is what the original poster happens to use. And I insist, IMHO, desktop environments should not be overriding the systemwide default here. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Taskotron depcheck broken/incomplete (was: Re: Removing packages that have broken dependencies in F21 tree)
Adam Williamson wrote: > http://tirfa.com/current-state-of-depcheck-and-paths-forward.html Sigh. This shows that once again a purported replacement for a working piece of software was deployed before it was able to perform the allegedly replaced tool's most important task, even though the problem was known to the replacement's developers. We really should not accept this kind of known regressions. > I'm sort-of volunteered to write the approach I suggested in a comment > as a new test, but it's going to have to wait until at least post-f21. Your approach indeed makes sense. It will not cause issues caused by added Conflicts or the like, but at least it catches the common case. (Just make sure you also consider Obsoleted packages as "the old package" whose Provides will no longer be available.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
