As per the encouragement on the wiki, just wanted to throw out a
greeting. I've been a Linux user for a bit over 10 years now, bouncing
between Fedora and Ubuntu depending on the application. The recent
addition of the MinGW toolkit into Fedora 17 has brought me back, as I
had been trying to
, 21 Jan 2015 06:57:57 +0100
From: Mikolaj Izdebski mizde...@redhat.com
To: devel@lists.fedoraproject.org
Subject: Re: IntelliJ
Message-ID: 54bf3fe5.7070...@redhat.com
Content-Type: text/plain; charset=utf-8
On 01/20/2015 09:41 PM, Greg Hellings wrote:
I'm curious about the possibility
I'm curious about the possibility of bringing IntelliJ/IDEA back into
Fedora. It was there previously, then was taken out sometime around
Fedora 15 or thereabouts. Back then the app was at version 9, it's
currently landed at version 14. With the announcement of Gradle making
an improved landing in
;devel@lists.fedoraproject.org>
> Message-ID: <d00a45ad-8a00-7811-0e4a-6533d1326...@gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> On 06/01/2016 05:24 PM, Greg Hellings wrote:
>> I'm looking into a bug filed against one of my applications (BZ:
>> http
I'm looking into a bug filed against one of my applications (BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=1330096). The complaint is
that the gnome-software application picks up the xiphos-common package
when the user tries to install from there, rather than picking up the
actual GUI packages
I'm working with a package (rubygem-minitest) which already exists in
the core EL packages on the 4.x series. In order to enable a whole
slew of new packages to be created in EPEL7, it will be necessary to
package the 5.x series. However, since we don't want to mask the EL
package it has been
Neal,
I've tried reaching him at the email address listed on his account, which is
via a public provider. I was unaware of his website. I will try reaching out
across that medium as well. Thanks.
--Greg
--
devel mailing list
devel@lists.fedoraproject.org
I've been trying to reach jstribny(
https://admin.fedoraproject.org/accounts/user/view/jstribny) for a few
weeks regarding commit privileges on EPEL7 to several packages in
pkgdb. Most notable among those are:
rubygem-minitest
rubygem-i18n
rubygem-tzinfo
As yet, I have been unable to produce a
I have three outstanding reviews that I'd like to push through so I
can work out the next layer of my dependency tree. I'd be happy to
swap reviews with someone. Links below:
rubygem-async_sinatra https://bugzilla.redhat.com/show_bug.cgi?id=1310873
rubygem-benchmark-ips
I've been struggling this evening with building a particular package
into the EPEL7 repositories. At first I thought I was just going
bonkers, but I think I've narrowed down a particular behavior's cause.
At least the only cause of it that I can see.
The package in question is
Hi, everyone.
I have three outstanding package reviews that I'd be happy to swap with
anyone who is willing and also in need. Listed in my order of need, they
are:
python-beaker: https://bugzilla.redhat.com/show_bug.cgi?id=1410594
mingw-libdb: https://bugzilla.redhat.com/show_bug.cgi?id=885919
I'm looking to get a review on this package:
https://bugzilla.redhat.com/show_bug.cgi?id=1393947
I'm willing to swap with someone if needed.
--Greg
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
I've been trying to log into pkgdb for the past few days - every time I do,
I get a 500 error response from the id.fedoraproject.org page doing the
SSO. I thought this was a temporary thing, but I first noticed the problem
back on Friday morning and it has persisted through the weekend and into
Marian,
Alas, no luck with that. Nor with using a new browser nor a private mode
window. The error seems to legitimately be coming from the server side.
--Greg
On Mon, Dec 19, 2016 at 9:01 AM, Marian Csontos <mcson...@redhat.com> wrote:
> On 12/19/2016 02:34 PM, Greg Hellings wrote:
I have a trio of reviews looking for reviewers. I'll be happy to swap for
them. Two Python libraries, and an app that depends on them:
python-camel: https://bugzilla.redhat.com/show_bug.cgi?id=1441841
python-yamlordereddictloader:
https://bugzilla.redhat.com/show_bug.cgi?id=1441842
linchpin:
So I have a new package that's gotten through review. Previously requesting
git access was handled by pkgdb.
Where is that functionality now? Is it still there? Is there a new way to
do it under Pagure?
___
devel mailing list --
Is there anyone currently maintaining Vagrant images for Rawhide? I have a
package which builds fine in F25 and F26, but is failing in F27, Rawhide,
etc with linker errors. Rather than chase arbitrary patches repeatedly with
mock, I would love to be able to spin up a quick VM. It would make my
All,
I've been an avid user of the Vagrant Openstack Provider plugin (
https://github.com/ggiamarchi/vagrant-openstack-provider). It seems it is
(or could be) a popular Vagrant plugin, but it is not packaged for Fedora.
There aren't a whole bunch of Vagrant plugins that are packaged in Fedora,
Hey all,
I have two reviews I'd love to get through. They're a dependency chain, but
it's a short one!
https://bugzilla.redhat.com/show_bug.cgi?id=1535291
https://bugzilla.redhat.com/show_bug.cgi?id=1535292
The first one is the dependency, the second one is the leaf node. I'd be
happy to do
I have a package that includes a group of Ansible playbooks embedded into a
Python module. The playbooks include a number of templates that are
designed to be uploaded into remote systems, templated out with appropriate
variables, and then executed on the remote system.
Since the templates are
Igor
On Sun, Feb 18, 2018 at 11:09 AM, Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> If you fixed package(s), found false positive, found missing packages in
> list
> or anything else -- please let me know.
>
>
biblesync
Content-Type: text/plain; charset=utf-8
>
> On Wed, Aug 22, 2018 at 10:06:17PM -0500, Greg Hellings wrote:
> > Recent versions of libgsf (since 1.14.43) have begun to fail to build in
> > MinGW environments. The error is straightforward enough - a function
> > signature d
Recent versions of libgsf (since 1.14.43) have begun to fail to build in
MinGW environments. The error is straightforward enough - a function
signature definition differs between its forward declaration and its
implementation. But I don't see any clear way that it differs. The same
code compiles
I intend to retire the mingw-libdb package. It failed to rebuild in
the latest Rawhide. I have no use for it, anymore, and maintaining
what is, essentially, abandonware by a company with no financial
reason to invest in the software is beyond my desire.
If you're interested in grabbing the
What's the best way to monitor for new releases on a package in copr? I
know the release-monitoring.org has "COPR" as a distribution that it knows
about, but I'm not sure if that's the same as the copr repositories we have
available. I'm also not sure how to tell it which package in which project
Halp!
I'm trying to track down a build error in my package that appears only on
ppc64le architectures in Rawhide. As I have no access to ppc64le machines,
I'm attempting to boot a VM with qemu. But when I get into the system many
of the more useful commands aren't working properly. Like "dnf".
On Thu, Aug 15, 2019 at 3:42 PM Steven Munroe wrote:
> > My qemu boot command is currently:
> > qemu-system-ppc64 -m 2048 -smp 2 -machine pseries -cpu power9 -hda
> -cdrom
>
> Looks like you are running an LE image in the BE machine:
>
> try qemu-system-ppc64le
>
I can't find that executable
that I am orphaning it (and its
>> dependencies) and if nobody takes it over, I will just retire it in a week
>> or so.
>>
>> Thanks,
>> Michal
>>
>> On Thu, Aug 29, 2019 at 7:50 PM Greg Hellings
>> wrote:
>>
>>> The jenkins paca
The jenkins pacakge is fearfully out of date and seems unmaintained. Does
anyone know how to get in touch with the maintainer(s) of the package?
https://bugzilla.redhat.com/show_bug.cgi?id=1560603
--Greg
___
devel mailing list --
Can I adopt python-plumbum?
On Mon, Jul 22, 2019 at 5:27 AM Miro Hrončok wrote:
> On 19. 07. 19 10:52, Miro Hrončok wrote:
> > Hello, I've just orphaned python-CacheControl and
> python-django-countries by the
> > request of the previous maintainer.
>
> Orphaned:
>
> python-rpyc
>
I have what should be a very simple review here. Just a MinGW build of an
existing Fedora package. Anyone looking for something simple, or a quick
swap?
https://bugzilla.redhat.com/show_bug.cgi?id=1827887
--Greg
___
devel mailing list --
On Wed, Sep 2, 2020 at 8:43 AM Vít Ondruch wrote:
>
>
> Dne 02. 09. 20 v 15:18 Greg Hellings napsal(a):
>
> Vit, et al,
>
> My professional need for rubygems ended a while back, and I have no
> personal investment into Ruby.
>
>
> That is perfectly fine.
&g
Vit, et al,
My professional need for rubygems ended a while back, and I have no
personal investment into Ruby. So I would prefer not to take on more Ruby
packages as I don't pay much attention to the space.
--Greg
On Wed, Sep 2, 2020 at 3:38 AM Vít Ondruch wrote:
> Hi Robbie,
>
> I wonder if
I'm sorry, I don't know where the boot media information is kept, otherwise
I would raise my question there, instead. I'm trying to automate the
creation of ppc64le systems. x86_64 ISOs have a 30 second timeout on the
boot menu. ppc64le machines have a 5 second timeout. With the vagaries of
system
On what date is that, again?
--Greg
On Thu, Sep 24, 2020 at 1:35 PM Ben Cotton wrote:
> The Fedora 33 Beta RC1.3 compose[1] is GO and will be shipped live on
> Tuesday, 17 March 2020.
>
> For more information please check the Go/No-Go meeting minutes [2] or log
> [3].
>
> Thank you to everyone
Many thanks!
--Greg
On Fri, Oct 2, 2020 at 1:26 PM Miro Hrončok wrote:
> On 02. 10. 20 20:15, Miro Hrončok wrote:
> > On 02. 10. 20 20:12, Neal Gompa wrote:
> >> On Fri, Oct 2, 2020 at 2:10 PM Greg Hellings
> wrote:
> >>>
> >>> I built an RC1 of
I built an RC1 of my package into Rawhide about 3 weeks ago. I tried to
build RC3 today, but the build failed on the final steps. My package
includes a Python wrapper with Swig and the following file:
%{python3_sitearch}/_Sword.cpython-%{python3_version_nodots}*-%{_arch}-linux-gnu*.so
%{_arch}
Quick question about the Epoch tag in a spec file: I goofed during F34's
rawhide series and packaged an RC of my package with the wrong version name
(1.9.0RC3-1 instead of 1.9.0-0.1) which causes it to sort higher in
ordering than the final 1.9.0-5. From what I can gather, the proper
resolution
> On Tue, Jun 08, 2021 at 03:31:07PM -0500, Greg Hellings wrote:
>
> This problem is because koji ignores the epoch when checking if a build
> version already exists and stores output in directories whose name does
> not contain the epoch. The solution is simply to *also* bump th
> On Tue, Jun 08, 2021 at 03:31:07PM -0500, Greg Hellings wrote:
>
> While you might have no choice, I'd caution that there a few traps
> with using Epoch, not just with Koji. One particular trap is that
> subpackage dependencies like:
>
> %package devel
> ...
&
Susi,
I've updated the repository in GitHub to allow issues to be followed.
How did you install the certificate? I had to go through some of the deep
Windows internals. Clicking the file and adding it directly wasn't enough, but
my machine was also the dev machine so there's lots of things
Fedora 34.
Obviously, it's not released into the Windows Store as that requires more
than just some technical bit wrangling. But if you're feeling adventurous,
and you are sometimes relegated to the world of Windows but want to bring
your Fedora along, you can find it here:
https://github.com/greg
So I built my package a few times for F34 in the Rawhide cycle (e.g.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-90a4c6ba11)
It was rebuilt successfully by releng for F34 (e.g.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1695213)
However, it does not appear in F34 in this
On Tue, Mar 2, 2021 at 6:46 AM Richard W.M. Jones wrote:
> [Adding the devel list, since this change would obviously affect
> several "base" packages.]
>
> On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote:
> > Way back when we first started the mingw project in Fedora we took
44 matches
Mail list logo
