Same shared lib in two packages
by Marwan Rabbâa
Hi,
I've found that
- gc
- gc-devel
in last fedora version has the same version of
- libcord.so
- libgc.so
- libgccpp.so
is there any reason having more than one version ?
Regards,
6 years, 6 months
rebasing older branches on (vs merge from) master
by Gianluca Sforna
I'd like to know if rebasing in the packages git repo is generally
frowned upon or I can use for my use case. Basically, I have a package
that has some broken tests upstream is looking into; however these
failures only shows on rawhide, so I have tests disabled there until
situation if fixed.
Other, unaffected branches, has a commit to restore the tests
execution, something like this:
[giallu@faxe rdkit (f25)]$ git lola
* fb42a18 (origin/master, origin/HEAD, master) new upstream release
* 224900e - fix non-x86 builds universally
| * 3346783 (HEAD -> f25, origin/f25) reactivate tests
|/
* bb09397 temporarily disable tests
so now I would like to rebase f25 to master so I pickup the new
release AND keep the tests activated.
Opinions?
--
Gianluca Sforna
http://plus.google.com/+gianlucasforna - http://twitter.com/giallu
Tinker Garage - http://tinkergarage.it
6 years, 6 months
Upcoming FPC meetings
by Jason L Tibbitts III
Note that we had no FPC meeting last Thursday as James was out and I was
simply unavailable due to office holiday parties and actual work to do.
Tomorrow is the US Thanksgiving holiday and while I'll probably have an
IRC client open and my guests won't have arrived, there is little chance
that I would be able to actively participate in a meeting. I certainly
won't object if other FPC members want to discuss things, though.
On Dec. 1 I will most likely be driving to New Orleans for a quick trip,
and will almost certainly have to miss that meeting as well.
Dec. 8 is my wife's birthday. I _think_ I'm still good to squeeze in a
meeting but, well....
I am now critically behind on writeups but have been making a little
progress. The drafts I promised I think are all "done" though the
versioning guideline rewrite needs more examples. Hopefully I can find
some free time during all of these holidays and vacations to finish
everything up.
- J<
6 years, 6 months
Packaging udev rules
by Igor Gnatenko
Hello @all,
unfortunately I was not able to find updated information how to do that.
%{_udevrulesdir}/foo.rules is fine in %files and BuildRequires:
systemd, but there are more questions:
* Should %udev_rules_update be put into %post?
* Should %{?systemd_requires} be presented in spec? probably something else?
--
-Igor Gnatenko
6 years, 6 months
packaging cronjob, run as non-root user
by François Kooman
Hi,
I'm trying to package a cron file after reading [1], but I am wondering
what the best approach is to run a cronjob not as root while still using
the /etc/cron.daily folder.
Using /etc/cron.d would be an option, as that allows to run jobs as
different user, but maybe this is not the nicest...
I could use "sudo" in the shell script, but this feels ugly as well. Any
thoughts?
Cheers,
François
[1] https://fedoraproject.org/wiki/Packaging:CronFiles
6 years, 6 months
How to install group rpms by mock
by Jun Aruga
Hello,
We can install rpms of one group by dnf like this.
```
$ sudo dnf group install "C Development Tools and Libraries"
```
However anyone, could you tell me how to install those to mock environment?
Can we use mock command?
```
$ mock -r fedora-rawhide-x86_64 -i something ?
```
Thank you.
--
Jun Aruga
6 years, 6 months
java: %mvn_check?
by Pavel Raiskup
Would that make sense/would it be possible to have %mvn_build not running
testsuite by default -> and have an explicit %maven_check put into
%check?
There are things like '--without check' or '--nocheck', but this doesn't
seem to work well with maven build.
Thanks,
Pavel
6 years, 6 months
Re: Broken dependencies: vim-syntastic
by Pavel Raiskup
On Monday, November 14, 2016 4:37:57 PM CET Peter Robinson wrote:
> On Mon, Nov 14, 2016 at 3:37 PM, Pavel Raiskup <praiskup(a)redhat.com> wrote:
> > On Wednesday, September 21, 2016 12:55:48 PM CET Jason L Tibbitts III wrote:
> >> First off, the guidelines have:
> >> https://fedoraproject.org/wiki/Packaging:Guidelines#Noarch_with_unported_...
> >>
> >> I've been assuming that you're talking about the BuildRequires: case.
> >> If you're just talking about the case where you can build it anywhere
> >> because you're just copying files around, but it just won't install,
> >> then you can try doing the noarch/ExclusiveArch: trick. To be fair, I
> >> have no idea if it still works; I recall that some people really didn't
> >> like it. Of course if it doesn't work then I'll remove that bit from
> >> the guidelines. I've sent out a couple of questions to folks who should
> >> know better than I.
> >
> > To close this for fedora-devel too, the ExclusiveArch trick probably
> > doesn't work at least in my case [1] because:
> >
> > - I set ExclusiveArch for set of sub-packages only
>
> Exclusive/Exclude arch only works for the whole package, not for sub
> packages, it's global to the extire spec.
Worth saying in Guidelines? Because I was able to build package that did
have multiple ExclusiveArch tags (seemingly assigned to subpackages), and
toolchain did not complain.
Still, the guidelines suggest to put 'noarch' into ExclusiveArch which is
clearly a bad advice (and it took a really long debugging to understand
why).
> If you want to exclude package based on arch (why?)
Because some of the sub-packages don't have important Requires available
on some architectures. See the thread.
> you need to do %ifarch conditionals for the sub package components.
Isn't truth that we build noarch packages on randomly chosen "primary"
architecture, and then distribute this noarch binary package to all
primary architectures? Wouldn't that mean that if 'aarch64' was chosen for
build, the subpackage would be missing on all primary arches?
(OT: for some reason, secondary architectures re-build the noarch packages
separately for every architecture, but that might be just self-defensive
approach)
Pavel
> > - I've added 'noarch' into ExclusiveArch, because of the bug 1298668
> > Orion mentioned.
> >
> > Can this be somehow reflected in guidelines [2]? I don't really know how,
> > but at least in case of vim-syntastic -> I'm against adding ExclusiveArch
> > into vim-syntastic (that means if single _sub_package doesn't work on say
> > aarch64, every other sub-package will be excluded from aarch64).
> >
> > [1] https://pagure.io/pungi-fedora/issue/87
> > [2] https://fedoraproject.org/wiki/Packaging:Guidelines
> >
> > Pavel
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
6 years, 6 months