Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Ole Streicher]

Pirate Praveen  writes:
>> Debian needs feature X but it is already in the e.nterprise version. We make
>> a patch and for commercial reasons it never gets merged (they already sell it
>> in the enterprise version). Which means we will have to fork the software and
>> keep those patches forever. Been there done that. For me, that isn't
>> acceptable. 
>> I don't want another Nagios. 
>
> I agree this is a legitimate concern. I have asked Gitlab Inc for their
> policy on merge requests to Gitlab CE for features already in Gitlab EE.
> Based on their reply, we can decide how to proceed. If their reply is
> positive, I will ask them to make it public, and we can go ahead with a
> debian.net instance of Gitlab. If their reply is negative, we can drop
> gitlab and consider Pagure (second best option).

We do patching as part of our daily packaging already: to replace (or
circumvent) non-dfsg functionality, to integrate into our environment,
and everything else that upstream is not willing or able to apply
himself but is good in our opinion. Depending on the package, you may
find huge patches for our packages

I would not see why a missing functionality of gitlab would be different
here.

Best regards

Ole

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Alexander Wirt]

On Sat, 11 Jun 2016, Ole Streicher wrote:

> Pirate Praveen  writes:
> >> Debian needs feature X but it is already in the e.nterprise version. We 
> >> make
> >> a patch and for commercial reasons it never gets merged (they already sell 
> >> it
> >> in the enterprise version). Which means we will have to fork the software 
> >> and
> >> keep those patches forever. Been there done that. For me, that isn't
> >> acceptable. 
> >> I don't want another Nagios. 
> >
> > I agree this is a legitimate concern. I have asked Gitlab Inc for their
> > policy on merge requests to Gitlab CE for features already in Gitlab EE.
> > Based on their reply, we can decide how to proceed. If their reply is
> > positive, I will ask them to make it public, and we can go ahead with a
> > debian.net instance of Gitlab. If their reply is negative, we can drop
> > gitlab and consider Pagure (second best option).
> 
> We do patching as part of our daily packaging already: to replace (or
> circumvent) non-dfsg functionality, to integrate into our environment,
> and everything else that upstream is not willing or able to apply
> himself but is good in our opinion. Depending on the package, you may
> find huge patches for our packages
> 
> I would not see why a missing functionality of gitlab would be different
> here.
Given my personal expericence with so called opencore software, I do. 

Alex
 

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Holger Levsen]

On Sat, Jun 11, 2016 at 10:24:48AM +0200, Ole Streicher wrote:
> We do patching as part of our daily packaging already: to replace (or
> circumvent) non-dfsg functionality, to integrate into our environment,
> and everything else that upstream is not willing or able to apply
> himself but is good in our opinion. Depending on the package, you may
> find huge patches for our packages
> 
> I would not see why a missing functionality of gitlab would be different
> here.

Ole, it seems you didn't understand what Alexander ment when he described his
reasoning with a single word, "nagios"?

Do you know what he is referring too?
 

-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Ole Streicher]

Holger Levsen  writes:
> On Sat, Jun 11, 2016 at 10:24:48AM +0200, Ole Streicher wrote:
>> We do patching as part of our daily packaging already: to replace (or
>> circumvent) non-dfsg functionality, to integrate into our environment,
>> and everything else that upstream is not willing or able to apply
>> himself but is good in our opinion. Depending on the package, you may
>> find huge patches for our packages
>> 
>> I would not see why a missing functionality of gitlab would be different
>> here.
>
> Ole, it seems you didn't understand what Alexander ment when he described his
> reasoning with a single word, "nagios"?
>
> Do you know what he is referring too?

No, I don't. I can speak only from my own experiences when packaging,
and from what I see f.e. as patches in iceweasel. It seems that we are
able to maintain significant patches for quite a while.

If nagios is a counterexample, it may be worth to see how it differs
from our successfull stories.

Best regards

Ole

Unidentified subject!

