Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
i remembered a couple more: * the freescale iMX6 has a 19-year supply / long-term support (with about another 10 years to go). it's used in the bunnie huang "Novena Laptop" and can take up to 4GB of RAM. processor core: *32-bit* ARM Cortex A9, in 1, 2 and 4-core SMP arrangements. * the Zync 7000 series of FPGAs. they're typically supplied with 1GB RAM on developer kits (and sometimes with an SODIMM socket), and are extremely useful and powerful. processor core: *32-bit* Dual-Core ARM Cortex A9 @ 800mhz. these (as well as the other 32-bit SBCs i mentioned, particularly the ones that work with 2GB of RAM) are not "shrinking violets". they're perfectly capable of running a full desktop GUI, Libre Office, web browsers, Gimp - everything that the "average user" needs. the Allwinner A20, Allwinner R40, Freescale iMX6 - these even have SATA on-board! they're more than capable of having a HDD or SSD connected to them, to create a *really* decent low-power desktop system. now, i don't _want_ to say that it's insulting to these systems to relegate them to "embedded" distro status (buildroot and other severely-limited distributions), but i don't know what other phrase to use. "lost opportunity", perhaps? something along those lines. so i hope that list gives a bit more context as to how serious the consequences of dropping 32 bit support really is. l.
Bug#935264: ITP: gridtools -- Framework for working on weather and climate grids
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: gridtools Version : 1.0.2 Upstream Author : ETH Zurich * URL : https://eth-cscs.github.io/gridtools/ * License : BSD-3-Clause Programming Lang: C++ Description : Framework for working on weather and climate grids The GridTools (GT) framework is a set of libraries and utilities to develop performance portable applications in which stencil operations on grids are central. The focus of the project is on regular and block-structured grids as are commonly found in the weather and climate application field. GridTools provides optimized backends for GPUs and manycore architectures. Stencils can be run efficiently on different architectures without any code change needed. Stencils can be built up by small composeable units called stages, using GridTools domain-specific language. . GridTools is used within the COSMO model and is used by the ECMWF software already present on Debian. . I intend to package this and maintain within the Debian Science team.
Re: lintian-brush adds redundant data
On Wed, Aug 21, 2019 at 2:48 PM Andreas Tille wrote: > DEP-12 is declared as "Work in progress" (without any progress since 5 > years) while DEP-5 is well established and decided. Charles and I > invented d/u/metadata to store publication information and it turned out > that there is other sensible information about upstream that can be > stored there as well. I'd vote against any duplication of information > in any way. So as long as Name and Contact are defined in DEP-5 it > should not be in DEP-12. These fields seem like they belong in DEP-12 more than DEP-5. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#935317: ITP: prometheus-elasticsearch-exporter -- Prometheus exporter for various metrics about ElasticSearch
Package: wnpp Severity: wishlist Owner: Badreddin Aboubakr * Package name: prometheus-elasticsearch-exporter Version : 1.1.0 Upstream Author : JustWatch * URL : https://github.com/justwatchcom/elasticsearch_exporter * License : Apache-2.0 Programming Lang: Go Description : Prometheus exporter for various metrics about ElasticSearch Prometheus elasticsearch exporter,fetches information from an ElasticSearch cluster nad expose expose various metrics this package is useful for monitoring elasticsearch cluster elasticsearch doesn't natively offer a Prometheus metrics endpoint however there is a plugin written in go, which we used to use but we had some compatibility problems since with each realse of elasticsearch the plugin must be installed in specific version in addition we had to install it manually I plan to maintain this with the long-term assistance of the Debian Go packaging team. Benjamin Drung (bdr...@debian.org) will sponsor me for the upload of this package.
Re: lintian-brush adds redundant data
On Wed, Aug 21, 2019 at 05:47:24PM +0800, Paul Wise wrote: > On Wed, Aug 21, 2019 at 2:48 PM Andreas Tille wrote: > > > DEP-12 is declared as "Work in progress" (without any progress since 5 > > years) while DEP-5 is well established and decided. Charles and I > > invented d/u/metadata to store publication information and it turned out > > that there is other sensible information about upstream that can be > > stored there as well. I'd vote against any duplication of information > > in any way. So as long as Name and Contact are defined in DEP-5 it > > should not be in DEP-12. > > These fields seem like they belong in DEP-12 more than DEP-5. Finally that's a matter of taste where the fields belong to. As long as there is no decision including a change of DEP-5 and a finalised DEP-12 I'd consider any change as its currently done as premature. Kind regards Andreas. -- http://fam-tille.de
Bug#935322: ITP: pytest-twisted -- Twisted plugin for py.test
Package: wnpp Severity: wishlist Owner: Andrey Rahmatullin * Package name: pytest-twisted Version : 1.11 Upstream Author : Kyle Altendorf et al. * URL : https://github.com/pytest-dev/pytest-twisted * License : BSD-3 Programming Lang: Python Description : Twisted plugin for py.test pytest-twisted is a plugin for pytest, which allows to test code, which uses the twisted framework. This will be used by future python-scrapy tests.
Re: Bits from the Release Team: ride like the wind, Bullseye!
Hi, On 18-08-2019 04:46, Lisandro Damián Nicanor Pérez Meyer wrote: >> I can already trigger all the autopkgtests in unstable for packages that >> are in experimental, so if you interested in this, please contact me. > > **Yes please**. This will certainly help *a lot* specially for us that we > prepare new releases on experimental. Soon. Figuring out some details on our side. > Perhaps derailing the thread a little, but other "pretty nice stuff to have" > as > a Debian service would be something that allows rebuilds of rdeps of stuff in > experimental. I can think of two existing services, albeit both need a bit of scripting on your side: 1) porterboxes (see e.g. https://lists.debian.org/msgid-search/20190614222919.gc24...@grep.be) 2) http://debomatic-amd64.debian.net/ (and other archs). > But yes, once again I can't nor will force anyone into doing it :-) Nor do you need to in my opinion. Yes, running on your own hardware is a pity. Paul signature.asc Description: OpenPGP digital signature
