Re: Where is yaws?
On Sat, Jan 3, 2015 at 3:09 PM, Eduardo Javier Echeverria Alvarado wrote: > was retired because were having multiple failed builds from fedora 15 > > see https://bugzilla.redhat.com/show_bug.cgi?id=843203 Thank you for the info shared above, I will try building it and then submit it again. -- 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: 20150103 changes
Compose started at Sat Jan 3 05:15:03 UTC 2015 Broken deps for i386 -- [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [aeskulap] aeskulap-0.2.2-0.19beta1.fc22.i686 requires libofstd.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires liboflog.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg8.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg16.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg12.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmnet.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmjpeg.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimgle.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimage.so.3.6 aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmdata.so.3.6 [boswars] boswars-2.7-5.fc22.i686 requires libtolua++-5.1.so [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [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 [fawkes] fawkes-lua-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-katana-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-pantilt-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-roomba-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-skiller-0.5.0-19.fc22.i686 requires libtolua++-5.1.so [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 [glances] glances-2.2.1-1.fc22.noarch requires python-psutil >= 0:2.0.0 [guacamole-server] libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-utils.so.1.2 libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-core.so.1.2 libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-codec.so.1.2 libguac-client-rdp-0.9.3-1.fc22.i686 requires libfreerdp-cache.so.1.2 [nwchem] nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1 [pam_mapi] pam_mapi-0.2.0-3.fc22.i686 requires libmapi.so.0 [perl-Log-Any-Adapter] perl-Log-Any-Adapter-0.11-6.fc22.noarch requires perl(Log::Any::Adapter::Core) [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [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 [stratagus] stratagus-2.2.7-4.fc22.i686 requires libtolua++-5.1.so [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 -- [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [aeskulap] aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libofstd.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires liboflog.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libijg8.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libijg16.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libijg12.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libdcmnet.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libdcmjpeg.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libdcmimgle.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libdcmimage.so.3.6()(64bit) aeskulap-0.2.2-0.19beta1.fc22.x86_64 requires libdcmdata.so.3.6()(64bit) [boswars] boswars-2.7-5.fc22.x86_64 requires libtolua++-5.1.so()(64bit) [cab] cab-0.1.9-12.fc22.x86_64 requires cabal-dev [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) [fawkes] fawkes-lua-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-lua-0.5.0-19.fc22.x86_64 requires libtolua++-5.1.so()(64bit) fawkes-plugin-katana-0.5.0-19.fc22.x86_64 requires libtolua++-5.1.so()(64bit) fawkes-plugin-pantilt-0.5.0-19.fc22.x86_64 requires libtolua++-5.1.so()(64bit) fawkes-plugin-roomba-0.5.0-19.fc22.i686 requires libtolua++-5.1.so fawkes-plugin-roomba-0.5.0-19.fc22.x86_64 requires libtolua++-5.1.so()(64bit) fawkes-plugin-skiller-0.5.0-19.fc22.i686 requires
Screen low resolution
Hi, i have a problem with driver video, on my Fedora 21 KDE i686 any ideas? thanks in advance - gil lspci -nn |grep VGA 04:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT216 [GeForce GT 220] [10de:0a20] (rev a2) xrandr --verbose xrandr: Failed to get size of gamma for output default Screen 0: minimum 640 x 480, current 1024 x 768, maximum 1024 x 768 default connected primary 1024x768+0+0 (0x17c) normal (normal) 0mm x 0mm Identifier: 0x17b Timestamp: 57188 Subpixel: unknown Clones: CRTC: 0 CRTCs: 0 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: 1024x768 (0x17c) 47.972MHz *current h: width 1024 start0 end0 total 1024 skew0 clock 46.85KHz v: height 768 start0 end0 total 768 clock 61.00Hz 800x600 (0x17d) 29.280MHz h: width 800 start0 end0 total 800 skew0 clock 36.60KHz v: height 600 start0 end0 total 600 clock 61.00Hz 640x480 (0x17e) 18.432MHz h: width 640 start0 end0 total 640 skew0 clock 28.80KHz v: height 480 start0 end0 total 480 clock 60.00Hz -- 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: Screen low resolution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2015 12:41 PM, gil wrote: > Hi, i have a problem with driver video, on my Fedora 21 KDE i686 > any ideas? thanks in advance - gil > > lspci -nn |grep VGA 04:00.0 VGA compatible controller [0300]: > NVIDIA Corporation GT216 [GeForce GT 220] [10de:0a20] (rev a2) > > xrandr --verbose xrandr: Failed to get size of gamma for output > default Screen 0: minimum 640 x 480, current 1024 x 768, maximum > 1024 x 768 default connected primary 1024x768+0+0 (0x17c) normal > (normal) 0mm x 0mm Identifier: 0x17b Timestamp: 57188 Subpixel: > unknown Clones: CRTC: 0 CRTCs: 0 Transform: 1.00 > 0.00 0.00 0.00 1.00 0.00 0.00 0.00 > 1.00 filter: 1024x768 (0x17c) 47.972MHz *current h: width 1024 > start0 end0 total 1024 skew0 clock 46.85KHz v: height > 768 start0 end0 total 768 clock 61.00Hz 800x600 (0x17d) > 29.280MHz h: width 800 start0 end0 total 800 skew0 > clock 36.60KHz v: height 600 start0 end0 total 600 clock > 61.00Hz 640x480 (0x17e) 18.432MHz h: width 640 start0 end > 0 total 640 skew0 clock 28.80KHz v: height 480 start0 end > 0 total 480 clock 60.00Hz Driver loaded ? - -- Antonio Trande mailto: sagitter 'at' fedoraproject 'dot' org http://fedoraos.wordpress.com/ https://fedoraproject.org/wiki/User:Sagitter GPG Key: 0x66E15D00 Check on https://keys.fedoraproject.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUp9sPAAoJEFyovWBm4V0ARe4QAIutItJ7tFW38FPpXmtOPiIH OlHEXRyByE9fftONVmhRelZxkIX5lcQ42ER7Gcb20jQkzoOaoshM7W7UoK8xd6Sv wjAdHFh6HB3v+floQEXyYWIRrW+zZLoZs+X8y1l4YgQFOeECIOeQjyy51B5+Fjze bC31fJZTlf1rlALr/+UwdOcDMcFnHrxk56rT2vZWLPoA5YrVkuQsxqYXqHFaI+5q 2ZTFwHIXEB1Vg1lm/AaniHAHZb8B+s+e0BYfqGlpyxTmX6r/MR6RmeJF6wQ3Ii9q QBU51QM69if4lgCSvAFuKSttSBfsyqkCZpqpV15yjI6ti8Js2xwNmuKIYNGa8OQj v4+IRqV62RItCHMj8sMC6hpzrhqcTRqAJnJ/VwlQNIdL38ggQi72PNQrooeHVz1i 4tSaUNl3tNCgd5zSXRchujbDCrYfA0MN+nkMvRLL8gx62yJOSoazad7O5UYM066e Pcj7Oq/IQWiihOeFRq5CtAxNzCRxFZscGGWnXwUMqfb4vFIbuhD0QWm/NlotfXo9 zDiuv4snQpWs5qCwtRULn3hj12HBZpZcCGJrTbCRKQT4oZwO2pAZiGdwMB9zx9x6 BmXWthjbFCEgg5Tcx4zKMixvxAjZtvkkDL2QVk5X9v2HbcFiO8L4+FOhc7/t3i8D KClOPxbNM6O9EY+8Pg14 =fqJ7 -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: allowing programs to open ports
Florian Weimer wrote: >On 12/21/2014 05:28 PM, Björn Persson wrote: > >> Alternatively, cut out the packet filter and have GlibC ask the user >> whether the call to bind or connect shall be allowed to succeed (or >> automatically allow or deny the call if so configured). This has the >> advantage that the program is informed that it's not allowed to >> communicate. > >glibc is the wrong place for this, and a patch in this direction has >absolutely zero chance of being accepted upstream. We also ship >applications which call system calls directly, not through glibc, so >patching glibc would not even work at a technical level. That's true. The ability to call system calls directly kills the idea of having GlibC deny the call. (It does not affect the idea of calling FirewallD from GlibC rather than from each program individually. Those few programs that do call system calls directly could still call FirewallD on their own.) >However, a Linux Security Module such as SELinux could audit socket >creation, and provide the user with means to override the default >choices. Yes, that may be an even better solution if there is a way for SElinux to ask the user. >However, this will be extremely controversial (even more so >than the open firewall) because it will remind people of “personal >firewalls” on Windows. I bet! I worry that the questions would quickly become annoying. But if ports are going to be blocked by default, then there needs to be some way for non-sysadmin users to open them. -- Björn Persson signature.asc Description: 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: allowing programs to open ports
Stephen John Smoogen wrote: >1) I do not feel that countless programs will or want to accept >patches to open ports twice. I expect them to actually open a port >once and if they want to work with firewalld or some other firewall >daemon signal on dbus that they are looking to have a port open using >a predefined and open protocol. The port will be open like it always >was and the firewall will be closed if they don't use it, and possibly >open if they do (depending on the top level policy of whatever >firewall management program is there). Fine, so they wouldn't be patches to open ports twice, they'd be patches to ask FirewallD to open the firewall in addition to opening ports. Whatever. The point is that a lot of programs would have to be patched to do a Fedora-specific thing, and the patches would either have to be accepted upstream or carried in Fedora, or else the programs wouldn't work on Fedora. >3) glibc is meant to work on multiple OS's and distributions. Fedora >and even Red Hat are not important enough to force through a change >that isn't in the interests of other distributions. Which is where the >vague politics comes up. This sort of change would require working >with other distributions, other OS's and other organizations to get >their consensus on how it should work. That takes a long amount of >meetings, talking with people, showing them why it would be >worthwhile, figuring out all the corner cases and seeing if they are >fixable, etc. And it would see if it breaks various 'promises' like >POSIX compliance and such that the glibc team work actively to keep. All of that is true, but I don't see how it would be an argument for signaling FirewallD from many places rather than from one place. Most of the programs are also meant to work on multiple OSes and distributions, and I doubt that their developers would be happy to implement multiple distribution-specific protocols for opening firewalls. It would still require lots of discussions to get all of those distributions, OSes and organizations to agree on a single firewall-opening protocol, regardless of whether that protocol would then be used from GlibC of from each program individually. -- Björn Persson signature.asc Description: 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
R: Re: Screen low resolution
i think xorg-x11-drv-nouveau regards gil >Messaggio originale >Da: anto.tra...@gmail.com >Data: 03/01/2015 13.05 >A: "Development discussions related to Fedora" >Ogg: Re: Screen low resolution > >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >On 01/03/2015 12:41 PM, gil wrote: >> Hi, i have a problem with driver video, on my Fedora 21 KDE i686 >> any ideas? thanks in advance - gil >> >> lspci -nn |grep VGA 04:00.0 VGA compatible controller [0300]: >> NVIDIA Corporation GT216 [GeForce GT 220] [10de:0a20] (rev a2) >> >> xrandr --verbose xrandr: Failed to get size of gamma for output >> default Screen 0: minimum 640 x 480, current 1024 x 768, maximum >> 1024 x 768 default connected primary 1024x768+0+0 (0x17c) normal >> (normal) 0mm x 0mm Identifier: 0x17b Timestamp: 57188 Subpixel: >> unknown Clones: CRTC: 0 CRTCs: 0 Transform: 1.00 >> 0.00 0.00 0.00 1.00 0.00 0.00 0.00 >> 1.00 filter: 1024x768 (0x17c) 47.972MHz *current h: width 1024 >> start0 end0 total 1024 skew0 clock 46.85KHz v: height >> 768 start0 end0 total 768 clock 61.00Hz 800x600 (0x17d) >> 29.280MHz h: width 800 start0 end0 total 800 skew0 >> clock 36.60KHz v: height 600 start0 end0 total 600 clock >> 61.00Hz 640x480 (0x17e) 18.432MHz h: width 640 start0 end >> 0 total 640 skew0 clock 28.80KHz v: height 480 start0 end >> 0 total 480 clock 60.00Hz > >Driver loaded ? > >- -- >Antonio Trande > >mailto: sagitter 'at' fedoraproject 'dot' org >http://fedoraos.wordpress.com/ >https://fedoraproject.org/wiki/User:Sagitter >GPG Key: 0x66E15D00 >Check on https://keys.fedoraproject.org/ >-BEGIN PGP SIGNATURE- >Version: GnuPG v1 > >iQIcBAEBAgAGBQJUp9sPAAoJEFyovWBm4V0ARe4QAIutItJ7tFW38FPpXmtOPiIH >OlHEXRyByE9fftONVmhRelZxkIX5lcQ42ER7Gcb20jQkzoOaoshM7W7UoK8xd6Sv >wjAdHFh6HB3v+floQEXyYWIRrW+zZLoZs+X8y1l4YgQFOeECIOeQjyy51B5+Fjze >bC31fJZTlf1rlALr/+UwdOcDMcFnHrxk56rT2vZWLPoA5YrVkuQsxqYXqHFaI+5q >2ZTFwHIXEB1Vg1lm/AaniHAHZb8B+s+e0BYfqGlpyxTmX6r/MR6RmeJF6wQ3Ii9q >QBU51QM69if4lgCSvAFuKSttSBfsyqkCZpqpV15yjI6ti8Js2xwNmuKIYNGa8OQj >v4+IRqV62RItCHMj8sMC6hpzrhqcTRqAJnJ/VwlQNIdL38ggQi72PNQrooeHVz1i >4tSaUNl3tNCgd5zSXRchujbDCrYfA0MN+nkMvRLL8gx62yJOSoazad7O5UYM066e >Pcj7Oq/IQWiihOeFRq5CtAxNzCRxFZscGGWnXwUMqfb4vFIbuhD0QWm/NlotfXo9 >zDiuv4snQpWs5qCwtRULn3hj12HBZpZcCGJrTbCRKQT4oZwO2pAZiGdwMB9zx9x6 >BmXWthjbFCEgg5Tcx4zKMixvxAjZtvkkDL2QVk5X9v2HbcFiO8L4+FOhc7/t3i8D >KClOPxbNM6O9EY+8Pg14 >=fqJ7 >-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 -- 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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
On 02/01/15 11:42, Richard Hughes wrote: Because as of now, gnome-software just doesn't fit the workstation bill I think you're misunderstanding what most developers do. We probably spend about 10 minutes installing development packages (on the command line) when setting up a new OS instance. I then spend a year or so of installing or removing the odd application, and a few minutes every week applying updates. I don't think GNOME Software is hugely useful for installing low-level developer packages, which is fine. It doesn't mean it's not a useful application. I don't know if "most" developers works with more or less just one toolchain and environment as you describe. At least "some" actually works in a lot of projects, with different development packages and sometimes also tools. That said, what about describing the developer usecase as a project, focusing on a user using both GUI and CLI tools? - Get the sources (if they exist). - Install a toolchain, GUI-based or not. - Install dependencies: -devel packages, interpreted modules, etc. - Install project- or user-specific tools (GUI or not). - Keeping the installed sw updated. Installing the toolchain seems like DevAssistant to me. Besides this, I understand your position as if users are supposed to use yum/dnf except for GUI development tools and their dependencies (?) To my mind, forcing user to the prompt to this extent is less than ideal. A GUI installer certainly has advantages even for an occasional CLI user. And having to use different installers is a Bad Thing. Rather than talking in riddles in your emails, could you also please suggest what needs to be done? Are you in favour of ripping out gnome-software and installing yumex in the workstation image? Do you have an alternate application proposal with design mockups? At this point, I'm just trying to understand the usecase. Without that, decisions like using yumex instead of gnome-software makes no sense, nor does mock-ups. It's also a question to what extent upstream is willing to support this usecase. That said, my gut feeling is that the balance between simplicity and functionality is quite different for a "novice user" and a developer and that this needs to be handled with different modes, views or so (if gnome-software should handle it). Adding things like random CLI applications, -devel packages etc. to the search result for a novice user is just not an option, agreed. But IMHO a developer probably needs it in some form. Cheers! --alec -- 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: R: Re: Screen low resolution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2015 01:33 PM, punto...@libero.it wrote: > i think xorg-x11-drv-nouveau regards gil You must check if the nVidia video driver is loaded and if it is, check why it does not work properly. See http://fedoraproject.org/wiki/How_to_debug_Xorg_problems. Also check Grub2's system boot configuration. > >> Messaggio originale Da: anto.tra...@gmail.com Data: >> 03/01/2015 13.05 A: "Development discussions related to >> Fedora" Ogg: Re: Screen low >> resolution >> > On 01/03/2015 12:41 PM, gil wrote: Hi, i have a problem with driver video, on my Fedora 21 KDE i686 any ideas? thanks in advance - gil lspci -nn |grep VGA 04:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT216 [GeForce GT 220] [10de:0a20] (rev a2) xrandr --verbose xrandr: Failed to get size of gamma for output default Screen 0: minimum 640 x 480, current 1024 x 768, maximum 1024 x 768 default connected primary 1024x768+0+0 (0x17c) normal (normal) 0mm x 0mm Identifier: 0x17b Timestamp: 57188 Subpixel: unknown Clones: CRTC: 0 CRTCs: 0 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: 1024x768 (0x17c) 47.972MHz *current h: width 1024 start0 end0 total 1024 skew0 clock 46.85KHz v: height 768 start0 end0 total 768 clock 61.00Hz 800x600 (0x17d) 29.280MHz h: width 800 start0 end0 total 800 skew0 clock 36.60KHz v: height 600 start0 end 0 total 600 clock 61.00Hz 640x480 (0x17e) 18.432MHz h: width 640 start0 end 0 total 640 skew0 clock 28.80KHz v: height 480 start0 end 0 total 480 clock 60.00Hz > > Driver loaded ? > - -- Antonio Trande mailto: sagitter 'at' fedoraproject 'dot' org http://fedoraos.wordpress.com/ https://fedoraproject.org/wiki/User:Sagitter GPG Key: 0x66E15D00 Check on https://keys.fedoraproject.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUp/bAAAoJEFyovWBm4V0A/MwQAIDEh0HVD/VhXMBnTb1EVAdz WjttXILk65Sy35XG3YNqg3DsOa4aRj1dkwQi7hMR4a1BNTCAGVb+BB/xzHP82Rcq q8/f15u3v70+vfWXBnW2KxhTgH0dx9AEVnyR2pypAGWtKoyU1wsQBTchKV5tZB6v xg9LsdRZEowa/vrVKSsjt6W8YF95aYoE4JDvZ0D4cIgF590ockM8dKZRI7fnEfbi Z6uFB2h27pGreHRZ61umJEq7aFjU2+3e8TZ/OBSftBSmS7JPxjPFVSUz/KgIJgkO Cg6P4P9vwpv5+pvBWnjFcbZH1C2QIIVdn4dEJOK1gJHRqI/u5YRnerPMc2QMC2/A 4ml1LpOczvyf+a6EuTDYzHGLVUu959l4UCcU/ylLGpBCFKJXjOP3dWBeb2gYX+O2 Iw3QRYwFfGoz0q9z4ichdsjwuzX3ZCIrlQtM/ZP9/kIyEhK0QXiI+xtK3n/Pnl0W 8CE0/ErnYPf5s4VvOTkrm0TFnVptZ7EIf81yAkdwTn86QzGznCcvy54jt2YP/ElV ZchxrEd9VsTp7+swp2xyx09bEr99weT4b5Rp6wlghEgssUyM9amVuY5rIKKLD+Z5 QbZVa3Q9O8n+EzK7TwckVG+znaZPu6cMQSR7EDmWtBy+YwQAnwd+U6qYBwbyNq4h SuKbJgcATiGyVmXuPD7S =qEkp -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: R: Re: Screen low resolution
Il 03/01/2015 15.03, Antonio Trande ha scritto: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/03/2015 01:33 PM, punto...@libero.it wrote: >> i think xorg-x11-drv-nouveau regards gil > You must check if the nVidia video driver is loaded and if it is, > check why it does not work properly. See > http://fedoraproject.org/wiki/How_to_debug_Xorg_problems. > > Also check Grub2's system boot configuration. with "|journalctl -e _COMM=Xorg.bin|" i have no infos, remain a blank report can atacched /var/log/Xorg-* files ? regards >>> Messaggio originale Da: anto.tra...@gmail.com Data: >>> 03/01/2015 13.05 A: "Development discussions related to >>> Fedora" Ogg: Re: Screen low >>> resolution >>> >> On 01/03/2015 12:41 PM, gil wrote: > Hi, i have a problem with driver video, on my Fedora 21 KDE > i686 any ideas? thanks in advance - gil > > lspci -nn |grep VGA 04:00.0 VGA compatible controller > [0300]: NVIDIA Corporation GT216 [GeForce GT 220] [10de:0a20] > (rev a2) > > xrandr --verbose xrandr: Failed to get size of gamma for > output default Screen 0: minimum 640 x 480, current 1024 x > 768, maximum 1024 x 768 default connected primary > 1024x768+0+0 (0x17c) normal (normal) 0mm x 0mm Identifier: > 0x17b Timestamp: 57188 Subpixel: unknown Clones: CRTC: > 0 CRTCs: 0 Transform: 1.00 0.00 0.00 > 0.00 1.00 0.00 0.00 0.00 1.00 filter: > 1024x768 (0x17c) 47.972MHz *current h: width 1024 start0 > end0 total 1024 skew0 clock 46.85KHz v: height 768 > start0 end0 total 768 clock 61.00Hz 800x600 > (0x17d) 29.280MHz h: width 800 start0 end0 total > 800 skew0 clock 36.60KHz v: height 600 start0 end > 0 total 600 clock 61.00Hz 640x480 (0x17e) 18.432MHz h: width > 640 start0 end 0 total 640 skew0 clock 28.80KHz v: > height 480 start0 end 0 total 480 clock 60.00Hz >> Driver loaded ? >> > > > - -- > Antonio Trande > > mailto: sagitter 'at' fedoraproject 'dot' org > http://fedoraos.wordpress.com/ > https://fedoraproject.org/wiki/User:Sagitter > GPG Key: 0x66E15D00 > Check on https://keys.fedoraproject.org/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJUp/bAAAoJEFyovWBm4V0A/MwQAIDEh0HVD/VhXMBnTb1EVAdz > WjttXILk65Sy35XG3YNqg3DsOa4aRj1dkwQi7hMR4a1BNTCAGVb+BB/xzHP82Rcq > q8/f15u3v70+vfWXBnW2KxhTgH0dx9AEVnyR2pypAGWtKoyU1wsQBTchKV5tZB6v > xg9LsdRZEowa/vrVKSsjt6W8YF95aYoE4JDvZ0D4cIgF590ockM8dKZRI7fnEfbi > Z6uFB2h27pGreHRZ61umJEq7aFjU2+3e8TZ/OBSftBSmS7JPxjPFVSUz/KgIJgkO > Cg6P4P9vwpv5+pvBWnjFcbZH1C2QIIVdn4dEJOK1gJHRqI/u5YRnerPMc2QMC2/A > 4ml1LpOczvyf+a6EuTDYzHGLVUu959l4UCcU/ylLGpBCFKJXjOP3dWBeb2gYX+O2 > Iw3QRYwFfGoz0q9z4ichdsjwuzX3ZCIrlQtM/ZP9/kIyEhK0QXiI+xtK3n/Pnl0W > 8CE0/ErnYPf5s4VvOTkrm0TFnVptZ7EIf81yAkdwTn86QzGznCcvy54jt2YP/ElV > ZchxrEd9VsTp7+swp2xyx09bEr99weT4b5Rp6wlghEgssUyM9amVuY5rIKKLD+Z5 > QbZVa3Q9O8n+EzK7TwckVG+znaZPu6cMQSR7EDmWtBy+YwQAnwd+U6qYBwbyNq4h > SuKbJgcATiGyVmXuPD7S > =qEkp > -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
R: Re: Screen low resolution
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2015 04:00 PM, gil wrote: > Il 03/01/2015 15.03, Antonio Trande ha scritto: On 01/03/2015 01:33 > PM, punto...@libero.it wrote: i think xorg-x11-drv-nouveau regards gil > You must check if the nVidia video driver is loaded and if it is, > check why it does not work properly. See > http://fedoraproject.org/wiki/How_to_debug_Xorg_problems. > > Also check Grub2's system boot configuration. >> with "|journalctl -e _COMM=Xorg.bin|" i have no infos, remain a >> blank report can atacched /var/log/Xorg-* files ? regards Run it as root. - -- Antonio Trande mailto: sagitter 'at' fedoraproject 'dot' org http://fedoraos.wordpress.com/ https://fedoraproject.org/wiki/User:Sagitter GPG Key: 0x66E15D00 Check on https://keys.fedoraproject.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUqABeAAoJEFyovWBm4V0A5UgP/26ICgiBHK7ua4vLQs8gRIVg nTUP5XrlJAQm018+fjufBHmZmZfgYFtK/Ggw03es37uZa2B4nZsb/GNfdGlzFuT5 ykCIfFiNKSLNht1udxsKsBdhoOi4dT/jcekBdkKMIe2VqmxDJDl2dFfm0OS3YhCP jz5d3Dj3lDcdHnRuQ6Ps+8GcMlOcctZOUJXHxsloBZqU8RtF81OYffGu64aaHZkf ozbg+7HaFgVp/xL21ggXvlNjvo+gHUBntkwzAItnDGZd080i1PtiW5InmEJGxyb1 IeIEcKY3seF29ATNlm9XFFjkvfInK5re867M8begdhRdQ2MDsSVJI85ZpKU5ai/3 +8pS3262Y20C7wPLfffx3SfhDEcoqQ3aNJLfivkUgqLas9iCILrOWUUeVOo+nfsY bKzHPKcqSKrpGGojvjez3/fes1YJg0qvmyr7khAREQDrzyMfni9EZzLtxk/fcU+2 kttbikyALN+cWyWxcCmu7VKeEZIZNIkeVz5wsaYz2qhlGhumUeA55jc0zs7Ez+3b +Vc7ULVMF8e3RT42iO1yUO97NZ72rF8SMS65y/JNctjSWAe+3jkSqrNcp2OsWGKY 2MokETIS0/DKBrpnFdSZ5zGlTVEonkfGpJGPFCrj7e4h6pahDkkG2JHHwh+s/9l9 y1+CVWhQuHBvALHuRdZo =V1pW -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: R: Re: Screen low resolution
Il 03/01/2015 15:44, Antonio Trande ha scritto: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2015 04:00 PM, gil wrote: Il 03/01/2015 15.03, Antonio Trande ha scritto: On 01/03/2015 01:33 PM, punto...@libero.it wrote: i think xorg-x11-drv-nouveau regards gil You must check if the nVidia video driver is loaded and if it is, check why it does not work properly. See http://fedoraproject.org/wiki/How_to_debug_Xorg_problems. Also check Grub2's system boot configuration. with "|journalctl -e _COMM=Xorg.bin|" i have no infos, remain a blank report can atacched /var/log/Xorg-* files ? regards Run it as root. Now use F20 ~]$ lspci -nn |grep VGA 04:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT216 [GeForce GT 220] [10de:0a20] (rev a2) ~]$ xrandr --verbose Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192 DVI-I-1 disconnected (normal left inverted right x axis y axis) Identifier: 0x61 Timestamp: 49340 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: dithering depth: auto supported: auto6 bpc8 bpc dithering mode: auto supported: autooffstatic 2x2dynamic 2x2 scaling mode: Full supported: NoneFullCenterFull aspect color vibrance: 150 range: (0, 200) vibrant hue: 90 range: (0, 180) underscan vborder: 0 range: (0, 128) underscan hborder: 0 range: (0, 128) underscan: off supported: autooffon subconnector: Unknown supported: UnknownDVI-DDVI-A VGA-1 connected primary 1280x1024+0+0 (0x65) normal (normal left inverted right x axis y axis) 376mm x 301mm Identifier: 0x62 Timestamp: 49340 Subpixel: unknown Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 0 CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: EDID: 000034388b0701010101 271101030c261e96ea6735a657479622 1b5054bfef008180714f010101010101 010101010101302a009851002a403070 1300782d111e00ff00373339 4244303234303930363200fc0031 3930352053310a202020202000fd 00384b1f530e000a2020202020200050 scaling mode: None supported: NoneFullCenterFull aspect color vibrance: 150 range: (0, 200) vibrant hue: 90 range: (0, 180) 1280x1024 (0x65) 108.0MHz +HSync +VSync *current +preferred h: width 1280 start 1328 end 1440 total 1688 skew0 clock 64.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.0Hz 1280x1024 (0x66) 135.0MHz +HSync +VSync h: width 1280 start 1296 end 1440 total 1688 skew0 clock 80.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 75.0Hz 1152x864 (0x67) 108.0MHz +HSync +VSync h: width 1152 start 1216 end 1344 total 1600 skew0 clock 67.5KHz v: height 864 start 865 end 868 total 900 clock 75.0Hz 1024x768 (0x68) 78.8MHz +HSync +VSync h: width 1024 start 1040 end 1136 total 1312 skew0 clock 60.1KHz v: height 768 start 769 end 772 total 800 clock 75.1Hz 1024x768 (0x69) 75.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1328 skew0 clock 56.5KHz v: height 768 start 771 end 777 total 806 clock 70.1Hz 1024x768 (0x6a) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 832x624 (0x6b) 57.3MHz -HSync -VSync h: width 832 start 864 end 928 total 1152 skew0 clock 49.7KHz v: height 624 start 625 end 628 total 667 clock 74.6Hz 800x600 (0x6c) 50.0MHz +HSync +VSync h: width 800 start 856 end 976 total 1040 skew0 clock 48.1KHz v: height 600 start 637 end 643 total 666 clock 72.2Hz 800x600 (0x6d) 49.5MHz +HSync +VSync h: width 800 start 816 end 896 total 1056 skew0 clock 46.9KHz v: height 600 start 601 end 604 total 625 clock 75.0Hz 800x600 (0x6e) 40.0MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 800x600 (0x6f) 36.0MHz +HSync +VSync h: width 800 start 824 end 896 total 1024 skew0 clock 35.2KHz v: height 6
Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
/*Alec Leamas */ wrote on Sat, 03 Jan 2015 14:57:10 +0100: On 02/01/15 11:42, Richard Hughes wrote: <> That said, my gut feeling is that the balance between simplicity and functionality is quite different for a "novice user" and a developer and that this needs to be handled with different modes, views or so (if gnome-software should handle it). Adding things like random CLI applications, -devel packages etc. to the search result for a novice user is just not an option, agreed. But IMHO a developer probably needs it in some form. Search results can be presented in groups (same as groups already used in the main screen): Sound/Graphics/Fonts/Development Libraries/etc... Usually, when a user search for some terms, he already know its category. In fact, I think grouping search results is useful even in the current state without any CLI tools or development libraries. It needs a good UI design though. Maybe search results can be 'tagged' with their category, and a list of categories (of the results) is presented somewhere at the top/side so that the user can select one or some tags so that only packages from those categories will be shown. Or, the UI might ask the user (ouch, frowned upon!) some questions (if results were scattered in many categories) so that it can fine tune the results. Thanks, Hedayat Cheers! --alec -- 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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
/*Luya Tshimbalanga*/ wrote on Fri, 02 Jan 2015 17:29:14 -0800: On 02/01/15 01:15 PM, Hedayat Vatankhah wrote: Probably true, but it already includes fonts and input sources. So, someone has felt that 'front-end applications only' is too narrow. Now, where you can draw the line? I exaggerated. Did you try that? The problem with searching for "C++" is that it will list almost all applications (probably it searches for "C"). So it has nothing to do with DevAssistant. I just searched "C++" resulting a freeze of Gnome Software due to handling of "++" character. That is a bug I already submitted https://bugzilla.redhat.com/show_bug.cgi?id=1178199 Normally, Gnome Software should list DevAssistant on the first list as I have no problem typing python or ruby keyword on the search field. Thanks for filling the bug. :P I was thinking when I'll report it. So, every IDE should have a 'clang' addon? and also a gcc addon? At least, if 'shared' add-ons are available things will be much easier. In this case, why not? I was actually suggesting a solution which could fit in the current design. I'm not against the latter (while I still prefer having them as independent applications, in case you really don't need an IDE. However, if it is also available as a DevAssistent add-on, it'd be good; but actually I'm mis-using DevAssistant as 'Development Tools' category!) I wonder why people want to split developers into two categories: GUI-only and Terminal-only? Why there couldn't be a "GUI as much as possible developer"? Such a developer will prefer to install autotools and clang/gcc using a GUI application, then open a terminal and run "./configure && make && sudo make install" in shell? Why do people think that a developer which wants (actually, since currently there are no(?) GUI ways to do configure, make and make install, he is forced) to use terminal should be 'punished' to use command line for installing the tools he need? They were attempt of create a frontend for that purpose and most of them were poorly implemented. Take a look of how Microsoft and Apple do their development. it is a matter of finding a better way of implementing the tool. If you mean finding a replacement for autotools, I disagree. While having better ways is great (and actually, there are many 'autotools replacements' and some of them are GUI friendly. A good example is CMake), but there is a fact that there are many packages using autotools. I don't know how Apple does it (but I think I remember some of my friends actually being *forced* to use command line to install an auto-tools based library), but I wonder if you know about a 'better way' Microsoft provides. As far as I know, installing and using third-party development libraries under Windows is nearly Terrible. And, the last time I tried to use Boost under Windows it certainly needed using command line to use boost build system. I used several other libraries under Windows, none of them provided any *good* means for installation and usage. Most importantly, Windows doesn't (or at least, didn't!) have any Software Center like tools at all. So, there are no means in Windows for finding and installing development libraries; and hence it can't be better or worse than ours! (Well, hopefully in future there will be a tool (DevAssistant?) which can help you to configure, compile and install a package from source. Then, it can have gcc/clang/... compilers as its addons too; so it's become more practical to have GUI-only developers who don't need to install a compiler directly). DevAssistant is a start. Next step will be adding packaging guideline and other stuff. It takes time but it can be done. Add-ons cannot cover development libraries, unless every library is an add-on for all IDEs! Then is IDE packaging issue. When it comes of using a development applications, the software should suggest installing the missing library. If Gnome Video is able to prompt uses to install missing component, then why shouldn't be possible for IDE application to do the same? Granted I don't know well the functionality but the logic is application should detect and suggest adding the missing function. Hmm... that's weird, I can't understand what you mean. Gnome Video's job is very easy: a video has a special format, and there are specific plugins to enable playing that. However, assume that I need an XML library for C++: 1. How can I tell the IDE that I need an XML library? 2. What should IDE do if there are 5 different XML libraries for C++? How should I tell it which one I want, specially if I don't know what should I use already, and want to see what is available out there? To me, it seems like implementing a special purpose software manager inside IDE with almost all functionality GNOME Software provides. As I said in another post, user reviews/rating for development libraries (like what GNOME Software provides for applications)
Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
On 03/01/15 20:26, Hedayat Vatankhah wrote: /*Luya Tshimbalanga*/ wrote on Fri, 02 Jan 2015 17:29:14 -0800: Add-ons cannot cover development libraries, unless every library is an add-on for all IDEs! Then is IDE packaging issue. When it comes of using a development applications, the software should suggest installing the missing library. If Gnome Video is able to prompt uses to install missing component, then why shouldn't be possible for IDE application to do the same? Granted I don't know well the functionality but the logic is application should detect and suggest adding the missing function. Hmm... that's weird, I can't understand what you mean. Gnome Video's job is very easy: a video has a special format, and there are specific plugins to enable playing that. However, assume that I need an XML library for C++: 1. How can I tell the IDE that I need an XML library? 2. What should IDE do if there are 5 different XML libraries for C++? How should I tell it which one I want, specially if I don't know what should I use already, and want to see what is available out there? To me, it seems like implementing a special purpose software manager inside IDE with almost all functionality GNOME Software provides. As I said in another post, user reviews/rating for development libraries (like what GNOME Software provides for applications) can be really helpful when a developer wants to choose a library for a specific purpose. In other words: there is a difference between the toolchain and project dependencies. The toolchain e. g. eclipse + gcc etc. can be probably partly be fixed using IDE dependencies, DevAssistant and similar setups reflecting general tool-set dependencies, agreed. OTOH, the dependencies for a specific project cannot really be handled this way. Such libraries are specific for the code you build, not the tools. Making them dependencies of e. g., eclipse just doesn't make any sense. Cheers! --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Yet another frustration with Fedora package management
Hi! Summary: Try to prevent a package from being updated/installed from repositories regardless of the package management tool you use. As it seems, then only way you can do this is to exclude it from the repositories themselves inside their configuration file in /etc/yum.repos.d/, because these are the only common settings between all three (yum/dnf/PackageKit). TBH, I'm not sure about PackageKit, but I feel that it don't read /etc/dnf/dnf.conf as it doesn't use DNF but its backends. This is fine if the package is in a single known repository, but what if it is in 3 repositories that you might not be aware of all of them? More details: As you might already know, nvidia drivers in RPMFusion F21 repositories doesn't work for all nvidia cards. In one system, I finally installed akmod-nvidia from RPMFusion F20 repositories which worked fine. Soon after I realized that I should exclude akmod-nvidia and dependencies from F21 repositories. I added "exclude=*nvidia*" to /etc/yum.conf as I was lazy to check which repository these packages come from. But then I noticed that dnf doesn't consider it excluded. Then I thought that probably PackageKit doesn't use dnf.conf too. So, how should I excluded these packages? Well, these were in rpmfusion-nonfree-updates repository, so I added the exclude directive there. Then I found that I should add it to rpmfusion-nonfree repository too. However, since I use yum-plugin-local I also have a local repository (I actually copied the repository from another system, so it was enabled on this system so that I could install software from it) which also included these packages. Therefore, I should exclude "*nvidia*" in 3 repository configuration files to make sure (hopefully!) that these will not be installed by any package manager I know. Suggestion: Please add a single configuration file to configure common package manager options (Specially between DNF and PackageKit, which are there to stay). As I mentioned in "F21 downloads repository metadata in 3 places!" thread, Fedora package management should be consistent and integrated; and the current situation is really frustrating. If I want to exclude some packages, I should be able to do it once for all. If I want to disable automatic download of metadata/packages, there should be a single place where I can define my desired package management policy. If I want to specify default metadata_expire timeout for all repositories, there should be one place to do it. There really should be a single package management policy that must be respected by every package manager in Fedora, specially the main ones: DNF and PackageKit (and currently Yum). Regards, Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
Sorry this is a bit late but I had a few thoughts on what I have read in this thread: Is workstation being aimed at new users or developers? And is the goal the same for Gnome? If Gnome is aiming to cater to new users, then is it the right primary DE for fedora? There seems to be a misalignment here. I have spent most of the last 15 years working for one of the largest computing colleges in the country. I can guarantee you that the vast majority of our students learned to program in a terminal. It may not be the preferred environment once they become professionals, but it shouldn't intimidate them by any means. So if workstation is aimed at developers, why are we worried about them encountering the terminal when using the OS? Instead of hiding the CLI from new users, why not simply give them the option of avoiding it? Instead of only showing gui apps, why not show all with packages being tagged as either cli or gui. Then the user can decide whether or not they want to install the package. A package manager that can show ALL packages should be installed by default in Gnome on Fedora. This isn't a distro that only ships a single DE. -- 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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
On Sat, 3 Jan 2015 15:56:55 -0500 Gary Scarborough wrote: > Sorry this is a bit late but I had a few thoughts on what I have read > in this thread: > > Is workstation being aimed at new users or developers? And is the > goal the same for Gnome? If Gnome is aiming to cater to new users, > then is it the right primary DE for fedora? There seems to be a > misalignment here. I don't speak for Gnome or the Workstation group, but no. I don't either of those groups are targeting 'new users' > I have spent most of the last 15 years working for one of the largest > computing colleges in the country. I can guarantee you that the vast > majority of our students learned to program in a terminal. It may > not be the preferred environment once they become professionals, but > it shouldn't intimidate them by any means. So if workstation is > aimed at developers, why are we worried about them encountering the > terminal when using the OS? I'm not personally worried about that, and I think lots of other folks aren't either. > Instead of hiding the CLI from new users, why not simply give them the > option of avoiding it? Instead of only showing gui apps, why not > show all with packages being tagged as either cli or gui. Then the > user can decide whether or not they want to install the package. Well, the current state of things is that the GUI software manager shows only GUI apps and users need to use a cli software manager to install and manage cli apps. I'm not sure there's advantage to showing cli apps in the GUI software manager. > A package manager that can show ALL packages should be installed by > default in Gnome on Fedora. This isn't a distro that only ships a > single DE. Yum or dnf meets this need as far as I can tell. kevin pgpm2vW5aMGGL.pgp Description: OpenPGP digital 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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
On 3 January 2015 at 20:56, Gary Scarborough wrote: > Is workstation being aimed at new users or developers? I don't think people fit clearly in these simplistic groups. I'm an experienced GNOME developer, but I've never used C# before. > A package manager that can show ALL packages should be installed by default > in Gnome on Fedora. I've had about a decade trying to help here. Designing an application manager is hard. Making an application "jack of all trades" makes it "master of none". I tried to mix packages and application concept in gnome-packagekit over the last few years, but it made for a poor package manager experience and a poor application management experience. So much so, now that gnome-software exists and is being used for application management and system updates, I've ripped out all the application stuff from gnome-packagekit returning it to a 100% package-centric view. If you type "package" into the dash the fist entry is "GNOME Packages" which is the install/remove tool from gnome-packagekit. You can install it with three clicks. I don't think it makes sense to install it by default. Richard -- 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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
/*Kevin Fenzi*/ wrote on Sat, 3 Jan 2015 14:09:11 -0700: On Sat, 3 Jan 2015 15:56:55 -0500 Gary Scarborough wrote: <...> Instead of hiding the CLI from new users, why not simply give them the option of avoiding it? Instead of only showing gui apps, why not show all with packages being tagged as either cli or gui. Then the user can decide whether or not they want to install the package. Well, the current state of things is that the GUI software manager shows only GUI apps and users need to use a cli software manager to install and manage cli apps. I'm not sure there's advantage to showing cli apps in the GUI software manager. It has advantage for a user who prefers GUI, but sometimes needs to install and use a CLI application. Such a user, which can easily include many GNU/Linux new users who might happen to need to use a specific CLI application, might know about the cli application usage (e.g. using a app specific manual) but doesn't know anything about dnf/yum, and is not interested to learn them. Does anybody really think that there should be any relation between the UI of your package manager and the UI of the packages you install with it? If so, maybe dnf/yum should be also unable to install GUI apps. :P Hedayat -- 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: Yet another frustration with Fedora package management
Hedayat Vatankhah wrote: > Hi! > Summary: Try to prevent a package from being updated/installed from > repositories regardless of the package management tool you use. As it > seems, then only way you can do this is to exclude it from the > repositories themselves inside their configuration file in > /etc/yum.repos.d/, ... > Suggestion: Please add a single configuration file to configure common > package manager options I think you answered your own question => modify the .repo files -- Rex -- 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: Yet another frustration with Fedora package management
Am 03.01.2015 um 23:58 schrieb Rex Dieter: Hedayat Vatankhah wrote: Hi! Summary: Try to prevent a package from being updated/installed from repositories regardless of the package management tool you use. As it seems, then only way you can do this is to exclude it from the repositories themselves inside their configuration file in /etc/yum.repos.d/, ... Suggestion: Please add a single configuration file to configure common package manager options I think you answered your own question => modify the .repo files "includepkgs" and "exclude" are also *global* options man yum.conf so the "configure common options" is just /etc/yum.conf signature.asc Description: OpenPGP digital 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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
On Sat, Jan 3, 2015 at 3:12 PM, Richard Hughes wrote: If you type "package" into the dash the fist entry is "GNOME Packages" which is the install/remove tool from gnome-packagekit. You can install it with three clicks. I don't think it makes sense to install it by default. We may have been too aggressive in removing it. I think we could include it by default if it had a first-run dialog that briefly explains what a package is, and that package management is an advanced tool for system administrators. Maybe with a link that launches GNOME Software. Alternatively, we could leave it uninstalled by default, and add a "cross-reference" to it from GNOME Software's first-run dialog, or simply by making it a featured app. Just throwing out ideas here -- 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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
Hi On Sat, Jan 3, 2015 at 6:20 PM, Michael Catanzaro wrote: > We may have been too aggressive in removing it. I think we could include > it by default if it had a first-run dialog that briefly explains what a > package is, and that package management is an advanced tool for system > administrators. Maybe with a link that launches GNOME Software. > Another alternative would be for GNOME Software to show packages perhaps optionally and deprioritize packages in the listing which don't fit GNOME Software's criteria for an "Application". Excluding all packages just causes confusion and has become a FAQ as of late in users list, Ask Fedora etc. Rahul -- 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: Yet another frustration with Fedora package management
On Sat, Jan 3, 2015 at 5:58 PM, Rex Dieter wrote: > Hedayat Vatankhah wrote: > >> Hi! >> Summary: Try to prevent a package from being updated/installed from >> repositories regardless of the package management tool you use. As it >> seems, then only way you can do this is to exclude it from the >> repositories themselves inside their configuration file in >> /etc/yum.repos.d/, > ... >> Suggestion: Please add a single configuration file to configure common >> package manager options > > I think you answered your own question => modify the .repo files > > -- Rex This is usually a poor approach for anything that needs to be excluded from multiple repos. The GUI's also have no idea about this kind of editing, and little or no ability to control the option if it's being done manually without their knowledge of its uses. The classic example is 'mysql-libs' from RHEL, when using a Percona or SCL yum configuration. The library is present as a "meta" package in packages that are not called 'mysql-libs'. Hilarity ensues when trying to do an update. The overlapping packages, with different names, meant that setting up a 3rd party repository requires editing the repo files of the base or other 3rd party repositories as added. Hilarity ensues, especially if there are "testing" respositories added later which are not enabled by default and the machine owner does not know to modify the new repo files. A safer approach is to use "exclude" options in the /etc/yum.conf, but this gets bogged down fast and can lead to quite dangerous manual auditing of core configuration files. I'd frankly prefer to see a "/etc/yum.exclude' included in yum by default, and that file included by default in /etc/yum.conf. I'd love to see that kind of architecture in dnf as well. -- 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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
On Wed, Dec 31, 2014 at 8:25 AM, Richard Hughes wrote: > On 30 December 2014 at 23:31, Chris Murphy wrote: >> b.) Would it be helpful, friendlier, and better emphasize the special >> focus, if these group install items mentioned above were exposed in >> GNOME Software with an appropriate icon? > > We could do this right now, although I don't think "expose the entire > comps tree" makes a lot of sense. We need translations, icons, > screenshots, and of course approval from the Fedora/GNOME designers. > Addons would be a logical place for this, although I think it probably > needs more design thought about how to handle these "non-application" > metagroupings. Sounds very reasonable. Qualifying my position: I'm fairly comfortable with yum/dnf group installs now, so this isn't a sticking point for me personally. This really is the Workstation WG's turf to define what kind of UI/UX they want to have for developers new to the platform. And I'm inclined to think keeping developers (even CLI dominant ones) away from the esoterics of platform packaging is a good thing. I don't know if Software will instinctually be their go to for such a thing, so that's also a question someone needs to answer. > Installing a compiler is something that *something* > needs to handle, I'm just not sure if that should be gnome-software > itself or something that *uses* gnome-software to do the correct thing > and to handle updates. Could maybe be in scope for Fedora dev assistant also. http://fedoraproject.org/wiki/Features/DevelopersAssistant "Make the development on Fedora easier for beginners." "Try to install package containing setup for your favourite language." -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File location
hi, I am working on packaging an upstream (aerospike) which presently puts some of its file in /opt/aerospike. The two main folders in use (by upstream) are /opt/aerospike/sys/udf/lua - This has the user defined lua functions shipped with the package. /opt/aerospike/usr/udf/ - This will have the user's custom UDFs. What will be the right place in FHS to put the above two directories when packaging for Fedora? Should these go into /usr/share/aerospike or some place in /var? regards Anshu Prateek -- 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: File location
Open a ticket in FPC, you can may only use directories in the /opt/fedora, however fpc can help you decide whether it's a valid use of /opt and what subdirectory should be allocated for your use [1][2] [1] http://fedoraproject.org/wiki/Packaging:Guidelines#Limited_usage_of_.2Fopt.2C_.2Fetc.2Fopt.2C_and_.2Fvar.2Fopt [2] http://www.lanana.org/lsbreg/providers/providers.txt 2015-01-04 2:11 GMT-04:30 Anshu Prateek : > hi, > > I am working on packaging an upstream (aerospike) which presently puts some > of its file in /opt/aerospike. > > The two main folders in use (by upstream) are > > /opt/aerospike/sys/udf/lua - This has the user defined lua functions > shipped with the package. > /opt/aerospike/usr/udf/ - This will have the user's custom UDFs. > > What will be the right place in FHS to put the above two directories when > packaging for Fedora? Should these go into /usr/share/aerospike or some > place in /var? > > regards > Anshu Prateek > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Eduardo Echeverría Director Soluciones SAEF, C.A. J-29663216-2 0245-7666441 0414-4304448 soluciones.s...@gmail.com -- 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: File location
Thanks echevemaster. Created https://fedorahosted.org/fpc/ticket/487 On Sun Jan 04 2015 at 12:51:16 PM Eduardo Javier Echeverria Alvarado < echevemas...@gmail.com> wrote: > Open a ticket in FPC, you can may only use directories in the > /opt/fedora, however fpc can help you decide whether it's a valid use > of /opt and what subdirectory should be allocated for your use [1][2] > > [1] http://fedoraproject.org/wiki/Packaging:Guidelines#Limited_ > usage_of_.2Fopt.2C_.2Fetc.2Fopt.2C_and_.2Fvar.2Fopt > [2] http://www.lanana.org/lsbreg/providers/providers.txt > > 2015-01-04 2:11 GMT-04:30 Anshu Prateek : > > hi, > > > > I am working on packaging an upstream (aerospike) which presently puts > some > > of its file in /opt/aerospike. > > > > The two main folders in use (by upstream) are > > > > /opt/aerospike/sys/udf/lua - This has the user defined lua functions > > shipped with the package. > > /opt/aerospike/usr/udf/ - This will have the user's custom UDFs. > > > > What will be the right place in FHS to put the above two directories when > > packaging for Fedora? Should these go into /usr/share/aerospike or some > > place in /var? > > > > regards > > Anshu Prateek > > > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/devel > > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > > > -- > Eduardo Echeverría > Director > Soluciones SAEF, C.A. > J-29663216-2 > 0245-7666441 > 0414-4304448 > soluciones.s...@gmail.com > -- > 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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
- Original Message - > From: "Hedayat Vatankhah" > To: "Development discussions related to Fedora" > > Sent: Friday, January 2, 2015 11:15:58 PM > Subject: Re: Ramblings and questions regarding Fedora,but stemming > from gnome-software and desktop environments > > > > Luya Tshimbalanga wrote on Fri, 02 Jan 2015 12:25:49 -0800: > > > > On 01/01/15 04:21 PM, Hedayat Vatankhah wrote: > > > > > > > Well, I was really surprised that developers are considered a target audience > here. GNOME Software *might* be considered good enough for normal users, but > its far from usable for a developer; even a developer who don't want to > touch the terminal. Actually, it is *terrible* for such a developer. Why? > > From what I understand, Gnome Software is intended for front-end applications > only. > Probably true, but it already includes fonts and input sources. So, someone > has felt that 'front-end applications only' is too narrow. Now, where you > can draw the line? > > > > > > > > 1. He search for "C++" and (I doubt that it tries to interpret it as a > regular expression or something. Probably it thinks that the user is an > idiot and removes "+" signs on behalf of him). > DevAssistant application available by default on Fedora Workstation is > designed for that purpose. > Did you try that? The problem with searching for "C++" is that it will list > almost all applications (probably it searches for "C"). So it has nothing to > do with DevAssistant. > > > > > > > > > > 2. He has installed Eclipse + CDT and hopefully he can compile his C++ > programs with GCC. Now, he learns about Clang and would like to try it. > Clang is a compiler that be installed as an add-ons for Eclipse. That is very > much an request of enhancement for IDEs installation in Gnome Software. > So, every IDE should have a 'clang' addon? and also a gcc addon? At least, if > 'shared' add-ons are available things will be much easier. > > I wonder why people want to split developers into two categories: GUI-only > and Terminal-only? Why there couldn't be a "GUI as much as possible > developer"? Such a developer will prefer to install autotools and clang/gcc > using a GUI application, then open a terminal and run "./configure && make > && sudo make install" in shell? Why do people think that a developer which > wants (actually, since currently there are no(?) GUI ways to do configure, > make and make install, he is forced) to use terminal should be 'punished' to > use command line for installing the tools he need? > > (Well, hopefully in future there will be a tool (DevAssistant?) which can > help you to configure, compile and install a package from source. Then, it > can have gcc/clang/... compilers as its addons too; so it's become more > practical to have GUI-only developers who don't need to install a compiler > directly). > > > > > > > > > GNOME Software is not that useful for a developer. As Rechard himself said, > he'll need a package manager anyway. So, If Workstation product really > targets developers, specially the ones who don't want to use terminal, it > MUST include a graphical package manager. > > There are developers unaware of the concept of package manager which does not > help. Gnome Software is actually useful once the add-ons functionality is > fully expanded on applications. Works need to be done allowing a seamless > integration. > Add-ons cannot cover development libraries, unless every library is an add-on > for all IDEs! It can be done dynamic aka install devel packages on request by IDEs - see https://rgrunber.fedorapeople.org/eclipse_packagekit_1.ogv Alexander Kurtakov Red Hat Eclipse team > > Regards, > Hedayat > > > > > > -- > Luya Tshimbalanga > Graphic & Web Designer > E: l...@fedoraproject.org W: http://www.coolest-storm.net > > > -- > 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