[bounce-debian-devel=archive=mail-archive . com]

new stuff

[Kyle Nelson]

Hi,

Here is some information on the new stuff that may seem helpful to you, read 
more here 

Yours sincerely, Kyle Nelson

OpenSSL 1.1.0

[Kurt Roeckx]

Hi,

The release of OpenSSL 1.1.0 is getting nearer.  Some packages
will no longer build with the new version without changes.  Most
of those changes should be trivial, like you can't allocate some
structures on the stack anymore and need to use the correct _new()
and _free() function.

It can also mean that you can't directly access some members of
those structures anymore and need to use a function instead.

There is an upstream wiki page for this at:
https://wiki.openssl.org/index.php/1.1_API_Changes

If things aren't clear, you have questions, are there are missing
access functions please contact us.

I've uploaded packages to experimental, so you can use those to
test things.

We did a rebuild of all packages build-depending on libssl-dev.
You can see the result of that here:
https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/


Here is a dd-list for packages that failed to build, not all of them
are related to changes in OpenSSL:

A. Jesse Jiryu Davis 
   libmongoc

Adam Conrad 
   cyrus-sasl2 (U)

Adam Majer 
   isc-kea
   mosquitto-auth-plugin

Afif Elghraoui 
   gridengine (U)

Afif Elghraoui 
   ori

Alan Baghumian 
   balsa (U)

Alberto Garcia 
   megatools

Alberto Gonzalez Iniesta 
   linux-ftpd-ssl (U)
   netkit-ftp-ssl (U)
   netkit-telnet-ssl (U)
   openvpn

Alessandro Ghedini 
   curl
   isync (U)
   libnet-ssleay-perl (U)

Alessio Di Mauro 
   yubico-piv-tool (U)

Alessio Treglia 
   crtmpserver (U)

Alexander Reichle-Schmehl 
   httperf

Alexander Wirt 
   cgit
   citadel (U)
   icinga2 (U)
   nsca-ng
   webcit (U)

Alexander Zangerl 
   nmh

Amul Shah 
   fis-gtm (U)

Anders Waananen 
   canl-c++ (U)
   nordugrid-arc (U)

Andreas Cadhalpun 
   clamav (U)

Andreas Henriksson 
   balsa (U)
   xchat-gnome (U)

Andreas Tille 
   alpine (U)
   dcmtk (U)
   fis-gtm (U)
   gdcm (U)
   ginkgocadx (U)
   iva (U)
   r-bioc-rtracklayer (U)
   r-cran-openssl (U)
   xrdp (U)

Andres Mejia 
   crtmpserver (U)

Andrew Ayer 
   git-crypt

Andrew Pollock 
   grpc (U)

Andrew Shadura 
   libdigidoc

Andrew Starr-Bochicchio 
   libtorrent-rasterbar (U)

Andriy Beregovenko 
   crtmpserver (U)

Android tools Maintainer 
   android-platform-system-core
   android-tools

Android Tools Maintainers 
   android-tools

Angus Lees 
   cargo (U)

Anibal Monsalve Salazar 
   libevent
   pidentd

Ansgar Burchardt 
   libcrypt-openssl-x509-perl (U)
   simutrans (U)

Anthony Fok 
   golang-github-yosssi-ace (U)

Anthony Prades 
   cyrus-imapd (U)
   cyrus-imapd-2.4 (U)

Antoine Beaupré 
   atheme-services
   atheme-services (U)

Antonio Radici 
   cfengine2
   cfengine3

Antonio Terceiro 
   ruby2.3
   vboot-utils

Antti Järvinen 
   classified-ads

Apollon Oikonomopoulos 
   dovecot (U)
   haproxy (U)
   mongodb (U)

Arnaud Cornet 
   bip (U)
   haproxy

Arno Töll 
   apache2 (U)
   lighttpd (U)
   trafficserver

