Re: Would be possible to have a ".treeinfo" file added to the installers' page?

[Paul Wise]

On Fri, Dec 7, 2018 at 9:07 PM Fabiano Fidêncio wrote:
> > http://ftp.debian.org/debian/dists/stretch/Release
>
> There's one problem with this file. It's not underneath the install tree URL.
> Our use case is that a user would provide an arbitrary install tree
> URL and we'd need to identify which OS it corresponds to. This
> arbitrary tree URL can be a mirror of the content on any 3rd party
> site.
>
> > http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/current/images/SHA256SUMS
>
> This one could be used if we'd have the "Description" entry as we do
> in http://ftp.debian.org/debian/dists/stretch/Release
> Do you think that adding the "Description" entry to the
> current/images/SHA256SUMS file would be easier/more secure than adding
> the ".treeinfo" file under
> http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/ ?

These two files are to be used together like this:

Fetch the Release/Release.gpg files (or InRelease).
Verify the OpenPGP signature.
Use the metadata in the Release file.
Get the path to the installer hash files from the Release file.
Download the installer hash files.
Verify the hash in the Release file matches the installer hash files.
Download the installer files you're interested in.
Verify the hash in the installer hash files matches the installer files.

If you had apt available to you, I think it could be made to do some
parts of this for you based solely on the sources.list file.

The other thing is that we generally don't expose the files you are
looking at to users, we generally recommend folks use the netinst ISO,
which is on another server altogether:

https://www.debian.org/
https://www.debian.org/distrib/
https://www.debian.org/CD/
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.6.0-amd64-netinst.iso

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Would be possible to have a ".treeinfo" file added to the installers' page?

[Fabiano Fidêncio]

On Fri, Dec 7, 2018 at 11:05 PM Colin Watson  wrote:
>
> On Fri, Dec 07, 2018 at 02:06:50PM +0100, Fabiano Fidêncio wrote:
> > Paul,
> >
> > > http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/current/images/SHA256SUMS
> >
> > This one could be used if we'd have the "Description" entry as we do
> > in http://ftp.debian.org/debian/dists/stretch/Release
> > Do you think that adding the "Description" entry to the
> > current/images/SHA256SUMS file would be easier/more secure than adding
> > the ".treeinfo" file under
> > http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/ ?
>
> The SHA256SUMS file is expected to be valid input to "sha256sum -c", so
> any extra metadata would have to live somewhere else.
>

Hmm. I see. :-/

So, what about the ".treeinfo" file suggestion? :-)

Having the ".treeinfo" suggestion would be easiest and more reliable
way for libosinfo (and, consequently, virt-manager/GNOME Boxes) to
consume the install trees. But we'd be more than happy if there was at
least one file, any file, under the install tree that we could
reliably parser in order to get the version we're dealing with.

One of the things we thought was to check
http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/current/images/MANIFEST.udebs
for "deb8", "deb9" ... but it's not reliable as there's not such
suffix for testing packages. More than that, even if it would for
Debian ... we'd have to have this very same discussion we're having
here with Ubuntu folks, while if something like the ".treeinfo"
suggestion is adopted, Ubuntu would also adopt that for free.

Best Regards,
-- 
Fabiano Fidêncio

Re: Would be possible to have a ".treeinfo" file added to the installers' page?

[Colin Watson]

On Fri, Dec 07, 2018 at 02:06:50PM +0100, Fabiano Fidêncio wrote:
> Paul,
> 
> > http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/current/images/SHA256SUMS
> 
> This one could be used if we'd have the "Description" entry as we do
> in http://ftp.debian.org/debian/dists/stretch/Release
> Do you think that adding the "Description" entry to the
> current/images/SHA256SUMS file would be easier/more secure than adding
> the ".treeinfo" file under
> http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/ ?

The SHA256SUMS file is expected to be valid input to "sha256sum -c", so
any extra metadata would have to live somewhere else.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Sending using my @debian.org in gmail

[Marc Haber]

On Thu, 6 Dec 2018 12:11:04 +0100, Raphael Hertzog
 wrote:
