Re: F24 Self Contained Change: sen - terminal user interface for docker engine
Quoting Jan Kurik (2015-12-07 16:28:22) > = Proposed Self Contained Change: sen - terminal user interface for > docker engine = > https://fedoraproject.org/wiki/Changes/sen--tui-for-docker > > Change owner(s): > * Tomas Tomecek > > sen enables you to manage your containers and images interactively > directly from command line. Interface is similar to htop, alot or tig. > > == Detailed Description == > * it can interactively manage your containers and images: > -- manage? start, stop, restart, kill, delete,... > * you are able to inspect containers and images > * sen can fetch logs of containers and even stream logs real-time > * all buffers support searching and filtering > * sen receives real-time updates from docker when anything changes > -- e.g. if you create a container in another terminal, sen will pick it up > * sen notifies you whenever something happens (and reports slow queries) > * supports a lot of vim-like keybindings (j, k, gg, /, ...) > > == Scope == > Proposal owners: > * package sen to Fedora > * provide an information it's available and documentation how to use > it (maybe via developer portal, or release notes) > > Other developers: N/A (not a System Wide Change) > Release engineering: N/A (not a System Wide Change) > List of deliverables: N/A (not a System Wide Change) > Policies and guidelines: N/A (not a System Wide Change) > Trademark approval: N/A (not needed for this Change) > -- > Jan Kuřík > Platform & Fedora Program Manager > Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic > ___ > devel-announce mailing list > devel-annou...@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org Builds are done and this is available for testing now: https://bodhi.fedoraproject.org/updates/sen-0.1.1-1.fc23 http://koji.fedoraproject.org/koji/buildinfo?buildID=709118 ~~ Tomáš Tomeček Software Engineer Developer Experience UTC+1 (CET) -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: emacs-filesystem
Michael Schwendt writes: > On Mon, 04 Jan 2016 15:35:51 +0100, Jan Synacek wrote: > >> Hello, >> >> long time ago, there was a request to create the emacs-filesystem >> package [1], so other packages could drop their emacs-specific files >> there. I believe it was done the other way around... Those files are >> useless without emacs to begin with. I think packages that have emacs >> snippets / modes should have a "-emacs" subpackage (or something like >> that) that depends on emacs itself. > > Two observations: > > 1) Emacs extensions are to be put into emacs- subpackages, not -emacs. > It's in the %parent-%child naming guidelines. Note that sometimes this > is implemented as virtual package names, i.e. explicit Provides such as > those in desktop-file-utils. Ok. > 2) A dependency on emacs-filesystem is primarily for packages, which store > files in those directories, but which do _not_ need Emacs to be installed. > Splitting off emacs- subpackages is not always the most wise/convenient > choice. Any examples of such packages? I still can't imagine how storing emacs specific stuff into emacs directories without requiring emacs could be useful. Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: emacs-filesystem
Am 05.01.2016 um 11:17 schrieb Jan Synacek: Michael Schwendt writes: 2) A dependency on emacs-filesystem is primarily for packages, which store files in those directories, but which do _not_ need Emacs to be installed. Splitting off emacs- subpackages is not always the most wise/convenient choice. Any examples of such packages? I still can't imagine how storing emacs specific stuff into emacs directories without requiring emacs could be useful any package dropping their snippets into /usr/share/bash-completion/completions/ - i doubt they all require "bash" and/or "bash-completion" but if it is used the completions are present signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Poll: emacs.desktop or emacsclient.desktop?
Which one do you use? Having both is confusing, as noted in [1], so I'm planning to remove one of them. What do you think should be the default? Please, write what *you* think/use, not what you guess that other people might want to use. For me, it's emacs.desktop, since clicking the desktop icon is then simply consitent with the rest of the icons. The emacsclient behavior is just weird. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1175969 Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
rawhide report: 20160105 changes
Compose started at Tue Jan 5 05:15:02 UTC 2016 Broken deps for i386 -- [IQmol] IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0 IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2 [OpenColorIO] OpenColorIO-tools-1.0.9-8.fc23.i686 requires libOpenImageIO.so.1.5 [alliance] alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2 [blender] 1:blender-2.76-2.fc24.i686 requires libOpenImageIO.so.1.5 1:blenderplayer-2.76-2.fc24.i686 requires libOpenImageIO.so.1.5 [eclipse-jbosstools] eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires osgi(org.eclipse.tm.terminal) [fawkes] fawkes-core-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 fawkes-plugin-player-0.5.0-26.fc24.i686 requires libgeos-3.4.2.so fawkes-plugin-xmlrpc-0.5.0-26.fc24.i686 requires libmicrohttpd.so.10 [gnash] 1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-extension-mysql-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:gnash-klash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:gnash-plugin-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0 1:python-gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0 [golang-github-kraman-libcontainer] golang-github-kraman-libcontainer-devel-0-0.4.gitd700e5b.fc24.noarch requires golang(github.com/docker/docker/pkg/netlink) [golang-github-kubernetes-heapster] golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/google/cadvisor/info/v1) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/google/cadvisor/client) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/schema) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/registry) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/pkg) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/coreos/fleet/machine) golang-github-kubernetes-heapster-devel-0.16.1-1.fc24.noarch requires golang(github.com/cor
Re: Poll: emacs.desktop or emacsclient.desktop?
On 05/01/16 10:23, Jan Synacek wrote: For me, it's emacs.desktop, since clicking the desktop icon is then simply consitent with the rest of the icons. The emacsclient behavior is just weird. Agreed, emacs.desktop is the application. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Poll: emacs.desktop or emacsclient.desktop?
On 5 Jan 2016 11:28, "Tom Hughes" wrote: > > On 05/01/16 10:23, Jan Synacek wrote: > >> For me, it's emacs.desktop, since clicking the desktop icon is then >> simply consitent with the rest of the icons. The emacsclient behavior is >> just weird. > > > Agreed, emacs.desktop is the application. > Agreed > Tom > > -- > Tom Hughes (t...@compton.nu) > http://compton.nu/ > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: emacs-filesystem
On Tue, 05 Jan 2016 11:17:15 +0100, Jan Synacek wrote: > > 2) A dependency on emacs-filesystem is primarily for packages, which store > > files in those directories, but which do _not_ need Emacs to be installed. > > Splitting off emacs- subpackages is not always the most wise/convenient > > choice. > > Any examples of such packages? One was given in 1). > I still can't imagine how storing emacs > specific stuff into emacs directories without requiring emacs could be > useful. Well, those packages do more than extending Emacs. They contain things other than the Emacs extension, and those things don't require Emacs. Of course, if you strictly want to split off all Emacs extensions into emacs- packages, it's clear that you cannot imagine a different style of packaging. # dnf list texlive\*|wc -l 5162 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: emacs-filesystem
On 4 January 2016 at 14:35, Jan Synacek wrote: > Hello, > > long time ago, there was a request to create the emacs-filesystem > package [1], so other packages could drop their emacs-specific files > there. I believe it was done the other way around... Those files are > useless without emacs to begin with. I think packages that have emacs > snippets / modes should have a "-emacs" subpackage (or something like > that) that depends on emacs itself. > > The following packages now depend on emacs-filesystem (I have omitted > i686 variants for brevity): > > a2ps-0:4.14-28.fc23.x86_64 > anthy-0:9100h-28.fc23.x86_64 > asymptote-0:2.35-3.fc23.x86_64 > autoconf-0:2.69-21.fc23.noarch > bigloo-0:4.1a-9.2.fc23.x86_64 > clisp-0:2.49-18.20130208hg.fc23.x86_64 > cmake-0:3.3.2-1.fc23.x86_64 > crm114-0:0-10.20100106.fc23.x86_64 > cscope-0:15.8-12.fc23.x86_64 > desktop-file-utils-0:0.22-5.fc23.x86_64 > emacs-common-1:24.5-6.fc23.x86_64 > emacs-pysmell-0:0.7.3-4.fc23.noarch This one (pysmell) is a packaging bug - pure emacs add on packages have no need to install emacs-filesystem (since they require emacs proper). > ftnchek-0:3.3.1-21.fc23.x86_64 > gambit-c-0:4.7.9-1.fc23.x86_64 > git-0:2.5.0-4.fc23.x86_64 > global-0:6.5.1-1.fc23.x86_64 > jflex-0:1.6.1-2.fc23.noarch > libidn-0:1.32-1.fc23.x86_64 > librep-0:0.92.5-1.fc23.x86_64 > mercurial-0:3.5.1-1.fc23.x86_64 > mozc-0:2.17.2077.102-5.fc23.x86_64 > ninja-build-0:1.6.0-1.fc23.x86_64 > nodejs-tern-0:0.7.0-6.fc23.noarch > perl-SystemPerl-0:1.344-2.fc23.x86_64 > pypy-libs-0:4.0.0-3.fc23.x86_64 > pypy3-libs-0:2.4.0-2.fc23.x86_64 > ratpoison-0:1.4.8-2.fc23.x86_64 > reposurgeon-0:3.29-1.fc23.noarch > root-0:5.34.32-5.fc23.x86_64 > rpmdevtools-0:8.6-2.fc23.noarch > tpp-0:1.3.1-19.fc23.noarch > uim-0:1.8.6-8.fc23.x86_64 > why-0:2.35-9.fc23.x86_64 > yast2-devtools-0:3.1.36-2.fc23.noarch > > I think it would be better that these packages had their emacs > subpackages, instead of the other way around. Not only would that make > more sense, but itw would also resolve the WTF moments when installing > unrelated packages that suddenly require emacs-filesystem to be > installed as a dependency. > > Any comments? Maybe there are still people that were involved with the > change? Those unaware of history are doomed to repeat it :) It previously was the case that packages that also shipped support files for emacs were required to ship the emacs bits in a sub-package. However, the result was that very few packagers actually complied, and indeed some just shipped the emacs bits as %docs. The move to using emacs-filesystem (proposed by me) was a move to be consistent with vim and xemacs practices. The packages you are talking about are primarily not emacs add-ons, but packages that also ship a couple of elisp files to provide auxillary emacs support if emacs is present on the system. Pulling in the whole emacs stack in such cases would be overkill. However, having the user have to install endless emacs-foo packages just to install a few elisp files also seemed like overkill. The emacs-filesystem approach was a happy compromise, and already a widely used strategy in Fedora (see vim, xemacs etc). I still think it's the best approach, personally, as splitting out all these little elisp files into their own packages just increases package metadata bloat. Any change to the current situation would need to be agreed with the FPC, and coordinated distro wide. Given that we're only now approaching compliance with the current emacs add-on packaging guidelines, I can imagine some resistance to the change you're proposing. I don't see why there are "WTF moments" when emacs-filesystem i installed - it contains a few directories, and nothing else. For info: https://fedoraproject.org/wiki/Packaging:Emacs -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Poll: emacs.desktop or emacsclient.desktop?
On Tue, 05 Jan 2016 11:23:02 +0100, Jan Synacek wrote: > Which one do you use? Having both is confusing, as noted in [1], so I'm > planning to remove one of them. What do you think should be the default? > Please, write what *you* think/use, not what you guess that other people > might want to use. > > For me, it's emacs.desktop, since clicking the desktop icon is then > simply consitent with the rest of the icons. The emacsclient behavior is > just weird. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1175969 What may be considered confusing at first (and breaks GNOME Shell's New Window feature, too), compared with the normal emacs.desktop file, the emacsclient.desktop file always starts the Emacs server in the background, if not running already. Which means you can access the same buffers from within any Emacs client window. That's a good feature actually. I would have found it more natural to start emacsclient with -c --alternate-editor="emacs", which would only start normal Emacs, if no server is running already. No daemon => no confusion? This could be done in a single emacs.desktop file, but oh well, it may not make all Emacs users happy. Perhaps the requester of that feature can tell more usage scenarios: -> https://bugzilla.redhat.com/665362 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: emacs-filesystem
Jonathan Underwood writes: > On 4 January 2016 at 14:35, Jan Synacek wrote: >> ... >> Any comments? Maybe there are still people that were involved with the >> change? > > Those unaware of history are doomed to repeat it :) That's why I'm asking ;) > It previously was the case that packages that also shipped support > files for emacs were required to ship the emacs bits in a sub-package. > However, the result was that very few packagers actually complied, and > indeed some just shipped the emacs bits as %docs. > > The move to using emacs-filesystem (proposed by me) was a move to be > consistent with vim and xemacs practices. The packages you are talking > about are primarily not emacs add-ons, but packages that also ship a > couple of elisp files to provide auxillary emacs support if emacs is > present on the system. Pulling in the whole emacs stack in such cases > would be overkill. However, having the user have to install endless > emacs-foo packages just to install a few elisp files also seemed like > overkill. The emacs-filesystem approach was a happy compromise, and > already a widely used strategy in Fedora (see vim, xemacs etc). I > still think it's the best approach, personally, as splitting out all > these little elisp files into their own packages just increases > package metadata bloat. This is the explanation I was looking for, thank you! > Any change to the current situation would need to be agreed with the > FPC, and coordinated distro wide. Given that we're only now > approaching compliance with the current emacs add-on packaging > guidelines, I can imagine some resistance to the change you're > proposing. > > I don't see why there are "WTF moments" when emacs-filesystem i > installed - it contains a few directories, and nothing else. > > For info: > > https://fedoraproject.org/wiki/Packaging:Emacs Cheers, -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
F24 Self Contained Change: Cloud MOTD
= Proposed Self Contained Change: Cloud MOTD = https://fedoraproject.org/wiki/Changes/Cloud_MOTD Change owner(s): * Kushal Das After logging in the running Cloud instance, the user should get the pending updates (including security) details as MOTD (message of the day). == Detailed Description == With the help of dnf-automatic package we would want to show all updates including the security updates in the MOTD. Many other major cloud images do the same. The corresponding bug is https://bugzilla.redhat.com/show_bug.cgi?id=995537 == Scope == Proposal owners: To work on implementation of this Change Other developers: N/A (not a System Wide Change) Release engineering: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide 20160105 compose check report
Missing expected images: Kde disk raw armhfp Cloud_atomic disk raw x86_64 Images in this compose but not Rawhide 20160104: Lxde live x86_64 Images in Rawhide 20160104 but not this: Scientific_kde live i386 Games live x86_64 Server disk raw armhfp Scientific_kde live x86_64 Games live i386 Failed openQA tests: 3 of 61 ID: 2463Test: x86_64 workstation_live default_install@uefi URL: https://openqa.fedoraproject.org/tests/2463 ID: 2460Test: x86_64 kde_live default_install URL: https://openqa.fedoraproject.org/tests/2460 ID: 2456Test: i386 kde_live default_install URL: https://openqa.fedoraproject.org/tests/2456 Passed openQA tests: 58 of 61 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fwd: daveisfera's llvm_3.7 copr build of llvm for fedora-21-i386 finished with 'failed'
>From what I gather from the logs, it appears that COPR just choked during this build. Is that true? Or am I missing something else? Thanks, Dave -- Forwarded message -- From: Date: Tue, Jan 5, 2016 at 1:21 AM Subject: daveisfera's llvm_3.7 copr build of llvm for fedora-21-i386 finished with 'failed' To: davejohan...@gmail.com Package: llvm COPR: daveisfera/llvm_3.7 Built by: daveisfera Status: failed ID: 00151514 Logs: Build: https://copr-be.cloud.fedoraproject.org/results/daveisfera/llvm_3.7/fedora-21-i386/llvm/build.log.gz Root: https://copr-be.cloud.fedoraproject.org/results/daveisfera/llvm_3.7/fedora-21-i386/llvm/root.log.gz Copr: https://copr-be.cloud.fedoraproject.org/results/daveisfera/llvm_3.7/fedora-21-i386/build-00151514.log Mockchain: https://copr-be.cloud.fedoraproject.org/results/daveisfera/llvm_3.7/fedora-21-i386/llvm/mockchain.log.gz Results: https://copr-be.cloud.fedoraproject.org/results/daveisfera/llvm_3.7/fedora-21-i386/llvm/ Repodata: https://copr-be.cloud.fedoraproject.org/results/daveisfera/llvm_3.7/fedora-21-i386/repodata/ https://copr.fedoraproject.org/coprs/daveisfera/llvm_3.7/build/151514/ -- You received this message due to your preference settings at https://apps.fedoraproject.org/notifications/daveisfera.id.fedoraproject.org/email/27209 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
wml
Hi, Are there users of website meta-language using fedora? I use it for some projects and thought it would be a useful addition. If you are a user of it please do the review for it at: https://bugzilla.redhat.com/show_bug.cgi?id=1295710 regards, Nikos -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Orphaned Packages in rawhide (2016-01-05)
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Package (co)maintainersStatus Change == cherrytreeorphan, ohaessler, zqfan 4 weeks ago flasm orphan 9 weeks ago ipcalculator orphan, jhrozek8 weeks ago radiusclient-ng orphan, nmav, swilkerson 0 weeks ago tailororphan, sharkcz1 weeks ago yarockorphan, jam3s 4 weeks ago The following packages require above mentioned packages: Depending on: radiusclient-ng (10), status change: 2016-01-05 (0 weeks ago) asterisk (maintained by: jsmith, itamarjp, lbazan, leifmadsen, russellb) asterisk-13.3.2-1.fc23.2.src requires radiusclient-ng-devel = 0.5.6-14.fc23 asterisk-radius-13.3.2-1.fc23.2.i686 requires libradiusclient-ng.so.2 nagios-plugins (maintained by: nb, kmf, mhayden, ondrejj, swilkerson) nagios-plugins-2.0.3-3.fc24.src requires radiusclient-ng-devel = 0.5.6-14.fc23 nagios-plugins-radius-2.0.3-3.fc24.i686 requires libradiusclient-ng.so.2 opensips (maintained by: ivaxer, peter) opensips-1.10.5-8.fc24.src requires radiusclient-ng-devel = 0.5.6-14.fc23 opensips-aaa_radius-1.10.5-8.fc24.i686 requires libradiusclient-ng.so.2 asterisk-gui (maintained by: fantom) asterisk-gui-2.0-11.20120518svn5220.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core (maintained by: jsmith, itamarjp) asterisk-sounds-core-en-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en-alaw-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en-g722-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en-g729-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en-gsm-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en-siren14-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en-siren7-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en-sln16-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en-ulaw-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en-wav-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_AU-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_AU-alaw-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_AU-g722-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_AU-g729-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_AU-gsm-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_AU-siren14-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_AU-siren7-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_AU-sln16-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_AU-ulaw-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_AU-wav-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_GB-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_GB-alaw-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_GB-g722-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_GB-g729-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_GB-gsm-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_GB-siren14-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2 asterisk-sounds-core-en_GB-siren7-1.4.26-2.fc23.noarch requires asterisk = 13.3.2-1.fc23.2
Re: F24 System Wide Change: Suds Jurko Fork (fwd)
I did get a response from Jeff Ortel (Suds upstream and Fedora maintainer) with his input on this proposal (forwarded with his permission). Regards, Scott -- Forwarded message -- Date: Mon, 4 Jan 2016 12:18:45 -0600 From: Jeff Ortel To: Scott Talbert Subject: Re: F24 System Wide Change: Suds Jurko Fork (fwd) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey Scott, No worries. As you know, I am both the upstream and package maintainer. I have not been actively maintaining it for some time now. Mainly because it requires a significant time commitment. A commitment to a thorough understand of a number of complicated specifications (SOAP, WSDL, XSD). A commitment to investigating tickets for root causes and to providing solutions that are supported by specification. A commitment to extensive regression testing against a wide variety of web services and engines that interpret the specifications in slightly different ways. It's easy to change the code in a way the fixes one ticket/bugzilla (web service) but breaks 100 others. I can no longer make this commitment and decided that my involvement would likely do more harm than good. That said, it would be good if python-suds was based on an actively maintained project. I am unfamiliar with how this type if request plays out. My expectation would be that the community (especially dependent packages) would have the opportunity to test against the rebased python-suds in rawhide and somehow vote to proceed. Is this true? How confident are you in making this change? Do you believe the jurko/suds fork has the level of commitment to stability I described above? Please be assured that I welcome the proposed change provided it's best for the entire Fedora community. Further, I appreciate your making the proposal. Thanks, Jeff On 01/04/2016 08:41 AM, Scott Talbert wrote: Hi Jeff, I apologize - I should have contacted you before submitting this proposal. Anyway, I am proposing moving to Jurko's Suds fork in Fedora 24. Do you have any objections or feedback on that change? Do you have any objections to having me at least as a co-maintainer of the package? Thanks, Scott -- Forwarded message -- Date: Mon, 4 Jan 2016 15:01:44 +0100 From: Jan Kurik Reply-To: Development discussions related to Fedora To: devel-annou...@lists.fedoraproject.org, Development discussions related to Fedora Subject: F24 System Wide Change: Suds Jurko Fork = Proposed System Wide Change: Suds Jurko Fork = https://fedoraproject.org/wiki/Changes/Suds_Jurko_Fork Change owner(s): * Scott Talbert Change the python-suds package to use the fork maintained by Jurko Gospodnetić. == Detailed Description == Suds is a SOAP-based web service client for Python which is currently packaged in Fedora as python-suds. This change proposal aims to update the python-suds package to use the fork maintained by Jurko Gospodnetić. Currently Fedora has the original version of Suds which has not been maintained or updated since 2011. The original version does not support Python 3. == Scope == Proposal owners: * Update existing python-suds package to suds-jurko and ensure it builds/works in Rawhide. (NOTE: proposal owner is not currently the maintainer of python-suds, but would intend to assume maintainership as part of this change.) The plan is to use the latest hg snapshot of suds-jurko. * In conjunction with the python-suds dependent package maintainers, help test dependent packages to ensure they work correctly with the new package. Other developers: * For maintainers of packages that depend on python-suds: test the dependent packages to ensure they work correctly with the updated python-suds package. No changes should be needed as the Jurko fork is believed to maintain compatibility with the original Suds. Release engineering: None List of deliverables: None Policies and guidelines: None Trademark approval: N/A (not needed for this Change) -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWireCAAoJEM9lW7UwFwZXLmUP/1ldXNqDorPks+g9/2hBKsyE zdCPhljp/G3YZLw5ph4Z7tU4HyFtUfeiUfBKUFSfGZJuDSqNtNdULZ5hAK4J823E 8rhB3L82VRSlxQGb0Iy0j9hl58BXC8WaXSm1zVThIZ4EWtZhh+gx1otFVmv6AgT6 /a3Mmsv3274x4m3rh3hDXyaKPRNTrv1vl2v5iN+tsqLxduxiGixKn+L5s90JuZ0Z enqqCSjJXgCc3GDlSvP0wK6ernoXVg6F/0rOpw06NH2S0EK90EyaqmijIsP8v44G aXNJ1AKMwm49eFt/g10OufZr9N+UZ5bwcg5Ow/cTSHrRcsADZ+esf4Hqpae5y8wU +HOnXZwTrCYiM112SQQAKeuEPcWPEdi8SXycIga2hgBhNS7PumHmLi/hBsJqi4so 0u5e+dB82OAiOdCmBGA5Oo2FOp26Le4lvbWzj28F6gOLFJTZkStSSOLuxF8bPMmi QPNZOdejZewRr+UzxszVAckDGTUfFMRzx7AK1owm1f2MjSuTn0R7cgnjISbvC/fH 2PLvMFtiAKcY+j/kIlslGAI8HRDfXOmK1VFLsdTlmR0uPugBTv2OhJKNo7mHNHM3 u8bMxR4ctoH+vcg65tQUniSZIKgwaEfklZTVprDtNnuH9e0NAtfbW0tMiQXmAifW 4g5JA1Eo2C4BlBrcUl+y =mgK4 -END PGP SIGNATURE--- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Specs using %define
On Thu, Dec 24, 2015 at 03:01:02PM -0600, Jason L Tibbitts III wrote:
> coccinelle (rjones)
coccinelle.spec has:
%{!?python_sitelib: %define python_sitelib %(%{__python} -c "from
distutils.sysconfig import get_python_lib; print get_python_lib()")}
TBH I have no idea if this is correct or not, or perhaps should be
completely removed. Thoughts?
> mingw-atk (rjones, epienbro, kalev)
Fixed.
> mingw-freetype (rjones, lfarkas, epienbro)
This uses:
%{!?_with_subpixel_rendering: %{!?_without_subpixel_rendering: %define
_without_subpixel_rendering --without-subpixel_rendering}}
_without_subpixel_rendering is not used anywhere else in the file.
No idea if that is right or not.
> mingw-gdk-pixbuf (epienbro, rjones, sailer)
> mingw-glib2 (fidencio, rjones, epienbro, lfarkas, sailer, kalev, elmarco)
> mingw-glibmm24 (sailer, elmarco, rjones)
> mingw-libgcrypt (rjones, epienbro)
> mingw-liboil (lfarkas, rjones)
> mingw-libsoup (epienbro, rjones)
> mingw-pangomm (sailer, rjones)
> mingw-pango (rjones, epienbro, kalev)
All done.
> mingw-libvirt (berrange, rjones, elmarco)
I didn't feel confident in changing this one. I compared the
mingw-libvirt.spec file and ordinary libvirt.spec, and both use
%define extensively for with_* settings. I assume there must be some
reason for that.
> nekovm (rjones, andyli)
Done.
> ocaml-ancient (rjones)
> ocamldsort (rjones)
> ocaml-omake (rjones)
Done.
> qemu (jforbes, dwmw2, berrange, quintela, ehabkost, amitshah, alon, rjones,
> bonzini, crobinso)
I was told off the last time I broke qemu.spec, so I didn't
modify this :-) It uses %define 7 times.
> unison213 (rjones, gemi)
> unison227 (rjones, gemi, brummbq)
> unison240 (brummbq, rjones)
All done.
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
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: xpad update 4.6.0
On Sun, 20 Dec 2015 23:42:58 - " mastaiza" wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1114370 > https://bugzilla.redhat.com/show_bug.cgi?id=1114007 > https://bugzilla.redhat.com/show_bug.cgi?id=1285277 Christoph is likely busy... but I'm happy to co-maintain, so I just requested acls on it and will look at pushing out an update soon. > It created a feeling that does not touch the gnome and the server is > secondary. and certainly with regard RedHad. I'm afraid I can't parse this... kevin pgpZ9NQjq22tg.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 Self Contained Change: sen - terminal user interface for docker engine
On Mon, Dec 7, 2015 at 9:28 AM, Jan Kurik wrote: > = Proposed Self Contained Change: sen - terminal user interface for > docker engine = > https://fedoraproject.org/wiki/Changes/sen--tui-for-docker > > Change owner(s): > * Tomas Tomecek > > sen enables you to manage your containers and images interactively > directly from command line. Interface is similar to htop, alot or tig. +1 - I've been following sen on github for a little while now. I think this would be great to have in Fedora. -AdamM > > == Detailed Description == > * it can interactively manage your containers and images: > -- manage? start, stop, restart, kill, delete,... > * you are able to inspect containers and images > * sen can fetch logs of containers and even stream logs real-time > * all buffers support searching and filtering > * sen receives real-time updates from docker when anything changes > -- e.g. if you create a container in another terminal, sen will pick it up > * sen notifies you whenever something happens (and reports slow queries) > * supports a lot of vim-like keybindings (j, k, gg, /, ...) > > == Scope == > Proposal owners: > * package sen to Fedora > * provide an information it's available and documentation how to use > it (maybe via developer portal, or release notes) > > Other developers: N/A (not a System Wide Change) > Release engineering: N/A (not a System Wide Change) > List of deliverables: N/A (not a System Wide Change) > Policies and guidelines: N/A (not a System Wide Change) > Trademark approval: N/A (not needed for this Change) > -- > Jan Kuřík > Platform & Fedora Program Manager > Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic > ___ > devel-announce mailing list > devel-annou...@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Specs using %define
On 01/05/2016 07:16 PM, Richard W.M. Jones wrote:
On Thu, Dec 24, 2015 at 03:01:02PM -0600, Jason L Tibbitts III wrote:
coccinelle (rjones)
coccinelle.spec has:
%{!?python_sitelib: %define python_sitelib %(%{__python} -c "from
distutils.sysconfig import get_python_lib; print get_python_lib()")}
TBH I have no idea if this is correct or not, or perhaps should be
completely removed. Thoughts?
That's one of those cases where using %define is actually *wrong*
because of the macro scoping thing. But in practise it'll never get used
since these days %python_sitelib is always defined so its not just wrong
but also pointless as well.
mingw-atk (rjones, epienbro, kalev)
Fixed.
mingw-freetype (rjones, lfarkas, epienbro)
This uses:
%{!?_with_subpixel_rendering: %{!?_without_subpixel_rendering: %define
_without_subpixel_rendering --without-subpixel_rendering}}
_without_subpixel_rendering is not used anywhere else in the file.
No idea if that is right or not.
Another case where %define is actually wrong. The whole construct looks
like a workaround for %bcond related misunderstanding, but dunno.
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: daveisfera's llvm_3.7 copr build of llvm for fedora-21-i386 finished with 'failed'
On Tue, Jan 5, 2016 at 8:08 AM, Dave Johansen wrote: > From what I gather from the logs, it appears that COPR just choked during > this build. Is that true? Or am I missing something else? > Thanks, > Dave > https://copr.fedoraproject.org/coprs/daveisfera/llvm_3.7/build/151593/ I rebuilt and it succeeded, so I believe that confirms that it was just a hiccup in COPR. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
mock fails to do rawhide builds on CentOS 7
I was testing an update to a package and the mock build worked just fine when doing builds on EL 7 and Fedora 22/23, but failed with the following error when trying to do a rawhide build: ~> mock -r fedora-rawhide-x86_64 --rebuild ~/rpmbuild/SRPMS/hgsubversion-1.8.4-1.el7.centos.src.rpm INFO: mock.py version 1.2.13 starting (python version = 2.7.5)... ERROR: invalid literal for float(): 7.2.1511 Traceback (most recent call last): File "/usr/sbin/mock", line 833, in main() File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py", line 84, in trace result = func(*args, **kw) File "/usr/sbin/mock", line 620, in main buildroot = Buildroot(config_opts, uidManager, state, plugins) File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py", line 84, in trace result = func(*args, **kw) File "/usr/lib/python2.7/site-packages/mockbuild/buildroot.py", line 55, in __init__ self.pkg_manager = PackageManager(config, self, plugins) File "/usr/lib/python2.7/site-packages/mockbuild/package_manager.py", line 20, in PackageManager version = float(version) ValueError: invalid literal for float(): 7.2.1511 What can I do to help resolve this issue? Thanks, Dave -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: mock fails to do rawhide builds on CentOS 7
On Tue, Jan 5, 2016 at 12:25 PM, Dave Johansen wrote: > I was testing an update to a package and the mock build worked just fine > when doing builds on EL 7 and Fedora 22/23, but failed with the following > error when trying to do a rawhide build: > ~> mock -r fedora-rawhide-x86_64 --rebuild > ~/rpmbuild/SRPMS/hgsubversion-1.8.4-1.el7.centos.src.rpm > INFO: mock.py version 1.2.13 starting (python version = 2.7.5)... > ERROR: invalid literal for float(): 7.2.1511 > Traceback (most recent call last): > File "/usr/sbin/mock", line 833, in > main() > File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py", > line 84, in trace > result = func(*args, **kw) > File "/usr/sbin/mock", line 620, in main > buildroot = Buildroot(config_opts, uidManager, state, plugins) > File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py", > line 84, in trace > result = func(*args, **kw) > File "/usr/lib/python2.7/site-packages/mockbuild/buildroot.py", line 55, > in __init__ > self.pkg_manager = PackageManager(config, self, plugins) > File "/usr/lib/python2.7/site-packages/mockbuild/package_manager.py", > line 20, in PackageManager > version = float(version) > ValueError: invalid literal for float(): 7.2.1511 > > What can I do to help resolve this issue? > Nevermind, this was resolved in a recent update to mock: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-a295f19cae -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Attempting to contact unresponsive maintainer - jklimes
Greetings, we've been told that the email addresses for this package maintainer is no longer valid. I'm starting the unresponsive maintainer policy to find out if they are still interested in maintaining their packages (and if so, have them update their email addresses in FAS). If they're not interested in maintaining or we can't locate them I'll have FESCo orphan the packages so that others can take them over. If you have a way to contact this maintainer, please let them know that we'd appreciate knowing what to do with their packages. Thanks! * jklimes - former email: jkli...@redhat.com Point of contact: rpms/mobile-broadband-provider-info -- Mobile broadband provider database ( master f23 f22 ) Co-maintainer: rpms/ModemManager -- Mobile broadband modem management service ( master f23 f22 ) rpms/NetworkManager -- Network connection manager and user applications ( master f23 f22 ) rpms/NetworkManager-openvpn -- NetworkManager VPN plugin for OpenVPN ( master f23 f22 ) rpms/NetworkManager-pptp -- NetworkManager VPN plugin for PPTP ( master f23 f22 ) rpms/NetworkManager-vpnc -- NetworkManager VPN plugin for vpnc ( master f23 f22 ) rpms/network-manager-applet -- A network control and status applet for NetworkManager ( master f23 f22 ) rpms/wpa_supplicant -- WPA/WPA2/IEEE 802.1X Supplicant ( master f23 f22 ) kevin pgp9RMSULSdWU.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
ARM help needed
paraview is failing to build on arm:
/builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:
In function '__cpuid':
/builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:95:3:
error: impossible constraint in 'asm'
asm volatile("cpuid" : "=a"(out[0]), "=b"(out[1]), "=c"(out[2]),
"=d"(out[3])
^
/builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:
In function 'check_xcr0_ymm':
/builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:124:3:
error: unknown register name '%edx' in 'asm'
__asm__("xgetbv" : "=a" (xcr0) : "c" (0) : "%edx");
^
/builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:
In function 'get_cpu_features':
/builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:124:3:
error: unknown register name '%edx' in 'asm'
__asm__("xgetbv" : "=a" (xcr0) : "c" (0) : "%edx");
^
Would someone familiar with arm assembly be willing to take a look?
Unfortunately this is a generated file, but I've attached at copy.
Does arm even implement cpuid?
Thanks.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
/*=
Program: ParaView
Module:pv-forward.c.in
Copyright (c) Kitware, Inc.
All rights reserved.
See Copyright.txt or http://www.paraview.org/HTML/Copyright.html for details.
This software is distributed WITHOUT ANY WARRANTY; without even
the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the above copyright notice for more information.
=*/
#define vtksys_SHARED_FORWARD_DIR_BUILD "/builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/bin"
#define vtksys_SHARED_FORWARD_PATH_BUILD "/builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/bin"
#define vtksys_SHARED_FORWARD_PATH_INSTALL "../lib/paraview"
#define vtksys_SHARED_FORWARD_EXE_BUILD "/builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/bin/paraview-config"
#define vtksys_SHARED_FORWARD_EXE_INSTALL "../lib/paraview/paraview-config"
#define vtksys_SHARED_FORWARD_OPTION_PRINT "--print"
#define vtksys_SHARED_FORWARD_OPTION_LDD "--ldd"
#include
#include
#include
#include
#include
/* CPU features */
static const int CPU_FEATURE_SSE= 1 << 0;
static const int CPU_FEATURE_SSE2 = 1 << 1;
static const int CPU_FEATURE_SSE3 = 1 << 2;
static const int CPU_FEATURE_SSSE3 = 1 << 3;
static const int CPU_FEATURE_SSE41 = 1 << 4;
static const int CPU_FEATURE_SSE42 = 1 << 5;
static const int CPU_FEATURE_POPCNT = 1 << 6;
static const int CPU_FEATURE_AVX= 1 << 7;
static const int CPU_FEATURE_F16C = 1 << 8;
static const int CPU_FEATURE_RDRAND = 1 << 9;
static const int CPU_FEATURE_AVX2 = 1 << 10;
static const int CPU_FEATURE_FMA3 = 1 << 11;
static const int CPU_FEATURE_LZCNT = 1 << 12;
static const int CPU_FEATURE_BMI1 = 1 << 13;
static const int CPU_FEATURE_BMI2 = 1 << 14;
static const int CPU_FEATURE_KNC= 1 << 15;
/* cpuid[eax=0].ecx */
static const int CPU_FEATURE_BIT_SSE3 = 1 << 0;
static const int CPU_FEATURE_BIT_SSSE3 = 1 << 9;
static const int CPU_FEATURE_BIT_FMA3 = 1 << 12;
static const int CPU_FEATURE_BIT_SSE4_1 = 1 << 19;
static const int CPU_FEATURE_BIT_SSE4_2 = 1 << 20;
static const int CPU_FEATURE_BIT_MOVBE = 1 << 22;
static const int CPU_FEATURE_BIT_POPCNT = 1 << 23;
static const int CPU_FEATURE_BIT_XSAVE = 1 << 26;
static const int CPU_FEATURE_BIT_OXSAVE = 1 << 27;
static const int CPU_FEATURE_BIT_AVX= 1 << 28;
static const int CPU_FEATURE_BIT_F16C = 1 << 29;
static const int CPU_FEATURE_BIT_RDRAND = 1 << 30;
/* cpuid[eax=1].edx */
static const int CPU_FEATURE_BIT_SSE= 1 << 25;
static const int CPU_FEATURE_BIT_SSE2 = 1 << 26;
/* cpuid[eax=0x8001].ecx */
static const int CPU_FEATURE_BIT_LZCNT = 1 << 5;
/* cpuid[eax=7,ecx=0].ebx */
static const int CPU_FEATURE_BIT_BMI1 = 1 << 3;
static const int CPU_FEATURE_BIT_AVX2 = 1 << 5;
static const int CPU_FEATURE_BIT_BMI2 = 1 << 8;
#if defined(__i386__) && defined(__PIC__)
void __cpuid(int out[4], int op)
{
asm volatile ("xchg{l}\t{%%}ebx, %1\n\t"
"cpuid\n\t"
"xchg{l}\t{%%}ebx, %1\n\t"
: "=a"(out[0]), "=r"(out[1]), "=c"(out[2]), "=d"(out[3])
: "0"(op));
}
void __cpuid_count(int out[4], int op1, int op2)
{
asm volatile ("xchg{l}\t{%%}ebx, %1\n\t"
"cpuid\n\t"
"xchg{l}\t{%%}ebx, %1\n\t"
: "=a" (out[0]), "=r" (out[1]), "=c" (out[2]), "=d" (out[3])
Re: ARM help needed
That's all x86 assembly, not ARM.
It looks like all that program is doing is trying to select a bundled
software mesa implementation. None of those are probably included in the
Fedora build anyway, I'd suggest patching to not build that executable
at all.
On 01/05/2016 06:12 PM, Orion Poplawski wrote:
> paraview is failing to build on arm:
>
> /builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:
>
> In function '__cpuid':
> /builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:95:3:
>
> error: impossible constraint in 'asm'
>asm volatile("cpuid" : "=a"(out[0]), "=b"(out[1]), "=c"(out[2]),
> "=d"(out[3])
>^
> /builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:
>
> In function 'check_xcr0_ymm':
> /builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:124:3:
>
> error: unknown register name '%edx' in 'asm'
>__asm__("xgetbv" : "=a" (xcr0) : "c" (0) : "%edx");
>^
> /builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:
>
> In function 'get_cpu_features':
> /builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:124:3:
>
> error: unknown register name '%edx' in 'asm'
>__asm__("xgetbv" : "=a" (xcr0) : "c" (0) : "%edx");
>^
>
> Would someone familiar with arm assembly be willing to take a look?
> Unfortunately this is a generated file, but I've attached at copy.
>
> Does arm even implement cpuid?
>
> Thanks.
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: ARM help needed
On 01/05/2016 07:26 PM, Thomas Daede wrote:
That's all x86 assembly, not ARM.
It looks like all that program is doing is trying to select a bundled
software mesa implementation. None of those are probably included in the
Fedora build anyway, I'd suggest patching to not build that executable
at all.
Thanks, I've ripped that all out.
On 01/05/2016 06:12 PM, Orion Poplawski wrote:
paraview is failing to build on arm:
/builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:
In function '__cpuid':
/builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:95:3:
error: impossible constraint in 'asm'
asm volatile("cpuid" : "=a"(out[0]), "=b"(out[1]), "=c"(out[2]),
"=d"(out[3])
^
/builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:
In function 'check_xcr0_ymm':
/builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:124:3:
error: unknown register name '%edx' in 'asm'
__asm__("xgetbv" : "=a" (xcr0) : "c" (0) : "%edx");
^
/builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:
In function 'get_cpu_features':
/builddir/build/BUILD/ParaView-v5.0.0-RC3-source/fedora/CommandLineExecutables/paraview-config-forward.c:124:3:
error: unknown register name '%edx' in 'asm'
__asm__("xgetbv" : "=a" (xcr0) : "c" (0) : "%edx");
^
Would someone familiar with arm assembly be willing to take a look?
Unfortunately this is a generated file, but I've attached at copy.
Does arm even implement cpuid?
Thanks.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