Aron Xu 
   libofetion (U)
   pidgin-openfetion (U)
   spdylay (U)
   trafficserver (U)

Asheesh Laroia 
   alpine

Asias He 
   libofetion (U)

Athena Capital Research 
   pion

Aurelien Jarno 
   freebsd-utils (U)

Axel Beckert 
   links2
   links2 (U)
   xymon (U)

Balint Reczey 
   kodi (U)
   pulseaudio (U)

Barak A. Pearlmutter 
   ettercap
   fossil

Bartosz Fenski 
   skipfish

Bas Couwenberg 
   postgis (U)

Bas Couwenberg 
   postgis (U)

Bastiaan Franciscus van den Dikkenberg 
   burp

Bastian Kleineidam 
   libpam-mount

Bdale Garbee 
   bind9 (U)
   ntp (U)

Ben Pfaff 
   openvswitch (U)

Benjamin Barenblat 
   urweb

Benjamin Drung 
   xmms2

Benjamin Kaduk 
   krb5 (U)

Benoît Knecht 
   libtorrent (U)

Bernd Zeimetz 
   open-vm-tools
   pgbouncer (U)

Bertrand Marc 
   libmicrohttpd

Boris Pek 
   uhub

Boris Pek 
   eiskaltdcpp

Brett Parker 
   pound

Brian Lin 
   condor (U)

Brian May 
   librabbitmq (U)

Bryan Sutula 
   openhpi

Bryan Sutula 
   openhpi

Caitlin Matos 
   attic

Carsten Leonhardt 
   bacula (U)

CAS packaging team 
   libapache2-mod-auth-cas

Casper Gielen 
   validns

Charles Plessy 
   m2crypto (U)

Chris Leishman 
   libneo4j-client

Chris Taylor 
   socat

Christian Hofstaedtler 
   ike
   ipsec-tools (U)
   pdns (U)
   pdns-recursor (U)
   ruby2.3 (U)

Christian M. Amsüss 
   pam-ssh-agent-auth

Christoph Berg 
   dacs
   pgadmin3 (U)
   pgbouncer (U)
   pgpool2 (U)
   postgresql-9.5 (U)
   xymon

Christoph Egger 
   freebsd-utils (U)

Christoph Martin 
   netkit-telnet-ssl (U)

Christophe Monniez 
   afflib (U)

Christopher Hoskin 
   libcrypt-openssl-pkcs10-perl (U)
   libcrypt-openssl-pkcs12-perl (U)

Christos Trochalakis 
   nginx (U)

ClamAV Team 
   clamav
   libclamunrar

Cleto Martín 
   zeroc-ice (U)

Clint Adams 
   mod-authn-webid
   simutrans (U)

Clint Adams 
   simutrans (U)

Colin Tuckley 
   mixmaster
   trustedqsl (U)

Colin Watson 
   openssh (U)

Condor Developers 
   condor

Cristian Greco 
   libtorrent-rasterbar
   poco
   poco (U)

Cyril Lavier 
   nginx (U)

Dain Nilsson 
   yubico-piv-tool (U)

Damien Raude-Morvan 
   opennebula (U)
   to

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Antonio Terceiro]

On Sat, Jun 11, 2016 at 10:51:18AM +0200, Ole Streicher wrote:
> Holger Levsen  writes:
> > On Sat, Jun 11, 2016 at 10:24:48AM +0200, Ole Streicher wrote:
> >> We do patching as part of our daily packaging already: to replace (or
> >> circumvent) non-dfsg functionality, to integrate into our environment,
> >> and everything else that upstream is not willing or able to apply
> >> himself but is good in our opinion. Depending on the package, you may
> >> find huge patches for our packages
> >> 
> >> I would not see why a missing functionality of gitlab would be different
> >> here.
> >
> > Ole, it seems you didn't understand what Alexander ment when he described 
> > his
> > reasoning with a single word, "nagios"?
> >
> > Do you know what he is referring too?
> 
> No, I don't. I can speak only from my own experiences when packaging,
> and from what I see f.e. as patches in iceweasel. It seems that we are
> able to maintain significant patches for quite a while.