>
>On Tue, 04 Dec 2018, Marc Haber wrote:
>> >> If I could vote for which idea Debian mail admin time is dedicated
>> >> (which I cannot since Debian admins are volunteers and can choose what
>> >> to work on), I'd vote for better spam filtering on
>> >> @packages.debian.org and @alioth-lists.debian.net, probably using the
>> >> crossassassin mechanism that @lists.debian.org already uses.
>> >
>> I am not even sure whether @packages.debian.org is a regular mailing
>> list manager.
>
>*@packages.debian.org are just a plain aliases to maintainer emails (and
>to the package tracker).

... and is in dire need of better spam filtering.

>But when maintainer emails point to mailing
>lists, the above advice might still be relevant.

... the usual case for my packages since the demise of
lists.alioth.d.o is @p.d.o forwarding to the tracker.d.o

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

perl versioned Provides in sid again

[Niko Tyni]

Hi,

just a note that I've re-introduced versioned Provides in
perl/perl-base/perl-modules-5.28 with 5.28.1-3.  This was briefly in
sid in July 2017 but had to be reverted [1] due to infrastructure issues
(#867104 / wanna-build and #867081 / autopkgtest) back then. The issues
have since been fixed, so I'm hoping everything will Just Work this time.

Please let us know (via debian-perl@ldo, perl@pdo or otherwise) should
any issues emerge.

No immediate action is required from packages affected by this change,
but they can now gradually start moving from the current idiom
 Depends: perl (>= x) | libfoo-bar-perl (>= y)
to just the 'libfoo-bar-perl (>= y)' part. This will need some changes
to lintian recommendations as well.

See #758100 for more information on the change.

[1] https://lists.debian.org/debian-devel/2017/07/msg00111.html

Happy hacking,
-- 
Niko Tyni   nt...@debian.org

Re: Perl 5.28 transition underway

[Niko Tyni]

On Fri, Dec 07, 2018 at 04:34:48PM +0100, Cyrille Bollu wrote:
> The URL https://release.debian.org/transitions/html/perl5.28.html  is 404

Indeed. The correct one seems to be

 https://release.debian.org/transitions/html/perl.html

The havoc part of the transition is long over though, so no big matter :)
-- 
Niko

Re: Perl 5.28 transition underway

[Julien Cristau]

