Re: rpmbuild
On 6/14/19 2:38 PM, Patrick Dupre wrote:
1) I expect that I would have to edit the .spec file
That's right. You do. And that's expected.
http://cpanspec.sourceforge.net/ indicates: "It is assumed that
maintainers will need to do some (hopefully small) amount of work to
clean up the generated spec file to make the package build and to verify
that all of the information contained in the spec file is correct. "
cpanspec was never expected to be a 100% solution. It's a tool that
assists packagers, but packagers still need to do some work.
2) After that I install the package
perl-Tk-JBrowseEntry-5.22-1.fc30.noarch
I generate a
perl-Tk-JFileDialog.spec
which contains:
BuildRequires: perl(Tk::JBrowseEntry) >= 4.63
Why that?
cpanspec reads the META.json file provided by Tk-JFileDialog, which
indicates that it needs Tk::JBrowseEntry >= 4.63, and then translates
that information into the spec so that rpm will also know about that
requirement.
Error: Problem: conflicting requests
- nothing provides perl(Tk::JBrowseEntry) >= 4.63 needed by
perl-Tk-JFileDialog-2.20-1.fc30.noarch
The solutions that I found are:
1) add Provides: perl(Tk::JBrowseEntry) = %{version}-%{release} in
perl-Tk-JBrowseEntry.spec or
2) remove BuildRequires: perl(Tk::JBrowseEntry) >= 4.63 in
perl-Tk-JFileDialog.spec
There is a third solution: Add "BuildRequires: perl-generators" in
perl-Tk-JBrowseEntry.spec (or use the "--add-buildrequires
perl-generators" argument to cpanspec). That will automatically
generate the "provides" so that you don't have to do #1 yourself.
In my opinion, I should not have to edit the .spec files
cpanspec appears to be unmaintained, and Fedora guidelines have changed
since 2013. I outlined a number of improvements that should be made in
order to conform to current guidelines, but only two stand out as being
strictly necessary: adding the missing installed files to the %files
section, and adding a buildrequires for perl-generators.
I'd encourage you to remember that Free Software is built on a culture
of participation. I understand that the tool you are using isn't
perfect, but no one here is the maintainer of that tool. Complaining
about it will not solve the problem, but participating might. If you
think the tool needs to be improved, please create a fork and improve
the tool.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@lists.fedoraproject.org
Re: rpmbuild
Thank you for these details.
However
1) I expect that I would have to edit the .spec file
2) After that I install the package
perl-Tk-JBrowseEntry-5.22-1.fc30.noarch
I generate a
perl-Tk-JFileDialog.spec
which contains:
BuildRequires: perl(Tk::JBrowseEntry) >= 4.63
Why that?
When I want to install
perl-Tk-JFileDialog-2.20-1.fc30.noarch.rpm
I get
Error:
Problem: conflicting requests
- nothing provides perl(Tk::JBrowseEntry) >= 4.63 needed by
perl-Tk-JFileDialog-2.20-1.fc30.noarch
(try to add '--skip-broken' to skip uninstallable packages)
The solutions that I found are:
1) add Provides: perl(Tk::JBrowseEntry) = %{version}-%{release}
in perl-Tk-JBrowseEntry.spec
or
2) remove
BuildRequires: perl(Tk::JBrowseEntry) >= 4.63
in
perl-Tk-JFileDialog.spec
In my opinion, I should not have to edit the .spec files
===
Patrick DUPRÉ | | email: pdu...@gmx.com
Laboratoire interdisciplinaire Carnot de Bourgogne
9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
Tel: +33 (0)380395988
===
> Sent: Friday, June 14, 2019 at 7:06 PM
> From: "Gordon Messmer"
> To: users@lists.fedoraproject.org
> Subject: Re: rpmbuild
>
> On 6/12/19 1:43 PM, Patrick Dupre wrote:
> > cpanspec --add-buildrequires perl-generators Tk-JBrowseEntry-5.22.tar.gz
> >
> > only add:
> > BuildRequires: perl-generators
> > in the .spec file
> >
> > which does not help.
>
>
> Sure, it does. The purpose of the "perl-generators" package is to
> include information about what a perl package "provides" and "requires"
> automaticaly, so that you don't have to. If I build Tk-JBrowseEntry
> with BuildRequires: perl-generators, then I get this on the resulting
> package:
>
> # rpm -q --provides perl-Tk-JBrowseEntry-5.22-1.fc30.noarch
> perl(Tk::JBrowseEntry) = 5.22
> perl-Tk-JBrowseEntry = 5.22-1.fc30
>
> If I run the command you included above, there are several changes we'd
> want to make to the spec to bring it more in line with Fedora's
> packaging guidelines. "Group" and "BuildRoot" aren't used in Fedora, so
> those lines can be removed. The "make" command can be replaced with
> "%{make_build}". The %install section should not remove the build
> root. The %clean section should be removed. We need to add
> "PERL5LIB=%{buildroot}%{perl_vendorlib}" to the "make test" command in
> order for it to find the modules it installed in the build root
> (although some tests don't work without an X11 connection). "%defattr"
> isn't required in Fedora. Finally, we need to add "%{_bindir}/*" or
> "%{_bindir}/JBrowseTest.pl" to the %files section (or, alternatively,
> remove that file in the %install section if it should not be included in
> the package). A patch is attached with those changes, for a more
> literal specification of the changes.
>
> I can use that modified spec to build a package, and move on to building
> the other package you mentioned, perl-Tk-JFileDialog. That package
> requires very similar changes, with the exception that "make test"
> actually fails, so I removed that rather than resolve the issue because
> I'm not working on pushing this through formal review. :)
>
> After making the same changes to perl-Tk-JFileDialog, and building the
> package, both packages can be installed:
>
> # rpm -q perl-Tk-JFileDialog perl-Tk-JBrowseEntry
> perl-Tk-JFileDialog-2.20-1.fc30.noarch
> perl-Tk-JBrowseEntry-5.22-1.fc30.noarch
>
>
> On 6/10/19 1:10 AM, Patrick Dupre wrote:
> > Same issue with Tk-JFileDialog.spec
> > In addition, I get:
> > rpmbuild -bb perl-Tk-JFileDialog.spec
> > error: Failed build dependencies:
> > perl(Tk::JBrowseEntry) >= 4.63 is needed by
> > perl-Tk-JFileDialog-2.20-1.fc30.noarch
> >
> > while the installed version is 5.22
>
>
> I believe you got this because your build environment did not include
> the perl-generator package. Once you add that to your BuildRequires,
> then the perl-Tk-JBrowseEntry package will automatically provide
> "perl(Tk::JBrowseEntry)", and resolve the dependency reported in this
> error message.
>
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-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/users@lists.fedoraproject.org
>
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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:
Call for Testers - Wine 4.10 update
Hello! Wine 4.8 started offering the ability to compile parts of itself as Windows binaries instead of Linux binaries but Fedora had not followed suit. This is changing. The Fedora Wine 4.10 update will switch to use MinGW to compile those Windows binaries. This will keep Fedora mostly in line with upstream. Please provide karma feedback on the following updates. I'd like to see how it reacts to a large user base. Fedora 29 https://bodhi.fedoraproject.org/updates/FEDORA-2019-8cfdc622bd Fedora 30 https://bodhi.fedoraproject.org/updates/FEDORA-2019-c647a11e46 Thanks, Michael ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org
Re: rpmbuild
On 6/12/19 1:43 PM, Patrick Dupre wrote:
cpanspec --add-buildrequires perl-generators Tk-JBrowseEntry-5.22.tar.gz
only add:
BuildRequires: perl-generators
in the .spec file
which does not help.
Sure, it does. The purpose of the "perl-generators" package is to
include information about what a perl package "provides" and "requires"
automaticaly, so that you don't have to. If I build Tk-JBrowseEntry
with BuildRequires: perl-generators, then I get this on the resulting
package:
# rpm -q --provides perl-Tk-JBrowseEntry-5.22-1.fc30.noarch
perl(Tk::JBrowseEntry) = 5.22
perl-Tk-JBrowseEntry = 5.22-1.fc30
If I run the command you included above, there are several changes we'd
want to make to the spec to bring it more in line with Fedora's
packaging guidelines. "Group" and "BuildRoot" aren't used in Fedora, so
those lines can be removed. The "make" command can be replaced with
"%{make_build}". The %install section should not remove the build
root. The %clean section should be removed. We need to add
"PERL5LIB=%{buildroot}%{perl_vendorlib}" to the "make test" command in
order for it to find the modules it installed in the build root
(although some tests don't work without an X11 connection). "%defattr"
isn't required in Fedora. Finally, we need to add "%{_bindir}/*" or
"%{_bindir}/JBrowseTest.pl" to the %files section (or, alternatively,
remove that file in the %install section if it should not be included in
the package). A patch is attached with those changes, for a more
literal specification of the changes.
I can use that modified spec to build a package, and move on to building
the other package you mentioned, perl-Tk-JFileDialog. That package
requires very similar changes, with the exception that "make test"
actually fails, so I removed that rather than resolve the issue because
I'm not working on pushing this through formal review. :)
After making the same changes to perl-Tk-JFileDialog, and building the
package, both packages can be installed:
# rpm -q perl-Tk-JFileDialog perl-Tk-JBrowseEntry
perl-Tk-JFileDialog-2.20-1.fc30.noarch
perl-Tk-JBrowseEntry-5.22-1.fc30.noarch
On 6/10/19 1:10 AM, Patrick Dupre wrote:
Same issue with Tk-JFileDialog.spec
In addition, I get:
rpmbuild -bb perl-Tk-JFileDialog.spec
error: Failed build dependencies:
perl(Tk::JBrowseEntry) >= 4.63 is needed by
perl-Tk-JFileDialog-2.20-1.fc30.noarch
while the installed version is 5.22
I believe you got this because your build environment did not include
the perl-generator package. Once you add that to your BuildRequires,
then the perl-Tk-JBrowseEntry package will automatically provide
"perl(Tk::JBrowseEntry)", and resolve the dependency reported in this
error message.
--- /root/perl-Tk-JBrowseEntry.spec.2 2019-06-14 15:41:06.202279307 +
+++ perl-Tk-JBrowseEntry.spec 2019-06-14 16:03:23.610542942 +
@@ -3,10 +3,8 @@
Release:1%{?dist}
Summary:Full-featured "Combo-box" (Text-entry combined with drop-down listbox) derived from Tk::BrowseEntry with many additional features and options
License:GPL+ or Artistic
-Group: Development/Libraries
URL:http://search.cpan.org/dist/Tk-JBrowseEntry/
Source0:http://www.cpan.org/modules/by-module/Tk/Tk-JBrowseEntry-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Tk)
@@ -29,11 +27,9 @@
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
-make %{?_smp_mflags}
+%{make_build}
%install
-rm -rf $RPM_BUILD_ROOT
-
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
@@ -42,16 +38,14 @@
%{_fixperms} $RPM_BUILD_ROOT/*
%check
-make test
-
-%clean
-rm -rf $RPM_BUILD_ROOT
+PERL5LIB=%{buildroot}%{perl_vendorlib} \
+ make test
%files
-%defattr(-,root,root,-)
%doc Changes META.json README
%{perl_vendorlib}/*
%{_mandir}/man3/*
+%{_bindir}/*
%changelog
* Fri Jun 14 2019 Gordon Messmer 5.22-1
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-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/users@lists.fedoraproject.org
Re: New mailing lists available for podman/libpod
On 6/13/19 3:14 PM, Neal Gompa wrote: > On Thu, Jun 13, 2019 at 3:13 PM Daniel Walsh wrote: >> Send an email to: podman-j...@lists.podman.io with the word "subscribe" >> in the title, or by going to https://lists.podman.io and scrolling to >> the bottom of that page to subscribe. >> > Could FAS login be added as a supported auth? > > FAS Loging now supported. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org
Re: New mailing lists available for podman/libpod
On 6/13/19 3:14 PM, Neal Gompa wrote: > On Thu, Jun 13, 2019 at 3:13 PM Daniel Walsh wrote: >> Send an email to: podman-j...@lists.podman.io with the word "subscribe" >> in the title, or by going to https://lists.podman.io and scrolling to >> the bottom of that page to subscribe. >> > Could FAS login be added as a supported auth? > > It should be enabled now. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org
[389-users] Re: Docker official image
> On 14 Jun 2019, at 01:25, Olivier JUDITH wrote: > > Of course, > > Yaml files are strictly dedicated to kubernetes object definition and > deployment (like deployment.yaml for service on docker). They are not to be > included in docker container. > In fact the better is to create a folder "k8s" and move them into . > > In order to create the container/pod on kubernetes you have to launch : > kubectl create -f 389-ds-container/kube/* with all yaml files in kube folder > In interactive mode : > kubectl run -d --name 389-ds-container > --image=registry.opensuse.org/home/firstyear/containers/389-ds-container:latest > --port=3389 > > > 389-ds-container/ > ├── Dockerfile > ├── other files/floders required for Docker image creation > └── k8s > ├── 389-ds-container.yaml > ├── secrets.yaml > ├── service.yaml > └── storage.yaml > > 389-ds-container => (i made a mistake the name should be > 389-ds-container.yaml) is the kubernetes pod declaration on k8s. It defines > what volume, environment variables, resources limit and more required to > start the container on the kube cluster. This file will use the image created > and pushed on the registry of your choice > > services.yaml => create a kube service which will allow external access to > the pod (container). On kubernetes you can not access to you container/pod > directly. You have to implement a service. In my case I created a ClusterIP > which means that the service in only available inside kubernetes cluster (Can > be changed) . Other modes are NodePort or LoadBalancer (available only when > your k8s cluster is hosted on a CloudProvider). Service allow loadbalancing > natively if you have many pods up (ie with MMR) . > > Secrets.yaml => all stuff like passwords or certificates that can be defined > like variable but are mounted in the pod/container and can be used like files > or variables. It’s an equivalent of secret in Docker. In defined there my own > fake certificate in order to inject them with certutil in the pods instead of > the self-signed one > > Storage.yaml => Are the definition of my volume in k8s world. I created a pv > (Persistent volume) which use a physical storage type as filesystem in my > case but can be another kind of storage (NFS,gluster,iscsi,FC…) the user has > to provide a pv with the same name whatever the kind of storage. > Then PVC (PersistentVolumeClaim) , which wil bind the volume defined with the > name and the size required. Do you think there is value in upstreaming these? Can they be made generic? Or is this a per-site kind of configuration and needs customisation? > > > > A better idea may be to have dscontainer take a set of PEM files and then > > load them to your certificate store on startup instead rather than the > > current method of certificate handling. > > Yes i agree but if you want to read them at startup you have to provide them > somewhere accessible from the container. The better i think is the secret. Okay - how does the content of secrets.yaml get sent to the process running in the container? There are two primary use cases here remember - both atomic/transactional server to run 389 (ie vanilla docker), and of course, k8s. So I'd prefer to re-use or share mechanisms if possible. Is there also a way in k8s that when an event occurs (IE a new container is launched in a pod) that a program can be called in existing containers? (This way we can automate replica addition/removal) Primarily my first goal has been to make 389 work for atomic/transactional server, because this is easy, and matches the way many peopl would run 389 today. k8s was always a future goal due to the deeper level of automation needed, and the "opinionated" nature of k8s. So I want to support both though :) > > > Le jeu. 13 juin 2019 à 16:15, William Brown a écrit : > Most of those look pretty reasonable. Can you describe to be the work flow > and how those yaml files interacte with k8s and how they are associated to > the container? Do they need to be in the docker file? Or something else? > > Thanks! > > > > On 13 Jun 2019, at 15:21, Olivier JUDITH wrote: > > > > ___ > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server > SUSE Labs > ___ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-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/389-users@lists.fedoraproject.org > ___ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > Fedora Code of Conduct:
Re: rpmbuild
On Thu, 13 Jun 2019 23:09:58 +0200, Patrick Dupre wrote: > Maybe, however, some perl packages require packages with a version > number higher than a certain value. > Thus, if the Provides/Requires instructions are not set properly, > all the packages requiring other packages fail, either at the build or > installation step. That doesn't make any sense at all. The Provides/Requires dependencies are set automatically at build-time. One package _provides_ exactly what is found within in. Another package _requires_ exactly what it uses in its code. These automatic dependencies are correct at build-time, if and only if none of the providing packages is taken away or replaced with something incompatible (such as failing to satisfy >= requirements due to API changes or runtime behaviour changes). If a Perl Module included in an RPM package is version X.Y, the package must not be used, if a package requires a version higher than X.Y. The package metadata must only provide exactly the version of the Perl Module that is included. That is why perl-generators is used to create these dependencies at build-time. If a newer version of the Perl Module is needed, an update to the package collection may be needed. If you hack a spec file with manually added "Provides:" for a higher version, you are working against the entire system of package dependencies. > In my opinion, all the perl packages need to be checked > to go through the distribution without requiring to use > capnspec by the final user. That is entirely unrelated to this mailing-list thread. It could be that there are perl-* RPM packages included in Fedora's package collection, which are missing the perl-generators build requirement and which are missing "perl(A::B) = version" provides. If that is the case, file a bug report. Or step up as co-maintainer, if you depend on such packages. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-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/users@lists.fedoraproject.org
