I think switching to `%{build_…}` convention makes much more sense. In the old
times where `optflags` meant everything, nowadays you want to have different
CFLAGS, CXXFLAGS. And having `%{build_cflags}` but `%{ldflags}` sounds
inconsistent.
--
You are receiving this because you are subscribed
What will happen if you combine SourceX tag and %sourcelist?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Cool, I'll send patch.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/593#issuecomment-486604885___
Rpm-maint mailing list
> I think a better way would be just merging the python modules back into one
> instead of splitting by C-side library, the split causes way more problems
> than it solves.
If you are talking about having pythonX-rpm to depend on rpm-build-libs and
rpm-sign-libs, but keeping C libraries
Count me in! :)
On Wed, Apr 24, 2019 at 7:09 PM Robert-André Mauchin
wrote:
> Hello,
>
> I'm very interested in AV1, the new royalty-free video codec developed by
> Xiph, Google and others (https://aomedia.org/).
>
> I have packaged almost all project related to AV1:
> - aom:
It seems that your patch is broken:
```
./rpmgeneral.at:318:
runroot rpm2archive - < "${RPMTEST}"/data/RPMS/hello-2.0-1.x86_64.rpm | tar tz
runroot rpm2archive - < "${RPMTEST}"/data/SRPMS/hello-1.0-1.src.rpm | tar tz
--- /dev/null 2019-04-24 19:34:18.132790957 +
+++
@pmatilai also it would be nice to have some extended syntax for this
patchlist, for example `popt-1.16-fix-something.patch,Fix broken
behavior,https://some/pull/request/url` So that it can be inspected by other
tooling.
--
You are receiving this because you are subscribed to this thread.
Same questions as @voxik regarding how sources / patches are extracted /
applied.
Also, would it be possible now to add them dynamically via some Lua magic?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
ignatenkobrain approved this pull request.
Indeed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
`%gopkg` should not expand to `%pre` if no package is generated by that macro.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Meh, I think everything needs to be correctly set during build of SRPM too.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> The problem is that the function lives in an entirely different DSO (_rpm.so)
> which is not linked in by the build module (_rpmb.so)
I spent 30 minutes googling and trying things and I could not find way how to
link it.
---
I would vote for removing `_doBuild` method entirely since it is
Yes, building rpm-python I sing system library as I reported this few years ago
.. it was not fixed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
ignatenkobrain commented on this pull request.
> @@ -237,11 +343,45 @@ static rpmRC buildSpec(BTA_t buildArgs, rpmSpec spec,
> int what)
} else {
int didBuild = (what & (RPMBUILD_PREP|RPMBUILD_BUILD|RPMBUILD_INSTALL));
+ if (!spec->buildrequires && (what &
I would like to have it licensed as the rest of RPM stuff (IIRC GPLv2+), but
I'm fine with whatever @ffesti or @pmatilai come up.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
ignatenkobrain commented on this pull request.
> * @return buffered stdout from script, NULL on error
*/
-static StringBuf getOutputFrom(ARGV_t argv,
-const char * writePtr, size_t writeBytesLeft,
-int failNonZero, const char
ignatenkobrain commented on this pull request.
> @@ -248,23 +248,24 @@ static rpmds rpmdsSingleNS(rpmstrPool pool,
* @param writeBytesLeft no. of bytes to feed to script on stdin
* @param failNonZero is script failure an error?
* @param buildRootbuildRoot directory (or NULL)
+ *
ignatenkobrain commented on this pull request.
> * @return buffered stdout from script, NULL on error
*/
-static StringBuf getOutputFrom(ARGV_t argv,
-const char * writePtr, size_t writeBytesLeft,
-int failNonZero, const char
```
⋊> ~/P/f/r/meson on master ⨯ rpm -qpR
/home/brain/Projects/fedora/rpms/meson/noarch/meson-0.50.1-1.fc31.noarch.rpm |
wc -l 13:39:52
10
⋊> ~/P/f/r/meson on master ⨯ rpm -qpR
and if you want to go with subpackage, you don't need any changes in RPM. Just
override %build/%install (whatever is generating debuginfo subpackages) and run
`rpm -qa` there. Although in some cases it won't work. This should be done by
mock, really.
--
You are receiving this because you are
yes, but you know that SRPM is built in one environment while rest of packages
in others.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai `%{unexpand:…}`?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/582#issuecomment-483977641___
Rpm-maint mailing
@nim-nim
from `ln(1)`:
```
-r, --relative
create symbolic links relative to link location
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This is wrong way to create symlink, you should always create relative ones. In
that case it will work both during build and during runtime.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think this is quite complex thing, because once we get automatic subpackages
generation, you will face same problem as with BuildRequires generator... That
your sourcerpm is incomplete until you build whole thing
Not saying that it is impossible, but I don't see it very useful in
Everything what you need to do is to check what is going to be built during
%generate_buildrequires and filter that out.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #657.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/657#event-2281830004___
Rpm-maint mailing list
Just put enough `%%` in there. It seems quite invasive change without much
benefit.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think you need to use some kind of Provides: bundled() and put there whatever
was used in buildroot. Doing this somewhere else doesn't worth it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #607.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/607#event-2281823809___
Rpm-maint mailing list
Closed #569.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/569#event-2281819018___
Rpm-maint mailing list
Closed #572.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/572#event-2281818977___
Rpm-maint mailing list
I think this has been long enough in waiting-for-info state. Closing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think this has been long enough in waiting-for-info state. Closing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Do you have specific example where and how this should be used?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Why?
What is the problem with packages having branch "latest", "1.x" and such?
On Tue, Apr 16, 2019 at 3:35 PM Jun Aruga wrote:
> Hi,
>
> I like to see "package branch name" of each modules to be aligned more.
>
> Here is a list of the current module, the module stream name, the
> package
Merged #666 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/666#event-2279531143___
Rpm-maint mailing list
Closed #664 via #666.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/664#event-2279531151___
Rpm-maint mailing list
Looks good, but I'll test it later today as well (I know one of packages which
need it).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
You can do something like:
rpms:
foo-bootstrap:
name: foo
bar:
buildafter:
- foo-bootstrap
foo:
buildafter:
- bar
However, MBS doesn't support that yet.
On Tue, Apr 16, 2019 at 1:35 AM Robert-André Mauchin
wrote:
> Hi,
>
> In Golang, we have a lot of cyclic
ignatenkobrain commented on this pull request.
>
case `uname -a` in
Darwin*) exit 0 ;;
*) ;;
esac
# Strip static libraries.
-for f in `find "$RPM_BUILD_ROOT" -type f -a -exec file {} \; | \
-grep -v "^${RPM_BUILD_ROOT}/\?usr/lib/debug" | \
+for f in `find "$RPM_BUILD_ROOT"
ignatenkobrain approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@ignatenkobrain pushed 3 commits.
19961172f5ebc3d728eeeb6463d6478a3278bd59 rpmbuild: Generate
buildreqs.nosrc.rpm properly with --nodeps
c2f5358a3346eb8b886d87aeb2b66605094aa19a rpmbuild: Put dynamic BuildRequires
into src.rpm even with --nodeps
7d339dff7a69c778bdef4bdbae16e52ed20ac36a Fix
Just some update on this from my side:
* RPM with this PR
* Latest mock
** With https://github.com/rpm-software-management/mock/pull/246
** With removed `--nodeps` from mock (@xsuchy is going to test whether it will
break anything)
* rust-packaging with
@ffesti you have one more bug which is breaking basically everything :)
```diff
@@ -354,7 +353,7 @@ static rpmRC buildSpec(BTA_t buildArgs, rpmSpec spec, int
what)
!(what & (RPMBUILD_BUILD|RPMBUILD_INSTALL|RPMBUILD_PACKAGEBINARY))){
/* don't run prep if not needed for
Thinking about this a bit more, rpmbuild should probably get an option to just
execute genbr section without checking dependencies. The reason why mock does
`--nodeps` because rpmbuild in target environment might be older/compiled with
different features so it can't read rpmdb within chroot
I have used standard `fedora-rawhide-x86_64.cfg` with 2 additional repos:
```ini
[ignatenkobrain-rpm-buildreqs]
name=Copr repo for rpm-buildreqs owned by ignatenkobrain
baseurl=https://copr-be.cloud.fedoraproject.org/results/ignatenkobrain/rpm-buildreqs/fedora-rawhide-$basearch/
type=rpm-md
Seems that it doesn't quite work (not sure why yet):
```
INFO: ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bb --target
x86_64 --nodeps /builddir/build/SPECS/rust-warp.spec'],
chrootPath='/var/lib/mock/fedora-rawhide-x86_64-buildreqs/root'env={'TERM':
'vt100', 'SHELL':
I have built 4.14 RPM with necessary changes (obviously, only for testing.
f28/f29/f30/f31):
https://copr.fedorainfracloud.org/coprs/ignatenkobrain/rpm-buildreqs/
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
At this moment,
* %meson doesn't pass -Db_ndebug at all, we use project-specific options
* If project doesn't specify it, b_ndebug=false is default in meson
* In case of mesa, it specifies b_ndebug=if-release which works correctly
now with backported patch
On Mon, Apr 8, 2019 at 4:29 PM Kalev
-d229ead72a
* https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-9f6eea54fe
On Mon, Apr 8, 2019 at 12:59 PM Kalev Lember wrote:
>
> On 4/8/19 11:13, Florian Weimer wrote:
> > * Peter Hutterer:
> >
> >> On Mon, Apr 08, 2019 at 09:20:35AM +0200, Igor
Hello,
While fixing mesa build which was slow due to a lot off debug stuff
(assert()), I've added -Db_ndebug=true into the %meson macro.
This seemed like good approach because in Fedora we should not use debug
bits in runtime (not related to debuginfo). However this caused some
breakage in some
I have implemented necessary bits in rust2rpm:
https://pagure.io/fedora-rust/rust2rpm/pull-request/75
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I tried multiple ways, but I can't get RPM to return `11` :/
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Ah, it seems that this part is broken on DNF side:
```python
# enable source repos only if needed
if not (self.opts.spec or self.opts.srpm):
I did give this quick try:
1. `Wrote: /home/brain/rpmbuild/SRPMS/rust-warp-0.1.15-1.fc31.buildreqs.rpm`
feels a bit strange to have in SRPMS directory with `Architecture: x86_64`.
Probably we should not set `Architecture` for these RPMs?
2. `rpmbuild --rebuild
s/unless/without/
And then it looks good.
On Wed, Apr 3, 2019 at 2:19 PM Neal Gompa wrote:
> On Wed, Apr 3, 2019 at 3:26 AM Jakub Cajka wrote:
> >
> >
> >
> >
> >
> > ----- Original Message -
> > > From: "Igor Gnatenko"
>
Michal, can you do it for all packages with ecosystem crates.io?
On Tue, Apr 2, 2019 at 8:04 PM Michal Konecny wrote:
> I refreshed every project on the list (deleted latest version that will
> be retrieved again in next check, which is done every hour). You should
> already see new bugs in
On Tue, Apr 2, 2019 at 6:17 PM Nicolas Mailhot
wrote:
> Le 2019-04-02 14:51, Jakub Cajka a écrit :
> > - Original Message -
> >> From: "Nicolas Mailhot"
> >> To: "Discussion of RPM packaging standards and practices for Fedora"
> >>
> >> Cc: golang@lists.fedoraproject.org, "Jakub Cajka"
ignatenkobrain commented on this pull request.
> @@ -487,6 +487,10 @@ AS_IF([test "$WITH_LIBELF" = yes],[
# If possible we also want the strtab functions from elfutils 0.167.
# But we can fall back on the (unsupported) ebl alternatives if not.
AC_CHECK_LIB(dw,
ignatenkobrain commented on this pull request.
> +if (auditFd < 0)
+ goto exit;
+
+int nelem = rpmtsNElements(ts);
+struct teop *ops = xcalloc(nelem, sizeof(*ops));
+char *dir = audit_encode_nv_string("root_dir", rpmtsRootDir(ts), 0);
+int enforce = (rpmtsVfyLevel(ts)
Hello,
I'm building modules with Rust apps (because this is only way to get them
in f28/f29/f30) and I noticed that building them takes ages (more
specifically, more than 12 hours(!)). I can build all those packages on my
laptop under 1 hour. Even composes take less time.
It seems that MBS has
Hello folks,
I've prepared PR for new version of minetest:
https://src.fedoraproject.org/rpms/minetest/pull-request/3
I'll merge it later this week and build for F30 and F31. It also involves
License change but it was just incorrect even before.
I'll also probably make a module out of it so it
Now I finally remember why I opened
https://github.com/rpm-software-management/rpm/issues/376
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think those messages are just informational, because nothing uses those
modules to build packages.. or am I wrong?
On Tue, Feb 26, 2019, 14:32 Miroslav Suchý wrote:
> From:
> https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2
>
> When you try to run:
> mock -r fedora-rawhide-x86_64
```
⋊> /v/t/f/python-aiorpcx on master ⨯ rpm2cpio
./python-aiorpcx-0.10.5-1.fc30.src.rpm | cpio -tv
14:10:18
-rw-r--r-- 1 root root23549 Feb 16 07:12 aiorpcX-0.10.5.tar.gz
-rw-r--r-- 1 root root 1069 Feb 23 14:12
Enjoy plain makefiles :)
The problem here is that custom build recipes do not set SONAME.
On Sat, Feb 23, 2019 at 7:47 PM Sandro Mani wrote:
> Hi
>
> I've pushed what looked like a harmless update from libgif-5.1.4 to
> libgif-5.1.6 to rawhide/f30, but apparently the dependency generator
>
@pmatilai so what can we do to make it better? Should I go ahead and create
4.15 milestone and put PRs and issues there (the ones I think should be done
for 4.15)?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
For external people and other contributors it is not visible when next release
of RPM will happen and what features will be there.
GitHub provides "Milestone" feature, so could you create 4.15 milestone and
assign Pull Requests and Issues which are planned for that release? And
possibly
> This is NOT a time to submit Fedora features.
So when is the time? Submitting change proposals help to gather feedback from
community and get additional people on board for discussions.
Unless you don't want any external people to be involved, implement something
and then wait another 10
On Tue, Feb 19, 2019 at 4:26 PM Petr Pisar wrote:
> On 2019-02-18, Ben Cotton wrote:
> > Let's take graphene as an example.
> >
> > Spec file contains:
> >
> > %package devel
> > Requires: %{name}%{?_isa} = %{version}-%{release}
> > %package tests
> > Requires: %{name}%{?_isa} =
I've updated wiki page with what Neal said.
On Tue, Feb 19, 2019 at 8:11 AM Miro Hrončok wrote:
>
>
> On 19. 02. 19 2:26, Neal Gompa wrote:
> > On Mon, Feb 18, 2019 at 6:31 PM Tom Stellard
> wrote:
> >>
> >> Would there be some way to opt out of this? In some cases,
> %{name}-devel
> >>
Bash 5.0 is now in Rawhide/F30. Enjoy :)
P.S. Don't hesitate to report bugs if you find one (or two).
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
and
> FESCo teams.
>
> = Proposed System Wide Change: Remove Excessive Linking =
> https://fedoraproject.org/wiki/Changes/RemoveExcessiveLinking
>
>
> Owner(s):
> * Igor Gnatenko
> * Neal Gompa
>
>
> Pass "--as-needed" flag the linker through
We have just merged side tag (f30-readline8) into the f30 which includes
readline 8 + packages which needed rebuild against new readline (due to
SONAME bump).
Whatever was failing before and fails now… It just failed.
Whatever was not failing before and fails now… Fails not due to readline
On Sun, Feb 17, 2019 at 11:32 PM Jerry James wrote:
> Was the apparently in-progress readline 8.0 rebase announced
> somewhere? All I can recall seeing is [1], which said, 3.5 weeks ago,
> that the rebase would happen "in a couple of weeks". But apparently
> there is a side tag and builds are
Bash 5.0 is now in Rawhide/F30. Enjoy :)
P.S. Don't hesitate to report bugs if you find one (or two).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
So in order to make some move here, I've submitted Fedora Change here:
https://fedoraproject.org/wiki/Changes/BuildRequires_Generators
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I've submitted this:
https://fedoraproject.org/wiki/Changes/Automatic_strict_inter-package_dependencies
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
On Fri, Feb 15, 2019 at 9:36 PM Eli Young wrote:
> > I'd still consider this on case by case basis instead of developing a
> general
> > solution, sometimes a simple Recommends works. Sometimes, it's more
> complicated.
>
> That's fair and makes a lot of sense. I do like the pattern mentioned by
It won't help because you didn't take the build dependencies of ant/maven…
On Tue, Feb 12, 2019 at 12:51 PM Fabio Valentini
wrote:
> On Tue, Feb 12, 2019 at 12:16 PM Fabio Valentini
> wrote:
> >
> > On Tue, Feb 12, 2019 at 12:08 PM Miro Hrončok
> wrote:
> > >
> > > On 12. 02. 19 11:46, Fabio
Not in the buildroot. Default modules are available by default only for
users and not in the buildroot.
On Tue, Feb 12, 2019 at 10:01 AM Tom Hughes wrote:
> On 12/02/2019 07:22, Mikolaj Izdebski wrote:
> > On Mon, Feb 11, 2019 at 11:19 PM Fabio Valentini
> wrote:
> >> I'm curious: What happens
I was talking to Petr Šabata some time ago and he told me that there will
be some solution for getting modular packages in non-modular buildroot
within month or two.
On Tue, Feb 12, 2019 at 9:06 AM Aleksandar Kurtakov
wrote:
>
>
> On Tue, Feb 12, 2019 at 9:51 AM Ralf Corsepius
> wrote:
>
>> On
I don't think you can generate graph... Because how would you display
"Requires: (foo if bar)"? :)
On Mon, Feb 11, 2019 at 6:11 PM Adam Williamson
wrote:
> On Mon, 2019-02-11 at 17:57 +0100, Miro Hrončok wrote:
> > The following packages require above mentioned packages:
> > (this is in fact so
You can do "%py3_build -- --some-cool-option".
On Sat, Feb 9, 2019, 14:40 Richard Shaw Just want to get others opinions before filing a bug...
>
> Currently %py3_build expands to:
>
> $ rpm -E %py3_build
> \
> CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}"
> LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}"\
>
, Tom Stellard wrote:
> > On 01/28/2019 02:47 PM, Igor Gnatenko wrote:
> >> It would be great if you would include list of dependent packages +
> >> their maintainers.
> >>
> >
> > Here is the list of dependent packages:
> >
> > Maintainers by
I can't speak on behalf of Neal, but I think I will try to answer.
On Thu, Feb 7, 2019, 10:21 Adam Samalik
>
> On Thu, Jan 31, 2019 at 6:19 PM Neal Gompa wrote:
>
>> On Thu, Jan 31, 2019 at 6:07 AM Matthew Miller
>> wrote:
>> >
>> > On Tue, Jan 29, 2019 at 11:06:25PM -0500, Neal Gompa wrote:
I never asked you to implement it :)
I try to always open an issue and discuss whether it is something which we
would get in before doing the actual implementation.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Is there anything better than `Requires: %{name}%{?_isa} =
%{?epoch:%{epoch}:}%{version}-%{release}` available?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai for the simple scriptlets which call ldconfig or anything else simple
(few commands), I think using `bash --rpm-requires` would be more than enough
and will be more nice to users so they don't have to write `Requires(post):
/usr/sbin/semanage` or anything like that.
--
You are
I don't think that this should be job of RPM. With koji you can always say what
packages were available at the time of build, do dependency resolution and
voila.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
It seems that b780f5a8d636073d67dbcdfa3f8795f878b55218 (from 2007) removed such
generator as not being used which probably happened because it was not ported
to new dependency generators syntax or so.
It would be nice if we could generate dependencies on scriptlets using that
code. No more
cc @wladmis @ldv-alt
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/627#issuecomment-460792388___
Rpm-maint mailing list
Imagine that the package you are building, contains following binary packages:
* util-linux (depends on libsmartcols.so.1)
* libsmartcols (provides libsmartcols.so.1)
I believe in 99.(9)% of cases you really want to have libsmartcols installed as
a provider and not something else what happen to
. We need to allow text relocations.
> @@ -162,11 +159,6 @@ restorecon -R %{_libdir}/ocp-* || :
> %endif
>
>
> On Fri, Dec 21, 2018 at 09:25:13AM +0100, Igor Gnatenko wrote:
> > If I manage to get this approved and done before mass rebuild, I'll
> > just push changes witho
On Mon, Jan 28, 2019, 18:32 Ben Cotton https://fedoraproject.org/wiki/Changes/SWID_Tag_Enablement
>
> == Summary ==
> Provide tools to allow users and developers to create Software
> Identity (SWID) tags for Fedora installs and repositories.
>
> == Owner ==
> * Name: [[User:adelton|Jan
In Rust we have similar problem (we have "features" than "extras") and we
always package them as a subpackages.
https://src.fedoraproject.org/rpms/rust-serde/blob/master/f/rust-serde.spec
rust-serde-devel
rust-serde+alloc-devel
rust-serde+default-devel
rust-serde+derive-devel
rust-serde+rc-devel
In Rust we have similar problem (we have "features" than "extras") and we
always package them as a subpackages.
https://src.fedoraproject.org/rpms/rust-serde/blob/master/f/rust-serde.spec
rust-serde-devel
rust-serde+alloc-devel
rust-serde+default-devel
rust-serde+derive-devel
rust-serde+rc-devel
visibility and reading easiness.
Feel free to reply to this email or comment in google doc (there is a link
on the bottom).
Proposal Owners
-
Mikolaj Izdebski (mizdebsk) - Java SIG, Fedora
infrastructure
-
Igor Gnatenko (ignatenkobrain) - Rust
SIG, Golang SIG, Neuro SIG, RPM a
visibility and reading easiness.
Feel free to reply to this email or comment in google doc (there is a link
on the bottom).
Proposal Owners
-
Mikolaj Izdebski (mizdebsk) - Java SIG, Fedora
infrastructure
-
Igor Gnatenko (ignatenkobrain) - Rust
SIG, Golang SIG, Neuro SIG, RPM a
401 - 500 of 1994 matches
Mail list logo
