On Tue, Sep 04, 2018 at 09:37:25AM +0200, Michael Adam wrote:
On Tue, Sep 4, 2018 at 9:21 AM, Igor Gnatenko <
ignatenkobrain(a)fedoraproject.org> wrote:
> On Tue, Sep 4, 2018 at 12:29 AM Michael Adam <madam(a)redhat.com> wrote:
>
>> On Mon, Sep 3, 2018 at 11:10 PM, Zbigniew Jędrzejewski-Szmek <
>> zbyszek(a)in.waw.pl> wrote:
>>
>>> On Mon, Sep 03, 2018 at 09:38:44PM +0200, Michael Adam wrote:
>>> > On Mon, Sep 3, 2018 at 7:07 PM, Zbigniew Jędrzejewski-Szmek <
>>> > zbyszek(a)in.waw.pl> wrote:
>>> >
>>> > > On Mon, Sep 03, 2018 at 06:29:34PM +0200, Michael Adam wrote:
>>> > > > On Mon, Sep 3, 2018 at 5:23 PM, Peter Robinson <
>>> pbrobinson(a)gmail.com>
>>> > > wrote:
>>> > > >
>>> > > > > On Mon, Sep 3, 2018 at 4:07 PM Michael Adam
<madam(a)redhat.com>
>>> wrote:
>>> > > > > >
>>> > > > > > Hi all,
>>> > > > > >
>>> > > > > > Tinyproxy just released a new version 1.10 which is
has been
>>> overdue
>>> > > > > > and containes 2 CVE fixes apart from several
enhancements.
>>> > > > > >
>>> > > > > > I created builds for rawhide already.
>>> > > > > >
>>> > > > > > I was wondering if it is still possible to get
tinyproxy to
>>> this
>>> > > > > important
>>> > > > > > update in f29, since no other packages depend on
it, afaict.
>>> > > > > >
>>> > > > > > If so, what do I do? Just update the scm branch and
bring it in
>>> > > through
>>> > > > > Bodhi?
>>> > > > >
>>> > > >
>>> > > > Thanks for the swift response!
>>> > > >
>>> > > > (And apologies for any cluelessness about newer aspects of
the
>>> fedora
>>> > > > process - it's been a while since i did these things, and
it
>>> worked a
>>> > > little
>>> > > > differently then...)
>>> > > >
>>> > > >
>>> > > > > Sounds like a reasonable course of action. Is it
backward
>>> compatible
>>> > > > > in terms of any interface people might use?
>>> > > >
>>> > > >
>>> > > > There are a few config file additions.
>>> > > > The location of the binary has changed from /usr/sbin
>>> > > > to /usr/bin . Otherwise no Interfaces i'm aware of.
>>> > >
>>> > > You should create a compat symlink from the old location to the
new
>>> > > location, at least in the stable releases, in case somebody calls
the
>>> > > binary by path.
>>> > >
>>> >
>>> > Good point.
>>> >
>>> > - Is there an established way to create such a "compat
symlink"?
>>>
>>> ln -s ../bin/NAME %{buildroot}/usr/sbin/NAME
>>>
>>> would be the standard way.
>>>
>>> > - What do you mean by "stable releases"?
>>> > Does F29 (which is not released yet) qualify as that?
>>> I meant F28 and F27, but since this costs so little, I'd do the same
>>> for F29 too.
>>>
>>
>> Hmm, ok. I guess it is not a problem at this point
>> if f29 thereby goes one build ahead of master.
>> If needed later, we can still bump master's release number..
>>
>
> This is wrong, rawhide version should be always newer. You can either bump
> release in rawhide and do no changes there or bump release *after*
> %{?dist} in f29/f28.
>
Ok...
Can I still downgrade the release from 2.f29 to 1.f29.1 (or so) in f29
(since it's not official yet, only put up in testing for f29)?...
You probably could, but I think it's better to just rebuild it in rawhide
with the same version. (It's less work for you and less chances of confusion
for others.)
Zbyszek