Bug#1017361: ITA: postsrsd -- Sender Rewriting Scheme (SRS) lookup table for Postfix
Hi, On 16-07-2023 22:35, Timo Röhling wrote: I think this was not forwarded to Oxan, so I'm resending it to You're right, thanks for the forward. On Sun, 11 Jun 2023 23:09:11 +0530 Abhijith PA wrote: Hello, I would like to adopt this package. I maintain a mailing list server where I am already using postsrsd. That's great! The packaging is currently hosted in the Debian group on Salsa, so as a DD you should already have access to it. I'm not aware of anything that needs to be done for the handover, so feel free to take over that repository (or move it elsewhere, if you prefer), and to upload a new version with you listed as Maintainer. If you've any questions about the current packaging, don't hesitate to reach out! Cheers, Oxan
Bug#757720: ITP: postsrsd -- Sender Rewriting Scheme (SRS) lookup table for Postfix
Package: wnpp Severity: wishlist Owner: Oxan van Leeuwen * Package name: postsrsd Version : 1.1 Upstream Author : Timo Röhling * URL : https://github.com/roehling/postsrsd * License : GPL-2+ Programming Lang: C Description : Sender Rewriting Scheme (SRS) lookup table for Postfix PostSRSd provides Sender Rewriting Scheme (SRS) support for Postfix via TCP-based lookup tables. SRS is needed if your mail server acts as a forwarder, and the mail originates from a server with Sender Policy Framework (SPF) enabled. -- 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/debian-wnpp
Bug#515793: RFP: cgit -- C-code Web Front-end to GIT
Hi, On 19-02-14 00:47, YAEGASHI Takeshi wrote: Oxan, have you already worked on your own cgit package built with something like git-source binary package? Please let me know if you made any progress. I might be able to contribute to your package! No, unfortunately I hadn't made any progress. I tried to get it working using a git-source package, but the Git package is quite complex and I couldn't get it working, so I gave up in the end. The lack of debhelper in the git package didn't help either (which might be because I'm not very knowledgeable on low-level package building). Cheers, Oxan -- 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/530634c3.7090...@oxanvanleeuwen.nl
Bug#729781: ITP: subliminal -- Command-line tool to search and download subtitles
Hi, On 17-11-13 11:56, Etienne Millon wrote: I intend to maintain this package within the Debian Python Modules Team. It has a few unpackaged dependencies (I'll file RFPs and/or ITPs if there is no objection to the inclusion of subliminal): - python-charade (ITP #698258, not sure if replaceable by chardet) - python-enzyme (same author ; https://github.com/Diaoul/enzyme ; Apache2) - python-babelfish (same author ; https://github.com/Diaoul/babelfish ; BSD-3) - python-guessit (https://github.com/wackou/guessit ; LGPLv3) - python-pysrt (https://github.com/byroot/pysrt ; GPLv3) I've just finished and published my packaging of subliminal and its dependencies yesterday: - python-charadehttps://github.com/oxan/charade-debian - python-enzyme https://github.com/oxan/enzyme-debian - python-babelfish https://github.com/oxan/babelfish-debian - python-guessithttps://github.com/oxan/guessit-debian - python-pysrt https://github.com/oxan/pysrt-debian - subliminalhttps://github.com/oxan/subliminal-debian Feel free to re-use (parts of) the packaging. I'm also a DPMT member, so I'm willing to help out with the packaging there later on too (I didn't push to DPMT initially because Alioth is down and I'm not sure whether I can personally invest enough time to keep them up to Debian quality standards). -- 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/5288b6af.80...@oxanvanleeuwen.nl
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
Hi, On 04-08-13 00:59, Jonathan Nieder wrote: I'd like to propse another solution for this: let git build a git-source binary package, and build cgit using that package. I would prefer not to go this way. It would mean that when I make git uploads, they'd always have a chance of breaking the cgit build without notice. And it would also mean that whenever I fix an important bug I have to track down whether cgit needs to be rebuilt. Yes, that's true. (Unfortunately Debian doesn't have CI-infrastructure available to rebuild cgit on all commits to the git package. I think that could have been a good compromise). An alternative that is not as bad is to export libgit.a (or .so, for that matter) and headers for cgit use. Wouldn't exporting the static library suffer from the same problems as exporting the source? cgit will still need to be rebuild to profit from bug fixes in git, and git can still break its build without notice. Exporting the shared library would of course prevent the first problem. However, some of the discussion in #407722 indicated that git upstream doesn't want libgit to be exported, and the Debian maintainers didn't want to overrule them. If that has changed, great :) I think git breaking cgit's build isn't that big of a problem. cgit upstream seems to be active enough in fixing compatiblity with newer git versions, and the required changes are in general quite small (upgrade from 1.7.7.4 to 1.8.3 required just 6 lines of code in total). So if you don't have a problem with exporting libgit anymore, I think that's the way we should go, and I'll create cgit packages using them. I'd far prefer to just have a copy of cgit built as part of the git build. It doesn't have to involve multiple upstream tarballs: e.g., cgit can be included in the debian/ directory in the debian.tar.xz in the short term, and in the long term I think it would be a candidate for inclusion in contrib/ upstream. Building two projects with separate release cycles and upstreams from the same source package just feels wrong to me, and I prefer to not do it, especially as the git package already seems quite complex. > All that said, if someone wants to add another binary package like > git-source to the git build and is willing to maintain it in the long > term, I'll be glad to help (and wash my hands of the day-to-day > maintenance :)). > > See /usr/share/doc/git/README.source for hints on working with the > package. Packaging is at git://git.debian.org/~jrnieder-guest/git.git I'll take a stab at doing that. Maintaining it long-term shouldn't be a problem. (fyi, the Vcs-* fields in the package indicate another repository. Might be useful to synchronize the repositories and/or changes the Vcs-* fields.) Cheers, Oxan -- 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/51fee388.1090...@oxanvanleeuwen.nl
Bug#515793: ITP: CGIT -- C-code Web Front-end to GIT
Hi Jonathan, Marc, On 29-07-12 18:19, Jonathan Nieder wrote: I would be very happy to see cgit in Debian. Perhaps we could approach this by building cgit from the git source package, either using dpkg source format 3.0's multiple-tarball feature or by including cgit in the Debian patch. Would you be interested in this approach? Do you have initial cgit packaging to play with? I'd like to propse another solution for this: let git build a git-source binary package, and build cgit using that package. I see a few advantages for this over building cgit from the git source package: - It doesn't group multiple separate projects into a single source package. While technically possible with the 3.0 source format, having separate source packages is more logical imo. - If cgit is broken due to a change in git, the git package doesn't FTBFS. This has the added advantage of cgit not holding up new releases, testing migrations, etc. of git. - Smaller packages are easier to maintain in my experience, though that's a bit subjective of course. The obvious downside is introduction of a new -source package. Since we cannot build-depend on source packages yet, and there are already ~80 such packages in the archive, I think this is acceptable. With the recent Built-Using introduction this also doesn't impose any licensing problems. If this route is acceptable for the git maintainers, I'm willing to step up as cgit (co-)maintainer. If someone else wants to join too, that's great! ;) Regards, Oxan -- 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/51fd870c.4040...@oxanvanleeuwen.nl
Bug#663006: libnfc
Control: retitle -1 RFP: libnfc -- Near Field Communication (NFC) library Control: unblock 663006 by 672795 Hi, I'm no longer interested in packaging this due to changing interests and shifting priorities. If anyone else wants to package this, you can find the start of my packaging in the SVN repository mentioned earlier (BSD-licensed). -- 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/50a91c40.8080...@oxanvanleeuwen.nl
Bug#663006: libnfc co-maintainer?
Hi, On 23-05-12 15:49, Ludovic Rousseau wrote: I created a (empty) SVN repository. To get it use: $ svn co svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/libnfc Bye Great! I've imported my current libnfc package into the repository (using debian/ only, but we can change that if you want). Most notable changes with the upstream packaging are: - I renamed the libnfc-bin package to libnfc-utils and dropped the libnfc-examples and libnfc-pn53x-examples. I'm not sure how useful the examples are for end-users. - Enabled multi-arch for the library package - Added an libnfc3-dbg package - Currently it still requires pcsc due to the acr122 driver. We might want to change that, but I'm a bit reluctant because the USB driver isn't in the 1.6.0~rc1 version yet. Regards, Oxan -- 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/4fbd3db0.3050...@oxanvanleeuwen.nl
Bug#663006: libnfc co-maintainer?
Hi, On 22-05-12 08:39, Thomas Hood wrote: Upstream contains a rather verbose debian/changelog. Could this be edited down, renamed and/or merged with ChangeLog so that debian/changelog contains exclusively a log of *Debian's* work? Or how do you feel about this? -- Thomas Hood (Maintainer of provisory libnfc packages at ppa:jdthood/nfc) In my experience the Debian changelog usually starts empty when an package is uploaded to Debian for the first time. I think most, if not all, information in the upstream debian/changelog is already in ChangeLog, which I intend to ship as the upstream changelog in the Debian packages. Regards, Oxan van Leeuwen -- 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/4fbb7bc2.3060...@oxanvanleeuwen.nl
Bug#663006: libnfc co-maintainer?
Hi Ludovic, On 21-05-12 16:59, Ludovic Rousseau wrote: Hello Oxan van Leeuwen, I am a Debian Developper and also a libnfc upstream maintainer (since a few days). It looks like you are not yet a DD and may be looking for a sponsor. That's great! Actually, I think you already applied the patches I created while packaging ;-). For reference, last week I have submitted the RFS as #672795 indeed. I propose you to use collab-maint projet on alioth to host the debian/* packaging files. It will then be easy to co-maintain the NFC-related packages. That sounds like a good idea. I think the current procedure for getting access to collab-maint is the one in http://deb.li/3qmXG, so I've applied to the collab-maint project at Alioth (username oxan-guest). I already made some changes to the debian/* files in https://libnfc.googlecode.com/svn/trunk/debian to fix some lintian warnings but I also prefer to have the debian/* files in a separate repository. Great. I'll take a look at them and merge the relevant changes to my packaging. Cheers, Oxan van Leeuwen -- 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/4fba93d4.4050...@oxanvanleeuwen.nl
Bug#663006: Progress?
Hi, On 08-05-12 14:02, Thomas Hood wrote: How's it going with the packaging of libnfc? Are you waiting for the 1.6.0 release? No, not really. I still have to finish up the copyright documentation and want to fix some "regressions" compared to 1.5 (mainly some functions that output to stdout, which a library shouldn't do). Unfortunately I've been a bit short on time lately, but I hope to open an RFS in the coming weeks. Cheers, Oxan -- 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/4fad66e0.2080...@oxanvanleeuwen.nl
Bug#663006: Why libnfc over The Linux NFC Subsystem ?
Hi, Thanks for your input! On 13-03-12 13:49, Andreas Henriksson wrote: You could ofcourse package anything you wish, but including it in Debian is another question for me. Including it in Debian means you are prepared to maintain it in the long run. Several years to come. I'd avoid introducing lots of programs that depend on the libnfc API which you'll later need to port over to a new API and/or provide a migration path for users to new tools that has been developed for the new stack. You're ofcourse welcome to disagree. That is only true assuming that libnfc will eventually completely disappear. Especially given the response from upstream (see Thomas' mail), I doubt that will happen. libnfc has some more features which probably won't ever make it to the kernel (mfoc has already been mentioned). There is also the possibility of writing a libnfc driver that uses the kernel module, so that they can exist (and be used) together. Even if it will be completely replaced by the NFC subsystem, I think the benefits of having a complete NFC stack in wheezy outweighs the drawback of having a migration later on. Packages have been removed and superseded since the earliest Debian releases, and when there is a (better) alternative available, that shouldn't cause much problems. Cheers, Oxan van Leeuwen -- 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/4f5fbc15.2070...@oxanvanleeuwen.nl
Bug#663006: Why libnfc over The Linux NFC Subsystem ?
Hi, On 12-03-12 19:20, Andreas Henriksson wrote: Could you please describe why you're interested in working on getting libnfc into Debian now that we have The Linux NFC Subsystem? I'm willing to bet my money on that the latter is the one who will survive in the long run While the Linux NFC subsystem might indeed have the best chances to survive on the long term, I think currently libnfc is in a better state. The NFC subsystem only appeared in Linux 3.1 and still has a long way to go before it equals the functionality of libnfc. I couldn't find equivalents of relatively simple programs like nfc-mfclassic. I also think it's nice to be able to update libnfc independent from your kernel, especially since NFC development (in general) has quite a high pace nowadays. Besides, there are applications that require libnfc. That is because they either were designed before the NFC subsystem was born, or need to be compatible with other operating systems too. I'd be a shame if we couldn't package those applications for Debian. Cheers, Oxan -- 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/4f5e4632.6010...@oxanvanleeuwen.nl
Bug#663006: ITP: libnfc -- Near Field Communication (NFC) library
Package: wnpp Severity: wishlist Owner: Oxan van Leeuwen * Package name: libnfc Version : 1.6.0~rc1 Upstream Author : multiple people * URL : http://www.libnfc.org/ * License : LGPL-3 Programming Lang: C Description : Near Field Communication (NFC) library libnfc is a library for Near Field Communication. It abstracts the low-level details of communicating with the devices away behind an easy-to-use high-level API. Supported NFC hardware devices are, theorically, all hardware based on the NXP PN531, PN532 or PN533 NFC controller chip. I also intend to package the libraries and applications from the nfc-tools project (http://code.google.com/p/nfc-tools/), based upon libnfc. In the ideal case a NFC packaging team that handles all NFC-related packages could be formed. I am not a Debian Developer though, so it would be nice if an interested DD could join. -- 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/debian-wnpp
Bug#610654: ITP: python-gearman -- Python interface to the Gearman library
Package: wnpp Severity: wishlist Owner: Oxan van Leeuwen I want to package the python-gearman library, as it's a lot easier to use then python-gearman.libgearman and it has better documentation. * Package name: python-gearman Version : 2.0.2 Upstream Author : Matthew Tai * URL : http://github.com/mtai/python-gearman/ * License : Apache 2.0 Programming Lang: Python Description : Python interface to the Gearman library Gearman is a system to farm out work to other machines, dispatching function calls to machines that are better suited to do work, to do work in parallel, to load balance lots of functions calls, or to call functions between languages. This package contains a Python interface to the library, allowing Python scripts to send and receive Gearman jobs. -- 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/20110120193356.15161.71144.report...@localhost.lan
