Bug#1054757: blends: FTBFS: make[1]: *** [debian/rules:20: override_dh_auto_test] Error 1

[Ole Streicher]

Hi Andreas,

yes: the tests for the Python package fail because they depend on which 
packages are in the astro-education task. Specifically, the "starplot" 
package was removed from Debian after Bookworm.


I now updated the debian-astro Blends package to reflect the package 
changes after Bookworm. It needs to migrate to testing (because the 
"testing" list is used in the tests, as the whole blends machinery is 
based on "testing"), and then I will upload a blends-dev package with 
the tests fixed.


astro-education evolves rather slowly, that's why I have chosen this one 
for the test.


Cheers

Ole

On 01.11.23 10:29, Andreas Tille wrote:

Hi,

any idea what might be wrong here?

Kind regards
 Andreas.

Am Fri, Oct 27, 2023 at 09:29:30PM +0200 schrieb Lucas Nussbaum:

Source: blends
Version: 0.7.5
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20231027 ftbfs-trixie

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):

make[1]: Entering directory '/<>'
pytest-3 --doctest-modules
= test session starts ==
platform linux -- Python 3.11.6, pytest-7.4.3, pluggy-1.3.0
rootdir: /<>
collected 8 items

blends.py F..F   [100%]

=== FAILURES ===
 [doctest] blends.Task.fix_dependencies 
469 celestia-gnome | celestia-glut
470 starplot
471 gravit
472 >>> for dep in task.suggests:
473 ... print(dep.rawstr)
474 sunclock
475 xtide
476 >>> task += apt.Cache()
477 >>> missing = task.fix_dependencies()
478 >>> for dep in task.recommends:
Expected:
 starplot
 gravit
Got:
 gravit

/<>/blends.py:478: DocTestFailure
_ [doctest] blends.Task.update _
434 Instead of using ``update()``, also the ``+=`` operator can be used:
435
436 >>> import apt
437 >>> with open('education') as fp:
438 ... task = Task('debian-astro', 'education', fp)
439 >>> dep = task.recommends[1][0]
440 >>> print(dep.name + ": ", dep.summary)
441 starplot:  None
442 >>> task += apt.Cache()
443 >>> print(dep.name + ": ", dep.summary)
Expected:
 starplot:  3-dimensional perspective star map viewer
Got:
 starplot:  None

/<>/blends.py:443: DocTestFailure
=== short test summary info 
FAILED blends.py::blends.Task.fix_dependencies
FAILED blends.py::blends.Task.update
= 2 failed, 6 passed in 0.95s ==
make[1]: *** [debian/rules:20: override_dh_auto_test] Error 1



The full build log is available from:
http://qa-logs.debian.net/2023/10/27/blends_0.7.5_unstable.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20231027;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20231027=lu...@debian.org=1=1=1=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Re: Bug#1018146: correct multiarch for blends stuff?

[Ole Streicher]

Petter Reinholdtsen  writes:
> [Ole Streicher]
>> We can also just make the final metapackage relase after the freeze
>> stops NEW processing.
>
> As far as I know this is done, and need to be done, and will continue to
> do so in the future. :)

I thought that we (at least Andreas) waited until the very last moment
to be save not being affected by last-moment testing removals. Maybe I
am wrong here, however.

Cheers

Ole

Re: Bug#1018146: correct multiarch for blends stuff?

[Ole Streicher]

Jonas Smedegaard  writes:
> Quoting Ole Streicher (2022-08-27 16:22:27)
>> Helmut Grohne  writes:
>> > The essence of my argument was that the dependency tree has become
>> > irrelevant. Since britney does not look into Recommends and the
>> > dependency tree has become a recommendation tree, there aren't actually
>> > that many dependencies left. It's a fairly simple tree now (when
>> > disregarding recommends).
>> 
>> I think this contradicts Debian Policy 2.2.1:
>> 
>> | In addition, the packages in main
>> | 
>> | * must not require or recommend a package outside of main for
>> |   compilation or execution [...]
>
> I thought so in the past as well, but was corrected (sorry, long ago,
> cannot point to a reference): Packages that does not exist at all (in
> any section of the Debian archive for the same release of Debian) is not
> "outside" and therefore not what that passage refers to.

As said in my other mail: If this is the common understanding, then we
really should re-think our blends package framework and remove the
debian/control.stub stuff. We can also just make the final metapackage
relase after the freeze stops NEW processing.

Cheers

Ole

Re: Bug#1018146: correct multiarch for blends stuff?

[Ole Streicher]

Petter Reinholdtsen  writes:
> [Ole Streicher]
>> I think this contradicts Debian Policy 2.2.1:
>
> Which relation did you have in mind that lead you to this idea?
>
> I thought we were discussing metapackages depending on packages in main,
> in unstable, which fail to build on one or more architectures.

I think the interpretation was that for a given Debian release, all
(primary) Recommends must be resolved in main. That's why we usually
wait for the last moment to upload the final version of a Blends
metapackage, and that's why the build process explicitly takes the
"testing" (i.e. proposed next stable) version and not the "unstable" one
to generate the Recommends. And since the current "testing" package list
is not locally available during build, the Blends package needs to create
them before upload (resulting in a complicated build procedure, using
a template for d/control).

If our policy should be interpreted as "package can be somewhere in
main, not necessarily in the Debian release", then we can greatly
simplify the way Blends are handled, by computing the Recommends list at
build time. Then, one would in principle just need a no-change reupload
(or a BinNMU) after the soft freeze.

While I doubt that the sloppy interpretation is correct, I would also
like to have this clarified (and then implemented) in the lazy way.

Cheers

Ole

Re: Bug#1018146: correct multiarch for blends stuff?

[Ole Streicher]

Helmut Grohne  writes:
> The essence of my argument was that the dependency tree has become
> irrelevant. Since britney does not look into Recommends and the
> dependency tree has become a recommendation tree, there aren't actually
> that many dependencies left. It's a fairly simple tree now (when
> disregarding recommends).

I think this contradicts Debian Policy 2.2.1:

| In addition, the packages in main
| 
| * must not require or recommend a package outside of main for
|   compilation or execution [...]

Cheers

Ole

Re: Python3 port for Blends tasks pages [Was: Python 3 transition: please prepare your service and its dependencies]

[Ole Streicher]

Hi Andreas,

as far as I recall fro the old mails, it should work with Python 3.
However we didn't switch since we didn't want to mix it with the move
towards UDD.

Could you just try to run the scripts manually and forward the
errors/problems you got? IMO all the encoding problems were solved.

Cheers

Ole


