Bug#1081247: ITP: tox-uv -- tox plugin replacing virtualenv and pip with uv
Package: wnpp Severity: wishlist Owner: Faidon Liambotis X-Debbugs-Cc: debian-devel@lists.debian.org, eam...@debian.org Control: block -1 with 1069776 * Package name: tox-uv Version : 1.11.3 Upstream Contact: Bernát Gábor * URL : https://github.com/tox-dev/tox-uv * License : Expat (MIT) Programming Lang: Python Description : tox plugin replacing virtualenv and pip with uv tox-uv is a tox plugin which replaces virtualenv and pip with uv in your tox environments. uv is an extremely fast Python package installer and resolver. Note that you will get both the benefits (performance) or downsides (bugs) of uv. Notes: - I intend to maintain this package as part of the Debian Python Team. Co-maintainers/Uploaders more than welcome. - This is a plugin by the tox author themselves. I've verified with them that it will remain a plugin. - This plugin (obviously) requires "uv" which is not currently in Debian, ITP: #1069776. Depending on how long this ITP takes to materialize, I may upload a version of this plugin that allows one to use tox-uv with "uv" installed manually or through pipx.
Re: Reviving schroot as used by sbuild
On Tue, Jun 25, 2024 at 02:02:11PM +0100, Simon McVittie wrote: > Could we use a container framework that is also used outside the Debian > bubble, rather than writing our own from first principles every time, and > ending up with a single-maintainer project being load-bearing for Debian > *again*? I had hoped that after sbuild's history with schroot becoming > unmaintained, and then being revived by a maintainer-of-last-resort who > is one of the same few people who are critical-path for various other > important things, we would recognise that as an anti-pattern that we > should avoid if we can. Absolutely agreed, strong +1 on this. > At the moment, rootless Podman would seem like the obvious choice. As far > as I'm aware, it has the same user namespaces requirements as the unshare > backends in mmdebstrap, autopkgtest and schroot (user namespaces enabled, > setuid newuidmap, 65536 uids in /etc/subuid, 65536 gids in /etc/subgid). I am perhaps a little biased, but I, too, think rootless Podman would be the best for the job :) > Podman uses the same OCI images as Docker, so it can either pull from a > trusted OCI registry, or use images that were built by importing a tarball > generated by e.g. mmdebstrap or sbuild-createchroot. I assume that for > Debian we would want to do the latter, at least initially, to avoid > being forced to either trust an external registry like hub.docker.com > or operate our own. > > Here's the Dockerfile/Containerfile to turn a sysroot tarball into an > OCI image (obviously it can be extended with LABELs and other > customizations, but this is fairly close to minimal): Note that podman run also has --rootfs, that accepts the path to an exploded container, and it supports both idmap and overlayfs on top of it as well. So that's another option, one that skips image management, Dockerfiles etc. entirely, allowing for an even closer experience to the existing tooling. Faidon
Bug#1068131: ITP: bootterm -- simple terminal to ease connections with SBCs
Package: wnpp Severity: wishlist Owner: Faidon Liambotis X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: bootterm Version : 0.4+git2023013 Upstream Contact: Willy Tarreau * URL : https://github.com/wtarreau/bootterm * License : Expat Programming Lang: C Description : simple terminal to ease connections with SBCs Bootterm is a simple, reliable and powerful terminal designed to ease connection to ephemeral serial ports as found on various SBCs, and typically USB-based ones. . Main features: * automatic port detection (uses the most recently registered one by default) * enumeration of available ports with detected drivers and descriptions * wait for a specific, a new, or any port to appear (convenient with USB ports) * support for non-standard baud rates (e.g. 74880 bauds for ESP8266) * can send a Break sequence and toggling RTS/DTR for various reset sequences, even on startup * fixed/timed captures to files (may be enabled at run time) * optionally time-stamped captures (relative/absolute dates) * reliable with proper error handling * single binary without annoying dependencies, builds out of the box * supports stdin/stdout to inject/download data * configurable escape character and visible character ranges Note that upstream has chosen /usr/bin/bt for the binary's name, but I'm trying to persuade them to use /usr/bin/bootterm instead, in order to avoid taking up a two-letter name in Debian's shared $PATH namespace, for what is intended to be a binary for a niche audience. At minimum I'd expect us to carry a Debian-specific patch.
Bug#1032143: ITP: python-pkcs11 -- high level PKCS#11 interface for Python
Package: wnpp Severity: wishlist Owner: Faidon Liambotis X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-pkcs11 Version : 0.7.0 Upstream Author : Danielle Madeley * URL : https://github.com/danni/python-pkcs11/ * License : Expat Programming Lang: Python Description : high level PKCS#11 interface for Python A high level, "more Pythonic" interface to the PKCS#11 (Cryptoki) standard to support HSM and Smartcard devices in Python. . The interface is designed to follow the logical structure of a HSM, with useful defaults for obscurely documented parameters. Many APIs will optionally accept iterables and act as generators, allowing you to stream large data blocks for symmetric encryption. . It also includes numerous utility functions to convert between PKCS#11 data structures and common interchange formats including PKCS#1 and X.509. . The library is fully documented and has a full integration test suite for all features, with continuous integration against multiple HSM platforms including Entrust nShield, Opencryptoki TPM and OpenSC/Smartcard-HSM/Nitrokey HSM. New optional dependency for esptool, a package that I am trying to help with. I intend to maintain this package as part of the Debian Python Team. Co-maintainers/Uploaders more than welcome.
Bug#1031300: ITP: sphinx-argparse-cli -- Sphinx extension to render CLI arguments defined by the argparse module
Package: wnpp Severity: wishlist Owner: Faidon Liambotis X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: sphinx-argparse-cli Version : 1.11.0 Upstream Author : Bernát Gábor * URL : https://github.com/tox-dev/sphinx-argparse-cli/ * License : Expat Programming Lang: Python Description : Sphinx extension to render CLI arguments defined by the argparse module sphinx-argparse-cli is an extension for Sphinx to render documentation for command-line interface (CLI) arguments defined by the argparse module. . Unlike the sphinx-argparse module, this module is more capable with regards to CLI interfaces that utilize sub-commands. A notable example is the "tox" project, from which this module originates. The package is trivial, but if anyone is interested in helping maintain it, or with tox's maintenance, you're more than welcome!
Bug#1031298: ITP: pyproject-api -- API to interact with Python pyproject.toml-based projects
Package: wnpp Severity: wishlist Owner: Faidon Liambotis X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pyproject-api Version : 1.5.0 Upstream Author : Bernát Gábor * URL : https://github.com/tox-dev/pyproject-api * License : Expat Programming Lang: Python Description : API to interact with Python pyproject.toml-based projects pyproject-api aims to abstract away interaction with pyproject.toml style projects in a flexible way. pyproject-api is a new dependency of tox, in the 4.x series, currently slated for experimental. I intend to maintain this package as part of the DPT. The package is trivial, but if anyone is interested in helping maintain it, or with tox's maintenance, you're more than welcome!
Re: generic viewer for md files
On Mon, Jan 24, 2022 at 04:29:54PM +0100, Jonas Smedegaard wrote: > Lowdown indeed has some interesting features as interactive Markdown > *reader* - thanks for mentioning. Package description however does not > mention if _always_ a superset of markdown/CommonMark is parsed or the > tool can be told to parse conservatively as well - perhaps relevant to > add such information to the package long description? lowdown describes itself primarily as a translator rather than a reader (that part is already in the package description). There are indeed many customization options with regards to disabling various features, whether markup extension-related (Markdown, CommonMark, GFM, MultiMarkdown, PHP Extra) or otherwise, such as --parse-no-cmark. lowdown(1) and lowdown(5) have all the details (in the package or on the website). I'll try to find a way to document that in the long description in a future upload; thank you for the suggestion. > For *packaging* Markdown-authored documentation, where common format is > html and plaintext, I still recommend to first consider more > conservative and lightweight options¹, then more conservative yet heavy > options² - i.e. only consider exciting tools when boring ones are > unsuitable. Agreed, and why I recommended lowdown as a pretty conservative and lightweight option. cmark is a good option too; pandoc is as well, if bootstrapping is not a concern. Regards, Faidon
Re: generic viewer for md files
On Mon, Jan 24, 2022 at 02:12:06PM +0100, Jonas Smedegaard wrote: > Personally I am of the opinion that more ideally such documentation > should be treated as a source format with two targets - html and > plaintext - and that both those target formats should be generated > during package build and installed with the binary package(s). > > For Github-flavored Markdown I recommend to render both target formats > using the command-line tool cmark-gfm. Here is an example of that: > https://salsa.debian.org/debian/doctest/-/commit/d9b848b > > For most other flavors of Markdown I recommend to render using pandoc. > Here is an example of that: > https://salsa.debian.org/js-team/twitter-bootstrap3/-/commit/f138bf1 > > For Gitlab-flavored Markdown there are currently no parser in Debian, > but depending on the actual markup used you might get away with pandoc + > a filter (but may then give up on rendering as plaintext). Here is an > example of that: > https://salsa.debian.org/matrix-team/olm/-/commit/094396d > > Feel free to reach out if you need help juggling Markdown or using > pandoc. I am no expert, but am interested, and am in touch with the > author if all else fails ;-) I maintain "lowdown" in Debian. It supports several markup extensions including several from GFM and CommonMark, and can output in HTML5, roff (man/ms), LaTeX, ODF etc. It also has a terminal output mode, that can be used to format and view Markdown documents in a pager. Upstream is at https://kristaps.bsd.lv/lowdown/ and the package in Debian is just "lowdown". Upstream is very responsive, so if you miss a particular feature please file a bug (preferrably upstream, but I can also forward) It's written in plain C and has no dependencies apart from libbsd. That is of note, because pandoc is notorious for being hard to bootstrap (because of Haskell) and the only other alternative I had explored for my use case was ronn, which is in Ruby and thus also has a complicated dependency chain. (Depending on your package, you may or may not care about your build-dependency chain; I did.) Regards, Faidon 1: https://kristaps.bsd.lv/lowdown/
Bug#982012: ITP: dbip-lite-databases -- IP geolocation databases
Package: wnpp Severity: wishlist Owner: Faidon Liambotis * Package name: dbip-lite-databases Version : 202102 Upstream Author : Eris Networks S.A.S * URL : https://db-ip.com/ * License : CC-BY 4.0 Programming Lang: - Description : IP geolocation databases The DB-IP Lite databases are a set of free IP geolocation databases, that can map an IPv4 or IPv6 address to a specific continent, country, city, and ISP, with varying degrees of accuracy. They are an alternative to the MaxMind GeoLite2 databases (in Debian as "geoip-database"), newer releases for which are now non-free. They are also a less accurate (but free) alternative to the commercially available DB-IP and MaxMind GeoIP databases. The databases will be offered in the MMDB file format, an open format with a number of open source reader and writer implementations, including libmaxminddb, bindings for a variety of programming languages. The data set is volatile, and upstream issues regular releases on a monthly cadence.
Bug#851940: ITP: certspotter -- Certificate Transparency Log Monitor
Package: wnpp Severity: wishlist Owner: Faidon Liambotis * Package name: certspotter Version : 0.2 Upstream Author : Opsmate, Inc. * URL : https://github.com/SSLMate/certspotter * License : MPL-2.0 Programming Lang: Go Description : Certificate Transparency Log Monitor Cert Spotter is a Certificate Transparency log monitor from SSLMate that alerts you when a SSL/TLS certificate is issued for one of your domains. Cert Spotter is easier than other open source CT monitors, since it does not require a database. It's also more robust, since it uses a special certificate parser that ensures it won't miss certificates. . Cert Spotter is also available as a hosted service by SSLMate that requires zero setup and provides an easy web dashboard to centrally manage your certificates. Visit <https://sslmate.com/certspotter> to sign up. . You can use Cert Spotter to detect: * Certificates issued to attackers who have compromised a certificate authority and want to impersonate your site. * Certificates issued to attackers who are using your infrastructure to serve malware. * Certificates issued in violation of your corporate policy or outside of your centralized certificate procurement process. * Certificates issued to your infrastructure providers without your consent. I intend to maintain this under pkg-go. Andrew Ayer (Cc'ed) is the upstream author and also a DM (Andrew, if you want to maintain this instead, happy to take a step back).
Bug#819027: ITP: xiccd -- X11/colord ICC bridge
Package: wnpp Severity: wishlist Owner: Faidon Liambotis * Package name: xiccd Version : 0.2.2 Upstream Author : Alexey Galakhov * URL : https://github.com/agalakhov/xiccd/ * License : GPL-3.0+ Programming Lang: C Description : X11/colord ICC bridge xiccd is a simple bridge between colord and X. It performs the following tasks: * Enumerating displays and registering them in colord; * Creating default ICC profiles based on EDID data; * Applying ICC profiles provided by colord; * Maintaining the user's private ICC storage directory. It does not depend on any particular desktop environment nor toolkit and it should not be used in desktop environments that support color management natively, like GNOME and KDE do.
Re: Bug#795113: ITP: twemproxy -- fast and light-weight proxy for memcached and redis
On 08/10/15 21:52, Jonas Genannt wrote: * Package name: twemproxy Version : 0.4.1 Upstream Author : Twitter Inc * URL : https://github.com/twitter/twemproxy * License : Apache 2 Programming Lang: C Description : fast and light-weight proxy for memcached and redis twemproxy aka nutcracker is a fast and lightweight proxy for memcached and redis protocol. It was primarily built to reduce the connection count on the backend caching servers. This is already packaged and in Debian (and is, in fact, part of jessie). Since everything, including the binary itself, with the sole exception of the Github repository is called "nutcracker", I opted into using that name. I'm working on 0.4.1 and will have it uploaded by next week too. Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55c913f4.3070...@debian.org
Re: motd handling in jessie & beyond
On Wed, Dec 31, 2014 at 07:08:22PM +0100, Santiago Vila wrote: > On Wed, Dec 31, 2014 at 04:20:36PM +0200, Faidon Liambotis wrote: > > c) base-files shipping /etc/update-motd.d, plus a script: > >00-uname: #!/bin/sh\nuname -snrvm\n > > Could you please choose another package? debianutils comes to mind. > Currently, base-files has no binaries at all, and I'd like to keep > it that way. What is your concern with shipping a simple executable shell script? base-files was suggested because it's the package that currently ships our default static motd text. While I don't personally have a preference on the place that uname call should be (if anywhere!), I do think that keeping all of Debian's motd default contents -whether a static blob of text or dynamic scripts- in one place would make the most sense. Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150102141636.ga32...@tty.gr
Re: motd handling in jessie & beyond
On Fri, Jan 02, 2015 at 11:56:44AM +0100, Ansgar Burchardt wrote: > as this seems to be only about including the output of `uname' in motd, > how about just *not* including it? I never found it to be particular > helpful anyway... > > If you want to include information about the machine you are connecting > to, then the OS version, amount of RAM, number and speed of processors, > and system architecture are probably more helpful than just the kernel > version the system is running. I hear you -- the OS version alone is far more useful than uname in my opinion. However, I think this is a separate question. This discussion is about the common interface between a number of key packages that: a) makes the behavior consistent between different login methods and init systems (a jessie regression), b) moves that uname call in one config file and one package rather than hardcoding that uname call in 2-4 places (including pam.d configs & init scripts, which while config files, people generally avoid to customize), c) allows customization by the sysadmin and/or other packages. The /etc/update-motd.d mechanism as is shipped in Ubuntu and partially shipped in Debian is excellent for this in my opinion, as it's just arbitrary scripts that can run and print whatever you want them to. For example, Ubuntu's update-notifier ships /etc/update-motd.d stanzas that print the number of package upgrades pending and whether a reboot is required because the kernel has been previously upgraded. Now, what really belongs in our motd and what doesn't is a discussion that is probably worth having, but I'd personally prefer it if we defer it for after we have a common interface that allows us to do those customizations and do them in one place. Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150102140954.ga28...@tty.gr
motd handling in jessie & beyond
motd handling spans multiple packages (libpam-modules, login, ssh, base-files, initscripts, systemd) and multiple uncoordinated half-baked attempts to take it to different directions have left the current state of affairs a bit of a mess. Steve Langasek (rightfully) suggested on #764841 to use debian-devel as a venue to discuss this so here goes (but note that I am not a maintainer of any of the affected packages). Here's what's currently inconsistent: - Behavior is different between login & sshd. login has (#741129): session optional pam_exec.so type=open_session stdout /bin/uname -snrvm session optional pam_motd.so but SSH has: session optional pam_motd.so motd=/run/motd.dynamic session optional pam_motd.so noupdate Switching SSH to use pam_exec was refused in #764841, as to not break existing update-motd.d behavior. (see below) - Behavior is different between systemd and other init systems. initscripts ships /etc/init.d/motd whose sole purpose is to execute uname -snrvm > /var/run/motd.dynamic on boot but systemd ships an *empty* motd.service file overriding this, presumably for performance reasons (see [1], where upstream suggested something PAM-based instead). Under systemd, nothing writes to /run/motd.dynamic. - pam_motd provides a facility (via a custom patch, brought over by Ubuntu) that run-parts /etc/update-motd.d. The directory exists in Ubuntu (along with default scripts that set Ubuntu's motd) but not in Debian, although https://wiki.debian.org/motd documents it. Moreover, this is broken in jessie right now (#743286) as pam_motd writes the run-parts output to (/var)/run/motd but nothing ever reads that. Ubuntu's pam_motd is patching this to be /run/motd.dynamic which is in accordance with sshd's pam configuration (and in Ubuntu, login's). All of the above result to, on an up-to-date jessie system: * If you login via SSH you don't get the uname line, but only if you use systemd. You get the uname line if you login via the console *or* if you login via SSH but you are using SysV init. * If you follow wiki's advice and manually create an /etc/update-motd.d directory, you won't see the motd being altered. The scripts *will* run on both console and SSH logins (for different reasons), though, and a /var/run/motd will be created (but not read by anything) leading to confusion. One can symlink /etc/motd to /var/run/motd and emulate Ubuntu's behavior, although the uname line will still remain a discrepancy between the two types of logins that can only be solved by editing the PAM configuration. I believe this to be broken behavior. Going forward, my (non-maintainer) take on this would be that hardcoding the uname call in the PAM config sounds suboptimal, as is overriding an init script with an empty unit file. Providing Ubuntu's update-motd.d facility sounds ideal to me since it's more generic and nicer to the sysadmin and especially since the hardest part (the pam patch) is already in Debian. For this to happen, we'll need: a) login reverting the pam_exec.so change and using pam_motd /run/motd.dynamic again (like wheezy had and jessie's sshd has). b) libpam-modules switching the run-parts output location from /var/run/motd to to /run/motd.dynamic (like Ubuntu) c) base-files shipping /etc/update-motd.d, plus a script: 00-uname: #!/bin/sh\nuname -snrvm\n d) (optionally) removing the now-redundant /etc/init.d/motd from initscripts & the empty motd.service override from systemd. The changes are in total 2+1+3 lines, plus killing two files, so relatively simple. On the flip side, this touches five essential/required packages so it might be a bit too much for jessie's freeze, although I also wonder if the current state of affairs is okay to release with. Opinions? Regards, Faidon 1: http://lists.freedesktop.org/archives/systemd-devel/2012-June/005417.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141231142036.ga16...@tty.gr
Bug#768979: ITP: geoipupdate -- MaxMind GeoIP/GeoIP2 database updates
Package: wnpp Severity: wishlist Owner: Faidon Liambotis * Package name: geoipupdate Version : 2.1.0 Upstream Author : MaxMind, Inc. * URL : https://github.com/maxmind/geoipupdate * License : GPL Programming Lang: C Description : MaxMind GeoIP/GeoIP2 database updates The GeoIP Update program performs automatic updates of GeoIP2 and GeoIP Legacy binary databases, as supplied by MaxMind. These are typically paid products; for the free GeoLite databases, the packages geoip-database or geoip-database-contrib can be installed instead. This package replaces the "geoipupdate" functionality that used to be part of the geoip-bin package but was removed starting with 1.6.0, following upstream's split of the packages. The geoip-bin maintainer, Patrick Matthäi, is already aware of the plans for this ITP. Compared to geoip-bin, this will add GeoIP2 support, as supported by libmaxminddb, #741199. Finally, since the only purpose of this package is to fetch paid, binary databases from MaxMind, it will uploaded to the contrib section of the archive. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110143621.ga11...@tty.gr
Re: so long and thanks for all the fish
On 11/07/14 23:04, Joey Hess wrote: It's become abundantly clear that this is no longer the project I originally joined in 1996. We've made some good things, and I wish everyone well, but I'm out. Extremely sad to read this, Joey. The few times we've crossed paths, I've enjoyed working with you (and on your ideas) incredibly. And of course I am -as we are all- enjoying the fruits of your efforts, on a daily basis. It's a big loss to the project. I have to say though, I share your sentiments to a very large degree: I am, too, quite disappointed from Debian's current state of affairs. More to the point, I am, too, quite disappointed by the current behavior of the CTTE and by extension, its members. If the CTTE needs to exist as a body, I am at least expecting from both the committee as a whole but from its individual members as well, to remain objective, act in a calm, wise and prudent manner, mediate, put out fires & unite the project. We've seen some pretty reckless and divisive behavior this past year that would be unacceptable for any member of the project, let alone a CTTE member. I don't have high respect for the committee as a whole right now and this is probably the opposite of how it should be. This is clearly a difficult time for the project and, unfortunately, the CTTE is in the middle of this debate and I believe it has actively made things worse. I don't think the CTTE members share this blame equally (not by a long shot), but especially considering the fact that it's a self-moderated body, noone is innocent here. Best, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545de691.2090...@debian.org
Re: Sources licensed under PHP License and not being PHP are not distributable
On 06/26/14 14:00, Ondřej Surý wrote: I did have a quite long and extensive chat with FTP Masters and our conclusion was that PHP License (any version) is suitable only for software that comes directly from "PHP Group", that basically means only PHP (src:php5) itself. This issue reached Planet today, making this even more visible and embarassing to the project, IMO. Unless I'm mistaken, I don't see any emails from any of the FTP masters on the matter and we've only been informed about a "long and extensive chat" with them that had the end result of the mass bug filling. The exact reasoning behind this is still unknown to me and I think this whole chat happened in private -- if not, pointers are welcome. The only think that we /do/ have is a short paragraph from the REJECT FAQ which a) was documented a long time ago, b) is inaccurate for 3.01 (the "includes the Zend Engine part") and c) has been consistently ignored in NEW reviews for almost a decade. Can we get an official word from the ftp-masters and have this discussion in public, please? Thanks, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b1c244.4080...@debian.org
Re: Sources licensed under PHP License and not being PHP are not distributable
On 06/26/14 14:00, Ondřej Surý wrote: I should have done this earlier before cloning the bugs, so here's some more background on the bugs filled. I did have a quite long and extensive chat with FTP Masters and our conclusion was that PHP License (any version) is suitable only for software that comes directly from "PHP Group", that basically means only PHP (src:php5) itself. Could you elaborate on the reasoning of that? Neither your email to -devel nor the one to -legal[1] explains why you think so and whatever it is, I think it's far from obvious. I think an outcome that results in a mass (RC) bug filing needs to be better documented than that -- and btw, you're supposed to mail debian-devel *before* you do so, not after; cf. developer's reference 7.1.1. Besides the importance of the bug filing itself and removing half of PHP from Debian (including packages such as php-memcached!), I have another point to make: as you're well aware, we're in the progress of packaging Facebook's HHVM, which is a new runtime engine for PHP that is gaining some popularity[2]. HHVM is heavily based on PHP and both the parts that are forked from PHP and the parts that were originally written by Facebook (e.g. the VM engine) are licensed either under the PHP 3.01 or the Zend 2.00 licenses. Facebook's lawyers clearly think it's okay, and I do too, FWIW. They do avoid direct and indirect GPL dependencies of course, but I frankly can't see why the PHP license here would be problematic. Regards, Faidon 1: <1401193085.24090.121958581.5b64c...@webmail.messagingengine.com> 2: We intend of switching Wikimedia's infrastructure to HHVM in the upcoming quarter, for instance. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ac05b2.8000...@debian.org
Re: GnuTLS in Debian
On 12/23/13 02:15, Steve Langasek wrote: On Mon, Dec 23, 2013 at 12:25:40AM +0100, Marco d'Itri wrote: On Dec 22, Moritz Mühlenhoff wrote: We should do that (and also reevaluate the position wrt OpenSSL) by running it by the Software Freedom Law Center. Red Hat has real lawyers who looked into the issue, we should do the same. Agreed, Debian has been promoting bad decisions due to developers playing armchair lawyers for way too long. Red Hat only needs to meet the standard that they don't think there's risk to the company of being sued for a license violation. Debian holds itself to a higher, ethical standard of complying with the license even when the risks are small. Your insulting reference to laymen who are capable of reading and reasoning about license terms as "armchair lawyers" doesn't magically make the text of the license ignorable. I think a better way to put Marco's argument would be: "[h]acker legal education, with its roots in programming, is strong on formal precision and textual exegesis. But it is notably light on legal realism: coping with the open texture of the law and sorting persuasive from ineffective arguments". That's from a commentary[1] by James Grimmelmann[2], that started from a review of Biella's book and discusses the legal education of hackers and members of the Debian community in particular. It's worth a read. I, too, believe that we could use the reality check. We already did so with our patent policy and solved long-standing problems for our users. Regards, Faidon 1: http://www.concurringopinions.com/archives/2013/09/hacker-legal-education.html 2: http://james.grimmelmann.net/ -- a professor of law specializing on copyright, IP & Internet Law, for what it's worth. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52b7daf6.2050...@debian.org
Re: Release sprint results - team changes, auto-rm and arch status
On 11/29/13 10:22, Aurelien Jarno wrote: On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: * [mips, mipsel] buildds/porterboxes run on hardware which is very old or has known defects: - mips octeon is unstable Better me more precise there, Octeon machines in general are very stable. That said out of the three machines we have in Debian, two are unstable, the other one is very stable. We never really understood why, we only have remarked they have different CPU revision number. Octeon is one of the most active MIPS ports in Linux upstream. Lately, there is renewed interest in this platform, due to some new Octeon-based router products by Ubiquity being extremely cheap, performant and hence, relatively speaking, very popular. Those run a modified Debian distribution (*not* a derivative, Debian's apt sources are recommended by the vendor) This obviously isn't sufficient for Debian to consider mips as a release architecture, but the statement "octeon is unstable" is obviously overly broad and incorrect, as Aurelien also points out. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52985dce.3080...@debian.org
Re: ITP: ruby-em-hiredis -- fast and simple Redis client for EventMachine
On 06/21/13 02:59, Per Andersson wrote: Package: wnpp Please use X-Debbugs-Cc when filing ITP bugs (or reportbug, which does this automatically). Do not Cc debian-devel directly, as it's impossible for someone to properly reply to your bug report without looking its bug number up on the WNPP bug index. Also, the whole point of Cc'ing ITPs to debian-devel is for people to get a chance to make notes/raise questions/object, so you should wait a day or two before uploading, not upload within three hours or so. Finally, like any bug report, when someone does take the time to make a comment on an ITP of yours, it is customary to at least reply to them addressing or rejecting their concerns :) Cheers, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51c3e576.2010...@debian.org
Bug#712107: ITP: nutcracker -- Fast, light-weight proxy for memcached and Redis
Package: wnpp Severity: wishlist Owner: Faidon Liambotis * Package name: nutcracker Version : 0.2.5 (TBA) Upstream Author : Twitter, Inc. * URL : https://github.com/twitter/twemproxy * License : Apache-2.0 Programming Lang: C Description : Fast, light-weight proxy for memcached and Redis nutcracker, also known as twemproxy (pronounced "two-em-proxy"), is a fast and lightweight proxy for the memcached and Redis protocols. It was primarily built to reduce the connection count on backend caching servers, but it has a number of features, such as: * Maintains persistent server connections to backend servers. * Enables pipelining of requests and responses. * Supports multiple server pools simultaneously. * Shard data automatically across multiple servers. * Supports multiple hashing modes including consistent hashing and distribution. * High-availability by disabling nodes on failures. * Observability through stats exposed on stats monitoring port. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130613035521.ga31...@tty.gr
Re: ITP: foreman -- manage Procfile-based applications
On 06/10/13 03:46, Per Andersson wrote: * Package name: foreman Version : 0.63.0 Upstream Author : David Dollar * URL : http://github.com/ddollar/foreman * License : MIT Programming Lang: Ruby Description : manage Procfile-based applications Foreman is a manager for Procfile-based applications. Its aim is to abstract away the details of the Procfile format, and allow you to either run your application directly or export it to some other process management format. There's a more popular/more complicated piece of software called Foreman[1], for which there's an RFP already[2], as well as a component of that, foremancli, already in Debian. Upstream provides a package too, although you could argue it isn't our problem if there's a naming conflict. Nevertheless, I think it'd be best to avoid a package naming conflict between the two apparently completely unrelated applications. Oh, and BTW, you should probably explain what a Procfile is on the long description of your package as it's not immediately obvious. Regards, Faidon 1: http://www.theforeman.org/ 2: http://bugs.debian.org/663101 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b53089.7040...@debian.org
Bug#710271: ITP: librdkafka -- library implementing the Apache Kafka protocol
Package: wnpp Severity: wishlist Owner: Faidon Liambotis * Package name: librdkafka Version : 0.8.0 Upstream Author : Magnus Edenhill * URL : https://github.com/edenhill/librdkafka * License : BSD-2-clause Programming Lang: C Description : library implementing the Apache Kafka protocol librdkafka is a C implementation of the Apache Kafka protocol, containing both Producer and Consumer support. . More information about Apache Kafka can be found at http://kafka.apache.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130529133508.7374.47283.report...@serenity.void.home
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 04/01/13 05:48, Gunnar Wolf wrote: Uoti Urpala dijo [Mon, Apr 01, 2013 at 05:12:46AM +0300]: No, that's not what I'm saying. But I think the release team is primarily responsible for the policies that harm the work other maintainers do on unstable. A release must not be the only goal for package maintainers, and IMO it should not be an overriding one either. Distributions that make latest software available are necessary for free software development. It's not responsible for Debian to say "development of new software should happen on a distro like Arch, we'll just use the results". And Debian is too big to be just for people that care about releases only (...) Hi Uoti, We Debian Developers might be backwards-thinking sometimes, and the release process is surely not perfect. It is, however, one thing we have agreed upon (although we keep working on it and trying to perfect it) over many years. It might be bad manners for me to put it this way: Your mail, although it points out several issues (we are aware of them in the most obvious ways: We work inside them!), lacks the knowledge of what has happened and led to Debian to choose the procedures it has chosen. Do you want to impact Debian's way of working? Great! We are always short on manpower. But, often, getting *really* involved will explain you some situations better than a long rant on a mailing list. Please, do get involved in Debian. Do help us make things better. Do point out at what is broken. You can even become part of Wheezy+1's release team! I think that the fact that unstable is frozen 30% of the time annoys the hell out of several old Debian Developers^Members as well, so it's not exactly fair to blame the new guy for being new for this. If anything, I think new people's views can be really helpful sometimes, as the old-timers may not be able to see our flaws at all. In this case, I think Uoti's views have some merit, if you ignore and move past the (unfair IMHO too) attack on the release team :) Personally, I wouldn't blame anyone specifically, much less a hard-working team of people that have to put up with everyone's crap for months (case in point: an R transition two weeks before the release). However, I do believe that our release process is flawed in some ways and we need to course-correct. I think there are things we could do to fix this which are orthogonal to fixing RC bugs faster. This is something that we need a project-wide discussion for and not something a release team alone can (easily) decide. Last time the release team tried to affect large changes to the release process (time-based freezes) alone, it didn't go too well anyway :) I don't think the time for this discussion is now, so I'll restrain myself from saying more. The release is near, and there's going to be plenty of time until the next freeze :) Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515913ce.3050...@debian.org
Bug#694173: ITP: gdnsd -- authoritative domain name server
Package: wnpp Severity: wishlist Owner: Faidon Liambotis * Package name: gdnsd Version : 1.6.9 Upstream Author : Brandon L Black * URL : https://github.com/blblack/gdnsd * License : GPLv3 Programming Lang: C Description : authoritative domain name server gdnsd is an Authoritative-only DNS server. The initial g stands for Geographic, as gdnsd offers a plugin system for geographic (or other sorts of) balancing, redirection, and service-state-conscious failover. gdnsd has a strong focus on high performance, low latency service. It does not offer any form of caching or recursive service, and does not support DNSSEC. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121124153502.ga25...@dewey.void.home
Bug#692483: ITP: dnsperf -- DNS server performance testing tool
Package: wnpp Severity: wishlist Owner: Faidon Liambotis Control: block -1 by 692467 * Package name: dnsperf Version : 2.0.0.0 Upstream Author : Nominum, Inc. * URL : http://www.nominum.com/support/measurement-tools/ * License : ISC Programming Lang: C Description : DNS server performance testing tool dnsperf is a DNS server performance testing tool. It is primarily intended for measuring the performance of authoritative DNS servers, but it can also be used for measuring caching server performance in a closed laboratory environment. . Also included is resperf, a similar tool that is more suitable for testing caching servers resolving against the live Internet. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121106161554.ga6...@tty.gr
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
On 08/11/12 01:12, Russ Allbery wrote: > There are choices that we don't support because the process of supporting > that choice would involve far more work than benefit, and the final goal > is excellence, not choice for its own sake. For example, we don't allow > users to replace the system C library with a different one. That's > something that we *could* do, but the general consensus of the project is > that investing our effort in that is not the best way to produce > excellence. I kind of disagree with that. I don't think that the fact that we don't support multiple C libraries is the result of a "consensus decision". I think it's just because noone attempted to properly do that and prove it's viability and usefulness either to a portion of the userbase or the project as a whole. Similarly, I don't think the kFreeBSD ports or any of the other Linux architecture ports were a consensus decision. People just did it, the work was of reasonable standards and useful both to expanding the userbase and to improving the quality of the other ports. People are working on building Debian with LLVM (which is great IMHO). Very few people complained about that and the talk was very much welcomed at DebConf. We even have a GSoC project about it. There are other similar examples. As for OpenRC, as far as I understand it, it's similar -but with its LSB header compatibility much less intrusive- with file-rc. None of the two are an /sbin/init replacement. The fact that the systemd-upstart debate is hot and controversial doesn't mean that everything else that is even remotely related to the boot process must be rejected from the archive. And certainly not because a few people think so and are being loud in a mailing list. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5025abc8.8070...@debian.org
Re: [CTTE #614907] Resolution of node/nodejs conflict
On 07/21/12 23:58, Lars Wirzenius wrote: > You're complaining about the posting volume of a list that has 13 + > 17 + 16 + 7 + 8 + 10 + 4 = 75 messages this year, or about 2.6 days > between posts. Is this a reasonable complaint? I don't think so. > > In my opinion, _every_ technical committee decision should be posted > to debian-devel-announce. Any time that the TC needs to make a decision, > it's already an unusual circumstance, and usually something's gone wrong. > It's _good_ to inform the whole project about it. It is educational and > keeps the voting population informed. Seconded. I very much like the recent activity in tech-ctte and I'm more than happy to read its actions through d-d-a. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/500b1958.8020...@debian.org
Re: Bug#659753: ITP: libnet-irr-perl -- Net::IRR - Perl interface to the Internet Route Registry Daemon
Carlos, On 02/13/12 17:29, Carlos Vicente wrote: > Hopefully this module will stimulate development of new Route > Registry tools written in Perl. An example of Route Registry tools > can be found by googling for RAToolset which is now known as the > IRRToolset. The RAToolset was originally developed by ISI, > http://www.isi.edu/, and is now maintained by RIPE, > http://www.ripe.net/. This is a really old description. IRRToolset has long moved under ISC's umbrella¹ where is dying a slow death… There's even an ITP for it (with packages prepared) but I've hesitated to upload since it seems to be abandoned upstream. Regards, Faidon ¹: http://www.isc.org/software/irrtoolset -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f394e2f.1040...@debian.org
Re: Minified files and source code requirement
On 10/27/11 20:53, Russ Allbery wrote: > Compressing all the whitespace out of it seems fine to me; you can fix > that well enough using an indenter. If the variables are also rewritten > into meaningless names, I think it becomes more borderline. If the code > is part "compiled" by, for instance, precomputing significant results or > doing things like turning a yacc parser into the table-driven C code, I > don't think it counts as source any more. Google's way of "minifiying" javascript, Closure, is actually a JavaScript to JavaScript compiler: it removes dead code, inlines and reorders functions and variables, etc. And of course, there's no easy way of knowing how much content a minifier has stripped (i.e. if it's a complicated process like Closure, a simple variable replacement or something in between), which is all the more of an argument against accepting them without their respective source. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111027184842.ga9...@noc.grnet.gr
Re: RFC: Making mail-transport-agent Priority: optional
On 10/15/11 22:06, Steve Langasek wrote: Needing to send mail through specific per-user smarthosts is the exception, not the rule. Most machines have a designated forwarding smarthost based on who their ISP is, not based on which email address someone wants to use. The exception to which rule? In this part of the world, at least, people have been switching away from using their ISP's e-mail account and use webmail providers like Gmail instead. So, if we're talking majorities here, then most desktops don't need an MTA (or an MUA talking SMTP...) in their system at all. It's sad but (IMO) true. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e9a025e.7020...@debian.org
Re: Bug#638976: ITP: python-gitdb -- a pure-Python git object database
On 08/23/11 15:56, Marco Túlio Gontijo Silva wrote: > Package: wnpp > Severity: wishlist > Owner: Marco Túlio Gontijo e Silva > > * Package name: python-gitdb > Version : 0.5.4 > Upstream Author : Sebastian Thiel > * URL : http://github.com/gitpython-developers/gitdb > * License : BSD > Programming Lang: Python > Description : a pure-Python git object database > The project's website says: “IO of git-style object databases - Phased out and merged into GitPython” And it seems GitPython is already in the archive as python-git. I'd be also curious to see how these compare to dulwich. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e57c304.3040...@debian.org
Re: network-manager as default? No!
Jon Dowland wrote: On Sun, Apr 03, 2011 at 07:22:47PM +0300, Faidon Liambotis wrote: It also can't do VLANs (.1q), bridges, bonds and all possible permutations of the above. I'd speculate that it also wouldn't be able to do things like 1k (or more) interfaces. It also doesn't support hooks to be able to do more advanced setups, such as multihoming, policy routing, QoS, etc. Is it necessary for the distribution's *default* network-management solution to handle all of these? If it could be easily substituted for another solution that was better suited to tasks which a majority of users will not use, then surely that is fine. True. ifupdown doesn't do those either by default; the argument was that it's *extendable* enough to be able to do these via simple addon hooks. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9ac81f.90...@debian.org
Re: network-manager as default? No!
On 04/03/11 19:08, Fernando Lemos wrote: On Sun, Apr 3, 2011 at 5:11 AM, martin f krafft wrote: [...] last I checked, for instance, it was not possible to hook up two network cards with DHCP. [...] Hmmm I do have two network cards and they both get IP addresses with DHCP as I would expect (when they both are enabled). Anyways, I don't think NM is the right solution for all proposed use cases right now for a number of reasons: It also can't do VLANs (.1q), bridges, bonds and all possible permutations of the above. I'd speculate that it also wouldn't be able to do things like 1k (or more) interfaces. It also doesn't support hooks to be able to do more advanced setups, such as multihoming, policy routing, QoS, etc. And, above all, losing the network configuration, even for a second, just because you restarted a daemon (or that daemon died) shouldn't be acceptable for the primary network configuration of our distribution. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d989ed7.7050...@debian.org
Re: enable/disable flags in /etc/default
On 03/02/11 05:24, Raphael Geissert wrote: > Interesting that everyone talks about update-rc.d but it appears that nobody > has read its documentation: > >> A common system administration error is to delete the links with >> the thought that this will "disable" the service, i.e., that this will >> prevent the service from being started. However, if all links have >> been deleted then the next time the package is upgraded, the package's >> postinst script will run update-rc.d again and this will reinstall links >> at their factory default locations. The correctc way to disable >> services is to configure the service as stopped in all runlevels in >> which it is started by default. In the System V init system this means >> renaming the service's symbolic links from S to K. > > That means: > # mv /etc/rc2.d/S??apache2 /etc/rc2.d/K00apache2 > # insserv # this bit is not documented, it seems Are you serious? How's that a sysadmin interface? Yes, everything can be done using sh/cp/mv/vi, but this is hardly something that's either properly documented or a replacement for the current method of doing things. Also, while we're at update-rc.d's documentation, that particular manpage says: >Example of disabling a service: > update-rc.d -f foobar remove > update-rc.d foobar stop 20 2 3 4 5 . Have you tried that recently? It doesn't work in squeeze systems. On the other hand, update-rc.d has enable/disable since squeeze, but this is considered an unstable interface, AFAIK. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6e4944.90...@debian.org
Re: Make Unicode bugs release critical?
On 02/11/11 14:20, Torsten Werner wrote: grep, sed, awk, bash, ... ? $ echo αβγ | sed 's/./a/' aβγ Regards, Φαίδων :-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d553373.5060...@debian.org
Re: Bug#610165: ITP: less.js -- JavaScript parser of LESS "Leaner CSS" macro language
Jonas Smedegaard wrote: LESS is a macro language to produce CSS files. I'd start with that and expand it a bit. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d320095.60...@debian.org
Re: 38
Russ Allbery wrote: > Could you please either start reporting (wishlist) bugs asking to make > these scripts more robust against strange administrative practices or get > tired of all this a little bit faster? A large thread in debian-devel > with no concrete actionable reports is basically useless and just wastes a > bunch of people's time. A thread maybe useless but the initial mail wasn't, IMO. It pointed out a class of bugs that are indeed present in Debian and alerted us of a bad practice that some people are following. It also serves as a reminder for all maintainers to audit their package's scripts which is way more useful than having tons of bugs filed. After all, as I'm sure you're aware, our developer reference considers mass bug filing "a deprecated practice" and recommends discussion on debian-devel, which is what he did. Granted, that mail wasn't written in the best possible way (...) but, still, we shouldn't discard it as a whole because of that. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c782298.7000...@debian.org
Re: dsniff is dead, long life to dsniff
Luciano Bello wrote: > I'm the dsniff[1] maintainer, which is a pretty dead project[2]. Dug > Song (the upstream) is putting his efforts in rewrite the project in > python[3], which is quite limited compared to the previous one. > The question is: should I package this new version as a replacement > of the previous one, even one there is a big reduction in the feature > list? Or, should I create a new package (let's say, python-dsniff) and > RM dsniff? Dug has gave me his permission and blessing to adopt dsniff (as in, the upstream), keeping the original name. It has been a while (= 2 years) since I was in that discussion -- I was the Debian maintainer back then, had ported dsniff to libnet 1.1 from 1.0 and wanted all these debian/patches to be merged upstream. He mentioned the Python version back then too FWIW. I am lacking free time but if anyone else is up to it (Luciano?), I'd happily collaborate to maintain the original project. In any case, I think that keeping the same name for the Python version would be a mistake. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b96b17a.3050...@debian.org
Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
Luis R. Rodriguez wrote: > Can you guys upstream a package into Debian with a gitweb URL reference? If I'm understanding the question correctly, yes. We have Vcs-$VCS (i.e. Vcs-Git) and Vcs-Browser pseudo-headers. Both are optional. I agree with Kel here, git2cl et al are unimportant details. Kel, mail me in private when you have something ready for review & upload, as usual. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b8c7b7c.5010...@debian.org
Re: [RFH] Debian 2.6.32 CONFIG_WIRELESS_OLD_REGULATORY, wireless-regdb and crda
Luis R. Rodriguez wrote: > As per Paul Wise' advice I'd like to request for help with the > crda/wireless-regdb package for Debian for the next release of Debian. > I am the upstream crda maintainer and John Linville is the upstream > wireless-regdb maintainer. Kel Modderman has already done most work > required for the Debian package, if not all. What we now need is some > Debian Developer to be willing to either upload the package as-is, or > some help from some experienced package maintainers to address a few > items. I should note Paul Wise has offered sponsorship for this > package so I think we are on the last track to getting this package > finalized and/or uploaded but he just noted a few changes required. > > Summary of review with Paul Wise: > > * Package could likely be uploaded into Debian as-is, just requires > someone comfortable with it > > * We need more help with thepkg-wpa-devel group I'm a member of pkg-wpa-devel and I've been sponsoring Kel for almost 4 years. I have absolute trust in him and I've even offered to advocate him to the NM process multiple times. I'd be happy to review and sponsor the uploads of crda/wireless-regdb, if Paul doesn't have a problem with this. I usually prefer team maintenance, so I think it'd be best if this happened in pkg-wpa; my offer to sponsor is independent of that, though. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b8995b6.5000...@debian.org
Re: Xen, Squeeze, and Beyond
Marco d'Itri wrote: > On Feb 26, Luca Capello wrote: > 5) Do we recommend that new installations of lenny or of squeeze avoid Xen for ease of upgrading to squeeze+1? If so, what should they use? >>> It depends. KVM in lenny is buggy and lacks important features. While it >>> works fine for development and casual use I do not recommend using it in >>> production for critical tasks. >> Is the qemu-kvm backport the "correct" solution, then? > You also need a recent kvm driver in the host, so probably you should > just use a newer kernel at least in the host. > I have tens of lenny guests (with their standard kernels) on RHEL 5.4 > hosts and so far I had no issues, but so far most guests are not heavily > loaded. The biggest problem for me (and work) right now is live migration. Among other things, there are known, fixed-but-not-yet-upstream issues with the KVM paravirt clock which prevents live migration from working. Unfortunately, there's also no way to disable the paravirt clock from the host unless you patch qemu or wrap ioctl() and filter the capability (I did the latter). Beyond that, I've also seen filesystem corruption when using live migration and the filesystem cache hasn't been disabled -- an almost undocumented directive of libvirt's XML. All in all, I'm wondering how people can call this "stable". Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b893bd4.1070...@debian.org
Re: Bug#561688: ITP: turbotail -- drop-in replacement for tail, using FAM for following files
Christian Dietrich wrote: > Package: wnpp > Severity: wishlist > Owner: Christian Dietrich > > > * Package name: turbotail > Version : 0.3 > Upstream Author : Folkert van Heusden > * URL : http://www.vanheusden.com/turbotail/ > * License : GPL > Programming Lang: C > Description : drop-in replacement for tail, using FAM for following > files > > turbotail provides almost all command line options as the normal tail > from coreutils, but when following files with -f, it doesn't poll the > file every second, but uses FAM to get informed about changes at the > file. The above is incorrect; tail in coreutils >= 7.5 uses inotify and hence doesn't poll needlessly. Even if the package is still needed for some reason (e.g. non-linux ports), your description should be adjusted. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Lucas Nussbaum wrote: > I'm fine with letting ftpmasters take that decision. However, they > should consult the project before adding new tags (mail to -devel: "We > are thinking of adding those new tags to our list, comments?" instead of > a mail to -devel saying "We just blocked the following tags"), and > listen to feedback. If someone feel that they made a mistake, it's > always possible to appeal to the TC. Is it? By my interpretation, I don't think that the TC has any authority here since the ftp-masters are DPL delegates and not individual maintainers. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
Steve Langasek wrote: > And I objected before when this was first proposed that the ftp team should > not be auto-rejecting from the archive for any issues that are not > violations of Policy "must" requirements. > > The right process is: discuss; reach a consensus; amend Policy; enforce > Policy. > > The wrong process is: the ftp team declares that certain bugs are blockers > for inclusion in the archive, and Policy is left to scramble to keep up with > documenting this. > > The ftp team are stewards of the archive, not autocrats. Well said. With some obvious exceptions (BYHAND and maintainer disputes come to mind), it's the first time that ftp-masters take accept/reject decisions on regular package uploads and not just NEW packages. lintian already categorizes the bugs into “errors” and “warnings”. I'd personally prefer it if the ftp-master team didn't choose to hand-pick lintian tags themselves but trusted lintian and its maintainers. Possibly also by filling bugs to lintian or policy as appropriate. I'd also prefer it if the QA team was involved somehow in all these, since, well, this is about “quality assurance”, isn't it? While I also agree in principle with lintian-based autorejects and respect the work that has been done for this, I don't think that it fits the ftp-master job description to take such a decision. It may be an acceptable change in the role's power but it should at least be clear and communicated as such. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Proposed mass prototypejs bug filing for multiple security issues
Michael S Gilbert wrote: > - asterisk (embed) It only shipped prototype as an example file, along with a demo webpage the used it. Since it was of limited usefulness and apparently also vulnerable, it has been removed from yesterday's upload (1:1.6.2.0~rc3-1). Thanks, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: usplash-theme-debian uploaded to sid
Frank Lin PIAT wrote: > There are probably three set of defacto-stantards. Those extra format > could be interesting > * VESA: 2560×1600 (on 30 inches monitors... lucky guys) > * Laptops: 1280×800 (as noted by Eugene), 1440×900, 1680×1050 > * LCD TVs: 1920×1080 > * Notebook: not much to add. > > There are many other weird/uncommon formats (like 1024x600) You just went from 12", 14" & 15" straight to 30". Most (all?) of the 24" & 27" monitors out there, plus some 15"-17" laptops, have 1920x1200 (standard 16:10 HD). Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: mms.mycricket.com user
Don, hi, Don Armstrong wrote: > On Sat, 10 Oct 2009, Faidon Liambotis wrote: >> If this is directly subscribed, could the listmasters remove the >> subscription? > > It's unfortunatly not directly subscribed. We'll try to run through a > bounce run and see if it can be teased out. [I already unsubscribed > the only address from cricket.com to any of our lists, and it's most > likely not the culprit.] Thanks. If it helps narrow down the list, I got the same bounce on my mail to listmas...@. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: mms.mycricket.com user
Dominic Hargreaves wrote: > Could the list subscriber who is using this service please stop it > from sending list posters incredibly confusing bounce messages please? > > It looks like the bounces contain vaguely private information so > not reposting here, but it is stripping out all the useful headers > and generating messages like: > > Your message was not delivered successfully. > > Subject: Bug#550242: ITP: rt-extension-emailcompletion -- Add auto > completion on RT email fields > Sent: Thu, 08 Oct 2009 17:00:54 +0100 > > The message could not be delivered to the following recipient: > sub...@bugs.debian.org > > which is wrong in so many ways (it's obviously extracted this address > from the To field of the message). I just got one such bounce from the automated mail going to debian-chan...@lists.debian.org. Original mail was sent on Sat, 10 Oct 2009 13:58:19 +, the mail seems to be destined to an @mms.mycricket.com address with the local part being a U.S. phone number, so obviously not reposting here. If this is directly subscribed, could the listmasters remove the subscription? Thanks, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: kms
Sven Arvidsson wrote: > As I mentioned on the intel-gfx list. For KMS on Intel you'll need to > boot with video=i915:modeset=1 > > Also, make sure you're using 0.93.4 or later of initramfs-tools. > > Having this more widely documented would probably be a good idea, as > upstream have just ripped out support for UMS... http://wiki.debian.org/KernelModesetting The page is there since 2009-04. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Auto Backporting
Frank Küster wrote: > For some teTeX (or older TeXLive?) packages, I've used a > "sarge-backport" (or whatever the stable version was) target in > debian/rules. It added a changelog entry with backport version number, > and it switched some patches and build-deps (in particular, poppler > wasn't available in stable, and we resorted to build with the embedded > copy of xpdf code). On the VoIP team, we used to have, a while back, an automated backporting mechanism using build-server.net's infrastructure. Kilian Krause from the team was operating this for us, along with some other people, I think Bastian Blank among them. We had (and there are still semi-maintained remaints) scripts under debian/backports/$DIST that performed the necessary steps to have something buildable in each distribution. These were mostly shell scripts calling sed on debian/control and the likes. We didn't try, however, to provide feature parity with testing/unstable; the scripts were allowed to disable a feature if e.g. the respective shared library was not available in stable. The feature was also (ab)used for Ubuntu-specific changes (where it wasn't possible otherwise) and/or backports. Going a bit off-topic here, the service also provided autobuilding for *each and every* commit done in the team's repository, for *all* distributions, including unstable. It prepared apt repositories for all of the packages/combinations and it was actually similar to what Ubuntu's PPA is providing now. All in all, it was a wonderful service and actually helped a lot with debugging because we were able to point users to a simple way to test a new version (whether it was stable or unstable users) and report back immediately if it fixed their bugs. It is obviously hard to scale on a project basis but I'd be extremely happy if it was revived even with limited functionality and/or a limited set of packages or teams. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#537110: ITP: libdap -- A C++ SDK contains an implementation of DAP 2.0 and 3.1, Client- and Server-side support classes and a prototype implementation of the AIS
Youhei SASAKI wrote: > Package: wnpp > Owner: Youhei SASAKI > Severity: wishlist > > * Package name: libdap > Version : 3.8.2 > Upstream Author : The University of Rhode Island and The Massachusetts > Institute of Technology > * URL or Web page : http://opendap.org/download/libdap++.html > * License : GNU Lesser GPL 2.1 > Description : A C++ SDK contains an implementation of DAP 2.0 and 3.1, > Client- and Server-side support classes and a prototype implementation of the > AIS > Programing Lang : C, C++, Fortran > > A C++ SDK contains an implementation of DAP 2.0 and 3.1, Client- and > Server-side support classes and a prototype implementation of the AIS. > > Upstream published new version 3.9.3, but can't build libnc-dap[1] > using libdap ver. 3.9.3. So I ITP libdap ver.3.8.2 Could you include a brief description of DAP and AIS? Reading this description made absolutely no sense to me. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs transition
Goswin von Brederlow wrote: > ia32-wine is only available when ia32-apt-get is installed. WTF? Are you listening to yourself? Do you actually believe that it's okay to mess in such horrendous ways with the packaging system? -- Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532481: ITP: radsecproxy -- RADIUS protocol proxy supporting RadSec
Package: wnpp Severity: wishlist Owner: Faidon Liambotis Package name: radsecproxy Version : 1.3 Upstream Author : Stig Venaas URL : http://software.uninett.no/radsecproxy/ License : Dual BSD/GPL (without OpenSSL exception) Programming Lang: C Description : RADIUS protocol proxy supporting RadSec A generic RADIUS proxy that in addition to usual RADIUS UDP transport also supports TLS (RadSec). It aims to be flexible while at the same time small in size and memory footprint, efficient and easy to configure. . It can be useful as a proxy on site boundaries or in other complex RADIUS routing topologies. It supports both IPv4 and IPv6. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Marco d'Itri wrote: > I have been told by upstream maintainers of one of my packages and by > prominent developers of other distributions that supporting a standalone > /usr is too much work and no other distribution worth mentioning does it > (not Ubuntu, not Fedora, not SuSE). BTW, last month Lennart Poettering began a discussion on fedora-devel-list about deprecating /usr completely, i.e. symlinking it to /: https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01063.html It seems that most of the arguments on that thread against that change were "but we won't be able to mount /usr separately that way!". I'm no Fedora expert, but it sounds like it is actually a supported configuration in Fedora. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#513606: ITP: freeswitch -- An open source telephony platform.
There's #389591 and you might want to contact Phil Hands who has showed interest for this. You're also welcome to join the Debian VoIP team. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#510476: ITP: LinuxCallRouter - an ISDN based PBX for Linux
Joerg Dorchain wrote: > Package: lcr LinuxCallRouter - an ISDN based PBX for Linux > Version: 1.3 (20081124) > Upstream Author: Andreas Eversberg > URL: http://isdn.eversberg.eu/download/lcr-1.3/ > Licence: GPL > Description: > Formerly known as "PBX4Linux", Linux-Call-Router is not only a router, > it is a real ISDN PBX which interconnects ISDN telephones and ISDN lines. > It is possible to connect telephones to a Linux box. It is a pure software > solution except for the ISDN cards and telephones. The great benefit is > the NT-mode that allows to connect telephones to an ISDN card. Special > cards are needed and a little bit of different cabeling. It supports lots > of features, that only expensive PBXs have. It include a channel driver > that can link LCR to Asterisk PBX. > > Now that the underlying misdn driver has made it into the mainstream > kernel and asterisk has a debian package for some time, this > package fills the gap of combining both into a very scalable PBX. You're welcome to join pkg-voip-maintainers and coordinate with us about this :) Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#510408: ITP: biew -- console hex viewer/editor with disassembler
Michel Loos wrote: > Package: wnpp > Severity: wishlist > Owner: Michel Loos > > * Package name: biew > Version : 5.7.1 > Upstream Author : Nick Kurshev > * URL : http://sourceforge.net/projects/biew/ > * License : GPL > Programming Lang: C > Description : console hex viewer/editor with disassembler biew was already part of the archive in the past and it was, in fact, released with etch. See #460636 for the bug that requested its removal. That isn't to say that you shouldn't package it; I just think that you should be aware of it. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
Anthony Towns wrote: > Anyway, despite something kinda close to advocacy for the FD option in > the second call for votes on d-d-a, FD lost convincingly to most of the > options on offer. So of any conclusions you might draw, the simplest, > safest and most easily justified seems to be "stop discussing this and > release lenny"... I've heard this before and I'm not sure I understand it. Lenny is _not_ in a releaseable state. We have enough RC bugs that it will take a while to be able to release. How's the discussion hurting the release at the moment? Unless you are suggesting that people discuss _instead of_ fixing RC bugs, to which I'm not sure I agree. Personally, I'm fine with the in depth discussion and with the voting as long as it's not a blocker for the release. That's not to say that I'm not getting tired of discussing the same thing again and again; I firmly believe that we should have one or more sane and clear GR(s), with no "for this release/time period only" options and end this matter once and for all. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: NEW processing
Thomas Viehmann wrote: > The particular pass through NEW that has been used to demonstrate the > deficiency of NEW processing was necessitated by the rename > iceweasel-l10n-hi to iceweasel-l10n-hi-in introduced in the previous > upload (and processed in 3-4 days or so). This rename took place after > uninstallability of iceweasel-l10n-all had been pointed out to the > maintainer after he asked for an unblock on release. In essence, this > whole trip through NEW would not have happened if the maintainer would > actually routinely install his packages before uploading. I am all in > favor of fast-tracking urgent stuff, but the deal should involve the > maintainer making extra-sure to get things right, too. Because we all know that uninstabillity problems can only occur when you change the package name... Or undistributable/illegal stuff. Or lintian errors. In that sense, you should perform quality checks and moderate _every_ upload as well. I'm all for doing legal checks and semi-automated quality/sanity checks on the *first* upload. But what's the point on doing it on binary package renames? Crap can be introduced into the archive just as easily without it /ever/ processing NEW. If the source package existed in the archive before it shouldn't pass through NEW! Quality assurance of existing packages is a job for the QA team. The two teams should definitely cooperate, share common patterns and possibly scripts. In that way, all packages can be automatically or semi-automatically checked, even those that don't ever change their package names. Am I the only one that finds all of the above obvious? Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations: non-free but no contrib
David Given wrote: > One potential reason is that in most jurisdictions you are legally *not > allowed* to use custom wifi firmware. Consider that most wifi systems > are software radios and that the software is entirely capable of > exceeding all regulators' transmissions strength limits or subverting > the carefully tuned frequency-hopping algorithms, etc. And of course, > it's the *hardware vendors* who'll be liable if someone does subvert > their wifi card to do this --- they'll be violating their FCC (or other) > license --- so there'll be pretty hefty signature validation to ensure > that only official firmware can be used. Enough with the "liability" argument. IMHO this is FUD well spread by companies that didn't want their IP "exposed". Atheros cards don't have any firmware; you can transmit in whatever frequency you want to with ath5k/ath9k -- ath9k is distributed by Atheros themselves while ath5k is nowdays endorsed by them. There are companies within the EU (possibly within the U.S. as well) that gained access to those bits (namely, the Atheros HAL) via NDA and distributed modified binaries that lifted any software limitations whatsoever. The most famous one that I know of is MikroTik; they sell a "superchannel" upgrade that allows you to tune Atheros cards to 2.3-2.5GHz and 4.9-6.1GHz. IOW, frequencies that are illegal to use without a license in most parts of the world. I highly doubt that MikroTik would do that (or Atheros would let them) if they had a risk of getting sued for liability in case one of their thousand customers violated the local or EU/federal laws. > So having the source doesn't actually gain you anything --- you would > neither be able nor allowed to do anything with it, apart from printing > it on T-shirts. That assumes that you want to operate only on unlicensed/ISM bands. You can always *buy* a license from the local regulating authority to transmit to other frequencies, in order to avoid interference by unlicensed stations (and yes, I know people that have done this). > (Incidentally, this is one reason why mobile phone handset vendors are > so paranoid about reflashing phones. A phone with a maliciously > programmed GSM stack would turn into a rather efficient cellphone jammer.) That's also false. You can easily jam cellphones using equipment bought from your local radio shop. There are even (perfectly legal) commercial products that do exactly that. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
pkg-netfilter team (was: Re: Bug#502402: ITP: xtables-addons -- Extensions for iptables)
Max Kellermann wrote: >> What do you all think? > > +1 from me. We are already maintaining our packages in a (private) > subversion repository which we could (and should) move to Alioth. Of > course it's a good idea to have a bigger team, since I am an > unofficial Debian maintainer, and sometimes Alexander doesn't have > enough time to sponsor my package uploads, leading to unnecessary > delays. Thanks for this! I created an alioth project with the name of "pkg-netfilter". Please apply for membership: https://alioth.debian.org/projects/pkg-netfilter/ Please discuss with Alexander if and how we can move your private repository to Alioth. I guess an svndump would be a good starting point. We should do this now, merging repositories at a later step would be far more difficult. Also, I haven't heard back from the other maintainers (still Cc'ed) but I guess we have enough packages for a packaging team to exist. Still, it'd be nice to have a larger team. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#502402: ITP: xtables-addons -- Extensions for iptables
Pierre, hi again,
Pierre Chifflier wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Pierre Chifflier <[EMAIL PROTECTED]>
>
> * Package name: xtables-addons
> Version : 1.5.7
> Upstream Author : Jan Engelhardt <[EMAIL PROTECTED]>
> * URL : http://jengelh.medozas.de/projects/xtables/
> * License : GPLv2
> Programming Lang: C
> Description : Extensions for iptables
>
> The xtables userspace code is an ongoing development effort to bring new
> ideas to the iptables, ip6tables, arptables and ebtables userspace
> programs. It provides a lot of patches for new features in Linux kernels
> 2.6.25 that have not yet gone upstream into the official “iptables”
> package.
> It contains new targets for iptables, such as TARPIT, CHAOS, TEE, geoip,
> etc.
Instead of creating an alioth project for ulogd as we dicussed
yesterday, perhaps it would make sense to create a common alioth project
and team, say pkg-netfilter, to maintain ulogd, xtables, iptables,
ebtables, arptables, conntrackd, libnfnetlink,
libnetfilter-{conntrack,log,queue}, nufw?
The involved people would be:
Pierre Chifflier(xtables*, ulogd2, nufw)
Laurence J. Lane(iptables)
Jochen Friedrich(arptables & ebtables)
Jan Christoph Nordholz (ebtables)
Max Kellermann ("netfilter maintainers", libnf*)
Alexander Wirt ("netfilter maintainers", libnf*)
Hilko Bengen(ulog-acctd)
Achilleas Kotsis(ulogd)
myself :) (ulogd, I'd be interested to work on
other packages, if needed)
There are many similarities and/or cross-dependencies between those and
AFAIK there are going to be more -- I've read that in the latest
Netfilter workshop there was a proposal for nftables, an iptables
replacement (perhaps ebtables and arptables too).
Correct me if I'm wrong; Pierre you told me you were at the workshop,
perhaps you know more.
Alexander and Max already began such an effort but perhaps it's a good
idea expanding the team and organizing it better (use alioth, a VCS etc.)
What do you all think?
Regards,
Faidon
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#502305: ITP: ulogd2 -- The Netfilter Userspace Logging Daemon, version 2
Pierre Chifflier wrote: > Ulogd is already packaged in Debian, but I think ulogd2 should be proposed as > a separate package, because: > - they are completely different projects, supporting different targets (NFLOG) > or features (connection tracking) > - ulogd is still the stable daemon, for some time I think > - some applications are based on version 1, and a transition to v2 require > many changes > - both can be installed at the same time > - packages for ulogd2 will be completely different, for ex. using dbconfig I'm sorry, I disagree. I think that ulogd should be updated to v2 post-lenny, since v1 is unsupported, hasn't released for some time and has some serious limitations and bugs (e.g. doesn't work on 32-bit userland/64-bit kernel systems, including sparc64 which is the only way sparc systems will be supported in Debian in the future). Even if we go the separate package name way for some time, this should be a decision that the existing ulogd maintainers (which includes myself) should make and not someone else. You are, of course, welcome to help and/or comaintain. I've known about ulogd2 for some time but haven't worked on it because of its instabilities that make it unsuitable for release. An upload to experimental might make sense but I haven't worked on this (and neither Achilleas, AFAIK) because of my lack of time. If you intend to work on this, please try to coordinate with us. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DELAYED queue and upload hostname
Joerg Jaspert wrote: > Only problem is - if someone goes and uploads a NEW package there it > would get us in trouble, as we would distribute it before it got its > inspection if we really can do that. So if that ever happens it needs > some extra code to look if its valid to give links or not. Well, and anyone can upload anything to his ~/public_html and have Debian servers distribute it. As long as it's not distributed as part of the official archive, I think we should be mostly OK. Not that I would disagree with having those extra checks, I'm just saying that we shouldn't overreact with this, IMHO. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] How should rsyslog handle .0 logfiles from sysklogd
Michael Biebl wrote: > 2.) Try to log rotate the .0 files for the default Debian log files in > postinst. I feel a bit uneasy about this approach, for several reasons: > - It adds fairly reasonable complexity to the maintainer scripts, if you > want to consider all corner cases. > E.g. if you switch from syslog-ng to rsyslog, it is very likely that you > have old .0 files lying around (from a sysklogd->syslog-ng switch), so > syslog.1 would be older than syslog.2 which would be very confusing. Well, you could rely on ctime for this, even though this would make postinst even more complex; any other reasons? > 3.) Delete the .0 files in postinst. Is this covered by the policy? I think that deleting logfiles without warning is totally unacceptable. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: people.debian.org to move to ravel
Tollef Fog Heen wrote: > I'm responsible for the DELAYED queue, which currently lives in my home > directory and is hard coded at least in the default dput configuration > (including lenny and stable), most likely also other personal > configurations. > > I've set up a DELAYED queue instance on ravel now, please use that > instead of the one on gluck. I'll keep the one on gluck running for > now (that is, until it becomes restricted). Perhaps the DELAYED queue should be moved out of ~tfheen to a more neutral directory? Not that I have any problems with you (on the contrary, this service is much appreciated) but it just seems official enough not to be maintained in anyone's home directory. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building with -msse
Russ Allbery wrote: However, a user mentioned that he thinks all chips that fall into the amd64 architecture have SSE and hence adding -msse would be safe for the amd64 build. Is that correct? And in general are there any guidelines about things like this? I assume that using -msse for the i386 build is still out since we still support 486 chips. AFAIK, the amd64 gcc enables those extension by default. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg triggers, dpkg hijack
Ian Jackson wrote: I apologise for boring everyone with this again. But it has been two more weeks and Guillem is still nowhere near finishing his artwork. There has also been no effort by Guillem or Raphael to negotiate with me; they have ignored my postings to debian-dpkg. If I was approached with the same aggressive tone that I'm seeing in your mails here, I'd ignore you too. Your work may be technically sound but you really need to improve your communication skills. In your position, I'd probably be afraid of receiving the "Joerg Schilling award". Also, I'm waiting for your proposals (or even actions!) for resolving the problems that the Technical Committee is facing, as you previously mentioned. You are, after all, the oldest member of the commitee and the only one that ignored its existence because of those "problems", so far. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg semi-hijack - an announcement (also, triggers)
Ian Jackson wrote: [4] Why not ask the Technical Committee to rule ? The TC has not shown great dynamism in recent months. I have tried quite hard as a TC member to get various questions that were put to the TC decided, and the results have not been encouraging. In any case, asking the TC about this at this stage would probably take at least a month or more. This would make it that much harder for other packages' maintainers to make good use of triggers in lenny. It would also allow Guillem to continue making his undesirable wholesale edits in the meantime. Finally, of course, I am on the Technical Committee. For me to appeal this dispute to it in this way would seem too much like me using it as a personal bludgeon. If you don't recognize the authority or the necessity of the Technical Committee on such matters but instead decide take matters into your own hands, I'd expect from you to resign from the comittee. I can't understand how a Debian Developer, let alone a Technical Comittee member, can find it acceptable to hijack a package actively maintained because of technical disagreements with its maintainer. Especially if that package is a core package such as dpkg. You're hurting the credibility of the comittee and of the whole project. That's much more important than a disagreement on a technical matter. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Out-of-tree kernel module popularity
Bastian Blank wrote: >>> 14 zaptel 295 >> Not really considered for inclusion by upstream, yet. > > Not possible to merge in the current state. I know, I'm comaintaining it :) It may be a good candidate (along with mISDN/vISDN) for Greg KH's team, however. >>> 12 kvm 337 >> Already present in mainline but lags a bit hence the need for a -source >> package. > > Why? Why what? It's still under heavy development and changes between versions are rapid. Only recently the ABI was stabilized. >>> 76 btsco 7 >>> 148 bluetooth-alsa1 >> Deprecated in favor of userspace alsa plugin. > > Hmm, the userspace alsa plugin is also called bluetooth-alsa and needs a > sco fix not yet submitted. Nope, that's deprecated too now. A support for ALSA was merged into Bluez. bluetooth-alsa's homepage mentions that. I'm 100% sure because it's working for me with stock Debian kernel :) Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Out-of-tree kernel module popularity
Philippe Cloutier wrote: >> > 4 ipw3945 897 >> Replaced by (free) iwlwifi which will be present in 2.6.24. >> > iwlwifi is "contrib", like ipw3945. iwlwifi needs non-free firmware, ipw3945 needs non-free firmware and non-free userspace daemon. The "free" above was mainline's defintion, not Debian's. ipw3945 was never merged mainly because of the non-free userspace part, while iwlwifi is already merged on wireless-2.6. >> > 132 rtl8180 1 >> > 130 rtl8180-sa24001 >> Merged. >> > You must be thinking about rtl8187. These look like unofficial packages > anyway. Right, I got confused because rtl8180 (the driver) is actually for rtl8185 chipsets (rtl8180 chipsets are not yet supported). Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Out-of-tree kernel module popularity
Ben Hutchings wrote: > I didn't know that table existed! It seems like it would be useful to > aggregate statistics for out-of-tree kernel module packages by stripping > off the kernel version suffix. Here's what I came up with: OK, here's a preliminary analysis of your results. There are quite a few of TODOs, so if anyone wants to step-in, be my guest ;-) WiFi > 1 madwifi1666 > 51 madwifi-ng 18 non-free/deprecated, in favor of ath5k, currently present in wireless-2.6 and pending kernel inclusion. > 4 ipw3945 897 Replaced by (free) iwlwifi which will be present in 2.6.24. > 5 alsa715 Merged on all 2.6 kernels (this was a sarge package) > 73 rt61 8 > 157 rt73 1 > 39 rt2400 46 > 7 rt2500 590 > 26 rt2570 100 > 123 rt2x00-cvs2 > 19 rt2x00 154 All replaced by the latter, which will be present in 2.6.24. > 25 ieee80211 109 > 61 ieee80211softmac 14 > 31 ipw2100 71 > 18 ipw2200 169 > 36 hostap 51 Merged. > 78 bcm43xx 6 Merged as bcm43xx and now (2.6.24) b43/b43legacy. > 132 rtl8180 1 > 130 rtl8180-sa24001 Merged. > 154 p54 1 Merged. > 97 adm8211 3 Merged. > 23 linux-wlan-ng 123 Not going to be merged since hostap (already present) does the job better. VoIP > 50 misdn20 Created by the i4l team, I think they're considering for inclusion. > 14 zaptel 295 Not really considered for inclusion by upstream, yet. > 155 sangoma-wanpipe 1 Binary blob, IIRC. proprietary/non-free > 29 vmware-kernel79 > 42 vmware 39 > 43 vmware-server-kernel 37 > 47 vmware-any-any-kernel26 > 96 vmware-any-any-player-1.0.2 3 > 111 vmware4 2 > 117 vmware-any-any-player-1.0.3 2 > 119 vmware-player-kernel 2 > 125 vmware-tools-kernel 1 > 128 kernel-vmware 1 > 107 cisco-vpnc3 > 143 cisco-vpnclient 1 (free replacement exists) > 93 fritz-classic 3 > 98 fritz-pci 3 > 100 fritz-pnp 3 > 109 fritz-xusb3 > 129 avm 1 False positives --- > 11 linux 391 > 62 linux-ubuntu 12 > 63 kernel 12 > 65 linux-restricted 12 > 85 kernel-nonfree5 > 95 linux-backports 3 > 153 dummy-linux 1 > 145 ext3 1 > 147 usb 1 > 150 scsi-core 1 (d-i module packages) Rest > 2 ndiswrapper1484 Present in Debian, not considered by mainline for inclusion. > 3 kqemu 898 Distributed by Debian (recently moved to main from non-free) I don't think upstream intends to submit it anytime soon. > 12 kvm 337 Already present in mainline but lags a bit hence the need for a -source package. > 22 unionfs 124 > 91 unionfs-knoppix 4 In the process of merging (under some discussion). > 53 pcmcia 17 > 30 kernel-pcmcia79 2.4 material, not needed on 2.6. > 20 ivtv149 > 94 ivtv0.3 3 > 60 ivtv0.4 14 > 66 ivtv0.6 12 > 55 ivtv0.7 16 > 59 ivtv0.8 15 > 102 ivtv0.9 3 > 37 ivtv0.10 49 Merged. > 28 fuse 82 Merged. > 151 lzma 1 Merged. > 67 eagle-usb11 > 69 sony-acpi 9 Merged. > 72 freeswan 8 Deprecated in favor of openswan > 74 rtai 7 Rejected from inclusion, -rt is the way to go. > 75 drbd 7 Proposed for inclusion, under review. > 76 btsco 7 > 148 bluetooth-alsa1 Deprecated in favor of userspace alsa plugin. TODO > 6 openafs 614 > 8 lirc475 > 9 gspca 461 > 10
Re: Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver
Robert Edmonds wrote: > Any modification to the tg3 driver to produce a GR 2006-004 compliant > driver would have to diverge from the kernel team's patch acceptance > guidelines[0] since upstream is intransigent[1] on making tg3 > firmware-free or firmware-optional. The kernel team does not appear to > be interested in maintaining such a driver, and it appears future linux > kernel source packages will be patched[2] to simply remove the blobs of > firmware (I don't know why the driver isn't simply removed entirely > since the result does not compile). This seems totally inappropriate. If the driver includes non-free firmwares these should be removed or split up from the driver source, not remove the driver entirely. If what you say is right, the driver *works* for most of the hardware without non-free blobs. Therefore, I can't understand how removing the driver serves our users. Any rationale behind that decision? I feel like I'm arguing for something completely obvious... Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver
Robert Edmonds wrote: > This package provides the source code for the tg3dfsg kernel > module. Kernel source or headers are required to compile this module. > > This driver complies with GR 2006-004 and should support all Tigon3 > hardware except for 5701a0 chipsets. I intend to upload it should > linux kernel images be uploaded which lack the tg3 driver. This doesn't sound good. Any reason why your 5701a0-removal patch can't be applied to our kernel packages? Or even better, why the driver can't be converted to use request_firmware() instead of embedding the firmware to the source? Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#445866: ITP: perforce -- closed source revision control system
Daniel Jacobowitz wrote: > On Mon, Oct 08, 2007 at 03:41:21PM -0400, Roberto C. S?nchez wrote: >> Given the great abundance of revision control systems already packaged >> for Debian, what is the point of adding another? Especially when it is >> non-free. > > How about "people use it"? There's plenty of installations of > perforce; I think making it easier to use Debian with them is > within the mandate for non-free. I'd say upload only the client to non-free. We should provide users a way to use their existent preforce servers but we should not encourage new installations of perforce. Sounds like a compromise to me :) Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pristine tarball generator
Anthony Towns wrote:
> On Tue, Oct 02, 2007 at 04:15:44PM -0400, Joey Hess wrote:
>> BTW, the next release of pristine-tar will support generating pristine
>> gz files too, so will fully support pristine .orig.tar.gz. Regenerating
>> pristine gz files from small deltas is quite a lot trickier, and
>> currently works for about 99% of the .orig.tar.gz files in the Debian
>> archive. Many thanks to paravoid for making it happen..
>
> Oh wow, that's cool. Any chance of a post/blog on how that was achieved?
There are mostly two kinds of gzip, both compatible with each other:
a) GNU gzip, which are relatively easy; they can have:
* the name of the original file (optional)
* the timestamp of creation
* a compression level ("normal", --fast, --best)
One can easily figure out these from the gzip headers and recreate them
passing the according gzip options (-n and the undocumented -m and -M).
There's also --rsyncable which is appears mostly (if not only) on Debian
and unfortunately can't be figured out from the headers.
GNU gzip is the vast majority of the archive.
b) zlib's gzip; the BSDs use a CLI-compatible gzip based on zlib and
most of the files in this category come from there.
zlib obviously results in a different content on all compression levels
because of a different algorithm.
Apart from that, since it's a library that many can easily use, there
are some really strange gzips out there; many have full or relative
paths in the original name field while others have a --best compression
level without indicating so in the headers (zlib doesn't write the
headers for you, unfortunately).
Some implementations also have a modified Operating System flag in the
gzip headers
For this, I ported NetBSD's gzip and heavily modified it so that it can
take "expert" arguments so that you can set e.g. the OS flag or various
quirks.
Unfortunately, it's not easy to separate the two implementations or the
quirks and pristine-gz tries to create all of them until it succeeds.
It's trying to be smart (e.g. by not using GNU gzip if the osflag is not
Unix or if the original name contains slashes) but recognizing a gzip
may take some time.
Something that doesn't work at the moment -and I'd be grateful for any
help- is the majority of MS-DOS and Win32/NTFS implementatations.
Multipart gzips would also not work even though I haven't yet find any.
On the first run of the tool on the whole archive, pristine-gz succeded
in recognizing 21869 of 22566 orig.tar.gz (almost 97% of the archive).
It explicitelly failed on 206 of them (0.91%) while something weird,
probably a bug, happened on the rest 491 (2.18%).
joeyh is doing another run on the archive with updated versions of both
pristine-tar and pristine-gz, we'll have more of these nice statistics soon.
Regards,
Faidon
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: volatile.debian.org: Does Debian still support it?
Piotr Roszatycki wrote: > After 30th of September the timezone data for New Zealand will be not > correct (Bug#440258). The users who rely on Debian package will notice > that something goes wrong. Based on the description (and not the patch) it seems to me that this kind of change should be in the next etch point release. SRMs? Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFH] Implementing "Homepage:" field support in lintian/linda
Christian Perrier wrote: > The latter should probably be quite conservative and only detect > something like: > > "^ +[Hh]ome *[Pp]age:.*" > > in the package description. /^\s+(web|home)\s*(site|page)\s*(:| at| is).*/i seems to catch more (5087 hits) with few false positives. Also, matching http:// would catch even more but with many false positives so I'm not sure if it's a good idea. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFH] Implementing "Homepage:" field support in lintian/linda
Christian Perrier wrote: > The latter should probably be quite conservative and only detect > something like: > > "^ +[Hh]ome *[Pp]age:.*" > > in the package description. /^ (web|home)( *)?(site|page) *(:| at| is).*/i seems to catch more (1905 hits) Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian's Linux kernel continues to regress on freedom
Sune Vuorela wrote: > On 2007-09-12, Faidon Liambotis <[EMAIL PROTECTED]> wrote: >> Joerg Jaspert wrote: >> >> You're not checking for copyright violations or for non-free stuff in >> all other packages. I obviously meant all other *existing* source packages, i.e. all the uploads that don't pass through NEW. >> The only reason that things like linux-2.6.XX pass through NEW is, from >> my POV, because noone stepped up to fix it so that old source packages >> don't have to pass through. > > I don't consider it something needing fixing. > It is a good way to have the copyright files occasionally reviewed. I don't think that old source packages are re-reviewed for copyright violations/non-freeness. But I could easily be wrong. Even if that is not the case, I don't think that Joerg's time should be spent that way, TBH -- but that not up to me :) Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian's Linux kernel continues to regress on freedom
Joerg Jaspert wrote: > Oh well, the kernel team just lost its trust, which means new uploads of > kernel-team packages dont get their old way of fasttracking in NEW, as I > now need to check all of their uploads for such cases. I'm not sure I find this helpful. You're not checking for copyright violations or for non-free stuff in all other packages. I see no reason why you should check for Linux just because it passes through NEW at each release for unrelated technical reasons. The only reason that things like linux-2.6.XX pass through NEW is, from my POV, because noone stepped up to fix it so that old source packages don't have to pass through. If you/we have an issue with the way things are being done by the kernel team, it should be resolved with them and possibly with the help of tech-ctte if an agreement can't be made. IMHO, it's not the ftp-master's job to check with each upload if a number of DDs follow the social contract as they should. If there is indeed a problem, we should try to solve this once and forever, shouldn't we? Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436404: ITP: asterisk-addons -- Asterisk GPL-only plugins
Package: wnpp Severity: wishlist Owner: Faidon Liambotis <[EMAIL PROTECTED]> * Package name: asterisk-addons Version : 1.4.2 Upstream Author : Digium Inc. (http://www.digium.com/) and others * URL : http://www.asterisk.org/ * License : GPL Programming Lang: C Description : Asterisk GPL-only plugins asterisk-addons is a plugin package distributed by Digium and containing plugins that are licensed under the GPL but their authors have not signed the copyright disclaimer, necessary for Digium to distribute them under a commercial license and hence not included in the main Asterisk distribution. They are, however, suitable for all intents and purposes for inclusion in Debian. This is not going to be the actual description, since this is going to be a multi-binary package, one for each plugin. WIP can be found on pkg-voip-maintainers subversion repository on alioth. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#435884: ITP: rsyslog -- enhanced multi-threaded syslogd
Pierre Habouzit wrote: > To scare people away. But maybe the ability to log into mysql was > enough. No kidding, that's a great feature of the Description, it says > to every clever sysadmin: don't use me. Well, I don't know if you or me or Debian will use it but Fedora is going to switch to it as the default syslog server for F8. It may be a mistake from their part of course but it certainly deserves at least another look because of that. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: making debian/copyright machine-interpretable
Sam Hocevar wrote: >Hello, I would like to gather comments about a proposal I have been > thinking about during the GPLv2/v3 and GPLv2/CDDL discussions. I have > finally written down what I have in mind here, and refined it with the > help of many people on IRC: > > http://wiki.debian.org/Proposals/CopyrightFormat That's great, thank you! Some initial comments: - Even though the GPL/OpenSSL is mentioned explicitely in the rationale, the rest of the document doesn't mention a good way to handle it. - It would be nice (but may be overcomplicated, not sure) to have a field for compatible licenses, probably only in the "other" license case. E.g. monsterz could have a Compatible-License: GPL or a Compatible-License: BSD. That would mostly solve the "other-bsd"/"BSD-like". - I'm not sure if "License: GPL, BSD" for a file makes any sense (it's GPL for all intents and purposes) and I'm afraid it will be (ab)used on a "Files: *" to mean "some files under the BSD, others under the GPL". Overall, this is a very good thing and besides the benefits you mentioned wrt GPLv2/GPLv3/CDDL I think it will help us catch many old bugs. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /bin/sh diversions
Wouter Verhelst wrote: > There are embedded environments where 80KB is a concern. We're not at > the level yet where we can reasonably support such environments, but > there are people who are trying to change that, and I don't think we > should make it harder for them by setting things up in a way that isn't > strictly necessary, but is the easy way out. This change is for the benefit of those environments; it could be the first step of dropping bash from Essential in favor of dash. It's certainly doable: 2 years ago I added a lintian check and ran it on the whole archive. Most packages are easily "fixed" (as in work-arounded) by adding a dependency on bash. The challenge is on preinst/postrm scripts that use bash and should be rewritten to avoid bashisms (e.g. mysql). Note that I'm not advocating that since I'm not convinced (yet) that is needed. Personally, I don't think that Debian will ever target environments where 80KB (or 107KB) of waste in default install matters. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian Installer] Experimental support for Serial ATA RAID (dmraid)
Frans Pop wrote: [1] To confuse the general public, this is also referred to as ATA RAID, BIOS RAID, fake RAID and software RAID, as well as a number of vendor specific terms such as "Intel Matrix Storage". Actually, ATA RAID is more appropriate since dmraid isn't limited to Serial ATA in any way. That't what the package description and upstream are using FWIW. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430622: ITP: dbeacon -- Multicast Beacon
Package: wnpp Severity: wishlist Owner: Faidon Liambotis <[EMAIL PROTECTED]> * Package name: dbeacon Version : 0.3.9 Upstream Author : Hugo Santos <[EMAIL PROTECTED]> * URL : http://fivebits.net/proj/dbeacon/ * License : GPLv2 Programming Lang: C++ Description : Multicast Beacon dbeacon is a multicast beacon. Its main purpose is to monitor other beacon's reachability and collect statistics such as loss, delay and jitter between them. dbeacon supports both IPv4 and IPv6 multicast, collecting information using both Any Source Multicast (ASM) and Source-Specific Multicast (SSM). This package also includes dbeacon matrix, a Perl script to generate beacon reachability matrices in HTML. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On including 64-bit libs in 32-bit packages (see #344104)
Matthew Garrett wrote: > Bill Allombert <[EMAIL PROTECTED]> wrote: >> On Mon, Oct 23, 2006 at 07:30:47PM +0100, Matthew Garrett wrote: >>> Bear in mind that the 64-bit kernel doesn't offer all the functionality >>> that the 32-bit one does. vm86 is the most obvious thing missing. >> and it seems a 64-bit kernel needs a 64-bit iptables. > > Yes, applications with close ties to the kernel are likely to be a > problem. Last time I checked USB printers didn't work either. It's > possible that it'll be a supportable configuration in the future, but we > may well have flying cars by then. No flying cars needed -- at least for the iptables/netfilter part. 2.6.17 and newer (64-bit) kernels[1] work fine with 32-bit iptables. This is not a problem for etch -- sarge OTOH had that problem and yet we shipped 64-bit kernels. 1: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2722971cbe831117686039d5c334f2c0f560be13 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
