Re: fedup FC20 -> FC21 update conflicts
On 12/10/2014 10:36 PM, Przemek Klosowski wrote: > I imagine there will be fc21 packages for those eventually, so should I file > a bugzilla report on it, or go ahead with > the install and wait for the new versions? If reporting, would it be against > fedup or specific packages? Do not wait. If package is missing in next version of Fedora it was either: 1) removed without replacement. In this case nothing should require it. So it is bug. 2) it was replaced by another package, which forgot to specify correct Provides/Obsoletes. And it is bug as well. So in both cases please file Bugzilla report. However fedup is innocent in this case. If you are unsure which package is the cause, choose the package which requires missing dependency and I'm sure the maintainer will reassign it to correct component. Example of such report is here: https://bugzilla.redhat.com/show_bug.cgi?id=1149675 It is good habit to do "dry upgrade" to Beta or Alpha release and report the issues, so maintainers have time to fix it before final release. I described it here: http://miroslav.suchy.cz/blog/archives/2013/10/07/donate_1_minute_of_your_time_to_test_upgrades_from_f19_to_f20/index.html -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- 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 webrtc support in F21?
Hi, the WebRTC needs the h264 CISCO codec which was disabled in Fedora Firefox, see: https://bugzilla.redhat.com/show_bug.cgi?id=1155499 https://fedorahosted.org/fesco/ticket/1359 If you'd like to use the WebRTC (and Mozilla Hello service) in Fedora Firefox, go to about:config and set those values to "true": media.gmp-gmpopenh264.autoupdate media.gmp-gmpopenh264.enabled media.gmp-gmpopenh264.provider.enabled Ma. On 12/12/2014 03:05 PM, Joachim Backes wrote: Hi all, anybody knows if the webrtc support in firefox will be released in F21? Kind regards Joachim Backes -- 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 webrtc support in F21?
There's also a good page about it: https://fedoraproject.org/wiki/OpenH264 ma. On 12/15/2014 09:12 AM, Martin Stransky wrote: Hi, the WebRTC needs the h264 CISCO codec which was disabled in Fedora Firefox, see: https://bugzilla.redhat.com/show_bug.cgi?id=1155499 https://fedorahosted.org/fesco/ticket/1359 If you'd like to use the WebRTC (and Mozilla Hello service) in Fedora Firefox, go to about:config and set those values to "true": media.gmp-gmpopenh264.autoupdate media.gmp-gmpopenh264.enabled media.gmp-gmpopenh264.provider.enabled Ma. On 12/12/2014 03:05 PM, Joachim Backes wrote: Hi all, anybody knows if the webrtc support in firefox will be released in F21? Kind regards Joachim Backes -- 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: F22 Self Contained Change: Preupgrade Assistant
On 12/11/2014 03:06 PM, Jaroslav Reznik wrote: > = Proposed Self Contained: Preupgrade Assistant = > https://fedoraproject.org/wiki/Changes/Preupgrade_Assistant > > Change owner(s): Petr Hracek > > The Preugrade Assistant is a tool to help people upgrade from one release to > another and be sure to track important manual configuration changes they > performed. I wish self contained features would provided frequently updated Copr repository. To test/contribute to this feature before merged to Fedora. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- 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 webrtc support in F21?
On Fri, Dec 12, 2014 at 7:35 PM, Joachim Backes wrote: > Hi all, > > anybody knows if the webrtc support in firefox will be released in F21? > We use Firefox Hello to do video chat on Fedora 21 :) Kushal -- Fedora Cloud Engineer CPython Core Developer Director Python Software Foundation http://kushaldas.in -- 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: Bad default error policy causes printing issues and BIG usability issues
On Sun, Dec 7, 2014 at 6:56 AM, Samuel Sieb wrote: > > On 12/06/2014 10:29 AM, valent.turko...@gmail.com wrote: > >> Any of these actions is simple uses error but results in permanently >> disabling of priner (Stops printer) and users can't print even when they >> resolve issue that was stopping them from accessing the printer. >> >> Yes, I've run into this a lot. The worst part of it is that if the user > isn't an admin, they can't fix the printer even if they knew where to find > the setting. > Jup, same thing here, I have admin level account and still need to "unlock" printer panel in order to turn printer back on :( Let's continue discussion here: https://bugzilla.redhat.com/show_bug.cgi?id=1171418 -- 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 webrtc support in F21?
Hi, You don't need open264 for webrtc, the only browsers that do webrtc today are Firefox and Chrome and they both use VP8. Open264 is an "in case IE Safari and other MPEG-LA clients eventually do webRTC without VP8" thing (right now they dont want to). And its has a very nasty patent license http://www.openh264.org/BINARY_LICENSE.txt Regards, -- 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: Firefox webrtc support in F21?
On 12/15/2014 09:12 AM, Martin Stransky wrote: the WebRTC needs the h264 CISCO codec Are you sure? I've always assumed that Mozilla was more in the WebM/VP8 camp. -- Florian Weimer / Red Hat Product Security -- 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: F21 downloads repository metadata in 3 places!
On 13 December 2014 at 21:10, Hedayat Vatankhah wrote: > Surprisingly, PackageKit uses its own separate cache. Not surprising at all, when you're familiar with how PackageKit works. PackageKit has to accept transactions from clients and return results very quickly. Just something as simple as SHA'ing a metadata file destroys our latency, which is one of the biggest reasons nobody liked the command-not-found functionality when it was introduced: it was SLOW. This interactive command had to return results in ~100ms, not tens of seconds. By having 100% complete control of a copy of the cache we can keep certain files locked in memory, and we can be aggressive about caching pools of packages. This allows us to achieve the low-latency design required by gnome-software, which is firing off tons of transactions in parallel at startup with expected latency guarantees. Another thing it allows us to do is atomically update the cache, so if we're updating the cache in the background and we get interrupted or the transaction is cancelled to make room for a user-requester "interactive" transaction, we can just continue to use the old cache, and then atomically rename the new location to the proper location and update pools when done. You just can't do this when there are three things fiddling with files behind your back without any co-ordination. Now, if we had a metadata format that was just one file (e.g. primary, other, filelists, etc) smushed into one file (possibly also joined fedora+updates, as the packages expect to be depsolved together) then we could share it with dnf and yum if the promise was to do atomic renames. What can't happen if for yum to just update repomd.xml and primary.xml, leaving the other files in a half-dead and invalid state (the files have indexes to each other internally) and then for the user to launch gnome-software and there be a ~5 minute delay while all the other required files are downloaded and indexes created. Note, if yum or DNF wanted to use the PK cache, it's guaranteed to be valid, complete and up to date, although I'm not sure a dependency from the package manager CLI to PK would be acceptable for their maintainers. 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: Firefox webrtc support in F21?
On 12/15/2014 10:29 AM, Florian Weimer wrote: On 12/15/2014 09:12 AM, Martin Stransky wrote: the WebRTC needs the h264 CISCO codec Are you sure? I've always assumed that Mozilla was more in the WebM/VP8 camp. Yes, I may be wrong here. But it seems to be necessary for the Mozilla Hello service, at least from my short testing. Ma. -- 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 webrtc support in F21?
On 12/15/2014 10:14 AM, Martin Stransky wrote: > There's also a good page about it: > > https://fedoraproject.org/wiki/OpenH264 If h264 is not mandatory for Hello to operate, we could enable it by default by changing the loop:throttled option. 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
rawhide report: 20141215 changes
Compose started at Mon Dec 15 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) [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 [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 [kdeplasma-addons] plasma-wallpaper-marble-4.14.3-1.fc22.i686 requires libmarblewidget.so.19 [mesa] mesa-libd3d-devel-10.5.0-0.devel.6.0d7f4c8.fc22.i686 requires mesa-d3d(x86-32) = 0:10.5.0-0.devel.6.0d7f4c8.fc22 [nwchem] nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1 [openstack-neutron-gbp] openstack-neutron-gbp-2014.2-0.2.acb85f0git.fc22.noarch requires openstack-neutron = 0:2014.2 [pam_mapi] pam_mapi-0.2.0-3.fc22.i686 requires libmapi.so.0 [python-bloom] python-bloom-0.5.15-1.fc22.noarch requires python-rosdistro >= 0:0.4.0 [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-wirb] rubygem-wirb-1.0.3-2.fc21.noarch requires rubygem(paint) < 0:0.9 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.i686 requires libmongoclient.so uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.i686 requires libmongoclient.so [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-utils-20140510-2.fc22.i686 requires libpolyclipping.so.16 Broken deps for x86_64 -- [3Depict] 3Depict-0.0.16-3.fc22.x86_64 requires libmgl.so.7.2.0()(64bit) [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [cab] cab-0.1.9-12.fc22.x86_64 requires cabal-dev [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) [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil >= 0:2.0.0 [kdeplasma-addons] plasma-wallpaper-marble-4.14.3-1.fc22.x86_64 requires libmarblewidget.so.19()(64bit) [mesa] mesa-libd3d-devel-10.5.0-0.devel.6.0d7f4c8.fc22.i686 requires mesa-d3d(x86-32) = 0:10.5.0-0.devel.6.0d7f4c8.fc22 mesa-libd3d-devel-10.5.0-0.devel.6.0d7f4c8.fc22.x86_64 requires mesa-d3d(x86-64) = 0:10.5.0-0.devel.6.0d7f4c8.fc22 [nwchem] nwchem-openmpi-6.3.2-11.fc21.x86_64 requires libmpi_usempi.so.1()(64bit) [openstack-neutron-gbp] openstack-neutron-gbp-2014.2-0.2.acb85f0git.fc22.noarch requires openstack-neutron = 0:2014.2 [pam_mapi] pam_mapi-0.2.0-3.fc22.i686 requires libmapi.so.0 pam_mapi-0.2.0-3.fc22.x86_64 requires libmapi.so.0()(64bit) [python-bloom] python-bloom-0.5.15-1.fc22.noarch requires python-rosdistro >= 0:0.4.0 [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-wirb] rubygem-wirb-1.0.3-2.fc21.noarch requires rubygem(paint) < 0:0.9 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) vfrnav-utils-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) Broken deps for armhfp -- [3Depict] 3Depict-0.0.16-3.fc22.armv7hl requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [avro] avro-mapred-1.7.5-9.fc22.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc22.noarch requires hadoop-client [cab] cab-0.1.9-12.fc22.armv7hl requires cabal-dev [dnssec-ch
sharutils-4.14.2 changes license
Dear sharutils users, be aware that sharutils-4.14.2 changed license from GPLv3+ and LGPLv3+ and (LGPLv3+ or BSD) and LGPLv2+ and Public Domain and GFDL to GPLv3+ and (LGPLv3+ or BSD) and LGPLv2+ and Public Domain and GFDL That's because bundled gnulib changed licensening from LGPLv3+ to GPLv3+. This change will be effective since Fedora 21. -- Petr -- 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: F21 downloads repository metadata in 3 places!
/*Richard Hughes */ wrote on Mon, 15 Dec 2014 09:37:27 +: On 13 December 2014 at 21:10, Hedayat Vatankhah wrote: Surprisingly, PackageKit uses its own separate cache. Not surprising at all, when you're familiar with how PackageKit works. PackageKit has to accept transactions from clients and return results very quickly. Just something as simple as SHA'ing a metadata file destroys our latency, which is one of the biggest reasons nobody liked the command-not-found functionality when it was introduced: it was SLOW. This interactive command had to return results in ~100ms, not tens of seconds. By having 100% complete control of a copy of the cache we can keep certain files locked in memory, and we can be aggressive about caching pools of packages. This allows us to achieve the low-latency design required by gnome-software, which is firing off tons of transactions in parallel at startup with expected latency guarantees. Another thing it allows us to do is atomically update the cache, so if we're updating the cache in the background and we get interrupted or the transaction is cancelled to make room for a user-requester "interactive" transaction, we can just continue to use the old cache, and then atomically rename the new location to the proper location and update pools when done. You just can't do this when there are three things fiddling with files behind your back without any co-ordination. <...> Note, if yum or DNF wanted to use the PK cache, it's guaranteed to be valid, complete and up to date, although I'm not sure a dependency from the package manager CLI to PK would be acceptable for their maintainers. Richard. What I think about this (I'm looking at the distribution level, rather than specific packages): 1. If PK really needs its own *copy* of the cache, that's OK (well, not OK but acceptable), but IMHO it should not download it independently too. I think it should just copy the DNF(librepo) cache if it is considered valid and up-to-date, or ask it to bring its cache up-to-date and then copy the cache atomically to its own cache (preferably using hardlinks if possible). 2. I believe that the use should know, and more importantly be able to control WHEN the repo data is being updated. At the very least, he should be able to specify if the updates are automatic or not using a very user friendly method (probably during/after the installation; or per network connection). 3. I think the repository data management backend should be separate from the frontends (including PK, and dnf cli). Also, I like the idea of having a working cache even when new repodata is being downloaded, and I think it is something that DNF/Yum/... should also do. There were many times that I ended up with a half-updated repo cache which prevented me from using Yum as I didn't want/can let it download whole repodata. Probably this should be filled as a feature request against DNF. 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
Re: F21 downloads repository metadata in 3 places!
On 15 December 2014 at 13:09, Hedayat Vatankhah wrote: > 1. If PK really needs its own *copy* of the cache, that's OK (well, not OK > but acceptable), but IMHO it should not download it independently too. But yum/dnf only download the files it needs for the single operation, and not all the "matching" files, unless you're using "dnf makecache" or something like that. > preferably using hardlinks if possible Yes, hardlinks help for the space-on-disk problem. > 2. I believe that the use should know, and more importantly be able to > control WHEN the repo data is being updated. At the very least, he should be > able to specify if the updates are automatic or not using a very user > friendly method (probably during/after the installation; or per network > connection). At the moment the PK front-ends only download when on wifi or wired. Do you have an actual use-case for per-network configuration? > 3. I think the repository data management backend should be separate from > the frontends (including PK, and dnf cli). PK isn't a front-end, gnome-packagekit and gnome-software are. PK is just the mechanism. 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: F22 Self Contained Change: Preupgrade Assistant
On 12/15/2014 09:18 AM, Miroslav Suchý wrote: On 12/11/2014 03:06 PM, Jaroslav Reznik wrote: = Proposed Self Contained: Preupgrade Assistant = https://fedoraproject.org/wiki/Changes/Preupgrade_Assistant Change owner(s): Petr Hracek The Preugrade Assistant is a tool to help people upgrade from one release to another and be sure to track important manual configuration changes they performed. I wish self contained features would provided frequently updated Copr repository. To test/contribute to this feature before merged to Fedora. Great point. I will do that. -- Best regards / S pozdravem Petr Hracek -- 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: F21 downloads repository metadata in 3 places!
On Mon, Dec 15, 2014 at 2:09 PM, Hedayat Vatankhah wrote: > 2. I believe that the use should know, and more importantly be able to > control WHEN the repo data is being updated. At the very least, he should be > able to specify if the updates are automatic or not using a very user > friendly method (probably during/after the installation; or per network > connection). I can only agree with this. Thanks to this thread I understand why I'd get noticeable slowdowns and bandwidth peaks with tethering. I already had an issue once with a DNF bug that took away a month's worth of bandwidth in one hour by repeatedly downloading packages until my data plan was shut down for the rest of the month. I believe that defaults should not aim for the best case but rather the worst. If my memory serves well (don't get me started) you can easily choose with with windows updates how you want to use it (automatically, on demand, etc) and that's something GUIs could provide. And again, you wouldn't just give a choice between different setups, but also explanations. And I don't mind having automatic background updates as the "recommended" strategy, as long as it comes with explanations on what it means. Command-line users like me can instead have a look at the man and system config (I know I should have done that) but I insist on prudent defaults. We should assume that convenient defaults could hurt other users instead, and especially non power users. Cheers, Dridi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Installation Needs Intelligence
if its the dell wifi its b43 or wl pkgs you need ive run into that before on dells Corey W Sheldon Freelance IT Consultant, Multi-Discipline Tutor 310.909.7672 www.facebook.com/1stclassmobileshine -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQSuBFSFm3MRDADMQUFvE2zeREEV2+mARfGttXR0HmamD3kJJMdRmGrtvHpEgTjK cg8ylpkjRTBOl3pWzrEfoxREnS5Ej6BbGbEdGP8cRgpnACkzVirTDtb6JLatzPzh 4xqpuO6st8ATh7/RkLdsK8R5IzjqvkJ+Q99MGZxBr6w0AaP8KMKe32TU5CzQkSMH hL+sZQlIVa5kiEbsvrYnYVrlvw9YFsHZQ38mxFyg0A4nmt3L+CBFS4LRdaQmsu07 Qr22aeOYdD4fWKkvEtGsy2MtxIOjqljdPk+lBqBiW3qK9J3DfGLQsVBholJFBMvY S6aLj6ITDOezJ36hHNlpQmPMOQLShIkP3/dlq7Y2xhyLY/hXG83Pw6WF7kRzF7vG bSqSDlMlmdnRzulnNtAaE4fzNtBR26oKSfMIwX9NUz4U1wFCVrzrOzEvvU2ZvU3k ZlpyMdm1fCEdXJt/oOWBVa6PH31TTGaYKl8JH2gQ0Z9DixaTmPS56ch3mbRGMqyz 5PzEtzvaM5b3yzMBAN/guLOJVzGKSqHwEMjhfxwDweHiOS50FAXH8i9w8qyVC/sG 4iFlS/yjH6SBm5DEdAKwIbY5EuFexgyVoVDpCZ65VSspDwoiXaHubOfNYUAEkOFJ o/YShNMInmajsB7kTlt5mlqsJlU/xAMGH6Zv+f5GIi2k8aDryZr+rHPHqs3lyCkb 7t7041z5mfy9/rJE+U20aVvBh/uUtSMm78CvmTcwdasskEpsiZR2ScuGUgc4ahlF 61dvEnCN+5mrTtPUQPISxtLGDUMhhrrw75z7LafPF6gFmMT/RLcnbrB1xPxPwxWR m5QpfV6qUNmRoGKnGRlyYkBbLwWRsZRSEtgFHUqb8Y3ghG1rKkEh4paFyPOzbGFo dZOHR4dsTStu41UE1MAdn41VhTjS/mQjI/CQPCIRPscjI64svBjQria3SV0iDqxb +Z3ACGoHdKaUI5TiJhJkjEWUjOunUfSnhR124mf7uEIG/1sHJoYonPKTtYNy2mlB ryZs7kZ3u7V3DV4TPMji3UC8sVV2+9HR2g0xxMEXyTA1AEoQeQIK05BthxX/auoM AKrGRPvY96RfaO9rNSerJGH+7VGpr/O4UxRDytHzRRfDb9PzMjUSspS6DtSMhk1z lB2+riyDwQ9HqgFk2PLgnj0LE/k9IxXDxtjjMAGAM1iBRJCsQZzoXfphOtZzU1bd 6teOAW2lsT+rp/+BwU7YxSLnEj0eFJgZTMAgNblLLzh3Cu53FNPauxdhacklYjj3 LO3d0CAkcHMA0ny+zXVoQupabgFLsgvVoSLqPqWVgrd5vS8gGWwvc+b4Q9YLWYpK qwI9tD6Z5poSbQjJPKJLuJfhiQqMgvjeLZGFnTHe9O5s1+dKInW1DhUH6yq61Exj 0grDevF7vyBBEfxkGVeKPyOd7gy7dXMRUwuaQZZ/yd2vbPv8Vbe4ux5TaltFekYc /F6bPWB2LwGAbxKchl5O9133C4VM6yO9bb0DiMMZFsJIUlIqnkDREgjMA30n2HZ4 Xzg+aho33VMRhzaE+YTZVfmNSZk7VlM4mprFKeBERycOyUNfU0B6hOwtrwrMp6gZ 47Q0Q29yZXkgU2hlbGRvbiAoRmVkb3JhIEtleSkgPHNoZWxkb24uY29yZXlAZ21h aWwuY29tPoiABBMRCAAoBQJUhZtzAhsjBQkB4TOABgsJCAcDAgYVCAIJCgsEFgID AQIeAQIXgAAKCRDpWMXWcYv1l0L9APwJ2famE03OlzpOMddQIxsGEnb6cgb4X8ZE tXNnkfmPZwD9Gt8tXcaLOqiwKjQqyiLRP3SoIqwUAJHe7GciZDZ5A/S5BA0EVIWb cxAQAK6uQCb9BZLnWUTXZAAKDK0qT2BVOzUBefB3YD5Eixtmdf7mqjxSfs2Mci5D rGdNZowgA9HnEeIzqg78giit21UlXhqCOt22hj0eO+Q1F401Dr6RFkkN8yQdVI1D 1UePDZQ/zz/fD0miD9KPQxGr6mwGWbn8it5NFHt1EnZMIYkXfS/TJxaMsrGY6Q2F RLjhQ3f69i0XjqPg1/IFx5C34ds0hw3K47yDTrgqR5pp309FjselYfLkC4z8R6ti TRbaXMwOhGuk56rEYB7Y6uzdxuQvS1zM/qqqmff3VqjwyCpVgTuqUlpiD8k/e2nq HB/ZvrOUWgSqT6NKWBn915DlVB5U95jxLFafopI4N12rsEGW7wIgPolXZ2yU8C4S E5kE84T8ahdHGAP9lHbqPhnA7aO1zuAl6hJB+Dcpt1nbPdqfwWR0FffkUU9kL6Qh CiV2ZiAx6Eqm8i5pM21aTlYo0RUosK4r0xFTDZ7SR7d7EGjmfO5k+YjoUSlqOvIb 2jNg6+ZD9EFzSEq5QHMViFnMsp1j+nEYiL44GIH4NPnQWCc3/p7vdxje3HTC4eBt E4Dp4CkTjX4MpiNrUMw57kjahv/nfITsDUcu4WcMc9e0F8GtfIgy/p3XVsXTqdcm CersMUgFZIbptI/bGwfj713QElkNiah1NGZc52YAmFWO9f4/AAMFD/4mjUWEaW/D plbV2tyo7w4j9cHT89+uz5R/Q/OOUjY6PhoFfAzfRAiBlOVjGba/IiYig0HJoBW8 r1HDrfO8xHCHCA9NXiBrhCLFnGM+T6m5+5YpMz5jnhv+xvudm0Dg5VxLtcBjo0/j OUxIHBEcvm0/H3MgABHJc/vTR5n/hNJ6kGRgfgg37qIruE4GOu7BeNABBW+8IIyP 1mXvQl/zIfokAPiDqW9Rmmuj5znOc+UvOX8CcJU/8YQYNIHtCzISkFGtkcz1spET BL6Bu5WrGbdStHFzoUKpaHQumyaHBBDn0VpJCjiRwf7Gu+LlZ/Wlah4KVo4nhk3k NsonNqOZjK16UZnrMrdK4VIDLxzCtlrmlmbGLuH8YUmmlxuw0Nt9EiYtpFTiNUQq Iplu8Me9O9hZ8ZmzlgJ+0tSzlXELOUUOwIgiQs67c9bEn18pHIln4YyrfCvPlhyw Ke+xXUeGGEXmIrKTjCQrFA9eWs3nPTfTG7xQmGkf93kUZHOJMohDJlpIHQza1uyt lu2s+s8HXiAHOBh6ZbMloL+Rg4M+w5+eKU2abQCW8QC1v9u3OgKWcZ1jZbYyTCyI 8Y7NQyiE/akAXQiUb1MHIezN7QpzHEpGxDyVr3tEYF26deJ8sVBxzd+m2wSWyFlT dPyuTxJJFIRCYtK5wpbPhrDlQfwL5riDzIhnBBgRCAAPBQJUhZtzAhsMBQkB4TOA AAoJEOlYxdZxi/WXW8wA/jWWfofUPZYg3QOquXIR/QDTm/fsQwTx+2vO4nEXRKlq AP0YOSlkGoCbaeFHgX+RU5lVfHzRyONK5T7RcDTcvJD83A== =v6Cq -END PGP PUBLIC KEY BLOCK- On Sun, Dec 14, 2014 at 2:23 AM, Samuel Sieb wrote: > > On 12/12/2014 03:57 AM, Marcin Juszkiewicz wrote: > >> There are still wireless cards which do not work with Linux out of box? >> (assuming that firmware is provided) >> >> The firmware is the problem. There are some Broadcom chipsets that need > firmware to work, but that firmware is not allowed to be distributed. They > might only be found in older laptops now, I've only run into them once or > twice. It would be nice if the installer could at least warn about it. > The wireless will work, but there are some manual steps required to install > the firmware. > > -- > 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: Firefox webrtc support in F21?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/15/2014 11:24 AM, Nikos Roussos wrote: > On 12/15/2014 10:14 AM, Martin Stransky wrote: >> There's also a good page about it: >> >> https://fedoraproject.org/wiki/OpenH264 > > If h264 is not mandatory for Hello to operate, we could enable it > by default by changing the loop:throttled option. > > > Hello seems not currently enabled on Firefox 34.0 (Fedora 21). - -- 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 iQIcBAEBAgAGBQJUjuegAAoJEFyovWBm4V0AMgsQAJyTVGDbfXR3GIBHokdGw3HK /LgXY1UpIXBzZbQm+p8vKC/fX5tIF+kSpLzCLWjHcdCVtgzzWSjbIWU+o2eJDzVG Dt5MeK9v4f1F/8nWIIEuwFghNJKuqO8xTtUJRmt9rn+VfBbuwC6mTohVvObsS73h 9fSsRSPlVToxY3+ePjaew2I+J+TsPdHkzRt8npAUwE0ipsvzFMGuL2X+kWp7ToU7 tjZ7kahIED425aOrrjhoyuSgkZwGzXEZ/qE4Q5O1ObqfxmIHzODT/DJh0dHaZKQn 6mkrjIiQsGTUFu2RUmbPQMQiea2EjX8sUn9wTSvpRU4qZNYwg365xPTjiNBMAlQY fC+KmE8qyLtghnCIWDXeO6+N9FxPfbdOGBfjil1zvgFoDHeo90yXwIYaiYYDUv5F 42KsVHcp6rpHg5s3qiWuz5FRfxbv/6xHUX8JQvAkLFdlHe7sqc2DJKFDe6+QF4Rc PZBgOVA/rpYjG1FyYSovIm8vt1x2VJP9XBNXifJ/ZMh61sxjMg0MwZjUkXFyk4S/ MqOn/QArgGsOotmvCSGTrBkateVxAIoCVqN6rjtFTV2UKTrSr1Y+3D6XfAaIiBNI 2A1zHQawMu2Zu+JrqLobZ/BVvsSBNSt7r6YoaRRPFgCe4ZmvOU1F+Clj3tq7HPNC Tyr2v7lU30I9keFMHGx/ =YLMW -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
yum command dropped from @Core?
It looks as if the 'yum' command has been dropped from the @Core package group in the latest Rawhide. 'dnf' is there. That's all fine -- I was just checking this was an intentional change, because I can't see any commit message about it in comps.git. (It's also possible my Fedora image building script has a mistake and that this is a false alarm, but it's a very simple kickstart and I cannot see the problem ...) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- 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 webrtc support in F21?
On Mon, Dec 15, 2014 at 10:29:25 +0100, Florian Weimer wrote: On 12/15/2014 09:12 AM, Martin Stransky wrote: the WebRTC needs the h264 CISCO codec Are you sure? I've always assumed that Mozilla was more in the WebM/VP8 camp. I believe they were both mandatory (required by the spec) in the end. Though there will be some clients that don't support both for various reasons. -- 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: yum command dropped from @Core?
On Mon, Dec 15, 2014 at 02:03:45PM +, Richard W.M. Jones wrote: > > It looks as if the 'yum' command has been dropped from the @Core > package group in the latest Rawhide. 'dnf' is there. > > That's all fine -- I was just checking this was an intentional change, > because I can't see any commit message about it in comps.git. Ah ha, I think it's this commit: commit 7dce142747f43013fda76704560e6c65889e754b Author: Rahul Sundaram <> Date: Fri Oct 10 13:10:30 2014 -0400 make dnf the default dep resolver Maybe I've not built a Rawhide image since October .. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- 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: F21 downloads repository metadata in 3 places!
Am 15.12.2014 um 14:29 schrieb Richard Hughes: > At the moment the PK front-ends only download when on wifi or wired. > Do you have an actual use-case for per-network configuration? Well I think the whole idea of "wifi === unmetered" is flawed. For example I use a UMTS/Wifi router so I can use multiple devices when I'm on the road (and don't have to bother configuring my Fedora laptop to use the UMTS stick correctly). fs -- 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: yum command dropped from @Core?
On 15. 12. 2014 at 14:03:45, Richard W.M. Jones wrote: > It looks as if the 'yum' command has been dropped from the @Core > package group in the latest Rawhide. 'dnf' is there. > > That's all fine -- I was just checking this was an intentional change, > because I can't see any commit message about it in comps.git. > > (It's also possible my Fedora image building script has a mistake and > that this is a false alarm, but it's a very simple kickstart and I > cannot see the problem ...) Yes, the change was completely intentional, see commit 7dce142747f43013fda76704560e6c65889e754b This is part of the https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF Thanks Jan -- 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: F21 downloads repository metadata in 3 places!
On 12/15/2014 09:38 AM, Felix Schwarz wrote: Am 15.12.2014 um 14:29 schrieb Richard Hughes: At the moment the PK front-ends only download when on wifi or wired. Do you have an actual use-case for per-network configuration? Well I think the whole idea of "wifi === unmetered" is flawed. For example I use a UMTS/Wifi router so I can use multiple devices when I'm on the road (and don't have to bother configuring my Fedora laptop to use the UMTS stick correctly). True, Android has UI inside the "Data Usage" activity, used to tell which network connections are metered (top right menu -> network restrictions) It is perfect because I tether my tablet to my phone internet service, that way the tablet knows it is on a 3G like connection. This is important. This should not be restricted wireless connections, because you can tether via USB, or you can have a 3G modem with an Ethernet port. fs -- 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 webrtc support in F21?
On Mon, Dec 15, 2014 at 9:12 AM, Martin Stransky wrote: > Hi, > > the WebRTC needs the h264 CISCO codec which was disabled in Fedora Firefox, > see: > > https://bugzilla.redhat.com/show_bug.cgi?id=1155499 > https://fedorahosted.org/fesco/ticket/1359 > > If you'd like to use the WebRTC (and Mozilla Hello service) in Fedora > Firefox, go to about:config and set those values to "true": > > media.gmp-gmpopenh264.autoupdate > media.gmp-gmpopenh264.enabled > media.gmp-gmpopenh264.provider.enabled Does it really need the cisco one or any h264 codec (i.e do gstreamer plugins work) ? -- 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: Power consumption with Fedora
- Original Message - > > > - Original Message - > > On Tue, 02 Dec 2014 14:44:59 -0700 > > "Nathanael D. Noblet" wrote: > > > > > On Tue, 2014-12-02 at 21:47 +0100, Jan Kratochvil wrote: > > > > On Tue, 02 Dec 2014 06:30:57 +0100, Nathanael d. Noblet wrote: > > > > > I don't know much about it but I hate how bad my battery life is > > > > > on my laptop... > > > > > > > > My 3 years old Lenovo X220 lasts for 12 hours (powertop reports so) > > > > on Fedora 20 x86_64 with powertop --auto-tune. According to > > > > powertop approx. 5.5W is display backlight and 1W is the rest of > > > > system. > > > > > > > > Just to give a reply that Fedora is not bad on all configs/hardware. > > > > > > Well until yesterday I didn't know that Fedora didn't install / > > > configure any of these packages. I've installed tlp and powertop, I > > > didn't know powertop did anything other than monitor. I'll see what > > > powertop --auto-tune does. I don't even know if the tlp package has > > > enabled anything either. I wonder if having tlp installed and running > > > powertop --auto-tune will conflict / fight each other... > > > > > > Time to try stuff out. > > > > You might also look at tuned... > > > > (I think it was mentioned early in the thread). > > > > tuned-adm profile powersave > > I've probably said this before, but I wouldn't trust tuned one bit, after I > was > told that 1) no measurements were ever taken Well, it's not easy to objectively measure this, results depends heavily on HW, SW, configuration used and things like moon phase - today's HW manage a lot of on its own in FW by utilizing factory algorithms/optimizations, but attempts were made to evaluate efficiency of the powersave profile regularly accross different HW: http://fedoraproject.org/wiki/Test_Day:2013-11-14_Power_management#Basic_2 http://fedoraproject.org/wiki/Test_Day:2013-04-17_Power_Management#Basic_2 http://fedoraproject.org/wiki/Test_Day:2012-10-11_Power_Management#Test_Results http://fedoraproject.org/wiki/Test_Day:2012-04-04_Power_Management#Test_Results https://fedoraproject.org/wiki/Test_Day:2011-09-29_PowerManagement#Test_Results These numbers are not bad at all. The powersave profile is targeted for lowest power consumption. I.e. it throttle down your machine - it sets most of the kernel knobs to "powersave" policy. This can increase you online time if your machine is mostly idle, but it will also increase latency and lowers throughput, so generally balanced profile is better choice for laptop. Patches are welcome, so feel free to do your our measurements/ experiments/scientific research or whatever and provide patches. 2) no attempts to make > beneficial > configurations the defaults were made (which is probably right, given that > they'd > have no data to back it up). > Tuned is tool/framework to ease management of tunings and also provides dbase of well known tunings. You can use it to e.g. fine tune your system for high throughput, then roll-back and re-tune for e.g. low latency. Tunings are also applied to newly added devices. You can use inheritance when constructing your own profiles for your own workloads/scenarios. Great for benchmarking, experiments, for cases when "auto" is simply not good enough and you know what you are doing. Currently the project is receiving mostly patches for performance tuning, but patches for other profiles are also welcome. The goal is to be non distro specific upstream. The goal isn't to press anything to distros defaults regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[POC-change] Fedora packages point of contact updates
Change in package status over the last 168 hours 36 packages were orphaned - bash-completion [el6, el5] was orphaned by scop Programmable completion for Bash https://admin.fedoraproject.org/pkgdb/package/bash-completion ccache [el6, el5] was orphaned by scop C/C++ compiler cache https://admin.fedoraproject.org/pkgdb/package/ccache colordiff [el6, el5] was orphaned by scop Color terminal highlighter for diff files https://admin.fedoraproject.org/pkgdb/package/colordiff geronimo-commonj [f21, f19, master, f20] was orphaned by jhernand CommonJ Specification https://admin.fedoraproject.org/pkgdb/package/geronimo-commonj gnurobbo [f21, f20, master] was orphaned by raphgro Port of an once famous game named Robbo from 1989 https://admin.fedoraproject.org/pkgdb/package/gnurobbo hibernate-validator [f21, f19, master, f20] was orphaned by jhernand Bean Validation 1.1 (JSR 349) Reference Implementation https://admin.fedoraproject.org/pkgdb/package/hibernate-validator javasqlite [f20, f21, f19, master, el6, epel7, el5] was orphaned by scop SQLite Java Wrapper/JDBC Driver https://admin.fedoraproject.org/pkgdb/package/javasqlite jboss-annotations-1.1-api [f21, f19, master, f20] was orphaned by jhernand Common Annotations 1.1 API https://admin.fedoraproject.org/pkgdb/package/jboss-annotations-1.1-api jboss-el-2.2-api [f21, f19, master, f20] was orphaned by jhernand Expression Language 2.2 API https://admin.fedoraproject.org/pkgdb/package/jboss-el-2.2-api jboss-jaxb-2.2-api [f21, f19, master, f20] was orphaned by jhernand Java Architecture for XML Binding 2.2 https://admin.fedoraproject.org/pkgdb/package/jboss-jaxb-2.2-api jboss-jsf-2.1-api [f21, f19, master, f20] was orphaned by jhernand JavaServer Faces 2.1 API https://admin.fedoraproject.org/pkgdb/package/jboss-jsf-2.1-api jboss-jstl-1.2-api [f21, f19, master, f20] was orphaned by jhernand JSP Standard Template Library 1.2 API https://admin.fedoraproject.org/pkgdb/package/jboss-jstl-1.2-api jboss-jts [f19] was orphaned by jhernand Distributed Transaction Manager https://admin.fedoraproject.org/pkgdb/package/jboss-jts jboss-metadata [f21, f19, master, f20] was orphaned by jhernand JBoss Metadata https://admin.fedoraproject.org/pkgdb/package/jboss-metadata jboss-rmi-1.0-api [f21, f19, master, f20] was orphaned by jhernand Java Remote Method Invocation 1.0 API https://admin.fedoraproject.org/pkgdb/package/jboss-rmi-1.0-api jboss-saaj-1.3-api [f21, f19, master, f20] was orphaned by jhernand SOAP with Attachments API for Java 1.3 https://admin.fedoraproject.org/pkgdb/package/jboss-saaj-1.3-api maven-anno-plugin [f21, f19, master, f20] was orphaned by jhernand Maven Annotated Mojo https://admin.fedoraproject.org/pkgdb/package/maven-anno-plugin maven-jaxb2-plugin [f21, f19, master, f20] was orphaned by jhernand Provides the capability to generate java sources from schemas https://admin.fedoraproject.org/pkgdb/package/maven-jaxb2-plugin mojarra [f21, f19, master, f20] was orphaned by jhernand JSF Reference Implementation https://admin.fedoraproject.org/pkgdb/package/mojarra pyftpdlib [f21, f19, master, f20] was orphaned by silas Python FTP server library https://admin.fedoraproject.org/pkgdb/package/pyftpdlib pymongo [el6, el5] was orphaned by silas Python driver for MongoDB https://admin.fedoraproject.org/pkgdb/package/pymongo python-asyncmongo [master, f21, f19, el6, f20] was orphaned by silas An asynchronous Python MongoDB library https://admin.fedoraproject.org/pkgdb/package/python-asyncmongo python-gevent [f21, f19, master, f20] was orphaned by silas A coroutine-based Python networking library https://admin.fedoraproject.org/pkgdb/package/python-gevent python-gflags [f20, f21, f19, master, el6, el5] was orphaned by silas Commandline flags module for Python https://admin.fedoraproject.org/pkgdb/package/python-gflags python-lockfile [el5] was orphaned by silas A platform-independent file locking module https://admin.fedoraproject.org/pkgdb/package/python-lockfile python-mox [f20, f21, f19, master, el6, epel7, el5] was orphaned by silas Mock object framework https://admin.fedoraproject.org/pkgdb/package/python-mox python-redis [f20, f21, f19, master, el6, epel7, el5] was orphaned by silas Python 2 interface to the Redis key-value store https://admin.fedoraproject.org/pkgdb/package/python-redis python-ssh [f19, f20] was orphaned by silas Python SSH2 library https://admin.fedoraproject.org/pkgdb/package/python-ssh python-txamqp [master, f21, f19, el6, f20] was orphaned by silas A Python library for communicating with AMQP peers and brokers using Twisted https://admin.fedoraproject.org/pkgdb/package/python-txamqp relaxn
Re: F21 downloads repository metadata in 3 places!
On 15 December 2014 at 14:08, Felix Schwarz wrote: > Well I think the whole idea of "wifi === unmetered" is flawed. It's as good a metric as we've got. When you set up a personal bridge between UMTS/wifi, or even GPRS/wired there's no metadata on the connection about this kind of setup. If the AP name had some kind of prefix/suffix we could use that as a clue, but I don't think just sticking yet another checkbox into a UI is going to solve this for all people. 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: F21 downloads repository metadata in 3 places!
Am 15.12.2014 um 15:32 schrieb Richard Hughes: On 15 December 2014 at 14:08, Felix Schwarz wrote: Well I think the whole idea of "wifi === unmetered" is flawed. It's as good a metric as we've got. When you set up a personal bridge between UMTS/wifi, or even GPRS/wired there's no metadata on the connection about this kind of setup. If the AP name had some kind of prefix/suffix we could use that as a clue, but I don't think just sticking yet another checkbox into a UI is going to solve this for all people. nothing will do for all people but a checkbox "do not bother me with anyhting related to updates and do not download any metadata until i say *now* look for updates because i do that on my own responibility, when i have time and know my environment" is what a grown up user expects 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: Firefox webrtc support in F21?
On 12/15/2014 03:25 PM, drago01 wrote: On Mon, Dec 15, 2014 at 9:12 AM, Martin Stransky wrote: Hi, the WebRTC needs the h264 CISCO codec which was disabled in Fedora Firefox, see: https://bugzilla.redhat.com/show_bug.cgi?id=1155499 https://fedorahosted.org/fesco/ticket/1359 If you'd like to use the WebRTC (and Mozilla Hello service) in Fedora Firefox, go to about:config and set those values to "true": media.gmp-gmpopenh264.autoupdate media.gmp-gmpopenh264.enabled media.gmp-gmpopenh264.provider.enabled Does it really need the cisco one or any h264 codec (i.e do gstreamer plugins work) ? No Idea. But the video (via Mozilla Hello) must me decoded and encoded which is done bu the cisco codec IMHO. ma. -- 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: F21 downloads repository metadata in 3 places!
On 15 December 2014 at 14:38, Reindl Harald wrote: > ...grown up user expects "grown up" users (whatever that means) can do "gsettings set org.gnome.software download-updates false" 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: F21 downloads repository metadata in 3 places!
Am 15.12.2014 um 15:45 schrieb Richard Hughes: On 15 December 2014 at 14:38, Reindl Harald wrote: ...grown up user expects "grown up" users (whatever that means) can do "gsettings set org.gnome.software download-updates false" what a nice usability 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: F21 downloads repository metadata in 3 places!
On 12/15/2014 10:02 AM, Richard Hughes wrote: On 15 December 2014 at 14:08, Felix Schwarz wrote: Well I think the whole idea of "wifi === unmetered" is flawed. It's as good a metric as we've got. When you set up a personal bridge between UMTS/wifi, or even GPRS/wired there's no metadata on the connection about this kind of setup. If the AP name had some kind of prefix/suffix we could use that as a clue, but I don't think just sticking yet another checkbox into a UI is going to solve this for all people. Android has it http://www.androidcentral.com/how-tag-wifi-access-points-hotspots-your-android-device Windows has it http://www.cnet.com/how-to/how-to-enable-metered-wi-fi-connections-in-windows-8/ Why a Workstation product can't, this is not about adding a setting for just only being extremely flexible, It is a setting that will help users a lot. 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
[perl-Sys-Virt] Update to 1.2.11 release
commit 66c057970a6e2c4c7951ed0391f1438e6ab2c7f5
Author: Daniel P. Berrange
Date: Mon Dec 15 15:39:00 2014 +
Update to 1.2.11 release
perl-Sys-Virt.spec |5 -
sources|2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Sys-Virt.spec b/perl-Sys-Virt.spec
index 6281558..f9a2835 100644
--- a/perl-Sys-Virt.spec
+++ b/perl-Sys-Virt.spec
@@ -1,7 +1,7 @@
# Automatically generated by perl-Sys-Virt.spec.PL
Name: perl-Sys-Virt
-Version:1.2.9
+Version:1.2.11
Release:1%{?dist}%{?extra_release}
Summary:Represent and manage a libvirt hypervisor connection
License:GPLv2+ or Artistic
@@ -59,6 +59,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Mon Dec 15 2014 Daniel P. Berrange - 1.2.11-1
+- Update to 1.2.11 release
+
* Thu Oct 2 2014 Daniel P. Berrange - 1.2.9-1
- Update to 1.2.9 release
diff --git a/sources b/sources
index 755ce5c..ec1b60b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-47327538e8a57cd78e8f16d2b503 Sys-Virt-1.2.9.tar.gz
+366672f8ac4abd2cc814a32fb10fa929 Sys-Virt-1.2.11.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F21 downloads repository metadata in 3 places!
On 15 December 2014 at 15:07, Reindl Harald wrote: > what a nice usability I don't think usability means what you think it means. 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: F21 downloads repository metadata in 3 places!
Am 15.12.2014 um 16:43 schrieb Richard Hughes: On 15 December 2014 at 15:07, Reindl Harald wrote: what a nice usability I don't think usability means what you think it means it means to have options visible and not burried in a windows like GNOME registry - make them visible in a GUI or just stick at plaintext configs 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: Heads up: F21 LLVM rebase
On Sat, 2014-12-13 at 01:51 +0100, Kevin Kofler wrote: > There can be only one version of LLVM in the whole distribution at a time. To be entirely fair this is a failing of upstream LLVM for not using symbol versioning on Linux. On OSX, where clearly most of LLVM's development happens, this isn't an issue because Mach-O's two level namespacing means every imported symbol knows which library it came from. If libLLVM used ELF symbol versions we'd get the same effect, and then you could have llvm 3.5 and 3.6 in the same address space and things would Just Work. I'd submitted a patch for this but it didn't get merged in 3.5, at least partly because gold doesn't support all the same command line options as binutils' ld. I'd make a snarky comment here about how the freedom to choose to use a different linker is clearly a great thing that improves users' lives, and about how mere packaging policy by definition cannot fix implementation bugs, but at this point I feel like I'm screaming at a wall. I'll try again for 3.6. - ajax -- 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: F21 downloads repository metadata in 3 places!
On 12/15/2014 10:15 AM, Richard Hughes wrote: On 15 December 2014 at 14:38, Reindl Harald wrote: ...grown up user expects "grown up" users (whatever that means) can do "gsettings set org.gnome.software download-updates false" Devices designed for not "grown up" users has settings to disable background data/updates over metered connections (iOS, Android, Windows Phone ...). I don't think Apple would find pretty to tell the user to run commands on their iOS device :) 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: ssh problem with pkgs.fedoraproject.org
On Sun, 14 Dec 2014 11:00:15 + Yaniv Bronhaim wrote: > Hey, > > According to > https://lists.fedoraproject.org/pipermail/devel/2014-June/199631.html > disabling selinux should do the trick, in my case it didn't really > help No? The case you are running to is very likely that same one... which has nothing to do with selinux. :) > still getting: ...snip... > It worked few weeks ago.. and I updated my pk in my fas account.. its > not permission failure, so any ideas what can is it ? It's likely denyhosts. Please mail me your external IP address, or file a infrastructure ticket with the IP address and we can get you unblocked. kevin pgp76oGEU58dc.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: Heads up: F21 LLVM rebase
On Thu, 2014-12-11 at 12:16 -0500, Adam Jackson wrote: > I've started staging an LLVM 3.5 rebase in F21. I hope to have > everything built by this Friday and the update available in testing by > Monday. Test feedback would be particularly appreciated on secondary > arches and radeonsi 3D hardware. Well, submitted for testing today anyway: https://admin.fedoraproject.org/updates/gambas3-3.6.1-2.fc21,julia-0.3.3-2.fc21,llvm-3.5.0-4.fc21,mesa-10.4.0-1.20141214.fc21,pocl-0.10-2.fc21,pure-0.62-2.fc21 Presumably that'll bubble out to mirrors tomorrow. - ajax -- 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: F21 downloads repository metadata in 3 places!
Robert Marcano wrote: > I don't know why the time to rebuild rpms is important, updates are now > applied at boot time, so rpms can be rebuilt with smaller nice/ionice > before the user reboots (on Workstation product). Offline updates are only a (mis)feature of the GNOME "Workstation" product. The tools shipped by all the other spins (Apper, Yumex) do immediate updates as always. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 downloads repository metadata in 3 places!
On Mon, 2014-12-15 at 18:01 +0100, Kevin Kofler wrote: > Robert Marcano wrote: > > I don't know why the time to rebuild rpms is important, updates are now > > applied at boot time, so rpms can be rebuilt with smaller nice/ionice > > before the user reboots (on Workstation product). > > Offline updates are only a (mis)feature of the GNOME "Workstation" product. > The tools shipped by all the other spins (Apper, Yumex) do immediate updates > as always. ...which brings this thread to the end of its useful life. If you have constructive suggestions for how to improve detection of 'metered' connections, please direct them to the desktop list, or send patches to the gnome-software component in bugzilla. -- 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: F21 downloads repository metadata in 3 places!
On Mon, Dec 15, 2014 at 01:29:21PM +, Richard Hughes wrote: > At the moment the PK front-ends only download when on wifi or wired. > Do you have an actual use-case for per-network configuration? I'd definitely like to select which wifi connections are used. I don't want to be eating up the coffee shop's bandwidth when I'll be home or at work later in the day, for example. And that's just being a good neighbor; from a more selfish point of view, when I use my phone as a wifi access point I'd like to not use up my limited data plan. -- Matthew Miller Fedora Project Leader -- 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: F21 downloads repository metadata in 3 places!
On Mon, Dec 15, 2014 at 9:38 AM, Matthias Clasen wrote: > On Mon, 2014-12-15 at 18:01 +0100, Kevin Kofler wrote: >> Robert Marcano wrote: >> > I don't know why the time to rebuild rpms is important, updates are now >> > applied at boot time, so rpms can be rebuilt with smaller nice/ionice >> > before the user reboots (on Workstation product). >> >> Offline updates are only a (mis)feature of the GNOME "Workstation" product. >> The tools shipped by all the other spins (Apper, Yumex) do immediate updates >> as always. > > ...which brings this thread to the end of its useful life. To attempt to bring the discussion back to a useful state, would it make sense to have delta repo metadata? Re-downloading 20-ish MB of mostly unchanged package and file lists every day seems inefficient to me. (We'd hopefully implement that *once* and get dnf and PackageKit to use the same copy.) --Andy -- 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: F21 downloads repository metadata in 3 places!
/*Matthias Clasen*/ wrote on Mon, 15 Dec 2014 12:38:54 -0500: On Mon, 2014-12-15 at 18:01 +0100, Kevin Kofler wrote: Robert Marcano wrote: I don't know why the time to rebuild rpms is important, updates are now applied at boot time, so rpms can be rebuilt with smaller nice/ionice before the user reboots (on Workstation product). Offline updates are only a (mis)feature of the GNOME "Workstation" product. The tools shipped by all the other spins (Apper, Yumex) do immediate updates as always. ...which brings this thread to the end of its useful life. If you have constructive suggestions for how to improve detection of 'metered' connections, please direct them to the desktop list, or send patches to the gnome-software component in bugzilla. Just wanted to remind that I would like to see an 'integrated' approach. It doesn't help if PK decides to not download anything but DNF starts to refresh its cache when I'm on a 'metered' connection. Also, any non-user-friendly approach is a no-go. If a first time GNU/Linux user which happens to use Fedora (which is rare these days, at least around me), come and tell me that Fedora has ate his 1 month internet credit, I'd prefer to tell him "Oh, sorry, you should use something like Ubuntu instead" rather than "You should open an application called 'Terminal', run a gsettings command, and then a 'systemctl mask ...' command to mask dnf makecache timer/service using sudo/su"; which will most probably cause him to run away from Fedora anyway (maybe back to Windows)! 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
Re: Fedora Installation Needs Intelligence
On Fri, Dec 12, 2014 at 4:57 AM, Marcin Juszkiewicz wrote: > There are still wireless cards which do not work with Linux out of box? > (assuming that firmware is provided) I haven't checked anything newer than 18 months, but Apple hardware for a long time needs proprietary b43 firmware installed by the user and it's completely non-obvious that this needs to be done and how. The documentation in general is incredibly verbose. So it's a "here baby, learn to swim" kindof experience. And then the reward is no 802.11n support. Ultimately the user would have to go down the road of entirely proprietary drivers for such wireless cards. They still seem to be rather prolific. -- 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: Fedora Installation Needs Intelligence
On Mon, Dec 15, 2014 at 12:48:59 -0700, Chris Murphy wrote: Ultimately the user would have to go down the road of entirely proprietary drivers for such wireless cards. They still seem to be rather prolific. I have one in a laptop I inherited. I just needed to put the firmware in /usr/lib/firmware/b43, I didn't actually have to use a proprietary driver (kernel module). Either way it is still annoying. -- 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: F21 downloads repository metadata in 3 places!
On Mon, Dec 15, 2014, at 02:17 PM, Hedayat Vatankhah wrote: > and then a > 'systemctl mask ...' command to mask dnf makecache timer/service using > sudo/su"; This one should help with that one: https://github.com/rpm-software-management/dnf/pull/186 -- 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: F22 System Wide Change: Change xorg input stack to use libinput
On Sat, Dec 13, 2014 at 10:15:41AM +, Tom Hughes wrote: > On 13/12/14 01:10, Kevin Kofler wrote: > > >An additional objection I have to this change proposal is that libinput > >(deliberately) only implements a small subset of the configurability of the > >old drivers, and thus, if we are going to remove the old drivers entirely, > >we are taking away flexibility from our users. > > Indeed. Is it, for example, still the case that the libinput developers are > refusing to consider things like definable button areas on clickpads so you > can create a proper middle button? Have you filed a bug for it? Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Change xorg input stack to use
On Fri, Dec 12, 2014 at 03:38:04PM +0100, Rave it wrote: > Am Fri, 12 Dec 2014 12:00:07 + > schrieb devel-announce-requ...@lists.fedoraproject.org: > > > Message: 1 > > Date: Thu, 11 Dec 2014 14:42:11 +0100 > > From: Jaroslav Reznik > > To: devel-annou...@lists.fedoraproject.org > > Subject: F22 System Wide Change: Change xorg input stack to use > > libinput > > Message-ID: <4092034.fsnsvv0...@dhcp-0-163.brq.redhat.com> > > Content-Type: text/plain; charset="us-ascii" > > > > = Proposed System Wide Change: Change xorg input stack to use libinput = > > https://fedoraproject.org/wiki/Changes/LibinputForXorg > > > > Change owner(s): Hans de Goede > > > > Replace the current (low-level) input xorg drivers with libinput using the > > xorg-x11-drv-libinput wrapper. > > > > == Detailed Description == > > Currently xorg uses different input drivers depending on the device type. > > This > > makes it impossible to do things like middle button scrolling on the > > trackpoint on laptops where the trackpoint buttons are software-emulated > > buttons on the touchpad. Besides this the xf86-input-synaptics driver was > > never really designed for multi-touch touchpads and this causes various > > issues. > > > > For Wayland we've been working on a new improved input stack, which is to > > be > > shared by all compositors and lives inside libinput. We plan to replace the > > current (low-level) input xorg drivers with libinput using the xorg-x11-drv- > > libinput wrapper. > > > > == Scope == > > Besides xorg changes, this will also require changes to the control panel > > applets for mouse / touchpad configuration in the various desktop > > environments, > > as those all are hardcoded to use the xorg-x11-drv-synaptics specific > > interfaces. > > > > * Proposal owners: > > Package libinput and xorg-drv-input-libinput (done), make sure that > > xorg-drv- > > input-libinput has the necessary config interfaces for control panel > > mouse/touchpad config applets (wip). Write patches for gnome-control-center > > mouse/touchpad capplet. Coordinate with other desktop environments. > > > > * Other developers: > > GNOME: merge the gnome-control-center patches. KDE: limits itself to > > standard > > X11 mouse config interfaces, no changes needed. Other Desktop Environments: > > adjust control-panel code to deal with xorg-x11-drv-libinput, merge these > > changes. > > > > * Release engineering: N/A > > * Policies and guidelines: N/A > > I would be very helpful if you could target a x-server version when > control-center apps should be ready for this change, to help upstreams. > Can we expect that those x-server changes also land in other distro later? > Or is this limited to fedora only? The X server version is independent of this change. You can install and use xorg-x11-drv-libinput right now and while I haven't tested it, the driver probably works with anything newer than F18 or so. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Change xorg input stack to use libinput
On Sat, Dec 13, 2014 at 02:10:18AM +0100, Kevin Kofler wrote: > Jaroslav Reznik posted (and > > Change owner(s): Hans de Goede > wrote): > > > KDE: limits itself to standard X11 mouse config interfaces, no changes > > needed. > > Not true. We ship kcm_touchpad on the KDE spin, which definitely does depend > on synaptics interfaces (search for "synaptics" in: > https://projects.kde.org/projects/playground/utils/kcm-touchpad/repository/revisions/master/entry/src/backends/x11/xlibbackend.cpp > ). > Anything that does not use the synaptics driver is not considered a > touchpad. And kcm_touchpad is also in the process of becoming a core part of > upstream Plasma. (It is currently in the git.kde.org playground.) > > Therefore, porting kcm_touchpad (the rewritten 1.x series we currently ship, > not the old, obsolete, 0.3.x version, please make sure you look at the > correct version) is an essential requirement before we can move away from > the synaptics driver. > > > An additional objection I have to this change proposal is that libinput > (deliberately) only implements a small subset of the configurability of the > old drivers, and thus, if we are going to remove the old drivers entirely, > we are taking away flexibility from our users. You are welcome to file bugs in the freedesktop.org bugzilla (Wayland/libinput) for the feature requests you have. Some of them may be closed as wontfix, but I suspect there are others the case isn't clear-cut. Oh, and if you do so, don't just go through the synaptics/evdev man pages and file a bug for every option in there. I want clear use-cases that justify each features you want us to add. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Change xorg input stack to use libinput
On 15/12/14 21:39, Peter Hutterer wrote: On Sat, Dec 13, 2014 at 10:15:41AM +, Tom Hughes wrote: On 13/12/14 01:10, Kevin Kofler wrote: An additional objection I have to this change proposal is that libinput (deliberately) only implements a small subset of the configurability of the old drivers, and thus, if we are going to remove the old drivers entirely, we are taking away flexibility from our users. Indeed. Is it, for example, still the case that the libinput developers are refusing to consider things like definable button areas on clickpads so you can create a proper middle button? Have you filed a bug for it? Well based on http://who-t.blogspot.co.uk/2014/09/libinput-common-input-stack-for-wayland.html I didn't think there was any point... What I did do after writing my email above was to go and half implement it, mostly to see if it would be feasible to maintain a locally patched libinput. So if you're interested I have code that (hopefully) allows a middle button to exist, but I haven't added any way of configuring that button yet so it's size is just hard coded. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- 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: F22 System Wide Change: Change xorg input stack to use libinput
On Mon, Dec 15, 2014 at 10:38:50PM +, Tom Hughes wrote: > On 15/12/14 21:39, Peter Hutterer wrote: > >On Sat, Dec 13, 2014 at 10:15:41AM +, Tom Hughes wrote: > >>On 13/12/14 01:10, Kevin Kofler wrote: > >> > >>>An additional objection I have to this change proposal is that libinput > >>>(deliberately) only implements a small subset of the configurability of the > >>>old drivers, and thus, if we are going to remove the old drivers entirely, > >>>we are taking away flexibility from our users. > >> > >>Indeed. Is it, for example, still the case that the libinput developers are > >>refusing to consider things like definable button areas on clickpads so you > >>can create a proper middle button? > > > >Have you filed a bug for it? > > Well based on > http://who-t.blogspot.co.uk/2014/09/libinput-common-input-stack-for-wayland.html > I didn't think there was any point... tbh, I'm not a fan of the feature at all, but then again a discussion may be worth having. But I'm not going to have this discussion on this list here. Please file a bug or bring it up on the wayland-devel list, then we can weigh up the pros and cons there. > What I did do after writing my email above was to go and half implement it, > mostly to see if it would be feasible to maintain a locally patched > libinput. > > So if you're interested I have code that (hopefully) allows a middle button > to exist, but I haven't added any way of configuring that button yet so it's > size is just hard coded. fwiw, hardcoding the size is fine IMO. The detail is in the various corner cases though, but if you already have it you're welcome to send it to the wayland list (or attach it to the bug report). Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] Summary/Minutes from today's FPC Meeting (2014-12-11 17:00 - 18:25 UTC)
On Mon, Dec 15, 2014 at 10:18:37AM +0700, Michel Alexandre Salim wrote:
>
>
> On 12/13/2014 12:54 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Dec 12, 2014 at 09:38:52AM -0500, Bastien Nocera wrote:
> >>
> >>
> >> - Original Message -
> >>> On 12/12/2014 03:18 PM, Bastien Nocera wrote:
>
>
> - Original Message -
> > On Fri, Dec 12, 2014 at 09:04:19AM -0500, Bastien Nocera wrote:
> >>>
> > Agreed, a static library is a waste of time. What about a normal
> > shared library? Do you think patches to do that would be accepted?
>
> How does a shared library solve any of those problems?
> >>> I wonder why I have to explain this ;)
> >>>
> >>> It would concentrate/centralize a distributed, undetectable origin of
> >>> bug into one point of maintenance and development.
> >>
> >> It wouldn't solve the problem of not wanting to offer an API to
> >> third-parties...
> > Hi,
> >
> > I understand why upstream did not want to do that, but current
> > situation is not very attractive either. The same piece of library-like
> > code is duplicated in two places in gnome, in cinnamon, and we are talking
> > about duplicating in a fourth place.
> >
> > FPC wants to have it split out and shared. gvc has the last commmit in
> > git 13 months ago. Shouldn't be that much of an issue to split it out.
> >
> Having a static lib that goes against upstream's wishes, and that won't
> be used by the core GNOME applications anyway, seems rather anomalous as
> well.
FPC would prefer it to be a shared lib ("at least a static library").
The goal of prefering shared libs over copied code is twofold:
1. make it easier to update in case of problems or bugs
2. share the code between running applications in memory
For this specific case 2. does not really apply, because it is unlikely
to have two desktops running at the same time.
For point 1., a static lib has slight advantage over a git submodule.
After a change, after the package containing the static lib it is enough
to rebuild dependent packages. So it *is* slightly less work than replacing
the submodule in the sources, but not too much. Because of this, I
don't see too much virtue in making it a static lib.
> On the other hand, given that Cinnamon, Budgie, and other GNOME-related
> external projects are using this internal dependency anyway, I'd say the
> intent of not offering an API to third-parties has already failed... and
> not offering a *stable* API should be obvious enough by offering only a
> static lib. We could even add a README.Fedora file clearly stating that
> this library comes with no API stability guarantee.
I'm not sure if the library being static means anything for API guarantees.
Let's say that gvc is updated (incompatibly) and gnome upstream starts
requiring this newer version. If the gvc static lib is updated, other
consumers of the library cannot be compiled or stop working after a
recompilation. If the library is shared, things fail in the same way
either during compilation or at runtime.
> Seems that we should go back to the FPC, now that the objection from
> upstream (in some cases overlapping with Fedora package maintainers) is
> clear. At the very least, we need a decision on what to do with shared
> internal modules that are not intended to be used by external third
> parties - like libgd and libg-v-c, but I won't be surprised if there are
> others.
>
> - is the current practice acceptable, or (per last week's FPC decision)
> should the use of a static lib be required
> - once such a static lib is made available, is its use optional or
> mandatory for existing / new packages, and what's the timeline for
> requiring dependent packages to build against it
> - or should we have a two-tier policy, with, say, modules from the
> originating project allowed to pull in such dependencies via git
> submodules as per the current practice, but external modules required to
> use the static lib?
>
> With the latter, in the case that, say, individual GNOME modules need to
> be built against different commits of such a shared dependency, they
> still can, while we at least have centralized such dependency's usage by
> external projects.
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
