Hi Martin,
On Mon, Jan 11, 2016 at 11:06:30AM +0100, Martin Uecker wrote:
>
> It was meant for system-wide add-ons installed by
> other packages or compiled locally. But you are right,
> another package could create it itself and locally compiled
> stuff should go in /usr/local/...
... so it
Hi Andreas,
> For me the package is close to ready if I would understand why you
> insist on the empty dir usr/lib/bart/commands/. I do not see any reason
> for this since in /usr only packages can / should write and a package
> that writes to this location would create the package itself.
> There are three remaining and easy to fix lintian issues:
>
> I: bart source: duplicate-short-description bart libbart-dev
> W: bart: package-installs-into-obsolete-dir etc/bash_completion.d/ :
> ^etc/bash_completion.d/ -> usr/share/bash-completion/completions (see also
>
Hi Martin,
On Sun, Jan 10, 2016 at 02:56:27PM +0100, Martin Uecker wrote:
> > There are three remaining and easy to fix lintian issues:
> >
> > I: bart source: duplicate-short-description bart libbart-dev
> > W: bart: package-installs-into-obsolete-dir etc/bash_completion.d/ :
> >
On 09/01/16 08:35, Martin Uecker wrote:
Ghislain Vaillant :
FYI, the same trick is used for other dependencies with multiple
backends such as OpenCL.
What is the state of OpenCL on Debian?
The OpenCL headers are regularly updated, so are the main open-source
drivers
On 09/01/16 08:35, Martin Uecker wrote:
Ghislain Vaillant :
FYI, the same trick is used for other dependencies with multiple
backends such as OpenCL.
What is the state of OpenCL on Debian?
The OpenCL headers are regularly updated, so are the main open-source
drivers
On 09/01/16 08:03, Martin Uecker wrote:
What are the next steps?
Submit an RFS bug [1] and upload the package to mentors [2].
That's the usual route. Maybe the MoM process is different though. To be
checked with Andreas.
[1] http://mentors.debian.net/sponsor/rfs-howto
[2]
Hi,
On Sat, Jan 09, 2016 at 10:46:45AM +, Ghislain Vaillant wrote:
> On 09/01/16 08:03, Martin Uecker wrote:
> >What are the next steps?
>
> Submit an RFS bug [1] and upload the package to mentors [2].
In the Debian Med team we simplify this. A mail here on the list where
you announce that
Hi,
no further comments to the OpenCL question which is IMHO fully answered
(way better than I could since I have no experience in this field).
There are three remaining and easy to fix lintian issues:
I: bart source: duplicate-short-description bart libbart-dev
N:
N:The listed binary
Hi Ghislain,
Ghislain Vaillant :
> On 08/01/16 19:29, Martin Uecker wrote:
> Good. Then, you might want to use libbart-dev as the package name, which
> is usually the naming convention for packages containing any libraries
> (in shared or static form).
Done.
> > Also
Ghislain Vaillant :
>
> FYI, the same trick is used for other dependencies with multiple
> backends such as OpenCL.
What is the state of OpenCL on Debian?
We only support CUDA in BART, but I always wanted to add OpenCL
support and it should be fairly easy...
Martin
Hi Ghisvail!
> - Binary packages split-up.
>
> I am not quite sure about the usefulness of the bart-dev package. The final
> compilation line shows:
...
> i.e. the final output is one executable (bart) with private libraries
> (libbox, libgrecon...) linked statically. So it looks to me that
On 08/01/16 19:29, Martin Uecker wrote:
Hi Ghisvail!
- Binary packages split-up.
I am not quite sure about the usefulness of the bart-dev package. The final
compilation line shows:
...
i.e. the final output is one executable (bart) with private libraries (libbox,
libgrecon...) linked
On Fri, Jan 01, 2016 at 11:00:20AM +0100, Martin Uecker wrote:
>
> >dh_clean
> > dpkg-source -i.git -I.git -b bart-0.2.09d
> > dpkg-source: info: using options from bart-0.2.09d/debian/source/options:
> > --extend-diff-ignore=(^|/)(version.(inc|txt)|commands.txt)$
> > dpkg-source: info:
Hi Andreas,
> I get:
>
> ...
>dh_clean
> dpkg-source -i.git -I.git -b bart-0.2.09d
> dpkg-source: info: using options from bart-0.2.09d/debian/source/options:
> --extend-diff-ignore=(^|/)(version.(inc|txt)|commands.txt)$
> dpkg-source: info: using source format '3.0 (quilt)'
>
Hi Martin,
Great to see that your packaging work is progressing. Here are a few
remarks on my side:
- Binary packages split-up.
I am not quite sure about the usefulness of the bart-dev package. The
final compilation line shows:
gcc -O3 -ffast-math -std=c99 -Wmissing-prototypes
Hi Andreas and Ghislain,
the bart package now produces a -dev package and a
octave-bart package. It also includes a bash completion
script. pristine-tar produces the correct upstream
tar ball.
I would appreciate if you could take a look and let
me know what else could be improved...
Also I
Hi Martin,
On Mon, Dec 28, 2015 at 11:30:33AM +, Uecker, Martin wrote:
> the bart package now produces a -dev package and a
> octave-bart package. It also includes a bash completion
> script. pristine-tar produces the correct upstream
> tar ball.
Sounds good.
> I would appreciate if you
Hi Martin, some pieces of advice below:
On 07/12/15 11:26, Martin Uecker wrote:
The only issue is that I have to specify the tag with 'gdb'
because it looks for 'upstream/v0.2.09' which does not
currently exist. Instead of adding these tags, I would prefer
to reconfigure 'gdb' to use the
On Mon, 2015-12-07 at 08:58 +, Ghislain Vaillant wrote:
> You could use something like libgsl0-dev | libgsl-dev to stay
> compatible with earlier versions?
This should probably be the other way around, i.e.
libgsl-dev | libgsl0-dev
so that the new package takes precedence.
Best,
Hi Andreas,
> On Sun, Dec 06, 2015 at 11:59:02PM +, Uecker, Martin wrote:
> > > Put simply, pristine-tar is our way to encapsulate access to the source
> > > tarball used for packaging. Someone who checks out a d-science
> > > repository does not need to know where the tarball comes from
On 07/12/15 08:18, Uecker, Martin wrote:
Hi Andreas,
On Sun, Dec 06, 2015 at 11:59:02PM +, Uecker, Martin wrote:
Put simply, pristine-tar is our way to encapsulate access to the source
tarball used for packaging. Someone who checks out a d-science
repository does not need to know where
Hi Martin,
On Mon, Dec 07, 2015 at 08:18:59AM +, Uecker, Martin wrote:
>
> Hi Andreas,
>
> > On Sun, Dec 06, 2015 at 11:59:02PM +, Uecker, Martin wrote:
> > > > Put simply, pristine-tar is our way to encapsulate access to the source
> > > > tarball used for packaging. Someone who
Hi Andreas,
> On Mon, Dec 07, 2015 at 08:18:59AM +, Uecker, Martin wrote:
> > > On Sun, Dec 06, 2015 at 11:59:02PM +, Uecker, Martin wrote:
> > > > > Put simply, pristine-tar is our way to encapsulate access to the
> > > > > source
> > > > > tarball used for packaging. Someone who
On 06/12/15 12:32, Uecker, Martin wrote:
Hi Andreas,
Ok, I put it in /git/debian-med/bart.git as described in the
debian-med policy.
I checked this out and added Vcs fields and Homepage to Debian control
(please pull). I noticed that the pristine-tar branch is missing in the
git
Hi Andreas,
> >
> > Ok, I put it in /git/debian-med/bart.git as described in the
> > debian-med policy.
>
> I checked this out and added Vcs fields and Homepage to Debian control
> (please pull). I noticed that the pristine-tar branch is missing in the
> git repository. You can get this
Am Sonntag, den 06.12.2015, 13:57 + schrieb Ghislain Vaillant:
>
> On 06/12/15 12:32, Uecker, Martin wrote:
> > Hi Andreas,
> >
> >>> Ok, I put it in /git/debian-med/bart.git as described in the
> >>> debian-med policy.
> >> I checked this out and added Vcs fields and Homepage to Debian
Hi Martin,
On Sun, Dec 06, 2015 at 11:59:02PM +, Uecker, Martin wrote:
> > Put simply, pristine-tar is our way to encapsulate access to the source
> > tarball used for packaging. Someone who checks out a d-science
> > repository does not need to know where the tarball comes from (github,
>
Hi Martin,
I just officially added you to the MoM wiki.
On Tue, Dec 01, 2015 at 04:33:19PM +, Uecker, Martin wrote:
> > Thanks for letting me know. Please try at least to get ssh access
> >
> > ssh git.debian.org
> >
> > via ssh key and commit the repository. I'll check what
29 matches
Mail list logo