Update on sysvinit on salsa

[KatolaZ]

On Fri, Oct 26, 2018 at 10:18:29AM +0800, Benda Xu wrote:
> Thank you KatolaZ!
> 
> KatolaZ <katolaz at freaknet.org> writes:
> 
> > here is an update of my first experiments with importing a newer
> > version of sysvinit in salsa.debian.org.
> >
> > First of all: the repo is at:
> >
> >   https://salsa.debian.org/debian/sysvinit
> >
> > The main branch is dgit/experimental. 
> 
> Does this branch has any relation with dgit(1)?

Thank you Benda,

Nope, it's just me learning the tooling :(

The branch came from merging dgit/sid from Ben. But then I realised
that Ben's dgit branch has debian/patches already applied. So I am
getting a new experimental branch properly merged from 2.89 and Ben's
one with debian/patches unapplied.

> 
> > As a starting point, I have merged Ben's repo with upstream 2.89 (the
> > closest version to 2.88dsf). It turns out that all but one of the
> > debian patches have been imported upstream, so if I did not make any
> > gross mistake with refreshes, there is only one debian patch left
> > (11_run_nologin.patch).
> 
> Brilliant.

Except there are 2/3 more patches there, see above (Ben's dgit/sid had
patches applied).


> > As I said, my intention is to actually bump the version to the current
> > HEAD upstream (2.91), and try out a build for experimental. But before
> > proceeding I think it would be better for the more experienced DDs
> > here to have a look at the repo and provide any comment on its shape
> > and/or on anything that should be amended. I guess I would find it
> > natural to include an upstream branch in the repo (atm I just tagged
> > the upstream/2.89 in the merged repo), but again, I need the advice of
> > more experienced devs on this point.
> 
> You don't need to model after Petter's branch upstream/current.  That
> practice was around 2010 and is considered outdated.
> 
> The following manual will inspire you,
> 
>    https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.newupstream.html
>

This is the workflow I am trying to use now. 

> > For the merge, I had to use the standard dquilt-based workflow, since
> > most of the patches did not apply cleanly and `gbp pq import` was
> > complaining all the time. Perhaps there is a way to convince it, but
> > this will do for a first PoC, I guess (and we have only one patch left
> > atm, after all).
> 
> I took a look into the commit history. You have merged upstream 2.89
> twice, once into experimental and once into experimental-new,
> consequently you have merged experimental with experimental-new.  This
> exposure of your local operation history is not ideal.  Would you mind
> if I create a new branch cherry-picking your commits?
>

Please do, but consider that I am working on another branch to get a
"clean" merge of the current status of 2.88dsf-59.11 (without patches)
and upstream 2.89. 

Sorry for the mess, but my main concern was to keep the whole history
of the package, rather than starting from scratch. 

Thanks

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[     "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[       @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[     @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/attachments/20181026/7cfe16f0/attachment.sig>