On 16.11.19 11:19, Andreas Tille wrote:
> Hi Ole,
>
> do you remember why we did not yet activated Python3 in the tasks pages?
> I just did not touched it a long time - but we somehow stick to Python2
> and did not yet activated your Python3 enabled code.
>
> Kind regards
>
>Andreas.
>
> PS: On my local machine the encoding issues remain for Python2 and
> Python3. :-(
>
> - Forwarded message from Paul Wise  -
>
> Date: Mon, 28 Oct 2019 09:06:17 +0800
> From: Paul Wise 
> To: debian-services-admin 
> Subject: Python 3 transition: please prepare your service and its dependencies
>
> Hi all
>
> The removal of Python 2 is planned for Debian bullseye and a number of 
> python-* module packages have been removed already. Please ensure that
> the debian.org meta-package for your service will be installable on
> systems without Python 2 and that your service will work on Python 3
> based systems. Since Python 3 and many modules for it are available in
> Debian buster already you can start migrating your service to Python 3
> early. Please send patches for updates to your service's dependencies
> once you have ported your service code to Python 3 or if you would like
> your Python 3 dependencies available for testing your porting.
>
> https://salsa.debian.org/dsa-team/mirror/debian.org
>
> Here is the list of service updates that will need to be dealt with.
> There may be more issues due to other things needing Python 2.
> Since the list of affected services is long I haven't BCCed anyone.
>
> bugs.debian.org
>python-pyinotify python-yaml
>
> buildd.debian.org
>python-apt python-contract python-coverage python-debian
>python-psycopg2 python-mako python-nose python-sqlalchemy
>
> planet.debian.org
>python python-django
>
> security-tracker.debian.org
>python-apsw python-apt python-soappy
>
> ftpmaster.debian.org
>python python-apt python-debianbts python-debian python-ldap
>python-psycopg2 python-pygresql python-pyrss2gen python-yaml
>python-rrdtool python-sqlalchemy python-tabulate python-epydoc
>python-numpy python-soappy python-magic python-mode pychecker pylint
>
> upload.debian.org
>python python-apt python-debian python-psycopg2 python-sqlalchemy
>python-rrdtool
>
> release.debian.org
>python2.7 python2.7-dev python-dev python-pygresql python-libxslt1
>python-apt python-debian python-six python-networkx
>python-pygraphviz python-yaml
>
> nm.debian.org
>python python-mako python-ldap python-apt python-beautifulsoup
>python-debianbts python-dns python-dnspython
>python-egenix-mxdatetime python-egenix-mxtools python-flup
>python-libxml2 python-lxml python-psycopg2 python-soappy
>python-xapian python-dateutil python-debian python-django
>python-django-south python-debiancontributors python-tz
>python-markdown python-lzma python-requests
>python-djangorestframework
>
> qa.debian.org
>python-apt python-psycopg2
>
> packages.qa.debian.org
>python python-lxml python-soappy python-debian python-yaml
>python-zsi
>
> udd.debian.org
>python-dateutilpython-debian python-dev python-launchpadlib
>python-psycopg2 python-yaml
>
> snapshot.debian.org
>python-yaml python-psycopg2 python-lockfile python-fuse python-dev
>python-pylons
>
> debtags.debian.org
>python-apt python-debian python-django python-xapian python-psycopg2 
>python-debiancontributors python-six
>
> ddtp.debian.org
>python-setuptools python-psycopg2 python-django python-sqlalchemy
>
> piuparts.debian.org
>python-debianbts python-rpy2 python-apt python-distro-info
>python-lzma python-yaml python-debian python-apt python-distro-info
>
> wiki.debian.org
>python-moinmoin python-launchpadlib python-docutils
>
> bits.debian.org
>python-feedparser
>
> wnpp-by-tags.debian.net
>python-debian python-beautifulsoup
>
> blends.debian.org
>python-genshi python-markdown python-docutils python-debian
>python-psutil python-psycopg2 python-apt
>
> dns.debian.org
>python-dnspython python-pycryptodome python-yaml
>
> ftpmaster.debian-ports.org
>python python-debian
>
> sources.debian.org
>python-apt python-debian python-flask python-flaskext.wtf
>python-flup python-magic python-lzma python-matplotlib
>python-psycopg2 python-sqlalchemy
>
> btslinks.debian.org
>python python-bs4 python-debianbts python-lxml python-ldap
>python-rrdtool python-soappy python-yaml
>

Re: Reorganisation of www.debian.org: Please provide information about your Blend

[Ole Streicher]

Hi Thomas,

this is to  confirm that we want to keep listed on the blends web site.

Cheers

Ole

On 22.07.19 03:48, Andreas Tille wrote:
> Hi Blends developers
> 
> today I sat together with some people who intend to update Debian web
> pages.  On one hand they care about design they also care about content
> and structure of content.  The structure should be unified and the
> content should be updated by not only provide up to date information but
> also by deleting stuff that is irrelevant.
> 
> It turned out that for some Blends the information is recent and well
> maintained, some Blends care not much about their documentation but are
> active otherwise (shame on me that I consider Debian Med in this
> category) and some Blends were either never really active or are not
> active any more.  The people who are working on new web pages want to
> provide current information and thus want remove the last category
> which I will refer to as "inactive" below.  (If you are actually
> consider yourself inactive or do not know what I'm writing about you
> could stop reading here in principle since any response is only
> expected from active Blends.)
> 
> To find out what Blend should be considered as active I proposed to
> write this e-mail to the main communication channel and ask the
> developers of the Blend to confirm they consider themselves an active
> Blend and will provide more content about that Blend to the web team if
> requested to do so.
> 
> This mail goes to the mailing list of all those Blends that are listed
> under
> 
> http://www.debian.org/blends [1]
> 
> as well as those projects that are featuring metapackage code in Git
> and have a mailing list or only a private mail address since no
> mailing list existed or the mailing list vanished by the shutdown
> of alioth since nobody cared about the migration (if those single
> maintainers do not know what this mail is about they certainly fall
> under the category "inactive" and do not need respond anyway.)
> 
> So please every Blend team that wants to be listed on [1]
> in future please write an e-mail to
> 
> Thomas Lange 
> 
> confirming that this Blend is active and wants to be represented
> on the official Debian Web site.  We actually want to unify the
> presentation of Blends and you should name a default entry page
> for your Blend.  Currently we have some very positive examples
> like
> 
> Debian Astro:   https://blends.debian.org/astro/
> Debian Edu: https://blends.debian.org/edu/
> 
> We also have the "care not so much about documentation ones"
> 
> Debian Med: https://blends.debian.org/med/
> Debian Games:   https://blends.debian.org/games/
> or even worse
> Debian Junior:  https://blends.debian.org/junior/
> 
> ones and those who simply maintain just a Wiki page.  Once you confirmed
> that your Blend is active you should probably start working on this -
> possibly by discussing some common standard for the Blends entry page on
> the general Blends list (debian-blends@lists.debian.org)
> 

Re: Debian Med Homepage - maybe all blends as "blendname".debian.net ?

[Ole Streicher]

Paul Wise  writes:
>> I'd vote for blendname.debian.org.
>
> This would mean an RT ticket for DSA for every new blend, I'd like to
> avoid that so I would echo Ole's proposal of blends.d.o/med.

Well, new blends don't pop up very often.

Cheers

Ole

Re: Debian Med Homepage - maybe all blends as "blendname".debian.net ?

[Ole Streicher]

Andreas Tille  writes:
> On Thu, Mar 14, 2019 at 02:42:18PM +0100, Steffen Möller wrote:
>> How do you all feel about having a home page for the Debian Med project
>> at an even simpler URL? We have https://www.debian.org/devel/debian-med/
>> which is really easy to remember [01189998819991197253] but when putting
>> this anywhere publicly this has the chance to just raise some questions
>> like ... why?
>> 
>> I propose to give all blends a blendname.debian.net address. Would that
>> be reasonable? med.debian.net for us, I  mean. I personally also prefer
>> the .net as being more inviting to the derivative distributions of Debian.
>
> I'd vote for blendname.debian.org.  There is no point in beeing "inviting"
> since derivative also can not register a debian.net address.

Currently, there is already https://blends.debian.org/, which
is what we also propagate for Debian Astro. Although astro.debian.org
sounds a bit nicer, I see no real urgency for it.

Cheers

Ole

Next attempt to add Blends to Debian installer

[Ole Streicher]

Filippo Rusconi  writes:
> Also, when I installed debian-science and debichem last time, the process
> downloaded such an amount of software that it almost filled my disk (which I 
> was
> not suspecting). Maybe, a rough indication of the used disk space in front of
> each blend might be useful, in this respect.

I would not include debian-science to the blends listed in the
installer: it is more an umbrella to organize the packages then a useful
selection of software. The software selection is also inconsitent: it
only contains software that is not maintained by a more specialized
blend (like debichem).

So, there is probably no real use case to install Debian Science in its
current form (unless someone takes the work to kurate a "Generic Debian
Science Workstation" or so).

On our last attempt, we had an opt-in for the blends to be in the
installer; I would propose the same now as well.

Cheers

Ole

Re: Bug#903593: python3-blends: shouldn't write Packages: list in case the udeb option is set

[Ole Streicher]

Wolfgang Schweer  writes:
> Sure, but see above. I'm pretty sure once the Packages list has been 
> dropped, re-adding Recommends: tfptd-hpa | atftpd to tasks/main-server 
> would do no harm.

I am (also after reading tasksel's README) ready to drop the explicit
packages list. However, there was probably an (undocumented) reason why
it is there for udebs -- I just took this over from the Perl script, and
I guess that from the blends debian-edu is the main/only use of udebs.

I'll do that tomorrow, unless someone complains.

Cheers

Ole

Re: Bug#903593: python3-blends: shouldn't write Packages: list in case the udeb option is set

[Ole Streicher]

Wolfgang Schweer  writes:
> On Thu, Jul 12, 2018 at 08:45:46AM +0200, Ole Streicher wrote:
>> Wolfgang Schweer  writes:
>> > Generated with blends-dev 0.7.1 the list contains tftpd-hpa as well. As 
>> > both packages conflict, the installation breaks, see:
>> > https://ci.debian.net/data/autopkgtest/testing/amd64/d/debian-edu/591122/log.gz
>> 
>> This also may be a bug in the handling of the "Packages" field during
>> udeb installation, which was just not exposed until now.
>  
> I guess the only problem has been that both conflicting alternatives 
> showed up in the 'Packages: list'.
> With atftpd removed from tasks/main-server, things are ok again, see:
> https://ci.debian.net/packages/d/debian-edu/testing/amd64/
>
> This removal has been the only change between versions 2.30 and 2.31, 
> see: https://salsa.debian.org/debian-edu/debian-edu/commits/master

Are you sure that this is not a bug in the Debian Edu environment? As
far as I looked into, the test calles

/usr/share/debian-edu-config/tools/debian-edu-bless

and this script seems to be unable to handle alternatives.

IMO it would not be a good solution to just limit the packages to the
first alternative, since that would break the idea of alternatives.

Cheers

Ole

Re: Bug#903593: python3-blends: shouldn't write Packages: list in case the udeb option is set

[Ole Streicher]

Wolfgang Schweer  writes:
> On Wed, Jul 11, 2018 at 09:41:05PM +0200, Ole Streicher wrote:
>> However, I am not sure about the required format to udeb .desc files. As
>> you describe it, the situation is:
>> 
>> * the Package: field is not needed for udebs
>> * but if it is there and contains alternatives, the installation breaks.
>> 
>> Do I understand you correctly?
>
> Yes, if there are conflicting packages among the listed alternatives. 
> But please note that I am no expert.

OK, so I will wait a day for other comments. If nobody else complains, I
will merge your proposal and upload a new version.

> Generated with blends-dev 0.6.100, debian-edu-tasks.desc had the 
> 'Packages: list' with only one package of alternatives, the first one.
> Example: tasks/main-server with Recommends: atftpd | tftpd-hpa ended up 
> in debian-edu-tasks.desc with only atftpd listed below 'Packages: list'.
> Generated with blends-dev 0.7.1 the list contains tftpd-hpa as well. As 
> both packages conflict, the installation breaks, see:
> https://ci.debian.net/data/autopkgtest/testing/amd64/d/debian-edu/591122/log.gz
>  

This also may be a bug in the handling of the "Packages" field during
udeb installation, which was just not exposed until now.

Cheers

Ole

Bug#903593: python3-blends: shouldn't write Packages: list in case the udeb option is set

[Ole Streicher]

Ho Wolfgang,

On 11.07.2018 18:40, Wolfgang Schweer wrote:
> The Packages: list now contains all alternative packages instead of only 
> the first one, e.g. tftpd-hpa | atftpd lists both packages which breaks 
> installation. I guess the fix for #785678 caused this.
> 
> The Packages: field doesn't seem to be needed for a valid desc file.
> Please consider to think about the alternatives again or maybe apply 
> this change:

I would prefer to apply your change; mainly because it removes the
special handling of udebs in one place (and fewer special cases is
always better).

However, I am not sure about the required format to udeb .desc files. As
you describe it, the situation is:

* the Package: field is not needed for udebs
* but if it is there and contains alternatives, the installation breaks.

Do I understand you correctly?

Best

Ole

Re: Comments regarding blends_0.7.0_amd64.changes

[Ole Streicher]

Dear Chris,

On 11.06.2018 09:44, Chris Lamb wrote:
> You added python3-blends.  This package includes one small python
> library and some documentation.  Is there a reason this needs to be
> separate?  You already ship blends-dev, which is the only user for
> this new package, and blends-doc.
> 
> The changelog does not mention any reasoning, not exists a bug report
> requesting this.

There was already a short discussion about this with Torsten Alteholz
(ftp-master@d.o) and Bastian Blank (waldi) a month ago; see

https://lists.debian.org/debian-blends/2018/05/msg0.html

for the thread. The python3-blends package is a (first version of) a
Python package that may deal with Blends -- to be used by blends-dev,
but in future also to generate the Blends webpages (and maybe other
uses). Depending on our experiences and further development, it would be
a candidate to be included in python3-debian.

So the idea is to keep it separate and to follow the Python policy in
naming, directory layout etc. Making things modular is IMO a good thing.

Best regards

Ole

Re: Comments regarding blends_0.7.0_amd64.changes

[Ole Streicher]

Hi Torsten and waldi,

the python3-blends package is a (first version of) a Python package that
may deal with Blends -- to be used by blends-dev, but in future also to
generate the Blends webpages (and maybe other uses). Depending on our
experiences and further development, it would be a candidate to be
included in python3-debian.

So the idea is to keep it separate and to follow the Python policy in
naming, directory layout etc. Making things modular is IMO a good thing.

Best regards

Ole

On 02.05.2018 20:10, Thorsten Alteholz wrote:
> Hi Ole,
> 
> waldi looked at your package and wants to know:
>  You added python3-blends.  This package includes one small python library
>  and some documentation.  Is there a reason this needs to be separate?  
>  You already ship blends-dev, which is the only user for this new package, 
>  and blends-doc.
> 
>  The changelog does not mention any reasoning, not exists a bug report 
> requesting this.
> 
> 
> Thanks!
>  Thorsten
> 
> 

Re: How to deal with static web pages

[Ole Streicher]

Andreas Tille  writes:
> The general question is:  Do we want to stick to the jekyll method?  If
> yes - and I think that's some interesting option - Debian Astro should
> make sure that their pages will be created using this option.  If no
> (which is fine for me as well) we should rather remove the according
> doc to prevent that somebody will fire up jekyll and mess up things.

I have no experience with Jekyll: Can it programmatically generate pages
from templates (with Python)? If yes, we could even think of moving the
blends-tasks pages there. The current system uses genshi, which is at
least unusual. And since I think to rewrite the non-static pages anyway,
this would be a good chance to switch.

It not, I could probably replace the generated part of the Debian-Astro
web pages by something static (they did anyway not change as much as I
expected -- to be specific: they didn't change at all). I would however
still like the idea of having a landing page that has some actual
information on it (number of packages, number of bugs, latest uploads or
similar).

Cheers

Ole

Re: Processing of blends_0.7.0_amd64.changes

[Ole Streicher]

Wolfgang Schweer  writes:
> On Fri, Apr 13, 2018 at 07:01:43PM +, Debian FTP Masters wrote:
>> blends_0.7.0_amd64.changes uploaded successfully to localhost
>
> As far as I can tell, this blends-dev version seems to work out of the 
> box for Debian Edu.

That is great! Thanks for the report!

Cheers

Ole

Re: Non-normalised field Provides in UDD table

[Ole Streicher]

Andreas Tille  writes:
>> Note that in the moment, the GENCONTROL_OPTS need to be defined *after*
>> the blends-dev/Makefile inclusion, since the latter set it to be empty
>> (I'll change that in a moment, however).
>
> Noted from changelog...
>
> See my other remark about the removal of the command line option.

It is not removed. You can any option specify either by command line, or
by GENCONTROL_OPTS.

> I've checked that it works after the removal of "GENCONTROL_OPTS := ".

Great.

> So my last concern (which I also expressed in my answer to your commit)
> is that the --udd option now seems to have gone and I can not see in the
> log whether UDD is really used or not.  Since the output is quite blurry
> anyway I wonder whether some line in the very end saying something like
>
>"Creation of {tasksel|control) file was done using {apt cache|UDD}"

I'll print a short summary to stdout.

Cheers

Ole

Re: Non-normalised field Provides in UDD table

[Ole Streicher]

Hi Andreas,

Andreas Tille <andr...@an3as.eu> writes:
> On Fri, Apr 13, 2018 at 09:35:39AM +0200, Ole Streicher wrote:
>> Andreas Tille <andr...@an3as.eu> writes:
>> > On Thu, Apr 12, 2018 at 09:22:35PM +0200, Ole Streicher wrote:
>> > H,
>> > but no --udd option for the /usr/share/blends-dev/blend-gen-control
>> > call.  How are you triggering the UDD option at your side?
>> 
>> Inside of blend-gen-control, see
>> https://salsa.debian.org/blends-team/blends/commit/dc6f7bc9.patch :
>> 
>> if 'GENCONTROL_OPTS' in os.environ:
>> opts = parser.parse_args(os.environ['GENCONTROL_OPTS'].split())
>> parser.set_defaults(**opts.__dict__)
>
> I've read this - but how did you actually *used* this setting.
> What are you doing on your side to trigger the UDD option?

I just added it to my Makefile and it works. Complete astro/Makefile:

```
#!/usr/bin/make -f

BLENDMAKEFILE=/usr/share/blends-dev/Makefile

CheckBLENDMakefile := $(shell if [ -e $(BLENDMAKEFILE) ] ; then echo 1 ; else 
echo 0 ; fi)
ifeq ($(CheckBLENDMakefile),1)
include $(BLENDMAKEFILE)
else
err := $(shell echo "$(BLENDMAKEFILE) is missing.  Please install 
blends-dev package!")
endif

export GENCONTROL_OPTS := --udd

dummy:
@echo $(err)
```

Note that in the moment, the GENCONTROL_OPTS need to be defined *after*
the blends-dev/Makefile inclusion, since the latter set it to be empty
(I'll change that in a moment, however).
> Well, also apt cache is a moving target.  So if we do not talk about
> reproducible test conditions and just want to debug the libodil0-dev
> issue in a defined time frame, the debug task can be helpful.

Yes; I finally did a minimal blend with one task containing just that
one dependency.

> In summary: I'm fine with a 0.7.0 release to unstable if there is a
> documented way to turn on the UDD option.  (I'm obviously to stupid and
> always need to trigger it manually. :-( )

Check if the thing above works.

Cheers

Ole

Re: Non-normalised field Provides in UDD table

[Ole Streicher]

Andreas Tille <andr...@an3as.eu> writes:
> On Thu, Apr 12, 2018 at 09:22:35PM +0200, Ole Streicher wrote:
> H,
> but no --udd option for the /usr/share/blends-dev/blend-gen-control
> call.  How are you triggering the UDD option at your side?

Inside of blend-gen-control, see
https://salsa.debian.org/blends-team/blends/commit/dc6f7bc9.patch :

if 'GENCONTROL_OPTS' in os.environ:
opts = parser.parse_args(os.environ['GENCONTROL_OPTS'].split())
parser.set_defaults(**opts.__dict__)

> I also need to admit that the issue with libodil0-dev remains:
> It is in Suggests when using --udd and in Recommends without
> UDD.

Harr, they trapped me in the backslash hell. But now I could escape
using even more backslashes. Can you re-check?

> BTW, I invented the debug[1] task to have short tasks featuring only the
> critical parts in the tasks.  I'd recommend to add libodil0-dev there
> and may be you add some logging feature with more verbose debug output.

Would probably be good. The problem is however the UDD content is a
moving target, and so that one provides may change over time.

Cheers

Ole

Re: Non-normalised field Provides in UDD table

[Ole Streicher]

Hi Andreas,

I extended the queries to allow multiple (and even versionized) provides.

Andreas Tille  writes:
>> > It has another really great feature.  It has the following warning
>> > output:
>> >
>> > WARNING:__main__:"filo" has been replaced with "bedtools"
>> 
>> Where does it get this from? Is this issued when "filo" is a "Provides"?
>
> Yes.  The package filo is missing and bedtools provides it.  That's a
> hint to fix the tasks file to not mention packages that are replaced.

 and replaces it, as seen from the other task. In principle, this
could be implemented in blend-gen-control (even independent of whether
APT or UDD is used); blends.py's uddcache would just need an extension
to return the "replaces" as well.

I would however leave this for future.

>> > WARNING:__main__: **Missing package python3-bd2k has the following
>> > existing versions:
>> > WARNING:__main__:python-bd2k
>> 
>> Similarly here: in which cases you issue this?
>
> I have not checked the code again (and lacking the time in the next
> hours).  But I once specified to the GSoC student that if the package
> name has a version number and that package name is not found to replace
> that number by '%' and seek for a match.  Here you see the result.  It
> usually happens with library packages if the ABI version is appended to
> the package name (even if tasks should not really specify library
> packages but rather the lib*-dev package but as we have seen in the
> libodil0-dev case sometimes these have versions as well).  The
> libodil0-dev package would have matched both tests (Provides and replace
> version number by %).

This is a bit more difficult; and I would leave this out of the normal
package.

Best

Ole

Re: Non-normalised field Provides in UDD table

[Ole Streicher]

Hi Andreas,

Andreas Tille <andr...@an3as.eu> writes:
> On Wed, Apr 11, 2018 at 10:02:39PM +0200, Ole Streicher wrote:
>> We had a short discussion in
>> 
>> https://lists.debian.org/debian-blends/2018/03/msg00059.html
>> 
>> and your answer. Do you mean something more?
>
> I mean we need different metapackages for say amd64, arm64, i386, etc.
> I agree that this is no solution for MultiArch but from my point of
> view that's rather a corner case.  However, our metapackages are
> currently simply broken for all architectures except amd64 and I'd
> love to get this fixed in Buster.
>
> As I said blends-gsoc had some solution for this: [...]
> 
> -Architecture: all
> +Architecture: any
>  Recommends: abacas,
> -abyss
> + abyss [!s390 !hurd-i386 !kfreebsd-amd64 !powerpc !sparc !ia64 
> !kfreebsd-i386],

That was what I meant: This problem is in no way specific for blends
tasks, but is general for "Architecture: all" packages: You always may
run into the problem that such a package has a recommendation (or even
dependency) that is not fullfillable on one or the other architecture.

Imagine f.e. when R would stop the support for 32-bit architectures.
That would mean that all R packages (which are "Arch: all") cannot be
installed on those architectures anymore, since the dependency cannot be
resolved there. Would you then consider to rewrite all R packages to be
"Arch: !i386 !powerpc ..."? And to maintain all of these dependencies in
all R packages just to be in sync with the platforms supported by R? IMO
that is out of question.

What is the difference to a blends task med-bio with Arch: all and
recommending a package that does not exist on s390x? What do we gain
except getting MultiArch problems?

> It has another really great feature.  It has the following warning
> output:
>
> WARNING:__main__:"filo" has been replaced with "bedtools"

Where does it get this from? Is this issued when "filo" is a "Provides"?

> WARNING:__main__: **Missing package python3-bd2k has the following existing 
> versions:
> WARNING:__main__:python-bd2k

Similarly here: in which cases you issue this?

Best regards

Ole

Re: Non-normalised field Provides in UDD table

[Ole Streicher]

Andreas Tille  writes:
>> Huh! That is ugly! Who made this???
>
> Probably the person who had the intention to add control file
> information verbosely to a database table.  I had discussed things like
> this years ago (debian...@lists.debian.org with [UDD] in subject is the
> right place to discuss this).  You could even argue that someonw is
> interested in the sequence of the dependencies (not that I personally
> would like this argument).  I was told UDD was *never* intended to be a
> normalised database and you always find arguments pro and contra
> normalisation.

>From your experience: do you think there are chances to get an
additional table with normalized dependencies?

Queries like for reverse dependencies or reverse suggestions seem quite
normal to me. Especially when it is called "Ultimate" :-)

>> But solving this on client side sounds like an ugly hack to me.
>
> Yes.  Didn't I told you that server side queries tend to be complex?
>
> The good thing about PostgreSQL is that it has really nice features.
> I'm using arrays to solve this.  To get the authoritative answer you
> were seeking above just do:

I would probably prefer to use a (temporary) view here, since it could
then work as if the database was normalized. But I have to learn more
Postgresql first... And the performance problem persists ofcourse.

> PS:  The main reason to use UDD was the "Architecture: any" feature.  As
> far as I can see that's not implemented yet and left for a future
> release.  That's perfectly fine since the current implementation is even
> now better than the old Perl script.  I just want to make sure that I
> have tested all new features.

We had a short discussion in

https://lists.debian.org/debian-blends/2018/03/msg00059.html

and your answer. Do you mean something more?

Best regards

Ole

P.S. please excuse the harsh tone of my last mail, that was not really
intended.

Re: New feature for 0.6.103

[Ole Streicher]

Hallo Andreas,

Andreas Tille  writes:
> It seems the usage of GENCONTROL_OPTS in Makefile does not work yet.  I
> did [...]

> +GENCONTROL_OPTS = --udd

IMO there is an export missing. Otherwise GENCONTROL_OPTS is only local.
You could try

$ GENCONTROL_OPTS="--udd" /usr/share/blends-dev/blend-gen-control  -r 
"unstable" -S -t

to check whether it retrieves from UDD then; for me it works.

>   SELECT packages.package, packages.provides, packages.architecture, 
> packages.version FROM packages WHERE  packages.provides like 'libodil%' ;
>
> is just empty, but you get:
>
> udd=# SELECT DISTINCT packages.package, packages.provides, packages.version 
> FROM packages WHERE  packages.provides like '%libodil%' ;
>package|   provides| version 
> --+---+-
>  libodil0-dev | libdcmtkpp-dev, libodil-dev   | 0.7.3-1
>  libodil-dev  | libdcmtkpp-dev, libodil0-dev  | 0.8.0-4
>  libodil-dev  | libdcmtkpp-dev, libodil0-dev  | 0.9.1-1
>  libodil-doc  | libdcmtkpp0-doc, libodil0-doc | 0.8.0-4
>  libodil-doc  | libdcmtkpp0-doc, libodil0-doc | 0.9.1-1
> (5 Zeilen)
>
> This means you can not expect an exact match on the package name since
> provides can have a list of packages (which again proves my point that
> UDD queries become always more complex than expected. :-P)

Huh! That is ugly! Who made this??? At least this contradicts to
everything I learned about databases: if there may be more than one
provides for a package, there should be an extra table for this
relation. Same for other dependencies (depends, recommends etc.).

How does one query for "give me all packages that provide (or depend on)
xyz"?

With "like", you basically need to retrieve and parse all "provides"
fields that are in the database with no chance to index it... and this
has to be done for all O(1000) packages of Debian Science. Sounds really
slow, especially when you want to get an authorative answer (your
example would also find f.e. a package calibodil-dev, if that would
exist).

IMO the clean solution would be to have a "package-dependencies" table
with the columns package, type, dependencies (or one table for each
dependency type), if that does not exist yet (I must admit that I may
have not searched carefully enough yet). But solving this on client side
sounds like an ugly hack to me.

Or do I miss something here?

> Unfortunately I need to finish now an will not be back on my keyboard
> in the next 5 hours - otherwise I'd provide a patch for your query.

Best regards

Ole

Re: New feature for 0.6.103

[Ole Streicher]

Hi Andreas,

Andreas Tille  writes:
> BTW, what do you think about the usage of blends_dependencies instead
> of creating a set of packages by other means?

Seems useful for the web pages, but not for blends-dev: to generate the
list of packages for a specific blend, the current (maybe uncommitted)
tasks should be used, not the ones that are provided by the database.

Best

Ole

Re: New feature for 0.6.103

[Ole Streicher]

Andreas Tille <andr...@an3as.eu> writes:
> On Tue, Apr 10, 2018 at 09:18:15PM +0200, Ole Streicher wrote:
>> Andreas Tille <andr...@an3as.eu> writes:
>> > I'm aware of this difference and I tried both releases testing and
>> > unstable.  Both show differences to the apt cache approach I have no
>> > explanation for.  Does my test work for you in Debian Astro?
>> 
>> The UDD has now the problem with files being in non-free + contrib,
>> will adjust that.
>
> I have spotted at least two packages from non-free in the said diff  so
> that seems to be at least part of the problem.

With that change, I didn't see a difference between udd and apt. I also
pushed now the adjustments unstable->testing and UNRELEASED->unstable in
the blends-dev Makefile.

> (Did I said in my other mail that the UDD queries tend to get complex?
> ;-) )

I'd still not count this as complex...

Cheers

Ole

Re: New feature for 0.6.103

[Ole Streicher]

Andreas Tille  writes:
> I'm not sure about the UDD usage.  I've manually used 
>
>   /usr/share/blends-dev/blend-gen-control --udd -r UNRELEASED -S -t
>
> but it seems its not doing anything. 

There are no double-checks in the moment. The release is directly
queried from the "release" database, so "UNRELEASED" will return an
empty list (and therefore downgrade all packages). I however don't
understand what this is for? Is it a hardcoded equivalent to unstable?

> I also assumed that I do not need
> to do anything manually but could do something like

> +GENCONTROL_OPTS = --udd

> But this does not have any effect.  Am I missing something?

It still does not check the environment. Will do...

Cheers

Ole

Re: New feature for 0.6.103

[Ole Streicher]

Hi Andreas and all,

Andreas Tille  writes:
> I think we should stick to the well tested UDD queries.  It was quite
> some work to write these.  The only change I have in mind is to restrict
> the version query to unstable, testing, stable, oldstable and
> exprimental (currently it returns everything in UDD).  May be we should
> also return only one version per release (sometimes kfreebsd or hurd
> is lagging behind and we have several entries for sid).

I must confess that I find them by far too complicated and hard to
maintain, but this is another Baustelle yet.

>> So, I will now add a "python3-blends" package, which however needs then
>> to go though NEW... If then everyone is happy, we can move back to
>> unstable.
>
> Fine for me.

I pushed the changes for the split. You can now also to a "from blends
import Deb822List" as long as it is not merged into the python-debian
package. 

The python3-blends package also contains the HTML documentation.

Could you have a look before I upload? I would otherwise upload
tomorrow.

Cheers

Ole

Re: New feature for 0.6.103

[Ole Streicher]

Andreas Tille <andr...@an3as.eu> writes:
> On Tue, Apr 10, 2018 at 11:30:07AM +0200, Ole Streicher wrote:
>> > $ git clone https://ole.ath.cx/blends/
>> > Klone nach 'blends' ...
>> > fatal: repository 'https://ole.ath.cx/blends/' not found
>> 
>> My wording was easy to misunderstand. I mean:
>> 
>> $ firefox https://ole.ath.cx/blends/
>> 
>> and then check what you read ;-)
>
> Ahhh- I admit I did this as well.  Please note that this page throws an
> error behind some proxy-firewall-whatever combination.  I needed to use
> my LTS-bound laptop to view the page.

They are just a static copy, so I don't know what could be wrong here.

> When the header does not contain a line
> Format: https://blends.debian.org/blends/1.1
> then the priorities will be lowered when read:
>   □ Recommends –> Suggests
>   □ Depends –> Recommends
>
> May be this is not yet adapted to what I wrote before but this is not
> correct.

I forgot to change the docs here. Fixed in the repo.

>> > I admit this json is of different nature and could be used in connection
>> > with any different method to obtain the Git-based data.  I'm just
>> > afraid about changing something that is *really* rarely used and simply
>> > works just for the reason to make it more elegant.
>> 
>> Sure. I am however not sure whether this is true for generating the
>> changelog entry. Maybe I just add this to blends-gen-control.
>
> May be its a compromise to do the changelog generation based on the
> Git tags.  Probably it would not be a big issue to either hide the
> json files in a separate branch - or may be only exclude these from
> the generation of the source tarball.

Why should one do this? Additional files for local purposes can always
be in the sources.

>> BTW, are you happy with the UDD support? Or do you think we need more
>> here?
>
> I admit I do not fully understand what you mean by "initial package
> list".

I don't want to query all packages, but only those which are in the
blend. Therefore, one needs to give this list, which is then used as
input.

I however meant the blends-gen-control utility itself, not the package.

>  Please note that for the web pages I've crafted quite complex
> queries which gather way more data than will fit into an ordinary
> apt.Cache.  So if the paragraph
>
>blends.uddcache(release, packages, **db_args)¶
>
> is just for the metapackage creation and if it ends up in arch dependant
> metapackages I'm perfectly happy.  But I can not really tell whether we
> need more here from the information I have.

Yes, it is for the metapackage creation only in the moment, and it
contains the versions for all archs (but only for the selected release).

For the web page, this needs probably to be extended to return the
packages for all (or a list of) Debian releases.

Also, for the web page this is however only what we (probably) need to
gather from the "packages" table. One would (in a similar manner) need
to select from popcon etc. And probably you want to create the Blends
infrastructure itself ("Blend", "Task" objects) from UDD instead of from
the files.

So, there is clearly some work for the web pages; the main idea in
blends-dev is to create some common infrastructure so that blends
related stuff does not need to be developed from scratch again.

So, I will now add a "python3-blends" package, which however needs then
to go though NEW... If then everyone is happy, we can move back to
unstable.

Cheers

Ole

Re: New feature for 0.6.103

[Ole Streicher]

Andreas Tille <andr...@an3as.eu> writes:
> On Tue, Apr 10, 2018 at 10:10:39AM +0200, Ole Streicher wrote:
>> >> If you like, I could try that as next step; then I would however just
>> >> create a "python3-blends" package (to not interfer with the
>> >> python3-debian package).
>> >
>> > May be a python3-blends package assembling (and documenting!) that kind
>> > of tools (and put them on a solid technical base rather than hackish
>> > scripts) would make sense.
>> 
>> That is the main idea of the rewrite.
>> 
>> Check out https://ole.ath.cx/blends/ which is generated from the
>> blends-gen-dev source. Does it fit your needs in terms of functionality
>> and documentation?
>
> $ git clone https://ole.ath.cx/blends/
> Klone nach 'blends' ...
> fatal: repository 'https://ole.ath.cx/blends/' not found

My wording was easy to misunderstand. I mean:

$ firefox https://ole.ath.cx/blends/

and then check what you read ;-)

>> > But I think, sticking to the approach to store the dependency data in
>> > some sensible way (not necessarily inside the source package) is
>> > reasonable if you want to look quickly at historic data.
>> 
>> We already have git, so creating a function that returns a
>> `blends.Blend` object based on some git tag (rep. Debian version) is
>> straightforward with `git worktree` and also (since the blends source
>> packages are rather small) quick. And has the advantage that you don't
>> need to maintain an additional json file. You can just generate it on
>> the fly ;-)
>
> I confirm that I understood that it is possible to do this.  However, I
> can not imagine that whatever kind of diff between tags will be used
> this is faster than just reading a json file.

It is not faster; it is probably just not much slower.

> In addition I would need to "fake commit" pre-version control data
> into Git (yes, there were releases of Debian Med before I started
> using SVN).  These are now simply stored in json that's aggregating
> the data I want to display[1].

That is ofcourse a good argument, and also maybe the blends class cannot
read all the really old data.

> I admit this json is of different nature and could be used in connection
> with any different method to obtain the Git-based data.  I'm just
> afraid about changing something that is *really* rarely used and simply
> works just for the reason to make it more elegant.

Sure. I am however not sure whether this is true for generating the
changelog entry. Maybe I just add this to blends-gen-control.

BTW, are you happy with the UDD support? Or do you think we need more
here?

Cheers

Ole

Re: New feature for 0.6.103

[Ole Streicher]

Andreas Tille  writes:
>> However, tasks_diff may also benefit from a blends
>> Python package, and it could make the handling much easier (no json), as
>> if the blends package is in git with a standard tagging:
>> 
>> * git worktree could check out the latest debian/ tag to some
>>   temporary dir
>> 
>> * one can create a blends.Blend object from that dir
>> 
>> * one can create a blends.Blend object from the actual dir
>> 
>> * compare them, write out, and you are done.
>
> That's surely an option for the changelog creation.  But the json files
> also enable creating statistics[1] using this script[2].  Its just a
> hack and not documented (if I only had the time to do this) but just
> parsing a set of json files is probably way more sensible than to do
> your algorithm over and over again for all available tags.

Another reason to create a separare python3-blends package... that
script should be convertible to use it.

>> If you like, I could try that as next step; then I would however just
>> create a "python3-blends" package (to not interfer with the
>> python3-debian package).
>
> May be a python3-blends package assembling (and documenting!) that kind
> of tools (and put them on a solid technical base rather than hackish
> scripts) would make sense.

That is the main idea of the rewrite.

Check out https://ole.ath.cx/blends/ which is generated from the
blends-gen-dev source. Does it fit your needs in terms of functionality
and documentation?

> But I think, sticking to the approach to store the dependency data in
> some sensible way (not necessarily inside the source package) is
> reasonable if you want to look quickly at historic data.

We already have git, so creating a function that returns a
`blends.Blend` object based on some git tag (rep. Debian version) is
straightforward with `git worktree` and also (since the blends source
packages are rather small) quick. And has the advantage that you don't
need to maintain an additional json file. You can just generate it on
the fly ;-)

Cheers

Ole

Re: New feature for 0.6.103

[Ole Streicher]

Hi all,

since there seem to be no problems with the current 0.6.103 release, I
would rename it to 0.7.0 and upload to unstable. Any doubts?

What I did not yet do is to reparate a "[debian.]blends" Python 3
package from it -- this should be done only after inspection/re-doing of
the web page, to ensure it is really usable there.

Cheers

Ole

Accepted blends 0.6.103 (source) into experimental

[Ole Streicher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 29 Mar 2018 21:33:29 +0200
Source: blends
Binary: blends-dev blends-common blends-doc blends-tasks
Architecture: source
Version: 0.6.103
Distribution: experimental
Urgency: low
Maintainer: Debian Pure Blend Team <debian-blends@lists.debian.org>
Changed-By: Ole Streicher <oleb...@debian.org>
Description:
 blends-common - Debian Pure Blends common package
 blends-dev - Debian Pure Blends common files for developing metapackages
 blends-doc - Debian Pure Blends documentation
 blends-tasks - Debian Pure Blends tasks for new installations
Changes:
 blends (0.6.103) experimental; urgency=low
 .
   [ Andreas Tille ]
   * d/control:
  - Build-Depends: dh-python, python3-all
  - blends-dev: Depends: ${python3:Depends}
   * d/rules: --with python3
   * ignore false lintian warning binary-package-depends-on-toolchain-package
   * cme fix dpkg-control
   * Take over tasks_diff from blends-gsoc to create dependency_data
   * Use Deb822List to evaluate taskprefix in tasks_diff
 .
   [ Ole Streicher ]
   * Add UDD query options to blend-gen-control
Checksums-Sha1:
 143bbf6dcd3217229550f9db1d046f45b7abd15c 1949 blends_0.6.103.dsc
 6df5619189641dc4bb67b024d9beca730ccabdaa 106332 blends_0.6.103.tar.xz
Checksums-Sha256:
 2ac2b33468b87e1f06c73722687c89a6d94a330ddc64ffce679bccf38d64fdca 1949 
blends_0.6.103.dsc
 067426016af74daa43035f9dffb6261bad6ec69cf130329e0d15da33d4e5cac2 106332 
blends_0.6.103.tar.xz
Files:
 b7a26f71ef6fc9c5ccd80f21273c4786 1949 devel optional blends_0.6.103.dsc
 632771075af2b8b68fa74c15a915e32a 106332 devel optional blends_0.6.103.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE7/BpV0Ra2/h0L3qtmk9WvbkOGL0FAlq9Q84ACgkQmk9WvbkO
GL1Vaw/7BlFNa76Vw+Prs8pcaPEGWpgW7uAZjR1Xi6u4Xy0ZYNn+ueIld2aWdeYO
Xq+NVNyWEoR5ePmSZ48Xd63byFWQ4VCNeJzECExTtaTA+YJBb2MSYTfMCgNJnkjK
F9S5staOycRohfvzs8Z4YxdDbFlqoEETOdLdL0AWBr8mWWHRtO+7Vn2rrcJwKxJv
eyhmq0OWeXTuv5qAVsL/CSImSeIl6mPvKnN4Ov6AHPoCJzbSCGHtK+IUyME/+p/W
7/KVQgLub2ZW3Mkfsw9ZFgmiu9SeknchIQsXydwpQSsvKPaXWyBCUXlWz6nzVjnc
L3FkR/VInFxChnQr1YagE1Mh/0pp1NIyhfD9JznxWxF0yjjeU8Z7j1ol0a1STebH
HS2T/PbeF+qQtAIxGGhy9ld9JK8HCIz2uPAoOm2xVk86UWQ/mpNa+0ace3eKIVJc
DvnB1GSv2TWeJ4PkeoiPJgsm/L69hJDHY3OqQEXI8yfvAqBFPuG9Dw6OLUOAP2IT
StyMvEROUN/0F8M/7hGCKRjrb2U1tHwoBKVYcnQqNOIp2UhAGLwS0SlQ1eOPdalT
yaa+6ReueY12GkQlXiW37unityZIii4jCQo/64wc2FI82c/9Fzcwv5w8hG52DHfK
fO7LvMg8t2zZZsZaQuoIUf5T06ypnYqBYbRSWYmkJ/A6Dy7a+lk=
=IkZX
-END PGP SIGNATURE-

blend-gen-control and UDD

[Ole Streicher]

Hi (especcialy Andreas),

I am going to implement UDD requests as an alternative to updating the
blends dependencies from apt. Major driver is your interest in having
architecture specific lists if required.

However, I feel that this does not solve the problem, since it is a more
general problem (or my understanding is just wrong): As far as I
understand is that a task "foo" may have a dependency ("Recommends")
"bar" that exists only on some architectures.

Currently, blend-gen-control just looks in amd64. When the package
exists there, it will be a "Recommends" in d/control:

Package: blend-foo
Architecture: all
Recommends: bar

When the package does not exist on amd64, it will go to "Suggests":

Package: blend-foo
Architecture: all
Suggests: bar

In case bar does not exist on f.e. amd64, you want instead to have
something like

Package: blend-foo
Architecture: any
Recommends: bar [!amd64]
Suggests: bar [amd64]

right? Note the "any" here -- "Architecture: all" package are not
allowed to have architecture restrictions (Policy 7.1).

IMO this has some essential drawbacks: First, it will not work nicely
when using multiple archs: Consider I have a package that I would like
to "Recommend" but it exists only for 32 bit. Then, (assuming that one
added i386 to the installed archs, and the MultiArch flags were properly
set) it should pull the recommended package automatically from the other
arch. In your approach however the foo is downgraded to Suggests and
will not be installed by default. Old science software may have its
difficulties with 64 bit; I have one of these packages in my longer-term
queue.

Second, the Blends approach is isolated; in principle this should be
applied to *every* package that Recommends a package possibly existing
only on selected archs. For example, a Python package that Recommends:
python3-pandas must in principle do the same (and therefore cannot be
Architecture: all anymore). And the maintainer would need to keep an eye
on this and update the Recommends any time the list of archs for these
packages change. Sounds like really a lot unnecessary work. But is the
consequence of interpreting the policy in your way.

I interpret the phrase in Policy 2.2.1

| In addition, the packages in main
|
| * must not require or recommend a package outside of main for
|   compilation or execution (thus, the package must not declare a
|   Pre-Depends, Depends, Recommends, Build-Depends, Build-Depends-Indep,
|   or Build-Depends-Arch relationship on a non-main package unless that
|   package is only listed as a non-default alternative for a package in
|   main),

not being architecture specific: A Recommends: needs to be in main, but
not necessarily on the same arch; thanks to MultiArch (whose approach
specifically was that one can solve dependencies across architectures).

Using UDD however has the advantage to be closer to this (and solve the
problem that a Recommends exists only of 32 bit). And it may be quicker
than downloading the whole package list.

Best regards

Ole

Re: New feature for 0.6.103

[Ole Streicher]

Andreas Tille  writes:
> This opened the need to use class Deb822List which is inside
> blend-gen-control.  You mentioned that you plan to provide a Python
> module for reusing such classes.  What is your plan to provide this
> module?  I did a very bloody hack for testing my method which I do not
> even want to commit but rather wait for your suggestion to proceed more
> cleanly.

I indeed would like to have most of blend-gen-control separated in a
"debian.blends" package, since it is re-usable for f.e. the web page.

Deb822List should really go to debian.deb822; I am however still not
happy about __init__(), since aside from being initialized with a list,
it should be initializable with a file. Once this is implemented (Merge
Requests are welcome :-) ), I will open a wishlist/patch bug for
python-debian.

Best regards

Ole

Re: Accepted blends 0.6.102 (source) into experimental

[Ole Streicher]

Andreas Tille  writes:
> When I run `make dist` the resulting med-all package has no long
> description any more.  It looks like this:

Found and fixed. Was an indentation problem (the long description was
not indended).

Cheers

Ole

Re: Accepted blends 0.6.102 (source) into experimental

[Ole Streicher]

Wolfgang Schweer  writes:
> Debian Edu has own sources.list.* files. These used to take precedence 
> over those with the same name found in /etc/blends/, but as far as I can 
> tell the related code seems to have gone since version 0.6.101; could 
> you please check it?

That is not implemented yet; I'll do it for the next release.

Thanks for the hint!

Ole

Accepted blends 0.6.102 (source) into experimental

[Ole Streicher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 28 Mar 2018 08:49:42 +0200
Source: blends
Binary: blends-dev blends-common blends-doc blends-tasks
Architecture: source
Version: 0.6.102
Distribution: experimental
Urgency: low
Maintainer: Debian Pure Blend Team <debian-blends@lists.debian.org>
Changed-By: Ole Streicher <oleb...@debian.org>
Description:
 blends-common - Debian Pure Blends common package
 blends-dev - Debian Pure Blends common files for developing metapackages
 blends-doc - Debian Pure Blends documentation
 blends-tasks - Debian Pure Blends tasks for new installations
Changes:
 blends (0.6.102) experimental; urgency=low
 .
   * blend-gen-control: Bugfixes, slight refactorization, documentation
  - Don't lower Recommends to Suggests in format 1.0
  - Fail on backslashes in dependency lists
Checksums-Sha1:
 cc4a14f26fa54d803cee46695a574a47ce5eae22 1930 blends_0.6.102.dsc
 fca44cc51723e206df005c72873f7abad154cff7 102720 blends_0.6.102.tar.xz
Checksums-Sha256:
 e315f7cbbef31564c0c33a808b44b2a0cf0e5780539825e6d86bb0a88c94bd47 1930 
blends_0.6.102.dsc
 0c0a11c209b5b0d6ccc39d1f61e1f8da4bbb86385a5cd551ce61189a50ff0619 102720 
blends_0.6.102.tar.xz
Files:
 0226b99a1bf228a24055e3fe589a4094 1930 devel optional blends_0.6.102.dsc
 ff5d9acf6f1ebc0fd536f897dba3d203 102720 devel optional blends_0.6.102.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE7/BpV0Ra2/h0L3qtmk9WvbkOGL0FAlq7PGYACgkQmk9WvbkO
GL0NyxAApGiGZzBzfSGi0QePkfHm11gSypc5jW/3K2SJbXtpEnrAVyTVQ/8Mu6kl
sbkOdPn3RbWxBEM7ct1ur7t3H0vyLikSXvcP7Pxdiy8wU4mOt9G8Bz1Sbu9kPNMA
voUjihbB29bBBxZPrcKduQxkHeoPBixcBevfkPL1NHM7A44IenvMIUdjx+4WjJph
aNnaX5EJLtrBUv/2Xx/EUta2GhRoro7lbQg569c2How3xE1ztx2v2QzRtwpFzfoz
lP/Tqrmgw4RU34B6ZdvGtwwAXtp4M03MLEsuhUz/jRHx7vbzJktHTrC8HdAGgPkt
xWl1BR9VA91g5JdwdUJXu1M+TkkDUTqgpWo3bpbxh7fLA1QU6OVT2TSdw9/8isXg
7YgzzdkfXuRkj6IOWAN9o8Z0SWA6RIzPqRx/v4pq6JDCTKynCyMRUOIf6fjS0DgS
eeXBkKJN79S6Qoe16sOFvyf3agzQjsU47GYc/ik6CYIS3z2+8iM/m195PBKeOkcJ
9THHvvvV8mK900fVo1kiV7SMUjqC9dhs5LpnmYDnbfkvUsVGES46d5kDeSTobd8Q
YfkDAuCG3rBv/89gtuCU1l1mvG9ED4HTla4SgbYqWyAg4Bzh1cjZPefRPTnIBosz
EnX9JhNgFVftNQRgCmmU811H+yXH/pdf3RLBmO2IgTHt28YdcTk=
=OJV8
-END PGP SIGNATURE-

Re: Accepted blends 0.6.101 (source) into experimental

[Ole Streicher]

Andreas Tille  writes:
>> >> for key, value in p.items():
>> >> if key == 'Recommends':   # This downgrades Recommends
>> >> key = 'Suggests'  # to Suggests
>> >  ... but only if the package is not available in the target
>> >  distribution.
>> 
>> The check for availability happens later (in the "fix_dependencies()" 
>> method).
>
> Fine but may be I understand your code wrong - Recommends should just
> stay recommends here and not changed to Suggests.

This is some misunderstanding: I have shown my *old* code, that
resulted in downgrading Recommends to Suggests for the 1.0 format. The
new code has these lines removed.

> In this case it might be probably more convenient if you just ping me
> once you pushed your release candidate to the official repository and
> give me 12 hours (hope that will be sufficient) for a quick check. 

Since it goes to experimental, I do not hesitate to just upload ;-)

Cheers

Ole

Re: Accepted blends 0.6.101 (source) into experimental

[Ole Streicher]

Andreas Tille <andr...@an3as.eu> writes:
> On Tue, Mar 27, 2018 at 09:43:04AM +0200, Ole Streicher wrote:
>> Andreas Tille <andr...@an3as.eu> writes:
>> >
>> > The usage of Recommends+Suggests was always permitted in 'classic'
>> > format.  The only difference between 1.0 and 1.1 is that in 1.1 it is
>> > permitted that Depends remain Depends while in 1.0 it was downgraded
>> > to Recommends in any case.
>> 
>> So, Recommends were never downgraded to Suggests, resp. Depends and
>> Recommends were synonyms?
>
> Yes.  Depends and Recommends were synonyms.  The old code made sure that
> no Depends will remain in the resulting control file.  May be the term
> "Format" is not very well choosen since the format of the tasks files
> can not really be distinguished.  Its rather the *interpretation* of the
> file that has changed.  In 1.1 it is permitted that a Depends remains
> (and thus Recommends need to be specified explicitly).

"Format" should refer to syntax *and* semantic. So if we do an
incompatible change in how things are interpreted, we should give a new
version number. 

And the old format allowed (at least factically) also to end lines with
a backslash, while the new format is in contrast strict Deb822.

> The only reason why I did a global s/Depends/Recommends/ in Debian Med
> is that it is now more explicit (the degraded Depends was confusing
> for some people).

You may now upgrade Debian Med tasks as well with the "-U" flag.

>> for key, value in p.items():
>> if key == 'Recommends':   # This downgrades Recommends
>> key = 'Suggests'  # to Suggests
>  ... but only if the package is not available in the target
>  distribution.

The check for availability happens later (in the "fix_dependencies()" method).

> I'll test as soon as possible.  I can even test a commit before
> uploading if you confirm that this is your target for an upload.

I do the development in my personal salsa project:

https://salsa.debian.org/olebole/python-debian-blends

You can take out "blends.py" there and use it as blend-gen-tasks. Take
care since some flags are changed, and the tool directly writes the
files instead of dumping to stdout.

Cheers

Ole

Re: Accepted blends 0.6.101 (source) into experimental

[Ole Streicher]

Andreas Tille  writes:
> The thing is: The Debian Med tasks files have 'classic' format but
> without specifying the Format line d/control remains empty.

It already uses Recommends+Suggests, which gets downgraded and since
then there are no Recommends anymore, the metapackages are not created.

This is avoided by the Format: line.

Cheers

Ole

Re: Accepted blends 0.6.101 (source) into experimental

[Ole Streicher]

Hi Andreas,

Andreas Tille  writes:
> Can you please try
>
> $ LC_ALL=C touch /var/lib/apt/lists/tmp
> touch: cannot touch '/var/lib/apt/lists/tmp': Permission denied

I get the same as you.

> I get: [...]
> Can't open file /var/lib/apt/lists/_tmp_autopkgtest.qDlH8X_binaries_Packages: 
> No such file or directory

Thank you for forwarding this. In the moment,  have no idea what the
problem is. Maybe you could set the environment var APT_CONFIG=/dev/null
before invoking Python to see if something weird is in your apt config?

> I admit that I'm able to run `make dist` successfully on a system
> running stretch.  I now understand what you mean by "removing the \ in
> tasks/cloud".  While I agree that the '\' is not part of the RFC822
> definition we obviously have tasks featuring these.  I'd prefer if
> the script would issue an error instead of creating broken d/control
> files.

Sure. Is on my todo list.

> Regarding the Format description field:  It seems I did not understand
> it completely since I assumed it is optional.  It seems that I
> definitely need to specify it if Recommends are used inside the tasks
> file.  Is this correct?

Yes. The idea is that any tools can autodetect the format of the tasks
files and this way handle format changes accurately.

So, if we have incompatible changes in the future, just update the
Format: line when you updated the format of the file. Default is the
'classic' format. I thought that (since #891188 affected only d-astro) I
was the only one actually using the non-downgrading version.

Cheers

Ole

Re: Accepted blends 0.6.101 (source) into experimental

[Ole Streicher]

Andreas Tille  writes:
> I've tested this but I get:
>
> /usr/share/blends-dev/blend-gen-control  -r UNRELEASED -S -t
> Can't open file /var/lib/apt/lists/_tmp_autopkgtest.qDlH8X_binaries_Packages: 
> No such file or directory
> I do not have permission to write to /var/lib/debtags/
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/apt/cache.py", line 462, in update
> pulse_interval)
> apt_pkg.Error: E:Problem executing scripts APT::Update::Post-Invoke-Success 
> 'test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i', 
> E:Sub-process returned an error code
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/usr/share/blends-dev/blend-gen-control", line 794, in 
> blend += aptcache(args.release)
>   File "/usr/share/blends-dev/blend-gen-control", line 729, in aptcache
> c.update()

That is strange. For me it works well for Debian med (after manually
removing the backslashes in tasks/cloud):

```
$ sed  -i '1i Format: https://blends.debian.org/blends/1.1' tasks/*
$ make dist
rm -f debian-med-tasks.desc debian/control
make -f debian/rules get-orig-source
make[1]: Verzeichnis „<>/med“ wird betreten
make -f /usr/share/blends-dev/Makefile debian-med-tasks.desc
make[2]: Verzeichnis „<>/med“ wird betreten
/usr/share/blends-dev/blend-gen-control  -r UNRELEASED -S -t
make[2]: Verzeichnis „<>/med“ wird verlassen
make -f /usr/share/blends-dev/Makefile debian/control
make[2]: Verzeichnis „<>/med“ wird betreten
/usr/share/blends-dev/blend-gen-control  -r UNRELEASED -S -c -m
Missing 351 packages downgraded to `suggests`:
  acacia
  afni
[...]
  x-tandem-pipeline
  zodiac-zeden
make[2]: Verzeichnis „<>/med“ wird verlassen
make[1]: Verzeichnis „<>/med“ wird verlassen
$ git diff -w debian-med-tasks.desc
$ git diff -w debian/control
[changes seem useful]
```

And if you look at lines 722ff. of blend-gen-control, the code to create
the cache is

```
d = tempfile.mkdtemp()
os.makedirs(os.path.join(d, 'etc', 'apt'))
shutil.copytree('/etc/apt/trusted.gpg.d',
os.path.join(d, 'etc', 'apt', 'trusted.gpg.d'))
shutil.copy('/etc/blends/sources.list.{}'.format(distribution),
os.path.join(d, 'etc', 'apt', 'sources.list'))
c = apt.Cache(rootdir=d, memonly=True)
c.update()
c.open()
```

The cache is created with `rootdir=d`, with `d` being a temporary
directory, which should be fully accessible for you. It seems that it is
ignored in your version of python3-apt.

And when I try to run apt in python without changing the root dir, I
directly get a

```
>>> import apt
>>> c = apt.Cache()
>>> c.update()
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/apt/cache.py", line 442, in update
raise LockFailedException("Failed to lock %s" % lockfile)
apt.cache.LockFailedException: Failed to lock /var/lib/apt/lists/lock
```

So, I can't reproduce your result. Maybe you have some weird environment
variables set that influence the behaviour of apt?

> I'm running this command as normal user (not root) and think that we
> should not require root permissions to create blends metapackages.

Sure; I also don't run it as root.

> BTW, I think the rewrite of the script is a good reason to bump the
> version of the package to 0.7.

I'd think the same.

Cheers

Ole

Accepted blends 0.6.101 (source) into experimental

[Ole Streicher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 24 Mar 2018 10:41:20 +0100
Source: blends
Binary: blends-dev blends-common blends-doc blends-tasks
Architecture: source
Version: 0.6.101
Distribution: experimental
Urgency: low
Maintainer: Debian Pure Blend Team <debian-blends@lists.debian.org>
Changed-By: Ole Streicher <oleb...@debian.org>
Description:
 blends-common - Debian Pure Blends common package
 blends-dev - Debian Pure Blends common files for developing metapackages
 blends-doc - Debian Pure Blends documentation
 blends-tasks - Debian Pure Blends tasks for new installations
Closes: 785678 825161 891188
Changes:
 blends (0.6.101) experimental; urgency=low
 .
   [ Andreas Tille ]
   * Moved to Salsa
 .
   [ Ole Streicher ]
   * Switch to experimental
   * Replace blend-gen-control with a Python implementation
 - Degrade packages from contrib/non-free to Suggests even when enforcing
   strict depends. Closes: #891188
 - Do not drop virtual packages in alternatives. Closes: #785678
 - Use Python deb822 to parse tasks files.
 - Recognize Format field in tasks file header. Closes: #825161
Checksums-Sha1:
 c93ad6c20e49eece55cf7185f4c8eb203bb3e20c 1930 blends_0.6.101.dsc
 f2b578281cfd426c267a8d7c6fe3f4df1c34b95d 102416 blends_0.6.101.tar.xz
Checksums-Sha256:
 4540cfd0b62e3e778890fc4ed666fa895275ae171df0b0425b9d5ac6abf7daf0 1930 
blends_0.6.101.dsc
 3c4d4b14c83147a93d23334fb2d6c506dd38b46352552cd63a8ca66dff3bff9c 102416 
blends_0.6.101.tar.xz
Files:
 23e8b0446ee98168964086cb9577228d 1930 devel optional blends_0.6.101.dsc
 2bb59264597acf249adebccc1077116f 102416 devel optional blends_0.6.101.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE7/BpV0Ra2/h0L3qtmk9WvbkOGL0FAlq2sCEACgkQmk9WvbkO
GL1BMw/5AVEQ4PdykoILNp/oYWJoR+x1y0DpEFdXbfNKRNOoa4CK0JQ4QVz2FPGM
Fwg9zeAmMPjMQVfF5ChtMQTsBGbcpM342SMo/wH0wZupIS+8wN9pT4wbCAj9J1I0
1UtBu+rhfXLdoimHp2BFLSzwV2egZ+YlZht0zbr9X5S014CqRAqHXzDuVmcUL7Q+
TK1tIH/IvFWzOQc+95cZEdW2scAA01ci6OMllrzeXzR0uTXkL69b4TpICcbxEgeJ
KoP7FLDISoWEiHsqsdMiGfK/RtpWXKMct5CDU12oL0vuu/b7weCvSVyRiI4eQ2Hr
59OedlZ7UJEeboe1xAmdVZUNzT/dHH+7HVsgw+V7d/vu2gbFNiGfLiJqvvHFAMUv
iFFuBmO0c9SiSnszAoGf0m559RkPXmkp/X5D1YB0ly+hLTr9wotN5REUCcpwdjNa
5qOxktwz+s4440NAxq95ONZq9Z5vrmy932DI6HCImLvIO1A/bHC08u7vDXzLCTHU
d1IL5WHmYknXGgFugXkXaJVwbWN3YfFG1Qo1ZKiV6cw/ltTox+lVQyi8zf0q2z/0
cqBNfCTwsG7zPh9PEla1ho6FaNP8elAu6+xEGZvMjDR911wuNGbEwRbNgbZCdohB
q/tiaB7t7zTns0aU9zq1C0vVcyr/4i7kvRCvzp+T1g7rt3m54bk=
=+4zH
-END PGP SIGNATURE-

Re: Bug#825161: blends-dev: please introduce something like compat level

[Ole Streicher]

Hi Andreas,

Andreas Tille <ti...@debian.org> writes:
> On Fri, Mar 23, 2018 at 11:59:15AM +0100, Ole Streicher wrote:
>> When this field is there, it is interpreted as format version, and the
>> code can take care of different formats. In the moment, it distinguishes
>> here between downgrading the dependency level (for format < 1.1) and
>> keeping them (format >= 1.1). If the format is not given, 1.0 is assumed.
>> 
>> Could you tell me whether this fits your needs here?
>
> Fine for me

The format line would suggest that the version of our manual can be
found there. So, would you mind to create a copy so that the current
version (1.0) can be found at https://blends.debian.org/blends/1.0 ?

After we upgraded the format description, we should make a 1.1 and
upload it to the .../1.1 dir (and have a link from the unversioned URL
there).

Best

Ole

Bug#825161: blends-dev: please introduce something like compat level

[Ole Streicher]

Control: tag -1 pending

Hi Holger,

I am going to re-write the blends-gen-control utility in blends-dev in
Python 3:

https://salsa.debian.org/olebole/python-debian-blends

(preliminary development repository; will merge into the blends package).

This utilizes an optional field "Format" in the tasks file, f.e.

```
Format: https://blends.debian.org/blends/1.1
Task: Education
Description: Educational applications
 Various applications that can be used to teach.

```

When this field is there, it is interpreted as format version, and the
code can take care of different formats. In the moment, it distinguishes
here between downgrading the dependency level (for format < 1.1) and
keeping them (format >= 1.1). If the format is not given, 1.0 is assumed.

Could you tell me whether this fits your needs here?

Best regards

Ole

Bug#891188: blends-dev: created d/control recommends packages not in main

[Ole Streicher]

On 22.03.2018 11:52, Andreas Tille wrote:
>> Reading the packages from UDD would follow then (taking the SQL
>> statements from the GSOC approach) by implementing an "apt.Cache" like
>> package repository that is built from UDD.
> 
> I do not mind much about the actual implementation.  If this "apt.Cache"
> like will be able to reflect dependency of architecture.

apt.Cache is already able to work with multiple archs if they are
enabled with dpkg.

>> The structure of the package is a bit more complicated than just for
>> To get the documentation, do a `make html` in the doc subdir (needs
>> sphinx installed).
> 
> I think that's just the code documentation not the general Blends
> documentation which is currently in the same source package as
> blends-dev, right?

Yes.

> PS: Do you plan to also implement the dependency_data statistics?

I am not aware of this, and since my time is a bit limited: Not in the
moment.

Best

Ole

Bug#891188: blends-dev: created d/control recommends packages not in main

[Ole Streicher]

Control: affects -1 src:debian-astro

Hi Andreas,

On 22.03.2018 11:04, Andreas Tille wrote:
> Control: severity -1 important

Sure. Debian Astro the only one which is affected.

I wrote:
> In the moment, I would tend to rewrite blend-gen-control from scratch,
> using Python 3 and the standard Debian Python packages (debian.deb822,
> apt) in  a modular fashion.

FYI, you may find the scratch development (to be integrated in the
blends package) at

https://salsa.debian.org/olebole/python-debian-blends

Currently it is able to generate d/control with the help of (python-)
apt, and it would resolve this bug. To replace the current
blends-gen-control I still need to implement the generation of the
tasks-desc file. Then (and after some finetuning) I would integrate this
and create a new blends version for "experimental" (publish early,
publish often). It would then also solve #764589, #785678, #825161, and
#885145.

Reading the packages from UDD would follow then (taking the SQL
statements from the GSOC approach) by implementing an "apt.Cache" like
package repository that is built from UDD.

The structure of the package is a bit more complicated than just for
d/control generation; the idea however is to re-use the same code for
the Web pages. For this, it may be nice to have a separate Python package.

To get the documentation, do a `make html` in the doc subdir (needs
sphinx installed). Package is tested under Python 3 only.

Best

Ole

Re: Bug#891188: blends-dev: created d/control recommends packages not in main

[Ole Streicher]

Hi Andreas

(completely moving to d/blends, since this is not bug related)

On 16.03.2018 14:17, Andreas Tille wrote:
> On Fri, Mar 16, 2018 at 01:51:25PM +0100, Ole Streicher wrote:
>> In the moment, I would tend to rewrite blend-gen-control from scratch,
>> using Python 3 and the standard Debian Python packages (debian.deb822,
>> apt) in  a modular fashion. This would make the script much more
>> maintainable (given the knowledge of Python is a bit better than Perl),
>> and could also lead to create a "debian.blends" Python package that
>> could be re-used for the Web pages.
> 
> I can only repeat:  Blends-dev *was* rewritten and creates correct
> results:
> 
> https://salsa.debian.org/blends-team/blends-gsoc

I was not aware that the rewrite was done in Python.

Anyway: That one is not much better. It is in Python, OK, but it is not
more modular, and it implements everything by itself instead of re-using
standard packages (namely debian.deb822 and apt). What I want to have is
something like

from debian.blends import Task
t = Task('tasks/education')

and t then "looks like" (duck-typing) the apt (versionized) package that
one would get with

import apt
c = apt.Cache()
t = c['astro-education'].version[0]

so that "t.recommends" gets apt.package.Dependency-like dependencies etc.

In principle, one could do the same by generating the Task from UDD.
But, I don't see why calling UDD instead of using the local tasks
definition has an advantage for writing d/control. UDD makes it
difficult for non-Debian blends/distributions: how f.e. would Mint Linux
get it? Or how would a blend that is not in the UDD get the information
about its metadata?

> I repeat again: This creates *architecture* dependent metapackages (I
> explained here why only this makes sense). 

Could you point me to your explanation please? I missed it.

> I'm all for switching to
> Python3 but a complete rewrite should not be necessary.  There are some
> glithes in the code (for instance line breaking in the auto generated
> part of d/changelog) and it definitely needs testing.

I would re-use parts of it, but I am a bit resistant of "just finishing"
it. And the word "changelog" does not appear in its blends-gen-control?

> I *really* appreciate your effort but may be 80% of the work is just
> done and you try blends-gsoc first.  As we all know the last 20% is
> the harder part - but I urgently vote for using UDD as base for
> anything we use.  May me using the public UDD mirror can help to not
> force everybody who wants to run blends-dev having a local clone.

I will have a deeper look into the package. However, for package
creation UDD looks to me the wrong tool (see above).

Best regards

Ole

Bug#891188: blends-dev: created d/control recommends packages not in main

[Ole Streicher]

Hi Andreas,

On 15.03.2018 19:41, Andreas Tille wrote:
> I've commited a fix to Git which for me creates now sensible Debian
> Astro metapackages.

For me, it actually upgrades the "Recommends" with to "Depends". For
example, the "education" task (shortened):

```
Task: Education
Install: true
Description: Educational astronomy applications [...]

Recommends: celestia-gnome, gpredict, kstars
Suggests: sunclock, xtide
```

becomes in d/control:

```
Package: astro-education
Section: metapackages
Architecture: all
Depends: ${misc:Depends},
 astro-tasks (= ${source:Version}),
 gpredict,
 kstars
Recommends: celestia-gnome
Suggests: sunclock,
 xtide
Description: Educational astronomy applications [...]
```

celestia-gnome is a package that does not exist in unstable.
GENCONTROL_DEPENDS is set to TRUE.

In the moment, I would tend to rewrite blend-gen-control from scratch,
using Python 3 and the standard Debian Python packages (debian.deb822,
apt) in  a modular fashion. This would make the script much more
maintainable (given the knowledge of Python is a bit better than Perl),
and could also lead to create a "debian.blends" Python package that
could be re-used for the Web pages.

Any thoughts on that? I'd volunteer here.

Best regards

Ole

Bug#891188: blends-dev: created d/control recommends packages not in main

[Ole Streicher]

Hi Andreas,

On 15.03.2018 16:16, Andreas Tille wrote:
> I tend to set the issue from serious to important since I now found out
> why the problem seems to occure only in the case of Debian Astro (or may
> be any other Blend that is using
> 
>GENCONTROL_DEPENDS = true
> 

Feel free to lower the severity. However, that was a change of the
default behaviour that we discussed a year ago: we wanted to remove the
translation

"Depends:" (tasks) -> "Recommends:" (d/control)
"Recommends:" (tasks) -> "Suggests:" (d/control)

in favour of a direct copy. I am wondering why debian-astro is the only
blend which finally used this, and I think we wanted to convert all.

> But I do not want to play severity ping-pong and will have a look
> why GENCONTROL_DEPENDS is obviously breaking this.

That is probably the code that was introduced for this purpose (August
2017).

Best

Ole

Bug#891188: blends-dev: created d/control recommends packages not in main

[Ole Streicher]

Hi Andreas,

could you Cc your mails to the bug?

On 23.02.2018 13:23, Andreas Tille wrote:
> Did you somehow changed /etc/blends/sources.list or are you
> pointing to some different location with -s option?

No. As you can see from my last mail, the list of missing or avoided
packages seems to be generated properly. It is just not used to lower
the dependencies.

Best

Ole

Bug#891188: blends-dev: created d/control recommends packages not in main

[Ole Streicher]

Hi Petter,

On 23.02.2018 11:29, Petter Reinholdtsen wrote:
> [Ole Streicher]
>> It did. astro-catalogs 1.0 (included in Stretch) has "Suggests:
>> astrometry-data-2mass" in the package and "Depends:
>> astrometry-data-2mass" in the tasks page:
> 
> But why did it?  Was it because astrometry-data-2mass was in contrib or
> non-free while astro-catalogs was in main, or because
> astrometry-data-2mass was simply missing from the checked package lists
> when the task was created?  I believe the latter, as I have not seen
> blends-dev checking main/contrib/non-free status.

astrometry-data-2mass was in contrib at this time. Gliese is in non-free
since 2004, is also listed as "Depends" in tasks/catalogs and as
"Suggests" in debian/control (just below astrometry-data-2mass).

>> Violates Debian policy 2.2.1:
>>
>> | In addition, the packages in main
>> |  * must not require or recommend a package outside of main for
>> |compilation or execution [...]
> 
> This only documents that it is _possible_ to use blends-dev to create
> non-policy compliant tasks, which is a given.  This in it self do not
> make blends-dev in conflict with policy.  It is the responsibility of
> the task writers to ensure policy compliance regarding
> main->contrib/non-free relations, not blends-dev.

blends-dev did generate policy conform packages in Stretch by
automatically downgrading everything not in main, and is now creating
packages that violate policy from basically the same source.

> My conclusion is that it is wise to keep blends-dev in a state where it
> is _possible_ to create policy breaking tasks, and leave it to the task
> author to avoid it.

What is the use case for that?
>> Having this processed is the basic idea of a separate "make" task for
>> the blends. If there was no comparison to the actual package list, one
>> could generate d/control directly in d/rules.
> 
> The blends-dev scripts have always checked package lists for
> _existance_.  As far as I know, it have not checked anything more.

It does *not* check the package list for _existance_ anymore. It puts
everything into Recommends, independent of being in main, contrib,
non-free or not packaged at all. That is the content of this bug.

BTW, when running "make", it properly shows the missing packages:

```
/usr/share/blends-dev/blend-gen-control -s unstable -S  -c -m -i -A) >
debian/control.new && mv debian/control.new debian/control
Hit:1 http://ftp.debian.org/debian testing InRelease
Reading package lists... Done
Missing or avoided packages:
  [...]
  astrometry-data-2mass
  [...]
  audela
  [...]
  gliese
```

It just does not use the list for lowering the dependency.

Best

Ole

Bug#891188: blends-dev: created d/control recommends packages not in main

[Ole Streicher]

Hi Petter,

On 23.02.2018 10:56, Petter Reinholdtsen wrote:
> [Ole Streicher]
>> This violates the policy in the generated blends tasks packages; 
>> therefore the severity.
>> 
>> IMO this is a regression; it worked some time ago, right?
> 
> As far as I know, this has never behaved differently.  I am not aware
> of blends-dev every looking at main/contrib status, only if the
> package exists.

It did. astro-catalogs 1.0 (included in Stretch) has "Suggests:
astrometry-data-2mass" in the package and "Depends:
astrometry-data-2mass" in the tasks page:

https://sources.debian.org/src/debian-astro/1.0/tasks/catalogs/#L10
https://sources.debian.org/src/debian-astro/1.0/debian/control/#L69

("Depends" was renamed to "Recommends" in the tasks after Stretch).

The idea here is that when typing "make", the latest package list (of
main) is downloaded, and all packages from the tasks are compared to it.
When a "Recommended" package is not in the tasks list, it gets
downgraded to "Suggests" in d/control. That was the processing at that time.

> In my view, it is the responsibility of the people writing the tasks
> to decide if a package in contrib should use recommends or suggest,
> not the blends build system.  I would thus classify this as a
> wishlist issue, and recommend against changing the current default,
> as changing this would make it impossible to use blends-dev to create
> a task where the developer want to recommend a package in contrib or
> non-free.

Violates Debian policy 2.2.1:

| In addition, the packages in main
|  * must not require or recommend a package outside of main for
|compilation or execution [...]

> In short, I do not agree that this 'violates the policy' to do what
> the task writer intends.  It might be useful to emit a warning if the
> build system detect a recommend from main to contrib or non-free, but
> it should not prohibit task writers from creating such tasks.

And this is only a side problem (I should have brought them in opposite
order). This also affects packages that are not at all (yet) in Debian.

Having this processed is the basic idea of a separate "make" task for
the blends. If there was no comparison to the actual package list, one
could generate d/control directly in d/rules.

Best

Ole

Bug#891188: blends-dev: created d/control recommends packages not in main

[Ole Streicher]

Package: blends-dev
Version: 0.6.100
Severity: serious

Hi,

when I run "make" on a blend's package, it puts all that is in
"Recommends" in the tasks package into "Recommends" of d/control,
independent of the status of the package.

Examples, from debian-astro
https://salsa.debian.org/debian-astro-team/debian-astro

tasks/catalogs:
```
Task: Catalogs
Install: false
Description: Astronomy catalogs
 This metapackage will install [...]

Recommends: stardata-common, gliese, yale

Recommends: astrometry-data-tycho2, astrometry-data-2mass
```

Here, astrometry-data-2mass is not in main, but in contrib; therefore
the dependency should be lowered to "Suggests". However, in d/control:

```
Package: astro-catalogs
[...]
Recommends: astrometry-data-2mass,
 astrometry-data-tycho2,
 gliese,
 stardata-common,
 yale
Description: [...]
```

The same happens with packages that are not uploaded yet, f.e. the
package "audela" in tasks/telescopecontrol ("Recommends", with a WNPP
entry) is still not packaged, but is "Recommends" in astro-telescopecontrol.

This violates the policy in the generated blends tasks packages;
therefore the severity.

IMO this is a regression; it worked some time ago, right?

Cheers

Ole

Re: Blends team on alioth created

[Ole Streicher]

Sebastiaan Couwenberg  writes:
> I took the liberty to import the gis project:
>
>  https://salsa.debian.org/blends-team/gis

At least Debian Science, Debian Med and Debian Astro are "top-level"
projects. I would also prefer a flat structure, with only common blends
stuff in blends-team.

Cheers

Ole

Re: change proposal for handling of Depends: field in task files

[Ole Streicher]

Hi all,

Mike Gabriel  writes:
> Nonetheless, the current status of blends-dev is:
>
>  1. it now fully suppors two modes "nodepends=true" (aka -D) and
> "nodepends=false (aka without -D)
>  2. the "nodepends=true mode is the default

I still think it would be better to depend on a tag within the tasks
file.

There is one more question now coming up: in the blends tasks pages, we
currently have two sections covering files in main:

* "Official Debian packages with high relevance" (Depends: and
  Recommends: fields in the tasks pages)
* "Official Debian packages with lower relevance" (Suggests: fields in
  the tasks pages)

After the change, we will have an additional section with the packages
that essential (the new "Depends:" section).

First question: how should that be named?
Second question: how do we handle the transition to not have the
packages silently in wrong sections?

Best regards

Ole

Re: change proposal for handling of Depends: field in task files

[Ole Streicher]

Andreas Tille <andr...@an3as.eu> writes:
> On Tue, Aug 08, 2017 at 09:04:56PM +0200, Ole Streicher wrote:
>> Mike Gabriel <mike.gabr...@das-netzwerkteam.de> writes:
>> > Is anyone here maintaining blend packages that have not been uploaded
>> > to Debian? If so, please speak up.
>> 
>> My point was here: If we introduce a format identifier (like an URL), we
>> can very simply test for it and exit with error if it is the wrong one.
>> 
>> The required changes in the tasks are trivial, so there would be no need
>> to support more than the "new" format. Anyone who did not get the bang
>> can just change it then.
>
> I wonder if all this format discussion might keep us away to continue
> with the simple solution to just do it and break things that are
> outside.  IMHO it should not stop our progress if outside people are
> using things that are intended for inside.  I would be very happy if
> some of the perl programmers would do that supposedly simple change and
> we could continue with interesting things.

Sorry, I don't see the big problem here: The first step is anyway just
to extend blends-dev to accept "Recommends" aside of "Depends", which
should be simply enough. Then, the only disagreement is that I propose
to have a required Format: line in the tasks header; this should be
trivial enough as well (as long as we agree on the URL itself).

This additional line even works if the URL is not valid yet -- but gives
us some additional pressure to create an up-do-date format description
(which is IMO not the worst thing).

So, what about

Format: https://blends.debian.org/doc/0.7/tasksformat.html

(blends-doc has currently version 0.6.98; 0.7 would be the logical next
step)

Best

Ole

Re: change proposal for handling of Depends: field in task files

[Ole Streicher]

Mike Gabriel  writes:
> Is anyone here maintaining blend packages that have not been uploaded
> to Debian? If so, please speak up.

My point was here: If we introduce a format identifier (like an URL), we
can very simply test for it and exit with error if it is the wrong one.

The required changes in the tasks are trivial, so there would be no need
to support more than the "new" format. Anyone who did not get the bang
can just change it then.

Best regards

Ole

Re: change proposal for handling of Depends: field in task files

[Ole Streicher]

Hi Andreas,

I my feeling right that you basically propose the same as I?

Andreas Tille  writes:
> I'm all for it.  I just did `sed -i 's/^Depends/Recommends/' tasks/*` in
> Debian Med packages but while I assumed that this would work with
> blends-dev unfortunately it does not.  I need to check this later since
> I'm busy with other stuff.  I think the web sentinel threats Depends and
> Recommends equally so the replacement should not harm.

So, we should do a 0th step and fix blends-dev to accept Recommends: as
well (and translates it to Recommends: at package dependency level)

>> and then change the behaviour of the "blends-dev" package.
>
> I think the first change in blends-dev should be to accept Recommends.

Ack. Should be trivial to fix.

> I admit for the sake of simplicity (and the fact that we have only a
> few Blends we could deal with easily) we could simply fix blends-dev
> to accept Recommends.

Ack. This is the first step and seems not nontroversial at all.

> After this we could inform those few Blends maintainers (I'll be
> responsible for med, science and junior)

Ack. The usual way to "inform other blends" (which means: ask them to
change something in their blends packages) is a bug report, which would
also help us to track the progress.

> I guess Debian GIS and Debian Games are also happy about the change,
> no idea about Debian Multimedia and how/whether it is maintained at
> all, Debian Accessibilities only uses web sentinel (no metapackages -
> I would do the change here as well) and finally EzGo which is kind of
> a riddle to me.

Non maintained blends cout get an NMU, and also then the bug report
helps documenting the process.

> In a second round we could later change the behaviour of Depends.

Ack. And to make sure that no older blends metapackage slips through
(maybe local, or in a derivative), we should mark the new format
somehow -- which brings the "Format:" header line into the game.

Any old-style blends metapackage would then fail to build (and could
again easily be fixed).

> I agree that technically that's a weak solution but should work if
> somebody intends to reproduce older packages since we would fail to
> reproduce older packages from older Git commits.  However, I do not
> consider this a strong argument over burning developer time with
> implementing and testing a more complex versioning + format system.

I do not see a use case for this. Even when backported, one could still
generate the source package on a current system. And if we provide a
simple (sed) script that does s/^Depends:/Recommends:/ (and adds the
format line in the begining), one could manually apply this before
further processing with blends-dev.

Best regards

Ole

Re: change proposal for handling of Depends: field in task files

[Ole Streicher]

Petter Reinholdtsen  writes:
> We started by using depends.  This proved a disaster, as the meta
> packages would be close to impossible to keep in testing.  It would be
> thrown out or blocked from entering testing whenever any of the more
> than 1000 packages we want had a RC problem.
>
> After struggling with this for a few years, we decided to use recommends
> instead.

The problem here is IMO that the task still says "Depends", which is
translated into "Recommends": this is just not intuitive. And it
requires that a task that has a strong real "Depends" needs to do some
workarounds.

The number of blends is countable: I personally like the idea to first
replace all "Depends" with "Recommends" in all tasks files, and then
change the behaviour of the "blends-dev" package.

We should also introduce a format identifier to make future changes
easier; so my proposal would be:

1. We write a (maybe preliminary) format description and publish it
under a well-defined URL

2. We create bugs for all known build-dependencies of blends-dev to
2.1 'sed s/^Depends:/Recommends:/ -i tasks/*`
2.2 insert a "Format: https://blends.d.o/format; as first line to
indicate that the new format is used

3. Once all switched (should be not that difficult, due to the
 straightforward change), we upload a new version of blends-dev that
 checks the format id and
 a) either exits with error if it is not there or a wrong one
 b) prints a depretation warning and proceeds with the old style in that
case
 Because of the trivial change, I would prefer a).

