Re: Modern best practice packaging tutorial?
On Tuesday, November 19, 2019 9:57:59 AM EST Paul Tagliamonte wrote: > Hey -devel! > > I've been less active on the packaging side for a while; has anyone > written up a modern packaging guide covering salsa best practices, > gbp best practices, and the commonly accepted strategy for tracking > upstreams (still uscan or are we doing something fancy with branches?) > for new packages? I see several people have provided different team approaches. Here's another (DPMT/PAPT): https://wiki.debian.org/Python/GitPackaging I tend to use it even for non-team packages. Scott K signature.asc Description: This is a digitally signed message part.
RE:GPU-ready (with free driver) buildd/CI/porterbox?
PICCA Frederic-Emmanuel writes: >> That is mostly upstream's job -- ICD packagers should just verify that the >> package still runs "Hello World" on their hardware, i.e. the ICD >> integration works, and then we assume that it works. > > ok, so in that case it would be nice to provide a computer with a GPU as > porterbox to test this hello world. > > Since we are using a lot of autopkgtest, this should be available for these > integrations tests. +1 because if we don't trust upstream-provided file.texi and are supposed to regenerate it from upstream's markdown files rather than trusting upstream's intermediary format, then how much moreso for something of importance like this! Given our reproduciblity and autopkgtest QA-related goals, we ought to QA the GPU-accelerated information processing on real hardware, because this provides an additional level of trust/confidence for people using Debian in their work and research. Finally, while it is proprietary software, it would be nice if such QA could encourage Davinci Resolve to support to support AMD on Debian. Currently they only support nVidia on RHEL. In other words, I absolutely affirm Mo Zhou's earlier proposal to provide a credible alternative to nVidia's CUDA. (email subject: rocm-team: in support of AMD's free CUDA counterpart and end NVIDIA monopoly) When framed this way (full-stack high-quality QA), I am optimistic that AMD would sponsor Debian--replying to Sam Hartman, who wrote: If AMD wants to sponsor Debian by giving us some hardware, I definitely think we should see if we can make that work. Cheers, Nicholas signature.asc Description: PGP signature
Bug#945117: ITP: matiec -- IEC 61131-3 to C translator
Package: wnpp Severity: wishlist Owner: Philip Rinn * Package name: matiec Version : 0.1+hgd9e47e0 Upstream Author : Mario de Sousa * URL : https://bitbucket.org/mjsousa/matiec * License : GPL-3 Programming Lang: C++ Description : IEC 61131-3 to C translator Open source code translator for the programming languages defined in the IEC 61131-3 standard. These programming languages are mostly used in the industrial automation domain, to program PLCs (Programmable Logic Controllers). The translator accepts the three textual representations defined in the standard, IL (Instruction List), ST (Structured Text) and SFC (Sequential Function Chart). . To my knowledge this is the only open source compiler for the IEC 61131-3 Languages. As I'm a DM, I'd need a sponsor for the upload.
RE:GPU-ready (with free driver) buildd/CI/porterbox?
> That is mostly upstream's job -- ICD packagers should just verify that the > package still runs "Hello World" on their hardware, i.e. the ICD > integration works, and then we assume that it works. ok, so in that case it would be nice to provide a computer with a GPU as porterbox to test this hello world. Since we are using a lot of autopkgtest, this should be available for these integrations tests. Fred
Re: libraries depending on interpreters
Hi Niko, On Sun, Nov 17, 2019 at 04:39:46PM +0200, Niko Tyni wrote: > at the last tech-ctte meeting the question came up of whether there's > a general rule in Debian about libraries/modules depending (or not) > on the corresponding interpreters for their implementation language. You've already mentioned that most ecosystems (but java) tend to have such a dependency in practice. Ecosystems not mentioned thus far: * lua is inconclusive. Some lua modules have a dependency, most don't. Though lua is often embedded, so not having the dependency kinda is relevant. * Although not interpreted, go is quite similar as it practically ships sources. go tends to lack compiler dependencies. * As far as I can see R tends to have a dependency on r-base-core. * Also consider that C libraries (even -dev packages) tend to not depend on gcc. Another aspect that hasn't been considered much yet is multiarch. This is where things become hairy due to our lovely multiarch interpreter problem. In a perfect world, we'd want language modules (and extensions) to be coinstallable for multiple architectures such that you can use say an amd64 Python interpreter executable and an i386 embedded Python interpreter in the same installation. Among other things, an interpreter dependency prevents us from doing so (unless annotated :any). So the perfect multiarch world would be in favour of not having such interpreter dependencies. This is a bit hypothetical though. Even installing a foreign Python is next to practically impossible. Hope this helps Helmut
Re: Debian event pre FOSDEM?
Hi Jurgen, thank you for continuing to show your space! On Mon, Nov 18, 2019 at 05:02:08PM +0100, Jurgen Gaeremyn wrote: > Cool! Glad you enjoyed our spot last year :) I did, it was a very nice and diverse evening! > We have a server room, where we also stock our valuables. I'm guessing we > could hand a key to one person. In any case, there are plenty of unused > spaces in the building. It would strongly surprise me if I wouldn't get > permission to use one to lock up your video gear. sounds great. I will leave it to the video team to contact you for this if needed. > P.S. wherever you end up... you're certainly invited for Bytenight :) Thanks! (and we, as group of Debian folks organizing us via https://wiki.debian.org/DebianEvents/be/2020/MiniDebCamp have settled for HSBXL now. *Maybe* the Debian videoteam folks will go elsewhere, though...) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Modern best practice packaging tutorial?
Hello, On Tue 19 Nov 2019 at 09:57AM -05, Paul Tagliamonte wrote: > I've been less active on the packaging side for a while; has anyone > written up a modern packaging guide covering salsa best practices, > gbp best practices, and the commonly accepted strategy for tracking > upstreams (still uscan or are we doing something fancy with branches?) > for new packages? If you are interested in trying something a bit more experimental there is dgit-maint-debrebase(7). -- Sean Whitton signature.asc Description: PGP signature
Bug#945104: ITP: surgescript -- scripting language for games
Package: wnpp Severity: wishlist Owner: Carlos Donizete Froes * Package name: surgescript Version : 0.5.4 Upstream Author : Alexandre Martins * URL : https://docs.opensurge2d.org * License : Apache-2.0 Programming Lang: C Description : scripting language for games Unleash your creativity! With SurgeScript, you unleash your creativity and create your own amazing interactive content. . Unlike other programming languages, SurgeScript is designed with the specific needs of games in mind. . Easy for beginners, powerful for experts. Object-oriented, dynamically typed and based on state machines. . These features come from the experience of the developer dealing with game engines, applications related to computer graphics and so on. . Some of the best practices have been incorporated into the language itself, making things really easy for developers and modders.
Re: Modern best practice packaging tutorial?
A large part of this exists also in Perl-Team. See https://perl-team.pages.debian.net/git.html Le 19 novembre 2019 17:20:45 GMT+01:00, Paul Tagliamonte a écrit : >On Tue, Nov 19, 2019 at 11:14 AM Xavier wrote: >> >> Hi, >> >> Here is a JS tuto. Some things are available for other teams: >https://wiki.debian.org/Javascript/Tutorial > >Very useful, thank you! Do you know how representative the JavaScript >team is of Debian writ large >these days? I understand each team has their quirks, but is the >average collab-maint style >package maintained this way? > >Thanks, Xavier! > paultag > >> >> Cheers, >> Xavier >> >> Le 19 novembre 2019 15:57:59 GMT+01:00, Paul Tagliamonte > a écrit : >>> >>> Hey -devel! >>> >>> I've been less active on the packaging side for a while; has anyone >>> written up a modern packaging guide covering salsa best practices, >>> gbp best practices, and the commonly accepted strategy for tracking >>> upstreams (still uscan or are we doing something fancy with >branches?) >>> for new packages? >>> >>> Much love to everyone! >>> paultag >> >> >> -- >> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez >excuser ma brièveté. > > > >-- >:wq -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Bug#945103: ITP: kt-update -- lightweight distribution management
Package: wnpp Severity: wishlist Owner: Jean-Jacques Brucker * Package name: kt-update Version : 0.18.9 Upstream Author : Jean-Jacques Brucker * URL : https://github.com/jbar/kt-update * License : GPL-2 Programming Lang: bash Description : lightweight distribution management Manage an apt sources.list and permit to switch between different distribution configurations. May also permit to switch beetween Debian and a light Debian derivative. . Using filters, it may also replace cron-apt. . Relevant only if you trust distro conf availables in your kt server. A kt server is trivial to deploy, cf. https://github.com/jbar/kt-update.
Re: Modern best practice packaging tutorial?
On Tue, Nov 19, 2019 at 11:14 AM Xavier wrote: > > Hi, > > Here is a JS tuto. Some things are available for other teams: > https://wiki.debian.org/Javascript/Tutorial Very useful, thank you! Do you know how representative the JavaScript team is of Debian writ large these days? I understand each team has their quirks, but is the average collab-maint style package maintained this way? Thanks, Xavier! paultag > > Cheers, > Xavier > > Le 19 novembre 2019 15:57:59 GMT+01:00, Paul Tagliamonte > a écrit : >> >> Hey -devel! >> >> I've been less active on the packaging side for a while; has anyone >> written up a modern packaging guide covering salsa best practices, >> gbp best practices, and the commonly accepted strategy for tracking >> upstreams (still uscan or are we doing something fancy with branches?) >> for new packages? >> >> Much love to everyone! >> paultag > > > -- > Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma > brièveté. -- :wq
Re: Modern best practice packaging tutorial?
Hi, Here is a JS tuto. Some things are available for other teams: https://wiki.debian.org/Javascript/Tutorial Cheers, Xavier Le 19 novembre 2019 15:57:59 GMT+01:00, Paul Tagliamonte a écrit : >Hey -devel! > >I've been less active on the packaging side for a while; has anyone >written up a modern packaging guide covering salsa best practices, >gbp best practices, and the commonly accepted strategy for tracking >upstreams (still uscan or are we doing something fancy with branches?) >for new packages? > >Much love to everyone! > paultag > >-- >:wq -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Modern best practice packaging tutorial?
On Tue, Nov 19, 2019 at 10:53 AM wrote: > > Hi Paul, > > I gave a talk on this as the SE Linux Fest in Charlotte earlier this > year. My presentation, notes, and sample project are here, in case > that's helpful: > https://bitbucket.org/elimtaft/debian-packaging-from-scratch-demo-project/src/master/. > Good luck! Thanks, Eli! I've been doing things this way for about 10 years or so, I'm very happy to do the dget/dput dance, or package something using a debian directory I build locally - do you happen to have any talk materials about specifically the modern Debian way to use salsa, gbp best practices, and the commonly accepted strategy for tracking upstreams on those git repos? I don't want to package something in line with best practices from 2015 by mistake :) I've been out of the game so long that I'd be tempted to fall back on my workflow from years ago. Thank you! Paul > > > Sincerely > > Eli > > -- > > Eli Taft > > Partner, Senior Software Engineer > > Quoin, Inc. > > www.quoininc.com > > -- :wq
Re: Modern best practice packaging tutorial?
Hi Paul, I gave a talk on this as the SE Linux Fest in Charlotte earlier this year. My presentation, notes, and sample project are here, in case that's helpful: https://bitbucket.org/elimtaft/debian-packaging-from-scratch-demo-project/src/master/. Good luck! Sincerely Eli -- Eli Taft Partner, Senior Software Engineer Quoin, Inc. www.quoininc.com signature.asc Description: OpenPGP digital signature
Re: GPU-ready (with free driver) buildd/CI/porterbox?
Hi, On Tue, Nov 19, 2019 at 02:48:48PM +, PICCA Frederic-Emmanuel wrote: > It would be nice also to be able to test the OpenCL icd implementations and > work with real hardware. That is mostly upstream's job -- ICD packagers should just verify that the package still runs "Hello World" on their hardware, i.e. the ICD integration works, and then we assume that it works. Then again, the last time I actively touched an ICD package I was also part of upstream. Simon
RE:GPU-ready (with free driver) buildd/CI/porterbox?
It would be nice also to be able to test the OpenCL icd implementations and work with real hardware.
Modern best practice packaging tutorial?
Hey -devel! I've been less active on the packaging side for a while; has anyone written up a modern packaging guide covering salsa best practices, gbp best practices, and the commonly accepted strategy for tracking upstreams (still uscan or are we doing something fancy with branches?) for new packages? Much love to everyone! paultag -- :wq
Re: GPU-ready (with free driver) buildd/CI/porterbox?
Hi, On Tue, Nov 19, 2019 at 09:21:16AM -0500, Sam Hartman wrote: > I'm hoping there's no need for a GPU on a buildd. > That would mean that the software required an active GPU to *build*, > which seems problematic on a number of fronts. As far as I've understood, that makes sense for some neural network packages -- we have free training data for e.g. speech recognition, and want to run the training once, then distribute the resulting NN, which is significantly smaller than the training data, and can be used without a GPU. It would be possible to compile these packages without a GPU, but that would be rather slow. I'm not sure on whether certain packages use vendor extensions that would require a particular brand of GPU -- a few autobuilders should have CPUs with integrated GPUs that have free drivers, but we're need a method to select these autobuilders then. Simon
Re: GPU-ready (with free driver) buildd/CI/porterbox?
On 19.11.19 05:59, Mo Zhou wrote: > Given that there are also a number of packages in debian with OpenCL > enabled, I'm wondering wether a shared buildd/CI/porterbox with GPU[2] > could be helpful? I would also be interested in this.
Re: GPU-ready (with free driver) buildd/CI/porterbox?
> "PICCA" == PICCA Frederic-Emmanuel > writes: PICCA> Hello >> Debian has from time to time funded hardware for people doing >> important work. I'd definitely be happy to receive a >> reimbursement request for such hardware from Debian developrs. >> For non DDs, I would want a DD involved in our GPU ecosystem >> (like yourself) to confirm the people doing the work have the >> necessary skills. We'd ask that people write regular status >> reports to let us know how our money is helping Debian. See >> https://wiki.debian.org/Teams/DPL/AskingForMoney for initial >> instructions on such requests. That links to a reimbursements >> page with the formal process. PICCA> What about AMD sponsoring Debian via providing GPU to the PICCA> Debian community, whcih should be added to the buildd or in a PICCA> porterbox ? I'm hoping there's no need for a GPU on a buildd. That would mean that the software required an active GPU to *build*, which seems problematic on a number of fronts. If AMD wants to sponsor Debian by giving us some hardware, I definitely think we should see if we can make that work. --Sam
RE:GPU-ready (with free driver) buildd/CI/porterbox?
Hello > Debian has from time to time funded hardware for people doing important > work. > I'd definitely be happy to receive a reimbursement request for such > hardware from Debian developrs. For non DDs, I would want a DD involved > in our GPU ecosystem (like yourself) to confirm the people doing the > work have the necessary skills. > We'd ask that people write regular status reports to let us know how our > money is helping Debian. > See https://wiki.debian.org/Teams/DPL/AskingForMoney for initial > instructions on such requests. > That links to a reimbursements page with the formal process. What about AMD sponsoring Debian via providing GPU to the Debian community, whcih should be added to the buildd or in a porterbox ? Frederic
Bug#945089: ITP: radiosonde -- Automatically Track Radiosonde Launches using RTL-SDR
Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
* Package name: radiosonde
Version : 1.2.2
Upstream Author : The Radiosonde Authors
* URL : https://github.com/projecthorus/radiosonde_auto_rx
* License : LGPL-2.1
Programming Lang: C, Python
Description : Automatic Radiosonde Receiver Utilities
This provide a software radiosonde receiver, along with a set of utilities
('auto_rx') to allow automatic reception and uploading of Radiosonde positions
to multiple services, including:
The Habitat High-Altitude Balloon Tracker
APRS-IS (for display on sites such as aprs.fi)
ChaseMapper and OziPlotter, for mobile radiosonde chasing.
It currently supports the following radiosonde types:
Vaisala RS92 (experimental support for the RS92-NGP)
Vaisala RS41
Graw DFM06/DFM09/DFM17/PS-15
Meteomodem M10
Intermet iMet-4 (and 'narrowband' iMet-1 sondes)
Lockheed Martin LMS6, 400 MHz and 1680 MHz variants (including the new
'LMS-X' type)
Meisei iMS-100
-BEGIN PGP SIGNATURE-
iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl3T7YsRHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MuxRw//dlt2a7T2kFUhivSh7ExIEo0LHWFwjlwR
R7OGoK++AWkFjOZ/C5egN6O+aMg1Fwqii2cXHzU39/5zjdx+b19/BgXBOL2dHe1P
mGyRCnJBzyX5OwXiY0sp0Na+qMMKoC76hHbpcZQRSN6IWm4WwZ9GdUXOtpPuNs7q
eV3AHscVT6x4lxiOPz+DO+AWQ+QOTURQnYMzsCevyccc+rUKx+jmIpWnuvqhTTW6
WsdcdaRupl50JtPgvBmXFkxhjHmKHSix7i3B1NnPI9DX85tOy6fuGSqB3gAOGzq4
q8phsaC+b2yhzd5otZBkjV5RHD5R32zTfy6wRszVejCpkhDh3/v+g6kPhQwYkHJ0
WEj+dCrVwDpSdTgSmgN+MF9UIhm1niZDu8Zawvczuj9bPGu/3WQVTqqN5bbADVFP
OwIFBz7uJKitaU8/UVydbTBeM63+6gW9a20LBtmacg8qjnFPdhEnkBnjmdWNdfmj
PL+zLWkJjVmPByDQaKuELTYIwWIxqGeAsjxraMnQ4CKSXA2l8dhUaGdYiJBM9ts4
VUF+0oXiLuqgW0jr6ZZZCqXlepipAWcLzg4n9RRHBZLMeGdCU1X/00fcZD58xYr3
Y68TV3A/L5X8iACZ8cEyY07inTOE3Jx4lqRTiOQQeFE0UlLm2Gm1363v1DCKP/9J
8QaRFeGH4Fg=
=5V0z
-END PGP SIGNATURE-
Re: GPU-ready (with free driver) buildd/CI/porterbox?
> "Mo" == Mo Zhou writes: Mo> Hi folks, Just a bold thought. Mo> Two Debian developers intended to package basic libraries of the Mo> AMD ROCm (freesoftware-licensed) [1], but both of them don't Mo> have access to such hardware. Debian has from time to time funded hardware for people doing important work. I'd definitely be happy to receive a reimbursement request for such hardware from Debian developrs. For non DDs, I would want a DD involved in our GPU ecosystem (like yourself) to confirm the people doing the work have the necessary skills. We'd ask that people write regular status reports to let us know how our money is helping Debian. See https://wiki.debian.org/Teams/DPL/AskingForMoney for initial instructions on such requests. That links to a reimbursements page with the formal process. --Sam
Bug#945087: ITP: golang-github-tidwall-tinyqueue -- Binary heap priority queues in Go
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-tidwall-tinyqueue Version : 0.0~git20180302.1e39f55-1 Upstream Author : Josh Baker * URL : https://github.com/tidwall/tinyqueue * License : ISC Programming Lang: Go Description : Binary heap priority queues in Go Tinyqueue is a Go package for binary heap priority queues. Ported from the tinyqueue (https://github.com/mourner/tinyqueue) Javascript library. This is a dependency of garagemq a.k.a. kubemq.io
Bug#945086: ITP: golang-github-tidwall-rtree -- RTree implementation for Go
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-tidwall-rtree Version : 0.0~git20180113.6cd4270-1 Upstream Author : Josh Baker * URL : https://github.com/tidwall/rtree * License : TODO Programming Lang: Go Description : RTree implementation for Go This package provides an in-memory R-Tree implementation for Go, useful as a spatial data structure. It has support for 1-20 dimensions, and can store and search multidimensions interchangably in the same tree. This is a dependency of garagemq a.k.a. kubemq.io
Bug#945084: ITP: golang-github-tidwall-grect -- Get the outer rectangle from GeoJSON, WKT, WKB
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-tidwall-grect Version : 0.0~git20161006.ba9a043-1 Upstream Author : Josh Baker * URL : https://github.com/tidwall/grect * License : TODO Programming Lang: Go Description : Get the outer rectangle from GeoJSON, WKT, WKB GRECT Quickly get the outer rectangle for GeoJSON, WKT, WKB. This is a dependency of garagemq a.k.a. kubemq.io
Bug#945085: ITP: golang-github-tidwall-pretty -- Efficient JSON beautifier and compactor for Go
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-tidwall-pretty Version : 1.0.0-1 Upstream Author : Josh Baker * URL : https://github.com/tidwall/pretty * License : TODO Programming Lang: Go Description : Efficient JSON beautifier and compactor for Go Pretty is a Go package that provides fast methods for formatting JSON for human readability, or to compact JSON for smaller payloads. . * pretty.Pretty will reformat the JSON for readability. * pretty.Color will add color to the result for printing to the terminal. The second param is used for a customizing the style, and passing nil will use the default pretty.TerminalStyle. * pretty.Ugly will reformat the JSON to make it more compact. . There's a PrettyOptions(json, opts) function which allows for customizing the output. This is a dependency of garagemq a.k.a. kubemq.io
Bug#945083: ITP: golang-github-tidwall-buntdb -- BuntDB is an embeddable, in-memory key/value database for Go with custom indexing and geospatial support
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-tidwall-buntdb Version : 1.1.0-1 Upstream Author : Josh Baker * URL : https://github.com/tidwall/buntdb * License : TODO Programming Lang: Go Description : embeddable, in-memory key/value database for Go BuntDB is a low-level, in-memory, key/value store in pure Go. It persists to disk, is ACID compliant, and uses locking for multiple readers and a single writer. It supports custom indexes and geospatial data. It's ideal for projects that need a dependable database and favor speed over data size. . Features: * In-memory database for fast reads and writes * Embeddable with a simple API * Spatial indexing for up to 20 dimensions; Useful for Geospatial data * Index fields inside JSON documents * Collate i18n Indexes using the optional collate package * Create custom indexes for any data type * Support for multi value indexes; Similar to a SQL multi column index * Built-in types that are easy to get up & running; String, Uint, Int, Float * Flexible iteration of data; ascending, descending, and ranges * Durable append-only file format for persistence * Option to evict old items with an expiration TTL * Tight codebase, under 2K loc using the cloc command * ACID semantics with locking transactions that support rollbacks This is a dependency of garagemq a.k.a. kubemq.io
Bug#945080: ITP: golang-github-dgraph-io-ristretto -- A high performance memory-bound Go cache
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-dgraph-io-ristretto Version : 0.0~git20191108.8d6a8a7-1 Upstream Author : Dgraph * URL : https://github.com/dgraph-io/ristretto * License : Apache-2.0 Programming Lang: Go Description : A high performance memory-bound Go cache Ristretto is a fast, concurrent cache library built with a focus on performance and correctness. . The motivation to build Ristretto comes from the need for a contention-free cache in Dgraph (https://github.com/dgraph-io/dgraph). . Features: * High Hit Ratios - with our unique admission/eviction policy pairing, Ristretto's performance is best in class. * Eviction: SampledLFU - on par with exact LRU and better performance on Search and Database traces. * Admission: TinyLFU - extra performance with little memory overhead (12 bits per counter). * Fast Throughput - we use a variety of techniques for managing contention and the result is excellent throughput. * Cost-Based Eviction - any large new item deemed valuable can evict multiple smaller items (cost could be anything). * Fully Concurrent - you can use as many goroutines as you want with little throughput degradation. * Metrics - optional performance metrics for throughput, hit ratios, and other stats. * Simple API - just figure out your ideal Config values and you're off and running.Status Ristretto is usable but still under active development. We expect it to be production ready in the near future. This is a dependency of garagemq a.k.a. kubemq.io
Bug#945082: ITP: golang-github-tidwall-btree -- B-Tree implementation for Go
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-tidwall-btree Version : 0.0~git20191029.400434d-1 Upstream Author : Josh Baker * URL : https://github.com/tidwall/btree * License : Apache-2.0 Programming Lang: Go Description : B-Tree implementation for Go This package provides an in-memory B-Tree implementation for Go, useful as an ordered, mutable data structure. . This is a fork of the wonderful google/btree package. It's has all the same great features and adds a few more. . * Descend* functions for iterating backwards. * Iteration performance boost. * User defined context. . User defined context is a great new feature that allows for entering the same item into multiple B-trees, and each B-tree have a different ordering formula. This is a dependency of garagemq a.k.a. kubemq.io
Bug#945081: ITP: golang-github-subosito-gotenv -- Load environment variables from `.env` or `io.Reader` in Go.
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-subosito-gotenv Version : 1.2.0+git20190917.de67a66-1 Upstream Author : Alif Rachmawadi * URL : https://github.com/subosito/gotenv * License : TODO Programming Lang: Go Description : Load environment variables from `.env` or `io.Reader` in Go. To modify your app environment variables, gotenv expose 2 main functions: * gotenv.Load * gotenv.Apply By default, gotenv.Load will look for a file called .env in the current working directory. . Behind the scene, it will then load .env file and export the valid variables to the environment variables. Make sure you call the method as soon as possible to ensure it loads all variables, say, put it on init() function. . Once loaded you can use os.Getenv() to get the value of the variable. This is a dependency of garagemq a.k.a. kubemq.io
Bug#945078: ITP: garagemq -- AMQP message broker implemented with golang
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: garagemq Version : 0.0~git20190703.39811a5+ds-1 Upstream Author : Valinurov Alexander * URL : https://github.com/valinurovam/garagemq * License : TODO Programming Lang: Go Description : AMQP message broker implemented with golang GarageMQ is a message broker that implement the Advanced Message Queuing Protocol (AMQP). Compatible with any AMQP or RabbitMQ clients (tested streadway/amqp and php-amqp lib) . The GarageMQ project is also knowns an KubeMQ (https://kubemq.io). . This package does not contain the admin-frontend/build files since debian packaging npm modules is "complicated". You can, after installing this package, download the files from github and `cp -a $SRCDIR/admin-frontend/build /var/lib/garagemq/admin-frontend/` to be able to use the admin frontend as intended.
Bug#945079: ITP: badger -- Fast key-value DB in Go.
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: badger Version : 2.0.0-1 Upstream Author : Dgraph * URL : https://github.com/dgraph-io/badger * License : Apache-2.0 Programming Lang: Go Description : Fast key-value DB in Go. BadgerDB is an embeddable, persistent and fast key-value (KV) database written in pure Go. It is the underlying database for Dgraph (https://dgraph.io), a fast, distributed graph database. It's meant to be a performant alternative to non-Go-based key-value stores like RocksDB. Project Status [Jun 26, 2019] Badger is stable and is being used to serve data sets worth hundreds of terabytes. Badger supports concurrent ACID transactions with serializable snapshot isolation (SSI) guarantees. A Jepsen-style bank test runs nightly for 8h, with --race flag and ensures the maintenance of transactional guarantees. Badger has also been tested to work with filesystem level anomalies, to ensure persistence and consistency. . Badger v1.0 was released in Nov 2017, and the latest version that is data-compatible with v1.0 is v1.6.0. . Badger v2.0, use a new storage format which won't be compatible with all of the v1.x. This is a dependency of garagemq a.k.a. kubemq.io
Bug#945070: ITP: puppet-module-voxpupuli-alternatives -- Puppet resource for managing Debian alternatives
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: puppet-module-voxpupuli-alternatives Version : 3.0.0 Upstream Author : Voxpupuli * URL : https://github.com/voxpupuli/puppet-alternatives * License : Apache-2.0 Programming Lang: Python Description : Puppet resource for managing Debian alternatives Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . This Puppet module provides a Puppet resource that manages Debian alternatives symlinks, which a user normally maintains through the shell command update-alternatives.
W sprawie współpracy
Dzień dobry, Zastanawiasz się ile powinna kosztować nowoczesna *Strona WWW*? Odpowiedz na tego maila w treści wpisując *Tak*, a my błyskawicznie zaproponujemy Ci atrakcyjne warunki dla Twojego biznesu! /--/ /Agencja Interaktywna z charakterem/
