shall we keep collecting suggestions in the task files?

[Andreas Tille]

Hi Holger,

as we keep many suggestions, candidates,

Keeping candidates is perfectly supported. However, you can ... and
should provide some metadata for candidates. The way you can do this
is either

1. Add some rudimentary packaging in your packaging VCS containing
a valid d/changelog, d/control including Homepage and description
and optionally a DEP5 formatted d/copyright skeleton. There is
an UDD importer that fetches this data and adds the info to the
tasks page.

2. Add the metadata right into the tasks file.

Both is explained in the Blends documentation[1]. Option 1. is prefered
since it shows that your interest into the package is somehow "honest".
The Med Bio task[2] provides an extensive example of all options.

valid packages which then get
orphaned or renamed, in the tasks files, the task files collect "dust"
and thus it becomes harder to see real issues in the task files.

I personally think that so called "prospective packages" should always
be accompanied by some metainformation which enables rendering on the
tasks pages. If you do not mind providing this bit of information I
doubt that the intent to work on this will be really honest. So it is
really easy to detect "dust": Dependencies that are not in the Debian
package pool and do not have any metainformation are dust, IMHO.

Using the output from the udd importer this is the dust there is
currently, see below.
I've checked some of the packages and some of them are indeed provided by
alternatives, so I don't think now is there right time to clean this up,
but rather after the Jessie release.

