1:50 p.m.
Hi all,
I've been exchanging a few emails with Ritesh Raj Sarraf, the Debian
maintainer of targetcli in Debian, about also getting targetcli-fb in
Debian main, as an alternative:
https://wiki.debian.org/DebianAlternatives
Would anyone be interested in helping (or leading) the effort to get
targetcli-fb and configshell-fb into Debian? (rtslib-fb somehow already
is there, due to OpenStack.) We have example Debian packaging files
already, but I don't know how much these may need to be changed to be
acceptable for Debian.
Please email me on or off list and hopefully we can organize to make
this happen!
Thanks -- Regards -- Andy
7:12 a.m.
I'm happy to lend a helping hand. I'm running Debian packages for the
stack on all my test systems, and sent the occasional fix to them. I've
also added Debian packaging to my new nvmetcli package which is
partially based on targetclu and rtslib-fb.
I'd need a sponsor like Ritesh for both of them, though.
On Wed, Jun 22, 2016 at 11:50:50AM -0700, Andy Grover wrote:
I've been exchanging a few emails with Ritesh Raj Sarraf, the
Debian
maintainer of targetcli in Debian, about also getting targetcli-fb in Debian
main, as an alternative:
https://wiki.debian.org/DebianAlternatives
I don't think using alternatives is a good idea, but given that the
Datera targetcli is basically unmaintained these days replacing it in
Debian would be very helpful for the broader user base. This might
would require finishing up your work to important the config files,
though.
11:02 a.m.
On 06/23/2016 05:12 AM, Christoph Hellwig wrote:
I'm happy to lend a helping hand. I'm running Debian
packages for the
stack on all my test systems, and sent the occasional fix to them. I've
also added Debian packaging to my new nvmetcli package which is
partially based on targetclu and rtslib-fb.
I'd need a sponsor like Ritesh for both of them, though.
CCing Ritesh. I think he sounded willing to be a sponsor...? :-)
Great! Since you've sent in fixes I'm assuming your packages are close
or identical to what's in the targetcli-fb and configshell-fb repos'
debian/ dir?
Actually, someone mentioned upstreams having a debian/ is frowned upon.
That's easily moved but I'm hoping you, Ritesh, or someone else can fix
or at least identify the remaining packaging issues so Ritesh can get us
into experimental, where I'm assuming any remaining issues can be worked
out.
On Wed, Jun 22, 2016 at 11:50:50AM -0700, Andy Grover wrote:
> I've been exchanging a few emails with Ritesh Raj Sarraf, the Debian
> maintainer of targetcli in Debian, about also getting targetcli-fb in Debian
> main, as an alternative:
>
> https://wiki.debian.org/DebianAlternatives
I don't think using alternatives is a good idea, but given that the
Datera targetcli is basically unmaintained these days replacing it in
Debian would be very helpful for the broader user base. This might
would require finishing up your work to important the config files,
though.
I really do not like working on the convert-to-json script. For the
first stage, getting into experimental, I'm not sure finishing it is
required. For the second stage, getting out of experimental as an
alternative, I don't think it's required. If we get to a third stage
where we're considering replacing Datera targetcli as the default, I'm
*still* not convinced it's required, given that we can push a config
into configfs with Datera and then save config into json with "targetctl
save".
But if Ritesh insists it's needed at some stage then yes I'll do it.
Regards -- Andy
1:25 p.m.
Hello Andy,
Good to hear back from you.
On Thu, 2016-06-23 at 09:02 -0700, Andy Grover wrote:
On 06/23/2016 05:12 AM, Christoph Hellwig wrote:
> I'm happy to lend a helping hand. I'm running Debian packages for the
> stack on all my test systems, and sent the occasional fix to them. I've
> also added Debian packaging to my new nvmetcli package which is
> partially based on targetclu and rtslib-fb.
>
> I'd need a sponsor like Ritesh for both of them, though.
Hello Christoph,
On Debian's Alioth infrastructure, I created a group named linux-target.
In my opinion the packages will be a good fit here if they are related to Linux
and Block Storage
https://alioth.debian.org/projects/linux-target/
We can co-maintain it here. And I'll happily sponsor the package.
CCing Ritesh. I think he sounded willing to be a sponsor...? :-)
Great! Since you've sent in fixes I'm assuming your packages are close
or identical to what's in the targetcli-fb and configshell-fb repos'
debian/ dir?
Actually, someone mentioned upstreams having a debian/ is frowned upon.
That's easily moved but I'm hoping you, Ritesh, or someone else can fix
or at least identify the remaining packaging issues so Ritesh can get us
into experimental, where I'm assuming any remaining issues can be worked
out.
:-)
There's no written rule for that, but yes, the packaging practice has been to
relieve upstream of such packaging work. But many others maintain their branch
(Datera's repo, sg3-utils).
When importing, my practice is to strip of the upstream debian/ folder.
For eg,
https://anonscm.debian.org/cgit/linux-target/targetcli.git/tree/debian/RE...
urce
> On Wed, Jun 22, 2016 at 11:50:50AM -0700, Andy Grover wrote:
> > I've been exchanging a few emails with Ritesh Raj Sarraf, the Debian
> > maintainer of targetcli in Debian, about also getting targetcli-fb in
> > Debian
> > main, as an alternative:
> >
> > https://wiki.debian.org/DebianAlternatives
>
> I don't think using alternatives is a good idea, but given that the
> Datera targetcli is basically unmaintained these days replacing it in
> Debian would be very helpful for the broader user base. This might
> would require finishing up your work to important the config files,
> though.
I really do not like working on the convert-to-json script. For the
first stage, getting into experimental, I'm not sure finishing it is
required. For the second stage, getting out of experimental as an
alternative, I don't think it's required. If we get to a third stage
where we're considering replacing Datera targetcli as the default, I'm
*still* not convinced it's required, given that we can push a config
into configfs with Datera and then save config into json with "targetctl
save".
But if Ritesh insists it's needed at some stage then yes I'll do it.
I'm not interested in the alternatives approach either. My intent is to get it
in shape to become the standard LIO target for Debian.
Getting the package into experimental doesn't really have any special criteria.
But my intent here is to target it for Debian Stretch, which will enter into
freeze around November this year.
Even though LIO has very low popcon count right now, I do keep getting bug
reports. And as is with all my SAN packages, people mostly test (and report
bugs) when these packages have entered Debian Testing (quite late).
But we should have an upgrade path.
https://tracker.debian.org/pkg/targetcli
So, imo, let's get it to Debian Experimental first. For that, I think the
quickest is that the source tarballs be switched with a version bump.
Then, once the packaging part is sorted out, we should look at the upgrade path
against the current version (Datera version) in Debian Unstable. That is pretty
much it. Once the package is in Unstable and no RC bugs are reported, it'll
migrate to Testing (and eventually to Stable).
PS: After having written this email, I think there may not be that much work. If
we can get 1 revision of the -fb based package imported into the Debian
packaging in Experimental, it'd be very easy to just push further incremental
uploads.
For convenience, I've cloned the Debian LIO Packaging repos at github. They
contain the entire packaging + source, in git-buildpackage workflow.
https://github.com/rickysarraf/configshell
To try out the current packages, you can just clone them, and then run
`gbp buildpackage` for each repo. That'd give you the entire flow of the build.
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
3:31 a.m.
On Thu, Jun 23, 2016 at 11:55:30PM +0530, Ritesh Raj Sarraf wrote:
On Debian's Alioth infrastructure, I created a group named
linux-target.
In my opinion the packages will be a good fit here if they are related to Linux
and Block Storage
https://alioth.debian.org/projects/linux-target/
We can co-maintain it here. And I'll happily sponsor the package.
Thanks. I used to have an alioth account from the days when I helped
with the debian kernel maintanance, let's see if I can recover that.
There's no written rule for that, but yes, the packaging practice
has been to
relieve upstream of such packaging work. But many others maintain their branch
(Datera's repo, sg3-utils).
When importing, my practice is to strip of the upstream debian/ folder.
For eg,
https://anonscm.debian.org/cgit/linux-target/targetcli.git/tree/debian/RE...
urce
For xfsprogs we have the debian packaging in upstream and it makes
my life a lot easier. But then again if both upstream and Debian
packaging is cooperative (and both are in git!) I'm fine either way.
PS: After having written this email, I think there may not be that
much work. If
we can get 1 revision of the -fb based package imported into the Debian
packaging in Experimental, it'd be very easy to just push further incremental
uploads.
For convenience, I've cloned the Debian LIO Packaging repos at github. They
contain the entire packaging + source, in git-buildpackage workflow.
https://github.com/rickysarraf/configshell
To try out the current packages, you can just clone them, and then run??
`gbp buildpackage` for each repo. That'd give you the entire flow of the build.
Sounds great!
9:33 p.m.
On 06/23/2016 11:25 AM, Ritesh Raj Sarraf wrote:
PS: After having written this email, I think there may not be that
much work. If
we can get 1 revision of the -fb based package imported into the Debian
packaging in Experimental, it'd be very easy to just push further incremental
uploads.
For convenience, I've cloned the Debian LIO Packaging repos at github. They
contain the entire packaging + source, in git-buildpackage workflow.
https://github.com/rickysarraf/configshell
To try out the current packages, you can just clone them, and then run
`gbp buildpackage` for each repo. That'd give you the entire flow of the build.
I've been trying to get this going since I'd really like to see this
happen, using configshell-fb as an example, but I just don't have a good
enough of a grasp of how Debian packaging works to do this without
spending a week learning everything.
So I have:
* Your repo
* The new upstream tarball:
https://fedorahosted.org/released/targetcli-fb/configshell-fb-1.1.fb20.ta...
...I have no idea where the upstream tarball is specified, so I can't
substitute the new one. I think I'm missing something obvious. Something
to do with .dsc files???
Please help? Maybe if someone can do configshell-fb, I can glean enough
understanding to help more with targetcli-fb.
Regards -- Andy
p.s. one other wrinkle, configshell-fb should be parallelly-installable
with configshell, because it's using "configshell_fb" as the library name.
7:47 a.m.
Hello Andy,
I am currently on travel, so please expect some delay in responses.
On Mon, 2016-06-27 at 19:33 -0700, Andy Grover wrote:
On 06/23/2016 11:25 AM, Ritesh Raj Sarraf wrote:
> PS: After having written this email, I think there may not be that much
> work. If
> we can get 1 revision of the -fb based package imported into the Debian
> packaging in Experimental, it'd be very easy to just push further
> incremental
> uploads.
>
> For convenience, I've cloned the Debian LIO Packaging repos at github. They
> contain the entire packaging + source, in git-buildpackage workflow.
>
> https://github.com/rickysarraf/configshell
>
> To try out the current packages, you can just clone them, and then run
> `gbp buildpackage` for each repo. That'd give you the entire flow of the
> build.
I've been trying to get this going since I'd really like to see this
happen, using configshell-fb as an example, but I just don't have a good
enough of a grasp of how Debian packaging works to do this without
spending a week learning everything.
So I have:
* Your repo
* The new upstream tarball:
https://fedorahosted.org/released/targetcli-fb/configshell-fb-1.1.fb20.ta...
...I have no idea where the upstream tarball is specified, so I can't
substitute the new one. I think I'm missing something obvious. Something
to do with .dsc files???
Please help? Maybe if someone can do configshell-fb, I can glean enough
understanding to help more with targetcli-fb.
The packaging follows the git-buildpackage workflow.
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html
So everything is maintained in git. When triggering a build, it checks out the
respective version (using a git tag, or pristine-tar if using a tarball) and
then applies the Debian packaging work on top of it.
In case of configshell, it is using the pristine-tar feature. In the cloned
repository, you'll find a branch named pristine-tar. This branch holds the 1st
tarball and deltas of the following versions. The full tarballs can be checked
out with the pristine-tar command.
Similarly, when you have a new tarball (like you mentioned above), you can add
it to the git workflow using the `gbp import-orig` command. It takes a tarball
and commits its delta to the pristine-tar branch.
Please give me some time. I think it'd be much easier if I did it myself. I
guess I'll do it once I'm back from travel.
Regards -- Andy
p.s. one other wrinkle, configshell-fb should be parallelly-installable
with configshell, because it's using "configshell_fb" as the library name.
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
8:52 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hello Andy and Christoph,
On Thu, 2016-06-30 at 18:17 +0530, Ritesh Raj Sarraf wrote:
Please give me some time. I think it'd be much easier if I did it myself. I
guess I'll do it once I'm back from travel.
This got pushed much more than what I anticipated. But as I promised, I've
prepared and uploaded configshell and targetcli to Debian Experimental, from the
tarballs from the -fb repository.
https://tracker.debian.org/news/787997
https://tracker.debian.org/news/788001
I've left out rtslib because Thomas Goirand is maintaining it already, and he
told me that he'd like to continue maintaining it under the pkg-openstack
umbrella. One less package to worry about for us.
Right now I've uploaded both the packages to Debian Experimental. They are very
basic. I just switched the sources and corrected some dependencies (for rtslib-
fb). I haven't tested it yet.
What needs to be done now:
* Christoph had a comment about a convert-to-json script. Now that the packages
are in experimental, this needs to be taken care of.
* Upgrades from the current Unstable version to the Experimental version should
be tested.
I'm hoping, now that the packages are in experimental, and can simply be
installed with apt-get, you can help improve it.
The packaging git repos:
https://anonscm.debian.org/cgit/linux-target/targetcli.git/log/?id=refs/h...
perimental
https://anonscm.debian.org/cgit/linux-target/configshell.git/log/?id=refs...
experimental
- --
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXn1QqAAoJEKY6WKPy4XVpjAgP+QHzyWxkyLhAL3yafhIRLyEJ
l06kcPNNlSyA5GtzFFUU7V07fVuYd8G824PKbLZDuTchDiP+wlep+KFWI2/n7JRt
zIznJ5WxoyBudpr/ooQGbyKUeC27TploRzN1uUOZp3FyHdOHrz8c2N/weaSlGekC
C8RdS7bwKLvWKWAo8Zheua+moc1kqOOOEf3unEzOdTvygHc7cEw0as/QteF9aoZO
JqJPp9BKBu4b8KNLCXrx4CLaYivnixJQZTjkMF6YJhHc6GlTEiAopgQm1CK6lMnu
0HwG2Nbx/Q38SJazT0MSal1B7S6ICGul9hTar/ktQATsYNbccqVrLpz9AFJKsyHo
kjby7cXxzNDkeTXo6tMG9LDoyMYqnMGhyUvgVBFUL0xd8GMDXJYcuOUWk79b2seR
OdYEJmT4esAcjf153MdqQPyIDaxz5k62pvs6Woy1a1wy0bMHDlIMCrajzMu5z+OH
vtEMu64sJx8HmUuBWbOs9qePM2BpzUH87uax4qD1kLgb3FXyPAqCwrBOC6QAo7NC
Myl0IV5bamulEgcIHm/TivM5zlK6376d003xqZicu9HBja9+5m4E2ZMRkxjYWt/J
1u3u4Pwe8O/mhpdllThENA0+mdLWw1Vax/WM4Gs22NfJ71HLrRuETqxrsqU92G1x
ogYMb3jJR/w8HNU/TKaR
=TqPy
-----END PGP SIGNATURE-----
3:21 p.m.
On 08/01/2016 06:52 AM, Ritesh Raj Sarraf wrote:
Right now I've uploaded both the packages to Debian Experimental.
They are very
basic. I just switched the sources and corrected some dependencies (for rtslib-
fb). I haven't tested it yet.
Thanks! Great to hear! :-)
What needs to be done now:
* Christoph had a comment about a convert-to-json script. Now that the packages
are in experimental, this needs to be taken care of.
OK, let's talk about this for a sec. For upgrade purposes, can we assume
the configuration has been pushed live to configfs by the old version?
Let's call this 'online conversion'. If so then a little bit of logic to
check old version num and verify a saveconfig.json doesn't exist would
do the trick, we just call 'targetctl save' and we're done.
If we cannot rely on old rtslib having pushed its settings to configfs
(let's call this 'offline conversion') then yes there's more work to do
to verify the convert-to-json script works ok.. Another approach would
be to fix some problems in the Datera rtslib parser that prevent us from
using its own schema definition to parse the file into something more
easily jsonifiable.
* Upgrades from the current Unstable version to the Experimental
version should
be tested.
You bet. I'm just looking for your call on if online conversion is
satisfactory, or whether I need to work on offline.
I'm hoping, now that the packages are in experimental, and can
simply be
installed with apt-get, you can help improve it.
This will certainly make it much easier for me! :)
Thanks again -- Regards -- Andy
3:15 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Dear Ritesh,
I am interested in having targetcli-fb in Debian and would like to help.
I looked at your packages and I have a few remarks.
I am bothered by the packages being named "targetcli" and
"python-configshell" because they come from the "free branch" (fb)
fork. I would prefer them to be named "targetcli-fb" and
"python-configshell-fb" respectively. I think it would clearly
indicate where they come from.
So I suggest changing the name to "targetcli-fb" and
"python-configshell-fb" and adding a "Conflicts: targetcli" and
"Conflicts: python-configshell" in their "control" files.
Moreover, you should adjust the "Homepage" tags in both packages: they
currently point to Datera's GitHub repositories instead of the
repositories of the open-iscsi organization.
In the "python-configshell-fb" package, you can drop the dependency to
"python-epydoc" because it was made optional at runtime:
https://github.com/open-iscsi/configshell-fb/commit/672a80e253a67439168fe...
Also in the "python-configshell-fb" package, you should replace the
"python-simpleparse" dependency with "python-pyparsing".
Both packages should depend on "python-six" which is used to make
their code compatible with Python 2 and Python 3.
Speaking of Python 3, you should probably provide packages for Python
3 as well and even make "targetcli-fb" available for Python 3 only.
If you are interested, I can work on patches to fix the issues I
mentioned and send them to you.
With best regards,
- --
Christophe Vu-Brugier
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJXugwAAAoJEAg5C33y/Bh2VK4QAJxYm7pc+ourGa0hhd3xSKeg
BUOzFouSOr9Mrwzg51Ttw8j+msUW80lkBj2+m+v19rRh4d6aHgIZbMhHH3b+I4CX
+nQeOXpl2Ez/AulQrzsmPDORY13sWMd9Ep+eOmJZ2f3WrOT8U+JuUqI/dQoVP2Ck
fUBetshlKmo8b7ASFFk4Qk6rVPebu725+rl8ZIIOBn1fS6calzAlTZlZAv/je6Rp
Pes8SRsXKTO+u5GDehRjv2LBZF29z2OsTAHE3qplO4sD3VtpN+gZmZs+xFUhqdrM
CvgzTSyVuVrp4MGm9GuHTjaKuzjE0qprzUx71rMAxyqnZa2W8enC9H5Sk2J6EN3q
8+lQQtgStIY1poKP7flY/ecj23/61Lj7m3HTXFYsQ3U4J/IrJ2FNKyJvA+r2mGgA
KTtr8r1MlxIUX0LMx2xuMWILR/l9ph5x9uMmYwY9KnSK8vv3lq63vTJ3vYIw1me4
HkW7DLWcNk+bxg/q/V6o3h7Irqih1ZFGphaW7l6tjH2DtnDmravLDGuzBnmnYKxa
TwNdMLcDhztgLd3rOiXs9qyf8PN+mWp5AI49oQrP0zUJf26WnWnCXjPWnaLDZS/p
XeHhwFEMwJ8ZTwaDohQOZ8QkdvfyR+71iZ/fKFbjw/LrfwP7KZM47d3ljer5+nqR
LGr+KBvsFE7VEXwNz6iQ
=VoKC
-----END PGP SIGNATURE-----
7:24 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hello Christophe,
On Sun, 2016-08-21 at 22:15 +0200, Christophe Vu-Brugier wrote:
Dear Ritesh,
I am interested in having targetcli-fb in Debian and would like to help.
I looked at your packages and I have a few remarks.
I am bothered by the packages being named "targetcli" and
"python-configshell" because they come from the "free branch" (fb)
fork. I would prefer them to be named "targetcli-fb" and
"python-configshell-fb" respectively. I think it would clearly
indicate where they come from.
So I suggest changing the name to "targetcli-fb" and
"python-configshell-fb" and adding a "Conflicts: targetcli" and
"Conflicts: python-configshell" in their "control" files.
My initial thought was to just switch the sources and leave the name alone. But
I too think the cleaner approach will be to add them with the new name.
Once the -fb packages are clean and in shape, we can simply orphan the older
ones and ask for their removal.
Moreover, you should adjust the "Homepage" tags in both
packages: they
currently point to Datera's GitHub repositories instead of the
repositories of the open-iscsi organization.
In the "python-configshell-fb" package, you can drop the dependency to
"python-epydoc" because it was made optional at runtime:
https://github.com/open-iscsi/configshell-fb/commit/672a80e253a67439168fef41
1804d9459ae086e0
Fantastic. This will cut out much of the bloat that gets pulled in.
Also in the "python-configshell-fb" package, you should
replace the
"python-simpleparse" dependency with "python-pyparsing".
Both packages should depend on "python-six" which is used to make
their code compatible with Python 2 and Python 3.
Speaking of Python 3, you should probably provide packages for Python
3 as well and even make "targetcli-fb" available for Python 3 only.
If you are interested, I can work on patches to fix the issues I
mentioned and send them to you.
Yes. Please do so. I'm open to the changes you've mentioned.
Just let me know where to pull from. We'll put a couple of package uploads in
experimental first. Then we can setup an LIO target with those packages, test,
and eventually push them to Unstable.
We still have time to have the -fb packages replace the Datera ones before the
freeze. But the sooner we do, the better testing/feedback we may get.
With best regards,
Thank you for your interest and help.
Ritesh
- --
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXuu8PAAoJEKY6WKPy4XVpGmwP/1zDUIxLqRDLUe/1eT+4CUll
hLAmzHarlRBTpVMjydGt0QCiPndyDTFB1GFRE/OHJ9+gjXMfrQJfPEqucvnl86x3
1Rym3tVgOlcbOJ9lfL9l1kjcIP6jnJwEm5rmxkQNfzTltH++RbXXofCtZ/k5wCXM
n006vlXpeAG12c+9RlZ7Ma2LxDA7frZpOhfPAPYVfX/91Px+ypxhn6hA6a7nvBPc
T7pDrR1DmAW0gjdj0oxogHpsQ/FQuGjJQ6q21AtduZgTXIwheMtxbw59DP18od1d
UL8X1HVWxwrrwf/ygOzEjRQyFgIAV5h7fhSuhe4V/giO0rkEPQeB0ppVh2OJ5qMg
ZVwW0gpO9+PjQr3SH9LCm/K1naZCUd2cJ7sfmpVxkH0WdRLe+IVvWxjJS7IOHzM3
wKKHuPCtJMOau+naktwECMzb2fY4hpr289Vk6mH7p51S1CFPxdIimZJxn/McvxIF
J9EO6SEBHW1SGAJE5hgeWzeOec6lorp/mtoqt/eF01tBlBS637aLc0ook31bpXKS
6qvLs+d3+D/m/amrX3zx3h4hqKMpT/Hq8oHo0hQ4gZkLCYcPTiTCK0MelEKyGf5p
e1yunJvbL4M37cc/gaHZDUC1Hcuv2zjgCnxKC4+Dqy7hinb9yyEwZ959Jd2dBMAV
X9/da75i4WKzyPVq98Lo
=M16b
-----END PGP SIGNATURE-----
9:16 a.m.
Hi Ritesh,
On Mon, 22 Aug 2016 17:54:47 +0530, Ritesh Raj Sarraf wrote :
> If you are interested, I can work on patches to fix the issues
I
> mentioned and send them to you.
Yes. Please do so. I'm open to the changes you've mentioned.
Just let me know where to pull from. We'll put a couple of package uploads in
experimental first. Then we can setup an LIO target with those packages, test,
and eventually push them to Unstable.
I think I will base my work on the debian packaging bits we already
have upstream in "configshell-fb" and "targetcli-fb" and submit my
changes to the upstream repositories.
Our debian packages are probably not perfect but people regularly send
fixes for them, so I guess the packages are installable at least.
Also, it will be easier for me to work on GitHub and for you and others
to comment and track the progress of our Debian packaging initiative.
At the end, you should be able to extract the changes made upstream and
merge them in your Debian repositories hosted on "anonscm.debian.org".
If you see a better way to proceed, please feel free to tell me.
Best regards,
--
Christophe Vu-Brugier
4:02 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Tue, 2016-08-23 at 16:16 +0200, Christophe Vu-Brugier wrote:
I think I will base my work on the debian packaging bits we already
have upstream in "configshell-fb" and "targetcli-fb" and submit my
changes to the upstream repositories.
Our debian packages are probably not perfect but people regularly send
fixes for them, so I guess the packages are installable at least.
Packaging in Debian is more than just preparing the deb. It requires integrating
with the rest of the OS, compliance with the policy etc.
You can contribute to the upstream repo. We'll have a look when we work on it
again.
Thanks,
Ritesh
- --
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXvWKuAAoJEKY6WKPy4XVpSm8P/iTB/+pPn56BW2DNuvThRK2z
bWGvxmdxCEWX/kzjsjLzoEJBPeRayH5Q2dR8+lxtoKEaUR0Qlk2qq6CZLM6j/UWc
07luJiT3BbOka1+GUTVTHdh0l+N33F2JZv7QHd31ycyEebhvVi9G2s0FUz2a0sIL
/loo9rf1g9S/J0RiZtSNsj1M3n6RMHvyANaBV53zyqLr3ukcvQ/mwHT6iTgTya/8
+ad/ookFkVpmZUR1F1C7spkWLwkmpJ0BY+g6MfUgCa9wDA85t2YVuiMh6fcdCWub
0T/IBVk4l7IEGrKGlLiST5fSRYBT+EUkZaQgW2oD4o5vv/Jzfw/hdNi+Ew1m4qMA
twQAFaChvJHA6ofQ1d3vqlTjSztU/aJuVwO8JOdf5LM1AsZHaUM5FkJ27k+fDHd1
yERnT7SaeSFKzjlengBVhyfAU2reWfIaaeSBTrtRU1GqJwUV9Gehk8GsVSFAg/Ej
n80afHrbyB+3lH0GJAe0cfN+J1AjdOGOkFX3RGBmMAYFRmsJj+gWB8moukHU8xYX
NnLyb3llro8AgxYpVhWjcRkYOrUQowWnyZN+u94QLCM8GQ79VuqkG6unp9uNr1+E
DUKa+eg0hRymh9gh5RPOHvDJyClBCWk5/DSMHZxUayEuJjD4Z3YuylDLjVSqNXV+
CP5IBiXqdg5QS4Xa4iuS
=lX42
-----END PGP SIGNATURE-----
8:04 a.m.
Hi Ritesh,
On Wed, 24 Aug 2016 14:32:38 +0530, Ritesh Raj Sarraf wrote :
You can contribute to the upstream repo. We'll have a look when
we work on it
again.
I created a pull request upstream on GitHub:
https://github.com/open-iscsi/configshell-fb/pull/25
There are some questions left in the pull request that I copy paste
here. Feel free to join the discussion on GitHub or discuss the changes
by email.
With best regards,
===
The purpose of this patch serie is to improve our Debian packaging so
that Debian can leverage our work to properly integrate configshell-fb.
Most of the patches are inspired by what @thomasgoirand did to package
rtslib-fb in Debian.
To @agrover, please do not merge my patches immediately because I would
like @rickysarraf to have enough time to review my changes.
The changes are quite straightforward. I will just describe what is
missing and what Debian developers may do in addition.
# Parts that should be discussed
## Content of debian/copyright
The copyright file should be updated. As reported by `lintian`, the
format is wrong and should follow the [Debian copyright
format](http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/).
More importantly, the content is probably wrong but I am not sure who
the copyright holders are and what to put exactly in this file. Some
help would be appreciated.
## Version in debian/changelog
Upstream version numbers in rtslib-fb, configshell-fb and targetcli-fb
follow this scheme: **X.Y.fbZ**. However, the rtslib-fb package in
Debian drops the **fb** string from the version number (e.g. version
**2.1.57** instead of **2.1.fb57**).
I did the same in configshell-fb's fake changelog, but I have no strong
opinion.
## Presence of the debian directory upstream
The Debian package maintainer of rtslib-fb reported that having a
debian directory upstream causes [some pain to Debian
packagers](https://github.com/open-iscsi/rtslib-fb/issues/59)
For now, I think it is easier to keep the debian directory until the
configshell-fb package lands in Debian stable or testing. At that
point, we may instruct people to simply use or rebuild Debian packages
and rename or remove the debian directory.
# Parts that are not included and that Debian packagers should add
## Vcs-Browser and Vcs-Git in debian/control
Our upstream control file does not contain Vcs-Browser and Vcs-Git tags
but the final control file in Debian should have them pointing to
anonscm.debian.org.
## Git-buildpackage configuration file
There is no **gbp.conf** file in this patch serie since it makes no
sense upstream.
===
--
Christophe Vu-Brugier
4:31 a.m.
Hi Ritesh,
On Fri, 26 Aug 2016 15:04:03 +0200, Christophe Vu-Brugier wrote :
On Wed, 24 Aug 2016 14:32:38 +0530, Ritesh Raj Sarraf wrote :
> You can contribute to the upstream repo. We'll have a look when we work on it
> again.
I created a pull request upstream on GitHub:
https://github.com/open-iscsi/configshell-fb/pull/25
I wrote similar patches to improve Debian packaging in targetcli-fb as
well:
https://github.com/open-iscsi/targetcli-fb/pull/68
Did you have the opportunity to look at the changes? Are these changes
good enough to be part of the configshell-fb and targetcli-fb packages
you maintain for Debian?
With best regards,
There are some questions left in the pull request that I copy paste
here. Feel free to join the discussion on GitHub or discuss the changes
by email.
With best regards,
===
The purpose of this patch serie is to improve our Debian packaging so
that Debian can leverage our work to properly integrate configshell-fb.
Most of the patches are inspired by what @thomasgoirand did to package
rtslib-fb in Debian.
To @agrover, please do not merge my patches immediately because I would
like @rickysarraf to have enough time to review my changes.
The changes are quite straightforward. I will just describe what is
missing and what Debian developers may do in addition.
# Parts that should be discussed
## Content of debian/copyright
The copyright file should be updated. As reported by `lintian`, the
format is wrong and should follow the [Debian copyright
format](http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/).
More importantly, the content is probably wrong but I am not sure who
the copyright holders are and what to put exactly in this file. Some
help would be appreciated.
## Version in debian/changelog
Upstream version numbers in rtslib-fb, configshell-fb and targetcli-fb
follow this scheme: **X.Y.fbZ**. However, the rtslib-fb package in
Debian drops the **fb** string from the version number (e.g. version
**2.1.57** instead of **2.1.fb57**).
I did the same in configshell-fb's fake changelog, but I have no strong
opinion.
## Presence of the debian directory upstream
The Debian package maintainer of rtslib-fb reported that having a
debian directory upstream causes [some pain to Debian
packagers](https://github.com/open-iscsi/rtslib-fb/issues/59)
For now, I think it is easier to keep the debian directory until the
configshell-fb package lands in Debian stable or testing. At that
point, we may instruct people to simply use or rebuild Debian packages
and rename or remove the debian directory.
# Parts that are not included and that Debian packagers should add
## Vcs-Browser and Vcs-Git in debian/control
Our upstream control file does not contain Vcs-Browser and Vcs-Git tags
but the final control file in Debian should have them pointing to
anonscm.debian.org.
## Git-buildpackage configuration file
There is no **gbp.conf** file in this patch serie since it makes no
sense upstream.
===
--
Christophe Vu-Brugier
6:26 a.m.
Hi Christophe,
Am 5. September 2016 11:31:02 MESZ, schrieb Christophe Vu-Brugier
<cvubrugier(a)fastmail.fm>:
Hi Ritesh,
On Fri, 26 Aug 2016 15:04:03 +0200, Christophe Vu-Brugier wrote :
> On Wed, 24 Aug 2016 14:32:38 +0530, Ritesh Raj Sarraf wrote :
> > You can contribute to the upstream repo. We'll have a look when we
work on it
> > again.
>
> I created a pull request upstream on GitHub:
>
> https://github.com/open-iscsi/configshell-fb/pull/25
I wrote similar patches to improve Debian packaging in targetcli-fb as
well:
https://github.com/open-iscsi/targetcli-fb/pull/68
Did you have the opportunity to look at the changes?
I co-maintain the open-iscsi initiator in Debian together with Ritesh. I've recently
offered to also help with the LIO target, which is why Ritesh added me to Cc.
I'm nearly done reviewing the configshell packaging (only started just now because I
had other things to do that came up, sorry) and my general impression is really good; so
far I have only nitpicks. I'll send a full review this evening. I'll also take a
look at the targetcli-fb branch, but that might take me till tomorrow.
No idea if Ritesh will have additional comments, but I'm confident the packages are in
a good enough shape to be uploaded very, very soon.
If you are interested in also co-maintaining this in Debian in the long term, you could
already register for an alioth guest account so that Ritesh could add you to the group
once the packaging is imported there.
Thanks a lot for the work you put in,
and sorry for the long delay on my part,
Christian
(Excuse the formatting please, sending this from my phone.)
8:26 a.m.
Hi Christian,
On Mon, 05 Sep 2016 13:26:09 +0200, Christian Seiler wrote :
Am 5. September 2016 11:31:02 MESZ, schrieb Christophe Vu-Brugier
<cvubrugier(a)fastmail.fm>:
>Hi Ritesh,
>
>On Fri, 26 Aug 2016 15:04:03 +0200, Christophe Vu-Brugier wrote :
>> On Wed, 24 Aug 2016 14:32:38 +0530, Ritesh Raj Sarraf wrote :
>> > You can contribute to the upstream repo. We'll have a look when we
>work on it
>> > again.
>>
>> I created a pull request upstream on GitHub:
>>
>> https://github.com/open-iscsi/configshell-fb/pull/25
>
>I wrote similar patches to improve Debian packaging in targetcli-fb as
>well:
>
> https://github.com/open-iscsi/targetcli-fb/pull/68
>
>Did you have the opportunity to look at the changes?
I co-maintain the open-iscsi initiator in Debian together with Ritesh. I've recently
offered to also help with the LIO target, which is why Ritesh added me to Cc.
I'm nearly done reviewing the configshell packaging (only started just now because I
had other things to do that came up, sorry) and my general impression is really good; so
far I have only nitpicks. I'll send a full review this evening. I'll also take a
look at the targetcli-fb branch, but that might take me till tomorrow.
No idea if Ritesh will have additional comments, but I'm confident the packages are
in a good enough shape to be uploaded very, very soon.
Great! Thank you for your time reviewing these patches.
If you are interested in also co-maintaining this in Debian in the
long term, you could already register for an alioth guest account so that Ritesh could add
you to the group once the packaging is imported there.
Well, I have been a happy user of Debian for a long time so it is past
time I contribute back. For several years, I have been using a small
home server running Debian armv5tel and the LIO iSCSI target to backup
my machine. So I rely on Debian and LIO.
Also, I would like to package target-isns later (target-isns is an iSNS
client for the LIO iSCSI target).
So yes, I am interested in helping Ritesh and you maintain these
parts in Debian.
I will register for an alioth guest account.
With best regards,
Thanks a lot for the work you put in,
and sorry for the long delay on my part,
Christian
(Excuse the formatting please, sending this from my phone.)
--
Christophe Vu-Brugier
9:02 a.m.
New subject: Debian packaging: plan (was: Re: Help wanted: Debian packaging
effort)
Hi Christophe,
I'm terribly sorry that I didn't reply sooner, but a lot of non-Debian
related stuff came up. :-(
First of all, reading the email thread back, there seems to be a bit
of miscommunication and confusion here, so I'd like to clear this up
first.
I think we can all agree that it is a good idea to have the -fb branch
in Debian. I also think that your changes to upstream's Debian
packaging are a good starting point for that. I'll post a detailed
review in response to this message later, but the changes are minimal.
My suggested course of action would therefore be the following:
- I create repositories on Alioth underneath
https://anonscm.debian.org/cgit/linux-target
for configshell-fb and targetcli-fb.
- I import the latest release tarballs of both projects + the
debian/ directory from your pull request there.
- I add the changes I found during my review. (See my other email
later.)
- Ritesh adds you to that alioth group so you have commit access
there. (You'd need to tell him your Alioth guest account name.)
- We upload the -fb packages to sid. (With name -fb.) Since they
have different names as the original packages (without -fb),
this will not disrupt any users of the original packages for
now. (We can worry about a transition plan later.)
Would that be agreeable for all?
(Review of the changes in a separate email.)
Again, sorry for delaying my review so long. :-(
Regards,
Christian
9:19 a.m.
New subject: Debian packaging: configshell-fb review (was: Re: Debian packaging:
plan)
Hi again,
this is my review of the configshell-fb packaging.
debian/source/format
Should be 3.0 (quilt), not 3.0 (native). See [1] for details about
the distinction.
debian/copyright
I very much prefer DEP-5 style copyright files. I did some git
archeology and some analysis of the license grants in the code, and I
came up with the following:
https://github.com/chris-se/configshell-fb/blob/053e12e9364dc147668f77d80...
A detailed description of the format can be found under [2]. I've
added Ritesh and myself there for now, under the assumption that
we'll co-maintain this in Debian.
debian/rules
It works, but is _way_ too complicated. There is something called
pybuild in Debian [3], which does all the magic for different Python
versions automatically. And normally Python packages would work
automatically with that when using the dh(1) wrapper. The problem is
though that in your case there's a Makefile in the root directory, so
debhelper will assume a Makefile-based build system.
However, you can force debhelper to use pybuild and not try to auto
detect the build system by specifying -S in the dh line:
dh $@ --with python3,python2 -Spybuild
This will also take care of the proxy settings (to disable network
access) and all these things, simplifying debian/rules significantly:
https://github.com/chris-se/configshell-fb/blob/41d0149313cdf13441542807b...
This also has the advantage that changes to how Python packages are
managed in Debian are more likely to work just out of the box via
debhelper, instead of having to manually implement them oneself.
debian/control:
In Debian proper (though not upstream) there should be an Uploaders
field if the Maintainer: field is a mailing list. The natural
candidates for that field would be you (Christophe), Ritesh and
myself.
Also, a moderated list is a really bad idea for Maintainer: when the
pacakge is uploaded to Debian, because lots of automated mails go
there. Unfortunately, since Ritesh had been maintaining the LIO
stack himself in Debian so far, there's no mailing list for the
Alioth project available right now. For the initial upload to Debian
we could probably just move one of the Uploaders: to Maintainer:, and
organize a packaging mailing list later.
The Build-Depends/Build-Depends-Indep split is useless, since the
package only generates Architecture: all packages. Therefore I'd
suggest to simply put everything in Build-Depends.
When testing package build in a clean chroot, pyparsing was missing
as a build dependency.
The -doc package doesn't have Depends: ${misc:Depends}, even though
all packages should have that if debhelper is used. (Even though it
will not actually add anything there currently, that might change at
some point in the future.)
debian/changelog
Obviously that'll have to be updated (and an ITP be filed) before
this can be uploaded to Debian.
I've fixed all these things (except the Maintainer: field) in a fork
of your packaging branch on my github:
https://github.com/chris-se/configshell-fb/commits/debian-packaging
Regards,
Christian
[1]
https://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a...
[2] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
[3] https://wiki.debian.org/Python/Pybuild
10:29 a.m.
New subject: Debian packaging: targetcli-fb review (was: Re: Debian packaging:
plan)
Hi again,
this is my review of the targetcli-fb packaging.
The following things (many related to what I discussed in my
configshell-fb review, so I'm going to be terse here), I've
also fixed in a fork I pushed to github.
debian/pyversions: obsolete, esp. with Python3, remove it
debian/source/format: missing
debian/control:
- Uploaders: missing (see my configshell-fb mail for details)
- Build-Depends-Indep unnecessary (see my configshell-fb mail)
- Missing build-dependencies (unit tests fail import during
build time otherwise):
python3-configshell-fb
python3-rtlslib-fb
python3-dbus
debian/rules:
- can be vastly simplified via -Spybuild
debian/copyright: DEP-5 format would be nice, I did some git
archeology and created one
README.md, targetcli.8, setup.py:
- if you want to package upstream, based on tarballs (as is
proper in Debian), you need to make sure that the contents
of everything _except_ the debian/ directory is identical
to the contents of the tarball. In this case, there were
two more commits in the main repository since the last
releease before you added your Debian packaging changes.
There are two ways around this: either use a git snapshot
as the base version (with a custom orig tarball), or don't
have these changes except as debian/patches (that will be
dropped after the next upstream release).
I've opted for the second here, just to show you how the
3.0 (quilt) format works (and hence have reverted the
changes in the tree). Therefore: DO NOT MERGE MY CHANGES.
They are just an illustration of how debian packaging can
look like.
The proper way to do this would be to branch off the
branch containing the Debian packaging from the upstream
release (and merging continuously).
This demonstrates why maintaining Debian packaging in an
upstream repository is not necessarily a good idea,
because it really complicates these kinds things.
What I liked about the package is that it's now Python3 based, I
really want to get rid of Python2-only stuff ASAP. :-)
Anyway, you'll find my updates here:
https://github.com/chris-se/targetcli-fb/commits/debian-packaging
As I said, because of the upstream commits since release and
debian/patches situation: DO NOT MERGE this.
That all said, there's one major issue that isn't resolved here:
There's no startup logic! I see neither init script nor systemd
service file. There was something upstream (that was minimally
patched in Debian) in the old version, but that's gone now, as
far as I can tell. In that case, the correct course of action for
Debian packaging would be to add this in the debian/ directory and
install it from there. I don't have time to fix that today, and I
think this is something that can wait until after the packaging
is imported into Alioth. But just to keep in mind that this needs
to be done before the package can enter Debian.
Anyway, if I hear positive feedback from both you (Christophe) and
Ritesh about getting this onto Alioth ASAP, I'll just rebase your
commits on the actual upstream version (and not previous git master)
when adding your commits to the packaging repository.
Regards,
Christian
1 p.m.
New subject: Debian packaging: targetcli-fb review (was: Re: Debian
packaging: plan)
On Sun, 18 Sep 2016 17:29:16 +0200, Christian Seiler wrote :
Hi again,
this is my review of the targetcli-fb packaging.
[snip]
I agree with all your changes.
That all said, there's one major issue that isn't resolved
here:
There's no startup logic! I see neither init script nor systemd
service file. There was something upstream (that was minimally
patched in Debian) in the old version, but that's gone now, as
far as I can tell. In that case, the correct course of action for
Debian packaging would be to add this in the debian/ directory and
install it from there. I don't have time to fix that today, and I
think this is something that can wait until after the packaging
is imported into Alioth. But just to keep in mind that this needs
to be done before the package can enter Debian.
As you observe, there is no startup logic in targetcli-fb. The startup
logic is provided by rtslib-fb which contains a utility named
"targetctl".
I would describe targetctl as a trimmed down version of targetcli.
It accepts only three commands to restore, save or clear the
configuration. Moreover, it is not interactive so it does not depend on
configshell-fb.
https://github.com/open-iscsi/rtslib-fb/blob/master/scripts/targetctl
In Debian, the python-rtslib-fb package maintained by Thomas Goirand as
part of Open Stack contains the targetctl utility. The package also
contains an init script but no systemd service file.
http://git.openstack.org/cgit/openstack/deb-python-rtslib-fb/tree/debian/...
Anyway, if I hear positive feedback from both you (Christophe) and
Ritesh about getting this onto Alioth ASAP, I'll just rebase your
commits on the actual upstream version (and not previous git master)
when adding your commits to the packaging repository.
My feedback is definitely positive.
With best regards,
--
Christophe Vu-Brugier
1:10 p.m.
New subject: Debian packaging: targetcli-fb review
On 09/18/2016 08:00 PM, Christophe Vu-Brugier wrote:
As you observe, there is no startup logic in targetcli-fb. The
startup
logic is provided by rtslib-fb which contains a utility named
"targetctl".
Ah, good to know, then targetcli doesn't need that anymore. :)
And I just now saw the long email you sent about rtslib to Thomas
and Cc'd me. (Sorry, I missed that.) Ok, then let's discuss this
there, I'll probably reply to that long email tomorrow.
Thanks for the pointer.
Regards,
Christian
12:23 p.m.
New subject: Debian packaging: targetcli-fb review (was: Re: Debian
packaging: plan)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Sun, 2016-09-18 at 20:00 +0200, Christophe Vu-Brugier wrote:
> That all said, there's one major issue that isn't resolved here:
There's no startup logic! I see neither init script nor systemd
service file. There was something upstream (that was minimally
patched in Debian) in the old version, but that's gone now, as
far as I can tell. In that case, the correct course of action for
Debian packaging would be to add this in the debian/ directory and
install it from there. I don't have time to fix that today, and I
think this is something that can wait until after the packaging
is imported into Alioth. But just to keep in mind that this needs
to be done before the package can enter Debian.
As you observe, there is no startup logic in targetcli-fb. The startup
logic is provided by rtslib-fb which contains a utility named
"targetctl".
I may not be well up on the conversation, but could you please be specific on
what startup logic is not more in the new repos ?
The Datera init script ensured that the supporting infrastructure was enabled
and active. Like configfs, kernel modules etc.
Given that LIO is a service, wouldn't you want it to act that way ?
- --
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJX5BOgAAoJEKY6WKPy4XVp5J8P/jF/WOSi88niGW2lfux1R8EF
P+JMdtYD5Gm8bY2ewEKOPOHbG69VGn0QvyIHHTN5HVYO+3xSM9GS01AYCrHikgHO
2b661/6ssFCALu4CsC24EyZglQx0lBRUFY1Z0FfGUVoBQaNBSYa9tkrkZJDtGQyx
GYTGHnVurUVMxkHcjTnKlfqQxRaAs3n/fGY0FDzyJpaCumtQO+4sU2w53WuRbKIn
iIsl0vJ09rGhMdefziddLEr2JQ5ECf3d0yxX8Y2sPwGZ1Q4A+JspVqDkQyFBv0I9
sc7TRNJAPK9sIDxzjhEQwwAsz4d4wYPR34C0+6eoB+ezJpHXjewUfcZzBwLV6xGi
WFaP8cbv+YzGCInyR3aYEBPRUj9ceIlgSbRcaclHDfa3DthlzGZPZAeHjdEJHQMw
mCoGvfwPz7J875FDt65k6GRk4k3RVylmvmhtWafAhkkvB4IRZatqn9RrqhHLnB46
n+vmp+2ZiBV7MDNLGAazzabCOtl0Rbde88cJaD9fbzKdBESou4FauchkJFKG1YJl
fVrRnzQ2mgtN3teNF34mCXXslVLHot0SojAJXDXDIe09hU1O1sg9Xkjo+AjjFnu9
1sr2QW/x140U2WD6uosPHu0cjo1mTs9TtjHMOmn9m33ZNZQoITlnKcJwj+r6IC6b
870l2K4OGK/fg3oVQjPw
=43AW
-----END PGP SIGNATURE-----
2:04 p.m.
New subject: Debian packaging: targetcli-fb review
On 09/22/2016 10:23 AM, Ritesh Raj Sarraf wrote:
On Sun, 2016-09-18 at 20:00 +0200, Christophe Vu-Brugier wrote:
>
>> That all said, there's one major issue that isn't resolved here:
>
> There's no startup logic! I see neither init script nor systemd
> service file. There was something upstream (that was minimally
> patched in Debian) in the old version, but that's gone now, as
> far as I can tell. In that case, the correct course of action for
> Debian packaging would be to add this in the debian/ directory and
> install it from there. I don't have time to fix that today, and I
> think this is something that can wait until after the packaging
> is imported into Alioth. But just to keep in mind that this needs
> to be done before the package can enter Debian.
As you observe, there is no startup logic in targetcli-fb. The startup
logic is provided by rtslib-fb which contains a utility named
"targetctl".
I may not be well up on the conversation, but could you please be specific on
what startup logic is not more in the new repos ?
The Datera init script ensured that the supporting infrastructure was enabled
and active. Like configfs, kernel modules etc.
Given that LIO is a service, wouldn't you want it to act that way ?
rtslib-fb loads modules (if needed) and mounts configfs (if it isn't
already) so the init script should be just calling 'targetctl restore'.
HTH -- Regards -- Andy
12:37 p.m.
New subject: Debian packaging: plan (was: Re: Help wanted: Debian packaging
effort)
Hi Christian,
On Sun, 18 Sep 2016 16:02:02 +0200, Christian Seiler wrote :
I'm terribly sorry that I didn't reply sooner, but a lot of
non-Debian
related stuff came up. :-(
Thank you for your detailed review and your effort explaining me a lot
of tiny but important things regarding Debian packaging. Much
appreciated!
Among your changes, my favorite is your patch to force debhelper to use
pybuild.
First of all, reading the email thread back, there seems to be a bit
of miscommunication and confusion here, so I'd like to clear this up
first.
I think we can all agree that it is a good idea to have the -fb branch
in Debian. I also think that your changes to upstream's Debian
packaging are a good starting point for that. I'll post a detailed
review in response to this message later, but the changes are minimal.
My suggested course of action would therefore be the following:
- I create repositories on Alioth underneath
https://anonscm.debian.org/cgit/linux-target
for configshell-fb and targetcli-fb.
- I import the latest release tarballs of both projects + the
debian/ directory from your pull request there.
- I add the changes I found during my review. (See my other email
later.)
- Ritesh adds you to that alioth group so you have commit access
there. (You'd need to tell him your Alioth guest account name.)
- We upload the -fb packages to sid. (With name -fb.) Since they
have different names as the original packages (without -fb),
this will not disrupt any users of the original packages for
now. (We can worry about a transition plan later.)
Would that be agreeable for all?
I agree with you. My alioth guest account is cvubrugier-guest.
Thanks again for your review!
(Review of the changes in a separate email.)
Again, sorry for delaying my review so long. :-(
Regards,
Christian
--
Christophe Vu-Brugier
12:48 p.m.
New subject: Debian packaging: plan
Hi Christophe,
On 09/18/2016 07:37 PM, Christophe Vu-Brugier wrote:
On Sun, 18 Sep 2016 16:02:02 +0200, Christian Seiler wrote :
> I'm terribly sorry that I didn't reply sooner, but a lot of non-Debian
> related stuff came up. :-(
Thank you for your detailed review and your effort explaining me a lot
of tiny but important things regarding Debian packaging. Much
appreciated!
Glad to be of help.
Among your changes, my favorite is your patch to force debhelper to
use
pybuild.
:-)
This is one of the tricks that you just have to know about.
> [...]
> Would that be agreeable for all?
I agree with you.
Ok, then let's wait what Ritesh says, but if he's also OK with
that, I'll create the repositories and push your and my changes
there.
My alioth guest account is cvubrugier-guest.
Thanks. Ritesh will have to add you to the project, I'm only a
member but not an admin of the project.
Regards,
Christian
12:09 p.m.
New subject: Debian packaging: plan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
On Sun, 2016-09-18 at 19:48 +0200, Christian Seiler wrote:
>> [...]
>> Would that be agreeable for all?
>
> I agree with you.
Ok, then let's wait what Ritesh says, but if he's also OK with
that, I'll create the repositories and push your and my changes
there.
Yes. Thank you for your review Christian.
Please push your changes.
> My alioth guest account is cvubrugier-guest.
Thanks. Ritesh will have to add you to the project, I'm only a
member but not an admin of the project.
I have added Christophe to the team, and I've added the Admin role to your uid
Christian.
- --
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJX5BBfAAoJEKY6WKPy4XVpDssP/37hWOUNf/+tmV0stQnV7mFv
b8IsjMnsmECeMiLr+/kV25IktttstPA9+FpkAY4HgfgjIkd4wsKkKgHCFrU4pzgK
MNzmKCqglq2tfjducTsoC9o2RFLI4UswFfRBpGIHwiCmiOUtUj4aD+NrpjNUd2ZZ
Fjen47LoJdB33nawj/HZGFTcZ4v32itqTkhPD4t69wyXZZG6nhV0oaVI6Gxr0OgA
3V+km1gJM9ZkX+PjEe6XlGq9bJfdTzStjaJC0uRE3W1jaI6DZZlfK+xMmpT92Tty
r+2d8tIY833ZTZmQc5UXQAMUiy8gWMmcYMCMOio08qEcefbkyQe54GLLjHmP75mn
Zo5ahHkJSvBfNUb2ACIwgQ6w4uq8aa6XgQ6t5POg0StguO6ZVFjT1qs0x1fAtgqL
nyQWKh9vlAkkB2qtH/+gE9+i6L8ZP5GpWDy8E/6K4eIcG1Xf2NqLWNwiaoBut+nY
5OrdZM1jkWUXfa/cqZdXmv3dp4wqZfhUG9lm5Xbt00m4PQAo2AyVk7Q95NymDR05
NsHXBN5qzr5lDGadvUMH8mQQHJ/OEIyICjj0lbuHtUWJCSfcxQ+KUiY6lbu98yyQ
13KPhiUNa4HDpRmWUmztVynh25Y2Al9Ic7uiXlOPvloZkH4tTWM5PGA2ti0NF46Z
kvII84OFmVeU4o23xIj+
=UVoY
-----END PGP SIGNATURE-----
6:58 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Mon, 2016-09-05 at 11:31 +0200, Christophe Vu-Brugier wrote:
I wrote similar patches to improve Debian packaging in targetcli-fb
as
well:
https://github.com/open-iscsi/targetcli-fb/pull/68
Did you have the opportunity to look at the changes? Are these changes
good enough to be part of the configshell-fb and targetcli-fb packages
you maintain for Debian?
Sorry. This past week I've been very sick.
You can keep a generic debian/ packaging folder if you want. But you'd want to
have it as generic as possible. So that all .deb distributions could use it. It
would have nothing much to do with Debian distribution in particular. And you
may still have some Debian packager requesting for its removal.
I had mentioned the same to Jerome earlier.
Note: What you do with the debian/ packaging in the upstream repository will be
independent and unrelated of the packaging in Debian itself.
This thread's intent is to replace the Datera LIO stack with that of -fb ones,
for Debian. It is taking time, on my part, for personal reasons. And since I've
been maintaining it alone, the progress is slow. I'm hoping I'll have more
Debian contributors working on it soon, until then it'll have to wait.
The current version in Unstable (Datera one) took some time before it became
quite bug free. And that's why I'm not hurrying much. Lots of people are using
it as a stand-by target for most of their software testing.
The rest of the changes in your pull request look fine, except for the
versioning one.
Currently, in Debian, we have:
python-rtslib-fb:
Installed: (none)
Candidate: 2.1.57+debian-3
and
python-rtslib:
Installed: (none)
Candidate: 1:3.0~pre4.1~g1b33ceb-3
And Thomas did that because Openstack added a dependency on rtslib-fb.
So, I'd suggest you keep your (upstream) packaging as generic as possible. And
push the onus on the user to ensure there is no other copy installed, from
elsewhere.
BTW, Are you doing the same with Fedora ?
I see your spec file and it looks outdated to me.
- --
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJXzV3dAAoJEKY6WKPy4XVp4fMP/iqO2SS2zUv3v5BU/OIA8u3G
Dquw8jfstePBN7tZp+WK/ZxhlbP26ZfmlDPMb3nhojaCbi35/aHD8anxyyQGY1lF
yqsa8KiwjhMvKonKDKmhA/gtwnf8EwRXur5XSyQbj1umM0i3SLZjFkOsUe36paPH
fPMq17AFxxdh0t1gtHLXjtH0T/fBABNW7EMsfoP4F5N0UooJRToVz9xszWZ1pYYA
OHTn0Bo8lQYe+usL3Dzjjt4gupX7HGWbaYWg5vXNOdBtX18vLziVAtXDOSH5P2HS
odARInHqMa6cylQaMjq+0MyCyoPtNFWco7filWIWZ8BnUjJKA89i+ZwmixkOhh4h
nRz8FkJC9IiiAmXXAfIXxqaSSF2a9KxRg819kRn4jRrurY/GrvKfy+8DV5skK5GP
+A/RQ7d8JyQZDs0RYp/qqufftEOkVgqB7cg0f+j2BVtgrjiBpRlCt2GHj2bc5LRi
gdi+cojQJYs6hWHzVi4xWWT6DgO51B3+sORfaYokKMhUPwjwAyIHwkbsNyndQPj7
d8BuRPTgNAsU8KsxuHGrr1QTQR285x2latw7nlOuO+OKhDP8L+hI4bLdOEbazOlm
W425OZq0m86JJkblyHm7e/P1H1DYsLOWv96Eh1+ZldluhV2aq/GvEy6sB8hW+AaI
1L33UnxLp5FFoa3yH/Sj
=vHxN
-----END PGP SIGNATURE-----
10:23 a.m.
Hi Ritesh,
Thank you for your remarks,
On Mon, 05 Sep 2016 17:28:21 +0530, Ritesh Raj Sarraf wrote :
You can keep a generic debian/ packaging folder if you want. But
you'd want to
have it as generic as possible. So that all .deb distributions could use it. It
would have nothing much to do with Debian distribution in particular. And you
may still have some Debian packager requesting for its removal.
I had mentioned the same to Jerome earlier.
I am not necessarily in favor of keeping a debian/ packaging folder
upstream. We have some people that want to install targetcli-fb as a
Debian package. Since targetcli-fb is not part of Debian testing/stable
yet, we maintain a debian/ folder upstream so that they can build the
package themself.
But once targetcli-fb will be part of the Debian repository, people
will naturally install it from Debian with `apt`. At this time, we may
remove (or rename) the debian/ directory upstream.
In the upstream README.md, we may emphasize that packages for
targetcli-fb exist for Fedora, Suse and (soon) Debian and that this is
the preferred way to install targetcli-fb.
Note: What you do with the debian/ packaging in the upstream
repository will be
independent and unrelated of the packaging in Debian itself.
I understand. I hope that packaging in Debian can leverage my patches
upstream. After that, I would like to help you and Christian with
packaging in Debian.
This thread's intent is to replace the Datera LIO stack with that
of -fb ones,
for Debian. It is taking time, on my part, for personal reasons. And since I've
been maintaining it alone, the progress is slow. I'm hoping I'll have more
Debian contributors working on it soon, until then it'll have to wait.
The current version in Unstable (Datera one) took some time before it became
quite bug free. And that's why I'm not hurrying much. Lots of people are using
it as a stand-by target for most of their software testing.
The rest of the changes in your pull request look fine, except for the
versioning one.
Currently, in Debian, we have:
python-rtslib-fb:
Installed: (none)
Candidate: 2.1.57+debian-3
and
python-rtslib:
Installed: (none)
Candidate: 1:3.0~pre4.1~g1b33ceb-3
And Thomas did that because Openstack added a dependency on rtslib-fb.
So, I'd suggest you keep your (upstream) packaging as generic as possible. And
push the onus on the user to ensure there is no other copy installed, from
elsewhere.
I am confused by what "versioning" means here. Is that version number
(i.e. "2.1.57" or "2.1.fb57"), package name
("python-configshell" or
"python-configshell-fb"), or conflicts?
BTW, Are you doing the same with Fedora ?
I see your spec file and it looks outdated to me.
No. Andy Grover maintains packages for Fedora, so packaging work for
Fedora happens in Fedora (same for Suse I think). That's why the spec
file upstream has been left behind.
http://pkgs.fedoraproject.org/cgit/rpms/targetcli.git/
And likewise, I think that packaging work for Debian should happen in
Debian.
With best regards,
--
Christophe Vu-Brugier
7:18 a.m.
Hi,
On Wed, 22 Jun 2016 11:50:50 -0700, Andy Grover wrote :
I've been exchanging a few emails with Ritesh Raj Sarraf, the
Debian
maintainer of targetcli in Debian, about also getting targetcli-fb in
Debian main.
An update on this subject was long overdue: the targetcli-fb package
has been migrated to Debian testing a month ago. It is maintained by
Christian, Ritesh and me and will be part of Debian Stretch.
We invite Debian users to test it and report bugs.
One of the differences with the upstream targetcli-fb package is that
the saveconfig.json configuration file is currently stored in
/etc/rtslib-fb-target/ instead of /etc/target. So you may have to copy
your configuration file there if you previously installed targetcli-fb
from the sources.
Also, Ritesh wrote a blog post to share the current state of some
storage related packages in Debian (including targetcli-fb) and his
experience upgrading from targetcli to targetcli-fb:
https://www.researchut.com/blog/storage-debian-stretch
https://www.researchut.com/blog/lio-migration-to-fb
With best regards,
--
Christophe Vu-Brugier
2718
days inactive
2874
days old
targetcli-fb-devel@lists.fedorahosted.org
29 comments
5 participants
participants (5)
-
Andy Grover -
Christian Seiler -
Christoph Hellwig -
Christophe Vu-Brugier -
Ritesh Raj Sarraf