On Sat, Feb 17, 2018 at 01:24:30PM -0500, Sergio Durigan Junior wrote:
> On Saturday, February 17 2018, Michael Meskes wrote:
> > I disagree, it is not maintainable source code, yes, but source code
> > nonetheless. According to wikipedia source code is:
> >
> > In computing, source code is any col
On Saturday, February 17 2018, Michael Meskes wrote:
>> Minification is quite comparable to compilation. I will give you some
>> examples from my frustration with Drupal8 in this answer. This can no
>> longer be seen as source code:
>> ...
>
> I disagree, it is not maintainable source code, yes, b
Hi Sean,
On Sat, 17 Feb 2018, Sean Whitton wrote:
I was making a more specific claim -- we don't and will never have the
manpower to provide security support for multiple different versions of
hundreds of little JavaScript libraries.
please have a look at for example CVE-2017-18077 [1] in the
]] Russ Allbery
> Paul Wise writes:
>
> > I think the discussion we are having here is orthogonal to
> > containers/flatpaks.
>
> > If Debian were to have a repository of containers/flatpaks, then it
> > should meet Debian standards. We cannot just say "here are some
> > containers, completely
> On Sat, Feb 17, 2018 at 01:51:38PM +0100, Michael Meskes wrote:
> > Then I guess the question is, what is Debian?
> >
> > Does a different and additional package format change the project?
>
> It seems like you're not reading what other people have said--tt has
Well I try, but I'm certainly n
Paul Wise writes:
> I think the discussion we are having here is orthogonal to
> containers/flatpaks.
> If Debian were to have a repository of containers/flatpaks, then it
> should meet Debian standards. We cannot just say "here are some
> containers, completely unsupported and might not up to o
Hello Paul,
On Sat, Feb 17 2018, Paul Wise wrote:
> I think the discussion we are having here is orthogonal to
>containers/flatpaks.
>
> If Debian were to have a repository of containers/flatpaks, then it
> should meet Debian standards. We cannot just say "here are some
> containers, completely u
Hello Andreas,
On Sat, Feb 17 2018, Andreas Tille wrote:
> On Fri, Feb 16, 2018 at 11:51:20AM -0700, Sean Whitton wrote:
>> We do not, and probably never will have, the required manpower.
>
> So if you are claiming we have no manpower that's pretty much our own
> fault since we do not actively ca
On Sat, Feb 17, 2018 at 01:51:38PM +0100, Michael Meskes wrote:
Then I guess the question is, what is Debian?
Does a different and additional package format change the project?
It seems like you're not reading what other people have said--tt has
nothing to do with the packaging format, it has
Raphael Hertzog schrieb:
> What do you think? Do you have other ideas? Are there other persons
> who are annoyed by the current situation?
There's clearly a set of software which is of high quality, but where
upstream's development practices are not usefully aligned with our
existing distro model
On 2018-02-17 13:57, Michael Meskes wrote:
> I disagree, it is not maintainable source code, yes, but source code
> nonetheless. According to wikipedia source code is:
>
> In computing, source code is any collection of computer instructions,
> possibly with comments, written using[1] a human-readab
On Sat, Feb 17, 2018 at 8:57 PM, Michael Meskes wrote:
> I disagree, it is not maintainable source code, yes, but source code
> nonetheless. According to wikipedia source code is:
>
> In computing, source code is any collection of computer instructions,
> possibly with comments, written using[1] a
On Sat, 17 Feb 2018, Michael Meskes wrote:
>> Minification is quite comparable to compilation. I will give you some
>> examples from my frustration with Drupal8 in this answer. This can no
>> longer be seen as source code:
>> ...
>
> I disagree, it is not maintainable source code, yes, but source
Michael Meskes, on sam. 17 févr. 2018 13:57:53 +0100, wrote:
> > Minification is quite comparable to compilation. I will give you some
> > examples from my frustration with Drupal8 in this answer. This can no
> > longer be seen as source code:
> > ...
>
> I disagree, it is not maintainable source
> I don't know where you got figures to support this case, but I have
> the
> inverse feeling (and no figures either). Arch is taking away our
> desktop
> users, Ubuntu is taking away our cloud users, Alpine is taking away
> our
> container users and CoreOS/Atomic Host are taking away users
> inter
> Minification is quite comparable to compilation. I will give you some
> examples from my frustration with Drupal8 in this answer. This can no
> longer be seen as source code:
> ...
I disagree, it is not maintainable source code, yes, but source code
nonetheless. According to wikipedia source cod
Am Freitag, den 16.02.2018, 17:22 -0500 schrieb Michael Stone:
> On Fri, Feb 16, 2018 at 10:01:53PM +0100, Michael Meskes wrote:
> > True, that's why I think we should look for a different solutions.
>
> There are different solutions, but the result isn't debian, it's
> something else with a diff
On Fri, Feb 16, 2018 at 11:51:20AM -0700, Sean Whitton wrote:
> We do not, and probably never
> will have, the required manpower.
Since 2012 I'm maintaining a survey in wiki[1] where developers are
giving reasons why they entered Debian. I presented the result in
several talks the first time at F
❦ 16 février 2018 17:25 GMT, Holger Levsen :
>> Well, strictly speaking Debian does not actually need to be involved
>> then, applications are already doing that. But it's indeed a sign that
>> Debian is losing relevance, which is concerning and Debian could have to
>> do something about it.
>
On Sat, Feb 17, 2018 at 6:07 AM, Sean Whitton wrote:
> On Fri, Feb 16 2018, Michael Meskes wrote:
>> If we were to package applications as containers (not necessarily
>> docker-style!) we could and should have different rules for
>> those
>
> Yes, I think that Debian should eventually be provid
On Fri, Feb 16, 2018 at 11:11 PM, Raphael Hertzog wrote:
> What do you think? Do you have other ideas? Are there other persons
> who are annoyed by the current situation?
I think we should keep software that doesn't meet our standards
outside of Debian. There are plenty of ways to deploy such sof
Michael Meskes dijo [Fri, Feb 16, 2018 at 10:07:06PM +0100]:
> > Is was a relevant part of the problem mentioned in Raphaels bug
> > report: Minified JS libraries without source code. this was one
> > of the starting points of this discussion. (#890598)
>
> Right, although merely technical since t
On Fri, Feb 16, 2018 at 10:01:53PM +0100, Michael Meskes wrote:
True, that's why I think we should look for a different solutions.
There are different solutions, but the result isn't debian, it's
something else with a different set of expectations.
Mike Stone
Hello Michael,
On Fri, Feb 16 2018, Michael Meskes wrote:
>> We cannot feasibly provide security updates when there is more than
>> one version of the library in the archive. We do not, and probably
>> never will have, the required manpower.
>>
>> This applies to the nixos/guix solutions too --
> > Who said we cannot properly maintain this stuff? And where do you
> > think our expected level of quality (whatever that is) will not be
> > reached?
>
> In this thread, at least Raphaël and myself.
>
> And, I guess, many others (say, OwnCloud was already brought up to
> this thread).
As I e
> Depends how it would be done. Nixos style would probably very
> difficult for Debian. Packages with version number in their
> name would be no packaging problem at all, but we would have
> to make clear, that security support is not likely.
Sure, I don't see a problem with this.
> > discussions
> stuff is packaged. The current "build everything from live git"
> paradigm
> just doesn't work well for a package-based distributon with a multi-
> year
True, that's why I think we should look for a different solutions.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Mes
> As a sysadmin, I know I can trust that most of my system is OK if I
> just apt update / apt upgrade every so often. And I know the maybe
> five to ten software packages I have hand-installed. I know I must be
> aware of their alerts and whatnot.
Personally I'm afraid that a lot of sysadmins know
Michael Meskes dijo [Fri, Feb 16, 2018 at 06:12:04PM +0100]:
> > No, I think it's better if people know they're on their own for maintaining
> > something. What's surely worse is when we ship stuff that we know we can't
> > properly maintain in the long term. Better to be out of the archive than in
On Fri, Feb 16, 2018 at 01:59:55PM -0600, Gunnar Wolf wrote:
While I agree with you, just the number of node-.* (1249) or libjs-.*
(398) packages (which tend to fall within this fast-paced development
culture) makes me shiver... Who will maintain them at different
compatibility levels? Even more
On 2018-02-16 20:41, Michael Meskes wrote:
> On Fri, Feb 16, 2018 at 08:21:19PM +0100, W. Martin Borgert wrote:
> > But it's probably too much work, preparing infrastructure etc.
>
> Why?
Depends how it would be done. Nixos style would probably very
difficult for Debian. Packages with version numb
On Fri, Feb 16, 2018 at 06:12:04PM +0100, Michael Meskes wrote:
On Fri, Feb 16, 2018 at 11:12:51AM -0500, Michael Stone wrote:
On Fri, Feb 16, 2018 at 04:58:04PM +0100, Michael Meskes wrote:
> I know that this does create some problems for us, e.g. on the security
> side, but the alternative is,
Michael Meskes dijo [Fri, Feb 16, 2018 at 04:58:04PM +0100]:
> Can't we treat a .deb file like a container in the sense that it may
> include additional source if needed? I'd very much like this.
>
> I know that this does create some problems for us, e.g. on the security
> side, but the alternativ
W. Martin Borgert dijo [Fri, Feb 16, 2018 at 06:59:21PM +0100]:
> If I understand Samuels idea correctly, he likes to have multiple
> versions of the same (JavaScript) library installed on Debian.
> Not "stuff", but proper Debian packages, with all bells and whistles.
> Only that you don't remove n
On Fri, Feb 16, 2018 at 07:26:35PM +0100, Innocent De Marchi wrote:
> I believe that the right way is to
> convince developers of the need to generate applications that respect
> the principles of free code.
Note that we don't want "applications that respect the principles of free
code", we specifi
On Fri, Feb 16, 2018 at 08:21:19PM +0100, W. Martin Borgert wrote:
This is true. We would have to be clear, that security support
would have to be limited to one (the latest?) version. This is
still a difference to some arbitrary compressed js files with no
source code, no copyright information e
Raphael Hertzog dijo [Fri, Feb 16, 2018 at 04:11:29PM +0100]:
> Hello everybody,
>
> the fact that I had to request the removal of dolibarr from Debian makes
> me sad (see below for the reasons) and I believe that we should be able
> to do better to provide complex applications to our end users.
>
On Fri, Feb 16, 2018 at 08:21:19PM +0100, W. Martin Borgert wrote:
> This is true. We would have to be clear, that security support
> would have to be limited to one (the latest?) version. This is
> still a difference to some arbitrary compressed js files with no
> source code, no copyright informa
> We cannot feasibly provide security updates when there is more than one
> version of the library in the archive. We do not, and probably never
> will have, the required manpower.
>
> This applies to the nixos/guix solutions too -- we cannot expect our
> security team to go around backporting pa
On 2018-02-16 11:51, Sean Whitton wrote:
> We cannot feasibly provide security updates when there is more than one
> version of the library in the archive. We do not, and probably never
> will have, the required manpower.
>
> This applies to the nixos/guix solutions too -- we cannot expect our
> s
W. Martin Borgert, on ven. 16 févr. 2018 18:59:21 +0100, wrote:
> If I understand Samuels idea correctly, he likes to
I don't.
I'm just saying what I'm noticing, not what I like.
> This is very much a web application problem. Other software is
> less affected in my experience.
Sure. But the cur
Hello Michael,
On Fri, Feb 16 2018, Michael Meskes wrote:
> Who said we cannot properly maintain this stuff? And where do you
> think our expected level of quality (whatever that is) will not be
> reached?
We cannot feasibly provide security updates when there is more than one
version of the lib
Hi Raphael
On 16/02/2018 17:11, Raphael Hertzog wrote:
> Dolibarr is not alone:
>
> - while gitlab is packaged in Debian, its packaging took years and the
> result is brittle because it can break in many ways whenever one the
> dozens of dependencies gets updated to some new upstream version
Hello everybody,
>
> I'm sure we are missing lots of good applications due to our
> requirements. What can we do to avoid this?
>
Is it a goal of Debian to accumulate applications? It is a priority to
offer a robust and solid system: Other Debian derivatives accept
relaxations: I think Debian m
Le vendredi 16 février 2018 à 16:11 +0100, Raphael Hertzog a écrit :
> Hello everybody,
>
> the fact that I had to request the removal of dolibarr from Debian
> makes
> me sad (see below for the reasons) and I believe that we should be
> able
> to do better to provide complex applications to our e
Recently on Planet: https://apebox.org/wordpress/linux/1229
--
WBR, wRAR
signature.asc
Description: PGP signature
Quoting Holger Levsen :
I very much disagree that Debian is loosing relevance, like many software
projects Debian usage is still growing. and other projects grow as well.
I agree.
you can use their package managers, and thus these features, on Debian
today. there's also docker containers and
Holger Levsen, on ven. 16 févr. 2018 17:25:06 +, wrote:
> > Or we could try to embrace the multiple-library-versions-in-the-same-root
> > issue like distributions such as NixOS and Guix do.
>
> you can use their package managers, and thus these features, on Debian
> today. there's also docker
On Fri, Feb 16, 2018 at 04:34:39PM +0100, Samuel Thibault wrote:
> Well, strictly speaking Debian does not actually need to be involved
> then, applications are already doing that. But it's indeed a sign that
> Debian is losing relevance, which is concerning and Debian could have to
> do something
On Fri, Feb 16, 2018 at 11:12:51AM -0500, Michael Stone wrote:
> On Fri, Feb 16, 2018 at 04:58:04PM +0100, Michael Meskes wrote:
> > I know that this does create some problems for us, e.g. on the security
> > side, but the alternative is, as you mentioned, manually installed
> > software and that s
Quoting Samuel Thibault :
What kind of relaxation could we introduce without damaging freeness?
And damaging quality. If a program uses some JS libraries without
any sources easily available, I cannot really promote this software.
Neither in Debian nor outside. This is just bad practice.
Or w
On Fri, Feb 16, 2018 at 04:58:04PM +0100, Michael Meskes wrote:
I know that this does create some problems for us, e.g. on the security
side, but the alternative is, as you mentioned, manually installed
software and that surely is worse.
No, I think it's better if people know they're on their o
> What can we do to avoid this?
>
> I don't have any definite answers although there are ideas to
> explore:
>
> - we could relax our requirements and have a way to document the
> limitations of those packages (wrt our usual policies)
>
> - we could ship those applications not as .deb but as c
> What do you think? Do you have other ideas? Are there other persons
> who are annoyed by the current situation?
Yes, indeed. I am more a simple user of Debian than a real Debian
Developer, but my feeling is paradoxical.
On one hand, I'd love to see some complex application in Debian, or at
least
On Fri, Feb 16, 2018 at 04:34:39PM +0100, Samuel Thibault wrote:
>
> When I see upstream java packages just stuffing .jar files without
> indication of where they come from or even their licencing terms, it's
> just unacceptable.
>
I see this as well and am quite frustrated by it. In the universi
Hello,
Raphael Hertzog, on ven. 16 févr. 2018 16:11:29 +0100, wrote:
> it can break in many ways whenever one the
> dozens of dependencies gets updated to some new upstream version
To me, that's really the problem: people are writing and piling layers
of free software without really caring a
On Fri, Feb 16, 2018 at 04:11:29PM +0100, Raphael Hertzog wrote:
> Hello everybody,
>
> the fact that I had to request the removal of dolibarr from Debian makes
> me sad (see below for the reasons) and I believe that we should be able
> to do better to provide complex applications to our end users
Hello everybody,
the fact that I had to request the removal of dolibarr from Debian makes
me sad (see below for the reasons) and I believe that we should be able
to do better to provide complex applications to our end users.
Dolibarr is not alone:
- while gitlab is packaged in Debian, its packag
101 - 158 of 158 matches
Mail list logo
