Bug#1060034: ITP: python-openai -- OpenAI Python API library
> "Mo" == Mo Zhou writes: Mo> On 1/5/24 11:45, Ansgar wrote: >> Then the package should be in main. >> >> We do not require external software to be free as well, be that >> Web APIs provided by Github, Twitter, or the NVidia firmware >> required for Nouveau, microcode or storage/keyboard/sound/printer >> firmware required for Linux, ... We would have to move pretty >> much everything to contrib if that was the case. Mo> OK. It seems that I misunderstood it all the time. Mailed Mo> ftp-master to reject so I can change the section and reupload. Also, I thought that there were several open-source implementations of this API, including from llama.cpp and ctransformers among others. My impression was the OpenAI API had become kind of a standard for gluing something like text-generation-webui to a hosted model not running locally. Or is that some *different* OpenAI API?
Bug#1031634: ITP: gum -- A tool for glamourous shell scripts
> "Antonio" == Antonio Terceiro writes: Antonio> On Wed, Feb 22, 2023 at 09:24:29AM -0700, Scarlett Moore wrote: >> >> On 2/21/23 15:03, Ryan Kavanagh wrote: >> > On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote: >> > > Description : A tool for glamourous shell scripts >> > > >> > > A tool for glamorous shell scripts. Leverage the power of >> Bubbles and > > Lip Gloss in your scripts and aliases without >> writing any Go code! > This long description does not provide >> users with enough information to > understand what the package >> does. What are "Bubbles" and "Lip Gloss" in > a shell script? >> What is a "glamourous shell script"? >> > >> > It would be helpful if the package's long description satisfied >> §3.4.2 > of the Debian Policy Manual [0]: >> > >> > The description field needs to make sense to anyone, even >> people who > have no idea about any of the things the package >> deals with. [3] >> > >> > [...] >> > >> > [3] The blurb that comes with a program in its announcements >> and/or > README files is rarely suitable for use in a >> description. It is > usually aimed at people who are already in >> the community where the > package is used. >> > >> > Best wishes, > Ryan >> > >> > [0] >> https://www.debian.org/doc/debian-policy/ch-binary.html#the-extended-description >> > >> >> The package description will be this or close to it: Antonio> That is just too long, please don't. >> A tool for glamorous shell scripts. Leverage the power of >> Bubbles (https://github.com/charmbracelet/bubbles) and Lip Gloss >> (https://github.com/charmbracelet/lipgloss) in your scripts and >> aliases without writing any Go code! . Tutorial . Gum >> provides highly configurable, ready-to-use utilities to help you >> write useful shell scripts and dotfiles aliases with just a few >> lines of code. Antonio> This last paragraph above looks like a good enough package Antonio> description. Save everything else for an upstream README Antonio> installed on /usr/share/doc/gum/, or some other type of Antonio> documentation. I disagree. I should not have to chase down links to websites to understand a description Please include a phrase or two describing each of bubbles and gloss.
Bug#1029842: ITP: randombytes -- Library generating fresh randomness
> "Jan" == Jan Mojzis writes: Jan> If I understand it correctly, CC0-style public-domain Jan> declaration in debian/copyright solves the problem. (learned Jan> here: Jan> https://lists.debian.org/debian-mentors/2017/09/msg00171.html) I'm not entirely sure I agree with Don, and he was also being short. I agree that a cc0 style declaration made by the original author makes everything fine. I do not think you can make a cc0 style declaration on behalf of someone else. signature.asc Description: PGP signature
Bug#1029842: ITP: randombytes -- Library generating fresh randomness
> "Jan" == Jan Mojzis writes: * Package name: randombytes Version : 20230126 Upstream Author : Daniel J. Bernstein * URL : https://randombytes.cr.yp.to/ * License : Public domain Public domain is problematic as a license. At least under US copyright law, there are very few circumstances when something can actually be public domain. One example is software written by US government employees. But I don't think any of those circumstances apply to this library. So I'm not sure the license is okay. I'll also admit to being skepticle of the utility of such a library given the getrandom() API in libc.
Bug#1024547: ITP: sparrow -- Bitcoin wallet with a focus on privacy and usability
> "Craig" == Craig Raw writes: Craig> I assume the next step is to upload these two files, but I'm Craig> uncertain of where or how to do this. No, probably the next step is to make sure all the dependencies are packaged in Debian and then to generate a Debian format source package that generates debs similar to those. See https://www.debian.org/doc/manuals/maint-guide/ That's probably targeted at packaging software written in C. You probably will want to look at the Debian Java team's pages https://wiki.debian.org/Teams/JavaPackaging for how they do things and of course the developers reference for procedures on things like sponsorship (which you will need since you are not a Debian developer) https://www.debian.org/doc/manuals/developers-reference/
Bug#1024547: ITP: sparrow -- Bitcoin wallet with a focus on privacy and usability
> "craig" == craig writes: craig> Inclusion into the Debian repository is a precursor to craig> inclusion into Tails, which has been broadly requested in the craig> Bitcoin community. Sparrow is already released as a .deb craig> package (see https://sparrowwallet.com/downloads/) as part of craig> the standard release process. I intend to maintain this craig> package going forward. In the past we've had a bit of trouble with bitcoin wallets in Debian when security issues emerged. If this package makes it into Debian stable, will you be able to provide security support for the version in stable without upgrading to new upstream versions for the release lifetime of stable? signature.asc Description: PGP signature
Bug#1020946: ITP: stripe -- Python bindings for the Stripe API
> "Mathias" == Mathias Behrle writes: Mathias> Programming Lang: Python Description : Python bindings for Mathias> the Stripe API Yet no where in your description do you describe what stripe is. I'd recommend that an API description describe what the API is good for. And I should be able to figure that out without going and chasing down your links. Some paragraph like Stripe is a web service that . Think of it this way. If I do a apt-cache search for some important key word related to what the stripe web service is good for, I should find your API package so I can consider whether Stripe solves my problem.
Bug#991859: Is a different opinion about a license a case for the ctte?
[I accidentally sent this as a private reply earlier this morning before Phil's message.] TL;DR: you don't have any recourse that is appropriate for this situation. All the hammers are bigger than your nail. > "Andreas" == Andreas Tille writes: Andreas> Hi folks, before I follow the advise how to refer a Andreas> question to the CTTE[1] I'm wondering whether licensing Andreas> questions are also a topic here. I admit I'm a bit unsure Andreas> whether this minor issue about a license is really worth Andreas> that even more people spent time into it. I'm demotivated Andreas> myself by no progress in something I would consider Andreas> nitpicking about a non-issue. But I would like to use this Andreas> as a general example to know whether CTTE could be of help Andreas> in licensing questions. The secretary ruled that the CT cannover overrule a delegate acting in their delegated responsibility, so no the CT cannot overrule ftpmaster. The CT could give advice to ftpmaster, especially if ftpmaster requested that advice. I'd expect the CT would be reluctant to give non-technical advice. The CT could set *technical policy* and I'd expect delegates would generally be expected to follow reasonable technical policy established by the CT or be accountable to the DPL and membership at large. However, I don't really think that license standards are technical enough to be technical policy. ftpmaster could establish an appeals procedure. The DPL could establish another set of delegates for setting license policy and separate that out from the ftpmaster delegation. I.E. someone sets license policy, and ftpmaster interprets it. That said, some questions could not be separated. In particular, because of liability concerns, if ftpmaster believes something is not redistributable, it would be highly inappropriate to ask them to redistribute it in the current Debian liability model. Any of this could be handled by a GR.
Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.
> "Stephan" == Stephan Verbücheln writes: Stephan> As far as I understand it, the main point of BabaSSL is to Stephan> add support for Chinese developed ciphers and algorithms. It looked like there were two main points. The first was in fact these ciphers. I don't think that's a good reason for including in Debian because it looks like OpenSSL is interested in adding these ciphers long-term, and that appears a much better strategy for us as a ddistribution. However there are some other features from the ITP: -Support NTLS (formal GM dual-certificate protocol) handshake processing, according to GB/T 38636-2020 TLCP -QUIC API support -Support delegated credentials, according to draft-ietf-tls-subcerts-10 I don't recognize NTLS and presumably since draft-ietf-tls-subcerts is a working group draft it will be possible to get into OpenSSL eventually.
Bug#994458: ITP: anymarkup -- Parse or serialize any markup format in Python
> "John" == John Paul Adrian Glaubitz writes: Description : Parse or serialize any John> markup format in Python John> Parse or serialize any markup. Currently supports INI, JSON, John> JSON5, TOML, XML and YAML. I'd find it helpful if the description were improved to indicate that this is for object serialization languages. When I ran across the one line description I was expecting html, markdown, rest--a pandoc competitor of some kind. --Sam
Bug#974678: ITP: openh264 -- H.264 encoding and decoding
> "Bastian" == Bastian Germann writes: Bastian> There are H.264 patents that are applicable. I do not know Bastian> how the existing H.264 implementations in Debian handle Bastian> this, e.g. x264 or ffmpeg. According to the legal FAQ, Bastian> these seem to be ignored. I suspect you meant to say that there are H.264 patents that may be applicable and that Debian should evaluate this risk using its normal proocesses and policies for looking at software patents. THOSE PROCESSES DO NOT INVOLVE debian-legal. Discussing patents in a public forum may result in speculative communication--like the assertion above where you said that patents are applicable and where you probably meant to say that the patents may be applicable--being produced in response to allegations of patent infringement. That harms Debian. Thus, we have a policy that we discuss patents only in privileged communication. See https://www.debian.org/legal/patent and if you are concerned about a specific patent risk, write to pate...@debian.org. signature.asc Description: PGP signature
Bug#989085: ITP: gamescope -- micro-compositor for games
> "Stephan" == Stephan Lachnit writes: Stephan> BSD-2-Clause Programming Lang: C Description : Stephan> micro-compositor for games Stephan> Will maintain in Games team. Stephan> Description on GitHub: Stephan> In an embedded session usecase, gamescope does the same Stephan> thing as steamcompmgr, but with less extra copies and Stephan> latency: That description isn't good enough that I can tell what this is without going and doing a bunch of additional research. I'd recommend improving significantly so someone can tell from the package description whether they want the package.
Bug#953378: enough conflict
> "Melanie" == Melanie Frost writes: Melanie> The volunteer was elected as a community representative and Melanie> he's been hounded ever since. It looks like he asked Melanie> people to stop these games, he resigned and he was still Melanie> chased. The issue is that Daniel is still chasing us. In this specific instance, I responded because Daniel filed an ITP. If Daniel resigned and stopped interacting with the Debian community, we would be a lot happier, and I would not have chosen to respond this way. The primary issue from Debian's side is that Debian has asked someone to leave--to stop interacting. And yet they are still interacting by doing things like filing ITPs. We are not chasing anyone. We are responding and reacting to being chased on websites like debian.community, in our own BTS, and in other fora. We are responding to being chased by having messages bcc'd to large numbers of our contributors even after we have banned someone from posting to our lists. In some cases, this has been done by Daniel. In other cases this has been done by people using anonymous accounts using techniques that are very similar to techniques described on a website run by Daniel. We reject these forms of interaction. If it were not for these forms of interaction, we would be much less vocal/much less interested in making public statements. --Sam
Bug#953378: Retitling to RFP
control: retitle -1 RFP: rake_nltk -- RAKE implemented in Python for nltk control: noowner -1 Dear Daniel: As you are aware, you have been expelled from the project as a Debian Developer and then later removed from the Debian Maintainer keyring in response to ongoing concerns with your behavior. For these reasons, it is not appropriate for you to maintain packages. As Project Leader with concurrence of two members of the ftpmaster team, I confirm that Debian does not welcome you as a package maintainer. I request that anyone maintaining a package based on packaging you have prepared audit that packaging as if it comes from an external source. Since you cannot be a package maintainer, I am retitling this bug to RFP instead of ITP. Moreover, it is inappropriate for you to describe yourself as a Debian Developer, as you did in your message filing the ITP. Constitution section 3.2 notes that the Project Leader's Delegates (in this case the account managers) may expel developers; in your case this has happened. So, you must not describe yourself that way or represent yourself as speaking on behalf of the Debian Project. Without limitation to other circumstances, this includes when interacting with the Debian community, its members, the BTS, and (without limitation) other aspects of the community. Such misrepresentations are unacceptable behavior in our community. In response to some of the same actions that ultimately ended up in your key being removed from the maintainer's keyring, you were banned from all our lists. I reviewed how to respond to this ITP with members of ftpmaster, members of the account manager team and members of the community team. As part of that discussion, the question came up as to whether you were welcome at all in our community. With the concurrence of members of the account managers, ftpmaster, and community team, I conclude that you are not welcome in the Debian Project. Please stop all interactions with our lists, our BTS, our forums, salsa.debian.org, and any other Debian Project communications channels. Allowing your activity and presence in our community would only support behavior that is not welcome in our community--behavior that you have declined to stop despite multiple requests from multiple parties over an extended period of time. As a general rule, the project avoids discussing expulsions in public. However, your choice to represent yourself as a Debian Developer and to attempt to act as a Debian Developer after you have been expelled put the project in a position where we have chosen to make an exception to that general rule so that our community can understand the situation and understand that we do value acting to make Debian a place where people can work free from disruption or harassment. Sam Hartman Debian Project Leader signature.asc Description: PGP signature
Bug#951710: ITP: microsoft-authentication-extensions-for-python -- Microsoft Authentication extensions for MSAL for Python
The description should describe what MSAL is.
Bug#951539: ITP: bruteforce-wallet -- Try to find a password of a encrypted wallet file
Might I suggest that wallet is kind of generic and I'm aware of a number of different tools out there that claim to be wallets of various kinds. I think the description should do a better job of scoping which wallets this is good for.
Bug#942132: ITP: python-nest-asyncio -- Patch asyncio to allow nested event loops
> "Diego" == Diego M Rodriguez writes: Diego> nested. This presents a practical problem: When in an Diego> environment where the event loop is already running it's Diego> impossible to run tasks and wait for the result. The above description should be improved. Because it's fairly easy to run a task and wait for the result: await coroutine_or_task will run a coroutine or task and await the result within any async function. You perhaps mean that it is difficult for non-asynchronous code to run tasks and wait for the result. If so, please say that. --Sam
Bug#941708: ITP: nextcloud-server -- Nextcloud folder synchronization tool (server)
I think that nextcloud-server-installer would be a better package name. Also, presumably you are targeting the contrib section rather than the main section. How would you feel about an actual packaging of the server (rather than an installer) that used fastrack.debian.net? Fastrack is intended to handle products where the security lifecycle is too short for Debian releases. --Sam
Bug#922952: ITP: simdjson -- Parsing gigabytes of JSON per second
I don't know about official policy, but I think you could make your bug not RC by detecting whether the current system can support the package in some reasonable wail and failing more gracefully than with SIGILL. It's not a requirement that all packages work on all systems. Open-vm-tools doesn't do squat if you aren't running on top of vmware; pcscd is remarkably useless without a smartcard reader; etc. I think it ought to be fine to have a package that is only useful with some given hardware provided that you're reasonable about detecting requirements, and that you don't place stronger requirements than are actulaly needed by your package. --Sam
Bug#835086: RFP: nextcloud -- self-hosted cloud services
> "Xavier" == Xavier Bestel writes: Xavier> Le mardi 20 septembre 2016 à 19:38 +0200, Moritz Mühlenhoff Xavier> a écrit : >> On Mon, Aug 22, 2016 at 12:02:59PM +0200, Xavier Bestel wrote: >> > >> > Package: wnpp > Severity: wishlist >> > >> > * Package name: nextcloud Xavier> [...] >> > Given that Nextcloud is an Owncloud fork, with the same people >> > behind it, and that Owncloud upstream has always had a >> difficult > relationship with distro maintainers, there may be >> problems for > packaging that correctly. > But Nextcloud is >> still a highly relevant package for Debian. >> >> Nack. It's not an important package if we can't support it >> properly. Let's not repeat the owncloud disaster. Xavier> OK, I understand the "official" debian point of view. I don't think this is an official Debian POV, simply the opinion of some Debian contributors... Well, I think it is the official Debian POV that in order to include a package, we need to be able to support it. Whether we will or will not be able to support nextcloud is up to interpretation. >From a user standpoint, having something that has the functionality of opencloud/nextcloud is quite important in the enterprise space. However, we do need to be able to get things to work. --Sam
Bug#595817: pam-ssh-agen-auth deb package
I have not looked at the specifics of this package. I know that I want something that has a similar user interface for sudo. I have no idea though whether this implementation is any good and don't have time to investigate.
Bug#761868: ITP: moonshot-gss-eap -- A GSS-API Mechanism for the Extensible Authentication Protocol
package: wnpp severity: wishlist owner: hartm...@debian.org x-debbugs-cc: debian-de...@lists.debian.org source: git://git.project-moonshot.org/mech_eap.git license: BSD-3-Clause Description: Project moonshot provides federated access to a wide range of applications. This package adds a GSS-API mechanism supporting EAP authentication and provides the core of Moonshot authentication and authorization. This package provides federated access for applications such as Ssh, NFS, LDAP and IMAP. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/tslioknlpax@mit.edu
Bug#760411: ITP: moonshot-ui -- Project Moonshot Identity Manager
package: wnpp severity: wishlist owner: hartm...@debian.org URL: http://www.project-moonshot.org/ source: git://git.project-moonshot.org/moonshot-ui.git license: BSD-3-Clause Description: This package manages the Moonshot identity store, permitting users to add and remove identities as well as to select which identity is used ith a given service. --Sam -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/tslppfc1pxm@mit.edu
Bug#759511: ITP: moonshot-ui -Project Moonshot's Identity Selector
package: wnpp owner: hartm...@debian.org severity: wishlist URL: http://www.project-moonshot.org/ source: git://git.project-moonshot.org/moonshot-ui.git License: BSD-three-clause Description: Project Moonshot provides federated access to services combining the best of EAP, RADIUS (over TLS), SAML and GSS-API. This component provides software to manage the local identity store and pick which identity is used for a given service. --Sam pgpSKo0Ub4N6R.pgp Description: PGP signature
Bug#759398: ITP: trust-router - Dynamically configure Trust Between RADIUS Realms
package: wnpp severity: wishlist owner: hartm...@debian.org URL: git://git.project-moonshot.org/trust_router.git http://www.project-moonshot.org/ license: bsd-3-clause Description: The trust router establishes a DH key between two RADIUS servers to protect a RADIUS over TLS session. GSS-API authentication is used between to securely establish this key. The trust router provides a trusted-third-party to manage connections between RADIUS realms and to provide information constraining what connections are permitted. The trust router is used to connect Moonshot Service providers to Identity Providers. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/tsl8umaolmv@mit.edu
Bug#759159: ITP: shibboleth-resolver - Library to access the Shibboleth Attribute Resolver from Third-Party Applications
package: wnpp severity: wishlist owner: hartm...@debian.org URL: http://www.shibboleth.org/ Source: svn https://svn.shibboleth.net/extensions/cpp-sp-resolver/trunk Description: Shibboleth library to access Attribute Resolver The Shibboleth Service provider consumes information about an authenticated user from SAML and GSS-API , providing services such as attribute mapping, authorization, and attribute resolution. This extension permits a third-party application to access resolved attributes. License: Apache 2.0 I'm packaging this because it is a dependency of the Moonshot GSS-API mechanism, an implementation of RFC 7055 (EAP for GSS-API). Current work can be seen at git://git.project-moonshot.org/shibboleth/resolver.git -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/tsl4mx134ua@mit.edu
Bug#732562: Do you need any help getting prpltwtr into debian?
Hi. I'd kind of like to be using this plugin, but it's not in Debian. It looks like it has packaging. Anything I can do to help? --sam -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/tslvbuzkv9q@mit.edu
Bug#647742: update
libradsec 0.0.5 seems stable enough to include in Debian. I have packaging available at git://git.project-moonshot.org/libradsec.git on the debian branch. I want to get a review of a few things and will upload. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/tslk3c7ehmn@mit.edu
Bug#738850: ITP: iniparser -- a stand-alone INI file reading/writing library
The krb5 libraries include read and write support for the krb5.conf format, which is very similar but not identical to ini. I would be entirely happy with the response that: 1) the krb5 profile library should be used only for modifying Kerberos configs 2) supporting the ABI that your application expects is worth having multiple libraries in debian that can do the same thing. Also, libconfuse seems to read ini files. I don't know if it can write them. This message is random information; it is *not* an objection to packaging of iniparser. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/tslmwhukb4a@mit.edu
Bug#647742: libradsec: changing back from ITP to RFP
retitle 647742 ITP: libradsec -- RADIUS over TLS/DTLS/UDP/TCP library owner 647742 ! thanks Lucas, thanks for the prod. my apologies for not keeping the bug updated. The current packaging status of libradsec can be found at git://git.project-moonshot.org/libradsec.git in the debian and libradsec branches. There are several reasons I have not uploaded: 1) Upstream has just gotten to a point where they think things might be stable enough 2) There were some pending ABI changes that just got merged upstream 3) The Debian packages do not include some security enhancements that would be required for release 4) The Debian packages have been available for that time to those libradsec users testing with Debian in a private repo. I totally agree I should have kept the ITP bug up to date. Also, if any user wants me to accelerate getting this into Debian, please write here and I'm happy to do that. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/tsl1u8sh4rv@mit.edu
Bug#647740: ITP: libvertfo - library abstracting event loop interfaces
OK, so I had not looked at what this does on win32. I think any criticism you have of the libverto win32 interface is probably valid. Fortunately I don't think that's being used. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/tslwrbdkwr9@mit.edu
Bug#647742: ITP: libradsec - RADIUS over TLS/DTLS/UDP/TCP library
> "Faidon" == Faidon Liambotis writes: Faidon> Hi Sam, Hope you're well. Faidon> Are you planning on putting the packaging efforts for this Faidon> on git somewhere (e.g. collab-maint?). If so, I'd be happy Faidon> to contribute, if help is needed, either now or when the Faidon> merging effort with radsecproxy starts. Packaging is on the debian branch of http://www.project-moonshot.org/git/radsecproxy.git I'm certainly happy to give you a git account there. I suspect once we fix the remaining security issues for the moonshot gss mechanism we'll probably be using moonshot authentication for our moonshot work. I'd rather not have to use both Alioth credentials and whatever Moonshot credentials we end up with in the same project so I'd probably want a compelling reason before moving the debian packaging to a different place than the rest of the moonshot sources. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/tslehxmnxz9@mit.edu
Bug#647740: ITP: libvertfo - library abstracting event loop interfaces
package: wnpp severity: wishlist URL: https://fedorahosted.org/libverto/ Description: libverto provides a common interface on top of libev, libevent, glib, tevent. The goal is to allow development of asynchronous libraries that will work with whatever event loop an application happens to be using Features include automatic detection of which event loops are in a particular process space and support for writing new event loop modules. License: * Copyright 2011 Red Hat, Inc. * * Permission is hereby granted, free of charge, to any person * obtaining a copy of this software and associated documentation files * (the "Software"), to deal in the Software without restriction, * including without limitation the rights to use, copy, modify, merge, * publish, distribute, sublicense, and/or sell copies of the Software, * and to permit persons to whom the Software is furnished to do so, * subject to the following conditions: * * The above copyright notice and this permission notice shall be * included in all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE * SOFTWARE. I'm packaging this because it's a dependency for MIT Kerberos 1.10. It's kind of annoying but libverto has not yet been released so I'll probably end up packaging a git snapshot. I'll prod upstream and see if a release can be caused to happen. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2005173408.0b7a14...@carter-zimmerman.suchdamage.org
Bug#647742: ITP: libradsec - RADIUS over TLS/DTLS/UDP/TCP library
package: wnpp severity: wishlist URL: libradsec branch of http://www.project-moonshot.org/gitweb/radsecproxy.git URL2: http://software.uninett.no/radsecproxy/ Description: libradsec is a library for RADIUS clients and servers This library features support for RADSEC (RADIUS over TLS/DTLS) as well as TCP and UDP transports. License: The following license is a bit misleading because there are GPL dependencies. So effectively libradsec is distributed under GPL2+. However, the intent is to remove the GPL dependencies in the near future and so the license will look more like The source code is licensed under two different licenses, a 3-clause BSD license and the GNU General Public License (version 2 or later). Users of this library may choose which of these suits them best. I'm packaging libradsec because Moonshot (http://www.project-moonshot.org/) depends on it. It has not been formally released yet. It's sort of related to radsecproxy that is already in Debian in that eventually, libradsec may be used as a library by radsecproxy. At that point it might make sense for the libradsec and radsecproxy source packages to be combined. Today, although they come from the same git repository, they come from different branches and different places in the directory tree. There are a couple of header files in common. I cannot upload libradsec to unstable until libevent 2.x makes its way into unstable. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2005174338.dec664...@carter-zimmerman.suchdamage.org
Bug#566346: ITP: krb5-appl - Kerberos applications and clients
package: wnpp severity: wishlist owner: hartm...@debian.org name: krb5-appl URL: http://web.mit.edu/kerberos/dist/krb5-appl License: MIT Kerberos license (roughly MIT license plus a requirement that if you modify the software you must mark it as modified) description: Contains fairly ancient versions of telnetd, ftpd, rsh and rlogin that support Kerberos authentication Up until the upcoming Kerberos 1.8 release, these applications were part of the main krb5 tree. They are kind of old and crufty, but attempts to kill them off have met with users (and Debian users) who say they are still valuable in certain environments. Reasons cited include that the code base is simpler than things like ssh, it works and is in use, etc. My belief that the security of the rsh and rlogin programs is quite good, although the telnet and telnetd are well below current security standards. However upstream krb5 doesn't want to maintain the applicatinos as part of the main source tree. So, they are being split out. Since Debian users still want them, I'm going to package them. They've been in Debian for years already, so I think this should not be a problem. To look at the WIP packages see git://git.debian.org/git/pkg-k5-afs/debian-krb5-appl.git pgpRQTHS9XpyD.pgp Description: PGP signature
Bug#516750: ITP: rsplib -- Implementation of the IETF's Reliable Server Pooling (RSerPool) standard defined in RFCs 5351 to 5356.
This is a nit, but it' seems inappropriate to refer to rsrvpool as a standard in your package description. These RFCs were published as experimental because of serious concerns raised at the IESG level. It would be better to describe it as the reliable server pool experiment or protocol rather than standard. --Sam -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#483382: ITP: barnowl -- curses based jabber, zephyr and IRC client
package: wnpp severity: wishlist Barnowl can be obtained from http://barnowl.mit.edu/. It is a fork of owl, which is already in Debian. Barnowl adds Jabber and IRc support and fixes many bugs providing a new extensibility architecture. I've discussed my plans to package barnowl with the Owl maintainer (Mark Eichin). he supports barnowl being packaged for Debian. At some future point it may be desirable to remove owl. Today though we both believe that would be a big transition for the owl community The main body of barnowl is distributed under the following license: From owl.c: /* Copyright (c) 2004 James Kretchmar. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are * met: * ** Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * ** Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in * the documentation and/or other materials provided with the * distribution. * ** Redistributions in any form must be accompanied by information on * how to obtain complete source code for the Owl software and any * accompanying software that uses the Owl software. The source code * must either be included in the distribution or be available for no * more than the cost of distribution plus a nominal fee, and must be * freely redistributable under reasonable conditions. For an * executable file, complete source code means the source code for * all modules it contains. It does not include source code for * modules or files that typically accompany the major components of * the operating system on which the executable file runs. * * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED * WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR * NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN * IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ In addition, barnowl includes a modified copy of XML::Stream , Net::Jabber and Net::XMPP. They are distributed under the LGPL. pgpkMZFAUiVj6.pgp Description: PGP signature
Bug#242251: ITP: user-friendly -- automatic helper to "manage Debian"
How do you plan to give more permissions to local users?
Bug#68243: Progress of packaging linphone
I'd like to use this program and was just wondering what problems/progress you had made with this ITP.
Bug#156287: Advice on Drip (ITP #156287)
I continue to believe that like other packages already in Debian, supporting libdvdcss if it is found is perfectly reasonable. If you manage to dlopen it and find the right symbols, use it. If someone complains, we can reevaluate the situation at that point.
Bug#142065: ITP: cyrus2-sasl-mit - MIT Kerberos modules for sasl2
package: wnpp severity: wishlist I'm planning on packaging libsasl2-gssapi-mit, a version of the GSSAPI plugin for libsasl2 compiled against MIT Kerberos. This package has the same source as cyrus-sasl2, but different build environment and options. It's not really possible to avoid having two source packages, even given crypto-in-main. This is the same setup we have for libsasl7 for all the same reasons. I sent the SASL maintainer mail a while back and received no objection. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#128888: ITP: ssh-krb5 - A version of OpenSSH patched to support Kerberos Authentication
package: wnpp severity: wishlist Hi. AS discussed below, I intend to package OpenSSH using the current Debian sources with patches to allow krb5 authentication. I will use the patches available at http://www.sxw.org.uk/computing/patches/openssh.html. These patches attempt to comply with draft-ietf-secsh-gss-keyex along with some of the more common other types of Kerberos authentication. The Kerberos packaging will follow guidelines agreed on by Debian kerberos package maintainers and included in /usr/share/doc/krb5-config/packaging-guidelines.txt.gz. The package will likely build withe either Heimdal or MIT Kerberos, although the version uploaded to non-us will be compiled against MIT Kerberos. Below is previous discussion on this package attempting to justify the need for yet another ssh package in Debian. --- Begin Message --- Hi. I sent mail to [EMAIL PROTECTED] about tthis a while back. I heard no response. It is my intent to ITP ssh-krb5 as a package at priority extra that conflicts with the existing ssh. I will probably store configuration files in /etc/ssh rather than /etc/ssh-krb5 because I believe that some time after woody releases we will be able to get these changes folded into OpenSSH upstream and then hopefully into the main Debian ssh packages. This is a heads up for the Kerberos and Ssh community in Debian. --- Begin Message --- So I suspect I'm not the only one on this list that would like Kerberized ssh in Debian. However ssh is somewhat of a moving target; here are the things we probably want to support: * The ssh.com sshv1 Kerberos5 protocol (used by MIT among others) * The ssh Kerberos4 protocol (used by CMU and others) (Is this the same as the krb4 in openssh?) * draft-ietf-secsh-gss-keyex (standards track protocol) * The krb5 support in sxw's patches to Openssh 2.5.2 (does anyone use * this? no would be a really really convenient answer) I propose that I talk to the ssh maintainer and get permission to ITP an ssh-krb5 that supports the first three listed protocols.I believe code will exist to do that fairly soon. I'd rather do that than fold in Kerberos support because it is so much of a moving target right now and because it would be asking the ssh maintainer to maintain a lot of third-party patches. Reasonable? ___ Debian-kerberos mailing list [EMAIL PROTECTED] http://mailman.boxedpenguin.com/mailman/listinfo/debian-kerberos --- End Message --- --- End Message ---
Bug#108942: The saga of cyrus2-imapd continues
> "David" == David D Kilzer <[EMAIL PROTECTED]> writes: David> I finally got cyrus2-imapd to authenticate an account, but David> I had to use "sasldb" instead of "PAM" for David> "sasl_pwcheck_method" in /etc/imapd.conf. David> It appears that until PAM-0.74 is available in "unstable", David> cyrus2-imapd won't be able to authenticate using it. I David> thought about filing a "new upstream version" bug against David> libpam0g, but I know there has been some discussion about David> how to handle new versions of PAM in Debian. I just can't David> seem to find the correct mailing list archive or web page David> that describes this. Disbelieve. It can be handled the same way as cyrus 1.x.
Bug#118427: TP: epo -- Miner mode to reduce the labour to edit code
> "Raul" == Raul Miller <[EMAIL PROTECTED]> writes: Raul> On Tue, Nov 06, 2001 at 09:16:19AM -0500, Peter S Galbraith Raul> wrote: >> Raul, why are you so quick to dismiss this? You state it like >> it was a matter of fact. Is this documented anywhere? Raul> I didn't dismiss it. [And, what is it that you want Raul> documentation on?] Raul> Look at the situation this way: the GPL restricts the Raul> distribution of emacs, not that of independently written Raul> code. The question asked was whether it was legal to Raul> distribute some non-gpled elisp code -- and the answer has Raul> to have a lot to do with how closely the code is tied to Raul> gpl'd emacs (gnu emacs vs. xemacs, ferinstance). How is this different distributing a version of ripem (sp?) that required GMP? My understanding is that the FSF argued that the distribution was illegal because it had the effect of distributing an application that violated the GPL, by linking non-GPL code to a GPL library. I believe they objected even to source distributions. For details on this situation check the gnu.misc.discuss archives, I think around 1994.
Bug#108942: ITP: cyrus2-imapd -- CMU Cyrus project mail system, version 2
> "Henrique" == Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: Henrique> Kerberos will not be present in the first versions of Henrique> the package, and unless someone shows up to help test Henrique> it, support may never be included. I'd be happy to help as Kerberos maintainer, however I don't think that the Kerberos support is useful. I'd recommend against using it. It is only authorization support; you use SASL for Kerberos authentication. Actually, you may want to use Kerberos for POP, but we'll take a look at that later, and it might be easier to just not deal. I may send you a patch to the unix authorization stuff to allow usernames including . if that isn't allowed. I've discussed the patch with leg and he indicated he would accept if I sent to him so I would send to both of you at the same time. This is the only issue most people run into with Kerberos.
Bug#108710: ITP: kernel-module-2.4.5-qdio-s390
A more consistent name for the binary package might be qdio-modules-2.4.5. Compare with modules like pcmcia-modules or alsa-modules.
Bug#97300: kerberos-configs going to non-us after all
James said he'd be happier if I uploaded to non-us, so I did.
Bug#97300: ITP: kerberos-configus - package to manage configuration files for multiple Kerberos implementations
package: wnpp severity: wishlist In an attempt to solve bug #80365, I found that we needed infrastructure to manage config files for Kerberos versions 4 and 5. We have two implementations of each version of Kerberos in Debian currently. The can in general share the same config files, so it is desirable not to lose configuration information when removing/purging one implementation for another. Thus, I have authored kerberos-configs, a package to manage the config files. There is a version available (referenced within the bug) that supports krb5. The krb4 support will be added once krb5 support is finalized. I will coordinate with the other maintainers of Kerberos implementations to upload this package. It's getting to a point where it is worth ITping the package, so I can upload once coordination is complete. The package is released under the GPL, so it should be fine for non-us.
Bug#92353: I might be able to give PAM a good home
retitle 92353 ITA: pam -- Pluggable Authentication Modules thanks Hi. I believe I could probably give PAM a good home. I'm a new Debian developer--only joined the project in December. However, I have significant free software experience going back to work on Kerberos starting in 1994. Most of my interest is in security software and in making security/single sign on/system administration easier. My company, Mekinok (http://www.mekinok.com/) hopes to work on various free-software IT infrastructure projects. Making sure PAM works within Debian is certainly something we care about and is something I could spend time working on. I'm fairly familiar with PAM; I maintain two pam modules already (libpam-krb5 and libpam-openafs-session) and am fairly familiar with how it works. I'm not a PAM developer; if someone else has inside connections both with PAM and with Debian they might be better than I. However, I'm a good designer, I have a good feel for packaging and integration issues both within Debian and with other OSes, so I'd likely make a good maintainer. The main issue I'm concerned about is dbs. I don't have much experience with it. I understand the idea, but it seems like it is hard to manage dbs while also trying to do revision control on my changes. I'm much more used to using cvs-buildpackage. However, I recognize that dbs provides better tracking of the separation of Debian changes from the upstream sources. I'll give using it a fair chance and learn to either like or hate it from an informed standpoint. If I decide I don't like it, I will only change after I'm firmly certain that I've given it a good chance and that I'm doing a good job mainting the PAM package and would like to continue. Making significant changes to the package and then orphaning it is not something I will do.
Bug#92043: ITP: libsasl-nonus-mit -SASL crypto plugins compiled against MIT Kerberos
package: wnpp severity: wishlist Hi. I will be packaging a version of the Cyrus SASL library that will build libsasl-gssapi-mit and libsasl-krb4-mit for non-us. These will be Kerberos SASL modules built against MIT Kerberos instead of Heimdal. I have talked to the current libsasl-modules-nonus maintainer, and he is aware of this and we have discussed how to handle the naming issues. The GSSAPI plugins are mostly interoperable between MIT and Heimdal, although some versions of Heimdal do not currently support the 3DES GSSAPI that MIT has been shipping.