Bug#545480: ITP: libnet-epp-perl -- EPP XML frame system built on top of XML::LibXML
Peter Pentchev wrote: > As of writing, its only > well-developed application is the provisioning of Internet domain names, > hosts, and related contact details. What about Net::DRI? Never used but heard good words about it. Regards, Faidon -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511036: ttf-droid, sponsorship?
Hi, There is an ITP bug for the droid fonts since January, but unfortunately noone has taken a step and upload them yet. However, I'm seeing that you're maintaining them in Ubuntu? Are you still interested in having them in Debian? If so, I can sponsor your uploads and perhaps you could also join the Debian Fonts packaging team (of which I am part of). If not, please say so, so someone else can go ahead and take over this ITP. If you don't reply within the next two weeks and time permits, I'll do an upload and you can join me or take over maintainership later. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545480: ITP: libnet-epp-perl -- EPP XML frame system built on top of XML::LibXML
Peter Pentchev wrote: > On Wed, Sep 09, 2009 at 04:41:59AM +0300, Faidon Liambotis wrote: >> Peter Pentchev wrote: >>> As of writing, its only >>> well-developed application is the provisioning of Internet domain names, >>> hosts, and related contact details. >> What about Net::DRI? Never used but heard good words about it. > > Well, I've never used Net::DRI either, although it looks good. > Still, I think there would be no harm in also having Net::EPP in > Debian, since it is useful in its own right - easy to use, quite > customizable, usable for lots of EPP-compatible registrars with > only small registrar-specific changes. At $REALJOB, we've been > using it internally for EURid for quite some time now, with only > a simple change of an XML element's namespace to make it work. > > Of course, if the community feels that it is redundant, I can > always maintain it myself outside of Debian, no worries :) Oh, you misunderstood, I wasn't suggesting to not include it in Debian; I was just wondering how the two packages relate or compare with each other. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511036: ttf-droid
Simon, hi, si...@ochsenreither.de wrote: > sincere apologies to you Faidon and everyone else waiting for that > package for already too long. > > I could need some guidance getting the package into Debian, but I'm > willing to work on it and join the font packaging team. You could join the Debian Fonts Task Force. The teams URL is http://pkg-fonts.alioth.debian.org/ Just send an e-mail to the mailing list introducing yourself and join the Alioth project. I am just a member of the team; Nicolas (Spalinger) is a project admin and will probably accept you as a team member. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#466391: Vodafone Mobile Connect Card for Debian
Pablo, hi, I found a piece of software that you apparently authored and "Debianized", Vodafone Mobile Connect Card Driver for Linux. I am a Debian Developer and I am interested in having this in Debian. That will mean that it will eventually get propagated to Ubuntu, which I've seen that you use and care about. I'll soon feed you with packaging patches :) Concerning the branding though, two issues worry me: a) By calling this "Vodafone Mobile Connect", users may get misleaded that this only works with the Vodafone network, something that is apparently not true. b) More importantly, Vodafone is a registered trademark; possibly "Vodafone Mobile Connect" too. Do we have permission from Vodafone to use this trademark for the package uploaded to the Debian distribution which may have changes compared to the version published by you? We've been bitten by this in the past (with the notable example of Mozilla products) and I'm trying to be careful. I've been thinking renaming this to a more common name but I'm afraid that will be a disrespect to your work and Vodafone Group's intentions. I'd be happy to cooperate with you privately or in public. Please note when replying that I'm Ccing Debian bug #466391 [1], which is a Request for Package (RFP) bug by a Debian user. Thanks, Faidon 1: http://bugs.debian.org/466391 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469397: ITP: xbmc -- XBox Media Center Linux Port
Matthew Johnson wrote: Description: XBox Media Center Linux Port A media center originally written for the XBox and then ported to linux. I intend to upload this to experimental to start with. The linux port of it is just that. It's also designed for installation to a single directory, not installation on a unix system. I'll need to hack round that first. The version number is a CVS snapshot. I need to improve the long description before uploading. First of all, you surely must mean SVN and you should use a version number like 0.0~svn20080302, i.e. MMDD or else I'd expect an epoch pretty soon :) I've had a look at this and even made it to successfully work on my machine. I reported some issues back to upstream (e.g. incompatibility with libmms 0.4) and told them that I was interested on bringing this to Debian. I also mentioned the FHS issue which is an obvious blocker for Debian inclusion. I've had only negative comments; they apparently don't care about inclusion in Debian or Ubuntu (which is their platform of preference) and they just want to be able to release a liveCD that works. The FHS proposal was thought to be "too much trouble for little gain" and potentially harming the MacOSX port which is also under development. I had a look at the code and it's a mess, because of the XDK/Windows heritage, e.g. there are conversions between Windows paths (H:\) and Linux ones (/opt/xbmc). ...and that's why I never filed an ITP and still don't regret that choice. All in all, good luck with that ;-) You should expect some heavy upstream patching and a potentially unfriendly upstream. But I'd really like to see this packaged. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439993: ITP: libapache2-mod-pubcookie -- apache2 module supporting Pubcookie
Hi, What are you plans about this ITP? It's been open for some time now. I've done some preliminary work on packaging upstream and will probably finish it really soon, since I need to deploy it for a work-related project. If you have prepared something, contact me to arrange comaintainance and/or sponsorship. If you haven't, I'll handle the whole thing, if you agree. Thanks, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439993: ITP: libapache2-mod-pubcookie -- apache2 module supporting Pubcookie
Peter Woodman wrote: Yeah, I submitted that quite some time ago and then the idea got buried. I've just recently completed repackaging of this and just deployed it to some machines last friday.. I've switched to using git-buildpackage, and can stick it online by day's end, but seeing that you're a debian developer, you'll probably have a much easier time getting it included.. Being a DD will make it easier for me to upload the package. *Which* package will that be is a completely different story. I'd be happy either base my work on top of yours, or (even better) review your work and upload it, letting you handle the maintainership of the package. So, by all means, please "stick it online" :) Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475116: ITP: asterisk-espeak -- eSpeak text-to-speech module for Asterisk
Andrew Pollock wrote: * Package name: asterisk-espeak Version : 0.4 Upstream Author : Francois Aucamp <[EMAIL PROTECTED]> * URL : https://sourceforge.net/projects/asterisk-espeak * License : GPL Programming Lang: C Description : eSpeak text-to-speech module for Asterisk This package provides the "eSpeak" dialplan application, which allows you to use the eSpeak TTS Engine with Asterisk. Would you like to join the Debian VoIP team[1] and maintain this as part of the team? Regards, Faidon 1: http://pkg-voip.alioth.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#513003: #513003 - progress?
Serafeim Zanikolas wrote: > The package is ready but my sponsor has been busy. Also, it appears that > pdfshuffler creates predictably-named temporary files, which might be a > blocker (I've notified upstream, but it's not fixed yet). (I'm the afforementioned sponsor that's been busy, sorry for that: -) It is certainly a blocker, since it has security consequences; Serafeim, perhaps you could modify it yourself (in coordination with upstream, if that's possible)? Thanks, Faidon -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532481: ITP: radsecproxy -- RADIUS protocol proxy supporting RadSec
Package: wnpp Severity: wishlist Owner: Faidon Liambotis Package name: radsecproxy Version : 1.3 Upstream Author : Stig Venaas URL : http://software.uninett.no/radsecproxy/ License : Dual BSD/GPL (without OpenSSL exception) Programming Lang: C Description : RADIUS protocol proxy supporting RadSec A generic RADIUS proxy that in addition to usual RADIUS UDP transport also supports TLS (RadSec). It aims to be flexible while at the same time small in size and memory footprint, efficient and easy to configure. . It can be useful as a proxy on site boundaries or in other complex RADIUS routing topologies. It supports both IPv4 and IPv6. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#392333: ITP: irrtoolset -- policy analysis tools to operate with routing policies in RPSL format
I'm ressurecting this, since upstream created a "cruft-removal" branch (that apparently is going to be released as 5.0) removing old cruft, automatically generated code and the such. I'm hoping that copyright extraction would be much easier with this, much more limited, tree but that remains to be seen. (and yes, we actually use it at GRnet, AS5408, and we actually have a complex enough RPSL; feel free to look it up at RIPE) Regards, Faidon -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#392333: AW: [Fwd: ITP: irrtoolset -- policy analysis tools to operate with routing policies in RPSL format]
On Fri, Jun 19, 2009 at 07:07:07PM +0200, Jan Wagner wrote: > I did follow the mailinglist and recognised it. If you haven't any > objections, we could propable maintain the package together. My rcs for the > package is available at https://trac.cyconet.org/svn/debian/irrtoolset/ Err, too late :( I've already created my own set of packages from scratch, unaware of the state of yours. Actually, debian/rules it's just 4 lines with debhelper 7 & dh :-) Thanks anyway, Faidon -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537110: ITP: libdap -- A C++ SDK contains an implementation of DAP 2.0 and 3.1, Client- and Server-side support classes and a prototype implementation of the AIS
Youhei SASAKI wrote: > Package: wnpp > Owner: Youhei SASAKI > Severity: wishlist > > * Package name: libdap > Version : 3.8.2 > Upstream Author : The University of Rhode Island and The Massachusetts > Institute of Technology > * URL or Web page : http://opendap.org/download/libdap++.html > * License : GNU Lesser GPL 2.1 > Description : A C++ SDK contains an implementation of DAP 2.0 and 3.1, > Client- and Server-side support classes and a prototype implementation of the > AIS > Programing Lang : C, C++, Fortran > > A C++ SDK contains an implementation of DAP 2.0 and 3.1, Client- and > Server-side support classes and a prototype implementation of the AIS. > > Upstream published new version 3.9.3, but can't build libnc-dap[1] > using libdap ver. 3.9.3. So I ITP libdap ver.3.8.2 Could you include a brief description of DAP and AIS? Reading this description made absolutely no sense to me. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#494928: ITP: sflphone -- SIP and IAX2 compatible VoIP phone
Francois Marier wrote: > SFLphone is a SIP/IAX2 compatible softphone for Linux. The SFLphone project's > goal is to > create a robust enterprise-class desktop phone. While it can serve home users > very well, > it is designed with a hundred-calls-a-day receptionist in mind. > > It features a flexible client/server architecture where the GTK client talks > to the daemon > through DBus and is capable of handling multiple VoIP connections at once. You're welcome to join the VoIP team[1] to maintain SFLphone and/or the other packages that the team maintains. You can contact us either via mail or IRC (#debian-voip on OFTC). Thanks, Faidon 1: http://alioth.debian.org/projects/pkg-voip/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376347: Voicetronix's vpb-driver
Hello, I am a member of the Debian VoIP packaging team and I'm mainly maintaining Asterisk. While investigating an open wishlist bug report which requests chan_vpb, your name came up: you have apparently ITPed vpb-driver and you have actually successfully Debianized it; I was surprised to see in the upstream tarball a complete debian/ directory written by a DD. So, I'm contacting you seeking for cooperation. I'd very much like to fulfill this wish that a user had and have a more complete package. However, I don't own such a card (and neither anyone else in the team) and this could be hard for us. Your debian/copyright is a bit worrying: you mention non-LGPL (and non-DFSG-free) executables present in vpb-driver. Is that a big part? Can these be stripped and still have a functional -even for some of the cards- driver? I have also found that opal (maintained by the team; primarily Kilian Krause) provides vpbapi.h -- I'm not sure why to be honest. Would you be interested in cooperating? Joining pkg-voip and importing your work in the SVN repository would be the first step (uploading to Debian will be the second I guess :). Plus, assuming that you have such a card, I would be glad to have you as a guinea pig for Asterisk packages with chan_vpb enabled. What do you think? Best regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445866: ITP: perforce -- closed source revision control system
Daniel Jacobowitz wrote: > On Mon, Oct 08, 2007 at 03:41:21PM -0400, Roberto C. S?nchez wrote: >> Given the great abundance of revision control systems already packaged >> for Debian, what is the point of adding another? Especially when it is >> non-free. > > How about "people use it"? There's plenty of installations of > perforce; I think making it easier to use Debian with them is > within the mandate for non-free. I'd say upload only the client to non-free. We should provide users a way to use their existent preforce servers but we should not encourage new installations of perforce. Sounds like a compromise to me :) Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446028: ITP: tg3dfsg -- firmware free Broadcom Tigon3 network driver
Robert Edmonds wrote: > Any modification to the tg3 driver to produce a GR 2006-004 compliant > driver would have to diverge from the kernel team's patch acceptance > guidelines[0] since upstream is intransigent[1] on making tg3 > firmware-free or firmware-optional. The kernel team does not appear to > be interested in maintaining such a driver, and it appears future linux > kernel source packages will be patched[2] to simply remove the blobs of > firmware (I don't know why the driver isn't simply removed entirely > since the result does not compile). This seems totally inappropriate. If the driver includes non-free firmwares these should be removed or split up from the driver source, not remove the driver entirely. If what you say is right, the driver *works* for most of the hardware without non-free blobs. Therefore, I can't understand how removing the driver serves our users. Any rationale behind that decision? I feel like I'm arguing for something completely obvious... Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#561688: ITP: turbotail -- drop-in replacement for tail, using FAM for following files
Christian Dietrich wrote: > Package: wnpp > Severity: wishlist > Owner: Christian Dietrich > > > * Package name: turbotail > Version : 0.3 > Upstream Author : Folkert van Heusden > * URL : http://www.vanheusden.com/turbotail/ > * License : GPL > Programming Lang: C > Description : drop-in replacement for tail, using FAM for following > files > > turbotail provides almost all command line options as the normal tail > from coreutils, but when following files with -f, it doesn't poll the > file every second, but uses FAM to get informed about changes at the > file. The above is incorrect; tail in coreutils >= 7.5 uses inotify and hence doesn't poll needlessly. Even if the package is still needed for some reason (e.g. non-linux ports), your description should be adjusted. Regards, Faidon -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#392333: [Fwd: Re: Bug#392333: AW: [Fwd: ITP: irrtoolset -- policy analysis tools to operate with routing policies in RPSL format]]
Jan, hi, [ Cc'ing the ITP ] Jan Wagner wrote: > I agree with you, that maintaining the package isn't a big trick. From the > last releases, the biggest issue was the review of the copyright/license > changes and probably maintaining additional patches. I'm not sure if you follow upstream's list so I'll repeat some stuff anyway. Some months ago I contacted some of the original authors about the licensing mess. The main author, Cengiz Alaettinoglu, who did the work for ISI/USC back then but has since left, promptly replied and was able to reach some of his old colleagues who convinced USC's management to a relicensing. All in all, we had a happy ending and all of the weird non-free licensing, including the stuff that had IBM copyrights(!) have been cleared and the license has been replaced by a standard MIT one! Nick and Shane were aware of this and were holding off the 5.0.0 release (the cruft-cleanout one) so that it can be released with the new license. 4.8.6 (= MIT-licensed 4.8.5) was released today, so 5.0.0 will soon follow. However, there are also some bad news: the project has been pronounced dead at the last RIPE summit by Nick. He has worked on it for over a year and decided that the software is broken beyond repair -- he's the one that cleaned up all the cruft. I objected and several others were not very happy about it; if you're not subscribed, have a look at the archives for the discussion that followed. I'm not sure how to proceed. I think the best course would be to wait a bit and see before uploading to Debian. Regards, Faidon -- 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/4ba03b0e.30...@debian.org
Bug#430622: ITP: dbeacon -- Multicast Beacon
Package: wnpp Severity: wishlist Owner: Faidon Liambotis <[EMAIL PROTECTED]> * Package name: dbeacon Version : 0.3.9 Upstream Author : Hugo Santos <[EMAIL PROTECTED]> * URL : http://fivebits.net/proj/dbeacon/ * License : GPLv2 Programming Lang: C++ Description : Multicast Beacon dbeacon is a multicast beacon. Its main purpose is to monitor other beacon's reachability and collect statistics such as loss, delay and jitter between them. dbeacon supports both IPv4 and IPv6 multicast, collecting information using both Any Source Multicast (ASM) and Source-Specific Multicast (SSM). This package also includes dbeacon matrix, a Perl script to generate beacon reachability matrices in HTML. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436404: ITP: asterisk-addons -- Asterisk GPL-only plugins
Package: wnpp Severity: wishlist Owner: Faidon Liambotis <[EMAIL PROTECTED]> * Package name: asterisk-addons Version : 1.4.2 Upstream Author : Digium Inc. (http://www.digium.com/) and others * URL : http://www.asterisk.org/ * License : GPL Programming Lang: C Description : Asterisk GPL-only plugins asterisk-addons is a plugin package distributed by Digium and containing plugins that are licensed under the GPL but their authors have not signed the copyright disclaimer, necessary for Digium to distribute them under a commercial license and hence not included in the main Asterisk distribution. They are, however, suitable for all intents and purposes for inclusion in Debian. This is not going to be the actual description, since this is going to be a multi-binary package, one for each plugin. WIP can be found on pkg-voip-maintainers subversion repository on alioth. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303794: ITA: log4cpp -- A C++ library for flexible logging
Hello, For a work-related project of mine[0], I needed the log4cpp library version >=0.3.0, and I've prepared packages for the 0.3.5rc1 version. If you want I can send you my changes, so you can incorporate them to a future version of your package. I would love to comaintain, but I'm not a DD, just a sponsored maintainer... Let me know if I can help in any way. Regards, Faidon [0]: The project is about Internet2's Shibboleth, http://shibboleth.internet2.edu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311597: ITP: anyterm -- web-based shell
retitle 311597 ITP: anyterm -- web-based shell owner 311597 ! clone 311597 -1 reassign -1 wnpp retitle -1 ITP: rote -- VT102 Terminal Emulation Library thanks Hi, I found out about anyterm today (I don't have a LWN subscription, so I lag a week ;) and I'm interested in packaging it. It seems like an easy task. anyterm needs the rote library, therefore I'm cloning this bug as another ITP (actually, I have this ready to upload). I already have a sponsor (IANADD), but since you made the RFP, you can evaluate and upload the package if you want. * Package name: rote * URL : http://rote.sourceforge.net/ * License : LGPL Description : VT102 Terminal Emulation Library Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311597: Happy to help
Hi, I'm the author of Anyterm. I'm a Debian user and would be very happy to help with packaging in whatever way I could - though I currently have only the vaguest idea of what happens inside a .deb file. I was going to contact you before uploading. I guess I'm lucky you found me first :) Thanks for your offer! I don't have any questions (yet) but if you have any suggestions, feel free to tell me ;-) I'm going to package the "development" version 1.1.1. There are lot of reasons for doing that, but I think the most important one is the 64-bit fixes. Any objections? I think that the major issue with installing this is security. At present, people have to read the instructions and so should have some idea of what the security implications are before installing. If they can just "apt-get install" it, they miss that. I am really hoping that someone who has some experience with security auditing, preferably in connection with Apache, will take an interest. Actually, I was thinking to _not_ auto-enable the site in Apache. Instead I'm going to provide the example Apache configuration (in /usr/share/doc/anyterm/) with BIG warnings about the security implications. I think it should be enough. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312740: Packaging of rote and anyterm
package wnpp owner 311597 "roberto c. sanchez" <[EMAIL PROTECTED]> owner 312740 "roberto c. sanchez" <[EMAIL PROTECTED]> thanks Hi, Well, it seems I don't have a lot of options now, do I? :) OK, since you want to maintain them so much, they're yours. But please, next time look at the ITPs before packaging something, it's a shame to have duplicated work. As I said, I have made the rote packages too therefore I have some notes on your packaging: a) librote-dev should depend on libncurses5-dev (you'll find out yourself when you try to pdebuild anyterm ;) b) You _have_ to package 0.2.6+20050511 (CVS snapshot). It has some very important fixes - without them anyterm doesn't work very well, read the anyterm homepage. c) (minor) Upstream COPYING has LGPL v2.1 - you are referencing "LGPL version 2 or newer" in debian/copyright. I'm CCing Phil Endecott, upstream author of Anyterm who has offered to help. Please look at the discussion in #311597, Phil has made some interesting suggestions. Good luck, I'm looking forward in seeing these in Debian! Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#638976: ITP: python-gitdb -- a pure-Python git object database
On 08/23/11 15:56, Marco Túlio Gontijo Silva wrote: > Package: wnpp > Severity: wishlist > Owner: Marco Túlio Gontijo e Silva > > * Package name: python-gitdb > Version : 0.5.4 > Upstream Author : Sebastian Thiel > * URL : http://github.com/gitpython-developers/gitdb > * License : BSD > Programming Lang: Python > Description : a pure-Python git object database > The project's website says: “IO of git-style object databases - Phased out and merged into GitPython” And it seems GitPython is already in the archive as python-git. I'd be also curious to see how these compare to dulwich. Regards, Faidon -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e57c304.3040...@debian.org
Bug#647742: ITP: libradsec - RADIUS over TLS/DTLS/UDP/TCP library
Hi Sam, Hope you're well. Are you planning on putting the packaging efforts for this on git somewhere (e.g. collab-maint?). If so, I'd be happy to contribute, if help is needed, either now or when the merging effort with radsecproxy starts. Best regards, Faidon -- 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/4eb577ba.6090...@debian.org
Bug#669643: ITP: bugzilla4 -- web-based bug tracking system
On Thu, May 03, 2012 at 10:47:31AM -0400, Mark A. Hershberger wrote: > > Have you checked why bugzilla3 used to be in Debian, and got removed > > (see #638705). > > Thanks for the info. I was not aware of that. I did wonder why it > wasn't being packaged. > > It looks like the main thing to be addressed is finding a > co-maintainer. As discussed in private with Mark (he's a coworker), I will serve as his comaintainer & sponsor for this package. Moreover, I'm adding the security team to the loop, since bugzilla3 was removed per their request. We know that bugzilla has had a troubled history in Debian, so we'll be careful. One area in particular that was problematic was a strained relationship with upstream (aiui, the result of having an unmaintained vulnerable package in Debian for some time); Mark has already been in some contact with them. If you still have reservations, feel free to raise them â before we upload this (soonish) would work better :) Thanks, Faidon -- 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/20120515064855.ga21...@tty.gr
Bug#692483: ITP: dnsperf -- DNS server performance testing tool
Package: wnpp Severity: wishlist Owner: Faidon Liambotis Control: block -1 by 692467 * Package name: dnsperf Version : 2.0.0.0 Upstream Author : Nominum, Inc. * URL : http://www.nominum.com/support/measurement-tools/ * License : ISC Programming Lang: C Description : DNS server performance testing tool dnsperf is a DNS server performance testing tool. It is primarily intended for measuring the performance of authoritative DNS servers, but it can also be used for measuring caching server performance in a closed laboratory environment. . Also included is resperf, a similar tool that is more suitable for testing caching servers resolving against the live Internet. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121106161554.ga6...@tty.gr
Bug#694173: ITP: gdnsd -- authoritative domain name server
Package: wnpp Severity: wishlist Owner: Faidon Liambotis * Package name: gdnsd Version : 1.6.9 Upstream Author : Brandon L Black * URL : https://github.com/blblack/gdnsd * License : GPLv3 Programming Lang: C Description : authoritative domain name server gdnsd is an Authoritative-only DNS server. The initial g stands for Geographic, as gdnsd offers a plugin system for geographic (or other sorts of) balancing, redirection, and service-state-conscious failover. gdnsd has a strong focus on high performance, low latency service. It does not offer any form of caching or recursive service, and does not support DNSSEC. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121124153502.ga25...@dewey.void.home
Bug#659753: ITP: libnet-irr-perl -- Net::IRR - Perl interface to the Internet Route Registry Daemon
Carlos, On 02/13/12 17:29, Carlos Vicente wrote: > Hopefully this module will stimulate development of new Route > Registry tools written in Perl. An example of Route Registry tools > can be found by googling for RAToolset which is now known as the > IRRToolset. The RAToolset was originally developed by ISI, > http://www.isi.edu/, and is now maintained by RIPE, > http://www.ripe.net/. This is a really old description. IRRToolset has long moved under ISC's umbrella¹ where is dying a slow death… There's even an ITP for it (with packages prepared) but I've hesitated to upload since it seems to be abandoned upstream. Regards, Faidon ¹: http://www.isc.org/software/irrtoolset -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f394e2f.1040...@debian.org
Bug#368748: ITP: network-manager-openvpn -- OpenVPN network-manager plugin
Hi, What is the status of this ITP? I've successfully created a package for this and it's working fine on my laptop. I could upload it if you're not interested anymore. I don't have problem setting you as an Uploader btw. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#526350: celery ITP: ping?
Ping? Any progress on this? I'm also interested. It seems that there has been progress on SVN; last commit, however, was over 3 months ago. I can assist in reviewing and sponsoring the package, if needed. Regards, Faidon -- 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/20110622123904.gb1...@faidon.noc.grnet.gr
Bug#610165: ITP: less.js -- JavaScript parser of LESS "Leaner CSS" macro language
Jonas Smedegaard wrote: LESS is a macro language to produce CSS files. I'd start with that and expand it a bit. Regards, Faidon -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d320095.60...@debian.org
Bug#610165: ITP: less.js -- JavaScript parser of LESS "Leaner CSS" macro language
On 15/01/2011 10:22 μμ, Jonas Smedegaard wrote: On Sat, Jan 15, 2011 at 10:16:21PM +0200, Faidon Liambotis wrote: Jonas Smedegaard wrote: LESS is a macro language to produce CSS files. I'd start with that and expand it a bit. How do you mean? Please elaborate. Or better: propose a patch. The description starts by describing what less.js wrt LESS and LESS 2.0 and then explains what LESS is; this should probably be the other way around. Also, “a macro language to produce CSS files” is a bit concise and doesn't say much to someone that doesn't know what LESS exactly is (like me). Maybe you should describe LESS in a few words. Regards, Faidon -- 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/4d3204e6.6040...@debian.org
Bug#516183: ITP: python-django-cms
Ping? Regards, Faidon -- 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/4d3481a1.9000...@debian.org
Bug#710271: ITP: librdkafka -- library implementing the Apache Kafka protocol
Package: wnpp Severity: wishlist Owner: Faidon Liambotis * Package name: librdkafka Version : 0.8.0 Upstream Author : Magnus Edenhill * URL : https://github.com/edenhill/librdkafka * License : BSD-2-clause Programming Lang: C Description : library implementing the Apache Kafka protocol librdkafka is a C implementation of the Apache Kafka protocol, containing both Producer and Consumer support. . More information about Apache Kafka can be found at http://kafka.apache.org/ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130529133508.7374.47283.report...@serenity.void.home
Bug#711811: ITP: foreman -- manage Procfile-based applications
On 06/10/13 03:46, Per Andersson wrote: * Package name: foreman Version : 0.63.0 Upstream Author : David Dollar * URL : http://github.com/ddollar/foreman * License : MIT Programming Lang: Ruby Description : manage Procfile-based applications Foreman is a manager for Procfile-based applications. Its aim is to abstract away the details of the Procfile format, and allow you to either run your application directly or export it to some other process management format. There's a more popular/more complicated piece of software called Foreman[1], for which there's an RFP already[2], as well as a component of that, foremancli, already in Debian. Upstream provides a package too, although you could argue it isn't our problem if there's a naming conflict. Nevertheless, I think it'd be best to avoid a package naming conflict between the two apparently completely unrelated applications. Oh, and BTW, you should probably explain what a Procfile is on the long description of your package as it's not immediately obvious. Regards, Faidon 1: http://www.theforeman.org/ 2: http://bugs.debian.org/663101 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b53089.7040...@debian.org
Bug#712107: ITP: nutcracker -- Fast, light-weight proxy for memcached and Redis
Package: wnpp Severity: wishlist Owner: Faidon Liambotis * Package name: nutcracker Version : 0.2.5 (TBA) Upstream Author : Twitter, Inc. * URL : https://github.com/twitter/twemproxy * License : Apache-2.0 Programming Lang: C Description : Fast, light-weight proxy for memcached and Redis nutcracker, also known as twemproxy (pronounced "two-em-proxy"), is a fast and lightweight proxy for the memcached and Redis protocols. It was primarily built to reduce the connection count on backend caching servers, but it has a number of features, such as: * Maintains persistent server connections to backend servers. * Enables pipelining of requests and responses. * Supports multiple server pools simultaneously. * Shard data automatically across multiple servers. * Supports multiple hashing modes including consistent hashing and distribution. * High-availability by disabling nodes on failures. * Observability through stats exposed on stats monitoring port. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130613035521.ga31...@tty.gr
Bug#727085: Taking over packaging in Debian.
On 03/04/14 00:01, David Martínez Moreno wrote: Don't act as we have some hidden agenda, please. There are several things that I'm putting work on like dropping support for the forked libevent HTTP server, using alternatives for the php5-cli/cgi binaries to be able to replace them, no init scripts for now, compiling folly statically (or at the very least not as a different package), getting rid of third-party stuff, releasing proper tarballs in hhvm.com, merging the nightly packages with my work, and those are off the top of my head. \o/ This list is awesome David, as is the rest of your work so far. Let's document this and others under debian/TODO. Thanks for this and apologies to you, Paul & team for not having made much progress on this since we last spoke. I took a look at the collab-maint repository and submitted a bunch of commits -- I had already prepared a very similar list of Build-Depends myself in the early work I had locally, so I merged mine into yours and fixed some other collateral issues I found. Please review! Thanks again and I hope we can find ways to collaborate to make an awesome HHVM package in Debian :) Best, Faidon -- 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/531591e6.1020...@debian.org
Bug#786460: ITP: kafka -- Distributed, partitioned, replicated commit log service
On Thu, Jun 18, 2015 at 07:44:05AM -0500, Brandon Bradley wrote: > I have multiple reasons for not contacting Wikimedia or using their work. > The possibility of them having additions for their own purposes is very > high. I believe starting fresh was easier than analyzing and debugging > their repo. Don't guess, ask :) That particular package has been prepared and is maintained by my team at the Wikimedia Foundation, which incidentally has 3 DDs (Filippo Giunchedi, Moritz Mühlenhoff and myself) in it, plus at least a couple of other people with Debian packaging expertise. At Wikimedia, we're using Kafka extensively. We're obviously very keen on pushing things upstream too, which why e.g. I already pushed our librdkafka package in Debian (already part of jessie). Vincent Bernat also worked on kafkacat (from the same upstream) which we also use, so we collaborated and now jointly comaintain each other's packages. We're definitely not trying to work in a silo :) We haven't attempted to push the "main" Kafka package to Debian, since our time was limited and the packaging was a bit hacky/get-the-job-done (e.g. replacing the complex build system that downloads jars off the Internet by a Makefile), plus, JVM packages are usually harder to maintain properly :) I've been quietly watching this ITP, though, and we would definitely be interested to join efforts and switch to better, properly maintained packages, if there is enough momentum from people that want to see this in Debian. Time is (always) limited but I'd be more than happy to review/mentor/upload. I'll also convey this whole conversation internally to my team, maybe we can pull some resources for this, if you're interested in collaborating. Best, Faidon -- 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/20150618141029.ga1...@tty.gr
Bug#510408: ITP: biew -- console hex viewer/editor with disassembler
Michel Loos wrote: > Package: wnpp > Severity: wishlist > Owner: Michel Loos > > * Package name: biew > Version : 5.7.1 > Upstream Author : Nick Kurshev > * URL : http://sourceforge.net/projects/biew/ > * License : GPL > Programming Lang: C > Description : console hex viewer/editor with disassembler biew was already part of the archive in the past and it was, in fact, released with etch. See #460636 for the bug that requested its removal. That isn't to say that you shouldn't package it; I just think that you should be aware of it. Regards, Faidon -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510476: ITP: LinuxCallRouter - an ISDN based PBX for Linux
Joerg Dorchain wrote: > Package: lcr LinuxCallRouter - an ISDN based PBX for Linux > Version: 1.3 (20081124) > Upstream Author: Andreas Eversberg > URL: http://isdn.eversberg.eu/download/lcr-1.3/ > Licence: GPL > Description: > Formerly known as "PBX4Linux", Linux-Call-Router is not only a router, > it is a real ISDN PBX which interconnects ISDN telephones and ISDN lines. > It is possible to connect telephones to a Linux box. It is a pure software > solution except for the ISDN cards and telephones. The great benefit is > the NT-mode that allows to connect telephones to an ISDN card. Special > cards are needed and a little bit of different cabeling. It supports lots > of features, that only expensive PBXs have. It include a channel driver > that can link LCR to Asterisk PBX. > > Now that the underlying misdn driver has made it into the mainstream > kernel and asterisk has a debian package for some time, this > package fills the gap of combining both into a very scalable PBX. You're welcome to join pkg-voip-maintainers and coordinate with us about this :) Regards, Faidon -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#513606: ITP: freeswitch -- An open source telephony platform.
There's #389591 and you might want to contact Phil Hands who has showed interest for this. You're also welcome to join the Debian VoIP team. Thanks, Faidon -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#1003128: ITP: wasmedge -- High performance WebAssembly Virtual Machine
On Wed, Jan 05, 2022 at 12:44:06AM +0800, Shen-Ta Hsieh wrote: > Package: wnpp > Owner: Shen-Ta Hsieh > Severity: wishlist > > * Package name: wasmedge > Version : 0.9.0 > Upstream Author : Second State INC > * URL : https://wasmedge.org/ > * License : Apache License 2.0 > Programming Lang: C++ > Description : High performance WebAssembly Virtual Machine I have prepared a package for 0.10.0 that is pretty much complete (i.e. including all metadata like debian/copyright, debian/watch etc.) and functional, including AOT/wasmedgec and libwasmedge_c. I needed to backport one patch from upstream (75c3890), but more importantly have some outstanding questions/issues around libwasmedge_c, that I have filed upstream bugs about (#1677¹, #1688²). Patching the former is trivial, but would require me to make an ABI promise that upstream hasn't made, so I consider this a blocker. I don't know if I have the bandwidth to properly maintain another package. I'm happy to share my work (e.g. in a Salsa git repo), and assuming someone else wants to take the primary role of maintainer, I'm happy to act both as a sponsor, and occasional contributor/Uploader. Shen-Ta, not sure if you'd be interested in such an arrangement? Best, Faidon 1: https://github.com/WasmEdge/WasmEdge/issues/1677 2: https://github.com/WasmEdge/WasmEdge/issues/1678
Bug#1003128: ITP: wasmedge -- High performance WebAssembly Virtual Machine
On Fri, Jul 22, 2022 at 03:40:13PM +0200, Faidon Liambotis wrote: > I have prepared a package for 0.10.0 that is pretty much complete (i.e. > including all metadata like debian/copyright, debian/watch etc.) and > functional, including AOT/wasmedgec and libwasmedge_c. > > I needed to backport one patch from upstream (75c3890), but more > importantly have some outstanding questions/issues around libwasmedge_c, > that I have filed upstream bugs about (#1677¹, #1688²). Patching the > former is trivial, but would require me to make an ABI promise that > upstream hasn't made, so I consider this a blocker. Update: upstream is making progress on #1677¹, and there is a PR #1783 out.
Bug#857318: ITP: golang-github-optiopay-kafka -- Go client library for Apache Kafka
Hi Tim, On Fri, Mar 10, 2017 at 12:48:01AM +, Potter, Tim wrote: > This library provides a high-level client API for Apacha Kafaka. It ^^ typo > implements connection management as well as producer and consumer > objects for sending and receiving messages, respectively. How is that different than Sarama, already present in the archive as src:golang-github-shopify-sarama? Even if they both are worthy of being in the archive, it might be worth documenting the differences in the package description. Also, a few of us have created pkg-kafka; we currently package mainly librdkafka and related tools but that's not set in stone. One of my comaintainers, Christos (Cc'ed), is also planning to package confluent-kafka-go which is a wrapper of librdkafka. You might be also interested in that one, as you might be in the pkg-kafka team in general. You're welcome to join it -- but also understandable if you wish to maintain this package under pkg-go too. Best, Faidon
Bug#857318: ITP: golang-github-optiopay-kafka -- Go client library for Apache Kafka
On Fri, Mar 10, 2017 at 02:41:59AM +, Potter, Tim wrote: > I'm primarily interested in the optiopay Kafka client as it's a build > dependency > for a Kubernetes add-on that I'm packaging at the moment. Unfortunately this > will result in a duplication in functionality in Debian but I don't see it as > my job to > write bits of upstream - at least not yet. That's fair enough, and I expected as much. Since the package will stand on its own though, it would still make sense IMHO to document a few differences between the various versions (in the package description and/or in README.Debian) so that people looking in Debian for a Kafka library for their Go project don't get overwhelmed with all of the different choices. > Nice. It's great to see a dedicated Kafka community being built in Debian. I > think it's one of those complicated packages that can't be created properly > if it's merely a dependency of something else. > > Since Kafka is written in Java I don't imagine we will cross paths very often > in packaging land, but I'm happy to transfer repos around if it makes sense. > I'm not sure it does for the optiopay client right now though but am willing > to be convinced. Apache Kafka is actually written in Scala, but we, the current pkg-kafka members, haven't been focusing on packaging that yet -- that's a much bigger endeavour. So far we have been maintaining librdkafka (the most popular C/C++ library for producing to or consuming from Kafka, already has a few rdeps in Debian), the Python bindings for it, and soon to be -as I said earlier- the Go bindings for librdkafka. I also comaintain kafkacat, a CLI utility based on librdkafka, and am planning to move it under pkg-kafka in the next upload. I definitely wouldn't say optiopay is out of scope for pkg-kafka, but I wouldn't say it's out of scope for pkg-go either. Your pick :) Regards, Faidon PS. Thanks for your work on k8s :)
Bug#727085: Now we don't depend on the weird libevent patch
On Sun, Dec 22, 2013 at 12:03:38AM +0100, Francesco Poli wrote: Not really, in my opinion. I think it's a valid rejection reason for anything that is not the reference PHP implementation published and copyrighted by the PHP Group. Personally, I consider the PHP License non-free even for PHP itself, but that's another story: https://lists.debian.org/debian-legal/2005/11/msg00272.html Just to clarify, since Paul may not be accustomed with Debian's structure or your involvement: this is your opinion but you're not a member of the Debian project and you're certainly not the decision maker for DFSG-freeness. The maintainer (and, possibly, sponsoring Debian Developer) is the first line of defense, and ultimately the decision is up to the ftp-master team[1] as part of the power of processing the NEW queue and accepting packages into Debian, a power that is delegated from the project leader. PHP is in the archive and is licensed under the PHP License to my knowledge, so the current ftp-masters' stance is that it's a perfectly acceptable license for inclusion into Debian. There is zero evidence suggesting that HHVM is not going to be accepted in Debian for the licensing reasons that you stated and there is, in fact, evidence to the contrary. Please avoid suggesting so -or if you do, explain that you're not part of the decision process- and possibly frightening perfectly good upstreams, or asking them to do more work, especially when they've proved themselves to be very willing to collaborate with us. Regards, Faidon 1: https://wiki.debian.org/Teams/FTPMaster -- 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/20131229134647.ga32...@dewey.void.home
Bug#727085: Now we don't depend on the weird libevent patch
On Mon, Dec 30, 2013 at 12:56:48AM +0100, László Böszörményi (GCS) wrote: My opinion for releases follows. Do one if there's an important bugfix, new feature added, etc. In short, if there's a reason. On the other hand, there's no problem with releasing every two weeks, it's just not common. It matches with Debian standards, meaning that normally ten days needed for unstable -> testing migration. Two weeks is probably too often for Debian but time-based releases in general (rather than "important bugfix") are fairly common. I think the original idea of accumulating multiple sprints into one "community" release is a great path forward. The proposal for 8-week releases sounds just fine to me. Looking a bit further ahead, Debian will release a new stable in something like a year from now, and will have to support whatever happens to be in testing by November 6th, for at least the release of next stable + one year (i.e. for about 3-4 years), without the ability to bump into newer HHVM versions. Some upstreams tend to release some "LTS" releases for such uses, potentially labeling one of their incremental releases as LTS. This isn't a prerequisite, but it's good to actually have some longer stable/security management in mind when planning your release schedule. Lastly, Laszlo, we should talk about how I can help with packaging. Do you have a packager position there, at FB? :) At least ATM I've two places to work for. At Debian I've more than a hundred packages and twenty to do. Especially that I have to work more or less constant from 31st 06:00 am to 2nd 04:20 pm. Will be hard, thus I'll start again with HHVM next year. Well, noone really forced you to ITP this :) You definitely seem to have your hands full, there's no need for you to take on more than you're able to handle. If you're too busy, I can just takeover this ITP, just say so. Now my previous package section for HHVM, which I've named hiphop-php (to match the PHP policy of Debian, but will re-check that): Which section of the policy mandates that? I'd be very suprised if the existing PHP policy covers alternative interpeters. -- cut -- HipHop VM (HHVM) is a new open-source virtual machine designed for executing s/a new/an/ (redundant for the description) programs written in PHP. HHVM uses a just-in-time compilation approach to achieve superior performance while maintaining the flexibility that PHP developers are accustomed to. HipHop VM (and before it HPHPc) has realized > 5x increase in throughput for Facebook compared with Zend PHP 5.2. HipHop is most commonly run as a standalone server, replacing both Apache and modphp. The last two lines are incorrect considering the new FastCGI mode of operation, which AIUI will be the only one actually offered by the package, as the embedded standalone webserver requires patches to libevent. I think packaging for Debian is a good step. Then Ubuntu maintainers will pick it up and as I know, Mint based on Ubuntu, they will have it as well. Ubuntu automatically syncs from Debian, there's no need for Ubuntu maintainers to do anything. And yes, there's tons of other Debian & Ubuntu derivatives that also regularly sync from those two. Regards, Faidon -- 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/20131231024523.ga...@dewey.void.home
Bug#727085: Now we don't depend on the weird libevent patch
On 01/04/14 19:54, László Böszörményi (GCS) wrote: On Sat, Jan 4, 2014 at 1:51 AM, Paul Tarjan wrote: checking whether the Boost::Thread library is available... yes configure: error: Could not find a version of the library! It looks like it defaults to looking in /usr/bin instead of where lib boost is in sid. Try ./configure --with-boost-libdir=/usr/lib/x86_64-linux-gnu/ Thanks, it helped. I used $BOOST_LDFLAGS for testing, but that didn't work. Anyway, folly is packaged and uploaded. HHVM is one small step closer to be part of Debian. Does folly have a stable ABI? I remember raising this with Paul some time ago and us deciding that embedding folly into the HHVM source would be the way to go, as there is really no stable interface between them. Also, you're really supposed to file separate ITPs for separate packages (and file them *before* you make an upload). Regards, Faidon -- 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/52c84bc5.4090...@debian.org
Bug#727085: Now we don't depend on the weird libevent patch
On Sat, Jan 04, 2014 at 07:07:15PM +0100, László Böszörményi (GCS) wrote: Does folly have a stable ABI? I remember raising this with Paul some time ago and us deciding that embedding folly into the HHVM source would be the way to go, as there is really no stable interface between them. I can't answer this question. Still, I expect that HHVM will follow ABI changes very fast. Paul? Anyway, I think having a separate package and let users get knowledge of that doesn't mean HHVM can't use an embedded copy if it needs to. But it should be a separate package whenever it's possible. If the ABI isn't stable, HHVM is the least of your problems. Non ABI stable libraries have really no place in Debian: you have to bump the SONAME, rename the package, go through NEW, binNMU all reverse dependencies, go through a testing transition etc. every time and that's *if* you detect the ABI breakage and it doesn't get silently undetected crashing reverse dependencies (= RC bug). Check with your upstream (Paul? someone else?) if they're guranteeing ABI, and preferrably also tag versions rather than packaging random git snapshots, *then* upload it. Otherwise it's a pretty pointless exercise and I'm sure it'll get REJECTed from NEW. For HHVM, embedding the folly source as the upstream build does seems like the best course of action to me, especially since folly isn't a library that we expect to see wide adoption for other packages out there. Also, you're really supposed to file separate ITPs for separate packages (and file them *before* you make an upload). ??? Please see its ITP[1]. I just noted the upload here. It's closed by the changelog in the folly package if that will be accepted into the archive. The reason ITPs exist and policy mandates that they are Cc'ed to debian-devel is so that all developers have a chance to raise issues (such as naming conflicts, ABI stability, package descriptions, previous work etc.). Filing the ITP and uploading <= 30mins later is a really bad practice and doesn't really count, it feels like working around Policy to me. (it also hasn't even reached my debian-devel inbox yet, did you X-Debbugs-Cc it?)[1] Regards, Faidon 1: You're not the first person that I've told that :) cf. https://lists.debian.org/debian-devel/2013/06/msg00666.html -- 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/20140104182824.ga...@tty.gr
Bug#727085: Now we don't depend on the weird libevent patch
On 01/05/14 05:44, Jordan DeLong wrote: On Sat, Jan 04, 2014 at 11:53:25PM +0100, László Böszörményi (GCS) wrote: Question is, does Folly maintain ABI compatibility? If it changes from time-to-time, how often? Yeah, it doesn't attempt to maintain ABI backward compatability, and we haven't done much about tracking when we break source-level backward compatability either. (As Sara said, we don't version it currently... unless you count the submodule in hhvm ;) There are changes probably a few times a week, although I'd suspect few of the changes that aren't to new components (usually in folly/experimental) actually break source backward compat. I do think it'd be nice to have folly packages some day, but mostly the value there would be making it easier to use folly (in other C++ projects). I don't think it's going to be all that helpful for people who just want to use hhvm: it's largely a header-only library, so even if there are nice folly-dev packages with .h's and .a's, I'd hope a pre-built hhvm package wouldn't depend on a folly package being installed, since it makes more sense to statically link it. (Actually there's probably not much point to having a non-development folly package containing .so's for most reasonable use cases w/ the library as it is today---maybe if it grows significantly in the non-header-only portion in the future, but probably not anytime soon.) Thanks a lot for the clarifications, Jordan and Sara. These seem to confirm my (educated :) guesses about folly's release model. László, given the above, are you going to inform the ftp-masters to REJECT the package from NEW right away? Regards, Faidon -- 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/52c9ed37.6060...@debian.org
Bug#700337: ITP: kibana -- is a user friendly way to view your log data.
On 11/02/2013 11:12 πμ, Jose Calhariz wrote: * Package name: kibana Thanks for packaging this. Kibana is not very useful on its own though, do you happen to also intend on packaging logstash? Regards, Faidon -- 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/511968fb.30...@debian.org
Bug#700337: ITP: kibana -- is a user friendly way to view your log data.
On Tue, Feb 19, 2013 at 07:31:38PM +, Jose Manuel dos Santos Calhariz wrote: > > Thanks for packaging this. Kibana is not very useful on its own > > though, do you happen to also intend on packaging logstash? > > No, I don't. That's sad. Why not? > I have a kibana package prepared for a review, Can you be my sponsor? I guess I could, although I'm not familiar much with Ruby packaging. Have you tried contacting more experienced people from the Ruby team? Regards, Faidon -- 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/20130301074535.gb23...@dewey.void.home
Bug#619642: ITP: libjs-extjs4 - cross-browser JavaScript library, version 4
On Mon, Nov 21, 2011 at 11:28:46PM +0100, Laszlo Boszormenyi wrote: > owner 619642 ! I'm packaging JSDuck which needs ExtJS 4, I'm wondering what the status of this ITP is. Thanks, Faidon -- 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/20130430175346.ga25...@tty.gr
Bug#851940: ITP: certspotter -- Certificate Transparency Log Monitor
Package: wnpp Severity: wishlist Owner: Faidon Liambotis * Package name: certspotter Version : 0.2 Upstream Author : Opsmate, Inc. * URL : https://github.com/SSLMate/certspotter * License : MPL-2.0 Programming Lang: Go Description : Certificate Transparency Log Monitor Cert Spotter is a Certificate Transparency log monitor from SSLMate that alerts you when a SSL/TLS certificate is issued for one of your domains. Cert Spotter is easier than other open source CT monitors, since it does not require a database. It's also more robust, since it uses a special certificate parser that ensures it won't miss certificates. . Cert Spotter is also available as a hosted service by SSLMate that requires zero setup and provides an easy web dashboard to centrally manage your certificates. Visit <https://sslmate.com/certspotter> to sign up. . You can use Cert Spotter to detect: * Certificates issued to attackers who have compromised a certificate authority and want to impersonate your site. * Certificates issued to attackers who are using your infrastructure to serve malware. * Certificates issued in violation of your corporate policy or outside of your centralized certificate procurement process. * Certificates issued to your infrastructure providers without your consent. I intend to maintain this under pkg-go. Andrew Ayer (Cc'ed) is the upstream author and also a DM (Andrew, if you want to maintain this instead, happy to take a step back).
Bug#819027: ITP: xiccd -- X11/colord ICC bridge
Package: wnpp Severity: wishlist Owner: Faidon Liambotis * Package name: xiccd Version : 0.2.2 Upstream Author : Alexey Galakhov * URL : https://github.com/agalakhov/xiccd/ * License : GPL-3.0+ Programming Lang: C Description : X11/colord ICC bridge xiccd is a simple bridge between colord and X. It performs the following tasks: * Enumerating displays and registering them in colord; * Creating default ICC profiles based on EDID data; * Applying ICC profiles provided by colord; * Maintaining the user's private ICC storage directory. It does not depend on any particular desktop environment nor toolkit and it should not be used in desktop environments that support color management natively, like GNOME and KDE do.
Bug#786460: ITP: kafka -- Distributed, partitioned, replicated commit log service
Brandon et al, It's been quite a while (10 months!) since that email exchange and your original ITP. Have you perhaps made any progress towards packaging Kafka? Is there some work-in-progress somewhere in a VCS or something I could pick up and perhaps find time to work on? In any case, if you are not planning to resume work on this, perhaps you should retitle this ITP to an RFP for the record :) Best regards, Faidon On Thu, Jun 18, 2015 at 09:34:14AM -0500, Brandon Bradley wrote: > Hello Faidon, > > Thank you for coming to talk to us! And your willingness to > review/mentor/upload. Glad to know Wikimedia is listening and willing to > contribute. Another reason I did separate packaging work was to get the > latest version of Kafka running. We can find some time in the next few > weeks to discuss on IRC. Whenever is good for you. > > Cheers! > Brandon > > > > On Thu, Jun 18, 2015 at 9:10 AM, Faidon Liambotis > wrote: > > > On Thu, Jun 18, 2015 at 07:44:05AM -0500, Brandon Bradley wrote: > > > I have multiple reasons for not contacting Wikimedia or using their work. > > > The possibility of them having additions for their own purposes is very > > > high. I believe starting fresh was easier than analyzing and debugging > > > their repo. > > > > Don't guess, ask :) > > > > That particular package has been prepared and is maintained by my team > > at the Wikimedia Foundation, which incidentally has 3 DDs (Filippo > > Giunchedi, Moritz Mühlenhoff and myself) in it, plus at least a couple > > of other people with Debian packaging expertise. > > > > At Wikimedia, we're using Kafka extensively. We're obviously very keen > > on pushing things upstream too, which why e.g. I already pushed our > > librdkafka package in Debian (already part of jessie). Vincent Bernat > > also worked on kafkacat (from the same upstream) which we also use, so > > we collaborated and now jointly comaintain each other's packages. We're > > definitely not trying to work in a silo :) > > > > We haven't attempted to push the "main" Kafka package to Debian, since > > our time was limited and the packaging was a bit hacky/get-the-job-done > > (e.g. replacing the complex build system that downloads jars off the > > Internet by a Makefile), plus, JVM packages are usually harder to > > maintain properly :) > > > > I've been quietly watching this ITP, though, and we would definitely be > > interested to join efforts and switch to better, properly maintained > > packages, if there is enough momentum from people that want to see this > > in Debian. > > > > Time is (always) limited but I'd be more than happy to > > review/mentor/upload. I'll also convey this whole conversation > > internally to my team, maybe we can pull some resources for this, if > > you're interested in collaborating. > > > > Best, > > Faidon > >
Bug#825821: ITP: neomutt -- NeoMutt is a place to gather all the patches against Mutt.
On Mon, May 30, 2016 at 06:42:21PM +0200, Elimar Riesebieter wrote: > I've contacted Antonio Radici, Christoph Berg, "Matteo F. Vescovi" and > Faidon Liambotis via PM a while ago. I'll respond here, unfortunately without not much context, as that was a PM and I wouldn't want to forward without permission. So, first of, a bit of a background for the ITP: - The mutt maintainers have been engaging with the neomutt upstream already. I, in fact, joined the mutt maintainer group precisely for this purpose. See https://github.com/neomutt/neomutt/issues/23 and others. - Debian is already shipping neomutt partially already; mutt 1.6.1-1 already replaces some of our home-grown patches with neomutt's. - Debian has *not* been shipping a vanilla mutt for years. Debian has been shipping mutt, mutt-patched and mutt-kz, the former two from src:mutt and the latter from src:mutt-kz. All of them, including the binary package called "mutt" are heavily patched, to a large extent with patches that neomutt ships (ifdef, compressed folders, trash/purge) but a lot of others as well. - The neomutt upstream (Cc'ed) has been incredibly responsive and receptive to requests, both in general and to Debian's needs specifically. Besides us, he's been bringing together many other downstreams (distros and BSDs). - Considering the above, consensus between the mutt maintainers so far (and AIUI) has been that the mutt source package should switch upstreams and start tracking neomutt. This would basically mean having *one* source and *one* binary package for mutt in Debian (not counting transitional packages). - This has been waiting to some extent on the new neomutt release which includes compressed folders and NNTP, released just today. As such, I think this ITP is superfluous, at least for now. Even if it is not, pkg-mutt should own this ITP, not Elimar alone -- as we are already the de facto downstreams of neomutt in Debian. We could certainly revisit the decision to ship two source packages in Debian, src:mutt and src:neomutt (the eventual deprecation of mutt-patched and src:mutt-kz is widely agreed at this point, I think). I still haven't heard a convincing response of what would happen to the "mutt" binary package, though. As I explained above, we're not shipping a vanilla mutt and haven't been doing so for many years now. Switching back to the vanilla mutt would be a regression at this point and break user expectations on upgrades. Keeping the status quo, on the other hand, would mean just a huge waste of effort for maintaining and forward-porting patches that neomutt upstream is already doing a better job at. I also haven't heard a convincing response on what would happen with all of the patches shipped in src:mutt's debian/patches that are not in neomutt yet; effectively forking off the two packages would suck for either future maintenance or for our users' upgrades, both of which I find unacceptable options. What do others think? Regards, Faidon
Bug#741199: RFP: libmaxminddb -- library for working with MaxMind DB files
retitle 741199 ITP: libmaxminddb -- library for working with MaxMind DB files owner 741199 ! thanks > This is now the de facto format for the GeoIP (and GeoLite) databases. > > CC'in the geoip maintainer in case he wants to take this RFP as this is > basically the continuation of what he is maintining. I'm interested in doing this and I have preliminary packages. I checked with Patrick and he is okay with this plan. I'll put packaged up in collab-maint soon, in case Patrick or others are interested as well. Thanks, Faidon -- 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/20141106090417.ga29...@tty.gr
Bug#768979: ITP: geoipupdate -- MaxMind GeoIP/GeoIP2 database updates
Package: wnpp Severity: wishlist Owner: Faidon Liambotis * Package name: geoipupdate Version : 2.1.0 Upstream Author : MaxMind, Inc. * URL : https://github.com/maxmind/geoipupdate * License : GPL Programming Lang: C Description : MaxMind GeoIP/GeoIP2 database updates The GeoIP Update program performs automatic updates of GeoIP2 and GeoIP Legacy binary databases, as supplied by MaxMind. These are typically paid products; for the free GeoLite databases, the packages geoip-database or geoip-database-contrib can be installed instead. This package replaces the "geoipupdate" functionality that used to be part of the geoip-bin package but was removed starting with 1.6.0, following upstream's split of the packages. The geoip-bin maintainer, Patrick Matthäi, is already aware of the plans for this ITP. Compared to geoip-bin, this will add GeoIP2 support, as supported by libmaxminddb, #741199. Finally, since the only purpose of this package is to fetch paid, binary databases from MaxMind, it will uploaded to the contrib section of the archive. Regards, Faidon -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141110143621.ga11...@tty.gr
Bug#768984: ITP: python-maxminddb -- Python module for reading the MaxMind DB format
Package: wnpp Severity: wishlist Owner: Faidon Liambotis * Package name: python-maxminddb Version : 1.0.0 Upstream Author : MaxMind, Inc. * URL : https://github.com/maxmind/MaxMind-DB-Reader-python * License : Apache-2.0 Programming Lang: Python, C Description : Python module for reading the MaxMind DB format This is a Python module for reading MaxMind DB files. The module includes both a pure Python reader and an optional C extension. MaxMind DB is a binary file format that stores data indexed by IP address subnets (IPv4 or IPv6). -- 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/20141110153252.ga18...@tty.gr
Bug#768979: Thanks and geoipupdate for free GeoLite users
On 11/11/14 02:42, Gregory Oschwald wrote: Thanks so much for packaging all of these! You're very welcome :) FWIW, I've also submitted an ITP for the Python bindings, #768984. I don't have any plans for the rest of the language binaries for now. All three packages are essentially done (modulo your recommendations below) and in Debian's git: http://anonscm.debian.org/cgit/collab-maint/geoipupdate.git http://anonscm.debian.org/cgit/collab-maint/libmaxminddb.git http://anonscm.debian.org/cgit/collab-maint/python-maxminddb.git Although it is poorly advertised, geoipupdate can actually be used with the free GeoLite databases, e.g., with the GeoIP.conf file: UserId 99 LicenseKey ProductIds 506 533 I think it would be reasonable to use this as a default in a general package. The GeoLite2 databases should work too with the product IDs of "GeoLite2-City" and "GeoLite2-Country", but there appears to be an issue with the deployment of them for geoipupdate currently. Hopefully in the future we will clean up that fake UserId/LicenseKey, but even as it stands, this is preferable for most people to using a homemade script for downloading as it only downloads if the file has changed, verifies the MD5s before deploy, and safely moves the verified files over the old files. Oh wow, that is indeed great (and indeed poorly advertised :). I wasn't aware of this at all. We could replace geoip-database-contrib with this entirely. Two questions: 1) Where can I find the product IDs for the rest of the GeoLite databases? Ideally we'd list all of them, at least commented-out. 2) Is there an ETA for fixing the GeoLite2 products on the server? I could wait for this before I make an upload. Thanks for the amazingly quick feedback :) Regards, Faidon -- 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/54615f2c.3090...@debian.org
Bug#896816: ITP: lowdown -- Simple markdown translator
owner 896816 ! thanks On Tue, Apr 24, 2018 at 10:24:06AM -0400, Jon Bernard wrote: > * Package name: lowdown It seems this ITP has been pending for 2½ years, and looks abandoned. I was interested in this package, so I worked with upstream to resolve a bunch of integration issues with both lowdown and oconfigure (its build system), plus a PR to libbsd, and prepared a package suitable for inclusion into Debian. I pushed the repository to Salsa, under the Debian project: https://salsa.debian.org/debian/lowdown I'll upload to unstable momentarily; Jon or anyone else, if you want to comaintain you're more than welcome! Regards, Faidon
Bug#982012: ITP: dbip-lite-databases -- IP geolocation databases
Package: wnpp Severity: wishlist Owner: Faidon Liambotis * Package name: dbip-lite-databases Version : 202102 Upstream Author : Eris Networks S.A.S * URL : https://db-ip.com/ * License : CC-BY 4.0 Programming Lang: - Description : IP geolocation databases The DB-IP Lite databases are a set of free IP geolocation databases, that can map an IPv4 or IPv6 address to a specific continent, country, city, and ISP, with varying degrees of accuracy. They are an alternative to the MaxMind GeoLite2 databases (in Debian as "geoip-database"), newer releases for which are now non-free. They are also a less accurate (but free) alternative to the commercially available DB-IP and MaxMind GeoIP databases. The databases will be offered in the MMDB file format, an open format with a number of open source reader and writer implementations, including libmaxminddb, bindings for a variety of programming languages. The data set is volatile, and upstream issues regular releases on a monthly cadence.
Bug#912735: ITP: dnsperf -- DNS server and recursor performance testing tools
Hi Stefan! On Sat, Nov 03, 2018 at 10:45:54AM +0100, Stefan Nachtnebel wrote: > * Package name: dnsperf > Version : 2.1.0.0 > Upstream Author : Nominum, Inc. (now Akamai) > * URL : > https://www.akamai.com/uk/en/products/network-operator/measurement-tools.jsp > * License : Apache License 2.0 > Programming Lang: C, Python > Description : DNS server and recursor performance testing tools > > > > A RFP for this software has already been filed[1], but has been archived due > to inactivity. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692483 I'm the author of the original ITP (later an RFP) for this. Thanks for picking that up again! At the time, the software was licensed under the ISC license and not Apache2; there was no LICENSE file in the source tree and not all files had license headers, which would made the ones that didn't, undistributable. I was in touch with folks from Nominum back then, but didn't manage to get this sorted out. Hopefully those issues have been fixed since, but just wanted to give you a heads-up regardless :) Regards, Faidon
Bug#1041463: ITP: rust-wasmtime -- cross-platform engine for running WebAssembly programs
On Wed, Jul 19, 2023 at 10:56:32AM +0200, Jonas Smedegaard wrote: > rust-wasmtime is the Rust embedding API for the Wasmtime project: > a cross-platform engine for running WebAssembly programs. > > This is a pseudo-ITP: The source package is already maintained for the > subset covering core Cranelift crates, since they are part of same > monorepo. The intent tracked here is extending that source package to > provide binary packages librust-wasmtime* which involves additional > dependencies unneeded for Cranelift. I'm not sure what you mean by that -- what is already maintained? Also, are you planning to package wasmtime, as in the CLI, itself? I believe this exists on the same upstream/source tree as the language bindings that you're proposing here? > Please shout if there is need for wasmtime, and especially if there is > interest in helping get the needed dependencies packaged. I don't have the bandwidth to help packaging wasmtime. However, I do maintain another popular WebAssembly runtime, WasmEdge, and last year I contributed a few changes to the Debian LLVM packages (src:llvm-project-14 and friends) with regards to WebAssembly support, and so you could say I'm interested with helping in bringing more parts of the WebAssembly ecosystem in Debian :) I'm also interested in opportunities to help each other, and in the relevant packages working well with each other and/or providing a unified experience. Let me know if you can think of any such ways. On that note, you may be interested in (and/or subscribing to) #1033322. Regards, Faidon
Bug#1041463: ITP: rust-wasmtime -- cross-platform engine for running WebAssembly programs
On Wed, Jul 19, 2023 at 06:41:54PM +0200, Jonas Smedegaard wrote: > > > This is a pseudo-ITP: The source package is already maintained for the > > > subset covering core Cranelift crates, since they are part of same > > > monorepo. The intent tracked here is extending that source package to > > > provide binary packages librust-wasmtime* which involves additional > > > dependencies unneeded for Cranelift. > > > > I'm not sure what you mean by that -- what is already maintained? > > Whoops, I had it in mind but evidently forgot to mention it: I mean the > packaging effort tracked as ITP bug#1041434 (and now in NEW queue). Ah! It makes sense now, thanks :) > > Also, are you planning to package wasmtime, as in the CLI, itself? I > > believe this exists on the same upstream/source tree as the language > > bindings that you're proposing here? > > I mean both the Rust crates and the command-line tool. > > You are right, both are part of same monorepo. Awesome! > > > Please shout if there is need for wasmtime, and especially if there is > > > interest in helping get the needed dependencies packaged. > > > > I don't have the bandwidth to help packaging wasmtime. However, I do > > maintain another popular WebAssembly runtime, WasmEdge, and last year I > > contributed a few changes to the Debian LLVM packages > > (src:llvm-project-14 and friends) with regards to WebAssembly support, > > and so you could say I'm interested with helping in bringing more parts > > of the WebAssembly ecosystem in Debian :) I'm also interested in > > opportunities to help each other, and in the relevant packages working > > well with each other and/or providing a unified experience. Let me know > > if you can think of any such ways. > > I don't have a special interest in WebAssembly (yet) - my packaging > efforts here is targeted packaging of swt (bug#991761). That work also > involves packaging (again only a subset of crates initially for) wasmer. Wasmer too? That's even better :) Good luck! Faidon
Bug#868895: Bug#1043168: please include missing stub_flasher_32.json file
Control: block -1 by 868895 On Sun, Aug 06, 2023 at 10:12:30PM +0200, Piotr Ożarowski wrote: > I had to add stub_flasher_32.json file manually from upstream repo in > order to make my esphome (not yet in Debian, working on it) work with > ESP32 WROOM 32 board. > > Please include this file in the package. TIA Not sure if that's entirely clear to you (apologies if it is): that file isn't "just" a JSON data file that has been accidentally omitted from the package. It's in fact a (JSON-wrapped) binary, compiled from C sources bundled with the esptool source (and built with gcc, and a libc and everything). So it's not a matter of including the file, but rather rebuilding it. A lot of work has happened in Debian and with upstream over the years to build these binaries from unmodified sources, which culminated with Debian shipping the stubs for the ESP8266, as well as for the ESP32 RISC-V variants (ESP32-C2, ESP32-C3, ESP32-C6, ESP32-H2). See the 4.5.1+dfsg-0.1 and 4.6.2+dfsg-0.1 changelog entries, Debian bug #948096, as well as upstream issues #458, #499 and PRs #500, #501, #856, #858. The reason that the same has not happened yet for the ESP32, ESP32-S2 and ESP32-S3 stubs is that we lack the toolchain for them in Debian (gcc, binutils & picolibc). picolibc seems to have gained ESP32 support upstream in 1.7.9, and Keith Packard is both upstream and the Debian maintainer for it, so I suppose it won't be too hard to persuade him. gcc and binutils are more complicated. #868895 provides some context, and Jonathan McDowell, who maintains gcc-xtensa-lx106 and binutils-xtensa-lx106, is aware of the need. I think there is more of a backstory there, but he has the details. Note that the ESP-IDF is thankfully *not* needed anymore (see upstream #458). As an alternative, we could probably ship these three stubs as built by upstream separately in non-free, but I wasn't motivated enough, and I was hoping we'd get the toolchain in Debian at some point. (I'm not even the maintainer for esptool. If you're interested, I'm sure Milan will appreciate the help!). Finally, note that the stub isn't always necessary. --no-stub should work for some, but not all, operations, sometimes at slower speeds. Hope this helps! Faidon
Bug#1080344: ITP: bcachfs-tools -- bcachefs userspace tools
On Mon, Sep 02, 2024 at 08:58:38PM +0200, Daniel Gröber wrote: > In my mind bcachefs is still under development so stable just isn't the > right place for it yet and thats where all this friction is stemming > from. We were perhaps just a bit over-enthusiastic in trying to have it > there already? > > [...] > > I don't agree with that unconditionall. Each maintainer in Debian is > perfectly able, if they are willing, to ignore policy at their own > political/organizational peril. > > In my experience so far these are usually little things, but I don't see > why this must be so. > > This is the kind of ridgidity Kent is obviously upset about IMO. > > I've mentioned this on IRC in #debian-devel, but have you considered > bcachefs-tools may not be suitable for stable however debian-fasttrack > exists and is so far as I know explicitly designed for software with fast > moving support timeframes such as Gitlab but perhaps also bcachefs-tools. No, I don't think this is where all the friction lies. That was a (small) part of it. Upstream's primary issue AIUI is: "Debian (as well as Fedora) currently have a broken policy of switching Rust dependencies to system packages. [...] We're primarily talking about the package in Debian _unstable_, although the ancient -tools package in stable is also causing problems"[1]. I believe the outdated versions of software that *unstable* carries, and the fact that dependencies need to be relaxed by patching Cargo.toml, etc. is also a major sticking point. It is my belief that this is going to be the major source of friction that you will have to deal with, either by setting some expectations at the beginning of your collaboration as a I suggested, or in perpetuity throughout the lifetime of this package (e.g. every time a package in the build-dep chain lags behind). For what it's worth, I certainly don't think ignoring existing Rust packaging practice, but rather fetching all all dependencies and sub-dependencies manually from crates.io and vendoring them to the source package is the way to go, especially for the sole reason of "bcachefs upstream thinks bcachefs-tools should be packaged in this way". There /is/ a concrete issue with the older version of rust-bindgen that we carry, however. This is the issue that I mentioned in my previous correspondence (#1078698). I do think this should be resolved with either a backport (i.e. my attempt at a compromise) or working with the Rust maintainers to upload a newer upstream. It's not just for the benefit of i386, but rather to fix an issue where the issue lies rather than patching bcachefs-tools to work around it. 1: https://lore.kernel.org/linux-bcachefs/917737081.127.1723057453...@mail.carlthompson.net/T/#t > > It looks like his issues are with the Debian maintainer having to stick > > with certain policies (primarily: not vendoring), rather than an issue > > with the bcachefs-tools packaging specifically, or Jonathan. For > > example, see: > > https://news.ycombinator.com/item?id=41408628 > > > > In my opinion, he also has a history of being uncompromising, > > unprofessional, and unempathetic towards the work of others including > > contributors and collaborators. > > Thanks for the links I hadn't seen those yet. Your assessment essentially > mirrors mine from the IRC interaction I mentioned above except for the the > "unprofessional" bit. I know too many people that act exactly like this in > their profession so I find this misleading and potentially hurtful for > Kent. Let's try to not make things even worse please. I would personally not accept being told to "stop wasting my time with this stupid bullshit"[2] and "[you] really screwed the pooch"[3] from e.g. a colleague, vendor or customer (i.e. what you would call a "professional setting") and would ask the individual to retract and promise to do better before continuing to work with them. I'm also pretty sure I'd be asked to leave from any professional establishment (like e.g. a bank or restaurant) if I spoke to its staff in this way, and conversely would certainly leave myself if I was spoken to in this way. I hope we can agree on that, but we can also agree to disagree. In any case, I don't think it'd be productive to litigate upstream's conduct any further. My goal here was for you to have all the facts, and I hope you at least have a clearer picture compared to when this conversation began! 2: https://lore.kernel.org/linux-bcachefs/917737081.127.1723057453...@mail.carlthompson.net/T/#t 3: https://www.reddit.com/r/bcachefs/comments/1f4erbg/comment/lkped4c/ Hope this helps, Faidon
Bug#1081247: ITP: tox-uv -- tox plugin replacing virtualenv and pip with uv
Package: wnpp Severity: wishlist Owner: Faidon Liambotis X-Debbugs-Cc: debian-de...@lists.debian.org, eam...@debian.org Control: block -1 with 1069776 * Package name: tox-uv Version : 1.11.3 Upstream Contact: Bernát Gábor * URL : https://github.com/tox-dev/tox-uv * License : Expat (MIT) Programming Lang: Python Description : tox plugin replacing virtualenv and pip with uv tox-uv is a tox plugin which replaces virtualenv and pip with uv in your tox environments. uv is an extremely fast Python package installer and resolver. Note that you will get both the benefits (performance) or downsides (bugs) of uv. Notes: - I intend to maintain this package as part of the Debian Python Team. Co-maintainers/Uploaders more than welcome. - This is a plugin by the tox author themselves. I've verified with them that it will remain a plugin. - This plugin (obviously) requires "uv" which is not currently in Debian, ITP: #1069776. Depending on how long this ITP takes to materialize, I may upload a version of this plugin that allows one to use tox-uv with "uv" installed manually or through pipx.
Bug#1003128: ITP: wasmedge -- High performance WebAssembly Virtual Machine
owner 1003128 ! thanks On Wed, Aug 24, 2022 at 02:19:46PM +0300, Faidon Liambotis wrote: > On Fri, Jul 22, 2022 at 03:40:13PM +0200, Faidon Liambotis wrote: > > I have prepared a package for 0.10.0 that is pretty much complete (i.e. > > including all metadata like debian/copyright, debian/watch etc.) and > > functional, including AOT/wasmedgec and libwasmedge_c. > > > > I needed to backport one patch from upstream (75c3890), but more > > importantly have some outstanding questions/issues around libwasmedge_c, > > that I have filed upstream bugs about (#1677¹, #1688²). Patching the > > former is trivial, but would require me to make an ABI promise that > > upstream hasn't made, so I consider this a blocker. > > Update: upstream is making progress on #1677¹, and there is a PR #1783 > out. Another update: 0.12 is around the corner and will bump the ABI, so I've decided to wait for that. I'm waiting on upstream to also fix #1869 to avoid having to deal with DFSG-repacked sources -- the latest update from yesterday is that it will be part of 0.12. Faidon
Bug#1031298: ITP: pyproject-api -- API to interact with Python pyproject.toml-based projects
Package: wnpp Severity: wishlist Owner: Faidon Liambotis X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: pyproject-api Version : 1.5.0 Upstream Author : Bernát Gábor * URL : https://github.com/tox-dev/pyproject-api * License : Expat Programming Lang: Python Description : API to interact with Python pyproject.toml-based projects pyproject-api aims to abstract away interaction with pyproject.toml style projects in a flexible way. pyproject-api is a new dependency of tox, in the 4.x series, currently slated for experimental. I intend to maintain this package as part of the DPT. The package is trivial, but if anyone is interested in helping maintain it, or with tox's maintenance, you're more than welcome!
Bug#1031300: ITP: sphinx-argparse-cli -- Sphinx extension to render CLI arguments defined by the argparse module
Package: wnpp Severity: wishlist Owner: Faidon Liambotis X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org * Package name: sphinx-argparse-cli Version : 1.11.0 Upstream Author : Bernát Gábor * URL : https://github.com/tox-dev/sphinx-argparse-cli/ * License : Expat Programming Lang: Python Description : Sphinx extension to render CLI arguments defined by the argparse module sphinx-argparse-cli is an extension for Sphinx to render documentation for command-line interface (CLI) arguments defined by the argparse module. . Unlike the sphinx-argparse module, this module is more capable with regards to CLI interfaces that utilize sub-commands. A notable example is the "tox" project, from which this module originates. The package is trivial, but if anyone is interested in helping maintain it, or with tox's maintenance, you're more than welcome!
Bug#1032143: ITP: python-pkcs11 -- high level PKCS#11 interface for Python
Package: wnpp Severity: wishlist Owner: Faidon Liambotis X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-pkcs11 Version : 0.7.0 Upstream Author : Danielle Madeley * URL : https://github.com/danni/python-pkcs11/ * License : Expat Programming Lang: Python Description : high level PKCS#11 interface for Python A high level, "more Pythonic" interface to the PKCS#11 (Cryptoki) standard to support HSM and Smartcard devices in Python. . The interface is designed to follow the logical structure of a HSM, with useful defaults for obscurely documented parameters. Many APIs will optionally accept iterables and act as generators, allowing you to stream large data blocks for symmetric encryption. . It also includes numerous utility functions to convert between PKCS#11 data structures and common interchange formats including PKCS#1 and X.509. . The library is fully documented and has a full integration test suite for all features, with continuous integration against multiple HSM platforms including Entrust nShield, Opencryptoki TPM and OpenSC/Smartcard-HSM/Nitrokey HSM. New optional dependency for esptool, a package that I am trying to help with. I intend to maintain this package as part of the Debian Python Team. Co-maintainers/Uploaders more than welcome.
Bug#1016183: RFH: crun -- lightweight OCI runtime for running containers
On Thu, Jul 28, 2022 at 06:39:21PM +0200, Bastian Germann wrote: > Package: wnpp > > The crun maintainer has requested help in #1014306. I've done a few uploads since (1.5+dfsg-1, 1.8-1 and 1.8.1-1), as well as prepared an upload for a bullseye-pu (#1031109). Reinhard also worked on the package a fair bit, and was added as a comaintainer with 1.8-1. We could always use more hands, but as far as wnpp goes, I think the maintainer got some help :) Faidon
Bug#1030845: RFP: sbctl -- Secure Boot Manager
On Wed, Feb 08, 2023 at 11:32:50AM +0100, Marco d'Itri wrote: > Package: wnpp > Severity: wishlist > > * Package name: sbctl > Version : 0.10 > Upstream Contact: Morten Linderud > * URL : https://github.com/Foxboron/sbctl/ > * License : MIT > Programming Lang: Go > Description : Secure Boot Manager I've pushed: https://salsa.debian.org/go-team/packages/sbctl as well as the missing dependency: https://salsa.debian.org/go-team/packages/golang-github-foxboron-go-uefi Note that there are two debian/patches for sbctl: 1) First, to use FHS paths, diverging from upstream's locations (which is non-ideal). Upstream issue #57 is open upstream: https://github.com/Foxboron/sbctl/issues/57 2) Second, to disable TPM support. It requires a long dependency chain for Go-Attestation that it felt too overwhelming for me. YMMV :) This package builds and works for me. I'm not up for maintaining it in the long-run though, so I'm leaving this as an RFP and *not* uploading it to unstable. Hopefully this initial packaging work is useful to whoever decides to pick it up. If anyone else is up for it, I may be available to sponsor the uploads and/or provide code reviews. Best, Faidon
Bug#1068131: ITP: bootterm -- simple terminal to ease connections with SBCs
Package: wnpp Severity: wishlist Owner: Faidon Liambotis X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: bootterm Version : 0.4+git2023013 Upstream Contact: Willy Tarreau * URL : https://github.com/wtarreau/bootterm * License : Expat Programming Lang: C Description : simple terminal to ease connections with SBCs Bootterm is a simple, reliable and powerful terminal designed to ease connection to ephemeral serial ports as found on various SBCs, and typically USB-based ones. . Main features: * automatic port detection (uses the most recently registered one by default) * enumeration of available ports with detected drivers and descriptions * wait for a specific, a new, or any port to appear (convenient with USB ports) * support for non-standard baud rates (e.g. 74880 bauds for ESP8266) * can send a Break sequence and toggling RTS/DTR for various reset sequences, even on startup * fixed/timed captures to files (may be enabled at run time) * optionally time-stamped captures (relative/absolute dates) * reliable with proper error handling * single binary without annoying dependencies, builds out of the box * supports stdin/stdout to inject/download data * configurable escape character and visible character ranges Note that upstream has chosen /usr/bin/bt for the binary's name, but I'm trying to persuade them to use /usr/bin/bootterm instead, in order to avoid taking up a two-letter name in Debian's shared $PATH namespace, for what is intended to be a binary for a niche audience. At minimum I'd expect us to carry a Debian-specific patch.
