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
Dear Raju,
On Fri, Feb 16, 2018 at 09:18:06PM +0530, Raju Devidas wrote:
> Hello Kumar,
>
> I took a look at your repository on salsa.
> Before taking a look at your repository I have also taken a look at some
> other repositories on github which had steps for
> supporting Ubuntu on the RDP.
>
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
Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu
* Package name: golang-github-valyala-fasthttp
Version : 20160617-1
Upstream Author : Aliaksandr Valialkin, VertaMedia
* URL : https://github.com/valyala/fasthttp
* License : Expat
Programming Lang: go
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 --
Package: wnpp
Severity: wishlist
Owner: Michael Stapelberg
* Package name: golang-gopkg-warnings.v0
Version : 0.1.2-1
Upstream Author : Péter Surányi
* URL : https://github.com/go-warnings/warnings
* License : BSD-2-clause
Programming Lang: Go
Description
Package: wnpp
Severity: wishlist
Owner: Michael Meskes
* Package name: webext-bulk-media-downloader
Version : 0.2.1
Upstream Author : InBasic
* URL :
https://addons.mozilla.org/firefox/addon/bulk-media-downloader/
* License : MPL-2.0
Programming Lang: Java
> > 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
Package: wnpp
Severity: wishlist
Owner: Markus Koschany
* Package name: jboss-bridger
Version : 1.4
Upstream Author : Red Hat Inc.
* URL : https://github.com/dmlloyd/bridger
* License : LGPL-2.1+
Programming Lang: Java
Description : Java Bridge Method M
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
On Fri, 16 Feb 2018 14:10:30 +0100, Raphael Hertzog wrote:
> Hi,
>
> On Fri, 19 Jan 2018, Jeremy Bicha wrote:
>> 3. If a team manages to get a lists.debian.org address, it's
>> recommended that they switch the Maintainer fields in their packages
>> from the Alioth list address to that address, ri
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 Kumar,
I took a look at your repository on salsa.
Before taking a look at your repository I have also taken a look at some
other repositories on github which had steps for
supporting Ubuntu on the RDP.
Specially this one.
https://github.com/sundarnagarajan/rdp-thinbook-linux
Most of the
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
On Fri, Feb 16, 2018 at 4:29 AM, Ghislain Vaillant
wrote:
> Le jeudi 15 février 2018 à 10:05 -0500, Florian Grignon a écrit :
> > Package: wnpp
> > Severity: wishlist
> > Owner: Florian Grignon
> >
> > * Package name: python3-anosql
>
> s/python3-anosql/python-anosql
>
> The name for the sou
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
On Fri, 16 Feb 2018, Thibaut Paumard wrote:
> Don't those two last paragraphs contradict each other? Or do you mean that
> team subscribers will (still) receive only the automatic maintenance
> e-mails?
Yes, team subscribers receive only the automatic e-mails forwarded by the
various services (BTS
Package: ftp.debian.org
Severity: normal
I'm the usual sponsor of dolibarr in Debian. The maintainer (and
upstream author) Eldy Destailleur announced me a few weeks ago that he
will no longer be maintaining Dolibarr within Debian because it was
too much of a pain to respect all the Debian requirem
Thank you All for the discussion. It looks like official part, e.g. bug
registration, should be done as usually, while technical work may be done
using git lab.
-Pavlo Solntsev
-
*Please avoid sending me W
Le 16/02/2018 à 14:10, Raphael Hertzog a écrit :
Yes, you can put team+@tracker.debian.org in your Maintainers
fields.
eg. team+pkg-secur...@tracker.debian.org for
https://tracker.debian.org/teams/pkg-security/
It's possible to use this right now (it will not generate any bounce) but
direct ma
Hi,
On Fri, 19 Jan 2018, Jeremy Bicha wrote:
> 3. If a team manages to get a lists.debian.org address, it's
> recommended that they switch the Maintainer fields in their packages
> from the Alioth list address to that address, right?
It depends on your choice. But I would not recommend this. I wo
Le jeudi 15 février 2018 à 10:05 -0500, Florian Grignon a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Florian Grignon
>
> * Package name: python3-anosql
s/python3-anosql/python-anosql
The name for the source package should use the python- prefix as in
Python the language. The pyth
53 matches
Mail list logo
