Hi Andreas,
Quoting Andreas Tille (2017-01-04 15:50:17)
> as in every release cycle I'm trying to verify that every package
> maintained in Debian Science team is properly categorised in our Blends
> tasks.
> I'm also fine if you debcheckout
> anonymously and send me `git format-patch` formated
(Dropping the CC list)
Hi Andreas,
I'm holding 6 uncategorized d-science packages.
* caffe and caffe-contrib are categorized into machine-learning task.
See the patch attached.
* the remaining 4 packages are core components of the torch7 framework,
and the torch7 metapackage (meta-torch-cor
Dear Andreas,
All my packages should really go to astronomy. Two sets of packages I
would hide in any case, the last one would need to fit in the right task
in the astronomy blend.
(python|python3|yorick)-pyorick hide
yorick-mira should go to astronomy
(python|python3|yorick)-svipc hide
Kind reg
Hi,
On 04/01/2017 15:50, Andreas Tille wrote:
as in every release cycle I'm trying to verify that every package
maintained in Debian Science team is properly categorised in our Blends
tasks. If a package is just a predependency for some other scientific
software I can add it to a blacklist of
Hi,
On Thu, Jan 05, 2017 at 02:46:55AM +, lumin wrote:
> I'm holding 6 uncategorized d-science packages.
>
> * caffe and caffe-contrib are categorized into machine-learning task.
> See the patch attached.
Thanks for the patch. Please note that for packages that are either
existing in Debi
Hi Thibaut
On Thu, Jan 05, 2017 at 07:07:16AM +0100, Thibaut Paumard wrote:
> All my packages should really go to astronomy. Two sets of packages I
> would hide in any case, the last one would need to fit in the right task
> in the astronomy blend.
>
> (python|python3|yorick)-pyorick hide
> yoric
Hi Julien,
On Thu, Jan 05, 2017 at 09:03:41AM +0100, Julien Puydt wrote:
> Ah, thanks for the heads-up and taking care of the blends!
You are welcome.
> Those should clearly be mathematics :
> - edge-addition-planarity-suite
I added planarity since the tasks files contain *binary* packages.
>
On 04/01/17 15:50, Andreas Tille wrote:
> Hi,
>
> as in every release cycle I'm trying to verify that every package
> maintained in Debian Science team is properly categorised in our Blends
> tasks. If a package is just a predependency for some other scientific
> software I can add it to a blackl
On Wed, Jan 04, 2017 at 05:47:50PM +0100, Maarten van Gompel wrote:
>
> python-pynlpl and uctodata should go to 'linguistics'
I did the following change:
$ git diff HEAD^
diff --git a/tasks/linguistics b/tasks/linguistics
index e414e94..197665f 100644
--- a/tasks/linguistics
+++ b/tasks/linguist
Hi Jose,
On Thu, Jan 05, 2017 at 03:21:39PM +0100, Jose Luis Rivero wrote:
> Thanks Andreas for the reminder. I've updated gazebo/sdformat versions
> and included gazebo into the simulation category. git format-patch attached.
Patch pushed. :-)
> Happy new year.
Same to you
Andreas.
--
Hi Thibaut, Andreas,
On 05.01.2017 14:39, Andreas Tille wrote:
> I realised that the astronomy task fully vanished from Debian Science
> since now there is a Debian Astro Blend. IMHO it makes sense to
> consider at least a task that sumarises all Debian Astro metapackages.
> Currently it looks as
Agreed. This is very weird from a Debian user point of view.
Astronomy is not Science ?
Thomas
> I realised that the astronomy task fully vanished from Debian Science
> since now there is a Debian Astro Blend. IMHO it makes sense to
> consider at least a task that sumarises all Debian Astro met
Hi Ole,
On Thu, Jan 05, 2017 at 03:34:52PM +0100, Ole Streicher wrote:
>
> When I removed the astronomy tasks from Debian Science, I added two
> transitional packages directly to debian/control.stub: science astronomy
> and science-astronomy-dev, to provide a smooth transition between the
> old t
On 05.01.2017 16:10, Andreas Tille wrote:
> For Debian Med its a bit different since its not only Biology. So
> adding the biology related metapackages seems somehow reasonable. I
> think the current approach works (at least I do not see any problem with
> it) so from my point of view we can leav
Dear Andreas,
Le 05/01/2017 à 14:39, Andreas Tille a écrit :
> Since this script has the logic to check whether a package that is
> maintained by the Debian Science team is mentioned in Debian Science
> tasks the best way to do the exclusion would be rather if you move your
> packages into Debian
On 4 January 2017 at 15:50, Andreas Tille wrote:
> as in every release cycle I'm trying to verify that every package
> maintained in Debian Science team is properly categorised in our Blends
> tasks. If a package is just a predependency for some other scientific
> software I can add it to a blac
Hi Tino,
On Fri, Jan 06, 2017 at 12:17:38PM +0100, Tino Didriksen wrote:
>
> giella-sme and everything built from hfst, hfst-ospell, lttoolbox fit in
> linguistics, given that there isn't a linguistics-dev task.
Since we do not have a linguistics-dev task I have done
$ git diff HEAD^
diff --gi
Hi Sébastien,
On Tue, Jan 10, 2017 at 11:29:14AM +0100, Sébastien Villemot wrote:
> > BTW, I removed r-base from the economics task since it seemed to
> > unspecific for me and it will be pulled in by the other r-* packages
> > anyway. I hope you agree with this - if not feel free to revert.
>
>
Le mardi 10 janvier 2017 à 12:05 +0100, Andreas Tille a écrit :
>
> On Tue, Jan 10, 2017 at 11:29:14AM +0100, Sébastien Villemot wrote:
> > If it is the former, it makes senses to remove r-base (+ octave and
> > julia). But if it is the latter (and it is what I was implicitly
> > assuming), then
On 04.01.2017 15:50, Andreas Tille wrote:
> Hi,
>
> as in every release cycle I'm trying to verify that every package
> maintained in Debian Science team is properly categorised in our Blends
> tasks. If a package is just a predependency for some other scientific
> software I can add it to a blac
On Sat, Jan 21, 2017 at 09:30:41PM +0100, Daniel Stender wrote:
> ... Theano would be belong into numerical computation.
>
> ---
> tasks/numericalcomputation | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/tasks/numericalcomputation b/tasks/numericalcomputation
> index cb0a7bb..b092
dolfin-bin and fenics are currently listed under the mathematics task.
In a sense python-dolfin is more appropriate for listing than dolfin-
bin. But dolfin-bin depends on it and also provides a couple of small
utility programs. So I'm inclined to leave dolfin-bin as listed
dolfin is the front-e
Hi Andreas, there are a couple more fenics components in the
mathematics-dev task:
Python-dolfin (and dolfin-dev)
python-ffc
python-ufl
I'm thinking it's redundant to list these separately under
mathematics-dev if there's already an entry in the mathematics task.
Likewise in your not-yet
Hi Drew,
I'm not sure whether I fully understand your suggestion.
On Thu, Jan 05, 2017 at 01:26:46PM +0800, Drew Parsons wrote:
> Hi Andreas, there are a couple more fenics components in the
> mathematics-dev task:
>
> python-dolfin (and dolfin-dev)
> python-ffc
> python-ufl
>
> I'm thin
On Thu, Jan 5, 2017 at 6:04 AM, Drew Parsons wrote:
> dolfin is the front-end of the FENiCS system, and I think the fenics
> package is now deprecated. Johannes, did you intend to update the
> fenics Debian metapackage, or should we remove it from the Debian
> archive?
I have already updated the
On Thu, 2017-01-05 at 14:13 +0100, Johannes Ring wrote:
> On Thu, Jan 5, 2017 at 6:04 AM, Drew Parsons
> wrote:
> > dolfin is the front-end of the FENiCS system, and I think the
> > fenics
> > package is now deprecated. Johannes, did you intend to update the
> > fenics Debian metapackage, or shou
On Thu, Jan 5, 2017 at 6:03 PM, Drew Parsons wrote:
> On Thu, 2017-01-05 at 14:13 +0100, Johannes Ring wrote:
>> On Thu, Jan 5, 2017 at 6:04 AM, Drew Parsons
>> wrote:
>> > dolfin is the front-end of the FENiCS system, and I think the
>> > fenics
>> > package is now deprecated. Johannes, did you
On Thu, 2017-01-05 at 18:11 +0100, Johannes Ring wrote:
> On Thu, Jan 5, 2017 at 6:03 PM, Drew Parsons
> wrote:
> >
> > No worries, thanks Johannes. We'll keep the fenics metapackage.
> >
> > In regards to Andreas' task package, is there any sense putting in
> > two
> > references, one for dolfi
On Thu, Jan 5, 2017 at 6:23 PM, Drew Parsons wrote:
> On Thu, 2017-01-05 at 18:11 +0100, Johannes Ring wrote:
>> On Thu, Jan 5, 2017 at 6:03 PM, Drew Parsons
>> wrote:
>> >
>> > No worries, thanks Johannes. We'll keep the fenics metapackage.
>> >
>> > In regards to Andreas' task package, is there
On Thu, 2017-01-05 at 14:01 +0100, Andreas Tille wrote:
> Hi Drew,
>
> I'm not sure whether I fully understand your suggestion.
What I mean is that there are a number of component packages which
together make up FENiCS:
dolfin-bin
python-dolfin
python-ffc
python-ufl
python-dij
Hi again,
On Fri, Jan 06, 2017 at 01:40:52AM +0800, Drew Parsons wrote:
>
> What I mean is that there are a number of component packages which
> together make up FENiCS:
> dolfin-bin
> python-dolfin
> python-ffc
> python-ufl
> python-dijitso
> python-instant
> python-m
On Thu, 2017-01-05 at 21:36 +0100, Andreas Tille wrote:
> I'd like you something else to consider: A user *application* should
> not contain the programming language it was written in its package
> name.
> I have not checked but dolphin-bin sounds way more like a user
> application than python-do
Hi Andreas,
thank you for your continuous effort!
I see ros-opencv-apps in the list, which is not in testing (and will not
make it, due to the freeze). So I assume it shouldn't be categorised as
well.
Regarding ros-ros, I think it would make sense to blacklist it, as it is
only the base of a lot
Hi Jochen,
On Thu, Feb 09, 2017 at 03:48:20PM +0100, Jochen Sprickerhof wrote:
>
> I see ros-opencv-apps in the list, which is not in testing (and will not
> make it, due to the freeze). So I assume it shouldn't be categorised as
> well.
Please categorise *any* of your packages - be it in testin
* Andreas Tille [2017-02-09 16:29]:
> Please categorise *any* of your packages - be it in testing or not. The
> metapackage creation process will verify whether a package is in testing
> and add Recommends *only* if a package is in testing. If not the
> package gets a Suggests - which IMHO is ve
Dear Andreas,
I would have been happy to do the job directly but I currently do not
have access to a running debian machine I can "control" (have devscripts
installed) and I lack time/HD space for a VM install. It perhaps could
make sense to have it on alioth? (no troll intended - if it can be
cat
Dear Thomas,
thanks for your attempt to help. Hope I can clarify how you can do this
more easy.
On Fri, Feb 10, 2017 at 12:58:50PM +0100, Thomas Schiex wrote:
> I would have been happy to do the job directly but I currently do not
> have access to a running debian machine I can "control" (have d
Andreas,
>> I'm sorry,[..] You just need Git to download
>> the repository and the repository has 5MB. :-P
>> The repositories are on alioth. You can also
>> perfectly login to Alioth and clone + commit + push.
Sorry, I'm showing off my mediocre knowledge of debian(science)
organization. I just
Hi Thomas,
On Fri, Feb 10, 2017 at 06:41:22PM +0100, Thomas Schiex wrote:
> > To add a binary (!) package to a task you can simply
> > debcheckout -u your_alioth_login debian-science
> > cd debian-science/tasks
> > and edit the task in question.
> and debcheckout is in devscripts. I just d
Hi Andreas,
thank you for your reminder. I finally made it to add calculix-cgx to the
appropriate task. Unfortunately I get the folloeing error trying to push my
changes to the repository:
remote: error: insufficient permission for adding an object to repository
database ./objects
remote: fat
Hi Wolfgang,
On Mon, Feb 13, 2017 at 07:55:49PM +0100, Wolfgang Fütterer wrote:
> thank you for your reminder. I finally made it to add calculix-cgx to the
> appropriate task. Unfortunately I get the folloeing error trying to push my
> changes to the repository:
>
> remote: error: insufficient
41 matches
Mail list logo
