Bug#1056784: ITP: bankstown -- barebones, fast LV2 bass enhancement plugin
On Sun, Nov 26, 2023 at 04:18:33PM +0100, Andreas Henriksson wrote: > Hello Jonas, > [...] > I've now renamed the *binary* package to bankstown-lv2, [...] Oh well, I'm renaming the source as well. I guess we can always rename our git repo to match and pretent like everything is bankstown-lv2. Just for comparison, I downloaded all sources for binary packages called '*-lv2' and 5 of 15 had -lv2 suffix in the orig tarball name (so 1/3). Regards, Andreas Henriksson
Bug#1056784: ITP: bankstown -- barebones, fast LV2 bass enhancement plugin
Hello Jonas, Thanks for your quick followup and thoughts. On Sun, Nov 26, 2023 at 03:59:34PM +0100, Jonas Smedegaard wrote: [...] > ...but then next year new shiny upstream project "dot" gets packaged not > as "dot-lv2" but "dot" because there is a precedence for lv2 packages to > use no affix. There's no such precedence. I've now renamed the *binary* package to bankstown-lv2, to somewhat align with the precedence of lv2 plugins currently in debian. [...] > Why do you call it mangling to pick another of upstream's multiple > names? They chose one name at crates.io and another at Github. In my experience it is constant hassle to get debian tooling to line up properly with a different name than what the source of the orig tarball calls it. The github tarball is called bankstown. Still not convinced renaming the source is worth it. How strongly do you feel using plain bankstown for source is a problem? (Atleast it's not a three letters acronym, unlike some other recently uploaded packages.) > > And why do you find it important to align source package name with > source package name of (non-derived) distros? If you think derivates are more important to consider than non-derivates you can simply replace Fedora Asahi Remix with Ubuntu Asahi. Regards, Andreas Henriksson
Bug#1056784: ITP: bankstown -- barebones, fast LV2 bass enhancement plugin
Hello Jonas, On Sun, Nov 26, 2023 at 12:45:02PM +0100, Jonas Smedegaard wrote: > Quoting Andreas Henriksson (2023-11-26 09:27:32) > > Package: wnpp > > Severity: wishlist > > Owner: Andreas Henriksson > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: bankstown > [...] > > Naming > > --- > > Upstream name: bankstown > > crates.io name: bankstown-lv2 > > > > My proposition is that we use the upstream name as debian source name > > (bankstown) and then use `lv2-bankstown` binary package name, as > > bankstown is a lv2 plugin and that would fit generic naming conventions > > in Debian about packages fitting into a particular ecosystem. > > Please consider using "bankstown-lv2" for both source and binary > package, to not needlessly consume multiple global namespaces. I have been considering, but please help convince me. Pro bankstown-lv2: - not needlessly consume multiple global namespaces. This argument is just saying binary and source name should match, right? - matches crates.io name. - matches what atleast some other lv2 plugins are doing in debian. Cons: - (source) does not match the upstream (git repo) name (bankstown). - does not follow the system-subsystem pattern commonly used in debian. - does not match what other distributions are doing (atleast not Fedora Asahi Remix, which is the reference distribution). It is my opinion that the bankstown name, in any form, is unique enough that noone should need to collide with it. My main worry would be if lv2 itself grew a subsystem called bankstown, which would then be lv2-bankstown as well, but see previous statement about the bankstown uniqueness. For me the strongest pro argument is probably that other lv2 plugins in debian seems to point to the pluginname-lv2 pattern, but not really enough to completely convince me (atleast not for source name). For the source name, if we're going to mangle it maybe I should atleast there follow fedora naming of `rust-bankstown-lv2` which would also align with the Debian rust-team naming convention? I really would like to avoid mangling source name though... Regards, Andreas Henriksson
Bug#1056784: ITP: bankstown -- barebones, fast LV2 bass enhancement plugin
Package: wnpp Severity: wishlist Owner: Andreas Henriksson X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: bankstown Version : 1.0.0 Upstream Contact: https://github.com/chadmed/bankstown/issues * URL : https://github.com/chadmed/bankstown * License : MIT Programming Lang: Rust Description : barebones, fast LV2 bass enhancement plugin Description --- Speakers found in small devices have trouble reproducing bass and sub-bass faithfully. This is because they are power and space constrained, and cannot move the amount of air required to reproduce such low frequencies at audible volumes. Designers of modern devices get around this problem by taking advantage of the fact that humans are very easy to fool. We generate harmonics of bass and sub-bass frequencies to trick the human brain into thinking there is more bass than there really is. . This package contains a lv2 plugin implementing halfway-decent three-stage psychoacoustic bass approximation. Team maintenance --- I've discussed both with Debian rust-team and bananas-team and we've concluded that since this package does not yet integrate well with existing debcargo-conf tooling, we'll maintain the package under the bananas-team umbrella. Preliminary packaging is available at: https://salsa.debian.org/bananas-team/bankstown Naming --- Upstream name: bankstown crates.io name: bankstown-lv2 My proposition is that we use the upstream name as debian source name (bankstown) and then use `lv2-bankstown` binary package name, as bankstown is a lv2 plugin and that would fit generic naming conventions in Debian about packages fitting into a particular ecosystem. For reference, fedora packaging: https://src.fedoraproject.org/rpms/rust-bankstown-lv2/blob/rawhide/f/rust-bankstown-lv2.spec
Bug#1055897: ITP: speakersafetyd -- speaker protection daemon for embedded Linux systems
Package: wnpp Severity: wishlist Owner: Andreas Henriksson X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: speakersafetyd Version : 0.1.4 Upstream Contact: https://github.com/AsahiLinux/speakersafetyd/issues * URL : https://github.com/AsahiLinux/speakersafetyd/ * License : MIT Programming Lang: Rust Description : speaker protection daemon for embedded Linux systems Speaker protection for Apple Silicon (and potentially other) laptops with built-in speakers. The Apple M1, M2, etc laptops do not have protection for melting speakers in hardware, so need this (unlike many other laptops). The implementation is generic enough that it could in the future support other systems as well (eg. many embedded systems might be in the same situation if they have speakers). I hope to maintain this package in the rust-team (with the help of the bananas-team). Preliminary packaging available at: https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/560 See also: https://wiki.debian.org/Teams/Bananas Regards, Andreas Henriksson
Bug#1055634: ITP: asahi-nvram -- NVRAM utilities for Apple Silicon (arm) machines
Package: wnpp Severity: wishlist Owner: Andreas Henriksson X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: asahi-nvram Version : 0.2.0-1 Upstream Contact: https://github.com/WhatAmISupposedToPutHere/asahi-nvram/issues * URL : https://github.com/WhatAmISupposedToPutHere/asahi-nvram/ * License : MIT Programming Lang: Rust Description : NVRAM utilities for Apple Silicon (arm) machines I intend to package the asahi-nvram utilities that are useful for Apple Silicon (arm) machines, eg. m1 and m2 (probably also m3, etc). The asahi-nvram includes the following tools (which are separate crates and will thus likely be uploaded as separate source packages): * asahi-nvram - generic utility * asahi-btsync - sync MacOS bluetooth settings to bluez * asahi-wifisync - sync MacOS wifi settings to iwd * asahi-bless - select active boot partition (These all use a common apple-nvram crate/library for parsing the nvram content.) The intention is that the packages will be maintained within the rust-team (with support from the bananas-team) and a MR is available for review at: https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/555 Regards, Andreas Henriksson
Bug#1055198: ITP: lzfse -- LZFSE Compression library
Hello, On Sat, Nov 04, 2023 at 08:47:11PM +0100, Timo Röhling wrote: > Hi, > > * Andreas Henriksson [2023-11-04 18:05]: > > I've previously suggested that maybe it would be better to set a > > debian-specific version (0d?), to avoid the theoretical situation that > > upstream one day ships a different ABI under the 1 so version. > Normally, I would agree, but in this particular case, Fedora already went > ahead and used SOVERSION 1 [1], so that version is "burned" and we might > just as well use it, too. > > [1] https://src.fedoraproject.org/rpms/lzfse/blob/rawhide/f/60.patch Thanks for pointing this out! > > > I would welcome peoples input here on what you think is best from the > > debian perspective. Obviously we're going to be incompatible with > > everyone else. > I don't think that "incompatible" patch you linked creates much of an issue, > because very few (if any) other library consumers will do this rather > unusual dlopen() "soft linking" dance (normal linking with e.g. "gcc > -llzfse" will automatically use the proper SONAME); besides, it is easy to > patch in Debian packages and trivial to work around with "apt install > liblzfse-dev" for everyone else. > > I do have one remark, though: the idea behind SONAME/SOVERSION is that you > have a common name for all versions which are binary backwards compatible. > Using the full version liblzfse.so.1.0 instead of libltfse.so.1 (i.e., the > SONAME) in your patch defeats that purpose: it will only work with the exact > version 1.0, but not any (hypothetical) future, backwards-compatible > versions. I hope I understood you correctly and this now adresses your concerns: https://salsa.debian.org/bananas-team/asahi-fwextract/-/commit/bfbd6f53c2e8721b9457c3a37421280a8a86dbc8 Regards, Andreas Henriksson
Bug#1055206: ITP: asahi-fwextract -- Asahi Linux firmware extractor
Hello, Filling out some of the missed information below and also providing some random thoughts of my own on this. On Thu, Nov 02, 2023 at 09:49:51AM +0100, Tobias Heider wrote: > Package: wnpp > Severity: wishlist > Owner: Tobias Heider > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: asahi-fwextract > Version : 0.6.12 > Upstream Authors: Asahi Linux Contributors > URL : https://github.com/AsahiLinux/asahi-installer/tree/main/asahi_firmware > * License : MIT > Description : Asahi Linux firmware extractor > > Scripts to extract firmware blobs from an EFI partition set up by the > Asahi Linux installer. > > I am planning to maintain this as part of the bananas team. > The firmware extractor is part of upstreams (custom) installer-repository. It also depends on asahi-scripts[1] which contains the asahi-fwupdate utility, et.al. This also contains initramfs integration to make the firmwares available during early boot and then provided as a tmpfs under /lib/firmware/vendor in the running system. Preliminary packaging is available at: https://salsa.debian.org/bananas-team/asahi-fwextract https://salsa.debian.org/bananas-team/asahi-scripts Some random thoughts: AIUI currently only initramfs-tools integration is shipped, but maybe it would be good to also provide dracut integration (as provided by upstream, if possible to integrate with debians dracut packaging)?! I don't see any asahi-scripts ITP yet. Since asahi-scripts is a dependency of asahi-fwextract I would have expected one to be posted before this. Maybe the multiple-upstream-tarballs feature could be used to package them together? But it's possibly more problems then benefits. Maybe the asahi-scripts should have a less generic binary package name? and split into multiple packages? Regards, Andreas Henriksson [1]: https://github.com/AsahiLinux/asahi-scripts
Bug#1055198: ITP: lzfse -- LZFSE Compression library
On Thu, Nov 02, 2023 at 01:04:03AM +0100, Tobias Heider wrote: > Package: wnpp > Severity: wishlist > Owner: Tobias Heider > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: lzfse > Version : 1.0 > Upstream Authors: > URL : https://github.com/lzfse/lzfse > * License : BSD-3-Clause > Description : LZFSE Compression library > > LZFSE is a Lempel-Ziv style data compression algorithm using Finite > State Entropy coding. It targets similar compression rates at higher > compression and decompression speed compared to deflate using zlib. > > I plan to maintain this as part of the bananas team. Calling all SO versioning experts! The upstream project does not have any shared object version set. A downstream patch was introduced to set one: https://salsa.debian.org/bananas-team/lzfse/-/blob/debian/unstable/debian/patches/0001-debian-set-library-SONAME.patch Upstream has seen no activity since 2017, so trying to interact is assumed to not generate much. Also the ABI is unlikely to change (since no changes are being made). I've previously suggested that maybe it would be better to set a debian-specific version (0d?), to avoid the theoretical situation that upstream one day ships a different ABI under the 1 so version. I would welcome peoples input here on what you think is best from the debian perspective. Obviously we're going to be incompatible with everyone else[1], unless you install/runtime-depend-on the -dev package for the unversioned so symlink. Please speak now before this is submitted for NEW. FWIW lzfse is needed to extract files compressed by Apple and shipped in macOS containing embedded firmwares. See asahi-fwextract ITP: #1055206 Regards, Andreas Henriksson [1]: https://salsa.debian.org/bananas-team/asahi-fwextract/-/blob/debian/unstable/debian/patches/0001-Use-versioned-library-name-for-liblzfse.patch
Bug#1042471: ITP: u-boot-asahi -- u-boot bootloader for Apple silicon systems
Hello Tobias Heider, While I'm as entusiastic as anyone else here, I have to ask a few questions that might be a bit skeptical below... On Fri, Jul 28, 2023 at 10:00:35PM +0200, Tobias Heider wrote: > Package: wnpp > Severity: wishlist > Owner: Tobias Heider > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: u-boot-asahi > Version : 2023.04-2 > Upstream Authors: Mark Kettenis > URL : https://github.com/AsahiLinux/u-boot This is a development repository and things are sent upstream to u-boot (mainline). The upstreaming effort is driven by the person you listed as author (while actual authors is usually someone else AFAIK). Is there any other u-boot development forks being packaged in Debian and how viable do you think this is? Is the plan to eventually provide a migration to u-boot-asahi binary package provided by src:u-boot or how do you see the future path of this? Is this targeting Trixie or Experimental? Is there any particular reason you're targeting u-boot? Are you planning on working on any installer? Also planning on packaging linux-asahi development repo? Do you have contact with upstream about this? They have been very vocal about distros shipping things that causes additional problems for (users and then in turn for) the Asahi project in the past. (Also atleast some Asahi team members are already not publishing their development git branches because of fear of people dumping them into distros.) How does this effort compare against Thomas Glanzmann effort[1]? Do you plan to provide a migration path (and why would users migrate over to debian-bananas effort instead of Glansmanns effort)? (IMHO while Glanzmanns effort is not my preferable packaging style, it provides a very good stop gap solution until everything has been mainlined into u-boot, linux, mesa which in turn then and only then makes it ready for proper Debian packaging. Apart from mainlining work which hopefully will happen without any assintance from Debian, the biggest challange is probably to provide a sane installer solution acceptable for Debian. Is this a task the bananas team intends to take on?) Something that I think is missing in Glanzmanns effort is providing https://github.com/AsahiLinux/alsa-ucm-conf-asahi which is needed for audio out on the mic/headphone jack. Would be great if these files found a home in some existing (or possibly new) package in Debian if you're looking for somewhere to invest your time. (The alsa-ucm-conf package currently provides all files currently offered by Debian.) > * License : GPL-2 > Description : A u-boot bootloader for Apple silicon systems > [... snip generic u-boot description ...] > > u-boot is used as a second stage bootloader for Linux on M1/M2 Apple macs. AFAIK and FWIW u-boot is in this case used to provide an EFI(-like) environment (to be able to use generic distro bootloaders as the next step in the boot chain). > This will be maintained by the Debian Bananas team. I'm not familiar with this team, is there anywhere to read up on its purpose and background or maybe you can give an introduction to this team? I found https://salsa.debian.org/bananas-team which links to the InstallingDebianOn/Apple/M1 wiki page which has no information as far as I can see about the Bananas team. Regards, Andreas Henriksson [1]: https://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian
Bug#1026274: ITP: golang-github-vmihailenco-msgpack.v5 -- MessagePack (msgpack.org) encoding for Golang
Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson
* Package name: golang-github-vmihailenco-msgpack.v5
Version : 5.3.5-1
Upstream Author : Vladimir Mihailenco
* URL : https://github.com/vmihailenco/msgpack
* License : BSD-2-clause
Programming Lang: Go
Description : MessagePack (msgpack.org) encoding for Golang
MessagePack encoding for Golang
.
Features
.
* Primitives, arrays, maps, structs, time.Time and interface{}.
* Appengine \*datastore.Key and datastore.Cursor.
* CustomEncoder/CustomDecoder interfaces for custom encoding.
* Extensions to encode type information.
* Renaming fields via msgpack:"my_field_name" and alias via
msgpack:"alias:another_name".
* Omitting individual empty fields via msgpack:",omitempty" tag or all
empty fields in a struct.
* Map keys sorting.
* Encoding/decoding all structs as arrays or individual structs.
* Encoder.SetCustomStructTag with Decoder.SetCustomStructTag
can turn msgpack into drop-in replacement for any tag.
* Simple but very fast and efficient queries.
This is a dependency for upcoming mender-connect packaging.
Note that .v2 of this package is already available, but this is .v5.
Bug#1026273: ITP: golang-github-vmihailenco-tagparser.v2 -- Opinionated Golang tag parser
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-vmihailenco-tagparser.v2 Version : 2.0.0-1 Upstream Author : Vladimir Mihailenco * URL : https://github.com/vmihailenco/tagparser * License : BSD-2-clause Programming Lang: Go Description : Opinionated Golang tag parser Opinionated Golang tag parser This is a dependency for the upcoming mender-connect packaging. (Actually a dep of golang-github-vmihailenco-msgpack.v5 and not mender-connect directly.) Note that an non-API-versioned version of this is already available in the archive, but this is .v2.
Bug#1026272: ITP: golang-github-go-ozzo-ozzo-validation.v4 -- idiomatic Go (golang) validation package.
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-go-ozzo-ozzo-validation.v4 Version : 4.3.0-1 Upstream Author : Ozzo Framework * URL : https://github.com/go-ozzo/ozzo-validation * License : Expat Programming Lang: Go Description : idiomatic Go (golang) validation package. ozzo-validation is a Go package that provides configurable and extensible data validation capabilities. It has the following features: . * use normal programming constructs rather than error-prone struct tags to specify how data should be validated. * can validate data of different types, e.g., structs, strings, byte slices, slices, maps, arrays. * can validate custom data types as long as they implement the Validatable interface. * can validate data types that implement the sql.Valuer interface (e.g. sql.NullString). * customizable and well-formatted validation errors. * error code and message translation support. * provide a rich set of validation rules right out of box. * extremely easy to create and use custom validation rules. This package is a dependency for the upcoming mender-connect packaging.
Bug#1026275: ITP: mender-connect -- remote shell access add-on
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: mender-connect Version : 2.1.0-1 Upstream Author : Nothern.Tech * URL : https://github.com/mendersoftware/mender-connect * License : Apache-2.0 Programming Lang: Go Description : remote shell access add-on Mender: remote shell access add-on . Mender is an open source over-the-air (OTA) software updater for embedded Linux devices. Mender comprises a client running at the embedded device, as well as a server that manages deployments across many devices. See: https://tracker.debian.org/mender-client . This repository contains the remote shell access add-on. It enhances the Mender client (https://github.com/mendersoftware/mender), allowing to log in to the devices remotely and start a shell in a remote terminal session.
Bug#1000284: ITP: golang-github-ant0ine-go-json-rest -- A quick and easy way to setup a RESTful JSON API
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-ant0ine-go-json-rest Version : 3.3.2-1 Upstream Author : Antoine Imbert * URL : https://github.com/ant0ine/go-json-rest * License : Expat Programming Lang: Go Description : A quick and easy way to setup a RESTful JSON API Go-Json-Rest is a thin layer on top of net/http that helps building RESTful JSON APIs easily. It provides fast and scalable request routing using a Trie based implementation, helpers to deal with JSON requests and responses, and middlewares for functionalities like CORS, Auth, Gzip, Status ... . https://godoc.org/github.com/ant0ine/go-json-rest/rest . This package will be maintained under the go-team umbrella and used as a build-dependency for golang-github-mendersoftware-go-lib-micro (once packaged, see ITP).
Bug#1000280: ITP: golang-github-mendersoftware-go-lib-micro -- Group of golang packages for developing microservices.
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-mendersoftware-go-lib-micro Version : 0.0~git20211108.4e20429-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/go-lib-micro * License : Apache-2.0 Programming Lang: Go Description : Group of golang packages for developing microservices. Mender: go-lib-micro Mender is an open source over-the-air (OTA) software updater for embedded Linux devices. Mender comprises a client running at the embedded device, as well as a server that manages deployments across many devices. . This repository contains the Mender go-lib-micro library, which is part of the Mender server. The Mender server is designed as a microservices architecture and comprises several repositories. . The go-lib-micro library is a collection of utilities and middlewares shared among microservices in the Mender ecosystem. . This package will be used as a build-dependency of mender-cli when updating to 1.7.0 (and possibly other mender components). The package will be team-maintained under the go-team umbrella.
Bug#992373: ITP: golang-github-mendersoftware-progressbar -- Minimal progressbar used in Mender projects
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-mendersoftware-progressbar Version : 0.0.3-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/progressbar * License : Apache-2.0 Programming Lang: Go Description : Minimal progressbar used in Mender projects Progressbar: A simple and minimalistic Golang progressbar for Mendersoftware projects. . This is a dependency for updating the mender-client package to new upstream release 3.0.0.
Bug#970428: Prepared new packages for cheggaaa/pb (v1 + v3)
Hello, As already discussed in ITP #970428 I've been pondering packaging v3 of what was initially called github.com/cheggaaa/pb later replaced by gopkg.in/cheggaaa/pb.v1 (and v2) and is now again back under the initial github.com/cheggaaa/pb import path again as both v1 and v3. I've prepared an updated package in git[1] under the original name again now including both v1 and the new v3. The new package Provides, Replaces and Conflicts with golang-gopkg-chegga-pb.v1. I've also added both import paths to debian/control and symlinked the gopkg one to the new/original path. I would be really happy if someone could review this and tell me if/what I messed up. I've personally only (so far) tested building the new upstream release of mender-cli (v1.5.0) which needs cheggaaa/pb v3 as well as the currently shipped debian package of mender-cli (v1.4.0) which uses cheggaaa/pb v1 (with the original github.com/cheggaaa/pb import path). (I will likely need to test another package which uses the gopkg.in import path for v1 for full coverage.) Your review comments about this would be greatly appreciated! ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970428 [1]: https://salsa.debian.org/go-team/packages/golang-github-cheggaaa-pb Regards,, Andreas Henriksson
Bug#970428: ITP: golang-gopkg-cheggaaa-pb.v3 -- Console progress bar for Golang
Hello Shengjing Zhu, Thanks for your feedback. On Wed, Sep 16, 2020 at 10:56:08PM +0800, Shengjing Zhu wrote: > On Wed, Sep 16, 2020 at 5:33 PM Andreas Henriksson wrote: [...] > > * Package name: golang-gopkg-cheggaaa-pb.v3 [...] > This package uses a very strange version approach. > > In short, v3 is not really v3. > > The master branch contains both v1 and v3 code. Right now that's true, but I wonder for how long. My guess is that it's set up like this so that both the old gopkg.in/cheggaaa/pb.v1 import path and then new github.com/cheggaaa/pb/v3 import paths both works. (Leaving v2 in the cold.) I assume at some point upstream don't want to deal with v1 anymore and will just drop it from the master branch. > v3 code is lived in a directory called v3, see > https://github.com/cheggaaa/pb/tree/master/v3 > > So basically, we can reuse the v1 source package, v1 and v3 can live > together... I'm a bit worried what will happen if we do this and then upstream drops v1 Also what version number to use for it? There are 1.x and 3.x releases being done in parallell. Also what about the different import paths? github vs gopkg? > And maybe we can add a transitional package to avoid confusion. An alternative might be to just do v3 completely separate and if we really want to avoid it containing a duplicate v1 we could just do `Files-Excluded: ./*.go` on whatever. I however don't see any real issue with just leaving it in (possibly without installing the files in the binary -dev package). The copyright review for it all is trivial. Would very much appreciate help with creating a package for it however that person wants to set it up. :) Regards, Andreas Henriksson
Bug#970428: ITP: golang-gopkg-cheggaaa-pb.v3 -- Console progress bar for Golang
On Wed, Sep 16, 2020 at 11:28:03AM +0200, Andreas Henriksson wrote: > * Package name: golang-gopkg-cheggaaa-pb.v3 > Version : 1.0.29-1 [...] Actually 'version' is 3.0.7 this confusion seems to be related to what I'm about to mention next. (Can I call it the 'go import path circus'?) First see https://github.com/cheggaaa/pb/issues/155 So apparently now all code has moved into a v3 subdirectory (unlike v1 and v2), for the potential benefit of the go mod tool I guess. Also note that the root directory of the git repo still contains some pre-v3 implementation of cheggaaa's pb (with a different API). This possibly means that using gopkg(.in) in the package name as well as the pb.v3 naming should be abandoned in the debian package name? Possibly it should now instead become: - golang-github-cheggaaa-pb(-dev) unlike previous versions in the debian archive which are named: - golang-gopkg-cheggaaa-pb.v1(-dev) - golang-gopkg-cheggaaa-pb.v2(-dev) I've asked for advice on the #debian-golang channel. Feedback welcome if anyone knows the best way to handle this problem. Sigh. As mentioned, If anyone else wants to do this package... - please! Regards, Andreas Henriksson
Bug#970428: ITP: golang-gopkg-cheggaaa-pb.v3 -- Console progress bar for Golang
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-gopkg-cheggaaa-pb.v3 Version : 1.0.29-1 Upstream Author : Sergey Cherepanov * URL : https://github.com/cheggaaa/pb * License : BSD-3-clause Programming Lang: Go Description : Console progress bar for Golang Terminal progress bar for Go. The v1 and v2 is already packaged in debian, but now projects are starting to port to v3 so it's needed as a dependency for other things I'm thus considering packaging it. If someone else wants to take it over, please go for it!
Bug#969586: O: iwd -- wireless daemon for Linux
Package: wnpp Severity: normal I intend to orphan the iwd package in the next upload. The package description is: Minimalistic wireless daemon that uses modern Linux interfaces like cfg80211 and nl80211 (netlink). The daemon provides a D-Bus API. . The daemon can be controlled from the command line with the included iwctl client utility. . The included iwmon utility can be used to monitor the 802.11 subsystem generic netlink commands and events. It uses the nlmon kernel driver from Linux 3.10 and later. Regards, Andreas Henriksson
Bug#964857: ITP: libeconf -- parse and manage key=value configuration files
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: libeconf Version : 0.3.8 Upstream Author : Pascal Arlt * URL : https://github.com/openSUSE/libeconf * License : Expat Programming Lang: C Description : parse and manage key=value configuration files libeconf is a highly flexible and configureable library to parse and manage key=value configuration files. It reads configuration file snippets from different directories and builds the final configuration file for the application from it. The first file is the vendor provided configuration file. There are two methods of overriding this vendor settings: copy the file from /usr/vendordir to /etc and modify the settings. Alternatively, a directory named file.suffix.d/ within /etc can be created, with drop-in files in the form name.suffix. This files contain only the changes of the specific settings the user is interested in. There can be serveral such drop-in files, they are processed in lexicographic order of their filename. In other words, this implements the configuration file scheme made popular by systemd unit files. The libeconf project is gaining traction and is already supported upstream in many of our core components. Introducing this library now for people to hopefully play around with it before a potential future discussion if this is something that should be widely adopted in core components in debian. (I would be very happy if someone else took over the maintenance of this package going forward.) Regards, Andreas Henriksson
Bug#940426: RFA: golang-github-streadway-amqp
Control: tags -1 + pending Hello, On Sun, Sep 15, 2019 at 06:59:07PM -0400, Alexandre Viau wrote: > Package: wnpp > Severity: normal > > Hello! > > I'd like to find new maintainers for some of my packages because I have > had less time for Debian. I'd like to focus the small amount of time > that I have for Debian on other things. I'm willing to help out (or take over) this package under the Debian Go Team umbrella, given that I've just introduced a new reverse dependency: garagemq (Others willing to help out could also join in under the team umbrella.) > > For now, I intend to do my best to keep maintaining this package. > However, I will probably retitle this bug with the 'O:' prefix at some > point, indicating that I have orphaned it. > > Feel free to upload a new version of the package and remove me from the > uploaders in debian/control. As you intend to still keep trying to do your best, I'll not remove you and expect you to eventually remove yourself (or explicitly ask me to do it). At the point you would consider changing this bug to O:, please consider if the package at that point is well enough maintained that you can just close this bug instead. > > Feel free to contact me with any questions. Also note that I always > willing to sponsor uploads! Thanks for your previous work. I'll get back to you with any questions that might pop up once I actually start looking into (updating) the package. Regards, Andreas Henriksson
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#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#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#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#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#927417: ITP: golang-github-remyoudompheng-go-liblzma -- Go bindings for XZ Utils/liblzma
The packaging is ready and available at: https://salsa.debian.org/go-team/packages/golang-github-remyoudompheng-go-liblzma I've reviewed it and it looks good to me, except one detail: The debian/copyright says year 2011 while the upstream files declares 2011-2012. Since I'm not sure the ftp-masters will overlook this detail I've asked Lluis to fix that before I upload his package. (If anyone else wants to go ahead and sponsor him, please feel free.) Regards, Andreas Henriksson
Bug#920435: ITP: mender-cli -- A general-purpose CLI for the Mender backend
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: mender-cli Version : 1.1.0-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/mender-cli * License : Apache-2.0 Programming Lang: Go Description : A general-purpose CLI for the Mender backend Mender is an open source over-the-air (OTA) software updater for embedded Linux devices. Mender comprises a client running at the embedded device, as well as a server that manages deployments across many devices. . This package contains a standalone tool that makes it much easier to work with the Mender server management APIs (https://docs.mender.io/apis/management-apis). . The goal with mender-cli is to simplify integration between the Mender server and cloud services like continuous integration (CI)/build automation.
Bug#914119: ITP: mender-client -- Mender over-the-air software updater client.
On Mon, Nov 19, 2018 at 04:56:06PM +0100, Jonas Smedegaard wrote: > Quoting Andreas Henriksson (2018-11-19 16:22:19) > > Mender logo Getting started To start using Mender, we recommend that >^^^ > > Looks like the long description was automated and could use some human > proof-reading ;-) I'm obviously intentionally leaving this in to create some low-hanging fruit that interested contributors could have an easy change to start out with submitting. Merge Requests welcome! ;) (Yes it's automated. Thanks for pointing out obvious errors. Not sure however the README file from the upstream project is a suitable long package description at all, so maybe someone is interested in completely revamping it?) Regards, Andreas Henriksson
Bug#914118: ITP: golang-github-mendersoftware-mender-artifact -- Library for managing Mender artifact files
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-mendersoftware-mender-artifact Version : 2.3.0b1+git20181022.1bedfca-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/mender-artifact * License : Apache 2.0 Programming Lang: Go Description : Library for managing Mender artifact files Build Status (https://travis-ci.org/mendersoftware/mender-artifact) codecov (https://codecov.io/gh/mendersoftware/mender-artifact) Go Report Card (https://goreportcard.com/report/github.com/mendersoftware/mender-artifact) Mender Artifacts Library Mender is an open source over-the-air (OTA) software updater for embedded Linux devices. Mender comprises a client running at the embedded device, as well as a server that manages deployments across many devices. . This repository contains the artifacts library, which is used by the Mender client, command line interface, server and for build integration with the Yocto Project. . The artifacts library makes it easy to programmatically work with a Mender artifact, which is a file that can be recognized by its .mender suffix. Mender artifacts can contain binaries, metadata, checksums, signatures and scripts that are used during a deployment. The artifact format acts as a wrapper, and uses the tar format to bundle several files into one. . In its simplest form, an artifact contains just a rootfs image, along with its checksum, id and device type compatibility. . The artifacts library might also be useful for other updaters or purposes. We are always happy to see other uses of it! . Mender logo Getting started To start using Mender, we recommend that you begin with the Getting started section in the Mender documentation (https://docs.mender.io/). Using the library You can use the parser and reader in go in the standard way: . . import ( "github.com/mendersoftware/mender-artifact/parser" "github.com/mendersoftware/mender-artifact/reader" ... ) . . For sample usage, please see the Mender client source code (https://github.com/mendersoftware/mender). Contributing We welcome and ask for your contribution. If you would like to contribute to Mender, please read our guide on how to best get started contributing code or documentation (https://github.com/mendersoftware/mender/blob/master/CONTRIBUTING.md). License Mender is licensed under the Apache License, Version 2.0. See LICENSE (https://github.com/mendersoftware/artifacts/blob/master/LICENSE) for the full license text. Security disclosure We take security very seriously. If you come across any issue regarding security, please disclose the information by sending an email to secur...@mender.io (secur...@mender.io). Please do not create a new public issue. We thank you in advance for your cooperation. Connect with us• Join our Google group (https://groups.google.com/a/lists.mender.io/forum/#!forum/mender)• Follow us on Twitter (https://twitter.com/mender_io?target=_blank). Please feel free to tweet us questions.• Fork us on Github (https://github.com/mendersoftware)• Email us at cont...@mender.io (mailto:cont...@mender.io) This is a dependency needed by mender-client package. It also provides the mender-artifact binary package which contains tools to build mender artifacts.
Bug#914119: ITP: mender-client -- Mender over-the-air software updater client.
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: mender-client Version : 1.6.0b1+git20181015.3032b74-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/mender * License : Apache 2.0 Programming Lang: Go Description : Mender over-the-air software updater client. Mender: over-the-air updater for embedded Linux devices Mender is an open source over-the-air (OTA) software updater for embedded Linux devices. Mender comprises a client running at the embedded device, as well as a server that manages deployments across many devices. . Embedded product teams often end up creating homegrown updaters at the last minute due to the need to fix bugs in field-deployed devices. However, the most important requirement for an embedded update process is robustness, for example loss of power at any time should not brick a device. This creates a challenge given the time constraints to develop and maintain a homegrown updater. . Mender aims to address this challenge with a robust and easy to use updater for embedded Linux devices, which is open source and available to anyone. . Robustness is ensured with atomic image-based deployments using a dual A/B rootfs partition layout. This makes it always possible to roll back to a working state, even when losing power at any time during the update process. . Ease of use is addressed with an intuitive UI, comprehensive documentation (https://docs.mender.io/), a meta layer for the Yocto Project (https://github.com/mendersoftware/meta-mender) for easy integration into existing environments, and high quality software (see the test coverage badge). . This repository contains the Mender client updater, which can be run in standalone mode (manually triggered through its command line interface) or managed mode (connected to the Mender server). . Mender not only provides the client-side updater, but also the backend and UI for managing deployments as open source. The Mender server is designed as a microservices architecture and comprises several repositories. . Mender logo Getting started To start using Mender, we recommend that you begin with the Getting started section in the Mender documentation (https://docs.mender.io/). . In order to support rollback, the Mender client depends on integration with U-Boot and the partition layout. It is therefore most easily built as part of your Yocto Project image by using the meta layer for the Yocto Project (https://github.com/mendersoftware/meta-mender).
Bug#914116: ITP: golang-github-mendersoftware-mendertesting --
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-mendersoftware-mendertesting Version : 0.0~git20180410.9e728b5-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/mendertesting * License : Apache 2.0 Programming Lang: Go Description : Testing package for Golang Build Status (https://travis-ci.org/mendersoftware/mendertesting) codecov (https://codecov.io/gh/mendersoftware/mendertesting) Godoc (https://godoc.org/github.com/mendersoftware/mendertesting) Go Report Card (https://goreportcard.com/report/github.com/mendersoftware/mendertesting) This is a dependency needed by mender-client package.
Bug#914117: ITP: golang-github-mendersoftware-scopestack --
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-mendersoftware-scopestack Version : 0.0~git20180403.c2f5599-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/scopestack * License : Apache 2.0 Programming Lang: Go Description : Scopestack package for Golang Build Status (https://travis-ci.org/mendersoftware/scopestack) Coverage Status (https://coveralls.io/github/mendersoftware/scopestack?branch=master) Godoc (https://godoc.org/github.com/mendersoftware/scopestack) This is a dependency needed by mender-client package.
Bug#914113: ITP: golang-github-ungerik-go-sysfs -- Go package for Linux sysfs
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-ungerik-go-sysfs Version : 0.0~git20170424.9c991ee-1 Upstream Author : Erik Unger * URL : https://github.com/ungerik/go-sysfs * License : MIT Programming Lang: Go Description : Go package for Linux sysfs go-sysfs Go package for Linux sysfs This is a dependency needed by mender-client package.
Bug#914115: ITP: golang-github-mendersoftware-log -- Logging package
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: golang-github-mendersoftware-log Version : 0.0~git20180403.f608c95-1 Upstream Author : Mender * URL : https://github.com/mendersoftware/log * License : Apache 2.0 Programming Lang: Go Description : Logging package Log package for Golang Build Status (https://travis-ci.org/mendersoftware/log) Coverage Status (https://coveralls.io/github/mendersoftware/log?branch=master) Godoc (https://godoc.org/github.com/mendersoftware/log) This is a dependency needed by mender-client package.
Bug#914114: ITP: golang-github-bmatsuo-lmdb-go -- Bindings for the LMDB C library
Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson
* Package name: golang-github-bmatsuo-lmdb-go
Version : 1.8.0+git20170215.a14b5a3-1
Upstream Author : Bryan Matsuo
* URL : https://github.com/bmatsuo/lmdb-go
* License : BSD-3-clause
Programming Lang: Go
Description : Bindings for the LMDB C library
lmdb-go releases/v1.8.0 (releases) C/v0.9.19
(https://github.com/LMDB/lmdb/blob/mdb.RE/0.9/libraries/liblmdb/CHANGES)
Build Status (https://travis-ci.org/bmatsuo/lmdb-go) Go bindings to the
OpenLDAP Lightning Memory-Mapped Database (LMDB). Packages Functionality
is logically divided into several packages. Applications will usually
need to import lmdb but may import other packages on an as needed basis.
.
Packages in the exp/ directory are not stable and may change without
warning. That said, they are generally usable if application dependencies
are managed and pinned by tag/commit.
.
Developers concerned with package stability
should consult the documentation. lmdb GoDoc
(https://godoc.org/github.com/bmatsuo/lmdb-go/lmdb)
stable (#user-content-versioning-and-stability) go import
"github.com/bmatsuo/lmdb-go/lmdb"
.
.
Core bindings allowing low-level access to LMDB. lmdbscan
GoDoc (https://godoc.org/github.com/bmatsuo/lmdb-go/lmdbscan)
stable (#user-content-versioning-and-stability) go import
"github.com/bmatsuo/lmdb-go/lmdbscan"
.
.
A utility package for scanning database
ranges. The API is inspired by bufio.Scanner
(https://godoc.org/bufio#Scanner) and the python cursor implementation
(https://lmdb.readthedocs.org/en/release/#cursor-class). exp/lmdbpool
GoDoc (https://godoc.org/github.com/bmatsuo/lmdb-go/exp/lmdbpool)
experimental (#user-content-versioning-and-stability) go import
"github.com/bmatsuo/lmdb-go/exp/lmdbpool"
.
.
A utility package which facilitates reuse of lmdb.Txn objects using
a sync.Pool. Naively storing lmdb.Txn objects in sync.Pool can
be troublesome. And the lmdbpool.TxnPool type has been defined as a
complete pooling solution and as reference for applications attempting
to write their own pooling implementation.
.
The lmdbpool package is relatively new. But it has a lot
of potential utility. And once the lmdbpool API has been
ironed out, and the implementation hardened through use by real
applications it can be integrated directly into the lmdb package
for more transparent integration. Please test this package and
provide feedback to speed this process up. exp/lmdbsync GoDoc
(https://godoc.org/github.com/bmatsuo/lmdb-go/exp/lmdbsync)
experimental (#user-content-versioning-and-stability) go import
"github.com/bmatsuo/lmdb-go/exp/lmdbsync"
.
.
An experimental utility package that provides synchronization necessary
to change an environment's map size after initialization. The package
provides error handlers to automatically manage database size and retry
failed transactions.
.
The lmdbsync package is usable but the implementation of Handlers
are unstable and may change in incompatible ways without notice.
The use cases of dynamic map sizes and multiprocessing are niche
and the package requires much more development driven by practical
feedback before the Handler API and the provided implementations can be
considered stable. Key FeaturesIdiomatic API API inspired by BoltDB
(https://github.com/boltdb/bolt) with automatic commit/rollback of
transactions. The goal of lmdb-go is to provide idiomatic database
interactions without compromising the flexibility of the C API.
.
NOTE: While the lmdb package tries hard to make LMDB as easy to
use as possible there are compromises, gotchas, and caveats that
application developers must be aware of when relying on LMDB to store
their data. All users are encouraged to fully read the documentation
(https://godoc.org/github.com/bmatsuo/lmdb-go/lmdb) so they are aware
of these caveats.
.
Where the lmdb package and its implementation decisions do not
meet the needs of application developers in terms of safety or
operational use the lmdbsync package has been designed to wrap lmdb and
safely fill in additional functionality. Consult the documentation
(https://godoc.org/github.com/bmatsuo/lmdb-go/exp/lmdbsync) for more
information about the lmdbsync package. API coverage The lmdb-go
project aims for complete coverage of the LMDB C API (within reason).
Some notable features and optimizations that are supported: • Idiomatic
subtransactions ("sub-updates") that allow the batching of updates.•
Batch IO on databases utilizing the MDB_DUPSORT and MDB_DUPFIXED flags.•
Reserved writes than can save in memory copies converting/buffering into
[]byte. For tracking purposes a list of unsupported features is kept in
an issue (https://github.com/bmatsuo/lmdb-go/issues/1). Zero-copy reads
Applications with high performance requirements can opt-in to fast,
zero-copy r
Bug#811377: closed by Dmitry Bogatov (Bug#811377: fixed in sysvinit 2.88dsf-60)
Hello Dmitry Bogatov, On Fri, Oct 26, 2018 at 08:55:12PM +, Dmitry Bogatov wrote: > [2018-10-26 13:58] Ben Hutchings [...] > > Benda created a git repository at > > <https://salsa.debian.org/debian/sysvinit>. > > My repository is fork of 'debian/sysvinit'. As far as I can tell, the > following work was done on debian/sysvinit: > > * import history from alioth up to 2.89-59.10 > * create (very) incomplete upgrade to 2.90 in branch dgit/experimental > > What I done: > > * incorporated NMU 2.89-59.11 > * modernized package a bit > > > You seem to have missed that Ian and Benda already started to adopt > > sysvinit. (While they missed closing this bug.) > > Sysvinit have undecided maintainance status for years, which prevented > me from taking actions previously. But now danger is grave and immediate > (see recent discussions about removal of sysvinit on debian-devel@), so > I took libery to take action right now. I'd like to echo what Ben already said that there's no immediate danger of removal. However I appreciate seeing someone take action sooner rather than later. Thanks for stepping up! > > I am sorry, if I stepped on someone's toes. I would greatly appericate > any help in maintaining sysvinit. Recruitment will be as big of a challenge in your maintainer role as technical work. I hope you manage to find people you can work together with that actually do work rather than just talk. I'd like to suggest you put the alioth mailinglist back as maintainer and put yourself as uploader. That will allow casual bystanders to have a chance to follow progress from the sidelines (and hopefully that way build up an interest in stepping in). If you want to aquire admin access to the mailing list, that can probably be arranged by contacting either Ian Jackson or pere. Also working towards using the debian/sysvinit repo would likely be a good move. It seems like you're using a -guest account on salsa, but at the same time you're a DD?! You should have an account on salsa matching your debian username (kaction?) which will allow you full access to debian/sysvinit. Try using that. > > Oh, and surely, while I did my best to not introduce any functional > changes in 2.89-60, brave souls to test upload are more then welcome. Unfortunately you seem to have been a little to eager with "(lintian?) cleanups" where you broke a few things. Please remember to always decide for yourself rather than listen to what lintian has to say. Lintian is usually good at "regular" packages but very often wrong about "special" packages (like sysvinit, et.al.). Also always be very careful and understand all possible consequenses when changing LSB headers in central init scripts. Here are some examples that I overheard a discussion about: You seem to have introduced loops with your changes in: https://salsa.debian.org/iu-guest/sysvinit/commit/7f1224311e24078be99864bd14f146d56d99804c (insserv will tell you about it. Just try to install any package which has an init script to see the warnings.) bootlogd will not catch entire boot process since your changes in: https://salsa.debian.org/iu-guest/sysvinit/commit/daa1e40ec7c3fb136a3f93e6f1a82dd699ec245e Your change to rmnologin init script likely also cause subtle breakage. You might want to consider reverting all the LSB header changes and adding lintian overrides where needed instead. Regards, Andreas Henriksson PS. I'm personally looking forward to a fix for #799329 finally being incorporated. That'll make helping out with testing easier.
Bug#899058: ITP: domoticz -- Home automation system
Hello Federico Ceratto, On Fri, May 18, 2018 at 07:33:21PM +0100, Federico Ceratto wrote: > Package: wnpp > Severity: wishlist > Owner: Federico Ceratto > > * Package name: domoticz [...] > The package will be maintained at https://salsa.debian.org/debian/domoticz [...] Thanks for packaging domoticz. I've not used it myself but I hear good things about it and think it'll be a great addition to the debian archive. I had a quick look at the packaging bits in your git repo and have some questions and comments. Maybe something can be useful for you, but maybe not. Anyway... I see you're using alot of the security features in your service file, great! I wish more packages where better at using these features. I can't help but wonder though if it's not possible for you to use DynamicUser=yes ? You seem to already use some of the strict limitations implied by DynamicUser=yes anyway. Using it would allow you to get away without creating a static system user for your service, but your service also won't be able to create any persistent files (which I don't know if you might need). You also added a 'default' file. Personally I think the only good usage for a default file is with init scripts. Unless I missed something you seem to not have any init script so I don't think that argument applies here. Thus I'd suggest you switch from EnvironmentFile to plainly setting the variables via Environment=. That way users can easily ports via 'systemctl edit ...' the same way they would override any other thing in the service. (Fwiw, I think splitting out the port numbers to an environment variable like you did can be useful even when not using a default file. If the ExecStart line is long and has many different arguments overriding the entire line completely for just a simple port change might be suboptimal for upgrades where you might add, remove or change another unrelated command line argument. Thus being able to just override the environment variable is safer.) Not really willing to take on any (co-)maintainership, but if there's a limited task you think I can help out with don't be shy to ask. (Ofcourse since I'm not a user myself, yet, I'll need help from someone who is to test whatever I implement though.) Regards, Andreas Henriksson PS. You already seem to be very well versed with systemd services but in case you're not already familiar with DynamicUser=yes information about it can be found, except from the systemd documentation ofcourse, at http://0pointer.net/blog/dynamic-users-with-systemd.html
Bug#895584: ITP: ell -- Embedded Linux library
Hello Nobuhiro Iwamatsu, On Fri, Apr 13, 2018 at 12:57:46PM +0900, Nobuhiro Iwamatsu wrote: [...] > * Package name: ell > Version : 0.4 [...] Out of interest (and since I'm not aware of any other users of ell than iwd), may I ask what your motivation is for packaging ell? FYI I've recently uploaded iwd which is currently in NEW (see also ITP #894537) which currently comes with a bundled version of ell. Any chance you're interested in iwd and would like to help out looking into building it against the system ell once your package is available in the archive? Regards, Andreas Henriksson
Bug#894537: ITP: iwd -- wireless daemon for Linux
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: iwd Version : 0.1 Upstream Author : See AUTHORS * URL : https://git.kernel.org/pub/scm/network/wireless/iwd.git/ * License : LGPL-2.1+ Programming Lang: C Description : wireless daemon for Linux I've prepared initial debian packaging of iwd which is available at: https://salsa.debian.org/debian/iwd Please see the debian/control file for full/official description. Help welcome with improving it! The unofficial one is that iwd is a minimalistic replacement for wpa_supplicant (suitable for embedded). It builds on top of modern linux interfaces (nl80211, cfg80211) and provides a D-Bus API. There are also iwctl and iwmon command line utilities included. This should likely still be considered experimental stage software. Latest upstream development release of NetworkManager provides experimental and disabled-by-default support for iwd. You should also be able to find (upstream) support for it in connman. (co-)maintainers welcome. Regards, Andreas Henriksson
Bug#886643: RFH: ed -- classic UNIX line editor
On Tue, Jan 09, 2018 at 04:29:20AM +0100, Andreas Henriksson wrote: > Hello Martin Zobel-Helas, [...] > May I suggest you to reconsider on #668352 ? [...] Also, please note that debhelper compat < 9 seems to currently be deprecated so atleast that part of the patch (which you didn't seem to object to) is useful to fix the current outstanding lintian errors/warnings (even if you choose to not use the 3.0 compat change in the same patch). https://lintian.debian.org/maintainer/zo...@debian.org.html#ed The patch should be trivial to update to apply, but please tell me if you'd like me to update it (and if you prefer having the compat 9 change separate out from the rest). Regards, Andreas Henriksson
Bug#886643: RFH: ed -- classic UNIX line editor
Hello Martin Zobel-Helas, On Mon, Jan 08, 2018 at 12:46:19PM +0100, Martin Zobel-Helas wrote: > I request assistance with maintaining the ed package. I would also be > willing to give up maintenance of this package in long term. I do not > find the time any more to maintain the package (that is basicly > installed on everyones machine) in a proper timely fashion. [...] Let me first thank you for taking the time to file a RFH when you've realized you don't have time for this package anymore. May I suggest you to reconsider on #668352 ? It might not be your personal preference, but if you want to attract others you might have to set your personal preference aside. I assume the number of people who knows how to properly handle a 1.0 format package is decreasing every day (and wonder if /anyone/ who have joined in after 3.0 was invented knows how 1.0 even works anymore). There seems to be very few open bug reports, so it would seem you're leaving the package in good shape (and I didn't really find something I could contribute on myself). If you know of things that could be improved it would be very helpful if you could file (wishlist?) bug reports about them (but I realize you might not have time for this either). I'm not volunteering to (co)maintain, but feel free to poke me if you want me to look into individual issues. Regards, Andreas Henriksson
Bug#860396: mozjs52_52.2.1-1_amd64.changes REJECTED
Hello Luke Faraone and the rest of the (still named? ;P) FTP Team. This followup on your rejection mail available at: http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/2017-August/136005.html I understand your pain in reviewing this, but was hoping for some understanding of our situation. I don't see accepting libmozjs52 despite its inferiour debian/copyright file as a real problem for Debian. We're already shipping this bundled in the firefox package and this is where the copyright file comes from. In other words, firefox is already opening Debian up for anything by shipping an inferiour copyright file. Rejecting libmozjs52 for this reason doesn't save Debian from any potential harm. Noone involved in pkg-gnome really like having to deal with libmozjs at all and we've tried our best to convince gjs upstream of switching to something else, but they unfortunately think they need and like the mozilla extensions. We don't have any volunteers that want to take on the task of updating debian/copyright, so at the moment we'll just have to wait until someone updates firefoxes version and copy it over again. The problem is that we don't know if firefox will ever do that since they already passed though NEW. We where aiming for packaging the GNOME 3.26 BETA release so that we can bring up any issues we find before the final 3.26 release with upstream. I hope you can relate with everyone reporting minor issues after we've already shipped a debian stable release. It would be much better if everyone tested and reported during freeze, right? Unfortunately this unexpected problem stops us from updating the core components and since upstream doesn't support mixing versions (and we don't have the resources to try to reproduce every problem every user hints at in a vague bug report) we're pretty much stuck. Is there any way forward for us other than just waiting and praying? Could you make a compromise given we already ship the same thing in the archive already? Regards, Andreas Henriksson
Bug#861581: ITP: rainloop -- Simple, modern & fast web-based email client
it some kind of practical security track record? Anyway, my notes... debian/control: - "nodejs (>=6) | npm (>=3)" b-dep looks weird to me as these two are not functionally equivalents of each other. - please use (the more secure and preferred) https url for Vcs-Git - Mix of php(7) and php5 dependencies? Only php5 compatible? Will we ship php5 or will rloop soon be php7 compatible? For example the php-sabre-vobject dependency in turn seems to depend on php(7.x). Maybe I'm just uninformed and some php5-* packages are both 5 and 7 compatible?! debian/copyright: - You probably need to include the full AGPL-3 license text since it's not available in "common-licenses". - Please consider, since it might make your life easier, to license debian/* under the same license as upstream (consider any contributed patches that might end up under debian/patches/* which you'll likely want to upstream to lessen your own maintenance burden). debian/*postinst: - Have you considered excluding /var/lib/rainloop from dh_fixperms instead of using maintainer script? The www-data user is a statically allocated user which should have the same uid on all Debian systems. (See 'base-passwd' package.) Hope this helps. Regards, Andreas Henriksson
Bug#820107: RFP: cockpit -- makes it easy to administer your server via a web browser
Hello! On Mon, Jan 09, 2017 at 09:51:08AM +0100, Martin Pitt wrote: > Control: retitle -1 ITP: cockpit -- administer your server via a web browser [...] > Cockpit is now my day job, so I guess I'm a good candidate. :-) However, it's > great that you and Michael are interested in this too, for some > cross-checking! Awesome that you're interested workin on getting cockpit into Debian. Feel free to drop me a mail if you're interested in getting a second pair of eyes on something, but don't hold your breath waiting for me. Full steam ahead! ;) (I guess pretty much the same goes for Michael who did the initial packaging, but you know where to reach him if you want his opinion.) > > > Please also see storaged RFA bug: #820099 > > I'm aware of this. FTR, I started to discuss re-merging udisks and storaged > [1] > and hope to make some further advancement on devconf when I meet the storaged > developers in person. Until then this shouldn't be a blocker, the other > cockpit > modules should work fine with udisks. Awesome again. Sorting out the udisks/storaged situation (or atleast having a long-term plan for how to maintain it) would be nice. The only real blocker I'm aware of is getting the package in shape so that ftp-masters will allow it to pass through NEW. ie. license situation is hopefully under control but bundling situation might need to be investigated further. Not sure exactly what is the hard line required by ftp-masters these days for javascript/npm stuff, but I think they've made an official statement recently about it Happy hacking. Regards, Andreas Henriksson
Bug#801707: ITA: shadow -- system login tools
Hello! Would just like to add here that http://bugs.debian.org/833256 has been filed and another option than seeking someone to maintain src:shadow would be to migrate over to the tools provided by src:util-linux (which other distributions use and is well maintained upstream) and thus possibly getting rid of src:shadow. Anyone thinking of adopting shadow might want to investigate this alternative. Feel free to comment on #833256. Regards, Andreas Henriksson
Bug#824358: ITP: freerdp2 -- RDP client/server for Windows Terminal Services
Hello Mike Gabriel. Thanks for looking at packaging a newer freerdp snapshot! I have some questions and doubts below... On Sun, May 15, 2016 at 12:53:07AM +0200, Mike Gabriel wrote: [...] > * Package name: freerdp2 > Version : 2.x (Git snapshot) [...] > The new major upstream version (well, upstream is not tagging versions, > but we have one upstream dev on the packaging team who recommends Git > snapshots) provides new ABI/API. This new source will supercede the > currently available Debian source package "freerdp". With new API/ABI a transition is needed (and hopefully upstream properly handles SONAME despite not doing releases), but renaming the source package is not normally how you do a transition. > . > From now on, upstream will support parallel installations of multiple > major upstream releases. This bit is quite confusing as you just said upstream doesn't do releases. > So shipping both FreeRDP versions in Debian unstable for a while is > possible. Given the lack of followup on existing bug reports do you really think you have the resources to support multiple versions?! Please explain a bit more about how you intend to support multiple versions? For example how do you intend to handle the naming of pkg-config files, rename or make the -dev packages conflict? > However, only freerdp2 will be made available in Debian 9. Apparently not and you seem to underestimate the amount of work needed to get something removed from the archive! Are you sure you'll manage to get down to only one version again before the stretch release? How? As mentioned renaming the source package is not how you normally do a transtion (only when you want to support multiple versions which you apparently don't want). Please consider handling this like a normal transition. > . > Packages depending on FreeRDP shared libraries should start migrating > their packages to the new ABI/API for FreeRDP 2.x. Again, please share some information on how you intend to package to make it possible to prepare. Likely you're creating extra work here when not following the normal transition workflow. > . > A transition bug will be file for monitoring this change-over, > once the freerdp2 src:package has landed in unstable. An automatic tracker would be available on https://release.debian.org/transitions/ if you followed the normal transition workflow which would be even better. Looking forward to hearing more details about your plans to be able to prepare for the transition. Regards, Andreas Henriksson
Bug#820107: RFP: cockpit -- makes it easy to administer your server via a web browser
Package: wnpp Severity: wishlist * Package name: cockpit Version : 0.99 Upstream Author : Stef Walter , et.al. * URL : http://cockpit-project.org/ * License : LGPL-2.1+ Programming Lang: C Description : makes it easy to administer your server via a web browser Hello! Cockpit is a framework for doing Administrator tasks via an interactive web based interface. The implementation sits on top of a websockets bridge over dbus. It communicate with standard system components over dbus to reuse their capabilities instead of reimplementing them. It also leverages dbus activating capabilities to avoid having things running when they're not used. I'm filing this borderline RFP, ITP, RFH, RFA. Packaging work has already been done and are available from: https://anonscm.debian.org/cgit/collab-maint/cockpit.git The initial packaging work was done by Michael Biebl and I've recently updated it. Neither of us have enough time to properly maintain this in Debian, so I'm posting this to hopefully find someone who has. While the current package when built from the above repo should be functional there's some remaining work to be done before it is ready to be uploaded for NEW review. Lintian helpfully detects some licensing issues w.r.t. for example javascript "evil" license as well as usage of bundled libraries. Suggesting solutions for this in cooperation with upstream is likely needed. Upstream is very interested in seeing cockpit included in Debian. Further work needed would also be for a designer to create a "branding" (theme) for cockpit suitable for Debian deployments. Please also see storaged RFA bug: #820099 If you're interested in working on and maintaining cockpit in Debian then please get in touch. I'm personally willing to act as a co-maintainer and I guess so is Michael. Initial focus would be to get the package ready for NEW review and once that milestone have been reached I'm willing to sponsor uploads if you're not already a Debian Developer. Regards, Andreas Henriksson
Bug#820099: RFA: storaged -- Disk Manager
Package: wnpp Severity: normal Hello! This is a borderline RFA/RFH. I've already packaged storaged, which is a fork of udisks2 but more targeted at supporting advanced "enterpricy" storage solutions. It's currently sitting in experimental, since I don't have time to properly maintain it myself and thus shouldn't upload it targeted at testing/stretch. Many backends are currently disabled since their dependencies are currently not available in Debian. I've also not properly tested that it's functional, but TTBOMK it is. Further information can be found at: https://tracker.debian.org/pkg/storaged Like the packaging vcs at: https://anonscm.debian.org/cgit/collab-maint/pkg-storaged.git There's also interest from upstream to see Debian support and their bug tracker has an issue for this, see: https://github.com/storaged-project/storaged/issues/41#issuecomment-205769607 Upstream has packaged the dependencies which are not available in Debian in separate Ubuntu PPAs and updated the storaged package in an Ubuntu PPA to enable the new backends, which should serve as a very good base for someone willing to maintain these in Debian! If you'd like to see storaged (which is an optional but quite central dependency of cockpit-project.org) in a future stable Debian release, then this is your chance to help out! Get in touch if you'd like to be the primary maintainer of storaged in Debian. I'm willing to assist as a co-maintainer and can also sponsor you if you're not already a Debian Developer. Regards, Andreas Henriksson
Bug#752900: ITP: appstream-glib -- Library for AppStream metadata access
Hello! Any progress on this so far? Do you have any outlook for the future? It feels like it's getting tight now for getting it into Jessie. What are your plans? Having this packaged is a blocker for updating other packages in Debian. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140911092056.ga11...@fatal.se
Bug#705169: Fwd: Re: Bug#705169: RFH: iproute2 -- networking and traffic control tools
Hello Matteo! On Tue, Jun 04, 2013 at 12:13:29PM -0400, Matteo Cypriani wrote: > Hi Andreas, > > I wrote the message below on May 4 but there was a problem with your email > address. I since forgot about it, so I'm retrying only today. I hope it will > work fine. Sorry for the mail problems, my machine went down when I was travelling Thanks for sending it again! I'm just leaving and will be away for the rest of the week (offline). Will look everything over when I'm back! Small status update: the minimal tweaking I did to debian/copyright recently made it pass NEW. What I could possibly be worried about (without having looked) in your work would be that maybe it's too fine grained and will (on top of your great effort) require alot of work to keep up to date. -- Andreas Henriksson signature.asc Description: Digital signature
Bug#705169: RFH: iproute2 -- networking and traffic control tools
Hello Ben Hutchings! On Sun, Apr 21, 2013 at 08:26:43PM +0100, Ben Hutchings wrote: > I reassigned several, but I think the remainder are now genuine bugs in > iproute2. Some of the documentation bugs may require input from kernel > developers. For the longstanding tc questions, you could ask Jamal Hadi > Salim as I think he did most of the kernel work. Thank you very much for your help! -- Andreas Henriksson signature.asc Description: Digital signature
Bug#705169: RFH: iproute2 -- networking and traffic control tools
Hello Matteo! On Thu, Apr 11, 2013 at 11:15:18AM -0400, Matteo Cypriani wrote: > Le jeudi 11 avril 2013 10:37:06 Andreas Henriksson a écrit : > > Please note the changes I've already done in the package git repo on > > alioth collab-maint. More improvements are probably needed until > > we reach a good enough state though. > > I'm also willing to help with the copyright thing, but to coordinate the work > we need to know what file you already worked on. Maybe you could create a > file The request is to rescan all files. The previous efforts are apparently not good enough anymore. Do not limit yourself to a particular subset (unless that's where you want to start). > on gobby.debian.org [1] so that we can synchronise in real time? Do that if you find it useful! I won't dictate how you work, just want to see your result. ;) > > [1] http://wiki.debian.org/gobby.debian.org > > Also, I think it would be a good idea to take advantage of the occasion to > update the debian/copyright file to a machine-readable format > (copyright-1.0). > What do you think? Feel free! All improvements welcome! > > One last question: how do you want to integrate contributions? Do you mind if > we push directly to your collab-maint repository? We can also work on a gobby > pad and you can import the work in a single commit after that if you prefer. For debian/copyright changes, feel free to push straight into the repo. For other changes, please send a couple of patches for review to me before I give you the go ahead to push straight into the repo. -- Andreas Henriksson signature.asc Description: Digital signature
Bug#705169: RFH: iproute2 -- networking and traffic control tools
Hello again! Given the very positive response on my RFH I'm following up with one more wish I forgot to mention. If you are interested in learning more about the advanced networking features provided by the linux kernel. Want to get into the gory details and learn stuff that not many other people (who aren't kernel hackers) know about. Why not take on the task to look at improving the manpages for iproute2? There are many bugs collected about pieces of information missing from manpages in the debian bug tracker at http://bugs.debian.org/src:iproute Start investigating, see what you find, try out stuff document your results in the manpage for everyone else to enjoy! -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130411091421.ga28...@amd64.fatal.se
Bug#705169: RFH: iproute2 -- networking and traffic control tools
Hello Ben! On Thu, Apr 11, 2013 at 03:09:15AM +0100, Ben Hutchings wrote: > On Wed, 2013-04-10 at 21:33 +0200, Andreas Henriksson wrote: [...] > > Triaging bugs listed at http://bugs.debian.org to find out if > > they are still valid, a fix can be found (and submitted upstream!), > > or confirmed to be in the kernel (and reassigned). > > > > Following up on new bug reports. Potentially review and forward > > patches upstream. > [...] > > I may be able to provide some help with this. I've made occasional > contributions to upstream development, and I'm fairly familiar with the > kernel side of rtnetlink. If you have time for this that would be awesome! My impression is that most iproute bugs are actually bugs inside the kernel networking stack. I didn't want to reassign stuff blindly though just to dump them somewhere else where they'll be forgotten. I've previously tried to do agressive bug triaging and I hope the result is that you'll now find most bugs are either longstanding probably-valid bugs (and you should be able to tell from the subject line already if it's a minor thing like manpage updates requests). -- Andreas Henriksson signature.asc Description: Digital signature
Bug#705169: RFH: iproute2 -- networking and traffic control tools
Hello Thomas! On Wed, Apr 10, 2013 at 10:32:48PM +0200, Thomas Preud'homme wrote: > Le mercredi 10 avril 2013 21:33:32, Andreas Henriksson a écrit : [...] > > "Please perform a full source scan and document all licensing information." > > As requested by ftp-masters. > > I didn't find a bug report mentionning this request. Is there a place > mentionning it where progress to review the licensing could be posted? There's nothing public about this. The only feedback is by the recent reject of the later versions of the package from NEW (where it ended up because of the package rename). I've asked for additional details, but I wouldn't recommend holding your breath until more info appears. Please note the changes I've already done in the package git repo on alioth collab-maint. More improvements are probably needed until we reach a good enough state though. > > I'm willing to help on this point. I might have some time this WE to start > looking at it. Thank you very much for your interest in helping out! > > Best regards, > > Thomas -- Andreas Henriksson signature.asc Description: Digital signature
Bug#705169: RFH: iproute2 -- networking and traffic control tools
Package: wnpp Severity: normal I request assistance with maintaining the iproute2 package. Help is welcome in all areas, but following ones would be extra appreciated: "Please perform a full source scan and document all licensing information." As requested by ftp-masters. Triaging bugs listed at http://bugs.debian.org to find out if they are still valid, a fix can be found (and submitted upstream!), or confirmed to be in the kernel (and reassigned). Following up on new bug reports. Potentially review and forward patches upstream. The package description is: The iproute2 suite is a collection of utilities for networking and traffic control. . These tools communicate with the Linux kernel via the (rt)netlink interface, providing advanced features not available through the legacy net-tools commands 'ifconfig' and 'route'. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130410193332.20605.8061.report...@amd64.fatal.se
Bug#663006: Why libnfc over The Linux NFC Subsystem ?
Hi! On Tue, Mar 13, 2012 at 10:28:53PM +0100, Oxan van Leeuwen wrote: > That is only true assuming that libnfc will eventually completely > disappear. Especially given the response from upstream (see Thomas' > mail), I doubt that will happen. libnfc has some more features which > probably won't ever make it to the kernel (mfoc has already been > mentioned). There is also the possibility of writing a libnfc driver > that uses the kernel module, so that they can exist (and be used) > together. > > Even if it will be completely replaced by the NFC subsystem, I think > the benefits of having a complete NFC stack in wheezy outweighs the > drawback of having a migration later on. Packages have been removed > and superseded since the earliest Debian releases, and when there is > a (better) alternative available, that shouldn't cause much > problems. I agree but I sincerely hope that we'll not have multiple stacks around forever with each stack containing their own set of bugs. That would be tragic. -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120314111902.ga30...@amd64.fatal.se
Bug#663456: why revive mediatomb?
On Tue, Mar 13, 2012 at 02:04:52PM +0100, Hector Oron wrote: > Debian is about freedom of choice and I choice to use mediatomb. I think you got that one wrong I remember something about debian being for the users and free software ;) > Longstanding issues are now gone I think it remains to be seen how well it'll be maintained this time around. > ...thanks to Fedora being a great distro and maintaining this > software, I am not alone. > < http://pkgs.fedoraproject.org/gitweb/?p=mediatomb.git > Awesome to hear! > > May I ask why you seem so irritated about having mediatomb back? Are > you a developer of some alternative? I'm not irritated, I'm just reluctant to repeating the same mistakes over and over again without reflecting over them. The reason is that we keep failing our users with poor maintenance, abandoning them stranded on an obsolete software with no migration path (removing stuff which has lots of users is a total failure!), and then doing this again and again... Why do we (Debian) not learn from our mistakes? And no, I'm not a developer of any alternative. You could ofcourse have looked this up yourself as well. I'm mainly interested in looking out for our users and providing them with something that have a better chance of long-term maintenance. > I am not the only one missing it, I got few mails about it which I > redirected to debian-multimedia mailing list. > < http://lists.debian.org/debian-multimedia/2012/03/threads.html > I'm well aware we left alot of users stranded the last time we removed mediatomb from the archive. I think it's very sad, and I think it would be a mistake to repeat it. I hope you manage to live up to your ambitions for the sake of our users! -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120313132411.ga21...@amd64.fatal.se
Bug#663456: why revive mediatomb?
Hi! On Mon, Mar 12, 2012 at 08:54:27PM +, Hector Oron wrote: [...] > Sorry, I am unaware of any alternative, if you let me know some I > might have a look into them. I don't want to be rude, but isn't this something you should be researching before filing an ITP? A simple apt-cache search dlna would be a good start. I dare to say that "I'm ignorant" is definitely not a good enough reason for reintroducing something that was removed because of longstanding issues. Do you really think you have the resources to maintain this in the long run where others (including upstream authors) has given up? -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120313130022.ga20...@amd64.fatal.se
Bug#663006: Why libnfc over The Linux NFC Subsystem ?
Hello Oxan! Thanks for clarifying your view on this. I think it's a good idea to always state such in an ITP. On Mon, Mar 12, 2012 at 07:53:38PM +0100, Oxan van Leeuwen wrote: > While the Linux NFC subsystem might indeed have the best chances to > survive on the long term, I think currently libnfc is in a better > state. The NFC subsystem only appeared in Linux 3.1 and still has a > long way to go before it equals the functionality of libnfc. I > couldn't find equivalents of relatively simple programs like > nfc-mfclassic. I also think it's nice to be able to update libnfc > independent from your kernel, especially since NFC development (in > general) has quite a high pace nowadays. > > Besides, there are applications that require libnfc. That is because > they either were designed before the NFC subsystem was born, or need > to be compatible with other operating systems too. I'd be a shame if > we couldn't package those applications for Debian. You could ofcourse package anything you wish, but including it in Debian is another question for me. Including it in Debian means you are prepared to maintain it in the long run. Several years to come. I'd avoid introducing lots of programs that depend on the libnfc API which you'll later need to port over to a new API and/or provide a migration path for users to new tools that has been developed for the new stack. You're ofcourse welcome to disagree. -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120313124949.gb20...@amd64.fatal.se
Bug#663456: why revive mediatomb?
Hello! I'd like to ask why you're interested in reviving mediatomb? The project is dead upstream and there are several alternatives which are alive and already available in the Debian archive. Maybe your efforts would be better spent on helping out maintaining one of these? ;) -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120312182520.ga12...@amd64.fatal.se
Bug#663006: Why libnfs over The Linux NFC Subsystem ?
Could you please describe why you're interested in working on getting libnfc into Debian now that we have The Linux NFC Subsystem? I'm willing to bet my money on that the latter is the one who will survive in the long run -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120312182037.ga12...@amd64.fatal.se
Bug#573737: ITP: grilo -- framework for media discovery and browsing
On Tue, Jun 07, 2011 at 11:56:01AM +0200, Alberto Garcia wrote: > A quick update on this: > > I've been talking to upstream and the problem now is that basically > Grilo doesn't have a stable API/ABI yet, so I'm not sure if it makes > sense to start packaging it so early. > > Is there a policy for libraries with no stable API in Debian? Normally you need a stable ABI, so if library versioning is not handled by upstream then you handle the so versioning. Debian-specific so versioning is best avoided though... I suggest putting it in experimental for now No guarantees there, and people who want to test it can easily install it. :) > > Berto -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110607111634.ga9...@amd64.fatal.se
Bug#573737: ITP: grilo -- framework for media discovery and browsing
Hello Alberto! On Wed, Jan 26, 2011 at 12:37:10PM +0100, Alberto Garcia wrote: > I work with the upstream Grilo team and I'm willing to create official > Debian packages. I think I have the technical background to do it on > my own but I'm not a DD, so I'd need sponsorship anyway. Please don't let me stop you! If you need any help with reviewing the packaging, maybe sponsorship, or anything please let me know! > > Berto > > -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110126121545.ga29...@amd64.fatal.se
Bug#426048: about your fuppes ITP.
Hello! I've read the comments in the fuppes ITP and quickly looked at fuppes collab-maint git repo. It seems you neither have an "upstream" branch, nor anything else to assist you with creating the orig tarball. You might want to investigate git-import-orig and the pristine-tar option. You might want to work some more on the long descriptions of some of the packages. It's common to include a brief description of what the main package is and what use it has in the plugin packages as well... Imagine someone stumpling upon any of your binary packages for the first time and don't know anything about them. You could drop the things you don't need in your debian/rules to clean it up (or even consider switching to dh7 for a really clean rules file). I read something in the ITP comments about warnings of unneccessary ldconfig calls and similar. This is usually because of plugins being incorrectly treated as regular shared libraries. You might want to exclude /usr/lib/fuppes/* when running dh_makeshlibs: dh_makeshlibs -X /usr/lib/fuppes/ Also, your postinst/rm scripts seems to manually run ldconfig on configure every time rather then relying on debhelper adding it (only) when needed. While at, do you really want to have the debian/shlibs.* included in your git repo? You generate them at build time. I hope my quick review helps you get the package in even better shape for sponsorship review. You're more then welcome to steal packaging ideas from http://git.debian.org/?p=collab-maint/rygel.git (See debian/README.source for comments about dealing with pristine-tar, et.al.) With friendly greetings from the competition! Andreas Henriksson (Rygel packaging team member) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100326133948.ga13...@amd64.fatal.se
Bug#550912: packages for emerillon 0.1.1
I've updated my packages to emerillon 0.1.1, available here: http://fatal.se/tmp/pkg-emerillon/emerillon_0.1.1-1.dsc or for the binary: http://fatal.se/tmp/pkg-emerillon/emerillon_0.1.1-1_amd64.deb (Please beware of http://bugs.debian.org/575384 and make sure libethos-ui-1.0-0 is installed in your build environment.) It would be nice to get a statup update for the emerillon ITP! It seems people are currently standing in line to get this package into Debian. I guess an ITP hijacking isn't far away... -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100325124036.ga20...@amd64.fatal.se
Bug#573738: ITP: rygel-grilo -- Grilo-based provider for Rygel
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: rygel-grilo Version : 0.0.0 Upstream Author : Juan A. Suarez Romero * URL : http://gitorious.com/grilo/rygel-grilo * License : LGPL Programming Lang: C Description : Grilo-based provider for Rygel rygel-grilo is a program that implements the "MediaServer specification" (http://live.gnome.org/Rygel/MediaServerSpec) and exposes content found by grilo backends over DBus to Rygel (and potential future implementions of the client part of the MediaServer specification). This means rygel-grilo makes all the grilo plugins content (read: youtube, jamendo, flickr, ...) accessible over UPnP/DLNA. rygel-grilo is still in very early development and I don't have any plans to package it until it atleast reaches basic maturity. Additionally grilo itself needs packaging first (see separate ITP). Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100313135826.5176.86731.report...@amd64.fatal.se
Bug#573737: ITP: grilo -- framework for media discovery and browsing
Package: wnpp Severity: wishlist Owner: Andreas Henriksson * Package name: grilo Version : 0.1.3 Upstream Author : Iago Toral Quiroga , Juan A. Suarez Romero , Víctor Manuel Jáquez Leal * URL : http://live.gnome.org/Grilo * License : LGPL Programming Lang: C Description : ITP: grilo -- framework for media discovery and browsing Grilo is a framework focused on making media discovery and browsing easy for application developers. At the moment plugins exists to browse the following list of media providers: Youtube, Jamendo, Flickr, Podcasts, UPnP, # Last.FM album art Please see the URL above for more information. I do not intend to work on the packages immediately since upstream says the program is not ready to be officially shipped. Additionally upstream already has prepared debian packaging, so this ITP might become a "I'm willing to sponsor upstream". I'm mainly posting this as a flag to others interested in grilo, which might be interested in a collaboration. Feel free to contact me! Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100313134852.4735.17539.report...@amd64.fatal.se
Bug#570539: retitle 570539 to ITA: libarchive
retitle 570539 ITA: libarchive owner 570539 ! thanks Initial effort available in new collab-maint repository: http://git.debian.org/?p=collab-maint/pkg-libarchive.git Any help is very welcome! Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1266819262-2737-bts-andr...@fatal.se
Bug#570539: libarchive maintenance in debian.
Hello John Goerzen (and others interested)! While upgrading today I noticed the changelog saying you've orphaned the libarchive package. Do you know of any future plans? Has anyone offered to step up as the maintainer? I'd be willing to maintain the package if noone else offers to do the job. (I already have upstream commit access.) Regards, Andreas Henriksson signature.asc Description: Digital signature
Bug#551100: ethos development snapshot packages available in ubuntu ppa.
Hello! Just wanted to add a short note to this bug about https://launchpad.net/~giftwrap/+archive/ppa/+packages where ethos packages can be found. These builds fine on Debian and could possibly be used as a starting point. -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550912: emerillon debian packages.
Hello Mathieu! I wanted to take a look at Emerillon as well. Made packages of the 0.1.0 development release which you can find here: http://fatal.se/tmp/pkg-emerillon/ (I also put rebuit versions of ethos packages there, which I found at https://launchpad.net/~giftwrap/+archive/ppa/+packages since ethos hasn't been packaged for debian yet. See bug #551100.) Besides missing ethos, I also ran into problems with librest dependency. Apparently upstream develops on ubuntu which has renamed rest-0.6.pc to rest.pc. Thus pkg-config has a hard time finding librest. See https://bugs.launchpad.net/ubuntu/+source/librest/+bug/462083 This should be fixed in the next upstream release (for us, breaking ubuntu). I quickly hacked the configure script for now to work around the problem. -- Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511532: releases...
Gnome DVB Daemon v0.1.3 released and available from: http://ftp.gnome.org/pub/GNOME/sources/gnome-dvb-daemon/0.1/ ... but more importantly the first release of Gnome RTSP Server v0.10.1 available from: http://people.freedesktop.org/~wtay/ -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511532: gnome-dvb-daemon needs gst-rtsp-server
Just to mention it, gnome-dvb-daemon needs gst-rtsp-server which does not have any official release yet. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#487263: atmailopen 1.02+dfsg+svn48-1: Please update debconf PO translation for the package atmailopen
On mån, 2008-09-01 at 01:22 +0200, Giuseppe Iuculano wrote:
[...]
> Please respect the Reply-To: field and send your updated translation to
> [EMAIL PROTECTED]
>
> The deadline for receiving the updated translation is
> Thu, 11 Sep 2008 01:21:06 +0200.
Here's an updated swedish translation. For anyone interested in
improving it, please send your improved version to the address Giuseppe
mentioned above!
--
Regards,
Andreas Henriksson
msgid ""
msgstr ""
"Project-Id-Version: Swedish debconf translation of atmailopen\n"
"Report-Msgid-Bugs-To: [EMAIL PROTECTED]"
"POT-Creation-Date: 2008-08-28 18:24+0200\n"
"PO-Revision-Date: 2008-09-01 19:06+0100\n"
"Last-Translator: Andreas Henriksson <[EMAIL PROTECTED]>\n"
"Language-Team: Swedish <[EMAIL PROTECTED]>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Poedit-Language: Swedish\n"
"X-Poedit-Country: SWEDEN\n"
#. Type: multiselect
#. Choices
#: ../templates:1001
msgid "apache2"
msgstr "apache2"
#. Type: multiselect
#. Choices
#: ../templates:1001
msgid "lighttpd"
msgstr "lighttpd"
#. Type: multiselect
#. Description
#: ../templates:1002
msgid "Web server(s) to configure automatically:"
msgstr "Webbservrar som skall konfigureras automatiskt:"
#. Type: multiselect
#. Description
#: ../templates:1002
msgid "Atmailopen supports any web server supported by PHP, however only Apache 2 and lighttpd can be configured automatically."
msgstr "Atmailopen stödjer alla webbservrar som stödjs av PHP, dock kan endast Apache 2 och lighttpd konfigureras automatiskt."
#. Type: multiselect
#. Description
#: ../templates:1002
msgid "Please select the web server(s) that should be configured automatically for Atmailopen."
msgstr "Vänligen välj de webbservrar som skall konfigureras automatiskt foer Atmailopen."
#. Type: boolean
#. Description
#: ../templates:2001
msgid "Should ${webserver} be restarted?"
msgstr "Skall ${webserver} startas om?"
#. Type: boolean
#. Description
#: ../templates:2001
msgid "Remember that in order to activate the new configuration ${webserver} has to be restarted. You can also restart ${webserver} by manually executing invoke-rc.d ${webserver} restart."
msgstr "Kom ihåg, för att aktivera den nya konfigurationen av ${webserver} måste den startas om. Du kan manuellt starta om ${webserver} genom att exekvera invoke-rc.d ${webserver} restart."
Bug#493645: nostromo vs boa?
On Mon, Aug 04, 2008 at 09:33:22AM +0100, Kai Hendry wrote: > Boa's code looks quite good. Boa being alike nostromo in being select > driven as opposed to fork. Select driven is especially important for > devices with low resources as forks are expensive. [...] I'm a bit familiar with boa, using it on an embedded system. I have no idea about options and can't really judge it at all. Mostly asked because maybe I could consider switching to nostromo if you had any convincing arguments over other similar webservers (like boa). ;) Please note that the source tarball is tainted by both CVS directories and binaries, and thus likely needs to be repackaged for DFSG-cleanliness. I'd also like to request that you please mention both "nostromo" and "nhttpd" in the package description to make it easy to find. Apparently both names are in use... Sorry for not having something more valueable then nitpicking to offer. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493645: nostromo vs boa?
Hello Kai! Regarding your intent to package nostromo... I see your point in the gap between thttpd and lighttpd, but could you please summarize why you would choose it over something like boa? What are the main differences and why would you choose one over the other? From a quick look at the description they seem very similar. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445366: RFP: yauap -- simple gstreamer based audio player (with amarok integration over dbus)
Package: wnpp Severity: wishlist * Package name: yauap Version : 0.2.1 Upstream Author : Sascha Sommer * URL : http://www.nongnu.org/yauap/ * License : GNU LGPL Programming Lang: C Description : simple gstreamer based audio player Yauap is a simple commandline audio player based on the GStreamer multimedia framework. There is also a DBus interface that allows yauap to act as a backend for the Amarok audio player. Yauap is free software. Rationale: Amarok dropped it's gstreamer backend[1] a while ago. Novell announced "out-of-the-box" support for mp3 decoding[2] in Amarok and Banshee, which has previously been lacking because of unlicensed mp3 patents preventing distribution of such software. This brought my attention to the solution, yauap With yauap Amarok will be able to use the mp3 decoder plugin for gstreamer which Fluendo has properly received patent licenses for. This way other legally-questionable alternatives available in Debian can be avoided. Anyone packaging this should probably be familiar with Amarok and work closely with its maintainers. [1]: http://amarok.kde.org/blog/archives/91-Backends,-Phonon,-GStreamer.html [2]: http://news.opensuse.org/?p=325 -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#429513: netdude packages in debian
Hello Everybody. I'm just writing to let you know that I've spent some time trying to package the latest upstream version of Netdude. My effort is available at: http://fatal.se/pub/debian/netdude/ If anyone feel like helping out that would be great! See the TODO file at the same place for issues I've already identified (without even testing the package :P). If anyone of you who talked about adopting it still want to do so I'd happily prepare it for you and hand it over to you, since I'm not really that interested. Even if you don't have the time to do take on any bigger part in this right now I'd deeply appreciate if you could find the time to test and/or review the packages since I'm not very experienced when it comes to packaging libraries. I would also need to find a sponsor for this if anyone is willing to help out there, but I don't know if the plan is to remove Gtk+ 1.x before the next release and if I'll have time to port netdude to Gtk+ 2.x. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435678: Status of Cheese packaging?
Hello Franz! Just writing for a quick check of the status of the intended Cheese package in Debian. Any progress? Ubuntu seems to have packages available[0], maybe they could be used or atleast be a useful base for your packages... [0]: http://packages.ubuntu.com/cheese -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#227768: updated package available.
Hi! I've just updated the bandwidthd package. This version, 1.2.1b-12, hopefully has all non-wishlist problems resolved. 22:18 < SynrG> "now has man pages" and "now is lintian clean" are good things to mention. Now has man pages! Now is lintian clean! ;) Also all writeable files (logfiles, html, graphs) are now stored under /var/lib/bandwidthd/ instead of /etc/bandwidthd. With this release I can finally say that I think the package is in a pretty good shape (but ofcourse, I'm not perfectly satisfied yet!). The latest version is available from: http://fjortis.info/pub/debian/bandwidthd-latest/ (which is a symlink I've decided to keep up to date so you won't have to search for the latest version.) The package is now also available from http://mentors.debian.net/. Regards, Andreas Henriksson
Bug#227768: bandwidthd packages.
Hi! I've created bandwidthd packages for my own use. Please help me test them. The current version of the package can be downloaded at: http://fjortis.info/pub/debian/bandwidthd-1.2.1/7/ (Please browse from http://fjortis.info/pub/debian/ to locate latest version) TODO: Write manpages. Get myself a GPG-key and sign the packages. Test, test and test the changes I've made to the original source. If anyone wants to see these packages in debian, please help me find a sponsor (since I'm not a registered Debian developer). Regards, Andreas Henriksson
New package suggestion: avi-xmms
Description: avi player interface (integrates with xmms) Depends on: libavifile 0.5x (!!! 0.6x is incompatible!!!, libavifile 0.6x is currently bundeled with debian unstable, this needs to be "downgraded", 0.6x isn't an "upgrade", it's a rewrite without backwards compability and not many applications support this new API. Honestly I haven't seen a single one yet, all use the 0.5x API) Available from: www.xmms.org (-> plugins -> input) Reason: It's the best avi player interface available for unix. I've read discussion about avi-xmms and that it should _NOT_ be included since it depends on non-open (and they used the work illegal too, but remember that you are innocent until other proven) binary .dll files, though I think the whole argument fail since avi-xmms doesn't really depend on these files, it depends on libavifile ... and yes... libavifile depens on these binaries (but that could be changed, so avi-xmms does NOT depend on these binaries). Even if you think it does, libavifile also does, and thats included in the distribution (without the binaries) ... so... unless I see a good explanation, I'd like to see one of the most downloaded linux apps available in the next debian release! //Andreas Henriksson
