Re: what about Netplan?
On Jul 15, 2024 10:48 PM, Luca Boccassi wrote: > and without being tied to > the internal decisions made in Canonical that we cannot do anything to > influence. Could you please stop this FUD campaign ? We aren't talking about MIR or Unity, but about a small tool to generate some configuration. It is NOT the same, as we could fork such a small(er) tool. Plus we DO have some influence (look when we decided to switch to systemd, Canonical followed... because they wanted to follow, whatever our decision!). Cheers, Thomas Goirand (zigo)
Re: what about Netplan?
On Jul 16, 2024 4:55 PM, Lukas Märdian wrote: > Netplan is integrated with [cloud-init] "v2" network configuration and the > "cloud-config" > is adopted by many major public cloud providers (AWS, GCE, Azure, ...) as a > deployment > method, which makes it a well-known format. Similarly default configuration > for > [debian-cloud] is provided via Netplan. It is already supported in > [Calamares] for our > live-images and as of recently landed in [debian-installer] as well. It'd be very nice if it could also support a bgp-to-the-host setup natively as well. Maybe I can catch you in Busan to explain that use case? Cheers, Thomas Goirand (zigo)
Re: Validating tarballs against git repositories
On Aug 27, 2024 12:07 PM, Jeremy Stanley wrote: > > On 2024-08-26 21:28:38 -0700 (-0700), Otto Kekäläinen wrote: > > On Tue, 2 Apr 2024 at 17:19, Jeremy Stanley wrote: > > > On 2024-04-02 16:44:54 -0700 (-0700), Russ Allbery wrote: > > > [...] > > > > I think a shallow clone of depth 1 is sufficient, although that's not > > > > sufficient to get the correct version number from Git in all cases. > > > [...] > > > > > > Some tools (python3-reno, for example) want to inspect the commits > > > and historical tags on branches, in order to do things like > > > assembling release notes documents. I don't know if any reno-using > > > projects packaged in Debian get release notes included, but if they > > > do then shallow clones would break that process. The python3-pbr > > > > You could use --depth=99 perhaps? > > > > Usually the difference of having depth=1 or 99 isn't that big unless > > there was a recent large refactoring. Git repositories that are very > > big (e.g. LibreOffice, MariaDB) have hundreds of thousands of commits, > > and by doing a depth=99 clone you avoid 99.995% of the history, and in > > projects where changelog/release notes is based on git commits, then > > 99 commits is probably enough. > [...] > > Maybe, but only if you want authorship, release note or changelog > generation truncated at 99 commits worth of information at build > time. Take OpenStack Nova for example, which has historically > averaged around a thousand non-merge commits between major releases > every 6 months; --depth=99 would be an order of magnitude too low to > find just one major release's worth of notes and tags on a stable > branch. > > Granted, this is why upstream in OpenStack we recommend package > maintainers use our source distribution changelogs rather than > rebuilding source themselves from code from version control. Our > community considers our version control to be an implementation > detail of our development workflow, not the primary means of > supplying source code to downstream consumers. Where version control > is concerned, we consider our source code to include the full Git > metadata and not merely the files held in the worktree. For a > hassle-free source distribution, we extract that metadata and > incorporate the relevant parts as files in our signed source > tarballs. > -- > Jeremy Stanley 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. Thomas Goirand (zigo)
Re: testing "testing" (was: Implementing "testing")
Ola <[EMAIL PROTECTED]> wrote "The big problem is as I see it, to implement it. I'm not familiar with the background work that the server do so I'm not the right person ot do it, I think. Are you willing to implement such a system?" I will try some experimentation on a local system, and see if I can get a proof of concept project running. I'm fairly sure that I'm "not the right person to do it" as well, but at worst I'll have just wasted some hours finding that out... Tom M. LetterRip [EMAIL PROTECTED] (Sorry for the delayed reply, although I subscribed to debian-devel, I'm apparently not getting any mail from it...)
Re: [Summary]: Another take on package relationship substvars
Sent from Workspace ONE Boxer On Mar 25, 2024 7:44 AM, Niels Thykier wrote: > > Niels Thykier: > A follow up on this: > > * The proposal is now implemented in debhelper compat 14 (as of version > 13.15+) and debputy (0.1.21+). > > * The `debputy` migration tool will flag any obsolete substvars that > are 1:1 with what `debputy` would have applied for you. No tool for > debhelper-based packages exist at this time. > > * Lintian is not updated yet and will still complain about missing > relationship substvars. I have filed #1067653 to have that changed. > > I expect this to be final on this topic for this round. :) > > Best regards, > Niels Hi Niels, Thanks a lot for your work on this, I very much agreed with the premiss that subst vars were a thing easy to fall into traps. It is a very welcomed improvement to automate them and avoid mistakes. Is there a place where you wrote some kind of doc about how to use debputy or debhelper compat 14? Does one need to add debputy as build-depends, and that is it? Pointers to URLs welcome. Cheers, Thomas Goirand (zigo)
Re: xz backdoor
On Mar 31, 2024 2:37 PM, Pierre-Elliott Bécue Wrote: > The PGP submodule of a Yubikey can host 3 keys, one signing, one > authent, and one encrypt. ISTR accessing the signing key is always > prompting for the PIN. Same for the encryption key. (I think both can be > configured otherwise) Only for the signing operation, one can turn on the "force-sig" option so that the key always prompt for a pin. And that is not the default. Thomas
Re: list of upstream tarball signing schemes?
Thank you for your input. I opened a bug with upstream: https://github.com/NixOS/nix/issues/3293
Bug#968098: ITP: ungoogled-chromium -- A lightweight approach to removing Google web service dependency
Package: wnpp Severity: wishlist Owner: Thomas X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : ungoogled-chromium Version : 84.0.4147.105-1.1 Upstream Author : Eloston * URL : https://github.com/Eloston/ungoogled-chromium * License : BSD-3-Clause Programming Lang: Python Description : A lightweight approach to removing Google web service dependency Chromium itself is still very dependent on Google web services to operate making this very difficult for those who want to use Chromium without the Google aspect to it. This is where ungoogled-chromium comes in and offers an alternative to Chromium: A transparent and more private Chromium with Google web services stripped from the source code. I use ungoogled-chromium quite heavily as my main browser as I believe that it is a better alternative to the chromium that currently exists. The package currently has a ungoogled-chromium-debian Github link where the original developer has included build files for ungoogled-chromium. I also intend on contacting & assisting the developer in packaging the files for Debian and uploading them to the official Debian archive.The ungoogled-chromium-debian branch contains packages for Debian sid and stable but is sometimes not as up-to-date as the original upstream source. So far, I plan on maintaining the package on my own but if I do need help I hope that I can reach out to the Debian Chromium Team. I require a sponsor - I have found a developer willing to sponsor the uploads.
Re: List of not-packaged depends
On Oct 12, 2024 3:02 PM, Sudip Mukherjee wrote: > > On Fri, Oct 11, 2024 at 11:01:37AM +0200, Thomas Goirand wrote: > > Hi, > > > > Having a quick look at requirements.txt VS Debian repo, to package this > > software, we would need: > > > > python3-cvss > > python3-gsutil > > python3-lib4sbom > > python3-lib4vex > > python3-packageurl > > python3-rpmfile > > Thanks for the list zigo. But the main intention of my mail was to check if > the ITP owner is still interested or not since there has been no progress > since 18 Apr 2023. > If the ITP owner is not interestd then I can do this one ( + any other > dependency) under the Debian Python team. > > I guess I will wait a week for any reply, and if there is no reply by then > from the owner I will assume the ITP owner is not interested anymore and take > over. > > > -- > Regards > Sudip At this point (ie: 6 months after the ITP), IMO you do not need to wait. Thomas
Re: sensible languages for younger contributors (was Re: lintian.debian.org off ?)
On Sep 22, 2024 5:05 PM, Jonathan Dowland wrote: > > On Wed Sep 4, 2024 at 8:33 PM BST, Serafeim (Serafi) Zanikolas > Or maybe the issue isn't difficulty, but > that doing so is simply unattractive? Rewriting things just to change language is indeed unattractive. > (Please, not Python :P) Why? If one looks at popularity, Python wins... Thomas Goirand (zigo)
Re: Bits from DPL
On Jan 7, 2025 21:25, Julien Plissonneau Duquène wrote: > I think that being able to host the primary git repository of packages > elsewhere is a freedom worth maintaining for many reasons. I don't think we should continue to allow the "freedom" to be annoying for every other contributors. Even if there may be some "technical excuses" to do so. Thomas Goirand (zigo)
Re: DEP-14: Default branch name 'debian/latest' objections?
On Jan 24, 2025 22:24, Xiyue Deng wrote: > > Fabio Fantoni writes: > > > > ... > > > > There is also another thing to consider, if you keep a generic one as > > default it always points to the latest version, while a specific one > > might not be the latest version and if the contributors do not check > > well the branches they could risk wasting time (and maybe also the > > reviewers) doing work that does not include work in progress on more > > recent branch or that conflicts with it > > > > I would like to echo on this point. I had worked on a repository that > has the "master" branch marked as the default branch on Salsa, which > lacks many changes compared to the released version. I tried to > manually incorporate those changes, and only later found out that the > actual latest branch is "debian/sid" and it did have everything > up-to-date. (Note that this has since been fixed[1]). I think for new > repository, standardizing on a name (either "debian/latest" or people's > liking) helps identify where the latest work goes to. And as Salvo > pointed out, it's the tag names that indicate where the releases go to, > not the branch names. > > [1] https://salsa.debian.org/debian/mozc What you experience shows one thing: having the default branch being set correctly should be what we mandate. NOT the name of it, which could be different than the standards for many reason. Thomas Goirand (zigo)
Re: Bits from DPL
On Jan 8, 2025 18:07, Peter Pentchev wrote:. > I am mostly concerned with content that may be viewed as illegal, > in the context of "this was pulled in automatically, there was no > human being who initiated that action, so there is nobody but > the site admins to be held responsible". Hi, I don't see why we would make a special case for mirror repos on Salsa. Just like other repos, those maintaining the mirror could be held respossible for what is hosted in the mirror, I suppose. If you fear illegal content may get in as you mentioned, please consider not seting up such a mirror. Hopefully, no Salsa admin will get into legal troubles because of another person mistake or missbehavior. If ones become aware of abuse, please report it like everything else at /salsa/support on salsa.d.org. If the source of the mirror is well known and accountable for, and it is your opinion it is useful, do it. Though a mirror just to pretend your package is hosted in Salsa, with all the tooling like MR desactivated brings IMO no value, and is just a waste of resources. Cheers, Thomas Goirand (zigo) P.S: the above is only my personal opinion, but I suspect other Salsa admins could agree with such common sense. :)
Re: Change the expectation that emails should wrap at 80 characters
On Feb 27, 2025 12:02, Blair Noctis wrote: > actually struggle to read the hard-wrapped-at-80-then-wrapped-again text. The standard for email is 74 chars, not 80... Thomas Goirand (zigo)
Re: Dropping awk?
On Apr 21, 2025 03:42, Josh Triplett wrote: > > On Sun, Apr 20, 2025 at 10:12:24PM +0300, Adrian Bunk wrote: > > Container size is obviously not a priority for such users. > > That is incorrect. Many, many users use Debian as the basis for > containers, and many such users care about container size, sufficiently > so to work on reducing it. I agree that reducing our footprint is important. But not only for containers. I'd love it if our base cloud image was smaller too. It currently is a way bigger than it used to (329M for the generic cloud qcow image), I don't know why... Thomas Goirand
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.
Bug#278035: ITP: vdr-plugin-remote -- Plugin for vdr to support the built-in remote control port of DVB-Cards
Package: wnpp Severity: wishlist * Package name: vdr-plugin-remote Version : 0.3.1 Upstream Author : Oliver Endriss <[EMAIL PROTECTED]> * URL : http://endriss.escape.bei.t-online.de/vdr * License : GPL Description : Plugin for vdr to support the built-in remote control port of DVB-Cards This plugin for vdr supports the built-in remote control port of some DVB-Cards or CI-Modules. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: [EMAIL PROTECTED], LC_CTYPE=iso_8859_15 (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED])
Bug#278045: ITP: vdr-plugin-console -- Plugin for vdr that implements a virtual terminal
Package: wnpp Severity: wishlist * Package name: vdr-plugin-console Version : 0.5.1 Upstream Author : Jan Rieger <[EMAIL PROTECTED]> * URL : http://ricomp.de/vdr/ * License : GPL Description : Plugin for vdr that implements a virtual terminal This plugin for vdr implements a virtual terminal, that can be displayed by vdr's OSD, it allows you to display and control allmost every console application. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: [EMAIL PROTECTED], LC_CTYPE=iso_8859_15 (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED])
So will test be grandfathered?
Manoj suggested this language for 10.1: > -- > 10.1 > > Except for the following shell builtins, additional commands provided > by a Debian shell installed in /bin/sh shall be considered to have the > same status as executables in the filesystem for the purpose of name > conflicts with other packages. As a result, they must either provide > the same functionality as the other program or else discuss with the > other maintainer and debian-devel which one should be renamed. > > > Note: > A Posix-conformant shell is allowed to build in *anything*, and if > it's not a Posix-specified utility that's being built in, then it can > have *any behavior whatsoever*. The presence of two commands with > conflicting behaviour adds an unacceptable uncertainty when scripts > are executed, and this has to be resolved. > ------ Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > What we do still need is the list of grandfathered builtins. While we wait for the official list, can we at least assume that "test" will be grandfathered, and consequently that "-a" and "-o" should be avoided? -- Thomas Hood
Re: So will test be grandfathered?
I wrote (on debian-devel): > While we wait for the official list, can we at least assume that > "test" will be grandfathered, and consequently that "-a" and "-o" > should be avoided? Oops -- I meant to send this to debian-policy. The broader context of my question was bug #267142 "debian-policy: Sections 10.4 and 6.1 are inconsistent (Posix doesn't say what you think it says)". Please follow up to debian-policy. -- Thomas Hood
Re: Introducing pmount in Debian / New plugdev group
On Tue, 09 Nov 2004 18:50:39 +0100, Martin Pitt wrote: > However, I was not satisfied with this solution because of several > reasons: [Several excellent reasons] > So the Ubuntu approach is a bit different: we let hal run as normal > user, do not modify /etc/fstab at all and instead use a program > called 'pmount' (policy mount) that allows normal users to mount > removable devices without an /etc/fstab entries. All sounds good. Have you heard that mount's upstream is looking for someone to adopt mount (and the rest of util-linux)? Interested? -- Thomas Hood
Bug#284978: general: libgmp segfaults on generating 48402688-bit random number
Package: general
Version: 20041209
Severity: normal
The program
#include
#include
#include
#include "gmp.h"
int main(int argc, char** argv)
{
mpz_t A,B,C;
gmp_randstate_t state;
gmp_randinit_default(state);
gmp_randseed_ui(state, 3);
mpz_urandomb(A, state, 48402688);
mpz_urandomb(B, state, 845*32);
mpz_gcd(C,A,B);
}
compiled with gcc = gcc-2.95.4, gmp = gmp-4.0.1
segfaults in the mpz_urandomb() function
with a back-trace
#0 0x4003d051 in __gmpn_copyi () from /usr/lib/libgmp.so.3
#1 0x40023012 in __gmp_randinit_lc_2exp () from /usr/lib/libgmp.so.3
#2 0x4002310d in __gmp_rand () from /usr/lib/libgmp.so.3
#3 0x400331f8 in __gmpz_urandomb () from /usr/lib/libgmp.so.3
#4 0x0804861b in main (argc=1, argv=0xbca4) at use-gcds-BUG.c:14
-- System Information
Debian Release: 3.0
Kernel Version: Linux chiark 2.4.28 #2 SMP Mon Nov 22 15:56:31 GMT 2004 i686
unknown
Re: Linux Core Consortium
On Sun, 12 Dec 2004 18:40:07 +0100, Joey Hess wrote: > Andrew Suffield wrote: >> > http://wiki.debian.net/index.cgi?ReleaseProposals >> >> Every single one of these falls into one of these four groups: > > Please note the "wiki" in the URL and the "edit page" button on the > page. Inspired by A.S.'s comment I've just sorted the proposals into four groups, though not exactly the ones he defined. -- Thomas Hood
Re: removing in postrm rc*.d symlinks that I did not create
It has been suggested that you install symlinks[*] but provide an /etc/default/foo file with an environment variable that forcibly disables the service when set to "off" or whatever, and that the initscript be written so that it overrides this forced disabling when run from the command line. Of course this can be made to work but it is a bad hack. Bad because it doesn't use Debian's standard mechanism for configuring services. The idea behind initscripts is that they do what they are told when they are run. sysv-rc and file-rc implement two different schemes for determining when they are run and with what arguments. I don't see why people keep trying to undermine the standard mechanism. Under the circumstances you describe it is reasonable to refrain from installing symlinks[*] in runlevel directories. I think you are justified in deleting the symlinks on purge too, so I suggest you simply override lintian and linda. [*] (or do the file-rc equivalent, which happens automatically if file-rc is installed because you use update-rc.d) -- Thomas Hood
Re: Problems to upload
[didn't sent to the list...] Andreas Tille wrote: On Fri, 17 Dec 2004, Andreas Metzler wrote: first place. Especially the hint to "PASSIV MODE" smells like something has changed to the situation before. | dput (0.9.2.15) unstable; urgency=low Perhaps this was the reason but I should probably reopen the bug which claimed more verbose error messages. The failure was caused because only passive mode seems to work - at least I was asked by manual ftp-client to switch to passive mode (I do not know until know what passive excatly is). Also dupload caused a passive mode related error message. In contrast to this dput just stopped with a Python error. Your analysis is correct, my apologies. As non-DD, I really don't get to test ftp uploads as thoroughly as I should. There is a bug report (and I've just sent a (corrected) fix), #283370, which concerning this problem. Sorry for leaving this open for so long. Kind regards Thomas (dput comaintainer) -- Thomas Viehmann, <http://thomas.viehmann.net/>
Re: How to ensure packages generated from -source are installable?
On Sun, 02 Jan 2005 04:20:04 +0100, William Ballard wrote: > Kernel module source packages generated Debian packages which may not be > installable. For instance, alsa-source does not depend on alsa-base, > but the generated alsa-modules does. ndiswrapper-source does the same > with ndiswrapper-utils. Right. Do you regard this as a problem? > Is there a flag to dpkg to refuse to install unless dependencies are > met? I am not sure what you mean. That is dpkg's default behavior. > What ends up happening now is the package ends up installing broken. I am not sure what you mean by this. Here is what happens when I install an alsa-modules package in the absence of alsa-base: [EMAIL PROTECTED]:/usr/src$ sudo dpkg -i alsa-modules-2.4.27-1-686_1.0.7-3~unreleased1+10.00.Custom_i386.deb Selecting previously deselected package alsa-modules-2.4.27-1-686. (Reading database ... 192428 files and directories currently installed.) Unpacking alsa-modules-2.4.27-1-686 (from alsa-modules-2.4.27-1-686_1.0.7-3~unreleased1+10.00.Custom_i386.deb) ... dpkg: dependency problems prevent configuration of alsa-modules-2.4.27-1-686: alsa-modules-2.4.27-1-686 depends on alsa-base (>= 1.0.1-1); however: Package alsa-base is not installed. dpkg: error processing alsa-modules-2.4.27-1-686 (--install): dependency problems - leaving unconfigured Errors were encountered while processing: alsa-modules-2.4.27-1-686 If you are complaining about the fact that dpkg leaves behind unpacked files when it aborts then I suggest you file a bug report against dpkg. This can then be merged with #15162 and the twelve reports already merged with it which complain about dpkg leaving behind unpacked files in various other circumstances. > The generalized form of this question is how does one deal with > missing dependencies when using dpkg and not apt. One downloads the missing packages and dpkg --install's them. BTW have you tried module-assistant? -- Thomas Hood
Re: New stable version after Sarge
Paul van der Vlis wrote: Hello, One of the biggest disadvantages of Debian for me is the long time it takes for a new stable version. What about saying something like: the next stable release comes in the beginning of 2006? I can understand something like "Debian releases when it's ready", but many people have to work together. Maybe it's better to say: "a package releases when it's ready, but the deadline for the next Debian release is a fixed date". You will understand that my most important point is security-support. With regards, Paul van der Vlis. Well, you could argue that debian branches are not perfectly named but: "stable" is best if you need *absolute* failsafety for critical jobs "testing" is best if you want a stable system with new(ish) software "unstable" is for everybody who needs the newest software, like me. honestly, I have never had problems (yet) with using sid for day-to-day stuff. If I needed something more production-ready, I'd use testing because you have (almost) garantee that the software will work and you will have security updates, too. (But not in the same quality as "stable", as I understand it. If I needed to run a always-needed very-important server on the internet, I would use "stable". Regards, Thomas Jollans
package up for grabs - xmms-xmmplayer
Package: xmms-xmmplayer Description: XMMS plugin that uses MPlayer to play video files CC me I am not on the list I know longer use this package so if someone wants to maintain it that uses it let me know. Its had two bugs in the year since I packaged it and one new upstream release 8 months ago. I would say there are not very many people using it, If no one wants it I will probably consider removing it. Its major problem is that it depends on mplayer. Which is not in debian. Unofficial packages of mplayer are available from http://debian.video.free.fr/ xmms-xmmplayer currently has one bug, which is about no mplayer: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286256 -- Jason "I hope you learn speaking English proper I hope speak I me you." -- Branden Robinson, 2001
Re: New stable version after Sarge
On 04-Jan 09:45, Steve Greenland wrote: > On 04-Jan-05, 07:40 (CST), Paul van der Vlis <[EMAIL PROTECTED]> wrote: > > One of the biggest disadvantages of Debian for me is the long time it > > takes for a new stable version. > > If you want Ubuntu or Progeny, you know where[1] to find them. :-) > > Seriously. There's just no way you're going to change the way Debian > makes releases, or rather, doesn't. It's too big, and there are just > too damn many people involved, many of whom simply don't care about > releases. As long as we maintain our current release criteria (which I > don't necessarily think we should change) we will get slower and slower > as we get bigger and bigger. > > Steve > > [1] Okay, just in case you don't: http://www.ubuntu.com/, > http://www.progeny.com How large of a change would it be to switch to a goal based releases? More along the lines of "new installer for sarge" and once all release goals have been met tag a release and only accept new packages that fix RC bugs. or Use popularity-contest results to find a "core" set of packages and make a release more time based, but only count RC bugs from those "core" packages (Maybe those packages that would fit on 2 CDs?) Debian is a great distro, but I can't really use it anywhere other than a static server (and even then woody's SpamAssassin is much too out of date to be usefull.) If an organization _needs_ the security and stability of hopefully^W historic debian release, than there is Progeny or decent admins to keep things running. It would be nice if testing really was "Testing" a whole set of packages where with every new release it was quickly switched to a new snapshot of Sid, or Sid when some major release goals where met. Thomas
Re: New stable version after Sarge
On 05-Jan 09:30, Jose Carlos Garcia Sogo wrote: > El mié, 05-01-2005 a las 04:16 -0800, Stephen Birch escribió: > > Paul van der Vlis([EMAIL PROTECTED])@2005-01-04 14:40: > > > Hello, > > > > > > One of the biggest disadvantages of Debian for me is the long time it > > > takes for a new stable version. > > > > I guess one man's meat is another man's poison. > > > > Since I administer a large number of distant computers I view the long > > time between stable releases as a feature not a bug. > > > > > What about saying something like: the next stable release comes in the > > > beginning of 2006? > > > > Once a year works for me, but any more frequent would be a pain in the > > neck. Frankly a release every 18 months seems about right. > > I agree with you on this. People using stable can not cope with > upgrades each 6 months or so. Is that really true? I would love to run "apt-get dist-upgrade" every half a year. Currently it doesn't get me much. :) Now, for production systems, don't you do some testing *before* you upgrade the OS? When debian release on a much fast and predictable schedule, it might be nice to have longer security support. Maybe the security team would only really _track_ security related problems and "remind" maintainers that they needed to update thier debs in Stable-1, and Stable-2. Thomas
Bug#293669: ITP: xen -- virtual machine monitor
Package: wnpp Severity: wishlist * Package name: xen Version : 2.0.4 Upstream Author : University of Cambridge Computer Laboratory <[EMAIL PROTECTED]> * URL : http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ * License : GPL / BSD license Description : virtual machine monitor Xen is a virtual machine monitor for x86 that supports execution of multiple guest operating systems with unprecedented levels of performance and resource isolation. Any Linux distribution (RedHat, SuSE, Debian, Mandrake) should run unmodified over the ported OS. Xen can securely execute multiple virtual machines, each running its own OS, on a single physical system with close-to-native performance. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please post listing and status of NEW queue
On Sat, 12 Feb 2005 01:20:13 +0100, Anibal Monsalve Salazar wrote: > http://qa.debian.org/~anibal/debian-NEW.html > > The above page is based on previous work done by Peter Reinholdtsen. > > It still work in progress. > > Any input is welcome. Thanks for providing this page. It would be nice if there were a "status" field that showed whether or not an ftp master had looked at the package and, if so, what his opinion of the package was. E.g., * new * looks OK * needs investigation I don't know whether or not ftp masters would be willing to make use of such a feature, though. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please post listing and status of NEW queue
On Sat, 12 Feb 2005 01:20:13 +0100, Anibal Monsalve Salazar wrote: > Any input is welcome. It would be nice if the page indicated which of the binary packages is new. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: please post listing and status of NEW queue
On Sat, 2005-02-12 at 18:59 -0600, David Moreno Garza wrote: > On Sat, 2005-02-12 at 22:52 +0100, Thomas Hood wrote: > > It would be nice if the page indicated which of the binary packages is new. > > The binary column indicates those created within the source package. > Every source package on the summary is new, that's why it is on the NEW > queue. Not every source package is new to the archive. Some of the source packages are already present in the archive but are in the queue because they contain binary packages that are not already present in the archive. It would be nice if the page indicated which of the _binary_ packages is new. -- Thomas Hood <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First line in /etc/hosts
On Sun, 13 Feb 2005 13:30:11 +0100, Steinar H. Gunderson wrote: > Current d-i writes the following line to the beginning of /etc/hosts: > >127.0.0.1localhost.localdomain localhost This is correct. > Traditionally, this confuses some programs; at least pvm used to have > problems with this, and I'm fairly sure cfengine2 doesn't like it either What problems? If there are problems then they probably arise from a faulty _combination_ of /etc/hosts, hostname, /etc/nsswitch.conf and /etc/resolv.conf settings. > so we've changed to > >127.0.0.1. localhost > > However, now we've suddenly discovered that _other_ programs get confused by > this! So revert the change? > In particular, if you use an NFSv4-patched mount, it does a > gethostname() and resolves that, which returns 127.0.0.1, which in turn makes > it happily use that as a client identifier to the remote server. (This breaks > when two or more such clients connect, obviously.) Make your /etc/hosts look like this: 127.0.0.1localhost.localdomain localhost w.x.y.z . Make w.x.y.z either the permanent IP address of your machine's permanently connected network adapter, or, if it does not have one of those, "127.0.1.1". -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
Hi Stefano, Bluefuture wrote: I know that there are a little bit group of people that think that the "old" use of watch file could be converted in a Qa tools, but actually i'm the only one that is trying to find a solution that could fix that lack of watch file. But without maintainers interest, the project still lack in an usable status. There is no reason to put more work and effort on a community tool that community itself consider useless. I hope that something could change. But i don't belive it. I know that I thougt dehs per se not too useful, but the watch section on qa.d.o has inspired me to write watch files for two of my packages. Not much (2 out of 7), admittedly, but I think that it's fairly useful. I think the experimental columns are overkill (as people packaging experimental stuff probably monitor upstream releases even more closely). If 25% of the packages can be watched, hey, that's a fair share. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
Josselin Mouette wrote: 2.6 kernel, alsa-base doesn't end up being installed. The result is that for most sound cards, both OSS and ALSA modules end up installed, resulting in various and random problems. To avoid that, shouldn't the kernel-image packages for 2.6 depend on alsa-base? Please not. There's people running kernels without needing sound or alsa-base. I wouldn't mind recommends/suggests, but depends is a litte bit strong IMO. Kind regards Thomas -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298117: ITP: camlrpc -- Ocaml Sun RPC libraries
Package: wnpp Severity: wishlist Owner: Thomas Petazzoni <[EMAIL PROTECTED]> * Package name: camlrpc Version : 0.4.1 Upstream Author : Gerd Stolpmann <[EMAIL PROTECTED]> * URL : http://www.ocaml-programming.de/programming/rpc.html * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : Ocaml Sun RPC libraries RPC is a package supporting the Sun RPC protocol. RPC programs, procedures, clients, and servers can be dynamically represented and modified. Of course, there is also a classical RPC generator which generates functions doing the language mapping from XDR values to language values and vice versa. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10 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 #298195: ITP: tinywm -- Ridiculously tiny window manager
Hi. Nick Welch wrote: (not sure if i can post to this list, but what the hey) Hey, thanks for joining the discussion. It's the fair license, which is OSI approved: http://opensource.org/licenses/fair.php Yet it seems that the BSD license's Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: is much more explicit than the fair license on use and modifications. Also I'm not sure about the "notification" bit, so I'll leave that to the experts. Thomas -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
Hi. Josselin Mouette wrote: As long as the linux26 installation ends up with both sound modules loaded, that's a bug that needs to be fixed, though. Another option would be to put the alsa modules in separate packages, just like pcmcia modules. That definetly sounds much better ;). Kind regards Thomas -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Sun, 06 Mar 2005 00:20:13 +0100, Paul Hampson wrote: > Hmm. I would think that the better solution (the less surprising > solution) would be to leave out the ALSA modules from the Debian > kernel package, since we have a seperate package of ALSA modules > which _does_ depend on alsa-base. That's not a bad idea. We already have the problem that the ALSA drivers in the kernel-image packages are out of date relative to the ALSA libraries in alsa-lib. (Currently, the drivers in kernel-image-2.6.8 are version 1.0.4 but alsa-lib in sarge is version 1.0.8.) Omitting the ALSA drivers from kernel-image packages would solve this problem by forcing people to install up-to-date alsa-modules packages. On Fri, 04 Mar 2005 20:20:10 +0100, Josselin Mouette wrote: > As long as the linux26 installation ends up with both sound modules > loaded, that's a bug that needs to be fixed, though. Another option > would be to put the alsa modules in separate packages, just like pcmcia > modules. There already exist separate alsa modules packages. Currently we only build them for 2.4 kernels, though. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Mon, 07 Mar 2005 13:50:10 +0100, Josselin Mouette wrote: > Without alsa-base installed, hotplug and discover will load both > modules, resulting in various disasters depending on the hardware. It's > not because things work with your setup that they are suitable for a > stable Debian release. Actually, this isn't true for 2.6 kernels. By default, discover loads ALSA modules into 2.6 kernels. The alsa-base/alsa-utils duo still has its uses, though, even if you are running 2.6. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Switchconf: Orphaning or removing?
On Wed, 09 Mar 2005 12:40:15 +0100, martin f krafft wrote: > I think switchconf is nice because it ties in well with guessnet, > and because it's lean and mean and does exactly what it should, no > more and no less. I agree that switchconf should be kept around so long as there is nothing else in Debian that provides the same functionality. laptop-net also contains a configuration file switching mechanism. I believe that Chris Hanson (laptop-net's author) was once thinking of repackaging this separately from laptop-net. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Mon, 07 Mar 2005 00:10:12 +0100, Christoph Hellwig wrote: > It's not a depency in any way. I play sound just fine with OSS drivers > without the ALSA mess getting in my way anywhere. On Mon, 07 Mar 2005 13:50:10 +0100, Josselin Mouette wrote: > Without alsa-base installed, hotplug and discover will load both > modules, resulting in various disasters depending on the hardware. It's > not because things work with your setup that they are suitable for a > stable Debian release. In theory I guess there should be an oss package that was the homologue of the alsa-base package. It would include files that would blacklist ALSA modules, just as alsa-base blacklists OSS modules. These packages would Conflict with each other and 2.6 kernel-image packages would Depend on their disjunction. An alternative is to drop ALSA modules from the 2.6 kernel-image packages. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Mon, 07 Mar 2005 20:40:40 +0100, Josselin Mouette wrote: > Actually, the proposed solution that raised some approval was to split > out the ALSA modules, just like the pcmcia modules. I raised this idea on #debian-kernel and it was shot down.[0] [0]http://lists.alioth.debian.org/pipermail/pkg-alsa-devel/2005-March/002039.html As one of the ALSA maintainers, I have done what I can about this problem. People who want to use ALSA can install alsa-base which blacklists OSS modules. If a fresh sarge/2.6 system lacks alsa-base then this would seem to be a problem because in that case nothing enforces the mutual exclusion of OSS and ALSA modules. If linux26 doesn't install alsa-base then perhaps it should do so. Even better, possibly, would be to give the user a choice between OSS and ALSA: if the user chooses ALSA then she gets alsa-base; if she chooses OSS then she gets the (currently nonexistent) "oss" package which blacklists ALSA modules. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serious kernel problems on new i386 hardware
might be fixable by regenerating a new initrd for the 2.6 kernel: mkinitrd -v /boot/initrd-2.6.x-x.img 2.6.x-x make sure to add this line to the grube menue.lst: initrd /boot/initrd-2.6.x-x.img On Fri, 11 Mar 2005 02:01:42 +1100, Paul Hampson wrote > On Thu, Mar 10, 2005 at 03:10:12PM +0100, Andreas Tille wrote: > > Hi, > > > I've got a new Dell machine which I was able to install with Kernel 2.4. 27. > > It has a SATA drive but I disabled SATA in BIOS according to the manuals. > > All I write in the following has this SATA disabled BIOS setting. > > > As I said kernel 2.4.27 works fine. I attach a dmesg and syslog to this > > mail. > > > I tried to upgrade to a 2.6.x kernel but failed always with kernel_panic. > > I tried 2.6.8, 2.6.8 and 2.6.10 (here -1-386 and -1-686 versions) and > > all failed with the same result: > > > pivot_root: No such file or directory > > /sbin/init: 432: cannot open dev/console: No such file > > Kernel panic - not syncing: Attempt to kill init! > > > ata: 0x1f0 IDE port busy > > ata1: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15 > > ata1: dev 0 ATAPI, max UDMA/33 > > ata1: dev 1 ATAPI, max UDMA/33 > > ata1: dev 0 configured for UDMA/33 > > ata1: dev 1 configured for UDMA/33 > > scsi0 : ata_piix > > elevator: using anticipatory as default io scheduler > > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > > ide0: I/O resource 0x1F0-0x1F7 not free. > > ide0: ports already in use, skipping probe > > ide1: I/O resource 0x170-0x177 not free. > > ide1: ports already in use, skipping probe > > This is your problem here. You made your initrd under 2.4.27, where your > devices where /dev/hd?. However, 2.6 with the initrd has loaded them > with the SATA driver, and sees them via /dev/sd?. > > I think you're going to have to manuall edit your initrd and fstab to > deal with the change in device name between versions. > > Alternatively, pull ata_piix driver out of the initrd, and see if the > ide driver will load and run your disks. > > However, that first line (IDE port busy) worries me a little, since > it seems neither driver is actually claiming the port itself. > > If you want to experiment, there's a command you can put on the Linux > kernel command line to break into the initrd before it actually does > anything, and you can see what devices exist and drivers and whatnot. > > I can't remember the command though. -_- > > -- > --- > Paul "TBBle" Hampson, MCSE > 8th year CompSci/Asian Studies student, ANU > The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) > [EMAIL PROTECTED] > > "No survivors? Then where do the stories come from I wonder?" > -- Capt. Jack Sparrow, "Pirates of the Caribbean" > > This email is licensed to the recipient for non-commercial > use, duplication and distribution. > --- -- Have fun! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Thu, 10 Mar 2005 02:50:04 +0100, Steve Langasek wrote: > Considering you're talking about solutions that require updates to > kernel-image packages *anyway*, why has no one suggested adding the > necessary blacklist entries to these packages? k-i packages aren't the right place to put the blacklists because more than one of them can be installed at once. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Thu, 10 Mar 2005 01:10:12 +0100, Josselin Mouette wrote: > Davide, would you agree with making gnome-media depend on something like > "alsa-base | kernel-image-2.4", to ensure sound is working properly upon > installation? I don't see why gnome-media should be involved. This problem has nothing specifically to do with GNOME. Also, the dependency you suggest would prevent people who install non-Debian 2.4 kernels from using OSS. Here is another idea. We create a new binary package "sound-system-chooser" which contains blacklists for both OSS and ALSA and provides a debconf interface that the administrator can use to disable either or both of the sound systems. Blacklists would be removed from alsa-base. k-i 2.6 and alsa-base would both Depend on sound-system-chooser. This would solve another problem with the current alsa-base, viz., that removing it isn't enough to enable OSS again -- alsa-base has to be purged in order to remove the hotplug blacklist file that it contains. sound-system-chooser could be generated from the alsa-driver source package. Anyone see anything wrong with this idea? P.S. I apologize for all my non-threading posts on this topic. My webmain interface apparently doesn't support In-Reply-To headers. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Stateless linux in Debian
I am interested in this subject. http://panopticon.csustan.edu/thood/readonly-root.html -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't kernel-image-2.6.x-y-z depend on alsa-base ?
On Thu, 10 Mar 2005 22:00:15 +0100, Thomas Hood wrote: > Here is another idea. We create a new binary package > "sound-system-chooser" which contains blacklists for both OSS and ALSA and > provides a debconf interface that the administrator can use to disable > either or both of the sound systems. Blacklists would be removed from > alsa-base. k-i 2.6 and alsa-base would both Depend on > sound-system-chooser. This would solve another problem with the current > alsa-base, viz., that removing it isn't enough to enable OSS again -- > alsa-base has to be purged in order to remove the hotplug blacklist file > that it contains. sound-system-chooser could be generated from > the alsa-driver source package. I have implemented this in alsa-driver, calling the new binary package 'sound-base'. One runs "dpkg-reconfigure sound-base" to change sound system. Josselin Mouette (and any other interested parties): Please test! http://www.aglu.demon.nl/alsa/ -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepted vile 9.4-r1 (powerpc sparc i386 source all)
In article <[EMAIL PROTECTED]> you wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > Format: 1.7 > Date: Tue, 15 Mar 2005 00:28:38 +1100 > Source: vile > Binary: xvile vile-filters vile vile-common > Architecture: all i386 powerpc source sparc > Version: 9.4-r1 thanks. For 9.5, the short list I have remaining is to finish the Inno Setup script and fix the bugs reported in the ruby filter. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Key management using a USB key
Eric Dorland wrote: An arguably more secure approach would be to use a cryptographic smart card in a usb key form factor with OpenSC. Unfortunately integration with ssh and gpg is lacking at this point, but I hope to be able to do something about that post-sarge (ssh has support but doesn't compile it in, and gnupg support will come with gnupg 2.0). gnupg 1.4 (as in sid) supports OpenPGP cards like the one I'm presently using (bought from g10code). The form factor is Chipcard-Reader+Chipcard, but it's there. Kind regards Thomas -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Accepted lynx 2.8.5-2sarge1 (source powerpc)
Thomas Dickey <[EMAIL PROTECTED]> wrote: > --ReaqsoxgOBHFXBhH > Content-Type: text/plain; charset=iso-8859-1 > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > On Sat, Nov 12, 2005 at 10:10:08AM +0100, Martin Schulze wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >>=20 >> Format: 1.7 >> Date: Sat, 8 Oct 2005 09:23:11 +0200 >> Source: lynx >> Binary: lynx >> Architecture: source powerpc >> Version: 2.8.5-2sarge1 >> Distribution: stable-security >> Urgency: high >> Maintainer: Martin Schulze <[EMAIL PROTECTED]> >> Changed-By: Martin Schulze <[EMAIL PROTECTED]> >> Description:=20 >> lynx - Text-mode WWW Browser >> Changes:=20 >> lynx (2.8.5-2sarge1) stable-security; urgency=3Dhigh >> . >>* Non-maintainer upload by the Security Team >>* Applied patch by Ulf H=E4rnhammar to fix buffer overflow that can le= > ad >> to arbitrary code execution [WWW/Library/Implementation/HTMIME.c, >> CAN-2005-3120] > I wrote the patch. Ulf reported the problem. hmm - I was being too optimistic. Ulf's original patch, which I see in the diff's changes the behavior from a core dump to truncating the data (and giving the wrong result). I'd rather that the code work than simply replace one bug with another. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: State of gcc 2.95 use in Debian unstable
Dave Carrigan wrote: > On Wed, Nov 16, 2005 at 04:12:45PM +0100, Thiemo Seufer wrote: >>>The situation is: gcc-2.95 is no longer needed to compile debian packages, >>>but it is still needed for other tasks, by many people. >>By whom, and for what? So far I haven't heard a specific project's >>name. [...] > I am quite sure that there are Debian *users* out there that have legacy > code that only builds under gcc 2.95 (or more likely g++ 2.95) and they > haven't ported it to a newer C compiler because there is no business > case for it. Dave, we're not working on the removal of gcc 2.95 for the fun of it. Sarge ships with gcc 3.3 as default and supports gcc 2.95. More than one year from now, Debian will release its next stable release and the balance of the costs of continued support of gcc 2.95 versus its benefits is shifting to a point where the effort of keeping 2.95 is undesirable. Support for old compilers is quite an effort and it's in the best interest of Debian and its users by dropping it so that Debian can retain its high quality standard. Debian is not rushing to drop gcc 2.95, but in the long run, it's inevitable. Or, to put it in your words, there is a business case for dropping gcc 2.95 support in etch. > Removing a package simply because the Debian developers don't need it > any more is the kind of arrogance that drives users away from Debian to > other distributions. Well, Debian is a fairly large sample of (free) software. If reliance on gcc 2.95 is a vanishing characteristic of Debian packages, this suggests that the general usage has diminished to a point where it is unreasonable to continue support. this is why Thiemo asks for evidance of the contrary. This has nothing to do with arrogance or developers disregarding the interests of its users. It is about sustaining quality by allocating resources appropriately. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Using Enhances a bit more?
Hi, Enrico Zini suggested something like: > Package: phpgroupware-foobar > Enhances: phpgroupware Good idea, will do. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mixing different upstream sources in one package
Hello Jay, Jay Berkenbilt wrote: > My inclination would be decline requests to add unrelated packages to > psutils, but I thought I'd solicit input from others in case someone > has some perl (oops, pearl) of wisdom that I have overlooked. Thanks! IMHO (and I have suggested this particulary for 'sed through a postscipt file' packages on d-mentors) this is about the users and free software. Both are greatly helped by putting the stuff providing yet-another-postscript-manipulation-scriptlet in the psutils package where users have a chance to find it. OTOH if upstream is actively opposing such additions, you might reconsider to keep them happy. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to deal with screwed up package
Hi Bartosz, Bartosz Fenski aka fEnIo wrote: > Let's say I'm going to remove debconf questions at all. To keep user's > system clean I should remove chosen group, but... because of some > bugs[3][4][5] it's possible to leave system non-working after that. How about just leaving the old group rot? Basically, the question is very similar to the ever-recurring should system users be removed one. It is my impression that both scenarios aren't the end of the world, but not removing seems to have the stronger support in numbers and possibly the better arguments in general and here it seems to be the prudent option by far. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: petsc_2.3.0-1_i386.changes REJECTED
Hi, Adam C Powell IV wrote: > * There is broad consensus for versioned -dev packages (e.g. > Thomas Viehmann's precedent, Junichi's libpkg-guide), > particularly for this case where both the Debian alternatives > system and PETSC_DIR mechanism allow users to select between > multiple versions or multiple builds of the same version (LAM, > single precision or complex, -contrib linked vs parmetis and > hypre, -dec with HPaq alpha tools, etc.) Eh. I only said that versioned -dev packages seem tolerable to most people. In particular, I don't really like the idea of my name being mentioned so close to petsc's use of the alternative system. IMHO it's a genuine example of a very bad idea. > * There is a very strong consistency argument for keeping > petsc-dev, cf. octave, python-dev, linux-image-2.6-xxx, though I don't really think that any of these packages have too much in common with petsc-dev - octave and linux-image-2.6-xxx aren't even -dev packages. Python and the notion of a default-python-version and it's implementation seems rather special to me, and TBH, I don't think anyone claims that the python dependency construction is without problems. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#272066: Patch?
debian-devel readers: There is a proposal (#272066) that bootclean.sh's
cleanrun function not delete symlinks under /var/run/ whose targets are
directories. The function already refrains from deleting directories.
Any objections? Please reply to [EMAIL PROTECTED], not to the list.
Cameron Hutchison wrote to #272066:
> This should do it. It uses the -xtype find(1) predicate. I'm not sure if
> that's GNU only and if so, whether it is allowed in an initscript.
>
> --- /etc/init.d/bootclean.sh 2005-01-05 10:27:40.0 +1100
> +++ /tmp/bootclean.sh 2005-11-22 09:27:46.105703939 +1100
> @@ -90,7 +90,7 @@
>
> [ "$VERBOSE" != no ] && echo -n " /var/run"
> ( cd /var/run && \
> - find . ! -type d ! -name utmp ! -name innd.pid \
> + find . ! -type d ! -xtype d ! -name utmp ! -name innd.pid \
> -exec rm -f -- {} \; )
> rm -f /var/run/.clean
> set -o noclobber
"! -type d" matches everything (including symbolic links) except directories.
"! -xtype d" in the absence of "-L" matches everything except directories
and symbolic links to directories. Thus IIUC the latter eliminates the need
for the former.
I am cc:ing this to debian-devel in order to solicit opinions.
Please reply to [EMAIL PROTECTED], not to the list.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to use lsb init-functions
In trying to convert the initscripts in the "initscripts" package to use the logging functions in /lib/lsb/init-functions I have run into some problems. Currently there are two sets of functions intended to implement the several kinds of messages normally output by Debian and Ubuntu initscripts. The first is for reporting the starting and stopping of services: log_daemon_msg "Foo" "bar" ; log_progress_msg "baz" ; log_end_msg 0 Debian: Foo: bar baz. Ubuntu: * Foo bar [ ok ] The second is for reporting actions to be taken: log_action_msg "Foo" Debian: Foo. Ubuntu: * Foo The third is for reporting actions to be taken and their completion: log_action_begin_msg "Foo" ; log_action_cont_msg "bar" ; log_action_end_msg 0 Debian: Foo...bar...done. Ubuntu: * Foo... * bar... [ ok ] In addition there is a function for reporting success: log_success_msg "Foo" Debian:Foo Ubuntu:* Foo one for reporting failure: log_failure_msg "Foo" Debian:* Foo [asterisk is red] Ubuntu:* Foo [asterisk is red] and a function for warning: log_warning_msg "Foo" Debian:* Foo [asterisk is amber] Ubuntu:* Foo [asterisk is amber] Finally there is a log_begin_msg which seems to be obsolete. Now my question. Suppose I have a script that does something and I want to do the following: * Report that foo will be done * Do foo * Report that foo has now been done I am supposed to do: log_action_begin_msg "Will do foo" foo log_action_end_msg $? But the problem is that foo may produce output and this will break up the nice single-line format. I don't mind deverting stdout to /dev/null, but I am reluctant to divert stderr to /dev/null and error messages will also break up formatting: Debian:Foo...ERROR failed. [in red] Ubuntu:* Foo... ERROR [fail][in red] It seems that in many cases we will have to adopt the following schema: log_action_msg "Will do foo" if foo ; then log_success_msg "Done foo." ; else log_failure_msg "Foo failed." ; fi Is this what I should do, or is there another solution I am overlooking; or do we need more functions; or does the whole system need to be reworked? -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Not delete symlinks to directories in /var/run/ ?
[Please forgive the duplicate, but I first sent this with a useless
Subject line.]
debian-devel readers: There is a proposal (#272066) that bootclean.sh's
cleanrun function not delete symlinks under /var/run/ whose targets are
directories. The function already refrains from deleting directories.
Any objections? Please reply to [EMAIL PROTECTED], not to the list.
Cameron Hutchison wrote to #272066:
> This should do it. It uses the -xtype find(1) predicate. I'm not sure if
> that's GNU only and if so, whether it is allowed in an initscript.
>
> --- /etc/init.d/bootclean.sh 2005-01-05 10:27:40.0 +1100
> +++ /tmp/bootclean.sh 2005-11-22 09:27:46.105703939 +1100
> @@ -90,7 +90,7 @@
>
> [ "$VERBOSE" != no ] && echo -n " /var/run"
> ( cd /var/run && \
> - find . ! -type d ! -name utmp ! -name innd.pid \
> + find . ! -type d ! -xtype d ! -name utmp ! -name innd.pid \
> -exec rm -f -- {} \; )
> rm -f /var/run/.clean
> set -o noclobber
"! -type d" matches everything (including symbolic links) except directories.
"! -xtype d" in the absence of "-L" matches everything except directories
and symbolic links to directories. Thus IIUC the latter eliminates the need
for the former.
I am cc:ing this to debian-devel in order to solicit opinions.
Please reply to [EMAIL PROTECTED], not to the list.
--
Thomas Hood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Bug#340428: octave2.9 - lists mailing list as uploader in changelog
Hi > First, what is DOG, I never heard about it. "In the debian/changelog for octave2.9 (and all other packages maintained collectively by the Debian Octave Group, the DOG)" Start of Thread: http://lists.debian.org/debian-devel/2005/11/msg01378.html > Second, I'm a member of the debian-installer team. I never say uploads > with such entries. http://lists.debian.org/debian-devel-changes/2005/11/msg01337.html Regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: texlive-basic_2005-1_i386.changes REJECTED
[I've dropped some CCs...] Norbert Preining wrote: >>What about texlive-bin-base? > As I said, it is true that I can arbitrary hyphens, but there was a > decisison behind these names: Keeping the collections of TeX live (this > is what users see when they use the installer) and the debian packages > namewise in sync. > I have no problem introducing different names, but only if I see good > reasons other than "I like it" or "it is usual like this". To me, the > argument on name-sync collection-debiannames is strong enough to keep > the current names. Well, Debian as a project has effectively standardized (by practice) on the hyphenation that has been suggested all over the place in this thread. Debian users will and should be able to expect a Debian-style package naming. Dismissing comments favoring this hyphenation - in unison - as expressions of personal taste doesn't really reflect the fact that consistency is a quality Debian users look for in packages. If you provide the TeX live names in the long description, people will be able to find stuff by the usual package search functions. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Automatic closing of bugs
Hi Matt,
if that would help, I'd include a (n option that allows to) check via
bts2ldap + the attached script into dput.
That'd be less intrusive than changing the behaviour of Closes:, for
better or worse.
Kind regards
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
#!/usr/bin/python
import sys, rfc822, ldap
from apt_listchanges import ttyconfirm
def parse_changes(changes):
chg_fd = open(changes)
check = chg_fd.read(5)
if check != '-':
chg_fd.seek(0)
else: # found a PGP header, gonna ditch the next 3 lines
chg_fd.readline() # eat the rest of the line
chg_fd.readline() # Hash: SHA1
chg_fd.readline() # empty line
if not chg_fd.readline().find('Format') != -1:
chg_fd.readline()
changes = rfc822.Message(chg_fd)
return changes
ch = parse_changes(sys.argv[1])
closedbugs = map(int, ch.get('Closes','').split())
pkgs = ch.get('Binary','').split()+[ch.get('Source','')]
if closedbugs:
print "Querying ldap..."
l = ldap.open("bts2ldap.debian.net", 10101)
l.simple_bind()
resid = l.search("dc=current,dc=bugs,dc=debian,dc=org",
ldap.SCOPE_SUBTREE,
"(|%s)"%(''.join(map(lambda x: "(debbugsID=%d)"%x, closedbugs))),
["debbugsPackage","debbugsID","debbugsTitle"])
res = []
r = l.result(resid, 0)
while r and r[1]:
res.append(r[1][0][1])
r = l.result(resid, 0)
otherpkgsbugstouched = filter(lambda a: a['debbugsPackage'][0] not in pkgs, res)
if otherpkgsbugstouched:
print 'Changelog closes bugs of other packages:'
print ' '+'\n '.join(map(lambda y:
' '.join(map(lambda x: ' '.join(y[x]),['debbugsID','debbugsPackage','debbugsTitle'])),
otherpkgsbugstouched))
print "Do you want to continue? [y/N]",
if sys.stdin.readline()[1:] not in ['y','Y']:
sys.exit(1)
Re: Automatic closing of bugs
Thomas Viehmann wrote: > if sys.stdin.readline()[1:] not in ['y','Y']: For added utility I might want to improve on that. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ 'What'll we drink to?' Nick asked, holding up the glass. 'Let's drink to testing,' Bill said. 'All right,' Nick said. 'Gentlemen, I give you testing.' 'All testing,' Bill said. 'Everywhere.' 'Testing,' Nick said. 'That's what we drink to.' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
