Hi,
On 21/11/2019 14:49, Patrik Dufresne wrote:
Hello
Regarding our release plan. Had a chat with someone on #debian-mentors
regarding the packaging of rdiff-backup for Debian. I'm not sure of all
the step required to make this happen, could we get more details about
what should be done, what is missing, what are the step to make this happen.
My understanding is that Otto is already the Debian packager of
rdiff-backup [1] and that he'll shout loud and clear if he's not able to
package the next version of it :-)
Based on my personal experience as Debian packager, as upstream project,
we just need to "stay out of the way", i.e. in a nutshell make sure to have:
- clearly released source code
- no hidden or very strange dependencies
- no binaries in the source code
- fully automatable build and installation process
- rather stable structure of build and installation process (packagers
don't like to redo their package anew with each new release)
- support the packager if he has questions or improvement suggestions to
make their life easier
And I think those are all given in our case, but Otto is very welcome to
comment. Same thing for Frank and Fedora [2]!
KR, Eric
PS: please don't put me in copy of the list, I'm on it and I read it.
[1] https://packages.debian.org/bullseye/rdiff-backup (right hand side).
[2] https://apps.fedoraproject.org/packages/rdiff-backup/overview/
I want to make sure we are covered
--
Patrik Dufresne Service Logiciel inc.
http://www.patrikdufresne.com <http://patrikdufresne.com/>/
514-971-6442
130 rue Doris
St-Colomban, QC J5K 1T9
On Tue, Nov 19, 2019 at 3:10 PM EricZolf <ewl+rdiffbac...@lavar.de
<mailto:ewl%2brdiffbac...@lavar.de>> wrote:
Hi Patrik,
On 19/11/2019 20:54, Patrik Dufresne wrote:
> Yep, sorry. About that, I intend to get appveyor working, but then I
> found out the current travis build for linux was not working well.
> Submitted a PR to fix the scm_version and did not complete it.
If you could just do a rebase on this one, that would be great, I could
merge it.
> Long story short, I did not take time to complete the work. But I
don't
> have alot of free time to spent and I really want to jump in, but
I'm
> struggling just to follow all your changes Eric :P
The trick is to learn looking TV and doing coding at the same time ;-)
> Regarding the Windows build, it might also be interesting to
leverage
> the travis windows build instead of appveyor. Would allow us to
have a
> unique CICD pipeline instead of two.
Whatever works for Arrigo or you, I'm open! At the end the result
counts. Limiting the number of technologies sounds like a good
strategy,
so I'm all for Travis, but if AppVeyor is easier/better for any reason,
also fine.
Thanks, Eric
>
> --
> Patrik Dufresne Service Logiciel inc.
> http://www.patrikdufresne.com <http://patrikdufresne.com/>/
> 514-971-6442
> 130 rue Doris
> St-Colomban, QC J5K 1T9
>
>
> On Tue, Nov 19, 2019 at 2:47 PM <ewl+rdiffbac...@lavar.de
<mailto:ewl%2brdiffbac...@lavar.de>
> <mailto:ewl%2brdiffbac...@lavar.de
<mailto:ewl%252brdiffbac...@lavar.de>>> wrote:
>
> Hi Arrigo,
>
> any help is welcome. Patrick started to work on an Appveyor setup
> but he
> seems to be busy, so if you want to take over the
issue/branch [1] and
> finish the work, drop a note in the issue to give Patrick a
chance to
> react, but from my point of view, you're welcome!
>
> Also under `tools/windows` there is a build setup based on a
Vagrant VM
> and Ansible, so feel free to take the best of all worlds
(even if you
> don't "speak" Ansible, the approach should be obvious from
reading
> through the yaml files and the documentation).
>
> Thanks, Eric
>
> [1] https://github.com/rdiff-backup/rdiff-backup/issues/105
>
>
>
> On 19/11/2019 10:54, Arrigo Marchiori wrote:
> > Hello,
> >
> > On Sun, Nov 17, 2019 at 09:29:10PM +0000, EricZolf wrote:
> >
> >> Hi,
> >> good question, let me try to summarize the current state:
> >>
> >> - migration to Python 3 is finished, there are no known
> regressions.
> >> - we've fixed a fair amount of smaller bugs and cleaned
the repo
> structure
> >> - testing on Linux is done automatically and regularly so
that
> I'm quite confident about the quality of the code on this
platform
> >> - testing on Windows would need more love - anybody is
welcome
> to test who can compile rdiff-backup
> >
> > I developed a small build system:
> > https://github.com/ardovm/rdiff-backup-build
> > that makes an self-contained EXE file (as did previous stable
> > releases) starting from the sources of librsync and
rdiff-backup.
> >
> > It can also make self-contained binaries for Linux, and
possibly
> other
> > Unix-based systems (to be tested).
> >
> > Contributions, comments etc. are of course welcome.
> >
> > [...]
> >> Writing these lines, I realise that I should try to
generate a
> beta release (even if only manually) so that people can more
easily
> test, without the trouble of compiling the code.
> >
> > I was also expecting this. IMHO it is better to have a
release tag,
> > alpha- or beta- is ok, but it must have a name, that we
will be able
> > to refer to in bug reports etc.
> >
> > Once we have the tag, I could help generating the
binaries, if you
> > think it would be useful.
> >
> > Best regards,
> >
>