The fact that we are able to do something does not mean that it is easy,
or that we like having to do it.


signature.asc
Description: PGP signature

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Lars Wirzenius]

On Sat, Jun 11, 2016 at 08:46:30AM +, Holger Levsen wrote:
> On Sat, Jun 11, 2016 at 10:24:48AM +0200, Ole Streicher wrote:
> > We do patching as part of our daily packaging already: to replace (or
> > circumvent) non-dfsg functionality, to integrate into our environment,
> > and everything else that upstream is not willing or able to apply
> > himself but is good in our opinion. Depending on the package, you may
> > find huge patches for our packages
> > 
> > I would not see why a missing functionality of gitlab would be different
> > here.
> 
> Ole, it seems you didn't understand what Alexander ment when he described his
> reasoning with a single word, "nagios"?
> 
> Do you know what he is referring too?

I'd be interested in that story.

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh


signature.asc
Description: PGP signature

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Ole Streicher]

Antonio Terceiro  writes:
> On Sat, Jun 11, 2016 at 10:51:18AM +0200, Ole Streicher wrote:
>> Holger Levsen  writes:
>> > On Sat, Jun 11, 2016 at 10:24:48AM +0200, Ole Streicher wrote:
>> >> We do patching as part of our daily packaging already: to replace (or
>> >> circumvent) non-dfsg functionality, to integrate into our environment,
>> >> and everything else that upstream is not willing or able to apply
>> >> himself but is good in our opinion. Depending on the package, you may
>> >> find huge patches for our packages
>> >> 
>> >> I would not see why a missing functionality of gitlab would be different
>> >> here.
>> >
>> > Ole, it seems you didn't understand what Alexander ment when he described 
>> > his
>> > reasoning with a single word, "nagios"?
>> >
>> > Do you know what he is referring too?
>> 
>> No, I don't. I can speak only from my own experiences when packaging,
>> and from what I see f.e. as patches in iceweasel. It seems that we are
>> able to maintain significant patches for quite a while.
>
> The fact that we are able to do something does not mean that it is easy,
> or that we like having to do it.

Sure. At the end this is left to the maintainers. All I wanted to say is
that long-term patches are no show-stopper for Debian packaging.

Best regards

Ole

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Holger Levsen]

On Sat, Jun 11, 2016 at 04:24:49PM +0300, Lars Wirzenius wrote:
> > Ole, it seems you didn't understand what Alexander ment when he described 
> > his
> > reasoning with a single word, "nagios"?
> I'd be interested in that story.

I don't know that much, just that nagios ain't part of Debian anymore,
instead we have it's fork, icinga. And given Alexander's previous comments
in this thread I imagine nagios used to have an "open source"
edition and an enterprise edition and patches were not always excepted
upstream, then broke on upgrades and dealing with such an upstream was no
fun.

*I imagine*.

I well *know* there are situations where an "Open Source" software is
accompanied by a differently licenced very similar product ("enterprise
edition") and where this "Open Source" variant is basically just a scam.
I don't know if this is the case for gitlab (nor nagios) but I know why
I prefer "Free Software" and why I think Debian should use free software
for it's infrastructure and stay away from stuff which is not free
software.

"Open source" is just a marketing term. Free software is something to
build upon. And not everything what is "Open Source" is also free
software.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Pirate Praveen]

