unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* netcat-openbsd implementations
@ 2016-06-29 12:13 ng0
  2016-07-03  9:52 ` Aron Xu
  0 siblings, 1 reply; 7+ messages in thread
From: ng0 @ 2016-06-29 12:13 UTC (permalink / raw)
  To: Aron Xu; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 2342 bytes --]

Hi,

I've seen you as the last person commiting to netcat-openbsd
for Debian in 2012[2].

I have written a package definition for netcat-openbsd for Guix.

At Guix we don't want to maintain forks through in-tree patchsets
and avoid it whenever possible. Patches are usually for fixing
CVEs and fixing severe build problems specific to guix.

Now this is a problem which is reflected in the thread at [0]
(discussing the netcat-openbsd package).

Resulting from the discussion I have questions for you:

1. I'd like to know if Debian could merge the specific changes
   applied to the OpenBSD package, available in the patches set,
   into the OpenBSD GNU-linux port.
   If this is not possible, could you give us the reason for it?
   My impression is that at least Gentoo, Gentoo deriviates and
   based systems, Archlinux, and Debian use the orig-source +
   the patches tarball.

2. Did you try to merge more generic changes back to OpenBSD?

   From what I've seen so far, those are bug fixes and a minority
   of feature fixes.

3. There's an initial statement in the README but as many of those
   are non-trivial patches, could you try and give an explanation
   on why they are needed,
   if they can't get merged into the Debian orig-source?


Third option I thought of, could Debian provide a tarball of
the orig-source with the patches applied, so there's no need
to conflict with systems currently pulling one or both of the
currently existing tarball.

We can apply all the patches in a way mentioned here [1], but
because we collectively maintain all the packages/source instead
of `n' specific packages per `n' specific developer(s) it would
be good in case Debian can't merge the changes to be able to
point to a reason.
For this, I ask for your permission to quote parts you give me
permission to use for, should for any reason this email
discussion not end up completely CC'ed on guix-devel.

[0]: https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00843.html
[1]: https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00909.html
[2]: http://anonscm.debian.org/cgit/collab-maint/netcat-openbsd.git/commit/debian?id=db2b1d9a8d4644ef892f47d84606ee96598d23fb


thanks,
--
♥Ⓐ  ng0
For non-prism friendly talk find me on
psyced.org / loupsycedyglgamf.onion

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: netcat-openbsd implementations
  2016-06-29 12:13 netcat-openbsd implementations ng0
@ 2016-07-03  9:52 ` Aron Xu
  2016-07-07 10:10   ` ng0
  0 siblings, 1 reply; 7+ messages in thread
From: Aron Xu @ 2016-07-03  9:52 UTC (permalink / raw)
  To: ng0; +Cc: guix-devel

Hi,

See comment below,

On Wed, Jun 29, 2016 at 8:13 PM, <ng0@we.make.ritual.n0.is> wrote:
>
> Hi,
>
> I've seen you as the last person commiting to netcat-openbsd
> for Debian in 2012[2].
>
> I have written a package definition for netcat-openbsd for Guix.
>
> At Guix we don't want to maintain forks through in-tree patchsets
> and avoid it whenever possible. Patches are usually for fixing
> CVEs and fixing severe build problems specific to guix.
>
> Now this is a problem which is reflected in the thread at [0]
> (discussing the netcat-openbsd package).
>
> Resulting from the discussion I have questions for you:
>
> 1. I'd like to know if Debian could merge the specific changes
>    applied to the OpenBSD package, available in the patches set,
>    into the OpenBSD GNU-linux port.
>    If this is not possible, could you give us the reason for it?
>    My impression is that at least Gentoo, Gentoo deriviates and
>    based systems, Archlinux, and Debian use the orig-source +
>    the patches tarball.
>

This is long overdue - my intention was to keep netcat-openbsd to
track the development of the openbsd one, but it appears not happened
that way.

