On Thursday, June 25, 2020 7:30:26 PM CEST PGNet Dev wrote:
On 6/25/20 10:08 AM, Pavel Raiskup wrote:
>> breaks -- specifically on COPR?
>> _either_ form seems to be ok with rpmbuild -- locally.
> Good question. I don't think so, but I didn't get to more deep observation
> Have you tried to put `%define _disable_source_fetch 0` into your ~/.rpmmacros,
> and then put %undefine into the spec, and is it still working? (copr isn't
> doing anything else).
nope ... I can give it a whirl. tho' not clear on what that tells me, or why
it might be a 'solution'
That may answer the question if that is Copr problem, package problem or rpm
problem. It looks like RPM problem to some extent to me, so I filled:
Speaking of solutions, either don't %undefine the macro at all (remove the
line), or re-define it to 0.
>> i'll change it in my spec in any case.
> Good, just let me know it is OK.
>> iiuc then, this needs to be fixed in online COPR before this'll work?
> We need to fix copr so it works with the %undefine variant, yes. At least if
> it is valid configuration. I did not check the semantics of the macros across
> distro versions, but what makes you think that "undefining" the macro is
> equivalent to allow "download random spec-requested blobs from the
initially, while scrounging around trying to _not_ have to manually use
spectool 1st, these:
not saying those are right/reliable, just frequent -- and what was found.
And since this is pretty common use case, copr already sets correct
default _disable_source_fetch to 0 for the users who upload plain spec
Things should work out of box, but googling this problem actually guided
you to broken use-case, you found a corner case. Let's wait for 1851238
i've been working with Fedora for a whopping 3-4 days now; a bit
at 1st to find thorough docs / examples on this^
and of course, the 'migration' isn't, atm, helping get at useful info ...