rawhide report: 20141230 changes
Compose started at Tue Dec 30 05:15:03 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) [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 [ember] ember-0.7.2-2.fc22.i686 requires libtolua++-5.1.so [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.1.2-2.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 [nodejs-got] nodejs-got-2.2.0-1.fc22.noarch requires npm(duplexify) 0:4 nodejs-got-2.2.0-1.fc22.noarch requires npm(duplexify) = 0:3.2.0 [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 [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 -- [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) [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) [ember] ember-0.7.2-2.fc22.x86_64 requires libtolua++-5.1.so()(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
Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments
On 12/29/2014 04:48 PM, Alec Leamas wrote: Fair enough. But to me, adding GNOME Software (GS) also cannot install compilers, interpreters and other CLI tools creates a more problematic situation. To me, Fedora Workstation w/ Gnome is an incarnation of GnomeOS - An OS aimed at single-user, single-seat, kiosk-style of use-cases, aiming at competing with Android/WinRT, MetroUI and iOS. Is GS intended to be a one size fits all solution for both novice users and the workstation target developer user? I don't know if it's aimed at being a one size fits all solution. To me, it's a matter of fact, that in general, there can never ever be such a thing as a one-size fits all solution anywhere. And if walking this path, the Workstation default mode would be the one corresponding to a developer, right? Define Workstation. I don't know which audience the people, who implemented it, were aiming at - It definitely wasn't my use-case scenario. Ralf -- 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 30/12/14 13:07, Ralf Corsepius wrote: On 12/29/2014 04:48 PM, Alec Leamas wrote: And if walking this path, the Workstation default mode would be the one corresponding to a developer, right? Define Workstation. I don't know which audience the people, who implemented it, were aiming at - It definitely wasn't my use-case scenario. The only definition I'm aware of is [1]. Cheers! --alec [1]: http://fedoraproject.org/wiki/Workstation/Workstation_PRD -- 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
Am 30.12.2014 um 13:07 schrieb Ralf Corsepius: Is GS intended to be a one size fits all solution for both novice users and the workstation target developer user? I don't know if it's aimed at being a one size fits all solution. To me, it's a matter of fact, that in general, there can never ever be such a thing as a one-size fits all solution anywhere. it can and it is known as KDE because KDE is highly configureable but you do not need to configure much to start - but you have the capabilities to adopt the UI to your personal workflow also GNOME tries to make a interface for a desktop as well as for tablets - KDE developers, especially in context Plasma5 realized that this is only a compromise for all usecases the idea is that the UI knows if it runs on a tablet or you connected a docking station with a 27 screen and appears differently ___ http://linux-beta.slashdot.org/story/14/07/16/1355218/kde-releases-plasma-5 Plasma 5.0 improves support for high-DPI displays and ships a converged shell, able to switch between user experiences for different target devices 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 30 December 2014 at 01:26, Rahul Sundaram methe...@gmail.com wrote: Hi On Mon, Dec 29, 2014 at 7:36 PM, Ian Malone wrote: Minor correction, CentOS is unbranded RHEL and Fedora is not RHEL upstream (so far as I am aware anyway). That is incorrect. Fedora is upstream for RHEL and therefore upstream for CentOS as well albeit, one step removed. I stand corrected then. Anyone know when this changed? -- imalone http://ibmalone.blogspot.co.uk -- 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
* Ian Malone [30/12/2014 13:09] : On 30 December 2014 at 01:26, Rahul Sundaram methe...@gmail.com wrote: That is incorrect. Fedora is upstream for RHEL and therefore upstream for CentOS as well albeit, one step removed. I stand corrected then. Anyone know when this changed? This has always been the case. What made you think differently? Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unresponsive maintainer : kanarip
Hi, A bug is open for perl-XML-TreePP since July (for opening a epel 7 branch) with no reaction (https://bugzilla.redhat.com/show_bug.cgi?id=1123681) I need this package so I'm volunteer to maintain it Cheers and seasons greetings Marianne / Jehane -- Marianne (Jehane) Lombard Geekfeminist and sysadmin -- 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: Unresponsive maintainer : kanarip
On Tue, 2014-12-30 at 14:53 +0100, Marianne Lombard wrote: Hi, A bug is open for perl-XML-TreePP since July (for opening a epel 7 branch) with no reaction (https://bugzilla.redhat.com/show_bug.cgi?id=1123681) I need this package so I'm volunteer to maintain it This bug seems unnecessary. AFAIK all it takes to create a branch for a package is a willing maintainer who's already a packager, in this case you, to make a SCM request for it in the package review request https://bugzilla.redhat.com/show_bug.cgi?id=607878 http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requests_for_existing_packages Make sure to list yourself as a owner of the new branch. Its perfectly understandable for a primary POC of a package on the Fedora branches to not want to deal with the EPEL packaging. Regards Yanko Cheers and seasons greetings Marianne / Jehane -- Marianne (Jehane) Lombard Geekfeminist and sysadmin -- 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: Unresponsive maintainer : kanarip
Hi, I have written here because the bug was already 5 month old without a reaction and the package don't seem maintened (upstream is 0.43 and fedora is 0.39 ). I have follow your advice and made a request for epel7 Le 30/12/2014 16:09, Yanko Kaneti a écrit : On Tue, 2014-12-30 at 14:53 +0100, Marianne Lombard wrote: Hi, A bug is open for perl-XML-TreePP since July (for opening a epel 7 branch) with no reaction (https://bugzilla.redhat.com/show_bug.cgi?id=1123681) I need this package so I'm volunteer to maintain it This bug seems unnecessary. AFAIK all it takes to create a branch for a package is a willing maintainer who's already a packager, in this case you, to make a SCM request for it in the package review request https://bugzilla.redhat.com/show_bug.cgi?id=607878 http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requests_for_existing_packages Make sure to list yourself as a owner of the new branch. Its perfectly understandable for a primary POC of a package on the Fedora branches to not want to deal with the EPEL packaging. Regards Yanko Hi, I have written here because the bug is already 5 month old without a reaction and the package don't seem maintained (upstream latest release is 0.43 and fedora package is 0.39 ). I have follow your advice and made a request for epel7. Regards Marianne PS : please excuse the noise, I'm still a newbie packager -- Marianne (Jehane) Lombard Geekfeminist and sysadmin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Troubleshooting systemd timers
It seems that the version of systemd in F20 doesn't have the systemctl list-timers option which makes interrogating timers more difficult. I need a timer that runs daily (with certain prerequisites) but I'm not having any luck. Here's my timer unit: [Unit] Description=Timer for the JSON based schedule grabber for MythTV [Timer] #OnCalendar=*-*-* 00:00:00 #OnCalendar=daily OnUnitActiveSec=1d [Install] WantedBy=network-online.target --- end --- I've tried all 3 of the timer settings above but unless I'm interpreting things incorrectly (could be the case), none of them seem to work. If I use systemctl show to get what information I can I see the following: For OnCalendar=daily (or the the equivalent one above it) I get this: NextElapseUSecMonotonic=0 NextElapseUSecRealtime=44y 11month 4w 1d 10h 30min For the OnUnitActiveSec version I get this: NextElapseUSecMonotonic=1w 2d 23h 6.227254s NextElapseUSecRealtime=0 Neither of those look anything close to 24 hours, though I suppose the 1w one is the closest :) What am I doing wrong? Thanks, 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
Firefox Aurora in rawhide
Would it make sense to include Firefox Aurora / Developer Edition in rawhide? -- 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 30 December 2014 at 13:13, Emmanuel Seyman emman...@seyman.fr wrote: * Ian Malone [30/12/2014 13:09] : On 30 December 2014 at 01:26, Rahul Sundaram methe...@gmail.com wrote: That is incorrect. Fedora is upstream for RHEL and therefore upstream for CentOS as well albeit, one step removed. I stand corrected then. Anyone know when this changed? This has always been the case. What made you think differently? Thought I'd been told otherwise at some point in the past, but must have been a misunderstanding. Had thought they weren't that closely coupled, i.e. not direct forks, but looks like I was wrong. -- imalone http://ibmalone.blogspot.co.uk -- 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: Firefox Aurora in rawhide
It will be great! 2014-12-30 19:09 GMT+03:00 Alexander Ploumistos alex.ploumis...@gmail.com: Would it make sense to include Firefox Aurora / Developer Edition in rawhide? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Kind regards, Vladimir. -- 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 30/12/14 04:07 AM, Ralf Corsepius wrote: On 12/29/2014 04:48 PM, Alec Leamas wrote: Fair enough. But to me, adding GNOME Software (GS) also cannot install compilers, interpreters and other CLI tools creates a more problematic situation. To me, Fedora Workstation w/ Gnome is an incarnation of GnomeOS - An OS aimed at single-user, single-seat, kiosk-style of use-cases, aiming at competing with Android/WinRT, MetroUI and iOS. Only valid with default setting from Live Media. Listed OS above are primarily designed from mobile device in mind with GnomeOS is simply a general purpose combining elements from mobile desktop environments and notably Apple OS X. -- *Luya Tshimbalanga* Fedora Design Team Design Suite spin maintainer -- 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 29/12/14 04:33 AM, Alec Leamas wrote: This certainly works, but is it really a reasonable trade-off in a developer context where things like compilers and interpreters are part of the very core? What role does Gnome Software play here? How fruitful is the idea to hide packages in this context? Compiler and interpreters i.e.Glade having GUI and implements app-data (supposedly mandatory starting on Fedora 22) will be displayed on Gnome Software. Gnome Software is to abstract the package concept to only focus on applications accessible to desktop. The recent inclusion of add-on on Gnome Software brings useful solution like installing Eclipse and select add-on like Java Development Tools. -- *Luya Tshimbalanga* Fedora Design Team Design Suite spin maintainer -- 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 30/12/14 20:57, Luya Tshimbalanga wrote: On 29/12/14 04:33 AM, Alec Leamas wrote: This certainly works, but is it really a reasonable trade-off in a developer context where things like compilers and interpreters are part of the very core? What role does Gnome Software play here? How fruitful is the idea to hide packages in this context? Compiler and interpreters i.e.Glade having GUI and implements app-data (supposedly mandatory starting on Fedora 22) will be displayed on Gnome Software. Glade is neither a compiler nor an interpreter, it's an IDE. Gnome Software is to abstract the package concept to only focus on applications accessible to desktop. Agreed. And I can see some usecases where this makes a lot of sense. But the question then becomes if this is the proper thing to do for the Workstation target user which is a developer. As such, she will in many cases want to install things like gcc, different python stacks using collections, text processing tools and so on. None of which with a GUI. She will also sometimes be interested in multiple desktops for testing etc., causing the MATE apps not visible problem. Bottom line: isn't there is a mismatch between Gnome Software (GUI applications only) and the idea of a developer using both CLI and GUI tools? And if so, how should it be handled? 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: NetBeans Re-Enable
I'll try https://fedorahosted.org/rel-eng/ticket/6071 thank you Mosaab Date: Mon, 29 Dec 2014 20:38:22 +0100 From: punto...@libero.it To: devel@lists.fedoraproject.org Subject: Re: NetBeans Re-Enable Il 29/12/2014 19:56, Itamar Reis Peixoto ha scritto: On Mon, Dec 29, 2014 at 4:36 PM, مصعب الزعبي moc...@hotmail.com wrote: Hi all Netbeans disabled on F16 due to lack of maintainers. I asked to take it on PkgDB No answer .. Regards Mosaab I think you probably needs to file a new review request -- Itamar Reis Peixoto When the package is approved, you need to open an rel-eng request: e.g. https://fedorahosted.org/rel-eng/ticket/6033 -- 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 30/12/14 12:34 PM, Alec Leamas wrote: On 30/12/14 20:57, Luya Tshimbalanga wrote: On 29/12/14 04:33 AM, Alec Leamas wrote: This certainly works, but is it really a reasonable trade-off in a developer context where things like compilers and interpreters are part of the very core? What role does Gnome Software play here? How fruitful is the idea to hide packages in this context? Compiler and interpreters i.e.Glade having GUI and implements app-data (supposedly mandatory starting on Fedora 22) will be displayed on Gnome Software. Glade is neither a compiler nor an interpreter, it's an IDE. My bad. Gnome Software is to abstract the package concept to only focus on applications accessible to desktop. Agreed. And I can see some usecases where this makes a lot of sense. But the question then becomes if this is the proper thing to do for the Workstation target user which is a developer. As such, she will in many cases want to install things like gcc, different python stacks using collections, text processing tools and so on. None of which with a GUI. She will also sometimes be interested in multiple desktops for testing etc., causing the MATE apps not visible problem. What about DevAssistant that comes with Fedora Workstation? Have you tried it? MATE apps not visible means they needed app-data included on their .desktop files hence the pleas from Richard Hughes. The case of multiple desktop installation reaches advanced use territory meaning advanced tool like yumex. Bottom line: isn't there is a mismatch between Gnome Software (GUI applications only) and the idea of a developer using both CLI and GUI tools? And if so, how should it be handled? No. Fedora Workstation already provided needed tools for CLI like Gnome Terminal included by default. -- *Luya Tshimbalanga* Fedora Design Team Design Suite spin maintainer -- 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 30/12/14 22:58, Luya Tshimbalanga wrote: On 30/12/14 12:34 PM, Alec Leamas wrote: On 30/12/14 20:57, Luya Tshimbalanga wrote: On 29/12/14 04:33 AM, Alec Leamas wrote: Gnome Software is to abstract the package concept to only focus on applications accessible to desktop. Agreed. And I can see some usecases where this makes a lot of sense. But the question then becomes if this is the proper thing to do for the Workstation target user which is a developer. [cut] What about DevAssistant that comes with Fedora Workstation? Have you tried it? No, it doesn't seem to solve any problem for me (?). That said, while such solutions certainly might be useful a generic installer application represents some kind of foundation I think all developers will need, sooner or later. Different devs, different ideas, different needs - not all can be shrink-wrapped. MATE apps not visible means they needed app-data included on their .desktop files hence the pleas from Richard Hughes. The case of multiple desktop installation reaches advanced use territory meaning advanced tool like yumex. Still the same question: is there a mismatch between the GUI only Gnome Software (GS) and the Workstation target user presumably using both CLI and GUI tools + perhaps multiple desktops? If you describe this as advanced use, should we read this as if the Workstation developer usecase is too advanced for GS? And if the target usecase is too advanced for GS, what is then the role for GS in the Workstation product? 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
On 30/12/14 22:58, Luya Tshimbalanga wrote: On 30/12/14 12:34 PM, Alec Leamas wrote: On 30/12/14 20:57, Luya Tshimbalanga wrote: Bottom line: isn't there is a mismatch between Gnome Software (GUI applications only) and the idea of a developer using both CLI and GUI tools? And if so, how should it be handled? No. Fedora Workstation already provided needed tools for CLI like Gnome Terminal included by default. Again: this is not about Gnome (I'm an overall happy Gnome user). It's about Gnome Software, the installer, and only that. -- 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
2014-12-30 23:58 GMT+02:00 Luya Tshimbalanga l...@fedoraproject.org: MATE apps not visible means they needed app-data included on their .desktop files hence the pleas from Richard Hughes. Perhaps I couldn't get my thoughts in order when I started this thread, but among the things I wrote was that although MATE apps now have AppData files, they are not visible in gnome-software, because of the GNOME_SOFTWARE_COMPATIBLE_PROJECTS environment variable. -- 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
The Workstation PRD explicitly, more than once states developers of all sorts are the primary target market. The special focus is for a platform for application development. I wonder two things: a.) Should more developer tools be installed by default? 'dnf group list' shows the following items with develop in the group name: C Development Tools and Libraries D Development Tools and Libraries Development Tools RPM Development Tools While 'dnf group list hidden' additional shows Development and Creative Workstation Development Libraries GNOME Software Development Java Development [skipping KDE and Xfce specific items] Legacy Software Development LibreOffice Development Perl Development X Software Development 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? GNOME Software is already smart enough to lump OS updates as a single line item as if it were a metapackage, when actually it's a collection of the current system only related packages available for updating. So there's already a UI/UX precedent for displaying non-applications within Software. 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
Re: How to take ownership of orphaned package: ddclient
On Wed, Dec 24, 2014 at 08:07:37PM +0800, Christopher Meng wrote: On Wed, Dec 24, 2014 at 6:26 PM, Michael Schwendt mschwe...@gmail.com wrote: On Tue, 23 Dec 2014 10:57:14 -0700, Kevin Fenzi wrote: You will need to convince a sponsor to sponsor you. https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group?rd=Extras/HowToGetSponsored Many sponsors like to see you put together a package for review or 'pre' review existing packages in the review queue to show that you know what you are doing. Btw, several sponsors have been burnt by someone new wanting to take over a single orphaned (or even deprecated) package, only to give up shortly afterwards without any notification. :( So, a positive attitude in general and not getting upset too easily by other changes in the dist is a plus if you are serious about becoming a contributor. I will take it back as I was an admin of this package. Incidentally, should I go through the review process again? https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure does not say anything like that. Kees, if you still decide to become a maintainer, when you get sponsored, you can apply for co-maintainership of ddclient. I'm sure cicku will be happy to have a second pair of hands. Best, Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
mygui changed from LGPLv3+ to MIT
The license for mygui changed between 3.2.0 and 3.2.1 from LGPLv3+ to MIT. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1177679] [abrt] slic3r: Perl_hv_undef_flags(): perl killed by SIGABRT
https://bugzilla.redhat.com/show_bug.cgi?id=1177679 Miro Hrončok mhron...@redhat.com changed: What|Removed |Added CC||bugzill...@free.fr Flags||needinfo?(bugzilla77@free.f ||r) --- Comment #9 from Miro Hrončok mhron...@redhat.com --- OK, could you provide the STL file? And tell me how exactly you've imported it? Because there are several ways. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=IagHr2tM7ga=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1177679] [abrt] slic3r: Perl_hv_undef_flags(): perl killed by SIGABRT
https://bugzilla.redhat.com/show_bug.cgi?id=1177679 Francois Cartegnie bugzill...@free.fr changed: What|Removed |Added Flags|needinfo?(bugzilla77@free.f | |r) | --- Comment #10 from Francois Cartegnie bugzill...@free.fr --- Created attachment 974440 -- https://bugzilla.redhat.com/attachment.cgi?id=974440action=edit blender file -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=nJRmq45yCOa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1177679] [abrt] slic3r: Perl_hv_undef_flags(): perl killed by SIGABRT
https://bugzilla.redhat.com/show_bug.cgi?id=1177679 --- Comment #11 from Francois Cartegnie bugzill...@free.fr --- Mistake, was not STL file, but blender OBJ. Opened via Quick Slice -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=SV2mTgeXfsa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1046006] Slic3r crashes on Quick Slice if multiple threads are configured
https://bugzilla.redhat.com/show_bug.cgi?id=1046006 Miro Hrončok mhron...@redhat.com changed: What|Removed |Added CC||bugzill...@free.fr --- Comment #19 from Miro Hrončok mhron...@redhat.com --- *** Bug 1177679 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=W7Kju7wrWPa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1177679] [abrt] slic3r: Perl_hv_undef_flags(): perl killed by SIGABRT
https://bugzilla.redhat.com/show_bug.cgi?id=1177679 Miro Hrončok mhron...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |DUPLICATE Last Closed||2014-12-30 10:19:20 --- Comment #12 from Miro Hrončok mhron...@redhat.com --- This is a known bug. As a workaround, either don't use Quick slice but lode the file to plater, or use only one thread (Print settings - Advanced - Other - Threads). *** This bug has been marked as a duplicate of bug 1046006 *** -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=CYQnYcavmKa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1177819] New: Failed at step NO_NEW_PRIVILEGES spawning /usr/sbin/amavisd: Invalid argument
https://bugzilla.redhat.com/show_bug.cgi?id=1177819 Bug ID: 1177819 Summary: Failed at step NO_NEW_PRIVILEGES spawning /usr/sbin/amavisd: Invalid argument Product: Fedora EPEL Version: epel7 Component: amavisd-new Assignee: juan.o...@miceliux.com Reporter: p...@bieringer.de QA Contact: extras...@fedoraproject.org CC: janfr...@tanso.net, juan.o...@miceliux.com, perl-devel@lists.fedoraproject.org, st...@silug.org, vanmeeuwen+fed...@kolabsys.com Description of problem: Can't start amavisd on a fresh installed CentOS-7 Version-Release number of selected component (if applicable): clamav-filesystem-0.98.5-1.el7.noarch clamav-update-0.98.5-1.el7.x86_64 clamav-data-0.98.5-1.el7.noarch clamav-0.98.5-1.el7.x86_64 clamav-server-systemd-0.98.5-1.el7.noarch clamav-lib-0.98.5-1.el7.x86_64 clamav-server-0.98.5-1.el7.x86_64 amavisd-new-2.9.1-5.el7.noarch How reproducible: Always Steps to Reproduce: # service amavisd start Redirecting to /bin/systemctl start amavisd.service Job for amavisd.service failed. See 'systemctl status amavisd.service' and 'journalctl -xn' for details. Actual results: - clamd started by amavisd - amavisd won't start Dez 30 17:43:14 *** clamd[5375]: Bytecode: Security mode set to TrustSigned. Dez 30 17:43:14 *** amavisd[5380]: Failed at step NO_NEW_PRIVILEGES spawning /usr/sbin/amavisd: Invalid argument Dez 30 17:43:15 *** amavisd[5384]: Failed at step NO_NEW_PRIVILEGES spawning /usr/sbin/amavisd: Invalid argument Dez 30 17:43:15 *** amavisd[5388]: Failed at step NO_NEW_PRIVILEGES spawning /usr/sbin/amavisd: Invalid argument Dez 30 17:43:15 *** amavisd[5392]: Failed at step NO_NEW_PRIVILEGES spawning /usr/sbin/amavisd: Invalid argument Dez 30 17:43:28 *** clamd[5375]: Loaded 3717589 signatures. Expected results: Proper starting of amavisd Additional info: amavisd will start in it's own shell on manual start # su - amavis -s /bin/bash $ /usr/sbin/amavisd -c /etc/amavisd/amavisd.conf Dez 30 17:45:51 *** amavis[5424]: starting. /usr/sbin/amavisd at *** amavisd-new-2.9.1 (20140627), Unicode aware, LC_ALL=de_DE.utf8, ...e_DE.utf8 Dez 30 17:45:52 *** amavis[5425]: Net::Server: Group Not Defined. Defaulting to EGID '997 997' Dez 30 17:45:52 *** amavis[5425]: Net::Server: User Not Defined. Defaulting to EUID '997' Dez 30 17:45:52 *** amavis[5425]: Module Amavis::Conf2.321 ... Dez 30 17:45:52 *** amavis[5425]: Using primary internal av scanner code for ClamAV-clamd Dez 30 17:45:52 *** amavis[5425]: Found secondary av scanner ClamAV-clamscan at /usr/bin/clamscan Dez 30 17:45:52 *** amavis[5425]: Deleting db files __db.002,__db.001,snmp.db,nanny.db,__db.003 in /var/spool/amavisd/db Dez 30 17:45:52 *** amavis[5425]: Creating db in /var/spool/amavisd/db/; BerkeleyDB 0.51, libdb 5.3 # getent passwd amavis amavis:x:997:997:User for amavisd-new:/var/spool/amavisd:/sbin/nologin # getent group amavis amavis:x:997: Looks like the problem is somehown known but no proper solution found so far: http://www.administrator.de/content/print.php?id=257717 Any hints, e.g. how to simulate systemd NoNewPrivileges=true in a shell and check e.g. with strace -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=S3bcCflunQa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