> 2. Did you try to merge more generic changes back to OpenBSD?
>
>    From what I've seen so far, those are bug fixes and a minority
>    of feature fixes.
>

Some of them was sent, but getting few responses.

> 3. There's an initial statement in the README but as many of those
>    are non-trivial patches, could you try and give an explanation
>    on why they are needed,
>    if they can't get merged into the Debian orig-source?
>

I don't treat this netcat-openbsd a full fork even if it's targeting
an older revision at the moment. Also, maintaining patches are very
easy using the git-buildpackage[1] tools for Debian packages.

[1]https://wiki.debian.org/PackagingWithGit

>
> Third option I thought of, could Debian provide a tarball of
> the orig-source with the patches applied, so there's no need
> to conflict with systems currently pulling one or both of the
> currently existing tarball.
>

I think it is hardly possible to provide another tarball because
there's no way of doing that with current Debian infrastructure. But
you can apply those patches easily using quilt[2]. In Debian, patches
are applied automatically when extracting the source package using
dpkg-source.

[2]https://wiki.debian.org/UsingQuilt

> We can apply all the patches in a way mentioned here [1], but
> because we collectively maintain all the packages/source instead
> of `n' specific packages per `n' specific developer(s) it would
> be good in case Debian can't merge the changes to be able to
> point to a reason.
> For this, I ask for your permission to quote parts you give me
> permission to use for, should for any reason this email
> discussion not end up completely CC'ed on guix-devel.
>

No problem.

> [0]: https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00843.html
> [1]: https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00909.html
> [2]: http://anonscm.debian.org/cgit/collab-maint/netcat-openbsd.git/commit/debian?id=db2b1d9a8d4644ef892f47d84606ee96598d23fb
>
>
> thanks,
> --

Best,
Aron

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: netcat-openbsd implementations
  2016-07-03  9:52 ` Aron Xu
@ 2016-07-07 10:10   ` ng0
  2016-07-12  9:19     ` Ludovic Courtès
  0 siblings, 1 reply; 7+ messages in thread
From: ng0 @ 2016-07-07 10:10 UTC (permalink / raw)
  To: Aron Xu; +Cc: guix-devel

Aron Xu writes:

> Hi,
>
> See comment below,
>
> On Wed, Jun 29, 2016 at 8:13 PM, <ng0@we.make.ritual.n0.is> wrote:
>>
>> Hi,
>>
>> I've seen you as the last person commiting to netcat-openbsd
>> for Debian in 2012[2].
>>
>> I have written a package definition for netcat-openbsd for Guix.
>>
>> At Guix we don't want to maintain forks through in-tree patchsets
>> and avoid it whenever possible. Patches are usually for fixing
>> CVEs and fixing severe build problems specific to guix.
>>
>> Now this is a problem which is reflected in the thread at [0]
>> (discussing the netcat-openbsd package).
>>
>> Resulting from the discussion I have questions for you:
>>
>> 1. I'd like to know if Debian could merge the specific changes
>>    applied to the OpenBSD package, available in the patches set,
>>    into the OpenBSD GNU-linux port.
>>    If this is not possible, could you give us the reason for it?
>>    My impression is that at least Gentoo, Gentoo deriviates and
>>    based systems, Archlinux, and Debian use the orig-source +
>>    the patches tarball.
>>
>
> This is long overdue - my intention was to keep netcat-openbsd to
> track the development of the openbsd one, but it appears not happened
> that way.
>
>> 2. Did you try to merge more generic changes back to OpenBSD?
>>
>>    From what I've seen so far, those are bug fixes and a minority
>>    of feature fixes.
>>
>
> Some of them was sent, but getting few responses.
>
>> 3. There's an initial statement in the README but as many of those
>>    are non-trivial patches, could you try and give an explanation
>>    on why they are needed,
>>    if they can't get merged into the Debian orig-source?
>>
>
> I don't treat this netcat-openbsd a full fork even if it's targeting
> an older revision at the moment. Also, maintaining patches are very
> easy using the git-buildpackage[1] tools for Debian packages.
>
> [1]https://wiki.debian.org/PackagingWithGit
>
>>
>> Third option I thought of, could Debian provide a tarball of
>> the orig-source with the patches applied, so there's no need
>> to conflict with systems currently pulling one or both of the
>> currently existing tarball.
>>
>
> I think it is hardly possible to provide another tarball because
> there's no way of doing that with current Debian infrastructure. But
> you can apply those patches easily using quilt[2]. In Debian, patches
> are applied automatically when extracting the source package using
> dpkg-source.
>
> [2]https://wiki.debian.org/UsingQuilt
>
>> We can apply all the patches in a way mentioned here [1], but
>> because we collectively maintain all the packages/source instead
>> of `n' specific packages per `n' specific developer(s) it would
>> be good in case Debian can't merge the changes to be able to
>> point to a reason.
>> For this, I ask for your permission to quote parts you give me
>> permission to use for, should for any reason this email
>> discussion not end up completely CC'ed on guix-devel.
>>
>
> No problem.
>
>> [0]: https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00843.html
>> [1]: https://lists.gnu.org/archive/html/guix-devel/2016-06/msg00909.html
>> [2]: http://anonscm.debian.org/cgit/collab-maint/netcat-openbsd.git/commit/debian?id=db2b1d9a8d4644ef892f47d84606ee96598d23fb
>>
>>
>> thanks,
>> --
>
> Best,
> Aron

Thanks for your reply, Aron.

It's not very satisfying to read about the reactions of OpenBSD.

So what do others make of this?
Ludovic, any follow-up thoughts or actions regarding our thread
on this?
In my opinion we could apply the patches like you suggested, in
the source and not as in-tree patches.
-- 
♥Ⓐ  ng0
For non-prism friendly talk find me on http://www.psyced.org
SecuShare – http://secushare.org

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: netcat-openbsd implementations
  2016-07-07 10:10   ` ng0
@ 2016-07-12  9:19     ` Ludovic Courtès
  2016-12-27  4:41       ` Aron Xu
  0 siblings, 1 reply; 7+ messages in thread
From: Ludovic Courtès @ 2016-07-12  9:19 UTC (permalink / raw)
  To: ng0; +Cc: guix-devel, Aron Xu

Hi,

ng0 <ng0@we.make.ritual.n0.is> skribis:

> Aron Xu writes:

[...]

>> I don't treat this netcat-openbsd a full fork even if it's targeting
>> an older revision at the moment. Also, maintaining patches are very
>> easy using the git-buildpackage[1] tools for Debian packages.
>>
>> [1]https://wiki.debian.org/PackagingWithGit
>>
>>>
>>> Third option I thought of, could Debian provide a tarball of
>>> the orig-source with the patches applied, so there's no need
>>> to conflict with systems currently pulling one or both of the
>>> currently existing tarball.
>>>
>>
>> I think it is hardly possible to provide another tarball because
>> there's no way of doing that with current Debian infrastructure. But

[...]

> So what do others make of this?
> Ludovic, any follow-up thoughts or actions regarding our thread
> on this?

I think it would be more convenient to have a source repo for
netcat-openbsd rather than the current setup with a set of
debian/*.patch files.

Perhaps alioth.debian.org could host a netcat-openbsd project containing
the GNU/Linux port (with all the patches applied), from which both the
Debian package and the Guix package would be built?

If that’s not an option then yes, you can do as you proposed, ng0.

Ludo’.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: netcat-openbsd implementations
  2016-07-12  9:19     ` Ludovic Courtès
@ 2016-12-27  4:41       ` Aron Xu
  2016-12-27  9:42         ` ng0
  0 siblings, 1 reply; 7+ messages in thread
From: Aron Xu @ 2016-12-27  4:41 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel, ng0

Hi there,

On Tue, Jul 12, 2016 at 5:19 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Hi,
>
> ng0 <ng0@we.make.ritual.n0.is> skribis:
>
>> Aron Xu writes:
>
> [...]
>
>>> I don't treat this netcat-openbsd a full fork even if it's targeting
>>> an older revision at the moment. Also, maintaining patches are very
>>> easy using the git-buildpackage[1] tools for Debian packages.
>>>
>>> [1]https://wiki.debian.org/PackagingWithGit
>>>
>>>>
>>>> Third option I thought of, could Debian provide a tarball of
>>>> the orig-source with the patches applied, so there's no need
>>>> to conflict with systems currently pulling one or both of the
>>>> currently existing tarball.
>>>>
>>>
>>> I think it is hardly possible to provide another tarball because
>>> there's no way of doing that with current Debian infrastructure. But
>
> [...]
>
>> So what do others make of this?
>> Ludovic, any follow-up thoughts or actions regarding our thread
>> on this?
>
> I think it would be more convenient to have a source repo for
> netcat-openbsd rather than the current setup with a set of
> debian/*.patch files.
>
> Perhaps alioth.debian.org could host a netcat-openbsd project containing
> the GNU/Linux port (with all the patches applied), from which both the
> Debian package and the Guix package would be built?
>
> If that’s not an option then yes, you can do as you proposed, ng0.
>
> Ludo’.

We've updated netcat-openbsd package to 1.130 with all patches
refreshed, if you have plan to follow the update then it's the time,
:)

Cheers,
Aron

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: netcat-openbsd implementations
  2016-12-27  4:41       ` Aron Xu
@ 2016-12-27  9:42         ` ng0
  2016-12-27 10:30           ` Aron Xu
  0 siblings, 1 reply; 7+ messages in thread
From: ng0 @ 2016-12-27  9:42 UTC (permalink / raw)
  To: Aron Xu; +Cc: guix-devel

Hi Aron,

Aron Xu <aron@debian.org> writes:

> Hi there,
>
> On Tue, Jul 12, 2016 at 5:19 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Hi,
>>
>> ng0 <ng0@we.make.ritual.n0.is> skribis:
>>
>>> Aron Xu writes:
>>
>> [...]
>>
>>>> I don't treat this netcat-openbsd a full fork even if it's targeting
>>>> an older revision at the moment. Also, maintaining patches are very
>>>> easy using the git-buildpackage[1] tools for Debian packages.
>>>>
>>>> [1]https://wiki.debian.org/PackagingWithGit
>>>>
>>>>>
>>>>> Third option I thought of, could Debian provide a tarball of
>>>>> the orig-source with the patches applied, so there's no need
>>>>> to conflict with systems currently pulling one or both of the
>>>>> currently existing tarball.
>>>>>
>>>>
>>>> I think it is hardly possible to provide another tarball because
>>>> there's no way of doing that with current Debian infrastructure. But
>>
>> [...]
>>
>>> So what do others make of this?
>>> Ludovic, any follow-up thoughts or actions regarding our thread
>>> on this?
>>
>> I think it would be more convenient to have a source repo for
>> netcat-openbsd rather than the current setup with a set of
>> debian/*.patch files.
>>
>> Perhaps alioth.debian.org could host a netcat-openbsd project containing
>> the GNU/Linux port (with all the patches applied), from which both the
>> Debian package and the Guix package would be built?
>>
>> If that’s not an option then yes, you can do as you proposed, ng0.
>>
>> Ludo’.

To me it still looks like the layout and releases did not include
any of the listed above, so if I'll package openbsd-netcat with
patches in the source sometime next year.

> We've updated netcat-openbsd package to 1.130 with all patches
> refreshed, if you have plan to follow the update then it's the time,
> :)
>
> Cheers,
> Aron

Thanks for your message on the update. So far the package on our
(my) side is stuck in the TODO phase of applying the patches as
it's not a priority for me.

I have no idea about the Debian project organization, but
if it's not already an open bug, could you open a bug for your
infrastructure and/or openbsd-netcat about what Ludovic wrote
here:



   Perhaps alioth.debian.org could host a netcat-openbsd project containing
   the GNU/Linux port (with all the patches applied), from which both the
   Debian package and the Guix package would be built?



This would make work on our side (and possibly also other systems
distributing your version of netcat) much easier, otherwise I'll
just pull in the patches.

Thanks,
-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: netcat-openbsd implementations
  2016-12-27  9:42         ` ng0
@ 2016-12-27 10:30           ` Aron Xu
  0 siblings, 0 replies; 7+ messages in thread
From: Aron Xu @ 2016-12-27 10:30 UTC (permalink / raw)
  To: ng0; +Cc: guix-devel

On Tue, Dec 27, 2016 at 5:42 PM, ng0 <ng0@libertad.pw> wrote:
> Hi Aron,
>
> Aron Xu <aron@debian.org> writes:
>
>> Hi there,
>>
>> On Tue, Jul 12, 2016 at 5:19 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Hi,
>>>
>>> ng0 <ng0@we.make.ritual.n0.is> skribis:
>>>
>>>> Aron Xu writes:
>>>
>>> [...]
>>>
>>>>> I don't treat this netcat-openbsd a full fork even if it's targeting
>>>>> an older revision at the moment. Also, maintaining patches are very
>>>>> easy using the git-buildpackage[1] tools for Debian packages.
>>>>>
>>>>> [1]https://wiki.debian.org/PackagingWithGit
>>>>>
>>>>>>
>>>>>> Third option I thought of, could Debian provide a tarball of
>>>>>> the orig-source with the patches applied, so there's no need
>>>>>> to conflict with systems currently pulling one or both of the
>>>>>> currently existing tarball.
>>>>>>
>>>>>
>>>>> I think it is hardly possible to provide another tarball because
>>>>> there's no way of doing that with current Debian infrastructure. But
>>>
>>> [...]
>>>
>>>> So what do others make of this?
>>>> Ludovic, any follow-up thoughts or actions regarding our thread
>>>> on this?
>>>
>>> I think it would be more convenient to have a source repo for
>>> netcat-openbsd rather than the current setup with a set of
>>> debian/*.patch files.
>>>
>>> Perhaps alioth.debian.org could host a netcat-openbsd project containing
>>> the GNU/Linux port (with all the patches applied), from which both the
>>> Debian package and the Guix package would be built?
>>>
>>> If that’s not an option then yes, you can do as you proposed, ng0.
>>>
>>> Ludo’.
>
> To me it still looks like the layout and releases did not include
> any of the listed above, so if I'll package openbsd-netcat with
> patches in the source sometime next year.
>
>> We've updated netcat-openbsd package to 1.130 with all patches
>> refreshed, if you have plan to follow the update then it's the time,
>> :)
>>
>> Cheers,
>> Aron
>
> Thanks for your message on the update. So far the package on our
> (my) side is stuck in the TODO phase of applying the patches as
> it's not a priority for me.
>
> I have no idea about the Debian project organization, but
> if it's not already an open bug, could you open a bug for your
> infrastructure and/or openbsd-netcat about what Ludovic wrote
> here:
>
>
>
>    Perhaps alioth.debian.org could host a netcat-openbsd project containing
>    the GNU/Linux port (with all the patches applied), from which both the
>    Debian package and the Guix package would be built?
>
>
>
> This would make work on our side (and possibly also other systems
> distributing your version of netcat) much easier, otherwise I'll
> just pull in the patches.
>

I've said before that I don't treat it as a fork, so sorry I'm not
going to request that feature on Debian's infrastructure.

Thanks,
Aron

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2016-12-27 10:30 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-29 12:13 netcat-openbsd implementations ng0
2016-07-03  9:52 ` Aron Xu
2016-07-07 10:10   ` ng0
2016-07-12  9:19     ` Ludovic Courtès
2016-12-27  4:41       ` Aron Xu
2016-12-27  9:42         ` ng0
2016-12-27 10:30           ` Aron Xu

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).