Bug#992338: O: tclcurl -- Tcl bindings to libcurl
Package: wnpp Severity: normal Control: affects -1 src:tclcurl I intend to orphan the tclcurl package. The package description is: This module enables the use of libcurl in Tcl scripts. Please refer to the libcurl documentation available in the libcurl4-gnutls-dev package. . NOTE: the SSL support is provided by GnuTLS. This package is without an active upstream. Lately there has been some activity by flightware guys in https://github.com/flightaware/tclcurl-fa/ but the current package is _not_ based on this one. There is also additional activity in https://www.androwish.org/index.html/timeline?chng=jni/TclCurl/* with occasional fixes. The git repo I used to maintain this package with gbp is still referenced and available. If a new maintainer would like to continue on this code base it's possible to clone it to host it on salsa or somewhere else. Regards, Sven
Bug#992337: O: mysqltcl -- interface to the MySQL database for the Tcl language
Package: wnpp Severity: normal Control: affects -1 src:mysqltcl I intend to orphan the mysqltcl package. The package description is: The mysqltcl package provides a Tcl interface to the MySQL database system. Within Tcl you've a range of Tcl commands and a global Tcl array available to access the database server. Written in C mysqltcl uses the official MySQL C-API so that almost all Tcl commands correspond to MySQL C-API functions. I tried to give the package a little bit of love but do not use it anymore. The git repo I used to maintain it in with gbp is still available for a potential adopter to clone from if he likes to. The last upstream release happened in 2012, so it's been a while. In general the upstream author replied to mails and applied patches in the past. Regards, Sven
Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems
On Sun, Jul 05, 2020 at 09:35:14AM +0300, Andrei POPESCU wrote: > On Sb, 04 iul 20, 19:56:45, s...@stormbind.net wrote: > > While fuse-exfat can be coinstalled at any moment exfat-utils and > > exfatprogs will for now conflict with each other. > > Isn't this the typical use-case for alternatives? IMO sensible if you have two packages which are likely to be coinstalled often. For those kind of niche tools I've here I do not want user to be bothered to figure out which alternative is selected and which he would actually like to use. Additionally the native names of the tools shipped in exfat-utils are /sbin/dumpexfat /sbin/exfatfsck /sbin/exfatlabel /sbin/mkexfatfs So probably the midterm will be that the exfatprogs provide the kind of "official" mkfs.exfat and fsck.exfat tools. But for now I prefer to keep the already tested exfat-utils in place. If you want to rely on the exfatprogs tools I assume that is a conscious decision and you're ok with letting go of the exfat-utils implementation. In case there is some overboarding interest in always having both installed, and bothering user with managing alternatives in case he'd like to switch between implementations, I might change that. But for now I do not believe it would offer value for the average user. The only case I can imagine right now that would break is desktop environment 1 depends on exfatprogs and desktop environment 2 depends on exfat-utils and a user has both DEs installed. But even here using alternatives might call for bad surprises when parameter differ. So I believe even in this case we are all better off for now if the packages conflict and thus make clear that they are different tools, and should not be installed in parallel, at least not with the same binary names. (I did not yet check if they are flag by flag compatible or not) Cheers, Sven
Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems
On Sat, Jul 04, 2020 at 02:49:15PM -0400, Nicholas D Steeves wrote: Hi Nicholas, > > Since people started to ping me about getting this one introduced > > I now give in and pick it up. I plan to continue for now the > > maintenance of the fuse-exfat and exfat-utils packages. > > While fuse-exfat can be coinstalled at any moment exfat-utils and > > exfatprogs will for now conflict with each other. > > Maybe I later on drop the mkfs.exfat and fsck.exfat links from > > the exfat-utils package. > > Might /etc/alternatives also be considered for mkfs.exfat and > fsck.exfat? > Also, what about /sbin/mount.exfat? That one also seems > like a candicate for /etc/alternatives. Yes I thought about it, I also thought about dropping the symlinks similar to the mount.exfat helper issue with fuse-exfat. Right now I believe we should cater for the general use cases which probably is someone wanting to mount an exfat filesystem with the most convenient and fast driver, which is the kernel based one. So if you have a reason to still want to use the fuse driver you make an explicit choice. That's when I expect you to be able to invoke the mount.exfat-fuse helper. One thing to note is that there is no alternative for the mount.exfat helper, either it's there or it's not. Michael proposed a thin wrapper in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963752 but I do not believe that helps the average user. That's why I droped the symlink from the package. Now back to the utils situation: Here we could use alternatives, but I believe for the average user that will be even more confusing. Luckily upstream of the exfatprogs made the concious decision to not create a naming colision with the existing exfat-utils package, so user have a chance to recognise the different upstream sources. I believe it's more straight forward to let the user select the implementation he prefers and just make sure we do not have the naming conflict of the binaries. The other, longterm more likely option from my point of view, is to drop the mkfs.exfat and fsck.exfat links, and let the user invoke exfatfsck and mkexfatfs binary provided by the package. I do not want to make that change right now, and would prefer to wait a bit if we see some bugs with the exfatprogs implementation, > Probably tangential: I wonder if this is a case where a virtual package > (where both the Samsung and the exfat-utils Provide exfat-tools or > similar) could be considered? As you know, I'm primarily interested in > backports, and I wonder if whatever the kernel team does with Wireguard > would be a useful precedent to follow. eg: if newer kernels Provide: > feature that that was previously wireguard-dkms. 'not sure if that's > over-engineering dependency and feature resolution though ;-) I believe the use case here is so narrow that we should keep it as simple as possible. Cheers, Sven
Bug#945524: RFP: container-diff -- Diff Docker containers
On Fri, Dec 27, 2019 at 03:58:38PM -0500, James Montgomery wrote: Hi, > I know that Sven has done some initial manual work to get bytefmt started, > but he noted it may be a bit outdated. If you like, we can get > dh-make-golang fixed and attempt to bring in bytfmt using dh-make-golang. I believe I must have figured out some way to auto generate that package with dh-make-go. Looking at the files in debian/ I don't think I copy&pasted that manually. But really, feel free to start from scratch with current standards et al. All I remember is that I stopped at some point because a module was hosted in a mercurial repo and that was somewhat painful to deal with. Sven
Bug#945524: RFP: container-diff -- Diff Docker containers
On Sat, Dec 28, 2019 at 01:46:27AM +0530, Utkarsh Gupta wrote: Hi, > Many, many thanks for this! I also updated it by now to a new snapshot, so the repo now has the latest code. > I'll polish this further and upload it at the earliest! > > D'you intend to maintain it, as well? :D > Or shall I take it from here? Feel free to take it, the git log is horrible, even without a proper name and mail set. So I don't even mind if you just copy the debian subdir or something like that. I usually license my contributions under the license used by the upstream project. That beeing said, I would really like to contribute more to Debian again, but I failed to do so for the past two years. So don't count on me. If you form a team or add container-diff to an existing team I would join (hoexter@d.o) and try to free some hours at work to help a bit. If required I can also help to sponsor uploads, though my go packaging experience is very small. I really appreciate you put some time into packaging container-diff. :) Sven
Bug#945524: RFP: container-diff -- Diff Docker containers
On Fri, Dec 27, 2019 at 11:19:32PM +0530, Utkarsh Gupta wrote: > Well, I am having a bit of a difficulty to package bytefmt. > I reported this issue with dh-make-golang here[1]. > > It'd be really helpful if you can help me get that packaged somehow? > I'd be interested in maintaining bytefmt further for container-diff > though :) Apparently I started to look into containerdiff and bytefmt some longer time ago. I have some old packaging based on an older snapshot around. I just pushed it, but this is very very basic, but this snapshot still builds here git clone https://git.sven.stormbind.net/bytefmt.git Not sure if that helps, will try to bring it up to a new snapshot. Sven
Bug#939577: ITP: jattach -- JVM Dynamic Attach utility all in one jmap jstack jcmd jinfo
Package: wnpp Severity: wishlist Owner: Sven Hoexter * Package name: jattach Version : 1.5 Upstream Author : Andrei Pangin * URL : https://github.com/apangin/jattach/releases * License : Apache 2.0 Programming Lang: C Description : JVM Dynamic Attach utility all in one jmap jstack jcmd jinfo jattach is a utility implementing commands for the JVM Dynamic Attach mechanism. Instead of installing a complete JDK you can use this small utility to query information from your running JVM.
Bug#634757: Adoption of lyx
On Sun, Oct 08, 2017 at 05:47:26PM +0200, Dr. Tobias Quathamer wrote: Hey, > In case of packaging problems and questions, may I contact you again? Sure, I'm still alive and have an eye on pkg-lyx-devel@lists.a.d.o as long as alioth is around. But you can also approach me directly. Sven signature.asc Description: PGP signature
Bug#634757: Adoption of lyx
On Sun, Oct 08, 2017 at 05:10:42PM +0200, Dr. Tobias Quathamer wrote: Hey, > I've seen that you, Sven, have removed yourself from the uploaders. I > don't know if Nick is a DD and still interested in the package. He's not (yet) a DD. > If there's currently noone actively packaging lyx, I'll adopt the > package completely. However, if Nick is still interested, that would be > great! Please go ahead! There quite a few barely tested changes I made to the packaging lingering in git master because the lintian on ftp-master is a bit dated and still rejected the lyx@packages.d.o email address as maintainer address. Not sure if that's solved by now. Maybe you've to revert that change for a few more weeks in case you'd like to push out the pending changes asap. > I have just asked to join the alioth group for git access. I just added you as an admin. Cheers, Sven signature.asc Description: PGP signature
Bug#634757: About adoption LyX
Hi guys, Liviu Andronic just made me aware of several people who would like to adopt the LyX package. I'll now CC everyone whom I see as interested because you've fallen in a little trap of the BTS. You just wrote to the RFA bug report but did not post on the pkg-lyx-devel mailinglist or otherwise pinged the former maintainer. We don't read the bugreport and I for one am not subscribed to the bug itself. Since the RFA bug is filled against the wnpp pseudo package we don't receive your mails. So here is the beef: Most infrastructure information has been collected in the Debian Wiki http://wiki.debian.org/PkgLyx You can start just from there and clone the repo and maybe start to send patches/pull requests to the mailinglist. If you've some history within Debian that shows that you know a few basics about Debian package building it's of course possible to add you to the project so you can commit to the central git repo. You've to create a alioth guest account for that on http://alioth.debian.org. Even if I didn't work on LyX in the last years I'm still willing to sponsor uploads and help with questions about the packaging. Please direct any further questions to the pkg-lyx-devel mailinglist and and join the list. Cheers, Sven -- We are what you say We are not what you think [ Dead Sara - We are what you say ] signature.asc Description: Digital signature
Bug#625611: Retitle to ITP
retitle 625611 ITP: exfat -- Free exFAT file system implementation for FUSE owner 625611 s...@timegate.de thanks Just started to create the two packages, current repos are at http://git.sven.stormbind.net/?p=sven/fuse-exfat.git;a=summary http://git.sven.stormbind.net/?p=sven/exfat-utils.git;a=summary -- 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/20111229120605.gc2...@sho.bk.hosteurope.de
Bug#634759: RFA: dvipost -- Post processor for dvi files supporting change bars
Package: wnpp Severity: normal I request an adopter for the dvipost package. This will be only relevant for someone who adopts it along with lyx. Please see the RFA bug for lyx for more details. The package description is: Dvipost is a post processor for dvi files, created by LaTeX or TeX. If the command is invoked as pplatex, it integrates the call of latex and the post processing of the dvi file. . Dvipost is used for special modes, which normally need the support of dvi drivers (such as dvips). With dvipost, these features could be implemented independent of the preferred driver. Currently, the post processor supports layout raster, change bars and overstrike mode. -- 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/20110719202430.18034.81156.report...@marvin.lan
Bug#634757: RFA: lyx -- document processor
Package: wnpp Severity: normal We request an adopter for the lyx package. Both of us (pelle@ and hoexter@) no longer use lyx so we would like to hand it over. The package is currently in a good shape and most bugs are handled. Upstream is very nice and responsive and I'm still around to help if required. The package is maintained on git.d.o with git-buildpackage, pristine-tar and in 3.0 quilt source format. You can find some of the relevant links on http://wiki.debian.org/PkgLyx Please not that you should dvipost along with lyx since it's solely used with lyx afaik. elyxer, which is also in the pkg-lyx repository can be taken aswell but I'll offer to keep that for some time. The package description is: LyX is an almost WYSIWYG-frontend for LaTeX. It makes the power and typesetting quality of LaTeX available for people who are used to word processors. Since LyX supports LaTeX's concept of general mark-ups, it is even easier and faster to create professional quality documents with it than with usual word processors. It is also possible to use LaTeX commands within LyX, so nothing of LaTeX's power is lost. . You can extend the functionality of LyX by installing these packages: * chktex: check for typographical errors * dvipost: display tracked changes in DVI format output * gnuhtml2latex: import HTML documents * groff: improved table formatting in plain text exports * librsvg2-bin, inkscape: use the SVG image format in LyX documents * linuxdoc-tools: export SGML LinuxDoc documents * mythes-*: use the OpenOffice.org/LibreOffice Thesaurus * noweb: import noweb files * rcs: integrated version control * sgmltools-lite: export SGML DocBook documents * wv: import MS Word documents -- 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/20110719202304.17280.93382.report...@marvin.lan
Bug#569469: adoption
retitle 569469 ITA: courierpassd -- Change courier user passwords using poppassd interface owner 569469 s...@timegate.de thanks I'll take this. -- And I don't know much, but I do know this: With a golden heart comes a rebel fist. [ Streetlight Manifesto - Here's To Life ] -- 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/20110214175255.GF7339@marvin
Bug#599446: ITP: libapache2-mod-rivet -- Server-side Tcl programming system combining ease of use and power
On Fri, Oct 08, 2010 at 01:01:16PM +0200, Massimo Manghi wrote: Hi, > http://people.apache.org/~mxmanghi/deb/ > > obviously only version 2.0.1-3 has all the changes that were > suggested on this list An upload should be a -1 since the Debian archive has never seen the package before so you've to combine the changelog into one entry. The changes made on the way to this first upload will be only seen in your VCS if you use one. The Vcs-Git lines in debian/control should be modified to reflect that or be removed. So far I've just fed the source package to lintian and there are already a bunch of issue listed. Some of them are not that important (wishlist) but others should be tackled. If you're not already doing it you should also build the package in clean enviroment with pbuilder et. al. and afterwards, as a very basic check, feed the resulting package (via the .changes) file to lintian. I'd recommend you apt-get install lintian and look through the recommendations for yourself. If you work on Debian/stable you've to install the lintian package from backports.d.o. Sven -- And I don't know much, but I do know this: With a golden heart comes a rebel fist. [ Streetlight Manifesto - Here's To Life ] -- 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/20101008115033.ga1...@marvin.lan
Bug#549359: ITA pflogsumm
owner 549359 Sven Hoexter retitle 549359 ITA: pflogsumm -- Postfix log entry summarizer thanks I'll take it (if nobody else feels he deservers it ;). Sven -- They're the cowards We are rebels We got the power to fight the devil [ AIV - We are rebels ] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530262: packaging is available
The package is currently in the pkg-lyx svn repo: svn://svn.debian.org/svn/pkg-lyx/elyxer/trunk Unofficial builds are hosted here: http://sven.stormbind.net/debian/elyxer-pre/ -- They're the cowards We are rebels We got the power to fight the devil [ AIV - We are rebels ] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#530262: ITP: elyxer -- Standalone LyX to HTML converter
Package: wnpp Severity: wishlist Owner: Sven Hoexter * Package name: elyxer Version : 0.22 Upstream Author : Alex Fernández * URL : http://www.nongnu.org/elyxer/ * License : GPL-3 Programming Lang: Python Description : Standalone LyX to HTML converter eLyXer (pronounced elixir) is a standalone LyX to HTML converter written in Python. eLyXer has a focus on flexibility and elegant output. It's not yet possible to convert every LyX document but a lot of document types already work. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#497098: there is already an alioth project for fedora-ds
Hi, there is already an Alioth project registered for Fedora-DS: http://alioth.debian.org/projects/pkg-fedora-ds/ I mailed with Noel some time ago and he told me that the build scripts are very nasty and nobody made some real packaging progress so far. If you feel like tackling it you should maybe create an alioth account and contact Noel. HTH Sven -- If God passed a mic to me to speak I'd say stay in bed, world Sleep in peace [The Cardigans - 03:45: No sleep] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442339: There are two libtorrents in the wild
Hi, there are two projects with a libtorrent: a) http://libtorrent.rakshasa.no/ Debian source package is actually called libtorrent and b) http://www.rasterbar.com/products/libtorrent/ which is actually at version 0.13 http://jbot.de/cgkfE AFAIK this one is not packaged for Debian yet. HTH Sven -- If God passed a mic to me to speak I'd say stay in bed, world Sleep in peace [The Cardigans - 03:45: No sleep] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470766: O: curator -- Turn directories of images into static web content
Package: wnpp Severity: normal I intend to orphan the curator package. In consensus with my sponsor, Andreas Tille, I've come to the conclusion that Debian would be better of without curator because a) it's abandoned upstream for a long time now b) jigl offers a great alternative to curator and has solved a lot of the shortcomings of curator. c) popcon results are low. To be fair to the 27 regular users of curator I'm orphaning the package to give you a chance to stand up and take it over if you really, really want to keep it. If nobody steps up very soon I'll request the removal of curator in early April. So if you wan't it please take into account that you've to fix every problem with the curator script on your own. There is nobody avaible upstream to help you. I recommend to switch to jigl now and let curator die. The package description is: Curator is a powerful script that allows one to generate Web page image galleries with the intent of displaying photographic images on the Web, or for a CD-ROM presentation and archiving. . It generates static Web pages only - no special configuration or running scripts are required on the server. The script supports many file formats, hierarchical directories, thumbnail generation and update, per-image description file with any attributes, and 'tracks' of images spanning multiple directories. The templates consist of HTML with embedded Python. Running this script only requires a recent Python interpreter and the ImageMagick tools. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367391: ITP: dvipost -- Dvipost is a post processor for dvi files to support change bars and overstrike mode
Package: wnpp Severity: wishlist Owner: Sven Hoexter <[EMAIL PROTECTED]> * Package name: dvipost Version : 1.1 Upstream Author : Erich Fruehstueck <[EMAIL PROTECTED]> * URL : http://efeu.cybertec.at * License : GPL v2 Programming Lang: C Description : Dvipost is a post processor for dvi files to support change bars an overstrike mode Dvipost is a post processor for dvi files, created by latex or tex. If the command is invoked as pplatex, it integrates the call of latex and the post processing of the dvi file. . Dvipost is used for special modes, which normally needs the support of dvi drivers (such as dvips). With dvipost, this features could be implemented independent of the prefered driver. Currently, the post processor supports layout raster, change bars and overstrike mode. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-ck9 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-1) (ignored: LC_ALL set to de_DE) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#221917: I have build a fspclient package and need a sponsor
I've build a fspclient package and it's avaible from http://sven.stormbind.net/debian/dists/sarge/fspclient/ I just need someone to sponsor it. Sven -- If God passed a mic to me to speak I'd say stay in bed, world Sleep in peace [The Cardigans - No sleep] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
