Re: Salsa Beta - Updates
On 06/01/18 00:30, Joerg Jaspert wrote: > Alexander (formorer) is running an Irker instance on one of its own > VMs. Irker can send push events to an IRC channel. Please check the > wiki[2] for details on how to use it. > > We are not entirely happy with irker and are working on a better > solution that will also support Issues, Merge Requests and other > gitlab events. Until that is ready, you are invited to use the Irker > instance. I have started working on adding webhook support to KGB, which is the tool that many projects are already using for years. Ideally, this would be a service plugin in gitlab, so projects could use templates for configuration, and to be able to configure what is now done in the kgb.conf file. But to get this out quicker, I will just add simple webhook parsing. On a side note, I only learnt about the idea to replace KGB with irker last week, during the CCC congress. I think that contacting the KGB maintainers beforehand would have been a better way of dealing with this. -- Martín Ferrari (Tincho)
Bug#870195: ITP: golang-github-opentracing-contring-go-stdlib -- OpenTracing instrumentation for packages in the Go stdlib
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Mart=C3=ADn_Ferrari?= * Package name: golang-github-opentracing-contring-go-stdlib Version : 0.0+git201705028.48e4d76 Upstream Author : opentracing-contrib * URL : https://github.com/opentracing-contrib/go-stdlib * License : BSD-3 Programming Lang: Golang Description : OpenTracing instrumentation for packages in the Go stdlib This package contains OpenTracing (http://opentracing.io/) instrumentation for packages in the Go standard library. Instrumentation is provided for the following packages, with the following caveats: * net/http: Client and server instrumentation. Only supported with Go 1.7 and later.
Bug#870191: ITP: golang-github-opentracing-opentracing-go -- Go platform API for OpenTracing
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Mart=C3=ADn_Ferrari?= * Package name: golang-github-opentracing-opentracing-go Version : 1.0.2 Upstream Author : The OpenTracing Authors * URL : http://opentracing.io/ * License : MIT Programming Lang: Golang Description : Go platform API for OpenTracing By offering consistent, expressive, vendor-neutral APIs for popular platforms, OpenTracing makes it easy for developers to add (or switch) tracing implementations with an O(1) configuration change. OpenTracing also offers a lingua franca for OSS instrumentation and platform-specific tracing helper libraries. This package is a Go platform API for OpenTracing.
Bug#854014: ITP: prometheus-postgres-exporter -- Prometheus exporter for PostgresSQL server metrics
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Mart=C3=ADn_Ferrari?= * Package name: prometheus-postgres-exporter Version : 0.1.1 Upstream Author : Will Rouesnel * URL : https://github.com/wrouesnel/postgres_exporter * License : Apache-2.0 Programming Lang: Golang Description : Prometheus exporter for PostgresSQL server metrics Prometheus exporter for PostgresSQL server metrics, written in Go. Supportes Postgres versions 9.1 and up.
Re: "not authorised" doing various desktoppy things [and 1 more messages]
On 15/01/17 13:43, Ian Jackson wrote:
> Ian Jackson writes ("Re: "not authorised" doing various desktoppy things [and
> 1 more messages]"):
>> More news later today.
>
> I have just uploaded systemd-shim 10-3~exp1 to experimental. I seems
> to fix the problem for me. Depending on feedback, I will upload this
> to sid in the next few days.
This seems to solve the problem for me, thank you very much! (And I hope
you can get this in for stretch!)
--
Martín Ferrari (Tincho)
Re: "not authorised" doing various desktoppy things
On 03/01/17 17:05, Ian Jackson wrote: > Recently, my nm-applet can no longer control my network-manager > daemon. I get a message saying[1]: Did you ever get to the root of this? I am having the same kind of problem (no way to control networking, removable media, power settings) and a similar set-up (sysvinit, lightdm, cinnamon). I have been experiencing these kind of problems for months, but usually they would go away after an apt-get upgrade. Not now, and I am afraid that we will ship stretch with this problem. -- Martín Ferrari (Tincho)
Re: Can we kill net-tools, please?
On 31/12/16 09:23, Joerg Jaspert wrote: > On 14533 March 1977, Marco d'Itri wrote: > > dak override net-tools net optional > I: Will change priority from important to optional > Continue (y/N)? y Thanks! -- Martín Ferrari (Tincho)
Re: Can we kill net-tools, please?
On 26/12/16 11:43, Steve Cotton wrote: > Given that the transition-freeze for Stretch was on Nov 5th, I think this > update should be kept out of Testing until Stretch has been released. Actually, I made this update in September 2015. Yesterday I added a debian/NEWS file to warn users about the possible breakage in scripts. -- Martín Ferrari (Tincho)
Re: Can we kill net-tools, please?
On 26/12/16 10:50, Marco d'Itri wrote: > ifconfig, route, etc... > > Recently the net-tools maintainer has forked the abandoned net-tools > code base and started developing it again, after 15 years of stasis. I am currently the Debian maintainer for net-tools, but note that I have not forked, nor I am developing net-tools. Upstream got active again, somehow. > With this post I want to encourage fellow maintainers to stop depending > on net-tools, which is obsolete software and has been replaced long ago > by iproute. > Can we stop shipping two network configuration CLI tools in the default > install? > net-tools has long been deprecated and should not have important > priority, for a start. I agree wholeheartedly, and thought about retiring it in the past, but it proved impossible at the time. Maybe the output format change will make people finally switch to something less awful. -- Martín Ferrari (Tincho)
Bug#846402: ITP: golang-google-genproto -- Generated Go packages for common protocol buffer types
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-google-genproto Version : 0.0~git20161115.08f135d-1 Upstream Author : Google Inc. * URL : https://godoc.org/google.golang.org/genproto * License : Apache-2.0 Programming Lang: Golang Description : Generated Go packages for common protocol buffer types This repository contains the generated Go packages for common protocol buffer types, and the generated gRPC code necessary for interacting with Google's gRPC APIs. . It provides similar functionality to the now abandoned golang-github-googleapis-proto-client-go. . There are two sources for the proto files used in this repository: . * google/protobuf: the code in the protobuf and ptypes subdirectories is derived from this repo. The messages in protobuf are used to describe protocol buffer messages themselves. The messages under ptypes define the common well-known types. * googleapis/googleapis: the code in the googleapis is derived from this repo. The packages here contain types specifically for interacting with Google APIs.
Bug#846339: ITP: golang-github-weaveworks-mesh -- go library to build distributed systems
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-github-weaveworks-mesh Version : 0+git20161024.3dd75b1 Upstream Author : Weaveworks Ltd. * URL : https://github.com/weaveworks/mesh * License : Apache-2.0 Programming Lang: go Description : go library to build distributed systems Mesh implements a gossip protocol that provide membership, unicast, and broadcast functionality with eventually-consistent semantics. In CAP terms, it is AP: highly-available and partition-tolerant. . Mesh works in a wide variety of network setups, including thru NAT and firewalls, and across clouds and datacenters. It works in situations where there is only partial connectivity, i.e. data is transparently routed across multiple hops when there is no direct connection between peers. It copes with partitions and partial network failure. It can be easily bootstrapped, typically only requiring knowledge of a single existing peer in the mesh to join. It has built-in shared-secret authentication and encryption. It scales to on the order of 100 peers, and has no dependencies. This package is a dependency for prometheus-alertmanager.
Bug#845336: ITP: chasquid -- simple SMTP (email) server written in go
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: chasquid Version : 0.1 Upstream Author : Alberto Bertogli * URL : https://blitiri.com.ar/p/chasquid * License : Apache-2.0 Programming Lang: golang Description : simple SMTP (email) server written in go chasquid is an SMTP (email) server. It aims to be easy to configure and maintain for a small mail server, at the expense of flexibility and functionality. . It's written in Go, and is open source under the Apache license 2.0. . It is currently in beta: it's functional and has had some production exposure, but some things may still change in backwards-incompatible ways, including the configuration format. It should be rare and will be avoided if possible.
Re: Bug#842839: ITP: golang-github-golang-leveldb -- The LevelDB key-value database in the Go programming language.
On 01/11/16 16:31, Sascha Steinbiss wrote: > This package is a Go version of the LevelDB lightweight key-value database. > It is provided as a dependency of stenographer > (https://github.com/google/stenographer). According to the webpage, this package is unfinished and experimental. You are probably better off using https://github.com/syndtr/goleveldb, which is already packaged. -- Martín Ferrari (Tincho)
Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)
On 12/10/16 21:41, Vincent Bernat wrote: >> I don't think that shipping a binary compiled upstream should be >> allowed, so where's the line drawn? > > Dunno. It would be great if the line wasn't challenged just to prove a > point and eject a lot of packages from main while DFSG#2 is correctly > met. It is really not in my plans to challenge that line. It is just that I would like to understand the rules properly. I prefer not to play Mao while packaging :-) -- Martín Ferrari (Tincho)
Re: [Pkg-dns-devel] Bug#833309: "Browserified" stuff (knot-resolver-module-http: please package embedded epoch.js separately)
I might have forgotten some important parts, or I missed the announcements when I was inactive for a while. But I am confused by these 2 statements, and would love to get some pointers to learn more: > On 2016-10-11 15:28, Vincent Bernat wrote: >> Those specific sources are buildable from tools in main (aka >> coffeescript compiler, sass compiler, cat + uglifyjs). There is no hard >> requirement to rebuild from source when building the package. I had always understood that rebuilding from source was a hard requirement. Is this not the case any more? I don't think that shipping a binary compiled upstream should be allowed, so where's the line drawn? On 11/10/16 23:04, W. Martin Borgert wrote: > It remains the originally reported problem, that the sources > (*.coffee and *.scss) are not under debian/missing-sources/. > Probably a normal bug, not serious nor wishlist. I have never heard of debian/missing-sources. What is the policy/documentation regarding this? I have repackaged tarballs many times to add missing sources, I did not think there was another way to do it! Thanks. -- Martín Ferrari (Tincho)
Re: "Browserified" stuff
On 10/10/16 21:40, Joerg Jaspert wrote: > It is not useless, and contrib is way different than any random > repository out there. I am not sure about that. We discourage people from using contrib, and don't promise much support. Whereas upstream can offer the latest package always. This is server software; as a sysadmin, many times I decide which tools to use by checking if they are present in debian stable main, and I don't think I am alone in that. > The solution is to have the full build environment needed (for The solution I am aiming for is to drop all this handlebars nonsense. I am currently checking libjs-mustache (handlebars is just a superset of it) as it can do most of what handlebars does and it seems to have a less braindead toolchain. -- Martín Ferrari (Tincho)
Re: "Browserified" stuff
On 10/10/16 16:35, Bas Wijnen wrote: > So the decision is that this code in its current form does not belong in main. > If I understand your position correctly, you do not dispute this, but you seem > to advocate that it should be allowed in main anyway, to avoid demoralizing > the > developers (in particular, yourself)? No, I was replying to the email by Adam that seemed to encourage moving everything to contrib, since it is "not the end of the world". I understand how Debian works, I am just saying that for me it is kind of "the end of the world", and that I will do all the work it takes to avoid the move to contrib. -- Martín Ferrari (Tincho)
Re: "Browserified" stuff
On 09/10/16 23:56, Adam Borowski wrote: > Another issue is, as mentioned in the TC discussion, the inability to fix > any non-trivial security bugs in stable. I can't quite imagine the Security > Team hunting for a specific old version of grunt and all of its extensive > dependencies to rebuild the buggy package. Such state hits the definition > of "contrib" exactly, why not actually use it for this purpose? Demotion of > libjs-handlebars would require changing or demoting two more packages: > prometheus and kcov, which would be a hassle but not the end of the world. Prometheus being in contrib basically means the work I have done for the past year is worthless, as users could as well just grab unofficial packages from other places. I am not saying this to justify the mess with handlebars, I want to find a solution, but putting this in contrib or non-free is not an option for me. -- Martín Ferrari (Tincho)
Re: Alternative solution
On 07/09/16 08:43, Christian Seiler wrote: > There's a piece of software called nss_wrapper, written by the > Samba people, that allows you to modify glibc's DNS functions' > (getaddrinfo, gethostbyname, ...) behavior via an LD_PRELOAD > library. It's called nss_wrapper; This is an excellent suggestion. Sadly, I've tried to use it for the tests of a golang library, only to realise that it does not work because everything in golang is statically compiled :/ -- Martín Ferrari (Tincho)
Bug#830785: ITP: mtail -- Extract monitoring data from logs for collection in a timeseries database
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: mtail Version : 0.0+git20160704.35c4023 Upstream Author : Google Inc. * URL : https://github.com/google/mtail * License : Apache-2.0 Programming Lang: Go Description : Extract monitoring data from logs for collection in a timeseries database mtail is a tool for extracting metrics from application logs to be exported into a timeseries database or timeseries calculator for alerting and dashboarding. It aims to fill a niche between applications that do not export their own internal state, and existing monitoring systems, without patching those applications or rewriting the same framework for custom extraction glue code. Metrics are exported for scraping by a collector as JSON or Prometheus format over HTTP, or can be periodically sent to a collectd, StatsD, or Graphite collector socket.
Bug#828073: ITP: prometheus-alertmanager -- Handle and deliver alerts created by Prometheus
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: prometheus-alertmanager Version : 0.2.1 Upstream Author : The Prometheus Authors * URL : https://prometheus.io/ * License : Apache-2 Programming Lang: Go Description : Handle and deliver alerts created by Prometheus The Alertmanager handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct receiver integration such as email, PagerDuty, or OpsGenie. It also takes care of silencing and inhibition of alerts.
Bug#827410: ITP: prometheus-mongodb-exporter -- Prometheus exporter for MongoDB
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: prometheus-mongodb-exporter Version : 0.0+git20160604.28251cc Upstream Author : 2015 David Cuadrado * URL : https://github.com/dcu/mongodb_exporter * License : MIT Programming Lang: Go Description : Prometheus exporter for MongoDB Prometheus exporter for MongoDB, written in Go.
Re: golang naming scheme
On 31/03/16 19:18, Russ Allbery wrote: >>> If I understand correctly, the URL of a Go package is ABI. > That's one of the reasons why so many people use github, since that URL is > less likely to change. > > One interesting detail of this approach is that it means that a takeover > of the package by a different maintainer results in a different package > name inherently. I'm not sure whether it's a feature or a bug, but it's > certainly interesting. Actually, go uses the URL as both the import name and the location from where to download sources when using "go get". But they are not necessarily tied together. Github could easily rename to goolab, and packages will not break, because we don't use "go get", at least until upstreams start changing the import names in the reverse dependencies. And that is not something you can avoid by using any kind of clever package naming. Actually, the package name can be ignored completely (except for the handiness of being automatically derived from the import name). Moreover, it is fairly trivial to have a single binary package provide different import names, by symlinking the directories where the sources are stored. We have done this a few times already. So, to conclude: - yes, the package names are ugly, we know. - they are still the best reasonable schema we could find, nobody was lazy - there is no impending doom waiting to happen, at worst some annoyance. -- Martín Ferrari (Tincho)
Bug#819281: ITP: golang-github-asaskevich-govalidator -- Validators and sanitizers for strings, numerics, slices and structs
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-github-asaskevich-govalidator Version : v3 Upstream Author : Alex Saskevich * URL : https://github.com/asaskevich/govalidator/ * License : MIT Programming Lang: Go Description : Validators and sanitizers for strings, numerics, slices and structs Package govalidator is package of validators and sanitizers for strings, structs and collections. It is based on validator.js.
Re: Bug#814823: ITP: prometheus-pgbouncer-exporter -- Export metrics from pgbouncer to Prometheus
Hi Christopher, On 15/02/16 17:40, Christopher Baines wrote: > Not sure quite how to handle this package, as I am the upstream author as > well. Ideally, keep the debian packaging separate from the upstream development. I'd recommend creating a repository on alioth (maybe in collab-maint?) where you can add your main repo as a remote, but only push debian-related commits to the alioth remote. I am the maintainer for a few prometheus packages, so if you need help or sponsored uploads, feel free to reach to me (I am also Tincho in oftc/freenode) -- Martín Ferrari (Tincho)
Bug#810674: ITP: golang-github-kolo-xmlrpc -- Implementation of the XMLRPC client protocol in Go
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-github-kolo-xmlrpc Version : 0+git20150413.0826b98 Upstream Author : Dmitry Maksimov * URL : https://github.com/kolo/xmlrpc * License : MIT Programming Lang: Go Description : Implementation of the XMLRPC client protocol in Go The github.com/kolo/xmlrpc package is an implementation of client side part of XMLRPC protocol in the Go language.
Bug#810667: ITP: golang-github-prometheus-common -- Common libraries for Prometheus components
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-github-prometheus-common Version : 0+git20160104.0a3005b Upstream Author : The Prometheus Authors * URL : https://github.com/prometheus/common/ * License : Apache-2.0 Programming Lang: Go Description : Common libraries for Prometheus components * github.com/prometheus/common/log: Wraps https://github.com/Sirupsen/logrus in order to add line:file annotations to log lines, as well as to provide common command-line flags for Prometheus components using it. * github.com/prometheus/common/model: Shared data structures * github.com/prometheus/common/expfmt: Decoding and encoding for the exposition format * github.com/prometheus/common/route: A routing wrapper around https://github.com/julienschmidt/httprouter using `context.Context` (Note that this package supercedes golang-github-prometheus-log, which I will ask for removal after all its reverse-deps migrate to this package.)
Bug#799169: ITP: golint -- Linter for Go source code
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golint Version : 0.0+git20150623.7b7f436 Upstream Author : The Go Authors * URL : https://github.com/golang/lint * License : BSD-3-Clause Programming Lang: Go Description : Linter for Go source code Golint differs from gofmt. Gofmt reformats Go source code, whereas golint prints out style mistakes. Golint differs from govet. Govet is concerned with correctness, whereas golint is concerned with coding style. Golint is in use at Google, and it seeks to match the accepted style of the open source Go project.
Re: Bug#791857: ITP: daemonize -- tool to run a command as a daemon
On 09/07/15 02:19, Guillem Jover wrote: >> Most programs that are designed to be run as daemons do that work for >> themselves. However, you’ll occasionally run across one that does not. When >> you must run a daemon program that does not properly make itself into a true >> Unix daemon, you can use daemonize to force it to run as a true daemon. > > Does this have any advantage over start-stop-daemon? I can say that it does: start-stop-daemon misses some functionality you need for programs that don't daemonise and log to stdout/stderr, which is something I needed only last week. Having said that, I think that 'daemon' does everything that 'daemonize' does and more. -- Martín Ferrari (Tincho) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/559e75eb.2060...@tincho.org
Bug#791720: ITP: prometheus-pushgateway -- Prometheus exporter for ephemereal jobs
Package: wnpp Severity: wishlist Owner: Martín Ferrari X-Debbugs-CC: debian-devel@lists.debian.org * Package name: prometheus-pushgateway Version : 0.2.0 Upstream Author : The Prometheus Authors * URL : https://github.com/prometheus/prometheus_cli * License : Apache-2.0 Programming Lang: Go Description : Prometheus exporter for ephemereal jobs The Prometheus Pushgateway exists to allow ephemeral and batch jobs to expose their metrics to Prometheus. Since these kinds of jobs may not exist long enough to be scraped, they can instead push their metrics to a Pushgateway. The Pushgateway then exposes these metrics to Prometheus. . The Pushgateway is explicitly not an aggregator, but rather a metrics cache. It does not have a statsd-like semantics. The metrics pushed are exactly the same as you would present for scraping in a permanently running program. . For machine-level metrics, the textfile collector of prometheus-node-exporter is usually more appropriate. The Pushgateway is best used for service-level metrics. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/559c3a77.4070...@tincho.org
ITP: golang-github-julienschmidt-httprouter -- High performance HTTP request router for Go that scales well
Package: wnpp Severity: wishlist Owner: MartÃn Ferrari * Package name: golang-github-julienschmidt-httprouter Version : 1.1 Upstream Author : Julien Schmidt. All rights reserved. * URL : https://github.com/julienschmidt/httprouter * License : BSD-3-clause Programming Lang: Go Description : High performance HTTP request router for Go that scales well HttpRouter (github.com/julienschmidt/httprouter) is a lightweight high performance HTTP request router (also called multiplexer or just mux for short) for Go. . In contrast to the default mux of Go's net/http package, this router supports variables in the routing pattern and matches against the request method. It also scales better. . The router is optimized for high performance and a small memory footprint. It scales well even with very long paths and a large number of routes. A compressing dynamic trie (radix tree) structure is used for efficient matching. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/559b9cd5.1010...@tincho.org
ITP: prometheus-cli - Prometheus command line interface
Package: wnpp Severity: wishlist Owner: Martín Ferrari * Package name: prometheus-cli Version : 0.3.0 Upstream Author : The Prometheus Authors * URL : https://github.com/prometheus/prometheus_cli * License : Apache-2.0 Programming Lang: Go Description : Prometheus command line interface A command line interface tool for querying the Prometheus server's HTTP API -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/559b8768.50...@tincho.org
ITP: golang-github.com-prometheus-log
Package: wnpp Severity: wishlist Owner: Martín Ferrari * Package name: golang-github.com-prometheus-log Version : 0.10.0 Upstream Author : The Prometheus Authors * URL : https://github.com/prometheus/node_exporter * License : Apache-2.0 Programming Lang: Go Description : Logging library for Prometheus's Go-based components Standard logging library for Go-based Prometheus components. This library wraps https://github.com/Sirupsen/logrus in order to add line:file annotations to log lines, as well as to provide common command-line flags for Prometheus components using it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/559400f1.6000...@tincho.org
Re: ITP: golang-github.com-prometheus-log
On 01/07/15 17:02, Martín Ferrari wrote: > * Package name: golang-github.com-prometheus-log > Version : 0.10.0 > Upstream Author : The Prometheus Authors > * URL : https://github.com/prometheus/node_exporter Err.. too fast C&P, that should have been: > * Package name: golang-github.com-prometheus-log > Version : 0+git20150701.439e5db > Upstream Author : The Prometheus Authors > * URL : https://github.com/prometheus/log -- Martín Ferrari (Tincho) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55940247.3060...@tincho.org
Bug#785645: ITP: golang-x-text -- Supplementary Go text-related libraries
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-x-text Version : 0+git20150518.c93e7c9 Upstream Author : The Go Authors * URL : https://godoc.org/golang.org/x/text * License : BSD-3-clause Programming Lang: Go Description : Supplementary Go text-related libraries golang.org/x/text is a repository of text-related packages, such as character encodings, text transformations, and locale-specific text handling. . - cases: Package cases provides general and language-specific case mappers. - cldr: Package cldr provides a parser for LDML and related XML formats. - collate: Package collate contains types for comparing and sorting Unicode strings according to a given collation order. - collate/build: - collate/colltab: - display: Package display provides display names for languages, scripts and regions in a requested language. - encoding: Package encoding defines an interface for character encodings, such as Shift JIS and Windows 1252, that can convert to and from UTF-8. - encoding/charmap: Package charmap provides simple character encodings such as IBM Code Page 437 and Windows 1252. - encoding/japanese: Package japanese provides Japanese encodings such as EUC-JP and Shift JIS. - encoding/korean: Package korean provides Korean encodings such as EUC-KR. - encoding/simplifiedchinese: Package simplifiedchinese provides Simplified Chinese encodings such as GBK. - encoding/traditionalchinese: Package traditionalchinese provides Traditional Chinese encodings such as Big5. - encoding/unicode: Package unicode provides Unicode encodings such as UTF-16. - internal/colltab: Package colltab contains functionality related to collation tables. - internal/gen: Package gen contains common code for the various code generation tools in the text repository. - internal/testtext: Package testtext contains test data that is of common use to the text repository. - internal/triegen: Package triegen implements a code generator for a trie for associating unsigned integer values with UTF-8 encoded runes. - internal/ucd: Package ucd provides a parser for Unicode Character Database files, the format of which is defined in http://www.unicode.org/reports/tr44/. - language: Package language implements BCP 47 language tags and related functionality. - runes: Package runes provide transforms for UTF-8 encoded text. - search: Package search provides language-specific search and string matching. - transform: Package transform provides reader and writer wrappers that transform the bytes passing through as well as various transformations. - unicode/norm: Package norm contains types and functions for normalizing Unicode strings. - unicode/rangetable: Package rangetable creates new unicode.RangeTables. - width: Package width provides functionality for handling different widths in text. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150518180547.12261.70422.report...@aine.tincho.org
Bug#779260: ITP: golang-prometheus-client -- Prometheus instrumentation library for Go applications
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-prometheus-client Version : 0.1.0 Upstream Author : The Prometheus Authors * URL : https://github.com/prometheus/client_golang * License : Apache-2.0 Programming Lang: Go Description : Prometheus instrumentation library for Go applications This is the Prometheus Go client library. It provides two main functions: * The exposition library is used to export metrics to a Prometheus server or pushgateway. * The consumption library is used to process metrics exported by a Prometheus client. (The Prometheus server is using that library.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150226022740.17985.37402.report...@aine.tincho.org
Bug#779258: ITP: golang-procps -- Golang library to retrieve metrics from the proc pseudo-filesystem
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-procps Version : 0+git20150225.6c34ef8 Upstream Author : The Prometheus Authors * URL : https://github.com/prometheus/procfs/ * License : Apache-2.0 Programming Lang: Go Description : Golang library to retrieve metrics from the proc pseudo-filesystem Procfs provides functions to retrieve system, kernel and process metrics from the pseudo-filesystem proc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150226011853.22268.42842.report...@aine.tincho.org
Bug#779235: ITP: golang-protobuf-extensions -- Protocol Buffer extensions for the Go language
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-protobuf-extensions Version : 0+git20150225.ba7d65a Upstream Author : Matt T. Proud * URL : https://github.com/matttproud/golang_protobuf_extensions * License : Apache-2.0 Programming Lang: Go Description : Protocol Buffer extensions for the Go language This repository provides various Protocol Buffer extensions for the Go language (golang), namely support for record length-delimited message streaming. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150225185727.20797.15460.report...@aine.tincho.org
Bug#778517: ITP: golang-snappy-go -- Implementation of the Snappy compression format in Go
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-snappy-go Version : 0+hg20150215.8850bd446ad6 Upstream Author : The Snappy-Go Authors * URL : https://code.google.com/p/snappy-go/ * License : BSD-3-clause Programming Lang: Go Description : Implementation of the Snappy compression format in Go Snappy is a compression/decompression library. It does not aim for maximum compression, or compatibility with any other compression library; instead, it aims for very high speeds and reasonable compression. For instance, compared to the fastest mode of zlib, Snappy is an order of magnitude faster for most inputs, but the resulting compressed files are anywhere from 20% to 100% bigger. On a single core of a Core i7 processor in 64-bit mode, Snappy compresses at about 250 MB/sec or more and decompresses at about 500 MB/sec or more. This is an implementation of the Snappy compression format in the Go programming language. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150216064914.30527.96377.report...@aine.tincho.org
Bug#778516: ITP: golang-ginkgo -- BDD Testing Framework for Go
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-ginkgo Version : 1.1.0 Upstream Author : Onsi Fakhouri * URL : https://github.com/onsi/ginkgo/ * License : MIT Programming Lang: Go Description : BDD Testing Framework for Go Ginkgo is a BDD-style Golang testing framework built to help you efficiently write expressive and comprehensive tests. It is best paired with the Gomega matcher library but is designed to be matcher-agnostic. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150216064503.30359.51013.report...@aine.tincho.org
Bug#778515: ITP: golang-gomega -- Matcher/assertion library for the Go programming language
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-gomega Version : 0.1 Upstream Author : Onsi Fakhouri * URL : https://github.com/onsi/gomega * License : MIT Programming Lang: Go Description : Matcher/assertion library for the Go programming language Gomega is a matcher/assertion library. It is best paired with the Ginkgo BDD test framework, but can be adapted for use in other contexts too. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150216064155.30124.43030.report...@aine.tincho.org
Bug#778420: ITP: golang-leveldb -- Implementation of the LevelDB key/value database in Go
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-leveldb Version : 0+git20150214.e9e2c8f Upstream Author : Suryandaru Triandana * URL : https://github.com/syndtr/goleveldb * License : BSD-2-clause Programming Lang: go Description : Implementation of the LevelDB key/value database in Go This is an implementation of the LevelDB key/value database (https://github.com/google/leveldb) in the Go programming language. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150214195029.22107.49697.report...@aine.tincho.org
Bug#778407: ITP: golang-glog -- Leveled execution logs for Go
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: golang-glog Version : 0.1~git20150214.44145f0 Upstream Author : Google Inc. * URL : https://github.com/golang/glog * License : Apache-2.0 Programming Lang: Go Description : Leveled execution logs for Go This is an efficient pure Go implementation of leveled logs in the manner of the open source C++ package http://code.google.com/p/google-glog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150214150927.32729.76240.report...@aine.tincho.org
Bug#777048: ITP: prometheus -- A systems and service monitoring system.
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: prometheus Version : 0.10.0 Upstream Author : The Prometheus Authors * URL : http://prometheus.io/ * License : Apache 2.0 Programming Lang: go Description : A systems and service monitoring system. Prometheus is a systems and service monitoring system. It collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts if some condition is observed to be true. Prometheus' main distinguishing features as compared to other monitoring systems are: * A multi-dimensional data model (timeseries defined by metric name and set of key/value dimensions). * A flexible query language to leverage this dimensionality. * No dependency on distributed storage; single server nodes are autonomous. * Timeseries collection happens via a pull model over HTTP. * Pushing timeseries is supported via an intermediary gateway. * Targets are discovered via service discovery or static configuration. * Multiple modes of graphing and dashboarding support. * Federation support coming soon. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150204130009.2893.37085.report...@aine.tincho.org
Bug#754804: ITP: python-flask-httpauth -- Basic and Digest HTTP authentication for Flask routes
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: python-flask-httpauth Version : 2.2.1 Upstream Author : Miguel Grinberg * URL : https://github.com/miguelgrinberg/flask-httpauth/ * License : MIT Programming Lang: Python Description : Basic and Digest HTTP authentication for Flask routes Flask-HTTPAuth is a simple extension that provides Basic and Digest HTTP authentication for Flask routes. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140714130944.8818.55079.report...@aine.tincho.org
Re: default messaging/VoIP client for Debian 8/Jessie
On 30/03/14 15:20, Jonas Smedegaard wrote: > Please use https://wiki.debian.org/UnifiedCommunications as starting > point. There is already link to a (mini-)HOWTO on some server setup, > but if that does not adequately cover conference calls (I haven't tried > yet myself) then consider extending that wiki page instead of sharing > details here ;-) What I see missing from the Wiki page and this discussion are other SIP clients, like linphone, Yate client, SFLphone, etc. Coincidentally, linphone and Yate are the best I have found so far. Each one with its own limitations and strenghts. At the same time, my experience with Jitsi was not great. I have just installed it again to try it out, and it just fails to connect to any of my accounts, I am guessing it is choking on IPv6. Also, seeing the amount of exceptions it throws on the console is not really reassuring. Empathy was simply not usable for me, specially if you had any kind of connection issues, it seemed impossible to debug, and the async nature of its modules was infuriating. Note that my criteria here is being able to make SIP voice calls, I don't really care about the rest, but still to this day I don't think there is a single decent SIP client in Debian, which will give me good audio quality, support multiple accounts reasonably, survive disconnections or other network issues, be integrated with some address book, work over NAT issues more or less painlessly, and have a decent UI. -- Martín Ferrari (Tincho) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/533bf57b.7010...@tincho.org
Bug#714405: ITP: larch -- A tool to copy messages from one IMAP server to another
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: larch Version : 1.1.2 Upstream Author : Ryan Grove * URL : http://github.com/rgrove/larch * License : GPL-2 Programming Lang: Ruby Description : A tool to copy messages from one IMAP server to another Larch is a tool to copy messages from one IMAP server to another quickly and safely. It’s smart enough not to copy messages that already exist on the destination and robust enough to deal with interruptions caused by flaky connections or misbehaving servers. Larch is particularly well-suited for copying email to, from, or between Gmail accounts. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130628213459.27441.58514.reportbug@localhost
Second BSP in Dublin + Ireland DUG announcement
Bug Squashing Party in Dublin = http://wiki.debian.org/BSP/2012/11/ie/Dublin Come and help get Wheezy released, a second time! After the success of the first Irish Debian BSP, we're holding a second one in November. We will gather to collectively fix bugs and help each other while having some fun. Visits to the pub are assured after a day of hard work! Everybody is invited, even newcomers! We will assist people who has never done this before, and the whole point of getting together is to help each other! There is no need to be a programmer to help, there are plenty of tasks for everyone! See http://people.debian.org/~vorlon/rc-bugsquashing.html for what exciting opportunities there are! Over [http://bugs.debian.org/release-critical/] of them! :-) Ireland Debian User Group created - Since I am already spamming all of you, I want to announce that the Ireland DUG can be considered founded after the Debian listmasters created our mailing list! You can subscribe here: https://lists.debian.org/debian-dug-ie/ When Saturday 3rd November, 2012. 11:00-19:00 Where = Google Ireland 1 Grand Canal Plaza Dublin 4 Ireland http://osm.org/go/es~TUCk1U-- (Dunno how to mark a point in the map!) We'll get a nice conference room in the ground floor with good Wi-Fi access, free snacks, and pizza! Who === Please add yourself to the list in the wiki page (http://wiki.debian.org/BSP/2012/11/ie/Dublin), I'll need to provide a list of people attending the event. Where to stay = If you do not live in Dublin and don't know where to stay, but would like to come, then please contact debian-dug...@lists.debian.org and we'll try to host you. -- Martín Ferrari -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAL60Pd9QbdK24T-3D135fDWQAQn9iPV+Y=_5qwtjx2lb6ke...@mail.gmail.com
Re: CIA going down: KGB wants your commits!
(you have a really weird reply-to :)) On Fri, Sep 28, 2012 at 1:35 AM, Joey Hess wrote: > d-i would like to use your bots, but we have an ever-changing list of > repositories. It'd be wrong to centralize the list of them in a bot's > config file. Any thoughts? For KGB the concept of a repository is a bit fuzzy. It is just the unit it uses to separate access control (password), channels to broadcast to, and a word in the commit notification. But you can use one of these for hundreds of repos, like pkg-perl does: all the git repos (one per package) use the same client config, and just add a module parameter derived from the path. Would that be enough for you? -- Martín Ferrari -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cal60pd8_+ghw83tgcjhnq0oozjc09t8h9vhogdgkkgi7eci...@mail.gmail.com
CIA going down: KGB wants your commits!
Hi there! Not to "to knock 'em when they're down", but since it seems that the CIA.vc service has officially closed recently (cannot find exactly when did that happen), I think it's worthwhile offering this little project we (dam@, gregoa@, and me) have since a few years ago, called KGB (ha-ha). It's a very simple and dumb client-server architecture: IRC bots running in our personal servers listen for SOAP messages sent by kgb-clients called from post-commit hooks in repos out there. The bot just relays and formats a message, nothing fancier than that. So, if you're looking for a simple IRC notification of your commits, this might be of help. You can either run your own bot (debian package kgb-bot), or use ours. As for the client, alioth does not have it installed, but you can run it off /home/groups/kgb. There's a sample configuration there too. In /home/groups/pkg-perl/meta/pkg-perl-post-receive you can see how to use it from a post-commit hook. If you rather use our bots, we'll need you to provide: a project/repository name, an IRC channel, and a password (used to avoid spam, not really secure). -- Martín Ferrari -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cal60pd_7zopk4w4rta49-jymxzkou+k7ddqzuiqsp32kz9b...@mail.gmail.com
Bug#680572: ITP: nemu -- A lightweight network emulator embedded in a small python library
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: nemu Version : 0.1 Upstream Author : Martín Ferrari , Alina Quereilhac * URL : http://code.google.com/p/nemu/ * License : GPLv2 Programming Lang: Python Description : A lightweight network emulator embedded in a small python library Nemu (Netwok EMUlator) is a small Python library to create emulated networks and run and test programs in them. Different programs, or copies of the same program, can run in different emulated nodes, using only the emulated network to communicate, without ever noticing they all run in the same computer. Nemu provides a very simple interface to create nodes, connect them arbitrarily with virtual interfaces, configure IPv4 and IPv6 addresses and routes, and start programs in the nodes. The virtual interfaces also support emulation of delays, loss, and reordering of packets, and bandwidth limitations. More advanced configurations, like setting up netfilter (iptables) rules, starting VPN tunnels, routing daemons, etc, are simply supported by executing the appropriate commands in the emulated nodes, exactly as if they were executed in real machines in a real network. You can even start interactive sessions by opening xterms on different nodes, Nemu has special support for forwarding X sessions to the emulated nodes. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706205055.4299.69209.report...@abhean.lan
Re: Dublin, Ireland bug squashing party
Hi Phillip, On Mon, Jun 25, 2012 at 7:00 AM, Philip Ashmore wrote: > It's come to my attention that bug squashing parties are _the_ way to fix > bugs. > > Not to be seen as uncool, I'm proposing a bug squashing party somewhere in > Dublin, Ireland at a mutually agreed date and time. That is a great idea! There does not seem to be much local Debian activity, despite the number of DDs living here, and this is a good way to help revert that, and help the release! Have you thought of a place, or talked with anybody about that? I'm thinking the TOG might be a good place. > I'm just canvassing for support right now, as I don't know the Debian > procedure for doing this - or even if there is one. I'd participate and/or help organise. > One of the topics/issues/bugs I hope to address is getting my open source > projects in SourceForge knocked into shape for acceptance into Debian. > I don't know if that meets the criteria for "party" - maybe a shindig or a > hootenanny. I think BSPs usually focus on fixing problems for packages already in Debian, specially RC bugs. But nobody would discourage you from working on your packages and getting help from other people doing so! Tincho. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAL60Pd8Ln++oL5=d_J7uR32A0U3=wjnhdoonmqy9kqtzxnv...@mail.gmail.com
Bug#677000: ITP: python-passfd -- Python extension to pass file descriptors across UNIX domain sockets
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: python-passfd Version : 0.2 Upstream Author : "Martín Ferrari" * URL : http://code.google.com/p/python-passfd/ * License : GPLv2 Programming Lang: Python, C. Description : Python extension to pass file descriptors across UNIX domain sockets This simple extension provides two functions to pass and receive file descriptors across UNIX domain sockets, using the BSD-4.3+ sendmsg() and recvmsg() interfaces. Direct bindings to sendmsg() and recvmsg() are not provided, as the API does not map nicely into Python. Please note that this only supports BSD-4.3+ style file descriptor passing, and was only tested on Linux. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120611000904.4340.3774.report...@abhean.lan
Bug#676969: ITP: python-unshare -- Python bindings for the Linux unshare() syscall
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: python-unshare Version : 0.1 Upstream Author : "Martín Ferrari" * URL : http://code.google.com/p/python-unshare/ * License : GPLv2 Programming Lang: Python, C Description : Python bindings for the Linux unshare() syscall This simple extension provides bindings to the Linux unshare() syscall, added in kernel version 2.6.16. By using unshare(), new and interesting features of the Linux kernel can be exploited, such as: * Creating a new network name space (CLONE_NEWNET). * Creating a new file system mount name space (CLONE_NEWNS). * Reverting other features shared from clone(). This library provides an equivalent of the (recently added) util-linux command-line program unshare. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120610203415.3361.25085.report...@abhean.lan
Re: Bug#590853: ITP: your-freedom -- The your-freedom.net client
Hi, On Thu, Jul 29, 2010 at 18:58, Irving Leonard wrote: > * Package name : your-freedom > Version : 0.0.20100728.01 > Upstream Author : resolution GmbH > * URL : http://your-freedom.net/ > * License : LGPL, others > Programming Lang: Java > Description : The your-freedom.net client > > Are you trapped behind a firewall or a filtering web proxy and > cannot access some or many web pages or use an application > you would like to use or play a game you would like to play? Is > your Internet connection being censored and you would like to stick > censorship where the sun doesn't shine? Would you prefer to stay > anonymous, that your IP address is not logged with every access to > someone's web page? Then look no further, you've found the solution! This description sounds like a marketing blurb (in fact, it is copied verbatim from the webpage), I think that's not good for a Debian package. IMO it should just explain what is this for, and highlight that it is a paid sarvice. -- Martín Ferrari -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikotbyeez6gy+wdvzyhjdr87-+wcu1kxcemx...@mail.gmail.com
Re: Moving ACL utilities to /bin?
On Thu, Jul 22, 2010 at 12:30, Julien BLACHE wrote: > Are there any reasons or objections against moving the ACL utilities to > /bin, alongside their traditional UNIX counterparts? Note that libacl is > already installed in /lib. Makes sense to me. -- Martín Ferrari -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikn74+pe4fdcgeomffwq8vgj5dpjdy-fmdyh...@mail.gmail.com
Re: ITP: kapow -- a punch clock program
2010/5/7 Tang Ke : > * Package name: tanglet is it called kapow or tanglet? A couple of corrections in the description: > Kapow is designed to easily keep track of your hours, > whether you're working on one project or many.Simply clock in A space is missing after the dot. > and out with the start/stop button. I you make a mistake in s/I/If/ -- Martín Ferrari -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/h2ub9800b71005070842ya506cc2fi910d7a5b38bee...@mail.gmail.com
Re: net-tools future
On Sun, Mar 15, 2009 at 21:52, Brian May wrote: > Martín Ferrari wrote: >> * netstat : sstat provides almost the same information, just some >> formatting changes and parsing the command line > sstat? > > I see /usr/bin/sstat in slurm-llnl - but that doesn't look right. > > What sstat are you referring to here? Sorry, it was meant to say "ss", from the iproute package -- Martín Ferrari -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
Marco, On Sun, Mar 15, 2009 at 15:11, Marco d'Itri wrote: >> * netstat : sstat provides almost the same information, just some >> formatting changes and parsing the command line > While I am happy to see ifconfig and route go, I am not sure that > netstat is in the same category and should be replaced with something > which is not 100% compatibile in the output. The idea is to provide a wrapper with the same output as the original netstat -- Martín Ferrari -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
net-tools future
Hi, Luk Claes and me, as the current maintainers of net-tools, we've been thinking about it's future. Net-tools has been a core part of Debian and any other linux based distro for many years, but it's showing its age. It doesnt support many of the modern features of the linux kernel, the interface is far from optimal and difficult to use in automatisation, and also, it hasn't got much love in the last years. On the other side, the iproute suite, introduced around the 2.2 kernel line, has both a much better and consistent interface, is more powerful, and is almost ten years old, so nobody would say it's untested. Hence, our plans are to replace net-tools completely with iproute, maybe leading the route for other distributions to follow. Of course, most people and tools use and remember the venerable old interface, so the first step would be to write wrappers, trying to be compatible with net-tools. At the same time, we believe that most packages using net-tools should be patched to use iproute instead, while others can continue using the wrappers for some time. The ifupdown package is obviously the first candidate, but it seems that a version using iproute has been available in experimental since 2007. So, the roadmap would be: - Send patches to net-tools using packages to use iproute instead - Development of the wrapper scripts - Uploading to experimental a net-tools-compat package, to allow wider testing. - Upload to unstable About the wrapper scripts: * ipconfig, route: the most difficult ones, both can be replaced by calls to "ip", maybe except for some obscure options. * netstat : sstat provides almost the same information, just some formatting changes and parsing the command line * rarp should be dropped, as the linux kernel doesn't support it anymore, since the 2.3 series. The replacement, arpd, is already included in iproute. * ipmaddr works exactly as "ip maddr", in fact, the code is from the iproute sources. Same for iptunnel and "ip tunnel". In both cases, they're just replaced by a symlinkm, as the ip command recognises that. * nameif: can be replaced by "ip link", not sure if it's worth the effort (does anybody actually use it?) Problematic tools: * mii-tool: it could be dropped and replaced by a pointer to ethtool as it's not meant to be used automatically by scripts. On the other hand, it's distributed as a stand-alone tool [0] and we could do the same. * plipsetup, slattach: we don't know of any replacement for those, but could be distributed separately too. Also, it's dubious if anyone still uses them. 0: http://freshmeat.net/projects/mii-tool/ -- Martín Ferrari signature.asc Description: This is a digitally signed message part
Re: can buildd logs be sorted (again)?
Hi, On Wed, Oct 29, 2008 at 21:11, Thomas Viehmann <[EMAIL PROTECTED]> wrote: >> Can this be fixed? The current situation is less than useful since >> the latest build is buried in other output. > > If someone could attest to > http://buildd.debian.org/~tviehmann/cmp_versions_php.txt > (translated from the perl that udd uses) being wrong in only harmless > ways (except showing that C->Perl->PHP with the last step being done by > someone disliking PHP is not a good idea), I could ask Ryan to put > http://buildd.debian.org/~tviehmann/build.php > in the appropriate location. If it's of any use, the PET project has a implementation from scratch of Debian version comparison, made by reading policy and dpkg code. The only bug I know of is that it doesn't reject some invalid versions. -- Martín Ferrari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497584: ITP: cosign -- Web single sign-on for intranets
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" <[EMAIL PROTECTED]> * Package name: cosign Version : 2.1.0rc1 Upstream Author : The University of Michigan * URL : http://weblogin.org/ * License : MIT Programming Lang: C Description : Web single sign-on for intranets An open source project originally designed to provide a secure single sign-on web authentication system, with support for different authentication backends and fault tolerance by means of replicated servers. Cosign includes an Apache module for authentication in distributed applications, CGI scripts tmo handle logon/logoff and a session tracking daemon. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unusual version numbering systems
Hi, On Wed, Aug 27, 2008 at 08:51, Dominic Hargreaves <[EMAIL PROTECTED]> wrote: > I'm asking now in case there is another option which would require me > doing something different for 4.21. I'd add zeroes to the right, to have always two digits after the point, which can be done automatically with a uversionmangle rule if you use uscan and watchfiles. And in this way, the "invented" version is documented. -- Martín Ferrari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ecki is retiring (Debian RT)
On Fri, Jun 13, 2008 at 13:55, Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > net-tools -> Robert Edmonds has offered to ITA this package, but I think we > need a second maintainer as long as net-tools is important severity. Maybe > Martin wants to help, he already is part of the upstream team. > > http://net-tools.berlios.de/ Sure. Although I did a poor job because of lack of time, I'd gladly co-maintain it. An alioth group would be the best. -- Martín Ferrari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Time to phase out net-tools?
Hi, On Fri, Jun 13, 2008 at 13:04, Thijs Kinkhorst <[EMAIL PROTECTED]> wrote: > With wrapper scripts, are you only talking about the interface to set > stuff or would you also want to mimick the existing output? Because I > think the output from commands like ifconfig and route is so old and > well-known that people rely on it both in scripts and just in mental > parsing. Both, I know that many people had written stuff on top of that output and interface. > net-tools doesn't suffer any showstoppers, is there a good reason to > replace it at this time? iproute is indeed much better, but it is not even > part of a standard Debian install currently. Maybe that's something that > we should start with if we want to migrate towards iproute. It's not something to be done in a day. But I think that given the amount of bug net-tools has, and the fact that it can't do much of the cool stuff provided by 2.4+ kernels, it's time for its retirement. And yes, iproute should become priority important. -- Martín Ferrari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Time to phase out net-tools?
Hi, After reading that Bernd orphaned net-tools I decided to share this feeling I have since some time ago. Net-tools has been very useful for us during all this years, but we have a much more powerful and clean tool since years ago: iproute. Maybe it's time for us to drop net-tools altogether and just write the compatibility scripts as iproute wrappers? I think that the iproute manual even has some sample scripts that do exactly this. What do you think? -- Martín Ferrari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#484767: ITP: libpoe-component-pluggable-perl -- base class for creating plugin enabled POE Components
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" <[EMAIL PROTECTED]> * Package name: libpoe-component-pluggable-perl Version : 1.06 Upstream Author : Chris 'BinGOs' Williams <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/POE-Component-Pluggable/ * License : Artistic | GPL-1+ Programming Lang: Perl Description : base class for creating plugin enabled POE Components POE::Component::Pluggable is a base class for creating plugin enabled POE Components. It is a generic port of POE::Component::IRC's plugin system. If your component dispatches events to registered POE sessions, then POE::Component::Pluggable may be a good fit for you. Basic use would involve subclassing POE::Component::Pluggable, then overriding _pluggable_event() and inserting _pluggable_process() wherever you dispatch events from. Users of your component can then load plugins using the plugin methods provided to handle events generated by the component. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#482486: ITP: libcddb-perl -- high-level interface to cddb protocol servers (freedb and CDDB)
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" <[EMAIL PROTECTED]> * Package name: libcddb-perl Version : 1.17 Upstream Author : Rocco Caputo <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/CDDB/ * License : Artistic | GPL-1+ Programming Lang: Perl Description : high-level interface to cddb protocol servers (freedb and CDDB) CDDB protocol (cddbp) servers provide compact disc information for programs that need it. This allows such programs to display disc and track titles automatically, and it provides extended information like liner notes and lyrics. This module provides a high-level Perl interface to cddbp servers. With it, a Perl program can identify and possibly gather details about a CD based on its "table of contents" (the disc's track times and offsets). Disc details have been useful for generating CD catalogs, naming mp3 files, printing CD liners, or even just playing discs in an automated jukebox. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
In March, I proposed adding some useful (to me) fields to the control
file, along this idea:
Upstream-Bug-Browser: http://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Curl
Upstream-Bug-Submitter: http://rt.cpan.org/Public/Bug/Report.html?Queue=WWW-Curl
Which were furiously rejected by many people, in the usual and
friendly tone commonly seen in -devel.
> Do that please but keep your fingers off the Packages files. The value
> of your meta information is not worth the costs of its distribution to
> every user's local system.
But just now I saw this in the dpkg changelog:
dpkg (1.7.0) unstable; urgency=low
{..}
* Add Origin and Bugs fields to the control file
{..}
-- Wichert Akkerman <[EMAIL PROTECTED]> Sun, 5 Nov 2000 17:28:39 +0100
Those were documented (or so) in deb-control(5) only last October, so
it's no wonder nobody replied telling me that the idea I had was
already implemented more than 7 years ago! Currently, there are about
two source packages in the archive using these fields.
There's no mention that I could find of those fields in the Debian
Policy nor in the Dev Ref. I guess that reading dpkg source code
should be added as a requirement to the NM templates.
--
Martín Ferrari
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
On Tue, Mar 18, 2008 at 5:17 AM, Ralf Treinen <[EMAIL PROTECTED]> wrote: > > It would be good if this process could be automated, however I suspect > > this header is not the solution. > > Granted, but then you are speaking about giving better tool support for > manually forwarding bugs, which is not the same thing as automatically > forwarding bugs. > > Better tool support would of course be welcome. As I said in a previous email, I chose the wrong word, when I said automatically forwarding bugs, I meant being able to instruct the bts command to forward a bug already in the BTS to upstream, probably preparing a boilerplate text and firing $EDITOR, etc. What I want to achieve is having metadata that then can be used by new tools or augment existing ones. -- Martín Ferrari
Re: Proposing a new source control header to link to upstream BTSs
On Tue, Mar 18, 2008 at 4:53 AM, Andreas Tille <[EMAIL PROTECTED]> wrote: > Sometimes innovation comes silent. I remember times when we > have hidden Homepage information behind 'XCBS-URL'. So why > not using > > XCBS-UpstreamBTS > > or something like that and experiment with this and see how it > might evolve? I assumed that it should start like this, but I guess that asking for opinions on -devel before adding custom fields was expected. -- Martín Ferrari
Re: Proposing a new field in the source control data (was: Proposing a new source control header to link to upstream BTSs)
On Mon, Mar 17, 2008 at 4:37 AM, Ben Finney <[EMAIL PROTECTED]> wrote: > Those pieces of data are called "fields". Just like in RFC2822 > messages or HTTP responses. Thanks for the correction. I always think of headers, because one usually refers to rfc2822 "fields" as "headers", I didn't know it was incorrect. -- Martín Ferrari
Re: Proposing a new source control header to link to upstream BTSs
(reply-to as requested) On Mon, Mar 17, 2008 at 5:45 AM, Bas Wijnen <[EMAIL PROTECTED]> wrote: > > It could be used to automatically forward bugs, > > I don't think bugs should be forwarded automatically. See my previous mail, I did choose the wrong word here. > > track which bugs are open that we don't know about today, > > This would indeed be useful, but if automated tools should be using it > (like DEHS), a lot of work is needed to parse all those bug systems. If > there's a prospect that this work will be done in the near future, then > I agree that the fields would be useful. I thought about the proposal because I'd like to add this kind of information to the package tracking tool used in pkg-perl (and some other groups) [0], of course I know I have to write the parsers :). Parsing RT and (source|g)forge already covers 99.9% of pkg-perl packages. > > and simply to avoid the need to look up manually where should one > > submit a bug. > This is the main reason I dislike the idea. Users shouldn't need to > submit bugs upstream. They use Debian, they submit bugs to Debian, and > if Debian (by means of the maintainer) thinks it's an upstream issue, > Debian forwards it to them. No, of course this is not intended for users, but for Debian developers/maintainers/etc. We already have the watch file, which can be related to this idea. > Given this position, you probably understand that I don't think > providing a link to the upstream BTS is very useful for the users. I agree completely on that premise. But then again, users also don't care about where we host our pakcages' VCS repositories. > It may be interesting information in case the maintainer goes MIA, or > something. Most of the time, Homepage should be enough to find it out, > though. If not, I think it would be good practise to write it in the > package somewhere, but I don't think the control file is a good place > for it. Especially given the very minimal amount of packages where > Homepage doesn't provide the information (and for those cases, upstream > is probably dead, so there isn't really anything useful to say either). It is true that having the homepage you can easily find the bug tracker, but I'm aiming at a different goal that what I thing you understood, which is enabling us to write more tools that help _us_. [0]: http://pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi -- Martín Ferrari
Re: Proposing a new source control header to link to upstream BTSs
On Mon, Mar 17, 2008 at 5:42 AM, Neil Williams <[EMAIL PROTECTED]> wrote: > Please can this 'trend' be stopped here and now? > > The Packages.gz file is already enormous (especially for Emdebian > purposes or other low resource units) and adding yet more fields to > debian/control is really not that friendly. I appreciate the strive to make Debian work on small machines, but it is reasonable to put their constraints on the whole project? > Please use debtags wherever possible for all such metadata - maybe even > migrate some existing data in debian/control to debtags. If I understand correctly, debtags are faceted and not free-form, so you won't be able to enter URLs into it. Other data, like the type of bug tracker, as Russ suggested, could be put in debtags, and it felts like the correct place for doing it. > This specific request, IMHO, is probably best done via links on the > Homepage URL anyway. Can you explain how you'd do this? -- Martín Ferrari
Re: Proposing a new source control header to link to upstream BTSs
Trying to answer some of the problems pointed out to my proposal... On Mon, Mar 17, 2008 at 2:49 AM, Russ Allbery <[EMAIL PROTECTED]> wrote: > I think that if the goal is to support automated tools, pointing to > straight web pages isn't particularly useful without some additional > information. At the least, I'd think we'd want to specify the type of bug > system that upstream is using so that any automated tools would know what > screen scraping or (hopefully) SOAP/REST interfaces they can use. I thought about this too. But I guess that trying to model all the many things that one can find is not realistically doable. An alternative would be to use a watchfile-like system in which you provide regexes to perform the necessary text-mangling, but it has the disadvantage of being much more complex to give basic support to (I have already worked on parsing watchfiles without using uscan...), and that you need to extract a file from the source package to read the information. On the other hand, having the base pointer to the BTS, you can build up tools that can parse some systems, and if you don't know about it, you still have an URL. On Mon, Mar 17, 2008 at 2:59 AM, Paul Wise <[EMAIL PROTECTED]> wrote: > That sort of information (like watch files and homepages) changes > independently of the source package, so it would be better if it were > not added to debian/control. Well, the watch file and the homepage are actually part of the source package already. Also, I don't think that you'll find many upstreams that change BTSs more often than releasing new versions. On Mon, Mar 17, 2008 at 4:59 AM, Ralf Treinen <[EMAIL PROTECTED]> wrote: > > It could be used to automatically forward bugs, [...] > > I do not think that automatically forwarding bugs would be a good idea. Sorry if I didn't choose the exact word, I meant something on the lines of doing "bts submit-upstream-and-forward nn", without you needing to go manually through all the hops that we have to go through today. -- Martín Ferrari
Proposing a new source control header to link to upstream BTSs
Dear -devel: Following the trend to add metadata to the debian/control file that allows for the creation of new and powerful tools, I thought about the usefulness of a header that'd allow to automatically relate to upstream bug trackers. It could be used to automatically forward bugs, track which bugs are open that we don't know about today, and simply to avoid the need to look up manually where should one submit a bug. So, my proposal would be to add two headers that are better explained by an example: Upstream-Bug-Browser: http://rt.cpan.org/Public/Dist/Display.html?Name=WWW-Curl Upstream-Bug-Submitter: http://rt.cpan.org/Public/Bug/Report.html?Queue=WWW-Curl This could easily support systems where submission is by email. And if there's no bug tracking system, the upstream maintainer email could be used, without adding the -Browser header. What do you think of this? -- Martín Ferrari
Re: On the subject of watchfiles (was Re: Proposed MBF: Debian upstream version higher than watch file-reported upstream version)
Hi Jon, On Tue, Feb 26, 2008 at 11:20 AM, Jon Dowland <[EMAIL PROTECTED]> wrote: > > Is it worth investing much effort into debugging watch file > issues? In my experience, yes. I can cite the example of the perl group: 679 packages group maintained. You'll guess that there's no way in earth a small group of people can track such amount of packages manually. We heavily rely on the watchfiles for detecting new upstream releases, and the tool we use (http://pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi) automates that for us. We go to great lengths to make every package have the correct watch information. Of course, we have luck, because CPAN (99% of our packages come from there, and we have only 4 unsolvable watch problems) is pretty well-behaving and consistent, compared to other upstreams. But chances are that watchfiles can be useful for the majority of people. -- Martín Ferrari
Bug#465742: ITP: libpoe-component-server-soap-perl -- POE component to publish event handlers via SOAP over HTTP
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" <[EMAIL PROTECTED]> * Package name: libpoe-component-server-soap-perl Version : 1.11 Upstream Author : Apocalypse <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/POE-Component-Server-SOAP/ * License : Perl (Artistic | GPL-1+) Programming Lang: Perl Description : POE component to publish event handlers via SOAP over HTTP POE::Component::Server::SOAP is a bolt-on component that can publish event handlers via SOAP over HTTP. Currently, this module only supports SOAP/1.1 requests, work will be done in the future to support SOAP/1.2 requests. The HTTP server is done via POE::Component::Server::SimpleHTTP. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23-1-686 (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465545: ITP: libpoe-component-server-simplehttpd-perl -- simple HTTP server for POE
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" <[EMAIL PROTECTED]> * Package name: libpoe-component-server-simplehttpd-perl Version : 1.40 Upstream Author : Apocalypse <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/POE-Component-Server-SimpleHTTP/ * License : Perl (Artistic | GPL-1+) Programming Lang: Perl Description : simple HTTP server for POE POE::Component::Server::SimpleHTTP is Perl extension to easily serve HTTP requests within the POE framework. It supports SSL and pre-forking if libpoe-component-sslify-perl and libipc-shareable-perl, respectively, are installed. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.23-1-686 (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: libjs-scriptaculous -- is a user interface JavaScript libraries
On Feb 7, 2008 1:03 PM, Marcelo Jorge Vieira (metal) <[EMAIL PROTECTED]> wrote: > Description: is a user interface JavaScript libraries I think that you should drop the "is a", as the Dev Ref recommends. -- Martín Ferrari
Bug#454564: ITP: libjtds-java -- Pure Java (type 4) JDBC 3.0 driver for Microsoft SQL Server and Sybase
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" <[EMAIL PROTECTED]> * Package name: libjtds-java Version : 1.2.2 Upstream Author : The jTDS Project <[EMAIL PROTECTED]> * URL : http://jtds.sourceforge.net/ * License : LGPL Programming Lang: Java Description : Pure Java (type 4) JDBC 3.0 driver for Microsoft SQL Server and Sybase jTDS is an open source JDBC 3.0 Type 4 driver for Microsoft SQL Server (6.5, 7.0, 2000 and 2005) and Sybase (10, 11, 12, 15). jTDS is the fastest JDBC driver for MS SQL Server and is a complete implementation of the JDBC spec. jTDS is the most performant JDBC driver for both Microsoft SQL Server and Sybase. It is a complete implementation of JDBC 3.0, it passes the J2EE 1.3 certification and Hibernate test suites and is the preferred SQL Server/Sybase driver for JBoss, Hibernate, Atlassian JIRA and Confluence, DbVisualizer and Compiere. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (901, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#451799: new evince cannot display Japanese characters correctly
(Dropping -legal from the cc) On Nov 27, 2007 3:56 PM, Josselin Mouette <[EMAIL PROTECTED]> wrote: > The new poppler version needs some specific files that contain some > mappings between Unicode and other encodings, which are in a separate > package. That's all that it contains? can't that be reproduced with data from iconv or similar? -- Martín Ferrari
Re: The status of libapache2-mod-perl2
On 8/16/07, Gunnar Wolf <[EMAIL PROTECTED]> wrote: > - Should we hijack/adopt the package, or will its current maintainers > stand up and get it back to life? > - Is there somebody who wants to lead this? > - Pkg-perl and/or Apache groups: Do you agree? :) > - In any other case: Other takers? I think that such an important module would benefit from group maintenance, be it the apache or the perl group. I don't think I have all the knowledge to lead it, but I can help. I have used mod_perl a lot, know enough C, and I'm already somewhat familiar with basic perlguts. -- Martín Ferrari
Bug#431803: ITP: pyctures -- Small and simple web gallery for pictures
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" <[EMAIL PROTECTED]> * Package name: pyctures Version : 0.20 Upstream Author : Alberto Bertogli <[EMAIL PROTECTED]> * URL : http://auriga.wearlab.de/~alb/pyctures/ * License : BOLA (Public Domain) plus some 3rd party modules (BSD, MIT & Public Domain) Programming Lang: Python Description : Small and simple web gallery for pictures pyctures is a small web gallery written in Python that uses the web.py framework. It does not use any database and stores all the necessary data in the filesystem. It does not intend to be as featureful as other galleries, just to be comfortable to browse. Most of the administration tasks are performed by manual file manipulation, so the owner is expected to be comfortable doing UNIX administration. It comes with one simple CSS-based style, and the HTML templates are isolated from the code, so it's very easy to modify. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (901, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores) Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What happened to popcon graphs?
On 5/31/07, Nico Golde <[EMAIL PROTECTED]> wrote: Hi, Anyone knows why the popcon graphs on: http://qa.debian.org/popcon.php?package= are missing? This seems to explain the problem: GET 'http://people.debian.org/~igloo/popcon-graphs/graph.php?packages=vtun&show_installed=1&show_vote=1&show_old=1&show_recent=1&show_nofiles=1&want_percent=0&want_legend=1&want_ticks=1&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m' Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 21 bytes) in /home/igloo/public_html/popcon-graphs/graph.php on line 80 Maybe the popcon database grew too big to be handled in-memory by those scripts -- Martín Ferrari
passing options to modules loaded in initramfs
Hi, After some discussion on IRC I was about to file a bug on the kernel, but I'm still not convinced if that's appropiate, as there are various ways to tackle this. So, please, give me your opinion on this. I found that some very critical cmdline options for booting aren't honoured anymore (I have an old computer that will exhibit various problems because of incorrect dma detection with recent kernels). I could finally dig that this is because drivers/ide/ide.c goes into a module in default debian kernels, and modules don't read cmdline. Now I found that the solution is very simple, adding the option as if the module was loaded post-init and then running update-initramfs. But I find this very non-obvious, and not very nice if you cannot boot. I had to read kernel code to find out what source file was responsible of this, to find that it is a module in Debian, then understanding that initramfs just copies /etc/modules.d and uses it. Maybe I'm a dummy, but I needed to do all that. I couldn't find anywhere in the net something describing all this process, but lots of references to the standard way of passing options from grub/lilo. To make things more confusing, when I installed, somehow I didn't have DMA problems. I think I deducted from the isolinux help that I could use ide-core.ide=nodma. A idiom that doesn't work with the installed kernel+initramfs. So, this could be handled by various ways: - Putting notices in relevant places so that everybody can understand what's happening (release notes, FAQs, package documentation..) - Compiling with CONFIG_BLK_DEV_IDE=y (Ubuntu does this) - Using Kyle McMartin's recent proposed patch [0] that enables modules to read cmdline. - Adding more intelligence to initramfs to detect this options and pass them to the correct module (I think it already does this for a couple of options), or using the same syntax as d-i (this seems easy to add, although it differs from historic usage). Thoughts? [0] http://lkml.org/lkml/2007/4/18/212 -- Martín Ferrari
Re: net-tools maintenance status
Hi again, On 4/5/07, Martín Ferrari <[EMAIL PROTECTED]> wrote: I don't know if I will be able to apply for co-maint, but I started working a little on triaging. Hope it helps. I've spent a lot of hours working on net-tools bugs, 17 of them if I don't miss anything. I usertagged them, so if any other is working on it can see what I've done so far: http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]&tag=working-on-it -- Martín Ferrari
Re: net-tools maintenance status
I'm copying Olaf, since he asked for it in the OP, and Bernd, since he's the maintainer. On 4/3/07, Michael Banck <[EMAIL PROTECTED]> wrote: Hi, On Tue, Apr 03, 2007 at 02:09:00PM +0200, Olaf van der Spek wrote: > On 8/2/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > >What's the maintenance status of the net-tools package? Are you applying for co-maintenance? If so, you should rather talk the the package maintainer, I think. Alternatively, you could do some bug triaging and/or trying to reproduce the older bugs, if you haven't done so already. I don't know if I will be able to apply for co-maint, but I started working a little on triaging. Hope it helps. -- Martín Ferrari
Re: IPW3945
Hi, On 11/11/06, Jurij Smakov <[EMAIL PROTECTED]> wrote: I have just updated http://www.wooyd.org/debian/ipw3945-daemon/ with the new version of the package, which I consider to be uploadable quality. If you have a chance, please test it. Unless some major issue will pop up, I'm going to upload it on Sunday. I have it running now from your package, and it's working just fine! It loads correctly on boot, and modprobe / modprobe -r handles correctly the daemon. This combined with wpa_supplicant made me have automatic wireless networking on boot, without much hassle. The only thing left now is to have a working driver package. I don't know which work is the most current to test it out. Thanks for your work! -- Martín Ferrari
Re: Status of IPW3945 (Was: IPW3945)
On 11/12/06, Darren Salt <[EMAIL PROTECTED]> wrote: [snip] > I think we should wait until the next firmware version is out; > that way we'll avoid the binary only regulatory daemon. Yes, but that could be released too late for inclusion in etch - if it's not too late already :-) I agree completely. It would be much better to have non-free support for etch that no support at all! -- Martín Ferrari
Re: IPW3945
On 11/8/06, Jurij Smakov <[EMAIL PROTECTED]> wrote: > The only thing I could find was http://www.wooyd.org/debian/ipw3945-daemon/ Yes, this is my site and ipw3945-daemon is the work in progress.. We had some discussions about its design issues recently [0], which are pretty much settled now, so I hope to finish and upload the package sometime later this week. [0] Thread starting with http://lists.debian.org/debian-kernel/2006/10/msg00374.html I don't see in that thread that the issues are settled, but I'll belive you :) If you need help, I can test and/or help fixing bugs. I have the hardware and I'm eager to stop using ubunu's packages for this. -- Martín Ferrari
IPW3945
Hi, I am wondering what is the status/current work being done on supporting the ipw3945 wireless card on Debian. In non-free I can find the firmware package, but I couldn't find the non-free regulatory daemon nor the free kernel driver. I would like to work on that, but I don't want to duplicate work. The only thing I could find was http://www.wooyd.org/debian/ipw3945-daemon/ And currently, there are problems with the debian version of 80211 and the 1.0 driver from intel, that prevented me from compiling it by hand. This is a very common card and I would like to see it fully supported in Debian -- Martín Ferrari
Re: 2.4 vs. 2.6 (was: Re: Moving /var/run to a tmpfs?)
On 9/17/06, Hendrik Sattler <[EMAIL PROTECTED]> wrote: A good hint for such cases is to actually report such bugs to the driver developers. Did you? You must have pretty uncommon hardware, though, as many use 2.6 kernels without such problems... I have an old server with 2.4 because 2.6 won't run on it. Not big deal, it doesn't need 2.6 anyway... -- Martín Ferrari
Re: Orphaning my packages
On 9/13/06, gregor herrmann <[EMAIL PROTECTED]> wrote: Just take a look at http://pkg-perl.alioth.debian.org/ and start working :-) Feel free to ask any questions an [EMAIL PROTECTED] Thanks!! -- Martín Ferrari
Re: Orphaning my packages
On 9/13/06, Gunnar Wolf <[EMAIL PROTECTED]> wrote: I was planning on starting the wide adopting process to the group, but if you can help, much better. In my experience, the pkg-perl group has helped me not appear like an irresponsable maintainer (which I am! :-P ) during my stress periods. So, Mart�n, if you are not currently part of the group, I can add you - just give me your Alioth user name and promise to do no intentional harm. it is tincho-guest. I have no experience with maintaining within a group, but I will be happy to learn :) -- Martín Ferrari
Re: Orphaning my packages
On 9/12/06, David Moreno Garza <[EMAIL PROTECTED]> wrote: If you think you could adopt some of the packages, feel free to do it (filling an ITA would be nice). Just talk to the Debian Perl Group first, if thinking on adopting some of the Perl modules; talk first to the pkg-ruby-extras groups if thinking on adopting some of the ruby modules, also. I'd like to adopt some of the -perl packages, but I don't know what has to be coordinated with the perl group. Can somebody comment? Thanks. -- Martín Ferrari
