Hi,
I have been trying to create a rpm for gbuffy which I like. However, I am hitting an error in the install directories.
The program is at:
http://www.fiction.net/blong/programs/gbuffy/
Here is my specfile:
# Note that this is NOT a relocatable package
%define ver 0.2.6
%define rel 1%{?dist}
Summary: multiple mailbox buffy for GTK+
Name: gbuffy
Version: %ver
Release: %rel
License: GPL
Group: Applications/Communications
Source0: ~/C.libs/linux/%{name}-%{version}.tar.gz
Source1: http://www.fiction.net/blong/programs/gbuffy/gbuffy-%{ver}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-%(%{__id_u} -n)
URL: http://www.fiction.net/blong/programs/gbuffy
BuildRequires: libPropList
%description
GBuffy is a GTK+ multiple mailbox "biff" program. It is conceptually
based on XBuffy by Bill Pemberton, but is a complete rewrite from
scratch.
GBuffy will poll multiple mailboxes for new mail. It will list the
number of new messages in each mailbox you configure. It will also
highlight the mailboxes which have new mail.
GBuffy is currently capable of watching MBOX, MMDF, Maildir and MH
Folders. This version also supports IMAP4rev1 and NNTP with XOVER
mailboxes.
%prep
%setup -q
%configure
%make_build
%install
%{make_install}
%find_lang %{name}
%{?ldconfig_scriptlets}
%files
%defattr(-,root,root,-)
%{_bindir}/%{name}
%doc README
%license GPL
%clean
rm -rf %{buildroot}
So, everything is fine, however I have the following problem:
......
mkdir /home/rpmbuild/BUILDROOT/gbuffy-0.2.6-1.fc35.x86_64
+ cd gbuffy-0.2.6
+ /usr/bin/make install DESTDIR=/home/rpmbuild/BUILDROOT/gbuffy-0.2.6-1.fc35.x86_64 'INSTALL=/usr/bin/install -p'
./mkinstalldirs /usr/bin
make: ./mkinstalldirs: Permission denied
make: *** [Makefile:49: install] Error 127
error: Bad exit status from /var/tmp/rpm-tmp.vhOJPC (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.vhOJPC (%install)
So, what happens is that there is a mkinstalldirs inside the archive that is triggered. It is supposed to be $(srcdir)/mkinstalldirs however, this is not recognized because I can not seem to be able to pass an srcdir into the configure scrrip.
I tried:
./configure --srcdir=${SRCDIR}
and many other things, but can not seem to get this right.
Any suggestions?
Thanks!
Hi folks,
I'm working on a new package, and am using the forge macros and the rpm
autospec macros. The current WIP spec is here:
https://pagure.io/python-neurotune/blob/main/f/python-neurotune.spec
When running `fedpkg mockbuild` here, I get an odd error where it writes
a src.rpm with a release string (0.1..), but looks for a different value
to build (0.2..).
Have I done something wrong here or is this a bug somewhere that I can
report? There are two commits in the repo, so I guess 0.2 is the correct
value here, but I hadn't added `-p` to autorelease in the first commit.
https://pagure.io/python-neurotune/commits/main
$ fedpkg mockbuild
sources file doesn't exist. Source files download skipped.
setting SOURCE_DATE_EPOCH=1637280000
Wrote: /home/asinha/Documents/02_Code/00_mine/fedora-new-packages/python-neurotune/python-neurotune-0.2.3-0.1.20211119gita17f0fd.fc36.src.rpm
INFO: mock.py version 2.14 starting (python version = 3.10.0, NVR = mock-2.14-1.fc35)...
Start(bootstrap): init plugins
INFO: selinux enabled
Finish(bootstrap): init plugins
Start: init plugins
INFO: selinux enabled
Finish: init plugins
INFO: Signal handler active
Start: run
ERROR: Cannot find/open srpm: /home/asinha/Documents/02_Code/00_mine/fedora-new-packages/python-neurotune/python-neurotune-0.2.3-0.2.20211119gita17f0fd.fc36.src.rpm. Error: [Errno 2] No such file or directory: '/home/asinha/Documents/02_Code/00_mine/fedora-new-packages/python-neurotune/python-neurotune-0.2.3-0.2.20211119gita17f0fd.fc36.src.rpm'
Could not execute mockbuild: Failed to execute command.
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
Hi,
Does anyone know if Seth Jennings (sjenning) is stil active in Fedora? I
sent him an email in June without response.
The package pam-u2f has been outdated for a while and I've created the
non-responsive maintainer bug [1]. There is also a bug open for pyscard [2].
Please ping me on irc (principis) or reply to this email if anyone knows
anything. I'm would like to maintain pam-u2f if needed.
Thanks,
Arthur
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2024771
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1690777
This first affects libraqm, and so its users
so libgd
so php
Initial report https://github.com/libgd/libgd/issues/790
Tracked as https://bugzilla.redhat.com/show_bug.cgi?id=2022957
In short
libraqm is broken on F35
same version works as expected on F34
F34 version works on F35
So, really looks like a build issue
Any idea help welcome
Remi
P.S. I temporarily disable libraqm usage from gd to
workaround this issue.
On Wed, Nov 10, 2021 at 03:50:44PM -0800, Michel Alexandre Salim wrote:
> On Wed, 2021-11-10 at 15:48 -0800, Michel Alexandre Salim wrote:
> >
> > This shows the minimum changes needed to:
> > - have openssl3-libs parallel installable with openssl-libs (tested in
> > mock for x86_64)
> > - mark the base, devel, and perl subpackages as conflicting
> > - openssl3 and openssl both ship binaries in %{_bindir}
> > - ditto with openssl3-perl and openssl-perl
> > - openssl3-devel and openssl-devel both ship headers and includes
> > with the same names
> >
> And of course I forgot to paste in the commit:
> https://gitlab.com/michel-slm/openssl3/-/commit/3649e51f898dbe1d97695cd8aca…
>
It's been 2 days, so I'm assuming I'm not doing anything insanely silly
here. I've put up the package for review:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2022907
cc:ing Sahana who is driving the OpenSSL 3 migration in Fedora. Sahana,
would it make sense to have this in Fedora 34 and 35 as well?
Best regards,
--
Michel Alexandre Salim
profile: https://keyoxide.org/michel@michel-slm.name
This is my first fedora package.
(I have tried before, but not made it this far.)
In the spirit of begging forgiveness rather than permission, I opened:
https://pagure.io/releng/issue/10393
Is the next step for me to:
- get added to the packagers group so that I can "take" ownership
or
- use my fork to update the broken dependencies and submit a PR?
Be ruthless and unforgiving in your feedback.
-Blaise
--
LinkedIn <https://www.linkedin.com/in/blaisepabon/> | Quora
<https://www.quora.com/profile/Blaise-Pabon> | Github
<https://github.com/blaisep>
“If you want to go fast, go alone. If you want to go far, go
together.” --African
proverb