Re: Use of Epoch/improper ordering
> 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
> ...
> Requires: %{name}%{?_isa} = %{version}-%{release}
>
> will break because the dependency should be:
>
> Requires: %{name}%{?_isa} = %{epoch}:%{version}-%{release}
>
> More insidious is that things like:
>
> Obsoletes: oldpackage < %{version}-%{release}
>
> will silently do the wrong thing.
Oops, good catch! I've updated that and rebuilt again.
>
> If you had the choice of moving to upstream 1.9.1, I'd do that instead.
Unfortunately, upstream only releases on their own timetable and this can
sometimes be years between versions. I was hoping to use that, as well, but
with 1.9.0 out just in Autumn of last year it's unlikely we'll see a 1.9.1
before the Fedora 36 release going by past releases. Upstream mostly just
builds off of SVN HEAD for their own purposes and development moves very slowly.
--Greg
>
> Rich.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Use of Epoch/improper ordering
> 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 the release > tag to '6'. This makes koji see it is as a new build and the epoch change > makes the RPM upgrade path happy. > > Regards, > Daniel Ah, you are a gentleperson and a scholar. Thank you! --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora for WSL
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 that would be different. If you either reply here or file an issue on the tracker, I can try to replicate what you've done in a clean Windows VM. --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Use of Epoch/improper ordering
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 for this is to add an Epoch tag to the SRPM file and build 1:1.9.0-5. However, adding the epoch tag seems to have no effect. When I try to build, I'm told version 1.9.0-5 is already built for Rawhide/Fedora 34. Is there a way to claw back the improperly versioned 1.9.0RC3 package from ages ago? Is there some magic to enable the Epoch tag that I'm missing? How do I get 1.9.0 final package out into Fedora? TIA --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora for WSL
I may be hair-brained to do this, but I've put together an installer for Fedora on WSL. It mostly follows the procedures that had been much talked about in a blog post about running Fedora 33 in the WSL2, but it uses the direct installer rather than the manual side-loads. It also will install 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-hellings/FedoraWSL Am I crazy? Yep. Does it work? "Works in dev." Anything to watch out for? It uses the trustywolf/wslu COPR repository for installing WSL integration packages. Otherwise it's just raw Fedora bits. Feel free to flame me if this was a terrible idea. --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Where'd my package builds go?
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 version (1.9.0-3) but instead in a version from 2 months before my last build and 4 months before the releng build (1.9.0RC3-1 from last August). Neither do any of the newer builds live in Rawhide. What am I doing wrong that my package has happily built, but apparently never made it into Rawhide or F34? Those later builds, up through 1.9.0-2, are in F33. Is there some additional step that's new in the F34 cycle that I missed, that I need to do? I'm executing a rebuild of the package so I can push it through Bodhi, but the previous versions also went through there but never appeared on mirrors. --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Merging mingw specs into native spec
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 the
> > decision to maintain the mingw builds as separate source RPMs in Fedora.
> > The rationale was that mingw support was a new concept to Fedora with
> > many unknowns. We often had custom mingw only patches, and there was a
> > decent chance there would be breakage upon rebases. We didn't want to
> > burden the native package maintainers with mingw support as that would
> > have increased pushback against the effort.
> >
> > This decision was always going to cause us problems with keeping the
> > mingw dist-git packages in sync with native dist-git packages. This
> > is especially important when it comes to security fixes, and there
> > have been reasonably well justified complaints about mingw lagging
> > native wrt to CVE fixing in recent times.
> >
> >
> > Since the early days we merged the separate mingw32-$PKG / mingw64-$PKG
> > source RPMS into a single mingw-$PKG in dist-git. The need for patching
> > mingw RPMs to fix problems in Fedora doesn't seem any higher than the
> > need for patching to fix native build problem. Generally things just
> > work when rebasing, because most upstreams recognize the importance
> > of keeping their projects working on mingw.
> >
> > IOW, we were afraid of a maintainer burden that has turned out to
> > largely not exist. To address this non-existant burden, we intentionally
> > made the maint of mingw packages harder than it needs to be in Fedora.
> >
> >
> > This is a long winded way of saying I think it is time to update
> > the mingw packaging guidelines to allow for, even recommend, mingw
> > packaging to be a standard part of the native RPM spec. In doing
> > so we eliminate the main burden of mingw packaging in Feora and
> > guarantee that we'll always be up to date wrt bug/security fixes
> > and rebases.
> >
> > I've done some basic tests with libvirt-glib upstream which recently
> > changed to using Meson. Supporting mingw in the main libvirt-glib.spec
> > was largely trivial. I simply needed to copy the various blocks of
> > the mingw-libvirt-glib.spec file into the libvirt-glib.spec, ending
> > up with a diff:
> >
> > diff --git a/libvirt-glib.spec.in b/libvirt-glib.spec.in
> > index 58e6242..81f972b 100644
> > --- a/libvirt-glib.spec.in
> > +++ b/libvirt-glib.spec.in
> > @@ -1,5 +1,15 @@
> > # -*- rpm-spec -*-
> >
> > +%bcond_without mingw
> > +
> > +%define _with_mingw 0
> > +%if 0%{?fedora}
> > +%define _with_mingw 0%{with mingw}
> > +%endif
> > +
> > +%define mingw32_pkg_name mingw32-%{name}
> > +%define mingw64_pkg_name mingw64-%{name}
> > +
> > Name: libvirt-glib
> > Version: @VERSION@
> > Release: 1%{?dist}
> > @@ -16,6 +26,16 @@ BuildRequires: libxml2-devel
> > BuildRequires: vala-tools
> > BuildRequires: gettext
> >
> > +%if %{_with_mingw}
> > +BuildRequires: mingw32-filesystem
> > +BuildRequires: mingw64-filesystem
> > +BuildRequires: mingw32-glib2
> > +BuildRequires: mingw64-glib2
> > +BuildRequires: mingw32-libvirt
> > +BuildRequires: mingw64-libvirt
> > +%endif
> > +
> > +
> > %package devel
> > Summary: libvirt glib integration for events development files
> > Requires: %{name} = %{version}-%{release}
> > @@ -37,6 +57,42 @@ Requires: libvirt-gconfig-devel =
> %{version}-%{release}
> > Requires: libvirt-gobject = %{version}-%{release}
> > Requires: libvirt-devel
> >
> > +
> > +%if %{_with_mingw}
> > +
> > +%package -n mingw32-libvirt-glib
> > +Summary: MingwGW Windows libvirt-gconfig virtualization library
> > +BuildArch: noarch
> > +Requires: pkgconfig
> > +
> > +%package -n mingw32-libvirt-gconfig
> > +Summary: MingwGW Windows libvirt-gconfig virtualization library
> > +BuildArch: noarch
> > +Requires: pkgconfig
> > +
> > +%package -n mingw32-libvirt-gobject
> > +Summary: MingwGW Windows libvirt-gobject virtualization library
> > +BuildArch: noarch
> > +Requires: pkgconfig
> > +
> > +%package -n mingw64-libvirt-glib
> > +Summary: MingwGW Windows libvirt-gconfig virtualization library
> > +BuildArch: noarch
> > +Requires: pkgconfig
> > +
> > +%package -n mingw64-libvirt-gconfig
> > +Summary: MingwGW Windows libvirt-gconfig virtualization library
> > +BuildArch: noarch
> > +Requires: pkgconfig
> > +
> > +%package -n mingw64-libvirt-gobject
> > +Summary: MingwGW Windows libvirt-gobject virtualization library
> > +BuildArch: noarch
> > +Requires: pkgconfig
> > +
> > +%endif
> > +
> > +
> > %description
> > This package provides integration between libvirt and the glib
> > event loop.
> > @@ -61,6 +117,31 @@ objects
> > This package provides development header files and libraries for
> > managing virtualization host objects
> >
> > +%if %{_with_mingw}
> > +
> > +%description -n mingw32-libvirt-glib
> > +MinGW Windows
Re: PPC64LE vs PowerPCLE64
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 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} is "ppc64le" as expected. But today, koji can't find the
> file.
> >>> Looking through the logs[0] I see this line in the install step:
> >>>
> >>> copying
> >>> build/lib.linux-ppc64le-3.9/_Sword.cpython-39-powerpc64le-linux-gnu.so
> ->
> >>>
> /builddir/build/BUILDROOT/sword-1.9.0RC3-1.fc34.ppc64le/usr/lib64/python3.9/site-packages
>
> >>>
> >>>
> >>> So now the generated file is "powerpc64le", but %{_arch} is still
> ppc64le.
> >>> That .so file gets generated and built during a "python setup.py
> >>> build/install" process. I'm not naming that file anywhere in the spec.
> So has
> >>> the naming scheme intentionally changed for Python bindings? Or is
> this a bug
> >>> that I should escalate and report somewhere? Upstream in the library
> I'm
> >>> packaging? Upstream in Fedora? Python?
> >>>
> >>
> >> This change is from this Fedora 34 Change:
> >>
> https://fedoraproject.org/wiki/Changes/Python_Upstream_Architecture_Names
> >>
> >> There are new macros defined for this, indicated here:
> >>
> https://fedoraproject.org/wiki/Changes/Python_Upstream_Architecture_Names#New_Macros
> >>
> >
> > That reminded me I wanted to send some PRs for this.
> >
> > Thanks.
> >
>
> https://src.fedoraproject.org/rpms/sword/pull-request/4
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
PPC64LE vs PowerPCLE64
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} is "ppc64le" as expected. But today, koji can't find the file.
Looking through the logs[0] I see this line in the install step:
copying build/lib.linux-ppc64le-3.9/_
Sword.cpython-39-powerpc64le-linux-gnu.so ->
/builddir/build/BUILDROOT/sword-1.9.0RC3-1.fc34.ppc64le/usr/lib64/python3.9/site-packages
So now the generated file is "powerpc64le", but %{_arch} is still ppc64le.
That .so file gets generated and built during a "python setup.py
build/install" process. I'm not naming that file anywhere in the spec. So
has the naming scheme intentionally changed for Python bindings? Or is this
a bug that I should escalate and report somewhere? Upstream in the library
I'm packaging? Upstream in Fedora? Python?
--Greg
[0] https://kojipkgs.fedoraproject.org//work/tasks/4976/52654976/build.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Beta is GO
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 who has and still is working on this release! > Subsequent schedule milestones[4] are unchanged. The Final Freeze > begins on 6 October. > > [1] https://dl.fedoraproject.org/pub/alt/stage/33_Beta-1.3/ > [2] > https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-24/f33-beta-go_no_go-meeting.2020-09-24-17.00.html > [3] > https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-24/f33-beta-go_no_go-meeting.2020-09-24-17.00.log.html > [4] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to > devel-announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Non-responsive maintainer: domcleal
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. > > > So I would prefer not to take on more Ruby packages as I don't pay much > attention to the space. > > > But if rubygem-unicode-display_width is going to be retired due to being > orphaned, your rubygem-terminal-table package is going to be in trouble. I > think it is your responsibility to do something about it (even if it should > be just orphaning). Nevertheless, rubygem-jekyll maintainers might be > interested to take over your rubygem-terminal-table, because this is the > dependency chain: > > rubygem-unicode-display_width <= rubygem-terminal-table <= rubygem-jekyll > Orphaning would be my go-to if no one else steps up to take it over. The other packages I have retired didn't have anything depending on them, so they just silently slipped by. I'm willing to hand off ownership of any packages that are threatened by this change. The same goes for other rubygems in my name. I'm happy to keep them until they need more attention than version bumps, but if they become a maintenance burden I would more than happily hand them off. --Greg > > Vít > > > > > --Greg > > On Wed, Sep 2, 2020 at 3:38 AM Vít Ondruch wrote: > >> Hi Robbie, >> >> I wonder if you had some intentions with the packages, be cause at lest >> the 3 down bellow looks to be required by other packages and they are >> now in danger of being removed from Fedora. >> >> Adding on CC Pavel, Dan and Greg who might be interested in some of them. >> >> >> Vít >> >> >> Dne 01. 09. 20 v 20:30 Miro Hrončok napsal(a): >> > On 01. 09. 20 19:40, Robbie Harwood wrote: >> >> You may remove me from these packages or orphan them as you see fit. I >> >> don't plan on making any more contributions. >> > >> > Done. >> > >> > domcleal is main admin of rpms/rubygem-Ascii85 >> > domcleal is no longer the main admin of rpms/rubygem-Ascii85 >> > domcleal is no longer watching rpms/rubygem-Ascii85 >> > domcleal is main admin of rpms/rubygem-ruby-rc4 >> > domcleal is no longer the main admin of rpms/rubygem-ruby-rc4 >> > domcleal is no longer watching rpms/rubygem-ruby-rc4 >> > domcleal is main admin of rpms/rubygem-unicode-display_width >> > domcleal is no longer the main admin of >> > rpms/rubygem-unicode-display_width >> > domcleal is no longer watching rpms/rubygem-unicode-display_width >> > >> >> ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Non-responsive maintainer: domcleal
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 you had some intentions with the packages, be cause at lest > the 3 down bellow looks to be required by other packages and they are > now in danger of being removed from Fedora. > > Adding on CC Pavel, Dan and Greg who might be interested in some of them. > > > Vít > > > Dne 01. 09. 20 v 20:30 Miro Hrončok napsal(a): > > On 01. 09. 20 19:40, Robbie Harwood wrote: > >> You may remove me from these packages or orphan them as you see fit. I > >> don't plan on making any more contributions. > > > > Done. > > > > domcleal is main admin of rpms/rubygem-Ascii85 > > domcleal is no longer the main admin of rpms/rubygem-Ascii85 > > domcleal is no longer watching rpms/rubygem-Ascii85 > > domcleal is main admin of rpms/rubygem-ruby-rc4 > > domcleal is no longer the main admin of rpms/rubygem-ruby-rc4 > > domcleal is no longer watching rpms/rubygem-ruby-rc4 > > domcleal is main admin of rpms/rubygem-unicode-display_width > > domcleal is no longer the main admin of > > rpms/rubygem-unicode-display_width > > domcleal is no longer watching rpms/rubygem-unicode-display_width > > > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
fedora-secondary boot image timeout
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 startup time, this makes a VERY narrow window for my automation to jump on and modify the boot parameters with kickstart info. Where can I suggest this change, or discuss it with the people who own it? --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Quick review
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 -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Non-responsive maintainer
On Fri, Aug 30, 2019 at 12:54 AM Michal Srb wrote: > /me sending the email second time as the first attempt bounced back to me > > Hi Greg, > > Thanks for bringing this to my attention. The package is, unfortunately, > broken in all supported Fedora releases. The version of the package is the > last stable release from 1.x branch, but upstream is now (and has been for > quite some time) on 2.x. Upgrading it to 2.x wouldn't be easy by any means, > it would require a ton of time (weeks, easily...) that unfortunately I > don't have at the moment and most likely won't have in foreseeable future. > In that case, neither will I! > So I am going to do what I should have done a long time ago - I am going > to retire the package. > > I will send a separate email that I am orphaning it (and its dependencies) > and if nobody takes it over, I will just retire it in a week or so. > Sounds perfect. Do you want to also tap the BZ for it? --Greg > Thanks, > Michal > > On Fri, Aug 30, 2019 at 7:45 AM Michal Srb wrote: > >> Hi Greg, >> >> Thanks for bringing this to my attention. The package is, unfortunately, >> broken in all supported Fedora releases. The version of the package is the >> last stable release from 1.x branch, but upstream is now (and has been for >> quite some time) on 2.x. Upgrading it to 2.x wouldn't be easy by any means, >> it would require a ton of time (weeks, easily...) that unfortunately I >> don't have at the moment and most likely won't have in foreseeable future. >> >> So I am going to do what I should have done a long time ago - I am going >> to retire the package. >> >> I will send a separate email 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 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 -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Non-responsive maintainer
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 -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: ppc64le Rawhide VM issues
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 anywhere. However, switching from power9 to power8 appears to have eliminated the issues. --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
ppc64le Rawhide VM issues
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". My qemu boot command is currently: qemu-system-ppc64 -m 2048 -smp 2 -machine pseries -cpu power9 -hda -cdrom I can login to the system, run some basic commands such as "cat", "ls", "cd", etc. However, running slightly more intense commands like "dnf" and "df" result in errors like this: "Illegal instruction (4) at 7fffb3a018e0 nip 7fffb3a018e0 lr 7fffb3a03f2c code 1 in libc-2.30.so[7fffb39b+1f]" I'm not sure if this is a bug in Rawhide or if it is a bug in how I'm launching the VM. Google has come up dry on further info than where I currently am in both regards. Thanks - Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned python-rpyc, python-WSGIProxy2, python-http-parser, python-lockfile, python-plumbum, python-socketpool, python-webtest, python-flask-script
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 > python-WSGIProxy2 > python-http-parser > python-lockfile > python-plumbum > python-socketpool > python-webtest > python-flask-script > > For the same reason. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Intent to retire: mingw-libdb
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 package, let me know and I'll be happy to transfer it. But it's run its course for me and I'm happy enough to let it wither. --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AJ3K4ZHSNPIGKDKXTYQX5Q76AD2H2PLR/
Re: libgsf build help - MinGW edition
> -- > > Date: Thu, 23 Aug 2018 08:04:15 +0100 > From: Daniel P. Berrangé > Subject: Re: libgsf build help - MinGW edition > To: Development discussions related to Fedora > > Message-ID: <20180823070415.ga23...@redhat.com> > 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 definition differs between its forward declaration and its > > implementation. But I don't see any clear way that it differs. The same > > code compiles cleanly in the native libgsf with nary a hiccup. The specific > > error is as follows: > > > > ../../gsf/gsf-input.c:632:1: error: conflicting types for > > 'gsf_input_set_modtime_from_stat' > > gsf_input_set_modtime_from_stat (GsfInput *input, > > ^~~ > > In file included from ../../gsf/gsf.h:54, > > from ../../gsf/gsf-input.c:24: > > ../../gsf/gsf-input-impl.h:67:10: note: previous declaration of > > 'gsf_input_set_modtime_from_stat' was here > > gboolean gsf_input_set_modtime_from_stat (GsfInput *input, > > ^~~ > > make[2]: *** [Makefile:706: gsf-input.lo] Error 1 > > > > Anyone know what could be different here vs in native builds? I've pushed a > > copy of my development branch to my own fork of the mingw-libgsf repo ( > > https://src.fedoraproject.org/fork/greghellings/rpms/mingw-libgsf). It > > lives in the branch named 1_14_44. There is nothing about it that should > > differ in compilation between f28 and current Rawhide. > > > > I'm definitely stumped at this. The two declarations look the same to me, > > but obviously there's something hidden in the bowels of these headers that > > changes the definitions between those two places. Any help would be > > appreciated. > > Given that the two declarations are identical, the difference must be in > the way they are being interpreted. The likely candidate for the cause > is the "struct stat" parameter. > > Looking at the code in gsf-input.c, it pulls in gsf.h which pulls in > gsf-input-impl.h with one definition of the struct. > > At this point, however, 'sys/stat.h' has not been included yet, so the > 'struct stat' is likely an undefined type. > > Later gsf-input.c includes 'sys/stat.h' and then after that the second > declaration of the function is done, which now sees the 'struct stat' > type. > > IOW, moving the sys/stat.h include to the top of gsf-input.c should > fix this problem, or adding it to the top of gsf.h is probably even > better. > > The reason for the difference is probably the glib.h header file. > I expect that on native builds, it ends up pulling in a definition > of 'struct stat' from somewhere, while this does not happen on > Mingw platforms. > > > Regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| Your advice was perfect. When I then went to report the bug to libgsf along with my hack-a-patch I found a pending MR for the change that was better. Thanks! --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HPTOJ5ZTZOQGJARQOJF42I4W4MPVYBPQ/
libgsf build help - MinGW edition
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 cleanly in the native libgsf with nary a hiccup. The specific error is as follows: ../../gsf/gsf-input.c:632:1: error: conflicting types for 'gsf_input_set_modtime_from_stat' gsf_input_set_modtime_from_stat (GsfInput *input, ^~~ In file included from ../../gsf/gsf.h:54, from ../../gsf/gsf-input.c:24: ../../gsf/gsf-input-impl.h:67:10: note: previous declaration of 'gsf_input_set_modtime_from_stat' was here gboolean gsf_input_set_modtime_from_stat (GsfInput *input, ^~~ make[2]: *** [Makefile:706: gsf-input.lo] Error 1 Anyone know what could be different here vs in native builds? I've pushed a copy of my development branch to my own fork of the mingw-libgsf repo ( https://src.fedoraproject.org/fork/greghellings/rpms/mingw-libgsf). It lives in the branch named 1_14_44. There is nothing about it that should differ in compilation between f28 and current Rawhide. I'm definitely stumped at this. The two declarations look the same to me, but obviously there's something hidden in the bowels of these headers that changes the definitions between those two places. Any help would be appreciated. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4TCLVFW7PPNFGYSKGJUNGRPKQXI72IG2/
Release monitoring for COPR
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 (nor where it will put its bugs). Does anyone have guidance on this, or their favorite tool to use? --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
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 mingw-nspr Fixed --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
RPM Lint Errors
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 designed to become executables on the remote hosts, they have she-bang lines as appropriate (mostly shell scripts, a few Python scripts). However, they are not yet supposed to be executed, since they are template files that generate the executable files. Rpmlint flags these files as executables (because of the she-bang) that lack the executable flag (because that flag will be set after templating and upload). Is there a way for me to specifically tell rpmlint to ignore that particular error for those files so I can avoid these false positives? Do I just have to pony up and deal with it? TIA, Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Review Swaps
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 swaps. --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
vagrant-openstack-provider
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, but there are a few (I use several of those as well in my standard configuration). Does anyone know of a reason why it isn't or couldn't be packaged? Has anyone attempted to package it, but run into issues? I'd love to have it available through the RPM infrastructure rather than attempting to mix and match RPM-installed plugins with manually managed ones. TIA, Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Brave New Packaging World
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 -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Rawhide + Vagrant
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 life much easier. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Review Swaps
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: https://bugzilla.redhat.com/show_bug.cgi?id=1441843 TIA --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Review Swaps
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 mingw-nss: https://bugzilla.redhat.com/show_bug.cgi?id=886322 Thanks! --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: PkgDB
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'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 >> today. Is anyone else seeing the same behavior? Is anyone aware of >> problems >> that could case this? >> > > Hi Greg, maybe a stale cookie? > > I used to face problems with SSO enabled google account regularly, > requiring clearing cookies from *.google.com and restarting browser. > > Now I have a separate profile for google + SSO, so I do not have to > restart default profile with all the tabs and fancy add-ons... > > HTH, > > -- Martian > > > >> Thanks >> >> --Greg >> >> >> >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> >> > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
PkgDB
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 today. Is anyone else seeing the same behavior? Is anyone aware of problems that could case this? Thanks --Greg ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Review Swap
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 devel-le...@lists.fedoraproject.org
Re: gnome-software integration
On Wed, Jun 1, 2016 at 12:19 PM, <devel-requ...@lists.fedoraproject.org> wrote:
> Date: Wed, 1 Jun 2016 17:38:15 +0200
> From: Kalev Lember <kalevlem...@gmail.com>
> Subject: Re: gnome-software integration
> To: Development discussions related to Fedora
> <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:
>> 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 (which are available as xiphos-gtk2 and
>> xiphos-gtk3).
>>
>> I need some advice on the proper way to handle this. First, a little
>> explanation of the three packages.
>>
>> Upstream Xiphos includes some support for building against GTK3 but
>> has no intention of moving to that for its primary support on its
>> current roadmap. Thus, there are occasionally bugs against the GTK3
>> build that are left as low-priority tasks - sometimes these will
>> render the GTK3 build completely unusable. Thus, upstream recommends
>> building only against GTK2.
>>
>> To satisfy both camps, and to allow ease of bug reporting (i.e.
>> identifying if the bug is a regression in GTK3 interfaces vs a bug in
>> Xiphos) and for various other reasons, both xiphos-gtk{2,3} were made
>> available. There are a small number of static or data files which can
>> be shared between the two builds - translations, etc. These are
>> packaged as xiphos-common, which is a dep of both the binary packages.
>>
>> One of those files that is shared between the two is the
>> %{_datadir}/appdata/xiphos.appdata.xml, which appears to be what
>> triggers gnome-software to consider a particular package the GUI
>> app-containing package that ought to be installed.
>
> Don't share that, it's meant to be unique per app, and you have two
> separate apps here.
I really only have one app - Xiphos. It's just been compiled under two
different toolkits. They are supposed to be feature-identical and
complete, which they both are to my knowledge. It's just that one of
them (GTK2) gets routine updates and fixes whereas the other (GTK3)
does not receive the same level of concentration from upstream.
I really only want the GTK2 to be exposed to casual users - which is
what I suspect is the majority of users of the gnome-software
interface. Anyone installing the xiphos-gtk3 should be someone who
knows and wants that specific version.
>
> Instead, create two .appdata files, one for each .desktop file, and put
> both the .desktop and .appdata files in the respective xiphos-gtk2 and
> xiphos-gtk3 subpackages. Something like:
>
> xiphos-gtk2.rpm:
> /usr/bin/xiphos-gtk2
> /usr/share/appdata/xiphos-gtk2.appdata.xml
> /usr/share/applications/xiphos-gtk2.desktop
>
> xiphos-gtk3.rpm:
> /usr/bin/xiphos-gtk3
> /usr/share/appdata/xiphos-gtk3.appdata.xml
> /usr/share/applications/xiphos-gtk3.desktop
Would it be better for me to leave only a single appdata.xml file, but
move it to the xiphos-gtk2 package, then it would be exposed to
gnome-software users? Then anyone wanting the GTK3 build could install
through a package manager instead of the app manager?
>
> --
> Hope this helps,
> Kalev
>
> --
>
> Date: Wed, 01 Jun 2016 11:43:46 -0400
> From: Matthias Clasen <mcla...@redhat.com>
> Subject: Re: gnome-software integration
> To: Development discussions related to Fedora
> <devel@lists.fedoraproject.org>
> Message-ID: <1464795826.29236.0.ca...@redhat.com>
> Content-Type: text/plain; charset="UTF-8"
>
>
>> xiphos-gtk2.rpm:
>> /usr/bin/xiphos-gtk2
>> /usr/share/appdata/xiphos-gtk2.appdata.xml
>> /usr/share/applications/xiphos-gtk2.desktop
>>
>> xiphos-gtk3.rpm:
>> /usr/bin/xiphos-gtk3
>> /usr/share/appdata/xiphos-gtk3.appdata.xml
>> /usr/share/applications/xiphos-gtk3.desktop
>
> I have to ask though: is it really worth shipping 2 copies of the
> application ? I would suggest to just ship one of them.
There are users who have specifically requested the GTK3 version be
made available, since they try to keep the GTK2 stack off their
systems for a variety of reasons. Since upstream provides both, though
with differing levels of support, upstream and users both ended up
asking for different builds to be available. Upstream is primarily
interested in GTK2 and simply defaults to telling users to in
gnome-software integration
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 (which are available as xiphos-gtk2 and
xiphos-gtk3).
I need some advice on the proper way to handle this. First, a little
explanation of the three packages.
Upstream Xiphos includes some support for building against GTK3 but
has no intention of moving to that for its primary support on its
current roadmap. Thus, there are occasionally bugs against the GTK3
build that are left as low-priority tasks - sometimes these will
render the GTK3 build completely unusable. Thus, upstream recommends
building only against GTK2.
To satisfy both camps, and to allow ease of bug reporting (i.e.
identifying if the bug is a regression in GTK3 interfaces vs a bug in
Xiphos) and for various other reasons, both xiphos-gtk{2,3} were made
available. There are a small number of static or data files which can
be shared between the two builds - translations, etc. These are
packaged as xiphos-common, which is a dep of both the binary packages.
One of those files that is shared between the two is the
%{_datadir}/appdata/xiphos.appdata.xml, which appears to be what
triggers gnome-software to consider a particular package the GUI
app-containing package that ought to be installed.
What is the proper way for me to resolve the install issue with
gnome-software? I don't feel like moving the xiphos.appdata.xml file
is appropriate in this case. The two binary packages are the same
application. Setting a hard dep from xiphos-common to either binary
package would create a cyclic dependency - not that this would
necessarily be the end of the world, but I don't want to just assume
that is appropriate behavior. Is there a way for me to indicate that
installing xiphos-common requires at least one of xiphos-gtk{2,3} be
installed but which does not create a cyclic dependency? Is a
"Recommends" line the appropriate way to go (and would gnome-software
pick up on that recommendation?).
I need a little guidance here. My Google skills didn't turn up any
clear answers to this particular predicament.
--Greg
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Strange VM/HW dichotomy building Ruby packages
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 rubygem-activesupport and the build is supposed to be a noarch, as the package is pure Ruby. Building locally in a mock environment has worked without fail all evening long, but building in Koji was giving me some issues. After eliminating mismatched packages from the two environments by tagging one of my prior builds into the buildroot and limiting minimum dependency version, I was still seeing a mismatch. My local builds were still fine, but the builds in Koji kept failing, both straight builds and scratch builds. Links to the failed scratch builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=13171824 https://koji.fedoraproject.org/koji/taskinfo?taskID=13171578 And failed source build: https://koji.fedoraproject.org/koji/taskinfo?taskID=13171784 And my succeeded scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=13171627 And the successful source build: https://koji.fedoraproject.org/koji/taskinfo?taskID=13171904 Note that nothing of consequence changed in the spec file between any of these builds. In fact, during the two source builds NOTHING changed in git. However, the only difference that I can see is that all of the failed builds occurred on either VMs or PPC machines and the successful builds all took place on hardware boxes. I'm not sure if this is a koji thing, a Fedora/EPEL thing, or maybe even a core Ruby thing. Has anyone else experienced similar strange behaviors? --Greg -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Review Swaps
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 https://bugzilla.redhat.com/show_bug.cgi?id=1305669 rubygem-em-spec https://bugzilla.redhat.com/show_bug.cgi?id=1305658 Thanks, Greg -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Package name for EPEL7 branch
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 proposed and agreed to that the EPEL package be named rubygem-minitest5. In order to bring this about, would I need to submit a Review Request for a new package named rubygem-minitest5 and go through the normal new package process? Or is there an expedited way I can just get rubygem-minitest5 added to the tags for epel7 in koji? --Greg -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unreachable Developer
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 http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Unreachable Developer
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 response, either in pkgdb or via email. Has anyone had contact with him lately? For some of my pending requests, there are other package maintainers who have been wonderfully helpful in responding, but I've been completely unable to reach jstribny. Assistance would be appreciated. Thanks! --Greg -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: IntelliJ
Thanks for the feedback, guys. On Tue, Jan 20, 2015 at 4:55 PM, devel-requ...@lists.fedoraproject.org wrote: Message: 10 Date: Tue, 20 Jan 2015 16:40:18 -0500 From: Corey Sheldon sheldon.co...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Re: IntelliJ Message-ID: caouzj4d2g40jzbzwoe3_vegehicrsqcxr3g1dlsasgzc22b...@mail.gmail.com Content-Type: text/plain; charset=utf-8 intellij/IDEA has now mostly been folded into AndroidStudio which while not in the default repos can be obtained on the android dev d/l page for linux as a .zip/tarball Base IntelliJ is also provided as the pre-compiled Linux zip files with all the bundled JARs inside. It would be nice to have it installed as per the rest of the applications on a host and not depending on a whole host of self-bundled JARs that duplicate the system JARs. But I have no insight into IDEA's use of such JARs at this point to know if updating them on the system side would lead to problems in the IDE, etc. As someone who just wants to be a consumer of IDEA and is not part of its development ecosystem, I definitely don't want to take on the solo task of building and maintaining the project, unbundling system JARs, etc. But I'd be willing to work with a few others if there's multiple people willing and able to contribute towards the packaging. Message: 11 Date: Tue, 20 Jan 2015 22:58:50 +0100 From: Julien Enselme juj...@jujens.eu To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Re: IntelliJ Message-ID: 54becf9a.8080...@jujens.eu Content-Type: text/plain; charset=utf-8 Hi, I also think this is a great idea. I just have a question: do you intend to package just the Java IDE or do you intend to include plugins for other languages like python (the version for python is called Pycharm but I guess it has the same code base than the Jave version)? BTW: there is a copr repo for Pycharm (https://copr.fedoraproject.org/coprs/phracek/PyCharm/). Maybe it can help you start. Regards, Julien Enselme I haven't gotten far enough down the rabbit hole to make solid decisions either direction with respect to such technical details. I wanted to put out feelers to see who or what else might crop up - like your mention of the PyCharm project. At this point, I'm not even sure whether the plug ins can be added afterwards (e.g. if one package could contain all the common IDE components while other sub-packages add support for the language-specific features) or whether they're required to compile in. My own interest is in Java use, and possibly a smattering of PHP from time to time (although that would be in a commercial setting, so the community edition might not even be appropriate for the PHP work). -- Message: 12 Date: Tue, 20 Jan 2015 17:55:22 -0500 From: Yohan Graterol yograte...@fedoraproject.org To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Re: IntelliJ Message-ID: CA+a4A=t8aojqi4wb8ouzyxkr5o1-xx7dmxowvr62pxnwa8r...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Hi It's a great idea, but IntelliJ (For Android and Java) need as requirement Oracle JDK, so, Fedora has OpenJDK. PyCharm, RubyMine and Webstorm not need Oracle JDK. Regards! As of last year, running the pre-built version was possible in OpenJDK. The system would just complain that there might be issues and if there are isn't that a shame for you! Hopefully it's not the case that there's something proprietary to the Oracle JDK that IntelliJ relies upon. Do you have more details on what that dependency is or where it is documented, so I can look into it before I go down some well of despair only to find out you're correct? -- Message: 10 Date: Wed, 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 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 Fedora 22, it might be possible to bring back in. I was curious if anyone had a particular feeling strongly one way or another, or if there were solid reasons not to resurrect it. It looks like it was a behemoth to maintain, so I don't know how deeply I want to dive into it (the build involved a large number of bundled jars) at this time. I just wanted to put out feelers regarding it. AFAIK IntelliJ was retired because it lacked interested people to maintain it. If there is someone (or better, group of people) willing
IntelliJ
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 Fedora 22, it might be possible to bring back in. I was curious if anyone had a particular feeling strongly one way or another, or if there were solid reasons not to resurrect it. It looks like it was a behemoth to maintain, so I don't know how deeply I want to dive into it (the build involved a large number of bundled jars) at this time. I just wanted to put out feelers regarding it. --Greg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction
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 leverage that into Ubuntu on my own. So, here I am to hopefully join in the effort with the Fedora MinGW team. I've just finished submitting a bug fix for the mingw-icu packages as well as a new mingw-clucene package (here https://bugzilla.redhat.com/show_bug.cgi?id=825557) that are necessary for some of the MinGW building that I want to do with Fedora. Hopefully others will find them useful as well. --Greg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
