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 interactive
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... Th
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
ch
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 i
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
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/
--
d
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.
>
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
> > choic
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 beg
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
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 th
= 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
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
Fai
>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
fi
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.fedoraproje
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 y
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 Wi
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, o
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 ac
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 int
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()
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
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.
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
> ~/
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 int
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 co
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 w
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 a
28 matches
Mail list logo
