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

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

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

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 lea

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

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 t

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

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

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

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

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

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.

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

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

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

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 ?

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]

Next attempt to add Blends to Debian installer

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,

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

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

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

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: >

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

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 >>

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

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

Re: Comments regarding blends_0.7.0_amd64.changes

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. >

Re: Comments regarding blends_0.7.0_amd64.changes

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

Re: How to deal with static web pages

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

Re: Processing of blends_0.7.0_amd64.changes

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!

Re: Non-normalised field Provides in UDD table

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

Re: Non-normalised field Provides in UDD table

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, >> > b

Re: Non-normalised field Provides in UDD table

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-

Re: Non-normalised field Provides in UDD table

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

Re: Non-normalised field Provides in UDD table

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

Re: Non-normalised field Provides in UDD table

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 >

Re: New feature for 0.6.103

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"

Re: New feature for 0.6.103

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

Re: New feature for 0.6.103

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 diffe

Re: New feature for 0.6.103

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

Re: New feature for 0.6.103

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

Re: New feature for 0.6.103

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 >> >&

Re: New feature for 0.6.103

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 &

Re: New feature for 0.6.103

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

Re: New feature for 0.6.103

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

Accepted blends 0.6.103 (source) into experimental

nds@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 t

blend-gen-control and UDD

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

Re: New feature for 0.6.103

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

Re: Accepted blends 0.6.102 (source) into experimental

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

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

Accepted blends 0.6.102 (source) into experimental

nds@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 t

Re: Accepted blends 0.6.101 (source) into experimental

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 >> >

Re: Accepted blends 0.6.101 (source) into experimental

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 on

Re: Accepted blends 0.6.101 (source) into experimental

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

Re: Accepted blends 0.6.101 (source) into experimental

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

Re: Accepted blends 0.6.101 (source) into experimental

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

Accepted blends 0.6.101 (source) into experimental

nds@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 t

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

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 >&g

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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: > >

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

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, t

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

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

Re: Blends team on alioth created

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

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

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

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

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?

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

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

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

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.

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

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

Re: About the internal and external view of Blends

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

Bug#846002: Lowering severity

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

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,

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

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

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

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 sho

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

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

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

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 >>>

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

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 worr

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

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

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

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.

Re: Blends naming in the Debian installer

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

Re: Blends naming in the Debian installer

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 "

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

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

blends.debian.org moved to https

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

Re: Blends integration into the Debian Installer

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

Re: Blends integration into the Debian Installer

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-

Re: Blends integration into the Debian Installer

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 >>

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

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

Re: Blends integration into the Debian Installer

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 &g

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)

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

Blends integration into the Debian Installer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 sc

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

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 installe

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

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 >

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

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

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

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

Re: Neurodebian tasks (and Debian Science)

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

Re: Neurodebian tasks (and Debian Science)

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,

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

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 frequentl

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

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

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

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

  1   2   >