Bug#907623: RFP: FileManager-Actions -- filemanager extension to configure programs to launch
Control: retitle -1 ITP: FileManager-Actions -- filemanager extension to configure programs to launch Control: owner -1 ! I intend to package this.
Bug#885983: O: tupi -- 2D Animation design and authoring tool
Control: retitle -1 ITA: tupi -- 2D Animation design and authoring tool Control: owner -1 ! I'd like to adopt this package. On Mon, 01 Jan 2018 20:51:58 +1100 Dmitry Smirnov wrote: > Package: wnpp > Severity: normal > Control: affects -1 tupi > X-Debbugs-CC: i...@maefloresta.com > > I have no capacity left to maintain _tupi_ hence it needs new maintainer... > > Maintaining this package requires time and skills. Please only adopt this > package if you will have enough time and attention to work on it. > > If you want to be the new maintainer, please see [1] for detailed > instructions how to adopt a package properly. > > [1]: https://www.debian.org/devel/wnpp/index.html#howto-o > > -- > Regards, > Dmitry Smirnov.
Bug#873553: O: ncurses-hexedit -- Edit files/disks in hex, ASCII and EBCDIC
Control: retitle -1 "ITA: ncurses-hexedit -- Edit files/disks in hex, ASCII and EBCDIC" Control: owner -1 ! I would like to adopt this package. On Tue, 29 Aug 2017 01:00:52 +0200 Tobias Frost wrote: > Package: wnpp > > The current maintainer of ncurses-hexedit, Manfred Lichtenstern , > is apparently not active anymore. Therefore, I orphan this package now. > > Maintaining a package requires time and skills. Please only adopt this > package if you will have enough time and attention to work on it. > > If you want to be the new maintainer, please see > https://www.debian.org/devel/wnpp/#howto-o for detailed > instructions how to adopt a package properly. > > Some information about this package: > > Package: ncurses-hexedit > Binary: ncurses-hexedit > Version: 0.9.7-14.1 > Maintainer: Manfred Lichtenstern > Build-Depends: debhelper (>> 5.0.0), libncurses5-dev (>> 5.0.0) > Architecture: any > Standards-Version: 3.8.0 > Format: 1.0 > Files: > 1c7f1df81947360734c4412b15a588f0 2454 ncurses-hexedit_0.9.7-14.1.dsc > 7c7232503edb3e9a01f59df64978bf9f 165225 ncurses-hexedit_0.9.7.orig.tar.gz > a486741ba8e7964e9e279208dd2a10c8 24501 ncurses-hexedit_0.9.7-14.1.diff.gz > Checksums-Sha256: > 2cffbd13ca43c48555de8dfb25befdcc1d1be68dbc5630e0595c914b560d1bd2 2454 ncurses-hexedit_0.9.7-14.1.dsc > 65c035e7778208a28480354bff093c4335fde1ea5b745ef76589536731f6e1e8 165225 ncurses-hexedit_0.9.7.orig.tar.gz > cc368147e77bbe5d52f74fe1bac825e7159287d5751bf4458fba3be8ebe4b8f1 24501 ncurses-hexedit_0.9.7-14.1.diff.gz > Package-List: > ncurses-hexedit deb editors optional > Directory: pool/main/n/ncurses-hexedit > Priority: source > Section: editors > > Package: ncurses-hexedit > Source: ncurses-hexedit (0.9.7-14.1) > Version: 0.9.7-14.1+b1 > Installed-Size: 126 > Maintainer: Manfred Lichtenstern > Architecture: amd64 > Depends: libc6 (>= 2.14), libncurses5 (>= 6), libtinfo5 (>= 6) > Description-en: Edit files/disks in hex, ASCII and EBCDIC > Hexedit is a file editor which allows editing and viewing a file in > hexadecimal, along with its ASCII or EBCDIC text equivalent. Standard > editing features include insert, delete, search (text or byte searches), > highlighted changes, undo, two different viewing formats, and full > screen text snapshots. Allows editing of fixed disks as well. Includes > a binary/octal/decimal/hex converter. > Description-md5: 69472dca280af3ec4b8f4b7bb446b41b > Tag: interface::text-mode, role::program, scope::utility, uitoolkit::ncurses, > use::editing, works-with::file > Section: editors > Priority: optional > Filename: pool/main/n/ncurses-hexedit/ncurses-hexedit_0.9.7-14.1+b1_amd64.deb > Size: 65670 > MD5sum: 70e0ad5f55e6319287c63c67f2889ec3 > SHA256: 873f538a98d745959b98fe55275f1e2d3bad266af4e65ab3f9bcba1cfdb41c6b >
Bug#845155: RFS: rmlint/2.4.4
Control: rititle -1 ITP: rmlint -- file reduplication toolset Control: owner -1 ! Hi Chris, I intend to package your project for Debian, and almost have a complete working solution. My problem is when I try to build the package with sbuild (i.e. from inside a clean chroot), the nose tests never complete. Perhaps they eventually would, but I'm not prepared to wait that long. I have so far left it for a few hours. Building the package the normal way on my Debian box, works however, and the tests don't take too long at all. I've had a read of docs/testing.rst, but still can't figure out what could be causing the problem. The slow tests are already omitted, since the test command being used is: nosetests3 -s -v -a '!slow' i.e. without sudo. And as far as I know, only /dev/shm from within the chroot uses tmpfs. The underlying filesystem being used by the chroot is ext4. I've also tried setting RM_TS_DIR (i.e. changed from /tmp/rmlint-unit-testdir to /build/rmlint-unit-testdir), but got the same result. I can't tell you which tests get to complete, because nothing is output when using sbuild, even with RM_TS_PRINT_CMD=1. The tests do get printed out in a normal build however. The following are the only files that are created inside RM_TS_DIR if it is of any help: drwxrwsr-x 2 carlos sbuild 4096 Jan 15 02:25 . drwxrws--- 21 sbuild sbuild 4096 Jan 15 02:25 .. -rw-rw-r-- 1 carlos sbuild4 Jan 15 02:25 a -rw-rw-r-- 1 carlos sbuild4 Jan 15 02:25 b -rw-rw-r-- 1 carlos sbuild0 Jan 15 02:25 .csv-0 -rw-rw-r-- 1 carlos sbuild4 Jan 15 02:25 stupid'file,name The only other RM_TS variable I've set so far is RM_TS_PEDANTIC which I've set to 0. Do the tests only work in virtualized environments, but not chroot? Perhaps the only solution would be to disable the tests completely in a chroot. Cheers, Carlos On Sun, 20 Nov 2016 22:12:30 +0100 Christopher Pahl wrote: > Package: sponsorship-requests > Severity: normal > > Hello. > > I'm the developer of rmlint (https://github.com/sahib/rmlint), a file deduplication toolset. > It tries to be more useful (helps in actually deleting the found duplicate data), > faster (something between 5x and 30x) and better tested than the popular fdupes. > Additionally an optional GUI written in Python is included. > > Since I'm not a Debian myself user myself, I have a hard time bringing the software > into Debian, although I know (from bug reports and IRC) that many users of Debian based distributions > compile it from source. I tried to persuade Axel Beckert (https://wiki.debian.org/XTaran) to sponsor > it, but he seems to a bit too busy. He did provide a basic packaging effort though, which can be found here: > > https://github.com/sahib/rmlint/pull/180 (does not include the GUI, should be probably a separate package) > > In short: I'm looking for a sponsor *and* maintainer (which do not need to be the same person). > Optimally the maintainer would be someone that uses rmlint from time to time. > The package already builds the cli and might only need minimal review. > > Sorry if this is not the right place to ask - I'm just a bit desparate since most other distributions > already ship rmlint. It's not that there aren't any volunteers, most of them just fail on the relative high > hurdle to bring a package into Debian. > > Best regards, > Chris Pahl > > -- System Information (this is a VM, due to reportbug): > Debian Release: 8.4 > APT prefers stable > APT policy: (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > >
Bug#849727: [Pkg-privacy-maintainers] Bug#849727: Adopting seahorse-nautilus?
Control: retitle -1 ITA: seahorse-nautilus -- Nautilus extension for Seahorse integration Control: owner -1 pkg-privacy-maintain...@lists.alioth.debian.org I've re-uploaded the necessary changes to mentors. Cheers, Carlos On Tue, 10 Jan 2017 12:18:00 + u wrote: > Hi Carlos, > > Carlos Maddela: > > On 09/01/17 20:29, intrigeri wrote: > >> Carlos Maddela: > > >>> I had been thinking of adopting this package myself, but since you'd > >>> like to adopt it too, I've opted for a QA upload instead. > >> How about joining pkg-privacy and participating in the maintenance of > >> this package there? Ulrike also expressed interest in taking care of > >> this package, so you two could help each other :) > > I'd be happy to do that. > > Great! > > Please tell me your Alioth handle if you have one, or create it and > click the "Request to join" button on > https://alioth.debian.org/projects/pkg-privacy/ > > >>> If you're > >>> interested in my changes, they are available here: > >>> https://mentors.debian.net/debian/pool/main/s/seahorse-nautilus/seahorse-nautilus_3.11.92-2.dsc, > >>> https://github.com/e7appew/pkg-seahorse-nautilus.git or the attached > >>> debdiff. > > >> Great, thanks! Do you think these changes are appropriate / safe for > >> Stretch? If you think so, then I'm happy to upload after someone has > >> reviewed your changes and made the additional ones that are necessary > >> adopted the package under the team's umbrella. Ulrike, perhaps? > > I can look at it this week. > > > Most of the changes are related to the packaging itself, which most > > end-users would not care about. The changes that would have the greatest > > impact on the end-user are the updates to translations, and possibly if > > problems to the code are exposed due to the hardened build, which I > > haven't detected any so far. I don't know if the changes are that > > important to be introducing them to Stretch at this late juncture. > > Thanks for working on this, Carlos. > > Cheers! > ulrike > >
Bug#849727: Adopting seahorse-nautilus?
On 09/01/17 20:29, intrigeri wrote: > Hi Carlos, hi team! > > Carlos Maddela: >> I had been thinking of adopting this package myself, but since you'd >> like to adopt it too, I've opted for a QA upload instead. > How about joining pkg-privacy and participating in the maintenance of > this package there? Ulrike also expressed interest in taking care of > this package, so you two could help each other :) I'd be happy to do that. >> If you're >> interested in my changes, they are available here: >> https://mentors.debian.net/debian/pool/main/s/seahorse-nautilus/seahorse-nautilus_3.11.92-2.dsc, >> https://github.com/e7appew/pkg-seahorse-nautilus.git or the attached >> debdiff. > Great, thanks! Do you think these changes are appropriate / safe for > Stretch? If you think so, then I'm happy to upload after someone has > reviewed your changes and made the additional ones that are necessary > adopted the package under the team's umbrella. Ulrike, perhaps? Most of the changes are related to the packaging itself, which most end-users would not care about. The changes that would have the greatest impact on the end-user are the updates to translations, and possibly if problems to the code are exposed due to the hardened build, which I haven't detected any so far. I don't know if the changes are that important to be introducing them to Stretch at this late juncture. > Cheers,
Bug#812613: O: dmalloc -- debug memory allocation library
Package: wnpp Followup-For: Bug #812613 Control: retitle -1 ITA: dmalloc -- debug memory allocation library Control: owner -1 ! I intend to adopt this package.
Bug#823128: RFP: proxychains-ng -- redirect connections through proxy servers
Control: retitle -1 ITP: proxychains-ng -- redirect connections through proxy servers On Sun, 1 May 2016 02:57:50 -0400 Jason Hennessey wrote: > Package: wnpp > Severity: wishlist > > The current proxychains package is relatively old, and development has > continued in a different project called proxychains-ng according to this > ubuntu report from 2013, the maintainer announced in a forum on the > original sourceforge site that development had moved to github: > https://bugs.launchpad.net/ubuntu/+source/proxychains/+bug/1109235 > > The new repo contains several useful additions, such as the ability to > specify a config file on the command line as well as using the remote > host to do DNS resolving (which allows things like resolving TOR onion > addresses), and may be found at: https://github.com/rofl0r/proxychains-ng > > Thanks for any help! > > >
