Re: Bug#1073496: ITP: requests-mock -- Python module to stub HTTP requests in testing code
On 6/16/24 20:48, Julian Gilbey wrote: On Sun, Jun 16, 2024 at 05:20:37PM +0200, Bastian Blank wrote: On Sun, Jun 16, 2024 at 03:43:38PM +0100, Julian Gilbey wrote: * Package name: requests-mock Version : 1.12.1 Upstream Author : Jamie Lennox * URL : https://github.com/jamielennox/requests-mock * License : Apache-2.0 Programming Lang: Python Description : Python module to stub HTTP requests in testing code This module creates a custom adapter that allows one to predefine responses when certain URIs are called when using the `requests` module. Is this something different then the already exising python-requests-mock? Oh, oops - I somehow missed that. Closing this ITP then. Julian Hi, I always welcome co-maintainer! :) Cheers, Thomas Goirand (zigo)
Re: ifupdown maintenance
On 7/9/24 13:31, Simon McVittie wrote:
I would tend to count "execute arbitrary user-supplied code on
networking changes" as a specialized requirement - by definition,
for this to happen, someone (the sysadmin) needs to have written and
installed the user-supplied hook script. If the sysadmin has made the
decision to do that, then they can equally well make the decision to
install networkd-dispatcher, or ifupdown{,-ng,2} or any other networking
management framework of their choice that supports the feature they need.
Things aren't as easy as you describe. Some packages (like openvswitch)
are currently working out-of-the-box in Debian. I certainly wouldn't
like it to stop working by default. (note: I haven't looked at it yet...
hopefully, it can also work with sd-networkd. but this was just an example)
(Because non-trivial networking is dynamic and can be shared between
multiple components, and in practice this has been the case for years,
I would personally say that if you want arbitrary actions to happen
as a side-effect of networking state changes, a better way to achieve
that is for long-running processes to monitor the network interfaces
via e.g. netlink, and trigger those arbitrary actions whenever there is
a state change, regardless of whether the state change was initiated
by the ifupdown family, NM, networkd, Docker, libvirtd, VPN services, or
something else. But I realise opinions might vary.)
Nice wishful thinking, but that's not the current state of things.
Such a simple thing as sshd isn't even binding properly when the IP of a
server is missing, and in some cases, needs restart (for example if
non-local-ip bind isn't set in sysctl). And there's lower profile
packages we need to address too...
Cheers,
Thomas Goirand (zigo)
Re: default network management tools
On 7/9/24 12:45, Simon McVittie wrote: To some extent, we are already there: for new laptop/desktop installations, NM is already the default (certainly true for GNOME, and hopefully for most/all of the other tasksel-supported desktops). Right. For new server/embedded installations, I think networkd would be a better default than ifupdown[...] networkd seems like an entirely reasonable implementation of "make the easy things easy"[...] You're probably right. However, such a change is best to be planned early in the development stage, like just right after a freeze. I'm wondering if it's not already too late for Trixie. Also, you may have seen that the official Debian cloud images have moved to using Ubuntu's Netplan. Don't we want to also move to it? Cheers, Thomas Goirand (zigo)
Re: default network management tools
On 7/10/24 20:03, Michael Biebl wrote: Since there is a lot of support for this idea, the next logical step as smcv said, would be to make d-i/netcfg networkd aware. At the beginning, this could be opt-in (for testing purposes) and we could make it the default later on. Any takers? If someone were to add that support in d-i for Trixie, that'd be great. Even better IMO, if it had support for Netplan. Then we could switch the default for Forky? Cheers, Thomas Goirand (zigo)
Re: what about Netplan?
On 7/11/24 09:16, Philip Hands wrote: I've only seen netplan mentioned in passing in this thread so far. It seems like it is exactly what we need as a replacemtent for ifupdown (given that is what it's designed for AFAICT -- I've not yet tried it out myself though) and it already supports configuring systemd-networkd, so seems like a more sensible route than duplicating that effort in D-I. See: https://netplan.readthedocs.io/ Cheers, Phil. Systemd networkd is nice, it reacts correctly to event and such, but its configuration without Netplan is just horrible. So Netplan fills nicely the gap, IMO. Cheers, Thomas Goirand (zigo)
Re: what about Netplan?
On 7/14/24 18:09, Steve McIntyre wrote: I understand what you're trying to say, but that's a disingenuous comparison. systemd is a massive (some would say *too* massive) project with fingers in many pies. How many of those people have touched *networking* bits? I agree. Also, Netplan is just a configuration layer. That's a way simpler than NM or sd-networkd. Cheers, Thomas Goirand (zigo)
Bug#1076947: ITP: python-accuweather -- wrapper for getting weather data from AccuWeather API
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-accuweather Version : 3.0.0 Upstream Contact: Maciej Bieniek * URL : https://github.com/bieniu/accuweather * License : Apache-2 Programming Lang: Python Description : wrapper for getting weather data from AccuWeather API This package is a python wrapper for getting weather data from the AccuWeather HTTP API. One needs to generate an API key at the AccuWeather site at https://developer.accuweather.com/user/register, and after registration it is possible to use the API. I'm packaging this within the Home Assistant team.
Bug#1076977: ITP: python-adax -- library to communicate with Adax heaters
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-adax Version : 0.4.0 Upstream Contact: Daniel Hjelseth Hoyer * URL : https://github.com/Danielhiversen/pyAdax * License : Expat Programming Lang: Python Description : library to communicate with Adax heaters This package provides a library to communicate with Adax heaters. . To use this library, one needs account ID and password in the Adax system. I intend to maintain this package in the homeasssistant team.
Bug#1076978: ITP: python-adax-local -- library to communicate with Adax heating systems
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-adax-local Version : 0.1.5 Upstream Contact: Daniel Hjelseth Høyer * URL : https://github.com/Danielhiversen/pyAdaxLocal * License : Expat Programming Lang: Python Description : library to communicate with Adax heating systems This package provides a library to communicate locally to Adax heating systems. I intend to maintain this package within the home asssistant team.
Bug#1076979: ITP: python-adb-shell -- implementation of ADB with shell and FileSync functionality
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-adb-shell Version : 0.4.4 Upstream Contact: Jeff Irion * URL : https://github.com/JeffLIrion/adb_shell * License : Apache-2 Programming Lang: Python Description : implementation of ADB with shell and FileSync functionality This Python package implements ADB shell and FileSync functionality. I itend to maintain this package within the home asssistant team.
Bug#1076980: ITP: python-aemet-opendata -- AEMET OpenData Rest API library
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aemet-opendata Version : 0.5.3 Upstream Contact: Álvaro Fernández Rojas * URL : https://github.com/Noltari/AEMET-OpenData * License : GPL-2 Programming Lang: Python Description : AEMET OpenData Rest API library AEMET-OpenData is a Python module implementing an interface to the AEMET OpenData Rest API. It allows a user to gather all the public weather information from AEMET (Agencia Estatal de Meteorología). I intend to maintain this package within the home assistant team.
Bug#1076982: ITP: python-adext -- AlarmDecoder extended
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-adext Version : 0.4.3 Upstream Contact: AJ Schmidt * URL : https://github.com/ajschmidt8/adext * License : Expat Programming Lang: Python Description : AlarmDecoder extended Adext is a small package that extends alarmdecoder to include some additional methods for Home Assistant. I intend to maintain this package within the home assistant team.
Bug#1076985: ITP: python-alarmdecoder -- interface for the AlarmDecoder (AD2) family of alarm devices
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-alarmdecoder Version : 1.13.11 Upstream Contact: Nu Tech Software Solutions, Inc. * URL : http://github.com/nutechsoftware/alarmdecoder * License : Expat Programming Lang: Python Description : interface for the AlarmDecoder (AD2) family of alarm devices This Python library aims to provide a consistent interface for the AlarmDecoder product line: AD2USB, AD2SERIAL and AD2PI. This also includes devices that have been exposed via ser2sock, which supports encryption via SSL/TLS. I intend to maintain this package within the home assistant team.
Bug#1077007: ITP: python-adguardhome -- Asynchronous Python client for the AdGuard Home API
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-adguardhome Version : 0.7.0 Upstream Contact: Franck Nijhof * URL : https://github.com/frenck/python-adguardhome * License : Expat Programming Lang: Python Description : Asynchronous Python client for the AdGuard Home API This package allows you to control and monitor an AdGuard Home instance programmatically. It is mainly created to allow third-party programs to automate the behavior of AdGuard. . An excellent example of this might be Home Assistant, which allows you to write automations, to turn on parental controls when the kids get home. I intend to maintain this package within the Home Assistant team.
Bug#1077008: ITP: python-advantage-air -- API helper for Advantage Air's MyAir and e-zone API
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-advantage-air Version : 0.4.4 Upstream Contact: Brett Adams * URL : https://github.com/Bre77/advantage_air * License : Expat Programming Lang: Python Description : API helper for Advantage Air's MyAir and e-zone API API helper for Advantage Air's MyAir and e-zone API I intend to maintain this package within the Home Assistant team.
Packaging homeassistant in Debian
Dear friends, Together with a bunch of people during debcamp, we decided to package homeassistant. This is a huge task, with hundreds of dependencies. Since there's too many, we've been told to no Cc: debian-devel@l.d.o when filing the ITPs, and instead write a summary (as per developper's ref). Well, we wont write such a summary, but everyone can follow our progress on this wiki page, which fills the same purpose: https://wiki.debian.org/Python/HomeAssistant As you may see, there are 600+ packages to do. Since we're a lot of people on the task, we believe it can be done. I've written 13 packages myself, and uploaded most already. Edward Betts beated me by a very much higher numbers! billchenchina1 and omnidapps already wrote many packages waiting in the NEW queue too. Note that we decided to push these packages to a separate team, as we don't really see drivers for heaters or air cond systems as very useful for any other things than homeassistant. Things that do make sense for a more general purpose will be pushed to the Python team as we see fit. Cheers, Thomas Goirand (zigo)
Bug#1077136: ITP: python-aio-geojson-generic-client -- generic async GeoJSON client library
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aio-geojson-generic-client Version : 0.4 Upstream Contact: Malte Franken * URL : https://github.com/exxamalte/python-aio-geojson-generic-client * License : Apache-2.0 Programming Lang: Python Description : generic async GeoJSON client library This library provides convenient async generic access to GeoJSON https://datatracker.ietf.org/doc/html/rfc7946 feeds. It uses asyncio and aiohttp. . This package is a dependency for Home Assistant. I itend to maintain this package within the home assistant team.
Re: Packaging homeassistant in Debian
Hi Joerg, Thanks for voicing your opinion. On 7/26/24 15:25, Joerg Jaspert wrote: Not going to stop you - I actually think it would be a nice thing to have something like this packaged for real - but how realistic is this in a Debian stable release (assuming you ever manage to get all of it packaged and uploaded). Using HA myself, that thing and all around it is changing faster than anything else I ever saw. One basically finished updating ones install and it goes again "Update available". That's part of my motivation for having HA in Debian: I hate that it wants to update too fast: faster than I can cope with, demanding too much of my time. I do not really care having the latest shiny last thing, I want something that works, that is reliable, and that I don't have to maintain too much. Also, what really is there in the updates? Maybe one doesn't care about them 99% of the time. That driver foo for the device bar that you don't even use, do we really need to update it? I hope the core of Home Assistant itself doesn't move *THAT* fast. It's hard to tell without inspecting all pieces of the puzzle. Combined with upstreams focus on their HassOS thing (and yes, that *is* damn easy and low-effort to use!) I very much like Homeassistant. But there's many things I hate with HassOS, like the fact it is focused on using containers, and trying all it can to avoid exposing anything to users. I feel very uncomfortable using it. I'm currently using their Virtualbox image. My current process is to, every month, spend a few hours maintaining it doing this: - shutdown - snapshot - start - upgrade - stop - snapshot - start This is clearly what I would like to stop doing. I currently have to, because a few times, the automated upgrades of Home Assistant broke badly on me. I'm sure it's going to happen again: it also happened to some of my friends. is upstream support for "oh gosh you outdated distro" even there, in case this ends up in a stable release? That's probably what they will say. Nothing new, this is what all upstream tell. Frankly, I do not know what's going to happen with HA in a stable release or not. But even running Unstable would be a better solution for me than their "OS". I sure would like if it ever goes with an "apt install homeassistant" and you have what "put this HASSOS image into a VM/raspy and automate away" does now, thats a cool target. But you found yourself a hill even larger than the OpenStack one - and one that changes even more often and faster. :) OpenStack needs roughly 200 packages upgrade every 6 months, in a predictable way. I currently am not sure what it's going to be with HA. I'm convince that *a lot* of device drivers for many stuff (heatings, air-cond, etc.) will not change, because I'm seeing that what we're packaging smells like old stuff already. It doesn't mean unmaintained, it's probably doing what it should already, and doesn't need update. Also, for OpenStack, I've been mostly alone. We're currently 5 enthusiastic DDs in the Home Assistant team. It's possible even more will join us. I don't think I'm even going to be the main driver behind this packaging, Edward seems very motivated, and he's done a lot already. Anyways, that's the beginning of an adventure. Where this will lead us, I'm not sure yet... For sure, looking at how, and even more importantly what things get updated by upstream will be interesting, and this will tell us if it's possible to have this in Debian Stable. Maybe the only solution will be having most drivers in Debian Stable (the huge list of 680+ python modules we're packaging), and have HA only in a non-official backport repo. IMO this would already be a great achievement. Cheers, Thomas Goirand (zigo)
Bug#1077211: ITP: python-aioairq -- asynchronous library to retrieve data from air-Q devices
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aioairq Version : 0.4.2 Upstream Contact: Daniel Lehmann * URL : https://github.com/CorantGmbH/aioairq * License : Apache-2.0 Programming Lang: Python Description : asynchronous library to retrieve data from air-Q devices This Python library provides asynchronous data access to local air-Q devices. . This package is a dependency of Home Assistant. I intend to maintain this package in the Home Assistant team.
Bug#1077245: ITP: python-fnv-hash-fast -- fast version of fnv1a
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-fnv-hash-fast Version : 0.5.0 Upstream Contact: J. Nick Koston * URL : https://github.com/bdraco/fnv-hash-fast * License : Expat Programming Lang: Python Description : fast version of fnv1a This package provides a Python library which is a fast version of fnv1a. It use a CPP implementation of fnv1a (32) if cython is available, and will fallback to pure python from the fnvhash package if it is not. I intend to maintain this package in the Home Assistant team.
Bug#1077382: ITP: python-aiodhcpwatcher -- watch for DHCP packets with asyncio
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aiodhcpwatcher Version : 1.0.2 Upstream Contact: J. Nick Koston * URL : https://github.com/bdraco/aiodhcpwatcher * License : GPL-2+ Programming Lang: Python Description : watch for DHCP packets with asyncio This Python library makes it possible to watch for DHCP packets with asyncio. Users of this library will simply provide a callback function that this library will call whenever a DHCP packet is detected. I intend to maintain this package in the Home Assistant team.
Bug#1077562: ITP: python-chacha20poly1305 -- chacha20-poly1305 implementation based on tlslite-ng
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-chacha20poly1305 Version : 0.0.3 Upstream Contact: Dusan Klinec * URL : https://github.com/ph4r05/py-chacha20poly1305 * License : LGPL-2.1 Programming Lang: Python Description : chacha20-poly1305 implementation based on tlslite-ng Simple pure-python chacha20-poly1305 implementation based on tlslite-ng code. Designed to be compatible with Cryptography API. . This package is a dependency of Home Assistant. I intend to maintain this package in the Home Assistant team.
Bug#1077719: ITP: python-inquirerpy -- collection of common interactive command-line user interfaces
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-inquirerpy Version : 0.3.4 Upstream Contact: Kevin Zhuang * URL : https://github.com/kazhala/InquirerPy * License : Expat Programming Lang: Python Description : collection of common interactive command-line user interfaces InquirerPy is a Python port of the famous Inquirer.js: a collection of common interactive command line user interfaces. This project is a re-implementation of the PyInquirer project, with bug fixes of known issues, new prompts, backward compatible APIs, as well as more customisation options. I intend to maintain this package within the Home Assistant team.
Bug#1077721: ITP: python-aiolifx -- API for local communication with LIFX devices over a LAN with asyncio
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aiolifx Version : 1.0.6 Upstream Contact: François Wautier * URL : http://github.com/aiolifx/aiolifx * License : Expat Programming Lang: Python Description : API for local communication with LIFX devices over a LAN with asyncio This package provides a Python 3, asyncio library to control Lifx LED lightbulbs over your LAN. Most of it was taken from Meghan Clarkk lifxlan package (https://github.com/mclarkk) and adapted to Python 3 and asyncio. I intend to maintain this package within the Home Assistant team.
Bug#1079586: ITP: python-aioesphomeapi -- Python API for interacting with ESPHome devices
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aioesphomeapi Version : 25.1.0 Upstream Contact: Otto Winter * URL : https://github.com/esphome/aioesphomeapi/ * License : Expat Programming Lang: Python Description : Python API for interacting with ESPHome devices The aioesphomeapi Python package allows one to interact with devices flashed with ESPHome. . This package is a dependency of Home Assistant. I intend to maintain this package within the Home Assistant team.
Bug#1079692: ITP: python-sushy-oem-idrac -- Dell EMC iDRAC OEM extension package for the sushy library
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-sushy-oem-idrac Version : 5.0.0 Upstream Contact: OpenStack * URL : https://github.com/openstack/sushy-oem-idrac * License : Apache-2.0 Programming Lang: Python Description : Dell EMC iDRAC OEM extension package for the sushy library The sushy-oem-idrac package is a sushy extension package that aims at adding high-level hardware management abstractions, that are specific to Dell EMC BMC (which is known under the name of iDRAC), to the tree of sushy Redfish resources. I intend to maintain this package within the OpenStack team, as this is a recommends: for Ironic (aka: OpenStack baremetal as a service).
Bug#1079821: ITP: python-aiosomecomfort -- client for Honeywell's US-based cloud devices
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aiosomecomfort Version : 0.0.25 Upstream Author : Mike Kasper * URL : https://github.com/mkmer/AIOSomecomfort * License : GPL-3 Programming Lang: Python Description : A client for Honeywell's US-based cloud devices This package provides a client for Honeywell's US-based cloud devices. This is for the US model and website. Be aware that EU models are different! . This package is a dependency of Home Assistant. I intend to maintain this package within the Home Assistant team.
Re: Validating tarballs against git repositories
On 8/27/24 22:30, Jeremy Stanley wrote: On 2024-08-27 19:41:54 +0200 (+0200), tho...@goirand.fr wrote: [...] All you wrote is precisely why I am not using these tarballs. I know we don't agree... :) Also, the FTP master do NOT want the changeLog as they are too big and provide no value when one can check the git repo to find the same info. Sure, but the assembled release notes are not nearly as large as the changelog while still relying on having Git history available to build, and the generated authorship list is referred to in the license information for at least one OpenStack project as a stand-in for referencing Git committer metadata. To put it another way, upstream in OpenStack when the project was started in 2010, we were aware that package maintainers preferred signed and clearly versioned tarballs for every release, so that's what we structured our workflows and tooling around providing. In the meantime, package maintainers decided to take advantage of the fact that we use Git repositories in our development workflow but the release process we settled on isn't designed with that in mind, and changing workflows and processes in a developer community that size is sometimes like trying to steer a train. Well, I don't want to just package the generated stuff, I would prefer to have the tools to generate them myself from source at build time. And that's what has been bothering me since the beginning: I do not know how to do that, currently, neither for the authorship list or the release notes. In both case, the Git repo is needed, and that doesn't fit at all a packaging workflow, unless I embed all of the .git folder in the source package. This was truth in 2010, and still is in 2024... As a consequence, I decided not to care, as I haven't find a solution to "build from source", so I'm not packaging release notes and authorship list. It's probably my fault that I didn't contribute some fixes to reno though. Cheers, Thomas Goirand (zigo)
Bug#1079860: ITP: python-threadloop -- Tornado IOLoop Backed Concurrent Futures
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-threadloop Version : 1.0.2 Upstream Author : Grayson Koonce * URL : https://github.com/TomerFi/aioswitcher * License : Expat Programming Lang: Python Description : Tornado IOLoop Backed Concurrent Futures This package provides a way to run Tornado Coroutines from Synchronous Python. This is a new indirect dependency for OpenStack.
Bug#1079909: ITP: python-jaeger-client -- OpenTracing tracer implementation
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-jaeger-client Version : 4.8.0 Upstream Contact: Yuri Shkuro * URL : https://github.com/jaegertracing/jaeger-client-python * License : Apache-2.0 Programming Lang: Python Description : OpenTracing tracer implementation This is a client-side library that can be used to instrument Python apps for distributed trace collection, and to send those traces to Jaeger. See the OpenTracing Python API for additional detail. I intend to maintain this package within the OpenStack team.
Bug#1080389: ITP: cyborg -- OpenStack Acceleration as a Service
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: cyborg Version : 12.0.0 Upstream Contact: OpenStack Foundtaion * URL : https://opendev.org/openstack/cyborg * License : Apache-2.0 Programming Lang: Python Description : OpenStack Acceleration as a Service Cyborg provides a general management framework for accelerators such as FPGA, GPU, SoCs, NVMe SSDs, CCIX caches, DPDK/SPDK, pmem and so forth. It provides a REST API for basic accelerator life cycle management, and has a generic driver for common accelerator support.
Re: Network stack for Trixie
On 8/20/24 16:25, Daniel Gröber wrote: Frankly I think the problem we have here is that this shouldn't be a technical decision. We should focus on what the majority of our users actually want not our preferences. I strongly do not agree with the above. This is not a question of who likes what, it's a question of what we can, and should support. At this time, ifupdown as a concept, is just dead. Systemd raises events, and we must have the logic to implement it. This is one of the reason why the cloud image switched to netplan and systemd-networkd: it needed to respond to PCI hotplug events, and perform DHCP on a new NIC hotplug. With ifupdown, the way to do it, is to write udev rules. These more and more, are a bad concept that is being actively removed from systemd. For example, in Bookworm, you cannot rename a NIC using an udev rule, you must use a file under /etc/systemd/network. So we're already in, like it or not... It is also super hackish style of scripts with ifupdown. At this time, ifupdown isn't a good fit for the job, and I don't see anyone volunteering to change the situation. The ifupdown path is just reaching a dead end. If you find volunteers, we may reconsider. And then, you're saying it is a question of taste, and we should vote? I do not agree. This isn't the case. Please don't go that path of making people vote on something they may not know about, and will have no time to investigate or read about: this is just wrong. Instead, either get ifupdown actively maintained and fixed for newer systemd (and then come back to us), or give-up the idea, so we can switch to a more modern, systemd-compatible stack. I propose taking an informal vote on this to gather data on networking tool preference among DDs and the wider Debian community to settle this. Please don't. We do not need another systemd vote... @d-devel has this been done on decisions like these beore? How should we go about doing this? Would a GR be more appropriate? No, it would not. We haven't even finished discussing it internally in this team, yet even raised a topic in debian-project. Please do not just fire a GR so fast, we should discuss it calmly first. Did you also think that maybe, the technical committee could be involved, if we can't agree reasonably, rather than yet-another-GR ? We aren't even there yet... If it turns out I'm alone in wanting Debian to retain it's identity as Debian I will (grudingly) step aside on this matter, but in the absence of tangible data my current view is that this is not the case and I will take appropriate steps to protect that identity. This sounds like a threat, rather than getting involved in the decision making process. Can't we have a normal (technical) discussion instead? Cheers, Thomas Goirand (zigo)
Re: Community survey on network stack for Trixie
On 9/2/24 21:02, Andrej Shadura wrote: On Mon, 2 Sep 2024, at 19:41, Daniel Gröber wrote: I promise you I'm not intentionally, but I do recognize that it may be a side-effect. Likewise I feel like you're just interested in pushing this through as quickly as possible. Consider that for you time is an ally, being employed to work on this (AFAICT?). For the rest of us not so much. Debian is a primarily a volunteer project. Please stop pushing for doing things faster. I don’t think Lukas is rushing things too much. Indeed, Lukas should be thanks for putting so much effort on his proposal, and doing it in a way to gather consensus, with a lot of discussion involved. Cheers, Thomas Goirand (zigo)
Bug#1080977: ITP: oscs -- OpenStack cloud selector parses credentials from clouds.yaml
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: oscs Version : 0.0.1 Upstream Contact: Bertrand Lanson * URL : https://salsa.debian.org/openstack-team/clients/oscs * License : Expat Programming Lang: Python Description : OpenStack cloud selector parses credentials from clouds.yaml This package provides a parser for the ~/.config/openstack/clouds.yaml and makes it possible to select one of the, by exporting the OS_CLOUD environment variable. When using "oscs set" without any argument, oscs displays a nice fzf ncurse dialogue where uses can select what cloud to use with the arrow keys. . The way to use it, is to source /usr/share/oscs/oscs from your .bashrc.
Bug#1081203: ITP: python-threadloop -- Tornado IOLoop Backed Concurrent Futures
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-threadloop Version : 1.0.2 Upstream Contact: Grayson Koonce * URL : https://github.com/TomerFi/aioswitcher * License : Expat Programming Lang: Python Description : Tornado IOLoop Backed Concurrent Futures This package provides a way to run Tornado Coroutines from Synchronous Python. . Tornado is a Python web framework and asynchronous networking library, originally developed at FriendFeed. By using non-blocking network I/O, Tornado can scale to tens of thousands of open connections, making it ideal for long polling, WebSockets, and other applications that require a long-lived connection to each user.
Bug#1081993: ITP: python-infoblox-client -- client for interacting with Infoblox NIOS over WAPI
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-infoblox-client Version : 0.6.0 Upstream Author : John Belamaric * URL : https://github.com/infobloxopen/infoblox-client * License : Apache-2.0 Programming Lang: Python Description : client for interacting with Infoblox NIOS over WAPI This package provides a client for interacting with Infoblox NIOS over WAPI. . Network Identity Operating System (NIOS) is the operating system that powers Infoblox core network services, ensuring non-stop operation of network infrastructure. The basis for Next Level Networking, NIOS automates the error-prone and time-consuming manual tasks associated with deploying and managing DNS, DHCP, and IP address management (IPAM) required for continuous network availability and business uptime. This is a new dependency of OpenStack Designate, aka OpenStack DNSaaS.
Request for key signing in Shanghai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello!
Is there somebody in Shanghai from Debian able to check my ID and sign
my key? If there is none, is there somebody in Singapore, where I might
be able to go? I wouldn't be able to go in Hongkong (because of visa
problems) where I could see there was somebody available.
I think we (at GPLHost) did work valuable enough to interest people
using Debian for web hosting, and I'd like to enter as a Debian
developer. I know there would be some more work for our package to enter
Debian, but I'm ready (and I have the time) for it.
Best regards,
Thomas Goirand, GPLHost LLC Manager
- --
Web: http://www.gplhost.com
GPLHost:>_ Open source hosing worldwide
Web spaces featuring GPL control panel and Xen VPS
Locations in Singapore, Florida, Paris and Israel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEdtzKl4M9yZjvmkkRAj0DAJ9/I/XzRfOMqYQQabWBv2LOPrZEAQCg257C
RT/Vg79j1oc5ym5oQqMsh5A=
=lM0E
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for key signing in Shanghai
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen Gran wrote: > This one time, at band camp, Thomas Goirand said: >> Hello! >> >> Is there somebody in Shanghai from Debian able to check my ID >> and sign my key? If there is none, is there somebody in >> Singapore, where I might be able to go? I wouldn't be able to >> go in Hongkong (because of visa problems) where I could see there >> was somebody available. > > I don't know off hand. The list (probably slightly outdated) > of people offering key signing is at > https://nm.debian.org/gpg_offer.php It's a shame it's not up-to-date. Is there somewhere it's more accurate? I've seen it, and that's why I said there was nobody in Shanghai. In fact I was very surprised that there was nobody in China, as half of the world population is in China... Also, if I've post here, it's because I don't want to wait years until one of the registered developers come over here. Anyway, if one of you wants to come and visit, I can offer a nice bedroom for few nights (for you and your wife/gf). :) Will there be somebody around in Paris or in Florida this summer for signing my key??? (I might travel there...) > In order to maintain a single package, you don't really need to be a > Debian developer. It is quite possible to work with sponsored > uploads, and many people do quite well with that arrangement. I > am not trying to discourage you, just pointing out that you may > not need to jump through as many hoops as you think just > to participate. > > Take care, I have a lot more than one package to have uploaded. Maybe 10 already. mod_log_sql, sbox, dtc, mysqmail (which is made of 6 packages), etc... Also, it's often updated, and I wouldn't like to depend on somebody to have it uploaded. Of course, I'd be (more than) happy if one of you had the time to work with us, but I don't think there will be one as I've been trying for quite long already to catch the attention of a sponsor for uploading. Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEeIThl4M9yZjvmkkRAu8GAJ0e5KCO5Yitw6BMKVUQIf4VZM1sIACcCOu+ U72NwPcer84yzc6/rKUOYtQ= =aKdd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466433: ITP: dkfilter -- implements domainKeys message signing and verification
Package: wnpp Severity: wishlist Owner: Thomas Goirand <[EMAIL PROTECTED]> * Package name: dkfilter Version : 0.11 Upstream Author : Jason Long <[EMAIL PROTECTED]> * URL : http://jason.long.name/dkfilter/ * License : GPL v2 Programming Lang: Perl Description : implements domainKeys message signing and verification dkfilter is an SMTP-proxy designed for Postfix. It implements DomainKeys message signing and verification. It comprises two separate filters, an "outbound" filter for signing outgoing email, and an "inbound" filter for verifying signatures of incoming email. The filters can operate as either Before-Queue or After-Queue Postfix content filters. The following is not in the control file, just in this ITP: As Yahoo! requests DomainKeys to be implemented for sending mail to them, it's quite urgent that this package reaches SID asap to allow people to be able to send email to Yahoo! Note that this package is NOT to be confused with dk-filter (with a dash) that is a package for Sendmail, and that has nothing to do with the perl scripts for which I'm doing an ITP (even though both intend to implement DomainKeys, one is for Sendmail, while this one is for Postfix). -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (700, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23.9 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#468287: ITP: dkimproxy -- an SMTP-proxy that signs and/or verifies emails, using the Mail::DKIM module
Package: wnpp Severity: wishlist Owner: Thomas GOIRAND <[EMAIL PROTECTED]> * Package name: dkimproxy Version : x.y.z Upstream Author : Jason Long <[EMAIL PROTECTED]> * URL : http://dkimproxy.sourceforge.net/ * License : GPL v2 Programming Lang: Perl Description : an SMTP-proxy that signs and/or verifies emails, using the Mail::DKIM module DKIMproxy is an SMTP-proxy that signs and/or verifies emails, using the Mail::DKIM module. It is designed for Postfix, but should work with any mail server. It comprises two separate proxies, an "outbound" proxy for signing outgoing email, and an "inbound" proxy for verifying signatures of incoming email. With Postfix, the proxies can operate as either Before-Queue or After-Queue content filters. - Maintainer's note: Note that after this package is upload, I can also upload a new version of dtc that will use it instead of dkfilter, and then I will ask for removal of dkfilter that is has been superceded by dkimproxy. FYI, See this bug in the BTS as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468192 -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (700, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.23.9 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#537423: ITP: mysqmail -- Use MySQL accouting and auth for most used MTA
Package: wnpp Severity: wishlist Owner: Thomas Goirand Hi there! I wish to package this software in order to have it enter Debian. This is the companion bandwidth accounting daemon for DTC (already in the archive), that we finally managed to debug after so many years we didn't care enough about it. Later, when it enters the archive, dtc will have a Depends: on it. * Package name: mysqmail Version : 0.4.1 Upstream Author : Thomas Goirand * URL : http://www.gplhost.com/software-mysqmail.html * License : GPL Programming Lang: C Description : Use realtime MySQL bandwidth accouting and auth for most used MTA MySQMail is a set of tiny daemon loggers for Qmail, Postfix, Pure-ftpd and Courier that will save trafic informations in database. This package holds the configuration file management for the other packages which share the same /etc/mysqmail.conf: mysqmail-qmail-logger, mysqmail-postfix-logger, mysqmail-pure-ftpd-logger and mysqmail-courier-logger. -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550031: ITP: libjs-extjs -- a cross-browser JavaScript library
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: libjs-extjs Version : 3.0.0 Upstream Author : Ext JS LLC * URL : http://www.extjs.com/ * License : GPL-3 Programming Lang: Javascript, PHP Description : a cross-browser JavaScript library A cross-browser JavaScript library for building rich internet applications. . The Ext JS library is widely use in numerous web applications. It includes: high performance, customizable UI widgets, well designed and extensible Component model, qn intuitive, easy to use API, Commercial and Open Source licenses available. Ext JS supports all major web browsers including: Internet Explorer 6+, FireFox 1.5+ (PC, Mac), Safari 3+, Opera 9+ (PC, Mac). Ext products are used by companies all over the world across many industries. Listed below are just a few of those companies: * Adobe * Aetna * AIG * Alcatel-Lucent * Amazon.com * Best Buy * Boeing * Borland * CA * Canon * Capgemini * Cisco * CNN * Dow Jones & Co. * EMC * Fidelity * General Electric * Hallmark * HP * HSBC * IBM * Mott MacDonald * NATO * NetApp * Nortel * Northrop Grumman * Panasonic * Pixar Animation Studios * Qualcomm, Inc. * S&P * SAP * Siemens * Sony * Symantec * Visa International So I believe it's becomming increasingly important to have this library included in main, as it's the base of many web applications that we would potentially want to include in Debian as well. After I got this library uploaded into Debian, I am wishing to work on some web apps that are using it, namely eXtplorer (an Ajax web file manager, which is important to me as none are included in Debian even if 100s are available for download on the web), ARIA Tree (as I need it for our web hosting panel DTC), and maybe more if I have time. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550031: ITP: libjs-extjs -- a cross-browser JavaScript library
Marcus Better wrote: > This is non-free. Please keep it out of Debian. > > Surely you are aware of the huge controversy around Ext JS licensing. > There is no need to repeat that story here, let me just point to this page: > http://www.extjs.com/company/dual.php > > Here they make claims that directly contravene parts of GPL-3: > > "If you derive a commercial advantage by having a closed source > solution, you must purchase an appropriate number of commercial licenses > from Ext." > > And this: > > "If you wish to use the open source license of an Ext product, you must > contribute all your source code to the open source community and you > must give them the right to share it with everyone too." > > Cheers, > > Marcus Hell, I missed it. This doesn't appear at all on the license.txt. Do you think I could still package it for the non-free archive? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550031: ITP: libjs-extjs -- a cross-browser JavaScript library
brian m. carlson wrote: > On Wed, Oct 07, 2009 at 04:13:59PM +0200, Mike Hommey wrote: >> Except the issue is not about dual licensing, but about intent being >> different to what the license actually says. i.e. The GPL3 the code is >> supposed to be released under doesn't have these obligations, and >> anybody not contributing back or taking commercial advantage in a closed >> source solution is in its total rights under the GPL3 license. Also, now that I read it again, the following in the page http://www.extjs.com/company/dual.php: "If you wish to use the open source license of an Ext product, you must contribute all your source code to the open source community and you must give them the right to share it with everyone too." may be a fail of the dissident test, as there is the word "must". But this is a "Quick Overview", and could be considered a bad interpretation or misunderstanding. Anyway, I got in touch with the author, I hope they will reply. If not, I will call them and try to clarify what is the author's intention and explain the Debian view on freeness, plus the fact that their license is raising some controversial opinions that should be avoided if possible. If I get no reply from them, or anything positive, then why should I care doing the packaging in main? Either send it in non-free or just forget about it... Please do not start a 100 post thread in this ITP if this has been discussed in the past (let's not loose time twice on a bad license). I just would like to have a link here to the archive of the old discussion about if one of you can find it. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550031: ITP: libjs-extjs -- a cross-browser JavaScript library
> Thomas, > > It's not my position to get into Debian's debate. I can confirm for you > that Ext JS can absolutely be licensed under GPL v3 without qualification. > If there is commentary that can be read counter to that, then that is not a > good read of what we are saying. From a legal standpoint, Ext JS can be > licensed under GPL v3, or alternatively under a Commercial License from Ext > JS. We put no conditions on the GPL v3 use, other than those of GPL v3 > itself. > > ~ Adam Nobody is asking for debate, but if you were to write yourself "We put no conditions on the GPL v3 use, other than those of GPL v3 itself." ends any starting debate indeed, but then what you have write on your website is kind of confusing (at least to some of us). Now, I wonder what other people from Debian will say after this declaration. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550031: ITP: libjs-extjs -- a cross-browser JavaScript library
Neil Williams wrote: > On Fri, 9 Oct 2009 00:20:51 - (UTC) > "Thomas Goirand" wrote: > >>> It's not my position to get into Debian's debate. I can confirm for you >>> that Ext JS can absolutely be licensed under GPL v3 without qualification. >>> If there is commentary that can be read counter to that, then that is not a >>> good read of what we are saying. From a legal standpoint, Ext JS can be >>> licensed under GPL v3, or alternatively under a Commercial License from Ext >>> JS. We put no conditions on the GPL v3 use, other than those of GPL v3 >>> itself. >>> >>> ~ Adam >> Nobody is asking for debate, but if you were to write yourself "We put no >> conditions on the GPL v3 use, other than those of GPL v3 itself." ends any >> starting debate indeed, but then what you have write on your website is >> kind of confusing (at least to some of us). >> >> Now, I wonder what other people from Debian will say after this declaration. > > What matters is what is claimed as the licence for the code itself, not > how that licence is or is not described on a website. But the license file refers to the website... Here's the main part of its content: Open Source License -- Ext is licensed under the terms of the Open Source GPL 3.0 license. http://www.gnu.org/licenses/gpl.html There are several FLOSS exceptions available for use with this release for open source applications that are distributed under a license other than the GPL. * Open Source License Exception for Applications http://extjs.com/products/floss-exception.php * Open Source License Exception for Development http://extjs.com/products/ux-exception.php Commercial License -- This is the appropriate option if you are creating proprietary applications and you are not prepared to distribute and share the source code of your application under the GPL v3 license. Please visit http://extjs.com/license for more details. OEM / Reseller License -- For more details, please visit: http://extjs.com/license. As you see, even the license.txt is kind of wrong and doesn't cut/past the necessary parts of the GPL v3. > If the claims on the website are retained into the licensing of the > software, then the software would seem to be non-distributable as the > licence (taken as a whole, the additional claims and the main licence) > is in conflict. What if the license.txt is like above? > If the software comes with an unaltered copy of the GPL3 and no other > conditions, then the website claims can be deemed misleading but > are irrelevant to the software to be packaged for Debian. The software comes with NO COPY AT ALL of the GPL3. Just a link to it as per above. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#550031: ITP: libjs-extjs -- a cross-browser JavaScript library
> Thomas,
>
> I discussed this matter with our CEO and he asked me to resolve the
> compliancy. I iwll update you shortly.
>
> ~ Adam
Hi Adam,
Ok, that sounds good, as I would really hate to push for a
package that has some controversy on the freeness of it's license.
I am very happy to see that you guys respond to emails, and this
makes me feel a lot more comfortable for this packaging.
I have already done my packaging, you can get the Debian package
from there if you want to test/see/comment them:
http://ftparchive.gplhost.com/debian/pool/lenny/main/l/libjs-extjs/
At the time of reading, it should also have reached all of our
mirrors around the world.
As you can see, I have separated the library itself from the
documentation, as it was rather big, and this is a good practice
in this case in Debian.
Let me know when you update your site and/or your licensing,
Best Regards,
Thomas Goirand
--
Thomas Goirand
GPLHost CEO
Phone numbers: +1 302 213 1611 (USA) / +33 177627734 (France)
+44 8449108864 (UK) / +61 280617698 (Australia)
Web: http://www.gplhost.com
GPLHost:>_ Open source hosting worldwide
Web spaces featuring GPL control panel and Xen VPS
Locations in Singapore, Sydney, Seattle, Florida, Paris, London,
Barcelona, Israel and Malaysia
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561871: ITP: libjs-edit-area -- a free javascript editor for source code
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: libjs-edit-area Version : 0.8.1.1 Upstream Author : Christophe Dolivet http://www.cdolivet.com/index.php?page=Contact * URL : http://www.cdolivet.com/index.php?page=editArea * License : LGPL, BSD, Apache (at your choice) Programming Lang: Javascript Description : a free javascript editor for source code Edit-area is a free javascript editor for source code that is easy to integrate, has only one script include and one function call. It supports tabulation (allow to write well formated source code), has customizable real-time syntax highlighting (currently: PHP, CSS, Javascript, Python, HTML, XML, VB, C, CPP, SQL, Pascal, Basic, Brainf*ck, and probably more...), word-wrap support, search and replace (with regexp), auto-indenting new lines, line numerotation, multilanguage support (currently: Croatian, Czech, Danish, Dutch, English, Esperanto, French, German, Italian, Japanese, Macedonian, Polish, Portuguese, Russian, Slovak, Spanish, and probably more...), has the possibility to use PHP gzip compression (compress the 12 core files to one file of ~30Ko), allows multiple instances, has a full screen mode, possible plugin integration, possible save and load callback functions, possible dynamic content management, can work in the same environment than prototype and mootools's like libraries. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561872: ITP: extplorer -- a web file explorer and manager using Ext JS
Package: wnpp Severity: wishlist Owner: Thomas Goirand Package name: extplorer Version : 2.1.0b6 Upstream Author : Soeren Eberhardt URL : http://extplorer.sourceforge.net/ License : GPL-2 Programming Lang: PHP / Javascript Description : a web file explorer and manager using Ext JS a web-based File Manager. You can use it to: * browse directories & files on the server and * edit, copy, move, delete files, * search, upload and download files, * create and extract archives, * create new files and directories, * change file permissions (chmod) and much more... You can even use eXtplorer to login to the FTP server (like net2ftp) and work as if you were using an FTP client. Access via WebDAV is also possible (requires some extra work and a database!). eXtplorer is released under a dual-license: You can choose wether you want to use eXtplorer under the Mozilla Public License (MPL 1.1) or under the GNU General Public License (GNU/GPL). Note that if you decide to distribute/use eXtplorer under the MPL, you are not allowed to use the ExtJS Javascript library. This ITP is an intend to finally have a web file manager included into Debian as there's currently none of them, and this gap needed to be filled by someone. I have picked up this software because: - It's famous, and wide spread - It has all the functionnalities that someone would need, especially archive extractions which saves a lot of time to anyone working on a website with FTP access only. - It has a nice and convenient web interface which makes it nearly a heavy client even though writen in PHP/JS (right click, drag and drop, Ajax, etc.). - It's using a well know and well maintained JS library (ExtJS) that is also well maintained. - It's author has been (very) responsive and helpfull to all my requests, and I believe that he will be able to address any security and bugfix concerns. The package is already working and lintian clean (I know... doing things the opposte way as it should here, as ITP should be filled first...), only the edition of the authusers is missing, but the author promissed me to fix it this week, so I can ask for a sponsored upload soon. Note that I already have all the dependencies package work done as well: - extjs 3.03 (itp already obtained) - edit-area - php-http-webdav - php-services-json - php-mime-type - php-archive I intend to have all these uploaded as well. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561873: ITP: php-services-json -- PHP implementaion of json_encode/decode
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: php-services-json Version : 1.0.1 Upstream Author : Alan Knowles * URL : http://pear.php.net/package/Services_JSON/download * License : BSD Programming Lang: PHP Description : PHP implementaion of json_encode/decode JSON (JavaScript Object Notation, http://json.org) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. This feature can also be found in Python. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, TCL, and many others. These properties make JSON an ideal data-interchange language. . This package provides a simple encoder and decoder for JSON notation. It is intended for use with client-side Javascript applications that make use of HTTPRequest to perform server communication functions - data can be encoded into JSON notation for use in a client-side javascript, or decoded from incoming Javascript requests. JSON format is native to Javascript, and can be directly eval()'ed with no further parsing overhead. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561875: ITP: php-mime-type -- Utility class for dealing with MIME types
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: php-mime-type Version : 1.2.0 Upstream Author : Christian Weiske http://pear.php.net/account-mail.php?handle=cweiske * URL : http://pear.php.net/package/MIME_Type/ * License : PHP 3.01 Programming Lang: PHP Description : Utility class for dealing with MIME types Provide functionality for dealing with MIME types: * Parse MIME type. * Supports full RFC2045 specification. * Many utility functions for working with and determining info about types. * Most functions can be called statically. * Autodetect a files mime-type, either with fileinfo extension, mime_magic extension, the file command or an in-built mapping list -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561876: ITP: php-archive-tar -- Tar file management class
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: php-archive-tar Version : 1.3.3 Upstream Author : Michiel Rook http://pear.php.net/account-mail.php?handle=mrook * URL : http://pear.php.net/package/Archive_Tar * License : BSD Programming Lang: PHP Description : Tar file management class This class provides handling of tar files in PHP. It supports creating, listing, extracting and adding to tar files. Gzip support is available if PHP has the zlib extension built-in or loaded. Bz2 compression is also supported with the bz2 extension loaded. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561907: ITP: php-http-webdav-server -- WebDAV server base class
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: php-http-webdav-server Version : 1.0.0RC4 Upstream Author : Hartmut Holzgraefe * URL : http://pear.php.net/package/HTTP_WebDAV_Client * License : PHP 3.01 Programming Lang: PHP Description : WebDAV server base class RFC2518 compliant helper class for WebDAV server implementation. Web-based Distributed Authoring and Versioning, or WebDAV, is a set of extensions to the Hypertext Transfer Protocol (HTTP) that allows computer-users to edit and manage files collaboratively on remote World Wide Web servers. RFC 4918 defines the extensions. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Steve Langasek wrote: > In this scenario, with Recommends installed by default (the only sane > model), the vast majority of metapackage dependencies are moved from Depends > to Recommends, so you can remove those Recommends manually without forcing > removal of the metapackage; and you can remove the metapackage without > causing cascading autoremoval of e.g., half your desktop. If I may, the "Recommends installed by default" scenario doesn't really apply here, as the goal here is to remove some dependencies that you don't want to have, because you want a smaller system. So what you are asking for is having even MORE packages installed when we want LESS. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFC] DEP-6: Meta-Package debian/control field
Steve Langasek wrote: > From what I can tell, the only difference between the two implementations is > compatibility with disabling installation of Recommends by default. > > I don't think this is a good rationale for adding yet another package > relationship field. The Recommends field is *already* defined in Policy to > have the behavior you're looking for (installed by default but not a hard > requirement), and I don't see any reason that metapackages should need the > added complexity of a different field. Without this metapackage thing, the only option we have is to have so many many metapackages, so we can choose one of them. This is not very nice, because that means that maintainers have to have the will to do it (which wont ever be the case for all of them). Which is why a real system to manage this would be nice. Another point would be that a meta-package could add a new meta-dependency in a new release. > Try to change your POV from the uber-user, who knows how to install "base" > packages and let others be pulled in, to the low-level users, which want > "gnome" installed, but don't want "rhythmbox" nor "banshee" installed. This > is what they do (writing the CLI version, but they're likely to use > something like Synaptic): > > # aptitude install gnome > # aptitude remove rhythmbox > > OOPS! Since aptitude does "autoremove" by default, the users suddenly get > asked to remove all their desktop environments. How many requests of this > type have you seen on IRC, mailing lists, Usenet? I've seen *TOO MANY*, and > that's why I drafted this DEP in the first place. EXACTLY! This is not only because of requests, this has annoyed everyone for a long long time. > Then I suggest you just help converting the gnome metapackage to a > task, since this'll work with no intrusive changes in our tools. Well, the issue is not ONLY with gnome, there are many many more. For example the X system installing all drivers, then you want to remove few of them that you don't care and identify as not for you, but keep all the rest of "just in case". I see few other examples in packages that I maintain myself where removing 1 or 2 package could be nice, still keeping new packages that would come with the metapackage in case of an upgrade, and giving freedom to users to do what they want. Andreas Metzler wrote: > The current proposal is not backwards compatible since it fundamentally > changes the meaning of Depends. Depends is transitive. If A depends on > B, and B depends on C. A can rely on functionality proveided by C. > Your proposal breaks that, since it allows removal of C (assuming B is > a meta package), keeping it installed in a broken state. > > I am not convinced that the gain (easily install KDE without kmail, or > something like that) is worth this price. It changes a clear relation > to something that most of the times works as expected, except for some > special cases. I do agree that the proposed implementation is bad, and that Depends should not change meaning. I do like more the Meta-Depends: instead of Depends: if we want to keep the original idea. How about having a differentiation about the idea and the implementation in this discussion? :P Also, I think having a Metapackage: yes field IS a good idea anyway, even if there's absolutely NOTHING ELSE implemented with it but search functionalities, which would be very convenient (unless there's also Meta-Depends, but we could imagine a package that would like the functionality of Meta-Depends and still not being a Meta-Package and installing useful files...). Does the majority agree with me on that point here? Just my 2 cents, as I wont be the one implementing anything... :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562193: ITP: xen-qemu-dm-3.4 -- Xen Qemu Device Model virtual machine hardware emulator
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: xen-qemu-dm-3.4 Version : 3.4.2 Upstream Author : Xensource * URL : http://www.xen.org/ * License : GPL Programming Lang: C Description : Xen Qemu Device Model virtual machine hardware emulator This package is the Xen version of the Qemu emulator especially patched for its hypervisor. With xen-qemu-dm, you can run a fully virtualized virtual machine if your hardware supports it (Intel VT support, or AMD-v technology). Explanation on why this package is created: Bastian Blank decided to remove xen-qemu-dm from his Xen packages, as he believed he could not face any potential security issues in the Xen version of Qemu. As many people still need HVM support in Xen, I have gathered a small team of people that are reading the xen-devel list, to maintain this package: Ian Jackson -> Debian guy at Citrix Stefano Stabellini -> Qemu guy at Citrix Christian Motschke -> Volunteering Samuel Thibault -> Can help so that I wont get stuck if there is any security issue on the package. I will also build a private mailing list with the above persons registered, so we can work as a team in case any issue is raised by the security team or others. I intend to be the main package maintainer, but I wont have any internal knowledge of the source code, which is why I insisted on having help here. This has already proven to be the right path, as Ian Jackson (and others) have been of great help. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562747: ITP: php-text-captcha -- a PEAR module for generating CAPTCHAs
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: php-text-captcha Version : 0.4.0 Upstream Author : Christian Wenz * URL : http://pear.php.net/package/Text_CAPTCHA * License : BSD Programming Lang: PHP Description : a PEAR module for generating CAPTCHAs Implementation of CAPTCHAs (completely automated public Turing test to tell computers and humans apart) in a nice easy to use PHP class, so that you can include the test in your web site or web application. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562750: ITP: php-text-figlet -- a PEAR module for rendering text using FIGlet fonts
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: php-text-figlet Version : 1.0.1 Upstream Author : Jan Schneider * URL : http://pear.php.net/package/Text_Figlet/ * License : BSD Programming Lang: PHP Description : a PEAR module for rendering text using FIGlet fonts The Text_Figlet is an engine for using FIGlet fonts to rendering text. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562749: ITP: php-image-text -- a PEAR module to do advanced text maipulations in images
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: php-image-text Version : 0.6.0beta Upstream Author : Tobias Schlitt * URL : http://pear.php.net/package/Image_Text/ * License : PHP 3.01 Programming Lang: PHP Description : a PEAR module to do advanced text maipulations in images Image_Text provides a comfortable interface to text manipulations in GD images. Beside common Freetype2 functionality it offers to handle texts in a graphic- or office-tool like way. For example it allows alignment of texts inside a text box, rotation (around the top left corner of a text box or it's center point) and the automatic measurizement of the optimal font size for a given text box. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562751: ITP: php-text-password -- a PEAR module for creating passwords with PHP
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: php-text-password Version : 1.1.1 Upstream Author : Martin Jansen * URL : http://pear.php.net/package/Text_Password * License : PHP 3.01 Programming Lang: PHP Description : a PEAR module for creating passwords with PHP Text_Password allows one to create pronounceable and unpronounceable passwords. The full functional range is explained in the manual at http://pear.php.net/manual/. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562752: ITP: php-numbers-words -- a PEAR module providing methods for spelling numerals in words
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: php-numbers-words Version : 0.16.1 Upstream Author : Marcelo Subtil Marcal * URL : http://pear.php.net/package/Numbers_Words * License : PHP 3.01 Programming Lang: PHP Description : a PEAR module providing methods for spelling numerals in words With Numbers_Words class you can convert numbers written in arabic digits to words in several languages. You can convert an integer between -infinity and infinity. If your system does not support such long numbers you can call Numbers_Words::toWords() with just a string. . With the Numbers_Words::toCurrency($num, $locale, 'USD') method you can convert a number (decimal and fraction part) to words with currency name. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#497899: ITP: automysqlbackup -- a daily, weekly and monthly backup for your MySQL database
Package: wnpp Severity: wishlist Owner: Thomas GOIRAND <[EMAIL PROTECTED]> Package name: automysqlbackup Version : 2.5 Upstream Author : [EMAIL PROTECTED] URL : http://sourceforge.net/projects/automysqlbackup/ License : GPL Programming Lang: sh Description : a daily, weekly and monthly backup for your MySQL database automysqlbackup creates backup every day, week and month for all of your MySQL database, to a configured folder. There's nothing to do but to install this package, and you'll rest assured that you have a way to go back in the history of your database. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (700, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.26.2 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435150: ITP: php-http-upload -- php-http-upload
Package: wnpp Severity: wishlist Owner: Thomas GOIRAND <[EMAIL PROTECTED]> * Package name: php-http-upload Version : 0.9.1 Upstream Author : Tomas Von Veschler Cox <[EMAIL PROTECTED]> * URL : http://pear.php.net/package/HTTP_Upload * License : LGPL Programming Lang: PHP Description : Easy and secure managment of files submitted via HTML Forms This class provides an advanced file uploader system for file uploads made from html forms. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (700, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.7 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#438642: ITP: php-net-geoip -- Library to perform geo-location lookups of IP addresses
Package: wnpp Severity: wishlist Owner: Thomas Goirand <[EMAIL PROTECTED]> Package name: php-net-geoip Version : 1.0.0RC1 Upstream Author : Jim Winstead <[EMAIL PROTECTED]> URL : http://pear.php.net/package/Net_GeoIP/ License : LGPL Programming Lang: PHP Description : Library to perform geo-location lookups of IP addresses A library that uses Maxmind's GeoIP databases to accurately determine geographic location of an IP address. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (700, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.7 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#443528: ITP: xmms-pulse -- Pulseaudio Output plugin for xmms
Package: wnpp Severity: wishlist Owner: Thomas Goirand <[EMAIL PROTECTED]> * Package name: xmms-pulse Version : 0.9.3 Upstream Author : Lennart Poettering <[EMAIL PROTECTED]> * URL : http://0pointer.de/lennart/projects/xmms-pulse/ * License : GPL v2 Programming Lang: C/C++ Description : Pulseaudio output plugin for xmms This plugin connects xmms to Pulseaudio, a drop in replacement for the ESD sound server with much better latency, so its output will be mixed with your system sounds and the output of other ESD/pulse programs, rather than conflicting with them. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (700, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.7 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443528: ITP: xmms-pulse -- Pulseaudio Output plugin for xmms
Thomas Viehmann wrote: > Hi, > > Thomas GOIRAND wrote: >> Description : Pulseaudio output plugin for xmms > > Last I heard the xmms maintainers asked for input on removing xmms and > how to deal with the plugins already in the archive... > > Kind regards > > T. Does it mean that I should try and make it work with xmms2 instead, which means open an ITP for xmms2-pulse? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444392: ITP: miniupnpc -- UPnP IGD client lightweight library
Package: wnpp Severity: wishlist Owner: Thomas Goirand <[EMAIL PROTECTED]> * Package name: miniupnpc Version : 1.0-RC9 Upstream Author : Thomas Bernard <[EMAIL PROTECTED]> * URL : http://miniupnp.free.fr/ * License : BSD Programming Lang: C, C++ Description : UPnP IGD client lightweight library The UPnP protocol is supported by most home adsl/cable routers and Microsoft Windows 2K/XP. The aim of the MiniUPnP project is to bring a free software solution to support the "Internet Gateway Device" part of the protocol. The MediaServer/MediaRenderer UPnP protocol is also becoming very popular but here we are talking about IGD. Miniupnpc aims at the simplest library possible, with the smallest footprint and no dependencies to other libraries such as XML parsers or HTTP implementations. All the code is pure ANSI C. Compiled on a x86 PC, the miniupnp client library have less than 15KB code size. For instance, the upnpc sample program is around 20KB. The miniupnp daemon is much smaller than any other IGD daemon and is ideal for using on low memory device for this reason. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (700, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.7 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444399: ITP: minissdpd -- UPnP IGD discovery speed enhancer for miniupnpc
Package: wnpp Severity: wishlist Owner: Thomas Goirand <[EMAIL PROTECTED]> * Package name: minissdpd Version : 1.0-RC9 Upstream Author : Thomas Bernard <[EMAIL PROTECTED]> * URL : http://miniupnp.free.fr/ * License : BSD Programming Lang: C, C++ Description : UPnP IGD discovery speed ehancer for miniupnpc In order to reduce discovery time in UPnP enabled applications, MiniSSDPd was developped for use in conjunction with MiniUPnPc. MiniSSDPd receive and process SSDP announces broadcasted on the network by UPnP devices so when an application starts, it does not need to do the whole discovery process. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (700, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.7 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444393: ITP: miniupnpd -- UPnP IGD lightweight daemon
Package: wnpp Severity: wishlist Owner: Thomas Goirand <[EMAIL PROTECTED]> * Package name: miniupnpd Version : 1.0-RC9 Upstream Author : Thomas Bernard <[EMAIL PROTECTED]> * URL : http://www.example.org/ * License : BSD Programming Lang: C, C++ Description : UPnP IGD lightweight daemon The UPnP protocol is supported by most home adsl/cable routers and Microsoft Windows 2K/XP. The aim of the MiniUPnP project is to bring a free software solution to support the "Internet Gateway Device" part of the protocol. The MediaServer/MediaRenderer UPnP protocol is also becoming very popular but here we are talking about IGD. Miniupnpc aims at the simplest library possible, with the smallest footprint and no dependencies to other libraries such as XML parsers or HTTP implementations. All the code is pure ANSI C. Compiled on a x86 PC, the miniupnp client library have less than 15KB code size. For instance, the upnpc sample program is around 20KB. The miniupnp daemon is much smaller than any other IGD daemon and is ideal for using on low memory device for this reason. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (700, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.7 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445741: ITP: tumgreyspf -- external policy checker for the postfix mail server
Package: wnpp Severity: wishlist Owner: Thomas Goirand <[EMAIL PROTECTED]> * Package name: tumgreyspf Version : 1.28 Upstream Author : Sean Reifschneider <[EMAIL PROTECTED]> * URL : http://www.tummy.com/Community/software/tumgreyspf/ * License : GPL v2 Programming Lang: Python Description : external policy checker for the postfix mail server Tumgreyspf can optionally greylist and/or use spfquery to check SPF records to determine if email should be accepted by your server. Because of it's design, legitimate e-mail is never trapped or rejected. Only spam and viruses are caught. If you add tumgreyspf to your mail server (also compatible when using Spam Assassin, ClamAV, and an outsourced anti-spam system), your spam level will be dropped by an order of magnitude. Tumgreyspf uses the file-system as it's database, no additional database is required to use it. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (700, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.7 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen, Squeeze, and Beyond
> But xen-tools have be removed from Squeeze, so I suppose it will be more > difficult to create new > installations (require much more work to replace the xen-create-image script). Well, I've been maintaining dtc-xen since Lenny, and it does even more than xen-tools. DTC-Xen is in Squeeze and I wont give-up on it. > > 6) Are we communicating this to Debian users in some way? What can I do > > to help with this point? > Remind people that Xen is dying and KVM is the present and the future. This is your own *personal view* on Xen vs KVM thing. I really don't see Xen dying despite the 2 years of bad propaganda of the KVM supporters. This eroneous view should *NOT* be pushed as Debian's official view. Xen is doing well, and there are more chances that the dom0 patches will be accepted this year as people improve Xen as required for inclusion. Xen support in Debian will continue as long as there are some people willing to work on it, and there's quite some activity by the pkg-xen guys (Bastian, etc.). Thomas -- 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/1269424689.1738.2.ca...@nokia-n900-42-11
Re: Xen, Squeeze, and Beyond
- Original message - > Ben Hutchings wrote: > > Xen might be doing well in some distributions but in lenny it has been a > > disaster. We have been stuck with a dead-end branch that no-one has the > > time and knowledge to fix. I believe squeeze will be better due to the > > common base kernel version and some support from upstream Xen developers > > (particularly Ian Campbell), but it will still lack the wide support > > that KVM gets as a project that has been merged into the kernel. > > I've just noticed that HVM guests (such as Windows) are broken in Xen in > squeeze due to the lack of qemu-dm (see #562703). Any word on plans for > that? There's more than plan, there's the solution. It's been 3 months that I am searching for a sponsor for this one: http://ftparchive.gplhost.com/debian/pool/lenny/main/x/xen-qemu-dm-3.4/xen-qemu-dm-3.4_3.4.2-1.dsc Which is tested and working. If anyone cared sponsoring the 1st upload that'd be great. I have a good hope to be DM allowed soon as my AM already approved it. I have Ian Jackson and the person responsible for Qemu in Xen (both from Citrix) that promissed to help, especially in case of a security issue on the package. Thomas (from my mobile) -- 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/1269458536.2358.2.ca...@nokia-n900-42-11
Bug#580936: ITP: xen-qemu-dm-4.0 -- Xen Qemu Device Model virtual machine hardware emulator
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: xen-qemu-dm-4.0 Version : 4.0.0 Upstream Author : Xen Devel * URL : http://www.xen.org/ * License : BSD, GPL v2, GPL v2 or later Programming Lang: C, C++ Description : Xen Qemu Device Model virtual machine hardware emulator This package is the Xen version of the Qemu emulator especially patched for its hypervisor. With xen-qemu-dm, you can run a fully virtualized virtual machine if your hardware supports it (Intel VT support, or AMD-v technology). -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- 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/20100509224739.22905.27133.report...@buzzig.gplhost.com
Let's write a system admin friendly mail server packaging system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear everyone, 1/ Briefly, who am I My first Debian package was for the web hosting control panel (a web interface) that my company released in open source. I'm the main programmer of it. The first time I tried to have it enter in Debian, it created a huge controversy, with (I heard) a 70 post thread in -private after it got sponsored. The reason was that my package goal is to have an over-simplified system, so that the user of it doesn't have to touch anything to the system configuration, everything has to be automated (which is the goal of my app). In Debian, by policy, a package cannot touch another package's configuration file. While I believe this policy is a good one, but it prevented me from having my postinst to do a successful setup without breaking the policy. The result is that what should have been sent to the postinst of my package has then been sent to a userland script (with often, users not starting the script an complaining about it in my forum). It doesn't make this script less ugly if running in userland rather than in the maintainer scripts (it is REALLY an ugly script, and I'm quite not proud of it), but at least it respects the policy. As I am soon to become a Debian Developer (if the DAM accepts me, after my AM wrote his report), I believe it is now time to get even more involved in Debian, and try to solve that issue once and for all. Even if for a reason or another, I'm rejected (which I don't think will happen), I still want to start the below discussion. 2/ The problematic == What happens here is that, if you take a normal Debian system, then install postfix, then let's say amavis, they don't talk to each other. In the same way, if you add dkimproxy (that I maintain), or clamsmtp, or tumgreyspf (that I maintain as well), you end up with a system that is not configured at all. None of these mail server components are aware of each other, and a system administrator has to spend a great deal of time to make it work. Truth is, in today's world, it is totally unrealistic to believe that just postfix is enough for setting up a mail system. There's just too much spams. It is also totally unrealistic to say that it's up to the system administrator to configure everything by hand. If, like me, you do at least one setup a day, it takes too much time for no reason, and it has to be automated in some way. There's loads of howtos available in many places that describe in 10 pages or more how to have a successful setup. This is really a pain. This is the reason why I'm writing this today: I want to (with the help of other maintainer of the concerned packages, if they agree) change that fact. 3/ Goal description === In the ideal world, a command like this: apt-get install postfix-mysql clamav clamav-daemon clamav-freshclam spamassassin tumgreyspf would create a mail toaster with postfix and all the above apps configured correctly so that the mail system would do like this: 1- postfix gets a mail, does some basic domain checkings (domain MX existance, etc.) 2- postfix asks tumgreyspf to check for SPF and greylisting 3- (see later) 4- postfix forwards the email to amavis 5- amavis does clamav and spamassassin checks with header tagging 6- amavis forwards the email to postfix 7- postfix sends the email to maildrop for delivery Let's say now that I add dkimproxy, I would do: apt-get install dkimproxy and then the sequence would become: 3- postfix sends the email to dkimproxy for DKIM signature checkings 4- dkimproxy forwards the email to amavis I don't see any reason why it shouldn't be as easy to use as what I wrote above. The complexity of this kind of setup MUST be done on our side, and not rely on the system administrator knowledge. The above is what we currently use, but of course, this could be extended to DSPAM (I read it's better than spamassassin), clamsmtp, some milter checks, some alternative MDA, etc. And of course, this could be extended as well to other mail servers (exim4 anyone?). That's for the problematic. Now, how to achieve this, I'm not sure how to do it yet, but I have couples of ideas. 4/ Few ideas, and what I believe should happen == First thing we could do, would be a special postfix package that would have the above packages as dependency. Let's say we call it postfix-toaster, and it would have the configuration already made so that it would be already configured for using other packages. But that's not really idealistic, because of so many possibilities that we have. The second idea would be to have some kind of triggers, a bit like we have for generating the mandb and others. The trigger would ask the MTA scripts to do the reconfiguration process, for example, giving it as argument a list of packages that it should use. But the MTA is not the only one to modify here, for example we might have to change the lis
Re: Let's write a system admin friendly mail server packaging system
Mario 'BitKoenig' Holbe wrote: > I'm installing apache2 and have a web server - more or less working, > I'm installing dhelp and ... magic, magic ... it extends the running > web-server to serve the dhelp content as well. I'm installing smb2www > and it extends the running web-server to act as smb client as well. > How do they do this? There is some conf.d directory which contains > config snippets for each of the packages. Yes, which feature I requested from the upstream of postfix. I got a stunning reply that it was a stupid idea, that it would be slow to parse, and that postconf wouldn't work anymore. So forget about having this in postfix, we must find another way. > Why would you like to go another way with mail servers? Because upstream doesn't want a conf.d folder, unfortunately, and that the issue is NOT ONLY with postfix, but with so many package that have to understand each other. Let me give an example. If you setup postfix + amavis, then postfix must relay emails to the incoming port of amavis, and amavis got to give the email back to postfix on another port. Both postfix and amavis have to be configured so they can talk to each other. Now, add dkimproxy in the loop. You have to configure dkimproxy to receive from postfix, relay to amavis, and amavis forwards to postfix. This is a LOT less trivial than what you pretend. > Get maintainer support for such conf.d directories, maybe get upstream > support for such conf.d mimics (sendmail most likely won't need it - > some m4 magic and triggers will just do it, dunno how it is for the less > flexible ones like postfix, exim, whatever), change the depending > packages to put their config snippets in there, everything is fine. > >> argument a list of packages that it should use. But the MTA is not the >> only one to modify here, for example we might have to change the listen >> and relay port of dkimproxy and amavis, depending if each others are >> present on the system or not. I am quite in the favor of this system, > > I don't think this is really necessary. It would probably be a bit more > efficient to have one component forwarding the stuff it processed to the > next one, but I'm sure there is a less efficient but more generic way to > just bounce it back to the MTA which continues forwarding it to the next > components. ... And who cares about efficiency in generic approaches. OF COURSE we do care about the performances of a mail server. Some ISP are running servers that are managing 100s of thousands of mail a day. But anyway, this was just an example, there's many use case where you must configure one of the elements of your mail server. Thomas -- 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/4bfd4522.4080...@goirand.fr
Re: Let's write a system admin friendly mail server packaging system
Ron Johnson wrote: > On 05/26/2010 11:42 AM, Michael Banck wrote: >> On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: >>> Mario 'BitKoenig' Holbe wrote: >>>> I'm installing apache2 and have a web server - more or less working, >>>> I'm installing dhelp and ... magic, magic ... it extends the running >>>> web-server to serve the dhelp content as well. I'm installing smb2www >>>> and it extends the running web-server to act as smb client as well. >>>> How do they do this? There is some conf.d directory which contains >>>> config snippets for each of the packages. >>> >>> Yes, which feature I requested from the upstream of postfix. I got a >>> stunning reply that it was a stupid idea, that it would be slow to >>> parse, and that postconf wouldn't work anymore. So forget about having >>> this in postfix, we must find another way. >> >> Eh, Debian can patch upstream software if it thinks it is necessary for >> inter-operation, that's the one of the major points of having a >> distribution. >> > > That would be some *serious* patching. > > Maybe, though, LaMont Jones (the Postfix DD) has a better relationship > with upstream and could convince them that conf.d is a good idea. I have to admit that I didn't insist so much, given the type of response I had when I asked. I also agree that it would be much better if upstream were happily accepting such patch, even if one of us is doing the job. I didn't really dive into the postfix code to know how hard it would be to add the feature, and I hope that LaMont Jones can talk about it. Anyway, postfix is NOT the only package that we shall consider modifying here. As per my original post, there's loads of other components that are to configure as well. The question is: is there a will to do this job by other maintainers. I am myself strongly motivated for this, but I wont be able to do it alone. Thomas -- 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/4bfd7686.4030...@goirand.fr
Re: Let's write a system admin friendly mail server packaging system
Mario 'BitKoenig' Holbe wrote: > So far this is independent of third packages which is IMHO fine and > desirable. So far, this could be solved by a postfix-conf.d-snippet > shipped with the amavis package. Quite not. You also need to configure the incoming and outgoing ports of amavis the correct way. > That's pain, indeed, and should IMHO be avoided at all. > A clean way to conf this would be > * postfix ships to amavis > * amavis ships back to postfix > * postfix ships to dkimproxy > * dkimproxy ships back to postfix > I don't know if this is possible with postfix yet. The sendmail milter > approach is way cleaner regarding such stuff. No, it's not any cleaner, and it's slower. As I wrote previously, we really don't want to have lower performances on a mail server if we want to do things seriously. And by the way, you wrote: postfix -> amavis -> dkimproxy -> postfix when what we really want to do is: postfix -> dkimproxy -> amavis -> postfix for obvious performance reasons. >> This is a LOT less trivial than what you pretend. > > That's not just less trivial, it's horrible :) > > And this is probably one of the reasons why newer amavis is now able to > perform DKIM signing on it's own. So, this specific chaining should be > historic sooner or later. I do not agree, for a very simple reason. Amavis is a dog, and you might want to remove it completely (depending on your setup/needs/mood). As much as I could see, each amavis instance is taking about 80MB of RAM! Back running sarge, it was a way smaller. I am quite stunned about the fact that, under Lenny, running amavis + clamav + spamassassin is taking about 6/700 MB of RAM when the server is idle. I quite don't understand what happened between Sarge and Lenny (or even, between Etch and Lenny). We used to run these 3 plus apache, mysql and others with just under 200MB of RAM + same amount of swap, on small footprint VMs. Currently, 512MB of RAM + same amount of swap is hardly enough. Also, running amavis is slow, very slow. So that's the one you want to run the last, after all other checks have been performed. To what I could see, dkimproxy performs very well. Others reported that it ran very well under such heavy load as 100k+ email a day (which is the type of traffic we always should keep in mind). > Do you have another example where such a chaining is unavoidable? Sure. clamsmtp for example. That makes 3 software that are used as SMTP proxies, and that could be chained. All of them would need dynamic configuration depending what is installed on the system. And this is only the one that I know/use. There must be more than this in the archive. The current situation in Debian, is that not even the default incoming and relaying ports are set correctly so the components can work together. This is quite a real mess. >> OF COURSE we do care about the performances of a mail server. Some ISP >> are running servers that are managing 100s of thousands of mail a day. > > And of course they use distribution-default configured mail servers for > that :) scnr. Are you trying to say that we shall ship a not performing configuration by default, because big ISP are capable of reconfiguring? If you are, sorry, I don't agree. I think we shall try to release the best distribution as we can, with correct, performing values by default, and even, if possible, have a default configuration that you never even need to edit, because it's just right by default. We should at least have this goal in mind, otherwise it slowly leads to an unusable default system, which is really not wanted here (and which I believe is the current state of many of the mail components in Debian, and that is the reason of my original post). Maybe I'm being too idealistic here. What's your opinion? Thomas -- 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/4bfeec27.1070...@goirand.fr
Re: Let's write a system admin friendly mail server packaging system
Mario 'BitKoenig' Holbe wrote: > Thomas Goirand wrote: >> Mario 'BitKoenig' Holbe wrote: >>> So far this is independent of third packages which is IMHO fine and >>> desirable. So far, this could be solved by a postfix-conf.d-snippet >>> shipped with the amavis package. >> Quite not. You also need to configure the incoming and outgoing ports of >> amavis the correct way. > > Which of course will also be done by the amavis package itself. Still, > no dependency on third packages so far. I think you quite don't get it. Here's 3 configuration: - postfix with dkimproxy - postfix with amavis - postfix with dkimproxy + amavis In these 3 cases, you have different configuration for the ports for both amavis, and the others. >>> * postfix ships to amavis >>> * amavis ships back to postfix >>> * postfix ships to dkimproxy >>> * dkimproxy ships back to postfix >> No, it's not any cleaner, and it's slower. As I wrote previously, we > > Cleaner from a dependency-perspective. Why isn't it? Cleaner for using it, of course not for the packaging. There's no reason why you should load postfix more, and have the message go 3 times by it, if it can go there only twice. > This way you are able to configure the whole integration within one > package (i.e. amavis ships the amavis-postfix integration, dkimproxy > ships the dkimproxy-postfix integration, etc. pp), you can just avoid > any complex chaining-magic. > > And slower? What are we talking about? Whole two percent? Well, both you and me are doing wild guesses here! We wouldn't be able to tell unless we bench it. But you must be right that the overhead wouldn't be so big, considering how much CPU amavis with spamassassin and clamav is taking. >> Are you trying to say that we shall ship a not performing configuration >> by default, because big ISP are capable of reconfiguring? If you are, > > I'm trying to say that I would prefer a straight, clean dependency- > minimizing approach over one that does and/or requires complex magic. > And I'm aware that clean approaches are usually somewhat less performant > than optimized setups, which, in turn, tend to be more complex. > > And I think that a clean and simple approach would help more users than > one that tries to squeeze the last cpu cycles out of your system for the > price of being hard to understand. > Don't get me wrong: I totally agree with you that what we have now is > neither the one nor the other. Cool. Then we agree! :) Just one remark (which doesn't invalidate your point): you named few percents of cpu cycle, but do not forget to also consider I/O here, as postfix will also use your HDD when managing its queue. I believe that the I/O wait is a bigger concern than any CPU load issue in this case. >> I think we shall try to release the best distribution as we can, with >> correct, performing values by default, and even, if possible, have a >> default configuration that you never even need to edit, because it's >> just right by default. We should at least have this goal in mind, > > "those goals" - you named three: correctness, performance and useful > defaults. Choose two of them :) Here, you are proposing to trade a little bit of performance, so that we have a correct, useful default, and with not too complex maintainer scripts. If we don't trade too much performance, then I don't mind. When having a server on the edge of collapsing because of the load, a bit more or less wont mater: you need a faster server and that is it. > I don't think it's bad to be idealistic. We just have different ideals > probably :) Well, most likely we just weigh conflicting goals different. In an ideal world, we wouldn't need such complex setup, as there wouldn't be any SPAM or viruses! :) Thomas -- 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/4c012711.60...@goirand.fr
Bug#584727: ITP: scim-googlepinyin -- Google Pinyin IM engine module for SCIM
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: scim-googlepinyin Version : 20100606 Upstream Author : Kov Chai * URL : http://code.google.com/p/scim-googlepinyin/ * License : Apache 2.0 Programming Lang: C Description : Google Pinyin IM engine module for SCIM Long description: SCIM (Smart Common Input Method) is an input method (IM) platform. scim-googlepinyin tries to bring the open source Google pinyin IME for Android to GNU/Linux. And customize it to fit the need on regular desktop instead of on mobile device by following Google Pinyin on Windows. This port is almost a line-by line translation from Java to C++. It's still under development. And it needs more testing and bug fixing for sure. Maintainer note: As the author describes his own work as being experimental, my intention is to first upload to experimental (makes sense, no?), until the author himself confirms that it works ok, and after my Chinese wife tests it for a long time in her Ubuntu laptop. For the few times I could test it, googlepinyin seems perfectly stable, but I still want to hear from the author and test it, before this package reaches SID or testing. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- 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/20100606032105.4160.2136.report...@buzzig.gplhost.com
Re: A lot of pending packages
Petter Reinholdtsen wrote: > My sponsoring preferences are available from > http://people.skolelinux.org/pere/debian-sponsoring.html >. To > make sure I have direct contact with the prospective package > maintainer and avoid a backlog of packages I should have sponsored, I > want to be contacted on IRC about sponsoring. So to me, > mentors.debian.net is a nice repository to find the source, and > uploading there is not the last step a future package maintainer need > to take to get her packages sponsored. > Hi, Before I write anything else: I only need to have my Debian accounts created and I'll be a DD. So, I am kind of seeing things with 2 different viewpoint at the same time: from my sponsoree and future DD. I got 2 suggestions to make about sponsoring. These are just raw ideas that I am sending, I'm not sure if they are good, but I just want to share what's in my mind. Feel free to comment and explain why I'm wrong. Maybe we could imagine a kind of survey that the sponsor would write, to tell how the new maintainer performed with his package, just right after it has been sponsored. That of course, be some added sponsor's work, but it could be kept small. My 2nd suggestion is coming from the Maemo platform (the OS behind the Nokia n900 that is Debian based). In Maemo, there is a "devel" repository that includes apps that aren't necessarily in good shape. The users know that fact when they are adding the repository which contains packages that are not necessarily as tested, and wont complain. I wonder if we could have such a repository in Debian, so that new maintainers would have their packages sent there. We would have to discuss what would be the rules to get from devel to SID. What I have in mind could be checks like: - the maintainer has been responsive for a period of time - the packages of the maintainer have been in good shape as well The issue really being the way the maintainer is reacting to issues, rather than the issues themselves. The advantage of this system would be that we wouldn't need so much check to have apps going to devel. We could even think about it as a big bazaar of ongoing work that would not need checks at all (apart of course, licensing, that would still need strong checks). This would prevent people from not being happy about sponsorship in SID. The devel repository could be said as NOT part of Debian, just like contrib and non-free. Now, combine the 2 ideas. If a (new) maintainer has X good sponsor surveys, then his package(s) would go from the devel repository to SID automatically (after a DD checks for it manually and agree on the decision), and he would gain the rights to have his packages go directly to SID when they get sponsored. Don't get me wrong, the idea is to have LESS checks on the sponsored packages, rather than too much, so that we would have a faster sponsoring process (new maintainers will be happy, sponsors too), while still maintaining intensive quality checks in SID / testing. Thomas -- 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/4c1160b7.5050...@goirand.fr
Re: [Pkg-xen-devel] [RESENT] Re: Xen for Squeeze, 3.4 or 4.0
Łukasz Oleś wrote: > 2010/6/10 Bastian Blank : >>> My personal preference would be to go with 4.0. > > I completely agree. Probably more people will use pvops kernel with > 4.0 instead 3.4, so hopefully it will be better tested. Hi Bastian, I have been running Xen 4.0.0 on my laptop since you made the Debian package, and there wasn't a single glitch (apart maybe the hibernate function which I don't really care about). Using an old version of Xen that already receives less attention from upstream isn't a bright idea. I believe that 4.0.1 will soon be released, which has many fixes. There's lots of new interesting features in 4.x too (like blktap2, which I believe you could re-add in the Debian package as the issue with OpenSSL was only the md5 thing, I suppose you saw it). My vote goes for 4.0.x. Thomas -- 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/4c117666.3090...@goirand.fr
Re: [RESENT] Re: Xen for Squeeze, 3.4 or 4.0
Russell Coker wrote: > Based on my experience with Xen I think that we should have both. Then if > one > doesn't work we can try the other. I don't think having to do a double work is a good idea. > My impression of Xen stability is that trying two different versions and > hoping that one will work is a good strategy for any given server. Do you also hang garlic on the server, to bring good luck? COME ON... this is computer science here, not voodoo! You should test things, see what works best, and go with it. If you see bugs, try to remove them. > Bastian, thanks a lot for all your great work on this, it's very important to > me and to lots of other people! I agree. > But through no fault of anyone in the Debian project I expect that an ideal > result of one version that works well for almost everyone can't be achieved. I don't agree (see above). Thomas -- 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/4c11d1f5.3010...@goirand.fr
Re: [RESENT] Re: Xen for Squeeze, 3.4 or 4.0
Russell Coker wrote: > Sometimes you test two options and find that for some systems one works well > and for other systems the other works well. Then if both options are > available you can get most (maybe all) systems working well, but if one > option > isn't available then some systems don't work well. Could you please report what option(s) in 4.0 isn't (aren't) working? Thomas -- 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/4c11e814.7040...@goirand.fr
Re: A lot of pending packages
Jordan Metzmeier wrote: > On 06/10/2010 06:01 PM, Thomas Goirand wrote: >> Petter Reinholdtsen wrote: >> My 2nd suggestion is coming from the Maemo platform (the OS behind >> the Nokia n900 that is Debian based). In Maemo, there is a "devel" >> repository that includes apps that aren't necessarily in good shape. The >> users know that fact when they are adding the repository which contains >> packages that are not necessarily as tested, and wont complain. > > > Isn't this already called experimental? If not, how would it differ? Right, I was being silly. Also, the word "experimental" adds more fear to the user than just "devel", which is good. Let me rephrase then. How about we accept MORE packages with LESS checks in Experimental, and have new maintainers forced in that repository, then if they are seen as responsive, we upload to SID? Could that be a sponsor's decision already right now, and be considered a good practice? Thomas -- 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/4c11ebc...@goirand.fr
Re: Bug#535830: ITP: php-recaptcha -- reCAPTCHA is a free CAPTCHA service
Angel Abad (Ikusnet SLL) wrote: > Package: wnpp > Severity: wishlist > Owner: "Angel Abad (Ikusnet SLL)" > > > * Package name: php-recaptcha > Version : 1.10 > Upstream Author : reCAPTCHA -- http://recaptcha.net > * URL : http://recaptcha.net > * License : MIT > Programming Lang: Php > Description : reCAPTCHA is a free CAPTCHA service > > A CAPTCHA is a program that can tell whether its user is a human or a > computer. You've probably seen them colorful images with distorted > text at the bottom of Web registration forms. CAPTCHAs are used by > many websites to prevent abuse from "bots," or automated programs > usually written to generate spam. No computer program can read > distorted text as well as humans can, so bots cannot navigate sites > protected by CAPTCHAs. > . > This package contains the php recaptcha library. Hi, I wrote it to the pkg-php list, but I want to write it to -devel as well, to have the opinions of others. I don't think packaging something working with a foreign website that provides a functionality that the user is supposed to run on its own website is compatible with the freeness of Debian, and matches the DFSG and social contract. Clearly, something like recaptcha, we don't own it, and we wont ever have the source code that they use. This is more than closed than a closed source app: we don't even have the binary for it, we only rely on the service of a website, that may well one day be gone (who knows?). This type of software doesn't pass any of the Debian freeness tests (desert island, dissident, tentacles of evil). I wouldn't mind if there was no alternative. I wouldn't mind also if such a functionality couldn't be made by ourself, standalone. Facts are: we don't need at all the recaptcha.net site to display Turring tests images and there ARE some alternatives available (well, at least one for this php module as you can see below, and there must be some more on the wild (eg: hidden in the deepness of internet)). I knew about recaptcha, I know it does things better than the modules that I describe below, but still, the non-freeness (in the Debian spirit) of recaptcha pushed me to fill the following ITPs: - php-image-text - php-numbers-words - php-text-figlet - php-text-psasword - php-text-captcha There are all available from here: http://ftparchive.gplhost.com/debian/pool/lenny/main/p/ I will upload them in Debian as soon as I have my Debian accounts created (as I found nobody willing to spend some time to do sponsoring, and that anyway I believe it wont take must time until I get my Debian Developer accounts ready since it's been 3 weeks my DAM approved me). The last of the above packages needs the other above 4 other php packages as dependencies. This solution is a lot more free than php-recaptcha, IMHO. I think that the best way would be to convince the authors of CiviCRM to use php-text-captcha instead of recaptcha, at least as an alternative solution. In short: anyway you put it, I don't like the idea of adding php-recaptcha in the archive, because I don't think it's really free. Am I the only person thinking this way? Thomas -- 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/4c1cd758.4010...@goirand.fr
Re: ITP: php-recaptcha -- PHP interface to recaptcha.net
Hi Mark, and thanks for your quick reply, Mark A. Hershberger wrote: > Thomas Goirand writes: > > These captchas are different than just generic captchas, though: > > reCAPTCHA is a free CAPTCHA service that helps to digitize books, > newspapers and old time radio shows. Check out our paper in Science > about it <http://recaptcha.net/reCAPTCHA_Science.pdf> > … > Currently, we are helping to digitize old editions of the New York > Times. And why should we care about this? How does this changes the freeness of php-recaptcha in the therms of my reasoning? The following paragraph has nothing to do with what I wrote, but I just have few things in mind I'd like to share, as it might help you to understand what I have in mind. It's not said in what you quoted what they will do with the digitized documents, I doubt they would give it back to the people giving their time to help this work, or give it for free to anyone. Does recaptcha.net represent an association, or a foundation, with clearly established goal, and freeness in mind? You and I have no clue of this. And by the way, The New York Times, last time I checked, is owned by its shareholders: it's a commercial entity. And to just make it 100% clear, so we close the recaptcha.net website goal topic: this is absolutely NOT related to what I said. They could do whatever they like with the digitized work, in fact, they would still own recaptcha.net and be able to do whatever change they want to the therms of service and make it a service you'd have to pay for, or even close it altogether if they feel like it, or even [paste whatever non-free issue you like here], and you'd have no power to influence any of this kind of decision (and neither would anyone at Debian). Please read point 9 of this document: http://people.debian.org/~bap/dfsg-faq.html Because we don't have the source code of the captcha system itself (you only have access to the source code of something that accesses the online service), php-recaptcha fails all of the 3 tests when we want to use it, which is a good indication that it shouldn't be considered free. > Additionally, this is part of the dependencies for CiviCRM: I have no doubts that CiviCRM must be very good, free and all. But this must NOT influence Debian's view on the freeness of one of its dependencies. A software is as free as its least free dependency, which is why we have the contrib repository. As I see it, php-recaptcha should be sent to non-free (which means anything depending on it would go in contrib). I'd be happy to see others expressing themselves here, in order to make sure I don't hold an extreme view on this. > I'm in the process of packaging CiviCRM for Debian. Which is a great idea, thank you for this work/intention, but is unrelated to my point. > I don't see a problem with providing access to reCAPTCHA for those who > want to help the Carnegie Mellon project as long as other CAPTCHA > modules are available. Please respond to my specific points about the freeness, and stay on topic, otherwise the discussion will loop and we are all loosing time. For the moment, the issue is php-recaptcha, not whoever depends on it. If at the end I was right that php-recaptcha was non-free, you should make it so that CiviCRM doesn't REQUIRES php-recaptcha, if you feel like it set php-recaptcha as a Suggest: (and not a Depends:), make it so php-recaptcha is uploaded to non-free, have other modules of CiviCRM be activated by default, and everyone is happy. Thomas -- 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/4c1d6994.6050...@goirand.fr
Re: [php-maint] ITP: php-recaptcha -- PHP interface to recaptcha.net
Hi Ansgar, and thanks for letting us know what you believe. Ansgar Burchardt wrote: > Thomas Goirand writes: > >> Please read point 9 of this document: >> >> http://people.debian.org/~bap/dfsg-faq.html >> >> Because we don't have the source code of the captcha system itself (you >> only have access to the source code of something that accesses the >> online service), php-recaptcha fails all of the 3 tests when we want to >> use it, which is a good indication that it shouldn't be considered >> free. > > Those tests are intended to be check the license of a software for > DFSG-freeness. php-recaptcha's license (MIT license) passes all these. Let's read again the DFSG faq: "The process involves human judgement. The DFSG is an attempt to articulate our criteria. But the DFSG is not a contract. This means that if you think you've found a loophole in the DFSG then you don't quite understand how this works. The DFSG is a potentially imperfect attempt to express what free software means to Debian. It is not something whose letter we argue about. It is not a law. Rather, it is a set of guidelines." My (human) judgement is that to use php-recaptcha, you need to use a web service that executes a remote procedure, that you normally wouldn't need. You are in fact using a bit of software that you don't even have a binary for. To me, it's worse than even the license of the said software. If you want to strictly focus on the license of the software using the service, fine, but I don't think it should be the case, as any software is only as free as its most non-free dependency. This is exactly why we have the contrib archive, which is said to not be a part of the official Debian distribution. >> As I see it, php-recaptcha should be sent to non-free (which means >> anything depending on it would go in contrib). I'd be happy to see >> others expressing themselves here, in order to make sure I don't hold an >> extreme view on this. > > The DFSG does *not* require that network services that are accessed are > available under a free license (or that the server software must even be > included in Debian as well). There are only requirements on the > software that Debian distributes itself. As I just quoted, "the DFSG is a potentially imperfect attempt to express what free software means to Debian". I believe we are in front of one of the loop-holes described in the DFSG faq here, and that our human judgment should have precedence over the word-by-word reading. > If you do think otherwise, please explain how software licensed under > one one the licenses explicitly listed as "free" in the DFSG can > suddenly become non-free. Which point of the DFSG is no longer > fulfilled? Ok, I revise what I said, and now that I have thought about it for a longer time, I'll express myself with stronger words: php-recaptcha MUST go to contrib, as it is using a remote procedure that is not free (even if php-recaptcha itself is free). I think it makes a lot more sense written this way, right? :) If you don't agree with this judgment, please explain with a strong argumentation, why you think having a remotely executed procedure (here, the captcha image generation) is different from any other non-free software bit (like for example an non-free library). To me it's even worse, as things in contrib are depending on non-free softwares that we store in the non-free archive. Here it wont even be the case as we don't have the source code for creating the pictures. > Compare with the various clients for proprietary instant messengers, > YouTube, other Google services, ...: The server software is not > available for any of these either. IMHO, this is irrelevant: let me explain my thoughts. You are comparing things that should not be compared. But even if you really want to, it's still not valid. An instant messenger's goal is to communicate with others. A youtube client's goal is to grab things on the internet (just like a web browser would). NEVER any of these 2 types of clients have a part of their code located on a server. Even though they connect to a server and exchange information, there's no remotely executed procedures here. The above software USE a service, yes, but this is because these services are obviously useless if they aren't online. The purpose of these clients are to get connected, and interact with the network. Removing the internet connection makes these kind of software quite useless. Now, with php-recaptcha, the problem is totally different. A part of the php-recaptcha software is hosted by a private entity, when there is no real valid reason why it should. Remove the internet connection, and you still might need a software that generates captchas. And a
Re: [php-maint] ITP: php-recaptcha -- PHP interface to recaptcha.net
Philipp Kern wrote: > On 2010-06-20, Ansgar Burchardt wrote: >>> As I see it, php-recaptcha should be sent to non-free (which means >>> anything depending on it would go in contrib). I'd be happy to see >>> others expressing themselves here, in order to make sure I don't hold an >>> extreme view on this. > [...] >> Compare with the various clients for proprietary instant messengers, >> YouTube, other Google services, ...: The server software is not >> available for any of these either. > > And clients like lastfm in main. We never had the requirement that the > web service must be free. Of course it would be cool if it would be, > but it's no reason for the package to go into non-free. Please read my response to Ansgar, I don't think this is a valid argument, and I believe this is totally irrelevant here, because you are talking about some network CLIENTS, when php-recaptcha is using a REMOTE PROCEDURE when it doesn't really need one (huge difference). I now believe php-recaptcha is a valid candidate for contrib, and not the non-free repo, because the MIT license itself is perfectly valid for Debian, but it is using an picture generation library hosted remotely for which we don't even have a binary to play with. Thomas P.S: Big letters are EMPHASIS only here, I'm a nice guy and I do not intend to SHOUT in these lists! :) -- 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/4c1dda12.2040...@goirand.fr
Re: ITP: php-recaptcha -- PHP interface to recaptcha.net
Marco d'Itri wrote: > It is another long-standing Debian tradition to tell non-developers to > STFU when they try to change the meaning of the DFSG. IMHO, this is not my case, read further. > You can find the details in the last 6 years of the debian-legal@ > archive... If you have mind reading the link that Zack took time to send you, you might have noticed that I have been approved by my DAM, and that I am just waiting for my account creations. But that's not the point. Like Yves-Alexis Perez, I can't help myself to write that I believe you have been quite rude when writing this: > You are not even a Debian developer so please refrain from trying to > re-interpret the DFSG to suite your opinions. I have tried to be as open minded as possible, and asking opinions of others, and I don't think I am re-interpreting the DFSG here. IMHO, the debate is all about how to consider the recaptcha service (eg: a service you connect to, or a remote procedure). I don't think this has anything to do with being a DD or not: users, maintainers and so on also have concerns about freeness, and I strongly believe that this kind of debate shall be open to anyone. Because I took the time to package php-text-captcha, which has been ready for MONTHS, it might also give me a bit more of legitimacy to comment about a PHP module that I refused to work with, because I considered that there was a more free alternative. Have you done such a work to consider what php captcha module should be in Debian? Some made the comparison (like you just did) with IM clients, specific browsers (like youtube clients and others), but I don't believe this applies here. To my opinion, I believe this is a remotely executed procedure, stored on a non-free server that we wont ever control, which makes php-recaptcha a good candidate for contrib. This is a lot more complex debate than what you pretend. The link you have past is just someone expressing his opinion, with sentences starting by "I think". Where exactly did you see that was written in the stone of the DFSG? Also, if I am not mistaking, this discussion is talking about an ICQ client. I already express myself, writing that I don't think this matches the case of php-recaptcha. We are talking about a remote procedure on a software, that has no valid reason to be used as a service, and not embedded on the server that you use. If you believe that there's a valid reason, I welcome you to express yourself about it. Thomas P.S: This is unrelated to the license of the software itself, and to the discussion that has to be technical and about principles we enforce in Debian, but recaptcha.net is using the user's input to digitize content, without being very clear about how this "free work" is being used. Truth is, it's quite obvious that Google is using it for it's online library that it will never share with others. I believe this is evilness, and I am against it. I also don't like at all the way Google managed to dismiss copyrights of many authors, injunctions from many governments, pretending to be above many laws, and so on. Recaptcha is yet-another-tool for this evilness. Having something like a "free as free beer" API, a "free as free speech" software to use the API, but keeping the digitized work for themselves, and keeping the server side code closed, is yet another trap that I *strongly refuse* to dive into. If Debian is not the entity to refuse/complain about it, then who will? Do we really care about software freeness? I hope we (as an entity) still do, and I *know* many of us still do. -- 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/4c1e1c0b.5060...@goirand.fr
Re: ITP: php-recaptcha -- PHP interface to recaptcha.net
Tollef Fog Heen wrote: > | Some made the comparison (like you just did) with IM clients, specific > | browsers (like youtube clients and others), but I don't believe this > | applies here. To my opinion, I believe this is a remotely executed > | procedure, stored on a non-free server that we wont ever control, which > | makes php-recaptcha a good candidate for contrib. This is a lot more > | complex debate than what you pretend. > > I don't see how that is fundamentally different from, say, youtube-dl. Server-to-server connectivity isn't part of the software functionality, removing it would enhance the software, and that is the fundamental difference to me. More in details if anyone didn't get it in a short version: remove any kind of connectivity to the youtube servers, and youtube-dl has no use, you can uninstall it from your system. Do the same with something that does a captcha, then it's great if it continues to work without connectivity. In fact, for a captcha software, it's *more convenient* if it doesn't connect to a specific privately owned captcha server at all, so that way you can run it in a LAN / DMZ. The connection to a server that holds a part of the code that you will never have access to, is only removing some freedom, it's not adding any functionality. > | We are talking about a remote procedure on a software, that has no > | valid reason to be used as a service, and not embedded on the server > | that you use. If you believe that there's a valid reason, I welcome > | you to express yourself about it. > > The valid reason is making those text where the captchas come from be > more accessible. I'm not 100% sure of what you are saying here, but I'll try to answer anyway (please be indulgent if I didn't understand you correctly). So here, you are discussing about the quality of the captchas, right? Not about my argumentation about recaptcha being a remote procedures / function / method (take your pick) that should, to me, live on your local server? If that is the case, then aren't you a bit off-topic, or am I missing something important? If your point is about the text that Google is digitizing thanks to recaptcha, that's off-topic IMHO. If it wasn't off-topic, then I'd say it's adding some evil, as Google has been quite bad with many book editors and copyright infringement (which I already wrote btw). > | If Debian is not the entity to refuse/complain about it, then who will? > | Do we really care about software freeness? I hope we (as an entity) > | still do, and I *know* many of us still do. > > Part of software freedom is the no discrimination against fields of > endeavour bit. Which is exactly why this was a "P.S" and not in the body of my message. This is a side note only, and should be considered as such, eg: no implication on the rest of my freeness reasoning, this was just a reminder for people not knowing who we are talking about here. This is also a hidden message saying that rather than spending time packaging and supporting Google tools they use to own us all (like php-recaptcha), we'd better focus on 100% free existing tools and enhance them (like php-text-captcha) so they become even better than the non-free counterpart. Neil Williams wrote: > IMHO if this package is to enter Debian at all, it should be in > contrib as it relies on a non-free component to operate (so non-free > that the component cannot even be packaged for Debian). This is exactly what I believe, and what I wrote as being my 2nd thought: to me, it should go to contrib, and not to non-free, as it depends on a remote execution by a library we don't even have a binary for. Neil Williams wrote: > Remote procedures alone are not sufficient reason to consider a > package using the procedure as non-free - e.g. blog clients use > a variety of blog engines, some of which are non-free. I want to insist here: the captcha generation is a remote procedure / method / function, absolutely NOT a a service like youtube or instant messaging, or even (micro-) blogging. Not understanding this point is not understanding why I am arguing against php-recaptcha to enter Debian main. Discussing on another point is, IMHO, a bit off-topic (which I don't mind so much... :) ). > Blog clients rely on remotely executed procedures. All blog > engines are *stored* on a non-free server because servers > themselves (as machines) are always non-free if they hope to > be secure. ;-) I think what you > meant is connecting to a non-free *service* and there are a lot of > those which do not preclude packages using them being in main. No, it's not like a blog client. In fact, I'd be happy if everyone could understand that there's no client/server thing here. Google is only giving you access to a function. That function could run on your local server, totally disconnected from internet, but the recaptcha system forces you to use a remote code that you don't have access to. > The difference here is that this procedure is server-to-se
Re: ITP: php-recaptcha -- PHP interface to recaptcha.net
Tollef Fog Heen wrote: > By this reasoning, we should move IM any IM clients that only talk to > proprietary servers (MSN, ICQ, etc) to contrib as well. Is that your > intention? Not at all, I never wrote this, I quite wrote the opposite in fact. > Even if we accept the premise that it's a RPC call, you have not > explained why an RPC call done by php-recaptcha is fundamentally > different from an IM client talking to a proprietary server. I believe I quite did. IM clients need to tell the server to perform actions of many kinds, because they are communicating. A captcha app doesn't, in fact it should not communicate at all, and just compute a picture. Here, we are adding an RPC call for no valid reason. > Why are (or should) remote, non-free data repositories (youtube) > fundamentally different from remote, non-free data generation services > (recaptcha)? We are *not* talking about retrieval of a specific data or content that you would like to let's say store on your local computer. Storing a captcha on your hard drive is of no use (as a well designed captcha system will expire with time). You can replace one captcha picture by another picture of the same kind, and the functionality is the same. Here, we are talking about a turing test and its associated data (here an image) generated by a function that needs computation, which is done remotely. I wrote: "Server-to-server connectivity isn't part of the software functionality, removing it would enhance the software, and that is the fundamental difference to me." > | Nobody has yet convinced me here. If there was no more argumentation, > | but the decision was still to accept software with remotely accessed > | library dependencies, that would be a serious breach in my trust for > | Debian staying 100% free. > > I'm not aware of us ever having made a statement that no software in > Debian depends on third-party services, be they non-free or not. No, but we wrote that a free software in our view, should not depend on a non-free software. The question is: is this an RPC call to a remote (non-free) library. My take is: definitively yes. As we are clearly on the line here, so I do respect other's opinion, but I thought it was a worth topic. Anyway, I think I have made my point, and it would be useless (and boring for everyone) to write more on this. Thomas -- 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/4c1ef2b5.7050...@goirand.fr
Bug#590135: ITP: php-text-diff -- Engine for performing and rendering text diffs
Package: wnpp Severity: wishlist Owner: Thomas Goirand Package name: php-text-diff Version : 1.1.1 Upstream Author : Geoffrey T. Dairiki URL : http://pear.php.net/package/Text_Diff License : LGPL Programming Lang: PHP Description : Engine for performing and rendering text diffs This PEAR class provides a text-based diff engine and renderers for multiple diff output formats: in classic context diff, inline, or the more commonly used unified format. This is a new dependency of eXtplorer that I have already uploaded to SID, so I wish to package this in order to upload the new version of eXtplorer and ExtJS. -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- 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/20100724032111.19490.10813.report...@buzzig.gplhost.com
Re: doc-base is hugely unloved; bug mass-filing needed?
Ian Zimmerman wrote: > After years and years of waiting for packages to register their > documents with doc-base, and filing individual bugs with some (not all > -- I am not jidani, LOL) of those that didn't register, I am quite > frustrated. Maybe if things were more automated and less painful, there would be more packages that would be registered using doc-base. Maybe I have missed some Debian tools to do it, or I am going to say stupidity about docbase itself (that I don't know more than what I read on how to support it on my own package, without really know what it is for). If that's the case, let me know (and don't start a flaming / trolling). But as it stands, each time I run lintian with the -Ii flags, and that it complains about the lack of doc-base registration, I feel like it should have been more easy to deal with. I try to be a good Debian citizen, so I still do it. But if we had only something like this: dh_docbase /usr/share/doc/$PKG/html/index.html \ -t "My package title" -f HTML and nothing more. Then I believe it would be a lot more attractive to everyone, and think that maybe, other DDs would not mind so much if the lack of docbase registration done this very easy way was producing a lintian error (and not just a warning when lintian is in verbose mode). I don't really see the point in having to write an Abstract, a Title, and a Section, when all of these are already available in debian/control, and most of the time, that's enough. I know already what people are going to reply here: "what if the doc addresses something different than the package description talks about?" Well, then make it possible to be overridden, possibly doing the exact same way it's done currently, but don't force people to write twice the same things in many case, do more automation, and you'll get more love in return. Just my 2 cents hoping that it will help, Thomas -- 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/4c5efc3b.6090...@debian.org
eXtplorer web file manager packaging work and SWFUpload packaging
interesting for them, like the full of the GPL license ... :) HTML5: this is really the best option. Unfortunately, currently only Firefox 3.6 supports it. If you can predict if people from Redmond will upgrade IE to support it, then please send me your crystal ball: I also would like to predict the future. As it stands, nobody can tell what will be the adoption rate for this feature. And even, there's sill users with the older browsers. Ol on #debian-devel nicely gave me this URL, which is a good example of what's going to be possible in the near future with some browsers (and right now with Firefox 3.6 Alpha 1): http://www.thecssninja.com/javascript/drag-and-drop-upload Flash: this is (I'd say: unfortunately considering the security record of this famous browser plugin) what I feel is the best solution. Flash is installed in nearly all browsers, it is working *now* and not sometimes later on, and on all browsers. Many big sites are using this method, including youtube itself (AFAIK). There's no need to sign a piece of binary either, and there's the SWFUpload library that is released under the MIT license, is fully free. It's available here: http://code.google.com/p/swfupload/ Note: the old swfupload.org seems to not be the home of this project anymore (weird that they are moving away from their own domain, if you ask me). How to fix the SWFUpload issue: - --- The SWFUpload is a client side file upload tool that uses a combination of Flash and Javascript to provide upload functionality beyond what the basic browser provides with the tag. It is shipped with the source files of the action script source code that are needed. But the issue here is that we need to build it using the tools available in Debian only. As of today, the only action script compiler that I am aware of is the "mtasc" one, that pabs packaged. Now, my problem is simple: I don't know anything about Flash, mtasc (that pabs maintain) or others, and I need help to do this packaging. As I don't know Flash, I don't think it's a good idea that I become the official maintainer of the package once it is in main. I know I could have just sent a request for packaging, but if I don't give the explanations that are going with it, and don't advertise, nobody will help. This would be a very small package and I believe it will be fast to write it. So, help anyone? Thomas Goirand (zigo) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkxga+wACgkQl4M9yZjvmklUlQCfdfS7v66iHgejFy2QMbRriAk9 2tMAn1LdMv6E1TCOmpRyE28MrEsgu4mE =shAd -END PGP SIGNATURE- -- 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/4c606bf8.7080...@debian.org
Bug#596229: ITP: lazyscripts -- A stupid scripts management tool and non official package installer
Package: wnpp Severity: wishlist Owner: Billy Zhe-Wei Lin 林哲瑋 * Package name: lazyscripts Version : 0.2.3.7 Upstream Author : Billy Zhe-Wei Lin, 林哲瑋 (billy3321, 雨蒼) * URL : http://www.lazyscripts.org * License : GPL-2 Programming Lang: Python, bash Description : A stupid scripts management tool and non official package installer Lazyscripts is just a stupid script distrubtion tool and quick-installer in Linux, which aims to provide a easy way to setup your working environment for people who need to install a new distrubution such as Debian, Ubuntu, openSUSE or who want to have much better experiences in Linux. -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- 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/20100909124239.6469.19928.report...@buzzig.gplhost.com
Re: Rapidly evolving end-user apps (Was: chromium not in Squeeze: a bit of communication needed?)
Stefano Zacchiroli wrote: > PS regarding the other part of this thread about how to support, via >backports, what I would call "rapidly evolving end-user apps", it is >surely a worthwhile discussion, more general than Chromium. I believe >it would be worth to have it elsewhere (e.g. -devel), possibly once >the needed feature requests (e.g. on APT) have been implemented. Note >that unless there is a chance to get those features into Squeeze, >it's probably a too-late-coming discussion. I'm jumping in. I was quite surprised to see that the proposed solution was to put Chromium in backports rather than in volatile. I don't really mind, as long as it's supported somehow, but then, what's the point of volatile? Also, I have found that Pidgin would really have been a valid candidate for volatile: after few months, Yahoo, MSN and other networks are changing, and it becomes simply impossible to log into these networks unless you upgrade Pidgin (or some of its protocol purple libs) to a higher upstream version. Wouldn't it make sense to have Desktop apps like these (I suppose there are other examples, like maybe the flashplugin-installer package in non-free) sit in volatile? Just my 2 cents idea, Thomas DISCLAIMER: I'm not willing to work on Desktop applications, this isn't my field, I have enough work on server packages. -- 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/4c891a7d.5010...@debian.org
Re: Bug#596229: ITP: lazyscripts -- A stupid scripts management tool and non official package installer
Hi there, Jon Dowland wrote: > Are you the upstream author? Are Thomas Goirand and Billy Zhe-Wei > Lin the same person? I was at the "Hacking Thursday" of the "Shanghai Linux User Group", and I was trying to show "Billy Zhe-Wei", a Taiwanese living in Shanghai, how he could package his application in Debian, and why he needed to fill an ITP. Unfortunately, his laptop couldn't connect to the WiFi there (for a weird reason that we didn't find out). So I used the "--email=" of reportbug on my laptop, but as I have set DEBFULLNAME in my environment, and I dind't use --realname=, so my name went in, instead of his. That's just a mistake I did, which I didn't see, because in the editor, you have the Owner: field that is correct (see the deceptive text below). > Are you the upstream author? Billy Zhe-Wei Lin 林哲瑋 is the upstream author. Jon Dowland wrote: > On Thu, Sep 09, 2010 at 08:42:39PM +0800, Thomas Goirand wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Billy Zhe-Wei Lin 林哲瑋 >> >> * Package name: lazyscripts >> Version : 0.2.3.7 >> Upstream Author : Billy Zhe-Wei Lin, 林哲瑋 (billy3321, 雨蒼) >> >> * URL : http://www.lazyscripts.org >> * License : GPL-2 >> Programming Lang: Python, bash >> Description : A stupid scripts management tool and non official >> package installer >> >> Lazyscripts is just a stupid script distrubtion tool and quick-installer > distribution >> in Linux, which aims to provide a easy way to setup your working >> environment for people who need to install a new distrubution such as >distribution >> Debian, Ubuntu, openSUSE or who want to have much better experiences in >> Linux. > > Apart from the spelling errors, reading this description I still have no firm > idea of what this package does. This is exactly what I told Zhe-Wei tonight when reading his short description. When I first saw his python GUI, I thought it was a replacement for the "Ubuntu software center" in a way faster. It seems I was wrong, but I discovered it after sending the ITP with him. What his package does is things like downloading unofficial packages at once with wget, and some dpkg -i of the .deb. He showed me some examples with some fonts packages. Now that I understand this, I think it's a bit silly, as packages should go in Debian directly, and we have dependencies if we wish to pull more than one package at a time. It could still be cool for non-free stuff though. And I think that his tool can do a lot more (it does a lot of scripting). Note that this is just a kind mentoring process, as Zhe-Wei is really willing to learn. So please do not care too much about this. :) Thomas Goirand (zigo) -- 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/4c891ff5.7070...@debian.org
Re: Debian Installer 6.0 Beta1 release
On 10/31/2010 03:00 AM, Otavio Salvador wrote: > The Debian Installer team[1] is pleased to announce the first beta > release of the installer for Debian GNU/Linux Squeeze. Great, thanks for the huge work. I was wondering if there will be WPA support in D-I for squeeze, as this was quite frustrating in Lenny to have to plug a wire (no way I'll use WEP anywhere considering it takes 5 minutes to crack with the proper tools... (like those in Linux backtrack 4)). Maybe I missed discussions about it, if so, sorry. Thomas -- 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/4ccea4b9.7090...@debian.org
Re: Debian Installer 6.0 Beta1 release (WPA support)
On 11/03/2010 01:57 PM, Christian PERRIER wrote: > then, a few > months before the release, we start getting suggestions to add this or > that fancy new thingy Do you consider that WPA support is a "fancy new thing" ??? With all due respect, I believe that my favorite distribution not having support for such an old technology would be quite lame. That's the kind of things that makes people go the Ubuntu way or more generally think that Debian is not adapted for their desktop use (and in that case, I would agree...). That being said, I do understand the need for testing, the fact that it should have been tested a long ago, etc. We're all at fault here. It's been a long time that I want to participate to the devel of D-I, I hope I will be able for Wheezy. Whatever path will be taken (hide the functionality in the expert mode, or have an unofficial ISO), as long as it's there, I think it's fine. I sincerely hope a solution will be found, Thomas -- 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/4cd3df6c.3020...@debian.org
Re: Debian Installer 6.0 Beta1 release (WPA support)
On 11/06/2010 06:03 PM, Philipp Kern wrote: > Whining on a mailinglist isn't overly helpful. I agree 100%. But my purpose wasn't at all to be whining, just to express my sadness about this missing feature. Sorry if you took it the wrong way. I also expressed my regret to not have enough time to work on it myself (I'm currently trying to get this patch to work though...). Thomas -- 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/4cd63699.4000...@debian.org