Best regards

Ole

Re: About the internal and external view of Blends

[Ole Streicher]

Andreas Tille  writes:
> My impression is that the view of the majority of the Debian developers
> is basically A which is possibly shared by Tollef when he considers the
> importance of the bug not RC.

In an earlier state of the universe, there were "Release Goals" [1],
which are however not updated since 2013. They were discussed thereafter
[2], and then of the Todo List of Lucas Nussbaum in 2014 [3], from where
they then disappeared [4].

However, putting the Blends installation on a something like the Release
Goals List could help here. It would also push us into the steps needed
for this (like to define who goes in etc.)

Cheers

Ole

[1] https://wiki.debian.org/ReleaseGoals/
[2] https://lists.debian.org/debian-devel/2013/11/msg00455.html
[3] https://lists.debian.org/debian-devel-announce/2014/08/msg00010.html
[4] https://lists.debian.org/debian-devel-announce/2014/12/msg6.html

Bug#846002: Lowering severity

[Ole Streicher]

Control: Severity -1 normal


Since no objections against my proposal were expressed for a week, I am
lowering the severity.

Since there is no update of the bug report with more recent experiences,
I will to close it as of version 0.6.94 within a few days.


Best regards


Ole

Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

[Ole Streicher]

Control: reassign -1 blends-tasks
Control: tags -1 moreinfo

Hi Holger,

thank you for your bug report to the "blends" package. I would, however
question a few things here and also ask for a little bit more information:

The "blends-tasks" package was created as a result of working on bug
#758116, titled "tasksel: Allow to select Blends selection during
installation - just 'DE', 'Web server', 'Mail server' is NOT enough".
This bug was created more than two years ago, and nowhere in the bug it
was questioned that the blends should be selectable during the
installation process. This, however, *requires* to have the information
about the blends available during installation, and this makes the
package that provides this information "important". Therefore, it is not
a policy violation, which in turn removes your argument to make this bug
"serious". It also does not "completely break the UI of the installer"
-- the selection is in no mean different from the desktop environment
selection. I would therefore propose to lower the severity of the bug.

Also, I would ask you to do an NMU until the discussion has settled
down. This would be an abuse of the NMU. NMUs are meant to deal with
unresponsive maintainers, and you did not show any evidence that the
blends maintainers are not responsive with respect to this problem.
Doing NMUs during a discussion is quite offending. I also don't see a
reason to hurry with implementing an unsettled decision: the blends
selection is there since almost 8 months now without any significant
change or discussion for ~6months. What makes the issue now so urgent
that you try to push this within four days? Why didn't you do this half
a year ago? We implemented the current solution at that time (and you
*knew* that we did) exactly to have some buffer for discussion about
critics. Why didn't you use that, but start now when it is quite late?