On 12/7/18 4:34 PM, Cyrille Bollu wrote:
> The URL https://release.debian.org/transitions/html/perl5.28.html  is
> 404 :-(
> 
With Perl 5.28 in testing, the transition is over.

Cheers,
Julien

Re: Perl 5.28 transition underway

[Cyrille Bollu]

The URL https://release.debian.org/transitions/html/perl5.28.html  is 404
:-(

BR,

Cyrille

Le mer. 31 oct. 2018 à 23:14, Niko Tyni  a écrit :

> I have uploaded Perl 5.28 to Debian unstable, starting a 500+ package
> transition. Wide uninstallability is to be expected in sid for the next
> few days until the necessary rebuilds have been completed. Please avoid
> unnecessary uploads of affected packages [1] until the transition is
> over and perl has migrated to testing. There is no need to submit bug
> reports against perl about the uninstallability of related packages
> during this transition.
>
> See the "perldelta" document [2] for information
> on upstream changes since 5.26.
>
> [1] https://release.debian.org/transitions/html/perl5.28.html
> [2] https://metacpan.org/pod/distribution/perl/pod/perldelta.pod
>
> Cheers,
> --
> Niko Tyni   nt...@debian.org
>

Re: Would be possible to have a ".treeinfo" file added to the installers' page?

[Fabiano Fidêncio]

Paul,

> http://ftp.debian.org/debian/dists/stretch/Release

There's one problem with this file. It's not underneath the install tree URL.
Our use case is that a user would provide an arbitrary install tree
URL and we'd need to identify which OS it corresponds to. This
arbitrary tree URL can be a mirror of the content on any 3rd party
site.

> http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/current/images/SHA256SUMS

This one could be used if we'd have the "Description" entry as we do
in http://ftp.debian.org/debian/dists/stretch/Release
Do you think that adding the "Description" entry to the
current/images/SHA256SUMS file would be easier/more secure than adding
the ".treeinfo" file under
http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/ ?

Best Regards,
-- 
Fabiano Fidêncio

Re: Would be possible to have a ".treeinfo" file added to the installers' page?

[Paul Wise]

On Fri, Dec 7, 2018 at 8:50 PM Fabiano Fidêncio wrote:

> Would you mind to point me to one of the apt repository metadata?
> I'd like to see its structure and what's the info provided (and mainly
> how we, as libosinfo, could fetch information about the kernel/initrd
> and OS version from there). If all the info is provided there, it may
> be the way to go.

http://ftp.debian.org/debian/dists/stretch/Release
http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/current/images/SHA256SUMS

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Would be possible to have a ".treeinfo" file added to the installers' page?

[Fabiano Fidêncio]

Paul,

On Fri, Dec 7, 2018 at 1:34 PM Paul Wise  wrote:
>
> On Fri, Dec 7, 2018 at 8:23 PM Fabiano Fidêncio wrote:
>
> > I sincerely don't know. But how is it different from accessing the
> > trees nowadays and hard-coding the paths to the kernel and initrd in
> > the apps?
>
> Accessing hardcoded URLs (to .treeinfo or other files) isn't a good
> idea in case they change.
>
> > For instance, 
> > http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/
> > isn't even available over TLS also.
>
> It is however protected in the same way all of the archive is, using
> OpenPGP signatures on the Release files and a hash chain to the files
> themselves.
>
> http://ftp.debian.org/debian/dists/stretch/Release
> http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/current/images/SHA256SUMS
>
> > So, not saying that we shouldn't care about MITM attacks, just trying
> > to understand how different the policy would be for this one file than
> > it currently is for the rest of the installer tree.
>
> If a .treeinfo were added for each of the installer directories, I
> assume it wouldn't be treated any different to the other files in
> those directories.
>
> > In any case, I'm more than happy to hear suggestions from the
> > community on how we could distinguish the installer trees on our side
> > if not using .treeinfo files.
>
> Personally, until something better exists (such as .treeinfo) I would
> be using the apt repository metadata. It seems to contain similar info
> to the example treeinfo you quoted anyway.

Would you mind to point me to one of the apt repository metadata?
I'd like to see its structure and what's the info provided (and mainly
how we, as libosinfo, could fetch information about the kernel/initrd
and OS version from there). If all the info is provided there, it may
be the way to go.

Best Regards,
-- 
Fabiano Fidêncio

Re: Would be possible to have a ".treeinfo" file added to the installers' page?

[Paul Wise]

On Fri, Dec 7, 2018 at 8:23 PM Fabiano Fidêncio wrote:

> I sincerely don't know. But how is it different from accessing the
> trees nowadays and hard-coding the paths to the kernel and initrd in
> the apps?

Accessing hardcoded URLs (to .treeinfo or other files) isn't a good
idea in case they change.

> For instance, http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/
> isn't even available over TLS also.

It is however protected in the same way all of the archive is, using
OpenPGP signatures on the Release files and a hash chain to the files
themselves.

http://ftp.debian.org/debian/dists/stretch/Release
http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/current/images/SHA256SUMS

> So, not saying that we shouldn't care about MITM attacks, just trying
> to understand how different the policy would be for this one file than
> it currently is for the rest of the installer tree.

If a .treeinfo were added for each of the installer directories, I
assume it wouldn't be treated any different to the other files in
those directories.

> In any case, I'm more than happy to hear suggestions from the
> community on how we could distinguish the installer trees on our side
> if not using .treeinfo files.

Personally, until something better exists (such as .treeinfo) I would
be using the apt repository metadata. It seems to contain similar info
to the example treeinfo you quoted anyway.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Would be possible to have a ".treeinfo" file added to the installers' page?

[Fabiano Fidêncio]

On Fri, Dec 7, 2018 at 1:23 PM Fabiano Fidêncio  wrote:
>
> On Fri, Dec 7, 2018 at 1:16 PM Paul Wise  wrote:
> >
> > On Fri, Dec 7, 2018 at 6:37 PM Fabiano Fidêncio wrote:
> >
> > > So, what I'm looking for is something like:
> > > http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/.treeinfo,
> > > where the .treeinfo would  have something like:
> >
> > None of the examples you have linked to or quoted appears to be
> > OpenPGP signed and some of them are not even available over TLS. I see
> > some of them do have cryptographic hashes though. Does treeinfo have
> > any protection against MITM attacks?
>
> I sincerely don't know. But how is it different from accessing the
> trees nowadays and hard-coding the paths to the kernel and initrd in
> the apps?
> For instance, http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/
> isn't even available over TLS also.
>
> So, not saying that we shouldn't care about MITM attacks, just trying
> to understand how different the policy would be for this one file than
> it currently is for the rest of the installer tree.
>
> In any case, I'm more than happy to hear suggestions from the
> community on how we could distinguish the installer trees on our side
> if not using .treeinfo files.

More into this one, please, take a look at
https://release-engineering.github.io/productmd/treeinfo-1.0.html

There it's specified that we could have the checksums to ensure that
the file provided is the one downloaded.
But, again, if someone takes over one of the servers, they can just
change the checksums and provide a different file. Although this
scenario is not related to having or not having a .treeinfo file.

Best Regards,
-- 
Fabiano Fidêncio

Re: git vs dfsg tarballs

[Paul Wise]

On Fri, Dec 7, 2018 at 7:48 PM Enrico Weigelt wrote:

> Have there been any cases where those files have been in the
> upstream VCS ? I don't recall any such case.

I assume most of the rejects from NEW would have this issue.

> For the case where certain parts shouldn't be built/shipped due to
> policy, this can - and IMHO should - be handled with changes within
> the VCS, instead of having tarballs laying around w/o any clear
> history and no indication how exactly it was created from upstream.

See Files-Excluded in Debian policy.

> Actually, since about a decade, I'm not doing any code changes outside
> git, and I'm building packages only directly from git. Frankly, I don't
> see any reason why that can't be the standard case.

The world is much less simple than that. There are people who don't
use version control systems, there are people who don't use git, there
are people who use version control systems that git cannot interface
with and there are people who invent new version control systems that
are meant to be better than git.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Would be possible to have a ".treeinfo" file added to the installers' page?

[Fabiano Fidêncio]

On Fri, Dec 7, 2018 at 1:16 PM Paul Wise  wrote:
>
> On Fri, Dec 7, 2018 at 6:37 PM Fabiano Fidêncio wrote:
>
> > So, what I'm looking for is something like:
> > http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/.treeinfo,
> > where the .treeinfo would  have something like:
>
> None of the examples you have linked to or quoted appears to be
> OpenPGP signed and some of them are not even available over TLS. I see
> some of them do have cryptographic hashes though. Does treeinfo have
> any protection against MITM attacks?

I sincerely don't know. But how is it different from accessing the
trees nowadays and hard-coding the paths to the kernel and initrd in
the apps?
For instance, http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/
isn't even available over TLS also.

So, not saying that we shouldn't care about MITM attacks, just trying
to understand how different the policy would be for this one file than
it currently is for the rest of the installer tree.

In any case, I'm more than happy to hear suggestions from the
community on how we could distinguish the installer trees on our side
if not using .treeinfo files.

Best Regards,
-- 
Fabiano Fidêncio

Re: git vs dfsg tarballs

[Wookey]

On 2018-12-07 12:48 +0100, Enrico Weigelt, metux IT consult wrote:
> On 21.11.18 04:22, Paul Wise wrote:
> 
> Actually, since about a decade, I'm not doing any code changes outside
> git, and I'm building packages only directly from git. Frankly, I don't
> see any reason why that can't be the standard case.

Just because you like a tool doesn't mean everyone does. I know I
understand patches and tarballs much better than I understand git, so
I prefer to use the former.

To answer your original question about DFSG differences, the
difference between upstream and the DFSG is normally defined by
'Files-Excluded' in the copyright file and compression/name
transformations in the watch file. It is for my packages, anyway.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Would be possible to have a ".treeinfo" file added to the installers' page?

[Paul Wise]

On Fri, Dec 7, 2018 at 6:37 PM Fabiano Fidêncio wrote:

> So, what I'm looking for is something like:
> http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/.treeinfo,
> where the .treeinfo would  have something like:

None of the examples you have linked to or quoted appears to be
OpenPGP signed and some of them are not even available over TLS. I see
some of them do have cryptographic hashes though. Does treeinfo have
any protection against MITM attacks?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Limiting the power of packages

[Enrico Weigelt, metux IT consult]

On 19.11.18 20:24, gregor herrmann wrote:
> On Mon, 19 Nov 2018 17:29:37 +0100, Enrico Weigelt, metux IT consult wrote:
> 
> (OT, but since I noticed it too:)
> 
>> Anyways, Skype doesn't work since 8.30 as it crashes directly on
>> startup.
> 
> Apparently it needs (e)logind since that version.

That didn't help neither.

Few days ago, I tried their inofficial preview build, which doesn't seem
to crash anymore. Let's see what happens when the official release
comes.


--mtx


-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Bug#915861: ITP: libsearch-elasticsearch-client-2-0-perl -- module to support elasticsearch in its 2.x version

[Laurent Baillet]

Package: wnpp
Severity: wishlist
Owner: Laurent Baillet 

* Package name: libsearch-elasticsearch-client-2-0-perl
  Version : 5.02
  Upstream Author : Clinton Gormley 
* URL : https://metacpan.org/pod/Search::Elasticsearch::Client::2_0
* License : Apache-2
  Programming Lang: Perl
  Description : module to support elasticsearch in its 2.x version

This module adds support for Elasticsearch server in version 2.x to
perl module libsearch-elasticsearch-perl

I will package it within the Debian Perl Team.

Re: git vs dfsg tarballs

[Enrico Weigelt, metux IT consult]

On 21.11.18 04:22, Paul Wise wrote:

> I don't think Andreas was talking about applying the DFSG but about
> files we don't have permission to distribute at all.

Have there been any cases where those files have been in the
upstream VCS ? I don't recall any such case.

For the case where certain parts shouldn't be built/shipped due to
policy, this can - and IMHO should - be handled with changes within
the VCS, instead of having tarballs laying around w/o any clear
history and no indication how exactly it was created from upstream.

Actually, since about a decade, I'm not doing any code changes outside
git, and I'm building packages only directly from git. Frankly, I don't
see any reason why that can't be the standard case.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Bug#915852: ITP: bagit -- Create and validate BagIt packages

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: bagit
  Version : 1.7.0
  Upstream Author : Ed Summers 
* URL : https://libraryofcongress.github.io/bagit-python/
* License : CC0
  Programming Lang: Python
  Description : Create and validate BagIt packages

bagit is a Python library and command line utility for working with
 `BagIt `__ style data packages.

A new dependency of cwltool. Will be team maintained by Debian-Med.

Re: Would be possible to have a ".treeinfo" file added to the installers' page?

[Antonio Terceiro]

On Fri, Dec 07, 2018 at 08:10:27AM -0200, Antonio Terceiro wrote:
> On Fri, Dec 07, 2018 at 10:45:31AM +0100, Fabiano Fidêncio wrote:
> > Howdy!
> > 
> > Firstly, sorry if I'm sending the message to the wrong mailing list.
> > If that's the case, please, point me to the right one.
> > 
> > Although the subject says it all, let me explain the background of the
> > change so you all can get the idea of why it'd help a few projects
> > and/or even come up with a better solution than adding a  ".treeinfo"
> > file.
> > 
> > I'm one of the maintainers of libosinfo[0], which is a project that,
> > basically, keeps info about OSes as such: the hardware they support,
> > the location for downloading ISOs, the location of online installation
> > trees, the minimum/recommended/maximum resources for an OS, scripts
> > for automating "JEOS"/"Desktop" installations and so on.
> > 
> > One of the APIs provided by libosinfo is to guess an OS from its
> > online installation tree and it's easily done by a treeinfo file like
> > the ones that can seen here[1], here[2] and here[3]. For the Debian
> > case however, as the ".treeinfo" file is not used, we're struggling
> > about having a reliable way to guess the OS from its tree because we
> > didn't find a specific file that we could try to inspect in order to
> > decide whether the installation tree is for debian7, debian8, debian9,
> > debian-testing ...
> 
> Does this work for you?

Just realized you meant the _installer_ files, so nevermind.


signature.asc
Description: PGP signature

Re: Would be possible to have a ".treeinfo" file added to the installers' page?

[Fabiano Fidêncio]

Antonio,

On Fri, Dec 7, 2018 at 11:10 AM Antonio Terceiro  wrote:
>
> On Fri, Dec 07, 2018 at 10:45:31AM +0100, Fabiano Fidêncio wrote:
> > Howdy!
> >
> > Firstly, sorry if I'm sending the message to the wrong mailing list.
> > If that's the case, please, point me to the right one.
> >
> > Although the subject says it all, let me explain the background of the
> > change so you all can get the idea of why it'd help a few projects
> > and/or even come up with a better solution than adding a  ".treeinfo"
> > file.
> >
> > I'm one of the maintainers of libosinfo[0], which is a project that,
> > basically, keeps info about OSes as such: the hardware they support,
> > the location for downloading ISOs, the location of online installation
> > trees, the minimum/recommended/maximum resources for an OS, scripts
> > for automating "JEOS"/"Desktop" installations and so on.
> >
> > One of the APIs provided by libosinfo is to guess an OS from its
> > online installation tree and it's easily done by a treeinfo file like
> > the ones that can seen here[1], here[2] and here[3]. For the Debian
> > case however, as the ".treeinfo" file is not used, we're struggling
> > about having a reliable way to guess the OS from its tree because we
> > didn't find a specific file that we could try to inspect in order to
> > decide whether the installation tree is for debian7, debian8, debian9,
> > debian-testing ...
>
> Does this work for you?
>
> on Debian 9:
>
> $ cat /etc/os-release
> PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
> NAME="Debian GNU/Linux"
> VERSION_ID="9"
> VERSION="9 (stretch)"
> ID=debian
> HOME_URL="https://www.debian.org/";
> SUPPORT_URL="https://www.debian.org/support";
> BUG_REPORT_URL="https://bugs.debian.org/";
>
> and on Debian unstable:
>
> $ cat /etc/os-release
> PRETTY_NAME="Debian GNU/Linux buster/sid"
> NAME="Debian GNU/Linux"
> ID=debian
> HOME_URL="https://www.debian.org/";
> SUPPORT_URL="https://www.debian.org/support";
> BUG_REPORT_URL="https://bugs.debian.org/";

Thanks for the answer! But, unfortunately, this is not related to what
I'm looking for. Your suggestion would work well for an *installed*
system. What we're trying to do is recognize an installation tree and
match it the OS that *will* be installed.

So, what I'm looking for is something like:
http://ftp.debian.org/debian/dists/stretch/main/installer-amd64/.treeinfo,
where the .treeinfo would  have something like:
```
[header]
version = 1.0

[release]
name = Debian Stretch
version = 9

[general]
arch = amd64
family = Debian
name = Debian Stretch
version = 9
platforms = amd64

[images-amd64]
kernel = current/images/netboot/debian-installer/amd64/linux
initrd = current/images/netboot/debian-installer/amd64/initrd.gz
```

With that, we (as libosinfo) could easily match which Debian version
we're dealing with and, even more, exactly know the location from
where we could fetch the kernel and the initrd in order to perform a
"tree" based installation.

Is it more clear now?

Best Regards,
-- 
Fabiano Fidêncio

Re: Would be possible to have a ".treeinfo" file added to the installers' page?

[Antonio Terceiro]

On Fri, Dec 07, 2018 at 10:45:31AM +0100, Fabiano Fidêncio wrote:
> Howdy!
> 
> Firstly, sorry if I'm sending the message to the wrong mailing list.
> If that's the case, please, point me to the right one.
> 
> Although the subject says it all, let me explain the background of the
> change so you all can get the idea of why it'd help a few projects
> and/or even come up with a better solution than adding a  ".treeinfo"
> file.
> 
> I'm one of the maintainers of libosinfo[0], which is a project that,
> basically, keeps info about OSes as such: the hardware they support,
> the location for downloading ISOs, the location of online installation
> trees, the minimum/recommended/maximum resources for an OS, scripts
> for automating "JEOS"/"Desktop" installations and so on.
> 
> One of the APIs provided by libosinfo is to guess an OS from its
> online installation tree and it's easily done by a treeinfo file like
> the ones that can seen here[1], here[2] and here[3]. For the Debian
> case however, as the ".treeinfo" file is not used, we're struggling
> about having a reliable way to guess the OS from its tree because we
> didn't find a specific file that we could try to inspect in order to
> decide whether the installation tree is for debian7, debian8, debian9,
> debian-testing ...

Does this work for you?

on Debian 9:

$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/";
SUPPORT_URL="https://www.debian.org/support";
BUG_REPORT_URL="https://bugs.debian.org/";

and on Debian unstable:

$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux buster/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/";
SUPPORT_URL="https://www.debian.org/support";
BUG_REPORT_URL="https://bugs.debian.org/";


signature.asc
Description: PGP signature

Would be possible to have a ".treeinfo" file added to the installers' page?

[Fabiano Fidêncio]

Howdy!

Firstly, sorry if I'm sending the message to the wrong mailing list.
If that's the case, please, point me to the right one.

Although the subject says it all, let me explain the background of the
change so you all can get the idea of why it'd help a few projects
and/or even come up with a better solution than adding a  ".treeinfo"
file.

I'm one of the maintainers of libosinfo[0], which is a project that,
basically, keeps info about OSes as such: the hardware they support,
the location for downloading ISOs, the location of online installation
trees, the minimum/recommended/maximum resources for an OS, scripts
for automating "JEOS"/"Desktop" installations and so on.

One of the APIs provided by libosinfo is to guess an OS from its
online installation tree and it's easily done by a treeinfo file like
the ones that can seen here[1], here[2] and here[3]. For the Debian
case however, as the ".treeinfo" file is not used, we're struggling
about having a reliable way to guess the OS from its tree because we
didn't find a specific file that we could try to inspect in order to
decide whether the installation tree is for debian7, debian8, debian9,
debian-testing ...

We also face the very same issue with Ubuntu's installation trees and
when approached they told us to firstly contact Debian and they'd be
happy to take the same direction taken by Debian.

So, would be possible to have the ".treeinfo" file added to the
installers' page? Is there any suggestion on any other path we could
take from our side?

[0]: https://libosinfo.org/
[1]: 
http://download.opensuse.org/pub/opensuse/distribution/leap/15.0/repo/oss/.treeinfo
[2]: http://mirror.vutbr.cz/fedora/releases/29/Server/x86_64/os/.treeinfo
[3]: http://mirror.centos.org/centos-7/7/os/x86_64/.treeinfo

Best Regards,
-- 
Fabiano Fidêncio

Bug#915835: ITP: libsearch-elasticsearch-client-1-0-perl -- module to support elasticsearch in its 1.x version

[Laurent Baillet]

Package: wnpp
Severity: wishlist
Owner: Laurent Baillet 

* Package name: libsearch-elasticsearch-client-1-0-perl
  Version : 5.0.2
  Upstream Author : Clinton Gormley 
* URL : https://metacpan.org/release/Search-Elasticsearch-Client-1_0
* License : Apache-2
  Programming Lang: Perl
  Description : module to support elasticsearch in its 1.x version

This module adds support for Elasticsearch server in version 1.x to
perl module libsearch-elasticsearch-perl

I will package it within the Debian Perl Team.