On Thu, Mar 22, 2018 at 12:15:44PM +0100, Ole Streicher wrote:
> >
> > 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.
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
Hi Ole,
On Thu, Mar 22, 2018 at 11:29:14AM +0100, Ole Streicher wrote:
> Control: affects -1 src:debian-astro
>
> On 22.03.2018 11:04, Andreas Tille wrote:
> > Control: severity -1 important
>
> Sure. Debian Astro the only one which is affected.
Thanks for confirming.
> I wrote:
> > In the
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
Control: severity -1 important
To work around the described problem it is sufficient to set
GENCONTROL_DEPENDS = false
(or simply not to set it inside Makefile at all == stick to the
current default)
Reducing the severity enables us to keep on using blends-dev as
is while we are discussing
Hi Ole,
On Fri, Mar 16, 2018 at 01:51:25PM +0100, Ole Streicher wrote:
> 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,
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
Hi Wolfgang,
thanks a lot for checking.
On Fri, Mar 16, 2018 at 12:07:28PM +0100, Wolfgang Schweer wrote:
> On Thu, Mar 15, 2018 at 07:41:30PM +0100, Andreas Tille wrote:
> > I've commited a fix to Git which for me creates now sensible Debian
> > Astro metapackages.
>
> I've checked how this
On Thu, Mar 15, 2018 at 07:41:30PM +0100, Andreas Tille wrote:
> I've commited a fix to Git which for me creates now sensible Debian
> Astro metapackages.
I've checked how this fix would concern Debian Edu:
(1) The Debian Edu Makefile has to be adjusted:
s/GENCONTROL_DEPENDS =
Hi Ole,
On Thu, Mar 15, 2018 at 05:14:36PM +0100, Andreas Tille wrote:
> > Feel free to lower the severity.
>
> I think there is no need to since I found the part of the code where the
> issue occures. If I would only understand Perl a bit better I would be
> ready with a fix. :-(
I've
Hi Ole,
On Thu, Mar 15, 2018 at 04:55:24PM +0100, Ole Streicher wrote:
> >
> >GENCONTROL_DEPENDS = true
> >
>
> Feel free to lower the severity.
I think there is no need to since I found the part of the code where the
issue occures. If I would only understand Perl a bit better I would be
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
Hi Ole,
On Fri, Feb 23, 2018 at 10:43:01AM +0100, Ole Streicher wrote:
> Package: blends-dev
> Version: 0.6.100
> Severity: serious
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
Hi Ole,
On Fri, Feb 23, 2018 at 01:32:17PM +0100, Ole Streicher wrote:
>
> 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.
Interestingly enough I can reproduce the issue for Debian
On 23.02.2018 14:00, Petter Reinholdtsen wrote:
> If the sources.list file do not list contrib and non-free, as any
> policy compliant task setup should, then no package from contrib and
> non-free will be listed as recommended in the resulting task
> package.
s/will/shall/
That is the problem.
Hi Ole,
On Fri, Feb 23, 2018 at 01:32:17PM +0100, Ole Streicher wrote:
> could you Cc your mails to the bug?
Ups, bounced ...
> 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?
>
>
Hi Ole,
On Fri, Feb 23, 2018 at 10:43:01AM +0100, Ole Streicher wrote:
>
> 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
>
[Andreas Tille]
>> 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.
>
> No. Recommends need to reside in main (per policy).
I believe I understand what both you and Ola
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
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
Hi Ole,
[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
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.
[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
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
24 matches
Mail list logo