The next point is that you base your critics not on some experience with
the current installer but on an outdated, half-a-year-old screenshot.
Since then, several improvements were done, both in the appearance in
the installer, and in the selection of which blends are there. For the
first, see the discussion here:

https://lists.debian.org/debian-blends/2016/07/msg00027.html

We would also not include all blends there, but select them on an opt-in
base. So, if debian-edu is not useful to be installed that we, it shall
be removed. At the end, this will reduce the number of selectable blends
quite much.

I would therefore ask you to rebase your arguments on your experience
with the current implementation and not on something that is six months
old and not actual anymore.

Another point, concerning the argument of "confusing" users: As I said,
the blends-tasks package is in place now since eight months, with the
current implementation there since ~6 months. Since then there was no
single report that someone did not understand the options here -- no bug
report, nothing on the installer, blends, or devel mailing lists. I also
did an extensive search on the net, and the only thing I found is
mentioned in the discussion above and addressed by the changes made
after that. Since then, no single problem was reported, with more than
5000 installations according to popcon. This gives a good sign that the
addition of the blends to that menu does not confuse people, and I would
ask you to show a better empirical evidence that it does.

I will not discuss the arguments during the discussion in #758116 here
again -- there was a lengthy discussion about this, and the linked
postings were covered there as well. It makes no sense to repeat that
here again six months later.