On 2016, ജൂൺ 11 7:13:41 PM IST, Holger Levsen  wrote:
>I well *know* there are situations where an "Open Source" software is
>accompanied by a differently licenced very similar product ("enterprise
>edition") and where this "Open Source" variant is basically just a
>scam.

If you substitute "Free Software", in place for "Open Source", your description 
of the situation would still be correct.

>I don't know if this is the case for gitlab (nor nagios) but I know why
>I prefer "Free Software" and why I think Debian should use free
>software
>for it's infrastructure and stay away from stuff which is not free
>software.

Please don't give your own meanings to well established terms.

Gitlab CE is by all definitions Free Software.

You may want to use the term "Open Core" (or Free Core if you wish to use Free 
instead of Open) for what you are trying to explain.

>"Open source" is just a marketing term. Free software is something to
>build upon. And not everything what is "Open Source" is also free
>software.

For all practical cases all Open Source Software is also Free Software. There 
is just one license (Reciprocal Public License or RPL) that is approved by Open 
Source Initiative as Open Source, but not considered Free Software by Free 
Software Foundation. Wikipedia page for RPL lists just 2 projects.

While understand your preference for using the term Free Software (I prefer it 
too), pushing a new definition for these terms as you wish does not help your 
cause.

The difference between the two is in their philosophies - "the why" (or what is 
more important in such software). Both give the same answer to "the what" or 
"the how".

For Free Software, its an ethical and social movement, for Open Source, its a 
great development model.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#827042: ITP: xmonad-wallpaper -- xmonad wallpaper extension

[Lev Lamberov]

Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: xmonad-wallpaper
  Version : 0.0.1.3
  Upstream Author : Ye Yan 
* URL : https://hackage.haskell.org/package/xmonad-wallpaper
* License : LGPL-3
  Programming Lang: Haskell
  Description : xmonad wallpaper extension

Designed for xmonad users who rely on feh to setup wallpaper. It allows user to
setup a random image as the wallpaper choosed from user specified image
directories.

I use this package, will maintain it inside DHG.

Re: OpenSSL 1.1.0

[Robert Edmonds]

Kurt Roeckx wrote:
> Robert Edmonds 

>unbound (U)

Thanks. Opened a bug report with upstream:

https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=777

-- 
Robert Edmonds
edmo...@debian.org

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Vincent Bernat]

 ❦ 11 juin 2016 10:46 CEST, Holger Levsen  :

>> We do patching as part of our daily packaging already: to replace (or
>> circumvent) non-dfsg functionality, to integrate into our environment,
>> and everything else that upstream is not willing or able to apply
>> himself but is good in our opinion. Depending on the package, you may
>> find huge patches for our packages
>> 
>> I would not see why a missing functionality of gitlab would be different
>> here.
>
> Ole, it seems you didn't understand what Alexander ment when he
> described his reasoning with a single word, "nagios"?
>
> Do you know what he is referring too?

Nagios' author did create Nagios Enterprise to provide paid support and
integration to Nagios. This triggered a fork (Icinga) by Netways, a
competing business. This created some frictions with both Nagios' author
and the community. However, Nagios' author also started to refuse
enhancements to Nagios and made several threats to its own
community. This triggered other forks, Shinken being among one of them.

I thought this was covered by LWN at the time, but I am unable to find a
link.
-- 
There are more things in heaven and earth,
Horatio, than are dreamt of in your philosophy.
-- Wm. Shakespeare, "Hamlet"


signature.asc
Description: PGP signature

Re: OpenSSL 1.1.0

[Jérémy Lal]

2016-06-11 14:30 GMT+02:00 Kurt Roeckx :

>
> Hi,
>
> The release of OpenSSL 1.1.0 is getting nearer.  Some packages
> will no longer build with the new version without changes.  Most
> of those changes should be trivial, like you can't allocate some
> structures on the stack anymore and need to use the correct _new()
> and _free() function.
>
> It can also mean that you can't directly access some members of
> those structures anymore and need to use a function instead.
>
> There is an upstream wiki page for this at:
> https://wiki.openssl.org/index.php/1.1_API_Changes
>
> If things aren't clear, you have questions, are there are missing
> access functions please contact us.
>
> I've uploaded packages to experimental, so you can use those to
> test things.
>


Is an openssl 1.1.0 transition scheduled before release freeze ?

Jérémy

Re: OpenSSL 1.1.0

[Antti Jarvinen]

Kurt Roeckx writes:
 > The release of OpenSSL 1.1.0 is getting nearer. 

Thanks for the warning, I'm finding myself listed.. For the
problematic package I maintain the API changes are already fixed
upstream but is there any idea about schedule when (at latest) the
fixing version should be included? 

The list itself was fairly impressive :)

--
Antti Järvinen

Re: OpenSSL 1.1.0

[Kurt Roeckx]

On Sat, Jun 11, 2016 at 07:41:25PM +0200, Jérémy Lal wrote:
> 2016-06-11 14:30 GMT+02:00 Kurt Roeckx :
> 
> >
> > Hi,
> >
> > The release of OpenSSL 1.1.0 is getting nearer.  Some packages
> > will no longer build with the new version without changes.  Most
> > of those changes should be trivial, like you can't allocate some
> > structures on the stack anymore and need to use the correct _new()
> > and _free() function.
> >
> > It can also mean that you can't directly access some members of
> > those structures anymore and need to use a function instead.
> >
> > There is an upstream wiki page for this at:
> > https://wiki.openssl.org/index.php/1.1_API_Changes
> >
> > If things aren't clear, you have questions, are there are missing
> > access functions please contact us.
> >
> > I've uploaded packages to experimental, so you can use those to
> > test things.
> >
> 
> 
> Is an openssl 1.1.0 transition scheduled before release freeze ?

I really would like it to make in the next release, so that would
be yes.


Kurt

Re: OpenSSL 1.1.0

[Kurt Roeckx]

On Sat, Jun 11, 2016 at 08:33:07PM +0300, Antti Jarvinen wrote:
> Kurt Roeckx writes:
>  > The release of OpenSSL 1.1.0 is getting nearer. 
> 
> Thanks for the warning, I'm finding myself listed.. For the
> problematic package I maintain the API changes are already fixed
> upstream but is there any idea about schedule when (at latest) the
> fixing version should be included? 

I have no schedule currently about when we're going to release
openssl.  We're already behind our own release schedule, but we're
only fixing things at the moment.

I don't want to maintain an openssl 1.0.2 package, so I assume
that soon after the transition starts you'll have to get your
package fixed to stay in testing, but that's clearly something I
need to discuss with the release team.


Kurt

Bug#827062: ITP: xmonad-extras -- various modules for xmonad that cannot be added to xmonad-contrib because of additional dependencies

[Lev Lamberov]

Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: xmonad-extras
  Version : 0.12.1
  Upstream Author : The Daniels Schoepe and Wagner 
* URL : https://hackage.haskell.org/package/xmonad-extras-0.12.1
* License : BSD-3-clause
  Programming Lang: Haskell
  Description : third party extensions for xmonad with wacky dependencies

Various modules for xmonad that cannot be added to xmonad-contrib because of
additional dependencies.

I use this package, will maintain it inside DHG.

Re: Unidentified subject!

[cbannister]

On Sun, Jun 12, 2016 at 12:04:59AM +1200, 
bounce-debian-devel=cbannister=slingshot.co...@lists.debian.org wrote:

Weird! Don't know what happened here. :(

-- 
The media's the most powerful entity on earth. 
They have the power to make the innocent guilty 
and to make the guilty innocent, and that's power.
 -- Malcolm X

ITP: newlisp -- a LISP like, general purpose scripting language

[Sergio Durigan Junior]

Control: retitle -1 ITP: newlisp -- a LISP like, general purpose scripting 
language

* Package name: newlisp
  Version : 10.7.0
  Upstream Author : Lutz Mueller 
* URL : http://www.newlisp.org/
* License : GPL and compatibles
  Programming Lang: C
  Description : a LISP like, general purpose scripting language

newLISP is a scripting language for developing web applications and
programs in general and in the domains of artificial intelligence (AI)
and statistics.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature