Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Disable subpackage check at SRPM build time (#674)

2019-04-20 Thread Igor Gnatenko
`%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:

Re: [Rpm-maint] [rpm-software-management/rpm] should document -q (#662)

2019-04-20 Thread Nick-Levinson
The pipe in the context means mutual exclusivity, not identicalness of meaning. While identicalness of meaning (when redundancy is disallowed) produces mutual exclusivity, mutual exclusivity does not produce identicalness of meaning. Already, info rpm explicitly describes both -v and --verbose

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Disable subpackage check at SRPM build time (#674)

2019-04-20 Thread Robert-André Mauchin
> Meh, I think everything needs to be correctly set during build of SRPM too. What is your solution to our current conundrum then? go-rpm-macros can't be in the default buildroot and rpm fails without it. -- You are receiving this because you are subscribed to this thread. Reply to this email

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Disable subpackage check at SRPM build time (#674)

2019-04-20 Thread Igor Gnatenko
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:

[Rpm-maint] [rpm-software-management/rpm] Disable subpackages checking for scriptlets when building SRPM (#675)

2019-04-20 Thread Robert-André Mauchin
Fix #674. Signed-off-by: Robert-André Mauchin It's a bit hackish, and I don't really know C, but it works. Hopefully someone will review it please? Go-SIG is kind of on the clock due to our Change Proposal. You can view, comment on, or merge this pull request online at:

Re: [Rpm-maint] [rpm-software-management/rpm] License of python-rpm-generators (#471)

2019-04-20 Thread Ville Skyttä
LGPLv2.1(+) or GPLv2(+) is fine with me. -- 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/471#issuecomment-485118161___

Re: [Rpm-maint] [rpm-software-management/rpm] Dynamic Build Dependencies (#593)

2019-04-20 Thread nim-nim
@xsuchy: that was I thought too but the first install report in the log does not have the problem. Unless mock uses a different dnf for different build stages? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: