Re: [gentoo-dev] samba (and related) packages are in desperate need of help

2015-09-09 Thread Lars Wendler
On Wed, 2 Sep 2015 21:23:24 +0200 Paweł Hajdan, Jr. wrote:

>On 9/1/15 3:24 PM, Lars Wendler wrote:
>> * samba upstream is extremely uncooperative. Best example is that we
>>   still have some automagic dependencies [5] in samba's build system
>> and upstream is not very keen on fixing these.
>> 
>> [...]
>>
>> [5] https://bugs.gentoo.org/489748
>> https://bugs.gentoo.org/489770
>
>I don't see any references to upstream bug reports, and so no evidence
>of upstream being uncooperative.
>
>Are there any public links that you could share?

Sorry, I forgot about the mails I sent to samba upstream [1]

Regards
Lars

>Paweł
>
>

[1]
http://samba-technical.samba.narkive.com/9UGYmeiG/patch-samba-4-0-automagically-depends-on-dmapi-libdm-so

-- 
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC


pgpWBWYgd1bxc.pgp
Description: Digitale Signatur von OpenPGP


Re: [gentoo-dev] samba (and related) packages are in desperate need of help

2015-09-09 Thread Lars Wendler
Hey all,

seems like I need to correct one of my previous said statements.
Please see below:

On Tue, 1 Sep 2015 15:24:05 +0200 Lars Wendler wrote:

>Hey community,
>
>for a way too long time Gentoo's samba packages lack the attention they
>would require to keep them top notch and as useful as possible for our
>users.
>
>The reason I started to take minimum care of our samba packages was
>because my former employer used Gentoo on his Linux server (guess
>why? :D) and as there were also samba servers among them I had slight
>interest in Gentoo's samba packages to be at least up to date on
>a security point of view.
>After I started work for my new employer this interest lowered even
>more and all I am doing right now is simple version bumps on all samba
>(and related) packages nobody else seems to take care of.
>The situation in Gentoo became even worse when upstream discontinued
>the 3.6.x series which still is the only samba version in Gentoo that
>is multilib capable.
>Given this fact I decided to unmask samba-4.0 and samba-4.1 series
>although both still suffering from two major problems:
>
>* Until now all samba-4 packages are not multilib ready [1]
>
>* samba-4 packages require heimdal, a kerberos implementation that
>  unfortunately cannot be installed in parallel with mit-krb5 package
>  [2]

This seems to be no longer true. I've added samba-4.2.4-r1 with
"system-mitkrb5" USE flag to portage today.

>So here comes a really seriously meant call for help:
>Gyus, if you _are_ interested in samba then please try to invest time
>and knowledge so we can make Gentoo's samba packages better.
>
>To be honest there are some trip wires that make solutions to the two
>above mentioned problems (and possibly others) a bit difficult:
>
>* samba upstream is extremely uncooperative. Best example is that we
>  still have some automagic dependencies [5] in samba's build system
> and upstream is not very keen on fixing these.

And the upstream reference [6]

>* samba (and related) packages are using waf as build system. One of
>  the most ugliest build systems I ever had the bad luck to be involved
>  with.
>
>* To make samba-4 (and related) packages multilib ready, we might need
>  to make python multilib ready first. I'm not sure this requirement is
>  still necessary - we should ask mgorny about this :)
>
>* We should really get heimdal and mit-krb5 packages in a shape where
>  we can install them in parallel [2]. Using the bundled heimdal from
>  samba is no valid option [3]

See above. Should no longer be a pressing requirement. Of course it
would still be nice to have.

>* Stabilization of samba-4 still needs to go a long road [4]
>
>
>Once again, we need your help so please help. If you are willing to do
>so and have no commit access, well... I have and as long as the
>contributions from any volunteer meet the Gentoo standards I am more
>than happy to commit any improvements as proxy maintainer. If they
>don't meet the standards, I'm quite sure we can work those issues out
>together.
>
>
>Kind regards
>Lars
>
>
>[1] https://bugs.gentoo.org/534432
>[2] https://bugs.gentoo.org/490872
>https://bugs.gentoo.org/542462
>[3] https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
>[4] https://bugs.gentoo.org/489762
>[5] https://bugs.gentoo.org/489748
>https://bugs.gentoo.org/489770
>
[6]
http://samba-technical.samba.narkive.com/9UGYmeiG/patch-samba-4-0-automagically-depends-on-dmapi-libdm-so

Kind regards
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC


pgpbCrqntlReJ.pgp
Description: Digitale Signatur von OpenPGP


Re: [gentoo-dev] samba (and related) packages are in desperate need of help

2015-09-09 Thread Paweł Hajdan , Jr .
On 9/9/15 4:00 PM, Lars Wendler wrote:
> On Wed, 2 Sep 2015 21:23:24 +0200 Paweł Hajdan, Jr. wrote:
>> I don't see any references to upstream bug reports, and so no evidence
>> of upstream being uncooperative.
>>
>> Are there any public links that you could share?
> 
> Sorry, I forgot about the mails I sent to samba upstream [1]
> 
> [1]
> http://samba-technical.samba.narkive.com/9UGYmeiG/patch-samba-4-0-automagically-depends-on-dmapi-libdm-so

I see. I'm not sure if I'm interpreting this correctly without more
context. These are my reactions to above thread:

1. All people who replied are listed on
 . To me this means it's indeed
"official" upstream response.

2. Upstream is indeed initially confused.

3. After reading the reference to
,
they point to "--with{out,}-pam, --with{out,}-aio-support and
--with{out,}-attr" flags. Notably, dmapi is not mentioned.

4. At that point I'd expect a reply from you Lars, that since they have
flags for other libraries but not dmapi (or the dmapi ones don't work -
and provide steps to repro), why wouldn't they take the patch.

5. In fact,  from your
original post links to upstream
 with a slightly
different patch that apparently has been landed.

Paweł



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] samba (and related) packages are in desperate need of help

2015-09-02 Thread Eray Aslan
On Tue, Sep 01, 2015 at 03:24:05PM +0200, Lars Wendler wrote:
> * We should really get heimdal and mit-krb5 packages in a shape where
>   we can install them in parallel [2]. Using the bundled heimdal from
>   samba is no valid option [3]

While bundling a copy of a kerberos implementation is certainly not
ideal, I think this is the only sensible option at the moment.

Re-evaluate when samba's changes end up in a heimdal release we can
package.  Some of the changes landed upstream in July, so there has been
some progress recently.

-- 
Eray



Re: [gentoo-dev] samba (and related) packages are in desperate need of help

2015-09-02 Thread Paweł Hajdan , Jr .
On 9/1/15 3:24 PM, Lars Wendler wrote:
> * samba upstream is extremely uncooperative. Best example is that we
>   still have some automagic dependencies [5] in samba's build system and
>   upstream is not very keen on fixing these.
> 
> [...]
>
> [5] https://bugs.gentoo.org/489748
> https://bugs.gentoo.org/489770

I don't see any references to upstream bug reports, and so no evidence
of upstream being uncooperative.

Are there any public links that you could share?

Paweł




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] samba (and related) packages are in desperate need of help

2015-09-02 Thread Rich Freeman
On Wed, Sep 2, 2015 at 2:28 AM, Eray Aslan  wrote:
> On Tue, Sep 01, 2015 at 03:24:05PM +0200, Lars Wendler wrote:
>> * We should really get heimdal and mit-krb5 packages in a shape where
>>   we can install them in parallel [2]. Using the bundled heimdal from
>>   samba is no valid option [3]
>
> While bundling a copy of a kerberos implementation is certainly not
> ideal, I think this is the only sensible option at the moment.
>
> Re-evaluate when samba's changes end up in a heimdal release we can
> package.  Some of the changes landed upstream in July, so there has been
> some progress recently.
>

I agree that it may make sense to allow use of a bundled heimdal until
this can be remedied.  Perhaps control it via a USE flag (which is how
chromium approached issues like this as they slowly unbundled things
in the earlier days).  If the user can install the packaged heimdal
that should be the recommended approach, but if not they can use the
bundle.

I didn't get the impression that changes to heimdal were the issue
here, but rather the fact that it blocks mit-krb5.

It seems like competing implementations of the same library that don't
actually aim to be completely compatible is becoming more of an issue
these days.  We're seeing it here, and we of course have all grown to
love ffmpeg/libav.  Since we're source-based we have a lot more power
to control these issues, but we probably don't want to have to patch
build systems left and right to do it.  Where there are simpler
solutions we should take them, and if upstream has already helped out
with the hacking by bundling that should be considered a practical
compromise where necessary.

-- 
Rich



[gentoo-dev] samba (and related) packages are in desperate need of help

2015-09-01 Thread Lars Wendler
Hey community,

for a way too long time Gentoo's samba packages lack the attention they
would require to keep them top notch and as useful as possible for our
users.

The reason I started to take minimum care of our samba packages was
because my former employer used Gentoo on his Linux server (guess
why? :D) and as there were also samba servers among them I had slight
interest in Gentoo's samba packages to be at least up to date on
a security point of view.
After I started work for my new employer this interest lowered even
more and all I am doing right now is simple version bumps on all samba
(and related) packages nobody else seems to take care of.
The situation in Gentoo became even worse when upstream discontinued
the 3.6.x series which still is the only samba version in Gentoo that
is multilib capable.
Given this fact I decided to unmask samba-4.0 and samba-4.1 series
although both still suffering from two major problems:

* Until now all samba-4 packages are not multilib ready [1]

* samba-4 packages require heimdal, a kerberos implementation that
  unfortunately cannot be installed in parallel with mit-krb5 package
  [2]

So here comes a really seriously meant call for help:
Gyus, if you _are_ interested in samba then please try to invest time
and knowledge so we can make Gentoo's samba packages better.

To be honest there are some trip wires that make solutions to the two
above mentioned problems (and possibly others) a bit difficult:

* samba upstream is extremely uncooperative. Best example is that we
  still have some automagic dependencies [5] in samba's build system and
  upstream is not very keen on fixing these.

* samba (and related) packages are using waf as build system. One of
  the most ugliest build systems I ever had the bad luck to be involved
  with.

* To make samba-4 (and related) packages multilib ready, we might need
  to make python multilib ready first. I'm not sure this requirement is
  still necessary - we should ask mgorny about this :)

* We should really get heimdal and mit-krb5 packages in a shape where
  we can install them in parallel [2]. Using the bundled heimdal from
  samba is no valid option [3]

* Stabilization of samba-4 still needs to go a long road [4]


Once again, we need your help so please help. If you are willing to do
so and have no commit access, well... I have and as long as the
contributions from any volunteer meet the Gentoo standards I am more
than happy to commit any improvements as proxy maintainer. If they
don't meet the standards, I'm quite sure we can work those issues out
together.


Kind regards
Lars


[1] https://bugs.gentoo.org/534432
[2] https://bugs.gentoo.org/490872
https://bugs.gentoo.org/542462
[3] https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
[4] https://bugs.gentoo.org/489762
[5] https://bugs.gentoo.org/489748
https://bugs.gentoo.org/489770

-- 
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC


pgp1K8UH3EswC.pgp
Description: Digitale Signatur von OpenPGP