Bug#998697: ITP: bees -- a btrfs deduplication agent
Am Samstag, dem 06.11.2021 um 21:32 +0300 schrieb Alexander GQ Gerasiov: > Package: wnpp > Severity: wishlist > Owner: Alexander GQ Gerasiov > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name : bees > Version : 0.7 > Upstream Author : Zygo Blaxell b...@furryterror.org > * URL : https://github.com/Zygo/bees > * License : GPL-3+ > Programming Lang: C++ > Description : a btrfs deduplication agent > > Best-Effort Extent-Same, a btrfs deduplication agent. > > bees is a block-oriented userspace deduplication agent designed for > large > btrfs filesystems. It is an offline dedupe combined with an > incremental data > scan capability to minimize time data spends on disk from write to > dedupe. > Hi Alexander, I totally forgot to look if there's already an ITP filed when I did my one #1002036. How far are you with packaging? And do you want a Co-Maintainer? Though I'm only a DM not DD. I just did a first version of a Debian package avaible at: https://salsa.debian.org/fzielcke/bees/ Feel free to use anything of it. Regards, Felix
Bug#1002036: ITP: bees -- Best-Effort Extent-Same, a btrfs deduplication agent.
Package: wnpp Severity: wishlist Owner: Felix Zielcke X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: bees Version : 0.7 Upstream Author : Zygo Blaxell b...@furryterror.org * URL : https://github.com/Zygo/bees * License : GPL-3+ Programming Lang: C++ Description : Best-Effort Extent-Same, a btrfs deduplication agent. bees is a block-oriented userspace deduplication agent designed for large btrfs filesystems. It is an offline dedupe combined with an incremental data scan capability to minimize time data spends on disk from write to dedupe. I'm happy to maintain it inside a team or with co-maintainer(s). I'm only DM so if someone has interest in sponsoring this, feel free to contact me. First debianized version avaible at https://salsa.debian.org/fzielcke/bees I guess it's a problem for ftp-masters that copyright and license is only mentioned inside README.md, but not directly at the source files? Then it can't yet be uploaded.
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Am Freitag, dem 26.11.2021 um 15:34 +0100 schrieb Stephan Lachnit: > Hi Felix, > > I was a bit more stressed this week than I hoped, I'll try to look at > it > saturday or sunday. If you don't get a reply by monday morning, feel > free > to ping me again. Hi Stephan, here's your friendly ping. Did you have time to look at pcmemtest? Regards, Felix
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Am Samstag, dem 20.11.2021 um 18:47 +0100 schrieb Stephan Lachnit: > Sounds interesting. > > On Fri, Nov 19, 2021 at 8:03 PM wrote: > > > > I'm happy to maintain it inside a team or with co-maintainer(s). > > I'm only DM so if someone has interest in sponsoring this, feel > > free to > > contact me. > > If you need me as sponsor, ping me when the package is ready for > upload. Hi Stephan, do you have time to review it? I think it's ready to upload. > Regards > Stephan
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Am Samstag, dem 20.11.2021 um 10:00 -0500 schrieb Antoine Beaupré: > Do let me know if you need a sponsor. Hi Antoine, as talked on IRC: I would be happy if you do the review (audit) of pcmemtest. Since you didn't reply back if you actually do this now: Would be good to have a clear answer here on the ITP so others know I have you as a sponsor. TIA Felix
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Hi Adam, thanks for all your comments. Am Montag, dem 22.11.2021 um 09:27 +0100 schrieb Adam Borowski: > On Sun, Nov 21, 2021 at 04:46:50PM +0100, Felix Zielcke wrote: > > Am Sonntag, dem 21.11.2021 um 10:15 -0500 schrieb Antoine Beaupré: > > > i would suggest not blocking on the grub deployment. you can > > > probably > > > just deploy whatever architecture the package was built from, in > > > any > > > case. > > > I just added now the GRUB 2 integration and a README.Debian. > > The integration isn't triggered on the package's install, but it is > picked > up the next time something else bumps grub. I forgot that grub2 isn't using triggers. Added now a postinst based on the one from memtest86+. Except that I removed the lilo parts. > > > > Note that I mention in README.Debian one nasty bug/issue: > > > > In EFI mode the keyboard only works if you have the CSM aka legacy > > boot > > also enabled: > > > > https://github.com/martinwhitaker/pcmemtest/issues/2 > > This is a nasty one. It seems most new machines lack CSM; no one wants > to > support and validate 16-bit stuff -- it's effectively expending > resources > to have two BIOSes instead of one, and the 8086 one has no practical > usage. > I opened now upstream a new issue about this: https://github.com/martinwhitaker/pcmemtest/issues/13 But in the closed one he said, it takes a while to write a usb keyboard driver for EFI. > > Upstream doestn't say anything there that this will change. Issue was > > closed with the hint it's documented. And it will just run with > > default > > settings. > > It does, but using just a single thread. There's not exactly many x86 > machines with only a single hardware thread that are still in use. > > What about defaulting to SMP when there's no user input? The UP mode > has little purpose for existing -- if concurrent accesses to memory > break, they'll also break when running the actual productive task the > machine is supposed to do. > I also made an issue for this: https://github.com/martinwhitaker/pcmemtest/issues/14 I don't know the reasons why it's not enabled by default. So I woudn't change that for the first upload to Debian on my own. > Meow! Cheers! Felix
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Am Sonntag, dem 21.11.2021 um 10:15 -0500 schrieb Antoine Beaupré: > > i would suggest not blocking on the grub deployment. you can probably > just deploy whatever architecture the package was built from, in any > case. > > a. > Hi Antoine and Stephan, I just added now the GRUB 2 integration and a README.Debian. You can now review it. And I think it would be better to first upload this to experimental? So a bit more experienced Debian users can test it first. Note that I mention in README.Debian one nasty bug/issue: In EFI mode the keyboard only works if you have the CSM aka legacy boot also enabled: https://github.com/martinwhitaker/pcmemtest/issues/2 Upstream doestn't say anything there that this will change. Issue was closed with the hint it's documented. And it will just run with default settings. Is for you my salsa repo enough or just I also upload to mentors? Git repo is in git-buildpackage format: https://salsa.debian.org/fzielcke/pcmemtest TIA Felix
Bug#1000208: ITP: pcmemtest -- stand-alone memory tester
Am Samstag, dem 20.11.2021 um 10:00 -0500 schrieb Antoine Beaupré: > On 2021-11-19 19:50:45, fziel...@z-51.de wrote: > [...] > > > PCMemTest is a fork and rewrite of Memtest86+, which in turn was a > > fork of > > Memtest86. > > > > > > I'm happy to maintain it inside a team or with co-maintainer(s). > > I'm only DM so if someone has interest in sponsoring this, feel free > > to > > contact me. > > Great find! I was disappointed to find out that memtest86* is basically > unusable these days in Debian, and find this ITP to be very > interesting! > Do let me know if you need a sponsor. > > Did you test the program at all? Does it behave better than the > existing > memtest86 packages currently in Debian? > > a. Thanks for your interest :) I pushed now my first work to my personal salsa profile: https://salsa.debian.org/fzielcke/pcmemtest The files are for now in /usr/lib/pcmemtest There are 32bit and 64bit legacy BIOS + EFI files Not sure if there's actually a different between the 2 legacy BIOS versions. I haven't yet tried it myself but will do soon. The suggestion came from #btrfs IRC channel. So it can't be that bad. And I'm not sure how I want to do the GRUB integration. Due to the differences with 32bit and 64bit EFI. Is there actually a way to find out with what EFI version the system booted? Regards Felix
Bug#784856: duperemove
Am Mittwoch, den 21.09.2016, 17:00 +0100 schrieb peter.zahrad...@znik.sk: > Hi Felix, > > I can takeover building the package for this tool if you agree. > > regards, > Peter Zahradnik Hi, feel free to do so. Regards, Felix Zielcke
Bug#784856: ITP: duperemove -- Tools for deduping file systems
Package: wnpp Severity: wishlist Owner: Felix Zielcke * Package name: duperemove Version : 0.09.3 Upstream Author : Mark Fasheh * URL : https://github.com/markfasheh/duperemove * License : GPL 2, 2 Clause BSD Programming Lang: C Description : Tools for deduping file systems Duperemove is a simple tool for finding duplicated extents and submitting them for deduplication. Deduplication is currently only supported on btrfs. The package also includes some low level tools: show-shared-extens - lists if 2 files shares the same extens btrfs-extent-same - to directly use the btrfs-extent-same ioctl hashstats - prints information about a duperemove hashfile -- 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/20150509162409.31479.20297.reportbug@fz.local
Bug#516255: Bug #516255 ITA: azureus -- BitTorrent Client
Hi, >There's any chance I can adopt azureus and vuze? I suggest you ask Adnan (CC'ed) if he has still interest in it. Maybe you can both adopt it and work on it. If not then you can IMO go ahead and prepare a new package and upload it to mentors.debian.net and find a sponsor. Unfortunately I can't sponsor it, because I'm just a DM not a DD. -- Felix Zielcke -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#483025: ITA: reiserfsprogs
Am Sonntag, den 15.02.2009, 13:08 +0100 schrieb José Luis Tallón: > Hi all > > Now that we have released Lenny, it's time to start moving :-) > Any progrogess? As I said already earlier I'd prefer SVN. I'm now a DM so only the first upload would be a problem but not the further ones. I'd really like to takeover the package, I already did so for reiser4progs. -- Felix Zielcke -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#483025: ITA: reiserfsprogs
Am Sonntag, den 08.02.2009, 17:26 +0100 schrieb José Luis Tallón: > I still care much about reiserfsprogs, however. > It migt be interesting to co-maintain, anyway. Hi, there's a new upstream version [0] which I'd like to have in Debian. Do you want to do an upload soon and take over the package now or is it okay if I do it? [0] ftp://ftp.kernel.org/pub/linux/utils/fs/reiserfs/ -- Felix Zielcke -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#483025: ITA: reiserfsprogs
Hi, do you still plan to adopt reiserfsprogs? If not then I'll do it. I hope that I'm soon a DM -- Felix Zielcke -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