Concerning your idea of having different install images, I am not
convinced that it is a good solution: First, it multiplies the whole
image creation process by the number of blends. If we have 10 official
architectures and (let's say) 5 blends to be included there, they would
then have to manage 60 images instead of 10, with all the requirements
that come out of this (installer manual, web page, updates, web space etc.).

But it also gives a wrong sign: Debian Pure Blends are by definition
integral part of Debian itself. But even now, this is hard to understand
for many people -- questions like "what is the difference between Debian
Astro and Debian" are quite common, even in front of a poster describing
exactly that. With having separate official images for all blends,
people would even be more confused. As an example, I would take the
Ubuntu approach of having "Ubuntu", "Kubuntu", "Xubuntu" etc. instead of
installation options -- people usually think that they have to
re-install the system if they want to switch from one flavour to the
other. Having similar experience with Debian would be bad for the
reputation of the Blends, and for Debian in general.

Best regards

Ole

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi Andreas, Petter and all,


On 15.11.2016 07:09, Andreas Tille wrote:
> Hi,
>
> I just want to announce that I'll be de-facto offline today and
> tomorrow.  So I can not do further testing of the "Use of uninitialized
> value" testing.
>
> Kind regards
>
>   Andreas.
>
> On Fri, Nov 11, 2016 at 12:52:46PM +0100, Andreas Tille wrote:
>> Use of uninitialized value $_ in pattern match (m//) at
>> /usr/share/blends-dev/blend-gen-control line 568,  line 28.
>> [...]

I fixed this in the git. HOWEVER, again: I have no glue what I do here.
I just assume that "next unless defined $_" does more or less what it
means, and I hope it will do so as well in the line where I put it. Same
for "last if !defined $_". I used these two phrases just because they
are already somewhere else in the script. Anyone with Perl knowledge:
CHECK IT!

Cheers

Ole

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi all,

On 11.11.2016 08:07, Andreas Tille wrote:
> On Thu, Nov 10, 2016 at 10:38:32PM +0100, Ole Streicher wrote:
>> --> debian-edu tasks are just broken. They don't follow any rule, and
>> depending from the parser one will get always different results. Maybe
>> we should fix that? remove all backslash continuation lines and
>> duplicated keywords from the tasks files?
> 
> I think it should be sufficient to add line breaks where needed.

If we touch them anyway, we could make them fully RFC compliant at this
time as well. Since I am currently stuck in the S-Bahn (Polizeieinsatz),
I will do that for debian-edu and push. Cellphone internet is a nice
thing sometimes... :-)

@Petter, please review and change/revert if you disagree.

Cheers

Ole

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi Andreas, Petter and all,

On 10.11.2016 21:07, Andreas Tille wrote:
> So I confirm that the first problem we detected is solved but there is
> another one breaking Debian Edu.  I have again no suspicion why the '\'
> sign is not elimiunated from the list only in those few cases.

I can also just "poke in the fog" here. I thought that the multilines
were already eaten up by lines 537-544, and should not appear again
here. However, they do, as my "print" debugger shows. Perlists, please
help!!!

The pragmatic solution here is to just remove the backslashes from the
end of line. I can commit a patch that does this.

However, debian-edu keeps to be broken. Reason is that the tasks contain
lines like (development)

Depends: fp-compiler, [...multiline... ], fp-units-fv
Depends: lazarus

so, with two "Depends" in one section. Or (electronics):

Depends: qucs, gpsim, oregano
Recommends: education-menus, xoscope
Suggests: kicad, kicad-doc-en, kicad-doc-de, kicad-doc-es, kicad-doc-fr
Suggests: electric, pcb, xcircuit, freehdl, gtkwave
Responsible: ?
NeedConfig:  no

two "Suggests". This does not work anymore (no idea why), but is also
IMO forbidden by RFC834.

I have no idea why this works without RFC834 continuation, but not with
them.

On the other hand, we *win* one more dependency: in "common", the
"firmware-ralink" dependency line was *not* preceded one with a
backslash. This shows that the backslash is just a bad idea for
continuation lines.

--> debian-edu tasks are just broken. They don't follow any rule, and
depending from the parser one will get always different results. Maybe
we should fix that? remove all backslash continuation lines and
duplicated keywords from the tasks files?

Best regards

Ole

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi Andreas,

On 10.11.2016 13:48, Andreas Tille wrote:
> Hi Petter,
>
> On Thu, Nov 10, 2016 at 12:39:07PM +0100, Petter Reinholdtsen wrote:
>> Control: tags -1 + pending
>>
>> [Andreas Tille]
 Should I commit it?
>>> Yes please.  Ole, you reported problems with your patch.  Could you
>>> please be more verbose about this problem - at best based on Petter's
>>> commit to make sure we are all working on the same code?
>> It is now commited.  Please give it some more testing before uploading.
>> Preferably also with the debian-edu git repo, where both tasks and
>> control file is kept in git, allowing any changes to be easily
>> discovered.
> I need to admit two things: Even in Debian Med we went into the trap
> criticised by Ole.  In bio-cloud which is not maintained by me we were
> also loosing entries.  The second thing I need to admit that there are
> in fact syntax errors resulting from the patch.  When using the new
> blends-dev package a
>
> gbp clone ssh://git.debian.org/git/blends/projects/med.git
> cd med
> make dist
> grep ^, debian/control
>
> shows the problem.  It leads to something like
>
> Suggests: bagpipe,
>  cufflinks,
>  embassy-phylip,
>  gmap,
>  r-cran-vegan
> ,
>  r-other-mott-happy.hbrem
> ,
>  r-other-valdar-bagphenotype.library,
>  soapdenovo2
> ,
>  sra-toolkit
> ,
>  staden-io-lib-utils
> ,

This is what I meant, and it is fixed by my last commit. Please try
again ;-)

Cheers

Ole

Re: Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi Bas,

Bas Couwenberg <sebas...@xs4all.nl> writes:
> On 2016-11-10 08:56, Ole Streicher wrote:
>> I am ready to test and also to fix; however my know-how ends here. I
>> don't know what is wrong with the fix.
>>
>> Just wondering, and starting to really get worried: None of the
>> debian-blends maintainers has enough Perl knowledge to fix this? If we
>> all do not know Perl, why do we use that language in one of our central
>> tools? That sounds to me even more RC than the bug itself...
>
> I know Perl quite well, but haven't tried your patch as I don't think
> it needs to fixed now.

As I wrote: there is a danger that a blend uses RFC822 style
continuation lines and silently gets bad metapackages. I had the
problem, nothing warned me, it was just luck that I discovered it. How
sure are we that I am the only one? Do you really think this shouldn't
be fixed before stretch?

Come on, we speak about a four-line change of in the code here. Have a
look please. It is not a sophisticated code here with many hidden traps,
it is just usual §$%&/-Perl-stuff, which makes it difficult to fix for a
strawman like me, but should be simple for an expert like you. Probably
takes less time than the whole discussion here.

Best regards

Ole

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi Andreas,


On 09.11.2016 12:47, Andreas Tille wrote:
> In other words: Once it was defined as syntax for these control files
> that newlines need to be escaped.  I do not like it and as I said this
> is fixed in the long-term pending rewrite.  However, the bug is not
> serious but at best wishlist.  Would you follow this arguing?
>

Not really. My point here is that this happens really unexpected, and
since blend-gen-control doesn't complain about the then wrong format,
one silently gets wrong dependencies. At least I did in the first
versions of debian-astro (<0.5).

We have a clear definition of how these files should look like, namely
RFC822, and this also defines continuation lines. Look at
https://blends.debian.org/blends/ch08.html#edittasksfiles - it is
blends-gen-control that isn't conform to that.

I would think that there is also a quick fix for it -- the tool already
handles continuation lines for the tasks description, so one could
probably just take that. I have no glue of all the Perl $@^!~ special
chars, but wouldn't do it something like the attached patch (after
removing the obvious errors from it)?

Or something else just adopted from lines 556-562 of blends-gen-control?

Best regards

Ole

diff --git a/devtools/blend-gen-control b/devtools/blend-gen-control
index 1aba552..cde3237 100755
--- a/devtools/blend-gen-control
+++ b/devtools/blend-gen-control
@@ -566,9 +566,14 @@ sub load_task {
 my $header;
 for $header (qw(Depends Recommends Suggests)) {
 if (m/^$header:\s+(.+)$/ && $1 !~ /^\s*$/) {
+		my $pkgs = $1;
+		while () {
+		last if (m/^\S+/ || m/^\s*$/);
+		$pkgs .= $_;
+		}
 $taskinfo{$curpkg}{$header} = ()
 if (! exists $taskinfo{$curpkg}{$header});
-my ($pkglist, $missinglist) = process_pkglist($1);
+my ($pkglist, $missinglist) = process_pkglist($pkgs);
 push(@{$taskinfo{$curpkg}{$header}}, @{$pkglist});
 
 		$haspackages += $#{$taskinfo{$curpkg}{$header}} + 1;

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Package: blends-dev
Version: 0.6.94
Severity: serious

When a "Depends:" field in a task file contains more than one line, only
the first line is used to create the dependency in debian/control. All
others are silently ignored.

I observed this on the "debian-astro" package which uses blends-dev.

Since this is quite dangerous (it is not recognized unless one really
checks the generated d/control file) and generates incorrect blends
packages, I make it severity "serious".

Short code inspection shows that there seem to be *two* places where the
list is parsed (in blend-gen-control): once on gen_control (aroound line
250), and then in load_task (around line 570). In the first appearance,
only the first line is used, while in the second one the full list is
there. Unfortunately, my perl is not enough to fix this...

Best regards

Ole

Re: Blends naming in the Debian installer

[Ole Streicher]

Hi Paul and all,

Paul Wise <p...@debian.org> writes:
> On Thu, Jul 21, 2016 at 4:56 PM, Ole Streicher wrote:
>> --> we should have better menu names here, which help a person who is
>> new to Debian to understand what is going on here.
>
> Agreed, the codenames we use for our projects shouldn't be exposed to
> first time users, instead we should use terms used by the targets of
> each blend to describe themselves and their peers.

I agree with your proposal and would change the naming:

> [ ] Special tasks
> [ ] ... astronomy
> [ ] ... education
> [ ] ... medicine
  life sciences and medicine
> [ ] ... geography
> [ ] ... hamradio
  amateur radio (?)
> [ ] ... gaming and fun
> [ ] ... for kids

We *could* still put the Blends names there as well:

[ ] Special tasks
[ ] ... astronomy (Debian Astro)
[ ] ... chemistry (DebiChem)
[ ] ... education (Debian Edu)
[ ] ... life sciences and medicine (DebianMed)
[ ] ... geographical information systems (Debian GIS)
[ ] ... amateur radio (Hamradio)
[ ] ... gaming and fun (Debian Games)
[ ] ... multimedia (DebianMultimedia)
[ ] ... for kids (Debian Junior)

so that people explicitely interested in a blend could find it; however
I am not sure if this would not be again confusing.

I would then however input for the not-so-simple blends:

Debian Accessibility, Debian EzGo

and for those who are not on the list yet as well :-)

We should also do an opt-in at some point; I don't want to force any
Blend to appear in the installer.

Best regards

Ole

Re: Blends naming in the Debian installer

[Ole Streicher]

Charles Plessy <ple...@debian.org> writes:
> Le Thu, Jul 21, 2016 at 06:17:26PM +0800, Paul Wise a écrit :
>> On Thu, Jul 21, 2016 at 4:56 PM, Ole Streicher wrote:
>> 
>> > 1) no understanding of what a "Debian Pure Blend" is
>> > 2) Also "Debian Astro", "Debian Junior" are not understandable easily.
>> >
>> > --> we should have better menu names here, which help a person who is
>> > new to Debian to understand what is going on here.
>> 
>> Agreed, the codenames we use for our projects shouldn't be exposed to
>> first time users, instead we should use terms used by the targets of
>> each blend to describe themselves and their peers.
>
> Hi Ole, Paul and everybody,
>
> in the case of Debian Med, I think that it is hard to avoid the codename.  We
> are covering different user roles (patients, medical doctors, research
> scientist, etc.), different professions (practitionner, software developer,
> system administrator, ...), or different fields (medecine, bioinformatics,
> neuroscience, microbiology, etc.).  Therefore, we need to make ourselves known
> as "Debian Med".  We should aim that people download a Debian installer with
> the goal of installing Debian Med, and help them to find us by that name.

IMO we will only have chances to survive in the installer if we do not
confuse the majority of people who do *not* install any blend. 

The forum message I cited shows that actually people get confused and
feel unsure what to do. This is also the case for a "Debian Med" entry,
as it is for "Debian Astro". So, maybe, an explanation *together* with
each blend name would do the trick?

Best regards

Ole

Bug#825172: any update on this bug ("please provide a way to create true depends")

[Ole Streicher]

On 10.07.2016 16:13, Holger Levsen wrote:
> but this is too ugly for my liking. I will not implement such stuff
> voluntarily. Debian is about correct solutions and this feels just too
> wrong.

I am not sure if I brought my proposal up already: In my opinion, the
best solution here would be to make a clear definition of the task file
format and to refer to it in the file. Like it is done for the copyright
(just forgot the dep number), including a version. This definition
already exists in Andreas' documentation, but it is not more actual
anymore (partly my fault: I extended quite some entries for the header
without documenting them).

Once we have the definition, we could extend

* blends-dev to use this format if it is referenced in the task header
* webtools to handle this new format
* whatever else exists there that uses the tasks files

If this is done and tested, people who need it could just use the
format. And once it is working flawlessly, we could write wishlist bugs
to the remaining blends to switch. And/or just change it in the RCS
(most of them are team maintained IMO) -- it should be mostly just an
sed script.

This should just be started. Holger, since you have the most pressure:
would you...? I don't see much sense in blaming anyone for possible
mistakes in the past; it would be better just to get it fixed: start
with a technical discussion.

Best regards,

and greetings from the last hour in the hack lab in Fuller House, Cape
Town, SOuth Africa

blends.debian.org moved to https

[Ole Streicher]

Hi all,

Today I found the https://blends.debian.org webpages working, and all
http requests forwarded to https.

This currently breaks many web pages, since they internally still link
to styles, images etc. via http. I already fixed this for the generated
pages (package lists etc. -- needs still a rebuild), and on the Debian
Astro Web pages. All other are still left as they are.

So, please check the web pages for your blend. If you observe
incomplete/broken web pages, you should fix them by moving to
https. Actually all (major) Debian web servers now are able to use
https.

Best regards

Ole

Re: Blends integration into the Debian Installer

[Ole Streicher]

Jonas Smedegaard <d...@jones.dk> writes:
> Quoting Ole Streicher (2016-05-24 14:31:41)
>> Ole Streicher <oleb...@debian.org> writes:
>>> I will open wishlist bug reports for all blends mentioned in the web 
>>> page to clarify if and what they want to have in a default 
>>> installation.
>>
>> Did this for almost all blends that claim to have metapackages:
>  ^^^
>
> I briefly skimed the bugreport for multimedia blend, and instructions 
> there seemed to be specific to using blends-dev for generating the 
> metapackages.
>
> Do the inclusion into debian-installer require blends-dev?  If not, is 
> there any hints anywhere on generic requirements?

All you basically need to to create a -all package that somehow
pulls all the packages you want to see in the default installation. If
one uses blends-dev, this can be done by using the "Install: true" flag;
however you are free to create the package on your own.

Cheers

Ole

Re: Blends integration into the Debian Installer

[Ole Streicher]

