Re: [debian-mysql] Introducing default-mysql-* metapackages
Hello! 2016-08-16 7:44 GMT+03:00 Rene Engelhard : > On Sun, Jul 10, 2016 at 05:22:22PM +0300, Otto Kekäläinen wrote: >> Hello maintainers of packages that depend in MySQL/MariaDB! > > Not everyone is required to read -devel. Mailing them where they read > it (and be it Cc'ing them) would be better. > > I am subscribed to -devel but still missed this mail (though I knew there > was something ongoing) That is why we'll send a mail about this to debian-devel-announce soon to get more visibility. >> BEFORE: Build-Depends: libmysqlclient-dev >> AFTER: Build-Depends: default-libmysqlclient-dev >> >> BEFORE: Depends: mysql-server | virtual-mysql-server OR Depends: >> mariadb-server | virtual-mysql-server >> AFTER: Depends: default-mysql-server | virtual-mysql-server >> >> BEFORE: Depends: mysql-client | virtual-mysql-client OR Depends: >> mariadb-client | virtual-mariadb-client >> AFTER: Depends: default-mysql-client | default-mysql-client > > ITYM virtual-mysql-client :) Yes, sorry for the typo. >> If a maintainer knows that his/her package only works with one >> variant, then the package can depend directly on that package and not >> use the default-mysql-* (matches one) or virtual-mysql-* (matches any) >> schemes. Please get in touch if this applies to you. At the moment >> there should be no such packages, but in the future cases like this >> can arise when MySQL and MariaDB develop diverging feature sets. > > Well, I know of packages needing MySQL 5.7 and/or failing to build against > MariaDB for other reasons. e.g. mysql-connector-c++. Upstream is Oracle, > so they obviously won't care about MariaDB.. Yes, this scheme is very flexible and in cases like mysql-connector-c++ the package can depend explicitly on the MySQL package and not the default package. The same applies also for some packages that use features available in MariaDB but not available in MySQL. >> Packages built against default-mysqlclient-dev and link using >> "-lmysqlclient" will end up with a shared library dependency on either >> libmysqlclient.so.X or libmariadbclient.so.X depending on the default >> defined by the release team at build time. These will be provided by >> the libmysqlclient18 (soon to be libmysqlclient20) and >> libmariadbclient18 packages, which will be co-installable. Packages >> which require particular functionality available from only one of the >> forks may Build-Depend directly on libmysqlclient-dev or >> libmariadbclient-dev and then link using "-lmysqlclient" or >> "-lmariadbclient" respectively. Again, please get in touch if this >> applies to you. > > See above. > > So this one could still use libmysqlclient-dev? Yes > Or we keep a working version with MariaDB, but then again there's other > packages like mysql-workbench also wanting 1.1.7 (and thus MySQL 5.7)... I think mysql-workbench works just fine with MariaDB, it only complains about the version string not being what it assumes as it thinks 10.0 < 5.x and it requires 5.x or later. Somebody should patch mysql-workbench to do proper version string comparison. >> The default-mysql-* metapackages will be uploaded to Experimental soon >> and to Unstable once we are confident there are no regressions. Once >> they are available in Unstable, we will announce this on > > I have seen those accepted in unstable this morning so.. :) Yes, it was uploaded 12 hours ago. I didn't have time to announce it just yet. Stay tuned :)
Re: [debian-mysql] Introducing default-mysql-* metapackages
Hi, On Tue, Aug 16, 2016 at 11:36:15AM +0300, Otto Kekäläinen wrote: > Yes, this scheme is very flexible and in cases like > > mysql-connector-c++ the package can depend explicitly on the MySQL > > package and not the default package. OK. > > Or we keep a working version with MariaDB, but then again there's other > > packages like mysql-workbench also wanting 1.1.7 (and thus MySQL 5.7)... > > I think mysql-workbench works just fine with MariaDB, it only > complains about the version string not being what it assumes as it > thinks 10.0 < 5.x and it requires 5.x or later. Somebody should patch > mysql-workbench to do proper version string comparison. Sure, but TTBOMK it wants Connector/C >= 1.1.7 which then in turn needs libmysqlclient-dev 5.7. That was the point. I also think it should be able to _connect_ to a MariaDB then... Regards, Rene
Re: Base binary packages using xz instead of gzip
On Sat, Aug 13, 2016 at 01:55:48AM +0200, Guillem Jover wrote: > Some time has passed and the current situation in sid is this: > > COMP=xz → 158 packages > COMP=gz → 5 packages > > The ones using gzip are: > > base-files_9.6_amd64.deb > base-passwd_3.5.39_amd64.deb > dpkg_1.18.10_amd64.deb > mawk_1.3.3-17_amd64.deb > sensible-utils_0.0.9_all.deb Thanks for your analysis. I agree that this ship has comprehensively sailed, so I've removed the gzip override from base-passwd. -- Colin Watson [cjwat...@debian.org]
Re: copyright precision
On Tue, Aug 16, 2016 at 10:59:09AM +0500, Andrey Rahmatullin wrote: > > Not because we are legally bound to do so, but because we want to do our > > job as distributors properly. We appreciate good quality packaging! > It's at least worth a discussion whether nitpicking at d/copyright is > really helping the package quality at all, and if it's worth it. I would be interested in having numbers how frequently a d/copyright file is accessed by users (should be possible to do via popcon techniques). A recent example (seqan2, currently in NEW) where I needed to review lots of copyright statements seems that even upstream is not caring a lot. I've got an answer via private mail on my question for clarification[1] that most probably everything else than BSD is simply a remaining that nobody minded to change. In short: We have examples where a maintainer spents a lot of time into things that are matching our formal principles but do not match reality. In other words: We are serving our princinples but not our users. This is no vote to drop or relax our principles but sometimes some less strict handling might be helpful for all involved parties. BTW, the thread drifted away from copyright information of auto generated files in binary packages. Did I missed some conclusion we've found? Kind regards Andreas. [1] https://lists.debian.org/debian-med/2016/08/msg00066.html -- http://fam-tille.de
Re: copyright precision
Quoting Andrey Rahmatullin (2016-08-16 07:59:09) > On Tue, Aug 16, 2016 at 01:10:42AM +0200, Jonas Smedegaard wrote: >>> So yes, copyright files are hard and unfun but why should we >>> continue to write them the way we do if we are not legally bound to >>> do so? >> >> Same reason that we should continue to care about ability to install >> multiple major versions of a library concurrently, and that daemons >> are not only linked correctly but also sensibly configured and >> started by default. >> >> Not because we are legally bound to do so, but because we want to do >> our job as distributors properly. We appreciate good quality >> packaging! > It's at least worth a discussion whether nitpicking at d/copyright is > really helping the package quality at all, and if it's worth it. Certainly. # Bugfixing upstream licensing Some upstreams had misunderstood some details of what are legally required of them, and appreciate our pointing out when we spot it as part of our documenting it. Some upstreams thought they communicated their licensing intent, and appreciate our reporting back when we do not understand their message, or that in our view their message is incoherent² or clashes with the intent of some of _their_ upstreams³. ¹ E.g. GPL (without version) ² E.g. some parts GPL-2 (not GPL-2+) and some GPL-3 ³ E.g. OpenSSL vs. GPL (without OpenSSL exception). # Bugfixing our licensing Some linking within our own distribution have particular licensing needs, and our fellow package maintainers are then helped in their ensuring that by (not only reading _all_ involved source code, but also) cross-checking with the documentation done for each existing package. # Use of Debian Some downstreams have particular licensing needs, and are then helped in their ensuring those needs are properly met for the packages they choose to include. # Setting (not only following) standards Tracking copyright and licensing info is tiresome: It is manual work. Ideally copyright and licensing info is expressed machine-readable at the source - i.e. by each upstream, and tools rely on that - i.e. "make doc" would imply "make credit" using copyright statements as source for e.g. AUTHORS file, and "make install" would imply "make legal" using licensing info also of linked libraries as source of a validation). Some upstreams have adopted our debian/copyright format. Some use other machine-readable formats. But very few so far. Why? Our core business as distribution is to fuse together extreme amounts of projects, so obviously we feel the pain of tracking copyright and licensing info far stronger than each individual upstream project. Debian invented and is bound by the Debian Free Software Guidelines. Those do not try identify the least we *must* do legally - they define what we *want* Free software to be. Debian is famous for the DFSG, for covering many architectures and several kernels, for handling multiple concurrently installed architectures, for its long-term support, for handling multiple concurrently installed versions of same libraries, etc. etc. All of that is hard work at first where upstream projects have little recognition ot the benefit of supporting it, but has gained interest and is becoming easier as upstreams adopt the structures we (and others) propose. Please let's continue to lead the way: Because proper copyright and licensing is a crucial and integral part of Free software, and because Debian want that addressed technically sound rather than manually. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: copyright precision
On Tue, Aug 16, 2016 at 11:30:34AM +0200, Andreas Tille wrote: > > > Not because we are legally bound to do so, but because we want to do our > > > job as distributors properly. We appreciate good quality packaging! > > It's at least worth a discussion whether nitpicking at d/copyright is > > really helping the package quality at all, and if it's worth it. > I would be interested in having numbers how frequently a d/copyright > file is accessed by users (should be possible to do via popcon > techniques). I don't know use cases when an user would access it... > A recent example (seqan2, currently in NEW) where I needed to review > lots of copyright statements seems that even upstream is not caring a > lot. Sure, most upstreams don't care about licenses, that's one of the reason writing a d/copyright is harder than copying some clear list put together by the upstream. > In short: We have examples where a maintainer spents a lot of time into > things that are matching our formal principles but do not match reality. ... which is not just about d/copyright. > In other words: We are serving our princinples but not our users. This > is no vote to drop or relax our principles but sometimes some less > strict handling might be helpful for all involved parties. I'd happily vote to drop or relax some of our principles. -- WBR, wRAR signature.asc Description: PGP signature
Re: copyright precision
Scott Kitterman writes: > Personally, I think the bulk of the reason we should care about > debian/copyright is to achieve license compliance. For this, IMO the licensing information is not just enough, since it does not document how our binaries are licensed. For example, a source package may contain BSD and GPL licensed files -- how would you find out under which license a certain binary package may be distributed? It may be the case that a binary package was built using only the BSD licensed sources (and another binary package from the rest), so the assumption that everything is GPL is not necessarily valid. And how would you differ between f.e. a binary package produced with a gfortan build dependency from another produced with libreadline-dev (both GPL)? The first does not need to have the sources being GPL compatible, the second needs it. readline may be a border case, since the result is dynamically linked to libreadline, but this can not be a general assumption. If we need license compliance, we would need details about how our binary packages are licensed, and even then it can give just a first guess. Best regards Ole
Re: copyright precision
Andrey Rahmatullin writes: > It's at least worth a discussion whether nitpicking at d/copyright is > really helping the package quality at all, and if it's worth it. I see here another reason -- and an argument actually *for* Debian packaging (being different from, f.e. MacPorts or Conda): Detailed investigation of the upstream copyright, and the discussion with upstream, helps very much to improve to code quality (wrt. licensing). For my (science/astronomy) packages, it lead to quite many discussions with upstream, and finally to changes in their licensing scheme, which in turn makes it better for our community to bring our software together. I always use this as one argument when it comes to "Why should be care about Debian? Our users use something else", that packaging includes a careful review and documentation of the copyright. So, it is not just about packaging quality, but also about code quality in general. Best Ole
Re: copyright precision
Andreas Tille writes ("Re: copyright precision"):
> On Tue, Aug 16, 2016 at 10:59:09AM +0500, Andrey Rahmatullin wrote:
> > It's at least worth a discussion whether nitpicking at d/copyright is
> > really helping the package quality at all, and if it's worth it.
>
> I would be interested in having numbers how frequently a d/copyright
> file is accessed by users (should be possible to do via popcon
> techniques).
Anecdata:
Yesterday I looked at the copyright file for a package[1] I was
considering using in an AGPLv3+ project, in order to check whether the
package's licence was AGPLv3-compatible.
This approach wasn't successful. It was hard to determine the
effective licence of the package by looking in debian/copyright,
because debian/copyright was a portmanteau of copies of various
different licences.
In the end up looked at the package's upstream web pages, which
contained a clear answer to the question.
[1] Package will remain nameless because I don't have the effort to
double-check the details and write a proper bug report, and because I
don't want to generate makework bug reports.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: copyright precision
Jonas Smedegaard writes ("Re: copyright precision"):
> Quoting Markus Koschany (2016-08-15 23:02:06)
> > So yes, copyright files are hard and unfun but why should we continue
> > to write them the way we do if we are not legally bound to do so?
>
> Same reason that we should continue to care about ability to install
> multiple major versions of a library concurrently, and that daemons are
> not only linked correctly but also sensibly configured and started by
> default.
>
> Not because we are legally bound to do so, but because we want to do our
> job as distributors properly. We appreciate good quality packaging!
Does that justify REJECTing a package which is imperfect in this
respect, though ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#834512: ITP: google-android-platform-installers -- This is a packaged scripts that automatically downloads Google's Android SDK Platform packages and unpacks them into Debian-friendly paths.
Package: wnpp Severity: wishlist Owner: Mouaad Aallam * Package name: google-android-platform-installers Version : 1470833400 Upstream Author : Google, Inc * URL : https://developer.android.com/index.html * License : public-domain Programming Lang: C, Java, Bash, Python Description : This is a packaged scripts that automatically downloads Google's Android SDK Platform packages and unpacks them into Debian-friendly paths. Target : contrib Google's Android SDK Platform Installer This package will download the Google's Android SDK Platform packages and unpacks them into Debian-friendly paths. . Every Google's Android SDK Platform package includes android.jar file with fully compliant Android library. In order to build an Android app, the SDK platform must be specified as build target. . WARNING: Installing this Debian package causes archives to to be downloaded from dl.google.com and/or from other suggested mirrors. The End User License Agreement of this binary package is available at developer.android.com.
Re: copyright precision
Quoting Ian Jackson (2016-08-16 15:32:19)
> Andreas Tille writes ("Re: copyright precision"):
>> On Tue, Aug 16, 2016 at 10:59:09AM +0500, Andrey Rahmatullin wrote:
>>> It's at least worth a discussion whether nitpicking at d/copyright
>>> is really helping the package quality at all, and if it's worth it.
>>
>> I would be interested in having numbers how frequently a d/copyright
>> file is accessed by users (should be possible to do via popcon
>> techniques).
>
> Anecdata:
>
> Yesterday I looked at the copyright file for a package[1] I was
> considering using in an AGPLv3+ project, in order to check whether the
> package's licence was AGPLv3-compatible.
>
> This approach wasn't successful. It was hard to determine the
> effective licence of the package by looking in debian/copyright,
> because debian/copyright was a portmanteau of copies of various
> different licences.
>
> In the end up looked at the package's upstream web pages, which
> contained a clear answer to the question.
How was the approach¹ not successful? Didn't you succeed in realizing
that the package you looked at had complex licensing?
Would you have called it succesful if same package had simply told you
"AGPL-3+" instead?
Reason I ask like that is that in my understanding, some in this thread
sugges that Debian should do only what is legally required, which
arguably is what e.g. Fedora is practising (because they have legally
survived with that pracice, even if technically way too superficial).
Let's take a concrete example, with name (I maintain that package, so
blame me for any faults!):
Ghostscript ships with a LICENSE file of 70 lines, stating that main
parts are AGPL-3+, most fonts are AGPL-3+ with an exception, and various
other details.
Ghostscript packaged for Debian has a debian/copyright file with ~400
lines enumerating which source files are covered by which license (and
then another ~800 lines covering the actual licenses verbatim).
Fedora apparently covers the Ghostscript license in a single line:
"AGPLv3+ and Redistributable, no modification permitted".
- Jonas
¹ I understandt that you failed in getting the _result_ you hoped for.
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: copyright precision
Jonas Smedegaard writes ("Re: copyright precision"):
> Quoting Ian Jackson (2016-08-16 15:32:19)
> > In the end up looked at the package's upstream web pages, which
> > contained a clear answer to the question.
>
> How was the approach¹ not successful? Didn't you succeed in realizing
> that the package you looked at had complex licensing?
No. It was far from obvious that the effective licence was actually
quite simple and indeed compatible with AGPLv3+ as I required.
> Ghostscript ships with a LICENSE file of 70 lines, stating that main
> parts are AGPL-3+, most fonts are AGPL-3+ with an exception, and various
> other details.
>
> Ghostscript packaged for Debian has a debian/copyright file with ~400
> lines enumerating which source files are covered by which license (and
> then another ~800 lines covering the actual licenses verbatim).
If I want to know which source files are covered by what licence, I am
working with the source code already and can just look in the relevant
files.
Normally what a potential user needs to know is the effective licence
of the whole thing.
In the case of something like Ghostscript, which copies bits of itself
(in this case, fonts) into its output, you also need to know what
effect this might have on the license of those outputs.
> Fedora apparently covers the Ghostscript license in a single line:
> "AGPLv3+ and Redistributable, no modification permitted".
I assume "AGPL-3+ with an exception" is AGPLv3+ with what is usually
termed an `additional permission'.
I also assume that Debian's Ghostscript does not contain anything
which is "Redistributable, no modification permitted".
It seems to me that your summary in this email is likely to be more
useful than what is in debian/copyright.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: copyright precision
On 16/08/16 16:21, Jonas Smedegaard wrote: Quoting Ian Jackson (2016-08-16 15:32:19) Ghostscript packaged for Debian has a debian/copyright file with ~400 lines enumerating which source files are covered by which license (and then another ~800 lines covering the actual licenses verbatim). Fedora apparently covers the Ghostscript license in a single line: "AGPLv3+ and Redistributable, no modification permitted". Arguably, this is not according to the Fedora GL which states that if there are multiple licenses there should be a comment in the spec defining which license applies to what. This can be a simple one-liner (the simple case) or a per-file license breakdown. The fedora-review tool (usually) used when reviewing new packages creates a list for this purpose. I guess that in this case the spec should be read "Everything is AGPL besides the firmware, which is redistributable/dont-modify". Something like this should thus be really included in the spec as a comment. Coming from Fedora, I tend to think that this policy isn't that bad, adhering to the keep-it-simple rule ;) Cheers! --alec
Re: copyright precision
Quoting Ian Jackson (2016-08-16 15:32:55)
> Jonas Smedegaard writes ("Re: copyright precision"):
>> Quoting Markus Koschany (2016-08-15 23:02:06)
>>> So yes, copyright files are hard and unfun but why should we
>>> continue to write them the way we do if we are not legally bound to
>>> do so?
>>
>> Same reason that we should continue to care about ability to install
>> multiple major versions of a library concurrently, and that daemons
>> are not only linked correctly but also sensibly configured and
>> started by default.
>>
>> Not because we are legally bound to do so, but because we want to do
>> our job as distributors properly. We appreciate good quality
>> packaging!
>
> Does that justify REJECTing a package which is imperfect in this
> respect, though ?
Good question. Thanks for bringing me back to the start of this thread
:-)
No, not categorically: That unfairly punishes¹ packages improving their
info.
But I strongly believe we should not stop caring either.
Similar to how we strongly encourage use of proper SONAME even if not
done upstream, or readily working daemon config - but do not mandate it:
It seems realistic to me that we raise the bar in the future, e.g. by
tagging those daemons and libraries being excellent, and similarly those
copyright files with full machine-readable coverage.
- Jonas
¹ netatalk is missing from Jessie solely due to improved licensing info
otherwise unnoticed for 15 years: https://bugs.debian.org/751121
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: copyright precision
On Tue, Aug 16, 2016 at 03:25:24PM +0100, Ian Jackson wrote: > Normally what a potential user needs to know is the effective licence > of the whole thing. Note that we don't even try to declare the license of *binaries we are shipping* and, unless I'm mistaken, the license of a library you are going to link against is the main (the only?) license-related thing interesting to an user. And, I suspect, we have binaries in the archive whose licenses are different from the licenses of their sources. -- WBR, wRAR signature.asc Description: PGP signature
Re: copyright precision
On Tue, Aug 16, 2016 at 02:30:58PM +0200, Ole Streicher wrote: > I always use this as one argument when it comes to "Why should be care > about Debian? Our users use something else", that packaging includes a > careful review and documentation of the copyright. Usually only for the initial upload, though. -- WBR, wRAR signature.asc Description: PGP signature
Re: copyright precision
Quoting Andrew Shadura (2016-08-16 19:57:05)
>
>
> On 16 August 2016 at 14:32, Ian Jackson
> wrote:
> > Jonas Smedegaard writes ("Re: copyright precision"):
> >> Quoting Markus Koschany (2016-08-15 23:02:06)
> >> > So yes, copyright files are hard and unfun but why should we continue
> >> > to write them the way we do if we are not legally bound to do so?
> >>
> >> Same reason that we should continue to care about ability to install
> >> multiple major versions of a library concurrently, and that daemons are
> >> not only linked correctly but also sensibly configured and started by
> >> default.
> >>
> >> Not because we are legally bound to do so, but because we want to do our
> >> job as distributors properly. We appreciate good quality packaging!
> >
> > Does that justify REJECTing a package which is imperfect in this
> > respect, though ?
>
> I wish it wouldn't. I'm struggling packaging GPLv3 software for which I
> am also an upstream, Kallithea, as it depends on a bunch of free
> software JavaScript libraries. However, using them in a Proper Way is
> such amount of work none of my comaintainers nor I have managed to
> complete in two years. I attempted to upload what I have during DebConf,
> and (obviously) my upload was REJECTed.
I highly suspect that you are talking about something else than me here.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#834544: ITP: dh-copyright -- debhelper extension to aid in tracking copyright and licensing info
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: dh-copyright Version : 0.0.1 Upstream Author : Jonas Smedegaard * License : GPL-3+ Programming Lang: Perl Description : debhelper extension to aid in tracking copyright and licensing info dh-copyright provides a debhelper sequence addon named 'copyright' and the command dh_copyright. . The dh_copyright command uses licensecheck to check sourcecode of a package and compares the result against an existing machine-readable debian/copyright file. The package will be maintained in the build-common team. -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJXs5M3AAoJECx8MUbBoAEhFaUP/2VRM93SyT5Q0m+LeTwcYyvP dHBdcs6o9g67nSeJyi0b1E9tgbVPxnvqXdg1hTd8v9YGdXlxpyiA2Cg1VnAUMnP1 9cRK1NDU2EGCyrSHjmDlb4nJRkxjke/z0CyRrZy4DzYelMTQNATifzn/kc5x0JBP 7F5k9CLGNUTyaZlDKct2RcduqSxlpRNG8LwNRcBOD4cMPx8qoGDA6v7yNVb2+FSo WHr8xruB1dZ3v3Ezk4IZystlwreSiaOz2zv5G5iak/C2d5nfQ2c97cZpbGK8/rYZ mkYP8rfA+wWw3HUQjv30ZuLe8ivqx/XJYeDvNzngEk2N8Y8/bhYDTq0N+dUxDYia b79kybxNjFVM2ebQxk5sTL/pBhJ+a93M6PrwE8t6YQHfTl6hewFs+eNyVyGF9nGy uXwPhVCHeymI5bLkLAmP02ntW79lmi60qe1VHk9fnxdmsU1HHDX6dFVQtfKfEchu MbuX1sI13j9qotUC9EjunQQJ7FtgKBEhyy9dN9QOAmhJTsWiOOELRgnJnbHzHFNq vl8kilS8y7IL95FKKETstlvxZ8WrH+q/cQ4CP0DT0F4zXM6xu+b6di4pCcw7JFyB /iYCbO7NHnEtWOpqHLCf5eJA6i/MyLUGqi7X/GD9pKDFFIaPX2aNWHuDDiKIdYNt J5t2i60GmZjrJB1dZRrN =wj0T -END PGP SIGNATURE-
Re: Please, provide a fixed Cloud Image URL for Debian
Hi, On Wed, Aug 10, 2016 at 05:58:05PM -0400, Martinx - ジェームズ wrote: [..snip..] > Debian 8.5 image URL: > > > > http://cdimage.debian.org/cdimage/openstack/8.5.0/debian-8.5.0-openstack-amd64.qcow2 > > This image will be gone, soon as Debian launches 8.6.0!!! This is bad. > > > So, can Debian provides something like this: > > > http://cdimage.debian.org/cdimage/openstack/8/debian-8-openstack-amd64.qcow2 > that always points to the latest stable release image of 8 series (Jessie)? I've filed a bug about this a while ago (regarding the CD/DVD images in this case) since it affects libosinfo as well: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813797 Cheers, -- Guido
