Re: Minutes from the "32bit architectures in Debian"-bof
* Helmut Grohne (hel...@subdivi.de) [150831 16:49]: > On Thu, Aug 20, 2015 at 03:04:17PM +0200, Andreas Barth wrote: > > minutes from the "32bit architectures in Debian" bof right now. > > It is my understanding that it was also agreed that mips and mipsel > would be dropped as release architectures after stretch. Yet it seems > this was missing from the minutes. Adding it here and now. I can't remember that. I however can remember that we agreed that decisions about individual arches out-of-scope for that bof because we focuse on things that all 32bit arches have in common. (We spoke about that the 32bit arches might be dropped at some point in future, especially if there is no additional use, e.g. all hardware sold for some time is able to run the 64bit aquivalent, but that's something else than "agreed after stretch"). Andi
Re: Improving your archive and package system for small package
Hi! On Thu, 2015-09-03 at 17:28:38 +0200, Adrien CLERC wrote: > This may have been discussed before, but could we achieve something like > this with virtual package? With the implemented version Provides, which means having versioned virtual packages, this is actually probably a good solution, either to pack a collection of different upstream projects or a collection of versions for the same upstream project. Thanks, Guillem
Re: Script to generate common license texts
Quoting Balasankar C (2015-09-04 20:42:19) > On ശനി 05 സെപ്റ്റംബര് 2015 12:01 രാവിലെ, Jonas Smedegaard wrote: >> Quoting Balasankar C (2015-09-04 19:38:20) >>> Is there any script which takes abbreviation of a license (like >>> GPL-3+) as input and generates the license text that can be used in >>> debian/copyright (80 character wrapped, one space before each line, >>> paragraph separated with periods - the whole deal. >> >> Please beware that debian/copyright strings should reflect the actual >> _verbatim_ text stated by the copyright holders, not any generic >> _boilerplate_ proposed by e.g. the Free Software Foundation. > > Yeah. I know that. Why I asked for such a script is that some of the > packages I dealt with just mentioned "Released under XYZ license. > Copyright 20xx MNO" without any explicit license text (they should've, > but they don't) which means they just use the _boilerplate_ license > text that is commonly used. For example, many Ruby gems are Expat > licensed and use boilerplate text. Either upstream states actual licensing terms, or refer to external licensing terms. It seems we use the term "boilerplate" differently: I don't call it "boilerplate" when upstream states actual licensing terms (e.g. Expat written out rather than by reference). Upstream "should" do whatever they want - but yes, if upstream state licensing terms ambiguously then we cannot redistribute their project, so it makes sense to suggest them to clarify if we are uncertain what they mean (e.g. when stating "MIT" without URL or actual licensing terms - because that may refer to several different actual terms). When upstream states "Released under MIT." then a) the actual licensing terms are not included and b) actual licensing terms are uncertain. We then should add in debian/copyright the upstream statement verbatim, add the actual licensing terms - also verbatim, and ideally also add a comment on our reasoning for resolving license terms from license grant. When upstream states "Released under GPL 2." then terms are similarly not included but (arguably) certain. We then should again add in debian/copyright the upstream statement verbatim, and (because we can) refer to /usr/share/common-licenses/GPL-2. We do *not* need¹ to also add the boilerplate included in the GPL license text under the title "How to Apply These Terms to Your New Programs" - exactly because we are not creating a new program ;-) > The scripts would just be used to reduce the time in searching for the > _boilerplate_ text in the Internet (or other packages), and that too > only if the upstream doesn't provide any verbatim text. If by boilerplate you mean common sets of actual licensing terms (e.g. Expat) then true, it might be convenient with a tool that can spit out verbatim texts we do not ship below /usr/share/common-licenses. If by boilerplate you mean common _reference_ for sets of common licensing term (e.g. the FSF-recommended text for GPL licenses) then wrong: There is no need for adding such additional text to debian/copyright if upstream did not state it using those exact same words. Because such text is then neither verbatim copy of upstream statement nor actual licensing terms. > I fail to provide a general use case where this can be directly > applied, but to share one of my experiences I recently dealt with a > package that was released under W3C license (that only, no verbatim > text) and I spent quite some time searching for the license text to be > included in debian/copyright (not the complete license text, but > something like we have for GPL-3.0+ - the one I mentioned in my > original mail) If you have trouble locating actual licensing terms, then take that as indication that those reading the copyright file you are writing may have trouble too: When you've succeeded locating the actual licensing terms then consider add a comment on where you found them, and your reasoning for why that location is believed to be reasonably correct. Practivally, if you use the machine-readable copyright file format, then first line has a URL to a web page, which links to licenses at SPDX: http://spdx.org/licenses Hope that helps, - Jonas ¹ Lintian may warn about lack of GPL boilerplate in debian/copyright but that's because lintian is not clever enough to read human language which may correctly refer the the actual licensing terms in other ways than using the boilerplate recognizable by lintian: Suppress such warnings if certain the reference indeed does exist. -- * 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: Script to generate common license texts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On ??? 05 2015 03:53 , Jonas Smedegaard wrote: > Either upstream states actual licensing terms, or refer to external > licensing terms. It seems we use the term "boilerplate" > differently: I don't call it "boilerplate" when upstream states > actual licensing terms (e.g. Expat written out rather than by > reference). > > Upstream "should" do whatever they want - but yes, if upstream > state licensing terms ambiguously then we cannot redistribute their > project, so it makes sense to suggest them to clarify if we are > uncertain what they mean (e.g. when stating "MIT" without URL or > actual licensing terms - because that may refer to several > different actual terms). > > When upstream states "Released under MIT." then a) the actual > licensing terms are not included and b) actual licensing terms are > uncertain. We then should add in debian/copyright the upstream > statement verbatim, add the actual licensing terms - also verbatim, > and ideally also add a comment on our reasoning for resolving > license terms from license grant. > > When upstream states "Released under GPL 2." then terms are > similarly not included but (arguably) certain. We then should > again add in debian/copyright the upstream statement verbatim, and > (because we can) refer to /usr/share/common-licenses/GPL-2. We do > *not* need¹ to also add the boilerplate included in the GPL license > text under the title "How to Apply These Terms to Your New > Programs" - exactly because we are not creating a new program ;-) > > > If by boilerplate you mean common sets of actual licensing terms > (e.g. Expat) then true, it might be convenient with a tool that can > spit out verbatim texts we do not ship below > /usr/share/common-licenses. > > If by boilerplate you mean common _reference_ for sets of common > licensing term (e.g. the FSF-recommended text for GPL licenses) > then wrong: There is no need for adding such additional text to > debian/copyright if upstream did not state it using those exact > same words. Because such text is then neither verbatim copy of > upstream statement nor actual licensing terms. > > > > If you have trouble locating actual licensing terms, then take that > as indication that those reading the copyright file you are writing > may have trouble too: When you've succeeded locating the actual > licensing terms then consider add a comment on where you found > them, and your reasoning for why that location is believed to be > reasonably correct. > > Practivally, if you use the machine-readable copyright file format, > then first line has a URL to a web page, which links to licenses at > SPDX: http://spdx.org/licenses > > > Hope that helps, Cool. That makes it clear. Thanks. - -- Regards Balasankar C http://balasankarc.in -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJV6sPVAAoJEJbtq5sua3Fxe28H/1VcX248/4jdEaV0CrUvAecB +ubKPik8XWeiHsFDJS5PGo3ZOgYO3Xaj2+kA1GFMXGZFlWwwILK1xVqC5k+VLuIo uhvShB3rcuJzfrOlZo2rVkQbxMaZWeM638uq3ee6AHs0jyT4qb3hVONp/775LDT/ Lx34hDRMGPjIFhLJgLwXGsu+uTUOa1CYUcJJwc0z0umk6PqlVW4xt3eIQ7JK8YWj NrT5bOoEZvcHNQbnI6ATAVFKLL/Uc3P+K2RLeBVjfoE+QxzRuboO+H2cdG2C1TeD lyzXHdpcd2d68CepmLn32D0Hr4ki5lF0zuU3CKtvPbh9o0IRl/3bedXB6mA0qMk= =KssL -END PGP SIGNATURE- 0x2E6B7171.asc Description: application/pgp-keys
Re: Improving your archive and package system for small package
Hi! On Thu, 2015-09-03 at 13:26:12 -0700, Josh Triplett wrote: > Jonas Smedegaard wrote: > > Seems Osamu Aoki is working on at least part of the puzzle: > > https://bugs.debian.org/797045 > > Merging multiple sources *really* shouldn't be necessary. And the > metadata for those sources will vary, so that likely won't save that > much space. Well, there seems to be different kinds of overhead when it comes to extremely tiny packages (those with dozens or hundreds of lines of code). Metadata is one, amount of packages on the distribution, installed systems and files on the mirrors is another one. All the above involve in one way or another some overhead on at least the amount or size of source packages, binary packages, Sources and Packages indices, package manager databases and possibly increased dependency complexity, usage on disk after installation, inodes used on mirrors or installed systems, number of source VCS, etc. This can have a cost on the mirror network, buildds, on any team doing distribution wide work, such as the ftp-masters, release, porter, QA or reproducible teams, tools like lintian, autopkgtest, DUCK, VCS or watch checkers, britney, botch, etc. On maintainers having to maintain hundreds of similar tiny packages. Doing package collections in Debian might reduce part of the above overhead, but *if* this needs fixing, ideally it should be fixed upstream. Having to package 100 new upstream release updates instead of one is significant work, and that cannot be easily skipped if upstreams do not do the conglomeration themselves. > Perhaps we should add a few more things to common-licenses, or figure > out if our packaging metadata could be further reduced or de-duplicated. > It should be possible to package a 1kB library without several kB of > overhead. There are certain things that we could do to reduce overhead in some places, I don't think we can easily reduce most of the overhead anyway. For example each source and binary package contain a changelog, that's usually what takes most space. Even if we went with my proposal to store that and the copyright files in the dpkg database, that might only reduce some overhead on installed systems. > But even if we have to pay that overhead, so be it; we have > tens of thousands of packages already, what's a few hundred more tiny > JavaScript packages as long as they're actually used? If we were talking about few hundred packages, I don't think anyone would have much of an issue, I guess what people are worried about is this setting precedent and opening the flood gates. That's probably one of the reasons people have not tried to inject much of CPAN or CRAN or similar upstream archives into Debian even if I don't think those are as tiny as the ones proposed here, and most of it could be automated for example. Thanks, Guillem
Re: Script to generate common license texts
On 05/09/15 11:23, Jonas Smedegaard wrote:
> Quoting Balasankar C (2015-09-04 20:42:19)
>> Yeah. I know that. Why I asked for such a script is that some of the
>> packages I dealt with just mentioned "Released under XYZ license.
>> Copyright 20xx MNO" without any explicit license text (they should've,
>> but they don't) which means they just use the _boilerplate_ license
>> text that is commonly used.
>
> Either upstream states actual licensing terms, or refer to external
> licensing terms. It seems we use the term "boilerplate" differently: I
> don't call it "boilerplate" when upstream states actual licensing terms
> (e.g. Expat written out rather than by reference).
The three things the ftp-masters have stated the copyright file needs,
with their jargon names, are:
- the *copyright statement* (copyright holder, and dates if available)
- the *license grant* (statement by the copyright holder that you may
copy/modify the work under a specified license)
- the full text of the *license* (which may be replaced by a reference
to /usr/share/common-licenses if it is one of our common licenses)
The license grant is the statement by your upstream that tells you that
license A applies to work B. Some licenses (like the GPL and MPL) have a
conventional license grant ("boilerplate") that the license author
suggests should be used; but if your upstream has used a different form
of license grant, you should quote what your upstream actually said, not
the conventional boilerplate.
For short BSD-style licenses, the license grant and the license are
often the same thing: the conventional use is to paste the entire
license into each file. For longer licenses like the GPL and MPL, that
would be impractical, so authors put a short license grant in each file,
with a reference to full license text elsewhere.
For instance, take openarena-data:
Most of it is GPL-2 or GPL-2+, with several increasingly short license
grants. I refer to external GPL text because it is in common-licenses,
but if the license was something different (e.g. Creative Commons) then
I would have to quote the full license text instead.
A couple of files are under a simple all-permissive license, which is
included in the relevant files in its entirety (it's only three lines).
Those three lines have two roles: they are the license grant, and also
the full license text.
S
Bug#798087: ITP: python-poppler-qt5 -- Python binding to Poppler Qt5 C++ library
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: python-poppler-qt5 Version : 0.24.2 Upstream Author : Wilbert Berendsen * URL : https://pypi.python.org/pypi/python-poppler-qt5/ * License : LGPL-2.1+ Programming Lang: Python, SIP Description : Python binding to Poppler Qt5 C++ library Python binding to libpoppler-qt5 that aims for completeness and for being actively maintained. The bindings closely follow the C++ library API documented at http://people.freedesktop.org/~aacid/docs/qt5/ . More information: This is a continuation of Ryan Kavanagh 's great work on python-poppler-qt4 package, but now for Qt5. Its primary "user" in Debian is Frescobaldi the LilyPond sheet music editor, written by the same author, Wilbert Berendsen. I intend to maintain this package inside the Debian Python Modules Team (DPMT) and to have the python-poppler-qt5 source package reside on Alioth.
Re: [CTTE #741573] Debian Menu System
On Sat, 05 Sep 2015, Matthias Klumpp wrote: > 2015-09-05 3:49 GMT+02:00 Osamu Aoki : > > [...] > > >2. In addition to those changes, the Technical Committee resolves > > > that packages providing a .desktop file shall not also provide a > > > menu file for the same application. > > > > That's good idea in general. I hope lintian warning should come soon. > > > > This reminds me some DE dependent .desktop file. Is there any best > > practice how to do it for Debian? KDE app not showing up on GNOME and > > vice versa. How to decide how much .desktop data are NotShowIn for what > > environment? > > In general: Do not use NotShowIn/OnlyShowIn for most applications. > There are only a few areas where it is actually useful, and this is almost > exclusively configuration tools specific to one desktop environment. Maybe not even then: I certainly had to call some of the GNOME config tools in the past even when running KDE, as it also configures application/toolkit behavior. I did it from the command-line, though, so I do not recall if they did show on KDE's menus or not. Use of these directives really requires careful though about the implications. IMO, any use at all of NotShowIn/OnlyShowIn should be a lintian warning. I'd even call for it to be a lintian error that must be overriden in a case-by-case basis only after discussion in a relevant Debian ML, but this hides potential issues when abused, so it might not be a good idea. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Bug#798103: ITP: alter-sequence-alignment -- genomic sequences ALignment Transformation EnviRonment
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: alter-sequence-alignment Version : 1.3.3 Upstream Author : David Posada * URL : http://sing.ei.uvigo.es/ALTER/ * License : GPL, LGPL Programming Lang: Java Description : genomic sequences ALignment Transformation EnviRonment ALTER (ALignment Transformation EnviRonment) is a tool to transform between multiple sequence alignment formats. ALTER focuses on the specifications of mainstream alignment and analysis programs rather than on the conversion among more or less specific formats. Remarks: Due to the quite generic name ALTER the package is renamed to alter-sequence-alignment. The ALTER homepage advertises the program as web tool. Since the primary goal to package ALTER was alter.jar as predepencency of some Debian Med Java packages the web frontend is not included into the packaging. Feel free to ask the Debian Med packaging team if you are interested in this web frontend. The package is maintaines by the Debian Med team at git://anonscm.debian.org/debian-med/alter-sequence-alignment.git
GCC-5 transition will move to testing tonight
Hi, Thanks to Adam, Julien, Jonathan, Matthias, Scott, Simon and many others, we are ready to migrate the bulk of the GCC-5 transition and related sub-transitions to testing tonight. Apologise for the short notice. We expect this to be *mostly* a smooth ride, but there are some caveats: * We will have to remove some packages from testing temporarily * A total of 36 (amd64) / 31 (i386) binary packages will become uninstallable in testing. We kindly ask of your patience while the temporary breakage is being resolved. The situation will improve over the next couple of days as we can easier focus on the remaining issues. If your package got removed, it will re-enter testing as soon as it is eligible again. Please ensure your package has no RC bugs, can build on all architectures (were it built previously) and it should be back shortly. Once again, apologies for the short notice. Thanks, ~Niels signature.asc Description: OpenPGP digital signature
Re: GCC-5 transition will move to testing tonight
On 2015-09-05 21:25, Niels Thykier wrote: > Hi, > > [...] > We expect this to be *mostly* a smooth ride, but there are some caveats: > > * We will have to remove some packages from testing temporarily > > * A total of 36 (amd64) / 31 (i386) binary packages will become >uninstallable in testing. > >[...] That should have read: * A total of 36 (amd64) / *34* (i386) binary packages will become uninstallable in testing. Apologies for the mistake. Thanks, ~Niels signature.asc Description: OpenPGP digital signature
Re: GCC-5 transition will move to testing tonight
On 2015-09-05 21:25, Niels Thykier wrote: > [...] > We expect this to be *mostly* a smooth ride, but there are some caveats: > > * We will have to remove some packages from testing temporarily > > * A total of 36 (amd64) / 34 (i386) binary packages will become >uninstallable in testing. > > Thanks to Adam, we now also have the list of packages being uninstallable (by architecture): > > Newly uninstallable packages in testing: > * amd64: crtmpserver-dev, libboost-date-time1.55-dev, > libboost-date-time1.55.0, libboost-log1.55-dev, libboost-log1.55.0, > libboost-thread1.55-dev, libboost-wave1.55-dev, libboost-wave1.55.0, > libboost1.55-all-dev, libganv-dev, libgstreamermm-1.0-dev, > libopenconnect-dev, libopenimageio1.5, libphonenumber6, libphonenumber6-dev, > libplb-dev, libreoffice-subsequentcheckbase, libsdformat-dev, libsoqt4-dev, > libsynfig-dev, libtorrent-dev, liburdfdom-dev, libwxsqlite3-3.0-dev, > libwxsvg-dev, libxml++2.6-dev, lightspark, openstack-cloud-identity, > openstack-cloud-services, openstack-proxy-node, openstack-toaster > * i386: crtmpserver-dev, libboost-date-time1.55-dev, > libboost-date-time1.55.0, libboost-log1.55-dev, libboost-log1.55.0, > libboost-thread1.55-dev, libboost-wave1.55-dev, libboost-wave1.55.0, > libboost1.55-all-dev, libganv-dev, libgstreamermm-1.0-dev, > libopenconnect-dev, libopenimageio1.5, libphonenumber6, libphonenumber6-dev, > libplb-dev, libreoffice-subsequentcheckbase, libsdformat-dev, libsoqt4-dev, > libsynfig-dev, libtorrent-dev, liburdfdom-dev, libwxsqlite3-3.0-dev, > libwxsvg-dev, libxml++2.6-dev, lightspark, openstack-cloud-identity, > openstack-cloud-services, openstack-proxy-node, openstack-toaster > * arm64: cairo-dock, cairo-dock-dbus-plug-in-interface-vala, > cairo-dock-plug-ins, cairo-dock-tomboy-plug-in, crtmpserver-dev, innoextract, > libboost-date-time1.55-dev, libboost-date-time1.55.0, libboost-log1.55-dev, > libboost-log1.55.0, libboost-thread1.55-dev, libboost-wave1.55-dev, > libboost-wave1.55.0, libboost1.55-all-dev, libganv-dev, > libgstreamermm-1.0-dev, libopenconnect-dev, libopenimageio1.5, > libphonenumber6, libphonenumber6-dev, libplb-dev, libsdformat-dev, > libsoqt4-dev, libsynfig-dev, liburdfdom-dev, libwxsqlite3-3.0-dev, > libwxsvg-dev, libxml++2.6-dev, lightspark, psi4, python3-taglib, > ruby-passenger > * armel: crtmpserver-dev, libboost-date-time1.55-dev, > libboost-date-time1.55.0, libboost-log1.55-dev, libboost-log1.55.0, > libboost-thread1.55-dev, libboost-wave1.55-dev, libboost-wave1.55.0, > libboost1.55-all-dev, libganv-dev, libgstreamermm-1.0-dev, > libopenconnect-dev, libopenimageio1.5, libphonenumber6, libphonenumber6-dev, > libplb-dev, libsdformat-dev, libsoqt4-dev, libsynfig-dev, liburdfdom-dev, > libwxsqlite3-3.0-dev, libwxsvg-dev, libxml++2.6-dev, lightspark, > ruby-passenger > * armhf: crtmpserver-dev, libboost-date-time1.55-dev, > libboost-date-time1.55.0, libboost-log1.55-dev, libboost-log1.55.0, > libboost-thread1.55-dev, libboost-wave1.55-dev, libboost-wave1.55.0, > libboost1.55-all-dev, libganv-dev, libgstreamermm-1.0-dev, > libopenconnect-dev, libopenimageio1.5, libphonenumber6, libphonenumber6-dev, > libplb-dev, libsdformat-dev, libsoqt4-dev, libsynfig-dev, liburdfdom-dev, > libwxsqlite3-3.0-dev, libwxsvg-dev, libxml++2.6-dev, lightspark, > ruby-passenger > * mips: cairo-dock, cairo-dock-dbus-plug-in-interface-vala, > cairo-dock-plug-ins, cairo-dock-tomboy-plug-in, crtmpserver-dev, fwbuilder, > fwbuilder-dbg, libboost-date-time1.55-dev, libboost-date-time1.55.0, > libboost-log1.55-dev, libboost-log1.55.0, libboost-thread1.55-dev, > libboost-wave1.55-dev, libboost-wave1.55.0, libboost1.55-all-dev, > libganv-dev, libgstreamermm-1.0-dev, libopenconnect-dev, libopenimageio1.5, > libphonenumber6, libphonenumber6-dev, libplb-dev, libsdformat-dev, > libsoqt4-dev, libsynfig-dev, liburdfdom-dev, libwxsqlite3-3.0-dev, > libwxsvg-dev, libxml++2.6-dev, lightspark, plasma-desktop, ruby-passenger > * mipsel: crtmpserver-dev, libboost-date-time1.55-dev, > libboost-date-time1.55.0, libboost-log1.55-dev, libboost-log1.55.0, > libboost-thread1.55-dev, libboost-wave1.55-dev, libboost-wave1.55.0, > libboost1.55-all-dev, libganv-dev, libgstreamermm-1.0-dev, > libopenconnect-dev, libopenimageio1.5, libphonenumber6, libphonenumber6-dev, > libplb-dev, libsdformat-dev, libsoqt4-dev, libsynfig-dev, liburdfdom-dev, > libwxsqlite3-3.0-dev, libwxsvg-dev, libxml++2.6-dev, lightspark, > ruby-passenger > * powerpc: crtmpserver-deremove cantata/1.5.2.ds2-2 The list of (manually) removed packages are in the attached file along with a dd-list. ~Niels amarok guayadeque remuco flightgear simgear fgrun octave-bim octave-secs1d mysql-workbench libpadre-plugin-autoformat-perl libpadre-plugin-datawalker-perl libpadre-plugin-git-perl libpadre-plugin-moose-perl libpadre-plugin-parsertool-perl libpadre-plugin-pdl-perl libpadre-plugin-perlcritic-perl libp
Re: GCC-5 transition will move to testing tonight
On Sat, Sep 05, 2015 at 09:25:46PM +0200, Niels Thykier wrote: > Thanks to Adam, Julien, Jonathan, Matthias, Scott, Simon and many > others, we are ready to migrate the bulk of the GCC-5 transition and > related sub-transitions to testing tonight. Apologise for the short > notice. I continue to be impressed at the fine work the release team do for Debian. Based on conversations at DebConf I'd expected a much longer period of instability and lack of updates to testing. While I understand we're not out of the woods yet I'd like to thank everyone who's worked hard on dealing with this major transition. J. -- ] http://www.earth.li/~noodles/ [] Time is an illusion. Lunchtime[ ] PGP/GPG Key @ the.earth.li [] doubly so. [ ] via keyserver, web or email. [] [ ] RSA: 4096/0x94FA372B2DA8B985 [] [ signature.asc Description: Digital signature
Bug#798127: ITP: package -- native Go Zookeeper Client Library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org pkg-go-maintain...@lists.alioth.debian.org Owner: Dmitry Smirnov * Package name: golang-github-samuel-go-zookeeper Version : 0.0~git20150817.0.177002e-1 Upstream Author : Samuel Stauffer * URL : https://github.com/samuel/go-zookeeper * License : BSD-3-clause Programming Lang: Go Description : native Go Zookeeper Client Library signature.asc Description: This is a digitally signed message part.
Bug#798129: ITP: package -- Go language bindings for Apache Mesos
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org pkg-go-maintain...@lists.alioth.debian.org Owner: Dmitry Smirnov Control: block -1 by 798127 * Package name: golang-github-mesos-mesos-go Version : 0.0~git20150903.0.d98afa6-1 Upstream Author : Mesos * URL : https://github.com/mesos/mesos-go * License : Apache-2.0 Programming Lang: Go Description : Go language bindings for Apache Mesos Pure Go language bindings for Apache Mesos. As with other pure implementation, mesos-go uses the HTTP wire protocol to communicate directly with a running Mesos master and its slave instances. One of the objectives of this project is to provide an idiomatic Go API that makes it super easy to create Mesos frameworks using Go. signature.asc Description: This is a digitally signed message part.
Buen dia
Buen dia me gustaria suscribirme Marcos Jimenez
Re: GCC-5 transition will move to testing tonight
Quoting Jonathan McDowell (nood...@earth.li): > I continue to be impressed at the fine work the release team do for > Debian. Based on conversations at DebConf I'd expected a much longer > period of instability and lack of updates to testing. While I understand > we're not out of the woods yet I'd like to thank everyone who's worked > hard on dealing with this major transition. Indeed. It's quite some time that I witness this amazing work silently (less Debian, more running, you know the story) but I'm incredibly impressed. Kudos, folks (and all "big teams" such as Python packagers, Perl packagers, KDE team, etc.) for your work even though my favourite sports tracking application got killed for a few weeks because of the transition...:-)...and even though I sufferred quite painfully from the Plasma 5 transition, in unstable. signature.asc Description: Digital signature
Bug#798140: ITP: ruby-minitest-utils -- utilities for Minitest
Package: wnpp Severity: wishlist Owner: Balasankar C * Package name: ruby-minitest-utils Version : 0.2.4 Upstream Author : Nando Vieira * URL : https://github.com/fnando/minitest-utils/ * License : Expat Programming Lang: Ruby Description : utilities for Minitest
Bug#798141: ITP: python-abstract-rendering -- Rendering as a binning process
Package: wnpp Severity: wishlist Owner: Diane Trout * Package name: python-abstract-rendering Version : 0.5.1 Upstream Author : Joseph Cottam * URL : https://github.com/JosephCottam/AbstractRendering * License : BSD-3-Clause Programming Lang: Python Description : Rendering as a binning process In most visualization systems, the pixels are tucked away under levels of geometric abstraction in the rendering system (such as circles, squares, and text). Abstract Rendering takes the opposite approach: expose the pixels and gain powerful pixel-level control. This pixel-level power is a complement to many existing visualization techniques. It is an elaboration on rendering, not an analytic or projection step, so it can be used as epilogue to many existing techniques. This is a dependency for bokeh 0.9.3 (and probably later) I have my preliminary packaging at https://github.com/detrout/python-abstract- rendering Though I need to figure out how to adapt it for the python modules team.