Jonas Smedegaard <d...@jones.dk> writes:
> Quoting Ole Streicher (2016-05-24 10:55:13)
>> * what are their requirements to be listed in the default installation
>>   image?
>> 
>> * can they live with just *one* option as a compromise?
>
> For both debian-parl and debian-design it is a sensible compromise for 
> now to include only "parl-desktop" and skip region- or topic-specific 
> metapackages.

Could you put this into the tasks files of the blends?

Cheers

Ole

Re: Blends integration into the Debian Installer

[Ole Streicher]

Andreas Tille  writes:
>> That is probably the main driver here. Please note that this is now
>> "opt-in" as changed to resolve #825004.
>
> I realised this and just pushed the relevant change.

Great!

>> I will open wishlist bug reports for all blends mentioned in the web
>> page to clarify if and what they want to have in a default
>> installation.
>
> I think
>
> $ git diff HEAD^
> diff --git a/tasks/bio b/tasks/bio
> index fb086e9..9c7c6fe 100644
> --- a/tasks/bio
> +++ b/tasks/bio
> @@ -1,4 +1,5 @@
>  Task: Biology
> +Install: true

>
> will close the wishlist bug report against, Debian Med before you have
> filed it, right?

Yes, this is it :-)

I will ignore now debian-med in the bugreporting... :-)

Cheers

Ole

Re: Bug#825004: workaround for src:debian-edu for 825004 (was Re: Bug#793667: #793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading f

[Ole Streicher]

Holger Levsen  writes:
> On Tue, May 24, 2016 at 01:42:48PM +0200, Andreas Tille wrote:
>> I've seen Ole busy commiting changes to Git in the direction of
>> fixing this. :-)
>
> oh, cool, looking forward to those! :)

They are in the git already. Please do and allow some testing however
before we create a new release.

Cheers

Ole

Re: Blends integration into the Debian Installer

[Ole Streicher]

Andreas Tille <andr...@an3as.eu> writes:

> Hi Ole,
>
> On Tue, May 24, 2016 at 10:55:13AM +0200, Ole Streicher wrote:
>> in the alpha-6 relase of the debian installer, blends can selected for
>> the first time directly during installation [1]. This was implemented by
>> adding a blends-dev/debian-blends-tasks.desc file on a place where the
>> "tasksel" step can find it.
>
> That's *very* good news and might realise a dream I'm dreaming of more
> than 10 years. ;-)

Let's see if we can keep a good compromise here. I was a bit surprised
about the emotions and personalities that popped up in the discussion.

>> * what are their requirements to be listed in the default installation
>>   image?
>> 
>> * can they live with just *one* option as a compromise?
>> 
>> * if not: what needs to be done to get your requirement into the
>>   installer?
>> 
>> For Debian-Astro, I can (unsurprisingly) state that having one checkbox
>> only is a compromise that works. What about the others?
>
> For Debian Med it would be a big enhancement over not beeing mentioned
> in the installer at all. 

That is probably the main driver here. Please note that this is now
"opt-in" as changed to resolve #825004.

I will open wishlist bug reports for all blends mentioned in the web
page to clarify if and what they want to have in a default
installation.

> If we might have only a single selection option for Stretch we might
> even go with just the Biology part.  So in the end we could cope with
> a one option compromise to not make things more complicated than they
> need to be.

Could you put the "Install: true" tag into the task headers of the
debian-med package that should go into the default installation, and
edit the debian-blends-tasks.desc in the blends package to reflect the
selection you make?

Best regards

Ole

Re: Bug#793667: #793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading from Debian Edu squeeze mainserver)

[Ole Streicher]

Andreas Tille  writes:
>> thinking about it…: we can't do this, as changes have to be in sid
>> before they are accepted in stable. As we cannot have this change in sid
>> atm (#825004) we cannot really have this in jessie now neither… sigh.
>> 
>> So let's wait for a fix for #825004 first.
>
> Depending how fast you need a solution you could easily add another sed
> call in the new dist target to work around #825004.  Feel free to ask me
> for another patch.  Its not the best method to work around but it would
> definitely work.  I'd add a bit of documentation to the Makefile and
> also a README.source.  Just let me know if I should push this right into
> Git.

I reversed now the behaviour of the flags in blends-dev, so that tasks
are *only* installed if they have an "Install: true" in the
header. Also, the -all package is only created if there was any task
with the "Install: true". This should solve the problem, so that a
workaround is not needed.

I would, however, also change the debian-blends-tasks.desc so that the
"-all" file is the key (not the -tasks file, as it is in the
moment). This would disable all blends in the installer that haven't
anything to install yet. For Debian-Edu (and others wishing their own
solution here): please edit the file afterwards and put there whatever
should be in there.

Objections on that?

Best regards

Ole

Blends integration into the Debian Installer

[Ole Streicher]

Hi all,

in the alpha-6 relase of the debian installer, blends can selected for
the first time directly during installation [1]. This was implemented by
adding a blends-dev/debian-blends-tasks.desc file on a place where the
"tasksel" step can find it.

However, this causes a lot of discussion: the common complaint is that
it adds too much complexity to the "Software selection" step of the
installer [2]. My hope here is that the compromise would be to move the
blends selection onto a separate step that can be enabled by
f.e. checkbox on the first "Software selection" screen.

The other complaint is about the way the task are selected: currently,
all tasks of a blend are selected, with an opt-out possibility, and all
the blends we have on the web page are included.  The first one is
questioned [3], and changing the behauivour to opt-in will remove those
blends who do not do this step. IMO we should discuss these aspects (how
the integration is to be done, and how the selection of tasks is done)
in the two mentioned bugs.

However, there is a third aspect that came up with the discussion in [3],
and also appeared in a discussion with NeuroDebian: Some blends have the
requirement not just to install a "default" package selection but to
have a more detailed choice.

I must say that I have no idea how we ge this implemented in the current
situation (especially the discussion in [2]) -- in my opinion the
maximal compromise for the installer we can reach is to have *one*
option per blend. So this mail is to ask the blends on

* what are their requirements to be listed in the default installation
  image?

* can they live with just *one* option as a compromise?

* if not: what needs to be done to get your requirement into the
  installer?

For Debian-Astro, I can (unsurprisingly) state that having one checkbox
only is a compromise that works. What about the others?

I think we should somehow come up with an agreement on how we want to
see the blends presented in the (default) installer.

Best regards

Ole

[1] https://lists.debian.org/debian-devel-announce/2016/05/msg4.html
[2] https://bugs.debian.org/758116
[3] https://bugs.debian.org/825004

Re: #793667: forced depends (instead of recommends) using blends-dev

[Ole Streicher]

Petter Reinholdtsen  writes:
> The tasksel description files have a "Key" concept, which if I remember
> correctly is packages that must be available for the task to show up.
> As such they behave a bit like depends for metapackages, where the
> metapackage is uninstallable if some dependency is missing.
>
> Perhaps we can introduce a Key: keyword in the blends task files and map
> it to Key: in the tasksel description file and depends in the
> metapackage?  It would avoid breaking existing blends tasks and give us
> a way to enforce that a package is pulled in during upgrades.

We could map the (new) "Depends:" packages in the task to the Key:
list in the debian--tasks.desc file (and to Depends: in the
metapackage itself). This would prevent uninstallable tasks from showing
up.

> It would also introduce a hard dependency between a package and the
> task, exactly the kind of link we wanted to avoid when deciding to make
> all task packages recommends or suggests, so it should be used with care
> to avoid getting a task thrown out of testing needlessly when some nice
> to have but not vital package is removed from testing.

The proposal for debian-edu does exactly this: introduce a hard
dependency, with all its advantages and drawbacks. When looking into the
bug, this seems to be the intention.

Best regards

Ole

Re: #793667: forced depends (instead of recommends) using blends-dev (was gosa-plugin-netgroups not pulled-in when upgrading from Debian Edu squeeze mainserver)

[Ole Streicher]

Andreas Tille  writes:
> Since a long time I'm wondering whether we should craft tasks files to
> express what we "really" want (like specifying mostly all dependencies
> as "Recommends" and leave the "Depends" for what we really mean as
> Depends.  Since there are the frequently discusses drawbacks and
> compatibility issues with the current tasks files this is nothing that
> should be done quickly.

Why not? In my opinion it is quite straightforward, *and* we get a
documentation as a nice bonus: /read all imperatives below as "we should" ;-)/

* Create a document that describes the (new) format, and put it on
  blends.d.o. The first line of the new format should be
  "Format: http://blends.debian.org/tasks-format/1.0;

* Extend the parser in blends-dev and in webtools to recognise this line
  and use it as switch between current and new format

* Start to convert the own blends. This probably is as simple as a
  couple of simple sed scripts.

* Identify all build-depends of blends-dev, apply the sed scripts to get
  a patch, and file bug reports for them

This does not look like really difficult; probably the hardest part is
to review the current format. Aside from the changes

Recommends: --> Suggests:
Depends: --> Recommends:
new Depends: for real hard dependencies

I would f.e. propose to do as well in this step:

Pgk-Description: --> Description
Pkg-Url --> Url (or consequently use Homeppage:)

and would also include the changes needed to include a default selection
of packages as installation option for the Debian installer (currently
an optional "Install: false", but see bug #825004, and also see the
discussion in bug #758116).

These steps will make the change possible, bring inform the dependencies
nicely (with a patch) about the change, and finally allows to stick them
with the old format if there are good reasons for it (f.e. if the depend
on the old format elsewhere).

Unsolved in this scheme is the integration into the blends-dev document;
maybe it could just link to the document. If we create the format spec
in .rst or .md, we can easily also provide a web-readable version.

What do you think?

Best regards

Ole

Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Ole Streicher]

Hi Cyril,

On 21.05.2016 22:58, Cyril Brulebois wrote:
> I'm very much not happy with tasksel's picking up ", and I would very much 
> prefer if it
> would only look at its own debian-tasks.desc when running from the
> installer. Any objections?

Just to clarify this, since I was the one who actually did and uploaded
the change:

It was not my intention to hijack the installation process. In some
earlier mail on bug#758116, you mentioned that you cannot promise that
you don't know if/when you have time to look into the integration of the
Blends into the installer yourself [1]. For me, this sounds that we have
to do it ourself if we want to get it in. And I tried it openly: The
current solution was proposed in the bug#758116 [2], which was mirrored
to debian-boot@l.d.o, and I asked explicitly for comments before the
upload. Since no-one replied, I re-assigned the bug to src:blends (since
this was the proposed place to actually fix it) and uploaded the new
version with the package priority needed to get it into the basic system.

I feel now a bit unhappy that there was no discussion about the topic
before the upload, but I don't see what I could have done better
(otherwise please give me a hint so that I can learn from it). However,
as I said, that was not meant to be hijacking. If we find a better
solution that does not need to include the debian-blends-tasks.desc, we
can remove it. IMO it *is* however a good idea to keep tasksel using
everything it finds in /usr/share/tasksel/descs/; this enables a
relatively easy way to customize Debian here. Within Debian, we as a
community should be able to find a solution that does not need to secure
the installation process from "whatever people have managed to get into
a basic system".

Best regards

Ole

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#220
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758116#240

Bug#825004: blends-dev: undesired new Task $blend-all package

[Ole Streicher]

Hi Holger,

Am 22.05.2016 um 12:45 schrieb Holger Levsen:
> since 0.6.93 blends-dev creates a new $blend-all package which is *not*
> useful for all blends, so there should be a way to disable that.
> 
> In the case of debian-edu it creates an education-all package which
> depends on packages which conflict which each other (eg standalone and
> main-server, but there are more).
> 
> For the Debian Edu usecase such a $blends-all package must not be created.
> 
> Please make this behaviour optional and opt-in. As it stands this is a
> major regression on the usability of the package.

I am not sure whether I understand you specific problem correctly: Do
you want to have a way to select individual tasks, or a way to disable
it for the whole blend?

The first option is already there, although opt-out: You may specify an
"Install: False" in the task header, and the task will not be in the
list. The idea of opt-out was that usually our packages should not
conflict, and harddisk space is not expensive anymore. So having
additional unused packages is better than missing expected packages. But
this may be changed ofcourse, if we agree on that (I can live well with
both).

The second option (don't create the -all task at all) is not there yet.
It could be done implicitely: if all tasks have "Install: false" (resp.
no task has "Install: true" if we agree on this), then the -all task
would be empty and could just be not created. If you agree here, I could
it implement this way; but maybe I would need to request some help since
my Perl knowledge (the logic in blends-dev is implemented in Perl) is
!"§&&*'.

Disabling the -all package completely would however mean that in the
however-it-is-implemented "blends" selection during installation
(discussed in #758116), selecting this task would install no additional
packages, so it would probably wise to remove it there as well.

Best regards

Ole

Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Ole Streicher]

Hi Cyril,

Am 21.05.2016 um 23:11 schrieb Cyril Brulebois:
> so it would be nice to support all desc files shipped in tasksel-data
> rather than hardcoding debian-tasks.desc when the --internal-tasks-only
> flag is passed.

If you want to do it in the way it was proposed some days ago (move the
blends and the desktop choice into separate pages):

You could use a "Section" keyword in the tasks header: this is already
there for the structuration of tasks. Then the "main" task would just
display everything without a section, and one option for each section
(currently "Desktop Environment" and "Debian Pure Blends"). Enabling
these options leads to follow-up screens showing their content.

Aside from keeping the initial tasksel screen clean, this would also
naturally remove the confusing checkboxes that are currently on the
sections headers.

Best regards

Ole

Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Ole Streicher]

On 18.05.2016 10:58, Petter Reinholdtsen wrote:
> [Ole Streicher]
>> In my opinion, the situation for the Debian Pure Blends is better here
>> than for the Desktop environments: If a user doesn't know what the
>> Blends mean, he just ignores it and doesn't install anything from it.
> 
> An unskilled user do not ignore options he do not understand, he worries
> and tries to understand them in order to avoid making a mistake that
> will bother him in the future.  If you believe options that are unknown
> or confusing do not cause any harm, I am quite sure you are mistaken.
> They increase the cognitive strain and force people to spend time trying
> to understand that the option can be ignored.  They also slow down the
> installation process.

Again, this questiones the whole tasksel step during the installation:
As Christian points out, the majority of users doesn't understand what
"Desktop Environment" means, especially if is should decide whether he
needs "Cinnamon" or "Mate".

My own experiences are that I don't know anyone who understands the
"standard tools" item.

Compared to that, "DebiChem" is understandable: That has something to do
with chemistry. If the help would have been displayed, then he could
also know it. He then could also understand what a "Pure Blend" is. It
may help him to understand what a "Desktop environment" is. And maybe
someone finds a smart help text for the "standard tools".

If we really care that people should understand what they see, the first
issue *should* be to implement the help texts here.

> Note, I am not against the blends selection option during installation,
> but believe it should be introduced after taking the negative effects as
> well as the positive effects into account, not by claiming the negative
> effects do not exist.

I claim that they do not increase much. The issues are already there.

> There exist usability research indicating that more than 7 options will
> confuse the human brain and cause a lot of cognitive strain.  To me it
> tell us that we should avoid "just two screenfulls" of options, and
> instead try to make sure at most one screenfull, and preferably less
> than 7 options are presented in any dialog in the installer.

This is already violated in some steps of the installation. And we
already have 13 Blends; I don't see a good way to squeeze them into 7.

Best regards

Ole

Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Ole Streicher]

Hi Christian,

I agree that the best compromise would probably be to have a separate
page "Debian Pure Blends". But someone should implement this -- any
volunteers? I myself don't have enough Perl knowledge to do this.

However, I don't understand your rationale here:

Am 18.05.2016 um 07:25 schrieb Christian Perrier:
> At first, I'm not happy with the idea of Pure Blends tasks mixing up
> with standard tasks. I fully respect the work done by the variou
> sblends teams, but having our usual longstanding "standard" tasks
> kinda lost in the middle of "strange" and obscure tasks which the
> average user has no idea about what they're about...is a no-no for
> me.

The "standard" task is IMO one of the concepts in this step that
actually *nobody* understands: I myself don't know what it means, and
all the people I asked (when I presented the current scheme of
installing the blends) have no idea what happens if they (de)select this.

The help text in the tasks file (which is anyway not displayed in
tasksel) does not help: f.e. if I want to use Debian for web browsing
and e-mail, shall I install it? If I am a Java developer? The "standard"
task itself is "obscure"; IMO even more than an "DebiChem" task (where
already the name suggests that you don't need it if you are not
interested in chemistry).

> I still remember Joey's objections about *not* having users forced
> to choose between desktop environmentsbecause, contrary to what
> the average geek thinks, most people have no idea about what is a
> desktop environment. So, just imagine if we present them with
> "Hamradio", "NeuroDebian", "Debian Med" and such a list of unsorted
> strange things.

So, if the average user doesn't have a glue about a Desktop environment,
why is it offered in the installation by default? You seem to contradict
to your own arguments here.

In my opinion, the situation for the Debian Pure Blends is better here
than for the Desktop environments: If a user doesn't know what the
Blends mean, he just ignores it and doesn't install anything from it.
This will cause no harm -- he will just not get something he anyway
doesn't know about. But if a user doesn't understand what a "Desktop
environment" is and therefore decides to not install it, he may left
with an installation that he did not expect, and may have no chance to
correct this without external help. Therefore it may be better to hide
the desktop environment choice as well.

> That leaves us with the idea of a "Debian Blends" choice in the
> standard task menu, which would lead to a dedicated "blends" menu. I
> think this is the best compromise to do, provided we find a good name
> for the menu entry : "Debian Blends" or "Debian pure Blends" is a
> great name for the project in its entirety...but probably not for the
> menu entry. Again, because it means nothing to Joe User.
> 
> So, with something like "Special-purpose packages" or "Specialized 
> installations" or whatever along those lines, *then* a menu with the 
> Blends list (unsorted) and the possibility of going back just in
> case people see the list and think "heck, I have no idea about what
> this stuff is about"then I'd say this is the way to go.
> 

I personally don't have problems with changing this; however this would
open again the discussion about the names -- IMO we should be consistent
here. We can't call them "Specialized Installations" in the installer,
but "Debian Pure Blends" on the web page. Renaming would have a tail of
renaming it everywhere.

So, I would propose to explain the name and the concept in the
installer. There is already some text in the debian-blends-tasks.desc
that would help to explain it -- it should just be displayed. Again, it
would help much if tasksel would be able to display the help texts that
are already there, and IMO if the programming efforts are limited, we
would gain more in implementing help texts instead of separating the
blends from the desktop environments.

Best regards

Ole

Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Ole Streicher]

On 17.05.2016 13:29, Cyril Brulebois wrote:
> Ole Streicher <oleb...@debian.org> (2016-05-17):
>> I don't see it problematic as it is in the moment: The list is not too
>> long: Even if it does not fit on one screen, the rest is visible with
>> just one scroll, and this is indicated by the scroollbar. And I don't
>> think that the number of options is too much (it shouldn't be much more,
>> however).
> 
> Well, I suppose this is quite a reasonable thing for someone interested
> in having Debian Pure Blends in this menu to see it as non-problematic?

Could you explain why you think it is problematic? The list is still
short (less then two screens), the Blends are well-separated (as much as
possible with debconf), for the non-iterested everything is on the first
screen, and the scrollbar clearly indicates that there is more.

> First things first: I don't think what NeuroDebian wants is going to
> happen within d-i, no. Not the place, and we have package managers for
> that.

In the moment, they place icons on the desktop to allow users to install
the major packages they want. *This* is ugly, imo. And it shows that the
current installer lacks this support, even if you (and I, BTW) don't
need it here.

> I have no idea whether the following is practical, and/or makes sense
> regarding d-i's logic, etc., but I'm wondering whether it would be
> possible to have checking "Debian Pure Blends" activate a follow-up
> screen which would list all Blends.

In the current solution, people without the need to select a blend have
everything on the first screen, and only those who want to see all
blends are required to scroll down *once*. So, it requires the same (or
even less) interaction than your proposal.

It also needs no change in the installer at all. What I would much more
like to see would be some help texts -- currently one has to guess what
"Debian EzGo" means (or "standard system utilities"). It would be nice
if tasksel would actually display the detailed description that is in
the tasks pages.

Best regards

Ole

Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Ole Streicher]

Hi Wolfgang,

On 17.05.2016 11:52, Wolfgang Schweer wrote:
> On Tue, May 17, 2016 at 08:52:32AM +0200, Ole Streicher wrote:
>> On 17.05.2016 02:13, Cyril Brulebois wrote:
>>> I'm not sure how reasonable it is to have such a long list of meta
>>> packages in the installer. See attached tasksel-gtk-greyscale.png for
>>> the initial display with the graphical installer, and attached
>>> tasksel-text-greyscale.png for the text mode installer.
>>
>> I don't see it problematic as it is in the moment: The list is not too
>> long: Even if it does not fit on one screen, the rest is visible with
>> just one scroll, and this is indicated by the scroollbar. And I don't
>> think that the number of options is too much (it shouldn't be much more,
>> however).
> 
> I'm just wondering if the blend install could be implemented one level 
> higher using the ISO image isolinux menu structure.

The advantage of the boot menu would be that in the tasksel step, one
could select individual tasks for the selected blend, and not just a
default installation. This would, however, still not allow a selection
on the package level as it was requested for NeuroDebian.

This would however add all the 13 blends to the boot menu, making this
much more crowded. And it would be impossible to select two blends at
the same time (say: science and astro).

It would also feel the Blends as being more separated from Debian
itself: you could either install "Debian", or one of the Blends. The
tasksel approach would make clear what they are in reality: a
comprehensive selection of packages and (maybe) configuration for a
specific need.

I would opt for the current solution of having it in tasksel and not in
the boot menu; especially since it is now already implemented (after two
years of discussion), with all the infrastructure and needed changes in
blends-dev in place. IMO the better solution is now to push tasksel for
a better structured package selection.

> All blends would need their own debian--install-udeb and 
> debian--profile-udeb; these need to be on all official 
> Debian installation media if these should work like the mini.iso image. 

Extrapolating the slow development on the common blends-install subject
in the last years (especially in bug #758116), I would not expect this
to happen before the next release. The tasksel approach also has the
advantage that it is semi-centralized: all Blends get a default install
of all their tasks, and they may adjust this in their debian-
package if needed.

Best regards

Ole

Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Ole Streicher]

Hi Cyril,

thanks for your response.

On 17.05.2016 02:13, Cyril Brulebois wrote:
> I'm not sure how reasonable it is to have such a long list of meta
> packages in the installer. See attached tasksel-gtk-greyscale.png for
> the initial display with the graphical installer, and attached
> tasksel-text-greyscale.png for the text mode installer.

I don't see it problematic as it is in the moment: The list is not too
long: Even if it does not fit on one screen, the rest is visible with
just one scroll, and this is indicated by the scroollbar. And I don't
think that the number of options is too much (it shouldn't be much more,
however).

> Also, not sure about the (lack of) ordering in Debian Pure Blends.
> The Debian desktop environment submenu might be considered a bit special
> (esp. after the default desktop changes…), but I don't see why the DPB
> one should be unsorted. (See attached tasksel-unsorted-greyscale.png)

There is no specific order of the blends. One might think of some
structuring -- many blends are somehow science related, while others are
not --, but there is not much more to say about the internal structure.
And I have no idea how to get a better order even in this sense. In the
moment, they are alphabetically sorted, and this somehow reflects the
order they appear in the blends web page [1]. It also may help to find a
specific blend. Another idea would be to sort by popconn, but this is
not transparent to the end user. And, other than that, I see nothing
that would make list f.e. Debian Astro before or after DebiChem.

To improve that, two things have to be done: First, the tasksel
mechanism should allow ordered lists (in the moment, they are
automatically sorted as long as they have the same priority) -- please
open a bug report for this, if needed. Second, we need a good idea *how*
they should be actually ordered so that a specific blend can easily be
found. Do you have a proposal?

One problem here is the limited support of debconf for structures: there
is one (hackish) level of sections (eaten up by the "Debian Pure Blends"
section), but no folding or similar. Since this is discussed now over
years without anyone actually implementing an improvement here, I doubt
that that willbe changed before the next release, so we need something
that works in the current scheme (well, unless *you* volunteer to
implement this ;-) ). And I also think that for an installer, there
should not be too much structure, since this makes the installation too
complicated. On the other hand, the current implementation is criticized
by some blends, f.e. NeuroDebian, who wishes a specific selection up to
the package level here.

Do you have any proposals what should be changed?

Best regards

Ole


[1] https://www.debian.org/blends/

Re: [Neurodebian-devel] Neurodebian tasks (and Debian Science)

[Ole Streicher]

Hi Michael and Yaroslav, and all

Just making the mails a bit shorter... :-)

On 06.04.2016 15:49, Michael Hanke wrote:
> Yes, you got it right. Debian science is the reference. Anybody who cares
> should rightfully feel responsible.
> [...]
> No we don't generate the tasks from tags, the tags a generated from the
> tasks.

Then, in my opinion, it would make sense to

* create a neuroscience-tasks package with neurodebian as the maintainer

* move the following tasks to this package:
  (prefixed by neuroscience):

   - science-electrophysiology
   - science-neuroscience-modelling
   - science-neuroscience-datasets
   - science-psychophysics
   - science-neuroscience-congnitive

This would however still not solve my initial problem with a "default"
task. The point is that we will probably not succeed in having more than
a "default install" option for each blend in tasksel for Stretch (well,
unless someone really starts working on it), and you should decide if
and how you want to deal for NeuroDebian with it.

In any case, I would recommend to put NeuroDebian onto the Debian Blends
web page.

Best regards

Ole

Re: [Neurodebian-devel] Neurodebian tasks (and Debian Science)

[Ole Streicher]

Hi Michael,

On 06.04.2016 14:36, Michael Hanke wrote:
>> Some Fields in neurodebian seem not to have 1:1 tasks in 
>> debian-science: [...]
> Any discrepancy should be in favor of the non-neurodebian tasks, 
> everything else is an ommision/bug in our side.

>> The debian-science task "science-neuroscience-congnitive" has no 
>> corresponding "field" in neurodebian, but seems to belong there.
> Again, a core debian target is preferred, hence this is a non-issue 
> from my PoV.

I must say that I didn't fully understand that. From your point of view,
Who actually shall feel responsible) for these tasks? NeuroDebian? Do
you say that these Debian tasks are the reference, and if NeuroDebian
does not match it is a bug in NeuroDebian but not in Debian? This is at
least how I did understand you; please correct me if I am wrong.

>> Wouldn't it make sense to move out the specific tasks 
>> (science-electrophysiology. science-neuroscience-modelling, 
>> science-neuroscience-datasets, science-psychophysics, and 
>> science-neuroscience-congnitive) into the "neurodebian" package
>> (and remove it from debian-science)?

> If somebody does that and it doesn't imply a future increase in 
> perceived responsibility of "NeuroDebian" to maintain this former 
> debian-science task -- I am all for it.

The question here is (also) about responsibility. I guess you already
feel responsible for them, since you maintain, or "tag" them on your web
site already? Then it would IMO make perfect sense to extract them to a
separate package (resp. to the existing "neurodebian" package),
maintained by NeuroDebian.

> I am not convinced that the "install all at once" approach is an 
> actual selling point for a real user (NeuroDebian users that is).

You already do this for your VMs, right? If you were not convinced, you
would not offer those ;-)

> I personally consider the task association as a "tag", no more. And
> I do mostly care about the second part of 
> "science-neuroscience-cognitive" (neuroscience-cognitive), and much 
> less about the prefix -- unless it is obscene ;-)

So, let's omit the prefix completely :-)

> But again, if this leads to the collateral damage that people are 
> less likely to touch the task file because of this change of the 
> umbrella from science (general) to neurodebian (less general), this 
> would be a cost that I'd hate to pay.

Browsing the logs, these tasks are mainly unchanged in the last years.
There were some changes 2 years ago by Andreas Tille and by Yaroslav,
but after then they are unchanged. Therefore, I would rate the risk
higher that these tasks become unmaintained. A move to the neurodebian
package would IMO a step forward. If you generate them from tags, that's
perfect, it would keep them synchronous to your web site.

Would that make sense to you?

Best regards

Ole

Re: Neurodebian tasks (and Debian Science)

[Ole Streicher]

Andreas Tille  writes:
> And by the way: We should develop bootable images and default virtual
> machines based on the Blends tasks.  If Neurodebian would finally agree
> to this we might get more manpower to implement this.  (I wonder how
> often I mentioned that we should join forces amongst people who are
> doing in principle the same thing just for different fields ...)

If we get our tasks into the tasksel, we could have two very simple
solutions for a blends specific installer medium:

1. We could preseed the installation with just the instruction to
   tasksel to preselect a specific blend.

2. We could preseed the installation with an 
   "apt install $blend-tasks"
   This would push the individual tasks for the selected blend into the
   installer's tasksel, allowing a detailed selection for the blend.

In both cases, we could stay with the standard Debian setup, so if
someone knows how to create (or modify) a standard Debian CD to change
the preseed, we are already done.

Live-CDs and Virtual machines are different, however.

Best regards

Ole

Re: Neurodebian tasks (and Debian Science)

[Ole Streicher]

Yaroslav Halchenko  writes:
> Would any user ever want that particular selection of Recommended 
> packages?   may be, but I see that most often users would want a 
> particular selection from those pointed by Suggests and Recommends.

I think that both is useful. Sure, there are many users who want to have
a detailed list of choices and do an educated selection.

However, there are also reasons for a "simple" way: if one has no glue
where to start with, for example. Or if one has no time (or doesn't
spend it on a carefule package selection). Since today disk space is
cheap, I also tend to just install everything I *could* need -- as long
as there are not conflicts to expect (and Debian is pretty good with
this).

> Are you aiming to provide that level of granularity within debian 
> installer?  if so -- that would be cool.

Sure, I am also unstatisfied with the current state. There is currently
no way to select individual packages during the installation and also
not with tasksel, and I would guess that this will stay so for Debian
Stretch. However, once we have our "foot in the door" (that's probably a
"False Friend" in english), we have a good reason and pressure to get
something. We just need volunteers ;-)

But let's be pragmatic here. The proposed solution is not ideal, but it
is a step forward, and something realistic.

>> Wouldn't it make sense to move out the specific tasks (...) into
>> the "neurodebian" package (and remove it from debian-science)?
> 
> Do you consider neuroscience not a science? ;)  Or is debian-science 
> blend is solely to collect all other sciences which haven't 
> found/established their own blends? and as soon as they do, new 
> naming/packages arrive etc...

I see Debian Science as a kind of "umbrella" for

* blends that are connected to science.
* science tasks that still didn't find an own blend

So, my ideal structure of Debian science would be:

Debian Science
 +-- Debian Astro
 |   +-- Astrononomy Catalogs
 |   +-- Data Viewers
 |   :   ... packges specific to astronomy
 |
 +-- Debian Med
 |   :   ... packages specific to medicine
 |
 : ... other science blends
 |
 +-- Biology
 +-- Physics
 : ... other science tasks that are not in a specific blend

This would IMO also be the ideal structure to show in tasksel (which
does not work yet since tasksel allows only one level structure yet)

So, yes: if there is a new blend, it is time to sort out the
corresponding tasks, rename them etc. I did this when I created the
Debian Astro Blend: the two "traditional" debian-science tasks
"astronomy" and "astronomy-dev" are now moved to debian-astro, and split
of into a much finer granulated structure. There are just two
transitional packages left in debian-science to move existing
installations to the new structure.

> moreover many of those are not neuro- specific, and some times even 
> though used in neuro-, they might be used in other sciences (e.g. 
> consider electrophysiology -- it is not just neuroelectrophysiology)

In the moment (when looking into the package list)
science-electrophysiology *is* neuroelectrophysiology, so I would
propose to have it there.

This is also a question of maintenance; debian-science tasks tend to be
left alone in some cases. science-neuroscience-congnitive seems to be a
candidate for an orphaned task... I would rather love a maintained
neurodebian task than an unmaintained science task.

> that somewhat points to our "concern" with current approach on blends
> -- pretty much attempt to impose separate hierarchies wherever
> structure is more of a tag cloud (single software/task could be a
> part of multiple blends).

In theory this is true; however in the moment we don't have so many
blends that a hierarchy would be unsuitable. There already was some work
by Andreas Tille to cross-link between tasks (@Andreas: could you tell
the state here?), which would improve the situation here, and they are
IMO exceptions: "astro-education" and "edu-astronomy" are such examples.
Most of your "fields" are neuro specific, or don't have a counterpart
that is maintained in the moment.

> I am not sure what such a default blend should carry really... how 
> could I decide for a lab to use e.g. AFNI vs FSL vs [...]

Neurodebian already offers a bootable image, and a default virtual
machine -- so you already *have* some idea of a default installation.

Why not just take this?

I see two arguments for the solution with "default" installations:

1. Provide a simple, low-threshold installation that "just works" for
those who like or need this

2. Promote the blend(s). Everyone who installs Debian will see that
there is NeuroDebian (and Debian Astro etc.), and will think whether
this is something he could be interested in.

>> A "neurodebian-tasks" package would be useful as well so that 
>> people could use tasksel to install additonal NeuroDebian tasks (or
>> to remove them if not needed).

Sure. And, once there is some need, 

Re: [SCM] science branch, master, updated. 62a9741420de5201ef8c55e8db751b3709150359

[Ole Streicher]

Andreas Tille <andr...@an3as.eu> writes:
> On Tue, Apr 05, 2016 at 04:16:30PM +0200, Ole Streicher wrote:
>> My own experience while learning Debian is that "extra" is very often
>> chosen by mistake
>
> I share this feeling 100%.  I preached frequently on mailing lists and
> changed very frequently in team Vcs es from extra to optional.

The problem seems to be that this is somehow not always propagated to
the archive: for example the "erfa" package has "optional" priority
since its second release in d/control (2 years ago), but the package in
the archive still shows "extra". I have no idea why this is not
propagated.

*If* it would be propagated, in principle that would be a simple mass
bug filing for all packages that have "extra", but no "conflicts",
right? ("wishlist" ofcourse).

I however feel a bit unhappy with using "extra" packages to be installed
with the initial tasks selection, due to potential conflicts. If we just
ignore this problem, we could also ignore the policy here and let
"optional" debian-science tasks "recommend" packages with "extra".

Best

Ole

Re: [SCM] science branch, master, updated. 62a9741420de5201ef8c55e8db751b3709150359

[Ole Streicher]

Paul Wise <p...@debian.org> writes:
> On Tue, Apr 5, 2016 at 10:16 PM, Ole Streicher wrote:
>> Andreas Tille writes:
>>> I think the change of priority from extra to optional is wrong.  Per
>>> policy packages with priority optional can not Depend / Recommend
>>> packages with priority extra.  Since we have no way to control the
>>> priority of all dependencies the metapackages should remain at priority
>>> extra.  Alternatively the every single priority of metapackages needs
>>> to be set explicitly.
>>
>> OK, that is a good point; I didn' think on it. I'll just revert the
>> Priority to extra for the moment.
>
> IIRC the plan for optional/extra was to delete extra entirely. No idea
> what happened to that idea.

What was the alternative to deal with conflicting packages?

Best

Ole

Re: [SCM] science branch, master, updated. 62a9741420de5201ef8c55e8db751b3709150359

[Ole Streicher]

Hi Andreas,

Andreas Tille  writes:
> I think the change of priority from extra to optional is wrong.  Per
> policy packages with priority optional can not Depend / Recommend
> packages with priority extra.  Since we have no way to control the
> priority of all dependencies the metapackages should remain at priority
> extra.  Alternatively the every single priority of metapackages needs
> to be set explicitly.

OK, that is a good point; I didn' think on it. I'll just revert the
Priority to extra for the moment.

However, this may point to a potential problem with the Blends included
in tasksel: The policy guarantees that all packages with policy
"optional" are conflict-free, but this is not true for "extra" (in fact,
conflicts are probably the main reason to use extra). So, if we are
going to install via tasksel, there may be conflicts in the package
selection, which would be a really bad experience for someone who
installs Debian the first time. While formally the "tasksel" task
dependencies are no dependencies for the policy, in fact they are.

I would guess that with a "good feeling", we can only include tasks with
all Recommends as "optional" into the list for the default installation.
Another way would be to automatically lower the priority "extra"
packages in the tasks.

My own experience while learning Debian is that "extra" is very often
chosen by mistake (I think there are some templates of the debian subdir
that use "extra"). Could someone with good apt experiences post a
command line to find out the "Priority: extra" packages in the blends?
Getting this fixed where "optional" could be used would probably help to
see where we have real problems.

Best regards

Ole