On 7/17/19 10:00 PM, Emmanuel Seyman wrote:
My initial reaction is that the lists of applications in categories 1 and 2
are very short. My second reaction is that this page doesn't sell me that
I should use Python in any business-critical software...
These categories are not complete at all.
* Nathanael Noblet:
>I have been using a library for awhile now and have been thinking
>of submitting it to Fedora. Part of what I have been doing with it
>was compiling it using -fsanitize=address and leak etc. I’m kinda
>wondering about how that is handled with Fedora packages.
Hi Nathanael,
Nathanael Noblet writes:
> Hello,
>
>I have been using a library for awhile now and have been thinking of
> submitting it to Fedora. Part of what I have been doing with it was compiling
> it using -fsanitize=address and leak etc. I’m kinda wondering about how that
> is
Hi Nathanael,
Nathanael Noblet writes:
> Hello,
>
>I have been using a library for awhile now and have been thinking of
> submitting it to Fedora. Part of what I have been doing with it was compiling
> it using -fsanitize=address and leak etc. I’m kinda wondering about how that
> is
Le mer. 19 juin 2019 à 15:16, Petr Viktorin a écrit :
>
> Hello,
> Back when [Django 2.0] was released in Fedora 28, I took over Django
> 1.11 LTS as some important (to me) packages depended on it. I'm no
> longer interested in maintaining it, so I've orphaned it.
> Let me know if you want to
AsciiBinder was introduced into Fedora to help generate Fedora
documentation. Nevertheless, it has been long replaced by Antora. I
don't have any use for AsciiBinder myself and it is deprecated upstream
(the home page should be switched of on July 31, 2019), therefore I have
orphaned
The outage is done, all our servers are now running Fedora 30 and
everything should work again.
We apologize for any inconvenience caused by the outage.
Jakub
On Tue, Jul 16, 2019 at 10:03 PM Jakub Kadlcik wrote:
>
> There will be an outage starting at 2019-07-18 05:00 UTC, which will last
>
I don't have any use for this library, so I have orphaned it.
Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Hi all,
I would like to ask as Vim co-maintainer, do you find useful for Vim to do:
- when you open new file with .spec suffix, Vim will get you basic spec
file structure?
Recently I found out someone can find it as bad behavior
https://bugzilla.redhat.com/show_bug.cgi?id=1724126 , so I
rubygem-fission + rubygem-CFPropertyList which is its dependency used to
be used by rubygem-fog-* packages. Because these were dropped couple of
months ago, I don't have any other use for
rubygem-{fission,CFPropertyList} therefore I am orphaning them.
On 7/18/19 1:44 PM, Zdenek Dohnal wrote:
> Hi all,
>
> I would like to ask as Vim co-maintainer, do you find useful for Vim to do:
>
> - when you open new file with .spec suffix, Vim will get you basic spec
> file structure?
>
> Recently I found out someone can find it as bad behavior
>
The package jaxen at least since version 1.2.0 no longer includes the
only differently (under W3C) licensed file from the rest (BSD) which
leaves the package with a single license (BSD).
--
Marián Konček
___
devel mailing list --
On 7/18/19 7:44 AM, Zdenek Dohnal wrote:
> Hi all,
>
> I would like to ask as Vim co-maintainer, do you find useful for Vim to do:
>
> - when you open new file with .spec suffix, Vim will get you basic spec
> file structure?
>
> Recently I found out someone can find it as bad behavior
>
A "necessary and sufficient" question on the use of .pc files supplied by
library providers.
1. Package foo-devel installs a pkgconfig .pc file as a convenience to
developers.
2. Package bar requires headers and libraries provided by foo and is both a
build and runtime dependency of foo.3.
Hello, Zdenek Dohnal.
Thu, 18 Jul 2019 13:44:56 +0200 you wrote:
> What's your opinion? Is it useful feature of Vim and it should stay as
> default, or it needs to be disabled?
I think, that *.spec files on Fedora should be treated as RPM SPEC files
by default.
--
Sincerely,
Vitaly Zaitsev
On 7/18/19 3:25 PM, Steven A. Falco wrote:
> On 7/18/19 7:44 AM, Zdenek Dohnal wrote:
>> Hi all,
>>
>> I would like to ask as Vim co-maintainer, do you find useful for Vim to do:
>>
>> - when you open new file with .spec suffix, Vim will get you basic spec
>> file structure?
>>
>> Recently I found
On 7/18/19 3:39 PM, Vitaly Zaitsev via devel wrote:
> Hello, Zdenek Dohnal.
>
> Thu, 18 Jul 2019 13:44:56 +0200 you wrote:
>
>> What's your opinion? Is it useful feature of Vim and it should stay as
>> default, or it needs to be disabled?
> I think, that *.spec files on Fedora should be treated
As stated in
https://docs.fedoraproject.org/en-US/packaging-guidelines/PkgConfigBuildRequires/
pkgconfig(foo) is a more reliable marker of what ships the devel files,
than the package name.
It does not matter if the config process uses pkgconfig or not.
Depending on the package name is
Le 2019-07-18 15:51, Zdenek Dohnal a écrit :
On 7/18/19 3:39 PM, Vitaly Zaitsev via devel wrote:
Hello, Zdenek Dohnal.
Thu, 18 Jul 2019 13:44:56 +0200 you wrote:
What's your opinion? Is it useful feature of Vim and it should stay
as
default, or it needs to be disabled?
I think, that *.spec
Hello, Zdenek Dohnal.
Thu, 18 Jul 2019 15:51:33 +0200 you wrote:
> Even the new .spec files, which do not have to be RPM spec files?
> Because Vim provides spec template for such cases.
I never used this feature, so I think it can be disabled by default. But
syntax highlighting for RPM SPEC
> It does not matter if the config process uses pkgconfig or not.
> Depending on the package name is not a way to state you're not using
> pkgconfig, it's a way to get broken builds when the package you depend
> on gets restructured.
Then the docs should be strengthened to state the case from
On 7/18/19 4:10 PM, Vitaly Zaitsev via devel wrote:
> Hello, Zdenek Dohnal.
>
> Thu, 18 Jul 2019 15:51:33 +0200 you wrote:
>
>> Even the new .spec files, which do not have to be RPM spec files?
>> Because Vim provides spec template for such cases.
> I never used this feature, so I think it can be
On Thu, Jul 18, 2019 at 10:26 AM Philip Kovacs via devel
wrote:
>
> A "necessary and sufficient" question on the use of .pc files supplied by
> library providers.
>
> 1. Package foo-devel installs a pkgconfig .pc file as a convenience to
> developers.
> 2. Package bar requires headers and
Hello,
my name is David Kaspar (a.k.a. Dee'Kej), and I used to be a package
maintainer as a Red Hat employee for 3.5 years. Now that I'm no longer part
of Red Hat I can't use my old Red Hat associated accounts to help with the
work on Fedora...
Therefore I have restored my old 'deekej' FAS
On Thu, 2019-07-18 at 10:25 +0200, Florian Weimer wrote:
> * Nathanael Noblet:
>
> >I have been using a library for awhile now and have been
> > thinking
> >of submitting it to Fedora. Part of what I have been doing with
> > it
> >was compiling it using -fsanitize=address and leak
Le jeu. 18 juil. 2019 à 17:12, Philip Kovacs via devel
a écrit :
>
> > It does not matter if the config process uses pkgconfig or not.
> > Depending on the package name is not a way to state you're not using
> > pkgconfig, it's a way to get broken builds when the package you depend
> > on gets
On 7/18/19 10:28 AM, Zdenek Dohnal wrote:
>
> On 7/18/19 4:10 PM, Vitaly Zaitsev via devel wrote:
>> Hello, Zdenek Dohnal.
>>
>> Thu, 18 Jul 2019 15:51:33 +0200 you wrote:
>>
>>> Even the new .spec files, which do not have to be RPM spec files?
>>> Because Vim provides spec template for such
On Fri, Jul 12, 2019 at 9:07 AM Jerry James wrote:
> I'm down to these 3 still to go: arm-none-eabi-gcc-cs, avr-gcc, and
> cross-gcc. Those gcc builds take a long time. :-) So far the builds
> have gone smoothly.
All the builds have completed without trouble. I did have to patch a
couple of
> "ZD" == Zdenek Dohnal writes:
ZD> Hi all, I would like to ask as Vim co-maintainer, do you find useful
ZD> for Vim to do:
ZD> - when you open new file with .spec suffix, Vim will get you basic
ZD> spec file structure?
Personally I have always found that behavior annoying. If I open a
Welcome back to Fedora. I've clicked the necessary sponsorship buttons.
- J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
There is an effort under way to enhance glibc so that it can use the
Y2038 support in the kernel. The result will be that more 32-bit
architectures can use a 64-bit time_t. (Currently, it's x86-64 x32
only.)
Originally, the plan was to support both ABIs in glibc for building
new applications,
On 7/18/19 4:05 PM, Florian Weimer wrote:
Old binaries with a 32-bit time_t will continue to run, but new
binaries built against a current glibc will always use a 64-bit time_t
under this approach.
How would this affect Wine's handling of 32-bit PE binaries? I'm assuming they will also
break
Anyone else seeing this? It seems to only happen on physical i686
machines, not vm's, but that's based on only three builds so far.
https://koji.fedoraproject.org/koji/taskinfo?taskID=36329825
BUILDSTDERR: create archive failed: cpio: write failed - Cannot allocate
memory
(this is after
Anyone else seeing this? It seems to only happen on physical i686
machines, not vm's, but that's based on only three builds so far.
https://koji.fedoraproject.org/koji/taskinfo?taskID=36329825
BUILDSTDERR: create archive failed: cpio: write failed - Cannot allocate
memory
Very similar
* Michael Cronenworth:
> On 7/18/19 4:05 PM, Florian Weimer wrote:
>> Old binaries with a 32-bit time_t will continue to run, but new
>> binaries built against a current glibc will always use a 64-bit time_t
>> under this approach.
> How would this affect Wine's handling of 32-bit PE binaries?
* Florian Weimer:
> For Fedora, that would affect the i686 architecture only.
It was pointed out off-list that I forgot armhfp. Sorry!
The external pressure to keep armhfp going indefinitely and switch to
a 64-bit time_t is probably larger on armhfp than on i686. The reason
is that new armhfp
On 7/17/19 11:47 PM, William Brown wrote:
On 17 Jul 2019, at 22:36, Mark Reynolds wrote:
On 7/17/19 3:01 AM, Matus Honek wrote:
I think we cannot remove it. Setting the MIN version is a workaround
for *old clients* not even supporting current NSS' default min.
Setting up MAX version is a
https://pagure.io/389-ds-base/pull-request/50505
--
389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://bugzilla.redhat.com/show_bug.cgi?id=1731013
Bug ID: 1731013
Summary: Upgrade perl-Net-Stomp to 0.60
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Net-Stomp
Assignee: lkund...@v3.sk
https://bugzilla.redhat.com/show_bug.cgi?id=1726163
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1720744
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In
https://bugzilla.redhat.com/show_bug.cgi?id=1726163
Fedora Update System changed:
What|Removed |Added
Fixed In Version|fusioninventory-agent-2.5.1 |fusioninventory-agent-2.5.1
42 matches
Mail list logo