Hmmm, unfortunately this argument was used even two releases before. :-(

And I also think this will only be
useful if we change the way we keep track of suggested packages.

+1 (see above)

Maybe
have a special task file just for those?

I do not think this is a good idea since by nature this is not really a
task in the sense we are using tasks.

And then once they become
available, we move them to the "real" tasks? This sounds a bit like a
generally useful feature for blends-dev - what do you think?

No. Blends-dev has a feature to deal with non-existing packages.

Kind regards

Andreas.

[1] http://blends.debian.org/blends/ch08.html#edittasksfiles
[2] http://blends.debian.org/med/tasks/bio#pkgvcs-debs

[Holger Levsen]

Hi,

Post by Andreas Tille
1. Add some rudimentary packaging in your packaging VCS containing
a valid d/changelog, d/control including Homepage and description
and optionally a DEP5 formatted d/copyright skeleton. There is
an UDD importer that fetches this data and adds the info to the
tasks page.

nope, that doesnt fit here.

Post by Andreas Tille
2. Add the metadata right into the tasks file.
Both is explained in the Blends documentation[1]. Option 1. is prefered
since it shows that your interest into the package is somehow "honest".
The Med Bio task[2] provides an extensive example of all options.

so the first software there is "Acacia" an "Error-corrector for pyrosequenced
amplicon reads.", how is that in your task file? how is that even part of the
debian-med source package?

matrix:~/m$ apt-get source debian-med
[...]
matrix:~/m$ cd debian-med-1.13.2/
matrix:~/m/debian-med-1.13.2$ ls
AUTHORS config COPYING debian debian-med-tasks.desc Makefile menu
README tasks tasks.ctl
matrix:~/m/debian-med-1.13.2$ grep -i Acacia tasks/*
matrix:~/m/debian-med-1.13.2$ rgrep -i Acacia *

hmmm.

Post by Andreas Tille
I personally think that so called "prospective packages" should always
be accompanied by some metainformation which enables rendering on the
tasks pages. If you do not mind providing this bit of information I
doubt that the intent to work on this will be really honest.

there is no(t neccessarily an) "intend to work on these packages", sometimes
we just want to track them (and use them if someone else packages them).

Post by Andreas Tille
So it is
really easy to detect "dust": Dependencies that are not in the Debian
package pool and do not have any metainformation are dust, IMHO.

yeah, maybe. I've looked at
http://blends.debian.org/blends/ch08.html#edittasksfiles now and "Ignore"
seems to be what we want and which we already use for such packges.

But then I still wonder about the "Acacia" example above! :)

Post by Andreas Tille

I've checked some of the packages and some of them are indeed provided by
alternatives, so I don't think now is there right time to clean this up,
but rather after the Jessie release.

Hmmm, unfortunately this argument was used even two releases before. :-(

Unfortunatly it's again true.

Post by Andreas Tille
No. Blends-dev has a feature to deal with non-existing packages.

Great. Just that it doesn't seem to be enough / used / used correctly, for
whatever reason(s).


cheers,
Holger

[Andreas Tille]

Post by Holger Levsen
Hi,

Post by Andreas Tille
1. Add some rudimentary packaging in your packaging VCS containing
a valid d/changelog, d/control including Homepage and description
and optionally a DEP5 formatted d/copyright skeleton. There is
an UDD importer that fetches this data and adds the info to the
tasks page.

nope, that doesnt fit here.

Post by Andreas Tille
2. Add the metadata right into the tasks file.
Both is explained in the Blends documentation[1]. Option 1. is prefered
since it shows that your interest into the package is somehow "honest".
The Med Bio task[2] provides an extensive example of all options.

so the first software there is "Acacia" an "Error-corrector for pyrosequenced
amplicon reads.", how is that in your task file? how is that even part of the
debian-med source package?
matrix:~/m$ apt-get source debian-med
[...]
matrix:~/m$ cd debian-med-1.13.2/
matrix:~/m/debian-med-1.13.2$ ls
AUTHORS config COPYING debian debian-med-tasks.desc Makefile menu
README tasks tasks.ctl
matrix:~/m/debian-med-1.13.2$ grep -i Acacia tasks/*
matrix:~/m/debian-med-1.13.2$ rgrep -i Acacia *
hmmm.

Try

debcheckout debian-med

instead. The tasks pages are created from VCS rather than the package
source.

Post by Holger Levsen

Post by Andreas Tille
I personally think that so called "prospective packages" should always
be accompanied by some metainformation which enables rendering on the
tasks pages. If you do not mind providing this bit of information I
doubt that the intent to work on this will be really honest.

there is no(t neccessarily an) "intend to work on these packages", sometimes
we just want to track them (and use them if someone else packages them).

You could at least add a Comment about this ...

Post by Holger Levsen

Post by Andreas Tille
So it is
really easy to detect "dust": Dependencies that are not in the Debian
package pool and do not have any metainformation are dust, IMHO.

yeah, maybe. I've looked at
http://blends.debian.org/blends/ch08.html#edittasksfiles now and "Ignore"
seems to be what we want and which we already use for such packges.

The "Ignore" exists for this very purpose and was injected by Petter.

Post by Holger Levsen
But then I still wonder about the "Acacia" example above! :)

You simply need to understand that we try to get the information as
current as possible and the source packages are simply static. Any VCS
commit to the tasks files will trigger a rerendering of the tasks pages
(after 15min cron job).

Post by Holger Levsen

Post by Andreas Tille

I've checked some of the packages and some of them are indeed provided by
alternatives, so I don't think now is there right time to clean this up,
but rather after the Jessie release.

Hmmm, unfortunately this argument was used even two releases before. :-(

Unfortunatly it's again true.

:-(

Post by Holger Levsen

Post by Andreas Tille
No. Blends-dev has a feature to deal with non-existing packages.

Great. Just that it doesn't seem to be enough / used / used correctly, for
whatever reason(s).

... in Debian Edu. That's correct.

Kind regards

Andreas.

[Holger Levsen]

Hi,

(do I need to you cc: you, Andreas?)

Post by Andreas Tille
Try
debcheckout debian-med
instead. The tasks pages are created from VCS rather than the package
source.

I see. And how is the vcs turned into the source package, or why is acacia
mentioned in tasks/bio in VCS but not in the source package? Where is the
logic for that? And does it have to be that way?

IOW: how can we get our candidates on our blends pages?

Post by Andreas Tille
You could at least add a Comment about this ...

in future, yes, we should. but there is no (realistic) way we do this for the
100 old entries.

Post by Andreas Tille
The "Ignore" exists for this very purpose and was injected by Petter.

Why don't you ignore acacia then?


cheers,
Holger

[Andreas Tille]

Post by Holger Levsen
(do I need to you cc: you, Andreas?)

I'd prefer CCing Debian Edu list (since it is not subscribed to the bug)

Post by Holger Levsen

Post by Andreas Tille
Try
debcheckout debian-med
instead. The tasks pages are created from VCS rather than the package
source.

I see. And how is the vcs turned into the source package, or why is acacia
mentioned in tasks/bio in VCS but not in the source package?

Well, we are developing in VCS, right? It will be part of the next
release of the source package.

Post by Holger Levsen
Where is the
logic for that? And does it have to be that way?

I'm sorry, what type of question is this? I admit I'm perplexed.

Post by Holger Levsen
IOW: how can we get our candidates on our blends pages?

Add it to the tasks files in Debian Edu Git.

Post by Holger Levsen

Post by Andreas Tille
The "Ignore" exists for this very purpose and was injected by Petter.

Why don't you ignore acacia then?

Since it is not set to "Ignore"? I also do not understand this question,
sorry.

Kind regards

Andreas.