On Wed, 17 Jun 2015, Sebastiaan Couwenberg wrote:
Do you understand the point of view of a distribution like Debian?
It's clear that you don't share Debians concerns for software freedom and
focus on quality. And you're not alone in that, that's why it's always
Debian people that bring up
On Thu, 18 Jun 2015, Richard wrote:
While there are common practices to make software packaging friendly, it is
strange when a distribution tries the explain developers how they should
develop their software. Especially as Debian does not follow common
guidelines itself.
it is by no means
On Wed, 17 Jun 2015, Sebastiaan Couwenberg wrote:
Do you understand the point of view of a distribution like Debian?
It's clear that you don't share Debians concerns for software freedom
and
focus on quality. And you're not alone in that, that's why it's always
Debian people that bring up
On Thu, 18 Jun 2015, Nelson A. de Oliveira wrote:
I'm not aware of any other distribution, which tries to tell developers
that
they should not use another some open source code with valid license or
implement workarounds so that packagers are happy. I've never done this
or
heard of this
On Thu, Jun 18, 2015 at 8:46 AM, Dirk Stöcker
openstreet...@dstoecker.de wrote:
I'm not aware of any other distribution, which tries to tell developers that
they should not use another some open source code with valid license or
implement workarounds so that packagers are happy. I've never done
On Thu, 18 Jun 2015, Nelson A. de Oliveira wrote:
I'm not aware of any other distribution, which tries to tell developers that
they should not use another some open source code with valid license or
implement workarounds so that packagers are happy. I've never done this or
heard of this for
On Thu, 18 Jun 2015, Sebastiaan Couwenberg wrote:
No. The request is that we do not use it or make it optional.
I only asked if it was possible to make it optional, to quote my initial
email:
...
Thanks for continuously misrepresenting my words.
Do we speak different languages?
Where's
On 06/18/2015 03:57 PM, Dirk Stöcker wrote:
On Thu, 18 Jun 2015, Sebastiaan Couwenberg wrote:
No. The request is that we do not use it or make it optional.
I only asked if it was possible to make it optional, to quote my initial
email:
...
Thanks for continuously misrepresenting my words.
On 17.06.2015 00:21, Sebastiaan Couwenberg wrote:
Would it be possible to make JCS an optional dependency and use the
previous caching mechanism if it's not available?
We switched to the JCS cache to address an issue we had with the old
custom file based caching system: There was no global
On Wed, 17 Jun 2015, Vincent Privat wrote:
We understand the problem but I don't know if keeping the old cache is
easy
nor feasible. Wiktor what do you think? Is the old code still there or
has
it been dropped during the switch ?
Actually I DO NOT see the problem.
Debian requires
W dniu 17.06.2015 13:09, Vincent Privat napisał(a):
I can try to have a look but I never packaged something on Debian
before.
Is there a Debian packaging for dummies somewhere? :)
Short one is here:
https://wiki.debian.org/IntroDebianPackaging
Full documentation (I guess):
I can try to have a look but I never packaged something on Debian before.
Is there a Debian packaging for dummies somewhere? :)
2015-06-17 13:02 GMT+02:00 Sebastiaan Couwenberg sebas...@xs4all.nl:
We understand the problem but I don't know if keeping the old cache is
easy
nor feasible.
I can try to have a look but I never packaged something on Debian before.
Is there a Debian packaging for dummies somewhere? :)
The Debian New Maintainers' Guide is the official resource for people new
to Debian packaging:
https://www.debian.org/doc/manuals/maint-guide/
For the Debian GIS
On Wed, 17 Jun 2015, Vincent Privat wrote:
We understand the problem but I don't know if keeping the old cache is easy
nor feasible. Wiktor what do you think? Is the old code still there or has
it been dropped during the switch ?
Actually I DO NOT see the problem.
Debian requires building
On 06/17/2015 09:28 AM, Wiktor Niesiobedzki wrote:
I don't quite understand what's your goal. All dependencies are
included in josm*.jar. Do you intend to create your own *jar for
distribution without dependencies and use separate packages to provide
them?
For software to be included in
Hi,
I don't quite understand what's your goal. All dependencies are
included in josm*.jar. Do you intend to create your own *jar for
distribution without dependencies and use separate packages to provide
them?
Cheers,
Wiktor
2015-06-17 0:21 GMT+02:00 Sebastiaan Couwenberg sebas...@xs4all.nl:
On Wednesday, June 17, 2015, Sebastiaan Couwenberg sebas...@xs4all.nl
wrote:
On 06/17/2015 09:28 AM, Wiktor Niesiobedzki wrote:
I don't quite understand what's your goal. All dependencies are
included in josm*.jar. Do you intend to create your own *jar for
distribution without dependencies
But when you download the source code from our repository, you will get
all the dependencies. Ant build will create a jar that will contain all
necessary dependencies within. What's wrong with such approach?
Bundling dependencies is not a good thing. Take JMapViewer for example, we
build this
Hi Sebastiaan,
We understand the problem but I don't know if keeping the old cache is easy
nor feasible. Wiktor what do you think? Is the old code still there or has
it been dropped during the switch ?
Even if it's possible, it might lead to Debian specific bugs...
Couldn't we help you to package
We understand the problem but I don't know if keeping the old cache is
easy
nor feasible. Wiktor what do you think? Is the old code still there or has
it been dropped during the switch ?
Even if it's possible, it might lead to Debian specific bugs...
I'm afraid keeping the old caching as an
On Wed, 17 Jun 2015, Sebastiaan Couwenberg wrote:
I wish it was that simple. While the Debian Policy does not explicitly
require splitting out embedded dependencies, it's a very common packaging
best practice.
A recommendation is still no requirement.
Debian does recommend upstream
On Wed, 17 Jun 2015, Sebastiaan Couwenberg wrote:
I wish it was that simple. While the Debian Policy does not explicitly
require splitting out embedded dependencies, it's a very common
packaging
best practice.
A recommendation is still no requirement.
Debian does recommend upstream
22 matches
Mail list logo
