[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#883297: marked as done ("Packages: list" field removed from tasksel control file)

Your message dated Wed, 17 Jan 2018 11:31:52 +0100
with message-id <[🔎] 20180117103152.vknwo7ws2anojzzi@an3as.eu>
and subject line Re: Bug#883297: "Packages: list" field removed from tasksel control file
has caused the Debian Bug report #883297,
regarding "Packages: list" field removed from tasksel control file
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
883297: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883297
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: blends-dev
Severity: important

Hi,

I intend to create a new set of metapackages for Debian Med.  After the
generation using blends-dev 0.6.100 I realised the following diff:

diff --git a/debian-med-tasks.desc b/debian-med-tasks.desc
index 40e4191..6108c40 100644
--- a/debian-med-tasks.desc
+++ b/debian-med-tasks.desc
@@ -1,817 +1,61 @@
+Task: debian-med
+Relevance: 7
+Section: debian-med
+Description: Debian Med Pure Blend
+ .
+
 Task: med-bio
+Parent: debian-med
 Section: debian-med
 Description: Debian Med bioinformatics packages
  This metapackage will install Debian packages for use in molecular biology,
  structural biology and other biological sciences.
-Relevance: 10
-Key:
+Test-new-install: mark show
+Key: 
  med-bio
-Packages: list
- abacas
- abyss
- acedb-other
- acedb-other-belvu
- acedb-other-dotter
- adapterremoval
- adun-core
- aegean
- aevol
...


In other words:  The field

   Packages: list

is missing (for all tasks).  I suspect this might be connected to the
s/Depends/Recommends change in blends-dev 0.6.99.  Please correct me
if I'm wrong (since I'm not a tasksel expert) but this is an unwanted
side effect, right?

Mike, could you have a look?

Thanks a lot

       Andreas.


-- System Information:
Debian Release: 9.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages blends-dev depends on:
ii  debconf    1.5.61
pn  debhelper  <none>
ii  make       4.1-9.1

blends-dev recommends no packages.

Versions of packages blends-dev suggests:
pn  blends-doc  <none>

--- End Message ---
--- Begin Message --- 
Hi Wolfgang,

On Tue, Jan 16, 2018 at 11:11:12PM +0100, Wolfgang Schweer wrote:
> 
> One more thing:
> I ran 'git log --follow debian-med-tasks.desc'
> 
> debian-med-tasks.desc with 'Packages: list' content is due to your 
> commit 2c219f08e54:
> 
> 'Render dependency relations using UDD based blends-dev'

Ups, sorry for the noise (hereby closing the bug).  I unintentionally
commited also the debian-med-tasks.desc file after generating the
statistics data in dependency_data.  Thanks a lot for taking over my
job to read the logs. :-(
 
> Don't know what this actually means, but maybe the reason is a different 
> blends-dev?

This is

    https://anonscm.debian.org/git/blends/blends-gsoc.git

and it *really*, *urgently* should be moved into production.  It was
done in a GSoC project in 2013 and was somehow "close to ready" but
obviously time went over this state.  Unfortunately I (nor anybody else)
found the time to finalise things to fully replace the old blends-dev
code.  The major feature which makes it *really* important is that
it generates architecture dependant metapackages.  The problem is that
our metapackages only work for amd64 architecture and that there are
lots of packages missing on other architectures.  Its just that nobody
really uses those metapackages so nobody realises in practice but it
is definitely a problem we should care about.

The other feature I'm using is that the dependency_data for each release
are kept which I'm using for some statistics about the development of
metapackages.  So I'm silently running the other blends-dev code, commit
the dependency_data (+ the autogenerated changelog entries which are
done as well) and afterwards I rerun with the production blends-dev.
That's a pretty boring and obviously dangerous workflow.  So again:
If anybody (with some Python skills) likes to have a look it would be
definitely worth to do (and I'd love to spent some time cycles into
it as well but I can not do the whole job).

So thanks again for helping me out of my own mess and lets try to
get out the new blends-dev in Buster.

Kind regards

       Andreas.

-- 
http://fam-tille.de

--- End Message ---
Reply to: